This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I have several small issues here regarding the "highest end presentation timestamp" and related notions: 1) In the "duration change algorithm" and in the "end of stream algorithm", the specification uses the term "highest end timestamp" which is not defined. There are 3 terms using "highest" in the spec: - "highest end time" in the context of TimeRanges - "highest presentation end timestamp" in the SourceBuffer - "highest presentation timestamp" in track buffers I believe in this case, it should be "highest end presentation timestamp". 2) Step 5 in the "Coded Frame Processing" uses the term "highest end timestamp" in the sentence: "run the duration change algorithm with new duration set to the maximum of the current duration and the highest end timestamp reported by HTMLMediaElement.buffered". I believe it should be "highest end time". 3) I find the definition of "highest presentation end timestamp" (HPETS in short) a bit unclear and cyclic: "The highest presentation end timestamp variable stores the highest presentation end timestamp [encountered in the current coded frame group]." It's basically saying HPETS is HPETS. And it's actually not defining what is an "end timestamp". Looking at the algorithms using it (namely the coded frame processing algo), I find it confusing. In some cases, HPETS is simply set to the value of a PTS (step 1.4.2, step 1.7.1 1st if) and in another case (step 1.21) it's set to the sum of PTS + frame duration. Could you clarify why the current frame duration is not added in all cases? Am I missing something? 4) Then, in my understanding, the HPETS is computed in all modes (sequence/segment) but is meant to initialize the Group Start TimeStamp (GSTS) for use in the sequence mode. IOW, it used to make the next group start at the end of the previous one (unless timestamp offset is used). It seems to me that it could be renamed as "group end timestamp" (GETS) with the following definition: "The group end timestamp variable stores the frame end timestamp of the frame in the current frame group with the highest presentation timestamp. It is set to 0 when the SourceBuffer object is created and gets updated by the coded frame processing algorithm." 5) Finally, I think a note indicating that the GETS is stored at the SourceBuffer level is important as it can have consequences when appending multiplexed segments in sequence mode. I'd suggest: "Note that group end timestamp stores the highest frame end timestamp across all track buffers in a SourceBuffer. Therefore, care should be taken in choosing the append mode when appending multiplexed segments in which the timestamps are not aligned across tracks."
Additionally, the spec says in step 1.21 : "If highest presentation end timestamp is unset or frame end timestamp is greater than highest presentation end timestamp [...]" but it is never unset and its definition says: "It is set to 0 when the SourceBuffer is created" I would replace 1.21 with: "If frame end timestamp is greater than highest presentation end timestamp [...]"
Changes committed https://dvcs.w3.org/hg/html-media/rev/d471a4412040
(In reply to Cyril Concolato from comment #0) > I have several small issues here regarding the "highest end presentation > timestamp" and related notions: > > 1) In the "duration change algorithm" and in the "end of stream algorithm", > the specification uses the term "highest end timestamp" which is not > defined. > There are 3 terms using "highest" in the spec: > - "highest end time" in the context of TimeRanges > - "highest presentation end timestamp" in the SourceBuffer > - "highest presentation timestamp" in track buffers > I believe in this case, it should be "highest end presentation timestamp". I changed this to the highest end time returned by the buffered attribute since that is what I actually meant in these cases. > > 2) Step 5 in the "Coded Frame Processing" uses the term "highest end > timestamp" in the sentence: > "run the duration change algorithm with new duration set to the maximum of > the current duration and the highest end timestamp reported by > HTMLMediaElement.buffered". > I believe it should be "highest end time". This was actually a bug. I changed this to group end timestamp so that the end times returned by the SourceBuffer.buffered attribute can never be larger than the duration. Using HTMLMediaElement.buffered only has the intersection which is problematic for demuxed multiple SourceBuffer case. > > 3) I find the definition of "highest presentation end timestamp" (HPETS in > short) a bit unclear and cyclic: > "The highest presentation end timestamp variable stores the highest > presentation end timestamp [encountered in the current coded frame group]." > It's basically saying HPETS is HPETS. And it's actually not defining what is > an "end timestamp". Looking at the algorithms using it (namely the coded > frame processing algo), I find it confusing. In some cases, HPETS is simply > set to the value of a PTS (step 1.4.2, step 1.7.1 1st if) and in another > case (step 1.21) it's set to the sum of PTS + frame duration. Could you > clarify why the current frame duration is not added in all cases? Am I > missing something? PTS is used instead of the PTS + frame duration in situations around discontinuities. The idea is to make it look like there was a frame that ended right where the next one to be processed is about to begin. That allows parts of the algorithm to be unaware that the discontinuity occured. > > 4) Then, in my understanding, the HPETS is computed in all modes > (sequence/segment) but is meant to initialize the Group Start TimeStamp > (GSTS) for use in the sequence mode. IOW, it used to make the next group > start at the end of the previous one (unless timestamp offset is used). It > seems to me that it could be renamed as "group end timestamp" (GETS) with > the following definition: > "The group end timestamp variable stores the frame end timestamp of the > frame in the current frame group with the highest presentation timestamp. It > is set to 0 when the SourceBuffer object is created and gets updated by the > coded frame processing algorithm." done with some slight wording tweaks and the addition of a "coded frame end timestamp" definition. > > 5) Finally, I think a note indicating that the GETS is stored at the > SourceBuffer level is important as it can have consequences when appending > multiplexed segments in sequence mode. I'd suggest: > "Note that group end timestamp stores the highest frame end timestamp across > all track buffers in a SourceBuffer. Therefore, care should be taken in > choosing the append mode when appending multiplexed segments in which the > timestamps are not aligned across tracks." Done.
(In reply to Cyril Concolato from comment #1) > Additionally, the spec says in step 1.21 : > "If highest presentation end timestamp is unset or frame end timestamp is > greater than highest presentation end timestamp [...]" > but it is never unset and its definition says: > "It is set to 0 when the SourceBuffer is created" > I would replace 1.21 with: > "If frame end timestamp is greater than highest presentation end timestamp > [...]" Done.
I believe I've addressed all of your concerns.