ffmpeg failed during dry run flight

[kendra]

We got the tracking to work several times, even though we were having connectivity issues.

We were able to stream when it was on the ground and lost the connection when it was about 5000 ft. 

Whenever I would try to start the stream again, each time, it would start to load and lock up like this:


C:\Users\Ground Station>cd..



C:\Users>cd..



C:\>cd ffmpeg



C:\ffmpeg>cd bin



C:\ffmpeg\bin>ffmpeg -i rtsp://192.168.1.3:8554/ -c copy -f flv - | ffmpeg -f flv -i - -c copy -f rtp://localhost:4000 -c copy -f flv rtmp://media.stream.live:1935/live/f6a2b7f9-a3cd-41a1-8b2c-8a84395f2045

ffmpeg version 3.3.1ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers

built with gcc 6.3.0 (GCC)

configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib Copyright (c) 2000-2017 the FFmpeg developers



libavutil 55. 58.100 / 55. 58.100 built with gcc 6.3.0 (GCC)



libavcodec 57. 89.100 / 57. 89.100 configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib



libavformat 57. 71.100 / 57. 71.100 libavutil 55. 58.100 / 55. 58.100



libavdevice 57. 6.100 / 57. 6.100 libavcodec 57. 89.100 / 57. 89.100



libavfilter 6. 82.100 / 6. 82.100 libavformat 57. 71.100 / 57. 71.100



libswscale 4. 6.100 / 4. 6.100 libavdevice 57. 6.100 / 57. 6.100



libswresample 2. 7.100 / 2. 7.100 libavfilter 6. 82.100 / 6. 82.100



libpostproc 54. 5.100 / 54. 5.100 libswscale 4. 6.100 / 4. 6.100



libswresample 2. 7.100 / 2. 7.100

libpostproc 54. 5.100 / 54. 5.100



Do you think this was a problem with not having a good enough data stream?

Kendra

[Skylar MSGC]

It could be, you could have lost connection to the payload as well. Ffmpeg will die if there is a loss in connection, it doesn't deal with timeouts very nicely.

[rmungin]

Skyler - Us at PSU were having this problem also. We are able to connect and stream our video - but the resulting video is low quality and choppy. The longest we were able to keep the stream running was ~40. When you are talking about losing connection do you mean loss in connection with the ground station or is this an internet connectivity issue?

[Skylar MSGC]

I'm talking about from ground station to payload. Having a steady connection to the internet would help the quality going to the website. If you were viewing this on VLC at the address rtp://localhost:4000/ you should be able to see the video pretty decently.

If you have a bad connection to the internet it would get a little choppy on stream's website.

[irowe]

I had this exact issue as well- until I realized there was a problem with my connection from the computer to the ground station modem.

The connection from ground station to payload was fine, and the connection from the computer to the internet was fine, but my connection with the ground station modem was interrupted (In my case, I was using a USB-to-Ethernet adapter and hadn't set a static IP. Whenever I switched to the Ethernet port I usually use, the command went through.)

I would make sure you can adequately communicate with your ground station and haven't changed anything there.

[Meggr]

We also had issues with the ffmpeg losing connection. We think the issue is power. When we connect a separate 12V source we get good quality results. Now if we can only get that to work in the air... Thanks for all the comments here - it helps a lot.

[Skylar MSGC]

Meggr,
I would double check your jumper on the power board to make sure that it isn't on the 5V setup instead of the 12V setup for the M5 output. Those m5 modems require a 8W supply and at 5V you are using 1.6A which is substantial output for those lithium batteries. Where at 12V you have .75A which is with operational capability for those batteries

[Meggr]

The problem is definitely in the power board. We had the streaming working just fine with the original power board (12V jumper in place). But during testing on Wednesday the video kept dropping out. Now that I have a known 12V applied via the POE to the modem it has run perfectly for over 2 hours.