Decoder accessing uninitialized variable... Re: [theora-dev] Using Theora in games?
Timothy B. Terriberry
tterribe at vt.edu
Thu Feb 26 06:02:14 PST 2004
> (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
> 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.
More information about the Theora-dev