How to Compress TS Video Online
- Upload Your TS Files: Drag and drop or click "+ Add Files" to select one or more
.tsTransport Stream files. Batch processing is supported, and uploads stream straight from your browser session — no account required. - Pick a Compression Mode: Choose Target file size (%) to shrink by a ratio (the default and best general-purpose setting), Specific file size to hit an exact MB target, Constant Bitrate or Variable Bitrate for streaming-friendly output, or Constant Quality / Constraint Quality (CRF) to lock visual quality and let the encoder decide the bitrate. Auto Scale is on by default so resolution drops sensibly when you ask for aggressive shrinkage.
- Trim or Resize (Optional): Switch the trim mode from Unchanged to Time Range to cut to a specific start and duration, pick a resolution preset (2160p, 1080p, 720p, 480p, 360p, 240p, 144p), enter custom width/height, or scale by percentage. Manual resolution is hidden while Auto Scale is active — toggle it off to set dimensions yourself.
- Compress and Download: Click Compress. The output keeps the
.tsextension 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.
Why Compress TS?
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.
- IPTV and DVR recordings — set-top boxes and tuners like HDHomeRun, TVHeadend, and NextPVR write live broadcast feeds straight to
.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. - HLS streaming segments — Apple's HLS spec emits
.tssegments (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. - DVB broadcast captures — DVB-T, DVB-S, and DVB-C captures often arrive at full broadcast bitrate (15-19 Mbps for HD MPEG-2). Compress to upload archives to platforms like Internet Archive or to ship to remote editors over slow links.
- Blu-ray rips and AVCHD source files — Blu-ray uses M2TS (a 192-byte-packet variant of TS), and many tools output plain
.tsafter demuxing. Compressing the TS keeps the bitstream structure intact for downstream Blu-ray Disc Java workflows. - Camera output and field recorders — some professional cameras and HDV camcorders write MPEG-2 TS directly. Compressing before handoff to a NLE shortens transfer time without forcing a container change.
- Long capture sessions — game-capture appliances and security DVRs that write
.tsfor crash-resilience can accumulate hundreds of GB per week; re-encoding old footage to H.265 reclaims storage without losing the error-recovery wrapper.
TS vs MP4 vs MKV — Container Comparison
| 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 |
Compression Mode Quick Guide
| 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 20 MB free / 50 MB Nitro Basic, 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 |
Frequently Asked Questions
Why are my TS files so much larger than the equivalent MP4?
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.
Will the compressed file still play in my IPTV box, VLC, or FFmpeg pipeline?
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.
Should I pick H.264 or H.265 inside the TS container?
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.
What CRF value should I use for TS compression?
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.
Can I compress TS without re-encoding (stream copy)?
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.
My TS file came from a Blu-ray rip — should I use this tool or compress-m2ts?
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.
Do HLS players prefer compressed TS segments or fragmented MP4?
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.
Will compression remove the embedded closed captions or program/PAT/PMT tables?
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.
Can I just convert TS to MP4 instead of compressing?
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.