Dans le domaine de la vidéo en ligne, l’une des principales questions ces dernières années fût de migrer des technologies classiques de streaming (RTSP, MMS, RTMP…) vers du téléchargement via HTTP. Et ceci pour plusieurs raisons :

• les coûts moins importants
• le filtrage, les ‘anciens’ protocoles étaient souvent filtré par les pare-feux
• HTTP ne demande pas de configuration particulière

Le principe

Le concept se présente de la manière suivante : différents débits de la même vidéo sont segmentés, voire fragmentés (ces morceaux de vidéos sont appelées des chunks). On liste ces différents segments dans différents fichiers manifestes permettant ainsi l’ajustement d’un débit à l’autre par le client. Le lecteur de ce dernier teste ainsi régulièrement l’état du débit et télécharge le meilleur segment suivant dans sa mémoire tampon (comme le montre la figure suivante).

L’introduction de ces technologies a permis d’un côté de réduire le coût en bande passante pour la diffusion et la mise en cache de contenu et de l’autre d’optimiser l’expérience utilisateur quelque soit son débit. En revanche, les coûts ont augmentés d’une part en terme de temps de préparation de contenus (notamment en raison des multiples transcodages) ; d’autre part, en terme de stockage de ces mêmes contenus (au lieu d’un seul fichier auparavant, on se retrouve maintenant avec un nombre important de petits fichiers).

Il est important de noter qu’en réalité, les technologies de streaming en multi-débit ne sont pas des technologies de streaming à part entière comme par exemple RTMP ; elles se basent sur le téléchargement progressif des contenus sur le protocole HTTP.

Les formats actuellement disponibles

HTTP Live Streaming (HLS)

Encore à l’état de brouillon (en version 8) mais fortement déployée, cette technologie est propulsée par Apple. On rencontre des vidéos HLS notamment sur les plateformes iOS (iPhone, iPad, iPod). On peut également en retrouver sur Android (depuis la version 3.0 : Honeycomb) et sur certains modèles de télévisions connectées. HLS se présente sous la forme de manifestes (fichiers textes .m3u8) et de segments vidéos (.ts). Il est possible de chiffrer les segments via l’algorithme AES. Le lien vers la clé de chiffrement est indiqué dans le manifeste. L’un des gros avantages de HLS est qu’il est possible de diffuser les contenus depuis n’importe quel serveurs HTTP (Apache, NGinx, …).

NB: dans le cadre d’une soumission d’applications pour l’Apple Store, il est nécessaire de se fier aux spécifications vidéos en fonction de la plateforme cible.

J’avais abordé la vidéo sur iPhone dans un précédent billet.

Smooth Streaming

Smooth Streaming est fortement lié à l’environnement de développement Silverlight de Microsoft. La diffusion de Smooth Streaming s’effectue via des serveurs IIS intégrant le module Smooth Streaming. La structure d’une vidéo Smooth Streaming se présente sous la forme suivante:

• un fichier manifeste ISM
• des fichiers vidéos ISMV correspondant aux différents débits

Smooth Streaming est utilisé via le plug-in Silverlight pour PC/Mac, sur la Xbox et sur les terminaux mobiles Windows Phone 7.

HTTP  Dynamic Streaming (HDS)

HDS est supporté par Adobe. Fonctionnant sur le même principe que HLS ou Smooth Streaming, HDS est défini via des fichiers manifestes au format XML : F4M et des segments vidéos au format F4V. Une présentation de HDS est déjà disponible.

Pour conclure, il y a cependant un problème à tout cela, il reste toujours 3 formats de diffusion; les impacts sont notamment la multiplicité des encodages des vidéos (et je n’ajoute même pas la gestion de DRM…).

Une solution pourrait tout de même résoudre cela : MPEG-DASH (Dynamic Adaptive Streaming over HTTP). Les différents acteurs citées dans l’article participent à sa définition. Si cette nouvelle technologie était appliquée sur l’ensemble des “écrans”, une grande partie des problèmes cités disparaîtrait. Une affaire à suivre…