=[SPAM?]= Re: [Matroska-devel] Timestamp precision in matroska files

Steve Lhomme steve.lhomme at free.fr
Wed Jan 7 09:50:04 CET 2004

Frank Klemm wrote:
>>>Then we need a new block type, with more than 16 bits for the timecode.
>>What about the same Block using a new attached (in BlockMore) containing 
>>the number of samples since the beggining ? A la Granule Pos.
>>This could apply to video for the number of frames too.
>>That's backward compatible and add a neat feature.
> What about A/V material with changing frame rates (mixed CCIR, FCC/IAC and
> cinema material) ???

Is that possible with audio ? Anyway audio will always be in samples 
(for still a long time). So counting samples is the only really accurate 
way to know where you are.

I didn't introduce the frame count feature for video because of VFR 
material. And most of the time 1 frame = 1 block. So seeking is frame 
accurate in this case.

> Better would be when all material can be mixed in a file, the decoder +
> display render engine translates the signal into the needs of the display.

Well, actually you have have a 25fps movie stored with the sound for the 
30fps version of the movie. There is a scale factor to adjust the 2 (or 
more) together (based on the sound). I dunno if that's the problem you 

> Note: 
> - You also must define exact rounding rules for sample precise cuttering
>   (otherwise you have problems even with 192 kHz Time Code when using audio
>   with 44100 Hz).

No rounding. As I said we count samples. (with a scale factor to reduce 
the size of the counter when possible)
For "high precision" matroska files (most probably audio-only files) 
this counter should be present in the file.

> - It should be defined how to handle FCC/IAC "nice" rate of 
>   59.94005232862375719518... Hz
>   a) exact 60 Hz, don't care about the 0.1% error (which was intended to
>      reduce interference between color and audio carrier in radio transmissions)
>   b) 59.94 Hz (ca. 0,9 ppm error)
>   c) 2863636 / 47775 Hz (exact theoretical value)

You can adjust the timecode scale of the track to avoid rounding errors 
as much as possible depending on your source material. Of course, it 
will never be perfect, but very close.

More information about the Matroska-devel mailing list