La diffusion de vidéo en ligne arrive à maturité
Avec HTTP Live Streaming, la diffusion de vidéo en ligne passe un nouveau cap. Les contraintes techniques n'ont en effet pas manqué depuis les premières heures d'Internet pour diffuser de la vidéo dans de bonnes conditions. Streaming, progressive download, que se cache-t-il réellement derrière ces termes ?
Les pages web sont distribuées par le biais du protocole HTTP. Le navigateur demande au serveur la page HTML, un fichier texte qui contient notamment les adresses de chaque fichier utilisé pour sa mise en page, puis demande au serveur l'envoi de chacun de ces fichiers pour effectuer le rendu final. Les fichiers sont téléchargés, stockés dans un cache, et affichés. Il en va de même pour la vidéo, jusqu'il y a peu par le biais exclusif de plugins.
Ce procédé n'est pas sans inconvénients, puisque, en fonction du format de fichier (par exemple si la piste sonore est stockée après la piste vidéo au sein du fichier), il faut parfois attendre son téléchargement complet avant de pouvoir l'exploiter, ce qui peut s'avérer particulièrement gênant pour la vidéo, souvent synonyme de gros fichiers qui prennent donc du temps avant de pouvoir être consultés.
Fluctuat et mergitur
Afin de remédier à ce problème, on a mis au point différents protocoles, indépendants du HTTP, pour afficher les images le plus rapidement possible : le streaming était né. À Real Networks le RDT, à Microsoft le MMS, et à Adobe le RTMP. L'Internet Engineering Task Force (IETF, un organisme qui chapeaute les standards ouverts du web) a pour sa part mis en avant le RTSP, utilisé par Microsoft, Apple, et Real pour leurs serveurs de streaming. Bien que le RTSP soit libre de droits, ce protocole n'a guère été populaire en raison d'incompatibilités avec nombre de pare-feux.
Au sens le plus strict, le streaming diffère beaucoup de la conception qu'on en a communément aujourd'hui : les protocoles dédiés au streaming ouvrent une connexion de point à point entre le serveur et le poste client, et diffusent un flux de données que le poste client devra se charger d'afficher à mesure que les données lui parviennent. Ainsi, il devient possible de sauter d'un point à l'autre de la vidéo sans qu'elle ait à être chargée intégralement (une fonction que le HTTP ne prend pas en charge), ni d'attendre le chargement complet d'un fichier pour lancer sa lecture. De même, cette technologie rend possible la diffusion d'événements en direct sur le web.
Mais le streaming n'est pas sans inconvénients : en cas de congestion sur le réseau, on peut être amené à perdre des images, voire des pans entiers de séquence. Pire encore, si le débit de la vidéo, tel qu'il est envoyé par le serveur, est supérieur à celui de la connexion du poste client, la vidéo se transforme rapidement en diaporama. Pour y remédier, le streaming permet d'adapter le débit de la diffusion aux capacités constatées du poste client à mesure de leur évolution, une fonction cruciale à l'époque où le réseau téléphonique commuté était le principal mode de transmission.
D'autre part, qui dit protocole différent, dit logiciel serveur différent. Et puisque ces protocoles sont promus par des entreprises dépositaires des technologies concernées, le modèle économique (plugin/codec gratuit pour les utilisateurs finaux, logiciel serveur payant pour les diffuseurs) s'avère autrement plus onéreux : les logiciels serveurs se vendent à prix d'or.
Le HTTP n'a pas dit son dernier mot
Pour répondre à ces problèmes, les codecs vidéo ont pris en compte ces problématiques à mesure de leurs évolutions, et ont permis d'introduire le téléchargement progressif (progressive download), ou plus exactement la lecture des vidéos à mesure qu'elles sont téléchargées par le biais du protocole HTTP, introduite notamment dans QuickTime 3 en 1998. Ainsi, il n'est plus besoin d'attendre que le fichier soit intégralement téléchargé dans le cache pour que sa lecture commence. De cette manière, HTTP revêtait l'avantage de la diffusion instantanée comme pour le streaming, en plus d'être un protocole libre et gratuit, tout en conservant l'avantage de ne perdre aucun passage de la vidéo. En effet, les plugins se chargent de mesurer la quantité de cache nécessaire à stocker avant de commencer la lecture en fonction de votre bande passante afin que la lecture puisse se faire de façon ininterrompue, la fin du téléchargement devant idéalement arriver peu avant l'achèvement de la lecture.
Dans les faits, il n'est pas rare d'avoir à interrompre la lecture à cause des variations de débit qu'on finit immanquablement par rencontrer. C'est notamment cette technologie qui est à l'œuvre sur YouTube ou encore sur le portail des bandes annonces d'Apple.
Notons bien que les plugins des quatre acteurs principaux (Apple avec Quicktime, Adobe avec Flash, Microsoft avec Windows Media et Silverlight, et Real Networks avec Real Player) supportent aussi bien le streaming que le progressive download.
Malgré cette amélioration, le téléchargement progressif via HTTP conservait quelques inconvénients face au streaming : le lancement de la lecture ne se faisait pas aussi rapidement qu'en streaming, particulièrement sur les débits les plus faibles pour lesquels il faut stocker un cache plus conséquent. Le bitrate de la vidéo ne peut également pas être adapté au débit des postes clients, ce qui ne fait qu'alourdir les effets du premier point, et si on ne perd aucune partie de la vidéo, ce manque rend les interruptions de lecture en cours de chargement récurrentes. D'autre part, si l'utilisateur souhaite avancer la tête de lecture, il ne peut le faire que dans la limite de la partie déjà téléchargée de la vidéo, alors que le streaming permet de "sauter" directement aux dernières secondes de la vidéo à peine sa lecture commencée. Enfin, le progressive download ne permet pas la diffusion d'événements en direct.
Le meilleur des deux mondes
Pour remédier à ces inconvénients, Apple a mis au point un ingénieux système, baptisé HTTP Live Streaming, qui remédie à tous les manques de la diffusion par HTTP, et se paye même le luxe de quelques avantages sur le streaming. Sachant que le HTTP ne peut que diffuser des fichiers dans leur intégralité, du début à la fin, et non à partir de points arbitraires comme le permet le streaming, il suffit de "saucissonner" une vidéo en une kyrielle de fichiers de quelques secondes. Ainsi, pour peu que le logiciel client soit modifié en conséquence, il n'y a plus de problème pour sauter à un point arbitraire d'une vidéo à tout moment : le client se contente de demander au serveur la livraison du fichier correspondant. De même, il devient également possible, par le même truchement, de proposer un bitrate adaptatif : si le logiciel client note que le débit de la connexion est insuffisant pour suivre celui de la vidéo, il suffit de passer à une version alternative, d'un débit inférieur, au passage du morceau suivant, évitant ainsi l'effet d'embouteillage parfois rencontré avec le téléchargement progressif (dans la mesure des capacités du serveur). Cet élément a pour autre effet vertueux de rendre la nécessité d'un cache beaucoup moins prégnante, et de lancer immédiatement la lecture. C'est également ce qui a permis à l'Apple TV de se débarrasser de son disque dur. Enfin, la diffusion en « live » devient possible, comme on a pu le voir lors du dernier special event d'Apple. Comble du luxe, ce procédé apporte tous les avantages du streaming sans la moindre perte d'images.
Concrètement, la vidéo est morcelée par le logiciel Segmenter, et les fichiers résultants sont référencés dans un fichier de liste de lecture dérivé du M3U, qui permet du côté client de connaître la durée totale de la vidéo, les versions alternatives par débit, et les morceaux à demander au serveur en cas d'avancement de la tête de lecture. En conséquence, HTTP Live Streaming nécessite quelques aménagements, tant du côté serveur que du côté client, pour fonctionner. Apple a introduit la gestion du HTTP Live Streaming dans iOS 3.0 et dans QuickTime X, livré avec Snow Leopard, et a proposé le standard à l'IETF. Microsoft avait également mis au point un procédé semblable, nommé Smooth Streaming, mais celui-ci a pour particularité de ne fonctionner qu'avec les solutions de Microsoft, tant du côté serveur que du côté client, alors que HTTP Live Streaming peut fonctionner avec n'importe quel fournisseur.
Les pages web sont distribuées par le biais du protocole HTTP. Le navigateur demande au serveur la page HTML, un fichier texte qui contient notamment les adresses de chaque fichier utilisé pour sa mise en page, puis demande au serveur l'envoi de chacun de ces fichiers pour effectuer le rendu final. Les fichiers sont téléchargés, stockés dans un cache, et affichés. Il en va de même pour la vidéo, jusqu'il y a peu par le biais exclusif de plugins.
Ce procédé n'est pas sans inconvénients, puisque, en fonction du format de fichier (par exemple si la piste sonore est stockée après la piste vidéo au sein du fichier), il faut parfois attendre son téléchargement complet avant de pouvoir l'exploiter, ce qui peut s'avérer particulièrement gênant pour la vidéo, souvent synonyme de gros fichiers qui prennent donc du temps avant de pouvoir être consultés.
Fluctuat et mergitur
Afin de remédier à ce problème, on a mis au point différents protocoles, indépendants du HTTP, pour afficher les images le plus rapidement possible : le streaming était né. À Real Networks le RDT, à Microsoft le MMS, et à Adobe le RTMP. L'Internet Engineering Task Force (IETF, un organisme qui chapeaute les standards ouverts du web) a pour sa part mis en avant le RTSP, utilisé par Microsoft, Apple, et Real pour leurs serveurs de streaming. Bien que le RTSP soit libre de droits, ce protocole n'a guère été populaire en raison d'incompatibilités avec nombre de pare-feux.
Au sens le plus strict, le streaming diffère beaucoup de la conception qu'on en a communément aujourd'hui : les protocoles dédiés au streaming ouvrent une connexion de point à point entre le serveur et le poste client, et diffusent un flux de données que le poste client devra se charger d'afficher à mesure que les données lui parviennent. Ainsi, il devient possible de sauter d'un point à l'autre de la vidéo sans qu'elle ait à être chargée intégralement (une fonction que le HTTP ne prend pas en charge), ni d'attendre le chargement complet d'un fichier pour lancer sa lecture. De même, cette technologie rend possible la diffusion d'événements en direct sur le web.
Mais le streaming n'est pas sans inconvénients : en cas de congestion sur le réseau, on peut être amené à perdre des images, voire des pans entiers de séquence. Pire encore, si le débit de la vidéo, tel qu'il est envoyé par le serveur, est supérieur à celui de la connexion du poste client, la vidéo se transforme rapidement en diaporama. Pour y remédier, le streaming permet d'adapter le débit de la diffusion aux capacités constatées du poste client à mesure de leur évolution, une fonction cruciale à l'époque où le réseau téléphonique commuté était le principal mode de transmission.
D'autre part, qui dit protocole différent, dit logiciel serveur différent. Et puisque ces protocoles sont promus par des entreprises dépositaires des technologies concernées, le modèle économique (plugin/codec gratuit pour les utilisateurs finaux, logiciel serveur payant pour les diffuseurs) s'avère autrement plus onéreux : les logiciels serveurs se vendent à prix d'or.
Le HTTP n'a pas dit son dernier mot
Pour répondre à ces problèmes, les codecs vidéo ont pris en compte ces problématiques à mesure de leurs évolutions, et ont permis d'introduire le téléchargement progressif (progressive download), ou plus exactement la lecture des vidéos à mesure qu'elles sont téléchargées par le biais du protocole HTTP, introduite notamment dans QuickTime 3 en 1998. Ainsi, il n'est plus besoin d'attendre que le fichier soit intégralement téléchargé dans le cache pour que sa lecture commence. De cette manière, HTTP revêtait l'avantage de la diffusion instantanée comme pour le streaming, en plus d'être un protocole libre et gratuit, tout en conservant l'avantage de ne perdre aucun passage de la vidéo. En effet, les plugins se chargent de mesurer la quantité de cache nécessaire à stocker avant de commencer la lecture en fonction de votre bande passante afin que la lecture puisse se faire de façon ininterrompue, la fin du téléchargement devant idéalement arriver peu avant l'achèvement de la lecture.
Dans les faits, il n'est pas rare d'avoir à interrompre la lecture à cause des variations de débit qu'on finit immanquablement par rencontrer. C'est notamment cette technologie qui est à l'œuvre sur YouTube ou encore sur le portail des bandes annonces d'Apple.
Notons bien que les plugins des quatre acteurs principaux (Apple avec Quicktime, Adobe avec Flash, Microsoft avec Windows Media et Silverlight, et Real Networks avec Real Player) supportent aussi bien le streaming que le progressive download.
Malgré cette amélioration, le téléchargement progressif via HTTP conservait quelques inconvénients face au streaming : le lancement de la lecture ne se faisait pas aussi rapidement qu'en streaming, particulièrement sur les débits les plus faibles pour lesquels il faut stocker un cache plus conséquent. Le bitrate de la vidéo ne peut également pas être adapté au débit des postes clients, ce qui ne fait qu'alourdir les effets du premier point, et si on ne perd aucune partie de la vidéo, ce manque rend les interruptions de lecture en cours de chargement récurrentes. D'autre part, si l'utilisateur souhaite avancer la tête de lecture, il ne peut le faire que dans la limite de la partie déjà téléchargée de la vidéo, alors que le streaming permet de "sauter" directement aux dernières secondes de la vidéo à peine sa lecture commencée. Enfin, le progressive download ne permet pas la diffusion d'événements en direct.
Le meilleur des deux mondes
Pour remédier à ces inconvénients, Apple a mis au point un ingénieux système, baptisé HTTP Live Streaming, qui remédie à tous les manques de la diffusion par HTTP, et se paye même le luxe de quelques avantages sur le streaming. Sachant que le HTTP ne peut que diffuser des fichiers dans leur intégralité, du début à la fin, et non à partir de points arbitraires comme le permet le streaming, il suffit de "saucissonner" une vidéo en une kyrielle de fichiers de quelques secondes. Ainsi, pour peu que le logiciel client soit modifié en conséquence, il n'y a plus de problème pour sauter à un point arbitraire d'une vidéo à tout moment : le client se contente de demander au serveur la livraison du fichier correspondant. De même, il devient également possible, par le même truchement, de proposer un bitrate adaptatif : si le logiciel client note que le débit de la connexion est insuffisant pour suivre celui de la vidéo, il suffit de passer à une version alternative, d'un débit inférieur, au passage du morceau suivant, évitant ainsi l'effet d'embouteillage parfois rencontré avec le téléchargement progressif (dans la mesure des capacités du serveur). Cet élément a pour autre effet vertueux de rendre la nécessité d'un cache beaucoup moins prégnante, et de lancer immédiatement la lecture. C'est également ce qui a permis à l'Apple TV de se débarrasser de son disque dur. Enfin, la diffusion en « live » devient possible, comme on a pu le voir lors du dernier special event d'Apple. Comble du luxe, ce procédé apporte tous les avantages du streaming sans la moindre perte d'images.
Concrètement, la vidéo est morcelée par le logiciel Segmenter, et les fichiers résultants sont référencés dans un fichier de liste de lecture dérivé du M3U, qui permet du côté client de connaître la durée totale de la vidéo, les versions alternatives par débit, et les morceaux à demander au serveur en cas d'avancement de la tête de lecture. En conséquence, HTTP Live Streaming nécessite quelques aménagements, tant du côté serveur que du côté client, pour fonctionner. Apple a introduit la gestion du HTTP Live Streaming dans iOS 3.0 et dans QuickTime X, livré avec Snow Leopard, et a proposé le standard à l'IETF. Microsoft avait également mis au point un procédé semblable, nommé Smooth Streaming, mais celui-ci a pour particularité de ne fonctionner qu'avec les solutions de Microsoft, tant du côté serveur que du côté client, alors que HTTP Live Streaming peut fonctionner avec n'importe quel fournisseur.
yeyette |
olanparis |
Yohmi |
pseudo714 |
Funji |
Dagui |
Arnaud de la Grandière |
maestric |
Sylvain_ |
mefysto |
diboutra |
melaure |
Anonyme (non vérifié) |
rva1mac |
momo-fr |
Almux |
Cybry |
thierry61 |
Psylo |
ziggyspider |
