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

[Michael Niedermayer]

Hi

On Thursday 15 April 2004 16:57, D Richard Felker III wrote:
> On Thu, Apr 15, 2004 at 02:42:44PM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Thursday 15 April 2004 06:13, D Richard Felker III wrote:
> > > On Thu, Apr 15, 2004 at 04:10:04AM +0200, Michael Niedermayer wrote:
> > > > Hi
> > > >
> > > > several ppl complained about $subj due to the required buffering
> > > >
> > > > current implementation:
> > > >
> > > > startcodes&forward pointers: M->S->S->2-------> ----> ------->2
> > > >           backward pointers: M<-S<-S<-2<-------1<----1<-------2
> > > >                                       2->0->0->1->0->1->0->0->2
> > > >
> > > > possible alternative:
> > > >
> > > > startcodes&forward pointers: M->S->S->2->       ->    ->      2
> > > >           backward pointers: M<-S<-S<-2<-------1<----1<-------2
> > > >                                       2->0->0->1->0->1->0->0->2
> > > >
> > > > problems of the alternative solution:
> > > > * currently we can detect errors in type 0 frames if they are larger
> > > > then the forward pointer
> > > > 1---->
> > > > 1->0---->oops
> > > > but if the forward pointers dont point to the next type != 0 frame
> > > > this wont work, one solution maybe to add a
> > > > maximum_type_not_0_distance field to the main header
> > > > * following forward pointers becomes more fragile, as there are many
> > > > more bytes involved then currently, the current average distance of
> > > > type 1 frames is 16k, and for an audio stream individual packets may
> > > > be about 100-200 bytes so while currently we need just 1 undamaged
> > > > pointer to reach the next type 1 frame, with the alternative solution
> > > > we would need about 100 undamaged pointers, that is clearly a
> > > > problem, the obvious solution, drop type 1 packets completely, that
> > > > would mean 8bytes more every 16kb, which is a negligible 0.05%
> > > > overhead
> > >
> > > 0.05% is not negligable, it's huge. Isn't that like half the total
> > > overhead?? Why not go back and compare those numbers again, and see
> > > _why_ nut is significantly smaller than mkv and ogm... I bet the
> > > difference is around 0.05%.
> >
> > -rw-r--r--    1 michael  michael    534004 2004-04-04 21:58 testv.avi P
> > -rw-r--r--    1 michael  michael    519843 2004-04-04 21:34 testv.asf P
> > -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 P
> > -rw-r--r--    1 michael  michael    481684 2004-04-04 21:36 testv.ogm P
> > -rw-r--r--    1 michael  michael    481682 2004-04-04 21:33 testv.ogg P
> > -rw-r--r--    1 michael  michael    479882 2004-04-04 21:32 testv.nut P
> > the difference between nut and ogg is 0.375%
> > the difference between nut and mov is 1.948%
> > the raw overhead for a 128kbit 30sec mp2    in nut was 0.332546%
> > the raw overhead for a 128kbit 30sec vorbis in nut was 1.006785%
> > the raw overhead for a 128kbit 60sec vorbis in nut was 0.967177%
> >
> > 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

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