[Bug 20714] timestampOffset in live case

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

--- Comment #9 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
Hi Aaron,

(In reply to comment #8)
> Hi Cyril,
> 
> If I understand correctly, I think you are bringing up several different
> issues.
> 
> 1. The default UI for streams that don't start at 0 is suboptimal.
> 2. There is no way to disable seeking.
> 3. Media data has to be parsed in JavaScript to force a 0 start time.
I think you've summarized the issues quite well. 

> For items 1 & 2, I think you have competing requirements for display that
> may be specific to your personal preferences for live controls. 
'Competing' between each others or with someone else's requirements? The latter
I presume.

> Like Adrian
> says, custom UI controls can make it easier for you to control seeking and
> display the timeline however you wish. In the case of live, it could be
> considered a feature that you can seek back into the buffered data.
I agree, although it is not clear to me reading the spec that when buffered
range is seekable. The 'seekable' given its name is clearer.
Anyway, there are cases where you know that you won't be able to seek outside
of the range that has been passed to the SourceBuffer. There should be a way to
inform the built-in UI about it.

> 
> For item 3, you don't have to parse the data in JavaScript. You could do the
> following to make the timeline start at 0 w/o parsing the data in JavaScript.
> 
> sourceBuffer.append(firstMediaSegment);
> sourceBuffer.timestampOffset = -sourceBuffer.buffered.start(0);
> sourceBuffer.remove(sourceBuffer.buffered.start(0),
> sourceBuffer.buffered.end(0))
> sourceBuffer.append(firstMediaSegment);
> 
> You only have to do this once at the beginning and it will make the timeline
> start at 0. I think this will make the default UI look closer to what you
> want, but the displayed time will be 0 based instead of starting at the join
> time. I've used this trick with some internal MSE live demos I've written so
> I know it works.
This might have consequences on the media element state, trigger events ...
which you might not want.

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

Received on Friday, 15 February 2013 10:55:29 UTC