PROJECT=Allwinner ARCH=arm DEVICE=A20 scripts/create_addon inputstream.adaptive
Posts by jernej
-
-
Will the H6 get RGB LCD support ?
While in theory should be easy to add, there is no plan to do that. Mostly because no LE developer has such HW. Doing any kind of development without HW is hard and wastes a lot of time.
-
mike2002 offbeat Thanks! Issue identified: libdrm: update to 2.4.105 by heitbaum · Pull Request #5301 · LibreELEC/LibreELEC.tv · GitHub
Nightly images will be unusable for a few days until issue gets resolved. Decoding works if libdrm is downgraded to 2.4.104, but that's not a proper solution.
-
That is why I was wondering if they will continue to publish tanix nigtly,
Yes, Tanix TX6 nightly images will continue to be published for foreseeable future.
-
Just start with the tanix image from the 21st. Since then, no more nightly have been posted to test?
I just checked and there is today's nightly image.
The image of belkin does not start.
Do you mean Beelink? Most probably your board is too different to that.
Anyway, Q+ is not supported, because no developer has it.
-
Does this setting correspond to every single video playback? I see I have to disable it on every channel separately.
I don't know, to be honest. I just know that I need to fix some corner cases with this functionality...
-
Kristian Test images are updated to beta2. This time I actually test them and they work as well as before.
-
Sorry Jernej, but I can't find it! Which settings menu should I search? I've got "System", "LE", "Player", "PVR"...
Not in general settings, but settings which can be opened during video playback.
-
levitsky86 I know another issue with interlaced content, which probably affects you. Before I fix it, there is no point of providing logs. However, please check if disabling deinterlacing helps in any way. Check in settings menu, right from pause, stop, rewind buttons.
-
mo123 I know there is enough documentation and source code to implement this, but I would need to study how it works. It may or may not be easy to implement, but my focus are Allwinner SoCs, which I know well and although they work pretty well by now, there is still much to improve.
-
There are experimental images (not in LE master branch) for AW, while AFAIK it doesn't work for RK. Both, AW and RK, platforms needs HDMI and I2S driver improvements in order to make it work. HDMI driver is common between these two, but I2S driver is not.
Note that AW experimental images are reportedly broken - I have to update them and re-test.
-
By HD audio you mean passthrough?
-
No, just put it in /storage/.update and reboot - it will be updated during next boot.
-
Now here is no image corruption, but the images freezes. Stop and play channel solves it.
How often freeze happens? Same amount as image corruptions before?
The second time I had frozen not only image but the whole Kodi that had self rebooted after a while.
Please enable debug logs in options and when crash happens, upload crashlog(s) from /storage/.kodi/temp and provide link
-
levitsky86 -=guybrush=- Please test this update: LibreELEC-H3.arm-10.0-devel-20210425125640-5701db2-h264-fix.tar
I think you should not see corruption anymore.
-
Better don't compare it to Rockchip, Amlogic or Allwinner - they needed 4+ years and are partly not even there yet
I tend to disagree (except about AML part) AW and RK support deinterlacing while RPi does not. RK is also almost on pair regarding HDR. In short, each platform has features that are not necessarily implemented on others. But I agree that RPi development progresses much faster.
-
I did exactly as the Official guide says, but the TrueHD and DTS-HD are not working at all.
High bandwith PT won't work - at least two drivers need to be extended and ALSA config must be changed accordingly. I created hackish experimental implementation for Allwinner, but I don't have knowledge about Rockchip internals to do the same for RK.
-
offbeat Thanks for detailed analysis. Enabling performance governor on H6 is not a good idea because H6 generates a lot of heat even on lower frequencies (many are not happy with that). You can of course enable it locally.
There is a reason why Allwinner port is marked as "stable beta" in LE10 release announcements. There is plenty of corner cases which needs to be fixed, but I'm actually quiet happy that it works as well as it does. Decoding using request API in ffmpeg is known to be suboptimal. We didn't rewrite it just yet, because kernel will in near future receive some uAPI updates which would allow even more efficient decoding. As mentioned before, GPU frequency switching doesn't work on H6 for some unknown reason, which nobody can figure out. However, maybe default frequency can be raised same way it is done for A64 (via DT)? This would be acceptable until dynamic switching is figured out.
Note that I don't know for any peripheral which would rely on CPU clock directly. You can always check how clocks are related and configured in /sys/kernel/debug/clk/clk_summary. VPU, DRAM and GPU have their own, dedicated PLLs, which makes them independent from rest of the system.
P.S. Testing it was a pain, the way ffmpeg is packaged in LibreElec is sooo confusing, binary programs aren't included in base build at all and ffmpeg-tools addon uses completely different build options, without any hardware decoding patches...
I actually use separate distro (Arch for ARM) when developing ffmpeg/Cedrus or other, mostly display related features. I apply all relevant LE patches to kernel and then netboot it. This allows much quicker turnaround time. However, I test Kodi only with LE.