1 / 24

Christine Guillemot, Paul Christ , Stefan Wesner [, Anders Klemets]

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].

indra
Télécharger la présentation

Christine Guillemot, Paul Christ , Stefan Wesner [, Anders Klemets]

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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]

  2. 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

  3. 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)

  4. 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)

  5. 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

  6. 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

  7. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  8. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  9. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  10. 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 | +-+-+-+-+-+-+-+ »

  11. 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“

  12. 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?

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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).

  19. 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

  20. 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

  21. 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)

  22. 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

  23. 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)

  24. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

More Related