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 20 and Version 21 of Encodings


Ignore:
Timestamp:
11/01/13 12:32:03 (7 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Encodings

    v20 v21  
    1515 * webp (lossy mode)
    1616 * vpx
    17  * x264
     17 * h264: either using [Encodings/x264] or [Encodings/nvenc]
     18Note: for backwards compatibility, you may have to specify the encoding as ''x264'' to get ''h264''.
    1819
    1920== Choosing an Encoding ==
     
    2223* on LANs with 100MBit/s or higher: rgb24 + zlib should give you the best latency possible (whilst consuming quite a lot of bandwidth in the process..)
    2324* to save a little bit of bandwidth at the expense of framerate and latency, use fast lossless encodings: webp or png
    24 * otherwise, choose x264 and tune the speed/quality to suit your needs (see below)
     25* otherwise, choose h264 and tune the speed/quality to suit your needs (see below)
    2526The other encodings are somewhat less useful:
    2627* vpx is similar to x264 but it does not support speed and quality tuning
    2728* 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
    2829* jpeg gives lower size/quality than other lossy encodings
    29 
    30 ----
    31 
    32 == x264 specifics ==
    33 (see [http://en.wikipedia.org/wiki/H.264 wikipedia H.264])
    34 x264 is the encoding that supports the most options and tunings.
    35 Quality/speed and minimum quality/speed can be set via the command line (and the latter can also be changed at runtime via the tray applet)
    36 Note that even when using the x264 encoding, some small screen updates may get sent as png or rgb24 to save time/bandwidth (not encoding a full frame).
    37 
    38 For more information on x264 options, see [http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264 H.264 encoding guide]
    39 
    40 === Profiles ===
    41 (see [http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles wikipedia h264 profiles])
    42 x264 supports the following profiles: {{{baseline}}}, {{{main}}}, {{{high}}}, {{{high10}}}, {{{high422}}} and {{{high444}}}.
    43 
    44 At present, we use {{{high}}} or better by default unless the client overrides it.
    45 
    46 
    47 === Quality Option ===
    48 What this does should be obvious (in x264 speak, this controls the {{{rc.f_rf_constant}}} parameter), but it is more complicated than you think:
    49 * we support 3 different colourspace modes: YUV420, YUV422 and YUV444 and this affects the quality of the picture too. (YUV420 is used for lowest quality settings). {{{YUV444}}} uses roughly twice as much bandwidth as {{{YUV420}}}. Switching from one mode to another is expensive, as we then need to send a new key frame and re-initialize both the encoder and the decoder - so the thresholds for going up to the next mode are not the same as the thresholds for going down to the next mode (prevents a yoyo effect).
    50 * not all modes are supported by all profiles, so we need to switch to a different profile to support {{{YUV422}}} ({{{high422}}} or {{{high444}}}) and {{{YUV444}}} ({{{high444}}} only).
    51 * some builds against older versions of libav/ffmpeg only support {{{YUV420}}},
    52  see [/browser/xpra/trunk/src/patches/x264-limited-csc.patch x264-limited-csc.patch]
    53 
    54 
    55 === Speed Option ===
    56 This option, shown as "latency" via the tray menu, controls how hard the encoder is going to work at compressing the picture. Working harder means lower bandwidth, but also higher latency.
    57 x264 supports the following speed settings: {{{ultrafast}}}, {{{superfast}}}, {{{veryfast}}}, {{{faster}}}, {{{fast}}}, {{{medium}}}, {{{slow}}}, {{{slower}}}, {{{veryslow}}} and {{{placebo}}}.
    58 xpra maps the 100% to 0% speed option from {{{ultrafast}}} to {{{slower}}} only.
    59 {{{veryslow}}} and {{{placebo}}} are not particularly useful (diminishing returns: much much slower and without sufficient savings for real-time use).
    60 {{{ultrafast}}} is only available when setting the encoder speed to 100% manually (via the command line or UI) - note that this setting has side-effects which prevents other settings from behaving as they should if the option is later changed.
    6130
    6231