The HTML5 specification gives a detailed description of the algorithm to be applied when rendering a media content.
The text is however sometimes a bit cryptic, with a lot of details only relevant to implementers. I will try in this article to give a simplified description of the expected behaviour of a Media element from a web application developer perspective.
One may distinguish typically three phases:
- initialization: the Media element selects a media source and retrieves its properties (duration, size)
- buffering: the Media element retrieves and store as many data as required to start rendering the content
- playback: the Media element decodes and renders the content
A newly inserted HTML Media element will be initialized only:
- when its
srcattribute is set,
- when a children
sourceelement is inserted.
An initialized HTML Media element will be reset only:
- when its
srcattribute is modified,
- when its
load()method is invoked.
Note: An HTML Media element will not be reset when a
child is inserted or modified.
During the initialization phase, the user-agent will apply the Media resource selection algorithm. to select the most appropriate media resource.
At the end of the initialization phase, the Media element should have:
currentSrcset to the actual Media source URL.
The algorithm may be blocked at this stage until an explicit user request to play the content. This happens in particular:
- if the Media element
preloadattribute has been set to
- on some user-agents (typically apple mobile devices) that want to prevent the user to be charged for useless data transfer (Please refer to this article for details).
Otherwise, the browser will immediately transition to the buffering phase.
During the buffering, phase, the user-agent will fetch the selected Media resource as described in the Media resource fetch algorithm.
autoplay attribute of the
is set to
true, or if the
play() method has
been called explicitly, the user-agent will immediately try to download
as much data as needed to play the content through.
Otherwise, the amount of data loaded at this stage is mostly implementation
The application developer may however influence the browser preloading
behaviour by setting the
preload attribute to:
metadatato download only what is needed to determine the duration and dimension of the content,
autoto download proactively as much data as needed to be able to start playback immediately.
At the end of the buffering phase, the Media element could have its
readyState set to:
HAVE_META_DATA: only the duration and the dimension of the content are then available. At this stage, the browser will have sent a
HAVE_CURRENT_DATA: a single frame of content is available (and can be used to be displayed in a canvas for instance). At this stage, the browser will have sent in addition a
HAVE_FUTURE_DATA: enough frames are available to start playback. At this stage, the browser will have sent in addition a
HAVE_ENOUGH_DATA: enough frames are available to play the content through. At this stage, the browser will have sent in addition a
autoplay attribute of the Media element is set to
true, the browser will wait until it reaches the
HAVE_ENOUGH_DATA state to transition to the next step and
start rendering content.
However, if the
play method has been called explicitly,
the playback will start as soon as the
state is reached.
As mentioned in the previous paragraph, the Media element cannot start
playing content before having reached at least the
state that corresponds to the
The user-agent constructs a media timeline based on the metadata retrieved from the stream. In most case, it will be the timeline as described in the original stream, with the following exceptions:
- if the Media resource specifies an explicit start date, the user-agent
will store it in the
startDateattribute, but will define its timeline relatively to it, starting from zero.
- if the Media resource specifies a discontinuous timeline, the user-agent will expand the timeline of the first content to the entire stream.
The application developer can specifiy an initial playback position by either:
- setting the Media element
currentTimeattribute to that position,
- specifying the position using a Media fragment URI.
If no specific playback position has been specified, the user-agent will start the playback at the initial playback position defined in the stream.
During playback, the browser exposes the ‘official’ playback position in the
currentTime attribute, that doesn’t necessarily reflect
accurately the real playback position.
The speed at which the content is being played is exposed by the user-agent
playbackRate attribute of the Media element.
Unless specified differently in the
attribute, a content will be initially played at an 1.0 rate.
If at any time during playback the Media element runs out of data, it will generate a
waiting event and switch back to the buffering phase.
When the end of the stream is reached:
endedattribute is set to
endedevent is emitted,
- if the
loopattribute is set to true, the playback resumes at the earliest playback position: otherwise it stops.