[Spice-devel] video passthrough ideas
Marc-André Lureau
mlureau at redhat.com
Thu May 12 08:56:39 PDT 2011
Hi Zeeshan,
(quick reply)
----- Original Message -----
> Hi everyone,
> 1. VAAPI (Video Acceleration API): The idea here is to implement a
> custom VAAPI driver for the guest that redirects all decoding/playback
> calls to the client through a spice channel. On the client side, we
> create a channel handler based on gstreamer and its playbin2 element.
>
> a. We still need to figure out how our VAAPI driver running in
> user-space (its loaded as shared-object in the application) will
> communicate to the spice server running inside Qemu?
I think that's what spicevmc channels are for. Someone else should tell you the details, or you'll have to investigate a little the agent code.
> e. Haven't yet figured how the interaction with QXL/windowing-system
> on client can/will work (i-e telling QXL to leave the part of the
> screen where the video is being played on as blank etc), need to read
> more of QXL and VAAPI code to figure i guess.
It should be "composited" like we do with other surfaces (including mjpeg).
My concern for VAAPI though (and other acceleration API) is that it is not a sink, which handle completely decoding and displaying. I understand it can take care of some expensive operations, but the result probably has to be returned to the server/guest. If that's the case, that won't fly well. Perhaps a trick would be to keep and send the original data, and find a way to use it in the client... (btw, I wouldn't be surprised if V4L2 has some way to send and display MPEG streams)
> 2. GStreamer all the way: This is the idea that I originally came-up
> with when Christophe suggested a "magic GStreamer element" on IRC. The
This is indeed a solution we have discussed in the past. It has several advantages:
- at the moment there are just too many video acceleration API to choose one, so going higher level sounds reasonable
- we have a fairly good idea how to do it, since we know GStreamer etc..
- we could send the whole stream to the client, which give us same advantage for audio, easy a/v sync, and a separate audio channel for free
- it will work for any client platform (spice-gtk already works with GStreamer on Windows)
- if the solution is proved to be robust and simple, for Windows, a DirectShow sink could convert the stream to a GStreamer flow, which will be handled in GDP the same way
- for MacOS, I suppose we could also write a simple QuickTime component doing the same conversion
Just my 2 cents, keep looking!
--
Marc-André Lureau
More information about the Spice-devel
mailing list