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 !