[MPlayer-dev-eng] forward pointers in NUT and possible NUT simplifications

[D Richard Felker III]

On Thu, Apr 15, 2004 at 06:45:17PM +0200, Michael Niedermayer wrote:
> > > so as i already said IMHO 0.05% is negligible, additionally a type 1
> > > packet currently has a backward, forward pointer and the data size of the
> > > current frame, with the proposed change we could drop both forward and
> > > backward pointers, each is at least 2bytes so the loss is just 0.024%
> > > approximately assuming 16k distance between type 1 frames, which are the
> > > value at which the current muxer will put type 1 packets if it can
> >
> > OK, fair enough. I was assuming overhead percentages applied to common
> > movies, not audio-only. Want to do some tests and let us know the
> > results?
> 400kbit mpeg4 + 128kbit mp3 30sec video, test.2.nut relaces all type 1 by type 
> 2 frames
> 
> -rw-r--r--    1 michael  michael   2129922 2004-04-15 18:00 test.avi
> -rw-r--r--    1 michael  michael   2118957 2004-04-15 18:00 test.asf
> -rw-r--r--    1 michael  michael   2102980 2004-04-15 18:02 test.ogm
> -rw-r--r--    1 michael  michael   2093553 2004-04-15 18:00 test.mkv
> -rw-r--r--    1 michael  michael   2091858 2004-04-15 18:24 test.mov
> -rw-r--r--    1 michael  michael   2080700 2004-04-15 18:27 test.2.nut
> -rw-r--r--    1 michael  michael   2079900 2004-04-15 18:24 test.nut
> 
> the overhead for nut is 0.269632% and 2.nut 0.308199% according to ffmpeg
> the overhead for mov is 0.848788%
> btw, i guess i should mention that mov is cheating, as it stores some mpeg4 
> headers only in the global ESDS, while all other formats repeat these headers 
> with every keyframe
> 
> btw2, all files are playable

Hmm. Care to drop the forward and backward pointers and calculate the
overhead with them removed? I expect they're usually 2 bytes each,
meaning that we'd recover a lot of the overhead.

BTW, do you have any thoughts on "sanitizing" the frame code system?
I'm not totally against it, but I agree with Ivan that it's very
counter-intuitive and that you should have a good spec for how the
muxer should choose a framecode table without having to have detailed
advance knowledge about the codecs. Either that, or it should be some
sort of bit-field rather than lookup table.

Rich