As the electronics world lurches toward everything under the sun wanting an Internet connection (and the faster the better, where video is concerned), so grows the use of the term “encapsulation,” in technical circles.
It usually manifests in two flavors: “IP to MPEG encapsulation,” and “MPEG to IP encapsulation.” The former gets “Internet” video to the TV; the latter fashions “traditional” cable and linear broadcast video for the PC, handheld, or anything else with an IP connection.
Here’s how people talk about it: “IP encapsulation of QAM-delivered content … can help to enable consumption in ways that aren’t limited to service provider-installed devices.”
Translation: The stuff that comes into the house for the TV is containerized differently than the stuff that comes into the house through the cable modem, to the PC, and any screen (wired or wireless) that can connect to it. That’s because digital video preceded broadband, for one. Plus, it uses a transport mechanism built to favor the needs of video.
In order to make a smooth ride for video to screens other than the TV, that content may need to be re-packaged. That’s encapsulation.
This is where the language of it gets almost visceral, in terms of how it works. Here’s another example, from a recent batch of notes: “What you do is, you strip off the IP header, de-jitter the stream, then restore it to MPEG format.”
A simplified look at the differences: An MPEG transport packet is always the same size: 188 bytes. IP uses variable length packets. MPEG transport is all about a smooth flow, to ensure a TV picture without glitches. IP packets might be for web pages or email, where smooth flow is less noticeable.
For that reason, something needs to make traditional video packets look like Internet Protocol, and visa versa. The question is where that happens: In the house? Before the house, in the network? Positions vary, but this is one element to watch in the industry’s slow-but-sure traipse to transporting more-IP, and eventually all-IP.
