qemu

FORK: QEMU emulator
git clone https://git.neptards.moe/neptards/qemu.git
Log | Files | Refs | Submodules | LICENSE

vnc-enc-tight.h (8498B)


      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 
     30 #ifndef VNC_ENC_TIGHT_H
     31 #define VNC_ENC_TIGHT_H
     32 
     33 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     34  * Tight Encoding.
     35  *
     36  *-- The first byte of each Tight-encoded rectangle is a "compression control
     37  *   byte". Its format is as follows (bit 0 is the least significant one):
     38  *
     39  *   bit 0:    if 1, then compression stream 0 should be reset;
     40  *   bit 1:    if 1, then compression stream 1 should be reset;
     41  *   bit 2:    if 1, then compression stream 2 should be reset;
     42  *   bit 3:    if 1, then compression stream 3 should be reset;
     43  *   bits 7-4: if 1000 (0x08), then the compression type is "fill",
     44  *             if 1001 (0x09), then the compression type is "jpeg",
     45  *             if 1010 (0x0A), then the compression type is "png",
     46  *             if 0xxx, then the compression type is "basic",
     47  *             values greater than 1010 are not valid.
     48  *
     49  * If the compression type is "basic", then bits 6..4 of the
     50  * compression control byte (those xxx in 0xxx) specify the following:
     51  *
     52  *   bits 5-4:  decimal representation is the index of a particular zlib
     53  *              stream which should be used for decompressing the data;
     54  *   bit 6:     if 1, then a "filter id" byte is following this byte.
     55  *
     56  *-- The data that follows after the compression control byte described
     57  * above depends on the compression type ("fill", "jpeg", "png" or "basic").
     58  *
     59  *-- If the compression type is "fill", then the only pixel value follows, in
     60  * client pixel format (see NOTE 1). This value applies to all pixels of the
     61  * rectangle.
     62  *
     63  *-- If the compression type is "jpeg" or "png", the following data stream
     64  * looks like this:
     65  *
     66  *   1..3 bytes:  data size (N) in compact representation;
     67  *   N bytes:     JPEG or PNG image.
     68  *
     69  * Data size is compactly represented in one, two or three bytes, according
     70  * to the following scheme:
     71  *
     72  *  0xxxxxxx                    (for values 0..127)
     73  *  1xxxxxxx 0yyyyyyy           (for values 128..16383)
     74  *  1xxxxxxx 1yyyyyyy zzzzzzzz  (for values 16384..4194303)
     75  *
     76  * Here each character denotes one bit, xxxxxxx are the least significant 7
     77  * bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the
     78  * most significant 8 bits (bits 14-21). For example, decimal value 10000
     79  * should be represented as two bytes: binary 10010000 01001110, or
     80  * hexadecimal 90 4E.
     81  *
     82  *-- If the compression type is "basic" and bit 6 of the compression control
     83  * byte was set to 1, then the next (second) byte specifies "filter id" which
     84  * tells the decoder what filter type was used by the encoder to pre-process
     85  * pixel data before the compression. The "filter id" byte can be one of the
     86  * following:
     87  *
     88  *   0:  no filter ("copy" filter);
     89  *   1:  "palette" filter;
     90  *   2:  "gradient" filter.
     91  *
     92  *-- If bit 6 of the compression control byte is set to 0 (no "filter id"
     93  * byte), or if the filter id is 0, then raw pixel values in the client
     94  * format (see NOTE 1) will be compressed. See below details on the
     95  * compression.
     96  *
     97  *-- The "gradient" filter pre-processes pixel data with a simple algorithm
     98  * which converts each color component to a difference between a "predicted"
     99  * intensity and the actual intensity. Such a technique does not affect
    100  * uncompressed data size, but helps to compress photo-like images better.
    101  * Pseudo-code for converting intensities to differences is the following:
    102  *
    103  *   P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1];
    104  *   if (P[i,j] < 0) then P[i,j] := 0;
    105  *   if (P[i,j] > MAX) then P[i,j] := MAX;
    106  *   D[i,j] := V[i,j] - P[i,j];
    107  *
    108  * Here V[i,j] is the intensity of a color component for a pixel at
    109  * coordinates (i,j). MAX is the maximum value of intensity for a color
    110  * component.
    111  *
    112  *-- The "palette" filter converts true-color pixel data to indexed colors
    113  * and a palette which can consist of 2..256 colors. If the number of colors
    114  * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to
    115  * encode one pixel. 1-bit encoding is performed such way that the most
    116  * significant bits correspond to the leftmost pixels, and each raw of pixels
    117  * is aligned to the byte boundary. When "palette" filter is used, the
    118  * palette is sent before the pixel data. The palette begins with an unsigned
    119  * byte which value is the number of colors in the palette minus 1 (i.e. 1
    120  * means 2 colors, 255 means 256 colors in the palette). Then follows the
    121  * palette itself which consist of pixel values in client pixel format (see
    122  * NOTE 1).
    123  *
    124  *-- The pixel data is compressed using the zlib library. But if the data
    125  * size after applying the filter but before the compression is less then 12,
    126  * then the data is sent as is, uncompressed. Four separate zlib streams
    127  * (0..3) can be used and the decoder should read the actual stream id from
    128  * the compression control byte (see NOTE 2).
    129  *
    130  * If the compression is not used, then the pixel data is sent as is,
    131  * otherwise the data stream looks like this:
    132  *
    133  *   1..3 bytes:  data size (N) in compact representation;
    134  *   N bytes:     zlib-compressed data.
    135  *
    136  * Data size is compactly represented in one, two or three bytes, just like
    137  * in the "jpeg" compression method (see above).
    138  *
    139  *-- NOTE 1. If the color depth is 24, and all three color components are
    140  * 8-bit wide, then one pixel in Tight encoding is always represented by
    141  * three bytes, where the first byte is red component, the second byte is
    142  * green component, and the third byte is blue component of the pixel color
    143  * value. This applies to colors in palettes as well.
    144  *
    145  *-- NOTE 2. The decoder must reset compression streams' states before
    146  * decoding the rectangle, if some of bits 0,1,2,3 in the compression control
    147  * byte are set to 1. Note that the decoder must reset zlib streams even if
    148  * the compression type is "fill", "jpeg" or "png".
    149  *
    150  *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only
    151  * when bits-per-pixel value is either 16 or 32, not 8.
    152  *
    153  *-- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048
    154  * pixels. If a rectangle is wider, it must be split into several rectangles
    155  * and each one should be encoded separately.
    156  *
    157  */
    158 
    159 #define VNC_TIGHT_EXPLICIT_FILTER       0x04
    160 #define VNC_TIGHT_FILL                  0x08
    161 #define VNC_TIGHT_JPEG                  0x09
    162 #define VNC_TIGHT_PNG                   0x0A
    163 #define VNC_TIGHT_MAX_SUBENCODING       0x0A
    164 
    165 /* Filters to improve compression efficiency */
    166 #define VNC_TIGHT_FILTER_COPY             0x00
    167 #define VNC_TIGHT_FILTER_PALETTE          0x01
    168 #define VNC_TIGHT_FILTER_GRADIENT         0x02
    169 
    170 /* Note: The following constant should not be changed. */
    171 #define VNC_TIGHT_MIN_TO_COMPRESS 12
    172 
    173 /* The parameters below may be adjusted. */
    174 #define VNC_TIGHT_MIN_SPLIT_RECT_SIZE     4096
    175 #define VNC_TIGHT_MIN_SOLID_SUBRECT_SIZE  2048
    176 #define VNC_TIGHT_MAX_SPLIT_TILE_SIZE       16
    177 
    178 #define VNC_TIGHT_JPEG_MIN_RECT_SIZE      4096
    179 #define VNC_TIGHT_DETECT_SUBROW_WIDTH        7
    180 #define VNC_TIGHT_DETECT_MIN_WIDTH           8
    181 #define VNC_TIGHT_DETECT_MIN_HEIGHT          8
    182 
    183 #endif /* VNC_ENC_TIGHT_H */