Bypassing YouTube's SABR streaming when FFmpeg can't help

There is no FFmpeg flag for this. No demuxer, no -protocol_whitelist entry, no patched build, no -headers trick. FFmpeg cannot consume YouTube’s SABR streams, and the yt-dlp maintainers have said so plainly: the in-progress SABR downloader PR notes that “single format streams were only supported by ffmpeg which does not support SABR.”

If you arrived here because of the warning

WARNING: [youtube] <id>: Some web client https formats have been skipped as they
are missing a url. YouTube is forcing SABR streaming for this client.
See  https://github.com/yt-dlp/yt-dlp/issues/12482  for more details

the fix is not at the FFmpeg layer. Three working bypasses follow, ranked by effort.

Why FFmpeg can’t help

SABR (Server Adaptive Bit Rate) is a YouTube-proprietary streaming protocol. The player no longer receives a plain googlevideo.com/videoplayback?... URL for every format — for the web client, adaptiveFormats now contains only the SABR URL. Segments are framed in UMP (Unified Media Protocol) with protobuf-encoded parts (MEDIA_HEADER, MEDIA, MEDIA_END).

FFmpeg’s http, hls, and dash demuxers expect a URL they can range-fetch. They don’t speak UMP, and they don’t decode the protobuf framing. The protocol isn’t implemented — there’s no flag that turns it on.

Bypass 1 — switch player clients (cheapest)

YouTube rolled out SABR-only formats per client. The web client is affected. The tv, ios, and android clients still hand out plain HTTPS URLs in many cases, and yt-dlp already includes a fallback chain. The fastest fix is to bias toward clients that still return URLs FFmpeg can consume:

yt-dlp --extractor-args "youtube:player-client=tv,ios,web_safari" \
       -f "bv*+ba/b" "https://www.youtube.com/watch?v=<id>"

A verbose log in yt-dlp issue #13968 shows the chain working: the web client is blocked by SABR, the ios client is skipped for a missing PO Token, and the tv client falls through to itag 18 — which streams over plain HTTPS without complaint.

The catch: itag 18 is 360p H.264 + AAC. Good enough for some workflows. If not, go to bypass 2.

Bypass 2 — provide a GVS PO Token

A PO Token (Proof of Origin Token) is an attestation parameter YouTube requires from some clients to release the higher-quality HTTPS URLs. The official yt-dlp PO Token Guide distinguishes three: GVS (video streaming), Player (Innertube format URLs), and Subs (subtitles). The web client needs GVS + Subs; mweb needs GVS; clients vary.

Manual extraction is no longer recommended, since PO Tokens are now bound to the video ID. The supported path is a provider plugin — install bgutil-ytdlp-pot-provider and verify with yt-dlp -v:

[debug] [youtube] [pot] PO Token Providers: bgutil:http

Once the token is delivered, the web client returns HTTPS URLs again and FFmpeg consumes them as ordinary segmented downloads. --cookies alone won’t do it: cookies authenticate the session but don’t satisfy attestation, and issue #13968 confirms cookies don’t suppress the SABR warning on their own.

Bypass 3 — use the SABR downloader fork

For videos where every non-SABR format has been removed (some 1080p+ tracks, some livestreams), there is now a yt-dlp branch with a native SABR downloader: PR #13515 by coletdjnz. A testing build is available at bashonly/yt-dlp@sabr.

yt-dlp --update-to bashonly/yt-dlp@sabr
yt-dlp --extractor-args "youtube:formats=duplicate" \
       -f "ba[protocol=sabr]+bv[protocol=sabr]" \
       "https://www.youtube.com/watch?v=<id>"

This downloads SABR segments entirely inside yt-dlp (via the protobug protobuf library). FFmpeg only enters at the post-merge mux step on the local .mp4 / .mkv — the SABR transport never touches it. You can’t pipe a SABR stream into ffmpeg -i -.

Picking a bypass

Path	Effort	Works for	Gotcha
Client switch (player-client=tv,ios)	None	Most videos at 1080p or below	Can fall back to 360p itag 18
bgutil PO Token plugin	Install one plugin	web and mweb HTTPS formats	Tokens are per-video; rotate often
SABR downloader fork	Install nightly fork	Everything, including SABR-only formats	Pre-release; PR is still open

Player-side: mpv, VLC, OBS

If you stream YouTube into a player that uses ytdl_hook + FFmpeg, the same wall applies. The mpv project tracks this in issue #16645, where the reporter notes the pipeline becomes “fairly useless to people for who this feature has been rolled out to for youtube, unless you love 360p video.” There’s no player-side fix while FFmpeg lacks SABR support — the workaround is the same: have yt-dlp pick a non-SABR client.

Keep yt-dlp on the nightly channel. The warning string, the client fallback order, and the SABR downloader branch are all moving fast — PR #13049 only landed the current warning text in April 2025, and the SABR downloader was still under test as of mid-2026.