Comment Netflix traite t’il ses vidéos ?

Ou comment transcoder une source 4K vers une dizaine de bas-débits en quelques heures, quelque soit la durée de la source. Un résumé de l’article paru sur le blog technique de Netflix : “High Quality Video Encoding at Scale”.

Publié le

L’article commence par nous informer de la priorité chez Netflix : le fait de pouvoir mettre à l’échelle tous les traitements (en plus d’avoir la meilleure expérience pour l’utilisateur).

Pour commencer, tout se fait sur le cloud d’Amazon, EC2, avec des instances Linux. D’ailleurs tout Netflix repose sur le cloud d’Amazon. Ils n’ont pas de datacentre à eux. Ils adaptent la location d’instances de VM en suivant leurs besoins.

Afin d’avoir des traitements plus rapides, ils découpent les gros traitements en plusieurs morceaux traités individuellement et en parallèle puis ils recollent les morceaux à la fin. En cas de problème, les traitements sont relancés sur d’autres instances.

Schéma principe des traitements
Schéma principe des traitements

La première étape d’un traitement, c’est la “Video Source Inspection”, c’est à dire que les équipes de Netflix reçoivent des images provenant de leurs partenaires ou de leurs propres productions, les ingèrent dans leurs systèmes, les vérifient, et les traitent.

L’article rappelle que si les vidéos en entrée ne sont pas exemptes de tous défauts techniques (conversions, erreurs humaines, transferts), alors les flux de sortie ne seront pas bons non plus.

Leur format préféré pour la récupération de source est l’IMF (SMPTE), à cela s’ajoute le ProRes (supposé QuickTime), le DPX, et le MPEG (2, je pense).

L’ingestion de la “Video Source Inspection” va :

  • vérifier que la source est conforme aux spécifications
  • détecter ce qui pourra poser des problèmes au visionnage (je pense qu’ils font allusion aux macroblock visibles, ou a des passages en très bas débit/trop compressé)
  • générer des métadonnées (indexation) pour le flux de traitement qui va suivre

Si le fichier ne pas pas cette inspection, il saura automatiquement rejeté et “renvoyé à l’expéditeur”.

Il n’est pas possible de stocker dans une instance de machine virtuelle un PAD 4K en entier (on parle de plusieurs To). C’est pour cela que le fichier source est découpé en morceaux. Ce travail est basé sur le résultat de l’indexation faite pendant la “Video Source Inspection” : on détermine à l’octet prêt le début et la fin de chaque morceau, en veillant à ne pas couper une image ou un GOP.

Ces morceaux sont appelés “chunk”. Pour chaque morceau, une passe d’analyse détermine une empreinte et vérifie le niveau de qualité en entrée afin de détecter le niveau de qualité en sortie, après traitement. Enfin l’ensemble des analyses de tous les chunks permettent au système de valider ou non la source, et de la traiter derrière.

Ingestion d’une source
Ingestion d’une source

Leurs process percent d’inspecter une source 4K en moins de 15 min, et ce, quelque soit la durée du programme. Visiblement ils adaptent la quantité de VM à louer et lancer pour chaque programme à traiter.

Le traitement à proprement dit produit converti les chunks de la source en chunks pour chaque déclinaison des bas-débits (en plusieurs formats et plusieurs codecs), assemble les chunks pour reconstituer les fichiers bas-débits et passe une étape de validation finale.

Traitements parallèles
Traitements parallèles

En sortie, cela produit plusieurs fichiers qui auront des débits entre 100 kbps et 16 Mbps, avec les codecs:

  • VC1 (Windows Media Broadcast)
  • h264/AVC Baseline
  • h264/AVC Main
  • h265/HEVC

Pour recoller les chunks, le traitement vérifie que l’ordre est bien respecté, en utilisant notamment les empreintes calculés avant. Il vérifie que la qualité en sortie reste dans les limites prévues et par rapport à la source.

Toutes ces analyses pointues permettent de debugger tout ces traitements avec une grande de précision, notamment pour pointer rapidement quelque chose qui cloche. En effet, on ne peut pas demander à un humain de regarder intégralement tous les bas débits générés pour tous les programmes. Ils veulent avoir le moins possible de retours client à cause d’un fichier mal traité. Ça peut arriver encore plus facilement quand tout tourne sur un Cloud avec des milliers de VMs qui se partagent des bouts de vidéo.

Grace à la parallélisassion de ces traitements, ils savent traiter un programme en quelques heures, et promettre une mise en ligne rapide d’un programme frais, là aussi quelque soit la durée du programme.

Ils espèrent bientôt arriver à 30 min de traitement max. pour un programme HD.

Dans cet article, Netflix montre qu’il est possible d’avoir des traitements de vidéo en masse qui soient rapides, de très bonne qualité, totalement mis à l’échelle suivant les besoins, sans investissement matériel, et sans passer par des systèmes tout-en-un limités.

Cela demande maintenant d’avoir une très grande maitrise dans :

  • les codecs et containers vidéos
  • l’analyse et le calcul d’empreinte, et plus généralement l’analyse de signaux vidéos
  • le traitement de calculs de façon massive et parallèle
  • la gestion dynamique d’instances de VM (comme les déploiements automatiques, et la gestion de parc, la supervision…)

Bref, ce Saint Graal du traitement de vidéo reste encore très difficile d’accès. Toute bidouille dans ce sens apportera un gain de temps de traitement relatif et amènera son lot de problèmes, car il faudra beaucoup de VMs pour compenser le temps que prendra les opérations de découpe et d’analyse.

A noté que Netflix à libéré quelques technologies libres, notamment pour ce qui concerne les VM, le bigdata et les calculs distribués. Mais rien pour le moment en ce qui concerne la vidéo.

Les images sont issues du Blog de Netflix, et je n’ai aucun lien commercial avec eux.