by Jeroen Wijering on 2010-05-26 05:05
Several months ago, Google bought ON2, the company behind the successful video codecs VP6 (used in Flash) and VP7 (used in Skype). Ever since the first rumors of this acquisition emerged, the online video community has speculated what this would mean for HTML5 video and its current issues around codec support. Last wednesday, Google finally made the announcement people hoped for: it open-sourced On2's VP8 codec as part of its WebM open media project.
Immediately after the announcement, we started receiving questions from our users: What exactly is WebM? Is it better than H.264? Do I have to re-encode my videos? Do you support WebM? This blog post answers these questions, focussing on the practical implications of WebM. Feel free to comment on this post if you have additional questions - we'll keep an eye on it.
First, a little overview. WebM is the overall name of the new video format Google launched last wednesday. WebM videos have the extension .webm (e.g. myCoolVideo.webm). They contain three major building blocks:
The big issue surrounding HTML5 video - video codecs - is basically an issue of rights. On one hand there is the H.264 codec, which is of superior quality but heavily patented. End users and online video publishers do not have to pay (at least, not yet), but browser and device vendors do pay millions of dollars for incorporating H264 support. On the other hand, there's the Theora codec, which is royalty-free but of inferior quality (in fact, Theora is a heavily modified version of ON2's VP3 codec).
Like Theora, VP8 is released using an open-source, royalty free license. The license also permits free inclusion in closed-source commercial products. Because of its free license, the VP8 codec has the ability to end the HTML5 codec war and become the de facto HTML5 video codec. Like VP8, the WebM container and Vorbis audio codec are open source, royalty-free and liberally licensed.
In its current state, VP8 is not better than H.264. The quality of VP8 video is more or less on par with the lowest quality profile of H.264: Baseline. The two higher quality profiles - Main and High - offer better results. VP8 is definitely better than Theora though.
Is this bad news? Absolutely not. One could say that VP8 video simply is good enough, just like JPEG was good enough for images and MP3 was good enough for audio. On top of that, the majority of today's H.264 videos use the Baseline profile, for efficiency and compatibility reasons. For example, Bits on the Run uses H.264 Baseline because videos transcode faster and more computers (e.g. ATOM-based netbooks) can play the videos without stuttering. Also, most mobile devices (like the iPhone) only support H.264 Baseline.
It depends. If you just want to do some tests with WebM, you can get started today. Download Miro Video Converter to encode your videos to WebM. Download Opera 10.54 to play these videos using the HTML5 video tag. Here is a WebM example using the JW Player for HTML5.
If you want to use WebM in a production environment, the story is different. The ecosystem around WebM (browsers, transcoders, hardware support) is in its infancy. It will take a few years until WebM has the same level of support and end-user penetration (browsers, phones) than H.264 has today. Also expect major improvements to the VP8 quality and processing speed, and solutions for advanced use cases like live streaming or security. This year for sure, H.264 will remain to be the best option for publishing video in a production environment.
For our video platform, Bits on the Run, expect WebM transcoding support to arrive in 3 to 6 months. We will wait for official releases of web browsers that can play WebM. Luckily, the implementation itself is fairly straightforward, since the WebM project includes an encoding library for the tool we use - FFmpeg.
As to when we will endorse WebM as the video format of choice - it depends upon the speed with which WebM will be adopted by the online community. It could be five years from now. It could also be one year from now, if WebM is adopted as fast as the <video> tag. Overall, we are very excited about WebM - both in terms of quality and licensing, it has what it takes to become the de facto format for online video.
by LongTail Video on 2010-05-24 17:58
Many of our customers use video as a means of showcasing their products. Whether a website’s purpose is to sell t-shirts or network routers, video creates an interactive and engaging experience for users to learn about the benefits of the product. Combine video with the reach of the world wide web, and you have an effective viral marketing campaign. But beyond describing the virtues of what you’re selling, you’ll actually want to sell it.
That’s where Adtonomy Text can be of assistance. Designed to run overlay text ads during video playback, Adtonomy Text is ideally suited to display a call-to-action while a user is engaged in learning about your product. Here is an example using a video that promotes our Bits on the Run product and text overlay ads encouraging the user to sign-up.
While video allows for audio and visual demonstration of products and services - overlay text ads act as a parallel promotional tactic that provide quick, easy links to a product page.
Start by determining which product video you want to promote. Once selected, prepare the following: a thumbnail image and the titles & descriptions for your promotional links. Be selective with your titles and descriptions – descriptions should be concise and action-oriented with phrases like “Buy Now”, or “Receive 50% off Today”. For best results, we recommended linking your Adtonomy Text Ads directly to an order form, or the product's promotional page.
You can create an XML file as shown below.
<?xml version="1.0"?> <ad-program> <ads> <ad id="ad1"> <text_ad title="Sign up for a Free Trial Today!" description="Try out Bits on the Run with a free, 30 day trial." length="0:08" link="http://www.longtailvideo.com/bits-on-the-run/sign-up" image_url="adimage1.gif"/> <trackers> <tracker type="impression" url="mytrackerurl1"/> <tracker type="clicktrack" url="mytrackerurl2"/> </trackers> </ad> <ad id="ad2"> <text_ad title="Premium-Quality Video for Just a Few Dollars a Month" description="Our pay-as-you-go pricing makes us the most affordable video platform." length="0:10" link="http://www.longtailvideo.com/bits-on-the-run/sign-up"/> <trackers> <tracker type="impression" url="mytrackerurl3"/> <tracker type="clicktrack" url="mytrackerurl4"/> </trackers> </ad> </ads> <controls overlay_reopen_color= "0x333333" overlay_background_color= "0x333333" overlay_title_color= "0x669900" overlay_description_color= "0xffffff" overlay_link_color= "0x669900" overlay_linkover_color= "0x99CC66" overlay_mouseover_color= "0x99CC66" /> <spots> <spot id="overlay1" timing="0:03" items="ALL"> <allow ad_ids="ad1"/> </spot> <spot id="overlay2" timing="0:20" items="ALL"> <allow ad_ids="ad2"/> </spot> </spots> </ad-program>
You can customize your text overlay ads by changing some of the the following features: ad position, ad color (background, title, description, etc.), and ad dimensions. You also choose how many ads to display throughout the video, and where they should appear. See in the example above where we've timed one ad to appear 3 seconds into the video and display for 8 seconds, then the second ad appears at 20 seconds and displays for 10 seconds.
You might also notice the impression and clicktrack tags in the XML, those allow you to report back to your own server when an ad is displayed to or clicked by the user. It is important to leverage analytics as best you can to measure the effectiveness of your promotional campaign. You should consider A/B testing different variations of your ads to determine which one resonates most effectively with your user base.
by Zachary Ozer on 2010-05-12 12:53
Today, we're pleased to announce the beta release of the JW Player for HTML5. The JW Player for HTML5 leverages new technology within modern web browsers to playback video without the need for plugins or addons. This has the potential to improve both user experience and performance, especially as browsers begin to take advantage of the hardware-based video decoding available on most devices.
That having been said, no browser on the market today has the extensive playback capability of the JW Player for Flash. For that reason, we've built in a seamless fallback for those viewers who can't take advantage of these improvements.
Although we've labeled the player as beta, you'll still find a fully functional player jam-packed with features, including:
You can download the JW Player for HTML5 here.
The JW Player for HTML5 is the newest in our long line of players and demonstrates our continued commitment to supporting the most innovative technologies. Should you have any issues, please don't hesitate to contact us via our support forum.
by Jeroen Wijering on 2010-05-10 17:04
Online video is an exciting field to work in. As creator of the JW Player, I'm privileged to be at the forefront of the industry. Every week, our team receives thousands of emails from web developers regarding various bug reports, product feature requests and general thoughts about the online video space. In these emails, we've seen a growing interest in HTML5, since its video implementation allows web developers to independently control video content.
Apple's launch of the iPad and its successive arguments with Adobe over Flash accelerated HTML5 video development. One could argue that today's tech industry is in a state of video tag euphoria. Although many high level discussions regarding online video are circulating through the blogosphere, the practical side of HTML5 video development has been overlooked. Therefore, when working hands-on with HTML5 for video development, it becomes clear the standard faces a major threat.
The video tag is still in its infancy and misses certain core functionalities. As developers demand these features, browser vendors are tempted to implement incompatible solutions instead of agreeing upon standards. These hasty developments, already underway, are setting HTML video up for the same chaos as HTML styling in the pre-CSS era.
Here are a couple of the most pressing issues:
The H264 versus OGG debate is ongoing, but all browsers have placed their bets - Firefox and Opera favor OGG, Internet Explorer and Safari choose H264. Chrome plays it safe and does both.
While their reasoning is noble, Firefox's choice to support just OGG isn't practical. The majority of online video content is encoded in H264. Nearly all mobile devices that support web browsing use H264. Desktops and laptops can do hardware decoding of H264. By contrast, content in OGG is virtually nonexistent and the number of mobile devices supporting OGG decoding is devoid. The lack of hardware decoding for OGG makes playback of HD content a resource hog. Apparently, developers don't want this.
Perhaps OGG (or VP8) will gain traction in the coming years. However, developers want to use HTML5 video today. And today's online video format is H264.
HTML5 does not specify a streaming mechanism yet. While this is being worked on (W3C: Fragments, Media Multitrack API), it means that live, DVR and long-form video content cannot be played using a video tag. Most browsers do provide an alternative, such as utilizing the range request header to do pseudo-streaming, but this is no long-term solution.
Safari, however, does provide a working streaming solution. It is easy to use (although a simple ingestion tool is still missing) and follows the emerging standard of chopping up videos into small fragments and delivering those to the browser. Unfortunately there are small differences between Safari's implementation and that of, say, Silverlight and Flash:
1) Safari requires the video fragments to be wrapped in an MPEG TS container, while both Flash and Silverlight use MP4 containers.
2) Safari uses M3U8 text files to tell the browser which video fragments are available. Silverlight and Flash both use XML files.
Since streaming is the single biggest block missing in HTML5 video, other browsers may rush to implement their own streaming solutions (for example, IE9 might support Silverlight's fragmentation and manifesting). A single standard is needed for HTML5 video streaming to ensure its usefulness.
While a small feature at first sight, fullscreen playback is essential to the success of HTML5 video. Fullscreen video captivates the viewer, greatly enhancing the visual experience, and tends to increase viewer engagement. Without fullscreen, HTML5 video is mostly useful for presenting short clips.
Browser-wise, things get a little complicated. The W3C video draft specifically states that browsers should not provide a public API to cause videos to be shown full-screen. The underlying reasoning (phishing) is valid, but technologies like Flash and Silverlight have already proven that simple restrictions can mitigate these risks.
Meanwhile, developers have demanded fullscreen playback and browser vendors worked around the W3C spec to implement custom solutions. In Firefox 3.6, fullscreen viewing is available by right-clicking a video (no API). In Webkit (the rendering engine both Safari and Chrome are based on), fullscreen mode can be activated by means of ALT-clicking (semi-API). Both options are too obscure to gain any traction. A single public API with clear restrictions is needed.
Video is an important part of today's internet. It deserves to become a first-class citizen and the video tag provides the opportunity to make that happen. Browser vendors should be stringent when building solutions that are both practical and compatible. If not, crossbrowser HTML5 video will be too difficult, not to mention expensive, to implement. This presents the risk of web development regression.
In favor of its advancement, we cannot allow this to happen. Online video will go mobile and big screen. It also needs to become accessible and searchable. HTML5 video will advance the progress in these areas, if developed carefully and intelligently. However, without compatible solutions, online video is in definite jeopardy of a setback.