My Lowbitrate Settings

[Pencil5]

Any tweaks I should make to these settings? I usually encode at ~500kbps and have tested these pretty thoroughly using VideoCheck, but always love new suggestions. I filter with Undot() and Unfilter(-5,-5) to increase compressibility without adding overhead or removing (important) details.

--profile high --preset slow --fps $fps --pass 1 --bitrate $vbit --stats "$stats.stats" --thread-input --deblock -2:-1 --sar 1:1 --me umh
--subme 6 --bframes 16 --b-pyramid normal --b-adapt=1 --trellis 1 --aq-mode=2 --qcomp=1.00 --output NUL "$avs.avs"

--profile high --preset slow --fps $fps --pass 2 --bitrate $vbit --stats "$stats.stats" --thread-input --deblock -2:-1 --sar 1:1 --me umh
--subme 6 --bframes 16 --b-pyramid normal --b-adapt=1 --trellis 1 --aq-mode=2 --qcomp=1.00 --aud --output "$newname.264" "$avs.avs"

Thanks.

[Atak_Snajpera]

why 500kbps and why --deblock -2:-1 and --qcomp=1.00 ????

[Dark Shikari]

That entire commandline is nonsense. Why are you overriding the presets with worse options?

[me7]

If you want to optimize the "slow" preset for low bitrates, you should override the settings with values that increase efficiency rather then reduce it or even better: just use a slower preset.
Raising bframes to 16 is overkill while lowering subme to 6 reduces quality, if you want to improve things you should raise subme and THEN raise bframes if you're still willing to sacrifice more speed (but there are still other settings that give you a bigger efficiency gain then bframes 16). Why deblock -2:-1? Negative debock values aren't great for low bitrates.

[Pencil5]

why 500kbps and why --deblock -2:-1 and --qcomp=1.00 ????

500kbps - Smaller/less storage/play on my netbook
deblock - Slightly sharper (was told at low bitrates this prevents lost details)
qcomp - It weakens mbtree (was told this prevents blocking in dark areas)

At least, these are my justifications for these settings...

That entire commandline is nonsense. Why are you overriding the presets with worse options?

I'm open to suggestions, and I gleaned most by reading a ton from various sources. I don't exactly have working knowledge yet which is why I am asking. Biggest difficulty is that I couldn't find a visual guide (like Scintilla's for avisynth), so it's all theory and limited personal testing. It's hard to find a decent guide for beginners that isn't "fire up MeGUI and press A, B and C", and the wikis aren't comprehensive enough to explain benefits/negatives for low bitrate encoding. I assure you, I have spent hours on the subject and wrote a perl conversion script so I could better understand the encoding process. We all gotta start somewhere.

If you want to optimize the "slow" preset for low bitrates, you should override the settings with values that increase efficiency rather then reduce it or even better: just use a slower preset.
Raising bframes to 16 is overkill while lowering subme to 6 reduces quality, if you want to improve things you should raise subme and THEN raise bframes if you're still willing to sacrifice more speed (but there are still other settings that give you a bigger efficiency gain then bframes 16). Why deblock -2:-1? Negative debock values aren't great for low bitrates.

So would it be better to: use the 'slower' preset (how much of a difference does this make?), deblock 0:0, 8 bframes and increase subme to 8 or 9? I have an overclocked quad so speed isn't too serious of an issue. Since you seem to know a bit about lower bitrates, do you have any filter suggestions?

Thank you very much for the suggestions. I really do appreciate it.

[Firebird]

I don't exactly have working knowledge yet which is why I am asking.
So that's why we have presets in x264. Slower the preset --> better the compression, simple as it is. And yes, lowering deblock on low bitrates isn't really a good idea.
So your command line should be something like:
--preset slower --tune Film/animation --bitrate 500 --pass 1 --aq-mode 2 -o NUL "input.avs"
--preset slower --tune Film/animation --bitrate 500 --pass 2 --aq-mode 2 -o "output.mkv" "input.avs"

[LoRd_MuldeR]

deblock - Slightly sharper (was told at low bitrates this prevents lost details)

First of all, the In-Loop Deblocking exists to prevent ugly blocking artifacts.

At high bitrates it makes sense indeed to lower Deblock in order to retain more sharpness, because blocking isn't really an issue there.

But at ultra-low bitrates are a completely different story! If you cannot preserve much detail anyway, lowering Deblock will probably make things look even worse :rolleyes:

I'd keep Deblock at default, i.e. 0:0, for ultra-low bitrates. Or I'd even try to raise it to 1:1.

qcomp - It weakens mbtree (was told this prevents blocking in dark areas)

You generally should never touch qcomp, unless you know exactly what you are doing!

Also MB-Tree probably gives the most benefit at ultra-low bitrates, so why the heck do you want to "weaken" it ???

At 500 kbps you will have more serious problems than "blocking in dark areas" :p

So would it be better to: use the 'slower' preset (how much of a difference does this make?), deblock 0:0, 8 bframes and increase subme to 8 or 9?

You can even use SubMe=10, if quality is important and speed isn't an issue. Deblock 0:0 sounds reasonable.

Using 8 b-frames should be sufficient. Going even higher never hurts, but probably doesn't give much benefit either.

If you have enough the (processor) time to waste, why not...

I have an overclocked quad so speed isn't too serious of an issue.

If speed doesn't matter, use --preset veryslow and do NOT overwrite any "speed -vs- quality" options. It's that simple ;)

You entire command-line can be reduced to:

--preset veryslow --fps $fps --pass [1|2] --bitrate $vbit --stats "$stats.stats" --sar 1:1 --aq-mode 2 --output [NUL|"$newname.264"] "$avs.avs"

[MatLz]

Maybe I missed something but can we say '500kbps is a low bitrate' if we don't know the resolution or the complexity of the videos the user want to encode?

(Aren't 500kbps overkill for 320x240 flat anime content?...:D)

[LoRd_MuldeR]

You are right! But since he didn't specify the content he's encoding, I'd assume PAL/NTSC resolution at least. He also asked for "Lowbitrate Settings" explicitly, so...

(BTW: I'd consider 500 kbps a "low bitrate" for anything above CIF size ^^)

[MatLz]

500kbps - Smaller/less storageI suggest one thing:
Don't encode each video at 500kbps but the more possible appended videos at this bitrate to have an optimal repartition of bits. Use a .qf file to force a keyframe insertion at the beginning of each and split after the encoding.

[MatLz]

You are right!it's not often!:)
(BTW: I'd consider 500 kbps a "low bitrate" for anything above CIF size ^^)and depending on the complexity¿

[julius666]

You generally should never touch qcomp, unless you know exactly what you are doing!

Also MB-Tree probably gives the most benefit at ultra-low bitrates, so why the heck do you want to "weaken" it ???


Well, the default (0.6) for qcomp is rather low, the optimal value would be somewhere around 0.7, for low-bitrates even higher (0.72-0.78 maybe).
Of course 1.0 is really overkill.

[creamyhorror]

You generally should never touch qcomp, unless you know exactly what you are doing!
This is tangential, but I'd like to learn more about qcomp. I asked in another thread but didn't get an answer:

1) When should qcomp be lowered or raised?
2) Does qcomp roughly correlate with the variance of the average quantizer?
3) What are the implications of raising/lowering qcomp for detail and grain retention?
4) Any use in reducing the variance of bitrate under CRF?

I hope someone can shed some light on it, because it does seem like a pretty powerful and potentially useful option. So far, raising it seems to improve detail+grain retention (and bitrate), as might be expected since 1.0 represents constant quantizer.

[Blue_MiSfit]

1) Basically never, unless you think you're smarter than x264 at making rate control decisions
2) It roughly correlates with bitrate variance (as I understand). This does NOT correspond to quality
3) The encoder is highly adaptive. If you screw with its decision making strategies, you will probably get sub optimal results
4) Not in my opinion. If you need to reduce the variance of bitrate using CRF, use VBV to limit local bitrate.

~MiSfit

[Pencil5]

You are right! But since he didn't specify the content he's encoding, I'd assume PAL/NTSC resolution at least. He also asked for "Lowbitrate Settings" explicitly, so...

(BTW: I'd consider 500 kbps a "low bitrate" for anything above CIF size ^^)

The content is primarily NTSC film at 640x480. VHS > Upscaled to 1080p > Archived on computer @ 640x480, Camcorder and various digital cameras/ipod nano for archive @ 640x480.

What about the b-adapt, trellis and b-pyramid settings?

[LoRd_MuldeR]

The content is primarily NTSC film at 640x480. VHS > Upscaled to 1080p > Archived on computer @ 640x480, Camcorder and various digital cameras/ipod nano for archive @ 640x480.

What about the b-adapt, trellis and b-pyramid settings?

"--b-adapt" and "--trellis" are already covered by the "--preset" option. No need to overwrite them.

And "--b-pyramid" defaults to "--b-pyramid normal", which should be kept that way (unless you are encoding for BluRay).

[Pencil5]

"--b-adapt" and "--trellis" are already covered by the "--preset" option. No need to overwrite them.

And "--b-pyramid" defaults to "--b-pyramid normal", which should be kept that way (unless you are encoding for BluRay).

I think I'm finally down to two questions. Should psy-rd be touched since it's low-bitrate film (I know the --tune film changes it)?


Is b-adapt 2 or more b-frames better? And why the low CPU with b-adapt 2?

b-adapt 1 and b-frames 8 = 250fps@90%CPU
b-adapt 2 and b-frames 8 = 30fps@30% CPU
b-adapt 2 and b-frames 5 = 110fps@50%CPU

[Blue_MiSfit]

b-adapt 2 is better, but a lot slower, and it gets EVEN slower the more b-frames you use.

With b-adapt 1, you should just use the default of 16 bframes, since this will be the fastest and best quality option (without going to b-adapt 2). Unless of course your playback device doesn't support that many b-frames.

[LoRd_MuldeR]

I think I'm finally down to two questions. Should psy-rd be touched since it's low-bitrate film (I know the --tune film changes it)?

Psy-RD tries to keep more details/sharpness, even if that means more "distortion" (PSNR-wise). That should be helpful at low bitrates to retain a certain amount of details, instead of smoothing out everything. If you don't trust the default Psy-RD strength, you should do some experiments yourself. That's definitely not a "more is better" option! You need to find the sweet spot...

Is b-adapt 2 or more b-frames better? And why the low CPU with b-adapt 2?

"--bframes" restricts the maximum number of consecutive b-frames. The more b-frames you allow, the better. It never hurts! However at a certain point allowing even more b-frames will give near-zero benefit. Therefore "--bframes 16" certainly doesn't hurt, but it isn't any better than "--bframes 8" in most cases. At the same time "--b-adapt" selects the method that is used by x264 to determine the "optimal" number of consecutive b-frames. This of course will never exceed the "--bframes" limit. Also the "--b-adapt 2" method is much better than "--b-adapt 1", but it's also much slower! Since the speed of the "--b-adapt 2" method depends on the maximum number of b-frames, it makes sense to use "--b-adapt 2" in combination with a reasonable "--bframes" limit. You can also use the x264 output at the end of the encode to check how many b-frames have actually been used. If you see that x264 rarely used more than ~5 consecutive b-frames, it probably doesn't make sense to use a limit as high as 16 ;)