Posts by Kwiboo

    The LG Chess is one of those [email protected] clips that rk3328 will have problems with and will usually play at 58-59 fps and ends out of sync.

    On ROC-RK3328-CC the slower memory bandwidth (compared to Rock64) may play back LG Chess with even less fps then that, a [email protected] sample showed similar a/v sync issue when I tested.

    Please share a sample of the video that stops after 8 seconds.

    Kwiboo I just tested the LE version you suggested on ROC-RK3328-CC.

    First of all this board runs extremely hot. I have the heatsink for the SoC mounted, and it still idles around 60C.
    It does play H264 very well now, HEVC 10-bit is still dead in the water, but the short HEVC 8-bit clip I tried played well. The GUI looks like it's not hardware accelerated, a lot of jaggies, not smooth, etc. I couldn't really test audio passthrough, the list of available passthrough formats was empty (it's connected to a PC monitor which only supports PCM, so perhaps that is working as intended).
    So yeah, there's progress since the last time I tried it.

    I agree the RK3328 is running very hot as the default setting is to run CPU and GPU with performance governor (CPU at 1.3GHz and GPU at 500 MHz). ROC-RK3328-CC device tree has trip points at 80/95/100C. My device starts at 61C idle without any heatsink.

    Please share any 10-bit HEVC clip that is having issues starting, all my 10-bit HEVC starts on my ROC-RK3328-CC-V1.0-A 2GB device using official RPi power supply, only the most demanding 4k 50/60 fps 10-bit HEVC should cause framerate issues.

    I suggest you test with a 4k 10-bit capable TV instead of a monitor, also do not enable debug gui overlay as that will affect video playback, use default settings.

    50/60fps 10-bit 4K HEVC will have more problems on ROC-RK3328-CC compared to Rock64 thanks to the DDR4 memory used on ROC-RK3328-CC vs LPDDR3 memory used on Rock64.

    GUI should be hw accelerated but the Mali 450 MP2 gpu will not be as fast as an S905 Mali 450 MP3 gpu running at higher frequency.

    PT-audio is not fully supported in current builds, only up to 192khz 24-bit 8 channel LPCM is supported. And as you have noticed EDID/ELD is used to determine audio capabilities.

    Do you know if Ezequiel's work will be published and added to a review of libreelec for rockchip? Or is it necessary to patch what it says manually?

    I tested the initial MPEG-2 decoder using libreelec and v1 patchset is included in my mainline test build. I will update to v2 patchset and 5.0 final for next mainline test images.

    Out of curiosity are you talking about the normal Libreelec github sources or is this something from your own github sources? i have built bables rockpro64 build and am interested in looking at others as well...

    The Alpha 014 image is build from the libreelec-9.0 branch at official LE repo.

    My mainline testing is built from GitHub - Kwiboo/ Just enough OS for KODI (final LE 9.0.0 + rockchip-5.x patches) using following commans:

    1. PROJECT=Rockchip DEVICE=RK3288 ARCH=arm UBOOT_SYSTEM=tinkerboard LINUX=rockchip-5.x make image
    2. PROJECT=Rockchip DEVICE=RK3328 ARCH=arm UBOOT_SYSTEM=rock64 LINUX=rockchip-5.x make image

    The two test images at Index of /test/ is built from the rockchip-5.x commit at my LE repo.

    Kernel patches is based on Commits · Kwiboo/linux-rockchip · GitHub and rockchip-5.x-rebase (locally I have rebased those branches on latest 5.0-rc8 and will rebase and push an update with final 5.0 any day now.

    I do all my building insed docker containers to minimize influense from build host, see README at at master · LibreELEC/ · GitHub for a short example on how I build my images.

    For Rock64 any eMMC should be faster then any SD-card as there only is support for high-speed transfer speed (20-23MiB/s).

    There is no 1.8v signal voltage support that is required for faster UHS sd-card speeds.

    I have a SBC based on another Rockchip, and the last time I tested it, it was pretty useless as a media player in all regards.

    H264 video stuttered, HEVC video would lock up after 10 seconds of playback, no HDR support, etc.

    Please try the latest LibreELEC 9.0.1 / Rockchip Alpha 014 build (on a rockchip sbc with a "supported"/tested devicetree), it should work very good.

    Do not stare blind at the alpha name, it is mostly there because there is features missing (HD-audio and full HDR infoframe metadata).

    So LE has stopped supporting Amlogic and Rockchip users?

    Rockchip is very much working and "supported" even if it is still flagged as alpha, the 9.0.0 / Alpha 013 and 9.0.1 / Alpha 014 images should work very well.

    My focus for Rockchip at the moment is on mainline linux, hd-audio and adding more codecs to the rk v4l2 request api driver and ffmpeg hwaccel.

    I still don't understand why you fixate on the Kernel version, how old it is, or what GPU drivers it has. As long as it works well and fast, and it does work well, and it's also very fast, I personally don't care what version of kernel it is running on.

    LE pushes towards Mainline kernel support, I can understand why, LE has to cover multiple different platforms, so it makes sense for you.

    Even with the 4.9 aml kernel the drm/kms stack is unfortunately not used for video rendering. Compared to mainline (or RK 4.4) this mean that the new video rendering path in kodi (the direct-to-plane drmprime renderer) cannot be used. When amlcodec (and mmal) rendering is removed from kodi the kernel subsystems used for the display stack gets important.

    The drm prime decoder + direct-to-plane renderer was first designed and tested for RK 4.4 kernel but thanks to using "modern" kernel subsystems it is working with any drm/kms platform that can render video on a dedicated video layer / plane and has been proven to work very good on mainline aml, rk, rpi, imx and other platforms.

    I have now been reading through LE forums including this one (wishing that I'd done that before ;) ) discovering all the issues with developing a stable image for this device and its SOC (RK3328), and I feel that I somewhat understand (it may go over my head ;) ) the problems with the Rockchip 4.4 kernel and how things are reliant on the development of the Lima project.

    From a developer perspective the Rockchip Alpha 013 image is as good as it is going to get with Rockchip 4.4 linux, it should be rather stable and supports hw decoding of most formats. Focus going forward is to make Rockchip run on mainline linux.

    I already have Tinker Board and Rock64 working okay on mainline but it only supports mpeg-2 hw decoding and up to 1080p resolution so far, mainline testimages can be found at Index of /test/, upstreaming of linux patches is ongoing.

    I get a Screenshot of a Black Image in .png format.

    Screenshots of video using Direct-To-Plane rendering is not implemented and will give you a black picture, screenshots using EGL renderer should work but Direct-To-Plane rendering is preferred for performance reasons.

    kodi log before crash Dropbox - kodi.old.log

    It looks like you have a few plugins installed that may cause instability, seems to complain about missing settings, there was some ALSA log entries I have never seen before.

    I suggest you try with a single/minimal addon on a clean install using HDMI/SPDIF audio. One or more of the addons is probably causing exessive resource usage.

    How the absence of metadata is handled by displays will presumably vary. The Rockchip is definitely in a worse case - as you have no idea at all of the source video range (or even the primary colour volume it was mastered within inside the BT.2020 colour space), nor do you know the min/max levels of the mastering display (below and above which you wouldn't expect valid content?)

    The CTA-861-G standard states: "The data in Data Bytes 3 – 26 are arranged into groups, as indicated in Table 45 Static Metadata Descriptor Type 1 above. When all of the Data Bytes in a group are set to zero, then the Sink shall interpret the data for that group as unknown." and "For MaxCLL and MaxFALL, this may occur when information about the content light level has not been, or cannot be, provided - for example, content that is rendered or broadcast in real-time, or pre-processed content that was delivered without information about the content light level.", this mean that TVs should support missing metadata, and I expect the result is that no optimization of light levels can be done.

    Interesting the DD and DTS bitstreams are being reported as PCM 2.0 not Bitstream via my HD Fury Vertex, so I wonder if not all flags are being set correctly.

    This is correct, only LPCM is "supported" correctly in the kernel code at the moment, when Kodi sends a NL-PCM bitstream it is flagged as LPCM 2.0 16bit 48khz stream. On my TV/AVR this usually gets treated as NL-PCM when using 24p mode and static noise in [email protected] mode.

    HDR stuff - ST.2084 PQ stuff flags the EOTF but doesn't flag Max/Average light level metadata (I think this was correctly passed in a previous release?)

    This should never have worked in earlier releases, the code have always only set the eotf parsed from the video metadata (there is currently no easy way to get other related hdr metadata from mpp library back to kodi). Code that sets HDR metadata.

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

    It should be enabled in the dts for all targets "supported" by LE.


    Perfect smooth Playback. :):):):):):):):):):):):):):):):):):)

    Thank You so much. I had Almost Given Up. :thumbup:

    I do not think I can take credit for this, for the last few released pushed main changes have been to update kodi, bootloader blobs and updates to the mpp library. I am guessing RK fixed your decoding issues in one of the mpp library updates.

    My latest test build should mainly contain experimental code for using direct to plane rendering for software decoded videos, but there is issues and will probably crash at end of playback, I recommend you test the just released LE 9.0 / RK Alpha 13 image, see Rockchip – LibreELEC

    what is the status of HD audio passthrough with RK3399 ?

    Currently only 8 channel LPCM works as it should on RK platform, basic NL-PCM may work by accident because TV/AVR treats the LPCM stream as NL-PCM.

    As chewitt mention video issues is much more fun to work on. Recent audio developement on Allwinner platform have sparked new ideas on how to finishing NL-PCM/HBR audio work.

    Recent work that was more interesting then NL-PCM/HBR audio:

    - FFmpeg v4l2request hwaccel

    - MPEG-2 v4l2 request api decoder

    Also status of 4K HDR with Rockchip ?

    HDR has been working on RK since Rockchip: add kodi HDR patches by Kwiboo · Pull Request #2927 · LibreELEC/ · GitHub but is limited to only set EOTF in the HDMI infoframe metadata.

    More metadata will be set in future once a HEVC v4l2 decoder is ready.

    When it comes to the 4.4 kernel rockchip have a pretty recent Linaro Stable Kernel (Android) merged, unfortunately when I asked if there was a chance to see a new version pushed to github it ended with "not a chance", I am speculating that the internal rockchip linux tree contains code for unreleased products blocking pushing a new version public.

    Rockchip pushed an updated 4.4 kernel and u-boot to github today, it has the latest linux-linaro-lsk-v4.4-android merged bringing it up to 4.4.167 and restores the tree back to a state where some rk3399pro/rk1808 commits no longer is dropped.

    Could someone from the devs confirm what is the current status of the deinterlacing support on RK3399?

    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.

    It is still unclear on how deinterlace will function in the drm prime rendering pipeline, hopefully the IEP can be exposed as a V4L2 device and a ffmpeg filter can be created that make use of such device or similar block on other platforms. Main focus on the drm prime rendering pipeline is to be cross platform compatible.

    Please give me a link to dts and I can take a quick look and possible include the dts in my linux tree (I usually compare it to rockpro64 dts and reorder nodes in same order to make compare across the different devices easier).

    And the RK pass-thru all of the HDR metadata especially the MaxFALL, MaxCLL too?

    RK3328 and RK3399 share same DW-HDMI TX core and can both send Dynamic Range and Mastering InfoFrame with EOTF/MaxFALL/MaxCLL metadata.

    RK3328 have HDR2SDR / SDR2HDR support, this is not supported by RK3399 where the T860 GPU could potentially be used for tone mapping for up to [email protected]

    RK3399 does however have more advanced colorspace conversions support with custom coefficients, where RK3328 have predefined color conversions methods.

    For LE we only set EOTF metadata because we currently do not have a simple way to extract MaxFALL/MaxCLL using rkmpp-library, will be something that gets improved once mainline v4l2 decoder is ready.

    I also see if you change the 'Limit GUI Size' to 720p and use Netflix, Amazon then there are a lot of crashes and LE restarts, leaving it on 1080p seems to stop the crashes.

    Very interesting, I will do some tests and see if I can solve such issues, just got Amazon installed to be able to fully test something other then local sample files.

    720p GUI with software decoding might decrease CPU load further and work better?

    I am not sure GUI resolution should affect that much, when there is no subtitle or debug overlay the gui should be completly disabled saving on gpu and memory bandwidth.

    When I test on RK3399 it seems to handle decoding of h264 1080p bluray rips using cpu, I should really switch to my Rock64 Transformer and continue testing.

    Is the CPU using an optimal governor eg. ondemand, interactive in the kernel that can help with spikes in higher usage to smooth it out when more items or motion appear on the screen, not sure if this can also help if changed for software video decoding?

    On RK3328 default is to run both CPU and GPU using performance govenor, i.e. run at full speed. On RK3288/RK3399 gpu use performance and cpu use ondemand.

    When watching 1920x960 content there is a thin flickering line on top of the picture.

    Crashes are more frequent than expected at first, usually when starting/stopping playback.

    Thanks for testing and logs, I am reworking the code to only work with netflix/amazon (addon video codec) in a second iteration, hopefully it will be more stable and won't depend on a "wrapper" video buffer (looks like the SysMem buffer got removed when buffer was still in use in your crashlog)..