我正在尝试找出适当的技术，以在iPhone上使用AudioFileStream和AudioQueue API播放音频文件时执行向前跳过或在mp4（或m4a）音频文件中搜索。
如果我将完整的mp4标头（直到mdat框）传递给打开的AudioFileStream，则正确识别了基础音频文件类型（在我的情况下为AAC），然后当我将文件的实际mdat数据部分传递给AudioFileStream时，正确开始生成音频数据包，并且可以将这些数据包发送到AudioQueue并进行播放。
但是，如果尝试使用随机访问方法来播放文件，则除非我总是将mdat框的第一帧发送到AudioFileStream，否则似乎无法使其正常工作。如果相反，在将mp4标头发送到AudioFileStream之后，我首先尝试通过首先调用AudioFileStreamSeek（）然后传递相关数据包的数据来跳到mdat中的下一帧，然后AudioFileStream似乎会生成音频数据包，但是，当我将这些传递给AudioQueue并调用AudioQueuePrime（）时，总是收到返回“ nope”的错误。
我的问题是：在尝试对mp4文件中的其他数据包进行随机播放之前，是否总是需要至少传入mdat框的第一个数据包？
我似乎找不到任何有关在使用AudioFileStream和AudioQueue时对mp4文件的各个部分进行随机播放的文档。我已经找到了Apple的QuickTime文件格式pdf，其中描述了在mp4文件中随机查找的技术，但这只是一个高级说明，而没有提及使用特定的API（例如AudioFileStream）。
感谢您的任何见解。
最佳答案
事实证明，我与AudioFileStreamSeek（）一起使用的方法是有效的，只是我没有将完整的初始mp4标头发送到AudioFileStreamParseBytes（）例程。
问题是我假设数据包在mdat box标签之后立即开始。通过检查AudioFileStream属性侦听器回调返回的数据偏移值（kAudioFileStreamProperty_DataOffset），我发现数据包数据的真正开始是在18个字节之后。
这18个字节被认为是初始mp4标头的一部分，在调用AudioFileStreamSeek（）之后发送任意数据包的数据之前，必须将其发送到AudioFileStream解析器。
如果忽略了这些多余的字节，则即使您可能已将有效的已解析音频数据包发送到AudioQueue，AudioQueuePrime（）调用也将始终失败并显示“ nope”错误。
关于iphone - 播放跳过/寻找MP4文件，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1882309/