Opened 7 years ago

Closed 5 years ago

#175 closed defect (fixed)

Strange increase of the size of dsputil.o

Reported by: xhpohanka Owned by:
Priority: minor Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Change History (7)

comment:1 in reply to: ↑ description Changed 7 years ago by 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

comment:2 Changed 7 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Priority changed from normal to minor
  • Reproduced by developer set
  • Status changed from new to open
  • Version changed from git to git-master

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

comment:3 Changed 7 years ago by michael

  • Resolution set to invalid
  • Status changed from open to closed

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.

comment:4 follow-up: Changed 7 years ago by xhpohanka

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 ...

comment:5 in reply to: ↑ 4 Changed 7 years ago by 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

comment:6 Changed 5 years ago by richardpl

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

comment:7 Changed 5 years ago by richardpl

  • Resolution set to fixed
  • Status changed from reopened to closed

I think this have been fixed.

Note: See TracTickets for help on using tickets.