Interested in using an HTML5-capable player on mobile devices like the iPhone, iPad, or Android devices? We’ve just unveiled this new script that works with Castfire Flash embeds to turn them into HTML5-friendly goodness.

Simply add this code to the header of your page, and you’re good to go:

<script type="text/javascript" src="http://static.castfire.com/media/js/html5ify.min.js"></script>
	<script>
		Castfire.html5ify({
			ios_ext: "myios.m3u8", // Profile for iPhone, iPod touch, iPad
			h264_ext: "foo.m4v" // Profile for Android, webOS, Blackberry
		});
	</script>

Any questions? Hit up support@castfire.com and we’ll answer them for you, or leave a comment on this post.

If you have been following the Castfire status blog then you have recently seen several updates involving backend changes for the Castfire API. I want to share with you how those changes will manifest for Castfire clients.

There are six upcoming API key enhancements that fall into two general categories.

1. Unlimited API keys
2. API key names
3. Ability to change an API secret
4. Ability to delete an API key
5. Limit access to specific API methods
6. Limit the access to specific content producers

API key management
API keys will be decoupled from a user login allowing for a network to create unlimited API keys. Separate API keys can be created and assigned to a specific task or third-party. For example, if you are working with a digital agency like Digitaria, an API key can be created and shared with just them.

The API key can also be given a name, such as “Digitaria” and if needed the API secret can be changed or the API key can be deleted easily in the Castfire CMS.

API key access restrictions
Keeping third-party integrations in mind, API keys can be restricted to one or more API methods. For example, if Digitaria only needs details about existing shows, the API key can be limited to the shows.getDetail API method. If later on, the ability to set show tags is required then access to shows.setTags can easily be added in the Castfire CMS.

Restrictions also encompass content producers, allowing for API keys to be restricted to one or more. For example, if Digitaria wants the ability to set foreign keys on all shows in the “News” content producer, an API key can be created that only has access to this content producer and the only the shows.setDetail API method

These upcoming API key enhancements will make API key management easier, give control over access restrictions and allow for more flexibility when integrating Castfire with third-party vendors.

In June of 2009, Apple introduced a new video format that provides adaptive bitrate over http.  If those words don’t sound like they should go together – or in that order – don’t worry. It’s actually not as complex as it sounds and is a really cool technology.

Adaptive bitrate allows the quality of the video to adjust depending on your internet connection speed. The faster the connection, the better quality the video will be. While it has been executed in a number of ways on the desktop, this is the first implementation for mobile devices. Additionally, the implementation uses a standard http connection – a very basic building block of the internet. This protocol is very easy to scale and requires no additional software.

While the adaptive bitrate does have advantages, there are three specific disadvantages for publishers:

1. It requires quite a bit of transcoding, as you need to transcode a minimum of 5 times per episode. If you chose to do separate profiles for iPad and iPhone, there are 12 or more transcodes required.
2. The only tool Apple provided for transcoding is a command line tool for OSX.
3. The spec is quite unfriendly to advertising!

Castfire utilizes a custom transcoding engine and queue that distributes the work across many different processors and servers. We are able to quickly divide the workload across available machines to process as quickly as possible. The queue enables each client and output profile to maintain a different priority to ensure that the most important episodes and profiles are completed as quickly as possible. Since Castfire acts as the origin server for your CDN, there is no need to be transferring all of the files between servers or to your desktop – it is completely automated.

Rather than tinker with the encoder from Apple, we built our own encoder for our LAMP infrastructure. We have now transcoded over 1600 hours of http adaptive video — almost 2 years worth — using our custom encoding solution. We are extremely happy with the quality and the performance of it.

Lastly, we have utilized our existing infrastructure, that enables ad insertion from any VAST enabled ad server, to allow publishers to monetize ads in the http adaptive format. Clients like CBS Mobile and the Washington Redskins are using this today to monetize videos across all of the iOS devices.

If you would like to view the http adaptive profiles from some Castfire customers, check out:

• CBS News iPhone App
• Washington Redskins TV (on iOS devices via html5  in your browser)

API integrations are a major focus for Castfire, with many of our clients never logging into the CMS to manage their solutions. Our REST based API allows for full control of the platform from website CMS’s, digital asset managers or backend systems. This follows with our philosophy of handling all of the details around publishing audio and video  allowing you, the publisher, to focus on content and audience. The API currently has 37 different methods to have complete control over your publishing solution.  To make the process of integration even easier, we are releasing foreign key functionality.

If you are a developer, you can skip directly to our API docs.

If you are not a developer, here is a non-technical description:

You have two books in your library and you have numbered them:

1. Harry Potter and the Philosopher’s Stone
2. Harry Potter and the Chamber of Secrets

You always know that book #1 is Harry Potter and the Philosopher’s Stone and #2 is Harry Potter and the Chamber of Secrets.  These, in essence, are your primary keys. They are unique to both books in your library.

Now, you loan your books to your friend, Tom, who has a library of 1,000 books. He also numbers his books from 1 to 1,000. However, books #1 and #2 are:

1. The Tower Treasure
2. The House on the Cliff

If you were to speak with Tom about book #1 (his primary key), he would think you are speaking about The Tower Treasure and not Harry Potter and the Philosopher’s Stone – quite confusing. You would have to remember when speaking to Tom, your books are #1001 and #1002 in his library.

To you, #1 is your primary key and #1001 is your foreign key. To Tom, #1001 is his primary key and #1 is his foreign key. It gets hard to manage!

What if Tom always knew, when speaking with you, that your book #1  is actually his book #1001?  And your book #2 is actually his book #1002? It would make life a lot easier as you don’t have to keep track of his keys.

That is – in very basic terms – what we have released in our API. Instead of using our show_id (our primary key) when talking to Castfire via the API, you can use your primary key to reference the show. It makes integrations with 3rd party content management and digital asset managements systems even easier. There are less keys to be stored in your system.

I am impressed if you have made it this far! This may sound esoteric, however, it lowers the burden of system integration a great bit allowing for faster implementations. If you have questions regarding our API, feel free to contact support (support@castfire.com, web).