vnc-enc-tight.h 8.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183
  1. /*
  2. * QEMU VNC display driver: tight encoding
  3. *
  4. * From libvncserver/rfb/rfbproto.h
  5. * Copyright (C) 2005 Rohit Kumar, Johannes E. Schindelin
  6. * Copyright (C) 2000-2002 Constantin Kaplinsky. All Rights Reserved.
  7. * Copyright (C) 2000 Tridia Corporation. All Rights Reserved.
  8. * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.
  9. *
  10. *
  11. * Permission is hereby granted, free of charge, to any person obtaining a copy
  12. * of this software and associated documentation files (the "Software"), to deal
  13. * in the Software without restriction, including without limitation the rights
  14. * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  15. * copies of the Software, and to permit persons to whom the Software is
  16. * furnished to do so, subject to the following conditions:
  17. *
  18. * The above copyright notice and this permission notice shall be included in
  19. * all copies or substantial portions of the Software.
  20. *
  21. * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  22. * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  23. * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
  24. * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  25. * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  26. * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  27. * THE SOFTWARE.
  28. */
  29. #ifndef VNC_ENC_TIGHT_H
  30. #define VNC_ENC_TIGHT_H
  31. /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  32. * Tight Encoding.
  33. *
  34. *-- The first byte of each Tight-encoded rectangle is a "compression control
  35. * byte". Its format is as follows (bit 0 is the least significant one):
  36. *
  37. * bit 0: if 1, then compression stream 0 should be reset;
  38. * bit 1: if 1, then compression stream 1 should be reset;
  39. * bit 2: if 1, then compression stream 2 should be reset;
  40. * bit 3: if 1, then compression stream 3 should be reset;
  41. * bits 7-4: if 1000 (0x08), then the compression type is "fill",
  42. * if 1001 (0x09), then the compression type is "jpeg",
  43. * if 1010 (0x0A), then the compression type is "png",
  44. * if 0xxx, then the compression type is "basic",
  45. * values greater than 1010 are not valid.
  46. *
  47. * If the compression type is "basic", then bits 6..4 of the
  48. * compression control byte (those xxx in 0xxx) specify the following:
  49. *
  50. * bits 5-4: decimal representation is the index of a particular zlib
  51. * stream which should be used for decompressing the data;
  52. * bit 6: if 1, then a "filter id" byte is following this byte.
  53. *
  54. *-- The data that follows after the compression control byte described
  55. * above depends on the compression type ("fill", "jpeg", "png" or "basic").
  56. *
  57. *-- If the compression type is "fill", then the only pixel value follows, in
  58. * client pixel format (see NOTE 1). This value applies to all pixels of the
  59. * rectangle.
  60. *
  61. *-- If the compression type is "jpeg" or "png", the following data stream
  62. * looks like this:
  63. *
  64. * 1..3 bytes: data size (N) in compact representation;
  65. * N bytes: JPEG or PNG image.
  66. *
  67. * Data size is compactly represented in one, two or three bytes, according
  68. * to the following scheme:
  69. *
  70. * 0xxxxxxx (for values 0..127)
  71. * 1xxxxxxx 0yyyyyyy (for values 128..16383)
  72. * 1xxxxxxx 1yyyyyyy zzzzzzzz (for values 16384..4194303)
  73. *
  74. * Here each character denotes one bit, xxxxxxx are the least significant 7
  75. * bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the
  76. * most significant 8 bits (bits 14-21). For example, decimal value 10000
  77. * should be represented as two bytes: binary 10010000 01001110, or
  78. * hexadecimal 90 4E.
  79. *
  80. *-- If the compression type is "basic" and bit 6 of the compression control
  81. * byte was set to 1, then the next (second) byte specifies "filter id" which
  82. * tells the decoder what filter type was used by the encoder to pre-process
  83. * pixel data before the compression. The "filter id" byte can be one of the
  84. * following:
  85. *
  86. * 0: no filter ("copy" filter);
  87. * 1: "palette" filter;
  88. * 2: "gradient" filter.
  89. *
  90. *-- If bit 6 of the compression control byte is set to 0 (no "filter id"
  91. * byte), or if the filter id is 0, then raw pixel values in the client
  92. * format (see NOTE 1) will be compressed. See below details on the
  93. * compression.
  94. *
  95. *-- The "gradient" filter pre-processes pixel data with a simple algorithm
  96. * which converts each color component to a difference between a "predicted"
  97. * intensity and the actual intensity. Such a technique does not affect
  98. * uncompressed data size, but helps to compress photo-like images better.
  99. * Pseudo-code for converting intensities to differences is the following:
  100. *
  101. * P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1];
  102. * if (P[i,j] < 0) then P[i,j] := 0;
  103. * if (P[i,j] > MAX) then P[i,j] := MAX;
  104. * D[i,j] := V[i,j] - P[i,j];
  105. *
  106. * Here V[i,j] is the intensity of a color component for a pixel at
  107. * coordinates (i,j). MAX is the maximum value of intensity for a color
  108. * component.
  109. *
  110. *-- The "palette" filter converts true-color pixel data to indexed colors
  111. * and a palette which can consist of 2..256 colors. If the number of colors
  112. * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to
  113. * encode one pixel. 1-bit encoding is performed such way that the most
  114. * significant bits correspond to the leftmost pixels, and each raw of pixels
  115. * is aligned to the byte boundary. When "palette" filter is used, the
  116. * palette is sent before the pixel data. The palette begins with an unsigned
  117. * byte which value is the number of colors in the palette minus 1 (i.e. 1
  118. * means 2 colors, 255 means 256 colors in the palette). Then follows the
  119. * palette itself which consist of pixel values in client pixel format (see
  120. * NOTE 1).
  121. *
  122. *-- The pixel data is compressed using the zlib library. But if the data
  123. * size after applying the filter but before the compression is less then 12,
  124. * then the data is sent as is, uncompressed. Four separate zlib streams
  125. * (0..3) can be used and the decoder should read the actual stream id from
  126. * the compression control byte (see NOTE 2).
  127. *
  128. * If the compression is not used, then the pixel data is sent as is,
  129. * otherwise the data stream looks like this:
  130. *
  131. * 1..3 bytes: data size (N) in compact representation;
  132. * N bytes: zlib-compressed data.
  133. *
  134. * Data size is compactly represented in one, two or three bytes, just like
  135. * in the "jpeg" compression method (see above).
  136. *
  137. *-- NOTE 1. If the color depth is 24, and all three color components are
  138. * 8-bit wide, then one pixel in Tight encoding is always represented by
  139. * three bytes, where the first byte is red component, the second byte is
  140. * green component, and the third byte is blue component of the pixel color
  141. * value. This applies to colors in palettes as well.
  142. *
  143. *-- NOTE 2. The decoder must reset compression streams' states before
  144. * decoding the rectangle, if some of bits 0,1,2,3 in the compression control
  145. * byte are set to 1. Note that the decoder must reset zlib streams even if
  146. * the compression type is "fill", "jpeg" or "png".
  147. *
  148. *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only
  149. * when bits-per-pixel value is either 16 or 32, not 8.
  150. *
  151. *-- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048
  152. * pixels. If a rectangle is wider, it must be split into several rectangles
  153. * and each one should be encoded separately.
  154. *
  155. */
  156. #define VNC_TIGHT_EXPLICIT_FILTER 0x04
  157. #define VNC_TIGHT_FILL 0x08
  158. #define VNC_TIGHT_JPEG 0x09
  159. #define VNC_TIGHT_PNG 0x0A
  160. #define VNC_TIGHT_MAX_SUBENCODING 0x0A
  161. /* Filters to improve compression efficiency */
  162. #define VNC_TIGHT_FILTER_COPY 0x00
  163. #define VNC_TIGHT_FILTER_PALETTE 0x01
  164. #define VNC_TIGHT_FILTER_GRADIENT 0x02
  165. /* Note: The following constant should not be changed. */
  166. #define VNC_TIGHT_MIN_TO_COMPRESS 12
  167. /* The parameters below may be adjusted. */
  168. #define VNC_TIGHT_MIN_SPLIT_RECT_SIZE 4096
  169. #define VNC_TIGHT_MIN_SOLID_SUBRECT_SIZE 2048
  170. #define VNC_TIGHT_MAX_SPLIT_TILE_SIZE 16
  171. #define VNC_TIGHT_JPEG_MIN_RECT_SIZE 4096
  172. #define VNC_TIGHT_DETECT_SUBROW_WIDTH 7
  173. #define VNC_TIGHT_DETECT_MIN_WIDTH 8
  174. #define VNC_TIGHT_DETECT_MIN_HEIGHT 8
  175. #endif /* VNC_ENC_TIGHT_H */