Is there any FFmpeg VP9 game recorder or video converter for windows?

[rcarlos243]

I tried both NVIDIA Shadow Play and AMD GVR to record footage, but they record significantly worse quality at the same bitrate(10,000kb/s) as x264.

I also tried x264 with very fast preset, but I want something better.

I searched around about x265 and while it does produce about 50% better quality at the same bit rate as x264, it is around 10~20x slower.

I also heard about VP9 (libvpx) and while it is a bit better than x265 it is still slow.

FFmeg VP9 the best from what I read here:
https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

[nevcairiel]

ffvp9 is a decoder only, not an encoder. It's speed won't help you ;)

[Warperus]

Why do you want to keep bitrate as low as 10Mbit/s? It's about production-level of bitrate for 1080p video, and sometimes it's not enough to stay away from artifacts even for placebo settings of good encoders.
I capture games with 50Mbit/s for 1080p-60fps with ShadowPlay and recommend at least 20Mbit/s for any realtime-capable codec. It's more than 30 hours for 1Tb. You can't seriously expect to capture that much in a week if you also do video editing.
And if it comes to final render, you are not limited by time. You can spend a day for rendering if you wish to get great quality for downloadable video.
So, why do you want something better for game capture?

[raffriff42]

x264 is it among lossy codecs right now. I do not think vp9 will satisfy you.

My best advice for fast x264 (https://encodingtalk.com/threads/fraps-to-youtube-with-h-264.894/#post-4756):
--preset ultrafast
--crf 19 or --bitrate 15000 or more (up to unlimited)
--keyint 1

Best performance is still obtained by lossless codecs such as UT Video or good old HuffYUV -- if you have a fast hard drive.

You don't say what capture program you are using. Some have trouble working with 3rd party (VFW / DirectShow) codecs.
For best performance, try to use the program's "native" or default codec.

[smok3]

4:2:2 or 4:4:4 should raise the quality as well (tested on screencasts only), but will reduce compatibility.

[rcarlos243]

ffvp9 is a decoder only, not an encoder. It's speed won't help you ;)

Thanks for clarifying.

Why do you want to keep bitrate as low as 10Mbit/s? It's about production-level of bitrate for 1080p video, and sometimes it's not enough to stay away from artifacts even for placebo settings of good encoders.
I capture games with 50Mbit/s for 1080p-60fps with ShadowPlay and recommend at least 20Mbit/s for any realtime-capable codec. It's more than 30 hours for 1Tb. You can't seriously expect to capture that much in a week if you also do video editing.
And if it comes to final render, you are not limited by time. You can spend a day for rendering if you wish to get great quality for downloadable video.
So, why do you want something better for game capture?

I am limited on bandwidth due to my ISP. I only have 75Mbps down and 8Mbps up thanks to Comcast.

I can't record on higher quality or on raw footage because it would increase the processing time tremendously (on top of my already slow upload speed).

x264 is it among lossy codecs right now. I do not think vp9 will satisfy you.

My best advice for fast x264 (https://encodingtalk.com/threads/fraps-to-youtube-with-h-264.894/#post-4756):
--preset ultrafast
--crf 19 or --bitrate 15000 or more (up to unlimited)
--keyint 1

Best performance is still obtained by lossless codecs such as UT Video or good old HuffYUV -- if you have a fast hard drive.

You don't say what capture program you are using. Some have trouble working with 3rd party (VFW / DirectShow) codecs.
For best performance, try to use the program's "native" or default codec.

I tried Shadowplay(when I have GTX 970), AMD GVR, OBS(x264, Shadowplay, VCE AMF), FRAPS, Bandicam, Afterburner(with x264vwf).

On my experience hardware accelerated recording records significantly inferior quality at the same bitrate as x264.

I am using very fast x264 preset (faster would be too laggy).


My PC specs:
i7 5820K @ 4.4Ghz
16GB DDR4 2400 Quad Channel
R9 290 4GB @ 1.1Ghz Core and 6Ghz Mem
960GB SSD, 6TB WD Red
1080p 144Hz monitor

Edit: does anyone know how many physical cores x264 support?

[nevcairiel]

NVIDIA GPUs can technically encode in 4:4:4 Lossless mode, but I'm not sure its exposed through any recording tool, and of course files might end up too large for comfort. :)

[Warperus]

I can't record on higher quality or on raw footage because it would increase the processing time tremendously.I assume you still do some processing after capture. In this case source bitrate up to 100Mbit/s doesn't really matter. Your computer can handle 10 video streams still showing steady 60 fps in preview. It's encoding that takes majority of time for final render.
For me fraps (up to 300Mbit/s) worked like a charm even though I had old i7-860 and no GPU accelerates its decoding. No problems with 50Mbit/s shadowplay captures as well. Long GoP is much worse for video editing than 100Mbit/s bitrate.
The idea for post-processing is simple:
* capture with fat quick codec that doesn't hinder your gameplay and keeps all the quality you need
* process, add some titles, voice over, change sound, add some fancy effects etc.
* encode with slow, but effective codec
* upload small well-packaged file

Difference between x264 in ultrafast (without b frames) and slow presets can be, say, 40%. It's significant difference, but you can't get it all in capture stage, so you get it in processing stage.

does anyone know how many physical cores x264 support?No hard limits. But each additional core decreases quality and only increases speed progressively lower than previous thread.
x264 defaults number of threads to 1.5 times number of logical cores, but more than 12 threads is a bad idea.

[rcarlos243]

I assume you still do some processing after capture. In this case source bitrate up to 100Mbit/s doesn't really matter. Your computer can handle 10 video streams still showing steady 60 fps in preview. It's encoding that takes majority of time for final render.
For me fraps (up to 300Mbit/s) worked like a charm even though I had old i7-860 and no GPU accelerates its decoding. No problems with 50Mbit/s shadowplay captures as well. Long GoP is much worse for video editing than 100Mbit/s bitrate.
The idea for post-processing is simple:
* capture with fat quick codec that doesn't hinder your gameplay and keeps all the quality you need
* process, add some titles, voice over, change sound, add some fancy effects etc.
* encode with slow, but effective codec
* upload small well-packaged file

Difference between x264 in ultrafast (without b frames) and slow presets can be, say, 40%. It's significant difference, but you can't get it all in capture stage, so you get it in processing stage.

No hard limits. But each additional core decreases quality and only increases speed progressively lower than previous thread.
x264 defaults number of threads to 1.5 times number of logical cores, but more than 12 threads is a bad idea.

Ideally I would want to upload it straight after recording (no post processing).

I tried slower presets than ultrafast but it raises the input lag on my pc and sometimes it my pc fails to recognize i pressed a button so I can only use ultrafast preset.


are you saying that my 5820k is the best possible CPU I can use for x264 as it has a total of 12threads?

Also can you clarify "But each additional core decreases quality", does that mean I get worse video quality at the same bit rate if I use multi core optimization for x264?

Can you also elaborate this more "but more than 12 threads is a bad idea." I am thinking of getting an either a Intel Xeon E5 2690 v3 (12core, 24threads 3.5Ghz) or Intel Xeon E5-2695 v3 (14core, 28threads 3.3Ghz). Does that mean that if I upgrade to either CPU I will not get any improvement in encoding speed?

[Asmodian]

The point where multi-threaded encoding starts to noticeably hurt quality is dependent on resolution but any more than a single thread does hurt quality, at least theoretically. The 12 threads rule is for 1080p and is on the safe side as I understand it. Systems with more cores are great for higher resolutions (e.g. 1440, 4K) or encoding multiple streams simultaneously.

I assume the game uses threads as well? Having more threads available on the CPU is not the issue, how many threads used by x264 is what is important. You can set x264 to use 16 threads on an i7-4970K (a bad idea) or 8 threads on an E5-2695v3.

[kuchikirukia]

Try reducing preset superfast from 3 b-frames to 1 or 2.
You might want to play with game settings to find if one is particularly CPU-heavy. Shadows used to be killers.

[Warperus]

does that mean I get worse video quality at the same bit rate if I use multi core optimization for x264
Well, yes. Each core in the process decreases overall quality. Not by far, though.
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/threads.txt

I am thinking of getting an either a Intel Xeon E5 2690 v3 (12core, 24threads 3.5Ghz) or Intel Xeon E5-2695 v3 (14core, 28threads 3.3Ghz). Does that mean that if I upgrade to either CPU I will not get any improvement in encoding speed?Well, each core adds speed, but progression is not linear. As you can see in linked document, with 2 cores on veryfast preset your encode is 40% faster. With 8 cores it's only 140% faster (each core works like with a speed of 30% counting from 1 core). Additional cores will add speed, but lower and lower.
I don't know of measurements for quality for more than 12 cores, but you can try it youself if you want. If you set number of cores in your current environment, you'll get the result similar to the one you'll get with new processor, (it will be a bit slower than on new processor, but it's another issue).

[vivan]

Well, each core adds speed, but progression is not linear. As you can see in linked document, with 2 cores on veryfast preset your encode is 40% faster. With 8 cores it's only 140% fasterFor slice-based threading, for frame-based it's 298% (which is reached at 4 threads, this might be related to the system being dual-cpu). Also lookahead is now threaded.