corresponding primary coded picture is correctly decoded. There
should be no noticeable difference between any area of the decoded
primary picture and a corresponding area that would result from
application of the H.264 decoding process for any redundant picture
in the same access unit. A redundant coded slice is a coded slice
that is a part of a redundant coded picture.
Redundant coded pictures can be used to provide unequal error
protection in error-prone video transmission. If a primary coded
representation of a picture is decoded incorrectly, a corresponding
redundant coded picture can be decoded. Examples of applications and
coding techniques using the redundant codec picture feature include
the video redundancy coding [23] and the protection of "key pictures"
in multicast streaming [24].
One property of many error-prone video communications systems is that
transmission errors are often bursty. Therefore, they may affect
more than one consecutive transmission packets in transmission order.
In low bit-rate video communication, it is relatively common that an
entire coded picture can be encapsulated into one transmission
packet. Consequently, a primary coded picture and the corresponding
redundant coded pictures may be transmitted in consecutive packets in
transmission order. To make the transmission scheme more tolerant of
bursty transmission errors, it is beneficial to transmit the primary
coded picture and redundant coded picture separated by more than a
single packet. The DON concept enables this.
13.5. Remarks on Other Design Possibilities
The slice header syntax structure of the H.264 coding standard
contains the frame_num syntax element that can indicate the decoding
order of coded frames. However, the usage of the frame_num syntax
element is not feasible or desirable to recover the decoding order,
due to the following reasons:
o The receiver is required to parse at least one slice header per
coded picture (before passing the coded data to the decoder).
o Coded slices from multiple coded video sequences cannot be
interleaved, as the frame number syntax element is reset to 0 in
each IDR picture.
o The coded fields of a complementary field pair share the same
value of the frame_num syntax element. Thus, the decoding order
of the coded fields of a complementary field pair cannot be
recovered based on the frame_num syntax element or any other
syntax element of the H.264 coding syntax.
The RTP payload format for transport of MPEG-4 elementary streams
[25] enables interleaving of access units and transmission of
multiple access units in the same RTP packet. An access unit is
specified in the H.264 coding standard to comprise all NAL units
associated with a primary coded picture according to subclause
7.4.1.2 of [1]. Consequently, slices of different pictures cannot be
interleaved, and the multi-picture slice interleaving technique (see
section 12.6) for improved error resilience cannot be used.
14. Acknowledgements
The authors thank Roni Even, Dave Lindbergh, Philippe Gentric,
Gonzalo Camarillo, Gary Sullivan, Joerg Ott, and Colin Perkins for
careful review.
15. References
15.1. Normative References
[1] ITU-T Recommendation H.264, "Advanced video coding for generic
audiovisual services", May 2003.
[2] ISO/IEC International Standard 14496-10:2003.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
15.2. Informative References
[8] "Draft ITU-T Recommendation and Final Draft International
Standard of Joint Video Specification (ITU-T Rec. H.264 |
ISO/IEC 14496-10 AVC)", available from http://ftp3.itu.int/av-
arch/jvt-site/2003_03_Pattaya/JVT-G050r1.zip, May 2003.
[9] Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), Special Issue
on H.264/AVC. IEEE Transactions on Circuits and Systems on Video
Technology, July 2003.
[10] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C.,
Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)", RFC 2429, October 1998.
[11] ISO/IEC IS 14496-2.
[12] Wenger, S., "H.26L over IP", IEEE Transaction on Circuits and
Systems for Video technology, Vol. 13, No. 7, July 2003.
[13] Wenger, S., "H.26L over IP: The IP Network Adaptation Layer",
Proceedings Packet Video Workshop 02, April 2002.
[14] Stockhammer, T., Hannuksela, M.M., and S. Wenger, "H.26L/JVT
Coding Network Abstraction Layer and IP-based Transport" in
Proc. ICIP 2002, Rochester, NY, September 2002.
[15] ITU-T Recommendation H.241, "Extended video procedures and
control signals for H.300 series terminals", 2004.
[16] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[17] ITU-T Recommendation H.223, "Multiplexing protocol for low bit
rate multimedia communication", July 2001.
[18] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[19] Stockhammer, T., Wiegand, T., Oelbaum, T., and F. Obermeier,
"Video Coding and Transport Layer Techniques for H.264/AVC-Based
Transmission over Packet-Lossy Networks", IEEE International
Conference on Image Processing (ICIP 2003), Barcelona, Spain,
September 2003.
[20] Varsa, V. and M. Karczewicz, "Slice interleaving in compressed
video packetization", Packet Video Workshop 2000.
[21] Kang, S.H. and A. Zakhor, "Packet scheduling algorithm for
wireless video streaming," International Packet Video Workshop
2002.
[22] Hannuksela, M.M., "Enhanced concept of GOP", JVT-B042, available
http://ftp3.itu.int/av-arch/video-site/0201_Gen/JVT-B042.doc,
January 2002.
[23] Wenger, S., "Video Redundancy Coding in H.263+", 1997
International Workshop on Audio-Visual Services over Packet
Networks, September 1997.
[24] Wang, Y.-K., Hannuksela, M.M., and M. Gabbouj, "Error Resilient
Video Coding Using Unequally Protected Key Pictures", in Proc.
International Workshop VLBV03, September 2003.
[25] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and
P. Gentric, "RTP Payload Format for Transport of MPEG-4
Elementary Streams", RFC 3640, November 2003.
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[27] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[28] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[29] ISO/IEC 14496-15: "Information technology - Coding of audio-
visual objects - Part 15: Advanced Video Coding (AVC) file
format".
[30] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
Generation Partnership Project (3GPP) Multimedia files", RFC
3839, July 2004.
Authors’ Addresses
Stephan Wenger
TU Berlin / Teles AG
Franklinstr. 28-29
D-10587 Berlin
Germany
Phone: +49-172-300-0813
EMail: stewe@stewe.org
Miska M. Hannuksela
Nokia Corporation
P.O. Box 100
33721 Tampere
Finland
Phone: +358-7180-73151
EMail: miska.hannuksela@nokia.com
Thomas Stockhammer
Nomor Research
D-83346 Bergen
Germany
Phone: +49-8662-419407
EMail: stockhammer@nomor.de
Magnus Westerlund
Multimedia Technologies
Ericsson Research EAB/TVA/A
Ericsson AB
Torshamsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46-8-7190000
EMail: magnus.westerlund@ericsson.com
David Singer
QuickTime Engineering
Apple
1 Infinite Loop MS 302-3MT
Cupertino
CA 95014
USA
Phone +1 408 974-3162
EMail: singer@apple.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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 IETF’s procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.