#175(undetermined:new): Strange increase of the size of dsputil.o
#175: Strange increase of the size of dsputil.o --------------------------+--------------------- Reporter: xhpohanka | Type: defect Status: new | Priority: normal Component: undetermined | Version: git Keywords: | Blocked By: Blocking: | Reproduced: 0 Analyzed: 0 | --------------------------+--------------------- 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 -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
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
#175: Strange increase of the size of dsputil.o ----------------------+--------------------------- Reporter: xhpohanka | Owner: Type: defect | Status: new Priority: normal | Component: undetermined Version: git | Resolution: Keywords: | Blocked By: Blocking: | Reproduced: 0 Analyzed: 0 | ----------------------+--------------------------- Comment (by xhpohanka): this situation appeared ... I have found the commit where the problem starts... be315a3232d96a2704e276f1ebe870a4d249d090 -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175#comment:1> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#175: Strange increase of the size of dsputil.o -----------------------+---------------------- Reporter: xhpohanka | Owner: Type: defect | Status: open Priority: minor | Component: avcodec Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced: 1 Analyzed: 0 | -----------------------+---------------------- Changes (by cehoyos): * priority: normal => minor * status: new => open * version: git => git-master * component: undetermined => avcodec * reproduced: 0 => 1 Comment: This is reproducible on x86_64: 7089265756a84bf884a7c2290c6cda38d4dfd60f: 3488784 libavcodec/dsputil.o be315a3232d96a2704e276f1ebe870a4d249d090: 5712920 libavcodec/dsputil.o -- Ticket URL: <https://avcodec.org/trac/ffmpeg/ticket/175#comment:2> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#175: Strange increase of the size of dsputil.o -----------------------+---------------------- Reporter: xhpohanka | Owner: Type: defect | Status: closed Priority: minor | Component: avcodec Version: git-master | Resolution: invalid Keywords: | Blocked By: Blocking: | Reproduced: 1 Analyzed: 0 | -----------------------+---------------------- Changes (by michael): * status: open => closed * resolution: => invalid Comment: 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. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175#comment:3> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#175: Strange increase of the size of dsputil.o -----------------------+----------------------- Reporter: xhpohanka | Owner: Type: defect | Status: reopened Priority: minor | Component: avcodec Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced: 1 Analyzed: 0 | -----------------------+----------------------- Changes (by xhpohanka): * status: closed => reopened * resolution: invalid => Comment: 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 ... -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175#comment:4> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#175: Strange increase of the size of dsputil.o -----------------------+----------------------- Reporter: xhpohanka | Owner: Type: defect | Status: reopened Priority: minor | Component: avcodec Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced: 1 Analyzed: 0 | -----------------------+----------------------- Comment (by michael): Replying to [comment:4 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 -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175#comment:5> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#175: Strange increase of the size of dsputil.o ------------------------------------+------------------------------------ Reporter: xhpohanka | Owner: Type: defect | Status: reopened Priority: minor | Component: avcodec Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | ------------------------------------+------------------------------------ Comment (by richardpl): I think this is no more relevant since dsputil is or still is being split into several files. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175#comment:6> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#175: Strange increase of the size of dsputil.o ------------------------------------+----------------------------------- Reporter: xhpohanka | Owner: Type: defect | Status: closed Priority: minor | Component: avcodec Version: git-master | Resolution: fixed Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Changes (by richardpl): * status: reopened => closed * resolution: => fixed Comment: I think this have been fixed. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/175#comment:7> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg