On Mon, Aug 24, 2009 at 11:32:05PM -0500, DRC wrote: > Hi. I run the VirtualGL Project, which produces a TightVNC derivative > called TurboVNC. I am also involved with the next generation TigerVNC > Project, which aims to replace both. TurboVNC has been unofficially > using the following extensions to the RFB protocol, and I wanted to see > if I could make these official so we could use them in TigerVNC as well: > > > Special encoding numbers: > ------------------------- > 0xFFFFFE00 .. 0xFFFFFE64 -- fine-grained quality level (0-100 scale) > > rfbEncodingFineQualityLevel0 0xFFFFFE00 > rfbEncodingFineQualityLevel100 0xFFFFFE64 > > 0xFFFFFD00 .. 0xFFFFFD05 -- subsampling level, for image compression > methods that support it > > rfbEncodingSubsamp1X 0xFFFFFD00 > rfbEncodingSubsamp4X 0xFFFFFD01 > rfbEncodingSubsamp2X 0xFFFFFD02 > rfbEncodingSubsampGray 0xFFFFFD03 > rfbEncodingSubsamp8X 0xFFFFFD04 > rfbEncodingSubsamp16X 0xFFFFFD05 > > (NOTE: these are out of order for historical reasons.) > > sig_rfbEncodingFineQualityLevel "FINEQLVL" > sig_rfbEncodingSubsampLevel "SSAMPLVL"
There is a bug report about creation of the separate JPEG encoding - http://sourceforge.net/tracker/?func=detail&aid=2674740&group_id=254363&atid=1126849. If we are really going to create new JPEG encoding and document it in the RFB protocol we should not create separate encoding for each quality level. We should include image quality control as part of the JPEG encoding. I know it will take more time than straightforward port from TurboVNC. What do you think about that? > > Tight Encoding: > --------------- > > Propose to extend the compression control byte for Tight encoding as > follows: Unfortunately I don't think we can extend the Tight encoding. You should discuss this change with Constantin. > > rfbTightNoZlib 0x0A > > The first byte of each Tight-encoded rectangle is a "compression control > byte". Its format is as follows (bit 0 is the least significant one): > > bit 0: if 1, then compression stream 0 should be reset; > bit 1: if 1, then compression stream 1 should be reset; > bit 2: if 1, then compression stream 2 should be reset; > bit 3: if 1, then compression stream 3 should be reset; > bits 7-4: if 1000 (0x08), then the compression type is "fill", > if 1001 (0x09), then the compression type is "jpeg", > > (*** NEW ***) if 1010 (0x0A), then the compression type is > "basic" and no Zlib compression was used (*** NEW ***) > > if 0xxx, then the compression type is "basic" and Zlib > compression was used, > values greater than 1010 are not valid. > > If the compression type is "basic" and Zlib compression was used, then > bits 5..4 of the compression control byte specify the following: > > bits 5-4: decimal representation is the index of a particular zlib > stream which should be used for decompressing the data. > > Bit 6 of the compression control byte specifies the following, > regardless of whether Zlib compression was used: > > bit 6: if 1, then a "filter id" byte is following this byte. > ... Regards, Adam -- Adam Tkac, Red Hat, Inc. _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
