Posts by chewitt

Netflix is software decoded on all Linux hardware (the addon mimics a browser with an L3 widevine cert) so max resolution etc. will be constrained by hardware CPU performance. There is no way to use the L1 certs embedded in some boxes from Linux because we're a generic distribution and the secure boot code required is both closed-source and device-specific.

Maxime and I did a mountain of testing since ~June so the 8-bit side of his code is in great shape, but there are still milestones to achieve. The DRM driver that underpins everything is missing 10-bit capabilities so we're unable to fully test the HEVC parser code in the vdec and Maxime is still working on seeking (which is more about Kodi and ffmpeg than his vdec). There is currently no hardware deinterlace code (only software which is watchable but not brilliant) and we still need to persuade that and VP9 support into existence. On the positive, we have HDMI 1.4 (up to 4k30) working - although only for 2GB+ boards as Amlogic's alternative to AFBC isn't supported in the DRM driver yet so we're using too much RAM. The mainline kernel is also missing HDR support, but based on recent email exchanges with Intel staff we'll see some movement on that soon and we'll be able to hook into the same kernel frameworks. Kodi is also seeing some love in that area so at some point between K18 and K19 you'll be able to watch an HDR movie without having to force the colourspace and other dumb crap that doesn't work in older 3.14 kernel releases. We're also missing multi-channel audio support but the same Synopsys audio IP is used in a broad ranges of Amlogic, Allwinner and Rockchip hardware so there's a plan to pool efforts and collectively solve that at some point.

So right now if you only want 1080p or 4k 8-bit video + stereo audio it's pretty stable and usable. I'm not planning to start major public testing until after 9.0 ships and a few more pieces of the jigsaw come together - largely because I don't have the bandwidth for needy users and the support work that releases entail. I'm not sure if we'll jump to using lima immediately - it's not perfect yet (as that video shows) but that will come with time and love. NB: There's also been recent progress on the lowest-level boot code (ATF etc.) which is the final layer of closed-source Amlogic code to tackle. If that work completes it's indeed plausible that 2019 might see GXBB/GXL boards running a 100% open stack, which would be awesome and frankly rather amazing considering where things were a year ago.

Lima woke from slumber about 4-5 months ago and started showing progress and we've been engaged with Yuq since - the video you've posted was created this morning by LibreELEC team member koenkooi and an equivalent LE image is my task this evening. We've also been engaged with the panfrost developers for some time and recently persuaded a couple of them to accept S912 boards so development can be done on a modern mainline kernel instead of Chromebooks that require an ageing Rockchip 4.4 codebase. We are being our usual helpful and supportive selves and Kodi support is seen as a worthwhile panfrost objective. I'm confident panfrost will be the missing piece of the long-term jigsaw puzzle we need for S912 support, but things are still at an early stage and it will be some time before panfrost code is in a mature state that's sensible to use (we did get it to show bits of the Kodi GUI tho!). I'd guess another six months is needed - the midgard/bifrost chips are mind-bogglingly more complicated (and completely different) compared to the older utgdard chips.

These chips are not supported on our current codebase and require the Amlogic 4.9 kernel which is not fantastic - the quality of Amlogic's botch job proprietary code has not improved and the overall kernel has become more Android oriented with time. Also, S905X2 does not guarantee GB ethernet (lots of boxes will use a 10/100 PHY) and while the Mali G31 is more capable than older Mali GPU's the performance increase is largely lost on a simple app like Kodi where rendering is capped at GLES 2.0 anyway.

So the forward path isn't clear yet. For some time our development focus has been on moving away from bug-ridden old kernels and onto a modern codebase, but while Amlogic have been sending patches for G12A platform support to the kernel for a while it's still in an early state and mainline kernel LE images for these boards are not currently possible (i've had hardware for a while). The 4.9 kernel also has a crop of new bugs to find and fix (in addition to loads of unresolved old ones inherited from the 3.14 codebase) and ultimately it depends on amcodec support which exists today but will be removed in Kodi v19 - so it's a load of work with a limited lifespan.

IMHO these devices should stick to Android until mainline kernels are viable, but I daresay users will be pissy with that suggestion and someone on the team will be forced to grapple with the 4.9 kernel mess as a stop-gap. It won't be me though

LE targets HTPC hardware not recycled old laptops whereas Ubuntu targets everything. We have no interest in adding the drivers to support an old laptop with a weak GPU that requires drivers that are known to be problematic. So if it works with Ubuntu .. stick with Ubuntu. Sorry..

No idea.

Quote from gregeeh

1. Would you recommend I stay with the AML platform (S912) and wait or swap to another platform like Allwinner or Rockchip?

2. As the main usage of these boxes is to stream video, and the issue I have described is related to streaming, why are AML products being recommended when this bug clearly interferes with the boxes main purpose? Sorry, but I just don't get it

Allwinner support is in the earliest of early stages of support. It will be some time before it matures. Rockchip is further up the curve but still subject to major rework before we publish a full release. Rockchip is both better and not as proven as the Amlogic 3.14 mess (which has been used long and is a bit more refined). If you already have the S912 box; it's a good box, be patient.

As a general rule Amlogic behaves well with most media. There's always going to be some exceptions though. If anyone else wants to investigate I won't stop them - it won't be me though.

Frequent corruption issues are often the result of an inadequate PSU .. the other cause being a card that's on its way out.

LE has always required a formatted target. The installer script uses the "blkid" command to identify potential install targets and blkid won't show anything unless the storage has been formatted with a filesystem first. It doesn't matter what filesystem is used, only that there is one.

If you attach a USB keyboard you should be able to run commands. It's attempting to follow the boot=UUID=UUID-5BE6-0135 param to mount /flash and the SYSTEM file to continue booting. The UUID is presumably wrong and boot params in extlinux.conf need to be corrected.

Yes, if you use the correct device-tree file.

ping CvH ^

The main issue with current Amlogic hardware is low-quality kernel source full of bugs and proprietary code and the amcodec interface which has lots of hacks to workaround the bad kernel source. We've cleaned up some major issues over time but there are lots of minor ones that aren't resolved - and won't be resolved (on that codebase). The long-term solution for Amlogic hardware is to move up to mainline kernels. This won't be a magic cure-all (new code = new bugs) but since the underlying codebase will be common to all our platforms (Generic, Raspberry Pi, Amlogic, Allwinner and Rockchip) the process of fixing stuff will no longer depend on someone working up the enthusiasm to poke sticks at a bad kernel source where fixing one thing frequently results in fresh breakage somewhere else. We are months (not years) from making the mainline jump.

NB: I wouldn't read too much into the S912 future story as the situation has changed. Open-source alternatives to the missing libmali are taking shape, we are well engaged with the developers and Kodi support is a mutual goal. I'd estimate we're about six months from a usable solution.

You can ignore the false warning (because os.libreelec.tv is installed) and continue or wait until the next Alpha release is out where we've added a temporary patch to prevent the warning - pending Team Kodi doing something to properly fix the issue.

Has that been flagged to any of the kernel mailing lists?

Quote from chessplayer

Anyway, thanks to you (and all the other active developers) for making it possible for users like me to play with our toys! I do hope that you also profit from donations made to LibreELEC

We profit from the personal experience of participating in the project and having fun, but otherwise we are non-commercial and aim to raise no more funds than we need to cover the project's running costs.

Nope, because decoding and rendering are separate things. Even if FFmpeg supports NVDEC for decoding we still need to render the decoded video via a zero-copy code-path and this is where the issue lies. Kodi supports GBM and nVidia's driver supports a competing "standard" (used only by nVidia) called EGL Streams. So Kodi will need to add another vendor-specific code path just for nVidia. The two logical candidates to do that within Team Kodi are lrusak (who wrote the GBM code) and the main architect fertnetmenta (who maintains VideoPlayer) and so far neither of them are interested.

Could be a while. Our efforts with the RK 4.4 kernel codebase have been a stop-gap until VPU support for the mainline kernel was available and the changes to add this now been submitted so we've started the lengthy process of rebasing against Linux 4.19 - which means no more real-world effort against the 4.4 codebase.

NB: Next 9.0 Alpha will come out with changes to Kodi but nothing much more. We have no plans to release Rockchip Beta or full release LE 9.0 images - Rockchip will remain in an Alpha state until at least LE 9.2.