Jump to content

RK3399 Legacy Multimedia Framework

JMCC

By JMCC
in Rockchip

 Share

Recommended Posts

dpapavas

dpapavas

Posted
Posted
  On 2/5/2021 at 9:20 PM, JMCC said:

Probably some Kernel patches being used in LibreELEC. I am not sure whether they updated to mainline yet, or are still using legacy, check that out too.

Expand  

 

The image I tried, which is still current, as far as I can see, uses 4.4.154, so they don't seem to have switched to mainline yet.  As far as I can see though all components necessary for video playback are SoC-specific.  Since I understand that the Legacy Multimedia Framework does support HDR playback on the RK3399, but, as it turns out, not on the Rock Pi 4B, I'd expect the reason to be something specific to the configuration of that board.  If some specific patch was necessary for the VOP, HDMI, or DRM drivers say, wouldn't that prevent playback on all RK3399-based machines?

 

That's why I was looking at the .dts files specific to the Rock Pi 4B, comparing with other RK3399 boards and with the libreelec versions.  Do you by any chance see any error messages in my kernel logs that aren't there in your case, to use as clues to direct my search?  Or perhaps any messages that seem to be missing?  Compared to the libreelec logs, the main differences are the lines about the various supply properties that failed to be looked up, which are there in my logs but not in libreelec and also output like the following, which is there in libreelec, seemingly after every mode change, but missing for me:

  

[   86.448357] dwhdmi-rockchip ff940000.hdmi: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
[   86.448384] dwhdmi-rockchip ff940000.hdmi:     colorspace: YCbCr 4:2:2
[   86.448401] dwhdmi-rockchip ff940000.hdmi:     scan mode: Underscan
[   86.448418] dwhdmi-rockchip ff940000.hdmi:     colorimetry: Extended
[   86.448433] dwhdmi-rockchip ff940000.hdmi:     picture aspect: No Data
[   86.448448] dwhdmi-rockchip ff940000.hdmi:     active aspect: Same as Picture
[   86.448462] dwhdmi-rockchip ff940000.hdmi:     itc: IT Content
[   86.448476] dwhdmi-rockchip ff940000.hdmi:     extended colorimetry: BT.2020
[   86.448490] dwhdmi-rockchip ff940000.hdmi:     quantization range: Limited
[   86.448505] dwhdmi-rockchip ff940000.hdmi:     nups: Unknown Non-uniform Scaling
[   86.448519] dwhdmi-rockchip ff940000.hdmi:     video code: 0
[   86.448534] dwhdmi-rockchip ff940000.hdmi:     ycc quantization range: Limited
[   86.448548] dwhdmi-rockchip ff940000.hdmi:     hdmi content type: Graphics
[   86.448562] dwhdmi-rockchip ff940000.hdmi:     pixel repeat: 0
[   86.448578] dwhdmi-rockchip ff940000.hdmi:     bar top 0, bottom 0, left 0, right 0
[   86.448608] dwhdmi-rockchip ff940000.hdmi: HDMI infoframe: Vendor, version 1, length 5
[   86.448623] dwhdmi-rockchip ff940000.hdmi:     HDMI VIC: 3
[   86.448649] dwhdmi-rockchip ff940000.hdmi: HDMI infoframe: Dynamic Range and Mastering, version 1, length 26
[   86.448664] dwhdmi-rockchip ff940000.hdmi: length: 26
[   86.448677] dwhdmi-rockchip ff940000.hdmi: eotf: 2
[   86.448692] dwhdmi-rockchip ff940000.hdmi: x[0]: 34000
[   86.448706] dwhdmi-rockchip ff940000.hdmi: y[0]: 16000
[   86.448720] dwhdmi-rockchip ff940000.hdmi: x[1]: 13250
[   86.448734] dwhdmi-rockchip ff940000.hdmi: y[1]: 34500
[   86.448747] dwhdmi-rockchip ff940000.hdmi: x[2]: 7500
[   86.448761] dwhdmi-rockchip ff940000.hdmi: y[2]: 3000
[   86.448774] dwhdmi-rockchip ff940000.hdmi: white point x: 15635
[   86.448788] dwhdmi-rockchip ff940000.hdmi: white point y: 16450
[   86.448802] dwhdmi-rockchip ff940000.hdmi: max_mastering_display_luminance: 4000
[   86.448817] dwhdmi-rockchip ff940000.hdmi: min_mastering_display_luminance: 50
[   86.448830] dwhdmi-rockchip ff940000.hdmi: max_cll: 457
[   86.448844] dwhdmi-rockchip ff940000.hdmi: max_fall: 179

 

Since this mentions HDR mastering specs, it seems to be highly relevant, but I can't figure out why I'm not receiving this infoframes (or if perhaps I'm receiving them, but they aren't printed out).

0
jernej

jernej

Posted
Posted
  On 2/6/2021 at 10:50 PM, dpapavas said:

The image I tried, which is still current, as far as I can see, uses 4.4.154, so they don't seem to have switched to mainline yet

Expand  

LE master branch and thus nightly images are using mainline kernel for a long time. But yes, download page will give you LE 9 based images, which are 4.4 based. LE10 is not that far away.

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/6/2021 at 10:50 PM, dpapavas said:

the Legacy Multimedia Framework does support HDR playback on the RK3399

Expand  

Well, the framework can play HEVC 10-bit HDR content, but I don't know if it can switch the display to HDR, since I don't have such a display to test :(. The user cooperation as testers is necessary for that, I appreciate your getting involved with that.

 

For the time being, can you send me a link to some HDR content that is causing playback trouble? So far, all the materials I tested worked fine, and I tried even 160 Mbps videos.

 

Can you also make some other test? Simply do 

apt install librockchip-mpp1=1.4.0-1

And then try again to play your HDR content.

 

[EDIT]: And please try all three available players: mpv in command line,  Rockchip GST player, and Kodi.

0
TheGuv

TheGuv

Posted
Posted
  On 1/6/2021 at 4:53 PM, TheGuv said:

I'm trying this on my Helios64 RK3399 system but I'm getting severe glitches and missing 'tiles', many long pauses and freezes in the desktop and a bunch of GPU errors and soft resets in the logs

 

Expand  

 

I noticed there has been quite a few updates recently which I have applied, but sadly the Mali errors, glitches and pauses continue for me.  ¯\_(ツ)_/¯

0
verplant23

verplant23

Posted
Posted

Hello 

i modified armbian build  script to get board images with 32bit userland and 64bit kernel. 

most time i´m using the rockpi4b board.  because of the 32bit userland i only get the armhf package (tinkerboard) but they only suppoert t76x mali .

is there a way you can provide a t86x package for the 32bit userland?! or how can i make it myself?

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/8/2021 at 4:30 PM, verplant23 said:

quite short answer 

Expand  

As I said, you can download the deb from the rockchip-linux github. The repo name is rk-rootfs-build, IIRC.

 

  On 2/8/2021 at 4:30 PM, verplant23 said:

some guidance you can give?

Expand  

Download the deb and install it :)

 

  On 2/8/2021 at 4:30 PM, verplant23 said:

no special magic u use ? 

Expand  

The info about the sources for my packages are in the first post.

0
dpapavas

dpapavas

Posted
Posted
  On 2/7/2021 at 9:06 AM, JMCC said:

Well, the framework can play HEVC 10-bit HDR content, but I don't know if it can switch the display to HDR, since I don't have such a display to test :(.

Expand  

 

Ah, I see.  In that case looking into missing patches is indeed the way to go.  The patches for the legacy librelec image I found to be wokring are here

 

https://github.com/LibreELEC/LibreELEC.tv/tree/libreelec-9.2/projects/Rockchip/patches

 

and the libdrm patch seems to be particularly interesting.  I'll see if it's missing from our version and try to apply it.

 

  On 2/7/2021 at 11:06 AM, JMCC said:

The user cooperation as testers is necessary for that, I appreciate your getting involved with that.

Expand  

 

I'm very happy to hear (well read anyway) that, as I was worried I was being a bother.

 

  On 2/7/2021 at 11:06 AM, JMCC said:

For the time being, can you send me a link to some HDR content that is causing playback trouble? So far, all the materials I tested worked fine, and I tried even 160 Mbps videos.

Expand  

 

Ah, this proved trickier that expected.  While looking for easily sharable content that exhibited the same problems, I found that most demo content I tried seemed, in fact, to work "mostly ok".  By mostly ok, I mean that while it did not switch the display to HDR, it did in fact play smoothly and with correct (albeit SDR, so correctly tonemapped) colors.  I tried all HDR trailers from here

 

https://www.demolandia.net/4k-video-test/hdr10.html

 

as well as a couple of HDR trailers from here

 

http://thedigitaltheater.com/dolby-trailers/

 

which were Dolby Vision and wouldn't have played in HDR on my display anyway, I suppose.  All of these played back smoothly in SDR.

 

Then I though perhaps the issue had to do with the aspect ratio, as the problematic content was generally 1600p and perhaps that had something to do with it, so I downloaded an HDR movie trailer from YouTube, which uses VP9.  This didn't play at all and in fact swamped the kernel logs with messages, but let's leave that for later.  I then converted it to HEVC HDR10 with

  

ffmpeg -i vp9.webm -c:a copy -c:v libx265 -tag:v hvc1 -crf 22 -pix_fmt yuv420p10le -x265-params "colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc" hdr10.mkv

 

and it also played "mostly ok".  Now, this video, according to ffprobe, is the same as one of the videos that plays back choppily.  Both are

 

  Quote

Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Expand  

 

so I can only assume that the choppiness, is due to the larger size or something like this.   I therefore think that the the best course of action, would be to concentrate on getting the display to switch to HDR, and see if that also fixes the problematic content.  If it doesn't, we can investigate further from there.

 

  On 2/7/2021 at 11:06 AM, JMCC said:

Can you also make some other test? Simply do 

apt install librockchip-mpp1=1.4.0-1

And then try again to play your HDR content.

Expand  

 

This didn't make any difference, as far as I could see.

 

  On 2/7/2021 at 11:06 AM, JMCC said:

[EDIT]: And please try all three available players: mpv in command line,  Rockchip GST player, and Kodi.

Expand  

 

Playing with "mpv --gpu-context=drm" seems to result in SW decoding for all videos I've tried.  It displays correct frames in SDR, albeit slowly and hogging all the CPU.  These lines of output seem suspicious:

 

  Quote

[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.
[vo/gpu/opengl] Cannot open render node "/dev/dri/renderD128": Permission denied. VAAPI hwdec will be disabled

Expand  

 

Running with sudo makes the last message go away, but doesn't change much.

 

Playing with "gst-play-1.0 --videosink=kmssink" seems to be the same as with kodi-gbm: smooth, HW decoded, SDR.  Excuse the long post, but this is a bit convoluted and I wanted to be as precise as possible.  I'll report back if I manage to find out anything more.

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/8/2021 at 8:16 PM, dpapavas said:

Playing with "mpv --gpu-context=drm" seems to result in SW decoding

Expand  

It shouldn't be like that. Can you post the full mpv output?

 

And also, the output of 

cat /etc/mpv/mpv.conf

 

0
dpapavas

dpapavas

Posted
Posted (edited)
  On 2/8/2021 at 9:05 PM, JMCC said:

It shouldn't be like that. Can you post the full mpv output?

 

And also, the output of 

cat /etc/mpv/mpv.conf

 

Expand  

 

There was no "/etc/mpv/mpv.conf".  As far as I know there never was, unless I somehow deleted it inadvertently.  There was a "/etc/mpv/mpv-dist.conf" though and after "cp /etc/mpv/mpv-dist.conf /etc/mpv/mpv.conf" mpv did in fact run with HW decoding.  Console output follows:

 

  Quote

LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Dec 22 2020 23:27:36
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libGLESv2.so
LIBGL: loaded: libEGL.so
LIBGL: loaded: libgbm.so
LIBGL: loaded: libdrm.so.2
LIBGL: Using GLES 2.0 backend
LIBGL: Error while gathering supported extension (eglInitialize: EGL_NOT_INITIALIZED), default to none
LIBGL: Targeting OpenGL 2.1
LIBGL: WARNING, No Limited or Full NPOT support in hardware, Forcing NPOT have no effect!
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: glX Will try to recycle EGL Surface
LIBGL: Current folder is:/home/pi
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.
[vaapi] libva: va_getDriverName() failed with unknown libva error,driver_name=(null)
mpi: mpp version: 11d98147 author: JMCC Import changes from fork Kwiboo/mpp, branch libreelec-hdr, and version bump
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
mpp: deprecated block control, use timeout control instead
mpp: deprecated block control, use timeout control instead
H265D_PARSER: No start code is found.
Using hardware decoding (rkmpp).
VO: [gpu] 3840x2160 drm_prime
[vo/gpu] Using HW-overlay mode. No GL filtering is performed on the video!
V: 00:00:04 / 00:00:30 (15%) Dropped: 9

Exiting... (Quit)
LIBGL: Shuting down

Expand  

 

Playback was smooth, in terms of framerate, but there were (random, not constant) black lines/bands in the output and the whole image "shook" vertically, almost as if every 50 scanlines say, a band of 4-5 was shifted a random amount downwards each frame (or perhaps scaled vertically for a similar but more symmetric effect).

 

[Edit]: forgot to mention that the libdrm patches seem to be included in the repository you mention as your source, so that takes care of the low-hanging fruit.  The other patches concern the kernel, which is a different version (4.4.154 vs 4.4.213) than that used in Armbian and also seem to address other stuff, besides video, which means that they'll probably require some cherry-picking and/or modification prior to application and I'll also have to set up a kernel building environment.  Before I enter that world of pain, let me ask you:  do you think that efforts would perhaps be better spent trying to get the mainline kernel working, or is that still a long way away?

Edited by dpapavas
0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/9/2021 at 9:16 PM, dpapavas said:

the libdrm patches seem to be included in the repository you mention as your source

Expand  

Yes, those patches are included in my repo. They only affect the headers, so are only meaningful during the compilation process, not on runtime.

 

  On 2/9/2021 at 9:16 PM, dpapavas said:

I'll also have to set up a kernel building environment

Expand  

Well, the Armbian build script already does that for you, doesn't it? ;)

 

  On 2/9/2021 at 9:16 PM, dpapavas said:

do you think that efforts would perhaps be better spent trying to get the mainline kernel working, or is that still a long way away?

Expand  

I'm ot sure what you mean with "getting the mainline kernel working".  If what you mean is keeping up-to date the VPU patches, well, that is fairly well taken care of by the main RK kernel maintainers at Armbian. 

 

In any case, I think your best efforts can be focused on figuring out what are the bits that LibreELEC is using to switch the display to HDR mode. It can be some kodi patch, not necessarily a kernel modification. Or even more simple, some default kodi setting without any modification to the code. I would start there, exploring all the Kodi settings and see if you find something that can be changed to enable HDR.

0
dpapavas

dpapavas

Posted
Posted

 

  12 hours ago, JMCC said:

Well, the Armbian build script already does that for you, doesn't it? ;)

Expand  

 

I never said it didn't, but one still has to read up on how it works, how to get it to compile just the kernel, after applying patches, how to use that kernel and handle unbootable systems etc.;  that sort of thing.  I'm very new to Armbian. :)

 

  12 hours ago, JMCC said:

I'm ot sure what you mean with "getting the mainline kernel working".  If what you mean is keeping up-to date the VPU patches, well, that is fairly well taken care of by the main RK kernel maintainers at Armbian. 

Expand  

 

I meant that, since you're currently working on getting the Media Framework to work based on the mainline kernel and asssuming that this HDR issue is, at least in part, due to something missing from the kernel, whether it might be better to troubleshoot this in the mainline version of the Media Framework.  But read also below.

 

  12 hours ago, JMCC said:

In any case, I think your best efforts can be focused on figuring out what are the bits that LibreELEC is using to switch the display to HDR mode. It can be some kodi patch, not necessarily a kernel modification. Or even more simple, some default kodi setting without any modification to the code. I would start there, exploring all the Kodi settings and see if you find something that can be changed to enable HDR.

Expand  

 

I sort of managed to do the reverse: find a libreelec setting that makes HDR output not work and exhibits the same behavior I get on Armbian.  As far as I can see, librelec for rockchip devices doesn't apply any KODI patches (although there is this).  I'm not sure if that means that the plain/unmodified source is used for KODI, or whether some patches are applied regardless of board, but on librelec, KODI has an extra option that lets you select the "HDMI output format".  This essentially sets the color space to RGB or YCbCr (4:2:2 or 4:4:4 ).  The display only switches to HDR with the (default) YCbCr mode, not with RGB.

 

The Media Framework version of KODI is missing that option.  In fact I haven't found any reference to it, outside of libreelec.  Output seems to default to RGB colorspace, as can be seen with:

 

  Quote

$ sudo cat /sys/kernel/debug/dw-hdmi/status
PHY: enabled            Mode: HDMI
Pixel Clk: 148500000Hz        TMDS Clk: 148500000Hz
Color Format: RGB        Color Depth: 8 bit
Colorimetry: ITU.BT709        EOTF: Off

Expand  

 

In contranst in librelec, I get something like:

 

  Quote

# cat /sys/kernel/debug/dw-hdmi/status
PHY: enabled            Mode: HDMI
Pixel Clk: 594000000Hz        TMDS Clk: 148500000Hz
Color Format: YUV444        Color Depth: 8 bit
Colorimetry: ITU.BT709        EOTF: Off

Expand  

 

I'm not sure of course, that getting KODI to switch to a YUV HDMI output mode will be enough to make the display switch to HDR, but it seems worth trying, especially since it should be easier than semi-blindly applying kernel patches.  That said, I can't seem to find much info on how to do so.  Let me know if you have any insight to share.

1
JMCC

JMCC

Posted
  • Author
Posted
  On 2/10/2021 at 10:00 PM, dpapavas said:

an extra option that lets you select the "HDMI output format"

Expand  

First: Can you send a screenshot of the option?

 

Second: I don't know if you said what board are you using. In any case, can you also post the output of "sudo armbianmonitor -u"

 

Third, I found these two LibreELEC kernel patches in master branch to be related to YCbCr: 

projects/Rockchip/patches/linux/default/linux-0021-drm-from-list.patch
projects/Rockchip/patches/linux/default/linux-1001-drm-rockchip.patch

 

In the 9.2 branch, there is this one: 

projects/Rockchip/patches/linux/rockchip-4.4/linux-0001-rockchip.patch

 

This is just from a "grep -rli ycbcr" on the sources. It will need further investigation.

0
dpapavas

dpapavas

Posted
Posted
  On 2/11/2021 at 5:05 PM, JMCC said:

First: Can you send a screenshot of the option?

Expand  

 

Not sure if I can somehow attach it here (I see references to such functionality, but can't find it.)  Anyway see here.  This option is in the "Video Player" section and affects the color space used for video playback.  There's an identical one in the Display tab of the System settings, which controls the color space used in the GUI (and for games and such).  Read also below for more information.

 

  5 hours ago, JMCC said:

Second: I don't know if you said what board are you using. In any case, can you also post the output of "sudo armbianmonitor -u"

Expand  

 

I'm using a Rock Pi 4B.  See here for the output (which seems to be repeated 6 times for some reason).

 

  5 hours ago, JMCC said:

Third, I found these two LibreELEC kernel patches in master branch to be related to YCbCr: 

projects/Rockchip/patches/linux/default/linux-0021-drm-from-list.patch
projects/Rockchip/patches/linux/default/linux-1001-drm-rockchip.patch

 

In the 9.2 branch, there is this one: 

projects/Rockchip/patches/linux/rockchip-4.4/linux-0001-rockchip.patch

 

This is just from a "grep -rli ycbcr" on the sources. It will need further investigation.

Expand  

 

Thanks for looking into it!  I think the master branch is built against the mainline kernel so patches from it are probably not applicable.  The patches from the 9.2 are applicable and as far as I've seen, most of the changes in the patch you mentioned are missing from the Armbian kernel.  A cursory look though, gave me the impression that they're mostly optimizations rather than fixes.  For instance the change you found forces  YCbCr mode under certain conditions (having to do with the current setting of the TMDS clock) and, while this may be useful, it woudln't allow choosing the color space yourself.  (Note: I have a hunch though that some of the changes in that patch, perhaps those augmenting the HDMI phy table and subsequent clocking-related changes might desirable, as I'm now fairly sure that the libreelec kernel is able to consistently connect at 4K@60, which the Armbian kenrel can't and changes such as these might be responsible for it.)

 

Some further research reveals the following:  The changes implementing that option seem never to have made it into upstream KODI.  As far as I could tell from the build scripts, the rockchip port of libreelec 9.2, is using this fork of KODI, which has the patch introducing the setting, as well as other HDR-related patches, that seem to be of interest.  If I manage to apply these patches onto the KODI sources you've used for your package and get HDR working, would you then be able/willing to introduce them into the package?

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/11/2021 at 10:46 PM, dpapavas said:

If I manage to apply these patches onto the KODI sources you've used for your package and get HDR working, would you then be able/willing to introduce them into the package?

Expand  

Sure. Just follow the instructions at the README.md. Set up an Armbian Buster image (or chroot) with enough free space on your Rockpi, and then compiling is just a copy-paste from the instructions -- well, I probably forgot to mention that you need to install ccache, IIRC. Compilation takes about an hour the first time, and shorter in subsequent runs.

 

If you get the patches to work, just make a PR and I will incorporate it.

0
JMCC

JMCC

Posted
  • Author
Posted

@TheGuv Good news, I made some progress. I just got DP-out to work on the NanoPC T4. Now, I'll have to make a clean patch to incorporate the fix into the legacy kernel, and after that I can start to test and debug those errors you reported.

0
dpapavas

dpapavas

Posted
Posted

Well, I've had partial success.  First, regarding compiling KODI, I've run into a problem where compilation would fail, a bit before the end, complaining about "gbm_surface_create_with_modifiers" not being declared.  Now, as far as I an see, this is neither decalred in "/usr/include/gbm.h", as installed by the bundled "libmali-rk-dev" package, nor is the symbol contained in "/usr/lib/mali/libgbm.so".  The (immediate) reason for this failure is that CMake performs the following test to determine whether to use that call:

 

  Quote

check_c_source_compiles("#include <gbm.h>

                         int main()
                         {
                           gbm_surface_create_with_modifiers(NULL, 0, 0, 0, NULL, 0);
                         }
                         " GBM_HAS_MODIFIERS)

Expand  

 

This does not fail outright; it merely warns that "gbm_surface_create_with_modifiers" is implicitly declared.  (It would have failed the linking stage though, had that been tried.)  I forced this test to fail, in order to disable the offending call and it finished compilation, with a seemingly correct result, but what I don't understand, is how this could have worked for anyone, so I worry I may have done something wrong.  Have you had similar issues?

 

Regarding the result, after incorporating the patches, I get the missing settings (along with other needed functionality) and it sort of works.  The board insists it outputs HDR content in the correct colorspace, judging by the contents of:
 

  Quote

 

sudo cat /sys/kernel/debug/dri/0/summary

sudo cat /sys/kernel/debug/dw-hdmi/status

 

Expand  

 

The display on the other hand does not immediately switch to HDR.  It switches resolution but stays in SDR mode, until sometimes, some time later (triggered by I don't know what) it does switch to HDR.  Then it may again have trouble switching back to SDR when playback stops and it returns to the GUI, although that is more rare.  Apart from that, everything seems to match the libreelec image.  I tried installing the patched KODI version onto a fresh installation and in the fresh installation the content that used to be reproduced in false color before seems to work fine.  (The other, which stutters and hangs, exhibits the same problem in libreelec.   VP9 content also fails to play in both and only results in a flood of kernel error messages.)

 

Well, that's not quite true.  The Armbian image still has trouble connecting at 4K@60, which the libreelec image can consistently do.  I also get various kernel messages which don't look very confidence-inspiring, such as:

 

  Quote

[  130.751002] dwhdmi-rockchip ff940000.hdmi: failed to get edid
[  131.371346] [drm:drm_scdc_set_scrambling] *ERROR* Failed to read tmds config, err=-11
[  131.471188] [drm:drm_scdc_set_high_tmds_clock_ratio] *ERROR* Failed to read tmds config, err=-11
[  131.579310] [drm:drm_scdc_set_high_tmds_clock_ratio] *ERROR* Failed to read tmds config, err=-11

Expand  

 

And I also get exceptions in the VOP/DRI driver from time to time, after which resolution switching doesn't seem to work anymore.

 

For all of the above, I guess that kernel patches are the obvious place to look, so I won't be avoiding that after all.  If you have any advice about kernel debugging/troubleshooting, other than what's mentioned in the developer guide in docs.armbian.com, do tell.

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/13/2021 at 9:17 PM, dpapavas said:

Have you had similar issues?

Expand  

No. I think it could be because of some pre-installed libs in your system. I always compile in a clean buster chroot , and everything goes smoothly, just copying & pasting the commands I put on the README.md.

 

  On 2/13/2021 at 9:17 PM, dpapavas said:

any advice about kernel debugging/troubleshooting

Expand  

Well, nothing special.

  • Put the patches in "userpatches/kernel/rockchip64-legacy".
  • Compile with "./compile.sh CREATE_PATCHES=yes", so it will stop after applying the patches and you can see if they worked or failed.
  • If they fail, look at the log in "output/debug/compilation.log", and see what is the problem.
0
NicoD

NicoD

Posted
Posted

I've just installed the media script on the Station P1. Video playback is 2x speed. Either in Youtube with Chromium, or with MPV and a normal video file.
Everything sounds like the chipmunks.
I also think not everything went correct with the chromium settings. 
screenshotChromeGPU.thumb.png.8d6879f94281a70dd69931cbcea6652f.png
Problems are haunting me on the StationP1. :) I've been trying for a month to make a video about it and never was able to have everything working. When not filming it often worked. But when filming... Quantum mechanics are against me.

1
dpapavas

dpapavas

Posted
Posted

After patching the kernel, my Armbian + Legacy Media Framework image seems to work as well as librelec.  The improvement is not confined to HDR output.  I can now consistently connect at 4Kp60 resolution and many of the error messages (notably including those due to crashes within the VOP driver) are now gone.  Things are still not perfect though.  Some content still plays back with skips every few seconds, but these are played back like this on libreelec, too, so it's not as easy as picking the right patch to fix this. Looking though dmesg, you see repeated messages such as these:

 

  Quote

[ 1781.674271] rk-vcodec ff660000.rkvdec: resetting...
[ 1781.674340] rk-vcodec ff660000.rkvdec: reset done
[ 1781.674346] rk-vcodec ff660000.rkvdec: reset done
[ 1781.906854] rk-vcodec ff660000.rkvdec: resetting...
[ 1781.906925] rk-vcodec ff660000.rkvdec: reset done
[ 1781.906931] rk-vcodec ff660000.rkvdec: reset done
[ 1782.075536] rk-vcodec ff660000.rkvdec: resetting...
[ 1782.075607] rk-vcodec ff660000.rkvdec: reset done
[ 1782.075612] rk-vcodec ff660000.rkvdec: reset done

Expand  

 

Although to get HDR output to work, I'm pretty sure that only a single patch was necessary, I've gone ahead and selectively picked and applied patches on the basis of whether they were related to video and looked useful.  As such, some may not be welcome in a general-purpose kernel image (I can think only of one, which sets the GPU's governor from ondemand to performance) and further discussion may be necessary.  I've been using the patched versions of the kernel and KODI for a couple of days now without any problems, but I'll test them for a couple of days more before submitting PRs.

 

Do I understand correctly that I should open the PR for KODI on the Github repo I downloaded it from?  What about the kernel patches?

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/16/2021 at 8:16 PM, dpapavas said:

I should open the PR for KODI on the Github repo I downloaded it from?

Expand  

Yes, correct.

 

  On 2/16/2021 at 8:16 PM, dpapavas said:

What about the kernel patches?

Expand  

You should move them from the userpatches directory to patch/kernel/rockchip64-legacy, and then make a PR against armbian build repo. You can reference this thread in the PR description.

0
balbes150

balbes150

Posted
Posted
  On 2/16/2021 at 5:24 PM, NicoD said:

I've just installed the media script on the Station P1. Video playback is 2x speed. Either in Youtube with Chromium, or with MPV and a normal video file.
Everything sounds like the chipmunks.

Expand  

Select the correct audio output, either via HDMI or analog output. By default, output via DP\MPI is enabled. I can disable this channel in DTB, so that it does not interfere, but maybe someone will use it.  :)

0
JMCC

JMCC

Posted
  • Author
Posted
  On 2/16/2021 at 5:24 PM, NicoD said:

not everything went correct with the chromium settings

Expand  

Definitely, according to the picture, something went wrong. Can you do the installation again from scratch, and this time copy-paste the installation output? And also "armbianmonitor -u".

1
NicoD

NicoD

Posted
Posted
  On 2/17/2021 at 9:35 AM, JMCC said:

Definitely, according to the picture, something went wrong. Can you do the installation again from scratch, and this time copy-paste the installation output? And also "armbianmonitor -u".

Expand  

I've done the installation again. Again with the same outcome. Videos play 2 x too fast. If I play it in Youtube at 0.50x then the video plays fast enough, but the sound is still chipmunk. 
@balbes150It's not because of the audio output. I disabled the unused ones.
I used the Buster Legacy Desktop from here : https://users.armbian.com/balbes150/firefly_station_p1/Armbian/
Here the install info :
 

  Reveal hidden contents

Looks normal to me. But chromium isn't hw acc.

  Reveal hidden contents


I don't know anymore. I think it worked a few days ago. Any other image I can try?

 

0
NicoD

NicoD

Posted
Posted
  On 2/17/2021 at 3:25 PM, JMCC said:

I suggest building or using a nightly

Expand  

I just tried the image from the download page : https://www.armbian.com/station-p1/
There it works as it should. 
 

  Reveal hidden contents

@balbes150You any idea why this happens? The image on the downloadpage doesn't have on-board wifi working. I'll see if the NVMe works with that dtb file. I use a 5Ghz usb wifi antenna so I don't care that much about on-board wifi. (yes I know, wifi bad :D )

0

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept