- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 18 May 2010 19:46:42 +1000
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> > wrote: >> >> 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? Cheers, Silvia.
Received on Tuesday, 18 May 2010 02:46:42 UTC