Focus

Focus



  • Disruption ? Au contraire, notre credo : continuité et fluidité !

    Muriel Le Bellac, Présidente et fondatrice de Videomenthe livre son point de vue sur la disruption...

    Nous vivons dans un monde en constante mutation, c’est un fait. Les progrès technologiques aussi bien dans les domaines informatiques que télécom modifient fortement les schémas traditionnels.
    Notre monde audiovisuel professionnel doit faire face à la dématérialisation des contenus et il nous appartient de revoir les méthodes de travail afin de tirer profit de ces avancées techniques.

    Faut-il pour autant s’alarmer ? Car il s’agit bien de translation de la bande au fichier, de la cassette au disque dur, du convertisseur vidéo au transcodeur de fichiers, de l’oscilloscope à la sonde logicielle, de la diffusion terrestre au flux IP, de la consommation des contenus en mode linéaire vers la relecture ou la vidéo à la demande ou encore de l’écran du téléviseur à l’écran du portable, de la tablette ou du mobile…
    Mais le contenu en lui-même doit toujours passer par les mêmes étapes de captation, de montage, de mise en conformité avant diffusion live, en différé, ou à la demande.

    * Pourquoi parler de disruption ?

    Ne s’agit-il pas simplement d’une fantastique évolution qui nous permet une liberté de consommation de contenus audiovisuels encore inimaginable il y a une vingtaine d’années ? Après tout, la VOD n’est apparue que depuis le début des années 2000…
    Partant de ce point de vue, il a fallu remplacer progressivement les plateformes hardware dédiées traitant des sources analogiques, puis numériques ‘bande de base’, par des serveurs hébergeant des solutions logicielles traitant les flux live IP et les fichiers medias.
    Viennent alors ces formidables ressources mises à disposition par l’arrivée du Cloud et de l’internet très haut débit…
    Quel bonheur pour nos développeurs mais quel stress pour nos équipes techniques craignant la dépossession de leur propre infrastructure locale.
    Une des approches est de considérer dans un premier temps le cloud comme simplement une extension de l’installation sur site, afin de pouvoir gérer les débordements, pics d’activité, sans pour autant sur-dimensionner les infrastructures locales qui tourneraient alors en sous régime la plupart de l’année.

    * Et si nous parlions plutôt de continuité ?

    L’idée vient alors d’utiliser un portail dédié à notre activité exploitant les mêmes outils que ceux utilisés en interne : le cloud pointe son bout de nez dans la continuité et la fluidité.
    Dans le même registre, si nous poussons le raisonnement jusqu’au bout, utilisons ce même portail de création de workflow pour piloter nos propres fermes de calculs en interne , du point de vue de l’utilisateur, seule l’interface et les ressources en global importent, il ne se préoccupe pas de la répartition de charge entre son infrastructure et celle mise à sa disposition dans le cloud. Continuité et fluidité sont notre credo et sont la base d’Eolementhe©
    Nous vivons une période enthousiasmante qui permet de faire reculer nos limites quant au traitement et la mise à disposition de contenus sur de multiples devices, profitons-en pour exploiter chaque solution, chaque méthode éprouvée, et révolutionnaire, de manière progressive et souple pour en tirer le meilleur parti.

    L’approche hybride onPremise / Cloud est sans aucun doute le fondement des nouveaux échanges audiovisuels de demain.
    Le monde du fichier nous permet d’utiliser des ressources techniques bien plus importantes que précédemment et d’entrevoir des passerelles qui peuvent devenir transparentes entre notre écosystème ‘on premise’ et le cloud.

    ‘Adapt or Die’, slogan de la société pour laquelle j’ai travaillé au début de mon parcours professionnel visant le passage de la video SD à la HD dans les années 90, a encore une fois tout son sens aujourd’hui : les réseaux télécom et le cloud nous tendent les bras pour nous permettre une diffusion massive sur de multiples supports, et représentent une boite à outils formidable pour développer notre créativité, et proposer de nouvelles offres dans notre milieu attractif des medias.

    Alors arrêtons la disruptivité et allons vers la fluidité des échanges et la richesse des contenus !


  • Episode 2 ! Project Management 3.0

    Suite de l'article!
    Vous n'avez pas encore lu le premier? Il suit celui-ci!

    Gérer un projet avec Github
    L’interface de Github est simple et propose tous les outils nécessaires pour gérer un projet. De la gestion des ressources à la gestion du code en passant par la planification des sprints, il n’y a pas besoin d’outils supplémentaires.

    La gestion d’équipe devient simple
    Il est très simple de créer des équipes, d’ajouter des développeurs et de les assigner à un ou plusieurs projets.
    Les issues pour tout faire
    Une issue est comme un ticket pouvant contenir des fonctionnalités, des bugs, des améliorations, des questions…

    Github issues
    • Une issue peut avoir des tags : feature, bug, improvement, design, question…
    • Une issue peut être assignée à un ou plusieurs membres de l’équipe.
    • Une issue possède une description et tout le monde peut en discuter, ajouter des commentaires, poser des questions...
    Des milestones pour chaque sprint

    Github milestones
    On peut créer des étapes appelées milestones qui représentent des sprints. Chaque sprint a une date de début et une date de fin et ils contiennent une liste d’issues à réaliser. Le pourcentage d’avancement se met à jour automatiquement en fonction des issues fermées.
    Le tableau Kanban pour une vision globale

    Kanban board
    Il permet d’organiser le sprint, de voir rapidement les tâches qui sont en cours, celles qui sont terminées et de savoir qui travaille sur quoi.
    Readme et Wiki pour tout documenter
    Le readme d’un projet donne toutes les informations importantes avant de commencer. Il permet de savoir par où débuter et donne une idée assez précise du fonctionnement global. Le wiki permet d’aller un peu plus dans les détails.
    Les graphiques pour analyser

    Ils permettent d’avoir une vision globale de l’activité sur chaque projet avec entre autres :
    • Les contributions par développeur.
    • La fréquence de code par jour/semaine/mois.
    • La carte des commits par branche.
    Les pull-requests pour conserver un code propre

    Grâce aux pull-requests, chaque développeur travaille sur sa propre version du code et ne risque pas de casser la branche master qui contient le code de production. Ainsi, après avoir bien testé son code, le développeur envoie une demande à la personne qui gère le dossier principal pour ajouter ses modifications. Le code est ensuite analysé automatiquement puis à la main avant d’être ajouté ou refusé.
    La recherche dans tout le projet

    Le champ de recherche permet de chercher un terme dans tout le projet. Il est possible de filtrer par issues, tags, commits, code, wiki…
    N’utiliser qu’un seul outil pour tous les aspects d’un projet est un réel avantage. Github propose peu de fonctionnalités mais l’essentiel est là et tout fonctionne parfaitement.
    ________________________________________
    Conclusion? C'est simple :
    • Utilisez Github pour gérer vos projets.
    • Utilisez les sprints Scrum!


  • Project Management 3.0 - Episode 1 by Rémi!

    1. La méthode classique
    Elle consiste à analyser les besoins, définir un produit à travers un cahier des charges exhaustif, concevoir le produit, le développer et le tester. Un projet peut donc durer entre plusieurs mois et plusieurs années. Le chef de projet doit définir des jalons pour chacune des phases. Les phases d’étude et d’analyse restent totalement théoriques jusqu’à ce que les développeurs se heurtent à certains problèmes que personne n’avait pu anticiper. Le temps de développement d’un projet est donc particulièrement imprévisible et dépasse souvent la durée et/ou le budget initialement prévus.

    2. Les méthodes agiles
    Ces méthodes ont débuté en 2001 aux États-Unis suite au constat du nombre d’échecs croissant de projets de développement. Une équipe d’experts s’est donc réunie et a rédigé un manifeste décrivant l’attitude à adopter pour mieux s’adapter au changement et ainsi mieux répondre aux attentes des clients.
    Le principe de ces méthodes est de découper le projet en plusieurs itérations qui définissent chacune des fonctionnalités composant le produit final. Il y a plusieurs avantages à travailler sur des mini projets plutôt que sur un gros projet :
    • Les développeurs n’ont plus cette impression de ne pas avancer.
    • Les clients participent régulièrement aux phases de tests de chaque fonctionnalité et donnent leur avis au fur et à mesure).
    • Un cercle vertueux se met en place.


    La méthode Scrum

    La méthodologie Scrum
    Scrum est la plus populaire des méthodes Agile. Elle consiste à définir toutes les fonctionnalités de l’application dans un backlog. L’équipe de développement se réunit toutes les 2 ou 4 semaines pour définir les fonctionnalités qu’elle va implémenter pendant les 2 ou 4 semaines suivantes. Le cycle se répète jusqu’à ce que le backlog soit vide. On appelle ces itérations des sprints. Une fois un sprint terminé, on debrieffe et on recommence avec de nouvelles fonctionnalités.
    Je trouve cette méthode valable si on enlève toutes les réunions qu’elle engendre. En effet, voici une liste de toutes les fois où l’équipe doit se réunir pour discuter :
    • Sprint planning : c’est là où on définit les priorités pour le sprint à venir (prévoir une demi-journée par sprint)
    • Daily scrum : tous les matins, on se réunit quelques minutes pour que chacun parle de ce qu’il a fait la veille, des difficultés rencontrées et de ce qu’il va faire aujourd’hui. En théorie, elle ne doit durer que 15 minutes, mais il suffit qu’une personne de l’équipe ait tendance à parler un peu trop et votre matinée est déjà presque terminée.
    • Backlog refinement : ici on estime la durée de chaque tâche. Cette durée est estimée en points. Donc en plus d’être totalement arbitraire et incompréhensible (1 point = combien d’heures ?), le temps passé à estimer la fonctionnalité aurait souvent suffi à la développer (prévoir une demi-journée par sprint).
    • Sprint review : c’est le moment où on fait le point sur le sprint que l’on vient de terminer. Conclusion : on se rend souvent compte que le nombre de tâches prévu était trop important, et on s’organise pour que le sprint suivant soit parfait ! (le sprint suivant se passe en réalité aussi mal que le précédent et en plus il fautprévoir une demi-journée par sprint).
    Toutes ces réunions sont chronophages. En moyenne,une équipe de 4 développeurs perd “10 jours hommes” en réunion toutes les deux semaines.
    Le terme agile ne veut plus rien dire. En théorie, l’équipe devrait pouvoir s’adapter immédiatement aux changements. J’ai malheureusement assisté à des réunions où le chef de projet ne pouvait pas ajouter une petite tâche au sprint en cours car cela “allait à l’encontre de la méthodologie Scrum”.
    Pour conclure, les sprints et les itérations rapides proposés par la méthode Scrum sont une réelle évolution dans la gestion de projets. En revanche, le trop grand nombre de réunions et le manque d’adaptabilité réduisent les bénéfices de cette méthode.

    Dans le prochain article je vous parlerai de GitHub!


  • Baton 7 : un outil à la pointe des dernières exigences

    Nouveaux et derniers formats intégrés (He-AACv2, fichiers de sous-titres TTML, contenu ProRes 4K etc.)

    Meilleure détection des erreurs (textes et sous-titres brûlés, correction du PSE etc.)

    Plus de vérifications spécifiques aux MXF

    Amélioration de l’interface utilisateur

    Personnalisation des rapports

    Multiples détections audio des langues

    Amélioration du processus de vérification manuelle


  • Une amélioration des fonctions Xpress

    Possibilité de multiplexer les flux à différents bitrate dans un seul fichier .mp4

    Création de taille de GOP fixe

    Ajout de l’option d’offset sur le « Timestamp »

    Ajout des informations « maxBitrate » et « avgBitrate » sur le fichier de sortie en .mp4

    Le packager DASH contient désormais les informations de configuration des canaux audio en AAC

    Le fichier MPD du packaging DASH contient désormais les informations d’accessibilité du programme.