GNOME Bugzilla – Bug 723670
applemedia: Fails to build on OSX < 10.8
Last modified: 2014-09-17 07:42:31 UTC
The recent changes in the applemedia plugin introduced a hard dependency in the VideoToolBox framework, conditioning the reset of elements in the applemedia plugin to the presence of this framework. I think it can be good to use this framework directly instead of dynamically, but if that's the case, the vt{dec|enc} elements should be moved to a different plugin so that the other elements in the applemedia plugin can still be used even if the framework is not available.
Why is this a blocker?
It's regression because this plugin was not linking dinamically to the VideoToolbox framework and it could be loaded in OS X < 10.8. Now that it links against against this framework this plugin, and therefore all the elements in the plugin, are no longer usable in OS X < 10.8.
(In reply to comment #2) > It's regression because this plugin was not linking dinamically to the > VideoToolbox framework and it could be loaded in OS X < 10.8. I meant it was linking dynamically to the VideoToolbox framework.
Ah you mean real linking, not dlopen() style dynamic linking :) Right, that needs to be fixed before 1.4 then. Are you working on this?
Another option would be to make it work with 10.6 too. Since 10.6 the VT API exists, just that it was hidden in a private path for 10.8. So maybe with some magic linker flags we can make it work on 10.6 and 10.8 with the same binaries even. Andoni, can you check the path on 10.6?
We could be using weak linking for this framework as explained here: https://developer.apple.com/library/mac/documentation/macosx/conceptual/BPFrameworks/Concepts/WeakLinking.html
But I am not sure if that would do the trick, because the path of the framework is different between version (public vs private) Going back to use the dynamic API should be trivial, there are exactly 4 symbols that we need to load at runtime: VTDecompressionSessionCreate VTDecompressionSessionDecodeFrame VTDecompressionSessionInvalidate VTDecompressionSessionWaitForAsynchronousFrames And these are the paths where the framework is installed: /System/Library/Frameworks/VideoToolbox.framework/VideoToolbox /System/Library/PrivateFrameworks/VideoToolbox.framework/VideoToolbox
That seems easier than the weak linking even
Note that all this is still there in vtapi.c/.h, just not used /o\
commit 0258ec0273a253c9fb94a16856228b9cb1f67761 Author: Alessandro Decina <alessandro.d@gmail.com> Date: Wed Jul 2 12:54:45 2014 +0200 applemedia: enable vtdec and vtenc only on >= 10.8 where VideoToolbox is public Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=723670
I pushed the commit above which disables vtdec and vtenc on osx < 10.8. vtapi.c can't really be used anymore since it's outdated and crashes >= 10.8.
It crashed in >= 10.8 because the path of the framework changed. The fix is really easy, check first with the public path, try then with the private path and disabled it none is found.
Anyway I would leave disabled compilation in older versions where the headers are not public and use g_module_open + g_module_symbol for those 4 symbols in the plugin init function, which should be easier to implement and maintain
Also this now will let the plugin compiled for 10.8 fail to load with 10.6. I think we should just use weak linking for the VideoToolbox API and then at runtime detect in plugin_init if it is available or not.
But that's ok, the only thing that is available before 10.8 from that plugin is qkitvideosrc. I don't think all this is worth the hassle, let's just keep it as is.
commit 82aae4df74c269765ccfe66c486fbcf3ae01f086 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Sep 17 10:38:20 2014 +0300 applemedia: Do weak linking with the VideoToolbox framework It does not exist on older OSX and iOS but we still want to be able to use it when it's available.