x264 encoding questions

lolilolicon · 2009-07-22 12:43:05

I have a DVD and I want to rip it. Got the VOBs.

I want to transcode them into H.264 so I searched around for usage of x264. It's such a complex thing... I decide to just take parameters from those fansub rips just to modifiy them a little...

Much I want to ask but here I'll keep it simple :

1. Does x264 have a resize filter? I imagine something as simple as this: $ x264 -resize 1280x720 -o XX_1280.mkv XX_1920.y4m (Yeah, just like convert from ImageMagick!)
If it, unfortunately, does not do resize(amazing...)...:( What's the way to go? ( $ ffmpeg -s 1280x720 -i XX_1920.mkv XX_1280.mkv does not do the right job... Result is still 1920x1080 and looks crappy, full of blocks. )

2. So... we can use mencoder, ffmpeg, handbrake, h264enc or plain x264 to do H264 encoding... What's the difference?? I don't have an opinion on this but I get a feeling...:P Since x264 looks pure, it's naturally best to use x264! Am I right? I think both ffmpeg and mencoder actually use x264's library but this can't convince me of their dencentness. Am I paranoia or am I insane? You tell me. I hear somebody say h264enc does "such a great job"... Well, but it uses mencoder... I kinda like to try it out but I'm here for a quick answer first.;)

So, so much so far.

Last edited by lolilolicon (2009-07-22 13:14:28)

skottish · 2009-07-23 03:02:04

FFmpeg's x264 presets are set up from Robert Swain, a FFmpeg developer, and takes a lot of the work out of things. I'd try something like this to start, which will resize your video too. It didn't work before because of where you had it in the command line. I'm assuming nothing about what you intend to do about the audio. Putting nothing in will probably yield low quality results, so I'm putting in the -an (audio none) switch just so you can test.

Notes: If FFmpeg complains about no preset 'libx264-hq', just replace it with 'hq'. To see the other presets, just:

ls /usr/share/ffmpeg

libx264-hq is high quality, so expect some time for processing. The -crf switch will control the rest of the quality. 23 is currently the default in x264-git.

ffmpeg -i <INPUT_VIDEO> -an -vcodec libx264 -vpre libx264-hq -crf 23 -threads 0 -s 1280x720 <OUTPUT>.mkv

I always recommend using FFmpeg from subversion and x264 from git, but upgrading both will break things right now. FFmpeg had a small API change around a month ago, and x264 had a .so version bump in the last few weeks. Although, x264 is getting faster and better all the time, so the work may be worth it.

Oh yes, a very good reference to FFmpeg's x264 presets by Robert Swain, FFmpeg developer:

http://rob.opendot.cl/index.php/useful- … ing-guide/

lolilolicon · 2009-07-23 08:55:32

Hi, skottish.

It's very nice of you to answer in such a detail.
with the command you post it works fine. I should have put the -s 1280x720 option after the in put file... my bad:D. (Also if I don't add -vcodec libx264 but just -s 1280x720, the result is gonna be full of blocks although the input file was encoded by x264.)

I came across a pretty nice guide for x264 encoding here:

http://sites.google.com/site/linuxencod … ding-guide

And there I read "Using FFmpeg or mencoder to handle everything is convenient but they have problems. We can avoid these problems by breaking down the steps and using the best tool for that specific job." which I tend to agree. (But not sure hence here to ask.)

Right now I've encoded a video file using the method from that link above. The x264 version is 20090720 which I compiled with the official snapshot. This new version offers some presets/profiles/tunes stuff but I just used them as reference.

How I did it:

mkfifo WE.y4m
x264 --deblock '-2:-2' --me umh --subme 9 --merange 24 --psy-rd '0.4:0.0' --bframes 5 --ref 16 --crf 21 --level 4.1 --no-fast-pskip --no-mixed-refs -o WE_x264.mkv WE.y4m & mplayer INPUT.mkv -vo yuv4mpeg:file=WE.y4m -nosound -noconfig all -vf scale=720:-3 -sws 9

mkfifo WE.wav
oggenc -q 4 -o WE_ogg.ogg WE.wav & mplayer -nocorrect-pts -vo null -vc null -ao pcm:file=WE.wav -noconfig all INPUT.mkv

mkvmerge -o WE.mkv WE_x264.mkv WE_ogg.ogg

As you see, x264 was encoding what mplayer fed it. The resize done here is by mplayer's video filter: "-vf scale=720:-3 -sws 9"
With this I managed to transcode the 7'34" source (1280x534 at around 3000 Kbps, 200MB) to 720x300 at around 636 Kbps, 43MB.

But before I preceed to do the real encoding, I still have some questions to ask.

What's the relationship between ffmpeg/mencoder/handbrake and x264? Say, like in the line from your last post, "-vcodec libx264" implies ffmpeg uses x264's library(the .so file or something I think...). But does ffmpeg do the same thing as plain x264 does? What really happens ain't as clear to me this way.... also I don't see what magic ffmpeg does with "-s 1280x720".... Does it do the same thing as mplayer's "-vf scale=1280:720"? Maybe I can also do it with handbrake, or avidemux... So many apps sharing so many common functions! What's behind this? Do they do the same thing the same way? If not, which is better?(...what a mess...)

The above is basically the same thing I asked with the 2nd question in my initial post.

For my 1st question, I think the answer is like "No, x264 does not do any resizing/scaling trivial thing! Those are for dummies!" ... Still I'd like to ask: did I do it right with mplayer "-vf scale=720:-3 -sws 9" or I should do it with something else for the best result?

O, that guide by Robert Swain is nice too, and pretty up to date. ^^

Last edited by lolilolicon (2009-07-23 09:16:26)

lolilolicon · 2009-07-23 11:36:38

Something interesting about 2 pass mode and crf mode:

http://forum.doom9.org/archive/index.php/t-143904.html

Dark Shikari wrote:

CRF, 1pass, and 2pass all use the same bit distribution algorithm. 2-pass tries to approximate CRF by using the information from the first pass to decide on a constant quality factor. 1-pass tries to approximate CRF by guessing a quality factor over time and varying it to reach the target bitrate.

LoRd_MuldeR wrote:

As far as I know if you create two files of the same size, one with CRF (1-Pass) and one with 2-Pass, then the difference in quality between these two files will be very small. Most likely you wouldn't be able to notice it.

On the other hand, in the mplayer DOCS, things are explained differently:
http://www.mplayerhq.hu/DOCS/HTML/en/me … -x264.html

mplayer_DOC wrote:

Still, there are very good reasons for using two pass encoding. For one thing, single pass ratecontrol is not psychic, and it often makes unreasonable choices because it cannot see the big picture. For example, suppose you have a two minute long video consisting of two distinct halves. The first half is a very high-motion scene lasting 60 seconds which, in isolation, requires about 2500kbps in order to look decent. Immediately following it is a much less demanding 60-second scene that looks good at 300kbps. Suppose you ask for 1400kbps on the theory that this is enough to accommodate both scenes. Single pass ratecontrol will make a couple of "mistakes" in such a case. First of all, it will target 1400kbps in both segments. The first segment may end up heavily overquantized, causing it to look unacceptably and unreasonably blocky. The second segment will be heavily underquantized; it may look perfect, but the bitrate cost of that perfection will be completely unreasonable. What is even harder to avoid is the problem at the transition between the two scenes. The first seconds of the low motion half will be hugely over-quantized, because the ratecontrol is still expecting the kind of bitrate requirements it met in the first half of the video. This "error period" of heavily over-quantized low motion will look jarringly bad, and will actually use less than the 300kbps it would have taken to make it look decent. There are ways to mitigate the pitfalls of single-pass encoding, but they may tend to increase bitrate misprediction.
Multipass ratecontrol can offer huge advantages over a single pass. Using the statistics gathered from the first pass encode, the encoder can estimate, with reasonable accuracy, the "cost" (in bits) of encoding any given frame, at any given quantizer. This allows for a much more rational, better planned allocation of bits between the expensive (high-motion) and cheap (low-motion) scenes.

Haven't tested it yet, but maybe we should agree to Dark Shikari? (Despite mplayerhq.hu says no, with such a long paragraph, which sounds pretty reasonable to me...)

[ If 2 pass makes no advantage over crf at a same resulting file size, I'd definitely go with crf!!! ]

Last edited by lolilolicon (2009-07-23 11:40:32)

skottish · 2009-07-24 01:49:45

I'll start with the 1 pass vs. 2 pass stuff. They serve different purposes. Use 2 pass if you need an exact bitrate (I-Pod video for instance), crf if you don't (archiving DVD). Dark Shikari, LoRd_MuldeR, Robert Swain, and every one else involved with FFmpeg and x264 development will agree. Two pass is important if you need a target bitrate, as the Mplayer docs suggest, but crf is designed for single pass quality. If one is really into wasting time for no quality gain, 3 pass will make them happy.

The relationship between FFmpeg and x264 is mostly what you posted above from converting the video to y4m using Mplayer, then piping it into x264. FFmpeg does this (or something just like it), then passes the parameters that the user specifies to the command line x264. Unfortunately FFmpeg does not support all of x264's options. If one is an expert at video encoding, or is learning from experts, this may be limitation. My needs aren't that fine-grained, so I'm not too concerned about it. Since Dark Shikari (Jason Garrett-Glaser) and AkuPenguin (Loren Merritt) are both x264 and FFmpeg developers, I'm sure that they'll get it all sooner or later.

As far as video scaling with x264 goes, there was an option previously. I've used it before and was actually searching for it the other day. Either it was dropped at some point or both x264 and the Internet is doing an amazing job of hiding the information. Jump on x264@freenode if you need an answer. Dark Shikari is always there. It's creepy how always there he is.

x264 has gone through quite a few quality and speed upgrades lately. It has also added its own set of presets. The presets and defaults were the most recent .so bump, so in order to use this stuff, you'll need to start rebuilding things.

Arch Linux

#1 2009-07-22 12:43:05

x264 encoding questions

#2 2009-07-23 03:02:04

Re: x264 encoding questions

#3 2009-07-23 08:55:32

Re: x264 encoding questions

#4 2009-07-23 11:36:38

Re: x264 encoding questions

#5 2009-07-24 01:49:45

Re: x264 encoding questions

Board footer