Concept de base sur la vidéo en direct

Question

Je suis un développeur C++ amateur qui s'intéresse au concept de diffusion de vidéo en direct sur un autre ordinateur.

Ceci est une idée très simple et abstraite que j'ai eue sur ce qui se passe et que j'aime bien lancer pour que vous puissiez voir si mes informations sont claires.

La façon dont je comprends en direct streaming est ceci:

1. serveur met en place le serveur UDP (serait plus facile sens de son message basé au lieu de connexion constante) (Je sais qu'il ya beaucoup d'autres raisons pourquoi le streaming utiliserait UDP, mais les données de l'analyse est vraiment ma faiblesse)

   1. serveur lit les données vidéo codées (je ne suis pas sûr à quelle vitesse il envoie, comme 1 image la valeur de données à la fois , etc.)
   2. Le serveur envoie au client
   3. Le client reçoit la vidéo et les décode
   4. Le client affiche la vidéo à l'utilisateur.

Est-ce que l'idée de base? Ou sont là plus. Je voulais attacher un appareil photo à mon pi de framboise et juste montrer le flux en direct à un navigateur Web (qui je crois devrait apprendre rstp)

Answer 1

D'abord, vous devez capturer la vidéo avec une API comme Directshow, AVFoundation ou v4l, selon votre plate-forme.

Ensuite, vous devez utiliser un codec pour convertir les images brutes en quelque chose que vous pouvez réellement envoyer sur un réseau pratique. Les données vidéo brutes sont énormes, donc un codec est nécessaire pour compresser avec perte ces données. À un niveau basique, les codecs seront dédoublés entre les trames afin que tout ce qui ne change pas vraiment ne soit pas envoyé pour chaque image. Les codecs sont beaucoup plus avancés que cela, en utilisant des techniques basées sur ce que nous percevons réellement (en donnant la priorité aux changements de luminosité par rapport aux changements de couleur, par exemple) pour réduire la quantité de données à envoyer. Vous n'avez pas besoin d'écrire un codec ... une telle tâche n'est pas une petite entreprise et est très complexe. Il y a beaucoup de codecs existants à choisir. Le choix de la plate-forme et la compatibilité vous donneront généralement une option ou deux.

Maintenant, vous avez besoin d'un protocole de transport. La plupart des flux vidéo sont en réalité effectués sur TCP, assurant ainsi un flux solide et non glitchy. (Les paquets UDP sont réorganisés tout le temps et peuvent être facilement perdus.) Les applications en temps réel comme la vidéoconférence utilisent souvent UDP, car la latence importe beaucoup plus qu'un flux de qualité. Il est acceptable de laisser tomber les cadres et d'avoir un petit problème dans une conversation en temps réel. Il n'est pas acceptable d'avoir de telles pépins dans un film, par exemple, ou même des flux en direct unidirectionnels où la latence n'a pas beaucoup d'importance.

Le protocole d'application que vous utilisez détermine généralement si vous utilisez TCP ou UDP. RTSP est une option, et il y en a beaucoup d'autres. Toutefois, si vous souhaitez afficher le flux dans le navigateur, vous avez besoin de RTMP avec Flash, WebRTC ou d'un protocole basé sur HTTP, tel que HTTP progressif, DASH ou HLS. DASH et HLS sont des formes de streaming segmenté, qui sont généralement implémentées en enregistrant quelques secondes et en écrivant des fichiers statiques sur le disque, où ils sont servis par un serveur HTTP normal. Un fichier manifest ou playlist est utilisé pour indiquer au client où se trouvent tous ces fichiers. (Vous pouvez utiliser les mêmes ressources directement depuis votre application si vous le souhaitez.WebRTC est conçu pour la transmission de flux de données et de médias entre deux clients connectés de pair à pair. Il est possible de créer un serveur qui agit comme l'un de ces clients. Je ne connais pas de code source ouvert pour le faire d'une manière qui vous permet d'envoyer des flux de médias. Mais, cela a été fait commercialement. HTTP progressif est l'endroit où vous pouvez simplement diffuser la sortie vers le client. Tous les formats ne peuvent pas être diffusés de cette manière. MJPEG peut fonctionner de cette façon. (MJPEG est couramment utilisé par les caméras de sécurité, il est de qualité médiocre mais facile à mettre en œuvre et fonctionnera tel quel dans la plupart des navigateurs.)

Si je faisais ce projet aujourd'hui, j'utiliserais DASH avec VP8 ou VP9 pour la plupart des navigateurs. codec vidéo (en fonction de la compatibilité), et Opus pour l'audio. Vous aurez besoin de DASH.js sur la page du client pour faciliter le chargement des segments DASH avec Media Source Extensions. C'est le moyen le plus compatible pour obtenir un flux de qualité décent.