Force Perian to Decode all Audio

[niko26]

Hi,

I am experiencing crashes with a certain application. The crash signature looks like this:

Code: Select all

Thread 22 Crashed:
0   ...ickTimeComponents.component	0x912a9f95 AddChunkToSoundQueue3 + 258
1   ...ickTimeComponents.component	0x912abd8f TrackTimeToSoundQueue3 + 1476
2   ...ickTimeComponents.component	0x912adde8 Sound3PreRoll + 806
3   ...ple.CoreServices.CarbonCore	0x96c12dcc CallComponentFunctionCommonWithStorage(char**, ComponentParameters*, long (*)(), unsigned long) + 54
4   ...ickTimeComponents.component	0x912a1953 Sound3ComponentDispatch + 212
5   ...ple.CoreServices.CarbonCore	0x96c0b51f CallComponentDispatch + 29
6   com.apple.QuickTime           	0x92c135ae MediaPreRoll + 49
7   com.apple.QuickTime           	0x92c1353e prerollMedia + 85
8   com.apple.QuickTime           	0x92bcd01b ForEachMedia_priv + 82
9   com.apple.QuickTime           	0x92c130bf PrivatePrerollMovie_priv + 147
10  com.apple.QuickTime           	0x92c13015 PrerollMovie_priv + 42
11  com.apple.QuickTime           	0x92c814de MovieAudioExtractionFillBuffer_priv + 1822
12  com.xxx.xxx        	0x002e34bd TagLib::List<TagLib::FileRef::FileTypeResolver const*>::List() + 2973653
13  com.xxx.xxx        	0x002dd224 TagLib::List<TagLib::FileRef::FileTypeResolver const*>::List() + 2948412
14  com.xxx.xxx        	0x000141fc TagLib::List<TagLib::FileRef::FileTypeResolver const*>::List() + 27924
15  com.xxx.xxx        	0x00013cea TagLib::List<TagLib::FileRef::FileTypeResolver const*>::List() + 26626
16  com.xxx.xxx        	0x00014d24 TagLib::List<TagLib::FileRef::FileTypeResolver const*>::List() + 30780
17  libSystem.B.dylib             	0x9a86b259 _pthread_start + 345
18  libSystem.B.dylib             	0x9a86b0de thread_start + 34

I assume that this has to do with the QT crashing during audio decoding. This happens randomly but I have found a good way for me to reproduce this.

My questions:

1. Is there any way to force Perian to decode all audio as well? (I have already tried "defaults write org.perian.Perian DecodeAllProfiles -bool YES")

2. Does this look like a QT based problem which could not even be fixed if Perian was going to decode the audio stream?

Thanks for your help in advance!

[gbooker]

There is absolutely no useful information in this crashlog. You stated a "certain application" but fail to mention what it is. You intentionally modified the crashlog and pruned out all the useful information. You provided no sample file nor any information for us to begin to track this down. How do you expect us to do anything with this? Absolutely none of the code in the crashlog is related to Perian. How are we to even know that Perian's code has even been loaded into memory?

1. Is there any way to force Perian to decode all audio as well? (I have already tried "defaults write org.perian.Perian DecodeAllProfiles -bool YES")

What does this mean? You shouldn't be messing with hidden preferences you clearly don't understand. The DecodeAllProfiles is for H.264 video!

2. Does this look like a QT based problem which could not even be fixed if Perian was going to decode the audio stream?

How on Earth do you expect us to answer this? You provided no information to even begin to apprehend what is going on.

BTW, going on the assumption that this may be a privately written program, you are aware, of course, that you must perform all QT operations on the main thread, and let QT do it's own multithreading, right? It looks like the "certain application" is doing this in a pthread, which is clearly stated in the QT documentation as resulting in unpredictable behavior. But then again, this is pure speculation from an intentionally completely inadequate crash log.

[niko26]

First of all, thanks for the answer.

But please bear with me

There is absolutely no useful information in this crashlog. You stated a "certain application" but fail to mention what it is. You intentionally modified the crashlog and pruned out all the useful information. You provided no sample file nor any information for us to begin to track this down. How do you expect us to do anything with this? Absolutely none of the code in the crashlog is related to Perian.

True. Sorry for "hiding" all the information, but I thought there is a slim chance that someone could see what's going on here. I pasted the tracecall and thought it would help and indicate "something".

How are we to even know that Perian's code has even been loaded into memory?

If you tell me what exact information you need to find this out, I will gladly send you the information.

1. Is there any way to force Perian to decode all audio as well? (I have already tried "defaults write org.perian.Perian DecodeAllProfiles -bool YES")

What does this mean? You shouldn't be messing with hidden preferences you clearly don't understand. The DecodeAllProfiles is for H.264 video!

I am not an PErian expert and I stated that I would like to know whether you can force Perian do decode all audio because I thought DecodeAllProfiles was for all video. Seems like I was wrong. Thanks for correcting me.

Can you tell me whether there is an option so that any and all decoding goes through Perian?

2. Does this look like a QT based problem which could not even be fixed if Perian was going to decode the audio stream?

How on Earth do you expect us to answer this? You provided no information to even begin to apprehend what is going on.

That's why I tried to ask as vague as possible "does this look like". I did not ask "Is this...".

BTW, going on the assumption that this may be a privately written program, you are aware, of course, that you must perform all QT operations on the main thread, and let QT do it's own multithreading, right? It looks like the "certain application" is doing this in a pthread, which is clearly stated in the QT documentation as resulting in unpredictable behavior. But then again, this is pure speculation from an intentionally completely inadequate crash log.

All QT AudioDecoder objects are created, used and destroyed in the same thread, but multiple threads are being used, each thread uses a different object. Is that already a violation?

Also is it a violation if multiple objects are created in one thread other than the Main thread?

[gbooker]

True. Sorry for "hiding" all the information, but I thought there is a slim chance that someone could see what's going on here. I pasted the tracecall and thought it would help and indicate "something".

Well it did; you are using the wrong thread.

Can you tell me whether there is an option so that any and all decoding goes through Perian?

Again, what does this mean?

All QT AudioDecoder objects are created, used and destroyed in the same thread, but multiple threads are being used, each thread uses a different object. Is that already a violation?

Also is it a violation if multiple objects are created in one thread other than the Main thread?

First hit from a 2 second google search:
http://developer.apple.com/library/mac/ ... index.html

It seriously looks like this has nothing to do with Perian; I'm not going to answer general QT questions.

[niko26]

Can you tell me whether there is an option so that any and all decoding goes through Perian?

Again, what does this mean?

Let me get this right:

MEdia decoding is handled by QT by default. If you install PErian, Perian will handle some of the decoding, for example if QT can't decode. I thought that the "DecodeAllProfiles" would force Perian to always decode the media. It doesn't. It only enforces h.264 video.

Is there a way to force Perian to always decode any and all audio (and maybe video)?

First hit from a 2 second google search:
http://developer.apple.com/library/mac/ ... index.html

It seriously looks like this has nothing to do with Perian; I'm not going to answer general QT questions.

I actually already read them. Did you read the Thread-Safe TechNotes at all? Because it doesn't seem that you did.

Here are some excerpts:

Independent threads in your application can safely use logically disjoint sets of QuickTime objects from multiple threads. If one thread has its own unique set of QuickTime objects and another thread has its own unique set, then any operation performed on these objects can be considered thread-safe. The two threads must have no QuickTime objects in common. See Figure 1.

Restrictions:

Performing some high-level operation such as opening a movie file or converting an image from one format to another may involve a number of lower-level components such as Movie Importers, Data Handlers, Image Decompressors and so on. These components may, or may not be thread-safe and often the application doesn't have any way of knowing which lower-level components will be invoked until the operation has started.

For example, while the most widely used still image formats such as JPEG, PNG and TIFF have been made thread-safe MacPaint has not. You can use this to your advantage by having a very well defined case to test how well your code handles dealing with media requiring components that are not thread-safe. In most cases you will need to move the QuickTime object to the main thread and continue the operation.

Correct me if I am wrong, but this means it *can* be moved from the Main to a worker thread (with restrictions).

Calling EnterMoviesOnThread

Applications using QuickTime on background threads should now call EnterMoviesOnThread on each background thread before calling any other QuickTime APIs on those threads. When QuickTime will no longer be used on a background thread, the thread should call ExitMoviesOnThread. This indicates to QuickTime that the application will no longer be using QuickTime from that thread.

Again...Correct me if I am wrong, but this means it *can* be moved from the Main to a worker thread (with restrictions).

When passing a QuickTime Movie from one thread to another, call DetachMovieFromCurrentThread in the old thread and AttachMovieToCurrentThread in the new thread. This lets QuickTime know which thread owns the Movie and ensures that the Movie is not incorrectly tasked on the wrong thread. See Figure 5.

Same here.

[gbooker]

It seriously looks like this has nothing to do with Perian; I'm not going to answer general QT questions.

Translation: I'm not going to diagnose your code for you.