[Bug 17004] Define a timestamp offset mechanism

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

--- Comment #2 from Aaron Colwell <acolwell@chromium.org> 2012-05-21 17:08:20 UTC ---
(In reply to comment #1)
> Here is a list of some of the issues/use cases I feel we should verify as part
> of adding this functionality.  They are listed in no particular order:
> 
> * Content Initialization: not only is the timeline discontinuous, but the new
> media will likely require initialization (like H264 SPS/PPS).

I think this can be handled by appending a new initialization segment before
appending the data with the different parameters. Is this not sufficient?

> 
> * Seeking: the effective mapping for the stream timeline needs to be completely
> deterministic (from the app script's perspective), so that a sane view of the
> total stream timeline can be computed for things like seeking.

I believe the proposed solution fulfills this requirement. The intent was to
apply the mapping at append time so that the source buffer is only aware of
presentation timestamps. Future changes to the mapping only effect future
appends and doesn't affect previous data.

> 
> * Tracking: this is related to the seeking requirement...not only does the
> script need to be able to compute the timeline for seeking, but it also needs
> to be able to infer where in the the sequence the current playhead is
> ("tracking" the playhead).

Is currentTime on HTMLMediaElement not sufficient? I'm assuming that the script
is keeping track of where it inserted a segment and can use currentTime to
determine whether the current playback position is within that segment.


> * Content Protection: this behavior will likely impact the content protection
> proposal, in that we should be able to change DRM key/license context at the
> discontinuous content boundaries.  This may mean a new key/license, or a shift
> from protected to unprotected (and back to protected).

I believe this is supported with the current spec language. I'd expect a new
initialization segment to be appended at the encrypted->decrypted &
decrypted->encrypted boundaries.

> 
> This is everything I can think of now :)

Thanks for your comments. :)

-- 
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 Monday, 21 May 2012 17:08:48 UTC