]> Meta

jcenzano@meta.com

Meta

afrind@meta.com

Web and Internet Transport Media Over QUIC Media over QUIC This protocol can be used to send and receive video and audio over Media over QUIC Transport . About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This protocol specifies a simple mechanism for sending media (video and audio) over MOQT for both live-streaming and VC use cases. The protocol is flexible in order to support this range of use cases. Media parameters can be updated in the middle of a the track (ex: frame rate, resolution, codec, etc) The protocol defines a low overhead packaging format optimized for WebCodecs called WCP that is extensible to other formats such as FMP4. This is not LoC , but will eventually be merged with that specification.

Protocol Operation

Track Names The publisher selects a namespace of their choosing, and sends an ANNOUNCE message for this namespace. Since MoQT tracks are immutable, each new broadcast MUST have a unique namespace. It is RECOMMENDED that the last tuple of the track namespace contain a broadcast timestamp to ensure uniqueness. Within the namespace the publisher offers media tracks named videoX and audioX, where X is an integer starting at 0 and increasing by 1 for each additional track of a given type. For example, if the publisher issues 2 audio tracks and 1 video track, the track names available will be video0, audio0, and audio1. The subscriber will consider all of those tracks belonging to the same namespace as part of the same synchronization group (timestamps aligned to the same timeline).

Mapping Tracks to MoQT Object Model For the video track, the publisher begins a new group at the start of each IDR (so object 0 will be always an IDR Keyframe), and each group contains a single subgroup. Each object has the format described in . For the audio track, the publisher begins a new group with each audio object, and each group contains a single subgroup. Each object has the format described in . TODO: Datagram forwarding preference could be used, but has problems if audio frame does not fit in a single UDP payload.

Timestamps To avoid using fractional numbers and having to deal with rounding errors, timestamps will be expressed with two integers:

• timestamp numerator (ex: PTS, DTS, duration)
• timebase

To convert a timestamp into seconds you just need to: timestamp(s) = timestamp numerator / timebase Example:

Object Format All objects this protocol have the following format.

MOQT Media object

• Media Type: Indicates what kind of media payload will follow.

Media Types

Code	Value
0x0	Video H264 in AVCC with WCP
0x1	Audio Opus bitstream

• Media payload: Media type specific payload

Video H264 in AVCC with WCP Payload Format

MOQT Media video h264 WCP

• Seq ID: Monotonically increasing counter for this media track.
• PTS Timestamp: Presentation timestamp in timebase.

TODO: Varint does NOT accept easily negative values, so it could be challenging to encode at start (priming).

• DTS Timestamp: Display timestamp in timebase. If B frames are not used, the encoder SHOULD set this to the same value as PTS.

TODO: Varint does NOT accept easily negative values, so it could be challenging to encode at start (priming).

• Timebase: Denominator used to calculate PTS, DTS, and Duration.
• Duration: Duration of Payload in timebase. It will be 0 if not set.
• Wall Clock: Epoch time in ms when this frame started being captured. It will be 0 if not set.
• Metadata Size: Size in bytes of the metadata section. It will be 0 when no metadata is present.
• Metadata: Extra data needed to decode this stream. This will be AVCDecoderConfigurationRecord as described in section 5.3.3.1, with field lengthSizeMinusOne = 3 (So length = 4). If any other size length is indicated (in AVCDecoderConfigurationRecord), the receiver SHOULD close the session with a Protocol Violation error. Any change in encoding parameters MUST send a new AVCDecoderConfigurationRecord
• Payload: H264 with bitstream AVC1 format as described in section 5.3. Using 4 bytes size field length.

Audio Opus bitstream Payload Format

MOQT Media audio Opus WCP

• Seq Id: Monotonically increasing counter for this media track.
• PTS Timestamp: Indicates PTS in timebase.

TODO: Varint does NOT accept easily negative, so it could be challenging to encode at start (priming).

• Timebase: Denominator used to calculate PTS and Duration.
• Sample Freq: Sample frequency used in the original signal (before encoding).
• Num Channels: Number of channels in the original signal (before encoding).
• Duration: Duration of Payload in timebase. It will be 0 if not set.
• Wall Clock: Epoch time in ms when this frame started being captured. It will be 0 if not set.
• Payload: Opus packets, as described in - section 3

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References Discord Meta Cisco Google Google This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. ISO This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Cisco Cisco Microsoft This specification describes a media container format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC transport (MOQ), with the goal of it being a low-overhead format. It also defines the LOC Streaming Format for the MOQ Common Catalog format for publishers to annouce and describe their LOC tracks and for subscribers to consume them.

Acknowledgments TODO acknowledge.