Convert MXF to 3GP — Free Online Tool
Convert professional MXF broadcast files to 3GP format optimized for 3G mobile delivery, re-encoding video with H.264 and audio with AAC to meet the low-bandwidth constraints of the 3GP container. This tool is especially useful for repurposing broadcast-grade MXF content for mobile viewing without requiring server-side processing.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your MXF 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
MXF is a professional broadcast container that typically carries high-bitrate video encoded with H.264, MPEG-2, or MJPEG alongside uncompressed or lightly compressed PCM audio. Converting to 3GP requires a full transcode of both streams: video is re-encoded using H.264 with a CRF quality setting optimized for mobile screens, and audio is re-encoded from PCM (common in broadcast MXF) down to AAC at a much lower bitrate suitable for 3G streaming. The 3GP container imposes strict constraints — it supports only a single audio track, no subtitles or chapters, and requires video dimensions to be divisible by 2, which the scale filter enforces. Broadcast-specific MXF metadata such as timecodes, reel names, and OP-Atom structural metadata is not carried over into 3GP.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg tool, which handles all decoding, filtering, and re-encoding. In the browser version, this runs via FFmpeg.wasm compiled to WebAssembly — no files leave your machine. |
-i input.mxf
|
Specifies the input MXF file. FFmpeg will detect the MXF container and identify the internal video (H.264, MPEG-2, or MJPEG) and audio (PCM, AAC) streams automatically. |
-c:v libx264
|
Re-encodes the video stream using the H.264 codec (libx264), which is one of only two video codecs supported by the 3GP container. This is required even if the source MXF already contains H.264, because the video must be reprocessed for the mobile-optimized output settings. |
-c:a aac
|
Re-encodes the audio to AAC, the default and most compatible audio codec for 3GP. This is essential when the MXF source contains uncompressed PCM audio (standard in broadcast), converting it to a compressed format suitable for mobile bandwidth constraints. |
-crf 23
|
Sets the Constant Rate Factor for H.264 video quality. A value of 23 is the libx264 default and produces a good quality-to-filesize balance for mobile screens; lower values (e.g., 18) increase quality and file size, while higher values (e.g., 35) shrink the file further at visible quality cost. |
-b:a 64k
|
Sets the AAC audio bitrate to 64 kilobits per second, which is appropriate for voice and speech content delivered over 3G networks. This is significantly lower than the PCM audio in the source MXF, reflecting 3GP's design for constrained mobile bandwidth rather than broadcast fidelity. |
-vf scale=trunc(iw/2)*2:trunc(ih/2)*2
|
Applies a video filter that rounds the output width and height down to the nearest even number. This is mandatory for H.264 encoding in 3GP and handles broadcast MXF sources that may have non-standard or anamorphic pixel dimensions that could otherwise cause an encoding error. |
output.3gp
|
Defines the output filename and tells FFmpeg to write a 3GP container. The .3gp extension triggers FFmpeg to use the 3GPP muxer, which enforces the container's mobile-optimized structural constraints including the single-audio-track limitation. |
Common Use Cases
- Repurposing a broadcast news segment stored in MXF for distribution to mobile journalists or field reporters on 3G-connected devices
- Delivering a short promotional clip or event highlight reel — originally mastered in MXF for broadcast — to a mobile audience in markets where 3G is the primary network
- Archiving lightweight mobile-viewable proxies of MXF master files for quick on-the-go review without accessing the full broadcast asset management system
- Converting MXF footage from a broadcast camera (such as an XDCAM or P2 recording) into a 3GP file for embedding in a legacy mobile web portal or WAP site
- Producing a mobile-compatible version of a broadcast interview or documentary clip to share via MMS or low-bandwidth messaging platforms
Frequently Asked Questions
Yes, all MXF-specific metadata including SMPTE timecodes, reel identifiers, OP-Atom structural data, and embedded KLV metadata will be lost during this conversion. The 3GP container has no provision for broadcast timecode or production metadata — it is designed purely for lightweight mobile playback. If preserving timecodes is important, keep the original MXF master and use the 3GP file only as a delivery or preview copy.
The 3GP container only supports a single audio track, so FFmpeg will mix down or select the first audio track from your MXF file during conversion. If your MXF contains multiple separate audio stems (a common broadcast configuration), the additional tracks will be dropped. If you need to control which audio track is included, you can add '-map 0:v:0 -map 0:a:2' (for example) to the FFmpeg command to explicitly select the desired audio stream before conversion.
Yes, if your MXF contains MPEG-2 video (common in XDCAM and DVCPro HD recordings), FFmpeg must fully decode and re-encode it to H.264 for the 3GP output. This is a computationally intensive transcode, unlike a simple remux. The output quality will depend on the CRF value used — the default CRF 23 is a reasonable balance for mobile screens, but the inherent resolution and detail of the MPEG-2 source will influence the final result.
The '-vf scale=trunc(iw/2)*2:trunc(ih/2)*2' filter ensures that the output video dimensions are divisible by 2, which is a hard requirement for H.264 encoding in the 3GP container. Broadcast MXF files sometimes have odd pixel dimensions due to anamorphic or non-standard sensor configurations. Removing this filter could cause FFmpeg to error out with a 'width or height not divisible by 2' message. It is safe to keep this filter even for standard resolutions since it effectively becomes a no-op when dimensions are already even.
Video quality is controlled by the '-crf' value: lower numbers produce higher quality and larger files (CRF 18 is near-visually lossless for mobile), while higher values reduce file size at the cost of quality (CRF 35 is noticeably degraded but very small). Audio bitrate is set with '-b:a': the default 64k is appropriate for voice content on 3G, but you can raise it to 96k or 128k for music. For example, a higher-quality command might use '-crf 20 -b:a 96k'. Note that 3GP's available audio bitrate options top out at 128k, reflecting its mobile-focused design.
Yes. On Linux or macOS you can run a bash loop: 'for f in *.mxf; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 64k -vf scale=trunc(iw/2)*2:trunc(ih/2)*2 "${f%.mxf}.3gp"; done'. On Windows Command Prompt, use 'for %f in (*.mxf) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 64k -vf scale=trunc(iw/2)*2:trunc(ih/2)*2 "%~nf.3gp"'. This is particularly useful for large broadcast archives where individual files may exceed the browser tool's 1GB limit.
Technical Notes
MXF to 3GP conversion is always a full transcode — there is no possibility of stream copying since 3GP's codec set, container constraints, and bitrate expectations are fundamentally incompatible with broadcast MXF content. PCM audio (pcm_s16le or pcm_s24le), which is ubiquitous in broadcast MXF, must be re-encoded to AAC; the default 64k bitrate reflects 3GP's mobile-streaming heritage and is sufficient for speech but may sound noticeably compressed for music or wide-dynamic-range audio. On the video side, even if the MXF source already contains H.264 (libx264), the video still needs to be re-encoded because the CRF and resolution normalization (the scale filter) require a decode-encode cycle. MXF files from broadcast cameras often use non-square pixels (anamorphic) or specific frame rates tied to broadcast standards (25fps, 29.97fps); FFmpeg will preserve the frame rate unless explicitly overridden, but if you're targeting very low-bandwidth 3G delivery, adding '-r 15' to halve the frame rate can dramatically reduce file size. The 3GP format does not support subtitles or chapters, so any closed-caption data embedded in the MXF (VANC, ANC, or sidecar) will be discarded silently.