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

[Alexander Strange]

On Jul 16, 2009, at 3:33 PM, M?ns Rullg?rd wrote:

> Jason Garrett-Glaser <darkshikari at gmail.com> writes:
>
>> On Thu, Jul 16, 2009 at 6:37 AM, Mike Melanson<mike at multimedia.cx>  
>> wrote:
>>> Frank Barchard wrote:
>>>>
>>>> I don't feel qualified to speak for ffmpeg, but 2 potential topics
>>>> would be Chrome, and subtitles:
>>>>
>>>> 1. The Chrome topic, because Chrome/Chromium use ffmpeg to  
>>>> implement
>>>> html5 video tag.  We could talk about whats great, and not so  
>>>> great,
>>>> about using ffmpeg, which would hopefully lead to improvements.
>>>
>>> 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.
>
> Could we improve this?

One thing is that the MPEG codecs decode an entire MB into the context  
before running idct/compenstation/etc on them, instead of interleaving  
them, so it wastes some cache misses reloading them. (not to mention  
the contexts being so large in the first place)

For H264 this would make the decoder bigger of course, and you might  
even have to clone more functions.

But there's some good easy optimizations left - making an AV_COPY64  
for 32-bit platforms (use double on PPC, SSE on x86, etc) and  
replacing the uint64_t* copies with it would help, for instance.

I almost submitted that one already, but we can't have SSE2 out of dsp  
functions yet, since runtime cpudetection can't be turned off for lavc.


>> The Theora decoder, well, nobody gives a crap about Theora anyways.
>> And the speed doesn't matter, since the Firefox developers seem to
>> have intentionally sabotaged Theora's decoding speed in 3.5.
>
> What did they do?

The Windows build was released with SIMD off (but not any other  
build). It's fixed in trunk.