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 28710 - [MSE] Ambiguous behavior with Coded Frame Processing algorithm
Summary: [MSE] Ambiguous behavior with Coded Frame Processing 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-05-28 07:49 UTC by Jean-Yves Avenard
Modified: 2015-10-13 23:10 UTC (History)
3 users (show)

See Also:


Attachments

Description Jean-Yves Avenard 2015-05-28 07:49:53 UTC
In the Coded Frame Processing algorithm:
http://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-processing

In Step 13. "If track buffer contains video coded frames:"

you find:
"If the presentation timestamp is less than the remove window timestamp, then remove overlapped frame and any coded frames that depend on it from track buffer.
"

This imply that we are to have detailed information about decoding dependencies available. We can't remove the frames depending on the removed frames otherwise.

However, Step 15. describes how to remove dependent frames for frames removed in the previous step (step 14.) should we have "detailed information about decoding dependencies is available".
If such information isn't available, then we are to "Remove all coded frames between the coded frames removed in the previous step and the next random access point after those removed frames. "


I suggest that Step 13 removes the mention of " and any coded frames that depend on it"

and have Step 15 have instead:
"Remove decoding dependencies of the coded frames removed in the previous two steps: "

This would mean we have a common code path for the removal of dependent frames.

As a side note, Step 15 note: "Removing all coded frames until the next random access point is a conservative estimate of the decoding dependencies since it assumes all frames between the removed frames and the next random access point depended on the frames that were removed. "

doesn't appear to cater for B-frames found prior the "coded frames removed" and dependent on the frames removed. This could leave frames that can't be decoded in the track buffer.
Comment 1 Matt Wolenetz 2015-10-13 23:10:05 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/25