===============================================
第一个比较大的坑，是我们需要搞定一个视频播放器，而关于直播苹果官方的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改写，这个过程也是非常痛苦的，这个毕竟是个开源项目，而且作者也不是经常维护的项目，结果可想而知，代码结构有些混乱，逻辑也不是很清晰。再加上，我们只需要一个简单的网络播放器，不需要里面那么多的东西，所以我干的第一件事，是删代码重构，理清整理的框架思路。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
