From: Dmitry Sepp <dmitry.sepp@opensynergy.com>
To: virtio-dev@lists.oasis-open.org
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
"Keiichi Watanabe" <keiichiw@chromium.org>,
"Tomasz Figa" <tfiga@chromium.org>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Alexandre Courbot" <acourbot@chromium.org>,
"Alex Lau" <alexlau@chromium.org>,
"Dylan Reid" <dgreid@chromium.org>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Pawel Osciak" <posciak@chromium.org>,
"David Stevens" <stevensd@chromium.org>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
Date: Thu, 21 Nov 2019 11:54:57 +0100 [thread overview]
Message-ID: <7736193.Whgddqjo8n@os-lin-dmo> (raw)
In-Reply-To: <20191120112929.gvsne7ykvcyw65lu@sirius.home.kraxel.org>
Hi Gerd,
On Mittwoch, 20. November 2019 12:29:29 CET Gerd Hoffmann wrote:
> 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?
Yes, of course. We will be ready to share the code very soon.
Regards,
Dmitry.
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Sepp <dmitry.sepp@opensynergy.com>
To: <virtio-dev@lists.oasis-open.org>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
"Keiichi Watanabe" <keiichiw@chromium.org>,
"Tomasz Figa" <tfiga@chromium.org>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Alexandre Courbot" <acourbot@chromium.org>,
"Alex Lau" <alexlau@chromium.org>,
"Dylan Reid" <dgreid@chromium.org>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Pawel Osciak" <posciak@chromium.org>,
"David Stevens" <stevensd@chromium.org>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
Date: Thu, 21 Nov 2019 11:54:57 +0100 [thread overview]
Message-ID: <7736193.Whgddqjo8n@os-lin-dmo> (raw)
In-Reply-To: <20191120112929.gvsne7ykvcyw65lu@sirius.home.kraxel.org>
Hi Gerd,
On Mittwoch, 20. November 2019 12:29:29 CET Gerd Hoffmann wrote:
> 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?
Yes, of course. We will be ready to share the code very soon.
Regards,
Dmitry.
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2019-11-21 10:55 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 19:19 [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification Dmitry Sepp
2019-11-05 19:19 ` Dmitry Sepp
2019-11-07 9:56 ` [virtio-dev] " Gerd Hoffmann
2019-11-07 9:56 ` Gerd Hoffmann
2019-11-07 13:09 ` Dmitry Sepp
2019-11-07 13:09 ` Dmitry Sepp
2019-11-08 7:49 ` Gerd Hoffmann
2019-11-08 7:49 ` Gerd Hoffmann
2019-11-08 7:58 ` Tomasz Figa
2019-11-08 7:58 ` Tomasz Figa
2019-11-08 9:51 ` Dmitry Sepp
2019-11-08 9:51 ` Dmitry Sepp
2019-11-08 7:50 ` Tomasz Figa
2019-11-08 7:50 ` Tomasz Figa
2019-11-08 9:05 ` Gerd Hoffmann
2019-11-08 9:05 ` Gerd Hoffmann
2019-11-08 9:28 ` Keiichi Watanabe
2019-11-08 9:28 ` Keiichi Watanabe
2019-11-20 11:29 ` Gerd Hoffmann
2019-11-20 11:29 ` Gerd Hoffmann
2019-11-21 10:54 ` Dmitry Sepp [this message]
2019-11-21 10:54 ` Dmitry Sepp
2019-12-04 7:48 ` Keiichi Watanabe
2019-12-04 7:48 ` Keiichi Watanabe
2019-12-04 9:16 ` Gerd Hoffmann
2019-12-04 9:16 ` Gerd Hoffmann
2019-12-04 19:11 ` Enrico Granata
2019-12-04 19:11 ` Enrico Granata
2019-12-05 8:21 ` Keiichi Watanabe
2019-12-05 8:21 ` Keiichi Watanabe
2019-12-06 7:32 ` Gerd Hoffmann
2019-12-06 7:32 ` Gerd Hoffmann
2019-12-06 12:30 ` Keiichi Watanabe
2019-12-06 12:30 ` Keiichi Watanabe
2019-12-06 15:50 ` Enrico Granata
2019-12-06 15:50 ` Enrico Granata
2019-12-09 13:43 ` Keiichi Watanabe
2019-12-09 13:43 ` Keiichi Watanabe
2019-12-09 10:46 ` Gerd Hoffmann
2019-12-09 10:46 ` Gerd Hoffmann
2019-12-09 11:38 ` Dmitry Sepp
2019-12-09 11:38 ` Dmitry Sepp
2019-12-09 13:17 ` Keiichi Watanabe
2019-12-09 13:17 ` Keiichi Watanabe
2019-12-09 14:19 ` Dmitry Sepp
2019-12-09 14:19 ` Dmitry Sepp
2019-12-09 21:12 ` Enrico Granata
2019-12-10 13:16 ` Dmitry Sepp
2019-12-10 13:16 ` Dmitry Sepp
2019-12-12 5:39 ` Keiichi Watanabe
2019-12-12 5:39 ` Keiichi Watanabe
2019-12-12 10:34 ` Dmitry Sepp
2019-12-12 10:34 ` Dmitry Sepp
2019-12-13 14:20 ` Keiichi Watanabe
2019-12-13 14:20 ` Keiichi Watanabe
2019-12-13 16:31 ` Keiichi Watanabe
2019-12-13 16:31 ` Keiichi Watanabe
2019-12-20 14:24 ` Dmitry Sepp
2019-12-20 14:24 ` Dmitry Sepp
2019-12-20 15:01 ` Keiichi Watanabe
2019-12-20 15:01 ` Keiichi Watanabe
2019-12-13 14:58 ` Christophe de Dinechin
2019-12-13 14:58 ` Christophe de Dinechin
2019-12-16 8:09 ` Tomasz Figa
2019-12-16 8:09 ` Tomasz Figa
2019-12-16 10:32 ` Gerd Hoffmann
2019-12-16 10:32 ` Gerd Hoffmann
2019-12-17 13:15 ` Tomasz Figa
2019-12-17 13:15 ` Tomasz Figa
2019-12-17 13:39 ` Gerd Hoffmann
2019-12-17 13:39 ` Gerd Hoffmann
2019-12-17 14:09 ` Keiichi Watanabe
2019-12-17 14:09 ` Keiichi Watanabe
2019-12-17 16:13 ` Dmitry Sepp
2019-12-17 16:13 ` Dmitry Sepp
2019-12-18 6:43 ` Gerd Hoffmann
2019-12-18 6:43 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7736193.Whgddqjo8n@os-lin-dmo \
--to=dmitry.sepp@opensynergy.com \
--cc=acourbot@chromium.org \
--cc=alexlau@chromium.org \
--cc=daniel@ffwll.ch \
--cc=dgreid@chromium.org \
--cc=hverkuil@xs4all.nl \
--cc=keiichiw@chromium.org \
--cc=kraxel@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=marcheu@chromium.org \
--cc=posciak@chromium.org \
--cc=stevensd@chromium.org \
--cc=tfiga@chromium.org \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.