品味應用 (Taste Application) 是做什麼的?
管線的後半部。taste-distillation 將參考素材測量為風格包;此步驟則根據該風格包進行生成,並剪輯最終結果。
執行與交付合約
原始實作位於此處的 scripts/ 目錄中;無需另外簽出 ito-video 倉庫。本地處理請安裝 scripts/requirements.txt。僅在提供者執行環境中才安裝 scripts/requirements-live.txt。即時上傳、提交和下載需要明確設定 TASTE_FORGE_ALLOW_LIVE=1 以及憑證;僅在使用者授權的執行中設定。--dry-run 模式無需憑證,並會產生帶有標籤的佔位符。不明確的提供者逾時不會作為新的付費任務重試。在決定是否再次提交前,請檢查提供者請求。
使用現有的完整 take,無需任何提供者呼叫:
python scripts/pipeline.py --genre example --root stylepacks \
--takes media/take-a.mp4 media/take-b.mp4 --duration 12 --fps 30 \
--out out/review-v1.mp4
--duration 是盡力而為的節奏目標,而非精確的執行時間。完整的鏡頭可能會產生較短或較長的剪輯;組合器不會複製片段或添加填充來達到目標。輸出清單會保留實際的 duration 並添加 duration_contract,其中包含請求與實際秒數、不足、超量以及 cadence_target 策略。至少一個輸出幀的差異會明確警告。不提供精確時長模式;當需要精確執行時間時,請檢查收據並在交付前修改或拒絕剪輯。
管線會保留每次執行的分級鏡頭檔案,因為可編輯的 FCPXML 和 EDL 會引用它們。它會拒絕輸出衝突並回報時間軸匯出失敗。已完成的渲染不代表已儲存的編輯器專案或創意已獲批准。在即時編輯前後,請保留原始素材和版本化的專案檢查點;分別記錄儲存路徑和摘要,與記憶體中的時間軸收據區分開。
可供複製的 Fal 圖及其離線輸入編譯器記錄在 workflows/README.md 中。在提交前編寫簡報和風格方向;不要假設一個未連接的 schema 欄位會影響模型提示。在付費執行前,驗證當前端點欄位是否與實際提供者相符。
對於 Blender,請使用完整紋理的來源 GLB;重新拓撲是一個獨立命名的衍生檔,絕不能取代該來源。blender_prop.py 支援明確的 --width 1920 --height 1080 --fps 30 --receipt receipt.json,並保留來自風格包的邊緣光和材質紋理。儲存場景不同於渲染場景;檢查收據的狀態和打包的圖片。
對於 Resolve 疊加層,請使用 taste.resolve.apply_placements,並注入來自明確選擇、有版本控制的目標物體。將 source_end_mode 設定為該主機上驗證過的慣例。不要假設不同 Resolve 版本之間包含相同的來源端點。配接器會在被保留的軌道上分配重疊效果,並在立即放置以及所有附加完成後再次檢查每個放置。複合整數必須與已安裝的 API 相符;對於已驗證的 Studio 21 主機,Screen 是 5,而不是歷史建構者錯誤的 22。收據僅證明記憶體中的放置。儲存專案,驗證其檢查點,然後檢查確切的渲染輸出,再報告交付。
何時啟動
- "製作這種風格的影片" / "套用風格包" / "補充這段素材"
- 將生成的片段組合成具有真實剪輯節奏的作品
- 根據外觀製作 3D 道具並將其放回影片中
- 驗證最終作品是否確實與其參考相符
分工
模型提供內容、動態、構圖和光線結構。風格包提供色彩和節奏。 這是測量結果,而非風格偏好——請參閱 taste-distillation 以了解數據。實際後果:
- 生成提示詞中不包含任何色彩語言。請加入 "色彩:無。渲染為中性。調色在之後進行。"
- 保留兩個獨立的旗標:
--brief(發生了什麼事:主體、動作、地點) 和--style-steer(看起來如何)。合併它們會將風格詞洩漏到場景中("teal" 變成青色物體),並將主體詞洩漏到色調中。 - 模型對局部、可檢查的規則反應遠優於全域規則。 "背景純黑無光;主體往白色方向曝光" 有效; "極端對比" 則無效。
生成 TAKE,而非鏡頭
"匹配節奏" 最直白的解讀是每個鏡頭生成一次。這在經濟上荒謬。一個平均 0.78 秒/鏡頭的參考,對應一個有 4 秒下限的端點,會將一個 10 秒的作品變成 12 次呼叫,生成 48 秒但僅使用 10 秒(21% 效率),以及十二個不相關的片段拼接成應該連貫的內容。
剪輯師會拍攝較長的 take 並在其中進行剪裁。將鏡頭分組為約 5 秒的 take:3 次呼叫,生成 13 秒,77% 效率,以及連續的鏡頭實際上是彼此相關的,因為它們來自同一次生成。
告訴模型你想要的形狀,否則它會渲染一個緩慢的鎖定推進鏡頭,而其中的六個剪輯看起來像結巴:
"拍攝為一個連續的 take,內部無硬切。它將在剪輯中被切成 6 個約 0.8 秒的片段,因此構圖、主體和光線必須持續變化——任何 0.8 秒的視窗都必須能夠獨立成為自己的鏡頭。"
剪輯規則
- 重新編碼,絕不串流複製。 串流複製只能在關鍵幀上剪輯,而在 0.78 秒的鏡頭長度下,每個邊界都會被四捨五入到最近的 GOP——破壞了管線存在的根本目的。
- 補充現有素材時,使用其自身的鏡頭邊界。 將基礎影片切割成連續片段並按順序播放只會重新組裝原始影片:每個 "剪輯" 都落在鏡頭中間且不可見。經測量,一個 20 個鏡頭的組合僅註冊到 12 個檢測到的剪輯。檢測真實的邊界並每隔 N 個取一個,以確保連續選取的鏡頭保證不連續。這將剪輯測量從 1.29 秒移到了 0.83 秒,目標是 0.78 秒。
- 從參考的分佈中取樣鏡頭長度,而不是從其平均值,這樣剪輯就能繼承節奏的變化,而不是變得均勻。
調色規則
- 當你擁有片段時,直接測量優於烘焙 LUT:測量它,匹配其 L* CDF,應用區域色度。
grade_clip_direct達到 MAE 1.58 和對比度 34.0(目標 34.7)。 - 當片段的直方圖與參考不同時,進行錨定,而不是 CDF 匹配。 將一個 68% 黑色的生成片段強制匹配到一個繁忙的參考直方圖會將整個背景提升出黑色:背景保留率降至 26.0%(CDF)對比 69.0%(錨定),而 MAE 和對比度看起來仍然很好。預設使用錨定色調。
- 批次大小很重要。 一次對 48 幀進行調色會導致 OOM 終止進程;6 幀是安全的。
恢復的 fal 平台行為
這些觀察結果和端點範例來自恢復的工作流程。請重新檢查當前端點元數據;它們不對未來的每個提供者版本提供保證。捆綁的圖形範本記錄了單獨驗證過的工作流程輸入,包括顯式的生成音訊控制。
這些發現耗費了真實時間。在設計圖形之前請檢查它們。
| 限制 | 詳情 |
|---|---|
| 完全沒有 3D 渲染器 | fal 有 image-to-3d、text-to-3d、3d-to-3d 而無其他。每個 3d-to-3d 端點都會產生另一個網格。沒有 3d-to-image/3d-to-video 類別,因此鑄造的 GLB 無法 重新進入 fal 影片圖形。請在本地渲染,然後使用 fal-ai/ffmpeg-api/images-to-video。 |
| compose 無法疊加 | fal-ai/ffmpeg-api/compose 拒絕第二個軌道,錯誤訊息為 "Multiple video tracks are not supported"——而且它將 image 軌道視為影片軌道。它只能排列一個影片軌道。使用 ffmpeg 在本地合成。 |
| compose 關鍵幀是毫秒 | 回應中沒有任何說明。以秒為單位提交的執行會被接受,但會回傳一個短 1000 倍的影片。 |
| extract-frame 僅提供第一/中間/最後 | 無任意時間戳。將這三個用作三個不同的條件圖像。 |
| DAG 中無迴圈、無字串拼接 | 每個鏡頭的分支必須逐節點編寫,或保留在本地處理。 |
| Kling 3.0 沒有 reference-to-video | v3 系列僅支援文字/圖像/動態控制;reference-to-video 位於 o3 系列:fal-ai/kling-video/o3/pro/reference-to-video。 |
| 前綴不一致 | bytedance/*、tripo3d/*、meshy/*、minimax/*、openai/* 沒有 fal-ai/ 前綴。kling-video、veo3.1、flux-*、hunyuan-3d、ffmpeg-api 則有。 |
端點選擇
| 插槽 | 最佳 | 替代方案 |
|---|---|---|
| 參考→影片 | bytedance/seedance-2.5/reference-to-video (~$0.473/s @720p) | fal-ai/kling-video/o3/pro/reference-to-video (~$0.112/s) |
| 圖像→3D | fal-ai/hunyuan-3d/v3.1/pro/image-to-3d ($0.375,最多 8 個視角) | tripo3d/h3.1/image-to-3d ($0.20) |
| 文字→3D | fal-ai/hunyuan-3d/v3.1/pro/text-to-3d | tripo3d/h3.1/text-to-3d |
| 重新拓撲 | fal-ai/hunyuan-3d/v3.1/smart-topology ($0.75) | tripo3d/tripo/remesh (便宜約 75 倍) |
| 部件分割 | fal-ai/hunyuan-3d/v3.1/part (僅 FBX) | tripo3d/tripo/segment |
| 文字→圖像 | fal-ai/nano-banana-pro ($0.15 固定) | fal-ai/flux-2-pro ($0.03/MP) |
Seedance 的價格約為 Kling o3 的 4 倍,同樣是 5 秒。它在多參考保真度(最多 50 個混合圖像/影片/音訊參考)方面物有所值,但在僅依賴單張靜止圖像時則不值得。
模型 ID 和價格會變動。在承諾任何模型之前,請至 fal.ai/models 進行驗證。
3D 分支
python mint3d.py --genre <name> --from-stills 4 --retopo --render
python mint3d.py --genre <name> --prompt "a cracked chrome visor" --render
- 首先生成乾淨的基底圖;不要從參考靜止圖中提取。 端點陳述的輸入要求是簡單背景、單一物體、物體佔據畫面 >50%。參考素材正是相反——拼貼、廣角鏡頭、多個主體、燃入圖形——它們會產生雕塑般的雜訊。文字 → 單物體基底圖 → 網格的成本約為 ~$0.15,這是可用網格與被丟棄網格之間的差異。
- 多視圖是按視角命名欄位,而非列表。
input_image_url(正面,必填),然後是back_image_url、left_image_url、right_image_url、left_front_image_url、right_front_image_url、top_image_url、bottom_image_url。沒有input_image_urls也沒有multi_view標誌—— 發明它們會讓每次鑄造降級為單視圖,同時看起來正常。錯誤的角度標籤比省略該視角更糟糕,因為模型信任它。 - 透過鍵來引用 GLB,而非位置。 回應中除了
model_glb之外,還攜帶了一個thumbnailPNG 和一個model_urls區塊;僅使用第一個 URL 只有在鍵重新排序前才有效,而預覽 PNG 下載正常——直到 Blender 拒絕開啟它時才發現問題。 - 請求 PBR 貼圖。 沒有它們,網格的光照就像塗漆的紙板。
- 進行重新拓撲,如果有人將編輯或綁定它。生成的網格密集且混亂。
- 在本地渲染以閉合迴圈。 一旦旋轉台變成幀序列,它就是素材,而下游的每個階段都已經處理素材——為其調色、剪輯、將其作為元素合成,或上傳為條件參考。當系統 PATH 中有二進位檔時使用 Blender;保留一個依賴較少的軟體光柵化器作為預設,因為無頭 GL 上下文是容器中最常缺失的東西,而一個僅在工作站上運作的渲染器不是管線的一部分。
驗證,然後相信
每個其他階段都聲稱一個結果。檢查它,並檢查分佈形狀,而不僅僅是統計量:
background— 低於 L*10 的畫面佔比 vs 風格包的數值。與參考比較,而非來源片段:一個 68% 黑色的生成來源比任何在 24–55% 帶寬內的參考都要黑,因此 "保留來源的黑色" 要求了錯誤的事情,並且同樣會原諒一個被提升的色調。chroma_mae— 每個區域的 a*/b* 誤差,使用中位數(匹配風格包目標的測量方式;使用平均值會將一個對偏斜敏感的統計量與一個穩健的統計量進行比較,並將定義不匹配報告為誤差)。contrast/black_point/white_pointbanding— 在 被佔用 區間之間的空 L* 直方圖區間。計算總的空區間數是行不通的:一個合法暗色的片段有空的亮色區間。cadence— 檢測到的平均鏡頭長度 vs 參考。
請注意單位陷阱:OpenCV 隨著 dtype 改變 Lab 慣例。在 float32 上,L* 是 0–100 且 a*/b* 是有符號的;在 uint8 上,L* 是 0–255 且 a*/b* 是偏移 +128。混合使用會報告數百的色度誤差。
完整鏈
python pipeline.py --genre <name> --refs a.mov b.mov \
--brief "what happens" --duration 12 \
--base-video existing.mp4 --out out/FINAL.mp4
mint → distill → (mint3d) → apply → forge → verify。階段 1–3 已被快取,因此迭代簡報從不會重新測量任何東西。--dry-run 會模擬每個網路呼叫:計劃、提示、軌道佈局和清單都會被執行。
反模式
| 不要 | 為什麼 |
|---|---|
| 每個鏡頭生成一次 | 21% 效率,12 個不相關的片段 |
| 在提示詞中加入色彩 | 經測量無效;偏離了 LUT 所需的中性基底 |
| 串流複製剪輯 | 僅關鍵幀的邊界破壞了次秒級節奏 |
| 連續剪輯基礎影片 | 重新組裝原始影片;每個剪輯不可見 |
| 信任 compose 能疊加 | 它不行;它拒絕第二個軌道 |
| 以秒為單位傳送給 compose | 默默地短 1000 倍 |
| 僅憑 MAE 出貨 | 加入背景佔比檢查 |
借用素材會攜帶錄製應用的 UI
在交付的剪輯中發現的單一最嚴重缺陷:完成的影片包含了其他人的按讚按鈕、觀看計數器和評論泡泡,因為基礎…
…[部分內容因原文截斷而省略]