Opened 13 years ago
Closed 12 years ago
#175 closed defect (fixed)
Strange increase of the size of dsputil.o
Reported by: | Honza | 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 by , 13 years ago
comment:2 by , 13 years ago
Component: | undetermined → avcodec |
---|---|
Priority: | normal → minor |
Reproduced by developer: | set |
Status: | new → open |
Version: | git → git-master |
This is reproducible on x86_64:
7089265756a84bf884a7c2290c6cda38d4dfd60f: 3488784 libavcodec/dsputil.o
be315a3232d96a2704e276f1ebe870a4d249d090: 5712920 libavcodec/dsputil.o
comment:3 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | open → 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.
follow-up: 5 comment:4 by , 13 years ago
Resolution: | invalid |
---|---|
Status: | closed → 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 by , 13 years ago
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 by , 12 years ago
I think this is no more relevant since dsputil is or still is being split into several files.
comment:7 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I think this have been fixed.
I have found the commit where the problem starts...
be315a3232d96a2704e276f1ebe870a4d249d090