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

[Rick Kern]

On Fri, May 24, 2019 at 6:34 PM Thilo Borgmann <thilo.borgmann at mail.de>
wrote:

> Am 22.05.19 um 14:27 schrieb Thilo Borgmann:
> > 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.
>
> If nobody else cares, should I try to come up with something like this? Or
> do you want to?
>

If you're willing to maintain the header as new values are added, it will
make it easier to read the code.


>
> -Thilo
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".