GB28181 rtp2rtmp

平台：https://github.com/GB28181/Awesome

背景
GB28181协议凭借其在安防流媒体行业独有的大统一地位，目前已经在各种安防项目上使用。雪亮工程、幼儿园监控、智慧工地、物流监控等等项目上目前都需要接入安防摄像头或平台进行直播、回放。而GB28181协议作为国家推荐标准，目前基本所有厂家的安防摄像头、NVR、监控平台都支持此协议，这样就方便我们通过GB28181协议去获取各种厂家设备的视频流，而不用繁琐的对接每家设备的SDK。
GB28181获取视频流转RTMP、HLS、RTSP、HTTP-FLV进行直播
GB28181协议获取到的视频流为PS封装的RTP数据包，PS包是没法直接用web、播放器直接播放的。需要将获取到的PS流转成ES流，然后打包提供RTMP、HLS、RTSP、HTTP-FLV格式进行直播流分发。如此就实现了通过GB28181协议将安防摄像头流转成可Web、手机、微信、客户端等直播、回放、控制的互联网直播方式。

LiveGBS国标流媒体服务，就是按照这种设计方式实现的，同时提供了二次开发的http接口供用户集成使用。

背景技术：

ps流全称是节目流(programstream)，将一个节目的多个组成部分按照它们之间的互相关系进行组织并加入各组成部分关系描述后的码流。ps流是一种多路复用数字音频、视频等的封装容器，它是一个或多个具有共同的时间基准的pes流合并成一个整体流，主要用于节目存储。其包长不固定，且较长，一旦失去同步信息，接收机无法确定下一包的同步位置，会造成失步，导致严重的信息丢失。

rtmp是实时消息传输协议(realtimemessagingprotocol)。该协议基于tcp，是一个协议族，包括rtmp基本协议及rtmpt/rtmps/rtmpe等多种变种。rtmp是一种设计用来进行实时数据通信的网络协议，主要用来在flash/air平台和支持rtmp协议的流媒体/交互服务器之间进行音视频和数据通信。

在互联网直播领域中，主流的直播协议采用的rtmp和hls等协议，直接在网页上就可观看视频，不需任何插件，非常的方便。在如今的公共安全领域中主要是通过gb/t-28181进行设备级联，而gb/t-28181中的媒体流是rtp荷载的ps流，ps流中荷载视频格式是h.264。由于web浏览器无法直接支持ps流的点播，用户需要安装插件才可以播放ps流，插件需要适配各种浏览器和各种操作系统，插件兼容性差，而且用户体验也不好。再者，浏览器公司需要开发相应的插件，需要额外的开发工作量，浪费人力物力。因此需要一套将国标ps流转为rtmp流的系统，将公共安全领域的视频转到互联网直播领域。

技术特征：
1.一种国标ps流转rtmp直播流的实时转换方法，其特征在于，包括以下步骤：

s1：从收流端口接收荷载ps流的rtp数据包，先查找第一个荷载着ps包头的rtp包，然后将荷载着ps包的rtp包放到ps包缓存中，并检查rtp包的sequence是否连续，如果不连续则缓存清空；

s2：对ps包缓存中rtp包解析，同时继续不断接受rtp包放到ps包缓存中，直到接收完一个完整的ps包，将这个完整ps包中荷载的视频数据解析出来，放到视频h.264缓存中；

s3：将ps包中拆出的h.264数据进行拆帧，将拆分出的的每一个完整的h.264帧放到帧缓存中；

s4：将完整的h.264帧打包成rtmp，然后通过url推流给rtmp流媒体服务器。

2.根据权利要求1所述的国标ps流转rtmp直播流的实时转换方法，其特征在于，所述h.264帧包括sps、pps、关键帧。

3.根据权利要求1所述的国标ps流转rtmp直播流的实时转换方法，其特征在于，web浏览器或vlc播放器通过url向rtmp流媒体服务器拉流进行视频点播

技术总结
本发明公开一种国标PS流转RTMP直播流的实时转换方法，属于视频技术领域，包括以下步骤：S1，从收流端口接收荷载PS流的RTP数据包，先查找第一个荷载着PS包头的RTP包，然后将荷载着PS包的RTP包放到PS包缓存中，并检查RTP包的Sequence是否连续，如果不连续则缓存清空；S2，对PS包缓存中RTP包解析，同时继续不断接受RTP包放到PS包缓存中，直到接收完一个完整的PS包，将这个完整PS包中荷载的视频数据解析出来，放到视频H.264缓存中；S3，将PS包中拆出的H.264数据进行拆帧，将拆分出的的每一个完整的H.264帧放到帧缓存中；S4，将完整的H.264帧打包成RTMP，然后通过URL推流给RTMP流媒体服务器。本方案解决浏览器无法直接播放公共安全领域的视频流需要使用插件的问题。

技术研发人员：毕凯强;万森;刘子龙;陈小奇;刘琼;张敬锋
受保护的技术使用者：安徽云森物联网科技有限公司
技术研发日：2019.09.30
技术公布日：2020.02.04

第二种方案：
https://www.cnblogs.com/babosa/p/11124026.html
最近一家深耕于南方电网的科技公司同事找到我们，咨询关于调用海康HCNetSDK取流，并进行互联网转化的方案，经过反复的沟通以及自身在EasyDSS和EasyNVR
方面的经验，我们推荐了海康HCNetSDK+EasyRTMP推流到RTMP流媒体服务器，再由RTMP流媒体服务器同步输出RTMP/HTTP-FLV/HLS的方案。

一般情况下我们在对接一款设备，进行流处理和流转的大概流程分为：

第一步：设备对接协议的选择
无论是以RTSP、Onvif协议从设备取流，还是国标GB/T28181向设备取流，都是根据设备所支持的协议，通过协议过程获取到设备回调的音视频数据，例如这里要说的海康HCNetSDK；

在取流协议的选择上，就看自身的应用需求，比如您的设备只有海康的，那么您完全可以用海康的SDK来取流，但是如果您的设备是各种厂家都有，而且不固定，建议采用的是RTSP这种国际标准的取流方式。

海康HCNetSDK是一套完全可以兼容海康几乎全部的IPC、DVR、NVR、NVS的客户端SDK，当现实场景中会不定存在很多款的设备型号，而且输出协议不一样，那么，海康的设备选择HCNetSDK是一个极佳的选择，因为海康已经将所有底层的兼容工作在HCNetSDK中完成了；

那么，以RTSP取流为例，我们在开源或者商用领域有很多可选的，比如ffmpeg、live555和EasyRTSPClient（https://github.com/EasyDSS/easyRTSPClient）；

第二步：数据处理与分析
从第一步取到音视频流后，我们需要将流统一Demux为ES流进行进一步的处理，例如海康SDK输出的大部分流为PS流，我们需要将PS解析成ES的音视频数据，再基于ES的音频、视频数据进行例如：快照、视频信息、转码、视频分析等多种操作。这里关于海康PS流的Demux操作以及相关的代码，我们会在下一篇博客中专门进行讨论。

第三步：推流与分发
在第二步进行了初步的数据处理后，我们需要将ES音视频数据通过librtmp、ffmpeg 或者 EasyRTMP（https://github.com/EasyDSS/EasyRTMP）推送到nginx-rtmp 或者 EasyDSS 流媒体服务器进行高性能分发和存储，并提供一系列的对外管理接口；

第四步：接口化处理
完成了以上3步，只能算是跑通了整个数据流程，我们还需要对整个流程进行控制，例如，当有客户端请求观看的时候，我们才启动取流、转码、推流、分发的过程，当用户停止观看或者一段时间内超时未进行服务端保活，服务端即停止整个流转的过程。

同时，我们需要将对某个设备的取流、取录像的过程均以接口的形式对外输出（参考EasyNVR的实现），这样一套底层可以提供给多个现场，多种项目使用。

三
首先说明一下nalu的格式
nalu由三个部分组成：开始码（0x01000000)+nalu头+nalu数据。
使用live555 testrtspclient那个例子来接收rtp流，接收到的nalu是没有开始码的，
需要自己加上起始码，然后喂个ffmepg的packet.data，然后就可以解码了，
将sps，pps补偿给ffmepg：

  在ffmpeg解码其他nalu之前，需要将h264视频流的 sps，pps补偿给ffmepg，这两个东西也是nalu

在rtsp的连接过程中，describe命令响应那里，可以拿到sps，pps，拿到的是使用了base64编码的
需要进行base64解码，解码出来的sps，pps是没有起始码的nalu，需要自己加上起始码，
然后喂给ffmepg的packet.data，然后解码这两个nalu即可，这样ffmepg就知道了视频的宽度高度
这些信息了，这样就可以解码后面的nalu视频流数据了。

https://blog.csdn.net/chen495810242/article/details/39207305
RTP协议全解析（H264码流和PS流）
上述这个有github相关代码

https://blog.csdn.net/zhoubotong2012/article/details/86502327?utm_medium=distribute.pc_relevant.none-task-blog-searchFromBaidu-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-searchFromBaidu-2.control
如何发送和接收RTP包，用FFmpeg分离、解码，跟gb28181代码对比就基本可以做出接受了

https://blog.csdn.net/qq_40732350/article/details/88374707
除了上表中明确指定PT值的负载类型，还有些负载类型由于诞生的较晚，没有具体的PT值，只能使用动态（dynamic）PT值，即96到127，这就是为什么大家普遍指定H264的PT值为96。下表中列出了没有具体PT值的负载类型

RTP 是目前解决流媒体实时传输问题的最好办法，如果需要在Linux平台上进行实时流媒体编程，可以考虑使用一些开放源代码的RTP库，如LIBRTP、 JRTPLIB等。 JRTPLIB是一个面向对象的RTP库，它完全遵循RFC 1889设计，在很多场合下是一个非常不错的选择，下面就以JRTPLIB为例，讲述如何在Linux平台上运用RTP协议进行实时流媒体编程。

https://blog.csdn.net/stone_overlooking/article/details/77197259
在Linux中编译jrtplib

other:
https://github.com/Lycycz/GB28181_RTMP
https://download.csdn.net/download/cuiyaonan2000/11383823
https://blog.csdn.net/songxiao1988918/article/details/81806831?utm_medium=distribute.pc_relevant.none-task-blog-title-3&spm=1001.2101.3001.4242

https://blog.csdn.net/g0415shenw/article/details/80385088?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-8.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-8.control
Gb28181之Ps流解析H264