xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Version 40 and Version 41 of Encodings


Ignore:
Timestamp:
04/02/14 08:08:07 (7 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Encodings

    v40 v41  
    1111Xpra supports a number of picture encodings, provided you have the required libraries installed. Even then, the features of each encoding may vary based on the version of the libraries and other dependencies, both client and server side.
    1212[[BR]]
    13 Here is the list as of v0.10
     13Here is the list as of v0.13
    1414* lossless encodings:
    15  * rgb24 (compressed with zlib or lz4, just like [/wiki/PacketEncoding#Compression packet compression])
    16  * png (24/32-bit colour, 8-bit grayscale and 8-bit colour)
     15 * {{{rgb}}}: {{{rgb24}}} for regular windows, {{{rgb32}}} for transparency support (compressed with zlib or lz4, just like [/wiki/PacketEncoding#Compression packet compression])
     16 * {{{png}}} (24/32-bit colour), {{{png/L}}} (8-bit grayscale) and {{{png/P}}} (8-bit colour palette)
    1717 * [/wiki/Encodings/webp webp] (lossless mode)
    1818* lossy encodings:
    19  * jpeg
     19 * {{{jpeg}}}
    2020 * [/wiki/Encodings/webp webp] (lossy mode)
    2121 * [/wiki/Encodings/vpx vpx] (VP8 and VP9)
    2222 * h264: either using [/wiki/Encodings/x264 x264] or [/wiki/Encodings/nvenc nvenc]
     23 * {{{h265}}} using {{{x265}}} (not usable, far too slow)
    2324Note: for backwards compatibility, on versions older than 0.10.10 you have to specify the encoding as ''x264'' to get ''h264''. Newer versions use ''h264'', but ''x264'' will remain for command-line compatibility.
    2425}}}
     
    2829The best thing to do is to try them all and choose the one that provides the best results.
    2930Here are some rough guidelines:
    30 * on LANs with 100MBit/s or higher: rgb24 + zlib/lz4 should give you the best latency possible (whilst consuming quite a lot of bandwidth in the process..)
     31* on LANs with 100MBit/s or higher: {{{rgb}}} + zlib/lz4 should give you the best latency possible (whilst consuming quite a lot of bandwidth in the process..)
    3132* if you have the required hardware, use [/wiki/Encodings/nvenc NVENC]
    32 * to save a little bit of bandwidth at the expense of framerate and latency, use lossless encodings: png
    33 * otherwise, choose h264 and tune the speed/quality to suit your needs (see below)
     33* to save a little bit of bandwidth at the expense of framerate and latency, use lossless encodings: {{{png}}} or {{{webp}}}
     34* otherwise, choose {{{h264}}}} and tune the speed/quality to suit your needs (see below)
    3435The other encodings are somewhat less useful:
    35 * [/wiki/Encodings/vpx vpx] is similar to h264 but it does not support speed and quality tuning
    36 * jpeg gives lower size/quality than other lossy encodings, use this if the video encodings are not available and you need better compression than png can give you
    37 * [/wiki/Encodings/webp webp] (lossy mode) is a single image subset of vpx, and therefore lacks [http://en.wikipedia.org/wiki/Intra-frame intra-frame] compression - but latency is decent, though it is leaking memory at present and should therefore be avoided
     36* [/wiki/Encodings/vpx vpx : VP8] is similar to {{{h264}}} but it does not support all speed and quality tuning, it also subsamples colours which leads to visual degradation. {{{VP9}}} is so slow it is unusable.
     37* {{{jpeg}}} gives lower size/quality than other lossy encodings, use this if the video encodings are not available and you need better compression than {{{png}}} or {{{webp}}} can give you
     38* [/wiki/Encodings/webp webp] (lossy mode) is a single image subset of {{{vpx}}}, and therefore lacks [http://en.wikipedia.org/wiki/Intra-frame intra-frame] compression - but latency is decent
    3839}}}
    3940