Convert 3GPP to TS — Free Online Tool
Convert 3GPP mobile video files to MPEG-2 Transport Stream (TS) format, re-encoding with H.264 video and AAC audio — transforming compact mobile-optimized content into a broadcast-ready container compatible with HLS streaming pipelines, digital TV systems, and live streaming workflows.
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 typically contain H.264 video and AAC audio encoded at very low bitrates optimized for 3G mobile networks. During this conversion, FFmpeg re-encodes the video stream using libx264 with a CRF of 23 (a medium-quality constant rate factor setting) and re-encodes the audio to AAC at 128k — a significant bitrate upgrade from the typical 32–64k found in 3GPP files. The output is wrapped in an MPEG-2 Transport Stream container, which uses a packetized structure designed for robust transmission over unreliable channels. Unlike the 3GPP container's MP4-derived box structure, TS uses fixed-size 188-byte packets, making it inherently seekable and resilient during live or broadcast transmission. No metadata, subtitle tracks, or chapter markers from the 3GPP file are carried over, as 3GPP does not support those features in this context.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg binary — the open-source multimedia processing engine that handles the demuxing of the 3GPP input, the re-encoding pipeline, and the muxing into the TS output container. |
-i input.3gp
|
Specifies the input 3GPP file. FFmpeg automatically detects the container format and identifies the video and audio streams inside — typically H.264 video and AAC or AMR audio encoded for 3G mobile delivery. |
-c:v libx264
|
Re-encodes the video stream using the libx264 H.264 encoder. Even if the 3GPP source already contains H.264, re-encoding is necessary to ensure the output conforms to the bitrate and profile expectations of a broadcast TS stream rather than a mobile-optimized encode. |
-c:a aac
|
Re-encodes the audio stream to AAC using FFmpeg's native AAC encoder. 3GPP files sometimes carry AMR (Adaptive Multi-Rate) audio — a codec designed exclusively for voice on mobile networks — which is not supported in TS containers, making this re-encode essential for compatibility. |
-crf 23
|
Sets the Constant Rate Factor for the H.264 encode to 23, FFmpeg's default quality level. For 3GPP source material that was heavily compressed at mobile bitrates, CRF 23 ensures the re-encode does not introduce additional quality loss while maintaining a reasonable output file size. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second — typically double or quadruple the audio bitrate found in 3GPP mobile files, bringing the audio quality up to a standard suitable for broadcast and streaming delivery in the TS container. |
output.ts
|
Specifies the output file with the .ts extension, instructing FFmpeg to mux the encoded video and audio into an MPEG-2 Transport Stream container using fixed 188-byte packets — the format required for broadcast playout systems, HLS segmenters, and live streaming pipelines. |
Common Use Cases
- Ingesting old 3GPP video clips recorded on early smartphones into a broadcast playout system or IPTV chain that requires TS-wrapped H.264 content
- Preparing mobile-captured footage for use in an HLS (HTTP Live Streaming) pipeline, where TS segments are the standard delivery unit
- Archiving 3GPP videos from legacy 3G-era devices into a more universally supported container that media servers and video editors can reliably open
- Feeding 3GPP content into a video processing workflow that uses FFmpeg-based tools expecting TS input for transcoding or segmenting
- Converting user-generated 3GPP clips into TS format for integration into a digital signage or broadcast automation system
- Upgrading the audio quality of 3GPP recordings — which often cap at 64k AAC or MP3 — to the 128k AAC standard expected in broadcast-grade TS files
Frequently Asked Questions
Not automatically — re-encoding a 3GPP file to TS with CRF 23 will produce output quality bounded by the source. Since 3GPP files are typically encoded at very low bitrates for mobile transmission, the original compression artifacts are baked into the pixel data and cannot be recovered by the conversion. What does change is that the output is encoded at a higher quality ceiling (CRF 23 targets a much higher bitrate than typical 3GPP encodes), so there's no additional quality loss from the re-encoding step beyond what the source already contains.
3GPP files are deliberately engineered for minimum file size — they target 3G mobile bandwidth constraints, often encoding video at sub-500kbps and audio at 32–64k. The TS container encodes the same content with a higher-quality H.264 pass at CRF 23 and AAC audio at 128k, which alone is double or quadruple the original audio bitrate. Additionally, the TS container's 188-byte packet structure introduces fixed overhead that MP4-derived containers like 3GPP do not have. Expect the output file to be several times larger than the source.
Yes — MPEG-2 Transport Stream is the native segment format for HTTP Live Streaming (HLS). The H.264 video and AAC audio codecs produced by this conversion are precisely the baseline codec combination required by the HLS specification and supported across all Apple devices, Android players, and web browsers. To use the output in an HLS workflow, you would further segment the TS file using FFmpeg's hls muxer or a dedicated packager.
No. 3GPP containers can store mobile-specific metadata such as GPS coordinates, device information, and recording timestamps in atom-based structures inherited from the MP4 specification. The MPEG-2 Transport Stream format does not have equivalent metadata atoms, so this information is not carried over during the conversion. If preserving metadata is important, extract it from the 3GPP file separately using a tool like ExifTool before converting.
Yes — the -crf flag controls video quality. Lower values mean higher quality and larger files: CRF 18 is near-visually lossless for H.264, while CRF 28 is noticeably compressed. For 3GPP source material that was already heavily compressed on mobile, going below CRF 20 rarely produces meaningful improvement since the source artifacts are already present. A CRF between 20 and 25 is a practical range for this conversion. You can also raise the audio bitrate from 128k to 192k or 256k with -b:a 192k if the source audio quality warrants it.
Yes. On Linux or macOS, you can loop over all 3GP files in a directory with: for f in *.3gp; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.3gp}.ts"; 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.ts". This applies the same codec settings to every file in the folder, outputting a matching TS file for each.
Technical Notes
The MPEG-2 Transport Stream format was designed for environments where packet loss is expected — broadcast satellite, cable, and over-the-air TV — which is why its 188-byte packet structure includes error correction metadata absent from the 3GPP/MP4 container model. The libx264 encoder used in this conversion supports the full range of H.264 profiles; by default it targets the Main profile, which is compatible with broadcast decoders and HLS players. The 3GPP source may contain video encoded at Baseline profile (common on early mobile devices), so the re-encode actually upgrades the profile compatibility. One important limitation: 3GPP does not support multiple audio tracks, subtitles, or chapters, so none of those features can be synthesized during conversion even though TS supports multiple audio tracks and subtitles natively. If you need to add subtitle streams to the output TS, you would need to supply them separately via an additional -i input in the FFmpeg command. The absence of -movflags +faststart in the TS output command is intentional — that flag is specific to MP4/MOV containers and has no meaning for Transport Stream files, which are inherently designed for sequential streaming without requiring a relocated index atom.