===============================================
第一个比较大的坑,是我们需要搞定一个视频播放器,而关于直播苹果官方的AVPlayer只能播放HLS,但是很可惜,这个格式不太适合我们的业务需求,还有其他方面的原因。最终我们放弃了这个格式,剩下的如果使用其他方式的话,我们就需要自己搞定播放器了。
首先,我们决定使用第三方的播放器SDK,这样无疑对开发还有维护成本都会节省大量的成本。一开始我们决定使用vitamio,但一方面它的商业授权费用非常高,我们也不太想冒着这个风险不去买授权,其次它对我们的视频流支持非常差,打开流基本在10秒左右,这个远远无法满足产品的需求。不得不说,由于是商业化的SDK,文档还有资料都是比较全面的,就是demo过于混乱,让人不知道这个东西到底什么意思。而且同样是基于ffmpeg,完全没搞懂这个SDK播放我们的视频流为何如此慢。
后来,我们尝试了一下百度的播放器SDK。首先,他们官方网站上的SDK竟然是真机无法编译的!这点让我非常郁闷,通过他们官方群找到了这个开发人员,最后他给我的SDK是可以播放的,非常感谢这哥们,人真的很热情负责。再次,里面的命名使用了一个叫base64的类,结果是这个文件是个静态库,而我们使用的另外一个SDK也有这个类,最后百度的开发人员把base64的源代码给了我,我把它做了一个category做了进来才最终解决问题。对于这个SDK中使用别的类似于ASI的静态库,我直接选择忽略,因为我们项目本身已经有了ASI,还有openssl之类的,遇到这些,直接不添加该静态包即可。在一个问题就是,这个SDK是去年10月份更新,之后再无更新,iOS7 SDK不知道有无使用,反正是只有armv7架构的SDK,这个后续升级的话会一不小心就让我们的项目卡死,很郁闷。好不容易最终编译进了我们的项目,发现百度播放器的SDK竟然是在主线程中做的OpenGL渲染,跟我们另外使用OpenGL的东西冲突,无奈之下,放弃!
在第三方SDK都失效的情况下,不得已,我们决定自己写视频播放器,这个很无奈的选择,之前我们对这方面都毫无经验,我找了一下目前可以使用网上的开源播放器代码。大概分为一下几种:
1. ffmpeg+SDL的ffplay,这个应该是效果最稳定的一种了,但是有需要编译一对类库,在iOS上面也没有特别好的移植方案,有个ffmpeg-iphone也已经好久不更新,并且这个项目也不是很稳定,不敢使用。ffplay的代码是非常好的,但是由于我自己对ffmpeg不是很熟悉,就不是很感冒,而且是C写的,我们这边的开发对C熟悉的也不是很多,后期维护也很蛋疼,就放弃了。
2. kxmoive,这个无疑是最经典的一个iOS开源播放器了,也是我们最终的选择,不过这个真的是个开源项目,无论是代码还是其他方面都显的过于粗陋了,槽点很多,后面再写。
3. VLC,非常有名的开源播放器,之前一直没有发现这个竟然有iOS版本,在下载这个代码的过程中,我的大脑中就只有一个想法了,果断放弃!代码太大,结果过于复杂,导入一个静态包就将近40M,我看了一个小时这个代码,竟然没有头绪。这么复杂的东西,就算引入,以后的维护也将是个大问题。
4. classxmobile(http://classx.sourceforge.net/),号称一个大学的开源项目,由于已经决定使用kxmoive了,这个就没来得及研究的很多,不过由于这个是直接使用UIImage进行渲染的,看着好感不是很多,最后还是决定放弃了,不再看了,不过据我的感觉,我们很多竞品应该就是使用的这个,因为比较简单,不涉及opengl。但是只能渲染rgb24不能直接渲染YUV,色彩有些不太丰富,分辨率也不太高。就没有过于研究这个方案,最后放弃了。
5. https://github.com/iOSffmpegPlayer/player,这个方案挺有意思的,结合ffplay和kxmoive而写的,还是国内的一个程序员写的。我看了一下这个代码,发现里面的代码结构不是很清晰,而且依赖于SDL这个类库,让我觉得不太爽,还是放弃了。多说一句,百度的SDK就我反编译看来,也是基于SDL而成的。
最终的结果,其实一开始就决定了,使用kxmoive改写,这个过程也是非常痛苦的,这个毕竟是个开源项目,而且作者也不是经常维护的项目,结果可想而知,代码结构有些混乱,逻辑也不是很清晰。再加上,我们只需要一个简单的网络播放器,不需要里面那么多的东西,所以我干的第一件事,是删代码重构,理清整理的框架思路。