Allow me to get straight to the point: You're reading this because you're either at or interested in the goings-on of what we used to call "the broadcast industry," and is now broadened to "content," "media," "video," and so on.

It is an industry that dates back 70+ years, depending on when you start the clock.

And, it's an industry clearly in transition. (Again.) "Clearly," because we've seen the same transition happen, at least twice (in media): First to the music industry, then to what we used to call the cable industry. It started with "going digital." Now, it's about "going IP."

The (Non-Linear) Phases of IP Transition

For broadcasters and media providers, "going IP" is a matter of phasing, and the phases aren't necessarily sequential. One phase: The shift from SDI (Serial Digital Interface) to IP (Internet Protocol.)

Another phase: To terrestrial, IP/CDN-based distribution, from satellite delivery.

Through it all: Professional-grade, and dare I say, "broadcast-quality" product. After all, broadcast-quality has long been a gold standard, when it comes to good looking "reliable" video/audio.

Let's start with the transition from SDI to IP. This is happening, by the way, because in the new world - the IP world - it's no longer about frames of video. It's about packets, and how best to assemble lots of IP packets into a video frame, as it's done with SMPTE 2022-6.

Perhaps not surprisingly, we at Cisco know an awful lot about packets. Packets are life! Which brings me to the sturdy pile of updates we've made to our Virtual DCM.

For starters, the Virtual DCM update began with a desire for a single-server/ "one box" approach. As a result, it's a software-based machine that accepts SDI as well as IP inputs, then outputs multiple "flavors" of packet-based media. Output flavors include 10-bit HEVC encoding, to support High Dynamic Range (HDR) at 60 frames-per-second (HDR10, Hybrid Log-Gamma, Technicolor and Dolby formats). Or, you can transcode that same SDI input as a MPEG-2, AVC, and/or "stat-muxable" format. In other words, output both linear Transport Stream (TS) and OTT from the same platform.

The point of the expansion was to extend the software-based functionality of the (x86-based) Virtual DCM to optimize bandwidth - because 4K/UHD is huge, relative even to "just" HD. We also expanded what was already a rigorous attention to overall video quality (more on that in a bit.)

Which reminds me: Big thanks and a high-five to HorizonSat, a leading satellite provider covering the Middle East, Asia, Africa, and Europe, which announced (here at NAB!) how they are augmenting their existing DCM platform with the Virtual DCM. It's a great way for them to implement HEVC Statmux in software and use less bandwidth to distribute more media, faster, for both direct-to-home (DTH) and over-the-top (OTT) streaming video delivery. Bravo!

Satellite to IP Distribution

The shift by large broadcasters and content owners to move as many of their programs/channels away from satellite has started a new IP migration approach.  Today broadcasters are actively looking for cost-effective approaches to move regional content and or long tail content off satellite.

Why? Because IP CDN delivery offers advantages in agility and cost savings unavailable with satellite. And CDN delivery for live content offers broadcasters and content owners options beyond costly direct fiber and proprietary direct connect over the Internet.

New is the ability to utilize Adaptive Bit Rate (ABR) technology to gain the advantages of ubiquitous IP with the cost-effectiveness of ABR. Also new is the addition of intelligence to make the shift to consolidate on IP/ABR distribution.

That intelligence comes from another batch of improvements we built into our Virtual DCM and the D9800 Network Transport Receiver for ABR video distribution:

1. You can anticipate a 40% improvement in bandwidth consumption with the Virtual DCM. This matters especially as HDR/4K content continues to augment "regular" HD material.
2. You can consolidate on ABR delivery in the core for all services (linear, on-demand, OTT, TS), and from that single source of content you can convert back to legacy MPEG-TS at the edge to feed existing end-points; or go direct to consumer/OTT (how about that).
3. Video quality, using ABR techniques, is a big part of it.

What's that, you say? We can cut bandwidth usage by 40%, while improving video quality?

You did indeed read that correctly. Part of our streaming strategy is to leverage intelligence and machine learning, end-to-end (as in from client to cloud, including encode and network elements).

Our new Smart Rate Control technology works by improving the output of the encoder, while optimizing bandwidth for ABR delivery. In other words, the encoder can deliver variable, bit-rate-base outputs, adjusted to the quality of the content - and can set optimal limits to optimize bandwidth, without impacting perceived video quality.  Bottom line: It improves the OTT experience, for sure.

And, lastly - we wouldn't be Cisco if we didn't talk about cloud. Everything I wrote about here, all of it, is cloud-based. The Cisco D9800, as part of our Virtualized Video Processing portfolio, enables broadcasters and content providers to move content to the cloud while enjoying a simple and manageable IP-based connection to affiliate clouds/headends. Plus, that conversion from ABR to TS? It's deployable as part of our distributed micro-services approach to extending processing functionality intelligently to where it makes sense in the network: both in the D9800 or on a server. Not to mention that the microservices of our Virtual DCM platform are implementing Docker-based containers, reaping those associated benefits and efficiency gains.

This is pretty long, for a blog, I'm told, but HEY, I wanted to put it down all in one place. So I did. Please do come by to check it all out. We are in SU8502CM and will happily talk your ear off!