Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Encoding Video For Mobile Devices?

kdawson posted about 4 years ago | from the pick-any-two dept.

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

cancel ×


Sorry! There are no comments related to the filter you selected.

Suck it N00bs! (0, Troll)

SpongeBob Hitler (1848328) | about 4 years ago | (#33023508)

Slashdot sucks! I hope you all die horrible, lingering deaths!

Handbrake (5, Informative)

jacoplane (78110) | about 4 years ago | (#33023520)

Handbrake is what I use: []

Re:Handbrake (5, Informative)

SquarePixel (1851068) | about 4 years ago | (#33023562)

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

Re:Handbrake (2, Informative)

bemymonkey (1244086) | about 4 years ago | (#33023812)

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

Anonymous Coward | about 4 years ago | (#33023940)

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.

Re:Handbrake (0)

King InuYasha (1159129) | about 4 years ago | (#33023962)

Fuck MP4 container. MKV all the way!

DivX is a bad choice no matter which way you slice it.

Re:Handbrake (2, Informative)

cynyr (703126) | about 4 years ago | (#33024368)

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 put them back together.

Re:Handbrake (1)

King InuYasha (1159129) | about 4 years ago | (#33024442)

I usually don't use FFmpeg to create MKVs. I usually choose to mux the MKVs myself using mkvmerge. However, I believe Handbrake generates good MKVs as well, though I'm not completely certain on it, since I don't use Handbrake.

Re:Handbrake (0)

jedidiah (1196) | about 4 years ago | (#33023986)

divx is a nice format if you happen to be encoding stuff.

It's 10 times faster than h264.

For transient data, it doesn't really make sense to use the single most expensive format out there. None of these devices are capable of playing archival quality video files anyways so there's no point in pretending.

Sure, the quality will be lower but it's a small device with a small screen so it really doesn't matter in the end.

OTOH, an HD divx file is something that an older machine has some hope of decoding.

The entire world should not be forced into h264 just because some ignorant people don't believe in using different tools for different jobs.

Re:Handbrake (4, Insightful)

jo_ham (604554) | about 4 years ago | (#33024142)

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 (1, Interesting)

Anonymous Coward | about 4 years ago | (#33025816)

Here's a crazy idea, provide a picture link to your videos that you upload to instead of trying to encode them in? Feel free to bash the idea, but I find it a simplistic way to solve the situation without doing a lot of work. Most phones come with a Youtube app preinstalled.

Re:Handbrake (0)

Anonymous Coward | about 4 years ago | (#33024170)

Except on nearly all devices H.264 is hardware decoded and DivX may not be. H.264 gives better picture quality, smaller sizes and your battery will last longer and play smoother.

The only thing you've got for DivX is it takes less time to encode. Since the encoding happens once and the playback occurs (for others) many more times it seems short sighted to use something like DivX.

Re:Handbrake (1)

DMalic (1118167) | about 4 years ago | (#33024736)

Many devices can output to TV. Say you have 1 mbps video; with x264 this might look reasonably close to DVD quality, with xVid it'll be blurry and nasty.

Re:Handbrake (1)

bemymonkey (1244086) | about 4 years ago | (#33024112)

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:Handbrake (3, Interesting)

squiggleslash (241428) | about 4 years ago | (#33024816)

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 ;-)

Re:Handbrake (0)

Anonymous Coward | about 4 years ago | (#33024978)

That's kind of hard when the DVD/Blu-Ray discs already aren't lossless.

Re:Handbrake (0)

Anonymous Coward | about 4 years ago | (#33024236)

Wait wait wait stop your trolling and state some facts first. MKV is just a file container... not a codec... []

Re:Handbrake (0)

Anonymous Coward | about 4 years ago | (#33024498)

Why fuck MKV ? MKV is a very good and flexible container which supports many different codecs. The tools are very good and it has a pretty wide support base. All of my devices support it out the box.

Re:Handbrake (2, Interesting)

mykro76 (1137341) | about 4 years ago | (#33025418)

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?

Re:Handbrake (2, Informative)

teh31337one (1590023) | about 4 years ago | (#33025018)

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:Handbrake (3, Interesting)

stms (1132653) | about 4 years ago | (#33023994)

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:Handbrake (3, Interesting)

ThePengwin (934031) | about 4 years ago | (#33024110)

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

mencoder to H.264 (1)

nemesisrocks (1464705) | about 4 years ago | (#33025562)

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:Handbrake (2, Informative)

Anonymous Coward | about 4 years ago | (#33023576)

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 stereo, i wouldn't putz with any of the dolby features.

Screen resolution is an issue I am completley guessing at. I'm assuming That the players scale resolution up or down. So I would render one low def, and one high def. I don't know the phones aspect ratios. High def being near evo 4g quality low def being errm low. You could possibly just do one medium definition but I don't know if the players will choke on higher resolutions.

For encoding video you have several choices
Target Size, Bitrate, or constant Quality.

Target Size usually looks like crap in my experience.

Bitrate allows finer grained control but you really should do 2 passes on it for better quality. So in turn it takes longer.

Constant quality works at variable bit rates to my understanding, and it only requires one pass. This is what I use. I rip all my dvds at RF=23. Lower number is higher quality. Due a couple small clips to figure out end size. But i would recommend starting with constant quality.

Re:Handbrake (1)

jedidiah (1196) | about 4 years ago | (#33024004)

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:Handbrake (0)

Anonymous Coward | about 4 years ago | (#33024362)

AFAIK there's no such thing as "mp4 files with mp3 audio". It's either MPEG-4 or H.264 video and AAC audio, inside an .mp4 container.

Re:Handbrake (1, Informative)

imbaczek (690596) | about 4 years ago | (#33023584)

mod parent up! also, use a nightly build for extra x264 goodness.

h.264 takes too much juice to play (-1)

Anonymous Coward | about 4 years ago | (#33023662)

h.264 takes too much juice to play.

MPEG2 and MP3 audio.

QVGA resolution will still be good (remember, the screen is still the same size as the small phone screens), or you can just pop it to 512x384 (or whatever 4:3 is).

Which pretty much means "DO NOT USE HANDBRAKE".

It's only a hobbled front-end to transcode anyway.

DVD::Rip for a gui:

Or just find the right script and automate it:

Re:h.264 takes too much juice to play (2, Informative)

willy_me (212994) | about 4 years ago | (#33023706)

It will use less power to play h264 in hardware then MPEG2 in software. And all of the phones will have hardware h264 decoders.

And MPEG2 in hardware less still (0)

Anonymous Coward | about 4 years ago | (#33023790)

And MPEG2 in hardware less still. And for mobile devices without H.264 hardware assist, you don't have H.264 hardware assist, so you're back to software decoding which is much cheaper with MPEG2 than with H.264.

Re:Handbrake (2, Informative)

krick-zero (649744) | about 4 years ago | (#33023772)

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:Handbrake (1, Funny)

sortius_nod (1080919) | about 4 years ago | (#33023826)

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:Handbrake (1)

Luckyo (1726890) | about 4 years ago | (#33025200)

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.

Multiple versions (5, Informative)

mikael_j (106439) | about 4 years ago | (#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.

Re:Multiple versions (1)

dingen (958134) | about 4 years ago | (#33023652)

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 (3, Informative)

mikael_j (106439) | about 4 years ago | (#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:Multiple versions (2, Informative)

Kylock (608369) | about 4 years ago | (#33023904)

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 decide to do 2 encodes instead of just one.

Re:Multiple versions (0)

Anonymous Coward | about 4 years ago | (#33023970)

Maybe consider doing 720p and 360p versions if you decide to do 2 encodes instead of just one.
Absolutely good advice. It's not a bad idea to follow YouTube's lead on this. H.264 at 360p, 480p, 720p (and on up) are what they've targetted. Going with 360p and 720p ensures you've got the low-end and high-end covered (for mobile web video at least).

Even 360p is overkill (1)

pslam (97660) | about 4 years ago | (#33024192)

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.

Re:Even 360p is overkill (1)

DMalic (1118167) | about 4 years ago | (#33024748)

I second this. Youtube 320 looks surprisingly good now on videos with a decent source. I have to wonder if they're using better settings than in the past.

Re:Multiple versions (1)

xded (1046894) | about 4 years ago | (#33024080)

And don't forget to use Lanczos anti-aliasing when downsizing to avoid moiré [] .

FWIW, to do these kind of processing/conversions I once used an AVISynth [] script with Nero Recode. No match on flexibility and speed (repsectively) at that time.

Re:Multiple versions (1)

Simulant (528590) | about 4 years ago | (#33024128)

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:Multiple versions (1)

LodCrappo (705968) | about 4 years ago | (#33025042)

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:Multiple versions (1)

Narcogen (666692) | about 4 years ago | (#33025278)

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 IP of your router at some high arbitrary port, which then maps to your local NAT IP address at port 80 so your web browser can read the page. Without your initial connection attempt (loading a web page) this port mapping is not created, and computers with public IP addresses cannot "see" or contact your machine.

Greylisting does intentionally for email what NAT does as a byproduct. Unlike blacklisting, which enumerates email addresses to block, and whitelisting, which unemerates email addresses to allow, greylisting allows messages from only email addresses you've sent messages to-- like NAT only allows IP connections from IP addresses you've already contacted.

Re:Multiple versions (1)

LodCrappo (705968) | about 4 years ago | (#33025370)

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 the analogy

Re:Multiple versions (1)

zach_the_lizard (1317619) | about 4 years ago | (#33025736)

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 that for a battleship game I wrote many moons ago so that I could play against friends through NAT. Not sure if this will work for all routers, but it worked with ours.

MPEG-4, H.264 (2, Informative)

dorzak (142233) | about 4 years ago | (#33023530)

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.

Re:MPEG-4, H.264 (0)

Anonymous Coward | about 4 years ago | (#33024598)

plus android has hardware to decode h264 and save some battery...

Supported media (3, Informative)

LiENUS (207736) | about 4 years ago | (#33023532)

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.

Android: WebM; iOS: H.264 (0)

mlauzon (818714) | about 4 years ago | (#33023566)

Well, for Android you could always use WebM, and for iOS H.264.

Re:Android: WebM; iOS: H.264 (3, Informative)

Anonymous Coward | about 4 years ago | (#33023632)

Or better just use H.264 for both.

Re:Android: WebM; iOS: H.264 (1)

dingen (958134) | about 4 years ago | (#33023644)

If you're going to create an H264 version, you might as well push that to the Android devices as well.

Re:Android: WebM; iOS: H.264 (0)

Anonymous Coward | about 4 years ago | (#33023980)

Does android have good support for WebM? As far as I know, only h.264 has hardware acceleration on *any* phone, including android ones.

A phone CPU is going to struggle to keep frame rate up and/or burn battery playing WebM.

How about now vs. later? Terrible advice. (1, Troll)

SuperKendall (25149) | about 4 years ago | (#33024042)

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.

Re:How about now vs. later? Terrible advice. (3, Insightful)

SimonTheSoundMan (1012395) | about 4 years ago | (#33024468)

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.

mediacoder (3, Informative)

ceraphis (1611217) | about 4 years ago | (#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 (3, Informative)

Warll (1211492) | about 4 years ago | (#33024326)

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 (3, Insightful)

wampus (1932) | about 4 years ago | (#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:mediacoder (0)

Luckyo (1726890) | about 4 years ago | (#33025260)

It should be noted that many of the better (if not best) encoding programs can be found on the shame list for one reason or another. MediaCoder, FormatFactory, etc. There are some that are for the reason such as FormatFactory that seems to be there out of total ignorance (no one seems to even have bothered to email the program developer with grievances). There are some cases where the dev honestly comes to ask "how can I comply?" and the answer he gets is summarizable in "RTFM nub! Follow the licence!" with no hints on what exactly is supposed to be done about it (such as the issue with mediacoder).

Re:mediacoder (0)

Anonymous Coward | about 4 years ago | (#33025448)

Wow, unbelievable. And it's still on Sourceforge! Since when do they host closed source?

As for an encoder frontend on Windows, Staxrip [] . Staxrip Staxrip Staxrip [] . Nothing else.

Re:mediacoder (2, Informative)

dotancohen (1015143) | about 4 years ago | (#33026238)

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 than show him what he did wrong.

Re:mediacoder (1)

gravis777 (123605) | about 4 years ago | (#33025756)

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 (2, Interesting)

zbobet2012 (1025836) | about 4 years ago | (#33023640)

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.

Audio: speech or more? (4, Informative)

dingen (958134) | about 4 years ago | (#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.

Re:Audio: speech or more? (1)

cptdondo (59460) | about 4 years ago | (#33025000)

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.

Video for Everybody, and an Android caveat (1)

cshbell (931989) | about 4 years ago | (#33023736)

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

Better place to ask (0, Offtopic)

kabloom (755503) | about 4 years ago | (#33023740)

Isn't this a better question for [] ?

Re:Better place to ask (0)

Anonymous Coward | about 4 years ago | (#33023840)

Or reddit or.. who knows perhaps /. is not so bad after all.

Or any Android forum -- already answered (1)

beakerMeep (716990) | about 4 years ago | (#33025022)

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

QT-AVIdemux (4, Informative)

gagol (583737) | about 4 years ago | (#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.

Testing is the only way, but here are the tools (0)

Anonymous Coward | about 4 years ago | (#33023750)

Assuming the video is already in a non encrypted format (read- not on a DVD) I recommend mediacoder ( It's free, runs pretty much everything, and has a bounty of features.

The mobile version is OK (assuming you know what device). If you get the full version you can control just about everything (video size, native resolution, bitrate, encoder, effects, etc...).

I would recommend playing with the settings, seeing what works and what doesn't work, then saving the final set-up as preset.

The one issue I've run into with mediacoder is subtitles. It burns subtitles into the video, even if you choose the "do not render" option. If you start with an .mkv remove the subtitles using mkv merge (, then process away. Both video and audio are straight forward, and should allow for whatever you're doing.

The forum for mediacoder should answer any other questions you might have. Best of luck to you, and remember that commercial users of mediacoder should seriously consider donating to keep the project running.

other concerns (3, Informative)

YrWrstNtmr (564987) | about 4 years ago | (#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

Re:other concerns (1, Informative)

Anonymous Coward | about 4 years ago | (#33023896)

Not to mention he can get more advertising revenue this way.

No one is going to do [x] on a mobile device? (2, Insightful)

rbeattie (43187) | about 4 years ago | (#33024522)

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.


Re:No one is going to do [x] on a mobile device? (1)

YrWrstNtmr (564987) | about 4 years ago | (#33024682)

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

Re:No one is going to do [x] on a mobile device? (0)

Anonymous Coward | about 4 years ago | (#33025984)

It's not really exclusive to mobile. I'd expect that much for web content in general

Ignore the fanboy rhetoric (0)

Anonymous Coward | about 4 years ago | (#33023936)

Upload to youtube and forget about it.

Re:Ignore the fanboy rhetoric (2, Interesting)

gollito (980620) | about 4 years ago | (#33024472)

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.

Re:Ignore the fanboy rhetoric (1)

martinX (672498) | about 4 years ago | (#33024594)

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.

Anonymous Coward (0)

Anonymous Coward | about 4 years ago | (#33023978)

vlc.exe -vvv -I dummy myvideo.avi --sout="#transcode{ab=96,samplerate=44100,channels=2,acodec=mp4a,vcodec=h264,width=480,height=320,vfilter="canvas{width=480,height=320,aspect=16:9}",fps=25,vb=900,venc=x264{profile=baseline,level=3.0,no-cabac,keyint=75,ref=3,bframes=0}}


Quicktime has made this easy... (1)

ducomputergeek (595742) | about 4 years ago | (#33024032)

File>Export>Movie to Iphone

For iPhone streaming, M3U8 file (1)

SuperKendall (25149) | about 4 years ago | (#33024054)

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.

Re:For iPhone streaming, M3U8 file (1)

dmorel (799497) | about 4 years ago | (#33024428)

No segmented mpeg via m3u8 on anything but APPL devices, it's their standard, like microsofts smooth streaming (though I do some STB guys who have written a linux app to handle smooth streaming chunks)... but there's nothing for android yet that I am aware. It's true for streaming to mobile devices, and well really any IP connected devices, some form of adaptive bit rate streaming over HTTP is the way to go. It's funny, the company that pioneered this stuff Move Networks is basically out of business but Microsoft, Apple, and Adobe (plus the big CDN's like Akamai and Limelight) are all moving towards HTTP streaming. For the OP, it's H.264 as everyone and their mother has said so far, works on both handsets you're talking about and is easy. FFMpeg is probably doing the work regardless of what front end wrapper you're putting on it.

Why do it alone? (1)

cdrgonzo (640470) | about 4 years ago | (#33024072)

H.264 with aac for both. Http live streaming on ios, progressive downloads on everything else... Seriously, why waste your time doing this solo? plenty of companies already do this stuff almost for free a lot better than you can do it by yourself. Ooyala or brightcove are good for web. Synctv does web and custom apps across every major platform (ios , android, pre, yahoo widgets, bluray, roku, etc...) You can waste months developing something not even close to as good.

It's a shame, the out-of-the-box requirement. (1)

pslam (97660) | about 4 years ago | (#33024118)

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)

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

TD-Linux (1295697) | about 4 years ago | (#33024388)

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 Theora was superior. In fact, it's been said many many times again that it's quite a bit worse. QVGA is horrible on modern smartphones which have very high resolution displays, and young users who can see the detail on a high resolution screen. 48kbit mp3 sounds like a metallic mess even for voice to me, especially considering that this is a portable market and many users will use headphones. Have you actually attempted mono mp3 at 48kbit/s? I think you have your perfect world wrong here - the only thing that restricts h.264 is the patents (and relatively cheap, they are). Vorbis is admittedly a bit superior, but mp3 encoders have gotten so much better it matters far less than the video.

Re:It's a shame, the out-of-the-box requirement. (5, Informative)

pslam (97660) | about 4 years ago | (#33024564)

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:It's a shame, the out-of-the-box requirement. (1)

MadGeek007 (1332293) | about 4 years ago | (#33024836)

Thank you for your detailed response. Insight like this is exactly why I posted to ask /. If I had any mod points left, I'd mod the parent up.

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

Upon further investigation, I discovered [] Which states, in part:

"MPEG LA announced today that its AVC Patent Portfolio License will continue not to charge royalties for Internet Video that is free to end users (known as Internet Broadcast AVC Video) during the next License term from January 1, 2011 to December 31, 2015. Products and services other than Internet Broadcast AVC Video continue to be royalty-bearing, and royalties to apply during the next term will be announced before the end of 2010."

Therefore, the statement in the grandparent comment is incorrect.

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

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.

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

westlake (615356) | about 4 years ago | (#33025114)

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 LA licensing is oriented toward very large scale commercial distribution - the premium cable channel with more 100,000 subscribers, the local broadcaster serving more than 500,000 households.

You really have little or nothing to offer them until you are seeeing sales of a quarter of million units with some regularity.

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

queazocotal (915608) | about 4 years ago | (#33024840)

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 be remarkably inexpensive.
Playing video with no sound at minimum brightness uses around 50mA more - around an additional 5% of the battery an hour over just having the system idle.

But - especially for the original questioner - this isn't very interesting information, as 3G or screen brightness will often swamp this.

With the (0)

Anonymous Coward | about 4 years ago | (#33024356)

You should check out Their service is what you need.
It is one of qualcomm's products.

H264 Warning (0)

Anonymous Coward | about 4 years ago | (#33024408)

Just because h264 fits your technical needs you still have to be aware of the licensing.

Not all uses of h264 are free !

Ogg Frog will eventually do that and more (1)

Orion Blastar (457579) | about 4 years ago | (#33024474)

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.

Make an instructional video when you're done! :) (0)

Anonymous Coward | about 4 years ago | (#33024484)

I'm just sayin......

Just remember the wise words of Vader, "You are part of a rebel alliance and a traitor. Take her away!"

Windows Mobile (0)

Anonymous Coward | about 4 years ago | (#33024746)

If you're targeting windows mobile, you're screwed. WMA is your only choice. Theora...nope forget it. Been there, done that.

Go with what the porn sites use (0)

Anonymous Coward | about 4 years ago | (#33024998)

Which would be mpeg4 for high res vids and 3gp for low res.

Helix Mobile producer (0)

Anonymous Coward | about 4 years ago | (#33025606)

Helix Mobile producer is purpose built for this task.

Handbrake settings (CLI) (0)

Anonymous Coward | about 4 years ago | (#33025916)

/usr/bin/HandBrakeCLI -I -O -i %DIR%/%FILE% -t 1 -c 1-21 -o /mythtv/videos/Compressed/"%TITLE%"-"%SUBTITLE%".mp4 -f mp4 -w 480 -l 272 –crop 0:0:0:0 -e x264 -b 384 -2 -T -r 29 -a 1 -E faac -B 160 -R 44.1 -6 stereo -D 1 -x ref=2:me=umh:cabac=0:bframes=0 -C 8 -v

I use this for encoding my MythTV recordings for my iPhone 3GS and my wife's Droid. Works very well.
Enjoy. You're welcome. I assume you will figure out on your own how to best use this and get what you want out of it.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>