Companies, who generate a lot of media—such as video production studios, educational institutions and houses of worship—have the need to properly organize and manage their creative assets. Solutions for such needs are usually referred to as media asset management and video workflow systems.

One such company, who requested that we do not mention their brand name in this blog, has created an all-in-one solution that provides users with ingest, shared storage, long-term archiving and disaster recovery services. Inside this product, our MFormats SDK is used to take care of transcoding, metadata extraction, proxy and thumbnail generation tasks.

Patrick Deuster, Product Development Manager, explained how they make use of MFormats today:

It’s used in every single product running our latest software. So, anytime we have to generate a low-res proxy version just for preview on our search screen — Medialooks is used; any transcoding to go from this format to that format — Medialooks is used; any time we generate a thumbnail — Medialooks is used; any time we index a file and get metadata or any type of attributes from a file — Medialooks is used. So, it’s heavily baked into the core of the product.

Patrick is not complaining about performance either:

Performance has been great. Especially once we throw a pretty beefy GPU in the system, we get really good performance. We’re going 3 to 4 times the speed when we’re doing proxy generation. The P4000 Nvidia card… I think we’re doing 4 simultaneous transcodes on that card. We’re pushing the upper limits of what that card can do and what our code can support.

Before implementing MFormats, the company used Telestream’s Episode, which is now a discontinued product. Interfacing a third-party transcoder via the command line wasn’t flexible enough: solving the transcoding problem with the Medialooks API turned out to be easy and Patrick was able to do it quickly:

It wasn’t a huge time for us. Just playing around with it, I was able to just take those couple of classes and move them to our main application and hook it up. So, probably less than 2 weeks. Overall it was not a huge spin-up time on my side…The hardest thing is just understanding the concepts behind it but once you get that it’s pretty easy to do. There’s good documentation, which is always appreciated, because inevitably you’re going to be figuring out why something isn’t working. There’s basic examples to show you how to do it and then you have to kinda roll your own ideas on how to make it all work.

He also gave this advice for developers who are just beginning to experiment with the SDK:

It’s literally: here’s the sample programs, go line by line and learn the methodology on how it works. Don’t be afraid to break it, because it’s the only way you’re going to get the experience; don’t be afraid to fail. The only way to learn it is to get in there and start playing around with it.

Moving to MFormats was obviously a way to save time and improve the product—but it was also fun to use for the developers:

I personally like the SDK; it’s very easy to use and integrate into our system; and quite frankly when we first put it in I didn’t think we would rely on it as much as we do today.

See also