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?

niko26 wrote: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!

niko26 wrote: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.

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.

niko26 wrote: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?

niko26 wrote: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?

niko26 wrote: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.

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

Again, what does this mean?

niko26 wrote: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?

niko26 wrote: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)?

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.