vp9 bitrate undershoot

[GoogleCodeExporter]

vp9 produces videos with too low bit rate, and hence lower quality, than 
specified, when the content is 'easy'.

Other codecs achieve the bitrate and quality specified.

Lowering bitrate doesn't always help.  On graytone, if you ask for the bitrate 
that it actually achieved, it undershoots even more, and quality goes down 
further.

This occurs on content where quality is roughly PSNR of 44 or higher.

see testmatrix spreadsheet for details of undershoot.  Here is how much:
Name    VP9 Size Error
3dtv    0.26%
avatar  0.94%
avatar3d    0.96%
worldwarz   1.63%
bbee    -0.41%
bear    6.55%
bikes   -0.04%
birds   0.55%
brian   99.84%
buck    -0.04%
chicken 0.44%
color   0.11%
crowd   0.89%
dance   0.31%
dartmoor    0.36%
graytone    80.55%
ironman 2.67%
mobile  0.95%
parkrun 3.07%
pitivi  56.10%
qjoe    1.59%
red 0.43%
scout3d -0.11%
small   8.20%
sonyh   -0.25%
still   1.71%
sync    43.89%
trek    1.62%
tulip   -0.10%
wembly  0.59%
surround    70.20%

Original issue reported on code.google.com by fbarch...@google.com on 19 Jan 2013 at 1:14

[GoogleCodeExporter]

On graytone, vp9 gets about 20 kbits losslessly, if I specify 200 kbits.
But if I specify 150 kbits or less, it compresses smaller and looses some 
quality.

Both vbr and cbr are same.  Example command line:
e:\mediatests\graytone>vpxenc.exe --codec=vp9 --verbose --fps=30000/1000 --good 
--cpu-used=0 --lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr 
--auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 
--static-thresh=0 --bias-pct=50 --minsection-pct=10 --maxsection-pct=800 
--arnr-maxframes=7 --arnr-strength=3 --arnr-type=3 --sharpness=0 
--undershoot-pct=100 --psnr -w854 -h 480 --target-bitrate=200 
graytone.854x480_30Hz_P420.yuv -o graytone0.vp9.webm

Original comment by fbarch...@google.com on 22 Jan 2013 at 5:35

[GoogleCodeExporter]

pitivi video is an interesting example of undershoot

When 2000 kbits is requested
80,037,500 bytes is expected file size.
35,138,264 bytes is actual size.

When 1000 kbits is requested
40,018,750 bytes is expected file size.
21,887,234 bytes is actual size.

When 500 kbits is requested
20,009,375 bytes is expected file size.
12,746,821 bytes is actual size.

Both VP8 and VP9 exhibit this behavior, but x264 does not.

Original comment by fbarch...@google.com on 26 Feb 2013 at 1:41

[GoogleCodeExporter]

Encode to VP9:

./vpxenc -v --target-bitrate=600 -o skyrim-vp9-600kbps.webm --codec=vp9 
Skyrim.y4m

Decode VP9:

./vpxdec skyrim-vp9-600kbps.webm --yv12 --progress -v -o skyrim-vp9-600kbps.y4m
WebM Project VP9 Decoder v1.2.0-1610-g1e8b3da
2253 decoded frames/2253 showed frames in 15902642 us (141.67 fps)

The problem:

File size:
after 1 day of encoding... I got my first VP9 file, but it's size looks 
questionable at 1.1 MB vs 4.7 MB for VP8 (same bitrate of 600 kbps).
Needless to say, that VP8 achieved better results.

Original comment by al4...@gmail.com on 13 Mar 2013 at 10:36

[GoogleCodeExporter]

I reduced my bitrate targets, since VP9 is roughly 40% better than VP8.

The experimental branch is a little better... I suspect due to 'lossless' 
encoding on simple frames.  But experimental doesn't work with Chrome.

Name   VP9 Size Error    Size VP9     Size Target   Target bits
3dtv       0.24%       15,304,421      15,342,000      1200
avatar     0.49%       31,508,262      31,663,500      1200
avatar3d   0.13%       31,196,011      31,237,500      1200
worldwarz  0.12%       36,534,701      36,577,500      2000
bbee       -1.46%       8,513,506       8,391,250      1000
bear       4.72%          130,529         137,000       400
bikes      0.33%       21,099,148      21,170,000      2000
birds      0.20%        5,327,069       5,337,500      2000
brian      -0.55%     275,624,639     274,116,500       400
buck       -0.05%      59,674,676      59,646,000       800
chicken    0.01%       30,694,553      30,699,000      1200
color      -0.15%       3,060,471       3,056,000       800
crowd      0.53%        9,946,903      10,000,000      8000
dance      -0.09%      73,222,865      73,157,500      2000
dartmoor   0.05%       20,060,104      20,070,000      1200
garden     0.41%       84,923,459      85,275,000      6000
graytone  49.18%            7,941          15,625        25
ironman    19.70%       5,209,616       6,487,571      1200
mobile     1.18%          988,194       1,000,000       800
parkrun    0.64%       10,015,509      10,080,000      8000
pitivi     14.93%      17,022,300      20,009,375       500
qjoe       0.93%       12,000,252      12,112,500      2000
red        -0.09%      31,975,826      31,947,500      2000
scout3d    -0.03%      32,110,855      32,100,000       800
small      -4.17%          14,271          13,700        40
sonyh      -0.96%   1,886,869,665   1,868,867,500      2000
still      -6.23%          99,595          93,750       750
sync       7.03%        2,093,992       2,252,250       100
trek       1.30%        4,507,928       4,567,500      1200
tulip      -0.21%       2,507,324       2,502,000      1200
wembly     -0.23%      21,427,637      21,379,500      1200
surround   56.95%         984,712       2,287,500       100
snow       0.03%       50,720,064      50,735,000      2000

graytone achieves lossless, so undershoot is okay.

Original comment by fbarch...@chromium.org on 14 Mar 2013 at 12:42

[GoogleCodeExporter]

VP9 bitstream is not yet finalized 

Original comment by albe...@google.com on 14 Mar 2013 at 10:27

• Changed state: Available
• Added labels: Mstone-12

[GoogleCodeExporter]

The bitstream may require further changes to fix this.
Its the most common reason that VP9 produces lower quality than other codecs.
The improvement made so far (lossless), in experimental, has helped, but its 
not fully fixed.

Original comment by fbarch...@chromium.org on 15 Mar 2013 at 3:08