Enabled (but not connceted to) SRT listener hangs OBS when disabling again unless you can connect a sender to it first

[steve616]

If I setup an SRT listener on branch

e.g. srt:/0.0.0.0:11001?mode=listener
in my case, this was using NvENC H265 and it was a 4k stream.

Then click the eye to enaable it, it will start as expected. However if I then decide to stop it (with no sender attached) it just hangs OBS ( OBS 32.1.0 and 32.1.2 - both using branch 1.0.8 (same for 1.0.9)

If, when I start the stream, I connect a dummy pipeline to it e.g.
gst-launch-1.0 -v srtsrc uri="srt://127.0.0.1:11001?mode=caller&latency=2000" ! fakesink sync=false async=false

It shows live and I can disable the listener again without the hang..

Slightly changing the order, if I enable the listener and then disable it (Causing the hang), and then run the dummy subscriber gstreamer pipeline above, after a couple of seconds, it crashes OBS.

Slight differences in OBS 32.1.0 in that it just crashes without crash log or evidence and 32.1.2 actually provided a crash log.

Unhandled exception: c0000005
Date/Time: 2026-05-07, 09:19:00
Fault address: 7FFCF8E55277 (c:\program files\obs-studio\bin\64bit\w32-pthreads.dll)
libobs version: 32.1.2 (64-bit)
Windows version: 10.0 build 26100 (release: 24H2; revision: 32522; 64-bit)
CPU: AMD EPYC 7R13 Processor

Thread 2C54: audio-io: audio thread (Crashed)
Stack EIP Arg0 Arg1 Arg2 Arg3 Address
000000734529F810 00007FFCF8E55277 000001EC7AF13E60 000000734529F8B0 000000000000BB00 000001EC7F5414D0 w32-pthreads.dll!pthread_mutex_unlock+0x27
000000734529F850 00007FFCCD10726A 000000734529F9E0 000000734529F9E0 000CDAE71C129AA4 000001EC7F540F60 obs.dll!audio_pause_check+0xda
000000734529F880 00007FFCCD107318 0000000000000050 000001EC7FB2CD58 000000734529FA70 0000000000000000 obs.dll!receive_audio+0x98
000000734529F970 00007FFCCD188FB7 000001EC7FB8CDE8 0000000000000000 0000000000000400 000CDAE71D581FF9 obs.dll!do_audio_output+0x307
000000734529FAD0 00007FFCCD189440 000CDAE71D581FF9 000020E8B60DC134 00000000000A2400 000CDAE71D581FF9 obs.dll!input_and_output+0x240
000000734529FD10 00007FFCCD1895B0 0000000000000041 000020E8ADCD0D11 0000000000006178 FFFFFFFFFFFFFFFF obs.dll!audio_thread+0x120
000000734529FD70 00007FFCF8E51461 000001EC7F0779F0 0000000000000000 0000000000000000 0000000000000000 w32-pthreads.dll!ptw32_threadStart+0x171
000000734529FDE0 00007FFCFEB437B0 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ucrtbase.dll!0x7ffcfeb437b0
000000734529FE10 00007FFD0090E8D7 0000000000000000 0000000000000000 000004F0FFFFFB30 000004D0FFFFFB30 kernel32.dll!0x7ffd0090e8d7
000000734529FE40 00007FFD0152C53C 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffd0152c53c

Thread B38:
Stack EIP Arg0 Arg1 Arg2 Arg3 Address
0000007341EFB6B8 00007FFD016027C4 000001EC9F302000 000001EC9F39D010 0000000000000000 0000000000000000 ntdll.dll!0x7ffd016027c4
0000007341EFB6C0 00007FFCFEE52533 0000000000000000 0000000000000000 0000000000000000 0000000000000002 kernelbase.dll!0x7ffcfee52533
0000007341EFB9B0 00007FFCFEE52401 0000000000000000 00000000FFFFFFFF 0000000000000001 0000000000000000 kernelbase.dll!0x7ffcfee52401
0000007341EFB9F0 00007FFCF8E541A9 0000000000000000 0000007341EFBAB0 000001EC7B1936E0 000001EC7B2DEB00 w32-pthreads.dll!ptw32_cancelable_wait+0x69
0000007341EFBA60 00007FFCF8E5821C 000001EC7F540F50 000001EC7B2DEB00 0000000000000001 00007FFCFEBA9266 w32-pthreads.dll!pthread_join+0x1ec
0000007341EFBAE0 00007FFCCD189D09 000001EC9F8287C0 000001EC7F540F60 000001EC7B1936E0 000001EC7B1936E0 obs.dll!audio_output_close+0x49
0000007341EFBB30 00007FFCB9D233F5 0000007341EFBC00 0000000000000001 00000000FFFFFFFF 000001EC0C0DF700 osi-branch-output.dll!AudioCapture::~AudioCapture+0x45
0000007341EFBB60 00007FFCB9D124FE 000001EC7B193988 000001EC7B193988 0000007341EFBC60 0000000000000000 osi-branch-output.dll!FilterAudioCapture::`scalar deleting destructor'+0x1e
0000007341EFBB90 00007FFCB9D18064 000001EC7B193988 000001EC7B193988 0000007341EFBC60 000001EC7B1936E0 osi-branch-output.dll!BranchOutputFilter::releaseInfrastructureIfIdle+0x84
0000007341EFBBC0 00007FFCB9D18A50 000001EC7B193988 0000000000000000 000001EC7B1936E0 000001EC7B1936E0 osi-branch-output.dll!BranchOutputFilter::stopOutput+0x60
0000007341EFBBF0 00007FFCB9D16813 0000000000000003 0000000000000004 000001EC7A86E810 0000000000000000 osi-branch-output.dll!BranchOutputFilter::onIntervalTimerTimeout+0xe73
0000007341EFBC90 00007FFCCA4DB588 000001EC7B2DEB00 00007FFC00000003 0000000000000003 000001EC00000001 qt6core.dll!0x7ffcca4db588
0000007341EFBDC0 00007FFCCA4DE0A4 000001EC7A6BE8B0 0000007341EFBEA9 0000007341EFC200 0000007341EFBF00 qt6core.dll!0x7ffcca4de0a4
0000007341EFBDF0 00007FFCCA4F61AE 0000007341EFBED0 00007FFCCA49E930 0000007341EFC200 000001EC7F6E8E20 qt6core.dll!0x7ffcca4f61ae
0000007341EFBE30 00007FFCCA4E515C 000001EC0C106D00 000001EC0C136710 0000007341EFC200 000001EC7B2DEB00 qt6core.dll!0x7ffcca4e515c
0000007341EFBF10 00007FFCCB362EE7 000001EC0C106D00 0000007341EFC040 0000000000000000 000001EC0FC811D0 qt6widgets.dll!0x7ffccb362ee7
0000007341EFBF40 00007FFCCB362056 0000007341EFF900 000001EC7B2DEB00 0000007341EFC200 0000000000000000 qt6widgets.dll!0x7ffccb362056
0000007341EFC170 00007FFCCA49E91F 0000000008F20302 00007FFD01228B75 000001EC7B16DD30 000001EC0C958790 qt6core.dll!0x7ffcca49e91f
0000007341EFC1E0 00007FFCCA624558 0000000000000000 0000000000000001 0000000000000000 0000000076000012 qt6core.dll!0x7ffcca624558
0000007341EFC230 00007FFCCA62293C 0000000000000000 0000000000000001 0000000000000113 0000000000000000 qt6core.dll!0x7ffcca62293c
0000007341EFC320 00007FFD01227846 0000007341EFC538 00007FFCCA6223A0 0000000008F20302 0000000000000000 user32.dll!0x7ffd01227846
0000007341EFC480 00007FFD0122539D 0000007341EFC538 00000000000000A4 0000000000000000 0000000000000000 user32.dll!0x7ffd0122539d
0000007341EFC500 00007FFCCA6221EA 0000000000000000 0000000000000000 000001EC7B8A24D0 000001EC0C145090 qt6core.dll!0x7ffcca6221ea
0000007341EFF650 00007FFCCAD64189 00000000000000A4 000001EC7B8A24D0 000001EC0C106D00 0000000000000080 qt6gui.dll!0x7ffccad64189
0000007341EFF680 00007FFCCA4A5234 0000007341EFF720 000001EC0C0DF7D0 0000007341EFFCC0 0000000000000000 qt6core.dll!0x7ffcca4a5234
0000007341EFF700 00007FFCCA49CE62 00007FF7D189122C 000020E8A039F92D 0000000000000002 00007FF7D189122C qt6core.dll!0x7ffcca49ce62
0000007341EFF760 00007FF7D162C18A 0000007341EFFC00 0000000000000001 0000000000000001 0000000000000001 obs64.exe!run_program+0xc0a
0000007341EFFBC0 00007FF7D162CEB2 0000000000000002 0000000000000002 0000000000000001 000001EC0C0C895C obs64.exe!main+0x722
0000007341EFFDA0 00007FF7D16A1CF0 0000000000000001 0000000000000000 0000000000000000 0000000000000000 obs64.exe!qtEntryPoint+0x30
0000007341EFFE30 00007FF7D16A1402 0000000000000000 0000000000000000 0000000000000000 0000000000000000 obs64.exe!__scrt_common_main_seh+0x106
0000007341EFFE70 00007FFD0090E8D7 0000000000000000 0000000000000000 000004F0FFFFFB30 000004D0FFFFFB30 kernel32.dll!0x7ffd0090e8d7
0000007341EFFEA0 00007FFD0152C53C 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffd0152c53c

Thread 258:
Stack EIP Arg0 Arg1 Arg2 Arg3 Address
00000073422FF268 00007FFD016058C4 000001EC0C0C0000 000001EC00000000 000001EC7F079FD0 00000073422FF329 ntdll.dll!0x7ffd016058c4
00000073422FF270 00007FFD01534D4E 0000000000000000 000001EC30909F08 00000073422FF330 0000000000000003 ntdll.dll!0x7ffd01534d4e
00000073422FF310 00007FFCFEE52818 0000000000000000 00007FFCCD072ECF 0000000000989680 00007FFCCD072ECF kernelbase.dll!0x7ffcfee52818
00000073422FF350 00007FFCC973F56C 0000000000989680 000001EC7B7EAF70 00007FFCC9D78F20 000001EC00000000 advanced-scene-switcher-base.dll!0x7ffcc973f56c
00000073422FF390 00007FFCC9660FD8 00000073422FF530 000001EC79D7F400 0000000000000000 0000000059682CA8 advanced-scene-switcher-base.dll!0x7ffcc9660fd8
00000073422FF3D0 00007FFCC9660867 000CDAE7A4F70CC4 00000073422FF530 0000000000000001 000001EC7F5C4230 advanced-scene-switcher-base.dll!0x7ffcc9660867
00000073422FF450 00007FFCC98FE676 00000073422FF530 00007FFCCD07285B 000001EC7A13CC08 000001EC7F412201 advanced-scene-switcher-lib.dll!std::_Func_impl_no_alloc<advss::Macro::RunActionsHelper'::15'::<lambda_1>,void>::_Do_call+0x16
00000073422FF480 00007FFCC9B2C12C 000001EC7F412901 000001EC79D7F408 0000000000000000 000001EC7F5C3F30 advanced-scene-switcher-lib.dll!advss::Lockable::WithLock+0x2c
00000073422FF4C0 00007FFCC98FBD12 000001EC7F412260 00007FFCC98FEE3F 00000073422FF708 000001EC7F079D08 advanced-scene-switcher-lib.dll!advss::Macro::RunActionsHelper+0xf2
00000073422FF5D0 00007FFCC98F56A0 0000EC23A52A0B00 FFFFFFFFFFFFFFFE 00000073422FF708 00000073422FF6C8 advanced-scene-switcher-lib.dll!std::_Invoke_stored_explicit<advss::Macro::PerformActions'::31'::<lambda_1>,0>+0x20
00000073422FF600 00007FFCC98FD6A8 000001EC7F412260 00000073422FF620 0000D56CAC6EF4EA 000000007FFE0386 advanced-scene-switcher-lib.dll!std::_Packaged_state<void __cdecl(void)>::_Call_immediate+0x28
00000073422FF650 00007FFCC98FE4E3 000001EC7F079D00 00000073422FF708 000001EC7F079D00 000000007FFE0386 advanced-scene-switcher-lib.dll!std::_Func_impl_no_alloc<Concurrency::details::_MakeVoidToUnitFunc'::2'::<lambda_1>,unsigned char>::_Do_call+0x13
00000073422FF680 00007FFCC98FFE04 000001EC7F079D00 000001EC7F079D08 00000073422FF708 000001EC7F9A8C00 advanced-scene-switcher-lib.dll!Concurrency::details::_PPLTaskHandle<unsigned char,Concurrency::task::_InitialTaskHandle<void,std::_Task_async_state<void>::_Task_async_state<void><std::_Fake_no_copy_callable_adapter<advss::Macro::PerformActions'::`31'::<lambda_1> > >'::+0xe4
00000073422FF780 00007FFCC98FEFDD 000001EC7F079D00 0000000000000000 0000000000000000 0000000000000000 advanced-scene-switcher-lib.dll!Concurrency::details::_TaskProcHandle::_RunChoreBridge+0x1d
00000073422FF7C0 00007FFCC98FD6F1 000001EC7F079D30 00000073422FF930 00007FFCC9840000 000000007FFE0386 advanced-scene-switcher-lib.dll!Concurrency::details::_DefaultPPLTaskScheduler::_PPLTaskChore::_Callback+0x21
00000073422FF800 00007FFCCD072BE9 00000073422FFB28 00007FFCC9840000 000001EC7A13CC08 00000073422FFB28 msvcp140.dll!0x7ffccd072be9
00000073422FF830 00007FFD01515370 0000000000000000 0000000000000001 00007FFD0157A560 000001EC0C144A00 ntdll.dll!0x7ffd01515370
00000073422FF990 00007FFD015163C1 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffd015163c1
00000073422FFCF0 00007FFD0090E8D7 0000000000000000 0000000000000000 000004F0FFFFFB30 000004D0FFFFFB30 kernel32.dll!0x7ffd0090e8d7
00000073422FFD20 00007FFD0152C53C 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffd0152c53c

Thread 23C8:
Stack EIP Arg0 Arg1 Arg2 Arg3 Address
00000073423FF478 00007FFD016058C4 00000073423FF618 000001EC00000080 0000000000000000 00000073423FF539 ntdll.dll!0x7ffd016058c4
00000073423FF480 00007FFD01534D4E 0000000000000000 000001EC30909F08 00000073423FF540 000000000000000A ntdll.dll!0x7ffd01534d4e
00000073423FF520 00007FFCFEE52818 0000000000000000 00007FFCCD072ECF 0000000000989680 00007FFCCD072ECF kernelbase.dll!0x7ffcfee52818
00000073423FF560 00007FFCC973F56C 0000000000989680 000001EC7B7EBAB0 00007FFCC9D78F20 000001EC00000000 advanced-scene-switcher-base.dll!0x7ffcc973f56c
00000073423FF5A0 00007FFCC9660FD8 00000073423FF740 000001EC79D7F160 0000000000000000 000000003B9A6D6C advanced-scene-switcher-base.dll!0x7ffcc9660fd8
00000073423FF5E0 00007FFCC9660867 000CDAE786DDD40C 00000073423FF740 0000000000000004 000001EC7F87B3B0 advanced-scene-switcher-base.dll!0x7ffcc9660867
00000073423FF660 00007FFCC98FE676 00000073423FF740 00007FFCCD07285B 000001EC7B05D6A8 000001EC7F414201 advanced-scene-switcher-lib.dll!std::_Func_impl_no_alloc<advss::Macro::RunActionsHelper'::15'::<lambda_1>,void>::_Do_call+0x16
00000073423FF690 00007FFCC9B2C12C 000001EC7F413101 000001EC79D7F168 0000000000000003 000001EC7F6E8FA0 advanced-scene-switcher-lib.dll!advss::Lockable::WithLock+0x2c
00000073423FF6D0 00007FFCC98FBD12 000001EC7F414270 00007FFCC98FEE3F 00000073423FF918 000001EC1006EC88 advanced-scene-switcher-lib.dll!advss::Macro::RunActionsHelper+0xf2
00000073423FF7E0 00007FFCC98F56A0 0000EC23A53A0900 FFFFFFFFFFFFFFFE 00000073423FF918 00000073423FF8D8 advanced-scene-switcher-lib.dll!std::_Invoke_stored_explicit<advss::Macro::PerformActions'::31'::<lambda_1>,0>+0x20
00000073423FF810 00007FFCC98FD6A8 000001EC7F414270 00000073423FF830 0000D56CAC7EF6FA 000000007FFE0386 advanced-scene-switcher-lib.dll!std::_Packaged_state<void __cdecl(void)>::_Call_immediate+0x28
00000073423FF860 00007FFCC98FE4E3 000001EC1006EC80 00000073423FF918 000001EC1006EC80 000000007FFE0386 advanced-scene-switcher-lib.dll!std::_Func_impl_no_alloc<Concurrency::details::_MakeVoidToUnitFunc'::2'::<lambda_1>,unsigned char>::_Do_call+0x13
00000073423FF890 00007FFCC98FFE04 000001EC1006EC80 000001EC1006EC88 00000073423FF918 000001EC7F9A55A0 advanced-scene-switcher-lib.dll!Concurrency::details::_PPLTaskHandle<unsigned char,Concurrency::task::_InitialTaskHandle<void,std::_Task_async_state<void>::_Task_async_state<void><std::_Fake_no_copy_callable_adapter<advss::Macro::PerformActions'::`31'::<lambda_1> > >'::+0xe4
00000073423FF990 00007FFCC98FEFDD 000001EC1006EC80 0000000000000000 0000000000000000 0000000000000000 advanced-scene-switcher-lib.dll!Concurrency::details::_TaskProcHandle::_RunChoreBridge+0x1d
00000073423FF9D0 00007FFCC98FD6F1 000001EC1006F010 00000073423FFB40 00007FFCC9840000 000000007FFE0386 advanced-scene-switcher-lib.dll!Concurrency::details::_DefaultPPLTaskScheduler::_PPLTaskChore::_Callback+0x21
00000073423FFA10 00007FFCCD072BE9 00000073423FFD38 00007FFCC9840000 000001EC7B05D6A8 00000073423FFD38 msvcp140.dll!0x7ffccd072be9
00000073423FFA40 00007FFD01515370 0000000000000000 0000000000000000 00007FFD0157A560 0000000000000000 ntdll.dll!0x7ffd01515370
00000073423FFBA0 00007FFD015163C1 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffd015163c1
00000073423FFF00 00007FFD0090E8D7 0000000000000000 0000000000000000 000004F0FFFFFB30 000004D0FFFFFB30 kernel32.dll!0x7ffd0090e8d7
00000073423FFF30 00007FFD0152C53C 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffd0152c53c

[steve616]

I might be wrong, but I think the crash stack stack implicates osi-branch-output.dll audio teardown via AudioCapture::~AudioCapture, with the final fault in w32-pthreads.dll!pthread_mutex_unlock.

[hanatyan128]

Investigation report

I traced the hang and crash through both the plugin source and the corresponding OBS Studio source paths. Here is what I found.

Symptom recap

1. Hang: enabling the SRT listener output (mode=listener) and then disabling it before any peer has connected freezes the OBS UI thread.
2. Crash: while in that hung state, connecting a peer (the dummy GStreamer pipeline) causes OBS to crash a few seconds later.
3. The crash log of 32.1.2 has the audio thread crashing at obs.dll!receive_audio -> obs.dll!audio_pause_check+0xda -> w32-pthreads.dll!pthread_mutex_unlock+0x27, while the UI thread (B38) is blocked in osi-branch-output.dll!releaseInfrastructureIfIdle -> ~AudioCapture -> obs.dll!audio_output_close+0x49 -> pthread_join.

Hang root cause

The hang originates in the OBS obs-ffmpeg-mpegts plugin's listener stop path:

1. ffmpeg_mpegts_start spawns a start_stop_thread running start(). For SRT in listener mode, start() reaches connect_mpegts_url -> libsrt_open -> libsrt_setup -> libsrt_listen -> srt_accept, which blocks indefinitely until a peer connects (the URL srt://0.0.0.0:11001?mode=listener does not specify listen_timeout).
2. When this plugin calls obs_output_stop (via stopStreamingOutput), libobs ends up in ffmpeg_mpegts_stop_internal, which executes:

   pthread_join(to_join, NULL);   // joins the start thread that is stuck in srt_accept

   The OBS UI thread is parked here until the listener accepts a peer.

This is fundamentally an OBS-side blocking behavior; the plugin cannot cancel the join from the outside.

Crash root cause

When a peer eventually connects, srt_accept returns and the previously-blocked sequence unwinds, but it triggers a use-after-free against the audio encoder's pause.mutex:

1. After srt_accept returns, start_stop_thread finishes start(): ffmpeg_mpegts_finalize -> write_thread spawned -> obs_output_begin_data_capture -> hook_data_capture -> start_audio_encoders -> obs_encoder_start -> add_connection -> audio_output_connect. The audio encoder is now an input on this filter's private audio_t, so the audio worker thread starts calling receive_audio(encoder, ...).
2. The UI thread's pthread_join unblocks. ffmpeg_mpegts_stop_internal spawns a new stop thread and returns. The plugin then runs streamings[i].output = nullptr, which triggers obs_output_destroy.
3. Inside obs_output_destroy, obs_output_actual_stop(force=true) calls os_event_reset(output->stopping_event) and re-enters ffmpeg_mpegts_stop, creating a tight race with the in-flight stop thread and the (just-spawned) end_data_capture_thread that is responsible for calling obs_encoder_stop -> remove_connection -> audio_output_disconnect.
4. Under that race the encoder ends up still being a live input on the audio_t when control returns to releaseInfrastructureIfIdle.
5. src/plugin-main.cpp#L846-L854 currently does:

   audioContext->encoder = nullptr;     // (1) destroy encoder, including pause.mutex
   if (audioContext->capture) {
       delete audioContext->capture;     // (2) audio_output_close (joins audio thread)
   }

   obs_encoder_destroy does NOT call audio_output_disconnect (it only removes the encoder from output arrays and then destroys its mutexes, including pause.mutex).
6. While pthread_join in step (2) is waiting for the audio thread, that thread is still iterating mix->inputs and calls receive_audio(<freed encoder>) -> audio_pause_check -> pthread_mutex_lock succeeds on stale memory but pthread_mutex_unlock fails on the destroyed mutex -> crash.

So the observed crash is a use-after-free: the encoder is destroyed while the audio_t still references it as an input.

Recommended fixes

A. Mitigate the hang (plugin side)

Two practical options:

1. Inject a default listen_timeout into SRT listener URLs. When the plugin sees mode=listener in the SRT URL and no listen_timeout is present, append e.g. &listen_timeout=5000000 so that srt_accept returns with a timeout instead of blocking indefinitely. This unblocks pthread_join in ffmpeg_mpegts_stop_internal.
2. Special-case stop while the slot is still in the "starting" phase. The plugin already tracks BranchOutputStreamingContext::outputStarting. We could route stops in that state through a different path that does not rely on obs_output_stop to drain the start thread, but this still has to face obs_output_destroy's force-stop, so it is only a partial mitigation.

(1) is the most reliable mitigation that the plugin alone can ship.

B. Fix the crash (plugin side)

Swap the release order in releaseInfrastructureIfIdle:

pthread_mutex_lock(&audioMutex);
{
    OBSMutexAutoUnlock audioLocked(&audioMutex);

    for (size_t i = 0; i < MAX_AUDIO_MIXES; i++) {
        auto audioContext = &audios[i];

        // Drain the audio worker first so the encoder's pause.mutex /
        // callbacks remain valid during the worker's final iteration.
        if (audioContext->capture) {
            delete audioContext->capture;     // audio_output_close: joins audio thread
            audioContext->capture = nullptr;
        }
        audioContext->encoder = nullptr;      // safe now: audio thread is gone
    }
}

I verified this is safe from the AudioCapture side:

• AudioCapture::~AudioCapture calls audio_output_close, which signals stop_event and joins the worker thread synchronously. During the join the encoder is still alive, so audio_pause_check's lock/unlock pair both operate on a valid pause.mutex.
• SourceAudioCapture::~SourceAudioCapture and MasterAudioCapture::~MasterAudioCapture already remove their respective OBS-side audio capture callbacks before the base destructor runs, and those removal APIs are synchronous against in-flight callbacks (they take the same mutex as the dispatch path), so no pushAudio can race with audio_output_close.
• FilterAudioCapture::pushAudio is gated by audioMutex, which releaseInfrastructureIfIdle holds throughout the loop, so the filter audio path cannot race with delete capture either.
• After audio_output_close the encoder->media pointer is briefly dangling, but obs_encoder_destroy never dereferences it (it does not call audio_output_disconnect), so the subsequent encoder destroy is safe.
• Lock ordering (pluginMutex -> outputMutex -> audioMutex) is unchanged.

A residual theoretical risk exists: if end_data_capture_thread somehow did not run, encoder->callbacks could still hold pointers to a destroyed obs_output_t, and the worker's last iteration could call into them via send_audio_data -> do_encode -> cb->new_packet(<stale output>). However, this is not a regression introduced by the swap; it is a pre-existing condition of the same end_data_capture failure that produced the original crash. In practice, obs_output_destroy waits on stopping_event set by end_data_capture_thread, which calls obs_encoder_stop and clears the callbacks before returning, so this path should not be hit.

Summary

• The hang is owned by libobs's ffmpeg_mpegts_stop_internal joining a start thread that is stuck in srt_accept. The plugin can mitigate it by enforcing listen_timeout in listener-mode URLs.
• The crash is a use-after-free in this plugin: releaseInfrastructureIfIdle releases the encoder before closing the private audio_t, so the audio worker can still call receive_audio on a freed encoder. Swapping the release order so the audio_t is closed first eliminates this specific crash without introducing new races on the AudioCapture side.

---

Investigated with Claude Code (Opus 4.7).