Improve quality and performance of WebM-based recordings

[Conan-Kudo]

Suggested-by: @apiraino

Fixes: #214

[Quackdoc]

I dont think VP9 is a good idea, it's pretty slow. especially at cpu-used 5, even with cpu-used 8, my chuwi hi10x couldn't even begin to think about recording realtime 1080p30 let alone 60. even my r5 2600 struggles at encoding vp9 realtime with plenty of tuning

[ammen99]

I dont think VP9 is a good idea, it's pretty slow. especially at cpu-used 5, even with cpu-used 8, my chuwi hi10x couldn't even begin to think about recording realtime 1080p30 let alone 60. even my r5 2600 struggles at encoding vp9 realtime with plenty of tuning

How does that compare to vp8 and libx264 (the older default)?

[llyyr]

With default ffmpeg options with a 24p source, my i5-13600k encodes with libx264 at 13x speed, vp8 at 1.3-1.5x speed (it varies a lot), and vp9 at around 0.8-0.85x speed.

I'm still in favor of defaulting to libx264 because the benefits it brings over vpx are just too big, both in terms of compatibility over the web as well as hardware decoding capabilities. And as mentioned in #215, vp8 only supports yuv420p pixel format.

I don't know why Fedora can't just set vp8 or vp9 as the default codec during build, if that's what they want. To be clear, I can also just set libx264 as the default when building but using vpx as the upstream defaults inconveniences more people while only serving the purposes of one distro.

[Quackdoc]

How does that compare to vp8 and libx264 (the older default)?

on the chuwi tablet, libx264 just manages to just stably encode x264 1080p30 when nothing else is going on, libvpx does about 20fps, vp9 does 8fps.

at 720p vp8 does about 29-31 fps, vp9 does about 6fps, libx264 does about 40fps

on my 2600 at 1080p libvpx does 100fps, 1080p30 libvpx-vp9 does about 70 when nothing else is going on, and libx264 does about 150fps~

all of the tests for vp8/vp9 were tested with row-mt which increases speed.

[Conan-Kudo]

using vpx as the upstream defaults inconveniences more people while only serving the purposes of one distro.

Aside from the fact that it's not just Fedora that can't ship libx264 (Fedora, openSUSE, and their downstreams can't), using a codec that's encumbered by default is (IMO) ethically wrong.

To be honest, I would prefer to use AV1, but that's even more complex. Most of my experience has been with the AOM encoder, which is abysmally slow. The most performant CPU encoder is SVT-AV1, but I haven't had a chance to test it on my older machines to see if it's good for this sort of thing.

(Honestly, in an ideal world, wf-recorder would probe for hardware accelerated variants of codecs and use them if they work, but because ffmpeg is dumb about how it exposes them, I get why it doesn't.)

[apiraino]

It looks like that different people have different (and valid) opinions on what the default encoding codec should be. How hard would it be to make it configurable without recompiling? 😃

ffmpeg infers the encoding codec based on the file extension choosen by the user.

[ammen99]

It looks like that different people have different (and valid) opinions on what the default encoding codec should be. How hard would it be to make it configurable without recompiling? 😃

ffmpeg infers the encoding codec based on the file extension choosen by the user.

It has been possible to choose the codec at runtime since basically forever ;) See -c

[apiraino]

It has been possible to choose the codec at runtime since basically forever ;) See -c

Sure and it's very handy, I use it to create different profiles. Would that also work for you @Quackdoc - if you need to stick to x264?

(my understanding is that the discussion here revolves around the default hardcoded codec)

[llyyr]

In my opinion, the default should be what is expected by most users, and if you're going to change it then there should be a very good reason for it. wf-recorder had libx264 as the default for a very long time, and it is also what is expected (for example, simplescreenrecorder also defaults to x264).

If you're telling the majority of your users to use a flag to get the behavior that they want, then doesn't that kind of defeat the purpose of this PR? I could also tell you to go use -p/--codec-param if I were to take that logic to its logical conclusion.

not to mention we're now recommending people to use vp{8,9}_vaapi, which only works on GTX 900 series GPUs or newer for vp8 and GTX 1000 series for vp9. And AMD doesn't support vp8 or vp9 hardware encoding at all. Promoting free software is fine and all, but I think you're losing the plot a bit when your ethical pursuit leads you to recommending defaults that only work on NoVideo GPUs.

[Conan-Kudo]

I think you're losing the plot a bit when your ethical pursuit leads you to recommending defaults that only work on NoVideo GPUs.

It also works on nearly every Intel CPU since 2016 (they support hardware encoding VP8/VP9).

[llyyr]

Why should we be recommending params that's only going to work on relatively new hardware by certain vendors? The defaults should be what's safest and what's most likely to work in the most types of environments. Makes no sense to suggest the defaults that's more likely to not work than it is to work.

[Quackdoc]

Sure and it's very handy, I use it to create different profiles. Would that also work for you @Quackdoc - if you need to stick to x264?

I'm fine with using custom settings, I already have a bunch of alias' setup anyways, I just don't think using a codec thats going to be effectively unusable as a default is a good idea. vp9 will straight up not work on plenty of hardware no matter how much you tune it sadly. and since ffmpeg doesn't support svt-vp9 I doubt that's going to change anytime soon.

for software:
Ideally default would be AVC since that by far gives the best quality:preformance at a reasonable filesize. VP8 is a "reliable" fallback, however quality of it will always be rather poor. VP9 does look significantly better but at the expense that only moderate to high end computers can reliably record it. since you either need enough per core perf to brute force encoding it and doing other tasks, or have enough cores that libvpx-vp9 can run comfortably without being interfered with. (which even then isnt that easy without tweaking).

as for libsvtav1, it is marginally faster then libvpx-vp9 but still too significantly slower then vp8, especially since those speed benefits come from better utilization of available resources, which said resources are also being used by the system, so you are much to the same issue it's hard to do even remotely reliably

as for hwdec, can't we just say "use vp9_vaapi or h264_vaapi"? I don't think it really matters what the example uses as long as the error it gives if it's missing is fine.

[ammen99]

Seems to me we should go back to libx264. I get that its not available everywhere, but 1) unfounded intuition tells me most users would have that codec installed 2) it seems to be the best wrt speed/quality, and that's what we want. I'll send a PR shortly.