Re: AVAssetReader crashing under 10.8.2
Re: AVAssetReader crashing under 10.8.2
- Subject: Re: AVAssetReader crashing under 10.8.2
- From: Matthias Hänel <email@hidden>
- Date: Fri, 04 Oct 2013 13:17:28 +0200
Hi Chris McGrath,
well, the actual reading and the startReading is in the same function and this function is only called
by one thread. Nevertheless, I had a quicktime implementation of my code and DTS told me I would have
to port to AVFoundation to solve thredaing issues btw ;) Now, I am almost on AVFoundation
and I expirence the similar issue (this time no crash but stalls).
The only reason why I am cancelReading so often is, because I need to change the Reader position.
ASAIK, there is no other possibility than to stop everything and to fire it up again.
Do you know a better solution?
kind regards
Matthias
Am 04.10.2013 um 08:53 schrieb "McGrath, Christopher" <email@hidden>:
> From memory, it's important that all of these operations are happening in the same thread - I think there's an assumption in AVFoundation that you must call copyNextSampleBuffer from the same thread as the thread that kicked off the reading. Calling these functions from other threads can have unpredictable results including crashes, deadlocks, and "stalls".
>
> Is this the case in your code? Dispatching to the global queue could result in a call from any number of threads.
>
> Chris.
>
> Sent from my iPhone
>
>> On 4 Oct 2013, at 4:46 pm, "Matthias Hänel" <email@hidden> wrote:
>>
>> Hey Chris,
>>
>>
>> this is quite a coinsidence since yesterday I have found a similar bug as well. Are you sure this 200ms wait will solve the problem?
>> I am on 10.8.5 and I don't see a crash, but a stall some times in copyNextSampleBuffer. this makes it not similar, I know.
>> The stall occours only after I scrubbed, that means very fast position changes. To change a possition I haven't found another solution
>> then to cancel the Reader, release it an build the entire reader once more see here:
>>
>> <snippet>
>> [assetReader cancelReading];
>> if( assetReader )
>> {
>> [assetReader release];
>> assetReader = nil;
>> }
>> if( audioOutput )
>> {
>> [audioOutput release];
>> audioOutput = nil;
>> }
>>
>> NSError* error = nil;
>> assetReader = [AVAssetReader assetReaderWithAsset: asset
>> error: &error];
>> [assetReader retain];
>>
>> if (error == nil)
>> {
>> audioOutput = [[AVAssetReaderTrackOutput assetReaderTrackOutputWithTrack: audioTrack outputSettings: decompressionAudioSettings] retain];
>> </snippet>
>>
>>
>> There you might notive the similarity ;) I know it is pretty heavy to release everything and build everything up again and it
>> obviously shows the bug you encountered.
>> Probably, I cannot dispatch the cancelReading, I'll have to wait there :( This is unfortunetly, not a sufficient solution for real world
>> applications.
>>
>>
>> kind regards
>> Matthias
>>
>>
>>
>>> Am 02.10.2013 um 17:52 schrieb Christopher Ashworth <email@hidden>:
>>>
>>> Hi again all,
>>>
>>> I'm happy to report that we eventually found a workaround for this, which I'll share here in hopes of helping some future developer searching through the archives:
>>>
>>> It appears that Apple's code has a race condition when you cancel an AVAssetReader that is still spinning up from a call to startReading.
>>>
>>> We managed to mostly (entirely?) avoid this crash by adding a delay of 200ms before our call to cancelReading, which in our code can sometimes happen quickly after we call startReading. e.g.:
>>>
>>> AVAssetReader *localReader = _reader; // local variables are retained by blocks
>>> double delayInSeconds = 0.2;
>>> dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));
>>> dispatch_after(popTime, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void){
>>> [localReader cancelReading];
>>> });
>>>
>>> Hope that helps someone,
>>>
>>> Chris
>>>
>>>> On Aug 14, 2013, at 9:57 AM, Christopher Ashworth <email@hidden> wrote:
>>>>
>>>> HI all,
>>>>
>>>> We're also encountering this crash in the AQClient thread, now in 10.8.4. It has been difficult for us to recreate ourselves, but it's far and away our most common crash.
>>>>
>>>> I spoke with the original poster (Michael) off list and it sounds like our scenarios are similar: we're both handling all buffering, playback, and sync directly. We use AVAssetReader to extract and then buffer frames on a background thread.
>>>>
>>>> In our case, our code can operate both reading using CoreAudio (ExtAudioFileRef) or AVAssetReader. The two code paths have minimal differences, except for this crash.
>>
>>
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden