Posts by wrxtasy

    but got the impression we users of these "cheap Chinese Android boxes" were not welcome anymore.

    Does not matter which OS you use, but it's a known fact that cheap Chinese boxes have questionable, highly variable hardware specs.

    There are even fakes which you well know.

    Then there is no open sourced code for U-Boot with these cheap Android chinese devices - which can lead to all sorts of issues. HDMI-CEC control being one of them.

    With "Reference" hardware - think the VIM's, ODROID's, LePotato RPi etc - developers are dealing with known, common spec hardware where U-boot can also be properly modified. You also get direct contact with the hardware vendors - in English usually.

    What all the developers are saying is it's a hell of a lot easier to code for something that is Reference hardware, which will be the same spec no matter what users buy.

    Cheap Android devices have basically had a "free ride". And relied on the good will of guys like kszaq and others coding workarounds for them.

    Expecting new Chipset spec hardware from cheap Chinese vendors to be fully Linux Kodi supported a few months after release is just fantasy stuff. It's why they only concentrate on specific devices.

    No developer want to go out and buy this cheap chinese stuff either when Hardware vendors are getting software support for their devices, basically for free. The Hardware vendors get a great deal IMHO.

    W.

    Unfortunately, HK has made a number of serious mistakes recently, after which I do not consider their products as a good option (the rejection of the N1 in favor of the firm's AML, etc.). N2 is a slightly extended version of the usual TV box at an inflated price, and having a shitty cooling system, from which more problems than benefits and a number of other errors .

    Cough cough !!!

    Talk about a Pinocchio post... why don't you exaggerate some more and see how long that nose of yours can grow !


    Shitty cooling system hey ?

    You could not be more wrong in regard to the Hardkernel N2's - AMLS922X cooling.

    The thing barely gets above 40 degrees C during normal Kodi use - in fact it has the best passive cooling system of anything I've used - and that is quite a few different ARM based devices over the years inc. RK3399's.

    That is what you get when a power efficient 12nm (SoC) manufacturing process is used.

    And this is with everything running in Performance mode by default with the GPU and CPU clock's near Max.

    Go to the Kodi forum -> video add-on section. There you will find the unofficial netflix repository stuff.Remember that all video decoding on linux is done in software, so you need more then a little device to get 1080p working (just found out myself. Runs great on my core i5 mediacenter. a low end atom x5 however...)

    Yes that is it. I did find not need to enter an ESN number at all tho.

    Also make sure the included inputstream-adptive addon is installed and enabled - or it will have to be installed from a LE or CE repo.

    Been testing on a Rockchip RK3399 - that has the CPU ponies to do SW decoding of 1080p Netflix easily.

    Only issue I've found is not all content wants to stream from the Netflix servers at 1080p with Linux Kodi Leia for some reason.

    Android Kodi Leia with baked into hardware Widevine L1 DRM streams reliably at 1080p and also does HW decoding of Netflix with the Addon.

    (Does not work on Android Kodi Leia Mecool devices with what appears to be blacklisted L1 DRM or HDCP 1.x)

    Ah yes that pwm-get_args patch - forgot I had that one as well - already.

    HINT: if you put .patch after the commit Hash - Github with auto generate a patch for you... for quick testing.

    eg from the above link....


    356102c69b4ec19058847147f790cac0b3406fd9.patch

    Also works for GitHub Pull Requests containing multiple commits...

    eg:


    3288.patch


    Managed finally to get the Trip points & Cooling back into the actual N1 device tree and successfully compiling now.

    There is this interesting thread:

    Eliminating the crazy (fan) chirp

    And you can play around with the Fan with this patch:


    hastebin


    I'm also testing Overclocking a RK3399 N1:

    Exploring CPU Voltage & undervolting

    hastebin

    I'm no device tree expert but...

    I've been playing with the Temps and Fan control on my RK3399 ODROID N1, here is what I have extra in the .dts

    You will need a patch like linux-0009-pwn-fan-enable-rk339-rockpro64.patch and save into this directory:


    http://LibreELEC.tv/projects/Rockchip/patches/linux/rockchip-4.4/


    hastebin

    I also changed the Kernel config:

    http://LibreELEC.tv/projects/Rockchip/devices/RK3399/linux/rockchip-4.4/linux.aarch64.conf

    Change the Thermal section to:


    hastebin

    This also has to be enabled:

    Code
    # CONFIG_PMBUS is not set
    CONFIG_SENSORS_PWM_FAN=y
    # CONFIG_SENSORS_SHT15 is not set

    Issues I'm facing is the Fan run's 24/7 even with extra Hardkernel device tree trip points & cooling maps in the rk3399.dtsi

    I do get an nice cool SoC tho idling at 32 C

    More research & tweaking needs to be done.


    Other info for reference:

    rockchip-thermal.txt

    RK_VIRTUAL_THERMAL

    is needed in the Kernel config if you do NOT have a TSADC (rk3399's do have a TSADC)

    https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/thermal/kconfig#l215

    I have both RK3328 and S905X. The S905X with CoreELEC is more smoother than the RK3328 with LibreELEC. Same Estuary skin.

    Yes if you use CoreELEC Leia on AML S905's you will notice further Kodi Leia optimisations that speed everything up.

    For the C2 specifically, Overclocking it too makes it nice and snappy. So does eMMC flash storage and a Wireless remote.

    With CoreELEC & the C2, look in the config.ini file and remove the # (comment) to enable 1.752GHz CPU clocking.

    Also SSH in and crank up the GPU to 792MHz (all CE - S9xx platforms) by:

    Code
    echo 'echo 2 > /sys/class/mpgpu/scale_mode' >> /storage/.config/autostart.sh

    Then reboot.

    And for every Kodi device I use, I remove the useless "Slide Animations" to speedup the user interface up.

    Kodi Settings > Interface > Skin > Configure Skin > General > Use Slide Animations > OFF

    HDR stuff - ST.2084 PQ stuff flags the EOTF but doesn't flag Max/Average light level metadata

    That was next the question I was going to ask you.

    In user friendly English can you tell us what a normal 4K HDR user would see visually with LE Rockchip at the moment ?

    ie. color, brightness - what more than Max/Average light level may be missing ?

    is it the same as Vero 4K or S912 with a HDR supported Kernel for example ?

    Hey wrxtasy can you test 7HD playback to see if 50fps full motion de interlacing works.

    My issues since wayback

    Brief testing...

    I had to remove the 1920x1080p 25Hz from Leia's whitelist when CPU software decoding and deinterlacing.

    For RK hardware decoding and deinterlacing..

    I get No stuttering with live 7HD Perth and excellent 50fps full motion deinterlacing. Picture quality is excellent.

    Also tested 7HD with recorded TvH - AFL footy - really the ultimate deinterlacing test for full motion.

    From Mediainfo this content is h264 25i/1080 - Top Field First

    RK3399 passes with flying colors.

    I need to let TV viewing run for an extended period tho, before giving the full 3 thumbs up.

    The mpp library will automatically activate deinterlacting using the IEP (Image Enhancement Processor), for this to happen the iep and iep_mmu node needs to be enabled in device-tree. Kodi will not show any deinterlace options or reflect if deinterlacer is used or not.

    There is also a different post-processing unit in the VPU that should support deinterlacting, but this is not used by mpp library.

    Took your advice there and dtc decompiled the .dtb plugged in a couple of Okay's - recompiled.

    Bingo 50fps full motion deinterlacing on the N1 RK3399 !

    Thx.

    Any reason why this in not enabled by default in Rock Kernel RK3399.dtsi for LE usage ?

    libreelec-rk3399.arm-9.0-nightly-20190201-974f4cb-khadas-edge.img.gz

    Since it's a nightly build, it should already have PR 15286 included.

    Thx. mate.

    The Leia ARM rendering PR has made very noticeable improvements to CPU software decoding and rendering on RK3399 and all other ARM platforms.

    Smooth 1080p Netflix is now possible on the RK 3399 and 576i mpeg2 with YADIF2x deinterlacing now also works properly.

    Even low bitrate 1080p 10bit HEVC CPU software decoded content now plays back smoothly.

    wrxtasy There is no multi-channel or HD audio support in RK images at the moment.

    Similar findings --> DD+ or HD audio passthru support has dropouts or for TrueHD produces static, which also means no Atmos.

    But 7.1 LPCM audio is working for me with the LE 9.0 nightly & RK3399

    Thx. for info on HDR. Looks like we all wait for Intel Linux HDR for use with mainline.

    What does work is Kodi Leia HDR > SDR tonemapping if you software decode HDR content.

    Kwiboo or anyone else, what is the status of HD audio passthrough with RK3399 ?

    I've been testing with the old RK3399 ODROID N1 and get nothing but white noise for DTS-HD MA and TrueHD.

    LPCM audio works.

    Also status of 4K HDR with Rockchip ?

    I already know RK3399 does No HDR > SDR tonemapping.

    Already know deinterlacing is not the best either with half motion outputs and lots of video combing.

    The S905X/S905D/S912 does basic tonemapping but it's not as good as say as Apple TV 4K.

    What has surprised me is HW decode support of 10bit h264 aka Hi10P Anime with RK 3399 LE 8.9.x

    Any chance of a test RK3399 Khadas Edge release with the improved Kodi Leia rendering improvement PR included ?

    Re-edited this post again after some testing and tweaking on the RK3399 - developer board ODROID N1:

    It depends what priorities a user requires at this point in time for use with the very latest Kodi Leia nightly...

    Rockchip - RK3399:

    Limitations:

    - HDR is not fully supported, limited to only set EOTF in the HDMI infoframe metadata. See noggin 's explanation HERE

    - DD+ and DTS-HD MA/HRA, Dolby TrueHD audio passthrough not working, which means no Atmos as well.

    - HD audio decoded to 7.1 LPCM, which works well as a workaround.

    RK 3399 surprises:

    - 1080p 10bit h264 aka Hi10P Anime is hardware decoded

    - 1080p video playback is possible when using the Kodi Leia Netflix Addon

    Read the most up to date Rockhip discussion info over HERE

    Amlogic - S912 & S905(X/D):

    Limitations I can think of now when using the very latest nightly Leia (CoreELEC):

    - S905 only chipset will never have HDR support

    - HDR MaxFALL/MaxCLL metadata not yet send to HDR capable displays from the AML Linux Kernel.

    - Only 720p Max. video playback possible when using the Kodi Leia Netflix Addon

    - S912 LE / CE Kodi video playback stuttering when using external Subtitles (due to non optimal Libhybris <> Android GPU driver)

    - Workaround for that is disabling Kodi Dirty Regions in advancedsettings.xml (easily done.)

    I will let chewitt detail developments that will need to be ticked off for LE 10.x / Kodi v19 M going forward for both platforms...

    Is the S905D the best choice if I want good support for CE/LE and Gigabit-LAN (incl. a good performance for Netflix and other Inputstream based Add-Ons) or is a S912 the better choice?

    Been away from the forums for a while and been a bit busy over the S.Hemisphere Holiday period. Been doing some testing as well.

    Previously users have been wary of the S912 with it's ARM Mali T820 GPU due to uncertainty with properly implemented Linux Mali GPU drivers which will be definitely be needed for Kodi v19 M. Which is at least a year away.

    As chewitt has already demonstrated in previous posts, work is already underway to add such stable T820 GPU driver support for Kodi v19 rendering.

    The S912 always had a problem with upcoming Inputstream-Adaptive - Linux / CoreELEC Kodi Leia - ffmpeg (CPU) h.264 decoding and rendering - needed for Leia Netflix Addon streaming. In fact you could not even ffmpeg decode and stream 720p

    The Kodi Leia rending performance issue has been hunted down by @fritsch and @peak3d just today and there is now a noticeable increase in ffmpeg decoding and rendering performance on ARM platforms. 720p Netflix now works smoothly with Kodi Leia on the S912.

    See the Kodi Leia PR HERE

    In fact I can decode and playback 1080p h264 Bluray Rips and (low bitrate) 1080p 10bit HEVC - using CPU software decoding alone on the S912 - MINIX U9.

    Be aware I'm using newer libhybris OpenGLES 2.0/3.2 - which I hope to include in future LE / CE versions - they increase rendering performance as well, especially with GLES 3.2 in Android 6.0 onwards.

    The GPU Overclocked S912 is now equal quickest S9xx platform I use, rivalling the SDR only Overclocked ODROID C2.

    Oh and the S912, Kodi dirtyregions workaround for S912 Subtitle stuttering will hopefully no longer be needed for Linux Kodi Leia with the above PR.

    Details about that HERE

    W.