draft-ietf-avt-uxp-01.txt   draft-ietf-avt-uxp-02.txt 
Internet Engineering Task Force G. Liebl, Internet Engineering Task Force G. Liebl,
T.Stockhammer T.Stockhammer
Internet Draft LNT, Munich Univ. of Internet Draft LNT, Munich Univ.
Technology of Technology
Document: draft-ietf-avt-uxp-01.txt Document: draft-ietf-avt-uxp-02.txt
November 2001 M. Wagner, J.Pandel, March 1, 2002 M. Wagner, J.Pandel,
W. Weng, G. Baese, W. Weng, G. Baese,
M. Nguyen, F. Burkert M. Nguyen, F. Burkert
Expires: May 2002 Siemens AG, Munich Expires: Sept. 1, 2002 Siemens AG, Munich
An RTP Payload Format for Erasure-Resilient Transmission of Progressive An RTP Payload Format for Erasure-Resilient Transmission of Progressive
Multimedia Streams Multimedia Streams
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 []. all provisions of Section 10 of RFC2026 [].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 10, line 14 skipping to change at page 10, line 14
Data Transmission Sub Block (data TSB) Data Transmission Sub Block (data TSB)
T T
<-------> <------->
/\ +-+-+-+-+-+-+-+-+-+ /\ /\ +-+-+-+-+-+-+-+-+-+ /\
| |&|&|&|&|&|*|*|*|*| | | |&|&|&|&|&|*|*|*|*| |
| +-+-+-+-+-+-+-+-+-+ | A_T=3 | +-+-+-+-+-+-+-+-+-+ | A_T=3
| |&|&|&|&|&|*|*|*|*| | | |&|&|&|&|&|*|*|*|*| |
| +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ |
L_d bytes | |&|&|&|&|&|*|*|*|*| \/ L_d bytes | |&|&|&|&|&|*|*|*|*| \/
per packet | +-+-+-+-+-+-+-+-+-+ /\ per packet | +-+-+-+-+-+-+-+-+-+ /\
| +%|%|%|%|%|%|*|*|*| | A_(T-1)=1 | |%|%|%|%|%|%|*|*|*| | A_(T-1)=1
| +-+-+-+-+-+-+-+-+-+ \/ | +-+-+-+-+-+-+-+-+-+ \/
| |$|$|$|$|$|$|$|*|*| . | |$|$|$|$|$|$|$|*|*| .
| +-+-+-+-+-+-+-+-+-+ . | +-+-+-+-+-+-+-+-+-+ .
| |||||||||*| . | |!|!|!|!|!|!|!|!|*| .
| +-+-+-+-+-+-+-+-+-+ /\ | +-+-+-+-+-+-+-+-+-+ /\
| |#|#|#|#|#|#|#|#|#| | A_0=1 | |#|#|#|#|#|#|#|#|#| | A_0=1
\/ +-+-+-+-+-+-+-+-+-+ \/ \/ +-+-+-+-+-+-+-+-+-+ \/
<-----------------> <----------------->
n packets n packets
&,%,$,,# : info bytes belonging to a certain info stream in &,%,$,!,# : info bytes belonging to a certain info stream in
decreasing order of importance decreasing order of importance
* : parity bytes gained from Reed-Solomon coding * : parity bytes gained from Reed-Solomon coding
Fig. 3: General structure for coding with unequal erasure protection Fig. 3: General structure for coding with unequal erasure protection
Furthermore, all rows in a particular class CA_i shall contain Furthermore, all rows in a particular class CA_i shall contain
exactly the same number of parity bytes, which is equal to the index exactly the same number of parity bytes, which is equal to the index
i of the class. For each row in a certain class CA_i, the same (n,n- i of the class. For each row in a certain class CA_i, the same (n,n-
i) RS code shall be applied. i) RS code shall be applied.
skipping to change at page 17, line 21 skipping to change at page 17, line 21
| |&|&|&|&|&|*|*|*|*| /\ | |&|&|&|&|&|*|*|*|*| /\
| +-+-+-+-+-+-+-+-+-+ | A_T=3 | +-+-+-+-+-+-+-+-+-+ | A_T=3
| |&|&|&|&|&|*|*|*|*| | | |&|&|&|&|&|*|*|*|*| |
| +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ |
L bytes | |&|&|&|&|&|*|*|*|*| \/ L bytes | |&|&|&|&|&|*|*|*|*| \/
payload | +-+-+-+-+-+-+-+-+-+ /\ payload | +-+-+-+-+-+-+-+-+-+ /\
per packet | +%|%|%|%|%|%|*|*|*| | A_(T-1)=1 per packet | +%|%|%|%|%|%|*|*|*| | A_(T-1)=1
| +-+-+-+-+-+-+-+-+-+ \/ | +-+-+-+-+-+-+-+-+-+ \/
| |$|$|$|$|$|$|$|*|*| . | |$|$|$|$|$|$|$|*|*| .
| +-+-+-+-+-+-+-+-+-+ . | +-+-+-+-+-+-+-+-+-+ .
| |||||||||*| . | |!|!|!|!|!|!|!|!|*| .
| +-+-+-+-+-+-+-+-+-+ /\ | +-+-+-+-+-+-+-+-+-+ /\
| |#|#|#|#|#|#|#|#|#| | A_0=1 | |#|#|#|#|#|#|#|#|#| | A_0=1
\/ +-+-+-+-+-+-+-+-+-+ \/ \/ +-+-+-+-+-+-+-+-+-+ \/
<-----------------> <----------------->
n packets n packets
? : descriptors and stuffing indicators for in-band ? : descriptors and stuffing indicators for in-band
signaling of the redundancy profile signaling of the redundancy profile
&,%,$,,# : info bytes belonging to a certain element of the &,%,$,!,# : info bytes belonging to a certain element of the
info stream in decreasing order of importance info stream in decreasing order of importance
* : parity bytes gained from Reed-Solomon coding * : parity bytes gained from Reed-Solomon coding
Fig. 5: General structure for UXP with in-band signaling of the Fig. 5: General structure for UXP with in-band signaling of the
redundancy profile redundancy profile
The following simple example is meant to illustrate the idea behind The following simple example is meant to illustrate the idea behind
using descriptors: Let an erasure protection vector of length T+1=7 using descriptors: Let an erasure protection vector of length T+1=7
be given as follows: be given as follows:
skipping to change at page 20, line 28 skipping to change at page 20, line 28
frames are only recoverable, if the I-frame, on which the decoding of frames are only recoverable, if the I-frame, on which the decoding of
P-frames depends, is recoverable. The same is true for B-frames, P-frames depends, is recoverable. The same is true for B-frames,
which can only be decoded if the respective P-frames are recoverable. which can only be decoded if the respective P-frames are recoverable.
This prevents situations in which, for example, the B-frames have This prevents situations in which, for example, the B-frames have
been received correctly, but the P-frames have been lost, i.e. been received correctly, but the P-frames have been lost, i.e.
assures a gradual decrease in application quality also on the frame assures a gradual decrease in application quality also on the frame
level. Of course, a similar encoding is possible with ULP. But in level. Of course, a similar encoding is possible with ULP. But in
this case one might have to send several frames within one packet this case one might have to send several frames within one packet
which leads to large packet sizes. which leads to large packet sizes.
Finally, decoding delay is also a crucial issue in communications. Furthmore, decoding delay is also a crucial issue in communications.
Again, both approaches have different delay properties: UXP Again, both approaches have different delay properties: UXP
introduces a decoding delay because a reasonable amount of correctly introduces a decoding delay because a reasonable amount of correctly
received packets are necessary to start decoding of a TB. The delay received packets are necessary to start decoding of a TB. The delay
in general depends on the dimensions of the interleaver. This should in general depends on the dimensions of the interleaver. This should
be considered for any system design which includes UXP. be considered for any system design which includes UXP.
With ULP, every correctly received media packet can be decoded right With ULP, every correctly received media packet can be decoded right
away. However, a significant delay is introduced, if packets are away. However, a significant delay is introduced, if packets are
corrupted, because in this case one has to wait for several corrupted, because in this case one has to wait for several
redundancy packets. Thus, the delay is in general dependent on the redundancy packets. Thus, the delay is in general dependent on the
actual ULP-FEC-packet scheme and cannot be considered in advance actual ULP-FEC-packet scheme and cannot be considered in advance
during the system design phase. during the system design phase.
Finally, we want to point out that UXP uses RS-codes which are known
to be the most efficient type of block codes in terms of erasure
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 On IPR related issues, Siemens AG refers to the Siemens Statement on
Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS-General. Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS-General.
11. References 11. References
[1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for [1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for
 End of changes. 

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