afaerber has quit [Remote host closed the connection]
jstein has quit [Quit: quit]
suprothunderbolt has quit [Ping timeout: 256 seconds]
matthias_bgg has quit [Ping timeout: 240 seconds]
florian_kc has joined #linux-sunxi
sbbg has joined #linux-sunxi
<sbbg>
Hi, everyone. I have serious frustration about hardware decoding on PineH64. I install forked version of FFMPEG, Kodi, Linux kernel 5.5.6 from LibreELEC build system into Gentoo. But I still cannot enjoy hardware decoding.
<sbbg>
jernej told me I have to install patched kernel from LibreELEC last time. But somehow it still does not work. May I ask you how to diagnose problem of hardware decoding for Kodi?
<sbbg>
In order to install the patched version of Kernel, I have to use the OLD DTB/DTS from armbian to boot properly. Does that affect hardware decoding?
<gnarface>
hey sbbg i think the answer is yes, severely, but i'm not sure. i think you might have better luck asking this question in the pine64 irc network though
<sbbg>
gee... really? I will go there and try my luck then. I forgot where I meet jernej last time.
<gnarface>
there might be a better way to boot it now than what you're using
<gnarface>
i'm pretty sure there is actually
<gnarface>
but i'm not sure what you're doing
<sbbg>
I want to make Armbian working with Gentoo Root file system and hardware decoding capable Kodi.
<gnarface>
working for kernel 4.x and 5.x but only with the new firmware
<gnarface>
the mainline one
<gnarface>
(and extra patches that aren't mainlined yet i think)
<sbbg>
ok, I forgot about the firmware actually. I copy only kernel and modules into my gentoo/armbian hybrid.
<gnarface>
there might be some images on their site
<sbbg>
Let me calm down and do this again.
<gnarface>
but what you'll probably want to do if you're able, is to build u-boot and the kernel yourself
<gnarface>
patches for u-boot i think *have* been mainlined now? not quite 100% on any of this but yea
<sbbg>
I did fit the patched LibreELEC kernel 5.5.6 into Armbian build system and compile it with its toolkit. It cannot boot properly unless I replace the DTS/DTB with old version.(from original Armbian kernel 5.4)
<gnarface>
so you'll probably be able to build u-boot without patches but you probably still need patches for the kernel
<sbbg>
okay, let me calm down a bit and try this over.
<sbbg>
gnarface, does dtb/dts coupled with firmware? I'm not really familiar with ARM development before.
<gnarface>
well, i'm misusing the term firmware
<gnarface>
it is read off your disk by the kernel to figure out your hardware
<gnarface>
yes it is paired with u-boot which kinda also acts in place of firmware but is also read off the disk
<sbbg>
So does the 'firmware' you mentioned is in form of files?
<gnarface>
yes, but they don't go on the filesystem
<gnarface>
they go in the empty space before it on the disk
<sbbg>
Typically,if I can build the Armbian image with the LibreELEC kernel. The output image should include them, right?
<KotCzarny>
uboot is best thought as bios+grub
<sbbg>
ok, so it's including a boot loader and... initalization of something, right?
ldevulder_ is now known as ldevulder
<KotCzarny>
yup
<KotCzarny>
that's why uboot has to be compiled for specific board
<KotCzarny>
because it includes configuration and initialization
<sbbg>
So that make me feel even more bewildered, I did build the image successfully for PineH64 with Armbian's toolchain including the LE kernel. But its output image still cannot boot here, unless I replace the dtb/dts with the old one(from Armbian 5.4 kernel)
<gnarface>
it's possible when you said *old* one i mistakenly interpreted that as being a much older one
<KotCzarny>
there are 3 things
<KotCzarny>
uboot, kernel and system
<sbbg>
the *old* dts/dtb I mentioned is from original Armbian image build for PineH64.
<KotCzarny>
dtb is loaded by kernel
<KotCzarny>
one kernel can use different dtbs for multiple boards without need of recompilation
<KotCzarny>
and dtbs are often universal between kernel versions
AneoX has joined #linux-sunxi
<KotCzarny>
there are some changes, but often they work ok
<sbbg>
That sounds great, but does any changes in dtb/dts affect HW decoding?
<KotCzarny>
depends on driver i guess
<gnarface>
it could in theory, since it's partially a list of what to power up, i think...
<KotCzarny>
as it's still in development, so it might require new options
<KotCzarny>
that weren't present before
<sbbg>
ok. I will try to compare the versions from Armbian and from LibreELEC
<sbbg>
BTW, does anyone have any idea about how to diagnose HW decoding problem in Kodi? I cannot find any in the logs.
<KotCzarny>
start with ffmpeg
<sbbg>
ok, I will try to keep that in mind.
<KotCzarny>
once it plays from cmdline, you can test kodi
<sbbg>
So I give parameter to force using HW decoder to test in FFMPEG first. Is that what you meant?
<gnarface>
hmm, does ffmpeg need a patch too?
<KotCzarny>
probably
<sbbg>
I did install the forked version from LibreELEC
lkcl has joined #linux-sunxi
<sbbg>
I mean compiled and installed the patched FFMPEG from LibreELEC's build system. The configure parameter also follow the log from LibreELEC, I think it should be fine for FFMPEG.
<KotCzarny>
just try using ffmpeg to play some file
<KotCzarny>
from command line
<sbbg>
even I don't have a proper display? May I direct the frame to something like /dev/null ?
<KotCzarny>
probably
<sbbg>
ok, thank you. That's a lot to try.
<gnarface>
i think it has benchmarking modes...
<gnarface>
check the man page maybe
<gnarface>
but couldn't you also just run it over ssh?
<gnarface>
like with X11 forwarding?
matthias_bgg has joined #linux-sunxi
tdebrouw has quit [Quit: Leaving.]
<sbbg>
I will see what I can do about that. Thank you for suggestion.
<KotCzarny>
it can probably also save to file
<KotCzarny>
for example as a bunch of jpegs
<sbbg>
Yeah, it certainly should, I tried that before.