RTP Payload for MPEG4 with Flexible Error Resiliency draftietfavtmpeg4streams00'txt proposed experim

1
RTP Payload for MPEG-4with Flexible Error
Resiliency draft-ietf-avt-mpeg4streams-00.txtpro
posed experimental RFCformerly
draft-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 gt 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
-------------------------
------- 00 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
-------------------------
------- GE XT
LENGTH EBITS
------------------------

.
Extension data (e.g. VOP header)
-------- .
GE0 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
-------------------------
------- GEF 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
-------------------------
------- GE XT
LENGTH EBITS
------------------------

. .
Extension data
.

-------------------------
------- GEF 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
------- GE 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 has the
• 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 (visualobjectsequenc
  e()),
• 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
-------------------------
------- GE XT
LENGTH EBITS
------------------------

. eg.
Video Object Plane header
-------- .
GE0 res
-------------------------
-------
. .
Media Payload
---------------------
-----------