HOWTO: Install and use the latest FFmpeg and x264

[mc4man]

?

Now I think I have two sets of libavcodecs, one statically built with ffmpeg following this guide and then there is another installed with restricted extras and Medibuntu before. But I have to make sure when I go home later. One of my questions was basically I am not sure which one will be used by what...

No - you only have 1 set of the 'libavcodes', those are the shared libs that you've installed from medibuntu, they end in .so (shared object file'

Sources that were built against their 'corresponding' -dev packages will then depend on (use), those shared libs. So that would be all the repo/ppa apps/plugins that depend on the ffmpeg libs'.
To see run this something like this, using the exact name of the repo libavcodec package, on 11.10 it's llbavcodec53 or libavformat53, ect.

apt-cache rdepends libavcodec53

So if you build a source that uses the repo/ppa libavcodec-dev, libavformat-dev, ect. they will also then depend on (use) the shared libs, libavcodec53, libavformat53 ect. That was the case with k3b, we built against the repo libavcodec-dev, libavformat-dev, so it now depends on those shared libs.

When you build a source statically or against a static depend then it will not depend on the associated shared libs. A clear example is this how-to, ffmpeg is a static build, using a static x264

So the ffmpeg binary does not depend on any of the ffmpeg shared libs, nor on libx264. It does depend on all of the .so's associated with the -dev packages you installed or had installed prior to building ffmpeg

You can see this clearly here if run when your static, 'ala this how-to' ffmpeg is installed - there will be no libx264* or libavcodec53, ect. listed

ldd /usr/local/bin/ffmpeg

If you were to uninstall your ffmpeg built, install the repo ffmpeg, & run that command again you'll see the difference.

As far as the apps that use the ffmpeg binary itself. They will use whichever one that is installed. (try not to have more than 1 ffmpeg installed at once
If it's your built one then most of the time things will be fine, sometimes maybe not, they need the usually older repo version.

Hopefully this is somewhat informing, don't consider definitive or even absolutely technically correct, I mainly know whatever I think I know from observing

[beew]

Hi, mc4man,

Thanks for the detailed explanation, you are the man!

How do you know if something is statically build? (I take it to mean that it is built in such a way that it is linked to its own versions of whatever libraries that it uses, rather than the system wide?)

[mc4man]

How do you know if something is statically build?

Only sources that you build yourself May be. No repo/ppa source is built static only, (at least anything of concern) nor is static linking allowed (as far as I know

As far as your builds, that depends on the source, if they use a configure script then ./configure --help will usually show you.
Some, like ffmpeg, default to static only, others may default to static & shared, some, like x264, need either or both to be specified

[qyot27]

The facetious answer to knowing if something is built statically is 'the binary is larger'. That still means you can see that it's larger, meaning you'd have to be comparing it to a shared build.

Basically,
Static = self-contained (and therefore larger)
Shared = not self-contained; relies on external libraries

For instance, taking Windows builds of FFmpeg as an example:
I always build as static. My static build of ffmpeg.exe is 10 megabytes.

Zeranoe's shared build of ffmpeg.exe is only 126 kilobytes, but has to have all of its dependency dlls either in the same folder or on the PATH to be usable. These dlls are much larger - avcodec-53.dll alone is 13 megabytes (there can be size differences due to feature support; my static builds don't have any external libraries included except for zlib, bzip2, and xvidcore).

In short, the difference between static and shared is where the 'mass' is - in a static build, the binary itself has all of the mass; in a shared build, the binary is small and depends on libraries in order to function, with the libraries having all the mass.

[FakeOutdoorsman]

Mandelbrot set:

ffplay -f lavfi mandelbrot

[beew]

Hi,

Kazam screen caster has stopped working, I am not sure if this has to do with switching to this build of ffmpeg, or if the problem lies elsewhere. This is the terminal output.

Xlib.protocol.request.QueryExtension
 ffmpeg -f alsa -i pulse -f x11grab -r 30 -s 1366x768 -i :0.0+0,0 -ac 2 -acodec flac -ab 128k -vcodec libx264 -vpre lossless_ultrafast -threads 0 /tmp/tmpvCzVAk.mkv
ffmpeg version git-2011-11-11-985e768, Copyright (c) 2000-2011 the FFmpeg developers
  built on Nov 11 2011 06:06:01 with gcc 4.5.2
  configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree --enable-postproc --enable-version3 --enable-x11grab --enable-libvpx
  libavutil    51. 24. 1 / 51. 24. 1
  libavcodec   53. 31. 0 / 53. 31. 0
  libavformat  53. 20. 0 / 53. 20. 0
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 47. 2 /  2. 47. 2
  libswscale    2.  1. 0 /  2.  1. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[alsa @ 0x92c9ae0] Estimating duration from bitrate, this may be inaccurate
Input #0, alsa, from 'pulse':
  Duration: N/A, start: 1321233958.242020, bitrate: N/A
    Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
[x11grab @ 0x92cec80] device: :0.0+0,0 -> display: :0.0 x: 0 y: 0 width: 1366 height: 768
[x11grab @ 0x92cec80] shared memory extension found
[x11grab @ 0x92cec80] Estimating duration from bitrate, this may be inaccurate
Input #1, x11grab, from ':0.0+0,0':
  Duration: N/A, start: 1321233958.328359, bitrate: 1007124 kb/s
    Stream #1:0: Video: rawvideo (BGRA / 0x41524742), bgra, 1366x768, 1007124 kb/s, 30 tbr, 1000k tbn, 30 tbc
File for preset 'lossless_ultrafast' not found
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/kazam/app.py", line 159, in cb_save_requested
    shutil.move(self.screencast.get_recording_filename(), uri)
  File "/usr/lib/python2.7/shutil.py", line 292, in move
    copy2(src, real_dst)
  File "/usr/lib/python2.7/shutil.py", line 127, in copy2
    copyfile(src, dst)
  File "/usr/lib/python2.7/shutil.py", line 81, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '/tmp/tmpvCzVAk.mkv'

Please advise, and my apologies if problem is not with ffmpeg, in that case I will start a different thread. Thanks.

[FakeOutdoorsman]

I'm not familiar with Kazam, but if you want to use it you will have to somehow change the FFmpeg encoding command from:

-vpre lossless_ultrafast -threads 0

to

-preset ultrafast -crf 0

The method of presets has changed, and Kazam appears to be using the old preset system. The -threads 0 is superfluous now that it should be the default with libx264.

[beew]

I'm not familiar with Kazam, but if you want to use it you will have to somehow change the FFmpeg encoding command from:

-vpre lossless_ultrafast -threads 0

to

-preset ultrafast -crf 0

The method of presets has changed, and Kazam appears to be using the old preset system. The -threads 0 is superfluous now that it should be the default with libx264.

Hi, thanks for the reply. Kazam is a gui,if I use it I wouldn't want to do it in the terminal. I am not sure how to change the encoding command since it seems to be hard coded. I will see what I happens if I try making screencast directly with ffmpeg instead.

[ppqq]

Hi, I've been editing mpeg movies in Avidemux and when I play the output file there is a fraction of a second of blocky picture where the movie was cut and joined.

I suspect this is not Avidemux but the encoder that it uses, so is that ffmpeg?

As far as i know I followed the instructions at the beginning of this thread to install the codecs, not too long ago. I run ubuntu natty, 64bit on core duo, cq40 laptop, 4gb.

any help would be appreciated!
thanks

[FakeOutdoorsman]

I believe Avidemux contains some FFmpeg code, but I don't think it uses any FFmpeg libraries as a dependency, so following this guide probably won't make Avidemux change its behavior.

Are you simply cutting and joining clips? This can often be deceptively tricky if you are not willing to re-encode (depending on your input formats).