Low FPS rate on mjpeg streaming

[nerdtool]

 Hi, I've used your superb method to hack both the 720p and 1080p Merkury/Geeni cameras with great success. I can now access them through my Blue Iris and iSpy Agent DVR installations.  However, I find that I cannot get faster than 6 FPS from these hacked cams.  If I revert back to the Geeni / Tuya native Android apps and register with those, the speed is much faster but not accessible to my DVR solutions.
 Has anyone had similar issues?  And if so, is there a fix?

Regards, NerdTool

[guino]

What connection method are you using with the camera? RTSP with UDP or TCP ? ONVIF?

I would suggest you check what kind of FPS you get on VLC first to compare - I believe my devices give 15FPS and the recordings (files) generated reflect that. You could have some sort of network congestion causing slowness on the stream too (my 2.4ghz wifi is heavily congested and sometimes that causes my stream to be slow even inside the tuya app).

In any case the device is running the same ppsapp - there should be no difference in performance using the app with/without the changes but I can’t say much for their quality of RTSP/ONVIF code (it usually works well enough).

These are definitely not ‘professional’ level devices but it’s still nice being able to use RTSP/ONVIF and record together with other devices instead of being forced to use the app.

If by any chance you’re using the MJPEG URL you should know there’s no guarantee of FPS with that - it is mostly just a rig for view/monitoring the output but it is not intended for recording.

[sanscorp1]

I'm experiencing the same problems, aware of the quality of the HW but my server log on my NVR (Milestone Xprotect Essentials+) is flooded with disconnects and 15 FPS is not achieved.

I'm using RTSP / TCP and I'm having trouble on all camera's:

• 3x Indoor camera 1080
• 1x Outdoor camera
• 1x Doorbell

The WiFi is not congested and signal is 70 - 90% according to the Tuya app on android. Ping is mostly 14ms but spikes every few seconds to as high as 150ms.

Is there anything I can do to improve on the connection time-outs and FPS other then using the stream on channel 102? I have made sure all options in Tuya_config are disabled, recording, motion detection etc. etc. except for ONVIF.

I have yet to try the snapshot or MJPEG "streams"

[guino]

@sanscorp1 snapshot/MJPEG will never have good FPS (and has no audio) -- the MJPEG we have on these devices is a 'rig' I made mostly for preview.

With RTSP if you're using TCP (and not UDP) I would expect it to be stable and functional unless you're having wifi congestion (which is not uncommon on 2.4Ghz).

I would suggest you telnet into the devices and execute top then watch the CPU% usage before the NVR/RTSP connection and after -- If the CPU is close to 90% (or more) most of the time then your NVR may not be using TCP connection and the high CPU load may be the reason for timeout/FPS issues. If it is staying below 90% CPU usage then the only explanation would be wifi connection/congestion issues. I have tested streaming full HD on my doorbell with VLC for many hours at a time without any issues, so I know it is possible, but you also have to remember that multiple cameras on wifi streaming at once will also slow down your 2.4Ghz band by themselves already so you should try 1 camera by itself, then add another and so on to see if you get better results -- then consider making separate wifi (on different channel) to split up the cameras if required.

[sanscorp1]

I have been monitoring the CPU and it is averageing arround 20% on all cams. WiFi is not congested, very few AP's nearby and I'm using openwrt on enterprise 4 AP's (Aerohive).

Also, the Tuya stream in the android app isn't showing this behaviour of disconnects. There is more latency though.

Would it be possible to run a seperate "onvif server" on the camera's?

[guino]

@sanscorp1 The TUYA app does NOT use ONVIF/RTSP so it should not be used as any basis for comparison.

I suggest you try different apps on phone or PC (i.e. VLC) to see if the streams are stable (and I would run all cameras at once).

if there's no issue with one app/device and there's with another app/device then it is most likely some sort of incompatibility/issue with the device where the issue is showing up (i.e. NVR).

I will say a lot of people report odd issues with the ONVIF/RTSP from these devices so the incompatibility may be due to their ONVIF/RTSP implementation on the cameras.

I would not recommend adding any other kind of servers on these cameras as they're overloaded as-is, besides you would not be able to make a streaming server while keeping their proprietary app working as it already using the video hardware.

You could setup a ffmpeg rtsp client+server on a machine to stream from the cameras and re-stream into your NVR to see if it would prevent the disconnects/timeouts but this most certainly would add latency to the stream (something like this: https://stackoverflow.com/questions/66538527/ffmpeg-capture-a-rtsp-stream-and-re-stream-it-to-another-rtsp-server -- notice his comment about wallclock parameter). You could try with one camera, then 2, then all (if you use the same machine you'll need to give a different port for each camera).