ISO/IEC 21122-3:2022
(Main)Information technology — JPEG XS low-latency lightweight image coding system — Part 3: Transport and container formats
Information technology — JPEG XS low-latency lightweight image coding system — Part 3: Transport and container formats
This document defines transport and container formats for JPEG XS codestreams as specified in ISO/IEC 21122-1. It defines file formats for working with still image and motion image sequence files on computer platforms and gives guidance on how to embed the codestream in transport streams, allowing internet-based communication. This document uses already existing specifications for file formats and extends them for the embedding of JPEG XS codestreams.
Titre manque — Partie 3: Titre manque
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 21122-3
Second edition
2022-03
Information technology — JPEG XS
low-latency lightweight image coding
system —
Part 3:
Transport and container formats
Reference number
© ISO/IEC 2022
© ISO/IEC 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2022 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.3
4.1 Symbols . 3
4.2 Abbreviated terms . 3
4.3 Naming conventions for numerical values . 3
5 Conformance . 4
6 Colour specification .4
7 Organization of the document .4
Annex A (normative) Use of JPEG XS codestreams in still image file format - JXS .5
Annex B (normative) Use of JPEG XS codestreams in the ISOBMFF - Motion JPEG XS .33
Annex C (normative) Use of JPEG XS codestreams in the HEIF image file format.37
Annex D (normative) Use of JPEG XS codestreams outside of file formats . 44
Bibliography .46
iii
© ISO/IEC 2022 – All rights reserved
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
This second edition cancels and replaces the first edition (ISO/IEC 21122-3:2019), which has been
technically revised.
The main changes are as follows:
— corrigenda;
— signalling for support of 4:2:0 images.
A list of all parts in the ISO/IEC 21122 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
© ISO/IEC 2022 – All rights reserved
Introduction
This document is part of a series of standards for a low-latency lightweight image coding system,
denoted JPEG XS.
In many use cases during production or transmission of a movie, limiting the latency and the
recompression loss is a more important aspect than the compression efficiency. The JPEG XS coding
system offers compression and recompression of image sequences with very moderate computational
resources while remaining robust under multiple compression and decompression cycles and mixing
of content sources, e.g. embedding of subtitles, overlays or logos. Typical target compression ratios
ensuring visually lossless quality are in the range of 2:1 to 10:1, depending on the nature of the source
material. The end-to-end latency can be confined to a fraction of a frame, typically between a small
number of lines down to below a single line.
This document specifies transport and container formats for JPEG XS codestreams. It also defines
metadata that enriches transport protocols for transmission of image sequences, in order to facilitate
transport, editing and presentation.
v
© ISO/IEC 2022 – All rights reserved
INTERNATIONAL STANDARD ISO/IEC 21122-3:2022(E)
Information technology — JPEG XS low-latency lightweight
image coding system —
Part 3:
Transport and container formats
1 Scope
This document defines transport and container formats for JPEG XS codestreams as specified in
ISO/IEC 21122-1. It defines file formats for working with still image and motion image sequence files
on computer platforms and gives guidance on how to embed the codestream in transport streams,
allowing internet-based communication.
This document uses already existing specifications for file formats and extends them for the embedding
of JPEG XS codestreams.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 15076-1, Image technology colour management — Architecture, profile format and data structure —
Part 1: Based on ICC.1: 2010
ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
ISO/IEC 11578, Information technology — Open Systems Interconnection — Remote Procedure Call (RPC)
ISO/IEC 14496-12, Coding of audio-visual objects — Part 12: ISO base media file format
ISO/IEC 21122-1, JPEG XS low-latency lightweight image coding system — Part 1: Core coding system
ISO/IEC 21122-2, JPEG XS low-latency lightweight image coding system — Part 2: Profiles and buffer
models
ISO/IEC 23008-12:2017, Information technology — High efficiency coding and media delivery in
heterogeneous environments — Part 12: Image File Format
ISO/CIE 11664-1, Colorimetry — Part 1: CIE standard colorimetric observers
Rec. ITU-T H.273 | ISO/IEC 23091-2, Coding-independent code points — Part 2: Video
ANSI/CTA 861-G:2016, A DTV Profile for Uncompressed High Speed Digital Interfaces
W3C Recommendation, Extensible Markup Language (XML) 1.0 (Fifth Edition), 26 Nov. 2008 (https://
www .w3 .org/ TR/ REC -xml/ )
3 Terms and definitions
For the purposes of this document the terms and definitions given in ISO/IEC 14496-12, ISO/IEC 21122-1,
ISO/IEC 21122-2, ISO/IEC 23008-12 and the following apply.
© ISO/IEC 2022 – All rights reserved
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
aux
auxiliary component channel typically used as opacity channel or alpha mask
3.2
big-endian
byte ordering from the most significant to the least significant byte of multi-byte value representations
3.3
box
structured collection of data describing the image or the image decoding process
3.4
box content
data wrapped within the box (3.3) structure
3.5
box type
kind of information stored with the box (3.3)
3.6
byte
group of 8 bits
3.7
coding-independent code point
code point based on enumerated values for the definition of the colourspaces
Note 1 to entry: Code points defined in Rec. ITU-T H.273 | ISO/IEC 23091-2.
3.8
high efficiency image file format
image file format which can embed still images and motion sequences (3.11)
Note 1 to entry: Based on ISO/IEC 23008-12.
3.9
image collection
unordered set of images without an implied or signalled presentation order or presentation time stamps
3.10
JXS
still image file format with JPEG XS compressed images
3.11
motion sequence
movie
timed sequence (3.15) of images
3.12
sample
single element in the two-dimensional image array which comprises a component
Note 1 to entry: This definition is used in Annex A.
[SOURCE: ISO/IEC 21122-1:2022, 3.1.45 modified – the domain and Note 1 to entry have been added.]
© ISO/IEC 2022 – All rights reserved
3.13
sample
all the data associated with a single time
Note 1 to entry: This definition is used in Annexes B and C as data associated with one coded image in a sequence.
3.14
superbox
box (3.3) that carries other boxes as payload data
3.15
timed sequence
linearly ordered sequence of media entities such as images where each entity is presented at a well
defined time stamp
4 Symbols and abbreviated terms
4.1 Symbols
N number of components in an image as defined in ISO/IEC 21122-1
c
Plev level a particular codestream conforms to as defined in ISO/IEC 21122-2
Ppih profile a particular codestream conforms to as defined in ISO/IEC 21122-2
Picture()
JPEG XS codestream as defined in ISO/IEC 21122-1
Codestream_Header()
codestream header preceding the image data in the codestream as defined
in A.5.5
Codestream_Body()
coded image data in the codestream without Codestream_Header() as
defined in A.5.5
4.2 Abbreviated terms
For the purposes of this document the abbreviated terms given in ISO/IEC 14496-12, ISO/IEC 21122-1,
ISO/IEC 21122-2, ISO/IEC 23008-12 and the following apply.
CICP coding-independent code points
CIE Commision Internationale de l’Eclairage
HEIF high efficiency image file format
ISOBMFF iso base media file format
LSB least significant bit
MSB most significant bit
UTF-8 8-bit Unicode transformation format as defined in ISO/IEC 10646
4.3 Naming conventions for numerical values
Integer numbers are expressed as bit patterns, hexadecimal values, or decimal numbers. Bit patterns
and hexadecimal values have both a numerical value and an associated particular length in bits.
Hexadecimal notation, indicated by prefixing the hexadecimal number by "0x", may be used instead
of binary notation to denote a bit pattern having a length that is an integer multiple of 4. For example,
© ISO/IEC 2022 – All rights reserved
0x41 represents an eight-bit pattern having only its second most significant bit and its least significant
bit equal to 1. Numerical values that are specified under a "Code" heading in tables that are referred to
as "code tables" are bit pattern values (specified as a string of digits equal to 0 or 1 in which the left-
most bit is considered the most-significant bit). Other numerical values not prefixed by "0x" are decimal
values. When used in expressions, a hexadecimal value is interpreted as having a value equal to the
value of the corresponding bit pattern evaluated as a binary representation of an unsigned integer (i.e.,
as the value of the number formed by prefixing the bit pattern with a sign bit equal to 0 and interpreting
the result as a two's complement representation of an integer value). For example, the hexadecimal
value 0xF is equivalent to the 4-bit pattern '1111' and is interpreted in expressions as being equal to the
decimal number 15.
5 Conformance
This document shares common definitions for the structure of files (a sequence of objects, called boxes
here, and atoms in other similar file formats), and a common definition of the general structure of an
object (the size and type).
File formats representing either images, or image sequences shall be as specified in Annexes A, B and C.
All these specifications require that readers ignore objects that are unrecognizable to them.
This document takes precedence over those on which it is based, in any case where there are differences
or conflicts; however, no such conflicts are known to exist.
For better readability and understanding, the syntax description for the different file formats is done in
the same way as in the base formats.
6 Colour specification
JPEG XS (as defined in ISO/IEC 21122-1) describes only the encoded bitstream of an image. The
integrated multiple component transformation is only responsible for a decorrelation of the different
colour components allowing for the reduction of the entropy in the data. In order to properly display
or interpret the image, it is essential that the colourspace of that image data is properly characterized.
For this purpose, the respective container format or transport channel has to signal the correct
colourspace. The defined formats in this document for JPEG XS signals the colour space as specified in
Rec. ITU-T H.273 | ISO/IEC 23091-2.
7 Organization of the document
Annex A specifies the JXS file format for still images. It is based on the box-based format defined in the
JPEG 2000 family of standards, for example JPEG 2000 (Rec. ITU-T T. 800 | ISO/IEC 15444-1). The boxes
carry additional information supporting the use of the codestream as still image file format.
Annex B specifies the integration of JPEG XS codestreams in the ISOBMFF (as defined in
ISO/IEC 14496-12) for use of image sequences as movie in a file format.
Annex C specifies the integration of JPEG XS codestreams in the HEIF file format (as defined in
ISO/IEC 23008-12) allowing the integration of both still images as well as movies in one format.
Annex D specifies the Media Type registration for JPEG XS codestreams solely any file format container,
i.e. not contained within the file formats specified by Annex A, Annex B or Annex C.
© ISO/IEC 2022 – All rights reserved
Annex A
(normative)
Use of JPEG XS codestreams in still image file format - JXS
A.1 General
This annex defines a still image file format that applications may choose to wrap a codestream based on
a JPEG XS compressed image. While not all applications will use this format, many applications will find
that it meets their needs. However, those applications that do implement this file format shall implement
it as described in this entire annex. This specification is based on the same syntax as the box-based file
format for JPEG 2000 in ISO/IEC 15444-1:2016, Annex I or ISO/IEC 15444-2:2004, Annex M.
This annex:
— specifies a binary container (file) for both image and metadata;
— specifies a mechanism to indicate image properties, such as the tonescale or colourspace of the
image;
— specifies a mechanism by which readers can recognize the existence of intellectual property rights
information in the file;
— specifies a mechanism by which metadata (including vendor-specific information) can be included
in files specified by this document.
A.2 Specification of the JXS file format
A.2.1 General
The JXS file format provides a foundation for storing application specific data (metadata) in association
with a JPEG XS codestream, such as information which is required to display the image. As many
applications require a similar set of information to be associated with the compressed image data, it is
useful to define the format of that set of data along with the definition of the compression technology
and codestream syntax.
Conceptually, the JXS file format encapsulates the JPEG XS codestream along with other core pieces
of information about that codestream. The building-block of the JXS file format is called a box. All
information contained within the JXS file is encapsulated in boxes. This document defines several types
of boxes; the definition of each specific box type defines the kinds of information that can be found
within a box of that type. Some boxes will be defined to contain other boxes.
A.2.2 File identification
JXS files can be identified using several mechanisms. When stored in traditional computer file systems,
JXS files should be given the file extension ".jxs" (readers should allow mixed case for the alphabetic
characters). Another possibility is to identify the file by the Signature box (A.5.1) and the File Type box
(A.5.2).
A.2.3 File organization
A JXS file represents a collection of boxes. Some of those boxes are independent, and some contain other
boxes, so called superboxes. The binary structure of a file is a contiguous sequence of boxes. The start
© ISO/IEC 2022 – All rights reserved
of the first box shall be the first byte of the file, and the last byte of the last box shall be the last byte of
the file.
The binary structure of a box is identical to ISO/IEC 15444-1:2016 and defined in A.3.
Logically, the structure of a JXS file is as shown in Figure A.1. Boxes with dashed borders are optional in
conforming JXS files. However, an optional box may define mandatory boxes within that optional box.
In that case, if the optional box exists, those mandatory boxes within the optional box shall exist. If the
optional box is not present, then the mandatory boxes within those boxes shall also not be present.
Figure A.1 — Conceptual structure of a JXS file
Figure A.1 specifies only the containment relationship between the boxes in the file. The JPEG XS
Signature box shall be the first box in a JXS file, the File Type box shall immediately follow the JPEG XS
Signature box and the JPEG XS Header box shall fall before the Contiguous Codestream box. For other
boxes, a particular order of those boxes in the file is not generally implied.
The file shown in Figure A.1 is a strict sequence of boxes. Other boxes may be found between the boxes
defined in this document. However, all information contained within a JXS file shall be in the box format;
byte-streams not contained in the box format shall not be found in the file.
© ISO/IEC 2022 – All rights reserved
As shown in Figure A.1, a JXS file contains a JPEG XS Signature box, JPEG XS Header box, and one or
more Contiguous Codestream boxes. A JXS file may also contain other boxes as determined by the
file writer. For example, a JXS file may contain several XML boxes (containing metadata) between the
JPEG XS Header box and the first Contiguous Codestream box.
A.2.4 Greyscale, colour, multi-component specification
One of the most important aspects of a file format is that it specifies the colourspace of the contained
image data. In order to properly display or interpret the image data, it is essential that the colourspace of
that image is properly characterized. The JXS file format provides one method to specify the colourspace
of the image based on coding-independent code points (CICP). The CICP enumerated method specifies
the colourspace of an image by the use of three numeric values that identifies the colourspace. The set
of supported colourspaces is specified in A.5.4.3. The allowed values are a subset of the code points
defined in Rec. ITU-T H.273 | ISO/IEC 23091-2.
A.2.5 Inclusion of auxilliary channels
In many applications, components other than the colour channels are required (auxilliary channels).
For example, many images used on web pages contain opacity information; the browser uses this
information to blend the image into the background. Another example is the use of alpha channels in
video production; video mixers use this alpha channel to mix multiple images. It is thus desirable to
include both the colour and auxiliary channels within a single codestream.
The JXS file format provides a means to indicate the presence of auxiliary channels (such as opacity), to
define the type of these channels, and to specify the ordering and source of these. When a reader opens
the JXS file, it determines the ordering and type of each component. The application shall then match
the component definition and ordering from the JXS file with the component ordering as defined by
the colourspace specification. Once the file components have been mapped to the colour channels, the
decompressed image can be processed through any needed colourspace transformations.
How applications respond to opacity or other auxiliary channels is outside the scope of this document.
A.2.6 Metadata
One important aspect of the JXS file format is the ability to add metadata to a JXS file.
Some of the boxes provide a set of tools by which applications can add vendor-specific information to
the JXS file format, like the Exif box or the XML box. These boxes are optional in conforming files and
may be ignored by conforming readers.
A.2.7 Conformance with the file format
All conforming files shall contain all boxes required by this document, and those boxes shall be as
defined in this document. Also, all conforming readers shall correctly interpret all required boxes
defined in this document and thus shall correctly interpret all conforming files.
Because all information is encapsulated in boxes, and all boxes have types, the format provides a
simple mechanism for a reader to extract relevant information, while ignoring any box that contains
information that is not understood by that particular reader. In this way, new boxes can be created,
through this or other International Standards. Also, any new box added to a JXS file shall not change the
visual appearance of the image.
Defining boxes for private implementation purposes is discouraged. Instead, implementation-specific
metadata should be carried by UUID boxes as specified in A.5.8.
© ISO/IEC 2022 – All rights reserved
A.3 Concept of boxes
A.3.1 Key to graphical descriptions
Each box is described in terms of its function, usage and length. The function describes the information
contained in the box. The usage describes the logical location and frequency of this box in the file. The
length describes which parameters determine the length of the box.
These descriptions are followed by a figure that shows the order and relationship of the parameters in
the box. Figure A.2 shows an example of this type of figure. A rectangle is used to indicate the parameters
in the box. The width of the rectangle is proportional to the number of bytes in the parameter. A shaded
rectangle (diagonal stripes) indicates that the parameter is of varying size. Two parameters with
superscripts and a grey area between them indicate a run of several of these parameters. A sequence
of two groups of multiple parameters with superscripts separated by a grey area indicates a run of that
group of parameters (one set of each parameter in the group, followed by the next set of each parameter
in the group). Optional parameters or boxes are shown with a dashed rectangle.
Figure A.2 — Example of the box description figures
The figure is followed by a list that describes the meaning of each parameter in the box. If parameters
are repeated, the length and nature of the run of parameters is defined. As an example, in Figure A.2,
0 N–1
parameters C, D, E and F are 8-, 16-, 32-bit and variable lengths, respectively. The notation G and G
i 0 M–1
implies that there are N different parameters, G , in a row. The group of parameters H and H , and
0 M–1 0 0 1 1 M–1
J and J specify that the box will contain H , followed by J , followed by H and J , continuing to H
M–1
and J (M instances of each parameter in total). Also, the field L is optional and may not be found in
this box.
After the list is a table that either describes the allowed parameter values or provides references to
other tables that describe these values.
Some boxes may carry other boxes as payload data. Such boxes are denoted as superboxes. The payload
size of a superbox is given by the sum of the box lengths of all the boxes it contains.
In addition, in a figure describing the contents of a superbox, an ellipsis (…) is used to indicate that the
contents of the file between two boxes are not specifically defined. Any box (or sequence of boxes),
unless otherwise specified by the definition of that box, may be found in place of the ellipsis.
For example, the superbox shown in Figure A.3 shall contain an AA box and a BB box, and the BB box
shall follow the AA box. However, there may be other boxes found between boxes AA and BB. Dealing
with unknown boxes is discussed in A.6.
Figure A.3 — Example of the superbox description figures
© ISO/IEC 2022 – All rights reserved
A.3.2 Box definition
Physically, each object in the file is encapsulated within a binary structure called a box. That binary
structure is as in Figure A.4, and detailed in Table A.1.
Figure A.4 — Organization of a box
LBox Box length. This field specifies the length of the box, stored as a 32-bit big-endian unsigned
integer. This value includes all of the fields of the box, including the length and type. If the
value of this field is 1, then the XLBox field shall exist and the value of that field shall be
the actual length of the box. If the value of this field is 0, then the length of the box was not
known when the LBox field was written. In this case, this box contains all bytes up to the
end of the file. If a box of length 0 is contained within another box (its superbox), then the
length of that superbox shall also be 0. This means that this box is the last box in the file.
The values 2-7 are reserved for ISO/IEC use.
TBox Box type. This field specifies the type of information found in the DBox field. The value of
this field is encoded as a 32-bit big-endian unsigned integer. However, boxes are generally
referred to by an ISO/IEC 646 character string translation of the integer value. For all box
types defined within this document, box types are indicated as both character string (nor-
mative) and as 4-byte hexadecimal integers (informative). Also, a space character is shown
in the character string translation of the box type as “\040”. All values of TBox not defined
within this documentare are reserved for ISO/IEC use.
XLBox Box extended length. This field specifies the actual length of the box if the value of the
LBox field is 1. This field is stored as an 64-bit big-endian unsigned integer. The value in-
cludes all of the fields of the box, including the LBox, TBox and XLBox fields.
DBox Box contents. This field contains the actual information contained within this box. The for-
mat of the box contents depends on the box type and is defined individually for each type.
Table A.1 — Binary structure of a box
Field name Size (bits) Value
0, 1, or
LBox 32
8 to (2 – 1)
TBox 32 Variable
64 16 to (2 – 1); if LBox = 1
XLBox
0 Not applicable; if LBox ≠ 1
DBox Variable Variable
For example, consider the illustration in Figure A.5 of a sequence of boxes, including one box that
contains other boxes:
© ISO/IEC 2022 – All rights reserved
Figure A.5 — Illustration of box lengths
As shown in Figure A.5, the length of each box includes any boxes contained within that box. For
example, the length of Box 1 includes the length of Boxes 2 and 3, in addition to the LBox and TBox fields
for Box 1 itself. In this case, if the type of Box 1 was not understood by a reader, it would not recognize
the existence of Boxes 2 and 3 because they would be completely skipped by jumping the length of Box
1 from the beginning of Box 1.
A.4 Overview of defined boxes
Table A.2 lists all boxes defined by this document. Indentation within the table indicates the hierarchical
containment structure of the boxes within a JXS file.
The following boxes shall properly be interpreted by all conforming readers. Each of these boxes
conforms to the standard box structure as defined in A.3. The following clauses define the value of the
DBox field from Table A.1 (the contents of the box). It is assumed that the LBox, TBox and XLBox fields
exist for each box in the file as defined in A.3.
Table A.2 — Defined boxes
Box name Type Superbox Required? Comments
This box uniquely identifies the file
JPEG XS Signature box 'JXS\040'
No Required as being part of the JPEG XS family of
(A.5.1) (0x4A58 5320)
files.
This box specifies file type, version
and compatibility information, in-
File Type box 'ftyp'
No Required cluding specifying if this file is a con-
(A.5.2) (0x6674 7970)
forming JXS file or if it can be read by
a conforming JXS reader.
'jpvs' This box supports video information
JPEG XS Video Support
Yes Optional
for JPEG XS codestreams.
box (A.5.3)
(0x6A70 7673)
'jpvi' This box describes video informa-
JPEG XS Video
No Required
tion.
Information box
(0x6A70 7669)
'jxpl' This box specifies the used profile
JPEG XS Profile and
No Required
and level.
Level box
(0x6A78 706c)
'bmdm' This box defines buffer model
Buffer Model
No Optional
parameters.
Description box
(0x626D 646D)
'dmon' This box describes the display char-
Mastering Display
No Optional
acteristics of the mastering display.
Metadata box
(0x646D 6f6E)
JPEG XS Video This box describes parameters for
'jptp'
Transport No Optional packet-based video stream trans-
(0x6A70 7470)
Parameter box port.
© ISO/IEC 2022 – All rights reserved
Table A.2 (continued)
Box name Type Superbox Required? Comments
This box contains a series of boxes
JPEG XS Header box 'jp2h'
Yes Required that contain header-type information
(A.5.4) (0x6A70 3268)
about the file.
This box specifies aspects of the
'ihdr'
Image Header box No Required image geometry, number of
(0x6968 6472)
components and bit depth.
'colr' This box specifies the colourspace of
Colour Specification
No Required
the image.
box
(0x636F 6C72)
This box specifies the type and or-
'cdef'
Channel Definition
No Optional dering of the components within the
box
(0x6364 6566)
codestream.
'Exif' This box specifies data as defined in
Exif box No Optional
Annex A.5.4.5.
(0x4578 6966)
Contiguous Codestream This box contains the codestream as
'jp2c'
box defined by ISO/IEC 21122-1.
No Required
(0x6A70 3263)
(A.5.5)
Intellectual Property box 'jp2i' This box contains intellectual prop-
No Optional
erty information about the image.
(A.5.6) (0x6A70 3269)
This box provides a tool by which
XML box 'xml\040'
No Optional vendors can add XML formatted
(A.5.7) (0x786D 6C20)
information to a JXS file.
This box provides a tool by which
UUID box 'uuid'
vendors can add additional informa-
No Optional
tion to a file without risking conflict
(A.5.8) (0x7575 6964)
with other vendors.
This box provides a tool by which a
UUID Info box 'uinf'
vendor can provide access to addi-
Yes Optional
tional information associated with a
(A.5.9) (0x7569 6E66)
UUID.
'ulst' This box specifies a list of UUIDs.
UUID List box No Optional
(0x756C 7374)
'url\040' This box specifies a URL.
URL box No Optional
(0x7572 6C20)
NOTE 1 Indented box names indicate that the corresponding boxes are contained within the non-indented
superbox preceding it.
A conforming JXS file may contain boxes not known to applications based solely on this document. If a
conforming reader finds a box that it does not understand, it shall skip and ignore that box.
A.5 Defined boxes
A.5.1 JPEG XS Signature box
The JPEG XS Signature box identifies that the format of this file is defined by the JPEG XS International
Standard, as well as providing a small amount of information which can help determine the validity of
the rest of the file. The JPEG XS Signature box shall be the first box in the file.
The type of the JPEG XS Signature box shall be 'JXS\040' (0x4A58 5320). The length of this box shall be
12 bytes. The contents of this box shall be the 4-byte character string '<0x87>' (0x0D0A
© ISO/IEC 2022 – All rights reserved
870A). For file verification purposes, this box can be considered a fixed-length 12-byte string which
shall have the value: 0x0000 000C 4A58 5320 0D0A 870A.
The combination of the particular type and contents for this box enable an application to detect a
common set of file transmission errors. The CR-LF sequence in the contents catches bad file transfers
that alter newline sequences. The final linefeed checks for the inverse of the CR-LF translation problem.
The third character of the box contents has its high-bit set to catch bad file transfers that clear bit 7.
A.5.2 File Type box
The File Type box specifies the International Standard which completely defines all of the contents
of this file, as well as a separate list of readers, defined by other Recommendations | International
Standards, with which this file is compatible, and thus the file can be properly interpreted within
the scope of that other standard. This box shall immediately follow the JPEG XS Signature box. This
differentiates the standard which completely describes the file from other standards that interpret a
subset of the file.
All files shall contain one and only one File Type box. The type of the File Type box shall be 'ftyp' (0x6674
7970). The contents of this box shall be as in Figure A.6 and Table A.4.
Figure A.6 — Organization of the contents of a File Type box
BR Brand. This field specifies the International Standard which completely defines this file.
This field is specified by a four-byte string of ISO/IEC 646 characters. The value of this
field is defined in Table A.3:
Table A.3 — Allowed Brand values
Value Meaning
'jxs\040'
Annex A
other values Reserved for other ISO/IEC uses
In addition, the Brand field shall be considered functionally equivalent to a major version
number. A major version change (if there ever is one), representing an incompatible change
in the JXS file format, shall define a different value for the Brand field.
If the value of the Brand field is not 'jxs\040', then a value of 'jxs\040' in the Compati-
bility list indicates that a JXS reader can interpret the file in the manner intended by the
creator of the file.
MinV Minor version. This parameter defines the minor version number of this JXS specification
for which the file conforms. The parameter is defined as a 32-bit big-endian unsigned
integer. The value of this field shall be zero. However, readers shall continue to parse and
interpret this file even if the value of this field is not zero.
© ISO/IEC 2022 – All rights reserved
i
CL Compatibility list. This field specifies a code representing this document, another stand-
ard, or a profile of another standard, to which the file conforms. This field shall be encoded
as a four-byte string of ISO/IEC 646 characters. A file that conforms to this document shall
have at least one CLi field in the File Type box, and shall contain the value 'jxs\040' in one
of the CLi fields in the File Type box, and all conforming readers shall properly interpret all
files with 'jxs\040' in one of the CLi fields.
Other values of the Compatibility list field are reserved for ISO/IEC use.
The number of CLi fields is determined by the length of this box.
Table A.4 — Format of the contents of the File Type box
Field name Size (bits) Value
BR 32 0 to (2 – 1)
MinV 32 0
i 32
CL 32 0 to (2 – 1)
A.5.3 JPEG XS Video Support box (superbox)
A.5.3.1 General
The JPEG XS Video Support box contains information relevant for using JPEG XS codestreams in a video,
such as video information (framerate, no. of fields, etc.), buffer model description data or mastering
display metadata. This box is an optional superbox. If the JPEG XS Video Support box is used in a JXS
file, at least the JPEG XS video information box and the JPEGXS Profile and Level box are mandatory.
For retransmitting of JPEG XS codestreams over Internet protocols or over SDI link channels, it is
recommended to store also the original buffer model description data used during the encoding.
The type of the JPEG XS Video Support box shall be 'jpvs' (0x6A70 7673).
This box contains several boxes. Other boxes may be defined in other standards and may be ignored
by conforming readers. Those boxes contained within the JPEG XS Video Support box that are defined
within this document are as in Figure A.7:
Figure A.7 — Organization of the contents of a JPEG XS Video Support box
jpvi JPEG XS Video Information box. This box specifies video specific data about frame rate,
field coding, time code and max. bit rate. This box shall be the first box in the JPEG XS
Video Support box.
jxpl JPEG XS Profile and Level box. This box stores information about the used JPEG XS profile
and level as described in ISO/IEC 21122-2. This box shall be the second box in the JPEG XS
Video Support box.
bmdm Buffer Model Description box (optional). This box specifies metadata about the buffer
model used during the encoding.
dmon Mastering Display Metadata box (optional). This box specifies information on the Master-
ing Display.
jptp JPEG XS Video Transport Parameter box (optional). This box specifies information how a
decoder should be best parametrized for packet-based video transport.
© ISO/IEC 2022 – All rights reserved
A.5.3.2 JPEG XS Video Information box
If the JPEG XS codestream is used as part of a video stream or recorded from a video stream, this box
specifies the characteristics of the video stream.
The type of the JPEG XS Video Information box shall be 'jpvi' (0x6A70 7669) and contents of the box
shall have the format as in Figure A.8 and Table A.5:
Figure A.8 — Organization of the contents of a JPEG XS Video Information box
Table A.5 — Format of the contents of the JPEG XS Video Information box
Field name Size (bits) Value
brat 32 1 to (2 – 1)
frat 32 Variable, four sub fields,
0 if frame rate unknown
schar 16 Variable, three sub fields
tcod 32 HHMMSSFF
brat The brat parameter specifies the maximum bit rate of the video stream. This parameter is
defined as a 32-bit big-endian unsigned integer which specifies a maximum instantaneous
bit rate that is not to be exceeded, expressed in Mbits per second for the video stream at
the specified frame rate. The maximum bit rate shall not exceed the bit rate specified for a
given profile and level.
frat The frat parameter specifies the frame rate in frames per second and is a 32-bit big endian
unsigned integer. The frame rate is expressed by a rational number of the form numerator/
denominator. If the frame rate is an integer, the denominator value shall be equal to 1. If
there are two video fields per frame, then the video field rate is twice the frame rate. If the
frame rate is unknown, the parameter is 0. The encoding of this parameter is specified in
Table A.6:
Table A.6 — Format of the frat parameter
Field position Size (bits) Field name
Bit 31 (MSB) –Bit 30 2 Interlace_Mode
Bit 29 –Bit 24 6 Framerate_Denominator
Bit 23 – Bit 16 8 Framerate_Reserved
Bit 15- Bit 0 (LSB) 16 Framerate_Numerator
Interlace_Mode:
Interlace_Mode code shall specify whether the original picture is progressive or interlaced (as well as
field order in the latter case). Values and their meanings are listed in Table A.7.
© ISO/IEC 2022 – All rights reserved
Table A.7 — Format of the contents of frat Interlace_Mode
Field value Meaning
0 Progressive frame (frame contains one full-height
picture)
1 Interlaced frame, first picture is top video field (top
field first)
2 Interlaced frame, first picture is bottom video field
(bottom field first)
3 Reserved
NOTE 1 The frat field does not change between the two fields of an interlaced frame. It specifies which of the
two fields comes first in the frame, and therefore is not an indicator of the field type itself.
Framerate_Denominator:
Framerate_Denominator code shall specify the denominator value for calculating the frame rate as
listed in Table A.8.
Table A.8 — Format of the contents of frat Framerate_Denominator
Field Value Meaning – denominator value
0 Reserved
1 denominator value is 1
2 denominator value is 1.001
3 – 63 Reserved
Framerate_Reserved:
Reserved for ISO/IEC, should be 0.
Framerate_Numerator:
Framerate_Numerator code shall specify directly the numerator value for calculating the frame rate.
NOTE 1 The NTSC frame rate 30/1.001 is correctly expressed as Framerate_Numerator field value 30 divi
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...