x264 not recognizing relative paths to the exe

[qyot27]

I've noticed recently that I can no longer run x264 using my system path variables, even if the path is set to x264's folder in megui's tools directory, or if x264.exe is in C:\WINDOWS. I can manage to run it if I specify the entire path to x264.exe on my cli input, but that also requires me to specify the full path to my input and output files (if I keep x264 in megui's tools directory, anyway, and don't want to copy the video files there).

I even tried to copy x264.exe to the same directory my files were in and run it from there, and it still didn't work, unless I specified the full path to the exe (which, seeing as I was already in that directory, should be entirely unnecessary). Is this an issue with x264, or with Windows? None of my other CLI apps behave this way, which makes me think it's an x264-centric problem (or at the very least, an issue with the specific x264 builds that are in megui's update pipeline - which, considering that the xvid_encraw builds that I get the same way work fine, I don't think it's a megui issue either).

I'm currently at rev1074 (Skystrife), if that information is pertinent. I've noticed this behavior when I've tried it on previous builds for about the last month or so, though. I don't know how far back this goes, though, as I had no reason to use x264 for about a four or five month stretch between June and October/November, and can't remember if it was there when I had to do some encoding in early November.

[buzzqw]

check the path variables in your windows system

make sure you have at least the system32 folder on path

BHH

[smok3]

from command line run 'path' with no parameters, i get;

PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\Program Files\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Intel\DMIX;T:\path

(and my x264 is in T:\path for example...)

[qyot27]

This is the readout from path (line separation mine):
PATH=c:\program files\imagemagick-6.4.2-q8;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
C:\Program Files\QuickTime\QTSystem\;
C:\Program Files\DGPulldown\;
C:\Program Files\HC023\;
C:\Program Files\potrace-1.8.win32-i386\;
C:\Program Files\toolame-02l\;
C:\Program Files\mplayer\;
C:\Program Files\Lame\;
C:\Program Files\mp4muxer\;
C:\Program Files\megui\tools\xvid_encraw\;
C:\Program Files\FLAC\;
C:\Program Files\MKVtoolnix

I'd had C:\Program Files\megui\tools\x264\ on there as well, but considering it wasn't working, I took it off. I'm fairly certain this is an issue with the x264 build, because as you can see, the other path variables are there and as I'd said, those CLI apps all work fine. And for older builds of x264, if I had its megui tools directory set or the exe itself was in C:\WINDOWS, it also worked fine. At least, until a month or so ago.

[kemuri-_9]

most of the time, windows doesn't update the PATH environment variable (or most environment variables for that matter) when edited until the system is rebooted...

so any edits you do to it usually won't be reflected in the system until the next reboot.

[qyot27]

most of the time, windows doesn't update the PATH environment variable (or most environment variables for that matter) when edited until the system is rebooted...

so any edits you do to it usually won't be reflected in the system until the next reboot.
That's strange, because most of the time when I would add a variable it'd recognize it right away. Wouldn't hurt to try, but seeing as how C:\WINDOWS has always been a variable and wavi, aften, mplex, and mp4box are all there and work flawlessly, why wouldn't x264 if it's in there too? And, let's say I've copied x264.exe to C:\Documents, and in the Command Prompt I have cd-ed into C:\Documents or simply opened the prompt there with the corresponding XP Powertoy, I cannot run
C:\Documents>x264 [opts]
because it'll exit without so much as a warning after seeming to hang for a half a minute or so, but I can run
C:\Documents>"C:\Documents\x264.exe" [opts]
and it'll work perfectly. Because that behavior is what I'm most concerned about, not the concept of editing my paths. I just figure it has to do with x264's path recognition.

[kemuri-_9]

so you try 'x264' and it doesn't work...
but what about 'x264.exe' instead of the absolute path...
does that work?

sounds like there might be some resolution issues going on in your windows.
i use x264 from a directory I added to my PATH variable as well...

[Shinigami-Sama]

most of the time, windows doesn't update the PATH environment variable (or most environment variables for that matter) when edited until the system is rebooted...

so any edits you do to it usually won't be reflected in the system until the next reboot.

if you edit it with regedit it usually updates right away though
plus its a lot faster going through a million windows...



[edit]
[QUOTE=qyot27;1236339]I cannot run
C:\Documents>x264 [opts]
./x264 [opts]

try that

[qyot27]

so you try 'x264' and it doesn't work...
but what about 'x264.exe' instead of the absolute path...
does that work?

sounds like there might be some resolution issues going on in your windows.
i use x264 from a directory I added to my PATH variable as well...
The .exe being there doesn't make a difference. I actually have it defined as x264.exe in the notes I copy and paste from when doing the encodes - I just didn't bother to type it out since in my experience Windows generally ignores the extension of a CLI app anyway. But I did try it both ways and it still fails.

One thing I should have mentioned in my first post is that this seems to be very particularly about x264 encoding the material. If I just type in x264 or x264 --help, it reports back to me properly. But if I try to encode something, it just hangs unless I have the full path to the executable.

./x264 [opts]

try that
Is ./ even valid on Windows? I've only ever seen that notation when using Linux or OSX.

Seems that it isn't, considering that attempting to do so results in:
'.' is not recognized as an internal or external command,
operable program or batch file.





After doing a tad bit more snooping over x264's revision numbers, I now actually think this is a Windows issue. Reason being, I went and downloaded different revisions (1016, 950, 900, and 805) that were from when this still worked fine from x264.nl's archive and even those now exhibit this same weird behavior.

[talen9]

Maybe I'm being stupid but ... have you tried putting the pthreadGC2.dll file in the same folder where you put x264.exe? :)

[kemuri-_9]

Maybe I'm being stupid but ... have you tried putting the pthreadGC2.dll file in the same folder where you put x264.exe? :)

you only need pthreadGC2.dll if x264 was built (using gcc) using a shared pthreads library instead of a static library.
x264.nl builds use a static pthread library and so do the ones megui uses (excluding mishaps)

[qyot27]

After some more testing, I think I've narrowed it down to the source of the problem. It isn't Windows, it's something with ffdshow (although I have no idea what). I discovered this because originally, my encoding method is to use an ffvhuff (YV12) AVI and serve that into x264 with AVISource. Because it's the VFW, the tray icons never showed up anyway. In the tests, I was using DirectShowSource instead, and while Haali's tray icon appeared (the test file was an MKV), neither ffdshow's nor VSFilter's icons showed up. So I tried to use FFmpegSource, and lo and behold, the weird behavior was gone - x264 recognized the paths just fine, and didn't hang or anything.

Now, looking around in ffdshow's configuration dialogs (for both DirectShow and VFW) I couldn't find anything to use to force it to behave, so I'm at a loss here. I've not updated ffdshow to rev2615 yet, so I'll see if this persists into that version as well. As a rule of thumb, I use clsid's generic svn builds. I don't know if this would be resolved by switching to one of xxl's builds or if this is intrinsic to ffdshow, period, and not something related to a specific build version.

As another test, though, I encoded a clip using Lagarith, and used AVISource to serve it to x264 - and it worked fine (although using DirectShowSource with the Lagarith clip didn't and left me with stranger error messages about DIB not being supported and not being able to find the script).

[recover]

most of the time, windows doesn't update the PATH environment variable (or most environment variables for that matter) when edited until the system is rebooted...

so any edits you do to it usually won't be reflected in the system until the next reboot.

Programs usually doesn't automatically update their environment variables. All you need to do is restart cmd, no need to reboot.

[qyot27]

As a test, I downloaded some of the old November 2008 builds of ffdshow and tested them to find out when exactly the problem arose.

I've been able to narrow it down to a gap between November 14th and November 23rd, and in one of the 25 revisions therein.

ffdshow_rev2322_20081114_clsid.exe works fine
ffdshow_rev2347_20081123_clsid.exe displays the relative paths issue


My only real fear in this is that the change happened in ffmpeg itself, rather than in the ffdshow implementation.

[Esurnir]

After some more testing, I think I've narrowed it down to the source of the problem. It isn't Windows, it's something with ffdshow (although I have no idea what). I discovered this because originally, my encoding method is to use an ffvhuff (YV12) AVI and serve that into x264 with AVISource. Because it's the VFW, the tray icons never showed up anyway. In the tests, I was using DirectShowSource instead, and while Haali's tray icon appeared (the test file was an MKV), neither ffdshow's nor VSFilter's icons showed up. So I tried to use FFmpegSource, and lo and behold, the weird behavior was gone - x264 recognized the paths just fine, and didn't hang or anything.

Now, looking around in ffdshow's configuration dialogs (for both DirectShow and VFW) I couldn't find anything to use to force it to behave, so I'm at a loss here. I've not updated ffdshow to rev2615 yet, so I'll see if this persists into that version as well. As a rule of thumb, I use clsid's generic svn builds. I don't know if this would be resolved by switching to one of xxl's builds or if this is intrinsic to ffdshow, period, and not something related to a specific build version.

As another test, though, I encoded a clip using Lagarith, and used AVISource to serve it to x264 - and it worked fine (although using DirectShowSource with the Lagarith clip didn't and left me with stranger error messages about DIB not being supported and not being able to find the script).
By default the VFW decoder don't decode huffyuv. You need to go to the VFW settings, on top there is decoder tab, go to codec and activate the huffyuv one

[qyot27]

By default the VFW decoder don't decode huffyuv. You need to go to the VFW settings, on top there is decoder tab, go to codec and activate the huffyuv one
Yes, I know that; I've known that ever since I started using it to encode YV12 and adaptive huffman table-enabled HuffYUV files. I specified I was using ffvhuff - which means that I also know that ffdshow is the only DS/VFW based solution that can decode them. And if I'm using ffdshow to encode said files, I also know to make sure it's decoding them as well.

The scripts work - that was never the issue here. Using AVISource with said files is fine in VirtualDubMod, WMP6.4, MPC, or any other program that accepts AVS input. Except x264 when I don't specify the full path to x264.exe. And I don't have a problem with using relative paths to the exe if I use a two-month old version of ffdshow - but I do if I use any ffdshow revision newer than that. As I said, x264 will work with newer versions of ffdshow if I type out all that stuff I shouldn't have to, which shoots the idea of ffdshow's Huffyuv VFW decoder not being set to libavcodec in the foot.

Forgive me for being terse about it, but several of the other posts I've made in this thread already signal the fact that the VFW decoder is set up correctly.

[haruhiko_yamagata]

I can't reproduce. I can decode huffYUV using ffdshow-VFW (AVISource), and encode using x264 in megui.
I removed megui.exe and x264.exe from "Use ffdshow only in:" in the DirectShow control/video page, it doesn't change anything (it shouldn't effect VFW).
The avs file is located in the same directory as input and output video files and no full path is given in the AVISource option.
What else should I try?

[qyot27]

How are you calling x264, though? I have it set up so that no matter what directory I'm in, all I have to do is call x264. The paths don't have to do with the script, it has to do with x264 itself. It'll only work if I tell the system exactly where x264.exe is.

With the Command Prompt, I'm in the directory my files and script are in. So since x264 is in my system path, I do
x264.exe --crf 18.0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock 1:1 --subme 9 --trellis 2 --partitions all --8x8dct --scenecut 100 --threads auto --thread-input --sar 1:1 --aud --progress --no-dct-decimate --no-psnr --no-ssim --output "output.mp4" "input.avs"
but that doesn't work. However, this does:
"C:\Program Files\megui\tools\x264\x264.exe" --crf 18.0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock 1:1 --subme 9 --trellis 2 --partitions all --8x8dct --scenecut 100 --threads auto --thread-input --sar 1:1 --aud --progress --no-dct-decimate --no-psnr --no-ssim --output "output.mp4" "input.avs"
(yes, I know the settings are insane; I tried it with others that were more sensible and the issue is still there)


In both cases the script used is exactly the same and works fine in VirtualDub, Windows Media Player, etc. Even other CLI apps like xvid_encraw recognize it and go ahead with the encoding. For whatever reason, x264 or Windows itself isn't letting ffdshow decode the video if it doesn't know exactly where x264.exe is, even though that information is in Windows' PATH variables.

This is only the case if I use an ffdshow-tryouts revision newer than November 14th, 2008 - if I use the build from November 14th, 2008 or one older than that, then it recognizes where x264 is according to the PATH variable and the first CLI call I listed works. Because of my computer's age, I figured it best to just use clsid's generic svn builds, rather than the icl10 builds or any of the other specialized ones. If there's some sort of log that I can post to show where this is stemming from that'd be great.


In all cases if I use x264 through megui it works (this is because megui supplies the full path to x264.exe every time), but I'm trying to run it directly from the command line, without using megui.

[haruhiko_yamagata]

Thanks for explanation.
I have tried command line, it works for me.
I still can't reproduce.
Around 20081123, I have change a lot about string manipulation. It should be related...

[Trahald]

http://img187.imageshack.us/img187/9886/cmddk9.jpg (http://www.imagehosting.com/)
@qyot27
Please do not self diagnose the issue. If you already know what is wrong there is no need to make a post. Just because your script works other places doesnt mean it isnt the problem (im not saying it is either.) We need all variables to diagnose (hopefully) an issue. Also dont edit what you paste and tell us what it should be ( your system path for example), this all helps in figuring out a problem especially when it cant be duplicated.

the above picture is a skystrife build. i was also unable to duplicate the issue.

[qyot27]

Please do not self diagnose the issue. If you already know what is wrong there is no need to make a post. Just because your script works other places doesnt mean it isnt the problem (im not saying it is either.) We need all variables to diagnose (hopefully) an issue. Also dont edit what you paste and tell us what it should be ( your system path for example), this all helps in figuring out a problem especially when it cant be duplicated.
Me finding out it had to do with ffdshow only came about because of testing as a result of posting this thread - I hadn't thought to test ffdshow when I started the thread, because I thought x264 was where the issue was.

But in any case, here is what I get. I even included runs with xvid_encraw and mencoder.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Stephen>F:

F:\>cd editing

F:\Editing>dir
Volume in drive F is Local Disk
Volume Serial Number is D48E-14E3

Directory of F:\Editing

01/20/2009 12:06 AM <DIR> .
01/20/2009 12:06 AM <DIR> ..
12/24/2008 12:15 AM 56,178,688 alwaysbeta2-xvid.avi
01/19/2009 11:58 PM 38 alwaysbeta2.avs
12/23/2008 11:03 PM 896,886,784 alwaysbeta2a-huffyv12.avi
12/23/2008 10:49 PM <DIR> alwaysforever
10/22/2008 07:20 AM 19 notes.txt
4 File(s) 953,065,529 bytes
3 Dir(s) 20,022,444,032 bytes free

F:\Editing>x264 --version
x264 0.65.1077M e46f648
built on Jan 13 2009, gcc: 3.4.5 (mingw-vista special r3)

F:\Editing>x264.exe --crf 18.0 --ref 16 --mixed-refs --no-fast-pskip --bframes 1
6 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock 1:1 --subme 9 --trel
lis 2 --partitions all --8x8dct --scenecut 100 --threads auto --thread-input --s
ar 1:1 --aud --progress --no-dct-decimate --no-psnr --no-ssim --output "output.m
p4" "alwaysbeta2.avs"

F:\Editing>"C:\Program Files\megui\tools\x264\x264.exe" --crf 18.0 --ref 16 --mi
xed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct
auto --deblock 1:1 --subme 9 --trellis 2 --partitions all --8x8dct --scenecut 1
00 --threads auto --thread-input --sar 1:1 --aud --progress --no-dct-decimate --
no-psnr --no-ssim --output "output.mp4" "alwaysbeta2.avs"
avis [info]: 848x480 @ 23.98 fps (100 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 Cache32
x264 [info]: profile High, level 4.0
mp4 [info]: initial delay 250 (scale 2997)
x264 [info]: slice I:2 Avg QP:10.00 size: 1717
x264 [info]: slice P:65 Avg QP:14.53 size: 5280
x264 [info]: slice B:33 Avg QP:15.34 size: 5590
x264 [info]: consecutive B-frames: 45.9% 18.4% 27.6% 8.2% 0.0% 0.0% 0.0% 0.
0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 81.6% 15.7% 2.7%
x264 [info]: mb P I16..4: 4.1% 11.0% 2.4% P16..4: 11.2% 5.3% 2.6% 0.1% 0
.1% skip:63.2%
x264 [info]: mb B I16..4: 3.7% 4.9% 0.8% B16..8: 30.2% 2.5% 2.7% direct:
15.0% skip:40.2% L0:39.1% L1:46.6% BI:14.3%
x264 [info]: 8x8 transform intra:55.0% inter:58.9%
x264 [info]: direct mvs spatial:90.9% temporal:9.1%
x264 [info]: ref P L0 49.0% 13.1% 9.1% 3.7% 3.9% 2.6% 3.9% 4.2% 5.3% 1.
2% 0.7% 0.6% 0.5% 0.5% 0.5% 1.3%
x264 [info]: ref B L0 70.7% 9.9% 4.3% 1.9% 2.1% 1.6% 1.6% 1.5% 2.1% 2.
5% 1.1% 0.4% 0.1% 0.1% 0.2%
x264 [info]: ref B L1 91.5% 8.5%
x264 [info]: kb/s:1018.6

encoded 100 frames, 0.29 fps, 1021.25 kb/s

F:\Editing>xvid_encraw -i "alwaysbeta2.avs" -single -bitrate 4000 -smoother 0 -q
uality 3 -vhqmode 0 -closed_gop -nochromame -max_bframes 0 -threads 1 -o "alway
stest.avi"
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 848 x 480, 23.976fps (2997/125), starting from frame 0
xvid [info]: Number of frames to encode: 100, Bitrate = 4000kbps
xvid [info]: xvidcore build version: xvid-1.2.1
xvid [info]: Bitstream version: 1.2.1
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE TSC
xvid [info]: Detected cpus = 1, threads requested = 1, threads in use = 1
0: key=2, time= 125, len= 4440 | type=I, quant= 4, len= 4440
1: key=0, time= 110, len= 7 | type=P, quant= 4, len= 7
2: key=0, time= 110, len= 7 | type=P, quant= 4, len= 7
3: key=0, time= 93, len= 7 | type=P, quant= 4, len= 7
4: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
5: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
6: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
7: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
8: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
9: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
10: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
11: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
12: key=0, time= 93, len= 7 | type=P, quant= 4, len= 7
13: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
14: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
15: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
16: key=0, time= 93, len= 7 | type=P, quant= 4, len= 7
17: key=0, time= 79, len= 7 | type=P, quant= 4, len= 7
18: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
19: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
20: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
21: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
22: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
23: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
24: key=0, time= 93, len= 7 | type=P, quant= 4, len= 7
25: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
26: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
27: key=0, time= 109, len= 7 | type=P, quant= 4, len= 7
28: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
29: key=0, time= 109, len= 7 | type=P, quant= 4, len= 7
30: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
31: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
32: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
33: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
34: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
35: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
36: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
37: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
38: key=0, time= 79, len= 7 | type=P, quant= 4, len= 7
39: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
40: key=0, time= 94, len= 7 | type=P, quant= 4, len= 7
41: key=0, time= 78, len= 7 | type=P, quant= 4, len= 7
42: key=0, time= 125, len= 6772 | type=P, quant= 2, len= 6772
43: key=0, time= 141, len= 7784 | type=P, quant= 2, len= 7784
44: key=0, time= 141, len= 8501 | type=P, quant= 2, len= 8501
45: key=0, time= 140, len= 9783 | type=P, quant= 2, len= 9783
46: key=0, time= 125, len= 9049 | type=P, quant= 2, len= 9049
47: key=0, time= 141, len= 10084 | type=P, quant= 2, len= 10084
48: key=0, time= 125, len= 9683 | type=P, quant= 2, len= 9683
49: key=0, time= 141, len= 10866 | type=P, quant= 2, len= 10866
50: key=0, time= 140, len= 10445 | type=P, quant= 2, len= 10445
51: key=0, time= 141, len= 11082 | type=P, quant= 2, len= 11082
52: key=0, time= 125, len= 10716 | type=P, quant= 2, len= 10716
53: key=0, time= 125, len= 11114 | type=P, quant= 2, len= 11114
54: key=0, time= 125, len= 11301 | type=P, quant= 2, len= 11301
55: key=0, time= 141, len= 11915 | type=P, quant= 2, len= 11915
56: key=0, time= 141, len= 11796 | type=P, quant= 2, len= 11796
57: key=0, time= 125, len= 12282 | type=P, quant= 2, len= 12282
58: key=0, time= 125, len= 12859 | type=P, quant= 2, len= 12859
59: key=0, time= 140, len= 11966 | type=P, quant= 2, len= 11966
60: key=0, time= 125, len= 13501 | type=P, quant= 2, len= 13501
61: key=0, time= 141, len= 13288 | type=P, quant= 2, len= 13288
62: key=0, time= 125, len= 13297 | type=P, quant= 2, len= 13297
63: key=0, time= 141, len= 14294 | type=P, quant= 2, len= 14294
64: key=0, time= 141, len= 16239 | type=P, quant= 2, len= 16239
65: key=0, time= 125, len= 14165 | type=P, quant= 2, len= 14165
66: key=0, time= 156, len= 16050 | type=P, quant= 2, len= 16050
67: key=0, time= 156, len= 18902 | type=P, quant= 2, len= 18902
68: key=0, time= 141, len= 20075 | type=P, quant= 2, len= 20075
69: key=0, time= 156, len= 22043 | type=P, quant= 2, len= 22043
70: key=0, time= 156, len= 26750 | type=P, quant= 2, len= 26750
71: key=0, time= 141, len= 26976 | type=P, quant= 2, len= 26976
72: key=0, time= 125, len= 24207 | type=P, quant= 2, len= 24207
73: key=0, time= 140, len= 20896 | type=P, quant= 2, len= 20896
74: key=0, time= 110, len= 9139 | type=P, quant= 2, len= 9139
75: key=0, time= 125, len= 19799 | type=P, quant= 2, len= 19799
76: key=0, time= 125, len= 20918 | type=P, quant= 2, len= 20918
77: key=0, time= 125, len= 9298 | type=P, quant= 2, len= 9298
78: key=0, time= 125, len= 22051 | type=P, quant= 2, len= 22051
79: key=0, time= 125, len= 27160 | type=P, quant= 2, len= 27160
80: key=0, time= 125, len= 8456 | type=P, quant= 2, len= 8456
81: key=0, time= 125, len= 21456 | type=P, quant= 2, len= 21456
82: key=0, time= 140, len= 24156 | type=P, quant= 2, len= 24156
83: key=0, time= 125, len= 9756 | type=P, quant= 2, len= 9756
84: key=0, time= 125, len= 20596 | type=P, quant= 2, len= 20596
85: key=0, time= 125, len= 21501 | type=P, quant= 2, len= 21501
86: key=0, time= 125, len= 9171 | type=P, quant= 2, len= 9171
87: key=0, time= 125, len= 23679 | type=P, quant= 2, len= 23679
88: key=0, time= 125, len= 20360 | type=P, quant= 2, len= 20360
89: key=0, time= 125, len= 8528 | type=P, quant= 2, len= 8528
90: key=0, time= 140, len= 19815 | type=P, quant= 2, len= 19815
91: key=0, time= 125, len= 20402 | type=P, quant= 2, len= 20402
92: key=0, time= 125, len= 8207 | type=P, quant= 2, len= 8207
93: key=0, time= 109, len= 23201 | type=P, quant= 2, len= 23201
94: key=0, time= 125, len= 26417 | type=P, quant= 2, len= 26417
95: key=0, time= 125, len= 9987 | type=P, quant= 2, len= 9987
96: key=0, time= 156, len= 23868 | type=P, quant= 2, len= 23868
97: key=0, time= 140, len= 24189 | type=P, quant= 2, len= 24189
98: key=0, time= 125, len= 12986 | type=P, quant= 2, len= 12986
99: key=0, time= 141, len= 21337 | type=P, quant= 2, len= 21337

Tot: enctime(ms) =11470.00, length(bytes) = 919841
Avg: enctime(ms) = 114.70, fps = 8.72, length(bytes) = 9198
I frames: 1 frames, size = 4440/ 4440, quants = 4 / 4.00 / 4
P frames: 58 frames, size = 15777/ 915114, quants = 2 / 2.00 / 2
N frames: 41 frames, size = 7/ 287

F:\Editing>mencoder "alwaysbeta2.avs" -o "always.avi"
MEncoder dev-SVN-r27419-4.2.2 (C) 2000-2008 MPlayer Team
CPU: Intel Celeron 2/Pentium III Coppermine,Geyserville (Family: 6, Model: 8, St
epping: 10)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 0
Compiled with runtime CPU detection.
success: format: 0 data: 0x0 - 0x32
AVS file format detected.
VIDEO: [YV12] 848x480 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:848x480 fps:23.976 ftime:=0.0417
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 848 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
videocodec: libavcodec (848x480 fourcc=48564646 [FFVH])
Selected video codec: [rawyv12] vfm: raw (RAW YV12)
==========================================================================
Forcing output FourCC to 55594648 [HFYU].
Writing header...
ODML: vprp aspect is 16384:16384.
Writing header...
ODML: vprp aspect is 16384:16384.
Pos: 4.2s 100f (100%) 13.66fps Trem: 0min 10mb A-V:0.000 [20556:0]
Flushing video frames.
Writing index...
Writing header...
ODML: vprp aspect is 16384:16384.

Video stream: 20556.171 kbit/s (2569521 B/s) size: 10717056 bytes 4.171 secs
100 frames

F:\Editing>dir
Volume in drive F is Local Disk
Volume Serial Number is D48E-14E3

Directory of F:\Editing

01/20/2009 12:17 AM <DIR> .
01/20/2009 12:17 AM <DIR> ..
01/20/2009 12:17 AM 10,723,572 always.avi
12/24/2008 12:15 AM 56,178,688 alwaysbeta2-xvid.avi
01/20/2009 12:08 AM 50 alwaysbeta2.avs
12/23/2008 11:03 PM 896,886,784 alwaysbeta2a-huffyv12.avi
12/23/2008 10:49 PM <DIR> alwaysforever
01/20/2009 12:17 AM 930,522 alwaystest.avi
10/22/2008 07:20 AM 19 notes.txt
01/20/2009 12:15 AM 533,461 output.mp4
7 File(s) 965,253,096 bytes
3 Dir(s) 20,010,246,144 bytes free

F:\Editing>
Pasted exactly how it appears in the Command Prompt. That first time I ran x264 the output file was 0 KB.

My script:
AVISource("alwaysbeta2a-huffyv12.avi").Trim(1,100)
If I use DirectShowSource then the exact same thing occurs - the only difference is that in my tray the Haali Media Splitter icon appears, but ffdshow's does not. When I run xvid_encraw or mencoder, however, both Haali's and ffdshow's icons appear.

The file that was being tested on was an ffvhuff file that had been created in VirtualDubMod 1.5.10.3 with ffdshow's VFW encoder, from one of clsid's generic svn builds of ffdshow-tryouts that was current as of December 23rd 2008 (downloaded from Sourceforge; unfortunately I cannot remember which exact build/revision because I only keep the most current installer of ffdshow on my computer - for later disc archiving - and I long since deleted the installer that goes with the build used to encode the input file, as well as having uninstalled and subsequently updated it with newer versions). All of the builds I've tried dated November 23rd 2008 and after, however, exhibit the behavior with x264 detailed above. If I use the November 14th 2008 build, then x264 acts just like xvid_encraw and mencoder do in that readout.

mencoder.conf:
ass=no
subcp=enca:ru:cp1251
fontconfig=no
nosound=yes
autoexpand=no
ovc=lavc=yes
lavcopts=vcodec=ffvhuff:context=1:vstrict=-1:pred=2
ffourcc=HFYU
force-avi-aspect=1/1

[qyot27]

Gah, Haali's doesn't appear with DirectShowSource if it's an AVI because I don't use Haali's for AVI - I was remembering my tests with MKVs. I posted this separately because of the prior comment about not editing.

[haruhiko_yamagata]

Could you try DebugView for Windows (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx)?
1. Open ffdshow video decoder configuration and goto "Info & CPU", check "Output strings to debugger". This setting is shared by video/audio/vfw.
2. Rung DebugView for Windows.
3. Run x264

Please tell me what appears in the DebugView window.

[qyot27]

This is the readout from DebugView, when x264 fails:
00000000 0.00000000 [2876] DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
00000001 0.00085765 [2876] DllGetClassObject() CLSID: CAVIFileSynth
00000002 0.00108254 [2876] 003E74A0->CAVIFileSynth::CAVIFileSynth()
00000003 0.00122809 [2876] 003E74A0->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1
00000004 0.00141359 [2876] 003E74A0->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-000000000046} (IClassFactory)
00000005 0.00156500 [2876] 003E74A0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2
00000006 0.00170944 [2876] 003E74A0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1
00000007 0.00185024 [2876] DllGetClassObject() result=0x0, object=003E74A8
00000008 0.00202009 [2876] 003E74A0->CAVIFileSynth::CreateInstance()
00000009 0.00272381 [2876] 003E74E8->CAVIFileSynth::CAVIFileSynth()
00000010 0.00304592 [2876] 003E74E8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1
00000011 0.00319510 [2876] 003E74E8->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-000000000046} (IUnknown)
00000012 0.00336244 [2876] 003E74E8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2
00000013 0.00351218 [2876] 003E74E8->CAVIFileSynth::Release() gRefCnt=2, m_refs=1
00000014 0.00367365 [2876] 003E74A0->CAVIFileSynth::CreateInstance() result=0x0, object=003E74E8
00000015 0.00381892 [2876] 003E74E8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2
00000016 0.00396335 [2876] 003E74E8->CAVIFileSynth::Release() gRefCnt=2, m_refs=1
00000017 0.00410611 [2876] 003E74A0->CAVIFileSynth::Release() gRefCnt=1, m_refs=0
00000018 0.00414103 [2876] 003E74A0->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1
00000019 0.00432513 [2876] 003E74E8->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-000000000046} (IUnknown)
00000020 0.00448269 [2876] 003E74E8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2
00000021 0.00464668 [2876] 003E74E8->CAVIFileSynth::Release() gRefCnt=1, m_refs=1
00000022 0.00489280 [2876] 003E74E8->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-000000000046} (unsupported!)
00000023 0.00504561 [2876] 003E74E8->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-000000000046} (IPersistFile)
00000024 0.00522441 [2876] 003E74E8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2
00000025 0.00537694 [2876] 003E74E8->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-000000000046} (IAVIFile)
00000026 0.00553730 [2876] 003E74E8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3
00000027 0.00557417 [2876] 003E74E8->CAVIFileSynth::Load("alwaysbeta2.avs", 0x0)
00000028 0.00580074 [2876] 003E74E8->CAVIFileSynth::Release() gRefCnt=2, m_refs=2
00000029 0.00595998 [2876] 003E74E8->CAVIFileSynth::Release() gRefCnt=1, m_refs=1
00000030 0.01586487 [2876] 003E74E8->CAVIFileSynth::GetStream(*, 73646976(vids), 0)
00000031 0.37088123 [2876] SSETools 0.1
00000032 0.50930607 [2876] DllMain: hModule=0x10000000, ulReason=2, lpReserved=0x00000000, gRefCnt = 1
00000033 0.77364802 [2876] QuickTime Movie Reader VFAPI Plugin
00000034 0.77384079 [2876] Copyright © 2001 James Holderness
00000035 0.77395314 [2876] jholderness@geocities.com
00000036 9.85056782 [352] <<UI>>
00000037 9.85080242 [352] MMTask compacting.
00000038 9.85266781 [352]
00000039 9.85319614 [352] <<UI>>
00000040 9.85343552 [352] MMTask compacted, 1044480 bytes in largest available block.
00000041 9.85357094 [352]
00000042 40.16058731 [352] <<UI>>
00000043 40.16883850 [352] MMTask compacting.
00000044 40.66009140 [352]
00000045 40.66808319 [352] <<UI>>
00000046 40.67276001 [352] MMTask compacted, 1044480 bytes in largest available block.
00000047 41.16234970 [352]
00000048 70.69187164 [352] <<UI>>
00000049 70.69375610 [352] MMTask compacting.
00000050 70.69714355 [352]
00000051 70.69921112 [352] <<UI>>
00000052 70.70119476 [352] MMTask compacted, 1044480 bytes in largest available block.
00000053 71.19213867 [352]

[haruhiko_yamagata]

None of these lines seem to be written by ffdshow.
Then ffdshow is failing in the very early stage.
I'll build a test build that has more debug outputs. Please wait.

[qyot27]

In the effort of completeness, here's the readout from DebugView when x264 works because I specified the full path:
00000000 0.00000000 [1208] DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
00000001 0.00040955 [1208] DllGetClassObject() CLSID: CAVIFileSynth
00000002 0.00059142 [1208] 003E7298->CAVIFileSynth::CAVIFileSynth()
00000003 0.00074032 [1208] 003E7298->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1
00000004 0.00092358 [1208] 003E7298->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-000000000046} (IClassFactory)
00000005 0.00107611 [1208] 003E7298->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2
00000006 0.00122418 [1208] 003E7298->CAVIFileSynth::Release() gRefCnt=1, m_refs=1
00000007 0.00136582 [1208] DllGetClassObject() result=0x0, object=003E72A0
00000008 0.00159909 [1208] 003E7298->CAVIFileSynth::CreateInstance()
00000009 0.00169407 [1208] 003E72E0->CAVIFileSynth::CAVIFileSynth()
00000010 0.00184297 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1
00000011 0.00200864 [1208] 003E72E0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-000000000046} (IUnknown)
00000012 0.00215698 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2
00000013 0.00230392 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1
00000014 0.00253691 [1208] 003E7298->CAVIFileSynth::CreateInstance() result=0x0, object=003E72E0
00000015 0.00268777 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2
00000016 0.00284645 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1
00000017 0.00299088 [1208] 003E7298->CAVIFileSynth::Release() gRefCnt=1, m_refs=0
00000018 0.00316996 [1208] 003E7298->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1
00000019 0.00331970 [1208] 003E72E0->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-000000000046} (IUnknown)
00000020 0.00354403 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2
00000021 0.00375802 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1
00000022 0.00393290 [1208] 003E72E0->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-000000000046} (unsupported!)
00000023 0.00408264 [1208] 003E72E0->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-000000000046} (IPersistFile)
00000024 0.00424160 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2
00000025 0.00439050 [1208] 003E72E0->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-000000000046} (IAVIFile)
00000026 0.00454946 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3
00000027 0.00471289 [1208] 003E72E0->CAVIFileSynth::Load("alwaysbeta2.avs", 0x0)
00000028 0.00487380 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=2, m_refs=2
00000029 0.00503248 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=1, m_refs=1
00000030 0.02435477 [1208] 003E72E0->CAVIFileSynth::GetStream(*, 73646976(vids), 0)
00000031 0.39757678 [1208] SSETools 0.1
00000032 0.61805147 [1208] DllMain: hModule=0x10000000, ulReason=2, lpReserved=0x00000000, gRefCnt = 1
00000033 1.08236492 [1208] QuickTime Movie Reader VFAPI Plugin
00000034 1.08252561 [1208] Copyright © 2001 James Holderness
00000035 1.08390784 [1208] jholderness@geocities.com
00000036 1.24517226 [1208] DllMain: hModule=0x10000000, ulReason=3, lpReserved=0x00000000, gRefCnt = 1
00000037 1.85655546 [1208] TffdshowBase::Constructor
00000038 1.91219640 [1208] TffdshowDecVideo::Constructor
00000039 1.93775296 [1208] TffdshowDecVideoOutputPin::Constructor
00000040 1.99727809 [1208] Tffvfw::decQuery: YV12
00000041 2.17617893 [1208] 00D9B4C8->CAVIStreamSynth(video)
00000042 2.17651772 [1208] 00D9B4C8->CAVIStreamSynth::AddRef() (video) gRefCnt=2, m_refs=1
00000043 2.17668486 [1208] 003E72E0->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2
00000044 2.17684054 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=2, m_refs=1
00000045 2.17748284 [1208] 00D9B4C8->CAVIStreamSynth::Info(0022F6F8, 204) (video)
00000046 2.17929959 [1208] 00D9B4C8->CAVIStreamSynth::Info(0022F728, 204) (video)
00000047 5.46235895 [352] <<UI>>
00000048 5.46258831 [352] MMTask compacting.
00000049 5.46272182 [352]
00000050 5.46458817 [352] <<UI>>
00000051 5.46478844 [352] MMTask compacted, 1044480 bytes in largest available block.
00000052 5.55520201 [352]
00000053 35.66298676 [352] <<UI>>
00000054 35.66318130 [352] MMTask compacting.
00000055 35.66330719 [352]
00000056 35.75585175 [352] <<UI>>
00000057 35.75607681 [352] MMTask compacted, 1044480 bytes in largest available block.
00000058 35.75620270 [352]
00000059 45.23125458 [1208] 00D9B4C8->CAVIStreamSynth::Release() (video) gRefCnt=1, m_refs=0
00000060 45.23150635 [1208] 00D9B4C8->~CAVIStreamSynth() (video), gRefCnt = 1
00000061 45.23165131 [1208] 003E72E0->CAVIFileSynth::Release() gRefCnt=0, m_refs=0
00000062 45.23179245 [1208] 003E72E0->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 0
00000063 45.23318100 [1208] TffdshowDecVideo::Destructor
00000064 45.23452377 [1208] TffdshowDecVideoOutputPin::Destructor
00000065 45.28534317 [1208] DllCanUnloadNow(): gRefCnt = 0
00000066 45.42623901 [1208] DllMain: hModule=0x10000000, ulReason=0, lpReserved=0x00000001, gRefCnt = 0
00000067 66.13414764 [352] <<UI>>
00000068 66.14633179 [352] MMTask compacting.
00000069 66.15375519 [352]
00000070 66.15965271 [352] <<UI>>
00000071 66.16554260 [352] MMTask compacted, 1044480 bytes in largest available block.
00000072 66.17330933 [352]


The commandline for that was grossly simplified because otherwise DebugView would tell me that too much memory was being used. So instead of the full options I specified in the other posts, this one only used --crf 18.

[haruhiko_yamagata]

Please try this test build. Here (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2625_20090121_Q.exe).
This build pops up a message box (ffvfw/DRV_LOAD) every time ff_vfw.dll is loaded (because output debug string does not work in that dll) and prints debug string when ffdshow.ax is loaded.

[zapco]

I can replicate the behavior qyot27 is experiencing (x264 hanging when calling ffdshow via DirectShowSource and not specifying an absolute path) on both Win XP Pro SP2 and Windows 2000 SP4, and to add one more variable to the equation, it only happens when the command line exceeds 264 characters in length, whether directly from a command prompt or via a batch file.

So,

x264.1084.exe -B 15000 -p 2 --level 4.1 --ref 3 --bframes 3 --deblock -2:-1 --weightb --direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 20000 --me umh --merange 12 --threads auto --progress -o test1.x264.1920x1080.012345678.mkv test1.avs
works, but

x264.1084.exe -B 15000 -p 2 --level 4.1 --ref 3 --bframes 3 --deblock -2:-1 --weightb --direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 20000 --me umh --merange 12 --threads auto --progress -o test1.x264.1920x1080.0123456789.mkv test1.avs

doesn't.

However,

"e:\x264.1084.exe" -B 15000 -p 2 --level 4.1 --ref 3 --bframes 3 --deblock -2:-1 --weightb --direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 20000 --me umh --merange 12 --threads auto --progress -o test1.x264.1920x1080.0123456789.mkv test1.avs
does.

I can also confirm that this behavior started with ffdshow r2347 (11-23-2008) and continues with r2597 (1-8-2009) - r2322 (11-14-2008) and previous versions were fine.

Edit: How do you get scroll bars in a code box?! I read through the BB code help page but couldn't find anything...

[qyot27]

I can replicate the behavior qyot27 is experiencing (x264 hanging when calling ffdshow via DirectShowSource and not specifying an absolute path) on both Win XP Pro SP2 and Windows 2000 SP4, and to add one more variable to the equation, it only happens when the command line exceeds 264 characters in length, whether directly from a command prompt or via a batch file.
After testing it out, both with the 2625 build that was posted and with 2615, it seems this indeed has been the problem I was having. I've attached the output from DebugView for both a failed attempt, using the full range of options I posted earlier, and a successful one which only uses --crf 18 (which confuses me, because I had run simplified command options before as well and it still had failed).

Edit: How do you get scroll bars in a code box?! I read through the BB code help page but couldn't find anything...
Quote tags will wrap the text, I'm not sure about what to do with the code tags.

[haruhiko_yamagata]

Thanks, I have reproduce the bug.

[haruhiko_yamagata]

I have fixed at rev 2627.
:thanks:

[qyot27]

Thanks, I updated to the 2630 build and it works as it should again.