[拉流,还是推流][GB28181]

[reanfly]

多场地,多 nvr. 需求度 流畅>清晰>延迟

以我的理解

拉流:即获取 rtsp 地址.在服务器搭建一个服务,拉.

推流.在场地里搞一个机器 ffmpeg 推流到 服务器.

问题

1.拉流镜头八个就转圈了.应该是场地上传带宽的问题吧.改成子码流就会好点,但是不清晰.拉流是应该无法控制码率吧,毕竟都是原始数据.

2.有没有做过 GB28181,比如 wvp-pro .我认为这种也是拉流吧.还是说可以动态改拉流的,这样场地带宽压力就能减小一点.

目前打算本地推流,写个客户端动态控制码率等视频质量.这样感觉工作量大一些,几十个镜头同时电脑要求也高.我测试同时推八个主码流.

[MrSheng]

1 、摄像头本身算力的问题，无法同时处理 8 路视频流；拉流可以控制码率，只要摄像头支持可变码率，没有所谓的原始数据，摄像头出来的视频编码基本都是 H264/H265
2 、GB28181 是推流，这个稍微看下协议就知道，一般支持及联的协议都是推流
3 、可以使用现成的项目，zlmediakit ，几十路的转发不会对电脑造成任何压力，瓶颈在上行带宽

[pming1]

用 GB28181 就好，在公网搭建一套 GB28181 的网关和 zlmediakit 服务器，完美。我们这样跑了上万台 NVR 一年多了

[reanfly]

@pming1 问个 low 的问题. 场地.装个 ffmpeg crf,还有码率了.各种参数.可以减少上传带宽.提示流畅度 .你们场地有这个没有?还是说全部通过 zlmediakit 来控制码率?

[reanfly]

@MrSheng 我还是认识不足

[pming1]

@reanfly nvr 直接配置到码率和编码，h265+1080p+2Mbps

[JusticeLanding]

@reanfly 除了摄像头端发出的视频流，编码时候能控制码率。后面一般都没法控制码率，想要重新控制码率，必须要重新编码，不管是服务器还是 NVR ，重新编码的代价太大了。
你的描述太不清楚了，把问题理理清楚。

[reanfly]

@JusticeLanding 好的.感谢.

[xwayway]

@pming1 想问一下，对服务端配置要求怎样？刚好公司有这方面的需求，想要提前了解下。推的话，按理说，nvr 多了，推的量会很大吧，可以由服务端控制推的时机么，就是我需要看哪个摄像头画面的时候再推，不看就不推

[suke119]

webrtc-stream 组件，https://github.com/mpromonet/webrtc-streamer 直接 RTSP 拉流,这个是直接 RTP 流到 webrtc 转换的，所以低延迟，消耗最少；如果你借助 ffmpeg 将 rtsp 转到 flv 或者 hls 流畅度上来说 HLS 要好点，但是 flv 会出现限制，也就是缓冲加载，所以建议 webrtc ；不想用 webrtc-stream ，那就剩下的 GB28181 推流到 ZLM 或者 SRS ，然后 webrtc 再从服务端拉流，目的还是低延迟但是中间还是 监控将流通过 RTP 的方式推流到 ZLM 或者 SRS 了，你提到的 GB+wvp 就是这个原理，通过 GB 协商 监控推流到 RTP 服务器，而 RTP 服务器就是 ZLM ； zlm 和 SRS 内部再将原始流转成 WebRTC 、RTMP 、RTSP 、HLS 、Flv 等格式

[pming1]

@xwayway GB28181 有定义的，按需通知 NVR 推流。简单理解，NVR 就是这个客户端，所有行为受服务端管控。

[reanfly]

目前基于 GB28181 ,搞了一套,省事多了.