draft-ietf-avt-uxp-06.txt   draft-ietf-avt-uxp-07.txt 
Internet Engineering Task Force G. Liebl Internet Engineering Task Force G. Liebl
Internet Draft LNT, Munich Univ. of Internet Draft LNT, Munich Univ. of
Technology Technology
Document: draft-ietf-avt-uxp-06.txt Document: draft-ietf-avt-uxp-07.txt
October 2003 M. Wagner, J. Pandel, October 2004 M. Wagner, J. Pandel,
W. Weng W. Weng
Expires: April 2004 Siemens AG, Munich Expires: April 2005 Siemens AG, Munich
An RTP Payload Format for Erasure-Resilient Transmission of An RTP Payload Format for Erasure-Resilient Transmission of
Progressive Multimedia Streams Progressive Multimedia Streams
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
By submitting this Internet-Draft, I accept the provisions of
Section 3 of RFC 3667
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum Drafts. Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted by other of six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document specifies an efficient way to ensure erasure- This document specifies an efficient way to ensure erasure-
resilient transmission of progressively encoded multimedia resilient transmission of progressively encoded multimedia
sources via RTP using Reed-Solomon (RS) codes together with sources via RTP using Reed-Solomon (RS) codes together with
interleaving. The level of erasure protection can be explicitly interleaving. The level of erasure protection can be explicitly
adapted to the importance of the respective parts in the source adapted to the importance of the respective parts in the source
stream, thus allowing a graceful degradation of application stream, thus allowing a graceful degradation of application
quality with increasing packet loss rate on the network. Hence, quality with increasing packet loss rate on the network. Hence,
this type of unequal erasure protection (UXP) schemes is intended this type of unequal erasure protection (UXP) schemes is intended
to cope with the rapidly varying channel conditions on wireless to cope with the rapidly varying channel conditions on wireless
Liebl,Wagner,Pandel,Weng [Page1]
access links to the Internet backbone. Furthermore, protection of access links to the Internet backbone. Furthermore, protection of
non-progressive multimedia streams is ensured, since equal non-progressive multimedia streams is ensured, since equal
erasure protection (EXP) represents a subset of generic UXP. By erasure protection (EXP) represents a subset of generic UXP. By
applying interleaving and RS codes a payload format is defined, applying interleaving and RS codes a payload format is defined,
which can be easily integrated into the existing framework for which can be easily integrated into the existing framework for
RTP. RTP.
Table of Contents Table of Contents
1. Introduction.................................................2 1. Introduction.................................................2
2. Conventions used in this Document............................3 2. Conventions used in this Document............................4
3. Reed-Solomon Codes...........................................6 3. Preliminaries................................................4
4. Progressive Source Coding....................................7 4. General Structure of UXP Schemes.............................8
5. General Structure of UXP Schemes.............................8 5. RTP payload structure.......................................14
6. Indication of UXP in SDP....................................21
Liebl,Wagner,Pandel,Weng [Page1] 7. Security Considerations.....................................22
6. RTP payload structure.......................................13 8. IANA Considerations.........................................22
7. Indication of UXP in SDP....................................20 9. Application Statement.......................................25
8. Security Considerations.....................................21 10. Intellectual Property Considerations.......................26
9. Application Statement.......................................22 11. References.................................................27
10. Intellectual Property Considerations.......................23 12. Acknowledgments............................................27
11. References.................................................23 13. Author's Addresses.........................................28
12. Acknowledgments............................................24
13. Author's Addresses.........................................24
1. Introduction 1. Introduction
Due to the increasing popularity of high-quality multimedia Due to the increasing popularity of high-quality multimedia
applications over the Internet and the high level of public applications over the Internet and the high level of public
acceptance of existing mobile communication systems, there is a acceptance of existing mobile communication systems, there is a
strong demand for a future combination of these two techniques: strong demand for a future combination of these two techniques:
One possible scenario consists of an integrated communication One possible scenario consists of an integrated communication
environment, where users can set up multimedia connections environment, where users can set up multimedia connections
anytime and anywhere via radio access links to the Internet. anytime and anywhere via radio access links to the Internet.
skipping to change at page 2, line ? skipping to change at page 3, line 6
to the next network element. to the next network element.
However, compared to the rather benign channel characteristics on However, compared to the rather benign channel characteristics on
today's fixed networks, wireless links suffer from severe fading, today's fixed networks, wireless links suffer from severe fading,
noise, and interference conditions in general, thus resulting in noise, and interference conditions in general, thus resulting in
a comparably high residual bit error rate after detection and a comparably high residual bit error rate after detection and
decoding. By use of efficient CRC-mechanisms, these bit errors decoding. By use of efficient CRC-mechanisms, these bit errors
are usually detected with very high probability, and every are usually detected with very high probability, and every
corrupted segment, i.e. which contains at least one erroneous corrupted segment, i.e. which contains at least one erroneous
bit, is discarded to prevent error propagation through the bit, is discarded to prevent error propagation through the
network. But if only one single segment is missing at the network. But if only one single segment is missing at the
reassemble stage, the upper layer IP packet cannot be reassembly stage, the upper layer IP packet cannot be
reconstructed anymore. The result is a significant increase in reconstructed anymore. The result is a significant increase in
packet loss rate at IP level. packet loss rate at IP level.
Since most multimedia applications can only recover from a very Since most multimedia applications can only recover from a very
limited number of lost IP packets, it is vitally necessary to limited number of lost IP packets, it is vitally necessary to
keep packet loss at IP level within a certain acceptable range keep packet loss at IP level within a certain acceptable range
depending on the individual quality-of-service requirements. depending on the individual quality-of-service requirements.
However, due to the delay constraints typically imposed by most However, due to the delay constraints typically imposed by most
audio or video codecs, the use of ARQ-schemes is often prohibited audio or video codecs, the use of ARQ-schemes is often prohibited
both at link level and at transport level. In addition, both at link level and at transport level. In addition,
retransmission strategies cannot be applied to any broadcast or retransmission strategies cannot be applied to any broadcast or
multicast scenarios. Thus, forward erasure correction strategies multicast scenarios. Thus, forward erasure correction strategies
have to be considered, which provide a simple means to have to be considered, which provide a simple means to
reconstruct the content of lost packets at the receiver from the reconstruct the content of lost packets at the receiver from the
redundancy that has been spread out over a certain number of redundancy that has been spread out over a certain number of
consecutive packets. consecutive packets.
There already exist some previous studies and proposals regarding There already exist some previous studies and proposals regarding
erasure-resilient packet transmission [1,8]. Since most of them erasure-resilient packet transmission [RFC2733,Hor99]. Since most
are based on the assumption that all parts in a message block are of them are based on the assumption that all parts in a message
equally important to the receiver, i.e. the respective block are equally important to the receiver, i.e. the respective
application cannot operate on partly complete blocks, they were application cannot operate on partly complete blocks, they were
optimized with respect to assigning equal erasure protection over optimized with respect to assigning equal erasure protection over
the whole message block. However, recent developments both in the whole message block. However, recent developments both in
audio and video coding have introduced the notion of audio and video coding have introduced the notion of
progressively encoded media streams, for which unequal erasure progressively encoded media streams, for which unequal erasure
protection strategies seem to be more promising, as it will be protection strategies seem to be more promising, as it will be
explained in more detail below. Although the scheme defined in explained in more detail below. Although the scheme defined in
[1] is in principle capable of supporting some kind of unequal [RFC2733] is in principle capable of supporting some kind of
erasure protection, possible implementations seem to be quite unequal erasure protection, possible implementations seem to be
complex with respect to the gain in performance. Finally, in [1] quite complex with respect to the gain in performance. Finally,
it is assumed that consecutive RTP packets can have variable in [RFC2733] it is assumed that consecutive RTP packets can have
length, which would cause significant segmentation overhead at variable length, which would cause significant segmentation
the link layer of almost all wireless systems. overhead at the link layer of almost all wireless systems.
This document defines a payload format for RTP, such that This document defines a payload format for RTP, such that
different elements in a progressively encoded multimedia stream different elements in a progressively encoded multimedia stream
can be protected against packet erasures according to their can be protected against packet erasures according to their
respective quality-of-service requirement. The general principle, respective quality-of-service requirement. The general principle,
including the use of Reed-Solomon codes together with an including the use of Reed-Solomon codes together with an
appropriate interleaving scheme for adding redundancy, follows appropriate interleaving scheme for adding redundancy, follows
the ideas already presented in [3], but allows for finer the ideas already presented in [Alb96], but allows for finer
granularity in the structure of the progressive media stream. The granularity in the structure of the progressive media stream. The
proposed scheme is generic in the way that it (1) is independent proposed scheme is generic in the way that it (1) is independent
of the type of media stream, be it audio or video, and (2) can be of the type of media stream, be it audio or video, and (2) can be
adapted to varying transmission quality very quickly by use of adapted to varying transmission quality very quickly by use of
inband-signaling. inband-signaling.
2. Conventions used in this Document 2. Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC-2119.
3. Preliminaries
The purpose of this section is to provide some preliminaries
which are important for understanding the UXP scheme. First, some
definitions used throughout this document are given. Next, Reed-
Solomon Codes are introduced. Finally, progressive source coding
and the resulting properties of progressive bitstreams are
discussed.
3.1 Definitions
The following terms are used throughout this document: The following terms are used throughout this document:
1.) Segment: denotes a link layer transport unit. 1.) Segment: denotes a link layer transport unit.
2.) Segmentation/Reassembly Process: If the size of the 2.) Segmentation/Reassembly Process: If the size of the
transport units at the link layer is smaller than that at transport units at the link layer is smaller than that at
the upper layers, message blocks have to be split up into the upper layers, message blocks have to be split up into
several parts, i.e. segments, which are then transmitted several parts, i.e. segments, which are then transmitted
subsequently over the link. If nothing is lost, the original subsequently over the link. If nothing is lost, the original
message block can be restored at the receiving entity message block can be restored at the receiving entity
(reassembly). (reassembly).
3.) Codec: denotes a functional pair consisting of a source 3.) Codec: denotes a functional pair consisting of a source
encoding unit at the sender and a corresponding source encoding unit at the sender and a corresponding source
decoding unit at the receiver; usually standardized for decoding unit at the receiver; usually standardized for
different media applications like audio or video. different media applications like audio or video.
4.) Media stream: A bitstream which results at the output of an
4.) Media stream: A bitstream. which results at the output of an
encoder for a specific media type, e.g. H.263, MPEG-4 encoder for a specific media type, e.g. H.263, MPEG-4
Visual. Visual.
5.) Progressive media stream: A media stream which can be 5.) Progressive media stream: A media stream which can be
divided into successive elements. The distinct elements are divided into successive elements. The distinct elements are
of different importance to the decoding process and are of different importance to the decoding process and are
commonly ordered from highest to least importance, where the commonly ordered from highest to least importance, where the
latter elements depend on the previous. latter elements depend on the previous.
6.) Progressive source coding: results in a progressive media 6.) Progressive source coding: results in a progressive media
stream. stream.
7.) Reed-Solomon (RS) code: belongs to the class of linear 7.) Reed-Solomon (RS) code: belongs to the class of linear
skipping to change at page 4, line 38 skipping to change at page 5, line 20
corresponding erasure marker can be set at the receiving corresponding erasure marker can be set at the receiving
entity. entity.
12.) Base layer: comprises the first and most important elements 12.) Base layer: comprises the first and most important elements
of the progressive media stream, without which all of the progressive media stream, without which all
subsequent information is useless. subsequent information is useless.
13.) Enhancement layer: comprises one or more sets of the less 13.) Enhancement layer: comprises one or more sets of the less
important subsequent elements of the progressive media important subsequent elements of the progressive media
stream. A specific enhancement layer can be decoded, if and stream. A specific enhancement layer can be decoded, if and
only if the base layer and all previous enhancement layer only if the base layer and all previous enhancement layer
data (of higher importance) are available. data (of higher importance) are available.
14.) Info stream: denotes the bitstream which has to be 14.) Info stream: denotes the bitstream which has to be protected
protected by the UXP scheme. It usually consists of the by the UXP scheme. It usually consists of the media stream
media stream (progressively source encoded or not), which is (progressively source encoded or not), which is arranged
arranged according to a desired syntax (e.g. to achieve an according to a desired syntax (e.g. to achieve an
appropriate framing, see Sect. 6.3 ). In any case, it is appropriate framing, see Sect. 5.4 ). In any case, it is
assumed that every info stream is already octet-aligned assumed that every info stream is already octet-aligned
according to the standard procedures defined in the context according to the standard procedures defined in the context
of the used syntax specifications. of the used syntax specifications.
15.) Info octet: Denotes one element of the info stream. 15.) Info octet: Denotes one element of the info stream.
16.) Transmission block (TB): denotes a memory array of L rows 16.) Transmission block (TB): denotes a memory array of L rows
and n columns. Each row of a TB represents a RS codeword, and n columns. Each row of a TB represents a RS codeword,
whereas each column, together with the respective UXP header whereas each column, together with the respective UXP header
(see 36) in front, forms the payload of a single RTP packet. (see 36) in front, forms the payload of a single RTP packet.
Each TB consists of at least two distinct transmission sub Each TB consists of at least two distinct transmission sub
blocks (TSB, see20): The first L_s rows belong to the blocks (TSB, see20): The first L_s rows belong to the
skipping to change at page 6, line 14 skipping to change at page 6, line 49
present at the start of the payload section of an RTP present at the start of the payload section of an RTP
packet. packet.
34.) X: denotes a currently not used extension field of 1 bit in 34.) X: denotes a currently not used extension field of 1 bit in
the UXP header. the UXP header.
35.) P: is a variable which denotes the number of parity symbols 35.) P: is a variable which denotes the number of parity symbols
per row used to protect the inband signaling of the per row used to protect the inband signaling of the
redundancy profile. redundancy profile.
36.) ceil(.): denotes the ceiling function, i.e. rounding up to 36.) ceil(.): denotes the ceiling function, i.e. rounding up to
the next integer. the next integer.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 3.2 Reed-Solomon Codes
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC-2119.
3. Reed-Solomon Codes
Reed-Solomon (RS) codes are a special class of linear nonbinary Reed-Solomon (RS) codes are a special class of linear nonbinary
block codes, which are known to offer maximum erasure correction block codes, which are known to offer maximum erasure correction
capability with minimum amount of redundancy. capability with minimum amount of redundancy.
An arbitrary t-erasure-correcting (n,k) RS code defined over An arbitrary t-erasure-correcting (n,k) RS code defined over
Galois field GF(q) has the following parameters [2]: Galois field GF(q) has the following parameters [Lin83]:
- Block length: n=q-1 - Block length: n=q-1
- No. of information symbols in a codeword: k - No. of information symbols in a codeword: k
- No. of parity-check symbols in a codeword: n-k=t - No. of parity-check symbols in a codeword: n-k=t
- Minimum distance: d=t+1 - Minimum distance: d=t+1
In what follows, only systematic RS codes over GF(2^8) shall be In what follows, only systematic RS codes over GF(2^8) shall be
considered, i.e. the symbols of interest can be directly related considered, i.e. the symbols of interest can be directly related
to a tuple of eight bits, which is commonly called an octet in to a tuple of eight bits, which is commonly called an octet in
packet transmission. The principle structure of a codeword is packet transmission. The principle structure of a codeword is
shown in Fig. 1. shown in Fig. 1.
skipping to change at page 7, line 4 skipping to change at page 7, line 31
block of n octets block of n octets
<-----------------> <----------------->
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
|&|&|&|&|&|&|&|*|*| |&|&|&|&|&|&|&|*|*|
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
<------------><---> <------------><--->
k=n-t t k=n-t t
(&:info) (*:parity) (&:info) (*:parity)
Fig. 1: Structure of a systematic RS codeword Fig. 1: Structure of a systematic RS codeword
4. Progressive Source Coding
3.3 Progressive Source Coding
The output of an encoder for a specific media type, e.g. H.263 or The output of an encoder for a specific media type, e.g. H.263 or
MPEG-4 Visual is said to be a media stream. If the media stream MPEG-4 Visual is said to be a media stream. If the media stream
consists of several distinct elements, which are of different consists of several distinct elements, which are of different
importance with respect to the quality of the decoding process at importance with respect to the quality of the decoding process at
the receiver, then the media stream is progressive. The the receiver, then the media stream is progressive. The
progressive media stream is often organized in separate layers. progressive media stream is often organized in separate layers.
Hence, there exists at least one layer, often called base layer, Hence, there exists at least one layer, often called base layer,
without which decoding fails at all, whereas all the other without which decoding fails at all, whereas all the other
layers, often called enhancement layers, just help to continually layers, often called enhancement layers, just help to continually
improve the quality. Consequently, the different layers are improve the quality. Consequently, the different layers are
usually contained in the (source-)encoded media stream in usually contained in the (source-)encoded media stream in
decreasing order of importance, i.e. the base layer data is decreasing order of importance, i.e. the base layer data is
followed by the various enhancement layers. followed by the various enhancement layers.
An example can be found in the fine granular scalability modes An example can be found in the fine granular scalability modes
which have been proposed to various standardization bodies like which have been proposed to various standardization bodies like
MPEG, where the resolution of the scaling process in the MPEG, where the resolution of the scaling process in the
progressive source encoder is as low as one symbol in the progressive source encoder is as low as one symbol in the
enhancement layer [4]. Another example is given by data enhancement layer [Li01]. Another example is given by data
partitioning which can be applied to the ITU/MPEG H.26L standard partitioning which can be applied to the ITU/MPEG H.264/AVC
[5], MPEG-4, and H.263++. Also, the existence of I,P, and B standard [Bla00], MPEG-4, and H.263++. Also, the existence of
frames in streams which comply with standards like MPEG-2 can be I,P, and B frames in streams which comply with standards like
interpreted as progressive. MPEG-2 can be interpreted as progressive.
From the above definition, it is quite obvious that the most From the above definition, it is quite obvious that the most
important base layer data must be protected as strongly as important base layer data must be protected as strongly as
possible against packet loss during transmission. However, the possible against packet loss during transmission. However, the
protection of the enhancement layers can be continually lowered, protection of the enhancement layers can be continually lowered,
since a loss at these stages has only minor consequences for the since a loss at these stages has only minor consequences for the
decoding process. Thus, by using a suitable unequal erasure decoding process. Thus, by using a suitable unequal erasure
protection strategy across a progressive media stream, the protection strategy across a progressive media stream, the
overhead due to redundancy is reduced. Furthermore, if channel overhead due to redundancy is reduced. Furthermore, if channel
conditions get worse during transmission, only more and more conditions get worse during transmission (resulting in a higher
enhancement layers are lost, i.e. a graceful degradation in number of corrupt segments and thus higher IP packet loss rate),
application quality at the receiver is achieved [6]. only more and more enhancement layers are lost, i.e. a graceful
degradation in application quality at the receiver is achieved
[Bur99].
Nevertheless, it should be mentioned that the specific structure Nevertheless, it should be mentioned that the specific structure
of the media stream strongly depends on the actual media codec in of the media stream strongly depends on the actual media codec in
use and does not always provide suitable mechanisms for transport use and does not always provide suitable mechanisms for transport
over data networks, like framing (see also Sect. 6.3 ). In order over data networks, like framing (see also Sect. 5.4 ). In order
to keep the description of the unequal erasure protection to keep the description of the unequal erasure protection
strategy in Sect. 5 as general as possible, the final bitstream strategy in Sect. 4 as general as possible, the final bitstream
which has to be protected by the proposed UXP scheme will be which has to be protected by the proposed UXP scheme will be
called "info stream" in the following. Furthermore, it is assumed called "info stream" in the following. Furthermore, it is assumed
that every info stream is already octet-aligned according to the that every info stream is already octet-aligned according to the
standard procedures defined in the context of the used syntax standard procedures defined in the context of the used syntax
specifications. specifications.
5. General Structure of UXP Schemes 4. General UXP Concept
In this section, the principle features of the proposed UXP In this section, the principle features of the proposed UXP
scheme are described with a special focus on the protection and scheme are described with a special focus on the protection and
reconstruction procedure which is applied to the info stream. In reconstruction procedure which is applied to the info stream. In
addition, the behavior of the sender and receiver is specified as addition, the behavior of the sender and receiver is specified as
far as it concerns the reconstruction of the info stream. far as it concerns the reconstruction of the info stream.
However, the complete UXP payload structure, including the However, the complete UXP payload structure, including the
additional UXP header, is described in Sect. 6. additional UXP header, is described in Sect. 5.
The reason for using the term "info stream" as well as the The reason for using the term "info stream", as well as the
details of the construction are described in Sect. 6.3 . For now, details of the construction, are described in Sect. 5.4 . For
we assume that we have an info stream which has to be protected. now, we assume that we have an info stream which has to be
protected.
4.1 Transmission Block Structure
Fig. 1 already illustrated the structure of a systematic RS Fig. 1 already illustrated the structure of a systematic RS
codeword, which shall be represented by a single row with n codeword, which shall be represented by a single row with n
successive symbols that contain the information and the parity successive symbols that contain the information and the parity
octets. This structure shall now be extended by forming a octets. This structure shall now be extended by forming a
transmission block (TB) consisting of L codewords of length n transmission block (TB) consisting of L codewords of length n
octets each, which amounts to a total of L rows and n columns octets each, which amounts to a total of L rows and n columns
[7]: Each column, together with the respective UXP header in [Lie99]: Each column, together with the respective UXP header in
front, shall represent the payload of an RTP packet, i.e. the front, shall represent the payload of an RTP packet, i.e. the
whole data of a TB is transmitted via a sequence of n RTP packets whole data of a TB is transmitted via a sequence of n RTP packets
all carrying a payload of length (L+2) octets (UXP header all carrying a payload of length (L+2) octets (UXP header
included). included).
Each TB usually consists of two or more horizontal sub blocks, Each TB usually consists of two or more horizontal sub blocks,
the so-called transmission sub blocks (TSB), as can be seen in the so-called transmission sub blocks (TSB), as can be seen in
Fig. 2: The first L_s rows always belong to the signaling TSB, Fig. 2: The first L_s rows always belong to the signaling TSB,
which is used to convey the actual redundancy profile in the data which is used to convey the actual redundancy profile in the data
part to the receiver (see 6.4.). The following L_d=(L-L_s) rows part to the receiver (see 5.5.). The following L_d=(L-L_s) rows
belong to one or more data TSBs, which contain the interleaved belong to one or more data TSBs, which contain the interleaved
and RS encoded info stream, as will be described below. and RS encoded info stream, as will be described below.
Transmission Block (TB) Transmission Block (TB)
/\ +-+-+-+-+-+-+-+-+-+ /\ /\ +-+-+-+-+-+-+-+-+-+ /\
| | signaling TSB | | L_s octets | | signaling TSB | | L_s octets
| +-+-+-+-+-+-+-+-+-+ \/ | +-+-+-+-+-+-+-+-+-+ \/
| | | /\ /\ | | | /\ /\
| + data TSB #1 + | L_d(1) octets | | + data TSB #1 + | L_d(1) octets |
skipping to change at page 9, line 30 skipping to change at page 10, line 16
| | . | . | | | . | . |
| +-+-+-+-+-+-+-+-+-+ /\ | | +-+-+-+-+-+-+-+-+-+ /\ |
| | data TSB #z | | L_d(z) octets | | | data TSB #z | | L_d(z) octets |
\/ +-+-+-+-+-+-+-+-+-+ \/ \/ \/ +-+-+-+-+-+-+-+-+-+ \/ \/
<-----------------> <----------------->
n packets n packets
Fig. 2: General structure of a TB Fig. 2: General structure of a TB
Since the UXP procedure is mainly applied to the data TSBs, it Since the UXP procedure is mainly applied to the data TSBs, it
will be described next, whereas the content and syntax of the will be described next, whereas the content and syntax of the
signaling TSB will be defined in section 6.4. signaling TSB will be defined in section 5.5.
4.2 TB Fill Procedure
For means of simplification, only one single data TSB will be For means of simplification, only one single data TSB will be
assumed throughout the following explanation of the encoding and assumed throughout the following explanation of the encoding and
decoding procedure. However, an extension to more than one data decoding procedure. However, an extension to more than one data
TSB per TB is straightforward, and will be shown in section 6.5. TSB per TB is straightforward, and will be shown in section 5.6.
As depicted in Fig. 3, the rows of a transmission sub block shall In the following description, we need an info stream which is
filled into a TSB. In order to make clear how the filling works
in detail, we denote the octets of a stream as described in Fig.
3.
Octet pos: 0 1 2 3 ... 10 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Octet |x0|x1|x2|x3|x4|x5|x6|x7|x8|x9|xA|xB|xC|xD|xE|xF|
Octet pos:16 ... .. 31
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Octet |xG|xH|...................................|xU|xV|
Octet pos: 32 44
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
Octet |xW|xX|xY|xZ|y0|y1|..................y8|
Figure 3: Exemplary info stream
This means, for example, that the octet at position 10 in the
info stream is denoted by xA. The info stream is progressive,
which means that the octets at the beginning of the stream are
more important than the octets later in the stream.
As depicted in Fig. 4, the rows of a transmission sub block shall
be assembled into T+1 different classes EPC_i, where i=0...T, be assembled into T+1 different classes EPC_i, where i=0...T,
such that each class contains exactly R_i=|EPC_i| consecutive such that each class contains exactly R_i=|EPC_i| consecutive
rows of the matrix, where the R_i have to satisfy the following rows of the matrix, where the R_i have to satisfy the following
relationship: relationship:
R_0+R_1+...+R_T=L_d R_0+R_1+...+R_T=L_d
Data Transmission Sub Block (data TSB) Data Transmission Sub Block (data TSB)
T T
<-------> <------->
/\ +-+-+-+-+-+-+-+-+-+ /\ /\ +--+--+--+--+--+--+--+--+--+ /\
| |&|&|&|&|&|*|*|*|*| | | |x0|x1|x2|x3|x4|* |* |* |* | |
| +-+-+-+-+-+-+-+-+-+ | R_T=3 | +--+--+--+--+--+--+--+--+--+ | R_T=3
| |&|&|&|&|&|*|*|*|*| | | |x5|x6|x7|x8|x9|* |* |* |* | |
| +-+-+-+-+-+-+-+-+-+ | | +--+--+--+--+--+--+--+--+--+ |
L_d octets | |&|&|&|&|&|*|*|*|*| \/ L_d octets | |xA|xB|xC|xD|xE|* |* |* |* | \/
per packet | +-+-+-+-+-+-+-+-+-+ /\ per packet | +--+--+--+--+--+--+--+--+--+ /\
| |%|%|%|%|%|%|*|*|*| | R_(T-1)=1 | |xF|xG|xH|xI|xJ|xK|* |* |* | | R_(T-1)=1
| +-+-+-+-+-+-+-+-+-+ \/ | +--+--+--+--+--+--+--+--+--+ \/
| |$|$|$|$|$|$|$|*|*| . | |xL|xM|xN|xO|xP|xQ|xR|* |* | .
| +-+-+-+-+-+-+-+-+-+ . | +--+--+--+--+--+--+--+--+--+ .
| |!|!|!|!|!|!|!|!|*| . | |xS|xT|xU|xV|xW|xX|xY|xZ|* | .
| +-+-+-+-+-+-+-+-+-+ /\ | +--+--+--+--+--+--+--+--+--+ /\
| |#|#|#|#|#|#|#|#|#| | R_0=1 | |y0|y1|y2|y3|y4|y5|y6|y7|y8| | R_0=1
\/ +-+-+-+-+-+-+-+-+-+ \/ \/ +--+--+--+--+--+--+--+--+--+ \/
<-----------------> <----------------->
n packets n packets
&,%,$,!,# : info octets belonging to a certain info stream in x#,y# : info octets belonging to the info stream defined in Fig.
decreasing order of importance 3
* : parity octets gained from Reed-Solomon coding * : parity octets gained from Reed-Solomon coding
Fig. 3: General structure for coding with unequal erasure
Fig. 4: General structure for coding with unequal erasure
protection protection
Furthermore, all rows in a particular class EPC_i shall contain Furthermore, all rows in a particular class EPC_i shall contain
exactly the same number of parity octets, which is equal to the exactly the same number of parity octets, which is equal to the
index i of the class. For each row in a certain class EPC_i, the index i of the class. For each row in a certain class EPC_i, the
same (n,n-i) RS code shall be applied. same (n,n-i) RS code shall be applied.
As can be observed from Fig. 3, class EPC_T contains the largest As can be observed from Fig. 4, class EPC_T contains the largest
number of parity octets per row, i.e. offers the highest erasure number of parity octets per row, i.e. offers the highest erasure
protection capability in the block. Consequently, the most protection capability in the block. Consequently, the most
important element in the info stream must be assigned to class important elements in the info stream must be assigned to class
EPC_T, where the value of T should be chosen according to the EPC_T, where the value of T should be chosen according to the
desired outage threshold of the application given a certain desired outage threshold of the application given a certain
packet erasure rate on the link. packet erasure rate on the link.
All other classes EPC_(T-1)...EPC_0 shall be sequentially filled All other classes EPC_(T-1)...EPC_0 shall be sequentially filled
with the remaining elements of the info stream in decreasing with the remaining elements of the info stream in decreasing
order of importance, where the optimal choice for the size of order of importance as follows: The info stream is filled into
each class (0 or more rows), i.e. the structure of the redundancy the TSB column by column, from left to right, and line by line,
profile, should depend on the quality-of-service requirements for from the upper lines to the lowest line. The result of this
the various (progressively-encoded) layers. procedure is shown in Fig 4.
The following set of rules contains a compact description of all
the operations that must be performed for each transmission
block:
1.) The total number of columns n of the TB shall be chosen
according to the actual delay constraints of the application.
2.) Next, the expected number of rows reserved for the signaling In the following, we describe a set of rules containing a compact
TSB has to selected, which limits the data TSB to L_d=(L-L_s) description of all the operations that must be performed for each
rows. transmission block at the sender and receiver.
3.) The maximum erasure correction capability T in the data TSB
should be chosen according to the desired outage threshold of the 4.3 UXP Sender Rules
application given the actual packet erasure rate on the link.
4.) The redundancy profile for the rest of the data TSB should 1) The total number of columns n of the TB shall be chosen
depend on the size and number of the various layers in the info according to the actual delay constraints of the application.
stream, as well as the desired probability of successful decoding 2) The maximum erasure correction capability T and the R_i in the
for each of them (quality-of-service requirement). data TSB should be chosen according to the desired outage
5.) Any suitable optimization algorithm may be used for deriving threshold of the application given the actual packet erasure
an adequate redundancy profile. However, the result has to rate on the link and the properties of the info streams.
However, the resulting number of TSB rows,
L_d=R_0+R_1+...+R_T, should be kept in mind since it has major
influence on the packet size of the resulting RTP packets (cf.
Sec.55555555 55).
3) Any suitable optimization algorithm may be used for deriving
adequate values for T and all R_i. However, the result has to
satisfy the following constraints: satisfy the following constraints:
a) All available info octet positions in the data TSB have to be a. All available info octet positions in the data TSB have
completely filled. If the info stream is too short for a desired to be completely filled. If the info stream is too short
profile, media stuffing may be applied to the empty info octet for a desired profile, media stuffing may be applied to
positions at the end of the data TSB by appending a sufficient the empty info octet positions at the end of the data TSB
number of octets (with arbitrary value, e.g. 0x00). The actual by appending a sufficient number of stuffing octets. The
number of stuffing symbols per data TSB is then signaled via the stuffing octets MUST have the value 0x00. The actual
respective stuffing indicator (see Sect. 6.4.). However, before number of stuffing symbols per data TSB is then signaled
resorting to any stuffing, it should be checked whether it is via the respective stuffing indicator (see Sect. 5.5.).
possible to strengthen the protection of certain rows instead, b. The info stream SHOULD be fully contained within the data
thus improving the overall robustness of the decoding process. TSB (unless cutting it off at a specific point is
b) The info stream SHOULD be fully contained within the data TSB explicitly allowed by the properties of the info stream).
(unless cutting it off at a specific point is explicitly allowed 4) For each nonempty class EPC_i, i=T...0, in the data TSB, the
by the properties of the info stream).
c) The number of required descriptors and stuffing indicators
(see section 6.4.) to signal the profile SHALL NOT exceed the
space initially reserved for them in the signaling TSB.
Constraints a) and b) should be already incorporated in the
optimization algorithm. However, if constraint c) is not met, the
data TSB has to be reduced by one row in favor of the signaling
TSB to accommodate more space for the descriptors and stuffing
indicators, i.e. steps 2-5 have to be repeated until a valid
redundancy profile has been obtained.
6.) For each nonempty class EPC_i, i=T...0, in the data TSB, the
following steps have to be performed: following steps have to be performed:
a) All rows of this specific class SHALL be filled from left to a. All rows of this specific class SHALL be filled from left
right and top to bottom with data octets of the info stream. to right and top to bottom with data octets of the info
b) For each row in the class, the required i parity-check octets stream as shown in Fig. 4.
are computed from the same set of codewords of an (n,n-i) RS b. For each row in the class, the required i parity-check
code, and filled in the empty positions at the end of each row. octets are computed from the same set of codewords of an
Thus, every row in the class constitutes a valid codeword of the (n,n-i) RS code, and filled in the empty positions at the
chosen RS code. end of each row. Thus, every row in the class constitutes
a valid codeword of the chosen RS code.
7.) After having filled the whole data TSB with information and 5) After having filled the whole data TSB with information and
parity octets, the redundancy profile is mapped to the signaling parity octets, the redundancy profile is mapped to the
TSB as described in section 6.4. signaling TSB as described in section 5.5.
8.) Each column of the resulting TB is now read out octet-wise 6) Each column of the resulting TB is now read out octet-wise
from top to bottom and, together with the respective UXP header from top to bottom and, together with the respective UXP
(see section 6.2.) in front, is mapped onto the payload section header (see section 5.2) in front, is mapped onto the payload
of one and only one RTP packet. section of one and only one RTP packet.
7) The n resulting RTP packets SHALL be transmitted consecutively
to the remote host, starting with the leftmost one.
9.) The n resulting RTP packets SHALL be transmitted 4.4 UXP Receiver Rules
consecutively to the remote host, starting with the leftmost one.
10.) At the corresponding protocol entity at the remote host, the 1) At the corresponding protocol entity at the remote host, the
payload (without the UXP header) of all successfully received RTP payload (without the UXP header) of all successfully received
packets belonging to the same sending TB SHALL be filled into a RTP packets belonging to the same sending TB SHALL be filled
similar receiving TB column-wise from top to bottom and left to into a similar receiving TB column-wise from top to bottom and
right. left to right.
11.) For every erased packet of a received TB, the respective 2) For every erased packet of a received TB, the respective
column in the TB shall be filled with a suitable erasure marker. column in the TB SHALL be filled with a suitable erasure
12.) Before any other operations can be performed, the redundancy marker.
profile has to be restored from the signaling TSB according to 3) Before any other operations can be performed, the redundancy
the procedure defined in Sect. 6.4.. If the attempt fails because profile MUST be restored from the signaling TSB according to
of too many lost packets, the whole TB SHALL be discarded and the the procedure defined in Sect. 5.5.. If the attempt fails
receiving entity should wait for the next incoming TB. because of too many lost packets, the whole TB SHALL be
13.) If the attempt to recover the redundancy profile has been discarded and the receiving entity should wait for the next
successful, a decoding operation shall be performed for each row incoming TB.
of the data TSB by applying any suitable algorithm for erasure 4) If the attempt to recover the redundancy profile has been
decoding. successful, a decoding operation SHALL be performed for each
14.) For all rows of the data TSB for which the decoding row of the data TSB by applying any suitable algorithm for
operation has been successful, the reconstructed data octets are erasure decoding.
read out from left to right and top to bottom, and appended to 5) For all rows of the data TSB for which the decoding operation
the reconstructed version of the info stream. has been successful, the reconstructed data octets are read
out from left to right and top to bottom, and appended to the
reconstructed version of the info stream.
4.5 Protection Properties of UXP
One can easily realize that the above rules describe an One can easily realize that the above rules describe an
interleaver, i.e. at the sender a single codeword of a TB is interleaved coding scheme, i.e. at the sender a single codeword
spread out over n successive packets. Thus, each codeword of a of a TB is spread out over n successive packets. Thus, each
transmitted TB experiences the same number of erasures at exactly codeword of a transmitted TB experiences the same number of
the same positions. erasures at exactly the same positions.
Two important conclusions can be drawn from this: Two important conclusions can be drawn from this:
a) Since the same RS code is applied to all rows contained in a a) Since the same RS code is applied to all rows contained in a
specific class, either all of them can be correctly decoded or specific class, either all of them can be correctly decoded or
none. Hence, there exist no partly decodable classes at the none. Hence, there exist no partly decodable classes at the
receiver. receiver.
b) If decoding is successful for a certain class EPC_i, all the b) If decoding is successful for a certain class EPC_i, all the
classes EPC_(i+1)...EPC_T can also be decoded, since they are classes EPC_(i+1)...EPC_T can also be decoded, since they are
protected by at least one more parity octet per row. Together protected by at least one more parity octet per row. Together
with rule 6, it is therefore always ensured, that in case a with rule 6, it is therefore always ensured, that in case a
decodable enhancement layer exists, all other layers it depends decodable enhancement layer exists, all other layers it depends
on can also be reconstructed! on can also be reconstructed!
4.6 Description of the Redundancy Profile by Erasure Protection
Vectors
Given the maximum erasure protection value T, the redundancy Given the maximum erasure protection value T, the redundancy
profile for a data TSB of size (L_d x n) shall be denoted by a profile for a data TSB of size (L_d x n) SHALL be denoted by a
so-called erasure protection vector EPV of length (T+1), where so-called erasure protection vector EPV of length (T+1), where
EPV:=(R_0,R_1,...,R_(T-1),R_T) EPV:=(R_0,R_1,...,R_(T-1),R_T)
From the above definition, it is easy to realize that the trivial From the above definition, it is easy to realize that the trivial
cases of no erasure protection and EXP are a subset of UXP: cases of no erasure protection and EXP are a subset of UXP:
a) no erasure protection at all: all application data is mapped a) no erasure protection at all: all application data is mapped
onto onto
class EPC_0, i.e. EPV=(L_d,0,0,...,0). class EPC_0, i.e. EPV=(L_d,0,0,...,0).
b) EXP: all application data is mapped onto class EPC_T, i.e. b) EXP: all application data is mapped onto class EPC_T, i.e.
EPV=(0,0,...,0,R_T=L_d). EPV=(0,0,...,0,R_T=L_d).
Hence, the UXP payload format can also be used with info streams
Hence, the UXP payload format also can be used with info streams
which are non progressive. which are non progressive.
6. RTP payload structure 5. RTP payload structure
This section is organized as follows. First, the specific This section is organized as follows: First, the specific
settings in the RTP header are shown. Next, the RTP payload settings in the RTP header are shown. Next, the RTP payload
header for UXP (the so-called UXP header) is specified. After header for UXP (the so-called UXP header) is specified. After
that, the structure of the bitstream which is protected by UXP, that, the structure of the bitstream which is protected by UXP,
the so-called info stream, is discussed. Finally, the in-band the so-called info stream, is discussed. Finally, the in-band
signaling of the erasure protection vector is introduced. signaling of the erasure protection vector is introduced.
For every packet, the UXP payload is formed by reading out a For every packet, the UXP payload is formed by reading out a
column of the TB and prefixing it with the UXP header. Thus, an column of the TB and prefixing it with the UXP header. Thus, a
UXP-compliant RTP packet looks as follows: UXP-compliant RTP packet looks as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|RTP Header| UXP Header| one column of the TB | |RTP Header| UXP Header| one column of the TB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
6.1 Specific Settings in the RTP Header 5.1 Specific Settings in the RTP Header
The timestamp of each RTP packet is set to the sampling time of The timestamp of each RTP packet SHALL be set to the sampling
the first octet of the progressive media stream in the timestamp of the first octet of the progressive media stream in
corresponding TB. If several data TSBs are included in one TB, the corresponding TB. The clock rate MUST be the same as defined
the sampling time of data TSB #1 is relevant. This results in the in the RTP payload format for the progressive media stream.
If several data TSBs are included in one TB, the sampling
timestamp of data TSB #1 SHALL be relevant. This results in the
TS value being the same for all RTP packets belonging to a TS value being the same for all RTP packets belonging to a
specific TB. specific TB.
The payload type is of dynamic type, and obtained through out-of- The payload type SHALL be of dynamic type, and obtained through
band signaling similar to [1]. End systems, which cannot out-of-band signaling similar to [RFC2733]. End systems, which
recognize a payload type, must discard it. cannot recognize a payload type, MUST discard it.
The marker bit is set to 1 in the last packet of a TB; otherwise, The marker bit SHOULD be set to 1 in the last packet of a TB;
its value is 0. otherwise, its value SHOULD be 0.
All other fields in the RTP header are set to those values
proposed for regular multimedia transmission using the RTP-format
of the media stream which is protected by UXP, e.g for MPEG-4
Visual as specified in RFC 3016.
6.2. Structure of the UXP Header 5.2 Structure of the UXP Header
The UXP header shall consist of 2 octets, and is shown in Fig. 4: The UXP header SHALL consist of 2 octets, and is shown in Fig. 5:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| block PT | block length n| |X| block PT | TB indicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 4: Proposed UXP header Fig. 5: Proposed UXP header
The fields in the UXP header are defined as follows: The fields in the UXP header are defined as follows:
- X (bit 0): extension bit, reserved for future enhancements, - X (bit 0): extension bit, reserved for future enhancements,
currently not in use -> default value: 0 currently not in use -> default value: 0
- block PT (bits 1-7): regular RTP payload type to indicate the - block PT (bits 1-7): regular RTP payload type to indicate the
media type contained in the info stream media type contained in the info stream
- block length n (bits 8-15): indicates total number of RTP - TB indicator (bits 8-15): This field indicates the size and
- packets position of one TB within a stream of RTP-packets. The
resulting from one TB (which equals interpretation depends on the actual RTP sequence number of this
the number of columns of the TB) packet. We denote the TB this packet belongs to as the current
TB. Then there are two cases:
1) If the sequence number is even, it indicates the total
number of RTP packets within the current TB (which equals
the number of columns of the current TB).
2) Otherwise, it indicates the sequence number of the first
RTP packet of the current TB. Since it is only one octet,
it contains the least significant octet of the sequence
number.
The syntax of the info stream which is protected by UXP is The syntax of the info stream which is protected by UXP is
specified by the RTP payload type field contained in the UXP specified by the RTP payload type field contained in the UXP
header. The details of the info stream are described in Sec. 6.3 header. The details of the info stream are described in Sec. 5.4
For example, payload type H.263 means that the info stream .
conforms to the specifications of the RTP profile for H.263 and Based on the RTP sequence number, the marker bit, and the TB
does not represent the "raw" H.263 media stream produced by an indicator in each UXP header, the receiving entity is able to
H.263 encoder. recognize both TB boundaries and the actual position of packets
However, UXP can also be applied to the "raw" media stream (in (both received and lost ones) in the TB. An example how this can
case it is already octet-aligned), if this can be signaled to the be done is given in the next subsection.
receiver via other means, e.g. by use of H.245 or SDP.
Based on the RTP sequence number, the marker bit, and the
repetition of the block length n in each UXP header, the
receiving entity is able to recognize both TB boundaries and the
actual position of packets (both received and lost ones) in the
TB.
6.3 Framing and Timing Mechanism in UXP: The Info Stream 5.3 Usage of UXP- and RTP-Header at the Receiver
As described in Sect. 5, UXP creates its own packetization scheme This subsection describes how the UXP- and RTP-headers can be
used to reconstruct a TB.
We assume that the receiver knows about the sequence number of
the first RTP packet within a TB, i.e. the left column, and the
width of the TB. Then it is easy to find out the column in which
the payload of an RTP packet has to be inserted only by
considering the RTP sequence number.
However, the receiver does not know this in advance, since the TB
width can be changed each time a new TB is sent. In addition, the
RTP session starts with a random sequence number. Therefore, even
if the TB width is known at the beginning, the receiver does not
know whether the first packets where lost or not. It is then
wrong to interpret the first received packet as the first packet
in the TB.
Therefore, the comination of UXP header, RTP timestamp, and
marker bit will help the receiver to recover TB synchronization.
5.4 Framing and Timing Mechanism in UXP: The Info Stream
As described in Sect. 4, UXP creates its own packetization scheme
by interleaving. The regular framing and timing structure of RTP by interleaving. The regular framing and timing structure of RTP
is therefore destroyed. This section describes which kind of is therefore destroyed. This section describes which kind of
problems arise with interleaving and how they can be solved. This problems arise with interleaving and how they can be solved. This
finally leads to the specification of the info stream. finally leads to the specification of the info stream.
The timestamp of an RTP packet usually describes the sampling The timestamp of an RTP packet usually describes the sampling
time of the first octet included in the RTP data packet. This is time of the first octet included in the RTP data packet. This is
in principle also true for UXP RTP packets. According to the time in principle also true for UXP RTP packets. According to the time
stamp definition in Sect. 6.1 every packet contains the stamp definition in Sect. 5.1 every UXP RTP packet contains as
timestamp of the sampling time of the first octet in the timestamp the sampling time of the first octet in the
corresponding TB. Therefore, all packets which belong to one TB corresponding TB. Therefore, all packets which belong to one TB
contain the same timestamp. This can lead to problems since due contain the same RTP timestamp. This can lead to problems since
to the theoretical size limit of a TB (the limit for the number due to the theoretical size limit of a TB (the limit for the
of columns is 256, and the limit for the number of rows is the number of columns is 256, and the limit for the number of rows is
maximum packet size), it can contain data from different sampling the maximum packet size), it can contain data from different
time instances, e.g. several video frames. Then the timing sampling time instances, e.g. several video frames. Then the
information of the later frames has to be determined from the timing information of the later frames has to be determined from
media stream itself and not from the RTP timestamp. the media stream itself and not from the RTP timestamp.
A second problem arising with interleaving is that the framing A second problem arising with interleaving is that the framing
mechanism of RTP is not supported. Consider a media encoder, mechanism of RTP is not supported. Since the payload of a single
which does not create a fully decodable bitstream, e.g. H.26L RTP-packet does not contain individually decodable payload, but
with the video coding layer (VCL) and network adaptation layer rather the whole stream is reconstructed from a full TB, the UXP
(NAL) concept [9]. In this concept the VCL creates slices which RTP packets can not be used to provide information about the
are prepared for transmission over several networks at the NAL. start of different access units within the octet stream.
Consequently, in case of RTP transmission, header information
which allows to decode the slices is included only in the RTP
packets. Thus, to fill an UXP TB with the "raw" media stream from
the VCL can lead, even without packet losses, to a non-decodable
stream.
The framing problem can be solved in two ways:
One solution could be to use the RTP payload specification of a
given media stream to create a bitstream with an appropriate
framing, resulting in the so-called info stream. For example, to
create an H.263 info stream, the following steps are necessary:
1.) Generate an H.263-compliant media stream, i.e. take a slice
or a video frame directly from the H.263 encoder.
2.) Apply the H.263 payload specification (e.g. RFC 2429) to
create the RTP payload for only one packet.
3.) Insert the latter row by row into one data TSB.
It is possible to apply the procedure mentioned above several
times for different data TSBs (see Sect. 6.5.). Due to the in-
band signaling, it is possible to determine the beginning and end
of every TSB without parsing the whole TB. This allows a fast
decomposition of the TB into the different TSBs.
Another solution of the framing problem would be to rely on the
framing mechanism of the media stream. This is, for example,
possible for media streams which contain start codes.
The timing problem can be solved in two ways.
One solution is to comply with the RTP payload specification of
the media stream. If the specification allows to put into one
packet octets which belong to different sampling times, this
should also be allowed for a TB.
The second solution for the timing problem is to rely on the
timing information contained in the media stream itself, if
available.
Therefore, there are two different modes for framing:
1.) RTP payload framing (if an RTP payload specification exists
for the media stream),
2.) pure media stream framing (if framing is contained in the
media stream),
and two different modes for timing: The framing and time problem can be solved in many ways:
1.) timing rules of the RTP payload specification for the media
stream,
2.) timing information within the media stream.
All combinations of timing and framing modes are possible, but One solution of the problem would be to rely on the framing and
framing mode 1 and timing mode 1 represent the default mode of timing mechanism of the elementary media stream. This is, for
operation for UXP. The use of other timing and framing modes has example, possible for media streams which contain start codes and
to be signaled by non RTP means. information about the frame rate.
The info stream is thus defined by the media stream together with A second solution could be to define a specific framing mechanism
framing and timing rules. for the info stream similar to [Laz04] and extend it by timing
In the following, some examples will be given: information. A third possibility is to insert the RTP packets of
1.) The info stream for MPEG-4 Visual according to RFC 3016 is a media directly into a TB
the pure MPEG-4 compliant media stream, since RFC 3016
specifies (in case of video) to take the MPEG-4 compliant
video stream as payload.
2.) The info stream for H.263+ can be created according to RFC
2429 as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|H.263+ payload| H.263+ compliant stream (possibly changed with|
|header | respect to RFC 2429) containing a slice/frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This info stream is inserted into one single data TSB. In this specification, we consider only the first solution, i.e.
If necessary, for example, if the slices are too short to achieve to rely on the timing in the elementary media stream. Other
a reasonable TB size, several info streams can be inserted in one solutions have to be defined as extensions of this specification.
TB by concatenating several data TSBs to a single TB (see Sect. Therefore, an info-stream in this specification SHALL be defined
6.5.). as an elementary media stream which provides timing and framing.
6.4. In-band Signaling of the Structure of the Redundancy Profile 5.5. In-band Signaling of the Structure of the Redundancy Profile
To enable a dynamic adaptation to varying link conditions, the To enable a dynamic adaptation to varying link conditions, the
actual redundancy profile used in the data TSB as well as the actual redundancy profile used in the data TSB as well as the
beginning and end of a TSB must be signaled to the receiving beginning and end of a TSB must be signaled to the receiving
entity. Since out-of-band signaling either results in excessive entity. Since out-of-band signaling either results in excessive
additional control traffic, or prevents quick changes of the additional control traffic, or prevents quick changes of the
profile between successive TBs, an in-band signaling procedure is profile between successive TBs, an in-band signaling procedure is
desired. desired.
Since without knowledge of the correct redundancy profile, the Since without knowledge of the correct redundancy profile, the
decoding process cannot be applied to any of the erasure decoding process cannot be applied to any of the erasure
skipping to change at page 18, line 7 skipping to change at page 18, line 50
EPC_P may be filled up with the otherwise unused descriptor 0x00. EPC_P may be filled up with the otherwise unused descriptor 0x00.
At the receiving entity, the sequence of descriptors shall be At the receiving entity, the sequence of descriptors shall be
recovered by performing erasure decoding on the first row of the recovered by performing erasure decoding on the first row of the
TB (which definitely belongs to the signaling TSB) using the same TB (which definitely belongs to the signaling TSB) using the same
algorithm as later for the data TSB. If successful, the very algorithm as later for the data TSB. If successful, the very
first descriptor now indicates the number of rows of the first descriptor now indicates the number of rows of the
signaling TSB, and the next (R_P-1) rows are decoded to signaling TSB, and the next (R_P-1) rows are decoded to
reconstruct the redundancy profile for the data TSB(s), together reconstruct the redundancy profile for the data TSB(s), together
with the number of media stuffing symbols denoted by the with the number of media stuffing symbols denoted by the
respective SI(s). respective SI(s).
The complete structure of the TB is now depicted in Fig. 5. The complete structure of the TB is now depicted in Fig. 6.
Transmission Block (TB) Transmission Block (TB)
P P
<---------> <--------->
/\ +-+-+-+-+-+-+-+-+-+ /\ /\ +--+--+--+--+--+--+--+--+--+ /\
| |?|?|?|?|*|*|*|*|*| | R_P=1 | |d0|d1|d2|d3|* |* |* |* |* | | R_P=1
| +-+-+-+-+-+-+-+-+-+ \/ | +--+--+--+--+--+--+--+--+--+ \/
| |&|&|&|&|&|*|*|*|*| /\ | |x0|x1|x2|x3|x4|* |* |* |* | /\
| +-+-+-+-+-+-+-+-+-+ | R_T=3 | +--+--+--+--+--+--+--+--+--+ | R_T=3
| |&|&|&|&|&|*|*|*|*| | | |x5|x6|x7|x8|x9|* |* |* |* | |
| +-+-+-+-+-+-+-+-+-+ | | +--+--+--+--+--+--+--+--+--+ |
L octets | |&|&|&|&|&|*|*|*|*| \/ L octets | |xA|xB|xC|xD|xE|* |* |* |* | \/
payload | +-+-+-+-+-+-+-+-+-+ /\ payload | +--+--+--+--+--+--+--+--+--+ /\
per packet | |%|%|%|%|%|%|*|*|*| | R_(T-1)=1 per packet | |xF|xG|xH|xI|xJ|xK|* |* |* | | R_(T-1)=1
| +-+-+-+-+-+-+-+-+-+ \/ | +--+--+--+--+--+--+--+--+--+ \/
| |$|$|$|$|$|$|$|*|*| . | |xL|xM|xN|xO|xP|xQ|xR|* |* | .
| +-+-+-+-+-+-+-+-+-+ . | +--+--+--+--+--+--+--+--+--+ .
| |!|!|!|!|!|!|!|!|*| . | |xS|xT|xU|xV|xW|xX|xY|xZ|* | .
| +-+-+-+-+-+-+-+-+-+ /\ | +--+--+--+--+--+--+--+--+--+ /\
| |#|#|#|#|#|#|#|#|#| | R_0=1 | |y0|y1|y2|y3|y4|y5|y6|y7|y8| | R_0=1
\/ +-+-+-+-+-+-+-+-+-+ \/ \/ +-+-+-+-+-+-+-+-+-+ \/
<-----------------> <----------------->
n packets n packets
? : descriptors and stuffing indicators for in-band
signaling of the redundancy profile
&,%,$,!,# : info octets belonging to a certain element of the
info stream in decreasing order of importance
d# : descriptors and stuffing indicators for in-band
signaling of the redundancy profile
x#,y# : info octets belonging to the info stream defined in Fig.
3
* : parity octets gained from Reed-Solomon coding * : parity octets gained from Reed-Solomon coding
Fig. 5: General structure for UXP with in-band signaling of the Fig. 6: General structure for UXP with in-band signaling of the
redundancy profile redundancy profile
The following simple example is meant to illustrate the idea The following simple example is meant to illustrate the idea
behind using descriptors: Let an erasure protection vector of behind using descriptors: Let an erasure protection vector of
length T+1=7 be given as follows: length T+1=7 be given as follows:
EPV=(R_0,R_1,...,R_5,R_6)=(7,0,2,2,0,3,10) EPV=(R_0,R_1,...,R_5,R_6)=(7,0,2,2,0,3,10)
Hence, the length L of the TB (including one row for the Hence, the length L of the TB (including one row for the
signaling TSB) is equal to 7+2+2+3+10+1=25 (rows/octets). If the signaling TSB) is equal to 7+2+2+3+10+1=25 (rows/octets). If the
width is assumed to be equal to 20 (columns/packets), then the width is assumed to be equal to 20 (columns/packets), then the
erasure protection of the descriptors is P=10. erasure protection of the descriptors is P=10.
The corresponding sequence of descriptors can be written as The corresponding sequence of descriptors can be written as
DP=(DP_6,DP_5,DP_3,DP_2,DP_0)=(0xAC,0x39,0x2A,0x29,0x7A), DP=(DP_6,DP_5,DP_3,DP_2,DP_0)=(0xAC,0x39,0x2A,0x29,0x7A),
skipping to change at page 19, line 17 skipping to change at page 20, line 8
DP=(DP_6,DP_5,DP_3,DP_2,DP_0)=(0xAC,0x39,0x2A,0x29,0x7A), DP=(DP_6,DP_5,DP_3,DP_2,DP_0)=(0xAC,0x39,0x2A,0x29,0x7A),
where the values of the descriptors are given in hexadecimal where the values of the descriptors are given in hexadecimal
notation. Next, the descriptor indicating the length of the notation. Next, the descriptor indicating the length of the
signaling TSB has to be inserted, the end of the data TSB has to signaling TSB has to be inserted, the end of the data TSB has to
be marked by 0x00, and the SI has to be appended. If the number be marked by 0x00, and the SI has to be appended. If the number
of media stuffing symbols is assumed to be 3, the 10 info octets of media stuffing symbols is assumed to be 3, the 10 info octets
in the signaling TSB take on the following values (descriptor in the signaling TSB take on the following values (descriptor
stuffing included): stuffing included):
(0x10,0xAC,0x39,0x2A,0x29,0x7A,0x00,0x03,0x00,0x00) (0x10,0xAC,0x39,0x2A,0x29,0x7A,0x00,0x03,0x00,0x00)
6.5. Optional Concatenation of Transmission Sub Blocks 5.6. Optional Concatenation of Transmission Sub Blocks
The following procedure may be applied if a single info stream The following procedure may be applied if a single info stream
would be too short to achieve an efficient mapping to a would be too short to achieve an efficient mapping to a
transmission block with respect to the fixed payload length L and transmission block with respect to the fixed payload length L and
the desired number of packets n. For example, intra-coded video the desired number of packets n. For example, intra-coded video
frames (I-frames) are usually much larger than the following frames (I-frames) are usually much larger than the following
predicted ones (P-frames). In this case, a certain number z of predicted ones (P-frames). In this case, a certain number z of
successive small info streams should be each mapped to a successive small info streams should be each mapped to a
transmission sub block with length L_d(y) and width n, such that transmission sub block with length L_d(y) and width n, such that
L_d(1)+L_d(2)+...+L_d(z)=L_d. L_d(1)+L_d(2)+...+L_d(z)=L_d.
The resulting transmission sub blocks can then be easily The resulting transmission sub blocks can then be easily
concatenated to form a TB of size L x n having one common concatenated to form a TB of size L x n having one common
signaling TSB (see Fig. 2): Since the second half-octet of the signaling TSB (see Fig. 2): Since the second half-octet of the
descriptors is of type signed (cf. Sect. 6.4.), we are able to descriptors is of type signed (cf. Sect. 5.5.), we are able to
signal both decreasing and increasing erasure protection signal both decreasing and increasing erasure protection
profiles. profiles.
Again, we will give a simple example to illustrate this idea: Let Again, we will give a simple example to illustrate this idea: Let
the erasure protection vectors for two concatenated data TSBs be the erasure protection vectors for two concatenated data TSBs be
given as follows: given as follows:
EPV1=(R1_0,R1_1,...,R1_5,R1_6)=(0,0,2,2,0,3,10), EPV1=(R1_0,R1_1,...,R1_5,R1_6)=(0,0,2,2,0,3,10),
EPV2=(R2_0,R2_1,...,R2_5,R2_6)=(0,0,2,2,0,3,10). EPV2=(R2_0,R2_1,...,R2_5,R2_6)=(0,0,2,2,0,3,10).
Hence, two single identical data TSBs will be concatenated to Hence, two single identical data TSBs will be concatenated to
form a TB of length L=2*(2+2+3+10)+2=36 (rows/octets). If the form a TB of length L=2*(2+2+3+10)+2=36 (rows/octets). If the
width is again assumed to be equal to 20 (columns/packets), then width is again assumed to be equal to 20 (columns/packets), then
the erasure protection of the descriptors is P=10. We reserve a the erasure protection of the descriptors is P=10. We reserve a
total of two rows for the signaling TSB. The corresponding total of two rows for the signaling TSB. The corresponding
sequence of descriptors can now be written as sequence of descriptors can now be written as
DP=(0xAC,0x39,0x2A,0x29,0xA4,0x39,0x2A,0x29), where the values of DP=(0xAC,0x39,0x2A,0x29,0xA4,0x39,0x2A,0x29), where the values of
the descriptors are given in hexadecimal notation. The values of the descriptors are given in hexadecimal notation. The values of
the first four descriptors are taken from the descriptor of EPV1 the first four descriptors are taken from the descriptor of EPV1
as described in Sect. 6.4. (without the SI). The last four as described in Sect. 5.5. (without the SI). The last four
descriptors are taken from the descriptor of EPV2 (without SI) descriptors are taken from the descriptor of EPV2 (without SI)
with one exception. The fifth descriptor of DP (i.e. 0xA4) is with one exception. The fifth descriptor of DP (i.e. 0xA4) is
created as follows: The first half-octed is created according to created as follows: The first half-octet is created according to
Sect. 6.4. However, the second half-octed describes no longer the Sect. 5.5. However, the second half-octet describes no longer the
difference between R_P and R2_6. It rather describes the difference between R_P and R2_6. It rather describes the
difference between R1_2 and R2_6, i.e. R1_2-R2_6, which can be a difference between R1_2 and R2_6, i.e. R1_2-R2_6, which can be a
positive or negative number. If the number of media stuffing positive or negative number. If the number of media stuffing
symbols is assumed to be 3 for each data TSB, the 20 info octet symbols is assumed to be 3 for each data TSB, the 20 info octet
positions in the signaling TSB are filled with the following positions in the signaling TSB are filled with the following
values (descriptor stuffing included): values (descriptor stuffing included):
(0x20,0xAC,0x39,0x2A,0x29,0x00,0x03,0xA4,0x39,0x2A,0x29,0x00,0x03 (0x20,0xAC,0x39,0x2A,0x29,0x00,0x03,0xA4,0x39,0x2A,0x29,0x00,0x03
, ,
0x00,0x00,0x00,0x00,0x00,0x00,0x00) 0x00,0x00,0x00,0x00,0x00,0x00,0x00)
Therefore from the example above, the following general rule MUST Therefore from the example above, the following general rule MUST
be used to create the resulting descriptors for concatenated data be used to create the resulting descriptors for concatenated data
TSB #u and data TSB #v, where v=u+1: TSB #u and data TSB #v, where v=u+1:
Let EPVu=(Au_0,Au_1,...) and EPVv=(Av_0, Av_1,...) be the Let EPVu=(Au_0,Au_1,...) and EPVv=(Av_0, Av_1,...) be the
corresponding erasure protection vectors and DPu and DPv the corresponding erasure protection vectors and DPu and DPv the
corresponding descriptors created according to Sect. 6.4. (with corresponding descriptors created according to Sect. 5.5. (with
stuffing). Let w be the smallest index for which Au_w >0. Let x stuffing). Let w be the smallest index for which Au_w >0. Let x
be the largest index for which Av_x >0. The resulting descriptor be the largest index for which Av_x >0. The resulting descriptor
can be created by concatenation of DPu and DPv where the first can be created by concatenation of DPu and DPv where the first
descriptor of DPv should be changed as follows: descriptor of DPv should be changed as follows:
The second half byte is defined by Au_w-Av_x. The second half byte is defined by Au_w-Av_x.
7. Indication of UXP in SDP 6. Indication of UXP in SDP
From the discussion in Sect. 6.3 , we know that UXP encapsulates From the discussion in Sect. 5.4 , we know that UXP encapsulates
and protects the info stream. The info stream consists usually of and protects the info stream. The info stream consists usually of
a regular RTP-Payload format, e.g. RFC 3016. a regular RTP-Payload format, e.g. RFC 3016.
There is no static payload type assignment for UXP, so dynamic There is no static payload type assignment for UXP, so dynamic
payload type numbers MUST be used. The binding to the number is payload type numbers MUST be used. The binding to the number is
indicated by an rtpmap attribute. The name used in this binding indicated by an rtpmap attribute. The name used in this binding
is is
"UXP". The payload type number of UXP is indicated in the "m" "UXP". The payload type number of UXP is indicated in the "m"
line of the line of the
media as well as the payload type of the info-stream. media, as well as the payload type of the info-stream.
A sample indication of UXP in SDP is as follows: A sample indication of UXP in SDP is as follows:
m = video 8000 RTP/AVP 98 99 m = video 8000 RTP/AVP 98 99
a = rtpmap:98 UXP/90000 a = rtpmap:98 UXP/90000
a = rtpmap:99 MP4V-ES/90000 a = rtpmap:99 MP4V-ES/90000
Here, PT 98 indicates that the payload consists of UXP with the Here, PT 98 indicates that the payload consists of UXP with the
corresponding info stream "MP4V-ES". Alternatively, PT 99 can be corresponding info stream "MP4V-ES". Alternatively, PT 99 can be
used which indicates "MP4V-ES" without UXP. used which indicates "MP4V-ES" without UXP.
skipping to change at page 21, line 13 skipping to change at page 22, line 7
a = rtpmap:98 UXP/90000 a = rtpmap:98 UXP/90000
a = rtpmap:99 MP4V-ES/90000 a = rtpmap:99 MP4V-ES/90000
a = rtpmap:100 H263-1998/90000 a = rtpmap:100 H263-1998/90000
mean that UXP can be used with either "MP4V-ES" or "H263-1998" as mean that UXP can be used with either "MP4V-ES" or "H263-1998" as
info stream (indicated by PT 98 in the RTP-Header and either info stream (indicated by PT 98 in the RTP-Header and either
block PT=99 or block PT=100 in the UXP-Header). Alternatively, block PT=99 or block PT=100 in the UXP-Header). Alternatively,
PT=99 or PT=100 in the RTP-Header means the use of "MP4V-ES" or PT=99 or PT=100 in the RTP-Header means the use of "MP4V-ES" or
"H263-1998" without UXP. "H263-1998" without UXP.
As described in Sect. 6.4., the parameter P has the default value As described in Sect. 5.5., the parameter P has the default value
P=ceil(n/2.0), if not otherwise stated. The parameter P MAY be P=ceil(n/2.0), if not otherwise stated. The parameter P MAY be
specified explicitly by means of SDP: specified explicitly by means of SDP:
a = fmtp:98 UXP-prof: fvalue a = fmtp:98 UXP-prof: fvalue
where fvalue is a floating point number in the interval (0 < where fvalue is a floating point number in the interval (0 <
fvalue <1) and specifies P by P=ceil(n*fvalue). For example, if fvalue <1) and specifies P by P=ceil(n*fvalue). For example, if
we set fvalue=0.5, we set fvalue=0.5,
a = fmtp:98 UXP-prof: 0.5 a = fmtp:98 UXP-prof: 0.5
we get the default value for P, since P=ceil(n/2.0). we get the default value for P, since P=ceil(n/2.0).
The ABNF for fvalue according to RFC 2234 is The ABNF for fvalue according to RFC 2234 is
fvalue = "0" "." 1*2DIGIT fvalue = "0" "." 1*2DIGIT
8. Security Considerations 7. Security Considerations
The payload of the RTP-packets consists of an interleaved media The payload of the RTP-packets consists of an interleaved media
and parity stream. Therefore, it is reasonable to encrypt the and parity stream. Therefore, it is reasonable to encrypt the
resulting stream with one key rather than using different keys resulting stream with one key rather than using different keys
for media and parity data. It should also be noted that for media and parity data. It should also be noted that
encryption of the media data without encryption of the parity encryption of the media data without encryption of the parity
data could enable known-plaintext attacks. data could enable known-plaintext attacks.
The overall proportion between parity octets and info octets The overall proportion between parity octets and info octets
should be chosen carefully if the packet loss is due to network should be chosen carefully if the packet loss is due to network
congestion. If the proportion of parity octets per TB is congestion. If the proportion of parity octets per TB is
increased in this case, it could lead to increasing network increased in this case, it could lead to increasing network
congestion. Therefore, the proportion between parity octets and congestion. Therefore, the proportion between parity octets and
info octets per TB MUST NOT be increased as packet loss increases info octets per TB MUST NOT be increased as packet loss increases
due to network congestion. due to network congestion.
The overall ratio between parity and info octets MUST NOT be The overall transmission rate for parity and info octets MUST be
higher than 1:1, i.e. the absolute bitrate spent for redundancy controlled by a congestion control algorithm. The congestion
must not be larger than the bitrate required for transmission of control algorithm used for the media which is protected by UXP
multimedia data itself. MUST by used for the overall transmission rate for parity and
info octets in UXP, i.e. for the resulting data rate. The trade-
off between parity and info octets is determined by the
optimization algorithm which determines the EPV and is, thus, out
of scope of this specification.
8. IANA Considerations
8.1 Video
To: ietf-types@iana.org
Subject: Registration of MIME media type video/UXP
MIME media type name: video
MIME subtype name: UXP
Required parameters: none
[RFC3555] mandates that RTP payload formats without a defined
rate must define a rate parameter as part of their MIME
registration. This payload specification does not specify a rate
parameter. However, the rate for UXP payload is equal to the rate
of the media data it protects.
Optional parameters:
UXP-prof: Describes the redundancy of the signaling sub block
(cf. Sec.5.5.).
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC3550]. Its transport within RTP is fully specified within
this specification.
Security considerations: The same security considerations apply
to these mime registrations as to the payloads for them, as
detailed in this specification.
Interoperability considerations: none
Published specification: This MIME type is described fully within
this specification.
Applications which use this media type: Audio and video streaming
tools which seek to improve resiliency to loss by sending
additional data with the media stream.
Additional information: none
Person & email address to contact for further information:
Marcel Wagner
Siemens AG
Otto-Hahn-Ring 6
81730 Munich, Germany
email: Marcel.Wagner@siemens.com
Intended usage: COMMON
Author/Change controller: Marcel Wagner.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) [RFC2327] are fully specified
within this specification.
8.2 Audio
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/UXP
MIME media type name: audio
MIME subtype name: UXP
Required parameters: none
[RFC3555] mandates that RTP payload formats without a defined
rate must define a rate parameter as part of their MIME
registration. This payload specification does not specify a rate
parameter. However, the rate for UXP payload is equal to the rate
of the media data it protects.
Optional parameters:
UXP-prof: Describes the redundancy of the signaling sub block
(cf. Sec.5.5.).
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC3550]. Its transport within RTP is fully specified within
this specification.
Security considerations: The same security considerations apply
to these mime registrations as to the payloads for them, as
detailed in this specification.
Interoperability considerations: none
Published specification: This MIME type is described fully within
this specification.
Applications which use this media type: Audio and video streaming
tools which seek to improve resiliency to loss by sending
additional data with the media stream.
Additional information: none
Person & email address to contact for further information:
Marcel Wagner
Siemens AG
Otto-Hahn-Ring 6
81730 Munich, Germany
email: Marcel.Wagner@siemens.com
Intended usage: COMMON
Author/Change controller: Marcel Wagner.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) [RFC2327] are fully specified
within this specification.
9. Application Statement 9. Application Statement
There are currently two different schemes proposed for unequal There are currently two different schemes proposed for unequal
error protection in the IETF-AVT: Unequal Level Protection (ULP) error protection in the IETF-AVT: Unequal Level Protection (ULP)
and Unequal Erasure Protection (UXP). and Unequal Erasure Protection (UXP).
Although both methods seem to address the same problem, the Although both methods seem to address the same problem, the
proposed solutions differ in many respects. This section tries to proposed solutions differ in many respects. This section tries to
describe possible application scenarios and to show the strengths describe possible application scenarios and to show the strengths
and weaknesses of both approaches. and weaknesses of both approaches.
The main difference between both approaches is that while ULP The main difference between both approaches is that while ULP
skipping to change at page 23, line 21 skipping to change at page 26, line 41
packets are corrupted, because in this case one has to wait for packets are corrupted, because in this case one has to wait for
several redundancy packets. Thus, the delay is in general several redundancy packets. Thus, the delay is in general
dependent on the actual ULP-FEC-packet scheme and cannot be dependent on the actual ULP-FEC-packet scheme and cannot be
considered in advance during the system design phase. considered in advance during the system design phase.
Finally, we want to point out that UXP uses RS codes which are Finally, we want to point out that UXP uses RS codes which are
known known
to be the most efficient type of block codes in terms of erasure to be the most efficient type of block codes in terms of erasure
correction capability. correction capability.
10. Intellectual Property Considerations 10. Intellectual Property Considerations
Siemens AG has filed patent applications that might possibly have Siemens AG has filed patent applications that might possibly have
technical relations to this contribution. technical relations to this contribution.
On IPR related issues, Siemens AG refers to the Siemens Statement On IPR related issues, Siemens AG refers to the Siemens Statement
on Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS- on Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS-
General. General.
The following patent might apply to this specification:
United States Patent 5,617,541, April 1, 1997, System for
packetizing data encoded corresponding to priority levels where
reconstructed data corresponds to fractionalized priority level
and received fractionalized packets, Inventors: Albanese;
Andres (Berkeley, CA); Luby; Michael G. (Berkeley,CA); Bloemer;
Johannes F. (Berkeley, CA); Edmonds; Jeffrey A. (Berkeley, CA)
Filed: December 21, 1994
11. References 11. References
Normative References Normative References
[1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for [RFC2733] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format
Generic Forward Error Correction", Request for Comments 2733, for Generic Forward Error Correction", Request for Comments 2733,
Internet Engineering Task Force, Dec. 1999. Internet Engineering Task Force, Dec. 1999.
[2] Shu Lin and Daniel J. Costello, Error Control Coding: [Lin83] Shu Lin and Daniel J. Costello, Error Control Coding:
Fundamentals and Applications, Prentice-Hall, Inc., Englewood Fundamentals and Applications, Prentice-Hall, Inc., Englewood
Cliffs, N.J., 1983. Cliffs, N.J., 1983.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-time Applications",
RFC 3550, July 2003.
[RFC3555] Casner, S., Hoschka, P.," MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
Informative References Informative References
[3] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan, [Alb96] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M.
"Priority encoding transmission", IEEE Trans. Inform. Theory, Sudan, "Priority encoding transmission", IEEE Trans. Inform.
vol. 42, no. 6, pp. 1737-1744, Nov. 1996. Theory, vol. 42, no. 6, pp. 1737-1744, Nov. 1996.
[4] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on [Li01] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on
Circuits and Systems for Video Technology, Vol. 11, no. 3, 301- Circuits and Systems for Video Technology, Vol. 11, no. 3, 301-
317, March 2001. 317, March 2001.
[5] G. Blaettermann, G. Heising, and D. Marpe: "A Quality [Bla00] G. Blaettermann, G. Heising, and D. Marpe: "A Quality
Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May
2000. 2000.
[6] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive A/V [Bur99] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive
coding for lossy packet networks - a principle approach", Tech. A/V coding for lossy packet networks - a principle approach",
Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999. Tech. Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999.
[Lie99] Guenther Liebl, "Modeling, theoretical analysis, and
[7] Guenther Liebl, "Modeling, theoretical analysis, and coding coding for wireless packet erasure channels", Diploma Thesis,
for wireless packet erasure channels", Diploma Thesis, Inst. for Inst. for Communications Engineering, Munich University of
Communications Engineering, Munich University of Technology, Technology, 1999.
1999. [Hor99] U. Horn, K. Stuhlmuller, M. Link, and B. Girod, "Robust
[8] U. Horn, K. Stuhlmuller, M. Link, and B. Girod, "Robust
Internet video transmission based on scalable coding and unequal Internet video transmission based on scalable coding and unequal
error protection", Image Com., vol. 15, no. 1-2, pp. 77-94, Sep. error protection", Image Com., vol. 15, no. 1-2, pp. 77-94, Sep.
1999. 1999.
[9] S. Wenger, "H.26L over IP: The IP-Network Adaptation Layer", [Wen02] S. Wenger, "H.26L over IP: The IP-Network Adaptation
Packet Video 2002, Pittsburgh, Pennsylvania, USA, April 24- Layer", Packet Video 2002, Pittsburgh, Pennsylvania, USA, April
26,2002. 24-26,2002.
[Laz04]Lazzaro, John, "Framing RTP and RTCP Packets over
Connection-Oriented Transport", draft-ietf-avt-rtp-framing-
contrans-02.txt, work in progress, 2004
12. Acknowledgments 12. Acknowledgments
Many thanks to Philippe Gentric, Stephen Casner, and Hermann Many thanks to Magnus Westerlund, Philippe Gentric, Stephen
Hellwagner for helpful comments and improvements. The authors Casner, and Hermann Hellwagner for helpful comments and
would like to thank Thomas Stockhammer who came up with the improvements. The authors would like to thank Thomas Stockhammer
original idea of UXP. Also, the help of Gero Baese, Frank who came up with the original idea of UXP. Also, the help of Gero
Burkert, and Minh Ha Nguyen for the development of UXP is well Baese, Frank Burkert, and Minh Ha Nguyen for the development of
acknowledged. UXP is well acknowledged.
13. Author's Addresses 13. Author's Addresses
Guenther Liebl Guenther Liebl
Institute for Communications Engineering (LNT) Institute for Communications Engineering (LNT)
Munich University of Technology Munich University of Technology (TUM)
D-80290 Munich D-80290 Munich
Germany Germany
Email: {liebl}@lnt.e-technik.tu-muenchen.de Email: {liebl}@lnt.e-technik.tu-muenchen.de
Marcel Wagner, Juergen Pandel, Wenrong Weng Marcel Wagner
Siemens AG - Corporate Technology CT IC 2 Siemens AG - Corporate Technology CT IC 2
D-81730 Munich D-81730 Munich
Germany Germany
Email: Email: marcel.wagner@siemens.com
{marcel.wagner,juergen.pandel,wenrong.weng}@mchp.siemens.de
Full Copyright Statement Juergen Pandel
"Copyright (C) The Internet Society (date). All Rights Reserved. Siemens AG - Corporate Technology CT IC 2
This document and translations of it may be copied and furnished D-81730 Munich
to others, and derivative works that comment on or otherwise Germany
explain it or assist in its implementation may be prepared, Email: juergen.pandel@siemens.com
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice Wenrong Weng
and this paragraph are included on all such copies and derivative Siemens AG - Corporate Technology CT IC 2
works. However, this document itself may not be modified in any D-81730 Munich
way, such as by removing the copyright notice or references to Germany
the Internet Society or other Internet organizations, except as Email: wenrong.weng@siemens.com
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet 14. Full Copyright Statement
Standards process must be followed, or as required to translate Copyright (C) The Internet Society (2004). This document is
it into languages other than English. subject to the rights, licenses and restrictions contained in BCP
The limited permissions granted above are perpetual and will not 78, and except as set forth therein, the authors retain all their
be revoked by the Internet Society or its successors or assigns. rights.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET This document and the information contained herein are provided
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
IMPLIED; INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
PURPOSE. THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
15. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/