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

[D Richard Felker III]

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%.

> now, if we do drop type 1 packets, the backward pointers would point exactly 
> from one startcode to the previous, this is not terrible usefull, we could 
> simply search for the startcode, and in a damaged stream the backward pointer 
> couldnt be trusted anyway, so we could drop backward pointers too, the result 
> would be without doubt simpler, but would it still be similarly good? rich, 
> ivan what do u think?

I'm not sure. Dropping backwards pointers would recover some of the
loss from using more type-2 frames, so maybe it's a fair tradeoff.

Rich