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
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.
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.
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).
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
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:
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
@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!
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.
