Streaming from ManyCam to YouTube directly results in significant bitrate drops as well as latency and high buffer. Also has significant popping audio.
Direct capture does not exhibit the problem (use ManyCam Lite Video Device as a camera source and direct to mic). Thus we know it’s an RTSP issue only and not our hardware.
Additional
After some troubleshooting, it was determined that for whatever reason, when NVenc is used, it is never maximized. This is a GTX 1060, so it’s more than capable of hardware encoding on the fly.
But when using Intel QuickSync, the bitrate comes in right around where we want it and remains consistent, and the latency is hardly ever more than 2 seconds, which is what we want.
Question
Why is this? NVenc should be much more efficient at this and it doesn’t seem to be, which makes me think that the software isn’t telling the card what it needs to know in order to fully use the power of it.
We haven’t tested other services because most of them allow us to just directly tap the hardware vs. RTSP. The only other one we know of is Twitch, and it also had the issue.
We’re now testing the “joined audio” mic option (which isn’t well documented) to see if that’s a viable alternative. Still remains the question why NVenc isn’t pumping the bitrate it should be.
If you face high latency and drop it is caused by network bandwidth in most cases. NVenc is unlikely a bottleneck if you run 1080p or below.
I would recommend to check your network and avoid wi-fi for streaming (use cable if possible).
Also, latest ManyCam 8 and Lite have increased RTMP chunck size that may reduce required network bandwidth up to 2 times compared to ManyCam 7, maybe this is your case.
Already running latest ManyCam Lite. Not the issue.
Only stream 1080p/30, so that’s not the issue.
NVenc is perfectly fine on other software - so no, it’s ManyCam specific.
Also doesn’t answer why the bitrate tanks to 1k using NVenc and does not with Intel QuickSync on the same hardware and configuration.
Something’s wrong with the NVenc implementation somewhere and it’s unusable.
For now, I have a workaround using loopback for audio, so I’ll just revert to using ManyCam as a ‘dumb’ video signal until it’s fixed (like the inability to resize windows bug)
OK, I’ll check NVenc. BTW here is the good tool to check your stream health/bandwidth: https://inspector.twitch.tv/
Sounds unpolite, but if QuickSync works fine for you why just don’t use it? Asking because I have a theory that you run ManyCam on NVidia GPU and add all nice things like VB or something and you consume a lot of NVidia GPU bandwidth (to transfer video back and forth GPU). Thus adding encoder make the situation even worse and it starts lagging. So using another GPU for encoding is always a good idea. Please share GPU uitilization for NVidia like:
Because I’m not a fan of leaning on workarounds when (as a technologist myself) the best answer is to fix what’s not working.
NVenc works fine in pretty much every other tool without issue.
ManyCam (Lite or otherwise) appears to be the only tool that’s having a problem.
Thus, something with how ManyCam (Lite or otherwise) is using NVenc isn’t done optimally. I don’t know what it is. I don’t really care.
Normally, I would tell the developers to fix it. Figure out what to do to make it optimized.
Like, if I look at OBS, right…and I see OBS (free) isn’t struggling, why is it acceptable to accept a workaround on ManyCam which I’m paying for? It’s not.
The reason I prefer ManyCam is (besides paying for it) that it’s more visually intuitive to do things and our use case is overly simplistic such that OBS is overkill.
But (putting my “company” hat on) it simply isn’t acceptable to tolerate anything less than the best performance out of your software nor is it acceptable to steer paying customers to implement workarounds rather than fixing bugs. I’m sorry.
