Brightcove Blog - Jeff Whatcott's Station

HTML5 and the Rise of Hybrid Apps

Jeff Whatcott — Wed, 30 Nov 2011 11:00:07 +0000

Today we announced the general commercial availability of App Cloud, our second major product. You can learn all about it here. This post is the back story for why we built it.

Let’s begin with a few somewhat controversial assertions:

Native apps are not a fad. They are just getting started. That is a good thing.
HTML5 is fundamentally transforming how apps are created, though not in the way that the zealots predict. That is also a good thing.
Apps and HTML5 are the future of the digital universe. That is awesome.
Apps are a journey, not a destination, and a life cycle mindset is required.

A Quick Quiz

To explore why these assertions are true, here’s a quick quiz. What do all of the apps below have in common?

The answer is that these are all hybrid apps developed with cross-platform HTML5 wrapped in a native container. They were not built from scratch in platform-specific languages like Objective-C or Java. Pure HTML5 web apps cannot appear in app markets like the iTunes App Store or Google Android Market, but these apps can because they have that native wrapper. This wrapper also gives these apps access to native capabilities like the camera, microphone, contact list, or notification system that are off limits to the browser.

All The Cool Kids are Doing It

Facebook created a 100% native app for the iPhone back in 2007, but did not release an iPad version until October 2011. The iPad version coincided with the re-release of the iPhone version and a new Android version, all of which were based on this new hybrid app approach where the bulk of the app is HTML5.

So why did they go this route? David Fetterman, Mobile Engineering Manager at Facebook, summed it up in his speech at F8 last month.

“All of our developers are good at HTML. Only a few of them are really good at Objective-C and Android. We are able to make our web developers the same as our client-side developers in some respects.”

It is instructive that Facebook, a company with virtually unlimited resources, is strategically shifting the way that they build apps because of a shortage of skilled native developers. If Facebook can’t find enough Objective-C and Java developers, why would any company with smaller resources think it can do so?

Netflix has been on this same path, having made their shift to HTML5 for creating native app UI well over a year ago. They have shipped HTML5-based hybrid apps across many mobile device platforms, smart TVs, gaming devices, and other consumer electronics platforms. They have also been evangelizing this new approach with real conviction, giving speeches and posting detailed documents that describe the theory and implementation of their approach and the problems it solves.

Microsoft is also adopting the hybrid app approach. They recently shipped new versions of their Bing for Mobile app that is built with HTML5 in a native container. They also managed to create intense anxiety among their developer community when they mentioned that Windows 8 will support creation of native apps in HTML5. It’s unclear how this HTML5 goodness (err, badness if you are a nervous XAML ninja) will appear in the Windows Phone environment, but it seems likely that it will.

Follow the Money

A couple of recent acquisitions illustrate the strategic importance of the hybrid app approach. Nothing shows commitment like an open checkbook.

Our friends at Adobe recently bought Nitobi, creators of PhoneGap. Adobe is doing a pivot away from Flash in the mobile browser to refit the company for the new app-centric world. PhoneGap was an early-mover in hybrid apps, allowing web developers to combine their HTML5 code with native containers. Adobe is probably hoping that ownership of PhoneGap will solidify its natural position as dominant tools vendor in the decade ahead.

Adobe didn’t need to do an acquisition to equip itself to build tools for plain vanilla HTML5 websites in the browser. They are fully capable of doing that on their own. But hybrid web apps require that native container piece that connects apps to the operating system capabilities. PhoneGap fills that void and fuses HTML5 to the native app economy. By acquiring Nitobi, Adobe just bought itself some relevance insurance for the new era of digital media, and got a good deal on it.

Facebook’s recent talent acquisition of Strobe is further proof of the importance of this new approach. Strobe was the company formed to build a business around Charles Jolley’s Sproutcore, an open source JavaScript framework for creating touch web apps that could be combined with a native container to make a hybrid app. Before the acquisition, Strobe had started building out commercial cloud services surrounding the free framework.

Now that they are part of Facebook, the fate of the core technology and those cloud services is in limbo. But one thing is crystal clear: Facebook is putting Charles and team to work on its app strategy and that strategy is all about hybrid app experiences.

A Funny Thing Happened on the Way to the App Store

The crazy thing about this new hybrid app approach is that the app economy wasn’t supposed to be this way. Apple’s original vision for apps drew a bright line between web apps and native apps, apparently under the belief that native code was going to yield the best end user experiences and monetization opportunities.

It is important to remember that when the original iPhone launched, there was no iTunes App Store and bookmarked web sites were the only way to extend the device. Also remember that this limited, browser-centric approach widely was dismissed as insufficient and the Apple developer community was extremely vocal in demanding tools for building native apps.

In March of 2008, fourteen months after the original iPhone hit the market, Apple introduced their app SDK and the iTunes App Store. The rest is history.

Given its incredible success and momentum, the native app concept is not going away anytime soon. However, as the native app concept has aged, a few stress fractures are starting to appear.

Unfortunately for everyone, platform-specific native app development has turned out to be relatively expensive. You can see this in the relative pay scales of native app developers who are paid an average of 28% more than web developers according to searches of job postings from technology job site Indeed.com. This is part of the pain that is causing Facebook to get excited about hybrid apps.

Chart Note: The bar titles are Indeed.com search syntax, so "HTML -Cocoa" means "mentions HTML but does not mention Cocoa."

Native app developers not only cost more and are harder to find, but they are highly specialized. You can’t take a team of skilled iOS developers rolling off an iPad app project and immediately redeploy them on an upcoming Android project. The skills are platform-specific and the workflow and pacing doesn't look at all like web development.

This is a big problem because smart phone, tablet, and consumer electronics platforms are proliferating quickly. Currently relevant app platforms include iOS, Android, Blackberry, Windows Phone, Nokia QT, Samsung Smart TV, LG Smart TV, Panasonic Viera Connect, and others. Platforms may come and go, but the one platform to rule them all is unlikely to emerge. In mobile, and consumer electronics in general, fragmentation is forever.

Imagine if you had to fund totally separate development teams for IE, Chrome, and Firefox. Crazy, right? Unfortunately, that’s exactly what the current landscape looks like to the digital media execs and CMOs who pay the bills for app creation. They are compelled to reach the largest audience possible, but to do that they have to support many app platforms, not just one. They are staring down a ridiculously expensive backlog of projects spread across a menagerie of platforms, but may only be able to afford to reach a single platform. Something has to give.

The Force is Strong With This One

Many have looked at this situation and said, “Wait. I’ve seen this movie before! The open web will save the day!” They think that native apps are a passing fad, a sort of bad trip flashback to the days of encyclopedias on CD-ROMs, Compuserve, and Microsoft Blackbird. They zealously profess the “The End of Native” and nostalgically hope for a happy browser renaissance where pure HTML5 apps obliterate the native app Death Star.

You can forgive them for believing this. It’s not a bad story. We have seen movies like this before. And HTML5 is awesome. Check out this chart from Indeed.com which shows appearances of HTML5 in technology job listings in the U.S.

So clearly, the Force is strong with this HTML5 thing. By definition, HTML5 is the future of the web, and it would be crazy to bet against it. But that doesn’t necessarily mean that native apps must fail in order for HTML5 to succeed. Nor does it mean that HTML5 can or should do everything.

An Inconvenient Stalemate

HTML5 is eloquently described as a pain machine for developers who force it into areas like gaming, where the technology is still immature. And even when it is applied to more modest content consumption apps, HTML5 on its own simply cannot do all the things that native apps can do. Here is my current scorecard.

A somewhat ridiculous Native App versus Open Web debate has been raging across the web for a few years now. A sample of relatively recent perspectives on this are here and here. As I’ve previously written, I think it is false choice because a) consumers are spending equal time in both the browser and native apps and b) mobile web experiences and native apps are best-suited to very different and yet complementary stages of a consumer relationship: mobile web for discovery and awareness and native apps for loyalty and nurture. It’s not either/or. It’s both/and. Peace wins.

It’s also important to remember that regardless of what the world wishes would happen, the platform owners like Apple, Google, Microsoft, Nokia, Samsung, and others are firmly in control. They currently limit what browser-hosted HTML5 web apps can do for both technical reasons (mostly security-related) and for business reasons.

Over time, the technical/security reasons may be addressed by new standards, though it will take years for these changes to grind through the W3C bureaucracy. And then it will take even longer for the new standards to find their way into the browser in your pocket or living room.

Unfortunately, the business reasons restraining HTML5 are structural and purposeful. In today’s world, shareholders require platform owners to cultivate vibrant and profitable native app economies. It’s foolish to expect the incumbents to act against their own self-interest and let their platforms be fully commoditized by the open web. That’s a sucker’s bet. The platform owners are allowing hybrid apps into their ecosystems because they can still control them. That is unlikely to change.

What About Performance?

There is a meme out there in some technical circles that says that apps based on an HTML5 WebView wrapped in a native container are always going to suffer poorer performance than a pure native app. I don’t buy it. The fact that the largest companies in the industry are using the hybrid app approach should be enough to put this to bed. Sure, there are going to be specific scenarios and types of apps where HTML5 is not going to work well (remember the pain machine), but for a very wide variety of content-centric app experiences, well-optimized HTML5, augmented by native APIs, is performing great.

We are the 99%

It’s clear that the industry giants like Facebook, LinkedIn, Microsoft, and Netflix have shifted to the new hybrid app approach to building apps. But these companies are the 1% with massive resources who live at the bleeding edge and can hack their own way to success. What about the 99% of organizations that want and need apps on all kinds of platforms, but have no idea how to get there?

At this point, many of the 99% have dabbled in apps by creating a 1.0 version for a single device type (e.g. iPhone) on a single platform (e.g. iOS). The customers I speak with are wondering how they are going to take the next step. They are feeling pressure to get their apps on many new platforms because that is where consumers’ attention is shifting. Ditto for advertising dollars. Organizations who are serious about their digital strategy need to be there. The question is how.

The hybrid app approach is absolutely part of the solution. It applies the formidable efficiency and agility of web development to the app problem, and is yielding promising results. But there is more to apps than just a pretty face derived from HTML5.

Apps Are a Journey, Not a Destination

One of the additional complicating factors with apps is that many organizations seem to think about them as discrete, experimental, one-off development projects, often outsourced to contractors with specialized skills. They focus on the UI and put relatively little thought into the back-end administration and content optimization. The operational workflow for non-technical business users and content producers is ill-conceived. They fail to plan ahead for analytics and monetization. They do little or no usability testing or even distributed real-world beta testing. Maintenance and release management and end-of-life strategy go unmanaged.

The problem is that this approach is short-sighted and unlikely to bring success. It is high time that we start treating apps as valuable digital properties that deserve careful planning and investment. Successful apps are not destinations, they are journeys through a life cycle that touches many different roles in an organization, not just developers. Even disposable campaign-specific apps need to be actively managed if they are to be effective during their short lives.

Designers and architects of valuable app properties need think about creating branded templates and scaffolding that make it easy to produce new apps quickly. Websites have that - so why would we tolerate less for apps? App operations staff need to optimize back end content sources to improve performance over high latency mobile networks, just as websites have all kinds of data optimization and caching schemes.

App business owners and ad ops pros need to plan for analytics, reporting, and ad targeting and delivery, just like they do for websites. Developers need to make continuous testing part of their process. And whole team needs to establish efficient methods of rolling out new versions, tweaking content presentation, and tuning ad campaigns.

Putting the Web Team Back in Charge

Apps clearly need to enter the mainstream, proactively-managed, realm in order to make them more sustainable and efficient. But you can hardly blame early adopters of apps for taking shortcuts. When every app project is based on a bleeding edge technology on an unfamiliar platform, compromises have to be made. These projects are often outsourced beyond the domain of the traditional web team. The normal rules and processes and accountability often go out the window.

As hybrid apps become the new de facto standard, app ownership is moving back into the realm of the the web team. The designers, information architects, producers, architects, front end developers, back end developers, DBAs, sysadmins, and project managers who build and operate traditional website are squarely back in the picture. All of their skills and processes are supremely relevant in a hybrid app world.

What We’re Doing About It

At Brightcove, we’ve been tracking all of the trends discussed in this post for a few years. And we’ve been doing something about it. We’ve been re-tooling our Video Cloud product to make sure that video can be a first class citizen on all the new platforms and devices, and we’ve been doing it both in HTML5 and native environments including connected TVs. Today we’re announcing the general commercial availability of Brightcove App Cloud, a new content app platform that is designed to support the entire life cycle of content-centric hybrid apps. It's our second major product and continuation of our mission to publish and distribute the world's professional digital media.

App Cloud combines native containers with HTML5 to make building custom apps a fast and natural process for web developers. It allows non-technical people to visually create apps without writing any code, and modify their apps even after they have been published and without requiring consumers to do an upgrade. Once an app is published, App Cloud continuously manages and mobile-optimizes content feeds and images to accelerate the end user experience. And it also includes built-in real-time analytics and monetization tools. It’s designed to be an end-to-end app platform that puts the spirit of the web in a native app body.

The AMC Mobile app that appeared at the top of this post is running on App Cloud and is available today for iPhones, Android smart phones, and Android tablets. So is the US Department of State - State Reader iPhone app. We hope you like these apps and others on the way.

For more info on App Cloud, check out the video below and get your own free development account by registering here.

Dumb Question: To App or Not to App?

Jeff Whatcott — Mon, 14 Feb 2011 20:01:36 +0000

One of the perennial questions discussed in the mobile world over the past two years has been whether mobile apps or mobile web sites will "win" in the end. The media likes to pitch it as a winner-take-all situation where five years from now consumers will predominantly be browsing on devices or using apps, but not both. I've also heard partisan platform vendors pushing this idea.

Well, according to the latest data from Comscore's 2010 Mobile Year in Review (free download with registration), the "app or web" thing increasingly looks like a dumb question. Consumers are clearly doing both.

Despite the unfortunate typo in the title, the data is pretty clear. As Comscore summarizes in the report:

"the two activities are not mutually exclusive. In fact, most users that utilize one method use the other. In the U.S., 82 percent of app users also use their browser, while 78 percent of browser users also utilize apps. Only 6 percent of app users don’t utilize their browser, while 8 percent of browser users don’t utilize apps. In Europe, 71 percent of mobile browser users also use apps, while 73 percent of app users also use their browser. Just 7 percent of app users in Europe don’t browser, while 8 percent of browser users don’t utilize apps. Instead of the browser vs. app question being an ‘either or’ proposition, the mobile web audience has quickly come to expect and utilize both browsing and apps"

Given that consumers are clearly consuming content through both apps and browsers, most brands and media companies are going to want to do both as well. But that doesn't mean that your mobile web site and mobile apps have the same goals or need to be exactly the same. In my view, mobile web sites are best suited for the awareness stage of a consumer relationship where discoverability and low commitment are essential. Once you have established awareness and some level of favorable brand image, you can ask consumers to install your app to keep the relationship going. So apps are more about ongoing engagement and loyalty.

We've had a ton of interest in our App SDKs for iOS and Android. But we have had just as much if not more interest in mobile-enabling existing web sites using HTML5 and mobile-optimized templates. And mobile processor friendly technologies like the new Flash StageVideo can make for an even more enjoyable mobile web experience on the growing set of Flash-capable devices. In content-centric marketing and media, it's all about reach and engagement, and that means both mobile apps AND mobile browsers.

Newspapers Don't Do Long Form

Jeff Whatcott — Wed, 22 Dec 2010 18:57:37 +0000

I was just reading a post by Matthew over at Gigaom that is a summary of our Online Video & the Media Industry Quarterly Research Report for the third quarter of 2010. One of Matthew's conclusion struck me as slightly off target (italics added):

The one area in which broadcasters led the pack, however, is the average number of minutes watched, where broadcasters as a group were far ahead of newspapers. This suggests that while newspapers are uploading more video, readers (or viewers) aren’t finding that content as engaging as they do videos that come from broadcasters. That’s probably not surprising, considering many newspapers are still grappling with how to produce video, something that doesn’t come naturally to print publications, while most broadcasters have learned how to create video content that grabs viewers.

While this be true, is is more likely that newspapers are uploading short features whereas broadcasters are uploading TV shows and movies. No newspapers I am aware of are investing to create original long form entertainment in competition with Hollywood. Their business is about snackable short form content that's always fresh and relevant. A newspaper site viewer would have to watch over 20 two minute videos back to back to spend the equivalent of a single TV show. That's not the model that newspapers are shooting for.

I think Matthew is right that newspapers may be behind the Hollywood crew in figuring out how to create compelling content. But they are clearly starting to figure it out, as evidenced by the growth highlighted in our report. In this regard, they are not unlike all the organizations we're talking to across many industries. For most of these organizations, short form is the right place to start.

Comscore Discovers Growth in European Mobile Users

Jeff Whatcott — Wed, 29 Sep 2010 18:45:21 +0000

Comscore just released a new report on the trends in mobile video consumption in Europe, and it's really interesting and promising. You should download the full report here, but here are few of the highlights:

Video consumption on mobile devices is up 66% in the past year
In Spain, video consumption is up 90% year on year
The mobile audience size in the top five European countries is a substantial 12.2 million
Over two thirds of mobile video consumption happens on smart phones

These are great numbers that correlate stongly with what I have been hearing from our European customers over the past year. I was surprised to hear from some of our large customers that mobile is growing to become a significant portion of their total audience. Everyone I talk to is excited about the growth potential and wants their content to be there. Mary Meeker of Morgan Stanley is predicting that mobile Internet will exceed the desktop Internet in the next five years, and these Comscore numbers suggest we may be on our way there.

Starting with the launch of our App SDK for iOS last November, we've had incredible interest in all things mobile. We've responded by reving the SDK for iOS to include iPad support, adding an App SDK for Android, and rolling out Smart Player support for HTML5 video experiences. As I noted in my post last March, it's still early days, and we're working hard to provide parity between the richness of video experiences on the desktop versus what we can provide on mobile devices. But we are chipping away at it, and it is great to see the progress.

WebM and The New Online Video Landscape

Jeff Whatcott — Wed, 19 May 2010 17:15:00 +0000

Google's release of the new open source, royalty-free WebM video format and VP8 codec is big news today. Brightcove is enthusiastically joining Google, Mozilla, Opera, Adobe, and others in pledging support for WebM. Our COO and CTO are on stage out at Google I/O to tell the crowd what we're up to. As you will see below, we believe that WebM is changing the landscape of online video in important ways that you'll want to understand.

What it Means for Brightcove Customers

Before we get into the broader industry impact, I want to clarify what this means for Brightcove customers. In the future (we're still working on a specific date), customers will be able to upload video source files to us and we will transcode them into multiple rendition sets in both the H.264 and WebM formats. These rendition sets will be available for use in both Flash and HTML5 video experiences, and we'll help deliver the best possible experience given the capabilities of the viewer. A screencam demo of what this could look like is included below.

Industry Impact

There are three fundamental approaches to delivering online video experiences today: Adobe Flash, HTML5, and native mobile apps. Flash can display video encoded in multiple formats (primarily On2 VP6 and H.264) and is available on 99% of all desktops and will soon be available on nearly all smartphone platforms except those created by Apple. HTML5 can also display video in multiple formats (primarily Ogg Theora and H.264) and although it's available on a growing but minority percentage of desktop Web browsers today, it is is pretty much the only way to deliver video in a browser on Apple devices like the iPhone and iPad. Mobile apps are native software applications designed to deliver a video experience on smart phone platforms like Apple iPhone OS, Android, RIM Blackberry, Symbian, Palm, etc.

Today, most Flash video experiences, including those delivered by Brightcove on behalf of our customers, utilize the H.264 format. H.264 also dominates today's HTML5 and mobile app video experiences, primarily because it is the only option on the hot iPhone and iPad devices. H.264 is based on technology contributed by an intellectual property consortium of vendors called MPEG-LA, and it provides outstanding quality. The only problem with H.264 is that there have been concerns about potentially large royalty payments associated with its online use. These royalty concerns have been pushed out to at least 2016. However, the possibility of substantial royalty liabilities continues to hang like a cloud over the H.264 standard and prevents browsers like Mozilla and Opera from adopting it.

Until WebM, there was no alternative to H.264 that was free and of sufficient quality to become pervasive across Flash, HTML5, and mobile app video experiences. Ogg Theora is free, but suffers from quality and efficiency concerns that make it a weak contender. WebM incorporates the well-regarded VP8 codec that Google acquired with its On2 Technologies deal last year. And now that the technology is open sourced under a royalty free Mozilla license, WebM has become "both free and good" format that has been missing from the market.

One of the primary factors that makes WebM so compelling is Adobe's commitment to support it in future versions of Flash. Adobe has an umatched ability to rapidly install new Flash versions on the vast majority of the world's desktops, and soon most non-Apple smartphones. New versions of Flash Player take about 18 months to be installed on 90% of all desktops. Having WebM in Flash will dramatically accelerate adoption by providing a huge available market of WebM-capable machines.

WebM will also change the HTML5 video landscape as leading browsers build in support for it. The lack of a strong free video format with broad browser support has been holding back HTML5 adoption. Now, Chrome, Firefox, and Opera are all slated to support HTML5 video with WebM. Microsoft appears to have left the door ever so slightly open to supporting another video format in Internet Explorer as long as the format is secure and legally sound. Given their ownership of 50% of all desktop web browsers, Microsoft is in a pivotal role to drive WebM adoption. I am hopeful that they will find a way to support it. UPDATE: Microsoft has said that they will allow users to separately install the VP8 codec in IE, but have stopped short of shipping it with the browser.

Browser version upgrades take longer that one might expect because old browsers die slowly. So it may take a while for desktop browser experiences built on HTML5 and WebM to become mainstream. However, developer enthusiasm for HTML5 is there, and now that the technology stack is ready, we'll see more and more HTML5 experiences on the Web.

So what about WebM on devices? Because of battery life concerns, video on devices is all about chip level acceleration. While I don't have any details to share, the word I'm hearing is that chip manufacturers are very interested in WebM for the same "free and good" reasons that everyone else is. A lot of manufacturers already have H.264 licenses and have embedded the technology into a wide array of devices. But over time, we are likely to see a new crop of WebM capable hardware that will give H.264 some healthy competition. A smartphone or connected TV running both in-browser and native app video experiences with WebM could be in your future.

One key remaining question is how Apple will approach WebM. Apple is an MPEG-LA member, and has deeply adopted H.264 across their tools, operating systems, and hardware. Apple is showing huge growth, particularly in mobile devices, and has more than enough brand and market power to strategically steer technology adoption to suit their business goals. I hope they will welcome WebM, but even if they don't, the format is likely to see broad adoption elsewhere.

Based on what we know today, it seems that WebM is well-positioned to become a strong alternative to H.264 across Flash, HTML5, and native app video experiences on both desktops and devices. That's not to say H.264 is going away. Apple and other companies have a lot invested in H.264, it works extremely well, and the royalty concerns are not universal held. We're probably going to have two strong standards in the market.

It will take a few years for WebM to reach its potential. Upgrading the world's Flash Player, browser, and hardware infrastructure will not happen overnight. There could be twists and turns as the formats duel for market share, patent rights, and developer hearts and minds. Even if one format ends up with a minority share, it may be big enough to command attention from publishers. For the foreseeable future, customers will need to rely on both H.264 and WebM formats to reach the maximum possible audience with the best possible experience.

This multi-format world will create headaches for customers who take the DIY approach to online video. These customers will need to manually generate and manage multiple formats for every asset, develop and maintain multiple playback experiences, not to mention figuring out how to do advertising and analytics across the different technology. We've already seen the first wave of publisher anxiety surrounding the introduction of the Flash-less iPad, and the landscape will continue to diversify as WebM becomes a substantial player.

The good news is that Brightcove can help. Our customers rely on us to help them avoid cost and complexity, and we're stepping up to the challenge. We're building a future where the Brightcove Experience is available across HTML5, Flash, and mobile apps with support for both H.264 and WebM formats. We hope to help customers avoid risky either/or bets and allow them to focus on their business strategy for video without having to worry about the technology. Hopefully, the end result will be video that just works. That is the way it should be.

Solving the Online Video Monetization Puzzle

Jeff Whatcott — Wed, 12 May 2010 05:04:00 +0000

The image of a jigsaw puzzle kept coming to mind as I watched last week's Brightcove Video Monetization Summit. The good news is that the picture is starting to take shape. We recently published some new research findings with TubeMogul showing that the number of video views is increasing dramatically across the media industry, social networks and search engines are deepening engagement and growing audiences, and the majority of publishers in our study plan to launch ad-supported mobile video within the next 6-12 months.

While it is clear that online video represents an exciting and fast-growing opportunity for media companies, monetization remains a tricky business, especially when you consider how fragmented the media and device landscape has become.

That’s why I’m very excited to announce that Brightcove will be unveiling a number of new innovations at Streaming Media East today that will help media companies ramp their monetization efforts, accelerate time to market, and provide advertising-supported distribution opportunities across every screen.

HTML5 Video Advertising

Brightcove and FreeWheel have teamed up to provide a new HTML5 video advertising solution. Built on Brightcove’s native support for HTML5 video, media publishers will now be able to take advantage of FreeWheel’s Monetization Rights Management (MRM) product to deliver advertising-supported video to HTML5-compatible devices, including the Apple iPad, iPhone and iPod Touch.

Expanded Support for VAST 2.0 and VPAID

We also unveiled expanded support for the VAST 2.0 and VPAID IAB standards, which Brightcove helped to develop. Standards were one of the themes that we heard over and over again at the Summit. In the words of Rob Davis of Ogilvy, "the lack of standards for online video advertising is a drag."

These standards give advertisers and publishers uniform ways of creating, trafficking, and tracking campaigns across properties and ad serving technologies, as well across Flash and HTML5 video experiences. This lowers the costs of campaigns, improves ROI, and encourages advertisers to invest more.

We’ve gone deep in natively supporting VAST and VPAID to make sure our customers can reap the full benefits of these emerging standards, including tracking third-party re-directs, enabling trafficked and synchronized HTML/JPG ads outside of the player, tracking for major ad events including play, midpoint, complete, pause, mute, unmute, full screen, first and third quartiles, creativeView, as well as initial support for VPAID non-linear ads (i.e. overlays). This summer, we’ll also add support for VPAID linear ads and advanced VAST features and additional tracking events.

The innovations announced today build on the most robust and sophisticated suite of online video monetization capabilities in the market, which includes a visual cue point editor for targeting ad insertions in long-form content, flexible advertising APIs that have spawned dozens of integrations with leading monetization partners, and mobile SDKs with hooks to connect mobile video applications to advertising networks and servers.

Addressing the Rest of the Puzzle

These product innovations and ongoing investments provide important pieces to a broader monetization puzzle, which involves questions of strategy, content and audience.

Strategy Issues

I think we really have to start by answering the question "How does online video connect to my overall business objectives?" In a media business context, the business objectives may include some or all of the following:

General marketing awareness creation and brand building
Direct monetization through pay-per-view
Improved SEO
Increased time on site
In-stream and on page advertising revenue

The objectives will be different for a national MVPD, television programmer, an independent film producer, a financial newspaper with both online and print operations, a gossip magazine, or a group blog on emerging technology. The relative priority of each of the applicable objectives helps bring the right strategy into focus and makes execution of the strategy much more straightforward.

Content Issues

As Chris Johnston and Erica Crossen pointed out in their presentation at the Monetization Summit, media companies do best when following a basic formula:

More Content + More Places = More Audience
More Audience + Right Experience = More Money

The simplicity of the formula is helpful, but underneath the simplicity lie some important strategy questions. When we say "More Content" it begs questions such as "How much content should I produce?" or "What kind of content is my top priority/second priority/non-priority?" When we say "More Places" it begs important distribution strategy questions like "What places?" and "How many places is enough?"

To answer these questions, you have to align your content strategy with your business strategy and your resources. If your primary objective is pay-per-view, you better have a substantial library of premium long-form content. Clips of cats on couches will not cut it. If your primary objective is in-stream and on-page advertising revenue, you're going to need a significant library of compelling content that is brand-safe and attracts a sought after demographic. News footage of IED explosions will not attract advertisers, but it can be very effective for improving SEO, and time on site if you are thoughtful about how you embed it.

Another content issue that I heard about at the Summit is the way that publishers handle recommended / related videos. Too few publications are optimizing their in-player and on-page experiences to keep viewers engaged. Our friends at Taboola can help with this.

Audience Issues

If you produce compelling and thematically coherent content on a consistent basis, you will gradually build a brand and an audience. However, having an audience does not do you much good unless you can package and sell it in a way that is compelling to advertisers. The work that Quantcast and others are doing in this area of audience measurement, segmentation, and targeting is incredibly promising. Publishers are starting to enjoy data and targeting capabilities on their online audience that are only rarely available in the offline world. Brightcove customers can integrate their account with Quantcast so that video-specific audience data is included in the overall data set, making it possible to target in-stream advertising with previously impossible precision.

There was a lot of buzz about all of these topics at our Summit, and we expect that interest to continue to build this year. We received great positive feedback from publishers about our implementation of the standards and our ongoing commitment to video monetization, and our team is now even more fired up to drive forward until the work is done. Brightcove has always been on the vanguard of advertising standards and innovation, and we intend to keep it that way.

April Showers Bring Encoding Quality, Player Customization, and Faster Uploads

Jeff Whatcott — Wed, 28 Apr 2010 14:00:00 +0000

Interest in online video continues to accelerate across many industries and throughout the world. Customers are getting more numerous, but they are also getting more sophisticated and demanding. We stay ahead of this wave of requirements by implementing agile development operating on 30 day iterations that resulted in a shipping release every month.

I'm going to focus this post on just a few of our recent innovations in the areas of quality and customization. We've just rolled out a new adaptive encoding engine, new player customization technology, and geo-optimized uploading. These are features that may not be as high profile as TV Everywhere, Android, HTML5, and Facebook Open Graph, but they help our customers succeed in fundamental ways, and we're really excited about them. Here are the details.

Adaptive Encoding Engine

A few months ago we added a brand-new scrum team charged with rearchitecting and completely overhauling our encoding infrastructure. We challenged the team to deliver a new encoding farm that was faster, more efficient, more functional, and that delivered just plain better quality than what we have been using up to this point. They nailed it.

In addition to the fundamentally better quality, the new encoding engine offers advanced features such as:

2-Pass Encoding that delivers the optimal resolution and clarity for every hit delivered over the wire
Non-Square (a.k.a. Anamorphic) Pixel Correction that detects video that was shot in widescreen format and automatically corrects it so that it doesn't come out of the transcoding system looking "squished"
Source Frame Rate Detection that improves quality by encoding video at the same frame rate as the original source, which can also help with audio synchronization issues common to many formats
Mobile Video Angle of Rotation Correction that detects a video that was shot with iPhones and other mobile video cameras that capture video in 90°, 180°, and 270° rotation angles so that the video comes through the transcoding system properly oriented
10X Faster Transcoding that gets content live faster than our old system and does it with better quality than ever

So does all this advanced technology make a difference in real life? Yes! Below you can see a video encoded from a 1080 HD source using the default settings and delivered using our standard multi-bitrate streaming with the default six renditions ranging from 261Kbps to 1.5Mbps. If you wanted to deliver even higher quality, you could add another couple of renditions on the high end through custom encoding settings, but I wanted to show the default experience here to offer a sense of what the average customer will see without any extra effort. The visual clarity you see will vary based on your available bandwidth and CPU utilization and the rendition selected, but hopefully you will like what you see.

You may be wondering how this new engine compares to the alternative online video platforms on the market today. Let me begin by pointing out that encoding is an art, and that hand encoding individual files is always going to offer better quality than default. On any given day on any given online video platform, you may see outstanding quality, so it is very tricky to make blanket statements about quality. It is very hard to compare encoding quality across different content. We haven't done a comprehensive comparison of all online video platforms, but we did do some spot checking using the same content encoded using default settings.

Below you will find two video players that are showing a single 700Kbps rendition of the same content encoded with the new Brightcove adaptive encoding engine and the encoding engine of another online video platform that appeared in last year's Forrester Wave comparison of online video platforms. We uploaded the file to both systems and encoded it using the default encoding settings. Then we extracted the 700Kbps renditions from each account, uploaded them to another Brightcove account, and associated them with the Brightcove player you see below. We've done our best to remove all other variables from the equation so the only difference is the actual quality of the encoding of each system. Needless to say, we're very happy with the results.

Brightcove Encoded File

Alternative Online Video Platform Encoded File

Custom Player Themes

One of the most powerful parts of our platform is Brightcove Experience Markup Language or BEML. It's an XML language that makes it incredibly easy to change the appearance and functionality of the Brightcove player. BEML solves the problems of customers who want to create customized player experiences but do not have Actionscript programming skills. BEML is a language that any traditional web developer can pick up easily, but it is incredibly powerful, and no other online video platform offers anything like it.

Since introducing BEML in 2008 we've been gathering feedback for how to make it even better. One thing we've heard is that there can be a somewhat tricky handoff between interactive designers who live in tools like Photoshop and Flash and developers who typically pick up the task of BEML development. We challenged our team to come up with a way that an interactive designer who knows some basic Flash, but who does not know Actionscript, can create custom player themes using BEML. The team delivered, and we're calling it Custom Player Themes.

A complete tutorial on how to take advantage of Custom Player Themes can be found here. To give you a taste of what's possible, a designer who knows a little Flash can independently create and apply themes like the one shown below. The first player is the default look and feel. The second is the themed player.

Default Chromeless Player

Chromeless Player with Custom Player Theme

This is pretty cool stuff. It really opens up the creative possibilities of BEML to a wider group of people, making it easier than ever to get that custom, branded look and feel that makes your site stand out. This capability is now available to all Brightcove Professional and Enterprise customers, and we can't wait to see the next wave of stylin' players from all around the world.

Geo-Optimized Uploads

There is also one more sleeper feature that is just too cool to overlook. It's called Geo-Optimized Uploads, and it solves the problem of slower uploads from regions that are far away from our primary data center in Massachusetts. We now detect the origin of every user that is uploading content to our platform, and we route their upload to the remote ingestion farm in the data center that is closest to the customer. This change has already accelerated upload times by an average of 65%. That's material.

We're really excited about these recent innovations in our platform. The net effect is that content will get live faster, look better than ever, and create a favorable brand impression that lasts.

Facebook and The Emergence of the Socially-Validated Web

Jeff Whatcott — Wed, 21 Apr 2010 19:30:00 +0000

Today Facebook rolled out the Open Graph and their new set of Social Plugins at the f8 conference in San Francisco. As you will see later on on in this post, we believe this is a massively important innovation for the Web and we’re happy to be one of the launch partners that Facebook has been working with.

We have created a way for Brightcove online video platform customers to quickly embed the Facebook Social Plug-Ins, such as the “Like” button and the “Recommendation” plug-in into their Brightcove video players using BEML. See "Facebook Open Graph Social Plugins in Brightcove Players" in the Brightcove Developer Center for a tutorial of how to do this.

Having this functionality implemented in the player itself is both important and cool because it means that the social plug-ins travel with the video content wherever it goes. If an end-user grabs the embed code and puts it their blog, the social plug-ins will be there. That can accelerate the pass-along effect and enrich the social graph with every click. The secret sauce behind this capability is BEML, the player customization and templating language for the Brightcove platform. BEML makes it possible to skin, extend, and add functionality to Brightcove video experiences without specialized development skills.

Thomas Pink "How to Tie a Bowtie" Merchandising Video with Purchase Links

The new Social Plugins are just the latest of many ways that we've been working with Facebook to embrace social sharing in the Brightcove platform. Last year we put a Facebook sharing control in our default player templates and worked with Facebook to have our players white-listed so that they can appear and play back directly in the Facebook activity stream and on fan pages. Without whitelisting, “Liked” or shared videos appear as linked thumbnails that force the end user out of the Facebook context. Viewing from within Facebook increases the likelihood that it will actually be watched. This is especially powerful with in-player calls to action (see Thomas Pink “How to Tie a Bowtie” example above) or when the video is a live streamed event (see Secretary Clinton Live Broadcast on Internet Freedom below).

U.S. Department of State Fan Page - Secretary Clinton Live Broadcast on Internet Freedom

So does socially recommended video get watched? Yes. And we can prove it. We've been working with TubeMogul on an upcoming research report that shows people who watch a video as a result of clicking on a link found through Facebook tend to watch longer than those who found the video through other means. It just makes sense that we are more inclined to stick with the video that was recommended by people we are at least casually connected to.

Taking a step back for a moment, what Facebook is doing here with the Open Graph is going to bring about what I call the "socially-validated Web." As sites and their visitors adopt these new plug-ins, it will create hundreds of billions of new connections between people and content. It's a thickening and contextualizing of the Web that could create incredible value for content owners, for consumers, and for Facebook. Better content will rise to the top quicker and the chaff will blow away faster.

Every time a real person authentically validates a piece of content as valuable, the world is better off. The socially validated Web will be very bad news for spammers, sploggers, and scammers who exploit the defects of today’s largely unvalidated Web. Add up all those micro-judgements and what you have is the possibility of a new distributed neural algorithm that transcends faceless "inbound links" and other 20th century content-ranking approaches. We’re talking about a re-imagining of content discovery on par with the semantic Web, but with no infrastructure re-architecture required.

Some may wonder what is so different about what Facebook is announcing today and all the multitude of social sharing buttons and links that have been growing like Web 2.0 mushrooms. The differences are critical mass scale and a connection a real-world social graph. Just sharing bookmarks and links over email or a real-time engine doesn’t forever bind the content to the social graph and make it possible to use that information to target content to users in the future. Facebook does. They are connecting all the pieces in a new way. Often that is all it takes.

If the genius of search was capturing user intent, the genius of the socially-validated web is capturing preferences and relationships. Exposing this data through APIs to every site owner is a win for the user because they get to better content faster, a win for the site owner because stickiness and engagement should improve, and a win for Facebook because they get insane amounts of data that they can use to target and monetize directly on their site.

I hope that all Brightcove customers are thinking deeply about how they can participate in the socially validated web to improve the reach and impact of their video content. Every site owner should be adding the features discussed in this post to their to-do list. And as the additional opportunities and implications of the socially validated Web come into focus, we'll be right there to help.

On Volcanoes, Drupal, and Community

Jeff Whatcott — Mon, 19 Apr 2010 15:13:52 +0000

The eruption of Eyjafjallajökull can shut down air traffic in Europe, but it can't shut down Brightcove and the global Drupal community. Many US-based Brightcovers are stranded in the UK along with hundreds of Drupal fans (a.k.a. Drupalistas) across Europe who had planned to attend Drupalcon San Francisco. The following map shows just a few of the affected Drupal community members:

View Drupalistas stuck in Europe in a larger map

Our own Mark Baker is based in the UK but had planned to travel to San Francisco to staff our booth and recruit/enable partners. As soon as it became clear that there was no way he was going to make it to San Francisco, Mark picked up the phone and started collaborating with the UK Drupal community to route around the situation. He and others quickly came up with the idea for DrupalVolCon, and a spontaneous unconference was born.

I worked through my Acquia contacts to make arrangements with Drupalcon organizers for free live video streaming (see below) of the keynote sessions. Google stepped up and provided space at the Googleplex for London Drupalistas to gather. Many helpers are now involved, and it is looking like additional DrupalVolCons have popped up in Antwerp and Paris. And all this in just 36 hours or so.

The live feed for this week's keynote sessions will be broadcast worldwide by Brightcove via the DrupalVolCon site, the Drupal UK site, the official Drupalcon San Francisco site, this blog post, and any other site that uses the embed code available through the player. NOTE: The feed will be dark at times other than the keynotes. Please be understanding if there are glitches: all of this came together at the last minute with volunteer efforts. You can track real time iteractions via the #drupalvolcon hashtag.

When I was working at Acquia in 2008, I had the privilege of participating with the community in the organization of Drupalcon Boston. It was early in my participation with the global Drupal community and I was truly amazed at the passion, the collaboration, and the volunteer spirit that everyone exhibited. It was chaotic at times, but in the end, everything came together in a inexplicable, but wonderful fractal fashion. Seeing the same dynamics at work with as the community adapts to a seemingly impossible disruption (a massive volcanic eruption) is very inspiring to me. Drupal is an unstoppable force.

Brightcove is working closely with several Drupal community members to extend and refine the integration between the Brightcove online video platform and Drupal. Many of our top customers like Sony BMG and Lifetime already use Brightcove and Drupal together, but we want to make it even easier. Stay tuned for more information on this. Drupal+Brightcove is powerful.

Desperation, Security, and Ethics

Jeff Whatcott — Wed, 31 Mar 2010 21:55:38 +0000

Small online video platforms are becoming increasingly aggressive in their attempts to compete with Brightcove. We have seen them pop up in a variety of deals doing and saying all kinds of things to try gain advantage. Most of the time, customers are able to see through the smoke and we don't pay much attention. But today, in an inexplicable act of desperation, one of these vendors crossed an ethical line that could have harmed customers and the industry, and we think it is worth mentioning here.

We received an email from the competing vendor's sales rep that was forwarded from a customer who had just signed on with Brightcove. The email ended with "thought you should be aware of this very serious security issue concerning Brightcove as it is another key differentiator between [vendor name] and Brightcove" in an effort to persuade the customer that they had made the wrong decision.

The email had an attachment called "brightcovesecurityholecommunicationdocumenttocustomers.zip" that contained two files of Brightcove documentation excerpts and two documents providing commentary from the competing vendor on what they claimed were serious vulnerabilities in our Media APIs and the way that these APIs are used in the context of our recently announced Brightcove Experience for HTML5 solution, the current version of which relies on our Media API architecture.

[UPDATE: NewTeeVee's Ryan Lawler has posted a story on this situation and named the vendor as Ooyala. We didn't name them here in the hope that they would back off these tactics.]

We later received a press inquiry from a reporter that had been given a tip to a potential security vulnerability in the Brightcove platform. We spoke with the reporter to clarify the facts and offer our perspective. We believe that this press inquiry was not a coincidence, and that the competing vendor planted the story through a surrogate as part of a coordinated campaign.

Before getting into the details, let's be very clear. We believe that there is in fact no vulnerability or "security hole" as described by the competing vendor. We believe that they are unethically distributing inflammatory misinformation about security matters. If this vendor actually believes that our customers are at risk, then their actions would only serve to harm our customers and our industry and make the world less secure. Mature, ethical software companies with a strong security culture do not handle things in this way.

Claims and Facts

The other vendor is making three claims. Their first, and most significant, claim is that our Media API architecture has a fundamental vulnerability. The second is that our Brightcove Experience for HTML5 solution has a "security hole" because it is based on our Media API architecture and that sites using our solution are at risk of unexpected information loss. The third is that our API tokens are "permanent", implying that customers cannot revoke or change them. Here are the facts.

Media API Architecture

Our Media APIs offer a separation between read actions and write actions. Write actions are inherently more high risk and we advise customers to never embed their write tokens in a system that is exposed to end-users. Write tokens should only be used from trusted systems that connect securely to Brightcove. In most cases, this would be a content management system or trusted custom server side process that the customer has written for this purpose.

Brightcove views read API actions as something that can be secured in situations where controlled access to the media library is desired, or can be left open in cases where open access to the media library is desired. In situations where restricted read access to the media library is desired, we advise customers to utilize a similar approach to what was described above for write APIs, where there is a trusted server-side process that stores the read API token and generates pages with embedded players that reference individual videos without any API information transmission to the end viewer. We believe that this method is highly secure if implemented properly.

For situations where open access to the media library is desirable, we advise customers that they may choose to place their read API token in untrusted client side code. It is equivalent in this case to providing a full content RSS feed or video sitemap to your website. Anyone who has an RSS feed can load all of the content, and in fact the publisher wants this to happen because they want the maximum number of viewers to enjoy and engage with the content. Many Brightcove customers fit this pattern.

In these open media library situations, the API token may be embedded on the client side, and it can be accessed and used in the manner that the other vendor has pointed out. This approach also saves the customer the complexity of developing a server side process that handles API access. Taking this approach is not a security risk, it is a proactive choice by the customer to make this information available because doing so accomplishes their business objectives.

Access to the media library over both MRSS and JSON via our read APIs is not a vulnerability, it is a feature, as long as the publisher is informed about what they're doing. For example, if a publisher has a video sitemap on their site for all their videos, their video information is already public and having access to a token and account info is not materially different. Likewise, if the customer has a section of their site that houses all of their videos in progressive download format, then their media library is also inherently open to the public.

Media API Usage in the Brightcove Experience for HTML5

The recently released Brightcove Experience for HTML5 solution includes code samples that incorporate the read API token in the client-side embed code. For all the reasons described above, this approach is completely valid for appropriate use cases and should not be a cause for concern as long as the customer is aware of the implications of this approach. We encourage customers to reference our existing documention on Media API security to understand the options for using the read token in this way.

The code we are currently providing for the Brightcove Experience for HTML5 follows a different, but valid, architecture from the code we will be providing later this year in the final version of the solution. The version we provide at that time will not use Media API tokens but will be providing a more constrained public API to retrieve video and player meta-data that does not require a token. When this new architecture is rolled out, the whole topic will be moot, but we maintain that the current approach is a valid choice for informed customers and that customers who want to take a server-mediated approach have that option today.

So again, we believe that the other vendor's claims about a "security hole" in our approach to HTML5 are false and misleading. The solution works exactly as designed and in accordance with the documentation that we have provided. The customer is in control of what they make available, and based on the guidance we have provided, can execute whatever security strategy they choose. In our opinion, calling our documented approach a "security hole" is wholly inaccurate and inflammatory.

Token Revocation

The other vendor also describes our media API tokens as "permanent," thereby implying that the tokens they are not revocable. This is false. Brightcove Media API tokens can be revoked and replaced at any time. This allows publishers a means to change their security approach at any time from the same account.

The Way it Should Be

Brightcove is committed to security. Our product has stood the test of time with the most demanding customers around the world. Our platform went through end-to-end audits by two separate third party security auditors in 2009. In one case, we paid for the audit to proactively find anything we had missed. In the other case, a large financial institution required the audit by their own auditor as a condition of their contract, which we welcomed. In certain areas, the auditors discovered areas for us to improve, but interestingly, neither firm took issue with our Media API architecture. We have taken action on the suggestions we received and we'll do more audits this year. Security work is never done, and anyone who tells you otherwise is either ignorant or untruthful.

It may be counter-intuitive, but we want our competitors products to be as secure as ours. Why? Because security breeds trust and trust brings industry growth, which creates more value for everyone. With that in mind, we'll make the following pledge to our competitors. If we find something that we perceive to be a critical vulnerability in your product, we will promptly and privately tell you everything we know about it, offer assistance and guidance on how to fix it, and we won't ask anything in return. We hope that our competitors will join us in making this pledge, because it will make the world more secure. And that's the way it should be.

If you are a Brightcove customer or interested in becoming one, and you would like to learn more about the security of our platform, please contact your account manager or submit a contact request via this form. We've got a great security white paper that we would love to share with you.

Brightcove Blog - Jeff Whatcott&#039;s Station