x264: why there is no way to force YUV4MPEG on stdin

[allak]

Apologies in advance if this has been discussed before, but I've been unable to find an answer to a question that is puzzling me: why there is no way to make x264 CLI to assume YUV4MPEG on standard input instead of YUV ?

This would do away with the need for a named pipe when encoding from ffmpeg; and it will permit a pure script based encoding workflow on Windows, where named pipes have a very different implementation and semantics from Linux.

(and no, the mkfifo command from Cygwin does not seems to work with non-cygwin based executables)

For example the following command should work:

ffmpeg.exe -v 0 -i source.vob -f yuv4mpegpipe - | x264.exe - <options>


I have taken a look at the source code, and the funny thing is that there is already some infrastructure ready to make this option work: in muxers.c the function open_file_y4m is able to handle the case where the input file name is '-'.

So it seems that all that is lacking is just a flag to force stdinput to be interpreted as YUV4MPEG.

Is there something obvious that I am missing ? Would the developers accept a patch to implement it ?


P.S. Yes, I know that I could use the x264 library included in ffmpeg, but I would rather use the new preset system of x264.exe than the weird options of ffmpeg; and anyway the x264 binaries for windows are compiled much more frequently.

[Snowknight26]

Just use something like
ffmpeg -i input.ext -vcodec rawvideo -f rawvideo -an -pix_fmt yuv420p - | x264 [...]
instead?

[ACoolie]

Here's the patch I've been using. http://pastie.org/609042
cat 1.y4m | x264 --force-y4m -

[allak]

Just use something like

ffmpeg -i input.ext -vcodec rawvideo -f rawvideo -an -pix_fmt yuv420p - | x264 [...]

instead?

Sure, but then you have to specify heightXwidth and -sar manually on the x264 command line, and fiddle with the -pix_fmt option; or get them programmaticly with Mediainfo or something like that if you want to script the entire workflow.

Using with YUV4MPEG that is not needed, as this information is put in the stream header by the decoder, and x264 is able to read it from there, like from this exemple:


YUV4MPEG2 W720 H576 F25:1 Ip A64:45 C420mpeg2 XYSCSS=420MPEG2
FRAME[......]
FRAME[......]
[.....]


Here's the patch I've been using. http://pastie.org/609042
cat 1.y4m | x264 --force-y4m -

Thanks ACoolie, that is what I had in mind ! For the developers, is there any chance to get this in the trunk ?

[allak]

I've found that the version of x264.exe shipped with Direct264 (http://forum.doom9.org/showthread.php?t=141441) accepts "-.y4m" as a way to specify YUV4MPEG on stdin.

Now I am happy :) :thanks: roozhou.

[roozhou]

I've found that the version of x264.exe shipped with Direct264 (http://forum.doom9.org/showthread.php?t=141441) accepts "-.y4m" as a way to specify YUV4MPEG on stdin.

Now I am happy :) :thanks: roozhou.

No, you should use .y4m instead of -.y4m

if( stricmp(psz_filename, ".y4m") == 0 )
h->fh = stdin;

[allak]

You are right, of course. I had found your post here: http://forum.doom9.org/showthread.php?p=1259722#post1259722 that did have that wrong (or old ?) syntax.

Thanks again. Now those two commands:


mplayer.exe -dumpstream -dumpfile source.vob dvd://X
ffmpeg.exe -v 0 -i source.vob -f yuv4mpegpipe - 2> log | x264.exe .y4m --preset slow -o target.mkv

(where X is '1' most of time) should be all that is needed to decode the main feature of a DVD to H.264/MKV.

[allak]

Nope, after all it does not work ...

The x264.exe binary I did take from direct264_20090818.7z does not seem to work with the .y4m format, even from a file.

x264.exe source.y4m -o target2.mkv

gives weird colorspace problems with that build, works fine with a build made from plain source.

[roozhou]

My bad. This is a bug introduced in June.
Please download the latest build from http://www.sourceforge.net/projects/direct264

[allak]

Now it seems to work like a charm. Thanks again !