Le streaming vidéo adaptatif via HTTP : une réalité…

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 (RTSPMMSRTMP…) 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
Ces nouveaux formats deviennent prépondérant notamment dans le domaine des médias.

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…

5 thoughts on “Le streaming vidéo adaptatif via HTTP : une réalité…

  1. David RIO

    In fine, a usage identique, les profils d’encodage entre un device Android ou iOs sont généralement identiques. La solution à la multiplicité des encodages des vidéos est d’évoluer vers des architectures de diffusion séparant les fonctions encodages, protection et protocolisation, avec l’adoption d’un format pivot entre encodeurs et serveurs d’origine. Les contenus sont ainsi encodés une seule fois, indépendamment des protocoles de delivery et de la technologie de protection. Une autre solution consiste à utiliser des solutions d’encodage supportant des features de type ‘encode once, deliver many’.

    Reply
  2. Olivier Post author

    Totalement d’accord avec toi David, cependant, ce n’est pas aussi simple que cela. Concernant la protection, le chiffrement des contenus se fait parfois au niveau du transcodage…
    Une autre contrainte est d’effectuer cela à la volée sur des architectures à fort trafic.

    Reply
  3. yannick

    Salut, merci pour ces explications claires.
    Y a t il une documentation aussi didactiques concernant la gestion des DRM en fonction du protocole de transport utilisé (HDS, HSS, HLS)?

    Reply
    1. Olivier Post author

      C’est assez simple au final : HDS c’est Adobe Access, HSS c’est Playready. Tu peux trouver en googlisant de la documentation assez facilement.
      Pour HLS, tu peux avoir Playready ou Access ou Widevine ou Marlin … bref chacun a fait sa propre solution. Là, c’est plus difficile de trouver de la documentation, mais il y a quelques articles sur le sujet, notamment dans la langue de Shakespeare.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.