Show HN: Qast – Cast anything (files, URLs, screen) to …

Hi HN,I built qast because I couldn’t find a tool that “just works” for casting content to a TV. Some TVs support YouTube natively, some do screen mirroring, and only a handful actually show up in Chrome’s cast menu. Even when you do get a connection, one TV …

Almost every TV made in the last decade can receive cast streams. But what they'll accept varies: In other words, TV's streaming features differ. Straightforward "play this stream" reveals inconsistencies — content that plays fine on a Samsung may fail on an LG. Codec mismatches (VP9, H.265, DivX/Xvid), uncommon containers (MKV, WebM, FLV, AVI, OGG), and unsupported audio formats (FLAC, Opus, DTS) are common causes of "format not supported" errors.

Even when a TV claims to support a format, it may only handle specific codec profiles or resolutions. qast sidesteps the compatibility problem entirely. Practically all TVs accept either MPEG transport stream or fragmented MP4, so qast transcodes everything — URLs, files, screen captures, windows, webcams, piped data — into a single H.264/AAC stream. Input can be anything ffmpeg understands, which is practically every media format in existence.

Because everything is transcoded to a common format, qast can play varied content (different sources, formats, and resolutions) back-to-back seamlessly. The TV sees one continuous stream with consistent format, resolution and bitrate throughout — content is added dynamically to a continuously-running mux, so there are no gaps or format switches between items. YouTube, Vimeo, Twitch, TikTok, Twitter/X, Dropbox, Google Drive, PBS, BBC, and 1000+ sites via yt-dlp.

Renders a URL in headless Chromium and casts the result to your TV. Good for dashboards, status pages, or any content that's best viewed as a live webpage rather than a video. Requires Playwright (pip install playwright && playwright install chromium). If you have a security camera on your network, it mostly likely outputs RTSP. You can cast it to your TV: HLS and IPTV streams work directly. Many international broadcasters stream free online but getting those streams onto your TV is a pain and sometimes requires a paid app.

qast handles the HLS fetching and transcoding — you just give it the URL. See iptv-org for a directory of free streams. Note, many of these streams are geo-blocked. Also note, aspect ratio often needs to be tweaked, see –aspect arg. The – tells qast to read from stdin. This makes qast composable with any tool that outputs video. Displays your music as a real-time frequency-based waterfall graph on your TV.

Note, ffmpeg has lots and lots of these kinds of visualizations. (But we're still waiting on –flight-simulator and –play-chess… C'mon ffmpeg!) Plain text, one source per line. Supports the same source syntax including @duration: Roku — Requires the free Media Assistant app, but conveniently, this app only needs to be installed — it doesn't need to be selected and "running" for qast to stream and render to your Roku device/TV.

qast auto-discovers devices on your network. If multiple are found, it presents a menu: Compatibility. TVs are picky about codecs, containers, and parameters. A Samsung might play your MKV; an LG might not. By normalizing to H.264 + AAC in MPEG-TS (or fragmented MP4 for Chromecast), qast hits the lowest common denominator that every TV accepts. It also enables seamless queue transitions — uniform codec parameters mean no discontinuities between sources.

Modern PCs typically have hardware encode support, so CPU usage is kept reasonably low. No. qast streams forward-only — it's designed for lean-back viewing. If you need seeking, consider using a casting app such as YouTube, which is supported on most TVs. If yt-dlp can't extract it, qast can't play it. Netflix, Disney+, etc. use DRM that prevents this. Make sure your TV and computer are on the same network/VLAN.

Try qast -v to see discovery traffic. Some TVs need DLNA/casting enabled in settings. Roku requires "Control by mobile apps" to be enabled under Settings > System > Advanced. Some DLNA TVs consume and discard the first chunk of data when they connect — probing the format before they start rendering. This means the first few seconds of your video get eaten, and it can also disrupt the audio/video sync that follows.

The –preroll flag works around this by inserting a placeholder video (a title card) at the start of the stream. The TV chews through the placeholder instead of your content. Start with –preroll 5 and increase until you see the placeholder appear on screen — that means the TV is past its probe phase and your real content will play from the beginning. Some TVs need 30 seconds or more. Once you know how much preroll your TV needs, you can add the preroll amount to your qast calls.

Practically all TVs want to buffer a few seconds of data before starting to render frames, which leads to latencies. For live streams such as webcam or computer desktop where latency matters most, you might see up to a 10 second lag from when you move your mouse and when you see it on your TV (for example). By default, qast asks yt-dlp for separate DASH video and audio streams when resolving YouTube URLs.

DASH streams are higher quality — YouTube serves its best resolutions and bitrates this way, while muxed (combined) streams typically cap at 720p. The downside is that ffmpeg receives two HTTP inputs (one video, one audio), and there's a long-standing ffmpeg bug where multiple HTTP inputs can cause audio truncation or desync. To work around this, qast downloads the audio stream to a small temp file (~1-2 MB) before handing it to ffmpeg.

This way ffmpeg only has one HTTP input (video) and one local file (audio), which avoids the bug. The audio download is fast and the temp file is cleaned up automatically. If the download times out or fails, qast falls back to a single muxed stream automatically. YouTube periodically changes its player internals to break yt-dlp extraction. When this happens you'll see errors like "Sign in to confirm you're not a bot" or "Unable to extract" in yt-dlp's output.

Two things help: Note that cookie extraction reads from your browser's cookie store — it does not modify anything. yt-dlp supports 1000+ sites. For most of these, qast receives a single muxed URL and no audio download is needed. The DASH splitting behavior is specific to YouTube (and a few other sites that use DASH). If yt-dlp fails entirely for a given URL, qast passes the raw URL directly to ffmpeg as a last resort — this works surprisingly often for direct video links.

Our office has TVs of various types. During the Winter Olympics I had mixed results casting live feeds from my browser — sometimes it would work, sometimes not, and some TVs were invisible to Chrome despite being capable of streaming. In the past our business has sought ways to display live numbers on TVs — user counts, sales figures, that sort of thing. We have Raspberry Pis, and that's a solution, but the pain factor is high.

Why can't I just "play this video" or "cast this window" to a given TV from the command line (and most importantly expect it to work)? Looking into it more, I found that screen casting is often a paid service for businesses (Yodeck, Screenly, UPshow, many more). These solutions typically use Raspberry Pis coupled to a cloud backend. The technical hurdles are solved but it requires a paid subscription and a Raspberry Pi for each TV.

Being a big ol nerd, it got me thinking — could you make a streamer that's agnostic to both the video source/format and the TV type? If so, you could curate your own "channel" of content and render it on practically any TV. Additionally, you could have a single machine casting customized streams to multiple TVs for free. qast is pronounced "cast". The q is for queue — play a queue of varied content back-to-back.

(And everyone knows replacing a c with q makes anything sound cooler.)

Summary

This report covers the latest developments in samsung. The information presented highlights key changes and updates that are relevant to those following this topic.

---