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: Mon, 07 Oct 2013 10:56:06 +0200
Hi Christopher Ashworth,
I did some further testing espacially with your 200ms sleep.
Unfortunately, this doesn't solve the issue. It just delays it a bit.
You'll still see a crash at this point.
Currently, I am doing this:
[assetReader cancelReading];
while( assetReader.status == AVAssetReaderStatusReading )
{}
usleep(200*1000);
I looks pretty odd but it delays the crash one more time.
I am quite out of ideas? Has anyone another idea to solve the issue?
Since I am working an audio/video decoder and I am still on the audio part
with this bug. I am wondering if this bug still persists in the Video(Image)
decoder as well. Has anyone had some observations about that?
If it occours in the video pipeline as well, I am pretty stuck, then
rewriting the audio decoder to ExtAudioFile is not an option anymore.
To be honest, I am about to rewrite all the stuff by hand, but I am not sure
which API to use. I just want to have raw audio data and corresponding raw video
data nothing more. Is there another API (without threading bugs) besides
Quicktime and AVFoundation on mac?
kind regards
Matthias
> Hi Chris Ashworth,
>
>
> I have to correct myself. It is not a similiar bug, it's exactly the same ;)
> Every now and then I see a stall or a crash. The crash is exactly where you pointed
> in AQTime.
>
> Unfortunately, I don't really understand your fix. How is it possible to defer just
> cancelReading while the application runs further. My whole AVFoundation calls are in just one
> thread that mean in general those calls to AV are safe but when I defer cancelReading the
> other calls are running on the Reader object and crash therefore. How do you do it?
>
>
> regards
> Matthias
>
>
>
>
>> 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