[FFmpeg-devel] Fw: [foms] Paper submissions to LCA

[David Conrad]

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.   
> The

I've been doing benchmarks of ffmpeg's Theora decoder, and libtheora  
is only significantly (~30%) faster in two situations, for different  
reasons:

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.