RTP Payload Format for H.264 Video
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, avt mailing list <firstname.lastname@example.org>, avt chair <email@example.com> Subject: Protocol Action: 'RTP Payload Format for H.264 Video' to Proposed Standard (draft-ietf-avt-rtp-rfc3984bis-12.txt) The IESG has approved the following document: - 'RTP Payload Format for H.264 Video' (draft-ietf-avt-rtp-rfc3984bis-12.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-rfc3984bis/
Technical Summary This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17. Working Group Summary The initial Working Group Last Call produced a number of comments that were successfully resolved. Subsequent to the initial Working Group Last Call interested parties suggested that it would be valuable to support the possibility of asymmetrical operation, where the two ends send at different levels. This capability was added to the specification. The process was dragged out by a lengthy debate over whether to add the ability for a sender to indicate its maximum capabilities. In the end the Chair had to cut off that debate by ruling that there was no consensus to add that feature. The document had a successful second WG Last Call. Immediately before this request was issued, some potential consumers of the specification had comments that suggested some text needs clarification. The change required is minor, so it is being left to be handled as part of IETF Last Call. Document Quality This document updates RFC 3984, which has a number of implementations not necessarily fully conformant to that specification. The document introduces new features that RFC 3984 implementations do not support. It is clear from list discussion that implementations of the new document are in the serious planning stage. Randell Jesup was brought on board as an additional author at the end, but before that he contributed a great deal to the process of review and the discussion of the document. The Media Type review was posted 10 November 2009. There was no response. Personnel Tom Taylor is PROTO Shepherd. Robert Sparks is the responsible Area Director.