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?"
Handbrake (Score:5, Informative)
Handbrake is what I use:
http://handbrake.fr/ [handbrake.fr]
Re:Handbrake (Score:5, Informative)
That and output as H.264 which is really the only choice.
Re: (Score:3, Informative)
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)
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.
Re: (Score:2)
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)
Re: (Score:2)
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...
Re: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
Actually, subtitles are in the spec : http://en.wikipedia.org/wiki/MPEG-4_Part_14 [wikipedia.org] and
http://en.wikipedia.org/wiki/MPEG-4_Part_17 [wikipedia.org]
Support is pretty shoddy though :(
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
.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:Handbrake (Score:5, 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.
Re: (Score:2)
Jeddiah have a point though, on a daily basis there are little reason to use your biggest hammer for even the small jobs.
In the case of this thread though, there are really no other option than h.264, as that is the format of choice between high-end smart-phones. I have no idea how Android or iPhone handles 3gp, but then again, that format is not exactly a high performer in any quality category anyway.
The main stumbling block is to decide which bandwidth, and frame size to use, and then perhaps chose the si
Re: (Score:2)
Most "featurephones" do h.264 as well. Using h.264 is a misnomer since it spans a quality continuum from 160x120 through 1080p and beyond. Most higher end phones can do VGA on h.264 easily.
3gp is a container format. It's a subse
Re: (Score:2)
Maybe he doesn't want the videos to be released in the (de facto) public domain? Sure, borrowing their compression, storage, and CDN skills would save a lot of time and money, but if you ever hoped to make money off of the videos you are publishing then youtube probably isn't the way to go.
Re: (Score:2)
Re: (Score:2)
Well it all depends on how long you want to wait for your result.
Really. What part of 10 TIMES FASTER did you not understand?
Of course, as others have said: It's all moot since Apple doesn't support anything but h264.
My comment was directed at the typical Apple fanboy cult approach to anything not done in a manner blessed by Apple.
Re: (Score:2)
With modern CPUs, 10 times faster isn't much of a difference, especially if your source content is high resolution (decoding takes the bulk of the time, since for transcoding you usually can't have hardware acceleration).
Also, in general, my experience is that most MPEG-4 ASP encoders were developed and perfected back in the days of single-core CPUs, and people haven't done much work into multithreading them. H.264 encoders, on the other hand, have been the focus of a LOT of multithreading optimization. T
Re: (Score:3, Informative)
only reason i disagree with you is i have 2 devices at home that will play mkv's, both are computers(PCs running vlc/mplayer). All of my portables and other devices(most importantly my ps3) won't play anything inside a mkv even if it is a compatible video/audio stream. Also i've had no luck doing "ffmpeg -i dumb.mkv -ac copy -vc copy useful.mp4". I always get some sort of error, about not being able to pack the h264 video into the mp4. I haven't tried, ripping them out, and then using mp4box, or ffmpeg to p
Re: (Score:2)
http://coreplayer.com/content/view/28/69/ [coreplayer.com] for symbian, palm and wm6 devices.
http://www.androidguys.com/2010/06/25/beta-test-rockplayerbase/ [androidguys.com] for Android (in Beta, but works great!)
Nothing for iphone, sorry. try this instead: http://www.gadgetsdna.com/how-to-install-android-2-2-froyo-on-iphone-3g/3501/ [gadgetsdna.com]
http://hubpages.com/hub/How-To-Play-MKV-Files-On-Playstation-3 [hubpages.com] Best bet for PS3 (which seems ridiculous, but tevs)
Re: (Score:2)
The above SHOULD work if it is an MKV with H.264 video and AAC video. It works for me.
However, a lot of "scene" MKVs are H.264 video and AC-3 (Dolby Digital) audio. AC-3 audio can't be put into an MP4 container (which is one reason MKV is used). AC-3 or DTS is the required format for 90%+ of surround sound systems out there, which is why that format is used for the audio instead of AAC.
To play such MKVs on a PS3, you need tsMuxer to remultiplex the H.264 video and the AC-3 audio into an MPEG transport st
Re: (Score:2)
I haven't seen a single device or muxer that supports that combo.
Re: (Score:3, Informative)
I prefer MKV, simply because it is one of the few to support an entire video package, with multiple audio tracks, subtitles and chapter marks.
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
Re: (Score:2)
> 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)
Rockplayer is a godsend, but unfortunately drains the battery in the blink of an eye :(
Re: (Score:2, Interesting)
Re: (Score:3, Interesting)
That is why AutoGK was made (http://www.autogk.me.uk/) However, going through the more complicated process gives you more options.
mencoder to H.264 (Score:2)
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 [realmtech.net] (part of mplayer [mplayerhq.hu]) has worked across all three platforms flawlessly.
Re: (Score:2, Informative)
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
Re: (Score:2)
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)
I do believe that the MP4 container can handle MP3, if not there are always AC3 as well.
Re: (Score:2)
You mean AAC?
Because AC3 (Dolby Digital) can definately not be put into an MP4 container. This is probably the #1 reason the "scene" uses MKV. (Typical MKV "scene" releases are 720p MPEG-4 AVC aka H.264 with the original source AC3 audio, since unless the source is DTS, the original AC3 is basically the only way to provide surround sound to 90% of home theater setups out there.)
Re: (Score:2)
Well then, isn't the mp4 container TERRIBLY LAME.
This explains why MKV is the Handbrake default for the High Quality preset in Handbrake.
This all comes back to "how lame is Apple".
You really do have to be careful about what they will and won't allow because combinations that seem obvious to everyone else will be disallowed by Apple even if the system in question is capable of dealing with the individual pieces and parts and the resulting aggregate. What Apple devices allow for will likely be your limiting f
Re: (Score:2, Informative)
Re: (Score:2, Informative)
It costs money, but they released a free full version 2.8 a while back that you can still find on this page...
http://www.videohelp.com/tools/FairUse_Wizard [videohelp.com]
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
www.pcfreetime.com
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.
Re: (Score:2)
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.
Re: (Score:3, Informative)
Re: (Score:2)
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
Multiple versions (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.
Re: (Score:2)
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)
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)
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
Re: (Score:2)
They may claim that the iP4 does 720p, but it's screen is still only 960x640, and that number comes from http://www.apple.com/iphone/specs.html
Even 360p is overkill (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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)
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
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
MPEG-4, H.264 (Score:3, Informative)
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.
Supported media (Score:3, Informative)
mediacoder (Score:3, Informative)
Re:mediacoder (Score:4, Informative)
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)
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)
Re:mediacoder (Score:4, Insightful)
"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 [mediacoderhq.com] isn't an excuse for not being able to read.
Re: (Score:2)
If you can't understand a software license, and can't be bothered to find someone to help you understand it, then you have no business trying to sell that software.
It is not the business of the people you are ripping off to provide you with free legal advice after the fact.
Re: (Score:3, Informative)
Here's the bug:
https://roundup.ffmpeg.org/issue1162 [ffmpeg.org]
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
Re: (Score:2)
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
Re: (Score:2)
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
iOS only support H.264 (Score:2, Interesting)
Audio: speech or more? (Score:5, 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.
Re: (Score:2)
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.
So:
1/4 resolution x 1/2 frame rate = 1/8 bandwidth of a normal stream.
Video for Everybody, and an Android caveat (Score:1)
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 [camendesign.com] 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.co [broken-links.com]
Better place to ask (Score:1, Offtopic)
Isn't this a better question for StackOverflow.com [stackoverflow.com]?
Or any Android forum -- already answered (Score:2)
Re: (Score:2)
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)
Works everytime.
DO NOT USE THE GTK VERSION as the auto facilities are not included.
other concerns (Score:4, Informative)
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
No one is going to do [x] on a mobile device? (Score:3, Insightful)
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
Re: (Score:2)
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'.
Re: (Score:2)
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
Quicktime has made this easy... (Score:2)
File>Export>Movie to Iphone
It's a shame, the out-of-the-box requirement. (Score:2)
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
Re: (Score:2)
Re:It's a shame, the out-of-the-box requirement. (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?
Re: (Score:2)
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
Re: (Score:2)
I will make my videos free to end users, so at this time I will not need to pay any fees. However, if I had planned on charging for access to the videos, I may have gotten into some trouble if I had not read your comment. Thank you.
Short subjects - 12 minutes or less - are royalty free.
You should seriously consider breaking up your instructional videos into smaller - more easily digestible - pieces.
The royalty on retail sales by title is 2% of sales or 2 cents a disk or download - whichever is lower.
MPEG L
Re: (Score:2)
Thanks! I think I would go with H.264/AAC as pretty much every modern Android and iOS handset is going to play that. The H.264/MP3 combination may even cause trouble.
What I don't recommend is the absurd overkill some are suggesting. I would hate to see you waste all that hosting bandwidth and storage, and end up with a high bitrate stream that will be problematic over 3G, and might not even work on a wide variety of handsets.
I would try to:
Re: (Score:3, Informative)
This generalization is wrong. Verses H.264, Theora does not perform well at any bitrate or resolution. Those who claim otherwise simply don't like H.264 because it's proprietary or have been given wrong information, like yourself.
Define "well". That's suitably vague. I put a figure on it: 20%. What's 20%? That's error power difference.
That's still perfectly usable. In some cases you can just use a little more bit rate to make up the difference, and depending on what that costs to you (bandwidth/storage/b
Re: (Score:2)
The difference is 20% compared to baseline profile at relatively high bitrates. The iphone 3gs, iphone 4, ipad and newer ipod touch model support high profile fine and then the difference is closer to 100%.
This is a misuse of the statistics. The trouble is they don't converge as the bitrate goes up - Theora converges to a lowest SSIM asymptote than H.264, so asking the bitrate it needs to have an equivalent SSIM is distorting things. It's good that those stats don't ask for the equivalent bitrate to reach
Re: (Score:2)
Low bit rate is the primary reason I don't use sites like pandora.com
Requirement: audio to accompany an instructional video, likely speech. Not crystal clear high quality entertainment music.
Requirement: played on a cell phone handset. Likely through a mono speaker. Not a pair of high end big speakers.
Re: (Score:2)
Ogg Frog will eventually do that and more (Score:2)
Ogg Frog [oggfrog.com] is designed to rip CDs into OGG format and then support MP3 and other formats. It will be based on Zoolib [sourceforge.net] 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
any dvd converter (Score:2)
http://www.any-dvd-converter.com/ [any-dvd-converter.com]
ISO MPEG-4 H.264 Baseline Profile (Score:3, Informative)
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/ [apple.com]
Re: (Score:3, Informative)
Or better just use H.264 for both.
Re: (Score:2)
Re:How about now vs. later? Terrible advice. (Score:4, Insightful)
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: (Score:2, Interesting)
Re: (Score:2)
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.