Discussion about x264 and system resources (32-Bit vs. 64-Bit)

[looney]

Why x264 x86-64 builds (x264_r119 latest build from x264.nl) doesnt call for avisynth64 mod by SEt but for plain old avisynth? And when x264 x86_64 build reaches ~2,03GiB it stops responding in W7-CommandPrompt from which was called so it resembles to be still 32bit application?

I had a problem opening MBoF (aka. my bunch of files) thru avisynth's DirectDrawSource calls in old VDub/VDubMod 32bit So upgrade to VDub64/avisynth64 was necessary so that i could preview files but it still breaks after ~75*GiB AVIs i was trying to load (occupies ~1.75GiB of RAM in W7-64b). I installed AviSynth-MT 64 bit mode as was said in instructions running bat and placing avisynth.dll in /Win/System32 folder

When i try to load same .avs with ~100files x264.exe crashes during DDS loading around 85th file (~1.5GiB RAM in W7-ResourceMonitor). So i suppose it still uses old avisynth(32) which was crashing for me at same RAM amount point.

[nm]

Originally Posted by looney

Why x264 x86-64 builds (x264_r119 latest build from x264.nl) doesnt call for avisynth64 mod by SEt but for plain old avisynth?

64-bit x264 (and VirtualDub) can't use 32-bit AviSynth at all without a pipe setup of some sort.

If you are now using 64-bit x264 and VirtualDub, looks like the issue is not due to 32-bit memory allocation limits but something else. 100 files is quite a lot to load in AviSynth at once, especially through DSS.

[looney]

Originally Posted by nm

64-bit x264 (and VirtualDub) can't use 32-bit AviSynth at all without a pipe setup of some sort.

That seems logical from my view also, because i unfortunately tried it for myself (... need VDub64 along with avisynth64 to load .avs files in VDub64 --64bit toolchain), but as long x264 goes it uses 32bit avisynth and has 2GB RAM limit at least this x86_64 build i downloaded. I don't have devenv to build it myself nor do i have all requirements.

If you are now using 64-bit x264 and VirtualDub, looks like the issue is not due to 32-bit memory allocation limits but something else. 100 files is quite a lot to load in AviSynth at once, especially through DSS.

I dont use x264 from VDub as its still impossible, from the old days of pre-sex264 vfw i used to thwittle with. I use x264 from w7 cmdline as its only possible afaik.
If ~75 files use less than 1.75G i think it should be possible to load at least 150 of them in some 3.5G RAM

I'm opened to use any other splitter, i tried ffms2 FFVideoSource w/o success and i dont know how safe is it, nowhere it mentions fps just like AS AVISplitter, but need index file. Well i'm not to familiarized with it as it's confusing for newbie coming from AS source openers. Updated list of other avisynth plugins for opening source files would help.

Only tweak i could think of now is not to use HaaliMatroskaSplitter to load AVIs as i selected that in installation and dont have RegTweak/knowhow to use original w7 avisplitter

[nm]

Originally Posted by looney

but as long x264 goes it uses 32bit avisynth and has 2GB RAM limit at least this x86_64 build i downloaded.

There are two options:

1. The x264 build that you are running is not 64-bit.
2. There is no 2 GB RAM limit.

So, are you sure the build you are running is 64-bit? How do you determine that there is a 2 GB memory limit? Loading up 100 files to AviSynth is not the way to look for a limit because there may be other bugs concerning large number of clips that lead to an AviSynth crash.

Originally Posted by looney

I dont use x264 from VDub as its still impossible

It's very possible with x264vfw, but I wasn't talking about using x264 within VDub. I meant that you have loaded your script in 64-bit AviSynth within both 64-bit VirtualDub and 64-bit x264, and 32-bit versions of both, and run against the same problem in all cases. The conclusion is that your issue is not due to 32-bit memory limits but something else.

Originally Posted by looney

If ~75 files use less than 1.75G i think it should be possible to load at least 150 of them in some 3.5G RAM

Sure, unless there's a bug or some other limitation in AviSynth that prevents you from loading up more than 75-80 files.

Originally Posted by looney

I'm opened to use any other splitter, i tried ffms2 FFVideoSource w/o success

What do your AVI files contain?

How exactly did FFMS fail?

Have you tried AviSource?

Post your AviSynth script.

[MatLz]

Maybe related ?
http://forum.doom9.org/showthread.php?p=1451951

[nm]

Originally Posted by MatLz

Maybe related ?
http://forum.doom9.org/showthread.php?p=1451951

Yep, definitely related.

Based on that information, the answer is to try a source filter that doesn't depend on DirectShow or VFW at all. So don't use DirectShowSource or AviSource.

I'd simply join the files to one video before sourcing it in AviSynth.

[looney]

Originally Posted by nm

There are two options:

1. The x264 build that you are running is not 64-bit.
2. There is no 2 GB RAM limit.

So, are you sure the build you are running is 64-bit? How do you determine that there is a 2 GB memory limit?

Or third, as i thought in my first post x264(64) calls for AviSynth(32) I only could be sure that i downloaded something that claimed to me 64bit version --different CPU optimizations also tell me that during encode (x264 x64 8b c119r2106 md5_0885DEE3579A0F8A06CEE783A3715226)

I saw limit in Resource Monitor Win7 (after it's crashed it stays some time as ghost info under Memory tab). I load enoug files <1.5GB thru avs-DDS and when x264 starts processing it reaches above mentioned 2,03GB and stops responding

Loading up 100 files to AviSynth is not the way to look for a limit because there may be other bugs concerning large number of clips that lead to an AviSynth crash.

When i divide same job into few smaller ones just DDS it loads regularly (as long as avs-load in x264 call is under 1.0-1.1GB)

I meant that you have loaded your script in 64-bit AviSynth within both 64-bit VirtualDub and 64-bit x264, and 32-bit versions of both, and run against the same problem in all cases. The conclusion is that your issue is not due to 32-bit memory limits but something else.

Sure, unless there's a bug or some other limitation in AviSynth that prevents you from loading up more than 75-80 files.

I load script into VDub64 and VDub both, and there are different limits but still doesn't help VDub/VDubMod1510.2 crashes on avs load ~1.35-1.4GB, while 64 bit crashes on 1.75GB

I used official AviSynth 2.5.8 and SEt's MT_x86-64 mod and there is obvious difference in number of files which they're capable to load (75 vs. 85 files) no matter that ain't enoug fpor me . So it doesn't resemble like some bug in 2.5.8 DDS call (and certainly i wouldn't be first to find it as these AviSynth builds are few years old)

What do your AVI files contain?
How exactly did FFMS fail?
Have you tried AviSource?
Post your AviSynth script.

The one thing that cant be wrapped into mkv HYUV
I fussle around FFVS load and i'm not too familiar with. It's really digressive d-tour i'd rather try different AVIsplitter than Haali's Matroska thats default and still aint finding how to deregister its AVIsplitting associations and connect to default W7 avisplitter

I tried AVISource and it fails after much sooner

Script is just boring DDS loader all equations works well (it passes parsing part when we talk about loader) it just crashes in memory. btw system W7 w/ 8GB RAM only which i thought it should suffice but i'm proven wrong
(zipped in attach)

btw. what this x264 exceptions means (producing normal encoding results)

x264 [warning]: non-strictly-monotonic pts at frame 0 (-9223372036854775808 <= -1)
x264 [warning]: non-strictly-monotonic pts at frame 1 (-9223372036854775808 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (-9223372036854775808 <= 1)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones

Originally Posted by MatLz

Maybe related ?
http://forum.doom9.org/showthread.php?p=1451951

Thanks. I d also want to script that way with function that would auto collect repetitive filenames in some folder. But i don't even know how to ?MAKE_DEF_FOLDER? as variable (name)

My question as some trying to d-tor me, aint [STRIKEOUT]"How many files i can load with DirectDrawSource()/AVISource() call?"[/STRIKEOUT] but rather "Why i cannot occupy more than 1.35/1.75/2.03GB of RAM space even though i use something that claimed to be 64bit toolchain? And is there someone who also faced this kind of problem"

64bit toolchain:
VirtualDub 1.9.11 AMD64, AviSynth 2.5.8 MT x64 (by SEt) (used install script and placed avisynth.dll in W/sys32 manually), HuffYUV64 (non-important?? since i'm using x264 from cmdline), Haali Matroska Splitter 201103, x264 x64 8b c119 r2106

32bit toolchain:
VirtualDub 1.6.17/VDubMod 1.5.10.2 b2540, AviSynth 2.5.8 (non-MT)/AviSynth 2.6 (before i had to roll back to install 2.5.8 MT x64 version), HuffYUV

Originally Posted by nm

Based on that information, the answer is to try a source filter that doesn't depend on DirectShow or VFW at all. So don't use DirectShowSource or AviSource.
I'd simply join the files to one video before sourcing it in AviSynth.

I dislike to work with huge files, too. The only valid way to open these files later is that they should be splitted into max size of 2048MB, in which they already are. So if I join them (and if that passes w/o errors ... it requires quite some time to just copy it to different drive) later I cant open it with nothing, and they cant be resplitted that they could work later. Anyhow you d-touring from my question.

You didn't work with HYUV and huge amounts of data. Unfortunately this combination ain't conceived to work in synergy without hassle.

I already read Decompressor error after too many calls to AVISource so i already knew what to expect from AviSource calls but this is different matter and it seems doesn't have nothing with internal AviSynth bug but rather with memory allocation which for some matter neither x64 mod doesn't resolve.

[kemuri-_9]

A) It is impossible for a 64bit x264 to use 32bit avisynth to open a script (e.g. you pass x264 a .avs directly), it must be a 64bit avisynth.

B) Just because you go from 32bit to 64bit doesn't magically mean Windows itself has a bazillion more resources to hand out.
What I mean by this is that Windows itself has its own caps on how many "resources" (or handles) of certain object types it's willing to give out. If you hit this limit, there isn't going to be much you can do to fix it, as the OS itself said it won't give you any more!

btw. what this x264 exceptions means (producing normal encoding results)

this is a known side effect of avisynth 64 violating the windows 64 ABI (JoshyD's 64bit avisynth builds have/had this issue). it's not usually a problem for cfr content like avisynth.

[looney]

Originally Posted by kemuri-_9

Windows itself has its own caps on how many "resources" (or handles) of certain object types it's willing to give out. If you hit this limit, there isn't going to be much you can do to fix it, as the OS itself said it won't give you any more!

It would be much more helpful that you kept me in behind the mirror How to override these limitations because cmd.exe is 64bit on Win7? and even has built in stupid message ~this is 32bit app you might wanna use 64bit version~ when executing 32bit applications. I'd expect at least that w7 now could handle 4GB per app (that would suffice in my case). Is there a switch from hidden cookbok that we could use because 2GB limit per app is same as it's 32b app running on plain good WXP.

this is a known side effect of avisynth 64 violating the windows 64 ABI (JoshyD's 64bit avisynth builds have/had this issue). it's not usually a problem for cfr content like avisynth.

This just puzzles me even more W64 ABI? How does CFR (constFR?) affect AS/W64 ABI?

[kemuri-_9]

Originally Posted by looney

It would be much more helpful that you kept me in behind the mirror How to override these limitations because cmd.exe is 64bit on Win7? and even has built in stupid message ~this is 32bit app you might wanna use 64bit version~ when executing 32bit applications. I'd expect at least that w7 now could handle 4GB per app (that would suffice in my case). Is there a switch from hidden cookbok that we could use because 2GB limit per app is same as it's 32b app running on plain good WXP.

Note that I did not say 'Memory', I said 'Resources' in my original post; they are different. You apparently skipped the thread linked by MatLz, I suggest you read that for clarity.

you are assuming that everything is memory based, which is a very wrong assumption when it comes to OS-based resources.

This just puzzles me even more W64 ABI? How does CFR (constFR?) affect AS/W64 ABI?

I was saying that the warning is not usually an issue for cfr content. vfr content is generally broken when this warning occurs however.
I'm not going to re-go into the details on the issue, it was discussed a good while back in the avisynth 64 thread... you can read it there.

[looney]

Originally Posted by kemuri-_9

Note that I did not say 'Memory', I said 'Resources' in my original post; they are different. You apparently skipped the thread linked by MatLz, I suggest you read that for clarity.

You meant this. It sound plausible.?

Originally Posted by StainlessS

.... EDIT:- There are probably settings that could be hacked in the registry to achieve a greater usable number of VFW instances, however, I would not know what they are and it may impact system performance in other
areas that may not be desirable.

<digress> Well i know they're limiting video card max stream that can use let's say Overlays (in WinXP) but that was done exam. by ATi drivers. When X1 series was actual i know i could render at least 3 overlays simultaneously in MPC6491 while with newer drivers that number was kept at only one overlay (probably to push sale of their dx10 cards and promote evr/vista). I know overlay is obsolete draw method, but it's low on resources and helping you draw multiple instances of video when you have poor CPU (A64x2 alike) and you try to mess around with multiple 720p x264 or just playback 1080p in those days w/o clipping</digress>

But, nevertheless I mention some regtweaks considering deactivating AVIsplitting by HaaliMS, I didn't thought (refer) that there could be a physically hardcoded number of VfW calls. And i still dont believe it is so because i myself in this case could pull different number of sources in same AviSynth script just loaded by different application.
I use DirectDrawSource calls and not AVI source as it was mentioned it helps a lot. I'm not the coder, but it seems that we cannot conclude this matter jus with Wins VfW or decoder for that matter it might be HaaliMS which in any case doesn't need to be compiled with x86-64 support. So trying deregistering HMS from my DD path might be helpful thing (already), if i knew how could it be done.

EDIT: I successfully disable AVIsplitting by Haali the only way possible by reinstalling it. But default Win7 AVIsplitter is even worse: it can load thru DDS calls less than 32 files and fails more rapidly without giving up where it failed. So another reinstall of HaaliMS now with AVI support brings things back to home waters.

[Audionut]

Originally Posted by looney

(x264_r119 latest build from x264.nl)

The latest version of x264 is 2106.

[looney]

After a few dozen unsuccessful tries to load quite a bunch of files thru avs into x264/vdub 64bit which was miserably failed on exit & save last few 1st pass stats (x264) or during seek in vdub-damn64. I finally try to familiarize myself with FFmmpegsource (ffms2).
And, duh it was a success story :biggrin:. Althou ffms2 after it loads all 43 files also eats up to 2,6GiB RAM it lets x264 to successfully terminate and starts second pass w/o fail to write few last frame stats. (DDsource also loads 42 files w/o issue using HaaliMedia Spliter, it just immediately eats up 3,3GiB RAM (commit) and bloatly sails across the wasteland just to be sunk in shallow waters whwn shore is just in its spitting distance.)
After a good sleep i realize that the only difference is DirectDrawSource "fps" now became two values in ffms2 fpsnum and fpsden (def=1, so fpsnum is enough) So now the line is

FFVideoSource("upaci04.00.avi", fpsnum=25000, fpsden=1000) +\
...
FFVideoSource("upaci04.42.avi", fpsnum=25000, fpsden=1000)

instead of

DirectShowSource("upaci04.00.avi", fps=25.000, audio=false) +\
...
DirectShowSource("upaci04.42.avi", fps=25.000, audio=false)

The only backside that nagged me in those days is .ffindex files that needs to be written before video source files could be loaded, but i guess it's the only way to lower needs for resources.
I still use old HFYU 2.21 (wCCESPpatch022) for intermediate passes as it seems to be least resource hungry, bu then i have this kind of fuss loading huge amount fo 2GB files into memory to step into next phase.

And big thanks to kemuri-_9 and the rest of you.

[looney]

Now when i saw that FFMS allow way larger loads to be transferred for x264 input i wonder how to make same good old jeeb build (which is no longer maintained :weeping: ) to work with larger than 4GB memory chunks?

So FFMS work with *unlimited* loads against DirectShowSource which doesnt know how to handle sizes around 2GB? Is there a way to surpass x264 4GB limit on AMD64 (x64) system, i've been looking on the forum and the only thing touching high loads is avs4x264mod v0.6.2, discover y2m (aka YUV4MPEG2) as its pipebuf feature is often mentioned for high memory need [1] and avs2pipe. But nothing really answering how to go beyond 4GB limit with x264?

[nm]

What 4 GB limit in x264? There isn't one in any x64 builds.

If you use 64-bit AviSynth with 64-bit x264 and a high enough SetMemoryMax(), there should be no 4 GB issues.

[looney]

I'm using same old x264 c119 10b by jeeb and AvS mod by SET as they explained to me there's no way x64 build to use old 32b AvS, but i never try to use SetMemoryMax() leaving it with empty value. Ii tried reduce memory use by SMM(3076) and lower trying to reduce AvS memory load, but still getting same "x264 has stop working" cmd's exception. Without SMM load on x264 start is around 4.8GB, (but with smm set mem load is same like my AvS doesnt use it (or i dont know how) but also dont throw any exception, x264 properly loads video but crashes on "x264 profile" line) So leaving it empty should help i'll try it hope you're save me cause i'd never try it. SMM 7000 or 8000 doesn't help, nor leaving it empty.

I cant build x264 for myself so i'll guess i have to split the load into two separate ones that i stubbornly want to avoid. (I use to encode in splits, but i didnt wanna admit that machine could beat be in such way if i have enough ram)

ED1: It might be a Win7 problem, as with splitting job in two parts when x264 should exit and accessing stats file at the end of first pass it crashes. Whole time x264 commit is around 3.5GB but at the same time polluted memory (by Win7 management aka.Standby) risen to 12GB (fills up the rest of free ram). If i kept jobs even smaller with above mentioned 2.6GiB of ram x264 finishes nicely. So i'm really not that tech savvy to say what is going around here. I could only try PowerShell (Vista/Vin7) instead cmd if that would help.

ED2: Seems for me that ffms2 indexing and windows SuperFetch (or whatever is its name, which service is disabled btw) are heavily caching those video files for some reason. (Something is really broken on this sys.) DDS seems to work for now but Commit is already too heavy >2.8GiB and x264 will probably crash after all.

ED3: Seems now that simple removing SetMemoryMax(3000) from every AvS job helps and now same job total memory usage doesnt rise above 2.65GiB (per x264.exe) while same job with this line took up to 3.9GiB before it crash at 25%. And its ffms2 instead dds again, as it proofs more memory friendly when no SetMemoryMaxi() line is used.

[looney]

It seems that part of my problem lie in c119 release, as i go and build 20120319-stable with gcc4.4.6 which build as x264 c120 (not 122) but then i'm not using L-SMASH because i dont know where should I put its libs after they're build separately, before starting x264 build, or how to patch L-SMASH with x264_film_grain_optimization_20101216 or x264_fadecomp_20110111 (which needs further implant of rejected lines of code patch)

With this x264_c120.X_mybuild I successfully crunched same .avs which has been stubbornly failing on closeup of first pass on writing lasts few .stats and x264 crashed. I also downloaded latest x264 c122 r2184 official build on gcc4.6.3 and it does the same job just some 10% faster. Suspect that below entry dealt with above mentioned feature-bug, so big tnx to Bugmaster you've eradicated a big pest (althou i think i don't do sliced threads? at least I don't specify their usage anywhere)

commit 5c85e0a2b7992fcaab09418e3fcefc613cffc743 r2184
Author: Anton Mitrofanov <Bugmaster.AT(narod(d0t&ru>
Date:   Sun Mar 11 23:08:18 2012 -0700

   Fix clobbering of mutex/cvs
   Regression in r2183.
   Bizarrely seemed to work on many platforms, but crashed on win64 and may have been slower.
   Only affected sliced threads during encoding, but could cause crashes on x264
   encoder close even without sliced threads.

But now I some strange motion jerkiness appears when reproducing same video encoded with this ~10% faster official x264_c122_r2184 build then when i use my build which hasn't been build up with x264_L-SMASH libs.
Does x264_L-SMASH introduces those speedups or is that gcc-4.6.3 behalf (vs. gcc-4.4.6-Komisar I used), and if x264_L-SMASH contribute on speedup does it have some strange motion estimation patches which introduces this picture stuttering effect? The source is high motion unblended but still mybuild w/o L-SMASH gives much more fluid result (same settings on both, -umh -merange 32) and jerkiness appears in low motion scenes where only some part of scene moves.

ED1: I updated my decoder from LAVFilters-0.47 to LAVFilters-0.49 and now both encodes seems to have been played in same manner and jerkiness-stuttering from video encoded with x264_c122_r2184 is gone (WinXP w/ HD3200 noDXVA as both are 10bit encodes)

So is it motion jerkiness, that was resolved with decoder update, issued from using x264_L-SMASH or different version of libavformat (v.53.30 vs. v.54.2)?

x264 0.120.x
(libswscale 2.1.100)
(libavformat 53.30.100)
(ffmpegsource 2.16.4.0)
built on Mar 26 2012, gcc: 4.4.6 (x86_64.generic.Komisar)
configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

x264 0.122.2184 5c85e0a
(libswscale 2.1.0)
(libavformat 54.2.0)
(ffmpegsource 2.17.1.1)
built on Mar 12 2012, gcc: 4.6.3
configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 3 or later