Reading mp4s in Windows - and distributing the resulting binary

Greetings, Jucers!

I am getting several requests for the ability to read mp4 audio files - something I am doing perfectly well on the Mac, but most of my customers are on Windows.

I looked into this before, and it seemed problematic - I'm wondering if it's easier these days or if anyone has guidance for me?

Here's my reasoning - PLEASE let me know if I'm wrong or missing something...


1. To read mp4 audio files, I need QuickTime.

2. I get QuickTime for free on the Mac - Windows is my only issue.

3. The QuickTime library only comes as a shared library on Windows, and this library isn't distributed with Windows by default.

4. Assuming I use Juce's QuickTimeAudioFormat, that shared library must be installed.

5. If that shared library is NOT installed, my program won't even be able to start...

6. ... and there is no practical way to trap this error and continue running the program without QuickTime.

7. So in order to guarantee that the program won't crash on startup, I need to distribute QuickTime.

8. But in order to do this, I need to get a license from Apple, which might or might not cost me money, will certainly require a delay, and seeming also prevents me from distributing a freeware ("crippleware") version.

9. Moreover, in order to do this I need to install their shared library when my program is installed - which means I need to write an installer (right now, everything's in one executable file, so there's no explicit installer).

I'm thinking that one mechanism might be to distribute TWO versions - the "default version" which doesn't refer to QuickTime at all, and the QT version, which assumes that you have independently installed QuickTime.  It's somewhat lame, but my resources are fairly limited.

Any help gratefully accepted!




No! You should avoid QuickTime, it's a dead duck since Apple have deprecated it.

I'd have thought that the CoreAudioFormat and WindowsMediaAudioFormat would handle MP4.. If not, they will do if the user installs an appropriate codec.

Neither CoreAudio nor the Windows Media Format SDK lets you add support for more codecs through installation. They both have a fixed amount of codec support.

CoreAudioFormat (Mac OS X) does support AAC (MP4 audio).

WindowsMediaAudioFormat (Windows) does not support AAC (MP4 audio). 


Since Windows 7 and later includes an AAC decoder, it certainly is possible to read AAC (MP4 audio) on these platforms however someone would have to write an Audio Format class that supports Microsoft's Media Foundation API.


If anyone really needs this, I'd be willing to be hired to take this on as contract work, provided that you allow me to assign copyright of the final code to Jules so it can end up in the JUCE mainline for everyone to use.

Unfortunately, I simply don't have the resources to pay for this (though I have already paid Jules to put a feature into JUCE so I'm cool with that... even though I never ended up using it!   Not your fault, Jules.  :-D)

While it is a commercial project, I'm basically losing money working on it, because our sales are not-so-great.

If you had hints on how to proceed, I'd be more interested in doing it myself and contributing it to JUCE...

....would the approach I originally described work for the "immediate future"?

It's more important for me to quickly be able to satisfy this request with something that works now, and then do it right in early 2014 when things are clear for me, than to do the 100% right now at the cost of time.

My suggestion is to use FFMPEG library for the audio decoding. It will solve also the problem of reading WMA files from Macs ( fact you will have access to whatever audio format that you can imagine). There are also a few libraries for decoding only MP4... for example FAAD2.

See this link: which leads to this project

Seems great - EXCEPT that the five people who reviewed it all gave it 1 star, the lowest ratings.  :-D  But, that might have been a long time ago.  Reading the code, it looks pretty good...!

Anyone have any experience with it?  I'm going to try to use it, and will report back.




Yes, I forgot to mention ffaudfmt implementation... it worked when I tried it, but I don't use (yet) the JUCE classes for audio decoding.

In my code I follow a similar approach than AVBIN:

AVBIN library is a good example of how to use FFMPEG but ffaudfmt is a very good start too if you are using JUCE infrastructure for audio decoding/playing.

The truth is that handling all the current audio formats has been always a problem in the software that I develop, at the end FFMPEG has worked fine, I would prefer that JUCE directly could decode all the formats by itself but I understand perfectly that it's a titanic work, maybe Jules should evaluate the option to use a wrapper around FFMPEG instead of trying to implement custom/native platform decoders, of course Jules way is by far more elegant (...and it avoids external library dependencies) but it's difficult to maintain from my point of view (...and just imagine the work involved if you want to decode video formats too).

Doesn't that seem like the right tactic?

I looked at libav, but they have a stupidly long set of legal conditions ( together with a threat to sue, so I'm really not interested in even opening that Pandora's box.


I wrote ffaudfmt but both juce and ffmpeg changed since then, unfortunately...

I also wrote DirectShow video component for juce. If your users have directshow mp4 codecs installed they might be able to play it using DirectShow video component (without video). Take a look at it, it should be easy to modify it for your needs.

Best option is to look at WindowsMediaFoundation AudioClip example at msdn (please search for "audioclip msdn")