This is a public copy of the editors’ draft.
It is provided for discussion only and may change at any moment.
Its publication here does not imply endorsement of its contents by W3C.
Don’t cite this document other than as work in progress.
If you wish to make comments regarding this document, please send them to firstname.lastname@example.org (subscribe, archives).
When sending e-mail,
please put the text “webrtc-media-streams” in the subject,
preferably like this:
“[webrtc-media-streams] …summary of comment…”.
All comments are welcome.
The [WEBRTC-NV-USE-CASES] document describes several functions that
can only be achieved by access to media (requirements N20-N22),
including, but not limited to:
Virtual Reality Gaming
These use cases further require that processing can be done in worker
threads (requirement N23-N24).
requires such processing to be done on encoded media, not just the raw
This specification gives an interface inspired by [WEB-CODECS] to
provide access to such functionality while retaining the setup flow of
This iteration of the specification provides access to encoded media,
which is the output of the encoder part of a codec and the input to the
decoder part of a codec.
The Streams definition doesn’t use WebIDL much, but the WebRTC spec does.
This specification shows the IDL extensions for WebRTC.
It uses an extension to RTCConfiguration in order to notify the RTCPeerConnection that insertable streams will be used, and uses
an additional API on RTCRtpSender and RTCRtpReceiver to
insert the processing into the pipeline.
At the time when a codec is initialized as part of the encoder, and the
corresponding flag is set in the RTCPeerConnection's RTCConfiguration argument, ensure that the codec is disabled and produces no output.
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in the normative parts of this document
are to be interpreted as described in RFC 2119.
However, for readability,
these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative
except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note”
and are set apart from the normative text with class="note", like this: