Install on Raspbian

[kevin201]

This is fantastic! I've installed on my NB on ubuntu Focal and it works a treat.

I'd really love to be able to install on my RPi, running raspbian, but there are dependencies missing from the repository. :disappointed: (qtwebengine5-dev etc.)

I've installed Kodi with the Jellyfin addon, which is good, but the Jellyfin UI is preferable IMHO.

[iwalton3]

The bigger problem is no one has been able to get MPV working in any reasonable capacity recently on the RPI. And even if it does work, the codec support will be significantly worse than a regular PC. See: https://github.com/jellyfin/jellyfin-mpv-shim/issues/57

Also related: https://github.com/jellyfin/jellyfin-media-player/issues/57

[kevin201]

Thank you for the info.

[shyzus]

Hello, I have recently began to use my Pi 4 B as my desktop and was disappointed to find there are no aarch64/arm64 builds available for this project. After reading trough this issue and the related issues at the jellyfin-mpv-shim project. I ended up following the build instructions and hope for the best.

With positive results, I have managed to get this to work with only minor alterations on my Pi 4 B.

Alterations:

• Did not execute: echo -Dpipewire=disabled >> mpv_options # hopefully temporary
• Installed meson as this was required but not included in the dependencies listed

Additional info: Kernel: 6.1.0-rpi7-rpi-v8 mpv:

mpv v0.37.0-217-g68f1057d2e Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
 built on Jan 25 2024 16:09:19
libplacebo version: v6.338.0-64-g34e019bf
FFmpeg version: N-113423-g00b288da73
FFmpeg library versions:
   libavutil       58.36.101
   libavcodec      60.38.100
   libavformat     60.20.100
   libswscale      7.6.100
   libavfilter     9.17.100
   libswresample   4.13.100

jellyfinmediaplayer: version 1.9.1 commit 411032f4a7e80cc37ea97213fd051bcb38b4041b Jellyfin Media Player Log: jellyfinmediaplayer.log

Program output:

[REDACTED]@pi-server:~/jmp/jellyfin-media-player/build $ jellyfinmediaplayer 
libpng warning: iCCP: known incorrect sRGB profile
Listening to socket: "/tmp/jmp_pmpUniqueApplication_[REDACTED].sock"
Signal handlers installed successfully.
Logging to  /home/[REDACTED]/.local/share/jellyfinmediaplayer/logs/jellyfinmediaplayer.log

(jellyfinmediaplayer:48113): GLib-GObject-CRITICAL **: 16:37:49.199: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory

As to why it seems to work just fine when building it without making any code changes. I believe that on the pi 3 and earlier. The default behaviour is to use MMAL for stuff like video decode. Where if I recall correctly, the pi 4 and after should be using the more common V4L2 for stuff like video decode. This change may be the cause.

Attached are two images showing direct playback without the use of transcoding for both H264 and H265 codecs. Note the GPU is being fully utilised in both images.

P.S: I forgot to mention this when I wrote this comment first. The quality of the video playback is considerably worse but still playable when comparing to the pi 4 b playing the same media back but using OSMC/LibreELEC/Kodi. I attribute this difference to be the whole wayfire desktop environment that is introducing some additional load. Video playback becomes quite good when using full screen and not moving the cursor at all. doing anything like moving the cursor or doing anything on the desktop while playing back video will heavily introduce laggy playback and choppyness.

[shyzus]

I have been using JMP for a few days now and noticed some issues mainly that some videos would refuse to play and hang the application. I ended up reading trough the logs to notice that all this time. It was always software decoding.

This explains the performance difference observed before. The reason for some videos working fine and not was simple. By default the application will try hardware decode but if there isn't a way to do it, it will default to software decode. Sometimes this process does not work correctly and ends up hanging the application.

I ended up getting a version with H264 hwdecode JMP + mpv by reading trough the steps described in this issue: https://github.com/mpv-player/mpv/issues/10956 .

The key step being a different distribution with a few patches specifically made for the raspberry pi. While this is good news it is also bad news. It means that the primary issue as to why MPV and by proxy JMP can't do hwdecode on the pi is due to certain patches not being merged upstream to mainline FFmpeg.

That lead to me to consider a different media player that actually came pre-installed on raspbian/raspberry pi OS. Which is VLC.

VLC performed incredibly well and actually was using hw accelerated decode for both h264 and h265 content.

Now I read trough some other issues that this client simply is not compatibly with any other player than MPV without doing some major overhauls.

Which is why I suggest making only one change to have at least a working JMP: For all builds intended to be used on a RPI. Set the default hardware decode behaviour to disabled. Using only software decode unless the user changes that setting.

This at the very least will make playback possible/reliable, but not exactly performant until hwdecode for the RPI is improved via FFmpeg and/or mpv in the future.

P.S: Currently I use JMP as a jellyfin "browser" rather than a player as well. I select the media I wish to watch and then select the option to "Copy Stream URL" which I then paste as a network stream into VLC. Which works surprisingly well. Hope this helps someone