While trying to use ffmpeg with simple parameters, and using libx264 as vcodec, then ffmpeg usually fails to run, showing this message: [libx264 @ 0x64bf30]broken ffmpeg default settings detected [libx264 @ 0x64bf30]use an encoding preset (vpre) This has been mentioned at the forums a few times: http://forums.gentoo.org/viewtopic-t-804441.html http://forums.gentoo.org/viewtopic-t-816950.html And I know that it used to work previously, but got broken recently. The same command-line that used to work last year stopped working a few months ago (not sure exactly when). I know that either ffmpeg-0.5-r1 or ffmpeg-0.5_p19928 used to work, but the current ffmpeg-0.5_p20373 is broken. Sample command-line: ffmpeg -threads 2 -i inputfile.avi -f mp4 -vcodec libx264 -b 250000 -sameq -s 320x240 -acodec copy -y outputfile.mp4 Other command-lines from the above forum topics: ffmpeg -f image2 -r 20 -i 'frame%d.png' -vcodec libx264 movie.mp4 ffmpeg -threads 2 -i inputfile.avi -vcodec libx264 -b 1100000 -acodec libmp3lame -ab 96000 outputfile.avi It's work noticing that adding "-vpre hq" or even "-vpre default" right after "-vcodec libx264" is enough to make ffmpeg work again. That setting makes ffmpeg look for a preset at ~/.ffmpeg/ and /usr/share/ffmpeg, and those preset files are ok. Thus, I conclude that the built-in defaults (stored inside the binary executable or the library) are broken. Tested with stable amd64: [ebuild R ] media-libs/x264-0.0.20091021 USE="threads -debug -pic" 0 kB [ebuild R ] media-video/ffmpeg-0.5_p20373 USE="X alsa encode faac faad gsm hardcoded-tables ipv6 jpeg2k mmx mp3 opencore-amr sdl speex ssse3 theora threads v4l v4l2 vdpau vorbis x264 xvid zlib -3dnow -3dnowext (-altivec) -bindist -cpudetection -custom-cflags -debug -dirac -doc -ieee1394 -jack -mmxext -network -oss -pic -schroedinger -test" VIDEO_CARDS="nvidia" 0 kB
I can confirm this bug. Encoding videos in h264 with media-video/dvdrip is broken because of this.
I did some testing, and these are the minimum parameters I was required to pass (instead of passing "-vpre default"): -qcomp 0.6 -i_qfactor 0.71 -g 250 -me_range 16 -partitions +parti8x8+parti4x4+partp8x8+partb8x8 Of course, the values don't need to be the same as these. Not sure if this helps to find the source of the problem, though.
Also, while using blender and trying to render the output with ffmpeg and H264, I get this message: "Couldn't initialize codec" Using ffmpeg (in blender) with other codec works well. Tested with media-gfx/blender-2.49b. This same blender version used to work well last year (the same time when standalone ffmpeg was working).
This check was added to x264 to prevent applications from inadvertently using the (horribly broken) ffmpeg default settings. Unfortunately, after over a year, ffmpeg default settings are still broken due to the lack of codec-specific defaults (it attempts to force a set of defaults designed for its own encoders onto all other encoders, even when it doesn't make any sense). Don't try to get around it by attempting to cheat the heuristic; the only proper solutions are: 1. Insert the correct default settings manually (crappy solution, but it works). or 2. Fix the application to use libx264 directly instead of libavcodec, bypassing the problematic code. or 3. Fix ffmpeg to suck less.
Using the FFmpeg profiles to work around this probably is a good idea, it should give you reasonable settings.
(In reply to comment #5) > Using the FFmpeg profiles to work around this probably is a good idea, it > should give you reasonable settings. > should be the solution; not a bug ?
