Operating system; Edition: Windows 10 Pro / Version: 20H2 / OS Build: 19042.508 / Windows Feature Experience Park: 120.2212.31.0
OBS Studio version: 25.0.8 (64-bit, windows)
OBS Studio needs to close and destroy the SRT listener port after you do one of the following;
After the SRT Port is successfully destroyed (closed) and if it's still visible then OBS Studio needs to start listening again (srt mode listener) on said port.
OBS Studio doesn't destroy(close) and "if" still visible reopen the SRT port after SRT caller disconnects, you have to fully close OBS Studio and start it back up again to regain access to the port SRT used.
(I have opened and forward ports)
srt://127.0.0.1:30000?mode=listener into 'Input' field.mpegts into the 'Input Format' field.The srt-live-transmit does this normally so I don't know why this wasn't implemented when adding SRT support for the Media Source 馃
Please fill in the issue template, including reproduction steps especially.
also add as an info the obs version tested. It might be worth testing with 26 rc2 since there's been fixes with Media Source. The issue rests solely on Media Source (which relies on ffmpeg libs)
Sorry I should've know, the issue has been updated.
you might want to try the other way; have the Media Source be a caller. But test rc2 first.
I have a HDMI Encoder with SRT support, I want to be able to send Video & Audio from this HDMI Encoder to OBS and if I disconnect the HDMI Encoder from OBS due to a connection issue I want to be able to reconnect when I am able to.
Trying rc2 now.
what's the encoder ?
You can find the encoder on Amazon here >> DDMALL HEV-4K
oh interesting device; thanks
I am also able to reproduce this on OBS 26.0.2 using the Larix Broadcaster app as my SRT caller.
it might be related to this issue: http://trac.ffmpeg.org/ticket/8372
which is fixed in last ffmpeg build; this would require us to update the ffmpeg deps. It's scheduled for 26.1 release.
Most helpful comment
it might be related to this issue: http://trac.ffmpeg.org/ticket/8372
which is fixed in last ffmpeg build; this would require us to update the ffmpeg deps. It's scheduled for 26.1 release.