Google

From OTT to IOT

Just as our focus in the lab is expanding from OTT-only to include gadgets outside the living room, so are many of the majors in the OTT world busily branching out into the Internet of Things (IOT). Let’s have a look.

Apple

For the past few years, the leadup to every Apple announcement always includes plenty of hype about Apple TV – a hardware update to the streaming player is always predicted, but never shows up.

That held true at Apple’s recent World Wide Developers Conference (handily abbreviated “the WWDC”), where there was once again no new TV-related hardware. Instead, a number of new developments on the IOT front:

Along with iOS 8 Apple is releasing HomeKit, software that runs on an iPhone or iPad and controls lights, security cameras, thermostats, garage doors – pretty standard connected home stuff. Apple has a certification program for hardware partners, and is already working with a bunch of companies, including TI, Honeywell, and Marvell.

HomeKit will be controlled by Siri, so you can say something like “Siri, get ready for bed” and it will dim the lights for you. I don’t have much hope for that at this point, but maybe Siri will get a lot better with iOS 8. Speaking as someone who spent several minutes this morning trying in vain to get Siri to understand an address and give me directions, I sure hope so.

Perhaps more exciting: Apple is developing a framework called HealthKit in partnership with the Mayo Clinic and Nike, which pulls in data from 3^rd-party apps to keep tabs on health metrics, over time, and allows clinicians to easily access information from your health apps. We don’t have much information yet, and clearly there are a lot of questions to be answered about security, but it’s exciting to see big companies getting involved in modernizing healthcare (more on that in a future post.)

Samsung

In April, Samsung released the “Gear Fit,” a smartwatch with a pedometer baked in, to lukewarm reviews – apparently Samsung’s custom software leaves quite a bit to be desired.

Then, on May 28, Samsung announced the Simband — a wearable prototype that measures key vital signs like heart rate, heart rate regularity, skin temperature, oxygen levels and carbon dioxide levels – impressive, but not an actual product, yet.

Samsung also introduced SAMI (Samsung Architecture for Multimodal Applications), an open software platform for wearables and sensor technology. We like the potential of an open platform, and the health applications are potentially exciting, but we’re not sure Samsung will be the one to ultimately succeed (our own experiences with their devices could be a post all on their own.)

Google

Back in March, Google announced its Android Wear initiative, extending its Android operating system to cover wearables (early arrivals to the market include smart watches from Motorola and LG; Samsung’s early Gear smartwatches used Android Wear as well). The Android Wear SDK is currently in Developer Preview, to be officially launched later this year.

And in other areas of the home, there are persistent rumors of Google subsidiary Nest (the gorgeous, automated thermostat) buying Dropcam, makers of the $150 WiFi security camera. What, you don’t want Google recording the goings-on in your home? They’re already reading our email, after all…

With all these gadgets and sensors in our homes and on our bodies, security is obviously a big concern — and there are currently some gaping holes that need to be filled. We’ll keep a close eye on what each of these massive companies does (or doesn’t do) to protect our data, in addition to how well the products actually work.

 

 

 

DIALing up the competition

Last week, as I was fiddling around in the lab, I realized just how many of the devices in our lab were quietly using the DIAL protocol.

Example: I opened YouTube on my phone and tapped the “Cast” button, only to see a long list of devices including the TiVo Roamio, Roku 3, Chromecast, and even two generations of Google TV.

DIAL, or Discovery And Launch, is the protocol used for Chromecast, and, increasingly, other devices. It was developed by Netflix and YouTube, with a little help from Sony and Samsung, and has gained support from a number of other big players in both content and hardware.

In a nutshell, DIAL enables apps on 2^nd-screen devices (such as your mobile phone) to discover and send content to 1^st-screen devices (i.e. Chromecast or Roku) on the same network.

How does it work?

From the user’s perspective, you launch an app. Let’s say it’s Netflix. You launch it from your mobile device and choose an output device on the same wireless network.* Let’s say it’s Chromecast. Then, you can start playing content from your mobile device, and it sends a signal to the Chromecast to go and retrieve that content.

This means that the content streams directly from The Cloud to the DIAL-enabled device — not from the mobile device. This frees up your phone for checking email, browsing the web, searching out other titles to play, texting people, and all the other things we do with our phones/tablets.

Most importantly, it means that the second-screen experience won’t drain your battery life and then grind to a halt. Even with the phone powered off, the video plays on.

*Because the devices need to be able to talk to one another over the wireless network, DIAL won’t work on networks with Access Point(AP)/Client isolation – i.e. don’t bother bringing your Chromecast for the hotel room.

Here’s the tech talk of it. DIAL relies on UPnP (Universal Plug n Play), SSDP (Simple Service Discovery Protocol), and HTTP (Hypertext Transfer Protocol).

DIAL consists of two parts: DIAL Service Discovery and DIAL REST (REpresentational State Transfer). In the first part, the DIAL client device (i.e. your phone) discovers DIAL servers (i.e. a Roku, Chromecast, etc.) and obtains access to DIAL REST on those devices. DIAL REST then allows the client device to query, launch, and stop apps on the DIAL server.

DIAL-enabled Devices (and how Chromecast differs)

Several of the devices in our lab already support DIAL, even though some of those devices are a couple years old. And because DIAL is based on UPnP, it may be possible to add DIAL support to other existing boxes through a software update.

Chromecast is a little different in that it uses Google Cast, which is based on DIAL but includes a few extras (of course it does) in the way of playback controls. It also has a more stable YouTube implementation than the other devices (it seems that way to us, anyway).

Chromecast also carries the distinction of using HDMI-CEC (Consumer Electronics Control), for controlling your TV through the HDMI port. All you need to do is find a piece of content on your phone and send it to the Chromecast – it’ll then turn on your TV, switch to the right input, let you change the TV volume, and so on. This is a great feature and we wish more of the devices in the lab had it.

What apps support DIAL?

Currently, only a handful of apps use DIAL – on most devices it’s Netflix and YouTube only. Chromecast currently has a handful of other apps such as HBO Go, Pandora, and Hulu Plus.

More interesting is the DIAL name registry, which shows us which apps may be using DIAL in the future. Not surprisingly, Turner Broadcasting has entries for all or most of its apps, and Comcast is on the list as well. In the OTT space, Aereo, Redbox Instant, and Crackle are all on the registry. And as a heavy Spotify user, I was thrilled to see it listed there too.

However, just because a name is on the DIAL registry doesn’t mean that it will ever end up on Chromecast, or even have a working DIAL implementation – just that the app maker has started tinkering with DIAL in some capacity. As of this writing, the Google Cast SDK is still being finalized and Google is keeping the Chromecast partners to a select few. However, Google promises a busy 2014 on the Chromecast front, with a goal of bringing as many apps to the device as possible. Needless to say, we’ll be watching.

Your 2013 Guide to Streaming Stocking Stuffers

Still looking for some last-minute holiday gifts? You’ve come to the right place. Once again, we’re rounding up our favorite streaming devices in an attempt to make your holiday shopping research a little easier. After all, we follow this stuff all year long!

In keeping with the title, we’re focusing on the stocking stuffers of the streaming world – small, specialized, and relatively inexpensive. Because the price and features differ so much, we’ve left the game consoles and connected Blu-ray players off this list (they won’t fit in a stocking, anyway).

Without further ado, here’s our list (scroll down to the bottom for a side-by-side comparison of the apps that are currently available on each device).

For your tech-savvy friends: Chromecast ($35)    

This little dongle made quite a splash earlier this year, and its low price point and small size make it a fantastic stocking stuffer. Unlike Roku’s streaming stick, Chromecast will work on any TV with an HDMI port. It currently has access to Netflix, Hulu Plus, YouTube, Pandora, and HBO Go, with more compatible apps joining the ranks soon. Chromecast isn’t as user-friendly as the other devices on this list, but it’s a great choice for anyone who enjoys playing with the latest technology.

For loved ones willing to pay for good TV: Apple TV ($99)

Despite no updates to the hardware for quite some time, Apple TV is finally getting more premium content. In past years Apple TV only had Netflix and iTunes, making it a tough one to recommend. But with the addition of Hulu Plus, and payTV apps such as HBO Go, Disney, and ESPN Live, the premium content selection is starting to look a lot more like Roku’s. And about HBO Go – many of the big payTV operators currently block access on Roku but not on AppleTV, so AppleTV is probably the best bet for any Comcast or DirecTV subscribers on your list.

For just about everyone: Roku ($50-$100)

This one won’t surprise anyone, because Roku is consistently at the top of our list in terms of value, content, and ease of use. (Disclaimer: My parents are still using the Roku I got them for Christmas 3 years ago).

There are a few different Roku devices to choose from:

Old TV? Roku LT or Roku 2.

Roku is the only manufacturer on this list that offers component out, making it a great choice to smarten up any dumb analog TV. At around $50, the Roku LT is a perfect gift for your relatives with an ancient TV. While the LT tops out at 720p, the Roku 2 ($80) streams full 1080p video and also includes a headphone jack on the remote – perfect for watching while other people are trying to pretend to work, or sleep.

For your favorite media junkie: Roku 3.

At $99, Roku 3 adds some premium features on top of the standard ones. Its processor is about 5x faster, and it includes a motion-sensing remote control for gaming (and a free copy of Angry Birds, as in years past). Roku 3 also includes USB and Micro SD ports, making it easier to put home movies and photos up on the big screen. But the thing we’re most excited about is support for DIAL (Discovery And Launch), the same protocol used by Chromecast – this makes it possible to control Roku’s Netflix and YouTube channels from a mobile device.

Google TV Android TV …just stick with Chromecast this year

Google retired the “Google TV” name and is now partnering with manufacturers to make devices “with Google services.” New devices from Sony and Hisense have been announced, and Google is also rumored to be building a “Nexus TV” device. We’ve yet to see the user interface, but the details released so far suggest the same old Google TV experience.

And remember, HDMI cables aren’t included with AppleTV and Roku anymore, so you’ll want to throw one in the box as well – no need for anything fancy, this will do.

Rumor Mill Roundup: The Rise of Virtual MSOs?

We’ve been hearing a lot about “virtual MSOs” lately – companies developing payTV subscription plans to be delivered exclusively over the Internet, as an alternative to the traditional payTV infrastructure.

Virtually every tech giant explored, or is rumored to be exploring a virtual MSO model. Microsoft, Google, Apple, Sony, Intel — the list keeps on growing, but we’ve yet to see a content deal nailed down.

The first real development (allegedly) came from Sony: In mid-August, we heard that they inked a preliminary deal with Viacom. Of course, we’ve got no confirmation of this from either party, and Sony hasn’t even officially announced that it’s working on a virtual MSO service. So there’s that.

We’ve also heard a lot of buzz about Intel over the past year. Intel’s service, supposedly called “OnCue,” is due to launch by the end of this year – though we can’t help but notice that the days are getting shorter, and still no announcement of content agreements or possible release dates.

Intel’s service will run on an Intel-powered set-top box, and also boasts a server farm with the ability to record every piece of content for 3 days, storing it in the cloud so viewers can go back and watch their shows without ever setting the DVR.

However, it’s not clear how (or if) this is going to work for the content providers, which typically require that there be a copy in the cloud for each subscriber, as with Cablevision’s remote DVR service. So essentially, Intel would need to record every piece of content for 3 days, multiplied by the number of subscribers – or perhaps work out something more along the lines of a VOD agreement.

Regardless, it’s going to be expensive. Because new virtual MSOs like Intel are just starting out, their content costs will be spread out across fewer subscribers. Intel reportedly offered to pay 75% more for the same content compared with cable operators, and the company remains optimistic despite not having any confirmed deals. In an interview with Barron’s back in June, Intel Media head Erik Huggers said, “We see incredibly serious engagement on the part of every programmer we talk with. I feel very good about our ability to get the right terms to move forward.”

Other wannabe MSOs are trying new approaches to get content, too: Apple is said to be developing a service in which viewers are allowed to skip ads, and Apple pays programmers for each ad skipped.

But despite all the buzz, it seems these companies are still having trouble obtaining the content that they’ll need in order to compete with existing MSOs. Contracts between MSOs and content providers, some of which have clauses preventing content from being licensed to any company that “does not control its own infrastructure,” may have something to do with this.

When (or should I say if?) if happens, the first virtual MSO will be a big deal for a variety of reasons. For me, living in a rural area, it means I might finally have a choice for payTV other than satellite (though what I could really use is a faster internet connection, so here’s hoping they get the adaptive streaming right).

For existing MSOs, it could have an even bigger impact. Assuming that a new virtual MSO is able to lure customers away from existing cable operators, we’ll probably see a big shift towards usage-based pricing for broadband service. Why: Because overall broadband consumption has been growing at a compound annual rate of more than 50% since 2009, and somebody has to pay to make sure capacity stays ahead of demand.

Many operators are already trialing usage-based plans, ostensibly as a cheaper option for light bandwidth users – but this will also give MSOs an opportunity to charge more to heavy bandwidth users (for example, people getting their TV content over the Internet).

It’s also important to note that at this point, the big operators spent the last 60 years building and maintaining (read: paying for) franchise agreements, town by town by town. As such, they tend to stick within their traditional geographic footprints and don’t typically compete with one another. But as more virtual MSOs and operators roll out IPTV services, those territory lines may start to blur – if that happens, you can bet we’ll see the competition heat up overnight.

This is Leslie’s observation, in proofing this blog: “MSO” stands for “Multiple System Operator.” The “system” part of that acronym points to the fact that cable operators spend billions of dollars every year on the physical plant that drops off all that services to subscribing homes. Unless Apple, Google, Intel, Microsoft, Sony and any of the other shaker-uppers own infrastructure, they’re really more accurately a “ZSO” — “Zero Systems Operator.”

Silverlight’s Twilight, and the Dawn of HTML5 Video

Netflix announced last month that it is finally moving towards its goal of ditching the Silverlight plugin, with a little help from Microsoft.

Background: Netflix currently uses Silverlight (a Microsoft product) plugin to deliver streaming video to most web browsers. Netflix announced their intent to move away from Silverlight in favor of HTML5 in a blog post back in April, after Microsoft listed only 8 more years on Silverlight’s lifecycle.

And that wasn’t the only reason: Not all browsers support plugins, particularly on mobile devices. And even on supported devices, some consumers view plugins as a security risk and avoid installing them.

So for the past couple years, Netflix has been involved with three W3C (World Wide Web Consortium) initiatives, collectively known as the “HTML5 Premium Video Extensions.” The general goal is to develop specifications that will make it possible to play premium video directly in a web browser, without the need for consumers to download proprietary plugins such as Silverlight or Flash.

The W3C initiatives involve three key areas: Playback and Adaptive Streaming, Digital Rights Management (DRM), and Encryption.

The Media Source Extensions (MSE) specification, in a nutshell, allows Netflix to download audio and video streams from their Content Delivery Networks (CDNs) and then feed those streams into the HTML5 video tag for playback. This spec also allows Netflix to control a number of things from within their JavaScript code, for example making improvements to their adaptive streaming algorithms and content delivery.

Meanwhile, the Encrypted Media Extensions (EME) initiative covers DRM implementation by providing standardized support for various DRM systems. (Notably, Leslie adds, the DRM-protected HTML5 stream is an area where multichannel video providers, steeped in how to satisfy contractual agreements with the program networks they offer, consistently grumble about monkey wrenches.)

Finally, the Web Cryptography API (WebCrypto) allows Netflix to encrypt and decrypt communication between their servers and JavaScript code. This is necessary to protect user data, and also for subscriber authentication.

One of the main hurdles for Netflix is getting these Premium Video Extensions implemented on all browsers – Firefox, Chrome, Safari, and Internet Explorer. And this is where we’re finally starting to see some progress.

Back in April, with Google’s help, the Premium Video Extensions were implemented for the first time on the Samsung ARM-Based Chromebook. This isn’t a complete implementation; WebCrypto hasn’t yet been implemented in Chrome so a Netflix-developed API handles those operations for now. But once Google’s WebCrypto implementation is complete, testing can begin for Chrome on Windows and OS X.

Notably, and to the “with a little help from Microsoft” in the title of this post, Internet Explorer 11 is the first to implement all three of the Premium Video Extensions. If you’re running the preview of Windows 8.1, you can now watch Netflix using HTML5. If not, or if you prefer Firefox or Safari, you’ve still got some waiting to do. But if the current uptick is any indication, maybe it won’t be long.

Regardless, HTML5 is a hot topic and a big, big deal across the video ecosystem. Netflix’s moves are noteworthy, but not an isolated achievement by any stretch.

May Your Buffer Never Bloat

Guess what: The Internet is getting bloated. “Buffer-bloated,” specifically.

Buffer bloat is a big thing in the lives of the people who work on network protocols and big-iron router stuff. Some even smoosh it into one word: Bufferbloat.

In theory and in practice, buffers are meant to smooth out; to level. They’re short-term storage, when packets – the envelopes of data transmission – move from source to destination.

But when buffers get overrun with bits, they themselves cause delays. The remedy becomes the culprit. That’s buffer bloat.

Buffer bloat is on the rise because of how much video we’re sending and receiving, over the Internet – from the two-minute clip shot on a smartphone, to the Netflix stream, to the live video coming from whichever webcam, to wherever we are.

Every time a packet transits a network, it runs into buffers. The “big iron” routers that run the Internet juggle billions of packets, from thousands of different places, all the time.

Their job is to see where each packet is going, and to find the best route to get it there. As routers route, packets pile up in buffers – more so during heavy volume.

Video is heavy to begin with, relative to a phone call or a web page request. And think about how much more video you’re doing on your phones and tablets than you did two years ago.

It’s getting to be a problem because the usual elixir – “throw more bandwidth at it!” – isn’t enough. At issue is a tenet of how stuff moves over the Internet, using TCP/IP (Transmission Control Protocol over Internet Protocol), which requires an acknowledgement on every packet sent. (In the lingo, they go by “acks.”)

Turns out that round trip time (“RTT”) impacts network performance as much or more so than available bandwidth. Latency trumps capacity.

Help is on the way, of course, under a general mantle of “active queue management.”

One remedy, developed by Google, is a protocol called “SPDY” (pronounced as “speedy” and not an acronym for anything.) It aims to improve on HTTP (Hypertext Transport Protocol) by using fewer TCP connections.

Ever get a “connection timeout” when loading a web page? (The maximum number of active connections in HTTP is six. Who knew?) SPDY fixes that, by multiplexing (smooshing) the next connection, onto an existing connection. Also in SPDY: compression and prioritization mechanisms. Some browsers (Chrome, Firefox, Opera) already use it.

Another goes by “CoDel,” for “controlled delay.” People pronounce it as a word: “Coddle.” Its inventors, Kathleen Nichols (girl power!) and Van Jacobson, describe it as a “no knobs” way of keeping delays low, even during big traffic bursts. They published a chewy paper about it called “Controlling Queue Delay,” available here: http://bit.ly/LDPNUp.

Discussing the paper with ARS Technica writer Iljitsch Van Beijnum, last May, Jacobson dropped this tasty tidbit: “Things would probably go fastest if we had some interested party who would apply it, for example in the cable data edge network.”

Sounds like a gauntlet thrown! Either that, or, maybe the Internet needs a Fitbit.

This column originally appeared in the Platforms section of Multichannel News.