[FFmpeg-devel] [PATCH] libaom: Dont use aom_codec_av1_dx_algo.

[James Zern]

On Mon, Nov 1, 2021 at 6:11 PM Matt Oliver <protogonoi at gmail.com> wrote:
>
> On Tue, 2 Nov 2021 at 04:41, James Zern <jzern-at-google.com at ffmpeg.org>
> wrote:
>
> > On Fri, Oct 29, 2021 at 8:51 PM Matt Oliver <protogonoi at gmail.com> wrote:
> > >
> > > On Sat, 30 Oct 2021 at 14:13, Matt Oliver <protogonoi at gmail.com> wrote:
> > >
> > > > Does this compile and link with libaom 1.0.0? We unfortunately still
> > > >> support that version (despite being unusable speed wise) because
> > distros
> > > >> like Debian still ship it.
> > > >>
> > > >
> > > > Just looked it up and yes version 1.0.0 includes the required
> > > > aom_codec_av1_dx() function (line 37 of aomdx.h for those interested).
> > > >
> > >
> > > I also noticed that libvpx does the same thing as libaom where it uses
> > the
> > > direct variable instead of the function returning the variable. libvpx
> > > doesnt currently support static compilation so it's not an issue that has
> > > come up but was wondering whether it was worth submitting a patch
> > > preemptively fixing that issue as well.
> > >
> >
> > That would be fine. By static compilation do you mean generating an
> > import lib for this scenario?
> >
>
> That was actually a typo, I meant libvpx doesnt support 'shared'
> compilation on windows (the configure script only allows it to be specified
> on ELF platforms). I'm not familiar with why libvpx doesnt currently allow
> it but if it did then ffmpeg would have the same issues as with libaom that
> was fixed with this patch.

There's no reason someone couldn't build libvpx this way, but
configure never had support added for it; libaom picked up support
through its transition to cmake.

> Which is why I was wondering if people were fine
> with me preemptively fixing it by patching ffmpeg now instead of waiting
> for it to be a potential issue down the line.
>

That's fine by me.