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 28877 - [MSE] Ambiguous behaviour when running the range removal algorithm
Summary: [MSE] Ambiguous behaviour when running the range removal algorithm
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Matt Wolenetz
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-02 00:28 UTC by Jean-Yves Avenard
Modified: 2015-10-13 23:17 UTC (History)
5 users (show)

See Also:


Attachments

Description Jean-Yves Avenard 2015-07-02 00:28:00 UTC
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.
Comment 1 Jerry Smith 2015-08-24 21:14:18 UTC
It is possible to append a segment that does not start with a key frame, but doing so doesn't seem like a recommended practice.  This bug requires resuming with a random access point, which is preferred.  We recommend adopting it.
Comment 2 Matt Wolenetz 2015-10-13 23:17:54 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/29