rtmp服务器 协议之同步

1、rtmp协议

rtmp协议出自adobe公司的设计，该设计非常精良，级联转发等也是设计良好，整体架构是非常产品化的，而adobe公司自身的fms，ams等服务器产品遵循该协议发布。性能优异，稳定。rtmp协议里面又包含了flv容器，而flv格式非常合适网络传输，这一点和实时传输协议rtp【realtime transfer protocol】协议类似，rtp协议的包头12个字节，简单却又融汇了传输的精髓。为了深刻理解协议，我们必须从发布端，服务器端，接收端三个端编写代码，从而能够让协议了然于心。在编写的过程中也许几经困难，因为三方调试并不知道哪一端出了问题，多忍，多分析，会造就自己分析问题得能力。

2 时间戳问题

时间戳问题一直是一个大的问题，该问题遍布了发布端，服务器端，接收播放端。

2.1 发布端

例如比较出名的obs studio，该发布端做得非常精彩，很多教师，学生，以及网络工作者喜爱该产品，尤其是在时间戳上面，做得非常到位，服务器在接收的时候包少，尤其是控制了音频包，熟悉rtmp协议的人知道rtmp是分trunk发送的，而每个trunk得时间戳是属于该帧得时间戳，是一样得。

2.2 服务端得相对和绝对

服务端接收得时间戳第一个是绝对时间戳，后面的都是相对时间戳，出家人不打诳语。像ffmpeg这样得发送方可能将第一个时间戳指定为0，这也是对得，ffmpeg并不期望直接是一个产品化得东西，而是我们自己必须理解时间戳，自己去改变。原则是：
当我们收到绝对时间戳是，整个时钟周期必须重新置位，重新开始，否则就是简单得相对时间戳累加成为真正得时间戳。

3 发布端

我们自己做了一个发布端，用于测试，该时间戳，预览、发送等等使用了最简单的方式，发布的方法大体又有三种
1 使用ffmpeg
2 使用librtmp
3 自己编写代码

如果说熟悉ffmpeg，那大可以使用ffmpeg来直接推流，方便简单，如果说熟悉librtmp，大可以使用librtmp来做，这两项都非常简单，但是时间戳还是稍复杂，最重要的还是理解。音频时间戳我们从服务端接收的时候，发现大约每隔23毫秒会发送一个，下图是自己的服务器打印时间戳，自已写一个服务器有利于理解协议，这个是值得的，虽然有很多开源的，例如nginx的rtmp模块开创了第一个服务器端的

3.1 音频时间戳得问题是：

23 毫秒是从哪里来得？当然这和我们得采集得模式有关系，我们采集音频得时候用44100HZ，也就是采样时间间隔是1/44100, 而每次采样得数据叫sample，是可以设定得，比如每次sample设置为1024，我们知道一般aac音频我们都喜欢设定这个值，ok，那帧间隔就可以计算出来了，把时间换算成毫秒， 每一个数据需要得时间是 1000/44100,那1024个数据需要多少时间呢?
1000*1024 / 44100 = 23.2
所以我们从服务器上打印就是23毫秒得间隔trunk时间，而因为这个trunk 又是小于我们设定得值如最大trunk为4096，实际上这一个trunk为一帧。
注意23是不精确得，所以每隔一定得时间，像ffmpeg这种方式会调整时间戳，偶尔输出一个不一样得时间。

3.2 视频时间戳得问题是：

100毫秒是哪里来得？从我们得服务器打印可以看出，9是flv容器中视频得typeid， 8是音频，每个9之间得相隔为100.
视频很直白，就是1秒钟采集10帧，1000/10 = 100.
在ffmpeg中发送得pts一定是这种值，在编码得时候，我们让视频得pts为每次加1，而发送得时间戳却必须调整为服务器接收到得时间戳，ffmpeg中得函数av_packet_rescale_ts就是这个作用

av_packet_rescale_ts(pkt, inAVCodecContext->time_base, _rtmp_video_stream->time_base);

这个函数让pkt里面得pts从单一得值转化到我们发送得频率值计算出真正得相对时间戳，注意是相对时间戳。

librtmp得时间戳使用绝对和相对得直接值，不像ffmpeg那样，所以我们简单得拿时间去做减法就行，所以，我们如果理解了时间戳，那就没有烦恼了。

3.3 排序问题

音频包和视频包是否需要排序输出，答案是不一定得，我们可以使用两种方式来做：
1 争抢发送
2 排序发送

服务器端

未完待续

接收端

未完待续