Removing Quicktime Dependency from LiveCode’s Player Object

by Ian Macphail on May 26, 2016 4 comments

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.

Ian MacphailRemoving Quicktime Dependency from LiveCode’s Player Object

Related Posts

Take a look at these posts

4 comments

Join the conversation
  • Claudine - September 13, 2016 reply

    ok, but you are not clear about what happen for the MAC OS, in particular for older versions like snow leopard (10.6) that millions of users, me included, still use, for many and diverse good reasons.
    Is there some change in functionality or code compatibility for those users?
    Thanks for informing,

    Ian Macphail - September 14, 2016 reply

    Hi Claudine, the QTKit version of the player will continue to work as is in LiveCode 8.1, however since Apple haven’t supported OS X 10.6 for over two and a half years, we will soon be ending support for that version of OS X. Please see https://livecode.com/updated-platform-support-policy/ for more details.

  • Peter Jenkins - September 14, 2016 reply

    Yes, it is confusing what is being used on what platforms.

    Is this correct?
    Mac — QTKit AND AVFoundation
    Windows — DirectShow

    If so, are they all now in LC 8.1?

    Ian Macphail - September 14, 2016 reply

    Hi Peter, this blog refers only to changes in the Windows version of LiveCode 8.1.

    You are correct that on Mac both QTKit and AVFoundation can be used. The ‘dontuseqt’ property controls which one.
    Due to the security risk posed by the removal of support from Apple of the QT libraries on Windows, we have removed that option from that platform – the player on Windows is now solely based on DirectShow.

    Both the AVFoundation and DirectShow player implementations have been added in LiveCode 8.1.

Join the conversation

*