Why FLV Still Appears in Linux Workflows
FLV files rarely arrive on purpose. They show up as byproducts: an old screen recorder that defaulted to Flash Video, a lecture archive pulled from a legacy portal, a client handoff from a pipeline built a decade ago, or a batch of recordings lifted from a discontinued streaming service. On Linux the file plays in some players and refuses to open in others, and the moment you try to import it into a modern editor, upload it to a platform, or send it to a colleague, the format becomes a problem.
The fix is not complicated, but there is a fast way and several slow ways to do it. A naive re-encode of a large library can take hours and quietly degrade quality. A smart remux can finish in seconds with zero loss. Knowing which situation you are in, and which command or tool to reach for, is the entire skill.
This guide covers the practical paths: FFmpeg for speed and control, batch scripts for volume, graphical tools like HandBrake for one-off jobs, plus the error messages you will eventually hit and the decision criteria that keep you from wasting time.
FLV vs MP4: Containers, Codecs, and What Really Changes
Container versus codec
The most common source of confusion is treating FLV and MP4 as if they were codecs. They are not. They are containers, the box that holds video, audio, subtitles, and metadata streams together with instructions on how to play them back.
FLV is a simple, streaming-oriented container designed for a plugin-based web player. MP4 is a standardized container built around indexed metadata, which is why playback can start instantly, seek precisely, and survive being copied to a phone, a TV, or a browser without a plugin.
What matters far more than the container is what is inside it. An FLV file usually carries H.264 video with AAC audio, which is exactly what MP4 expects. When that is the case, converting is a matter of rewriting the wrapper.
When MP4 support stops and conversion begins
MP4 is broadly accepted: browsers, mobile devices, video editors, social platforms, learning management systems, and hardware players all read it. FLV is accepted by a shrinking set of legacy tools.
Compatibility is not the only benefit. An MP4 with proper indexing gives you frame-accurate scrubbing, faster timeline performance in editors, better thumbnail generation, and predictable handling of chapter markers and embedded subtitle tracks. For anyone building a repeatable media workflow, standardizing on MP4 removes an entire category of downstream surprises.
When you can remux instead of re-encode
If the video stream inside the FLV is already H.264 and the audio is AAC, MP3, or another MP4-friendly codec, you can copy the streams without touching a single frame. This is called remuxing, and it runs at disk speed rather than encode speed. A one-hour recording might remux in five to fifteen seconds.
If the audio is MP3, remuxing still works and is fully playable, though some strict players prefer AAC. If the video is an old Flash-era codec such as Sorenson Spark or VP6, or if the audio is Nellymoser or PCM, remuxing will produce a file that technically has an MP4 extension but will not play everywhere. In that case, a real re-encode is required.
Check before you commit:
ffprobe -v error -show_streams -select_streams v:0 input.flv | grep codec_name
ffprobe -v error -show_streams -select_streams a:0 input.flv | grep codec_name
Two clean lines of output (h264 and aac) mean you are on the fast path.
FFmpeg: The Fastest Route From FLV to MP4
FFmpeg is the reference implementation for nearly every other video tool, including most graphical converters. Learning four or five of its flags covers the overwhelming majority of real jobs.
Install and verify
sudo apt install ffmpeg # Debian, Ubuntu, Mint
sudo dnf install ffmpeg # Fedora
sudo pacman -S ffmpeg # Arch
ffmpeg -version
The basic conversion command
ffmpeg -i input.flv -c:v libx264 -crf 20 -preset medium -c:a aac -b:a 192k output.mp4
Reading it left to right: the input file, the video encoder, the quality target, the speed/compression trade-off, the audio encoder, the audio bitrate, and the output. Add -movflags +faststart to move the index to the front of the file, which lets players and browsers begin playback before the download finishes:
ffmpeg -i input.flv -c:v libx264 -crf 20 -preset medium -c:a aac -b:a 192k -movflags +faststart output.mp4
Stream copy for compatible files
ffmpeg -i input.flv -c copy -movflags +faststart output.mp4
If the output plays, you are done and you have lost nothing. If it plays video but not audio, or the duration looks wrong, fall back to a full re-encode. Never assume; always spot-check the first file of a batch before running it across five hundred files.
Controlling quality: CRF, presets, and bitrate
The constant rate factor (CRF) is the quality dial. Lower means higher quality and larger files. Sensible ranges for H.264:
- CRF 16-18: archival masters, visually near-lossless
- CRF 19-21: excellent for delivery, the usual sweet spot
- CRF 22-24: good quality with noticeably smaller files
- CRF 26+: visible artifacts in motion-heavy footage
The preset controls how much CPU time the encoder spends finding compression opportunities. ultrafast, veryfast, medium, and slow are the common stops. veryfast is often only a few percent worse in quality than medium at the same CRF but two to three times faster, which makes it the best default for bulk work.
Fixed bitrate encoding is only worth using when a platform demands a specific target. For everything else, CRF gives better quality per megabyte.
Hardware acceleration on Linux
If you have an NVIDIA card, h264_nvenc or hevc_nvenc can cut encode times dramatically:
ffmpeg -hwaccel cuda -i input.flv -c:v h264_nvenc -preset p5 -cq 23 -c:a aac -b:a 192k output.mp4
Intel and AMD users can try h264_vaapi or h264_qsv, but VAAPI setups need correct device initialization and can be fiddly. The honest trade-off: hardware encoders are much faster but usually produce larger files at equivalent visual quality. For a one-off conversion, hardware is great. For a library you will store for years, software encoding at veryfast is often the better long-term choice.
Audio, subtitles, and metadata
If the FLV has no audio stream, -c:a aac is simply ignored, so you can safely use the same command everywhere. If it contains embedded subtitles or timecode tracks, FFmpeg copies compatible ones automatically with -c copy and drops unsupported ones with a warning. You can map streams explicitly:
ffmpeg -i input.flv -map 0:v:0 -map 0:a:0? -c:v libx264 -crf 20 -c:a aac output.mp4
The ? makes the audio mapping optional, preventing a hard failure when no audio exists. Metadata such as title and comment carries over by default; add -map_metadata 0 if you want to be explicit.
Batch Conversion: Turning One Command Into a Folder-Wide Pipeline
Most real projects involve dozens or hundreds of files. A shell loop handles them without any additional software.
A safe sequential loop
for f in *.flv; do
ffmpeg -hide_banner -loglevel error -i "$f" \
-c:v libx264 -crf 20 -preset veryfast \
-c:a aac -b:a 160k -movflags +faststart \
"${f%.flv}.mp4"
done
The "${f%.flv}.mp4" pattern strips the old extension and appends the new one, and the quotes handle filenames with spaces. Run it in a copy of the folder the first time.
Parallel jobs for speed
On a multi-core machine, encoding one file at a time wastes most of the CPU. Four parallel jobs is a reasonable starting point:
find . -name '*.flv' -print0 | xargs -0 -n1 -P4 -I{} \
sh -c 'ffmpeg -hide_banner -loglevel error -i "$1" -c:v libx264 -crf 20 -preset veryfast -c:a aac "${1%.flv}.mp4"' _ {}
Tune -P to your core count. More parallel jobs than cores usually slows everything down because each encoder competes for memory bandwidth.
Recursing through nested folders
When a library has subfolders, find -execdir keeps outputs next to their sources. Always test with -print before adding the conversion command. A dry run that lists filenames costs nothing; a half-finished batch that overwrites originals costs a lot.
Skip files that are already converted
for f in *.flv; do
out="${f%.flv}.mp4"
[ -f "$out" ] || ffmpeg -hide_banner -loglevel error -i "$f" -c:v libx264 -crf 20 -preset veryfast -c:a aac "$out"
done
This makes long batches resumable: rerun the script after an interruption and it picks up where it stopped.
Graphical Options: HandBrake and Other Desktop Tools
Not everyone wants a terminal. HandBrake is the strongest graphical transcoder on Linux and wraps the same underlying engines in a preset-driven interface.
HandBrake settings that matter
- Preset: start with a general MP4 preset, then adjust.
- Video codec: H.264 for compatibility, H.265 for smaller files when your players support it.
- Quality: constant quality around 20-22 gives results comparable to FFmpeg's CRF 20.
- Encoder preset: the slider from Fast to Slow mirrors FFmpeg's speed presets.
- Audio: AAC at 160-192 kbps, stereo unless the source is genuinely surround.
- Web optimized: enable it for the same effect as
+faststart.
Batch queueing is HandBrake's quiet strength: add a whole folder, apply one preset, and let it run overnight.
Other tools worth knowing
Simple converters like WinFF offer a friendlier front end to FFmpeg and are fine for quick jobs with no custom settings. VLC can remux or re-encode through Convert/Save but gives you very little control over quality. Kdenlive and Shotcut will import FLV and export MP4, which is convenient when you were going to edit the clip anyway, but they are heavyweight for a pure format change.
Choosing Your Workflow: Decision Criteria
Use this as a quick triage before touching a single file.
- One file, modern codecs inside, no editing needed: remux with
-c copy. - One file, needs a clean universal result: re-encode with CRF 20 and
veryfast. - A folder of files, no time pressure: sequential loop overnight.
- A folder of files, deadline today: parallel loop, or hardware encoding if the quality drop is acceptable.
- You need frame-accurate cutting and titles: import into an editor and export MP4.
- You are uncomfortable with command lines: HandBrake with a preset and a queue.
- You need to keep the originals untouched: always write to a new filename, never in place.
If you are unsure whether a file needs remuxing or re-encoding, run ffprobe first. Ten seconds of inspection saves an hour of encoding.
Common Errors and How to Fix Them
"Unknown decoder" or "Invalid data found"
The file may be corrupted, truncated, or mislabeled. Try ffmpeg -err_detect ignore_err -i input.flv ... to push past minor damage. If the file was recovered from a failing disk, expect artifacts regardless of the command.
A conversion that completes instantly and produces a tiny file
The stream copy failed because the codecs are not MP4-compatible, and FFmpeg wrote an almost empty container. Confirm with ffprobe on the output, then re-encode properly.
No audio in the output
The source audio is a legacy codec such as Nellymoser or PCM, which AAC cannot copy. Force a re-encode with -c:a aac -b:a 192k and check the mapping with -map 0:a:0?.
Video plays but runs twice as fast, or audio drifts out of sync
This usually points to a variable frame rate source or damaged timestamps. Try -vsync cfr -r 30 to force a constant frame rate, or -fflags +genpts to regenerate missing timestamps. Screen recordings are the usual culprits.
Encoding is painfully slow
Check that -preset veryfast is actually set, that hardware acceleration is available if you expect it, and that you are not running ten parallel jobs on four cores. Also verify libx264 is present rather than a stripped-down fallback build.
Output is huge
CRF too low, or a preset that is doing a lot of work for marginal gain. Move from CRF 18 to 21, or from slow to veryfast, and compare a sample clip side by side before committing to a whole library.
Quality, Storage, and Archive Considerations
Treat conversion as a one-way door. Each re-encode loses a little information, so never convert an already-converted file just to change settings. Keep the FLV originals until you have verified the MP4s play end to end, then archive or delete them deliberately rather than by accident.
Use a consistent naming scheme. project-name_episode-03.mp4 beats output_final_v2.mp4 every time, especially when a folder fills with conversions. If you are producing derivatives for different platforms, keep one high-quality master and generate the smaller versions from it, not from each other.
For long-term storage, H.264 at CRF 19-21 remains the safest choice: universally decodable, hardware-accelerated on virtually every device, and well understood by every archive tool. H.265 cuts file size by roughly a third at similar quality but costs compatibility in older browsers and players. AV1 is even more efficient and increasingly supported, but encoding is slow enough that it rarely makes sense for a rescue job on legacy footage.
Finally, verify your results. Play a converted file for thirty seconds, seek to the middle and the end, and check that audio stays in sync. A batch that finishes successfully is not the same as a batch that produced good output.
Automating Conversions in a Bigger Video Pipeline
Once one conversion works, the natural next step is a script that runs unattended. A dependable pattern: watch an inbox folder, convert anything that lands in it, write results to an outbox, and log failures to a text file you can review later. The skip-if-output-exists check makes the whole thing idempotent and safe to rerun.
If the footage feeds an editing workflow, standardize early. Convert to MP4 with a constant frame rate and a predictable resolution before importing into a timeline, and you avoid the classic patchwork project where every clip behaves differently. If it feeds a publishing workflow, generate your delivery variants from the master with a fixed set of FFmpeg commands stored in version control, so the same input always produces the same output.
The broader media landscape keeps moving toward standardized containers, and the tools that generate unusual formats tend to be the ones that disappear first. Building a small, documented conversion step into your pipeline now is cheap insurance against the next legacy format that lands in your inbox.
FAQ
Is converting FLV to MP4 lossy?
It depends entirely on the method. If the video and audio streams are already MP4-compatible, a remux copies them bit for bit and the result is lossless. A full re-encode with H.264 is technically lossy, though at CRF 19-21 the difference is invisible in normal viewing.
How long should a conversion take?
A remux of a one-hour file takes seconds. A software re-encode of the same file might take ten to forty minutes depending on resolution and preset. Hardware encoding can cut that to a few minutes at the cost of larger output.
Can I convert FLV to MP4 without FFmpeg?
Yes. HandBrake, VLC, WinFF, Kdenlive, and Shotcut can all do it graphically, and most of them use the same encoding libraries underneath. FFmpeg is simply the most direct and scriptable route.
Will I lose quality if I keep converting the same file?
Only if you re-encode repeatedly. Each generation of re-encoding adds a little more compression damage. Convert once from the original and work from that master.
What if the FLV has no audio track?
Nothing breaks. The audio options are ignored, and the output MP4 contains video only. Using an optional audio mapping avoids error messages from FFmpeg.
Should I choose H.264 or H.265 for the output?
H.264 unless you have a specific reason to do otherwise. It plays everywhere, encodes quickly, and is hardware-accelerated on nearly all devices. H.265 saves space but narrows compatibility and encodes more slowly.
Does the MP4 extension alone make a file playable?
No. Renaming an FLV to MP4 does not convert anything. Players that sniff file contents will still see FLV data, and players that trust the extension will fail. Always run a real conversion.
How do I convert an entire folder without overwriting originals?
Write outputs to a separate directory or use a distinct naming pattern, and include a check that skips files whose output already exists. Test on a small sample folder first, then run the full batch.
A Short Pre-Flight Checklist
Before starting any conversion job, confirm the source codecs with ffprobe, decide whether a remux is possible, pick a CRF and preset, verify you have enough free disk space for a full duplicate of the library, and test one file end to end. Those five minutes are what separate a clean, boring, successful conversion from an afternoon of debugging a half-finished batch of unplayable files.
