ATEM Mini + Decklink = no 24fps Premiere Pro Mecury transmit

Hi folks, I have a real head scratcher here.

I am running an SDI output from my Windows 10 (64bit) PC via a BMD Decklink Extreme PCIe card. This feed then routes through a BMD SDI to HDMI converter, where the SDI loop-out goes to my client monitor and the HDMI out goes into the BMD ATEM Mini. I additionally have another HDMI input from my GPU running into the ATEM Mini as a second feed.

What I want to achieve is a feed from Premiere Pro with both the main timeline (GPU screen capture) and the program feed (Decklink video feed via Mercury Transmit), all while maintaining a program feed to the client monitor in my suite.

And it works. At all frame-rates except for 24 fps timelines out of Premiere. Which is our only frame rate for our projects.

Now interestingly enough, the feed to the client monitor still works fine in 24fps. It just seems to kill any picture through the ATEM. The Mini will successfully stream the Program feed at 25, 29.97. 30, 50, heck even 60 fps - no problems. Just will not give me picture at 23.97 or 24 fps.

Could someone please offer me some suggestions on how to remedy? Throw them at me. I have pulled the set up apart several times, swapped the HDMI inputs to try and re-lock the fps in the switcher, tried new cables, uninstalled and reinstalled the drivers, OS and Adobe - no success.

As you can imagine, this is in an effort to COVID-proof a project and put the director as much on set with us as possible - it should be possible but it's just not working.

Lastly, we have hundreds of selects timelines that would be a punish to switch over to 25fps (as well as opening us up to a world of potential niggly problems down the track - human error for the win), so moving to 25fps as a solution to stream would be an absolutely last resort.

Thanks for your time, I would appreciate any suggestions.

I don't have any magic remedies, but here are a few suggestions for troubleshooting:

1. Set the ATEM video standard explicitly via the ATEM Software Control panel to either 1080p24 or 1080p23.98 (depending on which of these you actually need to use).
2. Avoid using HDMI input 1 to the ATEM Mini for testing as this input is often handled specially for video standards detection purposes. Use inputs 2-4 instead.
3. Connect input sources to the ATEM one at a time so that you can troubleshoot each input source independently and get it working before moving on to the next one.
4. Send the ATEM a resolution and frame rate that does work (e.g. 1080p60) and let it do the standards conversion (to 1080p24). This may not be ideal from a viewing perspective, depending on how clean the frame rate conversion is.
5. Get a video standards converter such as a Blackmagic UpDownCross HD or Decimator MD-HX so that you can convert the video resolution/frame rate from your video outputs to the exact video standard you are running the ATEM at.

In your case, I might actually recommend springing for the Decimator MD-HX over the UpDownCross HD. Even though it is a bit more expensive, it has a small LCD screen that displays the resolution and frame rate of the incoming video source. This will allow you to determine exactly what video formats you are dealing with, which is often invaluable when troubleshooting.

Keep in mind that a lot of devices are a bit fuzzy with their handling of 1080p23.98 vs. 1080p24 video, often labeling things as 1080p24 when they are actually 1080p23.98, for example. But these two standards are definitely not the same as the frame rates are different.

Also, be aware that with HDMI connections (unlike SDI) there is a negotiation (EDID) that happens between the source and sink device in an attempt to settle on a signal format compatible with both ends. This is the source of a range of problems and often means that the actual signal being sent over HDMI may not exactly match the desired (or configured) output format. In contrast, SDI is a one-way signal flow, so whatever you tell an SDI device to output, that is what it will send.

Also, be aware that with HDMI connections (unlike SDI) there is a negotiation (EDID) that happens between the source and sink device in an attempt to settle on a signal format compatible with both ends. This is the source of a range of problems and often means that the actual signal being sent over HDMI may not exactly match the desired (or configured) output format. In contrast, SDI is a one-way signal flow, so whatever you tell an SDI device to output, that is what it will send.

I was unaware of how this handshake took place, valuable knowledge.

I will take a further look into the Decimator MD-HX and proceed with your sugested troubleshooting today. By-passing port #1 makes sense, hopefully there is a gem amongst these new steps.

Thanks very much for your suggestions Dave.