When a video high quality issue occurs, the network may be the very first to be blamed. Broadcast engineers battle to identify the primary cause and figure out its impact. And enough time from recognition to resolution could possibly be minutes or hrs. It is no real surprise that broadcast engineers save money time on data selection than analysis. Troubleshooting can be costly and could prove difficult if the problem can’t end up being easily replicated inside real-time. Proper Day 2 planning enables broadcast engineers to obtain before challenges with the proper tools necessary for success: visibility, automation, safety, and broadcast integration.

Material visibility through telemetry

IP fabric shouldn’t be a black container. Broadcasters need presence to ensure that this content they deliver arrives intact. Without presence, you don’t understand if packets are dropped, where or even why. Broadcasters need a user friendly, visual tool to start to see the movement in the fabric. Presence is critical, should be real-period and consumable by 3^rd celebration devices.

Telemetry is really a tool that delivers visibility. It could be split into two categories, software program, and equipment. Software-based telemetry provides an efficient supply of statistics being created by the change CPU, such as for example interface stats, Precision Time Process (PTP), and multicast tables. Equipment streaming telemetry supplies the ability to stream equipment utilization such as for example buffer counters and IP packet headers. Cisco presents telemetry from both a equipment and software viewpoint.  Nexus switches offer presence across many stats and telemetry could be consumed by third-celebration receivers along with our media controller.

Extensive visibility reduces troubleshooting cycles and allows the broadcasting engineer to be proactive in solving problems before they happen. The Cisco Data Center Network Manager (DCNM) includes a built-in telemetry receiver that receives real-time information from all switches in the fabric and an aggregated view. The DCNM media controller provides multicast flow visualization, flow health, bandwidth, and historical performance

Figure 1: Multicast visualization and PTP monitoring

Let’s dig just a little deeper into how software telemetry can be used for multicast visualization. In SMPTE ST2110, packets are carried using multicast, so focusing on how to troubleshoot multicast is crucial for broadcast engineers. Multicast troubleshooting using switch Command Line Interfaces (CLIs) is challenging  even for probably the most experienced administrators. Our DCNM media controller utilizes the telemetry information from switches to supply a Graphic INTERFACE (GUI) to visualize and trace multicast flows over the fabric instantly. These visual tools allow broadcast engineers to triage the issue by examining traffic flow and packet loss, which equals less down-time. Figure 1 offers types of visualization for multicast and PTP monitoring.

Figure 2: Visualization of Media Flow Insights

SMPTE ST2110 essence monitoring requires a step further into visibility. In current projects with broadcasters, I see wide usage of media monitoring and analytic devices to report and monitor SMPTE ST2110 flow, PTP quality, etc. While these tools are great at what they do, they depend on the fabric to obtain them a copy of the flow to be able to monitor. They’re not reporting on the specific flow but on a copy of it. How will you improve decision making if you are unable to view the specific flow? And, what goes on when many flows have to be monitored simultaneously?

Broadcast engineers should be able to visualize a large number of actual flows passing through the IP fabric. By monitoring and reporting on Real-Time Protocol (RTP) sequence gaps within an SMPTE ST2110 flow, the Cisco Nexus 9000 IP Fabric for Media can monitor multicast flow integrity at a scale of a large number of flows. This enables for real-time detection of per-flow packet loss with the granularity of 100 microseconds. The DCNM media controller can receive streaming statistics about RTP events from the fabric and present it in a graphical interface pinpointing errors in the fabric. Figure 2 shows graphics from the Media Flow insights tool. The media controller also tracks historical flow errors so operators can correlate network events retroactively.

Here’s a real-world workflow example: video traffic from the stadium is being repaid to a media data center for processing. The traffic passes by way of a service provider link that is not controlled by the broadcast engineer. With Media Flow insights, the broadcaster gets real-time reporting on the video flows ahead of reaching the company network and also because the flow finds the media data center. The DCNM media controller correlates the reported state and localize if video errors were triggered at the stadium, at the SP transit network, or in the media data center.

In summary, operating an SMPTE ST2110 fabric requires visibility tools to provide broadcast engineers critical insights to the “black box” called IP fabric.

Automate all you can

Plugging and unplugging camcorders, microphones, and archive services ought to be as easy as moving an office telephone. But also for broadcast engineers, it’s not. Every move gets the prospect of human error. Automation helps broadcasters onboard endpoints without getting together with the fabric. Cisco’s IP Fabric for Media solution components uses NXAPI (which are open standard RESTful APIs) to push policies and configurations to the switch. The switch streams provide information to DCNM using streaming telemetry. Telemetry configuration is achieved utilizing the CLI or pushed from the DCNM to the switches in the fabric. The DCNM ships with media-specific templates which may be used to automatically generate and push telemetry configuration to all or any switches. Broadcast engineers can form their own templates to match the specific workflow.

Don’t forget security – It’s critical

Securing SMPTE ST2110 flows is crucial to the workflow to safeguard the flow from unintended impact by other flows. New threats are affecting the media business so broadcasters require a comprehensive security strategy. When delivering and subscribing to content in the network, those flows require enhanced security also it shouldn’t be an afterthought

Security protocols protect the info flows and stop outsiders from snooping around or stealing your articles.  To safeguard the bandwidth reserved for a flow, broadcast engineers should follow “trust but verify”. With this particular concept, flows are sent in to the fabric but monitored to make sure a particular flow will not send a lot more than its allocated bandwidth to be able to protect all adjacent flows.  Cisco’s Media Controller utilizes the host policy construct with whitelisting or blacklisting capabilities. The host policy defines who is able to send a specific flow (authorized sources) and who is able to receive it (authorized receivers). The policy is then dynamically put on the fabric because the flows are enabled.

Figure 3: Integrated architecture

Integrating with the broadcast workflow

Every one of the above capabilities can’t be siloed. The fabric should be open and integrate with existing broadcast tools and controllers. Figure 3 shows how existing tools could be built-into existing broadcast infrastructure, workflows, and tooling. The training curve for broadcast engineers could be minimized using APIs and ecosystem testing and validation.

Don’t make Day 2 broadcast production transformation planning an afterthought.  For more information concerning the four pillars of success: visibility, automation, security, and broadcast, have a look at our webinar. Become familiar with methods and tools to troubleshoot fabrics carrying professional video flows to be able to minimize anomaly detection and restoration time. Give us a call when you have any questions.

The post Media Flow Analytics: Assurance and Monitoring in Professional Video Production appeared first on Cisco Blogs.