- From: <bugzilla@jessica.w3.org>
- Date: Wed, 26 Feb 2014 12:22:00 +0000
- To: public-html-media@w3.org
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