 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : Réseau - à propos de l'envoie des flux de streaming | |
| xtress | et quel est le point fort de MC par rapport aux autres ... |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| xtress | et quel est le point fort de MC par rapport aux autres ... |
| Gardien | Le multicast point a multipoint est largement répandu c'est à dire utilisé (radio, télé sur le net, visioconf) et implémenté (dans les routeurs).
Le multicast multipoint à multipoint existe (protocole PIM-SM essentiellement) mais c très peu géré car cela pose plein d'autres problèmes comme la réservation d'adresses IP multicast -> classe D (224.0.0.0 à 239.255.255.255) avec MDHCP. Tout est à peu près normalisé (ou preske) mais de la a ce que se soit largement répandu .... Pour la question des données non synchrones entre les users, le multicast ne sert a rien ! [jfdsdjhfuetppo]--Message édité par Gardien--[/jfdsdjhfuetppo] |
| benwar | RTP/RTCP
RTP (Realtime Transport Protocol) et son compagnon RTCP (Realtime Transport Control Protocol) permettent respectivement de transporter et de contrôler des flots de données qui ont des propriétés temps-réel. RTP et RTCP sont des protocoles qui se situent au niveau de l'application et utilisent les protocoles sous-jacents de transport TCP ou UDP. Mais l'utilisation de RTP/RTCP se fait généralement au-dessus de UDP. RTP et RTCP peuvent utiliser aussi bien le mode Unicast (point à point) que le mode Multicast (multipoint). Chacun d'eux utilise un port séparé d'une paire de ports. RTP utilise le port pair et RTCP le port impair immédiatement supérieur. +-------------+ +-------------+ | |port pair port pair! | | RTP |----------- -----------| RTP | | appli A | | appli B | +-------------+ +-------------+ +-------------+ +-------------+ | |port pair+1 port pair+1! | | RTCP |----------- -----------| RTCP | | appli A | | appli B | +-------------+ +-------------+ RTP Rôle Le but du protocole RTP est de transporter des données qui ont des propriétés temps-réel. Format du paquet L'entête d'un paquet RTP est obligatoirement constituée de 12 octets, eventuellement suivie d'une liste d'identificateurs de sources contributeurs CSRCs dans le cas d'un mixer. Cette entête précède le "payload" qui représente les données utiles. Les types de payload déjà standardisés sont décrits dans le fichier "rtp-payload.html". +-------------------------+-------------------------------------- | RTP header (12 octets) | Payload ... +-------------------------+-------------------------------------- Format de l''entête RTP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ version V : 2 bits, V=2 padding P : 1 bit, si P=1 le paquet contient des octets additionnels de bourrage (padding) pour finir le dernier paquet. extension X : 1 bit, si X=1 l'entête est suivie d'un paquet d'extension CSRC count CC : 4 bits, contient le nombre de CSRC qui suivent l'entête marker M : 1 bit, son interpretation est définie par un profil d'application (profile) payload type PT : 7 bits, ce champ identifie le type du payload (audio, video, image, texte, html, etc.) sequence number : 16 bits, sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus timestamp : 32 bits, réflète l'instant d'échantillonage du premier octet du paquet SSRC: 32 bits, identifie de manière unique la source, sa valeur est choisie de manières aléatoire par l'application CSRC : 32 bits, identifie les sources contribuantes. |
| benwar | C clair c bizard vote truc... |
| Groody | je pense à un truc là...
Là ça sert dansd le cas de visio conférence par exemple, ou la video estr synchro pour tt le monde. Mais quand c'est un flux que n'importe qui peut visionner dès qu'iul le lance. AH :D |
| benwar |
[jfdsdjhfuetppo]--Message édité par benwar--[/jfdsdjhfuetppo] |
| Groody | Bah c'est ce que je pensais, oui, mais je voulais avoir confirmation.
Merci à vous :jap: |
| Pims |
|
| Groody | Je demandais ça pour mes connaissances perso. JE n'ai aucun besoin ici.
Merci pour ces réponses. Sur le net ça fonctionne ? LE multi-cast est géré ? |
| Gardien | Le multicast (en mode express = 1 seul émetteur) utilise les protocoles RTP/RTCP. J'imagine que n'importe quel serveur streaming s'en oqp tout seul. Après faut vérifier que les routeurs derrières lesquels se situe ton serveur de streaming implémente PIM-SSM, ce qui devrait etre le cas s'ils ont pas 10 ans. |
| kassdelire | :hello: En faites ca depends du protocole utilise par ton serveur de streaming.Le plus repandu est RTSP qui lui supporte le Multicast et donc normalement c'est 1 flux adresssé a un groupe d'IP Le truc c'est qu'il faut que ton routeur supporte le Multicast pour bien faire la gestion de ce groupe et permette une utilisation optimale de ta Bande Passante. |
| Groody | Ouai, et rapidement même, sinon je vais te faire courir :p (merci pour le UP :D) |
| boisorbe | ben qu'est ce que tu fais la au travail non mais :O OK je sors :lol: |
| Groody | Salut,
Si une site envoie un flux en streaming (de la video par exemple), et que (exemple) 10 personnes viennent tirer la vidéo, y'aura t'il 10 connexions sortante du serveur, 10 x la bande passante utilisé par le flux, ou y'a t'il un seul flux sortant, redirigé vers plusieurs IP (c le multicast c ça ?). ? |
