Re: [mpeg2-dev] A funny stream

[Peter G. <pe...@el...>]

>Well I still dont understand, because you said you use the same IDCT
>in the encoder and the decoder, and in that case errors should not
>accumulate... basically the prediction frames should be bitwise
>identical in the encoder and the decoder and so there is no reason to
>get error accumulation... is there ? Also given our statistics in the
>IEEE tests, I dont see that the errors should be visible after 100
>frames. In my maths the errors should still be a deviation of about 1
>level of gray after 100 frames - not anything noticeable really.
>
Don't forget about quantizer and saturation. I'm not sure there are no 
bugs in the encoder. I guess the inverse quantizers are slightly 
different, and this iduces errors %-) But you are right, equal routines 
produce equal rounding errors, so the result in both decoders should be 
equal.
BTW, I recall I have used a different decoder to view the result... It 
was MProbe, I suppose. %-)

>This weekend I've been looking at an ffmpeg bug related to IDCT and I
>couldnt put my finger on it. They use our IDCT and for some streams
>(basically one stream that has very little I pictures, I think one I
>every 100 or 132 pictures) they get bad error accumulation, in the
>form of horizontal stripes and/or color drift. Someone came up with a
>different IDCT routine, that doesnt behave much better than ours in
>the IEEE tests (ok, about 5-10% better), but does not show up this
>error accumulation. This is all in their divx codec. But I dont
>understand: according to the IEEE tests our worst mean square error is
>0.01, and our worst mean error (which is what should really matter for
>error accumulation) is 0.0026. So even if you multiply these by 100 or
>132, you really shouldnt get anything noticeable at all !!!!! somehow
>it seems that the stastistical tests do not match the behaviour of
>their divx codec, and I can not understand why at all.
>
Are you sure they haven't changed anything else except the idct? They 
can add error in motion compensation, block adding, etc. Stripes don't 
appear suddenly after 132 frames. And if there is a problem with idct, 
they should appear on luma much earlier.

>
>Any idea about this ?
>
I'd like to take a look at this first before I say anything.

Peter