一次RTMP的实践

之前在理解音视频的过程中
学习了落影的文集，能够理解直播传输的每个部分，
从摄像头获取视频，麦克风获取音频，视频硬编码为H264，音频硬编码为AAC
再推流到服务器去，服务器有推流使用的协议，推流需要按照协议来推
播放端从服务器拉流，拉流也要遵照服务器的协议啦进行拉流。拉流下来的
数据是H264 和aac 硬解码为 一帧一帧的数据用openGL绘制出来，aac的音频
转换为pcm 然后放入音频缓冲中播放

文集中主要是对这些过程进行了一一分解。转换也只是转换为文件。或者再把文件转换为流，真实的直播过程是一边转 一边传输，其实要求的是 流的转换与展示。于是又找了摄像头捕捉，转换为H264,转换成帧的时候就直接传出来 通过OPENGL绘制在视图上

然后就是需要考虑无音频 有视频 音频和视频都有的时候。音视频同步的问题。人听到音频一般都是连续不断的。所以都会以音频为主，视频为辅，音频接收到数据的时候，把时间戳传给视频播放层，视频播放数据的时间戳小于或者等于音频时间戳的部分，就正常播放，其他就不做操作。保证视频和音频对的上。当视频数据缓冲大于30帧的时候，一直没有收到音频的代理回应，就认为没有音频。将时间戳置空，就会播放无音频的处理。无音频情况下，是不需要视频时间戳等待的，就拿到一帧buffer 就传给openGL的View，就能够实时显示了。等到再接收到音频数据，就又会进入音视频同步的状态。这部分是公司的经验

除此之外。视频的推拉流也有许多协议。比如TUTK的方案，还有直播流标准的RTMP/HLS方案，像tutk的协议是C写的，拿到的数据是H264 的buffer 和pcm。
就直接解析播放的部分即可， HLS 是苹果的点播技术，因为分片的原因和HTTP一个通道。不会被墙。RTMP则是广泛应用的直播技术方案，是Adobe公司提供的。但是Adobe公司并没有完全开源协议。

然后我就想尝试推流一下，结果很难找到相关文章。
后来找到了雷神的文章。ffmpeg的ios编译是网上随便找的，集成好了不要忘了包含头文件就可以了。然后就是雷神的文章主要有rtmp的推流部分，所以就尝试了集成进去，也能成功。只要关注最下面的oc代码，其他的不是很重要。RTMp的本地服务器的搭建，参考的是一篇简书的文章。

目前ios端的大部分应用都是采用的第三方来做这件事。LFLiveKit.（推流、硬编、软编） + HLS/RTMP/RTSP(协议)+ijkplayer（拉流-硬解、软解、播放）+GPUImage（美颜）

于是推流就变成了加一行推流网址的事，拉流也变成了加一行网址的事情，美颜也是一件美颜化的，这样不是不好，可以让程序员更多的功夫花费在业务逻辑上，去写送个礼物，刷个弹幕，来个特效什么的。但这样的弊端也很明显，就是无法了解直播的原理和本质。像 LFLiveKit.和ijkplayer 都是需要编译的 里面还包含了ffmpeg，还有看不见源码的静态库，要是公司不采用这套方案，要你自己写其中的一部分，就只能GG 了。还有一些要优化的细节，要怎么处理，那也只能GG了。

所以掌握并理解直播的整个流程才是最关键的。硬解也好，软解也好，都要自己去调，自己去试，掌握了传输的话，换协议也能做。不然就始终只能做一个api调用者罢了。

拉流部分我找了挺久也没找到，相关文章也没看到。后来在github上翻了挺久，发现了这篇全开源的的rtmp流源码，还有他的文章博客，确实是完全开源的，从推流到拉流都是全的。我试了一下把流推到本地服务器并用VLC播放完全没问题，然后拉了他自带的视频，也是非常出彩。
后续就研究一下他的代码，逐字逐句的分析他的代码，争取尽快掌握这些内容。