flaccidware / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

vp9 encoding in ffmpeg undershooting and by a lot #1034

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Default parms in ffmpeg produce large undershoot on this file.

report    

http://demo.jwplayer.com/jluther/mobile-h264.mp4

./ffmpeg -y -i mobile-h264.mp4 \
-c:v libvpx-vp9 -pass 2 \
-vf scale=-2:480 -b:v 650k \
-keyint_min 150 -g 150 \
-tile-columns 4 -frame-parallel 1 \
-auto-alt-ref 1 -lag-in-frames 25 \
-undershoot-pct 5 -qmin 0 \
-an -f webm -dash 1 \
-threads 8 -speed 1 \
mobile-h264-480p-650kbps.webm 

See here : 
https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/1wShoyt56
sQ

Original issue reported on code.google.com by jimbankoski@google.com on 9 Jul 2015 at 3:57

GoogleCodeExporter commented 8 years ago
I suggest building ffmpeg from the tip-of-tree. There have been changes lately 
to how rate control parameters are passed down to libvpx from ffmpeg. Extreme 
undershoot issues are likely related to that with an older version of ffmpeg.

Having built the tip of tree ffmpeg with the tip of tree libvpx today, here are 
my results with default parameters (I do not expect any material difference 
with libvpx 1.4.0).

400 kbps:
---------
./ffmpeg -y -i mobile-h264.mp4 \
-c:v libvpx-vp9 -pass 1 \
-vf scale=-2:480 -b:v 400k \
-keyint_min 150 -g 150 \
-tile-columns 4 -frame-parallel 1 \
-auto-alt-ref 1 -lag-in-frames 25 \
-qmin 0 -an -f webm -dash 1 \
-threads 8 -speed 1 \
/dev/null 

./ffmpeg -y -i mobile-h264.mp4 \
-c:v libvpx-vp9 -pass 2 \
-vf scale=-2:480 -b:v 400k \
-keyint_min 150 -g 150 \
-tile-columns 4 -frame-parallel 1 \
-auto-alt-ref 1 -lag-in-frames 25 \
-qmin 0 -an -f webm -dash 1 \
-threads 8 -speed 1 \
mobile-h264-480p-650kbps.webm 

frame= 1944 fps=8.6 q=0.0 Lsize=    3746kB time=00:01:21.08 bitrate= 
378.5kbits/s

650 kbps:
---------
./ffmpeg -y -i mobile-h264.mp4 \
-c:v libvpx-vp9 -pass 1 \
-vf scale=-2:480 -b:v 650k \
-keyint_min 150 -g 150 \
-tile-columns 4 -frame-parallel 1 \
-auto-alt-ref 1 -lag-in-frames 25 \
-qmin 0 -an -f webm -dash 1 \
-threads 8 -speed 1 \
/dev/null 

./ffmpeg -y -i mobile-h264.mp4 \
-c:v libvpx-vp9 -pass 2 \
-vf scale=-2:480 -b:v 650k \
-keyint_min 150 -g 150 \
-tile-columns 4 -frame-parallel 1 \
-auto-alt-ref 1 -lag-in-frames 25 \
-qmin 0 -an -f webm -dash 1 \
-threads 8 -speed 1 \
mobile-h264-480p-650kbps.webm

frame= 1944 fps=7.7 q=0.0 Lsize=    6003kB time=00:01:21.08 bitrate= 
606.5kbits/s

Since the default values for rc_undershoot_pct and rc_overshoot_pct are 25 (%) 
each, the achieved bitrate is well within these limits. 

You can make the rate control tighter by using -undershoot-pct and 
-overshoot-pct parameters. However, these parameters are not 'strictly' 
enforced, and there is a tendency to resist the default behavior. For instance, 
if you requested 650 kbps and used -undershoot_pct 5, you will still get 608 
Kbps (-6.5%); and if you used -undershoot_pct 1 (-3.4%), you will get 628 kbps. 
But the trend is to get tighter.

Original comment by debar...@google.com on 9 Jul 2015 at 6:32

GoogleCodeExporter commented 8 years ago
Thanks, Debargha. Can you post your ffmpeg build settings (./configure 
commands, etc.) so I can try to reproduce on my machine?

Using your target 400Kbps settings with the latest ffmpeg static build from git 
(http://johnvansickle.com/ffmpeg/builds/ffmpeg-git-64bit-static.tar.xz, 
g7b404c9 built on 20150710), I got 334Kbps.

Targeting 650K, I got 530.

JL

Original comment by jlut...@jwplayer.com on 10 Jul 2015 at 5:31

GoogleCodeExporter commented 8 years ago
Also, using "-undershoot-pct 5" on this build results in 366 and 580, 
respectively.

JL

Original comment by jlut...@jwplayer.com on 10 Jul 2015 at 6:20

GoogleCodeExporter commented 8 years ago
I am attaching a ffmpeg build script that I used.

Original comment by debar...@google.com on 10 Jul 2015 at 6:31

Attachments:

GoogleCodeExporter commented 8 years ago
OK, thanks very much.

JL

Original comment by jlut...@jwplayer.com on 10 Jul 2015 at 6:39