AV1 export support

[jazztickets]

This PR adds basic AV1 support for WebM exporting. It uses the libsvtav1 encoder, as opposed to the much slower reference libaom-av1 encoder.

Newer versions of ffmpeg will use -crf instead of -qp, but for now I'm setting -qp for the quality setting.

More info: https://trac.ffmpeg.org/wiki/Encode/AV1

I also reordered the audio codec dropdown for WebM, since Opus and AV1 go hand in hand.

Tested on Arch Linux.

[Simran-B]

FYI: The Linux CI image includes libaom but not libsvtav1 currently. Does FFmpeg pick up the latter like it does the former?

[jazztickets]

I suppose some work could be done to make it fallback to libaom if libsvtav1 isn't found. I'd push for libsvtav1 though, even if it means updating the CI images.

[jazztickets]

Oops that merge was a mistake.

[Simran-B]

That's perfectly normal, and also a clean merge. Nothing to worry about.

Do you have an example of how to build FFmpeg with libsvtav1?

[jazztickets]

Assuming SVT-AV1 is installed, I think you just add --enable-libsvtav1 to the configure options of ffmpeg when building.

I found this: https://github.com/AOMediaCodec/SVT-AV1/blob/master/ffmpeg_plugin/README.md

The PKGBUILDS from arch linux might help: https://github.com/archlinux/svntogit-packages/tree/packages/ffmpeg/trunk https://github.com/archlinux/svntogit-packages/blob/packages/svt-av1/trunk/PKGBUILD

Looks like the CI image uses CentOS 7?

[Simran-B]

Thanks! This was also helpful: https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/Build-Guide.md#svt-av1-ffmpeg-plugin-installation

I replaced libaom with libsvtav1 in https://github.com/olive-editor/olive/pull/1943/commits/5565b322ddc01507d699f826c3827ed44d0c4976 and uploaded an updated CI image (yes, it's CentOS 7). Can you check whether the export works with the AppImage? https://github.com/olive-editor/olive/actions/runs/2424471332#artifacts

[jazztickets]

Nice! I tested the AppImage and it seems to work fine.

~However, I tested the Windows build and I get a Failed to open file: Failed to find codec for 0x 18 message when trying to export. I wonder if it needs a dll or something.~ Duh, the windows image hasn't been updated.

[jazztickets]

Also, it might be nice in the future to have the option of selecting which encoder you want to use. Maybe we should keep aom in the CI image?

[Simran-B]

The Docker-based CI is for Linux only. For Windows and macOS, the dependencies are managed separately and @itsmattkc needs to take care of it.

Adding consumer / web delivery codecs is already stretching the policy of including essential features only. I don't see a good reason for offering an alternative, slow encoder.

[Quackdoc]

I can't recommend adding av1 in it's current state. the quality of svtav1 is simply far too inferior to aomenc for video production, and even then I don't think aomenc is in a state where it is ready for being used in a video editor. and I don't think olive's UI is setup in a way that it conducive to using multiple encoders for any coding format. (though I think it would be the best way to implement av1 encoding)

I think the time where it could be included is soon, but IMO this is too soon. and even if it was I don't think svtav1 is the appropriate encoder to use. I myself am actually holding hope for rav1e, but it too is simply too slow, (though i have actually found it to be the fastest for arm based phones believe it or not, no idea how that translates to mac).

I think for now the proper way to use av1 in a process would be to export to a (near)/lossless intermediary, (I actually plan on making a PR for ffv1 soon for this purpose.) then transcoding to av1. it's a process I already do myself, I realize it's not ideal. but IMO av1 simply isn't ready for a video editor.

At the very least, if we do want to add av1, we don't want svtav1 we will want aomenc

[ThomasWilshaw]

Olive is about to undergo some largish code refactoring and I wanted to check on the status of old PRs before we do that. Do you plan to update/continue with the PR? Thanks

[jazztickets]

Personally I think it should just be merged before the refactoring.

[itsmattkc]

I'm not entirely sure what the state of this is, there seems to be some debate over aomenc vs svtav1 but without a solid consensus or conclusion. One is faster but lower quality and the other is vice versa?

[jazztickets]

In my tests (some examples at https://trac.ffmpeg.org/wiki/Encode/AV1), aom is incredibly slow. I get ~0.5 fps when encoding vs ~95 fps with svtav1.

I've used SVT in olive for the last couple months without any problems. Maybe @Quackdoc can expand on or provide examples for:

the quality of svtav1 is simply far too inferior

SVT has had quite a few updates in the last year: https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/CHANGELOG.md

[Quackdoc]

while I still have my reservations with SVT-AV1, (lacking features like 444 export) it's quality ceiling is much higher now, I myself am pretty indecisive if this is a good solution. on one hand, it's not the quality that aomenc can get still, so anyone looking to use the export for something high quality, would not suffice with SVT-AV1,

on the other side of the coin, anyone looking for that quality is probably going to want to use a lossless intermediate like h264, ffv1 or PNG/J2k sequences and use a dedicated exporter anyways, so while I am still disappointed at the quality ceiling of SVT AV1, I think you can get a fairly decent quality out of it. so I guess I can now retract my original statement that svt-av1 is unsuitable,

However on the other hand, aomenc has also had numerous speed improvements too, but still far to slow to be in an editor IMO this could very well change in the future.

I think adding AV1 now in the form of SVT-AV1 is not a bad idea, however I think it would be good to keep an open mind to replace svt-av1 with aomenc should it get significant encode speed improvements. Rav1e is also another potential solution, however it is far to slow it even compare at this point.

so in summary, I don't think svt-av1 is useful as a high quality encoder like aomenc is (for instance no 444 is a massive deal breaker for some people), but I'm not sure if the people looking to export av1 directly from a video editor would even care. I can't say it's no longer a reasonable add, but I can't say it is either.

EDIT: it's also important to go over the defaults of SVT-AV1, I haven't looked at them yet, but ffmpeg's defaults can be fairly lack luster, having good settings for crf, bit depth and preset should be the extent we need to go to however

[itsmattkc]

I think we can play it by ear, if SVT is good enough for now we'll use it, and if AOM becomes superior/viable in the future, we can add that too.

Sorry for the long delay @jazztickets. Merging now.

[jazztickets]

Thanks! I can add an encoder drop down in the future too if need be.

[Quackdoc]

IMO a better solution would be to, in the future choose the encoder based on speed preset, IF that is even a route to go down. implementing multiple encoders for format is just not great UX.