Re: [RFC PATCH v6] virtio-video: Add virtio video device specification

[Alex BennÃe <alex.bennee@linaro.org>]

Alexander Gordeev <alexander.gordeev@opensynergy.com> writes:

> Hi Alexandre,
>
> On 27.12.22 08:31, Alexandre Courbot wrote:
>> Hi Alexander,
>>
>>
>> On Tue, Dec 20, 2022 at 1:59 AM Alexander Gordeev
>> <alexander.gordeev@opensynergy.com> wrote:
>>> Hello Alexandre,
>>>
>>> Thanks for the update. Please check my comments below.
>>> I'm new to the virtio video spec development, so I may lack some
>>> historic perspective. I would gladly appreciate pointing me to some
>>> older emails explaining decisions, that I might not understand. I hope
>>> to read through all of them later. Overall I have a lot of experience in
>>> the video domain and in virtio video device development in Opsy, so I
>>> hope, that my comments are relevant and useful.
>> Cornelia provided links to the previous versions (thanks!). Through
>> these revisions we tried different approaches, and the more we
>> progress the closer we are getting to the V4L2 stateful
>> decoder/encoder interface.
<snip>
>> This probably means a bit more work on the device side, since this
>> spec is tailored for the specific video codec use-case and V4L2 is
>> more generic, but also less spec to maintain and more confidence that
>> things will work as we want in the real world. On the other hand, the
>> device would also become simpler by the fact that responses to
>> commands could not come out-of-order as they currently do. So at the
>> end of the day I'm not even sure this would result in a more complex
>> device.
>
> Sorry for the delay. I tried to gather data about how the spec has
> evolved in the old emails.
>
> Well, on the one hand mimicking v4l2 looks like an easy solution from
> virtio-video spec writing perspective. (But the implementers will have
> to read the V4L2 API instead AFAIU, which is probably longer...)
>
> On the other hand v4l2 has a lot of history. It started as a camera API
> and gained the codec support later, right? So it definitely has just to
> much stuff irrelevant for codecs. Here we have an option to design from
> scratch taking the best ideas from v4l2.

We definitely don't want to bake in Linux APIs into the VirtIO spec
which is meant to be host/guest agnostic if we can help it.

>
> Also I have concerns about the virtio-video spec development. This seems
> like a big change. It seems to me that after so many discussions and
> versions of the spec, the process should be coming to something by now.
> But this is still a moving target...
>
> There were arguments against adding camera support for security and
> complexity reasons during discussions about virtio-video spec v1. Were
> these concerns addressed somehow? Maybe I missed a followup
> discussion?

I think adding camera support would introduce a lot of potential
complexity to the spec - c.f. projects like libcamera and the fact most
modern cameras are more than providing a stream of images. It probably
warrants having its own device specification that is designed from the
outset with cameras in mind.

-- 
Alex BennÃe
Virtualisation Tech Lead @ Linaro