Apple

Mi Michael,

thanks for sharing your approach, I wasn’t aware of the kCMSampleBufferAttachmentKey_TrimDurationAtStart property before.

I looked a bit into your example code and also fiddled around with the above attachment property. Unfortunately, I haven’t found a solution to any of our problems, in fact the situation seems to be worse than I thought. Here are my findings briefly summarized:

I can also confirm the results from your example project, 64 bit builds report 0 on both priming/remainder numbers. Note that you pass 441000 instead of supposedly 44100 to your PCM ASBD, but that doesn’t seem to influence the point you are making.
I tried to reconstruct your approach of retrieving priming/remainder samples using the AudioConverter services:

I construct the AudioConverter using the compressed format as the source format, and my desired linear PCM format as the target format
If I have a magic cookie from a file, I pass it to the converter’s property kAudioConverterDecompressionMagicCookie
I retrieve the prime info using the property kAudioConverterPrimeInfo
As expected, under 64 bit this of course also reports zero for both priming and remainder figures
Under 32-bit, I get 2112 for my test AAC-compressed file. However, even 32-bit mode doesn’t seem to be perfectly working, as I would also expect a remainder of 134 samples for my file but was given zero (134 was reported by the afinfo command line utility).
Also, this approach using AudioConverter doesn’t report any priming/remainder figures for mp3 files.

ExtAudioFile/AudioFile APIs work both under 64 bit and 32 bit and correctly report the figures.
Using AVFoundation I can use the sample buffer attachment keys TrimDurationAtStart and TrimDurationAtEnd, both under 32 and 64 bit, to correctly retrieve priming/remainder figures from AAC-compressed files. This approach, however, would require me to parse the complete file, as the TrimDurationAtEnd is only report in one of the last few sample buffers. Therefore this is not a desirable approach. These attachments are also not given for mp3 files, only for AAC compressed files.

One other approach that I could think of, and that might also work for you, is to use the AudioFile services using AudioFileInitializeWithCallbacks. I would draw data using AVFoundation from the movie/sound file, and pass it to AudioFile services when the callbacks notify me of doing so. I would then hope to get proper priming/remainder figures using the AudioFile API.

I agree with you that using the AudioConverter services would be the easiest approach, but it seems to be failing on so many ends. I hope we can find a solution or at least valid workaround for this.

best regards,

Heinrich

On 18.10.2012, at 23:14, Michael Miller <email@hidden> wrote:

Hi Heinrich,

I saw your post while searching for solutions but came up empty-handed just like you. I'm not sure how much you can rely on the result of the method below. It does give me 2112 and seems to make some amount of sense, but again, seems a little bit fragile.

I'm using AVAssetReader to get out compressed frames from the AVAsset by passing in NULL for the options dictionary in the AVAssetReaderTrackOutput. When I start reading, I know what presentation time I asked for. AVFoundation will accommodate that request by returning a CMSampleBuffer with a TrimAtStart attachment that seems to cover both the priming frames and the offset into the buffer to make its output presentation timestamp match the requested time. Therefore, I do something like this:

CMTime startTime = CMTimeMake(10000, 44100);
CMTimeRange range = CMTimeRangeMake(startTime, kCMTimePositiveInfinity);
[assetReader setTimeRange:range];
AVAssetTrack* track = [[asset tracksWithMediaType:AVMediaTypeAudio] objectAtIndex:0];

AVAssetReaderTrackOutput* output = [AVAssetReaderTrackOutput assetReaderTrackOutputWithTrack:track outputSettings:nil];
[assetReader addOutput:output];
[assetReader startReading];

if ([assetReader status] == AVAssetReaderStatusReading)
{
if (CMSampleBufferRef buffer = [output copyNextSampleBuffer])
{
if (::CMSampleBufferGetDataBuffer(buffer))
{
// The time of the buffer we received, which should preceed the time we requested
CMTime presentationTime = ::CMSampleBufferGetPresentationTimeStamp(buffer);

// The time we requested in presentation units
CMTime requestedTime = [track samplePresentationTimeForTrackTime:startTime];

// trim = priming frames + offset into buffer to satisfy our requested time
CFDictionaryRef trimAtStartDictionary = (CFDictionaryRef)::CMGetAttachment(buffer, kCMSampleBufferAttachmentKey_TrimDurationAtStart, NULL);
CMTime trimAtStart = trimAtStartDictionary ? ::CMTimeMakeFromDictionary(trimAtStartDictionary) : kCMTimeZero;

// Therefore, priming frames = trim - offset
CMTime offset = ::CMTimeSubtract(requestedTime, presentationTime);
CMTime primingFrames = CMTimeSubtract(trimAtStart, offset);
printf("Priming frames: ");
CMTimeShow(primingFrames);
}

CFRelease(buffer);
}
}

Relying on the AudioConverter's result based upon the AudioStreamBasicDescription and magic cookie in the CMFormatDescription seems more sound to me, but again, it fails in 64-bit for some reason.

Thanks!
Michael Miller

On Oct 18, 2012, at 4:23 PM, Heinrich Fink wrote:

Hi Michael,

Unfortunately, I can't use the AudioFile API to get the packet table because I'm dealing with both movie files and audio files. And AVFoundation doesn't seem to provide this information in any direct way, though I can introspect about it in a somewhat sketchy fashion.

I know this is not really helping you with your main issue, but I have posted a question about retrieving priming/remainder figures

with AVFoundation recently, but haven't got an answer so far (I need to read mov files as well...). Would you mind briefly describing the "sketchy" way of doing so? I would really appreciate that!

I would be glad to run your example code, and give you feedback on that, once I'm back in the office.

Best regards,

Heinrich

References:
	>Re: AAC Priming Info Under 64-bit (From: Heinrich Fink <email@hidden>)