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

James Almer jamrial at gmail.com
Sat Sep 30 00:59:56 EEST 2017

On 9/29/2017 6:56 PM, Hendrik Leppkes wrote:
> On Fri, Sep 29, 2017 at 8:39 PM, Clément Bœsch <u at pkh.me> wrote:
>> On Fri, Sep 29, 2017 at 08:12:14PM +0200, Hendrik Leppkes wrote:
>> [...]
>>>> 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?
>> It's just a bit weird to actually introduce deprecated symbols that
>> weren't there in the first place.
> Since at least BBB was slightly confused by my comments, just to clarfiy:
> I don't really care how its done, but the ABI should remain intact. If
> I do a simple build on mac today with ./configure && make and it
> includes vda symbols, then so it should afterwards, even if they are
> non-functional. How thats done, I don't mind.

Then IMO we should wait until the major bump (Which is not too far
away). Leaving a stub object for the symbols and configure clutter
should be avoided.

More information about the ffmpeg-devel mailing list