As a general note, you can run the x264 executable from absolutely any directory if you use ./ in front of it. This is because Linux (and probably most other *nixen) denies execution rights to executables not located in directories specified on the system's $PATH. Using ./ overrides that restriction on a run-by-run basis. Same goes for executable shell scripts, thus why ./configure is ./configure, and not just a plain configure.
So basically, if the way you normally use x264 looks like:
x264 --preset ultrafast --tune zerolatency -o output.mp4 input.y4m
but you're in /home/user/x264_build/bin, meaning that it won't run if you try to use the above, then the override command would look like:
./x264 --preset ultrafast --tune zerolatency -o output.mp4 input.y4m
The alternate method would be to add any custom install locations to the $PATH, but that's cumbersome and apt to change with whatever you name the directories, making for extra hassle.
Last edited by qyot27; January 28th, 2011 at 05:45 AM.
I just did a fresh pull of x264 and ffmpeg and compiled x264 with lavf and ffms2 support. So what advantage exactly is this giving me?
I use ffmpeg on a regular basis to encode "any" to libx264 and MPEG2. The ffms2 documentation seems to elude that it's only useful when encoding files directly via the x264 binary and not using ffmpeg? Any clarification on this in plain english would be appreciated. Thanks.
I've only tried lavf support in x264 myself. It allows you use any video file input that FFmpeg can support instead of using a named pipe or some other method of input to x264. One advantage is that you gain access to some of the features that are lacking if you use FFmpeg to encode with x264, such as --tune (see x264 --fullhelp).
Last edited by FakeOutdoorsman; January 28th, 2011 at 08:44 AM.
Since there is some talk of x264 as a standalone encoder I was going to suggest that it might be helpful to add the gpac dev libraries to this guide? This of course would allow direct encoding by the cli x264 encoder into an mp4 container. Mind you I struggled a little on my current system as Gpac has moved home and deleted its old tarball, the currently required svn version reports itself as:
but is picked up with no problems by x264. The old tarball (0.4.5) did not compile with gcc 4.5.2 .Code:andrew@skamandros~$ mp4box -version | head -n 1 MP4Box - GPAC version 0.4.6-DEV (internal rev. 8)
You think that's air you're breathing now?
MP4Box - GPAC version 0.4.5 (build 33) (Ubuntu)Code:MP4Box -version | head -n 1
x264 core:112 Ubuntu_2:0.112.1867-1ubuntu1
Syntax: x264 [options] -o outfile infile
Infile can be raw (in which case resolution is required),
or YUV4MPEG (*.y4m),
or Avisynth if compiled with support (no).
or libav* formats if compiled with lavf support (yes) or ffms support (no).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.flv -> Flash Video
.mp4 -> MP4 if compiled with GPAC support (yes)
Output bit depth: 8 (configured at compile time)
Ego sum, qui sum
You think that's air you're breathing now?
It helps to understand FFMS2's original purpose to distinguish it from either x264's LAVF support or main FFmpeg, and that is that FFMS2 is primarily an AviSynth source plugin - it's meant to provide AviSynth with a method of frame accurate decoding of virtually any video file that FFmpeg supports. It later grew into a cross-platform library which performs essentially the same function for the programs linked against it (such as x264 and Aegisub). LAVF is x264 linking directly against FFmpeg's libraries to open and decode video files, but without the assurance it'll necessarily be frame accurate.
There was a trick to compiling 0.4.5 that involved copying config.h to include/gpac/internal after configure had been run and then going on with the compile. Supposedly the SVN dev branch makes it much simpler than the terror to build that GPAC has historically been, but I'd still recommend going with L-SMASH for MP4 output support. Especially as there was some nasty mux breakage between non-current SVN GPAC versions and x264 back last October. I honestly have no idea if it is completely resolved now (on GPAC's side; old versions are problematic on this, period - it had to do with the atoms that were being written screwing up because x264 properly implemented a feature on the bitstream level and the older builds of GPAC couldn't handle it correctly; it'd mux, but the resulting files were unplayable or went out of sync or had other types of issues) or if there's lingering issues with even a current SVN version of GPAC. No such problems have been reported with L-SMASH, though, or at least not that I can recall.
It's available either as a patch (which periodically needs updating because x264's development outpaces it at times), or as a standalone git branch which also needs periodic updating, but since it is an actual x264 branch, there's no need to worry about it failing to patch.
Both the patch and branch contain the audio encoding features of the x264-audio branch.
Last edited by qyot27; January 28th, 2011 at 02:10 PM.
Thanks for all the clarification. I'll have to give it a try now that I went through all that trouble to get it compiled. There are some great usage examples here if anyone is interested.