W3C home > Mailing lists > Public > public-html-media@w3.org > September 2015

[Bug 29133] New: Reset Parser State algorithm, in 'sequence' appendMode, should trigger potential discontinuity adjustment logic

From: <bugzilla@jessica.w3.org>
Date: Thu, 17 Sep 2015 21:27:38 +0000
To: public-html-media@w3.org
Message-ID: <bug-29133-5436@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29133

            Bug ID: 29133
           Summary: Reset Parser State algorithm, in 'sequence'
                    appendMode, should trigger potential discontinuity
                    adjustment logic
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: wolenetz@google.com
          Reporter: wolenetz@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: jdsmith@microsoft.com, mike@w3.org,
                    public-html-media@w3.org
  Target Milestone: ---

Currently, the following sequence of actions is allowed and produces strange
results:
SourceBuffer.appendMode = sequence;
Append [0,10)
Abort
Append [100,110) // or Append [0,10) again

Without the Abort ( == reset parser state), the expected result would be:
[0,20) (assuming each append began with a random access point such that no
frames were dropped).

With the Abort and the current Reset Parser State algorithm that is
appendMode-agnostic, the result would be:
[0,10 with a large not-real-gap until 100,110)
// or in the alternate case:
[0,10) from the second Append [0,10).

I believe the correct way to fix this problem is to include the following step
in the Reset Parser State algorithm:
'If mode equals "sequence": Set group start timestamp equal to the group end
timestamp.'

I will prepare a PR shortly for review.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 17 September 2015 21:27:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 September 2015 21:27:41 UTC