Opened 8 years ago
Closed 6 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 8 years ago by xhpohanka
comment:2 Changed 8 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 8 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: ↓ 5 Changed 8 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 8 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 6 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 6 years ago by richardpl
- Resolution set to fixed
- Status changed from reopened to closed
I think this have been fixed.
I have found the commit where the problem starts...
be315a3232d96a2704e276f1ebe870a4d249d090