Monthly Archives: November 2006
Getting to Know MetaData 2.0
by Leslie Ellis // November 27 2006
By now, you’v undoubtedly bumped into the “metadata” term a few times. It’s not new. In a video sense, metadata is the information applied to a title at its creation, to describe who’s in it, what it’s about, how long it is, when it needs to be removed from a video on demand (VOD) server — that kind of stuff.
At this moment — just after Thanksgiving, 2006 — the metadata used by cable operators in their VOD systems is pretty stable. It grew out of a specification issued by CableLabs in 2002, which means it’s had four years to bake into the gear used by content owners, aggregators, and headends.
Yet, as any tech-side person will tell you, the blessing and the curse of technical specifications is their tendency to engender additions. Metadata isn’t immune. As the on-demand sector continues to evolve, so does the need to improve its component parts.
That brings us to “VOD metadata 2.0,” a specification released by CableLabs earlier this year. This week’s translation is about what it does, and three reasons why it matters.
For starters, know that most of the goodness in the VOD metadata 2.0 spec happens way in the background — far from consumers, their couches, their TVs, and their remotes. This is back-end, behind-the-scenes, make-your-life-easier stuff.
If you ask a technical person to state the number one most important thing about metadata 2.0, they’ll probably explain how it eliminates the need to “double-pitch” a video asset (meaning a title and its accoutrements) if something changes.
In today’s VOD world, when you want to change anything about a title that’s already been populated into a server, your only option is to ask for a re-send of the whole thing. That wastes bandwidth. The new spec fixes that. More title volume, less bandwidth used. So that’s one thing.
If you pose the same question to a VOD operations person, they’ll waste no time in telling you what a pain it is right now (pre 2.0) to correct metadata when it comes in botched.
You’ve seen the botches. You’re browsing through the on-demand library. You come upon a listing where the title is repeated as the description, or the description is so long, it falls off the screen.
To be able to correct just the botched metadata, without having to re-send the entire show, is quite the hallelujah for systems people. (And yes, content owners, that does mean you’ll be asked to re-send your metadata, if it comes in goofy.)
The third item of note about metadata 2.0 is the grace it imparts to packaging. Right now, for instance, if you’ve received and stored a title, it probably has specific rules attached to it about how long it can stay active, and how to price it.
With 2.0, you could take that same title and bundle it into a double-feature, or a weekend special. You could switch out promos or advertisements, offer a 99 cent special, or do whatever you want (assuming you have permission) — again, without having to go through the process of requesting a re-pitch.
Plus, 2.0 improves search features, adds substantial multi-lingual support, and lets you use multiple display formats — if, for instance, a title can be played out in HD, SD, and a super-compressed mode, as may be needed by a handheld player.
That’s the highlights of what you’ll be able to do with the metadata 2.0 spec. The next step is for the supplier community to build it into actual applications, and for the content community to start marking its wares for 2.0.
It’ll happen in the background, but it’ll happen.
This column originally ran in the Technology section of Multichannel News.
The “F” in “HFC” Stands for “Fiber”
by Leslie Ellis // November 13 2006
Based on the volume of mail from East coast-based cable system employees over the last few months, it appears that there’s plenty of interest about the actual carrying capacity of fiber optic cable, versus coaxial cable.
One reader, based in Virginia, tagged her fiber curiosity to “a bad case of FiOS-in-the-face,” referencing Verizon Inc.’s triple-play brand. In case you haven’t seen it, here’s a sampling of how Verizon fluffs fiber into a series of bouncy refrains: “Jump into a brilliant fiber optic future!” “Internet and TV transformed through the power of fiber optics!”
If you, too, are feeling FiOS-weary, remember this handy fact: Cable operators jumped into a brilliant, fiber optic future nearly 20 years ago. They started transforming TV through the power of fiber optics in the late 1980s.
That’s why there’s that “F” in “HFC.” It stands for “fiber.”
And speaking of the “F”in “Hybrid Fiber Coax” — ever wonder where fiber drops off to coaxial cable, relative to your house? We hear loads about Verizon’s “fiber-to-the-home.” But where does cable’s fiber actually drop off, other than “at the node”?
Answer: Probably about a quarter mile from your house, if you live in a city or its suburbs. Translation: Not far.
The decision about how far to pull fiber toward homes is a big one. Not going far enough can attract interference, noise or distortion. Going too far can get real expensive, real fast — especially if digging into streets or lawns is required.
Back in the days when cable operators were first making these “how far” decisions, they put a giant amount of energy into design tests about how far fiber should go. It was the stuff of technical papers at industry conferences. (In fact, what’s now the SCTE’s annual “Conference on Emerging Technologies” began life, in the late 1980s, as its “Fiber Optics” conference.)
It turned out that the best place to hand fiber off to coax was at the center of a circle with a one kilometer radius. Figuring average densities of around 80 homes per mile, and typical subdivision layouts, there were about 500 homes inside that circle. That’s why you hear about the “500-home node.” The distance from the outer edge of the circle to the middle is about a quarter of a mile.
Drum Roll Please
There is a way to do the math on fiber v. coax carrying capacity, but know going in that the answer is misleading. The type of fiber used for sending video — known in tech circles as 1310 nanometer, single-mode — can move as much as 10 Gigabits per second, compared to around 5 Gbps for coax.
Actual carrying capacity does vary, depending on how long the fiber is, and what you put on either ends. But in general, it’s safe to conjure fiber as the fire hose, coax as the garden hose, and twisted-pair copper (meaning telephone wires) as the sipping straw.
Don’t despair, because that’s the simplistic way to look at raw capacity. Let’s put aside, for a moment, the notion of re-usable bandwidth, node splitting, and switching — all of which correlate into nearly unlimited bandwidth potential for cable operators.
Instead, let’s look at what all that bandwidth (real or perceived) gets you. Consider a high-end home in the future — maybe four or five years out. Inside are eight high definition TVs, four cable modems, and four voice adapters. Let’s even say the HD streams were squished by an advanced compressor, so they take up even less space.
If all of the HD displays were on, and all of the cable modems were streaming video, and all of the voice adapters were handling calls, you still only get to about 72 Mbps, needed by that house. (“Only.”)
The math goes like this: Eight HD displays times 8 Mbps per HD stream is 64 Megs; four cable modems, streaming video, 8 Mbps; four phone calls, negligible. All in, 72 Mbps.
Think about that, the next time someone dangles 100 Mbps in front of your nose.
Both fiber-to-the-home and any handful of cable techniques — channel bonding and switching come to mind — can blast that much bandwidth to a house. More, almost certainly. But what will you do with it?
Think of it this way. Your car’s speedometer probably goes up to about 150 miles per hour. When was the last time you pushed the needle up to the 150? Have you ever?
Somewhere along the way, fiber became sexy. Verizon made it so. So much for not using industrial terms in consumer marketing…
This column originally appeared in the Technology section of Multichannel News.
Broadcast Video vs. Internet Video
by Leslie Ellis // November 06 2006
Google as a multichannel video provider is a head-spinner. On the regulatory front, you have to wonder: Will Google relax its death-grip on network neutrality, if it too needs to send “broadcast quality” video as a part of a subscription package?
And then there’s the question of high definition TV content. If audio snacks on bandwidth, and video eats it, HD devours it. Is the public Internet plumbed to deliver big vats of big HD video, without collapsing? Can it handle even the ordinary needs of broadcast video?
Enter the technology portion of the conversation. Broadcasting a digital video stream, either over the air or over a series of wires, differs considerably from sending a video stream through the Internet. This week’s translation is about those differences.
If you’re having a déjà vu moment, rest assured that you did already see the foreshadowing for this. Kind of. Remember that National show in 2003, when Microsoft chairman Bill Gates grilled Comcast CEO Brian Roberts about how much of his digital spectrum he’d make available in IP (Internet Protocol)?
Add time and Internet momentum, and here we are. Gates posed a long-term question: While you cable people are going about making your networks all-digital, why not make them all-IP, too?
Three years later, the answer is the same: Why?
As with most things, both techniques — traditional broadcast, and IP — have strengths and weaknesses.
Broadcast video, like what you get from your local TV stations, cable operator, or satellite provider, has two identifying characteristics: Signal direction (one way only) and audience (no upper limit, no need to know your electronic address).
“One-way” means there’s no mechanism for a receiver (your TV) to tell the sender (your video provider) that a packet was trampled along the way. That’s why digital broadcasts apply extra bits to what’s called “forward error correction,” or FEC. FEC works in the background to make sure your digital picture (standard definition or HD) stays solid.
FEC applies to all three types of broadcasts (cable/satellite/broadcaster). It was built for efficiency. (Yes, cable boxes are two-way, but they weren’t always. And broadcast video, because of that FEC, only needs a one-way ride.)
By contrast, Internet Protocol — which underlies the public Internet, and thus Internet video delivery — is two-way. Its audience is point-to-point and individualized. It was built for a different kind of efficiency.
Two-way also means there’s a path for a receiver to tell a sender that some bits got smooshed en route. In tech talk, this exchange goes by “ack-nack,” for “acknowledgement” (“got it!”) and “negative acknowledgement” (“re-send please.”) Because every packet goes through the “ack-nack” process, IP doesn’t use very much forward error correction. It doesn’t need it.
It follows that because IP was designed for point-to-point, individualized deliveries, it is not so great at anything that needs to be sent simultaneously to lots and lots of receivers. Think of all the ack-nacks. Plus, any sender — Google or otherwise — essentially needs to know who wants its video. Bandwidth notwithstanding, they can’t just blast it out to an unknown “everyone,” like a broadcast.
Translation: Digital broadcast techniques used by cable, broadcast and satellite providers excel at efficiently sending popular, commonly watched, “one to many” content. They are not so inherently good at “long tail” or highly individualized material. (That’s a job for VOD.)
The inverse is true of IP. It’s not so good at hitting the masses with broadcast material, but it shines for lesser-watched shows with smaller audiences.
Of course, the IP camp is cooking up ways to remedy its broadcast shortcomings. You’ll hear people talk about a technique called “multicast” (translated in the August 30, 2004 edition). It’s like putting the flag up on your mailbox, to indicate that you have mail, except instead you’re indicating to the Internet that you’d like to receive a particular piece of Internet video. So far, it’s regularly described with terms like “clunky” and “inefficient.”
So, Mr. Gates, the “when all-IP” question is still plausibly answered with a “why.” Why do one to the exclusion of the other, when you can already do both? Things best delivered on IP will be sent on IP. Things better delivered on broadcast, like high definition or live events, will be delivered on broadcast.
This column originally appeared in the Technology section of Multichannel News.