Raspberry Pi4 + Pi5 - rpisurv 4.0.0

[gabiX87]

I have installed rpisuv 4.0.0beta2 -> Raspberry Pi4 + 2024-10-22-raspios-bullseye-armhf.img

The installer put rpisurv into /home/rpisurv with .yml config files

there is no longer rpisurv service

sudo service lightgdm start does not start rpisurv

● lightdm.service - Light Display Manager
     Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2024-11-03 13:57:50 CET; 12s ago
       Docs: man:lightdm(1)
   Main PID: 2278 (lightdm)
      Tasks: 7 (limit: 1599)
        CPU: 1.948s
     CGroup: /system.slice/lightdm.service
             ├─2278 /usr/sbin/lightdm
             ├─2374 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
             └─2393 lightdm --session-child 14 21

Nov 03 13:57:50 raspberry systemd[1]: Starting Light Display Manager...
Nov 03 13:57:50 raspberry lightdm[2278]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Nov 03 13:57:50 raspberry systemd[1]: Started Light Display Manager.
Nov 03 13:57:52 raspberry lightdm[2293]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Nov 03 13:57:52 raspberry lightdm[2293]: pam_unix(lightdm-autologin:session): session opened for user rpisurv(uid=1001) by (uid=0)
Nov 03 13:57:53 raspberry lightdm[2293]: pam_unix(lightdm-autologin:session): session closed for user rpisurv
Nov 03 13:57:55 raspberry lightdm[2384]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Nov 03 13:57:55 raspberry lightdm[2384]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=110) by (uid=0)

pi@raspberry:/home/rpisurv/bin $ ./rpisurv

(xfwm4:2535): Gtk-WARNING **: 14:04:27.443: cannot open display: :0
Traceback (most recent call last):
  File "/home/rpisurv/lib/surveillance.py", line 7, in <module>
    from core.util.config import cfg
  File "/home/rpisurv/lib/core/util/config.py", line 1, in <module>
    import yaml
ModuleNotFoundError: No module named 'yaml'

Tried to play H264 2866x1512 RTSP stream and it works without flickering.

pi@raspberry:/home/rpisurv/lib/core $ mpv rtsp://192.168.2.150:7447/xqcMN3QDr17t7ju9
 (+) Video --vid=1 (h264 2688x1512 30.000fps)
 (+) Audio --aid=1 (aac 1ch 16000Hz)
     Audio --aid=2 (opus 2ch 48000Hz)
File tags:
 Title: D021F996DFA9_0
[vo/sdl] Using opengl
[vo/sdl] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the sdl VO.
AO: [pulse] 16000Hz mono 1ch float
VO: [sdl] 2688x1512 yuv420p
AV: 00:00:14 / 00:00:15 (91%) A-V:  0.000 Dropped: 161

Going to try Raspberry Pi 5 .....

[SvenVD]

Thanks for testing, in version 4 there isn't a rpisurv service anymore. It gets autostarted with the lightdm service. So if you restart that service that is the same as restarting rpisurv.

Rpisurv version 4 was developed on Intel N100 It will not work out of the box for any version of the raspberry pi. I hope the community will discover the missing pieces to get it to work on at least a raspberry pi 5. If the missing pieces are found then I can incorporate them in the installer, documentation or rpisurv itself.

[SvenVD]

Before running the installer, you need to make sure you have a working X11 window manager on Raspberry pi 5. Preferable with Ubuntu so we can keep that aligned with other hardware.

[gabiX87]

I have test the 4.0.0beta2 on Raspberry Pi 5 2GB RAM + Ubuntu Desktop 24.10 (64-bit).

It works with H264 and H265 but both (2688x1512) streams freeze after a minute or so ... and nothing happens. Same thing with 1080p stream.

EDIT: 1080p solo stream seems to be doing fine ...

Two 1080p streams worked for a minute or so then the CPU utilization jumped to 100% and both froze ...

[SvenVD]

Thanks, Nice progress! was there anything special you need to do to come to this point. Or was it installing ubuntu and then run install.sh?

Does the mpv also freezes when running standalone?

[SvenVD]

Maybe this topic can provide some hints https://forums.raspberrypi.com/viewtopic.php?t=360902 Can you try configuring each stream with freeform_advanced_mpv_options: "--vo-gpu" or a combination of the options in that thread? Although it does say it is using the gpu already.

[gabiX87]

I used the Raspberry Pi Imager v1.8.5 then put the SD card into the rPI5 and booted it up. Had to setup name,username,passwd once I got into the desktop , opened up terminal installed SSH. Then I continued with the rpisurv installation from my desktopPC (putty). The rpisurv installer asked me which desktop env to be primary If i remember correctly lightdm vs (..pfff). After the install edited the monitor1.yml and that was it.

To restart after changes in the .yml file .... sudo service lightdm start | stop | status

[SvenVD]

I used the Raspberry Pi Imager v1.8.5 then put the SD card into the PI and booted it up. Had to setup name,username,passwd once I got into the desktop , opened up terminal installed SSH. Then I continued with the rpisurv installation from my desktopPC (putty). The rpisurv installer asked me which desktop env to be primary If i remember correctly lightdm vs (..pfff). After the install edited the monitor1.yml and that was it.

To restart after changes in the .yml file .... sudo service lightdm start | stop | status

Great, I did not expect that part to go so smooth on the pi👍 . Now some solution or explanation for the streams hanging and we can add rpi5 to the verified hardware list. Could you try with lower resolution streams, and maybe start with one stream to see how far it can go?

[gabiX87]

freeform_advanced_mpv_options: "--vo-gpu"

NOTE: RaspberryPi 5 - 2GB

It starts like this...

Ends like this ..

When the streams start , the CPU utilization is very low , like 3-10% but after a minute it start goes up to 90-100% and the streams freeze. It seems like the HW can keep up but something hangs it after a while ....

[gabiX87]

Great, I did not expect that part to go so smooth on the pi👍 . Now some solution or explanation for the streams hanging and we can add rpi5 to the verified hardware list. Could you try with lower resolution streams, and maybe start with one stream to see how far it can go?

SOLO 1080p h264 stream , freezes after a while too....

SOLO 1024x576 h264 stream ....lower resolution seems to be holding up

[gabiX87]

instead of vo=gpu I tried vo=gpu-next

and there seem to be progress ... the CPU utiliziation is way higher but the streams are holding up ...

as per AI

When comparing `vo=gpu` and `vo=gpu-next` in the **mpv** media player, there are several important differences to consider regarding performance, features, and compatibility. Here’s a summary based on the search results:

### Overview of `vo=gpu` vs `vo=gpu-next`

1. **Performance**:
   - **`vo=gpu`**: This is the traditional GPU video output driver. It has been well-optimized over time and generally provides stable performance across various hardware configurations.
   - **`vo=gpu-next`**: This is a newer implementation that aims to improve performance and efficiency. However, it may still perform worse than `vo=gpu` in certain scenarios. For example, benchmarks have shown that `vo=gpu-next` can be slightly slower than `vo=gpu`, especially when using specific settings or when hardware acceleration is not fully utilized [1][3].

2. **Hardware Acceleration**:
   - **`vo=gpu`**: Supports various hardware acceleration methods effectively, allowing users to leverage GPU capabilities for better playback performance.
   - **`vo=gpu-next`**: While it aims to support modern hardware features, some users have reported higher CPU usage when using `gpu-next`, indicating that it may rely more on software decoding in certain situations [2][3]. 

3. **Feature Set**:
   - **`vo=gpu-next`** introduces new features such as better dynamic tone mapping, improved color management, and support for advanced shaders. It also supports Dolby Vision content reshaping and GPU film grain application [3].
   - **Differences in Options**: Some options behave differently between the two outputs. For example, the scaling algorithms and tone mapping settings may yield different results depending on whether you're using `gpu` or `gpu-next`. The newer implementation may also deprecate certain options that are available in the older version [2][3].

4. **Compatibility and Stability**:
   - Users have reported occasional issues with `vo=gpu-next`, such as errors when initializing GPU contexts or problems with specific video files [4]. This suggests that while it offers advanced features, it may not be as stable across all setups compared to the more established `vo=gpu`.

5. **Development Status**:
   - The transition from `vo=gpu` to `vo=gpu-next` is part of ongoing development efforts to modernize mpv's video output capabilities. As such, users might find that `gpu-next` is still evolving and may receive updates that improve its performance and stability over time [3][5].

### Conclusion

In summary, while both `vo=gpu` and `vo=gpu-next` serve the purpose of rendering video output in mpv, they cater to different needs:

- Use **`vo=gpu`** for reliable performance and compatibility with a wide range of hardware.
- Use **`vo=gpu-next`** if you want to experiment with newer features and improvements but be prepared for potential stability issues and higher CPU usage in some cases.

As always, testing both options with your specific setup is recommended to determine which one provides the best experience for your use case.

Citations:
[1] https://github.com/mpv-player/mpv/issues/9479
[2] https://forum.artixlinux.org/index.php/topic,5763.0.html
[3] https://github-wiki-see.page/m/mpv-player/mpv/wiki/GPU-Next-vs-GPU
[4] https://forum.manjaro.org/t/mpv-0-36-how-to-setup/144958
[5] https://wiki.archlinux.org/title/Mpv
[6] https://kokomins.wordpress.com/2019/10/14/mpv-config-guide/
[7] https://discourse.osmc.tv/t/gpu-memory-allocation-for-steam-link-usage/97227
[8] https://raw.githubusercontent.com/classicjazz/mpv-config/master/mpv.conf

[gabiX87]

I have FLIRC aluminium ,passively cooled, rpi5 case and it's hot (sitting on the floor , ambient temp 23C). The CPU at them moment runs at 77,6C with 3 above mentioned stream resolutions. With such utilization consider actively cooled solution.

[SvenVD]

Nice work @gabiX87 !

[gabiX87]

Nice work @gabiX87 !

Well , thanks :)

note: camera used Unifi Video Camera G4 Instant (same resolution as the G5 Turret) SOLO 2866x1512 @ 30fps h265 (HEVC) VBR is holding up ....will let it run for +-24h

[gabiX87]

After about 16hours the solo 2866x1512 HEVC stream is frozen. I see that the process was "restarted" 1h 25min ago exactly when the stream freezed , that is the last image on the monitor, but it couldn't recover.

[linek1980]

gabiX87
for my system necessary parameter is gpu-dumb-mode=yes in /etc/mpv/mpv.conf *

Unfortunately, at the moment does not work monitored by watchdog process. When it is interrupted, it freezes

[gabiX87]

Thanks for input ... just for clarification for ourselves.

**Answer**
Setting gpu-dumb-mode=yes in your mpv.conf file can be beneficial for users with low-end GPUs or those looking to optimize performance. Here’s a detailed overview of what this setting does and how it interacts with other configurations:

**What is gpu-dumb-mode?**
gpu-dumb-mode=yes disables all built-in shaders in MPV and sets the image scaler to a simpler algorithm (bicubic). This can significantly reduce the computational load on both the CPU and GPU, making it suitable for systems with limited resources. It allows MPV to utilize basic GPU rendering without the overhead of more complex graphical processing tasks[2](https://forum.palemoon.org/viewtopic.php?t=29572)[3](https://github.com/mpv-player/mpv/issues/11000).

**Benefits of Using gpu-dumb-mode**
Reduced Resource Usage: By disabling shaders, the player consumes less power and operates more efficiently, which is particularly useful for older hardware or when running on battery power[2](https://forum.palemoon.org/viewtopic.php?t=29572)[4](https://forums.raspberrypi.com/viewtopic.php?t=360902).
Smoother Playback: Users have reported smoother playback of videos, especially at lower resolutions (e.g., 720p), as the player can handle video rendering more effectively without the additional processing required for advanced effects[3](https://github.com/mpv-player/mpv/issues/11000)[5](https://forum.porteus.org/viewtopic.php?t=10852).
Compatibility: This mode can help in scenarios where other settings might lead to performance issues or dropped frames, making it a good fallback option for less capable systems[1](https://www.reddit.com/r/mpv/comments/107m9q8/advice_for_an_mpv_noob_on_mpv_conf_for_midend_cpu/)[4](https://forums.raspberrypi.com/viewtopic.php?t=360902).

**Considerations When Using gpu-dumb-mode**
Quality Trade-offs: While this setting improves performance, it may also lead to a decrease in video quality due to the simplified scaling and lack of advanced visual effects. Users seeking high-quality playback may need to balance these settings based on their hardware capabilities[1](https://www.reddit.com/r/mpv/comments/107m9q8/advice_for_an_mpv_noob_on_mpv_conf_for_midend_cpu/)[2](https://forum.palemoon.org/viewtopic.php?t=29572).
Conflicting Settings: Some users have noted that using gpu-dumb-mode=yes may conflict with other high-performance settings like profile=gpu-hq, which aims to enhance video quality. It's advisable to adjust these settings according to your specific needs and system capabilities[1](https://www.reddit.com/r/mpv/comments/107m9q8/advice_for_an_mpv_noob_on_mpv_conf_for_midend_cpu/)[3](https://github.com/mpv-player/mpv/issues/11000).

**Example Configuration**
Here’s a sample configuration snippet for an mpv.conf file that includes gpu-dumb-mode along with other recommended settings for low-end systems:
text

# Basic mpv configuration for low-end systems
vo=gpu
gpu-dumb-mode=yes
hwdec=auto-safe
video-sync=display-resample
interpolation=yes
tscale=bicubic
tscale-radius=1.1

This configuration prioritizes performance while still allowing for decent video quality, making it ideal for users with limited hardware resources.
In summary, enabling gpu-dumb-mode=yes in your MPV configuration can lead to better performance on low-end systems by simplifying video processing tasks, although it may come at the cost of some visual fidelity.

[gabiX87]

gabiX87 for my system necessary parameter is gpu-dumb-mode=yes in /etc/mpv/mpv.conf *

Unfortunately, at the moment does not work monitored by watchdog process. When it is interrupted, it freezes

Are you using vo=gpu or gpu-next ? What resolution and codec are you streaming/replaying ?

[gabiX87]

Anyway as a temporary fix ( I would use it regardless ) I would use a crontab job to reboot the pi every 6 or 12hours or alternatively restart the lightdm process.

sudo crontab -e

0 */6 * * * sudo reboot - every 6hours (starting from midnight 00:00 , 06:00 , 12:00 , 18:00) 0 */12 * * * sudo reboot - every 12hours

[linek1980]

Are you using vo=gpu or gpu-next ? What resolution and codec are you streaming/replaying ?

I see the best results on vo=gpu but the key to proper work is gpu-dumb-mode=yes. Tests H.264 and H265 both give very good result and low CPU load. Devices are 4x cam unifi protect G4 and G5