La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: vivien le 06 août 2019 à 21:51:34
-
TF1 popularise le peer-to-peer directement dans un navigateur web
Vous êtes adapte des replays, live ou autres vidéos du groupe TF1 ?
Sans le savoir vous faites du peer-to-peer !
Le site MyTF1 le cache bien (je n'ai rien vu dans les Conditions Générales d'Utilisation des Services MYTF1 - MYTF1VOD - TFOUMAX (https://www.tf1.fr/conditions-generales-utilisation), mais il y a bien du peer-to-peer sur ces sites.
TF1 utilise la technologie de la société française Streamroot ( https://streamroot.io/ )
Ils utilisent un flux UDP pour envoyer les paquets entre les clients en peer-to-peer, directement depuis le navigateur web, sans besoin d'une application ou d'un plug-in à installer.
Les flux sont chiffrés, ce n'est pas de https, car on est en UDP, mais c'est du DTLSv1.2 (https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security) (Datagram Transport Layer Security).
Un brevet a été déposé par Streamroot en avril 2015 par Nikolay Rodionov (Co-Founder & COO) et Axel Delmas :
PROCEDE DE LECTURE EN CONTINU SUR UN EQUIPEMENT CLIENT D'UN CONTENU DIFFUSE AU SEIN D'UN RESEAU PAIR A PAIR
La présente invention concerne un procédé de lecture en continu sur un équipement client (11) d'un contenu diffusé au sein d'un réseau pair à pair (10) d'équipements clients (11, 12), ledit contenu étant constitué d'une séquence de segments, l'équipement client (11) comprenant une première mémoire tampon (M1) stockant de façon temporaire au moins un segment brut dudit contenu, chaque segment brut étant dans un format adapté pour le transfert au sein du réseau pair-à-pair (10), le procédé étant caractérisé en ce qu'il comprend la mise en œuvre par des moyens de traitement de données (110) de l'équipement (11) d'étapes de : (a) Conversion dans un format adapté pour la lecture sur l'équipement (11) d'au moins un segment brut de la première mémoire tampon (M1), et stockage dudit segment converti dans une deuxième mémoire tampon (M2) de l'équipement (11), de sorte que la deuxième mémoire tampon (M2) stocke un nombre compris entre un nombre minimal et un nombre maximal de segments convertis disposés en amont d'un point de lecture dudit contenu ; (b) Lecture depuis la deuxième mémoire tampon (M2) d'au moins un fragment du segment converti disposé au niveau dudit point de lecture ; (c) Suppression de ladite deuxième mémoire tampon (M2) d'au moins un segment converti disposé en aval dudit point de lecture, de sorte que la deuxième mémoire tampon (M2) stocke un nombre inférieur ou égal à un nombre maximal de segments convertis disposés en aval d'un point de lecture dudit contenu, le segment brut associé étant conservé temporairement dans la première mémoire tampon (M1).
(https://lafibre.info/images/tv/201504_streamroot_pair_a_pair.png)
Explication de la diffusion vidéo peer-to-peer par Streamroot : (traduction à gauche et l'original en anglais à droite - cliquez sur les miniatures ci-dessous - les documents sont au format PDF)
(https://lafibre.info/images/tv/201912_streamroot_livraison_video_peer-to-peer_expliquee.webp) (https://lafibre.info/images/tv/201912_streamroot_livraison_video_peer-to-peer_expliquee.pdf) (https://lafibre.info/images/tv/201912_streamroot_peer-to-peer_video_delivery_explained.webp) (https://lafibre.info/images/tv/201912_streamroot_peer-to-peer_video_delivery_explained.pdf)
-
Cas pratique : Visualisation du flux live de TF1
Sur cette capture, réalisée avec une connexion câble 100 Mb/s down et 5 Mb/s d'upload, j'ai reçu le flux en direct de TF1, mais ma connexions est utilisée en upload pour envoyer le flux à d'autres clients.
A noter l'absence de publicité pour regarder le live de TF1.
En vert le trafic reçu en TCP, sur une connexion https
En rouge le trafic émis en UDP, en peer-to-peer
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_0.png)
La capture wireshark (34 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
201908_tf1_live_sans_pub.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub.pcapng.gz)
Il est intéressant de regarder toutes les connexions nécessaires.
J'ai listées ci-dessous les différente connexions. L’utilisation de Streamroot ne fait aucun doute: on se connecte en https à cdn.streamroot.io
tcp.stream eq 0 : t=0,0 prod-player.tf1.fr 24 ko
tcp.stream eq 1 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 2 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 3 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 4 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 5 : t=0,1 cdn.streamroot.io 5 ko
tcp.stream eq 6 : t=0,1 player.tf1.fr 8 ko
tcp.stream eq 7 : t=0,1 nqs.nice264.com 6 ko
tcp.stream eq 8 : t=0,1 static.adsafeprotected.com 6 ko
tcp.stream eq 9 : t=0,1 das-q1-ssl.tf1.fr 4 ko
tcp.stream eq 10: t=0,1 www.googletagmanager.com 31 ko
tcp.stream eq 11: t=0,5 player.tf1.fr 11 ko
tcp.stream eq 12: t=0,7 www.google-analytics.com 25 ko
tcp.stream eq 13: t=0,8 7b9de.v.fwmrm.net 16 ko
tcp.stream eq 14: t=0,8 strmt.tf1.fr 14 ko
tcp.stream eq 15: t=0,8 strmt.tf1.fr 4 ko
tcp.stream eq 16: t=0,8 compte.tf1.fr 7 ko
tcp.stream eq 17: t=0,8 nqs.nice264.com 7 ko
tcp.stream eq 18: t=0,8 tf1-das-live-ssl.tf1.fr 18 ko
tcp.stream eq 19: t=0,9 connect.facebook.net 7 ko
tcp.stream eq 20: t=0,9 tf1-das-live-ssl.tf1.fr 3 ko
tcp.stream eq 21: t=0,9 tf1-das-live-ssl.tf1.fr 28 Mo
tcp.stream eq 22: t=0,9 tf1-das-live-ssl.tf1.fr 4 ko
tcp.stream eq 23: t=0,9 connect.facebook.net 4 ko
tcp.stream eq 24: t=1,0 static.adsafeprotected.com 13 ko
tcp.stream eq 25: t=1,3 staticxx.facebook.com 4 ko
tcp.stream eq 26: t=1,3 www.facebook.com 6 ko
tcp.stream eq 27: t=1,5 pythagore.demdex.net 24 ko
tcp.stream eq 28: t=1,6 w.usabilla.com 18 ko
tcp.stream eq 29: t=1,7 logs1169.xiti.com 5 ko
tcp.stream eq 30: t=1,7 prof.estat.com 6 ko
tcp.stream eq 31: t=1,7 ads.stickyadstv.com 5 ko
tcp.stream eq 32: t=1,7 ads.stickyadstv.com 6 ko
tcp.stream eq 33: t=1,9 143.204.222.221 0 ko
tcp.stream eq 34: t=2,1 auth.estat.com 7 ko
tcp.stream eq 35: t=2,8 infinity-c9.youboranqs01.com 9 ko
tcp.stream eq 36: t=2,8 infinity-c9.youboranqs01.com 7 ko
tcp.stream eq 37: t=2,9 infinity-c9.youboranqs01.com 7 ko
tcp.stream eq 38: t=2,9 dpm.demdex.net 6 ko
tcp.stream eq 39: t=2,9 sentry.io 24 ko
tcp.stream eq 40: t=3,2 logs1169.xiti.com 5 ko
tcp.stream eq 41: t=3,4 mesure.streaming.estat.com 11 ko
tcp.stream eq 42: t=11 infinity-c9.youboranqs01.com 13 ko
tcp.stream eq 43: t=29 tf1-das-live-ssl.tf1.fr 198 ko
tcp.stream eq 44: t=31 incoming.telemetry.mozilla.org 12 ko
tcp.stream eq 45: t=31 incoming.telemetry.mozilla.org 5 ko
tcp.stream eq 46: t=31 strmt.tf1.fr 18 ko
tcp.stream eq 47: t=62 logs1169.xiti.com 8 ko
Le flux source est envoyé par TF1 depuis tf1-das-live-ssl.tf1.fr , sur la connexion 21, qui fait 28 Mo alors que les autres font quelques ko :
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_9.png)
-
Voici un premier exemple concret: je partage mon flux avec ce client de la DSP Rennes Metropole Telecom
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_1.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_2.png)
-
Partage du flux avec un client Orange ADSL situé en Île-de-France :
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_3.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_4.png)
-
Partage du flux avec un client SFR ADSL :
On remarque que plusieurs paquets sont dédoublés, alors que l’intervalle de temps est très court. Je me demande bien pourquoi.
Exemple: 50ms entre les deux "Client Hello", ce temps sans réponse serait suffisant pour déclencher un renvoi ?
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_7.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_8.png)
-
Cas pratique : Visualisation d'un replay TF1
Sur cette capture, toujours avec une connexion SFR câble 100 Mb/s down et 5 Mb/s d'upload, j'ai reçu le flux au tout début de TF1 et ensuite ce sont des internautes du monde entier (USA, Japon, Espagne,...) qui prennent le relais. Par contre je ne partage rien.
A noter la présence d'une publicité de 30 secondes qui n'utilise pas le peer-to-peer.
En vert le trafic reçu en TCP, sur une connexion https
En rouge le trafic émis en UDP, en peer-to-peer
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_0.png)
La capture wireshark (61 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
201908_tf1_replay_avec_pub.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub.pcapng.gz)
Il est intéressant de regarder toutes les connexions nécessaires : 84 connexions rien que pour la vidéo (j'ai exclut les connexions pour le site web de TF1 que l'on lance avant la vidéo)
Ici aussi, on se connecte en https à cdn.streamroot.io
tcp.stream eq 0 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 1 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 2 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 3 : t=0,0 prod-player.tf1.fr 24 ko
tcp.stream eq 4 : t=0,0 prod-player.tf1.fr 5 ko
tcp.stream eq 5 : t=0,0 api.ipify.org 7 ko
tcp.stream eq 6 : t=0,1 nqs.nice264.com 6 ko
tcp.stream eq 7 : t=0,1 static.adsafeprotected.com 6 ko
tcp.stream eq 8 : t=0,1 player.tf1.fr 5 ko
tcp.stream eq 9 : t=0,2 cdn.streamroot.io 5 ko
tcp.stream eq 10: t=0,2 das-q1-ssl.tf1.fr 4 ko
tcp.stream eq 11: t=0,2 www.googletagmanager.com 32 ko
tcp.stream eq 12: t=0,5 player.tf1.fr 9 ko
tcp.stream eq 13: t=0,6 ws.facil-iti.com 6 ko
tcp.stream eq 14: t=0,9 das-q1-ssl.tf1.fr 28 Mo
tcp.stream eq 15: t=0,9 static-player.tf1.fr 63 ko
tcp.stream eq 16: t=0,9 7b9de.v.fwmrm.net 30 ko
tcp.stream eq 17: t=0,9 strmt.tf1.fr 15 ko
tcp.stream eq 18: t=0,9 strmt.tf1.fr 4 ko
tcp.stream eq 19: t=0,9 www.google-analytics.com 26 ko
tcp.stream eq 20: t=0,9 nqs.nice264.com 7 ko
tcp.stream eq 21: t=1,0 compte.tf1.fr 7 ko
tcp.stream eq 22: t=1,0 das-q1-ssl.tf1.fr 977 ko
tcp.stream eq 23: t=1,0 das-q1-ssl.tf1.fr 3 ko
tcp.stream eq 24: t=1,0 das-q1-ssl.tf1.fr 1 ko
tcp.stream eq 25: t=1,2 179.60.192.7 0 ko
tcp.stream eq 26: t=1,2 connect.facebook.net 7 ko
tcp.stream eq 27: t=1,3 static.adsafeprotected.com 14 ko
tcp.stream eq 28: t=1,6 www.facebook.com 6 ko
tcp.stream eq 29: t=2,3 cdn.tagcommander.com 5 ko
tcp.stream eq 30: t=2,4 pythagore.demdex.net 25 ko
tcp.stream eq 31: t=2,5 logs1169.xiti.com 6 ko
tcp.stream eq 32: t=2,5 52.47.44.247 0 ko
tcp.stream eq 33: t=2,8 w.usabilla.com 18 ko
tcp.stream eq 34: t=2,8 ads.stickyadstv.com 5 ko
tcp.stream eq 35: t=2,8 ads.stickyadstv.com 8 ko
tcp.stream eq 36: t=3,0 143.204.222.221 0 ko
tcp.stream eq 37: t=3,5 7b9de.v.fwmrm.net 1 ko
tcp.stream eq 38: t=3,5 infinity-c9.youboranqs01.com 9 ko
tcp.stream eq 39: t=3,5 infinity-c9.youboranqs01.com 7 ko
tcp.stream eq 40: t=3,5 infinity-c9.youboranqs01.com 7 ko
tcp.stream eq 41: t=3,5 infinity-c9.youboranqs01.com 8 ko
tcp.stream eq 42: t=3,5 infinity-c9.youboranqs01.com 8 ko
tcp.stream eq 43: t=3,6 vast.adsafeprotected.com 17 ko
tcp.stream eq 44: t=3,8 pixel.adsafeprotected.com 214 ko
tcp.stream eq 45: t=3,8 vpaid2.adsafeprotected.com 27 ko
tcp.stream eq 46: t=4,1 dt.adsafeprotected.com 18 ko
tcp.stream eq 47: t=4,1 vastpixel2.adsafeprotected.com 14 ko
tcp.stream eq 48: t=4,1 imasdk.googleapis.com 112 ko
tcp.stream eq 49: t=4,1 dt.adsafeprotected.com 16 ko
tcp.stream eq 50: t=4,2 dt.adsafeprotected.com 21 ko
tcp.stream eq 51: t=4,3 pagead2.googlesyndication.com 14 ko
tcp.stream eq 52: t=4,3 pagead2.googlesyndication.com 4 ko
tcp.stream eq 53: t=4,4 s0.2mdn.net 16 ko
tcp.stream eq 54: t=4,4 adservice.google.com 6 ko
tcp.stream eq 55: t=4,6 vastpixel2.adsafeprotected.com 9 ko
tcp.stream eq 56: t=4,7 csi.gstatic.com 6 ko
tcp.stream eq 57: t=4,7 gcdn.2mdn.net 6 ko
tcp.stream eq 58: t=4,8 vendorlist.consensu.org 7 ko
tcp.stream eq 59: t=4,8 r1---sn-25ge7nlz.c.2mdn.net 2 ko
tcp.stream eq 60: t=5,0 ade.googlesyndication.com 18 ko
tcp.stream eq 61: t=5,0 ade.googlesyndication.com 3 ko
tcp.stream eq 62: t=5,1 logs1169.xiti.com 5 ko
tcp.stream eq 63: t=5,1 216.58.204.129 0 ko
tcp.stream eq 64: t=5,1 ads.stickyadstv.com 6 ko
tcp.stream eq 65: t=5,1 dpm.demdex.net 8 ko
tcp.stream eq 66: t=5,1 vastpixel2.adsafeprotected.com 6 ko
tcp.stream eq 67: t=5,1 googleads4.g.doubleclick.net 3 ko
tcp.stream eq 68: t=5,1 sentry.io 59 ko
tcp.stream eq 69: t=5,3 1f2e7.v.fwmrm.net 6 ko
tcp.stream eq 70: t=5,3 cm.g.doubleclick.net 3 ko
tcp.stream eq 71: t=12 incoming.telemetry.mozilla.org 11 ko
tcp.stream eq 72: t=12 incoming.telemetry.mozilla.org 5 ko
tcp.stream eq 73: t=17 dt.adsafeprotected.com 6 ko
tcp.stream eq 74: t=17 infinity-c9.youboranqs01.com 2 ko
tcp.stream eq 75: t=17 7b9de.v.fwmrm.net 1 ko
tcp.stream eq 76: t=17 infinity-c9.youboranqs01.com 2 ko
tcp.stream eq 77: t=17 logs1169.xiti.com 5 ko
tcp.stream eq 78: t=17 auth.estat.com 7 ko
tcp.stream eq 79: t=17 logs1169.xiti.com 5 ko
tcp.stream eq 80: t=17 mesure.streaming.estat.com 12 ko
tcp.stream eq 81: t=31 strmt.tf1.fr 15 ko
tcp.stream eq 82: t=33 infinity-c9.youboranqs01.com 2 ko
tcp.stream eq 83: t=63 infinity-c9.youboranqs01.com 2 ko
tcp.stream eq 84: t=77 logs1169.xiti.com 5 ko
Le flux source est envoyé par TF1 depuis das-q1-ssl.tf1.fr (et non comme avant tf1-das-live-ssl.tf1.fr), sur la connexion 14, qui fait 28 Mo alors que les autres font quelques ko :
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_9.png)
-
Flux Vod envoyé par un client Espagnol (connexion Orange dans la région de Barcelone) :
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_1.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_2.png)
-
Flux Vod envoyé par un client Américain (connexion Cox Communications dans la région d'Atlanta) :
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_3.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_4.png)
-
Flux Vod envoyé par un client Bouygues Telecom (peut-être une connexion 4G vu la plage IP) :
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_5.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_6.png)
-
Flux Vod envoyé par un client Japonais, client de NTT :
Initialisation de la connexion :
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_7.png)
Transfert de données : (192.168.0.20, c'est l'IP de mon PC sur mon réseau local)
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_8.png)
-
Voila,
Rien de grave, mais je ne comprends pas que TF1 n'informe pas plus le consommateur, surtout quand il regarde la TV en 4G et que cela va lui coûter deux fois pus de données, si il est choisit pour partager les flux qu'il reçois.
Je trouve aussi étonnant que les connexions pochent ne soient pas privilégiées et que sur les 5 clients qui m'envoient du flux pour regarder ma VoD, j'ai 4 pays différents : USA, Japon, Espagne, France 4G, France ADSL)
-
Tu as vérifié que c'était le cas en 4G ? :)
-
Tu as vérifié que c'était le cas en 4G ? :)
Le traceroute de 176.159.47.111 est assez étrange car il ne montre aucun BSR.
On va sur Nanterre, le routeur cœur CBR01-NTR, mais ensuite on n'a pas d'information, probablement un reverse DNS pas mis à jour, car un routeur CBR n'est connecté qu'a des routeur RPT (Routeur Peering Transit) ou des BSR où sont connectés les collectes des clients aussi bien fixe que mobile.
La plage IP est taguée AS12844, donc plus mobile, mais je n'ai pas de certitude.
Maintenant ce système de peer-to-peer doit bien avoir du mal à séparer les technologies d’accès.
-
Via un point d'accès, possible. Mais sinon il me semble facile via l'application mobile de séparer.
(et c'est - je crois - la réponse qui m'avait été faite quand j'avais soulevé la même question que toi)
-
Hello !
Ça dévie un poil du sujet, mais j'ai remarqué un comportement similaire sur mycanal, version pour navigateur PC, sur une chaine TV live : de nombreux flux sortants vers des adresses des grands FAI, qui apparaissent une quinzaine de secondes après le début de la lecture. Je me demande si on en n'avait pas parlé dans un autre topic, mais je n'ai rien retrouvé ;D
-
On avait évoqué la techno Streamroot ici (https://lafibre.info/netalis/france-uruguay-vu-dun-noc-operateur-b2b/) et là (https://lafibre.info/coriolis-entreprise/coriolis-traffic-pendant-le-match-france-uruguay/) mais c'était aussi pour TF1.
-
Salut,
Le mot-clé qui manque, c'est que la technologie utilisée est WebRTC.
WebRTC commence en effet à être utilisé pour la répartition de charge des fournisseurs de contenus commerciaux et c'est tout à fait prévisible (considérant que la technologie est suffisamment mature, disposer de la possibilité de réduire ses coûts de fonctionnement en partageant les ressources de connexion des utilisateurs, du moment qu'elles sont suffisantes, n'est que bon à prendre pour une entreprise privée).
Cette entreprise « Streamroot » propose peut-être sa solution, mais la plus répandue aujourd'hui pour faire ça se nomme PeerTube (qui utilise elle-même la bibliothèque JavaScript WebTorrent, qui est une ré-implèmentation du protocole BitTorrent sur WebRTC).
DTLS n'est que la couche la plus basse de la pile WebRTC utilisée en mode partage de données brutes (data channel), à l'intérieur il y a du SCTP.
Voici un premier exemple concret: je partage mon flux avec ce client de la DSP Rennes Metropole Telecom
Il s'agit plus probablement d'un client Neufbox sur un accès non-câble situé dans le département de l'Ille-et-Vilaine (historiquement, dès lors que le dégroupage d'un département s'est fait en utilisant des fibres fournies par une DSP qu'il gérait, SFR a choisi d'utiliser des AS dédiés enregistrés avec le nom de la DSP pour les clients situés dans le département concerné).
-
Tu as vérifié que c'était le cas en 4G ? :)
Normalement, WebRTC peut utiliser deux méthodes successives pour contourner les NAT ; une fois avoir obtenu les adresses IP publiques et privées de chaque utilisateur en utilisant le protocole STUN, il les échange en utilisant un canal auxiliaire comme une suite de requêtes HTTP ou un échange Websocket, puis essaie soit :
- de simuler une connexion UDP factice du côté de chaque pair en utilisant la technique nommée UDP hole punching, qui consiste à envoyer de chaque côté des paquets UDP vers des ports dynamiques déterminés à l'avance, afin de tromper la table de routage temporaire du NAT : chaque client doit faire croire à son NAT qu'il parle à un socket serveur situé de l'autre côté, alors qu'il parle en fait à un socket client (sachant qu'UDP ne permet pas de faire la distinction). S'il y a une translation dynamique du port source, alors cette technique n'a pas toutes les chances de marcher ;
- si ça ne marche pas, il va utiliser par défaut à 100 % un proxy public (Mozilla et Google en fournissent, mais il est possible d'en configurer d'autres dynamiquement) à travers le protocole nommé TURN.
On peut penser qu'on tombera probablement sur du TURN si on est en présence d'un CG-NAT, et que la bibliothèque utilisée est peut-être configurée pour éviter d'èmettre des flux pair-à-pair lorsque le TURN est utilisé. On peut aussi présumer que si elle est bien faîte, elle effectuera des tests de bande passante basique avant d'utiliser le flux montant de l'utilisateur (l'upload d'une une ligne ADSL2+ est facilement saturé, elle préférera sûrement les flux VDSL2 ou fibre) et la possibilité d'un filtrage par plage d'adresse n'est pas à exclure non plus. Tous ces points sont à vérifier.
Skype, l'un des logiciels ayant disposé dans le passé d'un mécanisme de répartition des flux pair-à-pair les plus répandus, effectuait de nombreux tests sur la solidité des connexions avant de choisir d'utiliser un PC comme nœud pour partager la charge de ses flux, et seules les connexions les plus solides (en général d'entreprise) étaient sélectionnées. En dehors de ces vérifications, WebRTC reprend de nombreux points de fonctionnement de l'ancien protocole de Skype.
-
Hello !
Ça dévie un poil du sujet, mais j'ai remarqué un comportement similaire sur mycanal, version pour navigateur PC, sur une chaine TV live : de nombreux flux sortants vers des adresses des grands FAI, qui apparaissent une quinzaine de secondes après le début de la lecture. Je me demande si on en n'avait pas parlé dans un autre topic, mais je n'ai rien retrouvé ;D
Bonjour ,
J'ai effectivement l'impression que MyCanal version PC fonctionne comme TF1, étant sur une connexion adsl chez free j'ai environ 15 Mbps et j'ai souvent des hausses de ping et des pertes de paquet comme si j'utilisais mon upload au max alors évidemment avec 1 Mbps en upload tu satures vite ...
De souvenir dans les réglages My Canal la bande passante utilisé pour regarder Canal+ du moins est d'environ 3-4 Mbps , merci de me confirmer si je raconte pas de bêtise :)
-
C'est bizarre qu'il y est des clients hors France, car normalement c'est bloqué non ?
-
France Télévisions utilise aussi Streamroot depuis quelques temps: https://blog.streamroot.io/french-public-broadcaster-france-televisions-chooses-streamroot-as-its-peer-to-peer-video-cdn-provider/ (https://blog.streamroot.io/french-public-broadcaster-france-televisions-chooses-streamroot-as-its-peer-to-peer-video-cdn-provider/) et https://www.francetelevisions.fr/lab/start-ups/streamroot (https://www.francetelevisions.fr/lab/start-ups/streamroot)
Je trouve que globalement, que ce soit sur TF1 ou france.tv ça fonctionne plutôt bien.
Concernant l'utilisation en 4G, dans le cas d'une connexion d'un PC via un partage de connexion Sosh, ça cramait effectivement pas mal de data à envoyer des trames UDP aussi. Une des spécificités du système étant que sur une durée un peu longue, on èmet environ 2 ou 3 fois plus de données qu'on en reçoit, ce qui se voit vite sur un forfait.
-
Ca fait plaisir. C’est quand même un peu l’idée de base d’internet d’arriver à décentraliser ;D
MyCANAL qui plantait des qu’un gros match était à l’affiche, c’était vraiment pénible. Et on a beau avoir des architectures scalables suivant la charge, cela a du sens de décentraliser les ressources.
-
Tu as vérifié que c'était le cas en 4G ? :)
Test réalisé depuis la 4G SFR : J'ai mis mon mobile (Samsung Galaxy s8) en partage de connexion et la capture est prise sur mon PC portable avec Ubuntu 19.04 comme OS et Firefox 68 en navigateur.
TF1 Live : (Je n'ai gardé que le flux peet-to-peer upload)
La capture wireshark (40 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
201908_tf1_live_sans_pub_4g.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_4g.pcapng.gz)
Listes des IP vers lesquelles j’envoie le trafic :
- 165.169.115.233 Zeop île de la réunion
- 176.133.189.47 Bouygues
- 176.139.90.183 Bouygues
- 46.193.0.134 Wifirst
- 80.119.193.177 SFR
- 88.139.245.116 SFR
- 88.168.176.216 Free
- 90.45.6.11 Orange
- 90.49.36.210 Orange
Replay TF1 : (Je n'ai gardé que le flux peet-to-peer upload)
La capture wireshark (7 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
201908_tf1_replay_avec_pub_4g.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_4g.pcapng.gz)
Listes des IP vers lesquelles j’envoie le trafic :
- 176.188.156.255 Bouygues
- 80.215.64.149 Bouygues
- 89.88.239.137 Bouygues
- 90.120.163.38 Orange
- 92.129.216.50 Orange
- 92.184.96.85 Orange
-
Ca fait plaisir. C’est quand même un peu l’idée de base d’internet d’arriver à décentraliser ;D
c'est mieux quand on est que client.......................
-
Je trouve que globalement, que ce soit sur TF1 ou france.tv ça fonctionne plutôt bien.
la moitié du temps je dois faire F5 pour lire unevidéo.... maintenant je sais pourquoi...................
-
On peut penser qu'on tombera probablement sur du TURN si on est en présence d'un CG-NAT, et que la bibliothèque utilisée est peut-être configurée pour éviter d'èmettre des flux pair-à-pair lorsque le TURN est utilisé.
Les réglages de Firefox : https://wiki.mozilla.org/Media/WebRTC/Privacy
On peut positionner media.peerconnection.ice.relay_only pour forcer le passage par un serveur TURN, et voir ce qui se passe.
La partie RTCPeerConnection de WebRTC, contrairement à getUserMedia (accès au micro et à la webcam), ne fait malheureusement pas partie des fonctionnalités pour lesquelles les navigateurs demandent la permission à l'utilisateur.
Même si c'est une bonne chose pour le fonctionnement des réseaux, l'utilisateur devrait être informé de l'usage de son upload, ne serait-ce que pour tous les abonnés ADSL ou 4G fixe (quota).
En plus, si myCanal le fait, je trouve ça limite : les abonnés payent pour avoir accès au flux, c'est au service de se dimensionner correctement pour tenir la charge.
-
Les réglages de Firefox : https://wiki.mozilla.org/Media/WebRTC/Privacy
On peut positionner media.peerconnection.ice.relay_only pour forcer le passage par un serveur TURN, et voir ce qui se passe.
La partie RTCPeerConnection de WebRTC, contrairement à getUserMedia (accès au micro et à la webcam), ne fait malheureusement pas partie des fonctionnalités pour lesquelles les navigateurs demandent la permission à l'utilisateur.
Même si c'est une bonne chose pour le fonctionnement des réseaux, l'utilisateur devrait être informé de l'usage de son upload, ne serait-ce que pour tous les abonnés ADSL ou 4G fixe (quota).
En plus, si myCanal le fait, je trouve ça limite : les abonnés payent pour avoir accès au flux, c'est au service de se dimensionner correctement pour tenir la charge.
Je pense qu'on est dans une phase où ces solutions ne sont pas encore complètement matures : il y a 5 ans, les normes sortent des marmites du W3C pour arriver doucement dans les celles des navigateurs, la technologie est encore un peu confidentielle, peu de temps après, les premières start-ups commencent à investir le marché et se font probablement lever des fonds auprès des investisseurs, un petit écosystème se forme (il y a visiblement eu des petites « WebRTC conference » à Paris avec quelques sociétés en 2014 en 2015), elles engrangent petit à petit des partenaires commerciaux, là on arrive au stade où la technologie commence à être déployée en masse et avoir un impact sur les réseaux mais n'est pas tout à fait stable, puisque l'impact sur le ressenti, l'expérience utilisateur et le bufferbloat n'a pas encore été mesuré. On va peut-être le fixer pour dans deux ou trois ans max :)
Il y a aussi une occupation importante pour le mot-clé « peer-to-peer CDN » sur Google. En effet, lorsque je lance un flux sur le site de France Télévisions avec Firefox, je vois passer des communications avec les serveurs de la même société.
-
Même si c'est une bonne chose pour le fonctionnement des réseaux, l'utilisateur devrait être informé de l'usage de son upload, ne serait-ce que pour tous les abonnés ADSL ou 4G fixe (quota).
Je frolais les 100GB/mois en 4G maintenant je dois prévoir un autre forfait en plus ou alors l'illimité Week-end de BoT
va être ma seule option si cela continue....
Quand on voyait que windows se permettait de faire sa MAJ de Windows 7/8 vers Windows 10 de 2 à 6GB quand il le voulait, il avait flingué des forfaits 4G en mode modem en moins de 24 heures..........
-
Je frolais les 100GB/mois en 4G maintenant je dois prévoir un autre forfait en plus ou alors l'illimité Week-end de BoT
va être ma seule option si cela continue....
Quand on voyait que windows se permettait de faire sa MAJ de Windows 7/8 vers Windows 10 de 2 à 6GB quand il le voulait, il avait flingué des forfaits 4G en mode modem en moins de 24 heures..........
Il me semble que ça n'existait pas à l'époque, mais dans Windows 10 on peut définir une connexion comme limitée, et dans ce cas les mises à jour ne seront pas téléchargées automatiquement.
Côté navigateurs, il existe une spécification expérimentale de navigator.connection (cf l'exemple https://googlechrome.github.io/samples/network-information/), mais le support hors mobile est très limité (uniquement Chrome, et à priori sans le champ "type", uniquement le débit descendant et la latence estimés).
-
Ce que fait Molotov TV :
Une seule connexion TCP ouverte, transfert des flux depuis Akamai en http/2
(https://lafibre.info/images/wireshark/201908_molotov_tv.png)
Ce que fait OCS pour les flux Live :
6 connexions TCP ouvertes, le transfert n'utilise qu'une seule connexion TCP et se fait depuis Akamai en http/2
(https://lafibre.info/images/wireshark/201908_ocs_live.png)
Ce que fait OCS pour les flux de replay :
6 connexions TCP ouvertes, le transfert n'utilise qu'une seule connexion TCP et se fait depuis Akamai en http/2
(https://lafibre.info/images/wireshark/201908_ocs_replay.png)
-
Ce que fait SFR Play : (concurrent de Netflix)
4 connexions TCP ouvertes, le transfert n'utilise qu'une seule connexion TCP et se fait depuis SFR en http/2 - Note capture réalisée depuis une connexion SFR.
(https://lafibre.info/images/wireshark/201908_sfr_play.png)
Ce que fait TF1 pour les flux Live pour alimenter le P2P :
plusieurs connexions TCP ouvertes, le transfert n'utilise qu'une seule connexion TCP et se fait depuis TF1 en http/2.
(https://lafibre.info/images/wireshark/201908_tf1_live_sans_pub_9.png)
Ce que fait TF1 pour les flux replay pour alimenter le P2P :
plusieurs connexions TCP ouvertes, le transfert n'utilise qu'une seule connexion TCP et se fait depuis TF1 en http/2.
(https://lafibre.info/images/wireshark/201908_tf1_replay_avec_pub_9.png)
-
Dsolé vivien je ne comprends pas.... X connexions ouvertes OK mais en up ou down ? y'a du trafic ?
-
Peut être que les autres sessions TCP servent à gérer la signalisation relative au client qui zappe ?
-
A priori plusieurs services de vidéo ouvrent plusieurs connexions, au cas où une se bloque.
Quand tout se passe bien (mon cas) une seule connexion est utilisée, mais les autres sont prêtes à prendre le relais, TLS 1.2 est monté.
Il faudrait faire des tests en connexion dégradée pour voir leur usage.
-
6play :
Il y a du peer-to-peer, mais je n'ai pas été choisit par envoyer un flux significatif de paquets malgré de nombreuses tentatives.
Le flux qui m'est envoyé provient par contre bien d'autres peer. Des clients FTTH ?
Ma connexion câble a un upload limité à 5 Mb/s.
Par contre il me semble que vers certains peer, je reçois et j'envoie aussi (probablement des paquets différents) alors que sur TF1 j'ai des peer vers lesquels j'envoie un flux et d'autres (ip différente) d'où je reçois le flux.
La capture wireshark d'une IP (5,6 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
201908_6play_replay.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/201908_6play_replay.pcapng.gz)
Trafic réseau d'un replay (Zone interdite) avec le blocage de contenu de Firefox activé : (comportement par défaut)
(https://lafibre.info/images/wireshark/201908_6lay_avec_blocage_firefox.png)
Trafic réseau d'un replay (Zone interdite) - le blocage de contenu de Firefox est désactivé manuellement :
(https://lafibre.info/images/wireshark/201908_6lay_sans_blocage_firefox.png)
Le blocage de contenu de Firefox est activé par défaut avec Firefox 68 et il bloque :
- Traqueurs : le pistage se rapporte généralement aux contenus, cookies et scripts qui peuvent collecter vos données de navigation sur de nombreux sites. Firefox bloque les traqueurs dans les fenêtres de navigation privée par défaut. Sélectionnez les boutons radio Strict ou Personnalisé pour bloquer les traqueurs connus dans toutes les fenêtres.
- Cookies tiers : ce sont des cookies traqueurs placés par un site web différent de celui que vous êtes en train de visiter. Les annonceurs utilisent le plus souvent les cookies tiers pour vous pister sur de nombreux sites et cibler les publicités. Firefox va bloquer bientôt les cookies tiers traqueurs pour tout le monde par défaut. Nous déployons graduellement ces protections à tous les utilisateurs.
- Mineurs de cryptomonnaies : les scripts mineurs de cryptomonnaies utilisent l’unité centrale du microprocesseur (CPU) de votre ordinateur pour miner des cryptomonnaies à votre insu. Ces scripts ralentissent votre ordinateur et vident votre batterie. Bloquez les mineurs de cryptomonnaies en cochant le bouton radio Strict.
- Détecteurs d’empreinte numérique : les scripts détecteurs d’empreinte numérique collectent des informations sur votre navigateur et la configuration de votre appareil, comme le système d’exploitation, la résolution de l’écran et d’autres paramètres. En compilant ces bribes de données, ces détecteurs créent un profil unique qui vous identifie, l’empreinte numérique, et qui peut être utilisée pour vous pister de site en site. Les empreintes numériques violent la politique contre le pistage de Firefox. Bloquez les détecteurs d’empreinte numérique en cochant le bouton radio Strict.
-
Trafic réseau de TF1 live : (blocage de contenu de Firefox activé)
L'upload est en moyenne à 2 Mb/s, avec des pics à 4 Mb/s. Ma connexion câble a un upload limité à 5 Mb/s.
(https://lafibre.info/images/wireshark/201908_tf1_live.png)
Trafic réseau de France TV live : (blocage de contenu de Firefox activé)
Oui, France TV aussi utilise du peer-to-peer.
France TV sature systématiquement ma connexion en upload en chargeant au maximum possible. Ma connexion câble a un upload limité à 5 Mb/s, il est possible de faire un petit peu plus comme vous le voyez.
(https://lafibre.info/images/wireshark/201908_pluzz_live.png)
-
J'ai fais des tests en FTTH : La quantités de données émise augmente !
L’utilisation CPU est également très importante (tests réalisés sur un Intel Core i3-6100 @3.70GHz)
Vous pouvez-voir un débit descendant très important : TF1 envoi bien plus que les données nécessaires.
Si je mets sur pause la vidéo, le flux descendant (et bien sur celui montant) continue : Je pense que TF1 utilise le fait que j'ai une connexion avec un débit montant important pour me faire partager d'autres contenus.
Replay TF1 :
(https://lafibre.info/images/wireshark/201908_tf1_replay_ftth.png)
-
FranceTV Live (France 3) :
(https://lafibre.info/images/wireshark/201908_pluzz_live_ftth.png)
-
Replay 6play :
(https://lafibre.info/images/wireshark/201908_6lay_replay_ftth.png)
-
Molotov TV Live :
Pas de peer-to-peer et utilisation CPU bien plus faible
(https://lafibre.info/images/wireshark/201908_molotov-tv_live_ftth.png)
-
Si je mets sur pause la vidéo, le flux descendant (et bien sur celui montant) continue : Je pense que TF1 utilise le fait que j'ai une connexion avec un débit montant important pour me faire partager d'autres contenus.
On pourrait même voir t'envoyer X fois le flux de différentes sources pour être sür que tu reçois bien le signal....
et inversement.
-
J'ai eu une pointe à 36mbits sur FranceTV Live (France 3).
Il faudrait que je réessaye à une heure de grande affluence, sans traitement en fond sur le CPU, pour voir à combien ça pourrais monter.
-
Ca commence à m'énerver ces histoires... bientot ca sera du paywall "partagez XX megaoctects en P2P d'un contenu populaire de notre plateforme vidéo pour pouvoir visionner ce reportage paru dans le 13h de TF1"
-
Je pense que TF1 utilise le fait que j'ai une connexion avec un débit montant important pour me faire partager d'autres contenus.[/size]
Nous devrions au contraire nous féliciter que les opérateurs de CDN utilisent -à bon escient- ces techniques de P2P via les clients, et en complèment (notamment en heure de pointe) de leurs flux streamés... ce qui fait sens au plan de l'économie des réseaux, grâce à l'abondance désormais du débit remontant du client ;)
-
et si ca flingue ton forfait 4G ?
-
et si ca flingue ton forfait 4G ?
je n'en ai pas la preuve, mais il est tenu compte du terminal et de sa puissance (ex : jamais sur un Chromecast(c), qui ne tiendrait pas le choc). Ajoutons la logique évidente de ne pas se mettre le client final à dos. La cible est donc le terminal vu comme "proche" (au sens réseau, donc en Fibre essentiellement) qui sait efficacement renvoyer ses chunks locaux & temporaires vers son voisinage Wan.
-
Cela fait sens si c'est fait sur les PC connectés au secteur, vu que cela entraîne une surconsommation d'énergie, et que les IP proches (même AS) sont priorisées.
Les problématiques sont :
- Utilisation de ressources rare radio en 4G
- Utilisation de batterie supplèmentaire
- Ne pas faire trop de trajet au niveau réseau (je pense aux flux vers les USA et le japon de mes premières captures)
Les gains sont :
- Économies de serveurs
- Utilisation de la bande passante upload, peu utilisée habituellement
- Résilience potentiellement plus forte mais pas nécessairement (le diable se cache dans les détails)
-
ce qui fait sens au plan de l'économie des réseaux
Je pense que c'est plus une économie du côté du diffuseur, pour le dimentionnement du réseau des FAI, ça ne doit pas représenter grand chose par rapport à Netflix et YouTube (et dans une moindre mesure Amazon, Facebook, ...).
-
certes... aujourd'hui quelques % en heure de pointe sur le live de forte audience !
* gain dimensionnement FAI à suivre au fur et à mesure de l'effacement des technos multicast au profit de la généralisation du live streamé...
* mais par ailleurs, le développement de l'usage live en start-over (comme proposé par l'excellent MyCanal) vient en réduire la pertinence, les chunks devenant moins "partageables" en simultané... :P
-
Pour l'instant ce sont certaines chaînes qui utilisent ce système, pas les FAI.
On verra si ces derniers changent les solutions utilisées sur leur box TV (et avec quelle stabilité), pour du direct ça me semble difficile d'assurer un temps de zapping faible sans recourir au serveur au début (et si beaucoup de monde change de chaîne au lancement de la pub, il faut encaisser...).
-
Pour le direct géré par les FAIs il y a un qcq intérêt ? Ce serait contre productif je pense.
-
Si le flux est tout IP, le P2P reste toujours avantageux pour le FAI........ après je sais plus quelles technologies que les FAI proposent pour les flux TNT....
-
Bah justement les flux gérés par les FAIs c'est du multicast... D'où mon doute sur la pertinence du P2P dans ce cas.
-
willemijns devait parler des replay, qui sont en unicast.
Le peer-to-peer fonctionne sur le live comme sur les replay.
Ce flux, c'est un replay de TF1 (j'ai pris une vidéo populaire, mis en avant sur la page, de mémoire une série) :
(https://lafibre.info/images/wireshark/201908_tf1_replay_ftth.png)
Ce flux sur M6, c'est aussi un replay, en l’occurrence Zone interdite :
(https://lafibre.info/images/wireshark/201908_6lay_replay_ftth.png)
J'imagine que le peer-to-peer fonctionne moins bien sur les vidéo avec peu d'audiences.
-
willemijns devait parler des replay, qui sont en unicast.
Je parlais des flux principaux lisibles directement depuis les box...
-
Donc le multicast ? Quel serait l'intérêt du P2P ?
-
Sur les flux live, le plus économique c'est le Multicast, en injectant 5 Gb/s de trafic sur le réseau, tu couvres toutes les chaînes quel que soit le nombre de clients.
Pour comparer, en Unicast, le trafic demandé par Netflix le soir s’approche de 1 Tb/s et je ne serais pas étonné que pour Orange il le dépasse même.
-
Donc le multicast ? Quel serait l'intérêt du P2P ?
Aucun... car je savais pas si les 4 opérateurs etait en IP ou multicast....
-
Les flux FAI lineaires ne sont pas en multicast jusqu'au DSLAM et ensuite unicast sur la boucle locale ?
-
Aucun... car je savais pas si les 4 opérateurs etait en IP ou multicast....
Pourquoi différencier l'IP du multicast ?
-
Les flux FAI lineaires ne sont pas en multicast jusqu'au DSLAM et ensuite unicast sur la boucle locale ?
C'est la définition même de l'unicast vs Multicast ... (si tu considères que l'unicast c'est l'émission vers 1 seul client). Mais bon c'est le DSLAM qui "fait suivre" le flux de la chaîne vers le client.
Le vrai Unicast, c'est du replay, un flux dédié du serveur jusqu'au client final.
-
C'est la définition même de l'unicast vs Multicast ... (si tu considères que l'unicast c'est l'émission vers 1 seul client).
Pour moi la différence entre unicast vs multicast c'est l'@IP du destinataire dans le paquet (@IP individuelle ou de groupe).
-
Les flux FAI lineaires ne sont pas en multicast jusqu'au DSLAM et ensuite unicast sur la boucle locale ?
Transformer en unicast, non, ça coûte trop cher.
Par contre, restreindre le flux multicast et l'ouvrir à la demande, oui. Le DSLAM ou l'OLT fait office d'IGMP proxy et ouvre la chaine à la demande pour y balancer uniquement le flux désiré quand il est demandé.
-
Pourquoi différencier l'IP du multicast ?
Quand je dis en IP cela signifie le mode transfert en IP alias IPTV (http://mafreebox.freebox.fr/freeboxtv/playlist.m3u)
comme le font même actuellement netflix ou autres replays TV (objet de ce sujet)
De mémoire en 2006, il y a avais ces 2 technologies (IPTV et multicast) entre orange, SFR et free. Maintenant je ne sais plus qui utilise quoi...
-
Tu cherches à différencier 2 choses qui ne le sont pas en fait. Ça t'embrouille je crois.
La playlist Free, c'est du multicast qui la pousse.
Et en 2006 (ainsi qu'aujourd'hui) les flux live des BOFS c'est du multicast.
-
Tu cherches à différencier 2 choses qui ne le sont pas en fait. Ça t'embrouille je crois.
Exact, je ne sais pas le protocole proposé dans les M3U FREE. Dont acte.
-
Chez Free le multicast s’arrête au DSLAM ou à l'IAD (je ne sais pas lequel de deux), quand on regarde les flux entre la box TV et le modem routeur, ce sont des flux unicast.
Chez les autres opérateurs, ce sont bien des flux multicast jusqu'à la box TV, avec la problématique quand il y a un switch non managable devant la box TV : les flux multicast sont ennoyés sur tous les ports du switch et si un PC est en 10 Mb/s sur ce switch (cas des PC éteints qui attendent un paquet Wake on LAN) alors il y a une forte probabilité que le switch limite le flux multicast à 10 Mb/s, ce qui pose problème pour la 4k et les flux HD+.
-
Exact, je ne sais pas le protocole proposé dans les M3U FREE. Dont acte.
Le sujet ce n'est pas le protocole (IP dans tous les cas) mais le mode de diffusion : IP cible unicast ou IP cible multicast.
-
Et l'essentiel, ça reste qu'en utilisant du multicast, l'intérêt du P2P est très discutable pour la TV linéaire.
Par contre quand tu n'es pas en capacité de faire du multicast (Canal+, Molotov), ça prend tout son sens pour écouler une partie du trafic.
-
Qu'est-ce qui explique que Netflix ne s'y intéresse à priori pas ?
-
Ils ont 100% de délinéarisé ?
-
Qu'est-ce qui explique que Netflix ne s'y intéresse à priori pas ?
Hypothèses :
1) Netflix utilise des flux chiffrés en utilisant l'API CDM HTML5 (qui demande notamment de communiquer avec la trustzone des processeurs Intel), sauf pour la SD. Je ne sais pas si leurs mécanismes de distribution actuels se conjuguent à 100 % avec une distribution en peer-to-peer, si des flux seront partagés, ce seront des flux chiffrés.
2) Comme semblent en témoigner les messages ci-dessus, il semble que les technologies actuellement sur le marché aient parfois tendance à saturer les connexions utilisateur dans le sens montant, ce qui peut causer des problèmes de congestion liés au bufferbloat (hausse de la latence) et/ou aux règles QoS sur certains réseaux.
On peut penser qu'ils s'y intéressent à l'avenir, notamment pour les grosses séries/sorties.
-
Ils ont 100% de délinéarisé ?
Effectivement mais je demande à quel point il n'y a pas quand même un grand nombre d'abonnés qui regardent le même contenu à peu près en même temps.
-
1) Netflix utilise des flux chiffrés en utilisant l'API CDM HTML5 (qui demande notamment de communiquer avec la trustzone des processeurs Intel), sauf pour la SD. Je ne sais pas si leurs mécanismes de distribution actuels se conjuguent à 100 % avec une distribution en peer-to-peer, si des flux seront partagés, ce seront des flux chiffrés.
Les segments sont chiffrés, mais identiques pour tout le monde (à qualité identique bien sûr), sans ça il ne serait pas possible d'utiliser des serveurs de cache, donc ils pourraient être partagés.
Il est même probable que le même segment puisse être décodé par Playready (3.0 pour les flux 4K sur PC, et sur certaines STB) et Widevine (L3 pour les flux 720p/1080p sur PC, L1 pour les flux 4K sur Android, ...), il y a déjà assez de variantes comme ça (différents bitrates, H264/HEVC/VP9).
Ils ont des serveurs de cache chez les FAI, donc je ne sais pas si alléger la charge via du P2P est réellement intéressant.
C'est probablement moins fiable que les serveurs (et un peu plus compliqué pour gérer le basculement entre les différentes qualités), tant que le réseau du FAI tient le coup.
Effectivement mais je demande à quel point il n'y a pas quand même un grand nombre d'abonnés qui regardent le même contenu à peu près en même temps.
Sur PC, il serait effectivement possible de stocker un certain temps les segments déjà récupérés, et donc les envoyer à quelqu'un qui regarde le même contenu, même s'il y a plusieurs minutes de décalage.
-
Bonjour ,
Il y a t-il une solution du coup pour contourner ? car effectivement sur My Canal la qualité est bonne mais mon ping monte.
Etant en adsl mon upload sature rapidement .
-
Quand je vois STUN sur les captures Wireshark, je vomis bien comme il faut quand même :)
WebRTC désactivé chez moi depuis longtemps, sur tous les navigateurs.
Je trouve que c'est trop bavard et que l'utilisateur final manque de contrôle sur ce type de protocole (par exemple, si j'ai pas envie d'uploader, parce que je me fais facturer l'envoi , ou parce que je veux le router différement , je n'ai aucun contrôle sur ca).
-
[EDIT] message de Vivien en réponse à cette capture :
-
- 232.0.4.2 => IP muticast, c'est donc du flux multicast de la chaîne live
- Flux UDP sur le port 53 => DNS
- Flux UDP sur le port 443 => Je me demande si ce ne serait pas du flux QUIC, par exemple pour des services android.
-
Bonjour ,
Il y a t-il une solution du coup pour contourner ? car effectivement sur My Canal la qualité est bonne mais mon ping monte.
Etant en adsl mon upload sature rapidement .
Hello ;D
Je débarque ici après une recherche sur le host: "strmt.tf1.fr"
Curieux de voir un peu ce que ça racontait là dessus... je suis étonné qu'il y ait si peu de résultats
J'ai découvert ce weekend-end que mon 1M d'upload ADSL saturait dès que j'étais sur un replay TF1
Pour le fiston "On Game" le ping qui monte à 150 : il a senti direct ???
Bref, pour mon PC Windows, un simple ajout dans le fichier hosts
127.0.0.1 strmt.tf1.fr
semble suffisant pour que le player TF1 ne puisse plus récupérer les IP's des clients P2P
Je trouve vraiment moyen le manque d'information/consentement sur la technologie utilisée, je n'ai pas encore parcouru les 7 pages de ce post mais je suis curieux de connaitre à quel point TF1 "se sert" de notre bande passante
-
Je trouve cela très limite quand même.
Ont-ils le droit d'utiliser à notre insu notre upload?
-
J'ai parcouru ce post, de ce que j'y ai vu :
- c'est pas dans les CGU de TF1 (j'ai pas vérifié...)
- ils utilisent plus de 20M d'upload si ça leur chante
Pas de moyen simple de désactiver ce partage P2P depuis le player... mon 1M d'upload j'y tiens moi ;D
Alors je comprend le principe d'effort, la technologie est sympa et ça permet d'avoir ce qu'on veut même en cas de forte demande
Mais là, pour le coup, j'ai le sentiment que c'est utilisé juste pour faire des économies... c'est là que j'apprécie moyen...
-
J'ai du mal à vous comprendre.
D'un côté, vous particuliers (en fibre), disposez d'une bande passante "à volontée" confortée par une course à la montée en débit (tous vers le 10G à l'abonné !) et d'équipements actifs pour regarder le contenu,
D'un autre, le diffuseur se remet en question et semble prendre en compte les préoccupations écologiques/économiques pour économiser sur les serveurs de diffusion qui deviennent inutiles pour vous proposer du contenu _gratuitement_.
Et malgré cela ça bronche quand même. En gros, votre upload ne doit servir qu'à frimer lors de speedtests ? Ils ne font pas du minage bitcoin avec votre bécane non plus.
Au contraire, moi j'ai envie de saluer cette initiative qui a le mérite d'utiliser plus intelligemment les ressources plutôt que blinder un parc de serveurs.
Là où je vous rejoindrais c'est si un jour un service _payant_ genre Netflix utilise effectivement mes ressources pour diffuser le contenu que je paye pour y accéder. Mais là c'est gratuit, calmez-vous.
-
Gratuit ? Le temps que tu passes devant les pubs c'est quoi ?
Après c'est quand même qqn en ADSL qui se plait juste au dessus, à juste titre.
-
Je n'ai pas m'énerver, tu m'as très bien compris mais il y a une différence entre regarder un replay au calme, et sortir sa carte bleue hein.
-
C'est toujours pareil, y a une bonne idée (le P2P pour ce genre de services) et la mise en oeuvre pas toujours bonne (genre ça te pourri l'up d'un ADSL).
Côté payant, il me semble que Blizzard propose (ou proposait) le téléchargement de ses jeux en P2P.
-
C'est toujours pareil, y a une bonne idée (le P2P pour ce genre de services) et la mise en oeuvre pas toujours bonne (genre ça te pourri l'up d'un ADSL).
Côté payant, il me semble que Blizzard propose (ou proposait) le téléchargement de ses jeux en P2P.
Le système de streamroot ne peut il pas faire un simple test d'upload et en dessous d'un certain débit ne pas opérer ?
-
Ce serait normal, après c'est peut-être encore perfectible.
-
Faudrait les contacter pour leur poser la question :o
-
Désolé j'aurai du le préciser; en fibre ou sur une connexion correcte (bon VDSL, FTTLa...) je trouve que l'idée est très bonne, même si dans certains cas ça va te pourrir ton expérience si l'environnement WiFi est limite...
Là où je ne suis pas du tout d'accord avec l'idée et où il y a clairement un abus de la part de TF1, c'est pour les connexions ADSL/3G/4G ou un accès soumis à quota.
-
C'est toujours pareil, y a une bonne idée (le P2P pour ce genre de services) et la mise en oeuvre pas toujours bonne (genre ça te pourri l'up d'un ADSL).
C'est exactement ça !
Je ne suis pas du tout contre, mais à défaut d'une mise en oeuvre correcte pour les petits uploads/forfaits limités, j'aurai aimé être informé et avoir le choix de le désactiver si besoin.
Par ailleurs, je me suis débrouillé et j'ai trouvé en peu de temps pourquoi mon ping s'envolait,
Mais pour "Monsieur et Madame tout le monde": ils se retrouvent juste avec une connexion "merdique", pas facile à diagnostiquer ni à expliquer comme "panne"
Moi j'ai pas râlé non plus ;)
ça aurait été Arté j'aurai rien dit ;D
-
Sur l'application mobile, c'est aussi en p2p ?
Il faudrait un test de vitesse comme sur les vidéos youtube
-
Sur l'application mobile / Android TV, TF1 ne semble pas faire de peer-to-peer (cela a peut-être changé depuis mes tests)
Par contre depuis un navigateur web connecté en 4G, il y a bien du peer-to-peer.
-
En effet, sur ma connexion ADSL 4/0.5, ça met à terre la connexion entière. J'ai entendu au bout de quelques dizaines de secondes : "Ya pu internet!" à l'autre bout de la colloc.
Je soupçonne l'upload saturé d'impacter le téléchargement correct du flux parce que la qualité s'apparentait a un 240p youtube... Je l'ai peut être pas laissé assez longtemps se stabiliser aussi...
je rententerai quand il y aura personne, voir si il arrive à avoir un débit de download correct
-
En effet, sur ma connexion ADSL 4/0.5, ça met à terre la connexion entière. J'ai entendu au bout de quelques dizaines de secondes : "Ya pu internet!" à l'autre bout de la colloc.
Je soupçonne l'upload saturé d'impacter le téléchargement correct du flux parce que la qualité s'apparentait a un 240p youtube... Je l'ai peut être pas laissé assez longtemps se stabiliser aussi...
je rententerai quand il y aura personne, voir si il arrive à avoir un débit de download correct
En coloc, il vaudrait mieux mettre en place une QOS
-
En coloc, il vaudrait mieux mettre en place une QOS
bof se repartir la misère, sur une ligne "ADSL 4/0.5", autant rien faire franchement
que chacun fasse gaffe sera plus efficace je pense
-
Si l'upload est saturé (buffers pleins), cela limite le downlaod car les acquittements mettent plus de temps à arriver.
-
Pour revenir au sujet, TF1 n'est pas le seul à utiliser Streamroot en France : c'est toujours utilisé sur 6play, et Francetv le fait toujours par exemple sur les chaînes régionales de France 3.
C'est sûr que la techno n'est pas encore parfaite, et peut saturer les petites lignes, ou cramer un forfait data en partage de connexion. Pour l'instant, un moyen simple de l'éviter reste de désactiver WebRTC...
Mais sur le fond, je pense que c'est la bonne direction pour une utilisation un peu plus optimisée des infras existantes (tant qu'on a des abonnements fixes sans limitation au volume). Et ce genre de modèle ne pénalise pas les fournisseurs de contenus qui proposent des streams en haute qualité.
-
...Pour l'instant, un moyen simple de l'éviter reste de désactiver WebRTC...
Et comment effectues ça ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
Et comment effectues ça ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
Dans Firefox, il faut passer "media.peerconnection.enabled" à "false" dans about:config.
L'ennui est que c'est un réglage global, ça ne fait pas partie des choses qu'on peut autoriser ou bloquer suivant le site.
Sinon, avec des plugins.
Par exemple, avec uBlock Origin (dans mon cas EasyList semble casser tf1.fr actuellement...), on peut ajouter dans "Mes filtres" : tf1.fr##+js(nowebrtc)
-
A part du skype ou SIP dans le navigateur et du P2P comme l'explique ce sujet ca fait quoi le webRTC ?
-
A part du skype ou SIP dans le navigateur et du P2P comme l'explique ce sujet ca fait quoi le webRTC ?
Techniquement c'est :
- capture de flux vidéo / audio (webcam, ...)
- échanges P2P, c'est-à-dire entre deux clients (éventuellement avec un serveur relai si nécessaire)
Dans les applications, à part "Skype" et les CDN P2P dont on discute ici, il existe par exemple des sites permettant le transfert de fichiers directement entre deux machines.
-
Dans Firefox, il faut passer "media.peerconnection.enabled" à "false" dans about:config.
L'ennui est que c'est un réglage global, ça ne fait pas partie des choses qu'on peut autoriser ou bloquer suivant le site.
Sinon, avec des plugins.
Par exemple, avec uBlock Origin (dans mon cas EasyList semble casser tf1.fr actuellement...), on peut ajouter dans "Mes filtres" : tf1.fr##+js(nowebrtc)
Merci pour le tuyau: ça peut toujours servir. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
-
Hop la un script sous UBUNTU qui viendra completer mon init.sh
A lancer sous sudo sinon remplacer SUDO_USER par USER
nécéssite aussi de relancer le browser si c'est en cours d'utilisation.
#!/bin/bash
dir=`printf '%s\n' /home/${SUDO_USER}/.mozilla/firefox/*.default-release`;
echo $dir
echo "user_pref(\"_user.js.parrot\", \"NOK\");"> $dir/user.js
echo "user_pref(\"media.peerconnection.enabled\", false); // VIRE WEBRTC">> $dir/user.js
echo "user_pref(\"_user.js.parrot\", \"OK\");">> $dir/user.js
-
Ce soir, je n'allume Molotov TV qu'à 20h02 pour l'intervention d'Emmanuel Macron.
=> Saturation, impossible d'afficher la liste des chaînes.
Je passe sur TF1, sur le web, via Firefox 75 sous Ubuntu.
J'ai été étonné : aucun flux sortant, pas de partage de flux peer-to-peer.
Je regarde le flux récupéré : il provient de 13.224.62.114 (flux TCP avec chiffrement TLS 1.2).
Étonnant : c'est Amazon ! Je ne savais pas que TF1 pouvait déborder sur Amazon (car vu leur de ma connexion, je pense que je suis arrivé alors qu'il y avait déjà une forte demande)
-
Molotov ne suit pas sur ce genre de pics.
https://www.lemagit.fr/etude/Comment-Molotov-TV-a-bati-un-datacenter-qui-ne-tombe-pas-en-panne
-
Sur mes réseaux, le trafic a chuté... vu que la TV est balancée sur des fréquences dédiées pour le câble, et sur du 1550nm pour la fibre. Rien sur l'IP, ça me sauve la vie !
-
Pourquoi avoir coupé l'IPv6 sur les flux OTT maison (TV sur PC) ?
-
Pourquoi avoir coupé l'IPv6 sur les flux OTT maison (TV sur PC) ?
On garde les flux pour nos abonnés qui payent la TV
-
Ah donc les flux ne sont pas IPv4 only ? (c'est ce que l'on pouvait penser en lisant ton message)
Cela me rappelle CitéFibre où il était possible de récupérer les flux multicast avec VLC.
L'unique chaîne optionnelle, XXL, avait été cachée en ne suivant pas la logique des autres.
-
Ah donc les flux ne sont pas IPv4 only ? (c'est ce que l'on pouvait penser en lisant ton message)
Ils sont en IPv6-only. Ca force mes abonnés à ne pas le désactiver arbitrairement sur leurs devices. Et étonnamment de tous les retours que j'ai eu, je n'ai pas aucun abonné sur le carreau car son équipement n'est pas compatible.
-
Ce soir, je n'allume Molotov TV qu'à 20h02 pour l'intervention d'Emmanuel Macron.
=> Saturation, impossible d'afficher la liste des chaînes.
Ça fonctionnait très bien chez moi (Appli sur Android TV, réseau SFR FTTH).
Intercos ?
-
Ça fonctionnait très bien chez moi (Appli sur Android TV, réseau SFR FTTH).
Intercos ?
Je pense qu'une fois le flux lancé c'était bon. C'est vraiment la partie avant qui posait souci (handshake, liste des chaines, répartitions des clients, etc).
-
+1
Ils ont - à nouveau - communiqué sur cette panne de leur solution qui ne tombe pas en panne :
-
Ça fonctionnait très bien chez moi (Appli sur Android TV, réseau SFR FTTH).
Intercos ?
Je suis aussi chez SFR (câble, mais avec une IP AS15557) mais ce n'est pas l'interconnexion car le flux fonctionnait bien sur la dernière chaîne regardée, mais il était impossible de changer de chaîne (la liste de chaînes n’apparaissait pas).
EN parlant d'interconnexion, je ne note jamais de problème avec SFR, c'est clairement un de leur point fort.
-
Je suis aussi chez SFR (câble, mais avec une IP AS15557) mais ce n'est pas l'interconnexion car le flux fonctionnait bien sur la dernière chaîne regardée, mais il était impossible de changer de chaîne (la liste de chaînes n’apparaissait pas).
J'ai un peu regardé, en effet, leurs serveurs ne mettent rien en cache (sauf les pages à l'accueil quand on est déco). Du coup, la requête remonte et tape sur le backend applicatif pour, j'imagine, charger les droits de la session et savoir si on a le droit de regarder telle chaine, avant de balancer la liste... Il y a des technos aujourd'hui comme JWT pour vérifier ça côté client.
Fort fort longtemps, j'ai eu bossé pour un site à fort trafic (site de cams ^^) et on avait réussi à diviser par 10x la charge des serveurs simplement en écrivant la liste des salons et les chats dans de bêtes fichiers textes (oui le truc en txt ^^) où le navigateur tapait dessus tranquillou et où le serveur Apache n'avait pas besoin de charger PHP et d'appeler l'applicatif derrière.
-
Oui pour ceux qui ne le savent pas l’application Molotov TV, c'est un simple navigateur web basé sur Chromium qui est lancé.
Les applications proposées sur Mac, Linux et Windows sont en fait une seule web app packagée en applications natives grâce au framework Electron. Il est impossible de se connecter à cette web app, disponible à l’adresse https://app.molotov.tv, avec un navigateur, le service limitant son accès à ses logiciels.
On a vu des extensions, tel que Cocktail sous Firefox ou MoloChrome pour changer le user agent du navigateur pour se faire accepter, mais cela ne fonctionne plus.
-
Oui pour ceux qui ne le savent pas l’application Molotov TV, c'est un simple navigateur web basé sur Chromium qui est lancé.
Les applications proposées sur Mac, Linux et Windows sont en fait une seule web app packagée en applications natives grâce au framework Electron.
Un mec Français a fait ça aussi pour Stadia ;)
Il y a un Github et une vidéo sur YouTube qui présente le "hack".
-
Je n'avais pas vu ce thread. Si vous voulez je peux répondre à quelque question vu que j'ai été grandement impliqué dans la mise en place de la solution à l'époque. (bon pas à tout)
-
Perso je suis en routeur 4G, je regarde par exemple "the voice" cela consomme 500Mo en SD. je voudrais savoir le nombre de personne max qui peuvent recevoir eux-aussi mon flux de mon IP.
-
Ca c'est des secret d'implementation mais globalement un flux sd c'est max 1mbit/s en reception, en upload je ne sais pas combien, mais je dirais qu'en 4g c'est meme assez peu probable qu'il y ait des gens qui viennent taper chez toi vu la latence.
-
Sur franceTV avec la config browser par defaut, je suis obligé de relancer 2 fois un flux pour que ca marche...
J'ai plus ce probleme en desactivant WebRTC.
-
Par ailleurs je ne sais pas si on a déjà repondu sur le sujet mais il y a eu beaucoup de confusion sur la nature des flux:
gros résumé :
- live tnt :en direct de la regie, pas IP, c'est aussi ce qu'on appelle le flux primaire
- live box isp : multicast depuis les infras de la chaine via dark vers les isp, qui font ce qu'ils veulent après, mais en général c'est du mulitcast jusqu'au dslam, last router ; a noter que certains petit opérateur n'ont pas d'interco et reprennent du flux tnt, cable, sat pour le re-encoder de leur coté et le diffuser)
- replay box isp : alors il y a plusieurs cas. Le plus courant est que les ISP diffusent les videos eux meme. Donc les différentes chaines envoient leur videos dans un format pivot aux ISP qui en font ce qu'ils veulent, généralement les mettes sur un CDN interne en divers format. Je pense que ca reste assez simple et unicast. (par exemple je sais que SFR utilise un grosse ferme centralisé de varnish pour ca, free a une approche plus decentralisé avec des serveurs dans dans certains dslam, du moins à l'époque) A noter un cas alternatif qui est la bbox miami (du moins pour TF1) qui faisait du replay depuis la box en ott (aka comme si on était derriere un navigateur/tel)
- replay/live ott (pc, tel) : le cas qui nous interresse pour streamroot. Donc c'est simplement la mise à disposition de videos en pseudo streaming par les chaines. Ensuite il y a les CDN ou pas (par exemple TF1 diffuse pour une grande partie depuis son "CDN" interne) et par dessus il y a les technos p2p.
Le live en ott n'est qu'un cas particulier de replay.
-
Pour Free c'était réellement au niveau du DSLAM, pas des PoP régionaux ?
-
Pour Free c'était réellement au niveau du DSLAM, pas des PoP régionaux ?
En tout cas il y a un POC. Je me souviens de discussion sur comment installer des serveurs supermicro avec plein de disques dans des shelters (et donc des baies qui ne sont pas du tout faites pour)
-
- live box isp : multicast depuis les infras de la chaine via dark vers les isp, qui font ce qu'ils veulent après, mais en général c'est du mulitcast jusqu'au dslam, last router ; a noter que certains petit opérateur n'ont pas d'interco et reprennent du flux tnt, cable, sat pour le re-encoder de leur coté et le diffuser)
Peut-on connaitre les modalités pour demander une interco ?
Si c'est trop indiscret, possible en privé ?
-
Je t'ai répondu en MP.
-
Je me souviens de discussion sur comment installer des serveurs supermicro avec plein de disques dans des shelters (et donc des baies qui ne sont pas du tout faites pour)
Des shelter ça ressemble plus à des POP régionalisés.
-
On a une idée de la part du P2P par rapport au trafic total au niveau live/replay ?
-
On a une idée de la part du P2P par rapport au trafic total au niveau live/replay ?
Oui je connaissais le taux d'offload qui pouvait être très bon si le contenu était chaud.
-
Du coup ça s'applique sur le live aussi (qui par définition est toujours "chaud") ?
Sur le replay, un client qui a regardé le un contenu en entier peut servir des portions du début quand il est vers la fin ou il y a seulement une partie du flux qui est conservée ?
-
Du coup ça s'applique sur le live aussi (qui par définition est toujours "chaud") ?
Sur le replay, un client qui a regardé le un contenu en entier peut servir des portions du début quand il est vers la fin ou il y a seulement une partie du flux qui est conservée ?
Ca s'applique complétement au live (dés lors qu'il est regardé par un nombre suffisant de personne en simultané, par exemple les lives de TFX a 2h du matin bin bof quoi).
Sur un replay tu peux potentiellement servir tous les chunks (enfin des sub-chunks de la video que tu as loade) tant que tu n'as pas changé de page (a priori je n'ai pas regardé l'implem client en détail). Tu as aussi les limites lié au navigateur.
-
Explication de la diffusion vidéo peer-to-peer par Streamroot : (traduction à gauche et l'original en anglais à droite - cliquez sur les miniatures ci-dessous - les documents sont au format PDF)
(https://lafibre.info/images/tv/201912_streamroot_livraison_video_peer-to-peer_expliquee.webp) (https://lafibre.info/images/tv/201912_streamroot_livraison_video_peer-to-peer_expliquee.pdf) (https://lafibre.info/images/tv/201912_streamroot_peer-to-peer_video_delivery_explained.webp) (https://lafibre.info/images/tv/201912_streamroot_peer-to-peer_video_delivery_explained.pdf)
-
Le service peer-to-peer de Streamroot n'existe plus, Lumen l'a détruit (pas revendu, détruit).
Une autre solution de peer-to-peer est en train de prendre sa place : https://quanteec.com/
La solution permettrait de diviser par 5 le trafic coté serveur pour un flux live.
-
Le service peer-to-peer de Streamroot n'existe plus, Lumen l'a détruit (pas revendu, détruit).
On sait pourquoi ?
-
Lumen a revendu pas mal de choses et probablement que cet OVNI n'était pas simple à revendre.
C'est aussi risquer de concurrencer le marché de Lumen (les clients ont été migrés vers une technologique Lumen sans P2P).
Maintenant avec les rumeurs de Fare Share ( cf https://lafibre.info/peering/twitch-brider-en-coree/msg978413/#msg978413 ) les plateformes vidéo sont très intéressés par ces technologies qui permettent d'éviter la potentielle future taxe. Sur le Fare Share, l'Europe n'est plus aussi sûre d'elle, mais le sujet n'est pas définitivement enterré. Je pense que les nombreuses réactions opposées à un tel mécanisme a surpris et l'exemple de la Corée du Sud montre bien que cela peut tourner à la catastrophe (peut-être que les plateformes ont fait exprès de faire tourner mal le cas de la Corée, pour éviter que ce mécanisme n'arrive dans d'autres pays).
-
Est ce qu'on sait si France TV utilisait toujours une technologie à base de webrtc en octobre 2023 ?