True Cloud Hosting Is An Expensive Proposition

The 'cloud' is said to be the future, but it's an expensive prospect if our experiences are anything to go by.

At TVE we use providers in the UK, US and Germany and the average cost, all inclusive for 1Gbps, 56GB RAM, hex core and no bandwidth cap is £370 per month. We can scale using caching using our CDN provider, who provide bandwidth at rates we cannot disclose, but at large scale can easily undermine any of the companies mentioned below. This price includes all software from Microsoft.

I've just costed a similar setup on Microsoft's Azure and the cost, based on our current usage, came to £794.46. Rackspace quote £730 a month for their nearest equivalent, but without any software such as VMWare, Windows Server and SQL Server. Amazon pricing is, in my opinion, impossible to estimate, but comes in at around £7,000 without the database licence, according to http://tco.2ndwatch.com.

None of the above offer managed services, so with all of them you will need to also employ staff or consultants who have experience of deploying into the cloud.

Services offering sub £500 a month core functions in the cloud therefore provide huge cost savings, especially if that sum includes storage and bandwidth.

I encounter a lot of startups who select the cloud for their services, which makes sense if you have no traffic, but as soon as you have volume, the cloud makes no sense for hosting unless you are building your own cloud environment.

The 'cloud' has a long way to go to become a cost effective proposition, notwithstanding issues with security and reliability.

Delivery v Reception

When you transmit a channel on traditional platforms you have reasonably predictable costs. These involve MUX costing, satellite transmission costs and carriage costs. For example, if you want to get your channel onto Sky you will need to pay that company around £100k to appear on their EPG and then pay a satellite company around £400k to beam your signal. Then come the costs of scheduling, playout, ad insertion, etc.. But once you've done this there are no inceremental costs per viewer.

On broadband you can buy a package that will get you into every properly broadband enabled home in the UK for next to nothing. My own company will do this from £300 a month. But the flip side is that you have a cost per viewer, based on the bandwidth they use, ie how much of your programming they are watching and at what data rate.

These are now the two models for TV delivery.

If you're generating, or are likely to attract under 100,000 regular viewers the former model is madness. You'll quickly go bust.

But if you can generate 2,000 viewers for your online channel at any one time, you may well have a viable business model.

This is the difference between delivery charging and reception charging.

For example, every movie a viewer watches in rasonably lo res will cost around 1p to an online broadcaster such as Netflix. but a HD version may cost 7p. If you pay Netflix £10 a month and watch 90 hours a month the cost is around a pound in HD.

Creating Channels in Facebook

Adding your video channel to Facebook is easy - just take the code from the Player Builder and cut and paste it into a Facebook tab:

Here are the instructions from Facebook on creating a tab based application to host your code:

Using iframes in Page Tabs

Many useful applications have been built for Facebook Pages like BandPage for artists to share their music with fans andShop Now to help Pages sell merchandise on Facebook. As of today, you can build your Page Tab apps using iframes rather than FBML. This means you can now build apps that run across Facebook (including Pages and Canvas applications) using the same simple, standards-based web programming model (HTML, JavaScript, and CSS). In addition, you can easily integrate social plugins and the Graph API within your tab.

How to Add an iframe Page Tab

Enable iframes by editing the Facebook Integration settings on the Developer App: 

Specify a Tab Name and a Tab URL that is loaded when the user selects your Tab on a given Facebook Page. Finally, to add the app to a Page, an admin of the Facebook Page must navigate to your app's Profile Page and select "Add to my Page.” You can see step by step instructions in our guide.

Updated signed_request

When a user lands on the Facebook Page, she will see your Page Tab added in the left-hand menu. When a user selects your app in the left-hand menu, the app will receive the signed_request parameter with one additional parameter, page, a JSON array which contains the ‘id’ of the Facebook Page your Tab is hosted within, a boolean (‘liked’) indicating whether or not a user has liked the Page, and a boolean (‘admin’) indicating whether or not the user is an ‘admin’ of the Page along with the user info array. If a user has authorized your application, the signed request will also contain an access token and the user id for the current viewing user so you can personalize your application for them.

In addition, your application will also receive a string parameter called app_data as part of signed_request if an app_data parameter was set in the original query string in the URL your tab is loaded on. For the Shop Now link above, that could look like this: "http://www.facebook.com/MollySimsOfficial?v=app_135607783795&app_data=any_string_here". You can use that to customize the content you render if you control the generation of the link.

{
   "algorithm":"HMAC-SHA256",
   "expires":1297328400,
   "issued_at":1297322606,
   "oauth_token":"OAUTH_TOKEN",
   "app_data":"any_string_here",
   "page":{
      "id":119132324783475,
      "liked":true,
      "admin":true
   },
   "user":{
      "country":"us",
      "locale":"en_US"
   },
   "user_id":"USER_ID"
}

The result should look something like this: https://apps.facebook.com/vzfbpsurf/

Going Live - How To Stream Live Events

Streaming from a PC to the internet is relatively straightforward, but if you want to take a multi camera shoot to the world over the internet things get a bit more complex.

Here's a step by step guide on how to do it and what you'll need.

First of all you'll need all of the traditional trappings of a live production which agree likely to include two or more cameras, a live sound feed, a vision mixing desk and possibly an audio mixing desk.

Of course there are cables and Comms and tape decks for layoffs and for inserts and a graphics or caption generator.

So far, so traditional. Next comes the difficult part. You will need to get the feed from the mixing desk to the encoding software on your encoder.

Generally this is achieved using a video card or a dedicated hardware box from companies such as Pinnacle, Viewcast Haupauge and Blackmagic. You can also use the existing video and audio inputs of a computer.

Depending on the connections used, you may have separate video and audio connectors. Some of the options include component video, composite video, SVHS and HDMI.

There are some packages that can offer both mixing and encoding, for example AVTake. There are also hardware mixer with built in streaming from companies such as Roland.

Once the signal is received by the encoder (usually a Mac or PC) then you will need to use software to encode the signal for the internet. The most commonly used software is Adobe Flash Media Live Encoder. This is free. However, there are some other applications out there which offer more advanced options, such as the ability to play in video files and add graphics downstream of your mixer output. These include Wirecast and VidBlaster.

To link the encoder with a media delivery network such as our own VidStorer, you will need the following parameters: primary streaming server URL, secondary streaming server URL and stream name. You may also need a username and password to secure your stream. Obviously you'll also need the URL for the resulting stream (or multiple URLs is the stream is being transcoded.

There are other settings you need to configure such as the video encode settings and the audio settings.

These are entered into the AFMLE interface and you press Start. 

There are many nuances to the setup of the encoding, including the need to buy an MP3 plugin and encode using MP3 audio if you want to segment and deliver your stream to iOS devices. Your media delivery network partner should be able to help with the detail.

The MDN will probably also be responsible for the transcode of the feed to formats such as XML for adaptive bitrate and M3U8 for HLS delivery to iPads and iPhones.

Finally, you need to play out the feed. This involves setting up a player that can take and render the streams.

At TVEverywhere we have our own VZPlayer which you can set up using drag and drop and this will automatically roll between the various streams required depending on what device it's playing on.

And to answer an often asked question: no, unless you're a handful of NGOs, you cannot stream live to YouTube at the time of writing this.

If you need any help with your live event, please don't hesitate to contact info@tveverywhere.co.uk.

Optimising Video for Web & Mobile

Recently we've been confronted by a number of clients who haven't been used to encoding video (rather they have depended on server side encoding for their content).

Encoding is an art, not a science, and just like movies used to have graders, modern video production companies should have encoders who are skilled in optimising content for delivery over the internet to the web and mobile.

This is a field where drop downs in Final Cut Pro and a little knowledge are hugely dangerous things. The value of a well encoded video over a badly encoded one is immersurable.

And saying that 'YouTube does it well' is disengenious. YouTube encodes for a particular delivery profile, which does not necessarily optimise for mobile, set top boxes or platforms like Facebook.

But, as a broad guide, we would recommend using Handbrake, which has versions for Mac, PC and Linux.

After much recent experimenting we can barely see a difference between a 500Kbps and 2Mbps delivery using the following settings:

Container: MP4
Picture:
Width: 720
Height: 400
Cropping: none
Aspect Ratio: preserve
Anamorphic: none
Modulus: 16

Video Filters: None

Video: H.264 baseline using MPEG4 part 10 (not 2! And not Ffmpeg MPEG4 - this may result in either no video appearing in some browsers, or much lower quality)
Framerate: as source
2 pass encoding (takes more time but does make a difference of around 15% in quality we estimate)
Avg bitrate: 500Kbps

Audio: AAC (faac) Dolby II ProLogic 64Kbps 44.1 Mhz

Select web optimised or fast play or make sure Moov atom is at head, along with all metadata
Select streaming over download mode for scrubbing
Enable 5G Select No-DCT decimate for Android playback

This video will deliver HD over very poor bandwidth to most contemporary devices.

How 'Apple Streaming' Works

One of the major issues with video delivery over the internet is that it is based on patents going back a decade or more, and the industry has already seen its fair share of lawsuits regarding patent infringements.

This, perhaps, is the reason that Apple took a very different approach to delivering video to its iOS devices.

If you're looking to do live or adaptive streaming you have to use a format called 'M3U8'. Tis started life as an indexing file for MP3 video files, but was adapted by Apple as a means of splitting up and then reforming something called an MPEG-2 transport stream.

MPEG2 is the traditional codec used by broadcasters, and much of the television you will watch will be in this format. It isn't widely used in internet TV since the file sizes tend to be very big and the compression isn't very effective at lower bitrates (hence the popularity of MP4, or MPEG-4 for internet delivery).

Another objective that Apple seem to have set was to ensure that video delivery can be handled over port 80 using http. In other words, that it could travel using the same route as an old web page, hence making it more widely available in a world where 'reserved ports', such as 1935 for rtmp, are blocked by firewalls and the like.

The way it works is that an input stream is transcoded, or rather 'split up, into thousands of individual files with the extension '.ts'. These can carry the signal at multiple data rates, hence allowing for the data rate to be dynamically increased or decreased according to the viewer's available bandwidth. All of these files are then 'managed' by the index, or M3U8 file, which knows how to reassemble them and to adapt the stream.

It's actually very similar to the way the delivery of traditional browser based content works over the world wide web using http, but it is a very strange and rather crude approach to video delivery.

However, it seems to work pretty well. There are exceptions - sporting events, or events with a lot of movement, or when the adaptive rates are set too close together and the stream cannot 'adapt' quickly enough.

Another issue is that the setup of equipment to output M3U8 is far from easy - most of the tools available to do this are command based LINUX applications that require a fair degree of experience to use effectively. But gradually I'm sure we'll see these being automated and built into existing encoding solutions.

Delivering Live Mobile Video

Mobile video is a difficult subject, and mobile live video is even more difficult. The range of devices, networks and supported protocols are immense.

The first thing to do is to be pragmatic. Outside of very good 3G coverage, which is sparse, and 4G networks, which are rare outside of Asia and some American conurbations, WiFi and WiMax are really basic requirements for delivering any kind of reliable video to mobile devices.

Another basic problem with mobile phones is that they are, er..., mobile, and reliably handing over data services from cell to cell (or from one WiFI connection to the next) is a tough thing to do. So, the second things is to be stationary.

So, presuming you're standing still with a decent connection, the next thing to worry about is the device you're holding in your hand. If it's more than a couple of years old, and isn't a 'smartphone', then you should again probably give up. There is a very steep diminishing law of returns in trying to reach all mobile devices.

Older handsets primarily used the rtsp protocol and a format called 3GP, or H.263. The rtsp protocol isn't good at high data rates and the 3GP codec means you have to support yet another format. (You can stream H.264 over rtsp, but the devices often have no means of playing this back).

So, let's move back into the modern age.

Today there are five broad platforms you need to support:

• iOS - the Apple operating system used on iPads and iPhones
• Android - the wildly popular open source platform from Android
• Symbian - the underlying OS used by Nokia (and certain other manufacturers)
• Windows Mobile 9 - the Microsoft mobile OS used by a variety of manufacturers
• Blackberry OS - the platform for the eponymous devices favoured by businessmen and texters alike

Unfortunately, each one of these devices requires a slightly different approach for delivering live video, which ostensibly means taking a live feed or simulcast and encoding it into a number of formats and then delivering it over a number of different networks. Then comes the really tough bit - scaling the solution. Finally, there are the issues of detecting the device being used and providing a playout environment - a player, navigation and associated functions and applications such as voting, tweeting and sharing.

Over the coming weeks we're going to cover delivery to each of these device platforms, as well as looking at on demand delivery of video.