Day 98 of 100DaysOfSpec, media elements, contd.

I am reading and taking notes on the HTML specifications for 100 days as part of #The100DayProject. Read the initial intent/backstory. I am a Microsoft employee but all opinions, comments, etc on this site are my own. I do not speak on behalf of my employer, and thus no comments should be taken as representative of Microsoft's official opinion of the spec. Subsections not listed below were read without comment.

UAs = user agents = browsers, etc.

Continuing to read in 4.7.10.5 Loading the media resource

The resource fetch algorithm, contd.

Headings below are my own.

Algorithm when resource is available

• When the algorithm is able to determine the media resource’s duration, dimensions, and “other metadata”, that means the resource is usable. This is when the UA can start doing timeline (playback positions, etc) and duration work. This is also when the height and width attributes are set, and a resize event is fired. At the end of this work, the readyState attribute is set to HAVE_METADATA (+ loadedmetadata DOM event, for you scripting folks).
• After this work, the UA enables relevant audio/video tracks specified on the media resource in the audioTracks/videoTracks object. The first one listed in videoTracks is the selected video track, and all the others are disabled. This step can be triggered again by other events.
• “Once the readyState attribute reaches HAVE_CURRENT_DATA, after the loadeddata event has been fired, set the element's delaying-the-load-event flag to false. This stops delaying the load event.” The UA would also stop any buffering at this point.
• A UA is required to determine a media resource’s duration before playing the file.

Algorithm after the media resource has been fetched (possibly before decoded)

• UAs fire progress event, set networkState to NETWORK_IDLE, fire suspend event.
• Can reset networkState to NETWORK_LOADING if the UA ever needs to get more data.

Algorithm after a connection interruption forces the UA to give up fetching (some data has been received)

• Fetching process gets canceled.
• The UA reports an error—and fires an error event—and then the networkState is at NETWORK_IDLE.
• UA has to stop delaying the load event.
• The whole resource selection algorithm is aborted.

Algorithm if the media data is corrupted

• Like above, fetching gets cancelled, error stuff gets set/fired.
• If the readyState attribute’s value is “equal to” HAVE_NOTHING, the element’s poster frame is shown. Some conditional outcomes here for networkState.
• Like above, stop delaying load and abort the algorithm.

Algorithm if the user aborted the fetching process

(For example, pressing a “stop” button). This part of the process is not triggered by the load method itself being invoked during the algorithm.

• The steps are pretty much the same as the last case, except that the error code is MEDIA_ERR_ABORTED, and an abort event is fired instead of an error event.

Algorithm if the media data has “non-fatal errors or uses, in part, codecs that are unsupported”

The server has to cause the UA to render what it can handle. All other data is ignored.

Algorithm when the media resource declares a UA-supported media-resource-specific text track

The algorithm has to go through the steps to expose that text track if the media data is set to CORS-same-origin. There’s a security issue with sending possibly sensitive info in subtitles across domains.

 

One final note is that it’s quite possible that a media element would never reach the final step of the algorithm, which is aborting the algorithm itself. An example is a live-streaming infinite audio file for an online radio station.