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

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

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

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

@MrSheng 我还是认识不足

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

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

@JusticeLanding 好的.感谢.

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

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 等格式

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

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