Encvid - Outils d'automatisation pour l'encodage vidéo

Cet article est libre d'accès pour tous grâce à ceux qui soutiennent notre blog indépendant.

C'est un projet NodeJS sur lequel j'ai bossé très récemment. Super intéressant à développer contrairement à ce que l'on pourrait croire ; vous n'aurez malheureusement pas le droit d'observer le beau code que j'ai produit car c'est un projet que j'ai fait dans le cadre de mon poste d'ingénieur chez Econocom.

Pour re-situer un peu :
Nous avons un client pour qui, en plus de développer et de maintenir des applications, nous avons une activité d'encodage de vidéos. Le principe est simple, un collaborateur du client (que nous appeleront le client) nous fournit une vidéo à encoder, on l'encode et on retourne les videos encodées.

Vous pouvez vous imaginer que nous, développeurs, nous n'apprécions pas énormément de devoir interrompre nos séances de coding pour faire de l'encodage de vidéos... Nous avons donc décidé de fabriquer un outil qui automatiserait un peu tout ça.


L'encodage vidéo avant

En principe ça devait être simple, mais c'était sans compter sur les attentes précises du client et les contraintes liés au métier de celui-ci. (Oui sinon il l'aurait encodé lui-même sa vidéo si c'était si simple !)

Décrivons le process.

  1. Le client nous envoie par mail une demande d'encodage
  2. Le CDS[1] lui envoie par un lien (jeton) pour qu'il upload sa/ses vidéos sur un serveur de transfert.
  3. Le client upload sa vidéo.
  4. Le CDS récupère la vidéo.
  5. Le CDS encode la vidéo en mp4, flv, webm.
  6. Le CDS archive les vidéos (originales et encodées) sur le réseau partagé du client.
  7. Le CDS transfert les vidéos sur un serveur ftp interne (intranet) et/ou externe (internet) selon la demande du client.
  8. Le CDS envoie les liens vers les vidéos par mail au client.

J'ai volontairement omis quelques étapes par souci de confidentialité[2] mais je trouve le tableau assez bien brossé.

L'encodage vidéo après

Nous avons donc voulu optimiser le process pour faire en sorte qu'il s'exécute plus vite ou au moins qu'il s'exécute en temps masqué.

Voici le nouveau process :

  1. Le client nous envoie par mail une demande d'encodage
  2. Le CDS lui envoie par un lien (jeton) pour qu'il upload sa/ses vidéos sur un serveur de transfert.
  3. Le client upload sa video.
  4. Le CDS récupère la vidéo.
  5. Le CDS lance Encvid.
  6. Le CDS envoie le mail généré par Encvid au client.

Il ne nous reste donc plus grand chose à faire et ce qu'il reste ne nécessite aucune attention/intelligence particulière.

Bien-sûr nous ne comptons pas nous arrêter là. Après discussion avec les chefs de projets, le but est d'automatiser au maximum le process.


Comment ça marche ?

Bon, comment tout ça fonctionne ? Parce que c'est un blog de développement à la base.

L'application est basée sur NodeJS et le module commander pour fournir une interface en ligne de commande. L'encodage est effectué par fluent-ffmpeg qui agit en tant que wrapper JS du fameux ffmpeg.

Pour le transfert des vidéos sur le réseau partagé de l'entreprise le module fs de NodeJS suffit. Par contre pour le transfert en FTP j'ai utilisé le module ftp qui fournit toutes les fonctions définies dans les RFC 959 et 3659.

J'ai essayé de construire l'application de façon à ce que tout ce qui peut être fait de façon simultanée le soit pour gagner du temps.

schema ancien process

L'ancien process (où l'on faisait tout à la main) n'était qu'une succession de tâches, ce qui le rendait long. On perdait du temps inutilement.

schema nouveau process

Le nouveau process utilise pleinement les callbacks de JavaScript pour optimiser le temps passé sur chaque tâche, lancer le maximum de tâches en même temps et avoir une meilleure gestion des erreurs.

Le programme affiche l'avancement, la réussite et l’échec des sous-tâches du process dans la console.

encoding: 97%
screenshot: ok
screenshot copy: fail
generate mail: ok

L'état d'avancement d'une sous-tâche correspond à une ligne de log temporaire, son affichage change donc avec le temps et elle disparaît ou est remplacée lorsque la tâche est terminée. J'ai donc codé un objet Logger chargé de gérer les logs.

Il le fait grâce à un stack qu'il met à jour à chaque changement d'état d'une tâche. Il s'occupe ensuite de l'affichage dynamique des logs dans la console : ajout, modification, suppression d'une ligne de texte.

Voilà pour les quelques aspects particuliers de ce projet. Maintenant, ceux qui se demande ce que je fais vraiment au boulot le savent.


  1. Un CDS est un centre de service. Je bosse dans un centre de service. ↩︎

  2. On ne peut pas tout vous dire non plus ! ↩︎

Rejoins 250+ développeurs de notre liste de diffusion et sois reçois les articles directement dans ta boite mail.

S'inscrire à la newsletter

Aucun spam. Désabonnes-toi en un seul clic à tout moment.

Si vous avez des questions ou des remarques/conseils, n'hésitez pas à laisser un commentaire plus bas ! Je serais ravis de vous lire. Et si vous aimez l'article, n'oubliez pas de le partager avec vos amis.