质量控制 是做什么的？
相关人员应该看到的是作品，而不是技术错误。所有可测量的内容在展示之前都应被测量。无法测量的内容则由一位具备否决权的、眼光敏锐的监督员来检查。相关人员的每条修改意见都会被记录下来，以便下次能够自动发现类似问题。
- 自动质量控制工具是一个准备中的模块。在此期间，所有测量均来自
ffmpeg和ffprobe：相关命令位于 referencias/mediciones.md。 - 已出现过的错误列表，包含其阈值和检查方法，位于 referencias/lista-de-errores.md。
- 包中的
supervisor代理遵循此技能。
1 · 流程
- 在渲染之前，读取作品档案 (
pieza.md)：已批准不可更改的部分和待解决的问题。 - 测量渲染结果 (§ 2)。✘ 项必须在继续之前修正；⚠ 项需通过查看帧来决定。
- 使用
referencia.py分析节奏 (§ 3)。 - 制作控制图： 从作品中选取 6 到 24 个均匀分布的帧，并绘制安全区。逐一检查。
- 如果是修正版本， 将其与前一版本进行比较 (§ 4)。
- 监督员签署“批准”或“更改”意见 (§ 5)。
- 在重新制作任何内容之前，向相关人员展示相同的渲染结果和监督员的意见。
- 交付时附上报告 (§ 9)。
2 · 要测量的项目
| 测量项目 | 阈值 | 不满足时 |
|---|---|---|
| 格式 | 按要求：1080×1920 垂直，1920×1080 水平，1080×1350 feed。仅当要求时使用 4K | ✘ |
| 每秒帧数 | 序列的帧率 (±0.02) 且恒定 | ✘ · ⚠ 如果是可变帧率 |
| 时长 | Reel：最长 40 秒。导出：标记区间 ±1 帧 | ⚠ · 如果是 campaign reel 则阻塞 |
| 缩放 | 任何边缘出现黑边持续 0.5 秒或以上 | ✘ |
| 安全区 (1080×1920) | 两侧各 54 px；可读内容不超过 y 224 且不低于 y 1495；按钮列区域 (从 x 897, y 1228 开始) 必须空闲。水平方向：整个轮廓 96 px | ✘ 如果持续 0.35 秒或以上 · ⚠ 如果是瞬间出现 |
| 完整对象 | 在 Alpha 通道中，没有任何对象触碰画面边缘持续 0.35 秒或以上 | ✘ |
| 黑场 | 第一帧有图像。除有意的淡入淡出外，不允许出现任何孤立黑帧（1 帧） | ✘ 在开头 · ⚠ 在中间 |
| 静帧 | 在应该移动的地方，没有任何画面静止 0.5 秒或以上 | ⚠ · ✘ 如果是 broll 或动画且持续 1 秒或以上或在最后一秒内 |
| 画面不动 | 没有任何 4 秒的窗口无剪辑或运动 | ⚠ |
| 最后一帧 | 存在，非黑场，所有内容在边距内。帧数 = 预期数；音频不超过视频时长 | ✘ |
| 音量 | Reel 集成 LUFS 约为 −15（范围 −17 至 −13） | ✘ |
| 峰值 | 真实峰值 ≤ −1 dBTP；没有采样达到或超过 −0.1 dBFS（削波） | ✘ |
| 静音 | 开头静音不超过 0.3 秒；在有语音的地方，任何低于 −50 dB 持续 0.5 秒的间隙 | ⚠ |
| 音效 | 单独：峰值 ≈ −5.5 dB (上限 −5 dB)。在语音下方：峰值 ≤ −9 dB 且 RMS ≤ −27 dB | ✘ |
| 嘶声 ("chhh") | 没有任何持续宽频噪声：音效中 150 ms，混音中 300 ms。在音效中，最多 20% 的能量在 4 kHz 以上 | ✘ 在音效中 · ⚠ 在混音中 |
| 真实 Alpha | 像素格式包含 alpha (yuva…, rgba…) 且可见 | ✘ |
| 色彩 | 标记为 bt709 且在 TV 范围内。交付时使用 HLG 或 bt2020 | ✘ |
| 导出 | H.264 和 AAC 48 kHz 立体声；码率 30 Mbps 或以上（目标 52 时平均 38–43） | ⚠ |
3 · 使用 referencia.py 分析节奏
用于分解参考片段 的工具也可以测量您自己的渲染结果。它位于包根目录的 herramientas/referencia.py（比此技能高两级目录）：
python3 herramientas/referencia.py <render> --idioma es --salida control/<pieza>-vN-ritmo
读取 analisis.md 并查看 hoja.jpg 和 gancho.jpg：
| 在报告中 | 必须给出 |
|---|---|
| “每多少秒有事情发生” | 4 秒或更短 |
| “最长静止片段持续时间” | 少于 4 秒。如果不是，说明是哪个片段以及将引入什么内容 |
| “最长镜头持续时间” | 3 到 4 秒。更长只应在无法避免的情况下，并能解释原因 |
| 时长 (在“档案”中) | Reel 最长 40 秒 |
gancho.jpg (0.1 到 3 秒) | 你会为此停下手指吗？在 0.5 秒前有意料之外的事情发生，并在 3 秒内能理解故事 |
| “集成音量” | 与 § 2 测量结果一致 |
- 镜头内信息变化或摄像机缓慢移动不计为新镜头。切换到不同缩放、角度或想法，则算。
- 在无剪辑的动画中，“1 个镜头”不是错误：其节奏体现在“视觉变化”上。
- 如果作品源自参考，将其数据与已批准的概念进行比较。
4 · 与前一版本比较
修正不能使已经获得认可的版本变得更差。
- 在修正前，读取
pieza.md中已批准不可更改的部分。 - 之后，将新版本与前一个版本进行图像和音频比较（命令在 mediciones.md 中）：
- 在要求修改的区间之外（有 0.25 秒容差）必须保持一致；
- 在区间内，必须发生变化：如果没有任何改变，则说明问题未解决；
- 若时长改变，其后的所有内容都可能产生偏移。
- 在要求范围外发生的变化，要么是有意为之并在交付时说明，要么是回归性错误，需在展示前修复。
- 每条修改意见都必须在其对应新版本的帧上检查，并严格按照要求解决，不得自行解释。
整帧比较无法发现细微变化（例如，仅占画面 5% 的标识、110 px 的遮挡物、修正后的字幕）：请在这些位置放大至实际尺寸比较两个版本。修正通常破坏的内容列在错误清单的“回归”部分。
5 · 监督员
监督员与制作人员掌握相同的信息，但以全新的眼光审视作品：制作者往往看不到自己的失误。监督员不做任何修复：只负责查看、测量和签署意见。
接收 渲染结果、其类型（reel, broll, alpha, 效果, 封面等）、序列帧率和 pieza.md。如果是修正版本，还需接收前一版本、要求修改的区间以及带有精确秒数的修改意见。如果缺少任何信息，需在签署前找出。
审查方式：
- 根据作品的内容、展示和时长来识别，而不是文件名。
- 读取
pieza.md、修正档案 (§ 6) 和错误清单。 - 进行测量 (§ 2)。如果出现 ✘，则直接判定为“更改”，无需进一步讨论。
- 首先询问作品是否吸睛，其次才是是否符合规范 (§ 3)。
- 检查控制图，将可疑的秒数、每个剪辑点和每个已解决修改意见的秒数放大至全尺寸查看。
- 如果是修正版本，进行比较 (§ 4)。
- 检查数据和文字：不得出现虚构的数字、名称或事件。
严重程度：
- 阻塞性： 出现了 ✘；在正常速度下可读的私人数据；相关人员已修正过的错误；超过 40 秒的 reel；无法让人停下手指的钩子；没有理由超过 3–4 秒的镜头。
- 警告： 除此之外的所有情况，包括标准问题（仅在暂停时可见的 1 帧闪光、多余遮挡物）。由相关人员决定。
迭代轮次：
- 第一次审查： 一次性地给出所有发现的问题及其严重程度。
- 第二次： 仅检查其阻塞性问题以及与前一版本的比较。前一版本已存在但未发现的新问题，视为其首次审查的失误：以警告形式提出。
- 第三次： 如果没有任何阻塞性问题，则签署“批准”并附带警告。
- 绝不随意提高标准。重新审查耗时少于 5 分钟。
签署意见 对照现行规则。如果作品早于某项规则，则同等情况计为错误，并标记为“渲染后生效”。在将黑场或静帧判定为错误前，检查其是否为有意的从黑场进入。
判决：批准 | 更改
更改内容：1) 0:04,2 · 问题描述 · 规则 (ID) · 阻塞性 | 警告；2) …
已检查：测量、节奏、控制图 (n 帧)、放大的全尺寸帧在 …, 与 vN 的比较、已解决的修改意见 …
该签署意见仅针对当前渲染结果：如果文件更改，则需重新测量并签署。
6 · 修正档案
correcciones.md，位于工作目录中。监督员在每次审查前都会阅读此文档：这样其标准与相关人员同步。
- 在相关人员审查时， 即时记录每条修改意见：
时间 · 更改内容 · 原因 · 保留内容。首先阅读保留内容。 - 当天内， 每条可重复出现的错误修改意见都应转化为规则，包含编号和验证方法：
COR-12 · AAAA-MM-DD · 一个镜头最长 4 秒 · 测量：“最长的镜头”来自 referencia.py · 来源：“我觉得一个素材剪辑持续 8 秒太长了”，reel X v3 - 如果与之前的规则冲突，则采用新规则：修正旧规则，不应同时保留两条。
- 同时记录首次即批准的内容，以及监督员认为可视或可保留的内容：这些同样不应被否决。
- 如果相关人员发现了监督员未发现的问题，监督员应提议将其添加入清单。
- 监督员不应捏造偏好。如果某问题明显错误但未在清单中，则要求修改并说明原因：这样清单才能不断增长。
7 · 不应破坏的原则
- ✘ 项必须修正，不得争辩。 一个可测量的错误若被相关人员看到，会使其浪费时间去修正本不该出现的低级错误。
- 测量正确不等于批准。 一个仅带警告就批准的版本曾因“太长”（52 秒）和“无聊”（同一部手机持续 31 秒）而被退回。
- 修正应只触及要求修改的部分。 顺手重做曾导致手工完成的工作丢失，并损害了已获批的内容。
- 如果要求更改一个属性，则只更改该属性。 “降低黑色的不透明度”曾被解读为“移除栏目”，而事实并非如此。
- 相关人员批准或选择的内容，不应因监督员的细节问题而重做： 应通过一行询问解决。针对已让相关人员信服的内容连续三次否决，既浪费金钱也浪费时间。
- 如果相关人员在场，由其监督。 代理仅在相关人员不在时介入。
- 在重新制作之前， 相关人员应看到与监督员相同的内容及监督员的意见：否决了什么、在哪一秒、提出了什么建议。相关人员可能不在乎该否决，而且每轮迭代都有渲染成本。对于相关人员已提出的要求，无需询问直接执行。
- 每部作品最多 2 到 3 个版本。 遇到相同类型的第二次否决，或遇到标准问题，应暂停并以选项形式提问。曾有一晚因监督员不断提高标准而产生了 8 个版本。
- 每个版本仅重做发生更改的部分。 曾有一次因局部更改而将 45 分钟的视频全部重新渲染。
- 重新审查仅检查被否决的部分。 一次完整的审查迭代需要 12 到 17 分钟，消耗 300 到 400k tokens。
- “做完最后一个更改就完事” = 修复该问题，测量，展示，结束。不再进行另一轮否决。
- 随口提及的评论不是命令。 一句“我不太喜欢这个”曾导致一个已批准的内容被更改，渲染结果被拒：只修复要求的内容，其他保持不变；最多提供一次修改选项。如果相关人员已关闭某个议题，不再重开。
- 生成内容应从已批准的版本开始。 从已获得认可的图像出发，仅更改要求的部分。在连续两次无方向的拒绝后，不会盲目进行第三次：应说明理解的内容，并要求提供一张图像或一句话。如果相关人员改变主意，则以最后说的为准。
- 如果说某物已打开或在屏幕上，请核实。 曾宣布四个打开的草图，但实际上并不存在。
8 · 技术陷阱
nb_frames在 ProRes 中不可靠：它计算的是数据包 (-count_packets)。- 使用
-shortest合并音频会吞掉 1 到 4 帧：请使用精确时长 (-t)。 - 标签“4444”不保证 Alpha 通道：像素格式必须以
yuva开头。 ffmpeg -ss t返回从 t 开始的第一帧：对于帧 f，请使用 t = (f − 0.25) / fps。- QuickTime 和快速预览会改变色彩：应与编辑器的帧进行比较，而非肉眼。
- 安全区应在文本背景段测量：明亮的素材会干扰整帧测量。
- 转录会将第一个单词对齐到 0.0，并在下一个单词内部插入长暂停：紧随暂停之后的内容应通过能量来测量。
- 编辑器会缓存被覆写文件的时长和音频：每个版本都应使用新文件名。
- 以每秒 4 帧的速度读取文本会跳过闪烁：为确保隐私，应使用每秒 10 帧。
9 · 交付内容与验证项目
- 交付报告： 路径、时长、区间、实际平均码率、测量结果（含数据）、节奏、监督员意见、与前一版本的比较以及遗留问题。
- 在
pieza.md中，“控制”部分：vN · 测量结果 (错误和警告) · 监督员 (意见及理由)。 - 每个版本使用新文件名 (
v2,v3…)：保留前一版本以便比较。 - 未经相关人员请求，不得发布或发送任何内容给任何人。