Posts by chewitt

    Shouldn't an S905 handle HEVC completely in HW, I've finally finished setting up my Odroid C2 with the profiles and libraries and now when I went to test playback some stuff played perfectly with seeking and everything, some didn't play at all and some were stuttery. As far as I know my Odroid should handle HEVC at 4K/30 HW, at least that's what it says on the manual, so why am I getting these issues?

    The point being made was that MPEG2 media can be (or could be, if we disabled the broken MPEG2 hardware decoder) be decoded in SW.

    S905 does indeed have hardware HEVC decoding capabilities, but with some bugs (seeking is one of them) that remain unresolved pending the attentions of someone with coding skills taking an interest in fixing them (so not me). The H264 hardware decoder is generally in a much better state, and everything else (apart from MPEG1/2) .. e.g. MPEG4 is software decoded.

    The vendor kernel still runs best on Amlogic hardware, but that's outside the scope of this thread or upstream kernel images.

    I've been trying since last week to reboot my odroid but it always just shuts down, tho I should mention that the LE logo does appear and looks like its trying to start when it shuts off. No matter what method I use whether it's from SSH (reboot or kodi-send --action="restart") or the gui it's always the same. And to turn my device back on i have to unplug and replug it, sometimes several times which is starting to worry me.

    When the board boots (u-boot first, then kernel, then userspace) the kernel init script loads the LE boot splash. When Kodi starts, it renders to a full screen 'Window' and this overwrites/obscures the splash. If you manually stop Kodi the Window goes away to reveal the underlying layer with the splash again. If a shutdown is slow enough you'll see the same; Kodi stops and the splash is revealed again. If the screen then goes black, e.g. TV loses the HDMI signal and then you see the splash again; it suggests the board has rebooted. If you don't see the black loss of signal and the LE splash remains on-screen it suggests the board is never shutting down. If you only see the black/lost-signal it suggests the board shuts down and either never reboots; or it reboots and hangs before the kernel init runs.

    I haven't boot tested a C2 for a while, but it was working fine last time I did, and nothing has really changed. For kicks you can try this on a clean SD card: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz (removing all add-ons and such from scope is never a bad thing). If you see the same and have an old shitty SD card (no fancy fast speeds) lying around that's also worth testing to rule out issues with voltage changes not happening (not resetting the card to a state where it can be seen on boot). Testing a clean card also proves it's not just an old/bad/dying card (they don't last forever) - the same applies to emmc modules.

    The best way to really understand what's happening is connecting a UART cable as this will clearly show the early stages of boot (u-boot and kernel) and where things get stuck or not.

    And (as has already been said) whatever the issue is, it is guaranteed to have nothing to do with CONFIG_MESON_DRM in the kernel.

    Creating /storage/.please_resize_me will result in the current partition being removed and a new one being created on the next boot. This is a destructive action that will nuke the current contents of /storage, so you probably don't want to do that.

    Instead, take a backup using the LE settings add-on, move it somewhere safe, then clean install the same LE version you're currently running to the new SD card (which will use the full space of the card) then use the settings add-on to restore the backup onto the new card.

    Doing a backup/restore is normally a lot faster than card cloning methods because the amount of data 'on the card' is normally only a fraction of the large capacity of the card; whereas cloning requires you to bit-for-bit copy the card including all the unused space.

    Power Off is simple to handle because there's a functioning OS that can be (re)programmed to deal with whatever IR or RF keyboard codes the remote sends to run a shutdown. Power On requires something to always be powered and listening/waiting for a specific IR code; that wakes the internal power circuits to (re)start the device. And yes, about 95%+ of all hardware used for LE (all RPis, all NUCs, etc.) do not have that little extra circuit that remains powered to switch things on again. RPi devices can be modified with an add-on board that hosts an IR receiver and a small power circuit that's always-on and provides board power via the GPIO pins. There are IR/remote add-on "lids" for some NUC devices too; but rather expensive.

    TL/DR; If the Beelink box has an IR wake function? you might be able to get a programmable IR remote and configure it to wake the box. I'm quite sure the Minix remote is not programmable though, so even if it does have one you're not going to make that combo work.

    I use an Apple Airport Express WiFi basestation in Wireless Bridge mode for development as it means I can just connect an Ethernet cable and whatever board I'm playing with gets an IP address without having to muck about with WiFi drivers or configuring a connection. The last one I purchased (admittedly a couple of years ago) was about $20. It's not a blistering fast wireless connection, but it's "fast enough" for streaming moderate bitrate content for LE box/board testing and means I don't need to run a cable through three walls.

    TL/DR; any bridge device, or any router that can be configured as a bridge, is what you need.

    An S905 can almost handle 1080p HEVC in software so MPEG2 at 720p/1080i should be do-able. It would still be nicer to have proper hardware decoding.. but that needs someone to take an interest in the vdec code. MPEG2 isn't a complex driver, and it's likely broken due to a few small changes due to general V4L2 evolution since it was first written, but we're approaching three years since someone last seriously looked at the code and it appears nobody (who can code) cares enough to look.

    Is there progress on regression in MPEG2 hardware acceleration (S912 SoC's) ? Or perhaps, can you add separate switch for turning MPEG2 acceleration ON/OFF ?

    One of the HK forum regulars started to look at the MEPG2 code, but then stopped, and that was a year ago. It's probably easiest to just drop support for MPEG1/2 in the driver. This will force FFMpeg to decode in software. As MPEG1/2 media is almost always SD it's not challenging to handle in software - as much as it would be nice to use hardware decoding.