RAF to TS Converter

Convert RAF to TS: What This Tutorial Covers

A .raf is a Fujifilm raw file. Open one in a hex editor and the first bytes read FUJIFILM CCD-RAW in plain ASCII, followed by a version string and the camera model — Fujifilm never adopted TIFF's structure for these, which is one reason generic raw readers sometimes stumble on them.

A .ts is an MPEG-2 transport stream, ISO/IEC 13818-1: a flat run of 188-byte packets built for broadcast, IPTV and HLS delivery, where losing one packet costs you a frame rather than the file.

Putting one into the other is a legitimate but unusual request — a playout system, a set-top ingest or an old segmenting tool wants a Fujifilm frame as a slate or hold card. This tutorial walks the conversion and then works through the four things that actually go wrong on it.

How to Convert RAF to TS

1. Upload Your RAF File: Drop the .raf on the page or click "+ Add Files". Queue several frames if you want them in one stream.
2. Set Image Duration and Merge Strategy: Image Duration opens at 5 seconds per frame; the list runs from 1/60s up to 10 seconds. Merge strategy opens on Merge images so several uploads become one stream, with Video per image as the alternative.
3. Choose a Codec and Quality: Video Codec selects H.264; H.265, MPEG-2, MPEG-1, MPEG-4, DivX and Xvid are also listed. File Compression opens on Quality Preset at Very High (Recommended), and Constant Quality gives you the number yourself on a 16-to-51 slider that opens at 23.
4. Set Resolution and Background, Then Convert: Video resolution opens on Keep original; Fixed Resolutions offers exact rasters such as 1920 x 1080. Background Color opens on White and fills the bars a 3:2 frame leaves in a 16:9 raster. Click Convert — files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours.

Walk-through: What Happens to 26 Megapixels

Every still is developed to a clean intermediate image and clamped to 4096 pixels on its long edge before any encoder sees it. That ceiling is where a modern Fujifilm sensor loses most of its pixels.

A 26-megapixel X-series file decoded to 6264 x 4176 in testing. The frame that reached the encoder was 4094 x 2730 — a 35% linear cut, about 57% of the pixels gone. Keep original in the resolution panel means the clamped size, not the sensor size, and there is no setting that lifts the ceiling.

What that frame then costs depends almost entirely on the quality value, because a held still is nearly free after its first frame. Breaking a 5-second encode down packet by packet: the opening key frame was 4,713,483 bytes and the four that followed were 39,420, 3,767, 536 and 351 bytes.

Measured, 5-second holds of the same clamped 4094 x 2730 frame:

The last row is the real lever: a 1080p raster cut the stream by 82%. H.265 barely helped by comparison — on a single motionless intra-coded frame there is no inter-frame prediction for a newer codec to be clever about, so its advantage largely evaporates.

One quirk worth knowing: the Quality Preset is resolution-aware. Its recommended tier is a base value of 18 calibrated at 1080p, and because a 4094 x 2730 frame carries about five times the pixels of 1080p the pipeline shifts it to 20 on the reasoning that artefacts hide better at high pixel density. If you want the strict 1080p-equivalent setting on a big frame, use Constant Quality and type 18.

Common Errors and How to Fix Them

• "The colours look flat compared to my Fujifilm JPEG" — Expected, and it is not a bug. The decoder applies the white balance your camera recorded and renders to plain sRGB. It does not apply Fujifilm's film simulations — Provia, Velvia, Classic Chrome and the rest are rendering recipes the camera applies to its own JPEG output, and they are not reproduced here. If the look matters, export from Fujifilm's own software or a raw editor that implements the simulations, then convert that image.
• "There are white bars on both sides" — Fujifilm X-series sensors are 3:2 and broadcast rasters are 16:9, so bars are geometry, not a fault. Background Color opens on White; switch it to Black, or set Video resolution to a 3:2 Width x Height and the bars disappear.
• "The stream is silent" — Correct and unavoidable here. A still image has no audio, so the pipeline writes exactly one stream and hides the audio controls. If the receiving system requires an audio PID to be present, generate a silent track and mux it in downstream.
• "My newer camera's .raf will not decode" — Fujifilm ships several raw variants per body — uncompressed, lossless compressed and lossy compressed — and new bodies sometimes introduce a new one before decoders catch up. If a file fails, try the uncompressed variant from the same shoot, or shoot uncompressed for material you intend to convert. Older X-series files are the safest.
• "The .ts will not open in my player" — Bare transport streams carry no index, so many consumer players scan badly or refuse them, and browsers will not touch one. Test in VLC or mpv, both of which handle plain .ts properly. If watchability was the actual goal, RAF to MP4 is the target.

When This Is the Wrong Conversion

If you want to see the photograph, this is entirely the wrong route: RAF to JPG gives you the full sensor resolution with no 4096-pixel ceiling, no chroma subsampling of the whole frame, and a fraction of the bytes. If you want a clip for a timeline, a website or a phone, RAF to MP4 plays where a bare transport stream does not.

Choose TS only when something on the far end names it: a DVB or ATSC playout chain, an IPTV encoder, a set-top box, or an HLS pipeline that segments into .ts. And if your workflow is AVCHD editing or Blu-ray authoring rather than broadcast, you want the 192-byte BDAV variant instead — that is a different file layout, not a rename.

Frequently Asked Questions

Does X-Trans change how my file is developed here?

Not in a way you control, but it is worth knowing what is happening. Most Fujifilm X-series bodies since the X-Pro1 in January 2012 use the X-Trans colour filter array — a 6 x 6 repeating pattern with red, green and blue on every row and column, rather than the conventional Bayer 2 x 2 — which is why Fujifilm omits the optical low-pass filter and why X-Trans files need a demosaic algorithm written for them. The decoder used here handles X-Trans, but different demosaic implementations are known to differ on fine detail and on the smearing sometimes seen in foliage. If you are chasing the last of the detail, develop in software you have chosen and convert the exported image.

Why is the transport stream not at my sensor's resolution?

Because every still is capped at 4096 pixels on the long edge before encoding. A 26-megapixel X-series frame decoded to 6264 x 4176 came out of that stage at 4094 x 2730. Nothing in the resolution panel raises the ceiling — Keep original means the clamped frame. A video container is simply the wrong destination for print-resolution pixels; export a still instead if that is what you need.

Will making the clip longer make the file bigger?

Hardly at all. At 1 frame per second with a motionless picture, the first frame carries nearly the whole payload — 4.7 MB in the measurement above — and each held duplicate after it costs between a few hundred bytes and a few tens of kilobytes. A 10-second hold costs about the same as a 5-second one. Quality and resolution are the levers that matter; duration is not.

Should I switch the codec to H.265 to save space?

Probably not for a single still. H.265 earns its reputation on motion, where better inter-frame prediction pays across hundreds of frames. Here there is effectively one intra-coded frame and four near-empty ones, so on the measured example H.265 saved only about 4% over H.264 — and it costs you compatibility with the older transport-stream tooling that is usually the reason for wanting .ts in the first place. Use H.265 only if the receiving system asks for it.

Is the .ts from this page the same as .m2ts or .mts?

No. This page writes plain 188-byte transport-stream packets with the sync byte at offset 0, which is the broadcast and HLS form. AVCHD's .m2ts wraps each packet with a four-byte arrival timestamp for 192 bytes total, moving the sync byte to offset 4. They are different byte layouts, so renaming one to the other does not convert it. Pick this page for broadcast and streaming chains, and an MTS or M2TS target for camcorder and Blu-ray-authoring workflows.

Can I merge a set of Fujifilm frames into one stream?

Yes. Upload them together and leave Merge strategy on Merge images; each developed frame is held for the Image Duration you set, in upload order, in a single .ts. Video per image writes one file per photo instead. Neither mode adds transitions, motion or audio — the result is a sequence of held stills, which is exactly what a slate reel wants to be.

Does the raw file's editing latitude survive?

No. A Fujifilm raw holds roughly 14 bits per photosite of headroom, which is what lets you pull a blown highlight back or shift white balance long after the shot. The transport stream carries 8-bit 4:2:0 video with the tone curve applied and colour resolution halved on both axes. That is a one-way door. Keep the .raf as your master and treat the .ts as a delivery copy.

Why is the frame rate 1 fps?

Because a still image has no frame rate of its own. The pipeline encodes at 1 frame per second and holds your picture for the duration you chose, so 5 seconds is five identical frames rather than 125. B-frames are switched off as well: they exist to predict motion between differing frames, and there is none. If you need the still to sit inside a 30 fps timeline as a single frame, pick the 1/30s (single frame at 30fps) entry from the Image Duration list.

Does any Exif or capture metadata reach the .ts?

None of it. Camera model, ISO, shutter, aperture, focal length, lens and capture date are all dropped — a transport stream has no per-frame Exif equivalent, and the raw decoding stage does not carry those fields into the rendered image in the first place. If the shot data matters, keep the original .raf alongside whatever you deliver.

What happens to my file after the conversion?

Your .raf is uploaded over an encrypted connection, developed and encoded on our servers, and both the upload and the .ts it produced are deleted automatically after a few hours. Files are never shared or made public, there is no sign-up, and nothing is watermarked.