Codec agnostic RTP payload format for video

Document Type Active Internet-Draft (individual)
Authors Sergio Garcia Murillo  , Alexandre Gouaillard 
Last updated 2021-02-19
Replaces draft-codec-agnostic-rtp-payload-format
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
On Agenda avtcore at IETF-110
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
AVTCORE                                                S. Garcia Murillo
Internet-Draft                                             A. Gouaillard
Intended status: Standards Track                          CoSMo Software
Expires: August 23, 2021                               February 19, 2021

              Codec agnostic RTP payload format for video


   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

Garcia Murillo & GouaillaExpires August 23, 2021                [Page 1]
Internet-Draft Codec agnostic RTP payload format for video February 2021

   RTP/SRTP/webrtc, including but not limited to SSRC, RED, FEC, RTX,
   NACK, SR/RR, REMB, transport-wide-CC, TIMBR, .... It as illustrated
   by existing implementations in chrome, safari, and Medooze.

   This document also describes a solution to allow SFUs to continue
   performing packet routing on top of this generic RTP packetization

   This document complements the SFrame (media encryption), and
   Dependency Descriptor (AV1 payload annex) documents to provide an
   End-to-End-Encryption solution that would sit on top of SRTP/Webrtc,
   use SFUs on the media back-end, and leverage W3C APIs in the browser.
   A high level description of such system will be provided as an
   informational I-D in the SFrame WG and then cited here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 23, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Garcia Murillo & GouaillaExpires August 23, 2021                [Page 2]
Internet-Draft Codec agnostic RTP payload format for video February 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
Show full document text