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: Tue, 08 Oct 2013 12:31:52 +0200
To whom it may concern,
I am pretty sure I found what causes the bug at cancelReading.
The problem only occours if I do any sample conversion while decoding.
According to several sources in the internet the conversion is beeing
made through usage of an AudioQueue. This probably has the bug we are currently
concerned.
Currently, I disabled the audio conversion. That means AAC decodes to some
weird float data. Playing this as raw PCM makes it sound pretty noisy.
But, I can test the cancelReading-Bug. It has never ever occoured in my cases
anymore. My conclusion right now is that this bug only occours in audio with
conversion.
So I have to do the float/pcm and the Samplerate conversion on my own.
I though using AudioConverterFillComplexBuffer with an AudioConverterNew is
appropriate way to do this. Unfortunately, the AudioConverter is not beeing
created. I am using this for inputoptions:
// fill in format information
CMAudioFormatDescriptionRef formatDescription = (CMAudioFormatDescriptionRef) [audioTrack.formatDescriptions objectAtIndex: 0];
inputDescription = (AudioStreamBasicDescription*)CMAudioFormatDescriptionGetStreamBasicDescription (formatDescription);
Unfortunately, pretty nessecarry variables are zero inputDescription->mBitsPerChannel, inputDescription->mBytesPerFrame,
inputDescription->mBytesPerPacket so the AudioConverter never creates a correct object. Any idea?
kind regards
Matthias
> 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
_______________________________________________
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