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

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.

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?

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

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

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.

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

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.

9. 4/1/98Common Generic RTP Payload Format 9 Grouping (bundling) 4 RTP packets may contain multiple PDU’s. –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.

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

11. 4/1/98Common Generic RTP Payload Format 11 Grouping example 1

12. 4/1/98Common Generic RTP Payload Format 12 Grouping example 2

13. 4/1/98Common Generic RTP Payload Format 13 Overhead per RTP packet

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