rfc9134xml2.original.xml   rfc9134.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.2629.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.3264.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3550.xml">
<!ENTITY RFC3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3551.xml">
<!ENTITY RFC3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3711.xml">
<!ENTITY RFC4175 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4175.xml">
<!ENTITY RFC4585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4585.xml">
<!ENTITY RFC4855 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4855.xml">
<!ENTITY RFC5124 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5124.xml">
<!ENTITY RFC6838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6838.xml">
<!ENTITY RFC7201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7201.xml">
<!ENTITY RFC7202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7202.xml">
<!ENTITY RFC8083 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8083.xml">
<!ENTITY RFC8085 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8085.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8866 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8866.xml">
<!ENTITY RFC8888 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8888.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-payload-rtp-jpegxs-18" ipr="trust200902"
>
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-payload-rtp- jpegxs-18" number="9134" ipr="trust200902" obsoletes="" updates="" submissionTyp e="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDept h="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="RTP Payload Format for JPEG XS"> <title abbrev="RTP Payload Format for JPEG XS">
RTP Payload Format for ISO/IEC 21122 (JPEG XS) RTP Payload Format for ISO/IEC 21122 (JPEG XS)
</title> </title>
<seriesInfo name="RFC" value="9134"/>
<author fullname="S&eacute;bastien Lugan" initials="S.L." <author fullname="Tim Bruylants" initials="T" surname="Bruylants">
surname="Lugan"> <organization abbrev="intoPIX">intoPIX S.A.</organization>
<organization abbrev="intoPIX">intoPIX S.A.</organization> <address>
<address> <postal>
<postal> <street>Rue Emile Francqui, 9</street>
<street>Rue Emile Francqui, 9</street> <city>Mont-Saint-Guibert</city>
<city>1435 Mont-Saint-Guibert</city> <code>1435</code>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<phone>+32 10 23 84 70</phone> <phone>+32 10 23 84 70</phone>
<email>rtp@intopix.com</email> <email>t.bruylants@intopix.com</email>
<uri>https://www.intopix.com/</uri> <uri>https://www.intopix.com/</uri>
</address> </address>
</author> </author>
<author fullname="Antonin Descampe" initials="A" surname="Descampe">
<author fullname="Antonin Descampe" initials="A.D." <organization abbrev="UCLouvain">Université catholique de Louvain</organiz
surname="Descampe"> ation>
<organization abbrev="UCL">Universit&eacute; catholique de Louvain</organiz <address>
ation> <postal>
<address> <extaddr>bte L2.03.02</extaddr>
<postal> <street>Ruelle de la Lanterne Magique, 14</street>
<street>Place du Levant, 3 - bte L5.03.02</street> <city>Louvain-la-Neuve</city>
<city>1348 Louvain-la-Neuve</city> <code>1348</code>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<phone>+32 10 47 25 97</phone> <phone>+32 10 47 27 87</phone>
<email>antonin.descampe@uclouvain.be</email> <email>antonin.descampe@uclouvain.be</email>
<uri>https://uclouvain.be/en/research-institutes/icteam</uri> <uri>https://uclouvain.be/antonin.descampe</uri>
</address> </address>
</author> </author>
<author fullname="Corentin Damman" initials="C" surname="Damman">
<author fullname="Corentin Damman" initials="C.D." <organization abbrev="intoPIX">intoPIX S.A.</organization>
surname="Damman"> <address>
<organization abbrev="intoPIX">intoPIX S.A.</organization> <postal>
<address> <street>Rue Emile Francqui, 9</street>
<postal> <city>Mont-Saint-Guibert</city>
<street>Rue Emile Francqui, 9</street> <code>1435</code>
<city>1435 Mont-Saint-Guibert</city> <country>Belgium</country>
<country>Belgium</country> </postal>
</postal> <phone>+32 10 23 84 70</phone>
<phone>+32 10 23 84 70</phone> <email>c.damman@intopix.com</email>
<email>c.damman@intopix.com</email> <uri>https://www.intopix.com/</uri>
<uri>https://www.intopix.com/</uri> </address>
</address> </author>
</author> <author fullname="Thomas Richter" initials="T" surname="Richter">
<organization abbrev="Fraunhofer IIS">Fraunhofer IIS</organization>
<author fullname="Thomas Richter" initials="T.R." <address>
surname="Richter"> <postal>
<organization abbrev="IIS">Fraunhofer IIS</organization> <street>Am Wolfsmantel 33</street>
<address> <city>Erlangen</city>
<postal> <code>91048</code>
<street>Am Wolfsmantel 33</street> <country>Germany</country>
<city>91048 Erlangen</city> </postal>
<country>Germany</country> <phone>+49 9131 776 5126</phone>
</postal> <email>thomas.richter@iis.fraunhofer.de</email>
<phone>+49 9131 776 5126</phone> <uri>https://www.iis.fraunhofer.de/</uri>
<email>thomas.richter@iis.fraunhofer.de</email> </address>
<uri>https://www.iis.fraunhofer.de/</uri> </author>
</address> <date year="2021" month="October" />
</author>
<author fullname="Tim Bruylants" initials="T.B."
surname="Bruylants">
<organization abbrev="intoPIX">intoPIX S.A.</organization>
<address>
<postal>
<street>Rue Emile Francqui, 9</street>
<city>1435 Mont-Saint-Guibert</city>
<country>Belgium</country>
</postal>
<phone>+32 10 23 84 70</phone>
<email>t.bruylants@intopix.com</email>
<uri>https://www.intopix.com/</uri>
</address>
</author>
<date year="2021" />
<!-- If the month and year are both specified and are the current ones, xml2r
fc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suff
icient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area> <area>General</area>
<workgroup>avtcore</workgroup>
<workgroup>avtcore</workgroup> <keyword>video</keyword>
<!-- <keyword>transport</keyword>
<workgroup>Internet Engineering Task Force</workgroup> <keyword>protocol</keyword>
<keyword>Joint</keyword>
<!-- WG name at the upperleft corner of the doc, <keyword>Photographic</keyword>
IETF is fine for individual submissions. <keyword>Experts</keyword>
If this element is not present, the default is "Network Working Group", <keyword>Group</keyword>
which is used by the RFC Editor as a nod to the history of the IETF. --> <keyword>real-time</keyword>
<keyword>stream</keyword>
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>
<t>
This document specifies a Real-Time Transport Protocol (RTP) payload This document specifies a Real-Time Transport Protocol (RTP) payload
format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. format to be used for transporting video encoded with JPEG XS (ISO/IEC 21 122).
JPEG XS is a low-latency, lightweight image coding system. Compared to an JPEG XS is a low-latency, lightweight image coding system. Compared to an
uncompressed video use case, it allows higher resolutions and video frame uncompressed video use case, it allows higher resolutions and video frame
rates, while offering visually lossless quality, reduced power rates while offering visually lossless quality, reduced power
consumption, and encoding-decoding latency confined to a fraction of a vi deo frame. consumption, and encoding-decoding latency confined to a fraction of a vi deo frame.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
This document specifies a payload format for packetization of This document specifies a payload format for packetization of video
<xref target="ISO21122-1">JPEG XS</xref> encoded video signals into the signals encoded with <xref target="ISO21122-1" format="default">JPEG
<xref target="RFC3550">Real-time Transport Protocol (RTP)</xref>. XS</xref> into the <xref target="RFC3550" format="default">Real-time
</t> Transport Protocol (RTP)</xref>.
<t> </t>
<t>
The JPEG XS coding system offers compression and recompression of image The JPEG XS coding system offers compression and recompression of image
sequences with very moderate computational resources while remaining sequences with very moderate computational resources while remaining
robust under multiple compression and decompression cycles and mixing of robust under multiple compression and decompression cycles as well as mix
content sources, e.g. embedding of subtitles, overlays or logos. Typical ing of
content sources, e.g., embedding of subtitles, overlays, or logos. Typica
l
target compression ratios ensuring visually lossless quality are in the 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 range of 2:1 to 10:1 depending on the nature of the source material. The
latency that is introduced by the encoding-decoding process can be confin ed latency that is introduced by the encoding-decoding process can be confin ed
to a fraction of a video frame, typically between a small number of lines to a fraction of a video frame, typically between a small number of lines
down to below a single line. down to below a single line.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions, Definitions, and Abbreviations"> <name>Conventions, Definitions, and Abbreviations</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and "OPTIONAL" in this document are to be interpreted as described NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119
"
format="default"/> <xref target="RFC8174" format="default"/> when,
and only when, they appear in all capitals, as shown here. and only when, they appear in all capitals, as shown here.
</t> </t>
<t>
<list style="hanging">
<t hangText="Application Data Unit (ADU)"><vspace />
The unit of source data provided as payload to the transport layer,
and corresponding, in this RTP payload definition, to a single
JPEG XS video frame.
</t>
<t hangText="Color specification box (CS box)"><vspace /> <dl newline="true" spacing="normal">
An ISO color specification box defined in <xref <dt>Application Data Unit (ADU):</dt>
target="ISO21122-3">JPEG XS Part 3</xref> that includes <dd>
color related metadata required to correctly display JPEG XS video fr The unit of source data provided as payload to the transport layer.
ames, In this RTP payload definition, it corresponds to a single JPEG
such as color primaries, transfer characteristics and matrix XS video frame.
</dd>
<dt>Color Specification (CS) box:</dt>
<dd>
An ISO color specification box defined in <xref target="ISO21122-3"
format="default"/> (JPEG XS Part 3) that includes color-related
metadata required to correctly display JPEG XS video frames, such
as color primaries, transfer characteristics, and matrix
coefficients. coefficients.
</t> </dd>
<dt>End of Codestream (EOC) marker:</dt>
<t hangText="EOC marker"><vspace /> <dd>
A marker that consists of the two bytes 0xff11 indicating the A marker that consists of the two bytes 0xff11 indicating the end of
end of a JPEG XS codestream. a JPEG XS codestream.
</t> </dd>
<dt>JPEG XS codestream:</dt>
<t hangText="JPEG XS codestream"><vspace /> <dd>
A sequence of bytes representing a compressed image formatted A sequence of bytes representing a compressed image formatted
according to <xref target="ISO21122-1">JPEG XS Part 1</xref>. according to <xref target="ISO21122-1" format="default"/> (JPEG XS Pa
</t> rt 1).
</dd>
<t hangText="JPEG XS codestream header"><vspace /> <dt>JPEG XS codestream header:</dt>
A sequence of bytes, starting with a SOC marker, at the beginning of <dd>
A sequence of bytes, starting with an SOC marker, at the beginning of
each JPEG XS codestream encoded in multiple markers and marker each JPEG XS codestream encoded in multiple markers and marker
segments that does not carry entropy coded data, but metadata such as segments that does not carry entropy coded data, but metadata such as
the video frame dimension and component precision. the video frame dimension and component precision.
</t> </dd>
<dt>JPEG XS frame:</dt>
<t hangText="JPEG XS frame"><vspace /> <dd>
In the case of progressive video, a single JPEG XS picture segment. I n In the case of progressive video, a single JPEG XS picture segment. I n
the case of interlaced video, the concatenation of two JPEG XS the case of interlaced video, the concatenation of two JPEG XS
picture segments. picture segments.
</t> </dd>
<dt>JPEG XS header segment:</dt>
<t hangText="JPEG XS header segment"><vspace /> <dd>
The concatenation of a <xref target="ISO21122-3">video support box</x The concatenation of a <xref target="ISO21122-3"
ref>, format="default">video support box</xref>, a <xref
a <xref target="ISO21122-3">color specification box</xref>, target="ISO21122-3" format="default">color specification
and a JPEG XS codestream header. box</xref>, and a JPEG XS codestream header.
</t> </dd>
<dt>JPEG XS picture segment:</dt>
<t hangText="JPEG XS picture segment"><vspace /> <dd>
The concatenation of a <xref target="ISO21122-3">video support box</x The concatenation of a <xref target="ISO21122-3"
ref>, format="default">video support box</xref>, a <xref
a <xref target="ISO21122-3">color specification box</xref>, target="ISO21122-3" format="default">color specification
and a JPEG XS codestream. box</xref>, and a JPEG XS codestream.
</t> </dd>
<dt>JPEG XS stream:</dt>
<t hangText="JPEG XS stream"><vspace /> <dd>
A sequence of JPEG XS frames. A sequence of JPEG XS frames.
</t> </dd>
<dt>Marker:</dt>
<t hangText="Marker"><vspace /> <dd>
A two-byte functional sequence that is part of a JPEG XS A two-byte functional sequence that is part of a JPEG XS
codestream starting with a 0xff byte and a subsequent byte codestream starting with a 0xff byte and a subsequent byte
defining its function. defining its function.
</t> </dd>
<dt>Marker segment:</dt>
<t hangText="Marker segment"><vspace /> <dd>
A marker along with a 16-bit marker size and payload data A marker along with a 16-bit marker size and payload data
following the size. following the size.
</t> </dd>
<dt>Packetization unit:</dt>
<t hangText="Packetization unit"><vspace /> <dd>
A portion of an Application Data Unit whose boundaries coincide A portion of an ADU whose boundaries coincide
with boundaries of RTP packet payloads (excluding payload header), with boundaries of RTP packet payloads (excluding payload header),
i.e. the first (resp. last) byte of a packetization unit is the i.e., the first (or respectively, last) byte of a packetization unit
first (resp. last) byte of an RTP packet payload (excluding its is the
first (or respectively, last) byte of an RTP packet payload (excludin
g its
payload header). payload header).
</t> </dd>
<dt>SLH (SLice Header) marker:</dt>
<t hangText="SLH marker"><vspace />
A marker that represents a slice header, as defined in <xref target="
ISO21122-1" />.
</t>
<t hangText="Slice"><vspace />
The smallest independently decodable unit of a JPEG XS
codestream, bearing in mind that it decodes to wavelet coefficients
which still require inverse wavelet filtering to give an image.
</t>
<t hangText="SOC marker"><vspace /> <dd>
A marker that represents a slice header, as defined in <xref
target="ISO21122-1" format="default"/>.
</dd>
<dt>Slice:</dt>
<dd>
The smallest independently decodable unit of a JPEG XS codestream,
bearing in mind that it decodes to wavelet coefficients, which
still require inverse wavelet filtering to give an image.
</dd>
<dt>Start of a Codestream (SOC) marker:</dt>
<dd>
A marker that consists of the two bytes 0xff10 indicating the A marker that consists of the two bytes 0xff10 indicating the
start of a JPEG XS codestream. The SOC marker is considered an start of a JPEG XS codestream. The SOC marker is considered an
integral part of the JPEG XS codestream header. integral part of the JPEG XS codestream header.
</t> </dd>
<dt>Video Support (VS) box:</dt>
<t hangText="Video support box (VS box)"><vspace /> <dd>
An ISO video support box, as defined in <xref target="ISO21122-3" />, An ISO video support box, as defined in <xref target="ISO21122-3" for
mat="default"/>,
that includes metadata required to play back a JPEG XS that includes metadata required to play back a JPEG XS
stream, such as its maximum bitrate, its subsampling structure, its stream; such metadata could include its maximum bit rate, its subsamp
buffer model and its frame rate. ling structure, its
</t> buffer model, and its frame rate.
</dd>
</list> </dl>
</t> </section>
</section> <section numbered="true" toc="default">
<name>Media Format Description</name>
<t>
This section explains the terminology and concepts used in this memo spec
ific to JPEG XS
as specified in <xref target="ISO21122-1" format="default"/>, <xref targe
t="ISO21122-2" format="default"/>, and <xref target="ISO21122-3" format="default
"/>.
</t>
<section numbered="true" toc="default">
<name>Image Data Structures</name>
<section title="Media Format Description">
<t>
This section explains the terminology and concepts used in this memo that
are specific to JPEG XS
as specified in <xref target="ISO21122-1" />, <xref target="ISO21122-2" /
>, and <xref target="ISO21122-3" />.
</t>
<section title="Image Data Structures">
<!-- FIXME -->
<t> <t>
JPEG XS is a low-latency lightweight image coding system for coding JPEG XS is a low-latency, lightweight image coding system for coding
continuous-tone grayscale or continuous-tone color digital images. continuous-tone grayscale or continuous-tone color digital images.
</t> </t>
<t> <t>
This coding system provides an efficient representation of image This coding system provides an efficient representation of image
signals through the mathematical tool of wavelet analysis. The wavelet signals through the mathematical tool of wavelet analysis. The wavelet
filter process separates each component into multiple bands, where filter process separates each component into multiple bands, where
each band consists of multiple coefficients describing the image each band consists of multiple coefficients describing the image
signal of a given component within a frequency domain specific to the signal of a given component within a frequency domain specific to the
wavelet filter type, i.e. the particular filter corresponding to the wavelet filter type, i.e., the particular filter corresponding to the
band. band.
</t> </t>
<t> <t>
Wavelet coefficients are grouped into precincts, where each precinct Wavelet coefficients are grouped into precincts, where each precinct
includes all coefficients over all bands that contribute to a spatial includes all coefficients over all bands that contribute to a spatial
region of the image. region of the image.
</t> </t>
<t> <t>
One or multiple precincts are furthermore combined into slices One or multiple precincts are furthermore combined into slices
consisting of an integer number of precincts. Precincts do not consisting of an integer number of precincts. Precincts do not
cross slice boundaries, and wavelet coefficients in precincts that cross slice boundaries, and wavelet coefficients in precincts that
are part of different slices can be decoded independently of each are part of different slices can be decoded independently of each
other. Note, however, that the wavelet transformation runs across other. However, note that the wavelet transformation runs across
slice boundaries. A slice always extends over the full width of the slice boundaries. A slice always extends over the full width of the
image, but may only cover parts of its height. image but may only cover parts of its height.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Codestream"> <name>Codestream</name>
<t> <t>
A JPEG XS codestream is formed by (in the given order): A JPEG XS codestream is formed by (in the given order):
<list style="symbols"> </t>
<t>a JPEG XS codestream header, which starts with an SOC marker,</t> <ul spacing="normal">
<t>one or more slices,</t> <li>a JPEG XS codestream header, which starts with a Start of Codestre
<t>an EOC marker to signal the end of the codestream.</t> am (SOC) marker,</li>
</list> <li>one or more slices,</li>
</t> <li>an EOC marker to signal the end of the codestream.</li>
<t> </ul>
<t>
The JPEG XS codestream format, including the definition of all The JPEG XS codestream format, including the definition of all
markers, is further defined in <xref target="ISO21122-1" />. markers, is further defined in <xref target="ISO21122-1" format="defaul t"/>.
It represents sample values of a single image, without any interpretati on It represents sample values of a single image, without any interpretati on
relative to a color space. relative to a color space.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Video support box and color specification box"> <name>Video Support Box and Color Specification Box</name>
<t> <t>
While the information defined in the codestream is sufficient to While the information defined in the codestream is sufficient to
reconstruct the sample values of one image, the interpretation of reconstruct the sample values of one image, the interpretation of
the samples remains undefined by the codestream itself. This the samples remains undefined by the codestream itself. This
interpretation is given by the video support box and the color interpretation is given by the video support box and the color
specification box which contain significant information to correctly specification box, which contain significant information to correctly
play the JPEG XS stream. The layout and syntax of these boxes, together play the JPEG XS stream. The layout and syntax of these boxes, together
with their content, are defined in <xref target="ISO21122-3" />. with their content, are defined in <xref target="ISO21122-3" format="de
</t> fault"/>.
<t> </t>
The video support box provides information on the maximum bitrate, <t>
the frame rate, the interlaced mode (progressive or interlaced), The video support box provides information on the maximum bit rate,
the subsampling image format, the informative timecode of the current the frame rate, the interlaced mode (progressive or interlaced), the
JPEG XS frame, the profile, level/sublevel used, and optionally on the subsampling image format, the informative timecode of the current
buffer model and the mastering display metadata. JPEG XS frame, the profile, the level/sublevel used, and optionally
</t> the buffer model and the mastering display metadata.
<t> </t>
Note that the profile and level/sublevel, specified by respectively the <t>
<xref target="ISO21122-2">Ppih and Plev fields</xref>, specify limits o Note that the profile and level/sublevel, specified respectively by
n the capabilities needed to decode the <xref target="ISO21122-2" format="default">Ppih and Plev
the codestream and handle the output. Profiles represent a limit on the fields</xref>, specify limits on the capabilities needed to decode
required algorithmic features and parameter ranges used in the codestre the codestream and handle the output. Profiles represent a limit on
am. the required algorithmic features and parameter ranges used in the
The combination of level and sublevel defines a lower bound on the requ codestream. The combination of level and sublevel defines a lower
ired bound on the required throughput for a decoder in the
throughput for a decoder in respectively the image (or decoded) domain image (or decoded) domain and the codestream (or coded) domain, respect
and ively. The
the codestream (or coded) domain. The actual defined profiles and level actual defined profiles and levels/sublevels, along with the
s/sublevels, associated values for the Ppih and Plev fields, are defined in <xref
along with the associated values for the Ppih and Plev fields, are defi target="ISO21122-2" format="default"/>.
ned </t>
in <xref target="ISO21122-2" />. <t>
</t>
<t>
The color specification box indicates the color primaries, transfer The color specification box indicates the color primaries, transfer
characteristics, matrix coefficients and video full range flag needed characteristics, matrix coefficients, and video full range flag needed
to specify the color space of the video stream. to specify the color space of the video stream.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="JPEG XS Frame"> <name>JPEG XS Frame</name>
<t> <t>
The concatenation of a video support box, a color specification box, The concatenation of a video support box, a color specification box,
and a JPEG XS codestream forms a JPEG XS picture segment. and a JPEG XS codestream forms a JPEG XS picture segment.
</t> </t>
<t> <t>
In the case of a progressive video stream, each JPEG XS frame co In the case of a progressive video stream, each JPEG XS frame consists
nsists of one single of one single
JPEG XS picture segment. JPEG XS picture segment.
</t> </t>
<t> <t>
In the case of an interlaced video stream, each JPEG XS frame is made o In the case of an interlaced video stream, each JPEG XS frame is made
f two of two concatenated JPEG XS picture segments. The codestream of each
concatenated JPEG XS picture segments. The codestream of each picture s picture segment corresponds exclusively to one of the two fields of
egment corresponds the interlaced frame. Both picture segments <bcp14>SHALL</bcp14>
exclusively to one of the two fields of the interlaced frame. Both pict contain identical boxes (i.e., the byte sequence that contains the
ure segments concatenation of the video support box and the color specification
SHALL contain identical boxes (i.e. concatenation of the video support box is exactly the same in both picture segments of the frame).
box and the </t>
color specification box is byte exact the same for both picture segment
s of the frame).
</t>
<t>
Note that the interlaced mode, as signaled by the <xref target="ISO2112
2-3">frat field</xref>
in the video support box, indicates either progressive, interlaced top-
field first, or
interlaced bottom-field first mode. Thus, in the case of interlaced con
tent, its value
SHALL also be identical in both picture segments.
</t>
</section>
</section>
<section title="RTP Payload Format"> <t>
<t> Note that the interlaced mode, as signaled by the <xref target="ISO2112
This section specifies the payload format for JPEG XS streams over 2-3" format="default">frat field</xref>
the <xref target="RFC3550">Real-time Transport Protocol (RTP)</xref>. in the video support box, indicates either progressive interlaced top-f
</t> ield-first or
<t> interlaced bottom-field-first mode. Thus, in the case of interlaced con
tent, its value
<bcp14>SHALL</bcp14> also be identical in both picture segments.
</t>
</section>
</section>
<section numbered="true" toc="default">
<name>RTP Payload Format</name>
<t>
This section specifies the payload format for JPEG XS streams over the
<xref target="RFC3550" format="default">Real-time Transport Protocol
(RTP)</xref>.
</t>
<t>
In order to be transported over RTP, each JPEG XS stream is In order to be transported over RTP, each JPEG XS stream is
transported in a distinct RTP stream, identified by a distinct <xref targ transported in a distinct RTP stream, identified by a distinct <xref targ
et="RFC3550">Synchronization source (SSRC)</xref>. et="RFC3550" format="default">synchronization source (SSRC)</xref>.
</t> </t>
<t> <t>
A JPEG XS stream is divided into Application Data Units (ADUs), each ADU A JPEG XS stream is divided into Application Data Units (ADUs), each ADU
corresponding to a single JPEG XS frame. corresponding to a single JPEG XS frame.
</t> </t>
<section anchor="rtp_packet" numbered="true" toc="default">
<name>RTP Packetization</name>
<section title="RTP packetization" anchor="rtp_packet"> <t>
<t>
An ADU is made of several packetization units. If a packetization unit An ADU is made of several packetization units. If a packetization unit
is bigger than the maximum size of an RTP packet payload, the unit is is bigger than the maximum size of an RTP packet payload, the unit is
split into multiple RTP packet payloads, as illustrated in <xref split into multiple RTP packet payloads, as illustrated in <xref
target="rtp_packetization" />. As seen there, each packet SHALL target="rtp_packetization" format="default"/>. As seen there, each
contain (part of) one and only one packetization unit. A packetization packet <bcp14>SHALL</bcp14> contain (part of) one, and only one,
unit may extend over multiple packets. The payload of every packet packetization unit. A packetization unit may extend over multiple
SHALL have the same size (based e.g. on the Maximum Transfer Unit of packets. The payload of every packet <bcp14>SHALL</bcp14> have the
the network), except (possibly) the last packet of a packetization same size (based, e.g., on the Maximum Transfer Unit of the network)
unit. The boundaries of a packetization unit SHALL coincide with the with the possible exception of the last packet of a packetization unit.
boundaries of the payload of a packet (excluding the payload header), The
i.e. the first (resp. last) byte of the packetization unit SHALL be boundaries of a packetization unit <bcp14>SHALL</bcp14> coincide with
the first (resp. last) byte of the payload (excluding its header). the boundaries of the payload of a packet (excluding the payload
</t> header), i.e., the first (or, respectively, last) byte of the
packetization unit <bcp14>SHALL</bcp14> be the first (or, respectively,
last) byte of the payload (excluding its header).
</t>
<figure anchor="rtp_packetization" title="Example of ADU packetization"> <figure anchor="rtp_packetization">
<artwork><![CDATA[ <name>Example of ADU Packetization</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RTP +-----+------------------------+ RTP +-----+------------------------+
Packet #1 | Hdr | Packetization unit #1 | Packet #1 | Hdr | Packetization unit #1 |
+-----+------------------------+ +-----+------------------------+
RTP +-----+--------------------------------------+ RTP +-----+--------------------------------------+
Packet #2 | Hdr | Packetization unit #2 | Packet #2 | Hdr | Packetization unit #2 |
+-----+--------------------------------------+ +-----+--------------------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #3 | Hdr | Packetization unit #3 (part 1/3) | Packet #3 | Hdr | Packetization unit #3 (part 1/3) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #4 | Hdr | Packetization unit #3 (part 2/3) | Packet #4 | Hdr | Packetization unit #3 (part 2/3) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
RTP +-----+----------------------------------------------+ RTP +-----+----------------------------------------------+
Packet #5 | Hdr | Packetization unit #3 (part 3/3) | Packet #5 | Hdr | Packetization unit #3 (part 3/3) |
+-----+----------------------------------------------+ +-----+----------------------------------------------+
... ...
RTP +-----+-----------------------------------------+ RTP +-----+-----------------------------------------+
Packet #P | Hdr | Packetization unit #N (part q/q) | Packet #P | Hdr | Packetization unit #N (part q/q) |
+-----+-----------------------------------------+ +-----+-----------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
There are two different packetization modes defined for this RTP payload format. There are two different packetization modes defined for this RTP payload format.
<list style="numbers"> </t>
<t>Codestream packetization mode: in this mode, the packetization unit
SHALL be the entire JPEG XS picture segment (i.e. codestream preceded
by boxes). This means
that a progressive frame will have a single packetization unit, while
an interlaced frame will have two. The progressive case is illustrated
in <xref target="cs_packetization" />.
</t>
<t>Slice packetization mode: in this mode, the packetization unit <dl newline="true">
SHALL be the slice, i.e. there SHALL be data from no more than one <dt>Codestream packetization mode:
slice per RTP packet. The first packetization unit SHALL be made of </dt>
the JPEG XS header segment (i.e. the concatenation of the VS box, the <dd>In this mode, the packetization unit <bcp14>SHALL</bcp14> be the entire
CS box and the JPEG XS codestream header). This first unit is then JPEG XS picture segment (i.e., codestream preceded by boxes). This means that
followed by successive units, each containing one and only one slice. a progressive frame will have a single packetization unit, while an interlaced
The packetization unit containing the last slice of a JPEG XS frame will have two. The progressive case is illustrated in <xref
codestream SHALL also contain the EOC marker immediately following target="cs_packetization" format="default"/>.
this last slice. This is illustrated in </dd>
<xref target="slice_packetization" />. In the case of an
interlaced frame, the JPEG XS header segment of the second field SHALL
be in its own packetization unit.
</t>
</list>
</t>
<figure anchor="cs_packetization" title="Example of codestream packetizati <dt>Slice packetization mode:
on mode"> </dt>
<artwork><![CDATA[ <dd>In this mode, the packetization unit <bcp14>SHALL</bcp14> be the slice,
i.e., there <bcp14>SHALL</bcp14> be data from no more than one slice per RTP
packet. The first packetization unit <bcp14>SHALL</bcp14> be made of the JPEG
XS header segment (i.e., the concatenation of the VS box, the CS box, and the
JPEG XS codestream header). This first unit is then followed by successive
units, each containing one and only one slice. The packetization unit
containing the last slice of a JPEG XS codestream <bcp14>SHALL</bcp14> also
contain the EOC marker immediately following this last slice. This is
illustrated in <xref target="slice_packetization" format="default"/>. In the
case of an interlaced frame, the JPEG XS header segment of the second field
<bcp14>SHALL</bcp14> be in its own packetization unit.
</dd>
</dl>
<figure anchor="cs_packetization">
<name>Example of Codestream Packetization Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) | Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #2 | Hdr | JPEG XS codestream (part 2/q) | Packet #2 | Hdr | JPEG XS codestream (part 2/q) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
... ...
RTP +-----+--------------------------------------+ RTP +-----+--------------------------------------+
Packet #P | Hdr | JPEG XS codestream (part q/q) | Packet #P | Hdr | JPEG XS codestream (part q/q) |
+-----+--------------------------------------+ +-----+--------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="slice_packetization">
<figure anchor="slice_packetization" title="Example of slice packetization <name>Example of Slice Packetization Mode</name>
mode"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
RTP +-----+----------------------------+ RTP +-----+----------------------------+
Packet #1 | Hdr | JPEG XS header segment | Packet #1 | Hdr | JPEG XS header segment |
+-----+----------------------------+ +-----+----------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #2 | Hdr | Slice #1 (part 1/2) | Packet #2 | Hdr | Slice #1 (part 1/2) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
RTP +-----+-------------------------------------------+ RTP +-----+-------------------------------------------+
Packet #3 | Hdr | Slice #1 (part 2/2) | Packet #3 | Hdr | Slice #1 (part 2/2) |
+-----+-------------------------------------------+ +-----+-------------------------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #4 | Hdr | Slice #2 (part 1/3) | Packet #4 | Hdr | Slice #2 (part 1/3) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
... ...
RTP +-----+---------------------------------------+ RTP +-----+---------------------------------------+
Packet #P | Hdr | Slice #N (part q/q) + EOC marker | Packet #P | Hdr | Slice #N (part q/q) + EOC marker |
+-----+---------------------------------------+ +-----+---------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t> In a constant bitrate (CBR) scenario of JPEG XS, the codestream packetiz
In a constant bit-rate (CBR) scenario of JPEG XS, the codestream packeti ation
zation mode guarantees that a JPEG XS RTP stream will produce both a constant n
mode guarantees that a JPEG XS RTP stream will produce a constant number umber
of bytes per video frame, and a constant number of RTP packets per video of bytes per video frame and a constant number of RTP packets per video
frame. frame.
However, to provide similar guarantees with JPEG XS in a variable bit-ra However, to provide similar guarantees with JPEG XS in a variable bitrat
te (VBR) e (VBR)
mode or when using the slice packetization mode (for either CBR or VBR), additional mode or when using the slice packetization mode (for either CBR or VBR), additional
mechanisms are needed. This can involve a constraint at the rate allocat ion mechanisms are needed. This can involve a constraint at the rate allocat ion
stage in the JPEG XS encoder to impose a constant bit-rate at the slice stage in the JPEG XS encoder to impose a CBR at the slice level,
level, the usage of padding data, or the insertion of empty RTP packets (i.e.,
the usage of padding data, or the insertion of empty RTP packets (i.e. a an RTP
n RTP
packet whose payload data is empty). But, management of the amount of pr oduced packet whose payload data is empty). But, management of the amount of pr oduced
packets per video frame is application dependent and not a strict requir ement of packets per video frame is application dependent and not a strict requir ement of
this RTP payload specification. this RTP payload specification.
</t> </t>
</section> </section>
<section anchor="rtp_hdr" numbered="true" toc="default">
<section title="RTP Header Usage" anchor="rtp_hdr"> <name>RTP Header Usage</name>
<t> <t>
The format of the RTP header is specified in <xref target="RFC3550" /> a The format of the RTP header is specified in <xref target="RFC3550" form
nd at="default"/> and
reprinted in <xref target="rtp_header" /> for reprinted in <xref target="rtp_header" format="default"/> for
convenience. This RTP payload format uses the fields of the header in a convenience. This RTP payload format uses the fields of the header in a
manner consistent with that specification. manner consistent with that specification.
</t> </t>
<t> <t>
The RTP payload (and the settings for some RTP header bits) for The RTP payload (and the settings for some RTP header bits) for
packetization units are specified in <xref target="payload_hdr" />. packetization units are specified in <xref target="payload_hdr" format="
</t> default"/>.
</t>
<figure anchor="rtp_header" title="RTP header according to RFC 3550"> <figure anchor="rtp_header">
<artwork><![CDATA[ <name>RTP Header According to RFC 3550</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | sequence number | |V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers | | contributing source (CSRC) identifiers |
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
The version (V), padding (P), extension (X), CSRC count (CC), The version (V), padding (P), extension (X), CSRC count (CC),
sequence number, synchronization source (SSRC) and contributing sequence number, synchronization source (SSRC), and contributing
source (CSRC) fields follow their respective definitions in source (CSRC) fields follow their respective definitions in
<xref target="RFC3550" />. <xref target="RFC3550" format="default"/>.
</t> </t>
<t> <t>
The remaining RTP header information to be set according to this RTP The remaining RTP header information to be set according to this RTP
payload format is set as follows: payload format is set as follows:
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>Marker (M) [1 bit]:</dt>
<t hangText="Marker (M) [1 bit]:"><vspace /><vspace /> <dd>
<t>
If progressive scan video is being transmitted, the marker bit If progressive scan video is being transmitted, the marker bit
denotes the end of a video frame. If interlaced video is being denotes the end of a video frame. If interlaced video is being
transmitted, it denotes the end of the field. The marker bit SHALL transmitted, it denotes the end of the field. The marker bit <bcp14>SHA
be set to 1 for the last packet of the video frame/field. It SHALL LL</bcp14>
be set to 1 for the last packet of the video frame/field. It <bcp14>SHA
LL</bcp14>
be set to 0 for all other packets. be set to 0 for all other packets.
</t> </t>
<t hangText="Payload Type (PT) [7 bits]:"><vspace /><vspace /> </dd>
A dynamically allocated payload type field that designates the <dt>Payload Type (PT) [7 bits]:</dt>
payload as JPEG XS video. <dd>
</t> <t>
<t hangText="Timestamp [32 bits]:"><vspace /><vspace /> The payload type is a dynamically allocated payload type field that
designates the payload as JPEG XS video.
</t>
</dd>
<dt>Timestamp [32 bits]:</dt>
<dd>
<t>
The RTP timestamp is set to the sampling timestamp of the content. The RTP timestamp is set to the sampling timestamp of the content.
A 90 kHz clock rate SHALL be used.<vspace /><vspace /> A 90 kHz clock rate <bcp14>SHALL</bcp14> be used.</t>
<t>
As specified in <xref target="RFC3550" /> and As specified in <xref target="RFC3550" format="default"/> and
<xref target="RFC4175" />, the RTP timestamp designates the <xref target="RFC4175" format="default"/>, the RTP timestamp designates
the
sampling instant of the first octet of the video frame to which the RTP sampling instant of the first octet of the video frame to which the RTP
packet belongs. Packets SHALL NOT include data from multiple video fram packet belongs. Packets <bcp14>SHALL NOT</bcp14> include data from mult
es, and iple video frames, and
all packets belonging to the same video frame SHALL have the same times all packets belonging to the same video frame <bcp14>SHALL</bcp14> have
tamp. the same timestamp.
Several successive RTP packets will consequently have equal timestamps Several successive RTP packets will consequently have equal timestamps
if they belong to the same video frame (that is until the marker bit is set if they belong to the same video frame (that is until the marker bit is set
to 1, marking the last packet of the video frame), and the timestamp is only to 1, marking the last packet of the video frame), and the timestamp is only
increased when a new video frame begins.<vspace /><vspace /> increased when a new video frame begins.</t>
<t>
If the sampling instant does not correspond to an integer value of If the sampling instant does not correspond to an integer value of
the clock, the value SHALL be truncated to the next lowest integer, the clock, the value <bcp14>SHALL</bcp14> be truncated to the next lowe st integer,
with no ambiguity. with no ambiguity.
</t> </t>
</list> </dd>
</t> </dl>
</section> </section>
<section anchor="payload_hdr" numbered="true" toc="default">
<name>Payload Header Usage</name>
<section title="Payload Header Usage" anchor="payload_hdr"> <t>
<t>
The first four bytes of the payload of an RTP packet in this RTP The first four bytes of the payload of an RTP packet in this RTP
payload format are referred to as the payload header. <xref payload format are referred to as the "payload header". <xref target="p
target="payload_header" /> illustrates the structure of this ayload_header" format="default"/> illustrates the structure of this
payload header. payload header.
</t> </t>
<figure anchor="payload_header">
<figure anchor="payload_header" title="Payload header"> <name>Payload Header</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|K|L| I |F counter| SEP counter | P counter | |T|K|L| I |F counter| SEP counter | P counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
The payload header consists of the following fields: The payload header consists of the following fields:
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>Transmission mode (T) [1 bit]:</dt>
<t hangText="Transmission mode (T) [1 bit]:"><vspace /><vspace /> <dd>
<t>
The T bit is set to indicate that packets are sent sequentially by the The T bit is set to indicate that packets are sent sequentially by the
transmitter. This information allows a receiver to dimension its transmitter. This information allows a receiver to dimension its
input buffer(s) accordingly. If T=0, nothing can be assumed about the input buffer(s) accordingly. If T=0, nothing can be assumed about the
transmission order and packets may be sent out-of-order by the transmission order and packets may be sent out of order by the
transmitter. If T=1, packets SHALL be sent sequentially by the transmitter. If T=1, packets <bcp14>SHALL</bcp14> be sent sequentially
transmitter. The T bit value SHALL be identical for all packets of by the
transmitter. The T-bit value <bcp14>SHALL</bcp14> be identical for all
packets of
the RTP stream. the RTP stream.
</t> </t>
<t hangText="pacKetization mode (K) [1 bit]:"><vspace /><vspace /> </dd>
<dt>pacKetization mode (K) [1 bit]:</dt>
<dd>
<t>
The K bit is set to indicate which packetization mode is used. K=0 The K bit is set to indicate which packetization mode is used. K=0
indicates codestream packetization mode, while K=1 indicates slice indicates codestream packetization mode, while K=1 indicates slice
packetization mode. In the case that the Transmission mode (T) is packetization mode. In the case that the Transmission mode (T) is
set to 0 (out-of-order), the slice packetization mode SHALL be used set to 0 (out of order), the slice packetization mode <bcp14>SHALL</bcp
and K SHALL be set to 1. This is required, because only the slice 14> be used
and K <bcp14>SHALL</bcp14> be set to 1. This is required because only t
he slice
packetization mode supports out-of-order packet transmission. The packetization mode supports out-of-order packet transmission. The
K bit value SHALL be identical for all packets of the RTP stream. K-bit value <bcp14>SHALL</bcp14> be identical for all packets of the RT
</t> P stream.
<t hangText="Last (L) [1 bit]:"><vspace /><vspace /> </t>
</dd>
<dt>Last (L) [1 bit]:</dt>
<dd>
<t>
The L bit is set to indicate the last packet of a packetization unit. The L bit is set to indicate the last packet of a packetization unit.
As the end of the video frame also ends the packet containing the last unit As the end of the video frame also ends the packet containing the last unit
of the video frame, the L bit is set whenever the M bit is set. In of the video frame, the L bit is set whenever the M bit is set. In
the codestream packetization mode the L bit and M bit get an equivalent the codestream packetization mode, the L bit and M bit get an equivalen
meaning, so they SHALL have identical values in each packet. t
</t> meaning, so they <bcp14>SHALL</bcp14> have identical values in each pac
<t hangText="Interlaced information (I) [2 bit]:"><vspace /><vspace /> ket.
</t>
</dd>
<dt>Interlaced information (I) [2 bits]:</dt>
<dd>
<t>
These two I bits are used to indicate how the JPEG XS frame is scanned These two I bits are used to indicate how the JPEG XS frame is scanned
(progressive or interlaced). In case of an interlaced frame, they also (progressive or interlaced). In case of an interlaced frame, they also
indicate which JPEG XS picture segment the payload is part of (first indicate which JPEG XS picture segment the payload is part of (first
or second). or second).
<list> </t>
<t hangText="00:"> <dl newline="false" spacing="normal" indent='6'>
<dt>00:</dt>
<dd>
The payload is progressively scanned. The payload is progressively scanned.
</t> </dd>
<t hangText="01:"> <dt>01:</dt>
Reserved for future use. <dd>
</t> This value is reserved for future use.
<t hangText="10:"> </dd>
<dt>10:</dt>
<dd>
The payload is part of the first JPEG XS picture segment of The payload is part of the first JPEG XS picture segment of
an interlaced video frame. The height specified in the included an interlaced video frame. The height specified in the included
JPEG XS codestream header is half of the height of the entire JPEG XS codestream header is half of the height of the entire
displayed image. displayed image.
</t> </dd>
<t hangText="11:"> <dt>11:</dt>
<dd>
The payload is part of the second JPEG XS picture segment of The payload is part of the second JPEG XS picture segment of
an interlaced video frame. The height specified in the included an interlaced video frame. The height specified in the included
JPEG XS codestream header is half of the height of the entire JPEG XS codestream header is half of the height of the entire
displayed image. displayed image.
</t> </dd>
</list> </dl>
</t> </dd>
<t hangText="F counter [5 bits]:"><vspace /><vspace /> <dt>F counter [5 bits]:</dt>
The frame (F) counter identifies the video frame number modulo 32 to wh <dd>
ich a <t>
The Frame (F) counter identifies the video frame number modulo 32 to wh
ich a
packet belongs. Frame numbers are incremented by 1 for each video frame packet belongs. Frame numbers are incremented by 1 for each video frame
transmitted. The frame number, in addition to the timestamp, may help transmitted. The frame number, in addition to the timestamp, may help
the decoder manage its input buffer and bring packets back into their the decoder manage its input buffer and bring packets back into their
natural order. natural order.
</t> </t>
<t hangText="SEP counter [11 bits]:"><vspace /><vspace /> </dd>
The Slice and Extended Packet (SEP) counter is used differently <dt>Slice and Extended Packet (SEP) counter [11 bits]:</dt>
<dd>
<t>
The SEP counter is used differently
depending on the packetization mode. depending on the packetization mode.
<list style="symbols"> </t>
<t>In the case of codestream packetization mode (K=0), this counter <ul spacing="normal">
resets whenever the Packet counter resets (see <xref target="rtp_paylo <li>In the case of codestream packetization mode (K=0), this
ad_data" />), and counter resets whenever the Packet counter resets (see <xref
increments by 1 whenever the Packet counter overruns. target="rtp_payload_data" format="default"/>) and increments by
</t> 1 whenever the Packet counter overruns.
</li>
<t>In the case of slice packetization mode (K=1), this counter <li>In the case of slice packetization mode (K=1), this counter
identifies the slice modulo 2047 to which the packet contributes. If identifies the slice modulo 2047 to which the packet contributes. If
the data belongs to the JPEG XS header segment, this field SHALL have the data belongs to the JPEG XS header segment, this field <bcp14>SHAL L</bcp14> have
its maximal value, namely 2047 = 0x07ff. Otherwise, it is the slice its maximal value, namely 2047 = 0x07ff. Otherwise, it is the slice
index modulo 2047. Slice indices are counted from 0 (corresponding to index modulo 2047. Slice indices are counted from 0 (corresponding to
the top of the video frame). the top of the video frame).
</t> </li>
</list> </ul>
</t> </dd>
<t hangText="P counter [11 bits]:"><vspace /><vspace /> <dt>P counter [11 bits]:</dt>
The packet (P) counter identifies the packet number modulo 2048 <dd>
<t>
The Packet (P) counter identifies the packet number modulo 2048
within the current packetization unit. It is set to 0 at the start of within the current packetization unit. It is set to 0 at the start of
the packetization unit and incremented by 1 for every subsequent the packetization unit and incremented by 1 for every subsequent
packet (if any) belonging to the same unit. Practically, if packet (if any) belonging to the same unit. Practically, if
codestream packetization mode is enabled, this field counts the codestream packetization mode is enabled, this field counts the
packets within a JPEG XS picture segment and is extended by the SEP packets within a JPEG XS picture segment and is extended by the SEP
counter when it overruns. If slice packetization mode is enabled, counter when it overruns. If slice packetization mode is enabled,
this field counts the packets within a slice or within the JPEG XS this field counts the packets within a slice or within the JPEG XS
header segment. header segment.
</t> </t>
</list> </dd>
</t> </dl>
</section> </section>
<section anchor="rtp_payload_data" numbered="true" toc="default">
<name>Payload Data</name>
<section title="Payload Data" anchor="rtp_payload_data"> <t>
<t>
The payload data of a JPEG XS RTP stream consists of a concatenation of The payload data of a JPEG XS RTP stream consists of a concatenation of
multiple JPEG XS frames. Within the RTP stream, all of the video support boxes multiple JPEG XS frames. Within the RTP stream, all of the video support boxes
and all of the color specification boxes SHALL retain their respective la and all of the color specification boxes <bcp14>SHALL</bcp14> retain thei
youts r respective layouts
for each JPEG XS frame. Thus, each video support box in the RTP stream SH for each JPEG XS frame. Thus, each video support box in the RTP stream <b
ALL cp14>SHALL</bcp14>
define the same sub boxes. The effective values in the boxes are allowed to define the same sub boxes. The effective values in the boxes are allowed to
change under the condition that their relative byte offsets SHALL NOT cha change under the condition that their relative byte offsets <bcp14>SHALL
nge. NOT</bcp14> change.
</t> </t>
<t> <t>
Each JPEG XS frame is the concatenation of one or more packetization Each JPEG XS frame is the concatenation of one or more packetization
unit(s), as explained in <xref target="rtp_packet" />. unit(s), as explained in <xref target="rtp_packet" format="default"/>.
<xref target="rtp_cs_progressive_packet_data" /> depicts this <xref target="rtp_cs_progressive_packet_data" format="default"/> depicts
this
layout for a progressive video frame in the codestream packetization mode , layout for a progressive video frame in the codestream packetization mode ,
<xref target="rtp_cs_interlaced_packet_data" /> depicts this <xref target="rtp_cs_interlaced_packet_data" format="default"/> depicts t his
layout for an interlaced video frame in the codestream packetization mode , layout for an interlaced video frame in the codestream packetization mode ,
<xref target="rtp_slice_progressive_packet_data" /> depicts this <xref target="rtp_slice_progressive_packet_data" format="default"/> depic
layout for a progressive video frame in the slice packetization mode and ts this
<xref target="rtp_slice_interlaced_packet_data" /> depicts this layout for a progressive video frame in the slice packetization mode, and
<xref target="rtp_slice_interlaced_packet_data" format="default"/> depict
s this
layout for an interlaced video frame in the slice packetization mode. The Frame layout for an interlaced video frame in the slice packetization mode. The Frame
counter value is not indicated because the value is constant for all counter value is not indicated because the value is constant for all
packetization units of a given video frame. packetization units of a given video frame.
</t> </t>
<figure anchor="rtp_cs_progressive_packet_data">
<figure anchor="rtp_cs_progressive_packet_data" title="Example of JPEG XS <name>Example of JPEG XS Payload Data (Codestream Packetization
Payload Data (codestream packetization mode, progressive video frame)"> Mode, Progressive Video Frame)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+=====[ Packetization unit (PU) #1 ]====+ +=====[ Packetization unit (PU) #1 ]====+
| Video support box | SEP counter=0 | Video support box | SEP counter=0
| +---------------------------------+ | P counter=0 | +---------------------------------+ | P counter=0
| : Sub boxes of the VS box : | | : Sub boxes of the VS box : |
| +---------------------------------+ | | +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| Color specification box | | Color specification box |
| +---------------------------------+ | | +---------------------------------+ |
| : Fields of the CS box : | | : Fields of the CS box : |
| +---------------------------------+ | | +---------------------------------+ |
skipping to change at line 806 skipping to change at line 779
| (part 2049/q) | P counter=0 | (part 2049/q) | P counter=0
: : M=0, K=0, L=0, I=00 : : M=0, K=0, L=0, I=00
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream | SEP counter=(q-1) div 2048 | JPEG XS codestream | SEP counter=(q-1) div 2048
| (part q/q) | P counter=(q-1) mod 2048 | (part q/q) | P counter=(q-1) mod 2048
: : M=1, K=0, L=1, I=00 : : M=1, K=0, L=1, I=00
+=======================================+ +=======================================+
]]></artwork> ]]></artwork>
</figure> </figure>
<t/>
<t><vspace blankLines='100' /></t> <figure anchor="rtp_cs_interlaced_packet_data">
<name>Example of JPEG XS Payload Data (Codestream Packetization Mode,
<figure anchor="rtp_cs_interlaced_packet_data" title="Example of JPEG XS P Interlaced Video Frame)</name>
ayload Data (codestream packetization mode, interlaced video frame)"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+=====[ Packetization unit (PU) #1 ]====+ +=====[ Packetization unit (PU) #1 ]====+
| Video support box | SEP counter=0 | Video support box | SEP counter=0
+- - - - - - - - - - - - - - - - - - - -+ P counter=0 +- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box | | Color specification box |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream (1st field) | | JPEG XS codestream (1st field) |
: (part 1/q) : M=0, K=0, L=0, I=10 : (part 1/q) : M=0, K=0, L=0, I=10
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (1st field) | SEP counter=0 | JPEG XS codestream (1st field) | SEP counter=0
| (part 2/q) | P counter=1 | (part 2/q) | P counter=1
skipping to change at line 855 skipping to change at line 827
| (part 2/q) | P counter=1 | (part 2/q) | P counter=1
: : M=0, K=0, L=0, I=11 : : M=0, K=0, L=0, I=11
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (2nd field) | SEP counter=(q-1) div 2048 | JPEG XS codestream (2nd field) | SEP counter=(q-1) div 2048
| (part q/q) | P counter=(q-1) mod 2048 | (part q/q) | P counter=(q-1) mod 2048
: : M=1, K=0, L=1, I=11 : : M=1, K=0, L=1, I=11
+=======================================+ +=======================================+
]]></artwork> ]]></artwork>
</figure> </figure>
<t/>
<t><vspace blankLines='100' /></t> <figure anchor="rtp_slice_progressive_packet_data">
<name>Example of JPEG XS Payload Data (Slice Packetization Mode, Progr
<figure anchor="rtp_slice_progressive_packet_data" title="Example of JPEG essive Video Frame)</name>
XS Payload Data (slice packetization mode, progressive video frame)"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+===[ PU #1: JPEG XS Header segment ]===+ +===[ PU #1: JPEG XS Header segment ]===+
| Video support box | SEP counter=0x07FF | Video support box | SEP counter=0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter=0 +- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box | | Color specification box |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header | | JPEG XS codestream header |
| +---------------------------------+ | | +---------------------------------+ |
| : Markers and marker segments : | | : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00
+==========[ PU #2: Slice #1 ]==========+ +==========[ PU #2: Slice #1 ]==========+
skipping to change at line 904 skipping to change at line 875
| (part 1/r) | P counter=0 | (part 1/r) | P counter=0
: : M=0, T=0, K=1, L=0, I=00 : : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| Slice #(N-1) | SEP counter=N-2 | Slice #(N-1) | SEP counter=N-2
| (part r/r) | P counter=r-1 | (part r/r) | P counter=r-1
: + EOC marker : M=1, T=0, K=1, L=1, I=00 : + EOC marker : M=1, T=0, K=1, L=1, I=00
+=======================================+ +=======================================+
]]></artwork> ]]></artwork>
</figure> </figure>
<t/>
<t><vspace blankLines='100' /></t> <figure anchor="rtp_slice_interlaced_packet_data">
<name>Example of JPEG XS Payload Data (Slice Packetization Mode, Inter
<figure anchor="rtp_slice_interlaced_packet_data" title="Example of JPEG X laced Video Frame)</name>
S Payload Data (slice packetization mode, interlaced video frame)"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+====[ PU #1: JPEG XS Hdr segment 1 ]===+ +====[ PU #1: JPEG XS Hdr segment 1 ]===+
| Video support box | SEP counter=0x07FF | Video support box | SEP counter=0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter=0 +- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box | | Color specification box |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header 1 | | JPEG XS codestream header 1 |
| +---------------------------------+ | | +---------------------------------+ |
| : Markers and marker segments : | | : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10
+====[ PU #2: Slice #1 (1st field) ]====+ +====[ PU #2: Slice #1 (1st field) ]====+
skipping to change at line 995 skipping to change at line 965
| (part 1/t) | P counter=0 | (part 1/t) | P counter=0
: : M=0, T=0, K=1, L=0, I=11 : : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| Slice #(N-1) | SEP counter=N-2 | Slice #(N-1) | SEP counter=N-2
| (part t/t) | P counter=t-1 | (part t/t) | P counter=t-1
: + EOC marker : M=1, T=0, K=1, L=1, I=11 : + EOC marker : M=1, T=0, K=1, L=1, I=11
+=======================================+ +=======================================+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="tsdt" numbered="true" toc="default">
<section title="Traffic Shaping and Delivery Timing" anchor="tsdt"> <name>Traffic Shaping and Delivery Timing</name>
<t> <t>
In order to facilitate proper synchronization between senders and receive In order to facilitate proper synchronization between senders and
rs it receivers, it is <bcp14>RECOMMENDED</bcp14> to implement traffic
is RECOMMENDED to implement traffic shaping and delivery timing in accord shaping and delivery timing in accordance with the Network
ance Compatibility Model compliance definitions specified in <xref
with the Network Compatibility Model compliance definitions specified in target="SMPTE2110-21" format="default"/>. In such a case, the session
<xref target="SMPTE-ST2110-21" />. In such case, the session description description <bcp14>SHALL</bcp14> signal the compliance with the media
SHALL type parameter TP. The actual applied traffic shaping and
signal the compliance with the media type parameter TP. The actual applie timing delivery mechanism is outside the scope of this memo and does
d not influence the payload packetization.
traffic shaping and timing delivery mechanism is outside the scope of thi </t>
s memo </section>
and does not influence the payload packetization. <section numbered="true" toc="default">
</t> <name>Congestion Control Considerations</name>
</section> <t>
Congestion control for RTP <bcp14>SHALL</bcp14> be used in accordance wit
h
<xref target="RFC3550" format="default"/> and with any applicable
RTP profile, e.g., <xref target="RFC3551" format="default">RTP/AVP</xref>
or
<xref target="RFC4585" format="default">RTP/AVPF</xref>.
</t>
<t>
While JPEG XS is mainly designed to be used in controlled network
environments, it can also be employed in best-effort network
environments, like the Internet. However, in this case, the users of
this payload format <bcp14>SHALL</bcp14> monitor packet loss to ensure
that the packet loss rate is within acceptable parameters. This can be
achieved, for example, by means of <xref target="RFC8888"
format="default">RTP Control Protocol (RTCP) Feedback for Congestion
Control</xref>.
</t>
<t>
In addition, <xref target="RFC8083" format="default"/> is an update to
<xref target="RFC3550" format="default"/> that defines criteria for
when one is required to stop sending RTP Packet Streams and for when
applications implementing this standard <bcp14>SHALL</bcp14> comply
with it.
</t>
<section title="Congestion Control Considerations"> <t>
<t> <xref target="RFC8085" format="default"/> provides additional information
Congestion control for RTP SHALL be used in accordance with
<xref target="RFC3550" />, and with any applicable
RTP profile: e.g. <xref target="RFC3551">RTP/AVP</xref> or
<xref target="RFC4585">RTP/AVPF</xref>.
</t>
<t>
While JPEG XS is mainly designed to be used in controlled network environ
ments, it
can also be employed in best-effort network environments, like the Intern
et. However,
in this case the users of this payload format SHALL monitor packet loss t
o
ensure that the packet loss rate is within acceptable parameters. This ca
n be
achieved for example by means of the <xref target="RFC8888">RTP Control P
rotocol (RTCP) Feedback for Congestion Control</xref>.
</t>
<t>
In addition, <xref target="RFC8083">Circuit Breakers</xref> is an update
to
<xref target="RFC3550">RTP</xref> that defines criteria for when one
is required to stop sending RTP Packet Streams and applications
implementing this standard SHALL comply with it.
</t>
<t>
<xref target="RFC8085" /> provides additional information
on the best practices for applying congestion control to UDP streams. on the best practices for applying congestion control to UDP streams.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Payload Format Parameters"> <name>Payload Format Parameters</name>
<t> <t>
This section specifies the required and optional parameters of the payload format and/or This section specifies the required and optional parameters of the payload format and/or
the RTP stream. All parameters are declarative, meaning that the informati on signaled by the RTP stream. All parameters are declarative, meaning that the informati on signaled by
the parameters is also present in the payload data, namely in the payload the parameters is also present in the payload data, namely in the payload
header (see <xref target="payload_hdr" />) or in the JPEG XS header segment <xre header (see <xref target="payload_hdr" format="default"/>) or in the JPEG XS hea
f target="ISO21122-1" /> <xref target="ISO21122-3" />. When provided, their resp der segment <xref target="ISO21122-1" format="default"/> <xref target="ISO21122-
ective values SHALL be consistent with the payload. 3" format="default"/>. When provided, their respective values <bcp14>SHALL</bcp1
</t> 4> be consistent with the payload.
<section title="Media Type Registration" anchor="media_type_def"> </t>
<t> <section anchor="media_type_def" numbered="true" toc="default">
<list style="hanging"> <name>Media Type Registration</name>
<t>This registration is done using the template defined in <xref targ
et="RFC6838" /> and following <xref target="RFC4855" />.</t> <t>
<t>The receiver SHALL ignore any unrecognized parameter.</t> This registration is done using the template defined in <xref
<t hangText="Type name:">video</t> target="RFC6838" format="default"/> and following <xref
<t hangText="Subtype name:">jxsv</t> target="RFC4855" format="default"/>.
<t hangText="Clock rate:">90000</t>
<t hangText="Required parameters:"> </t>
<list>
<t hangText="rate:"> <t> The receiver <bcp14>SHALL</bcp14> ignore any unrecognized parameter.</t>
The RTP timestamp clock rate. Applications using this pa <dl newline="true" spacing="normal">
yload format SHALL use a value of 90000. <dt>Type name:</dt>
</t> <dd>video</dd>
<t hangText="packetmode:"> <dt>Subtype name:</dt>
<dd>jxsv</dd>
<dt>Required parameters:</dt>
<dd>
<dl newline="false" spacing="normal">
<dt>rate:</dt>
<dd>
The RTP timestamp clock rate. Applications using this payload fo
rmat <bcp14>SHALL</bcp14> use a value of 90000.
</dd>
<dt>packetmode:</dt>
<dd>
This parameter specifies the configured packetization mode as d efined This parameter specifies the configured packetization mode as d efined
by the pacKetization mode (K) bit in the payload header of <xre by the pacKetization mode (K) bit in the payload header of <xre
f target="payload_hdr" />. f target="payload_hdr" format="default"/>.
This value SHALL be equal to the K bit value configured in the This value <bcp14>SHALL</bcp14> be equal to the K-bit value con
RTP stream (i.e. 0 for codestream or 1 for slice). figured in the RTP stream (i.e., 0 for codestream or 1 for slice).
</t> </dd>
</list> </dl>
</t> </dd>
<t hangText="Optional parameters:"> <dt>Optional parameters:</dt>
<list> <dd>
<t hangText="transmode:"> <dl newline="false" spacing="normal">
This parameter specifies the configured transmission mo <dt>transmode:</dt>
de as defined <dd>
by the Transmission mode (T) bit in the payload header This parameter specifies the configured transmission mode as
of <xref target="payload_hdr" />. defined by the Transmission mode (T) bit in the payload
If specified, this value SHALL be equal to the T bit va header of <xref target="payload_hdr" format="default"/>. I
lue configured in the f
RTP stream (i.e. 0 for out-of-order-allowed or 1 for sequentia specified, this value <bcp14>SHALL</bcp14> be equal to th
l-only). If not specified, e
a value 1 (sequential-only) SHALL be assumed and the T bit SHA T-bit value configured in the RTP stream (i.e., 0 for
LL be set to 1. out-of-order-allowed or 1 for sequential-only). If no
</t> t
<t hangText="profile:"> specified, a value 1 (sequential-only) <bcp14>SHALL
The <xref target="ISO21122-2">JPEG XS profile</xref> in use. </bcp14>
Any white space in the profile name SHALL be omitted. be assumed and the T bit <bcp14>SHALL</bcp14> be
set to 1.
</dd>
<dt>profile:</dt>
<dd>
The <xref target="ISO21122-2" format="default">JPEG XS profile<
/xref> in use.
Any white space Unicode character in the profile name <bcp14>SH
ALL</bcp14> be omitted.
Examples of valid profile names are 'Main444.12' or 'High444.12 '. Examples of valid profile names are 'Main444.12' or 'High444.12 '.
</t> </dd>
<t hangText="level:"> <dt>level:</dt>
The <xref target="ISO21122-2">JPEG XS level</xref> in use. <dd>
Any white space in the level name SHALL be omitted. The <xref target="ISO21122-2" format="default">JPEG XS level</x
ref> in use.
Any white space Unicode character in the level name <bcp14>SHAL
L</bcp14> be omitted.
Examples of valid levels are '2k-1' or '4k-2'. Examples of valid levels are '2k-1' or '4k-2'.
</t> </dd>
<t hangText="sublevel:"> <dt>sublevel:</dt>
The <xref target="ISO21122-2">JPEG XS sublevel</xref> in use. <dd>
Any white space in the sublevel name SHALL be omitted. The <xref target="ISO21122-2" format="default">JPEG XS sublevel
</xref> in use.
Any white space Unicode character in the sublevel name <bcp14>S
HALL</bcp14> be omitted.
Examples of valid sublevels are 'Sublev3bpp' or 'Sublev6bpp'. Examples of valid sublevels are 'Sublev3bpp' or 'Sublev6bpp'.
</t> </dd>
<t hangText="depth:"> <dt>depth:</dt>
<dd>
Determines the number of bits per sample. This is an Determines the number of bits per sample. This is an
integer with typical values including 8, 10, 12, and 16. integer with typical values including 8, 10, 12, and 16.
</t> </dd>
<t hangText="width:"> <dt>width:</dt>
<dd>
Determines the number of pixels per line. This is an Determines the number of pixels per line. This is an
integer between 1 and 32767 inclusive. integer between 1 and 32767, inclusive.
</t> </dd>
<t hangText="height:"> <dt>height:</dt>
<dd>
Determines the number of lines per video frame. This is an Determines the number of lines per video frame. This is an
integer between 1 and 32767 inclusive. integer between 1 and 32767, inclusive.
</t> </dd>
<t hangText="exactframerate:"> <dt>exactframerate:</dt>
<dd>
Signals the video frame rate in frames per second. Signals the video frame rate in frames per second.
Integer frame rates SHALL be signaled as a single decimal Integer frame rates <bcp14>SHALL</bcp14> be signaled as a singl
number (e.g. "25") whilst non-integer frame rates SHALL be e decimal
number (e.g., "25") whilst non-integer frame rates <bcp14>SHALL
</bcp14> be
signaled as a ratio of two integer decimal numbers separated signaled as a ratio of two integer decimal numbers separated
by a "forward-slash" character (e.g. "30000/1001"), utilizing by a "forward-slash" character (e.g., "30000/1001"), utilizing
the numerically smallest numerator value possible. the numerically smallest numerator value possible.
</t> </dd>
<t hangText="interlace:"> <dt>interlace:</dt>
<dd>
If this parameter name is present, it indicates If this parameter name is present, it indicates
that the video is interlaced, or that the video is that the video is interlaced, or that the video is
Progressive segmented Frame (PsF). If this parameter name is Progressive segmented Frame (PsF). If this parameter name is
not present, the progressive video format SHALL be assumed. not present, the progressive video format <bcp14>SHALL</bcp14>
</t> be assumed.
<t hangText="segmented:"> </dd>
<dt>segmented:</dt>
<dd>
If this parameter name is present, and the If this parameter name is present, and the
interlace parameter name is also present, then the video is a interlace parameter name is also present, then the video is a
Progressive segmented Frame (PsF). Signaling of this Progressive segmented Frame (PsF). Signaling of this
parameter without the interlace parameter is forbidden. parameter without the interlace parameter is forbidden.
</t> </dd>
<t hangText="sampling:"> <dt>sampling:</dt>
<dd>
<t>
Signals the color difference signal sub-sampling Signals the color difference signal sub-sampling
structure. structure.
<vspace /><vspace /> </t>
<t>
Signals utilizing the non-constant luminance Signals utilizing the non-constant luminance
Y'C'B C'R signal format of Recommendation ITU-R BT.601-7, Y'C'B C'R signal format of <xref target="BT.601-7" format="defa
Recommendation ITU-R BT.709-6, Recommendation ITU-R BT.2020-2, ult"/>,
or Recommendation ITU-R BT.2100 SHALL use the appropriate one <xref target="BT.709-6" format="default"/>, <xref target="BT.20
20-2" format="default"/>,
or <xref target="BT.2100-2" format="default"/> <bcp14>SHALL</bc
p14> use the appropriate one
of the following values for the Media Type Parameter of the following values for the Media Type Parameter
"sampling": "sampling":
<figure><artwork><![CDATA[
YCbCr-4:4:4 (4:4:4 sampling) </t>
YCbCr-4:2:2 (4:2:2 sampling)
YCbCr-4:2:0 (4:2:0 sampling) <dl indent="15">
]]></artwork></figure> <dt>YCbCr-4:4:4</dt><dd>(4:4:4 sampling)</dd>
<vspace /><vspace /> <dt>YCbCr-4:2:2</dt><dd>(4:2:2 sampling)</dd>
<dt>YCbCr-4:2:0</dt><dd>(4:2:0 sampling)</dd>
</dl>
<t>
Signals utilizing the Constant Luminance Y'C C'BC C'RC signal Signals utilizing the Constant Luminance Y'C C'BC C'RC signal
format of Recommendation ITU-R BT.2020-2 SHALL use the format of <xref target="BT.2020-2" format="default"/> <bcp14>SH ALL</bcp14> use the
appropriate one of the following values for the Media Type appropriate one of the following values for the Media Type
Parameter "sampling": Parameter "sampling":
<figure><artwork><![CDATA[ </t>
CLYCbCr-4:4:4 (4:4:4 sampling)
CLYCbCr-4:2:2 (4:2:2 sampling) <dl indent="15">
CLYCbCr-4:2:0 (4:2:0 sampling) <dt>CLYCbCr-4:4:4</dt><dd>(4:4:4 sampling)</dd>
]]></artwork></figure> <dt>CLYCbCr-4:2:2</dt><dd>(4:2:2 sampling)</dd>
<vspace /><vspace /> <dt>CLYCbCr-4:2:0</dt><dd>(4:2:0 sampling)</dd>
</dl>
<t>
Signals utilizing the constant intensity I CT CP signal format Signals utilizing the constant intensity I CT CP signal format
of Recommendation ITU-R BT.2100 SHALL use the appropriate one of <xref target="BT.2100-2" format="default"/> <bcp14>SHALL</bc p14> use the appropriate one
of the following values for the Media Type Parameter of the following values for the Media Type Parameter
"sampling": "sampling":
<figure><artwork><![CDATA[ </t>
ICtCp-4:4:4 (4:4:4 sampling)
ICtCp-4:2:2 (4:2:2 sampling) <dl indent="15">
ICtCp-4:2:0 (4:2:0 sampling) <dt>ICtCp-4:4:4</dt><dd>(4:4:4 sampling)</dd>
]]></artwork></figure> <dt>ICtCp-4:2:2</dt><dd>(4:2:2 sampling)</dd>
<vspace /><vspace /> <dt>ICtCp-4:2:0</dt><dd>(4:2:0 sampling)</dd>
</dl>
<t>
Signals utilizing the 4:4:4 R' G' B' or RGB signal format Signals utilizing the 4:4:4 R' G' B' or RGB signal format
(such as that of Recommendation ITU-R BT.601, Recommendation (such as that of <xref target="BT.601-7" format="default"/>, <x
ITU-R BT.709, Recommendation ITU-R BT.2020, Recommendation ref target="BT.709-6" format="default"/>,
ITU-R BT.2100, SMPTE ST 2065-1 or ST 2065-3) SHALL use the <xref target="BT.2020-2" format="default"/>, <xref target="BT.2
following value for the Media Type Parameter sampling. 100-2" format="default"/>,
<figure><artwork><![CDATA[ <xref target="SMPTE2065-1" format="default"/>, or <xref target=
RGB (RGB or R' G' B' samples) "SMPTE2065-3" format="default"/>) <bcp14>SHALL</bcp14> use the
]]></artwork></figure> following value for the Media Type Parameter "sampling":
<vspace /><vspace /> </t>
<dl indent="15">
<dt>RGB</dt><dd>(RGB or R' G' B' samples)</dd>
</dl>
<t>
Signals utilizing the 4:4:4 X' Y' Z' signal format (such as Signals utilizing the 4:4:4 X' Y' Z' signal format (such as
defined in SMPTE ST 428-1) SHALL use the following value for defined in <xref target="SMPTE428-1" format="default"/>) <bcp14
the Media Type Parameter sampling. >SHALL</bcp14> use the following value for
<figure><artwork><![CDATA[ the Media Type Parameter "sampling":
XYZ (X' Y' Z' samples) </t>
]]></artwork></figure>
<vspace /><vspace /> <dl indent="15">
Key signals as defined in SMPTE RP 157 SHALL use the value key <dt>XYZ</dt><dd>(X' Y' Z' samples)</dd>
for the Media Type Parameter sampling. The Key signal is </dl>
represented as a single component. <t>
<figure><artwork><![CDATA[ Key signals as defined in <xref target="SMPTE157" format="default"/
KEY (Samples of the key signal) > <bcp14>SHALL</bcp14> use
]]></artwork></figure> the value key for the Media Type Parameter "sampling". The key
<vspace /><vspace /> signal is represented as a single component:
</t>
<dl indent="15">
<dt>KEY</dt><dd>(Samples of the key signal)</dd>
</dl>
<t>
Signals utilizing a color sub-sampling other than what is Signals utilizing a color sub-sampling other than what is
defined here SHALL use the following value for the Media defined here <bcp14>SHALL</bcp14> use the following value for
Type Parameter sampling. the Media Type Parameter "sampling":
<figure><artwork><![CDATA[ </t>
UNSPECIFIED (Sampling signaled by the payload.)
]]></artwork></figure> <dl indent="15">
</t> <dt>UNSPECIFIED</dt><dd>(Sampling signaled by the payload)</dd>
<t hangText="colorimetry:"> </dl>
Specifies the system colorimetry used by the
image samples. Valid values and their specification are: </dd>
<figure><artwork><![CDATA[ <dt>colorimetry:</dt>
BT601-5 ITU-R Recommendation BT.601-5. <dd>
BT709-2 ITU-R Recommendation BT.709-2. <t>
SMPTE240M SMPTE ST 240M. Specifies the system colorimetry used by the image
BT601 ITU-R Recommendation BT.601-7. samples. Valid values and their specification are the
BT709 ITU-R Recommendation BT.709-6. following:
BT2020 ITU-R Recommendation BT.2020-2. </t>
BT2100 ITU-R Recommendation BT.2100
Table 2 titled "System colorimetry". <dl indent="15">
ST2065-1 SMPTE ST 2065-1 Academy Color Encoding
Specification (ACES). <dt>BT601-5:</dt><dd><xref target="BT.601-5" format="default"/>.</dd>
ST2065-3 SMPTE ST 2065-3 Academy Density Exchange <dt>BT709-2:</dt><dd><xref target="BT.709-2" format="default"/>.</dd>
Encoding (ADX). <dt>SMPTE240M:</dt><dd><xref target="SMPTE240M" format="default"/>.</dd>
XYZ ISO/IEC 11664-1, section titled <dt>BT601:</dt><dd><xref target="BT.601-7" format="default"/>.</dd>
"1931 Observer". <dt>BT709:</dt><dd><xref target="BT.709-6" format="default"/>.</dd>
UNSPECIFIED Colorimetry is signaled in the payload by <dt>BT2020:</dt><dd><xref target="BT.2020-2" format="default"/>.</dd>
the color specification box of [ISO21122-3], <dt>BT2100:</dt><dd><xref target="BT.2100-2" format="default"/>, Table 2 titled
or it must be manually coordinated between "System colorimetry".</dd>
sender and receiver. <dt>ST2065-1:</dt><dd><xref target="SMPTE2065-1" format="default">Academy Color
]]></artwork></figure> Encoding Specification (ACES)</xref>.</dd>
Signals utilizing the Recommendation ITU-R BT.2100 colorimetry <dt>ST2065-3:</dt><dd><xref target="SMPTE2065-3" format="default">Academy Densit
SHOULD also signal the representational range using the y Exchange Encoding (ADX)</xref>.</dd>
<dt>XYZ:</dt><dd><xref target="ISO11664-1" format="default"/>, section titled "1
931 Observer".</dd>
<dt>UNSPECIFIED:</dt><dd>Colorimetry is signaled in the payload by the color spe
cification box of
<xref target="ISO21122-3"/>, or it must be manually coordinated between sender
and receiver.</dd>
</dl>
<t>
Signals utilizing the <xref target="BT.2100-2" format="default"
/> colorimetry
<bcp14>SHOULD</bcp14> also signal the representational range us
ing the
optional parameter RANGE defined below. Signals utilizing the optional parameter RANGE defined below. Signals utilizing the
UNSPECIFIED colorimetry might require manual coordination betwe en UNSPECIFIED colorimetry might require manual coordination betwe en
the sender and the receiver. the sender and the receiver.
</t> </t>
<t hangText="TCS:"> </dd>
<dt>TCS:</dt>
<dd>
<t>
Transfer Characteristic System. This parameter specifies Transfer Characteristic System. This parameter specifies
the transfer characteristic system of the image samples. the transfer characteristic system of the image samples.
Valid values and their specification are: Valid values and their specification are the following:
<figure><artwork><![CDATA[ </t>
SDR Standard Dynamic Range video streams that
utilize the OETF of ITU-R Recommendation <dl indent="15">
BT.709 or ITU-R Recommendation BT.2020. Such
streams SHALL be assumed to target the EOTF <dt>SDR:</dt><dd>Standard Dynamic Range video streams that utilize the Optical E
specified in ITU-R Recommendation BT.1886. lectrical
PQ High dynamic range video streams that utilize Transfer Function (OETF) of <xref target="BT.709-6" format="default"/> or <xref
the Perceptual Quantization system of ITU-R target="BT.2020-2" format="default"/>.
Recommendation BT.2100. Such streams <bcp14>SHALL</bcp14> be assumed to target the Electro-Optical Trans
HLG High dynamic range video streams that utilize fer
the Hybrid Log-Gamma system of ITU-R Function (EOTF) specified in <xref target="BT.1886-0" format="default"/>.</dd>
Recommendation BT.2100.
UNSPECIFIED Video streams whose transfer characteristics <dt>PQ:</dt><dd>High dynamic range video streams that utilize the Perceptual Qua
are signaled by the payload as specified in ntization system
[ISO21122-3], or must be manually of <xref target="BT.2100-2" format="default"/>. </dd>
coordinated between sender and receiver.
]]></artwork></figure> <dt>HLG:</dt><dd>High dynamic range video streams that utilize the Hybrid Log-Ga
</t> mma system
<t hangText="RANGE:"> of <xref target="BT.2100-2" format="default"/>.</dd>
This parameter SHOULD be used to signal the encoding
<dt>UNSPECIFIED:</dt><dd>Video streams whose transfer characteristics are signal
ed by the payload
as specified in <xref target="ISO21122-3"/>, or that must be manually
coordinated between sender and receiver.</dd>
</dl>
</dd>
<dt>RANGE:</dt>
<dd>
This parameter <bcp14>SHOULD</bcp14> be used to signal the enco
ding
range of the sample values within the stream. When paired with range of the sample values within the stream. When paired with
ITU Rec BT.2100 colorimetry, this parameter has two allowed <xref target="BT.2100-2" format="default"/> colorimetry, this p
values NARROW and FULL, corresponding to the ranges specified arameter has two allowed
in table 9 of ITU Rec BT.2100. In any other context, this values, NARROW and FULL, corresponding to the ranges specified
in TABLE 9 of <xref target="BT.2100-2" format="default"/>. In a
ny other context, this
parameter has three allowed values: NARROW, FULLPROTECT, and parameter has three allowed values: NARROW, FULLPROTECT, and
FULL, which correspond to the ranges specified in FULL, which correspond to the ranges specified in
SMPTE RP 2077. In the absence of this parameter, and for all <xref target="SMPTE2077" format="default"/>. In the absence of
but the UNSPECIFIED colorimetry, NARROW SHALL be the assumed this parameter, and for all
but the UNSPECIFIED colorimetry, NARROW <bcp14>SHALL</bcp14> be
the assumed
value. When paired with the UNSPECIFIED colorimetry, FULL value. When paired with the UNSPECIFIED colorimetry, FULL
SHALL be the default assumed value. <bcp14>SHALL</bcp14> be the default assumed value.
</t> </dd>
</list> </dl>
</t> </dd>
<t hangText="Encoding considerations:"><vspace /> <dt>Encoding considerations:</dt>
This media type is framed in RTP and contains binary data; see Sect <dd>
ion 4.8 in <xref target="RFC6838" />. This media type is framed in RTP and contains binary data; see
</t> <xref target="RFC6838" sectionFormat="of" section="4.8"
<t hangText="Security considerations:"><vspace /> format="default"/>.
Please see the <xref target="security">Security Considerations</xre </dd>
f> of RFC XXXX. <dt>Security considerations:</dt>
</t> <dd>
<t hangText="Interoperability considerations:"><vspace />None.</t> See the <xref target="security" format="none">Security
<t hangText="Published specification:"><vspace /> Considerations</xref> section of RFC 9134.
See RFC XXXX and its References section. </dd>
</t> <dt>Interoperability considerations:</dt>
<t hangText="Applications that use this media type:"><vspace />Any ap <dd>None</dd>
plication that transmits video over RTP (like SMPTE ST 2110).</t> <dt>Published specification:</dt>
<t hangText="Fragment identifier considerations:"><vspace />N/A.</t> <dd>
<t hangText="Additional information:"><vspace />None.</t> See the <xref target="references" format="none">References</xref>
<t hangText="Person &amp; email address to contact for further inform section of RFC 9134.
ation:"><vspace />S. Lugan &lt;rtp@intopix.com&gt; and Th. Richter &lt;jpeg-xs-t </dd>
echsupport@iis.fraunhofer.de&gt;.</t> <dt>Applications that use this media type:</dt>
<t hangText="Intended usage:"><vspace />COMMON</t> <dd>Any application that transmits video over RTP (like SMPTE ST 2110)
<t hangText="Restrictions on usage:"><vspace /> .</dd>
This media type depends on RTP framing, and hence is only defined f <dt>Fragment identifier considerations:</dt>
or transfer via <xref target="RFC3550">RTP</xref>.</t> <dd>N/A</dd>
<t hangText="Author:"><vspace />See the Authors' Addresses section of <dt>Additional information:</dt>
RFC XXXX.</t> <dd>None</dd>
<t hangText="Change controller:"><vspace />IETF Audio/Video Transport <dt>Person &amp; email address to contact for further information:</dt
working group delegated from the IESG. >
</t> <dd>T. Bruylants &lt;rtp@intopix.com&gt; and T. Richter &lt;jpeg-xs-te
</list> chsupport@iis.fraunhofer.de&gt;.</dd>
</t> <dt>Intended usage:</dt>
</section> <dd>COMMON</dd>
</section> <dt>Restrictions on usage:</dt>
<dd>
<section title="SDP Parameters"> This media type depends on RTP framing; hence, it is only defined f
<t> or transfer via <xref target="RFC3550" format="default">RTP</xref>.</dd>
A mapping of the parameters into the <xref target="RFC8866">Session Descri <dt>Author:</dt>
ption Protocol (SDP)</xref> <dd>See the Authors' Addresses section of RFC 9134.</dd>
<dt>Change controller:</dt>
<dd>IETF Audio/Video Transport Working Group delegated from the IESG.
</dd>
</dl>
</section>
</section>
<section numbered="true" toc="default">
<name>SDP Parameters</name>
<t>
A mapping of the parameters into the <xref target="RFC8866" format="defaul
t">Session Description Protocol (SDP)</xref>
is provided for applications that use SDP. is provided for applications that use SDP.
</t> </t>
<section title="Mapping of Payload Type Parameters to SDP"> <section numbered="true" toc="default">
<t> <name>Mapping of Payload Type Parameters to SDP</name>
The media type video/jxsv string is mapped to fields in the <xref targe <t>
t="RFC8866">Session The media type video/jxsv string is mapped to fields in the <xref targe
t="RFC8866" format="default">Session
Description Protocol (SDP)</xref> as follows: Description Protocol (SDP)</xref> as follows:
</t> </t>
<t> <dl newline="false" spacing="normal">
<list style="hanging"> <dt/>
<t> <dd>
The media type ("video") goes in SDP "m=" as the media name. The media type ("video") goes in SDP "m=" as the media name.
</t> </dd>
<t> <dt/>
<dd>
The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding
name, followed by a slash ("/") and the required parameter "rate" name, followed by a slash ("/") and the required parameter "rate"
corresponding to the RTP timestamp clock rate (which for the payloa d corresponding to the RTP timestamp clock rate (which for the payloa d
format defined in this document SHALL be 90000). format defined in this document <bcp14>SHALL</bcp14> be 90000).
</t> </dd>
<t> <dt/>
The required parameter "packetmode", and any of the additional opti <dd>
onal The required parameter "packetmode" and any of the additional
parameters, as described in <xref target="media_type_def" />, go in optional parameters, as described in <xref
the SDP media format description, being the "a=fmtp" attribute (For target="media_type_def" format="default"/>, go in the SDP media
mat Parameters), format description, being the "a=fmtp" attribute (Format
by copying them directly from the MIME media type string as a semic Parameters), by copying them directly from the media type string
olon-separated as a semicolon-separated list of parameter=value pairs.
list of parameter=value pairs. </dd>
</t> </dl>
</list> <t>
</t> All parameters of the media format <bcp14>SHALL</bcp14> correspond to t
<t> he
All parameters of the media format SHALL correspond to the
parameters of the payload. In case of discrepancies between parameters of the payload. In case of discrepancies between
payload parameter values and SDP fields, the values from the payload parameter values and SDP fields, the values from the
payload data SHALL prevail. payload data <bcp14>SHALL</bcp14> prevail.
</t> </t>
<t> <t>
The receiver SHALL ignore any parameter that is not defined in <xref ta The receiver <bcp14>SHALL</bcp14> ignore any parameter that is not defi
rget="media_type_def" />. ned in <xref target="media_type_def" format="default"/>.
</t> </t>
<t> <t>
An example SDP mapping for JPEG XS video is as follows: An example SDP mapping for JPEG XS video is as follows:
<figure><artwork><![CDATA[ </t>
<sourcecode type="sdp"><![CDATA[
m=video 30000 RTP/AVP 112 m=video 30000 RTP/AVP 112
a=rtpmap:112 jxsv/90000 a=rtpmap:112 jxsv/90000
a=fmtp:112 packetmode=0;sampling=YCbCr-4:2:2; a=fmtp:112 packetmode=0;sampling=YCbCr-4:2:2;
width=1920;height=1080;depth=10; width=1920;height=1080;depth=10;
colorimetry=BT709;TCS=SDR;RANGE=FULL;TP=2110TPNL colorimetry=BT709;TCS=SDR;RANGE=FULL;TP=2110TPNL
]]></artwork></figure> ]]></sourcecode>
</t> <t>
<t>
In this example, a JPEG XS RTP stream is to be sent to UDP destination In this example, a JPEG XS RTP stream is to be sent to UDP destination
port 30000, with an RTP dynamic payload type of 112 and a media clock port 30000, with an RTP dynamic payload type of 112 and a media clock
rate of 90000 Hz. Note that the "a=fmtp:" line has been wrapped to fit rate of 90000 Hz. Note that the "a=fmtp:" line has been wrapped to fit
this page, and will be a single long line in the SDP file. This example this page and will be a single long line in the SDP file. This example
includes the TP parameter (as specified in <xref target="tsdt" />). includes the TP parameter (as specified in <xref target="tsdt" format="
</t> default"/>).
</section> </t>
<section title="Usage with SDP Offer/Answer Model"> </section>
<t> <section numbered="true" toc="default">
When JPEG XS is offered over RTP using <xref target="RFC3264">SDP in an <name>Usage with SDP Offer/Answer Model</name>
<t>
When JPEG XS is offered over RTP using <xref target="RFC3264" format="d
efault">SDP in an
offer/answer model</xref> for negotiation for unicast usage, the follow ing offer/answer model</xref> for negotiation for unicast usage, the follow ing
limitations and rules apply: limitations and rules apply:
</t> </t>
<t> <dl newline="false" spacing="normal">
<list style="hanging"> <dt/>
<t> <dd>
The "a=fmtp" attribute SHALL be present specifying the required The "a=fmtp" attribute <bcp14>SHALL</bcp14> be present specifying t
parameter "packetmode", and MAY specify any of the he required
optional parameters, as described in <xref target="media_type_def" parameter "packetmode" and <bcp14>MAY</bcp14> specify any of the
/>. optional parameters, as described in <xref target="media_type_def"
</t> format="default"/>.
<t> </dd>
All parameters in the "a=fmtp" attribute indicate sending capabilit <dt/>
ies (i.e. properties of the payload). <dd>
</t> All parameters in the "a=fmtp" attribute indicate sending capabilit
<t> ies (i.e., properties of the payload).
</dd>
<dt/>
<dd>
An answerer of the SDP is required to support all parameters and An answerer of the SDP is required to support all parameters and
values of the parameters provided by the offerer; otherwise, the an values of the parameters provided by the offerer; otherwise, the
swerer answerer <bcp14>SHALL</bcp14> reject the session. It falls on the
SHALL reject the session. It falls on the offerer to use offerer to use values that are expected to be supported by the
values that are expected to be supported by the answerer. If the answerer. If the answerer accepts the session, it
answerer accepts the session, it SHALL reply with the exact same pa <bcp14>SHALL</bcp14> reply with the exact same parameter values
rameters in the "a=fmtp" attribute as they were initially offered.
values in the "a=fmtp" attribute as it was offered. </dd>
</t>
<t>
The same RTP payload type number used in the offer SHOULD be used i
n the answer, as specified in <xref target="RFC3264" />.
</t>
</list>
</t>
</section>
</section>
<section title="IANA Considerations"> <dt/>
<t> <dd>
The IANA is requested to register the media type registration "video/jxsv The same RTP payload type number used in the offer
" <bcp14>SHOULD</bcp14> be used in the answer, as specified in
as specified in <xref target="media_type_def" />. <xref target="RFC3264" format="default"/>.
The media type is also requested to be added to the IANA registry for </dd>
"RTP Payload Format MIME types" &lt;https://www.iana.org/assignments/rtp- </dl>
parameters&gt;. </section>
</t> </section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
IANA has registered the media type registration "video/jxsv"
as specified in <xref target="media_type_def" format="default"/>. The
media type has also been added to the IANA registry for "RTP
Payload Format Media Types" <eref brackets ="angle"
target="https://www.iana.org/assignments/rtp-parameters"/>.
<section title="Security Considerations" anchor="security"> </t>
<t> </section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
RTP packets using the payload format defined in this memo RTP packets using the payload format defined in this memo
are subject to the security considerations discussed in <xref target="RFC are subject to the security considerations discussed in <xref target="RFC
3550" /> 3550" format="default"/>
and in any applicable RTP profile such as <xref target="RFC3551">RTP/AVP< and in any applicable RTP profile such as <xref target="RFC3551" format="
/xref>, default">RTP/AVP</xref>,
<xref target="RFC4585">RTP/AVPF</xref>, <xref target="RFC4585" format="default">RTP/AVPF</xref>,
<xref target="RFC3711">RTP/SAVP</xref>, or <xref target="RFC3711" format="default">RTP/SAVP</xref>, or
<xref target="RFC5124">RTP/SAVPF</xref>. This implies <xref target="RFC5124" format="default">RTP/SAVPF</xref>. This implies
that confidentiality of the media streams is achieved by encryption. that confidentiality of the media streams is achieved by encryption.
</t> </t>
<t>
<t> However, as <xref target="RFC7202" format="default">"Securing the RTP Fra
However, as <xref target="RFC7202">"Securing the RTP Framework: Why RTP mework: Why RTP
Does Not Mandate a Single Media Security Solution"</xref> Does Not Mandate a Single Media Security Solution"</xref>
discusses, it is not an RTP payload format's responsibility to discusses, it is not an RTP payload format's responsibility to
discuss or mandate what solutions are used to meet the basic security discuss or mandate what solutions are used to meet the basic security
goals like confidentiality, integrity, and source authenticity for goals like confidentiality, integrity, and source authenticity for
RTP in general. This responsibility lies on anyone using RTP in an RTP in general. This responsibility lies on anyone using RTP in an
application. They can find guidance on available security mechanisms application. They can find guidance on available security mechanisms
and important considerations in and important considerations in
<xref target="RFC7201">"Options for Securing RTP Sessions"</xref>. <xref target="RFC7201" format="default">"Options for Securing RTP Session
Applications SHOULD use one or more appropriate strong s"</xref>.
Applications <bcp14>SHOULD</bcp14> use one or more appropriate strong
security mechanisms. security mechanisms.
</t> </t>
<t>
<t>
Implementations of this RTP payload format need to take appropriate Implementations of this RTP payload format need to take appropriate
security considerations into account. It is important for the decoder security considerations into account. It is important for the decoder
to be robust against malicious or malformed payloads and ensure th at to be robust against malicious or malformed payloads and ensure that
they do not cause the decoder to overrun its allocated memory or otherwis e they do not cause the decoder to overrun its allocated memory or otherwis e
misbehave. An overrun in allocated memory could lead to arbitrary code misbehave. An overrun in allocated memory could lead to arbitrary code
execution by an attacker. The same applies to the encoder, even though execution by an attacker. The same applies to the encoder, even though
problems in encoders are typically rarer. problems in encoders are typically rarer.
</t> </t>
<t>
<t>
This payload format and the JPEG XS encoding do not exhibit any This payload format and the JPEG XS encoding do not exhibit any
substantial non-uniformity, either in output or in complexity to perform substantial non-uniformity, either in output or in complexity to perform
the decoding operation and thus are unlikely to pose a denial-of-service the decoding operation; thus, they are unlikely to pose a denial-of-servi ce
threat due to the receipt of pathological datagrams. threat due to the receipt of pathological datagrams.
</t> </t>
<t>
<t>
This payload format and the JPEG XS encoding do not contain code that is executable. This payload format and the JPEG XS encoding do not contain code that is executable.
</t> </t>
<t>
<t>
It is important to note that HD or UHDTV JPEG XS-encoded video can have
significant bandwidth requirements (typically more than 1 Gbps for
ultra high-definition video, especially if using high framerate).
This is sufficient to cause potential for denial-of-service if
transmitted onto most currently available Internet paths.
</t>
<t> It is important to note that high-definition (HD) or ultra-high-definitio
n
(UHD) video that is encoded with JPEG XS can have significant bandwidth
requirements (typically more than 1 Gbps for UHD video, especially if
using high framerate). This is sufficient to cause potential for denial
of service if transmitted onto most currently available Internet paths.
</t>
<t>
Accordingly, if best-effort service is being used, users of this Accordingly, if best-effort service is being used, users of this
payload format SHALL monitor packet loss to ensure that the packet payload format <bcp14>SHALL</bcp14> monitor packet loss to ensure that th e packet
loss rate is within acceptable parameters. Packet loss is considered loss rate is within acceptable parameters. Packet loss is considered
acceptable if a TCP flow across the same network path, and acceptable if a TCP flow across the same network path, and
experiencing the same network conditions, would achieve an average experiencing the same network conditions, would achieve an average
throughput, measured on a reasonable timescale, that is not less than throughput, measured on a reasonable timescale, that is not less than
the RTP flow is achieving. This condition can be satisfied by the RTP flow is achieving. This condition can be satisfied by
implementing congestion control mechanisms to adapt the transmission implementing congestion control mechanisms to adapt the transmission
rate (or the number of layers subscribed for a layered multicast rate (or the number of layers subscribed for a layered multicast
session), or by arranging for a receiver to leave the session if the session) or by arranging for a receiver to leave the session if the
loss rate is unacceptably high. loss rate is unacceptably high.
</t> </t>
<t>
<t>
This payload format may also be used in networks that provide This payload format may also be used in networks that provide
quality-of-service guarantees. If enhanced service is being used, quality-of-service guarantees. If enhanced service is being used,
receivers SHOULD monitor packet loss to ensure that the service that receivers <bcp14>SHOULD</bcp14> monitor packet loss to ensure that the se rvice that
was requested is actually being delivered. If it is not, then they was requested is actually being delivered. If it is not, then they
SHOULD assume that they are receiving best-effort service and behave <bcp14>SHOULD</bcp14> assume that they are receiving best-effort service and behave
accordingly. accordingly.
</t> </t>
</section> </section>
<section title="Acknowledgments">
<t>
The authors would like to thank the following people for their
valuable contributions to this memo: Arnaud Germain,
Alexandre Will&egrave;me, Ga&euml;l Rouvroy, Siegfried Foessel, and Jean-
Baptise Lorent.
</t>
</section>
<section title="RFC Editor Considerations">
<t>
Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section.
</t>
<t>
RFC XXXX is to be replaced by the RFC number this specification
receives when published.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** --> </middle>
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries <references anchor="references">
: <name>References</name>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <references>
as shown) <name>Normative References</name>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
If you use the PI option, xml2rfc will, by default, try to find included fil C.2119.xml"/>
es in the same <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
directory as the including file. You can also define the XML_LIBRARY environ FC.3264.xml"/>
ment variable <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
with a value containing a set of directories to search. These can be either FC.3550.xml"/>
in the local <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
filing system or remote ones accessed by http (http://domain/dir/... ).--> FC.3551.xml"/>
<references title="Normative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2 FC.4855.xml"/>
119.xml"?--> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC2119; FC.6838.xml"/>
&RFC3264; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC3550; FC.8083.xml"/>
&RFC3551; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC4855; FC.8085.xml"/>
&RFC6838; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8083; FC.8174.xml"/>
&RFC8085; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8174; FC.8866.xml"/>
&RFC8866;
<reference anchor="ISO21122-1"> <reference anchor="ISO21122-1">
<front> <front>
<title> <title>
Information technology - JPEG XS low-latency lightweight image coding Information technology - JPEG XS low-latency lightweight image coding
system - Part 1: Core coding system system - Part 1: Core coding system
</title> </title>
<author> <author>
<organization>International Organization for Standardization (ISO) - <organization>ISO/IEC</organization>
International Electrotechnical Commission (IEC)</organization> </author>
</author> </front>
<date /> <seriesInfo name="ISO/IEC" value="IS 21122-1"/>
</front> </reference>
<seriesInfo name="ISO/IEC" value="IS 21122-1"/>
</reference> <reference anchor="ISO21122-2">
<reference anchor="ISO21122-2"> <front>
<front> <title>
<title>
Information technology - JPEG XS low-latency lightweight image coding Information technology - JPEG XS low-latency lightweight image coding
system - Part 2: Profiles and buffer models system - Part 2: Profiles and buffer models
</title> </title>
<author> <author>
<organization>International Organization for Standardization (ISO) - <organization>ISO/IEC</organization>
International Electrotechnical Commission (IEC)</organization> </author>
</author> </front>
<date /> <seriesInfo name="ISO/IEC" value="IS 21122-2"/>
</front> </reference>
<seriesInfo name="ISO/IEC" value="IS 21122-2"/>
</reference> <reference anchor="ISO21122-3">
<reference anchor="ISO21122-3"> <front>
<front> <title>
<title>
Information technology - JPEG XS low-latency lightweight image coding Information technology - JPEG XS low-latency lightweight image coding
system - Part 3: Transport and container formats system - Part 3: Transport and container formats
</title> </title>
<author> <author>
<organization>International Organization for Standardization (ISO) - <organization>ISO/IEC</organization>
International Electrotechnical Commission (IEC)</organization> </author>
</author> </front>
<date /> <seriesInfo name="ISO/IEC" value="IS 21122-3"/>
</front> </reference>
<seriesInfo name="ISO/IEC" value="IS 21122-3"/>
</reference> </references>
</references>
<references>
<name>Informative References</name>
<reference anchor="ISO11664-1" target="https://www.iso.org/standard/7416
4.html">
<front>
<title>Colorimetry - Part 1: CIE standard colorimetric observers</ti
tle>
<author>
<organization>ISO/CIE</organization>
</author>
<date year="2019" month="June"/>
</front>
<seriesInfo name="ISO/CIE" value="IS 11664-1:2019"/>
</reference>
<reference anchor="BT.601-5" target="https://www.itu.int/rec/R-REC-BT.60
1-5-199510-S/en">
<front>
<title>Studio encoding parameters of digital television for standard
4:3 and wide screen 16:9 aspect ratios</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="1995" month="October"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.601-5"/>
</reference>
<reference anchor="BT.601-7" target="https://www.itu.int/rec/R-REC-BT.60
1-7-201103-I/en">
<front>
<title>Studio encoding parameters of digital television for standard
4:3 and wide screen 16:9 aspect ratios</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="2011" month="March"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.601-7"/>
</reference>
<reference anchor="BT.709-2" target="https://www.itu.int/rec/R-REC-BT.70
9-2-199510-S/en">
<front>
<title>Parameter values for the HDTV standards for production and in
ternational programme exchange</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="1995" month="October"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.709-2"/>
</reference>
<reference anchor="BT.709-6" target="https://www.itu.int/rec/R-REC-BT.70
9-6-201506-I/en">
<front>
<title>Parameter values for the HDTV standards for production and in
ternational programme exchange</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="2015" month="June"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.709-6"/>
</reference>
<reference anchor="BT.1886-0" target="https://www.itu.int/rec/R-REC-BT.1
886-0-201103-I/en">
<front>
<title>Reference electro-optical transfer function for flat panel di
splays used in HDTV studio production</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="2011" month="March"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.1886-0"/>
</reference>
<reference anchor="BT.2020-2" target="https://www.itu.int/rec/R-REC-BT.2
020-2-201510-I/en">
<front>
<title>Parameter values for ultra-high definition television systems
for production and international programme exchange</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="2015" month="October"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.2020-2"/>
</reference>
<reference anchor="BT.2100-2" target="https://www.itu.int/rec/R-REC-BT.2
100-2-201807-I/en">
<front>
<title>Image parameter values for high dynamic range television for
use in production and international programme exchange</title>
<author>
<organization>ITU-R</organization>
</author>
<date year="2018" month="July"/>
</front>
<seriesInfo name="ITU-R Recommendation" value="BT.2100-2"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3711.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4175.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4585.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5124.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7201.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7202.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8888.xml"/>
<reference anchor="SMPTE157" target="https://ieeexplore.ieee.org/documen
t/7290447">
<front>
<title>SMPTE Recommended Practice - Key and Alpha Signals</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2012" month="November"/>
</front>
<seriesInfo name="SMPTE" value="RP 157:2012"/>
<seriesInfo name="DOI" value="10.1109/ICPST.1998.729044"/>
</reference>
<reference anchor="SMPTE240M" target="https://ieeexplore.ieee.org/docume
nt/7291461?arnumber=7291461">
<front>
<title>SMPTE Standard - For Television - 1125-Line High-Definition
Production Systems - Signal Parameters</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="1999" month="November"/>
</front>
<seriesInfo name="SMPTE" value="ST 240M:1999"/>
<seriesInfo name="DOI" value="10.5594/SMPTE.ST240.1999"/>
</reference>
<reference anchor="SMPTE428-1" target="https://ieeexplore.ieee.org/docum
ent/8709077">
<front>
<title>SMPTE Standard - D-Cinema Distribution Master - Image Charact
eristics</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2019" month="March"/>
</front>
<seriesInfo name="SMPTE" value="ST 428-1:2019"/>
<seriesInfo name="DOI" value="10.5594/SMPTE.ST428-1.2019"/>
</reference>
<reference anchor="SMPTE2065-1" target="https://ieeexplore.ieee.org/docu
ment/9343931">
<front>
<title>SMPTE Standard - Academy Color Encoding Specification (ACES)<
/title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2021" month="January"/>
</front>
<seriesInfo name="SMPTE" value="ST 2065-1:2021"/>
<seriesInfo name="DOI" value="10.5594/SMPTE.ST2065-1.2021"/>
</reference>
<reference anchor="SMPTE2065-3" target="https://ieeexplore.ieee.org/docu
ment/9286953">
<front>
<title>SMPTE Standard - Academy Density Exchange Encoding (ADX) - En
coding Academy Printing Density (APD) Values</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2020" month="November"/>
</front>
<seriesInfo name="SMPTE" value="ST 2065-3:2020"/>
<seriesInfo name="DOI" value="10.5594/SMPTE.ST2065-3.2020"/>
</reference>
<reference anchor="SMPTE2077" target="https://ieeexplore.ieee.org/docume
nt/7290588">
<front>
<title>SMPTE Recommended Practice - Full-Range Image Mapping</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2013" month="November"/>
</front>
<seriesInfo name="SMPTE" value="RP 2077:2013"/>
<seriesInfo name="DOI" value="10.5594/SMPTE.RP2077.2013"/>
</reference>
<reference anchor="SMPTE2110-21" target="https://ieeexplore.ieee.org/doc
ument/8165971">
<front>
<title>SMPTE Standard - Professional Media Over Managed IP Networks:
Traffic Shaping and Delivery Timing for Video</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2017" month="November"/>
</front>
<seriesInfo name="SMPTE" value="ST 2110-21:2017"/>
<seriesInfo name="DOI" value="10.5594/SMPTE.ST2110-21.2017"/>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors would like to thank the following people for their valuable
contributions to this memo: <contact fullname="Sébastien Lugan"/>,
<contact fullname="Arnaud Germain"/>, <contact fullname="Alexandre
Willème"/>, <contact fullname="Gaël Rouvroy"/>, <contact
fullname="Siegfried Foessel"/>, and <contact fullname="Jean-Baptise
Lorent"/>.
</t>
</section>
</back>
<references title="Informative References">
&RFC3711;
&RFC4175;
&RFC4585;
&RFC5124;
&RFC7201;
&RFC7202;
&RFC8888;
<reference anchor="SMPTE-ST2110-21" target="https://doi.org/10.5594/SMPTE.S
T2110-21.2017">
<front>
<title>
SMPTE Standard - Professional Media Over Managed IP Networks: Traffic
Shaping and Delivery Timing for Video
</title>
<author>
<organization>Society of Motion Picture and Television Engineers</org
anization>
</author>
<date year="2017"/>
</front>
<seriesInfo name="SMPTE" value="ST 2110-21:2017"/>
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 173 change blocks. 
1138 lines changed or deleted 1372 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/