| 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 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/default | pending | |
| andriy/make | success | Make finished |
| andriy/make_fate | success | Make fate finished |
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.
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 --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,
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(-)