3GPP to MXF Converter

3GPP to MXF: A Phone Clip Going Into a Broadcast Wrapper

A .3gpp file is the mobile world's smallest common denominator — the 3GP file format defined by 3GPP TS 26.244, built on the ISO base media structure, holding H.263 or MPEG-4 video at QCIF (176 x 144) or CIF (352 x 288) alongside an AMR narrowband voice track. MXF is the opposite end of the industry: SMPTE's Material Exchange Format, the interchange container broadcasters and post houses use for masters and deliverables. Converting one into the other is usually about ingest — a station, an archive, or an editing system will accept an MXF and will not accept a phone recording.

Expect the file to get much bigger, not smaller. That is not a bug and it is not something you can tune away with the quality controls; it falls out of two decisions the MXF path makes for you, described below.

How to Convert 3GPP to MXF

1. Upload Your 3GPP File: Drag the .3gpp onto the page or click "Add Files". Several clips can be queued and they share one set of settings.
2. Pick a Video Codec: The dropdown offers MPEG-2 and H.264, and the page resolves to MPEG-2 — the essence most MXF ingest specifications were written around. Switch to H.264 if the receiving system accepts it, because it will get far more out of the same bitrate.
3. Set File Compression, Video resolution and Trim: File Compression lists Quality Preset, Specific file size, Constant Bitrate, Variable Bitrate, Constant Quality and Constraint Quality. Video resolution opens on Keep original, with Resolution Percentage, Preset Resolutions, Width, Height and Width x Height available — this is the control that actually decides how big the output gets. Trim can be set to Time Range with a Start time and a Duration.
4. Convert and Download: Click Convert and save the .mxf. Files are uploaded over an encrypted connection, processed on our servers and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.

Why the MXF Comes Out So Much Larger

Two things happen on the way into MXF that have nothing to do with the settings you chose.

Every frame becomes a keyframe. The MXF muxer has a strict limit on how far a frame may be offset from its container position, and the pipeline avoids the problem by setting the GOP length to 1 — an all-intra stream where no frame is predicted from any other. That is a legitimate broadcast choice (all-intra material scrubs and cuts cleanly), but it is expensive. Encoding the same six-second 720 x 576 clip twice, once with GOP=1 and once with ffmpeg's default GOP, produced a 4,364,857-byte video track against 2,616,377 bytes at the same quantiser — 1.67 times larger for identical settings. Holding the bitrate fixed instead at 4 Mbps, the all-intra encode measured 38.4 dB PSNR against the source where the long-GOP encode measured 46.8 dB. The budget buys noticeably less picture.

The audio becomes uncompressed PCM. Audio Codec on this page has exactly one entry, PCM 16-bit Little Endian, because that is what MXF ingest expects. An AMR narrowband track from a phone runs at roughly 5–12 kbit/s; 16-bit PCM at 48 kHz costs 768 kbit/s per channel. The soundtrack alone can end up outweighing the video.

In one measured run a 248,091-byte .3gpp came back as a 1,690,169-byte .mxf — 6.8 times the size, from a clip whose picture is 176 x 144.

The MPEG-2 Minimum Bitrate Overrides Small Targets

MPEG-2 cannot encode reliably below a resolution-dependent floor, so the pipeline raises any target that falls under it. The floor is derived from the output pixel count and never drops below 2 Mbit/s.

Two consequences worth planning around. First, asking for a small file from a QCIF source does not work: a 300 kbit/s Constant Bitrate request is lifted to the 2 Mbit/s floor. Second, Constant Quality and Constraint Quality are both converted to that floor bitrate on an MPEG-2 output — the quantiser value you type is accepted and then discarded, because MPEG-2 has no CRF mode. On this page the modes that genuinely change the result are Quality Preset, Specific file size, Constant Bitrate and Variable Bitrate, plus Video resolution.

Frequently Asked Questions

My conversion failed and produced nothing. What is the most likely cause?

The audio sample rate. The MXF muxer implements 48 kHz audio only, and a 3GPP recording almost always carries AMR narrowband at 8 kHz. There is no audio sample-rate control on video-to-video pages, so if a clip refuses to convert, that mismatch is the first thing to suspect. The practical route is a general-purpose container instead — 3GPP to MP4 or 3GPP to MOV — or feeding the MXF stage a source whose audio is already 48 kHz.

Should I upscale the phone footage to 1080p on the way in?

Only if the receiving specification demands a fixed frame size. Upscaling 176 x 144 to 1920 x 1080 invents no detail, and because MPEG-2's minimum bitrate scales with pixel count it pushes the floor from 2 Mbit/s to roughly 7.5 Mbit/s — a much larger file carrying exactly the same picture. If a house spec requires 1080p, set Width x Height explicitly rather than relying on a percentage.

Which video codec should I choose, MPEG-2 or H.264?

MPEG-2 if the destination is a traditional broadcast ingest or an older editing system, because that is the essence most MXF operational specifications assume. H.264 if the destination accepts it: at the same bitrate H.264 keeps far more detail, and it does not carry MPEG-2's minimum-bitrate floor, so a small source can stay a small file. Note that the GOP=1 setting applies either way, so H.264 will also be all-intra here.

Will the MXF carry timecode and the metadata MXF is known for?

Not from this source. MXF's rich KLV metadata and timecode tracks exist because professional cameras and playout systems write them; a .3gpp from a phone has none of that to carry over, so what you get is a structurally valid MXF wrapping your picture and sound with no production metadata attached. If an ingest system requires specific reel names, timecode start or UMIDs, those have to be applied by the tool that owns that workflow.

Is the output an OP1a file or an Avid OP-Atom file?

A single self-contained file with the picture and sound together, which is the OP1a shape. Avid's OP-Atom convention splits each essence track into its own file and is produced by Avid's own media engine, not by a general converter. If your target is an Avid bin, expect to import and transcode inside Media Composer rather than dropping this file into an OP-Atom media folder.

Why is there only one entry in the Audio Codec dropdown?

Because MXF is used almost exclusively with uncompressed PCM in the workflows it was designed for, so the page offers PCM 16-bit Little Endian and nothing else. That also means you cannot compress the audio to save space, and you cannot drop the audio track from this page. If uncompressed sound is the problem, MXF is the wrong container for what you are doing.

Does converting to MXF improve the quality of a phone clip?

No. Re-encoding can only preserve or lose detail, never restore it — the H.263 or MPEG-4 compression already baked into the .3gpp stays baked in, and the MPEG-2 or H.264 pass adds its own losses on top. What MXF gives you is compatibility with systems that will not open a phone file, at the cost of size and one generation of quality.

Can I convert only a section of a long recording?

Yes. Set Trim to Time Range and give a Start time and a Duration; both accept plain seconds or HH:MM:SS.sss. This is worth doing before rather than after, since the trimmed range is what gets encoded — an all-intra MPEG-2 stream with uncompressed audio grows quickly, so cutting first keeps the output manageable.

What is the difference between .3gpp, .3gp and .3g2?

.3gpp and .3gp are the same container under two spellings — the 3GP file format from 3GPP TS 26.244, with brands such as 3gp4, 3gp5 and 3gp6 recorded inside the file. .3g2 is the 3GPP2 variant used by CDMA networks, which registers a slightly different codec set. Our converter dispatches on the file extension, so if a tool rejects your file, renaming between .3gpp and .3gp is harmless — the bytes are unchanged.

How are my uploads handled?

Your file is uploaded over an encrypted connection, converted on our servers and deleted automatically after a few hours, along with the MXF it produced. There is no sign-up, no watermark and files are never shared or made public. 3GPP sources are small, so upload time is rarely the constraint here — the download of the much larger MXF is more likely to be.