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
