Bug: caller needs to be off to receive SRT stream on listener mode.

[Sidonai-1]

Observed Behavior

When trying to receive a SRT stream PLAY 1-10 "srt://192.168.0.220:8004?mode=listener&transtype=live&latency=200", if the caller is already sending frames when I try to grab it, it doesn't work, throws this error:

[2025-04-25 11:27:06.882] [info]    Received message from 127.0.0.1: PLAY 1-10 "srt://192.168.0.220:8004?mode=listener&transtype=live&latency=200"\r\n
[2025-04-25 11:27:06.883] [info]    Sent message to 127.0.0.1:202 PLAY OK\r\n
[2025-04-25 11:27:24.742] [warning] [ffmpeg] [mpegts @ 000001714872F480] Could not find codec parameters for stream 0 (Video: hevc (HEVC / 0x43564548), none): unspecified size
[2025-04-25 11:27:24.742] [warning] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[2025-04-25 11:27:24.742] [warning] 
[2025-04-25 11:27:24.763] [error]   [ffmpeg] [buffer @ 00000171230A62C0] Unable to parse option value "0x0" as image size
[2025-04-25 11:27:24.763] [error]   
[2025-04-25 11:27:24.763] [error]   [ffmpeg] [buffer @ 00000171230A62C0] Error setting option video_size to value 0x0.
[2025-04-25 11:27:24.763] [error]   
[2025-04-25 11:27:24.763] [error]   [ffmpeg] [in_0 @ 0000017144F9A980] Error applying options to the filter.
[2025-04-25 11:27:24.763] [error]   
[2025-04-25 11:27:24.766] [error]   Exception: D:\a\server\server\src\modules\ffmpeg\producer\av_producer.cpp(486): Throw in function auto __cdecl caspar::ffmpeg::Filter::{ctor}::<lambda_8bee28624ecd543403dc975ac23b75cf>::operator ()(void) const
[2025-04-25 11:27:24.766] [error]   Dynamic exception type: class boost::exception_detail::clone_impl<struct caspar::ffmpeg::ffmpeg_error_t>
[2025-04-25 11:27:24.766] [error]   [struct boost::errinfo_api_function_ * __ptr64] = avfilter_graph_create_filter( &source, avfilter_get_by_name("buffer"), name.c_str(), args.c_str(), nullptr, graph.get())
[2025-04-25 11:27:24.766] [error]   [struct boost::errinfo_errno_ * __ptr64] = 22, "Invalid argument"
[2025-04-25 11:27:24.766] [error]   [struct caspar::ffmpeg::tag_ffmpeg_errn_info * __ptr64] = -22
[2025-04-25 11:27:24.766] [error]   [struct caspar::tag_stacktrace_info * __ptr64] =  0# 0x00007FF7CF462D57 in casparcg
[2025-04-25 11:27:24.766] [error]    1# 0x00007FF7CF48DAC6 in casparcg
[2025-04-25 11:27:24.766] [error]    2# 0x00007FF7CF5D625E in casparcg
[2025-04-25 11:27:24.766] [error]    3# 0x00007FF7CF5D1CFA in casparcg
[2025-04-25 11:27:24.766] [error]    4# 0x00007FF7CF5D8D6B in casparcg
[2025-04-25 11:27:24.766] [error]    5# 0x00007FF7CF5D9C43 in casparcg
[2025-04-25 11:27:24.766] [error]    6# 0x00007FF7CF5D6977 in casparcg
[2025-04-25 11:27:24.766] [error]    7# 0x00007FF7CF6A14B3 in casparcg
[2025-04-25 11:27:24.766] [error]    8# configthreadlocale in ucrtbase
[2025-04-25 11:27:24.766] [error]    9# BaseThreadInitThunk in KERNEL32
[2025-04-25 11:27:24.766] [error]   10# RtlUserThreadStart in ntdll
[2025-04-25 11:27:24.766] [error]   
[2025-04-25 11:27:24.766] [error]   

[2025-04-25 11:27:24.766] [error]    0# 0x00007FF7CF462D57 in casparcg
[2025-04-25 11:27:24.766] [error]    1# 0x00007FF7CF4627E5 in casparcg
[2025-04-25 11:27:24.766] [error]    2# 0x00007FF7CF74BABD in casparcg
[2025-04-25 11:27:24.766] [error]    3# _CxxFrameHandler4 in VCRUNTIME140_1
[2025-04-25 11:27:24.766] [error]    4# 0x00007FFAB7952572 in VCRUNTIME140_1
[2025-04-25 11:27:24.766] [error]    5# RtlCaptureContext2 in ntdll
[2025-04-25 11:27:24.766] [error]    6# 0x00007FF7CF5D6977 in casparcg
[2025-04-25 11:27:24.766] [error]    7# 0x00007FF7CF6A14B3 in casparcg
[2025-04-25 11:27:24.766] [error]    8# configthreadlocale in ucrtbase
[2025-04-25 11:27:24.766] [error]    9# BaseThreadInitThunk in KERNEL32
[2025-04-25 11:27:24.766] [error]   10# RtlUserThreadStart in ntdll

The only way I can make it work is if I open the CasparCG listener before I start the SRT stream on the sender side.

Forcing the listener to be 'waiting' before sending the stream can be a problem in certain workflows, forcing us to restart the sender. It means that if I need to restart CasparCG for some reason, I cannot get it back unless I restart the sender as well.

Also if the sender needs to be restarted CasparCG is also not able to reconnect the stream, it just says:

[2025-04-25 12:15:07.758] [warning] ffmpeg[srt://192.168.0.220:8004?mode=listener&transtype=live&latency=200|211.3600/0.0000] Waiting for audio frame...
[2025-04-25 12:15:18.206] [warning] ffmpeg[srt://192.168.0.220:8004?mode=listener&transtype=live&latency=200|211.3600/0.0000] Waiting for audio frame...
[2025-04-25 12:15:28.655] [warning] ffmpeg[srt://192.168.0.220:8004?mode=listener&transtype=live&latency=200|211.3600/0.0000] Waiting for audio frame...

But it never manages to retrieve the signal, forcing the same process again: turn off the sender, start the listener, then start sending frames again.

Expected behaviour

My point of reference testing this is ffplay,

ffplay "srt://192.168.0.220:8004?mode=listener&transtype=live&latency=200"

During similar tests, ffplay manages to catch the SRT 'automatically' if one side is restarted, and without needing a certain order of operations.

Environment

• Server version: 2.4.3
• Operating system: Windows 10