相机 S&Q 模式的码率计算与 DSH 页面数据核对
相机菜单里的 S&Q（Slow & Quick）模式常被当成“高帧率拍摄”的同义词，但两者在码率上不是一回事。典型场景是：用 S&Q 拍 120fps 的慢动作片段，回放确实变慢了，可文件体积远小于按 120fps 估算的数值；对照规格表里的码率一栏，又发现它标的是“按拍摄帧率计”。这句话本身自相矛盾——如果真按拍摄帧率计，慢动作文件就该和同帧率常规录制一样大。要判断一个 S&Q 片段到底占多少码率，得先弄清楚它记录的是什么。
两种帧率，两个不同的量
S&Q 模式在机内完成变速，输出的是已经变慢或变快的片段。这里有两个帧率：
- 拍摄帧率（记录帧率）：传感器实际采样的速度，如 120fps。
- 输出帧率（回放帧率）：成片封装进容器的时间基，如 24fps 或 30fps。
码率描述的是单位时间内写进文件的数据量，而“时间”由输出帧率决定。一个 120fps 拍摄、24fps 输出的片段，播放 5 秒对应 600 帧素材，但这 600 帧被摊到 25 秒的回放时长里。文件体积 = 码率 × 回放时长，所以按输出帧率算才对得上。规格表里“按拍摄帧率计”的说法，只有在输出帧率等于拍摄帧率（即不变速）时才成立。
用 DSH 核对实际码率
光看规格表不够，实际码率还受编码器、场景复杂度、码率控制模式影响。在 DSH 里可以用会话记录和投递接口把核对过程固定下来。
先确认 DSH 的本地投递接口可用：
curl -s -X POST http://127.0.0.1:3080/api/dsh-im/delivery/messages \
-H 'Content-Type: application/json' \
-d '{"botId":"probe","targetId":"media-check","text":"S&Q 码率核对开始","format":"plain"}'返回 {"sent": true} 表示受理，否则先排查 DSH 是否在跑、targetId 是否已登记。投递目标写在 deliveryTargets 里，targetId 必须与其中一项一致。
接着把 ffprobe 的输出交给 DSH 会话，让码率数值和帧率一起落进记录。会话文件在 session.v4.jsonl.zstd，事后可以回查每次核对用的参数。对单个片段执行：
ffprobe -v error -select_streams v:0 \
-show_entries stream=r_frame_rate,avg_frame_rate,bit_rate,nb_frames \
-show_entries format=duration,bit_rate \
-of json clip.mp4avg_frame_rate 是输出帧率，format.bit_rate 是容器整体码率，stream.bit_rate 是视频轨码率。把两个帧率和两个码率并排列出，就能看出文件是按哪个时间基在计。若 avg_frame_rate 是 24/1 而拍摄时设的是 120fps，format.bit_rate 就应当落在 24fps 档位的量级，而不是 120fps 档位。
确认与失败判断
核对成功的标志是：avg_frame_rate 与相机菜单里的输出帧率一致，format.bit_rate 与同输出帧率的常规录制处于同一量级，且 nb_frames / (duration × avg_frame_rate) 接近 1。三者对不上，说明取错了流或文件被二次转码。
失败时先看 ffprobe 是否报 Invalid data found when processing input，那是文件头损坏或路径不对；再看 stream.bit_rate 是否为空，部分封装不写单轨码率，此时只能用 format.bit_rate 估算。DSH 侧若投递返回非 sent: true，检查 workspaces.json 里的 deliveryTargets 是否包含该 targetId，以及 format 是否只用了 plain 或 markdown。
边界
这套方法只适用于机内完成变速、输出帧率固定的 S&Q 片段。若相机以“高帧率 + 元数据标记”方式记录、由后期软件解释变速，文件本身仍是拍摄帧率的时间基，码率就按拍摄帧率算，此时 ffprobe 读到的 avg_frame_rate 会等于拍摄帧率。另外，VBR 模式下瞬时码率波动大，单片段数值不能直接外推到整段素材的存储规划，需要多取几个片段看分布。DSH 的接口字段以当前版本为准，升级后先跑一次上面的投递请求确认返回结构未变。
