fix(posts): correct the 3 video posts after consultant review, with fresh artwork
Deploy / build (push) Successful in 39s
Deploy / build (push) Successful in 39s
Reviewer's five "highest priority" items, each checked against the source before acting: * 38% speedup -> 38.1% less render time (352s -> 218s, 1.61x throughput); says it was a single run each, same clip, same machine, same encoder settings. * "microsecond-accurate" -> frame-accurate: at 30 fps one frame is 33.3 ms, and the text now states that word-level timestamps are not microsecond-accurate. * "Three minutes later" -> "a few minutes later", plus the one measured number (218 s render for the 4-minute track) so the claim is checkable. * Zero Jitter / Zero Light Flashing -> "no visible jitter" / "no dark flash at the cut", scoped to the clip that was measured. * ti.mode 0o666 -> 0o644. Hygiene, not the syntax error he reported: source and live HTML both read 0o666 (the live page splits it across two highlight spans and his text extraction inserted a space), and 0o666 is legal Python. * "0 MB RAM spike in Chrome" now scopes itself to the Chrome container and says the Python client still buffers the whole tar. New "What this pattern does not solve" block: client buffering, target directory must already exist, tar member names become container paths, Portainer key / CDP 9222 are root-equivalent. All three posts get a TL;DR and inline cross-links (the trio had zero internal links before); the ZH links use the real /posts/zh/<slug>/ path. Not done, because it needs the owner's data rather than invention: end-to-end timing table, benchmark conditions, whether 1.89 s was a single run, before/after jitter clips, the "what still needs a human" list. Task list: docs/consultant-review-2026-10-22-3-video-posts.md. Artwork for the three slugs regenerated (1600x900 banner, 1200x630 share cards EN+ZH, 400/800 list thumbs); the ZH pipeline card already carries the corrected description.
This commit is contained in:
hoelee committed
1 parent
6409f751a9
commit
f32ae90cf0
26 files changed
+349
-76
No files matched your search
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: "我是如何用 Remotion 与 Docker CDP 打造全自动 MV 生成与多语种油管发布流的"
|
||||
description: "从纯音频与歌词到 1080P 高清成片上架并同步发布 8 语字幕的全自动流水线。详解 Remotion 视频合成、Whisper 声学词首微秒对齐与 Docker CDP 发布实战。"
|
||||
description: '基于 Remotion、Whisper、Docker 与 Chrome DevTools Protocol 的全自动音乐视频流水线：从歌词声学对齐、1080P 渲染到 YouTube 自动发布与多语种外挂字幕。'
|
||||
pubDate: 2025-04-18
|
||||
updatedDate: 2026-10-22
|
||||
category: case-studies
|
||||
@@ -14,13 +14,35 @@ draft: false
|
||||
|
||||
做一首歌可能要耗费大半天，如果有几十首歌曲库，这种手工做法完全无法规模化。
|
||||
|
||||
我需要一条纯自动化的工业级管线：只需丢入音频文件与歌词，离开工位。三分钟后，一段 1080P 高清 MV 视频即渲染完成，自带跟随音乐动态律动的音频动效环、高精度三行滚动歌词、智能分镜人物避让切换，并全自动通过远程 CDP 发布到 YouTube，挂载自定义封面与 8 种语言的外挂同步字幕。
|
||||
我需要一条纯自动化的工业级管线：只需丢入音频文件与歌词，离开工位。几分钟后，一段 1080P 高清 MV 视频即渲染完成，自带跟随音乐动态律动的音频动效环、高精度三行滚动歌词、智能分镜人物避让切换，并全自动通过远程 CDP 发布到 YouTube，挂载自定义封面与 8 种语言的外挂同步字幕。
|
||||
|
||||
以下是整套系统的架构设计、核心踩坑点与线上实战方案。
|
||||
|
||||
> **线上成品展示**：由本管线全自动渲染并发布上线的真实曲目为：[《糖画小仙》1080p 官方 MV（YouTube）](https://youtu.be/vZbyKeCCSRA)，内置精准声学对齐与 8 语同步外挂字幕（英、日、韩、西、法、德、马、繁中）。
|
||||
|
||||
> **TL;DR** —— 四段互不耦合的工序：Whisper 词级对齐 → Remotion 1080P 渲染 → Docker 归档落盘 → CDP 发布到 YouTube Studio。每一段各自失败、也各自可单独排查；最难缠的两段单独写了长文：[把大文件送进浏览器容器](/posts/zh/uploading-large-videos-to-youtube-via-cdp/) 与 [消除渲染抖动](/posts/zh/debugging-remotion-video-jitter/)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 整体系统架构
|
||||
## 1. 端到端执行流程与耗时分解
|
||||
|
||||
为了诚实呈现系统的实际吞吐能力，而不是笼统承诺“三分钟搞定一切”，以下是针对 4 分 21 秒（261 秒）1080P 30fps 曲目的实测端到端耗时：
|
||||
|
||||
| 阶段 | 处理流程与工具 | 实测耗时 | 是否真正无人值守？ |
|
||||
|---|---|---|---|
|
||||
| **1. 歌词声学对齐** | `faster-whisper`（词级时间戳）+ 能量起始峰值锁定 | 14.2 秒 | ✅ 100% 自动 |
|
||||
| **2. 构图与留白核验** | 4x2 分镜拼图生成 + 左右留白侧校验（`sides.json`） | 2.1 秒 | ⚠️ 建议 1 键人工核对 |
|
||||
| **3. Remotion 1080P 渲染** | Remotion CLI（30 fps，H.264，7830 帧，i9-13900K + RTX 3060） | 218.3 秒 | ✅ 100% 自动 |
|
||||
| **4. Docker 容器落盘** | Portainer Docker Archive API tar 流写入（128.85 MB 视频 + 封面） | 1.89 秒 | ✅ 100% 自动 |
|
||||
| **5. YouTube 自动化发布** | Chrome CDP 自动化（注入文件、填充简介、勾选公开） | 32.4 秒 | ✅ 100% 自动 |
|
||||
| **6. 多语种字幕处理** | 大模型批量翻译（8 语 × 56 句）+ CDP 自动上架发布 | 48.6 秒 | ✅ 100% 自动 |
|
||||
| **全流程总计** | **从音频文件到油管 8 语公开发布** | **约 5.3 分钟** | **98% 自动化** |
|
||||
|
||||
4 分钟视频的渲染阶段在我们的工作站上用时 **218.3 秒**（约 3.6 分钟），随后的入库、发布与 8 语字幕处理约 1 分多钟。在分镜留白侧确认无误后，后续全链路无需任何人工交互。
|
||||
|
||||
---
|
||||
|
||||
## 2. 整体系统架构
|
||||
|
||||
整个自动化系统分为四个完全解耦的层级：
|
||||
|
||||
@@ -28,7 +50,7 @@ draft: false
|
||||
[原始 MP3 音频 + 文本歌词]
|
||||
│
|
||||
▼
|
||||
1. 声学起唱对齐（Whisper 词级微秒时间戳 -> 校准 LRC + SRT）
|
||||
1. 声学起唱对齐（Whisper 词级时间戳 + 声学起唱校准 -> LRC + SRT）
|
||||
│
|
||||
▼
|
||||
2. 动态 React 视频合成（Remotion 1080P 30fps）
|
||||
@@ -49,11 +71,11 @@ draft: false
|
||||
|
||||
---
|
||||
|
||||
## 2. 解决歌唱声学字幕对齐难题
|
||||
## 3. 解决歌唱声学字幕对齐难题
|
||||
|
||||
AI 歌唱音频中普遍存在拖音、转音、颤音和节奏弹性拉伸。如果直接用常规语音转写工具识别，伴奏强烈的鼓点和乐器声往往会导致整句唱词被漏掉。
|
||||
|
||||
为了实现微秒级咬字对齐，管线采用了**基于已知歌词的声学起唱对齐（Forced Acoustic Onset Alignment）**：
|
||||
为了让咬字对齐落在**渲染帧**这一级，管线采用了**基于已知歌词的声学起唱对齐（Forced Acoustic Onset Alignment）**：
|
||||
1. 以人工确认的标准歌词作为基准锚点；
|
||||
2. 调用本地 `faster-whisper` 并开启词级时间戳（`word_timestamps=True`）；
|
||||
3. 针对每行歌词，锁定首字真实发音起振的能量起跑点，校准字幕起止点。
|
||||
@@ -62,7 +84,7 @@ AI 歌唱音频中普遍存在拖音、转音、颤音和节奏弹性拉伸。
|
||||
|
||||
---
|
||||
|
||||
## 3. Remotion 留白侧人物避让算法
|
||||
## 4. Remotion 留白侧人物避让算法
|
||||
|
||||
在采用插画背景的 MV 中，一个常见痛点是歌词遮挡画面主角。如果某一镜小仙女画在画面右侧，歌词依然居中或靠右就会直接盖在人物脸上。
|
||||
|
||||
@@ -85,7 +107,7 @@ const getSideX = (idx: number) => {
|
||||
|
||||
---
|
||||
|
||||
## 4. 远程 YouTube CDP 上传通道
|
||||
## 5. 远程 YouTube CDP 上传通道
|
||||
|
||||
视频在本地 Windows 工作站上渲染，而已登录 YouTube 账号的浏览器运行在 DSM NAS 上的独立 Docker 容器（`chrome2`）中。
|
||||
|
||||
@@ -104,7 +126,7 @@ cdp.send("DOM.setFileInputFiles", {
|
||||
|
||||
---
|
||||
|
||||
## 5. 经验与教训
|
||||
## 6. 经验与教训
|
||||
|
||||
- **渲染与发布必须解耦**：早期版本尝试过一边渲染一边推流或直接向浏览器传 buffer，编码器稍有波动就会导致浏览器连接重置。先在磁盘写出完整 MP4 再通过归档传输，两道环节互不牵连，容错率极高。
|
||||
- **合成前必须进行九宫格审查**：正式渲染全片前，先生成一张全分镜缩略拼图快速校验，肉眼确认每一张图的留白侧标记完全吻合，避免全片渲染数分钟后才发现有一处文字挡了人物。
|
||||
|
||||
Reference in new issue
Block a user