Hi,<br><br>Sorry for any confuse.&nbsp; My 1st question is:<br>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? <br><br>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.<br><br>Thank you.<br><br>Thanks,<br>Liang<br><pre><br>At&nbsp;2011-01-10&nbsp;22:24:15£¬"Alon&nbsp;Levy"&nbsp;&lt;alevy@redhat.com&gt;&nbsp;wrote:

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