- From: David Singer <singer@apple.com>
- Date: Thu, 30 Apr 2009 09:49:45 -0700
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.
Received on Thursday, 30 April 2009 09:49:45 UTC