Initializing... drag & drop files here
Supports: TS
.ts Transport Stream files. Batch processing is supported, and uploads stream straight from your browser session — no account required..ts extension and the underlying MPEG-2 Transport Stream wrapper, so it stays drop-in compatible with IPTV set-top boxes, HLS pipelines, and FFmpeg-based broadcast workflows.Transport Stream is a broadcast container defined in MPEG-2 Part 1, ISO/IEC 13818-1. Every TS file is built from fixed 188-byte packets with a 4-byte header (~2.1% overhead) plus optional adaptation fields, which is why a raw recording from an HDHomeRun tuner or a DVB capture stays large even when the underlying video is already H.264. Re-encoding to a tighter bitrate or modern codec is usually the only way to shrink it without leaving the TS container.
.ts. A two-hour HD recording at the typical 8-12 Mbps ATSC bitrate runs 7-11 GB; CRF re-encoding to H.265 routinely cuts that in half with no visible loss..ts segments (default 6-second duration per Apple's authoring guidelines). Shrinking source TS files before segmentation reduces CDN egress and player buffering on bandwidth-constrained networks..ts after demuxing. Compressing the TS keeps the bitstream structure intact for downstream Blu-ray Disc Java workflows..ts for crash-resilience can accumulate hundreds of GB per week; re-encoding old footage to H.265 reclaims storage without losing the error-recovery wrapper.| Property | TS (MPEG-TS) | MP4 (MPEG-4 Part 14) | MKV (Matroska) |
|---|---|---|---|
| Spec | ISO/IEC 13818-1 | ISO/IEC 14496-14 | Open spec (CELLAR/IETF) |
| Packet structure | Fixed 188-byte packets | Variable atoms/boxes | Variable EBML elements |
| Container overhead | ~2.1% header + adaptation fields | <1% with moov atom |
<1% typical |
| Error resilience | High — designed for lossy broadcast | Low — single corruption can break index | Medium — chapter markers help recovery |
| Seeking without index | Yes, via sync bytes (0x47) |
No, requires moov atom |
Yes, via cluster index |
| Native HLS support | Yes (default segment format) | fMP4 only (HLS v7+) | No |
| Codec support | MPEG-2, H.264, H.265, AAC, AC-3 | H.264, H.265, AV1, AAC, MP3 | Effectively unlimited |
| Common players | VLC, set-top boxes, FFmpeg | Universal | VLC, PotPlayer, mpv |
| Mode | What it does | Good for |
|---|---|---|
| Target file size (%) | Scales output to a percentage of input | General "make it smaller" — recommended default |
| Specific file size | Two-pass encode hits a target MB | Upload caps (Discord 10 MB free / 25 MB Nitro, Gmail 25 MB attachments) |
| Constant Bitrate (CBR) | Fixed kbps throughout | HLS/IPTV streaming where bandwidth must be predictable |
| Variable Bitrate (VBR) | Bitrate adapts to scene complexity | Archives where average size matters more than per-second consistency |
| Constant Quality (CRF) | Locks visual quality, bitrate floats | Re-encodes that must "look as good as the source" — H.264 CRF 18-23 is the sweet spot |
| Constraint Quality | CRF with a max bitrate ceiling | When you need CRF visuals but cannot exceed a streaming bitrate cap |
Two reasons. First, TS adds a 4-byte header to every 188-byte packet — about 2.1% of the file is structural overhead, versus under 1% for MP4. Second, broadcast TS captures are usually recorded at full transmission bitrate (typically 8-19 Mbps for HD) with no second-pass optimization, while MP4 downloads have already been re-encoded by the publisher. The container itself only accounts for a few percent of the gap; the rest is bitrate.
Yes. The output stays in the MPEG-2 Transport Stream wrapper with the same 188-byte packet layout, sync bytes, and PID structure. VLC, MPV, FFmpeg, HDHomeRun viewer, Plex, and any HLS player will treat it identically to the input.
H.264 is the safer default — every IPTV box, browser, and editor supports it. H.265 (HEVC) typically cuts file size by 40-50% at equivalent quality but is not universal: some older set-top boxes and Smart TVs lack hardware HEVC decoders, even though both codecs are valid inside the TS wrapper per ISO/IEC 13818-1.
For H.264, CRF 18 is visually lossless, CRF 23 is the FFmpeg default, and CRF 28 is acceptable for archival web playback. For H.265, add about 6 to the H.264 number (CRF 24 ≈ H.264 CRF 18). Lower CRF = bigger file, higher quality; the relationship is roughly logarithmic, not linear.
Not meaningfully. Stream copy (-c copy in FFmpeg) only rewrites the container, which saves at most the ~2% header overhead. Real size reduction requires re-encoding the video stream at a lower bitrate or to a more efficient codec like H.265 or AV1.
M2TS uses 192-byte packets (188-byte TS plus a 4-byte timecode field) and is the native Blu-ray BDAV container. If your file extension is .ts after demuxing, this page is correct. If it's still .m2ts, use compress M2TS to preserve the timecode layer. The reverse direction is compress MTS for AVCHD camcorder files.
Apple's HLS spec has supported fMP4 segments since WWDC 2016, and fMP4 is now common for HEVC and CMAF deliveries. Plain TS segments remain the most compatible option for legacy Android, smart TVs, and older Roku devices. If broad device reach matters, ship TS; if you control the player, fMP4 can be marginally more efficient.
Re-encoding the video stream does not touch CEA-608/708 captions when they are carried in the video elementary stream (the FFmpeg/x264 default for TS), and Program Association Table and Program Map Table entries are rebuilt by the muxer. Subtitle tracks carried as separate PIDs are preserved as-is when the encoder is told to copy them.
Often the better move if you do not need broadcast features. Convert TS to MP4 wraps the same video in a lighter container and is universally playable. Compressing TS makes sense only when downstream tools — IPTV boxes, broadcast pipelines, HLS origins — specifically need the .ts extension and packet structure.