[FFmpeg-devel] manually hacked configure options increase h264 decoding speed significantly

[Michael Niedermayer]

On Thu, Oct 20, 2011 at 10:41:11AM +0200, madshi wrote:
> Hey guys,
> 
> recently I've noticed that ffdshow decodes faster than my
> own ffmpeg dlls. After some digging I found out that ffdshow
> uses a couple of custom configure settings that noticably
> improve h264 decoding performance. So now I'm wondering
> why these options are not activated by default. Is there a
> good reason for that?
> 
> I'm testing on win32, using MingW/GCC for compiling.
> 
> Here's the list of changes I'm currently doing manually to
> config.h:
> 
> #define HAVE_CMOV 1
> #define HAVE_EBP_AVAILABLE 1
> #define HAVE_FAST_CLZ 0
> #define HAVE_FAST_CMOV 1
> #define HAVE_ISATTY 0
> #define HAVE_MEMALIGN 1
> 
> These are all set differently. The biggest performance
> gain comes from activating HAVE_EBP_AVAILABLE,
> but the others seem to help a little bit, too.

if HAVE_EBP_AVAILABLE works for you and isnt enabled then the
autodetection is broken

to say anything about clz and cmov we need to know your exact CPU
and also if this is specified correctly to configure.


> 
> Furthermore ffdshow also uses a modified mem.c with
> "__mingw_aligned_malloc", "__mingw_aligned_realloc"
> and "__mingw_aligned_free". Probably the modified mem.c
> is necessary for being able to set HAVE_MEMALIGN? Not
> sure.

probably ...

a patch that autodetects their availability in configure and uses them
in mem.c if available is welcome


> 
> I can't claim to understand what these options do exactly
> and why they help h264 decoding performance, but I thought
> I should post it here and ask for feedback. If there's no
> disadvantage to these modified options, maybe ffmpeg can
> use these options by default?

ffmpeg wont compile or wont work when we enable things that have been
detected as not available. The existing autodetection has to be fixed,
and its a bit hard for me to do this without a mingw system to test.
Could you look into why it fails ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111020/dbadd825/attachment.asc>