cerhu > comp.divers.* > comp.reseaux.ip

PP (17/12/2017, 19h15)
Bonjour à tous,

Je ne sais pas si le forum est le bon, tant la pauvreté des sujets
disponibles sur usenet en fr.* est importante ?

Voilà, je suis tombé sur un article intéressant à propos de la diffusion
de la télévision depuis les réseaux IP.

[..]

Cela me rappelle une phrase de Xavier Niel qui disait déjà il y a
presque une dizaine d?année que les box disparaitraient dans les 15
prochaines années.

Il semble que la migration vers le protocole IPv6 favoriserait le
développement du multicast, et notamment pour la diffusion de la
télévision via les réseaux IP. Hors où en sommes nous aujourd?hui ?

Y a-t-il des blocages qui font qu?aujourd?hui les réseaux de chaînes de
télévision ne se convertissent pas à cette technologie qui leur
permettrait d?obtenir des coûts de diffusion, une économie du réseau
contrairement à l?unicast et une indépendance vis-à-vis des FAIs.

Je parle bien sûr de la diffusion en direct. La VOD ne pouvant
qu?utiliser de l?unicast.

Je remarque par ailleurs que de plus en plus Youtube diffuse des
programmes en direct (utilise-t-il le multicast ou l?unicast ?)

Merci de vos avis/nouvelles/informations
Pascal Hambourg (17/12/2017, 21h36)
Le 17/12/2017 à 18:15, PP a écrit :
> Il semble que la migration vers le protocole IPv6 favoriserait le
> développement du multicast, et notamment pour la diffusion de la
> télévision via les réseaux IP. Hors où en sommes nous aujourd?hui ?


Je crains que nous en soyons toujours au même point qu'avant.

> Y a-t-il des blocages qui font qu?aujourd?hui les réseaux de chaînes de
> télévision ne se convertissent pas à cette technologie qui leur
> permettrait d?obtenir des coûts de diffusion, une économie du réseau
> contrairement à l?unicast et une indépendance vis-à-vis des FAIs.


Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
PP (17/12/2017, 23h03)
Le 17/12/2017 à 20:36, Pascal Hambourg a écrit :
> Le 17/12/2017 à 18:15, PP a écrit :
> Je crains que nous en soyons toujours au même point qu'avant.
> Le blocage, c'est que le multicast ne passe pas entre les opérateurs.


J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y
avait un problème avec le protocole multicast qui est en unidirectionnel
et sans répétition des paquets perdus.
Je trouve que techniquement l'excuse n'est pas recevable, car on sait
très faire aujourd'hui des flux TNT et satellite qui sont
unidirectionnels qui ne pixelisent pas (effet bloc). Il suffit
d'intégrer dans les données du flux des bits/octets de correction, avec
des répétitions de données dans des paquets différents émis à des
moments différents du flux (comme 400ms en TNT) ce qui permet de
corriger les parasites intermittents

Je pense qu'il y a surtout une grosse pression lobbyingstique de la part
des gros FAIs, pour qui le service TV fait actuellement la différence
entre eux.
Didier (18/12/2017, 19h56)
Le 17/12/2017 à 22:03, PP a écrit :
> Je pense qu'il y a surtout une grosse pression lobbyingstique de la part
> des gros FAIs, pour qui le service TV fait actuellement la différence
> entre eux.

Sans doute, mais je ne vois pas trop la différence entre les 200 chaines
de l'un et les 200 chaines de l'autre, commercialement parlant bien entendu.
Didier.
Pascal Hambourg (18/12/2017, 23h48)
Le 17/12/2017 à 22:03, PP a écrit :
> Le 17/12/2017 à 20:36, Pascal Hambourg a écrit :
> J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y
> avait un problème avec le protocole multicast qui est en unidirectionnel
> et sans répétition des paquets perdus.


Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
Le vrai problème, c'est le routage multicast lui-même.
PP (19/12/2017, 09h29)
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
> Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
> Le vrai problème, c'est le routage multicast lui-même.


Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
que cela soit bien lourd en terme de capacité pour les routeurs, non ?
Le trafic parait extrêmement réduit si on le compare au trafic youtube,
facebook ou mail par exemple.
Pascal Hambourg (20/12/2017, 22h51)
Le 19/12/2017 à 08:29, PP a écrit :
> Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
>> Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
>> Le vrai problème, c'est le routage multicast lui-même.

> Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
> que cela soit bien lourd en terme de capacité pour les routeurs, non ?
> Le trafic parait extrêmement réduit si on le compare au trafic youtube,
> facebook ou mail par exemple.


Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le
problème est la gestion du routage multicast lui-même. A ce jour, elle
n'existe pas entre les opérateurs.
PP (07/03/2018, 17h51)
Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :
> Le 19/12/2017 à 08:29, PP a écrit :
> Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le
> problème est la gestion du routage multicast lui-même. A ce jour, elle
> n'existe pas entre les opérateurs.


En effet, lorsque je cherche des informations au sujet du multicast,
j?ai l?impression d?un grand flou.
Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone.
Ne serait-ce que dans l?attribution des IP, il n?y a aucun renseignement.

J?ai découvert aussi des protocoles tel que rtp et rtsp qui permettent
de transmettre en UDP des flux video et audio et qui permettent de
ranger et de corriger les données. Cependant je n?ai rien trouvé à
propos de l?algorithme de correction et de la robutesse de celui-ci.
Pierre Léonard (02/09/2018, 11h26)
Bonjour à toutes et tous,

J'ai eu l?occasion pour mes études de travailler sur une application de
vidéoconférence en 1993, et eu l'occasion de voire une première
conférence en multicast dés 1991 sur le réseau de l'éducation et la
recherche RENATER IPV4 bien sur.
A cette époque un groupe d'ingénieur géraient le FMBONE comme un réseau
au dessus de RENATER avec ses propres routeurs mais utilisant RENATER
comme couche de transport.

Le 07/03/2018 à 16:51, PP a écrit :
> Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :


>> Le 19/12/2017 à 08:29, PP a écrit :
>>> Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
>>>> Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
>>>> Le vrai problème, c'est le routage multicast lui-même.

Dans la plus part des box, le routage multicast est bloqué à l'entrée et
à l'émission. Pourquoi ?, cela donnerai l'occasion à tout un chacun de
faire sa radio et sa télévision en multidifusion.

>>> Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
>>> que cela soit bien lourd en terme de capacité pour les routeurs, non ?
>>> Le trafic parait extrêmement réduit si on le compare au trafic youtube,
>>> facebook ou mail par exemple.

Excellente remarque. Que ce soit en ipv4 ou ipv6, la gestion du groupe
multicast et des abonnements à ces groupes est géré par le réseau. C'est
un travail supplémentaire mais qui est du même niveau que la recherche
d'une adresse IP. La différence vient ensuite lors de l'utilisation, les
routeurs ne gèrent plus des flux point à point mais des flux multipoints
Plus clairement lorsqu'un paquets multicast arrive sur un routeurs et
qu'il a des abonnés pour ce flux, il doit multiplier les envoient pour
chaque abonnés. Un abonné pouvant être : soit un utilisateur final, soit
un autre routeur multicast.

>> Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le
>> problème est la gestion du routage multicast lui-même. A ce jour, elle
>> n'existe pas entre les opérateurs.


A ce jour, il n'y a pas de peering multicast officiel entre les
opérateurs. puisque l'usage du multicast par les clients est interdit.

Quand au volume, les opérateurs réfléchissent actuellement à une
limitation du volume IP de leurs clients, comme nous l'avons tous sur
nos smartphones.
Raison : il y a certainement de l'argent à se faire sur le dos des
gourmands.

> En effet, lorsque je cherche des informations au sujet du multicast,
> j?ai l?impression d?un grand flou.
> Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone.
> Ne serait-ce que dans l?attribution des IP, il n?y a aucun renseignement.


l'attribution des adresses multicast a été pendant de longues année un
prés carré des USA, comme d'habitude pour tout ce qui touche l'Internet.
Je n'ai pas entendu dire que l'AFNIC pouvait réservée des adrsses
multicast, donc je doute que cela est changé. Le RFC3171 "IANA
Guidelines for IPv4 Multicast Address Assignments"

donne quelques indication sur la gestion des adresses multicast. Il faut
sans doute aussi fouiller toutes les références qui sont nommées.

> J?ai découvert aussi des protocoles tel que rtp et rtsp qui permettent
> de transmettre en UDP des flux video et audio et qui permettent de
> ranger et de corriger les données. Cependant je n?ai rien trouvé à
> propos de l?algorithme de correction et de la robutesse de celui-ci.


RTSP est un protocole de session. Le transport des données est ensuite
réalisé par RTP.
RTP travaille en UDP unicast ou multicast, il n'y a pas de récupération
de paquets perdus. C'est à l'application de gérer la façon dont elle
rempli les paquets avec ses données pour que ces pertes soient le moins
gênantes pour les utilisateurs.

J'ai travaillé de 1993 à 1997 sur les flux audios et vidéo H261, La
première proposition de mise en paquets des flux étaient mauvaise,
métaphoriquement les fluxs étaient découpés avec une simple paire de
ciseaux. J'ai proposé un mies em paquets prenant en compte la structure
des flux afin de limiter l'incidence des pertes.

Une explication de la méthode est décrite dans le document suivant :
[..]

Il y en a d'autre, les anglais ont proposé pour le son des outils vic et
vat, de mettre dans un paquet dédiée au flux audio, une première partie
du son à l'heure courante et une deuxième partie du son du paquet
précédent compressé, pour ne pas doubler la bande passante.

J'ai d'autre document en ligne, mais mon serveur est en panne. Je vais
les transférer sur mon site personnel.

Cordialement.
Pierre Léonard
Discussions similaires
Multicast IPv6

Le projet de loi sur la télévision du futur impose...

Loi sur la télévision du futur

Télévision numérique : futur


Fuseau horaire GMT +2. Il est actuellement 23h12. | Privacy Policy