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

[Hendrik Leppkes]

On Fri, Sep 29, 2017 at 8:25 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 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.
>

Its not exactly any effort, however.

- Hendrik