Stable connection via External RTSP (>30min)

Solved
robbyf
Conversationalist

Stable connection via External RTSP (>30min)

Hi Meraki Team,

 

we are using MV22 and MV32 to generate an external RTSP link that we consume using our own software.

 

We currently experience a stability issue that the RTSP stream eventually stops working.

This is happening for example when using VLC with `:network-caching=1000` after maybe 30min.

Other implementations using Gstreamer have similar issues. Increasing latency to several seconds mitigates the problem but does not solve it for longer periods (>30min)

 

https://documentation.meraki.com/MV/Advanced_Configuration/External_RTSP says that no metadata is attached, which may indicate that we are missing information in order to setup the stream correctly. In Gstreamer, we are using tcp for connection.

 

ny more information regarding the strem would be greatly appreciated!

1 Accepted Solution
PhilipDAth
Kind of a big deal
Kind of a big deal

That sounds like a bug.  Are you using a current stable MV firmware or better?

 

If you are using up to date firmware, I would open a support case.

View solution in original post

4 Replies 4
robbyf
Conversationalist

Just to add some info here. Using ffplay via tcp, I get significant, intermittent videoqueuing (vq) as shown in the log here:

 

C:\Users\XXXX>ffplay rtsp://XXX.XXX.XXX.XXX:9000/live -rtsp_transport tcp
ffplay version N-106799-g0914e3a14a-20220505 Copyright (c) 2003-2022 the FFmpeg developers
built with gcc 11.2.0 (crosstool-NG 1.24.0.533_681aaef)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --enable-shared --disable-static --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --enable-libmfx --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --disable-libdrm --disable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra-version=20220505
libavutil 57. 24.101 / 57. 24.101
libavcodec 59. 27.100 / 59. 27.100
libavformat 59. 23.100 / 59. 23.100
libavdevice 59. 6.100 / 59. 6.100
libavfilter 8. 37.100 / 8. 37.100
libswscale 6. 6.100 / 6. 6.100
libswresample 4. 6.100 / 4. 6.100
libpostproc 56. 5.100 / 56. 5.100
Input #0, rtsp, from 'rtsp://XXX.XXX.XXX.XXX:9000/live': 0B f=0/0
Metadata:
title : www rtsp live
comment : LIVE555 Streaming Media v2017.01.26
Duration: N/A, start: 0.033333, bitrate: N/A
Stream #0:0: Video: h264 (High), yuvj420p(pc, smpte170m, progressive), 1280x720, 8 fps, 8 tbr, 90k tbn
[swscaler @ 00000250b7356a00] [swscaler @ 00000250b7365a00] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 00000250b7356a00] [swscaler @ 00000250c09c0740] deprecated pixel format used, make sure you did set range correctly
488.76 M-V: 0.091 fd= 329 aq= 0KB vq= 2062KB sq= 0B f=0/0

vq was upt to 5MB.

After >10min, the video output is stuck, queues are empty and the M-V value keeps decreasing to larger, negative numbers (-34 and increasing).

 

ffplay generates the following SDP when connecting to the stream:

v=0
o=- 1676523757369165 1 IN IP4 127.0.0.1
s=www rtsp live
i=LIVE555 Streaming Media v2017.01.26
t=0 0
a=tool:LIVE555 Streaming Media v2017.01.26
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:www rtsp live
a=x-qt-text-inf:LIVE555 Streaming Media v2017.01.26
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=Z2QAH6y0AoAt0rBgYGQO5rKA7msoADaFCag=,aO4G4sA=
a=control:track

 

PhilipDAth
Kind of a big deal
Kind of a big deal

That sounds like a bug.  Are you using a current stable MV firmware or better?

 

If you are using up to date firmware, I would open a support case.

robbyf
Conversationalist

I was on MV4.18, updated to MV5.0 and now it appears to be running >1hr without problem or noticeable lag so far.

 

Sometimes it can be that easy, thank you.

JustLowVoltage
New here

I'm troubleshooting the same issue in that the streams disconnect from VLC. I am to achieve fairly long streams (2-3hrs) but they always drop. Confirmed running 5.0 across all MV devices.

Get notified when there are additional replies to this discussion.