[FFmpeg-devel] Fw: [foms] Paper submissions to LCA
Thu Jul 16 22:44:33 CEST 2009
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>
>>> 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
>>>> html5 video tag. We could talk about whats great, and not so
>>>> 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.
More information about the ffmpeg-devel