At 16:45 +0000 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, David Singer wrote:
If the resource is 'seekable' then time is relevant, and I agree that
time should be a normal play time and run from 0 to duration.
That wouldn't address the use case of files that were split with non-zero
start times, though, where the author wants the original range to be the
one visible in the UI.
The complexity of edited files is only really dealt with by embedded
time-codes. A single segment is the beginning of a large can of
worms; what do you want to have happen when there are two segments
played consecutively? Following your logic, there would be a
time-jump.
If it's not seekable (live), then the UA is free, of course, to buffer
and allow seeking in that buffer, but that's a UA thing. Duration is
indefinite, and the origin value of current time is also so.
The concern is with resources that are seekable yet indefinite -- and in
fact, the spec encourages browsers to make streaming resources seekable
(much like how a DVR makes streaming live TV seekable).
OK, in the case of server-supported DVR-like functionality, I agree
there is a question.
--
David Singer
Multimedia Standards, Apple Inc.
