W3C home > Mailing lists > Public > public-html-media@w3.org > July 2014

[Bug 26314] New: [MSE] Coded Frame Removal algorithm leaves in place decoding dependencies

From: <bugzilla@jessica.w3.org>
Date: Sat, 12 Jul 2014 00:12:21 +0000
To: public-html-media@w3.org
Message-ID: <bug-26314-5436@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26314

            Bug ID: 26314
           Summary: [MSE] Coded Frame Removal algorithm leaves in place
                    decoding dependencies
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: jer.noble@apple.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

3.5.10 Coded Frame Processing

"1.15 Remove existing coded frames in track buffer:
↪︎ If highest presentation timestamp for track buffer is not set:
  Remove all coded frames from track buffer that have a presentation timestamp
greater than or equal to presentation timestamp and less than frame end
timestamp.
↪︎ If highest presentation timestamp for track buffer is set and less than or
equal to presentation timestamp:
  Remove all coded frames from track buffer that have a presentation timestamp
greater than or equal to highest presentation timestamp and less than frame end
timestamp."

"1.16 Remove decoding dependencies of the coded frames removed in the previous
step:
↪︎ If detailed information about decoding dependencies is available:
  Remove all coded frames from track buffer that have decoding dependencies on
the coded frames removed in the previous step.
↪︎ Otherwise:
  Remove all coded frames between the coded frames removed in the previous step
and the next random access point after those removed frames."

vs.

3.5.11 Coded Frame Removal Algorithm

"3.3. Remove all media data, from this track buffer, that contain starting
timestamps greater than or equal to start and less than the remove end
timestamp."

While "remove end timestamp" is guaranteed to be either a sync-sample or the
end of the frames, "start" is not guaranteed to be a sync-sample. If decoding
dependencies are not removed, decoding errors can result, particularly if a
removed sample is a sync sample.

I propose adding the same language as found in section 3.5.10 after section
3.5.11 step 3.3:

"Remove decoding dependencies of the coded frames removed in the previous step:
↪︎ If detailed information about decoding dependencies is available:
  Remove all coded frames from track buffer that have decoding dependencies on
the coded frames removed in the previous step.
↪︎ Otherwise:
  Remove all coded frames between the coded frames removed in the previous step
and the next random access point after those removed frames."

This would eliminate decoding errors, if there exist frames with presentation
timestamps which occur before /start/, but whose decode timestamps occur after
frames within the range define in step 3.3.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Saturday, 12 July 2014 00:12:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:04 UTC