W3C home > Mailing lists > Public > public-html-media@w3.org > May 2015

[Bug 28710] New: [MSE] Ambiguous behavior with Coded Frame Processing algorithm

From: <bugzilla@jessica.w3.org>
Date: Thu, 28 May 2015 07:49:53 +0000
To: public-html-media@w3.org
Message-ID: <bug-28710-5436@http.www.w3.org/Bugs/Public/>
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 on the CC list for the bug.
Received on Thursday, 28 May 2015 07:49:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 May 2015 07:49:56 UTC