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

[skystrife]

Originally Posted by kemuri-_9

i will no longer be supporting the
x264_win_zone_parse_fix patch i originally started.

for the reason of:
I've successfully added BugMaster's strtok_r to my mingw's native libraries.
it works like a charm,
thus the patch is not needed for me anymore

This may be a dumb question, but how did you go about doing this?

--------------------------------------------------------------------

x264.1055M.exe - Alternate Download

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

Originally Posted by skystrife

This may be a dumb question, but how did you go about doing this?

put it most simply 'library hacking' though i wouldn't slate it as 100% hacking,
due to the way the mingw libraries are setup as ar packages.

[Audionut]

x264-r1056.rar

Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

[kemuri-_9]

Originally Posted by skystrife

This may be a dumb question, but how did you go about doing this?

I've finished standardizing a shell script which should be able to handle patching any mingw installation...
(in other words, tell me if it says it didn't work with supplying what didn't work)

files:
install_strtok_r.sh: "./install_strtok_r.sh /mingw" - should work for most (requires base directory prefix of lib and include dirs as a parameter - which for most is /mingw)
x264_mingw_check_strtok_r.diff: recognize existence of strtok_r to not define it as strtok if strtok_r does exist.

Edit:
oh right, here's a patch for msvc users to use its version of reentrant strtok (and thus have zone support).
x264_msvc_zones_fix.diff

[skystrife]

Thanks again, kemuri; the script worked like a charm.

x264.1057M.exe - Alternate Download

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_mingw_check_strtok_r.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

-----------------------------------------------

x264.1057M.x64.exe - Alternate Download

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff (as the custom strtok_r patch likes to crash with the 64-bit build, unsure as of why but it crashes upon reaching 100% completion. I suspect gcc being stupid, personally.)
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

[burfadel]

What do these two uncommitted? patches do?
http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

The second one has some SSE4 references

[Dark Shikari]

Originally Posted by burfadel

What do these two uncommitted? patches do?
http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

The second one has some SSE4 references

The first is the first part of an evil plan to make an obnoxiously fast SATD function. Current estimations say that we might be able to beat the current one by over 60% on Conroe Core 2. Once all the parts of the evil plan come together, they may result in the largest speed gain in a single patch in at least a year.

The second one is a prototype of an attempt to make exhaustive a little bit faster.

Wait for them to be finished and committed

[burfadel]

What would a 60 percent faster SATD function result in overall for speed, using typical settings (as an estimation)? I realise its not nice to annoy developers with such questions, but I think its justified in this case .

Keep up the great work! Its appreciated by a lot of people. Merry Christmas/Seasons greetings!

[Dark Shikari]

Originally Posted by burfadel

What would a 60 percent faster SATD function result in overall for speed, using typical settings (as an estimation)? I realise its not nice to annoy developers with such questions, but I think its justified in this case .

At ordinary encoding settings, SATD can be up to 20-25% of encoding time.

Do the math.

(By the way, we define "60% faster" as "60% more SATDs can be done in the same period of time", not "takes 60% less time").

[kemuri-_9]

Originally Posted by skystrife

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff (as the custom strtok_r patch likes to crash with the 64-bit build, unsure as of why but it crashes upon reaching 100% completion. I suspect gcc being stupid, personally.)
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

reasons for the crash could be one of the following:
1. it might be crashing due to the mingw aligned patch, since the function names are different for mingw x64.*1

2. the win zone patch also includes a memory allocation change since 03,
this change is meant to fix possible incorrect allocations, which could rear it's ugly head in data manipulation and when freeing the data which would result in seg faults.
the strtok_r patch does not include the supposed memory allocation fix, as it's never crashed for me in mingw builds, only in msvc builds.

*1
I'm holding on releasing the updated patch, since I'm not sure what's going on with mingw x64 having the necessary aligned memory prototypes commented out in the header file.
(options are that the methods are not implemented or not needed, but i'm not exactly sure which one it is - current patch assumes the latter)

you can try out my build listed in the win x64 support thread to see if it proceeds to crash so i can determine if the patches are ok to release or need some working.

[alexVS]

I have a question that may be very simple, may be not
I use VFW version of h264 encoder for using in TMpg Express 4.0 Encoder.
I use default settings, just set up ABR mode and bitrait.

What h264 codec settings can I change to get much better output quality WITHOUT big decrease of encoding speed?
I've got not a superb CPU. Only Athlon64 X2 4000+

[bmnot]

Why this patch was not accepted in main code?

HD HRD/Pulldown Patch:
Current: x264_hrd_pulldown.diff
Creator: Ian Caulfield/Trahald
Description: HRD and pulldown for HD compatibility.

Sorry, I didn't read 70 pages, but I am seeing it in many alternative builds.

[J_Darnley]

Originally Posted by bmnot

Why this patch was not accepted in main code?
Sorry, I didn't read 70 pages, but I am seeing it in many alternative builds.

http://forum.doom9.org/showthread.ph...rd#post1086281

Granted it was not in this thread but it wasn't hard to find by searching for posts by akupenguin that contain hrd

[MasterNobody]

Originally Posted by alexVS

I have a question that may be very simple, may be not
I use VFW version of h264 encoder for using in TMpg Express 4.0 Encoder.
I use default settings, just set up ABR mode and bitrait.

What h264 codec settings can I change to get much better output quality WITHOUT big decrease of encoding speed?
I've got not a superb CPU. Only Athlon64 X2 4000+

This is bad thread for VfW discussion (better here). If you mean x264vfw then I would recommend to change this options (they are not optimal by default but there is reason why they used):

Max consecutive B-frames: 0 -> 3
Threads: 1 -> 0
Max frame refs: 1 -> 3

BUT this changes would lead to drop of few last frames (and may be video vs audio desync). And you can't use "VirtualDub hack" to fix this problems because TMPGEnc doesn't support it.

[burfadel]

I thought www.x264.nl was self updating? I see there's rev 1058 up on git for 12 hours and www.x264.nl still shows build 1057...

I don't use ESA for which the patch pertains to, however I'm still curious why it hasn't self updated in case the same thing happens later!

[LoRd_MuldeR]

Originally Posted by burfadel

I thought www.x264.nl was self updating? I see there's rev 1058 up on git for 12 hours and www.x264.nl still shows build 1057...

I don't use ESA for which the patch pertains to, however I'm still curious why it hasn't self updated in case the same thing happens later!

Maybe the compile script failed?

[EDIT]

Yup, something seems to be wrong with r1058

This happens with "make fprofiled" on my system:



[EDIT²]

Seems like "-me esa" causes a crash, as soon as the encoding process reaches 100%.

Can't post backtrace, because GDB encounters an "internal error" right at the beginning with my r1058 debug build

[burfadel]

At a guess I'd presume the output file is fine? It may be related to the issue that I and someone else mentioned a few days ago under the x64 x264 thread, that rarely and unreproduceably the x86 x264 crashes right at the end, exactly the same fault as in your screenshot!

[LoRd_MuldeR]

Originally Posted by burfadel

At a guess I'd presume the output file is fine? It may be related to the issue that I and someone else mentioned a few days ago under the x64 x264 thread, that rarely and unreproduceably the x86 x264 crashes right at the end, exactly the same fault as in your screenshot!

Since it only happens with "--me esa" and didn't happen in previous revision, I suspect the latest commit...

[Audionut]

No problems here.


x264-r1058.rar


Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

[LoRd_MuldeR]

Originally Posted by Audionut

No problems here.


x264-r1058.rar


Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

Nope. Identical problem with that build: