Posts by offbeat

    3. Cedrus needs to be more resilient to stream errors (mostly missing references for B and P frames)

    Oh yes, from my personal experience, SAT stream quality goes from 100% bit-perfect to unwatchable mess of pixels, even with all the DVB error correction algorithms. Thunderstorms, snowstorms... can't beat physics.

    H264 and H265 decoders as well as TS container parser just has to be resilient as hell, able to consume pretty much garbage input without crashing. Drop frames and move on.

    Actually, if ffmpeg decoding with -f null - works, I think issue might be in display driver or misreporting actual buffer information, like size or stride.

    ffmpeg -f null - doesn't work for these HEVC samples, not display output involved.


    But tested with EGL rendering, just in case, iommu still faults.

    should improve VP9 decoding speed

    ffmpeg VP9 decoding test shows some improvement, but not much, can't reach 30fps for 4K HDR sample.

    Code
    ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i COSTA.RICA.vp9.2160p60.HDR.mkv  -f null -
    
    frame= 1644 fps= 28 q=-0.0 Lsize=N/A time=00:00:27.46 bitrate=N/A speed=0.47x 

    Maybe bottleneck is elsewhere, or VP9 decoder clocks aren't set to 576MHz.
    I see 552MHz for both decoders in clk_summary, if it can be trusted.

    Code
    /sys/kernel/debug/clk/clk_summary
        pll-ve                            0        1        0   552000000          0     0  50000         N
           vp9                            0        1        0   552000000          0     0  50000         N
           ve                             0        0        0   552000000          0     0  50000         N



    hopefully lower issues with Cedrus based decoding

    IOMMU still crashes on my HEVC .ts samples

    Code
    ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i NASA.x265.2160p60.ts -f null -
    
    [   60.534272] sun50i-iommu 30f0000.iommu: Page fault for 0x000000000001c000 (master 1, dir rd)
    [   60.534309] IOMMU: Level 1 page error
    [   62.557439] cedrus 1c0e000.video-codec: frame processing timed out!


    I would also like to know if HDR works for you.

    Yes, HDR output works, my monitor does switch modes!
    Colors look very similar for both SDR and HDR versions of Costa.Rica VP9 sample.
    But obviosly 8-bit output, heavy banding in gradients while playing HDR.


    Here are photos of monitor OSD with some technical data.


    HDR:


    SDR:

    I updated my iommu branch, if you're interested

    Thank you, no more drm_gem errors!


    Retested my NASA and F1 .ts HEVC samples. Interesting thing, all three samples fault IOMMU when fed through ffmpeg command line at max speed, but only F1 faults when played on normal speed through Kodi.


    Will test HDR metadata tomorrow, when I get to monitor.

    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.

    Yes, my H6 box is connected to 12-year old 1080p SDR TV, used to be rather high-end. According to EDID it supports 10bit and 12bit colors, but its definitely way too ancient for HDR.


    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.

    can try this patch to make VP9 10-bit work (downscaled to 8-bit)

    Tested this patch on both master(cma=1024M) and iommu branch.

    Looking good, not a single error in logs!
    Works for every 8bit and 10bit VP9 sample I've got, all from Youtube anyway.
    10bit HDR plays with washed out colors, but thats probably expected, H6 HDMI hardware tonemapping most likely isn't implemented yet.


    Also tested bare decoding speed with ffmpeg commandline:

    Code
    ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i sample.mkv  -f null -

    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 [email protected]", so [email protected] most likely isn't achievable on H6.


    I'd say this VP9 fix patch should go to master, nice job!

    Quick test of iommu commit:


    1) Kodi starts with a few drm_gem errors, but keeps running

    2) Some HEVC videos give iommu faults, requiring reboot. Uploaded F1.x265.2160p50.ts sample to GDrive at the link above.

    Code
    [  111.890421] sun50i-iommu 30f0000.iommu: Page fault for 0x000000000000e000 (master 1, dir rd)
    [  111.890445] IOMMU: Level 1 page error
    [  113.890831] cedrus 1c0e000.video-codec: frame processing timed out!

    3) VP9 10bit videos are failing with iommu fault as well

    if you have video sample which causes out of CMA memory issue, I would appreciate if you can provide it to me.

    Samples – Google Drive

    Two HEVC [email protected] samples, one seems to be 8-bit, another is 10-bit. Both captured from NASA UHD TV channel, free-to-air on Hotbird 13E satellite.

    H6 can't play any of these with default CMA settings, partially decodes first frame, green screen rest, kernel log full of cma errors. No more errors after booting with cma=1024M, but playback isn't smooth. Also, for some reason Kodi switches from 60p to 30p output after a second of playback.


    I'm outputing to 1080p60 TV, so there is some downscaling involved as well.



    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

    Cherry picked iommu commit, xtest.patch doesn't apply, probably something already in master.

    If you want to get this solved please try the suggested addon change.

    I did a full clean and rebuild of latest master with with Python 3.9 and DEBUG=yes.
    Made Kodi crash relatively quickly, by scrolling around, trace attached.


    And yes, disabling script.embuary.info seems to help, can't crash Kodi by navigating in video lists anymore.


    Then I've reenabled embuary and got this error in kodi.log

    In most cases LibreELEC uses eventlircd as a shim to pass IR button presses from kernel to Kodi. This approach is stable and reliable, but has one rather major drawback: it’s impossible to use longpress events, which in fact halves the amount of actions you can bind to your IR remote buttons.


    Alternative approach is to disable eventlircd altogether and use IR remote as a Linux keyboard device, so this is a way I went.


    LibreELEC documentation says “Kodi ... doesn't cope well with Linux input events”, I’d say this is the understatement of the century, to put it mildly. Kodi keyboard handling system is archaic, weaving layer upon layer of abstractions, throwing away more and more of your keypresses, the deeper it goes.


    To my understanding, the way IR keypress travels towards Kodi in is:

    1) Linux kernel decodes IR signal and translates keypress to evdev scancode, based on IR remote .toml definition, loaded by ir-keytable.

    2) Xkbcommon library assumes we got a standard pc105 keyboard and translates evdev code to something resembling xfree86 keycode, according to /usr/share/X11/xkb/keycodes/evdev

    3) Xkbcommon library futher translates xfree86 keycode to xkb key name, mapping non-printable keys according to /usr/share/X11/xkb/symbols/inet

    4) Kodi accepts a very limited subset of xkb key names, filtering them and mapping to Kodi internal keysyms, according to code in xbmc/platform/linux/input/LibInputKeyboard.cpp

    5) Kodi goes through another layer of translations, from Kodi internal keysyms to Kodi internal vkeys and Kodi keynames, relevant code in xbmc/input/XBMC_keytable.cpp

    6) Kodi once again translates, keynames are mapped to actions, based on default rules in /usr/share/kodi/system/keymaps/keyboard.xml and user customizations in ~/.kodi/userdata/keymaps/keyboard.xml


    Every layer of this onion has some random historical subset or superset of non-printable keycodes hardcoded in, throwing away everything else, sometimes in completely illogical way. There is no way for user to bind directly to kernel evdev scancode, is all buried and hidden away. I’m afraid to look at the Windows or Android keyboard abstractions, probably not much saner.


    But in the end I managed to dig through this spaghetti and made a .toml keymap for my IR remote, scraping together some 50 evdev keys Kodi actually lets through the cracks. Longpress events work for me now, yey. Hope my keymap can help someone with the same problem.


    Beelink GS1 Ethernet sometimes fails with a "transmit queue 0 timed out" error, resulting total loss of connection.



    The only way to get it back alive without rebooting is to rmmod/modprobe dwmac_sun8i

    Rmmod gives two additional errors "bus-emac already disabled" and "bus-emac already unprepared"


    I got H6 Beelink GS1, using it daily for a last few weeks with 1080p TV, so can give some feedback.


    It’s certainly usable, smooth hardware playback 1080p60 8bit for all three relevant codecs H.264/HEVC/VP9. No problems seeking videos.


    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.


    4K60 is probably only realistic with HEVC, both H.264 and VP9 hardware decoders seem to only handle 4K30. Had to increase kernel CMA memory reservation while trying 4K60 10bit HEVC, defaults are too low.


    Now, some some bugs and annoyances:


    Hardware deinterlaced videos tend to stuck after resuming from pause, need to seek to get them going again.


    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.


    H6 still needs algorithmdirtyregions=0 set in Kodi, otherwise any video will stutter.


    HDMI CEC seems to be very stable and usable now. But I had to disable it, because Panfrost GPU drivers ability to sleep is still semi-broken, every second or third attempt to suspend fails, so TV gets woken up by CEC, etc.


    Crust co-processor firmware rocks as well, this box consumes pretty much zero watts in sleep. If Panfrost will let you to suspend it, that is :)

    H6 box can also be configured to support pretty much any IR remote, including wakeup button if you bother to rebuild Crust. I certainly did, reused big comfortable remote from old mediaplayer.


    Theoretically, if display output stack gets some upgrades, H6 can become as capable video player as RPI4: 4K60 with 10bits and HDR should be real.

    but you've got to have a developer who has the time to put in hard work

    Developers on payroll of Realtek and other vendors put their time in either way. Its management who wasn't interested in going extra mile mainlining code, adjusting own deadlines, etc.

    I'm happy that some companies are starting to see the benefits of mainlining things, others are getting pushed there by Google because of Android sertification.


    For us, end users, it will hopefully result less fragmentation, less e-waste. And maybe one or two less video decoding standard to care about, if we stay on topic.

    Maybe a bit off-topic and maybe too philosophical, but do you see the vendor-specific ARM-based stuff as the 'future' of Kodi?

    Got two rather ancient old media devices running in my living room.


    First is media player, MIPS Sigma SOC. Fantastic hardware, plays any 8bit H.264 with dynamic Hz changing, every older codec, not a single visible framedrop and glitch. But welcome back to year 2007 and say hello to kernel 2.6.22. If you want to play something off network share, open up SMB1.


    Another one is DVB-S2 SAT receiver, MIPS Realtek SOC. Once again, vendor blobs, kernel 3.13, you get what you get. Want to plug additional DVB-T USB stick supported in mainline? Tough luck.


    Both devices got hardware beefy enough to run something like LibreElec (3D acceleration, hardware video decoding, enough RAM), yet both are rotting away, feature and security wise, waiting to become e-waste.


    Who wants such 'future'?