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

[Michael Niedermayer]

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

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