• 1
  • 4
  • 5
  • 6
  • 7
  • 8(current)
Solved RPi3 and RPi4 hardware decoding expectations for version 19
@graysky with kms enabled this would be OK (I also use that as a current workaround). But in general it's better to leave that out - if kms isn't enabled then the simple fb will only run at HD resolution (and upscale to HD).

I tested with a dev firmware (and kernel change) from popcornmix two days ago and that worked quite well (both clock boost and initial FB were removed), but popcornmix then noticed it broke CEC (hadn't tested that myself). I guess it shouldn't take long until that is ironed out, too, and the fixes appear in official RPi FW and kernel.

so long,

Hias
Reply
Hey there, I've read every post in this thread, but I'm still confused about a couple of things. I'm hoping someone knowledgeable can clarify.

I've got a Pi 4. Using instructions on this forum, I successfully built both the ordinary Kodi 19.1 and the popcornmix fork, but I'm not getting hardware decoding with either. (At least, I assume I'm not. CPU use is very high with h264 and h265 videos are unplayably slow.) Changing the dtoverlay settings around doesn't seem to make a difference. I've checked that I'm not seeing permission issues with the graphics acceleration devices in /dev.

Questions:

1. Is hardware video decoding supposed to work, out of the box, with ordinary Kodi built with the GBM target? Or is a fork still required?

2. What exactly are the changes in the popcornmix / graysky2 forks? (I have tried to crawl through the changelogs, but they're extremely uninformative about what the overall purpose of the fork is, and the README is unmodified so there's no explanation.) Should I prefer one fork over the other?

3. If the changes in these forks are necessary to get hardware decoding on the Pi, why haven't they been upstreamed?

4. I thought the point of switching to GBM was that stuff like hardware decoding was just going to work, easily and out of the box, in the future. Is that not the case? Why does the Pi seemingly still require a bunch of hacks?

5. Does anyone have HDR working with Kodi on a generic Linux distribution for the Pi 4? I'd like to have it working, but I'm not interested in using a special purpose distro with a bunch of hacks slapped together that can't be upstreamed or generalized.

6. Are there any settings in Kodi that need to be changed to get things working correctly on the Pi 4? I saw upthread someone mentioned enabling PRIME but I don't think that should be necessary(?).

Thank you all for your time and expertise. I think clarification of these issues would be useful to many people, as it's currently quite hard for newbies like me to figure out exactly what the status of Pi 4 support is.
Reply
@athone when asking for help it is necessary to provide a Debug Log .
It will provide the info that you failed to provide, eg What's your OS? What's your kernel version ? What's your firmware version?
All these questions are relevant for hw decoding on the pi.
And the info in the Debug Log might allow someone to see why it's not working for you.
 
(2021-07-08, 16:48)athone Wrote: I thought the point of switching to GBM was that stuff like hardware decoding was just going to work, easily and out of the box, in the future.

The point of GBM is to avoid running additional stuff like Xorg + windows manager or wayland compositor which consume resources.
Reply
(2021-07-08, 17:59)asavah Wrote: @athone when asking for help it is necessary to provide a Debug Log .
It will provide the info that you failed to provide, eg What's your OS? What's your kernel version ? What's your firmware version?
All these questions are relevant for hw decoding on the pi.
And the info in the Debug Log might allow someone to see why it's not working for you.
 
(2021-07-08, 16:48)athone Wrote: I thought the point of switching to GBM was that stuff like hardware decoding was just going to work, easily and out of the box, in the future.

The point of GBM is to avoid running additional stuff like Xorg + windows manager or wayland compositor which consume resources.

Thanks for the reply. To clarify, I'm not asking for help - I can use software decoding for the time being. I was just providing context for my questions. I think the questions are the interesting thing here, because as things stand (as I said before) it's almost impossible for anyone not heavily embedded in Kodi development to figure out what the status is on the Pi 4. My questions are aimed at figuring that out. (For what it's worth, I decided to test things on the latest Raspbian, fully up to date, because it's easy to find build instructions on the forum here. But I'm open to trying Arch Linux Arm or something else.)

I don't understand what you mean about GBM. Before the GBM build was standard, I ran MMAL based Kodi on the Pi without Xorg or a compositor, as far as I'm aware. I didn't encounter any problems in doing so.
Reply
(2021-07-09, 02:06)athone Wrote: Thanks for the reply. To clarify, I'm not asking for help

To clarify - if you want to know what's wrong with your build/setup/os/whatever you will need to provide a Debug Log . Period.
Our last crystal ball broke ages ago and I guess that no one will spend their time guessing.
If Kodi was built properly and with a proper config.txt hw decoding should work. <- Edit: I'm not so sure about that.

Edit: I forgot that you do need ffmpeg patch from popcornmix's repo to enable some pi specific stuff, for pi I've been using popcornmix fork.
So I'm not totally sure what is the state of hw decoding is if Kodi was built from official repo, sorry.
 
(2021-07-09, 02:06)athone Wrote: Before the GBM build was standard, I ran MMAL based Kodi on the Pi without Xorg or a compositor, as far as I'm aware. I didn't encounter any problems in doing so.

Kodi 18 ran over dispmanx + firmware (closed source blobs) GLES/EGL on the pi.
AFAIK there are no firmware GL* drivers for pi4 at all.
Support for vendor specific hw decoding apis like mmal/amcodec was completely dropped in Kodi 19.
Reply
@athone Kodi works with hardware acceleration without source changes on a Pi.
Unfortunately ffmpeg does require patches.
Its upstream support for stateful (e.g. h264) v4l2 is very basic. Its upstream support for stateless (e.g. hevc) is non existent.

The usual method of compiling kodi uses an internal ffmpeg build. The significant change in my gbm branch to kodi is to the ffmpeg patch.
You can in theory build kodi with external ffmpeg libs (which debian do), although kodi devs tend to not support that (as exactly what is in ffmpeg is far less clear).
In that configuration kodi will run untouched, but ffmpeg will need a forked build.

Quote:I thought the point of switching to GBM was that stuff like hardware decoding was just going to work, easily and out of the box, in the future
I think your comment "in the future" is key. One day it will, once ffmpeg contains enough v4l2 support. But that is not today.
Reply
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8(current)

Logout Mark Read Team Forum Stats Members Help
RPi3 and RPi4 hardware decoding expectations for version 190