[Bug 24820] [MSE] Highest presentation end timestamp

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24820

--- Comment #3 from Aaron Colwell <acolwell@google.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 1 April 2014 23:27:12 UTC