Well, welcome again to our audience to the third podcast in our series on AV over IP sponsored by Matrox, a partner to Sound and Video Contractor. My name is Phil Hippensteel and I am a contributor to Sound and Video Contractor. With me again are Ron Berty, Business Development Manager at Matrox and Dave Chiappini, who is the Vice President of Research and Development for AV-over-IP Solutions. In our second session, we talked about latency in compression as well as in the network, bandwidth management, and the appropriate network to carry video over IP. Again today, we have a series of new questions and we’ll get right to them.
I found a feature in your products that I think I really like and I’d like it clarified a little bit. I spent a good portion of my career at one point when the first 568 cable standards were written and schools and colleges insisted in putting in structured cabling. I did a lot of consulting because I happened to be working doing consulting work with a cable manufacturer at that point in time. So I’m sensitive to the question of cabling infrastructure and things like that. Your decoders feature a daisy chain capability. How do I use that?
Ron: That’s an option we built into our decoders that allows for – certainly the key element is that it allows for more convenient wiring, exactly as you’re sort of describing. And you know, when we look at it, and certainly what we found when we started getting into AV-over-IP and even before that, and even in base band, just regular signaling for display walls and that sort of thing, wiring and installation can be expensive. So with this option for daisy chain on the decoder it kind of allows you to wire a venue, say, like a stadium. You can do it more efficiently. So if you have a stadium the decoder behind the display over each doorway around the concourse and all those doorways going into the stadium, you can keep daisy-chaining from one decoder at one door to the next instead of wiring back to the switch in each and every case. So it’s very possible and likely there will be less wiring in general, but also it’s the cost of the installation of running that wire back to the switch using the ports and so on that it can save a significant degree and make it just simpler and easier to work with. So alternatively it also allows you to connect the network to the display for display communication for managing the on/off of the display. After the event is over when you want to shut down the display itself and the lamp there so you’re saving the lifecycle of the display and also the energy costs are important and on people’s minds today. So instead of wiring – using one port on the switch for the decoder and then one port for the control of the display you actually run one wire to the decoder and connect the other port on the decoder to the display and manage it that way because we’re just passing through the commands to the display or the return code from the display back to the control mechanism. So it’s a really easy way and it just saves on used ports on the switch and on running and installing that additional cable. And then on top of that we sort of learned from that and on future appliances that we build on the end code side we’re actually planning on building and addressing the point that we talked about before and managing bandwidth. So we’ll have two ports on a future encoder that’s going to come out midway through next year, one for data and one – well, it could be used for either, but there’s two ports there and the idea is that you can use one for data and one for the V-LAN if you want to separate the data and the V-LAN as well. So it just gives you that additional flexibility to manage that. And we really learned that sort of from your point, Phil, on the decoder side where we started using it for daisy chain and then we started learning from people and telling us we’d like to see that on an encoder too because we want to separate that out, that communication on the encoder and manage the bandwidth of our network a little better.
That’s what I thought it did and that’s – I like that. I think that’s really neat. I think that’s a slick feature. Another very hot item that’s been around the IT industry for a long time but is very, very quickly developing in the AV industry is a question of security. And your PowerStream control software is secured. It tells me that in your literature. The intention is to prevent inadvertent or intentional tampering with the encoders. I assume that means the control traffic is encrypted and the user’s identity is authenticated. Am I correct?
Dave: Yeah, you’re correct, Phil. PowerStream uses HTTPS for all commanding and control access to Matrox devices. This means that your communications are as secure as typical remote banking solutions are. There’s also a password system in place for user authentication and managing user access, right? But security doesn’t stop there. We use tightly-controlled firmware in the box that helps us further control and manage access. We manage network ports in our devices to minimize any access or any access point for unauthorized access to our devices. We use signature authentication methods on all of our firmware to guarantee that you can’t tamper with firmwares on updates so that we’re always sure that our firmware are Matrox-signed firmwares; Matrox also uses Microsoft signatures and so on wherever we can to guarantee integrity of our applications. So we’re committed to constantly investing in our security practices and you’re right. It’s a growing topic on the AV side. Now that more and more everything is connected by IP, which is a great benefit, it’s also everything is connected malicious people will try and take advantage of that and so best practices and constant vigilance are required on all suppliers and the network designer side to try to prevent easy access from these people. And we recognize it’s a major concern of our customers and we strive to build in the products and the features that they can count on for all of their uses.
Well, while we’re on that topic, and you mentioned this once before about applications, how about the importance of the .NET API?
Ron: Yeah, Dave sort of touched on it before in a broader sense. The .net-based PowerStream API for our Matrox encoders allow our customers to build their own application if they wish to do so. They can – they don’t necessarily – we don’t require people to use the applications that we build. We sort of build them in a general sense but the API gives them access to all the features of our own PowerStream application or our new PowerStream Plus application. And it allows them to pick and choose what features they would like to expose in their own application. So for instance, as an example, you might – administrators might use PowerStream or PowerStream Plus because it has all the features built into it and it gives access to everything. So the idea being that wow, we don’t want to lock out things like the GOP structure, like being able to change the group of pictures or IP and B-frame structure. But at the same time administrators may not want users to be able to access those so they might want to make a smaller and more simplified application for their users that they can just turn off and on streams or change the source of a stream on a decoder or that sort of thing, but not give them access to those more highly-developed feature sets that are really all about the H.264 encoding and the quality that you might get.
They may also want to use like the PowerStream API to add PowerStream features into their own existing application so that their users have access to an existing and familiar application that adds PowerStream access and control. In many cases this can make the transition to AV-over-IP much easier for the user and allows them to access this new sort of AV-over-IP technology in a simpler and familiar way. They’re not looking at it as new technology. They’re just looking at it as a new feature. And it just makes it easier for people to get used to this new way of doing things in some cases, those that aren’t that familiar with AV-over-IP and driving streams onto the network. You know, and then on top of that – and Dave touched on this as well – we have a deeper and more low-level API’s and libraries that are open and that open up our core technology to potential OEM’s and integrators that simply want to take advantage of Matrox’s core technology and the way we’re doing and implementing our H.264 encoding and all the other features that we expose. And they want to expose it with their own brand or existing branded applications. These libraries and API’s also allow the OEM’s and integrators to create more purpose-built applications. And again, Dave touched on that. They build these purpose-built applications on top of our core technology for more specific needs and details that they’re aware of in their markets for their potential customers in specialized markets like for instance military applications or process control like oil and gas applications or even medical applications where those OEM’s or integrators really have gone very vertical and very deep in those markets and know a lot about the details of those markets and what those customers want as it concerns AV-over-IP. And with those libraries and deeper-level API’s they can expose specifically feature sets that fit those markets and brand it to themselves and sell a whole new and more advanced product specifically for that market that’s built on our core technology. And those are really key elements to Matrox and how it believes our products can work in the market. We built something that’s generalized and works well for general and everyday opportunity and then we also have the API’s and SDK’s and libraries that allow customers to build them to go deep dive on specific applications and feature sets for well-known and developed markets that they’ve worked with for years. So it’s a nice mix of the two types of environments and we see a lot of response for that. And the API certainly has helped us grow the market for ourselves and for our customers.
So clearly you’ve made a significant investment in R&D and a big part of that is the API. Where do you see the technology going? Where do you see the markets going and how do you think your research and development will fit into that?