Jeff R Posted January 27, 2019 Posted January 27, 2019 Here is mediainfo dump for the 4k file mediainfo_4kfile.txt
danboid Posted January 27, 2019 Posted January 27, 2019 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?
Jeff R Posted January 27, 2019 Posted January 27, 2019 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.
danboid Posted January 27, 2019 Posted January 27, 2019 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!
Jeff R Posted January 27, 2019 Posted January 27, 2019 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.
Dante4 Posted January 27, 2019 Posted January 27, 2019 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>
danboid Posted January 27, 2019 Posted January 27, 2019 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.
Jeff R Posted January 27, 2019 Posted January 27, 2019 I've been using an Interstellar movie trailer but I forgot where I got it from. I just downloaded a different version from http://www.hd-trailers.net/movie/interstellar/. The one labelled "Trailer 2" This played fine at full screen, downscaled to my 1080 monitor. I won't get a chance to test it on a 4k display until next weekend.
danboid Posted January 27, 2019 Posted January 27, 2019 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?
danboid Posted January 28, 2019 Posted January 28, 2019 I have had to change my CPU governor from ondemand to powersave (by editing /etc/default/cpufrequtils) to increase the stability when playing 4K videos but I don't think that is enough to watch a full movie yet as I'm still experiencing crashes or reboots after 20m or so of use.
JMCC Posted January 28, 2019 Author Posted January 28, 2019 On 1/27/2019 at 6:01 AM, danboid said: Have you been able to get videos playing in proper full screen mode with gstreamer It should be enough with double clicking on the video to make it fullscreen. Is that failing too?
danboid Posted January 28, 2019 Posted January 28, 2019 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?
JMCC Posted January 29, 2019 Author Posted January 29, 2019 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.
danboid Posted January 29, 2019 Posted January 29, 2019 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.
JMCC Posted January 30, 2019 Author Posted January 30, 2019 17 hours ago, danboid said: Which player? Please read the documentation. There it says: Quote 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.
danboid Posted January 30, 2019 Posted January 30, 2019 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?
TonyMac32 Posted January 30, 2019 Posted January 30, 2019 38 minutes ago, danboid said: I wonder if the renegade is any better in that respect? Doubtful, it is powered via USB instead of with a barrel jack. Does your SSD have current requirements listed on it? SBC's honestly don't even conform to USB 2.0 current capacity of 500mA, let alone USB 3.0's 900 mA.
balbes150 Posted February 2, 2019 Posted February 2, 2019 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. 1
TonyMac32 Posted February 2, 2019 Posted February 2, 2019 You've reminded me to double-check the ram configuration on Renegade and Potato, they may be slow.
Shades_aus Posted March 14, 2019 Posted March 14, 2019 (edited) 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 March 14, 2019 by Shades_aus Thanking the developer was missing 2
pokkecon Posted March 16, 2019 Posted March 16, 2019 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. 1
pokkecon Posted March 16, 2019 Posted March 16, 2019 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. 1
JMCC Posted March 16, 2019 Author Posted March 16, 2019 Thanks for all the feedback, guys, it's really useful. Sorry I cannot give an immediate solution right now to all of that, I'm working in fixing more fundamental stuff for the Renegade (at device tree level), and then I plan to get back to this.
JMCC Posted March 16, 2019 Author Posted March 16, 2019 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"
pokkecon Posted March 16, 2019 Posted March 16, 2019 Ah, OK, thanks for clearing that up. I guess I still don't know why it's locking up then. I will keep digging.
NicoD Posted March 20, 2019 Posted March 20, 2019 @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. Cheers. 1
JMCC Posted March 20, 2019 Author Posted March 20, 2019 15 minutes ago, NicoD said: 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 have no 4K monitor either. In theory, the SoC supports 4K@60. Can anyone confirm if this actually works with Armbian? 1
NicoD Posted March 22, 2019 Posted March 22, 2019 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 Quote 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 reboot 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. 1
JMCC Posted March 22, 2019 Author Posted March 22, 2019 1 hour ago, NicoD said: Hi again. I've been testing things. I've had a few problems. It's been a while since I don't test this setup. I'll have it a look. 1
NicoD Posted March 22, 2019 Posted March 22, 2019 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.
Recommended Posts