RTVS (Radio and Television of Slovakia) distributes its on-demand catalogue through adaptive streaming rather than plain progressive downloads. When you press play, the player negotiates a manifest — typically an MPEG-DASH MPD or an HLS M3U8 playlist — and the server then delivers the timeline in short fragments, often with separate video and audio representations. That architecture is excellent for switching bitrates mid-stream, but it means there is no single file sitting at a URL for you to right-click and save. Archiving RTVS content therefore requires a tool that can parse the manifest, resolve every variant, fetch hundreds or thousands of discrete chunks, and then remux the result into a playable container.
Two further obstacles appear at scale. First, mainstream broadcast CDNs apply per-connection throttling, so a naive sequential download of a 60fps 4K asset may run far below your actual line speed. Second, audio is frequently served as a distinct AAC or Opus track, and subtitle tracks arrive as segmented WebVTT resources that must be stitched separately. Resolving these cleanly demands concurrent fragment retrieval — the kind engineered into aria2c — plus a muxer such as FFmpeg to recombine the streams losslessly, without a re-encode that would degrade the original bitrate or drop the embedded subtitle channel.
Legality matters here as much as engineering. Downloading a broadcast for personal, offline, time-shifted viewing generally falls within Fair Use and private-copying norms in many jurisdictions, but redistribution, public re-upload, or commercial exploitation of RTVS material almost certainly does not. Verify your local copyright law, respect geo-restrictions, and never bypass access controls on paywalled or rights-restricted content. Treat every method below as a personal archival instrument, not a publishing pipeline.
This guide evaluates three approaches against a consistent set of criteria: maximum resolution and frame-rate fidelity, subtitle and multi-audio handling, multi-fragment acceleration, playlist and series batch support, and the privacy posture of the software doing the work. The comparison below is ordered from the most capable and dependable desktop workflow to the most convenient but least trustworthy browser-based option.
yt-dlp app (Recommended Desktop GUI)
The yt-dlp app is a proprietary desktop application built on Tauri v2 with a Rust backend, wrapping the upstream yt-dlp extractor, an aria2c fragment engine, and FFmpeg into a single graphical workflow. It handles DASH and HLS manifests natively, selects the highest available 4K or 8K representation, and preserves 60fps timing without frame drops. Because the shell is compiled Rust rather than a browser runtime, memory use stays low even when a queue holds an entire RTVS series.
Concurrency is the decisive advantage. The app splits each manifest into its constituent chunks and pulls them over multiple parallel connections through aria2c, which bypasses the per-stream throttling that cripples single-threaded fetchers. When the fragments land, FFmpeg muxes video, audio, and subtitle tracks into a container losslessly — stream copy, no re-encode — while JSON job state is written to the local filesystem. No telemetry leaves the machine, and no account is required.
Step-by-Step Instructions
Step 1: Download and Launch yt-dlp app
Install the desktop build for your operating system from the official source, then open it. No account creation or cloud sign-in is required.
Step 2: Paste the RTVS Video or Series URL
Copy the address of the RTVS programme or playlist page and paste it into the main input field. The app will probe the manifest and enumerate every available variant.
Step 3: Choose Resolution, Audio, and Subtitles
Select your target format from the detected list — 4K or 1080p60 where offered — and tick the audio and subtitle tracks you want embedded in the output file.
Step 4: Configure the Fragment Engine
Confirm that multi-connection downloading is enabled and set a sensible concurrent-fragment count. Higher concurrency accelerates long broadcasts but should match your connection's stability.
Step 5: Start the Queue and Verify the Output
Begin the download and let aria2c fetch fragments while FFmpeg muxes them on completion. Open the finished file to confirm duration, subtitle rendering, and audio track selection.
Advantages
- ✓ Multi-connection aria2c fragment engine defeats CDN throttling and saturates available bandwidth
- ✓ Automatic FFmpeg stream-copy muxing retains original video bitrate, 60fps cadence, multi-audio, and subtitle tracks
- ✓ Zero telemetry, fully local JSON job storage, and native 4K/8K plus full-playlist batch queueing
Drawbacks
- ✗ Requires desktop installation
Ready to download yt-dlp app? 🚀
Experience native speed, 4K/8K stream extraction, and zero telemetry video archiving on Windows, macOS, and Linux. ✨
Get yt-dlp appyt-dlp (Command Line Interface)
Upstream yt-dlp is the open-source command-line engine that most graphical tools are ultimately derived from. It is extraordinarily capable: format selection expressions, cookie-jar authentication, playlist ranges, subtitle conversion, and post-processing hooks are all exposed as flags. For repetitive archival work it is the most scriptable option available, and it runs identically on Linux servers, macOS workstations, and Windows terminals.
The trade-off is operator burden. Nothing is discovered for you — you must know the correct format-selector syntax, remember that external FFmpeg and aria2c binaries must be installed and on your PATH, and keep three separate tools updated in parallel. For a one-off 4K capture it is efficient; for a non-technical user it is a significantly steeper climb than a GUI.
Step-by-Step Instructions
Step 1: Install the CLI and Its Dependencies
Install yt-dlp plus FFmpeg and aria2c, then confirm each resolves on your PATH. Version drift between the three is the most common source of failure.
Step 2: Inspect Available Formats
List the format table for the RTVS URL to identify the 4K or 1080p60 video representation and the matching audio track IDs before committing to a long download.
Step 3: Compose the Download Command
Combine the chosen format selector with external-downloader flags so aria2c handles fragments, and enable subtitle and metadata embedding in the same invocation.
Step 4: Run and Verify
Execute the command, watch the fragment progress, and confirm that the muxed output retains the requested resolution, frame rate, and subtitle stream.
Advantages
- ✓ Fully scriptable for cron jobs, batch series archival, and automated post-processing pipelines
- ✓ Granular control over format selectors, fragment concurrency, cookie authentication, and remuxing flags
- ✓ Runs headless on servers and NAS devices without any graphical environment
Drawbacks
- ✗ Steep learning curve for format syntax, flags, and error diagnosis
- ✗ Manual dependency management for FFmpeg, aria2c, and ongoing version updates
Web-Based Online Converters
Browser-based downloader sites ask only for a pasted URL and return a file, which makes them superficially attractive. Under the hood they typically proxy the manifest server-side, transcode the result to a lower bitrate to save their own bandwidth, and hand back a single flattened MP4. There is no fragment acceleration under your control, and long broadcasts frequently time out under server-side rate limits.
The privacy cost is the more serious issue. These services exist to monetise traffic: expect aggressive interstitial advertising, redirect chains, and analytics scripts that observe the URL you submitted. Uploading authenticated cookies to a third-party endpoint is a straightforward credential leak, and resolution ceilings usually stop well below 4K.
Advantages
- ✓ No installation or command-line knowledge required — works in any browser on any device
- ✓ Occasionally useful for a short clip when no desktop tool is available at that moment
Drawbacks
- ✗ Intrusive advertising, redirect chains, and third-party tracking of submitted URLs
- ✗ Severe privacy risk if credentials or cookies are ever supplied to the service
- ✗ Strict resolution and file-size caps with lossy server-side re-encoding