【AVD】简述某些视频在线播放时卡顿、本地播放时不卡顿的问题

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

曾经在业务中遇到过这样的问题，我们编码出来的视频在 Android、iOS 端，使用 ijkplayer 内核的播放器播放时卡顿，甚至无法任意定位播放位置，将导致卡顿无法播放。今天，又有同事遇到类似的问题，而我发现，我只写过一个《用 notepad++ 和 Excel 协助分析媒体文件包》，而并没有把当时遇到的问题分析记录下来。于是，在此简单说明一下。

视频文件结构

教科书般的教程、课程中对视频文件结构的描述非常详细，此处不赘述，简单地说，视频文件也是一种文件，是文件，就是一堆二进制数的集合，而且是一个一维的二进制数的集合。因此，视频文件中的视频流、音频流，甚至可能包含的字幕流是如何存放的呢？

答案显而易见，就是那么交织地（interleaved）放着的。通过 ffprobe 相关命令行 ffprobe -i test.mp4 -show_packets 可以看到视频文件 test.mp4 中的各个数据包的存放状态。
如上图所示，这是上述命令的一段输出，用[PACKET]...[/PACKET]区隔，它表示了两个包（packet），简单分析一下这些参数，

• 首先，这两个包都是音频包（codec_type=audio），
• 然后，stream_index=1 表明这两个音频包处于同一个数据流（流1）中，
• pts 的值需要根据 stream info 中的 timebase 换算成 pts_t，
• 而 pts_t 就是我们正常理解的时间，表明了这两个包应该在第124秒左右被渲染展示（presentation）
• dts 跟 pts 一样，是个 int64_t 的值，需要借助 timebase 转换成 dts_t
• 同样，dts_t 就是表明了这两个包应该在124秒左右被解码（decode）
• duration 与 dts pts 一样，是个 int64_t 的值
• duration_time 是表示这个包所需要展示的时长
• timebase = pts_t/pts = dts_t/dts = duration_time/duration = 1/44100 这不是巧合
• convergence 相关的两个参数暂时不清楚啥意思
• size 表明了这个包的数据占有的字节数
• pos 表明了这个包在文件中的位置偏移（offset）
• pos(n) = pos(n-1) + size(n-1) 这也不是巧合
• flags=K_ 表明这是个关键帧，这在视频流中很有用，音频流每个包都有这个标记

dts_t 和 pos

重点关注上述 packet info 中的 dts_t 和 pos 这两个参数，这两个参数，一个标记了这个包应该在什么时间被解码，另一个标记了这个包在文件中的存储位置。因此，当视频文件被播放时，读取文件也是从头到尾一个包一个包地读入，并且送给对应的音频或视频解码器。

因此，我们可以来看看，那些卡顿的视频的数据包中的 dts_t 和 pos 的关系是怎样的。

我拿同事发给我的一个在 Android 端用 ijkplayer 播放卡顿的视频，根据 《用 notepad++ 和 Excel 协助分析媒体文件包》提到的方法，做了个 pos 随 dts_t 变化的曲线，如下：
如果对 stream_idx 进行筛选可知，上面这张图里下面那条线是音频的线，而上面那条线是视频的线。当然，不是很严谨。严谨地说，它的音频流的 pos 随 dts_t 的变化曲线是这样的：

对，后面有极个别的包在很大的 pos 上。从数据上看，是这样的：

它有一个很大的断层。而这个很大的断层中间就夹杂了大量的视频流的包。

这样的话，会有什么样的影响呢？请看着那个分叉了的散点图，我们来分析，播放器开始读取视频准备播放，时间轴是从左向右推进的，但是播放器读文件却是y轴从下向上推进的。这就会有一个问题：假设播放器是按时间从文件中取数据的，就会发现，随着时间的推进，需要在文件中不断地跳来跳去地取数据，它需要跳到比较大的位置上去取一帧视频数据，然后再在一个比较小的位置上去取音频数据。或者，换个思路看，是这样的问题：播放器是按读入的数据进行播放的，那么它将沿 y 轴自下而上地读取数据包，结果，播放器读入了很多音频数据包，却发现暂时用不到这些音频数据包，那么，它就得缓存下来，继续读下个包。尤其是在上面那条曲线的拐点位置，播放器几乎读取了全部的音频数据包，却发现都不是它想要的视频数据包。

这样一来，本地播放的话，如果内存够大，应该问题不大。但是在线播放的话，当在时间轴上定位到一个中间位置，那么网络服务器将从文件的中间位置处开始返回数据报，对应于文件的一个中间位置上，能取到对应的视频包，却找不到与之对应的音频包（同时刻的数据包在文件的较靠前的位置上），于是，要么播放器就一直等待寻找 dts 合适的音频包，要么就只能舍弃音频包静音播放了。于是就卡顿，甚至不能播放了。

能正常播放的视频文件的包的 pos 与 dts_t 的关系应该是这样的：

无论是筛选出音频包还是视频包，或者两者并存的情况下，这张散点图都应该是近似一条曲线的。这样，当用户定位到时间轴（x轴）的任意位置，网络服务器同样 seek 到文件的对应中间位置，然后开始源源不断地返回 interleaved 音视频数据包，客户端这边才能流畅正常播放。

关注封装

那么，如何才能保证，转码或者编码或者压缩后的视频文件里的包，能像上图这样，能正常流畅播放呢？

问题所在就是关注封装，关注封装驱动的对音/视频的选择。如果是用 FFmpeg api，则需要关注的是 avformat，关注 av_interleaved_write_frame() 这个接口的调用。而如果是 MediaCodec，则需要关注的是 MediaMuxer 类中的 writeSampleData 接口。

我们要保证，这个接口写入的包的 dts_t 的信息是连续的，或者单调的。
那么，也就是 av_interleaved_write_frame(AVFormatContext * ctx, AVPacket *pkt) 中的 pkt->dts 根据 stream->timebase 转换成 dts_t 后的 float 值，是连续的，或者单调的。
用 MediaCodec，由于 mediacodec 没有 dts 的概念，在文件中的存放顺序就是解码顺序，所以我们就要关注 writeSampleData(int, ByteBuffer, MediaCodec.BufferInfo) 中的 BufferInfo.presentationTimeUs 这个参数是连续的、单调的。

这里的连续的，是指，我们要拿两个变量来分别记录上次写入的视频包和音频包的这个值，如果这一帧是视频帧，它的 dts_t 或者 presentationTimeUs 大于了上次写入的音频包的这个值，那么写入的下一帧，就得是个音频帧。如果小于，那么就继续写视频帧。
如果这一帧是音频帧，它的值大于上次写入的视频包的这个值，那么写入的下一帧，就得是个视频帧，否则，就继续写音频帧。

也就是说，下一帧要编码视频还是音频，是由封装时写入的包的时间值选择驱动的。如果是多线程编码，则要阻塞视频编码或者阻塞音频编码，是由这个值来决定的。

总之，要保证实实在在往文件中写入操作的这个接口调用时参数中的 pkt->dts 或者 Bufferinfo.presentationTimeUs 是连续或单调的。