Files
hoelee-blog/src/content/posts/zh/uploading-large-videos-to-youtube-via-cdp.md
T
hoelee f32ae90cf0
Deploy / build (push) Successful in 39s
fix(posts): correct the 3 video posts after consultant review, with fresh artwork
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.
2026-10-22 19:29:26 +08:00

10 KiB
Raw Blame History

title, description, pubDate, updatedDate, category, tags, ogImage, banner, draft
title description pubDate updatedDate category tags ogImage banner draft
用 CDP 自动化上传百兆视频到 YouTube:跨越 DevTools 内存墙的 Docker 归档法 了解如何使用 Docker Archive API 将大型视频直接送入容器文件系统,再通过 CDP 秒级挂载,彻底避免将百兆文件经由 WebSocket 慢速传输挤爆浏览器。 2025-08-22 2026-10-22 devops
docker
cdp
playwright
youtube
portainer
automation
/og/zh-uploading-large-videos-to-youtube-via-cdp.jpg /banners/uploading-large-videos-to-youtube-via-cdp.jpg false

在前端自动化与爬虫开发中,通过无头浏览器或 Chrome DevTools Protocol(CDP)来提交表单、抓取数据或上传几百 KB 的图片通常十分顺畅。然而,当你试图在自动化流程中将一个 100MB 以上的高清 1080P 视频通过远程 CDP 自动上传到 YouTube 时,常规的浏览器自动化方案几乎一定会崩溃。

本文记录这个让远程自动化频繁掉线的内存陷阱,以及如何通过轻量优雅的 Docker 归档模式(Docker Archive Pattern)实现百兆大视频的稳定秒级注入。

TL;DR —— 不要把上百兆字节塞进 CDP 的 WebSocket。Docker Engine API 的 PUT /containers/{id}/archive?path=…(这里走 Portainer)把文件打成 tar 直接解进 Chrome 容器的文件系统,再用 DOM.setFileInputFiles 把容器内路径交给网页。千兆局域网下 130 MB 落盘 1.89 秒。这一篇是 全自动 MV 生成流水线 的落盘那一半;渲染层相关的转场与低频抽动排查见 排查 Remotion 视频抽搐。


1. 什么时候该用哪种文件上传方案

在动手写代码前,先理清四种常见方案的适用边界:

方案 适合场景 权衡与取舍
Playwright setInputFiles() 同一台机器上的本地 Chrome 实例 挂接系统原生文件选择器。跨远程 WebSocket 传输大文件极易内存溢出或超时。
CDP DOM.setFileInputFiles 文件已经存在于 Chrome 宿主机/容器内部 耗时仅 2 毫秒,网络零内存开销,但本身不具备跨机器传文件的能力。
Docker Archive API (/archive) 把文件注入已有容器,免配 SSH/NFS/卷挂载 原生 tar 流式导入,快速自包含,适合带外落盘。
YouTube Data API v3 后台纯无头服务,拥有 Google Cloud 服务凭据 支持官方断点续传,但每日免费配额极紧(每次上传消耗 1600 单位,每天最多传 6 个视频),且很多 YouTube Studio 独占设置(如特定多语种 CC 字幕、音频轨道)API 无法完全覆盖。

为什么这里选择 CDP 而不是官方 Data API?

YouTube Data API 默认每天只有 10,000 单位配额,上传一个视频扣除 1,600 单位,一天上传 6 个视频就会触发限流配额耗尽。此外,官方 API 对外挂多语种字幕的授权和上传要求频繁更新的 OAuth2 授权圈子。在已有登录态的自托管 Chrome 容器中通过 CDP 驱动,不仅零配额限制,还能 100% 保持与人工在 YouTube Studio 点击完全一致的行为体验。


2. 50MB 远程浏览器协议陷阱

在控制本地 Chrome 时,Playwright 或 Puppeteer 使用 page.setInputFiles("input[type=file]", local_path)。浏览器直接从当前机器的物理磁盘中读取文件句柄,操作极其平稳。

但在自托管 Homelab 或生产部署中,为了让 YouTube、电商等带有登录态的账号 7x24 小时保持在线且不污染日常桌面,我们通常将 Chrome 运行在 Synology NAS 或 Linux 服务器的 Docker 容器中。

当我们在外部工作站或 CI 流水线上运行脚本,试图跨网络通过远程 CDP 将视频推给容器里的浏览器时,问题接踵而至:

  1. Playwright 会尝试通过 WebSocket 协议将巨大的二进制文件转为 Base64 或分片推流;
  2. 庞大的数据帧直接挤爆 WebSocket 协议栈缓冲区,两端内存激增;
  3. 远程浏览器随之报出 Target closed 崩溃退出,或者由于帧超时直接断开连接。

即使你费尽心思调大 WebSocket 参数,跨协议在网络上传输上百兆视频依然极其脆弱。


3. 破局思路:本地文件路径直接注入

核心思路的转变其实非常直观:如果视频文件本身就已经保存在容器内部的磁盘里,Chrome 根本不需要走 WebSocket 网络把数据传过来。

当 /config/Downloads/video.mp4 已经落在容器文件系统内时,CDP 提供了一个原生且完全不消耗协议内存的底层指令:

cdp = context.new_cdp_session(page)
doc = cdp.send("DOM.getDocument")
file_node = cdp.send("DOM.querySelector", {
    "nodeId": doc["root"]["nodeId"],
    "selector": "input[type='file']",
})

# 耗时仅需 2 毫秒,且在浏览器 WebSocket 上传输 0 字节:
cdp.send("DOM.setFileInputFiles", {
    "files": ["/config/Downloads/video.mp4"],
    "nodeId": file_node["nodeId"],
})

于是,真正的工程问题转变为:如何无需繁琐的 SSH 密钥或挂载庞大卷,就能将一个 130MB 的文件在 2 秒内送入容器内部?


4. Portainer Docker Archive 归档注入法(生产强化版实现)

每个 Docker 守护进程原生暴露了一个容器归档接口: PUT /containers/{id}/archive?path=/path/in/container

在 Synology NAS 或 unRaid 环境下,Portainer 会将此 Docker socket API 封装在统一的 API Key 鉴权之后:

PUT http://<host>:9000/api/endpoints/2/docker/containers/{container_id}/archive?path=/config/Downloads

以下是带有完整异常捕获、入参校验与安全权限的生产级 Python 脚本:

import io
import os
import tarfile
import urllib.error
import urllib.request

PORTAINER_KEY = os.environ.get("PORTAINER_API_KEY", "")
PORTAINER_BASE = "http://192.168.1.1:9000/api/endpoints/2/docker"
CONTAINER_ID = "2dc0fb6a11c7"  # 目标 Chrome 容器 ID

def stage_file_to_container(local_path: str, dest_filename: str) -> None:
    if not PORTAINER_KEY:
        raise ValueError("未检测到 PORTAINER_API_KEY 环境变量")
    if not os.path.exists(local_path):
        raise FileNotFoundError(f"本地文件不存在: {local_path}")

    size = os.path.getsize(local_path)
    tar_stream = io.BytesIO()

    # 在内存中打包 tar(对于拥有 16GB+ RAM 的工作站,100-200MB 媒体文件完全安全可控)
    with tarfile.open(fileobj=tar_stream, mode="w") as tar:
        with open(local_path, "rb") as f:
            ti = tarfile.TarInfo(name=dest_filename)
            ti.size = size
            # 0o644:文件属主可读写,其他组只读(严禁赋予全局可写 0o666/0o777)
            ti.mode = 0o644
            tar.addfile(ti, f)

    tar_stream.seek(0)
    data = tar_stream.read()

    endpoint = f"{PORTAINER_BASE}/containers/{CONTAINER_ID}/archive?path=/config/Downloads"
    req = urllib.request.Request(
        endpoint,
        data=data,
        headers={
            "X-Api-Key": PORTAINER_KEY,
            "Content-Type": "application/x-tar",
        },
        method="PUT",
    )

    try:
        with urllib.request.urlopen(req, timeout=120) as resp:
            if resp.status not in (200, 204):
                raise RuntimeError(f"Archive PUT 请求失败,HTTP 状态码: {resp.status}")
        print(f"成功将 {dest_filename} ({size / (1024 * 1024):.2f} MB) 注入容器!")
    except urllib.error.HTTPError as e:
        body = e.read().decode("utf-8", errors="replace")
        raise RuntimeError(f"Portainer 接口返回错误 {e.code}: {body}") from e

运维注意事项与安全清单

  1. 客户端 RAM 内存开销:虽然 Chrome 端彻底消除了内存尖刺,但 io.BytesIO() 会在当前 Python 脚本进程中驻留整份 tar 镜像。如果要处理数 GB 的大型视频归档,应先将 .tar 写入临时文件,并通过 requests 或 urllib3 以流式分块形式上传。
  2. 目标目录必须预先存在:Docker Archive API 是直接解包到 ?path= 指向的目录中。如果目标容器内部缺失 /config/Downloads 目录,接口会直接返回 404/500,而不会自动创建父级目录。
  3. API Key 与 CDP 端口暴露风险:Portainer API Key 与未鉴权的 Chrome DevTools 端口(默认 9222 或 9242)都拥有宿主或容器等效的最高执行权限。切勿将这两个端口直接映射到公网 IP(0.0.0.0),务必严格限制在内网隔离桥或套在双向 TLS / Authentik SSO 之后。

实测性能读数

在千兆局域网环境下实测:

  • 128.85 MB 视频成片(.mp4):从发起请求到容器解包就绪,耗时 1.89 秒(固态硬盘存储);
  • Chrome 容器内存占用:所有浏览器标签页均观察不到额外内存峰值;
  • WebSocket 流量:DevTools 协议通道 0 字节负载。

5. YouTube Studio 上传流程自动化

当视频和自定义封面都已安静地躺在容器内部的 /config/Downloads/ 下,Playwright 只需要通过 CDP 驱动页面向导:

  1. 挂载主视频:获取主上传框 input[type='file'],调用 DOM.setFileInputFiles 传入容器视频路径;
  2. 填充标题与描述:定位 contenteditable 输入区域,自动输入预生成的 SEO 标题与详细简介;
  3. 挂载封面缩略图:通过 DOM.getDocument 重新拉取动态注入的 DOM 树,获取 input[type='file']#file-loader 节点,挂载 /config/Downloads/cover.jpg;
  4. 受众选择:勾选 VIDEO_MADE_FOR_KIDS_NOT_MFK;
  5. 跳过向导检查:连续点击 #next-button 进入发布选项;
  6. 公开可见性与发布:选中 PUBLIC,点击 #done-button 即可完成发布。

因为文件在容器磁盘上本地可读,YouTube Studio 以最饱满的网络带宽直推谷歌服务器,全程无一次断流或卡顿。


6. 核心总结

  • 严禁在 CDP 的 WebSocket 通道传输大型文件:远程浏览器不是为了在内存中缓冲几百兆媒体流而设计的;
  • 带外落盘先行:使用 Docker Archive PUT 接口,利用 Docker 原生机制以极高速度直接将文件推入容器文件系统;
  • 容器内部路径秒挂载:通过 CDP 的 DOM.setFileInputFiles 直接指定容器路径,实现零内存损耗、零失败率的文件绑定。