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

[tormento]

http://doom10.org/index.php?topic=177.msg2130#msg2130
Is it possible to get a x64 version with all the patches but the one that causes that issue?

Staxrip can't change the command line.

[easyfab]

Toolchain:

x264_x86_r1592M (http://www.multiupload.com/56NLFZ4CUQ)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/qcNYfXWZ) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/G7zjaChB) <komisar>
x264.open-gop.22_r1592 (http://pastebin.com/at39YNXN) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/rf9EZfN2) <Dark Shikari>
x264_avi_output.v4_r1592 (http://pastebin.com/xyNNAqy6) <MasterNobody>
x264_filtering_r1592 (http://pastebin.com/98VLM5Pg) <kemuri-_9>
x264_filtering_changes_r1592 (http://pastebin.com/1eiDAmiv) <J_Darnley>

Is it possible to set % for the resize filter, for example 75% of the original size ?

[J_Darnley]

Is it possible to set % for the resize filter, for example 75% of the original size ?

No...

[rack04]

Is it possible to get a x64 version with all the patches but the one that causes that issue?

Staxrip can't change the command line.

Use the unpatched version.

[tormento]

Use the unpatched version.

I'd like to get the benefits of other patches...:eek:

[Audionut]

I'd like to get the benefits of other patches...:eek:

http://komisar.gin.by/

And thanks for using the filtering patch again rack04.

[burfadel]

Is it possible to get a x64 version with all the patches but the one that causes that issue?

Staxrip can't change the command line.

If the patch provides an extra command line option, it can be added under 'config codec', under the 'Command Line' tab. There are three boxes under the command line tab. The first is to change the options for all passes, or in CRF mode, and the other two are for first and second pass options.

If there is a patch that changes an existing option, you can also change it. For example, if there were a new AQ patch that added AQ mode 3 for testing (and this has been done in the past)!, you can't change it via the standard gui options. What you do is leave/change AQ mode to 1 in the gui (typical default), in which case its not specific in the command line. You can then add --aq-mode 3 in the command line section and you will see it with all the options selected at the bottom of that tab.

This has been a feature of Staxrip for a long while, but if you haven't got the very latest version, it would still be a good idea to update :)

Of course, you can use later versions of any component Staxrip uses by replacing the ones that come with Staxrip. You can then accept the message saying its newer and it should be ok! (unless the updated version of the programme changes the required command line syntax or function).

[tormento]

If the patch provides an extra command line option, it can be added under 'config codec', under the 'Command Line' tab.
Very kind answer, thanks. I have the latest version but can't find how to replace a mandatory command line option with another.

[outlaw.78]

x264 0.96.1612M x64 & x86 (http://www.mediafire.com/?mkmzjmdzcdm)


gcc 4.5.1 20100523 prerelease
ffmpeg svn 23327
swscale svn 31217
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.96.1612M x86,x64,amdfam10,fprofiled
patches used :
04_x264_thread_pool_v2.9.r1602.diff (http://komisar.gin.by/old/1602/p/04_x264_thread_pool_v2.9.r1602.diff)
x264_demuxer_threads.diff (http://komisar.gin.by/old/1602/p/x264_demuxer_threads.diff)
x264_sws_typecast.diff (http://komisar.gin.by/old/1602/p/x264_sws_typecast.diff)
x264_avi_output.v4.diff (http://komisar.gin.by/old/1602/p/x264_avi_output.v4.diff)

[burfadel]

Very kind answer, thanks. I have the latest version but can't find how to replace a mandatory command line option with another.

Which mandatory command line are you trying to replace?

[3ngel]

Hi,

from some time, i'm facing a strange problem.

I'm not able to complete an encode whetever parameters i set, because of the error after some time (first pass)

"ratecontrol _init: can't open stats file"

After investigation, i found that pheraps there is a memory allocation problem.

That is, actually i'm doing an encoding, first pass, and x264.exe has allocated already 1.575.233 bytes, and is slowly but constantly increasing.

Now the memory user space on a 32bit system is 2GB, so i can assume that when the allocation reaches the 2GB, the encoder fails because _malloc can't allocate anymore.

I could try with the /3G switch but i think it's not normal to allocate for an encoding such a huge amount of memory (and i suspect that even with the /3G the encoder would reach the limit).

Any confirm on this from someone?

Possible solution?

I'm on Windows 2003 intel i7 6 cores.

Thanks

[Dark Shikari]

Hi,

from some time, i'm facing a strange problem.

I'm not able to complete an encode whetever parameters i set, because of the error after some time (first pass)

"ratecontrol _init: can't open stats file"

After investigation, i found that pheraps there is a memory allocation problem.

That is, actually i'm doing an encoding, first pass, and x264.exe has allocated already 1.575.233 bytes, and is slowly but constantly increasing.x264 will print a malloc error if a memory allocation fails.

[J_Darnley]

Which mandatory command line are you trying to replace?

He's trying to get the filter patch working via staxrip. The change he needs is that the input resolution must be given with --input-res instead of just the argument after the input file name.

[rack04]

He's trying to get the filter patch working via staxrip. The change he needs is that the input resolution must be given with --input-res instead of just the argument after the input file name.

What raw inputs files do you need to specify --input-res?

[nm]

What raw inputs files do you need to specify --input-res?

All that are really raw and don't have a container. Apparently Staxrip is piping raw video to x264, so --input-res is required when using the filtering patch.

[rack04]

All that are really raw and don't have a container. Apparently Staxrip is piping raw video to x264, so --input-res is required when using the filtering patch.

Thanks. The reason I asked is because I am feeding yuv, have the resolution set in the filename, and it still works fine.

[nm]

Thanks. The reason I asked is because I am feeding yuv, have the resolution set in the filename, and it still works fine.

Yes, that is still an option, but not when piping without a FIFO file.

[J_Darnley]

What raw inputs files do you need to specify --input-res?

All raw input needs the resolution set. I had forgotten about the filename parsing though.

[rack04]

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

ffmpeg SVN-r23340M and libswscale SVN-r31226M (http://www.multiupload.com/7J673HAZOW)
ffms2 SVN-r312 (http://www.multiupload.com/TVBZPXWJDE)
x264 Builds:

x264_x64_r1613 (http://www.multiupload.com/9SSR7BIARU)
x264_x86_r1613 (http://www.multiupload.com/THYZ0VBC9N)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1613M (http://www.multiupload.com/VCXRCEEEIU)
x264_x86_r1613M (http://www.multiupload.com/GNF6148HX8)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/Gj3vR7re) <komisar>
x264_demuxer_threads_r1602 (http://pastebin.com/12ECMUPX) <komisar>
x264.open-gop.22_r1613 (http://pastebin.com/5AScMVNS) <Trahald>
x264_fade_compensation_r1612 (http://pastebin.com/JhY4G5XU) <Dark Shikari>
x264_avi_output.v4_r1602 (http://pastebin.com/4sew624g) <MasterNobody>
x264_filtering_r1612 (http://pastebin.com/AZdGNwMv) <kemuri-_9>
x264_filtering_changes_r1602 (http://pastebin.com/QU9Xwxy6) <J_Darnley>
x264_thread_pool_v2.9_r1613 (http://pastebin.com/R3ADAXuj) <MasterNobody>

[komisar]

rack04, x264_thread_pool_v2.9_r1612 patch by <MasterNobody>...

[rack04]

rack04, x264_thread_pool_v2.9_r1612 patch by <MasterNobody>...

Fixed. Thank you.

[ajp_anton]

What happened to the Intel builds?

[Schrade]

rack04, x264_x86_r1613M download link links to an archive named x264_x86_r1612M.7z

Is it just a typo?

[rack04]

rack04, x264_x86_r1613M download link links to an archive named x264_x86_r1612M.7z

Is it just a typo?

What does --help say?

x264 core:97 r1613M 81e75e9

[jpsdr]

Rack04 : Big problem with your x64 1613M version. I have the program wich brutaly crash/stop without any kind of error message after encoding 30 frames of the 1rst pass (video is 1280x720 23.976fps)...

Commande line used :

@echo off

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

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

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.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --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 %5 --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.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

[rack04]

Rack04 : Big problem with your x64 1613M version. I have the program wich brutaly crash/stop without any kind of error message after encoding 30 frames of the 1rst pass (video is 1280x720 23.976fps)...

Commande line used :

Post a sample that can be reproduced. Do it work with unpatched build?

[tormento]

Which mandatory command line are you trying to replace?

Well, replace the older command line with the newer that should use rack04 patched compile.

[jpsdr]

I'll make other tests this evening. With unpatched build, the command line will be of course without open-gop.

[kypec]

Fixed. Thank you.
You've only fixed _x86 part. <komisar> is still mentioned at _x64 part.
I think it would be easier for you and also for the readers to join that
descriptive links to patches. Write them just once together with compilation
settings used and post only separate download links to _x86 / _x64 builds underneath.
Same suggestion to unpatched builds applies.
It's redundant and likely error prone to write same information twice, no need for that.

[Wishbringer]

Big problem with your x64 1613M version. I have the program wich brutaly crash/stop without any kind of error message after encoding 30 frames of the 1rst pass...

Same here, tried to encode 1920x1080/24
--profile high --preset veryslow --tune film --slices 4 --level 4.0 --keyint 48 --min-keyint 2 --aq-mode 2 --b-pyramid strict --aud --nal-hrd vbr --open-gop --vbv-bufsize 31250 --vbv-maxrate 15000 --direct auto

Same encode worked with 1603, I just updated the exe to 1613M and restarted encode.

[rack04]

Same encode worked with 1603, I just updated the exe to 1613M and restarted encode.

Have you tried without open-gop? Can you post a sample?

[Wishbringer]

Without --open-gop it works (1st pass was ok, atm it started 2nd pass and is at 10%).
Sorry, no sample, am here at girlfriend with only 64kbit/sec upload speed.

[rack04]

Without --open-gop it works (1st pass was ok, atm it started 2nd pass and is at 10%).
Sorry, no sample, am here at girlfriend with only 64kbit/sec upload speed.

I found the problem. Try (http://www.multiupload.com/VCXRCEEEIU) this build. I will update the download link in the other post.

[jpsdr]

Was the problem specific to x64 build ?

[rack04]

Was the problem specific to x64 build ?

Nope. I managed to screw up the the open-gop patch. It should be fixed now.

[Wishbringer]

Seems to work now, 1st pass at 30%, no crash like first build at 0-1%.

Thanks rack04!

[jpsdr]

@Rack04Thanks for the builds and the updates. I'll test it.
@Wishbringer : Level 4.0 don't need slices (if encoding for blu-ray), so, removing will slighty improve quality.

[3ngel]

I continue to have the same situation with first pass truncked after some minutes with only a "encode failed" and second pass that can't find the "stat file".

I've downloaded again from the Rack04 updated post the new build (with the open gop corrected patch), but same problem.

I download the x86 without filters.

Am i missing something?

Thanks

[Wishbringer]

I continue to have the same situation with first pass truncked after some minutes with only a "encode failed" and second pass that can't find the "stat file".

I've downloaded again from the Rack04 updated post the new build (with the open gop corrected patch), but same problem.

I download the x86 without filters.


The 1613 build without "M" in name?
Does it even have open-gop-patch? it's not "Modified"!
Maybe your 1st pass doesn't start because it can't recognize "--open-gop" command.

[rack04]

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

ffmpeg SVN-r23424 and libswscale SVN-r31303 (http://www.multiupload.com/YUWSC4I0YH)
ffms2 SVN-r312 (http://www.multiupload.com/OQOYFB5ID9)
x264 Builds:

x264_x64_r1627 (http://www.multiupload.com/347NAPXR9D)
x264_x86_r1627 (http://www.multiupload.com/4J4LYXN9E6)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[3ngel]

I continue to get this error after some minutes of encoding

x264.1627.x86.exe --pass 1 --slow-firstpass --profile
high --preset veryslow --tune grain --bitrate 5832 --no-deblock --ssim --level
4.1 --output NUL s2.avs
avs [info]: 1920x1080p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [error]: x264_encoder_encode failed50.21 kb/s, eta 7:29:39

What is related to?

How can i resolve?

[rack04]

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

ffmpeg SVN-r23439 and libswscale SVN-r31309 (http://www.multiupload.com/UR61SHUQHN)
ffms2 SVN-r312 (http://www.multiupload.com/890GM7F1VK)
x264 Builds:

x264_x64_r1629 (http://www.multiupload.com/UQHOWB3ZK8)
x264_x86_r1629 (http://www.multiupload.com/QVO60QPT79)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1629M (http://www.multiupload.com/SWLVZ6FSHM)
x264_x86_r1629M (http://www.multiupload.com/YK0B52W77K)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_open-gop.22_r1629 (http://pastebin.com/t2Y0QYA8) <Trahald>

[kemuri-_9]

MinGW ffmpeg+x264 builders:
please update ffmpeg to r23448+ to fix >4GB file support in ffmpeg (and ffms2).
*NOTE*: this only applies if you haven't already patched your mingw to already fix the issue...
I've confirmed that JEEB, rack04, and x264.nl builds are all broken in this regard...

[JEEB]

Oh ffu~.

Thanks for the heads-up and great job on getting stuff fixed in ffmpeg. Will have to rerun the compilation script once more it seems :)

Edit: Could you also possibly link to the related "fixing it on the mingw side" patch? Would be nice to know just in case.

[kemuri-_9]

Edit: Could you also possibly link to the related "fixing it on the mingw side" patch? Would be nice to know just in case.

I received http://pastebin.com/sz0Gc4HE from Nicholi on the matter

[rack04]

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

ffmpeg SVN-r23467 and libswscale SVN-r31314 (http://www.multiupload.com/SXF8B8VHCO)
ffms2 SVN-r312 (http://www.multiupload.com/DU5APARCNO)
x264 Builds:

x264_x64_r1629 (http://www.multiupload.com/0PFS2K388D)
x264_x86_r1629 (http://www.multiupload.com/5FLZW54876)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1629M (http://www.multiupload.com/JQMTS68C32)
x264_x86_r1629M (http://www.multiupload.com/GHWP53LONW)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_open-gop.22_r1629 (http://pastebin.com/t2Y0QYA8) <Trahald>

[rack04]

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

ffmpeg SVN-r23486 and libswscale SVN-r31321 (http://www.multiupload.com/0AU1IH676Z)
ffms2 SVN-r312 (http://www.multiupload.com/80ZNKANZHE)
x264 Builds:

x264_x64_r1629M (http://www.multiupload.com/RWKMNCQ6SD)
x264_x86_r1629M (http://www.multiupload.com/A6JZVGTP73)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_open-gop.26_r1629 (http://pastebin.com/iPZTiykn) <Trahald>

[aegisofrime]

Hi there. I have a question that I guess some will find really weird. But anyway...

I'm about to start an encode of a TempGaussMC'ed 1080i content. As one can imagine, the process will be slow. The last time I did this it took 2 weeks.

As such, I will like to ask if the x264 developers have any major quality or speed improvements in the pipeline soon, so I can hold off my encode until that release.

Thanks :)

[jpsdr]

Personnaly, i do all process before encoding, and save the result in a file with lossless codec (i use Lagarith in YV12 mode).
Like this, if you encode in multi-pass, you gain speed of not having all your pre-processing doing twice, and if there is a problem with the encode, and you need to do it again, at least your pre-processing is already done. This is the first thing to do to gain speed, i think.

[julius666]

I'm about to start an encode of a TempGaussMC'ed 1080i content. As one can imagine, the process will be slow. The last time I did this it took 2 weeks.


That's simply insane. :eek:
Are you sure that it's worth the effort? The + quality that TempGaussMC gives (over TDeint for example) is not "so huge", let alone in FullHD.
What's your source? What avisynth script do you using?