ffmpeg are essentially the same thing. [as of VERY recently there is SOME divergence, but not really much to write home about if you compile your own
ffmpeg [the one provided in Ubuntu repos for instance is OLD and suffers from that video size is not a blah blah blah deal [basically tries to tell you the video has wrong proportions], but if you bother to read the
ffmpeg compile guide and compile it from git it has none of the issues of the older versions that come stock in most OSes. the depreciation warning referring to
avconv is telling you that they have created a newer util to try and replace
ffmpeg, BUT it is SO extensively used that even if they tried to cut it off we would all be creating softlinks from
ffmpeg anyways so they are not going to stop work and drop it.]]
It is not a bad thing to use
avconv, I just saw the one reply mentioning the depreciation warning which is essentially an empty message should be more of for an alternative to ffpmeg you could try avconv which is more true to the case here.
avconv -i inputfile.flv -map 0 -c:v libx264 -c:a copy outputfile.mp4
is really the SAME as
ffmpeg -i filename.flv -vcodec libvpx -acodec libvorbis
essentially in the first you are using the shorter-handed options and in the second is the more written out variety.
-map 0 is referring to audio tracks so if using something like
mp4a which can handle multi audio tracks just fine you can leave this off to copy all audio streams to the resulting file. This is only required if using a codec which does not support multiple audio tracks in the same file then you would want to map the needed audio and not all. Of course if trying to minimize space used you could specify just one to try and knock a little bit of size off the file [audio is like maybe a 1/3 the size of the video track [and that's being generous]].
-c:v = codec(video) so:
-c:v libx264 is same as using:
-vcodec libx264 FYI; same with this example:
-c:v copy = -vcodec copy
and furthermore for FLVs be careful the flv file is the same as an avi in that it is a container which can contain any number of codecs for either video or audio. You would want to first use media inspection utility of choice to see what is used within the file itself before you choose to either just copy the video and/or audio stream or if you would want to transmux it from whatever it was to something new. So the command that works best for one FLV may not be the same for another FLV [of course USUALLY if getting multiple FLVs from same source they will be encoded the same way but it is never a guarantee].
Not trying to nit pick just ran across this in web search and wanted to try to help clarify things for folks a little.
Again as this answer states for the reply below this one YES running ffmpeg will always post that message it is essentially hollow as these 2 utils are really still just the same util with very little difference. You should in almost all cases get the exact same results using either command.
This is not necessarily going to result in a full re-transcode, why? A, if it is not needed it saves a ton of time, and B if you re-transcode a file it has already been compressed in to a video codec you are essentially running a compression routine against something that is already compressed and will always result in less quality than the source.
Most newer codecs are somewhat cross compatible [not all] like for instance an flv could techinically be an MP4 within an FLV wrapper since FLVs like AVIs are just containers of other codecs. So, it depends on what the source flv has for the video and ausio codec compared to what you are converting it to as to whether it needs to be transcoded at all. If within the FLV they used the H264 MP4 video and MP4a for audio you would not need to re-transcode the thing you would only need to copy it out and adjust the file headers so it is read as a true MP4 instead of an MP4 video inside an FLV file.