I-D Action:draft-ietf-avt-rtp-svc-17.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I-D Action:draft-ietf-avt-rtp-svc-17.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.
Title : RTP Payload Format for SVC Video
Author(s) : S. Wenger, et al.
Filename : draft-ietf-avt-rtp-svc-17.txt
Pages : 101
Date : 2009-02-23
This memo describes an RTP payload format for Scalable Video Coding
(SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is
technically identical to Amendment 3 of ISO/IEC International
Standard 14496-10. The RTP payload format allows for packetization
of one or more Network Abstraction Layer (NAL) units in each RTP
packet payload, as well as fragmentation of a NAL unit in multiple
RTP packets. Furthermore, it supports transmission of an SVC stream
over a single as well as multiple RTP sessions. The payload format
defines a new media subtype name "H264-SVC", but is still backwards
compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer,
when encapsulated in its own RTP stream, must use the H.264 media
subtype name ("H264") and the packetization method specified in [I-
D.ietf-avt-rtp-rfc3984bis]. The payload format has wide
applicability in videoconferencing, Internet video streaming, and
high bit-rate entertainment-quality video, among others.
Table of Contents
Status of this Memo...............................................1
Abstract..........................................................2
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-17.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
- <ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-17.txt>
-
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.