Initializing... drag & drop files here
Supports: TS
.ts transport stream into the upload area, or click "+ Add Files" to browse. Batch uploads are supported, so you can queue multiple recordings from the same DVR or capture session at once..rmvb is delivered as a direct download, and uploads are deleted after the job finishes — no sign-up, no watermark.MPEG-TS (.ts) is the transport-stream container used for DVB/ATSC broadcast, HLS streaming chunks, and Blu-ray/AVCHD camcorder recordings — typically H.264 video with AAC or AC-3 audio wrapped in 188-byte packets so a tuner can recover quickly after signal loss. RMVB is the variable-bitrate flavor of RealNetworks' RealMedia container, introduced in the early 2000s and still widely circulated in East and Southeast Asian fan-sub communities for anime, C-drama, and K-drama distribution where small files matter more than universal device support.
.ts file routinely runs 6-10 GB at broadcast bitrates; re-encoding to RMVB at 600-900 kbps brings the same runtime under ~800 MB while staying watchable at SD or 720p.| Property | TS (MPEG Transport Stream) | RMVB (RealMedia Variable Bitrate) |
|---|---|---|
| Container origin | MPEG-2 Systems (ISO/IEC 13818-1, 1995) | RealNetworks RealMedia, RMVB variant added 2003 |
| Typical video codec | H.264, H.265, MPEG-2 | RealVideo 8/9/10 (similar in design to MPEG-4 Part 10) |
| Typical audio codec | AAC, AC-3, MP2 | RealAudio Cook / AAC |
| Bitrate model | Constant or capped VBR (broadcast-friendly) | Variable bitrate, allocated by scene complexity |
| Packet structure | 188-byte packets with PCR for resync | RealMedia chunks with .RMF four-byte header |
| Native use | DVB/ATSC broadcast, HLS segments, AVCHD/Blu-ray | Asian fan-sub releases, mid-2000s web download |
| Modern device support | Universal (FFmpeg, VLC, Plex, all TVs) | VLC, MPlayer, RealPlayer SP — not iOS, modern Android, smart TVs |
| Streaming friendliness | Designed for streaming and seek-by-time | Local playback only, no HTTP streaming standard |
| File size at similar quality | Larger (broadcast overhead, CBR/capped VBR) | Smaller (aggressive VBR, ~30-50% saving common) |
| Preset | Approximate video bitrate (720p) | Use case |
|---|---|---|
| Highest | ~1500-2000 kbps | Master archive, near-source quality |
| Very High (default) | ~1000-1400 kbps | Long-term library, low artifacting |
| High | ~700-900 kbps | Standard fan-sub release |
| Medium | ~500-650 kbps | Storage-constrained mirror |
| Low | ~350-450 kbps | Thumb-drive episode pack |
| Very Low / Lowest | ~200-300 kbps | Audio-driven content, talking-head clips |
For tight file-size targets, switch File Compression to "Specific file size" and enter the cap in MB — the encoder will solve for a bitrate automatically rather than relying on a preset.
RMVB hangs on in specific niches: Chinese-language anime/drama fan-sub communities standardized on it in the mid-2000s and many indexers still expect it; legacy RealPlayer-based deployments in education and corporate kiosks still run; and the variable-bitrate efficiency of RealVideo plus RealAudio Cook produces noticeably smaller files than naive MP4 encodes at the same perceived quality. For everyday playback on phones, smart TVs, or browsers, MP4 is the right answer — see TS to MP4 for that path.
The default pairing is RealVideo 1.0 (RV10) for video and RealAudio 1.0 / REAL_144 for audio. The RMVB option also exposes RealVideo 2.0 (RV20) if your target player specifically needs it. Other audio codecs (MP3, AAC, AC-3) are technically permitted by the RealMedia container but are not commonly demuxable by RealPlayer-class decoders, so we keep the audio path on RealAudio for compatibility.
Yes — RMVB requires re-encoding from H.264 to RealVideo, and any cross-codec re-encode is lossy. To minimize the visible loss, pick the "Highest" or "Very High" quality preset and keep the resolution unchanged. If your source TS is already low bitrate (e.g., an off-air SD broadcast capture), staying at the source resolution and using the "High" preset is usually indistinguishable from the source on playback.
Transport-stream captures from set-top DVRs, HDHomeRun tuners, or AVCHD camcorders often carry partial GOPs at the start (the tuner began recording mid-segment) and broadcast-specific metadata that some players choke on. Re-encoding to RMVB rebuilds the keyframe structure from scratch, so the output starts cleanly. If you only want to fix the container without re-encoding, try TS to MKV instead, which can remux H.264 directly.
Yes. Open Advanced Options, expand Trim, switch to "Time Range", and enter a start time and duration. Only the trimmed segment is re-encoded, which both shortens processing time and avoids any leading garbage from a tuner sync issue. The default trim is the full file.
No. The RealMedia container has no widely supported subtitle track standard comparable to MKV's SRT/ASS embedding or MP4's closed-caption tracks, and chapter markers are not preserved. If your TS carries DVB subtitles or EIA-608/708 captions you want to keep, output to MKV instead so the subtitle stream survives the conversion.
The platform accepts video uploads up to several gigabytes. For a typical 1-2 hour HD broadcast capture (6-10 GB), the upload itself is the slow step; conversion runs on the server and the output RMVB is usually a fraction of the source size at default quality. If you regularly handle very large captures, use Compress TS first to drop the source bitrate before remuxing or converting.
Unlikely without help. iOS and modern Android do not include RealVideo decoders, and Samsung/LG/Sony smart TV firmware dropped RM/RMVB support years ago. VLC for iOS/Android plays RMVB on phones, and VLC or MPlayer handle it on desktop. If your target device is a smart TV or game console, convert to MP4 instead via RMVB to MP4 or skip RMVB entirely.
Stick with RealVideo 1.0 (RV10) — it's the default for a reason. RV10 is what virtually every RMVB file in circulation uses and what every RealMedia-capable player implements. RealVideo 2.0 (RV20) was an interim codec rarely seen in the wild; some older RealPlayer builds may decode it inconsistently. Unless you have a specific compatibility requirement, the default pairing produces the most portable output.