x264 Linux

[Hellworm]

about mencoders internal x264: seems as I was totally wrong, I looked at an old man page, making me think mencoder would not support every encoder feature :p .
So I think I'm an idiot and theres no point in using mencoder + external x264 if you compile mencoder with internal support.

Anyway my cmd for mencoder to x264 was:

mencoder infile -nosound -vf format=i420 -ovc raw -of rawvideo -o encode & x264 -o outfile encode 720x576

[Oline 61]

I've still never been able to get the same quality out of mencoder internal x264. All of my encodes had more blocking than using external x264. My main problem now is IVTC with Mencoder, as it always outputs a different number of frames that AviSynth+Decomb.

[bugmenotwillyou]

the tiny bit that i and seeminly others have overlooked is that if you use the scale parameter together with format=i420 you have to take care of the order of your video filters!

standard version without the scale filter (cf. hellworm's last post):
mkfifo yuv.stream
mencoder <infile> -nosound -vf format=i420 -ovc raw -of rawvideo -o yuv.stream & x264 -o <outfile> yuv.stream <WIDTHxHEIGHT
rm yuv.stream

a version including other video filters like linear blend deinterlacing (lb) and scaling:
mkfifo yuv.stream
mencoder <infile> -nosound -vf pp=lb,scale,format=i420 -ovc raw -of rawvideo -o yuv.stream & x264 -o <outfile> yuv.stream <WIDTHxHEIGHT>
rm yuv.stream

if you place the format filter before the scale filter you will notice colour distorion and picture shifts (like scrolling by) and a drastic slowdown of the encoding processes.
it might be that other filters, like crop and harddup, are affected badly by a "misplaced" format filter as well. you may want to experiment; for the moment, placing format=i420 last in the filter queue seems to be safe.

btw, i used matroska (.mkv) and all my files were good.

so to make sure, i'll provide a concrete example (2-pass encoding, the first 300 frames of title 10 of a dvd (ntsc)):
mkfifo yuv.stream
mencoder dvd://10 -frames 300 -ovc raw -nosound -noskip -vf pp=lb,scale,harddup,format=i420 -of rawvideo -o yuv.stream & x264 -p 1 --stats x264_2pass.log.10 -o 10.mkv yuv.stream 720x480
rm yuv.stream
mkfifo yuv.stream
mencoder dvd://10 -frames 300 -ovc raw -nosound -noskip -vf pp=lb,scale,harddup,format=i420 -of rawvideo -o yuv.stream & x264 -p 2 --stats x264_2pass.log.10 -o 10.mkv yuv.stream 720x480
rm yuv.stream


addendum: it seems format=iyuv (instead of format=i420) results in stable pictures as well.

[pete]

I use ffmpeg to decode my stuff, because I had a/v sync problems with mencoder:
ffmpeg -i infile.ext -pix_fmt yuv420p outfile.yuv
You can also pipe the output of ffmpeg directly into x264 without using mkfifo:
ffmpeg -i infile.ext -pix_fmt yuv420p -f rawvideo - | x264 -o outfile.264 - WxH

[rushin_911]

I still miss AviSynth when encoding in Linux. I love my AviSynth :(.

Actually I think you can still use it under linux and encode through it to x264
from this link you can get the instructions on how to get avisynth to work on linux http://forum.doom9.org/showthread.php?t=103550&highlight=avisynth

then you need to get a program called avs2yuv which I believe was authored by akupenguin
http://students.washington.edu/lorenm/src/avisynth/avs2yuv/

after that you can issue it through these series of command
mkfifo test.yuv
wine avs2yuv.exe -raw x.avs test.yuv & x264 (whatever options) -o whatever.mkv (or mp4 etc...) test.yuv 320x240 (or whatever resolution)

the -raw command is very important so that the piped stream is the raw yuv kind that x264 would accept without problems

to make things easier and more practical you can put the wine and x264 commands in a text file and make it an executable file.

wine avs2yuv.exe -raw x.avs test.yuv & x264 -p 1 ... -o x.mkv test.yuv 320x240
wine avs2yuv.exe -raw x.avs test.yuv & x264 -p 2 ... -o x.mkv test.yuv 320x240

you may also put the mkfifo command as well in a line before the wine and x264 commands (haven't tested it though).

hope that helps

[evade]

If you would like to use your avisynth scripts with x264 under linux why not just use the windows binary compiled with avs support?

This is much simpler. No need to pipe output or specify framerate on the x264 cmdline. You are already decoding the mpeg2 and serving frames under wine, why not encode as well. Wine is not an emulator just an api compatibilty layer so if there is a performance hit at all, which I doubt it will be doubious at best.

I've just tested this out and this command works fine for me:


wine ~/x264.exe --threads 2 --qp 18 --progress -o DRT.mkv "Z:\raid\dvdrip\dr1.avs"

[rushin_911]

You could use the x264 binary, however sometimes these aren't always available or have problems with wine (Sharktooth's binaries work but they've been temporarily suspened, and boor's do not work well with wine for whatever reason).

[Hellworm]

If you compile yourself the linux binary you can always have the newest version, have it optimized for your specific cpu, don't have to hassle with installers ...
But of course, it's just a question of choice.

[hellfred]

If you are willing to work out cross-platform compilation, you may be able to build your latest win32/Mingw x264 binaries from within linux using a crosscomplie gcc binary yourself and therefore have latest features and nativ avs input and mp4 output. For mp4-output you will have to crosscompile gpac, too, and make sure that the linker uses your crosscompiled version. Moreover you will have to link it statically. But that is something I never did, so you are on your own when attempting this.

Hellfred

[evade]

I have managed to cross-compile x264.exe.

here's what I did:

I already had a mingw toolchain installed. Under gentoo everything you need is compiled and installed to /opt/xmingw with an "emerge xmingw-runtime" command.

So I checked out the latest x264 revision and entered the directory.
I ran a configure with no arguments to produce a config.mak and config.h.

The makefile for x264 doesn't use variables for ranlib and ar. It calls the defaults in your path. To fix that I altered the Makefile with this command.
sed -e 's!ranlib !${RANLIB} !g' -e 's!ar !${AR} !' Makefile > Makefile2 && mv Makefile2 Makefile


Then I needed to edit the config.mak and config.h.
here is my config.mak file with variables pointing to my mingw toolchain and cflags for my cpu

prefix=/opt/xmingw
exec_prefix=${prefix}
bindir=${exec_prefix}/bin
libdir=${exec_prefix}/lib
includedir=${prefix}/include
ARCH=X86
SYS=MINGW
CC=/opt/xmingw/bin/i386-mingw32msvc-gcc
RANLIB=/opt/xmingw/bin/i386-mingw32msvc-ranlib
AR=/opt/xmingw/bin/i386-mingw32msvc-ar
CFLAGS=-Wall -I. -O4 -march=prescott -ffast-math -fomit-frame-pointer -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD=1 -s -I/opt/xmingw/i386-mingw32msvc/include
LDFLAGS= -lvfw32 -s -L /opt/xmingw/i386-mingw32msvc/lib
AS=nasm
ASFLAGS=-f win32 -DPREFIX
VFW=no
EXE=.exe
VIS=no
HAVE_GETOPT_LONG=1
DEVNULL=NUL
CONFIGURE_ARGS=


my config.h

#define AVIS_INPUT
#define fseek fseeko64
#define ftell ftello64
#define X264_VERSION ""
#define X264_POINTVER "0.44.x"


After running make I have an x264.exe which I can execute with wine capable of outputing mkv files and accepting avisynth files as input. I didn't build with gpac or vfw as I have no use for them right now. I use matroska because it supports ac3 which mplayer can pass through to my reciever via spdif.

[rushin_911]

I would like to retract my statement regarding the piping method.
After numerous tests which included the encoding of 2 full length movies it appears there is a problem with the method which makes the video and audio unsynchronized with each other, and it isn't simply a matter of delaying the audio or advancing it but rather it's as if it is is streched (or the video is shortened) which possibly could be an indication of frame dropping during the encoding process (I can't really prove this statement though).
I've tested a windows x264 binary (10000 frames) and it doesn't seem to suffer from the same problem.
I apologize if my previous statements had affected anyone negatively.

[akupenguin]

it appears there is a problem with the method which makes the video and audio unsynchronized with each other, and it isn't simply a matter of delaying the audio or advancing it but rather it's as if it is is streched You didn't specify --fps on the x264 commandline, whereas x264 reading .avs directly can autodetect it.

[rushin_911]

You didn't specify --fps on the x264 commandline, whereas x264 reading .avs directly can autodetect it.

oh, it seems I missed that. Thank you :)

[mikeX]

I encode x264 with mencoder to AVI, demux to RAW with gpac, then mux the raw stream to MP4 (again with gpac) and finaly remux from MP4 Matroska. However, this leads to gradual loss of audio sync.

mike@shinobi [/data/dvdrip]% mkv264 last2m.avi last_days-q148.ogg -o ld.mkv
[extracting]: MP4Box -aviraw video last2m.avi
Extracting AVI video (format h264) to last2m_video.h264
[muxing]: MP4Box -add last2m_video.h264 last2m.mp4
Adjusting AVC SizeLength to 16 bits
AVC-H264 import - frame size 640 x 480 at 25.000 FPS
Adjusting AVC SizeLength to 24 bits
Import results: 139113 samples - Slices: 670 I 138443 P 0 B - 1 SEI - 654 IDR
Saving to last2m.mp4: 0.500 secs Interleaving
[cleanup]: rm last2m_video.h264
[merging]: mkvmerge last2m.mp4 last_days-q148.ogg -o ld.mkv
mkvmerge v1.6.5 ('Watcher Of The Skies') built on Feb 15 2006 02:12:25
'last2m.mp4': Using the Quicktime/MP4 demultiplexer.
'last_days-q148.ogg': Using the OGG/OGM demultiplexer.
Warning: 'last2m.mp4' track 1: The AVC video track is missing the 'CTTS' atom for
frame timecode offsets. However, AVC/h.264 allows frames to have more than the
traditional one (for P frames) or two (for B frames) references to other frames.
The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed
for getting the timecodes right. As it is missing the timecodes for this track might
be wrong. You should watch the resulting file and make sure that it loo ks like you expected it to.
'last2m.mp4' track 1: Using the MPEG-4 part 10 (AVC) video output module.
'last_days-q148.ogg' track 0: Using the Vorbis output module.
The file 'ld.mkv' has been opened for writing.
progress: 100%
The cue entries (the index) are being written...
Muxing took 52 seconds.

Same thing happens if I specify -fps 25 to MP4Box, if I mux to matroska directly from avi with --engage allow_avc_in_vfw_mode, or if I play the avi directly with mencoder and -audiofile, so this appears to be related to mencoder. My mencoder version is 'MPlayer dev-CVS-060301-00:28-4.0.3 (C) 2000-2006 MPlayer Team'. Am I missing something?
evade wrote:
After running make I have an x264.exe which I can execute with wine capable of outputing mkv files and accepting avisynth files as input. I didn't build with gpac or vfw as I have no use for them right now. I use matroska because it supports ac3 which mplayer can pass through to my reciever via spdif.

You mean x264 can output directly to mkv!?

[evade]

You mean x264 can output directly to mkv!?

Yes! Recent development. It will compile this way automaticly, no libraries to include, nothing to specify on the configure command line (everything is in matroska.c). Works for linux or mingw compiles.

There are 2 issues with encoding to avi with mencoder and demuxing and remuxing.

1) avi is incomaptible with some of the advanced features of h.264.
I don't know the details. You are better of encoding with "-nosound -of rawvideo -o file.264"

mencoder will always drop video frames to save space. It keeps the sync in the file it encodes but when you demux and remux forget it.

If you are going to use mencoder to encode x264 or encode anything where you might process audio seperately: force mencoder to keep all the frames:

mencoder -noskip -mc 0 vf harddup

harddup should be at the end of your filter chain unless you have a goodreason to put it somewhere else.

http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat-dvd-mpeg4-muxing-filter-issues

[mikeX]

This sounds really cool, I will update my toolchain asap. About the audio sync issue, I guess -nosound is the culprit, since I didn't use any filters other than -vf scale. I'm also gonna give transcode+x264 another try, I think it's feasable with -y ffmpeg or something. Thanks for the tips!

[evade]

I didn't use any filters other than -vf scale.

Right, I think "-mc 0 -noskip -vf scale,harddup" would fix your sync issues.

[mikeX]

Strangely enough, it appears that enablind b-frames fixes my sync issues. Go figure ...

[WoofDef]

Err .. if this isn't a stupid question (or even if it is) how did you enable B-frames, and was this in mencoder or x264?

I tried --b-bias 1 option to x264 in the piping method but MP4Box refused to mux this. It said it couldn't find H264 header or something.

I'm getting the same ~300mS sync lapse that everyone seems to get. Or do the people using matroska only containers get no sync problem?

[mikeX]

I used mencoder with the following option -x264encopts bframes=1 to enable b-frames (I don't use the pipe method).