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?"

Comments

Handbrake

[jacoplane]

Handbrake is what I use:

http://handbrake.fr/

Re:Handbrake

[SquarePixel]

That and output as H.264 which is really the only choice.

Re:Handbrake

[ThePengwin]

That is why AutoGK was made (http://www.autogk.me.uk/) However, going through the more complicated process gives you more options.

Re:Handbrake

[jo_ham]

Who is the ignorant one? He asked specifically for a format supported by both Android and iOS4 - that pretty much means h.264 unless he delivers two different videos to the two platforms, and if you can get decent performance from one format that both support, why bother to make it hard for yourself? Presumably you will also want to target hardware video decoders where possible, which also lends itself to h.264.

If the ideology behind using a format other than h.264 is that strong, he shouldn't be developing for iOS 4 in the first place.

Re:Handbrake

[squiggleslash]

This is why you should store all of your movies in a lossless format somewhere and then just re-encode them for yout portable devices ;-)

Multiple versions

[mikael_j]

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.

Re:Multiple versions

[mikael_j]

Well, 480p isn't high enough to match the resolution of the iPhone 4 and it would have to be upscaled which looks significantly worse than native resolution (it does, really, there are plenty of users who dislike this even if you happen to be one of the loudmouths who claim it looks "just fine").

Obviously higher res video needs higher bitrates to look good.

And finally you don't have to waste bandwidth by streaming the same 960x640 high bitrate video to every user just to make sure that the iPhone 4 users don't get a video that looks like crap on their device. You also lower the risk of having lower end devices choke on videos with a bitrate that's too high for them to handle.

Supported media

[LiENUS]

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.

mediacoder

[ceraphis]

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.

Re:mediacoder

[Warll]

It should be mentioned that MediaCoder is in the ffmpeg hall of shame: http://www.ffmpeg.org/shame.html (I cannot link any more direct because ffmpeg's bug tracker uses a self signed cert)

Judging from the related bug tracker the author appears to almost be playing dumb.
I agree that it is a fine program and I myself have suggested it to non-tech savy friends, but that doesn't mean I feel good about doing so.

Re:mediacoder

[wampus]

I just read that entire stupid ass bug. I can't possibly imagine why the author decided to tell the ffmpeg guys to fuck off.

Re:mediacoder

[Minwee]

Maybe we're half way through reading different threads. The one I read goes something like this:

"Hey, MediaCoder violates our license. What can we do about it?"
"No it doesn't!"
"Yes it does. Read the license for ffmpeg."
"I don't want to. Read it for me!"
"Seriously, read the license for the software you are reselling."
"I didn't do it! Someone else did it first!"
"I don't care. Read the damn license."
"Reading is hard. Please read the license for me."
"Why don't you just read the license?"
"How about I release a patch? I haven't done it yet, but let's just pretend that I will. Does that make everything better?"
"No. Read the license."
"Okay, here's a patch. Is everything okay now?"
"That doesn't help. Just read the license for ffmpeg and stop violating it."
"I don't want to. Maybe I could change the colour of the windows in the installer. Why isn't anyone helping me? Why won't you tell me what I can do?"
"Have you tried reading the license?"

While things certainly could have been handled better by both sides, when you are taking someone else's work and reselling it the way that Mediacoder is, it shouldn't be too much to ask that you spend a little bit of time making sure that you aren't violating the license you acquired it under. Being too busy selling copies of ffmpeg for $399 isn't an excuse for not being able to read.

Re:Android: WebM; iOS: H.264

[Anonymous Coward]

Or better just use H.264 for both.

Audio: speech or more?

[dingen]

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.

QT-AVIdemux

[gagol]

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.

other concerns

[YrWrstNtmr]

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

Re:How about now vs. later? Terrible advice.

[SimonTheSoundMan]

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.

Re:It's a shame, the out-of-the-box requirement.

[pslam]

This is what I mean by misinformation:

I think he wants to make it through the entire 20 minute instructional video on battery... Enjoy your horribly wasteful software decoding, or use h.264 which has very liberal and cheap licensing requirements (in fact, you won't have to pay anything as the hardware decoder is already paid for by the hardware manufacturer, and you don't owe anything for encoding the video, look it up)

Do you realize how little CPU it takes to do QVGA decode software-only? Depends on the handset, but 10-30% is realistic. Do you know how much battery impact that has? Ball-park 100mW. Very little compared to the backlight or OLED (0.5W) and an order of magnitude less than the power a continuous 3G link is taking (1-2W).

H.264 has additional license fees for professional use. Yes, most people ignore that.

You continue to use the fallacy that Theora is worse as a reason not to use it. QVGA is not horrible on a modern smartphone - it is perfectly acceptable on a screen that's barely 4 inches across. The different between Theora and H.264 everyone overstates is for high bitrate, high profile, high resolution videos. This is none of the above, and even if it was, under fair analysis (not H.264 high profile which even a 3GS doesn't do) it's about 20% for "HD" video. Ths isn't HD.

48kbit MP3 is perfectly reasonable when it's mono. Next you'll tell my 128kbit MP3 stereo isn't acceptable. Come on, this is coming out of a handset speaker. You obviously haven't tried 48kbit or you wouldn't make such a ridiculous statement. Me, I've been in the codec business (and writing them) for over a decade.

I'm not even suggesting anyone use Theora/Vorbis as a solution. My gripe is that it could so easily be a neat solution. But isn't because, well, there's a ton of misinformation like yours around.

The truth - and if you'd ever tried it you wouldn't even question this - is that QVGA resolution is fine, 48kbit mono audio is fine, Theora is more than fine, and battery impact is negligibly different between codecs at these settings. I would love to know WHY people even think otherwise, because I'm trying hard to combat the spread of overkill like this. Who is "educating" folks with this?