- 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