vp9 encode performance regression

[GoogleCodeExporter]

What is the expected behavior?
The sonyh video historically takes 449 hours to encode.

What do you see instead?
After 7 days, encoder says ETA 1783:40:03.  This is 3.96x slower.

What version are you using?
VP9 Encoder v1.3.0-469-gf69b560
Which is synced from head on evening of Dec 20, 2013.

On what operating system?
Windows7 64 bit, cross built with gcc on linux.

Can you reproduce using the vpxdec or vpxenc tools?
yes

What command line are you using?
e:\mediatests\sonyh>timex ..\vpxenc --cpu-used=0 -t 1 -w 1920 -h 800 
--fps=24000/1001 --target-bitrate=2000 sonyh.1920x800_24Hz_P420.yuv -o 
sonyh0.tmp.vp9.webm --fpf=sonyh_vp9.fpf -p 2 --pass=2 --codec=vp9 --good 
--lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr --auto-alt-ref=1 
--kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 
--bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 
--arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 -v --psnr

Please provide any additional information below.
Pass 2/2 frame 15360/15334 139117367B 600830588 ms 1.53 fpm [ETA 1784:04:31] 
45.511 44.867 45.793 49.252    2849F

Original issue reported on code.google.com by fbarch...@google.com on 28 Dec 2013 at 2:16

[GoogleCodeExporter]

5 additional videos are affected by more than 2x slower encodes
video     time compared to Nov 27 build - 100% being same.
worldwarz 249.40%
bear      672.96%
bikes     254.10%
dartmoor  222.59%
small     225.72%

It may relate to bitrate? If you graph encoding time vs size (see attachment), 
videos that went down in size encoded in the same time, while those that took 
longer to encode tended to be those that used to produce substantially smaller 
files.  Overall bitrate is 14.40% with dec 20 build vs 18.65% with nov 27 build.

When configuring, this is the output:

~/on2/win64$ CROSS=x86_64-w64-mingw32- ../libvpx/configure 
--target=x86_64-win64-gcc --enable-static-msvcrt --disable-install-docs 
--disable-unit-tests --disable-docs
Configuring selected codecs
  enabling vp8_encoder
  enabling vp8_decoder
  enabling vp9_encoder
  enabling vp9_decoder
Configuring for target 'x86_64-win64-gcc'
  enabling x86_64
  enabling runtime_cpu_detect
  enabling mmx
  enabling sse
  enabling sse2
  enabling sse3
  enabling ssse3
  enabling sse4_1
  enabling avx
  using yasm
  checking here for x86inc "x86_64" ""
  enabling use_x86inc
  enabling postproc
Creating makefiles for x86_64-win64-gcc libs
Creating makefiles for x86_64-win64-gcc examples

~/on2/win64$ make -i V=1
    [CREATE] vpx_scale_rtcd.h
../libvpx/build/make/rtcd.sh --arch=x86_64 --sym=vpx_scale_rtcd 
--config=libs-x86_64-win64-gcc.mk --disable-avx2  
../libvpx/vpx_scale/vpx_scale_rtcd.sh > vpx_scale_rtcd.h

Original comment by fbarch...@google.com on 30 Dec 2013 at 10:24

Attachments:

• vp9sizetime.jpg

[GoogleCodeExporter]

Original comment by ya...@google.com on 9 Jan 2014 at 11:08

• Changed state: Assigned

[GoogleCodeExporter]

I've reproduced and narrowed this down on 2 videos:

sonyh
nov27 build is fast
Pass 2/2 frame 8540/8515 43823737B 56519642 ms 9.07 fpm [ETA 314:37:52] 
←[K44.721 43.705 47.280 48.794    6328FF
dec 31 build is slow
Thu Jan  2 12pm Pass 2/2 frame 7441/7416 40439790B 166295725 ms 2.68 fpm [ETA 
1069:11:20] 44.872 43.955 46.371 49.415    8280F

worldwarz
nov27 build is fast
Pass 2/2 frame 1000/1000 8584616B   68676b/f 1646599b/s 5322491 ms (0.19 fps)
dec05 build is fast
Pass 2/2 frame 1000/1000 8584616B   68676b/f 1646599b/s 5363871 ms (0.19 fps)
dec06 build is slow
Pass 2/2 frame 1000/1000 9637303B   77098b/f 1848513b/s 23900332 ms (0.04 fps)
dec07 build is slow
Pass 2/2 frame 1000/1000 9637303B   77098b/f 1848513b/s 23107269 ms (0.04 fps)

Original comment by fbarch...@google.com on 29 Jan 2014 at 6:59

[GoogleCodeExporter]

ping?
In todays version, encoder remains slow

Feb 19, 2014
Pass 2/2 frame  442/417  8817261B 74885526 ms 0.35 fpm [ETA 8938:42:  17] 
43.095 41.931 46.999 47.486   68568F

Nov 27, 2013
Tue Feb 18 10am Pass 2/2 frame 55350/55325 513208198B 513842836 ms 6.46 fpm 
[ETA 319:40:15] 44.168 43.165 46.497 48.417   13555F

The issue was introduced on Dec 6, 2013.

Original comment by fbarch...@chromium.org on 20 Feb 2014 at 12:29

[GoogleCodeExporter]

working as expected, hopefully we will make the encoder faster through future 
optimizations

Original comment by ya...@google.com on 27 Feb 2014 at 11:27

• Changed state: Invalid

[GoogleCodeExporter]

Discussed offline - its not a 'bug'.. its a feature that improves quality, but 
is slower.

But I didn't observe a quality improvement, and performance is substantially 
slower, so I'd suggest a change.
Transcode time of 8938 hours is really not feasible.

Original comment by fbarch...@google.com on 1 Mar 2014 at 1:06