good ffmpeg/x264 settings for HQ

[Tephra]

Hey Guys,

I am using the below command and was wondering if there is anything I can do differently to boost quality or reduce size futher:

ffmpeg -i input.mpg -f mpegts -acodec copy -vcodec libx264 -level 41 -crf 20 -bufsize 20000k -maxrate 25000k -g 16 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me hex -subq 5 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq "blurCplx^(1-qComp)" output.mpg

now this is using todays svn/git for ffmpeg/x264.

My sources are either 720x576 or 1920x1080, for 1920x1080 I find I would need to use -crf 25 otherwise there isn't much point in encoding :)

Comments?

Cheers
D.

[Dark Shikari]

As a general warning, ffmpeg mangles options very badly for x264 (they are working on this though), so you will have to be very careful to avoid having ffmpeg pass a commandline to x264 that would be considered "horribly stupid." For example, I think merange 4 or something is the default with ffmpeg.

-g 16This is wasting an enormous amount of bits. 250 or 300 is more reasonable.

I also see no 8x8dct or parti8x8, and of course if you're willing to slow down a bit, -me umh, -subq 6 or 7, bime (bidir_refine), b-rdo, etc.

[Tephra]

Thanks DS,

ok revised cmd line:

ffmpeg -i input.mpg -f mpegts -acodec copy -vcodec libx264 -level 41 -crf $CRF -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti8x8+parti4x4+partp8x8+partb8x8 -flags2 +brdo+dct8x8+bpyramid -me umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq "blurCplx^(1-qComp)" output.mpg

I am also thinking of switching to mp4 or mkv as the muxing overhead of TS is horrible...

[Dark Shikari]

It would help if you enabled B-frames :p

[Tephra]

sorry DS - how do I do that?

[Dark Shikari]

sorry DS - how do I do that?I would suggest you read this page (http://ffmpeg.x264.googlepages.com/mapping).

[teddg]

Tephra, you'll noticed a big difference after enabling B frames. Consider adding -flags2, see example below. I'm always looking for improvements too if anyone has suggestions.

ffmpeg -i xyz.VOB -threads auto -r 29.97 -vcodec libx264 -croptop 54 -cropbottom 58 -s 720x368 -aspect 2.318 -flags +loop -cmp +chroma -deblockalpha -2 -deblockbeta -1 -crf 23 -refs 5 -bf 3 -b_strategy 1 -bidir_refine 1 -coder 1 -me umh -me_range 16 -subq 7 -partitions +parti4x4+parti8x8+partp8x8+partb8x8 -flags2 +brdo+mixed_refs+wpred+dct8x8+bpyramid -g 250 -keyint_min 25 -qmin 10 -qmax 51 -trellis 2 -sc_threshold 40 -i_qfactor 0.71 -acodec libfaac -ab 128k -ar 48000 -ac 2 output.mp4

You also mentioned size... Try MeGui and use minimal noise filter, then try ffmpeg and see which creates the smaller file size. Every once in a while MeGUI creates a file much smaller than ffmpeg with similar settings (like 10% or more), but only for some video. I'm not sure why, but I always use 'minimal filter' on MeGUI, could that be the difference?

--edit--
see this (http://forum.doom9.org/showthread.php?p=1093309) thread too.

[Tephra]

thanks guys.

Ted what are your sources?

also why only 3 bframes?

[TheRyuu]

thanks guys.

Ted what are your sources?

also why only 3 bframes?

Use 16, the max. As the name of the option implies, it is the MAX consecutive b-frames and normally only 3 or 4 are used, but it is a good idea to give it the option to use more.

x264 is smart enough to know when or when not to use them (sort of...)

[Sagittaire]

thanks guys.

Ted what are your sources?

also why only 3 bframes?

well use more than 3 bframes is not really usefull for quality. Encoder will use 16 bframes in particular case (really static scene for example). More doesn't mean always better. Moreover 16 bframes is not compliant for hardware decoding ...

[Dark Shikari]

well use more than 3 bframes is not really usefull for quality.Generally I find that more than 3 B-frames is most useful in animated footage where the purpose of the B-frames is not to directly improve coding efficiency, but to improve the use of reference frames by using B-frames to represent completely static periods of time so that older reference frames don't get thrown away (which would happen if it used P-frames instead).

[Avenger007]

Generally I find that more than 3 B-frames is most useful in animated footage where the purpose of the B-frames is not to directly improve coding efficiency, but to improve the use of reference frames by using B-frames to represent completely static periods of time so that older reference frames don't get thrown away (which would happen if it used P-frames instead).
Is that still true when bpyramid is used?

[Dark Shikari]

Is that still true when bpyramid is used?Yes, because x264 only uses a single-level B-pyramid (thus no matter how many B-frames are used, only one is referenced).

That is actually a case where x264's implementation of pyramid might be counterproductive; on average in animated footage it would probably be useful, but there would probably be such specific cases where it wouldn't be.

[Tephra]

ok this is what I have now:

ffmpeg -i input.mpg -acodec copy -vcodec libx264 -level 41 -crf 20 -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +brdo+dct8x8+bpyramid -me umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq "blurCplx^(1-qComp)" -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 output.mkv

I am still choosing between umh/subq7 and hex/subq5, also the CRF is still changing, might get to 22 and leave it at that.

Anything else I should add/remove?

what about wpred, parti8x8 or trellis?

Cheers
D.

[Tephra]

I just added trellis=2, +wpred and parti8x8 and my bitrate increase as did my encoding time:

without above options:
video:38838kB audio:1824kB global headers:0kB muxing overhead 0.108250%
[libx264 @ 0x845cb30]slice I:22 Avg QP:16.95 size: 36033
[libx264 @ 0x845cb30]slice P:1783 Avg QP:19.55 size: 16091
[libx264 @ 0x845cb30]slice B:1555 Avg QP:22.05 size: 6615
[libx264 @ 0x845cb30]mb I I16..4: 17.0% 46.1% 37.0%
[libx264 @ 0x845cb30]mb P I16..4: 18.6% 0.0% 10.9% P16..4: 42.5% 15.5% 4.3% 0.0% 0.0% skip: 8.2%
[libx264 @ 0x845cb30]mb B I16..4: 3.8% 0.0% 0.0% B16..8: 60.2% 1.8% 1.9% direct: 9.1% skip:23.2%
[libx264 @ 0x845cb30]8x8 transform intra:1.7% inter:64.6%
[libx264 @ 0x845cb30]ref P 67.2% 15.6% 7.0% 4.0% 3.1% 3.1%
[libx264 @ 0x845cb30]ref B 65.9% 18.3% 7.8% 4.8% 3.2%
[libx264 @ 0x845cb30]SSIM Mean Y:0.9792164
[libx264 @ 0x845cb30]kb/s:4734.3

encoding time: 638 seconds
41682932 bytes

with above options:
video:41764kB audio:1824kB global headers:0kB muxing overhead 0.101239%
[libx264 @ 0x845cb30]slice I:23 Avg QP:16.94 size: 35713
[libx264 @ 0x845cb30]slice P:1783 Avg QP:19.56 size: 17057
[libx264 @ 0x845cb30]slice B:1554 Avg QP:22.12 size: 7420
[libx264 @ 0x845cb30]mb I I16..4: 17.7% 44.8% 37.5%
[libx264 @ 0x845cb30]mb P I16..4: 6.7% 28.0% 4.4% P16..4: 34.8% 13.8% 4.1% 0.0% 0.0% skip: 8.1%
[libx264 @ 0x845cb30]mb B I16..4: 4.1% 0.0% 0.0% B16..8: 57.1% 1.9% 2.0% direct:10.0% skip:24.8%
[libx264 @ 0x845cb30]8x8 transform intra:65.0% inter:66.0%
[libx264 @ 0x845cb30]ref P 69.8% 15.5% 6.2% 3.5% 2.5% 2.6%
[libx264 @ 0x845cb30]ref B 65.6% 19.1% 7.5% 4.8% 3.0%
[libx264 @ 0x845cb30]SSIM Mean Y:0.9811319
[libx264 @ 0x845cb30]kb/s:5091.1

encoding time: 716 seconds
44680058 bytes

According to SSIM the quality is "slightly" better, havn't actually looked at the video yet...

Comments?

[Dark Shikari]

[libx264 @ 0x845cb30]SSIM Mean Y:0.9792164
[libx264 @ 0x845cb30]SSIM Mean Y:0.9811319
According to SSIM the quality is "slightly" better, havn't actually looked at the video yet... SSIM is logarithmic; that is vastly better. But the bitrate's higher tool, so its hard to judge.

i8x8 is very useful for quality, visually and metric-wise, and has little speed cost. It should always be on; wpred should basically always be on too.

Trellis=2... unless you're using psyrdo, trellis=1 is plenty.

[Tephra]

I understand about SSIM, but would you notice the quality difference between those two numbers?

I am doing another encode now without trellis, I suspect it was the cause of the increase in encoding time and bitrate... Will report back soon :)

not using psyrdo btw.. Would you recommend any addition/removal of options in my cmd line above?

[Tephra]

ok results for trellis = 0:

video:39659kB audio:1824kB global headers:0kB muxing overhead 0.106255%
[libx264 @ 0x845cb30]slice I:23 Avg QP:16.93 size: 35707
[libx264 @ 0x845cb30]slice P:1780 Avg QP:19.54 size: 16611
[libx264 @ 0x845cb30]slice B:1557 Avg QP:22.02 size: 6564
[libx264 @ 0x845cb30]mb I I16..4: 17.8% 44.5% 37.7%
[libx264 @ 0x845cb30]mb P I16..4: 6.8% 28.1% 4.4% P16..4: 34.5% 13.9% 4.1% 0.0% 0.0% skip: 8.2%
[libx264 @ 0x845cb30]mb B I16..4: 4.2% 0.0% 0.0% B16..8: 57.9% 1.9% 2.0% direct: 9.5% skip:24.6%
[libx264 @ 0x845cb30]8x8 transform intra:64.7% inter:63.6%
[libx264 @ 0x845cb30]ref P 70.6% 15.2% 6.1% 3.3% 2.4% 2.5%
[libx264 @ 0x845cb30]ref B 66.1% 18.7% 7.5% 4.7% 3.0%
[libx264 @ 0x845cb30]SSIM Mean Y:0.9797564
[libx264 @ 0x845cb30]kb/s:4834.4

encoding time: 647 seconds
42524003 bytes

[Dark Shikari]

I understand about SSIM, but would you notice the quality difference between those two numbers?A good way to compare SSIMs at the same bitrate is to do (1 - old SSIM) / (1 - new SSIM). If the result is 1.05, for example, the new SSIM is 5% better. However, note that in my opinion SSIM is completely useless as a visual metric, so don't use it to compare things like AQ and psy-RDO.
I am doing another encode now without trellis, I suspect it was the cause of the increase in encoding time and bitrate... Will report back soon :)Trellis 2 is vastly more expensive than trellis 1. Note, however, if you use subme < 6, trellis 2 does nothing (and automatically is dropped to 1).

[Tephra]

Hrmm ok - interesting - does trellis (1 or 2) mean better quality? i would hope so given the increase in bytes..

I am just updating to latest git/svn now so will rerun to see if anything changed there b4 continuing.

edit - slight improvement in encoding time, 630s down from 647s... same bytes/SSIM

[Tephra]

Just a general question.

When comparing 2 encodes, is it ok to look at individual frames for quality differences? ie same frame in both encodes?

Or is it much better to view the video as a whole?

Cheers
D.

[Dark Shikari]

Just a general question.

When comparing 2 encodes, is it ok to look at individual frames for quality differences? ie same frame in both encodes?

Or is it much better to view the video as a whole?

Cheers
D.Its generally safe to work at the same frame as long as both encodes used the same frametype for each one.

[Tephra]

Yup well I assume it will be the same frame type as all I am changing is CRF :)

Thanks by the way - you have been very helpful :)

[Tephra]

ahh crap - one last thing, I changed my destination container format from mkv to mp4 (trying for better compatability) and I get this error from ffmpeg:

[mp4 @ 0x8444520]track 1: could not find tag for codec
Could not write header for output file #0 (incorrect codec parameters ?)

anyone?

edit - seems to be related to my audio options, does mp4 allow any type of audio codec? it didn't like mp2...

[Tephra]

ok last problem I swear:

mp4 vs mkv

when I change the output file from .mkv to .mp4 - the aspect ratio goes out the window, I have tried setting it manually but it doesn't help..

What am I doing wrong?

[foxyshadis]

Just ffmpeg's lousier mp4 support. You'll have to remux it with mp4box or mp4creator if you want an aspect ratio.

This may not still be the case - last time I encoded to mp4 with ffmpeg was well over a year ago - in which case it might be your mp4 splitter/decoder instead.

And yes, mp4 is very restricted as to possible audio formats. MP2 is one of them, but AC3 isn't - are you sure the .mpg actually has mp2 audio? (it might just be that ffmpeg doesn't know how to mux mp2 into mp4 also, I forget whether it can.)

[teddg]

thanks guys.

Ted what are your sources?

also why only 3 bframes?

Sources - usually DVD backups, but occasional HD stuff (http://www.nasa.gov/multimedia/hd/index.html).

3 bframes - I think that was for hardware compatibility in some example I was referencing - changing to 16 :)

[Ranguvar]

Yup well I assume it will be the same frame type as all I am changing is CRF :)
I don't think that's correct - first, I think you're confusing the quantizers with frame-types (I, P, or B). Second, only CQ has the same quantizer across the board anyways.

You need to use a separate tool to see what type of frame is in each encode :)