Greetings! My name is Talbot - known in the community as "TBOT" - I'm new to these forums but I am not new to vMix. Additionally, I'm the head live stream engineer for a streaming service... and we have a large number of vMix licenses in use across the country!

I am running into a perplexing issue at a number of our venues as of late - and I'm trying to figure out if this is a vMix issue or an issue with Amazon IVS - which hosts our streaming platform's back end.

We use custom built rack systems which are pretty much identical in all of our venues across the country. We use the same stream settings (1080p - 30fps - 6000kbps, Keyframe interval of 2, CBR, Keyframe aligned, as well as some minor adjustments as IVS requests for settings.)

I am attaching our standard vMix stream settings (IVS standard) as well as what is received by IVS in Cloudwatch.

Stream Settings vMix.PNG (15kb) downloaded 3 time(s).
Stream Settings - Advanced vMix.PNG (17kb) downloaded 1 time(s).
AWS issue.png (43kb) downloaded 0 time(s).

Please notice that the keyframe interval in IVS is received at 4 instead of 2 - and that the bitrate is halved - in addition - the AVC profile seems to be received incorrectly

This only affects certain venues/streams, again - all at 30FPS for their master frame rate (thought we do have some at 60fps in special use cases). Other venues - which have identical set ups and show files - all report correctly with a keyframe of 2 - and a locked CBR bitrate of 6000. So whatever it is, it's throwing us off because it's not a problem we can reproduce from one venue to another. It seems to be completely random.

We are working with IVS to explore the issue being on their end, however I feel it only prudent to explore it possibly being an issue within vMix - and I wanted to inquire if anyone has any thoughts on why this may be happening - or if they are experiencing it themselves.

The problem is - we are running into issues with low latency streaming as it seems to deeply depend on the keyframe being interpreted properly. This bug has been a show stopper a few times, especially when utilizing ultra low latency systems as when the keyframe is not received correctly, we experience skips, hiccups, repeating... and generally show stopping issues on the receiving end. We've been circumventing the issue by using higher latency when this happens as it seems to not be so susceptible to the issue but I don't want this to continue to be our Band-Aid.

Thanks in advance for any thoughts or solutions you may have! Cheers!

Hmm, can you give me some insight as to why this may help? All of these systems are 3080 and 3090 Nvidia GPUs... and like I've said we use these same settings across the board.... Including using the hardware encoder... I'll certainly try it next time this pops up... but I'd like to understand the logic.

Thanks!

Thanks for this! This confirms my suspicion.

Further testing on this today actually - seems to point to this being the possible culprit - however - I am unable to replicate it on purpose. It only seems to happen randomly - whether the settings are mismatched or not - however after matching everything back up between stream settings and external outputs and restarting my stream seems to fix it in 2 instances today.

What's annoying is I can't get it to break on purpose to confirm - I try to set the external output settings incorrectly and it doesn't break it... *facepalm*

Is there any official documentation on this that I've clearly missed? ...or is this one of those things I had to come across organically?

I finally managed to recreate and fix this bug.

I wasn't just needing to match up framerates - I also needed to change the stream server by a single character and then back to get the settings to take hold. Without doing that, the problem persisted.

Here is a Gdrive folder containing 3 videos on this bug - how I finally recreated it, and solved it. Please watch in numerical order.

https://drive.google.com...h_H91_YZZioj?usp=sharing

@admin - this seems like something vMix support may want their eyes on. It's clearly a bug.

Thanks for everyone's help in narrowing down this issue - really top notch!

Thanks for such a prompt reply!

Interesting as it doesn't request a restart after changing these external framerate settings - and that makes sense as the stream settings likely recalls the commands required to set these things correctly... though maybe not a bug per say - it's interesting that it doesn't warn you or request a restart.

I'll keep in mind that restarting after any setting change is best practice in general - as up until this point I have only restarted the software when I am requested... and changing the external framerate doesn't request a restart.

It would be nice if it did however as this is anything but obvious... and many of us have been chasing our tail on it for a minute.

Additionally, we did check "use stream settings" as this is default in all of our venues. Typically we don't even use the external feature except in a few select cases - and in those cases I've received warnings about mismatched framerates...

I know this isn't the feature request section but any chance of getting this flagged? Maybe a pop up that notifies the user that if the frame rate on external is not matched to the master frame rate that it can cause keyframe and bitrate issues such as this? Or even easier? Request a restart when the external settings are changed? That would solve it too.

Thanks a ton once again!

Kindest regards!

p.s. the next time this issue crops up i'll be sure to follow these restart steps and see if that helps. In my experience it didn't - but I want to confirm that before submitting a bug report at this point. Cheers!