[FFmpeg-devel] Fw: [foms] Paper submissions to LCA
Fri Jul 17 02:43:40 CEST 2009
On Jul 16, 2009, at 7:38 PM, Frank Barchard wrote:
> 2009/7/16 M?ns Rullg?rd <mans at mansr.com>
>> Jason Garrett-Glaser <darkshikari at gmail.com> writes:
>>>> That's easy enough: The H.264 decoder is great; the Theora decoder
>> sucks. :)
>>> The H.264 decoder isn't great because CoreAVC is a crapton faster,
>>> primarily due to better architecture, despite the fact that ffmpeg's
>>> assembly is significantly superior.
> Chrome uses ffmpeg-mt, which is pretty fast. It would be nice if
> that made
> it into mainline.
>> The Theora decoder, well, nobody gives a crap about Theora anyways.
> Theora might be more interesting, being simplier, if it worked on
> lower end
> CPU's. Currently the ffmpeg version is about the same speed as H264.
> I'm told the xiph version is faster. Performance isnt everything.
I've been doing benchmarks of ffmpeg's Theora decoder, and libtheora
is only significantly (~30%) faster in two situations, for different
1: HD (720p and up). This isn't particularly important for the
internet since the bitrate needed for Theora at these resolutions is
too high to be feasible. This will be solved by not sorting
coefficients into raster order when they're decoded and instead doing
MC/IDCT in Hilbert order.
2: On the ARM11. I'm pretty sure this is mainly due to a lack of L2
cache (and the small L1 cache); being smarter with cache usage should
fix this. On the Cortex-A8, ffmpeg is under 5% slower than libtheora
for 640x480 and under before NEON optimizations.
That said, I have been working on fixing these two problems and it's
led to a pretty significant rework of almost everything but the
initialization code, so I don't know how easy it will be to merge back
in once I'm done.
More information about the ffmpeg-devel