[Bug 17004] Define a timestamp offset mechanism

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

suzie.hyun@disney.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |suzie.hyun@disney.com

--- Comment #8 from suzie.hyun@disney.com 2012-06-18 21:55:58 UTC ---
(In reply to comment #2)

> (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.
> > 

Which spec language are you referring to for content protection?
Other than key delivery, does this spec assume that buffers are intact?

> > 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, 18 June 2012 21:56:01 UTC