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. |
24th April 2010, 23:00 | #1 | Link |
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" |
24th April 2010, 23:08 | #2 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
why 500kbps and why --deblock -2:-1 and --qcomp=1.00 ????
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
25th April 2010, 00:06 | #4 | Link |
Registered User
Join Date: Mar 2007
Posts: 217
|
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. |
25th April 2010, 01:30 | #5 | Link | ||
Registered User
Join Date: Aug 2009
Posts: 5
|
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:
Quote:
Thank you very much for the suggestions. I really do appreciate it. Last edited by Pencil5; 25th April 2010 at 01:45. |
||
25th April 2010, 11:30 | #6 | Link | |
Registered User
Join Date: Mar 2008
Posts: 61
|
Quote:
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" |
|
25th April 2010, 12:02 | #7 | Link | ||||
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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:
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:
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:
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"
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 25th April 2010 at 12:18. |
||||
25th April 2010, 12:51 | #8 | Link |
I often say "maybe"...
Join Date: Jul 2009
Location: France
Posts: 583
|
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?...) |
25th April 2010, 12:57 | #9 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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 ^^)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
25th April 2010, 13:42 | #10 | Link |
I often say "maybe"...
Join Date: Jul 2009
Location: France
Posts: 583
|
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. |
25th April 2010, 16:22 | #12 | Link | |
Registered User
Join Date: May 2009
Location: Hungary
Posts: 79
|
Quote:
Of course 1.0 is really overkill. |
|
25th April 2010, 17:11 | #13 | Link | |
Registered User
Join Date: Mar 2008
Posts: 118
|
Quote:
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. |
|
25th April 2010, 18:45 | #14 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
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
__________________
These are all my personal statements, not those of my employer :) |
26th April 2010, 00:03 | #15 | Link | |
Registered User
Join Date: Aug 2009
Posts: 5
|
Quote:
What about the b-adapt, trellis and b-pyramid settings? |
|
26th April 2010, 00:08 | #16 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
And "--b-pyramid" defaults to "--b-pyramid normal", which should be kept that way (unless you are encoding for BluRay).
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
26th April 2010, 03:37 | #17 | Link | |
Registered User
Join Date: Aug 2009
Posts: 5
|
Quote:
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. |
|
26th April 2010, 04:42 | #18 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
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.
__________________
These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 26th April 2010 at 04:46. |
26th April 2010, 15:50 | #19 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
"--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
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 26th April 2010 at 18:43. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|