Decided to give the nightlys another go after 6 months on my OPI3. All hardware seems to work nice, however most videos have a shudder, like they're going at maybe 15fps.. Is there current problems with video decoding on the OPI3?
Posts by dmarkey
-
-
Not much look with 4K video on the nightlys, one OOM killer and one garbled video
Cec, Wifi and Wired work good though!
-
Are the nightlys best for Orange Pi 3 or is there some secret build floating around? jernej
-
I just got an OrangePi 3 and RPI 4 arriving in the same day
Anyone know is the H6 faster than the BCM processor the RPI 4 has?
Seems out of the box RPI has better support but will test more later.
-
Anything I can do to help get CEC to work on the x96 max?
-
Sorry is seems if I use the meson-g12a-x96-max-rmii.dtb ethernet works. but 100mb, maybe it's not gigabit
-
A few problems on the X96max 2gb (I believe this is gigabit NIC) - with a build of the latest github branch.
NIC not starting:
HVEC crash
Code[ 565.048555] meson-vdec ff620000.video-decoder: Direct firmware load for meson/vdec/g12a_hevc.bin failed with error -2[ 565.048571] meson-vdec ff620000.video-decoder: Unable to request firmware meson/vdec/g12a_hevc.bin[ 565.074145] meson-vdec ff620000.video-decoder: Direct firmware load for meson/vdec/g12a_hevc.bin failed with error -2[ 565.074162] meson-vdec ff620000.video-decoder: Unable to request firmware meson/vdec/g12a_hevc.bin[ 565.094814] meson-vdec ff620000.video-decoder: Direct firmware load for meson/vdec/g12a_hevc.bin failed with error -2[ 565.094829] meson-vdec ff620000.video-decoder: Unable to request firmware meson/vdec/g12a_hevc.binCEC also fails in initialise.
CodeCode[ 0.000000] Linux version 5.1.0-rc1 ([email protected]) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 SMP Tue Jun 4 18:32:28 UTC 2019[ 0.000000] Kernel command line: boot=LABEL=LIBREELEC disk=LABEL=STORAGE quiet console=ttyAML0,115200n8 console=tty0[ 0.000000] Memory: 989608K/1963008K available (8382K kernel code, 792K rwdata, 3204K rodata, 2496K init, 574K bss, 55896K reserved, 917504K cma-reserved)[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns[ 0.000166] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=80000)[ 0.012284] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns[ 0.048402] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]> -
Anyone know the git
Updated image Libreelec_s905_aarch64_20180425.
Other options for s912 and arm will be added later as build and test.
Major change.
1. The shared dtb file (dtb.img) is excluded from the image. The startup script will attempt to use dtb data from internal memory. If the system fails to start in this mode, you must manually copy the correct file from the /device_trees directory to the root and rename it to "dtb.img " (this principle is exactly the same as it has long been used in all Armbian images). You can try all the files in a row, until you have selected an option with full support for all iron TV box.
2. Added the ability to easily connect the settings file for the remote. It must be copied to the directory /storage/.config/rc_keymaps named remote-ir.conf. Additional manipulations are not required. Now already have one settings file for Khadas VIM\VIM2. If someone wants to add their own choices in the images - to send it to me indicating the model of the TV box.
PROJECT=Amlogic ARCH=arm DEVICE=AMLG12 UBOOT_SYSTEM=box make image
what UBOOT_SYSTEM should I use for the x96 MAX box (2g)?
-
Thanks, but I prefer it running slower and safer. I was wondering why the thermal section was missing from the shipped device tree, jernej solved the mistery and without a heatsink and no thermal protection the risk of burning the chip does not worth the extra megahertz.
Sure.. I have a spare
-
This DTB makes the CPU run at 1.3ghz on my OP-PC (use at your own risk)
-
Yeah, that's mainline issue due to missing temperature monitor driver. 1.5Ghz @ 1.3volts is actually already a overclocking, more like 1.3 GHz would be maximum. Anyway, you don't need any of that extra speed if you watch videos which are HW decoded.
I have to check that.
Can you check if this is related to tinkerboard: disable 5s polling for CEC adapters by viulian · Pull Request #3506 · LibreELEC/LibreELEC.tv · GitHub ?
Compiling with a similar patch fixes the problem.
-
-
Tried the Orange PI PC image and it looks like it is working quite well.
I spotted something that doesn't look right to me:
* The Orange PI PC device tree operating points table has only three states, and the fastest is 1.0 Ghz. As far as I remember, the SoC was supposed to run up to 1.5Ghz @ 1.3volts
* There is no cpufreq driver built in the kernel. Is it expected?
* About CEC, there is a Kodi thread that apparently is using a lot of cpu time related to CEC. Doing a strace over it seems to continously scan the /sys directory in search for something and never stops. Maybe there's something missing to let it find the proper CEC device to listen to
Yep is see the PeripBusCEC using a lot of CPU, and I have a CEC enabled TV.
-
can you provide sample video?
I'll try to dig one out. It may have been a 10bit HVEC
-
Trying GitHub - jernejsk/LibreELEC.tv at aw_linux_patches on my orange pi PC.
Almost everything seems to work well, "Green screens" on some HVEC videos.. Generally seems a bit sluggish.
Biggest problem is some videos are not filling the screen, some only a small box in the middle.