Lecture sautant/recherchant dans un fichier MP4

Question

J'essaie de trouver la bonne technique pour effectuer un saut avant ou rechercher dans un fichier audio mp4 (ou m4a) tout en le jouant en utilisant les API AudioFileStream et AudioQueue sur l'iPhone. Si je passe l'en-tête complet mp4 (jusqu'à la boîte mdat) à un AudioFileStream ouvert, le type de fichier audio sous-jacent est correctement identifié (dans mon cas, AAC) et quand je passe ensuite la partie de données mdat réelle de la fichier, AudioFileStream commence correctement à générer des paquets audio et ceux-ci peuvent être envoyés à l'AudioQueue et la lecture fonctionne. Cependant, si j'essaie une approche d'accès aléatoire à la lecture du fichier, je n'arrive pas à le faire fonctionner correctement, à moins que j'envoie toujours la première image de la boîte mdat à l'AudioFileStream. Si au lieu de cela, après avoir envoyé l'en-tête mp4 à AudioFileStream, j'essaye alors de passer d'abord à une trame plus tard dans le mdat en appelant d'abord AudioFileStreamSeek() et en passant les données pour les paquets associés, AudioFileStream semble générer des paquets audio, mais quand je les passe à AudioQueue et j'appelle AudioQueuePrime(), je reçois toujours une erreur de 'nope' retournée.

Ma question est la suivante: dois-je toujours au moins passer dans le premier paquet de la boîte mdat avant d'essayer de faire la lecture aléatoire d'autres paquets dans le fichier mp4?

Je n'arrive pas à trouver de documentation sur la lecture aléatoire de sections d'un fichier mp4 en utilisant un AudioFileStream et un AudioQueue. J'ai trouvé QuickTime File Format pdf d'Apple qui décrit la technique de recherche aléatoire dans un fichier mp4, mais c'est juste une description de haut niveau et ne mentionne pas l'utilisation d'API spécifiques (comme AudioFileStream).

Merci pour vos commentaires.

Answer 1

Il s'avère que l'approche que j'utilisais avec AudioFileStreamSeek() est valide, je n'envoyais tout simplement pas l'en-tête mp4 initial complet à la routine AudioFileStreamParseBytes().

Le problème était que j'avais supposé que les paquets commençaient immédiatement après l'étiquette de boîte mdat. En examinant la valeur de décalage de données (kAudioFileStreamProperty_DataOffset) renvoyée par le rappel AudioFileStream Property Listener, j'ai découvert que le vrai début des données de paquet était de 18 octets plus tard. Ces 18 octets sont considérés comme faisant partie de l'en-tête mp4 initial qui doit être envoyé à l'analyseur AudioFileStream avant d'envoyer les données des paquets arbitraires après les appels à AudioFileStreamSeek().

Si ces octets supplémentaires sont omis, l'appel AudioQueuePrime() échouera toujours avec une erreur «non» même si vous avez envoyé des paquets audio analysés valides à l'AudioQueue.