Slashdot Mirror
Encoding Video For Mobile Devices?
MadGeek007 writes "I am developing an app for Android that will use many short (averaging 10-20 minutes) instructional videos. Unfortunately, I know next to nothing about encoding video. I'd like to use a codec that is supported by Android and iOS out-of-the-box. I need the videos to look decent on large mobile displays (IPhone 4, HTC EVO, etc.), and still be able to stream well on a good 3G connection. The sound quality is also important. With so many different display resolutions on mobile devices, do I need to encode multiple copies of the same video? Or can I get away with a one-size-fits-all video? Can anyone recommend encoding software, codecs, resolutions, and bitrates that would work best for this application?"
Handbrake is what I use:
http://handbrake.fr/
While it does mean you'll use up a little extra storage it is probably best to encode one version for each resolution, h.264 tends to be the standard in video these days (especially for mobile devices since they tend to have h.264 decoding hardware).
By using one resolution per device (or at least for the more common devices and then a couple of fallback resolutions) you ensure the best possible quality for the largest number of users while also avoiding wasting a lot of bandwidth streaming high-res iPhone 4-res video to some other phone just because you didn't want your video to look like crap on the iPhone.
Greylisting is to SMTP as NAT is to IPv4
For iOS pretty much the only choice is MPEG-4, H.264.
I believe Android supports it as well.
Apple actually has a decent section in their web developer section on developer.apple.com about what is supported for iOS.
The android developers site has an excellent list of supported media formats. http://developer.android.com/guide/appendix/media-formats.html The iphone 4 specifications http://www.apple.com/iphone/specs.html claims that the iPhone 4 supports AAC-LC and h.264 which android supports as well. So looks like you have an easy match for high quality as well.
As others mentioned, make it an h264 video with aac audio. I suggest using mediacoder, a free encoder with a billion options, including preconfigured iphone profiles I believe. Others suggest handbrake but I've found in the past that mediacoder looks like it has a lot more options to fiddle with. YMMV though, I've read handbrake has come a long way since ditching the "only encode DVDs" thing It used to do exclusively.
Or better just use H.264 for both.
If you wish to hit iOS H.264 is your only option. Apple has very strict requirements on applications that stream over 3g, including a 60k/s variant. (If you don't mean actual streaming but just progressive download thats different). You can look those up on the Apple developer forums.
If you're going to create an H264 version, you might as well push that to the Android devices as well.
Pretty good is actually pretty bad.
The sound quality is also important.
You say you are making instructional videos, which implies to me the audio will contain mostly speech. If that is indeed the case, then a low bitrate like 64 kbps in mono will probably suffice. Encoders like MP3 or AAC are very good at keeping speech intelligible at lower bitrates.
Pretty good is actually pretty bad.
It will use less power to play h264 in hardware then MPEG2 in software. And all of the phones will have hardware h264 decoders.
I'm assuming you're talking about web video; if not, this info won't be applicable. The 'Video for Everybody' project at Camen Design has put a lot of work into cross-platform HTML5 video, and the test page has an extensive compatibility matrix for both desktop and mobile platforms.
Be aware that if you're targeting Android, its implementation of HTML5 video is lackluster (for now; I'd expect this to get better soon). Details of the problems, and a few solutions, can be found here: http://www.broken-links.com/2010/07/08/making-html5-video-work-on-android-phones/.
I am under Ubuntu and uses QT-AVIdemux and uses MENU: Auto-> Apple-> Apple Ipod
Works everytime.
DO NOT USE THE GTK VERSION as the auto facilities are not included.
Tomorrow is another day...
As others have suggested, handbrake + h.264
But my thought is, 10-20 minute instructional videos? Especially on a mobile device?
Break it up into 2-4 minute segments. No one is going to watch a 20 minute video, and retain what was in minute 0-6. zzzzzzzzzz
Android Gingerbread Build Due Q4 with WebM
I liked my next sig a lot better
File>Export>Movie to Iphone
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Well, for Android you could always use WebM, and for iOS H.264.
Oh really? Oh what currently shipping device would that work?
If you can name a shipping device on which that would work, then mull over the battery implications of playing back hardware decoded video vs. using the mobile CPU to do all the decoding.
WebM is a great idea and it will be interesting to see if Google can push hardware makers to support it, but to suggest using it for anything that plans to ship in under a year is awful advice.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm not sure if Android supports this yet, but the best way to do what you want is to encode at a few different bitrates, and build an M3U8 wrapper which basically describes what video to use at the current bandwidth available to the device. You point the player at that file, then the player makes the choice at runtime which of the feeds to use.
I'm not sure if you need anything specific on the server side beyond encoding all the video in h.264.
Even if you can't do this for Android it's still well worth supporting on the iPhone, since someone on WiFi can have a much better quality video viewing experience than someone on 3G.
You also might consider bundling lower quality versions with the app for times when there is no network to be had - though with so many videos, it might only be practical to cache from the server or not cache at all.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That requirement pretty much restricts the choice to H.264. I think Android and iOS both have 3GPP support (not sure), and maybe H.263, but they're both rather terrible quality.
The shame is that, and don't rip me a new one for saying this, Theora is otherwise a perfect solution. Most smartphones in the last few years will manage QVGA (320x240) software-only decode perfectly fine. That means it's a baseline that will work on nearly all Android handsets and any iOS platform from 3G onwards. QVGA is a perfectly acceptable resolution, bearing in mind you want this to fit reliably on a 3G link. I'm sure many will be telling you to cram a 800x480 1mbps video down to handsets, but that's extreme overkill.
As for audio, oddly enough a baseline may be MP3. You only need 48kbit for a high quality mono stream. Any more is overkill. You can go for AAC if you really must. Again, the shame here is that Vorbis would otherwise be a perfect solution.
Summary: H.264/AAC/MP3. In an ideal world Theora/Vorbis, but sadly there's too much political shenanigans and misinformation to make that a reality. (And because of that, it's not available out-of-the-box on these handsets)
What's wrong with 320x240 (QVGA)? This is supposed to go over a 3G link, and quite frankly if it's just some instructional videos, you don't need crisp, crystal clear video. Going for low resolution also means you can turn down the 'profile' settings for the encoder, ensuring it works on a wider variety of handsets.
I think you'll be surprised just how good low resolution video works. Most of the quality difference is from codec choice, not resolution. I think most people are imagining crappy 3GPP and/or H.263 videos (old flash). iPhone 4 may have a high resolution display, but it's still only a few inches. Even the larger form factor handsets aren't big enough to warrant high resolution videos, quite frankly. We're not talking entertainment here - this is instructional.
There is no need to push hardware developers, they already make DSP chips for mobile devices that will be able to do HW acceleration for WebM. We're just waiting for software to make this happen.
I would say do this too. Can't speak for iOS but on Android a youtube link fires up the youtube app and on my EVO it goes full screen. I think it is similar on the iphone too.
Ogg Frog is designed to rip CDs into OGG format and then support MP3 and other formats. It will be based on Zoolib which Mike Crawford is working on porting to different platforms with Andy Green.
Eventually Mike will take Ogg Frog out of alpha testing and move it to beta and then a golden 1.0 release in 2020, 2023 tops. By then standards will have changed to something else but the OGG audio and video formats will be used as they are open sourced and almost everything else is someone else's or company's IP and will start suing people who use them in their applications and sell music and videos in that format. Compuserve for example came up with GIF standards as I recall and started suing so people moved to TIF, JPG, PNG, etc. PNG I believe is safe from lawsuits but it is only an image format and not an audio or video format.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I only had a buck every time I read, "No one is going to do [x] on a mobile device," over the past few years...
I have entire seasons of TV shows (Last Airbender) queued up on my phone for when I get trapped waiting somewhere and/or my son is bored on car trips, etc. It's not 2004 any more - the whole "mobisodes" trend came and went as it was discovered people don't *like* 2 minute custom-created content for the phones. They want normal length videos, and with today's large screens and relatively massive storage there's no problem with that.
-Russ
Me
Normally good advice (even the big companies don't mind the YouTube watermark, it seems), but I think he wants to sell them as part of an app so YouTube is probably out.
When they came for the communists, I said "He's next door. Take him away. Goddam commies."
Indeed -- or any of the dozens (hundreds?) of Android community websites where this question has been answered 100 times already. I'm sorry, but Ask Slashdot has gone down the tubes (or series thereof). This is a question one could Google and find the answer to in less than a minute. This is supposed to be "news for nerds", not "common questions for laymen & kdawson."
meep
That and output as H.264 which is really the only choice.
Agree. H.264 is supported, in hardware, by most of the smartphones you care about (iPhone, Nokia/Symbian and most android phones).
I've found the output from mencoder (part of mplayer) has worked across all three platforms flawlessly.
http://www.any-dvd-converter.com/
You seem to be forgetting bandwidth in your argument, and that very few mobile devices CAN decode MPEG2 in hardware.
So far it's been proprietary formats, then 3gp and now h.264 when it comes to cell phones.
I agree that MPEG2 have it's uses as a less CPU intensive codec, but not in this case. :)
Had we been talking about the best intermediary format for video editing, I'd have told you to always transcode your h.264 to high bandwidth (50Mbit) MPEG2, or something else like for instance Cineform, as h.264 is very poorly suited for editing, and not just because it's very highly compressed
For the bandwidths available for mobile phones (1-2Mbit range tops for most users) you have to go with a codec with a very high compression rate, like the h.264, especially since the devices in question do come with hardware decoders.
check http://h264.code-shop.com/trac for encodings to fix vids for Android specificly, use the provided qtfaststart >qt-faststart "$tmpfile" "$outfile"
But that way he wouldn't be promoting Free standards. So I guess it's up to him whether the tradeoff between Freedom and simplicity is worth it for him or not.
Encode your video in H.264 Baseline Profile and it will play on everything. Baseline Profile is DVD-quality, 640x480. Players with smaller screens will scale it down. The bigger HD H.264 profiles will not play on everything, because not all devices can play HD yet. Devices with smaller screens will scale the video down.
You don't get to express your individuality with a choice of codec, because video consumers only have one: H.264. If your video is not H.264, the consumer cannot see it. That is the reason H.264 exists, that is why it has that ISO/IEC name starting with an H instead of its previous name, which was Advanced Video Coding. Making a universal meeting place for video content is why we have ISO standardization of video codecs, so there is a common playback and capture codec for consumers. In the same way that you had to use MPEG-2 video on a DVD Player, you have to use MPEG-4 H.264 video on the video players has succeeded it: iPhone, iPad, Blackberry, Android, Palm, Blu-Ray, iTunes, iPod, Zune, YouTube (although they will transcode nonstandard codecs to H.264 automatically), QuickTime Player, FlashPlayer, Safari, Chrome, IE9, Mac OS, Ubuntu, various set-tops and other devices.
To stream well on 3G it will have to be very low-bandwidth. Typically, a version is encoded for Wi-Fi and a separate version for 3G.
Apple has a lot of information about video authoring and encoding for mobile devices on their developer site. Apple has forgotten more about this topic than most companies will ever know: QuickTime is the backbone of audio video authoring, MPEG-4 is a standardization of the QuickTime file format, Final Cut Pro is the most popular pro video editor, iMovie is the most popular consumer video editor, WebKit the most video-savvy browser core, and of course they run iTunes Store are the maker of the iPod. So you can follow their advice and get the job done right. Their advice will also apply to Android and other smartphones because when it comes to video they are all iPods.
http://developer.apple.com/
There is some software written for maemo called Knots2 (cf. http://wiki.maemo.org/Knots2) that does a pretty decent job of encoding a stream starting from any type of format to something that can be watched natively on the device or with a browser.
It's what I use to access MythTV from my N900.
No idea on how hard this would be to port to Android, though.
I agree - it does seem to be odd to have a rather specific development question for one particular platform as an Ask Slashdot. I have plenty of questions I ask, for things like Symbian/Qt and Windows/DirectX development that I do in my spare time, and I'm sure plenty of other Slashdot readers do on various areas, but I post to an appropriate development forum (e.g., Nokia forums, GameDev). If every development question about a random platform they were development got asked, the front page would quickly get bogged down with endless questions...
I'm no expert on this, but http://wurfl.sourceforge.net/ has a very extensive database on mobile device capabilities, so you might find what you need there.