VOB to x264 using Mencoder

[horrormaster34]

Is there anyway to take a VOB file and encode it using only Mencoder and x264? I figured I could just use Mencoder for all my cropping, scaling, and other work and then pipe that into x264 for the actual encoding of the video. The only thing I ever get is static output. Basically, since GNU/Linux doesn't have something like Avisynth, I was thinking I could use Mencoder for that sort of stuff (de-interlacing, cropping, scaling, etc.).

[roozhou]

This can be done on either *nix or Windows.
Take a look at MediaCoder and you will learn how mencoder piping x264 is done.

e.g.

mencoder -ovc raw -of rawvideo -nosound -o - -really-quiet input.VOB -vf format=i420 | x264 - 720x480 -o output.264

[Selur]

you could look at the command line sx264 uses with mencoder. ;)

[nm]

Is there anyway to take a VOB file and encode it using only Mencoder and x264? I figured I could just use Mencoder for all my cropping, scaling, and other work and then pipe that into x264 for the actual encoding of the video. The only thing I ever get is static output. Basically, since GNU/Linux doesn't have something like Avisynth, I was thinking I could use Mencoder for that sort of stuff (de-interlacing, cropping, scaling, etc.).
On Linux, it's easy to use a FIFO file and yuv4mpeg output from MPlayer: http://forum.doom9.org/showthread.php?p=1234194#post1234194

However, why don't you encode directly with libx264?
mencoder input.vob -nosound -ovc x264 -x264encopts crf=22:threads=auto -of rawvideo -o output.264

In both cases you still need to encode audio separately and mux with a third tool (mkvmerge or MP4Box).

[roozhou]

MEncoder does not use seperate thread for decoding which is similar to --thread-input in x264. If you use fast encoding settings or heavy video filtering like deinterlacing, you cannot benefit from multicore CPUs.

P.S. mencoder's muxer really sucks and for years none of MPlayer's maintainers has ever worked on fixing it.

[nm]

MEncoder does not use seperate thread for decoding which is similar to --thread-input in x264. If you use fast encoding settings or heavy video filtering like deinterlacing, you cannot benefit from multicore CPUs.
Well, I don't see any significant difference on a dual core CPU and PAL MPEG-2 input.

Heavy filtering, slow encoding

libx264 through MEncoder:

$ time mencoder input.ts -really-quiet -vf yadif=1,mcdeint=0:0:10,framestep=2 -nosound -ovc x264 \
-x264encopts crf=22:threads=auto:me=umh:subme=9:ref=5:mixed_refs:partitions=all:8x8dct:trellis=2:bframes=3:b_adapt=2:b_pyramid:weight_b:ssim:psnr \
-of rawvideo -o menc.slow.264

real 4m55.786s
user 8m31.520s
sys 0m4.760s

Piping to x264:

$ time mencoder input.ts -really-quiet -vf yadif=1,mcdeint=0:0:10,framestep=2,format=i420 -nosound -of rawvideo -ovc raw -o - \
| x264 -o x264.slow.264 --crf 22 --threads auto --thread-input --me umh --subme 9 --ref 5 --mixed-refs --partitions all --8x8dct \
--trellis 2 --bframes 3 --b-adapt 2 --b-pyramid --weightb -- - 720x576

encoded 1147 frames, 3.89 fps, 1423.05 kb/s

real 4m54.712s
user 8m18.251s
sys 0m5.468s


Heavy filtering, fast encoding

libx264 through MEncoder:

$ time mencoder input.ts -really-quiet -vf yadif=1,mcdeint=0:0:10,framestep=2 demo -nosound -ovc x264 \
-x264encopts crf=22:threads=0:partitions=none:me=dia:subme=0:nocabac:nodeblock:ssim:psnr \
-of rawvideo -o menc.fast.264

real 1m52.572s
user 1m51.479s
sys 0m0.312s

Piping to x264:

$ time mencoder input.ts -really-quiet -vf yadif=1,mcdeint=0:0:10,framestep=2,format=i420 -nosound -of rawvideo -ovc raw -o - \
| x264 -o x264.fast.264 --crf 22 --threads auto --thread-input --me dia --subme 0 --partitions none --no-cabac --no-deblock -- - 720x576

encoded 1147 frames, 10.39 fps, 3283.43 kb/s

real 1m50.403s
user 1m51.363s
sys 0m0.884s

This was made with x264 r1153, before the new defaults, so the command-lines need to be changed when using newer x264 versions. I checked that the output files had the same option strings in them, and closely matching PSNR & SSIM values.

P.S. mencoder's muxer really sucks and for years none of MPlayer's maintainers has ever worked on fixing it.
Yeah, but piping to x264 doesn't make muxing any easier. If you're thinking about VFR encoding of hybrid sources, HandBrake(CLI) is the easiest option on Linux.

[roozhou]

Well, I don't see any significant difference on a dual core CPU and PAL MPEG-2 input.

Heavy filtering, slow encoding

libx264 through MEncoder:

$ time mencoder input.ts -really-quiet -vf yadif=1,mcdeint=0:0:10,framestep=2 -nosound -ovc x264 \
-x264encopts crf=22:threads=auto:me=umh:subme=9:ref=5:mixed_refs:partitions=all:8x8dct:trellis=2:bframes=3:b_adapt=2:b_pyramid:weight_b:ssim:psnr \
-of rawvideo -o menc.slow.264

real 4m55.786s
user 8m31.520s
sys 0m4.760s



I tested your command lines on a 704x480 source with Sherpya's 29238 win32 build which uses x264 r1145. It gave me ~60% CPU load and ~3 fps. But with piping from mencoder to x264 it gave me 100% CPU load and ~4.5fps.

I don't have linux at present so I cannot repeat your test. But I am sure both MPlayer and MEncoder are single-threaded. Demuxer, decoder, filters, encoder and muxer run in the same thread.

[nm]

Tried on virtualized 32-bit Windows 7 (VirtualBox, SMP enabled) with Techouse's x264 build (r1159) and MEncoder r29355 from http://oss.netfarm.it/mplayer-win32.php

With average x264 settings, CPU was fully saturated when piping, while MEncoder&libx264 only gave an 80-90% load. Still, the total "wallclock" encoding time was the same for both cases.

[Selur]

iirc. the main bummer for is that multithreaded decoding is broken when using mencoder for mpeg2 content so nowadays mencoder only uses one thread for decoding mpeg2 content (or was this fixed in one of the latest builds and I missed it)
Personally I prefer piping since it's faster for me to compile x264 than mencoder wherefore switching x264 builds seems to be easier with a separate x264 binary. ;)

Cu Selur

[nm]

iirc. the main bummer for is that multithreaded decoding is broken when using mencoder for mpeg2 content so nowadays mencoder only uses one thread for decoding mpeg2 content (or was this fixed in one of the latest builds and I missed it)
This doesn't matter a lot since MPEG-2 decoding is many times faster than encoding, unless the video is scaled down radically. Anyway, as roozhou said, the rest of the pipeline is single-threaded up to the encoder, so even if the decoder is threaded, x264 may be hindered by heavy filtering.