Will a ST2110 virtual Video/Audio device be developed.

Ok,
ST2110 is an interesting technology. Like with Dante, there is no reason a PC/Mac cannot have a virtual SDI video card that pushes the Data out as ST2110 over a generic ethernet card. (10GBe, 25, 100)

So, technically, a Monitor with a ST2110 to SDI/HDMI into the Monitor, and resolve, using a virtual video device could then push the image to any screen on a 10gBE network.
i.e. basically like we do today with Dante virtual device software for Mac/PC.

Will Blackmagic be releasing a virtual video/audio driver that can talk to the ST2110 devices?

This is of course a sensitive subject as it negates the need for the SDI/HDMI card that Blackmagic sells.
So, it is not a good idea for such a piece of software to exist as it cannibalises those products BMD sells.

But then again, BMD ST2110 is supposed to be based on open standards and anyone could technically make that software.

So I am keen to hear BMDs thoughts on this and if they will release a virtual device.

I think the issue, unlike with Dante and AES67, is that 2110-20 uncompressed video has pretty onerous requirements for timing and throughput - such that normal SFP+ NICs on PCI-E cards require more than just software at the user level to work with 2110-20/-30 etc. (For the same reason you can't use regular switches either)

The BBC has done some work with Mellanox and Netmap on bypassing the kernel to improve throughput - but the reason most 2110 capture/generation solutions for COTS hardware have integrated NICs (and aren't just virtual devices with software drivers) is that generic NICs and OS level support for them isn't good enough for 2110 on its own - or so I understand?

https://www.bbc.co.uk/rd/blog/2018-04-h ... nel-bypass

(This is a world away from NDI)

> (This is a world away from NDI)
No it is not. ST2110 was specifically designed to be an open version of NDI.

If a computer can feed an SDI card, I see no reason why it cannot also feed ST2110.
It can also listen to a PTP sync source and send packets based on that. Most hi end switches are nothing but computers these days anyway. (With a lot of ethernet ports)
ST2110, does not need to be compressed. Plus, the compression BMD have created is specifically designed to be light and easy for a CPU / GPU to implement. That's what its designed for. This is not a J2k heavy codec. Also, I would like to know why they didn't implement the new J2K-HT (Open standard) which sounds very much like the proprietary one BMD has implemented. J2K-HT is Super fast and light High-Throughput version, specifically designed for this type of use model.

So, I see no reason why this is not possible. Even it it adds 2-3 frames of buffering to make sure it gets it all together. Still very useful.

A computer doesn't feed an SDI signal, it needs some kind of hardware to convert decompressed data correctly from a timeline into one (or vice versa for input); just as ST2110 would require monitor manufacturers either to adopt Ethernet and internal decoding as a new standard input; or use external hardware convertors for SDI; every 'virtual' device ends up needing hardware; Dante is pretty useless without a physical soundcard to hear its signal output somewhere. A 'virtual' SDI signal of any kind would require some kind of hardware, and at least the physical outputs for it. There used to be Nvidia GPUs with SDI outs but that was just to get a non-broadcast computer signal to a broadcast monitor.

Why would the need for BMD's I/O devices be negated; anymore than Dante has killed the high end sound card market? When their whole purpose is to provide calibrated broadcast quality outputs and inputs locally, by passing any GPU computer device; without any latency whatsoever, for colour critical grading, VFX and editing? They are not simply hardware convertors.

ST2110 is just a new standard of sending broadcast quality video/audio data huge distances over Ethernet ,on existing infrastructure; much greater than and beyond existing SDI installations capabilities.

They're not that expensive; I'd just buy a simple Decklink or Ultrastudio rather than wait for some kind of 'Virtual' SDI device, that may never come.

> (This is a world away from NDI)
No it is not. ST2110 was specifically designed to be an open version of NDI.

ST-2110-20 isn't really an 'open version of NDI' - it's uncompressed and a lot more tightly specified.

If a computer can feed an SDI card, I see no reason why it cannot also feed ST2110.

Yes - just as a computer can feed a specialised 2110-20 friendly NIC (as BMD implements in their 2110 Decklinks).

The issue with doing it all in software is that you then need your OS and your Network Interface Card driver to be able to perform at 2110-20 levels. That's not a given by any means. How many 2110-20 software solutions do you see on the market that are sold for use with generic NICs?

As for 2110-22 CBR compressed video - then JPEG-XS seems to be getting leverage as a 2110-22 kicks in as a compressed remote production standard for remote camera feeds getting back to base (taking over from J2K, and TICO used with 2022 video)

ST2110 is just a new standard of sending broadcast quality video/audio data huge distances over Ethernet ,on existing infrastructure; much greater than and beyond existing SDI installations capabilities.

Remote Production is a use case - but it's also heavily used in UHD production vehicles (nobody really uses 12G-SDI, and Quad-3G is very limiting...) The big UHD production vehicles in the UK are mainly 2110-20 (with a few early ones using 2022 with TICO compression I believe). The big issue with Quad 3G UHD production is your routers and mixer/switchers quickly run out of inputs and outputs - whereas with a 2110 friendly switch you can handle more cameras, more replays etc. in UHD.

The BBC's new building in Cardiff is 2110 for example - people are less and less building large SDI installs.

You can play with gstreamer / ffmpeg, https://github.com/pkeroulas/st2110-too ... _source.md

Ok back to the topic at hand.

ST2110 has been slow for adoption BECAUSE you don't need a purpose-built card like a decklink. If you sat thouh some of the SMPTE meetings in the early days (I did for a while) you would know this. A main idea for the implementation was to be able to kick up in the virtual TV station on cloud infrastructure. ie. utilising typical hi-speed Ethernet cards.
It's just another form of IO wrapped in a very specific packet structure, a legacy of SDI.

ST2110 is not NDI, but it is designed to be able to do everything NDI did and more. If anything, standards that come out of SMPTE are over-engineered, and like BMD is trying to simplify it in its implementation, cutting the options out to make it more relatable to specific consumers. It does not take away from the fact, you can, if you need to, use all of the capabilities.

But back to the fact. It was designed to be able to produce a data stream from ANY Ethernet card that could go to a ST2110 device that can accept it. Removing the need for dedicated IO cards for SDI.

The main reason you don't see much of this adoption is it greatly damages the profit of all the manufacturers who make those dedicated IO cards. So they have no interest in supporting it.

So it's brave of BMD to do this, but then again I see BMD branching into so many other areas of production, they have the ability to now walk this path without hurting BMD as it expands all the other products and is an overall benefit.

But like Dante, NDI etc. These proprietary implementations support virtual device drivers. ST2110 obviously can too. It's just, when will a company/entity step up and make them. As indicated above, FFmpeg is capable of doing it. We just need Windows/MacOS native drivers that can interface with the operating system and common video editors.

I work in Post houses, and having 10+GBe networking and SDI going to every Mix/Edit suite is a pain. There is no reason we cannot go Ethernet for everything. And remove the need for SDI cables and a rack full of SDI switches and achieve a similar result. We may need to install an extra 10/25/100GBe switch.

If you feel you do need a dedicated IO card, just consider the propaganda that may have come your way. Yes, if you need to compress or process the data in any way, an outboard card would be useful. And a common excuse for the IO-card-makers to shoot software-based devices down. But the fact is YOU DON'T NEED THEM when doing completely uncompressed. I can see a need for some edge case use models that may need a type of card to do any compression but then again, you can devote some CPU cores to it, or even GPU. CPUs are so powerful now, that even that excuse for that edge case holds less water too.

ST2110 is, from my working on it many years ago, not well suited for Internet, high packet loss, scenarios. But there may be a ST2110-?? That looks into that. It also very likely implements high compression, and decent amounts of latency to result in a reliable and high quality picture.

To support ST.2110-20 or ST.2022-6/7 uncompressed IP video, your NIC needs to support both packet time-stamping and packet pacing - the Intel and Realtek generic NICs in PCs generally won't do that (nor will they handle the bitrate required either - but that's a separate issue)

Hence you either need a higher-end NIC (Mellanox, Silicom) and software that is optimised to handle those NICs (which is how software-based approaches like OBE handle 2110/2022 conversion to and from compressed streams), or you take an approach like Blackmagic, Matrox or AJA have, and implemented what are effectively video I/O cards with IP support that is separate to the OS-level network connectivity.

To support ST.2110-20 or ST.2022-6/7 uncompressed IP video, your NIC needs to support both packet time-stamping and packet pacing - the Intel and Realtek generic NICs in PCs generally won't do that (nor will they handle the bitrate required either - but that's a separate issue)

Reading up on "packet time-stamping and packet pacing" they are a nice to have, but I see no reason why it cannot work without them. Especially if you add a few frames of buffering. I would consider these options, optional. Especially if we are talking one good switch sitting between everything. (And you are not bouncing the signal between a lot of switches or routing it.)

I'm sure the person using FFmpeg and a generic PC is not utilising these features.