Crash related to juce_QuicktimeAudioFormat?

Hello All (or more specific: Jules),

let me just start by stating that i’m using (and am bound to) the Git version of Juce as of 10 June 2010. So perhaps this issue might be addressed already.

i’ve been developing an application that, amongst other thing, has a file browser that automatically creates thumbnails of all Audio / Video files in the chosen folder. For audio files, the readers for these files are created on the Main thread, and are passed into a AudioThumbnail object that uses a AudioThumbnailCache to make the process async.

I recently had some problems with a specific Quicktime audiofile (2 sec stereo 44 khz AAC, .mov). If this file is duplicated a number of times in the same folder, it would give an access violation when creating the thumbnails.
The stack showed it had something to do with ScopedAutoReleasePool -> [QTMovie dealloc].
This led me to think that it isn’t clear who is responsible for cleaning up the movie data. Indeed, when looking in juce_QuicktimeAudioFormat.cpp, DisposeMovie( movie ); is called in the readers deconstructor. If I omit this line, the crash doesn’t happen.
This workaround / fix doesn’t seem to leak any memory.

The strange thing is that this crash seems to be specific to Mac, it’s not happening on Windows.
Also when doing:

File movFile(T("awfulFile.mov"));
OwnedArray<AudioFormatReader> readers;
AudioFormatManager::getInstance()->registerBasicFormats();
for(int i=0;i<10000;i++)
   readers.add(AudioFormatManager::getInstance()->createReaderFor(movFile));

Then the crash won’t happen on either platform. This leads me to think that this is a threading issue… but I’m certainly no expert on this.
Any thoughts?

Hmm, it does sound like the movie handle that the QTMovie object returns is getting deleted by the QTMovie object. That’ll happen when the QTMovie’s autorelease pool goes out of scope, which explains why your test code there would be ok - it’s all running within the same autorelease pool scope.

Not really sure what to do about it, I guess you should just remove the DisposeMovie call if that works for you. The old Quicktime API is deprecated (it’s already unavailable in 64-bit builds), so I’m not keen to spend any time maintaining it - I’ll replace it with the newer (and much better!) audio codec APIs in the near future.

oh, i like to hear that :slight_smile: (but don’t remove the Quicktime Audioformat, i still need it)

Jules, any news about when the near future will be? :slight_smile:

Bit busy on other stuff right now, but it’s on my to-do list!

Cool, would be also nice to see a DirectShowAudioFormat or something like this on the windows side :slight_smile: