HOWTO: Install and use the latest FFmpeg and x264

[Nullack]

mtune and march as native just means gcc uses the best available for your specific cpu - your native setup.

[Leefmc]

I can confirm this error. I'm getting the same error but haven't found a reason or solution yet.

Well im not even sure what im missing out on haha. I know very little about encoding videos (actually, i know just about all i want to heh ).

[PGLGreg]

mtune and march as native just means gcc uses the best available for your specific cpu - your native setup.

How do you think gcc knows that, or even knows what cpu I have? If I had compiled gcc and tailored it to my own system, then it would know whatever I told it about that, and if I told it correctly, then it would know my cpu. I didn't actually compile my gcc -- it came with my distribution, and it knows I have an AMD 64-bit processor, but it doesn't know which one. I have to tell it, if I want optimal results.

I don't find any documentation of "-march=native" in "info gcc".

[Nullack]

Have a look on the web, native is the optimal setting when your compiled binaries dont need to be run on anything else than your machine.

[PGLGreg]

Have a look on the web, native is the optimal setting when your compiled binaries dont need to be run on anything else than your machine.

I did look. I learn that "-march=native" was introduced in gcc 4.2. I have only gcc 4.1.2 here, so it's no good to me personally, until I update. Still, very interesting.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448370

[Nullack]

Im on gcc 4.3.1 and have no problems with it. Mplayer now use mtune and march as native in mplayer / mencoder builds. Its super fast, much faster than VLC, Totem etcetc

[FakeOutdoorsman]

FFmpeg does not support "-threads auto" as an option anymore. If your command or script gives you the following error when using "-threads auto", then use "-threads 0" (the integer zero, not a letter) instead:

Expected number for threads but found: auto

I'm unsure when this change was introduced.

Update from S. Sabatini on ffmpeg-user mailing list:

-threads auto never worked as you expected, "auto" was previously parsed by atoi() which returned "0", now it omplains if it can't recognize the argument as a number.

[FakeOutdoorsman]

*edit3*
Yea, seems it is a rate control equation. Not knowing encoding at all, how important is this? If i use the command "ffmpeg -rc_eq" i get the same error, so im guessing that specific command is corrupted or something? I compared an older videos size to the newly "no rc_eq" encoded one, and they seem to be the same size and quality, though i have not tested on quicktime yet (thats a bit of a pain when you dont have windows heh).

Thoughts?

Looks like you found a bug in ffmpeg. I submitted this to the ffmpeg-user mailing list. You can follow it here:
rc_eq causes 'invalid pointer' error

And the resulting patch that should be applied to svn soon:
[PATCH] Fix the ffmpeg -rc_eq "foo" bug

Also, I will not have internet acces for a week, so I can't reply until then.

Update: This error has been fixed in today's SVN.

[maxbear]

I got one more question about ffmpeg on ubuntu. Just to see if there is anyone have any idea about this problem.

I am using a quad core (q9450) cpu. But ffmpeg only utilize 25% cpu usage. I already add "-threads 4" or even "-threads 8" in the command line. But I don't see any increase in speed.

I used to have over 200-250 fps in windows (320x240 video encoding). But I got only 100-150 fps in ubuntu (same video, same encoder setting.....).

[seagull man]

absolute gold. thanks for the howto.