W3C home > Mailing lists > Public > public-html-media@w3.org > November 2014

[Bug 27342] New: Clarify if the source buffer is still valid when appendBuffer/appendStream meets 'decode' error

From: <bugzilla@jessica.w3.org>
Date: Mon, 17 Nov 2014 06:37:21 +0000
To: public-html-media@w3.org
Message-ID: <bug-27342-5436@http.www.w3.org/Bugs/Public/>

            Bug ID: 27342
           Summary: Clarify if the source buffer is still valid when
                    appendBuffer/appendStream meets 'decode' error
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: jiajia.qin@intel.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

Currently, when SourceBuffer.appendBuffer/appendStream fails in segment parser
loop algorithm, it will run the end of stream algorithm with the error
parameter set to "decode". However, in end of stream algorithm, 'If error is
set to "decode". If the HTMLMediaElement.readyState attribute is greater than
HAVE_NOTHING. Run the media data is corrupted steps of the resource fetch
algorithm' will result aborting the overall resource selection algorithm and
the media player pipeline will be shutdown. So, if we execute
SourceBuffer.appendBuffer/appendStream again, the media data will be ignored
since the demuxer has been shutdown. What's more, if the MediaSource's
readyState is set to 'closed'. Then, that SourceBuffer will be cleared. 

But if we only look at MSE spec, when executing end of stream algorithn, it
changes the readyState attribute value to "ended" not "closed". It seems that
we can still use the current MediaSource and SourceBuffer which called the end
of stream algorithm. But it's kind of conflict with above paragraph.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 17 November 2014 06:37:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:05 UTC