Video SDK: replacement of internal video playout server by wTVision, Portugal

broadcast studio

Headquartered in Lisbon, wTVision builds integrated broadcast solutions for TV stations worldwide, including global customers like Globo and DAZN. The company maintains sales and engineering offices throughout the world, in Spain, Belgium, United States, Brazil, India and Dubai. We sat down with Daniel Gonçalves, Innovation Officer and Pre-sales Director to discuss his products and how the Video SDK helped bring a new playout product line to life.

What is the story behind wTVision?

wTVision was founded in 2001 and started working on football matches and basketball events, primarily generating graphics for television. At the time, the core product was just the controlling software: it allowed the operators to manipulate graphics engines and automate some of the graphics insertion processes. The software was agnostic to the engines and that was one of the key selling points. Later, the company started doing live shows and news content. And then, gradually, throughout the years, we started doing more and more broadcast operations and began developing our own graphics engine and video playout technology.

What do your customers value?

Our customers like the interfaces in our products. They say they are very well-designed, very easy to understand and provide the information they need for their operations.

The other thing they like is our availability for customization. One of the key characteristics of our software is the customization layer. And, in our overseas offices, software developers work with this customization layer to deliver the final version of the product to the client.

Finally, it’s the capability of the software to work with multiple brands and models of various third-party products. This is a very good selling point because, as you can imagine, not all of our clients are new TV broadcasters who just show up to build their infrastructure from scratch. I would say that most of them have existed for multiple years now and already have a solution for broadcasting. They want to change that solution, but they want to keep their media servers, or graphics engines, or video routers, or video mixers. The fact that we can work with any product that they may have is a very good factor for them. They value that.

What products is the Video SDK currently used in?

One product that we are actively selling. It is called the wTVision Media Server Streaming Edition, a video playout solution, 100% software-based, that lets you play out all your media assets and also have live inputs for your TV channel – so, it can be used for MCR operations or live production operations. It's not advertised as a standalone product, we only sell it if you buy our playout automation or live production solution.

We are also developing a new version of the Media Tools. The old version had to be installed on your computer and you could only work with it from your computer. The new version can be installed on a server in your data center. The new interface is web-based, the user can just open the browser on any workstation that is on the same network, or VPN to the server that has the software installed and access the interface of the software. The old version was limited to SDI inputs. This new version, because we are using your SDK, can open any kinds of streams.

Why did you think it was a good idea to use a third-party SDK?

We were spending a lot of time on media processing. To open the container, decode the content, synchronize all the video and audio… At some point, the maintenance of this piece of the solution was having a huge impact on the company because the development team was only focused on video management and not on developing the other parts of the software.

Also, at that time, some of our clients were looking into playing out directly to the Internet. Let's say, they have their main channel and they want to open pop-up channels or smaller channels that are branching from the main channel so they can have their own network. They were looking into streaming directly to the Internet or to the cloud and this requires the output to be already compressed and to have a known protocol.

And that's when we looked at Medialooks. We have been trying the SDK and felt it had all we needed. So we decided to see how long it would take us to replace the video management core of our software with the Medialooks engine, and how long it would take us to reach the same feature set in the product with the Medialooks SDK. And, to be honest with you, it was amazingly fast. It was really fast. We reached the same feature set in a matter of weeks. It was really fast.

And on top of that, we also opened the possibility to have all these features that our clients were asking for. Do they want to do SRT outputs? Now we have them. Do they want us to do WebRTC? Now we can offer that. Did they want to do RTMP or UDP? Now we can offer that as well. And we don’t have to develop all of that, we can just call a few APIs, and we will have that functionality in our product.

The fact that it was very easy for us to integrate with the Medialooks SDK means that our development team could switch their focus to work on the features of the products that our customers value. Because in the end, if you think about it, our clients do not care how you open an MXF file or if you open it with ease or not. They just want the file to be opened and played out and they want to know what else you can do besides that.

Do you recall having doubts and how was the learning curve?

I wouldn't say we had doubts about how things worked. When we started using the SDK, it was quite easy for us to go straight to what we wanted to do. It was only when we started digging into the features that we started having some questions. And although you have a very good knowledge base on your website, some things were not that clear. But you have improved a lot since then. I recently had to switch these products to a new team, and it was really fast for them to start working with it. The learning curve was very, very good.

What have you achieved with the SDK?

The features that we can now deliver to our clients are way more comprehensive, we can offer more in our products to our clients. The way things work is… it's very reliable. The repeatability of the things is very, very good. For the same kind of inputs, you can expect the same kind of output.

What do you think is the business value of the product to you?

I can tell you this: if we had not switched to your SDK, at this moment we wouldn't have, most probably, our MCR product line… It allows us to focus more on our core business, then on developing the media engine – because our business is the end solution, not the video handling part.

What do you like most about the SDK?

The comprehensiveness of the features that the broadcast business requires. You offer a solution for most of the things broadcasters need. It's very comprehensive and easy to use… Medialooks is kind of a Swiss Army knife for media handling. I bet that you hear this a lot, but I think it's the best description for Medialooks. In terms of features, I think nothing beats Medialooks.

One of the biggest challenges that we are living in is that the level of demand for video quality is lowering. More people and more customers are more open to lower-quality video. Some of our clients are moving back to HD, leaving Ultra HD behind.

Another trend is the move into virtualized environments. It means the software needs to be less hardware-dependent. This is a challenge because diagnosing software is way more difficult and we need to develop new tools for that.

See also