如何使用 nginx 反向代理 IP 摄像机的 mjpeg 流?

发布于 2024-11-19 00:25:25 字数 231 浏览 6 评论 0原文

我在 OpenWRT 上使用 nginx 来反向代理来自 IP 摄像机的运动 jpeg 源,但即使在相当低的帧大小和速率下,我也遇到了长达 10-15 秒的延迟。将 OpenWRT 设备从路径中移除后,即可毫无延迟地访问相机。

由于延迟的长度(以及它随时间增长的事实),这看起来像是某种缓冲/缓存问题。我已经设置了 proxy_buffering 关闭,但是还有什么我应该注意的吗?

谢谢。

I'm using nginx on OpenWRT to reverse-proxy a motion-jpeg feed from an IP camera, but I'm experiencing lag of up to 10-15 seconds, even at quite low frame sizes and rates. With the OpenWRT device removed from the path, the camera can be accessed with no lag at all.

Because of the length of the delay (and the fact that it grows with time), this looks like some kind of buffering/caching issue. I have already set proxy_buffering off, but is there something else I should be watching out for?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

半步萧音过轻尘 2024-11-26 00:25:25

我在 Arduino Yun 上安装了 mjpg-streamer,然后在我的路由器设置中设置仅将端口转发白名单到我的网络服务器。

这是我的 Nginx 配置,它位于启用站点的目录中。

server {
  listen      80;
  server_name cam.example.com;
  error_log /var/log/nginx/error.cam.log;
  access_log /var/log/nginx/access.cam.log;

  location    / {
    set $pp_d http://99.99.99.99:9999/stream_simple.html;
    if ( $args = 'action=stream' ) {
      set $pp_d http://99.99.99.99:9999/$is_args$args;
    }
    if ( $args = 'action=snapshot' ) {
      set $pp_d http://99.99.99.99:9999/$is_args$args;
    }

    proxy_pass $pp_d;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Request-Start $msec;
  }
}

I installed mjpg-streamer on an Arduino Yun, and then in my routers settings setup port forwarding whitelisted to my webserver only.

Here is my Nginx config which lives in the sites-enabled directory.

server {
  listen      80;
  server_name cam.example.com;
  error_log /var/log/nginx/error.cam.log;
  access_log /var/log/nginx/access.cam.log;

  location    / {
    set $pp_d http://99.99.99.99:9999/stream_simple.html;
    if ( $args = 'action=stream' ) {
      set $pp_d http://99.99.99.99:9999/$is_args$args;
    }
    if ( $args = 'action=snapshot' ) {
      set $pp_d http://99.99.99.99:9999/$is_args$args;
    }

    proxy_pass $pp_d;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Request-Start $msec;
  }
}
山有枢 2024-11-26 00:25:25

我对 nginx 的工作从未感到满意。根据您的具体需求,两种解决方案可能就足够了:

  • 如果您可以容忍流位于不同的端口上,请使用 OpenWRT 内置防火墙的端口转发功能将其通过。

  • 使用tinyproxy的反向代理功能。默认包具有通过标志禁用的反向代理功能,因此您需要轻松地自行检查和构建它。这种方法肯定更麻烦,但也有效。

我仍然有兴趣听到有人使用 nginx 来实现这一点。

I never got this working to my satisfaction with nginx. Depending on your specific needs, two solutions which may be adequate:

  • if you can tolerate the stream being on a different port, pass it through using the port forwarding feature of OpenWRT's built-in firewall.

  • use the reverse-proxy capabilities of tinyproxy. The default package has the reverse-proxy capabilities disabled by a flag, so you need to be comfortable checking out and building it yourself. This method is definitely more fiddly, but does also work.

I'd still be interested to hear of anyone who gets this working with nginx.

○愚か者の日 2024-11-26 00:25:25

我在 Openwrt BB (wndr3800) 上使用 Nginx 反向代理到 dlink 932LB1 ip cam,并且运行良好。即使在我禁用 proxy_buffering 之前,也没有明显的延迟。如果我有很多东西通过网络传输,视频可能会变得断断续续,但不会比从浏览器(或从我的任何网络摄像头应用程序)直接连接到摄像机的链接更糟糕。所以……这是可能的。

Nginx 是我的最佳选择。我尝试过tinyproxy & lighttpd 用于反向代理,但每个都缺少 OpenWrt 上的功能。 tinyproxy 和 lighttpd 都需要自定义编译才能获得完整的反向代理功能,并且(据我所知)lighttpd 不会接受代理指令中的 FQDN。

这就是我要做的:

  • 面向公众的 Nginx 上的基本或摘要身份验证提供站点范围的访问控制。
  • 我将我的 CGI 脚本(shell、haserl 等)代理到 Openwrt 的 uhttpd。
  • 严格控制相机 mjpeg 和 mjpeg 的反向代理jpeg API,无
    其他相机功能向公众公开。
  • 相机基本身份验证由 Nginx (proxy_set_header) 处理,因此没有后端
    授权码公开。
  • 占用空间相对较小(没有 perl、apache、ruby 等)。

我会在这里包含我的 nginx.conf,但它没有什么不寻常的......只是简单的代理内容。如果流量确实是罪魁祸首,您可以尝试 tcpdump 或wireshark 来查看是什么使您的 LAN 混乱。

但听起来你的路由器的某些问题是造成延迟的原因。也许硬件无法处理 cpu/流量负载,或者您的 Openwrt 设置上可能有其他东西占用了高速公路。您的视频是否流畅,只是有延迟?或者您是否看到了严重断断续续的视频?你提到的延长延迟听起来确实像是缓冲区/缓存的事情......但我不知道会做什么。

I have Nginx on Openwrt BB (wndr3800) reverse-proxying to a dlink 932LB1 ip cam, and it's working nicely. No significant lag, even before I disabled proxy_buffering. If I have a lot of stuff going over the network, the video can get choppy, but no more than it does with a straight-to-camera link from the browser (or from any of my ip cam apps). So... it is possible.

Nginx was the way to go for me. I tried tinyproxy & lighttpd for the reverse proxying, but each has missing features on OpenWrt. Both tinyproxy and lighttpd require custom compilation for the full reverse proxy features, and (AFAIK) lighttpd will not accept FQDNs in the proxy directive.

Here's what I have going:

  • Basic or digest auth on public facing Nginx provides site-wide access control.
  • I proxy my CGI scripts (shell, haserl, etc) to Openwrt's uhttpd.
  • Tightly controlled reverse-proxy to the camera mjpeg & jpeg API, no
    other camera functions are exposed to the public.
  • Camera basic-auth handled by Nginx (proxy_set_header), so no backend
    authorization code exposed to public.
  • Relatively small footprint (no perl, apache, ruby, etc).

I would include my nginx.conf here, except there's nothing unusual about it... just the bare bones proxy stuff. You might try tcpdump or wireshark to see what's cluttering your LAN, if traffic is indeed your culprit.

But it sounds like something about your router is the cause of the delay. Maybe the hardware just can't handle the cpu/traffic load, or there could be something else on your Openwrt setup that is hogging the highway. Is your video smooth and just delayed? Or are you seeing seriously choppy video? The lengthening delay you mention does sound like a buffer/cache thing... but I don't know what would be doing that.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文