Streaming

Un article de Wiki Paris Descartes.

Des clés pour comprendre l'Université numérique
Accès par catégories au glossaire : Accès thématique
HYPERGLOSSAIRE : A B C D E F G H I J K L M N O P Q R S T U V W X Y Z



(ou Lecture en transit)
Concept inventé en 1994 par la société Real Networks.
Le streaming consiste à lire en temps-réel un média qui n'est pas présent sur votre disque dur mais sur un serveur Internet.
Le streaming est une technique de transfert de données (audio ou vidéo) sous forme d'un flux (stream) régulier et continu autorisant sa lecture (écoute ou visualisation) quasi simultanée à sa réception. Le flux peut être du direct (Live) ou non (media de longue durée préalablement enregistré sur disque). Dans le second cas, on parle de "lecture anticipée" (on dit aussi qu'on "streame" un fichier).
Le streaming permet ainsi de diffuser des contenus multimédias sur Internet depuis un serveur, à la demande et en temps réel, et ce sans que l’utilisateur ait à télécharger tout le fichier.


Pour cela, le serveur découpe le fichier audio ou vidéo en paquets de données dont la taille est adaptée à la bande passante disponible entre le client et le serveur. Quand celui-ci a reçu suffisamment de paquets (bufferring), l'application cliente (le lecteur multimédia ou player) restitue au fur et à mesure le contenu : elle parallélise ainsi la réception des données et leur restitution.

Ses applications sont multiples : formation à distance, vidéo et cinéma à la demande (VoD : Video On Demand), diffusion en live (télévision, concert en direct), diffusion de conférences, etc. En pratique, l'utilisateur pourra, en "cliquant" sur un hyperlien vers un média avec son navigateur, accéder à une fenêtre dans laquelle il pourra, via son lecteur multimédia, visualiser la vidéo ou entendre le flux audio demandé.

Sommaire

« Faux » et « vrai » streaming

Il existe deux sortes de streaming.

Streaming statique (ou pseudo-streaming)

  • Il s’effectue à partir d’un serveur web « standard » et utilise les protocoles HTTP et FTP basés sur TCP. Il ne nécessite donc pas de serveur spécialisé.
  • Il consiste à lire progressivement le fichier multimédia pendant son téléchargement. Après un temps de latence nécessaire au chargement des premières secondes, celles-ci sont lues tandis que la suite du fichier se charge. Le fichier est donc simplement proposé au téléchargement, de la même manière que tout autre type de fichier, et c'est le navigateur ou client (lecteur multimédia) qui se charge d'effectuer le streaming. La copie du fichier téléchargé est détruit par le navigateur à la fin du traitement.
  • Il permet de délivrer tout type de médias mais préalablement préenregistrés : il ne peut pas transmettre de flux en temps réel.
  • Les paquets perdus sont retransmis jusqu'à ce qu'ils soient reçus.
  • Il ne peut pas utiliser les modes de fonctionnement en broadcast ou multicast
  • Il ne peut pas sauter un passage de la vidéo sans télécharger tout le début.
  • Il n’est pas arrêté par les Nat ou par les FireWall.
  • Il ne s’adapte pas à la qualité de connexion de l'utilisateur. Il devient ainsi souvent nécessaire de proposer sur le serveur plusieurs fichiers encodés en plusieurs qualités (avec des résolutions différentes) afin de permettre à l'utilisateur de choisir en fonction des capacités de sa connexion.

Streaming dynamique (ou « vrai » streaming)

  • Il nécessite un serveur spécialisé, appelé serveur de streaming, et utilise le protocoles RTP / RTCP sur UDP pour diffuser le contenu.
  • Il n'est pas nécessaire de télécharger l'ensemble du fichier. Le serveur n'envoie à l'internaute que les données dont il a besoin, qui sont automatiquement effacées après lecture.
  • Ce streaming est le seul capable de transmettre du contenu en temps réel. Il convient également pour la diffusion de médias préenregistrés.
  • C’est le support des modes broadcast et multicast (un seul flux pour plusieurs clients).
  • Il n'utilise jamais plus de bande passante que nécessaire.
  • Il autorise un accès aléatoire pour les vidéos préenregistrées.
  • Il ne laisse pas de copie du média sur le disque dur du client.
  • La vidéo est coupée si le flux de données est supérieur à la bande passante disponible.
  • Les transmissions peuvent être affectées par des pertes de données.
  • Il peut être bloqué par certains NAT ou FireWall.

Les différentes étapes du streaming

Le streaming est le traitement appliqué à un flux de données en temps réel transitant sur le serveur ou à un montage vidéo ou à un fichier audio installés sur le serveur. Il procède en plusieurs étapes :

Encodage

Afin de réduire le nombre de paquets de données à transmettre (et donc économiser la bande passante nécessaire) et permettre leur lecture en temps réel, les fichiers multimédias doivent être compressés dans un format de streaming du serveur : c'est l'encodage.

Cela suppose deux opérations : la compression à l’aide d’un codec et le multiplexage dans un conteneur (muxeur).

Compression avec un codec

Un codec (pour "COmpression/DECompression") est un algorithme de compression utilisé pour réduire la taille d'un flux ou d’un fichier (audio ou vidéo). Il génère un format de compression spécifique. Il y a des codecs audio et des codecs video.

MPEG-1, MPEG-2, MPEG-4, DivX, Vorbis, MP3 (etc) sont des codecs.

Il existe de nombreux formats de compression.

On distingue deux types de compression :

  • La compression sans perte
    La compression sans perte se base sur la fréquence d'apparition de mots binaires dans le flux binaire représentant une image ou une source audio. Elle réduit la quantité d'information à transmettre aux clients en comptabilisant le nombre de fois qu'apparaît continuellement chacun des mots binaires les plus fréquemment rencontrés.
  • La compression avec perte
    La compression avec perte, quand à elle, réduit la quantité d'information à transmettre en dégradant sensiblement les données tout en conservant l'information la plus pertinente du média. Les limites des perceptions auditives et visuelles humaines aidant, ces formats de compression permettent d'obtenir des ratios avoisinant le 1/10 tout en conservant une qualité visuelle ou auditive.

Multiplexage dans un conteneur

Le multiplexage consiste à encapsuler (empaqueter) ensemble les différents flux requis dans un même fichier (conteneur) avant que celui-ci ne soit diffusé sur le réseau.
Un conteneur (ou muxeur) contient donc un ou plusieurs flux déjà encodés à l'aide de codecs, mais aussi d’autres informations qui définissent comment lire les données en indiquant le nom du codec nécessaire au décodage des flux audio et vidéo. Généralement, il y a un flux vidéo et un flux audio. Les formats conteneur les plus avancés sont capables de gérer de l'audio, de la vidéo, des sous-titres, des chapitres et des métadonnées (ou tags) et de façon synchronisée pour que les différents flux soient bien lus en même temps.

WAV, AIFF (etc) sont des conteneurs audio (flux audio seulement).
AVI, OGG, Quicktime, ASF, MP4 (etc) sont des conteneurs vidéo (flux audio et vidéo).

Les flux contenus peuvent être encodés à l'aide de codecs différents. Attention, tout codec n’est pas compatible avec tout conteneur.
Ainsi, un fichier AVI peut contenir du divx avec du mp3, ou wma, ou du mpeg, par exemple.
L'extension du fichier donne ainsi le type du conteneur des flux présents dans le fichier et les possibilités offertes à la lecture.

Diffusion des données sur le réseau - Buffering

Le fichier audio ou le conteneur vidéo est ensuite placé sur le serveur qui, à chaque requête d'un internaute, duplique le fichier demandé et le délivre sous la forme d'un flux continu de données (petits paquets de données marqués temporellement afin d’être réordonnancés de manière cohérente par le client).
C'est le serveur de streaming qui se charge de faire correspondre une URL ("Mediafile") à un flux temps-réel (direct) ou à un fichier pré-enregistré (différé): 

[protocole]://[hote]/[chemin de fichier ou d'encodeur]

par exemple: 

 rtsp://host.media.com/encoder/stream_1
 pnm://host.media.com/medialib/fichier_a
 mms://host.media.com/medialib/fichier_b

Protocoles : rtsp (protocole de l'IETF, voir-ci dessous), pnm (RealMedia), mms (microsoft)

Remarque : Le métafichier SMIL, suffixe .smil ou .smi, est un type spécial de métafichier. Techniquement parlant ce n'est pas un métafichier, mais son but est similaire. Le fichier smil permet de combinaison et l'intégration de différents contenus multimédias diversifiés (images, sons, textes, vidéo, animations, flux de texte) au sein d'une page Web en les synchronisant afin de permettre la création de présentations multimédias.

Plutôt que d'incruster un lien de ce type dans un document HTML, on préfère utiliser un metafile qui n'est autre qu'une référence (pointeur) vers un mediafile. La forme la plus simple de metafile est un fichier texte contenant un URL de la forme ci-dessus.


A cause des fluctuations réseaux, des différents parcours empruntés par les paquets et des variations de la bande passante, les paquets n'arrivent pas toujours dans le bon ordre. Les paquets sont donc regroupés et agencés dans le bon ordre dans une mémoire tampon (ou buffer) créée par le lecteur média de l'ordinateur de l'utilisateur. Au bout de quelques secondes, une fois que le buffer de réception possède assez d'informations, la lecture du flux commence et les images ou le son sont retransmis. La mémoire tampon a donc pour rôle de fluidifier le flux. Si la connexion réseau est mauvaise, l'arrivé des paquets sera ralentie. Lorsque le buffer de réception est vide, la lecture s'arrête et reprendra lorsqu'elle possèdera assez de données pour continuer. L'image est alors figée.

Lecture du média

Les différents opérations permettant la lecture du média sont assurées par le lecteur multimédia de l’utilisateur. Tout lecteur est libre (gratuit) et multiplateforme. Il dispose de plusieurs codecs à sa disposition.

  • Démultiplexage
    Le conteneur est tout d’abord démuxé (c’est le démultiplexage) : les différents flux audio et vidéo sont séparés et sauvegardés dans des fichiers différents.
  • Décompression
    Chacun de ces flux sont ensuite décodés (décompressés) en temps réel avec les mêmes codecs que ceux utilisés pour compresser ces flux. Le lecteur multimédia peut être amené à devoir télécharger le codec nécessaire (sous forme de plug-in) si celui-ci n’est pas présent dans l’environnement et s’il est autorisé à le faire (le codec requis peut être « propriétaire » et donc payant …). Ces flux sont alors restitués avec le maximum de qualité possible à l’utilisateur. Dans la plupart des cas, la compression est asymétrique : la compression (en fonction de la qualité que l'on souhaite avoir) sera plus longue et la décompression assez rapide pour permettre une lecture presque instantanée du flux.

Technologies utilisées pour le streaming

Les technologies utilisées pour encoder les données en streaming et les lire :

Real Networks

Microsoft et Windows Media Player

  • Conteneurs : ASF (.asf), WMV (wmv et .wma : audio)
  • Lecteur : Windows Media Player (et VLC Media player ?)
  • Site : http://www.microsoft.com/windows/windowsmedia/fr
  • Serveur : Windows Media Services
  • Encodeur : Windows Media Encoder
  • Environnement : version adaptée à la plupart des ordinateurs : PC, MAC, ordinateurs de poche et Stations de travail, ainsi que sur Pocket Phone.
  • Protocoles supportés : UDP / TCP / HTTP (connexion) - RTP et RTSP

Apple et Quicktime

  • Conteneurs : Quicktime (.mov), AVI (.avi)
  • Lecteur : Quicktime Player (téléchargeable gratuitement)
  • Site : http://www.quicktime.com
  • Serveur : Darwing Streaming Server
  • Encodeur : QuickTime Pro
  • Environnement : version PC et MAC
  • Protocoles supportés : UDP / TCP / HTTP (connexion) - RTP et RTSP

Format mpeg4

    Le format MPEG-4, normalisé (comme l’est le MPEG1 ou le MPEG2) et lisible par la plupart des lecteurs du marché, est en passe de devenir un format majeur.
    Malheureusement il n’est que très peu, pour l’instant, utilisé dans la pratique sur les sites web. Le seul encodeur grand public qui permet de réaliser des fichiers Mpeg4 est le Quicktime Player en version Pro.
  • Conteneur : MP4 (.mp4)
  • Ce format est lisible par les 3 lecteurs multimédias (Quicktime player, Real One player et Windows Média Player)..
  • Le plugins « Envivio » doit être ajouté au lecteur pour rendre lisible le fichier. Il est téléchargeable gratuitement depuis le site : http://www.envivio.com
  • Environnement : multi-plateformes

Des solutions alternatives

  • VLC Media Player
    Logiciel libre (GNU Open source), VLC Media Player (VideoLan Client) est un lecteur multimédia multi-plateforme qui intègre de très nombreux codecs (il exclue les codecs "propriétaires", c'est à dire payants).
    Ce logiciel peut s'utiliser soit comme un simple lecteur à la fois léger et puissant mais aussi lire des vidéos diffusées sur un réseau local en streaming et être utilisé comme serveur de diffusion de flux.
  • Cisco IP/TV

Les protocoles

La transmission de données en temps réel demande de bons débit réseaux. Il est plus facile de compenser de la perte de données que de compenser de longs délais dans la réception de données. Ce type d'accès est très différent de celui à un simple fichier statique où la chose la plus importante est que chaque paquet de données arrive à destination.

TCP (Transmission Control Protocol) est un protocole de transport « fiable », orienté connexion, fournit un flux d'octets fiable assurant l'arrivée des données sans altérations et dans l'ordre, avec retransmission en cas de perte, et élimination des données dupliquées. Il gère aussi les données « urgentes » qui doivent être traîtées dans le désordre (même si techniquement, elles ne sont pas émises hors bande). TCP essaie de délivrer toutes les données correctement et en séquence. C'est son but et son principal avantage sur UDP, même si ça peut être un désavantage pour des applications de transfert ou de routage de flux en temps-réel, avec des taux de perte élevées au niveau de la couche réseau. FTP (transfert de fichiers) et HTTP (web), protocoles applicatifs, sont basés sur TCP/IP.

UDP (User Datagram Protocol) est un protocole de transport simple, sans connexion, permettant un débit optimal mais « non fiable » : UDP ne vérifie pas que les paquets sont arrivés à destination, et ne garantit pas leur arrivée dans l'ordre. Si une application a besoin de ces garanties, elle doit les assurer elle-même, ou bien utiliser TCP. UDP est généralement utilisé par des applications de diffusion multimédia (audio et vidéo, etc) pour lesquelles le temps requis par TCP pour gérer les retransmissions et l'ordonnancement des paquets n'est pas disponible.

RTP (Real Time Protocol), est un protocole fonctionnant avec UDP ou TCP, spécialisé dans le transport de données possédant des contraintes temps réel. Il permet la diffusion de manière synchrone des flux temps réel transportés mais n'inclue pas le contrôle de la qualité de la communication. RTP reconstitue l’ordre des paquets, synchronise les média, détecte la perte de paquets.

RTCP est chargé de la partie contrôle du flux de la connexion temps réel avec le client. Il est souvent adjoint à l'usage du protocole RTP pour assurer une dynamique face aux problèmes de congestion éventuelle.

RTSP (Real Time Streaming Protocol) est un protocole de communication spécifique au streaming. Il permet de contrôler la diffusion du contenu et permet ainsi d’améliorer les performances de RTP.
Celui-ci est un « canal de retour » (ou « feedback ») qui peut informer l'émetteur sur les propriétés temps-réel du canal, l'état du tampon du récepteur, ainsi que demander des changements de compression/débit pour les applications multimédia par exemple. Par l'intermédiaire du protocole RTSP, le client est libre d'arrêter le flux provenant du serveur (mode pause) ou d'accéder directement à une partie avancée du média sans avoir à télécharger la partie passée (mode avance rapide). Il propose également au client la possibilité de négocier certaines options avec le serveur comme par exemple le type de protocole de transport à utiliser (UDP ou TCP).

Pour la diffusion en masse cependant (flux en direct, radiodiffusé ou via satellite), cette voie de retour n'est généralement pas utilisée, mais le contenu est transmis plusieurs fois en parallèle avec un décalage temporel suffisant pour pallier les interruptions temporaires de qualité de réception, mais n'excédent pas les limites des tampons des récepteurs (normalement pas plus d'une quinzaine de secondes d'écart). Le récepteur peut alors reconstituer et réordonner la séquence complète afin d'obtenir un flux continu sans perte.

Streaming unicast et streaming multicast

Un flux de streaming peut être diffusé de deux façons : individuelle ou multiple.

Streaming unicast

(Diffusion individuelle)
Connexion de point à point entre le serveur streaming et l'utilisateur.
Le client contacte le serveur de streaming grâce au protocole RTSP. En réponse à cette requête, le serveur retourne via RTSP une description de la session de streaming qu’il va ouvrir. Une session de streaming est composé d’un ou plusieurs flux (stream), par exemple audio ou vidéo. Le serveur informe le client du nombre de flux. Il donne aussi des informations décrivant les flux comme le type du média et le codec de compression. Les flux sont quant à eux diffusés séparément via le protocole RTP.
Cette méthode demande beaucoup de ressources (bande passante), car il faut allouer un flux unique par utilisateur. Mais elle permet une grande souplesse à l’utilisateur (celui-ci peut choisir le débit qui convient à son infrastructure.).

Streaming multicast

(Diffusion multiple)
Connexion de point à multi-points entre le serveur et les différents utilisateurs.
Le serveur de vidéo envoie ici une seule copie de chaque flux qui est ensuite distribuée par un routeur multi-diffusion à plusieurs utilisateurs, ce qui permet de réduire considérablement le trafic lors d’une diffusion pour de nombreux clients. Cela nécessite l'utilisation de dispositifs permettant la distribution en multicast. L'utilisateur quant à lui ne peut pas piloter le flux puisqu'il est partagé avec plusieurs utilisateurs. Le multicast est typiquement utilisé pour la diffusion en live ou le multi-conférence.

Une diffusion multicast est annoncée par un ’’ficher SDP’’ (Session Description Protocol) qui est téléchargé à partir d’un serveur web classique (Apache, IIS,...). Ce fichier contient les informations nécessaires pour recevoir le flux multicast, adresse IP du serveur, numéro du port et les informations de description des flux (même informations que celles envoyées par RTSP dans le cas d’une diffusion unicast).

Actuellement, tous les routeurs ne supportent pas le multicast. Afin de permettre aux clients situés derrière ces routeurs d’accéder aux données multicast, il est possible d’installer un serveur de streaming qui va agir comme une passerelle entre multicast et unicast. Ce serveur est connecté aux flux multicast et sert aux clients qui se connectent à lui sous la forme de flux unicast en utilisant RTP et RTSP. Cette opération s’effectue en temps réel, ce qui permet de retransmettre aussi bien des vidéos préenregistrées que des images en direct.

Liens pour approfondir

Récupérée de « http://wiki.univ-paris5.fr/wiki/Streaming »