Qlab video output to SDI?

[Oskar Krogell]

Hi,

I tried searching but couldn't find a suitable answer.

Is there a way to convert the video signal going to the projector from a MBP13" to (HD/3G)-SDI somehow for use with Qlab? Apparently the BlacMagic and AJA TB->SDI boxes are not supported.
I'd prefer something that is simple and robust and tested.

Is there an easy way? Or do I have to go to DVI or HDMI first, then to SDI?

Thanks,
Oskar

[Paul Gotch]

On Mon, Nov 24, 2014 at 03:41:58AM -0800, Oskar Krogell wrote:
> Hi,
>
> I tried searching but couldn't find a suitable answer.
>
> Is there a way to convert the video signal going to the projector from a
> MBP13" to (HD/3G)-SDI somehow for use with Qlab? Apparently the BlacMagic
> and AJA TB->SDI boxes are not supported.

Certain BlackMagic boxes are supported in QLab 3 however using these
boxes directly means you are not using the GPU in the Mac to render
output which limits what you can do.

After some testing we bought one of these

http://www.rolandsystemsgroup.co.uk/products/100120

We drive it from the HDMI port on a MacMini but there's no reason it
shouldn't work from a MiniDisplayport to HDMI adaptor.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Sean Dougall]

Quick correction:

> Certain BlackMagic boxes are supported in QLab 3 however using these
> boxes directly means you are not using the GPU in the Mac to render
> output which limits what you can do.

This is not true. QLab still does all its rendering in OpenGL, which is processed by the GPU. It then copies pixels out of VRAM and into a RAM-backed pixel buffer, which it sends out to the Blackmagic device. So there is some extra overhead from those last two steps, but up until that point, everything in the rendering pipeline is identical to rendering on a regular video output.

If you’re curious to know more about the steps that happen before that point, I wrote it up in some detail here: http://figure53.com/notes/2014-08-12-qlab-3.1-video/

Cheers,
Sean

[Oskar Krogell]

Okay.

So DeckLink devices are supported in 3.1, but my case involves two MBP13" laptops. So DeckLink cards are out of the question, since they seem to be PCIe cards.. Correct me if I'm wrong, but I believe other BlackMagic devices, such as the UltraStudio Mini Monitor still do not work with Qlab?

So is my best option still to do MacBook MiniDisplayPort -> DVI and then a DVI -> SDI conversion?

Thanks,
Oskar

[Dave "luckydave" Memory]

On Monday, November 24, 2014 at 10:47 AM, Oskar Krogell wrote:

So DeckLink devices are supported in 3.1, but my case involves two MBP13" laptops. So DeckLink cards are out of the question, since they seem to be PCIe cards.. Correct me if I'm wrong, but I believe other BlackMagic devices, such as the UltraStudio Mini Monitor still do not work with Qlab?

The DeckLink API works with several different lines of Blackmagic devices, including UltraStudio. The Mini Monitor works well with QLab 3.1.

-- 

luck...@figure53.com

[Oskar Krogell]

The DeckLink API works with several different lines of Blackmagic devices, including UltraStudio. The Mini Monitor works well with QLab 3.1.

OK. Thanks. Will give it a try.

[Brian Mohr]

I wanted to come back to this thread because the mini monitor is a beautiful solution for getting SDI out which for a long time seemed not to have a native output solution.  Granted I don't keep up with QLab regularly. 

Can someone clarify who makes the DeckLink API (it's built into QL 3.1? or is a separate piece to be installed or?).  And then it is a device that can be applied to a surface despite not being desktop space?  This is news to me because I always understood QLab could only output to desktop space.  Thanks for any clarification. 

[Andy Lang]

On Tue, Dec 8, 2015 at 11:08 PM Brian Mohr <a2a...@gmail.com> wrote:

Can someone clarify who makes the DeckLink API (it's built into QL 3.1? or is a separate piece to be installed or?).  And then it is a device that can be applied to a surface despite not being desktop space?  This is news to me because I always understood QLab could only output to desktop space.  Thanks for any clarification. 

Hi Brian,

An API is a protocol that a hardware or software developer publishes to allow other hardware or software to communicate with their devices. So the DeckLink API is a command set that Blackmagic created that allows developers to give their software the ability to control and send data to/receive it from a number of Blackmagic devices.

QLab 3.1 added support for output via any Blackmagic device that supports the DeckLink API, and does indeed allow direct output to those devices, even though they don’t show up as displays to the OS.

That said, as I mentioned a couple weeks ago, this is rarely the ideal solution, and in all circumstances, you will always get better performance by taking one of the computer’s normal display outputs and converting it to SDI outside of the computer.

The reason for this is that, in both cases, the graphics rendering has to happen in the GPU. In the case of the built-in display connections, this data goes straight from the GPU to the output, which is a part of the graphics card. In the case of Blackmagic output, after it’s rendered, the GPU has to write it back to RAM, and then the CPU can push it out to the Blackmagic device. This extra round trip adds latency, and incrases the performance load dramatically.

For a real world example of this, look for Andrew Keister’s recent post, where he related a story of a recent high profile show I helped him with that had massive performance problems, even on a rather beastly Mac Pro cylinder, when using Blackmagic output. Switching to the HDMI output, and converting externally with a Blackmagic HDMI to SDI converter, everything immediately ran smoothly.

While Blackmagic output from QLab is handy in a bind, when you simply can’t do it any other way, I would never, ever recommend it over using a direct graphics output from the computer and converting it externally.

I hope that helps, but please ask away if I can explain anything in more detail, or if you have more questions!

-Andy

—
Andy Lang
@SoundGuyAndy
sup...@figure53.com

​

[Brian Mohr]

Thanks for the detailed response.  I did read above about the extra layers of video process, but did not understand what a performance hit was involved.  Though the system I have in mind is strictly a single file playback with no geometry or effects- it is a 13" mbp, so no dedicated graphics and dual core.  We also don't run a backup so we have to keep everything simple and safe to stay stable- which is has been.  We'll go the converter route, though I'll lament the additional conversion points and need for a power supply.  As a touring rig we like things small and super simple, as in foreign countries even coming up with another power port can get tricky when you've run out of adapters.  I also believe I had a colorspace issue in converting between HDMI and SDI once, but didn't have the time to truly troubleshoot where the issue was exactly.

I do have another question- does a video editing program not have to go through this same process?  Why would they add this overhead process rather than similar use a direct GPU output?  Or are video editing programs processing on the CPU and more easily go to ram and out the video device?  Since SDI is a production format, is there any hope for a 'native' SDI output?

Many thanks again.

​

[Chris Ashworth]

On December 9, 2015 at 1:17:46 AM, Brian Mohr (a2a...@gmail.com) wrote:

I do have another question- does a video editing program not have to go through this same process? 

That’s correct. QLab is performing all compositing and rendering live, since everything needs to be dynamic and able to change at any time. Video editing programs do not need to do this, and pre-render for simpler output.

-C