Encode > Serve > Play
Having touched on rights and Intellectual property from the perspective of content producers, I am going to segue in to some deeper technology discussion now, but starting with the focus on intellectual property and a look at the elemental building principles of content delivery networks.
The Basic Building Blocks
In nearly all streaming paradigms there is a very established and common theme throughout. A simple broadcast or transmission network, be it used for video transmission or other types of signaling, will typically have a simple start and end point, or if you like, a client and a server.
In the distribution model we have to scale this up somewhat so that there is a client/server model established between the original video signal “capture” and the distribution “hub,” and then there are typically “many” client/server connections between the hub and the end users.
Thus at its very basic level, as shown in Figure 2.3, a typical content delivery network architecture will comprise three basic building blocks of Encode > Serve > Play.
From a computing perspective this is actually a pairing of client server systems where the “server” stage is both a “client” of the encoder and a server for the player-client. Note that this is why a fuller workflow (as seen in Figure 2.1 for classic live streaming workflow) splits the central Distribute stage into “acquire and distribute”).
We will explore this model in some depth, and go into some detail on the internals of the various stages. We will also see how many such models can be orchestrated to run in parallel, and equally how each of the stages in such models can be scaled out independently.
Figure 2.3 Basic building blocks of a content delivery network.
For now though, it is sufficient to simply follow this three-stage picture and quickly apply it to some analogies we may be familiar with:
- • TV broadcasting might have an encoder in its outside broadcast truck, a server at its play-out center, and the “players” could be considered to be the TV sets.
- • An enterprise video platform might have an encoder connected to a TV camera, a server on a central office platform, perhaps integrated with a knowledge base or perhaps a training platform or something like Microsoft SharePoint, which would then have the capability to serve each video browser as the “player”
- • A financial data network may encode real-time data into a form suitable for trading desks at the stock exchange, aggregate that in a high-frequency trading platform (“server”), and then deliver that to many banking terminals “players”
- • A content delivery network (in the common sense of the term) that would typically think of the “encoder” as a stage in the process that their customers take control of, leaving them to offer a “server” as an entry point or “origin” on their distribution network, which may in turn comprise a “tree” of servers that form the distribution topology, each of which then provides the “edge” services to which the end users with Set-Top Boxes or mobiles (etc.) can connect (“player”).
I included the financial data network because while at first sight the nature of the content makes the system look unrelated to the delivery of TV and video, the fact is that architecturally there is very little difference between these distribution models - the nuances are actually to do with quite fine details.
This is a good thing: most distribution challenges can be broken down to fit this three-stage model. However, this simplicity has also been exploited in ways that were counterproductive for the sector, and an example is covered in the next section.