x264 Command Line Won't Open Input

[kalorx]

Hi all. This is the third such post I've made regarding this issue. I will solve it, no matter how long it takes.

Programs and Versions and Crap:
First off, I'm using x264 version 275. The input is a DGIndex 1.4.0 D2V project, DVD/MPEG2 YV12 source. I have a fully functional (tested through VDub and all) AviSynth AVS script that opens the D2V file via DGDecode.dll. Once again, there is nothing wrong with the AVS script. I also have the Helix 1.2 codec installed on my system, along with FFDShow 2004-10-12 and a very recent version of the Haali Media Splitter. Lastly, I currently have installed AviSynth 2.5.5RC3. I have also tried to solve this issue on AviSynth 2.5.6B4.

The Problem:
x264 275 refuses to input my 100% fully correct and functional input.avs file. I get the following error message:

avis [error]: unsupported input format (DIB )
could not open input file '\input.avs'

The AVS file, the source video along with the D2V file, both the AviSynth plugins, and x264.exe are all in the same directory. This isn't an issue.

Once again, I have run this AVS through VDub with no problems. According to VDub's File Information, this is a 4.2.0 YV12 video, and x264 should have no problems whatsoever opening it.

Any help would be greatly appreciated.

Thanks,

Robert Aronson (KalorX)

[Sharktooth]

even if vdub says YV12 try adding ConvertToYV12() to your avs and see if it goes.
also check if you have any yv12 vfw decoder (divx or xvid is better) installed.

[kalorx]

I tried using ConvertToYV12() a while ago. No luck. Sorry I forgot to mention it.

I have both XviD and DivX installed, latest versions (1.1B2 and 6, respectively).

[Isochroma]

I've run into your problem, too. x264 gives that error when the filename in the AVS script or the name of the script itself contains spaces. It is a known bug that the developers seem reticient about fixing.

[kalorx]

Here's the filename and code:

\input.avs
LoadPlugin("D:\Rips1\DGDecode.dll")
LoadPlugin("D:\Rips1\Decomb521.dll")
mpeg2source("D:\Rips1\PROJECT.d2v")
FieldDeinterlace()
LanczosResize(640,360)

No spaces.

[Isochroma]

All I can suggest is adding ConvertToYV12()

[twist3d]

Have you tried making a new dgmpgdec .d2v file from the source?
maybe the current .d2v is corrupted? have you tried with any other source/.d2v?

[Isochroma]

Does the d2v file contain a reference to the original mpeg/vob file which contains spaces?

[kalorx]

As you can see, no spaces in any of the code (which is in a previous reply).

And ConvertToYV12() does nothing.

And yes, I tried different D2V files.

Nic tells me that it's probably a problem with x264's actual coding... but I would like to be sure.

[Doom9]

does it work if you use mencoder instead?

[kalorx]

I'm not a Linux user. I wouldn't and can't know.

[ChronoReverse]

le sigh

Go into the megui thread and download the win32 version of mencoder there. You can also use megui with it.

[kalorx]

Oh yeah. Now I remember this thing. I was about to install it once, but it told me in needed the .NET framework... and... well... I will never install the .NET framework on my PC again. Last time I did it virtually destroyed all stability on my PC; the same happened to my parents on their own PC. Same thing happened with XP Service Pack 2.

I swear to God, I'm going to scream if the lack of .NET has been the issue all along.

EDIT: ...and it isn't. After pacing madly, frothing at the mouth, and pulling out all my hair, I installed .NET. That isn't connected to x264 at all it seems. As for MeGUI, I tried downloading the mPlayer build for my system via the link in the appropriate thread, but the archive was corrupt.

[ChronoReverse]

You know, instability with .NET 1.1 screams of something else being broken in your computer. It really shouldn't cause instabilities.

[kalorx]

Something doesn't seem right here... I know you people hate it when I ask questions, but are there two different x264 encoders -- VFW and CLI? What's the difference?

EDIT: Hell, screw that last question. The AVS script opens in MeGUI but it won't encode, and YES, I linked MeGUI to all the requires EXEs and the EXEs were of the required versions or higher. There were no error messages in the EXE linkings.

It created a 0 byte MP4 file after dying 0.2 seconds into the encode... exactly like x264.

[Sharktooth]

uhm... then it's a colorspace problem. remove all codec packs (if any), reinstall xvid and ensure it is decoding YV12.
remove and reinstall avisynth (and keep only the needed plugins) too..

[kalorx]

But that doesn't make any sense! I've done everything required to create a YV12 colorspace video -- even VDub says the colorspace is YV12! I mean, I'll try it, but I don't understand how that could fix anything when all sources point to me having a YV12 vid already.

EDIT: Furthermore, I use FFDShow and Haali to decode YV12, and have Helix installed. I don't even know how to have XviD or DivX decode YV12 -- I didn't even know that was possible.

EDIT: And what counts as a codec package? I have Helix, HuffYUV, XviD, DivX, and FFDShow installed. As far as codecs go, that's it. I wouldn't exactly call any of them a "package."

[Doom9]

no wonder you experience the same with MeGUI.. you are after all using x264.exe for encoding. I asked what happens if you use mencoder. I'm afraid the site hosting it isn't performing too great, and you'll need a modern winrar version (older ones cannot properly open 7zip), but you should really give that a try. And then of course you can always pipe YUV data into mencoder by having avs2yuv (search for that term... you'll find a download link) decode the source to stdout, and pipe that data to mencoder's stdin (in which case the input filename will be "-").

Oh yeah, neither SP2 nor the .NET runtime cause any instabilities.. I'm running about 20 PCs with that configuration productively at work and not a single problem.

[kalorx]

Sooo... but... MeGUI requires mencoder to function. It doesn't actually use mencoder? And also, I use 7-Zip itself to open 7z files, not WinRAR.

EDIT: I tried to use mencoder Win32, but I can't figure out how. I browsed the online documentation, but it was completely unhelpful. For basic usage it pointed me back to "the man page," with no link. I think it was a misspelling of "main," but what main page? The main help page? That's not it. The main mPlayer page? That's not it. The main mencoder help page? That's not it. In case it really meant "man," I search the help docs for "man," but found nothing relevant.

[leowai]

@kalory, mencoder is also another encoder client like x264 but offers more codec than x264 (i.e. XviD). MeGUI probably won't "use" it if you specify the encode to used as x264.

[Doom9]

you need to go into the megui settings (control-s or from the tools menu), and change the x264 encoder to mencoder.. the configure mencoder path and you can use it as encoder. It won't just magically pick up that mencoder is available.. the default is x264 and encoding will fail if that one isn't available.

[kalorx]

I can't find the option to choose which command line encoder I want to use in MeGUI.

EDIT: Scratch that.

[kalorx]

I get the exact same crash when I try to use mencoder.

[kalorx]

I also uninstalled every conceivable video codec from my PC -- including FFDshow -- and reinstalled, in the order presented, XviD, AviSynth, and x264.

I don't know how to make XviD my YV12 decoder.

Beyond that, no dice on the x264 front.

[Doom9]

there's always avs2yuv ;)

[kalorx]

As someone once put it on this topic: "le sigh..."

I'm about ready to give up. This simply can't be something I'm doing wrong. Whatever the problem is, it has got to be something beyond my control. I've tried almost everything under the sun, and by all accounts x264 should be freakin' working by now.

I mean, aside from AVS2AVI, what left is there to try?

[Revgen]

In your first post you mentioned using a 2004 version of FFDSHOW.

Are you using FFDSHOW during the encoding process?

[hhanh00]

You know what? I have exactly the same problem. I never posted anything because I thought it was something obvious that I missed, but now you're giving me a reason to investigate further. I'll look into it tonight with windbg.

[kalorx]

In your first post you mentioned using a 2004 version of FFDSHOW.
Are you using FFDSHOW during the encoding process?

Not that I know of, and especially not after I uninstalled FFDShow and tried again.

[kalorx]

You know what? I have exactly the same problem. I never posted anything because I thought it was something obvious that I missed, but now you're giving me a reason to investigate further. I'll look into it tonight with windbg.

Heh. Always ask, my friend. That's one thing I've learned over the years. :)

Sure, sometimes it can make you look like an inbred, ignorant fool who, for some completely irrational, hard-to-believe reason isn't up to date on dozens of huge forum threads, documentation manuals, and the latest software technology. Why, may Heaven in its wisdom strike down any who don't spend hours poring over hundreds of thousands of words in tech docs and forums and instead opts to ask a simple question to a fellow human being!

I hope all of you are catching my sarcasm. It can be supremely annoying to ask a simple question (with an answer that, sure, probably exists buried in a forum thread or manual somewhere) and be treated like someone who refuses to actually read anything and exists solely to waste others' time. Some of us, it seems, are only casual encoders and don't have the time to visit the Library of Congress whenever we have what appears to be a simple conundrum before us.

Now, before I make myself even more enemies in my exhaustion-induced rant, I shall cease. Any help you could provide, hhanh00 (or anyone else), would be very helpful.

Thanks for all your help thus far,

Robert Aronson (KalorX)

[hhanh00]

Well, by the time I compiled a new x264 and updated avisynth, it started working. So I don't know what was wrong :(
I looked at the source code though, and all x264 does is calling AVIStreamInfo to get the fccHandler. If it is reported as DIB (= RGB), I will suspect AviSynth. Have you tried installing the latest version and *rebooting*?
After that, you could add Info() to your script and see if the colorspace is YV12.

--h

[kalorx]

Yes, I've tried rebooting. No change. I've not tried "Info()", but I already have programs telling me the video is YV12.

[Doom9]

I looked at the source code though, and all x264 does is calling AVIStreamInfo to get the fccHandler.Hmm.. so it uses AviFile after all? In that case, do you get a preview in MeGUI? MeGUI uses the AviFile API as well.. I would presume that you don't get a preview in MeGUI as well.. and that is a clear indicator of a codec problem.

[hhanh00]

I've asked you to use Info() because I saw a suspicious line in CAVIStreamSynth::Info.

asi.fccHandler = 'UNKN';
if (vi->IsRGB())
asi.fccHandler = ' BID';
else if (vi->IsYUY2())
asi.fccHandler = '2YUY';
else if (vi->IsYV12())
asi.fccHandler = '21VY';
else {
_ASSERT(FALSE);
}
// asi.fccHandler = vi->IsYUY2() ? '2YUY' : ' BID';

The last line is commented out in avisynth 2.55, but if not anything not YUY2 is reported as RGB. I was wondering if an older version would not have that thing uncommented.

x264 uses AVIStreamInfo(). It is different from virtualdub which actually parses the AVI. They may give different results.

--h

[kalorx]

I do in fact get a preview with MeGUI, but complete encoding non-functionality.

I'll look into this "Info()" thing... my job is unfortunately getting in my way again.

So I just add Info() to my script somewhere? Like, the end, or what?

[Doom9]

BTW, why strings? I have fccHandler and fccType in AVISTREAMINFO defined as uint for Interop.

[hhanh00]

BTW, why strings? I have fccHandler and fccType in AVISTREAMINFO defined as uint for Interop.

These aren't strings. It's a single quote, so it's a multibyte character literal.

--h

[kalorx]

Interesting development: I can encode through x264 via VDub, just not the command line version. However, when I try to compress a 640x360 video, it screams at me because 360 isn't divisible by 16. Thinking that may have been the problem with the command line version, I changed the resize to 640x480 and then to 640x272, but to no avail.

So, here are two questions:

Number 1, how to I encode a 16:9 video with x264?
Number 2, can H.264 video be saved into an AVI and then be converted to MP4 without hurting it?

EDIT: I downloaded version 280 of x264 CLI, which can output raw or MP4 via a command line. Just like VDub, it simply won't work with 640x360. (But it will work otherwise!)

EDIT: Yep, any standard DVD res but 640x360 works. Same in MeGUI with x264 activated.

[Sharktooth]

i didnt noticed you had this line in your AVS:
LanczosResize(640,360)
x264 wants mod 16 resolutions otherwise it will not work.
use 640x352 or better, keep 720x384.

[kalorx]

But how do I resize it for playback? I didn't notice any options in the x264 encoding options to soft-code a display resolution.

EDIT: More:

x264.exe --progress --pass 1 --bitrate 1385 --stats "\x264.stats" --subme 3 --ref 1 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me esa --merange 16 --sar 1:1 --bframes 2 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --analyse p8x8,i8x8,i4x4 --8x8dct --verbose -o "\output.mp4" "\input.avs"

Is there anything wrong with that? Because my video is now /16 compliant in both height and width and STILL not working!

I had it working before, but now I can't remember how I did it...

[Doom9]

try megui again.. your commandline is way too long and contains a lot of default settings.. it's a lot easier to see what's wrong if you have a minimized commandline.

Your \yzs paths disturb me.. I don't have time to test but I dare doubt they are valid. cd \yzx works but in the commandline context you have a drive letter pre-set.. you don't have that in x264.

[kalorx]

The command line provided is the one generated by x264 itself.

Aside from that, I did try it through MeGUI again. After having to shut off High Profile, I4x4, and ME Algo Exhaustive (none of which it liked and would cause it to crash), I did finally get it to not crash.

That's just it, really. It just didn't crash... but I don't think it was encoding, either. Once the encoding started I think it froze. After waiting 30 minutes with no sign of progress I aborted. I mean, my PC's "data crunching" lights weren't even blinking.

Your \yzs paths disturb me.. I don't have time to test but I dare doubt they are valid. cd \yzx works but in the commandline context you have a drive letter pre-set.. you don't have that in x264.

I tried it once with full paths. It didn't make a difference.

[freshNewB]

I encountered the same problem. but i find something strange.
the same input will lead to different result.
this is the log which is ok.and it is aborted normally by myself finally.
Next job job2 is a video job. encoder commandline:
"C:\Documents and Settings\kmccc\桌面\x264\x264.exe" --pass 3 --bitrate 500 --stats "C:\temp\逮捕令\senseigold\3.stats" --ref 8 --mixed-refs --bframes 3 --b-pyramid --filter -2,-1 --subme 1 --weightb --analyse all --8x8dct --ratetol 5.0 --qcomp 0.8 --me umh --threads 2 --cqm "jvt" --progress --no-psnr --output "C:\temp\逮捕令\senseigold\03.264" "C:\temp\逮捕令\senseigold\3.avs"
successfully set up video encoder and callbacks for job job2
Log for job job2

avis [info]: 640x480 @ 23.98 fps (34772 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2

----------------------------------------------------------------------------------------------------------
The current job was aborted. Stopping queue mode
The current job contains errors. Skipping chained jobs



and this is another :(

Next job job4 is a video job. encoder commandline:
"C:\Documents and Settings\kmccc\桌面\x264\x264.exe" --pass 3 --bitrate 500 --stats "C:\temp\逮捕令\senseigold\3.stats" --ref 8 --mixed-refs --bframes 3 --b-pyramid --filter -2,-1 --subme 7 --b-rdo --weightb --trellis 1 --analyse all --8x8dct --ratetol 5.0 --qcomp 0.8 --me umh --threads 2 --cqm "jvt" --progress --no-psnr --output "C:\temp\逮捕令\senseigold\03.264" "C:\temp\逮捕令\senseigold\3.avs"
successfully set up video encoder and callbacks for job job4
----------------------------------------------------------------------------------------------------------

Log for job job4

avis [error]: unsupported input format (DIB )
could not open input file 'C:\temp\逮捕令\senseigold\3.avs'


which makes the difference?

[kalorx]

Wow man, I haven't had this problem ever since I got MeGUI working. I don't even bother using the CLI version anymore. It would be interesting to know what causes the problem, though.

[Sharktooth]

I encountered the same problem. but i find something strange.
the same input will lead to different result.
this is the log which is ok.and it is aborted normally by myself finally.



and this is another :(


which makes the difference?
the first case is a 23.98 fps content.. try adding NiceFPS() filter to your avisynth file.
the second encode: wrong input resolution or colorspace! Resize to a mod 16 res (now x264 accepts even mod 8 or mod 4... but use mod 16 to be sure) and add a ConvertToYV12() to your avisynth file.
Next time :search:

[Doom9]

And how would ?? or ??? be an allowable directory name? And there's always the good old "start - run - cmd" then copy and paste the commandline from megui and let it rip.. there's a good reason commandlines are dumped to the log ;)

And berrinam wrote a nice little howto: http://forum.doom9.org/showthread.php?p=738149#post738149

[foxyshadis]

Actually

avis [error]: unsupported input format (DIB )
could not open input file 'C:\temp\逮捕令\senseigold\3.avs'

Almost always means an error in the avisynth script itself. DIB is how it draws its errors. Open it in vdub or any player and get the error message staring at you. ;)

[freshNewB]

I am sorry. It would be the fault of my system.
Now I can encode it normally.(but i did not reboot my computer)
:)
this could not be a bug or something.