Amélioration en vue de l’interaction avec le réseau

Lors du chargement de contenu multimédia sur des périphériques mobiles, il peut se produire des problèmes qui ne surviennent pratiquement jamais sur un ordinateur de bureau. Il est plus probable, par exemple, que la mémoire ou l’espace disque soit saturé. Lors du chargement d’une vidéo, les versions de bureau de Flash Player 10.1 et d’AIR 2.5 téléchargent et mettent en cache la totalité du fichier FLV (ou fichier MP4) sur le disque dur. Le moteur d’exécution lit ensuite la vidéo à partir du fichier mis en cache. Il est donc rare que l’espace disque vienne à manquer. Si cela se produit, le moteur d’exécution de bureau arrête la lecture de la vidéo.

Sur un périphérique mobile, il arrive beaucoup plus fréquemment que l’espace disque soit saturé. Si tel est le cas, le moteur d’exécution n’arrête pas la lecture comme c’est le cas sur la version de bureau. Il reprend l’écriture du fichier en cache depuis le début de celui-ci. L’utilisateur peut continuer à visionner la vidéo. Il lui est impossible d’effectuer une recherche dans la portion de la vidéo qui a été récrite, sauf au début du fichier. La mise en mémoire tampon circulaire ne démarre pas par défaut. Il est possible de la démarrer au cours de la lecture et au début de celle-ci si la taille de la vidéo est supérieure à l’espace disque ou la mémoire RAM disponible. Le moteur d’exécution nécessite au moins 4 Mo de mémoire RAM ou 20 Mo d’espace disque pour pouvoir utiliser la mise en mémoire tampon circulaire.

En tant que développeur, pensez qu’il est uniquement possible d’effectuer une recherche au sein du flux en cache. Il arrive que NetStream.seek() échoue si le décalage est hors limites, auquel cas un événement NetStream.Seek.InvalidTime est distribué.

Flash Player 10.1 et AIR 2.5 proposent un nouveau comportement, la recherche dynamique, qui améliore l’expérience de l’utilisateur lors de la lecture de vidéos en flux continu. Si l’utilisateur recherche une destination au sein de la mémoire tampon, le moteur d’exécution réutilise celle-ci pour assurer une recherche instantanée, ce qui n’était pas le cas dans les versions précédentes du moteur d’exécution. Par exemple, si un utilisateur lisait une vidéo à partir d’un serveur de diffusion en continu, que le délai de mise en tampon ( NetStream.bufferTime ) était défini à 20 secondes et que l’utilisateur effectuait une recherche en avant de 10 secondes, le moteur d’exécution supprimait toutes les données en mémoire tampon plutôt que de réutiliser les 10 secondes déjà chargées. Le moteur d’exécution devait alors demander de nouvelles données au serveur beaucoup plus fréquemment, d’où des performances de lecture médiocres sur les connexions lentes.

La figure ci-dessous illustre le comportement de la mémoire tampon dans la version précédente du moteur d’exécution. La propriété bufferTime détermine le nombre de secondes à précharger à l’avance pour qu’il soit possible d’utiliser la mémoire tampon sans arrêter la vidéo en cas de perte de la connexion :

Comportement de la mémoire tampon avant la fonction de recherche dynamique

Grâce à la fonction de recherche dynamique, le moteur d’exécution utilise désormais la mémoire tampon lors d’une recherche en avant et en arrière au sein de la vidéo. Ce nouveau comportement est illustré ci-dessous :

Recherche en avant avec la fonction recherche dynamique

Recherche en arrière avec la fonction recherche dynamique

La recherche dynamique réutilise la mémoire tampon pendant une recherche en avant ou en arrière, garantissant ainsi une lecture plus fluide et rapide. Pour les éditeurs de vidéo, ce nouveau comportement se traduit par des économies de bande passante. Cependant, si la recherche dépasse les limites de la mémoire tampon, le comportement standard est appliqué et le moteur d’exécution demande de nouvelles données au serveur.

Pour utiliser la recherche dynamique, définissez NetStream.inBufferSeek sur true .