Initializing... drag & drop files here
Supports: NEF
MXF is the wrapper broadcast, playout and archive systems ingest, and a Nikon NEF raw photo is a single still. Putting one inside the other sounds like it should be trivial. It is not, and this page is going to tell you why up front rather than after a failed job: an MXF built from a still image does not currently complete here. The reason is a frame-rate rule baked into the MXF wrapper itself, explained below, and there is no setting on this page that works around it. What does work is a two-step route through a container that accepts a one-frame-per-second still, then a wrap to MXF in the tool that owns your delivery spec. That route is the how-to further down.
MXF does not simply hold video the way MP4 or MOV do. It ties essence to a content package rate — the wrapper records what editing rate the material runs at, because downstream systems need to line frames up against timecode. That rate has to come from a fixed broadcast set. An image-to-video conversion, by contrast, encodes a still at one frame per second: there is no motion to sample, so one coded picture per second of hold is all that is needed, and nothing on this page exposes a frame-rate control to change it.
One frame per second is not in the set the wrapper will accept. In our testing, MXF writes at 1, 2, 5, 10, 12 and 15 frames per second were all refused, while every rate in the broadcast set wrote cleanly:
| Frame rate | Accepted by the MXF wrapper? |
|---|---|
| 1, 2, 5, 10, 12, 15 fps | No — refused before any data is written |
| 23.976 / 24 / 25 fps | Yes |
| 29.97 / 30 fps | Yes |
| 48 / 50 fps | Yes |
| 59.94 / 60 fps | Yes |
| 96 / 100 / 120 fps | Yes |
This is a wrapper-level rule, not a codec one, so switching Video Codec between MPEG-2 (the default here) and H.264 makes no difference — both are rejected at the same point. It is also why an MXF made from an actual video file works fine: a camera clip already carries a broadcast frame rate.
Doing the wrap in your own tool is not a workaround so much as the correct order of operations. Broadcast MXF delivery is rarely "any MXF will do" — it is a named profile with a named essence, and the system that will ingest the file is the one that knows which.
| Property | Value |
|---|---|
| Full name | Material Exchange Format |
| Standard | SMPTE ST 377-1:2019, "Material Exchange Format (MXF — File Format Specification)" |
| Type | Professional container / wrapper, not a codec |
| Essence it can carry | Many, including MPEG-2, AVC-Intra, DNxHD, XDCAM and uncompressed audio |
| Frame-rate model | Essence is tied to a content package rate from a fixed broadcast set |
| Structural variants | Operational patterns, of which OP1a (a single self-contained file) is the most common |
| Where it lives | Newsroom and playout systems, camera formats such as XDCAM and P2, MAM and archive tools |
| Where it does not | Consumer players, phones, browsers — MXF is invisible outside the industry |
Yes, but not in one step from here. Convert the NEF to a clip whose container accepts the still-image frame rate — NEF to MOV or NEF to MP4 — and then wrap or transcode that clip to MXF in the tool that owns your delivery spec. That is also the only way to hit a specific facility profile, since operational pattern, essence codec and timecode rules vary from one ingest system to the next.
Because a video file already carries a broadcast frame rate. A clip shot at 25 or 29.97 frames per second hands the wrapper a rate it recognises, so the write proceeds normally. A photograph has no rate at all, and the image-to-video path supplies one frame per second, which the wrapper refuses. Our MP4 to MXF and MOV to MXF pages take that video path.
No. The Video Codec control on this page offers MPEG-2 (the default) and H.264, but the rejection happens in the wrapper before either encoder's output is written, so both behave the same way. The frame rate is the deciding factor, and this page exposes no frame-rate control to change it.
Moving finished material between professional systems. Material Exchange Format is defined by SMPTE ST 377-1 as a container that carries picture and sound essence together with structured metadata, so a newsroom system, a playout server, a camera and an archive can all hand the same file to each other without renegotiating what is inside it. Consumer software has no reason to support it, which is why nothing on a phone or in a browser opens one.
It wraps it. MXF is a container: the picture inside might be MPEG-2, AVC-Intra, DNxHD, XDCAM or something else entirely, and the audio alongside it is commonly uncompressed PCM. This is why "we need an MXF" is never a complete specification on its own — the operational pattern and the essence codec matter just as much, and a facility that accepts one MXF profile may reject another.
Often it is not. Slates, test cards and holding images do get delivered as MXF in tapeless chains, but many systems would rather take the still as a graphic and generate the clip themselves at the project's frame rate — which sidesteps the whole problem and guarantees the result matches the timeline. Ask the ingest side whether they want a picture file or a clip before you build anything; if it is a picture they want, NEF to PNG gives them a clean full-resolution frame.
You would not want it to. Recent Nikon bodies record roughly 20 to 45 megapixels, and broadcast rasters top out far below that. Whichever route you take, set an explicit frame size that matches the delivery spec — 1920 x 1080 for HD is the usual answer — so the downscale happens once, predictably, rather than being applied unpredictably by whatever ingests the file.
Any file you upload goes over an encrypted connection, is processed on our servers and is deleted automatically after a few hours — no sign-up, no watermark, never shared or made public. Nikon raw files are large, so the upload is normally the slowest part of a job. The full list of targets available from a NEF source is on the NEF converter page.