Streaming multimédia à partir de pages HTML internes, par exemple

Je suis donc un ingénieur logiciel essayant de comprendre quelques détails concrets sur le fonctionnement du streaming multimédia. J'ai passé la majeure partie de la journée à essayer de comprendre les différents codecs, formats de conteneurs et protocoles de streaming qui sont pertinents pour mon application. Jusqu'à présent, voici ma compréhension de son fonctionnement, qui pourrait très bien être induit en erreur:

• Le streaming multimédia se résume vraiment au format de conteneur et au protocole de streaming :
  • Toutes les données audio sont encodées (via un codec audio) dans un train de bits audio
  • Toutes les données vidéo sont encodées (encore une fois, via un codec) dans un train de bits vidéo
  • Les deux flux sont fusionnés ( multiplexés? ) Ensemble dans un conteneur qui devient finalement un fichier (tel que MP4, etc.)
  • Un serveur multimédia spécial sert ensuite ce conteneur (fichier MP4 ou autre format) à un client (peut-être un lecteur vidéo HTML5 exécuté dans le navigateur de quelqu'un) via un protocole de streaming standard, tel que RTSP
    • Dans le cas d'un client de navigateur, je suppose que le navigateur lui-même a un client RTSP qu'il présente ensuite aux utilisateurs HTML5 Video Player
• Je pourrais héberger un fichier MP4 à partir d'un serveur Web , tel que nginx ou httpd, mais comme ces serveurs ne sont pas des serveurs RTSP, je ne pourrais traiter les demandes de MP4 que comme des demandes de téléchargement et, par conséquent, je ne pourrais pas diffuser le fichiers multimédias
  • De même, si je devais utiliser curlpour récupérer les fichiers d'un serveur nginx, puisque ni curlni ni nginx ne parlent RTSP, il serait traité comme un téléchargement de fichier
• Mais, lorsque j'héberge un fichier MP4 à partir d'un serveur multimédia en streaming (VideoLAN, Red5, Wowza, etc.), et que j'utilise un client RTSP (ou tout client multimédia en streaming pris en charge) pour demander un flux à partir de ce serveur, cela alors et seulement puis tout streaming réel se produit
  • Par conséquent, même si les "vidéos" YouTube ou Vimeo sont hébergées sur des pages HTML servies sur HTTP (S) par des serveurs HTTP, je suppose que les lecteurs vidéo intégrés sur ces pages (où les vidéos sont effectivement lues ) commencent en fait une seconde , une connexion ultérieure à un serveur de streaming et un streaming se produit via RTSP ou un autre protocole non HTTP

C'est ma compréhension, et je suppose que je demanderais d'abord que si quelque chose que j'ai dit ci-dessus est incorrect, veuillez commencer par me corriger! En supposant que j'ai plus ou moins raison:

Comment les lecteurs multimédias en streaming, fonctionnant à l'intérieur des pages HTML et servis par des serveurs HTML, établissent-ils des connexions de streaming (RTSP, etc.) avec des serveurs de streaming multimédia (servant les requêtes RTSP)?

Comment les lecteurs multimédias en streaming, fonctionnant à l'intérieur des pages HTML et servis par des serveurs HTML, établissent-ils des connexions de streaming (RTSP, etc.) avec des serveurs de streaming multimédia (servant les requêtes RTSP)?

Applications courantes

Le RTSP semble actuellement être utilisé davantage avec des applications / interfaces de périphérique qui diffusent directement en direct (par exemple une caméra IP) ou redistribuent (comme un moteur) que pour diffuser des fichiers multimédias enregistrés à partir d'un emplacement physique via une interface de lecture Web HTTP avec un lecteur intégré.

Il semble que RTSP soit un protocole avec état et qu'il utilise plus UDP que TCP lors de la diffusion, et il est davantage utilisé comme un périphérique serveur (comme une caméra IP) qui est connecté à un réseau TCP / IP, et alimente les flux via UDP, etc. Vous vous connectez ensuite à ces flux (le serveur) en tant que client sur le même réseau et vous pouvez émettre des demandes RTSP à utiliser en conséquence.

^{Directives de protocole}

^{Bien que similaire à certains égards à HTTP, RTSP définit des séquences de contrôle utiles pour contrôler la lecture multimédia. Alors que HTTP est sans état , RTSP a un état; un identifiant est utilisé en cas de besoin pour suivre les sessions simultanées. Comme HTTP, RTSP utilise TCP pour maintenir une connexion de bout en bout et, alors que la plupart des messages de contrôle RTSP sont envoyés par le client au serveur, certaines commandes voyagent dans l'autre sens (c'est-à-dire du serveur au client).}

^{Voici les requêtes de base RTSP. Certaines requêtes HTTP typiques, comme la requête OPTIONS, sont également disponibles. Le numéro de port par défaut de la couche de transport est 554 [3] pour TCP et UDP, ce dernier étant rarement utilisé pour les demandes de contrôle.}

^{_{la source}}

^Apatride

^{Un protocole sans état ne nécessite pas que le serveur conserve les informations de session ou l'état de chaque partenaire de communication pendant la durée de plusieurs demandes. En revanche, un protocole qui nécessite le maintien de l'état interne sur le serveur est appelé protocole avec état .}

^{Un inconvénient de l'apatridie est qu'il peut être nécessaire d'inclure des informations supplémentaires dans chaque demande, et ces informations supplémentaires devront être interprétées par le serveur.}

^{_{la source}}

Flux logique

La façon dont je comprends le flux de médias en streaming sous cette forme est:

• le serveur sur lequel réside le contenu multimédia encapsulera, compressera, encodera, etc. le contenu des données vidéo / audio dans les formats et segments appropriés pour la diffusion du flux
• le serveur Web qui écoute les connexions pour accéder aux médias en streaming fournira toutes les ressources nécessaires pour diffuser les médias
• le client demande et télécharge les ressources et fichiers applicables, puis les assemble de manière continue pour la lecture via le pointeur URL tel que configuré et d'autres paramètres. Le logiciel de lecture au niveau client assemble les paquets transmis en séquence pour permettre une lecture correcte du contenu.

Veuillez consulter la section Technologies de streaming ci-dessous pour une comparaison générale de HTTP par rapport à RTSP.

en outre

Dans les 10 raisons ci-dessous pour lesquelles vous ne devriez jamais héberger vos propres vidéos , j'ai cité les parties qui vont au point d'aider à répondre à votre question en «général» sans être trop spécifique.

Essentiellement, il dit que le site Web qui contient les commandes du lecteur multimédia intégré:

• ⁽¹⁾ détecter les paramètres du navigateur Web du client lors de la "connexion et demande" du client et
• ⁽²⁾ cela définira le codec et tout autre paramètre de détection côté client sur les valeurs de paramètres applicables, puis
• ⁽³⁾ il diffusera la vidéo directement depuis le serveur de streaming sur lequel vous hébergez les fichiers vidéo et audio sur la base d'un code supplémentaire dans vos configurations de lecteur multimédia intégré pointant vers l'URL du fichier multimédia sur le serveur hébergé.

^{Technologies de streaming}

^{Le navigateur client doit recevoir les données du serveur et les transmettre à l'application de streaming pour traitement. L'application de streaming convertit les données en images et en sons. Un facteur important dans le succès de ce processus est la capacité du client à recevoir des données plus rapidement que l'application peut afficher les informations. Les données en excès sont stockées dans un tampon - une zone de mémoire réservée au stockage de données dans l'application. Si les données sont retardées dans le transfert entre les deux systèmes, le tampon se vide et la présentation du matériel ne sera pas fluide.}

^{Protocole HTTP}

^{Le HTTP est la manière prédominante dont les documents sont liés sur Internet. Le client établit une connexion avec le serveur contenant le fichier à diffuser, le fichier est récupéré et la connexion fermée. Le serveur HTTP communique au navigateur le type de fichier à transférer.}

^{Avantages de l'utilisation de HTTP}

^{Lors de la diffusion d'un fichier via HTTP, un serveur de diffusion spécial n'est pas requis. Tant que votre navigateur comprend les types MIME, il peut recevoir un fichier en streaming à partir d'un serveur HTTP. L'un des avantages distincts du streaming de fichiers à l'aide de HTTP est qu'il peut passer par des pare-feu et utiliser des serveurs proxy.}

^{Quelques inconvénients}

^{Le streaming HTTP utilise TCP / IP (Transmission Control Protocol et Internet Protocol) pour assurer une livraison fiable des fichiers. Ce processus vérifie les paquets manquants et demande qu'ils soient retransmis. Cela devient problématique dans le scénario de streaming lorsque vous souhaitez que les données soient ignorées si elles sont perdues lors de la livraison, de sorte que les fichiers dynamiques continuent de jouer. HTTP ne peut pas détecter la vitesse du modem, les administrateurs de serveur doivent donc produire des fichiers à des taux de compression différents pour les utilisateurs de serveur avec différents types de connexions. La diffusion de fichiers à partir de serveurs HTTP n'est pas recommandée pour les situations à forte demande.}

^{Protocole RTSP}

^{RTSP est le protocole standard utilisé par la plupart des fournisseurs de serveurs de streaming. Les serveurs RTSP utilisent le protocole UDP (User Datagram Protocol) pour transférer des fichiers multimédias. UDP ne vérifie pas en permanence que les fichiers sont arrivés à destination. C'est un avantage pour les applications de streaming car cela permet d'interrompre les transferts de fichiers tant que le délai n'est pas trop long. Le résultat de cette méthode est qu'il y a parfois une perte de données, mais les fichiers continuent à jouer si le retard est faible.}

^{la source}

^{10 raisons pour lesquelles vous ne devriez jamais héberger vos propres vidéos}

^{Nous parlons d'intégration et de vidéo auto-hébergée}

^{Tout d'abord, vous téléchargez votre fichier vidéo sur un service d'hébergement vidéo tiers comme YouTube, Vimeo ou Wistia.}

^{Ensuite, vous copiez un petit morceau de code qu'ils vous fournissent et le collez dans votre message ou votre page sur votre propre site WordPress. La vidéo apparaîtra sur votre site, à l'emplacement où vous avez collé le code d'intégration, mais la vidéo elle-même est diffusée depuis les serveurs de l'hôte vidéo, par opposition à votre propre serveur Web, où votre site WordPress est hébergé.}

^{4. Aucune norme de format de fichier unique pour la vidéo Web}

^{Le brouillon de la spécification HTML5 actuelle ne spécifie pas les formats vidéo que les navigateurs doivent prendre en charge. En conséquence, les principaux navigateurs Web ont divergé, chacun prenant en charge un format différent. Internet Explorer et Safari liront des vidéos H.264 (MP4), mais pas WebM ni Ogg. Firefox lira les vidéos Ogg ou WebM, mais pas H.264. Heureusement, Chrome lira tous les principaux formats vidéo, mais si vous voulez vous assurer que votre vidéo sera lue sur tous les principaux navigateurs Web, vous devrez convertir votre vidéo en plusieurs formats: .mp4, .ogv et .webm}

^{5. J'espère que vous aimez convertir des vidéos. Beaucoup.}

^{La plupart de vos spectateurs regarderont probablement vos vidéos depuis leur ordinateur de bureau ou portable grâce à une connexion Internet haut débit. Pour ces gens, vous voudrez fournir un gros fichier de qualité HD afin qu'ils puissent le regarder en plein écran s'ils le souhaitent. En général, cela signifie un fichier 1080p ou 720p à un débit binaire de streaming élevé (5000 - 8000 kbps).}

^{Mais vous voudrez également encoder une version plus petite et de résolution inférieure pour la livraison aux appareils mobiles comme les téléphones et les tablettes, ainsi que la livraison aux téléspectateurs avec des connexions Internet plus lentes.}

^{6. Lecteurs vidéo}

^{Un lecteur vidéo est un petit logiciel Web que vous installez sur votre site qui détectera automatiquement l'appareil qui demande votre vidéo, ainsi que sa vitesse de connexion, puis fournira la version appropriée à cette personne.}

^{7. Code [ou shortcodes] encombrant}

^{Que vous utilisiez un plug-in tiers ou les capacités vidéo intégrées de WordPress, vous devrez créer un peu de code pour indiquer au lecteur vidéo les formats que vous avez créés, ainsi que leur emplacement sur le serveur. Cela ressemble à quelque chose comme ça…}

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

Alors, quelle est la meilleure solution pour ajouter une vidéo à votre site?

Utilisez simplement un service d'hébergement vidéo tiers, puis intégrez simplement votre vidéo dans votre publication ou page WordPress.

Première étape: téléchargez votre vidéo sur l'un des services d'hébergement vidéo populaires et bien établis comme Vimeo PRO.

Deuxième étape: une fois que votre vidéo a été téléchargée et prête à être visionnée, copiez l'URL de votre vidéo. Retournez sur votre site WordPress et collez l'URL dans votre publication ou page où vous souhaitez que la vidéo apparaisse.

---

^{Lorsque les gens consultent votre page, la vidéo apparaît à l'emplacement où vous avez collé l'URL. Mais le fichier vidéo lui-même sera diffusé depuis les serveurs de l'hôte vidéo, par opposition à votre propre serveur, où votre site WordPress est hébergé.}

_{Le lecteur vidéo intégré détectera automatiquement l'appareil, le navigateur et la vitesse de connexion Internet de l'utilisateur, puis leur servira la version appropriée du fichier vidéo. Rien à installer sur votre site. Aucun plugin pour rester à jour. Pas de code délicat.}

_{la source}

Je traiterai ci-dessous principalement votre question de savoir ce qui se passe lorsqu'une vidéo est affichée dans le navigateur. Le sujet est vaste, je n'aborderai donc que les éléments pertinents.

HTML5 a introduit la <VIDEO>balise qui a résolu le problème d'intégration de la vidéo affichée dans le navigateur lors de l'utilisation de JavaScript et CSS. La <OBJECT>balise précédente nécessitait un logiciel externe et était mal intégrée à la page. Le nouveau tag en vigueur obligeait le navigateur à devenir également un lecteur vidéo, bien qu'aucune norme n'ait été imposée. Le résultat a été une fragmentation totale des normes, à laquelle la seule solution est que le serveur vidéo mettra à disposition plusieurs formats vidéo et que toutes ces sources alternatives soient spécifiées dans la <VIDEO>balise, à partir de laquelle le navigateur choisira celle qu'il prend en charge.

Un exemple de balise avec plusieurs sources:

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

La <VIDEO>balise elle-même est indépendante du protocole, elle peut donc utiliser n'importe quel protocole pris en charge par le navigateur, y compris RTSP. La prise en charge du protocole MPEG-DASH (Dynamic Adaptive Streaming sur HTTP) est récemment devenue très complète, donc il jouera sur la plupart des appareils et navigateurs natifs, ou en utilisant HTML5, ce qui signifie qu'aucun plugin supplémentaire n'est requis. Voir ce tableau de compatibilité des appareils et du navigateur . Consultez également cet article Mozilla pour préparer votre serveur à servir MPEG-DASH. DASH fonctionne via HTTP, donc cela fonctionnera tant que votre serveur HTTP prend en charge les demandes de plage d'octets et qu'il est configuré pour servir les fichiers .mpd avec mimetype="application/dash+xml".

L'interaction normale entre le client et le serveur ressemble à ce qui suit. Pour HTML5 VIDEO, le navigateur est également le lecteur, bien qu'il puisse ouvrir une nouvelle connexion pour la lecture.

La connexion initiale fournit les métadonnées que le client utilise pour afficher la vidéo. Si le protocole RTSP a été utilisé pour obtenir ces métadonnées, une connexion RTP est ensuite créée pour transférer les données vidéo + audio. Le protocole RTCP est utilisé pour transférer des commandes supplémentaires au serveur.

RTP, RTCP et RTSP fonctionnent tous sur des ports différents. Habituellement, lorsque RTP est sur le port N, RTCP est sur le port N + 1. Une session RTP peut contenir plusieurs flux à combiner à l'extrémité du récepteur; par exemple, l'audio et la vidéo peuvent être sur des canaux séparés.

Pour que personne ne soit exclu de votre contenu, vous devez mettre à disposition à la fois des codecs libres de droits, webM ou Theora, et de la vidéo H.264, ainsi que du Vorbis et de l'audio MP3. (Facile à dire, difficile à faire.)

Voici ce qui se passe en détail pour RTSP:

1. Le client établit une connexion TCP avec les serveurs, généralement sur le port TCP 554, le port bien connu de RTSP.

2. Le client commencera alors à émettre une série de commandes d'en-tête RTSP qui ont un format similaire à HTTP, dont chacune est reconnue par le serveur. Dans ces commandes RTSP, le client décrira au serveur les détails des exigences de session, telles que la version de RTSP qu'il prend en charge, le transport à utiliser pour le flux de données et toutes les informations de port UDP ou TCP associées. Ces informations sont transmises à l'aide des en-têtes DESCRIBE et SETUP et sont augmentées sur la réponse du serveur avec un ID de session que le client et tout périphérique proxy transitoire peuvent utiliser pour identifier le flux dans d'autres échanges.

3. Une fois la négociation des paramètres de transport terminée, le client émettra une commande PLAY pour demander au serveur de commencer la livraison du flux de données RTP.

4. Une fois que le client décide de fermer le flux, une commande TEARDOWN est émise avec l'ID de session demandant au serveur de cesser la livraison RTP associée à cet ID.

Lectures complémentaires:

• Bases des protocoles de streaming
• Présentation des protocoles de couche application - Protocole de streaming en temps réel (RTSP)
• Introduction à la vidéo HTML5 (Opera)
• Audio et vidéo HTML5: ce que vous devez savoir
• Analyse RTSP Wireshark

Voici une réponse rapide et sale-

Il y a une différence entre lire une vidéo sur le Web et la diffuser en temps réel.

La lecture se fait au moyen d'un lecteur qui est inclus dans la page Web (peut utiliser Flash, JS ou un objet vidéo html5). Le client (navigateur) télécharge ce lecteur et l'exécute. Le joueur, à son tour, récupère la vidéo à partir d'une simple URL de téléchargement. En fait, même avec Youtube, il existe des programmes qui vous permettent d'accéder directement aux fichiers vidéo hébergés et de les télécharger comme vous le feriez pour n'importe quel fichier. Étant donné que le système utilise un ancien lien de téléchargement classique, il n'est pas nécessaire de recourir à des protocoles de streaming complexes tels que RTSP

Le streaming en temps réel (par exemple, à partir d'une webcam) est ... eh bien, plus compliqué. Flash a cette fonctionnalité intégrée, mais elle ne devrait plus être utilisée. La vidéo HTML5 ne prend pas en charge la diffusion en temps réel, mais les gens ont pu la "tromper" en obligeant le serveur d'hébergement de fichiers à changer constamment le fichier vidéo qu'il propose.