Portage 2.1-r2 (default-linux/amd64/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 x86_64) ================================================================= System uname: 2.6.17-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.4 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer -mmmx -msse -msse3 -m3dnow" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/en v /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo " LANG="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/p ackages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X aac alsa avi berkdb bitmap-fonts cdr cli crypt cups dlloader dri dvd dvdread eds emboss encode ffmpeg foomaticdb fortran gif gimp gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 isdnlog jack jpeg kde lzw lzw-tiff mad mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia opengl oss pam pcr e pdflib perl png ppds pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd tiff truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 xorg xpm xv xvid zlib elibc_gl ibc input_devices_keyboard input_devices_mouse kernel_linux linguas_de userland_GNU video_cards_nv vi deo_cards_nvidia video_cards_v4l" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Could you explain your problem, please?
Created attachment 95758 [details, diff] fix the abs -> fabs problem Add following line to ebuild-file: "epatch ${FILESDIR}/ratecontrol_NowWarning.patch" then make a "ebuild ffmpeg-0.4.9_p20051216.ebuild digest" then re-emerge ffmpeg
(In reply to comment #1) > Could you explain your problem, please? The Problem is further specified in related bug 145393. Here the duplication of the comment #17: Today I'm testing the ffmpeg-0.4.9_p20051216. I was first exposed there is no bug. I looked into the sources to understand what's better in ffmpeg-ratecontrol. It's not better! There is the abs-bug in it. After that I make the patch doing the fabs and also the warning like mpeg-patch above. Then I test with that patched version the mpeg4-code and get the message. Now I'm sure the same bug is inside the ffmpeg-code. ffmpeg -t 4 -pass 1 -i Infile.avi -vcodec mpeg4 -s 352x144 OutFilep1.avi ffmpeg -t 4 -pass 2 -i Infile.avi -vcodec mpeg4 -s 352x144 OutFilep2.avi The problem don't exist anymore if I remove the -s Option. In my opinion in that case the higher bitrate correlate better to framesize (704x288).
*** This bug has been marked as a duplicate of 145393 ***
(In reply to comment #4) It's not a duplicate bug! The developement from ffmpeg and mencoder seems to be separately in a wide range. You can see this in the fact that mencoder has solved the abs-fabs problem in the actual ebuild, but ffmpeg dosn't yet. With a little bit fortunateness we can solve the converge-problem with nearly the same patch, but I'm not sure with that.
Why don't you just try some newer snapshots to see whether it's fixed or not?
(In reply to comment #6) I does the wollowing: echo "media-video/ffmpeg" >> /etc/portage/package.keywords emerge ffmpeg media-video/ffmpeg-0.4.9_p20060530 now installed ffmpeg -t 10 -pass 1 -i Infile.avi -vcodec mpeg4 -s 352x144 OutFilep1.avi ffmpeg -t 10 -pass 2 -i Infile.avi -vcodec mpeg4 -s 352x144 OutFilep2.avi failes with: [mpeg4 @ 0x2b5a90ac4f90]Error: 2pass curve failed to converge Error while opening codec for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height Yes, with -b 250 it's OK but really don't looks good.
Thanks for testing.
Being fixed upstream...
(In reply to comment #9) Where and how do I get this fix/patch for testing?
*** Bug 147903 has been marked as a duplicate of this bug. ***
Comment on attachment 95758 [details, diff] fix the abs -> fabs problem This obviously doesn't fix the problem.
Hello - I was bitten by this earlier today when doing some work in dvd::rip. While searching around, it looks like a fix for the issue was checked into ffmpeg's SVN tree pretty shortly after this bug was closed out. The diff in question is available here: http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/ratecontrol.c?r1=6170&r2=6176 The thread in which the patch was fixed starts here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-September/014853.html - you can follow that through the development of the patch up through its commmit on the 4th. I'll be able to verify if this fixes at least my problem in a few minutes, I'll post again once I'm sure. If it does work, it might be nice to have this added into the currently-stable ffmpeg ebuild, since it's an SVN-based version anyway and there's no ebuild available for after this was fixed. I checked and the patch at least applies cleanly to ffmpeg-0.4.9_p20060530 and ffmpeg-0.4.9_p20060816. I could attach the patch as well, if you like.
Well, the patch *does* let me get through the second pass, seemingly without problems. On this particular disc the second pass ended up "freezing" at 99% - I'm not sure if that's related or not. The file it generated looks like it's fine, and this could certainly be some other dvdrip-related problem that I ran into here (I ended up just hitting the "cancel" button - as I said, the actual output file seemed fine afterwards). If someone else could give the patch a try to see if it Works For You, that'd be peachy.
Well, when converting a whole DVD I didn't get the hang-at-the-end problem I mentioned last night, I'm guessing that that's just a separate issue with dvd::rip.
Updated snapshot due 2 weeks from now, let me sort out some issue, a masked snapshot will appear in few days.
Groovy, thanks. It'd be nice to have Actual Releases to use for ffmpeg, no?
