I’ve probably exhausted all possible ffmpeg argument combinations for encoding with a libx264 codec - none worked, the codec always either segfaults or tells me incorrect parameters. I’ve installed, uninstalled and re-installed all available versions of the codec - no difference.
Did anyone have any luck with it? Are there any tricks or conflicts in different arguments? Does the input file have to be in any particular container/format/codec for the x264 to work on?
My examples:
>ffmpeg -i video.mpg -vcodec libx264 video.mkv
>… Error while opening encoder for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height
Its possible there is a packaging bug in Packman’s ffmpeg or in one of Packman’s libx264. While there is discussion going on the Packman mailing list about an ffmpeg problem, it is not clear to me that this is the same, and hence I think this should be reported to the mailing list.
Do you subscribe to that list?
Even though I think this segfault is a Packman packaging problem (assuming you are using Packman), with respect to your question, are you adverse to using a crutch?
There is a program available from PackMan Packagers called “winff” which is a front end to ffmpeg. It has preset configurations (or templates) that one can apply for encoding. One can let the winff GUI do the conversion, or one can just select in ffmpeg for it to give you its ffmpeg command so you can see how it is done. And then in that later case you can copy and paste the ffmpeg command run the ffmpeg command yourself from a terminal (as opposed to the GUI sending the command).
It segfaults, because I believe there may be a Packman packaging problem.
Typically (not in this case because of the segfault) for this to work you need to use Packman packaged rpms of multimedia. If you do not follow this advise, if you ignore the advice, this may also just segfault. Or it may segfault anyway. In particular to NOT mix videolan and other packaged multimedia apps with Packman packaged versions.
Note I always recommend 4 and only 4 repositories be setup in users’ Software Package Manager. The first 3 are OSS, Non-OSS and Update which are official Novell/SuSE-GmbH repositories. And the 4th is Packman, the largest of the 3rd party repositories of software for openSUSE. Just those 4. No others. None. Not one. Installing apps from others can cause problems (such as segfaults). If you MUST add an app from another repository, then add the 5th repository, install the must have application, and then remove or disable the 5th repository. Do NOT keep the 5th repository enabled. Experienced average users (with openSUSE) and advanced open SUSE uses can get away with out following this advice, but new to openSUSE users can not. Thats just general advice.
Myself ? I’ve been using SuSE/openSUSE since 2001 and I still follow that approach.
There is guidance here for setting up repositories: Repositories/11.2 - openSUSE-Community Again, ignore the temptation there, and stick with ONLY OSS, Non-OSS, Update and Packman. The first 3 (OSS, Non-OSS, and Update) should already be installed. Just add the 4th: Packman.
I also recommend users stay away from the 1 click install, and instead install with the zypper command or via YaST > Software > Software Management.
Again, my recommendation is to add the repos, install the application, and then remove the repos. For example the following commands run with root permissions would do that:
zypper ar http://download.opensuse.org/repositories/home:/microchip8/openSUSE_11.2/ microchip
zypper install h264enc
zypper rr microchip
Yeah, I have a LOT of repositories and I may have a conflict somewhere as you pointed out due to either a bug or “improvement” in YAST to enable to Switch System Packages to the repository (I’ve mentioned this problem already earlier and filled out a bug report) - basically YAST used to show newer versions regardless of what repository they belonged to, but now it only shows newer packages only if they’re available in that repository. So if I have, for example, Kaffeine from Packman, but KDE from Factory, there’s no way any more to update all newer KDE packages without updating Kaffeine as well and then updating Kaffeine gain from Packman - it’s crazy, it used to be sensible before, if your Kaffeine was from Packman, it stayed Packman when updating KDE. Now I have to Switch System Packages to KDE Factory, update all if newer versions available, then go to Packman, Switch System Packages to Packman, then update all if newer versions available.
Anyway, hope it’ll be fixes in 11.3. But I’ve just realised that the windows version of FFMPEG may not come with libx264 compiled in (here’s a guide how to build ffmpeg with libx264 on windows - Quick ffmpeg x264 - FFmpeg on Windows). This may answer the question about ffmpeg not finding the right parameters. As to Linux, first, there may be a conflict between some packages, or second, the libx264 on Linux may be buggy. And why are there 5-10 different versions of it on Packman (-60, -75, -86 or something like that)?
There are no hr presets on windows (because there’s no libx264 I guess), but Linux’s still crashes with hq preset.
Does yours actually work? Have you tried encoding with x264 yourself? What version of libx264 are you using?
I use this for transcoding certain mpg streams I record in MythTV. I had the segfaulting issue until I incorporated beli0135’s suggestion. This is the line I use:
It seems to work, but I’ve just started incorporating the fix.
Just so you know, the “-async 24” is there because I have one channel that doesn’t record well, and ffmpeg drops a LOT of frames. Without it, the audio was 15+ seconds off by the end of the video.
I’ve been trying to coming up with a list of the x264 presets for ffmpeg, and thus far have not been as successful as I would like. Thus far I have come up with: Video/Audio Encoding Cheat Sheet for FFmpeg
default, fastfirstpass, lossless_ultrafast, lossless_slower, baseline, slowfirstpass, lossless_fast, lossless_max, normal, hq, lossless_medium, ipod320, main, max, lossless_slow, ipod640
Searching some more, I saw references stating that the vpre preset should not always be needed. Hence I have a suspicion I will be told that a preset (such as vpre) should not be necessary with ffmpeg.
If that is the case (and I don’t know, the documentation is wide and confusing for me), then we could be back to this being a packaging (?) of an ffmpeg (?) bug … I guess I’ll wait and see as to what I stir up and how much I am corrected in my winFF post (if any).
But thanks for the -vpre option as I note it does work.
Well, I do not know if it is a bug or not, I noted that it won’t work without -vpre, which I found on some other forum when I also had troubles with it.
I dont use winFF, but I couldnt make any video without -vpre on libx264. However, any other setting you put, overrides settings in -vpre, so I think it is ok to use -vpre hq, and then pack your own settings you wish to override.
Well, at least it does like that with ffmpeg.
incredible, I didnt belive the preset change, it was so funny but worked.
I choosed " -vpre max " just to try and now it’s processing.
I recently (today) tried in the ubuntu, there after installing libavcodec it was solved.
Its very faulty there exists many “same” tools
x264 is to convert yuv files to h264 files, It doesn work with already coded files
there exists x264enc which forces to install postfix in ubuntu, here it required pv (I dont completely know what it is)
and the old friend ffmpeg.
all these tools have different syntax, you need to read, also confusing. Also they require you to type help in their style:
x264 --help
ffmpeg -help
I think this is because of not freedom, it is because of to make people feel bad about linux.
the work can be seen in sarkisozu.web.tr.
Sorry to read of your frustration, but I can assure you, there are no efforts there to discourage users. Just the opposite, … the effort is to help people.
But the coding is done by volunteers, sometimes they code just for themselves to use, and they do NOT use other apps (like you pointed out) and hence they the authors/developers of the programs have no idea that their method is different from some one elses. Then a friend see’s their app, asks that they share it, and then you and I have access to the app, … where the sorts of inconsistencies that you observe are then encountered.
In particular to NOT mix videolan and other packaged multimedia apps with Packman packaged versions.