探索移动端音视频与GSYVideoPlayer之旅 ｜ Agora Talk

Posted 2022-02-13 涂程

作者：恋猫de小郭

基础知识

首先是基础知识，本次分享在这一块会占据很大比例，为什么要和大家聊音视频的基础知识？这就又要考古我很久前的一个经典 issue ，如图所示：

在维护 GSYVideoPlayer 这 5 年多的时间里，关于类似的基础的问题其实收到不少，只是这个比较典型，而处理这些问题的流程都是类似，举个例子，我收到最多的视频播放问题应该是

“播放黑屏，播放失败，xxx能播为什么GSY不能播？”

每次遇到这种问题的时候，我都会问：

“视频编码是什么？”

而很大概率我收到的回复就是 ：

MP4

之后就需要进一步去解释： “MP4 不是视频编码，要如何去查看视频编码…” 这样的一个流程。

所以关于音视频的基础常识，也是我最经常科普的内容，这部分内容其实也很多，这里就挑选一部分常见或者我比较经常解释的给大家分享。

封装

如图所示，一般情况下，视频流从加载到准备播放是需要经过解协议、解封装、解编码等这样的过程，其中：

• 协议指的就是流媒体协议；
• 封装是的是视频的封装格式；
• 编码又分为视频编码和音频编码；

常见的协议一般有 HTTP 、RTSP、RTMP 等，其中最常见的就是 HTTP 网络协议，而 RTSP 和 RTMP 一般用于直播流或支持带有控制信令的场景，比如远程监控；当然 HTTP 也有可以支持直播的，比如 HLS （也就是我们常见的 m3u8）。

视频封装协议指的是我们常见的 MP4 、AVI 、RMVB 、MKV、FLV 等常见后缀格式，它们所表示的就是多媒体的封装协议，就是在传输过程中把音频和视频打包都一起的封装，所以播放前是需要把这部分内容解开，提取出对应音频编码和视频编码。

所以可以看到，前面我们说过的 MP4 属于封装格式，它的作用主要是把视频编码和音频编码后的文件塞到一起，这是为了方便传输和存储，所以播放前一般需要解开这层封装，从而得到我们需要的音频轨和视频轨。

音频编码

音频编码指的是音频数据的编码方式，常见的如：MP3、 PCM、WAV、AAC、AC-3 等，因为音频的原始数据大小一般不适合直接传入，比如原始大小一般可以按照 采样率 * 声道数 * 样本格式 去计算，假设视频的音频采样率是 44100 、样本格式是 16 bit 、单声道、24 秒，那么它原始音频大小应该是

44100 * 16 * 1 * 24 / 8 ≈ 2MB

而实际将音频信息提取出来的大小大概只有 200 多K，这就是音频编码的作用。

所以一般都会音频传输会采用各种编码格式进行压缩和去冗余，其中比如没什么压缩的 WAV/PCM 编码的音频质量会比较好，但是体积会比较大；MP3 有损压缩能在音频质量还可以的情况下压缩音频的体积；AAC 也是有损压缩，但是又有分有 LC-AAC、HE-AAC等。

举个例子，正常我们耳感受声音的频率范围是 20Hz-20kHz，在 MP3 编码时，其中就是就截掉了大量的冗余信号和无关的信号。

视频编码

视频编码指的就是画面图像的编码压缩方式，一般有 H263、H264、HEVC（H265）、MPEG-2 、MPEG-4 等，其中H264 是目前比较常见的编码方式。

通常情况下我们理解的画面是 RGB 组合出来，而目前视频领域可能更多使用 YUV 格式，其中 Y 表示的是亮度（灰度），而 U 和 V 表示的是色度（饱和度）。

“Y”表示明亮度，也就是灰阶值，“U”和“V”表示的则是色度，描述影像的色彩及饱和度，用于指定像素的颜色。

最常用的表示形式是Y、U、V都使用8个字节来表示；Y的取值范围都是16～235，UV的取值范围都是16～240，这个取值范围是为了防止传输过程中信号变动造成过载等，也就是后来的 YCbCr 。

举个例子， YUV 最常用的采样格式是 4：2：0 格式， YUV420 可以理解对色度以 2：1 的抽样率进行存储。

YUV 420 并不意味着不采样 V 分量，而是 4个Y 分量共享一组 UV，然后亮度透过色度来显示画面，更多 YUV 的这里就不展开讨论，而为什么使用 YUV 其中有一点因素就是为了兼容以前的黑白电视。

为什么不直接用原始 YUV ？这里假设上面的 MOV 视频直接使用 YUV420 的格式，那么一帧的大小就会是：

1080 * 1920 * 1 + 1080 * 1920 * 0.5 = 2.9MB ，这里省去了换算，简单就是 Y = width * height; U = Y / 4；V = Y / 4；

----------------------
|     Y      | U|V |
----------------------

可以看到 YUV 420 采样的图像，已经比 RGB 图像节省了一半的空间，但是如果在这个基础上，算上帧率（30）和一个视频的时长（一小时），那一部视频原始大小就会是天文数字，这样的情况明显不符合网络传输，所以才有了视频编码用于压缩图像。

有了视频编码的存在，视频编码的作用就是对传输图片进行压缩，从而达到尽量还原画面的同时，得到更小的体积。

接下来就介绍最常见的视频编码的基础概念：

• 1、IPB 帧是一种常见的帧压缩方法，其中 I 帧属于关键帧是每个画面的参考帧； P 帧是前向预测帧；B 帧是双向预测帧。简单来说就是 I 帧自己就可以得到一个完整画面，而 P 帧需要前面的 I 帧或者 P 帧来帮助解码得到一个完整画面，而 B 帧则需要前面的 I/P 帧或者后面的 P 帧来协助形成一个画面。

所以 I 帧是很关键的存在，压缩 I 帧就可以很容易压制掉空间的大小，而压缩 P/B 帧可以压缩掉时间上的冗余信息。而一般在视频 seek 的时候，I 帧很关键，如果视频 seek 之后发生往前的跳动，那很可能就是你的视频压缩得太厉害了。

• 2 还有一个叫 IDR 帧的概念，因为 H264 采用的是多帧预测，导致 I 帧不能作为独立的观察条件，所以多出一个叫 IDR 帧的特殊 I 帧用于参考，IDR 帧最关键的概念就是：在解码器过程中一旦收到 IDR 帧，就会立即清空参考帧缓冲区，并将IDR帧作为被参考帧。

IDR 帧说白了就是立刻刷新，这样如果出现一些异常画面，也不会让不因为连续导致传播，从 IDR 帧开始重新算一个新的序列开始编码，比如 IDR 帧 之后的 BP 帧都不能引用它之前的 I 帧。所以 IDR 帧一定是 I 帧，但是 I 帧不一定是 IDR 帧。

• 3、在视频解码里还有一个叫 DTS（Decoding Time Stamp） 和 PTS（Presentation Time Stamp）的存在，DTS主要用于视频的解码，PTS主要用于在解码阶段对视频进行同步和输出。

因为视频包里面数据解码不是连续的，而是需要通过解码数据源得到的 DTS，才决定以包应该在什么时候被解码，而得到的PTS 决定了解码后的图片什么时候被绘制。

• 4、GOP（Group Of Picture）就是两个 I 帧之间的距离，一般 GOP 设置得越大，图像压缩效率越高，但那时需要解码的时间就会越长。 所以如果码率固定而 GOP 值越大，P/B帧 数量会越多。

可以看到，视频编码很大程度都是在去除冗余，也就是单独的数据包是无法自己组成画面的，它需要对应关联的数据辅助才能实现完整的渲染，所以解码的顺序不代表着画面的顺序，是 I 帧就是最关键的参考点。

讲了上面这些常见的基础知识之后，还有两个特殊又常见的基础点想顺便简单地介绍下：HLS 和 RTSP 。

M3U8

一般情况下 HLS 和 M3U8 是指一个东西，HLS(HTTP Live Streaming) 指的是苹果开发的基于 HTTP 协议的流媒体解决方案，它可以在普通的 HTTP 的应用上直接提供点播和直播的能力。

在 HLS 里会将视流文件切分成小片(ts)并建立索引文件(M3U8)，常见情况下视频流编码会是 H.264，音频流编码为 AAC。

M3U8 的特殊在于，它是通过先获取索引文件，之后获取每个 ts 文件进行播放，例如你把一个 M3U8 链接放到PC浏览器，它很大程度可能不会支持播放，而是下载下来一个 M3U8 的文件。

虽然大家一直叫它 M3U8，但是其实它的格式是 M3U，然后编码格式采用的是UTF-8，所以合起来是 M3U8，它是一个纯文本的文件，文件里有许多的 tag 组成，常见的有：

• #EXTM3U： 必备的tag，标识该文件是 M3U；

• #EXTINF： 每个 ts 媒体文件的持续时间，单位是秒，仅对其后面的 URL 有效；

• #EXT-X-TARGETDURATION： M3U文件中最长的 ts 时长，单位是秒，上面 #EXTINF 中的时间长度必须小于或是等于这个最大值，只能出现一次；

• #EXT-X-KEY：表示加解密的作用，后面会详细聊一聊它。

• #EXT-X-PLAYLIST-TYPE：可选项，如果是 VOD 则服务器不能改变整个 ts 文件列表；如果是 EVENT 则服务器不能改变或是删除 ts 文件列表中的任何部分，但是可以向该文件新增内容；

• #EXT-X-ENDLIST： 表示到末尾了，它可以在中任意位置出现，但是只能出现一个；

• #EXT-X-MEDIA： 常用在多语言版本，比如多个不同的音频语言；

• #EXT-X-STREAM-INF： 用于嵌套 M3U8, 例如提供多个不同码率的 M3U8 播放链接；

• #EXT-X-MEDIA-SEQUENCE： 唯一的序号，相邻之间往下+1, 如果没有则默认为0；这个后续也会讲到作用；

所以播放 M3U8 格式的视频，首先需要获取到索引文件，然后解析对应的 tag ，然后得到一个 PlayList 去播放，而在维护 GSYVideoPlayer 的这段时间里，接收到关于 M3U8 最多的问题之一其实是：加密。

前面我们介绍过，通过 #EXT-X-KEY 这个 tag ，可以实现 M3U8 的加密播放，一般格式是

#EXT-X-KEY：METHOD=<method> [,URI=<uri>][,IV=<iv>]

在 M3U8 里，加密方式一般是 AES-128 加密，具体到 ExoPlayer 里就是 AES-CBC-PKCS7Padding。

为了大家更好地了解这部分加密的了逻辑，就有必要介绍下 AES / CBC / PKCS7Padding 这三个的组成，简单来说，一般加密过程就是:

• 加密：Padding -> CBC加密 -> Base64编码
• 解密：Base64解码 -> CBC解密 -> Unpadding

PKCS7Padding

首先是 PKCS7Padding，因为在使用 AES 做加密时，有时候数据可能会不满足一个块，也就是不对齐，而 PKCS7Padding 故名思义就是填充一些字节进入，从而到达每个块都是一样大小的结果。

对于 PKCS7Padding， 如果数据的大小不是指定块大小的整数倍，则添加字节直到它成为整数倍，每个添加进去字节的值是添加的字节总数。

是不是有点绕口，举个例子，如果消息比 16 的整数倍少了 3 个字节，则就会填充三个 0x03 字节添加到块的末尾。

对于 PKCS7Padding，如果数据已经是块大小的整数倍，则将整个 0x15 块（16 个 0x15 字符）添加到消息末尾。这是为了得到校验和，表示在解密期间已到达消息的末尾，并且没有更多数据跟随，我们也可以默认读取最后一位，来得到要剥离的字节数。

除了常见的 PKCS7Padding ，还有一个叫 PKCS5Padding，它的不同之处在于它仅针对使用 64 位（8 字节）块大小的块密码进行了定义，也就是块大小为固定的 8 。

CBC

CBC 就是是先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密，也就是下一段内容和上一段有关系，在 M3U8 里也有类似交 IV 的参数。

IV 一般是 0，如果没有IV（Initialization Vector，则使用序列号作为IV进行编解码，将序列号的高位赋到16个字节的buffer中，左边补0。

第一个块使用初始化向量 (IV) 或 16 字节随机值加密，下一个块使用它来启动加密过程。每个后续块都使用来自前一个块的密文以一种称为密码块链接 (CBC) 的方法进行加密。

AES

AES 作为对称加密，它加密和解密用相同的密钥。

另外 AES为分组密码，把明文数据分成一组一组的，每组长度相等，每次加密一组数据，直到加密完整个明文。

AES标准规范中，分组长度只能是128位，也就是说，每个分组为16个字节（每个字节8位），也就是我们上面说的 AES-128，对于密钥的长度可以使用128位、192位或256位，这里面涉及到了矩阵运算，具体就不展开了，我也没太深入研究，记住这个位数 16 个字节。

介绍完加密，我们看 M3U8 格式在 ExoPlayer 里的，如果是遇到了存在加密的，首先需要通过 url 取获取密钥

在这里其实就遇到过一个有趣的问题，因为通常情况会对密钥进行一个 base64 的处理，而之前就遇有用户遇到过，一个应该为 16 个字节的 base64 密钥，在解析后出现：

“java.io.IOException: javax.crypto.IllegalBlockSizeException: error:xxxx Cipher functions:OPENSSL_internal:WRONG_FINAL_BLOCK_LENGTH”

这是因为在 android 上于默认设置下，Android 的 Base64 包含行终止符，要获得与 Apache 编码相同的结果，就需要使用 Base64.NO_WRAP，因为默认的是 Base64.DEFAULT。

publich String encode(byte[] bytes) 
    return Base64.encodeToString(bytes, Base64.NO_WRAP);

这里为什么特意解释这么多关于 M3U8 的加解密逻辑呢？因为对于 M3U8 而已加密是非常常见，又非常容易出错的地方，介绍这个也是为了大家以后在使用 M3U8 格式播放时，可以更熟练地去寻找问题的解决办法。

RTSP

第二个想额外介绍的就是 RTSP，它也是我收到最多的问题之一， RTSP（Real Time Streaming Protocol）是一种实时流传输协议，当然有时候它也可以用于点播，最多是被用在监控和网络电视上。

如果你去看 RTSP 的概念，就会看到类似这一堆的概念，这里我们不展开解释它的详细内容，主要介绍它们概念是什么：

• RTSP ：它是应用层的一些网络协议，一种实时流传输协议，一般情况下 RTSP 使用 SDP 来传送媒体参数，使用 RTP（RTCP）协议来传输媒体流；另外它是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作，也就是它除了直播，还可以带上控制的逻辑。

• SDP ： 它是会话描述的格式，它其实并不包含传输协议，只是一种约定格式，里面包含了传输协议（RTP/UDP/IP，H.320等） 和 媒体格式（H.261视频，MPEG视频等），也即会话级别的描述（session level）和媒体级别的描述（media level）。

所以可以看到 RTSP 里会使用到 SDP ，但是它们基本属于应用层面。

• RTP，（Real-time Transport Protocol），它是一种实时传输协议 ，定义它在传输层其实并不是特别准确，因为它其实依赖于我们常见的 TCP 或者 UDP 协议，默认情况下一般是 UDP ，因为一般情况下，RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，例如 RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

• RTCP （Real-time Transport Control Protocol）实时传输控制协议是实时传输协议（RTP）的一个姐妹协议，RTCP为RTP媒体流提供信道外（out-of-band）控制，RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。

一般情况下 RTP 提供实时传输时间信息和流同步，而RTCP保证服务质量。

所以 RTSP 内包含了应用层的 SDP 和传输层的 RTP ，在使用 RTP 时可以使用 UDP 或者 TCP，所以搞清了这些概念，就可以帮助你更好理解 RTSP 的整体概念。

例如在 ijkPlayer 里，如果你接入 rtsp 的话，就可以通过 rtsp_transport 和 rtsp_flags 的配置来配置传输的协议。

另外还有一个叫 RTC 的概念，RTC（Real-time Communications）是实时通信协议，常见的 WebRTC 就是 RTC 的一部分，它和 RTSP 没有关系，一般用于做视频会议，实时通信和直播交互等。RTC 通常是指点对点 ( P2P ) 通信，覆盖了从了采集、编码、前后处理、传输、解码、缓冲、渲染等等的环节。

还有人问 WebSocket 能不能做直播，当然可以，通过 WebSocket 流式传输和共享音频和视频是可以做到的，但是 API 不像 WebRTC 中的对应功能那样强大，简单来说，比如采集，编码，打包，接收，同步这些都需要自己处理。

GSYVideoPlayer

介绍完这么多基础概念，接下来介绍 GSYVideoPlayer ，以 GSYVideoPlayer 给大家介绍下 Android 里音视频开发的一些常识。

其实 GSYVideoPlayer 并不是什么有技术含量的项目，代码量也不大，它更多是对现有资源的一个整合。如图所示，可以看到主要是分：

• 播放内核层

主要是用于实现真正的播放器内核的，比如常见的 IJKPlayer，MediaPlayer 和 ExoPlayer ，用于集成它们的播放能力，至于它们的区别，我们后续会讲到。

• Manager 层

主要用于管理和桥接内核层和 UI 层的中间过程，一般情况下不会直接操作内核，而是通过统一的 Manager 层来操作内核，比如释放、快进、暂停等等。

• UI 层

就是 GSYVideoPlayer 里用户直接使用的 View ，用户在 GSYVideoPlayer 里使用的基本都是 UI 层对象的子类，比如 StandardGSYVideoPlayer ，UI 层主要是连通了 Manager 层和渲染层。

• 渲染层

渲染层主要用于提供不同的渲染媒介，也就是 TextureView、SurfaceView、 GLSurfaceView 等等，用于提供不同的渲染 View， 因为不同的场景或者机器环境，需要不同的渲染效果。

例如如果你需要在画面渲染时，对画面数据做一些定制操作时，你可能就需要 GLSurfaceView ；在某些硬件设备上 SurfaceView 渲染可能会比 TextureView 更清晰；比如涉及透明度操作时选用 TextureView 等等。

• 缓存层

就是用于视频播放时，针对需要实现视频边播边下载的逻辑。

就是上面所示，GSYVideoPlayer 简单地根据需求对播放器做了一些分层，各个分层通过固定接口拼装在一起，其实这里为什么要实现多种播放内核和多种渲染 surface 的支持呢？

因为一般情况下一种内核很难满足各种各样的播放和渲染常见，千奇百怪的音视频来源下，最好的就是通过多种播放内核来支持，从而达到比较稳定的播放效果。

IJKPlayer、MediaPlayer 和 ExoPlayer

这里面主要需要讲的就是默认内置的三种内核：IJKPlayer、MediaPlayer 和 ExoPlayer 的区别。

IJKPlayer

首先 IJKPlayer 的底层使用的是 FFmpeg ，这说明 IJKPlayer 可以很灵活地配置需要支持的播放格式，因为 FFmpeg 的解码大部分时候都是软解码能力，也就是通过 CPU 来实现解码播放，所以可以很灵活地支持和配置自己需要支持的视频播放格式，当然这个支持是需要自己修改配置和打包。

另外使用了 FFmpeg ，所以 IJKPlayer 默认情况下使用的是软解码，软解码简单的理解就是纯 CPU 的解码能力，所以在面临高码率的视频时，就可能会出现解码能力出现瓶颈的问题，比如花屏，画面和视频不同步等等。

当然 IJKPlayer 也可以开启硬解码能力，硬解码就是配合硬件和GPU增加协助视频的解码能力，但是目前看来 IJKPlayer 的硬解码效果其实并不好。

MediaPlayer & ExoPlayer

MediaPlayer 和 ExoPlayer 的底层其实都是通过 MediaCodec 来实现解码的能力，他们之间的底层区别并不大，一般情况下可以理解为他们使用的都是硬解码的能力。

为什么说一般情况下呢？因为 Android 底层其实是会有一个优先级顺序排列的编解码器列表，如果设备具有用于该格式的解码器，则一般通常会选择硬解码器。

这个优先级顺序是不对上层公开的，Android系统中默认是通过解码器的命名区分，软解码器通常是以 OMX.google 开头，硬解码器通常是以 OMX.[hardware_vendor] 开头，当然有一些厂家可能会不遵守这个命名规范的，不以. OMX.. 开头的，那也会被认为是软解码器。

比如如下代码就可以简单看作为判断是否支持 H265 的硬件解码

   public static boolean isH265HardwareDecoderSupport() 
        MediaCodecList codecList = new MediaCodecList();
        MediaCodecInfo[] codecInfos = codecList.getCodecInfos();
        for (int i = 0; i < codecInfos.length; i++) 
            MediaCodecInfo codecInfo = codecInfos[i];
            if (!codecInfo.isEncoder() && (codecInfo.getName().contains("hevc")
                    && !isSoftwareCodec(codecInfo.getName()))) 
                return true;
            
        
        return false;
    
    public boolean isSoftwareCodec(String codecName) 
        if (codecName.startsWith("OMX.google.")) 
            return true;
        

        if (codecName.startsWith("OMX.")) 
            return false;
        

        return true;
    

但是使用了 MediaCodec 也就代表了你没办法干预它的解码支持，所以一般情况下 MediaCodec 的编码能力支持拓展就很弱，特别是针对一些奇奇怪怪的视频编码的情况下。

而这里对于 MediaPlayer 和 ExoPlayer 的最大的区别就是： MediaPlayer 的自定义空间很小，基本上 MediaPlayer 如果出现无法播放，那基本上就是没救了，因为它可以提供的操作空间很少，就比如 https 的证书不校验。

相对的 ExoPlayer 是一个开源项目，它提供可以更灵活的配置和调试，在 ExoPlayer 里最重要的就是 DataSource 和 MediaSource 。

官方提供了丰富的 MediaSource 用于处理各种不同协议的数据，比如

• SsMediaSource
• RtspMediaSource
• DashMediaSource
• HlsMediaSource
• ProgressiveMediaSource

一般情况下 SsMediaSource 、DashMediaSource 可能大家用得比较少，简单介绍下它们对应分别是微软的 Smooth Streaming 和国际标准 MPEG-DASH（Dynamic Adaptive Streaming over HTTP）。

它们其实都类似于苹果的 HLS 方案，都是支持基于 HTTP 的自适应流视频方案。

一般情况下在现在新版的 ExoPlayer 里， ProgressiveMediaSource 会是最常用的，它内部默认的 DefaultExtractorsFactory 会为这个视频寻找到对应的解码格式。

另外除了 RTMP 和 RTSP 之外的协议，一般都需要给他们设置一个 HTTP 的 DataSource ，DataSource 主要负责根据网络协议下载视频，另外 ExoPlayer 官方的视频缓存 CacheDataSource 也是在这一层实现。

举个例子：

• 如果你是 Rtmp 的视频，那就是 ProgressiveMediaSource + RtmpDataSource ；
• 如果是你 http 的 MP4，那就是 ProgressiveMediaSource + DefaultDataSource；
• 如果你希望在 http 播放时缓存视频，那就是 ProgressiveMediaSource + （CacheDataSource 嵌套 DefaultDataSource）
• 如果你希望介入网络下载过程，比如忽略 SSL 证书，那么你可以定义自己的 DataSource 来实现；
• 如果你需要预加载的列表播放，可以使用 ConcatenatingMediaSource；
• 如果你想自定义 M3U8 的解密和ts列表解析过程，可以自定义 HlsMediaSource 并实现里面的 HlsPlaylistParser 和 Aes128DataSource；

以前循环播放还有一个叫 LoopingMediaSource ，但是现在已经弃用，直接改为 setRepeatMode 方法。

可以看到 ExoPlayer 更加灵活和可定制化，通过 MediaSource 的嵌套和定义，组合 DataSource 的嵌套，可以得到更可控和可调试的代码结构，当然对比 MediaPlayer 使用上相对会复杂一些。

另外还有一个消息，就是未来的 ExoPlayer 可能会迁移到 androidx 下的 Media 项目。

常见问题

首先看一张图，这是以前做音视频开发时，遇到某些细节条件时的局部截图，对应分支需要取处理的情况：

事实上音视频开发如果只是到 “能播就行” 的状态并不难，但是如果细节到每个问题上时，就有很多需要处理的情况，所以如果老板对你说“做一个类似爱奇艺的播放页面”时，不妨把这些细节的问题和他讨论一遍，让他感受下做一个播放器是有多不容易。

开始一个音视频相关的项目需要注意什么

因为很多时候开发者可能有个误解，以为 “不就是接个播放器 SDK 放个 Url 的功夫吗？” ，从而给后面的开发留下了太多的坑需要填。

• 1、首先在做音视频开发时，要确定好自己需要支持的封装协议、视频编码、音频编码格式，因为编码格式千万种，一般情况下你不可能全都支持，所以首先要在需求内确定好需要支持的格式范围。

• 2、如果存在用户自主上传视频的场景，最好还要在服务端提供转格式与转码率等功能。因为在服务端判断视频格式并转码可以规范编码统一，这能够减少客户端端因为编解码失败无法播放的问题；另外提供同一视频不同码率的链接，可以在不同手机型号和系统上能够拥有更好的播放体验，减少前面说过的因为码率太高出现音视频不同步或者卡顿的问题。

类似功能在阿里云和腾讯云等等流媒体平台都有支持。

通过解决数据源来适配，会比你被动在客户端做各种视频成本来得更低和更可靠。

“为什么我的视频缓冲了，在 seek 之后还需要重新请求？”

这就需要解释缓存和缓冲的区别：

• 缓冲：就像在倒垃圾的时候，不可能一有垃圾马上跑去垃圾堆倒，而是先把垃圾倒到垃圾桶，垃圾桶满了再一起倒到垃堆。因为缓冲是在内存中，不可在内存中把整个视频都缓冲进去，所以一般情况下你看到的缓冲都是一段一段的临时数据，一个缓冲块是处于不断地加载又不断清除的过程。

• 缓存: 缓存的解释就简单多了，就是把视频在播放的时候一边下载到本地，这样在缓存区域内的数据就不需要发生二次请求。

另外前面也介绍过 Seek 导致跳动的问题，其实就是关键帧的问题，你 Seek 到一个位置上因为如果没有关键帧，那其实是无法获取到一个完整画面的，所以当视频的关键帧被压缩得太少时，就会导致 Seek 的时候帧跳动。

“为什么我的视频会出现大小和方向不对？”

一般情况下视频信息里是带有旋转角度的，比如 Android 手机上录制的视频就可能带有旋转角度，所以在布局和绘制时需要把旋转角度如： 270，90 这样的角度考虑上。

另外视频在获取大小还会有 Width Height Ratio 的信息，也就是宽高比，例如这个信息在 ijkplayer 上是以 videoSarNum / videoSarDen 得到的，只有把宽高比和视频的宽高一起计算，才能获取到真正的展示宽高。

倍速

前面介绍过，视频在播放时音频编码和视频编码会被单独解码出来，这时候他们在播放时就需要组合起来，就会有一个同步时钟的概念，比如以音频为同步时钟，视频画面跟着同步播放。

倍速播放其中一个关键就是同步时钟，这时候比如同步时钟是音频，但是视频其实是没有音频的无声视频，那设置倍速播放会有无效。

另外如果音频和视频帧交错不合理，比如前面一大半数据都是音频帧，后面一大段才是视频帧，这就会导致预读取的数据会很多，需要反复横跳，导致播放过程中频繁 seek 和卡顿。

在 A 页面播放视频 a，跳到 B 页面播放 b ，回到 A 页面视频 a 不会继续播放

默认情况下在 GSYVideoPlayer 只会有一个活跃内核，这个问题也是被问得到最多的问题之一。

这是因为活跃的播放内核默认只有一个。

当 B 页面的 b 视频开始播放时，A 页面对应的内核就已经被释放了，这是因为如果同时存在多个内核会不方便管理，并且占用过多的内存，所以当 B 页面视频播放时，A 页面的内核就被释放了，如果这时候需要 A 页面回复播放，就是重新设置并调用播放接口，才能恢复播放。

当然如果 A 页面和 B 页面时同一个视频，比如时列表调整到详情页面的场景，就可以在不释放内核的情况下，通过切换渲染层的 surface 来达到无缝切换的效果。

当然针对一定要多个内核的场景，GSYVideoPlayer 里也做了对应的实例，比如：

• 开启单独的内核用于广告播放，在播放广告时也同步加载视频内容；
• 多个监控画面的同时查看，支持开启多个内核同时播放；

整体来说 GSYVideoPlayer 并不是一个完美的项目，因为他依旧有很多问题，依旧也有很多需要自己兼容和处理的场景，但是它免费啊，它开源啊～。