Open kenkeiter opened 6 years ago
kenkeiter
commented
6 years ago Also wanted to note that I was able to validate my encoding setup a little further. By streaming with the following command:
gst-launch-1.0 videotestsrc pattern=ball ! x264enc ! rtph264pay ! udpsink host=127.0.0.1 port=5600I am able to watch the ball video in VLC player by using an .sdp file with the following contents:
v=0
m=video 5600 RTP/AVP 96
c=IN IP4 127.0.0.1
a=rtpmap:96 H264/90000
DonLakeFlyer
commented
6 years ago You're better off with this stuff on Gitter where there are more video people. Since it is most likely a setup problem as opposed to a QGC bug.
kenkeiter
commented
6 years ago @DonLakeFlyer If you feel that, given the information above, it's still a setup issue, I'll certainly give that a shot. Thank you.
If you don't mind, I'd like to leave the ticket open for just a while until I verify w/the Gitter folks. I'm suspicious, given the facts:
But I've certainly been wrong before, and I'd love to be wrong now 😅
lbegani
commented
6 years ago The error is perhaps due to unsupported format by QGC. QGC doesnt support all the formats supported by gstreamer but limited few
kenkeiter
commented
6 years ago I wanted to note that @lbegani resolved my issue, which was caused by incorrect documentation. The test command listed in the video streaming doc suggests using the following command to test locally:
gst-launch-1.0 videotestsrc pattern=ball ! x264enc ! rtph264pay ! udpsink host=127.0.0.1 port=5600This is incorrect. The following command may be used, instead.
gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480 ! videoconvert ! x264enc ! rtph264pay ! udpsink host=127.0.0.1 port=5600When I have a second, I'll submit a PR to resolve the issue. This issue should probably remain open until that time.
Thanks again for your help, @lbegani! 🎊 💯
jaxxzer
commented
6 years ago The command in the documentation is correct. If 0.0.0.0 works, but 127.0.0.1 does not, I suspect something is up with your network configuration. I'm not sure what would cause this, what's your OS?
kenkeiter
commented
6 years ago @jaxxzer Nothing's up with my network config. The unicast address is not the only thing in the aforementioned command that changed -- an additional item was added to the pipeline (video/x-raw,width=640,height=480). Changing the unicast address back to 127.0.0.1 works as well, given that QGroundControl binds to 0.0.0.0 (all IP addresses on the local machine) when listening for UDP/RTP video.
I have updated my suggested doc change to revert back to using 127.0.0.1 as the host address. My apologies; that part of the change was unnecessary.
Also, @jaxxzer, thanks for taking the time to take a look 👍 Seems like a well-staffed/maintained open-source project!
jaxxzer
commented
6 years ago Hm, the original command works fine for me on Ubuntu, so does your proposed amendment.
kenkeiter
commented
6 years ago @jaxxzer Yeah, no idea why it wouldn't on macOS. Software, amirite?
When using qgroundcontrol (macOS
10.12.4, Qgroundcontrol versions3.2.4anddaily) in conjunction with the instructions in the video streaming guide, display of video fails due to an "internal data flow error."I've tried the example
gstreamerpipelines in the documentation (and verified that I'm seeing streamed data usingnc). I've also tried variations with different h264 encoders to ensure that I'm not just seeing issues with the way a specific encoder has been built for macOS.I installed gstreamer and associated plugins using the following:
Please let me know if I can be of service in debugging. The log output was as follows (for both versions):
(the aforementioned log excerpt repeats)