So far all VP9 Encodes crash/currupt or Fail

[SplitCoreGaming]

Well I have tried every type, every option, command line and selection to export a VP9 test video. Closest I have reached is what I have attached but as you can see the encode eventually just goes 'ape shit'. Really unsure what to think as I really want to use VP9.

http://splitcoregaming.com/grid%2028-07-2014%2019-40-43.VP9.webm

[fnordware]

OK, let me first say that I'm actually sort of impressed by what I saw. Nearly 3 minutes of 60fps HD video in VP9. Must have taken forever to encode! It seems to fail for me around the 2:58 mark when I play it in Firefox (the entire thing is supposed to be nearly 11 minutes).

You say you've tried every setting. How about the only setting currently recommended for VP9: Variable Bitrate (2-pass) encoding, with --cpu-used=2 in the custom options. Have you tried that?

One other thing I noticed is that this video appears to not have keyframes, so scrubbing is broken and other playback is difficult as well.

I have never tried to encode something like this, so there could be bugs, possibly in the VP9 encoder. But I have to make sure you've used the right settings first.

[SplitCoreGaming]

Yeh had the --cpu-used=2 as your readme recommended as well as tried 1, 0 (which fail immediately after first few frames). I actually went out all day while it encoded to see Guardians of the Galaxy so it was worth it :P. Currently doing a ffmpeg command line encode overnight to see if same issue accrues and to compare quality. I find it amazing YouTube uses VP9 so I am really curious how they pull this off with such high demands.

Full settings are: 1080p Square Pixels Field Type None 60fps VP9 VB 2-pass 50,000 kb/s Best --cpu-used=2

Audio: Stereo Opus Auto

[fnordware]

Thanks for the details. It would help if we could reproduce the bug with a configuration that won't take so long to encode.

So what happens if you shrink the video down to 256 pixels wide? Do you get the same problem? (You'll want to scale down the data rate accordingly.) And while you're at it, maybe try Vorbis audio instead of Opus. If the video is failing around 3 minutes of your total 11 minutes, see if it fails in the same place if you just encode 4 minutes.

This is why the plug-in is still beta!

[SplitCoreGaming]

Yeh fully understand. I just successfully did a ffmpeg VP9 encode of same file at 1080p 60fps CQ mode. File clocks in at 1.375 gig with 3 chapter key frames. No corruption at all or audio issues, more than happy to keep Beta testing but at moment does feel like a major issue somewhere. Sorry Cannot be more of help.

[fnordware]

Hmmm. Another question: are you on Mac on Win?

Chapter keyframes? Is that different from regular VP9 keyframes?

The lack of VP9 keyframes is a little disturbing. For footage like this, I'd expect to have them every few seconds, making hundreds of keyframes in an 11 minute file. The lack of keyframes makes scrubbing nearly impossible because the decoder has to start at a keyframe and work forward.

[SplitCoreGaming]

Hello Again. I am on Windows 8.1 64Bit using 64bit software such as Adobe. VP9 from the mass reading I have done today seems to automatically assign key frames to major transitions detected during encoding. In the case of continuous footage (which most game footage will be) this seems to not assign anything until the race ends and a major transition takes places such as camera fade/pan.

To fix this issue I have used '-g 300' in ffmpeg (--kf-max-dist= Maximum keyframe interval (frames)) which will assign a key frame at every 5 seconds (60 * 5 = 300).

My full code I am now running as a final test in ffmpeg is - ffmpeg -i grid.avi -c:v libvpx-vp9 -deadline good -cpu-used 1 -crf 10 -g 60 -b:v 20M -c:a libvorbis -qscale:a 6 outputV2.webm

Basically operating Constant Quality mode at 15 (Documents state this is 0 - 64 with lowest being higher quality. Your add-on goes to 100 and does not make clear which direction is intended) with a key frame at every 1 second with maximum bit rate at 20,000 kbps. Audio is then Vorbis with a Quality level of 6 (0.6 of your scale set to Quality).

Will link newest encode when it finishes in a few hours. Hope above helps.

Update Seems adding a key frame at every 60 breaks the compression of the VP9. I am guessing that it must reset the algorithm they use. Very very odd. Now trying back to every 5 secs (YouTube Standard).

ffmpeg -i grid.avi -c:v libvpx-vp9 -deadline good -cpu-used 1 -crf 20 -g 300 -b:v 18M -c:a libvorbis -qscale:a 7 outputV2.webm

[fnordware]

OK, I think I was not updating my Windows build properly when I updated to newer versions of the encoder. I've fixed it and posted a new build. Please give it a try.

The VP9 encoder seems to be coming along! Still slow, but not as slow as it once was.

BTW, my 0-100 quality roughly maps to FFmpeg's 64-0. In other words, for this plug-in 100 is the highest quality, which to me seems like the natural thing, higher quality value meaning higher quality output. I think FFmpeg's inverted quality is weird.