Convert MXF to TS — Free Online Tool

Convert MXF broadcast media files to MPEG-2 Transport Stream (TS) format, re-encoding the video with H.264 and the audio with AAC — making professional production footage ready for broadcast playout, HLS streaming pipelines, and live distribution systems that require TS-compatible containers.

FFmpeg Command

Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg

Free — no uploads, no signups. Your files never leave your browser.

Estimated output:

Conversion Complete!

Download

How It Works

MXF files typically carry H.264, MPEG-2, or MJPEG video alongside PCM audio (16-bit or 24-bit), which is the professional lossless audio standard used in broadcast ingest. During this conversion, the video stream is re-encoded from whatever codec the MXF contains into H.264 using libx264, and the PCM audio is transcoded into AAC at 128k — a lossy compression step that significantly reduces file size while remaining broadly compatible with TS-based broadcast and streaming systems. MXF metadata such as timecodes, clip names, and embedded descriptors cannot be carried into the TS container, as TS does not support MXF's rich metadata model. The output TS file uses MPEG-2 Transport Stream packetization, which segments the multiplexed audio and video into 188-byte packets designed for robust transmission over lossy broadcast channels.

What Each Flag Does

Flag What it does
ffmpeg Invokes the FFmpeg binary — the open-source multimedia processing engine that performs the MXF decode, video re-encode, audio transcode, and TS mux operations in this conversion.
-i input.mxf Specifies the input MXF file. FFmpeg will probe the MXF container to identify its operational pattern (OP-Atom or OP-1a) and detect the internal video codec (which may be H.264, MPEG-2, MJPEG, or others depending on the camera or ingest system that created the file) before decoding begins.
-c:v libx264 Re-encodes the video stream to H.264 using the libx264 encoder, regardless of what video codec the source MXF contains. H.264 is required for TS files destined for HLS streaming, broadcast playout systems, and CDN delivery.
-c:a aac Transcodes the audio from the MXF's native PCM (typically pcm_s16le or pcm_s24le) to AAC, which is the standard lossy audio codec for TS-based broadcast and streaming. AAC is mandatory for HLS compatibility and is natively decoded by all modern broadcast receivers and streaming clients.
-crf 23 Sets the H.264 Constant Rate Factor to 23, FFmpeg's default quality level. For broadcast-quality MXF source material this is a reasonable distribution-quality setting; reduce this value (e.g., -crf 18) to improve fidelity at the cost of a larger TS file.
-b:a 128k Sets the AAC audio bitrate to 128 kilobits per second. This is sufficient for stereo distribution and streaming, but if the MXF source contains broadcast-grade 24-bit PCM audio intended for a critical delivery, consider increasing this to 256k or 320k to better preserve the perceived audio quality.
output.ts Defines the output filename and instructs FFmpeg to mux the encoded H.264 video and AAC audio into an MPEG-2 Transport Stream container, using the standard 188-byte TS packet structure required for broadcast transmission, HLS segmentation, and IPTV playout.

Common Use Cases

  • Preparing camera-original MXF footage from Sony or ARRI cameras for ingest into an HLS streaming pipeline that requires TS-segmented input
  • Delivering a finished broadcast programme stored as MXF to a playout server or transmission encoder that only accepts MPEG-2 Transport Stream files
  • Converting MXF rushes with 24-bit PCM audio to AAC-in-TS for upload to a CDN or streaming platform that does not support MXF containers
  • Extracting a broadcast-ready TS file from an MXF archive for use in live streaming software like OBS or FFmpeg-based ingest pipelines
  • Converting MXF dailies to TS format for compatibility with IPTV middleware systems or set-top boxes that decode MPEG-2 Transport Streams natively
  • Producing a TS test stream from MXF production files to validate broadcast chain compatibility before transmission

Frequently Asked Questions

No — MPEG-2 Transport Stream does not support the rich metadata model that MXF provides. MXF embeds timecode tracks, clip names, umid identifiers, and descriptive metadata in its structural metadata layers, none of which have equivalent fields in the TS container format. The TS output will contain only the video and audio elementary streams. If preserving timecode is essential, you should retain the original MXF file as your archive master and use the TS purely for distribution.
Yes, this conversion involves a lossy audio transcode. MXF commonly stores audio as pcm_s24le (24-bit, 48 kHz PCM), which is lossless and used throughout professional broadcast post-production. The TS output uses AAC at 128k, which is a perceptually compressed format. For most distribution and streaming use cases the quality difference is not audible, but if you are delivering a broadcast master you may want to use a higher AAC bitrate (such as 256k or 320k) by modifying the -b:a flag in the FFmpeg command.
A remux (stream copy) would only be possible if the video codec in the MXF is already H.264 and is structured in a way that is directly compatible with TS packetization. However, many MXF files carry MPEG-2 video or MJPEG, which are not valid for direct placement into a TS file intended for H.264 distribution. To ensure a universally compatible output, the tool re-encodes the video to H.264 using libx264. If you know your MXF already contains H.264 and want to avoid re-encoding, you can change -c:v libx264 to -c:v copy in the FFmpeg command.
Video quality is controlled by the -crf flag, where lower values produce higher quality and larger files — 0 is mathematically lossless H.264, 23 is the default, and 28–35 is suitable for lower-bitrate distribution. To increase audio quality from the default 128k AAC, change the -b:a value to 192k, 256k, or 320k. For example: ffmpeg -i input.mxf -c:v libx264 -c:a aac -crf 18 -b:a 256k output.ts would produce a higher-quality output suitable for broadcast mastering.
Yes. On Linux or macOS you can use a shell loop: for f in *.mxf; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.mxf}.ts"; done. On Windows Command Prompt use: for %f in (*.mxf) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.ts". This is particularly useful when converting a batch of MXF dailies or archive files for a broadcast delivery or streaming ingest workflow.
Yes — MPEG-2 Transport Stream is the native segment format for HLS (HTTP Live Streaming). The H.264 video and AAC audio produced by this conversion are precisely the codecs required by the HLS specification and are supported by virtually all CDNs, iOS devices, Android players, and smart TVs. If you are building an HLS stream, you would typically pass the TS output to a segmenter (such as ffmpeg with the hls muxer) to split it into .ts segment files with an accompanying .m3u8 playlist.

Technical Notes

MXF (Material Exchange Format) is a professional wrapper standardised under SMPTE 377M, designed to carry audio, video, and rich metadata for broadcast ingest and post-production. The format supports OP-Atom and OP-1a operational patterns, and MXF files from different manufacturers (Sony XDCAM, ARRI AMIRA, Panasonic P2) may use different internal codecs including DNxHD, MPEG-2 Long GOP, AVC-Intra, MJPEG, or plain H.264. This tool defaults to libx264 encoding with CRF 23, which is codec-agnostic at the input side — FFmpeg will decode whichever video codec the MXF contains and re-encode it to H.264 for the TS output. The AAC audio transcode from PCM will be the most perceptible quality step-down; 24-bit PCM used in broadcast masters carries significantly more dynamic range than 128k AAC, so consider raising the audio bitrate for critical deliveries. The TS container supports multiple audio tracks and subtitles, both of which are valid in FFmpeg output, but MXF subtitle or closed caption data (such as VANC-embedded CEA-708) will not automatically be mapped to the TS output without explicit stream mapping flags. File size will typically be substantially smaller than the MXF source, particularly when the source contains MJPEG or uncompressed video, since H.264 at CRF 23 is a highly efficient codec by comparison.

Related Tools