ASPEN Provides a “Safe Path” to IP
Evertz's Mo Goyal says the ASPEN and AIMS groups will merge once SMPTE 2110 becomes a standard.
As the industry continues its slow and steady migration to Internet Protocol (IP) infrastructures, the manufacturing community has coalesced around two initiatives ASPEN and AIMS, each of which is claimed to help ease the conversion from SDI to IP.
The first such group was founded by Evertz Microsystems (and endorsed by companies including AJA Video, Ikegami and Sony) and is called Adaptive Sample Picture Encapsulation (ASPEN). The technology was introduced at NAB 2015 and submitted to SMPTE as a Registered Disclosure Document (RDD 37) and is now published in the SMPTE digital library. ASPEN is an open framework that enables independent flows for video, audio, and metadata in an IP-based broadcast and media facility. ASPEN expands on the MPEG-2 Transport Stream (IEC 13818-1 or ITU-T Rec. H.222.0) standard to include uncompressed UHD/3G/HD/SD video over TS. The ASPEN framework also utilizes open standards for transporting audio (SMPTE ST 302) and metadata (SMPTE ST 2038). SMPTE 2022-2 is used to encapsulate the transport streams into IP. More than 30 companies have endorsed the ASPEN program.
In January, 2016, five companies—Grass Valley, Imagine Communications, Lawo, Snell Advanced Media (SAM) and Nevion—announced the formation of the Alliance For IP Media Solutions (AIMS), which serves as a certification of compatibility with other AIMS members’ products. All AIMS members have agreed to a “road map” that leverages open standards like the Video Services Forum (VSF)’s TR-03 for video distribution and the AES67 spec for audio. To date, the AIMS group includes more than 55 companies.
For customers, there’s been some confusion about which marketing entity to follow, and indeed many companies are members of both (including Evertz) initiatives.
The Broadcast Bridge spoke to Mo Goyal, Director, Product Marketing at Evertz, to explain the differences (and similarities) of the two.
The Broadcast Bridge: How is the Aspen framework different from the newly emerged AIMS road map? How do your strategies on how to migrate to IP differ?
Goyal: First, I want to highlight that SMPTE 2110 is what the industry is diligently working on as the standard in broadcast. This is important because both the ASPEN framework and VSF (Video Services Forum) TR-03 are inputs into the harmonized format that is SMPTE 2110. In all three cases, the framework is the same: independent essences for video, audio, and metadata. The major difference between ASPEN and TR-03 frameworks is the addition of a Transport Stream header. The similarities regarding the framework are extremely beneficial as it makes the transition from ASPEN (for example) to SMPTE 2110 very easy.
The Broadcast Bridge: There are multiple companies that are members of both camps. But why do we need two camps?
Goyal: The two camps formed as result of two different yet similar approaches to solving the same problem. However, as we have seen over the last few months, everyone is quickly converging towards SMPTE 2110. Also, both current approaches (ASPEN and TR-03) can be easily migrated to the harmonization format of SMPTE 2110 in the future. Once SMPTE 2110 becomes a standard, I feel you’ll see the camps merging to help educate the industry with best practices on the IP transition.
The Broadcast Bridge: ASPEN has been submitted to SMPTE as a “Registered Disclosure Document.” What does that mean?
Goyal: One of the great misconceptions in the industry is that ASPEN is a proprietary format. That is simply untrue. Around 2013, Evertz was working with a major customer on a large IP project. The key to the project was to maximize the benefits of IP and 10GbE. Although SMPTE 2022-6 was available, it basically only maps SDI (and its constraints) to IP and is ideal for transport applications. If SMPTE 2022-6 is used in a production environment, you would still have requirements for external embedding and de-embedding equipment. Looking at other options, we saw MPEG-2 transport streams as an option. MPEG-2 TS is a known and proven standard in the industry that broadcast engineers are familiar with. SMPTE standards for audio (SMPTE ST 302) and ancillary data (SMPTE ST 2038) already exist. The only missing component was mapping uncompressed 3G/HD/SD video to TS.
Evertz created a format (called ASPEN) to fill the missing void of uncompressed video over TS. As we started to deploy more systems based on this framework, we saw the need for interoperability with other vendors. Hence, at IBC 2015 we had the formation of the ASPEN Community with the objective of making ASPEN an open format via a SMPTE RDD. Although a RDD is not a standard, it is an open public document that is published by SMPTE (after a technical review). Any SMPTE member can access the document and implement the format for no licensing or royalty fee. It is akin to the request for comments (RFC) process in the Internet Engineering Task Force (IETF).
The Broadcast Bridge: Are there any existing SMPTE (or other) standards that are part of the ASPEN framework?
Goyal: As mentioned earlier, the ASPEN framework uses SMPTE ST 302 for audio and SMPTE ST 2038 for ancillary data. All the essences are mapped to IP using SMPTE 2022-2.
The Broadcast Bridge: What’s the biggest benefit for customers?
Goyal: The major benefit of ASPEN is that you can deploy it now and have confidence there’s a path to SMPTE 2110. At this point, ASPEN is the only proven format to work at scale. As business conditions continue to evolve, broadcasters need to start thinking about transitioning to IP. Some have tried to postpone this decision until a standard has been established. With ongoing work within SMPTE, we strongly feel using ASPEN now is the only safe path available today.
You might also like...
Designing IP Broadcast Systems - The Book
Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…