Can x264 open stdin as y4m stream ?

[galaxy001]

Some people may want to use avs on one PC and run x264 on another PC, or run quite a slow avs script for 2-pass, then, lossless format is needed. (Since x264 support y4m, I don't want to use Lagarith or MSU.)
But under windows, there is no named pipe. So I can only use:
avs2yuv -raw movie1.avs -o - | 7za a movie1.7z -simovie1.yuv -mf=off

7za x movie1.7z -so | x264 --crf 18 - 720x480 --fps 24000/1001 -o movie1.mkv

If I can use y4m, I won't need to write resolution and fps again.

So, will x264 accept "-.y4m" or "-:y4m" or "- --y4m-input" ?
7za x movie1.y4m.7z -so | x264 --crf 18 -:y4m -o movie1.mkv

[kemuri-_9]

x264 does not accept y4m as a piped stdin stream, only raw yuv.

Edit:
what you're trying to do would possibly be more effective using avisynth's TCPDeliver plugin to send data over sockets.
check out
http://avisynth.org/mediawiki/TCPServer
for more info.

[galaxy001]

TCPServer is a good solution for 2 PCs, but not for 2-pass encodeing.
Still, I think it is good for x264 to add this function.

So, where to put this feature request ?

[LoRd_MuldeR]

BTW: Why do you store raw YUV data in a 7-Zip archive, rather than using lossless compression like HuffYUV, FFV1 or Lagarith?

[roozhou]

Check x264 here http://forum.doom9.org/showthread.php?t=141441.
I did a small hack in my x264 build. Specifying input file name as -.y4m will work.

There is named pipe on windows, but it works in C/S mode and you can only access the client end of the pipe by pipe name, either read or write.

[galaxy001]

lzma is quite fast in decompress, and I want a way that make x264 works under both Windows and Linux.
Sometime, rar IS better than lossless codec, so will lzma.
Since I cannot find a lzma.exe, I choose 7z instead.

To roozhou:
I googled you NamedPipe.exe on doom9 and on popgo.net, and I find they are a bit different. So I didn't run a test yet.
And I am interesting in your dshow2raw, since the daily build x264 is more up-to-date, why can't you just release such pipe tool to render VFAPI to y4m or raw ?

[LoRd_MuldeR]

lzma is quite fast in decompress, and I want a way that make x264 works under both Windows and Linux.

So you can still use HuffYUV or FFv1. On Windows you can load a HuffYUV/FFv1 AVI file via Avisynth (AVISource or FFmpegSource) and on Linux you can pipe it in from MEncoder or FFmpeg...

[galaxy001]

HuffYUV didn't consider other frames, so it is not good at compress.
FFv1, I remember ffdshow says when the version changes, the format also changes. So I have to keep all PC running the same version of FFmpeg, which is a bit hard.

lzma or gzip is a common format, and pipe tools are common under Linux. So I just be used to using the pipe way to merge all kinds of my favorite tools.

Still, WHERE to put a feature request for x264 ?

[LoRd_MuldeR]

HuffYUV didn't consider other frames, so it is not good at compress.

Neither HuffYUV nor FFv1 uses inter-frame prediction, only intra-frame prediction. But "raw" YUV data (if packed into 7-Zip or not) doesn't use any prediction at all, so...

FFv1, I remember ffdshow says when the version changes, the format also changes.

I think the bitstream format for FFv1 is fixed now...

Still, WHERE to put a feature request for x264 ?

There's a great chance that the x264 developer already read your post. Anyway, you may post it on the mailing list (http://www.videolan.org/developers/lists.html) and/or use the IRC channel (irc://irc.freenode.net/x264) ;)

[Dark Shikari]

lzma is quite fast in decompress, and I want a way that make x264 works under both Windows and Linux.FFV1 is much much much faster than LZMA.FFv1, I remember ffdshow says when the version changes, the format also changes. So I have to keep all PC running the same version of FFmpeg, which is a bit hard.Wrong. Backwards compatibility is basically guaranteed, and AFAIK the format has never changed anyways.

[roozhou]

To roozhou:
I googled you NamedPipe.exe on doom9 and on popgo.net, and I find they are a bit different. So I didn't run a test yet.
And I am interesting in your dshow2raw, since the daily build x264 is more up-to-date, why can't you just release such pipe tool to render VFAPI to y4m or raw ?

y4m or raw cannot keep pts from directshow and, pipe is slow. Instead I will try to make my x264 builds up-to-date.

[galaxy001]

Neither HuffYUV nor FFv1 uses inter-frame prediction, only intra-frame prediction. But "raw" YUV data (if packed into 7-Zip or not) doesn't use any prediction at all, so...

That is why I use lzma, which can do the "inter-frame" prediction since 1 frame of 720x480 is only 1.4M and the whole stream is a single file to lzma. Well, I remember 7z data piece can be 4g (or 2g ?) max., not unlimted.
FFV1 is much much much faster than LZMA.
Backwards compatibility is basically guaranteed, and AFAIK the format has never changed anyways.
Well, I'll try FFv1 next time.
y4m or raw cannot keep pts from directshow and, pipe is slow. Instead I will try to make my x264 builds up-to-date.
pts ? Do you mean something like timecode ? since x264 cannot deal with timecode, why not output a extenal timecode.txt for mkvmerge ?

[Dark Shikari]

That is why I use lzma, which can do the "inter-frame" prediction since 1 frame of 720x480 is only 1.4M and the whole stream is a single file to lzma. Well, I remember 7z data piece can be 4g (or 2g ?) max., not unlimted.If you need interframe prediction, encode with x264.

The lack of context-awareness in a general-purpose compressor makes it pretty awful for compressing video data.

[roozhou]

pts ? Do you mean something like timecode ? since x264 cannot deal with timecode, why not output a extenal timecode.txt for mkvmerge ?

Maybe this should be a better way:

1st pass: Encode from source (either avs or dshow) and dump frames to y4m+timecode
2nd pass: Encode dumped y4m and mux with timecode