老中医的博客

是一个底层框架，提供对硬件编码器和解码器的直接访问。它提供视频压缩和解压缩服务，以及存储在CoreVideo像素缓冲区中的光栅图像格式之间的转换服务。这些服务以会话对象(压缩、解压缩和像素传输)的形式提供，它们作为核心基础(CF)类型出售。不需要直接访问硬件编码器和解码器的应用程序不需要直接使用VideoToolbox。详情可参考其开发文档videotoolbox开发文档。输入的是，输出的是。CVPixelBuffer再与OpenGL ES结合，将像素数据喂给OpenGL ES进行render。

pipeline是在分析了软硬解及跨平台视频decoder的创建、配置及初始化与音频的跨平台输出共性，从而抽象出来的接口；pipeline定义了配置、初始化和创建视频decoder的接口(包括FFmpeg软解及对应平台硬解decoder)，及创建SDL_Aout实例的接口；音频decoder的创建、配置及初始化，则是在SDL_Aout接口里定义；

OpenGL ES 通过 CAEAGLLayer 与 Core Animation 连接，CAEAGLLayer 是一种特殊类型的 Core Animation 图层，它的内容来自 OpenGL ES 的 RenderBuffer，Core Animation 将 RenderBuffer 的内容与其他图层合成，并在屏幕上显示生成的图像。所以，videotoolbox硬解后的像素数据来源也清楚了，来自AVFrame的opaque，实际是CVPixelBuffer。iOS端显示的主函数，是在iOS端。

上文分析了OpenGL ES渲染的实现。本文边可以分析video画面是如何在Android端窗口上显示的了。

提示：阅读本文需要有一定的OpenGL shader编程基础。

IJKPLAYER实现了AudioQueue和AudioUnit播放PCM音频的功能，但当前使用的是AudioQueue来播放PCM音频。因此，本文来只介绍AudioQueue播放PCM的实现。关于AudioQueue官方文档，请参见。

与IJKPLAYER处理AudioTrack播放类似，OpenSL ES的接入需要满足SDL_Aout的接口规范，所不同的是OpenSL ES播放是在native完成的，调用的是NDK接口OpenSL ES的播放能力。关于OpenSL ES的详细介绍，请参考官方文档一文。Pipeline及SDL_Aout结构体及相关创建，与AudioTrack一致，请参考前文。

AudioTrack是Android SDK所提供的播放PCM音频的技术，IJKPLAYER对此使用的以native层反射到Java层的播放能力。

mediacodec技术是Android系统音视频硬编/硬解的一套标准，各硬件厂商加以实现，常和MediaDrmImageSurfaceAudioTrack一起使用。请参考MEDIACODEC开发文档。由上图了解到，一言以蔽之，一端输入、一端输出，input输入的数据提交给codec异步处理后，由output输出再归还给codec。

本文来介绍下IJKPLAYER的音视频同步策略及方法。

本文来介绍下IJKPLAYER的几个主要结构体。主要有以下几个：IjkMediaPlayer：是IJKPLAYER的外围结构体，最接近于caller层，主要包装了FFPlayer结构；FFPlayer：这个代表的是IJKPLAYER播放器内核的结构；VideoState：这个是FFPLAY的上下文，被IJKPLAYER包装在了FFPlayer中；

本文来介绍下IJKPLAYER的几个重要字段，对这些个字段的理解，将更有助于理解IJKPLAYER播放器内核。

本文对IJKPLAYER的点播原理做下分析，主要涉及到拖动播放、精准SEEK、暂停和恢复播放等几个常用操作。下文分析均是在iOS端，Android端也类似，只是多了JNI层调用。

本文简要介绍IJKPLAYER的几个关键API，站在使用的角度，来审视其内部运作原理。这里以iOS端直播API调用切入。

对IJKPLAYER播放器内核几个关键的队列的理解，将有助于掌控全局。单链表环形队列。

本文主要分析IJKPLAYER源码软解主流程，硬解将另起一篇分析。

前两天把android端的播放缓存搞定了，这两天开始着手搞iOS端的播放缓存。由于要支持，github上可供选择的不多，KTVHttpCache stars较多，但仅支持对mp4的本地缓存，这里选择基于KTVHttpCache二开的SJMediaCacheServer作为hls的缓存库。项目计划是将SJMediaCacheServer作为.a文件或framework引入到ijkplayer中，本文介绍编译链接使用SJMediaCacheServer的方法。

而播放器启播时，必须首先下载mp4的moov box数据，MP4是由一个个的box（以前叫atom）组成，所有的Metadata（媒体描述元数据），包括定义媒体的排列和时间信息的数据都包含在这样的一些结构box中。1）由以上分析可知，可使用DASH，fragment MP4切片来实现，将大的MP4分片为诸多较小的MP4文件，以此来降低MP4首开延迟，但DASH不受国内各CDN厂商所支持，网上资料也少，不建议；经过自测，发现片源总时长短则加载快，而片源总时长长则加载慢，加载时间不定，短则1s内长则N秒。

本项目是基于ijkplayer二次开发的http-mp4点播项目，业务UI层是flutter，所使用的render方式是flutter的。在使用ijkplayer做二次开发的http-mp4点播项目时，在生产环境遇到了一些视频在播放时，的问题，而同样的视频在android平台，不论是mediacodec硬解还是ffmpeg软解均是ok的。分析发现，此类视频的分辨率均非标准，但android表现正常，大胆推测是iOS平台。进一步分析iOS平台源码，发现是将rgba格式数据，存储在。需要给flutter提供。

关键的代码段逻辑：即首先判断是否是http-mp4网络流（本地文件不走此逻辑），通过VideoState结构体的Decoder类型字段viddec，再通过AVCodecContext类型变量avctx找到本片源的gop_size，然后将seek_target - gop_size * 1000 * 1000，再按此值往回找IDR，可实现http-mp4的精准定位。本地mp4文件，如果要做精准seek，则按如上方案实施即可，可找到target_ts后面最近的IDR帧，然后逐帧解码后，当视频的。

最近维护了一个点播播放器，基于B站开源ijkplayer播放器做二次开发，支持Android和iOS平台。Android平台在Java层对ijkplayer包装了一层，做成了一个sdk的aar包，给App使用；同事离职后，接手其所负责事宜，测试同事提了一系列播放缺陷，诸如切到前台概率性黑屏、屏幕旋转画面扭曲或者不继续播放、seek崩溃或时间点向前跳跃几秒、最终播放时长和片源时长不一致、画中画视频不继续播、暂停后全屏画面扭曲等等问题。如本文主题，App暂停播放后再切到前台概率性黑屏，暂停后全屏也黑屏。....

本问主要介绍如何在win上编译ijkplayer for android库。