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

[Alexandre Courbot <acourbot@chromium.org>]

Hi Alex (are we having too many Alexes in this discussion? ^_^;)

On Thu, Jan 12, 2023 at 5:20 AM Alex BennÃe <alex.bennee@linaro.org> wrote:
>
>
> 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.

Note that using V4L2 here wouldn't bind us to Linux on either the host
or guest, it would just provide definitions of structures and
processes to perform video tasks. You can think of it as the way FUSE
is used in virtio-fs.