Sporadic issue with using gstreamer to send video frames to mediamtx via rtspclientsink

General Discussion
1

The following warning appears after sending what seems to be a random number of video frames. (no obvious pattern. e.g. 5, 6, 200+, 1000+, 5000+, etc). The video frames still can be received by mediamtx until the warning appears.

(abc.exe:20984): GLib-GIO-WARNING **: hh:mm:ss:miliseconds (../gio/goutputstream.c:398):g_output_stream_writev: run time check failed: (res || (error == NULL || *error != NULL))

Around the same time it appears, mediamtx would also provide this log.

INF [RTSP] [conn [::1]:50498] closed: read tcp [::1]:8554->[::1]:50498: wsarecv: An existing connection was forcibly closed by the remote host.

At this point, mediamtx would destroy the rtsp session and no more encoded video frames can be sent to mediamtx.

My gstreamer pipeline is as follows:

gchar* pipe = g_strdup_printf(

"appsrc name=src is-live=true ! video/x-raw,format=RGB ! "

"videoconvert ! video/x-raw,format=NV12,width=%d,height=%d ! "

"nvh265enc name=encoder preset=p6 tune=ultra-low-latenct bframes=0 gop-size=30 ! "

"video/x-h265,stream-format=byte-stream,alignment=au ! "

“rtspclientsink location=%s protocols=tcp latency=0”,

WIDTH,HEIGHT,RTSPURL);

My source provides RGB8 video frames.

Things tested:

  • The issue disappears when the rtspclientsink protocol=udp (the warning disappears and mediamtx no longer produces that log)

  • Tried adding h265parse with config-interval=1 (but the warning still appeared)

  • Changed the speed at which I supplied the video frames (1hz-20hz). The warning still eventually appeared.

  • When there is no receiver reading from mediamtx, the warning can still appear.

  • Tried adding queues after encoding/parsing with leaky=downstream but the warning still appeared.

  • Tried using x264enc (and the corresponding changes to use a 264 encoder) and the warning does disappear.

Any guidance for this matter would be appreciated. Thank you.

2

Hello @dav,

Have you tried enabling time-based timestamps in appsrc and checking whether the issue persists?

Since the issue only occurs with TCP, while MediaMTX reports that the remote host closed the connection, it would be useful to determine whether the RTSP connection is being terminated by the GStreamer side because of invalid or missing buffer timestamps.

As a first step, you could configure appsrc to use time-based timestamps:

g_object_set(appsrc,
    "is-live", TRUE,
    "format", GST_FORMAT_TIME,
    "do-timestamp", TRUE,
    NULL);

Or add the equivalent properties to the pipeline:

appsrc name=src is-live=true format=time do-timestamp=true ! \
video/x-raw,format=RGB ! \
videoconvert ! \
video/x-raw,format=NV12,width=...,height=... ! \
nvh265enc preset=p6 tune=ultra-low-latency bframes=0 gop-size=30 ! \
h265parse config-interval=-1 ! \
video/x-h265,stream-format=byte-stream,alignment=au ! \
rtspclientsink location=... protocols=tcp latency=0

If enabling timestamps avoids the disconnect, the issue is likely related to the timing information of the buffers pushed into appsrc. If it still occurs, the next step would be to collect a debug log around the disconnect to focus on the H.265 RTP packetization or the TCP RTSP output path:

GST_DEBUG=rtspclientsink:6,rtspconnection:6,rtph265pay:6

Please let me know how the test goes.

3

Hi @Julian_Camacho,

Thank you for your detailed reply. I really appreciate you taking the time to respond to this. However, my team’s priorities have shifted elsewhere, so I’m not sure when I’ll have any further updates to share but I will definitely keep your suggestion in mind if I do get back to this.