motioneye-project / motioneye

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

FPS drop when a remote access #2549

Open ghost opened 2 years ago

ghost commented 2 years ago

Motion eye problem

Equipment used :

Software used:

Hello,

I have my IP camera that sends its video stream to motioneye via RTSP. And locally via motion eye the stream is smooth but when I access it remotely the stream jerks.

Try 1 : Local

Connection via VLC to the IP camera GS-GHXFSTWC5MA-KT, address: RTSP://192.168.0.39:554/11 Smooth video flow

Export NAT/PAT port 554 of the camera to UDP/TCP

And the same for motion eye port 80

Try 2 : Locally

Set up the IP camera in motion eye, address : rtsp://26ftpderveur.ddns.net:554/11

Connection to motion eye address 192.168.0.11 The video stream is smooth

Try 3 : Remote

Connect to motion eye http://26ftpserveur.ddns.net/ Video stream jerks FPS drop

Test 4: Remote

Connection to IP camera via VLC rtsp:26ftpserveur.ddns.net:554/11 The video is smooth

MichaIng commented 2 years ago

Sounds like a bandwidth issue, since the remote camera stream is "downloaded" by motion, passed over to motionEye, then "uploaded" to the client/browser. When connecting via VLC, the round trip through the motionEye server is skipped, when connecting from LAN, at least the upload doesn't affect Internet bandwidth.

ghost commented 2 years ago

Sounds like a bandwidth issue, since the remote camera stream is "downloaded" by motion, passed over to motionEye, then "uploaded" to the client/browser. When connecting via VLC, the round trip through the motionEye server is skipped, when connecting from LAN, at least the upload doesn't affect Internet bandwidth.

How to solve this problem do you have an idea?

MichaIng commented 2 years ago

A limited bandwidth? Reducing camera resolutions, amount of cameras streamed on web UI e.g.

But this is just the first theory I had in mind. Also check CPU usage, RAM usage, journalctl -u motioneye (logs) and such things, probably that gives another hint.

ghost commented 2 years ago

A limited bandwidth? Reducing camera resolutions, amount of cameras streamed on web UI e.g.

But this is just the first theory I had in mind. Also check CPU usage, RAM usage, journalctl -u motioneye (logs) and such things, probably that gives another hint.

image

For the use of the processor and correct and the same for the ram.

image

MichaIng commented 2 years ago

Could you try the new Python 3 based motionEye version from dev branch: https://github.com/motioneye-project/motioneye/tree/dev#installation

CPU usage is notable, but since you have multiple cores (?) not maxed. Did you try a different video format?

ghost commented 2 years ago

Could you try the new Python 3 based motionEye version from dev branch: https://github.com/motioneye-project/motioneye/tree/dev#installation

CPU usage is notable, but since you have multiple cores (?) not maxed. Did you try a different video format?

I've got the new version, it's the same thing. I also tried changing the video format, it's the same

ghost commented 2 years ago

You have another idea ?