silviapfeiffer1 at gmail.com
Tue May 18 02:46:42 PDT 2010
On Tue, May 18, 2010 at 7:28 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Tue, May 18, 2010 at 8:23 PM, Odin Omdal Hørthe <odin.omdal at gmail.com>
>> Justin Dolske's idea looks rather nice:
>> > This seems like a somewhat unfortunate thing for the spec, I bet
>> > everyone's
>> > going to get it wrong because it won't be common. :( I can't help but
>> > wonder if
>> > it would be better to have a startTimeOffset property, so that
>> > .currentTime et
>> > al are all still have a timeline starting from 0, and if you want the
>> > "real"
>> > time you'd use .currentTime + .startTimeOffset.
>> > I'd also suspect we'll want the default video controls to normalize
>> > everything
>> > to 0 (.currentTime - .startTime), since it would be really confusing
>> > otherwise.
> That's exactly what I've advocated before. I lost the argument, but I forget
> why, probably because I didn't understand the reasons.
To be honest, it doesn't make much sense to display the "wrong" time
in a player. If a video stream starts at 10:30am and goes for 30 min,
then a person joining the stream 10 min in should see a time of 10min
- or better even 10:40am - which is in sync with what others see that
joined at the start. It would be rather confusing if the same position
in a video would be linked by one person as "at offset 10min" while
another would say "at offset 0min". And since the W3C Media Fragments
WG is defining temporal addressing, such diverging pointers will even
end up in a URL and how should that be interpreted then?
More information about the whatwg