User avatar
fbutler
Posts: 302
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England

gst-omx issue or recent change to openmax issue?

Tue Oct 09, 2012 7:03 pm

Hi,
I have the same version of the gstreamer omx-gst plugins on two different Pis

On one Pi using:

Linux raspi2 3.2.27+ #114 PREEMPT Tue Sep 4 00:15:33 BST 2012 armv6l GNU/Linux

the plugins work successfully as shown in the debug output here:

http://pastebin.com/bCWKzgWj

On another Pi using:

Linux raspberrypi 3.2.27+ #244 PREEMPT Sat Oct 6 17:26:38 BST 2012 armv6l GNU/Linux

they don't work and stay stuck in PREROLLING with the debug output shown here:

http://pastebin.com/gf26Gvtm

In the successful run on line 209 of the paste you can see "Port 131 filled buffer 0x1bc5340 (0x45442020" message followed by a "Port 131 is flushing: " message on line 215 whereas in line 210 of the other unsuccessful run paste there is a "Settings changed (port index: 131)" message followed by a "Setting port 131 to disabled" on line 214

From examining the source code in gstomx.c it is clear that the "Settings changed (port index: 131)" message is triggered by openmax raising an event being handled by the

case OMX_EventPortSettingsChanged:

statement of the switch statement in the EventHandler. Adding a break statement at the start of that case statement, recompiling, and re-installing gst-omx enables the video to start playing successfully, although it stops after a few seconds.

So what has changed between #114 and #224 that would cause this issue? Is it a recent change to Openmax that is causing the issue or a different behaviour of Openmax which is now not being handled correctly by gst-omx?

Any thoughts/fixes for this would be appreciated

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5398
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: gst-omx issue or recent change to openmax issue?

Tue Oct 09, 2012 10:52 pm

Lots of code has changed in #244. I don't know if the problem is with the GPU code or gst-omx.
Instructions for how I can reproduce this issue would be helpful.

User avatar
fbutler
Posts: 302
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England

Re: gst-omx issue or recent change to openmax issue?

Tue Oct 09, 2012 11:42 pm

dom wrote:Lots of code has changed in #244. I don't know if the problem is with the GPU code or gst-omx.
Instructions for how I can reproduce this issue would be helpful.
Thanks Dom,

I believe these are the commands that I ran after a fresh install of 2012-09-18-wheezy-raspian, and setting a memory split of 192 with no overclocking, are as follows:

# Get and install rpi-update if necessary
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo apt-get -y install git-core

# Upgrade to the latest packages and firmware
sudo apt-get update
sudo apt-get upgrade -y
sudo rpi-update
sudo reboot

# Add the qt50-snapshot to the sources list and install it
sudo sh -c 'echo deb http://archive.qmh-project.org/rpi-wheezy/debian unstable main >> /etc/apt/sources.list'
sudo apt-get update
sudo apt-get -y --force-yes install qt50-snapshot

# Get gst-omx source
cd $HOME
git clone -b raspberry git://anongit.freedesktop.org/gstreamer/gst-omx

# Install the Gstreamer packages, and the packages required to build omx
sudo apt-get install -y autoconf gtk-doc-tools libtool libglib2.0-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev

# Autogenerate the configure script, configure, make and install gst-omx
cd gst-omx
./autogen.sh --noconfigure
./configure --prefix=/home/pi/omx
make
make install

# Set up the gst-omx environment for the pi user
cp omx/gstomx-raspberry.conf $HOME/omx/lib/gstreamer-0.10/gstomx.conf
cd $HOME
echo -e \\n# Gstreamer environment >> .profile
echo export GST_PLUGIN_PATH=$HOME/omx/lib/gstreamer-0.10/ >> .profile
echo export GST_OMX_CONFIG_DIR=$HOME/omx/lib/gstreamer-0.10/ >> .profile
echo export LD_LIBRARY_PATH=$HOME/omx/lib/gstreamer-0.10/ >> .profile
. ./.profile

# Install the GStreamer Tools
sudo apt-get install gstreamer0.10-tools

# Verify that gst-omx has been installed correctly. If it has the following command should show these plug-ins:
# openmax: omxmpeg4videodec: OpenMAX MPEG4 Video Decoder
# openmax: omxh264dec: OpenMAX H.264 Video Decoder
gst-inspect-0.10 | grep omx

# List all of the currently installed GStreamer plug-ins and features
gst-inspect-0.10

# A list detailing other GGtreamer plug-ins and what packages they are in is available at: http://gstreamer.freedesktop.org/docume ... ugins.html
# Install a basic core of Gstreamer plug-ins
sudo apt-get install -y gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-bad gstreamer0.10-plugins-ugly gstreamer0.10-alsa

# List all of the currently installed GStreamer plug-ins and features
gst-inspect-0.10 | more

# Install the v4l-utils to be able to use the v4l2-ctl command to configure v4l2 input devices, such as webcams, if required
sudo apt-get install v4l-utils

# Get the big buck bunny video
wget http://mirrorblender.top-ix.org/peach/b ... p_h264.mov

# Play the video
gst-launch-0.10 --gst-debug=omx:5 filesrc location=big_buck_bunny_480p_h264.mov ! qtdemux name=demuxer \ demuxer. ! queue ! faad ! audioconvert ! alsasink device=hw:0,0 sync=false \ demuxer. ! h264parse ! omxh264dec ! ffmpegcolorspace ! fbdevsink


Let me know if you see any glaring errors that I've made or if you need more info.

Thanks again for taking the time to look at this.

Fergal

MattSwarbrick
Posts: 27
Joined: Thu Oct 04, 2012 3:15 pm

Re: gst-omx issue or recent change to openmax issue?

Wed Oct 10, 2012 3:40 pm

So reverting back to a previous firmware version I am now able to play a big buck bunny 480p mov file.

Its very slow about half of the full speed, and it uses around 95% cpu, is this not using the GPU?

Running the same video in omxplayer which definately uses the GPU runs at the right speed, and uses about 25% of cpu

Any suggestions,? this is from using various gst-launches

User avatar
fbutler
Posts: 302
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England

Re: gst-omx issue or recent change to openmax issue?

Wed Oct 10, 2012 4:04 pm

MattSwarbrick wrote:So reverting back to a previous firmware version I am now able to play a big buck bunny 480p mov file.

Its very slow about half of the full speed, and it uses around 95% cpu, is this not using the GPU?

Running the same video in omxplayer which definately uses the GPU runs at the right speed, and uses about 25% of cpu

Any suggestions,? this is from using various gst-launches
The reason for the high CPU use is that omx-gst has only implemented the H.264 decode and encode elements so far to take advantage of the GPU. Other elements in the gstreamer pipelines haven't been created/modified to make use of the GPU yet. One of the elements responsible for consuming large chunks of the CPU is ffmpegcolorspace. I did some quick analysis of this some time ago which can be seen here:http://www.raspberrypi.org/phpBB3/viewt ... 27#p169327

Hopefully in time more gstreamer elements will be optimised to use the GPU on the Pi.

I'll be reverting the firmware to an earlier version tonight as well to narrow down when the issue was introduced.

User avatar
fbutler
Posts: 302
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England

Re: gst-omx issue or recent change to openmax issue?

Wed Oct 10, 2012 5:38 pm

dom wrote:Lots of code has changed in #244. I don't know if the problem is with the GPU code or gst-omx.
Instructions for how I can reproduce this issue would be helpful.
Hi Dom,

Reverting to the 17ff0bb5bb46210bad235d32589d35f951f269cf firmware version has fixed the issue. I'm now consistently able to replay the video without any issues.

Fergal

wickwire
Posts: 3
Joined: Thu Nov 22, 2012 1:52 pm

Re: gst-omx issue or recent change to openmax issue?

Fri Nov 23, 2012 3:01 pm

fbutler wrote:
dom wrote:Lots of code has changed in #244. I don't know if the problem is with the GPU code or gst-omx.
Instructions for how I can reproduce this issue would be helpful.
Hi Dom,

Reverting to the 17ff0bb5bb46210bad235d32589d35f951f269cf firmware version has fixed the issue. I'm now consistently able to replay the video without any issues.

Fergal
Hi, I've followed the steps in this thread, reverted to the mentioned firmware and I'm also able to play the buck bunny video - however, slow framerate/high CPU load.

Just to make sure, this is the most we can expect from gst-omx at this point, correct? Where to go from here, is gst-omx the only way to go with Gstreamer+Raspberry Pi?

Thanks!

luc4
Posts: 49
Joined: Mon Nov 12, 2012 12:28 am

Re: gst-omx issue or recent change to openmax issue?

Sat Nov 24, 2012 12:03 am

I also encountered the issue with gst-omx. I compiled gst-omx but I was only able to play a 320x180 video with a recent image. Is there anyone actively working on this already?

richardp
Posts: 117
Joined: Thu Jan 12, 2012 11:46 am

Re: gst-omx issue or recent change to openmax issue?

Sun Jan 06, 2013 2:32 pm

Arrrrrrrgh... examples I made 6 months ago are now non-functional on the Pi

Linux raspberrypi 3.2.27+ #1 PREEMPT Sat Dec 29 16:54:58 GMT 2012 armv6l GNU/Linux
using the codebase (is this correct?)

Code: Select all

git clone git://anongit.freedesktop.org/gstreamer/gst-omx -b raspberry

Code: Select all

GST_DEBUG="omx:5" gst-launch-0.10 -v filesrc location="./test.h264" ! h264parse ! omxh264dec ! queue ! ffmpegcolorspace ! fbdevsink sync=true
It now hangs waiting for events....

Code: Select all

0:00:12.067417304  2109  0x1c22a90 DEBUG                    omx gstomx.c:803:gst_omx_component_get_last_error:<omxh264dec-omxh264dec0> Returning last error: None (0x00000000)
0:00:12.069672372  2109  0x1c22a90 DEBUG                    omx gstomx.c:1542:gst_omx_port_set_enabled_unlocked:<omxh264dec-omxh264dec0> Setting port 131 to disabled
0:00:12.080753706  2109  0x1c22a90 DEBUG                    omx gstomx.c:825:gst_omx_component_get_parameter:<omxh264dec-omxh264dec0> Getting parameter at index 0x02000001
0:00:12.068552339  2109  0x1c22950 DEBUG                    omx gstomx.c:945:gst_omx_port_acquire_buffer:<omxh264dec-omxh264dec0> Acquiring buffer from port 130
0:00:12.083935802  2109  0x1c22950 DEBUG                    omx gstomx.c:803:gst_omx_component_get_last_error:<omxh264dec-omxh264dec0> Returning last error: None (0x00000000)
0:00:12.085585851  2109  0x1c22950 DEBUG                    omx gstomx.c:977:gst_omx_port_acquire_buffer:<omxh264dec-omxh264dec0> Waiting for output ports to reconfigure
RaspberryPi's galore
Solid run CuBox
ODroid U2

tthef
Posts: 2
Joined: Sun Jan 20, 2013 3:32 pm

Re: gst-omx issue or recent change to openmax issue?

Sun Jan 20, 2013 3:59 pm

Commit hash 17ff0bb5bb46210bad235d32589d35f951f269cf no longer exists in the firmware repo (perhaps someone committed the cardinal sin of rebase); would anyone be able to post the commit message, or at least the date, for that commit?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5398
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: gst-omx issue or recent change to openmax issue?

Sun Jan 20, 2013 6:04 pm

tthef wrote:Commit hash 17ff0bb5bb46210bad235d32589d35f951f269cf no longer exists in the firmware repo (perhaps someone committed the cardinal sin of rebase); would anyone be able to post the commit message, or at least the date, for that commit?
https://github.com/Hexxeh/rpi-firmware/ ... f951f269cf

User avatar
Defiant
Posts: 179
Joined: Tue Oct 30, 2012 6:17 pm
Location: Hamburg, Germany

Re: gst-omx issue or recent change to openmax issue?

Sun Jan 20, 2013 6:07 pm

Isn't that commit one of the <=256MB Ram versions?

So I guess someone has to adjust the gst-omx plugin to make it work again?

tthef
Posts: 2
Joined: Sun Jan 20, 2013 3:32 pm

Re: gst-omx issue or recent change to openmax issue?

Fri Jan 25, 2013 5:45 pm

Yes, the last known working firmware is before support for the 512MB model, which does not help me. I was really hoping to get the codec working for a demo at FOSDEM, but I guess I will have to resort to a using different HW.

adrien
Posts: 12
Joined: Thu Apr 18, 2013 2:02 pm

Re: gst-omx issue or recent change to openmax issue?

Thu Apr 18, 2013 2:05 pm

I have the same issue on my system.

Anyone got a solution ?

Perhaps, the solution is in the gstomx.conf file, but I could find any informations.

User avatar
Defiant
Posts: 179
Joined: Tue Oct 30, 2012 6:17 pm
Location: Hamburg, Germany

Re: gst-omx issue or recent change to openmax issue?

Thu Apr 18, 2013 5:47 pm

gst-omx is working with Gstreamer 1.0, see http://www.raspberrypi.org/phpBB3/viewt ... 05#p289205

alexandru_cazacu
Posts: 1
Joined: Thu Jul 13, 2017 11:43 am

Re: gst-omx issue or recent change to openmax issue?

Thu Jul 13, 2017 12:08 pm

Hi everyone,

I got stuck some good weeks trying to display videos using an qt application(QML), but i finally did it, and it works great.

First of all, on raspberry you have to install the following packages:
  • -sudo apt-get install libudev-dev libinput-dev libts-dev libxcb-xinerama0-dev libxcb-xinerama0
    -sudo apt-get install gstreamer1.0-omx libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
    -sudo apt-get install libdbus-1-dev
    -sudo apt-get install gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly gstreamer1.0-alsa gstreamer1.0-omx
    -sudo apt-get install gstreamer1.0-libav
    -sudo apt-get install gstreamer1.0-plugins-base
    -sudo apt-get install gstreamer1.0-fluendo-mp3
    -sudo apt-get install gstreamer1.0-tools
    -sudo apt-get install omxplayer
After that, to compile your app for raspberry make sure
you follow the steps presented in the link: https://wiki.qt.io/RaspberryPi2EGLFS

WARNING!!!!!
The key step was to compile the QtMultimedia with -GST_VERSION=1.0 flag.
  • ~/raspbi/qt5/bin/qmake -r GST_VERSION=1.0
    make -j8
    make install
Good luck!!!

Best regards,
Alexandru Cazacu.

Return to “Graphics, sound and multimedia”