[vlc-devel] [PATCH] Contribs: ffmpeg, enable small when deactivating encoder

[Martin Storsjö]

On Sun, 5 Feb 2012, Rafaël Carré wrote:

> The doc says:
> --enable-small           optimize for size instead of speed
>
> and it does two things:
> * remove __attribute__((always_inline))
> * add -Os to CFLAGS, which you override with -O2; instead of -O3 previously.

FWIW, the "some libav guy" who suggested it to j-b was me.

--enable-small changes a few other things within libav except for changing 
the optimization flags to -Os, it removes some extra cruft (like long 
description strings for codecs and similar minor things), and in some 
codecs chooses alternative implementations that are smaller but perhaps 
slightly slower (e.g. runtime calculation instead of using some built-in 
table or so).

The combination of --enable-small with -O2 was based on an old benchmark 
done by me, for a different use case (building one single video encoder 
only, everything else disabled), where I tested with and without 
--enable-small, combined with optflags -Os, -O, -O2, -O3.

In that old test, the file sizes (for libavcodec.so IIRC) were as follows:
normal O3 1857068
normal O2 1134524
normal O  1087228
normal Os  888752
small  O3 1437300
small  O2  716372
small  O   680692
small  Os  515528

So in this case, small+O2 was the sweet spot - noticably smaller than most 
of the other configurations, not noticably slower than the other ones, and 
noticably faster than small+Os.


> I have a few questions:
>
> * Why override -O3 with -O2?

Because -O3 IIRC more aggressively inlines stuff, which might give the 
last percent of performance, but quite massively increases the file size.

> * Why override -Os, when you want to optimize for size?

Because -O2 might produce faster code which isn't all that much bigger 
than with -Os.

Also, j-b mentioned that it didn't build properly with only --enable-small 
without changing optflags to -O2, most probably due to some arm inline 
assembly that gcc wasn't able to allocate registers for when using -Os.


> * What is the result of this patch:
>  * How much smaller is libav*?

Don't remember exactly how much smaller it was, but the final .apk shrunk 
from 6.0 MB to 5.2 MB IIRC.

>  * How much faster/slower?

No idea far for VLC - proper benchmarks of these different combinations is 
very much welcome I guess, in setups that are relevant for VLC (my old 
benchmarks tested just a video encoder).

> IMO it does not make sense at all to optimize ffmpeg for size; unless
> decoding speed is not affected negatively, or at a very small rate.
> In any case it should be benchmarked before and after the patch.

In my original case, it was only affected negatively at a very small rate, 
which made the trade-off sensible to me.

> My android device is a dual core 1.2GHz with 1GB of ram, I think I have
> enough memory to optimize FFmpeg for size.
> Encoders are disabled because I use it to consume media, not to create.
>
> I for sure have a couple megabytes of RAM to spare to get the fastest
> decoders, especially when faster decoding means longer battery life.
>
>
> If you are too cheap to have FFmpeg use more memory, then you should
> have added specific options to your CFLAGS like -mthumb -Os or
> -vomit-frame-pointer, but in the default case it should optimize for
> speed (configure does that itself already).

I don't think the actual installed size was the target of j-b's 
optimization, I think it was secondary to shrinking the size of the 
download package. Also, configure already adds -fomit-frame-pointer in all 
of these configurations, unless one adds --disable-optimizations.

// Martin