I’m Steve Doll, founder and chief technologist for D2D Technologies. I’m going to miss seeing everybody at NAB this year, but I want to thank Cindy and Ross Video for putting on this webinar so we still get a chance to talk to everybody virtually and share the new things we’ve been working on for the past year.
You may not be really familiar with D2D, so I want to talk a little about the company. We’ve been around since 2007, but most of the team has over 20 years in the industry, so we’re very experienced. We’re based here in the U.S. with offices both in Florida and California. We have a reputation for being very reliable. Remember the old Ronco thing? Just set and forget it. You configure the devices, set them up, and they run. You don’t ever have to think about them again.
We were recently awarded as the technology vendor for the next-generation PBS and WARN system for transmitting the wireless emergency alert messages. We’ll go into a little more detail about that later. That’s actually a fully customized solution.
TV Azteca has over 200 stations using our equipment for multiplexing and rebranding. In that situation, we also had to do some customization where they were wanting to send their electronic program guide (EPG) data out to all the locations. With each location, they were doing a decode / re-encode so they could do some local regulation. Of course, when they do that, they lose all their EPG data.
Instead of having a generator at each site, as the satellite’s feed came in, we would take off the existing EPG data, save it, and send the stream out. It could be decoded and re-encoded, and then we bring it back to our system and inject the EPG data back into it.
Another one of our key customers is a national network, Three Angels Broadcasting Network. Once again, in that situation, we had to do some customization. To become FCC-compliant, they needed to do EAS insertions. We came up with a way to push a slate across all their channels during alert and then switch back, allowing them to be FCC-compliant. One of our core strengths is that we are very open and willing to do customization. That’s one of our key values.
We’re used both in contribution and distribution. In contribution, we can do four multiple-camera feeds. We can mux things together, then send it back to the studio for further processing and distribution. We do rebranding, EPG, and EAS insertion. Then we can then send a signal out to your transmitters, satellite uplinks, and cable head ends.
Some of our key products and features: The main one we’re focusing on here today is the D2Flex OG-5220. That’s our new openGear card, and it’s a multiplexer and an IP gateway. Related to that is the 5220, which is basically the openGear card in its own frame, so you can also use it as a stand-alone product. Another one of our key products is D2Flex 3000, which is the little brother of the 5000, which is very good as a turnaround box for hub-and-spoke type applications, which we’ll get a little more into later. A couple of our key software products that you could add on is the D2Guide for doing EPG generation and insertion and also the D2Alert for doing EAS insertion for FCC compliance.
The core technology of the Flex is built on an FPGA, and it’s a very proven technology. It’s been around for over 12 years now and going all the way back to our original mini-mux through our D2-Mux 5000 series products and now into the new Flex series. It’s something which is very mature, but we’re continually adding to it, improving it. It’s a very robust, mature technology. Also, with it being FPGA-based, it’s extremely fast and extremely reliable, so we can handle full ASI in on both channels concurrently at the same time, also doing IP streams in and out.
It’s also very capable of doing IP streaming. Since we are doing this all within the FPGA, we have very tight time tolerances that we can exceed, and we can do very low-level IP packet processing without having to bring it all the way up through the processor. We can do everything within the FPGA, but it is all managed by a Linux processor, which gives us a lot of flexibility because it’s a network.
On the Linux platform, we have an embedded Linux, so it’s very stripped down. It’s very light. It gives us very fast bootup times, but also gives us a lot of flexibility with any existing IP protocols which are out there. All you have to do is tell us, “Hey, we need this protocol.” We just rebuild the kernel with that protocol in there, and the next day you have that. It gives us a lot of flexibility.
That’s also what houses our D2 managed interface browser web server for configuring the devices. It gives us a lot of flexibility to add different options, such as SRT D2Alert and the D2Guide, and we’ll get a little more in the detail on those particular applications.
The main card we want to focus on today is the openGear 5220, our new openGear card, which is an ASI multiplexing gateway. One of the key benefits of this card is it allows you to optimize your transport stream bandwidth. You can bring in transport streams, you can strip off secondary audio, complete programs, and just pass through the particular programs that you want. It also allows you to easily rebrand channels. You can bring in different transport streams, and before you send them out, we can change your major minor numbers, your channel names — all that information can be modified before sending onto the final destination.
Mark:
Steve, I want to chip in here to say that featuring this multiplexing gateway, the OG-5220, we actually launched the original version of this about a year ago at NAB, it was very well-accepted. This is, to our knowledge, the only solution on the openGear platform that enables IP and ASI multiplexing and video processing. It’s a very significant addition and offering within the openGear platform.
Steve:
That is correct, Mark. It’s not just a gateway which can convert from ASI to IP. It actually does full multiplexing — combining the streams, breaking them apart — so it is a full multiplexing, de-multiplexing device. As you were saying, as far as we’re aware of, it’s the only one on the openGear platform. You can do service aggregation, where you can take different programs from different inputs. You can do any PID remapping and any program can go to any output, even multiple outputs. It’s very powerful to take existing streams and create new outgoing streams. It also has built-in fail-safe ASI relay bypass so that, in the unlikely event there was a card failure, the inputs would be passed directly to the output. Your signal would still be on the air.
Mark:
This was a key design element for the PBS selection as well. Why we were selected is really because of the fail-safe, for ASI and then also the power fail-over that is capable within the openGear chassis. Then, the design that you’ll go into next uses two of these cards with the ASI fail-safe, which really gives us a lot of resiliency within that design, which is great.
Steve:
Correct. That was a big selling point. We were giving our formal presentation when we were going through the PBS selection process, and we pulled the power on the openGear frame. The relays kicked in, and we never lost the signal. That is a very big selling point in our selection as the PBS WARN technology provider.
I want to talk a little bit about that system, since it is built around the openGear platform. First, let me explain a little bit about what the PBS WARN system is. Currently, your wireless alert messages are typically delivered by FEMA and other government agencies who will send it over the internet to the mobile carrier providers who will then distribute it to the cell phones in that area.
They’ll determine who in that area needs those messages. In that situation, whether you have a national disaster such as a hurricane, earthquake, or act of terrorism and the internet goes down, you need another way to get those messages out to people’s cell phones. That’s where the PBS WARN system comes into play.
The way the PBS WARN system works is all those messages are also sent to the PBS uplink, which sends them up to the satellite, then distributes them to all the PBS stations throughout the country. Then at each PBS station, we have our D2WARN system, which will strip off the alert messages and then inject them into the PBS stations’ over-the-air feed. They will then be broadcast, and the wireless carriers have special receivers that receive those messages and get the alerts out to your phones.
Mark:
This is a system that has been in place for five to seven years or so. What we were asked to do over this past year is implement the second generation of that. The next generation of the WARN system adds some capabilities. They call it public safety 2.0. This next generation of the WARN system is able to send those wireless systems. They’re very excited about the Ross openGear platform because it made this a very condensed solution. The previous solution took a lot of rack space. This one gets it down into that 2RU with the openGear chassis. Within a normal system we have two receivers, two of our multiplexer cards, and optionally also a Ross 7310 card in it that you’ll see, but all of this can be housed within that one openGear chassis.
Even in certain stations where they may do simultaneous broadcast with multiple stations, we can put up to four stations within one chassis, which gives it a lot of that density. Also very, very appealing is that the solution is fully integrated. That 2RU system was great, and having that standard space was a benefit as well. Of course, openGear is used quite extensively throughout the PBS stations, so they were very attracted to that.
We already talked about that automatic fail-over and resiliency and the ASI bypass protection. The other thing that we built into this is monitoring and alerting. The Ross chassis does have the SNMP monitoring. We monitor the state of the power supplies as well and provide that backup into an aggregated display, a browser-based dashboard that they can monitor within their dock.
Steve:
The compactness of 2RU was one of the key selling points when we were selected. As we have been rolling out the system, pretty much every station that has received it so far has given us really good feedback about just how condensed it is and how much they enjoy having everything within a single system in the 2RU. On this page, you see a little of just how condensed now it is. We went from multiple pieces of equipment, taking up a good part of a rack, to now just four cards within a single openGear frame. As you can see on the back panel there, there’s basically two satellite receiver cards and two of our D2Flex cards.
Mark:
A shout out to Sencore — we’re using Sencore receivers in the solution. We appreciate our partners at Sencore working with us on the solution. The receiver cards are Sencore, and we designed and manufacture the openGear D2Flex card.
Steve:
Along with Sencore, you see, for a handful of sites who are still using SMPTE 310, we are using a Ross ASI SMPTE 310 converter card, which would also go inside the openGear frame. All pieces of the system are housed within a single openGear frame.
Here’s a block diagram showing what we’ve been discussing, where you see within the primary D2Flex A, you have both a broadcast stream and a satellite stream, where we then do the injection. If it’s an ASI system, we would come out ASI, and that would waterfall into the D2Flex B, which would then monitor that ASI feed. If it detected any issues with it, if there’s any failure on the receiver A where the messages weren’t being injected, then the D2Flex B would use receiver B to do the injection itself.
All these are the ASI relays. If one of the cards were to fail, the signal would pass through to the next card. Also you can see, the ASI is how most of the stations are doing it today, but this is also designed to be used well into the future.
We’ve added the capability of doing all this using IP streams. With IP streams, each card will monitor the other stream for internal redundancy. Then also both of these systems, whether ASI or IP, can be operated in what we call chain redundancy, where they operate independently, and you have two complete broadcast transport stream chains. Then you would need some piece of equipment downstream that would then select which stream it wants to use. You have full chain redundancy in that case.
Another key application of using the Flex card is with hub-and-spoke type applications for distributing content over the public internet. In this case here, you would have a Flex openGear 5220 card at your station. There, we do all the multiplexing, bring in transport streams over IP, whether SRT or in house. ASI streams also bring your EPG data and EAS alert. Then we can bundle all that up to create your stream. Then we can deliver over the public internet using SRT.
Each of the cards can support up to eight different SRT routes. One card could send out to eight different locations. You could fit 10 of these cards within a single openGear frame, and you could be distributing your content to 80 different TV transmitters, cable head ends, or satellite uplinks all around the country, or all around the globe. SRT can take it anywhere. Another nice thing is that this will go over the public internet to your different types of destination points.
Another product we have is our D2Flex 3000, which is basically a turnaround box, which can receive your SRT at the different spokes in a hub-and-spoke application. In each location, it would take the SRT stream back to either regular IP or ASI to be fed into the transmitter into the cable head end. This would be what would go on the other end, and you’d have the openGear card acting as the SRT server.
I want to talk about a couple of the other software upgrades we have for the system. Going to the next slide, the first is the D2Guide for EPG generation. This can work in either manual mode or automated mode. In manual mode, you can create a very easy spreadsheet which gives you an air date, airtime duration, and what your event idea is. You send that over to the unit, and we’ll parse that up and create your EIT’s DTT tables. Or it can be automated where we support both TitanTV and Grace Note, where you put your credentials into our configuration page. From there, it pulls the schedules each morning and creates all your channel guide information. Once you set it up, you don’t ever have to deal with it again. It’ll do everything automatically.
Another key feature we have is the D2Alert for EAS insertion. This is what I was explaining in the beginning, what we had developed for Three Angels Broadcasting Network, where you would use an EAS system. We support both the DASDEC and the Trilithic where they have options to send out an MPEG-2 version of the alert message as text in a background. Then when we receive that, we’ll replace all the programs in your transport stream with that slate for the duration of the insert. Once the insert is over, we switch everything back. That allows you to have FCC EAS compliance without having to do a decode re-encode to insert a crawl.
Mark:
One of the questions that came in was about the number of streams, the SRT streams. There’s a question also around support for RIST in addition to SRT. Steve, do you want to comment on that?
Steve:
We currently don’t support RIST, but we have been monitoring that as it’s being developed. It’s not currently supported, but now that it has been ratified by the Video Services Forum, it’ll be moving on to a standard that we will then support.
Mark:
We’ve been supporting SRT. Gosh, we’re part of that interop and stuff probably for about three or four years now.
Steve:
Correct. As we speak, there’s another interop going on. Once we’re done with this, I’ll be jumping onto that and doing some of the SRT interop. When RIST comes out, we will support that. But SRT now has been very successful for us. We think we’re now up to about 125 links around the country, mostly being used for the studio transmitter links, where the TV station will use one of our products on each end and SRT to send their signal to the public internet, either out to the transmitter or to a regional cable head end.
Mark:
Do you want to talk about the density there, Steve, as far as the number of streams, SRT streams, and then also just regular IP streams that each card, the OG-5220 can handle?
Steve:
It’s basically the same. On the 5220, they both will support up to eight streams in and eight streams out.
Mark:
Simultaneously, so you can receive, re-multiplex. You could add localization, you could add guide information or whatever. Then as you turn that around, you could actually stream it back out. Again, it’s a good application for, like you said, STL links, houses of worship. If they have multi-site applications as well — contribution and being able to get it back into the studio — those are some really good applications.
Steve:
Another application for it is on the distribution side of sending out multiple point-to-point connections to different sites around the country.
Not as much SRT, but for the regular IP multiplexing within the openGear frame, there are other openGear manufacturers out there with encoder cards. You can plug the multiple encoder cards into a single frame and then route them to our card. You can create a multichannel encoder in a single openGear frame using multiple encoder cards and our multiplexing card. We also support being able to receive that over the internal openGear frame. If the encoder card is capable of streaming over the internal openGear frame, we can muscle those cards together and have one ethernet cable doing the whole thing. You won’t have to have ethernet cables coming out of each card. We can do it all internally within the openGear frame.
Mark:
Steve, do you want to comment on some of the new features that we’re going to add or that are slated up?
Steve:
A couple of things we have coming up over the rest of the year and into the beginning of next year focus a lot on analysis and the health of the stream. D2Health, which will monitor each input stream and each output stream, looking for things like continuity count errors, PCR jitter, and a loss of sync, can be configurable to send you SNMP traps. It can email you, it can text you — any way to let you know that, “Hey, do you have an issue with one of your streams?” We can also set it up to where we can monitor that for you, where the streams will come directly to us, and we’ll do the first line of defense.
We’ll go in and see if we can take care of it before we pass it on to your local engineers. Along with that, we’re also going to have an in-depth stream analyzer. Once you determine there’s a particular stream that you want to look at more in-depth, you’ll be able to drill down into that and see all your individual PID bit rates, all your continuity count errors, your PCR jitter — all those values will be available. That’ll be coming probably around the end of summer for ATSC 1.0. Then we’ll have the same capability around the end of the year for 3.0. It will have a built-in ATSC 3.0 analyzer.
Next year, we’ll be moving into an actual ATSC 3.0 schedule, and not just analyzing streams, but creating the same thing we do now, taking in existing streams, combining them, breaking them apart, but doing it all with ATSC 3.0 streams.
Jessica:
If viewers need technical info, maybe they need a little more about the new ATSC 3.0 analysis you’re doing or anything you talked about, where should they reach out to you?
Mark:
They can go to D2Dtechnologies.com. If you have any questions, please reach out to us.
We’d love to talk about what problems you’re trying to solve and how we might be able to work together. You’ll see that our technology has been very flexible and well-received in large deployments. PBS, for one, is out to 170 stations. TBS tech as well. We’ve done large rollouts of technology.
We’re super excited about partnering with Ross and openGear, and with Sencore as well on the solution we did for PBS. We have that piloting now, and that’s in the process of fully rolling out with PBS this summer.
