240 likes | 386 Views
RTP Payload for MPEG-4 with Flexible Error Resiliency draft-ietf-avt-mpeg4streams-00.txt proposed experimental RFC formerly draft-guillemot-avt-genrtp-03.txt. IETF AVT WG, Adelaide. March, 2000. Christine Guillemot, Paul Christ , Stefan Wesner [, Anders Klemets].
E N D
RTP Payload for MPEG-4with Flexible Error Resiliencydraft-ietf-avt-mpeg4streams-00.txtproposed experimental RFCformerlydraft-guillemot-avt-genrtp-03.txt IETF AVT WG, Adelaide. March, 2000 Christine Guillemot, Paul Christ, Stefan Wesner [, Anders Klemets]
Modifications since Washington • draft-guillemot-avt-genrtp-03.txt => new title • Flexmux section added in discussion with authors - (see draft-rgcc-flexmuxmpeg4-00.txt); • Payload Type (PT):Different payload types should be assigned for MPEG4 ES, MPEG4 SL-PDU MPEG-4 FlexMux streams. A payload type in the dynamic range should be chosen. • Same format, same interface ES, SL, Flexmux • TSOFFSET removed, Ebits included
Multiple Dimensions of MPEG-4/RTP ... in applications relying on • Systems (OD) or non-systems (non-OD) framework • Various types of streams with different QoS requirements (MPEG-4 A/V, OD, BIFS, IPMP, other compressed AV formats, eg. H.263 streams) • Mixed live and streamed (pre-encoded) content • Session Types • Client - Server (unicast), “MU” • (Multi) Peer-to-Peer - (multicast)
Summary • Unified solution for the transport of MPEG-4 • MPEG-4 SL packet streams - and for • MPEG-4 ES • Common solution for • both live and pre- encoded content • Applicable to the transport of FlexMux PD (submitted draft-rgcc-avt-mpeg4flexmux-00.txt)
Summary • Abstraction of QoS monitoring and Congestion Contro “intelligence” • unique interface • architectural simplicity and consistent stream “adaptation” in high number of streams applications (mixing real-time & pre-encoded content) • Packet Loss flexible protection mechanisms • Full and partial AUs Segments with types or priority • Abstract media idiosyncrasies • Assuming a media and network aware adaptation layer • Towards UEP and/or Diffserv marking based on AUs
Sample RTP packet for MPEG-4 ESs If no additional data-based protection needed 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Res | | +-+-+-+-+-+-+-+-+ | | . . AU or partial AU . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - One byte difference with draft-ietf-avt-mpeg4-es-00.txt, Byte offering additional flexibility in terms of protection - The packet would be of this form if protection supported by compression layer in the case of real-time
Sample RTP packet for MPEG-4 ESs If additional data-based protection needed (eg. duplicated headers), (no fragmentation used). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|E| XT | LENGTH |EBITS| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . + Extension data (e.g. VOP header) +-+-+-+-+-+-+-+-+ . |G|E|0| res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . Media Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sample RTP packet for MPEG-4 SL-PDUs If no additional data-based protection needed 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|E|F| res | optional SL header paramaters as indicated by . +-+-+-+-+-+-+-+-+ the SLConfigDescriptor . | . . Media payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sample RTP packet for MPEG-4 SL-PDUs If additional protection needed 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|E| XT | LENGTH |EBITS| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . Extension data . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|E|F| res | optional SL header paramaters as indicated by | +-+-+-+-+-+-+-+-+ the SLConfigDescriptor . | . . Media payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Usage of the format for MPEG-4 Flexmux-PDUs in draft-rgcc-avt-mpeg4flexmux-00.txt « What is suggested here is to define objects in the RTP payload, as it is proposed in draft-ietf-avt-mpeg4streams-01.txt. The RTP payload being a succession of ob-jects. Each object is byte aligned. Each object starting with its length. » « A payload object is either a protection data object, or a complete FlexMux packet. Each payload object follows an identification byte, its object type byte. The RTP payload starts with one object type byte. » « The object type byte syntax: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+ |G|E| XT | +-+-+-+-+-+-+-+ »
MPEG-4/RTP recent history • 12/98 Orlando, • draft-ietf-avt-rtp-mpeg4-00.txt, SL-packetized streams • draft-guillemot-avt-genrtp-00.txt, ES streams + flexible additional protection (if needed, eg. for streamed content) • 04/99 NY + 07/99 Oslo joint IETF/MPEG (phone) meetings • “No non-SL- and non-Systems ES RTP-mapping needed”: • “2 experimental RFCs ...” • 10/99 ISO Melbourne • JNB non-System AV ES-mapping proposed • 12/99 Washington • draft-jnb-mpeg4av-rtp-00.txt „the normative way on how MPEG-4 Audio/Visual streams ... mapped ... to RTP“
MPEG-4/RTP recent history • 03/2000 Adelaide, • draft-rgcc-avt-flexmuxmpeg4-00.txt, flexmux-packetized streams - • withdrawn last week in the Netherlands ?? • .... more to come?
Implementation status • Mapping/de-mapping completed • Integrating into IM1 as a DMIF plug-in (with CSELT) is ongoing • FEC implemented: duplicated headers, parity codes • Adaptivity for QoS monitoring under development • R-S under development
Information - Distribution • current code documentation • http://www-ks.rus.uni-stuttgart.de/PROJ/GP • ACTS COMIQS project ended february 2000 • http://www.ccett.fr/comiqs/welcome.htm • Used in 1 National Project (F, RNRT-VISI) • Continue in 2 European Projects (IST-SONG, IST-OPENISE) • Distributed to 4 Companies outside the above projects
Conclusion • Complexity of (future) MPEG-4 usage • Multiple streams (live and pre-encoded) with different QoS requirements • so far, multiple ways for handling protection in the different ESs (HEC specific to visual) • Stresses the need, for the sake of architectural « simplicity », • simple, single interface, avoiding parsers of the ESs • draft-ietf-avt-mpeg4streams-01.txt hasthe potential for an homogeneous way of handling efficient transport of the different types of MPEG-4 streams
Application Case of draft-ietf-avt-mpeg4streams-01.txtto MPEG-4 Visual streamsin draft-gc-avt-mpeg4visual-00.txt IETF AVT WG, Adelaide. March, 2000 Christine Guillemot, Paul Christ, Stefan Wesner
Summary • Application of drat-ietf-avt-mpeg4streams-01.txt to the transport of MPEG-4 visual streams • Common solution for • both live and pre- encoded content • Common solution for the different profiles
Visual Profiles • Simple Visual Profile: efficient, error resilient coding of rectangular video objects, suitable for applications on mobile networks. • Simple Scalable Profile:adds support for coding of temporal and spatial scalable objects, useful for applications which provide services at more than one level of quality due to bit-rate or decoder resource limitations. • Core Visual Profile: adds support for coding of arbitrary-shaped and temporally scalable objects, useful for applications such as those providing content-interactivity (Internet multimedia applications).
Visual Profiles (continued) • Main Visual Profile: adds support for coding of interlaced, semi-transparent, and sprite objects to the Core Visual Profile; useful for interactive and entertainment-quality broadcast and DVD applications. • N-Bit Visual Profile:adds support for coding video objects having pixel-depths ranging from 4 to 12 bits to the Core Visual Profile. • …. More for synthetic and for natural/synthetic hybrid visual content
Impact of Profiles on Syntax • Very elaborate and powerfull syntax. • HEC mechanism useable initially for protecting header parameters needed in the simple profile • Lately corrigendum (DCOR1) in order to cover header parameters for arbitrary shape objects • Not (yet?) for enhancement layers when scalability is used in simple scalable, core, main
Elements of syntax • Configuration information • global configuration information refering to the whole group of visual objects (visualobjectsequence()), • object configuration information refering to a single visual object (visualobject()) • object layer configuration information (visualobjectlayer()) • video object plane header (videoObjectPlane()) (for video)
Transmission of key segments • Two modes of transmission for visual object sequence layer, visual object layer and video object layer: • separate mode (in containers provided by MPEG-4 system (Ods) • combined mode (as part of the ES) • video object plane header as part of ES
Uniform way of handling protection of key segments • To avoid to have to support parsers in streaming applications • Same way of handling protection for real-time and pre-encoded content • simple and same interface Esdata dataLength number of padding bits at the end (if needed) degradationPriority and/or segment type (videoobjectlayer(), GOV header, video object plane header, video packet)
Sample RTP packet for MPEG-4 visualstreams 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|E| XT | LENGTH |EBITS| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . + eg. Video Object Plane header +-+-+-+-+-+-+-+-+ . |G|E|0| res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . Media Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+