[Bug 28573] New: suspending and notifying resumption of a download for a media element fetching from a MediaSource

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28573

            Bug ID: 28573
           Summary: suspending and notifying resumption of a download for
                    a media element fetching from a MediaSource
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: wolenetz@google.com
          Reporter: bugs+w3@karlt.net
        QA Contact: public-html-bugzilla@w3.org
                CC: jdsmith@microsoft.com, mike@w3.org,
                    public-html-media@w3.org

"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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 27 April 2015 21:34:48 UTC