- From: <bugzilla@jessica.w3.org>
- Date: Wed, 19 Sep 2012 19:14:40 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18921 Mark Watson <watsonm@netflix.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |watsonm@netflix.com --- Comment #1 from Mark Watson <watsonm@netflix.com> 2012-09-19 19:14:40 UTC --- (In reply to comment #0) > From step 6 of the append method, as defined in the spec: > If data is part of a media segment and timestampOffset is not 0: > 1.Find all timestamps inside data and add timestampOffset to them. > 2.If any of the modified timestamps are earlier than the presentation start > time, then call endOfStream("decode"), and abort these steps. > 3.Copy the contents of data, with the modified timestamps, into the source > buffer. > > The definition of "part of a media segment" have several conditions that needs > to be addressed. In particular, a part of a media segment that is not > continuous to a previously appended buffer. > > In seeking scenario, after the current source buffer is aborted, a user might > append a buffer which is not a beginning of a segment. No, at the beginning, or after flushing the buffer, appending must begin at the start of a segment. It's not an assumption that the media file format supports 'discovery' of segment boundaries. > In that case, the > browser should discard all the bytes that are prior to a beginning of a > segment. It may not have any way to recognize segment boundaries. The application should be aware of segment boundaries and append only from the beginning of a segment. > This will protect the playback from failing. In some cases, there can > be several "small" appends which are part of previous segment which should all > be discarded, until the append of buffer the contain the start of a segment. > > Without that, js developers must employ parsers to have the accurate offset of > all segments. Yep. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 19 September 2012 19:14:41 UTC