[Bug 24820] New: [MSE] Highest presentation end timestamp

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

            Bug ID: 24820
           Summary: [MSE] Highest presentation end timestamp
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: cyril.concolato@telecom-paristech.fr
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

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."

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 26 February 2014 12:22:02 UTC