[Spice-devel] The interaction between qxl driver and spiceserver for video stream?

[Alon Levy]

On Tue, Jan 11, 2011 at 11:50:05PM +0800, 梁亮 wrote:
> Hi,
> 
> Sorry for any confuse.  My 1st question is:
> from code red_send_stream_data(), it doesn't support SPICE_BITMAP_FMT_RGBA. My understanding is that this should also be one kind of 32bit BITMAP: RGB plus Alpha, each for 8 bits. For such unsupported format, current method is to use usual compression algorithm instead of MJPEG. Why not transfer them to 24bit bitmap at first and use MJPEG?
> 

Sounds right.

> The reason for me to ask this question is that: I setup one Guest OS (Windows XP) using qemu+kvm with spice and qxl enabled (qxl driver is also installed in Guest OS). The Guest OS desktop uses 32-bit color-depth. When I play some video in Guest OS, I noticed "unsupported format 9" log on the screen.
> 

Thanks, sounds like a bug. Would be great if you supplied information on recreating this, or better yet filed a bug report, or better better yet wrote a patch :) Bugzilla is at bugzilla.redhat.com (I think there is one setup on freedesktop but I'm not sure if we use it for spice).

> Thank you.
> 
> Thanks,
> Liang
> 
> 
> At 2011-01-10 22:24:15，"Alon Levy" <alevy at redhat.com> wrote:
> 
> >On Mon, Jan 10, 2011 at 09:20:39PM +0800, 梁亮 wrote:
> >> Hi,
> >> 
> >> Thanks for your kind information.  Yes, recently I digged the spice implementation and found some clues like what you mentioned :-)  I still have some questions regarding stream data:
> >> 1) from version 0.63 source code, it seems that 32bit bitmap format is not supported to use MJPEG, why?
> >
> >I don't understand the question - MJPEG isn't a bitmap format.
> >
> >> 2) for 32bit bitmap(format 9), there are two methods to process it depending on JPEG compression flag.  If bandwidth is ok, it will use high quality delivery. Otherwise it will use some lossy-compression algorithm. So what's the difference between the lossy-compression and MJPEG?
> >
> >MJPEG is for streaming. Basically, any rendering operation has two paths when the server reads it from the driver outgoing queue:
> > * should it be streamed?
> >   * yes:
> >    * is there an existing stream?
> >     * no: create one. if client exists: send creation to client. create mjpeg encoder
> >    * push to mjpeg encoder, take output and send to client if attached.
> >   * no:
> >    * send as usual: apply compression flags and heuristics to choose best, compress and
> >     send as a draw operation
> >
> >> 3) I'm really puzzled by the spice marshaller code... it seems that they are generated by some python modules/scripts, could anyone share something about it and the purpose?
> >> 
> >
> >Well, it's there to allow us to support both the old and the new protocols. It actually has a nice benefit that you can read the whole protocol by looking at spice.proto (new) and spice1.proto (old). Both in the root directory.
> >
> >> Have a nice day!
> >> 
> >> Thanks,
> >> Liang
> >> 
> >> 
> >> 
> >> At 2011-01-10 18:16:30，"Alon Levy" <alevy at redhat.com> wrote:
> >> 
> >> >On Fri, Dec 17, 2010 at 09:51:39PM +0800, 梁亮 wrote:
> >> >> Dear all,
> >> >> 
> >> >> Several days ago I tried using spice and really impressed by its  performance, really good job! Then I tried to dig the details, mainly focus on graphics subsystem and learned a lot. Thank you!
> >> >> 
> >> >> During studying the handling for stream data, I'm lost in the interaction of qemu display driver and spice server. So I send this mail to consult you experts some simple questions  :-)
> >> >> 1. For the video played in Guest OS, my understanding is that media player (for example, mplayer) in Guest OS will decode the video file and the display driver(qxl driver) will process decoded frames. Is it true? Then display driver will store frame data into stream chain of RedWorker? Each frame will be stored or just some key frames? For above descriptions, they are just my assumption, I have not found provens from the code. Help you could share some hints about the detail.
> >> >
> >> >The frames are fed one by one to the mjpeg encoder on the server, and its output is sent to the client if one is connected. Look in red_worker.c, track mjpeg_encoder and streams (streams belongs to RedWorker).
> >> >
> >> >> 2. Each stream data will be encoded using MJpeg on server side and decoded on client side. Have the team considered higher compression rate codec, like mpeg-4?  If yes, could you help share the reason why it's not adopted? My understanding is that video application is the killer application and consume much bandwidth for remote display system.
> >> >
> >> >We should definitely try adjusting the codec and it's parameters based on bandwidth/latency and cpu requirements.
> >> >
> >> >> 
> >> >> Thank you and have a nice weekend!
> >> >> 
> >> >> Thanks,
> >> >> Liang
> >> >
> >> >> _______________________________________________
> >> >> Spice-devel mailing list
> >> >> Spice-devel at lists.freedesktop.org
> >> >> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >> >