1. 背景介绍
15年移动端直播应用火起来的时候,主要的直播协议是RTMP,多媒体服务以Adobe的AMS、wowza、Red5、crtmpserver、nginx rtmp module等,后面过长RTMP服务SRS开始流行。Android端播放器主要以开始以EXOPlayer播放HLS,但是HLS有延迟高的确定,随后大家主要使用开源的ijkplyer,ijkplayer通过ffmpeg进行拉流及解码,支持多种音视频编码,还有跨平台,API与系统播放器保持一致等特征,后续各大厂提供的直播SDK均有ijkplayer身影。
当时在做一款游戏SDK,SDK主要提供了游戏画面声音采集、音视频编解码、直播推流、直播拉流播放等,SDK为游戏提供直播功能,播放也是采用了现成的ijkplayer播放器。但是SDK推广的时候遇到了问题,游戏厂家嫌弃SDK体积大(其实总共也就3Mb左右),我们需要一款体积小,性能高的播放器,由于开发成本的原因一直没有时间做,后面换工作期间,花了一个月时间把这款播放器开发出来,并开源了出来。oarplayer 是基于MediaCodec与srs-librtmp,完全不依赖ffmpeg,纯C语言实现的播放器。本文主要介绍这款播放器的实现思路。
2. 整体架构设计
播放器整体播放流程如下:
通过srs-librtmp拉取直播流,通过package type分离音视频流,将package数据缓存到package队列,解码线程不断从package队列读取package交由解码器解码,解码器将解码后的frame存储到frame队列,opensles播放线程与opengles渲染线程从frame队列读取frame播放与渲染,这里还涉及到音视频同步。
播放器主要涉及了以下线程:
-
rtmp拉流线程;
-
音频解码线程;
-
视频解码线程;
-
音频播放线程;
-
视频渲染线程;
-
JNI回调线程。
3. API接口设计
通过以下几步即可完成rtmp播放:
-
实例化OARPlayer:
OARPlayer player = new OARPlayer();
-
设置视频源:
player.setDataSource(rtmp_url);
-
设置surface:
player.setSurface(surfaceView.getHolder());
-
开始播放:
player.start();
-
停止播放:
player.stop();
-
释放资源:
player.release();
Java层方法封装了JNI层方法,JNI层封装调用了对应的具体功能。
★文末名片可以免费领取音视频开发学习资料,内容包括(FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,srs)以及音视频学习路线图等等。
见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
4. rtmp拉流线程
oarplayer使用的是srs-librtmp,srs-librtmp是从SRS服务器导出的一个客户端库,作者提供srs-librtmp初衷是:
-
觉得rtmpdump/librtmp的代码太难读了,而SRS的代码可读性很好;
-
压测工具srs-bench是个客户端,需要一个客户端库;
-
觉得服务器能搞好,客户端也不在话下
目前srs-librtmp作者已经停止维护,主要原因如作者所说:
决定开源项目正义的绝对不是技术多好,而是能跑多久。技术很牛,性能很强,代码风格很好,固然是个好事,但是这些都顶不上一个“不维护”的大罪过,代码放出来不维护,怎么跟进业内技术的不断发展呢。而决定能跑多久的,首先是技术热情,然后是维护者的领域背景。SRS的维护者都是服务器背景,大家的工作都是在服务器,客户端经验太少了,无法长久维护客户端的库。因此,SRS决定果断放弃srs-librtmp,不再维护客户端库,聚焦于服务器的快速迭代。客户端并非不重要,而是要交给专业的客户端的开源项目和朋友维护,比如FFmpeg也自己实现了librtmp。
oarplayer当初使用srs-librtmp是基于srs-librtmp代码的可读性考虑。oarplayer有相当高的模块化特性,可以很方便的替换各个rtmp lib实现。这里介绍srs-librtmp接口:
-
创建