rv1126 GB28181开源服务端播放问题分析及解决

1.问题分析

由于LiveGBS和EasyGBS的试用都到期了，而且为了测试设备端的兼容性和稳定性，找了一个开源的流媒体服务器框架和sip信令服务器框架：ZLM+Wvp-GB28181，但是搭建起来之后，发现rv1126上的应用推流，服务端web前端显示没有成功播放出来，但是用ipc以及用gb28181的拉流直接推流的测试程序，都可以正常播放出来，后来抓包对比发现是gb28181推流程序有个地方不规范导致的，分析过程如下。

1.可以正常播放出来的抓包截图如下：

2.不能正常播放的抓包截图如下：

对比就很容易看出一个差别，就是Seq值，不能正常播放的抓包可以看出，每一帧开始的时候，Seq重置了，Mark标识每帧的最后一个包，而开源服务器刚好会根据rtp包的Seq值进行查重处理，开源流媒体框架的wiki如下：

ZLMediaKit支持GB28181的 ps-rtp推流，支持的编码格式分别为 h264/h265/aac/g711/opus。 在收到GB28181推流后，ZLMediaKit会依次做以下事情：

• rtp排序去重。
• rtp解析成ps或ts。
• ps或ts解析成h264/h265/aac/g711/opus。
• 输入到复用器，生成rtsp/rtmp/ts/fmp4等格式，以便转换成其他协议或容器。

2.解决方法

查设备端处理，发现rtp的seq值每一帧都会重置，将seq值由局部变量改为全局即可，如下修改：

//组包rtp
int rtp_packet_count = ((index - 1) / single_packet_max_length) + 1;

for (int i = 0; i < rtp_packet_count; i++)
{
    gb28181_make_rtp_header(rtp_header, ctr->rtp_seq, ctr->pts, atoi(ctr->ssrc.c_str()), i == (rtp_packet_count - 1));

    int writed_count = single_packet_max_length;

    if ((i + 1) * single_packet_max_length > index)
    {
        writed_count = index - (i * single_packet_max_length);
    }

将rtp_seq改成全局，并且每一路不同记录控制即可解决问题。

另外注意：seq每帧都重置的程序，在livegbs和easygbs上都可以正常使用，在一个外网测试服务器上（免费试用），也可以正常使用，暂时不清楚他们的处理，为了规范统一修改了，seq值每包累加。