Jeff R

Update on stability issues. Sadly, I never discovered a way to make my gstreamer player stop crashing. As I noted in my July 20 2019 post, I created a very stripped down player that loops, but it continued to lock up between 20 and 700 minutes. Happily, I decided to try out the Kodi/LibreELEC player, and spent a couple days porting my looping/GPIO-triggered player to be a Kodi python addon. After a couple 8+ hour runs, I have not seen the crashing issues I saw with gstreamer. I'm not sure if the stability is from the stripped-down LibreELEC OS, or because Kodi is using OpenGL (or is gstreamer also using the OpenGL interface?) But, at least I know have a stable Rock64 4k player.

That was a great suggestion. I launched several 4k, 1080p and 640x480 videos in the Rockchip Gst Player, and yes, I see the same behavior in all of them (now that I am looking closely for it) The first frame is displayed statically for ~1/4 sec for the 4k video, and then the video plays smoothly. Interestingly enough, the 640x480 delay is noticeably shorter, but I still see it. I see the same thing when running MPV-GBM. I see the same thing when playing a file on a ramdisk. And, I just launched VLC on my Windows i7, set it up to loop, and i see the startup delay there, too. Based on this test, I'm assuming this is just something inherent in setting up video playback streams. And unless someone has any additional ideas, there is nothing in gstreamer or the Rock64 media kit that I can set to reduce it. So, I'll have to work around it by making sure that the first second of the video is static. Thanks for the suggestion. -Jeff

Here's one more post, looking for advice. Subject: delay/stutter in gst/gstreamer c code application When the video starts playing in my C-coded gst video player program, there is a noticeable delay, or stutter of the first frames. (See my previous post for a description of the environment and code) The delay/stutter is visible, but is too short for me to measure (1/10 to 1/4 second). This also occurs when using a seek to loop back to 0. I suspect there is a finite amount of time needed to uncompress/deinterleave the video data before it can be displayed. It doesnt seem to be a file access problem, since I've tried running out of a ram disk to eliminate SD card read time, but it did not help. Is this normal for gst/gstreamer? Is there any way to reduce this delay with different gst/gstreamer parameters in the c-code? I can work around this if I have to, but it would be nice to have a clean video start. Thanks, -Jeff

Topic: Stability of gst based player using RK3328 Media Script My earlier post today regarding Buster made me recall that I have a stability problem with my gst video player, and maybe one of you can help. My gst-based video application plays one video file that is actually a concatenation of 4 other videos of the same format. A GPIO input selects which of the 4 videos to be played, and the program loops that video until a different selection is made. The seek command in the concatenated video is much faster than loading a new video each time. This is largely based on the examples in the gstreamer/gst-docs files at Github. It all worked, but the program occasionally freezes, anywhere from 20 to 700 minutes into a test. I ran with GST_DEBUG=2 (WARN), and I found a bunch of warnings and errors, including many warning and error messages at startup (some of these may be audio related – I did not have speakers hooked up) frequent frame drops - <mppvideodec0> can't process this frame timestamp issues - <mppvideodec0> decreasing timestamp But, I was never able to see a specific error associated with the program lockup My first guess was that there was a data streaming problem somewhere, so I forced a CPU speed increase from 408 MHz to 1200MHz. No difference. So, I did a clean build using the latest Bionic (to make sure that it was not a random package that I installed that was the problem) and still see the errors. This occurs with several different videos, from 640x480 up to 4k, and using both h264 and h265 encoding. Configuration: Rock64, 4GB board OS: Latest Bionic, downloaded from: www.armbian.com/rock64/ Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182_desktop.img (see my other post about my attempt to move to Buster) VIdeo: Big Bunny 1080p, 30fps, h264 from http://bbb3d.renderfarming.net/download.html I installed the Media Script, downloaded from this thread, dated Jan 13, 2019 I installed gstreamer1.0-tools gstreamer1.0-plugins-base-apps libgstreamer1.0-dev X11VNC I stripped the program down to get rid of everything I could (removing config files, keyboard watch, GPIO watch, debug statements, etc) and made a simple player that just loops after 30 seconds. The code is attached, as is the log file based on a GST_DEBUG=2 setting. Anyone have any thoughts? I’d love some advice, or a pointer to a person or group that I could get in contact with. Thanks! -Jeff simple_player_log_bunny_20190720.log simple_player.c

I did a test build using Armbian Buster on my Rock64 TLDR: It failed Hardware: Rock64 4 GB OS downloaded from: https://www.armbian.com/rock64/#kernels-archive: Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.7z Media script: downloaded from this thread, dated Jan 13, 2019 I imaged the SD card, booted, setup a user and password, and connected to wifi. That's it. I then ran the media script, using the first 4 options (system, dev, mpv, gstreamer) and the Armsoc version. The script seemed to run OK, but ended in a message that said there were errors during installation. I've attached the install.log. There are no FAIL, ERROR or WARN messages. The only issue I found was this sequence: Could not open file /var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-armhf_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-arm64_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-armhf_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-arm64_Packages.lz4 - open (2: No such file or directory) I then rebooted and it failed to boot, showing : [FAILED] Failed to start Light Display Manager Per the bootstrap.log, I ran "systemctl status lightdm.service" (the output is also attached) I'm not sure what the error messages mean, or what "Unit plymouth-quit.service not found" implies. So, obviously something in the media script did something to mess up the desktop. Perhaps an old Bionic library incompatible with Buster? So, I was eager to try the new build to see if it got rid of some stability problems I'm having with my gst based player. But it looks like I'm going to have to go back to my Bionic build, unless someone has any idea on how to repair the Light Display Manager and get me booted. Thanks, -Jeff sysctl_log.txt install.log

Hi. The Armbian site for Rock64 has the Buster release. https://www.armbian.com/rock64/#kernels-archive The release notification includes: "Video and 3D acceleration addon" with a hyperlink to this forum topic. Does that mean that I only have to apt-get install gstreamer1.0, apps, tools and utilities to get my gst program to run? Or do I need to dissect he media script to figure out what to install?

So, I never resolved the problems with the Pine64-CPP library but I found an alternate. First, I used bash scripts to make sure the Rock64 was working, and I had the right pin addresses. https://github.com/Leapo/Rock64-BashGPIO I used the table table from this website to correctly identify the gpio indices. https://github.com/Leapo/Rock64-R64.GPIO...GPIO-Modes I used the items from the column labeled GPIO# (ROCK) Lastly, I used the GPIO Class from the following. https://github.com/halherta/RaspberryPi-GPIOClass-v2 Even though it is was created for the Raspberry Pi, I found that it correctly manipulated the files in /sys/class/gpio on my Rock64. Note: I have only tested the GPIO read function, since that is what I'm trying to do for my project.

I'm trying to run the example.cpp that comes with Pine64-CPP but I am throwing segmentation faults. The man-setup() call initialzes the board with the following if statement in the setup() function in gpio.cpp if((uint64_t)gpio_mem % PAGE_SIZE) and the this->gpioMap = statement that uses SUNXI_GPIO_BASE In the example code, I initialize the pin with man->pinMode (PI_GPIO_24, OUTPUT); The pinMode function in gpio.cpp, launches _setPullupdn with gpio=78 and pud = 1. As expected Inside _setPullupdn, the following is set bank= 2 index = 0 offset = 28 The segmentation fault seems to come from this line: regval = *(&pio->PULL[0] + index); I have a 4 GB Rock64 running the latest Armbian desktop from this site. sudo cat /sys/kernel/debug/gpio gives me GPIOs 0-31, platform/pinctrl, gpio0: gpio-0 ( |vcc_host_5v ) out hi gpio-2 ( |? ) out lo gpio-30 ( |vcc_sd ) out lo GPIOs 32-63, platform/pinctrl, gpio1: gpio-50 ( |mdio-reset ) out hi GPIOs 64-95, platform/pinctrl, gpio2: GPIOs 96-127, platform/pinctrl, gpio3: GPIOs 510-511, platform/rk8xx-gpio, rk8xx-gpio, can sleep: gpio-510 ( |? ) out lo gpio-511 ( |? ) out lo Anyone have any thoughts? Thanks.

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.

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.

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.

Here is mediainfo dump for the 4k file mediainfo_4kfile.txt

I would also like to thank JMCC for this script. It is exactly what I need for my project. I have also been testing this script on my Rock 64, and I am not experiencing any problems with the 4k playback. Rock64, 4 GB version Clean build of armbian bionic desktop from https://www.armbian.com/rock64/ Installation of the media script (I installed everything) Installed libgstreamer1.0-dev Installed gtk 2.0 and 3.0 ( a bunch of files!), thinking I needed these for full screen video. I don't think this impacted the gst install, but I'm not sure. ran update and upgrade I can run gst-play-1.0 test.mp4 gst-launch-1.0 playbin uri=file:///home/rock64/gs/test.mp4 note the use of playbin. This was key to getting it to work - see dma error notes below I did not have to specify using rkximagesink. I am using two test files, both of them mp4 files 1920 x 1080 at 29.97 Hz, identified by ffmpeg as Video: h264 (Constrained Baseline), 23 seconds 3840 x 2160 at 29.97 Hz, identified by ffmpeg as Video: h264 (High), 2 minutes 38 seconds (yes, a >500MB file) Both videos run smoothly with no artifacts. I am not seeing any noticeable cpu heating after the 2+ minute video. (50 C before playing, 58 C after) When played on a 1080p monitor both videos play full screen when I hide the ldxe panel When played on a 4k monitor the 1080 video plays in a window the 4k video plays full screen I can also compile a simple c++ file using a playbin construct. I should note that I saw a bunch of failures trying to build the gstreamer pipeline manually, both with gst-launch-1.0 and the c++ code (it started throwing "gst_dmabuf_memory_get_fd" errors). Using playbin seems to bypass all of this. Hope this provides a clue.

Hi. This seems like an incredible newbie question. I created a forum account a couple days ago, including validating my email. My profile says that my status is "Validating". But, I don't seem to be able to respond to an existing post to ask a question. There are no "reply" buttons on the existing post, like I see on other forums. I can post a new topic (like this one). But I do see a popup that says that "Your content will need to be approved by a moderator" Am I missing something? Do I need an additional validation of some sort to reply to posts? Do I just need to wait another day? Thanks.