Convert HEVC to MXF — Free Online Tool
Convert HEVC/H.265 video files to MXF for professional broadcast and post-production workflows. This tool re-encodes the H.265 stream into H.264 inside an MXF container — the format expected by broadcast ingest systems, NLEs like Avid, and professional archive pipelines.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your HEVC 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
HEVC/H.265 and MXF are fundamentally incompatible in a simple remux scenario — MXF's broadcast-oriented codec roster (H.264, MPEG-2, MJPEG) does not include H.265, so the video stream must be fully re-encoded. This tool decodes the HEVC input and re-encodes it to H.264 using libx264 at CRF 23, a visually high-quality setting. Audio, if present in the HEVC file, is encoded to PCM S16LE — uncompressed 16-bit linear PCM — which is the standard lossless audio format used in broadcast MXF deliverables. The result is an MXF OP1a file suitable for ingest into broadcast playout systems and professional editing suites.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg application — in the browser this runs as a WebAssembly binary (FFmpeg.wasm); on the desktop it calls your locally installed FFmpeg executable to perform the HEVC-to-MXF conversion. |
-i input.hevc
|
Specifies the HEVC input file. FFmpeg reads this raw HEVC bitstream and decodes the H.265 video for re-encoding into H.264. |
-c:v libx264
|
Sets the video encoder to libx264, which re-encodes the decoded HEVC frames as H.264 — the video codec required for this MXF output, since MXF's broadcast-standard codec roster does not include H.265. |
-c:a pcm_s16le
|
Encodes audio as uncompressed 16-bit signed little-endian PCM, the standard lossless audio format for broadcast MXF deliverables that is required by most playout and ingest systems. |
-crf 23
|
Sets the Constant Rate Factor for the H.264 encode to 23, a high-quality default. Since this is a full transcode from HEVC, keeping the CRF low (18–23) minimizes generation loss compared to the original compressed source. |
-b:a 192k
|
Specifies a 192 kbps audio bitrate — this applies as a reference target but is effectively overridden by the PCM S16LE codec, which is uncompressed and not bitrate-constrained in the traditional sense. It is included for compatibility with FFmpeg's muxer defaults. |
output.mxf
|
The output filename with the .mxf extension, which instructs FFmpeg to use its MXF muxer and wrap the re-encoded H.264 video and PCM audio into an MXF OP1a container for broadcast and professional post-production use. |
Common Use Cases
- Delivering camera footage shot in HEVC (e.g., from a GoPro, Sony, or DJI drone) to a broadcast facility that requires MXF ingest packages
- Preparing H.265-encoded archive files for import into Avid Media Composer or other NLEs that expect MXF-wrapped H.264 or MPEG-2
- Converting streaming or OTT source files encoded in HEVC to MXF for frame-accurate offline editing in a professional post-production environment
- Transcoding HEVC content from consumer devices into a broadcast-safe MXF container with uncompressed PCM audio for compliance with delivery specifications
- Creating MXF versions of HEVC-encoded rushes for playout servers or broadcast automation systems that cannot decode H.265 natively
- Generating an H.264/MXF proxy file from a high-efficiency HEVC master for archive or QC review in a broadcast facility
Frequently Asked Questions
The MXF specification as implemented in broadcast environments defines a fixed set of allowed video codecs — primarily H.264, MPEG-2, and MJPEG. H.265/HEVC is not part of the standard MXF OP1a codec set supported by most broadcast tools and playout systems. Because of this codec incompatibility, the video stream must be fully decoded from HEVC and re-encoded as H.264 before it can be wrapped in an MXF container. This means conversion takes longer than a simple remux and involves a generation loss in video quality.
Yes, there will be some generation loss because the HEVC stream is decoded and then re-encoded into H.264. H.265 is significantly more compression-efficient than H.264 — it achieves similar visual quality at roughly half the bitrate — so re-encoding to H.264 at CRF 23 will produce a larger file with slightly different compression artifacts. For most professional purposes the output at CRF 23 is visually high quality, but if you are working from a heavily compressed HEVC source, the perceptual impact may be more noticeable. Use a lower CRF value (e.g., 18) for higher fidelity output.
PCM S16LE (16-bit signed little-endian uncompressed audio) is the standard audio format for broadcast MXF deliverables and is required by many broadcast facility ingest specifications. It is fully lossless and universally compatible with professional playout systems, NLEs, and audio workstations. Compressed audio formats like AAC, while supported by the MXF container, are often rejected by broadcast ingest systems that expect uncompressed PCM. If your HEVC file contained compressed audio, this step is technically a quality improvement since PCM introduces no further compression artifacts.
MXF is a metadata-rich container format, but basic stream metadata such as framerate, aspect ratio, and pixel format are preserved through the re-encode. However, embedded HDR metadata (HDR10 static metadata or Dolby Vision dynamic metadata) from the HEVC source is not carried through to the H.264/MXF output because H.264 in standard MXF implementations does not support HDR signaling in the same way. Custom tags, GPS data from drone footage, or camera model metadata embedded in the HEVC source will generally not be transferred to the MXF output.
The CRF value in the command controls H.264 output quality. Lower values produce higher quality and larger files — CRF 18 is considered near-lossless for H.264, while CRF 28 produces noticeably compressed output. To change it, modify the '-crf 23' flag, for example: 'ffmpeg -i input.hevc -c:v libx264 -c:a pcm_s16le -crf 18 -b:a 192k output.mxf'. The CRF scale runs from 0 (lossless) to 51 (worst quality), so adjusting from 23 to 18 will significantly increase file size while improving fidelity.
Yes. On Linux or macOS you can run the command in a shell loop: 'for f in *.hevc; do ffmpeg -i "$f" -c:v libx264 -c:a pcm_s16le -crf 23 -b:a 192k "${f%.hevc}.mxf"; done'. On Windows Command Prompt use: 'for %f in (*.hevc) do ffmpeg -i "%f" -c:v libx264 -c:a pcm_s16le -crf 23 -b:a 192k "%~nf.mxf"'. Because HEVC-to-H.264 re-encoding is CPU-intensive, batch processing can take considerable time for large or high-resolution files.
Technical Notes
HEVC to MXF conversion is a full transcode operation — not a remux — because the MXF OP1a format does not include H.265 in its standard codec set for broadcast use. The libx264 encoder wraps the output in an MXF container using FFmpeg's MXF muxer, which targets OP1a (single item) operational pattern, the most widely supported MXF variant in broadcast environments. The default CRF 23 for H.264 output produces files noticeably larger than the HEVC source at equivalent visual quality, since H.264 requires roughly double the bitrate of H.265 to match it perceptually. If the HEVC source contains HDR10 or HLG metadata, this will be lost in the H.264 re-encode because standard MXF/H.264 delivery chains are SDR-centric; a separate HDR-aware workflow would be needed to preserve that information. PCM S16LE audio in MXF is uncompressed at 16-bit depth, which is CD-quality and meets most broadcast audio specifications; if your source was 24-bit audio, you may want to swap the audio codec to 'pcm_s24le' for higher fidelity. MXF's multiple audio track support is available in this container but the default command maps a single stereo pair; multi-track audio from the source would need explicit stream mapping flags to preserve.