AutoClip : découper des vidéos en extraits par pipeline Celery

Le problème visé : transformer une longue vidéo en extraits courts

Le point de départ est une vidéo longue, souvent une interview ou un stream, dont il faut sortir des passages autonomes. AutoClip prend une URL YouTube ou Bilibili, ou un fichier local, et déroule une chaîne qui va du téléchargement à la génération de clips et de compilations. Le public visé est celui qui refait du contenu à partir de sources existantes, ce que le dépôt appelle la seconde création. Le README liste explicitement le téléchargement multi-plateforme, l'analyse par un LLM, le découpage automatique et la recommandation de compilations. Ce n'est donc pas un éditeur vidéo au sens classique : il n'y a pas de timeline de montage décrite dans la documentation, mais une succession d'étapes automatisées dont on récupère le résultat dans une interface web. La valeur tient à l'enchaînement, pas à une fonction isolée : yt-dlp télécharge déjà très bien une vidéo, ffmpeg coupe déjà très bien un segment, et le README ne prétend pas réinventer l'un ou l'autre. Ce qu'il ajoute, c'est la décision de où couper.

Un pipeline en six étapes, orchestré par Celery et Redis

L'architecture décrite dans le README est une séparation nette entre le front, l'API et le calcul. Le navigateur parle à un backend FastAPI, qui écrit dans SQLite et pousse des tâches dans Celery via Redis. Le dossier backend/pipeline/ montre le découpage en fichiers numérotés : step1_outline.py pour l'extraction du plan, step2_timeline.py pour l'identification des intervalles de sujet, step3_scoring.py pour la notation des segments, puis step6_video.py pour la génération. La numérotation saute de 3 à 6, ce qui suggère des étapes intermédiaires non listées dans l'extrait de README fourni : je ne peux pas affirmer ce qu'elles font. Le README décrit sept opérations côté utilisateur (préparation du matériel, analyse du contenu, extraction de la timeline, notation, génération de titres, recommandation de compilations, génération vidéo), ce qui ne correspond pas un pour un aux fichiers visibles. La progression remonte au client par WebSocket, ce qui évite le sondage. Le choix de SQLite par défaut, avec PostgreSQL présenté comme une évolution possible, indique une cible mono-instance plutôt qu'un déploiement multi-utilisateurs.

Mise en route : Docker, scripts shell ou installation manuelle

Le README propose trois chemins. Le plus court passe par Docker : git clone, puis ./docker-start.sh, avec ./docker-start.sh dev pour l'environnement de développement, ./docker-stop.sh et ./docker-status.sh. En local, ./start_autoclip.sh effectue les vérifications complètes, ./quick_start.sh saute ces vérifications, ./status_autoclip.sh et ./stop_autoclip.sh complètent l'ensemble. L'installation manuelle demande Python 3.8 ou plus, Node.js 16 ou plus, Redis 6 ou plus et FFmpeg, puis pip install -r requirements.txt et npm install dans frontend/. La configuration passe par cp env.example .env. Les clés documentées sont DATABASE_URL, REDIS_URL, API_DASHSCOPE_API_KEY, API_MODEL_NAME avec qwen-plus comme valeur d'exemple, LOG_LEVEL, ENVIRONMENT, DEBUG, UPLOAD_DIR et PROJECT_DIR. Les besoins annoncés sont de 4 Go de mémoire au minimum, 8 Go recommandés, et 10 Go d'espace disque. Ce dernier chiffre mérite attention : il ne couvre que l'installation, pas le stockage des vidéos téléchargées et des clips générés, qui vivent dans ./data/uploads et ./data/projects.

La notation par LLM est le point de fragilité du système

Toute la sélection des extraits repose sur l'étape step3_scoring.py, qui attribue une note de qualité à chaque segment. C'est un jugement produit par un modèle de langage à partir des sous-titres, pas une mesure. Le README ne décrit ni seuil de sélection, ni possibilité de rejouer la notation avec un autre modèle, ni mécanisme de correction manuelle de la note. Il indique seulement que les titres des extraits sont générés par l'IA et que les compilations sont recommandées. Conséquence pratique : si le modèle se trompe sur un passage, le pipeline le propagera jusqu'à la génération vidéo. La documentation ne mentionne pas de garde-fou à ce niveau. Autre contrainte, plus opérationnelle : l'analyse dépend d'une clé API_DASHSCOPE_API_KEY et d'un accès réseau au service DashScope. Une vidéo longue consomme beaucoup de tokens de sous-titres, et le README ne donne aucune estimation de coût ni de débit. Sur un lot important, le facteur limitant sera l'API, pas Celery ni Redis.

Ce que le dépôt ne fait pas encore

Le README marque quatre fonctions comme en développement : le support mobile, la gestion multi-comptes Bilibili, l'upload automatique vers Bilibili et l'éditeur de sous-titres. Ces mentions apparaissent à la fois dans la liste des fonctionnalités et dans le guide d'utilisation, ce qui laisse penser que l'interface expose déjà des points d'entrée pour des fonctions incomplètes. La section de configuration des comptes Bilibili décrit trois méthodes de connexion (import de cookie, identifiants, QR code) et une vérification automatique de l'état des comptes, mais elle porte elle aussi la mention en développement. Le dossier backend/models/bilibili.py et le composant frontend BilibiliManager.tsx existent dans l'arborescence, donc le travail a commencé. Pour un usage réel, il faut considérer la partie Bilibili comme non fiable et se limiter au téléchargement. La licence MIT est permissive : elle autorise la modification et la redistribution, y compris commerciale, sans obligation de publier vos changements. Elle ne dit rien du droit d'usage des vidéos téléchargées, qui relève des conditions de YouTube et de Bilibili et reste votre problème.

Face à yt-dlp et ffmpeg pilotés à la main

L'alternative évidente n'est pas un autre outil d'IA mais la combinaison directe yt-dlp plus ffmpeg, que le README cite lui-même parmi les dépendances. Avec cette approche, vous téléchargez la vidéo et ses sous-titres, vous lisez les sous-titres, vous décidez où couper, puis vous lancez ffmpeg sur les bornes choisies. La différence n'est pas la qualité du résultat, c'est la nature de la décision. Dans le cas manuel, un humain choisit les bornes et peut justifier chaque coupe. Dans AutoClip, le choix vient d'un modèle et vous héritez de ses erreurs sans trace du raisonnement. En contrepartie, le cas manuel ne passe pas à l'échelle : une vidéo de trois heures demande une lecture, et dix vidéos demandent dix lectures. AutoClip échange cette lecture contre une facture d'API. Le bon critère est donc le volume et la tolérance à l'erreur : peu de vidéos et exigence de précision, restez sur yt-dlp et ffmpeg ; beaucoup de vidéos et sélection approximative acceptable, le pipeline automatique se défend.

Coût de maintenance et de mise à jour

Le dépôt a publié v1.1.0, v1.2.0 et v1.2.1 entre juin et septembre 2026, avec un dernier push au 8 septembre 2026. La cadence est récente mais l'historique fourni est court, ce qui ne permet pas de conclure sur la régularité à long terme. La surface de dépendances est large : FastAPI, Celery, Redis, SQLite, Pydantic côté serveur, React 18, TypeScript, Ant Design, Vite, Zustand et Axios côté client, plus yt-dlp, FFmpeg et l'API DashScope. Chacune de ces briques évolue, et yt-dlp en particulier casse régulièrement ses intégrations quand les plateformes changent leurs pages. Le README annonce des scripts de maintenance dans backend/tasks/maintenance.py, mais n'en détaille pas le contenu. Concrètement, prévoyez de mettre à jour yt-dlp indépendamment du reste, et vérifiez que les scripts docker-start.sh et start_autoclip.sh ne figent pas une version ancienne. Le README ne documente pas de procédure de migration de schéma pour la base SQLite, ce qui devient un point sensible dès que vous modifiez les modèles.

Conclusion éditoriale

AutoClip convient à un développeur Python isolé qui veut un pipeline complet, de l'URL au clip, sans écrire d'orchestration Celery lui-même, et qui accepte de dépendre d'une clé DashScope. Ce n'est pas l'outil à choisir pour un traitement par lots de plusieurs centaines de vidéos, ni pour une chaîne de montage où chaque coupe doit être justifiée : le score de chaque segment vient d'un LLM, et le README ne décrit aucune validation humaine avant la génération. Avant d'investir du temps, vérifiez deux points précis : que le modèle qwen-plus accepté par votre clé DashScope est bien celui que API_MODEL_NAME attend, et que le pipeline step3_scoring.py du dépôt correspond à la version documentée. Le reste, y compris l'upload Bilibili, est annoncé comme en développement.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. zhouxiaoka/autoclip on GitHub