On en parlait sur IRC, c'est n'importe quoi, plein d'incohérences techniques... Et baser tout ça sur Multicast : No comment....En ce qui me concerne, très instructif; et l'auteur n'est pas n'importe qui (https://fr.wikipedia.org/wiki/Benjamin_Bayart), non plus ! (https://lafibre.info/images/smileys/@GregLand/ca.gif)
J'ai toujours pense que la TV en P2P (qui induit malheureusement un certain décalage avec le direct) était une solution déjà viable et proposée.
C'est dommage de ne pas s'appuyer la dessus.
avec la neutralité du net (ou, a minima, avec ma définition de la neutralité du net)Le problème ne serait pas ici ? Chacun ayant sa définition...
Bon, le coeur du sujet me parait toujours dans l'erreur.Je rejoins Jack.
Je rejoins Jack.
(...)
Fonctionnement de la diffusion de la télévision linéaire en IP
Techniquement, la télévision linéaire est diffusée en multicast. C'est un cas intéressant, tout le monde voit le même flux, à la même seconde, la même image en même temps. L'idée est que, quel que soit le nombre de téléspectateurs, on ne va transporter les informations qu'une seule fois. Et pour obtenir cet effet, on utilise du multicast.
Le principe de l'unicast est simple : un serveur a le flux à sa disposition, chaque personne qui veut regarder demande à recevoir le flux, et ce flux lui est envoyé. Si 100 personnes veulent voir le flux, alors il est émis 100 fois depuis le serveur de départ, et transporté 100 fois sur le réseau. Sur le dernier brin du réseau, celui qui va chez moi, il n'est transporté qu'une fois (pour moi), sur les grands axes du réseau il est transporté plusieurs fois. Quand on regarde le direct d'une chaîne de télé sur son site web, c'est ce qui se produit. Si un million de personnes regardent en direct, il faut envoyer le flux un million de fois en simultané.
Le principe du multicast est radicalement différent. Le réseau sait que c'est un flux (de quoi, il s'en fiche, c'est un flux). Quand je veux regarder une chaîne donnée, mon décodeur télé envoie un message au routeur juste au-dessus dans le réseau disant "Je veux recevoir le flux de Télé Bocal". Si le routeur reçoit déjà le flux en question (mon voisin regarde déjà cette chaîne) alors il copie le flux vers moi et c'est fait. Sinon, il propage la demande au routeur suivant, jusqu'à remonter au serveur qui èmet le flux. L'effet sur le brin du réseau qui va chez moi est assez faible. On a mis en œuvre un protocole de routage plus complexe, mais il y a bien un seul exemplaire du flux qui arrive chez moi, comme avant, comme en unicast. En revanche, sur les grands axes du réseau, un seul exemplaire du flux est transporté. Cet exemplaire sera dupliqué à chaque point de connexion, pour aller vers les zones où quelqu'un regarde la chaîne, et seulement ces zones-là.
Du coup, en effet, si on remplace la diffusion de la télévision linéaire en multicast par des flux web en unicast, on crée un stress considérable sur le réseau, les grands axes du réseau se retrouvent avec le même flux en plusieurs millions d'exemplaires, au lieu d'un exemplaire unique. Mais... ce n'est pas la priorisation, ou un changement de priorisation, qui produit cet effet. Ce n'est pas de rendre prioritaire les flux des bouquets télé autres que celui de l'opérateur qui produit cet effet. Ce qui produit cet effet, c'est qu'on a changé de technologie. On est passé d'une diffusion multicast à une diffusion unicast.
Si on reste sur la même technologie, à savoir multicast... Mais, peut-on rester sur la même technologie ? Globalement, la réponse simple est oui. Oui. Un èmetteur de flux multicast est défini par une adresse IP et un numéro de port. Une seule adresse IP multicast peut donc èmettre des dizaines de milliers de flux différents. Et il existe des milliers millions d'adresses IP identifiées comme multicast. Et je ne parle là que d'IPv4, en IPv6, il y en a beaucoup plus. Pour le moment, entre les grands opérateurs d'Internet, les flux multicast ne sont pas routés. Sur les points d'échange, on ne fait pas passer ces flux là. Si on voulait le faire, on déstabiliserait ces points d'échange. Mais le concept de point d'interconnexion multicast entre deux réseaux est un concept raisonnable, qui ne demande pas des équipements nouveaux, mais simplement des équipements actuels et un effort de configuration.
À tel point que certains opérateurs, de petite taille, commencent à fournir ce type de plateforme d'interconnexion multicast, pour aider d'autres petits opérateurs à diffuser des flux de télévision. C'est donc faisable. Pas encore à grande échelle, mais uniquement parce que les grands acteurs du secteur ne veulent pas le faire.
DSM, Geoblocking
Quelle est donc la configuration du réseau que nous proposons, et quel serait son effet ?
Nous proposons qu'il y ait des points d'interconnexion multicast sur le réseau IP européen, comme il y a des points d'interconnexion pour les flux unicast. Certaines interconnexions sont payantes, d'autres sont gratuites, on pourrait fonctionner sur les mêmes bases. Chaque èmetteur de flux télé vient se connecter sur un de ces points (via son fournisseur d'accès à Internet) et dispose d'une adresse IP multicast. France Télévision a une de ces adresses, le groupe Canal+ aussi, Télé Bocal aussi, etc.
[...]
Notre idée d'un réseau multicast ouvert et public, routé comme il devrait l'être, permet de faire du marché de la télévision un vrai marché européen. Non pas qu'une chaîne de télévision en polonais ait une chance de prendre 40% des parts de marché en France, mais qu'un polonais qui est en séjour en France ait accès à des informations en polonais. Le citoyen européen qui se déplace en Europe peut prendre des nouvelles de chez lui. Il est un peu plus chez lui partout en Europe. Et il nous semble que tout ça a du sens.
[...]
Mais il y a plus, comme disent certains juristes. En effet le règlement européen indique clairement que l'utilisateur doit pouvoir fournir le service de son choix. Dans notre approche, c'est possible. Chacun peut avoir une adresse multicast s'il le souhaite, et donc se mettre à èmettre, depuis chez lui si la vitesse de son accès le permet, un flux de télévision. Et l'Europe entière pourrait regarder ce flux, sans que sa ligne soit plus chargée que d'habitude.
Le texte du règlement européen est très clair. Il ne dit pas qu'il doit y avoir plusieurs acteurs de marché dans le monde de la télévision. Il dit que chaque utilisateur final doit pouvoir proposer les services de son choix. La vision que nous proposons d'un réseau multicast ouvert, interconnecté, routé, pour le réseau de diffusion de la télévision linéaire est la seule qui permet ça.
Effets sur le réseau
Quand je prétends que sur le réseau c'est sans effet, et que tout est comme d'habitude, je néglige une optimisation classique. Les routeurs de cœur de réseau qui gèrent de grosses masses de flux multicast sont de grosses machines, mais les grosses machines n'aiment pas réfléchir. Si tout fluctue tout le temps, si à chaque abonné qui zappe le routage des flux est susceptible de changer, alors on crée des mouvements stochastiques. C'est le principe des flux de vent dans l'air. Souvent, ça ne fait rien. Des fois, ça fait un orage. Rarement ça fait une tempête ou un ouragan.
[...]
Mon analyse à moi, c'est qu'il n'y a qu'un seul Internet. Et que tous les FAIs fournissent un accès au même Internet. Et la proposition qui est faite ici est simplement de réintégrer dans ce réseau Internet unique les flux multicast que les opérateurs ont mis de côté.
Snickerss, la problématique de contenu unicast de masse est déjà une réalité. Si Youtube et Netflix y arrivent, d'autres acteurs avec une audience moindre devraient y arriver, non ?Audience moindre ? Au niveau global oui, mais au niveau de chaque FAI je pense que le débit TV (si elle était en unicast) resterait supérieur au débit Youtube / Netflix (surtout que les bitrates ne sont pas les mêmes).
En plus Youtube par exemple a beaucoup de serveurs de cache, ce qui est possible car la majorité de son contenu n'est pas une diffusion temps réel (ce qui permet également de lisser les variations de vitesse de transfert lors de la lecture, chose impossible en direct sans introduire de délai supplèmentaire).Live ou différé, c'est techniquement la même chose
Live ou différé, c'est techniquement la même choseSur Youtube ou Netflix, le buffer de lecture fait bien plus qu'une seconde.
Dans les deux cas, c'est des fichiers HTTP
Dans les deux cas, tu peux utiliser des proxy HTTP, et ce sans délai supplèmentaire (<1sec)
C'est la latence totale qui compte, je trouve que 10s c'est beaucoup, mais si c'est déjà le cas avec certains FAI... (je n'ai jamais personnellement vu autant, en comparant Free ou SFR par rapport à la TNT).J'ai déjà vu plus chez Free.
Après pour revenir au sujet, pour diffuser en unicast sans consommer trop de bande passante, il faudrait des caches locaux (NRO/NRA), ce qui dépendrait du FAI, et donc ce ne serait pas neutre (sauf à imposer la mise en place d'un cache universel, qui serait capable de traiter les flux de tous les fournisseurs sans discrimination).
Voici donc la liste des préfixes GGC déchiffrés pour SFR :
Préfixe chiffré Préfixe en clair Code AITA PoP probable Serveurs sn-n4g-jqb sfr-cdg Paris CDG SFR Netcenter Courbevoie (http://www.datacentermap.com/france/paris/neuf-courbevoie.html) 48 sn-n4g-ato sfr-lyn Lyon SFR Netcenter Vénissieux (http://www.datacentermap.com/france/lyon/neuf-vennissieux.html) 24 sn-n4g-cvq sfr-bod Bordeaux SFR Netcenter Bordeaux (http://www.datacentermap.com/france/bordeaux/neuf-bordeaux.html) 24 sn-n4g-uan sfr-tls Toulouse SFR Netcenter Toulouse (https://beta.peeringdb.com/fac/1131) 16 sn-n4g-gon sfr-rns Rennes SFR Netcenter Rennes (http://www.datacentermap.com/france/rennes/neuf-cesson-sevigne.html) 16 sn-n4g-apa sfr-lil Lille SFR Netcenter Lille (https://beta.peeringdb.com/fac/989) 8 sn-n4g-nmc sfr-sxb Strasbourg SFR Netcenter Strasbourg (http://www.datacentermap.com/france/strasbourg/neuf-strasbourg.html) 8 sn-n4g-g0o sfr-run Saint-Denis PoP La Réunion ? 3
Les fournisseurs d'accès à avoir des GGC en France sont SFR, Free, Numericable, Bouygues Telecom, Adista, Céleste, K-Net, Renater, Rézopole, Neo Telecoms actuellement et Orange précédemment.+ Marin à oublié le FAI Zeop (sur l'Île de La Réunion) qui as lui aussi un GGC.
On remarque que c'est aussi le cas pour Youtube ou Netflix, qui ont des caches hébergés sur les réseaux des FAI dans les grandes villes.Je pense qu'il y a moins d'abonnés qui regardent YouTube que la télé, et les bitrates ne sont pas les mêmes non plus.
On en parlait sur IRC, c'est n'importe quoi, plein d'incohérences techniques... Et baser tout ça sur Multicast : No comment.Allons donc. Une faute technique, que j'ai corrigé quand on me l'a signalée et qui n'altère pas le fond du raisonnement.
Je pense qu'il y a moins d'abonnés qui regardent YouTube que la télé, et les bitrates ne sont pas les mêmes non plus.Ce n'est pas la question. Le réseau est neutre quand deux services équivalents sont traités de manière équivalente. Point.
Allons donc. Une faute technique, que j'ai corrigé quand on me l'a signalée et qui n'altère pas le fond du raisonnement.
No comment étant un argument percutant, la messe est dite, je dois me tromper. Certainement.
Comme dit plus haut, de base je pense que le Multicast pour des flux type TV n'a aucun avenir
je pense que c'est le futur, et infiniment plus neutre que la solution du multicast (J'entends que tout le monde peut proposer sa chaine de TV en stream unicast aujourd'hui, et potentiellement toucher tout le monde).
Ben non justement, une fois le problème d'attribution des addresses de diffusion gérées
Et pour la tv en direct en unicast sur TCP avec la gestion d'erreur, ben au bout d'un moment si ça bufferise, soit tu perds des bouts soit c'est plus du direct.
Neutre, ça ne veut pas dire zéro filtrage (il y a le traitement des attaques, par exemple), et ça ne veut pas dire zéro priorisation.
C'est pareil, une fois le problème de la vitesse de la lumière réglé, on pourra se déplacer plus vite dans la galaxie.
(Serieux, c'est pas juste un petit problème pour le coup)
Si ça bufferise, c'est pas pour 50 raisons : saturation. C'est pas le Multicast qui va empécher ça ;D
Bah pour le coup, la non duplication des flux permet au moins modérer la saturation.
Dire que l'avenir est à l'unicast, c'est dire que l'avenir est aux GAFA : surement vrai dans les faits mais pas nécessairement souhaitable.
Unicast ne leur est pas réservé, de plus, entre un GAFA et un Drahi/Bouygues, je me demande ce qui est le pire...
Donc tu voudrais que chaque client aie une IP dédiée au Multicast et qu'il puisse diffuser ce qu'il veut avec ? Mwai, ça fait 2 réseaux à entretenir, j'adhère pas. Le réseau en Unicast a l'avantage d'être déjà présent.Je ne pense pas qu'il reste beaucoup de routeur ne supportant que l'unicast. Tous les protocoles et les équipements existent déjà, il ne manque que la volonté des les configurer correctement.
Unicast ne leur est pas réservé, de plus, entre un GAFA et un Drahi/Bouygues, je me demande ce qui est le pire...Non, ça ne leur ait pas réservé, mais ça a un coût assez dissuasif pour empêcher les petits acteurs de s'y lancer.
Certes, mais là n'est pas le débat, on parle de développer Multicast pour le rendre accessible /à tous/aux petits acteurs/ ;)ahh
Il n'y a aucune raison technique pour que le multicast ne soit pas implèmenté sur Internet, uniquement des raisons politiques (et surtout de l’incompétence).pas de raison techniques, ok
Je ne pense pas qu'il reste beaucoup de routeur ne supportant que l'unicast. Tous les protocoles et les équipements existent déjà, il ne manque que la volonté des les configurer correctement.Non, ça ne leur ait pas réservé, mais ça a un coût assez dissuasif pour empêcher les petits acteurs de s'y lancer.
ahh
haben ca c'est mort hein vous pouvez oublier :)
Et je m'avance, mais il me semble que les IPs multicast ne sont pas routables "globalement" comme les autres,Cela n'a aucun sens vu qu'une IP multicast (classe D) n'appartient à personne.
Et je m'avance, mais il me semble que les IPs multicast ne sont pas routables "globalement" comme les autres, dans le sens ou un AS n'a pas un bloc d'IPs multicast qu'il annonce au reste, ce qui rend le "partage" des flux compliqués, pour avoir discuté avec des professionnels, généralement, les "liens" entre les fournisseurs et les FAI se fait soit en Unicast avec conversion des deux cotés, soit avec un vrai controle des deux cotés vu que ça reste de l'UDP, donc aucun mécanisme de prévention de la congestion comme TCP/IP.mécanisme de prévention de la congestion? Qu'est-ce que tu me waconte la?
Cela n'a aucun sens vu qu'une IP multicast (classe D) n'appartient à personne.
mécanisme de prévention de la congestion? Qu'est-ce que tu me waconte la?
pour connaitre des fluxs multicast entre des réseaux (RFO/france télé/ groupe tf1/ dépot légal de l'INA), disons que c'est le merdier dans la vraie vie.
Il n'y a aucune raison technique pour que le multicast ne soit pas implèmenté sur Internet, uniquement des raisons politiques (et surtout de l’incompétence).
Cela n'a aucun sens vu qu'une IP multicast (classe D) n'appartient à personne.Et pourtant... http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
Donc, et de facto, il est impossible, aujourd'hui, de laisser des tiers être la source d'un flux multicast fiable.
En vla quelques unes, avec des mots clefs en gras, pour le travail du soir.Bah justement, la plupart des DDOS actuels utilisent UDP principalement parce que la plupart des opérateurs ne préviennent pas l'ip spoofing (incompétence ?). Pour autant que je sache, on ne s'interdit pas de l'utiliser sur Internet à cause de ça.
Des faits:
- aujourd'hui, beaucoup de réseau IP sont sensibles à l'IP spoofing (un emetteur envoie des paquets avec une autre IP que la sienne).
- le multicast est unidirectionnel
- l'adresse multicast ne permet pas d'identifier la source du flux. Le mode IGMP le plus utilisé est certainement ASM (any source multicast). Il est nécessaire, pour avoir une vague idée de la source, d'utiliser SSM (source specific multicast).
- SSM n'est valide que si tu préviens l'IP spoofing, ce qui n'est pas le cas aujourd'hui (cf les ddos)
Donc, et de facto, il est impossible, aujourd'hui, de laisser des tiers être la source d'un flux multicast fiable.
Je place la question de la vie privée de côté;
Et pourtant... http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtmlQue veux-tu dire?
En UDP, tu ne peux pas connaitre la taille d'un lien, donc si ça sature, ça droppe salement, jusqu'a ce que tu règle le souci à la main. En TCP, la négociation se fait toute seule, c'est pas vraiment de la prévention, mais c'est ce que j'entendaisTu ne peux jamais connaitre la taille du lien, juste constater qu'il y a des pertes de paquets.
Que veux-tu dire?De facto certaines adresses multicast ont déjà été attribuées (GLOP).
De facto certaines adresses multicast ont déjà été attribuées (GLOP).et donc sont utilisables sur l'Internet global?
Je ne comprends toujours pas en quoi consistent les adresses multicast attribuées.
En théorie oui
Quant au "sens de la discussion": j'ai un peu perdu le fil j'avoue...
Pour moi, le probleme est plutôt politique et pas technique
Il faut aussi penser que si en IPv4 on ne peut envisager (en pratique) autre chose qu'UDP et TCP, en IPv6 ce n'est pas le cas.Même avec les box qui font du filtrage par défaut en IPv6?
En IPv6 le multicast fonctionne différemment aussi, la QoS est simplifié et le chiffrement facilité.
Ce qui en IPv4 peut ne pas sembler réaliste ou praticable pourrait s’avérer tout a fait faisable avec IPv6.
Je crois qu'il pense qu'elles sont attribuées à l'IANA&Co.https://tools.ietf.org/rfc/rfc6034.txt
Ouais, enfin vu les arguments que tu avances "C'est juste un problème de [...]", alors que Jack et Matt' avancent des éléments factuels pour t'expliquer que ça ne tient pas, mon argumentation est au moins aussi qualitative.
Ouais, enfin vu les arguments que tu avances "C'est juste un problème de [...]", alors que Jack et Matt' avancent des éléments factuels pour t'expliquer que ça ne tient pas, mon argumentation est au moins aussi qualitative.De ce que j'en ai lu, il y a un argument de fiabilisation de la source qui est tout à fait recevable mais qui n'est pas en soi définitif. L'autre argument c'est j'ai piscine...
De ce que j'en ai lu, il y a un argument de fiabilisation de la source qui est tout à fait recevable mais qui n'est pas en soi définitif. L'autre argument c'est j'ai piscine...
l'autre te remercies ! mais l'autre a un métier où les flux doivent passer et où il est confronté à la vrai vie, pas à vos brassages de vents.Heu je disais bien l'autre argument hein, je ne me serais jamais permis parler de quiconque de cette façon.
On est sur un forum technique, non ? et puis :
https://lafibre.info/tv-numerique-hd-3d/le-multicast-et-la-telediffusion-par-un-reseau-neutre/msg340682/#msg340682 (https://lafibre.info/tv-numerique-hd-3d/le-multicast-et-la-telediffusion-par-un-reseau-neutre/msg340682/#msg340682) (Désolé, c'est impossible à citer) ;D
C'est un débat intéressant, la question n'est pas un problème technique, trouver des compétences qui sachent gérer de l'unicast et multicast, cela existe.Vraiment ?
... avec des belles pixelisations sur la TV
kgersen : Je suis d'accord avec toi sur ce point de vue, je ne me prononce que sur le point de vue technique, c'est celui qui me concerne le plus ^^
Vraiment ?Orange est, le moins que l'on puisse dire,une machine lourde.
Je me souviens d'une soirée mémorable, chez des gens qui étaient chez orange, avec des belles pixelisations sur la TV
C'est vrai que du coup, je me suis posé la question, ce jour là : pourquoi ? Est-ce qu'orange manque de moyen ? Est-ce qu'ils sont mauvais ? Ou autre chose ?
Carrèment trop pas, nan.Est-ce qu'on "route" du multicast, ou est-ce qu'on "arrose"? ;)
(router du multicast!!!!!!!=router de l'unicast, à pas mal de niveaux)
La technologie ADSL perd beaucoup de paquets.
99,9% sont renvoyés (sont avec la correction bas niveau DSL qui permet aux lignes de ne presque plus avoir de CRC) soit au niveau haut (FEC chez Orange qui occupe 20% du flux TV)
Maintenant quad tu as des perturbations importantes qui font perdre 50 paquets d'un coup, il n'y a rien à faire : cela va se répercuter sur l'écran (sauf si on est en TCP avec un buffer suffisamment grand, ce qui explique pourquoi la qualité Netflix/Youtube est supérieur à celle de la TV des FAI)
Genre... En TCP/Unicast ? Au hasard ::)
Usine à gaz sur usine à gaz over usine à gaz ?
Non pas du tout.
Il ne s'agit pas de corriger les paquets, il s'agit de corriger le signal !
prévoir des entrelacements de trames, des répétitions de partiel de signal décalé dans le temps à l'instar de ce qui se fait avec la TNT.
Je pense que l'idée d'utiliser le multicast pour de la diffusion TV est loin d'être stupide ou simplette.
Probablement qu'il y a des adaptations à faire.
Le lobby de France Telecom disait qu'il était impossible de faire de la phonie over IP il y a 20 ans, aujourd'hui quasiment l'intégralité de la phonie l'est.
Tu comprends de quoi on parle avec fec ?
Je pense qu'il faut aborder la problématique autrement qu'avec l'idée que l'intégralité de tous les paquets doit arriver à bon port. Il faut penser contenu.
Je pense qu'il faut que tu penses à autre chose où excercer tes talents.
Probablement qu'il y a des adaptations à faire.Ça fait 30 ans qu'on fait de la tv sur multicast, s'il y a des "adaptations à faire", elles sont faites depuis longtemps.
Le lobby de France Telecom disait qu'il était impossible de faire de la phonie over IP il y a 20 ans, aujourd'hui quasiment l'intégralité de la phonie l'est.
Rien n'empêche d'avoir une correction direct à la réception des paquets.Oui, un truc genre TCP
Mais manifestement avec ce procédé, le signal ne serait pas d'après vous suffisamment robuste pour un flux vidéo.Tu veux dire, d'après des années d'expériences.
en quoi ca fait avancer cette discussion de sortir de telle phrase ? tu cherches quoi ici ? un endroit pour te défouler sur les autres ou flatter ton ego ?
Je ne pense que la lafibre.info soit l'endroit pour cela.
Ça fait 30 ans qu'on fait de la tv sur multicast, s'il y a des "adaptations à faire", elles sont faites depuis longtemps.
Oui, un truc genre TCP
Tu veux dire, d'après des années d'expériences.
Et ben vas-y fais-lui toute l'histoire de DVB et de Mpeg system.vu les questions qu'il pose il n'a pas compris ce qui est disponible publiquement sur le net.
Je ne parle pas des ouvrages spécialisés que l'on trouve dans les librairies techniques.
Sinon il y a aussi de la formation de vidéo sur IP, j'ai des bons contacts.
Les technologies évoluent, les évidences d'il y a 25 ans n'ont plus lieu d'être à ce jour.
Quand vous parlez de faire des adaptations, j'ai surtout l'impression que vous vous arrêtez à des faits peut-être vrais il y a 30 ans, mais par contre, vous refusez toutes possibilités d'innovation.As-tu la moindre idée de la recherche effectuée par les opérateurs dans le domaine ? Les sommes énormes qui sont allouées à ce sujet ?
En TNT, régulièrement des trames sont perdus non corrigeables et pourtant le streaming fonctionne très bien, car le signal vidéo est robuste avec des entrelacements de trame, des répétitions partielles qui permet de récupérer les choses en temps réel.Non c'est faux : il suffit d'avoir des perturbations et le résultat est catastrophique.
Je ne vois pas en quoi cette vision des choses ne seraient pas possibleC'est possible, et y'a même un nom: TCP.
As-tu la moindre idée de la recherche effectuée par les opérateurs dans le domaine ? Les sommes énormes qui sont allouées à ce sujet ?
Visiblement pas.
Fait preuve d'un peu de respect.
Non c'est faux : il suffit d'avoir des perturbations et le résultat est catastrophique.
C'est possible, et y'a même un nom: TCP.
Le FEC, c'est justement rendre robuste le flux multicast.
Cela augmente de 20% la taille du flux et permet une correction de la plupart des pertes de paquets rencontrées.
C'est utilisé par Orange et Bouygues Telecom.
TCP est par contre plus performant pour la correction que le FEC.
Le FEC, c'est justement rendre robuste le flux multicast.
Cela augmente de 20% la taille du flux et permet une correction de la plupart des pertes de paquets rencontrées.
C'est utilisé par Orange et Bouygues Telecom.
TCP est par contre plus performant pour la correction que le FEC.
Le FEC est là pour corriger les erreurs dans la transmission des trames.
Cependant si la trame est non récupérable, elle est tout simplement perdu en multicast.
Le TCP permet de faire répéter la trame perdue, mais cela demande trop de temps, et cette technologie n'est pas adaptée temps réel sauf à utiliser des buffers pour laisser le temps de récupérer une trame qui manque, et à condition d'avoir un lien qui n'est pas limite en débit.
Pour assurer un flux sans trop d'erreur, il faut augmenter la robustesse, par des répétitions partielles de flux afin de pouvoir corriger les erreurs qui ne sont pas récupérable par les autres FEC.
Certes le flux est certainement plus important (50-100%), mais parfaitement robuste est fiable.
Manifestement on ne parle pas du même niveau de couche du signal …
Lorsque que vous dîtes que le signal TNT est catastrophique dès qu'il y a la moindre perturbation je ne suis pas d'accord.
L'exemple des jours d'orage est un bon exemple.
Malgré les sommes énormes dépensées par les opérateurs telecom, la TV ne fonctionne pas bien dès qu'il y a une petite perturbation malgré les corrections FEC des trames. Parce qu'il n'y a pas d'entrelacement par exemple, et qu'on s'obstine à vouloir avoir une transmission parfaite du streaming. Voilà l'erreur ! Le temps s'accomode mal de cette technologie.
Lorsqu'on fait du streaming à la TNT/DAB, il y a des tas de combinaison possible de transmission du signal vidéo dans des trames. Le décodage du signal vidéo avec les trames arrivées intactes ou récupérer permet d'avoir un signal sans erreur. Chez moi la TNT passe parfaitement les jours d'orage sans effet de bloc alors qu'en ADSL c'est tout simplement inregardable et pourtant avec un lien à 11Mbit/s le reseau pourrait me renvoyer les trames 3 fois, mais ça ne marche pas, car le TCP est mal adapté au temps réel, sauf à avoir des buffers de 30s comme fait Youtube par exemple.
Chez moi la TNT passe parfaitement les jours d'orage sans effet de bloc alors qu'en ADSL c'est tout simplement inregardable et pourtant avec un lien à 11Mbit/s le reseau pourrait me renvoyer les trames 3 fois
car le TCP est mal adapté au temps réel, sauf à avoir des buffers de 30s comme fait Youtube par exemple.Dommage que tu répondes à coté de la plaque.
Alors une piste pour que tu nous lâches : Mpeg System
Tu mélanges tout et ça ne t'aide pas à être crédible :
1) Le support physique n'est pas le même donc les mécanismes de contrôle et de correction d'erreur ne sont pas les même
2) L'entrelacement est un artefact qui n'a aucun intérêt en terme de correction d'erreur en numérique.
3) Pour illustrer le point 2) : les têtes de réseaux IPTV d'Orange, Free, Bouygues et SFR diffusent en entrelacé. C'est globalement plutôt historique que pour toutes autre raisons.
4) Si tu estimes que les corrections d'erreurs/ les transmissions sont ultra robustes en Satellite et en TNT, je t'invite à venir visiter la salle de supervision d'un broadcasteur un soir d'orages, tu verras que les solutions miracles en terme de diffusion/corrections d'erreurs n'existent pas.
Alors non, l'encodage n'a rien à voir la dedans
c'est la technologie DAB/TNT
https://en.wikipedia.org/wiki/Digital_audio_broadcasting
Error-correction coding
PS : Je ne comprend pas cette agressivité
Mais ne le fait pas, puisque c'est de l'UDP/Multicast et pas du TCP/Unicast.
Dommage que tu répondes à coté de la plaque.
Ce n'est (toujours) pas du TCP.
Et faire du flux TCP en temps réel, ça se fait. Très bien même.
En ADSL la TV (chez free) n'est pas en UDP entre le NRA et ma box !Si si.
Et oui du flux temps réel en TCP est possible, sauf qu'en cas de grosses perturbations le réseau explose, que si le lien est trop petit ça ne passe pas longtemps, qu'il faut un cache important pour laisser du temps au routeur de répéter les trames perdues. Mais ça marche nous sommes d'accord
En 2017 (presque 2018), les routeurs, les liens... etc. Sont bien dimensionnés pour ça (ou du moins, le cout d'un upgrade n'est pas prohibitif). La clé c'est d'avoir beaucoup de serveurs de cache locaux :)
En 2017 (presque 2018), les routeurs, les liens... etc. Sont bien dimensionnés pour ça (ou du moins, le cout d'un upgrade n'est pas prohibitif). La clé c'est d'avoir beaucoup de serveurs de cache locaux :)
Alors non, l'encodage n'a rien à voir la dedans
c'est la technologie DAB/TNT
https://en.wikipedia.org/wiki/Digital_audio_broadcasting
Error-correction coding
PS : Je ne comprend pas cette agressivité
System, ce n'est pas l'encodage !
Tu confonds la base de la base avec Mpeg audio/ vidéo d'un côté et System de l'autre
Ah évidemment que tu ne pourrais pas tout passer en Unicast du jour au lendemain, mais c’est quelque chose qui est du domaine du possible 😊
Du domaine du possible, certainement certains grostelcos semblent l'avoir déjà étudié sérieusement, mais personne n'a franchit le pas, l’intérêt technico-economique semblerait plutôt difficile à trouver à court et moyen terme.Bof, la "nouvelle" infra pop-ng d'orange est orientée sur ce genre de design :)
Du domaine du possible, certainement certains grostelcos semblent l'avoir déjà étudié sérieusement, mais personne n'a franchit le pas, l’intérêt technico-economique semblerait plutôt difficile à trouver à court et moyen terme.
Le FEC est là pour corriger les erreurs dans la transmission des trames.
Cependant si la trame est non récupérable, elle est tout simplement perdu en multicast.
[...]
Pour assurer un flux sans trop d'erreur, il faut augmenter la robustesse, par des répétitions partielles de flux afin de pouvoir corriger les erreurs qui ne sont pas récupérable par les autres FEC.
en quoi ca fait avancer cette discussion de sortir de telle phrase ? tu cherches quoi ici ? un endroit pour te défouler sur les autres ou flatter ton ego ?
Je ne pense que la lafibre.info soit l'endroit pour cela.
Ben alors, une journée plus tard, il raconte autant de conneries et il n'y comprend toujours rigoureusement rien
Où sont les démonstrations brillantes ? J'avais sorti, mon calepin et un beau stylo pour prendre des notes et rien....
En tout cas, je ne vois pas avec tout cela, ce qui empêcherait d'espérer avoir les chaîne par exemple de la TNT en flux libre Multicast comme en parlait M BAYART.
La propriété intellectuelle / le juridique ?
La loi ?
Il n'y a aucune loi qui l'interdit, par contre, certainement qu'il y a des droits d'auteur qui demande des trucs pour cloisonner les marchés pour rentabiliser leurs productions.
Par contre, certainement qu'il faudrait une loi pour rendre les droits d'auteurs justement pour au moins l'Europe entière.
Mais oui....
Il n'y a aucune loi qui l'interdit, par contre, certainement qu'il y a des droits d'auteur qui demande des trucs pour cloisonner les marchés pour rentabiliser leurs productions.Faux.
Par contre, certainement qu'il faudrait une loi pour rendre les droits d'auteurs justement pour au moins l'Europe entière.
Petite question innocente pipantal : Tu bosse dans le domaine de la diffusion TV ?
Faux.
Diffuser le contenu d'un tiers sans son consentement (généralement écrit), c'est de la contrefaçon. Et c'est un coup à se retrouver au tribunal, j'en sais qq chose.
Je pense tout de même qu'il y a en tout logique des affirmations surprenantes comme l'impossibilité de faire du multicast sérieusement à travers internet alors que le réseau se débrouille pas si mal avec les milliards de flux Youtube par exemple. Donc je pense que quelques milliers de flux multicast devrait y trouver leur place son problème.
L'utilisation du multicast se base sur le postulat suivant : la perte de paquet n'a aucun impact.
Hors, en video, la perte de paquet EST problématique.
Donc, le multicast n'est pas adapté à la video.
Des entreprises payent des sommes énormes (je pense qu'on peut parler de milliards, depuis le temps) pour "faire en sorte que ça fonctionne malgré tout". Le prix de la bande passante en interne, en 2017, permet de ne plus s'astreindre et d'utiliser un système fonctionnel et conçu pour les services sensible à la perte de paquet : TCP.
TCP est fait pour des services comme la video, end of story.
Donc, le multicast n'est pas adapté à la video.
Tu es peut-être un peu excessif dans ton affirmation.Non :)
Non :)
Ils payent des sommes hallucinantes pour avoir un service qui est médiocre : il suffit de voir des artéfacts sur la tv orange pour se dire qu'apparement, orange n'a pas les moyens / n'a pas mis encore assez de moyen pour que cela fonctionne.
Surement.
Non :)Tu n'arriveras pas à me convaincre. :)
Les sources ne sont pas toujours impeccables et les encodeurs ne sont pas infaillibles. Le réseau n'est pas toujours le seul à incriminer. Le multicast sur un réseau bien dimensionné fonctionne. Les paquets ne se perdent pas par magie.
Quand aux sommes allucinantes, je ne suis pas convaincu qu'une autre techno soit fondamentalement moins chère.
il suffit de voir des artéfacts sur la tv orangeJ'ai de la chance alors, je passe plusieurs heures d'affilée devant la TV d'Orange le WE, et des artefacts si j'en vois 2 fois par jour c'est le bout du monde. J'en avais clairement plus quand j'étais en réception satellite...
J'ai de la chance alors, je passe plusieurs heures d'affilée devant la TV d'Orange le WE, et des artefacts si j'en vois 2 fois par jour c'est le bout du monde. J'en avais clairement plus quand j'étais en réception satellite...
On est bien d'accord, seulment le muticast utilisé par les FAI est pas comparable avec ce des liaisons dédiés pour alimenter des emeteurs TNT ou autre, tu traveverse plusieurs routers, pas toujours bien paramètré, ou on paye pas la bande passante qu'il faut, et le resultat est la, tu te ramasse toute les aléas du reseau.
K-Net etait au début en UDP, c'etait franchement degeulasse, ensuite en TCP, c'est nettment mieux, mais c'est pas encore la qualité/stabilité de ce que tu as sur le SAT ou la TNT, et meme quand je regarde les repay de Canal en OTT, ben navré, mais les soirs de foot ca pixellise.
Peux etre leur seveurs saturé, le reseau qui bouchonne, mais ca me gonfle de regarder un truc avec des frezze et une roue qui tourne pendent 2 seconde toutes les 10 minutes....
J'ai de la chance alors, je passe plusieurs heures d'affilée devant la TV d'Orange le WE, et des artefacts si j'en vois 2 fois par jour c'est le bout du monde. J'en avais clairement plus quand j'étais en réception satellite...
Alors Orange est un FAI serieux qui je supose met plus de moyens pour avoir une TV de qualité, K-Net depend du reseau du SIEA et et ca peux etre une raison que ca passe moins bien.
L'utilisation du multicast se base sur le postulat suivant : la perte de paquet n'a aucun impact. Hors, en video, la perte de paquet EST problématique. Donc, le multicast n'est pas adapté à la video.En même temps et pourtant, la TV numérique en broadcast (en DVB notamment) ça fait plus de 20 ans que ça tourne, donc un medium (de type "ether") avec pertes et perturbations ça marche quand même pas si mal dans ce cadre, apparemment (et le DVB a été conçu en ce sens).
Alors Orange est un FAI serieux qui je supose met plus de moyens pour avoir une TV de qualitéOui enfin attention car parfois plus c'est gros plus c'est lourd et rien de plus, c'est pas forcèment synonyme de meilleures solutions.
En même temps et pourtant, la TV numérique en broadcast (en DVB notamment) ça fait plus de 20 ans que ça tourne, donc un medium (de type "ether") avec pertes et perturbations ça marche quand même pas si mal dans ce cadre, apparemment (et le DVB a été conçu en ce sens).
Donc utiliser du multicast pour du live en lieu et place du broadcast (vu que ce n'est plus un "ether" mais une série de liens) ne parait pas déconnant dès lors que le codage et l'environnement sont adaptés (avec de la QoS, et avec du FEC et/ou avec retransmission de paquets perdus en unicast).