Streaming vidéo en direct à faible temps de latence (<2s) Des solutions HTML5?

Question

Avec Chrome désactivant Flash par défaut très bientôt, je dois commencer à chercher des solutions de remplacement Flash/RTMP html5.

Actuellement, avec Flash + RTMP, j'ai un flux vidéo en direct avec un délai de <1-2 secondes.

J'ai expérimenté MPEG-DASH, qui semble être la nouvelle norme de l'industrie en matière de diffusion en continu, mais avec 5 secondes de retard, c'est le meilleur temps que je puisse en tirer.

Pour le contexte, j'essaie de permettre à l'utilisateur de contrôler les objets physiques qu'il peut voir sur le flux, de sorte que tout dépassement de quelques secondes de retard entraîne une expérience frustrante.

Existe-t-il d'autres techniques ou n'existe-t-il pas encore de solutions html5 à faible temps de latence pour la diffusion en direct?

Answer 1

Technologies et exigences

WebRTC est le seul ensemble technologique basé sur le Web qui soit réellement orienté vers une faible latence. Il est construit pour la vidéoconférence. Les codecs sont ajustés pour une faible latence sur la qualité. Les débits binaires sont généralement variables, optant pour une connexion stable sur la qualité.

Cependant, vous n'avez pas nécessairement besoin de cette optimisation à faible latence pour tous vos utilisateurs. En fait, d'après ce que je peux comprendre de vos besoins, une faible latence pour tout le monde nuira à l'expérience utilisateur. Alors que vos utilisateurs qui contrôlent le robot ont définitivement besoin de la vidéo à faible temps de latence pour pouvoir le contrôler de manière raisonnable, les utilisateurs qui ne le contrôlent pas n’ont pas cette exigence et peuvent au contraire opter pour une vidéo fiable de qualité supérieure.

Comment le configurer

 

Utilisateurs contrôlés à Robot Connection

Les utilisateurs contrôlant le robot chargeront une page utilisant certains composants WebRTC pour se connecter à la caméra et au serveur de contrôle. Pour faciliter les connexions WebRTC, vous avez besoin d’une sorte de serveur STUN. Pour contourner NAT et d’autres restrictions de pare-feu, vous aurez peut-être besoin d’un serveur TURN. Ces deux éléments sont généralement intégrés aux frameworks WebRTC basés sur Node.js.

Le serveur de caméra/contrôle devra également se connecter via WebRTC. Honnêtement, le moyen le plus simple de le faire est de rendre votre application de contrôle quelque peu basée sur le Web. Puisque vous utilisez déjà Node.js, consultez NW.js ou Electron . Tous deux peuvent tirer parti des fonctionnalités WebRTC déjà intégrées à WebKit, tout en vous laissant la possibilité de faire ce que vous voulez avec Node.js.

Les utilisateurs sous contrôle et le serveur de cames/contrôle établissent une connexion entre homologues via WebRTC (ou le serveur TURN si nécessaire). À partir de là, vous souhaiterez ouvrir un canal multimédia ainsi qu'un canal de données. Le côté données peut être utilisé pour envoyer des commandes à votre robot. Le canal multimédia sera bien sûr utilisé pour le flux vidéo à faible latence renvoyé aux utilisateurs sous contrôle.

Encore une fois, il est important de noter que la vidéo qui sera renvoyée sera optimisée pour la latence, pas pour la qualité. Ce type de connexion assure également une réponse rapide à vos commandes.

Vidéo pour voir les utilisateurs

Les utilisateurs qui visualisent simplement le flux et ne contrôlent pas le robot peuvent utiliser les méthodes de distribution vidéo normales. En fait, il est très important que vous utilisiez un CDN existant et des services de transcodage, car vous aurez 10 000 à 15 000 personnes qui regardent le flux. Avec autant d'utilisateurs, vous allez probablement vouloir votre vidéo dans deux codecs différents, et certainement dans toute une gamme de débits binaires. La distribution avec DASH ou HLS est plus facile à utiliser pour le moment et vous libère des exigences relatives à Flash.

Vous voudrez probablement aussi envoyer votre flux vers des services de médias sociaux. C'est une autre raison pour laquelle il est important de commencer avec un flux HD de haute qualité. Ces services transcoderont à nouveau votre vidéo, ce qui réduira la qualité. Si vous commencez d'abord par une bonne qualité, vous obtiendrez finalement une meilleure qualité.

Métadonnées (discussion, signaux de contrôle, etc.)

Le type de métadonnées dont vous avez besoin n’est pas clairement défini dans vos besoins, mais vous pouvez utiliser une bibliothèque de socket Web, telle que Socket.IO, pour les petites données reposant sur des messages. Lorsque vous augmentez ce nombre à quelques reprises, vous pouvez utiliser pub/sub, tel que Redis , pour la distribution des messages sur les serveurs.

Pour synchroniser les métadonnées sur la vidéo, cela dépend un peu du contenu de ces métadonnées et des exigences de synchronisation, en particulier. De manière générale, vous pouvez supposer qu'il y aura un délai raisonnable mais imprévisible entre la vidéo source et les clients. Après tout, vous ne pouvez pas contrôler la durée de la mise en mémoire tampon. Chaque appareil est différent, chaque variable de connexion. Ce que vous pouvez supposer, c'est que la lecture commence par le premier segment téléchargé par le client. En d'autres termes, si un client commence à mettre en mémoire tampon une vidéo et commence à la lire 2 secondes plus tard, la vidéo a 2 secondes de retard par rapport à la première demande.

La détection du moment où la lecture commence réellement est possible côté client. Comme le serveur connaît l'horodatage pour lequel la vidéo a été envoyée au client, il peut informer le client de son décalage par rapport au début de la lecture de la vidéo. Étant donné que vous utiliserez probablement DASH ou HLS et que vous devez utiliser MCE avec AJAX pour obtenir les données, vous pouvez utiliser les en-têtes de réponse dans la réponse du segment pour indiquer l'horodatage du début segment. Le client peut alors se synchroniser. Permettez-moi de vous expliquer cela étape par étape:

1. Le client commence à recevoir des messages de métadonnées du serveur d'applications.
2. Le client demande le premier segment vidéo du CDN.
3. Le serveur CDN répond avec un segment vidéo. Dans les en-têtes de réponse, l'en-tête Date: peut indiquer la date et l'heure exactes du début du segment.
4. Le client lit l'en-tête de réponse Date: (disons 2016-06-01 20:31:00). Le client continue à mettre les segments en mémoire tampon.
5. Le client démarre la mise en mémoire tampon/lecture normalement.La lecture commence. Le client peut détecter ce changement d'état sur le lecteur et sait que 00:00:00 sur le lecteur vidéo est actuellement 2016-06-01 20:31:00.
6. Le client affiche les métadonnées synchronisées avec la vidéo, en supprimant tous les messages des temps précédents et en les mettant en mémoire tampon pour les temps futurs.
7. Cela devrait répondre à vos besoins et vous donner la possibilité de faire tout ce dont vous avez besoin pour la réalisation de votre vidéo.

Pourquoi pas [technologie-magique-ici]?.

• Étant donné que vous n'avez pas réellement besoin faible latence pour la plupart de vos téléspectateurs, il est préférable d'optimiser leur qualité.
• Pour les 2 utilisateurs sur 15 000 nécessitant une faible latence, nous pouvons optimiser pour une latence faible. Ils auront une qualité vidéo inférieure aux normes, mais pourront contrôler activement un robot, ce qui est génial!.
• Rappelez-vous toujours qu'Internet est un lieu hostile où rien ne fonctionne aussi bien qu'il le devrait. Les ressources système et la bande passante sont constamment variables. C’est la raison pour laquelle WebRTC s’ajuste automatiquement (dans la mesure du possible) aux conditions changeantes.
• Toutes les connexions ne peuvent pas répondre aux exigences de faible latence. C'est pourquoi chaque connexion à faible latence connaîtra des abandons. Internet est à commutation de paquets et non à commutation de circuits. Il n'y a pas vraiment de bande passante dédiée disponible.
• Le fait d’avoir un tampon important (quelques secondes) permet aux clients de survivre à des pertes momentanées de connexions. C'est pourquoi les lecteurs de CD avec tampons anti-sauts ont été créés et très bien vendus. Si la vidéo fonctionne correctement, l'expérience de ces 15 000 utilisateurs est bien meilleure. Ils n'ont pas besoin de savoir qu'ils se trouvent à 5-10 secondes du flux principal, mais ils sauront certainement si la vidéo disparaît toutes les deux secondes.
• Il y a des compromis dans chaque approche. Je pense que ce que j'ai décrit ici sépare les préoccupations et vous donne les meilleurs compromis dans chaque domaine. N'hésitez pas à demander des éclaircissements ou à poser des questions complémentaires dans les commentaires.

There are tradeoffs in every approach. I think what I have outlined here separates the concerns and gives you the best tradeoffs in each area. Please feel free to ask for clarification or ask follow-up questions in the comments.

Answer 2

Ce n'est pas encore prêt (espérons-le, deuxième semestre de cette année), mais/ Protocoles basés sur HTTP Full Duplex vous permettra d'utiliser MPEG DASH sur des Websockets, offrant ainsi les avantages de DASH (open source, ABR, compatibilité ...), ainsi que la faible latence d'autres formats (par exemple, WebRTC, qui ne fonctionne pas sur safari btw ).

Donc, si vous envisagez un format vidéo à faible latence dans quelques mois, essayez de regarder pour cela.

Answer 3

Optez pour WebRTC, car:

WebRTC est une norme qui prend en charge la communication en temps réel basée sur un navigateur. Développé à l'origine par Google, le standard est maintenant géré par le W3C. WebRTC permet aux applications de navigateur à navigateur pour les appels vocaux, le chat vidéo et le partage de fichiers sans recourir à des plug-ins externes, autres qu'un navigateur compatible.

Avantages :

• Les solutions WebRTC peuvent aider à étendre les communications unifiées (UC) en temps réel au-delà des limites d'une entreprise - à tout client, partenaire ou fournisseur doté d'un navigateur WebRTC.
• Les technologies compatibles WebRTC permettent aux opérateurs de réseaux mobiles de créer une expérience client plus convaincante sur les appareils mobiles. Par exemple, l'ajout de capacités vocales ou vidéo dans une application fournie par un opérateur de téléphonie mobile permettrait à un abonné de contacter un représentant du service clientèle pour obtenir un support plus personnalisé.
• WebRTC réduit les coûts de déploiement et de support informatique des entreprises en éliminant le besoin des utilisateurs d'ouvrir des clients de communications unifiées. Dans le même temps, WebRTC permet aux opérateurs de télécommunication et aux développeurs de créer des applications de communication et de collaboration compatibles WebRTC avec des ressources de développement limitées/de base.
• Grâce à l'utilisation de normes et de navigateurs ouverts, WebRTC élimine le besoin de systèmes complexes pour étendre les utilisateurs à travers les pare-feu pour la collaboration et le partage de vidéos. Dans certains cas, WebRTC peut réellement réduire le cycle de vente global en aidant rapidement les clients et les prospects à obtenir les informations dont ils ont besoin.

WebRTC Test.