Convert 3GPP to MTS — Free Online Tool
Convert 3GPP mobile video files (.3gp) to MTS (AVCHD) format, re-encoding the H.264 video and AAC audio into an MPEG-2 Transport Stream container used by Sony and Panasonic camcorders. Ideal for bringing low-bitrate mobile footage into professional video editing workflows that expect broadcast-compatible MTS files.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your 3GPP file here
or click to browse
Free — no uploads, no signups. Your files never leave your browser.
Settings
Note: Browser-based encoding uses approximate quality targets. For precise CRF compression, copy the FFmpeg command above and run it on your desktop.
Estimated output:
Conversion Complete!
DownloadHow It Works
3GPP files use a lightweight MP4-derived container optimized for mobile transmission, typically carrying H.264 video at low bitrates and AAC audio at reduced quality (often 64k or below). During this conversion, the H.264 video stream is re-encoded using libx264 with a CRF of 23, which increases the bitrate headroom and output quality relative to the highly compressed mobile source. The AAC audio is re-encoded at 128k — double the 3GPP default — to produce cleaner audio in the MTS output. The resulting file is wrapped in an MPEG-2 Transport Stream (.mts) container, which structures data in fixed 188-byte transport packets as required by the AVCHD standard, making it compatible with camcorder-oriented editing software like Sony Vegas, Premiere Pro, and Final Cut Pro when handling MTS footage.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg binary — the open-source multimedia processing engine that handles all demuxing, decoding, encoding, and muxing for this 3GPP-to-MTS conversion. |
-i input.3gp
|
Specifies the input 3GPP file. FFmpeg reads the MP4-derived container, demuxes the H.264 video and AAC audio streams, and decodes them for re-encoding into the MTS output. |
-c:v libx264
|
Re-encodes the video stream using the libx264 encoder, producing H.264 video compatible with the AVCHD MTS container. A full re-encode is required here because the MPEG-2 Transport Stream framing of MTS is incompatible with a direct stream copy from the 3GPP MP4 container. |
-c:a aac
|
Re-encodes the audio using FFmpeg's native AAC encoder. The 3GPP source audio is also AAC, but decoding and re-encoding is necessary due to the container change, and the bitrate is being increased from the typical 3GPP mobile default to 128k for improved output quality. |
-crf 23
|
Sets the Constant Rate Factor for libx264 to 23, the standard default. This produces a visually balanced quality level for H.264 in the MTS output — lower values like 18 would yield sharper video at larger file sizes, while higher values like 28 would compress further but degrade the already limited quality of the 3GPP source. |
-b:a 128k
|
Sets the AAC audio bitrate to 128k in the MTS output, which is double the 64k default used by 3GPP files. This ensures the audio track in the MTS file meets the quality expectations of AVCHD camcorder workflows and professional NLEs. |
output.mts
|
Specifies the output filename with the .mts extension, which signals FFmpeg to mux the encoded H.264 video and AAC audio into an MPEG-2 Transport Stream container structured in 188-byte packets as required by the AVCHD standard. |
Common Use Cases
- Merging smartphone-recorded 3GPP clips with Sony or Panasonic camcorder MTS footage in a timeline that expects a consistent AVCHD format
- Ingesting older 3G-era phone videos into professional NLEs like Sony Vegas or Edius that are optimized for AVCHD MTS workflows
- Archiving or cataloging mobile event footage alongside existing MTS camcorder recordings in a unified AVCHD library
- Preparing low-bitrate 3GPP clips for broadcast post-production pipelines that require MPEG-2 Transport Stream delivery
- Upconverting 3GPP footage captured on legacy Nokia, Samsung, or feature phone devices into a format accepted by modern video editing suites without manual codec configuration
- Standardizing a mixed batch of mobile and camcorder clips to MTS before handing off to an editor who works exclusively in an AVCHD environment
Frequently Asked Questions
No — the 3GPP source is already lossy-compressed at a low mobile bitrate, and re-encoding cannot recover detail that was discarded during original capture. The output MTS file will be encoded at a higher bitrate with CRF 23, which means it won't degrade further, but the ceiling of quality is set by the original 3GPP file. Think of it as preserving the best possible rendition of a low-quality source rather than genuinely upscaling it.
3GPP files are intentionally compressed to tiny sizes for transmission over 3G/4G mobile networks, often at bitrates of 100–500 kbps. MTS, as an AVCHD format designed for camcorder recording and broadcast use, targets much higher bitrates — typically several megabits per second. Re-encoding with libx264 at CRF 23 and AAC at 128k will produce a file sized proportionally to the video duration and resolution, not the original compressed 3GPP size. A 10 MB 3GPP clip could easily become 50–150 MB as MTS.
3GPP files do not support subtitles or chapters, so there is no subtitle or chapter data to carry forward. MTS supports subtitles in principle, but this conversion does not add any — the output will be video and audio only. If you need to add subtitles to the MTS file after conversion, that requires a separate step using an SRT or other subtitle source.
Yes — the -crf flag controls video quality. For MTS output, valid CRF values range from 0 (near-lossless, very large file) to 51 (very low quality, smallest file). The default here is 23, which is a balanced midpoint. For high-quality output suitable for broadcast or archival, use CRF 18 or lower. For smaller files where quality is less critical, CRF 28–30 is reasonable. Changing -crf 23 to -crf 18 in the command will noticeably improve sharpness, at the cost of a larger MTS file.
On Linux or macOS, you can run: for f in *.3gp; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.3gp}.mts"; done. On Windows Command Prompt, use: for %f in (*.3gp) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.mts". This loops over every .3gp file in the current directory and produces a corresponding .mts file with the same base name.
The -movflags +faststart flag is specific to MP4-family containers (including 3GPP) and moves the moov atom to the beginning of the file to enable progressive web streaming. MTS uses an MPEG-2 Transport Stream container with a completely different structure — fixed 188-byte packets — which does not use moov atoms at all. That flag is therefore not applicable to MTS output and is correctly omitted from this command.
Technical Notes
3GPP (.3gp) is a subset of the MPEG-4 Part 12 container, purpose-built for mobile networks and constrained devices. Its audio is commonly AAC at 64k or below, and its video H.264 at resolutions like 176×144 (QCIF), 320×240 (QVGA), or occasionally 640×480. MTS, the file extension for AVCHD streams, wraps H.264 (AVC) video and AAC or AC-3 audio inside MPEG-2 Transport Stream packets. Because both formats share H.264 as a video codec, the libx264 encoder used here is compatible with both source expectations and output requirements — but a full re-encode is still necessary because the container structure and packet framing differ entirely. No stream copy shortcut is possible between these two containers. The output MTS file will not carry over 3GPP-specific metadata such as GPS location tags or device information, as MTS has no equivalent metadata fields for these. Multiple audio tracks and chapters are unsupported in 3GPP input, so the MTS output will be single-stream audio only. The audio bitrate is raised from the 3GPP default of 64k to 128k in the output, which improves fidelity for the re-encoded AAC stream within the limits of the source material.