From: "Michael S. Tsirkin" <mst@redhat.com>
To: Dmitry Sepp <dmitry.sepp@opensynergy.com>
Cc: Saket Sinha <saket.sinha89@gmail.com>,
Keiichi Watanabe <keiichiw@chromium.org>,
Kiran Pawar <Kiran.Pawar@opensynergy.com>,
Samiullah Khawaja <samiullah.khawaja@opensynergy.com>,
qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
Gerd Hoffmann <kraxel@redhat.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
Alexandre Courbot <acourbot@chromium.org>,
Tomasz Figa <tfiga@chromium.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Alex Lau <alexlau@chromium.org>,
Pawel Osciak <posciak@chromium.org>
Subject: Re: [virtio-dev] Re: Fwd: Qemu Support for Virtio Video V4L2 driver
Date: Mon, 11 May 2020 07:32:27 -0400 [thread overview]
Message-ID: <20200511073049-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <2515515.r9knKAEANn@os-lin-dmo>
On Mon, May 11, 2020 at 01:25:23PM +0200, Dmitry Sepp wrote:
> Hi Saket,
>
> On Montag, 11. Mai 2020 13:05:53 CEST Saket Sinha wrote:
> > Hi Keiichi,
> >
> > I do not support the approach of QEMU implementation forwarding
> > requests to the host's vicodec module since this can limit the scope
> > of the virtio-video device only for testing,
>
> That was my understanding as well.
>
> > which instead can be used with multiple use cases such as -
> >
> > 1. VM gets access to paravirtualized camera devices which shares the
> > video frames input through actual HW camera attached to Host.
>
> This use-case is out of the scope of virtio-video. Initially I had a plan to
> support capture-only streams like camera as well, but later the decision was
> made upstream that camera should be implemented as separate device type. We
> still plan to implement a simple frame capture capability as a downstream
> patch though.
You want to spec out what's in the field, spec-wise internal up/down
stream distinctions are not important.
> >
> > 2. If Host has multiple video devices (especially in ARM SOCs over
> > MIPI interfaces or USB), different VM can be started or hotplugged
> > with selective video streams from actual HW video devices.
>
> We do support this in our device implementation. But spec in general has no
> requirements or instructions regarding this. And it is in fact flexible enough
> to provide abstraction on top of several HW devices.
>
> >
> > Also instead of using libraries like Gstreamer in Host userspace, they
> > can also be used inside the VM userspace after getting access to
> > paravirtualized HW camera devices .
> >
>
> Regarding the cameras, unfortunately same as above.
>
> Best regards,
> Dmitry.
>
> > Regards,
> > Saket Sinha
> >
> > On Mon, May 11, 2020 at 12:20 PM Keiichi Watanabe <keiichiw@chromium.org>
> wrote:
> > > Hi Dmitry,
> > >
> > > On Mon, May 11, 2020 at 6:40 PM Dmitry Sepp <dmitry.sepp@opensynergy.com>
> wrote:
> > > > Hi Saket and all,
> > > >
> > > > As we are working with automotive platforms, unfortunately we don't plan
> > > > any Qemu reference implementation so far.
> > > >
> > > > Of course we are ready to support the community if any help is needed.
> > > > Is
> > > > there interest in support for the FWHT format only for testing purpose
> > > > or you want a full-featured implementation on the QEMU side?
> > >
> > > I guess we don't need to implement the codec algorithm in QEMU.
> > > Rather, QEMU forwards virtio-video requests to the host video device
> > > or a software library such as GStreamer or ffmpeg.
> > > So, what we need to implement in QEMU is a kind of API translation,
> > > which shouldn't care about actual video formats so much.
> > >
> > > Regarding the FWHT format discussed in the patch thread [1], in my
> > > understanding, Hans suggested to have QEMU implementation forwarding
> > > requests to the host's vicodec module [2].
> > > Then, we'll be able to test the virtio-video driver on QEMU on Linux
> > > even if the host Linux has no hardware video decoder.
> > > (Please correct me if I'm wrong.)
> > >
> > > Let me add Hans and Linux media ML in CC.
> > >
> > > [1] https://patchwork.linuxtv.org/patch/61717/
> > > [2] https://lwn.net/Articles/760650/
> > >
> > > Best regards,
> > > Keiichi
> > >
> > > > Please note that the spec is not finalized yet and a major update is now
> > > > discussed with upstream and the Chrome OS team, which is also interested
> > > > and deeply involved in the process. The update mostly implies some
> > > > rewording and reorganization of data structures, but for sure will
> > > > require a driver rework.
> > > >
> > > > Best regards,
> > > > Dmitry.
> > > >
> > > > On Samstag, 9. Mai 2020 16:11:43 CEST Saket Sinha wrote:
> > > > > Hi,
> > > > >
> > > > > As suggested on #qemu-devel IRC channel, I am including virtio-dev,
> > > > > Gerd and Michael to point in the right direction how to move forward
> > > > > with Qemu support for Virtio Video V4L2 driver
> > > > > posted in [1].
> > > > >
> > > > > [1]: https://patchwork.linuxtv.org/patch/61717/
> > > > >
> > > > > Regards,
> > > > > Saket Sinha
> > > > >
> > > > > On Sat, May 9, 2020 at 1:09 AM Saket Sinha <saket.sinha89@gmail.com>
> wrote:
> > > > > > Hi ,
> > > > > >
> > > > > > This is to inquire about Qemu support for Virtio Video V4L2 driver
> > > > > > posted in [1].
> > > > > > I am currently not aware of any upstream effort for Qemu reference
> > > > > > implementation and would like to discuss how to proceed with the
> > > > > > same.
> > > > > >
> > > > > > [1]: https://patchwork.linuxtv.org/patch/61717/
> > > > > >
> > > > > > Regards,
> > > > > > Saket Sinha
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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:[~2020-05-11 11:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAK25hWN3kJcW-dcpryFrvZ50t7Y0Z=MZM66-8NMuhwjRpNo2aQ@mail.gmail.com>
[not found] ` <CAK25hWMj5PyQFZVN5AToHjdySvi6iZ4zjZeUJQR85jNgoeLeAw@mail.gmail.com>
[not found] ` <CAK25hWOPS1wGORXgtv8hUNu9-mLO+5C_k3Cj=8pnoFWmjuhJdg@mail.gmail.com>
[not found] ` <2405792.XL1faGB9W5@os-lin-dmo>
2020-05-11 10:20 ` [virtio-dev] Re: Fwd: Qemu Support for Virtio Video V4L2 driver Keiichi Watanabe
2020-05-11 11:05 ` Saket Sinha
2020-05-11 11:25 ` Dmitry Sepp
2020-05-11 11:32 ` Michael S. Tsirkin [this message]
2020-05-11 11:34 ` Michael S. Tsirkin
2020-05-11 11:49 ` Keiichi Watanabe
2020-05-11 12:32 ` Saket Sinha
2020-05-11 14:06 ` Keiichi Watanabe
2020-05-11 14:31 ` [libcamera-devel] " Laurent Pinchart
2020-05-12 12:10 ` Dmitry Sepp
2020-05-14 23:38 ` Nicolas Dufresne
2020-05-19 8:37 ` Keiichi Watanabe
2020-05-19 17:29 ` Nicolas Dufresne
2020-05-20 3:19 ` Alexandre Courbot
2020-05-20 16:21 ` Nicolas Dufresne
2020-05-20 16:27 ` Michael S. Tsirkin
2020-05-20 16:56 ` Nicolas Dufresne
2020-05-21 7:08 ` Alexandre Courbot
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=20200511073049-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Kiran.Pawar@opensynergy.com \
--cc=acourbot@chromium.org \
--cc=alexlau@chromium.org \
--cc=dmitry.sepp@opensynergy.com \
--cc=hverkuil@xs4all.nl \
--cc=keiichiw@chromium.org \
--cc=kraxel@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=posciak@chromium.org \
--cc=qemu-devel@nongnu.org \
--cc=saket.sinha89@gmail.com \
--cc=samiullah.khawaja@opensynergy.com \
--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;
as well as URLs for NNTP newsgroup(s).