Strange increase of the size of dsputil.o

[xhpohanka]

Hello,
I'm using this configure command to build libav* libraries

../../ffmpeg-git/configure \

--enable-memalign-hack \
--disable-ffmpeg --disable-doc \
--disable-ffplay --disable-ffprobe --disable-ffserver \
--disable-avfilter --disable-avdevice --disable-network \
--disable-pthreads --disable-mpegaudio-hp --disable-swscale-alpha \
--disable-fft --disable-golomb --disable-huffman --disable-lpc \
--disable-mdct --disable-rdft --disable-vaapi --disable-vdpau --disable-dxva2 \
--disable-everything \
--enable-encoder=mpeg4 \
--enable-muxer=mp4 \
--enable-encoder=h263p \
--enable-muxer=h263 \
--enable-muxer=tgp \
--enable-encoder=flv \
--enable-encoder=adpcm_swf \
--enable-muxer=flv \
--enable-decoder=rawvideo \
--enable-decoder=h263p \
--cross-prefix=arm-unknown-elf- \
--enable-cross-compile --target-os=none --cpu=arm926ej-s \
--target-exec=arm-unkonown-elf-run.exe \
--arch=armv5te \
--extra-cflags="-mcpu=arm926ej-s -mthumb-interwork -mlittle-endian -mfpu=vfp -mfloat-abi=soft" \
--extra-ldflags="-nostartfiles" \
--prefix=/e/_dev/h263/ffbuild/ff-arm-spec \
--enable-version3

It worked fine until I did a rebase last month. That means dsputil.o file had size 2.1MB with debug info. For example in Commit:22180e7a5a39f8a77498fcbce54368ecc408df8f.

After the rebase onto actual master the size of dsputil.o increased to 4.7MB, which seems really wierd to me. Maybe it can be a gcc bug/feature as it is connected with optimization (--disable-optimizations reduces the size again but the speed ...). Unfortunately I can't track the commit when this situation appeared I'm only sure that the commit mentioned above is OK.

I'm using gcc 4.4.5 for arm-unknown-elf target on windows/mingw.

$ arm-unknown-elf-gcc -v
Using built-in specs.
Target: arm-unknown-elf
Configured with: ../../gcc-4.4.5/configure --prefix=/e/gcc --target arm-unknown-elf 'CFLAGS_FOR_TARGET=-msoft-float -mfpu=vfp' --enable-interwork --enable-multilib --with-float=soft --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c++,c --with-system-zlib --disable-libmudflap --disable-libgomp --without-headers
Thread model: single
gcc version 4.4.5 (GCC)

regards
Honza

[xhpohanka]

After the rebase onto actual master the size of dsputil.o increased to 4.7MB, which seems really wierd to me. Maybe it can be a gcc bug/feature as it is connected with optimization (--disable-optimizations reduces the size again but the speed ...). Unfortunately I can't track the commit when this situation appeared ...

I have found the commit where the problem starts...
be315a3232d96a2704e276f1ebe870a4d249d090

[cehoyos]

This is reproducible on x86_64:
7089265756a84bf884a7c2290c6cda38d4dfd60f: 3488784 libavcodec/dsputil.o
be315a3232d96a2704e276f1ebe870a4d249d090: 5712920 libavcodec/dsputil.o

[michael]

The size increase is due to the 10bit h264 support i suspect.
patch welcome to make it less without speed loss
Beyond that it doesnt seem to be a bug.

[xhpohanka]

Unfortunately this change make ffmpeg less usable on embedded systems. When ffmpeg is configured for only several codecs this increase size of its binary more than twice. I suggest to put things needed only by h264 to separate files (if it is possible) to keep ffmpeg scalability ...

[michael]

Replying to xhpohanka:

Unfortunately this change make ffmpeg less usable on embedded systems. When ffmpeg is configured for only several codecs this increase size of its binary more than twice. I suggest to put things needed only by h264 to separate files (if it is possible) to keep ffmpeg scalability ...

I agree this is an issue, and a patch improving it is welcome, shouldnt be hard if someone searches for some easy thing to contribute

[richardpl]

I think this is no more relevant since dsputil is or still is being split into several files.

[richardpl]

I think this have been fixed.