What Is Time Base?
time-base
If you found a value for Time Base in your file, you surely want to know what it means. Find out information we gathered around the Time Base metadata.
Time Base is the unit of time a stream counts in. Rather than storing timestamps in seconds, a media file counts in ticks of its own clock, and the time base says how long one tick lasts. It is written as a fraction of a second.
Which files carry it and where the value comes from
You will find a time base on the individual streams inside media files - the picture, the sound and any subtitles in MP4, MOV, MKV, WebM, AVI and MPEG transport streams, as well as in standalone audio files. Each stream has its own, so the audio and the video in one file usually count in different units.
The value is chosen by the encoder or the program that assembled the file. Some container formats require a particular time base and fix it outright; where the format leaves the choice open, the writing program picks something that suits the content, and a file may simply carry that program's default.
What the value looks like
It is always a fraction, and the number underneath is the number of ticks per second:
1/1000- one millisecond per tick, the usual choice in Matroska and WebM files1/90000- long standing in MPEG transport streams1/48000- audio streams often count in samples, so the time base matches the sampling rate1/12800- a value commonly seen on video streams in MP4 files
To turn a timestamp into seconds, multiply it by the fraction. A presentation timestamp of 12800 in a stream with a time base of 1/12800 is exactly one second in; with a time base of 1/1000, a timestamp of 3500 is three and a half seconds in. This is why the raw timestamps in a report look like huge numbers - they are tick counts, not seconds. Older tools may also print a separate Codec Time Base row alongside this one.
Why it matters
Everything in a media file happens on a whole number of ticks, so the time base sets the finest timing the stream can express. If a frame or a sample falls between two ticks, its timestamp has to be rounded, and rounding errors accumulate.
That is a real problem at video frame rates that are not whole numbers. At the broadcast rate of 30000 frames per 1001 seconds, one frame lasts slightly over 33 milliseconds but not a round number of them, so a millisecond time base cannot place any frame exactly. A time base with more ticks per second - a larger number under the fraction - can land on every frame boundary precisely, which is why encoders prefer values like 1/12800 or 1/90000 over plain milliseconds.
The consequences show up as timing faults rather than as anything you can see in a single frame: sound drifting gradually out of step with the picture, uneven frame spacing, a cut or a seek that lands slightly off. Joining files whose streams count in different time bases means all the timestamps must be rescaled, and that conversion is a classic source of synchronisation bugs. The field has no effect on image or sound quality by itself, and it contains no personal information.