Initializing... drag & drop files here
Supports: RAF
A RAF is a Fujifilm raw capture — one still photograph stored as unprocessed sensor data. An .mts file is a video stream, the extension camcorders write when they record AVCHD. Turning one into the other means rendering the raw frame and then holding that single picture on screen for a set number of seconds, which produces a static, silent clip rather than moving footage.
This tutorial covers the settings that matter, the codec in the list that cannot work from a still, and the one thing most pages about this conversion get wrong: the file you get is an H.264 transport stream named .mts, which is not the same thing as an AVCHD-compliant recording.
.RAF files onto the page or click "+ Add Files" to browse. Queue several at once — "Merge strategy" opens on "Merge images", which lays every upload into one clip in sequence; switch it to "Video per image" to get a separate MTS for each photo.Before encoding, our pipeline re-renders the raw frame as a clean PNG and clamps it to 4,096 px on the long edge, rounding both dimensions down to an even number. That matters because Fujifilm sensors are far bigger than that ceiling: a 40.2 MP X-T5 writes a 7728 × 5152 raw file, so the sanitised frame lands at exactly 4096 × 2730 before anything is encoded. The clip is then written at 1 frame per second with B-frames disabled, because identical frames gain nothing from bidirectional prediction and B-frames add a start-time offset at that rate.
Three settings do most of the work:
| Property | AVCHD as specified | What this converter writes |
|---|---|---|
| Video codec | MPEG-4 AVC/H.264 (MVC for 3D) | H.264 by default; H.265, MPEG-2, MPEG-4, DivX and Xvid also selectable |
| Audio | Dolby Digital AC-3 (64-640 kbps) or Linear PCM | None — the audio control is hidden on image-to-video, so the clip is silent |
| Container | MPEG-2 Transport Stream | MPEG-2 Transport Stream, 188-byte packets (the plain framing .mts gets, not the 192-byte BDAV framing .m2ts gets) |
| Maximum resolution | 1920 × 1080 | Up to 4096 px on the long edge — above the AVCHD ceiling |
| System bitrate | 24 Mbps or lower | Set by your Quality Preset, not clamped to the AVCHD budget |
| Disc structure | BDMV/STREAM folder layout on the card or disc | A single loose file, no folder structure |
Source for the left column: the AVCHD Format specification published by the format's co-promoters.
| Property | RAF (Fujifilm raw) | MTS (as produced here) |
|---|---|---|
| What it holds | Undeveloped sensor readout, one frame | Rendered RGB frames in a transport stream |
| Bit depth | 14-bit on X-series bodies; 14 or 16-bit on GFX | 8-bit, 4:2:0 after encoding |
| Colour filter array | X-Trans on most X-series; a conventional primary-colour array on GFX | Not applicable — already demosaiced |
| Motion | None, it is a photograph | Plays as a clip, but the picture never changes |
| Audio | None | None on this path |
| Editing latitude | Full — white balance, exposure and highlight recovery still adjustable | Baked in |
| Typical size | Tens of megabytes per frame | Small; a motionless frame compresses heavily |
If the goal is a clip anyone can play, MTS is the wrong container to reach for. Nothing about this file needs a transport stream — RAF to MP4 produces the same rendered frame in a container that phones, browsers and editors all accept, and it is the better default unless a specific tool has told you it wants .mts. If what you actually want is a picture rather than a clip, stop here and use RAF to JPG instead. And if you need the Fujifilm look baked in, develop the RAF in Capture One, Lightroom, RawTherapee or Fujifilm's own software first, export a finished image, and convert that.
No, and it is worth being precise about why. The AVCHD specification requires H.264 video paired with Dolby Digital AC-3 or Linear PCM audio, inside an MPEG-2 transport stream, at 1920 × 1080 or below, laid out in a BDMV folder structure. This conversion gives you the H.264 video and the transport stream, but the clip has no audio track at all, the frame can be larger than 1080p, and it is a single loose file. Call it an H.264 transport stream with an .mts name — that is accurate, and it sets the right expectation for whatever you feed it to.
Packet framing, decided by the output extension. .mts is written as plain 188-byte MPEG-2 transport stream packets, with the 0x47 sync byte at the very start of the file. .m2ts gets BDAV framing instead: 192-byte packets, each prefixed with a 4-byte arrival timestamp, which pushes the sync byte to offset 4. Some Blu-ray-oriented tools care about that difference and some do not, so match the extension your target software asks for.
Because there is nothing to move. A single photograph held for five seconds is five identical pictures, so the encoder is given one frame per second and told to hold it, with B-frames switched off. The playback duration is what you set under "Image Duration"; the frame rate only affects how the encoder describes the stream. It also has a side effect worth knowing: MPEG-1 refuses to encode at that rate, which is why that codec option cannot succeed here.
Yes, completely. A RAF stores what the sensor measured — 14-bit values on X-series bodies, 14 or 16-bit on GFX — which is why exposure, white balance and highlight recovery stay adjustable while the file is still raw. Encoding to MTS demosaics that data, renders it to 8-bit, and then throws away chroma detail in the 4:2:0 conversion every H.264 stream uses. Keep the original .RAF as your master; treat the MTS as a disposable delivery file.
Upload them all and leave "Merge strategy" on "Merge images". Each photo is held for the Image Duration you set and they play back to back in one clip, which is a slideshow in the literal sense — cuts, no crossfades or motion. If you would rather have a separate file per photo, switch to "Video per image" and each RAF becomes its own one-shot clip.
By default, whatever your photo is after the 4,096 px clamp, because "Video resolution" opens on "Keep original". A 40.2 MP X-T5 frame at 7728 × 5152 comes out at 4096 × 2730; a 102 MP GFX100 II frame at 11648 × 8736 comes out at 4096 × 3072. If you need a specific size — and for anything AVCHD-adjacent you do — set "Fixed Resolutions" to 1920 × 1080, or use "Preset Resolutions", which sets the height and lets the width follow your photo's aspect ratio.
No. Provia, Velvia, Astia, Classic Chrome and Acros are instructions applied when a renderer develops the raw data, not pixel values stored inside the RAF. Any neutral development ignores them, which is why the clip can look flatter than the preview on the back of the camera. If the look matters, apply it in a RAF-aware developer, export a TIFF or JPEG, and build the clip from that file instead.
Not from your side — both are .raf and both go through the same path. Under the hood they are different sensors: most X-series bodies use the X-Trans colour filter array, a 6 × 6 non-Bayer pattern, while Fujifilm's GFX medium-format bodies use a conventional primary-colour array (the GFX100 II spec sheet lists a "102MP CMOS II HS with primary color filter"). Demosaicing an X-Trans pattern is a harder problem and different renderers reach slightly different answers, so a very close pixel-level match between two converters is not something to expect.
The practical limit is upload size and time rather than anything on your end — Fujifilm raw files routinely run 40-80 MB each, and lossless-compressed 102 MP GFX files are larger still. Your file travels over an encrypted connection, is rendered and encoded on our servers, and is deleted automatically after a few hours. It is never shared or made public, there is no sign-up, and nothing is watermarked.