Leslie Ellis's blog

This Is Just A Test

By: Oct 24 2011 - 5:24pm

Here’s one you may not have heard about: On Nov. 9, at 2 p.m. (ET), anyone, anywhere in the U.S., who’s sitting around watching TV will witness a test, just a test, of the national Emergency Alert System.

It’ll be just like the local EAS tests conducted each month, but nationwide. Everybody, all at once, same message.

The reasoning behind it is grim, but logical: What if the president needs to get an emergency message out to as many people as possible, with or without a live Internet? Answer: Send it to the TV.

That’s the reasoning, devised by the U.S. Department of Homeland Security, the Federal Emergency Management Agency, the Federal Communications Commission and the National Weather Service.

The test is a first, over a system that’s never been activated to be hierarchical. Only local. And, as it turns out, the technology required for the effort isn’t exactly a no-brainer.

First of all, it’s not like someone is sitting at a console, over at the headquarters for FEMA, Homeland Security or the FCC, saying, “OK, Freddy, type this in.” There’s no hitting “send” and distributing a message, live, to every TV set in the land.

No, the message itself, and for the purposes of the test, is to be hard-coded into the existing gear that handles local and state emergencies. In a cable sense, that means gear in headends, listening for the EAS trigger, then force-tuning all set-tops to a channel.

The thing is, the verbiage of the visual message doesn’t exactly say it’s a test. The audio does, yes. The text? Not so much. And it’s too close to the test to change it now.

What happens on Nov. 9? Here’s how the FCC describes it:

“During the test, the public will hear a message indicating, ‘This is a test.’ The audio message will be the same for everyone, however due to the limitations of the EAS, the video test message may not be the same and may not indicate, ‘This is a test.’ This is due to the use of a ‘live’ national code - the same code that would be used in an actual emergency. Also, the background image that appears on video screens may indicate ‘this is a test,’ but in some cases there may be no image at all.”

So, what if the sound is off or the ears aren’t working right? Seems likely that someone, somewhere, will see the alert’s text - “This is a national emergency,” or some such - but not hear that it’s just a test. People flipping out, as a consequence, seems plausible, if not likely.

Meanwhile, work continues within an outfit called EAS-CAP (www.eas-cap.org), where the “CAP” stands for “Common Alerting Protocol.” Its tagline is “promoting standards for the next generation of EAS.” The FCC in September extended manufacturer compliance with EAS-CAP specs from Sept. 30 until June of 2012.

So, if there’s a next generation of EAS coming by next summer, maybe hold off on the test until then, instead of freaking people out? Just a thought.

Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.

The Flip Side of 'Service Velocity'

By: Oct 17 2011 - 12:15pm

Fail quickly. On driving home from the airport recently, I tuned into the middle of a BBC show. In it, four delightfully British people were talking about the advantages of the Internet for startups. Four times, one of the top three reasons stated was the ability to fail quickly: Think it up, put it up, see if people like it. If they don’t, take it down. Gather lessons learned, dissolve, move on.

Example: You want to open a store. In the old world, that meant finding space, then signing a year’s lease. Online? Try it out. If it doesn’t work, take it down. Fail quickly.

This is all great, unless you’d just spent cash money on the product or service. Or you really liked the thing that failed quickly.

Another example: Your salon gets you completely hooked on some new hair-care product. You agree: It’s the best. Then, six months later, they don’t carry it anymore. You reluctantly try the new thing. Get hooked. Six months later …

In the rolling transition to “all things IP” (Internet protocol), one benefit comes up a lot: service velocity. Launch new services more quickly. Say goodbye to the dreary muck that is hooking into back-office systems that grew up in the proprietary-heavy past. Keep content fresh. Add new features in eight weeks, not 18 months.

Service velocity is everything you’ve seen happen with “the guide,” all tightened up, studded with graphics and available in ways that aren’t constrained to the remote control: on an iPad, on your smartphone.

Here’s how people talk about it, culled from an evergrowing batch of notes on the topic of The Big IP Transition: “Development cycles are getting shorter and shorter. For set-tops, we have about 300 developers and quality-assurance (QA) people who do nothing but set-top box software. With those 300 people, we put out a total release of the guide about every 18 months.

“Compare that to the development of an iPad app. We had 10 developers and QA people. Start to finish, we put it out in five months; today we’re on the fourth version of the app. Last year, this time, the tablet wasn’t even in people’s hands.”

That was Comcast executive vice president and chief technology officer Tony Werner, talking to a Canadian audience earlier this year about service velocity. Another part of it, he noted, is the back office. “Five, six years ago, we started to stand up all the back-end systems into Web services.” Goodbye, huge internal integrations; hello, Web-based interfaces to practically everything. Hello, cloud.

Service velocity is important, for obvious reasons. The cloud gets you there. So far, the only obvious examples of “fail quickly” in the video world are those apps, usually not related to video, getting taken down from connected TVs.

Failing quickly, as a byproduct of service velocity, is inevitable. All I ask is this: When you decide something’s a failure, think about how to treat those people who really like it or who just spent hard-earned cash on it. Give us an alternative to try. I thank you in advance.

________________________________________

Stumped by gibberish? Visit Leslie Ellis at www.translation- please.com or multichannel.com/blog.

Some Class Qs on IP

By: Oct 10 2011 - 12:27pm

Nothing like teaching a class about the transition to everything over IP (Internet protocol) to keep you on your toes, translation- wise.

What’s top of mind about IP in a classroom full of cable people at this moment in time? For starters, that skinny little upstream path and whether Comcast is doing something different with it, given its work on video-Skyping via the TV.

Lots of questions, too, about what all ultimately goes into “the cloud.”

And, my personal favorite, because it’s easiest to answer: What is VoLTE?

Answer: Voice Over Long-Term Evolution, where “LTE” is that get-funky mobile euphemism for wireless broadband. LTE was developed for broadband and is oriented for IP-based data services.

So, putting voice over LTE isn’t as much of a no-brainer as you’d think, even though mobile as an industry grew up on voice as its bread and butter.

From a consumer angle, Comcast’s work with Skype is imaginable: Wave to the nieces from a perch in front of the TV, instead of in front of the laptop. As for Comcast’s upstream signal boundaries,they’re no different than the rest of the industry: a mean little swish of spectrum located between 5-42 MHz.

MSOs historically and deliberately haven’t attempted to stuff video upstream. Why? Not enough room. Will the blobbish-ness of video-Skyping clog it up?

According to the engine-room talent working on it, there are two things to keep in mind here. First, there’s a beginning and an end to a phone call. Unlike TV, you don’t usually leave the phone on or open after you’ve said goodbye.

Two, the signaling and codecs involved are designed to be mindful of bandwidth. This means that Skype in the upstream is not like that swell surveillance camera on sale from Acme Camera, which only does full-motion JPEG at 5.5 Mbps upstream (because it’s cheaper! And bandwidth is free!).

About the cloud, and what all goes up there: maybe not everything, but close.

Remember that cable innately is a cloud - an intelligent network that relays entertainment, information and communications back and forth to homes. Watch for cloud storage (think network DVR), and cloud guide (think iPad app), and the business logic and databases of “the back office,” in the cloud. Identity management, parental controls. Voice mail and email already sit in the cloud for the most part.

We are entering the kitchen sink phase, friends, for clouds and gateways. This is a transition, a marriage of households. That means for some period of time, you’ll either need two of everything, or have three of the thing you don’t need.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.

One! More! Time! IP and Bandwidth

By: Sep 26 2011 - 1:24pm

Just under two decades ago, at a National Show breakfast for engineering mucketymucks in L.A., MIT Media Lab founder Nicholas Negroponte, who at the time had just published Being Digital, caused a few dozen forkfuls of scrambled eggs to quiver with indignation.

Back then, it was a relatively new bit of network blasphemy; today, it’s a perennially popular theme: Bandwidth should be free!

Fast-forward to now. The work of today’s network engineers is the race to service the dozens of electronic doodads in our lives, parched for broadband. For them, bandwidth is anything but free, especially if you’re the one girding for the growth in moving all the bits.

It’s a two-step. Analog went to digital. Digital now goes to IP — Internet protocol.

Going from A-to-D was one thing, and a big thing. And it’s still in motion.

Just as analog spectrum bows to digital, digital morphs. Once, “digital” was the thing that made it possible to do lots more TV - remember John Malone’s “500 channels”?

The volume of things that become quaint every two months is simultaneously exciting and depressing.

So, back to bandwidth basics this week. The bandwidth of IP. A typical cable system is built to 860 Megahertz of total available bandwidth. Some go higher (1 Gigahertz); lots go lower (750 MHz). But let’s go in the middle.

Subtract the upstream path, which represents about 5% of total available capacity between 5 MHz and 54 MHz. That includes guard band, so that stuff going down doesn’t mess with stuff going up.

That leaves 811 MHz, or, about 135 “channels” - where “channel” means a 6 MHz chunk of spectrum. (Will the 6 MHz designation become vestigial? It appears so. But that’s not for this column.)

Suddenly, the signal path carved out for IP traffic - used by cable modems and voice-over-IP - needs to grow. For more than a decade, two 6-MHz channels carried everything an operator needed to service highspeed Internet and voice services. Not so now.

By next year, that pool of IP-capable channels could go to 12. Why: Because soon enough, the average U.S. household will contain an average of six screens that play video from an IP-based signal. That’s roughly two times the number of TV screens accustomed to receiving signal through a set-top box connected to a TV.

Meanwhile, the trend of making everything smaller and lighter - a function of silicon - thrives. Hardware cedes to software. Lines of code are the new black. (Sigh.)

On the drawing boards or production schedules, depending on who you ask, are chip designs that make it possible to go “all-IP” - meaning that the entire downstream spectrum, from 54 MHz to 860 MHz, can be undone as 6-MHz channels, and treated as a giant pool of IP spectrum.

That’s all a function of bonded DOCSIS 3.0 channels. Bond them all, the logic goes. Use gateways (see last week’s column) for the transition. In conventional logic, this transition will take a decade.

Which means blink twice, and we’ll be there.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

It Slices, It Dices, It Juliennes Fries

By: Sep 19 2011 - 12:35pm

“Gateways.” Over the past decade, this column has mentioned that term 33 times, across a gamut of uses. In the beginning, gateways ganged around home-networking conversations, and how to accommodate the range of wired and wireless options that were then nascent.

Since then, gateways invaded the lexicon of voice-over-Internet protocol (”signaling gateways,” “media gateways”), cable modems (”DOCSIS signaling gateways”), and digital video (”residential gateways,” “home media gateways”).

Lately, gateways are grabbing the spotlight again. This month, at IBC2011 in Amsterdam, Liberty Global detailed its aggressive “Horizon” gateway plans; over on this side of the ocean, Canada’s Shaw Communications, BendBroadband and Comcast are all active with gateway tests and deployments.

What’s it all about? In this 2011 chapter, gateways are about extending the reach of your video subscription to all the screens you’ve bought (or will buy) that take a broadband connection.

In engineering lingo, these things we’re buying that play video and want broadband connectivity go by “unmanaged devices,” or, in Comcast’s case, “customer owned and managed” devices (COAM).

By contrast, “managed devices” are those things designed, installed and maintained by the service provider - set-tops, cable modems, digital terminal adapters (DTAs), and for voice, EMTAs (embedded multimedia terminal adapters).

Gateways help to make those unmanaged devices more manageable.

Here’s a sample bill of materials for a gateway: Six QAM tuners (for “traditional” digital video), four DOCSIS tuners (for broadband stuff), dual-band Wi-Fi, Ethernet, a big hard drive (for DVR). MoCA and DLNA, for multiroom DVR and unmanaged device recognition. Chips that convert MPEG-2- compressed streams to MPEG-4, or vice versa.

The idea is this: Lots more glass is going into people’s homes, from big-screen HDTVs to laptops to tablets. Instead of putting a $300-ish dual-tuner HD-DVR on all the big screens, put in one $350- ish gateway, connected to as many $50 “slave” or “client” devices on the other TVs. And, be able to better service the other connected devices, fed by broadband.

The logic makes sense, except for the other big trend: Virtualization, and the making of everything into software, set-tops included.

Are gateways an interim step to a world where everything’s invisible, constructed of malleable lines of code? If so, the vendor community carries a cheery view of what “interim” means. Gateways started showing up at trade shows in 2009; we’re watching for another gateway glut at the SCTE Cable Tec-Expo in November, and through next year. The players: Arris, Cisco, Motorola, Pace, Samsung, and Technicolor (formerly Thomson).

Expect a mish-mash of inclusions, exclusions, and jargon around this one. Or, as this column noted in January of 2001: “Note that there’s serious lexicon confusion around this device.’ ” Still.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

Adaptive Streaming: Cloud, Gateway or Both?

By: Oct 31 2011 - 2:11pm

Here’s a good one from reader Jan: “Where does adaptive streaming happen - in the cloud or in the gateway?”

Adaptive streaming is the process of slicing a digital video file into different sizes: maybe one that’s two seconds in length, another that’s four seconds and so on. The technique necessarily works hand in hand with “transcoding” and “transrating,” which match available bandwidth with video stream size. Less bandwidth, stream the smaller file; more bandwidth, stream the bigger file.

One glance at last week’s TelcoTV event in New Orleans shows a vendor community that is teeming weth adaptive streaming (and teaming, for that matter - see Itaas, RGB and Verimatrix). Why? When one is bandwidth-constrained, which can happen squishing a linear, multichannel HDTV product over DSL networks, it’s good to have adaptive streaming at hand.

Which isn’t to say that adaptive streaming is just an AT&T thing. It’s attractive to anybody with a network that’s staggering under the weight of that pesky 45% growth rate of video as a percentage of IP traffic. That means cable, mobile, and telco networks.

Which brings us back to you, Jan. Where does adaptive streaming happen, gateway or cloud? The answer is … yes. Turns out, parts of adaptive streaming can happen in both places.

Some cable technologists say the headend is the place to right-size streams to suit the care and feeding requirements of the end displays - tablets, PCs, laptops, things that connect through the cable modem, not the set-top box. Slice, authenticate and secure video streams there.

It’s all very Scotty McNealy, who put Sun Microsystems on the map in the late 1980s with this famous remark: “The network is the computer.” (Which brings to mind the one about how the difference between early and wrong is indistinguishable.)

Other technologists point out the gateway or “hybrid box” (half cable modem, half set-top box) could be the place to do transcoding. In that case, it’s not so much about sizing the stream for the screen, based on available bandwidth. It’s more about making it so that any of your screens can play any of your digital video archives. Maybe some titles you own were compressed with the older stuff of MPEG-2.

Maybe some of your screens only know how to decompress the newer stuff of MPEG-4/H.264, or vice versa. That’s when you’d consider putting transcoding activities there.

Plus, silicon is simultaneously growing in capability while shrinking in size. The gates on the chips are there (or will be) to support the heavy processing requirements of trans-coding.

Which is good, because there’s an H.265 compression method on the drawing boards, and the 2012 Consumer Electronics Show is likely to show fresh examples of “4K” video - the next size up in picture resolution, from today’s 1080p HDTV.

Anyway: Gateway or cloud? Yes. Both. So far.

________________________________________

Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

Who Did Coin The Term 'Cloud Computing'?

By: Nov 7 2011 - 4:16pm

In the Oct. 31 edition of MIT Technology Review, writer Antonio Regalado delves into the origin of this ample ingredient in tech jargon: “Cloud computing.”

His research puts the date at November 1996 - almost exactly 15 years ago. That’s when a renegade group of technologists inside Compaq Computer (later bought by Hewlett-Packard) coined the phrase as a strategy to sell more servers to Internet-service providers.

Not Google in 2006. Or Amazon, with its Elastic Compute Cloud (abbreviated “EC2″). Or Dell Computer, which tried to trademark the term in 2008, only to get lambasted by the ever-vocal computer programming community.

Given the reach of the publication and the incendiary nature of such a topic, I’m betting a dime that Regalado gets lots and lots of comments (and email flames) on his linguistic time stamp.

Think of this in plain old cable terms. Ever ask an old-timer who built the first cable system and where? It always comes out at least two ways: Oregon and Pennsylvania, in a dead heat.

Besides, it just seems to me that “cloud computing” must twist back farther than 15 years.

Here’s how the National Institute of Standards and Technology recently defined the term: “A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service-provider interaction.”

“Or service-provider interaction?” Not to quibble with the nation’s standards-setting body, but for the readers of this publication, and as this column has pointed out before: Cable is a cloud. That’s even more the case these days, as operators and programming networks race to place clickable icons on all of our screens that can play video, but aren’t necessarily connected via a set-top box.

Think about it: Headends are morphing into “data centers,” and every operator in the land is readying its “as-a-service” suffixes - in the cloud world, these go by “infrastructure as a service (IaaS),” “software as a service (SaaS)” and so on.

That brings into question whether “cloud computing” is synonymous with “network-based computing.” I’d say yes.

Regardless of where you stand on the matter, you can’t ever go wrong in reading MIT Technology Review, which last year brilliantly asked whether what’s going on is a cloud - or a swamp.

One line stood out to me in Regalado’s piece: ” ‘Cloud computing’ captures a historic shift in the IT industry as more computer memory, processing power, and apps are hosted in remote data centers, or the ‘cloud.’ ”

So, be super-nice to your IT people. They’re the folks who will make sure you’re a cloud, and not a swamp.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com or multichannel.com/blog.

Big (Cable) Tech Trends for 2012

By: Dec 19 2011 - 8:30pm

And here we are again at the last issue of the year. This week, we’ll go more “things in motion stay in motion” than “history is a great teacher,” with a forecast of five big tech trends for ‘12. Here goes:

1. HTML5. This one skips into the shop-talk scene every day, it seems. Remember the big fight between Apple and Adobe about which was better, HTML5 or Flash? Steve Jobs won. What HTML5 means for cable: A way to render subscription video on all those Internet-protocol-connected screens, without the need for customers to do anything (like download a player). It’ll focus the 2012 scene around efforts like remote user interfaces (RUIs), companion-screen viewing, and putting clickable, MSO-branded icons on screens served by IP.

2. ACR. Automatic Content Recognition, Audio Content Recognition, po-tay-toe, po-tah-toe. If the hype about this one gets any more breathless than at the recent TV of Tomorrow conference in New York, we’re in for a doozy of a year. Why: ACR, in essence, is an out-of-band bypass technique. An app on a handheld (or built into the TV) listens to the stream, as it plays out, and correlates interactive stuff with it. That portends a dance of angst between program networks and service providers, in the familiar tune of “We Don’t Need You to Do This.”

3. IPv6. Short version: Everything connected to the Internet needs an address; the pool of addresses (IPv4) is running out. As in right now. There’s a remedy - IPv6 - but issues will abound, likely in a “death by 1,000 cuts” pattern. No huge calamities; lots of little aggravations. IPv6 isn’t backward-compatible with IPv4, for starters. This one affects all of us: consumers, retailers, manufacturers and service providers.

4. CDNs and “Federated” CDNs. Content delivery networks, or CDNs, exist to store and process video hierarchically for delivery to all of those IPconnected, video-capable screens we keep buying. They’re a mixture of national and fiber backbones, storage servers, and ways to slice and dice video files into right-sized chunks for the end screens that want them. Bigger operators, like Comcast, started years ago on their CDNs; smaller operators are talking about “federated” CDNs, useful to rent capabilities rather than having to buy glass and servers.

5. Clouds and Gateways. Gateways are in-home devices that work as both set-top boxes and cable modems. Lots of tuners for bonded IP channels (read: shelf space for IP traffic). Lots of ways to transcode incoming video into other formats. Bigger processors, more memory, more ways to interconnect all the stuff in your house.

But wait: Isn’t the cloud for handling transcoding and processing? Sit tight. Transitions, like the one we’re living in right now, usually can’t accommodate a flash-cut (to cloud, or to gateway). Both will exist, here in the fervor of the transition.

That’s the short list. Next time, what to expect at the upcoming Consumer Electronics Show in Vegas. Until then, merry merry and Happy New Year to you!

________________________________________

Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

Adaptive Streaming and Picture Quality

By: Dec 6 2011 - 3:45pm

Ever wonder what could happen to picture quality when a given screen is displaying a “downshifted” stream of video, sent using adaptive bit-rate techniques? I did, and was glad to soak up a session about it at the recent SCTE Cable-Tec Expo.

Short version: Arris CTO Tom Cloonan and colleague Jim Allen built an emulator in their lab to sample what happens when different types of traffic gets smooshed together on the Internet-protocol plant.

Refresher: Tons of video is moving over the Internet. Unprecedented growth. It uses a lot of bandwidth, comparatively. Everyone’s working on it - by adding IP bandwidth and by working the end points. The “clients,” in the lingo, mean your other screens - laptops, tablets, smartphones.

From a bandwidth perspective, here in the twilight of 2011 (and the eve of big channel bonding), adding more IP bandwidth means going beyond the two to four downstream digital channels reserved for broadband and voice-over-IP services. (Watch for this to rise to 12-18 bonded channels in the next few years.)

Consequently and inevitably, video-service providers will start increasing the types of traffic sent over the IP part of the plant. That means plain old Web browsing, plus whatever’s moving “over the top” on the public Internet, plus the newer “managed IP” video services.

On the client (screen) side of the equation, adaptive bit-rate streaming (a.k.a. “fragmented” streaming) is big. It works by chunking video streams into different sizes - in the Arris experiments, 3, 2.1, 1.5 and 1 Megabits per second - so that if bandwidth isn’t available to play the bigger chunk, the client can request a smaller chunk next.

Which brings us back to the question of what happens on your various screens when network congestion causes a downshift in video bit delivery?

Nice descriptive language in this wheelhouse, by the way. Example: Things that can go wrong crop up as “rendering engine starvation” and “videoresolution dithering.”

Both conditions stem from network congestion - the former when the software in the end point device (tablet, TV) doesn’t get enough bits; the latter when not enough bits arrive to render a goodquality picture, causing the screen to “dither” between 1080p and lower resolutions.

Also factored into the simulator: An “aggressiveness factor” to assess who does what when bandwidth does become available. As it turns out, some client software is more aggressive than others - meaning they jump up to a higher resolution chunk, lickety split.

Generally speaking, though, the simulator found that most adaptive streaming protocols back off quickly in times of congestion. Sort of a digital cacophony of, “After you. No, after you.”

This just scratches the surface of the 34-page paper, and companion presentation, titled “Competitive Analysis of Adaptive Video Streaming Implementations.” For more, contact the SCTE (www.scte.org).

________________________________________
Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com or multichannel.com/blog.

TVOT 2011: EBIF, or ACR?

By: Dec 12 2011 - 4:04pm

NEW YORK - One of the recurring themes at Tracy Swedlow’s twice yearly “TV of Tomorrow” events is the interactive-TV activity around EBIF. The episode held on Dec. 5 was no exception.

This time, though, there was a new wrinkle: EBIF, or ACR (audio content recognition), as the best means to do “companion apps” on second screens, like tablets?

Refresher: EBIF, which stands for Enhanced TV Binary Interchange Format, is a way for multichannel video providers to make those old, installed digital boxes do more stuff. That means building upon the standard EBIF deliverables, like RFIs (requests for information) and voting/polling.

(Aside: If you think this is tired and not happening, heads up: Comcast Spotlight reported 1,400 campaigns and more than 3 billion impressions so far, using EBIF.)

Then there’s the (relatively) newer stuff of displaying caller ID on TV and using companion devices (tablets, smartphones) as remote controls, using EBIF.

And now, multiple panelists said during the packed, daylong event, there’s a new chapter for EBIF: The bridge to the world of IP (Internet protocol).

That means using EBIF as a signaling mechanism (more so than for interactive trigger delivery) to the world of connected devices. The thinking: Put the EBIF user agent, which traditionally sits in the set-top box, into the service provider’s cloud. Then, use HTML5 to render that content on the companion screens.

Voilà: The burgeoning in-home landscape of IP end points (tablets, connected TVs) can participate in the landscape of program-synchronous activities, using EBIF for the critical signaling.

That’s the EBIF side. Then there’s the ACR (also called “automatic content recognition”) side, which is very active with another way to do companion apps.

In a nutshell: You like a show. It has an ACR component. You download that show’s app to your tablet. When the show airs, and the app is on, it listens to the audio feed coming from the TV, and serves up a batch of contextually relevant, advertising-friendly components, on that second screen.

But what if you regularly watch, say, 20 shows? Download the app for each one? Really? Seems like a pain. That brings us back to EBIF, and multichannel-video providers in general, which exist as content aggregators. Watch for tons of activity around this mighty chewy debate as the New Year progresses.

My biggest takeaway from TVOT: When asked if 2012 is the year cable providers work to put their “clickable thing” - the Xfinity icon, to use a Comcast example - on as many consumerpurchased screens as possible, the answer came back as a resounding yes.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com or multichannel.com/blog.

Syndicate content