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

[Michael Niedermayer]

Hi

On Friday 16 April 2004 15:18, Michael Niedermayer wrote:
> Hi
>
> On Friday 16 April 2004 05:50, D Richard Felker III wrote:
> > 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.
>
> ok, here are the numbers, but test.3.nut isnt decodeable obviously with the
> current decoder
> -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   2080057 2004-04-16 15:06 test.3.nut
> -rw-r--r--    1 michael  michael   2079900 2004-04-15 18:24 test.nut
> test.3.nut overhead is 0.277201%, this is indeed somewhat lower then what i
> would have expected, probably the old version already contained more type 2
> frames then i thought
>
> > 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
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%

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en