直播录制缺帧和时长错乱到底是哪一层出的问题

一场开了两小时零七分钟的会议，录制文件拖进播放器，进度条只有 47 分钟；拉到后半段画面还在正常放，时间轴却早就跑到头了。客户第二天要拿这份录像做内部复盘，电话打过来的语气可想而知。处理直播录制缺帧这类事故，我的习惯是把出问题的文件当成飞机黑匣子——不猜原因，只逐层解码，每解开一层就写一条结论。摄行科技的运维手册里，这套流程被固化成了四层。

先说个可能会让人意外的判断：所谓"缺帧"，绝大多数时候画面数据其实一帧没丢，丢的是时间戳的连续性。真正被删掉像素的情况，我这些年遇到的不超过三次。

直播录制缺帧的事故现场先别急着修，先取证

去年冬天，西部一个会展中心的年度供应商大会，会场是临时搭的，走线从舞台侧幕绕到导播房，地上一层地毯胶带，空气里全是新地毯的味道。录制机塞在机柜最下层，风扇进气口对着地面吸灰。会开完，导播说录制正常，绿灯一直亮着。

第二天问题才暴露。我到现场做的第一件事不是修文件，是把原始文件复制三份出去，一份留原样封存，一份给分析，一份给尝试修复用。这个规矩摄行科技吃过亏才立下来的——有同事直接拿工具在原文件上跑修复，写坏了 moov，最后连能读的部分都读不出来了。

取证还包括三样东西：录制机的运行日志、编码器的推流日志、磁盘的 SMART 信息。这三份东西凑齐，后面四层解码才有交叉验证的依据。

第一层解码：容器层，moov 在直播录制缺帧里说了谎

MP4 的时长不是播放器数出来的，是从 moov box 里的 mvhd 读出来的，字段是 duration 和 timescale，一除就是秒数。所以时长错乱最先要怀疑的就是这两个数字。

那份 47 分钟的文件，我用工具把 box 结构打出来，mvhd 里 timescale 写的是 90000，duration 的数值除下来正好 47 分多一点。但把每个 trak 里的 stts 表加总，样本数对应的实际时长是 127 分钟。两边对不上，说明写文件的程序在收尾时算错了总时长。

第一层解码结论：容器头部的元数据不可信，要以样本表为准。这种文件其实不用重录，把 moov 按样本表重建就能恢复完整时长。

还有一种更狠的情况——录制进程被强杀，moov 根本没写完。MP4 的 moov 默认是在文件最后写的，进程一挂，前面几十 GB 的 mdat 数据都在，就是没有索引，播放器直接判定文件损坏。FLV 在这点上反而皮实，它是流式结构，截断了也能从头播到断点。所以我们现在的录制策略是 MP4 和 FLV 双写，或者开启 MP4 的分片模式让索引边写边落。

第二层解码：分片编号断在了重连那一刻

如果录制是靠切片落盘的，第二层就要去看切片序列。正常情况下切片编号是连续递增的，每片时长基本一致，比如都在 5.9 到 6.1 秒之间浮动。

出问题的那次，我把切片列表按编号排开，发现两处断裂：一处从 1187 直接跳到 1203，中间少了十五片；另一处编号没断，但有六片的时长只有 0.4 秒左右，明显是碎片。

对照编码器日志，那两个时间点都有推流重连记录。原因是会场用的临时网络，无线桥接到运营商光纤，中间那台交换机放在配电箱旁边，估计是散热不良偶发重启。重连之后编码器重新握手，序列号从新的基准开始，录制侧按自己的计数器命名，两边就对不上了。

第二层解码结论：编号断裂对应断流重连，缺的那段内容是真的没录到，而碎片切片是重连瞬间的残余数据，合并时必须丢弃，否则会污染时间轴。这一层是少数几种"直播录制缺帧"名副其实的情形——内容确实没落盘，谁来也补不回来。

这里插一句合并的正确姿势。很多人拿命令行把切片首尾相接直接拼，这对时间戳连续的切片没问题，一旦中间有断裂，拼出来的文件必然时长错乱。正确做法是重建时间轴：以第一片的起始时间为零点，按每片的实际时长顺序累加，遇到断裂就补一段黑场或者显式写入间隙，让时间轴保持单调递增。

第三层解码：直播录制缺帧其实丢的是时间戳

这一层是重头戏，也是最容易被误判的一层。

音视频每一帧都带 PTS 和 DTS，在 TS 体系里 PTS 是 33 位、以 90kHz 为单位计数的。算一下就知道，这个计数器跑满一圈大约是 26.5 小时。一般会议撑不到这个时长，但如果编码器不是开播才启动，而是提前一天就在跑，或者做常态化的 7×24 直播，回绕就会实打实地发生。

回绕那一刻，PTS 从最大值突然掉回接近零。播放器和封装器看到时间戳倒退，处理方式五花八门：有的直接丢弃后续帧，表现为"缺帧"；有的按倒退值写进时长字段，表现为总时长变成负数或者奇怪的小数；有的会把这一跳算成一个超长间隔，进度条直接飞到几百小时。

第三层解码结论：先判断时间戳是否单调。把整条 PTS 序列画出来，看有没有断崖式的跳变。如果有，且跳变幅度接近计数器满量程，那就是回绕，处理办法是在解封装时做展开，检测到倒退就给累加一个满量程偏移量，时间轴立刻就顺了。

我一直觉得这条挺反直觉的：文件看起来"少了一大段画面"，实际上帧全在硬盘里躺着，只是被一个错误的时间轴挡住了。摄行科技这几年经手的直播录制缺帧工单里，能靠重建时间轴完整恢复的占了绝大多数，真需要重录的是极少数。

同一层里的两个暗礁：时钟不同源与帧率写错

比回绕更隐蔽的是时钟漂移。录制机和编码器如果各用各的晶振，两边的"一秒"长度就存在微小差异。短时间看不出来，跑够两小时，累积误差能到一秒多。

表现出来就是音画渐进失步，或者多路素材在后期时间轴上首尾对不齐。这个问题的根子不在录制，在同步架构，我们在会议直播的时钟同步凭什么决定多路能不能对齐里专门拆过 PTP 和时间码这两条路。录制机接入统一参考时钟，成本不高，但能省掉后期一大堆麻烦。

另一个暗礁是帧率。有一类时长错算跟网络和时钟都没关系，纯粹是参数写错了。

有些采集源输出的是可变帧率，画面静止时帧率自动降到十几帧省带宽，动起来再回到二十五帧。如果录制端封装时按固定帧率来写，时长就等于总帧数除以标称帧率——实际录了两小时，因为静止段掉了帧，总帧数偏少，算出来的时长自然短。那份 47 分钟的文件里，这一项也占了一部分成因。

处理办法只有一个：录制封装必须按每帧的实际时间戳写入，别用帧计数去推算时间。软件里那个"固定帧率输出"的选项看着省事，遇到可变帧率源就是个陷阱。顺便提一句，转码环节如果也按错误的帧率参数跑，算力会被白白吃掉不少，这笔账在直播转码集群的成本是怎么被算力吃掉的里算过。

第四层解码：磁盘写盘顺序也会造成直播录制缺帧

最后一层往往被忽略，但它是真的会咬人。

录制是持续的顺序写，码率 38.4 Mbps 的四路同录，落盘压力接近每秒 19 MB。这个量级对固态盘不算什么，但如果录制盘同时被拿去做包装素材的读取、被杀毒软件扫描、或者干脆用的是一块跑了三年多的机械盘，写入延迟一抖，录制进程的缓冲区就会溢出，直接丢样本。

那次会展中心的事故里，SMART 信息显示录制盘有 27 个重分配扇区，写入延迟峰值超过 800 毫秒。这是块该退休的盘，被临时抓来顶班。导播机上同时挂着几层动态包装图层，本来就在抢资源，这类连锁反应我在直播包装图层为什么会拖慢导播机里描述过现场表现。

第四层解码结论：录制盘必须独占，不跑任何其他读写任务，开播前看一眼 SMART，重分配扇区非零的盘一律不进现场。这一层导致的直播录制缺帧是最难事后补救的，因为丢的样本根本没进过文件。

排查直播录制缺帧按这个顺序走，别跳步

这张表在摄行科技内部就贴在录制机柜门内侧，遇上直播录制缺帧的报障，从上往下逐行排除，基本不会走冤枉路。跳步最常见的后果是：一上来就怀疑硬盘，把整套存储换了，结果问题出在时间戳回绕上，钱花了问题还在。

一个不太受欢迎的结论

说句可能有点扎心的话：录制文件比原始推流更容易坏。

推流是流式的，坏一段丢一段，后面照样跑；录制是要落成一个完整文件的，容器索引、时间轴、磁盘写入，任何一环出问题都会波及整份文件。换句话说，直播录制缺帧的报障率天然就比直播中断高，只是它不在开播那两小时里发作，没人当场看见。可现实里，大家的注意力全在"直播别中断"上，录制这条线常常连个监控都没有，靠录制机面板上那个绿灯给心理安慰。那个绿灯只代表进程在跑，不代表文件是好的。

所以我们现在的做法是给录制单独做探针：每两分钟检查一次文件体积增量是否在预期区间、切片编号是否连续、磁盘剩余空间是否够撑完全场。任何一项异常直接推告警到导播房的手机上。这类指标该不该进交付报告，直播数据报告应该包含哪些指标里给过一份清单。

直播录制缺帧的日常防线怎么建

技术层面能做的都写在上面了，剩下的是流程。摄行科技现在硬性要求三条：录制双备份，主备两台机器分别落盘且不共用磁盘；开播后第十分钟做一次抽检，把已生成的文件片段真的拖进播放器看一眼；散场前不拆设备，先把文件完整播一遍首尾各三分钟，确认无误再收线。

行业侧的规范也值得对着看一眼。国家广播电视总局公开的相关技术文件对节目录制存档有明确要求，中国通信标准化协会在音视频服务质量方面也有可参考的文件，给客户写交付标准时引用这些，比空口承诺有分量得多。

如果你手上有一批录制文件时长对不上、或者正在为重要会议规划录制方案，可以把编码器型号、录制软件版本、码率配置和存储情况发给摄行科技，我们能帮你做一次录制链路体检，出一份分层排查报告；需要现场保障或者双机备录方案报价的，也可以直接约勘场。别等散场了才发现文件坏了，那时候什么都补不回来。

#摄行科技