iPhone/iPad App Development Learnings: Building a Video App with HTTP Live Streaming
by Huntley in General / 03.30.11
Many folks ask us what’s involved with putting out a video app for the iPhone/iPad. They’re curious how and if videos need to be transcoded (e.g. differently than when you’re preparing them for web distribution), how to deliver videos via 3G versus Wifi, what the monetization options are, etc.
We all know that Flash doesn’t play well with the iPhone/iPad. That said, this limitation (unless you’re in the Steve Jobs school of thought) is something that is pretty easy to work around at this point with other video formats. MindBites, for instances, transcodes all uploaded videos into two formats. For each format, we create two different videos. Thus, after an uploaded video runs through the media processor, we end up with four videos - 2 are preview length and 2 are full-length. Within each pair, we have one MP4 file (which we use for downloads [if allowed] and delivery to iPhone/iPad/iTouch) and one FLV (which we use for delivery to traditional browsers). Thus, video on iOS devices is pretty straightforward to handle through the browser on the device if you have a video person that knows what they’re doing.
However, Apple throws some additional wrinkles into the mix if you’re dealing with the App Store. Generally speaking, if you have more than a very brief video clip, you won’t be able to allow users to just download all of the videos included in your app with the app bundle that they download following purchase from the app store (as there are limitations in how large these bundles can be). Thus, you’ll have to figure out a way to serve these files to the application, and you’ll have to store them elsewhere. That’s not too tricky in and of itself, but the tricky part comes in if you want to allow viewers to stream the videos over a 3G connection.
To do this, Apple basically requires you to use HTTP Live Streaming. Using this approach, you’ll be able to deliver video over 3G connections (as well as wifi), but you’ll add a considerable amount of complexity. Thus dealing with streaming video over 3G for an iPad/iPhone app isn’t something that someone outside the video space will be able to easily figure out. For each video file, you’ll have to break the full-length video into segments (Apple recommends 10 second increments as the sweet spot and wouldn’t allow you to go much longer than that). For each 10-second increment of content, you’ll have to have 4-5 different versions of the file that have varying bit rates. One file has to have a bit rate that has 64 kbps bit rate. This is super low and will be your cellular fallback stream when the connection is very poor. You won’t have video on this stream - you’ll either be able to have audio-only or perhaps audio-only with a static image. The app then detects which 10 second stream to pull and deliver at appropriate increments based upon the connection speed at that point.
Encoding settings are also a bit tricky - if you want to support older versions of iPhone or iPod Touch (e.g. iPhone 3G), you’ll want to use H.264 Baseline 3.0 Video for compatibility reasons. If you want to constrain devices for your app, you can move up to Baseline 3.1. That said, it’s important to note that device limitations need to be submitted in the app binary. You cannot re-submit a binary later that makes the app more restrictive (for obvious reasons - e.g. it’s not cool if someone with an iPhone 3G bought your app and then you added a device restriction in an upgrade that makes it not work on their phone).
Thinking about building your own iPhone/iPad video-based paid app? We can probably help you out with it. Contact us if you’d like to talk through what you’re thinking!