Nolife, les outils (5) : Papoum

Après Marvin, Logolife et Time Attack, au tour d’un autre logiciel propriétaire de Nolife de se voir dévoilé ici : Papoum. Ce sera un peu plus long… car le sujet est plus complexe 🙂

La situation mi-2008, plus d’un an après le début de la diffusion de Nolife, était que la chaîne avait un sérieux soucis à la diffusion : les personnes en charge de la conduite antenne (à l’époque, principalement Alex Pilot) n’avaient aucun moyen automatisé de vérifier qu’un programme était actuellement online sur la régie de diffusion ou pas. Le seul moyen était manuel : il fallait y accéder par ftp et vérifier, parmi des centaines de fichiers, que les émissions qui avaient dernièrement été uploadées étaient bien présentes.

Tout le problème résidait dans le système d’upload, qui n’était pas trivial : la première étape était d’uploader les fichiers par FTP dans un dossier dans lequel Nolife possédait des droits d’écriture. Ensuite lorsque l’upload était terminé, un script distant était sensé détecter que le fichier était uploadé (en réalité que sa taille ne changeait plus…) et faisait une vérification d’intégrité de la vidéo. Si la vidéo était ok, elle était copiée automatiquement dans le dossier contenant tous les fichiers disponible pour la diffusion (vidéos dites « PAD » pour « Prêt À Diffuser »), sur lequel Nolife n’avait qu’un droit en listing+lecture, une règle imposée par Cognacq-Jay pour des raisons de sécurité. Sinon, le fichier partait dans un dossier « quarantaine » de vidéos non-viables pour la diffusion.

Le système s’arrêtait là : pas d’alerte, pas d’avertissement. Si jamais il y avait une interruption lors de l’upload (ce qui était fréquent…), le script se lançait, en concluait que la vidéo était incorrecte et la mettait en quarantaine. De plus, un autre script était régulièrement lancé qui allait nettoyer le dossier en effaçant des vidéos PAD en fonction de règles prédéfinies (exemple : les 101% qui ont plus d’un mois), car la place disque était extrêmement limitée.

Au niveau de la diffusion à proprement parler, lorsqu’un fichier de la playlist courante n’était pas présent, la régie passait simplement au fichier suivant – un comportement qui est normalement interdit en diffusion télé : les régies génèrent normalement un noir équivalent à la durée du programme manquant pour ne pas décaler le reste de la programmation. Lorsqu’il s’agissait de clips ou de rediffusions de courtes rubriques, ce n’était pas grave. Mais lorsqu’il s’agissait du 101% du jour, c’était un problème évidemment très gênant, et en général la saute d’une émission se traduisait par un décalage catastrophique de l’enchaînement des playlists (se terminant souvent, encore une fois, par un coup de fil à Cognacq-Jay pour sauter un programme).

Autrement dit, il fallait absolument trouver un moyen de vérifier automatiquement si tous les programmes d’une playlist étaient bien « online » en régie. L’idée a commencé à germer en juin 2008 : en effet, sur la fin de saison l’équipe de Nolife est en général très fatiguée et les erreurs humaines se multiplient, ce qui a été le cas à cette période. Peu de temps auparavant, si mes souvenirs sont bons, Sébastien avait développé Time Attack, dont on a déjà parlé ici. À la rentrée de septembre 2008, après de nouvelles erreurs d’émissions non diffusées, je me suis mis au travail.

Ce fût ma première contribution à la création des outils de Nolife. Ça n’était pas si évident que ça : ma dernière vraie expérience de développement datait de 7 ans plus tôt. De plus, j’ai choisi de travailler en C# (.NET 3.0 à l’époque) et en WPF, ce qui n’était pas répandu (le WPF sont les nouvelles API d’interface homme-machine de Microsoft qui ont été introduites avec Windows Vista). Seb n’ayant pas l’expérience du WPF, il n’a pas pu m’aider et je me suis souvent bien fait chier pour comprendre la logique du bouzin. Mais au final je ne l’ai pas regretté… comme vous pourrez le voir plus tard.

Papoum 0.1 – L’origine
(septembre 2008)

Papoum, dans sa version 0.1, avait été développé sur le modèle d’interface de Time Attack que je trouvais très pratique et qu’Alex connaissait déjà.

Le fonctionnement était relativement simple : Papoum téléchargeait au lancement la liste des fichiers par FTP sur la régie de diffusion. Ensuite, il suffisait de glisser sur la fenêtre un m3u généré par Marvin et retouché par Alex. Papoum affichait alors la playlist à la façon de Time Attack, sauf qu’il vérifiait que le fichier était bien en ligne sur la régie. Dans le cas contraire, la ligne apparaissait en rouge. C’était tout, mais cela a suffit pour qu’Alex l’utilise immédiatement ! Évidemment, à partir de fin septembre 2008, les erreurs de diffusion dues à des fichiers offline ont baissé de façon spectaculaire (c’est toujours un peu gratifiant de voir un résultat quasi-immédiat ^^).

(Je fais une petite parenthèse sur le nom : au départ ce devait être un tout petit projet et je m’étais imaginé mettre un petit son qui faisait « Papoum ! » lorsqu’on droppait une playlist. Le son n’est jamais arrivé mais par contre le nom est resté. C’est toujours un peu délicat du coup quand on le présente à des professionnels :))

Papoum 0.1 permettait aussi d’afficher la liste complète des fichiers disponibles en régie (bouton « Afficher CJI » sur l’interface), ce qui évitait d’avoir à utiliser un client FTP pour vérifier des uploads manuellement.


Version 0.2a de Papoum. Ici, tous les fichiers de la playlist apparaissent offline. Je ne peux plus le faire fonctionner car ses paramètres sont entièrement hardcodés et la configuration de Nolife a changé.

Dès le départ, Papoum intégrait certains bout de code de Marvin, comme celui qui permettait de déduire la durée d’une vidéo de la taille du fichier, ce qui lui donnait un air de « Time Attack ++ ». Puis Alex a commencé à demander plus de fonctions, comme par exemple éviter de charger le listing du ftp à chaque lancement.

La version 0.3 (renommée ensuite 0.30) permettait de scanner les fichiers stockés localement à Nolife afin de les comparer avec ceux en ligne. Cela permettait de détecter les différences de versions car les émissions étaient parfois recompressées ; c’est notamment arrivé lorsque Nolife a commencé à être diffusée sur Neufbox, car la compression utilisée par Nolife jusque-là était incompatible avec ce réseau.

Pour éviter le scan des fichiers systématique à chaque lancement, les metadatas des médias de Nolife étaient sauvegardés en XML : la base de données de Papoum était née. Cela permettait de faire des stats (du genre : tous les 101% additionnés font tant d’heure, etc), mais surtout cela a eu une incidence notable par la suite sur le fonctionnement de Nolife.

Papoum a ensuite continué à évoluer avec deux mises à jour majeures.


Papoum 0.31 : les stats de durée totale des émissions, disponibles pour la première fois, ont également servi pour faire la promotion de Nolife.

Papoum 0.40 – Rock the Playlist
(décembre 2008)

La version 0.40 a intégré une véritable simulation de la diffusion des playlists par IPPlay. Pour résumer, au lieu de glisser une seule playlist, on pouvait désormais en glisser plusieurs ; Papoum affichait ensuite ce qui allait effectivement être diffusé à l’antenne en simulant le comportement de la régie, y compris les enchaînement foirés et les playlists qui bouclaient (avec un avertissement quand ça arrivait).
Cette fonctionnalité est, après encore bien des améliorations, celle qui sert encore actuellement pour checker les playlists et les envoyer en régie (cf les screenshots en fin d’article).

Papoum 0.50 – De bien belles assets
(janvier 2009)

La seconde étape majeure a été la transformation de logiciel de vérification de playlist à celle de MAM (Media Asset Management), fin janvier 2009.

Je m’étais en effet rendu compte que je pouvais récupérer les infos de Marvin (via une passerelle intégrée à Papoum) et en faire une espèce de base de données un peu mieux foutue. De plus, je disposais d’informations supplémentaires : par exemple, la simulation de playlists implémentée dans Papoum 0.40 me permettait de déduire les heures de premières et dernières diffusions d’un programme.
Je me suis donc dit qu’en structurant un peu tout ça, il serait peut-être possible de centraliser un minimum les informations que l’on avait sur les émissions de Nolife tout en ajoutant d’autres, comme par exemple lier un titre à chaque type d’émission (CU : « 101% », CM : « Chez Marcus », etc), donner des numéros, des sous-titres, des descriptions, la couleur du logo, etc.

Donc, d’une base stockée sur un fichier XML, Papoum est passé à plusieurs. Comme je viens de le dire, il était possible de rentrer des informations sur chaque émission. Une autre nouveauté, plus discrète mais essentielle, était que ces metadatas n’étaient plus liées au fichier media mais à une entité de plus haut niveau : l’émission (« show »). À la base, l’idée était de préparer Papoum à la connexion avec une vraie base de donnée relationnelle (type MySQL). De plus je caressais l’espoir de pouvoir envoyer les infos un jour ou l’autre aux différents EPG (guide des programmes), et également d’indiquer sur le site web les programmes en cours de diffusion ; la centralisation des informations était essentielle pour cela.

D’autres fonctions sont apparues dans cette version : la recherche, la possibilité de donner un niveau d’importance aux émissions…

Bien sûr un travail de nettoyage et de réécriture a dû également être fait en parallèle pour supporter tout ça, et c’est à ce moment-là par exemple que la maintenance (debuggage…) a commencé à prendre du temps, et que la configuration via des fichiers externes est apparue (fin du paramétrage « en dur » dans le code).


Papoum 0.50. Beaucoup de choses étaient déjà prévues dans la structure de cette version, qui ont été implémentées dans les versions 0.5x suivantes.

Papoum 0.60 – L’apogée
(mars 2009)

La base de code de la version 0.60 de Papoum a été la plus stable et la plus aboutie techniquement, ce qui a fait d’elle la version qui a le mieux fonctionné, et ce pendant 15 mois. Je crois que c’est un record dans la vie de ce logiciel !

Principalement il s’agissait de grosses améliorations techniques ou la réutilisation de fonctionnalités déjà existantes. Par exemple est arrivée la possibilité de « lier » virtuellement plusieurs médias pour en faire une émission (principalement pour le J-Top et Ami Ami Idol). Mais la première fonctionnalité « publique » de Papoum, celle qui l’a un peu fait connaître des gens suivant assidûment la chaîne, fût NoAir, en avril 2009 (Papoum 0.63).

NoAir part du principe qu’on pouvait faire un « guide des programmes » avec tout ce que j’avais déjà dévelopé pour Papoum. Cela consistait tout simplement à aller chercher les playlists déjà entrées en régie (on en a toujours conservé une copie en local), et faire une simulation de diffusion sur celles correspondants aux 12 dernières et 24 prochaines heures. De là on garde les programmes uniquement marqués comme « importants », et hop ! On a la liste des programmes qu’on peut partager avec les téléspectateurs. Ceci s’est fait par l’upload d’un XML sur le site web (qu’il fallait déclencher via un bouton dans Papoum). NoAir existe toujours à l’heure actuelle même s’il n’est plus généré de la même manière : vous pouvez en avoir un exemple et apprendre comment créer votre propre client.


L’implémentation de Nolife de NoAir, disponible sur le site officiel.

Un autre amélioration technique concernait le scan des médias car le format de compression avait encore changé pour s’adapter à des modifications dans IPPlay. Du coup, on se retrouvait avec une multitude de formats différents (MPEG2 en 544×576 4/3 et 16/9, 720×576 16/9, upper field first, lower field first et deux bitrates différents) et le scan « à l’arrache » ne suffisait plus. Papoum a donc intégré un vrai scan des médias grâce à l’excellent mediainfo.dll et pouvait sonner l’alerte dès qu’un fichier non compatible avec la diffusion était programmé, car chaque type de fichier était reconnu et classifié. L’algorithme de scan a dû être pas mal affiné à cette occasion car mediainfo prend son temps et il est hors de question de rescanner intégralement 16000 fichiers à chaque fois.

La version 0.60 a aussi introduit le multi-utilisateur qui était TRÈS bancal. En fait les XML étaient centralisés sur le réseau et au démarrage, Papoum en chargeait une copie. L’utilisateur pouvait ensuite centraliser les informations de son poste vers le réseau (en écrasant les anciennes)… j’ai dit que c’était bancal ?

Ensuite, et c’est plus subtil, la terminologie a évolué. Par exemple on a vu apparaître la notion de « stocks » pour définir les emplacements des médias. Ce changement vient du fait que Nolife, avec l’aide d’Ankama, avait déposé des dossiers pour la reprise sur le câble et le satellite ; or IPPlay n’était pas une régie suffisamment fiable pour ces réseaux – de toute façon, IPPlay était une bonne solution pour démarrer, mais pas sur le long terme. Ankama avait donc lancé l’achat d’une nouvelle régie pour Nolife, construite par la société MBT et avec laquelle, à terme, Papoum devait s’interfacer. La terminologie s’est donc adaptée à celle en vigueur dans le milieu.

Pour finir, une sombre version 0.70 est sortie mi-juillet 2009. En fait la seule vraie nouveauté était une passerelle écrite pour récupérer toutes les informations concernant les clips japonais et français qui étaient stockées dans un tableau Excel et que Seb recopiait à la main dans Marvin (comme vous le voyez, on partait de loin). Le but était de centraliser toutes les informations concernant les émissions de Nolife dans Papoum, car la véritable base de données à été construite durant l’été 2009 à partir des XML de ce dernier.

Papoum 0.90 – Adieu IPPlay… Adieu Papoum ?
(octobre 2009)

Mais, mais mais, où est la version 0.80 ?

En fait, la 0.80 n’a jamais été déployée sous ce nom. Il s’agit d’un « fork », une branche parallèle dans le développement de Papoum qui s’est créée mi-2009. Elle sera mise en production durant l’été mais déployée sur l’ensemble des postes de Nolife uniquement début 2010. Je vous laisse deviner ce qui a motivé cette bifurcation soudaine ! 🙂

La branche 0.60 de Papoum a tout de même continué à évoluer sous le numéro « 0.9x » pour la différentier de la nouvelle branche (qui sera finalement numérotée 1.0). Au départ, la 0.60 devait être abandonnée, mais elle est restée, jusqu’à ce jour, le seul outil que l’on avait pour vérifier les playlists avant diffusion. Elle est donc encore en production et curieusement, est revenue à sa fonction de base.
Les autres fonctions de Papoum ont été progressivement désactivées ou modifiées car Papoum et ses XML n’était plus la référence. Par exemple, les métadatas des émissions sont désormais automatiquement récupérés de la nouvelle base de données, mais Papoum ne peut pas les renvoyer dans l’autre sens. C’est en quelque sorte devenu une « impasse » logicielle.

Entre temps, les choses avaient pas mal changées au niveau de la diffusion.

Car même si Nolife n’a finalement pas été reprise sur le câble et le satellite, Médiamétrie a commencé à mesurer l’audience sur l’ADSL dès février 2010… mais le signal envoyé par IPPlay interdisait à Nolife de se faire mesurer. Donc la régie de MBT (le « Chameleon »), qui était restée en sommeil, a finalement été mise en production en juin 2010, et IPPlay complètement abandonné.

Or, le Chameleon ne fonctionne pas du tout comme IPPlay ! Le principe est absolument contraire : le player vidéo est asservi par un logiciel (« Phoenix ») qui gère une seule playlist (dite « playlist antenne »).
Autrement dit, c’est la playlist antenne qui définit à quelle moment précis chaque média doit être joué, et à quel moment il doit s’arrêter, et ce, à l’image près. Il faut évidemment que ces données correspondent au média qu’on veut jouer… donc on ne peut plus simplement donner une liste de fichiers, il faut aussi donner un timecode de début de lecture (par exemple le 20/05/2011 à 14:35:24:12, soit 14h 35mn 24s et 12 images) et une durée précise pour chaque média. Le player qui joue le média est dans une couche plus basse et si le média joué est en réalité plus long que ce qui est indiqué dans la playlist, il sera coupé ; s’il est plus court, il y aura un écran noir à l’antenne.

Du coup, impossible de balancer nos m3u moisis dans ce système. La solution, encore une fois, a été d’utiliser la simulation IPPlay intégrée à Papoum et tout simplement d’exporter une playlist antenne au bon format, avec tous les TC, pour la nouvelle régie. Pour être vraiment précis sur cette partie, MBT nous a aussi aidé en développant de leur côté une autre passerelle pour nous permettre de fusionner la playlist exportée de Papoum dans la playlist antenne de Phoenix.

C’est donc Papoum qui fait la passerelle entre Marvin et le Chameleon, alors qu’au départ il avait un simple rôle de vérification. Ce qui explique en partie sa longévité en production, car il est assez difficile de changer un composant critique de la diffusion.

Enfin (ouf !), la dernière modif a concerné l’arrivée toute récente de la publicité, le challenge ici étant que les noms des médias et leur durée nous sont communiqués par France Télévision Publicités bien avant leur diffusion, mais que Papoum n’a pas accès aux médias pour les scanner. Or ce dernier n’a pas été prévu pour gérer des émissions sans média (par défaut quand ça arrive la durée est ramenée à 0).

Le problème là-dedans, c’est que la nouvelle régie, la publicité et d’autres changement structurels à Nolife n’étaient pas du tout prévus dans la mécanique originale de Papoum. Du coup depuis début 2010 les patchs s’enchaînent, le rendant de moins en moins stable, et chaque nouveau patch génère des comportement imprévisibles. La branche 1.0 ayant considérablement évolué depuis, sa retraite est donc très proche et il sera vraisemblablement entièrement remplacé dans le courant de l’été 2011 par… Shin Papoum !

Et pour finir, voici quelques screenshots de Papoum 0.98 :


Papoum 0.98, qui devrait être la version finale.
Notez le fichier offline (non disponible en régie pour une diffusion immédiate) et les petites images dans l’interface qui sont là grâce à la souplesse de WPF ! De plus, un clic droit sur un média ouvre un menu contextuel permettant soit de localiser le média sur le réseau, soit de le jouer dans VLC. La colonne de gauche est la liste des types d’émissions, générée à partir des noms de l’ensemble des médias trouvés.


Un exemple de recherche qui s’effectue en live, « à la iTunes ». Le niveau de vert des émission correspond à leur niveau de visibilité publique (pour NoAir). Notez qu’un scan des médias est effectué en parallèle (en bas).


Les metadatas d’émissions sont désormais principalement importées d’une source extérieure mais sont toujours dispo dans l’ancienne fenêtre d’édition pour consultation. Le rouge indique que toute modification sera perdue.


Voici le fameux simulateur de conduite antenne IPPlay, introduit dans Papoum 0.40.
Ici il y a trois playlists, et on voit que la simulation est correcte (la playlist de 18h33 commence à 18h55 à cause du Chez Marcus). Les pubs sont en violet pour qu’elles soient bien visibles (Nolife a l’obligation de les diffuser dans certaines plages horaires). Trois fichiers sont actuellement offline sur la régie, mais la playlist antenne peut tout de même être générée avec les bons timecodes et les médias copiés plus tard. Enfin, le bouton « Exporter vers Phoenix » permet d’exporter ce que l’on voit vers la nouvelle régie de diffusion.

Diverses infos. Le switch entre régie a été désactivé une fois la migration de la diffusion effectuée.

Nolife, les outils (4) : Time Attack

Cet article est la suite de…
Le défi du m3u
Marvin
LogoLife

Donc, continuons sur la liste des outils spécifiquement développés pour Nolife. Jusqu’à présent je vous ai présenté Marvin, qui génère les playlists au format texte en suivant certaines règles (comment sont définies ces règles sera l’objet d’un autre article… et oui, c’est pas fini). Puis LogoLife, le petit bijou de PixelPhil qui permet d’incruster les habillages de chaîne à la volée lors de la compression des vidéos.

Tout ceci est bien joli, mais à la fin, il fallait dès le 1er juin 2007 reprendre les playlists à la main pour vérifier les enchaînements entre elles.

Je rappelle succinctement le fonctionnement de la première régie de Nolife (IPPlay) :

  1. Une playlist est chargée et commence à jouer à une heure donnée (heure extraite du nom de fichier de la playlist).
  2. La playlist suivante est, elle aussi, chargée, mais pas jouée.
  3. La régie est comme un gros Winamp, elle va jouer le premier fichier et attendre qu’il soit fini de jouer.
  4. Une fois que le fichier est terminé, IPPlay compare l’heure actuelle avec l’heure de la playlist suivante. Si l’heure de la playlist suivante est inférieure à l’heure actuelle…
    —> alors IPPlay bascule sur cette nouvelle playlist et retourne au (2).

  5. Si la fin de la playlist est atteinte sans qu’il n’y ait de playlist suivante :
    —> alors IPPlay revient au début de la playlist courante, charge le premier fichier et retourne au (4)
    —> Sinon, IPPlay charge le fichier suivant et retourne au (4).

En gros, ce système simplissime avait pour but la diffusion de chaînes extrêmement simples, du genre Astro center (je crois que Freenews TV l’utilisait aussi).

On peut dire que Nolife, dès le départ, a explosé les limites du logiciel, vu que d’une playlist qui bouclait toutes les heures et qui ne changeait pas très souvent, on est passé à 48 playlists par jour contenant parfois jusqu’à une vingtaine de médias différents. (ce qui n’a pas manqué de déclencher certains bugs dans IPPlay).

Une des problématiques de faire les playlists était donc de connaître, au moins approximativement, la durée des médias joués à l’avance et si possible, la durée d’une playlist entière. En effet une playlist trop courte ou une émission trop longue pouvait décaler complètement la diffusion. Par exemple, si dans la playlist de 19h on mettait une bande-annonce et un 101%, si le 101% faisait 35mn et que la playlist suivante démarrait à 19h30, en réalité cette dernière allait démarrer à 19h35 au moins et tout fonctionnait. Par contre, si le 101% faisait par exemple 27mn, IPPlay arrivait en bout de playlist, bouclait sur la playlist de 19h et rejouait une deuxième fois le 101%, ce qui décalait la playlist de 19h30 à 19h54. Le soucis ici, c’est qu’on n’avait absolument pas la main sur IPPlay et que ça se soldait par un coup de fil à Cognacq-Jay pour demander à un technicien de cliquer sur le bouton « next » pour sauter le 101% en trop (Cognaq-Jay a reçu beaucoup de coup de fils en trois ans).

Bref, c’est devenu rapidement pas tenable du tout, et Alex a demandé à Seb d’essayer de faire un logiciel pour lui indiquer la durée d’une playlist. Dont acte, avec Time Attack.



Le principe de Time Attack est simple : on glisse un ou plusieurs fichier(s) média au(s) format de la régie dans l’une des 4 cases (à l’époque, des MPEG2 Transport Stream à 3Mbps), et il donne la durée de chaque fichier.

On peut aussi glisser une playlist et Time Attack va alors calculer l’heure de diffusion de chaque média, ce qui était extrêmement pratique pour faire des simulations mentales de ce qui risquait approximativement de se passer à l’antenne. Comme il y avait 4 case, cela permettait d’avoir de la visibilité sur au maximum 4 playlists. Cette fonctionnalité ne marche plus car Time Attack devait alors aller chercher lui-même les médias qui étaient stockés sur le réseau, or l’emplacement réseau a changé et l’adresse est codée en dur dans le logiciel.

L’autre petit défaut est que Time Attack ne scannait pas vraiment les médias pour en connaître la durée : comme on travaillait en CBR, Seb avait calculé un débit moyen et pouvait déduire la durée approximative d’une fichier à partir de sa taille. Ce système implémenté dans Marvin à l’origine fonctionnait plutôt bien et a d’ailleurs été conservé pendant deux ans.

Preuve que Time Attack était utile, Alex l’a immédiatement adopté. C’est aussi en voyant Time Attack que je me suis dit qu’on pouvait faire un autre logiciel du même type pour détecter les médias mal (ou pas) uploadés sur la régie, ce qui se soldait par des émissions non diffusées. Et ce sera pour la prochaine fois !

Audiences : Tout le monde a gagné

Les plus anciens reconnaîtront cette phrase extraite d’un des plus fameux programmes du PAF (et pouf !) : l’école des fans. « Tout le monde a gagné, allez chercher vos cadeaux » qu’il disait le Jacques aux petits enfants qui avaient bien ou mal chanté à nous en faire péter les oreilles pendant une heure.

Pour les résultats Médiamétrie du câble/satellite/ADSL/TNT payante, cette mesure appelée « Mediamat’Thématik » (anciennement MediaCabSat), c’est un peu la même chose. Le jour où les résultats tombent, deux fois par an, les communiqués pleuvent dès le milieu d’après-midi. Et les résultats sont invariablement les mêmes : tout le monde a gagné, tout le monde est n°1 quelque part. Il n’y a pas de perdant.

Pour comprendre ce qu’il se passe, il faut savoir que les chaînes ne reçoivent pas une grande feuille Excel avec le classement des chaînes (comme celui que donne Médiamétrie dans son propre communiqué officiel). En réalité, Médiamétrie fournit un logiciel propriétaire ainsi qu’un fichier de données contenant toutes les mesures effectuée pendant la période de l’étude. Ensuite, à charge de la chaîne d’utiliser ce logiciel pour sortir tout un tas de chiffres qui lui seront utiles pour éventuellement modifier sa grille (y compris publicitaire), voir comment sa chaîne se comporte sur telle ou telle tranche d’âge, réseau, jour, heure, etc.
Les possibilités sont assez vastes, par exemple on peut sortir un pourcentage d’audience par rapport à la totalité des individus regardant la télé sur une période donnée, ou par rapport à l’audience d’une autre chaîne. On peut sortir l’audience brute en nombre de téléspectateurs, ou bien en % par rapport à plein de choses. On peut savoir, sur un mois, combien de personnes uniques auront regardé telle tranche horaire, etc. La seule limitation est qu’on ne peut pas sortir les audiences d’un jour particulier de la période : au plus fin, on ne peut travailler que sur des moyennes par « jour nommé » (moyenne de tous les lundi, de tous les mardi, etc), et la précision horaire la plus fine est de 15mn.

À partir de là, le but du jeu est de sortir l’indice qui mettra la chaîne le plus en avant pour faire un joli communiqué. Tout en sachant que pour la publicité, ça ne changera strictement rien : les régies pub ne prennent en compte que les chiffres bruts (nombre de téléspectateurs) et jamais les part d’audience. La part d’audience, c’est surtout classer les chaînes les unes par rapport aux autres sur une période donnée, et donc, pouvoir éventuellement se la péter.

Je rappelle que la part d’audience (pda) se mesure simplement en prenant le nombre de téléspectateurs regardant la chaîne à un moment donné, divisé par le nombre de téléspectateurs regardant la télévision au même moment. On multiplie par 100, et hop, on trouve la pda.

Si vous vous êtes un peu intéressé aux communiqués sortis mardi, vous aurez pu donc remarquer que chaque chaîne est la meilleure. Mais par contre, aucune chaîne n’est la meilleure au même endroit : une communiquera sur le fait qu’elle est très bonne sur les 4-50 ans, une sur les hommes 15-34, une sur les CSP+… C’est normal : on parle ici de chaînes thématiques. Vivolta n’a pas les mêmes téléspectateurs que Nolife, qui n’a pas les mêmes téléspectateurs que Gulli. Donc comparer toutes les chaînes ensemble sans restreindre l’âge, c’est très compliqué et ça donne des résultats au final pas très parlants pour la majorité des chaînes qui se battent plutôt sur des tranches d’âges bien précises (cf le classement de Médiamétrie). Au final, le but, c’est évidemment d’essayer de ramasser la plus grosse part du marché publicitaire sur la tranche d’âge qui concerne la chaîne.

Cependant, lorsqu’on est dans le milieu professionnel de la télévision, on est au courant de tout ça, et évidemment, on sait que les communiqués de presse sont à prendre avec (beaucoup) de pincettes. De toute façon, toutes les chaînes mesurées par Médiamétrie reçoivent les mesures de tout le monde, donc on peut facilement vérifier les dires des communiqués. Parfois, la surprise est toutefois au rendez-vous…

Comme par exemple, avec ce communiqué de Lagardère.

Avec 0.1% de part de marché et près de 5 millions de téléspectateurs par mois, MCM, diffuseur du Top 50, enregistre une progression de 100% auprès des hommes de 15/34 ans. Elle se partage la première place des chaînes musicales aux côtés de NRJ Hits et MTV, auprès de cette cible.

La première phrase est aisément vérifiable lorsqu’on a accès au logiciel d’interprétation des mesures. Par contre, la seconde phrase est plus discutable. Il s’agit d’une interprétation des résultats via le filtre du service marketing & communication de Lagardère, qui est beaucoup plus sujet à caution. Vous en trouverez pas mal, des phrases de ce genre, dans les communiqués (ex. : « chaîne très forte chez les jeunes » -> définissez « jeunes » ?). Comme c’est l’exemple qui m’a le plus frappé, je vous donne les résultats tels que les donnent Médiamétrie. Je vous laisse deviner comment ils les ont interprétés, en sachant que généralement on enlève les chaînes TNT gratuites qui font des chiffres de toute façon bien supérieures aux chaines cab/sat/ADSL/TNT payante (ici, dans cette étude, l’audience des chaînes TNT gratuite n’est mesurée que sur leur part câble+satellite+ADSL, on n’a pas les chiffres d’audience sur la TNT gratuite, donc c’est un peu biaisé. On considère généralement que les 18 chaînes TNT gratuite seront toujours au-dessus des autres).

Part d’audience Hommes 15-34 ans, univers complet (câble/satellite/adsl)
Mediamat’Thematik vague 20 (30 août 2010 – 13 février 2011)
6 premières chaînes musicales :
1. Direct Star (1,1%)
2. Nolife (0,7%)
3. NRJ Hits (0,5%)
4. Trace Urban (0,3%)
5. MCM (0,2%)
6. MTV (0,2%)

« (MCM) se partage la première place des chaînes musicales aux côtés de NRJ Hits et MTV »

…savent-ils seulement que Nolife et Trace Urban sont des chaînes musicales ?

Nolife sur le câble ?

Il y a quelques jours, un téléspectateur potentiel de Nolife (DaPlayer) qui reçoit la télévision par l’offre câble de Numéricâble a eu la surprise de voir qu’il captait Nolife en branchant sa télé directement sur l’arrivée Numéricâble. Il a tout de suite fait part de sa trouvaille sur le forum de Nolife : oui, la chaîne était diffusée sur le réseau de Numéricâble, sur le canal 178 !

À Nolife, on a reçu la nouvelle avec beaucoup de circonspection, car rien n’avait été signé avec Numéricâble, aucune négociation n’était en cours, et surtout se posait la question de l’origine du signal que cette personne recevait.

Nous avions besoin de preuves pour commencer à contacter nos différents prestataires et éventuellement Numéricâble. Finalement, DaPlayer a envoyé une vidéo expliquant la manipulation qu’il avait faite, et comment il recevait la chaîne.


DaPlayer a en fait trouvé le flux de Nolife en n’utilisant pas le décodeur TV de Numéricâble (le sien étant en panne) mais en branchant le câble coaxial directement sur l’entrée antenne de son nouveau téléviseur HD, pensant ainsi pouvoir capter le « service antenne », c’est à dire les chaînes analogiques et de la TNT reprises par le câble et disponibles que la personne soit abonné au câble ou pas (c’est une obligation légale, il me semble).

Mais en fait, son téléviseur disposait en plus du tuner analogique et DVB-T (TNT), un tuner DVB-C (Câble). Ce tuner permet de capter tous les flux numériques qui transitent par le réseau utilisé par Numéricâble, qui n’est pas le réseau de « Numéricâble » à proprement parler, comme je vais l’expliquer un peu plus bas. Beaucoup de chaînes sont payantes, et donc cryptées, et sa télévision ne peut les lire (à moins d’avoir un lecteur de carte dans sa télé pour mettre la carte Numéricâble, de tels téléviseurs existent désormais).

Pour ma part, mes soupçons se sont envolés à partir du moment où j’ai compris que les téléviseurs récents possédaient un tuner DVB-C – ce que je ne savait pas. Mais le mystère restait entier : d’où provenait ce flux vidéo ?

Un petit appel à notre prestataire de diffusion, Cognacq-Jay Images, nous a permis d’y voir un peu plus clair sur la probable source de ce flux magique.

En fait, le réseau physique en fibre optique qu’utilise Numéricâble n’est pas le réseau de Numéricâble mais celui d’une autre société, Completel. Il se trouve que Numéricâble a racheté Completel il y a quelques temps, donc il s’agit plus ou moins de la même entité (quand vous donnez l’autorisation à Numéricâble de percer un mur, vous le donnez aussi à Completel), mais en réalité le réseau de Completel est utilisé pour d’autres choses que les offres aux particuliers. Par exemple, la régie de diffusion de Nolife transmet son signal à Cognacq-Jay via une liaison spécialisée transitant par le réseau de Completel.

Donc, en réalité, Completel fait transiter les flux télévison de Numéricâble via son réseau, mais il pourrait aussi faire transiter d’autres flux, y compris sur son réseau dédié aux offres de Numéricâble.

Et c’est précisément ce qui se passe, puisque Completel loue désormais son réseau à un concurrent de Numéricâble qui va déployer son offre aux particuliers normalement très bientôt. Nous n’avons aucun détail là-dessus mais je pense qu’il devrait s’agir d’une offre THD (Très Haut Débit) via la fibre optique FTTB de Completel, en triplay (internet+téléphone+télé), voire quadriplay.

Il se trouve que Nolife est déjà diffusé sur un autre réseau de cet opérateur. Maintenant, je vous laisse tirer les conclusions de cet article avec une petite précision : pour l’instant, aucune arrivé de Nolife sur le réseau de Numéricâble est à l’ordre du jour.

Pour ceux qui sont abonnés Numéricâble, il reste donc trois solutions pour recevoir Nolife : ou bien attendre l’offre de ce nouvel opérateur et quitter Numéricâble pour cette nouvelle offre, ou bien essayer de brancher votre télé HD à la sortie coaxiale de Numéricâble en espérant que vous captiez la chaîne (il vous faudra certainement un câble de ce type), ou prier pour que Numéricâble se réveille…

Nolife, les outils (1) : le défi du .m3u

Ça faisait un moment que je voulais faire cette série d’articles alors je profite d’un moment de douce folie pour la commencer.

Nolife est une chaîne atypique de beaucoup de points de vue.
Sébastien Ruchet, le PDG, met cependant un point de départ assez clair à l’histoire de la création de la chaîne : la possibilité d’utiliser une régie de diffusion à très bas prix (quelques centaines d’euros) pour diffuser sur les réseaux IPTV ADSL. C’est véritablement le secret du début de l’aventure Nolife, car même si la forme actuelle de la chaîne est évidemment due à d’autres éléments bien plus importants, sans cette possibilité technique de base le projet n’aurait jamais pu voir le jour.

Ce système de régie appelé IPplay est proposé par la société Cognacq-Jay Images ; techniquement il s’agit d’un simple PC doté d’un disque dur contenant les fichiers vidéo des émissions déjà compressés au format MPEG2 et encapsulés dans un flux TS (transport stream). Le logiciel met bout à bout (concatène) les fichiers et les envoie tels quels sur le réseau de Free, et ce flux est décodé nativement par les freebox.

Ce système a l’avantage de ne pas nécessiter de hardware coûteux (cartes de sorties vidéo pro, système d’automation coûteux et compresseurs MPEG2 IP broadcast hardware). Une simple connexion FTP permet d’envoyer les fichiers sur le serveur.

Il possède également de nombreux inconvénients. Tout d’abord sur le format des fichiers : les logiciels permettant d’encapsuler du MPEG2 dans un flux TS corrects se comptent sur les doigts d’une main. Et dans tous les cas, la concaténation des fichiers est aléatoire, des inconsistances de timestamp ou de timecode sont monnaie courante. Le second problème est que ce système n’est directement compatible qu’avec les terminaux de Free (freebox). Pour les autres réseaux, il faut tout de même passer par des encodeurs MPEG2 IP hardware. Si le format du MPEG2 ou du flux TS est incorrect, cela peut faire planter les freebox ou les encodeurs hardware (problème qui s’est souvent posé sur Nolife, et une seule fois la chaîne a même provoqué des écrans bleus chez ceux qui la regardaient avec VLC ! Bug de IPplay qui fut corrigé par la suite).

Enfin, l’inconvénient le plus gros n’est pas forcément le plus évident ! Pour jouer des fichiers dans IPplay, il faut fournir à ce dernier des playlists. Celles-ci sont de simples fichiers texte nommés « m3u » qui contiennent le nom des fichiers à jouer les uns après les autres. La date et l’heure de lancement de la playlist est indiqué dans le nom du fichier de la playlist : par exemple la playlist « 2010_02_01_19_00_00.m3u » se lancera le 1er février 2010 à 19h. Si un programme est en cours de diffusion, la playlist sera lancée à la fin de ce dernier.

Ce système simple à un défaut : il est simple ! Même pour une chaîne qui démarrait comme Nolife, le problème s’est très rapidement posé de l’automatisation de la création de playlists. La grille originale était pourtant relativement basique : plages de clips, émission (101%), plage de clips, émission… mais il fallait créer toutes les playlists à la main dans notepad, sans se tromper dans les noms de fichiers, choisir les clips à passer pour des plages de plusieurs heures, etc, tout cela quotidiennement.

Nolife n’aurait pas pu continuer avec ce seul système de diffusion, qui était à la base prévu pour boucler la même playlist toutes les 30 minutes (donc pour une chaîne de TV à la grille très simplifiée et redondante à l’extrême). C’est grâce à l’ingéniosité de plusieurs personnes qui ont développé des outils que l’équipe de la chaîne a pu se consacrer sur le contenu plutôt que sur la création du conducteur antenne proprement dit.

Sans parler du site web et de Nolife Online, qui ont à eux seuls une histoire aussi torturée que tumultueuse sous l’égide de Debug, Alesk et Seb, des outils ont été spécifiquement développés par ou pour Nolife afin d’automatiser beaucoup d’aspects de la conduite antenne ainsi que simplifier la gestion d’autres aspects de Nolife.
Voici une liste non-exhaustive :

– Marvin
– LogoLife
– Time Attack
– Papoum !
– Shin Papoum !
– OtomeGUI

…à la prochaine fois pour plus de détails !