[Bug 17004] Define a timestamp offset mechanism

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

--- Comment #4 from Aaron Colwell <acolwell@chromium.org> 2012-05-23 15:11:11 UTC ---
(In reply to comment #3)
> Agreed that some of what is described here is already allowed in the proposed
> API.  I called them out only because they also put requirements on the user
> agent to interpret certain sequences of API calls in a semantically specific
> way.  For example, it is important that the user agent playback the media
> continuously and seamlessly even if a new initialization segment is injected. 
> I feel like we should call out the appropriate semantics so that user agents
> implement the behavior consistently, since it would be easy to create a
> simplified implementation that didn't handle these cases well.

Ok. I was just giving examples to make sure I understood what you were talking
about. I'll try to come up with some better text to convey that new
initialization segments should be handled as seamlessly as possible.

> 
> Regarding "tracking", if am not 100% sure that currentTime is sufficient for
> the task. One issue I see is that it will be challenging for the application to
> know when to check currentTime.  Polling is an option, but polling always leads
> to a tradeoff between responsiveness and efficiency.  It would be nice if the
> app would be notified as timeline boundaries were crossed, or maybe there was a
> mechanism to introduce app-specified markers that would lead to a notification
> as they were hit during stream play.

I wonder if it would be better to handle this with a metadata TextTrack instead
of something explicitly added to this API. You could add TextTrackCues when you
append segments of interest. You could hook into the enter & exit events to get
notified when the timeline enters & exits the cue time range. Would this be
sufficient?

-- 
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, 23 May 2012 15:11:19 UTC