Closed turbo2ltr closed 3 years ago
It is available in v2 and v3. You configure a normal "screen" with one "stream", if you hit the corresponding number Rpisurv will switch to that screen and display that one stream fullscreen. The first screen would have multiple streams, each of those streams you can additionally configure in a dedicated screen. So you can bring them all fullscreen with the corresponding numpad number. Disable autorotation if you do not want Rpisurv to cycle between the screens himself. But you can do all kind of combinations.
Ahh, that's what I did, but was hoping for a feature that didn't have to reconnect to the stream. If I want to go fullscreen, it's usually because I see some activity I need to see larger. Even though it's already connected in the multi-screen view, switching to a different screen seems to reconnect to the stream (using the same RTSP url for both screens). This takes time and leaves 6 seconds I'm completely blind. Was hoping there was more of a zoom feature that would switch quickly rather than completely switching screens/reconnecting streams.
Looks like it isn't going to matter. I'm not sure what the issue is but no matter what I do, RTSP streams from unifi UDMP Pro just will not stay running. It connects up fine, streams for 30 seconds to several minutes before all the streams just freeze. You don't even know it's frozen. It is so frustrating that there are no good solutions for real-time viewing of unifi protect streams. Viewing it using the unifi protect webpage in chromium has been the most stable but with more than 3 streams it tends to crash several times a day (which is still more stable than any other sdolution). And I thought maybe I'd update it and see if it's any better and now it doesn't run at all. Sorry... /rant. closing.
Ahh, that's what I did, but was hoping for a feature that didn't have to reconnect to the stream. If I want to go fullscreen, it's usually because I see some activity I need to see larger. Even though it's already connected in the multi-screen view, switching to a different screen seems to reconnect to the stream (using the same RTSP url for both screens). This takes time and leaves 6 seconds I'm completely blind. Was hoping there was more of a zoom feature that would switch quickly rather than completely switching screens/reconnecting streams.
If it happens to be the next screen it will be in cache, but otherwise, yes you have to wait a little for the reconnecting.
Looks like it isn't going to matter. I'm not sure what the issue is but no matter what I do, RTSP streams from unifi UDMP Pro just will not stay running. It connects up fine, streams for 30 seconds to several minutes before all the streams just freeze. You don't even know it's frozen. It is so frustrating that there are no good solutions for real-time viewing of unifi protect streams. Viewing it using the unifi protect webpage in chromium has been the most stable but with more than 3 streams it tends to crash several times a day (which is still more stable than any other sdolution). And I thought maybe I'd update it and see if it's any better and now it doesn't run at all. Sorry... /rant. closing.
Did you try rpisurv v3 with vlc player?
Yes. I believe I also previously tried it with the package here https://github.com/Anonymousdog/displaycameras to no avail. Guessing it's a Unifi issue. If I switch screens it comes back, but freezes up again within a minute.
So changing it to tcp helped and only having one stream helped as well. The time-before-lockup appears to be proportional to the number of streams. But even with one stream, it still eventually freezes which makes me think it some sort of overflow. It doesn't appear to be a resource issue on the pi side. Plenty of CPU and memory available (4B 4GB). I'm not even streaming the full HD streams..
I had the whole screen routinely going blank for a second or 4 and disabling overscan solved that.
I opened 4 VLC players playing the same 4 streams on my windows PC and they all seem to be doing fine so maybe it's not the UDMP. There's just something about the Pi that it doesn't like these streams no matter what player.
So I've been testing using VLC command line and verbose output. I was seeing a "runaway" condition with "picture too late to be displayed" right when it would freeze. So I ran it using --rtsp-frame-buffer-size=500000 (also using --no-audio) and so far it's been running longer than it ever has. It still gets the errors but hasn't frozen yet. Currently running 2 streams.
So I see the freeform_advanced_vlc_options
option. I've added --rtsp-frame-buffer-size=1000000
and we'll see how that goes..
I don't want to celebrate too early, but I have 4 streams on one screen running for over an hour which is the longest so far.
Current setup: All streams have the following options
rtsp_over_tcp: True
freeform_advanced_vlc_options: " --rtsp-frame-buffer-size=1000000 "
My /boot/config.txt has the following:
gpu_mem=512
disable_overscan=1
and the one thing that I think finally made the difference:
dtoverlay=vc4-fkms-v3d
The line was there but was commented out.
4 hours later, it's been rock solid!
12 hours later and it's been rock solid. I sent you a little something. This has solved the issue of live viewing my unifi cams that I've been trying to solve for nearly 2 years. Thanks!
Thanks for sharing the solution and the support!
I see issue #46 says it was implemented in v2 beta. Did it make it to V3_latest? If so how does it operate? I don't see any mention of the feature in the readme or the display yml.