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. |
28th October 2017, 02:38 | #1 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
Optimizing VP9 encoding for ultra low bitrate
Hey folks!!
I'm looking to optimize VP9 compression to target a very low bitrate scenario - specifically 150 Kbps average bitrate. Resolution is flexible, but we're probably shooting for 428x240. The use case is offline playback, so pure unrestricted 2 pass VBR is probably ideal. Thoughts, other than just using -quality best and -speed 0? Some of the content will be animated, so anything similar to x264's --tune animation would probably be useful. I see some AQ modes listed in ffmpeg for libvpx-vp9, is there any consensus on those? Thanks in advance! |
28th October 2017, 11:11 | #2 | Link |
Registered User
Join Date: May 2002
Posts: 95
|
My recomenation:
Filter the video with a noise reduction filter ("nlmeans" in medium preset is a good option), this helps reduce the bitrate needs and as the birate is very low shoftening the video is a plus as it prevent blocking artifacs. Use 10bit video in the encoding, it helps with banding and blockines in the dark regions specially at this low bitrate. When downscalig select a algorithm good for downscaling and adecuate for the content, "bilinear", "area" and "sinc" are my prefered options. Only the aq0 (none) aq1 (variance, based on the complexity variance in a frame) and aq2 (complexity, based on the computational cost) are somewhat recomendable, for me is better to use aq0 or aq1, and my preference is aq1, aq3 is for videoconferency but it can be useful for presentations, aq4 is a no. This is an example of a batch in windows with my preferences: Code:
@@:LOOP "D:\media-autobuild_suite\local64\bin-video\ffmpeg.exe" -i %1 -map 0 -c copy -c:v libvpx-vp9 -pass 1 -passlogfile "%~dpn1.log" -b:v 150K -threads 1 -deadline good -cpu-used 4 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 24 -g 9600 -aq-mode 1 -sws_dither none -pix_fmt yuv420p10le -filter:v nlmeans=s=6:p=5:r=7,scale=w=428:h=240:force_original_aspect_ratio=decrease:sws_flags=area:sws_dither=none,crop=trunc(iw/2)*2:trunc(ih/2)*2:0:0 -an -f null NUL "D:\media-autobuild_suite\local64\bin-video\ffmpeg.exe" -i %1 -map 0 -c copy -c:v libvpx-vp9 -pass 2 -passlogfile "%~dpn1.log" -b:v 150K -threads 1 -deadline good -cpu-used 1 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 24 -g 9600 -aq-mode 1 -sws_dither none -pix_fmt yuv420p10le -filter:v nlmeans=s=6:p=5:r=7,scale=w=428:h=240:force_original_aspect_ratio=decrease:sws_flags=area:sws_dither=none,crop=trunc(iw/2)*2:trunc(ih/2)*2:0:0 -c:a libopus -b:a 32k -ac 2 -f webm "%~dpn1.webm" @shift @if not (%1)==() goto LOOP pause in the vp9 option "-threads 1" force the use only one thread and "ntile-columns 0 -frame-parallel 0" disable tiles and some frame parallelism witch boost quality at the cost of speed, also I use "-deadline good" because best don't guive actually better quality than good unles in very rare cases and sometimes the quality is also worse plus is much slower. Also this script is dumb and only work with square pixel and don't crop the video. It encodes the audio in opus at 32kbps, if ffmpeg uses libopus 1.2.x the quality is going to me more than acceptable and you can test the audio at 24kbps to view it is acceptable for you. Edit: batch change to make the video dimensions always mod2 after the scaling. Last edited by Phanton_13; 28th October 2017 at 21:21. |
30th October 2017, 04:26 | #3 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
@Phanton_13
Thank you for the notes! Super helpful. I'll look into some testing here. I've found that out of the box so far x264 gives more stable results in this use case, even if vp9 is more detailed in some scenes. When vp9 fails it seems to fail quite spectacularly, whereas x264 is quite consistent. I'll try your recommendations out! |
1st November 2017, 16:32 | #5 | Link |
Registered User
Join Date: May 2002
Posts: 95
|
After testing vp9 with limited max quant: it helps a lot.
I tested VP9 with two videos and found that limiting the max quantification can prevent VP9 to fail misserably but at the same time it penalizes the bitrate for 854x480 video up to 50% using -qmax 36 depending of various factors but more in the line of a max of 25% of the target bitrate, for 426x240 the penalization at -qmax 36 virtually don't exist in comparison with the target bitrate. And even at -qmax 48 de quality in comparison with when vp9 screws is much highter in the same part. Also I found that at 150kbps at a resolution of 854x480 is really workable and even cosidering that with the penalization of -qmax 36 the bitrate is bellow 200 Kbps in the samples the result is really good.
854x480 anime target 150kbps -aq-mode 2 : 124 Kbps -aq-mode 1 : 127 Kbps -aq-mode 0 : 128 Kbps -qmax 36 -aq-mode 0: 186 Kbps -qmax 42 -aq-mode 0: 163 Kbps -qmax 48 -aq-mode 0: 154 Kbps 426x240 anime target 150kbps -qmax 36 -aq-mode 0: 146 Kbps -qmax 42 -aq-mode 0: 137 Kbps 854x356 movie target 150kbps -aq-mode 2 : 124 Kbps -aq-mode 1 : 131 Kbps -aq-mode 0 : 141 Kbps -qmax 36 -aq-mode 0: 168 Kbps -qmax 42 -aq-mode 0: 156 Kbps -qmax 48 -aq-mode 0: 153 Kbps 428x178 movie target 150 Kbps -qmax 36 -aq-mode 0: 153 Kbps -qmax 42 -aq-mode 0: 145 Kbps |
3rd November 2017, 02:28 | #6 | Link |
Registered User
Join Date: Aug 2015
Posts: 34
|
If you can at all manage, you should try one of the --end-usage=q --cq-level=x (ideally with two pass enabled, unlike x265, it does do something in "crf" mode). You'll avoid the crazy jumps in quality from frame to frame. Of course, you're no longer rate controlled, so this may be totally unviable for your application...
|
Thread Tools | Search this Thread |
Display Modes | |
|
|