- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Dec 2014 06:14:56 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27487 Aaron Colwell <acolwell@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |acolwell@google.com Assignee|adrianba@microsoft.com |acolwell@google.com --- Comment #4 from Aaron Colwell <acolwell@google.com> --- (In reply to Jer Noble from comment #1) > It looks like this line was changed after the 21 May 2014 Editors draft. > That version read: > > "1.7 If the presentation timestamp or decode timestamp is less than the > presentation start time, then run the end of stream algorithm with the error > parameter set to "decode", and abort these steps." > > It seems like the requirement that the presentation timestamp < 0 was > removed, leaving the requirement that the decode timestamp < 0. Perhaps > that decision could be revisited, and instead the decode timestamp < 0 > requirement be removed, and the presentation timestamp < 0 requirement be > reinstated. Yes. The presentation timestamp check was removed as part of resolving Bug 25998. The check was redundant because the constraints on appendWindowStart always make sure presentation timestamp is within bounds. It's a little subtle, but that is the reason the pts check was removed. I vaguely remembering having a discussion about this with Matt Wolenetz on the Chrome team a while ago. I believe I may have just forgotten to file a spec bug for it. The relevant Chromium code even has this comment in it: "B-frames may still result in negative DTS here after being shifted by |timestamp_offset_|." :/ I'm fine with dropping the check since I don't believe it will cause any problems. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 3 December 2014 06:14:58 UTC