Posts by Kwiboo

Quote from kostaman

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.

Quote from polo_joe

http://ix.io/1zsn

http://ix.io/1zsp

kodi log before crash Dropbox - kodi.old.log

It looks like you have a few plugins installed that may cause instability, plugin.video.youtube 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.

Quote from noggin

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.

Quote from noggin

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 1080p@60hz mode.

Quote from noggin

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.

Quote from wrxtasy

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.

Quote from kostaman

FIXED MY ISSUES WITH THE 2 CHANNELS

Perfect smooth Playback.

Thank You so much. I had Almost Given Up.

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

Quote from wrxtasy

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

Quote from wrxtasy

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/LibreELEC.tv · 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.

Quote from Kwiboo

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.

Quote from KOPRajs

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).

Quote from djnice

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 4k@30hz.

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.

Quote from mo123

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.

Quote from mo123

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.

Quote from mo123

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.

Quote from LeoD

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)..

RK3399 in mainline linux is rather good as it is also used in some Chromebooks (OP1 processor = RK3399).

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.

For LE we use a special 4.4 version that I have tuned for video/audio/cec/media, see the different rockchip-4.4 branches at Branches · Kwiboo/linux-rockchip · GitHub, they correspond to the patches seen at rockchip-4.4, the base version used in LE corresponds to the release-4.4 branch in my kernel tree.

Moving forward I am mainly focused on mainline linux development (rk3288 and rk3328 already works rather okay), my next step is to confirm rk3399 devices works before I push initial mainline support to LE.

As mo123 mentions gpu driver exists for T860, you can find it at GitHub - rockchip-linux/libmali: The Mali GPU library used in Rockchip Platform, for LE we only use the gbm version.

When it comes to tv boxes I would also highly recommend any of the SBC type of devices, box devices will not see much support when we move to mainline unless vendor or other community members upstream device tree to mainline u-boot/linux.

Quote from Wassco

what could be the reason why it locks up/loses signal after an hour+ of use but not initially?

Unsure what could be the reason, I mostly test samples of few seconds to 10 minutes, debug log when the issue happens would help, but sounds very hard/time consuming to reproduce.

Quote from LeoD

Rock64/Netflix : smoothness seems improved, indeed; brightness is OK. Thanks, man! Had one (probably unrelated) crash, but the crashlog is too big to upload.

Thanks for testing, this has improvement potential so I should probably setup netflix/amazon addon so I can test myself.

Quote from mo123

Is there a way to get logs for troubleshooting for this remote, what steps to do, or something you can add to CEC code to help with Sony Bravia remotes?

The latest LE master should have some improvements to libcec code (was included in Rockchip: update patches and packages by Kwiboo · Pull Request #3239 · LibreELEC/LibreELEC.tv · GitHub), that was the result after some testing using mainline and an older Sony KD-65X8509C TV.

Enable debug logging and libcec component logging to get CEC details in kodi log, you can also use echo 2 > /sys/module/cec/parameters/debug to enabled detailed kernel log.

The issue fixed in libcec affects the initial identification of what TV model is used and short periods of non-working cec (mainly affected mainline).

On Sony and LG I have noticed that you may have to explicitly select Kodi in the input selection menu to get CEC to work.

Quote from mo123

I hope your new direct-to-plane software decoding can help so video playback in such a case can be smoother.

I have a rather hacky first version ready now (HACK: RendererDRMPRIME: render sw decoded frames · Kwiboo/xbmc@14f686f · GitHub), I have only tested this on rk3399 and sw decoded video seems to display correctly.

I have pushed two new rk3328 images to Index of /test/, please test and see if anything improves since last build.

Quote from mo123

Can you include one of the patches mentioned here?

I will do some tests using this and I am also working on an alternative where software decoded video can be rendered using direct-to-plane instead of the GLES pipeline, it will not be zero-copy rendering but rendering would bypass gpu, downside is no deinterlace support.

Quote from mo123

I get the following compile error

This is due to Kodi using something that is defined in GLES3/gl3.h without including this header. The libmali package is using the latest EGL-Registry and OpenGL-Registry include files, if it works using mesa or Android without GLES3/gl3.h it is probably because they use non-standard include files.

Edit: It looks like gl3.h is included from xbmc/system_gl.h at master · xbmc/xbmc · GitHub, I am guessing this compile issue only happens on non GLES3 targets. GLES3 headers should be installed for RK3288/RK3399 targets (they support GLES 3.1/3.2).

Edit2: I pushed some commits to Commits · Kwiboo/xbmc · GitHub including a fixup that should fix compile issues on RK3328 (it now checks if GLES3 headers exists). Test images including these changes can be found on Index of /test/ (untested).

Quote from rav101

Just wondering if it has come through yet?

I received my Rock Pi 4 the other day and already have it running, see Index of /test/ for a test image that seems to work. Mainly need to test kernel + wifi/bt changes on other devices before I can push a PR.

It does seem to run a little bit hot, 60C with heatsink and bottom acrylic case installed (cpu side faced up), 70C with cpu side faced down, what is interesting is that it was running at 56C without any heatsink or acrylic case (haning in the air).

I am not too concerned about the heat on rk3288/rk3399 devices as it seems stable when running hot. When I accidently left my RK3288 Tinker Board constant rendering the Kodi settings menu at 60fps (an old bug in Kodi Krypton) for a week it reached 80C but was still stable and went down to 50-60C a few minutes after I exited the Kodi settings menu.

Quote from rav101

Any plans to add EMMC support, I don't think this is officially supported so I suppose not?

eMMC should be working and it should be possible to install the image directly to eMMC using the eMMC/SD adapter (my package included one).

Installing to eMMC from inside Kodi is not supported as there is not yet consensus on how this should work moving to LE10, mainline and across the different platforms.

Using different zoom/aspect ratio options in Kodi is only something I have done minimal testing with and I know there are limitations that are not fully enforced by software that can cause issues with hw.

Interesting to know if anything improves with direct-to-plane and zoom/aspectratio/mode setting using default/normal options, and/or a clean install/user data using default options.

From what I can read in log files it looks like the same file (Star trek the Next Generation S01E07.mkv) is playing when crash occurs, is crashes also happening with other files?

It also looks like you are using EGL rendering when playing the video file, please change to use Direct-To-Plane rendering for best support and performance. Direct-To-Plane rendering should be the default.

My Transformer has been running pretty much non-stop without crashes since it was released, but then I only play occasional sample video when testing new code.

A sample device should have been shipped last week and I expect it to arrive any day now, will be sure to test and include for next rockchip update.

Very nice to see that mainline device tree has been merged into mmind's for-next tree at kernel/git/mmind/linux-rockchip.git - Linux Rockchip kernel tree