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

[D Richard Felker III]

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?

Rich