- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 1 May 2009 11:36:30 +1000
On Fri, May 1, 2009 at 3:00 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 30 Apr 2009, David Singer wrote: >> 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. > > Yeah I'm not really sure how to handle this case. (I imagine it could get > even worse with multiple frames having the same timecode). I guess time is > linearised starting from the first frame's timecode? I would suggest handling this as a playlist. It is the same fundamental problem. If there is a time reset, the timeline should also reset. Then there can be a prev/next file button for scanning. We haven't really solved the problem of having playlist references in <video> tags, so this is a whole discussion to itself IMHO. Cheers, Silvia.
Received on Thursday, 30 April 2009 18:36:30 UTC