Ensemble, vainquons les problèmes d'IPTV !

Snipe Foo · 22 Août 2011 à 10:00:20

Comme dit dans le sujet Problème ce gel d'image, je pense qu'en s'y mettant tous, on peut aider à résoudre le problème que nous connaissons tous en ce moment avec l'IPTV à savoir :

Gel d'image, apparition de mosaïque et autres artéfacts, coupure du son.

Il nous faut donc réaliser le plus possible de diagnostics et essayer d'éliminer certaines hypothèses.

Listons les hypothèses, comment les confirmer/infirmer et les tests que nous faisons tous ...

Je mettrai à jour ce post au fur à mesure que l'on avance .

Hypothèse	Tests	Résultats	Commentaires
Un ou des équipement(s) souffre(nt) du chaud	Est-ce que les problèmes sont moindre lorsqu'il fait plus frais (la nuit par exemple) ?	...	Parait peu plausible car les problèmes ont commencé avant qu'il fasse très chaud ... mais bon il faut tout vérifier.
La charge du réseau (Internet) influence la qualité du flux IPTV	Est-ce que le flux est de meilleure qualité lorsque le réseau est moins chargé (pendant les heures de travail) ?	...	Avec le P2P, difficile de savoir quand le réseau est le plus chargé; K-Net pourrait-il fournir un graphe sur une journée de son trafic (en enlevant les chiffres si c'est secret) ?
La quantité de personnes qui regardent la TV influence-t'elle la qualité du flux ?	Est-ce que le flux est de meilleure qualité lorsque la TV est moins regardée (pendant les heures de travail) ?	...	Avec les vacances, difficile de dire quand la TV est regardée; sans compter les box qui restent allumée et continuent de consommer le flux. Le SIEA pourrait-il fournir un graphe d'utilisation des flux IPTV (difficile à collecter j'imagine vu que l'IGMP est géré par chaque NRO) ?
K-Net a été marabouté par un concurrent et seuls ses abonnés souffrent du problème.	Un abonné à un autre FAI sur la fibre SIEA a-t'il des problèmes ?	...	Peu probable aussi (l'architecture IPTV étant la même pour tous).
Les perturbations sur le flux IPTV sont aussi perceptibles sur les autres services (Net et Téléphone)	Créer un graphe des performances réseau sur les autres services (latence/débit) et indiquer sur ce graphe moments ou le flux IPTV perd en qualité.	...	...
Les perturbations sur le flux IPTV sont cycliques.	Créer un graphe temporel indiquant les perturbations sur le flux IPTV. Et essayer d'y voir des cycles.	...	Ça ne vous fait pas penser au projet SETI ?
Les perturbations sur le flux IPTV sont visibles sur toutes les chaines en même temps.	Regarder plusieurs chaines en même temps et indiquer si les perturbations sont visibles sur toutes les chaines ou seulement une à la fois (ou de manière dé-corrélée).	...	Pas forcément évident à mettre en oeuvre. Éventuellement avec des enregistrements ?
Quel est vraiment le problème au niveau flux ?	Inspecter le flux MPEG pour trouver des erreurs.	...	Bon, ce point là il est velu, mais c'est sans doute celui-ci qui nous apportera le plus d'infos. Trouver un bon outils pour faire l'analyse.
...	...	...	...

Snipe Foo · 22 Août 2011 à 10:07:20

Bon, pour faire une analyse plus technique qu'empirique : quel outils permet d'analyser le flux MPEG2 ou 4 ? Je pense que WireShark permet d'avoir certaines données, mais je ne suis pas sûr qu'il sache descendre au niveau frame MPEG. Existe-t'il un plug-in ?

Il faudrait voir s'il manque des paquets MPEG ou s'ils arrivent dans le mauvais ordre.

J'ai aussi l'intuition que le couplage réseau IPTV et réseau LAN c'est le mal.
Le SIEA a mis en place une restriction du nombre d'adresses MAC visibles en amont du CPE, ce qui a pour effet de couper le Net à ceux qui font cette manip et qui on plus de 3 machines sur leur LAN.
Je vais indiquer sur mon blog (encore plus clairement) qu'il ne faut plus utiliser cette méthode...

cbval · 22 Août 2011 à 10:09:48

Pour ma part, j'ai remarqué que les coupures TV et pixellisation correspondaient à une perte de qualité audio lorsqu'on téléphone. Les deux évènements étant concomitants, je pencherait pour un problème de bande passante: une sorte d'oscillation de la vitesse de la bande passante qui se répète toutes les 30-60sec.

Snipe Foo · 22 Août 2011 à 10:13:05

Intéressant cbval, ça rejoindrait un peu le problème que nous avions l'année dernière (coupure toutes les x secondes). Il faudrait faire un graphe de performance réseau (latence/débit) et le corréler avec les pertes de signal sur la TV.

felix_clerc · 22 Août 2011 à 10:23:48

Personnellement, je suspecte plutôt le format des flux. Chez moi, M6 bloque régulièrement - je dois jouer sur le timeshift puis revenir au direct pour que l'image ne soit plus figée - mais je n'ai pas ce souci avec direct8 ou la TSR...

Les chaînes HD, c'est la cata - je ne m'en sers même pas.

Par contre, lorsque je teste ces chaînes depuis le serveur TV de mediaportal, je n'ai aucune perte de paquets - je soupçonne donc vraiment les codecs utilisés d'être une source de gêne.

Ayant cru comprendre que le SIEA réencodait les flux, il serait peut-être utile de savoir quels formats sont exactement utilisés pour chaque chaîne...

Snipe Foo · 22 Août 2011 à 10:31:00

OK, donc il faut vraiment trouver un outils qui inspecte les flux. Peut être FFMPEG ou VLC en mode verbose ?

Je "regarde" encore les chaines HD (car j'ai la flemme de changer ma playlist

) et c'est clair que c'est pire que les autres.

Sur le Media Center Windows, même les enregistrements ont le problème, par contre j'ai pas essayé de revenir en arrière avec le time-shift. A tester (ce soir...).

Steph01 · 22 Août 2011 à 11:46:31

Moi je pense qu'il faut regarder ce qui circule sur ce vlan.

Pas exemple, si un port lan du router est branché sur ce vlan, alors on a des requêtes DHCP qui y circulent.
On a aussi les annonces IGMP des équipement du LAN qui peut-être passent, je ne pense pas néanmoins à une source de problèmes. J'ai regardé le flux IGMP en détail et les coupures/blocks ne sont rattachés à aucun désabonnement de nom décodeur (VLC).

Pour moi, les problèmes sont dues à des paquets UDP dropés (les coupures de son et les blocks en sont typiques). De plus c'est bien pire en HD, ce qui tend à renforcer pour moi cette hypothèse.
Maintenant, qu'est ce donc qui pourrait bien provoquer cela ? Grande question, il va falloir que je pose un snifer pour voir tout ce qui n'est pas IGMP de 10.65.0.x ou UDP de 192.168.0.x. Donc capturer éventuellement tous ce qui n'a rien à faire sur ce vlan.

Va-t-on voir et comprendre le problème en regardant par le coté abonné ? C'est une autre question ouverte car le problèmes peut aussi être caché en amont dans un switch ou router qui est à fond vers 20H avec x chaines de 3 mbps en moyennes à gérer.

En tous cas bonne initiative Snipe Foo, regardons ça de près nous même si nous le pouvons.

Snipe Foo · 22 Août 2011 à 12:01:15

Steph01 : effectivement je pense qu'on a un peu tous la même intuition. Mais les observations de Felix viennent un peu contredire cette hypothèse. Il va donc falloir vérifier tout cela.

Lors du précédent gros problème (perte nette su signal) il s'agissait de requêtes de désabonnement IGMP qui circulaient sur le VLAN IPTV mais qui étaient invisibles du coté client car filtré (interprétée) par le CPE... Toutefois, l'analyse faite à l'époque avait permis de mettre le SIEA sur la voie (cela a conduit à la désactivation de l'IGMP snooping sur le CPE).

Pour moi il est clair que nous n'aurons pas le fin mot de l'histoire sans avoir accès à toutes les parties du réseau, mais j'espère qu'une bonne analyse de notre coté pourra une nouvelle fois aider le SIEA à trouver/résoudre le problème

Maintenant, si le SIEA et/ou K-Net veut communiquer sur leurs propres observations et/ou nous transmettre des infos utiles au diagnostic, ils sont les bienvenus !

Marc01FR · 22 Août 2011 à 13:06:31

Je ne sais pas combien il coûte, mais cet outil semble pas mal

Sinon, vous pouvez sûrement glâner des infos ici, ici et ici

Il y a aussi cette présentation sur le monitoring du traffic IPTV ainsi que celle-ci qui mentionne des outils et celle-ci qui est aussi intéressante.

Steph01 · 22 Août 2011 à 13:43:30

Citation de: Snipe Foo le 22 Août 2011 à 12:01:15
Steph01 : effectivement je pense qu'on a un peu tous la même intuition. Mais les observations de Felix viennent un peu contredire cette hypothèse. Il va donc falloir vérifier tout cela.

Je suis d'accord avec toi. Il y a aussi ce que dit cbval qui est troublant et qui situerait le problème bien en amont.
Je vais d'abord jeter un œil sur le trafic autre si il y en a et ceci dès ce soir.

Citation de: Snipe Foo le 22 Août 2011 à 12:01:15
Lors du précédent gros problème (perte nette su signal) il s'agissait de requêtes de désabonnement IGMP qui circulaient sur le VLAN IPTV mais qui étaient invisibles du coté client car filtré (interprétée) par le CPE... Toutefois, l'analyse faite à l'époque avait permis de mettre le SIEA sur la voie (cela a conduit à la désactivation de l'IGMP snooping sur le CPE).

Ce n'est pas le même cette fois. Mon client n'a jamais besoin de ce réabonner (donc il n'est pas désabonné), il répond juste aux "membership reports" qui arrivent à intervalles réguliers et qui sont sans corrélation observée avec les coupures. J'ai justement le nez dans l'IGMP car je développe une version améliorée d'IGMPProxy en ce moment

, je vais donc regarder l'IGMP d'encore plus près au cas où.

Snipe Foo · 22 Août 2011 à 14:48:33

Marc01 : merci pour les liens. Je ne pense pas qu'on va se cotiser pour acheter l'outils, on va d'abord regarder du coté des softs gratuits

La présentation sur le monitoring est intéressante mais implique la participation des routeurs du SIEA. Je vais lire avec attention celle qui concerne les mesures sur l'IPTV.

Steph01: en fait je citais le précédent problème plus pour dire qu'on pouvait aider le SIEA même sans avoir accès à tout. Je pense effectivement qu'IGMP n'est pas le coupable cette fois-ci.

Pour l'analyse des flux j'ai une piste (mais je peux rien tester depuis le bureau) :
- sniff du trafic avec wireshark -> création d'un pcap avec tout le trafic réseau
- récupération du flux mpeg avec ce script : http://www.perlmonks.org/?node_id=661366
- analyse du flux avec ce soft : http://www.pjdaniel.org.uk/mpeg/ ou un autre ci celui-ci ne donne rien.

Steph01 · 22 Août 2011 à 19:09:47

Premiers résultats de sniff :

Il n'y a bien plus d'igmp snooping sur le CPE
On voie le ~~CDP~~ Spanning Tree Protocol des CISCO et l'annonce PIMv2 de 10.65.3.1, rien d'autre
Je capture en regardant Atlantis sur NRJ-12 et bien sure... ça marche nickel, lol.

Snipe Foo · 22 Août 2011 à 20:24:44

Effectivement, je regarde M6 depuis une bonne demi heure et il n'y a eut qu'une seule perturbation... Donc je pense qu'on peut éliminer l'hypothèse "équipement qui a trop chaud".

Hypothèses les plus plausibles :
- l'abonné qui downloadait comme un goinfre s'est fait chopé par la Hadopi;
- l'employé du SIEA qui avait oublié sa session de debug sur le routeur central est revenu de vacance;
- le SIEA a mis en place la QOS sur le VLAN IPTV.

Bon attendons quand même L'amour est dans le pré avant de crier victoire

cbval · 22 Août 2011 à 20:28:56

Pareil pour moi. Ça va bcp mieux. a croire que seul une mini rébellion sur un forum est susceptible de faire évoluer les choses dans le bon sens. En tout cas, excellente initiative de Snipe Foo...merci!

cbval · 23 Août 2011 à 22:46:13

Ce soir les coupures reprennent...bien que moin nombreuses que les jours précédents c'est suffisant pour agacer. Qqun d'autre subit le même sort?
Me disais bien que cetait trop beau pour durer...

Rechercher