品味应用（Taste Application）

品味应用（Taste Application） 是做什么的？

管道的后半部分。品味蒸馏将参考素材测量成风格包；此处根据该风格包生成并剪辑结果。

执行与交付合约

原始实现位于 scripts/ 中；无需单独的 ito-video 检出。安装 scripts/requirements.txt 以进行本地处理。仅当在提供商上执行时安装 scripts/requirements-live.txt。实时上传、提交和下载需要显式设置 TASTE_FORGE_ALLOW_LIVE=1以及凭据；仅针对用户授权的运行设置。--dry-run 无需凭据，并生成带标签的占位符。不明确的提供商超时不会作为新的付费作业重试。在决定是否再次提交之前，请检查提供商的请求。

无需任何提供商调用即可使用现有的已完成镜头：

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 中记录。提交前编译简报和风格方向；不要假设断开的模式字段会影响模型提示。在付费运行前，针对实际提供商验证当前端点字段。

对于 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道具并将其放回视频中
• 验证成品是否实际匹配其参考素材

分工

**模型提供内容、运动、构图和光照结构。风格包提供颜色和节奏。**这是测量得出的，而非风格偏好——请参阅品味蒸馏以了解具体数字。实际后果：

• 生成提示包含零颜色语言。添加 “颜色：无。渲染中性。后期进行调色。”
• 保持两个独立的标志：--brief（描述发生什么：主体、动作、地点）和 --style-steer（描述外观）。合并它们会将风格词泄露到场景中（“青色”变成青色物体），并将主题词泄露到调色中。
• 模型对局部、可检查的规则的反应远优于全局规则。“背景纯黑无光；主体向白色过曝”有效；而“极高对比度”则无效。

生成连续镜头，而非独立镜头

“匹配节奏”的直接理解是一个镜头一次生成。这在经济上是荒谬的。一个平均每镜头0.78秒的参考素材，针对一个最低4秒的端点，将10秒的作品变成 12次调用、生成48秒，仅使用10秒（21%效率），以及12个不相关的剪辑拼接成本应是连续的作品。

编辑通常会拍摄较长的连续镜头并在其中进行剪裁。将镜头分组为约5秒的连续拍摄：3次调用、13秒生成、77%效率，以及真正属于彼此的连续镜头，因为它们来自同一次生成。

告诉模型你想要什么形状，否则它会渲染一个缓慢的锁定推进镜头，而其中的六次剪裁看起来像卡顿：

“作为一次连续拍摄，内部无硬剪裁。它将在编辑中被剪成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 无参考到视频功能	v3 系列仅支持文本/图像/运动控制；参考到视频功能位于 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 对于同样的5秒，价格大约是 Kling o3 的4倍。它在多参考保真度（最多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。 响应中包含一个 thumbnail PNG 和一个 model_urls 块以及 model_glb；取第一个URL仅在键重新排序前有效，而预览PNG可以正常下载——直到Blender拒绝打开它之前，一切都不会失败。
• 请求PBR贴图。 没有它们，网格看起来像涂漆的纸板。
• 进行重拓扑，如果有人会编辑或绑定它。生成的网格密集且混乱。
• 本地渲染以闭环。 一旦转台变成帧，它就成为素材，而所有下游阶段都已处理素材——对其进行分级、剪辑、作为元素合成，或作为条件参考上传。当二进制文件在PATH中时使用Blender；保持一个轻依赖的软件光栅化器作为默认选项，因为无头GL上下文是容器中最常缺失的东西，而只能在工作站上工作的渲染器不构成管道的一部分。

验证后再相信

每个其他阶段都声称有结果。检查它，并且检查分布形状，而不仅仅是矩：

• background — 低于L*10的画面比例对比风格包的数值。与参考素材比较，而非源素材：一个68%黑色的生成源比任何参考素材（24–55%范围）都更黑，因此“保留源的黑场”要求了错误的事情，并同样会原谅一个被提亮的调色。
• chroma_mae — 每分区a*/b*误差，使用中位数（匹配风格包目标的测量方式；这里的均值将偏差敏感的统计量与稳健的统计量进行比较，并报告定义不匹配为错误）。
• contrast / black_point / white_point
• banding — 在被占用的直方图区间之间的空白 L* 直方图区间。计算总空白区间数行不通：一段合法的暗色素材会有空白的高光区间。
• cadence — 检测到的平均镜头长度对比参考素材的。

注意单位陷阱：OpenCV根据数据类型更改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

生成 → 蒸馏 → (mint3d) → 应用 → 制作 → 验证。阶段1-3是缓存的，因此在简报上迭代时永远不会重新测量任何内容。--dry-run 为每个网络调用创建桩：计划、提示、轨道布局和清单仍会被测试。

反模式

不要做	原因
每镜头一次生成	21%效率，12个不相关的剪辑
在提示中添加颜色	经过测量无效；偏离了LUT所需的中性基础
流复制剪裁	仅关键帧边界会破坏亚秒级节奏
连续剪裁基础视频	重新组装原始视频；每个剪裁不可见
相信 compose 可以叠加	它不能；它会拒绝第二个轨道
向 compose 发送秒数	静默缩短1000倍
仅凭MAE交付	请同时加入背景占比检查

借用的素材会带有采集应用的UI

在一个交付剪辑中发现的最严重缺陷：完成的视频包含了别人的点赞按钮、观看计数器和评论气泡，因为基础视频……

……[已截断以供翻译]