Add Software AV1 support to FFMPEG

[Rahul Chandra]

Requires Adding Encoder: rav1e: ​https://github.com/xiph/rav1e

Decoder: dav1d: ​https://code.videolan.org/videolan/dav1d

[Xi Ruoyao]

I guess we can archive libaom after we add them, as the pair provides AV1 encoder/decoder faster than libaom. libavif can also be configured to use libdav1d instead.

[Rahul Chandra]

I think we can do that, I need to make sure that gstreamer supports it though

[Rahul Chandra]

​https://gstreamer.freedesktop.org/documentation/dav1d/?gi-language=c ​https://gstreamer.freedesktop.org/documentation/rav1e/index.html?gi-language=c

They're both part of the Rust plugins suite... We could either add the respective plugins or keep libaom. I'm leaning towards just adding them. I don't know how this would affect jhalfs but maybe we could put all of the rust plugins on one page similar to xorg-libs or KDE. Just have users pick which one's they want or install all by default?

[Rahul Chandra]

We already use an rs plugin for gtk4, I think we might also want another one for laptop camera support in snapshot (I forget which one I installed to make mine work)

[Xi Ruoyao]

Replying to Rahul Chandra:

​https://gstreamer.freedesktop.org/documentation/dav1d/?gi-language=c ​https://gstreamer.freedesktop.org/documentation/rav1e/index.html?gi-language=c

They're both part of the Rust plugins suite... We could either add the respective plugins or keep libaom. I'm leaning towards just adding them.

I agree.

I don't know how this would affect jhalfs but maybe we could put all of the rust plugins on one page similar to xorg-libs or KDE. Just have users pick which one's they want or install all by default?

I think we can just provide the 3 plugins needed by other packages and let the users pick. jhalfs can simply just install all the 3 plugins. It would be like how we deal with webkitgtk.

[Xi Ruoyao]

Regarding rav1e, gst-plugins-rs will always build a copy of rav1e instead of using the system one. And there seems nothing we can do to make it use the system one (as both are Rust packages, and it's common for a Rust package to build a Rust dependency in this way).

[zeckma]

Added SVT-AV1 (AV1 encoder) and dav1d (decoder) in GLFS and archived libaom. The commit is here: ​https://github.com/glfs-book/glfs/commit/5ab31a98ea8c7d92ece2a5b6a291b2ee374adb50. No problems over here with a non-libaom build. YT videos work as expected, Twitch livestreams work just fine, and Google Play Movies which some can have some issues with FFmpeg upgrades have no issues.

[zeckma]

gst-plugins-bad builds libaom plugin. We don't seem to document this or the dependency.

[zeckma]

gst-plugins-bad has an svt-av1 plugin. We still need to add gst-plugin-dav1d (from the rust plugins) for dav1d.

[Douglas R. Reno]

I've seen several references to rav1e in here. Do we need that as well, or what's the plan with that?

[zeckma]

Replying to Douglas R. Reno:

I've seen several references to rav1e in here. Do we need that as well, or what's the plan with that?

SVT-AV1 replaces rav1e. They do the same job, it's just one is faster and doesn't depend on Rustc. The packages we care about support dav1d and SVT-AV1, and optionally rav1e which will stay out of book for now.

[Joe Locash]

Replying to zeckma:

gst-plugins-bad builds libaom plugin. We don't seem to document this or the dependency.

libaom is listed as an optional dependency so if it's installed at build time the plugin will get built.

[zeckma]

Replying to Joe Locash:

Replying to zeckma:

gst-plugins-bad builds libaom plugin. We don't seem to document this or the dependency.

libaom is listed as an optional dependency so if it's installed at build time the plugin will get built.

Ah, didn't notice it. If it's optional though, that sort of means AV1 is optional. Do we need to add instructions for the Rust plugin for dav1d?

[zeckma]

Replying to zeckma:

Replying to Joe Locash:

Replying to zeckma:

gst-plugins-bad builds libaom plugin. We don't seem to document this or the dependency.

libaom is listed as an optional dependency so if it's installed at build time the plugin will get built.

Ah, didn't notice it. If it's optional though, that sort of means AV1 is optional. Do we need to add instructions for the Rust plugin for dav1d?

Talked with Doug in regards to this. SVT-AV1 will be added to Recommended for gst-plugins-bad and gst-plugins-rs will get instructions for dav1d. That way, WebKitGTK will be able to do AV1 playback.

[zeckma]

Replying to zeckma:

Added SVT-AV1 (AV1 encoder) and dav1d (decoder) in GLFS and archived libaom. The commit is here: ​https://github.com/glfs-book/glfs/commit/5ab31a98ea8c7d92ece2a5b6a291b2ee374adb50. No problems over here with a non-libaom build. YT videos work as expected, Twitch livestreams work just fine, and Google Play Movies which some can have some issues with FFmpeg upgrades have no issues.

I mentioned it in the previous FF ticket, but after a reboot, I encountered the standard FFmpeg upgrade issues. So this point of everything working as expected is moot.

[zeckma]

Done and dusted. We are keeping libaom because it supports chroma subsampling outside of YUV420. SVT-AV1 does not, it only supports 420. This is likely the reasons distros haven't axed libaom yet. At the very least, it will be up to each package to pick and choose with encoder/decoder to use. FFmpeg might choose the newly added dav1d/SVT-AV1, while libavif may use libaom.

[Rahul Chandra]

Thanks Zeckma, I'm in the middle of the move right now and wasn't able to get to this.

[Rahul Chandra]

Replying to zeckma:

Done and dusted. We are keeping libaom because it supports chroma subsampling outside of YUV420. SVT-AV1 does not, it only supports 420. This is likely the reasons distros haven't axed libaom yet. At the very least, it will be up to each package to pick and choose with encoder/decoder to use. FFmpeg might choose the newly added dav1d/SVT-AV1, while libavif may use libaom.

Because of the outrageous test time I think we should still axe this but keep it documented. Every time I've seen 4:2:2 or 4:4:4 HDR/DoVI has been involved and we don't support either AFAIK. I think we're fine only supporting only 4:2:0

[Douglas R. Reno]

I disagree. We had the functionality before, and folks like myself do depend on it when doing editing using Kdenlive. We already discourage running the tests, and if you run them for libavif it will grab a copy anyway and run the full libaom test suite

[Rahul Chandra]

good point, I guess we can leave it in until svt-av1 gets full color range support.

[Bruce Dubbs]

Milestone renamed