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

[D Richard Felker III]

On Fri, Apr 16, 2004 at 03:44:52PM +0200, Michael Niedermayer wrote:
> > > 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.
> >
> > yes, i agree, we need to do some tests to see how much we would loose if we
> > replace the frame_code system with simple flags, and if the loss is too
> > large we must clarify the spec and add some example code which generates a
> > good table

Agree.

> ok, first test, identical frame_code table but never store any bits of the 
> frame size in the frame_code, the file is playable, and doesnt contain any of 
> the type 1 or pointer changes
> -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   2081606 2004-04-16 15:33 
> test.zero_size_lsb.nut
> -rw-r--r--    1 michael  michael   2080700 2004-04-15 18:27 test.2.nut
> -rw-r--r--    1 michael  michael   2080057 2004-04-16 15:06 test.3.nut
> -rw-r--r--    1 michael  michael   2079900 2004-04-15 18:24 test.nut
> test.zero_size_lsb.nut overhead is 0.351877%
> 
> and for our vorbis only stream:
> -rw-r--r--    1 michael  michael    534004 2004-04-04 21:58 testv.avi
> -rw-r--r--    1 michael  michael    497770 2004-04-04 21:35 testv.rm
> -rw-r--r--    1 michael  michael    489228 2004-04-04 21:36 testv.mov
> -rw-r--r--    1 michael  michael    486516 2004-04-04 21:36 testv.mkv
> -rw-r--r--    1 michael  michael    482227 2004-04-16 15:38 
> testv.zero_size_lsb.nut
> -rw-r--r--    1 michael  michael    481684 2004-04-04 21:36 testv.ogm
> -rw-r--r--    1 michael  michael    479882 2004-04-04 21:32 testv.nut
> testv.zero_size_lsb.nut overhead: 1.483871%
> testv.nut               overhead: 1.006785%

I'm against moving the size out of the framecode/bitfield entirely.
It's a huge advantage not to waste extra bytes storing the packet
size, timestamp, and streamid when they can be packed into one byte.
I'm just curious if it can be done with better use of prediction from
one packet to the next, rather than custom lookup tables that seem to
be very specific to the codec.

Rich