Leslie Ellis's blog

Goodbye Tru2way, Hello To ‘AllVid'

By now it’s clear that the chapter involving CableCards and the retail part of Tru2way is closing, if not closed.

We’ll stop short of “stick a fork in it, it’s done,” because as former National Cable & Telecommunications Association attorney Dan Brenner once quipped, it’s just never a good idea to stick a fork into a piece of electronics.

Here’s how the Federal Communications Commission said it, in its April 21 notice of inquiry (NOI) on multichannel video issues: “We are not convinced that the Tru2way solution will assure the development of a commercial retail market.”

And, from FCC commissioner Robert McDowell: “To be blunt, the CableCard approach … has been disappointing.” Let’s review the facts. CableCards grew out of an FCC mandate that banned (only) cable operators from deploying set-top boxes with integrated security.

So they did. Today, some 18 million boxes are deployed with CableCards, at a cost north of $1.2 billion.

No, the new “AllVid” proposal from the FCC is for an “adapter,” or “set-back device.” The latter is so named not because it’s a setback, of course, but because it sits back. Small, unobtrusive, out of sight.

The FCC’s set-back adapter would handle signal reception, tuning and upstream (home outward) functions. Oh, and conditional access. (Quick translation: On the condition that your account is in good standing, you get access.) So much for that integrated security ban.

The adapter would hook to a different, “smart video” device, which would handle “navigation functions, including presentation of programming guides and search functionality.” That’s a biggie for the consumer-electronics industry: they’ve wanted first-screen navigation for two decades.

If you’re hungry for tech-talk, the 28-page NOI is chewy. Short list of terms to keep an eye on: DLNA, short for Digital Living Network Alliance. It’s the protocol that lets different gadgets connected to an IP network identify themselves on different screens with an icon (e.g., “hi, I’m a TV,” “hi, I’m a PC,” and so on).

Also: DTCP-IP, or Digital Transmission Content Protection/ Internet Protocol, a not-new way to enforce digital rights, using encryption, which most in the video foodchain seem to agree is OK.

Mostly, the NOI asks questions. Lots of questions. (I lost count at 22.) Some of them venture alarmingly deep into the techno-weeds. Citing how devices connected to cable’s switched digital video systems need a way to tell the switch when a viewer stops viewing (true enough), the FCC asks: “What protocols would be necessary for the AllVid adapter to query whether the navigation device still requires access to the program stream?”

That answer, and 21 others, are due back to the FCC in mid-June. Heigh-ho.

Interactive TV And Pipe Cleaners

Almost 10 years ago, this column investigated the fraught-ridden life of the interactive-TV trigger and its taxing journey from origination to TV screen.

“Like salmon, triggers are born with a mission: To make a difficult journey, perhaps with a tryst near the end. If they’re lucky. Then, it’s over,” the column noted.

Back then, we were talking about ITV triggers in terms of “ATVEF” (pronounced as a word), the name of a Microsoft- originated standard at the time. (And you thought “EBIF” was bad.)

Then and now, “triggers” are the clickable things that appear on the TV screen, hoping to be bright and sparkly enough to entice viewers to click.

This was back in the days when interactive TV triggers slipped into the vertical blanking interval of analog TV signals - the place where closed-captioning data rode. Digital ITV was still fairly new.

Then and now, the matter of trigger transit safety is huge. So much so that these days, in the engine rooms of interactive TV and EBIF, you hear people talking about “pipe cleaners.”

EBIF stands for Enhanced TV Binary Interchange Format. Just the inclusion of the word “binary” should be an indicator that it’s teeny - written tightly, on purpose, so as to reach as many fielded set-top boxes as possible (25 million this year, of a total potential footprint of 50 million-plus).

But just because EBIF apps are small (about 150 Kilobits per second, rough numbers) doesn’t mean they’re any less vexed by transit issues. Think about it: Being the clickable thing on the screen means being squirted into a video bit stream, blasted up into geosynchronous orbit (or injected into a terrestrial fiber backbone), received, processed and resent to homes.

The “pipe cleaner” talk, then, is about how to keep that whole transit path clear of debris and drop points.

Technically, pipe-cleaning is a workflow. It involves plunking a data feed on top of a video stream’s primary audio and video packet identifiers, or PIDs, at the content origination point. (For the advanced class, this involves the use of a special scheduler, which talks to a special data carousel to create an additional MPEG Transport Stream containing EISS and DSM-CC PIDs.)

Without pipe-cleaning, triggers run the risk of getting squished or dropped somewhere along the way, which means they don’t get to the TV screen. Not good.

Key places to start jabbing the pipe cleaner, if you’re the one in charge of degunking: Satellite receivers with analog outputs, certain re-encoding points, and in those dense quadrature amplitude modulation multiplexes.

The Map TO CMAP

In cable, making room for more new stuff is two-pronged.

First is the chronic question of bandwidth: How many slots on the digital shelf can go to more HD and VOD? How many for any new 3D and Internet-protocol TV offerings?

The second prong is the matter of sheer physical space. If you’re the keeper of headends and hubs - heating, cooling, power, rack arrangements, wiring - it’s not a good day when the headend starts looking like the five-pound bag, with another 10 pounds of new stuff on the way.

At issue, in large part, are those impressively nerdy mainstays of digital cable: the QAMs. Quadrature amplitude modulators are necessary to imprint digital signals onto the physical plant, for transmission to subscribing homes.

Pretty much everything needs a QAM in cable, including the new stuff. But up until now, most service categories attracted their own vendors, each with their own QAMs. There are QAM suppliers for video and QAM suppliers for voice and data.

Right now, the densest packing of video QAMs is eight per port. For broadband data, four. Switched digital video? Up to 16. IPTV will need a few to start, then more as the service develops.

Right now, they all exist in isolation. Different racks, different batches of gear.

That’s why the industry’s headend caretakers - led by Comcast - posed this question: Why not make the QAM spigots denser, and more capable of sending information across service categories?

If you’ve gotten this far, you’re probably hip to a relatively new, Comcast-specific term: “CMAP,” which stands for Converged Multiservice Access Platform. It grew out of another Comcast acronym: “NGAA,” which stands for “Next Generation Access Architecture.”

If you dabble in the cable-modem termination system landscape, this is probably sounding a lot like the “modular CMTS” conversations that dominated the broadband cable scene a few years ago.

This is different, in that it’s a blueprint for gear.

Here’s what CMAP isn’t: It’s not a new version of DOCSIS, nor is it an active CableLabs project. That’s because it’s a product definition, not an interface specification. In other words, it doesn’t mess with how data talks when it moves from one port to another. Instead, it suggests a way to mix and match QAMs for video, voice and data services, in a denser way. 160 of them, per port, with room to grow.

This is at the write-the-specs stage now. They turn into CMAPs as soon as next year, with launches expected the year after. More on this as it develops.

IPTV and Bandwidth

We’ll take a break from the lingo of IPTV this week in favor of a more fundamental question: How much bandwidth does it take to send linear and on-demand video over IP?

The short answer: Less. Less than it takes to deliver “traditional” digital TV streams, anyway. Why? Three reasons.

Reason #1: If you’re prepping for video over IP (meaning video over the path now used by cable modems), you might as well do advanced compression. The two move in lockstep.

Advanced compression – variously called MPEG-4, AVC and H.264 – makes it possible to squish two to three times more HD streams into the same channel size (6 MHz, or, the equivalent of around 40 Mbps.)

To put that in perspective, today’s compression – MPEG-2 – slims standard definition (SD) TV streams to 3.75 Mbps, and HD streams to around 15 Mbps.

By contrast, MPEG-4 skinnies SD streams down to 1 Mbps or less, and HD streams as low as 4 Mbps. (This is highly dependent on screen size.)

In bandwidth costs, that’s a big savings right there.

Reason #2: IP video – at least the on-demand stuff – will be switched. Switching is a bandwidth efficiency method all by itself.

Reason #3: The built-in statistical gains that come with moving video packets through wider packaging. What wider packaging? The bonded, or “wideband” channels, that come with the DOCSIS 3.0 cable modem specification.

Statmux refresher: If compression squeezes video streams to their smallest state, statistical multiplexing hyper-organizes those compressed bits, for the ride to homes.

Right now, in “traditional” digital video, statmuxing organizes multiple video streams more efficiently, inside one 6 MHz channel. In a four-channel wideband bond, though, the statmux gets to work across 24 MHz. The extra elbow room, space-wise, translates into more little gaps that can be filled with video packets.

The supplier community, and especially those who sell the gear that will enable video over IP – meaning Cable Modem Termination Systems (CMTS) and in-home gear – says that moving video over IP can save as much as 40% in bandwidth, compared to traditional means. (They have a dog in this hunt, of course.)

This conversation typically veers into talk of variable bit rate encoding vs. adaptive streaming. More on that another time.

A Reader's Guide to This Week's Tech Feast

Big doings in Denver this week, especially for the tech-interested. That’s good, because it’s been six months since the last big core dump in cable engineering, and four months since that empty spot, in mid-June, when the SCTE Cable-Tec Expo used to occur.

 

It’s time for a feast.

 

If your plans give you a full week in Our Fair City, and you can attend both the CTAM Summit and the SCTE Expo, start on Monday at CTAM with “We Have An App for That! Bringing New Applications to Traditional Devices,” “3D Television: Entering the Third Dimension, Ready or Not?” and “Ringing Toward the Future: Home Phone Market, Technology and Trends.”

 

Then, don’t miss “Cable’s Consumer Product Agenda,” on Tuesday morning, for the view from an A-list of cable technologists from Bright House Networks (Nomi Bergman), Comcast (Tony Werner), Time Warner Cable (Mike LaJoie) and Rogers (Mike Lee).

 

For those planning to stay through the SCTE Expo, don’t miss the 8:30 opening on Wednesday, October 28. We have it on good authority that the keynote by John Schanz, EVP of Network Engineering & Technical Operations at Comcast, will be a multimedia abundanza of past (SCTE celebrates 40 this year), present, and future.

 

Plus, the Expo workshop schedule – which doesn’t repeat this year, heads-up – is right on the money of what’s on engineering minds. If you can’t go, here’s a sampling.

 

Advanced Advertising: If it’s your thing, but you’re not as hip as you’d like to be about  “SaFI” (pronounced as a word that rhymes with “taffy”), check out the “Advanced Advertising: Making it a Reality” session, on Thursday from 8-9:15.

 

DOCSIS 3.0 and Wideband: Lots to choose from here. Take IPv6, for instance – the new numbering system for Internet-connected devices. To do this in context, take a count, before you leave home, of all the items in your house that take an Internet connection. (Here in the geekosphere, the count is 16.)

 

Today’s numbering system for Internet-connected devices – Ipv4 – is redlining. IPv6 expands the number of number of IP-connectable devices to a one with 18 zeros behind it, which is roughly analogous to the number of known stars in our universe. That’s good, but the transition to IPv6 isn’t without challenges.

 

The SCTE workshop motherlode also hits on how to write applications for EBIF and tru2way; how to engineer for video over IP and “TV everywhere;” how to measure the impact of IP video on capacity planning, and how to get wideband and channel bonding going in the upstream. Aaaaah, details.

 

For dessert? Make your way toward Golden Gate Canyon, 30 miles west of town. It’s a quick getaway into some Rocky Mountain scenery that will assuredly blunt the stress of such a jam-packed week.

 

###end

EBIF, Revisited

In the blur of last week’s mash-up of cable events, the lingo landscape bulged with EBIF, pronounced “ee-biff.”

 

EBIF refresher: Five or so years ago, U.S. cable got wiggy about a U.K. interactive TV staple that allowed viewers to participate with programs by “pressing red” whenever a “red button” appeared on the screen.

 

Work commenced at CableLabs to fast-track a way of doing “program synchronous” interactivity here, so that viewers could, say, click to vote a player off a reality show, or click to dive into the on-demand warehouse to pull up additional titles of an episodic show, or see longer-form versions of an ad.

 

A driving goal was ubiquity. Nobody wanted another interactive plan that worked only on a small subset of deployed set-top boxes. That body of work began to be called “ETV,” for “Enhanced TV.” The technology behind it was the enhanced binary interchange format (EBIF).

 

Somewhere in there, Canoe was born, and took the lead on the ad-centric applicability. That work will become reality yet this year, Canoe people said last week.

 

Comcast executives are similarly headlong into EBIF, which is good news – because if consumers are exposed only to EBIF triggers that lead exclusively to ads, they could easily “learn,” incorrectly, that clickable things on the TV screen are ads, so why bother.

 

The word from Comcast: Eleven million set-tops will be EBIF-enabled by year-end; shloads more next year. Applications will be launched in three categories: Content-based (a better way of saying “program synchronous”), widget-oriented (meaning not tied to a particular show), and guide extensions.

 

That last one was news to me. It makes sense, especially for expediency: Stop spending a year or more on enhancements, including testing a big, monolithic code footprint to work right on a huge and mixed base of deployed boxes. Instead, launch smaller features individually, and quickly, using EBIF.

 

Example: A “remind/record” app, which lets consumers ask to be reminded to watch favored programs. The “remind” part is aimed at people who don’t use a digital video recorder – you’re watching TV on one channel, and are reminded that you wanted to watch a different channel at that time.

 

This is one of those intuitive things, like Time Warner Cable’s “Start Over,” that just makes sense for TV. Case in point: Comcast placed the “remind/record” app on an ad for Lifetime’s Project Runway in its San Francisco market for four days; 2,600 people hit it.

 

I don’t know any Runway fans who wouldn’t dive at a chance to get a reminder (of anything) from Tim Gunn. The whole thing makes it tempting to call 2010 “the year of EBIF.” Someone should probably just say it.

Why the Transition to IPv6 is Tricky

For such a nerdy, network-y name, IPv6 rides with some pretty colorful language. Without it, for instance, the global Internet faces “IP address exhaustion.” With it, we could theoretically affix an IP address to “every atom on the surface of Earth.”

 

But getting to IPv6 (from IPv4) won’t be trivial, engineers said over and over during the recent SCTE Cable Tec Expo. (And in engineer-speak, “non-trivial” is several shades darker than “really challenging.”)

 

Here’s the situation: We’re running out of IP addresses, and pretty much everything needs one. Bad news for any TV, PC or handheld screen craving an Internet connection.

 

Two entities are the keepers of Internet Protocol addresses: IANA, the Internet Assigned Numbers Authority, and ARIN, the American Registry for Internet Numbers. IANA runs dry by the end of next year; ARIN in 2012.

 

That’s why it’s good that so many IPv6 addresses are on deck – except for the largess of getting backbone, access and in-home networks ready for them. Turns out that the coexistence of IPv4 and IPv6 addresses is … well … non-trivial.

 

From a consumer perspective, if the bits moving to or from a screen affixed to an IPv6 addresses smack into any gear the route that only knows IPv4, whatever that consumer was looking at won’t load right, at least the first time.

 

For the caretakers of broadband, going to IPv6 requires careful planning and phasing. (This particular point is consistently bracketed in “I can’t emphasize this enough” admonitions from the engineers working on it.) It’ll seem like a slowdown, or a glitch, and it will happen on the day you hit every red light on the way to work, while feeling like you’re getting a cold.

 

The transition itself can go down in at least three ways. Safest, from a consumer perspective, is “dual stacking,” which means gear that speaks both v4 and v6.

 

Or, there’s tunneling, also known as encapsulation, which sidelines into terminology like “6to4,” “ISATAP,” and “Teredo.” All describe different was of making the new stuff look and act like the old stuff.

 

Also an option: Network address translation, or NAT, which does the opposite – it translates v4 addresses into v6 addresses.

 

Other, more tactical considerations: Getting the actual IPv6 address allocations; deciding where to start transitioning – core, or edge; picking routing protocols; prepping all back-office functions; and making sure all bases are covered — so that the new, v6 stuff doesn’t put the existing, v4 stuff at risk.

 

Bottom line, and to quote Comcast’s John Brzozowski, chief IPv6 architect and principle engineer: “This is no one-man show. Everyone in your company has something to do with the success of your v6 program.”

 

Best get on it.

 

 

Yes, But Does It Scale?

In combing through pages of notes from CTAM Summit and SCTE

Cable-Tec Expo, one word popped up over and over (and over).

Scale.

Examples: “What EBIF will give us is scale.” “We have to scale

and get more and more DVRs out there.” “Part of my job is, I’m supposed to make

it scale.”

And, my personal favorite, “Even if you dual stack or single

stack your mail servers, many of these spam mitigation techniques, especially

if you’re depending on an IP address, don’t scale

so well.”


Scale, in the context of a consolidated industry operating

in compressed times, is about the peace of mind that comes with knowing you can

get enough materials, from suppliers who aren’t going to do something crazy — like

go away, or be gobbled up by a “frenemy.” It means deployable to millions of

customers.



The components of “scale” usually include cost, physical

space requirements, and the ability to nestle comfortably and quickly into data

center workflows, like provisioning and billing.

Here’s an example. You’re hot with a new service that will

assuredly stuff gobs of cash into everyone’s pockets. Giddy with the

possibilities, you find a way into your cable partner of interest, to lay out

the plan.


On your end, let’s say you need at least one digital, 6 MHz

chunk of shelf space. You need a corner in the headend, for your racks of gear.

You’re pretty sure you can link to the provisioning system, as long as it’s

similar to how you wrote yours. You’ll have just a scant impact on billing. And

you’ll figure out a way to make sure field techs and care reps are nurtured

(just as soon as you find someone to put together some documentation.)




Uh-oh. Before you even pull out the laptop with the slide

presentation, you’ve struck out. Twice.

Hey! At least you have the gobs of cash. If you’d polished your

product as a churn reducer (as its major feature), you’d still be waiting for

the meeting.

As a fallback position, there’s always the other kind of

scale, which always comes to mind around the major Eating Holidays. (Which kick

off next week, unless you count Halloween.) Tipping the scale in that sense can

usually be remedied on the treadmill.


As for this other kind of scale: It’s a front-of-mind

ingredient for everything that needs to happen, from here on out. May yours be palatable.

Cable's Two 3DTV World Firsts

In case you missed it (I did), the home team achieved two world’s firsts last month, when it comes to getting 3D content into consumer homes.

Both occurred during the SCTE Cable-Tec Expo, in a tucked-away CableLabs corner tagged the “3D Pavilion.”

World’s first #1: Sending and displaying two 3DTV channels and 3D-VOD, delivered simultaneously over Comcast’s plant. The 3D signal was live for three days (the duration of the Expo) and was decoded by existing set-tops.

Up until then, 3D vendors brought their own demos, tricked out to make their gear look as good as possible.

The material was 3D-encoded at the Comcast Media Center, using the “over-under” method. That means squeezing the right eye and left eye frames on top of one another, within the same digital channel. An assortment of compression rates and resolutions were sampled – some 720p / 60 frames, some 1080p / 24 frames.

World’s first #2:  Connecting multiple brands of 3DTVs to the same signal, at the same time. Or, put another way, the coexistence of passive and shutter glasses, on the same 3D signal.

Here’s why that matters: Different brands of 3DTVs use different types of eyewear – both “active” (shuttered) glasses, and “passive” (polarized) glasses. Up until now, confusion reigned about whether the same incoming signal could feed TVs that use different types of glasses.

Answer: Apparently so. The demonstration made clear that 3D signals don’t require special formatting for one type of eyewear vs. another. The 3D-TVs can resolve those differences internally.

Closing observation: The amount of progress in 3DTV for home use, even since the SMPTE 3D and Digital Cinema deep-dive in April, is astonishing. What looked to be a “five years out” thing suddenly seems much, much more imminent.  The technical kinks are clearly being resolved.

What’s needed now (in a huge oversimplification): 3D content.

CBR, VBR and Adaptive Streaming

Here’s another example of video lingo from different sectors bumping into one another: The way video is streamed on the Web, versus the way it works on cable. (Or broadcast, or satellite, or telco, for that matter.)

It’s hard to keep it all straight. Hence this week’s translation.

Original Internet video streaming dates back to the dial-up days. Streaming meant video bits flowing over the Internet, which could be viewed on the computer screen as they arrived — if, of course, there’d been no dropped packets along the way.

Next came the “progressive download.” The biggie. Adobe Flash, Microsoft Silverlight, and YouTube use it, among many others. The “progressive” part means you watch the video that progressively spills into your PC’s hard drive, as a file, after a comfortable chunk of it had loaded into your browser’s cache.

The new big thing in Web video is “adaptive streaming,” sometimes also called “fragmented MPEG-4.” It mixes traditional streaming with file-based delivery. The “adaptive” part means multiple video files of the same content are each encoded into two- to four-second chunks. That way, the client can switch between files on the fly, at varying bit rates, depending on available bandwidth.

Example: You’re watching an HD video stream on your computer. At the moment, and probably unbeknownst to you, it’s coming in at a throughput rate of around 7 Megabits per second (Mbps). Suddenly, the Internet sneezes — congestion. In the background, your player knows to hop to a 5 Mbps stream, or a 3 Mbps stream.

On the linear cable side, digital video is encoded in one of two ways: Constant bit rate (CBR), or variable bit rate (VBR). Both deal with how the bits are stuffed into a pipe of fixed size (6 MHz, or 38.8 Mbps). Variable bit rate is harder to do, but more efficient; it finds ways to fill the pipe completely, smooshing bits into all blank space. “Zero nil bits,” as they say. Almost all linear video uses VBR encoding these days, thanks to statistical multiplexing.

VOD, on the other hand, still uses CBR, as does switched digital video – meaning that a fixed amount of the available bandwidth is ascribed to each stream (3.75 Mbps per stream for standard definition video; 15 Mbps for HD).

In that sense, Internet adaptive streaming of fragments is like VBR for on-demand. Near-VBR, for lack of a better term, because fixed file sizes (2 Mbps, 4 Mbps, 6 Mbps) are still on the scene.  You click to play a stream; it’s sent in a way that optimizes quality, depending on available bandwidth.

That’s the basics of Internet vs. cable encoding, for video streaming. Next week: Your own personal Faraday cage? Really?

Syndicate content