[Theora-dev] Experimental decoder

[Timothy B. Terriberry]

<40F09A4C.7060501 at vt.edu> <1089543888.867.40.camel at localhost>
Message-ID: <40F13705.90706 at vt.edu>

This sounds like it's probably related to my latest changes, which I
didn't really test with my encoder (they seemed to work just fine with
the reference encoder).


> (gdb) p _dec->state.nfrags
> $10 = 1716
> (gdb) p ti
> $11 = 511141
>
> Hm, that value of ti looks way too high (from my reading of the source).

Yes, ti should never exceed the number of coded blocks (which should
obviosuly be no more than nfrags).

> (gdb) p pli
> $12 = 0
> (gdb) p _ntoks_left[pli][_zzi]
> $13 = 283
> (gdb) p cfi
> $14 = 99
> (gdb) p eobs
> $15 = -2146972505
> I can't see myself yet what's causing this, but I hope this information can help.
> I'm afraid I don't know where to put asserts in the decoder/encoder to see if this
> can be caught, but I'll keep reading the source :)

Yay! The more eyes, the better.

> I did notice that this looks iffy though:
>
>       if(skip<0)eobs-=skip;
>       else{
>         run_counts[skip-1]++;
>         cfi++;
>       }
>
> since (unless skip can never be 0) it could do (*(run_counts - 1))++; that would
> increment cfi twice instead of once on this platform (PC - though I haven't checked
> the assembler yet).

Generally the compiler doesn't have to obey the order you declare
variables in when it puts things on the stack, so it could really be
incrementing anything, except...