W3C

Media Recording API

November 28, 2012

This version:
@@@
Latest published version:
@@@
Editors:
Jim Barnett, Genesys
Travis Leithead, Microsoft

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is not complete. It is subject to major changes and, while early experimentations are encouraged, it is therefore not intended for implementation. The Media Capture Task Force expects this specification to evolve significantly based on:

  • Privacy issues that arise when capturing media.
  • Technical discussions within the task force.
  • Experience gained through early experimentations.
  • Feedback received from other groups and individuals.

This document was published by the Web Real-Time Communication Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-media-capture@w3.org (subscribe, archives). All feedback is welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

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 (Web Real-Time Communication Working Group, Device APIs Working Group) 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.

1.0 Overview

This proposal attempts to make basic recording very simple, while still allowing for more complex use cases. In the simplest case, the application instatiates the MediaRecorder object, calls record() and then calls stopRecord() or waits for the MediaStream to be ended. The contents of the recording will be made available in the platform's default encoding via the dataavailable event. Functions are available to query the platform's available set of encodings, and to select the desired ones if the author wishes. The application can also choose how much data it wants to receive at one time. By default a Blob containing the entire recording is returned when the recording finishes. However the application can choose to receive smaller buffers of data at regular intervals.

2.0 Media Recorder API


[Constructor (MediaStream stream)]
interface MediaRecorder : EventTarget  {

    readonly attribute MediaStream mediaStream;
    readonly attribute Boolean recording;
             attribute EventHandler onrecording;
             attribute EventHandler onstoprecording;
             attribute EventHandler ondataavailable;
             attribute EventHandler onrecordingerror;
             attribute EventHandler onrecordingwarning;
    void                          record (optional long timeSlice);
    void                          stopRecording ();
    void                          requestData();
    AvailableRecordingFormats     getRecordingOptions ();
    void                          setRecordingOptions (RecordingFormat RequestedFormats);
};

The MediaRecorder() constructor takes one argument which must be of type MediaStream (see Media-Capture). When the constructor is invoked, the UA must construct a new MediaRecorder object, set its mediaStream attribute to be the provided MediaStream, set its recording attribute to 'false' and return the object.

2.1 Attributes

mediaStream of type MediaStream, readonly

The MediaStream passed in to the constructor.

recording of type Boolean, readonly

True if 'record()' has been called and not stopped. Otherwise False.

onrecording of type EventHandler

Called to handle the recording event.

onstoprecording of type EventHandler

Called to handle the stoprecording event.

ondataavailable of type EventHandler

Called to handle the dataavailable event. Note that the Blob (see FILEAPI) of recorded data is contained in this event and can be accessed via the 'detail' attribute.

onrecordingerror of type EventHandler

Called to handle the recordingerror event.

onrecordingwarning of type EventHandler

Called to handle the recordingwarning event.

2.2 Methods

record

When a MediaRecorder object’s record() method is invoked, the user agent must queue a task that runs the following steps:

  1. If recording is 'true', raise a recordingwarning event and abort these steps.
  2. Otherwise set recording to 'true' and wait until media becomes available from mediaStream.
  3. Once data becomes available raise a recordingevent and start gathering the data into a Blob (see FILEAPI).
  4. If the timeSlice argument has been provided, then once timeSlice milliseconds of data have been colleced, raise a dataavailable event containing the Blob of collected data, and start gathering a new Blob of data. Otherwise (if timeSlice has not been provided), continue gathering data into the original Blob.
  5. When the mediaStream is ended set recording to 'false' and stop gathering data.
  6. Then raise a dataavailable event containing the Blob of data.
  7. Finally, raise a stoprecording event.

Note that the stopRecording() and requestData() also affect the recording behavior.


The UA must record the MediaStream in such a way that the original Tracks can be retrieved at playback time. If any Track within the MediaStream is muted, the UA must insert black frames or silence until the Track is unmuted. If the UA is unable to start recording or at any point is unable to contine recording, it must raise a recordingerror event, follwowed by a dataavailable event containing the Blob it has gathered, follwed by the stoprecording event.

stopRecording

When a MediaRecorder object’s stopRecording method is invoked, the user agent must queue a task that runs the following steps:

  1. If recording is 'false', raise a recordingwarning event and abort these steps.
  2. Set recording to 'false' and stop gathering data.
  3. Raise a dataavailable event containing the Blob of data that has been gathered.
  4. Raise a recordingdone event
requestData

When a MediaRecorder object’s requestData() method is invoked, the user agent must queue a task that runs the following steps:

  1. If recording is 'false', raise a recordingwarning event and abort these steps.
  2. Raise a dataavailable event containing the current Blob of saved data.
  3. Creat a new Blob and gather subsequent data into it.
getRecordingOptions

When a MediaRecorder object’s getRecordingOptions() method is invoked, the user agent must return a availableRecordingFormats structure containing the set of recording formats that it supports.

setRecordingOptions

When a MediaRecorder object’s setRecordingOptions() method is invoked, the user agent must run the following steps:

  1. If recording is 'true', raise a recordingwarning event and abort these steps.
  2. Otherwise let encodings be the current set of encodings that are specified to be used for recording by the MediaRecorder. (If setRecordingOptions() has not yet been called, these will be the UA's defaults.)
  3. For each encoding format that is specified in the requestedFormats argument, if the UA does not support it, raise a recordingwarning event, set encodings back to its value in step 2, and terminate these steps. Otherwise replace the corresponding member of encodings with the specified value.

3.0 Dictionary AvailableRecordingFormats

dictionary AvailableRecordingFormats {
    sequence<DOMString> containerEncodingFormats;
    sequence<DOMString> audioEncodingFormats;
    sequence<DOMString> videoEncodingFormats;
};
containerEncodingFormats of type sequence<DOMtring>

A list of the container encoding formats that the platform supports.

audioEncodingFormats of type sequence<DOMtring>

A list of the audio encoding formats that the platform supports.

videoEncodingFormats of type sequence<DOMtring>

A list of the video encoding formats that the platform supports.

The UA must be able to play back any encoding format that it can record into. The UA must support a container format capable of holding at least two video Tracks and two audio Tracks.

3.1 Dictionary RecordingFormat

dictionary RecordingFormat {
    <DOMString> containerEncodingFormat;
    <DOMString> audioEncodingFormat;
    <DOMString> videoEncodingFormat;
};
containerEncodingFormat of type <DOMtring>

The container encoding format to use for recording. If it is not specified, the platform default will be used.

audioEncodingFormat of type <DOMtring>

The audio encoding format to use for recording. If it is not specified, the platform default will be used.

videoEncodingFormat of type <DOMtring>

The video encoding format to use for recording. If it is not specified, the platform default will be used.

4.0 Error Handling

If a fatal error occurs while recording is occuring, the UA must raise a recordingerror, followed by a dataavailable event, containing any data that it has gathered, and then a recordingdone event. The UA may set platform-specific limits, such those for the minimum and maximum Blob size that it will support, or the number of Tracks it will record at once. It must signal a fatal error if these limits are exceeded. If a non-fatal error occurs during recording, the UA should raise a recordingwarning event, with data indicating the nature of the problem, and continue recording.

5.0 Event summary

The following additional events fire on MediaRecorder objects:

Event name Interface Fired when...
recording Event The UA has started recording data on the Track.
stoprecording Event The UA has stopped recording data on the Track.
dataavailable CustomEvent The UA returns data to the application. This 'detail' attribute of this event contains a Blob of recorded data.
recordingerror CustomEvent A fatal error has occurred and the UA has stopped recording. More detailed error information is available in the 'detail' attribute.
recordingwarning CustomEvent A problem has occurred, but the UA has not stopped recording. More detailed information is available in the 'detail' attribute.

A. Open Issues

  1. Do we need an MTI format?
  2. Do we need a "setSyncPoint()" operator and a "syncpoint" signal, so that the client can tell the recorder to insert a point at which a recording can be broken up (typically a new I-frame)?
  3. Does it make sense to set audiorecordingformat and videorecordingformat separately? Would it be simpler to specify a container format with options for codecs?

B. References

B.1 Normative references

[FILE-API]
Arun Ranganathan; Jonas Sicking. File API. 25 October 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-FileAPI/
[Media-Capture]
Daniel C. Burnett; Arant Narayan. Media Capture and Streams. 15 November 2012. W3C Editors' Draft. (Work in progress.) URL: http://dev.w3.org/2011/webrtc/editor/getusermedia.html