Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification

Dmitry Sepp
2019-11-08T09:51:48Z

Hello Gerd,

Please see the answer below.

On Freitag, 8. November 2019 08:49:55 CET Gerd Hoffmann wrote:
> On Thu, Nov 07, 2019 at 02:09:34PM +0100, Dmitry Sepp wrote:
> > Hello Gerd,
> >
> > Thank you for your feedback.
> >
> > There is no relationship between those. As I mentioned earlier. we have
> > also been working on a virtio video device at the same time. And there is
> > no relationship between the two specs.
>
> Keiichi, have you looked at the spec?
>
> I think it is useful to have a single device specification for all video
> functions given that there is a bunch of common stuff. Both encoder and
> decoder must negotiate video frame and video stream parameters for
> example. Also the virtio-video spec looks like a superset of
> virtio-vdec.
>
> Is there any important feature in video-vdec which is missing in
> virtio-video?
>
> > virtio-video:
> > 1. Uses the 'driver requests - device responses' model.
> > 2. Does not have the logical split of bitstreams and framebuffers, has
> > only a generic buffer object.
>
> Can you give a quick summary on buffer object management?
Buffer objects are implemented in a similar way to how it was done for virtio-
gpu. The driver allocates a resource (descriptor) on the device. Than the
driver allocates/imports backing pages and attaches those to the resource.

When a buffer is ready for processing from the driver's point of view, the
driver queues it to the device (please see struct
virtio_video_resource_queue). Within this structure the driver provides
required metadata (number of data bytes in the buffer, timestamp/counter and so
on).

The nice thing about this is that there is no real decode or encode requests.
The device just fetches the buffer from the input queue, applies some
transformation according to its function and settings, fetches an output buffer
from the respective queue, and stores the result in the output buffer (or -s,
if needed).

The device keeps buffer requests until the respective buffer has been processed
(i.e. input is consumed or output is written). When the buffer is not needed
anymore, the virtio_video_resource_queue request completes asynchronously.
This also makes it possible to easily handle different frame types that are
decoded out-of-order.

Regards,
Dmitry.

>
> thanks,
> Gerd