1 / 8

RTP Payload Format for MPEG-4 Streams

RTP Payload Format for MPEG-4 Streams. M. Reha Civanlar AT&T Labs - Research 44 th IETF Minneapolis, MN. Why MPEG-4?. Added values: New codecs new functionality, e.g. non-rectangular images new media, e.g. facial animation parameters better compression

duke
Download Presentation

RTP Payload Format for MPEG-4 Streams

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 Format for MPEG-4 Streams M. Reha Civanlar AT&T Labs - Research 44th IETF Minneapolis, MN

  2. Why MPEG-4? Added values: • New codecs • new functionality, e.g. non-rectangular images • new media, e.g. facial animation parameters • better compression • Dynamic session descriptions (Object Descriptors (OD)) • Dynamic Scene Descriptions (SD) 44th IETF - Minneapolis, MN

  3. Recommendation: • Map MPEG-4 Synchronization Layer (SL) packets to RTP, use RTP header followed by an optional SL header that is compressed by removing what is covered by RTP • draft-ietf-avt-rtp-mpeg4-01 by M. Reha Civanlar, Vahe Balabanian, Andrea Basso, Stephen L. Casner, Carsten Herpel, Colin Perkins 44th IETF - Minneapolis, MN

  4. MPEG-4 Payload Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : contributing source (CSRC) identifiers : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |SL Packet Header (variable # of bytes) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP | | | SL Packet Payload (byte aligned) | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44th IETF - Minneapolis, MN

  5. RTP Header Fields Usage • Payload Type (PT): assigned in a profile for a particular class of applications or dynamic • Marker (M) bit: Set to one to mark the last fragment (or only fragment) of an AU • Extension (X) bit: Defined by the RTP profile used • Sequence Number: Derived from the sequenceNumber field of the SL packet by adding a constant random offset • If sequenceNumber is shorter, it is extended to 16 bits • The sequenceNumber is removed from the included SL header • Deliberately repeated packets are assigned different sequence numbers • If the sequenceNumber field does not exist, a Sequence Number is generated by RTP packetizer • SSRC: set as described in RFC1889. A mapping between the ES identifiers (ESIDs) and SSRCs should be provided through out-of-band means. 44th IETF - Minneapolis, MN

  6. RTP Header Fields Usage • Timestamp: Set to the value in the compositionTimeStamp (CTS) field of the SL packet • resolution is transmitted out-of-band • if CTS is shorter than 32 bits, the unspecified, significant bits of the timestamp are set to zero • if CTS is longer than 32 bits, this payload format can’t be used • if CTS is not present in the current SL packet,but has been present in a previous SL packet, the same value MUST be taken again as the timestamp • if CTS is never present in SL packets for this stream, the RTP packetizer SHOULD convey a reading of a local clock at the time the RTP packet is created • timestamps are recommended to start at a random value for security reasons • CTS is removed from the SL header • CC and CSRC fields are used as described in RFC 1889 44th IETF - Minneapolis, MN

  7. To be defined: • RTP - ES Mapping: Use SDP attributes to convey the RTP-stream to ES-stream mapping (e.g. a=x-mpeg4-esid:2301 as a media stream attribute) • Initial Object Descriptor (IOD) • to be transmitted out-of-band. • may be part of the SDP information (size problem) • representation format in SDP is to be determined. 44th IETF - Minneapolis, MN

  8. Multiplexing requirements • Multiplexing is unavoidable due to the large number of ESs that may be used in each MPEG-4 session. • The ESs multiplexed in one stream can change frequently during a session. Consequently, • coding type • individual packet size • temporal relationships between the multiplexed data units must be handled dynamically. • In general, an SL packet does not contain information about its size. The multiplexing scheme should be able to delineate the multiplexed packets whose lengths may vary from a few bytes to close to the path-MTU. • The multiplexing scheme should have a mechanism to determine the ES identifier (ES_ID) for each of the multiplexed packets. ES_ID is not a part of the SL header. This may need to be handled out-of-band. 44th IETF - Minneapolis, MN

More Related