Switch to vp9_vaapi if it is available Using libvpx-vp9 I was getting 3-5fps at 1080p which is painfully slow if you're trying to convert an hour of video.
If your GPU supports it, using vp9_vaapi
can be much, much faster. On my HTPC with an i7 8650u vaapi gives about 30x better performance, I can encode 4 videos at once at 130-150fps each.
Sample ffmpeg line:
ffmpeg -vaapi_device /dev/dri/renderD128 -i $infile -vf 'format=nv12,hwupload' -c:v vp9_vaapi -b:v 0 -c:a libvorbis $outfile
There is an option loop_filter_level
seems to be equivalent to CRF and goes from 0-63. However, it is poorly documented online other than the default is 16. I tried it at 1 and 63, the file size and subjective quality were practically identical so either I'm using it wrong or the option is ignored by ffmpeg.
Using default settings I could not see any visual difference between my 1080p h264 source video and the vp9 output.
You'll need to check your GPU supports hardware encoding. Run vainfo
and look for:
VAProfileVP9Profile0 : VAEntrypointEncSlice
vp9_vaapi vs libvpx-vp9
I tried encoding the same 50 minute 1080p video with these results:
- libvpx-vp9 took nearly 8 hours and produced a 568.8mb file
- vp9_vaapi -loop_filter_level 1 took just over 7 minutes and produced a 756.1mb file
- vp9_vaapi -loop_filter_level 63 tool just over 8 minutes and produced a 734.1mb file
Subjectively all the videos look the same to me and I could not tell one from the other.
Clearly, libvpx-vp9 wins on compression but unless you're very, very starved for disk space (or bandwidth if you're planning to stream the video), it is absolutely not worth the unreasonable encoding time.
I don't know why loop_filer_level
makes such a little difference, I would suggest leaving it at the default (16) until it is better documented.
All the usual caveats apply. libvpx will no doubt mature over time, your hardware may produce different results, and hardware encoders often give worse visual quality than software ones (though I could not tell in my test).