PDA

View Full Version : x264 and i7 problem


egrimisu
26th October 2009, 08:01
hi,
i have this problem with x264 jeeb's 1183 when encoding with megui(up to date).
It's encoding like 1% sometimes 10% and after that freezes the frame count or x264 stop and getting (encoutered a problem an need to close)

xvid seems to work just fine.
i have tried older releases but still freezes.

the sistem is not OC'd only the ram to 8-8-824 1.35v and 1.66v but these are the dominators specs. Prime passed for 48 hours so the pc seem's to run fine. Nothing else freezed on the ring just x264.

when encoding the cpu is at maximum of 25% and it uses all 8 threads.

Does this happened to anyone else or just me? is there a solution or i need to look for something else? when encodig 264 uses some splitter or somekind of decoder that i need to replace? i need cccp with hali media spliter. Don't realy know exacly witch but sure not the latest. Thanks guys

Selur
26th October 2009, 09:04
Some additional infos might be a good idea,...
What OS are you using ?
Tried a current x264 (r1309) version?
How does your avisynth script look like?
How do your x264 settings look like?
...

egrimisu
26th October 2009, 09:42
DGDecode_mpeg2source("D:\Misu\1\VTS_01_1.d2v")
checkmate()
AnimeIVTC(mode=1,aa=1,mt=true)
LimitedSharpenFaster()
source = last
vectors = source.MVAnalyseMulti(refframes=1, pel = 2, overlap=4, sharp=1, idx = 1)
source.MVDegrainMulti(vectors,thSAD=400,idx=1)
crop( 8, 0, -8, 0)

os win7 x64 RC build 7100, but was the same on vista x32 or vista x64

x264:
program --profile high --crf 18 --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --direct auto --subme 9 --trellis 2 --partitions all --me umh --merange 32 --thread-input --no-dct-decimate --output "output" "input"

i haven't try the latest release but since all releases till 1183 freezes i son't think the new one will resolve anything.

Some additional infos might be a good idea,...
What OS are you using ?
Tried a current x264 (r1309) version?
How does your avisynth script look like?
How do your x264 settings look like?
...

nm
26th October 2009, 12:32
Is your source standard NTSC? You could be hitting the 2 GB memory limit of a 32-bit process with that AviSynth script and x264 with MBTree enabled. Check the memory usage of x264 after encoding for a while.

Try adding SetMemoryMax(128) to your script.

egrimisu
26th October 2009, 13:01
it's standard ntsc dvd. mem max usage of the x264 process when crashing was like 1.1gb.
i tryed a few days ago with setmemmorymax(512) and was the same problem.

Is your source standard NTSC? You could be hitting the 2 GB memory limit of a 32-bit process with that AviSynth script and x264 with MBTree enabled. Check the memory usage of x264 after encoding for a while.

Try adding SetMemoryMax(128) to your script.

LoRd_MuldeR
26th October 2009, 13:07
Did you try with a lower "--rc-lookahead" value? And more important: Can you track it down to a specific Avisynth script?

You should probably start with the most simple Avisynth script (only source filter) and see if encodes properly or not. Also you should run x264.exe from the command-line, to exclude any GUI problems.

Last but not least you may try another x264 build. Preferable one that doesn't contain any "experimental" patches...

Alf Bundy
26th October 2009, 13:32
MBtree ratecontrol is not the problem since he uses Jeeb's rev.1183 (latest update available with "Stable update server" in MeGUI).
And if he can succesfully encode the same script with Xvid, then I guess we can exclude AVIsynth being the source of his problem.

But latest x264 is rev.1309 now, and maybe this "problem" is already solved in newer revision ?

LoRd_MuldeR
26th October 2009, 13:39
MBtree ratecontrol is not the problem since he uses Jeeb's rev.1183 (latest update available with "Stable update server" in MeGUI).

There's absolutely no guarantee that this build is stable, especially since it uses unofficial patches. The location where you downloaded it doesn't make it any more or less stable ;)

Also MB-Tree RC is known to occupy a lot of memory, especially with high "--rc-lookahead" values.

So there is always a chance of running out of memory, especially with memory-intensive Avisynth scripts running in the same process as x264 with MB-Tree RC enabled...

And if he can succesfully encode the same script with Xvid, then I guess we can exclude AVIsynth being the source of his problem.

If x264 consumes more memory than Xvid, that may be the source of the problem and cause Avisyth to fail.

x264 itself won't fail with "out of memory" without telling you that! But if Avisynth or one of the Plugins run out of memory, then x264 cannot detect that.

But latest x264 is rev.1309 now, and maybe this "problem" is already solved in newer revision ?

I'm not aware of any fix for that kind of problem recently.

Anyway, trying an up-to-date and unpatched build (e.g. from x264.nl) should be the first thing to do, if you suspect x264 to fail...

Alf Bundy
26th October 2009, 14:44
Also MB-Tree RC is known to occupy a lot of memory, especially with high "--rc-lookahead" values.

So there is always a chance of running out of memory, especially with memory-intensive Avisynth scripts running in the same process as x264 with MB-Tree RC enabled...
All I was trying to say with my poor english is that MBtree ratecontrol was not yet included in rev1183.
It was commited in rev1197 according to the changelog.

LoRd_MuldeR
26th October 2009, 14:47
All I was trying to say with my poor english is that MBtree ratecontrol was not yet included in rev1183.
It was commited in rev1197 according to the changelog.

Oh, you are right. So the memory consumption of MB-Tree RC can't cause his problem. Which doesn't mean he couldn't run out of memory for another reason.

Anyway, the lack of MB-Tree RC in his build is an even more important reason to update ASAP ;)

egrimisu
26th October 2009, 16:12
since after updating x264 megui can't handle the new verrion (probably command diference) could you pleas how to open a avs to encode in command line?
thanks

Oh, you are right. So the memory consumption of MB-Tree RC can't cause his problem. Which doesn't mean he couldn't run out of memory for another reason.

Anyway, the lack of MB-Tree RC in his build is an even more important reason to update ASAP ;)

wyti
26th October 2009, 16:49
you only need to give the avs in input to x264 (he can handle them)

Ex:
x264 -o output.xxx input.avs
note : output extention can be .264, .mp4 or .mkv

Groucho2004
26th October 2009, 16:53
By the way,

the sistem is not OC'd

I7 920 @ 3.60GHz

:confused::confused:

LoRd_MuldeR
26th October 2009, 16:57
you only need to give the avs in input to x264 (he can handle them)

Ex:
x264 -o output.xxx input.avs
note : output extention can be .264, .mp4 or .mkv

He may also want to check out "x264.exe --help" for a suitable preset and append the desired RC mode. Which completes the commandline to:

x264.exe --preset <preset> --crf 18 -o output.mkv input.avs

Blue_MiSfit
26th October 2009, 17:49
1) Update x264, and use CLI for now. MeGUI is borked for the time being.

2) Use a clean script, no filters

Once you get a stable output, swap out MVDegrainMulti for equal syntax in MVTools2. This should be more stable.

Also, make sure you're using the most recent build of AviSynth 2.5.8 MT.

~MiSfit

egrimisu
26th October 2009, 17:54
Attached you'll find the error i get when trying to run x264 under cli.

Blue_MiSfit updating all now and be back with feedback
Thanks

Blue_MiSfit
26th October 2009, 18:08
Post attachments elsewhere (tons of free image hosting sites). Forum tend to take forever to get approved, if ever - and for good reason ;)

~MiSfit

egrimisu
26th October 2009, 21:14
as my english is bad ia strugle to understand simple things :)

is the next script what mvdegrainmulti lookslike in mvtools2?

Load MT plugin by TSP
LoadPlugin("MT.dll")
avisource("some.avi")
MT("""
super = MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 2, overlap=4)
backward_vec1 = super.MAnalyse(isb = true, delta = 1, overlap=4)
forward_vec1 = super.MAnalyse(isb = false, delta = 1, overlap=4)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
""",2) # two threads

Thanks in advance

1) Update x264, and use CLI for now. MeGUI is borked for the time being.

2) Use a clean script, no filters

Once you get a stable output, swap out MVDegrainMulti for equal syntax in MVTools2. This should be more stable.

Also, make sure you're using the most recent build of AviSynth 2.5.8 MT.

~MiSfit

egrimisu
26th October 2009, 21:23
x264 --profile high --crf12 --outupu misu.mkv 3.avs

x254.exe has stopped working :( as soon as i start it. the x64 version won't open the avs like the screenshot attached 2 post earlyer.

LoRd_MuldeR
26th October 2009, 21:30
x264 --profile high --crf12 --outupu misu.mkv 3.avs

It's "--output" instead of "--outupu" and there should by a white-space between "--crf" and the value.

Also you cannot use 64-Bit x264 with 32-Bit Avisynth, so you will have to install 64-Bit Avisynth to use 64-Bit x264.

Or you can use my tool here:
http://forum.doom9.org/showthread.php?t=144140

BTW: Can you tell us in which Module it crashed? Or even better run x264 in a debugger and do a backtrace?

Blue_MiSfit
26th October 2009, 23:49
Yes, those would very much help :D

~MiSfit

egrimisu
27th October 2009, 07:51
don't know realy how to debug or what piece of soft do i need to do that, but the windows error sais this(maybe this leps):
Problem signature:
Problem Event Name: APPCRASH
Application Name: x2642.exe
Application Version: 0.0.0.0
Application Timestamp: 4ae4d957
Fault Module Name: StackHash_abcc
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c00000fd
Exception Offset: 779dfe34
OS Version: 6.1.7201.2.0.0.256.1
Locale ID: 1033
Additional Information 1: abcc
Additional Information 2: abcc8f7853b48d9807d6d51eb1fa5df9
Additional Information 3: abcc
Additional Information 4: abcc8f7853b48d9807d6d51eb1fa5df9

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt


It's "--output" instead of "--outupu" and there should by a white-space between "--crf" and the value.

Also you cannot use 64-Bit x264 with 32-Bit Avisynth, so you will have to install 64-Bit Avisynth to use 64-Bit x264.

Or you can use my tool here:
http://forum.doom9.org/showthread.php?t=144140

BTW: Can you tell us in which Module it crashed? Or even better run x264 in a debugger and do a backtrace?

egrimisu
28th October 2009, 10:02
i x264 1309 x32 undre cli freezes but x64 version with the tool work's fine, to bad it does not have a queue. Thanks. Till megui get's fixed this is more than perfect.