Home        Store        Docs        Blog

Gstreamer in win10


(Vagelis Chalkiadakis) #1

Hi there.

I would like to have an additional video streaming window in my PC, independently from QGC (which works fine).

I have downloaded Gstreamer v.1.5.2, and I have created a .bat file as follows:

@echo off
cd C:\gstreamer\1.0\x86\bin
gst-launch-1.0 -e -vvv udpsrc port=5600 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

However no video window appears…

All I get to CLI window is:

WARNING: no real random source present!
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstAutoVideoSink:fps-display-video_sink/GstD3DVideoSink:fps-display-video_sink-actual-sink-d3dvideo: sync = false
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

Any ideas?

Thanks in advance,
Vagelis


(Jacob) #2

This works for me in linux. Have you tried running that command while qgc is not running?

 

This one also works for me

gst-launch-1.0 -e -v udpsrc port=5600 ! application/x-rtp, payload=96 ! rtph264depay ! avdec_h264 ! autovideosink
-Jacob

(Vagelis Chalkiadakis) #3

Hello Jacob and thank you for your answer.

The same command works fine on a linux machine - you have to disconnect qgc to get video screen.

Just tried both commands (yours and mine) after having first closed qgc and worked perfectly.

So the key here was that I should have firstly close qgc.

A couple of additional questions:

  1. Is there a way to run qgc and gst-launch in parallel?
  2. How can I save the streaming video in a file?
Thanks in advance,

Vagelis


(Jacob) #4

Vagelis,

This command will run the video in a separate window, as well as qgc, and save the video to file. You need to set QGC to look at a different port, like 5700. This can be done in the latest daily builds, at the bottom of the ‘General’ tab when you click the Q icon in the upper left.

gst-launch-1.0 -e -v udpsrc port=5600 ! tee name=STREAMOUT ! tee name=VIDEOWINDOW ! queue ! application/x-rtp, encoding-name=H264, payload=96 ! rtph264depay ! h264parse ! mp4mux ! filesink location=/path/to/save/myvideo.mp4 STREAMOUT. ! queue ! udpsink port=5700 VIDEOWINDOW. ! queue ! application/x-rtp, payload=96 ! rtph264depay ! avdec_h264 ! autovideosink

-Jacob


(Vagelis Chalkiadakis) #5

Wow! Thanks! I will try it and let you know the results!

Vagelis


(Vagelis Chalkiadakis) #6

Thanks again Jacob.

Works perfectly!

The only problem I see is that the file it produces is huge (250 MB for 1:38)

Is there a way to compress it more?

Vagelis


(Vagelis Chalkiadakis) #7

Hi again Jacob.

Suddenly both commands you provided are not working anymore.
The video screen shows a green screen.

FYI, when I open QGC the video shows perfectly.

The above is true on both Linux and Windows.

Any ideas?

BR,
Vagelis


(Vagelis Chalkiadakis) #8

Somehow the problem was disappeared!
I don’t know why, but now (6 days after) it works again!


(Vagelis Chalkiadakis) #9

@jwalser
Although in linux the command-line you proposed works fine, in windows-10 I get an error message:

ERROR: from element /GstPipeline:pipeline0/GstQueue:queue1: Internal data flow error.
Additional debug info:
gstqueue.c(970): gst_queue_handle_sink_event (): /GstPipeline:pipeline0/GstQueue:queue1:
streaming task paused, reason error (-5)

Any ideas?


(Jacob) #10

Is that the entire output after you enter the command, or is there more before the error bit? Try doing gst-inspect-1.0 queue on both machines and compare the output, particularly the version of the plugin.

-Jacob


(Vagelis Chalkiadakis) #11

Hi Jacob and thanks for your response.

I am not in my lab, so I will reply tomorrow with additional data.
Out of my memory I can tell that before that in both machines it says something about opening pipelines etc.

I’m not sure i understand how to use “gst-inspect-1.0 queue” though (but I’ll give it a try and let you know the results).

V.


(Altum Operations) #12

Hi @jwalser

Would I be able to run this same code in GStreamer on my OS X machine?
Regards,
Tobin Cox


(Jacob) #13

If you have gstreamer installed, yes, I believe so.

-Jacob


(Vagelis Chalkiadakis) #14

@jwalser
Hi again Jacob.

So here are the gst-inspect-1.0 queue" results:

Linux Debian PC:
queue gst plugin version: 1.4.4

Win10 PC:
queue gst plugin version: 1.5.2

In the meanwhile, as I was digging, I stopped having video signal in both QGC and gstreamer and in both machines (Win10 and linux) …
IP addresses are ok, 5600 port is used, QGC / gstreamer don’t run in parallel.
QGC remains with “no-video” (5600 udp port is used) and gstreamer does not open the video window.
When QGC runs, I can control the ROV (e.g. i can change flight mode, compass and art. horizon work ok)

Any ideas?

This is what I get on the linux machine:
$ gst-launch-1.0 -e -v udpsrc port=5600 ! application/x-rtp, payload=96 ! rtph264depay ! avdec_h264 ! autovideosink
Setting pipeline to PAUSED …
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_36
libva info: va_openDriver() returns 0
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock

And this is what I get on the Win10 machine with the same cmd-line:
WARNING: not real random source present!
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock

Vagelis


(Jacob) #15

Try this troubleshooting section to check on the Pi side if the camera is working.

-Jacob


(Vagelis Chalkiadakis) #16

Troubleshooting revealed the problem (loose camera cable connection @Raspberry board), and now QGC shows video.

@jwalser: However i still cannot get video signal using the “tee” command on Win10. The only message i receive when giving the command is the same as above:

WARNING: not real random source present!
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock

The file “myvideo.mp4” is created but it is empty

Also, if i give the single video streaming command:
gst-launch-1.0 -e -v udpsrc port=5600 ! application/x-rtp, payload=96 ! rtph264depay ! avdec_h264 ! autovideosink

the video window shows up and video is shown perfectly right.

UPDATE: for @jwalser / maybe @rjehangir should have a look?
It looks that the problem was not the (what I thought) loose cable.
Video starts and stops at will in random time intervals.
And when it works, the above commands work perfectly.

I followed troubleshooting - without success.
I changed camera cable, and the camera itself without success.
So I return to my first thought: can it be a software problem caused by a “sudo rpi-update” for example?
Please help, as it drives me crazy…
An additional “clue” may be that when i ordered a rpi-update, it finishes with the following:

*** Updating firmware
*** Updating kernel modules
*** depmod 4.4.48-v7+
*** depmod 4.4.48+
*** Updating VideoCore libraries
*** Using HardFP libraries
cp: cannot create regular file ‘//opt/vc/bin/raspivid’: Text file busy

Vagelis


(Jacob) #17

Try doing sudo rpi-update without the streaming process running. To stop the streaming process, do sudo screen -X -S video quit.

Let me know if anything changes.

How are you determining this, do you see video starting and stopping in a videosink window or QGC? Which command are you referring to?

-Jacob


(Vagelis Chalkiadakis) #18

Thanks @jwalser

I will try tomorrow (our time) your proposal.

Answering your question:
trying both gst-launch commands in both win10 and linux systems, the stream sometimes starts and then stops, sometimes starts after some delay and then stops, sometimes never starts (in approx 10 minutes).

The same is true with QGC in both PCs, while telemetry works perfectly all the time.

That’s why I thought ti was the camera or the camera-cable. I replace both with similar results.

Let’s hope it is the incomplete rpi-update. Otherwise the only thing I have not replace is Raspberry and its software…
We will know in the next 14-15 hours :wink:

Thanks for your support,
Vagelis


(Vagelis Chalkiadakis) #19

@jwalser: Problem solved Jacob!!
The incomplete rpi-update was the real problem for all the above.

The only remaining issue (was not an issue in the past when we were using the “daily” QGC versions) is that I cannot make QGC 3.1.2 to look @port 5700 (where the gst-launch tee the video stream)

Thanks a lot Jacob!
I really appreciate your “first class” support!

Vagelis


(Jacob) #20

Interesting on the point of 3.1.2, I still have this option in Ubuntu, what operating system are you using? An alternative would be to edit the video launch script on the pi to send the stream from the raspberry pi to a different port, then tee it to 5600.