This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.5.10 Coded Frame Processing "1.10 If the 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." Decode timestamps < 0 (a.k.a., presentation start time) are common. In ISO BMFF, decode timestamps for random-access samples typically precede display timestamps by 1 frame-duration. In these cases, the initialization segment (a 'moov' box) will typically have an edit list (a 'edts' box) which moves the display time of the first sample back to 0, which results in a decode timestamp of negative-1 frame-duration. This should be allowed.
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.
My understanding is that the edit list applies to the presentation timeline, but not the decode timeline. This allows the presentation and decode timelines to both be arranged such that the sample with the smallest initial timestamp in each timeline starts at 0. Does this differ from your understanding?
(In reply to Steven Robertson from comment #2) > My understanding is that the edit list applies to the presentation timeline, > but not the decode timeline. This allows the presentation and decode > timelines to both be arranged such that the sample with the smallest initial > timestamp in each timeline starts at 0. Does this differ from your > understanding? Yes, my understanding is that the edit list applies to both. If you think about this in terms of more classic uses of the edit list, you can see why: if a piece of media been edited such that a range of media in the middle of the natural movie timeline is to be displayed much earlier, both the decode timeline and the presentation timeline must be equally affected or the samples will not be decoded in time for their new display times.
(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.
Change committed... https://github.com/w3c/media-source/commit/a2fb2419d21de5494c6ded956a157a0f1d5b94ba