RK3328 Media Script (Rock64, Renegade)

Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

Thanks Jeff!


I'm going to experiment with encoding settings and see if I can get smooth playback to work but right now gst-play etc aren't working - I'm getting some error about ion allocator not being found and something about not being able to prepare a gst_openal_sink device. This might've happened because I installed totem but reinstalling the media scripts base and gstreamer stuff hasn't fixed it so looks like I'll have to reinstall armbian.


Have you been able to get videos playing in proper full screen mode with gstreamer or do you still have the window title bar showing and/or desktop panel showing?



Link to post
Share on other sites

I was able to get full screen video by:

1) playing a video of the same size, or larger than my monitor (the 4k image autoscales nicely to my 1080 monitor, without any work on my part)

2) hiding the top panel   .  In LXDE, right-click on the panel, go to Panel- Panel Preferences.  On the Display tab,  change the "Automatically hide the panel" to Intelligently or Always.

3) hiding the title of the playback window. title   In LXDE, under Applications - Settings - Window Manager Tweaks.  On the Accessibility tab, enable "Hide title of windows when maximized"


It will be different on different desktops.  I had to google for a bit to find these hidden settings for LXDE, which I am only using to try to be consistent with the media script.


Note that I am trying to create a standalone video player, so I'm willing to modify my desktop settings for my final application.

I turn all of this back off when I am programming.

I have no idea how one would do this on an application by application basis. 

Link to post
Share on other sites

Totem and Kaffeine, maybe there are others, are both gstreamer-backed media players that should allow for fullscreen playback using the rockchip gstreamer plugin without resorting to the workarounds you mentioned but they may need to be built against the rockchip libraries / packaged especially instead of installing the versions in the regular Ubuntu arm64 repo.


Thanks for sharing your workarounds though!

Link to post
Share on other sites

I agree that there must be some way to override the desktop manager, since other programs do that. 

But, this is way beyond my skillset.

I saw some postings about using GTK to manage a Gstreamer application inside a GTK window. But it was more work than I wanted to tackle, and I found my workaround.

Link to post
Share on other sites
17 hours ago, danboid said:

You recommend fullscreen playback for videos but it seems that both gst-launch-1.0 and gst-play-1.0 don't support proper fullscreen playback so we need to get something like totem working. I just tried running totem with the armsoc driver and this scripts gstreamer packages and when I try to start totem I get the error:


libGL error: unable to load driver: rockchip_dri.so


I have tried running totem prefixing it like so:


LD_LIBRARY_PATH=/opt/libmali-gbm:$LD_LIBRARY_PATH totem


but that didn't help, nor did creating a symbolic link from rockchip_dri.so to libmali.so

libGL error happens because application require OpenGL that Mali don't have. It have nothing to do with gbm. To fix it you need to do 

LD_LIBRARY_PATH=/opt/gl4es <application>

Link to post
Share on other sites

I've been experimenting with handbrake and various h264/h265 video settings today but I've not yet found settings that have produced smooth playback without green lines. Might you have a link to that video or could you possibly upload it somewhere so that I could try the exact same video so I know if its my videos / encoder settings at fault or my hardware, please Jeff?


Handbrake isn't ideal anyway as it doesn't really support hardware encoding under Linux. ffmpeg has much better support for hardware encoding. quicksync would seem to be the way to go for Intel users wanting to do lots of / fast h264 encoding.

Link to post
Share on other sites

 Fixed it!


I have my 4K clips playing fine with gstreamer (gst-play-1.0) under armbian now!


Pretty much all my 4K vids are 29/30 fps but armbian/xfce defaults to setting my display to 60Hz. After changing the display settings to 4K @ 30Hz using the XFCE display settings tool, 4K vids (h264 and h265) play smoothly with no horizontal green lines.


I'm relieved it was something simple and I don't have to re-encode everything! As Jeff said, there is no need to pass the --videosink argument, gst-play-1.0 then the filename is enough so maybe that could be changed in the README?

Link to post
Share on other sites
6 hours ago, JMCC said:

It should be enough with double clicking on the video to make it fullscreen. Is that failing too?


Double-clicking within the gst-play window does not make it full screen. I found a post by a gstreamer developer saying that its included command line players don't support full screen without resorting to the workarounds Jeff uses. To utililise fullscreen, you would need to use totem.


Am I right in saying mpv-gbm can decode 4K videos fine but can only output (up to) 1080? That has been my experience on Rock64, but maybe 4K display output from mpv works on the Renegade?


I'm not having any more luck with armbian gstreamer's playback of 4K videos than Libreelec. I have now set the cpufreq gov to conservative and limited the CPU to 408 Mhz but I still struggle to watch 10/15 minutes of 4K video before it reboots. I could well have a faulty board if it is still doing this at 408 Mhz with a heatsink attached, which probably invalidated my warranty, if I still had one.


Jeff: Have you managed to play 4K video for longer than 15 / 20 minutes on your rock64 without it crashing, freezing or rebooting mid vid?

Link to post
Share on other sites
5 hours ago, danboid said:

Double-clicking within the gst-play window does not make it full screen. I found a post by a gstreamer developer saying that its included command line players don't support full screen without resorting to the workarounds Jeff uses. To utililise fullscreen, you would need to use totem.

The  Gstreamer player included in the script will go fullscreen when double-click on the video, or when you press the "Fullscreen" button.

Link to post
Share on other sites
4 hours ago, JMCC said:

The  Gstreamer player included in the script will go fullscreen when double-click on the video, or when you press the "Fullscreen" button.


Which player?


Have you not tested 4K playback to a 4K display with mpv? If it doesn't work, it should be noted in the README as currently it states all three video players can play 4K video but that isn't true of mpv/rock64.

Link to post
Share on other sites
17 hours ago, danboid said:

Which player?

Please read the documentation. There it says:


To play a video in a X session, use the launcher "Rockchip Gst Player".


17 hours ago, danboid said:

Have you not tested 4K playback to a 4K display with mpv?

If you read some posts above, you'll see posts confirming that it works for them. There are also others stating that they have problems. This is what this thread is meant for, to test the media implementation and debug it.


So if you are having problems with MPV, you are invited to post here details, logs, etc., so we can try to find the cause of the problem.

Link to post
Share on other sites

Ah yes! I was so convinced I would have to use the terminal to get a video to play correctly I didn't even think to look at what was under the Multimedia menu! As you say, Rockchip GST Player does enable fullscreen 4K playback.


I'm interested to hear what results people will have with this. I can only play 4K h264 videos for about 10/15 minutes on my 4GB Rock 64 before it reboots itself and thats with a heatsink attached to the CPU and under clocked to 408 Mhz max CPU speed. Are the Renegade boards or any of these Android TV devices using the same chipset more reliable for 4K video playback with gstreamer?


Another flaw with the r64 is that USB3 (SSD) drives don't seem to be reliable without external power, bus power does not seem to be quite sufficient for reliable operation. I wonder if the renegade is any better in that respect?

Link to post
Share on other sites

Checked 4K playback (full screen) on TV boxes. The main cause of the brakes and stop playback 4K  - overheating. If run a 4K video in MPV or Gstreamer, within the first few tens of seconds the temperature rises to a critical 70 (this is the first stage of regulator) and the video begins to slow down and does not play smoothly. When reach the next level of adjustment 80, the video simply stops working. I added a fan and the temperature immediately dropped when playing 4K to 45-55. And all the video began to work smoothly during the entire playback period. By the way. there was a reason for the green bars when working in 4K mode on MX10-incorrect parameters in DTB. Now assembled a new version of Armbian 5.73 with new DTB (memory optimization and increased frequency to 1500). I run the system on MX10 with TV 4K, MPV gstreamer KODI - everything works on a full screen without interference.


By the way, it is very convenient to run "armbianmonitor-m" through the UART console (or SSH console) and see the temperature in real time with any playback program.

Link to post
Share on other sites

Using 5.75 image


Glamor: The tweaked X server that you included is just as snappy IF you turn compositing back ON in the windowing settings.

This is the opposite setting for armsoc. If you leave it disabled, the screens are horribly delayed when dragging.

I have just tested both and Glamor is as fast as Armsoc on my 4GB renegade when the compositing is enabled.


Chromium is still having issues playing anything 1080p from youtube (Just running chromium-streaming from GUI)

Trying to change settings in Chromium-streaming makes it crash (probably known, as you stated some web pages will be broken)


Audio out from the audio jack is still not working. HDMI audio works fine.


- Bottom USB2 sometimes doesn't work. Unplug / replug keyboard fixes this once the OS has finished loading.


Thank you for your efforts here. :-)

This device is almost usable because of this. Once browsing is fixed, I'tgoing to be my daily Linux box!

Edited by Shades_aus
Thanking the developer was missing
Link to post
Share on other sites

JMCC: You'd asked for a follow-up, I have been using a 4GB Rock64 as a primary desktop machine for about six weeks now using Armbian + your script.

Thank you very much for the script, being able to use sites like YouTube etc with streaming video and have it work (in full screen) is very nice.

Chromium is horribly unstable for me, I find that it works well for the first while, but eventually locks up the box almost completely. I ran vmstat on a console to try and figure out what the issue is, I think it is because I have a microSD card for storage and that is basically not a long-term solution, I need an eMMC.

I was never able to get to get the Rock64 to talk properly to my 27" screen, I always experienced severe tearing and flickering -- I believe I will have fewer problems with a newer screen, so that is another solution I want to try, in the meantime I use a small screen with low resolution -- I will provide more feedback when I have a better storage device and screen, in the meantime I get by and the script helps a lot with getting this SBC to where I need it to be.

Link to post
Share on other sites

Running Deluge also causes similar to behaviour to Chromium with half a dozen tabs open -- the machine locks up for a few minutes at a time, with maybe ten seconds of normal responsiveness between slow periods.  At the console with vmstat, I see large swaps right before the GUI becomes responsive again, so I believe it may be thrashing. It seems that any use of swap at all with a microSD card is very bad for performance. 

Link to post
Share on other sites
6 minutes ago, pokkecon said:

any use of swap at all with a microSD card is very bad for performance

As a matter of fact, Armbian does not use SD card for swap by default, but instead uses zram (virtual swap partitions that are actually stored in compressed ram). You can double check it is working for you with the command "cat /proc/swaps" 

Link to post
Share on other sites

@JMCC First of all, great job done.
I'll make a video about the desktop useability of the Rock64 these days. This with Armbian Bionic + your media script. I've red many complaints of novice Rock64 owners that they can't make things to work well(Pine64 forum, my YT channel...).
So I think this video is needed for many.

I've red all the posts here and I'll add the info I've learned. Can you confirm the display refresh rate must be 30Hz in 4K to make it work well? I don't have a 4K monitor.
I'll say it's not officially supported by Armbian. If there's anything else you find important to mention, please let me know.

I'll also show how to set it to 1.51Ghz because this has changed since my first Rock64 video.
Thanks for all the work. Next month I'll do the same with the NanoPi M4 and RockPi4B. Hopefully Radxa can improve things a bit by then for their software.

Link to post
Share on other sites
On 3/20/2019 at 4:14 PM, JMCC said:

I have no 4K monitor either. In theory, the SoC supports 4K@60. Can anyone confirm if this actually works with Armbian?

Hi again. I've been testing things. I've had a few problems. Now I think I've got most fixed. But I don't get the performance others have.
First a recap.
With : Armbian_5.75_Rock64_Ubuntu_bionic_default_4.4.174_desktop (from downloadpage) : Chromium is very unstable after installing the script. I constantly get "aw snap". It plays up to 720p, but crashes during playing. Firefox the same. Plays 720p but sometimes crashes(less than Chromium) Also had hard crashes with resets. Very unstable.
I then build : Armbian_5.77_Rock64_Ubuntu_bionic_default_4.4.176_desktop : The same issues, but no hard crashes of the system. Then I changed to nightly and reinstalled your script. Chromium was a bit more stable, Firefox and Vivaldi couldn't boot anymore, they couldn't show anything in their window.

So today I started reading everything again in this thread. Until I came upon


Can you make a Rk3328-tv_Ubuntu_bionic_default_desktop image that uses a 4.4.167 kernel like the default Armbian Rock64 image with working media script also included?

It seems the media script was made for this kernel and nightly Armbian images and 4.4.154 kernel is used in your images.

So I thought, lets try with kernel 4.4.167. Everything is stable. Chromium plays Youtube well, only in 720p. 1080p seems to play ok, but it continuesly rebuffers. Firefox works again, but without vpu now.
I've now played almost an hour of different content on youtube and it hasn't crashed yet. Even different browsers together.

So it seems to me there is a problem with your script and the kernel that's used now in default build. I'm sorry I'm not more knowledgeable to know what the problem is. I just want to let you know.

Another small thing, when I choose to install streaming in the script, I can't choose arm soc or glamour anymore. You get that warning it takes xxxMB space, and after that it starts installing.

Any idea how I could improve 1080p? I'm using eMMC, and wifi connection is ok. (wifi works only with a USB hub, and I've got to replug every time it boots, I tought this was fixed. But that's another topic )

Chromium 32-bit works on none of the kernels. It always crashes, and there's no VPU support either.

I'm happy with what I've got now. It's a lot better than default where even 480p is unwatchable. If it could be improved then it's a bonus.
Here is my walktrough until now.

sudo apt update && sudo apt upgrade
sudo armbian-config  -> system -> other -> linux-image-rockchip=5.70 4.4.167-rockchip64
sudo armbian-config  -> system -> freeze enable

sudo nano /etc/default/cpufrequtils
MAX_SPEED -> 1520000 (it clocks to 1.39Ghz at 1510000)

Download script : https://forum.armbian.com/topic/9310-rk3328-media-script-rock64-renegade/
Install script : sudo ./media-rk3328.sh <- ARM SoC
Disable compositing : Windows Manager Tweaks -> compositor -> disable display compositing

sudo reboot

I'll do more tests, in a few days I'll make my video. Cheers.

Link to post
Share on other sites
18 minutes ago, JMCC said:

It's been a while since I don't test this setup. I'll have it a look.

Thank you. I can also say I changed to glamor on kernel 4.4.167.  Chromium instantly froze when playing a video.
I then changed to armsoc again with the script.  I again played video for +1 hour, and it crashed 2 times(aw snap!)
So now I'm not sure if I had luck the last time that it didn't crash, or if it's because I've done the script multiple times with different settings. 
But it's clearly more stable with 4.4.167 and armsoc. 

I'll see how things go with a clean install with 4.4.167 and glamor as first time choice. 

It does feel very snappy to work with, surfing is nice. Strange thing is that kdenlive works with the script installed, while on the RK3399's and the Tinker Board it stops it from working. 

Link to post
Share on other sites
  • JMCC unpinned this topic

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.

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.