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

[Dmitry Sepp <dmitry.sepp@opensynergy.com>]

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