search

motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
3.94k stars 651 forks source link

Slow streaming fps when connected remotely using dataplicity #2419

Open Febey opened 2 years ago

Febey commented 2 years ago

My problem The streaming fps is very slow(<1fps) when I connect to motioneye remotely. Capture fps is ok. I access my raspeberry pi (behind NAT) using dataplicity which allows me to access port 80 remotely. (so only one port is accessible). I dont use motioneyeOS so i have changed the webport from 8765 to 80. Local wifi streaming fps is ok and almost similar to capture fps.

The camera is using rtsp and I have tried both tcp and udp streams and both primary and secondary stream (lower resolution) with the same results. However the delay is significantly longer on primary stream. Also changing resolution (both in motioneye and on camera itself) or quality (in camera settings) does not improve fps.

I have also tried with the streaming url pointing to port 80 and watched that remotely. Although fps is quite inconsistent it feels higher then watching the stream in motioneye.

Any ideas how I could continue my troubleshooting?

My Setup Raspberry pi 4 WiFi 4g router Huawei e8372 network camera camhipro, connected using rtsp.

motionEye Version | 0.42.1 Motion Version | 4.3.2 OS Version | Raspbian 11

image camera-1.conf.txt motion.conf.txt motioneye.conf.txt

MichaIng commented 2 years ago

Many thanks for your report.

Before we invest time into the Python 2 version, could you try it out with the dev branch motionEye using Python 3 and newer module/library versions? https://github.com/motioneye-project/motioneye/tree/dev#installation

Febey commented 2 years ago

Thanks for your reply. I followed the instructions and now I have these versions.

motionEye Version | 0.43.0 Motion Version | 4.3.2 OS Version | Raspbian 11

Unfortunately the issue with slow fps is still there. I didnt change any configuration after the update, they appear to be the same, camera config and motioneye listening on port 80. Should I update Motion as well (not sure which versions are supported by motioneye)?

MichaIng commented 2 years ago

Should I update Motion as well (not sure which versions are supported by motioneye)?

No, 4.3.2 is best, 4.4 is not yet fully supported by motionEye: #2333

Btw with "remote" connection you mean connecting to the motionEye web interface through the Internet? And it has nearly capture FPS when you connect to the motionEye web interface from within your LAN?

Febey commented 2 years ago

Yes, so within LAN it works fine but with remote, as in I access motionEye web over internet its low fps. The pi uses a 4g router so I guess it could be poor network speed but I felt that the fps would have changed more when setting different resolutions or when I added the secondary stream.

Could it be that I need to open more ports, or should it be enough to only have one port open?

Dataplicity (which I need to bypass the NAT) list these limitations. Not sure what to expect with these limitations if they could explain the low fps. Perhaps I should find an alternative for dataplicity.

Running speedtest on my pi gives this.

Retrieving speedtest.net configuration...
Testing from Telenor Sverige AB (###)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Telenor AB (Stockholm) [397.42 km]: 53.336 ms
Testing download speed................................................................................
Download: 53.04 Mbit/s
Testing upload speed......................................................................................................
Upload: 8.65 Mbit/s
MichaIng commented 2 years ago

Could it be that I need to open more ports

motionEye is only listening on a single port as of the config, other ports would remain unused. Also a port cannot be a bandwidth limiter 😉.

Generally, when those are external RTSP streams, it is thinkable that your Internet or dataplicity bandwidth is the limiting factor. Those streams are reaching the server (inbound/download traffic) and then passed to the client (outbound/upload traffic). If the bandwidth unit is used commonly here, 1.5Mbps = 1.5 Mbit/s < 8.65 Mbit/s upload bandwidth, which can be too low for high resolution streams, indeed. Worth a shot to forward port 80 directly via NAT and skip dataplicity, at least for testing whether this helps.