[BUG] Restart a stream doesn't work anymore in OBS Studio #2865
Comments
|
What RTMP server are you streaming to? |
|
MistServer |
|
i can confirm, same issue with flussonic rtmp server |
|
The same issue is happening with Flussonic Media Servers, the exact same issue. 21:30:54.208: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://xx-xx/static... |
|
I can confirm such issue also occur when using Castr multistreaming service. The error log also ends at
In our case, we have the same issue since v25.0 and all the way up to v25.0.8 |
This reverts commit 2b131d2. Trying to keep state in the RTMP structure wasn't working well and was introducing regressions such as obsproject#2865. This commit moves mbedTLS initialization to obs_module_load, which is the only place we can guarantee that loading / freeing occurs on the same thread.
This reverts commit 2b131d2. Trying to keep state in the RTMP structure wasn't working well and was introducing regressions such as obsproject#2865. This commit moves mbedTLS initialization to obs_module_load, which is the only place we can guarantee that loading / freeing occurs on the same thread.
|
Same issue with Flussonic media server |
|
I'm running into problems on v25.0.8 properly reconnecting to an nginx-rtmp-module streaming server. It sometimes will reconnect but other times will not. I am using |
|
Hi there! MistServer dev here. In short: please reset the librtmp internal state in between reconnect attempts, as fixing this on the media server side will break other client implementations instead. |
|
Oh, I've been trying to find the culprit to this for ages... Google served me no luck and yet it was reported here all along! I'm glad the cause was narrowed down and I wasn't just going crazy. Hopefully it's an easy fix! |
|
I found that my issue was not this problem but was caused by #3078. |
|
I've tested it on master and it still can't connect after one disconnect. And in the rtmp server logs: After increasing And after connecting for the 2nd time it just get's stuck at connecting. |
|
Any updates on this? |
|
I have updated to 26.0.0 this morning and it seems as if the bug is gone! There have been tons of bugfixing in the version so I'm not sure if this was one of them, or one of them was tangential to this issue and was fixed as consequence, nonetheless I couldn't find it mentioned in the changelogs at first glance. I think we can set this as "solved" if anyone can confirm it was fixed? |
|
This wasn't explicitly fixed in v26, but I can also confirm it's no longer crashing. One of the unrelated commits might be masking the issue. |
|
From what I understand it's not exactly the same bug, I saw the ticket you linked back in July but thought the behaviour fit better this issue here rather than that one. Nonetheless, it could be! |
|
Looking at the changes, I don't think that particular pull request fixed this particular bug. |
|
Hi all, unfortunately I do have and see the same problem in v26.0.0.
12:54:50.186: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3 Downgraded to v24.0.3 and all is good again. |
|
It seems either I was having a different issue or the tangential fix only solved it for specific situations and not in the general case, I'd think. Still doesn't seem to me like #3078, my issue was perfectly described by the above and I do remember checking the logs gave me almost the same messages. On the other hand it could also be that the servers I'm streaming to now (Picarto.tv) just changed on their end, the same day version 26.0.0 came up for me. |
|
@Banderi As I am one of the people maintaining the streaming software on Picarto's servers, I can confirm that we implemented a workaround for this OBS bug months ago. OBS will work there, despite this bug being present. You're welcome. |
|
Upgraded to v26.1.0 but still the same issue as before, can someone else check and comment. |
It'd be nice if you'd share us what workaround you did because that bug still exists. |
What server software are you streaming to? |
I describe the exact problem + how to fix it, here: #2865 (comment) EDIT: For reference, this is the exact code of our workaround: DDVTECH/mistserver@b45fd85 Just to be clear: this is 100% a problem in OBS, and easily fixable. Unfortunately I don't know the OBS code base enough to contribute a fix, but using my earlier post it should take a knowledgeable developer no more than a few minutes to fix this problem. Server-side software can work around it (as we have done), but that's not how this should be resolved at all. |
|
When I raised this potential bug 2th of May 2020 (#2849) it was ignored and closed with a comment that the issue is on server side. A new case was opened 4th of May asking for a deeper investigation before just closing the ticket. |
|
Hi Newbie here.. The newest versions of OBS caused me GREAT GRIEF! I was live-streaming a New Year's Eve event (to Mistserver), and had to constantly keep rebooting the program when the stream was interrupted (in my case due to exceeding my own bandwidth issues). Every time it hung, I also had to shutdown a persistent OBS in task manager too, which added to my troubles. The video essentially was unreliable. I had no idea what "I" was doing wrong.. only to learn later the program is broken. The issue that prevents the OBS program from "start > stop > restarting" again.. also prevents the "auto-reconnect" from working as well. To duplicate the issue, just temporarily physically pull the network connection, then reconnect.. OBS will hang indefinitely. Through much forum searching I discovered that someone posted that earlier versions (up to) 24.03 still worked fine, which I found to be the case for me too. After that version, they no longer work correctly. I tried the most recent version 26.1.1 and it failed like the others. I'm back with 24.03 which works great. (should note I found the same issue on both 32 & 64 bit machines) Workaround: I've found with newer OBS versions that if I setup the stream with udp://ip:port/streamname/live.. it continues streaming (even with network interruptions). I don't know if using UDP for live streaming is a bad idea or not ... (I'm pretty new to video streaming) but it seemed to work, I assume since the stream (in this case) doesn't actually stop or disconnect. |
|
Tagging this to look at before v27. The fix for this is not simple, which is why we have not fixed it yet. The problem exists deep in librtmp and we haven't sorted out exactly what or where, and it's also difficult to replicate without access to a deployed custom RTMP server, which makes testing cumbersome. |
|
@Fenrirthviti A cursory glance at the source code tells me uncommenting this line should do the trick. Full explanation: Should this not be enough to solve the issue, I'd be happy to provide an RTMP endpoint for you to test against (without workarounds, so the bug triggers). Though I believe practically all streaming services are affected by this bug. It looks like the problem was introduced in this commit, which fixed a thread safety issue in librtmp but also commented out the line in question (probably because it also initializes the TLS context). Splitting the TLS init and the RTMP state init into two separate functions should resolve that cleanly. |
|
Doing that breaks RTMP authentication, which is why we have not just uncommented it. A different fix needs to be found. |
|
Might need more info if a back and forth of "can't do that" is to be avoided. How does that break authentication, and why does that only happen on versions of librtmp above the ones before that commit? As far as I can tell, this has been going on for ages with no proper response while Thulinma and others have been giving the closest to a transparent explanation of what's going on, and piecing together how to fix it. Moreover, this only happens in OBS and it only happens after said commit, and there wasn't another major issue like this one beforehand; so either literally no other streaming app uses librtmp, or they use a patched version/correct implementation, or whatever issue was solved by the commit is a compromise they are willing to accept. |
|
@Banderi I understand that it seems like there is "no proper response" but we don't really have anything to report. It's been acknowledged, and we're looking in to how to properly fix it. I don't have the technical knowledge to explain the specifics, I will leave that to @notr1ch, but my understanding is that any attempted fixes have broken other parts of librtmp because of the thread safe issues referenced in that commit. Have the proposed fixes been tested in OBS and all conditions and features that change might affect also been tested (which is really every single librtmp function that OBS uses to ensure there's no other potential regressions)? If so, why is there no PR for the fix? If there is a solution that has been properly vetted and tested, then it should be submitted as a PR so we can review and verify. |
|
@Fenrirthviti thanks for the full response. From what I'm seeing it's only surface speculation, even though I'm sure there's enough experience to be able to find the cause if given time and chance on their part (and again closest to explanation of what's going on than what has been given yet, which is more than we could ask for). That said, again I must stress I really find strange that this happens only in OBS and only after said commit, and no other streaming app has this issue. It doesn't add up to me. You say it's a deeper problem with librtmp itself, which means there is indeed info that could be provided (if who you mentioned would have time to respond of course). What is the actual issue? Can you please provide a link to a ticket on their trackers, if it's been reported? |
|
I'll post a pull request after I get out of the office today with a clean solution that won't break threading or encryption. I figure that's the fastest way to get this fixed. Expect it somewhere in the next 10 hours or so, I'll link back to this issue to make sure it's found. |
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with.
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with.
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with.
|
Thanks for the PR, definitely the fastest way to get the ball moving. I'll make some time in the next few days to run through testing and make sure things that were causing issues previous are not affected. |
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with. Fixes obsproject#2865
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with. Fixes #2865
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with. Fixes obsproject#2865
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end. This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library. The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with. Fixes obsproject#2865
Platform
Operating system and version: Windows 10 v1909 64bit
OBS Studio version: v25.0.8
Expected Behavior
Start Streaming = start the stream (it's ok and works today)
Stop Streaming = stop the stream (it's ok and works today)
Start Streaming again after a stop = shall start the stream as task 1 as with OBS Studio v24.0.3
Current Behavior
Start Streaming = start the stream (it's ok and works today)
Stop Streaming = stop the stream (it's ok and works today)
Start Streaming again after a stop = stream doesn't start, control button "Start/Stop Streaming" is totally grey and I can't do any thing with this button. Exit OBS studio works but the program still runs in background and process task need to be ended via Windows task manager. Thereafter can OBS Studio be started and used again until next stop.
OBS Studio v25.0.8 part of log file when issue occur
11:29:13.744: ---------------------------------
11:29:13.744: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3
11:29:13.744:
11:29:13.746: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://192.168.0.174/live/...
11:29:13.750: [rtmp stream: 'adv_stream'] Interface: Intel(R) 82574L Gigabit Network Connection (ethernet, 1000 mbps)
11:29:16.507: [rtmp stream: 'adv_stream'] Connection to rtmp://192.168.0.174/live/ successful
11:29:16.514: ==== Streaming Start ===============================================
11:29:52.048: [rtmp stream: 'adv_stream'] User stopped the stream
11:29:52.048: Output 'adv_stream': stopping
11:29:52.048: Output 'adv_stream': Total frames output: 880
11:29:52.048: Output 'adv_stream': Total drawn frames: 957
11:29:52.053: ==== Streaming Stop ================================================
11:29:52.116: warning: 2 frames left in the queue on closing
11:32:28.898: [jim-nvenc: 'streaming_h264'] settings:
11:32:28.898: rate_control: VBR
11:32:28.898: bitrate: 2500
11:32:28.898: cqp: 20
11:32:28.898: keyint: 125
11:32:28.898: preset: llhq
11:32:28.898: profile: high
11:32:28.898: width: 1920
11:32:28.898: height: 1080
11:32:28.898: 2-pass: false
11:32:28.898: b-frames: 2
11:32:28.898: lookahead: false
11:32:28.898: psycho_aq: true
11:32:28.898:
11:32:28.920: ---------------------------------
11:32:28.921: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3
11:32:28.921:
11:32:28.922: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://192.168.0.174/live/...
11:32:28.923: [rtmp stream: 'adv_stream'] Interface: Intel(R) 82574L Gigabit Network Connection (ethernet, 1000 mbps)
11:32:28.927: HandleInvoke, error decoding invoke packet
Steps to Reproduce
Start Streaming = start the stream
Stop Streaming = stop the stream
Start Streaming again after a stop = stream doesn't start
Additional information
Tested both v24.0.3 and v25.0.8 / uninstalled and installed 3 times and totally left the server side.
Version 24.0.3 works as a charm every time but 25.0.8 fails on the second "Start Streaming" all the time.
I refer to closed case #2849 and ask for a investigation before closing this new support ticket.
The text was updated successfully, but these errors were encountered: