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

[iko417]

AQ Mode 2 is committed, any up-to date x264 build does have it. The same applies to MB Tree.

What about "mixaq", i have really good results with that, i like to encode with smaller bitrate and with mixaq i'm getting good picture.

Thanks for your reply.

[LoRd_MuldeR]

What about "mixaq", i have really good results with that, i like to encode with smaller bitrate and with mixaq i'm getting good picture.

Thanks for your reply.

Well, there was an unofficial "MixAQ" patch floating around. But it seems most people building x264 don't use it currently.

Also the only MixAQ patch I found by a quick search is for x264 r1240. So if somebody is still interested in this patch, he would need to update the patch for x264 r1292, I guess ;)

x264_MixAQ_r1240.diff (http://jeeb.pastebin.ca/1547858) -> Rejects (http://pastie.org/659399)

[VFR maniac]

MixAQ had been born in my idea, and I have been maintaining it now. (Main maintainer seraphy had dropped of supporting it now because he is busy.)
If you want to encode with MixAQ builds, download my x264_DANGEROUS builds.
They are available from here (http://www.esnips.com/web/x264dangerous).


x264_DANGEROUS is highly dangerous builds, because they are applied with many patches and my programming knowledge and skill is poor.
The builds includes fgo, thread_pool, nal-hrd(19), Japanese AQ(MixAQ and/or OreAQ) and timestamps control.

I think weak fgo + psy-rd keep constant grain well on Japanese Anime.

Timestamps control (http://www.esnips.com/doc/62941ca8-7eec-4cf3-9c33-0f50983a773e/x264_ts_ctrl_10_r1281) is available for direct VFR output.
This patch supports VFR VBV, but it is still incomplete because I don't understand ratecontrol algorithm sufficiently.
VBV underflows cause on 2pass encoding, especially when the frame rate bursts locally.
This patch also eliminates initial decoding delay for B-frames in MP4 container with DTS hacking.

[iko417]

Thank you both, VFR maniac & LoRd_MuldeR

[JEEB]

x264 r1294 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1294/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1294/x264.md5)

built on Oct 19 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

x264 r1294 32bit
download (http://jeeb.fiveforty.jp/x264/1294/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1294/relnotes.txt)

built on Oct 19 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


x264 r1294 64bit
download (http://jeeb.fiveforty.jp/x264/1294_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1294_x64/relnotes.txt)

built on Oct 19 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)


おもちうにょ～ん。

[techouse]

x264_x64_r1294_unpatched (http://techouse.project357.com/builds/revision1294/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1294/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1294_techouse (http://techouse.project357.com/builds/x264_x86_r1294_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1294_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1294_techouse (http://techouse.project357.com/builds/x264_x64_r1294_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1294_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)

[Dark Shikari]

Perfect timing, techouse! :p:p:p:p

[wyti]

speaking of updates : "Make B-pyramid spec-compliant"
is the second mode is fully compliant ? it's only blue-ray who use it's own rules and need more to be blue-ray compliant right ?

[Dark Shikari]

speaking of updates : "Make B-pyramid spec-compliant"
is the second mode is fully compliant ? it's only blue-ray who use it's own rules and need more to be blue-ray compliant right ?Correct.

[techouse]

x264_x64_r1301_unpatched (http://techouse.project357.com/builds/revision1301/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1301/x264.md5)
GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1301_techouse (http://techouse.project357.com/builds/x264_x86_r1301_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1301_techouse.txt)
GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1301_techouse (http://techouse.project357.com/builds/x264_x64_r1301_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1301_techouse.txt)
GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[rack04]

I get the following error when I try to fprofile:

http://i11.photobucket.com/albums/a199/rack04/x264.jpg

gcc.exe (GCC) 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1281.diff (http://jeeb.pastebin.ca/1601582)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[moviefan]

Concerning the new b-pyramid description in the GIT log, does it mean the 2nd method is not Blu-ray compliant?

[juGGaKNot]

Concerning the new b-pyramid description in the GIT log, does it mean the 2nd method is not Blu-ray compliant?

--b-pyramid strict: Strictly heirarchical pyramid
--b-pyramid normal: Non-strict (not Blu-ray compatible)

1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.

http://forum.doom9.org/showthread.php?t=108570&page=45 last post, 898.

[Kurtnoise]

Concerning the new b-pyramid description in the GIT log, does it mean the 2nd method is not Blu-ray compliant?
if you want BD compliancy, use --b-pyramid strict




edit: /me too slow

[moviefan]

Fine, thanks guys! Is the nal-hrd again incompatible to the latest revision?

[VFR maniac]

I get the following error when I try to fprofile:

Rename nal-hrd's i_dts. Please don't remove that.
B-pyramid implementation's i_dts is not equal to nal-hrd's.

[shon3i]

Ok how is now safe to use --b-pyramid strict with --ref 4 and --bframes 3 since every encoder (mc, elecard, ateme....) automaticly decrase number of ref's or bframes if some ilegal combination is set. For example allowed combinations in scenarist/cinevision are:

3 bframes + 3refs + pyramid = allowed
3 bframes + 4refs = allowed
2 bframes + 4refs + pyramid = allowed

3 bframes + 4refs + pyramid = not allowed ref decrased to 3.

Generaly same problem is been with old x264 pyramid. The question is that, did will x264 automaticly decrase or warn settings that make violation

[VFR maniac]

x264_x86_r1301_with_nal-hrd_16.rar (http://www.mediafire.com/download.php?iyhjod2e2dn)

gcc: 4.4.1-dw2 (TDM-2)
-march=core2

[akupenguin]

2 bframes + 4refs + pyramid = allowed
3 bframes + 4refs + pyramid = not allowed ref decrased to 3.
No. Number of b-frames doesn't affect DPB size.

[kemuri-_9]

GCC 4.4.2 released,
those using 4.4.1 should update when possible.

[moviefan]

No. Number of b-frames doesn't affect DPB size.

So 3 b-frames + 4 refs + b-pyramid strict should be fine for 1080p24 Blu-ray compliance?

[shon3i]

No. Number of b-frames doesn't affect DPB size.
My mistake, but original question stays: is 3 bframes + 4refs + pyramid (strict) allowed?, or can do violation as previous?

should be fine for 1080p24 Blu-ray compliance? Something still not smell good to me :) Anyway bpyramid strict can't incrase quality that much.

[jpsdr]

According a lot of things i've read, 4 ref without bpyramid, 3 ref with bpyramid.

[akupenguin]

is 3 bframes + 4refs + pyramid (strict) allowed?
Yes. --refs selects the DPB size, and individual frames just use as many refs as they can within that constraint.
(Except that pyramid forces the DPB to be at least 4, so if you select a smaller value of --refs it skips motion search on some of them, thus only using the specified number for inter prediction. Which means that "--b-pyramid strict --refs 4" is now the same as "--b-pyramid strict --refs 3", since both imply DPB=4 and strict pyramid with DPB=4 never has more than 3 refs available for any given frame. "--b-pyramid normal --refs 4" sometimes can use 4 refs, and thus is different from "--b-pyramid normal --refs 3" even though they have the same DPB.)

According a lot of things i've read, 4 ref without bpyramid, 3 ref with bpyramid.
A lot of things you've read were written before today's commit.

[shon3i]

"--b-pyramid strict --refs 4" is now the same as "--b-pyramid strict --refs 3"That is i want to hear. So basicly encoder decrase refs?

[JEEB]

x264 r1301 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1301/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1301/x264.md5)

built on Oct 19 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

x264 r1301 32bit
download (http://jeeb.fiveforty.jp/x264/1301/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1301/relnotes.txt)

built on Oct 19 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


x264 r1301 64bit
download (http://jeeb.fiveforty.jp/x264/1301_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1301_x64/relnotes.txt)

built on Oct 19 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Over 1300～なの

[rack04]

x264_x86_r1301M (LINK)

Built by rack04 on October 19, 2009, 4:14:04 PM CST
gcc.exe (GCC) 4.4.2 (x86.generic.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1301.diff (http://forum.doom9.org/showthread.php?p=1336048#post1336048)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[Alf Bundy]

Hi, what is the default now with the new b-pyramid spec-compliant ?

--b-pyramid / --b-pyramid normal / --b-pyramid strict / or not set by default ?


Sorry to ask, but I don't know (yet) how to use command line --longhelp.
I tried (in WinXP) Start -> Run -> "path to\x264.exe" --longhelp, but the command window only shows for a tenth of a second, and I'm too slow to hit "pause/break" in time. :(

x264.exe used : rack04's build just above (x264_x86_r1301M). Thanks

[bob0r]

Hi, what is the default now with the new b-pyramid spec-compliant ?

--b-pyramid / --b-pyramid normal / --b-pyramid strict / or not set by default ?


Sorry to ask, but I don't know (yet) how to use command line --longhelp.
I tried (in WinXP) Start -> Run -> "path to\x264.exe" --longhelp, but the command window only shows for a tenth of a second, and I'm too slow to hit "pause/break" in time. :(

x264.exe used : rack04's build just above (x264_x86_r1301M). Thanks

Start -> Run -> cmd -> cd "path to x264.exe" -> x264.exe --longhelp

[Alf Bundy]

Thanks bob0r, I will finally be able to encode without the help of GUI's. :)

And thanks to all of you being involved in x264 development. Great work !

[benwaggoner]

Start -> Run -> cmd -> cd "path to x264.exe" -> x264.exe --longhelp
And if you'd like to review it in your favorite text reader, just append ">x264_longhelp.txt" to the end of your command line to dump the --longhelp output into a .txt.

[Widok]

JEEB, techouse
Why you do not use x264_AQ2mod.diff? After all in a theme (http://forum.doom9.org/showthread.php?t=147067) more than positive responses.
You after all are not afraid of innovative decisions in a positive side influencing quality of a coded material?

[LoRd_MuldeR]

JEEB, techouse
Why you do not use x264_AQ2mod.diff? After all in a theme (http://forum.doom9.org/showthread.php?t=147067) more than positive responses.
You after all are not afraid of innovative decisions in a positive side influencing quality of a coded material?

If you refer to "AutoVAQ" (that is what was discussed in the theread (http://forum.doom9.org/showthread.php?t=147067) you link to), then the patch isn't used because its superflous ;)

AutoVAQ has been committed long ago and is available as "--aq-mode 2" in any unmodified build of x264.

[komisar]

LoRd_MuldeR, Widok refer to new variant of commited patch. In new version BugMaster add additional parameter to --aq-strength... AQ2mod patch (http://forum.doom9.org/showthread.php?p=1331855#post1331855)

[Dark Shikari]

x264 needs fewer psy options, not more. I refuse to commit any patch that increases the number of tweakable psy options unless extraordinary evidence is shown to me suggesting that it is useful.

If an feature needs user tweaking to make it useful, the feature is useless.

(On a related note, I have it on my agenda to eventually merge psy-trellis with psy-RD for this reason.)

[Widok]

komisar Thanks for specification.

LoRd_MuldeR
x264_AQ2mod.diff (Add second parameter for strength in AQ-modes
"#1:#2" where #1 - aq-strength; #2 - frame QP offset;
#2 >0.0 -- more 'loves' fades and dark frames (1.0 -- optimal).
Patch made by BugMaster)
--aq-mode 2 --aq-strength 1.0:1.0

[Dark Shikari]

Allocating more bits to dark frames should be controlled by qcomp, not by a second AQ parameter.

[komisar]

Dark Shikari, qcomp with mb-tree mean differ than without mb-tree

[Dark Shikari]

Dark Shikari, qcomp with mb-tree mean differ than without mb-treeThen x264 should compensate, not the user.

[komisar]

Dark Shikari :) if x264 could not compensate, maybe user try... moreover second aq-strength parameter can be omitted and remain the "standard" behavior...

[LoRd_MuldeR]

Dark Shikari :) if x264 could not compensate, maybe user try... moreover second aq-strength parameter can be omitted and remain the "standard" behavior...

Still the proper/desired solution would be to find out why the second parameter must be adjusted at all and how the optimal value depends on the video content. Then one could develop an algorithm that will do the required adjustment automatically...

[komisar]

LoRd_MuldeR, BugMaster may describe more correct this changes

P.S. small tests from www.x264.info (http://www.x264.info/2009-08/aq-mode-3/)

[Ulf]

Why doesn't --aud show up in --longhelp for the latest patched versions of x264? It's a part of "x264_hrd_pd_interlace.16_r1301.diff" as far as I have understood.

[kemuri-_9]

the help description for aud moved to --fullhelp with that revision that added the --fullhelp option.

[LoRd_MuldeR]

And it's not a part of the HRD patch. It's supported by unmodified x264 from GIT.

But if you are using x264 with the HRD patch, then you probably are targeting for BluRay and then you also need to enabled AUD (Access Unit Delimiters).

[burfadel]

I have to say, the AQ mod patch (setting aq-strength to 1.0:1.0) seems to work quite well. Perceptively it seems better, thats the main thing :) I'm guessing from what I've read on here though that it won't be committed though...

[menlvd]

I have to say, the AQ mod patch (setting aq-strength to 1.0:1.0) seems to work quite well. Perceptively it seems better, thats the main thing :) I'm guessing from what I've read on here though that it won't be committed though...

using that a long time. mine things same - quite well :)

[JEEB]

x264 r1309 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1309/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1309/x264.md5)

built on Oct 25 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

x264 r1309 32bit
download (http://jeeb.fiveforty.jp/x264/1309/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1309/relnotes.txt)

built on Oct 25 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


x264 r1309 64bit
download (http://jeeb.fiveforty.jp/x264/1309_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1309_x64/relnotes.txt)

built on Oct 25 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)
x264_hrd_pd_interlace.16_r1301.diff (http://www.mediafire.com/download.php?iyhjod2e2dn)


Patches seem ok by the log, let's see how it goes.

[rack04]

x264_x86_r1310M (http://www.mediafire.com/?sharekey=293e523b0b16a6678d78a0e555291609e04e75f6e8ebb871)

Built by rack04 on October 27, 2009, 9:22:27 AM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1301.diff (http://forum.doom9.org/showthread.php?p=1336048#post1336048)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[rack04]

x264_x86_r1318M (http://www.mediafire.com/?sharekey=63dbd186229a03b16b21be4093fab7ace04e75f6e8ebb871)

Built by rack04 on October 30, 2009, 9:15:04 AM CST
gcc.exe (GCC) 4.3.4 (x86.core2.Komisar)
--extra-cflags="-march=core2"
make fprofiled

Patched with:

x264_hrd_pd_interlace.16_r1301.diff (http://forum.doom9.org/showthread.php?p=1336048#post1336048)
x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)