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

[Alon Levy]

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
> >