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 !

3 réflexions sur “Nolife, les outils (4) : Time Attack”

  1. Et ça vaudrait pas le coup de mettre toute cette belle collection de logiciels en open-source ?

    Je sais, si Nolife pouvait en revendre un bout ça ferait toujours du bien. Mais si d’autres chaînes l’utilisent, ça peut aussi permettre d’avoir un système complete plus stable. Et virer les bugs plus vite, y compris dans IPPlay ou les interactions avec IPPlay.

    L’open-source est typiquement utile dans ces cas là : votre métier n’est pas de faire des logiciels de diffusion, c’est de faire du contenu. Les outils « pour pouvoir travailler » sont ceux qu’on a le plus intérêt à open-sourcer : ils ne rapportent pas d’argent à la boite (ils coutent en fait) et on veut qu’ils soient stables et qu’ils aient un maximum de fonctionnalités.

    [Note : je sais pour LogoLife, tout n’est pas entre vos mains …]

  2. La question nous a été posée plusieurs fois, mais cela n’est pas forcément intéressant, pour des raisons différentes à chaque fois.
    Par exemple, pour Time Attack, ce logiciel est déjà obsolète (il n’est plus utilisé depuis 2008 à Nolife).

    Pour d’autres, dont Papoum dont je parlerai la prochaine fois, c’est que globalement nos codes sont tout sauf génériques : pour l’adapter à un autre contexte que Nolife, il faudrait tout réécrire à 100%. Il existe d’ailleurs déjà des softs (propriétaires et payants) qui font la même chose de façon complètement générique, mais pour faire la même chose en Open Source autant repartir de 0, ça sera plus simple ; je pourrais filer tous les sources que personne ne pourrait rien en faire (sauf s’ils ont la même config réseau que Nolife, les mêmes postes de travail que Nolife, les mêmes médias que Nolife, la même régie que Nolife et exactement la même base de données que Nolife avec exactement les mêmes besoins que Nolife). Même moi je ne peux plus lancer les anciennes versions de nos softs car la configuration de Nolife a changé entre temps.

    La force de développer en interne est justement de pouvoir coller au plus près aux besoins de Nolife. L’open source n’apporterait rien de mieux là-dessus… à part complexifier le soft avec des fonctions dont on n’aurait en fait que faire.

    Et puis honnêtement, n’importe qui avec un peu de background pourrait relancer des projets Open Source similaires et avec des bases plus génériques et plus à même de répondre à des besoins beaucoup plus variés.

    Donc bof.

  3. Cool !

    Vivement la suite des articles, c’est toujours aussi intéressant ^^

Les commentaires sont fermés.