[MPlayer-dev-eng] forward pointers in NUT and possible NUT simplifications
D Richard Felker III
dalias at aerifal.cx
Thu Apr 15 06:13:53 CEST 2004
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
More information about the MPlayer-dev-eng
mailing list