047、直播录制丢帧、音画不同步?实时 TS 切片写入、Buffer 缓冲与降级策略

047、直播录制丢帧、音画不同步?实时 TS 切片写入、Buffer 缓冲与降级策略 047、直播录制丢帧、音画不同步?实时 TS 切片写入、Buffer 缓冲与降级策略一、凌晨三点,线上告警:录制文件全是“鬼畜”上周三凌晨,我正睡得迷糊,手机震得跟按摩棒似的——线上直播录制模块大面积告警。用户反馈回放视频音画不同步,有的干脆卡成PPT,更离谱的是某场重要直播的录制文件,播放器直接报“无法解析”。我打开监控面板,看到录制任务的丢帧率飙到15%,音频时间戳和视频时间戳的差值已经超过2秒。这问题我太熟了。直播录制不像点播,源流是实时推送的,网络抖动、编码器负载、磁盘IO瓶颈,任何一个环节出问题,都会让TS切片写入变成一场灾难。更恶心的是,很多问题在测试环境根本复现不了——因为测试环境没有真实用户并发,没有那种“突然涌入10万观众”的流量冲击。二、TS切片写入:你以为的“实时”其实是“伪实时”很多人写直播录制,上来就开个线程,收到RTP包就解析成PES,然后直接往文件里写。这种写法在实验室里跑得挺欢,一上生产就原形毕露。TS(Transport Stream)的设计初衷是广播级传输,它的包结构固定188字节,每个包都有PID标识,PCR(Program Clock Reference)用来同步时钟。但问题在于:直播源的时间戳不是均匀到达的。编码器可能因为场景复杂度变化,突然丢出几个大I帧,或者网络抖动导致B帧晚到几百毫秒。我见过最蠢的写法是这样的(别笑,真有人这么干):