Click here to load reader

4/1/98Common Generic RTP Payload Format 1 Common Generic RTP Payload Format Anders Klemets

  • View
    224

  • Download
    2

Embed Size (px)

Text of 4/1/98Common Generic RTP Payload Format 1 Common Generic RTP Payload Format Anders Klemets

  • Slide 1
  • 4/1/98Common Generic RTP Payload Format 1 Common Generic RTP Payload Format Anders Klemets
  • Slide 2
  • 4/1/98Common Generic RTP Payload Format 2 RTP Payload Formats 4 Each codec bitstream requires an RTP P.F. Defines how the bitstream is encapsulated in RTP. May define a Payload Format Header that should be included in the RTP packet. May use knowledge of the codec to provide resiliency against lost RTP packets. Redundant information. Independently decodable packets.
  • Slide 3
  • 4/1/98Common Generic RTP Payload Format 3 Problems 4 Servers need a P.F. implementation for each supported codec bitstream. Each new codec requires upgrading the server. Server administrator must trust content provider and software vendor. 4 Extensible file formats that use many codecs. Examples: ASF, QuickTime, MPEG-4 File Format 4 Lengthy standardization process. What if I want to use my new codec now?
  • Slide 4
  • 4/1/98Common Generic RTP Payload Format 4 Generic RTP Payload Formats 4 A codec independent RTP P.F. is needed 4 Multiple file format dependent proposals: QuickTime ASF MPEG-4 File Format 4 The Common Generic RTP Payload Format: codec independent file format independent provides common framework for specialized P.F.s
  • Slide 5
  • 4/1/98Common Generic RTP Payload Format 5 Overview of features 4 Support for fragmentation codec-aware fragmentation codec-unaware fragmentation 4 Support for grouping Fragments may be grouped, allowing fixed size packets 4 Extensibility Uses grouping mechanism Extra timestamps, flags, duration fields, etc., go here
  • Slide 6
  • 4/1/98Common Generic RTP Payload Format 6 Codec-unaware fragmentation 4 Simple network layer fragmentation. 4 If a fragment is lost, all other fragments of the same PDU must be discarded.
  • Slide 7
  • 4/1/98Common Generic RTP Payload Format 7 Codec-aware fragmentation 4 Fragment boundaries chosen by app. layer May allow a partial App. Unit to be decoded 4 OFFSET field gives placement of fragment 4 FRAG field gives fragment sequence number Separates fragments of different App. Units.
  • Slide 8
  • 4/1/98Common Generic RTP Payload Format 8 Nested fragmentation 4 Codec-aware and codec-unaware fragmentation can be combined. 4 Example: 1. Codec-aware fragments are read from a file. 2. Some of the fragments have a size that is > MTU. 3. Codec-unaware fragmentation is applied on the fragments that exceed the MTU size.
  • Slide 9
  • 4/1/98Common Generic RTP Payload Format 9 Grouping (bundling) 4 RTP packets may contain multiple PDUs. TIMESTAMP DELTA field allows for different presentation times. 4 Fragments (of both kinds) may be grouped. Allows for constant size RTP packets. 4 Grouped elements can be tagged as Extension Data Allows arbitrary extension headers for each PDU.
  • Slide 10
  • 4/1/98Common Generic RTP Payload Format 10 Extension Data 4 Allows arbitrary extensions (specify thru SDP?) 4 Example of extensions that can be ignored: Send Time timestamp Duration field Key Frame flag, etc. 4 Extensions that cannot safely be ignored: Multiplexing of multiple logical streams into one RTP packet. C.f. FlexMux in MPEG-4
  • Slide 11
  • 4/1/98Common Generic RTP Payload Format 11 Grouping example 1
  • Slide 12
  • 4/1/98Common Generic RTP Payload Format 12 Grouping example 2
  • Slide 13
  • 4/1/98Common Generic RTP Payload Format 13 Overhead per RTP packet
  • Slide 14
  • 4/1/98Common Generic RTP Payload Format 14 Conclusion A generic RTP payload format with: 4 minimalist set of features features interact, can be combined attempt to cover most usage scenarios 4 low-overhead packet format 4 ease of extensibility the Common format can be extended to a Specialized format