@Darksky : Your version works very well, HW acceleration for both h264, h265 10 bits, no problem.
It’s even better than the RC1 version i get from archlinux alarm repo because there is no flickering when i zoom on h265 video.
But anyway, meanwhile, i have found that i could minimize the black borders within Kodi → Player → Minimize black borders(you have to set a percentage). That way, zooming works in either your version and the RC1 version i get.
Btw, is there any reason why we have to switch to tty instead of staying to a xorg session ?
In addition, i have tried the 18.9 version from Manjaro repo, and there, there is no HW acceleration at all, for h264 or h265.
I use the latest version of graysky from arch kodi-rpi-git 19.0rc1.57039.46685b10c7-2 and no pb with h264, h265 10 bits. (jellyfish-180-mbps-4k-uhd-hevc-10bit.mkv ok). And no need of xf86-video-fbturbo-git. i know that vblank_mode=0 glxgears is not a test but with xfce, latest kernel,mesa-git and picom-git i have 1315 fps, but with xf86-video-fbturbo-git it’s 344 FPS.
I am thinking the glxgears test might be skewed. Pi OS and arch-arm use fbturo. fbturbo has not been mentioned to be disabled when using arch-arm with the new kodi; only some changes in /boot/config.txt. Testing with glxgears in a DE environment with and with out fbturbo may not be indicative of what is really going on in a non desktop environment like this kodi version has to run in.
With out fbturbo in a DE environment the desktop apps uses mesa and the kernel’s KMS and that allows for V3D video acceleration for the pi. With fbturbo in a DE environment you will not get V3D video acceleration for the pi. If you try to run this version of kodi it senses that it is in a graphical environment and will fail trying to load up as it is geared to run in a non graphical environment.
Having said all of that arch-arm recommends dtoverlay=vc4-kms-v3d,cma-384 but due to my tv monitor I can not test that because mesa will not detect the tv’s edid info to load up. I have to use dtoverlay=vc4-fkms-v3d,cma-384. They said that dtoverlay=vc4-fkms-v3d,cma-384 willl work but dtoverlay=vc4-kms-v3d,cma-384 would be better.
If i would use kodi in a non DE, sorry but I’ll use a libreelec version first. But for a 100% desktop user with RPi4, It’s more easy to do ctrl alt F2 than having to power off, switch sdcard, reboot, re-power off re-switch on the SSD… thus a version ok kodi with no need of xf86-video would be preferable. No side effect for users with or without a DE.
Today I started fresh (mainly to get it updated with the latest libs) and cloned popcornmix’s repo which arch-arm uses and also cloned the latest kodi git and merged the 2 with “git merge”. There seemed to be a lot of new commits since popcornmix’s last merge. I did not look what all was new but guessing a combination of cosmetic, bug fixes and maybe some new things:
Here is a link for download. Inside the folder when you unpack the tarball there are the 4 kodi install packages and there is a sub folder called addons that has some common addons packages that I compiled for kodi 19. Some addons are for required to play video-addons and I have a couple of screensavers.
linux-rpi4-mainline kernel needs to be installed and due to the nature of libs getting upgraded often I highly recommend to be on the stable branch and do a sudo pacman -Syu to have everything current.
I know of nothing at this time with a 64 bit os. Thanks to popcornmix with the the Pi Foundation’s kernel git we are able to have what we have now. He also contributes to kodi so just maybe some time in the future it might happen.
Don’t you have problem of flickering when you zoom in while playing a video ?
I mean, play a video (h264 or h265), then go to video settings and zoom in, say, 1.01 or 1.02.
What will happen?
Indeed, i like to reduce black borders in movies.
When i use the “Minimise black borders” in Kodi → Player…it only stretches the video vertically, which is bad.
So, the only solution i have is zooming in while playing.
Now, any video does flicker in the version @Darksky uploaded yesterday as the one in Arch ARM repo.
I do not now if it happens to me only or to anybody.
I tried with or without fbturbo, or by changing few parameter within config.txt, without success.
I do not have any black borders; guessing your monitor dimensions are not listed in kodi’s setup. In the past I have seen flickering when my tv’s refresh rate was inot detected. Have you messed with the Refresh setting under Player. It is off on mine by default. It has minimal choices and have no clue really what it does.
In the past I have achieved in my monitor’s settings it’s self what could not be done otherwise adjusting the screen.
Yes, i will play with that. But i think everybody has black borders, i am talking about black borders related to 2.35:1 movie format. Thus, you should see top or bottom black borders on a 1080p monitor or 16:9 TV
I haven’t tried playing anything in kodi yet because I noticed performance is incredibly sluggish. Is this normal behavior? Additionally, i’m in a sway environment without any xf86-video-fb* drivers.
edit:
as mentioned in the op, running kodi in a separate tty works perfectly. If launching from the DE is some limitation then I am perfectly fine with launching from a separate tty.
edit2:
noticing this output when I run kodi: libva error: /usr/lib/dri/v4l2_request_drv_video.so init failed
but everything, including that jellyfish-110-mbps-hd-hevc test video seems to be running fine… is this something that should be addressed though?
here’s output from file for what it’s worth:
> file /usr/lib/dri/v4l2_request_drv_video.so
/usr/lib/dri/v4l2_request_drv_video.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b45121f0716f96babf6534cb4dc3d0fa4d6207a8, stripped
edit3:
is playback of the jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv or any 4k content possible through kodi on the pi4(00) or no?
I have never installed those files from the arch repo. I have always used the ones I compiled. If it runs fine when exiting the DE (CTRL-ALT F2) then it sounds like it is the same. That is what it is supposed to do. It is not made to run under a DE.
I do see Something in config.txt that seems to be missing though.
I have fbturbo installed and use dtoverlay=vc4-fkms-v3d,cma-384 due to my monitor not sending correct edid info.
This willl be normal. Kodi is checking for available drivers on startup to use. The pi does not support libva.
No it is not.
This is horrible. You should re-consider using this.
I use:
over_voltage=5
arm_freq=2000
These are PrintScreen screenshots taken in kodi. Keep in mind the actual video will not show up as they are playing in a terminal. I mostly want you to se the specs and cpu usage.
I have done another 3 way git merge with popcorn → upstream → my tree to bring kodi to to version 19.0.0 and to have everything up to date as of yesterday.
The pi3b and pi3b+ is now also supported using h264 and h265 HW decoding. In my tests using the pi3b it worked on the lower end streams which will probably be normal daily use but the really intense streams it had issues but I really expected that.
As previously kodi still has to be run outside of a DE enviourment (CTRL-SHFT-F2)
So, in short, there is no HW accel in a x11 session (whatever DE) in Kodi 19, it was the same in Kodi 18. Indeed, in Raspberry OS, there is a wrapper that run Kodi in a VT at start and return to the DE on exit → Kodi 18.x does not run inside the DE in reality, but in a VT.
This wrapper does not exist yet for Kodi 19 apparently. In this Kodi’s forum post, the man who effectively did this wrapper for Kodi 18 in Rasp OS explains it.
@mergerprodukt , it’s perfectly normal for Kodi 19 provided from Arch ARM repo to be sluggish if you run it inside a DE because there is support for it → that’s why you can run it inside any DE without a wrapper, as you can see in this commit. The drawback is that you do not have any HW accel.
@Darksky.
Your last Kodi 19 package is fine for me, no problem.
Nevertheless, as i already mentioned it earlier in this thread, there are flickering issues when zooming video, whatever content type is. Those issues are not related to your package nor to Manjaro ARM, but on Kodi 19, on raspberry pi 4 at least.
There is an ongoing post on that on Kodi’s forum, but no solution yet.
Although the title says it’s related to rpi2/rpi3, the messages of this thread are related to rpi4 too.
To be honest with you, i do not understand everything, they talk about kernel patches that i do not know anything of. I do not have sufficient knowledges.
Maybe there is a clue in there regarding flickering issues.
After reading the thread it kinda seems like I may have to revert one patch in kodi and patch the kernel with another patch. Kodi will take a couple of hours to compile as as a patched ffmpeg and other programs get compiled and the kernel @40 min.
Since I do not zoom anything what is the zoom sequence to zoom in and out so I can test.
You can try with “Z” key, it’s the default key to zoom, when you are watching a video.
In addition, when playing back a video, i usually adjust the “Zoom amount” in the video settings of the video (not the video settings of Kodi). I have flickering issue when i adjust it above 1.00
I could make some test too if you want
