HOWTO: Install and use the latest FFmpeg and x264

[Amefurashi]

CUT

Thanks, it worked like a charm!
Quick question: generating the executable is fine (I copied it into usr/local/bin), but is it possible to obtain a .deb package too? I need it for some friends...

Regards,
Ame

[qyot27]

Thanks, it worked like a charm!
Quick question: generating the executable is fine (I copied it into usr/local/bin), but is it possible to obtain a .deb package too? I need it for some friends...

Regards,
Ame

If you want a .deb package, just use the checkinstall step from the official guide rather than the regular 'make install' one. I'm not sure if checkinstall still makes the packages install to /usr/local when they have a custom prefix used on them during the configure process, though. You'd have to test that.

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.

[mocha]

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.

[FakeOutdoorsman]

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).

[andrew.46]

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:

andrew@skamandros~$ mp4box -version | head -n 1
MP4Box - GPAC version 0.4.6-DEV (internal rev. 8)

but is picked up with no problems by x264. The old tarball (0.4.5) did not compile with gcc 4.5.2 .

Andrew

[Henrikx]

Why?

MP4Box -version | head -n 1

MP4Box - GPAC version 0.4.5 (build 33) (Ubuntu)


x264 --help
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)

[andrew.46]

Hi Henrikx,

Why?

Well, as it stands FO's guide does not actually include the gpac -dev file required to allow x264 to use an mp4 container, hence my suggestion. My disjointed ramblings about the svn gpac were more to do with my inability, on another distro, to successfully compile gpac 0.4.5 .

Andrew

[qyot27]

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.

Correct. FFMS2 (FFmpegSource2) does nothing in FFmpeg itself.

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.

[qyot27]

Hi Henrikx,



Well, as it stands FO's guide does not actually include the gpac -dev file required to allow x264 to use an mp4 container, hence my suggestion. My disjointed ramblings about the svn gpac were more to do with my inability, on another distro, to successfully compile gpac 0.4.5 .

Andrew

The last GPAC discussion I can remember:
http://ubuntuforums.org/showpost.php...&postcount=330

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.

http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/ (patch)
https://github.com/silverfilain/x264_L-SMASH (branch)

Both the patch and branch contain the audio encoding features of the x264-audio branch.

[mocha]

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.