Removing Quicktime Dependency from LiveCode’s Player Object

A recent blog post from computer security firm Trend Micro announced that they had found 2 potential security vulnerabilities in QuickTime for Windows, and that a fix for those issues would not be forthcoming as Apple have withdrawn support for the Windows version of QuickTime. Consequently they recommend Uninstalling QuickTime for Windows as soon as possible. This is also the recommendation of US-CERT, the US government’s Computer Emergency Readiness Team.

Links:
Trend Micro Blog Post
US-CERT Alert
Apple QT For Windows Download Page

How does this affect LiveCode and our users? Our media player object has been based on QuickTime, on Windows and Mac. There is fallback support to use the old Windows MCI system, however this has been around since the days of Windows 3.1 and is no longer supported by Microsoft. Clearly it is now necessary to remove our reliance on Quicktime and move to a modern implementation of the player object. Happily, we have just done that, and the solution is available to you in the latest LiveCode release.

We decided to overhaul the Windows player object, replacing the existing Quicktime based implementation with one based on DirectShow, which is fully supported on all current Windows versions.

The new video player is based on DS, using external code provided by Docas AG

Thankfully there had already been a bit of work done towards replacing our old media player with something more modular and easy to work with. When porting the engine to run on 64-bit Mac it was necessary to use Apple’s new AVFoundation media playback library, as the old QuickTime APIs are only available on 32-bit Macs. This means for a time we had to support both. To get around this a new version of the LiveCode player object has been created that doesn’t directly call the underlying system calls that are specific to one implementation or another – instead the implementing code is accessed through the MCPlatformPlayer abstraction which hides the details of loading video/audio files, accessing information about the loaded files, and controlling playback. This has allowed us to create two different player implementations on Mac – one based on QuickTime (QTKit) and another based on AVFoundation while keeping the code for both implementations separate.

While working on the new DirectShow-based player, I took the opportunity to revise the way that players handle their native views. Each platform-specific player implementation creates a native view into which it renders any video content. Previously the player object was responsible for ensuring the location and visibility of this native view was kept in sync with the settings of the player object itself. During the development of the browser widget we added a native layer class specifically to manage this exact same behaviour for widgets. With a little bit of alteration it was possible to reuse this class for the player views, allowing us to remove this responsibility from the player object and remove a lot a of custom code dealing specifically with native video views.

Keeping common code together in this way allows us to reduce code duplication making bug fixing and maintenance much easier as a bug in native view handling will now only need fixing in one place, as opposed to having to search through the codebase for any other places where the same logic is used.

The majority of the work to replace the player on Windows has been completed, with the result being that playback should work exactly as before for most video files supported by DirectShow (a list of standard file formats can be found here, and codecs can be installed to support additional files). There are a number of features not yet supported, such as track switching support and offscreen rendering, but we will be continuing development to bring these back in future releases.

With thanks to Docas AG for contributing their DirectShow external source code, on which the new player implementation is based.

This is available now in LiveCode 8.1 DP1 in all editions.