Contact us
|
+1 888 882-1880
M-F 8am to 8pm EST

USING GOOGLE COMPUTE ENGINE FOR VIDEO TRANSCODING

bsp-admin-1 on July 23, 2012

For those of us in the cloud computing world, the most exciting thing that came out of Google I/O in 2012 wasn’t skydivers wearing Glass, and it wasn’t a new tablet. The big news was that Google is getting into the cloud infrastructure-as-a-service space, currently dominated by Amazon Web Services (AWS). Specifically, Google has launched a new service called Google Compute Engine to compete with Amazon EC2.

This is exciting. The world needs another robust, performant, well-designed, cloud virtual machine service. With apologies to Rackspace and others, this has been a single-player space for a long time—EC2 is far and away the leader. Google obviously has the expertise and scale to be a serious competitor, if they stick with it.

How does it look? Early reports are positive. Google Compute Engine (GCE) is well-designed, well-executed, and based on infrastructure Google has been using for years. Performance is good, especially disk I/O, boot times, and consistency, which historically haven’t been EC2’s strong suit. But how well suited is GCE for cloud video transcoding? We have some preliminary results, acknowledging that more testing needs to be done. Here are some basic tests of video transcoding and file transfer using Zencoder software on both GCE and EC2.

Raw Transcoding Speed

Performance is our top priority, so Zencoder uses the fastest servers we can find. On EC2, we use Cluster Compute instances, which are fast dual-CPU machines in two sizes: 4XL and 8XL. We compared these with the fastest GCE instance type, which is currently a single-CPU 8-core server.

ServerCPU
GCE 8-coreIntel Xeon (Sandy Bridge – probably E5-2670) – 8 cores @ 2.60GHz
EC2 cc1.4xlargeDual Intel Xeon X5570 – 8 cores @ 2.93GHz/core
EC2 cc2.8xlargeDual Intel Xeon E5-2670 – 16 cores @ 2.60GHz/core

These tests were done using an H.264 source video at 640×360 and 1280×720 resolutions, and were encoded by Zencoder using the same single-pass output transcoding settings (H.264 Baseline profile, AAC, one-pass Constant Quality transcoding, etc.).

Google Compute Engine vs. Amazon EC2

ServerResolutionSimultaneous EncodesTime (seconds)Cost per thousand
EC2 cc1.4xlarge640×360615.87$0.96
EC2 cc2.8xlarge640×36069.93$1.10
GCE 8-core640×360621.05$1.13
GCE 8-core640×36016.01$1.94
EC2 cc1.4xlarge640×36015.96$2.15
EC2 cc1.4xlarge1280×720648.58$2.92
EC2 cc2.8xlarge640×36014.99$3.33
EC2 cc2.8xlarge1280×720630.74$3.42
GCE 8-core1280×720668.15$3.66
EC2 cc1.4xlarge1280×720112.89$4.65
GCE 8-core1280×720116.01$5.16
EC2 cc2.8xlarge1280×720110.92$7.28

Using default Zencoder settings, both types of EC2 instance are faster than GCE. The economics are a bit closer, and there isn’t a clear winner between 4XL EC2 instances and GCE. So GCE is a viable option for transcoding where cost is a higher priority than raw speed, though AWS customers can make use of Reserved Instances and Spot Instances for further cost reductions. We noticed that the 16-core EC2 instances were roughly twice as fast as GCE 8-core instances when under load with 6 simultaneous transcodes.

Given the similar clock speeds, but half the number of cores, this is what you would expect. However, if Google adds similar 16 core machines, they could have comparable transcoding speeds.

Transfer Speeds

When transcoding video in the cloud, network I/O is almost as important as CPU. This is especially true for customers working with high-bitrate content (broadcasters, studios, and creatives). So how do GCE transfer speeds compare to EC2? To test this, we ran four sets of benchmarks:

  • Amazon S3 to Amazon EC2
  • Amazon S3 to Google Compute Engine
  • Google Cloud Storage to Amazon EC2
  • Google Cloud Storage to Google Compute Engine

We did this by testing the same 1GB video file stored on Google Cloud Storage (GCS) and on Amazon S3. Transfer was performed using 10 HTTP connections (Zencoder does this by default to optimize transfer speeds, and it can dramatically speed up large file transfers over HTTP).

GCE vs EC2 Transfer Speeds

 Transfer speed (Mbps)Server Bandwidth
S3 to GCE470.961 Gbps
S3 to EC2 c1.xlarge644.291 Gbps
S3 to EC2 cc2.8xlarge1458.3210 Gbps
GCS to GCE202.601 Gbps
GCS to EC2 c1.xlarge378.281 Gbps
GCS to EC2 cc2.8xlarge641.3410 Gbps

This is interesting. We expected Amazon-to-Amazon transfer to be fast, which it was. But we also expected Google-to-Google transfer to be fast, which it wasn’t. In fact, it appears that GCS is slower than S3, and GCE transfer is slower than EC2, such that even if you’re using Google for compute, you may be better off using S3 for storage. Transfer was 2.3x faster from S3 to GCE than from GCS to GCE.

More Tests Needed

Consider these results preliminary. Further testing needs to be done to take into account more variables.

  • Instance-to-instance differences. This is especially true for file transfer, which can vary widely based on network conditions and instance variability.
  • Additional applications. These benchmarks only cover transcoding, which is a CPU-bound benchmark. Other applications are limited by disk, memory, etc., and these tests don’t speak to anything other than transcoding.
  • Scalability. Scalability is extremely important for anyone using the cloud for video transcoding. More tests are needed to see how GCE compares with EC2 when it comes to enormous scale—tens of thousands of servers (or more). At what point do users run into capacity issues? Performance problems? Design limitations? Instability?

Cloud Infrastructure Future

Even though EC2 wins in these early tests, we’re excited about Google Compute Engine. To be a serious competitor for high-performance transcoding, Google needs to add larger instances with faster CPUs. But adding new instance types is easy. Nothing prevents Google from doing this. What is hard is building a robust, performant, feature-complete, scalable cloud platform, and Google seems to have succeeded. If Google is committed to this product and developers for the long run, the cloud virtualization world may have just gotten a second legitimate player.

CLOSED CAPTIONING FOR WEB, MOBILE, AND CONNECTED TV

bsp-admin-1 on July 13, 2012

Closed captioning is a good thing for accessibility and usability, and is yet another milestone as internet video marches towards maturity. Unfortunately, closed captioning is not a single technology or “feature” of video that can be “turned on.” There are a number of formats, standards, and approaches.

Closed captioning is kind of a mess, just like the rest of digital video, and is especially challenging for multiscreen publishers. So if you want to publish video today for web, mobile, and Connected TV delivery, what do you have to know about closed captioning?

This post will outline the basics: how closed captions work, formats you may need to know about, and how to enable closed captions for every screen.

How Closed Captions Work

The first thing to understand is how closed captions are delivered, stored, and read. There are two main approaches today.

  • Embedded within a video. CEA-608, CEA-708, DVB-T, DVB-S, WST. These caption formats are written directly in a video file, either as a data track or embedded into a video stream itself. Broadcast television uses this approach, as does iOS.
  • Stored as a separate file. DFXP, SAMI, SMPTE-TT, TTML, EBU-TT (XML), WebVTT, SRT (text), SCC, EBU-STL (binary). These formats pass caption information to a player alongside of a video, rather than being embedded in the video itself. This approach is usually used by browser-based video playback.

Differences Between Subtitles and Closed Captions

What about subtitles? Are they the same thing as closed captions? It turns out that there are three main differences.

  • Goals. Closed captions are an accessibility feature, making video available to the hard of hearing, and may include cues about who is speaking or about what sounds are happening: e.g. “There is a knock at the door”. Subtitles are an internationalization feature, making video available to people who don’t understand the spoken language. In other words, you would use captions to watch a video on mute, and you would use subtitles to watch a video in a language that you don’t understand. Note: This distinction holds in North America, but much of the world does not distinguish between closed captions and subtitles.

  • Storage. Historically, captions have been embedded within video, and subtitles have been stored externally (see CEA-608 below). This makes sense conceptually, because captions should always be provided along with a video; 100% accessibility for hard-of-hearing is mandated by legislation. Whereas subtitles are only sometimes needed; a German-language video broadcast in Germany doesn’t need to include German subtitles, but that same video broadcast in France would.

  • Playback. Since captions are passed along with the video and interpreted/displayed by a TV or other consumer device, viewers can turn them on and off themselves at any time using the TV itself, but rarely have options for selecting a language. In these situations when subtitles are added for translation purposes, they are generally hard subtitles (see below) and thus cannot be disabled. However, when viewing DVD/Blue-Ray/VOD video, the playback device controls whether subtitles are displayed, and in which language.

Formats and Standards

There are dozens of formats and standards for closed captioning and subtitles. Here is a rundown of the most important ones for internet video.

  • CEA-608. Also called Line 21, CEA-608 captions are the NTSC standard, used by analog television in the United States and Canada. Line 21 captions are encoded directly into a hidden area of the video stream by broadcast playout devices. If you’ve ever seen white bars and dots at the top of a program, that’s Line 21 captioning.
  • SCC. This file contains captions in Scenarist Closed Caption format. It contains SMTPE timecodes with the corresponding encoded caption data as a representation of CEA-608 data.
  • CEA-708. This is the standard for closed captioning for ATSC digital television (DTV) streams in the United States and Canada. There is currently no standard file format for storing CEA-708 captions apart from a video stream.
  • TTML. Timed Text Markup Language describes the synchronization of text and other media such as audio or video. See the W3C TTML Recommendation for more.
  • DFXP. This is a profile of TTML defined by W3C. DFXP files contain TTML that defines when and how to display caption data. DFXP stands for Distribution Format Exchange Profile. DFXP and TTML are often used synonymously.
  • SMPTE-TT. The Society of Motion Picture and Television Engineers – Timed Text is an extension of the DFXP profile that adds support for three extensions found in other captioning formats and informational items but not found in DFXP: #data, #image, and #information. SMPTE-TT is also the FCC Safe Harbor format. If a video content producer provides captions in this format to a distributor, they have satisfied their obligation to provide captions in an accessible format. However, video content producers and distributors are free to agree upon a different format.
  • SAMI. Synchronized Accessible Media Interchange is based on HTML and was developed by Microsoft for products such as Microsoft Encarta Encyclopedia and Windows Media Player. SAMI is supported by a number of desktop video players.
  • EBU-STL. This is a binary format used by the EBU standard, stored in separate .STL files.
  • EBU-TT. This is a newer format supported by the EBU, based on TTML. EBU-TT is a strict subset of TTML, which means that EBU-TT documents are valid TTML documents, but some TTML documents are not valid EBU-TT documents because they include features not supported by EBU-TT.
  • SRT. This is a format created by SubRip, a Windows-based open source tool for extracting captions or subtitles from a video. SRT is widely supported by desktop video players.
  • WebVTT. This is a text format that is similar to SRT. The Web Hypertext Application Technology Working Group (WHATWG) has proposed WebVTT as the standard for HTML5 video closed captioning.
  • Hard subtitles. Hardsubs are, by definition, not closed captioning. Hard subtitles are overlaid text that is encoded into the video itself, so that they cannot be turned on or off, unlike closed captions or soft subtitles. Whenever possible, soft subtitles or closed captions are generally be preferred, but hard subtitles can be useful when targeting a device or player that does not support closed captioning.

Captioning for Every Device

What formats get used by what devices and players?

  • HTML5. Captions are not yet widely supported by browsers, but that will change over time. There are two competing standards: TTML, proposed by W3C, and WebVTT, proposed by WHATWG. At the moment, Chrome has limited support for WebVTT; Safari, Firefox, and Opera are all working on WebVTT support; and Internet Explorer 10 supports both WebVTT and TTML. Until browsers support a format natively, an HTML5 player framework like Video.js can support captions through Javascript, by parsing an external file (Video.js currently supports WebVTT captions).
  • iOS. Apple takes a different approach, and uses CEA-608 captions using a modified version of CEA-708/ATSC legacy encoding. This means that, unlike HTML5, captions must be added at the time of transcoding. Brightcove Zencoder can add captions to HTTP Live Streaming videos for iOS.
  • Android. Video player support is still fragmented and problematic. Caption support will obviously depend on the OS version and the player used.
  • Other mobile devices. Some have no support for closed captions at all, and hard subtitles may be the only option.
  • Roku. Supports captions through external SRT files.
  • Other Connected TV platforms. Some do not support closed captioning yet. But they will soon enough. Every TV, console, cable box, and Blu-Ray player on the market today wants to stream internet content, and over the next year and a half, closed captioning will become a requirement. So Sony, Samsung, Vizio, Google TV, et al will eventually make caption support a part of their application development frameworks. Unfortunately, it isn’t yet clear what formats will be used. Most likely, different platforms will continue to support a variety of incompatible formats for many years to come.

Closed Captioning Requirements

The landscape for closed captioning will change and mature over time, but as of 2012, here are the most common requirements for supporting closed captioning on common devices.

  • A web player with player-side controls for enabling and disabling closed captioning.
  • An external file with caption data, probably using a format like WebVTT, TTML, or SRT. More than one file may be required (e.g. SRT for Roku and WebVTT for HTML5).
  • A transcoder that supports embedded closed captions for HTTP Live Streaming for iPad/iPhone delivery, like Zencoder. Zencoder can accept caption information in a variety of formats, including TTML, so publishers could use a single TTML file for both web playback and as input to Zencoder for iOS video.

Beyond there, things get difficult. Other input formats may be required for other devices, and hard subtitles are probably necessary for 100% compatibility across legacy devices.

Brightcove Zencoder and Captions

Brightcove Zencoder supports closed captioning for two formats: CEA-608-style captions for iOS devices using HLS, and MP4 files with CEA-608 caption tracks. On the input side, we support SCC, SAMI, DFXP/TTML/SMPTE-TT, and CEA-608 caption tracks in MP4 files.

To date, we’ve chosen to focus on embedded captions because these formats are added to video files at the point of transcoding. So if we didn’t support captioning for iPad or iPhone, our customers publishing to these devices wouldn’t be able to use closed captions. In the future, we’ll expand the range of caption formats we accept, and we may provide services like format conversion for external caption files (e.g., TTML to WebVTT).

In the meantime, with a single caption file and the right HTML5 player, Brightcove customers have everything they need to create captioned videos for web, mobile, and Connected TV devices.

APP CLOUD: A WEB DEVELOPER’S EXPERIENCE REPORT

bsp-admin-1 on February 24, 2012

During my 13 years as a web developer and designer, I’ve effortlessly adapted to new technologies—starting with Java, then PHP, and later Ruby. For a long time, I was immersed in the “Flash steamer,” exploring major UI libraries like Prototype and jQuery while staying up-to-date with rapidly evolving web standards.

However, like many web developers, I missed the leap into mobile applications. I lacked experience with low-level languages like C++ or Objective-C and didn’t have the time to learn them. The idea of creating “small” apps in Java—a language I found bulky and extensive—was equally unappealing.

I explored several cross-platform development tools, but they consistently fell short of expectations:

  • App “factories” that wrap RSS feeds in pre-built templates created generic, uninspired apps.
  • Frameworks converting JavaScript or ActionScript into native code required complex toolchains for app creation and compilation.
  • Frameworks that wrapped web pages in native shells offered little infrastructure for deploying data-driven apps in production environments.

When I discovered App Cloud, a framework for creating native mobile apps using HTML, CSS, and JavaScript, I was skeptical. Would it be any different from the others? Could it deliver on its promises? After developing my first app, I can confidently say the answer is “Yes!” Here’s why.

APP CLOUD SPEAKS THE LANGUAGE OF DEVELOPERS

App Cloud relies on the core skills of web developers: HTML to structure content, CSS to shape, and JavaScript to edit it. There’s no need to learn new languages to create content-driven, rich apps. Web technologies have always excelled in simplicity. Compare the complexity of creating a table view in iOS with the ease of creating a basic HTML list—it’s no contest!

The App Cloud SDK also supports almost any JavaScript library, letting me apply tricks I’ve mastered over years of web development.

IN THE FAST LANE WITH APP CLOUD

I frequently switch between BBEdit and vim when coding, as they remain my most comfortable tools. App Cloud allows me to keep using these familiar editors. Since it relies on standard web technologies, I can also debug and test my code with Chrome Developer Tools. Unlike cumbersome systems tied to XCode or Eclipse, App Cloud provides flexibility and freedom.

RAPID ITERATION WITH THE WORKSHOP APP

The App Cloud workshop app for iOS and Android enables real-time testing during development. After making code changes, I simply click “Refresh” to immediately view updates. For web developers accustomed to iterative processes—code, refresh, repeat—this feature is invaluable.

While much testing can be done on desktop browsers, nothing beats seeing how an app performs on actual devices. The workshop app makes this easy and seamless.

LEVERAGING DEVICE-SPECIFIC FEATURES

App Cloud offers a straightforward JavaScript API for accessing device-specific functionalities, such as the camera or photo library. For instance, scanning a QR code is as simple as:

bc.device.getQRCode(
function (data) { /* handle success */ },
function (error) { bc.device.alert("Oops! " + error.errorMessage); }
);

SIMPLIFIED APP COMPILATION

Compiling apps with other tools, like Android developer kits, often feels like assembling IKEA furniture: tedious and frustrating. With App Cloud Studio, apps are compiled in the cloud with just a few clicks. In minutes, the app is ready for download and deployment to various app stores—no special tools required.

CONTENT OPTIMIZATION: LESS IS MORE

In content-driven apps, content itself is often the bottleneck. App Cloud optimizes performance by:

  • Removing unnecessary data, compressing feeds, and caching content. For example, my blog feed shrank from 39KB to 4KB—a 90% reduction.
  • Transcoding images to reduce file size. One image went from 125KB at 425 pixels wide to 8KB at 200 pixels wide—a 94% reduction.

These optimizations significantly improve load times, which are critical for user engagement.

FLEXIBILITY BEYOND DEPLOYMENT

Unlike other tools, App Cloud Studio allows me to modify data, design, and settings post-deployment—no need to recompile or redistribute the app. This flexibility enables me to create multiple apps from a single template by swapping data feeds and adjusting settings.

COLLABORATION MADE EASY

App Cloud makes it simple to share apps with colleagues. Screenshots can be shared directly from the workshop app, or templates can be distributed via URLs or QR codes, enabling efficient collaboration and testing.

COMPREHENSIVE CLOUD MANAGEMENT

App Cloud offers everything I need to manage and monetize apps, from native ad delivery to real-time analytics. I can track installations, usage time, and other key metrics.

Additionally, App Cloud provides free performance enhancements and feature updates. Future improvements, such as push notifications and in-app purchases, will make the platform even more powerful.

App Cloud combines the simplicity of web development with the functionality of native apps, making it an indispensable tool for developers looking to create efficient, scalable, and engaging mobile apps.

ENCODING SETTINGS FOR PERFECT IPAD/IPHONE VIDEO

bsp-admin-1 on January 24, 2012

Any serious video publisher either already supports iPad and iPhone or needs to think hard about adding support. For some major publishers, iPad delivery represents a third of total video views or more.

Encoding for iOS is a little tricky, though. These devices have gone through several generations of technical capabilities, and the ideal video settings for the iPhone 4 are not ideal for the iPhone 3GS or for the iPad.

Fortunately, with just a few encoding profiles, you can stream high quality video to every iOS device, from the first iPhone to the iPad 2, and even prepare for future generations of mobile hardware.

General Settings

Like most video today, use h.264 video and AAC audio when targeting iOS.

On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio.

On the video side, use multiple profiles to target each device. The iPhone 3GS and earlier only supports the h.264 Baseline profile, level 3.0 (and some support a more constrained version than that), whereas newer devices support the Main and High profiles.

For the best user experience, HTTP Live Streaming (HLS) is a must. Apple requires it of any video app in the App Store that plays content longer than 10 minutes, and it is the only true streaming format supported by iOS. HLS is also being adopted by Android (version 3+), Roku, and a range of other destinations.

General Approach

ResolutionProfileBitrate@ 16:9@ 4:3AudioComments
1024×768[email protected]2Mbps1024×5761024×76856kbps HE-AAC 
960×640[email protected]1.5Mbps960×540854×64056kbps HE-AAC 
640×432[email protected]1Mbps640×360576×43256kbps HE-AAC 
480×320[email protected]600kbps480×272426×32056kbps HE-AAC 
400×288[email protected]400kbps400×224384×28856kbps HE-AAC 
400×288[email protected]200kbps400×224384×28856kbps HE-AACdecimate frame rate
N/A (Audio Only)    56kbps HE-AAC 

Why these recommendations?

  • These are just recommendations. Different resolutions and bitrates are perfectly valid, and may actually be preferable in some circumstances. For example, extremely complex content may warrant higher bitrates.
  • 720p is the largest video playable on iPad 1 and iPhone 4, and iPad 2/iPhone 4S play anything up to 1080p. But since the native display is only 1024 pixels wide, going all the way to 720p or 1080p isn’t critical. Unless, of course, you want to reuse a video somewhere else—720p is a great resolution for fullscreen web playback, and 1080p is entirely appropriate for Connected TVs. Future iPads are rumored to have 4x the resolution of the current iPad, so consider adding 720p for future-proofing.
  • The h.264 profile is important. The iPad 1 and iPhone 4 both support the Main profile. The iPad 2/iPhone 4S support the High profile, which is marginally better than Main, but given the number of iPad 1 devices in the world, it is probably better to stick to Main profile. For truly optimal device targeting, encode to both Main and High.
  • These six resolutions and bitrates provide reasonably good coverage of varying bandwidth. You could certainly do more, so add or subtract resolutions and profiles as desired.
  • Legacy iPhone/iPod Touch users will have three streams available to them, including a reasonably high quality 480×320 video (the screen resolution of these devices). Users of the iPad and iPhone 4 will be able to make use of all six streams.
  • The resolution scaler on the iPad is pretty good, so videos that are rescaled will generally look good.
  • As much as possible, these settings allow for resolution dimensions divisible by 16. This makes for more efficient compression. The efficiency gains are small, especially at high resolutions, but at lower resolutions they start to make a difference.
  • Be sure to keep the audio identical across each video. If the audio specifications change from one version to another, the user may hear pops and clicks during playback when switching streams.

Other Settings

  • Set the speed based on desired turnaround time. For these recommendations, we’re going to use Speed 2, which improves compression a bit over the baseline but is still reasonably fast.
  • Ensure that each segment is roughly the same size by using a peak bitrate\_cap of 150% of the target bitrate, but within a long buffer\_size (e.g., five seconds, or 5x the bitrate\_cap).
  • Brightcove automatically chooses proper keyframe placement when you set the type to “segmented.” If you’re encoding to MP4 for separate segmenting to HLS, set forced\_keyframe\_rate to “0.2” or “0.1” (for five or 10 second keyframe intervals, respectively).
  • If you can accept slightly unpredictable bitrates, add quality to the mix, and change video\_bitrate to max\_video\_bitrate to optimize for file size. The encoder will use the max bitrate when needed, and will use a lower bitrate when it can achieve the desired quality with fewer bits.
  • Set the max\_frame\_rate to 30 and the max\_audio\_sample\_rate to 48000.
  • The first generation if iOS devices only allow one h.264 reference\_frame, so enable this on the Baseline streams for max compatibility.

USING ONLINE VIDEOS: DIY VS. SOCIAL VS. OVP

bsp-admin-1 on July 13, 2011

More and more companies are discovering the diverse potential of online videos: their immense popularity with users, their ability to evoke emotions, excellent marketing opportunities, significant boosts to product sales, and even improved search engine rankings. However, many overlook the unique challenges and hurdles associated with leveraging videos effectively.

Even with a coherent video concept and professionally produced clips, one critical question remains: How should the videos be integrated into the company’s website? There are three primary options.

1. DIY SOLUTIONS

The first option is an individual solution. A (hopefully) skilled employee encodes the videos, programs a Flash player or configures a freely available player, uploads the videos to an HTTP server, and integrates them into the website.

While this approach may work for a small number of videos with limited views, it quickly becomes impractical when handling more videos or higher traffic. This DIY solution can become disorganized, error-prone, maintenance-intensive, and time-consuming.

2. SOCIAL VIDEO SITES

The second option involves using social video sites like YouTube. By uploading videos to these platforms, companies receive embed codes to integrate the videos into their websites. These sites offer relatively robust statistics on video usage, and the videos are discoverable not only on the company website but also via YouTube’s search.

However, this solution comes with significant drawbacks. By uploading videos to YouTube, companies partially relinquish rights, allowing YouTube to market the videos, which could result in competitor advertisements running before the company’s content. Additionally, YouTube retains control over the video’s appearance and technical specifications, leaving companies dependent on the platform’s decisions. In this scenario, companies hand over control to YouTube and must accept whatever changes or limitations come their way.

3. ONLINE VIDEO PLATFORMS (OVPS)

This is where Brightcove comes in as the third and most professional option. An OVP combines the customization of a DIY solution with the technical capabilities of a social video site while offering legal security and complete control.

Of course, an OVP requires an investment—but it’s no different from other professional tools and systems companies routinely use. For a relatively small cost, customers gain access to a comprehensive, well-maintained, and continuously improved system.

KEY ADVANTAGES OF OVPS

  • Reliable delivery: Videos are delivered via Content Delivery Networks (CDNs), ensuring performance without straining the company’s servers.
  • Detailed analytics: OVPs provide detailed statistics on video views, enabling companies to measure effectiveness and gain insights for future productions.
  • Complete control: Videos remain under the company’s full control, with the ability to integrate monetization through connections to ad servers or advertising networks.
  • Optimized workflows: OVPs minimize technical tasks and risks, streamlining video production and distribution processes.

Online video platforms are designed specifically for the professional use of videos. They allow companies to optimize workflows, reduce technical challenges, and use videos on the internet effectively, securely, and cost-efficiently. By investing in an OVP, companies can unlock the full potential of online videos while maintaining complete control and ensuring long-term success.

10 TIPS FOR ENCODING AND HIGH-QUALITY VIDEO PLAYBACK

bsp-admin-1 on June 17, 2011

The community and knowledge team has scoured through search trends on our support site, numerous inquiries to our customer support team, and the forums to find out what kind of topics you are searching for and asking about. One of the trends we found is questions about encoding best practices and tips for high quality video playback.

Encoding is a very broad topic, but we’ve put together a list of the top 10 things to keep in mind when encoding your videos for upload into Brightcove.

1. Encode for Broad Device Support

In order to ensure that you have broad device support, we recommend encoding your videos to h.264. Uploading h.264 videos provides you with more ways to customize your Brightcove content, and they’re delivered with higher quality and less bandwidth than many alternative encodings.

H.264 allows for broad device support, as it provides the best options for mobile video deliver and is the only format that will playback on our HTML5 smart players. Smart players will deliver your video in Flash or HTML5, depending on your viewer’s device capabilities. This enables you to use a single Brightcove player that can deliver video in Flash or HTML5, so you don’t have to create and manage separate players for each viewer environment and your existing players can automatically load in Flash or HTML5 mode without any custom work or additional JavaScript on your part.

2. Use Multi-bitrate Streaming

If you have a diverse audience watching your videos from around the world with big differences in their bandwidth and internet connectivity, using multi-bitrate streaming is a must.

For those with higher bandwidth, a high quality (potentially even your source) video will be delivered automatically. Those viewers with lower bandwidth won’t have to sit though long buffering times, but instead will be able to watch a slightly lower quality video instantly.

On the other hand, if your videos are strictly being viewed, for example, on an internal network with very strong internet connection, you may want to simply upload one high quality video with only one single rendition.

3. Preserve Your Source File as a Rendition

If your source video file is in h.264 format, you can choose to keep your original source file as an available rendition. This option lets you retain an h.264 master that can be at an even higher level of quality than Brightcove’s highest-quality rendition.

In addition, when you select this option, your h.264 source video is available immediately, as soon as the upload is complete, and you don’t have to wait for the video to be transcoded before it is available in the Media module and in your players.

4. Capture Videos at a Constant Frame Rate

To avoid stuttering during playback, record video at a constant frame rate of 25-30 frames per second, and shoot film at constant frame rate of approximately 24 frames per second.

5. Consider the Content You’re Uploading

Factual or news type videos typically require lesser quality than an action packed longer-form video or an engaging nature film which will require much higher quality.

If you are producing screencast videos with very little action at all, other than the occasional change of a slide, be sure to export the video at h.264 at the same aspect ratio as your recording and use some of these techniques for configuring your player.

One-pass vs. Two-pass Encoding

In general, two-pass produces a better transcode than one-pass. However, a two-pass encode does take up a lot more time to perform. For videos that have a lot of motion, we recommend taking the extra time to export as two-pass. You may also want to perform a comparison test to determine if there is a noticeable difference and keep an eye out during any transitions or high motion areas. If you do not see any noticeable difference, stick with the one-pass and save some time.

6. Upload the Best Quality Source File

While Brightcove can certainly preserve the quality of your source file and create multiple different levels of renditions, we can’t create renditions that are higher quality than the source file you provide us with. We have a list of source file recommendations and export settings to help you create the best quality source file to upload into your Brightcove account.

7. Don’t Ignore Audio Quality

Most people focus on having the highest-possible image quality in their videos and ignore audio completely. However, viewers of your videos are much more likely to drop off if the audio quality drops out or is choppy than if the video is slightly lower quality.

For the most part, if a user can’t hear what is being said in a video, there is no purpose in continuing to watch it. Make sure to use a good microphone when recording your videos and consider our recommended sound settings.

Audio Setting Best Practices

  • Codec. Select “AAC” when encoding h.264 video.
  • Sample rate. When in doubt, choose 44.1 kHz or 48 kHz.
  • Bit rate. Use 128-160 kbps, or 192 kbps+ for content that’s heavy on audio.

8. Deinterlace Analog Videos

If you are working with content that was shot on tape, then we highly recommend you to select the Deinterlace Source Video checkbox when exporting to avoid any sort of interlacing effects on your Brightcove content. If your content was shot to a digital format and is not currently interlaced, then you do not need to deinterlace.

9. Modify Your Transcode Settings

If you have a professional or enterprise edition account, you have the option to modify your transcode settings directly in the Brightcove Studio. By default you have six renditions available in your transcode profile. However, if you have a particularly diverse customer base viewing your videos on different devices and connections speeds, you may want to add additional renditions (up to 10). Brightcove’s default transcoding settings provide a good baseline set of renditions that should meet the needs of most publishers and viewers.

10. Allow Video Smoothing

Brightcove players can use video smoothing to improve the perceived quality of video playback. There’s a trade-off, however, between the added quality you might get by using video smoothing and the additional CPU burden that video smoothing imposes on the client.

With higher video bitrates, the benefits of video smoothing are less noticeable. Viewers, especially those with less powerful computers, may perceive a choppier video quality due to frame dropping, which may outweigh the benefits of video smoothing.

By default, Brightcove uses video smoothing for videos with a bit rate less than 950 kbps, and does not use video smoothing for videos with a bit rate greater than or equal to 950 kbps.

You can override the default video smoothing behavior by including the optional videoSmoothing configuration parameter in your player publishing code and setting it to either “true” (video smoothing always used) or “false” (video smoothing never used).

ENCODING SETTINGS FOR QUALITY HD VIDEO DELIVERY

bsp-admin-1 on January 20, 2011

Brightcove enables publishers to stream HD content to the web. But you need to ensure you’re encoding your source files correctly to take advantage of our high-quality streaming capabilities. For those of us who think “4:2:2 pulldown” sounds like a foreign language, it’s helpful to have a simple explanation of how to deliver true high definition video streaming.

Step 1: Know How It Works

Brightcove uses multi-bitrate streaming technology to give viewers the best video quality their Internet speed can handle. This means we create up to six renditions of your video at varying resolutions and bitrates for a wide variety of internet connections, from blazing-fast T3 office lines to sometimes-spotty 3G mobile connections. Our video players detect viewers’ internet speeds and serve them the appropriate rendition of your video.

If you want to use Brightcove’s default settings, simply upload a file at the highest resolution and bitrate you have. The default settings support just about all video codecs and containers in use today, and your highest-quality rendition will be a very respectable 1280×960 (1280×720 for 16:9 formats) at about 1.8 Mbps. That said, if you’re willing to take a few extra steps you’ll be set up to deliver true HD video content through Brightcove.

Step 2: Upload in H.264 and Preserve the Source File as a Rendition

Since Brightcove’s transcoding process limits the highest-quality rendition to 1280×960 at 1.8 Mbps, the key to squeezing the best possible quality out of Brightcove is to upload your video in a format we can deliver through our players without requiring any transcoding. This format is h.264.

H.264 video can play on PCs, iOS devices, and Android devices. Given its broad compatibility across devices and operating systems, it is Brightcove’s preferred video format. As such, Brightcove gives you the option to preserve an H.264 source and add it to the video’s list of available renditions. The end result is Brightcove’s six default renditions, plus your source file just as you encoded it on your machine.

Step 3: Encode Your Source File in Web-Friendly HD

The key considerations when encoding a video for Brightcove are quality and playback accessibility. There is no reason to include a 10 Mbps source rendition when few, if any, end users will have sufficient Internet speeds to stream 10 Mbps video. Similarly, a 2 Mbps source file will be virtually indistinguishable from Brightcove’s 1.8 Mbps rendition.

Video content at 1920×1080 requires exceptionally high bitrates (between 6-8 Mbps and up) to display clearly, so it’s best to stick to a 1280×960 or 1280×720 resolution for your videos. Most viewers on screens smaller than 35″ won’t be able to tell the difference.

Finally, you need to decide on an encoding bitrate. We suggest a bitrate between 3 and 6 Mbps. Which side of that range you lean to depends on whether you’d rather sacrifice a bit of quality for greater accessibility or vice versa. Just remember this: If a viewer doesn’t have a strong enough internet connection to view your source rendition, it’s not the end of the world. Brightcove will be able to serve them one of the lower renditions our encoding engine created.

HOW TO ENCODE VIDEO FOR MOBILE USE

bsp-admin-1 on September 30, 2010

There are hundreds of mobile devices out there, and it’s basically impossible to support all of them. But the good news is that mobile devices are getting better.

Modern smartphones can actually play high-quality video, and smartphone use is increasing. That’s not to say that 3GP is over, or that everyone has a smartphone. But smartphone use is growing, and not surprisingly, smartphone users are more likely to watch video on their phones.

So if you want to support 90%+ of mobile devices, you need at least two video types: 3GP + MPEG-4 for less sophisticated devices and h.264 + MP4 for smartphones. That’s good news, really. One output video can cover all of your smartphone users: iPhone/iPad/iPod, Android, and (for the most part) Blackberry. You can include PSP, PS3, and Xbox 360 for good measure.

Of course, while one universal smartphone output can take care of most smartphone users, you can do better with multiple mobile outputs. For example, the iPad has a native resolution of 1024×768—five times higher than the 480×320 on earlier iPhones. So if you encode your video at 480×320, you’ll be missing out on the near high-def capabilities of the iPad.

Fortunately, you can target mobile devices well using a handful of standard encoding profiles. Start with the Universal Smartphone Profile for wide compatibility. Then, add in an Advanced Smartphone Profile version for the more advanced devices and round out your mobile list with a legacy profile for widest compatibility (either our Legacy Smartphone Profile below or even a 3GP video for even wider compatibility).

Note that the following defaults are the starting point for these profiles. Brightcove Zencoder uses these settings by default, but you can replicate them easily enough in whatever encoding tool you’re using.

Defaults

  • Video: h.264, Level 3.0
  • Baseline profile audio: AAC, 1-2 channels

1. Universal Smartphone Profile

This is a great starting profile for wide compatibility with modern smartphones. Plays on just about everything, though it doesn’t take advantage of the higher resolutions and codec complexity possible on the newest crop of devices.

Plays On

  • iOS: iPhone, iPad, Apple TV, iPod Touch, iPod Classic, iPod 5.5G
  • Blackberry: Bold 9000, Curve 8910, 8900, 8520, Pearl 9XXX, Storm, Storm 2, Torch, Tour, Bold 9650 + 9700
  • Android: All (?)
  • Other: PSP (3.30+), PS3, Xbox 360, web

Doesn’t Play On

  • iPod 5G
  • PSP (pre-3.30)
  • Blackberry Curve 9330, 9300, 8530, 83XX
  • Pearl 8XXX, 88XX

Settings

Defaults, plus:

  • Audio_bitrate: 128 (or less)
  • Audio_sample_rate: 44100 (or less)
  • Size: 480×320
  • Max_frame_rate: 30
  • Video_bitrate: 1500 (or less)

1b. Universal Smartphone Profile B: Higher Resolution

This profile plays better on iPhone 4g, iPad, Apple TV, new iPod Touch, Droid, PS3, and Xbox, by increasing the video resolution. The extra pixels are wasted on older iPhones though, and make for a video that won’t play on Blackberry and some Android phones.

Plays On

Everything above, minus Blackberry and maybe weaker Android devices.

Settings

Universal Smartphone Profile (above), plus:

  • Size: 640×480

2. Advanced Smartphone Profile

Newer iOS devices allow higher resolutions and higher encoding complexity (which means better compression). In particular, iPad and Apple TV users shouldn’t have to watch 480×320 video on their beautiful screens, so it makes sense to provide a higher quality version if you want to provide a good experience to these users.

Plays On

  • iOS: iPhone 4G, iPad, Apple TV*, newer iPod Touch
  • Android: Nexus One, Droid, maybe others (Note: Some users report trouble with 720p video)
  • Other: PS3, web

Doesn’t Play On

  • iOS: iPod 5G/5.5G/Classic, iPhone 3GS and before, older iPod Touch PSP, old Apple TV*
  • Blackberry: all
  • Android: others
  • Other: PSP, PS3, Xbox 360, web

Settings

Defaults, plus:

  • H264_profile: main
  • H264_level: 3.1
  • Audio_bitrate: 160 (or less)
  • Audio_sample_rate: 48000
  • Size: 1280×720 (max) or 960×640 (iPhone 4 native)
  • Max_frame_rate: 30
  • Video_bitrate: 5000 (or less)

*2b. Advanced Smartphone Profile B: with Old Apple TV Compatibility

To support older Apple TV devices, use the Advanced Smartphone Profile setting, plus one of the following.

Settings

Advanced Smartphone Profile (above), plus either one of the following:

  • Size: 960×540
  • Max_frame_rate: 24

3. Legacy Smartphone Profile

This profile plays on the last major set of H.264-based mobile devices: notably, older iPods and some Blackberries. The tradeoff is significantly smaller video: 320×240, at no more than 768kbps.

Plays On

Everything above, plus:

  • iPod 5G, PSP (pre 3.30)
  • Blackberry Curve 9330, 9300, 8530, 83XX
  • Pearl 8XXX, 88XX

Settings

Defaults, plus:

  • Audio_bitrate: 128 (or less)
  • Audio_sample_rate: 44100 (or less)
  • Size: 320×240
  • Max_frame_rate: 30
  • Video_bitrate: 768 (or less)
  • H264_level: 1.3

4. Legacy 3GP Profile A and B

Finally, a 3GP profile or two will extend support to many remaining mobile devices. Notably, you can use these on most of the same devices supported above under the Legacy Smartphone Profile. So if you’re encoding a 3GP video at 320×240, you might not need to encode another H.264 video at 320×240. Note that 3GP video support is still in beta at Zencoder. Finally, note that these videos will look terrible, but that’s the cost of supporting 3GP phones.

Plays On

Hard to say. There are thousands of types of 3GP devices, and each one is a little different. Consider these a starting point.

 Profile AProfile B
Format3gp3gp
Video_codecmpeg4mpeg4
Size320×240176×144
Aspect_modepadpad
Frame_rate155
Upscaletruetrue
Video_bitrate19252
Bitrate_cap19258
Buffer_sizeN/A16
Audio_bitrate2416
Audio_channels11
Audio_sample_rate1600016000

Summary

If you want to create mobile video, start with the Universal Smartphone Profile. For better quality, supplement this with Advanced Smartphone Profile video. For wider compatibility, add a Legacy profile or two using either MP4 or 3GP. It only takes 1-3 profiles to support most mobile devices.

Edits

Older iPhone/iPod devices ask for the “H.264 Baseline Low Complexity” profile. “Low Complexity” isn’t an H.264 standard; it actually just means “only 1 reference frame.” The jury is out on how much Apple devices really enforce this, but for true compatibility, you should probably use Baseline profile and limit reference frames to 1. You can do this at Zencoder with the new h264_reference_frames setting.

November 23, 2010: A few people have asked about Palm Pre video. The published specs for Palm Pre are very similar to other smartphones:

  • 480×320 native resolution (with 640×480 supported)
  • H.264, H.263, or MPEG-4 video
  • MP3 and AAC audio (along with a few other codecs)

If these specs are accurate and comprehensive, then the Universal and the Legacy profiles above should work on Palm Pre.

January 24, 2011: In order to deliver 3GP video as an RTMP stream it needs to be “hinted.” Add "hint": 1 to your API request to enable it.

Products

Services

FEATURES

Solutions

Resources

Company

© 2025 Brightcove Inc. All rights reserved.

Privacy
Terms & Conditions
Linkedin X-twitter Facebook Instagram Rss