Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Cellphones Google Iphone

Encoding Video For Mobile Devices? 177

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?"
This discussion has been archived. No new comments can be posted.

Encoding Video For Mobile Devices?

Comments Filter:
  • Handbrake (Score:5, Informative)

    by jacoplane ( 78110 ) on Sunday July 25, 2010 @05:14PM (#33023520) Homepage Journal

    Handbrake is what I use: []

    • Re:Handbrake (Score:5, Informative)

      by SquarePixel ( 1851068 ) on Sunday July 25, 2010 @05:22PM (#33023562)

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

      • Re: (Score:3, Informative)

        by bemymonkey ( 1244086 )

        Android's support of H.264 is surprisingly good. As a content provider, it's hard to go wrong for any iPhone or Android phone with H.264.

        Consumers, on the other hand, get the short end of the stick... those hundreds of gigs of DivX everyone has laying around are useless on many Android devices, and even software-based decoder-players aren't enough because they need max CPU permanently, draining the battery nearly as fast as Flash on an iPhone (at least according to Steve Jobs :p)...

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          those hundreds of gigs of DivX everyone has laying around are useless

          And that's because pirate groups insist on using an obsolete format based on a container that's more than two decades old.

          Hint to those in "the scene": fuck DivX and fuck MKV, start using H.264+AAC in standard mp4 containers.

          • Why would I redownload/reencode all the stuff I already have?

            Sure, I wouldn't mind getting new stuff in H264 mp4/m4v right away, but I've got a lot of stuff I encoded or downloaded a long time ago, and redownloading and/or reencoding all of it would be pretty much out of the question...

            • Re: (Score:3, Interesting)

              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 ;-)
              • Lossless? We're talking about video here, not audio... even Blu-Ray is lossy.

                Of course, that would be ideal... but when you've got a fully catalogued and sorted collection filled with DivX, why would you want to re-rip everything? The quality of the original DVDs hasn't gotten any better, and the ONLY thing that won't play the damned things natively is my Android phone...

                • Whoosh!

                  (Geez guys, I even put a sarcastic smiley at the end)

                  On a separate, more serious, note, just be happy that in the longer term, this issue will disappear anyway. Mobile CPUs are getting more powerful, flash drives are getting bigger and costing less. Algorithms concerning soon-to-be public-domain standards like MPEG-1 are getting better and better. Realistically, in five years you can have a hard drive full of high quality 1080p MPEG-1 movies, knowing you can copy them as-is to your portable devi

                  • by Golias ( 176380 )

                    I would counter that format requirements will continue to go up as available tech improves, but the truth is that I ***still*** have not bothered with Blu-Ray at all, and even lossy 1/4 HD rips of Doctor Who look pretty good on my high-def projection system, let alone my tiny iPhone screen. As we already have with audio, we're rapidly reaching a point where most consumers simply aren't going to care about fidelity improvements enough to invest in near-future new technologies.

                    The screen already looks good t

          • Re: (Score:2, Interesting)

            by mykro76 ( 1137341 )
            Fuck MP4, it can't even handle subtitles. Renders most media centres including Apple TV almost useless. The pirate groups were right to choose MKV, but then they don't even bother to rip the subs. wtf?
          • by arivanov ( 12034 )

            While I agree with you regarding DivX I do not quite see your point on Matroska. MKV is Google's choice for VP8 standard so "scene" aside it is likely to be the _NATIVE_ container of choice in the next Android. It is not supported on the iPhone of course.

            As far as the actual settings for iPhone, PSP, etc they are in the ffmpeg wiki. The first gen Iphones can barely do a 1.2Mbit stream at 320x240. Newer ones are OK and the iPad can play a native SD stream. As far as encoding the video my rule of thumb is to

          • Yes everybody is dying to reencode all their stuff, losing quality, under a codec which is more CPU intensive, and having MPEG LA dictating the terms for simply viewing them, or ANY reencoding of them.

          • by ncc74656 ( 45571 ) *

            Hint to those in "the scene": fuck DivX and fuck MKV, start using H.264+AAC in standard mp4 containers.

            .m4v files can't contain AC3 or DTS audio. Reencoding audio to AAC results in getting it downmixed to stereo on playback over a S/PDIF or HDMI connection unless you have one of the handful of cards that implement Dolby Digital Live and/or DTS Connect. That probably doesn't matter much if you're only going to play your movies on an iPhone, but it's not so good if you're feeding your home-theater setup fro

        • Re: (Score:3, Informative)

          Consumers, on the other hand, get the short end of the stick... those hundreds of gigs of DivX everyone has laying around are useless on many Android devices, and even software-based decoder-players aren't enough because they need max CPU permanently, draining the battery nearly as fast as Flash on an iPhone (at least according to Steve Jobs :p)...

          My Samsung Galaxy S i9000 android phone (European version) plays DivX natively, without any dropped frames. :D

        • by gig ( 78408 )

          > Consumers, on the other hand, get the short end of the stick... those hundreds of gigs of DivX everyone has laying around are useless

          You have it backwards. H.264 enables consumers to choose video playback, video capture, and video editing tools from any manufacturer and still have universal compatibility. They can still create and share video with anyone, they can still purchase commercial video from any source and it all works. And it does all that entirely for free. That is the benefit of standardiza

      • Re: (Score:2, Interesting)

        by stms ( 1132653 )
        Not If you use 0.9.3 it supports xvid as well. At any rate Gordian Knot is a bit better than handbrake though slightly more complicated to use. []
        • Re: (Score:3, Interesting)

          by ThePengwin ( 934031 )

          That is why AutoGK was made ( However, going through the more complicated process gives you more options.

      • 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.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I also use handbrake. I don't own a smartphone so I'm going from guess work here.

      Video codec i would go with h264, that is pretty much the standard right now. Handbrake uses x264 by default. You can get advanced and pass specific options to x264 via handbrake. However some players don't support advanced x264 features. I would start with the apple presets and work from there.

      Audio codec mp3 or aac. The rate varies, i would say ~160 for mp3 and ~128 for aac. Again trial and error will work best. Mixdown stere

      • by jedidiah ( 1196 )

        Basically use Apple's devices as the lowest common denominator as they tend to be the most picky.

        Generate h264 mp4 files with mp3 audio.

        As others have said, Handbrake has nice presets for this.

        If you try to futz with individual h264 settings on your own you will probably generate something that is unplayable on Apple devices.

    • Re: (Score:2, Informative)

      by imbaczek ( 690596 )
      mod parent up! also, use a nightly build for extra x264 goodness.
    • Re: (Score:2, Informative)

      by krick-zero ( 649744 )
      Fair Use Wizard is pretty decent.

      It costs money, but they released a free full version 2.8 a while back that you can still find on this page... []
    • Re: (Score:2, Funny)

      Well, that killed the discussion, can't go past Handbrake. In fact, if you read past this post, you're wasting your time.

      There are many like it, but Handbrake is the best.

      • Well, that killed the discussion, can't go past Handbrake. In fact, if you read past this post, you're wasting your time.

        You have got to be kidding. If there was an ask Slashdot "what is 2 + 2?" you'd still get a lot of different answers. And quite rightly, too.

    • by Luckyo ( 1726890 )

      FormatFactory is probably an easier choice to get into for a beginner because it features built-in optimized settings for vast majority of phones. Not just Android/Iphone but many other makers like Nokia, Samsung, Sony Eriksson etc.

      It's yet another ffmpeg frontend, but it supports far more output options then handbrake that went h.264 only this year. Personally I use it also because it allows very easy handling of subtitles in addition to wide device support.

      • Thank you! I've been looking for a tool that handles MKV subtitles correctly. Handbrake doesn't support burning in MKV subtitles but it seems to work perfectly with this tool.

  • Multiple versions (Score:5, Informative)

    by mikael_j ( 106439 ) on Sunday July 25, 2010 @05:16PM (#33023526)

    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.

    • by dingen ( 958134 )

      What's the advantage of multiple resolutions instead of just pushing one 480p (or 360p if detail isn't that important) file at a low enough bitrate to be streamable but high enough to be watchable?

      Seems to me that everyone would be happy with this one version of the video.

      • Re:Multiple versions (Score:4, Informative)

        by mikael_j ( 106439 ) on Sunday July 25, 2010 @05:55PM (#33023758)

        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.

        • Re: (Score:2, Informative)

          by Kylock ( 608369 )

          Going lower than this is silly. The OP is asking about iOS and Andriod phones specifically. If were going to talk about the newest hardware, I'm not sure about the iPhone 4, but the HTC Evo and the Moto Droid X both support 720p video. HTC Just recently announced a new phone where they plan to support 1080, although it seems like overkill for such a small screen, I think they are thinking more people will use the hdmi outputs available on those phones.

          Maybe consider doing 720p and 360p versions if you de

          • by JavaBear ( 9872 ) *

            They may claim that the iP4 does 720p, but it's screen is still only 960x640, and that number comes from

        • there are plenty of users who dislike this even if you happen to be one of the loudmouths who claim it looks "just fine:

          Oh come on.... there are millions more who are, as I write this, watching stretched out, upscaled, crap ass video on their 720P/1080P flat screens, connected to their HD cable box via the RCA video jack. This includes every non-techie iphone user I know.

        • Re: (Score:3, Insightful)

          by wvmarle ( 1070040 )

          For that iPhone if bandwidth is a problem for 960x640 video, you may want to look at say 480x320 resolution video. Yes it has to scale up, but I can imagine it looks better than 480p or 360p as every video pixel becomes exactly 2x2 screen pixels. Instead of having to interpolate or whatever you have to do to make it fit on a non-matching resolution, like 1.5 screen pixels per video pixel.

          From my experience with LCD screens it is the non-matching of resolutions that make them look crappy. When using the exa

    • Can I just ask what "Greylisting is to SMTP as NAT is to IPv4" is supposed to mean? I'm quite familiar with both technologies and can't figure out what this is trying to say. Maybe I can't see the forest for the trees?

      • He's comparing the byproduct of IP sharing through NAT (incoming traffic cannot reach a destination past the router without extraordinary means (preconfigured port forwarding, DMZ) without a pre-established connection. Your local IP address behind the NAT router is inaccessible, except when the router sees you've established a connection with an external public IP, and then it creates a temporary port mapping table that connects the public IP and its port (say, 80 in the case of a webserver) with the public

        • That would make a lot more sense if greylisting actually meant what you think it does. Greylisting has nothing to do with banning sources that you haven't sent messages to, or actually banning anything at all. Greylisting is simply giving a temp fail to a host you haven't seen before, and then allowing them as normal when (if) they retry. All this happens at the SMTP level and is completely automatic, so unlike NAT it does not require any specific configuration for individual entities.

          still not seeing th

        • NAT can be crossed if the users on both sides know the public IP address of the other. Host A sends a stream of garbage to the NAT gateway of Host B. All of these packets will be dropped, but it will make the router allow incoming traffic from that public address to go to Host A. Host B then sends its own garbage data to Host A's gateway, which will then pass through. Host B's router now will let traffic through. Once Host A gets the garbage, it can send an acknowledgement and establish a connection. I did
  • MPEG-4, H.264 (Score:3, Informative)

    by dorzak ( 142233 ) <dorzak AT gmail DOT com> on Sunday July 25, 2010 @05:17PM (#33023530) Journal

    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 about what is supported for iOS.

  • Supported media (Score:3, Informative)

    by LiENUS ( 207736 ) <slashdot@vetma n a g e . com> on Sunday July 25, 2010 @05:17PM (#33023532) Homepage
    The android developers site has an excellent list of supported media formats. [] The iphone 4 specifications [] 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 (Score:3, Informative)

    by ceraphis ( 1611217 ) on Sunday July 25, 2010 @05:24PM (#33023570)
    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 (Score:4, Informative)

      by Warll ( 1211492 ) on Sunday July 25, 2010 @07:40PM (#33024326) Homepage
      It should be mentioned that MediaCoder is in the ffmpeg hall of shame: [] (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 (Score:4, Insightful)

        by wampus ( 1932 ) on Sunday July 25, 2010 @08:54PM (#33024744)

        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: (Score:2, Insightful)

          No kidding. The finer points of the GPL are lost on me as well, but god damn. The guy is actively trying to fix the problem with FFmpeg and I'm over halfway through the thread and they have been nothing but unhelpful assholes to him.
          • Re:mediacoder (Score:4, Insightful)

            by Minwee ( 522556 ) <> on Monday July 26, 2010 @10:53AM (#33030016) Homepage
            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: (Score:3, Informative)

        by dotancohen ( 1015143 )

        Here's the bug: []

        The MediaCoder author is asking what he violated and the FFmpeg dev is just telling him to RTFL (license), all of it. The FFmpeg dev is being a jerk, too, and calling him names. The MediaCoder author even mentioned that he asked on the mailing list before distributing and got told that him usage was fine.

        MediaCoder might be violating the license, but it looks like an honest mistake that the author wants to rectify. The FFmpeg dev would rather call him names

        • I have to echo this. It's a pity that the mediacoder dev couldn't get his ducks in a row, but he's opening an honest dialog on that thread and in return is being ridiculed and spat upon. It may not be an issue that diego would like to deal with, but that doesn't mean he should be a jerk (the jerk store called...!).

          I find it both humorous and disappointing that he justifies his ridicule by saying that he deals with "ignorance" all the time and so, of course, now has a short fuse. That may give reason, bu
    • Mod parent up, I was going to suggest this if noone else did. It has a full blown version (free), as well as one specifically tweaked for mobil devices (also free). Use h264, and I recommend one encode per device. I am not sure about the android, but the iPhone is REALLY picky over the resolution of its videos.

      Also, if you have some Adobe Suites laying around, Adobe Media Encoder is SWEET, especially if you have CS5. I know it has presets for iPhone, and CS5 will hopefully have presets for Android as well

  • 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.
  • by dingen ( 958134 ) on Sunday July 25, 2010 @05:45PM (#33023688)

    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.

    • by cptdondo ( 59460 )

      Further, you can cut the video size in half by going to 15fps instead of 30fps.

      Unless you're doing high speed action flicks, no one will notice.

      I've encoded fast action at 15fps for use on a handheld and no one noticed.

      Also, I'm not sure about the devices you want to support, but typically you can encode at 1/4 the display resolution with OK results. Fast action at 1/4 resolution looks OK.


      1/4 resolution x 1/2 frame rate = 1/8 bandwidth of a normal stream.

  • 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: []

  • Isn't this a better question for []?

    • 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."
      • by mdwh2 ( 535323 )

        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 ge

  • QT-AVIdemux (Score:4, Informative)

    by gagol ( 583737 ) on Sunday July 25, 2010 @05:53PM (#33023744)
    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 (Score:4, Informative)

    by YrWrstNtmr ( 564987 ) on Sunday July 25, 2010 @06:01PM (#33023796)
    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
    • 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 sto

      • TV shows or movies != instructional video. Completely different use case.

        Sure I could watch a 30 min TV show on the train going to work (if I had an iTouch/iPhone/Android and if I rode the train).
        But if it were an instructional vid of how to change the oil in the car, I'd like to be able to bypass the 'gather tools' and 'jack up the car' segments, and jump directly to 'turn the filter this way'.
        • by Andy Dodd ( 701 )

          I remember one particular set of instructional videos (how to download Ibycus Topo) consisted of 3 10-minute videos.

          If you were moderately computer-savvy and had familiarity with BitTorrent, you only needed 30 seconds that started 8:30 in the first video (where to find the .torrent file, which the person who released Ibycus Topo didn't bother to link directly to.)

          What was funny was the only source for the .torrent file was ThePirateBay, despite the fact that this particular dataset was 100% free/legit as it

  • File>Export>Movie to Iphone

  • 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 perfect

    • 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) From a business standpoint, which makes more sense? P.S. not to give you a new one, but you fail to list any reasons why Th
      • by pslam ( 97660 ) on Sunday July 25, 2010 @08:22PM (#33024564) Homepage Journal

        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?

        • Some numbers.

          Nokia n900.

          Medium brightness.

          480x272 h264.

          mplayer - 60% CPU at 500MHz. 460mA. This is software.

          Built in player. 30% CPU at 500MHz. 270mA. This is hardware.

          Or - around a half more to do it in software.

          However. This is pretty much the worst case.

          If you up the brightness to max - then it's more like an extra third (120mA is added on in both cases).

          With brightness at max, and streaming the video over 3G - it's under an extra quarter.

          Technically, with integrated hardware decoders - playing video can

  • 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 a

  • by gig ( 78408 ) on Monday July 26, 2010 @06:55AM (#33027770)

    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. []

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell