DENVER—At IBC2025, Sept. 12-15 at the RAI Amsterdam, Imagine Communications will introduce the SNP-XS, a versatile addition to its Selenio Network Processor (SNP) that packs the power of Imagine’s SNP platform into a deploy-anywhere form factor. Delivering ultra-quiet operation and high-performance processing in a small 2RU footprint, SNP-XS is the ideal solution for edge deployments, facility expansions, remote routing endpoints, mobile production, and any space-constrained environment.

Imagine says it has shipped more than 5,000 SNP units since it was first introduced in 2017, powering over 150,000 video streams and 2 million audio streams worldwide. Built on the same field-proven architecture as the flagship SNP platform, SNP-XS supports SMPTE ST 2110 and ST 2022-6 IP standards while maintaining seamless interoperability with SDI-based workflows — making it a perfect bridge for customers transitioning to IP or optimizing an existing SDI facility.

“IP technology is no longer limited to tier 1 broadcasters and large-scale projects — it’s become the clear path forward for media operations of all sizes — making SNP-XS exactly the right tool at the right time,” said John Mailhot, senior vice president, product management, at Imagine Communications. “Whether it’s serving as a high-quality SDI processor or an ST 2110 gateway for smaller jobs, SNP-XS provides the same trusted capabilities of the proven SNP platform in a compact, ultra-flexible footprint ideal for any environment where space is at a premium.”

Despite its reduced size, SNP-XS offers flexible I/O configurations and runs all 16 current SNP applications right out of the box—including UHD and HDR conversion, multiviewers, master control, and JPEG XS. It shares the same software releases, APIs, control protocols, and feature licenses as the flagship SNP, ensuring full compatibility and consistent deployment across operations.

“Even in large facilities there are small jobs, such as in edit suites and standup studio environments where a handful of signals join and leave the network,” Mailhot added. “Flexible mounting and a super-low-noise design, coupled with analog audio breakout capabilities, make SNP-XS a perfect, compact 2110 endpoint for small rooms in big systems.”

Imagine will demo the new SNP-XS at its IBC2025 stand, 1.B73.

ANS, Belgium & LISBOA, Portugal—VoiceInteraction, a developer of speech processing solutions for automated closed captions, has selected DELTACAST’s ST 2110 IP Virtual Card to move its live closed captioning platform to IP. DELTACAST is a provider of live video transport & processing solutions for developers in broadcast and ProAV markets. 

DELTACAST’s new card will be used with VoiceInteraction’s Audimus.Media, the company’s flagship software for the broadcast industry, offering accurate, reliable, and cost-effective captioning, with live translation on-premises and source video signal encoding to enable clip export with synchronized captions to VOD platforms, according to the company. It now also offers HLS playlist creation with WebVTT files to allow stream accessibility in any language.

VoiceInteraction says it selected the DELTACAST IP Virtual Card as a solution to quickly carry its software from SDI to ST 2110 and reduce the time-to-market. The card features a new video and multimedia programming interface that allows the use of third-party computer network cards (NIC) to capture and stream out video. The IP Virtual Card brings in support for video transport as per ST2110-20, audio transport as per ST2110-30, and ancillary data transport as per ST2110-40.

“The fact that the solution can be installed on any machine independent from the NIC card was a key decision factor for us,” said Renato Cassaca, Chief Software Development Engineer at VoiceInteraction.

The VideoMasterIP SDK provided by DELTACAST simplifies integration; the SDK connects the application to the IP Virtual Card through an easy to use API (Application Programming Interface) coming with comprehensive documentation and example source code.

“VoiceInteraction seamlessly integrated the SMPTE ST 2110-30 (PCM audio) and ST 2110-40 (Ancillary data) essences natively supported by VideoMasterIP in Audimus.Media,” said Olivier Antoine, Product Manager at DELTACAST.

Audimus.Media is now ready for deployment in any IP broadcast infrastructure, independently from the NIC card used and will be live demonstrated at the VoiceInteraction booth (W9711) at the NAB Show, April 24-27.

 LAS VEGAS—At the 2022 NAB Show next month, Cobalt Digital will introduce its +UDX-Dante-16x16, the industry’s first license-based 12G-SDI bridge to Dante audio, according to the company. Also on deck is Cobalt's new Indigo 2110-DC-01 SMPTE ST-2110 solution, as well as the company's line of compression products with a multilink demo of RIST, and new Technicolor features for reversible inverse tone mapping SDR to HDR incorporated into Cobalt products.

Dante is Audinate’s combination of software, hardware and network protocols that deliver uncompressed, multichannel, low-latency digital audio over a standard Ethernet network. Dante effortlessly replaces point-to-point analog and digital connections with software-based routing sending AV channels anywhere on the network with perfect digital fidelity.

Cobalt has made Dante’s IP-based audio networking solution available to users on a license-basis, which is field upgradable, by incorporating the functionality into the Company’s 9904-UDX processing card. +UDX-Dante-16x16 supports embedding and de-embedding all the way to 12G with full audio routing capabilities between SDI, MADI, and Dante, both input and output, adding up to 32 channels to existing 9904 cards for a high-density solution without the need for any new hardware. Users can ingest and process up to 16 audio channels from the network and output up to 16 channels back into the network using Dante and the Ethernet port. 

In addition to accessing Dante on Cobalt’s 9904 cards, users also have access to the card’s other functions such as UDX, color correction, 3D-LUT, frame-sync, audio mixing which are still available while embedding and de-embedding to/from SDI.

+UDX-Dante-16x16 users can also benefit from Cobalt’s BBG-1300 compact and portable frame by inserting a licensed 9904 card into a frame, converting it to a standalone chassis.

Cobalt's Indigo 2110-DC-01, is a new openGear-based SMPTE ST-2110 solution with dual 25G interfaces and 4K support. This highly integrated factory option offers best-of-class native ST 2110 audio/video processing to the Company’s 9904-UDX-4K and 9905-MPx audio/video processor cards. 

On the compression side, the 9992-ENC/DEC line has been enhanced with support for decoding Dolby AC-4 and Dolby E, as well as transport protocols such as SRT and soon, Zixi.

Cobalt will also conduct multiple demonstrations including ST 2110 processing, multilink RIST in seamless switching mode using SMPTE ST 2022-7, and a new feature from Technicolor that allows reversible inverse tone mapping SDR to HDR, followed by SL-HDR1 in seamless fashion.

Cobalt Digital will be in Booth N3713.

For more information on the NAB Show, April 23-27, visit nabshow.com/2022/.

This is the fourth installment in a series of articles about the newly-published SMPTE standard covering elementary media flows over managed IP networks. This month, the focus is on audio transport, specifically on uncompressed, studio quality audio for broadcast applications.

UNCOMPRESSED AUDIO

The full title of SMPTE ST 2110-21 is “Professional Media Over Managed IP Networks — PCM Digital Audio.” This standard is closely related to, and heavily based on AES67, which is titled “AES standard for audio applications of networks — High-performance streaming audio-over-IP interoperability.” Although the document titles may not be totally self-explanatory, both standards are all about transmitting raw, uncompressed samples of audio signals directly within RTP/UDP datagrams using an IP network.

To understand how audio signals are packed into these datagrams, it helps to remember that each individual channel of uncompressed digital audio signal is created using a fixed sampling frequency and a fixed number of bits per sample. In the case of ST 2110-30, all senders and receivers are required to support 48 kHz sampling, at a minimum. In broadcast applications, 24 bits (3 bytes) are generally used for every sample. So, for a 48 kHz, 24-bit stereo audio pair, the raw audio data would consume 48,000 x 3 x 2=288,000 bytes/sec which equals 2.304 Mbps without any packet headers.

PACKETIZATION

An example of how audio samples are placed into packets is shown in Figure 1, where an HD-SDI signal is separated into individual IP packet streams for each media type. Video is encapsulated using ST 2110-20 and ancillary data is done using 2110-40. Two audio groups are shown — one stereo pair and one set of 7.1 surround sound (which is eight channels uncompressed). Each of these signals is packetized into a separate stream, as shown in the two rows that make up the table. By keeping the number of audio channels at eight or below for each of the two packet streams, maximum flexibility in choosing receivers is achieved, since the minimum (Level A) conformance level for an ST 2110-30 receiver is eight channels.

[Read: What SMPTE-2110 Means for Broadcasters]

Four factors control the way that audio samples are packed into the RTP packets that make up a stream, and are listed in the table within Figure 1 for each audio stream. The four factors are:

· Audio sampling rate. Most broadcast applications today use 48 kHz sampling, so all ST 2110-30 senders and receivers are required to support it. Some applications use 96 kHz sampling, and 44.1 kHz can also be found in practice, so the standards recommends that both additional rates should be supported. Other sampling rates are out of scope for the standard.

· Audio sampling depth. Because IP packets are formatted in bytes, the audio data payload must be an integer number of bytes. Therefore, AES67 and ST 2110-30 only allow 16-bit and 24-bit audio sampling.

· Packet time. This parameter indicates the timespan covered by the audio samples contained in each packet. For example, when 48 kHz sampling is used with a packet time of 1 millisecond, there will be 48 audio samples from each audio channel in each packet. Note that longer packet times increase the end-to-end latency of the audio stream (because it takes longer to fill each packet) and shorter times increase the number of packets in a stream.

· Number of channels. Normally, all of the parts of a multichannel audio signal, such as stereo or surround sound, are transported in the same IP packet stream. Thus, a 5.1 surround sound signal would have samples from six different audio channels interleaved within each packet.

A receiver relies on information contained in the SDP (Session Description Protocol from RFC 4566) in order to properly interpret the packet contents. The SDP data, which typically consists of a few lines of text, can be transported in multiple ways from a sender to a receiver. SMPTE ST 2110-30 does not define a specific way to do this. Instead, methods are being developed by the AMWA (Advanced Media Workflow Association) for use by media production facilities.

Along with the four parameters described in the preceding paragraphs, the SDP values defined in ST 2110-30 provide standard order for the individual channels within the IP packets. Two examples of this are shown in the table in Figure 1, including both the symbols that are used in the SDP file (“ST” and “71”) and their associate channel order in the last column in the table. Symbols and channel orders are defined within ST 2110-30 for other audio systems such as matrix stereo, 5.1 surround and 22.2 surround (symbols “LtRt,” “51,” and “222,” respectively).

SMPTE ST 2110-30 also defines a set of six compliance levels for audio receivers, as shown in Figure 2. To achieve compliance at a particularly level, a receiver must be able to accept any quantity of audio channels in a single stream within the range shown in the table for each combination of packet time and sampling rate. Note that only the “–X” receivers are required to support 96 kHz sampling.

COMPATIBILITY & DIFFERENCES WITH AES67

One question that might be asked about AES67 and ST 2110-30 is: “Can they be made to work together?” The answer is: “Absolutely.” Because ST 2110-30 is based on AES67 and includes multiple “normative” (i.e. required) references, it is very easy to achieve interoperability. That being said, there are a few areas of difference.

First of all, ST 2110-30 receivers are not required to support SIP connection management for unicast audio signals. This is likely not an issue, since large audio networks frequently use IP multicasting to allow signals to be sent to multiple destinations simultaneously. This does mean, however, that ST 2110-30 receivers won’t be able to send or receive VoIP (Voice over IP) calls that use SIP for connection setup. Also note that RTCP (RTP Control Protocol) is recommended for use in AES67 but only needs to be “tolerated” in ST 2110-30 devices.

There are some differences with respect to how PTP (Precision Time Protocol, as defined in IEEE-1588) is implemented between the two standards. One important difference is that RTP clock offsets are not permitted in ST 2110-30. This means that AES67 receivers can work fine with ST 2110-30 senders, but that AES67 senders must not use an RTP clock offset when sending signals to ST 2110-30 receivers. There are also some differences in the specific profiles of PTP that are used in the two standards, however, the permitted ranges overlap so the two systems can be set up to work together.

One other slight difference: ST 2110 requires that every device has an option that allows it to be set in a PTP slave-only mode. When this mode is enabled, the device will never attempt to become a PTP master. This is important in large networks in order to prevent chaos when every device becomes available to take over as PTP master when an interruption in the PTP distribution system occurs. This option is not required in AES67, but should be a useful feature in many products.

HARMONIOUS SOUND

SMPTE ST 2110-30 was developed specifically to make audio as compatible as possible with video. By using the widely-accepted AES67 standard as a base, this new standard allows a wide range of existing audio equipment to harmonize with the rest of the 2110 suite.

Other entries in this series:

SMPTE ST 2110-21: Taming the Torrents

SMPTE ST 2110-20: Pass the Pixels, Please

SMPTE ST 2110-10: A Base to Build On

[Want more information like this? Subscribe to our newsletter and get it delivered right to your inbox.]

This is the third installment in a series of articles about the newly-published SMPTE standard covering elementary media flows over managed IP networks. This month, the focus is again on video transport, specifically the rules that help ensure that high-bitrate video streams are well-behaved and won’t overwhelm the IP networks used to transport them nor overflow receiver buffers.

KEEPING STREAMS FROM OVERFLOWING

The full title of SMPTE ST 2110-21 is “Professional Media Over Managed IP Networks: Traffic Shaping and Delivery Timing for Video.” Both of these terms refer to the same basic topic: how are the packets transmitted over the network, from the perspective of both the sender and the receiver? In other words, how should packet flows be sent into the network “pipes” so as to not cause flooding (of packets)? Answering these questions is crucial for properly provisioning network connections to support as many signals as possible without causing packet congestion, which could lead to packet loss.

To really understand the potential issue, it helps to deal with some actual numbers. Consider a 1080p signal with a 50Hz (European) frame rate that has a bandwidth of 3 Gbps on an SDI cable. At 50 Hz, a new frame of video is created every 20 milliseconds. Using constant-size packets, each with 480 pixels, would result in 4320 packets for each video frame. Using 10-bit sampling, 480 pixels would require 1200 bytes of data, plus 90 bytes of overhead, for a total of 1290 bytes per packet.

One way that this video signal could be transmitted would be using evenly spaced packets. In this case, 4320 packets sent every 20 milliseconds would mean that one packet is sent every 4.63 microseconds. On a 10 Gbps link, each 1290-byte packet would require (1290*8=10,320) bit-times to transmit, or 1.032 microseconds, followed by a gap of roughly 3.6 microseconds.

Another way that this video signal could be sent would be sending all of the pixels within a frame all at once. (This could hypothetically be the case for a device that was, say, generating graphics.) In this case, the sender would generate a burst of packets lasting 4320*10,230 bit times, or 4.419 milliseconds. This burst of packets would be followed by a gap of (20-4.419) 15.581 milliseconds until the next video frame was ready to transmit.

[SMPTE ST 2110-10: A Base to Build On]

So which of these packet transmission schemes is better? Well, both of the above streams have the same long-term average bit rate, of just about 2.23 Gbps. However, the first stream with evenly spaced packets will be much easier for signal receivers, switches and other network devices to handle. Why? Because the second stream will fully occupy a 10 Gbps data circuit for a significant period of time, forcing any lower-priority data that might need to be transmitted over that link to be placed in a buffer to wait for the link to become free. If higher-priority data came along during the data burst, then video packets would need to be buffered instead. Since network devices typically have a limited amount of buffer space that needs to be shared by multiple physical data channels, any signal that places heavy demands on buffers can cause problems, such as lost or deleted packets when buffers are filled up.

This issue becomes even more of a problem when multiple senders are all trying to transmit bursts of data at the same time, as would frequently occur in applications where several video sources are locked to a common clock. Therefore, to prevent network problems and to make it easier to design signal receivers, it makes sense to set some limits on the size and duration of packet bursts. These limits are often called “traffic shaping” and/or “delivery timing” in networking jargon.

TYPE N, NL AND W VIDEO SOURCES

The ST 2110-21 standard defines three types of senders: N (for Narrow), NL (for Narrow Linear) and W (for Wide). These types define limits for the amount of packet delay variation (i.e. the burstiness) that a sender is allowed to exhibit in its output stream.

Type NL is the easiest to understand, and corresponds to a stream where all the packets for a video signal are evenly spaced across the duration of each video frame (i.e. a stream that is like the first example given in the preceding section). The SDP (Session Description Protocol) for this type of stream must include a parameter “TP=2110TPNL.”

[SMPTE ST 2110-20: Pass the Pixels, Please]

Type N is similar to Type NL, except that the sender doesn’t send packets during the time that would correspond to the VBI (Vertical Blanking Interval) or VANC (Vertical Ancillary data space) of the corresponding traditional SDI video signal. Thus, a Type N sender would be able to send packets in a stream that would have a noticeable gap that occurs during each video frame period. For example, in a 720p signal running at 50 frames per second, and a VANC equal in duration to 30 lines of video, the sender would deliver packets for (720/750*20 milliseconds) 19.2 milliseconds out of every 20 milliseconds, and have a 0.8 millisecond gap when no packets are sent. Note that this would be the behavior that would be the easiest to implement if an incoming SDI signal was simply converted to ST2110 packets whenever active video samples arrive. The SDP for this type of stream must include a parameter “TP=2110TPN.”

Type W senders are allowed to have a significantly greater burstiness. This category was included in the ST 2110-21 standard to accommodate software-based senders, such as a graphics generator. For Type W flows, senders can have at least quadruple the amount of burstiness as a Type N or a Type NL, and in many cases much more. While this looser tolerance should make things better for a sender (particularly one that is implemented on a virtual machine), it does have consequences for receivers, which require a corresponding increase in the size of their input buffers. This can be costly, both in terms of the raw amount of memory that is required as well as in terms of delay for an incoming signal. Type W streams will also tend to consume larger amounts of buffer space within network switches and other devices; applications with significant quantities of Type W senders will need to be implemented using network devices that have sufficiently large internal memories. The SDP for this type of stream must include a parameter “TP=2110TPW.”

Fig. 1

Click on the Image to Enlarge

Fig. 1 shows a comparison of the three different sender types. Each of the three types is shown with a simplified representation of the packet flows along with a moving average of the bit rate. Note that for type NL, the moving average bit rate is flat, showing that these flows are the best behaved. Type N shows an increase in average bit rate during active video and a decline during the VANC. For Type W, the average rate shows even larger flow rate surges and drops.

Receivers are also categorized in ST 2110-21, but this information is not required to be transmitted with SDP. A Type N receiver should be able to correctly receive a flow originating from either a Type N or a Type NL sender(but not a Type W), provided that the receiver is locked to the same clock as the sender and that sender is aligned to the SMPTE ST 2059-1 Epoch. A Type W receiver should be able to receive a stream from an N, NL or W sender, provided the receiver is locked to the same clock as the sender. A Type A (for Asynchronous) receiver should be capable of receiving a stream from any type of sender, regardless of clock source or signal phase.

PRACTICAL CONSIDERATIONS

For time-sensitive flows within a media facility, such as a live broadcast, Type N or NL senders will tend to dominate, because they are the easiest to multiplex together and require the least amount of buffering in the network and at receivers, and therefore introduce the smallest amount of end-to-end delay. If Type W senders are present in a network, receivers will also need to be Type W to be able to receive these flows. For non-frame-accurate applications, such as monitors and multiviewers, or when synchronization between senders and receivers is not present, Type A receivers can be used to accommodate any type of ST 2110 uncompressed video flow.

Wes Simpson is the president of Telecom Product Consulting. He can be reached via TV Technology.