Compiling x264 on Linux

[Qyot27]

When you commit changes (i.e. apply patches), that change is recorded. A series of changes is a git history.

A good git tutorial is here: http://www.kernel.org/pub/software/scm/ ... orial.html

I suppose this means that different versions of the same patch are treated similarly? For instance, the HRD/Pulldown patch was recently updated from 10 to 11, apparently from a major re-write. Or would that require removing the previous version first and then applying the new version?

Thanks for the link to the tutorial. I'll make sure to read through that since beyond the really basic act of retrieving the data, I have next-to-zero experience with git (or other revision control systems, for that matter).

If it's color errors like swapped U and V channels, you can throw swapuv in the filter chain. That usually does it for me, anyway.

I'm pretty sure it is swapped channels - things start looking blue and orange when they definitely shouldn't. I think the reversed channels are the only thing that really differentiates I420 from YV12 (aside from I420 actually using 4:2:0 in its name).

How did you isolate the cflags changes from every other factor? (Are you absolutely sure it was compiler optimizations making the difference?)

What else could it be? Everything else was exactly the same, as far as I can remember - same video file in the same method of input (either raw or through piping, as I did separate tests on those), same options, same revision of x264 - I didn't include the patches because at that point I'd not found the information to use them yet. Nothing else was running, except maybe Nautilus and gedit (far more likely to still have gedit open than both it and Nautilus, though). But I usually close all other programs when encoding, no matter what OS I'm using.

I'll probably go and re-run all those tests again so I can get a more definite picture, though.

While you might get a small performance boost out of tweaking compiler flags, overly-aggressive optimization can cause also subtle bugs in program behavior. The default compiler flags are best unless you're sure you know what you're doing.

I chose to include the optimization because of the general trend on the Current Patches thread for the custom builds there to have them (including Skystrife's builds that are included in MeGUI's update chain, which are -march=pentium2).

[Qyot27]

Ok, well, I'm going to eat my words a little bit now. I re-ran tests to determine the speed differences between a CFLAGS-enabled build and one without. The results are posted below.

Source video: scrotal.avi / scrotal.i420
AVI:

Code: Select all

mkfifo scrotal.y4m
x264 --crf 18.0 --progress --output "scrotal-avi.mp4" "scrotal.y4m" | mplayer -nosound -vo yuv4mpeg:file=scrotal.y4m scrotal.avi

RAW:

Code: Select all

x264 --crf 18.0 --progress --output "scrotal-raw.mp4" "scrotal.i420" 848x480 --fps 23.976

x264-r1136M, Apr 6 2009, gcc 4.3.2
x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.11_interlace.diff

Stats for "-march=pentium3" build:
AVI: 2.77fps
RAW: 2.91fps

Stats for non-CFLAGS build:
AVI: 2.86fps
RAW: 3.09fps

Values were the final reported average fps. The AVI file was compressed with ffvhuff, 95 frames long, and contained mostly static imagery. It would probably be good to run a subsequent test with a high-motion, much longer source, but I needed something quick for right now.

The only thing open was the Terminal. Nautilus, gedit, etc. were all closed at the time.

Also, trying to use git-am for the win_zone_parse_fix and hrd_pulldown patches failed with warnings about not having email/mailbox information or whatever. Those patches didn't come from the mailing list (or at least, the copies I have of them didn't come from the mailing list - I downloaded them straight from Skystrife's host server and the attachments on the Doom9 patches thread, respectively). Is there some other set of options needed to make git-am work on those patches? Because it seems - and I somewhat expected it, considering the description of git-am in the first place - that it'll only accept patches that adhere to its formatting standards, otherwise you're SOL. Which means you'd need to either know where the patches came from to ensure that they do meet said requirements, or that you know how to correct the patches to that standard yourself.