gstreamer 1.4 / gst-omx 1.2

[mouse9911]

Hi, I am looking to compile deb files for gstreamer1.4 and gst-omx1.2 . Gst-omx seems to have some pi-specific fixes and more OMX features (intraframe-refersh) that would be very useful for the current project I am working on.

I also hope that some of the fixes might fix a problem I noticed on the PI with gstreamer,
https://github.com/Hexxeh/rpi-firmware/issues/57

I managed to compile the gstreamer packages,
gstreamer
gst-plugins-base
gst-plugins-good
gst-plugins-bad
gst-plugins-ugly
gst-libav
gst-omx

Using a slightly modified version of the script from
http://www.onepitwopi.com/raspberry-pi/ ... pberry-pi/
And then using checkinstall

Does anyone have any advice on how to compile deb packages or by chance have these debs already compiled?

[sphaero]

Did you ever get more success with gst1.4 and the omx plugins?

I'm testing 1.4.4 with omx from git latest but not having a lot success yet.

Creating a deb should be trivial, I haven't done it myself yet for gstreamer but the debian package in unstable is just the latest stable release. You should just build from the deb-src: https://wiki.debian.org/SourcePackage

[pbeyl]

Hi

I am also currently trying to compile gstreamer with gst-omx plugin. Have tried various different branches but also not having much success. Seems like the gst-omx plugin does not follow same release cadence as the main gstreamer application and plugins. So not sure which gst-omx version is compatible with which branch of the gstreamer application.

Have been able to use the unmodified script http://onepitwopi.com/code/gstreamer.sh from the post http://www.onepitwopi.com/raspberry-pi/ ... pberry-pi/ to compile all components but the gst-omx plugin fails to load because there are some undefined variables.

I suspect that the gst-omx plugin is dependent on newer branch of gstreamer but not sure which one. If anyone has guidance on version dependency and has recently successfully compiled gstreamer with gst-omx plugin on raspbian, guidance would be greatly appreciated.
BTW. I need to be able to set the "inline-header=true" flag for the omxh264enc function which is not included in the gstreamer1.0 through apt on wheezy

/P

[gkreidl]

I've compiled gstreamer1.0-omx 1.2 a short while ago because of some memory leaks in the 1.0 version from the repository (which have been fixed meanwhile). It should work with gstreamer1.0 1.4 versions from the repository, but all my test brought negative results. gstreamer chains that worked with version 1.0 didn't work any more with 1.2.

[Swap_File]

pbeyl: I have a similar (or same) problem with compiling gstreamer, it all seems to complete but the omx plugins don't show up when I run gst-inspect-1.0

((gst-plugin-scanner:14708): GStreamer-WARNING **: Failed to load plugin '/usr/local/lib/gstreamer-1.0/libgstomx.so': /usr/local/lib/gstreamer-1.0/libgstomx.so: undefined symbol: GST_PAD_SET_ACCEPT_TEMPLATE

I've tried 1.2.4, 1.4 and 1.6 and they all get the same error.

I think I'm going to have to stick with the 1.2 version that ships with Raspbian, I don't have time to debug gstreamer...

[Swap_File]

I switched over to Jessie and now I get a new error after compiling 1.2.4

(gst-plugin-scanner:616): GStreamer-WARNING **: Failed to load plugin '/usr/local/lib/gstreamer-1.0/libgstomx.so': /usr/local/lib/gstreamer-1.0/libgstomx.so: undefined symbol: GST_VIDEO_DECODER_CAST

[Dingo_aus]

I am in a similar position with Jessie.

Is there a definative solution for accessing OMX encoding on Jessie anywhere?

Cheers,

Dingo

[gkreidl]

I am in a similar position with Jessie.

Is there a definative solution for accessing OMX encoding on Jessie anywhere?

Cheers,

Dingo

Yes, use the gstreamer1.0-omx module from the repository.

[Dingo_aus]

Thanks, trying that now.

[Swap_File]

I did not realize that the default version of gstreamer1.0 in the Jessie repository was 1.4.4....

That makes things a lot easier and solves my problems for me. It's unfortunate so many guides online are out of date...

[Swap_File]

Near as I can tell, scaling to full screen in hardware is broken in glimagesink on the Pi with 1.4.4.

The best alternative I have found is to unpack the debs from the old vontaene repository and drop libgstegl-1.0.so and libgsteglglessink.so into the gstreamer plugins directory to add eglglessink back in (see attachment for the two files if you don't want to do it yourself).

Using eglglessink means you cannot use the gleffects plugins, but that's a small price to pay.

Technically you could use the gleffects plugins, but you'd have to use glupload, gleffects, then gldownload which is incredibly slow again.

I was able to compile the non-omx parts of 1.6.2 using the onepitwopi script (and renaming the references) and let install it over my 1.4.4. It seems to have left my 1.4.4 omx plugins alone and updated the rest, but it didn't help my glimagesink problems.

[gkreidl]

https://github.com/RPi-Distro/repo/issues/4
and also
https://github.com/RPi-Distro/repo/issues/8

I really hope that someone will fix that soon.

[Swap_File]

I haven't ran into those problems yet, but that's likely because I'm not running Xorg (command line only, Jessie Lite).

[Swap_File]

Using the above modifications, I found some working pipelines for my low resolution, low latency, full screen, 30fps, video streaming with effects.

Sending:
raspivid -w 400 -h 240 -s -fps 30 -g 10 -n -pf baseline -ex auto -t 0 -o - | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink host=192.168.1.255 port=9000

TV Effects (software)
gst-launch-1.0 -vvv udpsrc port=9000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! avdec_h264 ! videoconvert ! queue ! revtv ! eglglessink

Software h264 decoding is better here to avoid uploading and downloading from the video card repeatedly. The queue forces the pipeline to split into two threads and spread out the cpu load.

GL Effects (hardware)
gst-launch-1.0 -vvv udpsrc port=9000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! h264parse ! omxh264dec ! glupload ! glfiltercube ! gldownload ! eglglessink

Hardware h264 decoding is better here because glupload realizes that the output from omxh264dec is already in the video card and doesn't waste resources uploading and downloading it again.

If anyone figures out how to get glimagesink to scale to full screen in hardware like eglglessink, I'd love to hear it!

Some other pipelines I used:
gst-launch-1.0 -vvv videotestsrc ! capsfilter caps="video/x-raw,width=400, height=240" ! glupload ! glfiltercube ! gldownload ! eglglessink

gst-launch-1.0 -vvv alsasrc device=hw:1 ! libvisual_jess ! capsfilter caps="video/x-raw,width=400, height=240 ,framerate=30/1" ! eglglessink

[gkreidl]

eglglessink has been removed in 1.4.

[Swap_File]

eglglessink has been removed in 1.4.

As stated above, I added eglglessink back in by extracting the two required files of the debs from 1.2 and dropped them into the gstreamer 1.4 / 1.6 shared plugins / library folder with the rest.

libgsteglglessink.so goes in /usr/local/lib/gstreamer-1.0/
libgstegl-1.0.so.0 goes in /lib/arm-linux-gnueabihf/

The files are attached to my other post if you want them, it seems to work fine. eglglessink can scale video to full screen in hardware at zero cpu cost, something I can't get glimagesink to do.

I think it's a known issue with glimagesink.
http://gstreamer-devel.966125.n4.nabble ... 71513.html

[bust]

Hi all

I am sorry if I interfere in your discussion about your problem occurred with gst
I work principally on the system Linux in the lower level and i am not really expert on
side video but could you please give me the result of the command line ldd libgsteglglessink.so
when I build (gst-plugins-bad-1.6.2), this lib is not generated... ???

Regards

[gkreidl]

It's not a good idea to use/compile other versions of gstreamer1.0 libraries, because it might corrupt epiphany and other browsers using webkit3.
The gstreamer1.0 libraries and tools come from two different sources: a part comes from raspbian.org (without any RPi specific patches) and another part comes from archive.raspberrypi.org. Those have specific patches which are needed to work with other software (and to use the GPU). They are maintained by developers from collabora.

[bust]

Hi
Thank for your councils commented but my question is rather result of dependency (*.so) command line (ldd libgsteglglessink.so)
Regards

[Swap_File]

Hi
Thank for your councils commented but my question is rather result of dependency (*.so) command line (ldd libgsteglglessink.so)
Regards

eglglessink is not included in gstreamer 1.6. If you want to use it you need to take it out of the debs from 1.2 and put it in your 1.4 or 1.6 plugins folder. See my above posts.

You may need to delete your .cache folder in your profile directory to force gstreamer to rescan your plugins.

I don't know how eglglessink will work with anything X related or any other programs. gkreidl mentioned it may cause problems.

I only use gstreamer for handling video feeds via gst-launch-1.0 and my own C programs and python scripts, and for that, adding eglglessink from 1.2 to 1.4 / 1.6 works great.

[bust]

Hi
Thank to you two.
Regard

[Gamadril]

Thanks for sharing, but for some reason it does not help on my system.

I have a buildroot 2016.02-rc2 system with gstreamer 1.6.3 - glimagesink has the same problem - playback is not usable. I've tried the eglglessink from the zip above.

Code: Select all

gst-launch-1.0 videotestsrc pattern=ball ! video/x-raw,width=800,height=480 ! eglglessink

The pipeline starts playing, but still slow like with glimagesink.

Do I need a specific rpi firmware version?

[Swap_File]

Adding a queue to make it multi-threaded seems to make it usable for me, CPU usage is around 104%.

Without the queue it drops buffers and only uses 84% of my CPU.

gst-launch-1.0 videotestsrc pattern=ball ! video/x-raw,width=800,height=480 ! queue ! eglglessink

[pedruski]

hi everybody, did anybody manage to get omx 1.2 working with gstreamer 1. 4? I have been having a series of crashes with video and openframeworks in the rpi and everything points to the omx module. unfortunately i cant manage to upgrade the omx module 1.0.0 to 1.2 - its crazy that its not that in the repository as 1.2 came out 2 years ago ! has anybody had any luck ? heres a link to the documentation of my process http://piratepad.net/0uPIhAVSj3,

any pointers would be welcome ! many thanks

p/

[gkreidl]

hi everybody, did anybody manage to get omx 1.2 working with gstreamer 1. 4? I have been having a series of crashes with video and openframeworks in the rpi and everything points to the omx module. unfortunately i cant manage to upgrade the omx module 1.0.0 to 1.2 - its crazy that its not that in the repository as 1.2 came out 2 years ago ! has anybody had any luck ? heres a link to the documentation of my process http://piratepad.net/0uPIhAVSj3,

any pointers would be welcome ! many thanks

p/

gst-omx 1.0 is working quite will after a memory leak has been fixed. (I also tried to compile and install 1.2 a while ago but it never worked.). I'm using it all the time for video transcoding.

What really seems to be broken is the OpenGL ES output in 1.4 that used to work in Wheezy. I filed an issue about that many months ago but it never got fixed.
Part of gstreamer-1.0 1.4 comes from raspbian.org, another part (gst-omx and the bad plugins as far as I remember) from the archive at raspberrypi.org. The sources should be in the github of collabora, but I could never find the official sources of the bad plugins.