品質控制
客戶應該看到的是作品，而不是基本錯誤。所有可測量的項目在展示前都必須測量。無法測量的部分則由一位具有新鮮眼光與否決權的主管檢查。而且，客戶的每個修正意見都會被記錄下來，以便下次自動偵測到。
- 自動化的品質控制工具目前是一個正在準備中的模組。在此期間，每項測量都來自
ffmpeg和ffprobe：相關指令在 參考資料/測量.md 中。 - 已經出現過的錯誤列表，包含其閾值與檢查方式，在 參考資料/錯誤列表.md 中。
- 套件中的
supervisor代理會遵循此技能。
1 · 流程
- 在渲染之前，先讀取該片段的規格文件 (
pieza.md)：已核准不得更動的部分，以及待解決的備註。 - 測量渲染成果 (§ 2)。✘ 的項目必須修正後才能繼續；⚠ 的項目則透過檢查影格來決定。
- 使用
referencia.py測量節奏 (§ 3)。 - 製作控制表： 從影片中選取 6 到 24 個均勻分佈的影格，並畫上安全區域。檢查每個影格。
- 如果是修正版本， 與前一版本進行比較 (§ 4)。
- 主管簽署「已核准」或「需修改」 (§ 5)。
- 在重新製作任何內容之前， 將同一個渲染成果與主管的意見一起展示給客戶。
- 連同報告交付 (§ 9)。
2 · 測量項目
| 測量項目 | 閾值 | 若不符合標準 |
|---|---|---|
| 格式 | 依訂單需求：1080×1920 垂直、1920×1080 水平、1080×1350 動態消息。僅在要求時才使用 4K | ✘ |
| 每秒影格數 | 與序列一致 (±0.02) 且為常數 | ✘ · ⚠ 若為變動幀率 |
| 時長 | Reel：最長 40 秒。匯出檔：為標記區間 ±1 影格 | ⚠ · 在宣傳 Reel 中為阻塞性錯誤 |
| 黑邊 | 任何邊緣出現黑邊 0.5 秒或以上 | ✘ |
| 安全區域 (1080×1920) | 兩側各 54 像素；上方 224 像素內、下方 1495 像素內不得有可讀文字；按鈕欄 (從 x 897, y 1228 開始) 需保留。水平：四周各 96 像素 | ✘ 若持續 0.35 秒或以上 · ⚠ 若僅瞬間出現 |
| 完整物件 | 在 Alpha 通道中，任何物件觸及畫面邊緣 0.35 秒或以上 | ✘ |
| 黑畫面 | 第一個影格必須有影像。不允許非預期的黑畫面（單一影格），除非是刻意設計的淡入淡出 | ✘ 在開頭 · ⚠ 在中間 |
| 凍結畫面 | 在應該有動作的地方，非預期靜止 0.5 秒或以上 | ⚠ · 在 B-roll 或動畫中，若持續 1 秒或以上，或發生在最後一秒，則為 ✘ |
| 靜止太久 | 任何 4 秒無剪輯或無動作的視窗 | ⚠ |
| 最後一個影格 | 必須存在、非黑畫面、且全部在邊界內。影格數 = 預期數；音訊時長不得超過影片時長 | ✘ |
| 音量 | Reel 的整合 LUFS 約為 −15 dB (允許範圍 −17 到 −13) | ✘ |
| 峰值 | 真實峰值 ≤ −1 dBTP；不得有任何樣本達到 −0.1 dBFS 或更高 (失真) | ✘ |
| 靜音 | 開頭靜音不得超過 0.3 秒；在有人聲處，不得有 0.5 秒低於 −50 dB 的空隙 | ⚠ |
| 音效 | 單獨存在時：峰值約 −5.5 dB (上限 −5)。在語音下方時：峰值 ≤ −9 dB 且 RMS ≤ −27 dB | ✘ |
| 嘶聲 | 任何持續的背景噪音：在單一音效中 150 毫秒，在混音中 300 毫秒。在單一音效中，4 kHz 以上能量最多佔 20% | ✘ 在音效中 · ⚠ 在混音中 |
| 真實 Alpha | 像素格式包含 Alpha (yuva…, rgba…) 且 Alpha 通道中有可見內容 | ✘ |
| 色彩 | 標記為 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 像素的修補、修正的字幕)：請用兩個版本的原始尺寸裁剪區域來檢查這些位置。修正版本常破壞的項目，列於錯誤列表的「回歸」章節。
5 · 主管
主管與製作人員擁有相同的背景知識，但以全新的眼光看待作品：製作者往往看不到自己的錯誤。主管不做修正：只檢查、測量並簽署。
接收 渲染成品、其類型 (reel、broll、alpha、效果、封面等)、序列的 FPS 和 pieza.md。如果是修正版本，還要包含前一版本、指定的修改區段以及帶有精確秒數的備註。如果缺少任何資訊，請在簽署前先查找。
審查方式：
- 根據內容、畫面和長度來識別片段，而不是依賴檔案名稱。
- 閱讀
pieza.md、修正記錄檔 (§ 6) 和錯誤列表。 - 進行測量 (§ 2)。只要有一個 ✘，結論即為「需修改」，無需進一步討論。
- 第一個問題是 片段是否吸引人，其次才是是否符合規格 (§ 3)。
- 查看控制表，並放大至全尺寸檢查有疑問的秒數、每個剪輯點以及每個已解決備註的對應秒數。
- 如果是修正版本，則進行比較 (§ 4)。
- 檢查數據和文字：不得有錯誤的數字、名稱或案例。
嚴重性分級：
- 阻塞性： 任何 ✘；以正常速度播放時可辨識的個人資料；客戶已修正過的相同錯誤；長度超過 40 秒的 Reel；不會讓人想暫停觀看的鉤子；無正當理由長達 3–4 秒的鏡頭。
- 警告： 其餘所有事項，包括主觀判斷問題 (例如，只有暫停時才能看到的單影格閃爍、過多的修補)。這些由客戶決定。
審查輪次：
- 第一次審查： 一次性提出所有發現，包含嚴重性分級。
- 第二次審查： 僅檢查阻塞性問題以及與前一版本的比較。如果出現前一版本已存在的問題，則視為主管在第一次審查時的疏失：記錄為警告。
- 第三次審查： 如果沒有留下任何阻塞性問題，則簽署「已核准」並附上警告。
- 絕不提高各版本之間的標準。重新審查時間應少於 5 分鐘。
簽署 時需對照現行規則。如果片段在規則制定前完成，錯誤仍應記錄，並標註「渲染後發生」。在將黑畫面或凍結畫面判定為錯誤前，請先確認是否為刻意設計的開場黑畫面。
VEREDICTO: APROBADO | CAMBIOS
Cambios: 1) 0:04,2 · qué está mal · regla (ID) · bloqueante | aviso; 2) …
Mirado: medidas, ritmo, hoja (n fotogramas), fotogramas a tamaño completo en …, comparación con vN, notas resueltas …
此簽署 僅適用於該特定 渲染成品：如果檔案變更，則必須重新測量並再次簽署。
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…)：保留前一版本以便比較。 - 在客戶要求之前，不得發布或發送任何內容給任何人。