LibreELEC doesn't support passthrough for Rockchip devices.
Hi, has anyone also problem with Direct Passthrough of DTS, DTS-HD and TrueHD on RockPi 4 ver A in Kodi ??
I get only loud white noise or something...the same I get on Android TV images. I was able to transmit DTS-HD on Odroid C2 but now looking for How to exclude that it's even possible to get DTS-HD working on RockPi ??
Has anyone experience DTS-HD playback issues ????
What might the limitations might be for DTS-HD to work in Rock Pi 4 while it works on AMLogics ????
DTS-HD is working in my AndroidTV images for RockPi 4.
Try setting keep device alive to off and send low audio noise to off.
Can you tell WHY it does not bitstream ?? I am guessing are there hardware or license issues...
Because no patch for it was added yet.
You can use the same patch as for Allwinner but need to modify it a bit to be compatible with Rockchip devices, which I don't know how to do.
The LE developers first want to add 10-bit, H265, VP9 video playback support for mainline LE before working on audio.
So it might still take a few months unless someone can adapt jernejsk's kernel patch for Rockchip devices themselves or do it another way.
Rockchip released an updated 4.19 kernel here
Perhaps users still building LE with the 4.4 kernel can get it booting?
Because this kernel is also used for Android-Q things like HDR, 4K, 10-bit color, H265, VP9 might work out of the box just like in the 4.4 kernel.
There is also a commit for HDMI Bitstream audio, perhaps it can help to get HD audio passthrough working?
Another benefit of the 4.19 kernel is PS4 bluetooth controllers working now.
It might still take a long time until all features work in mainline so this might be a stopover for some developers and work better than the 4.4 kernel for now?
And for the mainline kernel, user jernejsk made a patch based on the Raspberry Pi 4 HBR audio passthrough to get it working on Allwinner devices.
Because Rockchip and Allwinner devices use the same HDMI hardware, someone might get it working on Rockchip devices too or can work with him to test it on Rockchip devices?
Can anyone kindly tell me if the following things are working or not in the recent builds/images:
- x264 10bit
- X265 & 10bit
- Bluetooth, Ethernet & WiFi
- PWM Fan Controls with speed settings
- USB 2 & 3 Ports
- InputStream_Adaptive for YouTube
- Customs skins
Don't think 10-bit H264 work but kwiboo did write patches already for it, might need to wait for the next Linux kernel for it to be merged.
X265 is not working
Bluetooth, ethernet, wifi - It depends on your hardware, but works for supported devices
PWN Fan - No fan settings, only some devices' fan work and it's automatic
USB Ports work depending on device
Youtube using VP9 codec won't work, only H264 codec will work.
Do you know how you could build LibreELEC but with a local package with changes that were zipped
instead of it downloading it from a remote site?
Eg. I want to quickly test with local changes I make to the Linux kernel without first making patches or downloading/reuploading the whole kernel to Github to test a small change.
Later when it has a desired effect, then I can make patches.
try to build your own with this patch:
This Patch is compatible with current dev-4.4 Rockchip Kernel.
look for a suitable northbridge cooler, it is noiseless.
Do you know how to add the 'add 'uboot-set' in io-domain node' for Edge RK3399?
The same patch of nanopi added to rk3399-khadas-edge.dtsi doesn't seem to boot, only if I use an older u-boot.
Here are all the specific Edge Linux 4.4 kernel changes
I'll try to add and check what is different compared to your kernel to make the device more compatible.
RockPi 4 with a heatsink works great so far and stays cool.
Not sure why Khadas decided to use a noisy fan.
The fan is working with LibreELEC with mainline kernel.
I still couldn't get the fan working with the 4.4 kernel even with 8018716dd73adc85c8f5175290066bf6d5b4e70a commit, but maybe it's because I tested with an old u-boot or more kernel changes are missing, not sure.
i have now integrated the Rockchip change for the Rockpi4 device tree.
But do not know exactly whether the problem could be.
Here is the dtb file.
I also saw if I use an old u-boot package >5 months ago then LE also boots correctly again on every device.
You don't perhaps know how fans work on RK3399?
The Khadas Edge also has a fan like the nanopi4(rk3399-nanopi4-common.dtsi) but I can't seem to get it turning on automatically on LE with the 4.4 kernel. With mainline LE, the fan is working.
If I use the NanoPi4 dts file, the fan starts spinning on the Edge but obviously doesn't boot because it's the incorrect dts/dtb used.
Here is a kernel fan patch but I think it's for Android and not Linux(LE) - FAN: enable PWM FAN, add auto mode and factory test support · khadas/[email protected] · GitHub. The fan has 0 1 2 3 speeds, if it can automatically use speed 1, low speed, it would be great.
The device runs quite hot if software decoding 1080p so having the fan work would be helpful with the older 4.4 kernel.
here is a new release:
retroarch is disabled.
Nanao-pc t4 Display Port is disabled in device tree
I tried to also boot on a RockPi 4 RK3399 but couldn't get it to boot, no signal on tv.
I copied the dtb file and edited the one in the extlinux file too.
With the previous images from 17/11/2019, it booted correctly.
Do you know if any big kernel, u-boot changes since then might be what is causing the non booting issue perhaps?
I will just try different micro-sd card brands too.
I don't have a uart cable so it's difficult to troubleshoot.
Do you know how to build Kodi for ARM Linux, eg. for Manjaro Linux for RockPi 4, Edge-V RK3399?
The default Kodi for Manjaro is 64-bit but I want to build a 32-bit one so it can work with more addons and Widevine.
The Kodi wiki only explains it for Linux X86 and not for ARM devices and how to activate OpenGLES, Panfrost etc.
It must share some build steps with LibreELEC.
Is it possible to build some newer test images?
There are now VP9 support, more wifi driver support in mainline kernel and new DRMPrime software decoding not merged yet in Kodi, which would be interesting to test.
Hope the 4K resolution, fractional frame-rate support and 10-bit color will also be possible soon.
Then everything will be supported except H265 and HDR playback.
What does that mean? By "software", do you mean the default media player? (No loss there..)
Suppose I'd like to dual-boot Android TV and (legacy) LibreELEC images. Is running both off of 1 storage device possible/viable? The Radxa wiki provides an example image (ubuntu+android), for an older SBC that had onboard NAND. but I don't see any info how to prepare it, or if the process is applicable to the Rock Pi4, and it's quite old at this point.
For Hi10p, the manufacturers also have to modify the Android framework to broadcast to all video players that Hi10p is available, 99% of manufacturers don't implement this. What it means is that Hi10p won't work in any video player like Kodi, VLC, Nova or MxPlayer.
Luckily I fixed it in RockPi 4, Edge-V and RK3328, RK3229 firmwares I made. Without the changes, videos will play in 8-bit color with green, purple color artifacts and the picture will break up.
At the moment you have to use emmc and micro-sd but Rockchip is working on it so you can install 2 OS's on the same storage in future.
Widevine shows L3 so most apps can work. Widevine L1 is only available on closed-source devices with locked bootloaders.
You can also use Magisk to make your device Google Certified or use LibreELEC for 1080p Netflix.
mo123 Thanks. Totally forgot Android TV was an option for the SBCs as well. Will probably go for the Rock Pi, the Edge is nearly double the price here, and has lower specs.
Thanks for the tip, though I'll take my chances. User reports suggest that it is indeed working, at least on the Rockchip kernel. Just took a look at the current scene, and it seems most have migrated to H265, so that might become a strong requirement after all.
For Hi10p 10-bit Level 5.1 Anime videos, it is working on my AndroidTV firmware for RockPi with Kodi 18.
Actually Hi10p is supported on most Rockchip CPU's like RK3399, RK3328 and RK3229 but almost no manufacturer implements the software changes needed to play such files. LibreELEC images using the older 4.4 kernel also plays this format hardware decoded.
You can run Android from a micro-sd card or removable emmc storage, I'm also trying to make Android/LibreELEC boot from USB & NVME storage on the RockPi 4.
Hi all. Seeing as my shelved A10-based TV box will probably be of little use due to the low specs, I'm wondering if getting a TV box or SBC with a Rockchip SoC (specifically, the RK3399) would make sense now that mainline support is landing, and the recent announcement of new SoCs should be a signal for incoming sales of current/old stock.
- How usable are the boards now/ what's missing (compared to, say, an x86 PC with well-suported hardware components)? (Rockchip's status matrix hasn't beed updated in 8 months... Is anyone tracking the mainline development of Rockchip as well as the sunxi community is tracking theirs?)
- Does any tick all "boxes" listed below? If so, which would you recommend?
My expected use of the box/SBC:
• used as a TV box - controllable using a remote (if not shipped with a decent one, then preferably usable with generic IR (nec encoding), and audio through HDMI
• Playing movies stored on NAS (SMB v2+, Wired Ethernet, preferably gigabit)
- "typical" H264 (up to 1080p BD quality; alternatively 1080p60 from youtube and the like) ~50%
- mpeg4 (xvid,divx) ~10%
- "Hi10P H264" ~35%
- various sw-decodable SD-or-lower content (flv) ~5%
- H265 - Don't see myself caring about, and (knowingly) getting H265 and/or 4K content any time soon. Unknowingly (through services forcing H265) - I'm currently not subscribed to anything, but am considering Nebula and Curiosity Stream; can't see anyone dropping H264 altogether, not even Youtube. About the only forced-H265 source I can possibly see considering is DVB-T2, (probably streamed into the network from another box), where the resolution will most likely never go beyond 1080i. If the chip can sw-decode such H265 stream, possibly while overclocked, that's good enough.
• Anime, and most movies in non-native language -> (rich) subtitles, and lots of 'em. I think this places additional requirements on the quality/capability of the DRM driver, as it isn't just scaling+scanning out a single plane with the video, but also combining the video plane (may not match display resolution) with display-resolution OSD/subtitle plane at all times. Ie. if the system starts stuttering the playing video when showing OSD, it's no good - just playing the video smoothly with nothing else showing isn't good enough (there's probably a workaround, where the subtitles are rendered into the video plane, but that limits their resolution and on-screen position, so.. "No, thanks.")
• Plex client (server should be capable of transcoding to h264 if needed).
• (maybe) hosting Kodi DB for all home Kodi clients - a non-roaming, passively-cooled TV box is IMHO best suited for the task. Weeks-long uptimes and low tolerance for kernel glitches affecting the DB operation (networking, storage) expected. Probably needs 4 GB of RAM?
• (maybe) WiFi AP (assuming the driver supports it) - the other AP at home doesn't quite reach one room, having an extra AP for better coverage would be nice.
• Case (for SBC): sufficient cooling required - mustn't overheat/throttle under sustained load (à la Raspberry Pi). Shouldn't need to disassemble the case to access sd-card, if the SBC has on-board IR the case mustn't block it (duh).
I took a look at a few SBCs:
- Rock Pi 4: I don't understand the point of putting RK3399 in a Raspberry form factor. RK3399 needs a beefy heatsink, and cools on the bottom, so it's not like I can use any Raspberry cases anyway, I think. Lots of USB ports are nice. No mention of infrared. Can buy some of the models locally for an OK price. Not a fan of having connectors on multiple/adjacent sides, with even the minimal setup (power, Ethernet, HDMI) having cables sticking out of 2 of them.
- RockPro64 Can't seem to find a decent case for it. Doesn't come with infrared.
- Rock960: Has a nice metal case, a bit bare-bones but probably sufficient aside from the missing IR.
You can also look at the Khadas Edge-V or NanoPi.
But the RockPi 4B and NanoPi have the best cooling with their cases and heatsinks.
RockPi 4B also has the best Android Pie firmware(and Edge-V but the connectors are a problem since you need to remove the HDMI cable every time to access the micro-sd card slot, it only has 2 USB ports and you need to use a fan for better cooling).
NanoPi, RockPro64 only has Android 8 firmware that is very outdated but it's not a problem if you only want to use LibreELEC or Armbian.
For any device, a cheap $10 airmouse wifi remote works wonders.
With LibreELEC and the old 4.4 kernels all those things should work.
But for mainline only mpeg2, mpeg4, VP8, H264 is currently working with H265, VP9, HDR, 10-bit H264 coming later.
Thanks for the build.
I tried it today and although I was able to see mpeg4 hardware acceleration on some files, not all used it I noticed. I believe I saw msmepg4(SW) for one file, perhaps an older video format. No biggie.
But what was a showstopper for me on this build, was that I was unable to reboot and get back to the interface. I always had to unplug the power to get it working, was greeted with a "no signal" on both tv's I tried after a reboot. Also, when this happened, I couldn't ping the rock64 over the network. Not sure if I was doing something wrong, but I never experienced this with the official 9.2 build.
I don't want to sound unappreciative, I'm just reporting my findings. Thanks again for this.
Will check if I can do something else.
It would help a lot if you can send me test videos that don't work correctly.
If you still use Android, please check Nova Video Player, it has lots of optimisations for Rockchip devices.
You can also click multiple times on the video decode menu to then choose between several video decode methods, one might fix your problem.
Also check Android Kodi if it has the same problem as LE.
Thanks for the reply. It's really any mpeg4 file as far as I can tell, that exhibits this choppy / low frame rate type of problem.
I've somehow reduced the problem by changing the resolution to 720p but that's not an optimal solution.
I'd totally appreciate your image!
You can try the image I built