[Bug 20714] timestampOffset in live case

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

--- Comment #4 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
Had problems replying the first time. Replying again.

(In reply to comment #1)
> 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.
I'm not having problems appending, the problem is mostly with the UI as
depicted in the attachement. 

> 
> Note that you can append media data and then examine the buffered ranges to
> determine the timestamps of the media data that was appended.
Yes, but you cannot change the timestamps anymore. I think it's a general
problem that in order to append properly (i.e. without creating gap) you need
to parse the data first to get the time stamp. 

> 
> 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.
In my understanding HLS does not provide such a timestamp. DASH provides, only
in some cases, the presentationTimeOffset attribute, but not always. In my
case, I'm also envisaging simple chunk-transfer delivery of live data without
manifest, similar to IceCast and ShoutCast.

> (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.)
I agree that your use case make sense but you assume that a live event is a one
shot event for which the streaming starts at the beginning of the event
(timestamp = 0). If you record a single program in 24/7 TV channel, the
timestamp of the first AU won't be zero. You'd have the same problem. 

On second thoughts, maybe the problem is not about shifting the timestamps but
about indicating properly to the browser that it will never be able to seek
before the first data received, so that it can adjust the timeline UI. I'm
unclear about how the buffered and seekable attributes are filled in with MSE
(and HTML 5 Media Elements in general).

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

Received on Tuesday, 29 January 2013 07:35:01 UTC