diff mbox series

[FFmpeg-devel] avcodec/libaomenc: remove the experimental flag when using libaom 2.0.0 or newer

Message ID 20200527013218.14540-1-jamrial@gmail.com
State Accepted
Commit 49d37b4b618b20669bbd7081e6af2aecf9c09745
Headers show
Series [FFmpeg-devel] avcodec/libaomenc: remove the experimental flag when using libaom 2.0.0 or newer
Related show

Checks

Context Check Description
andriy/default pending
andriy/make success Make finished
andriy/make_fate success Make fate finished

Commit Message

James Almer May 27, 2020, 1:32 a.m. UTC
Signed-off-by: James Almer <jamrial@gmail.com>
---
Alternatively, we could remove support for libaom 1.0.0, since it's pretty much
unusable. But unfortunately both current Debian Stable and latest Ubuntu LTS
ship it, so i'm not sure if it would be wise.

Any opinions?

 libavcodec/libaomenc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

James Zern May 27, 2020, 5:46 p.m. UTC | #1
On Tue, May 26, 2020 at 6:40 PM James Almer <jamrial@gmail.com> wrote:
>
> Signed-off-by: James Almer <jamrial@gmail.com>
> ---
> Alternatively, we could remove support for libaom 1.0.0, since it's pretty much
> unusable. But unfortunately both current Debian Stable and latest Ubuntu LTS
> ship it, so i'm not sure if it would be wise.
>
> Any opinions?
>

Those were based off of the normative branch so I agree with you it's
pretty unusable. For LTS at least if there has been an incompatible
ffmpeg release since their snapshot I don't think a new one with
libaom disabled would get pulled in. That said, I'm ok with leaving
1.0.0 support through another release and when we see 2.0 get picked
up by distros. This patch is lgtm depending on other people's
preferences.
James Almer May 28, 2020, 8:14 p.m. UTC | #2
On 5/27/2020 2:46 PM, James Zern wrote:
> On Tue, May 26, 2020 at 6:40 PM James Almer <jamrial@gmail.com> wrote:
>>
>> Signed-off-by: James Almer <jamrial@gmail.com>
>> ---
>> Alternatively, we could remove support for libaom 1.0.0, since it's pretty much
>> unusable. But unfortunately both current Debian Stable and latest Ubuntu LTS
>> ship it, so i'm not sure if it would be wise.
>>
>> Any opinions?
>>
> 
> Those were based off of the normative branch so I agree with you it's
> pretty unusable. For LTS at least if there has been an incompatible
> ffmpeg release since their snapshot I don't think a new one with
> libaom disabled would get pulled in. That said, I'm ok with leaving
> 1.0.0 support through another release and when we see 2.0 get picked
> up by distros. This patch is lgtm depending on other people's
> preferences.

The idea is that if a library version is supported in one version of
ffmpeg, there should be a good argument to drop it in future versions.
So while libaom 1.0.0 is extremely slow, it (in theory) still produces
valid output, is supposedly not insecure, and is the only version
currently shipped by non rolling release distros.

Will apply this soon unless someone objects.
diff mbox series

Patch

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index fc1ea96659..d26083a426 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1055,6 +1055,9 @@  static av_cold void av1_init_static(AVCodec *codec)
         codec->pix_fmts = av1_pix_fmts_highbd;
     else
         codec->pix_fmts = av1_pix_fmts;
+
+    if (aom_codec_version_major() < 2)
+        codec->capabilities |= AV_CODEC_CAP_EXPERIMENTAL;
 }
 
 static av_cold int av1_init(AVCodecContext *avctx)
@@ -1131,7 +1134,7 @@  AVCodec ff_libaom_av1_encoder = {
     .init           = av1_init,
     .encode2        = aom_encode,
     .close          = aom_free,
-    .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_EXPERIMENTAL,
+    .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
     .profiles       = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
     .priv_class     = &class_aom,
     .defaults       = defaults,