Bug Report Bitrate Drops Significantly Mid Stream

[Daniel J. Lewis]

As noted earlier in this thread, the exact previous working version was 0.15.1.

I now see there's a version 0.18.0.1 for macOS (I never received an update notification in the app), so I'll give that a try before I downgrade to 0.15.1.

 

[RytoEX]

As noted earlier in this thread, the exact previous working version was 0.15.1.

I now see there's a version 0.18.0.1 for macOS (I never received an update notification in the app), so I'll give that a try before I downgrade to 0.15.1.

I would guess that you didn't get an update notification because the file that serves the version info for OBS Studio was never updated to indicate a new macOS version. I'll admit that I'm not overly familiar with the update mechanisms for non-Windows versions, so I may be wrong about that.

The QSV streaming issues, if that's what this is, were, as far as I know, fixed in OBS Studio 0.16.6 (this commit), which was never officially released for macOS. OBS Studio 18.0.1, which is available for macOS, should have those fixes as well. If this is the same issue, anyway.

• Fixed a bug when using the QSV encoder where if frames were dropped due to network issues, frames would not stop dropping.

 

[Osiris]

That release note is not relevant, that's for the regular QSV encoder, not the VT one.

As noted earlier in this thread, the exact previous working version was 0.15.1.

I now see there's a version 0.18.0.1 for macOS (I never received an update notification in the app), so I'll give that a try before I downgrade to 0.15.1.

0.15.1 contains the exact same version of the VT plugin as 0.16 and 18.0.1

 

[RytoEX]

That release note is not relevant, that's for the regular QSV encoder, not the VT one.

0.15.1 contains the exact same version of the VT plugin as 0.16 and 18.0.1

Okay then. Hmm. The symptoms just seem extremely similar. Is it possible that the VT code was affected by the same streaming code that affected the regular QSV code? That's how the regular QSV issue came up. The "offending" commit was this one, and Jim applied the fix to plugins/obs-qsv11/obs-qsv11.c after I pinpointed that commit by running through a bisect with an affected user. Could plugins/mac-vth264/encoder.c also be having a bad interaction with the RTMP change? If not, then I'm at a loss.

 

[Osiris]

Could be, though would be weird if both implementations suffer from the same issue.

 

[RytoEX]

Stranger things have happened.

If I recall correctly, the easiest way to trigger the bad behavior was to cause congestion on your Internet connection while streaming. According to my notes, loading up several web pages at once was the easiest way to do this. If we could get an affected Mac user to test VT streaming with OBS Studio 0.15.4 and 0.16.0, that might help show if this just another manifestation of the p-frame dropping code. Since there aren't official Mac builds for those releases anyway, it might be easier if they could test builds based on commits 7d5df34 and 34590b4. If there's a relatively easy way to build Mac releases on Windows/Linux, I could try to provide those builds to rule out/in this theory. If I'm right, we know where to look. If I'm wrong, then maybe someone can run through a new bisect if nothing else comes to mind.

 

[Daniel J. Lewis]

Switching to x264 did, indeed, prevent the problem from happening. Sadly, that means my CPU is under more load, and I have more audio sync issues, but that's better than streams failing within 15 minutes.

 

[tienld]

Stranger things have happened.

If I recall correctly, the easiest way to trigger the bad behavior was to cause congestion on your Internet connection while streaming. According to my notes, loading up several web pages at once was the easiest way to do this. If we could get an affected Mac user to test VT streaming with OBS Studio 0.15.4 and 0.16.0, that might help show if this just another manifestation of the p-frame dropping code. Since there aren't official Mac builds for those releases anyway, it might be easier if they could test builds based on commits 7d5df34 and 34590b4. If there's a relatively easy way to build Mac releases on Windows/Linux, I could try to provide those builds to rule out/in this theory. If I'm right, we know where to look. If I'm wrong, then maybe someone can run through a new bisect if nothing else comes to mind.

After modify code (version 21.1.2): comment line 1072 "check_to_drop_frames(stream, true);" in function "static bool add_video_packet(struct rtmp_stream *stream,struct encoder_packet *packet)" of file "rtmp-stream.c", i compiled code on my Mac, and problem gone! I can use Apple VT H264 hardware encoder without drop in mid stream (after about 10 mins on my Macbook) like before. I think "p-frame dropping code" has problem. Code version 0.15.1 don't have "p-frame dropping code".

 

[c3r1c3]

Can you issue a PR for this?

 

[RytoEX]

@c3r1c3
Making a PR of what they outlined would effectively remove an entire code branch. While it is helpful as a diagnostic, that is probably not an appropriate fix.

I've been working on getting something together, but I want to confirm with one of the active contributors with a macOS system that it actually works before submitting it (I don't have a macOS system). That has been slow going.

 

[Locksmith]

So...any update on a release for this? Because i haven't been able to use OBS for streaming for a whlie now.

 

[RytoEX]

So...any update on a release for this? Because i haven't been able to use OBS for streaming for a whlie now.

No. I have yet to be able to get my patch tested on a Mac, and I'm not (currently) capable of producing a full macOS build myself. At present, I need someone who can both build and test on a Mac that is actually capable of using the hardware encoder.

 

[Locksmith]

I'm willing to help, what do I have to do?

 

[RytoEX]

I'm willing to help, what do I have to do?

@Locksmith
You would need to be able to compile a patched OBS Studio for macOS and run the custom build on a system that is capable of using the VideoToolbox H264 encoder and try streaming to see if it breaks or not. The easiest way I know of to "break" a VTH264 stream is to introduce network congestion by loading up a bunch of web pages at once. If all of that sounds like something you can do, send me a PM.

 

[TheLogicDump]

@Locksmith
You would need to be able to compile a patched OBS Studio for macOS and run the custom build on a system that is capable of using the VideoToolbox H264 encoder and try streaming to see if it breaks or not. The easiest way I know of to "break" a VTH264 stream is to introduce network congestion by loading up a bunch of web pages at once. If all of that sounds like something you can do, send me a PM.

I am a software developer (though mainly Linux focused) and appear to be having this issue so would love to test out your proposed bug fix. Send me a message :)

 

[dan_k]

@RytoEX @TheLogicDump I've been reading this thread with interest because I wanted to try using the Apple VT encoder for streaming to Facebook. I found that I get better motion encoding and lower CPU usage with the VT encoder vs. the software encoder, and Facebook seems to handle VBR OK.

After a few minutes though, the OBS indicator goes red, and Facebook reports that it's not receiving a stream. I seemed to be able to induce this to happen by moving my camera around a *lot* to generate more motion. I didn't try purposefully degrading my network connection. I tried bitrates of 2500, 3000, 3500 and 4000 and experimented with a few different maximum bitrate settings. The only way to get it working again is to stop and restart streaming.

I'm not a software developer but I'm comfortable at the CLI and have a rudimentary understanding of building/compiling stuff, so if there's any way I can help with testing please let me know.

Edit: Will test again and post a log ;)