[Bug 20714] timestampOffset in live case

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

Steven Robertson <strobe@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |strobe@google.com

--- Comment #1 from Steven Robertson <strobe@google.com> ---
I think the assumption that playback must begin at t=0 may be wrong here. Are
you encountering problems when you append media data starting at t>0, and then
seeking to that time to begin playback? If so, that's an implementation bug,
not a spec issue.

Note that you can append media data and then examine the buffered ranges to
determine the timestamps of the media data that was appended.

By what means are you fetching media data? In most scenarios (e.g. DASH, HLS)
the timestamp of the media data being fetched is provided in the manifest which
describes chunk URLs, so you don't even need to wait for parsing to finish.

(IMHO, t=0 should be the natural start time of the stream, not the join time.
This lets users watching on multiple devices (or users who refresh the page)
have the same timestamps; it allows users to rewind to before they started
watching a stream; it allows people to talk about and link to particular
timecodes in a stream, and have them be consistent; and it allows the same
content to be used in a VOD setting after the live presentation has concluded
without different player logic. Of course, all of that is application-level
policy, but it has bearing on this issue because it suggests that the proposed
"force the timestamp to zero" functionality may not be widely used.)

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

Received on Sunday, 20 January 2013 19:03:30 UTC