hpr-knowledge-base/hpr_transcripts/hpr0594.txt

Episode: 594
Title: HPR0594: Using FFMPEG To Convert Video Shot With An Android Phone
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0594/hpr0594.mp3
Transcribed: 2025-10-07 23:40:25

---

music
Howdy, this is 5150.
This is my presentation on how to use FFMPEG Convert Video Shot on an Android phone
to a more portable format, specifically to a format suitable to upload to YouTube.
I'm not asserting that I've arrived at the optimal parameters, I do know that after
a period of research and frustration, I came up with a method that I was satisfied with.
It is a fact by hope that I can start a discussion whereby those more knowledgeable may respond
with better options.
The other day I was attending an event for which I wished to record video, but my trusty
Sony digital video tape camera decided to cough up a hairball and refused to recognize
a perfectly good brand new tape.
As a substitute, I broke out my HTC droid incredible and was able to record a couple
15 minute clips before the battery gave out.
When I got home, I transferred the clips to my PC and was surprised to learn that I
didn't recognize the video container format denoted by the extension, .3GP.
.3GP, what the heck is .3GP?
Fortunately, Wikipedia to the rescue.
.3GP is a multimedia container format defined by the 3rd generation partnership project for
3G mobile phones.
It is a derivative of MPEG4 and they use .3GP for GSM phones and .3G2 for CDMA phones.
And by that, I'm assuming they mean all smartphones, but very least applied to HTC Android.
The video is for an organization of which I'm a member, and I developed an organization's
website on my Windows PC, so that's where I'd copied the video files.
The first thing I tried was opening the .3GP files in Windows Media Player, and to its
credit, at least recognized that it was a video format, even though it had no idea how
to play them.
Of course, the next thing I tried was to play the files in VLC, and there I had video,
but no audio.
That was corrected by downloading and installing the current version of VLC for Windows.
I realized that I would probably like to use an open-source tool to convert the video
format to something more common, so I transferred the files over to my Linux box, and again,
I tried to play them with in-player, which reported that it needed a plug-in, AMR, adaptive
multi-rate decoder, before it could play.
Again, VLC played the video with no problem.
I'd already decided that the most appropriate tool for converting video would be FF impact,
but I had no experience using it.
Now, if I digress for a minute, I've mentioned I transferred files to my PC and from the
PC to the Windows PC to the Linux box, rather than uploading video directly to the internet.
The reason first I wanted to take a look at the video before I uploaded it, make sure
I didn't have to do any additions, corrections, and I do know that the camera album software
on my droid has support for uploads to Flickr and Facebook, and there certainly should
be an app for almost any other popular video website to upload video clips.
Even if I was interested in using those services, I have what I like to call a Bino Internet
connection or broadband in-name only.
It was a lot faster to transfer the files directly across my network than it would be to
upload them to the internet and pull them back.
I've been using ES or E-Strong File Explorer to connect my droid phone to the Wi-Fi and
transfer files to my PCs that way.
The File Explorer allows you to browse all the folders on the phone, including internal
storage, and that's without rooting the phone.
It connects to some bus shares and FTP servers, though it is most convenient if you configure
the workstations on your network with static IPs.
When you're in the Strong's File Explorer, if you click on the local tab which is the
default, you'll see a button that just has a forward slash on it for root.
If you click that button, you'll see the root folder of your phone and all the subfolders
under it.
Now, I don't know where your pictures be stored necessarily on my HTC Android.
I navigate to forward slash, all lowercase, Edward, Mike, Mike, Charlie, forward slash,
all uppercase, David, Charlie, India, Mike, forward slash, 100, all uppercase, Mike, Edward,
David, India, Alpha.
Or if you were to look at it, it would be the root slash EMMC slash DCIM slash 100 media.
And that's where I find both my video and my static photographs.
Now, what you're in the folder that you want to work in, on media files to view them,
all you have to do is touch the file name and eStrons will play the file because, of
course, there it's going to look like a camera folder, it's going to be pictures 001,
pictures 002, no description or anything like that.
Now, to select files in that folder for copying to another device, in the toolbar, there's
what they call a multi-select icon, it has kind of a picture of a file plus a plus sign
on top of it, so it shouldn't be blamed for mistaking it for a new folder icon.
But that function is actually, if you press the hardware menu key and then the menu comes
up, there's a new selection.
If you select files, you press that multi-select icon to a bar, it'll light up, so you know
that it's active, and then with your finger, you can press on each of the files that you
want to designate individually.
It's just like doing a control click on a computer with a mouse, when you can de-select
file the same way, and they'll light up or not light up as you click on them.
When you have the files that you want to transfer selected, again, press the hardware menu
key, select operations, then select copy, now you have to go to your target folder.
So you have two choices, either LAN or FTP, so if you're looking for a soma share, say
on a PC, or I'm guessing a Macintosh, I haven't tried it with my Macs yet, select LAN.
If you have one of your computers or computer on the internet even, set up as an FTP server,
select FTP.
If you don't already have your server set up, then of course you're going to have to
click add and create your server, and you do that by plugging in the IP address, that's
why it's more convenient to use static IPs, otherwise you're going to have to look at
if, config, see what your IP is today, and plug that in, and then every time you use
the file transfer, you're going to have to create your set up a new.
But you need the IP address of the target workstation, and of course your username and
password.
Now on the soma share, you're going to be able to see every folder on that machine that
your login would have access to if you were sitting directly on the machine.
So it doesn't matter if it's an admin or a limited login under Windows, you're going
to see the contents of every drive and every folder, whether they've been specifically
shared in Windows or not, for some people that might be a security concern.
And under FTP, it's pretty much the same thing, if the user can't you plug in can be elevated
to root as it can be on all devian based distros, then you're going to see every folder
that you could get into if you were sitting at the workstation, in other words, everything
on the machine, assuming it's your machine, you know, full-blown login.
The reason I use FTP on the Linux box, on Russ Winner's Tech-A-Geek webpage, he has
a fine tutorial prepared by Kevin Wisher that goes through everything you'd ever want
to know about enabling soma shares in Linux.
Unfortunately, I've never made it all the way through that yet, and it's fairly easy
in Linux just to install from the command line an FTP server.
In my case, I'm using Pro FTPD.
Now FTP services can easily be stopped and started from the terminal, so if you have
physical access to the machine, in other words, if it's in the same room, best practice
would be to go into your startup configuration and make sure that that FTP server does not
start with the machine by default.
If I'd ever taken time to do that, I could tell you exactly how that should be done.
Okay folks, I'm going to interrupt myself a minute to patch in this edit.
Where I left off, I just glibbly said something about if I'd ever gotten around to figuring
out how to fix the security hole introduced by leaving an open FTP server on my network
and I would tell you how to do it.
Well, I sat down the other day and got around to figuring it out.
If you're using Pro FTPD as your FTP server, like I am, then you can edit the Pro FTPD.CONF file.
Pro FTPD.conf.
My Mint system, it's located on slash Etsy slash Pro FTP, FTPD slash Pro FTPD.conf.
Other distributions, you might just find it in slash and we're Tango Charlie slash Peter
Romeo, October, Frank, Tango, Peter, David.Charlie, October, November, Frank.
The file itself is pretty well-common, like a lot of these rebuilt configuration files.
There's a lot of common and out options and then pretty detailed explanation about what
happens if you remove the hash symbol to make the option active.
So if you scroll down where it says default root, if you notice that after that you have
a tilde and what that does, tilde is the universal symbol for your own home folder.
So if you comment it out in front of default root, when you FTP in your system, instead
of seeing the contents of your entire file system, you'll be limited just to the files
in your home folder.
Now I modified that since I had a downloads directory in my home folder, I just made
that tilde slash downloads.
Now if you have multiple users on your system, you need to remember that each one of those
users would have to have a downloads folder in their home folder or an X folder X being,
you know, tilde slash X, whatever you decide to make it, but all your users have to have
that same folder, I'm not sure exactly what the results would be.
And if you scroll down right below that, there's a section for port.
And of course the fault port for FTP is 21.
And so if you comment that out and set it to something uncommon, generally you can probably
use just about any four digit number.
You've got a service running and it's not for public consumption.
It's always best to set it to something different than the default port.
And of course when you're logged in with an FTP client, there should be a field to plug
in the port number.
Okay, that takes care of opening up the whole hard drive or the whole file system with
FTP.
And now what they didn't take into account when they designed the FTP servers that you
might not want it to run all the time, most cases FTP servers are going to run on a machine
that you're not logged into all the time, it can change it.
If you have a Debian based system like Debian or Ubuntu or Mint, anything like that, you
can install our Cconn, Robert Charlie, Charlie, October, November, Frank.
It may not be installed by default and it's the Debian Run Level Configuration Tool.
And it's sort of like running services.msc or MSconfig in Windows that you can, it's a text
type menu like the text installer that you see on many Linux installs, but essentially
you just get a window or a menu that you can scroll through with all the services that
are starting out by default.
And the ones that are set to start will have an asterisk in a box, and if you want to
make that service not stop, you scroll down to that line and hit the space bar and a
asterisk will disappear and the next time you boot up that service will come up by default.
So I unchecked service proFTPD and then when I want to connect to my Mint box from one
of my other computers, I just opened up a terminal and run sudo service proFTPD start.
And when I'm done, I can type in the same terminal window sudo service proFTPD stop, sorry
proFTPD or stop.
All right.
Next back to our regularly scheduled discussion.
Okay.
Back at the point, FFMPEG is a scary powerful command line utility for converting media formats.
And to me, it's always just been plain scary.
If you look at the man page, FFMPEG has more switches than the 747.
Many of the graphical media tools including players and Linux are making calls to FFMPEG
in the background.
So knowing that I would need some help, I hit Google to find some real world examples
of converting video from the .3GP format to something a little more common.
Meanwhile while I was doing my research, I opened one of the .3GP clips in my keynote
movie editor.
The first thing it told me was that the file was not a digital video file.
In other words, it wasn't raw video.
So it had to convert it into that format.
The keynote expanded a 200 megabyte .3GP video clip to a gig-and-a-half .dv raw video
file.
And I'm going to be wrong.
Kino is excellent for editing video from my digital tape camera by capturing the raw
video stream where I then I can cut it up into individual clips, cut out the parts that
I don't want, rearrange it, and export it into the appropriate format.
But in this case, I just wanted to transfer the two clips as is without doing any editing.
And I thought there might be a more efficient way to do that than running them through
Kino.
While I had VLC open, I also tried to convert the file using the functions in VLC.
But I never came up with any useful outputs, so undoubtedly I was doing something wrong.
While I was learning to use FFMPEG along the way I learned a little trick, FFMPEG expects
at minimum arguments for the input and output files, i.e. FFMPEG, space, dashi, space,
input file, space output file.
If you just want to see the particulars of a video file, just codec, resolution, frame
rate, frequency and bit rate, you can issue FFMPEG, dashi, space, just the input file.
FFMPEG will give you an error saying that you did expect an output file, but it will
show you your report of what it sees in the file.
And in the discussion notes, at this point, I've added the output from FFMPEG on one of
my .3GP files.
And parts that I can interpret, the video clip is 7 seconds, I'm sorry, 7 minutes, 21 seconds
and some change long.
It was quoted a bit rate of 3,015 KPPS, 3,015 kilobits per second.
It was encoded in the MPEG 4 video format at 800 by 480, it's using the AMR audio codec
recorded at 8,000 hertz mono.
Now at the end of the article, I've also have a link to Wikipedia page that shows the
various common recording formats.
The lowest one is 8,000 hertz and it's equivalent to telephone communications, which since
we're recording with a phone, that's probably not a surprise.
I compared this to a raw digital video file that I recorded with my Sony digital camera.
My Sony digital tape cam, actually the phone has slightly better resolution, but the
audio codec is significantly higher frequency in stereo, so it beats the phone there.
Okay, when you're issuing this command, do not forget the dashi before the input file
name.
You forget it, FFMPEG will assume that the file name is the output, and it will ask,
are you sure you want to do this?
If you absent mindedly say yes, I believe FFMPEG will happily overwrite the video file with
the input you specify, which is nil.
With the help of various examples I found using Google, and there are links at the end
of the discussion notes, I was able to come up with a set of arguments for FFMPEG, which
transferred my phone video into something suitable for YouTube.
As I said before, someone may be able to suggest a more optimal set of parameters, and I invite
comment and criticism so I can learn myself what I could have done more effectively.
Now that YouTube accepts high death, I couldn't find anything on the side about their preferences
for upload parameters, except keep it under 15 minutes and 2G.
With my slow internet, 40 megabytes for 10 minute clip is more my speed, and I believe
more considerate of the end viewer.
And I'm not sure, except for high death video, does YouTube render the stream the same for
every clip, regardless of the quality of the input, I'd really like to know when I
re-download my video via tinyog.com to my computer, it all comes out with the same parameters,
but that may be an artifact of how they convert video on tinyog.
Since I couldn't find their current video requirements on YouTube, I found an old reference
to it, and I'll tell you the FFM head command that I eventually issued that was successfully
created an output video, and then we'll go through and deconstruct each argument in that
command.
On command line, of course I browse to the folder where the input video resided, and typed
in, FFMPEG, space-i, space, video, 002.3GP, space-b, space, 564kb, space-s, space, 320x420,
space-vcodec, space, MPEG4, space-r, space, 30,000, forward slash, 2001, space, AR, space,
22,050, space, youtube1.avi, again, and I'm sure you're tired hearing me say this by now,
you can look to the discussion notes to find that command, and we'll start at the end
of the video, and we'll see you in the next video, and I'll see you in the next video,
be choosing between .tar versus .zip or gzip, that's an imperfect analogy I realize.
I suspect that some codecs are more compatible with certain containers, and it may be possible
to choose a combination that actually degrades the video quality.
Clot 2 made an excellent and comprehensive presentation on codecs in the early days
of hacker public radio, and I encourage you to check that out.
And he also recently discussed the effect of frequency and bit rate on the new world order,
which you can find his podcast at thebadapples.info.
Okay, we'll start back at the beginning on parameters.
The first one being dashi, video, 002.3GP.
This resonates the input file.
I believe you could specify parameters such as codec and bit rate on the input side,
but if FFNP can't detect the correct parameters, I doubt if overriding what it thinks
is going to produce the best output.
Next parameter, dash b, space, 564kb, video, bit rate.
Now, Mr. Hussain recommends a bit rate of 700 to 1000 kilobits for YouTube video.
And if you look at his site, note that he omitted the kb in his example.
Without it, FFNP can interpret the parameter as 800 bits per second and refuses to process the video at that low bit rate.
You need to either include kb after the number or add the appropriate number of zeros.
In my case, 800 kilobits per second produced a file that came out three or four times the size of what I've been used to getting
for a similar length clip from keynote.
The keynote export menu gives you various selections,
four high definition, four DVD, four broadband, four dial-up, etc.
And I looked at the bit rate, four broadband, which keynote has set at 564kb,
so that's how I arrived at that particular number.
It's good enough for me and my output resulted in a file that was under 40 Mac.
Going back to Kletoo's recent podcast, bit rate determines how many pixels can change from one frame to the next.
Set it to low and the video looks pixelate.
Next parameter, dash S, space, 320x240.
Self-explanatory, that's the output resolution.
Now, remember, our source clip was recorded at 800 by 480.
So, for YouTube, we're reducing the resolution of the clip.
In the past 320x240, I believe, was the default that YouTube asked for.
And I'm not sure that submitting a clip in higher resolution would improve the quality once it's up on the website.
Next parameter, dash V codec, space, mpeg4.
I selected mpeg4 for the video codec.
I had success with keynote uploading clips that were encoded in mpeg4.
The original video was an mpeg4.
And I suspect that mixing and matching video codecs on the input side and on the output side could introduce loss.
And I've not tried uploading a Dioro video to YouTube, but I assume it would work just fine.
Next parameter, dash R, space, 30,000, slash, 1,001.
In other words, you're doing a little inline math here, dividing 30,000 by 1,001.
This is the audio bitrate.
It represents the rate of change over time in the audio.
Again, there are people who speak better to this than I can.
I was just using the recommendation on Mr. Sane's site.
And that math comes out to be approximately 29.97003 frames per second, which is the old standard for NTSC or American Standard Definition Video.
Other online references recommend a discrete value somewhere between 27 and 30.
The default, if you leave the dash R argument out, is 64, which I found odd because ffmpeg would refuse to process the video,
unless I did give it a specific dash R value.
Perhaps that's an artifact of my codec selection.
Next parameter, dash AR, space, 22,050.
This is the audio frequency, which represents the range of the discrete audio frequencies that can be reproduced.
Higher numbers produce higher fidelity.
In other words, 22,050 is probably good enough for speech, but not good enough for music.
Note that the input frequency on the original file was only 8,000 hertz.
Now, I can't magically improve the fidelity by selecting a higher output frequency.
So, why did I?
Simply put, the selected output codec refused to accept a lower number, which brings us to the next parameter.
Dash A codec, space, not specified.
In other words, if you go back and you look at the ffmpeg command I issued, I didn't put in a value for dash A codec.
So, it's not dash A codec blank.
That's not in there at all.
The default is MP2.
ffmpeg supports MP3, but the codecs that ffmpeg's acknowledges are determined by your software distribution.
And even in mint, the default ffmpeg does not support MP3.
Some of the references I found stated ffmpeg actually has to be recompiled with additional libraries to include support for additional codecs.
I'm not sure if that applies to just the gen 2 arch and slackware camp, or if that's all of us.
I also tried to specify Vorbus, but Vorbus won't accept mono input. Remember, our original clip was recorded in mono.
I suppose I could have tried AMR, but the reference I found so the MP2 was probably adequate, no better than the original audio that I had to work with.
And this brings us to the next parameter which I didn't actually use.
Dash AC, also not specified, audio channel, channel.
Ergo, dash AC, one would be mono, dash AC, two would be stereo.
Alright, those parameters produced what I thought to be the acceptable output for my first clip.
On the second video, I found that above settings were fine for large objects.
Actually, I was doing owner interviews at a truck show, but facial features tended to be washed out,
especially when my human subjects moved around.
Again, I'm not sure that uploading in a higher video quality YouTube has any effect, but when my friend asked me what happened to his face in the video, I can blame it on YouTube.
So for the second video, I issued FFMPEG, space-i, space, video, 003.3gp, space-b, space, 800kb, space-s, space, 800x480, space, dash-v to codex, space,
L-I-B-X-264, space-r, space, 30,000, divided by 1001, space, AR, space,
22,050, space, YouTube2.avi.
As you can see, I increased the video bit rate to 800kb per second, and I left the resolution at 800x480, the same as the input clip.
And then I used the freedom-hating H.264 video codec, my file size increased to a still manageable 120 megabytes.
Looking at the two videos on YouTube, I affect the one encoded with the higher numbers, looks a little better, but I'm going to need to look at it again when I get to a faster broadband connection.
One note on the designator for the video codec, L-I-B-X-264. A lot of codec seemed to be referenced as L-I-B-something or other, but apparently that parameter was once just X.264.
You're probably going to have to Google around and see what's appropriate for your kernel, your distro, and your version of FFMPEG.
If there's a man page for codec, I did not find it.
Alright, well this brings us to the references that I've been promising you at the end of the discussion.
To find out about the video container.3gp, I went to Wikipedia, typed in 3gp.
The page I found on recommended video parameters for uploading to YouTube was on shaheedwhosane.com.
Let me spell that, and I would like to apologize to the gentleman in advance if I'm not pronouncing his name correctly.
shaheedwhosane.com slash tech slash optimize-video-4-YouTube-on-linux-with-FFMPEG.
I'd like to thank these folks for their help.
I also found the page that I found useful concerning converting AVI files to 3gp to play them on the phone in the native format.
Though I don't believe you have to convert, I believe you can, you can, the phone will recognize most video formats.
But that article can be found at corregilmore.com slash blog slash 2010 slash 0-03 slash 0-05 slash use-FFMPEG-2
dash-incode-a-3gp-video-2-more-portable-formats.
And the author, and again I apologize if I'm not pronouncing that right, is Shrinivasan.
I found a nice big reference to FFMPEG-N codex by Howard Pritchett on how-pages.org slash FFMPEG.
And the reference for the various common audio sampling rates, I found that by going to Wikipedia and typing in sample rate.
So it's EN.wikipedia.org slash wiki slash sampling underscore rate.
Well that's all I have, and thank you for your time.
Again, I invite corrections and comments, which may be addressed to me personally at 5150 at the bigredswitch.comoff.com.
Thank you.
Thank you for listening to After Public Radio.
If you are sponsored by Carol.net, so head on over to CARO.ENC for all of us here.
.