From: Dmitry Sepp <dmitry.sepp@opensynergy.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: <virtio-dev@lists.oasis-open.org>, <linux-media@vger.kernel.org>,
<tfiga@chromium.org>, <keiichiw@chromium.org>,
<acourbot@chromium.org>, <alexlau@chromium.org>,
<dgreid@chromium.org>, <marcheu@chromium.org>,
<posciak@chromium.org>, <stevensd@chromium.org>,
<hverkuil@xs4all.nl>, <daniel@ffwll.ch>
Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
Date: Thu, 7 Nov 2019 14:09:34 +0100 [thread overview]
Message-ID: <1573181413.STYvEGL1rf@os-lin-dmo> (raw)
In-Reply-To: <20191107095657.72dlxzm4uz7ndkek@sirius.home.kraxel.org>
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.
I can point you to the differences I see:
virtio-vdec:
1. Both the device and the driver submit requests to each other. For each
request the response is sent as a separate request.
2. No support for getting/setting video stream parameters. For example
(decoder): output format (NV12, I420), so the driver cannot really select the
output format after headers have been parsed.
3. No support for getting plane requirements from the device (sg vs contig,
size, stride alignment, plane count).
4. In the vdec device Drain and Flush are not separate for each buffer queue.
So seek and dynamic resolution change (adaptive playback) cannot be
implemented because 'flush' can have different meaning for a resolution change
and a seek.
5. Decoder only: new devices will be needed to support encoder, processor or
capture. Currently input is always a bitstream, output is always a video
frame. No way set input format (needed for encoder, see 2).
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.
3. Generic: can support any type of video device right away due to flexibility
of stream configuration. Both input and output buffer queues can accept
bitstream and frame buffers and run independently. (more controls need to be
defined for e.g. camera)
4. Supports seek, drain, dynamic resolution change using an API agnostic
command set (no v4l2/vaapi or so on remoting).
5. Complex configuration (most likely cannot be simplified for such a complex
device type).
Best regards,
Dmitry.
On Donnerstag, 7. November 2019 10:56:57 CET Gerd Hoffmann wrote:
> On Tue, Nov 05, 2019 at 08:19:19PM +0100, Dmitry Sepp wrote:
> > [Resend after fixing an issue with the virtio-dev mailing list]
> >
> > This patch proposes a virtio specification for a new virtio video
> > device.
>
> Hmm, quickly looking over this, it looks simliar to the vdec draft
> posted a few weeks ago, with other device variants added but not
> fully specified yet.
>
> So, can you clarify the relationship between the two?
>
> thanks,
> Gerd
next prev parent reply other threads:[~2019-11-07 13:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 19:19 [RFC RESEND] virtio-video: Add virtio video device specification Dmitry Sepp
2019-11-07 9:56 ` [virtio-dev] " Gerd Hoffmann
2019-11-07 13:09 ` Dmitry Sepp [this message]
2019-11-08 7:49 ` Gerd Hoffmann
2019-11-08 7:58 ` Tomasz Figa
2019-11-08 9:51 ` Dmitry Sepp
2019-11-08 7:50 ` Tomasz Figa
2019-11-08 9:05 ` Gerd Hoffmann
2019-11-08 9:28 ` Keiichi Watanabe
2019-11-20 11:29 ` Gerd Hoffmann
2019-11-21 10:54 ` Dmitry Sepp
2019-12-04 7:48 ` Keiichi Watanabe
2019-12-04 9:16 ` Gerd Hoffmann
2019-12-04 19:11 ` Enrico Granata
2019-12-05 8:21 ` Keiichi Watanabe
2019-12-06 7:32 ` Gerd Hoffmann
2019-12-06 12:30 ` Keiichi Watanabe
2019-12-06 15:50 ` Enrico Granata
2019-12-09 13:43 ` Keiichi Watanabe
2019-12-09 10:46 ` Gerd Hoffmann
2019-12-09 11:38 ` Dmitry Sepp
2019-12-09 13:17 ` Keiichi Watanabe
2019-12-09 14:19 ` Dmitry Sepp
[not found] ` <CAPR809t2X3eEZj14Y-0CdnmzGZFhWKt2vwFSZBrEZbChQpmU_w@mail.gmail.com>
2019-12-10 13:16 ` Dmitry Sepp
2019-12-12 5:39 ` Keiichi Watanabe
2019-12-12 10:34 ` Dmitry Sepp
2019-12-13 14:20 ` Keiichi Watanabe
2019-12-13 16:31 ` Keiichi Watanabe
2019-12-20 14:24 ` Dmitry Sepp
2019-12-20 15:01 ` Keiichi Watanabe
2019-12-13 14:58 ` Christophe de Dinechin
2019-12-16 8:09 ` Tomasz Figa
2019-12-16 10:32 ` Gerd Hoffmann
2019-12-17 13:15 ` Tomasz Figa
2019-12-17 13:39 ` Gerd Hoffmann
2019-12-17 14:09 ` Keiichi Watanabe
2019-12-17 16:13 ` Dmitry Sepp
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=1573181413.STYvEGL1rf@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox