Xpra supports a wide variety of picture and video encodings for sending window contents to the client quickly and efficiently. For background information on picture encodings, see images.guide.
Choosing an encoding is best left to the Xpra engine. It considers the window’s characteristics, network performance, user preferences, client and server capabilities, and available processing power.
If tuning is needed, use min-speed and min-quality before overriding the
encodings or encoding options. The xpra configure encodings tool is
designed to help with this; use it first and try other options only later.
These encodings control how Xpra selects and compresses screen updates.
Pseudo encodings control which actual encodings the engine may select:
auto — the default; allows all optionsgrayscale — allows all options without sending colours, which can save
bandwidthscroll — tries harder to send screen updates using motion vectors; see
the scroll encoding for the
semantics client implementations must honourSelect one with --encoding=ENC.
mmap — all bit depths; fastest; only available with local connections
and selected automaticallyrgb — all bit depths; very fast; raw RGB pixels, potentially compressed
with a stream compressor such as lz4webp — 24 / 32 bit; good; fast, with transparency and lossy or lossless
modesjpeg — 24 bit; fast and easy to supportavif — 24 bit; average; limited supportpng — 24 / 32 bit; slow and easy to supportpng/P — 8 bit; slow; useful for 8-bit desktop modepng/L — 8 bit; slow; greyscaleVideo streams are often the most efficient way to send large amounts of screen updates without consuming too much bandwidth. Xpra automatically detects when switching to a video codec makes sense.
vp8 — 24 bit; fast but less efficientvp9 — 24 / 30 bit; more efficient but somewhat slowerh264 — 24 / 30 bit; licensing issueshevc — 24 / 30 bit; licensing issues and usually slowerav1 supports 24-bit colour. It is the most efficient video encoding, but
does not provide a lossless mode.
Xpra ships these encoder modules. Availability and supported encodings can vary with the Xpra version, build options, and hardware capabilities.
vpx — vp8, vp9x264 — h264; fastnvenc — h264, hevc, av1; fastest, requires hardwareChoose which modules are loaded at runtime with video-encoders.
Some video encoders require a colorspace conversion step. These modules can:
Available modules include:
cython — r210, BGR48, GBRP10, YUV444P10; slow but useful for
high-bit-depth modeslibyuv — BGRX, YUV420P, NV12; fastestChoose loaded modules at runtime with csc-modules.
Xpra ships these decoder modules:
openh264 — h264vpx — vp8, vp9aom — av1Choose which modules are loaded at runtime with video-decoders.
Use these commands to see which encodings, codecs, and conversion modules are available in the current installation.
xpra encoding
On Windows and macOS, you can also use the Encodings_info wrapper.
xpra video
xpra attach --encoding=help
xpra seamless --encoding=help
xpra seamless -d damage,compress,encoding
Tuning is often misused and can make performance worse. Start with the automatic selection and minimum quality or speed settings before forcing a specific encoding.
Rather than selecting a lossless picture encoding, which may use too much bandwidth and cause performance issues:
min-quality and/or lower min-speedauto-refresh delay, while remembering that lossless
refreshes can be costlyValues range from 1 (lowest) to 100 (lossless). Rather than tuning quality,
use min-quality. Lower values save bandwidth and CPU but may make updates
more blurry.
Values range from 1 (lowest) to 100 (lossless). Rather than tuning speed, use
min-speed. Lower values use more CPU, reducing bandwidth consumption but
possibly lowering the framerate.
Use NVENC or another hardware encoder supported by libva when
available. Hardware encoders compress very well and do so extremely quickly.
When comparing performance, use the right metrics. Updates per second (fps)
are not always meaningful: many small regions can make a high or low count
misleading.