IJKPLAYER源码分析-总体概述

已于 2024-11-14 21:55:17 修改
阅读量1.2k 收藏 18
点赞数 19
分类专栏： ijkplayer 文章标签： 音视频
于 2024-04-15 11:19:19 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_41255248/article/details/137753544
版权

1 前言

    前面系列文章，对IJKPLAYER源码所涉及到的各个技术点、模块、关键技术及其实现原理，做了较为详细的梳理。但窃以为那只是微观层面的梳理，还不够完整不够透彻，本文拟尝试从宏观框架架构的视角加以补充。

    算是抛砖引玉。在此列出对IJKPLAYER源码分析的系列文章：

IJKPLAYER源码分析-iOS端显示-优快云博客

IJKPLAYER源码分析-Android端显示-优快云博客

IJKPLAYER源码分析-OpenGL ES渲染-优快云博客

IJKPLAYER源码分析-AudioQueue播放-优快云博客

IJKPLAYER源码分析-OpenSL ES播放-优快云博客

IJKPLAYER源码分析-AudioTrack播放-优快云博客

IJKPLAYER源码分析-videotoolbox硬解-优快云博客

IJKPLAYER源码分析-mediacodec硬解_ijkplayer硬解-优快云博客

IJKPLAYER源码分析-主结构体-优快云博客

IJKPLAYER源码分析-重要字段_packet-buffering-优快云博客

IJKPLAYER源码分析-点播原理-优快云博客

IJKPLAYER源码分析-音视频同步_ijkplayer 音视频同步-优快云博客

IJKPLAYER源码分析-常用API_sdl_profilerreset-优快云博客

IJKPLAYER源码分析-主要队列_ijkplayer packetqueue-优快云博客

IJKPLAYER源码分析-软解主结构_androi中ijkplayer源码分析-优快云博客

2 架构图

IJKPLAYER框架图

    阐述如下： 

  •  网络层：拉流、解协议、解封装，使用的是FFmpeg库，因此FFmpeg所能支持的协议，IJKPLAYER均支持，具体执行是在read_thread线程，软解及Android和iOS硬解平台无关；
  • 解码层：分为音频和视频解码，其中音频解码及视频软解，Android和iOS统一逻辑，均使用FFmpeg软解，而视频硬解则因Android和iOS系统而已，Android使用Android SDK层mediacodec解码能力，iOS则使用videotoolbox解码；
  • 渲染层：也分为音频和视频渲染显示，音频Android支持AudioTrack和OpenSL ES播放、iOS支持AudioQueue播放(AudioUnit亦有实现)，而视频Android系统则分为ANativeWindow和OpenGL ES + EGL，iOS则是OpenGL ES + EAGL；

3 线程模型

    具体到IJKPLAYER程序实现上来看，首先来看看各个线程及其通信方式： 

  • 网络线程与音频解码线程audio_thread、视频解码线程以及字幕解码线程subtitle_thread，用PacketQueued队列通信，可通过选项限制队列大小； 
  • 音频解码线程audio_thread、视频解码线程以及字幕解码线程subtitle_thread与音视频各自render线程用FrameQueue队列通信，由于是像素或pcm数据，因此
最低0.47元/天 解锁文章
ijkplayer源码分析 整体概述
baiiu
01-21 3932
前言 本系列是对ijkPlayer进行源码分析，本篇是对ijkPlayer的整体概述，分析了主要流程、主要结构体和初始化流程，为后面的文章打下基础。 主要流程 read_thread -> PacketQueue(AVPacket) -> FrameQueue(AVFrame) -> 渲染 对应关系 PacketQueue FrameQueue Clock 解码线程 渲染线程 视频 videoq pictq vidclk video_thread video_refres
ijkplayer源码分析 音频解码流程
baiiu
01-21 972
前言 本文是流程分析的第三篇，分析ijkPlayer中的音频解码流程，在audio_thread中，如下流程图中所示。 音频帧是如何解码的、如何入队的 音频帧的解码操作是在audio_thread线程中，audio_thread从packet_queue中读取了音频packet，并软解码成音频帧，放入frame_queue中。 音频帧只有软解码，无硬解码。 static int stream_component_open(FFPlayer *ffp, int stream_index) { //
BiliBili-IJKPlayer播放器源码分析（一）
热门推荐
veilling的专栏
09-30 2万+
IJKPlayer是一款基于ffmpeg/ffplay的开源播放器，可支持rtmp/rtsp/hls等多种媒体协议，支持Android/IOS等移动平台。项目地址：https://github.com/Bilibili/ijkplayer，项目地址有可供参考的编译方式。 “Android/iOS video player based on FFmpeg n3.1, with MediaCod
ijkplayer视频播放器源码分析
风平浪静的专栏
07-04 1085
http://www.jianshu.com/p/7d9b86919682
IJKPlayer 使用教程
最新发布
gitblog_00176的博客
04-14 818
IJKPlayer 使用教程 ijkplayer 编译工具链升级到最新，能够在最新的安卓15 和 iOS18 上正常运行。 项目地址: https://gitcode.com/gh_mirrors/ijkplay/ijkplaye...
BiliBili-IJKPlayer播放器源码分析（二）
veilling的专栏
10-31 8134
IJKPlayer播放器（https://github.com/Bilibili/ijkplayer）是一款全格式播放器，支持（rtsp/rtmp/hls）等媒体协议，支持字幕，快进快退等功能。但就播放器的功能而言， 这些时不够的，比如没有截屏，不支持手势等功能。下面就给视频播放器添加截屏功能，来熟悉IJKPlayer播放器的源码结构。 IJKPlayer播放器底层依赖于ffmpeg，
IJKPLAYER源码分析-mediacodec硬解
老中医的博客
04-06 1360
mediacodec技术是Android系统音视频硬编/硬解的一套标准，各硬件厂商加以实现，常和MediaDrmImageSurfaceAudioTrack一起使用。请参考MEDIACODEC开发文档。由上图了解到，一言以蔽之，一端输入、一端输出，input输入的数据提交给codec异步处理后，由output输出再归还给codec。
IJKPLAYER源码分析-主结构体
老中医的博客
05-03 755
本文来介绍下IJKPLAYER的几个主要结构体。主要有以下几个：IjkMediaPlayer：是IJKPLAYER的外围结构体，最接近于caller层，主要包装了FFPlayer结构；FFPlayer：这个代表的是IJKPLAYER播放器内核的结构；VideoState：这个是FFPLAY的上下文，被IJKPLAYER包装在了FFPlayer中；
ijkplayer框架深入剖析
STN_LCD的专栏
06-16 1614
http://www.jianshu.com/p/daf0a61cc1e0 ijkplayer框架深入剖析   作者 金山视频云 关注 2017.01.23 11:34 字数 3965 阅读 1561评论 5喜欢 18 随着互联网技术的飞速发展，移动端播放视频的需求如日中天，由此也催生了一批开源/闭源的播放器，但是无论这个播放器功能
深入理解Android音视频同步机制（五）如何从零开始写一个音视频同步的播放器
张晖的专栏
12-07 1万+
前面我们分析了三个播放器的av sync逻辑，可以看到他们都各有不同，那么究竟哪种方法可以达到最好的avsync结果？哪些逻辑是必要的？如果我们想自己从零开始写一个av同步的播放器，都需要做哪些工作？ 本文通过一个demo解答上面的问题
IJKPLAYER源码分析-常用API
老中医的博客
04-20 896
本文简要介绍IJKPLAYER的几个关键API，站在使用的角度，来审视其内部运作原理。这里以iOS端直播API调用切入。
ijkplayer源码
05-10
ijkplayer 底层和应用层源代码 ijkplayer JNI APP ijkplayer
IJKPLAYER源码分析-主要队列
老中医的博客
04-20 742
对IJKPLAYER播放器内核几个关键的队列的理解，将有助于掌控全局。单链表环形队列。
ijkplayer 源码分析（1）：初始化流程
AlanWang4523
03-29 1019
ijkplayer 源码分析，梳理 ijkplayer 动态库加载及初始化路程
ijkplayer源码分析 —— 事件消息设计
u010187654的博客
06-30 354
1. 事件消息队列设计 1.1 结构体对象定义 ff_ffmsg_queue.h 消息、队列结构体定义和功能函数 // 消息结构体（节点） typedef struct AVMessage { int what; //消息类型 int arg1; //整型可选参数 int arg2; //整型可选参数 void *obj; //无类型可选动态内存参数 void (*free_l)(void *obj); //用于释放obj指针的内存 } AVMessage; //
ijkplayer视频播放器源码分析(android)
eydwyz的专栏
11-17 888
近年来，直播这么火，对于我们android程序员来说，手上掌握几个开源的播放器很有必要：一是方便在别人开源的项目上面更改；二来了解别人的思路可以帮助我们自己以后开发类似的项目。所以这次我带来的是bilibili的开源项目ijkplayer。 这次由于ijkplayer深入到了jni层，所以阅读源码的工具我选择了SourceInsight 3.5,这是一个很好的源码阅读工具，因为它对源码的
超详细讲解IJKPlayer的播放器实战和源码分析
yan_chenglong的博客
03-02 3945
函数IjkMediaPlayer_pause(JNIEnv *env, jobject thiz)->调用ijkmp_pause(mp)->ijkmp_pause_l(mp)->回调ffp_notify_msg1(mp->ffplayer, FFP_REQ_PAUSE)->msg_queue_put_simple3(&ffp->msg_queue, what, 0, 0)->msg_queue_put(q, &msg)->msg_queue_put_private(q, msg)->
IJKPLAYER源码分析-videotoolbox硬解
02-28
<think>好的，我现在需要分析用户关于IJKPlayer源码中VideoToolbox硬解的问题。用户之前已经询问过相关的代码片段，现在希望得到源码分析的详细介绍。首先，我得回想一下IJKPlayer的整体结构，它基于FFmpeg，所以硬解部分应该和FFmpeg的硬件加速机制相关。 用户之前给出的代码涉及设置硬件加速选项，遍历编解码器的硬件配置，初始化VideoToolbox。我需要确定这些步骤在IJKPlayer中的具体实现位置，可能是在解码器初始化的部分。比如，在FFmpeg的avcodec_open2之前，IJKPlayer可能调用了相关的硬件加速设置。 接下来，用户可能需要了解VideoToolbox在IJKPlayer中的集成方式。可能需要解释如何通过FFmpeg的hwcontext机制来创建硬件设备上下文，以及如何在解码时使用这个上下文。此外，iOS/macOS平台上的VideoToolbox支持哪些编码格式，比如H.264和HEVC，这也是需要注意的点。 还要考虑用户可能的疑问点，比如硬解和软解的区别，为什么使用VideoToolbox能提升性能，或者遇到不支持的编码格式时如何处理。同时，错误处理机制，比如当初始化失败时如何回退到软解，这些在源码中是否有体现。 另外，用户可能对IJKPlayer中特定的封装函数感兴趣，比如hw_decoder_init的具体实现，里面是否涉及创建硬件设备、配置解码器参数等步骤。需要回忆相关代码结构，或者参考FFmpeg的官方文档来确认这些函数的用法。 还需要注意代码中的日志输出，比如ALOGI和ALOGE，这些日志在调试时的重要性，帮助开发者确认硬解是否成功启用，或者在失败时快速定位问题。 最后，可能需要补充一些性能优化的建议，比如多线程解码、内存管理，或者不同iOS版本之间的兼容性问题。这些都是在实际使用VideoToolbox硬解时需要考虑的因素。 总结下来，回答的结构应该包括：IJKPlayer与FFmpeg的关系，VideoToolbox硬解的初始化流程，关键函数的作用，支持格式与平台要求，错误处理机制，以及性能优化点。需要确保用中文清晰解释，并保持技术细节的准确性。</think>### IJKPlayer源码分析 - VideoToolbox硬解实现 IJKPlayer是基于FFmpeg的跨平台播放器，其VideoToolbox硬件解码实现主要通过与FFmpeg硬件加速框架的深度集成完成。以下是关键实现分析： #### 一、架构设计原理 $$ \text{IJKPlayer架构} = \text{FFmpeg核心} + \text{平台硬件抽象层} $$ VideoToolbox硬解通过FFmpeg的`hwcontext`机制实现，核心类交互关系： ```mermaid graph TD A[IJKFF_Pipeline] --> B[VideoToolbox初始化] B --> C[av_hwdevice_ctx_create] C --> D[AVHWDeviceContext] D --> E[AVCodecContext] ``` #### 二、核心实现流程 1. **硬件加速使能检测** ```c // 检查编译时支持 #if CONFIG_VIDEOTOOLBOX // 检查运行时可用性 if (av_hwdevice_find_type_by_name("videotoolbox") != AV_HWDEVICE_TYPE_NONE) { enable_hwaccel = 1; } ``` 2. **硬件上下文创建** ```objc AVBufferRef *hw_device_ctx = NULL; av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_VIDEOTOOLBOX, NULL, NULL, 0); ``` 3. **解码器配置（关键代码段）** ```c // 设置硬件像素格式 avctx->get_format = get_hw_format; static enum AVPixelFormat get_hw_format(AVCodecContext *ctx, const enum AVPixelFormat *pix_fmts) { while (*pix_fmts != AV_PIX_FMT_NONE) { if (*pix_fmts == AV_PIX_FMT_VIDEOTOOLBOX) return AV_PIX_FMT_VIDEOTOOLBOX; pix_fmts++; } return AV_PIX_FMT_NONE; } ``` #### 三、关键技术点 1. **内存管理机制** - 使用`CVPixelBufferRef`直接访问GPU内存 - 通过`AVBufferRef`实现引用计数管理： $$ \text{显存生命周期} = \max(\text{解码器引用计数}, \text{渲染器持有计数}) $$ 2. **格式转换流水线** ```c Videotoolbox硬解输出 --> 转换YUV420P --> OpenGL ES渲染 ``` 转换过程通过`vtDecompressionSessionDecodeFrame`回调实现 3. **多线程同步** - 独立的硬件解码线程：`videotoolbox_async_thread` - 使用pthread条件变量实现帧缓存同步 ```c pthread_mutex_lock(&q->mutex); while (q->count == 0) pthread_cond_wait(&q->cond, &q->mutex); frame = q->frames[q->rindex]; pthread_mutex_unlock(&q->mutex); ``` #### 四、性能优化策略 1. **零拷贝渲染** ```objc CVOpenGLESTextureCacheCreateTextureFromImage( kCFAllocatorDefault, _textureCache, pixelBuffer, NULL, GL_TEXTURE_2D, GL_RGBA, width, height, GL_BGRA, GL_UNSIGNED_BYTE, 0, &_texture); ``` 直接绑定CVPixelBuffer到OpenGL纹理 2. **动态降级策略** | 触发条件 | 处理方式 | |---|---| | 解码超时 > 200ms | 切换软解 | | 显存不足 | 清空缓存队列 | | 格式不支持 | 触发格式转换器 | 3. **参数调优建议 ```objc [options setPlayerOptionIntValue:0 forKey:@"videotoolbox-max-frame-width"]; // 4K限制 [options setPlayerOptionIntValue:1 forKey:@"videotoolbox-async"]; // 异步模式 ``` #### 五、平台适配问题 1. **iOS版本差异** - ≥ iOS8: 完整HEVC支持 - iOS11+: 改进的色彩空间处理 2. **Mac特殊处理** ```c #if TARGET_OS_MAC av_dict_set(&opts, "output_cvpixelbufferpool", "true", 0); #endif ``` 该实现通过深度整合FFmpeg硬件加速框架与苹果原生VideoToolbox API，在保证跨平台兼容性的同时实现了高性能视频解码。实际开发中需特别注意显存管理和线程同步问题。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

老中医的博客

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值