[FFmpeg-devel] [PATCH] lavc: drop VDA

[Ronald S. Bultje]

Hi,

On Fri, Sep 29, 2017 at 2:12 PM, Hendrik Leppkes <h.leppkes at gmail.com>
wrote:

> On Fri, Sep 29, 2017 at 7:08 PM, Clément Bœsch <u at pkh.me> wrote:
> > On Fri, Sep 29, 2017 at 06:15:57PM +0200, Hendrik Leppkes wrote:
> >> On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch <u at pkh.me> wrote:
> >> > On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote:
> >> >> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch <u at pkh.me> wrote:
> >> >> > From: Clément Bœsch <cboesch at gopro.com>
> >> >> >
> >> >> > Deprecated (aka removed) in OSX 10.11, and we have a replacement
> for it
> >> >> > (VideoToolbox).
> >> >> > ---
> >> >> > Changes since RFC: rebase, ifdefery depreciation dance for the pix
> fmt,
> >> >> > Changelog entry.
> >> >> >
> >> >>
> >> >> vda.h is an installed header with public API in it, removing it
> >> >> entirely would be an API and ABI break.
> >> >>
> >> >
> >> > vda.h may be exposed unconditionally, but its associated object vda.o
> >> > isn't. Since it depends on vda to be assembled, the vda stub itself
> >> > doesn't seem to be present ever. So we're basically exposing a header
> for
> >> > functions we can never link against.
> >> >
> >> > So should I somehow fix VDA while dropping it by providing a stub
> that was
> >> > never present?
> >> >
> >>
> >> vda is autodetected so a "naive" build would have it, so I would argue
> >> the ABI of such a "naive" build should probably remain constant?
> >
> > Just to be clear (sorry if I make you repeat yourself), we currently have
> > the following:
> >
> > - Systems without VDA (that is, almost all of them) do not have access to
> >   either VDA or the stub: for them, we are exposing a header with FFmpeg
> >   symbols not accessible.
> >
> > - Systems with VDA have access to the VDA code (assuming it still build)
> >
> > What you suggest:
> >
> > - Both systems (with and without VDA) should now use the existing stub we
> >   currently never build so the ABI for systems with VDA will be kept.
> >
> > Is that correct?
> >
> > If so, this means we will start introducing a deprecated API stub for VDA
> > on all systems.
> >
> > Or should I start exposing the stub only for VDA systems, meaning I'll
> > need to keep the VDA detection in the configure?
> >
>
> Obivously including the stub everywhere is much easier and far saner,
> does it really harm to do that?


I don't think it's reasonable to ask people to fix a feature if all they
want to do is deprecate and remove it.

Ronald