[MPlayer-dev-eng] Nut and Matroska comparison :)))

D Richard Felker III dalias at aerifal.cx
Mon May 3 22:00:57 CEST 2004


On Mon, May 03, 2004 at 09:24:24PM +0200, Tristan Seligmann wrote:
> On Mon, May 03, 2004 at 03:28:12 -0400, D Richard Felker III wrote:
> > Time units: Matroska defines a single time unit for the whole file,
> > while NUT has separate time bases for each stream. This allows NUT to
> > use very efficient storage for timestamps, and to store additional
> > logical information. For example if you have a timebase of 25/1, the
> > player knows the frames are timed as PAL video, and timestamps
> > correspond exactly to frame numbers. This information, which could be
> > useful when editing a video or retiming it for NTSC telecine, simply
> > isn't there in Matroska, so you have to guess.
> 
> I guess I'm not familiar enough with the technology / terminology here
> to figure it out myself, so I'll just ask:
> 
> Can NUT handle variable framerate video?

Yes, of course. Actually this was one of the goals, but it's so
basic/fundamental I forgot to mention it.

With that said, there are two approaches to variable framerate. One is
"no-framerate", giving every frame a timestamp in terms of some
arbitrary unit like milliseconds or microseconds. This is what
Matroska does. It works, but it's a bad approach for two reasons:

1. Timestamp increments end up being stupid numbers like +41/+42
   (alternating) for 24fps video (msec) or +41666/+41667 (usec). Thus
   the timestamps take considerably more space to store.

2. If the original video was fixed-fps or mixed between several fixed
   framerates, that information was lost. There's no way the player or
   the user can easily tell if the video had an "original" framerate,
   which is desirable to know if you're trying to make it into a DVD
   or [S]VCD, or choose an optimal refresh rate for your monitor to go
   with it, etc.

The other way to store variable framerate is "common time base". That
is, you choose a division of time that's suitable for the content
you're storing, and then store all timestamps in that unit. For
example, for fixed-25-fps video, you would use 25/1 as the time base,
and timestamps would just be frame numbers. For mixed 23.976/29.97
(~24/30) fps NTSC, you would use a time base of 120000/1001 (~120/1).
This has several added benefits, including:

1. Less container overhead. 
2. Player can set the monitor refresh rate proportional to the time
   base, i.e. 119.88 Hz in the above example.
3. Someone editing/reencoding the movie can tell what the intended
   time units are.
4. Timestamps are exact numbers, not approximations. Maybe you care,
   maybe you don't.

Rich




More information about the MPlayer-dev-eng mailing list