JMCC

Can you share some details on the steps you followed, and which player you are using? It can be useful for a complete implementation into Armbian. Thanks, and Merry Christmas.

I am not using Netflix anymore, so I cannot tell for sure. I'll probably remove that feature from future versions of the script. However, here are some suggestions that may work: Look for a compatible version of the widevine-cdm library for Chromium Use the Kodi Netflix add-on Use Exagear Desktop to run Chrome Browser for x86 Please let us know about your findings.

There is a post confirming that LibreElec patches allow playing of 10-bit videos in other RK SoC's. I want to experiment with it, and probably will be included in some future version of the script.

You can copy-paste this code into a root console, and it will give you a Qt5 player using the RK GStreamer plugin: apt-get -y install qtgstreamer-plugins-qt5 gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-plugins-good gstreamer1.0-plugins-base libqt5opengl5 libqt5qml5 libqt5quick5 libqt5widgets5 libqt5gui5 libqt5core5a qml-module-qtquick2 libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediaquick-p5 qtmultimedia5-examples qtmultimedia5-doc-html echo '#!/usr/bin/env xdg-open [Desktop Entry] Type=Application Name=Rockchip Gst Player GenericName=Media Player Comment=A gstreamer base player Exec=env QT_GSTREAMER_WIDGET_VIDEOSINK=rkximagesink /usr/lib/aarch64-linux-gnu/qt5/examples/multimediawidgets/player/player --geometry 960x640+0+0 Icon=/usr/share/icons/gnome/48x48/categories/applications-multimedia.png Terminal=false Categories=Qt;AudioVideo;Player;Video; MimeType=application/ogg;application/x-ogg;application/mxf;application/sdp;application/smil;application/x-smil;application/streamingmedia;application/x-streamingmedia;application/vnd.rn-realmedia;application/vnd.rn-realmedia-vbr;audio/aac;audio/x-aac;audio/vnd.dolby.heaac.1;audio/vnd.dolby.heaac.2;audio/aiff;audio/x-aiff;audio/m4a;audio/x-m4a;application/x-extension-m4a;audio/mp1;audio/x-mp1;audio/mp2;audio/x-mp2;audio/mp3;audio/x-mp3;audio/mpeg;audio/mpeg2;audio/mpeg3;audio/mpegurl;audio/x-mpegurl;audio/mpg;audio/x-mpg;audio/rn-mpeg;audio/musepack;audio/x-musepack;audio/ogg;audio/scpls;audio/x-scpls;audio/vnd.rn-realaudio;audio/wav;audio/x-pn-wav;audio/x-pn-windows-pcm;audio/x-realaudio;audio/x-pn-realaudio;audio/x-ms-wma;audio/x-pls;audio/x-wav;video/mpeg;video/x-mpeg2;video/x-mpeg3;video/mp4v-es;video/x-m4v;video/mp4;application/x-extension-mp4;video/divx;video/vnd.divx;video/msvideo;video/x-msvideo;video/ogg;video/quicktime;video/vnd.rn-realvideo;video/x-ms-afs;video/x-ms-asf;audio/x-ms-asf;application/vnd.ms-asf;video/x-ms-wmv;video/x-ms-wmx;video/x-ms-wvxvideo;video/x-avi;video/avi;video/x-flic;video/fli;video/x-flc;video/flv;video/x-flv;video/x-theora;video/x-theora+ogg;video/x-matroska;video/mkv;audio/x-matroska;application/x-matroska;video/webm;audio/webm;audio/vorbis;audio/x-vorbis;audio/x-vorbis+ogg;video/x-ogm;video/x-ogm+ogg;application/x-ogm;application/x-ogm-audio;application/x-ogm-video;application/x-shorten;audio/x-shorten;audio/x-ape;audio/x-wavpack;audio/x-tta;audio/AMR;audio/ac3;audio/eac3;audio/amr-wb;video/mp2t;audio/flac;audio/mp4;application/x-mpegurl;video/vnd.mpegurl;application/vnd.apple.mpegurl;audio/x-pn-au;video/3gp;video/3gpp;video/3gpp2;audio/3gpp;audio/3gpp2;video/dv;audio/dv;audio/opus;audio/vnd.dts;audio/vnd.dts.hd;audio/x-adpcm;application/x-cue;audio/m3u; ' > /usr/share/applications/demo-player.desktop

No, it is not obvious. I knew it because I had to deal with the LibreElec source tree when I was preparing the RK-enabled Kodi for the Tinker Board . RK used to have their own version of libdrm, but for some reason they discontinued the project. ASUS TinkerOS still included the library as of version 2.0.5, not sure if it is present in last release.

Libreelec has some patches to libdrm for 10-bit formats: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/libdrm

I stand corrected, it does support 10-bit HEVC with the Main profile. I also know that LibreELEC uses some patches to libdrm to support 10 bit display, which we don't do ATM.

TB dows not support 10-bit HW decoding, so all the work needs to be done via software. It's probably able to decode a 1080p file, but not 4K. It looks like newer versions of Chromium are not compatible with the widevine library that the script installs. I haven't found a more recent library yet. In the meantime, if you don't mind using an outdated version of Chromium, you can try to downgrade it: sudo aptitude install chromium-browser=65.0.3325.181-0ubuntu1 sudo apt-mark hold chromium-browser Let us know if that works You can autostart it as the root user, just by placing this line in /etc/rc.local: kodi-gbm-wrapper Or you can disable the desktop altogether through "armbian-config", and then run just "kodi" in your .bashrc file, if you want to autostart it as your regular user.

Seems like the community is seriously demanding 64 bit versions of the RK media script (3399 and 3328). Give me some days, I'll work on it.

No, I need to make another one for RK3399. I made one already, but for a 32 bit Armbian Xenial, when we were in the first stages of development for that SoC. I can search for the link if you are interested. The 64bit Bionic can be ready in a few weeks

I understand you already tried to add these lines to /etc/systemd/resolved.conf: DNS=8.8.8.8 2001:4860:4860::8888 FallbackDNS=8.8.4.4 2001:4860:4860::8844 And also try adding this one to /etc/rc.local: grep -q 'nameserver 8.8.8.8' /etc/resolv.conf || echo 'nameserver 8.8.8.8' >> /etc/resolv.conf And reboot Or even a more radical solution, in case the above doesn't work, putting in /etc/rc.local: echo 'nameserver 8.8.8.8' > /etc/resolv.conf and reboot.

I'm not aware of any Tinker Board emulator out there, so I can only test on "real hardware". I'm not aware either that Tony is having those issues when running my script with the official Armbian default image. Make sure everything is in place in your setup (double check you're using default, not mainline).

As a matter of fact, I only guarantee my script to work against the official Ubuntu Bionic Armbian desktop default image. That is the one I use as build environment, and as testing system.

Do you mean it should say "Armbian Bionic" instead of "Ubuntu Bionic Armbian"?

Those problems are not present in the released image, nor if you build with the kernel I froze. I think switching to that kernel would have two important advantages: Less headache. Everything in the board would work unless we break it. A solid base to experiment and introduce new features (e.g. the LibreELEC multimedia patches referenced by @Kwiboo, camera ISP driver, new kernel configs, etc.). Right now, if you try something new and the board fails, you are in doubt whether it was because of the change you made or because it broke upstream.

If that application you mention requires an accelerated OpenGLES canvas to display the videos, then the answer is yes. You can try, it won't harm.

Well, going back to the kernel: Do we want to use the frozen version I referenced above? If so, I'll start working on adding the remaining patches (though, as I said, I'll need a little help with that). @Igor @TonyMac32 what do you think?

When did HDMI break? It is working in the stable released images

Probably if you use x11vnc instead of tightvncserver. Maybe this tutorial still works in Xenial.

Well, that is in a sense what is done now with "board families". All the boards in the same family share the kernel and most filesystem tweaks, and differ only in the device tree and some adjustments for specific hardware. But it is only possible when all the boards share the same SoC or a very close one. With completely different SoC's, that is not possible, each one needs a different kernel. Notice that all different boxes supported by balbes150's images have some Amlogic Meson SoC, and that is why they can use the same image with minor tweaks.

I completely agree: the core team is overwhelmed with work, if someone wants to see new boards supported, community contributions is the way to go. However, I've always been curious why @balbes150 is maintaining a separate fork, with different boot method etc., instead of making Vim work on regular Armbian. Is it in order to be able to support more TV boxes with a single image?

Okay, so I created a working fork of RK BSP kernel. It reproduces the status at the end of August, when we created the Default images that are currently available for download. I also modified the buildscript patchset to resemble what it was back then. I have tested Wifi, network, Bluetooth, GPU, VPU, all working. There are two things missing: Security patches after 4.4.132 All the features added after August 28 2018 (like some crypto modules, etc.) I'd appreciate if you guys could lend me a hand with those two things, it can be very easy for you because you already added those patches to 'master' before, but I'm a bit lost about where to start. This is our forked RK kernel: https://github.com/armbian/linux/tree/rockchip-4.4 And this is the working branch of the build script: https://github.com/armbian/build/tree/rockchip-4.4

Finally, the version 2.0 for Armbian Bionic is out! Check the OP for documentation and download link. CHANGELOG: Updated all necessary packages to work with Ubuntu Bionic Updated versions of MPV and Kodi Added the GL4ES wrapper, to provide OpenGL support (thanks @jock for the tips). In order to use it, you must launch your app from command line using the wrapper "glrun" RELEASE NOTES: I'm not sure whether the Widevine library is still working with newer versions of Chrome, and I don't have access to Netflix anymore to test it. Some feedback on this point is welcome. I'm still including the old cgminer as OpenCL example. If you want to try more recent algorithms and experiment with GPU mining just for fun, I recommend you to have a look to this sgminer for from the ODROID community (it works also with RK3288): https://github.com/hominoids/sgminer-arm As I said, just for learning, curiosity or fun. Trying to get money with a Tinkerboard is a waste of time. Plus, I think the whole crypto-mining idea is absurd, basing the value of a currency on wasting as much electricity as possible Remember you need a default (4.4.y) kernel for HW video acceleration to work. It is not yet implemented in mainline (4.14.y).

I have noticed that all SBC manufacturers just clone the repo at certain point, and then fork it from there, without merging successive upstream changes. It looks to me that's how Rockchip expects their kernel source to be used: They make it work for a certain SoC/board, and after the manufacturers fork it, they forget about that SoC/board and start working in making the necessary changes for the next one, regardless of whether it breaks the previous ones. I'll try to make an experiment of making a fork, though usually all my attempts to do kernel development end up with little success

@Sergei Steshenko IMO, anyone with enough Debian knowledge to use Synaptic, has also enough knowledge to type 'sudo apt install synaptic' after installing Armbian. I think the issue is not whether install it by default or not, but whether it works or not. If you got a fix for it, as @chwe said, please make a PR, it will be very welcome.