PDA

View Full Version : x264 crashing when psy-rd specified


Sagekilla
12th March 2009, 01:17
Okay, the latest build (1027) off x264.nl seems to crash every time I specify psy-rd.

If I use the following command line, it works fine:

x264 --pass 1 --keyint 1000 --level 4.1 --crf 18 --ref 6 --mixed-refs --b-adapt 2 --bframes 4 --weightb --b-pyramid --me umh --subme 9 --trellis 2 --8x8dct --aq-strength 0.7 --threads auto --progress --output "video.264" --stats "stats.log" "source.avs"


The following one (With just --psy-rd 0:0 specified!) crashes

x264 --pass 1 --keyint 1000 --level 4.1 --crf 18 --ref 6 --mixed-refs --b-adapt 2 --bframes 4 --weightb --b-pyramid --me umh --subme 9 --trellis 2 --8x8dct --aq-strength 0.7 --psy-rd 0:0 --threads auto --progress --output "video.264" --stats "stats.log" "source.avs"


Any thoughts on why specifying something for --psy-rd would cause it to crash?


Edit: If I don't change anything for psy-rd (I.e. let x264 default to --psy-rd 1:0), the encode runs fine. As soon as I tell it -ANYTHING- for psy-rd, I get crashes :(

Dark Shikari
12th March 2009, 01:21
It crashes even if you specify --psy-rd 1:0 ? Can you post a backtrace of the crash, along with which type of exception it is (SIGSEGV, SIGILL, etc)?

Sagekilla
12th March 2009, 01:22
Yes, I just tried this with --psy-rd 1:0 and I got a crash.

LoRd_MuldeR
12th March 2009, 01:24
Your commandline is wrong. The argument for "--trellis" is missing. After correction, it works fine for me (using the latest build from x264.nl).

I tried "--psy-rd 0:0" as well as "--psy-rd 1:0". Does it happen with all sources for you or only with a specific one?

Sagekilla
12th March 2009, 01:27
Sorry, that was a mistype on my part. Both command lines say "--trellis 2". I'm writing this on my laptop (Didn't copy and paste)

Interesting oddity here: I have two machines with identical encoding setups.

Both have revision 1027, use Avisynth 2.5.8, same exact avisynth plugins, same script and input. Both decode using CoreAVC 1.9 through DSS with hardware acceleration disabled. No difference between my command line settings either, but my laptop runs with --psy-rd 0.7:0.7 fine. My desktop doesn't!


Edit: Will try another source. The one I just tested was Iron Man (Blu-ray) and I have the same copy on both my machines.

LoRd_MuldeR
12th March 2009, 01:29
Time to load up your debugger and find out where it does crash ;)

Sagekilla
12th March 2009, 01:30
Oh joy. What should I do for windows (Vista, 32-bit)?

Also, it's not source specific. I tried with a different file and it showed same behavior.

LoRd_MuldeR
12th March 2009, 01:40
Oh joy. What should I do for windows (Vista, 32-bit)?

MinGW and GDB should work on Vista ;)

But first you may want to check whether it does crash with Skystrife's build:
http://forum.doom9.org/showpost.php?p=1260054&postcount=1750

--[EDIT]--

Here's a debug build:
http://www.mediafire.com/file/01yludtzmyj/libx264-r1127-gcc345-debug.7z

GDB can be found here:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=594520

Sagekilla
12th March 2009, 01:45
Just tested his x264.1127M.x86 and it crashed on me too for --psy-rd 0:0.

I'll install MinGW and GDB now.

Edit: What should I be downloading off mingw.org? I just went to downloads but am I supposed to be downloading the dev tools or something else?

LoRd_MuldeR
12th March 2009, 01:49
Edit: What should I be downloading off mingw.org? I just went to downloads but am I supposed to be downloading the dev tools or something else?

See the EDIT in my previous post please. You run it like this:

gdb.exe --args x264.exe --crf 22 --progress --output "video.264" "source.avs"
(gdb) run

Sagekilla
12th March 2009, 01:57
Here's the output:


(gdb) run
Starting program: C:\Windows\system32/x264_debug.exe --pass 1 --keyint 1000 --le
vel 4.1 --crf 19 --ref 6 --mixed-refs --b-adapt 2 --bframes 4 --weightb --b-pyra
mid --me umh --subme 9 --trellis 2 --8x8dct --psy-rd 1:0 --aq-strength 0.7 --thr
eads auto --progress --output video.264 --stats stats.log source.avs
[New thread 3428.0x164]
warning: DllMain: hModule=0x01da0000, ulReason=1, lpReserved=0x00000000, gRefCnt
= 0

warning: DllGetClassObject() CLSID: CAVIFileSynth

warning: 003C31F0->CAVIFileSynth::CAVIFileSynth()

warning: 003C31F0->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1

warning: 003C31F0->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-0000
00000046} (IClassFactory)

warning: 003C31F0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 003C31F0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: DllGetClassObject() result=0x0, object=003C31F8

warning: 003C31F0->CAVIFileSynth::CreateInstance()

warning: 003C33B0->CAVIFileSynth::CAVIFileSynth()

warning: 003C33B0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1

warning: 003C33B0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 003C33B0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 003C33B0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 003C31F0->CAVIFileSynth::CreateInstance() result=0x0, object=003C33B0

warning: 003C33B0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 003C33B0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 003C31F0->CAVIFileSynth::Release() gRefCnt=1, m_refs=0

warning: 003C31F0->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1

warning: 003C33B0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 003C33B0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 003C33B0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 003C33B0->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-0000
00000046} (unsupported!)

warning: 003C33B0->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-0000
00000046} (IPersistFile)

warning: 003C33B0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 003C33B0->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-0000
00000046} (IAVIFile)

warning: 003C33B0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3

warning: 003C33B0->CAVIFileSynth::Load("source.avs", 0x0)

warning: 003C33B0->CAVIFileSynth::Release() gRefCnt=2, m_refs=2

warning: 003C33B0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 003C33B0->CAVIFileSynth::GetStream(*, 73646976(vids), 0)

dbxread.c:1336: internal-error: Section index is uninitialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

LoRd_MuldeR
12th March 2009, 02:00
Ehm, that looks like a problem with GDB itself. I once had that too on my system, but I thought updating GDB has resolved it...

Sagekilla
12th March 2009, 02:02
Yeah, I tried running a second time without --psy-rd 1:0 (As well as running the debug build as a regular encoder with --psy-rd 1:0 and without it to confirm my sanity). Gave same crash regardless of whether I had --psy-rd specified under gdb :(

Dark Shikari
12th March 2009, 02:04
If you're using avisynth input, you generally want to empty your plugins folder (no autoloading) before using gdb.

LoRd_MuldeR
12th March 2009, 02:07
Yeah, I tried running a second time without --psy-rd 1:0 (As well as running the debug build as a regular encoder with --psy-rd 1:0 and without it to confirm my sanity). Gave same crash regardless of whether I had --psy-rd specified under gdb :(

Naa, if the debugged application crashes then it looks different in GDB. What you posted is clearly a problem with DGB itself :o

Sagekilla
12th March 2009, 02:08
Alright. I renamed my plugins folder and used LoadPlugin("...") to get access to DirectShowSource()

I got the following output. It seems very odd I got a segfault from CoreAVC since I'm running the same exact thing (with same settings) on my laptop and it's encoding with CoreAVC fine!

(gdb) run
Starting program: C:\Windows\system32/x264_debug.exe --pass 1 --keyint 1000 --l
vel 4.1 --crf 19 --ref 6 --mixed-refs --b-adapt 2 --bframes 4 --weightb --b-pyr
mid --me umh --subme 9 --trellis 2 --8x8dct --psy-rd 1:0 --aq-strength 0.7 --th
eads auto --progress --output video.264 --stats stats.log source.avs
[New thread 1520.0xe24]
warning: DllMain: hModule=0x01ef0000, ulReason=1, lpReserved=0x00000000, gRefCn
= 0

warning: DllGetClassObject() CLSID: CAVIFileSynth

warning: 002531F0->CAVIFileSynth::CAVIFileSynth()

warning: 002531F0->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1

warning: 002531F0->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-000
00000046} (IClassFactory)

warning: 002531F0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 002531F0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: DllGetClassObject() result=0x0, object=002531F8

warning: 002531F0->CAVIFileSynth::CreateInstance()

warning: 002533B0->CAVIFileSynth::CAVIFileSynth()

warning: 002533B0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1

warning: 002533B0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-000
00000046} (IUnknown)

warning: 002533B0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 002533B0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 002531F0->CAVIFileSynth::CreateInstance() result=0x0, object=002533B0

warning: 002533B0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 002533B0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 002531F0->CAVIFileSynth::Release() gRefCnt=1, m_refs=0

warning: 002531F0->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1

warning: 002533B0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-000
00000046} (IUnknown)

warning: 002533B0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 002533B0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 002533B0->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-000
00000046} (unsupported!)

warning: 002533B0->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-000
00000046} (IPersistFile)

warning: 002533B0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 002533B0->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-000
00000046} (IAVIFile)

warning: 002533B0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3

warning: 002533B0->CAVIFileSynth::Load("source.avs", 0x0)

warning: 002533B0->CAVIFileSynth::Release() gRefCnt=2, m_refs=2

warning: 002533B0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 002533B0->CAVIFileSynth::GetStream(*, 73646976(vids), 0)

[New thread 1520.0x950]
warning: DllMain: hModule=0x01ef0000, ulReason=2, lpReserved=0x00000000, gRefCn
= 1

[New thread 1520.0x344]
warning: DllMain: hModule=0x01ef0000, ulReason=2, lpReserved=0x00000000, gRefCn
= 1

[New thread 1520.0xa1c]
warning: DllMain: hModule=0x01ef0000, ulReason=2, lpReserved=0x00000000, gRefCn
= 1


Program received signal SIGSEGV, Segmentation fault.
0x0390f044 in DllCanUnloadNow () from E:\Tools\CoreAVC Pro\CoreAVCDecoder.ax

LoRd_MuldeR
12th March 2009, 02:11
Program received signal SIGSEGV, Segmentation fault.

That looks better. Now type "bt" and press <Enter> when that happens...

Sagekilla
12th March 2009, 02:12
Entering bt gives this:


#0 0x03bbf044 in DllCanUnloadNow ()
from E:\Tools\CoreAVC Pro\CoreAVCDecoder.ax
#1 0x0022d31c in ?? ()
#2 0x03bc000c in DllCanUnloadNow ()
from E:\Tools\CoreAVC Pro\CoreAVCDecoder.ax
#3 0x77cbe1c4 in ntdll!RtlDefaultNpAcl () from C:\Windows\system32\ntdll.dll
#4 0x77cac4c2 in ntdll!RtlSeekMemoryStream ()
from C:\Windows\system32\ntdll.dll
#5 0x77cac673 in ntdll!RtlSeekMemoryStream ()
from C:\Windows\system32\ntdll.dll
#6 0x77ca7a52 in ntdll!LdrQueryImageFileKeyOption ()
from C:\Windows\system32\ntdll.dll
#7 0x00000000 in ?? ()

kemuri-_9
12th March 2009, 02:14
what did you do to CoreAVC to break it?
(obviously not an x264 problem)

Sagekilla
12th March 2009, 02:17
Nothing. I installed CoreAVC Pro as-is. My "Configure" dialog has all the defaults. Checked: Agressive Deint / Crop 1088 to 1080 / Preferred Decoder / Use Tray Icon / Auto Detect Input and Output levels / Hardware Deinterlacing. Unchecked: Force VMR AR correction / Prefer CUDA acceleration

On my laptop I have the same exact settings for CoreAVC.



That doesn't make any sense that x264 would crash when I have --psy-rd specified, but run fine if I don't have it present.

LoRd_MuldeR
12th March 2009, 02:18
what did you do to CoreAVC to break it?
(obviously not an x264 problem)

But how can CoreAVC fail with "--psy-rd" specified and work fine without? :confused:

It's at least possible that something in x264 corrupts memory and causes CoreAVC to crash...

Sagekilla
12th March 2009, 02:19
Read my mind LoRd_MuldeR ;) Just edited my last post to include that sentiment.

It also doesn't explain why my laptop (which has the same exact encoding setup) can encode perfectly fine.

kemuri-_9
12th March 2009, 02:21
at what frame does it crash?

try using avs2yuv to convert the avs to a y4m and encoding with the same params from the y4m to see if it crashes at the same point.

Sagekilla
12th March 2009, 02:24
It crashes before the encoding starts. I don't get a single frame encoded at all. Just logged onto IRC if it helps anyone to talk there.


Edit: If I encode from raw y4m file, it runs perfectly fine.

Sagekilla
12th March 2009, 02:37
Just edited above post if anyone knows what's going on :(

kemuri-_9
12th March 2009, 03:08
sounds like x264 is aggravating a problem with coreavc/avisynth with psy-rd on to where it's causing a crash...

looks like it's need to redirect this to the avs and coreavc guys for their takes on it.

LoRd_MuldeR
12th March 2009, 03:17
Since it even happens when passing the default values "--psy-rd 1:0", I'd suspect the command-line parsing code...

Sagekilla
12th March 2009, 03:19
But why would this issue show up only on my desktop PC? My Laptop runs the same decoder, plugins, avisynth version, and x264 revision, yet it doesn't exhibit this issue at all.

LoRd_MuldeR
12th March 2009, 03:35
But why would this issue show up only on my desktop PC? My Laptop runs the same decoder, plugins, avisynth version, and x264 revision, yet it doesn't exhibit this issue at all.

Different CPU? Different OS? Even injected DLL's?

:confused:

Sagekilla
12th March 2009, 03:42
Well, I do have Opteron (Desktop) vs C2D (Laptop), and Vista Business (Desktop) vs Vista Home Premium (Laptop). Still. I don't see how any of those could significantly change things enough to make this crash on my desktop.

It's also worth noting that a few months back when I had my system running XP still, I was experiencing instant crashes on x264 back then too. Same solution turned out being removing --psy-rd :(

I'd almost forgotten about the issue now since I resorted to using my laptop for encoding (Due to the crashes, as well as the fact that my desktop simply -stopped- working)

burfadel
12th March 2009, 04:04
Just curious, why is --pass 1 specified and also crf?

LoRd_MuldeR
12th March 2009, 04:06
Just curious, why is --pass 1 specified and also crf?

Because CRF mode can be used for the first pass of a 2-Pass encode (instead of ABR mode).

Sagekilla
12th March 2009, 04:08
--pass 1 was specified so I can output a stats file. I usually like to encode then check the stats for no arbitrary reason beyond checking how x264 does it's job allocating bits.

It can be used as a stats file for --pass 2 like LoRd_MuldeR said but I stick with --crf ;)

Sagekilla
12th March 2009, 04:22
I just ran x264 with directshowsource as usual, but using libavcodec (through ffdshow) as my decoder. I can't run x264 still; it always crashes before encoding even begins. But when run under gdb, I seem to get it able to keep on encoding.

Here's the (partial) gdb output. It seems to run fine but keeps throwing warnings.


(gdb) run
Starting program: C:\Windows\system32/x264_debug.exe --pass 1 --keyint 1000 --le
vel 4.1 --crf 19 --ref 6 --mixed-refs --b-adapt 2 --bframes 4 --weightb --b-pyra
mid --me umh --subme 9 --trellis 2 --8x8dct --psy-rd 0.7:0.7 --aq-strength 0.7 -
-threads auto --progress --output video.264 --stats stats.log source.avs
[New thread 916.0xcd0]
warning: DllMain: hModule=0x01fc0000, ulReason=1, lpReserved=0x00000000, gRefCnt
= 0

warning: DllGetClassObject() CLSID: CAVIFileSynth

warning: 00343200->CAVIFileSynth::CAVIFileSynth()

warning: 00343200->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1

warning: 00343200->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-0000
00000046} (IClassFactory)

warning: 00343200->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 00343200->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: DllGetClassObject() result=0x0, object=00343208

warning: 00343200->CAVIFileSynth::CreateInstance()

warning: 003433C0->CAVIFileSynth::CAVIFileSynth()

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1

warning: 003433C0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 003433C0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 00343200->CAVIFileSynth::CreateInstance() result=0x0, object=003433C0

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 003433C0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 00343200->CAVIFileSynth::Release() gRefCnt=1, m_refs=0

warning: 00343200->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1

warning: 003433C0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 003433C0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 003433C0->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-0000
00000046} (unsupported!)

warning: 003433C0->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-0000
00000046} (IPersistFile)

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 003433C0->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-0000
00000046} (IAVIFile)

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3

warning: 003433C0->CAVIFileSynth::Load("source.avs", 0x0)

warning: 003433C0->CAVIFileSynth::Release() gRefCnt=2, m_refs=2

warning: 003433C0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 003433C0->CAVIFileSynth::GetStream(*, 73646976(vids), 0)

[New thread 916.0xbd4]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0xbe8]
[New thread 916.0xb94]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0xeb4]
[New thread 916.0xa40]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0xf24]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0x1bc]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0xe8c]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 1

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0x9d4]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0x324]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 1

[New thread 916.0x9f4]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 1

warning: 01DD0BE0->CAVIStreamSynth(video)

warning: 01DD0BE0->CAVIStreamSynth::AddRef() (video) gRefCnt=2, m_refs=1

warning: 003433C0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 003433C0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 01DD0BE0->CAVIStreamSynth::Info(0022F8A8, 204) (video)

avis [info]: 1280x544 @ 23.98 fps (320 frames)
warning: 01DD0BE0->CAVIStreamSynth::Info(0022F898, 204) (video)

x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.1
x264 [info]: version: core 66 r1127M 8d82fec
x264 [info]: compiler: gcc 3.4.5 (mingw-vista special r3)
x264 [info]: options: cabac=1 ref=6 deblock=1:0:0 analyse=0x3:0x113 me=umh subme
=9 psy_rd=0.7:0.7 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 d
eadzone=21,11 chroma_qp_offset=-4 threads=3 nr=0 decimate=1 mbaff=0 bframes=4 b_
pyramid=1 b_adapt=2 b_bias=0 direct=1 wpredb=1 keyint=1000 keyint_min=25 scenecu
t=40 rc=crf crf=19.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_rati
o=1.30 aq=1:0.70
warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0xef4]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0x628]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0x4e4]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0x1c8]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0xd34].14 fps, 0.00 kb/s, eta 0:01:01
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0x544]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

warning: DllMain: hModule=0x01fc0000, ulReason=3, lpReserved=0x00000000, gRefCnt
= 2

[New thread 916.0xd60]
warning: DllMain: hModule=0x01fc0000, ulReason=2, lpReserved=0x00000000, gRefCnt
= 2

LoRd_MuldeR
12th March 2009, 04:30
I think this is x264 continuously creating new "worker" threads for each frame to encode. Also Avisynth writes a lot of warnings to the debugger log...

Sagekilla
12th March 2009, 04:33
Yes, I saw the new threads being spawned by x264. I thought that was more or less normal. What's extremely odd to me is that running x264 through gdb gives me no issues, but running it through regular CLI gives me a crash.

Heisenbug perhaps?


Edit: I can confirm that this isn't an issue with CoreAVC. I just tried decoding another Blu-ray (Serenity, VC-1) using DirectShowSource() and it failed in the same way. It would only encode if run through gdb.

Edit 2: This seems to be localized to DSS(). If I try loading using Avisource("..") on a lagarith encoded copy of ED, the movie encodes fine. Once I try DSS() on it, I get a crash.

Edit 3: Even less sense to be made. It seems like it depends on the length of my command line. If I remove --pass 1 and --stats "stats.log" but keep --psy-rd 0.7:0.7 I run fine. If I add in --nr 0 and --deblock 0:0 next (Meaning without --pass 1 and --stats "stats.log" but with --psy-rd 0.7:0.7) I get crash.


More notes: If I use DirectShowSource() I get the crash if my command line is too long. But if I use avisource(), I can use a command line that's as big as I want.

Sharktooth
12th March 2009, 15:20
that's called spirit possession.
or maybe something hardware related. what about running some memory/cpu/system burn-in tests?

roozhou
12th March 2009, 18:33
Why not try encoding from raw YUV or Y4M files?

Sagekilla
12th March 2009, 18:36
Because I'm working from a blu-ray source. Converting each blu-ray I rip to y4m would require 32 MB per second of video at 720p.. That wouldn't be time or space efficient at all, when you consider that's over 200 GB just for a 2 hour video (I don't even have that much storage available on a single drive).

LoRd_MuldeR
12th March 2009, 19:06
You know that avs2yuv can write to STDOUT and x264 can read "raw" YUV data from STDIN? So there's no need for a temporary file, you can use a pipe...

roozhou
12th March 2009, 19:31
You know that avs2yuv can write to STDOUT and x264 can read raw "yuv" data from STDIN? So there's no need for a temporary file, you can use a pipe...

Official x264 build cannot read y4m from STDIN.

LoRd_MuldeR
12th March 2009, 19:34
Official x264 build cannot read y4m from STDIN.

What's the difference to "raw" YV12 data, which does work?

kemuri-_9
12th March 2009, 19:35
Official x264 build cannot read y4m from STDIN.

it can read yuv from stdin and avs2yuv can pipe yuv with the -raw option.

@LoRd_MuldeR
y4m contains a header about the data, i.e. width, height, and fps, where as raw yuv does not (why x264 needs the resolution of the video when using it)

LoRd_MuldeR
12th March 2009, 19:38
@LoRd_MuldeR
y4m contains a header about the data, i.e. width, height, and fps, where as raw yuv does not (why x264 needs the resolution of the video when using it)

I see ;)

Well, avs2yuv can put out the framerate and the resolution, so you can parse that information and pass it to x264.

That's how I do it in my tool:
http://forum.doom9.org/showthread.php?t=144140

roozhou
12th March 2009, 19:58
it can read yuv from stdin and avs2yuv can pipe yuv with the -raw option.


:stupid: I forgot avs2yuv has -raw option.

Sagekilla
12th March 2009, 20:01
Well, I'm not so much concerned with getting it working any more (It seems to work fine if my CLI isn't too long) My main concern now is trying to figure out what's causing x264 to crash when the command line is too long.

If it's a bug in the parser, avisynth code, or otherwise, it'd be nice to have it fixed.

roozhou
12th March 2009, 20:10
But how can CoreAVC fail with "--psy-rd" specified and work fine without? :confused:

It's at least possible that something in x264 corrupts memory and causes CoreAVC to crash...

Well this is very similar to crashes with my dshow x264 tool.

Some input file would cause x264 crash when the DirectShow graph is being rendered. It crashes in ntdll.dll so i cannot track. The weired thing is if you rename the input file, or add whatever more parameters to the cmdline, or reorder your parameters, it no longer crashes. Sometimes even white spaces will work. The more weired thing is running x264 in cmd.exe or using CreateProcess will cause crash but running in bash/sh won't.

lexor
12th March 2009, 21:23
roozhou, sounds more like a problem with the win-zone patch then, since that's the one that actually interacts with the param string. Does unpatched git build exhibit the same issue?

kemuri-_9
12th March 2009, 21:29
roozhou, sounds more like a problem with the win-zone patch then, since that's the one that actually interacts with the param string. Does unpatched git build exhibit the same issue?

the win zones patch, as the name implies, only fixes zones cli parsing on windows where there is no strtok_r...
if --zone(s) isn't on the command line, then it never sees the affected code section.

Sagekilla
12th March 2009, 22:26
For the record, I -do- run the unpatched GIT build. I tried three different (debug, git, skystrife) builds and get this crash.

roozhou
13th March 2009, 03:21
For the record, I -do- run the unpatched GIT build. I tried three different (debug, git, skystrife) builds and get this crash.

Please try running x264 in the following ways and see whether it crashes again

1) Make "input.avs" the first parameter
2) Add or delete some irrelevant parameters to the cmdline (e.g. --no-psnr)
3) Add some trailing whitespace to your cmdline
4) Run it in MinGW's bash/sh/rxvt