seek 先挑入口,要准就多解一段

拖进度条,跳过去只是第一步;跳到之后从哪一帧开始解,才是这条路上真正费心的事。落点上可能压着一条真 IDR,可能只有 open-GOP 的恢复点,也可能落在 P、B 帧中间——三种落点三种起步方式,挑错了就是冻住的画面或者几秒黑屏。这篇讲落点的三档入口、默认关着的精确 seek 选项,还有播放中换软硬解时那一下怎么接。素材多来自高清修复版片源:超长的图像组,甚至整条流没有一个真 IDR。

seek 跳过去只是第一步,从哪一帧开始解才是关键。这篇讲落点的三档入口、默认关着的精确 seek,以及换软硬解时渲染这一侧怎么接。

落点分三档:真 IDR、恢复点、丢弃到下一入口

先看翻车长什么样。有些重封装过的片源,seek 完画面直接冻住,帧队列一直是空的;另一些黑几秒才恢复,恢复的同时错误日志刷屏。根因都在起步那一下:视频里真正能独立解码的只有 IDR 帧,修复版转码为了压体积把图像组拉到二十秒以上,极端的整条流只有 open-GOP 的恢复点、没有一个真 IDR。落点落在一组中间,解码器就从缺参考的状态起解,帧号断档会一路延续,解出来的有效帧持续是零。

所以 seek 之后不能急着把包喂给解码器,先看落点上是什么。我把它做成源侧的一道闸,保护期内逐包过,按优先级挑入口:

第一档最干净:组内有真 IDR,把数据截断到它起步。组首 NAL 不可信,判新帧的启发式会把 IDR 切片误判成「没起新帧」而并进前一组,所以要做的是全组扫描随机访问 NAL,找到就把组截断到它——截掉的前导 B、P 切片本来就缺参考,喂进去只会产出灰帧。

第二档是容器标出的关键帧组,也就是 open-GOP 的恢复点,直接当入口放行。它不保证解出干净画面,但配合下面的两个前提,恢复期很短,开头一小段花屏可以接受。整条流没有真 IDR 的片源,只能走这一档。

第三档是落点踩空,落在 P、B 帧中间,通常是容器索引本身有问题。这一档先丢弃,一直丢到下一个能用入口出现。丢弃比解码快得多,但也不能无限丢:万一遇到真的一条关键帧都没有的流,丢满五千包就放行,免得永远黑屏。

判据用容器索引的关键帧标记,但这里要分容器看。mkv 索引里标的关键帧是封装器认定的可跳转点,包括恢复点,可信;有的容器给所有包都打关键帧标记,拿来当判据就全乱了。所以这道闸只在 h264、h265 上开,用位流里的 NAL 语义复核容器标记,mkv 那种可信的索引才被采信。

三档之外还有两个前提,是这类片源能用的底线。一是解码器容许输出坏帧:缺参考的帧也吐出来,靠后续正常的参考帧自愈,而不是整条流卡死。二是音频有保护期,等视频的第一个 I 帧出现才放行音频包——seek 之后音频先跑起来、画面还冻着,错轴的感觉很明显,这条把两头钉在一起。

精确 seek 是默认关着的选项

三档解决「从哪起解」,还有一个方向:显示的第一帧,要不要正好落在目标位上。

默认是快进式:落点在哪个关键帧上,就从那一帧显示,画面起点可能离目标差一段,但不多解一帧。精确模式反过来:从入口帧开始静默解码,时间戳还没到目标的帧一律丢掉,第一个不早于目标的帧才显示。它默认关,按需打开,命令行播放器留了对应的参数。

实现落在两端。视频这端在帧入队之前丢:时间戳还没到目标的帧不入队,第一个达标的帧自动解除丢弃,冲刷时复位。音频这端在源侧丢目标之前的包;纯没有时间戳的包要放行——音频的时间本来就可以不由包携带,没戳的包靠解码出来的采样数往下推,丢掉反而挖坑。

代价在另一头:二十秒的图像组,开精确模式软解要黑一到三秒才能到目标位,这段是在静默解码、还没轮到显示;这是这类片源的固有成本,不是哪一处的缺陷。还有一条边界来自容器索引:索引稀疏时,落点可能已经越过目标,往回退不动,丢弃条件就不成立,只能从落点直接播,退化成快进式。索引决定上限,播放器补不了。

验证两种模式真落在不同帧上,判据不能看界面:截图文件名里的位置,在 seek 过程中会被钉在目标值上。可靠的是解码日志里第一帧实际解出来的时间戳。同一片源同一次 seek,目标在十二秒多、落点约十秒:快进式首帧时间戳是十秒,精确式是十二秒多,比目标晚两毫秒。

换软硬解那一下,渲染跟着重建

播放中把软解换成硬解,做法是解码器关掉重开;时机与重建归解码接入那一篇,这里只补渲染这一侧的两件事。

一是渲染对象要跟着解码器一起重建。软解交出来的是内存里的帧,硬解交出来的是纹理,两边的帧队列形状都不一样,渲染侧拿着旧的一套接不住新的一套。这也要求解码、渲染、窗口三者分开——窗口只管显示,不然动一下就会牵到窗口。

二是重建解码上下文的时候,设备本身不动。硬解设备是解码和渲染共用的一台,Windows 那一篇写过它怎么建、怎么交出去复用;重建上下文时把已有的硬件缓冲挂回去,设备保持原样,共享纹理那条互拷的路才不会断。

流的分辨率、采样率中途变了,要做的也是重建,直接复用这同一条路,不另写一条。

引擎 avox 在 GitHub 开源,仓库 xxxzhou/avox。

系列《从零做一个全平台播放器》按施工顺序发,本篇是 6.1;已发各篇收在这里:https://cloud.tencent.com/developer/column/109457

上一篇:5.5 不改 WebRTC 一行,给源与编码器各接一个适配器 https://cloud.tencent.com/developer/article/2780806