Piping from mencoder to x264 -> losing frames :(

[Selur]

I ran into a problem when piping from mencoder to x264 and hope someone here might be able to help:

when calling:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "D:\comparison\totalrecall_trlr_01_1080p_dl.mov" | x264 --preset ultrafast --crf 18 --fps 24000/1001 --input-res 1920x1080 --output "D:\Encoding Output\test.mkv" -
I end up with 3377 frames instead of 3385.

by changing the value for X in "-lavdopts threads=X" I end up with:
-lavdopts threads=8 -> 3377 frames
-lavdopts threads=7 -> 3378 frames
-lavdopts threads=6 -> 3379 frames
-lavdopts threads=5 -> 3380 frames
-lavdopts threads=4 -> 3381 frames
-lavdopts threads=3 -> 3382 frames
-lavdopts threads=2 -> 3383 frames
-lavdopts threads=1 -> 3383 frames
without -lavdopts threads=X -> 3383 frames

when I use ffmpeg or x264 directly I end up with 3385 frames (like the input).

Since lowering the threads count really hurts the encoding speed and it still leaves me with 2 missing frames, I was wondering is someone knows if there's some sort of 'magic option' to fix the problem.

Cu Selur

Ps.: I also made a thread over at doom10 regarding this problem http://doom10.org/index.php?topic=2203.0 (where I posted the stuff I tried and a link to the source)

[smok3]

just guessing: what happens if you omit -nosound?

[Selur]

mencoder complains about the missing '-oac' and if you use '-oac pcm' you end up with the same results (8->3377 frames,...) ;)

[CruNcher]

those 2 frames where going lost since ages not sure but i think stanley fixed it with his win32 piping @ least i made him aware of this early on ;)

[Selur]

only found http://forum.doom9.org/showthread.php?t=138463 related to it, but it does not speak of a solution,.. (btw. does anyone know if this is a windows only problem?)

[Reimar]

Hm, why are you using mencoder instead of mplayer -vo yuv4mpeg?
If the reason is that it cannot output to stdout, from r34861 on you can use -really-quiet -vo yuv4mpeg:file=- for that.
In addition, I fixed the issues of frames getting lost (due to codec delay) in r34860.

[Selur]

Hm, why are you using mencoder instead of mplayer -vo yuv4mpeg?
a. because of the name :) (mencoder, mplayer I normally use mplayer only for playback :))
b. like you suspected the std::out problem (thanks for changing that)
c. I encode some stuff directly with mencoder :)

If the reason is that it cannot output to stdout, from r34861 on you can use -really-quiet -vo yuv4mpeg:file=- for that.
Nice! :)

In addition, I fixed the issues of frames getting lost (due to codec delay) in r34860.
Thanks a lot!

[nm]

a. because of the name :) (mencoder, mplayer I normally use mplayer only for playback :))

But in that command you aren't really using mencoder for encoding. Just playing to stdout. MPlayer's yuv4mpeg output does that in a better way with video parameters communicated automatically to x264.

[Selur]

I know :)

[Selur]

@Reimar: r34861 on you can use -really-quiet -vo yuv4mpeg:file=- for that.
would be cool if file=- would also work for audio output :D
because than one could then use:
mplayer -really-quiet -benchmark -mc 0 -vc null -vo null -afm ffmpeg -nocorrect-pts "D:\Encoding Output\test__aid_1__09_02_10_821_01.mp3" -aid 1 -channels 2 -ao pcm:fast:waveheader:file=- | ...
to pipe to NeroAacEnc/OggEnc2/Flac/... ;)
(atm. '-ao pcm:fast:waveheader:file=-' creates a file named '-')

---------------

taking:
mencoder -lavdopts threads=8 -really-quiet -ofps 25 -of rawvideo -o - -ovc raw -noskip -demuxer lavf -vfm ffmpeg -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "G:\Hybrid\test - clips\test.avi" | x264 --preset ultrafast --tune fastdecode --crf 18 --fps 25 --input-res 640x352 --output "D:\Encoding Output\mencoder.mp4" -
as a basis I changed it for mplayer to:
mplayer -benchmark -lavdopts threads=8 -really-quiet -vo yuv4mpeg:file=-,y4m -demuxer lavf -vfm ffmpeg -forcedsubsonly -nosub -nosound -noframedrop -mc 0 "G:\Hybrid\test - clips\test.avi" | x264 --demuxer y4m --preset ultrafast --tune fastdecode --crf 18 --sync-lookahead 15 --colormatrix undef --fps 25 --output "D:\Encoding Output\mplayer.mp4" -
sadly, that aborts for me with:
y4m [error]: bad header magic (4152467f <=> ¦FRAM)
y4m [error]: bad header magic (520a0d45 <=> E
RR)using: r34866 from http://www.spirton.com/mplayer-mencoder-subjunk-build/
Problem is probably that mplayer does not write the number of frame into the yuv4mpeg file,..
(adding a --frames FRAMECOUNT to the x264 call does not help; using -vo yuv4mpeg:file=- instead of -vo yuv4mpeg:file=-,y4m does neither)

Cu Selur

[Reimar]

It works just fine for me (x264 reports itself as 0.122.x). The output you printed means that for some reason you x264 expects the frame data to be one byte less that what it really is.
"FRAME" is the y4m frame header and as you can see from the x264 output it sees one byte before it. And its resync mechanism is absolutely ridiculous, trying 4 bytes further instead of with the next byte.
Try piping into mplayer of ffplay to check that the mplayer output is fine.
I also find it quite sad that x264 can't even autodetect y4m but instead just assumes that stdin data is raw.

[Selur]

using:
mplayer -benchmark -lavdopts threads=8 -really-quiet -vo yuv4mpeg:file=-,y4m -demuxer lavf -vfm ffmpeg -forcedsubsonly -nosub -nosound -noframedrop -mc 0 "G:\Hybrid\test - clips\test.avi" | ffplay -i -
only the first two frames get shown, than the picture freezes,...

[Reimar]

The y4m option for yuv4mpeg is really pointless, it's the default.
But anyway this one works perfectly for me on Linux (latest SVN mplayer, old ffplay in Debian, but that should not matter):
mplayer -benchmark -lavdopts threads=8 -really-quiet -vo yuv4mpeg:file=-,y4m -demuxer lavf -vfm ffmpeg -forcedsubsonly -nosub -nosound -noframedrop -mc 0 http://samples.mplayerhq.hu/MPEG-4/video.mp4 | ffplay -i -