Codec agnostic RTP payload format for video
draft-codec-agnostic-rtp-payload-format-00

Document Type Replaced Internet-Draft (individual)
Authors Sergio Garcia Murillo  , Alexandre Gouaillard 
Last updated 2021-02-19
Replaced by draft-gouaillard-avtcore-codec-agn-rtp-payload
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-gouaillard-avtcore-codec-agn-rtp-payload
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-codec-agnostic-rtp-payload-format-00.txt

Abstract

RTP Media Chains usually rely on piping encoder output directly to packetizers. Media packetization formats often support a specific codec format and optimize RTP packets generation accordingly. With the development of Selective Forward Unit (SFU) solutions, that do not process media content server side, the need for media content processing at the origin and at the destination has arised. RTP Media Chains used e.g. in WebRTC solutions are increasingly relying on application-specific transforms that sit in-between encoder and packetizer on one end and in-between depacketizer and decoder on the other end. This use case has become so important, that the W3C is standardizing the capacity to access encoded content with the [WebRTCInsertableStreams] API proposal. An extremely popular use case is application level end-to-end encryption of media content, using for instance [SFrame]. Whatever the modification applied to the media content, RTP packetizers can no longer expect to use packetization formats that mandate media content to be in a specific codec format. In the extreme cases like encryption, where the RTP Payload is made completely opaque to the SFUs, some extra mechanism must also be added for them to be able to route the packets without depending on RTP payload or payload headers. The traditionnal process of creating a new RTP Payload specification per content would not be practical as we would need to make a new one for each codec-transform pair. This document describes a solution, which provides the following features in the case the encoded content has been modified before reaching the packetizer: - a paylaod agnostic RTP packetization format that can be used on any media content, - a signalling mechanism for the above format and the inner payload, Both of the above mechanism are backward compatible with most of (S)RTP/RTCP mechanisms used for bandwidth estimation and congestion control in

Authors

Sergio Garcia Murillo (sergio.garcia.murillo@cosmosoftware.io)
Alexandre Gouaillard (alex.gouaillard@cosmosoftware.io)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)