八个平台档位其实只有五组分辨率

2026-08-09

看到「支持 8 个平台的输出档位」这种说法，第一反应通常是「那就是 8 套参数」。OpenMontage 的 README 里确实有这么一张 Platform Profiles 表，8 行。但把这 8 行的分辨率列拉出来去个重，只剩 5 个值。

这不是挑刺，是件挺实用的事：它决定了你实际需要关心的输出参数有几套。

先把这张表原样摆出来

README 的档位表逐行照抄如下：

Profile	Resolution	Aspect Ratio
YouTube Landscape	1920x1080	16:9
YouTube 4K	3840x2160	16:9
YouTube Shorts	1080x1920	9:16
Instagram Reels	1080x1920	9:16
Instagram Feed	1080x1080	1:1
TikTok	1080x1920	9:16
LinkedIn	1920x1080	16:9
Cinematic	2560x1080	21:9

8 行，第二列去重后是 5 个值：

1920x1080（16:9）——YouTube Landscape 和 LinkedIn 共用
1080x1920（9:16）——YouTube Shorts、Instagram Reels、TikTok 三家共用
3840x2160（16:9）——只有 YouTube 4K
1080x1080（1:1）——只有 Instagram Feed
2560x1080（21:9）——只有 Cinematic

也就是说，横屏两个平台是同一组参数，竖屏三个平台是同一组参数，剩下三个档位各自独占。从这张表本身能读出来的信息只有这两列：分辨率和画幅比。别的什么都没有。

档位名不是参数，是语义标签。它的作用是让你在跟 agent 说话时可以说「我要发 TikTok」而不用说「1080x1920」，至于这个名字在代码里怎么落到具体行为上，仓库里有 lib/media_profiles.py 这个文件，我们没有读过它的实现，这里只能提到它的存在，不做任何描述。

顺着这个去重再往下看一层，会发现一件对沟通有影响的事：在这张表覆盖的范围内，「我要发 TikTok」和「我要发 Instagram Reels」是同一句话——两者的分辨率、画幅比完全一致，YouTube Shorts 也一样。这三家在这两列上不构成任何区别。如果你心里其实是有区别的（比如两个平台你想要不一样的处理），那这个区别在这张表里表达不出来，得换个地方说。README 的这张表没有给出这类区别，我们也不替它编。

另一头，3840x2160、1080x1080、2560x1080 这三组各自只对应一个档位，属于单点值。你要的东西如果不在这 5 组里——比如某个非标尺寸——这张表本身也没写能不能扩、怎么扩。这是这张表的边界，不是这张表的缺陷，摆清楚就好。

落到 `config.yaml`：这张表没给的东西在哪

一张只有分辨率和画幅比的表，显然不足以定义一次输出。剩下的在仓库根目录的 config.yaml 里，output 那一段是这样的：

output:
  default_format: mp4
  default_codec: libx264
  default_audio_codec: aac
  default_resolution: "1920x1080"
  default_fps: 30
  default_crf: 23

六个键。容器默认 mp4，视频编码 libx264，音频编码 aac，分辨率 "1920x1080"，帧率 30，CRF 23。

把这段和上面那张表并排看，有两点值得记住。

第一，default_resolution 的值就是 "1920x1080"，跟档位表里 YouTube Landscape 和 LinkedIn 那一行完全一致。换句话说，你什么都不指定的时候，落到的就是横屏那一组。要出竖屏，是要显式表达的。

第二，帧率、CRF、编码格式这三样不在档位表里。档位表只管画面尺寸，编码相关的默认值统一放在 config.yaml 的 output 段。这意味着 8 个档位在 config.yaml 这一层共享同一套 30 fps / CRF 23 / libx264。这些值在具体渲染时会不会被流水线或工具覆盖，我们没有读过对应代码，不下结论。

所以「8 个档位」这个说法拆开是：5 组尺寸参数 + 1 套共享的编码默认值 + 8 个方便人称呼的名字。你真正需要维护和核对的东西，比「8」这个数字听起来少。

这个拆法的实际好处是省事。你要检查一次输出对不对，不用对着 8 行表格逐行比，只要确认两件事：分辨率落在那 5 组里的哪一组，以及编码相关的三个默认值有没有被你或者流水线改动过。这两件事一件在 README 的表里，一件在 config.yaml 的 output 段里，都是可以直接打开文件核对的纯文本，不需要跑任何东西。

顺带一个容易撞车的同名

档位表里最后一行叫 Cinematic，2560x1080、21:9。而 README 的流水线表里也有一条叫 Cinematic 的流水线，产出是预告片、teaser、氛围驱动的剪辑。

这两个 Cinematic 是仓库里两个不同层面的东西：一个是输出尺寸档位，一个是制作流水线。表述上撞了名字，如实说到这里就够了，我们不推断这是有意为之还是巧合，也不拿它去评价什么。真要沟通的时候，把它说成「Cinematic 这个档位」或者「cinematic 那条流水线」，歧义就没了。

成片形态在第一个阶段就要写清楚

OpenMontage 的每条流水线都走同一套阶段流，README 原文写的是：

research -> proposal -> script -> scene_plan -> assets -> edit -> compose

分辨率听上去像是最后 compose 阶段的事。但翻 pipeline_defs/documentary-montage.yaml 这份 manifest 会看到，跟成片形态有关的一条要求，被摁在了第一个阶段的过闸清单里。这份 manifest 的第一个 stage 是这样写的：

stages:
  - name: idea
    skill: pipelines/documentary-montage/idea-director
    produces:
      - brief
    tools_available: []
    checkpoint_required: true
    human_approval_default: true

tools_available 是空数组 []——这个阶段不调任何工具，纯粹产出一份 brief。但它 checkpoint_required: true 且 human_approval_default: true，第一个阶段就要人批。而这个阶段的 review_focus 里有一条原文是 Duration and shape are concrete（时长和形状要具体）。

这条只有几个词，shape 在这里究竟涵盖哪些东西，manifest 没有展开，我们也不替它定义。能确定的只有一点：这一条要在还没有生成任何素材、还没调用任何工具的时候就写具体，并且过一道人工闸。

跟档位表并排看，两边的信息量是配得上的：档位表把可选项收敛成 5 组尺寸、4 种画幅比（16:9、9:16、1:1、21:9），短到可以在开工前当场念完。至于这张表在代码里由哪一步读、和 review_focus 里那个 shape 是不是同一件事，我们没有读过实现，不下结论。

同一份 review_focus 里，和「时长与形状要具体」并列的还有几条：music plan 和 end-tag plan 都标了 MANDATORY，只有用户显式选择退出才能为空；narration 本身则写的是 OPTIONAL，原文给的理由是音乐、视觉加 end-tag 撑得住调性的话，没有旁白也行。把这几条放在一起读就明白，review_focus 不是一段描述性的说明文，而是一张拿来逐条过闸的清单，「形状」在这张清单上和「必须有配乐计划」是同一等级的东西。

再往前翻一点，这份 manifest 的 orchestration 段里还写了几个上限：max_revisions_per_stage: 3（每阶段最多 3 次修订）、max_send_backs: 2（最多 2 次打回）、max_wall_time_minutes: 60（墙钟时间上限 60 分钟），编排模式叫 executive-producer，这条流水线自带的 budget_default_usd 是 1.00，比 config.yaml 里的全局 total_usd: 10.00 紧得多。这几个数字说明返工次数在 manifest 层面就是有限的，不是想改几轮改几轮。把它和「第一个阶段就要人批、时长与形状要具体」放在一起看，至少能确定一件事：这条流水线留给你反复推翻开头决定的余量，是被写死了数的。至于这是不是刻意设计成配套的，manifest 没有说，我们不猜。

需要说明边界：我们只读了这份 manifest 的前 70 行，scene_plan 之后的阶段和另外 12 份 manifest 都没读过，上面这些字段只对 documentary-montage 这一条成立。这条流水线在 manifest 里自标 stability: beta，它的 default_checkpoint_policy 是 guided，与 config.yaml 里的全局默认一致——顺带说明流水线是可以覆盖全局 checkpoint 策略的。

这张表回答不了的问题

最后把话说死一点，免得读者拿它当完整的发布规格用。

这张表给的是分辨率和画幅比，两列，仅此而已。它没有说各平台的时长限制、码率上限、字幕安全区、封面尺寸，也没有说同一份 1080x1920 的成片发到三个竖屏平台是不是就万事大吉。README 的这张表没写这些，我们也不替它补——需要这些的话，以各平台自己的官方发布规范为准。

它也没有说这些档位在代码里由谁消费、能不能自定义新增。lib/media_profiles.py 这个文件名我们看到了，实现没读，不做推测。

真正能拿走的结论只有一条，而且是可以自己数出来的：8 个名字背后是 5 组分辨率，配上 config.yaml 里 1920x1080 / 30 fps / CRF 23 这套共享默认值。你在跟这个系统对齐输出预期时，需要核对的就是这几个数。

本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、 AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。