[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13

Thilo Borgmann thilo.borgmann at mail.de
Wed May 22 15:27:20 EEST 2019


Am 22.05.19 um 01:41 schrieb Jan Ekström:
> Hi,
> 
> On Tue, May 14, 2019 at 4:16 PM Thilo Borgmann <thilo.borgmann at mail.de> wrote:
>>
>> $Subject
>>
>> Tested compilation only, sanity test actually using it appreciated.
>>
> 
> Thanks for the patch. To be completely fair, this is not to fix
> compilation for specific target systems, but rather to fix compilation
> on older SDKs (building with newer SDKs you can still build aiming for
> macOS starting from 10.9, for example).
> 
> I didn't notice a patch landed on the encoder side that utilized the
> defines without further checking/ifdefs. Too bad. I think I
> specifically didn't yet merge the full/limited range patch on the
> decoder side due to related reasons.
> 
> I did notice that VLC just re-defined these enum values themselves to
> stop needing to have ifdefs depending on which SDK is being utilized
> (https://github.com/videolan/vlc/commit/1b7e1c4bfcda375e2d4e657135aeaf3732e44af2#diff-a11cdb805d111956af60619d7dfa022bR735).
> I wonder if we should have a helper header that would re-define these
> enum values with their name. That way the code would look correct, and
> the resulting binary has the same features independent of the SDK it
> had been built under.
> 
> What would be the opinion of people on a solution like this?

Tested with a local definition of the symbols (like a would be header would do).
Seems to work for building with -macosx-version-min=XXX.

Also checked with VLC, they do these checks via thinks like:

#ifndef MAC_OS_X_VERSION_10_13
	...
#endif

Wich might be a better alternative to what I suggested.

Thus I would be fine with a helping header.

-Thilo




More information about the ffmpeg-devel mailing list