offbeat this patch http://ix.io/3QwZ should improve VP9 decoding speed and hopefully lower issues with Cedrus based decoding. It turns out that Android box is running VP9 core on much higher frequency and Cedrus on slightly lower. While at least in Cedrus case it doesn't seem much, it can be just enough to avoid issues. Let me know if this makes VP9 4k 30fps fast enough for you. I would also like to know if HDR works for you.
Posts by jernej
-
-
Well, if you don't have wifi+bt module connected, then having overlay for it is pointless. But I agree that it shouldn't make any harm, just some overhead. I don't see any issue in wifi+bt overlay, so maybe you can just omit it and be done?
-
Can test on modern HDR capable monitor if needed, but guess not much point until H6 HDMI driver gains ability to send HDR metadata to display.
That ability exists for some time now and it works for HEVC videos, didn't test VP9 yet (I heard HDR metadata is packed differently in VP9 streams). However, colours are still off - HDR is usually connected with 10-bit output, which isn't implemented yet.
EDIT: one IOMMU issue is probably fixed with https://www.spinics.net/lists/kernel/msg4055249.html
EDIT2: above patch indeed fixes kernel warning and H6 indeed sends HDR info to display when playing your Costa Rica VP9 10-bit HDR demo, I updated my iommu branch, if you're interested
-
I'd say this VP9 fix patch should go to master, nice job!
Thanks for testing! This is just a quick hack and it uses more memory than necessary for 8-bit videos (unconditional buf_size *= 2;). I'll make proper patch series soon, hopefully over next weekend.
10bit HDR plays with washed out colors, but thats probably expected, H6 HDMI hardware tonemapping most likely isn't implemented yet.
I suppose you're testing this on non-HDR capable screen? During writing 10-bit HDMI output support, I noticed that HW does proper downscale from 10-bit to 8-bit, but that is probably just averaging. There is HW for applying HDR tonemapping, but I have no idea how to use it nor how to integrate it in DRM framework.
Typical 4K 8bit VP9 decodes at ~32 FPS, and 4K 10bit HDR is slower at ~24FPS. Probably ffmpeg decode path isn't 100% optimized yet.
Allwinner datasheet only promises "VP9 Profile 0/2 4K@30fps", so 4K@60 most likely isn't achievable on H6.Yeah, ffmpeg is not optimized yet. As I said before, adopting RPi HEVC approach should yield more performance, but that probably won't happen soon.
Tested this patch on both master(cma=1024M) and iommu branch.
Looking good, not a single error in logs!
We can't afford to set CMA so high, some boards only have 1 GiB of RAM. But I'm glad IOMMU doesn't report any issue. This means my quick patch is sound.
-
Log shows that TV was properly detected (all resolutions are listed) and you even played video. Make another log, this time make sure it's created "during" the issue, e.g. when you only hear sound effects but Kodi is not visible.
I'm not sure what needs to be done in order for kernel to pick up edid file. FAT partition is mounted to /flash, so proper line would be /flash/edid.bin, but then kernel might request file before /flash is even mounted... Anyway, reading EDID should not be problem even if TV is turned off. Try with only video=HDMI-A-1:D
-
offbeat you can try this patch to make VP9 10-bit work (downscaled to 8-bit): http://ix.io/3Qje
-
That's actually a good clue! This means some buffer is too small. With a little extra debug output, it shouldn't be that hard to figure which one. Well, there are some additional registers to set, but hopefully, that's all.
-
There is a reason why I didn't PR those changes yet
Although VP9 worked for me. -
there is a merged commit "Add analogue audio driver to Allwinner H6" for the 5.4 kernel.
Analogue audio is not implemented there. However, I know where confusion comes from. H6 contains AC200 IC integrated alongside SoC. AC200 is responsible for several things, like Ethernet PHY for fast ethernet and also analogue audio. So patches mentions audio, but only functionality really implemented there is Ethernet PHY.
-
Cherry picked iommu commit, xtest.patch doesn't apply, probably something already in master.
Yes, just remove this chunk: https://github.com/jernejsk/Libre….patch#L98-L106
-
offbeat if you have video sample which causes out of CMA memory issue, I would appreciate if you can provide it to me. However, this should soon become issue of the past, I'm working for some time now on fixing all IOMMU issues and once fixed, Cedrus will use normal memory allocator instead of CMA. Interestingly, IOMMU is great debugging tool. If there is access outside of designated buffer, it complains. This already allowed me to fix some Cedrus bugs. Anyway, if you want to see current progress (some H264 videos and HW deinterlacing doesn't work), you can check https://github.com/jernejsk/LibreELEC.tv/commits/iommu
GPU suspend issue is really unfortunate, but no panfrost developer on IRC seems to be particularly interested in fixing that (at least at time of asking some time ago). I looked into this quickly, but it's way over my head, GPU drivers are not my cup of tea.
HDMI output can randomly drop out for a second, both during playback and in menu. Probably some output timings issues, since sometimes (rare though) TV gets confused and refuses to display certain Hz videos, requiring on/off cycle, which never happened outputing from my other STBs.
I went over BSP HDMI driver code many times now and I believe everything is as it should be with latest nightly images, except maybe some minor HDMI PHY settings. I haven't experience any HDMI related issue for a long time. I learned the hard way that HDMI signal quality also depends on board design. During development of H616 HDMI driver I didn't have any luck of getting 4k output on OrangePi Zero2 board. It turns out, 4k also doesn't work with BSP kernel image. However, on H616 TV box, everything work as expected.
H6 still needs algorithmdirtyregions=0 set in Kodi, otherwise any video will stutter.
I don't experience that, not sure why.
10bit HEVC plays just fine, 10bit VP9 isn’t really working yet (decodes to garbled pixels). Can’t vouch for colors, most likely TV only gets 8bit for now.
True on all counts. VP9 driver is pretty new, nobody really worked on 10-bit support. I did a quick check, but nothing stands out. It needs detailed analysis. 10-bit HDMI output is being worked on.
Note that ffmpeg decoding loop is not optimized for speed, ideally RPi ffmpeg code for HEVC should be reused (it uses same interface as Cedrus) since it was already improved for speed. Also HEVC supports AFBC "compression", which makes memory accesses more efficient and that translates to higher decoding speed. Needless to say, that also needs to be added.
So, H6 still has a lot of untapped potential. Many issues/missing features are being worked on, but currently I'm busier than expected, so progress is slow. Some issues are not addressed at all, mostly because I don't experience them, so any kind of detailed analysis is impossible.
-
if I start my PineA64 (or any other PC) before the TV turn on, I cannot see the Kodi interface, instead I see the last terminal message in the up left corner and the LibreElec logo in the center.
This is probably Kodi issue, not LE. At this point it would be interesting to know if Kodi is running (output of top) and information provided by pastekodi
I've tried to use edid.bin inside FAT partition and andd commands inside the extlinux.conf file, but the Pine64 does not start, and I got a critical error.
You have to be much more specific than that. What exactly did you write, what edid.bin file did you use, what error did you get?
I've tried to use the command getedid create but I got the error getedid: command not found.
what are you trying to do with that command?
-
Is there any chance to get the H6 internal DAC to work with LE?
Someone needs to write a driver for that. To this date, no one has.
-
I believe "bus-emac already disabled" will be fixed in kernel 5.17. I have zero idea about the first issue, though. It's best if you send bug report to [email protected]
-
As long as it is IR related, it's fine IMO.
-
I know, I own the board. However, Linux rule is that if something is missing, it's not enabled. Sockets/headers don't count. So just add above lines and it should work.
-
Neither wifi nor IR receiver are present on Pine64+ board by default. Did you add any of them by yourself? If so, you should activate them via DT overlays first. Just add FDTOVERLAYS /overlays/sun50i-a64-ir.dtbo /overlays/sun50i-a64-pine64-wifi-bt.dtbo to extlinux/extlinux.conf on FAT32 partition.
-
No, issues are not the same. 4K 10-bit decoding works, but as I said, colours are not 100% correct, because it's rendered as 8-bit. I'm working on this.
I doubt you'll find any 1 GB RAM H6 box. Lowest specs are 2 GB and that's already enough. Note that most boxes use 100 Mbit ethernet for some reason. Also worth considering is wifi. Most chips are not supported, but at least for 3 most popular modules, drivers are WIP. Last but not least, only 2 distinct H6 boxes are supported by LE - Tanix TX6 and Beelink GS1. Most of cheap boxes on market will be compatible with Tanix TX6 image. However, they will probably have different IR remote keymap, which will make them impossible to wake from sleep via IR and of course, you'll have to set up your own IR keymap for navigating.
