- From: <bugzilla@jessica.w3.org>
- Date: Thu, 28 May 2015 07:49:53 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28710 Bug ID: 28710 Summary: [MSE] Ambiguous behavior with Coded Frame Processing 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 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 28 May 2015 07:49:55 UTC