New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFE] Improve Odroid XU4 #6250
Comments
@heitbaum @chewitt |
@MastaG Neither of us write driver code so detailed fixing of MFC problems isn't likely to happen, but if there are patches that resolve or improve things (that apply-to and work on modern kernels) we can pick them. If you can point me to source patches in a repo that would be helpful. I've looked at @AreaScout GH repos but armbian/linux/xbmc ones do not show any updated branches for several years and I don't have time to read hundreds of disorganised posts on the HK forums. |
Have you guys missed this ? https://forum.odroid.com/viewtopic.php?p=350810#p350810 MFC patches, AND he has KODI running with Panfrost on XU4, patches to get the driver working are also within this post: I will build a new NAS Image with KODI passed on that patch set + KODI will be installable from the HK minimal Ubuntu XU4 images, but it will take a week or two, still have two bugs to fix for KODI on ODROID-M1 edit: Well he is NOT running it on XU4 but on SBC with same GPU, but it is already tested on XU4 and Panfrost works, also MFC but it was not 5.10 but 5.18 RG, |
Hi AreaScout! |
I'll spin an LE image based on 5.19-rc3 over the weekend and see what works. |
@AreaScout @MastaG https://chewitt.libreelec.tv/testing/LibreELEC-Exynos.arm-10.85.0-odroid-xu4.img.gz <= no hardware decoding and prob. some more things to port over, but I am looking at the Kodi home screen via panfrost :) |
@chewitt That's so cool, didn't believe anymore in seeing Panfrost on XU4 and then bam, out of nowhere it was there :) |
I've updated the image I posted with "the usual patches" for kernel/kodi that have been doing the rounds for a while though those should be re-evaluated as some of them probably aren't needed. I also figured out kernel defconfig changes needed to include the s5p-* drivers; there's been a large rearrangement of drivers/media in Linux 5.19.y so those were missing a few CONFIG dependencies. The image is usable with software decoding and some 1080p test files. IIRC hardware decoding will need a rework of @mihailescu2m ffmpeg hack or the adaptation of https://patchwork.kernel.org/project/linux-samsung-soc/cover/20190301122055.7135-1-a.hajda@samsung.com/ ..which is technically better, although with the age of these boards now the ffmpeg hack probably has a greater chance of finding a willing volunteer to work on it. NB: If anyone wants to look at ffmpeg, we should use the same V4L2 codebase that LE is currently using for Amlogic/RPi as this is theoretically the codebase that will eventually be upstreamed (by RPi Foundation devs) to ffmpeg. |
@chewitt didn't had time yet :( I still don't believe in drmPRIME on XU4, I saw it not working correctly with GSCALER inside FFmpeg but I love to get corrected here, this are the patches we used to run KODI on XU4 |
What @chewitt said is correct, I did get drmprime working as good as it was working on other boards back then. |
Hi memeka :) It's good to see you ! Well as far as I remember only 1080p files did work, no scaling to other resolutions or what so ever, only color conversation and the movie playback was flickering, I still have a video lying around showing it, if you did had that working then I don't get it why we didn't know about it Regards, |
Here's a Kodi debug log (with ffmpeg debug) http://ix.io/412S - hardware decoding currently fails for me using the same ffmpeg sources LE uses with RPi/Amlogic. The RPi developer who's been working on their v4l2_m2m vdec commented: "Coded data goes in but the expected initial 'resolution changed' event never comes out of the decoder. Also, the decoder doesn't seem to support DECODER_START/STOP which is not technically fatal but doesn't inspire confidence" .. I need to experiment with another patch @MastaG pointed me to, but I think v4l2_m2m evolved a little and some rework is needed. |
@chewitt keep in mind that my image still uses FFmpeg 4.3. So there's a chance that more recent versions broke the v4l2-m2m decoder when using with s5p-mfc. |
I've done some experimenting over the last few days. I'm working from an LE develpment branch which is currently using Kodi 20a1, ffmpeg 4.4, and Linux 5.19-rc4. Changes are here: https://github.com/chewitt/LibreELEC.tv/commits/samsung Kernel: https://github.com/chewitt/linux/commits/samsung-5.19.y Using the same ffmpeg 4.4 with changes for improved v4l2_m2m on Amlogic/RPi, I have no decode and playback doesn't start (see comments from the RPi ffmpeg developer above). Using default ffmpeg 4.4 I can see hardware decode start, but it's using s5p-mjpeg not s5p-mfc so the frame-rate is horrific, see http://ix.io/41bC. I'm wondering if this is because s5p-mjpeg advertises YUV support? so is a better match for output? - RPi dev commented "it certainly is using mjpeg but that might be subtitles or something over the main video? I don't think the old unpatched v4l2m2m code is as chatty as mine when working so its hard to tell. I'd certainly believe that your decoder is happier if it has size setup before startup which is what the older decoder did." The upstream kernel does not have a stable UAPI for stateful (v4l2_m2m) decode yet but there was some effort towards establishing conformance tests about 18-months ago, and the Amlogic/RPi drivers (and the ffmpeg we use) are aligned to those changes. I strongly suspect the upstream ffmpeg and s5p-mfc driver are still in a state that pre-dates those tests being available, so the driver needs some work. If that's done, it should play nicely with the Amlogic/RPi ffmpeg sources (which will go upstream at some point soon) and should reduce the need for Kodi hacks (zero would be the goal). The challenge is always finding people with the talent and motivation to do low-level work on the drivers, because it's a rather niche skillset. |
I don't know the Amlogic/RPi changes, but I remember that Lukas had all that v4l2_m2m drmPrime in work, it is hosted here https://github.com/lrusak/FFmpeg/tree/v4l2-drmprime-v5 If that changeset is applied https://patchwork.kernel.org/project/linux-samsung-soc/cover/20190301122055.7135-1-a.hajda@samsung.com/ I would have test it with the one from Lukas RG, |
closing now that #6827 has been commited |
See commentary in these PRs
The text was updated successfully, but these errors were encountered: