VLC, Kodi 19.1, Firefox and generally on Vanilla Debian bullseye playing videos of all different types extremely slow and stuttering

[ThomasKorimort]

This issue of extremely slow playback of video appears again and again (and no, it is not due to compositor issues). I have set gpu_mem to 512 on my RPi 4 with Vanilla Debian Bullsyeye arm64, i set a big buffer for Kodi and i tried Deb-Multimedia replacements for the video codecs (completely destroying my system), so i ask myself whether it could be an issues with the current firmware?

[pelwell]

Why set gpu_mem to 512? This is unlikely to improve anything, particularly on a 64-bit OS - try without that setting.

[ThomasKorimort]

I tried with default setting too. On my last Raspbian resp. Raspberry Pi OS with Kodi 18.7 it was working flawlessly with all codecs and all resolutions. It is not a problem of Kodi alone. Generally, videos playing in browser, VLC, anywhere are slow and stutter till the point it is impossible to watch them.

In the past several things were suggested:

*) Compositor problem

*) Kodi cache (this is Kodi-specific)

*) Codec problem

As already explained before updating the Codecs via Deb-Multimedia repository broke my installation completely. So now i am helplessly switching between LibreElec for my videos and Vanilla Debian Bullseye arm64 via image-specs script from Debian. I guess it is a problem with the firmware, maybe hardware codec support or some problem with playback of videos beyond frame tearing.

[popcornmix]

Vanilla Debian Bullsyeye

You won't have any video acceleration. It will be software decode.
You'll need RPiOS repo for accelerated versions of Kodi/VLC/Chromium.
Or use LE.

[ThomasKorimort]

Is this valid for the 64 bit arm64 version too? When will Raspberry Pi OS be updated to arm64 and Bullseye?

[popcornmix]

Vanilla debian won't have hw decode on 32-bit or 64-bit.
RPiOS Bullseye is being worked on, but we don't have an exact date.

[ThomasKorimort]

OK. I guess 64 Bit does not pay off, if i cannot play videos nor use it as Debian system. I'll sort back to the recent RPi OS. Will there be a DRM library for the RPi OS for playback of DRM material on FireFox or Chromium? On my desktop with Debian Bullseye DRM via Widevine works fine.

[XECDesign]

Will there be a DRM library for the RPi OS for playback of DRM material on FireFox or Chromium?

There's no arm64 build of widevine and 64bit binaries cannot load 32bit shared objects. Unless somebody creates something like a shim library that uses interprocess communication to work around this, it's unlikely we'll see widevine support. At some point we may look into way to get armhf chromium installed on arm64 pios, but not soon.

[ThomasKorimort]

I am using Austrian Broadcast library (ORF TvThek: https://tvthek.orf.at) and the live streams of ORF 1 and ORF 2 are DRM encrypted somehow via the HTML5 player. This seems to be an issue beyond WideVine since i cannot watch the live streams of ORF1 or ORF 2 on armhf Raspberry Pi OS either. It works on desktop amd64 Bullseye flawlessly though. The archived shows i can watch without any problem. That is also a legal issue, since in Austria ORF is getting state funding via ORF fees, but recently there have been high court judgments that watching it via Internet does not allow for fees and charges being pressed. Thus ORF has a funding problem now and they do all kinds of encroaching things to get their money, including encryption of the live streams of the two main channels ORF 1 and ORF 2 contrary to their obligations towards legal public broadcast demands. That is how everything gets impure and polluted in our world. Still RPi OS armhf does not solve the problem for the live streams amd64/amd32 does though. Why?