RTP Payload Format for H.264 Video
RFC 6184

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>,
    avt mailing list <avt@ietf.org>,
    avt chair <avt-chairs@tools.ietf.org>
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.