After a historical review of Barco’s evolution from radios to television to industrial video, Marc explained how the company shifted from software that has to adapt to the hardware to software that is in the pilot seat.
In the 20th century, technology evolution was fast, they became deprecated very quickly. Now, however, the technologies last for much longer, and you can make investments for a longer time.
10 years ago, the FPGA was at the core of the design. It is combined with DSP and microcontrollers to glue things together. Software plays the role of the network controller, as a single management access point. However, this model requires resources to be committed for 4-5 years. The components had to be expensive and underperforming to meet the lifetime requirements. What is driving the technology is not the industry, but the consumer market. And mobile makes that even more so.
In mobile, the software was becoming less performant and power-efficient (Java VM, automatic memory management), which drives processes and memories to just perform better to make it work.
Barco’s first encounter with GStreamer was in 2006 on a MPC8349 core with uClibc. But this had very bad thread switching overhead, and the processor was not as fast as expected. The problem was that the hardware was a given, not driven by software. So yet another custom stack was developed, but it learnt some lessons from GStreamer.
In 2008, Barco developed a x86-64 server based system, which doesn’t have all the limitations of previous products (hardware). This solution removed much of the limitations of the previous custom stack because GStreamer has so much already, and bugfixes etc. were upstreamed. The stability and flexibility make a convincing case. From that point on, the custom stacks are gradually replaced with GStreamer. For instance, compatibility issues with camera network streams are solved in the network processor instead of needing to hack the receiver itself. Finally, because the GStreamer API is defined externally, it stops endless discussions of what the API should be.
Can GStreamer still be used for very high bandwidth applications? E.g. raw HD video handling. Obviously, this cannot be done, but GStreamer can be used for the metadata handling (caps negotiation, …). The data handling and network stack is done in FPGA.
For GStreamer, there is no difference between raw and compressed video. This allows to keep the hardware contained. All the custom hardware is contained in v4l2 interfaces.
The switch to GStreamer didn’t come easy. “It is slow”, “it adds overhead”. Indeed, sometimes it is slow or incorrect, but fixing a bug is better than rewriting a complete software stack.
Compared to Barco’s previous open-source experience, the kernel, GStreamer allows a lot more reuse. The kernel is very much tied to the hardware. In userspace, however, the solutions you come up with in one project can be used in other projects with zero extra development.
Like the API, an external project also forces the issue of tooling. For instance, to use GStreamer and be able to modify it, it is kept in git instead of importing snapshots in svn.
The challenge now is to migrate the company to a software-centric product. The first step is training. Because GStreamer is an external project, it is possible to buy training without requiring the trainers to be educated in the internals of Barco. Instead of making a board and giving it to the software team, now there are architecture meetings across the divisions.
The use of open software requires the company to think about what is really the added value that the company brings. They have to move away from “our case is special” and adopt standards. Since others can do the same as you, you have to keep moving.