Le téléchargement HTTP progressif est-il une alternative viable à HLS / DASH / RTMP pour fournir des vidéos en direct?

Je travaille sur un site Web qui doit diffuser des vidéos en direct aux utilisateurs, et en tant que tel, j'ai dû me renseigner sur l'état désolant de la technologie actuelle de streaming vidéo sur navigateur. Les solutions les plus populaires pour la diffusion en direct à l'heure actuelle ont toutes des problèmes de compatibilité; RTMP nécessite Flash, HLS est uniquement pris en charge nativement sur Safari et Chrome pour Android, DASH n'est pris en charge nativement nulle part et l'utilisation de dash.js nécessite des extensions de source multimédia , qui ne sont pas encore largement prises en charge.

Cela m'amène à une question qui me semble évidente: est-il possible d'utiliser le téléchargement progressif simple comme alternative aux protocoles tels que HLS, RTMP et DASH qui nécessitent soit un support de navigateur, soit des plugins?

L'idée d'utiliser le téléchargement progressif pour diffuser des médias en direct n'est pas sans précédent; les gens le font déjà pour l'audio. Des outils comme liveCaster vous permettent de diffuser de l'audio MP3 en direct via une seule réponse HTTP progressive sans avoir besoin d'un fichier MP3 préenregistré, et des bibliothèques comme AmplitudeJS ont fait tout leur possible pour ajouter des fonctionnalités liées à ce type de streaming audio en direct .

Je n'ai pas vu d'exemples de cette technique utilisée dans la nature pour la vidéo , cependant, et je ne peux pas dire pourquoi. Il semble que cela supprimerait une couche de problèmes de compatibilité difficiles et difficiles à gérer pour le navigateur pour un compromis relativement faible. (Et la compatibilité est toujours un énorme problème pour la diffusion en direct, même lorsque les pros le font; si j'essaie de regarder des vidéos en direct sur iPlayer de la BBC dans Firefox, cela me donne juste un message d'erreur me disant d'installer Flash.) Pourtant, personne n'utilise cette technique, et je n'ai jamais vu personne mentionner cette idée à part moi.

Pourquoi? Y a-t-il une limitation fondamentale que je ne vois pas qui rendrait impossible de simplement diffuser un fichier vidéo comme un MP4 via un téléchargement progressif lors de sa génération, et de le lire dans un <video>élément lors du téléchargement?

— Mark Amery
source

Ne pourriez-vous pas utiliser une bibliothèque javascript HLS (par exemple, hls.js ici: github.com/video-dev/hls.js/tree/master ) pour ajouter une prise en charge HLS multi-navigateur pour votre page? Je suppose que cela n'existait peut-être pas lorsque vous avez posé cette question à l'origine ... mais c'est le cas maintenant. :)

— stuckj

Votre question est valide et théoriquement, je pense que vous pouvez utiliser les téléchargements progressifs pour le streaming vidéo en direct. En fait, beaucoup de vidéos en ligne comme YouTube, etc. utilisent déjà HTTP. Je suppose que vous parlez strictement de live streaming et pas seulement le streaming.

Vous devrez cependant implémenter vous-même les cas d'utilisation de la diffusion en direct! Autrement, les protocoles de streaming (RTMP, etc.) font eux-mêmes. Voici quelques raisons de préférer ces protocoles et cette architecture:

1. Débit binaire variable

La plupart des vidéos en streaming en direct sont encodées en VBR et votre vidéo devra s'adapter rapidement à l'évolution de la congestion du réseau de votre client. Ainsi, votre vidéo peut passer de plusieurs résolutions en très peu de temps en fonction de la vitesse ou de la lenteur de la connexion client.

Selon Wikipedia

Il fonctionne en détectant la bande passante et la capacité du processeur d'un utilisateur en temps réel et en ajustant la qualité d'un flux vidéo en conséquence

2. Contenu en direct

Le point le plus important est que le streaming en direct signifie du contenu en direct . Contrairement au téléchargement progressif HTTP, vous ne pouvez pas mettre en mémoire tampon à tout moment. L'utilisateur doit voir le dernier cadre destiné au monde entier et ne peut pas prendre de retard.

3. Désactiver la recherche

Un problème mineur, mais le protocole ne devrait spécifiquement pas permettre à l'utilisateur de rechercher en arrière (et évidemment en avant). Cela ne devrait pas seulement être contrôlé au niveau du lecteur vidéo mais également au niveau du réseau.

4. Déconnexions fréquentes / réseau peu fiable

Je ne suis pas certain de ce point, mais je sais qu'une fois qu'un téléchargement HTTP entrant est déconnecté, cela peut prendre un certain temps pour établir une autre poignée de main (même avec keep-alive). Les protocoles en direct sont beaucoup plus rapides à connecter et à déconnecter en raison du point suivant ->

5. Latence

HTTP fonctionne par nature sur TCP, ce qui garantit la livraison des paquets. Comparez cela avec UDP utilisé dans de nombreux protocoles (en particulier les jeux multijoueurs en direct) où la vitesse est prioritaire sur les garanties.

Pour plus d'informations, voir ici -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Copie de contenu

La plupart des serveurs de diffusion en direct ne répondent qu'au contenu de l'heure actuelle. Bien qu'il soit toujours possible de copier le contenu des flux en direct, il faut recourir à la capture d'écran, etc. Donner un téléchargement progressif HTTP rend la tâche de copier du contenu assez triviale (d'où de nombreux téléchargeurs YouTube).

Maintenant, HTTP peut être modélisé pour fournir la plupart des éléments ci-dessus.

Le HTTP Live Streaming (HLS) d' Apple , vous l'avez mentionné, se rapproche le plus de ce que vous essayez d'atteindre.

Et des recherches actives sont en cours dans ce domaine, comme indiqué ici -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Je suis à la recherche de plus d'informations et mettrai à jour cette réponse.

— Gaurav Ramanan
source

Il semble incorrect de mentionner la latence comme un inconvénient de l'utilisation du téléchargement progressif HTTP étant donné que les principaux concurrents incluent DASH et HLS qui fournissent des segments de vidéo via plusieurs requêtes HTTP séquentielles. Je ne connais pas tous les détails des protocoles, mais je suppose que cette dernière approche nécessite une latence minimale d'au moins la longueur de segment utilisée, alors qu'avec l'approche de téléchargement progressif il n'y a pas de latence minimale théorique - une latence plus faible devrait être une annonce vue de l'approche de téléchargement progressif, non?

— Mark Amery

En outre, certaines des autres préoccupations ici - comme la recherche et la récupération des déconnexions - sont des problèmes qui s'appliquent également à une implémentation JavaScript de DASH, mais dash.js les surmonte probablement. J'imagine qu'ils pourraient être surmontés pour un lecteur de téléchargement progressif simplement en volant les solutions proposées par les développeurs de dash.js.

— Mark Amery du

@MarkAmery Si vous comparez à DASH et HLS, alors oui, je suppose que c'est comparable. Mais, si vous le comparez à certains des anciens protocoles sur UDP, HTTP perd haut la main! Même si vous voyez que beaucoup de systèmes en temps réel sont aujourd'hui construits à l'aide de Websockets et évitent HTTP en raison de ses problèmes de latence.

— Gaurav Ramanan du

La facilité de copie de contenu est un réel inconvénient par rapport à dash.js et HLS. Et je ne sais pas comment les flux à débit binaire variable pourraient être mis en œuvre à l'aide du téléchargement progressif, bien que je m'attende à ce que ce soit possible avec un peu de ruse.

— Mark Amery

@MarkAmery En ce qui concerne le streaming en temps réel et en direct, nous devons considérer les performances et pas seulement les possibilités. J'examinerai DASH, mais je me demande s'il existe des repères qui montrent des comparaisons de performances entre les protocoles de streaming et la récupération HTTP à partir d'une déconnexion.

— Gaurav Ramanan du