This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28573 - suspending and notifying resumption of a download for a media element fetching from a MediaSource
Summary: suspending and notifying resumption of a download for a media element fetchin...
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Matt Wolenetz
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-27 21:34 UTC by Karl Tomlinson
Modified: 2015-10-13 23:09 UTC (History)
3 users (show)

See Also:


Attachments

Description Karl Tomlinson 2015-04-27 21:34:46 UTC
"User agents may decide to not download more content at any time" by
suspending the fetch, setting networkState to NETWORK_IDLE.  The decision re
when the user agent stops buffering may depend on the value of the preload
attribute.  Also "User agents may allow users to selectively block or slow
media data downloads."

A media element without a MediaSource receives media data only when the user
agent is looking for media data, but when the fetch involves a MediaSource,
the media element receives data whenever appendBuffer() or appendStream() is
called on a SourceBuffer.  The only specified mechanism for rejecting an append is if the buffer full flag is true.  Setting the buffer full flag to true is
explicitly specified only after parsing a complete media segment header in the
segment parser loop algorithm when append state equals PARSING_MEDIA_SEGMENT
(i.e. while parsing an appended array that was not rejected because of the
buffer full flag).

Is the expected behavior of the user agent one of these?:

(i) continues to accept media data after suspending the download, but does not
    dispatch progress events for this data.

(ii) accepts appended media data after suspending the download until it has a
     chance to set the buffer full flag to true, and then rejects subsequent
     arrays.

(iii) sets the buffer full flag immediately when suspending the download and
      rejects future appends.

(iv) does not suspend a download which has begun until either all the
     SourceBuffers are all full or it has all of the media data
     (i.e. endOfStream has been called).  a "metadata" value for the
     preload attribute is ignored.  A stalled event may be queued even
     if the user agent does not require more media data.

The NETWORK_IDLE/NETWORK_LOADING distinction seems useful for a user agent to
indicate to a player when it wants more media data or not.  However, what is
missing is a specific event to notify on transition to NETWORK_LOADING.  (The
"suspend" event exists for transition to NETWORK_IDLE.)  "playing" and
"timeupdate" may provide some hints.

In the prepare append algorithm, if the readyState is "ended", and so is
changed to "open", and the buffer is not full, I assume the media element
networkState should be changed from NETWORK_IDLE to NETWORK_LOADING?
In that situation, there is a sourceopen event to notify of the state change
from "ended", but MediaSource readyState doesn't have a distinct value for a
suspended incomplete download.

Similarly, there is no specific event to notify a player when a SourceBuffer
transitions from a state where eviction will not unset the buffer full flag to
one where an append can succeed.
Comment 1 Matt Wolenetz 2015-10-13 23:09:01 UTC
This bug has been migrated to the GitHub issue tracker. Please follow/update progress using the GitHub issue:
https://github.com/w3c/media-source/issues/24