Cinegy Air 14 - What’s New

Below are headline "major" category changes in Cinegy Air 14 which are supposed to have the most significant importance for customers:

Below are some other changes, called out due to their potential impact on installation or the secondary benefits they might bring and warrant inclusion in the "must read" section.

If you have read this far, then you are interested in details, preferably with pictures and data points. So let’s dive into some of these changes with a little more purpose and discuss these enhancements.

While working back in the more conventional world of broadcasting, where HD is still considered something high-end (rather than just the starting point of a graph), one business requirement that is not going anywhere soon is moving signals from one place to another.

With the increase in public cloud adoption, and an ever more well-connected world to report from or hold events in, the arrival of an open technology that people can utilize for moving signals around could not have been better timed. For those of you that are not aware of what SRT is, I encourage you to jump to the SRT Alliance (of which Cinegy is a member) website and learn a bit about it:

https://www.srtalliance.org/

For those that don’t want to follow a link, in a nutshell SRT (which stands for ‘Secure, Reliable Transport) is a protocol to allow error-free, very low-latency connections over imperfect networks, and is available as an open-source library that anyone can include in their products.

Why we at Cinegy are jumping up-and-down happy that this is available is because for the first time there is a way such a capability can be added to our products that can just work with others. Sure, the concept behind SRT is nothing new – and some high-quality products exist that fill this space. But now, anyone can turn on these features baked right into Cinegy Air 14 and backhaul a stream from AWS or Azure via the public Internet back to their premises. It’s built in and has no cost element – if you have a copy of Cinegy Air under SLA, you’ll just be able to update to Cinegy Air v14 and use it.

Since we integrated this into our tools, we’ve never looked back - even for internal use. No longer do we need to have all workstations in the office connected into the dedicated video network if we want to pull up the output from some machines in elsewhere – SRT removes the need for it. Anywhere you could previously send in / out an MPEG2 Transport Stream within our products, you can now also do with SRT as the wrapping envelope.

It’s hard to explain quite how much this changes what you can do in words, so we’ve made a small GIF that shows how to take a Cinegy Air channel, and how to add an output stream of H.264 in "SRT Pull" mode – finishing with then making good old VLC connect up to the stream:

While the GIF shows a "pull" of a stream, you can also set up a "push" (or "Caller mode", in SRT speak) to pro-actively send out the stream to anything sat waiting to catch one. An area this suddenly makes much easier and neater is inside the public Cloud – no longer do you need to carefully balance where you unicast what; set up SRT on the Cinegy Playout engine to allow clients to pull a stream ("Listener mode") as they need it.

You can look forward to further SRT enhancements in the next point-releases of Cinegy Air, as well as being integrated into our other products. We’ve not yet exposed any parameters and options for people to adjust; it’s pre-set into "it-just-works mode" – but we will add more knobs and dials to allow people to control encryption, latency and bandwidth in coming releases.

As eluded to in the above 8K section, we’ve once again made more performance increases with the Cinegy Playout engine. With the introduction of Cinegy Air 12, we moved the compositing stage of the playout pipeline to optionally reside within the GPU – which had great benefits for customers that wanted to use our integrated branding system for adding graphics to the output, or were using the very convenient and efficient NVIDIA "NVENC" H.264/H.265 encoding blocks, since we could neatly combine these things and copy frames around inside the super-fast GPU memory.

However, our studies have shown that as people pushed the boundaries of the engine, the computation overhead of taking source material decoded within the CPU (or worse, decoded by the GPU and then handed to the CPU to just send back to the GPU) was becoming a limiting factor. To reach the dream of 8K60 at 10-bit, we knew we needed to cure this. As a result, we created a way to connect the input stage of our media layer to the compositing stage without moving over the CPU at all, performing any technology conversion (e.g. CUDA to DirectX) or color-space conversions (YV12 to YUV2) now within that interconnection.

Here is another lovely GIF showing the resulting change in a visual way – each example performing the same base tasks, running on an i7-6700 with a GeForce 1060 GTX:

– Playing a 4:2:0 H.264 Long-GOP clip in 1080i50

– Creating an NVIDIA encoded H.264 5Mbps IP stream

– Rendering a static channel ident

Obviously, when you need to do 64x more work than HD to make 8K work the way it’s needed, you need to get those graphs down so low you can barely see them!

A couple of words of warning though – before people go rushing off to consolidate too much onto a single machine.

However, using this knowledge, you should be able to get much more life out of existing equipment – maybe with a GPU update for a few hundred dollars. Remember though that not all codecs and containers can be decoded within GPU – if you decode something that is only supported by CPU, then you’ll see performance similar to the Cinegy Air 12 engine.

Accelerated codecs / container combinations are:

We look forward to SMPTE completing their work towards supporting H.265 inside an MXF container, so we can add this option.

We’ve always worked hard to offer a great cross-section of board support within our products, but there is always a newer board, or a board with some extra features someone wants to work with that we don’t support natively.

Now with Cinegy Air 14, we’ve added a generic wrapper which will allow people to use boards previously unsupported by Cinegy with their engine. This works by using the Microsoft WDM (Windows Driver Model) framework to access a board as an intermediary. You might have seen this as the mechanism by which something like a Blackmagic Decklink board becomes available to an application such as Skype. This model also opens up a world of "virtual device" inputs from other software – if you have another application that presents as a WDM device, you can now bind that to an input in Cinegy Air.

When accessing a board via WDM, Cinegy Air will attempt to get the requested raster format from the board through the WDM interfaces, so that the input video has the highest quality in the application. For several cases, this can prove absolutely perfect for requirements, so why do we still bother to support any boards "natively"? Well – WDM is not without limits. Using that framework, we can’t directly configure features of a board - for example, to choose what ports to enable on an AJA board. Neither can we access extra capabilities – such as reading timecode and sync from an LTC port. Finally, we have less control of that board in general, so we can’t support a board via WDM as a 24x7 mission critical component; we test in the lab specific supported boards and make driver and firmware recommendations to achieve that level of confidence.

But if you are in a hurry and can accept these limits – you now can.

An offshoot of this work is a far more fun improvement, which, while it might not be generally useful for people in a proper broadcast environment, is a great benefit for people performing training, testing, or demoing our software – webcam support!

When you pick a detected webcam, Cinegy Air will negotiate with that webcam to work out what the best choice of raster and framerate is to synchronize with the configured channel (note: turn on full logging in Cinegy Air and take a peek at what we dump to the logs to see what your camera can do).

With a webcam configured as an input, you now have a readily available, low-latency source of video to use for whatever you wish – here is another GIF showing the set up and use of the camera with Cinegy Air set to jump directly to "live" on startup:

Switching to the operators rather than the core engine, a couple of call-out improvements in Cinegy Air 14 involve labelling and replacing items in the playlist. We’ve introduced the ability to flag items in the playlist with customizable color categories, helping to make it easier to glance at a playlist and see what types of content are within the grid.

We’ve added some sensible defaults to the list, but you can set them to anything you want within the configuration panel. If you are using automation to set these values, you can print anything you want into the source XML and the Cinegy Air grid will show what you entered – as a user, you can then click to import any values that are displayed in the list, in case you want to re-use them.

Additionally, we’ve improved the way you can replace items inside the panel. If you hold down Ctrl while drag-replacing an item, you are now presented with a nice dialog that helps you consider how you want the item replacing. It was possible to do some of this before, but you needed to remember if it was Ctrl or Alt to work out what was going to happen… now just use Ctrl and then review the dialog box – like below:

For some loyal customers that discovered Cinegy a long time ago, you will recall that once upon a time it was possible to run the Cinegy Playout engine as a Windows service. This was lovely – you didn’t have to worry if a machine was rebooted and someone had to log back in (or setup some account to auto-login). However, with the introduction of Windows 2008, Microsoft made it technically impossible to continue running as a Windows service and still access the GPU with a feature called "Session 0 Isolation" (note: it’s fun to Google that term and see an amount of unhappy people venting in forums at the time this was introduced).

We tried hard to soften the blow by introducing Playout Dashboard in the system tray, which is actually a really nice way to interact with the engine while configuring and experimenting.

In the intervening years, Microsoft re-enabled support for DirectX and NVIDIA enabled support for CUDA from within a Windows service (Windows 8 / Server 2012 onwards). However, OpenGL has still not been re-enabled – so, rather than wait (possibly forever), we re-created our branding engine on DirectX and removed all OpenGL from the product.

Now we have formally ended official support for Cinegy Type in Cinegy Air 14, we’ve re-introduced the ability to configure the engine to run as a Windows service again. But we did it in such a way that people can keep working interactively (and enjoying the dashboard), whilst also pleasing sysadmins that prefer to work with automation and scripts. From Cinegy Air 14 – as well as Cinegy Air 12.3 when it ships – we have added a PowerShell script that helps people choose to install the engine as a Windows service.

Using this script, you can convert all configured Cinegy Playout engines to a service and inhibit the dashboard from starting a fight with the services. We’ve posted the actual script to GitHub in case people want to adapt this script to configure services in a different way:

https://github.com/Cinegy/Cinegy.Powershell/blob/master/Air/configure-services.ps1

You’ll find the script in the "support" folder when you unzip Cinegy Air, along with a classic BAT file you can use to start it:

The script can be used to create the services, but also stop and remove all services should you wish to go back to working with the Dashboard.

Working this way is not only more secure, it also helps keep loading on the servers lower; the Dashboard generated a reasonable amount of extra load, particularly over remoting tools. With the combination of XML-based engine configurations, you can configure and run a playout server without logging into the console at all – check out the example PowerShell-based configuration template script also on our GitHub page:

https://github.com/Cinegy/Cinegy.Powershell/blob/master/Air/create-playout-confs.ps1

There are some things to remember when running as a service though:

We hope you are glad to have services make a welcome return and would encourage you to review these scripts and adapt to your needs. Don’t forget about the "Unattended-Install" script also in the "Support" folder – it’s a nice timesaver on machines that want a default install. And in case you are wondering – the BAT file equivalents of the PowerShell scripts are just an easy way to let you choose "Right-click → Run as admin" to get the PowerShell launched correctly.

Cinegy Air 14 has now been released – so, while last year we recommended people grab a laptop and make your first HD channel, now this year why stop at HD? With our improved engine - use that laptop (and a webcam!) for a full UHD channel.

Updated 19th July 13:51: This article was updated for the purpose of clarification of language and text. A hero image was added.