- From: Eric Carlson <eric.carlson@apple.com>
- Date: Sun, 23 Nov 2008 12:17:24 -0800
On Nov 23, 2008, at 10:51 AM, Maik Merten wrote: > Eric Carlson schrieb: >> >> Reporting the absolute time of the current sample won't help when >> the >> first sample of the file doesn't have a timestamp of zero. It will be >> even more confusing for files with portions removed or added without >> fixing time stamps - for example a movie created by concatenating >> different files. > > Well, at least the "zero-timestamp has offset" problem can be > corrected. > Whenever possible a "corrected" time should be reported - whatever > that > may be. > >> As I noted when this subject came up a few weeks ago, the right >> way to >> deal with media formats that don't store duration is to estimate the >> duration of the whole file by extrapolating from the known, exact, >> duration of the portion(s) that have been processed. While the >> initial >> estimate won't always be correct for variable bit-rate formats, the >> estimate will become more and more accurate as it is iteratively >> refined >> by processing more media data. The spec defines the >> "durationchange" for >> just exactly this scenario. > > Personally I don't think extrapolating the duration will work at all. > Yes, it gets better the more has been seen, but I assume we'll see a > lot > of position indicators in the UI bouncing back and forth if durations > are to be extrapolated. > QuickTime has used this method this since it started supporting VBR mp3 in 2000, and in practice it works quite well. I am sure that there are degenerate cases where the initial estimate is way off, but generally it is accurate enough that it isn't a problem. An initial estimate is more likely to be wrong for a very long file, but each pixel represents a larger amount of time in the time slider with a long duration so changes less noticeable. eric
Received on Sunday, 23 November 2008 12:17:24 UTC