Premature termination of x264 when piping input

[omion]

I've been having a bit of a problem running x264 from piped data in Windows.

I think the problem is that something along the way sees the 0x1A character as an end-of-file character and halts encoding. As an example, type this into a console:
perl -e "for $a (1 .. (388800 * 8)) {print chr(128)}; for $a (1 .. 388800) {print chr(26)}; for $a (1 .. 388800 * 8) {print chr(128)}" | x264.exe --verbose -o outfile.mkv - 720x360
This will make Perl output 8 frames of character 128, 1 frame of character 26 (0x1A), and 8 more frames of character 128. However, it never gets past the first 8 frames. You can try with other characters, but I noticed that it just stops encoding if a character 26 is found.

So here's the really weird part:
I tried it on a bunch of different versions of x264, and the only ones I found actually work are some 64-bit builds I made a long time ago (revs 389 - 477).
I don't know if it's a 32 vs 64-bit issue, but I noticed that I had built with MSVC, whereas it seems that everybody else builds with GCC.

Any ideas?

[akupenguin]

iirc, using fopen(..., "rb") isn't enough, and you have to do some sort of ioctl to make it really binary mode.
avs2yuv (http://akuvian.org/src/avisynth/avs2yuv/) ran into that issue. I don't remember if I ever fixed it though, I might just have given up on Windows since it worked under Wine.

[squid_80]

Hmmm, not seeing any problems here but maybe that's because I use MSVC too.

[omion]

Well, I made a simple patch which should fix it. It took me so long because I don't actually know how to write C, and I just got around to installing cygwin.

BIG WARNING: I have no idea what I'm doing. But here goes anyway:
Index: x264.c
===================================================================
--- x264.c (revision 611)
+++ x264.c (working copy)
@@ -38,6 +38,11 @@
#include <fcntl.h> /* _O_BINARY */
#endif

+#ifdef SYS_CYGWIN
+#include <io.h> /* setmode() */
+#include <fcntl.h> /* _O_BINARY */
+#endif
+
#ifndef _MSC_VER
#include "config.h"
#endif
@@ -104,6 +109,11 @@
_setmode(_fileno(stdout), _O_BINARY);
#endif

+#ifdef SYS_CYGWIN
+ setmode(fileno(stdin), _O_BINARY);
+ setmode(fileno(stdout), _O_BINARY);
+#endif /* SYS_CYGWIN */
+
x264_param_default( &param );

/* Parse command line */


Input would be appreciated!

[Opuz Klass]

Are we going to see this fixed in the near future? :|

[DarkZell666]

Well, the "easy" solution is to compile using MSVC (if you have it :/). The author of MediaCoder also attempted a patch somewhere else in the forum (I can't even remember his name, sorry mate ^^').

Dunno if these 2 patches actually work, btw... did you try yours omion ? Or do I get it that since you didn't know how to code C you didn't have the compiler either ? :o

[omion]

Well, the "easy" solution is to compile using MSVC (if you have it :/). The author of MediaCoder also attempted a patch somewhere else in the forum (I can't even remember his name, sorry mate ^^').

Dunno if these 2 patches actually work, btw... did you try yours omion ? Or do I get it that since you didn't know how to code C you didn't have the compiler either ? :o

Well, I compiled it in Cygwin and it worked. But then I realized that Sharktooth uses MinGW to compile, so my patch wouldn't help in that case. I would make a patch which includes MinGW support, but I can't seem to get MinGW up and running on my computer, so I wouldn't be able to test it.

I just got into the habit of making my own builds with MSVS, which you can get here (http://forum.doom9.org/showthread.php?t=117889) (in the section that says "You also need the following:")

It'd be great if somebody can tweak my patch to work with MinGW. I'm currently fairly busy with work and other programming projects, so I don't have enough time to try to get MinGW working.