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

7 of 177 comments (clear)

  1. Handbrake by jacoplane · · Score: 5, Informative

    Handbrake is what I use:

    http://handbrake.fr/

    1. Re:Handbrake by SquarePixel · · Score: 5, Informative

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

    2. Re:Handbrake by jo_ham · · Score: 4, Insightful

      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.

  2. Multiple versions by mikael_j · · Score: 5, Informative

    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
  3. Audio: speech or more? by dingen · · Score: 4, Informative

    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.
  4. QT-AVIdemux by gagol · · Score: 4, Informative

    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...
  5. Re:It's a shame, the out-of-the-box requirement. by pslam · · Score: 5, Informative

    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?