Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th April 2010, 23:00   #1  |  Link
Pencil5
Registered User
 
Join Date: Aug 2009
Posts: 5
My Lowbitrate Settings

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.

Code:
--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"
Code:
--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.
Pencil5 is offline   Reply With Quote
Old 24th April 2010, 23:08   #2  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 6,232
why 500kbps and why --deblock -2:-1 and --qcomp=1.00 ????
Atak_Snajpera is offline   Reply With Quote
Old 24th April 2010, 23:16   #3  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
That entire commandline is nonsense. Why are you overriding the presets with worse options?
Dark Shikari is offline   Reply With Quote
Old 25th April 2010, 00:06   #4  |  Link
me7
Registered User
 
Join Date: Mar 2007
Posts: 216
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.
me7 is offline   Reply With Quote
Old 25th April 2010, 01:30   #5  |  Link
Pencil5
Registered User
 
Join Date: Aug 2009
Posts: 5
Quote:
Originally Posted by Atak_Snajpera View Post
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...

Quote:
Originally Posted by Dark Shikari View Post
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.

Quote:
Originally Posted by me7 View Post
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.

Last edited by Pencil5; 25th April 2010 at 01:45.
Pencil5 is offline   Reply With Quote
Old 25th April 2010, 11:30   #6  |  Link
Firebird
Registered User
 
Join Date: Mar 2008
Posts: 61
Quote:
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"
Firebird is offline   Reply With Quote
Old 25th April 2010, 12:02   #7  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,811
Quote:
Originally Posted by Pencil5 View Post
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

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.

Quote:
Originally Posted by Pencil5 View Post
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"

Quote:
Originally Posted by Pencil5 View Post
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...

Quote:
Originally Posted by Pencil5 View Post
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:

Code:
--preset veryslow --fps $fps --pass [1|2] --bitrate $vbit --stats "$stats.stats" --sar 1:1 --aq-mode 2 --output [NUL|"$newname.264"] "$avs.avs"
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 25th April 2010 at 12:18.
LoRd_MuldeR is offline   Reply With Quote
Old 25th April 2010, 12:51   #8  |  Link
MatLz
I often say "maybe"...
 
MatLz's Avatar
 
Join Date: Jul 2009
Location: France
Posts: 586
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?...)
MatLz is offline   Reply With Quote
Old 25th April 2010, 12:57   #9  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,811
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 ^^)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 25th April 2010, 13:42   #10  |  Link
MatLz
I often say "maybe"...
 
MatLz's Avatar
 
Join Date: Jul 2009
Location: France
Posts: 586
Quote:
Originally Posted by Pencil5 View Post
500kbps - Smaller/less storage
I 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 is offline   Reply With Quote
Old 25th April 2010, 13:48   #11  |  Link
MatLz
I often say "maybe"...
 
MatLz's Avatar
 
Join Date: Jul 2009
Location: France
Posts: 586
Quote:
Originally Posted by LoRd_MuldeR View Post
You are right!
it's not often!
Quote:
Originally Posted by LoRd_MuldeR View Post
(BTW: I'd consider 500 kbps a "low bitrate" for anything above CIF size ^^)
and depending on the complexity┐
MatLz is offline   Reply With Quote
Old 25th April 2010, 16:22   #12  |  Link
julius666
Registered User
 
julius666's Avatar
 
Join Date: May 2009
Location: Hungary
Posts: 75
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
julius666 is offline   Reply With Quote
Old 25th April 2010, 17:11   #13  |  Link
creamyhorror
Registered User
 
Join Date: Mar 2008
Posts: 118
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
creamyhorror is offline   Reply With Quote
Old 25th April 2010, 18:45   #14  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,301
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
Blue_MiSfit is offline   Reply With Quote
Old 26th April 2010, 00:03   #15  |  Link
Pencil5
Registered User
 
Join Date: Aug 2009
Posts: 5
Quote:
Originally Posted by LoRd_MuldeR View Post
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?
Pencil5 is offline   Reply With Quote
Old 26th April 2010, 00:08   #16  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,811
Quote:
Originally Posted by Pencil5 View Post
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).
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 26th April 2010, 03:37   #17  |  Link
Pencil5
Registered User
 
Join Date: Aug 2009
Posts: 5
Quote:
Originally Posted by LoRd_MuldeR View Post
"--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

Last edited by Pencil5; 26th April 2010 at 03:57.
Pencil5 is offline   Reply With Quote
Old 26th April 2010, 04:42   #18  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,301
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.

Last edited by Blue_MiSfit; 26th April 2010 at 04:46.
Blue_MiSfit is offline   Reply With Quote
Old 26th April 2010, 15:50   #19  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,811
Quote:
Originally Posted by Pencil5 View Post
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...

Quote:
Originally Posted by Pencil5 View Post
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
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 26th April 2010 at 18:43.
LoRd_MuldeR is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.