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

[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
• ffms2 SVN-r320

x264 Builds:

• x264_x64_r1683M

• x264_x86_r1683M

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

[JEEB]

x264 r1683 64bit unpatched:
download ; hash

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

________________________________________________________________________________

x264 r1683 32bit
download

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

x264 r1683 64bit
download

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

patched with:

• mp4muxer.diff
• x264_fade_compensation_1629.patch
• x264_film_grain_optimization_1680.patch

After sorting out the problems with my encoding environment, here's something newer. After talking about FGO 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]

Originally Posted by 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.

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!

Originally Posted by 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.

[JEEB]

Originally Posted by elguaxo

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]

Originally Posted by 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.

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

[rack04]

Originally Posted by MasterNobody

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
• ffms2 SVN-r320

x264 Builds:

x264_x64_r1688M

x264_x86_r1688M

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
• x264_libavcore

x264_x86_r1688M_Filtering

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
• x264_libavcore
• x264_filtering

[Soichiro]

Originally Posted by 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.

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.


________
amber trichomes
________
Triumph Sprint ST

[JEEB]

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

config.log paste

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]

Originally Posted by kemuri-_9

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 ; hash

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

________________________________________________________________________________

x264 r1688 32bit
download

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

x264 r1688 64bit
download

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

patched with:

• mp4muxer.diff
• x264_fade_compensation_1629.patch
• 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
• FFMS2 r320 (FFmpeg git ~ of SVN-r24643 + Lagarith)
• LAVF "2010-01-30 17:52" + Lagarith + Ordered Chapters

  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]

Originally Posted by JEEB

...
patched with:

• mp4muxer.diff
• 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)?

[JEEB]

Originally Posted by laserfan

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

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]

Originally Posted by rack04

Toolchain:

• ffmpeg SVN-r24577 and libswscale SVN-r31859
• ffms2 SVN-r320

x264 Builds:

x264_x64_r1688M

x264_x86_r1688M

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
• x264_libavcore

x264_x86_r1688M_Filtering

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
• x264_libavcore
• x264_filtering

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