这是一个创建于 181 天前的主题，其中的信息可能已经有所发展或是发生改变。
多场地,多 nvr. 需求度 流畅>清晰>延迟
以我的理解
拉流:即获取 rtsp 地址.在服务器搭建一个服务,拉.
推流.在场地里搞一个机器 ffmpeg 推流到 服务器.
问题
1.拉流镜头八个就转圈了.应该是场地上传带宽的问题吧.改成子码流就会好点,但是不清晰.拉流是应该无法控制码率吧,毕竟都是原始数据.
2.有没有做过 GB28181,比如 wvp-pro .我认为这种也是拉流吧.还是说可以动态改拉流的,这样场地带宽压力就能减小一点.
目前打算本地推流,写个客户端动态控制码率等视频质量.这样感觉工作量大一些,几十个镜头同时电脑要求也高.我测试同时推八个主码流.
 |
1
MrSheng 181 天前
1 、摄像头本身算力的问题，无法同时处理 8 路视频流；拉流可以控制码率，只要摄像头支持可变码率，没有所谓的原始数据，摄像头出来的视频编码基本都是 H264/H265
2 、GB28181 是推流，这个稍微看下协议就知道，一般支持及联的协议都是推流 3 、可以使用现成的项目，zlmediakit ，几十路的转发不会对电脑造成任何压力，瓶颈在上行带宽 |
 |
2
pming1 181 天前
用 GB28181 就好，在公网搭建一套 GB28181 的网关和 zlmediakit 服务器，完美。我们这样跑了上万台 NVR 一年多了
|
 |
3
reanfly OP @pming1 问个 low 的问题. 场地.装个 ffmpeg crf,还有码率了.各种参数.可以减少上传带宽.提示流畅度 .你们场地有这个没有?还是说全部通过 zlmediakit 来控制码率?
|
 |
6
JusticeLanding 181 天前
@reanfly 除了摄像头端发出的视频流，编码时候能控制码率。后面一般都没法控制码率，想要重新控制码率，必须要重新编码，不管是服务器还是 NVR ，重新编码的代价太大了。
你的描述太不清楚了，把问题理理清楚。 |
|
7
reanfly OP @JusticeLanding 好的.感谢.
|
 |
8
xwayway 181 天前
@pming1 想问一下，对服务端配置要求怎样？刚好公司有这方面的需求，想要提前了解下。推的话，按理说，nvr 多了，推的量会很大吧，可以由服务端控制推的时机么，就是我需要看哪个摄像头画面的时候再推，不看就不推
|
 |
9
suke119 181 天前
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 等格式
|
1 |
11
reanfly OP 目前基于 GB28181 ,搞了一套,省事多了.
|
Select Language