28710 2015-05-28 07:49:53 +0000 [MSE] Ambiguous behavior with Coded Frame Processing algorithm 2015-10-13 23:10:05 +0000 1 1 1 Unclassified HTML WG Media Source Extensions unspecified PC All RESOLVED MOVED P2 normal --- 1 jyavenard wolenetz jdsmith mike public-html-media public-html-bugzilla oldest_to_newest 120556 0 jyavenard 2015-05-28 07:49:53 +0000 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. 123698 1 wolenetz 2015-10-13 23:10:05 +0000 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