ZLMediaKit流媒体服务器 RTSP推流时候的堆栈

先直接看图 这是ffmpeg向流媒体服务器推流时候的堆栈 引入C++ 11之后  堆栈会显得特别繁复冗余 看起来 也没有 以前没有C++11之前那样 简单明了 

 太复杂了 标记下  很多函数名字被我改了 因为原来的看起来 同名函数太多了

C++11 和lambada 匿名函数 让看堆栈 成了地狱模式 

断点断在  DemuxInputRtp 这个函数 这个是我改了名字的 之前是叫inputRtp 叫这个名字的函数太多了，所以给重新改了个名字  这样 看起来 会清晰一点 

从eventpoller里面的 RunLoop函数开始  慢慢开始看 

cb这个标黄的316行这里 

 之后会走到 这个ReadData函数

 ReadData函数 中 不管UDP还是TCP都是通过recvfrom这个函数 从内核接收网络数据

 正常流程会走到 _on_read这个回调

这个回调是在tcpserver onAcceptConnection中设置的 如下图

一般流程会走到onRecv那个回调去

 这个onRecv回调就是创建tcpserver的时候 根据不同的类型 比如HttpSession  RtspSession 在其对应cpp文件中 去实现这个虚函数

我的工程中 没有全部按照官方的代码 走 很多地方 为了便捷 就服用了httpsession中的部分代码 

所以 我的代码中会走到HttpSession的onRecv中  这个ProcessData函数也是我重新命名了 

 再看ProcessData函数 他会给收到的数据 组装或者拆分成对应的 head和 content数据

之后会调用 onRecvHeader或者 onContentRecv函数  这两个函数不同协议实现方式不一样

如下图

 

对于RTSP协议来说  如下图 会区分成是rtsp交互的sdp数据 还是媒体rtp数据 如下图

 rtsp协议的各种方法 媒体描述信息都是在onWholeRtspPacket那个函数里面处理的

这里我们只关心媒体数据 代码中已经给出注释 rtcp先不管 所以我们会走到handleOneRtp这个函数里

 

PushRtpData也是我改名字了的函数 最后 会走到 sortPacket这里  

 

 

 

这个cb设置的有两个地方

 

 

实现体就是 推流的走到这个onWrite函数

 至此 终于走到我们打断点的地方了

 这里根据不同的媒体类型 会调用不同的inputRtp函数 我们这里是 H264

 

这里的decodeRtp函数中会将Rtp包重新组装成H264 packet包

 分别是上面标黄的三个函数

在mergeFu 和 singleFrame函数中  会调用outputFrame函数如下图

 

 outputFrame函数又调用了基类的inputFrame函数 之后通过obtainFrame函数开辟一个新的Frame

 

_delegates的定义如下

 这个map是在addDeletegate中添加的

再看下谁调用了这个addDelegate函数即可 是在rtspdemuxer类中

 

刚刚那里的inputFrame自然就是调用了如下的代码

 

 然后走到RtspMediaSourceMuxer 的inputFrame函数中

 

 这里终于走到encoder了 之前一直是decoder  demuxer

这里是 muxer encoder

 

 

 

 不管是那个packRtp都会走到 RtpCodec::inputRtp 

将rtp数据写进环形队列

 

 

 最终会走到  大概应该是将这个数据填充到ringbuffer里面

   

 暂时先分析到这