[MPlayer-dev-eng] Flaming NUT

[D Richard Felker III]

On Thu, May 06, 2004 at 10:21:12PM -0400, D Richard Felker III wrote:
> > > - improving error resilience
> > 
> > So far, I haven't sow anything that improve error resistance.
> 
> Maybe current error resilience is comparable to the original spec,
> which you love so much and which I really dislike. I'm talking about

Actually, I changed my mind. I want to claim error resilience is much
better than the original spec, at least in terms of how the original
spec was meant to be used.

Ivan, one of your big complaints with "type0 frames" and the changes
that came out of them is that you lose all frames until the next
startcode if there's minor header corruption. But the old spec used
"subpackets" (aka lacing) to store lots of packets together as one
unit. If the single header for the master packet was damaged, all of
the subpackets would be lost!

Of course you had the option of not using subpackets, but then you
would incur a huge overhead (take a look at how big the old headers
were!), so I don't think that was a realistic option.

Keep in mind that when we added "type0" frames, they were only
intended to be used in the same pattern as subpackets, so that even if
you couldn't recover before the next "type1" or "type2" frame, the
loss would be no greater than it was back in the old subpacket system. 

Since then, we decided that the type0/1/2 system was a little bit
silly, and added complexity by having arbitrary different frame types.
Thus, we removed frame types and made startcodes a separate unit.
Provided you position startcodes in the same pattern as you would have
used with subpackets in the old spec, the error recovery should still
be just as reliable.

Finally, the current spec has much less overhead with the same level
of recovery, so alternatively you can greatly increase the frequency
of startcodes (even put a short startcode on every frame if you like!)
and still have much lower overhead than with the original spec. Or in
other words, at the same level of overhead, much better error
recovery.

Rich