"Media Capture from DOM Elements"

Editor’s Draft,

This version:
https://w3c.github.io/mediacapture-fromelement/
Feedback:
public-media-capture@w3.org with subject line “[mediacapture-fromelement] … message topic …” (archives)
Editors:
Martin Thomson (Mozilla)
(Google Inc.)
(Google Inc.)
Participate:
Mailing list
GitHub repo (new issue, open issues)

Abstract

This document defines how a stream of media can be captured from a DOM element, such as a <video>, <audio>, or <canvas> element, in the form of a MediaStream.

Status of this document

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 file an issue on the specification repository or send them to subscribe, archives).

This document was produced by the Device and Sensors Working Group and the Web Real-Time Communications Working Group.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

1. Introduction

This document describes an extension to both HTML media elements and the HTML canvas element that enables the capture of the output of the element in the form of streaming media.

The captured media is formed into a MediaStream ([mediacapture-streams]), which can then be consumed by the various APIs that process streams of media, such as [WEBAUDIO], or [WEBRTC].

2. HTML Media Element Media Capture Extensions

This section defines a method captureStream() on HTMLMediaElements.

Both MediaStream and HTMLMediaElement expose the concept of a track. Since there is no common type used for HTMLMediaElement, this document uses the term track to refer to either a VideoTrack or an AudioTrack. MediaStreamTrack is used to identify the media in a MediaStream.

partial interface HTMLMediaElement {
    MediaStream captureStream();
};

2.1. Methods

captureStream()
captureStream() method produces a real-time capture of the media that is rendered to the media element.

The captured MediaStream comprises of MediaStreamTracks that render the content from the set of VideoTrack.selected (for VideoTracks, or other exclusively selected track types) or AudioTrack.enabled (for AudioTracks, or other track types that support multiple selections) tracks from the media element. If the media element does not have a selected or enabled tracks of a given type, then no MediaStreamTrack of that type is present in the captured stream.

A <video> element can therefore capture a video MediaStreamTrack and any number of audio MediaStreamTracks. An <audio> element can capture any number of audio MediaStreamTracks. In both cases, the set of captured MediaStreamTracks could be empty.

Unless and until there is a track of given type that is selected or enabled, no MediaStreamTrack of that type is present in the captured stream. In particular, if the media element does not have a source assigned, then the captured MediaStream has no tracks. Consequently, a media element with a ready state of HAVE_NOTHING produces no captured MediaStreamTrack instances. Once metadata is available and the selected or enabled tracks are determined, new captured MediaStreamTrack instances are created and added to the MediaStream.

A captured MediaStreamTrack ends when playback ends (and the ended event fires) or when the track that it captures is no longer selected or enabled for playback. A track is no longer selected or enabled if the source is changed by setting the src or srcObject attributes of the media element. The steps in stop() are performed on the MediaStreamTrack when it ends.

The set of captured MediaStreamTracks change if the source of the media element changes. If the source for the media element ends, a different source is selected.

If the selected VideoTrack or enabled AudioTracks for the media element change, an addtrack event with a new MediaStreamTrack is generated for each track that was not previously selected or enabled; and a removetrack event is generated for each track that ceases to be selected or enabled. A MediaStreamTrack MUST be ended prior to being removed from the MediaStream.

Since a MediaStreamTrack can only end once, a track that is enabled, disabled and re-enabled will be captured as two separate tracks. Similarly, restarting playback after playback ends causes a new set of captured MediaStreamTrack instances to be created. Seeking during playback without changing track selection does not generate events or cause a captured MediaStreamTrack to end.

The MediaStreamTracks that comprise the captured MediaStream become muted or not muted as the tracks they capture change state. At any time, a media element might not have active content available for capture on a given track for a variety of reasons:

  • Media playback could be paused.
  • A track might not have content for the current playback time if that time is either before the content of that track starts or after the content ends.
  • A MediaStreamTrack that is acting as a source could be muted or not enabled.
  • The contents of the track might become inaccessible to the current origin due to cross-origin protections. For instance, content that is rendered from an HTTP URL can be subject to a redirect on a request for partial content, or the enabled or selected tracks can change to include cross-origin content.

Absence of content is reflected in captured tracks through the muted attribute. A captured MediaStreamTrack MUST have a muted attribute set to true if its corresponding source track does not have available and accessible content. An event named mute is raised on the MediaStreamTrack when content availability changes.

What output a muted capture produces as a result will vary based on the type of media: a VideoTrack ceases to capture new frames when muted, causing the captured stream to show the last captured frame; a muted AudioTrack produces silence.

Whether a media element is actively rendering content (e.g., to a screen or audio device) has no effect on the content of captured streams. Muting the audio on a media element does not cause the capture to produce silence, nor does hiding a media element cause captured video to stop.

Captured audio from an element with an effective playback rate other than 1.0 MUST be time-stretched. An unplayable playback rate causes the captured audio track to become muted.

3. HTML Canvas Element Media Capture Extensions

The captureStream() method is added to the HTMLCanvasElement. The resulting CanvasCaptureMediaStreamTrack provides methods that allow for controlling when frames are sampled from the canvas.

partial interface HTMLCanvasElement {
    MediaStream captureStream(optional double frameRequestRate);
};

3.1. Methods

captureStream(optional double frameRequestRate)
This method produces a real-time video capture of the surface of the canvas. The resulting MediaStream has a single video CanvasCaptureMediaStreamTrack that matches the dimensions of the canvas element.

Content from a canvas that is not origin-clean MUST NOT be captured. This method throws a SecurityError exception if the canvas is not origin-clean.

A captured stream MUST immediately cease to capture content if the origin-clean flag of the source canvas becomes false after the stream is created by captureStream(). The captured MediaStreamTrack MUST become muted, producing no new content while the canvas remains in this state.

Each track that captures a canvas has an internal frameCaptureRequested property that is set to true when a new frame is requested from the canvas.

The value of the frameCaptureRequested property on all new tracks is set to true when the track is created. On creation of the captured track with a specific, non-zero frameRequestRate, the user agent starts a periodic timer at an interval of 1/frameRequestRate seconds. At each activation of the timer, the frameCaptureRequested property is set to true.

In order to support manual control of frame capture with the requestFrame() method, browsers MUST support a value of 0 for frameRequestRate. However, a captured stream MUST request capture of a frame when created, even if frameRequestRate is zero.

This method throws a NotSupportedError if frameRequestRate is negative.

A new frame is requested from the canvas when frameCaptureRequested is true and the canvas is painted. Each time that the captured canvas is painted, execute the following steps, for each track capturing from the canvas:

  1. If new content has been drawn to the canvas since it was last painted, and if the frameCaptureRequested internal property of track is set, add a new frame to track containing what was painted to the canvas.
  2. If a frameRequestRate value was specified, set the frameCaptureRequested internal property of track to false.

When adding new frames to track containing what was painted to the canvas, the alpha channel content of the canvas must be captured and preserved if the canvas is not fully opaque. The consumers of this track might not preserve the alpha channel.

This algorithm results in a captured track not starting until something changes in the canvas.
Parameter Type Nullable Optional Description
frameRequestRate double
Return type: MediaStream

3.2. CanvasCaptureMediaStreamTrack

CanvasCaptureMediaStreamTrack is an extension of MediaStreamTrack that provide a single requestFrame() method. Applications that depend on tight control over the rendering of content to the media stream can use this method to control when frames from the canvas are captured.

interface CanvasCaptureMediaStreamTrack : MediaStreamTrack {
    readonly attribute HTMLCanvasElement canvas;
    void requestFrame();
};

3.2.1. Attributes

canvas, of type HTMLCanvasElement, readonly
The HTMLCanvasElement element being captured.

3.2.2. Methods

requestFrame()
This method allows applications to manually request that a frame from the canvas be captured and rendered into the track. In cases where applications progressively render to a canvas, this allows applications to avoid capturing a partially rendered frame.
As currently specified, this results in no SecurityError or other error feedback if the canvas is not origin-clean. In part, this is because we don’t track where requests for frames come from. Do we want to highlight that?

4. Security considerations

Media elements can render media resources from origins that differ from the origin of the media element. In those cases, the contents of the resulting MediaStreamTrack MUST be protected from access by the document origin.

How this protection manifests will differ, depending on how the content is accessed. For instance, rendering inaccessible video to a canvas element causes the origin-clean property of the canvas to become false; attempting to create a Web Audio MediaStreamAudioSourceNode succeeds, but produces no information to the document origin (that is, only silence is transmitted into the audio context); attempting to transfer the media using RTCPeerConnection results in no information being transmitted.

The origin of the media that is rendered by a media element can change at any time. This is even the case for a single media resource. User agents MUST ensure that a change in the origin of media doesn’t result in exposure of cross origin content.

5. Acknowledgements

This document is based on the stream processing specification [streamproc] originally developed by Robert O’Callahan.

Conformance

Document conventions

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:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Conformance Classes

A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents.

A conformant server must implement all the requirements listed in this specification that are applicable to servers.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[MEDIACAPTURE-STREAMS]
Daniel Burnett; et al. Media Capture and Streams. URL: https://w3c.github.io/mediacapture-main/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[WebIDL]
Cameron McCormack; Boris Zbarsky; Tobie Langel. Web IDL. URL: https://heycam.github.io/webidl/

Informative References

[STREAMPROC]
Robert O'Callahan. MediaStream Processing API. 31 May 2012. NOTE. URL: https://www.w3.org/TR/streamproc/
[WEBAUDIO]
Paul Adenot; Chris Wilson; Chris Rogers. Web Audio API. URL: https://webaudio.github.io/web-audio-api/
[WEBRTC]
Adam Bergkvist; et al. WebRTC 1.0: Real-time Communication Between Browsers. URL: https://w3c.github.io/webrtc-pc/

IDL Index

partial interface HTMLMediaElement {
    MediaStream captureStream();
};

partial interface HTMLCanvasElement {
    MediaStream captureStream(optional double frameRequestRate);
};

interface CanvasCaptureMediaStreamTrack : MediaStreamTrack {
    readonly attribute HTMLCanvasElement canvas;
    void requestFrame();
};