From: Gerd Hoffmann <kraxel@redhat.com>
To: Natalia Portillo <claunia@claunia.com>
Cc: "Peter Baitz" <ussenterprisencc1701@rocketmail.com>,
"Andreas Färber" <andreas.faerber@web.de>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Webcams under KVM and Linux
Date: Tue, 31 May 2011 09:01:57 +0200 [thread overview]
Message-ID: <4DE49265.6010300@redhat.com> (raw)
In-Reply-To: <FB8C46E5-915A-485D-BB78-9AABA7A46C9D@claunia.com>
Hi,
>>> Takes a frame from ANY available V4L2 device (/dev/video0),
>>> caches it, and sends it completely to the guest before requesting
>>> any other frame.
>>
>> I think you can double-buffer (i.e. let the host driver fill one
>> buffer while sending the other one to the guest). Probably gives a
>> slightly higher frame rate, but maybe at cost of added latencies.
>
> Indeed you can infinite-buffer it, but there is really no gain, the
> added latency makes an effective lower frame rate (total number of
> real frames seen by the guest in percentage)
Just two buffers, so capture and sending to the guest can be
parallelized. More buffers don't really help and just increase latency.
>> Nice. Patches are waiting for EHCI being merged I guess?
>
> Patches are on RFC on June 2010 ML messages. There are some updates I
> did to the emulation (internal conversion from YUV2 to MJPEG, gives
> twice the framerate when the host webcam is YUV2 only) that I have
> not sent to RFC yet.
Can you repost the latest version for review so we can get the bits merged?
> There are also some things that can be enhanced (conversion of more
> strange RAWs like OV511's, show the guest the controls of the real
> webcam) easily but I won't do that until a legal problem about the
> usage of my emulation code along with all the rest of QEMU by a
> commercial vendor in violation of GPL is solved.
Thats fine, we can always add it later once the legal issues are sorted.
> It works really well with USB 1.1 (up to 24fps with KVM, up to 10fps
> with TCG), but your when EHCI is merged it will allow bigger
> resolutions easily
Great.
> The most curious and interesting thing is that, while the
> specification says there can be webcams using bulk transfers (that's
> what mine is doing) I've seen NONE in wild. All do ISO.
Using bulk certainly makes sense for a virtual device.
cheers,
Gerd
next prev parent reply other threads:[~2011-05-31 7:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-29 13:01 [Qemu-devel] Webcams under KVM and Linux Peter Baitz
2011-05-29 13:37 ` Andreas Färber
2011-05-29 13:53 ` Natalia Portillo
2011-05-29 14:03 ` Peter Baitz
2011-05-30 12:50 ` Natalia Portillo
2011-05-30 14:56 ` Gerd Hoffmann
2011-05-30 18:19 ` Natalia Portillo
2011-05-31 7:01 ` Gerd Hoffmann [this message]
2011-05-30 16:34 ` Peter Baitz
2011-05-30 10:38 ` Gerd Hoffmann
2011-05-30 20:47 ` Brad Hards
2011-05-30 23:39 ` Natalia Portillo
2011-05-31 0:41 ` Brad Hards
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=4DE49265.6010300@redhat.com \
--to=kraxel@redhat.com \
--cc=andreas.faerber@web.de \
--cc=claunia@claunia.com \
--cc=qemu-devel@nongnu.org \
--cc=ussenterprisencc1701@rocketmail.com \
/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.