Current Patches, Where to get them, How they affect speed/output

[Dark Shikari]

Thank you for the explanation. A test has just confirmed it when using Normal, the reported ref frames is as was set in the encoding options.

The reason why I used strict was because I wanted improved quality while trying to retain hardware compatibility for hardware media player playback. I have been researching different media players using chipsets such as those made by Realtek and Sigma Designs because I wanted to purchase one. I don't want to get one and find it won't playback my already/recently encoded files.Strict does not improve hardware compatibility, it just improves compatibility with the Blu-ray spec.

[burfadel]

It seems pretty common that for animation, or sources where there are lines that separate too flat surfaces, for people to raise the deblocking to 1:1

I know the deblocking filter is already automated somewhat and that adjusts the bias, my question relates to the deblocking in certain scenarios like that above. Is it possible for x264 to increase the strength and threshold of deblocking up to say 1:1 (or part thereof), when transitions between different flat surfaces is detected, such as in animation? This would be more beneficial for lower res animation, say 512x384 or 640x352. At higher resolutions the bias to be automatic scaled, such that at 720x576 it would be more like (for example) 0.6:0.6.

For high resolution images, have this scaled back to the point where there is a high resolution image the deblocking is at the default. I think this would be very beneficial if possible. The deblocking bias should only be applied to the relatively flat surfaces/shaded surfaces and the transitions between such surfaces, and not to higher detailed parts of the picture. Of course, the deblocking can still be changed for peoples preference.

Probably a stupid idea, but I'm guessing I'm not the only one that has thought of it...

[Dark Shikari]

It seems pretty common that for animation, or sources where there are lines that separate too flat surfaces, for people to raise the deblocking to 1:1

I know the deblocking filter is already automated somewhat and that adjusts the bias, my question relates to the deblocking in certain scenarios like that above. Is it possible for x264 to increase the strength and threshold of deblocking up to say 1:1 (or part thereof), when transitions between different flat surfaces is detected, such as in animation? This would be more beneficial for lower res animation, say 512x384 or 640x352. At higher resolutions the bias to be automatic scaled, such that at 720x576 it would be more like (for example) 0.6:0.6.

For high resolution images, have this scaled back to the point where there is a high resolution image the deblocking is at the default. I think this would be very beneficial if possible. The deblocking bias should only be applied to the relatively flat surfaces/shaded surfaces and the transitions between such surfaces, and not to higher detailed parts of the picture. Of course, the deblocking can still be changed for peoples preference.

Probably a stupid idea, but I'm guessing I'm not the only one that has thought of it...Deblocking can only be set per-slice. Trying to add enough slices to cover objects efficiently would hurt compression quite a bit.

[burfadel]

Ah ok! that explains it :)! I knew there would have to be a simple reason why its not done automatically!

How about using something like me-prepass to determine whether the consecutive frames are animation or film, and adjust deblocking based on that?

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24352 and libswscale SVN-r31758 (http://www.mediafire.com/?4d7gcu8gt74ppyi)
ffms2 SVN-r320 (http://www.mediafire.com/?d1wark634cg0yod)
x264 Builds:

x264_x64_r1680M (http://www.mediafire.com/?qb609r42rc2q52i)
x264_x86_r1680M (http://www.mediafire.com/?dgk2400dxtxw8l8)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (LINK)

[ckmox]

anyone help please im getting this error

ffms [error]: could not create index
lavf [error]: could not open input file
raw [error]: raw input requires a resolution.
x264 [error]: could not open input file `o.mkv' via any method!


my commandline
x264 --preset slow --tune animation --crf 27 --vf resize:704,400 -o "i.mkv" "o.mkv"

im on Windows XP SP3 32-bit

[nm]

my commandline
x264 --preset slow --tune animation --crf 27 --vf resize:704,400 -o "i.mkv" "o.mkv"

Looks like you have i.mkv and o.mkv reversed in that command line, if i=input and o=output.

[ckmox]

Looks like you have i.mkv and o.mkv reversed in that command line, if i=input and o=output.

haha ye thats it silly me thanks a lot

[Snowknight26]

And hopefully it doesn't really say
x264 [error]: could not open input file `o.mkv' via any method!
Who uses grave accents in place of apostrophes?

[Midzuki]

And hopefully it doesn't really say
x264 [error]: could not open input file `o.mkv' via any method!
Who uses grave accents in place of apostrophes?

Looks like a "bad habit" that was born in the "7-bit age". :)

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24429 and libswscale SVN-r31767 (http://www.mediafire.com/?rdj7obkdvmtdo3i)
ffms2 SVN-r320 (http://www.mediafire.com/?99072bq150nnmk1)
x264 Builds:

x264_x64_r1683M (http://www.mediafire.com/?ah46kc955lckb3w)
x264_x86_r1683M (http://www.mediafire.com/?er1hcnlyabg8tlk)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/4tB1dw26)

[JEEB]

x264 r1683 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1683/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1683/x264.md5)

built on Jul 22 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1683 32bit
download (http://x264.fushizen.eu/files/1683/x264_1683_32.7z)

built on Jul 22 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1683 64bit
download (http://x264.fushizen.eu/files/1683_64/x264_1683_64.7z)

built on Jul 22 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)


After sorting out the problems with my encoding environment, here's something newer. After talking about FGO (http://x264dev.multimedia.cx/?p=25) with VFR Maniac, I decided to take it in. Currently using --psy-rd 0.8:0.4 --fgo 2 and got pretty good results.

[Soichiro]

I don't get it. I thought the whole point of Psy-RD and Psy-Trellis was to optimize for film grain in a way that wouldn't also destroy videos that lack grain. I also thought that was why builds with FGO were discontinued 1-2 years ago and why FGO never made it into the git. Correct me if I'm wrong though.

[JEEB]

I don't get it. I thought the whole point of Psy-RD and Psy-Trellis was to optimize for film grain in a way that wouldn't also destroy videos that lack grain. I also thought that was why builds with FGO were discontinued 1-2 years ago and why FGO never made it into the git. Correct me if I'm wrong though.

They are quite different tools and concepts, I would say (and thus do not cover each other off). Not to mention that FGO by itself, as you say, is nothing new. The main reason I took it into my own builds was because VFR Maniac commented to me that "it was/is a way of retaining some grain/noise while still not breaking the image with relatively low bitrates, unlike psy-rd and psy-trellis." I must say, I was interested.

And because I saw that it was extra something that might be useful, and, even if used, doesn't really break anything as long as you don't overdo it (high FGO and Psy-RD/-Trellis together seem like something you wouldn't want to use), I decided upon adding the properly updated patch to my builds. VFR Maniac and BakaPop have kept this patch up-to-date and 64bit-compatible (and their own builds of course contain this patch).

[elguaxo]

Sounds interesting, thanks JEEB!

Currently using --psy-rd 0.8:0.4 --fgo 2 and got pretty good results.

Just to know where to start my tests. I'll try it at a medium/low bitrate. Is that suggestion above for film or animation.

:thanks:

[JEEB]

Is that suggestion above for film or animation.
I mostly encode animation recently, which leads to most of my settings being closer to animation than live action. I guess I could've mentioned this in the post itself.

Anyways, since --fgo 5 is "weak", --fgo 2 is even weaker. This was mainly a precaution because I was trying it on an encode that I would rather like to come up nice the first time. Although I did up it from the recommendation of 1 that came from VFR Maniac ;) .

[elguaxo]

Ok! Thanks for the quick replay. :)

[rack04]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.

[MasterNobody]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.
Probably this is libavcore dependence. Try with this patch: http://pastebin.org/428030

[rack04]

Probably this is libavcore dependence. Try with this patch: http://pastebin.org/428030

That fixes it. Thanks.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24577 and libswscale SVN-r31859 (http://www.mediafire.com/?i06g5a4ko628655)
ffms2 SVN-r320 (http://www.mediafire.com/?ayqcvcqkfmj3dcu)
x264 Builds:

x264_x64_r1688M (http://www.mediafire.com/?boo762he0q0hozm)

x264_x86_r1688M (http://www.mediafire.com/?tn626hv2vgd4gll)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)

[Soichiro]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.

In msys/mingw32? Mine does this sometimes too, and I don't understand why. If I just rerun the configure script again, though, it usually detects everything properly. It's weird...

[pistacho]

@ rack04

Thank you very much by the build with filters. I've tested and works perfect :)

The command line is:
x264.exe --bitrate 5000 --preset medium --tune
film --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --fps "2
4000/1001" --force-cfr --keyint 24 --b-pyramid strict --open-gop bluray --bframe
s 3 --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709
" --sar 1:1 --vf "pad:,,,,1920,1080" --pass 2 -o "T:\TEMP\El_negociador.264" "E:
\TEST\El Negociador-006.mkv"
ffms [info]: 1920x800p 1:1 @ 24000/1001 fps (cfr)
pad [info]: expanding frame to 1920x1080, picture starting at (0,140)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 4.1
[20.6%] 633/3078 frames, 8.10 fps, 5119.04 kb/s, eta 0:05:01

Input: a 2.40:1 AR MKV (1920x800)
Ouput: 16:9 AR (1920x1080) AVCHD/Blu-Ray compilancy

I think this function is very useful to encode for Blu-ray when the source is not 16:9. (requires add borders).

I will add it to my application when I have more tested. I hope that soon could be included in x264 official releases.

:thanks:
________
amber trichomes (http://trichomes.org)
________
Triumph Sprint ST (http://www.cyclechaos.com/wiki/Triumph_Sprint_ST)

[JEEB]

Anyone else having trouble when building 64bit builds with pkg-config with lavf/ffms?

config.log paste (http://privatepaste.com/2f1472a7e9)

ffmpeg and ffmpegsource seem to build fine with the correct prefixes and all (like earlier) together with 32bit x264, but 64bit x264 seems to fail like this.

used command lines (have used them for quite some time now on my buildscript):
ffmpeg
./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-postproc --enable-filters --disable-network --disable-encoders --extra-cflags='-U__STRICT_ANSI__' --enable-runtime-cpudetect --enable-pthreads

ffmpegsource
PKG_CONFIG_PATH=/mingw/x86_64-pc-mingw32/lib/pkgconfig/ ./configure --host=x86_64-pc-mingw32 --prefix=/mingw/x86_64-pc-mingw32

x264
PKG_CONFIG_PATH=/mingw/x86_64-pc-mingw32/lib/pkgconfig/ ./configure --cross-prefix=x86_64-pc-mingw32- --host=x86_64-pc-mingw32

[kemuri-_9]

does adding --extra-ldflags=-lavcore to x264's ./configure fix the issue?

[JEEB]

does adding --extra-ldflags=-lavcore to x264's ./configure fix the issue?

Aand yes, it did. I wonder why pkg-config doesn't handle that, though. I wonder if it's my damn system or something else :|

x264 r1688 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1688/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1688/x264.md5)

built on Jul 31 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1688 32bit
download (http://x264.fushizen.eu/files/1688/x264_1688_32.7z)

built on Jul 31 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1688 64bit
download (http://x264.fushizen.eu/files/1688_64/x264_1688_64.7z)

built on Jul 31 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)

[qyot27]

x264_r1688-allbits.7z

Flags:
--extra-cflags="-march=pentium3"

Contains:
x264 r1688 (8-, 9-, and 10-bit)
FFmpeg git ~ of SVN-r24652 + Lagarith decoder (http://repo.or.cz/w/FFMpeg-mirror/lagarith.git)
FFMS2 r320 (FFmpeg git ~ of SVN-r24643 + Lagarith)
LAVF "2010-01-30 17:52" + Lagarith + Ordered Chapters (http://repo.or.cz/w/FFMpeg-mirror/ordered_chapters.git)
git checkout `git rev-list -n 1 --before="2010-01-30 17:52" master`
Notes:
No patching outside of the branch mergings. I forgot to use L-SMASH this time, so it's still using GPAC.

Cross-compiled on Ubuntu 10.04 using mingw-x (supposedly, gcc 4.4.5 prerelease; I somehow doubt this but lack any way of proving it).

All of the above are 32-bit. I don't have access to 64-bit Windows at all.

The disparity between the FFmpeg used for FFMS2 and the fully-built one is due to how ancient my computer is (i.e. it takes upwards of a half hour to compile FFmpeg at any stage; see also the -march used...I'm on a Coppermine-based Celeron), and an initial lack of Internet connection.

As the stats say, the LAVF these builds use is six months out-of-date. Newer versions of FFmpeg break the Ordered Chapters branch in a way I haven't a clue how to fix using Meld.

The Lagarith support is, well, a little spotty. Only YV12 files, and seems to have problems with fades.

[laserfan]

...
patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)...
I can't seem to find any information on the usage of the fade compensation patch. Can anyone direct me to a site/thread where ppl talk about settings, sources, results etc?

Or maybe the folks who use it include a specific setting for every one of their encodings without tweaking (if yes, what setting would that be)? :confused:

[JEEB]

I can't seem to find any information on the usage of the fade compensation patch. Can anyone direct me to a site/thread where ppl talk about settings, sources, results etc?

Or maybe the folks who use it include a specific setting for every one of their encodings without tweaking (if yes, what setting would that be)? :confused:

There was some talk about it on doom10 and on IRC. Most people I see use it with settings around the 0.6-0.8 range, which is normally rather effective. Of course, if x264 doesn't find the fade a fade, nothing can really be done about that.

[moosekaka]

Toolchain:

ffmpeg SVN-r24577 and libswscale SVN-r31859 (http://www.mediafire.com/?i06g5a4ko628655)
ffms2 SVN-r320 (http://www.mediafire.com/?ayqcvcqkfmj3dcu)
x264 Builds:

x264_x64_r1688M (http://www.mediafire.com/?boo762he0q0hozm)

x264_x86_r1688M (http://www.mediafire.com/?tn626hv2vgd4gll)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)


hi, is the pad filtering patch available on 64bit x264 build? or is it somehow difficult to implement on 64 bit? thanks

[detmek]

x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)

Hi. I tried using this build but I get this warrning:

ffms [info]: 720x304p 1:1 @ 24/1 fps (vfr)
pad [info]: expanding frame to 720x480, picture starting at (0,88)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile Baseline, level 3.0
x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
x264 [warning]: 3015 suppressed nonmonotonic pts warnings

x264 [info]: frame I:13 Avg QP:17.54 size: 19819
x264 [info]: frame P:3006 Avg QP:19.32 size: 5262
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 8.4% 0.0% 0.0% P16..4: 28.3% 0.0% 0.0% 0.0% 0.0% skip:63.3%
x264 [info]: coded y,uvDC,uvAC intra: 23.0% 35.5% 11.9% inter: 15.2% 14.1% 2.4%
x264 [info]: i16 v,h,dc,p: 45% 28% 14% 13%
x264 [info]: i8c dc,h,v,p: 52% 25% 14% 8%
x264 [info]: kb/s:1022.40

encoded 3019 frames, 72.20 fps, 1022.44 kb/s


Command line is --vf pad:0,88,0,88/ --preset ultrafast -o testpad.mp4 D3.avi

D3.avi is:
General
Complete name : C:\ft\D3.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 151 MiB
Duration : 2mn 5s
Overall bit rate : 10.1 Mbps
Writing library : VirtualDub build 32817/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : H264
Duration : 2mn 5s
Bit rate : 10.1 Mbps
Width : 720 pixels
Height : 304 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 1.921
Stream size : 151 MiB (100%)
Writing library : x264 core 102 r1666bm d058f37
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=4 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

I found some posts but those are about resize filter problem, but my OS is WinXP Pro SP3 32-bit and I don't use Avisynth, as x264 log shows. Same problem with --preset medium. I did not have problems with resize filter, only with padding.

Tested again. No warrnings if I add --force-cfr to command line. VFR is the problem, I think.

[rack04]

hi, is the pad filtering patch available on 64bit x264 build? or is it somehow difficult to implement on 64 bit? thanks

No it is not available.

[JEEB]

And another update to my build script (http://x264.fushizen.eu/files/buildx264.sh), L-SMASH straight from the git repo :3

Yes, it looks ugly and very much like a hack, but works and seems to be the official way to install git L-SMASH at the moment. If anyone has a better version, please do share <3.

x264 r1698 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1698/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1698/x264.md5)

built on Aug 16 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1698 32bit
download (http://x264.fushizen.eu/files/1698/x264_1698_32.7z)

built on Aug 16 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1698 64bit
download (http://x264.fushizen.eu/files/1698/x264_1698_64.7z)

built on Aug 16 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

0001-Fix-compilation-to-support-L-SMASH.patch (http://up-cat.net/L-SMASH/0001-Fix-compilation-to-support-L-SMASH.patch)
Adding the whole L-SMASH git repo (http://repo.or.cz/w/L-SMASH.git) (revision 2d99fcd) into /output and then rewriting the x264 mp4.c with the one for L-SMASH.
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)


Flabbergasted and not really getting what I did? Read the build script, it should be more understandable ^^;. Seems to be working, though.

[julius666]

JEEB: Could you upload the files (the compiled binaries at least) to a file-sharing site like mediafire? For some reason I can't reach your webpage from Hungary just through a proxy. :(

[mariush]

I've put them here on the mplayer's mirror i host:

http://mplayer.savedonthe.net/x264/x264_r1698_64bit_unpatched.exe
http://mplayer.savedonthe.net/x264/x264_1698_32.7z
http://mplayer.savedonthe.net/x264/x264_1698_64.7z

... in the order they appear in the post

[julius666]

Thank you, that works :)

[rack04]

Toolchain:
GCC Version 4.5.1 Experimental Release SVN rev. 162774, 2010.07.31
Pthreads 2.9.0.0 Static
Yasm 1.1.0 r2361
LAVF/FFMS Build:

ffmpeg SVN-r24819 and libswscale SVN-r31971 (http://www.mediafire.com/?36b9y9ic4o9m8se)
ffms2 SVN-r325 (http://www.mediafire.com/?x0268x5cxw6sf4o)
x264 Build:

x264_x86_r1698M (http://www.mediafire.com/?idgw2sziatdh1it)
Platform: X86
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
audio: yes (raw)
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)

[qyot27]

x264_r1698-allbits.7z

x264=r1698 [8-, 9-, and 10-bit]
FFMS2=r325
FFmpeg=r24829

Patches:
http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff

Flags:
-march=pentium3

Cross-compiled on Ubuntu 10.04, GCC 4.4.5 prerelease (again, something I doubt but can't verify)
AAC encoding requires Quicktime to be installed. The version shipped with iTunes is sufficient, although I assume you need Quicktime 7.3 or higher; if you can use iTunes to access the Store, chances are it's a right version of Quicktime.

[RainyDog]

x264 0.100.1659 x86 & x64 (http://www.mediafire.com/?yi3dmkmqniw)

gcc 4.5.1 20100623 prerelease
ffmpeg svn 23787
swscale svn 31559
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.100.1659 amdfam10,fprofiled,LTO

Outlaw, will you be doing anymore of your amdfam builds? Cheers.

[qyot27]

With all the talk about licensing going on elsewhere in this section, I've made the decision to drop the builds I've made. Instead, I'll post the steps I took for the audio encoding one in the meanwhile (since the LAGS+OC build was a pain in the neck to get working right, and I'd have to constantly recheck the steps involved):

1. Sign up for a free account on Apple Developer Connection (sadly, there's no way around this part) and download the Quicktime 7.3 SDK for Windows (http://developer.apple.com/quicktime/download/).

2. Install the SDK normally.

3. Copy the contents of C:\Program Files\Quicktime SDK to a directory on msys' root called /qtsdk. Alternately, you could just install to said location right away, but you need to remember to rename the directory so there aren't any spaces in the path name.

4. When configuring x264, use --qtsdk=/qtsdk. It should recognize it and under Audio should respond with yes (raw, qtaac, qtaac_he).

4a. Cross-compiling on Linux is possible, but requires the .lib files in /qtsdk/Libraries to be renamed/copied/symlinked to have upper-case (.LIB, not .lib) extensions - case sensitivity causes configure to fail otherwise. Windows doesn't have this problem.

[bob0r]

You should not be scared by the money makers.
If it wasn't for "us" xvid and x264 would never grown so popular. We did all the hard work, and now companies make money of it.
If you are afraid of hosting stuff, you can always host it on x264.nl.

[qyot27]

Well, at least in my own case, those two builds were mainly for esoteric features/purposes, and my ability to churn them out with regularity was already a problem because of how old my comp is. The tide of progress on all the parts inside them would have made it a moot point in relatively short order anyhow. It already somewhat did to the r1688 build with Lagarith and Ordered Chapters. The Quicktime stuff is a regular part of the L-SMASH patch now, it's just a matter of whether one chooses to supplement said patch with AAC encoding or not by downloading the SDK from Apple.

It would be far more convenient for me to document what I did to get there, because this flare-up still points out that source code is apparently different from binaries; I'm comfortable with being told what to do with source code, or to rely on existing pipelines to get a hold of things, I've just re-evaluated whether I myself want to or have the time/ability to be part of said pipelines. Binaries may be more convenient for an average user without knowledge of compiling software, but the methodology to get different results is more valuable to those that feel confident with compiling it themselves - not to mention most of them would get through the process faster than I could simply due to better underlying hardware. Waiting 1h45m-2h or so just for a complete cycle of ffmpeg->ffms2->x264->ffmpeg is getting to be too much for me anyhow. That should seriously take me a half hour (or less!), not 3-4x that. Discounting, of course, any extra time racked up due to stuff causing builds to fail mid-way through and start the process over again trying to troubleshoot it.

[jpsdr]

@rack04 : Do you intend to make a 32/64 bit with fade_compensation patch of the last version ?

[easyfab]

Can someone make a build for LAVF/ffmpeg SVN but with all audio codec enable ( aac,lame,vorbis ... ) because I want to try to build "x264 audio" and I don't know how to build ffmpeg correctly under mingw/msys. ( A guide for ffmpeg under mingw/msys can also be good)

[lucassp]

I'm also looking for a recent Mac build of x264 with ffms/lavf. Or at least a build tutorial. Thanks :)

[qyot27]

I'm also looking for a recent Mac build of x264 with ffms/lavf. Or at least a build tutorial. Thanks :)
For OSX,
A) install Xcode - it's on the OSX install disc or through Apple Developer Connection.
B) Install MacPorts (by following Parts 1 & 2 from http://davidbaumgold.com/tutorials/wine-mac/ - although if you want to go on to install wine feel free to).
C) Use MacPorts to install subversion, git-core, yasm, nasm, texi2html, automake, autoconf, libtool, pkg-config (might already be installed through Xcode...I can never seem to remember this), and I think that's it.



svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffms2
git clone git://git.videolan.org/x264.git

cd ffmpeg
./configure --prefix=$HOME/ffms2_build --enable-gpl --enable-version3 --enable-postproc --disable-encoders \
--disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
--extra-cflags="-march=pentium3"
make
make install

cd ../ffms2
./configure --prefix=$HOME/ffms2_build PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig
make
make install

cd ../x264
wget http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff
patch -p1 < mp4muxer.diff
PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --extra-cflags="-march=pentium3"
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-9bit \
--extra-cflags="-march=pentium3" --bit-depth=9
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-10bit \
--extra-cflags="-march=pentium3" --bit-depth=10
make
make install



All -march=pentium3 parts should be changed to the processor you actually have; refer to GCC's documentation for that list (http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html)...-march=native could also be used if you'd rather not take the time to target your cpu explicitly and let GCC autodetect it.

The MSYS/MinGW instructions are pretty much identical to those - the only place they differ are that ffmpeg requires two additional options: --enable-memalign-hack and -U__STRICT_ANSI__ needs to be added to the cflags, like --extra-cflags"-U__STRICT_ANSI__ -march=pentium3".

EDIT: I forgot...I have read reports that ffmpeg won't build under Snow Leopard unless --disable-asm and --arch=x86_64 are also given. I'm not entirely sure because I can't remember if I've ever built without those options, so be aware of that as well.

[jpsdr]

@jeeb : I've tested your x64 patched 1703 version, with the following command line :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET CHAPTERS=%6%5
SET STAT_FILE=%6%1.stats
SET TUNING=%4
SET LOG_FILE_1=%6%1_log_1.txt
SET LOG_FILE_2=%6%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%


My avisynth script is only AVISource("File.avi"), where avi is Lagarith YV12 without audio.
2 problems :
- It displays avs errors about audio... First time i'm having this kind of message, specialy when output is raw h264...
- It never finish the 1st pass... Process is some kind of locked, i've one thread (ie one CPU) at 100%, log of 1st pass seems completed, but still used/locked by the process, and there is no log of 2nd pass, which mean 2nd pass is not starting.
Reproductible at 100%, even with a small file of few frames.

[livetolove92]

This is my settings
x264.exe --profile high --level 4.1 --pass 1 --preset veryslow --bitrate 1900 --stats ".stats" --min-keyint 24 --thread-input --threads 6 --deblock -3:-3 --deadzone-inter 21 --deadzone-intra 11 --qcomp 0.6 --bframes 4 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --keyint 250 --ref 6 --rc-lookahead 00 --aq-mode 1 --aq-strength 0.7 --merange 24 --me umh --subme 7 --no-dct-decimate --mixed-refs --partitions all --trellis 2 --psy-rd 0.8:0.1 --ipratio 1.4 --pbratio 1.3 --no-fast-pskip --output NUL "F:\Worker\x.avs"

x264.exe --profile high --level 4.1 --pass 2 --preset veryslow --bitrate 1900 --stats ".stats" --min-keyint 24 --thread-input --threads 6 --deblock -3:-3 --deadzone-inter 21 --deadzone-intra 11 --qcomp 0.6 --bframes 4 --direct auto --b-bias 0 --scenecut 40 --keyint 250 --ref 6 --rc-lookahead 00 --aq-mode 1 --aq-strength 0.7 --merange 24 --me umh --subme 7 --no-dct-decimate --mixed-refs --partitions all --trellis 2 --psy-rd 0.8:0.1 --ipratio 1.4 --pbratio 1.3 --no-fast-pskip --output "x.mkv" "F:\Worker\x.avs" 2>log.txt
And this my avs
LoadCPlugin("F:\Encode software\megui-core_0_3_4_15_x64\tools\ffms\ffms2.dll")
ffmpegsource2("H:\US\X.mkv")
Spline36Resize(960,406) # Spline36 (Neutral)

This my log
avs [info]: 960x406p 0:0 @ 24000/1001 fps (cfr)
x264 [warning]: lookaheadless mb-tree requires intra refresh or infinite keyint
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [error]: ratecontrol_init: can't open stats file
x264 [error]: x264_encoder_open failed

I use the latest x264, ffms2, megui, avisynth for x64.
I can't create the .stats file. x264 crash immediately when i run the bat.

[jpsdr]

@jeeb
I've tested your x64 1713 patched build, still the same issue i've described in post #3397 (http://forum.doom9.org/showthread.php?p=1431557#post1431557)

[kemuri-_9]

@jeeb
I've tested your x64 1713 patched build, still the same issue i've described in post #3397 (http://forum.doom9.org/showthread.php?p=1431557#post1431557)

have you even tried the unpatched x64 build to see if it also exhibits the issues?
iirc JEEB is using the still-being-developed audio support patch which would explain the audio warning...