Hello,
I’m working on a DVR esque application that needs to be able to stream data out via the tcpserversink gstreamer element.
I’m testing the following pipeline:
gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.51:554/axis-media/media.amp ! rtph264depay ! h264parse ! matroskamux ! tcpserversink host=192.168.1.253 port=8080
This pipeline works on Windows with gstreamer 1.5.2.
This also works with gstreamer compiled from source on my Linux desktop: 1.7.2.
This also works with gstreamer compiled from source on my Jetson: 1.7.2
This does not work with gstreamer distributed on my Linux desktop: 1.2.4
This does not work with gstreamer distributed on my Jetson: 1.2.4
So it seems it’s a problem that gstreamer did fix at one point, but the main distro hasn’t been updated yet.
I have compiled gstreamer and all Jetson related modules from source on the Jetson at version 1.7.2, however there seems to be a bug when trying to use the nvomxh264dec element, more can be found about that here:
https://devtalk.nvidia.com/default/topic/922934/omxh264dec-from-source-produces-4-greyscale-interleaved-tiles-of-the-actual-image/
I followed all instructions given by nvidia to compile their gstreamer modules from source, yet I still can’t get decoding to work correctly. Does anyone have a verified working version of gstreamer at a newer version?
Would it be possible to get nvidia to have an officially supported updated version of gstreamer for the Jetson platform?
Hi dtmoodie,
By further checking with the team, the coming release will still ship with gstreamer-1.2.4. But user can build and install gst-1.8 manually. Our plugins have been tested to be working with gst-1.8.
Thanks
Newer version of gstreamer could work. Could you comment on the issue in https://devtalk.nvidia.com/default/topic/922934/omxh264dec-from-source-produces-4-greyscale-interleaved-tiles-of-the-actual-image/ ?
I’ve tried building your plugins from source and they weren’t working.
Would you clarify if your binary plugins work against 1.8 or if they need to be compiled from source against 1.8.
Hi dtmoodie,
We have verified the following command working fine with gst 1.8.0 on r21.5
gst-launch-1.0 filesrc location=a.h264 ! h264parse ! omxh264dec ! nvhdmioverlaysink
If you still see the issue, could you dump the h264 stream and share to us? We should be able to reproduce the issue with a.h264 replaced. Thanks.
I have tested many of the plugins with v.1.8 of gstreamer, as well as the latest stable release (v.1.10), and can verify that so far they work great for my project. Have not compiled the plugins from source, just used the available binaries that comes with the jetpack.
I would like to know if the Nvidia team will agree to maintain these plugins for future versions of gstreamer. If an incompatabillity issue will occurr with gstreamer 1.8 or 1.10, will the team fix it for the community?
Hi StefanKarlsson,
Ideally, if it is not a big change in architecture, NVIDIA plugins should work fine. But for TK1, we don’t have plan to maintain these plugins for future versions of gstreamer.
While I can still say that the pre-compiled plugins are working great for what I am doing, and that I enjoy the great work behind them :)
… there are documented issues with these plugins (for gstreamer 1.8) :
I will continue to use them, but will try with the fixes in the repo above, and go back to gstreamer 1.8.
For those who are new to how to get the plugins from Nvidia, the way I did it was just to copy the following (located in /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/, default by jetpack)
libgstomx.so,
libgstnveglglessink.so,
libgstnvcamera.so,
libgstnvvidconv.so,
libnvgstjpeg.so
… to wherever your new install of gstreamer will be. Building them from source with the fixes in above linked repo seems more sane however, will try that. Since I am pretty new to gstreamer (and Linux in general) perhaps there is something important that I am missing…
Also, if you build gstreamer 1.8 from source for l4t, there are dependency issues with alot of plugins. At the moment, I have to build “libsoup” as well, because the required version (2.48) is not present in any ubuntu 14.04 PPA. I dont have any extended list of these dependency issues, but I guess there be dragons here… I may have just been lucky to not run into them yet in the particular needs of my project…