On Mon, 24 May 2010 03:03:15 +0200, Robert O'Callahan
<[email protected]> wrote:
On Tue, May 18, 2010 at 9:46 PM, Silvia Pfeiffer
<[email protected]>wrote:
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?
Here's how I think it should work:
-- currentTime (and related times, such as times in TimeRanges) range
from 0
to 'duration'
-- media resources are allowed to have a non-zero "initial playback
time".
This is what currentTime should be set to on media load. We could create
a
new DOM attribute to expose this.
Is this a typo? If currentTime runes of 0 to duration, how can it begin at
something non-zero?
-- media resources are allowed to have a "real time offset". This is an
optional date+time (in UTC) that corresponds to currentTime=0, exposed
as a
DOM attribute. Players would be encouraged to use this to display real
times, when it's present.
This would be similar in power to what the spec already has. In your
example
you could either let currentTime=0 be the start of the stream that the
user's loading, and use the "real time offset" to get the correct time
displayed, or you could let 0 be the real "start", and set the initial
playback time to match where the user joined. However, I think describing
things the way I just did is simpler and avoids weirdness like the "start
time" changing dynamically. It also preserves the invariant that
currentTime
ranges from 0 to 'duration', which I think players will come to depend
on if
the cases where it's not true are rare.
Rob
What concretely should we change? Should we drop startTime, or redefine
it? Is it necessary to have the offset as an absolute date, or could that
probably odd case be handled in other ways? I can't really see a browser
UI making use of it, so I'd be happy to put it in a data-* attribute or
using microdata.
--
Philip Jägenstedt
Core Developer
Opera Software
