By Antonin Descampe, intoPIX
Let's have a little talk with our expert in compression technology, Antonin Descampe !
Antonin Descampe is co-founder of intoPIX and member of the JPEG committee since 2005. He will explain how the JPEG XS technology differs from other codecs & what are the advantages of JPEG XS compared to other existing codecs.
What is JPEG XS and how does it differ from JPEG 2000, Motion JPEG and various MPEG standards ?
The main difference between JPEG XS and existing codecs from JPEG, MPEG or other standardization Committees is that compression efficiency is not the main target. Whereas other codecs primarily focus on their compression efficiency, disregarding latency or complexity, JPEG XS addresses the following question: “How can we ultimately replace uncompressed video?”. The goal of JPEG XS is therefore to allow increasing resolutions, frame rates and number of streams, while safeguarding all advantages of an uncompressed stream, i.e. interoperability, visually lossless quality, multi-generation robustness, low power consumption, low latency in coding and decoding, ease of implementation, small size on chip (no additional DDR), and fast software running on general purpose CPU and GPU.
No other codec fulfills this set of strong requirements simultaneously. It can thus “compete” with uncompressed in every aspect and reduce bandwidth / video data significantly.
What sort of compression will be reasonable with JPEG XS and what are the compres-sion choices for a 8K video with JPEG XS ?
In a nutshell, we can say that the typical operating points for visually lossless quality with JPEG XS are around 10:1.
However, it is important to take resolution and content type into account when identifying a maximum compression ratio. For instance, natural content usually reaches higher compression ratios for a given quality level.
Moreover, “visually lossless quality” can also mean different quality levels. During its development, JPEG XS has been tested against the strictest quality assessment procedures (ISO/IEC 29170-2, “Eval-uation procedure for visually lossless coding”), seeking the threshold guaranteeing an “indistinguishable flickering” between original and compressed image - a measure often referred to as “visual transpar-ency”.
Based on our tests, including different kinds of content (screen content, Computer Generated Images (CGI) and natural imagery), we defined the following table. The lower compressed bitrate in the table defines use cases playing with natural content typically while the upper range defines more complex content or use cases requiring full visual transparency.
|Formats ||Compressed bitrates ||IP network & SDI mapping |
|HD 720p60 |
|70 - 195 Mbps ||5 to 14 streams over 1GbE |
50 to 140 streams over 10 GbE
|HD 1080p60 ||150 - 390 Mbps ||2 to 6 streams over 1GbE |
25 to 66 streams over 10 GbE
|4K 2160p30 ||250 Mbps - 750 Mbps ||1 to 4 streams over 1 GbE |
3 to 10 streams over 2.5 GbE
13 to 40 streams over 10 GbE
|4K 2160p60 ||500 Mbps - 1,4 Gbps ||1 to 2 streams over 1 GbE |
1 to 5 streams over 2.5 GbE
7 to 20 streams over 10 GbE
Single 3G-SDI / single HD-SDI
|8K 4320p60 ||2 Gbps - 5,6 Gbps ||1 stream over 2.5 GbE |
1 to 5 streams over 10 GbE
Single 3G-SDI / single 6G-SDI / single 12G-SDI
|8K 4320p120 ||4 Gbps - 12,8 Gbps ||1 to 2 streams over 10 GbE single 6G-SDI / single 12G-SDI |
JPEG XS is specifically targeted at high-end video applications, such has broadcasting, broadcast contribution, virtual reality applications, etc. Why JPEG XS and not H.264 or H.265?
Video applications like broadcasting, broadcast contribution, virtual reality applications, … require features that MPEG-4 AVC / H.264 or HEVC / H.265 do not offer.
JPEG XS has a much lower complexity than any inter-frame codec like the MPEG ones. It leads to much cheaper implementation, a tiny FPGA footprint and there is no need to store frames in an additional DDR. It also has a more balanced complexity between encoder and decoder, making it more suitable for environments where you have the same number of encoders and decoders. MPEG-4 AVC / H.264 encoders are much more complex than the decoder.
There is also a huge difference in terms of power consumption. MPEG-4 AVC / H.264 and HEVC / H.265 require a lot of memory due to their inter-frame / GOP-based scheme. Thus, they would never be used for reducing power consumption / interfaces within an electronic device, as they are highly complex and use lots of power by themselves already. JPEG XS does not require such memory since it’s a line-based compression technology.
In terms of latency, using MPEG-4 AVC / H.264 and HEVC / H.265 in a live production workflow with multiple encoding & decoding steps would lead to a compiled latency of many seconds. JPEG XS has a microsecond-latency and can thus be run throughout a whole live production workflow without even inducing the latency of a single MPEG-4 AVC / H.264 encoding-decoding step. Even though we need H.265 for the last mile to distribute it to the consumers, we try to avoid any additional latency in the production workflow before distribution. Aside broadcast, applications that JPEG XS targets need (near) real-time transmission, such as autonomous driving systems, KVM extension, VR/AR gear, … A delay of > 100 milliseconds would make these applications unusable (or in case of an autonomous car even lead to a crash). JPEG XS stays well below this measure at < 1 millisecond for combined encoding and decoding.
In fact, JPEG XS not only targets high-end video applications, but is suitable anywhere where uncom-pressed video is currently used and needs to maintain high quality levels, while wanting to gain efficiency - and who wouldn’t want that? Hence, there is also a great focus on consumer electronics such as mobile devices, cars, TVs and other screens, etc.
What is the status of the JPEG XS standardization process ?
Concerning the status of the standardization process itself, JPEG XS consists of 5 parts which all have published first editions.
While Part-1 (Core coding system) relates to the actual compression algorithm, Part-2 (Profiles and buffer models) defines several profiles that can be seen as operating points suited for particular appli-cations or content type. In Part-3 (Transport and container formats) and in other standardization activi-ties, various file formats and transport formats are specified, allowing to store or stream one or several JPEG XS code streams (see table hereunder). Part-4 (Conformance testing) and Part-5 (Reference software) handle everything related to conformance testing and reference software to support and guide implementers with developing compliant JPEG XS products.
Since the publication of the first editions of the JPEG XS standards, the focus of the JPEG Committee went into further enhancing and improving XS to support new features and use cases. Most notably is the development of new coding tools dedicated to compression of Color Filter Array (CFA) data, mostly known as Bayer patterns. These new tools will make JPEG XS even more suited for use cases involving image sensor data compression, like the ones found in the automotive industry or in professional cam-eras.
And, in addition, new profiles are provided to support 4:2:0 chroma sampling and mathematically loss-less compression. Initially, these new developments were planned as amendments to Part-1 and Part-2, however this decision was changed in favor of going for a complete second edition of JPEG XS (all five parts).
Besides this process, there are several ongoing liaisons between standard bodies and industrial or-ganizations such as AIMS, VSF, SMPTE, TICO Alliance, IETF, etc. At the last IP Showcase at NAB there was a presentation about JPEG XS in ST2110-22. Several broadcast suppliers are already work-ing on implementation within their upcoming products.
|ITEMS ||DESCRIPTIONS ||CURRENT STATUS ||TARGET PUBLICATION DATES |
|ISO/IEC 21122-1 ||Part 1 : Core coding sys-tem ||Published ||1st edition published in 2019 |
2nd edition in Q4 2021
|ISO/IEC 21122-2 ||Part 2 : Profiles and buffer models ||Published ||1st edition published in 2019 |
2nd edition in Q1 2022
|ISO/IEC 21122-3 ||Part 3 : Transport and container formats ||Published ||1st edition published in 2019 |
2nd edition in Q4 2020
|ISO/IEC 21122-4 ||Part 4 : Conformance testing ||Published ||1st edition published in 2020 |
2nd edition in Q1 2022
|ISO/IEC 21122-5 ||Part 5 : Reference soft-ware ||Published ||1st edition published in 2020 |
2nd edition in Q1 2022
|ISO/IEC 21122-1:2019/AMD1 ||Part-1 Amendment 1: Ex-tended capabilities for JPEG XS ||Canceled in favor of 2nd edition ||N/A |
|ISO/IEC 21122-2:2019/AMD1 ||Part-2 Amendment 1: Profiles extensions ||Canceled in favor of 2nd edition ||N/A |
|IETF RFC JPEG -XS RTP ||JPEG -XS RTP payload ||Draft formally adopted by IETF payload WG ||Q4 2020 |
|SMPTE 2110-22 ||Compressed essence in ST 2110 ||Published ||Published |
|ISO/IEC 13818-1:2019/AMD1 ||MPEG-2 Transport Stream (TS) wrapper for JPEG XS ||Published ||Published |
|SMPTE ST 2124 ||MXF wrapper for JPEG XS ||Final draft under review ||Q3 2020 |
|VSF TR-07 ||Technical recommenda-tion on JPEG XS over MPEG-2 TS ||Final draft under review ||Q4 2021 |
|VSF TR-08 ||Technical recommenda-tion on JPEG XS over SMPTE ST 2110 ||Final draft under review ||QA 2021 |
*Dates updated in July 2021
We hope this will have given you a better understanding of the JPEG XS technology and its advantages against other codecs.
Please feel free to contact us if you want more information about the JPEG XS technology, we would be happy to talk about it with you !
For more details about JPEG-XS solutions see:
If you wish to download a copy of this white paper, click here