Blog Archives: August 2010
Sharing Plugin Now Supports Skinning and Playlists!
by LongTail Video on 2010-08-30 14:13
We've released Version 2 of our Sharing Plugin, compatible with the JW Player for Flash v5 API. Sharing is most often used in viral sharing of a video. The plugin can display a screen to share an embed code of the video, similar to YouTube or Vimeo, or share a share link of the video, e.g. the URL of the page where the video is.
Version 2 of our Sharing Plugin now supports the following features:
Skinning
As mentioned above, Version 2 of the Sharing Plugin supports PNG skinning - the buttons and the screens can now be skinned. We currently have 4 compatible skins, in our library , that will work with Sharing v2: Glow , Modieus, Bekle, and Stijl. Below is a screenshot of what the Sharing Plugin looks like, when used with PNG Skin, Modieus. Check our our live example here.
Playlists
Now, in addition to setting the sharing option in the embed code, two sharing options can also be set per playlist entry. Watch this example of the Sharing Plugin working with Playlists:
The JW5 API
Version 2 of the Sharing Plugin is compatible with JW Player for Flash v5 only. We switched from the 4.x to the 5.x plugin API. As of now, this version of the plugin cannot be loaded in the JW Player for Flash v4. To ensure ease-of-use, we've created new user documentation to support the Sharing Plugin. Check it the new Sharing v2 User Documentation on our Support Site. Here, we dig deeper into how you can use Sharing to embed directly into popular social media, such as Facebook.
If this is your first time learning about Sharing, visit our AddOns Library to learn how to use the Sharing Plugin with your JW Player.
Transcoding Best Practices
by Daniel Taylor on 2010-08-30 13:10
Core Wisdom
Transcoding is something of an art form whereby one must balance dozens of requirements, formats, parameters and more. Sometimes this can seem daunting for those that just want to know a little more information or want to step into the world of digital media. What follows are a culmination of best practices developed while building Bits on the Run over the last few years. This is by no means an exhaustive list but should give a good idea of some things to watch out for or remember after reading the basic Overview of Transcoding.
Quality vs. Bitrate
Always encode for a specific quality rather than relying on bitrates. With bandwidth availability increasing across the board there is no need for using a target bitrate unless you are targeting a specific limited device or the quality you wish to achieve is unrealistic within your bitrate constraints (in which case try lowering your quality expectations). To give concrete example using constant rate factor to encode H.264:
ffmpeg -i infile.avi -vcodec libx264 -vpre default -crf 21 -acodec libfaac -ab 128k output.mp4
The following two videos also demonstrate nicely the difference in bitrates required for the same dimensions to get the same visual quality from two very different videos (with a difference of almost 800kbps!) These were produced by a command very similar to the one above.
Avatar Trailer 720px wide: 1800kbps
Diggnation excerpt 720px wide: 1050kbps
As can be seen above these two very different videos can look the exact same quality with very different bitrates. It is a good example of how specific bitrates are not a good indicator of quality given changing dimensions, framerates, picture complexity and complexity of movement over time. When dealing with a large set of videos of varying qualities, sizes and complexities it is a good idea to always use constant quality settings.
Avoid Upscaling
There is no reason that you should ever scale video dimensions to be larger than the original input. You cannot get better quality by transcoding, and scaling up will do nothing but blur the video. The exception to this rule is of course a device with strict dimension limits, such as a phone where your video absolutely must be 800x480 pixels. Also keep in mind that video players will scale video to fit screens for you, so there is no need in general for you to do so during transcoding.
Upscaling 320px wide video to 480 and 720 pixels blurs the video
Provide Sane Defaults
Try to always provide sane defaults that offer a good compromise between quality, size, transcoding time, etc. Be realistic and remember what devices and available bandwidths you are targeting. If your audience is mostly low-power phones and netbooks then don't encode 1080P content and expect them to be able to play it. Don't listen to random bloggers (including me) and use your own eyes and ears to choose defaults that work for you and your customers.
By default things should look acceptable
Less is More
While this is really a general philosophy of Bits on the Run, this is extremely important when it comes to transcoding. Users will hang themselves if given enough rope. We've seen impossibly high and ridiculously low bitrate selections, dimensions, and other options. Along with sane defaults you should try to make the options as simple as possible, but provide enough to appease power users.
Handbrake: too many complex options
Bits on the Run template options: simple
Most People Just Want Stuff To Work
As much as you might want to show up to the second statistics on transcode jobs and exact reasons for failures or issues, try to resist the temptations. Most people don't care, get confused, and really just want stuff to work. Focus on preventing failures and making sure all media transcode properly.
Services
The following best practices pertain more specifically to services like Bits on the Run where many files are processed by a service-type backend.
Steer Away From Complex Queue Logic
You are likely to want to use really smart, really clever queue processing and management logic to make a transcoding cloud behave in the most efficient manner possible. My advice: don't. Stick with simple logic that won't get out of hand and treats most users fairly. Simple, fast, and easy to understand is key. You will never hit 100% efficiency and the more complex the queue logic becomes the harder it is to predict how small changes will affect the system. A good starting point for the logic is as follows:
- Process files from as many different people as possible
- Process as many files concurrently as possible within reason
- First come, first serve (FIFO)
Speed and Quality are a Trade-off
When processing a lot of media on a farm of servers you need to find a compromise of quality, speed, and the number of servers in the farm. Using the slowest and best quality is not worth it in such a situation, because this costs you servers and time. The time spent encoding with a preset to save an extra 3% bandwidth has the potential to scare a customer away to faster services. Err on the side of too little quality or too few servers processing and they may leave as well.
Play Well With Others
Using Free and Open Source software like FFmpeg and libx264 is highly recommended. You get a community of video experts helping you, and they can be very friendly when you try to help back. You save money by not licensing large proprietary tools and you get some of the best quality output in the industry.
At Bits on the Run we regularly make use of the above as well as many other open source projects. Much of the transcoding system is written in Python. It's a great way to glue various components together, interact with databases and APIs, and to provide interactive object-oriented shells for job and queue management.
Conclusion
Hopefully this will give you a good idea of some of the best practices to follow when transcoding media after understanding the basic Overview of Transcoding. Remember that quality is more important than bitrate, unless your application requires a specific bitrate. Upscaling should always be avoided when possible. Provide sane defaults for users and make sure things work well without needing tweaks. If you have a queue system, keep it simple to save yourself future headaches. Have any other tips to leave? Add a comment below!
All copyrighted content is owned by the respective copyright holders and used in this post under fair use to show examples. The Avatar trailer and images are copyright Apple, Inc. The Diggnation exerpt is copyright Diggnation and Revision3. The Big Buck Bunny image is copyright Blender Foundation and used under the Creative Commons Attribution license.
Introducing the Open Video Ads Project
by Meagan Palatino on 2010-08-24 11:47
About Open Video Ads
Open Video Ads is an open source initiative dedicated to the development and distribution of Flash (AS3) and HTML5 technology, that enables the implementation of IAB VAST and VPAID compliant Video Players.
Check out this live example of OVA in Action:
A
companion ad
will appear
here
Some of what we think are the most attractive features of OVA are its:
- VAST-compliant ad server communication
- VAST-compliant tracking of video ad performance
- Support for a wide array of ad units
- Flexible configuration & scheduling options
- Overlay advertising using Images, Flash, Text or HTML
- Playback using HTTP and RTMP protocols
The OVA plugin works with the JW Player for Flash v5, JW Player for Flash v4, and Flowplayer. If you have a custom video player use the OVA for AS3 VAST framework to turn your own video player into a IAB compliant, "advertising enabled" player. For developers, looking for the product roadmap, or more technical help, please visit the OVA Developer Site.
Take a look for yourself, and browse the comprehensive documentation, or support community forums on Open Video Ads.
Securing Your Content
by Zachary Ozer on 2010-08-09 08:51
Since the Napster trials in late 1999, content producers have become increasingly aware of intellectual property issues. Even then, the Recording Industry Association of America (RIAA) tried to send the message that the Internet had made widespread piracy possible, and that it was leading to enormous losses in revenue for the music labels and artists.
In addition to direct losses from piracy, content producers today face an even greater challenge when it comes to controlling how their work is distributed. It's quite common for anyone who admires your video to simply repost it on their site. Generally, this isn't a big deal - it's flattering and it provides a mechanism for increasing the visibility of your work. Unfortunately, this redistribution can also lead to a poor perception of your work and it can also dramatically increase your web-hosting costs.
With that in mind, I'd like to introduce "The Golden Rule":
Anyone who can watch your video can steal your video.
It is very easy to become paranoid about protecting your content. We'll try to offer a few simple steps that you can take to defend against most unauthorized uses, however you will need to take into account the technology you have available, the time amount of time you can invest in setting everything up, and the amount of money you're willing to spend.
Security for Individuals
The most basic form of protection is obfuscation, which can be accomplished on the web with JavaScript. In order to watch your video, a viewer's computer must first know its location. As a result, the location is generally printed right in the source code of the page with the video. Using JavaScript, it's possible to do some complicated text replacements so that the actual address isn't immediately visible. As easy and useful as this seems, most web browsers offer an interface for inspecting web traffic, which will always display the non-obfuscated address, thus rendering this solution ineffective.
This is a prime example of client-side security, which means that the actual security measure is written into the software running on the user's computer. However, given the limitations of this type of security, most content protection relies on a completely different type of security: server-side security. Server-side security is much more reliable as regulates access at the source and only relies on hardware you control.
The most widely used form of server-side security is web authentication. If your web browser has ever popped up a dialog box and asked you for a username and password, then you've used web authentication. The best part is that most web common servers have this functionality built in, which makes it incredibly cheap and easy to implement. In fact, configuring web authentication can be as simple as creating a text file. But be careful - it's very easy to give users access to content they shouldn't be able to see and it can become time consuming to manage. In fact, web authentication is relatively insecure in practice as individuals often share their usernames and passwords. For this reason, it's not recommended in an organizational setting, but it's perfectly appropriate for sharing between a few trusted individuals.
Security for Small and Medium Sized Organizations
Just like web authentication is the de-facto security mechanism for individuals running their own web servers, temporary URLs are the de-facto security mechanism for organizations using a content delivery network (CDN). Sites using temporary URLs generate a new link to a video file every time a user loads the page. This link is only valid for a short period of time or a limited number of accesses. Once it has expired, individuals who want to view the content will have to request a new link. This makes it incredibly effective at protecting against leechers (people who copy-and-paste your embed code into their site), since the link that's copied will eventually expire. In fact, many video hosting services, such as Bits on the Run and Amazon Web Services' CloudFront readily promote this.
Temporary URLs become even more effective when uses in combination with encrypted streams. This prevents malicious individuals from intercepting web traffic on your network in order to reconstruct the video, since only the viewer at the end will have the credentials to decrypt the video. The most commonly used implementation is Adobe's Flash Media Server (FMS) with encrypted RTMP. While individuals have created software that allows viewers to extract the video from these streams, they are not widely used, in large part due to legal action by Adobe. Both Bits on the Run and Cloudfront offer encrypted RTMP streaming via FMS, and it works in combination with their temporary URL mechanisms.
Security for Large Organizations and Institutions
No discussion of content security would be complete without mentioning digital rights management, or DRM. While DRM is the most secure form of content protection, it's really only suitable for large organizations, owing to its cost and complexity. DRM solutions use special cryptographic algorithms when encoding to ensure that only individuals with the proper credentials are able to decrypt and view the content, and often only after being authenticated by a DRM server or for a specified period of time. Not surprisingly, vendors charge a pretty penny for the software ($40,000+ in licensing fees are not uncommon), and this says nothing about the cost of maintaining and running the necessary server hardware.
Additionally, DRM blocks many legitimate users, especially those using mobile devices. For example, Apple's DRM solution for audio, video, and eBooks, FairPlay, only works on Apple devices or computers running QuickTime. Microsoft's PlayReady DRM has been supported by their cross-platform Silverlight player since version 2, but only after they abandoned their PlaysForSure DRM solution, stranding many users with unplayable content. Finally, Adobe's Flash Access DRM has only recently become available to clients with the release of Flash 10.1, so it's ability to deliver secure content to clients is still limited.
Conclusion
Hopefully you are now aware of the need to protect your content, and feel equipped to make a decision about what type of protection best suits your needs. Clearly, the challenges associated with securing original content online have continued to increase as people have sought out ways to circumvent protective measures. And so while technical solutions to protect intellectual property continue to grow more complex, you should always remember one thing: that your videos are your property and you have a right to protect them.
Follow us on Twitter: 