Posts by offbeat

  • Allwinner H6 HEVC?

    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

  • Allwinner H6 HEVC?

    Quote from jernej

    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 4K@60 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.

    Quote from jernej

    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.

  • LibreELEC-RPi4.arm-11.0-nightly-20220213-fcba5db is restarting every 20 seconds

    Quote from HiassofT

    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

  • IR remote and longpress

    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.

  • Nightly images for A64, H3, H5, H6 and R40 boards

    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"

  • Allwinner H6 HEVC?

    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.

  • Hardware accelerated video in 2022

    Quote from powerarmour

    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.

  • Hardware accelerated video in 2022

    Quote from isamudaison

    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'?

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    It's entirely possible that 144 Hz output needs some things to be done in more precise ways

    According to calculator, 1440p@144 pushes the very limits of HDMI 2.0 bandwidth, assuming H6 outputs full RGB.
    At least simple OpenGLES things like kmscube seem to render and output at 144FPS just fine, so it's only video plane output that has some glitch.

    Data Rate Required: 14.08 Gbit/s

    Video Format:

    2560 × 1440 (16∶9 ratio) at 144 Hz

    8 bpc (24 bit/px) RGB color

    Uncompressed

    CVT-R2 timing format

    HDMI 2.0 14.40 Gbit/s

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Downloaded some random popular youtube playlist, 1080p res, each video in h264, vp9 and av1.

    Latest master build for Beelink GS1, tested in both kodi and mpv.


    AV1 software decoding get H6 to its knees, all 4 cores loaded pretty much to 100%.

    H264 hardware decoding, no problems detected.

    VP9 hardware decoding, 49 of 50 videos played just fine, one produces garbled picture. Also, mpv sometimes hangs on VP9 videos, not a hard lock though, can Ctrl+C and play again.

    This VP9 clip fails to decode correctly

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Ah yes, H6 hardware decoding path also garbles everything when outputing to 1440p@144Hz my monitor HDMI defaults at.

    Downgrading video output to 1080p@60Hz solved the issue (except that one VP9 clip)