[Bug 28877] New: [MSE] Ambiguous behaviour when running the range removal algorithm

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

            Bug ID: 28877
           Summary: [MSE] Ambiguous behaviour when running the range
                    removal algorithm
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: wolenetz@google.com
          Reporter: jyavenard@mozilla.com
        QA Contact: public-html-bugzilla@w3.org
                CC: jdsmith@microsoft.com, mike@w3.org,
                    public-html-media@w3.org

The coded frame processing algorithm introduce the concept of Coded Frame
Group. If the coded frame processing algorithm detects a discontinuity, a new
coded frame group will be started and the need random access point flag will be
set.

The coded frame processing algorithm handles multiple successive runs nicely.
The only call that could interrupt a coded frame group currently is the Reset
Parser State.

The coded frame removal algorithm however takes no regard to the current coded
frame group.

It is possible to call remove with a range that intersects with the current
coded frame group ; which would introduce a discontinuity.
A follow up call to the coded frame processing may render the track buffer
unplayable as it wouldn't have detected the introduced discontinuity.

something like:
sourcebuffer.appendBuffer(init + mediasegment[0-10));
waitfor("updateend").then(
sourcebuffer.remove(5, 10);
);
waitfor("updateend").then(
sourcebuffer.appendBuffer(mediasegment[10,20));
);

if the first frame of the last media segment doesn't start with a key frame,
the trackbuffer content is now undecodable.

I suggest amending the coded frame removal, following step 4, and prior to step
5 (which would become step 6) with something like:

If the last decode timestamp for track buffer is set and if any of the coded
frames removed in the previous step have a decode timestamp that equals to the
last decode timestamp:
 1. Unset the last decode timestamp on all track buffers.
 2. Unset the last frame duration on all track buffers.
 3. Unset the highest end timestamp on all track buffers.
 4. Set the need random access point flag on all track buffers to true.

There may be something to do related to the group start timestamp that I
haven't considered, likely need to unset it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 2 July 2015 00:28:11 UTC