---

[This post is part of our Designing Hardware for HD series. Be sure to check it out!]

I’d like to take a bit of a break from all those hardware posts in my “HW for HD” series, now that I’ve covered the video coding chip, as well as scaling and layout issues. Instead I want to delve into the realm of designing the software architecture of the application itself.

The hardware you design will affect your software architecture.

As you might have understood from the previous posts, and we will definitely discuss later when I’ll touch on some additional aspects of the hardware, the hardware of an HD video calling device requires multiple chipsets, interconnected to each other. This means your application is not a single process, but rather a slew of processes, being executed across chipsets. This should not be taken lightly and should probably be one of the initial decisions you make in your application’s architecture.

The first question I want to try and answer regarding the software architecture is who the host is?

Who’s the Host?

Let’s first define the “host” as the main chip, the one that runs the application itself. It is not necessarily where most of the processing is done, but rather where most of the decision making on an application level takes place. Think of it as the brain of the application. It is more of a conceptual selection, to make it easier for developers to deal with the design than any real decision.

My suggestion would be to have the host designated as the chip that is connected to the Ethernet and used to send and receive data packets – signaling and media. The reasoning behind this selection is that this is where most of the core logic of the application will reside – close to the network itself.

As an example, if you are using our BEEHD, then the physical location of our VoIP Client module inside BEEHD should be designated as the host.

What Operates the Host?

As I’ve already written over at NoJitter a while back, my dream chip for HD video will be running Embedded Linux. The reason for that is that I want to make the application as easy to develop as possible. It also means that the host of the video terminal should be running an Embedded Linux operating system or something in that range of flexibility and power. As this is where decision making is done, you’d want that extra flexibility and the strong development tools that are available on Embedded Linux.

What Runs on the Host?

What tasks would I select to run on the host?

There are multiple options. But mainly this will be dependent on the way your hardware architecture is built, as it will force some components to be executed on specific chips.

But generally speaking, here’s the list of tasks/modules that I’d place on the host:

• All network signaling stuff – SIP, H.323, RTP, SNMP, TFTP, HTTP, etc.
• Call control logic – dialing calls, disconnecting, registration to the network, …
• The Address book module
• Management interfaces and logic

Note that I haven’t placed the UI here. While you might argue that the GUI is where the interaction happens and where the logic should be, for me it’s only a thin layer that is displayed to the user – all of the smarts behind it reside in the application, which is indeed located on the host itself.

Oh, and them codecs? They are most probably distributed all over the place, depending on the selection you’ve made for your video chipset.