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?
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. Thank you. Thanks, Liang At 2011-01-10 22:24:15，"Alon Levy" <al...@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" <al...@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@lists.freedesktop.org >> >> http://lists.freedesktop.org/mailman/listinfo/spice-devel >> >
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
