Steve Doll, President of D2D Technologies discusses ATSC 3.0 Data Applications and their role in NextGen TV.

Using SRT for Live Video Contribution

Jessica of D2D Technologies explains how to use SRT to transport your ASI signal, and she makes it simple! In this short video, she covers common applications (news, sports, and more), how things have changed over the years, how to leverage your old gear (or even someone else’s!) to support a new SRT signal flow, and why this new approach to contribution is such a game-changer for broadcasters.

How SRT Is Transforming Live Video Contribution

Can you believe that today you need just one Ethernet cable to send an ASI signal across the country for live contribution? Not that long ago, you needed a truckload of gear to make it happen. SRT (Secure Reliable Transport) has changed all that. And in doing so, it has opened up endless possibilities for flexible, cost-effective live contribution.

Developed by HaiVision, SRT uses a packet transmission method known as ARQ, or automatic repeat request, for error control and packet recovery. Thanks to this highly reliable technology, you can send your entire ASI signal across any internet connection, even through firewalls. If you have the available bandwidth, which typically is about 25% overhead or less, you’re good to go! That’s why we like to refer to SRT as a long extension cable for your ASI.

And when sending your ASI signals is as simple as this, you can enhance your broadcasts with more live content — and often more interesting content too! You can go live with a great-looking on-location news report without expensive gear, satellite dishes, power amplifiers trucks, microwaves, and miles of coax. It’s so much simpler, and so much more affordable. The flexibility is unreal!

This isn’t to say that your existing equipment inventory is no longer useful. Much of the satellite gear you used in your trucks or facility can be repurposed to support delivery of an ASI signal over the internet using SRT. And when gear is already installed in your facility, you can set up an SDI output tied into your switcher for a seamless production workflow.

Check out our new video, “Using SRT for Live Video Contribution,” to learn more about how SRT works and why it’s a great solution for bringing fresh content into your stories.

Matt:

Hello, and welcome to the show brought to you with the support of media proxy. Today. We’d like to welcome Steve doll from D two D technologies. Hi, Steve. Welcome to the show.

Steve:

Oh, thank you, Matt and Simon. Thank you for having me here today.

Simon:

It’s good to see you. So, Steve, we’re going to be talking about, uh, PBS war today. Um, we’re going to come onto that in just a minute before we get started. Tell us a little bit about D2D and what you do.

Steve:

Sure. So D2D technologies, we’ve been around for almost 20 years. We have a background in multiplexing and some of the areas, in addition, multiplexing we do is, um, yeah, EES insert that’s an emergency alert system, insertion program guidance insertion also do a lot of sending transport streams around the country using the public internet, using the SRT protocol.

Matt:

Okay, great. Yeah. So brings us neatly then onto, onto the PBS warn system. What, what is it?

Steve:

Sure. So first, let me give you a little background of what PBS is for some of your international viewers who may not be aware. It’s a private nonprofit organization, uh, and partnership with almost 200 member stations around the country. And their mission is to provide high-quality content which educates, inspires, and entertains. They have a lot of great programming, including educational children’s programs, arts, and theater uh, documentaries, international programs. Remember when I was, young, that PBS was the first place I saw C great British show, such as Monty Python and, Dr. Who <laugh> and there you go. Fantastic. So they had, contacted us a couple of years ago, but a project there wanted to do called the PBS Warren system, a Warren stands for warning alert and response network, and basically what it is, is a backup to the emergency, uh, alert system, the wireless emerging, uh, alert system, those messages you get on your phone, uh, periodically.

Steve:

And the way that normally works here in the United States is the different government entities will send the messages over the public internet to the wireless providers, such as Verizon AT&T. And then they will basically send the messages out to whatever different phones are in that geographical area. But the question becomes what happens if the internet style, how do we get those messages out to your phones? That’s where PBS comes in. The alert messages will also go to the PBS satellite up link, where they’re sent to over satellite, to all the PBS stations around the country, where then each site, our D two Warren system will take the alert messages out of the satellite feed and inject it into the PBS over the air local, uh, local broadcast. And those yeah, uh, transmission be picked up by the, the wireless carriers.

Simon:

So what are the key requirements of the system of

Steve:

Sure. First of all, the one thing that was very important from the beginning that PBS really emphasized was do no harm, um, that, you know, we don’t wanna do anything to the regular over the air broadcast. So the first step we did with that, we use opportunist opportunistic injection, where we basically replace the null packets in the stream with the alert messages. So we don’t actually modify any of the data in the stream. It all had to be very robust. Uh, so we had kind of two modes of fail-safe, and a failover. Basically, what fails safe does is if there’s some sort of, uh, CATA, uh, issue where the, uh, the hardware just, uh, you know, loses power, or if some reason fails, it’ll still pass the signal through uninterrupted. We also had, uh, fail over, which is where if the, uh, primary inserter failed, it would fail over to a backup and also required SMP for communicating between the two servers and also for remote monitoring.

Steve:

This also needs to be a single-unit solution. This is where the Ross openGear was a key component of the system. So we’re able to put two of our insertion cards, plus two satellite cards, all within a single two UR frame, uh, supplied by, uh, the Ross openGear frame. I also had to have alarm and status indicators. And one of the other key functionalities that required was flexibility and functionality. As I mentioned before about PBS and something I didn’t realize until we were actually doing this project is PBS. Doesn’t actually own the stations. They’re all actually member stations. So each one is unique. There’s kind of a same within PBS that if you’ve seen one PBS station, you’ve seen one PBS station. So we had to handle different stations and ASI some IP, some 73, 10, some a combination of all three. So it’s quite a bit, different situations you had to be prepared for once the system was deployed.

Matt:

So, that’s interesting. What, was the process? What were the key steps in? Cause it sounds interesting getting, you know, warning signal up to satellite, and then down, via TV signal and then out into the mobile network, what’s the process how’d you start to, develop that kind of tool?

Steve:

Sure. So once we awarded the contract, we spent about three months, it’s earning out the statement of work, and it’s not only a technical process but also had to get upper management approval legal teams involved. Uh, and one of the things we did during that process, which became very, important was we built in some pre-approved funding for unanticipated features, modified functionality, cuz just sometimes, you know, you, you have this great plan, but once you start implementing realize it doesn’t quite work the way, you were expecting to. So it’s good to have this sort of built in so that when these situations came along, you didn’t have to go through that whole process. Again, of getting all the upper management involved legal teams involved. We only had to get approval from the PBS Warren team that we were working with.

Steve:

And once we had that at statement of work, the next key step was to break that up into task of milestones, which could be easily managed. We actually used the JIRA management system for our project management and it’s very important also to have an iterative process. We had weekly meetings and code updates with the PBS warrant team. We worked very closely. So that way they could see week by week, how the project was coming along, they could test it in their own. They had a demo unit at their site. They can be tested when we want along. So that way we can really keep track of that. We’re on schedule, it’s working, how they’re supposed to. And this is where kind of as saying the having that pre-built in funding is as we’re going along, we ran into this issue called rain fade. It’s not familiar with that.

Steve:

That’s with satellite reception rainy conditions, the signal can go in and out. And we first started testing that was causing it to fail over to the backup quite often. So we had to kind of go in and, and tweak things a bit so that we had a better, uh, understanding of when it was just rain fade and not an actual failover. So we wouldn’t fail the system over. Mm. And once you have a system ready to go, uh, it works great in our lab, works great in the PBS lab, but you really need to get it out in the real world. So we had about 10 stations, uh, lined up for beta testing and it was really nice cuz we had a mix of somewhere. I had I some more IP, some more hybrids. We can actually see the system working in different environments before we actually fully deployed it.

Steve:

Then after it’s deployed, uh, things aren’t over yet, cuz the really, probably the key thing is support. You know, making sure, you know, we’re always there, if there’s any issues, uh, we, we support it. We add enhancements. Uh, we actually, uh, it’s not once we got the, the system out and started giving feedback from the individual stations, um, they’d be like, oh, it’s working great. It’d be really nice that did this. We took all that feedback. And about six months after it was deployed, we did another update to kind of take in all that user feedback. So

Simon:

Steve, how, how important was the open gear element in the project?

Steve:

Critical. It’s kind of under saying that those kind of, one of the key features in hu being award of the contract was to have it the whole solution within a single product. So even though it was redundant, there was two of everything. It was still all in one single to U frame. And that was definitely the feedback we had from PBS was that was, is a major, uh, decision point in us getting the contract.

Simon:

The Tod technologies has been around it for quite a while. I can’t believe this is the first custom project you’ve done. Tell us about some other work you you’ve been involved in.

Steve:

Sure. There’s a couple others, uh, which come to mind, uh, there’s three angels broadcasting, which is religious broadcaster here in the states and they were doing a satellite distribution that we had our equipment, each site receiving over the, or the satellite feed. But one thing they needed to do for government compliance was to be able to insert alert messages, and they didn’t wanna go through the expense and the quality, uh, uh, degradation by decoding and recoding it site to put the alert message in. So we came up with a method to basically take the alert message, uh, replace all the programs in the stream with the alert message for the duration. Then it’s done switch everything back. So that way they can be compliant without having to decode and reco re-encode at each location. Another custom project we did was in Mexico, uh, a system and we had called D2propel where they were also doing a site like distribution.

Steve:

And in this case at each site, they did knew that did need to do a decode and recode cause they’re inserting local content at each location. But the one issue they had though is they needed program guide information and it was the same program guide information, every location. But since they’re doing a decode Recode, if they did the, uh, program guide generation at the uplink, it would all be lost. And they, so they’re looking at the expense of having to put in a generation, uh, at each location, which would be very expensive and very redundant, cuz it’d all be the same guide information. So what we did with our system, which is already deployed at each site was we took the satellite feed in with the guide information. We take the guide information out, send it out our first output to be decoded recoded for local content. Then we take it back in our second input, put the guide information back in and send it out our second output to go into transmitter for broadcast. So that way they can only have one, uh, guide generation at the uplink and not have to have that added expense of having one at every, uh, location.

Matt:

Yeah, I think I partly was to also see whether you’ve learn anything over the years of doing all of these, uh, custom projects. They must, you must have identified some, some sort of some vital, some key elements that you and both you and the customer need to achieve. Sure. When you are entering into a custom project like this,

Steve:

Correct? Yeah, yeah. Here at D2D, we love doing custom projects. It’s, it’s very challenging. We really like that working one on one with the customer and also being a small, nimble company. It it’s nice that, uh, you know, basically with the PBS project, it’s pretty much involved in, in every, uh, phone call and meeting. So if something needs to be changed, it doesn’t have to go up through four levels of management to somebody who’s not even involved in the project to make a decision. You know, I can make the decision right there so we can be very flexible. But some of the other keys, uh, we learned, uh, was that, well, it’s important to have a, a very detailed and comprehensive statement of, of work that you should build in flexibility, cuz there’s always things that you didn’t think of or, you know, you thought would work one way, but once you actually implemented it doesn’t quite work the way you thought. So you want some flexibility built-in. You also wanna be able to break that statement of work down to smaller tasks, which would be easily manage and track. We wanna very iterate. We work closely with the, the customer. So ensure the project stays on the schedule and it’s meeting what they’re actually looking for. It’s also good that before you actually do full deployment, you wanna do some beta testing, some real world environments. Then finally just the ongoing support, uh, and enhancements based on customer feedback.

Simon:

Yeah. That’s so some good, good, good advice, sir. Steve, thank you very much indeed. For your time today, today, it’s been great talking to you. Um, you’re welcome learning about and learning about your solutions and also the open gear solutions as well. And on the point of open gear, you can check out a channel for the other other openGear partners that we’ve been chatting to over the last couple of months. Do, um, also go to D2Dtechnologies.com, where you can find everything that, uh, Steve’s been talking about. And also there’s a full-length case study on there as well. Thanks to media proxy for their support care plus TV. And thank you for watching. We’ll see you next time.

Matt:

Hello, and welcome to another Kitplus TV supported by mediaproxy. Today, we are continuing our series of open gear discussions and are delighted to welcome Jessica Colyer from D2D Technologies. Hi, Jessica. Welcome to the show.

Jessica Colyer:

Hi guys. What a pleasure it is to be here. Thank you so much for having me.

Matt:

Brilliant. So, first of all, let’s have a little bit of a briefing. D2D, what does the D stand for? And what’s your game?

Jessica Colyer:

Well, great question. We’re “designed to deliver” was the idea that it came up with. So basically, we do that. We deliver video. We do it really well over SRT primarily.

And, we have our openGear card, which we were going to be showing you at NAB, but I’m showing it to you now virtually, which is great. But we primarily make multiplexers, and we send signals via SRT whether we’re receiving a bunch of signals and muxing them in or demuxing them. Or sending out signals like is in a hub and spoke, where you have a central station and then translators all around.

And as you know, the US is big, and there’s a lot of translators everywhere. So this has really become a big deal in the United States for smaller stations that can’t really afford satellite. At $200 an hour or whatever a satellite is. Now, people can actually take their ASI signal and send it through the common internet and boom; it shows up as a satellite signal in their control room. It’s instantly genlocked and plumed into the switcher, and it makes it really easy for people to either use it as contribution or to use it as distribution. So it’s pretty much a game-changer in my mind for the distribution and contribution markets here in the US. And, and now it’s going global.

Simon:

So I guess as people are moving away from satellite now, your business must be exploding with more and more people wanting to do this.

Jessica Colyer:

Yes, actually, it is. And in fact, now that a lot of people are doing everything remotely because of this pandemic, we have weather people now that are inside their bedrooms, or wherever they are, in their living rooms doing weather, and this is really easy. We just basically have a throwdown box you could put down at the other end and plug a cheap encoder in there, or a good encoder, whatever you like, and it’s an instant ASI signal out to the station. And again, all they got to do is plug it into a satellite decoder that takes ASI in, which most stations have literally dozens of satellite decoders in there that are just collecting dust. Now they can reuse this platform because the decoders are coming out, and they’re already genlocked into the switcher and ready to come up as a received site. So it made it really easy for a lot of stations to add beauty cameras, and remote anchors, and remote weather people, cooking shows. Everything! So it’s really, really changing everything as we know it.

Matt:

That’s great. I mean, we know all about doing green screen from home; it’s what we’re doing here now. So that’s great getting the remote talent in. Is this improving people’s ability to set lots of channels? This is distribution as well. This just means that you can just chug out hundreds of channels. Yeah.

Jessica Colyer:

Exactly. And now that basically what’s happening is the slices in the pie are getting smaller. Back in the day, when digital came out, everybody was given 19.3962 megabits per second to play with. And that was pretty much it back then; that was one channel. But then they realized, oh, well, now we could start adding more and more and more channels.

So this actually adds revenue to a lot of stations, and it has begun a big birth for the LPTV market here in the United States, which is, I don’t know, you guys, you’re old enough, you’re a member cable access. When all of a sudden the cable company decided they had a whole bunch of bandwidth they could give away. Well, this is actually really great because it’s adding a lot of content that other people wouldn’t ordinarily see, specifically out on some of the low lying rural areas where people can’t afford cable. Now LPTV is springing up with everything from cooking shows to QVC, which is a shopping channel. There’s a lot of religious and worship, and educational out there. And again, it’s also adding in educational TV as well. So it’s a big deal.

Simon:

And I suppose that then leads on to how they can use SRT to get contribution video into the channel as well.

Jessica Colyer:

Exactly. Yeah. As I said, you could either have… Now you can have your weather person at home, or in some cases, beauty cameras, or there’s a station in Chicago that’s actually talking with a newspaper. And every day, they like to do an entertainment report from the local newspaper in Chicago. And back in the day, they would have to pretty much either set up a microwave link or they’d have to set up a sat shot, or something to that effect. But now they could just use this box and bring that in as contribution every day. And it’s the simple as plugging it into an IRD, which is just an integrated receiver and decoder in their control room.

Matt:

Yeah. I’m going to ask you to expand a little bit on a phrase you used a moment ago, which is new to us, but it might be quite a common phrase over there, but hub and spoke.

Jessica Colyer:

Yes.

Matt:

Give me a bit of an explanation of what you mean by that.

Jessica Colyer:

Well, you think of a bicycle wheel, right? And you have the hub and then you have spokes that go out everywhere else. So basically, your TV station or your head-end, as they call it, would be your hub. And then now they can easily send out spokes. So a good example was a religious broadcaster here in the United States that had one central church. And obviously, with COVID happening, people couldn’t go to church anymore. So they were able to take their message and send it out pretty much all over with very minimal bandwidth to different LPTV markets and full-power stations. So basically, they were the hub, and then they could use the openGear SRT card in a Ross frame

 a

nd just send them out. And then the way that these throwdown boxes are set up, is basically you can just toss it down, you plug internet in the back, and then ASI magically comes out so they can instantly broadcast their message. And they were the hub and everyone else that receives it as a spoke.

Simon:

And is that the openGear is 5220 card that you’re referring to there?

Jessica Colyer:

Yeah. Actually, we’ve reimagined it, and now it’s the 5220. So it’s already grown a generation. But yeah, that’s basically this card, which just takes up two spots in a Ross openGear frame, and it can send out up to eight spokes, SRT streams, or receive eight spokes. So the opposite to hub and spoke would be spoke and hub. So you have a hub, and here you’re pulling in all different kinds of contribution. And then it’s going one ASI out to your encoder, your transmitter, whatever.

Matt:

So what other benefits are there to this system? If they’re distributing it out to all of these different places in the hub and spoke, what other benefits does your solution bring?

Jessica Colyer:

Well, that’s a great question. Actually, once you get the signal from point A to point B, let’s say you are a spoke and hub. Well, the thing here is, the FCC could want to change. So you might be say, WXYZ in Albany, New York, but you’re setting the signal out to Clovis, California. And it’s going to be K321 or whatever. So the nice thing is we have the ability to rebrand that virtually, as well as change the channel number. Because what might be channel 42-3 in New York, might be 55-1 or -7 in California. So rebranding is the being key. Even though you’re setting out the exact same content, you can rebrand it. And then also add in local EPG, which is your Pissup, your channel guide. And then more importantly, you can also add in a local emergency alert.

 So if there should be a tornado, or a hurricane, or in the case out here in California, a fire, alerts could be sent in at the local level, even though the programming is coming from 2000 miles away. 

And so we were actually very instrumental in using the openGear chassis as well as our 3220 card for the public broadcasting system here, PBS, in the United States. We established their warn system, which was basically a wireless alert EAS system. But what PBS was thinking of, for instance, here in California, when there’s a fire, they shut the towers off, they shut the cell towers off, so you no longer have cell service to warn you that fire is here, you can now turn it on your TV and get the same alerts through PBS, which was basically a text protocol of what the alert is. So, in addition to setting the signal out via SRT, multiplexing it, or demultiplexing it, we can also add Pissup, rebrand it, and add an EAS alert, all with this one openGear card.

Simon:

So Jessica, where can people find out more? Because I think you’ve also got an online SRT guide somewhere as well, haven’t you?

Jessica Colyer:

We do. In fact, if you go to our website at d2dtechnologies.com, there is some support and some resources. And of course, you’re always welcome to give us a call. Our numbers are on the d2dtechnologies.com website. And I like talking to people. So I would love it if you’d call me. And if you’ve got more questions, we’re here. I’m not getting to go to NAB, guys. So this is it. It’s my booth. So yeah. Please call-

Matt:

We’ll see you in April.

Jessica Colyer:

… Or reach out. Let’s hope so. Yeah. Let’s hope so.

Simon:

Yeah. We really enjoyed talking to you as well today, Jessica. Thank you very much-

Jessica Colyer:

Likewise.

Simon:

… For your time. And as we say, fingers crossed. I’m sure we’ll get together in Vegas, April, 2022.

Jessica Colyer:

Oh, I hope so.

Simon:

And as Jessica says, do head over to d2dtechnologies.com, where you can find their SRT guide. You’ll find it under the resources menu, I think. Thanks to mediaproxy for their support of Kitplus TV. And thank you for watching. We’ll see you next time.

D2Monitor is an Enterprise level
monitoring and alerting platform that
provides a comprehensive view into all of
the D2D systems. From the intuitive
dashboard that provide real time status of
each system, you can drill down and get
the details you need to address issues that
may arise. With D2Monitor you get the
monitoring and alerting you need to
maintain a reliable and high quality
operation.

Grab a datasheet.

Secure Reliable Transport (SRT) offers a truly amazing way to secure and move streams for OTA broadcast operations, and we’re seeing a lot of new stations take advantage of this technology to optimize video streaming performance — and video quality — as they transport video across unpredictable (but economical!) networks.

But why stop there in using broadcast technology to support and simplify your operations? No matter how many inbound and outbound streams you manage, you can benefit from a centralized monitoring model — and our new D2Monitor solution makes it easy.

Whether you’re working with a hub-and-spoke model, a bunch of point-to-point links, or delivery of ATSC 1.0 signals to a “lighthouse” transmitter, you can use D2Monitor to keep an eye on every stream, all the time. Consolidate monitoring across your operations, and you radically reduce the amount of time it takes to check in and confirm that a stream is up and uncompromised. No more logging in to each device! Instead, you pull up a single window, where you can get real-time status data for each and every stream.

When you consolidate monitoring, you also make it possible to configure automated notifications and alerts in the event that any device goes down or metrics (bandwidth, dropped and retransmitted packets, etc.) fall out of an acceptable range. What’s more, with continual access to these metrics over time, you also gain a historical view of stream health and network performance. You can identify patterns or recurring issues that point to a problem with an upstream device. With past performance data in hand, you’re also equipped to speak with your ISP about resolving network issues.

Rather than wait for that alert that a stream has gone down, you can be proactive in maintaining stream and network health, preventing issues from getting to the point that they can compromise the viewing experience or make it impossible for audiences to watch your programming.

Running a broadcast operation involves enough complexities when all streams are healthy and moving across the network smoothly. A convenient centralized monitoring solution such as D2Monitor helps to keep things simple, allowing you to confirm at a glance that everything is OK — or sending you a notification or alert when it’s not. With peace of mind that you’ve got monitoring of all inbound and outbound streams covered, you can focus your time and energy on other parts of running a broadcast station.

Download the guide here

Transcript:

Steve:

Glad you could join us today. If you need to monitor your on-air chain, you’re in the right place. Today you’ll find out about a station group and how they consolidate all their monitoring and status into one place, find out more about lighthouse applications, and have a look at D2Monitor in action. We’ll finish with a QA session, so if you have any questions along the way, just go ahead and put them in the chatbox and we’ll answer them all at one time at the end. I’m Steve. I’m here today with Jess. Hey Jess, how are you doing?

Jess:

Hey, Steve. I’m doing great. Very, very excited to be here. This is a much-needed product. Excited. How are you doing?

Steve:

Doing good, so let’s go ahead and get started. The first thing we’re going to talk about today is a station group. Actually, it’s owned by Keith Leach, who has actually joined us on the webinar today. And what Keith is doing, he’s with One Ministries and they have about five-point to point links. They’re in the bay area. Mostly received sites are on remote mountaintops with limited bandwidth, so this makes a very challenging network, which is ideal for SRT. SRT can re-send lost packets when things get on these band limited networks. So when they get lost, it’s able to recover, and it can stay on the air, even in the event of these significant packet losses. Because of these challenging routes, it’s also very important to be monitoring them. So in case one of these satellite or network links does go down, we can inform the station group and then they can let the network provider know and get it corrected and have the issue corrected properly. Another type of application using something similar as a hub and spoke. Jessica, I believe that GBN is using that type of application.

Jess:

Yeah, Global Bible Network. They basically have, I guess what we’re calling a hub and spoke, which is one location that sends out to many different locations. Kind of like a bicycle, hub and spoke. And they have a TOC area, and then they’re sending it out to ministries and television stations all over the country. And so it really would behove them if they could keep their eyes on everything going out at one time, especially being that some of the outlying areas where they’re sending the signal to aren’t really television engineers. Some of them are IT people, some people are just not technical at all. So it’s really a good idea if they had some way to keep an eye on their entire chain in one spot.

Steve:

That’s great. So there’s kind of a couple of ideas, examples here of multiple point to point locations or a hub and spoke where you’re sending out and you’re using all these separate routes all across the country, using the public internet. So it’s very important to keep an eye on the quality of those routes. And also, as Jessica was saying, a lot of times at the endpoints, there may not be an actual station engineer there. So sometimes it’s kind of good to have… Where we can get on there and kind of see what’s going on and kind of give some added engineering support here, remotely. Another thing we do that’s sort of the opposite, instead of the hub and spoke, we have the spoke and hub, which good application. It’s like Jessica’s lighthouse application.

Jess:

Right, exactly. So especially with ATSE three coming up and it’s eventually going to, I guess, become popular eventually. What’s going to happen is, every station is going to put their ATSE 1.0 into a particular lighthouse transmitter. So that way, it’s going to be a legacy for those that aren’t ready to go to. ATSE 3.0. It’s going to be very similar to what we did about 20 years ago when we went HD and all the stations still had to send an old analog signal for those that weren’t in HD yet. So in this kind of case, every single station is pretty much going to send their dot one channel to a lighthouse, one way or the other, whether it be microwave. But in this case, if you’re sending it SRT, which I think is probably how a lot of people are going to do it, this is the exact opposite of hub and spoke. It’s where there’s a whole bunch of spokes coming into one hub, and again, it’s going to be really nice to keep track of all of the feeds coming in at one time.

Steve:

That’s kind of a great application therefore using both SRT and the monitor. Kind of see all these different routes coming into one location, making sure they’re getting there properly. Now we’ve kind of been talking a little bit about the D2Monitor and SRT and how they interwork and some different types of applications. So now let’s actually take a look at D2monitor in action. So I’m going to go ahead and share a screen here so we can see it. Jessica, can you see that?

Jess:

Cool. Yeah, yeah. I got it.

Steve:

Okay. So kind of what we’re looking here, just a little bit here. So I’m logged in as an employee of D2D, so I can actually go into the company view and select which company units I want to look at. If you’re a customer, you would just have your own views. You’d just see your own unit. So right now, what I’m looking at is just some test units we have as we’re kind of developing D2Monitor and just working on our own units, so that we can monitor them. And one particular interest here is, you go down here and we have a unit here called San Diego, Jack sent. So that’s actually out of Jessica’s location, San Diego. And you can see she’s actually here. It’s picking up an ASI feed, which is coming up on a local TV station there. Then she’s routing it out to her ASI output so she can monitor the signal there locally. And then she’s also creating an SRT listener, so that somebody can pull that stream.

Steve:

And then what’s happening over here, you can see in San Diego, Jack’s received, which is actually in a unit sitting right behind me here. I’m pulling that signal into my ASI and then I’m sending it out… Or excuse me, I’m pulling it into my IP here. You can see that she has her listener set to port 3008. And then you can see over here, on my SRT caller, I’m basically calling her Wayne address with that port number. That makes the connection, and I start pulling the stream here. And then I’ve taken one of those channels, the channels she’s sending me, and taken out ASI so I can view the program here. So we had this nice route going from all the way across the country, from San Diego to Jacksonville, and monitor both ends right here in one location.

Steve:

One thing I’m going to do here now is, I’m going to… I’m basically going to shut down. So as I just announced, I just shut down the San Diego Jack’s received unit here. And what you will see is, you can see here now where the sent unit is still the uptime. It’s still going up here. You’ll see the uptime is not updating on the receiving end because it stopped sending messages. And what we should see hereafter… It takes a minute because we don’t want to kind of send any false alarm. So we do wait for a minute of a unit not checking in before we actually declare it off-air and go into an alarm state. We’ll just give it a little bit longer here, and we should see it switch over. But while we’re kind of waiting for that, we can also see that Jessica has got another one of her units here. This is actually one of our 52 20s, which has a lot more inputs and outputs.

Steve:

And you can see that it is kind of… She’s got multiple routes coming here and multiple IPS going in to ASI so she can monitor all this, to make sure everything’s looking proper. And as you can see now, it just grayed out, showing that… Now you’ll see that no longer shows an uptime. It now wants the last check-in, showing this unit hasn’t checked in, in the last now minute, 12 seconds. It’s now showing it’s offline. And if you go over here to our D2 care, it’s actually sent us a notification that that unit failed to check-in, and it gives us an indication when it last checked in. Then at the same time, if you’re a customer, you would get that same email. So it’s notifying both us and you, that that unit’s gone offline.

Steve:

So then we can go here. I can actually restart that unit back up. Okay. And you’ll see that it’s come back online and reconnected to Jessica’s unit. Everything looks good. Then at that point, we can go over to the alarm’s page, and you’ll actually see that the unit was alarmed here. Now one thing we do is, once a unit has been alarmed and we have sent an email notification, we do flag it that it’s alarmed. Because one thing we don’t want is, if there’s a bad network and the network’s been up and down every five, 10 seconds, we don’t want to send an email out every five, 10 seconds. So once it’s actually been alarmed, we flag it. And then it won’t alarm again until you actually come over and clear the alarm. So at this point, that unit will not alarm again, if it was to ever go off.

Jess:

It’s brilliant.

Steve:

Then also, I was talking a little bit earlier about One Ministry. So we can go here, and I’ll switch over to his units, and you can see all the different routes he has going on. This top one here, you send in from… Cato unit sending here, to the received. Everything’s looking good. But one thing that gave me an idea of just how effective SRT is. So here’s a site he sent into, that he sent in his programming to the dove, which is a religious broadcaster. And so this unit’s been up just for three days. Yeah. Just under four days, this unit’s been running. And in those four days, it has lost, or there’s been almost one and a half million packets that have had to be retransmitted.

Jess:

Wow.

Steve:

But not a single package has been dropped. So that kind of just gives you an idea of what SRP is capable of, that it can recover from a million and a half retransmitted packets in just a matter of four days. So it’s a really effective technology for sending stuff over the public internet.

Jess:

No doubt.

Steve:

So that’s kind of a little example of the capability that the D2Monitor service is capable of. And it’s kind of nice because not only do we get to see it, but if you’re a customer, you get to be able to see your units as well and be monitored, be alerted of anything, if you go offline, if any of your inputs sync. So now that we’ve kind of shown you a little bit, we’re going to open up to questions here, see if anybody has any questions. And as I say, everybody’s muted, but if you have any questions, feel free to enter it into the chatbox and we’ll go ahead and get those answered.

Jess:

Hey Steve. Yeah, we actually got a couple of questions already coming in. Let me see. One would say, how would this work with OTT services over the top?

Steve:

I guess it depends on which particular OTT service. Most of what this is here, is using basically transport syringes and SRT. We are adding some capability to use more of an HSL type, which would be more of a traditional over the top. And once we have that in our system to support that, it would work just the same. On here, you would see a similar type. Instead of this being SRT, you could see something about HLS or whatever other over the top protocol you’re using. So it should work seamlessly within monitor, once we just add the support for HLS within the flex system itself.

Jess:

Great. Yeah. That’s true, I guess. That’s a great question. Got another question about, how often does it polar update? How often does D2Monitor ask for information?

Steve:

So currently, it basically is broadcasting every three seconds. That’s kind of set right now. We are kind of looking into possibly making that more user-configurable, if they want to kind of either speed up or slow down how much it is updating. But you get an idea. If you see here, you should see kind of these… In this particular unit, the uptime should be changed about every three 15, then she got 18. So it’s basically on a three-second interval at the moment, is how fast it is sending it out its status.

Jess:

Great. So about every three seconds, I guess, is when it updates the status.

Steve:

Yes.

Jess:

Very cool questions flying in right now. Would this work with SMS text messaging?

Steve:

It doesn’t. Well actually, it really should. We were actually talking with the developers earlier, and you should basically… SMS is really just sending an email to that phone address, so that actually should work. Have to talk a little bit with them how we actually enter it into the system, what the format is. But you should be able to basically send the email to a phone, which will show up then as a message within your phone text.

Jess:

Right. On my phone, my email and text messages pretty much come in the same amount anyway. So, I guess you could have your email forwarded to a text message. More questions. Is there a way to see an error to an individual stream? So if a particular stream went offline.

Steve:

Well, that’s what I was showing. So that’s one thing we’re showing here, we don’t actually have here at the… Not showing here at the moment, but you could… Yeah, but it would show if an individual stream lost sync. I mean, that’s kind of the question. So, that is kind of one thing it’ll alarm. If one of these IP streams, or you had ASI in this case enabled, and we’d lost sync on that for a certain time interval, that would also alarm as well.

Jess:

Okay.

Steve:

So it’s not just the unit going down, it’s also the loss of sync on the input. So what’s kind of really nice about that is, just the nature of a lot of the applications we do is, the receive unit is right there at the transmitter. So it’s kind of right there at the end of the chain. So by looking at our input, you can see if you’re having an issue somewhere upstream. So if we were to kind of lose sync on our input, we could let you know that, “Hey, you may want to check your upstream multiplexer, your upstream encoder, because something happened to the stream coming into us.” So that’s kind of a really nice thing about us being at the end of the chain, that we can sort of monitor all your upstream equipment as well.

Jess:

Great. Yeah, that’s a great answer.

Steve:

And another thing, I guess along those lines, that we’re adding into it. So right now, we’re basically detecting that the unit stops checking in or we lose sync. But some of the things we’re going to be adding here in the near future is, monitoring continuity counts. So if the streams coming in but you’re just losing a lot of unpaid packets, kind of another indication you may want to check your upstream encoders or multiplexers, see what’s going on. So one of the things we really want to do with this is, by kind of monitoring some of these statistics, like for the network of SRT, if you are getting a lot of retransmissions or you’re getting some drop packets, to kind of let you know about this so you can try and work your ISP to get it fixed. Because if you have just a handful of dropped packets, it’s probably okay. You may see occasionally a glitch in your screen. But if it continues to get worse over time, you may get to the point that you basically end up going off-air.

Steve:

So one of the things we really want to do with the monitor, is not just letting you know when something has happened to take you off-air, but to give you some indications that you’re kind of heading that way and let’s get it taken care of before your viewers can’t watch your program. So we want to kind of avoid that at all costs and try and be more proactive instead of reactive.

Jess:

Right, of course. Because engineers don’t like getting that call on a Monday morning saying they’re off the air half the weekend, right? Or whatever. So this sort of is proactive to not going off the air. And I could imagine, this whole gooey right now that’s in front of us, being up on a monitor in master control or something like that so everybody can have an eye. And when I see a red barn, they know to go and look into it. So that’s actually a good segue into the next question, which is, is there any plans to add a transport stream analyzer? I guess they mean, a TR 101 290 deck tech or send core type transport stream analyzer.

Steve:

Sure. That’s a great question, Jessica. And that’s kind of how we talk a little bit of soon be having the ability to trigger on continuity count errors and things of that nature, or transport stream error indicators. So in the monitor itself, it’ll probably be more just these… You’ll see more of the global type analyzer things and continuity count errors, total for the system, transport stream error indicators. But we are basically putting in a DTR 290 analyzer within the flex system.

Steve:

So what you could do… The monitor may show, hey, you’re getting a lot of continuity count errors on this particular stream. And then what you can do is then, login to that stream where it’ll give you… Or login to that unit, where it’ll give you access to the full monitor where you can actually drill down and see continuity count errors on individual PIDs, bit rates on individual PIDs. Putting capabilities into do PCR jitter detection. So that’s ongoing, and that’s a lot of information to be constantly sending back to the monitor. So be kind of more… There’ll be more global statistics, which will be sent back to the monitor. And then if there’s an issue or a unit or stream which is having a particular issue, then you would kind of login to that particular unit and see the full analyzer.

Jess:

Right. Okay. Yeah, great question.

Steve:

Oh, go ahead. Yeah. You’re kind of getting ahead of me. Let’s see what the next question was. Or you may be kind of predicting where I’m going.

Jess:

Well, they’re coming fast and furious. So the next question is, is there any way to control the units through RSSH or some other way, through a VPN? So for instance, if I do need to get to a flex 3000 that’s at a mountaintop 3000 miles away, can I do it through this platform?

Steve:

Correct. So, you definitely can do that. A few things we’re working on at the moment. One, right now with the VPN. So here at the NOC, we have the D2Monitor server. It also has VPN supports, so all the units would ship out now. You have the capability of basically putting in the VPN credentials, check-in your unit to the VPN, and at that point… We’re soon adding here, where if you are connected to the VPN, there’ll be a little link here just pressing that. It’ll take you right to the login page.

Jess:

Wow.

Steve:

Of the unit. And there’s some other things. If you’re not on the VPN, we’re looking at some things which may be able to give us full access if you’re not on the VPN. But at a worst case, we will be coming out with, even if you’re not on the VPN, the units will be basically able to pull commands from the monitor using HTTP, or at least be able to kind of tell the unit to… So here, you have all these statistics of how many packets are retransmitted.

Steve:

So there’ll be the capability to at least send commands to the unit to clear the statistics, so you can see more current statistics or to reset the unit or command it to go download the latest firmware and install it. So we at least have, if you’re not on VPN, where you can send the commands to do different things. We’re not sure yet if we’ll be able to get the full user interface if you’re not on the VPN. But if you’re on the VPN, there is no problem with… We’ll have a link here, you click on the link and it’ll take you right to the login page.

Jess:

Wow, great. That’ll be handy. More questions. Is the loss of sync only on ASI or would it work with the loss of SRT also? So if you lose SRT, would that also generate an error? I think I know the answer.

Steve:

Correct. Yeah. The loss of sync on any, whether it’s IP or ASI, will generate an alarm.

Jess:

Any input? Great. Yeah, of course.

Steve:

Correct. And actually, any output as well. Typically, there shouldn’t really be an issue on the output. But if for some reason we’re receiving, it’s supposed to be going out and it’s not going out… Or it could be something for whatever… Just a configuration got changed, and now you had an output that was enabled, but you’re no longer sending anything to it. It will generate alarm that may be kind of an indication that, oh yeah, I didn’t quite set this up the way I wanted to. Or you may want to just then disable that output if you’re not actually using it. So it will actually alarm if an output is enabled and also doesn’t have any data going out on it.

Jess:

And it looks like we lost your D2Monitor screen. You must have shifted off of it somehow. There you go.

Steve:

Is it back?

Jess:

Yep. Perfect.

Steve:

Are we seeing okay?

Jess:

Yeah.

Steve:

I guess I did the screen instead of the window.

Jess:

This next question is really good. I would imagine, in the future, it’s possible. Is there a way to see a thumbnail or proxy of the video stream? Kind of, I guess, like what Ts reader does.

Steve:

That’s things we’re kind of looking into. It may be something that, maybe if you click on a unit that you could do it. Because one of the potential issues is, it starts becoming a lot of bandwidth. If there’s a lot of units being monitored and they’re all sending back video streams, that could get quite data intensive. But that’s something we can definitely look into putting some sort of thumbnail. Maybe even if it’s kind of a slow update. So you may not be able to watch true video, but at least see there’s… Every few seconds you’re seeing a new frame pop up, to know that there is something on air.

Jess:

Yeah. Just not good enough for QC, but good enough just for monitor control to see that it’s there, which I would think that would need another rendering machine because that would take up an enormous amount of hardware and bandwidth. So it’s a great question though. I think I could see that happening sometime in the future, without a doubt, especially if people request it. Next one. I think I already know the answer. Is there a way to encrypt by using AES, SRT?

Steve:

Well, for SRT specifically?

Jess:

Yes.

Steve:

Yes. You can encrypt SRT. This screen actually here right now, is not encrypted. But yes, it does support AES encryption for SRT, if you do want to encrypt your stream.

Jess:

And he used a passphrase, I think it’s eight, 12 or 16 different digits.

Steve:

Correct. Yeah, which kind of correlates to, is it AES 128, AES 256 or AES 512. Each one gets more and more encryption to it, so that it does support different variants of AES.

Jess:

And I can say that it works great, because we had to do that with… I don’t remember the customer, but I remember we had to help him get his AES set up. I believe it was someone at Fox.

Steve:

There’s also the guys over in Europe, who were doing some European soccer games.

Jess:

That’s right, and they wanted AES encryption. So yeah, we got it working. One last question. Does the SNMP platform work with solar winds or Nagios or some other SNMP platform?

Steve:

Correct. Yeah. So let’s say the unit, once you kind of configure the D2Monitor, it will be broadcasting the status every three seconds. So if you do have some sort of SNMP aggravator, it can’t do that. Kind of develop your own view, you won’t get all the nice colorful boxes and the email. All that stuff would have to be… You’d have to develop that on your own.

Jess:

Sure.

Steve:

But as far as the data itself, is available over SNMP.

Jess:

So it’d work that way. I like this interface because like I said, if I was a chief engineer, I would have this up in master control or TOC so that whoever’s operating, or if you walk into the room, at one glance, you can see that all of your links, whether they’re coming or going, are working and happy. And so it’s really, really a great platform. I think it’s really, really, really well needed. Looking to see if there’s any other questions. Let me look through the chat here. I think we got a lot of great ones, but I think that’s it. Anyone else have any last questions? Bueller? Bueller? Oh, wait, hold on. A lot of great questions. I’m really excited. When is this available? Good question.

Steve:

Oh, it’s available now. It just kind of came live, so it still is kind of in a beta situation, but we’re definitely looking for people to come in and kind of join up for it. And as I say, we can do this. As we’re showing here, these units here have finished all tests. When I go back to One Ministries, these units are all live on the air, broadcasting. So it is actually up and running.

Jess:

Yep.

Steve:

So if anybody wants to kind of check it out, just give myself or Jessica a call and we can help get you set up.

Jess:

Cool. Yep. Awesome. Yeah. And if you’re curious about pricing, probably best bet is to give us a call. The last question that came in was about pricing.

Steve:

Correct. And that’s something, as I say, we’re still kind of finalizing everything. But if you give us a call, we’d be happy to go over that with you.

Jess:

Yeah, we’ll work it out. Yeah, definitely. For sure. It looks like that’s it for the questions. There were a lot of great questions. A lot of great comments.

Steve:

All right. Okay. It looks like, actually… Okay. All right. So any other questions? Not seeing any more come in.

Jess:

No.

Steve:

So, okay. So today, this was a really great webinar. It’s a lot of great information. Today, you learned about keeping track of all inbound and outbound streams in one spot, automating SNMP alerts and emails when it goes offline or loss of sync on an input. Identifying and resolving issues before they affect your viewers. And so it’s just a lot of really great stuff going on with the monitor. And hope everyone was able to learn something today, and please contact us if you have any more questions or would like to try out the D2Monitor.

Jess:

Thanks, Steve.

Steve:

So have a great day, everybody.

Jess:

Great webinar. Thanks everybody. Have a great day. Call me if you need anything.

Steve:

Hello, everybody. Glad you could join us today. Customer projects in the broadcast world, it can be very challenging, but there’s some key development practices that will help you with your next project to be a success. Today, we’ll go over some of those practices by doing a case study on a recent project we did with PBS to update their Warning Alert and Response Network System, otherwise known as PBS WARN. We’ll finish with a Q&A session, so if you have any questions along the way, please add them to the chat, and we’ll answer them all at the end. I’m Steve, I’m here today with Jess. Hello, Jess, how are you doing?

Jessica:

Hey, Steve. I hope you’re doing well, and welcome everybody. Thanks for joining us. I’m really excited for today’s webinar, very informative.

Steve:

Great. So, I guess first thing, let me just take a moment to explain what is the WARN system? I’m sure everybody’s familiar with the alerts you get on your phone, your Amber Alerts, Silver Alerts, some Weather Alerts. And the way that typically works is the messages get sent over the internet to the wireless carriers, who will then send it out to cellphones as needed. But what happens if the internet goes down? What’s the backup system? Well, you’ll probably be surprised to learn that it’s actually the nationwide footprint of the PBS member stations.

Steve:

And the way this works is the messages are also sent by government entities, such as FEMA, to the PBS satellite uplink. And from there, they go up to the satellite, which goes out to all the PBS stations. And then, from the PBS stations, when it comes in, with the PBS WARN system, we developed, does is it’ll take those messages out of the satellite feed, and then inject them into the PBS over-the-air feed. So, now you have this nationwide over-the-air system, which is sending out the alert messages, so the different wireless carriers can get the messages, and then deliver them out to your phone.

Steve:

So, that’s just kind of a little bit of an idea of what the wireless alert system does there, or what the PBS WARN system does. A few of the key requirements which was needed for the system. One, it needed to do opportunistic injection. Basically, what that means, is that it uses null packet replacement. You don’t want to affect the transport stream. So, you replace null packets with the wireless alert messages. On the case that there is no… null packets are very few, especially in cases where people are using stat boxes to kind of really squeeze as much out of the risk capabilities in there that it will actually… First their null packets and we’ll use the IT and ETP PIDs. And in the worst-case scenario, if none of those are available, either there is also a user-configurable PID, the spatial set, that it can use to do the alert messages. It also has to be fail-safe and fail-over.

Steve:

And what that means is with fail-safe, it needs to basically fail gracefully. If something happens, you don’t want the system to suddenly go off the air, so it needs to fail gracefully. But in addition to that, it should also fail-over to a backup redundant system. So, not only does it fail and that caused the issues, but if you still get the alert messages sent with because it will fail-over to a backup system. It also needed to support SNMP messaging. It also needed a single unit solution. One of the things PBS wanted to change from the original warrant system is that it was made up of individual components. So, it took up a lot of Rackspace, just a lot of different user interfaces you had to use to talk to it. So, they wanted to get it trimmed down to just one device. And it also needed to support IP in and IP out.

Steve:

Since a lot of station is now transitioning to an all-IP infrastructure. Also needed a lot of alarm indicators, all the different things, that different message type errors. If there are any issues with the power supply, the fans, communications between the cards. So, it had a very robust alarm system, which will also manage the glow bar on the front panel of the open gear frame. And one of the key things, which is kind of unique about this PBS project, is it really had to be flexible in function. One thing I didn’t really know until I got involved in this project was that PBS doesn’t actually own the PBS stations.

Steve:

They’re all independent member stations. And just kind of made this very challenging, but also very a fun project to do because each PBS station is different. Some maybe using ASI, some maybe using IP, somebody’s using SMPTE 310 and the other use combination of all three. And also, where they placed the WARN system. It could be different. It could be before the multiplexer, after multiplexer. Sometimes there may be a need that there is no incoming stream to inject into, so we have to generate our own null packets to be able to inject WARN messages into. So, that kind of made it a very interesting project, in that sense.

Steve:

So, now let’s talk a little bit… Oh, actually, one thing I was going to say about that, about PBS stations, which is kind of a phrase I kind of learned in this project is, “If you’ve seen one PBS station, you’ve seen one PBS station.” Because everyone’s unique, you’re going to run into different things at each station because they’re all independent. Now, let’s talk a little about the process of working with PBS WARN team, and some of the keys to a successful custom project. So, once we were awarded the project, the first thing we did was spent about three months hammering out the statement of work. It was a long process, if you’re trying to kind of think of everything which needs to be covered, everything that used to do and try and think of every potential thing which could happen. And another thing which makes that process a long process is because it’s such a big project and scope that it has to be approved by all the C-level executives at PBS.

Steve:

It’s got to go through our legal team, PBS legal teams. There’s just a lot of behind-the-scenes involvement with other people, as well. So, because of that, one of the things we built into the statement of work is sort of pre-approved engineering hours. Because one thing we know from experience is you come up with a statement of work, and you think everything’s great, but once you actually start doing it, you start realizing, “Oh, we didn’t think of this.” That we’ve got to account for this possible thing. Or, you kind of get everything done, and you’re kind of looking, and it’s just not working the way you envisioned it. You have to make modifications, so it’s good to add this flexibility in there and what allowed us to do since these engineering hours were already pre-approved. When you came across these situations, all we needed to do was to get approval from the PBS WARN team to move forward with it.

Steve:

We didn’t have to go through and get everything re-approved by all the C-level executives go through legal against that really helps as you go along in the process if you have some flexibility built into the statement of work. Next thing, once we had the statement of work, is you want to break that up into small manageable tasks and milestones, and then have some sort of a project management software. Here at D2D, we use Jira, so it really helps when you break these tasks down. You can assign them to the engineering team and really allows you to manage the project to make sure everything’s staying on track. Along those ways, one of the most important things you want to do, in a project of this scope, is to have a very iterative and agile process. Because one thing you don’t want to do is kind of work out this statement of work, and then you go off for six months and develop it, because even if you do it exactly as described in the statement of work, it’s not going to be what the customer ultimately wanted.

Steve:

As I was saying before, there would be things that you didn’t think of, you don’t include, or things that just didn’t work the way you thought. A good example of that, for this project, was once we had things kind of functioning and we started kind of doing testing, we came across the issue of rain fade, which is quite common in a lot of stations throughout the country, where you have, due to different falling weather, rain, snow, that the satellite feed will come and go.

Steve:

The way the system was originally designed is, it’s supposed to receive a heartbeat every 30 seconds. So, if this is a couple of heartbeats, it would think, “Oh, something’s wrong.” And it will switch over to the redundant system. But in areas where you have rain fade, that’s going to happen quite often. So, we had to kind of come up with some ways to kind of better determine if it was rain fade or if there’s really an issue. One of the things we did was, if we miss a couple of heartbeats, but we can still talk to the satellite card, we would think it would be a good indication that it was just a rain fade issue.

Steve:

And we’d wait a longer time period of missed heartbeats before we actually switched with… We had to put a warning out at that time, but it would be a longer time period, which is configurable, but defaulted to around 10 minutes before it actually thinks there was a true failure and switch over to the backup system. Now, once you have your system between the customer and the vendor, you think you have a system which is good and ready to go, it’s really key to get it out to some beta stations in the field and get some real-world testing on it. Because one thing you will find is, if one is in a different environment, things may work a little different than they do in the lab. And another thing is, ran across this a lot in years of being a developer, as you’re developing things, you sort of have a preconceived notion in your head of how it’s going to work, how people are going to use it.

Steve:

And what you realize is, once it gets out there, people can do things you’ve never even thought of. They’re going to try certain things. It’s like, “Why would somebody try that?” But it’s a new system, and they’re just trying different things. And so, it’s really good to kind of get it out there and kind of get a good feel for how people are going to truly use it in the field and see what changes you may have to make because of that. Then, once it’s finally deployed another key aspect is support. And I’ll let you talk a little bit about that, Jessica.

Jessica:

Sure. Thanks, Steve. Yeah. Well, obviously, when you’re deploying something that really has no history to almost 200 stations, there’s obviously going to be a lot of support. And the thing about support that we did on this project, and what I feel is always the best way to do it, is to document things from the beginning. We started the manual based on the statement of work on day one. And then, we handed it over to PBS and we sort of wrote it in collaboration together and it worked out real well. And the other thing we did is we wanted to make it really easy for people to get ahold of us. So, if they have a problem, we gave them a special phone number. We gave them my personal emails and the support personnel email. So, for some reason I’m busy, they could get ahold of somebody else.

Jessica:

We also gave them a web portal on our website, so they could go there and get all the latest manuals, the latest firmware. There was a frequently asked questions on there. And then, at the same time, they could either submit a ticket through there, through our Jira, or that he’d get ahold of us through email. So, we made it really easy to track all the problems. And then, in most cases, I think, because of the beta station rollout, we were able to fix the problems pretty much before they came, not in every situation, but in most situations, we knew about the problems before they were reported.

Jessica:

So, it was kind of nice to say, “Oh yeah, okay. Well, we know about that. We weren’t caught broadsided very often by problems that came out of nowhere.” And so, that was the great thing is, as I think, if you’re doing a special project for a station group or somebody, start your paperwork early, start the manual early, start thinking about customer support long before the product rolls out, because you’re going to need it. And in this situation, more was less. So, the more we gave people information advance, the less the phone rang, and honestly the phone didn’t ring very much. It’s been really good.

Steve:

Awesome. What about having sort of some webinars to kind of help stations be prepared?

Jessica:

Yeah, well, that’s exactly what we did, is we did a webinar with PBS. It was actually by PBS. They invited all of the PBS stations, and most people showed up, and we’re sort of able to give them a heads up, advance of here’s what’s coming, here’s what’s going to happen. And then, at that point, we were able to go through of all of our customer service applications and the best way to get ahold of us. And so, I think that put a lot of stations at ease during the rollout. I think it also put all of us at ease, too. We sort of established a rapport with everybody, in advance. And that’s also key, too. You don’t want to just surprise somebody with this new gear that they have to put in and not answer their questions upfront if you can. So, I think we did a good job on that.

Steve:

Great. Another kind of thing, as far as the support and ongoing development of the project, is just to kind of take that feedback you get from the customer base and use it to improve the system. So, in the case of PBS, it’s been out there about six months now and we get some good feedback from the customers, where all things are going great, but you always get those questions like, “Yeah, it’s working fine and everything’s good, but it would be really cool if it did this.” So, to kind of get that feedback. And so, we’re actually going to be here soon, sending out a kind of big release with some enhancements. We’re just letting them just use our ability type things where each of the system has two groomer cards in it. And it’s kind of nice that you can actually see the status of both groomers on one page, but now there are things that you can with a groomer.

Steve:

That card will actually go a little gray out to kind of indicate that it’s not talking or working. For the browser tabs, so just have an IP address, how we’ve changed it to, and actually has the cards name. So, just kind of a lot of usability things that once it gets in the field. People have suggestions of, “Hey, it’d be nice if it could do this.” So, it’s really important to kind of take that feedback and if all possible, try and get that rolled into a future release, that it really helps improve the system over time.

Jessica:

That’s a great point, Steve. You got to listen to your customers because they’re going to use your gear, not in a lab, but they’re going to use it in real-world situations. And listening to them makes it important to put out the features, and it’s especially nice when you do special projects to really put out a product that exactly what your customers need.

Steve:

Okay. So, kind of talking here about the keys to success for a project, some of those include… While it’s important to develop a detailed and comprehensive statement of work is should really build in some flexibility for things that you don’t anticipate, or things which don’t work in practice, the way you envisioned. Then, once you have that statement of work, you should break it down to smaller tasks, which can be easily managed and tracked. You should do an iterative process. You get that constant communication between the customer and vendor to ensure the project is on schedule and is meeting the customer’s needs, then follow that up with some beta testing.

Steve:

And then, the final thing is you always want to make sure you provide good quality support and it’s… Once the systems out there, it’s really just the beginning. Because, now, you got to make sure over the lifetime of the product that it’s meeting the customer’s requirements, and it’s also kind of build in enhancements and improve the system over time. So, next, I’d like to just give a quick overview of the WARN system kind of a little bit early to went over kind of what the requirements were. And just to kind of show you kind of what we came up with D2WARN. So, you have a slide there, Jessica.

Jessica:

I do. Yep, hang on.

Steve:

Just kind of get a little block diagram of the D2WARN system.

Jessica:

It’s opening. It’s opening very slowly. Sorry about that.

Steve:

That’s all right.

Jessica:

Here we go. All right.

Steve:

Okay.

Jessica:

Here we go.

Steve:

There we go. Okay. A block diagram is a D2WARN system, and basically, everything you see within the dotted line is actually included inside of a Ross OpenGear Frame. So, that’s one of the things we did, is to kind of really take all those five different components, which make up the original WARN system, is really condensing down into a single component, which is the Ross OpenGear Frame. And you’ll see, within the frame, we basically have two satellite cards which are integrated from Suncor and what they are doing, they’re supplying the groomer cards, which are the ones who are actually doing the work here. So, you can see the local over the airstream comes in, comes into the product primary groomer, it will then kind of take the alert messages from the primary satellite, inject them into the stream, and pass on to the backup groomer.

Steve:

And so, what the backup groomer will then do, if it seems that the primary groomer is not doing the insertion like it should be, it’ll actually take over from its own satellite receiver card and do the insertion. And then, we’ll kind of go out over the air. So, you can see here, this sort of takes them both the fail-safe and the fail-over. The fail-safe comes in the play where both these groomer cards have switches in them. So, if they’re to lose power or the card fails, that will just pass the ASI directly through almost as if it was a barrel connector. And then, the way the fail-over works, if either the groomers, if the primary groomer fails, the backup will take over.

Steve:

If the backup fails, it’ll just pass through the primary, and the primary alarm saying, “There was an issue with the backup groomer,” so that things can be replaced. And what’s really kind nice, is this system, with this fail-over, is you can actually take the opengear frame, pull the power on it, and then you won’t even see a glitch on air, it’ll just pass right through. So, that’s kind of good. The key things, probably the number one thing for PBS over everything, is not to cause issues with the over-the-air stream. So, it’s very important that if there is any failures, that it fails over gracefully. And if you want to go and stop sharing for a second, Jessica, I’m going to share real quick here, our system here, we have… Okay. Can you see that, Jessica?

Jessica:

Yeah, we got it. Looks great.

Steve:

Okay. So, what we’re looking at here is an actual WARN system running in our lab here. So, this gives you an idea of, as I told you before, it has to be in a lot of alarm capability, but shown here, we have our are two groomers at the same… What’s kind of nice, no matter which groomer you’re talking to, you actually get the status of both groomers. The two panels here shows both, everything’s green. That’s what you like to see. You see, we have all these different alarms for communications between the cards, power supplies, fans, all these types of things. So, if there are any issues… So, not only on this screen, you would see these alarm indicators would go, but this also would signal on the front of the actual opengear frame itself, that there is a white bar, which is normally blue.

Steve:

Then, if you give me a warning, so it’ll go yellow. And an actual alerts will actually turn the light bar to red. So, a lot of indications that if there is an issue with the system. And one thing we really tried to do here was trying to get a lot of information on one screen, but without also making it too cluttered. I think we did a pretty good job with that, so you can really get a lot of information here. And then, the one you guys talked about was the flexibility and functionality. So, if you go over to the configuration page, you can see there’s a lot of different roles that the system could be in. It’d be primary backup with no video.

Steve:

Then, these aren’t even showing all the different options if you have IP. So, there’s a lot of different ways this could be configured. It takes a lot of different flexibility to meet all the unique demands of different PBS member stations. It’s also kind of nice here. We tried to kind of make it as user friendly as possible, so we had a lot of these standard configurations built in that if just select one, it’ll automatically set these other fields for you, for that configuration. So, you don’t have to set it individually though. We do have an actual manual configuration, which will then allow you to change individual fields that’s kind of made it a lot more user-friendly with all the different types of configurations you have at different systems.

Jessica:

You know what I like about this, too, is the fact that you actually put the manual inside the browser. There was… Yeah, you took it down. But-

Steve:

I just took it out for you, Jessica, but I get that.

Jessica:

No worries. I just thought that was really slick to put the manual inside the browser. So, it doesn’t just lead you to a web page, it’s actually, you can download the PDF from inside the browser. So, that was really cool. And then, the other thing that helped us a lot, too, is the diagnostic button. If for some reason something does go sideways, then they call us. We can say, “Hey, do us a favor and send us a diagnostic package.” And with one click, the customer can download the package and send it to us. And so, that’s helped a lot for troubleshooting.

Steve:

Just a little thing, what that diagnostic package includes. It includes all the logs, all the configuration settings, just a lot of system information. So, basically anything we can think of as engineers, we kind of put into that thing, which may help us determine if there’s a problem, what’s the cause. There’s a lot of really good, useful information in there that if there is an issue, you can download the diagnostic package and get a good idea of what occurred.

Jessica:

Yeah. It’s been super helpful.

Steve:

And then, one thing I was going to point out, so not only does the manual downloadable right from the user interface, so are the meds. So, if you’re using any type of SNMP program and you want to kind of get the MIBs, so you can see the messages yourselves in your own system. You can download the MIB right here from the unit, as well.

Jessica:

Which that’s true. Yeah. That’s also a good point because they didn’t have to call us to get MIBs, which was really great to help the customer help themselves. All right.

Steve:

So, that’s kind of a quick overview of the D2WARN system, which is what we get developed to put out to all the PBS member stations. It was a really fun project. We really enjoyed doing it. In fact, we actually, here at D2D, that’s thing we really enjoy is doing custom projects. Throughout our whole history, we’re a very engineering-centric company. We kind of do all our own hardware and software, and we really enjoy that kind of getting down, roll up our sleeves with a customer, and say, “What do you need? How can we help you?” And really kind of come up with some unique solutions that really kind of help customers with their unique situations, and it really gives us a really good sense of satisfaction where we’re able to kind of help the customer and see that they’re able to kind of get done with what they need to.

Steve:

And we just have a lot of design experience in that area and andother thing too with us. Being a smaller company, we are very agile and very nimble, and we can kind of do a lot of very personal service. One thing with the PBS iterative process is we basically had weekly meetings for the last two years with PBS. And I think I was on every one of those calls. So, you really get this personal service. If something comes up and it’s a question of, “Hey, can D2D do this?” Or, “How can we do this?” That’s not, somebody who’s got to kind of go back and talk to their boss, who’s going to talk to their boss. And maybe a week later, you finally get a response from somebody who’s not even intimately involved, day-to-day, with the project. So, if you really get that personal service where you’re actually get that one-on-one contact with people who are actually doing that development. I think that’s a real big thing that we provide when doing these types of custom projects.

Jessica:

Yeah. That’s important. Being able to roll with the changes and not have a bunch of red tape in the way if you… I mean, everyone’s going to change their mind and also scenarios are going to come up after the fact where you have to be able to make the change and make the customer happy without having to go through 10 channels of red tape and, of course, get 15 signatures. I mean, basically, we were able to make decisions on the fly, and our twice-weekly meetings, we’re able to keep everybody abreast of all the issues in real-time. And so, that’s so important. And the fact that we’re here in the US, too, on the same time zone, also made support and everything a lot easier rather than going overseas for support.

Steve:

That’s definitely a good point, Jessica.

Jessica:

Thank you.

Steve:

Okay. So, that’s kind of the D2WARN project and, say, your D2D… We really excel at doing these types of custom projects, a project coming up that you kind of need some assistance with, of how to do that, we’d love to talk to you and help you out with that. And let’s turn it over in the audience and see if you have any questions that we can help you with right now.

Jessica:

Yeah, Steve, we’ve got a couple questions come in. Here’s the first one. “Have you done any other custom projects?”

Steve:

Sure. The history of D2D, we’ve done quite a few, actually. The first one was very early on in the company, Three Angels Broadcasting Network. They are a religious broadcaster. They’d come to us and they’re kind of using some of our basic technology. But the other thing that they needed to do was, they’re doing satellite distribution and they didn’t want each location decode and re-encode the system and use a lot of quality that way, the extra expenses of decoders and encoders. But the one thing they still need to do was have FCC compliance for emergency alert messages. So what we did, we came up with a system, which you mentioned became our D2 alert product, is you can actually take in conjunction with digital alert systems. We’ve taken their stream from the alert system, which will basically have an impact stream, which is texts on a background and associated audio.

Steve:

And what we’ll do is we’ll replace all the incoming programs with the alert message. And then, when the alert message comes over, we switch everything back. That gave Three Angels a very cost-effective way for them to be FCC-compliant with their emergency alert message system. And another one we did was somebody that’s kind of a little bit the opposite. In Mexico, there’s a situation where they were sending out, once again, satellite distribution. But in this case, they weren’t doing decode and re-encode to do some vocal insertion, but the issue they were having is they’re having their PCIP being generated at the uplink. Well, the problem is when you then, decode and re-encode, you lose on your piece of information, all your channel guide information. And we’ve been very cost-prohibitive to put a piece of equipment out in every location. So, they went away to still generate that uplink, but not lose it when they did their local origination.

Steve:

So, what we came up with our system is we’re able to take in on our end. Yes, I want input. We take the satellite feed, we’d strip off all the alert messages, send it back out our ESI1 output for the local origination. Then, once all that was done, we passed back through into our second input where we had basically take the guide information and then put it into the post-local origination, which, and then, go out over it into the transmitter. So, it was kind of a nice way that we could keep their piece of information through the local origination process.

Jessica:

Oh, those customers still have those systems running, too, by the way. We hardly hear from them unless, for some reason, they forgot a password or something. So, I mean, that’s always a good sign. 10 years later, they’re still humming along. So, that’s really great. The next question, “Any particular challenges that you’ve had to overcome doing these special projects?”

Steve:

Sure. Kind of a good example with this particular PBS project is, one thing that PBS was trying to stay away from is having to use in Java because you know Java has a lot of issues. You got to make sure you got the right job, a virtual machine on your project, on your computer. And it can just be a bit of a headache. Especially, when you have this unique system with PBS, where every member station is independent. It’s not like, “Hey, all the stations are all running this version of Windows.” So, it’s a lot the user do, a single update to everybody. Every different station is unique. So, they really want to stay away from having to depend on Java, which was no problem for our cards because we were browser-based but what we ran into an issue is with this dashboard for the opengear frame.

Steve:

So, if, at all possible, they were trying to make it where dashboard is optional. Sure. If you have a dashboard and you like using it, great. But a lot of these stations, this is the only opengear frame they have. And they didn’t want to have to be a requirement that they have to let them a dashboard to kind of set the IP address of the frame and then those kinds of things. So, it was a challenge, but there’s a lot of fun to kind of really get in there and all the different types of protocols for the opengear frame.

Steve:

We worked with Ross to kind of get into some of these protocols that we can sort of basically, control the frame ourselves. So, you can actually, from our user interface, set the opengear frame, IP address, gateway. Then, the way that we were pulling the status of the frame, we’re getting the frames, the status for the power supplies, the fans. So, if anything goes wrong with the frame, it’ll actually alarm within our user interface. So, that took a lot of work to kind of get that all worked out and functional, but it’s kind of things we enjoy doing, here, at D2D.

Jessica:

Yeah. It was really neat. It was really kind of cool the way that you just use the canvas technology to work within the dashboard, so it can be done either way. I thought that was really impressive. Let’s see, we got one more question here. “How big of a company do you have to be to have a special project done?” Can you be-

Steve:

A lot, depending on kind of what you want to have, what you want to do, and sort of what the budget is. So, if it’s only a unit or two, you can’t really do a big project, but we also do a lot of just with customers, which only have one or two units. They’ll come to us and say, “Hey, it’d be really nice to do this.” And if it’s not something which involves a lot of work or it’s something like, “Oh, this would be really cool.” But all our customers would like this, so we’ll try and really work with people and, if possible, get that feature in. When it comes to a project, the scope of PBS, you do need some scales because there is a lot of engineering costs involved. So, if you don’t have that something like PBS, with 180 member stations, something of that scale to amortize the cost of development across a lot of units, that does become a lot of cost-prohibitive if you just have a handful of means to do something of that scale.

Jessica:

Sure. But you don’t need to be a multi-billion dollar company to come to us and say, “We have the special situation.” I find that a lot of things, as television evolves, a lot of people have these special situations where they’re doing this or that. And there’s a lot of the repack, obviously, sent a lot of people into different corners to do different things and people are getting pretty smart with engineering off-the-shelf. But in a lot of cases, I think you could save money and time by just having somebody do a special project for you if you’re rolling out to several stations. So, you don’t need a multi-billion dollar company,

Steve:

We can definitely do a lot of work with the smaller companies, which just have a handful of units.

Jessica:

Right. Fantastic. Oh, great. I don’t see any other questions, I guess, unless somebody else has one, we can… If anything else comes up, it looks like that was about it.

Steve:

I’m trying to say something else. Give it another minute for…

Jessica:

Let’s see if anything else… I’m saying, but it looks like, Oh, that’s it. All right.

Steve:

Okay. Yeah. It looks like that’s it for the question. I enjoyed this check with everybody today. And, once again, if you have projects coming up that you would like to talk about, we’d be happy to hear from me. You can contact either Jessica or myself. And with that, we’ll say goodbye and hope everybody a great day.

Jessica:

Absolutely. Thanks everyone for joining. Appreciate it. Talk to you soon. Bye, for now.

Although Program and System Information Protocol (PSIP) data has been around for quite a while now — since the advent of digital television broadcasting — it remains a common source of confusion.

We get that PSIP can be a bit daunting! With its collections of tables, all with their own acronyms, PSIP can come across as being complex and hard to understand.

The good news is that with an understanding of the fundamentals, you can establish a smart, simple system for effective handling of PSIP data. So, let’s start by tackling those acronyms.

There are two types of PSIP data: static PSIP and dynamic PSIP. We’ll begin with static.

Static PSIP data is unchanging, and it includes the Virtual Channel Table (VCT), the Rating Region Table (RRT), and the System Time Table (STT). Each of these tables serves a straightforward function. The VCT supplies information including major number, minor number, and channel name. The RRT provides parental guide-type information. The SST supplies the current time. These tables allow viewers’ receivers to tune to your channel.

Dynamic PSIP data offers further information that add visibility to your channel and make it easier for viewers to find. It also provides the program information that populates the electronic program guide (EPG) and helps viewers decide whether or not to watch a show.

Get more detail in “Your Guide to PSIP: The What, Why, and How.” Or just drop us a line to learn more about implementing an economical PSIP solution for your ATSC digital transport streams.

Get the Guide!

Tables included in dynamic PSIP data include the Master Guide Table (MGT), which tells the receiver to find information in other PSIP tables, such as the Event Information Tables (EITs) and the Extended Text Table (ETT).

While you can dig into all of these aspects of PSIP data in greater detail, what’s most important is that you deliver this data along with your signal correctly and reliably. If you do it right, it can also be simple and cost-effective!

Learn how you can implement more reliable and economical PSIP EPG data for your ATSC digital transport streams. You’ll see a live demo and learn about:

-The difference between static and dynamic PSIP

-The advantages of generating program guide info and injecting it in the same hardware

-How to do PSIP for less http://www.d2dtechnologies.com/

Webinar Transcript:       

Practical PSIP for Everyday Stations

Steve:

Hello, everyone. Glad you could join us today. If you want to take advantage of Dynamic PSIP at your station and save money, edit as well, you’re in the right place.

Steve:

Today, you’ll find out about the difference between Static and Dynamic PSIP, the advantage of using the same hardware to both generate and inject Dynamic PSIP and some novel ways to do PSIP.

Steve:

We also have a short demo, so you can see just how easy it is to add PSIP to your station. We’re also going to finish with a question and answer session. So, if you have any questions along the way, go ahead and enter into the chatbox, and we’ll answer those at the end.

Steve:

I’m Steve, I’m the President of D2D Technologies, I have with us here today, Jess, and also have Fallon with us as well. She’ll be working things behind the scenes.

Steve:

Hey Jess, how are you doing?

Jess:

Great, Steve, happy to be here. Happy to talk PSIP.

Jess:

How are you doing?

Steve:

Good, doing great.

Jess:

Great.

Steve:

So, PSIP is a very important part of your station, and probably a lot of you are already familiar with PSIP, but there may be some which not too familiar with how and what makes up PSIP.

Steve:

So, I’ll just do a quick overview about PSIP. I think it started here.

Steve:

So, there’s two main types of PSIP. There’s Static PSIP and Dynamic PSIP. Static PSIP, as the name implies, is a PSIP which doesn’t change, such as your major number, your minor number, your channel name. And the tables which make that up, or your virtual channel table, which is the most important one for Static PSIP, that is where you define your major number, your minor number, your channel name, is all that is defined within the virtual channel table.

Steve:

There’s also the rating region table, the RRT, which that’s where you get all your parental guide information, whether it’s PG 13, whatever. What other things may be for the parental guide ratings.

Steve:

And also included with the Static PSIP is your system timetable. Now one thing I did want to talk about the system timetable, because we do get calls about this occasionally, is the system timetable actually uses UTC time, the Universal Time Code, or actually Coordinated Time Code. And why that’s important to address it a little bit is, so it does, that’s the basically very similar to GMT, it’s basically. Everything’s based of, what the time is over in England. And so that’s comes in handy, because when you’re broadcasting, your signal may actually be picked up in more than one time zone. So you can’t put the time zone within the time, which is being transmitted. So, what that means is, it’s the receiver, is where you actually add your timezone offset. So, in case if you have a customer is calling and say, “Hey, the time’s off, it’s not showing the correct time on my TV.” It’s most likely not your PSIP. The first thing you want to do is, have them checked to make sure they have the proper time zone set in the receiver. And that’ll usually clear up the issue.

Steve:

The other type of PSIP is Dynamic PSIP, which is basically your channel guide information and tables, which make up that or the master guide table. And that’s the table which tells the receiver, where to find all the guide information. And the guide information is made up of the event information table. And that’s the table, which tells you the “what” and the “when”.

Steve:

So, maybe, as we were just looking on the PSIP right now and showing you, right now, is Judge Brown is showing. So that’s what the EIT, which we’ll show you is, what’s playing, the program title and when it’s playing.

Steve:

And then, also along with that, is the extended text table. And what that will give you, is more detailed information about that episode. Like say, it was Oprah, it would may tell you, who’s going to be on Oprah that day, so I’m just giving you more in-depth information. So, that’s basically what makes up your PSIP, both Static and Dynamic.

Steve:

And so Jess, why is PSIP important?

Jess:

Well, Steve, you got to have a channel guide. It’s like, if you have a store, you need to have a sign out front, right? So people know what you’re selling, they know what they’re going to get.

Jess:

And so what PSIP does is, it brands your channel. And it’s important because, if you’re flipping through the channels, you might be in a commercial, but everybody always wants to know what’s on. Plus, viewers are very much used to being able to turn on a TV, thanks to cable and whatnot and knowing what’s on immediately. People want to know right away what’s on the air, and you could easily catch a lot of viewers, just by displaying your PSIP correctly. So they might be flipping through the channels, and there’ll be able to say, “Okay, I like the show.” Or they can look ahead even, because it allows you to look ahead in the guide. So, for instance, you can see what’s coming on in an hour. So for instance, you’re looking for the St. Louis Blues versus the LA Kings game. You can display that on the screen, and it’ll tell you when it’s coming on and when it’s coming up, and he can go actually all the way up to two weeks.

Jess:

So, it’s important to brand your channel properly. If you’re going to spend all that money to put the channel on the air, you might as well brand it correctly. So, PSIP is really important.

Steve:

That’s great. Yeah, sounds like, great use for a Dynamic PSIP.

Steve:

Is there any uses for Static PSIP?

Jess:

Well, absolutely because, even a Static PSIP, your short name. So, for instance, you want people even to know if they’re watching the right show or rather the right channel. So, let me share my screen here really quick, where’d you go, oops.

Jess:

If you want people to be able to know what channel they’re looking at, and in actuality, you should have your channel branded as far as the short name and Static PSIP is also your channel number, your short name.

Jess:

So for instance, if your virtual channel is 26, but you might be receiving it at 13 or whatever, what Static PSIP-

Steve:

That’s all I could feel like a translator or something?

Steve:

Yeah, you may want to-

Jess:

Exactly. So for instance in here, if you see, you’ll notice I pulled in program one, well, when people are flipping through channels, they don’t really care if it’s program one or program two, but I was able to rebrand our channels D2D TV and Just TV, just for this demo purpose.

Jess:

So, the Static PSIP up is really important. People have to know what channel you’re watching, and the FCC might like to know as well. So, it’s a good idea to have your short name in there and then also brand your channel to the proper virtual channel, because otherwise people are never ever going to find you.

Steve:

Right? Yes. And it’s really comes down to … with translators where, you’re broadcasting, maybe the original is channel 12, on one side of the mountain, you have a translator broadcasting into the other side of the mountain and now it’s channel 14. So, you’ve got to go and modify your Static PSIP to change your major number or your minor number as well.

Steve:

Another area where that comes in handy is, we do a lot with what’s SRT, where we have a secure reliable transport, for sending transport streams over the public internet. So we have people such as one of our customers, the Global Bible Network, where they have one location, they send the channel out to 20 different stations across the country. And each station, you have to change the Static PSIP, to reflect what the major, minor number and channel name is at that location.

Steve:

So, Static PSIP, it is very important as well.

Jess:

Yep, yes.

Steve:

Okay. So, we’ve talked a little bit about Static and Dynamic PSIP and what the difference is and what are some of the good uses for it.

Steve:

Another important thing to talk about with PSIP, there’s many ways to generate the PSIP and inject the PSIP.

Steve:

I’m going to talk a little about the advantage of doing the generation and injecting it, within the same hardware. So what are some of the advantages of that Jessica?

Jess:

Well, back in the day, PSIP was mostly done in through the encoder. It was done, as the transport stream is getting created, which, that was a great way to do it, but there’re some disadvantages. Number one, you need a $40,000 encoder to do it, or some other piece of gear.

Jess:

Number two, if your encoder goes down, well, everything goes off the air. So, the way that we do it is a little different. We actually do it inline downstream. So, by doing that, it actually is very beneficial for a number of reasons.

Jess:

Number one, it is, you can literally use just about any encoder, any ASI. In fact, you don’t even need an encoder. If you’re pulling this in from a remote location far away, all we need is the ASI or the SRT and then we just come into our box.

Jess:

The box calls out, the flux calls out to the FTP server. It pulls in the tables and then it adds it, maxes it in to the ASI, that’s already coming through, and it goes out to exciter.

Jess:

It’s simple, it’s easy. It’s very effective. It’s very cost-effective and it works nice because you can use some more cost-effective encoders, nothing wrong with the real expensive ones but, the nice thing is if you’re pulling a feed off of a satellite or SRT, you don’t need to break it into baseband or have another very expensive piece of gear to insert the PSIP. You could just throw our box down, ASI in and out and off it goes.

Jess:

So, there’s a number of advantages. And the other advantage too, if I can point out, if for some reason you go black, your encoder dies. At least you still have the channel branding on the air. So, you don’t really lose your spot. Like people aren’t going to scan their TV and lose you, your PSIP is going to stay there, even if you might temporarily be off the air with your video and audio.

Steve:

Yeah. That’s a good point, Jessica. And also, when you’re generated externally, not only do you need an encoder multiplexer to inject that stream, which adds cost to your encoder or generate a multiplexer you can’t use. Certain encoders just don’t have that feature, so you have to get more expensive encoders and increases your price, but you also had this other external piece of equipment, which is a lot of cases, is Windows-based. So you have to do your Windows updates and reset it occasionally.

Steve:

So, it’s just not as robust as a dedicated hardware for generating and inserting your PSIP.

Jess:

That’s a good point, Windows updates.

Steve:

Yes, everybody loves a Windows updates.

Jess:

Yeah. Your PSIP stops, because Windows wants to update, so you can have that. So, it’s nice to have one piece of hardware, that just injects it into the stream.

Steve:

Right. So, it really gives you a lot of reliability, reduce costs and helps keep your station branding on the air in the event that something were to happen to your encoder.

Jess:

Yep.

Steve:

So, those are some of the more common ways of doing PSIP and injecting PSIP, but at D2D, we also enjoy providing customers with novel solutions.

Steve:

They come with those with some of those crazy ideas like, “How can we do this?” And we really kind of, they get in there, it’s like, “Hey what’s we can create this custom code for you?”

Steve:

And we did have the situation in Mexico, if you have some info on that Jessica, what was the issue there from the South?

Jess:

Well, so, they were transmitting their stations all over Mexico. And in most cases, they wanted to add some Dynamic PSIP to the signal. But the problem is, some of the locations where on top of a mountain, where there was no internet, there was no chance of internet. There was no way to get internet there. So they couldn’t have any way to pull the tables down. They obviously didn’t want to send a guy down there to go and load the PSIP in manually. So we figured out a way..

Steve:

I think they are doing local origination as well weren’t they at the sites?

Jess:

Yeah. Well, that’s just the other thing, too.

Jess:

Yeah, thanks for pointing that out. They wanted to be able to break the channel down and break it into baseband, add some local content, as well as add some local branding. I think they ran it through a Tektronix, so they could analyze the video, and then they wanted to re-encode it and put it back on the air.

Jess:

So, all of that was great, except they didn’t have internet access to insert the PSIP. So, we came out with our propel, which was just basically a way to send the PSIP guide tables over satellite, and then be able to inject them after the fact, into the stream, right before the exciter, without having to have an internet out there. And that way, they could generate all their PSIP data at the very head end and then send it over satellite. And then at each single translator, be able to insert their PSIP. Other programming was primarily the same. So, other than the branding that they did locally, they were able to do this with, it was a great solution without having to provide internet.

Steve:

Sure. Yeah, because one of the big issues, once we find out they’re doing the local origination is normally, you do it over satellite, but once you convert the baseband to your local insertion and re-encode it, well, you’ve lost all your PSIP information from the satellite uplink.

Steve:

So, the solution we came up with is, we still use just one PSIP generator at the uplink, which would send it out over satellite to all the locations. And then at each location, we had one of our D2Flex products, which has two ASI inputs and two ASI outputs. And what we would do, is we would take the satellite feed in on ASI one, and we had stripped off all the guide data and send it out the ASI output to the downstream decoder, encoder. So they could do all their local origination content.

Steve:

Then the output of the encoder we’d taken to our ASI two input, we would then take all the UPG data we’d taken off the satellite feed. Now, put it into the over their feed, which would then go out or ASI two output to the exciters. That way, we could basically use our box to take the PSIP off the satellite feed and then inject it into over the air feed. So, that way they can still keep all their PSIP, without having to worry about trying to somehow get internet access to these very remote sites.

Jess:

Great solution. Absolutely fantastic.

Steve:

Yeah. So that’s why we really enjoy doing that, those special projects for different customers.

Jess:

Yeah, they’re fun.

Steve:

Yeah. So, now that we’ve been talking been about PSIP, it just is going to do a little demo for you real quick, because it’s just show you just how easy it is to add Dynamic PSIP to your station.

Jess:

Yep. Give me a quick second to exit out of this huge screen.

Jess:

Hold on a sec.

Jess:

We’re just talking before about multiple screens and how I don’t do multiple screens. So basically, what I have here is, let me pull this back up, and we’ll share the screen and then, come on.

Jess:

Here we are.

Jess:

Okay, so I just have one of our Flex products here. I’m basically pulling in ASI, just a couple channels. They’re just elementary stream. So, they’re just wanted the program to… I showed you this a bit earlier, but I went ahead and rebranded them just D2D TV and Just TV. And for PSIP sake, you have to be major and minor channel-specific. So, the files that are coming in, that we actually went to the FTP and got looked like this.

Jess:

You don’t really need to know that, except for the fact that it’s just basically a tablet of limited Excel file. And then they come in, through an FTP site every day. So, at about midnight, we go up and we grabbed the file and we inserted into our box here. We rebranded 26, one and 26, two. And just basically coming ASI out of the box and for the sake of the zoom call into a transport stream analyzer.

Jess:

So, currently right now, you’ll see how we’ve added the tables into here. And as Steve mentioned, here’s the EIT tables, under the table, out of the channel, I branded D2D TV. We’ve got some events here, basically it’s event number 14, here’s a title. It’s a Judge Joe Brown and saying it’s in English and it goes forward like that.

Jess:

So, basically, it’s as easy as plugging in a box inline ASI in, ASI out, as simple as taking any one of those ASI programs that you like and just, you dragging it on over and renaming it. And then once you rename it, you go into the settings here, and it’s as simple as adding your transport stream ID. Hopefully, the FCC will give you one, automated PSIP and then here you can see we’re using our friends at TV Media and Display Systems International, and we’re pulling their PSIP down here for the purpose of the demo. And that’s it.

Jess:

That’s all you really got to do. If you get hung up, you call me, and we get it working for you.

Steve:

That’s a very straightforward. So, you just put in your credentials there. Set a few settings for each channel and you’re on the air with your channel guide information, and that’s really exciting, Jessica.

Jess:

Easy, quick and you can do it remotely too.

Steve:

Okay. So, we’ve tried to pack as much information here, and everyone has a busy schedule.

Steve:

So, we’re going to open the floor now that anybody has any questions. If you want to just go and enter them into the chatbox here and we’re going to answer those.

Jess:

Let’s take a look and see what we got.

Jess:

All right. I got one, Steve, someone asking how much bandwidth should I allocate for, I guess, Dynamic PSIP?

Steve:

Sure, it can be very a bit, depending on how far out you want to go, because you can go anywhere from 12 hours to two weeks and how many channels you have, but you’re just doing at a minimum, just a few channels over the air, doing 12 hours.

Steve:

You’re only talking tens of kilobits, very low bandwidth. Start going out to the full two weeks, maybe getting up to a hundred, 200 kilobits. And then at the far end, if you’re a cable station, you have many channels those cable has. You can actually get into megabits worth of data, but for typical over the air, you’re talking tens of kilobits, a hundred at the most, in most applications.

Jess:

So, like a good rule of thumb, is if you leave like say 150, 200K and old packets in your stream, that’s funny, right?

Steve:

Yeah, that’d be plenty.

Jess:

Okay, cool.

Steve:

Yep. Yeah, for over the air, why don’t you get the cable with so many channels? It gets more, but for over the air station, a 150 should be plenty.

Jess:

Right. Yeah, great question.

Jess:

Let’s see what else we got.

Jess:

Ken, do we have to do ASI or can they come in SRT or IP?

Steve:

It can, either one that doesn’t make like a difference once you get the transport stream, what other mode it comes in with ASI, IP. We inject the tables, and then they can go out ASI or IP.

Steve:

So, the PSIP itself, that is agnostic to whether it’s ASI or IP.

Jess:

So, the cool thing about us is, you could be at your station in Birmingham and SRT your signal all the way out to Seattle. Now, Seattle, obviously it’s going to be a different time zone, probably different programming. You could just SRT and then add a box in Seattle. And that would change all your programming, including your static and your Dynamic PSIP.

Steve:

Correct. Yes, we’ll do that.

Jess:

Yeah, that’s a good idea.

Steve:

Once we received a signal, we can do all the modifying to it as needed, before it’s sent on to the transmitter or wherever downstream it needs to go.

Jess:

Nice. Yeah, that’s great.

Jess:

Let’s see if we got anything else.

Jess:

What vendors do you support for Automatic PSIP?

Steve:

Yes. We currently support three vendors for automated PSIP. We support Titan TV, Display Systems International and Grace Notes. So, if you are partnered with any of those vendors, all you got to do is go into our user interface, enter your credentials, and we’ll start pulling that schedule.

Jess:

Great. So, three vendors.

Jess:

Another one just popped in on top of that question, “Can I do it my own?”

Steve:

Oh, sure. We actually do have the ability where you can do a manual PSIP. It can be a little laborious because it’s basically, it’s a spreadsheet.

Steve:

If you do have a station which really doesn’t change a whole lot from week to week, it’s not too bad, because you have two options. You can do it for each event. You can either put a day, month, year for when it’s going to occur, or you can put a day of the week index.

Jess:

Right.

Steve:

For example, a Sunday would be zero, Monday be one. So, if your schedule doesn’t really change from week to week, you could create just one weekly schedule and just keep repeating it over and over. So, that’s it. But if you do have a schedule, which varies quite a bit, yes, it’s really nice to have an automated system. So you don’t have to be constantly check update in those Excel sheets all the time.

Jess:

So, what about ProTrack?

Jess:

Are you familiar with ProTrack?

Steve:

I’m not sure, I’m not familiar with Protrack, but that’s one we’ll definitely look into after this. We’ll see and we’ll get in touch with them. And so you can get them to start supporting us as well or us supporting them.

Jess:

As long as it’s basically like a tablet limited Excel file, right?

Jess:

It’s a text file, but it’s created in Excel and then you just save it as tablet limited. It’s pretty much that’s it, right?

Jess:

So, it’s so…

Steve:

So we did, there’s actually a standard for doing it, which is, it’s very complicated with all these XML files and all. You have to have a bunch of different files, and for just basic over the air sketches like this, it’s just crazy complex. It’s like, you don’t really need all this. So, we actually have our own protocol. We came up with a very simple, 10 to limited text file and we’ve just partnered with the different major providers, and they’ve been willing to, because it’s so straight forward that it’s very easy for them to put their schedule in that format. And then we just pull it down and inject it into the stream.

Jess:

Yeah, I think Protrack is a lot of like traffic. Like they do primarily traffic and scheduling software, so it might be a little bit different, but definitely we’re looking into.

Jess:

That’s a great question.

Steve:

Sure, we’ll definitely, once you get the call and do a little research on try and contact them to, through to us, it’s something we can work out there to support them.

Jess:

It’s the first time I’ve heard of that Protrack.

Jess:

I’m familiar with it from a previous life. And it was primarily, I think it was a lot of commercial and scheduling software, but it would be great if it could pull in the show somehow and work with that.

Jess:

Is PSIP a requirement? Does the FCC make you do it?

Steve:

It depends on what type of station you are. If you’re a full-power station, it is definitely required at least for the first 12 hours.

Steve:

So you just have to have 12 hours ahead. And it’s only the EIT which are required. The ETPs are optional. I believe that’s the same for class A as well. I’m not sure and then for low power, it’s not required at all. You don’t have to do any PSIP, but we highly recommend that you do it because it really adds a lot of value to your channel for people, to be able to find you and then as their channel surfing, go, “Hey, I’m going to watch this show.” Instead of saying, “I don’t know what this is, it just pass on by.”

Jess:

Right. Yeah, like I said, if you’re going to spend all that money, you might as well just put a couple more in and then be able to put a sign out front, right? It’s basically what it is.

Jess:

We mentioned SRT, will it work with Multicast?

Steve:

Yes. Yeah, that say it doesn’t really, so how the transport stream gets in and out of the box. Really doesn’t make a difference as far as doing you’re putting the PSIP on there.

Jess:

We don’t care.

Steve:

We don’t really care how it gets in and out. Once we have it, we put the PSIP in and send it back out, either way. We can go out ASI or IP or both, if you want on

Jess:

Great question.

Jess:

Yeah, that’s a good question. Like you come in, some channels with IP, some channels with ASI, some other channels with SRT, max them altogether and then build PSIP just for that particular bouquet.

Jess:

So, that was a great question.

Jess:

Let’s see, anyone else? Looking.

Steve:

I don’t see this one.

Jess:

What’s the difference between PSIP and EPG?

Steve:

Well, it’s somewhat intertwined. It’s the PSIP, it’s made up as I was talking earlier about the two different types of PSIP.

Steve:

So EPG, is more, is the Dynamic type of PSIP. It’s your EITs and ETPs, is the Dynamic part of PSIP. And then the Static part of PSIP is your channel name, channel number, those tables.

Jess:

So, I guess if we break them down into the acronym, EPG is Electronic Program Guide and PSIP is Program System and Information Protocol.

Steve:

Right.

Jess:

So, PSIP is a protocol for the EPG, if that makes any sense.

Steve:

Right. Yeah. So, it’s almost like an umbrella.

Steve:

So, overall it’s all called PSIP. Ant then within PSIP, there’s your Static PSIP, your Dynamic PSIP and the EPG, is specifically the Dynamic PSIP, which is your chronic program guide.

Jess:

Okay, that makes sense.

Jess:

Good question.

Jess:

Anybody else?

Jess:

Mueller, Mueller.

Steve:

Any more than we had on here.

Steve:

See if I give another minute, see for me also, has anything else to ask.

Jess:

Yeah. If not, while we’re waiting, if you want to set up a meeting or a demo, by all means, you clearly have our website address, our contacts are in there. Feel free to give me a ring or Steve, and we’ll be happy to give you a live demo or send you out a box and get you started by all means.

Steve:

Okay, yeah.

Steve:

So, I don’t see any more questions coming in. I apologize if I missed any, but yes, we are definitely available for any questions.

Steve:

So today, we’re happy to have you join us. You learned about the difference between Static and Dynamic PSIP. Some of the advantages of using the same hardware to both generate, inject Dynamic PSIP and some novel ways to do PSIP and also had a short demos and we just show how easy it is to set up PSIP at your station.

Steve:

So, I hope everyone is able to learn something today and please contact us with any more questions, or I’ll let you see the demo unit to try out and have a great day.

Jess:

Piece of cake.

Jess:

Thanks guys.

Be sure to get the guide “Internet Distribution with SRT: A Long Extension Cable for Your ASI”

Steve:

Welcome everybody. Glad you’re here. If the high cost of fiber, or satellite, or line-of-sight requirements of microwave are causing you challenges in getting your stream from A to B, you’re in the right place. Today you’ll find out about using SRT for different applications, such as Studio Link, both distribution and contribution, and even repurchasing old equipment, if laying around, which you’re no longer using.

Steve:

But we do encourage you to enter any questions you have in the chat box. And at the end, we’ll have a Q and A session where we’ll go over those. So let’s get started. I’m Steve Doll, I’m the president of D2D Technologies, and I’m here today with two colleagues, Jessica Kelly, director of Business Development.

Jessica:

Hi everybody. Hi, Steve. I’m really happy to be here.

Steve:

And also, I have with us Jon Kipp, who’s the Broadcast Sales manager at Toner Cable. Hi, Jon, how are you doing?

Steve:

Okay. For some of you who may not be that familiar with SRT, I just want to spend a few minutes to just give a little background down for you before we start getting into some use cases. SRT stands for Secure Reliable Transport. It was developed by HAIVISION a few years ago, a while back before that, but a few years ago, they open-sourced it. D2D was actually one of the first companies to integrate it into our systems back in 2018, so we’ve been doing this for quite a while. And over time, it’s actually become widely adopted to the point now that HAIVISION’s actually actively working with the IETF, which is the standard’s committee for the internet. So, this will soon become an actual official internet standard.

Steve:

To go over a couple of the key features of SRT. One, it’s secure. So, you can use AES encryption to help encrypt your content as it’s going over the public internet. It’s also very reliable. Now this will be very much an oversimplification, but in a nutshell, what it’s basically doing is, on the receive site, there is a buffer. And that buffer allows enough time that if a packet doesn’t make it, the receive site can re-request it. In that way, it can arrive before the buffer drains out, so you don’t have any loss of video. Now that you have a little bit of understanding what SRT is let’s start getting to some of those use cases. One of the most common applications we receive from customers on SRT is for Studio Transmitter Link.

Steve:

And some of the reasons they have is, they don’t want to pay the high cost of fiber, they don’t have line-of-sight to use a microwave link so, SRT makes a great application for that. It reminds me of a couple of years ago, at NAB we had this station engineer who came up to Jessica, really excited like, “SRT, it saved my station.” If you can tell us about that, Jessica.

Jessica:

You’re talking about Ravi. Ravi came up to me and he hugged me at NAB. And I didn’t really know who the guy was because I talked to him on the phone a lot. But he came up, and he’s like, “Jessica, Oh my God. You saved my station because we had the transmitter signal from our studio to our transmitter.” And, he was struggling.

Jessica:

They were doing their best to get up on the air, and he couldn’t afford microwave. It was actually in San Francisco with Diya TV. They couldn’t get a microwave link, and so they were using the old style COP 3 SMPTE 2022 Forward Error Correction, and it just wasn’t doing the job. It just was dropping out, and he was losing all of his viewers. So I talked to him on the phone, and we sent him a couple of boxes, and sure enough, he was up on the air flawlessly. Since then, he’s expanded to six or seven different markets and bought a bunch more, and so those use cases are getting really common. Yeah. He was really happy.

Steve:

That’s great. And I think then Jon, you have a customer as well, who was using it.

Jon:

I do, thank you. Yes. Very similar story and ease of use is right. So I got a call from Bern, and he’s in his truck, and he’s driving up the side of the mountain. And every time I talk to this guy, he’s in his truck driving up the side of the mountain. He’s not an engineer, but he has a translator site, and he needs to get his information to the translator site. And so I said, “Well, I know just the thing.” And so we talked to Jessica and she said, “Yeah, okay. We’ll, send out two boxes, and we’ll get you hooked up.” And of course, he had one more thing that he needed to do; I’m sure you could talk more about that later, but basically end-to-end, he was set up. He could transmit into the next footprint, and also you enabled him the ability to change some of the PSIP information. So it wasn’t just that SRT connection, but it was a little bit more.

Steve:

Correct, we actually can do that once we get it from point A to point B. If, for some reason, point B it’s a different geographical location, if you change your major or minor number of your channel call letters, any of that information we can change before we pass it on to the downstream equipment. So there’s a couple of great uses of using SRT as a Studio Transmitter Linking. It’s a good way to get away from the high cost of fiber or if you’ve run into issues with line-of-sight with microwave. Another great application, we come across is for more of a distribution application for hub-and-spoke where you have content you want to distribute it to multiple places across the country, or even across the globe. We have a recent customer that came up who wanted to do that, Global Bible Network. Can you tell us about that, Jessica?

Jessica:

Oh yeah. Steve Aldrich. He’s a great use case. He wanted to send up… They were just a small little network, and they wanted to send out their message to everywhere in the U S., And so it was really great for Steve because all he had to do basically is he got… One of the units is a hub, and then he programmed all the other ones, they could do DHCP. So he was able just set all of his spokes up at Home or at the Library there, and then just mail out the Flex-3000 boxes already set up. And so the customers were able to just take the box, plug it into the wall, into the ethernet and then come out ASI and then go on the air with Global Bible Network’s message. And it was really, really a great scenario. And Steve loves us. He keeps buying them. They’re great.

Steve:

Yeah. That’s a great thing to point out there where you can set up the DHCP or CHP and have everything pre-configured so that when each end of the spoke receives their unit, they basically plug it in, it automatically connects, and they’re immediately on the air with getting ASI across the public internet. I think Jon, one time you had the reverse, instead of hub-the-spoke, it was more of a contribution application where it was going spoke-the-hub. Can you tell us about that?

Jon:

Exactly. Our friend, Kevin, had a really unique set up where he needs to come almost the reverse of the image there. So we’re coming from the transmit sites, and we’re doing competence monitoring, but to bring back those signals from different geographical locations like that, it’s really expensive to do unless you can use the public internet. So, this was a perfect situation. I wasn’t sure at first when we first started talking about it that you guys could do that, and was happy to find out that on the receiving end, instead of having to have a one-to-one relationship, you actually have a server that can receive multiple streams coming in at the same time. So that’s what they were able to do. They were able to do confidence monitoring by sending their receive signal over the public internet back to the hub.

Jessica:

Great. So they were just using SRT to basically make sure they’re on the air and have confidence and QC that everything was good. So basically it was like the drawing, they just reversed the arrows.

Jon:

Exactly.

Steve:

It does make a great return path just to give you that confidence that yes, you are the… Whether it was something else, like microwave or fiber that you do have that confidence return path to let you know that it is getting out to the transmitter.

Jessica:

Brilliant.

Jon:

And the great thing about it is the distance doesn’t really matter. So for anybody that’s running… As we know engineers that are responsible for a state, they could absolutely use this at all of their transmit sites and then centrally be able to tell with confidence, “Hey, yes, I am on the air over there.” And to save in bandwidth, they could even use one of the sub channels to do so. So you’re not bringing the whole pipe. You just need to see one. And this is a great way to do it. It lowers the cost by using the public internet.

Jessica:

Right. Good point, Jon. Yeah,

Steve:

Pretty great. There’s a couple great ways of using SRT, both in hub-and-spoke or spoke-the-hub for distribution or contribution, and it’s a much more cost effective way for distribution than using the more previous standard of satellite, which can get very expensive. This can really reduce your operating costs by going to an SRT distribution. One more use case we want to go over. And this one’s a bonus. It’s two in one. One, it’s a contribution, but also they had this really cool way where they’re able to reuse all the equipment they just had laying around, didn’t use any more. They thought it was basically useless or probably going to get rid of it in the near future, and SRT allowed them to reuse it. If you can tell us about that, Jessica.

Jessica:

Yeah, absolutely. This was one station. Actually, there’s been a couple, but it came about when a guy says, “Hey, I can use my satellite receivers, which are no longer being used anymore,” basically any IRD that has an ASIN, because it’s already gen-locked into the station. Audio and video is already plumbed into the production switcher and into audio and everything else. So basically his satellite receiver became an SRT receiver. And what he wanted to do was set up a remote studio at a newspaper. And they wanted to do live shots every day from the newspaper back to the station and they were tired of live shots looking like this and everything else. So he was able to use SRT to go from the newspaper, from his little home studio, from the newspaper studio back to the station. They could put them on the air and it doesn’t look like a Zoom call. It looks really professional, and it’s broadcast quality. It’s like a long extension cable for your ASI. And so now they’re using those all over Chicago to do live inserts, and it’s really taken off.

Steve:

Okay, great. So we’ve spend some time here going over some great applications for SRT, including Studio Transmitter Link. It’s not just from the studio to the transmitter, we have a lot of customers who are using it from the studio to maybe a regional cable head-end that they want to send it to. So there’s more plays anywhere you want to go point to point over distance. It works as a great application. Also it has distribution, contribution and hub-and-spoke type applications, and also allowing you to take some of that old equipment laying around and be able to take that over the IP, convert it to ASI and send it into things like a satellite IRD you may have there laying around that you can reuse.

Steve:

So now we’ve gone over that and I think it’s the time now we can get on to some of these questions that people have. And as I was saying before, feel free. If you have any questions, you have the chat box there, just feel free to put them in and we’ll just start answering them as we go. We’ll just keep answering until all the questions have been answered to everybody’s satisfaction. So let’s get started.

Jessica:

Let’s see, we got one. Okay. So we’ve got a question here. Typically, what’s the overhead? So if I want to send a 10 megabit signal across the internet, an HD live shot, how much extra bandwidth do I need? Well, that’s one of the questions.

Steve:

It can definitely be network dependent. But typically it runs about 25% is the rule of thumb. So if you have a 10 megabyte streaming, you go about 12 and a half, and if you have a full ATFC stream at 19 4, your base want to go somewhere in the 23, 24 megabit range is a good rule of thumb.

Jessica:

Yeah. Okay. Yeah. That’s a good one. Let’s see if we got any other questions. So they want to know, another good question. Can they max in some streams at the other end? So if they’re going from station to transmitter, can they take it in like a sidelight feed at the end of the red, box them in and rebrand them and put them out over the air, just for that particular translator?

Steve:

Sure. Yes. The flux bands are capable at their full multiplexer. So when the stream comes in, you can max another existing ASI streams, IP streams already have there, at the facility or at the tower, wherever the devices are at. And so then we can do all the table manipulation, create new PMTs, tables for all the new programs so you get a full multi-program transport stream, at least. So you can basically pick and choose which programs from each input that you want to put on to the final output.

Jessica:

Brilliant. Let’s see. Let me throw a skull through here, a couple more. Oh, here’s a good one. What’s the latency? Is it good enough for contribution?

Steve:

Yes, it’s definitely good enough for contribution. Once again, similar to the overhead, it’s very network dependent. But if you have a good solid network, it’s typically in the order of 3-400 milliseconds on the overhead. And a good rule of thumb is basically do a ping test. You would actually see in our Standard’s Panel, when we’re on a connection, we’ll actually show the roundtrip time, which is basically the equivalent of ping. And if you basically go about four times that amount and you set that for your buffer, which is basically how long your rates will be, so that’s how long it’s going to buffer for. So if you have your ping time’s say 60 milliseconds, so if you put about 250 milliseconds for your buffer size, that’s also is going to be about the time of your latency.

Jessica:

That’s crazy. That’s really good latency. You got to figure, nowadays people are using banded cellular for live shots. And that can run in seconds, like four or five seconds in some cases. I’ve seen it run up as high as 20 seconds, which is really awkward on air. This is almost as good as a microwave shot, a Marty shot, which is just outstanding. That is good enough for contribution. That’s even better than Zoom, for that matter. Yeah. That’s a great question. Can the units go bi-directional? In other words, can it go in two different ways?

Steve:

Correct. That is possible that you can. Because then you can have the… Some way it’s similar to what Jon’s application earlier, where they’re using SRT as the confidence back haul. You can actually use SRT both directions and send it on SRT then also still come back with a confidence return just to make sure it is making the full round trip. And that you are all on the air at the transmitter site.

Jon:

I have a question regarding that.

Steve:

Sure.

Jon:

So the overhead in that scenario, is that just additive? So if it was about 25% more for single way, is it the same number or does it curve off?

Steve:

Is that on the bi-directional?

Jon:

Mm-hmm (affirmative).

Steve:

You’d need that overhead both ways, to both ends maybe to be re-requesting packet. So you would need that. So you’d take your… Say you had a 10 megabit stream going each way, that’d be a total of 20. So you still need about 25% on top of that.

Jon:

Okay.

Jessica:

Oh, okay. Yeah. That’s good to know. Another question here. We’ve got, do you need an encoder and a decoder for this setup?

Steve:

Actually, no, you don’t. We’re actually ex… So basically in a typical application, we would take the output of the encoder, say an ASI encoder would feed into a D2 Flex gateway at the studio, then we send out over IP. Then when it gets to the far end, we would take that IP and send it back out to ASI then you might have a decoder there that you want to decode it before you display it or what you want to do. So basically the encoders and decoders are on either end of us. And we sit in the middle, creating that public internet pipe to get you between the encoder and decoder, if they’re at two different locations.

Jessica:

It’s probably worthwhile to clarify though that we don’t do base band, you have to already be encoded. We can’t put HDMI or SDSC or HD-SDI into our unit. So you do need an encoder and decoder at the other end. Think of it like a long extension cable for your ASI.

Steve:

Correct. So it is true that you don’t need for this specific SRT, but at some point for us to feed into our box, it does need to be encoded first and decoded downstream. The flex system itself does not encode or decrease.

Jessica:

Yep. That was a good question. Jon-

Jon:

Michael Lloyd has a question. Michael Lloyd’s asking if we have a CATV headend where we had successful applications for receiving local broadcast via antenna, and then going SRT to another headend. And yeah, we were talking about that a little bit earlier in the scenario where it was spoke-the-hub. Mike, that’s exactly what they were doing. It’s good to see you on here by the way, Mike. And so they were receiving different transmit sites with an antenna coming down and to a digital tuner and then handing off ASI, I think all of them, but it could hand off IP as well into the DTD box and then SRT back.

Jessica:

Great question.

Steve:

Okay, lets see. If there’s any more questions. One just came in. “So does it have to be ASI or can I just take TSO IP on one side and ASI out on the other or just TOS IP TOS IP?”

Steve:

Correct. It can be TSO IP. So it doesn’t have to be ASI coming in or ASI going out. We can take just regular TSO IP, going around the plant, send it to the flex. We patch it up for SRT, send it across the public internet. But the other end where you receive an SRT, we can then output it either as ASI or back to just a regular TSO IP.

Jessica:

Great. Yep. Cool. Did you see one, Steve?

Steve:

I just saw another one here that somebody’s asking about redundancy. So that’s something we’re actually working on now, and we should have come out here shortly in our new release where what this will do, there’s a couple of different flavors of it. So it’s worked really well if you had two different ISP. So let’s say at your station, you have a full bar Comcast connection and 80 and DNT connection to the box and basically send the stream out over Bolt. And then the Receive unit will receive both, and if one goes down, it’ll automatically switch. And depending on which one you do, it could be seamless announcing list. There’s two different methods of doing it. One is based on the SMPTE 2022-7 Hitless Redundancy from the [Cap in 00:19:59] cap through standard. What this does is that the band basically sends both programs all the time, and then we’ll just automatically switch over with no hits from one to the other.

Steve:

Now the one downside of that is double the bandwidth. So if you’re sending a full ATSE transport stream at 19.4 megabits, it’s basically going to duplicate it. So you’re looking about 40 megabits. So you do need to make sure you have enough bandwidth. And the other way of doing this is, it’ll set up both routes but only send on one. So the other one will be ready to go, so it can switch on an instant. And that one, you have a couple of options, really disciplines on how big you want to make the receive buffer for your latency. If you’re okay with a longer latency, versus if you have a shorter latency, you could have a breakup, when it goes to Switch, because you may not have enough time to switch it over.

Jessica:

All right’

Steve:

If you do, but it would be a brief sub second, you may see some breakup on the screen, you wouldn’t actually lose your total video. It’d be very brief. Or if you’re okay with having a longer latency, maybe a second or two, you can increase that latency, and that’ll give it enough time that it can switch over to the other one without taking any hits on there.

Jessica:

That’s great because having options for redundancy is a great thing. No two redundancy scenarios are the same. Some people want an instant seamless switch, and other people don’t really care, as long as you don’t go dark. So it’s great to have those options. It’s fantastic.

Steve:

Okay. I agree. And when I was thinking about doubling the bandwidth of that 40 megabits. One thing, it’s always good to check. When you’re good to do SRT is that you do have the, especially the uplink band with Google running the stations and your different customers will have 50 megabits down, but they only have 10, 50 megabits up and they’re trying to send a full transport stream in, and that’s just not going to work. So you need to make sure, especially that you do have enough bandwidth on the uplink side because a lot of times people have a lot more downlink than uplink,

Jessica:

Great point. I had a customer the other day that called me. He goes, “I’m taking hits and I’ve been arguing with the cable company and it turns out…” He’s like, “I’m doing a speed test and I’m getting like 50 megabits down.” I said, “Oh yeah, check your uplink.” And sure enough, his uplink was throttling and that’s quite honestly, some of the biggest caveat, it’s getting the uplink speed. And if you have that, SRT works amazing. That’s a good point.

Jon:

So Derek Freeman has a question. Did you see that, Steve? It just came-

Jessica:

Oh sure, I’m just going to look at that and see… In that case, I guess an example, we were talking earlier where we’re rebuilding the tables, I guess it was flexing multiple streams together. He’s asking about PSIP information can be manipulated in the Flex-3000 locally. That’s a great question. That’s just two. As far as PSIP, there are two different kinds of services. The Static, it’ll definitely do the static where whatever programs you take from the different inputs and combine to the output, it’ll create your PMT or your path for that specific stream and allow you to go in and set your major, minor numbers, all that information. But in addition to that, we also do the dynamic PSIP, which is your channel guide information. So once we have your new customized, tailored, output stream made up of components of your input, we also work with Titan TV, Grace Note, and recently it was DSI. Is it Digital …?

Jessica:

Display Systems. Display Systems International, yeah.

Steve:

There’s another one where we’ve just start about operating with. So any of those, if you have an account there, you just plug your credentials into the unit and it’ll just automatically pull your schedules down every day and create all your chunk and information as well.

Jessica:

Yeah, that makes PSIP easy. There’s a lot of advantages to having your PSIP downstream before your transmitter and after your encoder, because number one, you don’t need a $60,000 encoder to put in PSIP. Number two, if it dies, you could put any encoder in there. And the other one is, if your encoder goes off the air for some reason, you’re still a placeholder for your station. So you might be black but at least, your station isn’t gone completely. So there’s some serious advantages to using us for PSIP as well and that’s probably a whole different webinar.

Steve:

Yeah. So flip for that one, coming in the near future.

Jessica:

I had one more question in here. Let me see. Oh, can SRT go multi point? In other words, like we talked about doing the spoken-and-hub, is it a different stream every time or is it multicast?

Steve:

Correct. It is a different stream each time. So the multicast is, different routers will quickly shut down a multicast before it can get out onto the open internet. So, it does require. So if you are doing a hub-and-spoke type application, so that one we were discussing with Global Bible Network where they’re going from the hub into, I think they’re up to like 22, 23 spokes, it is really… I think they’re just sending a single program and I think maybe five megabits, but that is really going to be five times 23 is the total bandwidth that’s going to use up. Because each one, even though it’s one piece of equipment creating all the different routes, it is still separate bandwidth for each one.

Jessica:

Right? Yeah. That’s a good point because the way that SRT works is point to point. So that way the packets… If for instance, packet number 500 is missing, it has to go back and ask for that packet again. And that’s what makes us so resilient is, each location is its own buffer base. So, to set it multicast would just clog up networks. So point to point is really the best thing, also it makes it more secure. But it’s a good question.

Steve:

Great. Do we have…? Looks like that’s all we have here. So here’s your last chance. If anybody has a question, if you want to go ahead and type it in here and we’ll give you a minute or so…

Jessica:

And if not, I’m not calling anyone.

Steve:

Yeah, definitely. Feel free to contact us anytime. You have myself, Jessica, Jon, any of us are always available if you have any additional questions or if anybody wants to schedule a one-on-one demo or if you even want to demo our pair, we have a very good demo policy. Just order it on a 30 day money back guarantee. So if you want to test out, we send a pair out to you, test it out in 30 days, either sending in as fax or sent us a check, preferably a check, but… But there has definitely been situations where the network just has not been stable enough. Somebody trying to put it up on a mountain somewhere and the network’s constantly going up and down and they’re just… You’re just not going to make it work over the public internet. And so in that case, if it doesn’t work. No problem. Just send it back to us.

Jessica:

Yeah. I won’t even bill you for a month. I trust you.

Jon:

So for mobile applications, once you’re set up with DHCP and you have your SRT requirements placed in a box, can you just send that box anywhere? Does it matter anymore? Or do you have to do anything more to it than that?

Jessica:

Now you could stick a FedEx label on and send it, and then you could get the box. I could hand it to you. And all you have to do is you basically just plug it into the wall.

Steve:

It depends a little bit how you configure it, if you configure out in Default way, so there’s… In any case, one of the systems will be a listener and one will be a caller. And the way we typically default set them up is the Send unit is the listener and the receiving is the caller. So there’s space and think of it as a client server where you show the recipients of the client, and it’s calling into the servers, requesting the stream. What’s really nice about this, especially for a hub-and-spoke… So how you configure it, basically on the listener side, it’s just listening on a UDP port coming in on the network. And then on each receive site, you basically put in that port number and wherever the signal’s coming from, that location’s public internet facing LAN address. And then it requires you to put a port forwarding on the Send side so that when the calls come in, it knows to forward that port on to a particular IP address within the lab which is IP address of the Send unit.

Steve:

But what’s nice since they’re all calling into that public address, as Global Bible Network did, if everything would be pre-configured, you already know the port number, you already have the address, you’ve plugged it in, set it up for DHCP. So then you just slide things out all across the country. Each station receives it, plugs it in. It connects, starts pulling the stream, just take it out ASI or IP into whatever downstream device you need to go to.

Steve:

I think we’ve lost your audio there, Jessica.

Steve:

Did you come unplugged?

Steve:

Somehow we’ve lost your audio, but I think we’re getting closer to being about done here. I haven’t seen any additional questions come in. So I guess at this point, we’ll go ahead and wrap it up and say, if anybody has got any questions, we’re always available. Feel free to contact us and hope you’ve enjoyed learning about all these different ways to use SRT from Studio Transfer Links, contribution, distribution, repurchasing old equipment. And once again, thanks for joining us and have a great day.

Jon:

Thank you, Steve.

Jessica:

Thanks guys.

Jon:

Goodbye everyone.

Steve:

Oh, you’re back.

Jon:

Thanks you, Jessica.

Steve:

All right. Have a good day, everybody.

Jessica:

Bye-bye.