Decoder accessing uninitialized variable... Re: [theora-dev] Using Theora in games?

[Timothy B. Terriberry]

> (from DecodeMVectors() in theora_static/decode.c) generates this error:
> "Run-Time Check Failure #3 - The variable 'MVect' is being used without
> being defined.".

For macro block modes which do not have a motion vector, the values 
stored in FragMVect are never used. There's a list of which is which in 
the ModeUsesMC array. You can verify that in all the cases in which 
MVect is not initialized, the entry in this array is 0, and so the 
values are never actually used.

This is not to say that there aren't memory access problems somewhere in 
the decoder. While testing with some (unintentionally) broken streams, I 
was able to make the decoder crash, write into memory it had not 
allocated, etc. I haven't had time to investigate all those problems 
yet, however. In theory the decoder should work (but possibly produce 
garbled output) regardless of the bit content of the input. My guess is 
the problems are with decoding zero runs of DCT coefficients that extend 
beyond the end of a block, but there could be other issues as well.

> Other than that, splayer works great. Decoding speed is even better than I
> have expected (from one little test that I tried). Overall, I'm impressed,
> especially considering that this is all in "alpha" stage. Still have to
> check actual picture quality, tough I doubt there can be much problems
> there.
> 
> What I am more concerned about would be:
> 
> 1) streaming bandwidth variations and

When streaming, the correct behavior (for Ogg) is to continuously read 
pages, and buffer packets until you have at least some data available 
for every stream. No seeking is required.

Current tools sort pages by the end time of the last packet, which does 
not quite give optimal buffering. However, in practice the discepancy 
won't be more than a few video frames worth of audio.

> 2) decoder memory usage.

The big numbers are 9*(w+32)*(h+32)/2 bytes for the 3 reference frame 
buffers required and 24*63*80 bytes (~118 K) used for the Huffman codes. 
However, the current decoder also uses a ton of extra storage space for 
decoding the DCT tokens (more than 6*w*h/2 bytes) due to the ordering of 
these coefficients in the bit stream. I think it's possible to avoid 
this by scanning each packet twice, which may even result in a speed win 
for large frame sizes because of better cache coherency. No one's done 
this, or tested the results, however. There are a number of other places 
the decoder could be significantly sped up, too, such as in decoding the 
Huffman codes themselves.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.