QuickTime transport does not respond to input

Windows
1

When building the JUCE demo (from tip) with QuickTime on Windows, the built-in movie transport controls do not seem to respond to any input (but they work fine on the same system in Firefox/IE for example). The programmatic API controls work just fine, so we can build our own transport if need be.

(We would be happy to use the native DirectShow, but it doesn’t appear to support the mov/mp4 wrapper and H.264 codec out of the box? We are working with documents that have embedded videos in our app and we need a cross-platform video playback solution, which is why we’re using QuickTime.)

2

I think it probably makes sense to create your own transport controls, and also to avoid QuickTime if humanly possible, since it’s clearly a doomed technology. They’re even deprecating it on OSX, so you can’t expect the PC version to be supported for much longer!

Perhaps consider installing a DirectShow codec for the format you need?

3

Thanks for the advice! Yes I’d be happy to get out of QuickTime. Looking into this a little more, it seems the web browser is probably the best place to do cross-platform video, for example, by just streaming video from YouTube or wrapping the movie in a video tag. The juce WebBrowser component does a fine job with this except for one caveat (for those interested)…

On Windows, the IE control defaults to the IE7 render mode, but you need IE9 to get the HTML5 video tag (and thus avoid Flash). This can be fixed by adding a key to the registry to allow the JUCE app to access IE9 mode…
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
Create DWORD “NameOfApp.exe” with decimal value 9000

Microsoft reference…
http://msdn.microsoft.com/en-us/library/ee330730(v=vs.85).aspx#browser_emulation

4

There’s also ffmpeg to consider, if you can bear the sheer awfulness of the code.

5

I haven’t tried this yet but I think someone posted a player component using libvlc a while ago. Might be worth a look.

6

Yes, we were actually shipping the app with the ffmpeg binary and reencoding to a standard format on the fly, but it was seriously nasty! And it’s just not possible to create universal quality settings for the reencode that keep the original quality without seriously increasing the file size. With the web browser component using HTML5 you are at least guaranteed to get H.264 (which is semi-standard now).