gtrk 直播切片

直播切片图纸——把一场数小时的直播回放，拆成一批可编辑的逐 clip 粗剪工程（gtrk+剪映+PR），交给用户自己挑、自己改、自己出片。含超长源片分段规约（服务端 2h 硬闸 + 60min 轮询墙钟）、选题清单确认停点、按画面形态配分屏、源片贴片如实告知。当用户想「直播切片 / 直播回放切高光 / 把这场直播剪成短视频 / 三小时直播怎么切 / 带货直播剪片段 / 讲座直播出短片 / 录播切片」时使用本 skill。凡涉及把直播回放拆成一批短片工程，优先用本图纸编排，别直接裸跑 long2short（超过 2 小时会被服务端直接拒）。

gtrk-live-slicing（直播切片 · 组合成片图纸）

把一场直播回放（1–4 小时）变成一批可编辑的逐 clip 粗剪工程：五问定策略 → 分段 → 逐段选段 → 选题清单必停 → 出工程。

定位：第三张 structure 级组合图纸（前两张=gtrk-travel-recap 旅拍解说、gtrk-vlog-docu Vlog 纪实）。不新增任何命令，只编排既有零件。参数细节以 gtrk-long2short 与 --help 为准，本图纸引用不复制；编排次序、分段规约、检查点以本图纸为准。CLI 是手，你是脑。

⚠️ 定位铁律（先读这条，后面全部服从它）

本图纸产的是「粗剪工程」，不是成片。

由此推出一条贯穿全文的边界：MUST NOT 对源片做任何像素级改动。

• ❌ 不去水印、❌ 不去烧录贴片、❌ 不做画面清理美化、❌ 不调色不裁切
• 源片长什么样，切片就长什么样。要不要动那些元素，是用户在客户端二次编辑时的决定，不是你的。
• 分段所需的时间轴裁切必须用 ffmpeg -c copy 流拷贝（不重编码）。
• 工程层设置不算像素改动：变速倍率（--speed-factor）、运镜关键帧（--camera-move）、客户端字幕轨（gtrk subtitle lay）、画布模糊底（gtrk project background）都写在工程里、可在客户端撤销，源片本身一个像素不动——与本条不冲突。

用户只要能直接发的成片、不打算再剪？ 那不是本图纸的活，转 gtrk tool video_long2short_pro（精剪，整片上传、云端渲染、计费约两倍）。判断句同 gtrk-long2short：「剪完还要不要再动？」要动 → 留这儿；不动 → 转精剪。

一、输入契约与开工六问

输入：一条直播回放的本地文件（.ts / .mp4 等均可）。

MUST NOT 执行录制或下载——平台动作与版权责任归用户。用户给什么文件就用什么。

开工前先答六问，答案决定后面全部策略：

#	问	怎么取证	决定什么
①	源片总时长与几何	ffprobe（或直接跑一次 gtrk long2short 让它打印）	要不要分段、分几段（§二）
②	画面形态是否单一	问用户——全程主播口播位？还是含实景走播/换机位？	哪些段开分屏（§四）
③	有无烧录贴片	抽 2–3 帧看（开头/中段/尾段各一）	交付时要如实告知什么（§五）
④	入选切片要不要叠 MG 动画	问用户——缺省不叠（粗剪定位）	选题清单敲定后是否走 MG 车道（§七）
⑤	入选切片要不要加运镜（推拉镜头）	问用户——缺省不加	逐段提交是否带 --camera-move（§七「运镜」）
⑥	入选切片要不要做合成包装	问用户——缺省不做（公约 §三⁵）	选题清单敲定后是否对入选 clip 做精剪包装（§七「合成包装」）；答要时 gtrk composite bake --abi 报烘焙浏览器没装，同一张表里多问一句装不装

②④⑤⑥ MUST 问用户、MUST NOT 代猜。 ②猜错的代价是白跑一轮分屏（几十分钟 + 积分）； ④缺省是不叠——用户没要就零 MG 动作，MUST NOT 硬塞；⑤缺省是不加——用户没要就全程不带 --camera-move、不再追问。 ⑤ 必须在提交前问：运镜是云端任务参数，交上去之后改不了（没入选的 clip 带了运镜也无害，随 clip 一起丢弃）。 ③ 的取证目的只是「告知」，不是「处置」——看到贴片不要动手，见定位铁律。 ② 与 /gtrk-long2short、/gtrk-tools 精剪开工的「多人同框」一问同口径：是就开、不确定按否； 分屏单段最长 8 秒、每条最多 3 处。

推荐面（公约 §三‴）：问答收口时可问一句「要不要看看第三方 skill？」；题材命中场景触发词才定向推荐，读取 gtrk skills recommend --scene <id> --json；用户拒绝后不执行推荐动作。

二、分段规约（本图纸的骨干）

两道闸

	闸	值	命中时的表现
闸一	服务端媒体探测层全局业务限制	2 小时	建单期直接拒：6019 媒体时长无效或超过业务限制。任务不创建、不计费
闸二	CLI 轮询墙钟	60 分钟	轮询超时报错（任务在云端照常跑完，可取回）

处理耗时 / 源时长比值按分屏与否分档：

• 不开分屏：墙钟压力较小；
• 开分屏：处理耗时明显增加，优先按较短段切分。

⇒ 单段 MUST ≤ 2h（硬拒线），开分屏时 SHOULD ≤ 48min（墙钟线）。

判据与做法

源片 > 40 分钟即 MUST 分段。 40 是落在两条线内并留余量的取值。

bash

# 段边界优先级：内容自然停顿（长静音/话题转折）> 等分兜底
# MUST 用 -c copy，MUST NOT 重编码
ffmpeg -ss 3600 -t 2400 -i "<直播回放>" -c copy "<工作区>/inputs/<名>_seg02_60-100min.mp4"

• 命名带上源片时间范围（如 _60-100min），后面汇总选题清单时你要靠它把 clip 定位回原片。
• 有弹幕文件时可用热区微调边界（§六），但不作为主依据。

⚠️ 两条必须在动手前告诉用户

1. 切段是新文件，工程指向它、不指向原片。 逐 clip 工程的 materials[].path 实指切段；用户删掉切段文件，工程就素材脱机。让他把 inputs/ 留着。
2. 超过 2 小时整条提交会被直接拒，不是慢、是拒。好消息是零计费（不进队列），但会白抽白传一个大文件——所以先分段。

超时兜底

单段仍超墙钟时，轮询超时属预期不属故障：

bash

gtrk oralcut-result <task_id> --out <目录>   # task_id 在产物根 task.json；--out 必填

服务端按 task_id 取结果幂等。MUST NOT 重跑——重跑是重复计费。

三、双模式（两种都要停）

为什么直播切片必须停，而口播/TTS 不用？

口播毛片是用户已经讲完的内容、TTS 稿是他已经认可的文本——内容选择在进剪辑链之前就完成了，agent 只是执行。而一场数小时直播里「这几十个候选哪些值得做」尚未发生、本身就是创作决策。全自动跑完 = 替创作者行使了选题权。

模式	停点
快速成片	六问 + 分段方案确认 → 逐段跑 → 【必停】选题清单 → 确认后一路出工程（⑥ 答要时含逐条精剪包装，合成静帧随交付一次给）
逐步推进模式	上述基础上每步都停（分段方案 / 逐段选段结果 / 逐条工程产物）

两模式共用同一套分段规约与参数配方，差别只在停几次，不在停不停。

选题清单长什么样

每段跑完后产物根有 clips.md，一张五列表（标题 / 时长 / 评分 / 简介）。把各段的表合并成一张给用户，标注每条回溯到原片的大致时间，让他勾。真实样例：

#	标题	时长	评分
clip1	别被高认知陷阱害了	5:40	8.5
clip2	孩子情绪稳定靠父母正反馈	3:06	8.2

别让用户自己开工程猜——他要的就是这张表。

四、按形态配分屏（不给一刀切默认）

--split-screen 只对用户在开工②里确认含多人同框的段开。

⚠️ 静默面（务必知道）：段内无多人同框候选时，服务端静默跳过——不报错、不记 errors、不置降级标志。所以：

判断分屏是否真的生效，MUST 看产物证据，MUST NOT 按「没报错」推定。 证据 = report.json 的 split_manifest 条数 + 毛片旁 split_screen/ 目录里的素材（可抽帧看）。

分屏在子轨、主轨原片可回退：分屏素材落在独立子轨上叠放， 主轨的原片全程完整在场——用户对某段分屏不满意时，在客户端隐藏/删除子轨该段即回退原片， 零重跑。交付时把这条回退动线告诉用户。⚠️ 连带边界：本地 gtrk render 是快照渲染、 不合成子轨——渲出来没有分屏画面；要分屏成片走客户端出片（或剪映导出）。

其余参数配方：

• --language 必填，缺失在上传前就报错（省一次白上传）
• 竖屏直播源通常无需转比例，--output-size 缺省即可
• --duration-pref / --max-clip-sec 按投放平台口径给档
• --subtitle-out 产逐 clip 独立 .srt（不烧进画面）——可选，给要拿去 PR 精修的用户；客户端用户走 §七 的字幕上轨
• --speed-factor 只在用户主动要求时加（见 §七「调速」）；开工问询里不问速度
• --camera-move 按开工⑤：用户要运镜才带（见 §七「运镜」），各段一致

完整参数表在 gtrk-long2short，本节只给直播场景的配方差异，不搬手册。

五、贴片如实告知（交付项，不是处置项）

直播源片常自带烧录元素。你的义务是说清楚，不是动手。

类型	后果	怎么说
静态标题贴片（贯穿全场不变）	每条切片都带一个与自己主题无关的标题	举实例给用户看：某条讲 A，画面上却写着 B
时效信息贴片（价格 / 截止日期）	切片再发布时是过期信息	额外点一句，让用户自行判断是否适合再发
无叠加	—	不必提

贴片可能贯穿全场且与切片主题无关，也可能包含会过期的价格或日期；交付时按实际画面如实告知。

这一节不含任何去除动作。 用户问「能不能去掉」→ 告诉他这超出本图纸射程，可在客户端二次编辑时自行处理。

六、弹幕（可选增强，不是必需输入）

真实场景绝大多数没有弹幕——无弹幕是默认路径，不是降级。本图纸主干全部步骤在零弹幕下完整可执行。

用户确实给了弹幕文件时，可以额外用：

• 格式：B站式 .xml 是 <d p="秒数,…">用户:文本</d>，p 首字段即距开播秒数 = 源片时码；平台导出 .txt 通常是时钟列。归一化成「秒 + 文本 + 用户」三元组即可。
• 两个信号：复述密度（同一句话被多个用户在短窗口内重复——观众自发复述的往往就是金句）、刷屏密度（互动符号瞬时峰值）。

⚠️ 别高估它：弹幕对「选哪些段」通常只是辅助

结论：弹幕主要用于验证选段、提取观众原句标题和微调边界，不是必需输入：

• ❌ 不要为了「更准地选段」去要用户补弹幕（没有就没有，主干照跑）
• ✅ 它真正剩下的价值是 取候选标题原句：观众自发复述出来的那句话（如「大脑不接受否定」被 15 人复述）， 往往比 LLM 生成的标题更有传播力。有弹幕时，优先把这类原句作为标题候选给用户挑。
• ✅ 次要价值：微调段边界（别把一个热区从中间切开）。

⚠️ 红线

弹幕 MUST NOT 当 --subtitle-file 喂入。 那个入口收的是主播口述的转写；弹幕是观众文本，喂进去会污染选段依据。

两者都是「带时码的文本文件」、形状极像，极易误用——看到弹幕文件先想这条。

现实诱因实例：某创作者的弹幕就存在名为「文稿」的目录里——目录名叫文稿，内容却是弹幕。别被目录名带偏。

七、二次包装（可选；全部不动源片像素）

看板点名的三件，都不碰源片：

• 标题钩子：文本建议。有弹幕时优先取观众复述的原句。
• 字幕：见下「字幕上轨」——选题确认后对入选 clip 缺省做。
• 模糊底：见下「模糊底」——源片与画布横竖不一致时，对入选 clip 缺省做。
• 封面：走 /gtrk-cover（另出图，不改片）。
• 合成包装：见下「合成包装」——开工 ⑥ 答要才做，只对入选 clip。

合成包装（缺省不做，开工 ⑥ 答要才做，只对入选 clip）

选题清单敲定之后，对每条入选 clip 交棒 /gtrk-composite 做精剪包装（公约 §三⁵：快速成片 auto ≤ 25% → 逐窗口复核 → 构建机检 → 铺轨烘焙，不停；回执列「做了 / 建议了没做 / 烘焙结果」；逐步推进按合成 skill 两个检查点停；开工时用户说了不要就跳过）。clip 工程与整片转写的路径同「字幕上轨」：--gtrk "<产物根>/clip{i}/gtrk/<该 clip 的 .gtrk>" --transcript "<产物根>/json/transcript.json"。合成写在工程里、可在客户端撤销，不动源片像素。

字幕上轨（缺省做，只对入选 clip）

选题清单敲定之后，对每条入选 clip 跑一次（用户明确说不要字幕才跳过；没入选的不做）：

bash

gtrk subtitle lay --gtrk "<产物根>/clip{i}/gtrk/<该 clip 的 .gtrk>" --transcript "<产物根>/json/transcript.json" --language <该段提交时的源语种>

• json/transcript.json 是该段任务落下的整片转写，一份服务该段全部 clip；分了几段就各用各段产物根里的那份。
• --language 跟该段 gtrk long2short 的 --language 一致（英文直播就 en-US），否则云端会按中文断句。
• 交付时说清三件事：① 字幕在客户端字幕轨上，可换样式、可整轨删，不烧进画面；② 云端产出的剪映 / PR 工程是在上字幕之前生成的，不含这条字幕轨，要带字幕的剪映草稿请从客户端导出；③ 用了 --subtitle-file 的段，字幕按行出现、词级时间是近似值（clips.md 会提示）。 打开 PR 工程时的重链提醒照 gtrk-oralcut「回给用户（三端打开方式）」PR/FCP 条，引用不复制。
• 该段产物根里没有 json/transcript.json（老服务端或下载失败，CLI 日志会说）：如实告诉用户这一段没法自动上字幕，其余段照常。MUST NOT 拿弹幕或别的文本凑一份当字幕来源（见 §六 红线）。

模糊底（横竖互转时缺省做，只对入选 clip）

横屏直播切成竖屏（缺省 9:16）时，粗剪工程上下是黑边。选题清单敲定之后，对每条入选 clip 判断源片朝向与该段画布朝向：

• 源片几何：该段 gtrk long2short 日志里的源分辨率，或 ffprobe -v error -select_streams v:0 -show_entries stream=width,height -of csv=p=0 "<源片>"；
• 画布：该段提交时的 --output-size（没传就是 9:16 竖屏）。

朝向不一致（横屏源进竖屏画布，或反之）⇒ 缺省跑（用户说要保持黑边才跳过）：

bash

gtrk project background --gtrk "<产物根>/clip{i}/gtrk/<该 clip 的 .gtrk>" --blur

朝向一致（竖屏直播进竖屏画布）⇒ 不跑。

交付时说清：模糊底写在主轨每个片段上（片段自己画面的模糊副本铺满垫底），客户端里可逐片段或多选批量改成黑底 / 纯色；从客户端导出的剪映草稿带模糊底，Pr 工程降级为纯黑，本地 gtrk render 带；云端随 gtrk long2short 产出的剪映 / PR 工程生成在它之前、不带。强度缺省 200，用户嫌太虚或不够虚可加 --intensity <0–1000 整数> 重跑（幂等覆盖）。零计费、不访问云端。（只想要旧的整片画布设置：--scope canvas。）

运镜（仅当开工⑤用户要了才做）

⑤答「要」⇒ 逐段提交都带 --camera-move（细项如幅度、概率不另开旗标，确有需要走 --params-json '{"camera_move":{"enable":true,"amplitude":0.1}}'）。云端按与精剪同一套调度给主轨片段写推 / 拉镜头关键帧，零渲染、不加价。

交付时说清：

• 运镜写在工程里：客户端与剪映打开可见、可在关键帧面板改或删；本地 gtrk render 与 PR 工程看不到运镜（按静态画面出片），要成片带运镜请从客户端或剪映导出；
• clips.md 每条的「运镜 N 处」是实际写入数，0 处属正常（按概率抽取）；有「未能加运镜的切片」小节就点名告知；
• 之后用 gtrk patch 裁剪 / 切分带运镜的片段，关键帧会跟着调整，不用手改。

调速（只在用户主动要求时）

用户说「切片都加速到 1.2 倍」这类话时，逐段提交带 --speed-factor 1.2（范围 0.5–2.0，保音高）。倍率写进逐 clip 工程，客户端 / 剪映 / PR 打开都按倍率播放，可在客户端逐条改回；交付时把这句告诉用户，clips.md 里若有「未能变速的切片」小节就点名告知。用户没提就全程不加、不追问；要超出 0.5–2.0 的倍率，告诉他在客户端对具体片段拖边变速。

MG 动画（仅当开工④用户要了才做）

• 时机：选题清单敲定之后、只对入选 clip 做——没入选的切片不白做颗粒。
• 姿势：逐 clip 走标准成片化车道（gtrk split 拆分派单 → 颗粒 → gtrk mg 铺轨）， 素材=该 clip 的粗剪工程与 .srt。风格按内容驱动的临场泛化横切原则 （全部成片型图纸通用）：风格必须有，但不锚定既有风格 skill，按当下内容自由泛化。
• 红线：MG 是叠加层，照旧不动源片像素；④答「不要」= 全程零 MG 动作。

B-roll：缺省不掺（明示条款）

直播切片的画面本体就是直播实录，本图纸缺省不派 FILM_BROLL、不推销 B-roll 填充 ——开工问询里也刻意没有这一问。用户主动明确要求给某条切片补空镜时，按通用 gtrk matrix 车道单独走，不改本图纸主干。

八、计费与预算速查（跑前转述给用户）

• 计费基 = 上传物音频流时长（≈源片时长）；单价以 CLI 跑前打印的实时价格为准，本图纸不写数字。
• 分段不改总量：切段总时长≈原片，所以分不分段花的钱差不多，分段买的是「能跑通」和「粒度更细的选题清单」。费用以实时价格和音频时长为准。
• 建单期被拒是零计费的（如超 2h 硬闸）——试探性提交不会烧钱，但会白传一个大文件。
• 任务失败按服务端回执处理；只有回执明确退款时才向用户说明可重跑。
• 先报价再开跑：gtrk long2short <源片或切段> --language <码> --dry-run --json（零抽取、零上传、零计费），把 pricing 里的单价与预估原样转述，长片等用户确认再正式跑；正式运行在抽音频之前也会往 stderr 打同一行「计费提示」。

九、排错

• 超过最大重试次数 → 这句是通用兜底文案；优先检查外部 ASR 查询接口状态。
  • 判据：失败很快（1–2 分钟内就报，而正常 40 分钟段要跑 4–20 分钟）⇒ 卡在开头的转写阶段。
  • 处置：先原样重跑一次。若仍失败，说明故障可能不是瞬时的。
  • 重试仍失败时，别死磕同一段：换个切点重切该时段（边界挪几分钟）、或先跑其他段把能出的先出了， 把这一段单独挂起问客服/换时间再试。MUST NOT 反复重跑——每次都会重新等待，是否退款以回执为准。
  • 别改参数、别一味切更短——那会掩盖问题；先确认是不是 ASR 侧的事。
  • 分段跑的好处在这里体现：只需处理失败的那一段，其余段的成果不受影响。
• 6019 媒体时长无效或超过业务限制 → 单次提交超服务端 2 小时硬闸。分段，别重试。
• 轮询超时 → 不是失败，gtrk oralcut-result <task_id> --out <目录> 取回（§二）。
• 分屏没生效但也没报错 → 正常静默面（§四）。按 split_manifest 与 split_screen/ 目录核实；确无多人同框就是没候选，不是 bug。
• clips 为空 → 该段没有可成片的高光（纯语义选段），看 report.json 摘要给用户解释；直播的垫场/等人段落出现这个属正常。
• 工程打开缺素材 → 多半是切段文件被移动/删除了（§二 警告）。
• 其余症状（部分 clip 失败 / 剪映看不到草稿 / 改工程）→ 一律以 gtrk-long2short 的排错节与 gtrk patch 为准，本图纸不搬。