public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
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



  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