From Software to Hardware: Transcoder

This year we made and released our own piece of hardware: a transcoder. This is a big transition for a software company because of completely new processes and tasks. Transcoding, in general, is necessary if you want to create a multi-bitrate stream, change parameters of video — the codec and the bitrate of the stream, the size of the image, or overlay a logo on top of a video stream.

But now I’d like to talk about the very process of creating hardware and what objectives has it set for us. Unlike usually, we’ve prepared everything by ourselves, starting from the core. The structure of the transcoder itself is unusual, it is a tricky device with a bunch of processors and Linux.

First of all, it turned out to be completely incomprehensible on how to hire an engineer who will work with the Transcoder and what responsibilities they shall have. Second of all, a bunch of interesting difficulties with core configuration have raised. In addition, the impossibility of intelligible full-fledged testing other than manually is very unusual.

This work has something in common with our Flussonic Iris (it’s the firmware for IP cameras). You need to constantly decide how to use Linux: use system code or write your own. For example, we had to create our own DHCP, TFTP and NTPD servers (one and a half days for everything), because there were fatal flaws in the system’s ones.

Another problem is geography. When we sell software, we and our customers don’t need to go anywhere. That’s the advantage of digital selling. But when it comes to something material, you start to think about the geography and all the “what-ifs” that might be involved. What if the shipping might not be possible? What if a customer wants to actually see and try the Transcoder before buying it?

These are the issues we’re solving right now, but it’s all worth it — the hardware Transcoder is a great break-through for us.