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

[Michael Niedermayer]

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

[...]
-- 
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