Remarque, pour la question ci-dessous: Tous les actifs sont en local sur l'appareil-pas de réseau de streaming. Les vidéos contiennent des pistes audio.
Je suis en train de travailler sur une application iOS qui nécessite la lecture de fichiers vidéo avec un minimum de retard pour commencer le vidéo-clip en question. Malheureusement, nous ne connaissons pas exactement le clip vidéo suivant jusqu'à ce que nous avons vraiment besoin de le démarrer. Plus précisément: Quand un clip vidéo est en cours de lecture, nous allons savoir ce que la prochaine série de (environ) 10 clips vidéo sont, mais nous ne savons pas lequel exactement, jusqu'à ce qu'il vient de temps pour "juste" jouer le prochain clip.
Ce que j'ai fait pour regarder réelle, le délais est d'appeler addBoundaryTimeObserverForTimes sur le lecteur de vidéo, avec une période de temps d'une milliseconde à voir lorsque la vidéo a effectivement commencé à jouer, et je prends la différence de l'époque de timbre avec la première place dans le code qui indique actif pour commencer à jouer.
De ce que j'ai vu donc ici, j'ai trouvé que l'utilisation de la combinaison de l' AVAsset de chargement, puis la création d'un AVPlayerItem partir qu'une fois que c'est prêt, et puis d'attendre pour AVPlayerStatusReadyToPlay avant que j'appelle jouer, tend à prendre entre 1 et 3 secondes pour démarrer le clip.
Depuis, j'ai passé à ce que je pense est à peu près équivalent: l'appel d' [AVPlayerItem playerItemWithURL:] et en attendant AVPlayerItemStatusReadyToPlay à jouer. À peu près les mêmes performances.
Une chose que je suis observation est que la première AVPlayer de l'élément de charge est plus lent que le reste. Semble une idée est de pré-vol de l'AVPlayer avec un court / vide actif avant d'essayer de jouer la première vidéo peut être de bonne pratique générale. [Démarrage lent pour AVAudioPlayer la première fois qu'un son est joué
J'aimerais obtenir la vidéo de démarrage fois vers le bas autant que possible, et d'avoir quelques idées de choses à expérimenter, mais voudrais l'avis de quelqu'un qui pourrait les aider.
Mise à jour: idée 7, ci-dessous,-mise en œuvre des rendements des temps de commutation de l'ordre de 500 ms. C'est une amélioration, mais il serait agréable de recevoir ce soit encore plus rapide.
Idée 1: Utilisation de N AVPlayers (ne fonctionne pas)
À l'aide de ~ 10 AVPPlayer d'objets et de démarrer et d'interrompre tous les ~ 10 clips, et une fois que nous savons ce qui nous a vraiment besoin, passez, et d'annuler la pause les corriger AVPlayer, et de tout recommencer pour le prochain cycle.
Je ne pense pas que cela fonctionne, parce que j'ai lu il y a environ une limite de 4 active AVPlayer's dans iOS. Il y avait quelqu'un demander à ce sujet sur StackOverflow ici, et a découvert le 4 AVPlayer limite: fast-commutation entre-deux-vidéos-aide-avfoundation
Idée 2: Utilisation de AVQueuePlayer (ne fonctionne pas)
Je ne crois pas que bousculer 10 AVPlayerItems en AVQueuePlayer serait de pré-charger tous pour un début. AVQueuePlayer est une file d'attente, et je pense que ça rend la vidéo suivante dans la file d'attente prêt pour la lecture immédiate. Je ne sais pas lequel de ~10 vidéos nous ne voulons lire, jusqu'à ce qu'il est temps de commencer. ios-avplayer-vidéo-préchargement
Idée 3: Charger, Jouer, et de conserver AVPlayerItems en arrière-plan (pas sûr à 100% encore, mais pas à la recherche de la bonne)
Je suis en train de regarder si il n'y a aucun avantage à charger et jouer à la première seconde de chaque clip vidéo dans l'arrière-plan (supprimer la vidéo et la sortie audio), et de conserver une référence à chaque AVPlayerItem, et quand nous savons que l'élément sur lequel doit être joué pour de vrai, swap que l'on dans, et remplacez le fond AVPlayer avec celle qui est active. Rincer et Répéter.
La théorie serait que récemment joué AVPlayer/AVPlayerItems'peut encore tenir quelques préparé ressources qui permettrait de faire une autre lecture plus rapide. Jusqu'à présent, je n'ai pas vu les avantages de cela, mais je ne pourrais pas avoir l' AVPlayerLayer configuré correctement pour l'arrière-plan. Je doute que cela va vraiment améliorer les choses de ce que j'ai vu.
Idée 4: Utilisation d'un format de fichier différent, peut-être celui qui est le plus rapide à charger?
Je suis actuellement à l'aide .m4v (vidéo MPEG4) H. 264 format. H. 264 a beaucoup de différentes options de codecs, il est donc possible que certaines options sont plus rapides pour demander que d'autres. J'ai trouvé que l'utilisation de paramètres plus avancés que réduire la taille des fichiers d'augmenter le temps de recherche, mais n'ont pas trouvé toutes les options qui vont dans l'autre sens.
Idée 5: Combinaison de lossless format vidéo + AVQueuePlayer
Si il y a un format vidéo qui est rapide à charger, mais peut-être que la taille du fichier est de fous, une idée pourrait être de pré-préparer les 10 premières secondes de chaque clip vidéo avec une version qui est pléthorique, mais plus rapide à charger, mais de retour avec un actif qui est encodé en H. 264. Utiliser un AVQueuePlayer, et ajouter les 10 premières secondes dans le format de fichier non compressé, et un suivi par un autre qui est en H. 264, qui reçoit jusqu'à 10 secondes de la préparation et de la précharge du temps. J'aimerais obtenir le meilleur des deux mondes: démarrage rapide de fois, mais bénéficie également d'un format plus compact.
Idée 6: Utilisation d'un non-standard AVPlayer / écrire mon propre / l'utilisation de quelqu'un d'autre
Compte tenu de mes besoins, peut-être que je ne peut pas utiliser AVPlayer, mais avoir recours à des AVAssetReader, et de décoder les premières secondes (éventuellement écrire raw fichier sur le disque), et quand il s'agit de la lecture, utiliser le format raw pour jouer rapidement vers l'arrière. Semble comme un projet énorme pour moi, et si j'y prendre d'une façon naïve, elle ne sait pas / peu probable à même de mieux fonctionner. Chaque décodé et non compressé l'image vidéo est de 2,25 MO. Naïvement parlant -- si nous allons avec ~ 30 fps pour la vidéo, je finirais avec ~60 MO/s en lecture à partir du disque exigence, qui est probablement impossible / le poussant. Évidemment, nous aurions à faire à un certain niveau de compression de l'image (peut-être natif openGL/es formats de compression via PVRTC)... mais c'est un peu fou. Peut-être il y a une bibliothèque là-bas que je peux utiliser?
Idée 7: regrouper le tout en un seul film de l'actif, et seekToTime
Une idée qui pourrait être plus facile que certains de ce qui précède, est de regrouper le tout en un seul film, et l'utilisation seekToTime. Le truc, c'est que nous allions sauter tout autour de la place. Essentiellement d'accès aléatoire dans le film. Je pense que cela peut vraiment travailler sur ok: avplayer-film-jeux-gal-en-ios5
L'approche qui pensez-vous serait le mieux? Jusqu'à présent, je n'ai pas fait beaucoup de progrès en termes de réduction de la gal.
