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

[wyti]

Can anyone compile a patch with me-prepass ? Or the patch is actually borked ?

[Sagittaire]

Can anyone compile a patch with me-prepass ? Or the patch is actually borked ?

from the author of pre-pass ...

ME-prepass is just a simple ugly hack to do tons of hex searches. Its not particularly pretty or efficient

Use most available patch doesn't mean always better quality!

[wyti]

True but.
Dark Shikari isn't the author of pre-pass

And I ask this because I tried it, and I use it with a lot of my encodes (I usually encore small clips of 2-3 minutes) and it give me better results than --me esa.

[Sharktooth]

dark shikari IS the author... iirc death the sheep just kept it up to date.

[wyti]

Thanks for the explanation, but what about this patch itself, is it borked, or no one want to use it ?

[Dark Shikari]

Thanks for the explanation, but what about this patch itself, is it borked, or no one want to use it ?I'm too lazy to keep it updated with all the changes I've been making to me.c, I never figured out entirely why it worked at all, and people these days aren't exactly demanding more "lots of time for very little quality boost" improvements anyways.

[wyti]

Ok thanks, but i think that with the good speed boost, we can introduce some quality boost too.

if I understand, the patch isn't dead, but someone have to maintain it ?

[techouse]

A high --merange and --me esa or tesa would probably give you the same results.

[wyti]

Yes but with pre-pass i got about 1.5fps, that was not bad for a 3minutes long clip. But with esa, it is significantly slower, i don't remember the exact numbers, but around 0.8-0.9 fps, with a very slighly better result...
for me umh + prepass was very good.

Now i have to learn how to maintain me-pre-pass patch :p

[techouse]

It's quite nasty cause the problem is in the encoder/me.c section which is very SENSITIVE. Good luck.

[bob0r]

x264.886.modified.01.exe (http://files.x264.nl/x264.886.modified.01.exe)
x264.886.modified.01.source.zip (http://files.x264.nl/x264.886.modified.01.source.zip)

x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.886.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.886.modified.01.fprofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[IgorC]

sorry for offtopic
A high --merange and --me esa or tesa would probably give you the same results.
Could somebody show a clear sample where --merange > 16 and --me (t)esa would be helpfull? Really.
I tested some videos and never have seen where is it so usefull (at all?).

And --me-prepass was more efficient than tesa and merange some time ago.
http://forum.doom9.org/showthread.php?p=1054774

[Sagittaire]

sorry for offtopic

Could somebody show a clear sample where --merange > 16 and --me (t)esa would be helpfull? Really.
I tested some videos and never have seen where is it so usefull (at all?).

And --me-prepass was more efficient than tesa and merange some time ago.
http://forum.doom9.org/showthread.php?p=1054774

Well I make a little test with 10 000 frame from Casino Royal (1080p24 at crf 22) and tesa + merange 32 produce something like 1% improvement (lower bitrate and higher metric).

[IgorC]

Thanks for throw some numbers. I expected practically the same.
But I think it's correct to keep insane settings (tesa, merange). This way user know the limits of encoder and there is no paranoid thoughts about if it's possible to squeeze the last .% of quality when it's necessary.

[skystrife]

x264.889.modified.exe (http://www.mediafire.com/?gymumhj1fnc) - Source (http://www.mediafire.com/?jmmucyhy9mb)
(alt download link) (http://www.sendspace.com/file/atdvmv)

Patches:
x264.psyRDO.0.22.diff
x264_hrd_pulldown.04_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build

Built in mingw on Windows Vista x64.

Enjoy.

[kemuri-_9]

Hmm.... I think i developed a small patch that relaxes the qpfile to be able to only specify certain frames of the video (i believe this was mentioned as a feature request somewhere)
http://kemuri9.net/dev/x264/x264_qpfile_relax.diff
(based on r889)

if someone else can confirm this for me that would be great

Edit:
Just changed it up a little to increase efficiency on reading the qpfile for only specifying certain frames

[MythCreator]

x264.modified.r891.exe (http://www.fs2you.com/files/20b87597-4268-11dd-a40a-0014221f4662/)
Source (http://www.fs2you.com/files/ae42fa5c-4269-11dd-a410-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364


x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[jethro]

Hmm.... I think i developed a small patch that relaxes the qpfile to be able to only specify certain frames of the video (i believe this was mentioned as a feature request somewhere)
http://kemuri9.net/dev/x264_qpfile_relax.diff
(based on r889)

if someone else can confirm this for me that would be great

Edit:
Just changed it up a little to increase efficiency on reading the qpfile for only specifying certain frames
You mean the feature request in this thread?
http://forum.doom9.org/showthread.php?t=120449

So with your patched qpfile we may e.g., force key frames at specific frames?

[kemuri-_9]

You mean the feature request in this thread?
http://forum.doom9.org/showthread.php?t=120449

Ah yes, there was that thread where I read that.

So with your patched qpfile we may e.g., force key frames at specific frames?

yes, that's how I've been testing it so far and confirming its success in the stats file.

qpfile (entire file)
99 I 35
100 I 30

stats
...
in:99 out:99 type:I q:35.00 itex:326 ptex:0 mv:308 misc:326 imb:1350 pmb:0 smb:0 d:-;
in:100 out:100 type:I q:30.00 itex:224 ptex:0 mv:418 misc:318 imb:1350 pmb:0 smb:0 d:-;
...

I did back-to-back keyframes in an attempt to see if it can override the min-keyint parameter and it does.

The qp for the frame is still mandatory, but that's not too big of a deal in my opinion

[akupenguin]

btw, relaxing (qp < 0) to (qp < -1) will let you specify some frames as qp=-1 meaning auto.
It's a bad idea to mix a few auto frames into a lot of forced ones, but the other way around should work.

[kemuri-_9]

thanks for the tips, I updated the patch file to allow for -1 qp and confirmed it working!

btw, is there any chance of having this put into the git for standard usage?

[Razorholt]

Can someone please compile another modified version with this patch from MasterNobody: http://forum.doom9.org/showthread.php?p=1151782#post1151782

Thanks,
- Dan

[MythCreator]

x264.891.modified.2.exe (http://www.fs2you.com/files/9eee3fa8-435e-11dd-9653-001143e7b41c/)


General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff(fixed)
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[Razorholt]

Thanks MythCreator!

[LoRd_MuldeR]

What revision are we at now? The latest log entry on git says:

commit 2ca45934d79a62c1c04771c98eb3ee1d119cdd7a

Move bitstream end check to macroblock level
Additionally, instead of silently truncating the frame upon reaching the end of the buffer, reallocate a larger buffer instead.

That is identical with the latest entry in the changelog on x264.nl, but the revision number there says 890 instead of 891 :confused:

[burfadel]

I asked essentially the same question on another thread under the x264 sticky earlier today. It hasn't been answered yet! The other day I noticed x264.nl seemed to be down, so something could have happened to the system and it combined the last two revisions. The main issue with this is it creates confusion and possibility of problems applying future patches!

[Dark Shikari]

What revision are we at now? The latest log entry on git says:



That is identical with the latest entry in the changelog on x264.nl, but the revision number there says 890 instead of 891 :confused:I thought it was 891 too... :confused:

[MythCreator]

Changelog has been changed to r891~

[Fantacinni]

x264.r892.patched.exe (http://www.mediafire.com/?x1zne7mkyhd)

Patches used:
x264.progress.indication.01.diff
x264_hrd_pulldown.04.diff
x264_psy_rdo.0.22.diff

Built by GCC 4.2.2 fprofiled, pthread, GPAC

[Razorholt]

x264_psy_rdo
Which patch please?

Thanks,
- Dan

[Fantacinni]

Which patch please?

Thanks,
- Dan

x264_psy_rdo.0.22.diff

P.S. Congratulations Spain!

[Razorholt]

Have you checked this patch: http://forum.doom9.org/showthread.php?p=1151782#post1151782 ?
It's just a suggestion since I haven't compared it with 0.22. Maybe someone has?

[Razorholt]

Can someone please compile a new build with:

- New VAQ2.0: http://forum.doom9.org/showthread.php?p=1153982#post1153982
- New PsyRDO: http://forum.doom9.org/showthread.php?p=1151782#post1151782

Thanks! :)

- Dan

[MythCreator]

x264.892.modified.exe (http://www.fs2you.com/files/214c21cc-4722-11dd-af7f-001143e7b41c/)
Source (http://www.fs2you.com/files/b339b668-4721-11dd-80e8-001143e7b41c/)


General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff(fixed)
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[MythCreator]

@Razorholt:
PsyRDO & VAQ2 can't be patched at the same time

[Razorholt]

@Razorholt:
PsyRDO & VAQ2 can't be patched at the same time
I see... Hopefully this is something that will be fixed soon :)

Thanks for the builds!

- Dan

[Wishbringer]

@MythCreator:
x264_hrd_pulldown.04.diff intentionally left out? Or was it meanwhile committed?

[MasterNobody]

@Razorholt:
PsyRDO & VAQ2 can't be patched at the same time
They can but there is small problem with applying them together because they both add constants in x264.h and patch utility after applying first patch can't find place where to patch second. But you can simply add these constants manually. There result would be
#define X264_RC_NONE -1
#define X264_RC_CQP 0
#define X264_RC_CRF 1
#define X264_RC_ABR 2
#define X264_AQ_NONE 0
#define X264_AQ_LOCAL 1
#define X264_AQ_GLOBAL 2
#define X264_AQ_HYBRID 3
#define X264_CMP_SSD 0
#define X264_CMP_PSY 1
By the way you can find recent builds with this patches here: http://komisar.gin.by/
P.S. This is not my builds.

[MythCreator]

@Wishbringer:
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

[Wishbringer]

Thanks, missed that message

[lexor]

@Wishbringer:
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html

I don't understand that message, it's talking like hrd was only ever used for interlaced encoding. But nal-hrd switch had to be used for 360/PS3 blu-ray/hddvd profiles even on progressive material.

So I don't see how that patch is a substitute for original.

[Sharktooth]

it is NOT.

[lexor]

it is NOT.

What's not? Not needed or not substitute?

If the former, it's in every megui profile for hd formats.

If the later, original question was why hrd patch isn't in, and MythCreator replied with that link. That suggests that he thinks it's a substitute. Since he does builds, I assumed he knew what the patches were for.

[Sharktooth]

it's not a substitute.
infact i dont use myth's builds for megui.

[MythCreator]

x264.893.modified.exe (http://www.fs2you.com/files/0138aa73-480a-11dd-9903-00142218fc6e/)
source (http://www.fs2you.com/files/0c8228ba-480b-11dd-bd53-001143e7b41c/)

General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919


Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[bob0r]

x264.895.modified.01.exe (http://files.x264.nl/x264.895.modified.01.exe)
x264.895.modified.01.source.zip (http://files.x264.nl/x264.895.modified.01.source.zip)

x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
http://forum.doom9.org/showthread.php?p=1151782#post1151782
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.895.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.895.modified.01.fprofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[MythCreator]

x264.897.modified.exe (http://www.fs2you.com/files/42531e61-4908-11dd-915e-0014221f4662/)
source (http://www.fs2you.com/files/4cfae88f-4908-11dd-8391-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364


x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919


Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[kemuri-_9]

x264 r899 builds with mods:

x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
http://forum.doom9.org/showthread.php?p=1047919#post1047919
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905

builds using -march flags (if specified)
k8 (AMD) flavor
http://kemuri9.net/dev/x264/x264_k8.exe
prescott (Intel) flavor
http://kemuri9.net/dev/x264/x264_prescott.exe
unspecified (generic) flavor
http://kemuri9.net/dev/x264/x264.exe

GCC 4.2.1-sjlj build fprofiled
can see how much gcc -march affects the speeds and which one works best for you.

see http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/i386-and-x86_002d64-Options.html for information on -march specs

[chainring]

x264 r899 builds with mods:

x264_psy_rdo.r889.diff
http://forum.doom9.org/showthread.php?t=138293
x264_qpfile_relax.diff
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_hrd_pulldown.04_interlace.diff
http://forum.doom9.org/showthread.php?p=1047919#post1047919
X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905

builds using -march flags (if specified)
k8 (AMD) flavor
http://kemuri9.net/dev/x264-arch/x264_k8.exe
nocona (Intel) flavor
http://kemuri9.net/dev/x264-arch/x264_nocona.exe
unspecified (generic) flavor
http://kemuri9.net/dev/x264.exe

GCC 4.2.1-sjlj build fprofiled
can see how much gcc -march affects the speeds and which one works best for you.

see http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/i386-and-x86_002d64-Options.html for information on -march specsAny possibility you could do one with '-march=prescott'? I have a lowly core duo, but it bombs on the nocona build, so I'm guessing it doesn't support the 64 bit extensions.

[akupenguin]

nocona (Intel) flavor
Nocona fails as a generic Intel flavor. In fact, both core2 and pentium4 run march=k8 faster than march=nocona.
Note that my results are specific to x264; apps with floating-point will differ.