dpapavas

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: 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?

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

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. I'm using a Rock Pi 4B. See here for the output (which seems to be repeated 6 times for some reason). 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?

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. 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. 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: In contranst in librelec, I get something like: 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.

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: 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?

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. I'm very happy to hear (well read anyway) that, as I was worried I was being a bother. 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 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. This didn't make any difference, as far as I could see. 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: 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.

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

I've been having similar issues and in my case, it seems to be related to the specific mode, so that it might have to do, to some extent, with the HDMI cable used. For me, the default terminal mode is 3840x2160p60, probably because it is the best mode seen as supported by the display, but at this mode the HDMI link can't be established most of the time. My understanding is that disconnecting and reconnecting the cable forces the driver to retry and sometimes it manages to establish the link and it works. Setting the mode manually to 3840x2160p30 results in reliable HDMI operation. You might want to try setting a lower mode, by putting something like the following in "/boot/armbianEnv.txt": If this results in getting a signal during kernel boot-up, which is then lost once lightdm starts, you'll need to also set a lower mode for X. That said, I've also tried a libreelec image, which seemed to work every time (although I didn't boot it up more than a couple of times), so this may well also be related in part to the kernel, or the configuration used in Armbian. Apart from that, I'm also having a hard time getting Armbian and the RK3399 Legacy Multimedia Framework to work for 4K HDR video on a Rock Pi 4B. It seems to work fine for all other modes but a couple of 10-bit HDR HEVC videos I've tried either result in choppy reproduction where a few seconds of video are displayed, after which the image freezes while sound continues, or playback is smooth but with incorrect colors. In each case, the display switches to the correct resolution and refresh rate, but it does not switch to HDR mode. I add a grepped version of dmesg below, showing seemingly relevant messages, including several error messages which might, or might not be normal: [ 0.000000] rockchip_clk_register_frac_branch: could not find dclk_vop0_frac as parent of dclk_vop0, rate changes may not work [ 0.000000] rockchip_clk_register_frac_branch: could not find dclk_vop1_frac as parent of dclk_vop1, rate changes may not work [ 1.472998] iommu: Adding device ff650000.vpu_service to group 0 [ 1.473203] iommu: Adding device ff8f0000.vop to group 2 [ 1.473300] iommu: Adding device ff900000.vop to group 3 [ 2.464585] rk-vcodec ff650000.vpu_service: Looking up vcodec-supply from device tree [ 2.464599] rk-vcodec ff650000.vpu_service: Looking up vcodec-supply property in node /vpu_service@ff650000 failed [ 2.464624] rk-vcodec ff650000.vpu_service: no regulator for vcodec [ 2.465017] rk-vcodec ff650000.vpu_service: probe device [ 2.465333] rk-vcodec ff650000.vpu_service: drm allocator with mmu enabled [ 2.466106] rk-vcodec ff650000.vpu_service: could not find power_model node [ 2.466117] rk-vcodec ff650000.vpu_service: init success [ 2.466503] rk-vcodec ff660000.rkvdec: Looking up vcodec-supply from device tree [ 2.466517] rk-vcodec ff660000.rkvdec: Looking up vcodec-supply property in node /rkvdec@ff660000 failed [ 2.466536] rk-vcodec ff660000.rkvdec: no regulator for vcodec [ 2.467085] rk-vcodec ff660000.rkvdec: probe device [ 2.467321] rk-vcodec ff660000.rkvdec: drm allocator with mmu enabled [ 2.467740] rk-vcodec ff660000.rkvdec: could not find power_model node [ 2.467748] rk-vcodec ff660000.rkvdec: init success [ 2.479429] rockchip-vop ff900000.vop: missing rockchip,grf property [ 2.479705] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff8008d47290) [ 2.479749] rockchip-vop ff8f0000.vop: missing rockchip,grf property [ 2.479939] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff8008d47290) [ 2.480204] i2c i2c-9: of_i2c: modalias failure on /hdmi@ff940000/ports [ 2.480219] dwhdmi-rockchip ff940000.hdmi: registered DesignWare HDMI I2C bus driver [ 2.480325] dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 2.481023] rockchip-drm display-subsystem: bound ff940000.hdmi (ops 0xffffff8008d3bbc0) [ 3.315328] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 3840x2160p30, type: 11 [ 4.140435] vcca1v8_hdmi: 1800 mV [ 4.146203] vcca0v9_hdmi: 900 mV [ 4.829054] of_get_named_gpiod_flags: can't parse 'simple-audio-card,hp-det-gpio' property of node '/hdmi-codec[0]' [ 4.829078] of_get_named_gpiod_flags: can't parse 'simple-audio-card,mic-det-gpio' property of node '/hdmi-codec[0]' [ 4.830099] asoc-simple-card hdmi-codec: i2s-hifi <-> ff8a0000.i2s mapping ok [ 4.880580] rockchip-pm-domain ff310000.power-management:power-controller: Looking up pd_vopl-supply from device tree [ 4.880592] rockchip-pm-domain ff310000.power-management:power-controller: Looking up pd_vopl-supply property in node /power-management@ff310000/power-controller failed [ 4.880729] rockchip-pm-domain ff310000.power-management:power-controller: Looking up pd_vcodec-supply from device tree [ 4.880740] rockchip-pm-domain ff310000.power-management:power-controller: Looking up pd_vcodec-supply property in node /power-management@ff310000/power-controller failed [ 4.881811] #1: HDMI-CODEC [ 35.614277] rockchip-pm-domain ff310000.power-management:power-controller: Looking up pd_vopb-supply from device tree [ 35.614291] rockchip-pm-domain ff310000.power-management:power-controller: Looking up pd_vopb-supply property in node /power-management@ff310000/power-controller failed [ 35.614398] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 1920x1080p60, type: 11 [ 95.708357] rk_vcodec: vpu_service_ioctl:1890: error: unknown vpu service ioctl cmd 40086c01 [ 95.848892] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 3840x2160p24, type: 11 [ 95.879288] dwhdmi-rockchip ff940000.hdmi: Rate 296703000 missing; compute N dynamically [ 105.693585] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 1920x1080p60, type: 11 [ 178.595257] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 3840x2160p24, type: 11 [ 178.626142] dwhdmi-rockchip ff940000.hdmi: Rate 296703000 missing; compute N dynamically [ 178.955692] rk-vcodec ff660000.rkvdec: resetting... [ 178.955762] rk-vcodec ff660000.rkvdec: reset done [ 178.955768] rk-vcodec ff660000.rkvdec: reset done [ 180.476956] rk-vcodec ff660000.rkvdec: resetting... [ 180.477023] rk-vcodec ff660000.rkvdec: reset done [ 180.477029] rk-vcodec ff660000.rkvdec: reset done ... [ 273.326954] rk-vcodec ff660000.rkvdec: resetting... [ 273.327025] rk-vcodec ff660000.rkvdec: reset done [ 273.327031] rk-vcodec ff660000.rkvdec: reset done [ 274.327763] rk-vcodec ff660000.rkvdec: resetting... [ 274.327832] rk-vcodec ff660000.rkvdec: reset done [ 274.327838] rk-vcodec ff660000.rkvdec: reset done [ 275.902475] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 1920x1080p60, type: 11 My terminal video mode is "3840x2160p30", while the interface in kodi-gbm is set to "1920x1080p60". The shown messages are taken after booting up and playing two separated HDR videos, the first playing smoothly in false color, while the second plays back intermittently in correct (albeit SDR) color. You can use the mode update messages as markers to figure out what happens when. Note that on the exact same hardware (including the HDMI cable) a libreelec image seems to work correctly, at least to the extent that it switches the display to HDR mode and shows a correct-looking picture. I've tried comparing the device trees used in libreelec and Armbian for clues as to what might be missing and, although there are some differences, I didn't manage to get anywhere. Any pointers on what to try or where to look next would be welcome.