Comments on: Theora 1.1 Released

By: NB

NB — Fri, 09 Oct 2009 01:48:23 +0000

mat, Mike: It really should do now – support for AQ was added in r18986, back in May. Chromium took that from ffmpeg, not the other way around – see http://code.google.com/p/chromium/issues/detail?id=17174

I haven’t checked whether it’s bit-exact but it certainly looks OK.

By: dconrad

dconrad — Tue, 29 Sep 2009 11:05:14 +0000

The coeffs are already stored in the the bitstream in Hilbert order; the trick is to simply decode them into a single array and keep pointers to the first coeff of each zigzag index in each plane so that you simply pull the next coeff for each index for each block.

This unfortunately requires duplicating all the EOB and zero run logic in both unpack_vlcs and right before you do IDCT, plus a larger slice size (16 -> 64 pixels), but it’s worth it to avoid the current O(n^2) sorting loop in upack_vlcs.

By: Multimedia Mike

Multimedia Mike — Mon, 28 Sep 2009 17:47:13 +0000

@dconrad: Thanks for the tip regarding ‘-f null’. That definitely helps to narrow the gap.

Libtheora does IDCT in Hilbert order? That blows my mind. Or is it zigzag order?

By: dconrad

dconrad — Mon, 28 Sep 2009 04:57:50 +0000

I was, it turned into a major effort in figuring out how to minimize the cache footprint and eliminate the block macroblock superblock mapping tables. My motivation was drained when I realized that it was impossible to eliminate those ugly mapping tables due to stupidly minor things in the spec, plus I was busy with GSoC and now classes.

But the main reason libtheora is faster is because it doesn’t sort AC coefficients into the blocks that own them, instead doing IDCT in hilbert order so that no reordering is needed.

Also, -f yuv4mpeg4pipe or -f rawvideo involve memcpy() on each pixel row, which is slow, whereas dump_video calls fwrite() on each pixel row, which is much faster. A fairer benchmark would be -f null and excising the fwrite()s from dump_video.

By: Multimedia Mike

Multimedia Mike — Mon, 28 Sep 2009 04:55:32 +0000

@astrange: Thanks for the tip. I think I see where to focus my creativity.

By: astrange

astrange — Sun, 27 Sep 2009 19:10:05 +0000

The problem is the data layout; it spends all its time in the “if (coeff_counts[fragment_num] > coeff_index) continue;” check.

David Conrad was working on that, I think.

By: Xuggler 3.3 « Xuggle

Xuggler 3.3 « Xuggle — Sun, 27 Sep 2009 17:35:40 +0000

[...] the latest libtheora release (1.1), which means you can decode theora video even faster (about 15% or so), and get better rate-control when encoding. – We’ve added the ability to read and write raw [...]

By: Multimedia Mike

Multimedia Mike — Fri, 25 Sep 2009 19:25:21 +0000

@mat: Good question. The release notes mention that this is the first production Theora encoder to use adaptive quantization and I’m not sure if this is in FFmpeg’s decoder yet. We have been merging some of Chromium’s fixes, starting with the security matter (I merged one myself the other day for the Theora decoder).

@Michael: Yeah, that’s nasty. I wonder why that is? There must be something unusual about the VLCs on PS1 games (which were never exactly standardized). VLC reading code isn’t usually that impenetrable. In fact, the entirety of this problematic unpack_vlcs() function fits on a single (tall) web browser page.

Maybe that’s the problem– that it’s not complicated enough.

By: Michael Sabin

Michael Sabin — Fri, 25 Sep 2009 18:49:13 +0000

The ffmpeg macros used for PlayStation VLC unpacking [1] are 3 levels deep, and are impossible to decipher for a mere mortals. I’m sure its magic is blazingly fast, so it makes me wonder just what it is doing, and what other tricks and techniques can be used for VLC unpacking.

[1] http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/mdec_8c-source.html#l00054

By: mat

mat — Fri, 25 Sep 2009 18:44:29 +0000

BTW : does ffmpeg is still able to decode Thusnelda encoded video ?
Last time I check ffmpeg theora decoder doesn’t implement all theora feature.

But some chromium patch seems to implement some features. Will they be merged ?