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

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > > > 3. No support for getting plane requirements from the device (sg vs contig,
> > > > size, stride alignment, plane count).
> > >
> > > There is actually a bigger difference that results in that. Vdec
> > > assumes host-allocated buffers coming from a different device, e.g.
> > > virtio-gpu and the host having the right knowledge to allocate the
> > > buffers correctly. This is related to the fact that it's generally
> > > difficult to convey all the allocation constraints in a generic
> > > manner.
> >
> > Yep, buffer handling is tricky, especially when it comes to decoding
> > directly to gpu buffers and also when supporting playback of
> > drm-protected streams where the guest might not be allowed to access
> > the stream data.

> Also, if we decide to have a buffer sharing device as Gerd suggested
> in a different thread,
> we'll get less overlaps between video codec feature and camera feature.
> e.g. VIRTIO_VIDEO_T_RESOURCE_* would be simplified. (or removed?)

Disclaimer: Havn't found the time yet to go over both virtio-video and
virtio-vdec in detail.

> As Tomasz said, I think virtio-vdec can be modified to support
> encoding as well without big changes.  I'm happy to update our
> protocol and driver implementation to support encoding if needed.

I think it makes sense to have a rough plan first ;)
Is there a virtio-video implementation too?

When it comes to buffer handling:  I don't like that virtio-vdec depends
on virtio-gpu for buffer handling.  Allowing sharing buffers between
virtio-vdec and virtio-gpu (and possibly other devices) makes sense as
an optional extension.  But IMO the encoder/decoder device should be
able to operate as stand-alone device.

cheers,
  Gerd