Conception et implémentation du pipeline Go (API, worker, stockage objet, file)

Pipeline de transcodage événementiel (API / queue / worker)

Upload découplé du FFmpeg : API → stockage objet → file de messages → workers CMAF (HLS+DASH), métadonnées PostgreSQL.

≥ 85
seuil VMAF (cible design)
2
binaires api + worker
async
upload ≠ encode

Contexte

Socle média pour une marketplace et un client mobile feed vidéo : besoin d'ingérer des vidéos, les transcoder, et les servir en streaming adaptatif sans bloquer la requête HTTP d'upload.

Le problème

Lancer FFmpeg dans la requête HTTP bloquerait l'API et couplerait le scaling du front au GPU. Il fallait une source de vérité objet, des workers sans état, et un packaging lisible par les lecteurs mobiles (HLS) tout en gardant DASH possible.

L'approche

  • API Go (chi) : création d'upload, URL présignée S3, enqueue file de messages — aucun encodage dans le process HTTP.
  • Worker stateless : probe → thumbnail → transcode CMAF → packaging HLS + DASH ; disque local éphémère uniquement.
  • Interfaces ObjectStore / Queue pour S3 (ou MinIO en local) et SQS (ou LocalStack).
  • Seuil qualité documenté VMAF ≥ 85 avant statut ready ; déploiement prévu Docker / Terraform / Kubernetes.

Pourquoi ce choix

Go pour l'orchestration (concurrence, binaires statiques) ; FFmpeg pour l'encodage. CMAF pour un seul jeu de segments fMP4 réutilisable HLS et DASH, plutôt que deux pipelines séparés.

Résultat mesuré

  • Architecture API ↔ file ↔ worker validée en local (PostgreSQL + MinIO + SQS)
  • Sorties HLS/DASH prévues depuis un packaging CMAF unique
  • Cible qualité documentée : VMAF ≥ 85 avant ready