Skip to content

SABR in the extractor ​

SABR is YouTube's session-based delivery protocol. The protocol itself, its motivation, UMP, BotGuard and attestation are covered by the SABR Guide. This page maps the current services/youtube/sabr package in PipePipeExtractor and explains the boundary between extraction, requests, decoding and media assembly.

Where it sits ​

SABR streams are only built on the MWEB path. ensureStreamsAreCached() calls buildSabrStreams() when the selected endpoint is mweb, the item is neither a live nor a post-live stream, and the player response carries a SABR streaming URL. Every other combination extracts direct formats instead, which is why switching the endpoint to VisionOS does not work around a SABR problem: it leaves the SABR path and takes the older delivery route YouTube is winding down.

When those conditions hold, YoutubeStreamExtractor.buildSabrStreams() exposes the formats as DeliveryMethod.SABR. There is no per-format media URL. The stream carries the common serverAbrStreamingUrl as reference, while the client chooses formats and drives the session with YoutubeSabrRequest.

The current division of labour is:

  • YoutubeStreamExtractor parses streamingData, resolves JavaScript n and signature parameters in one batch, and creates YoutubeSabrInfo plus SABR stream metadata;
  • YoutubeSabrSession and YoutubeSabrRequestHelper encode and send each transaction, follow redirects and policies, track cookies, contexts and live metadata, and apply bounded recovery;
  • SabrStreamingResponseReader and SabrMediaSegmentCollector decode the UMP envelope and assemble completed media segments, optionally using a spool file for large uncompressed segments;
  • the application layer consumes the completed segments and supplies a PO token when YouTube requests one. The extractor does not mint that token or render media.

In PipePipeClient, SabrSessionHelper validates the extractor metadata and creates the session, SabrMediaBridge translates Media3 segment demand into preparation/playback requests, and SabrRequestCoordinator serializes retries, backoff and attestation recovery. Downloads use the same extractor session from SabrDownloader, then remux the collected audio/video files. The local DOM provider supplies the PO token; it is not a second SABR implementation.

Read in this order ​

  1. Starting a session — player-response parsing, YoutubeSabrInfo, request creation and the state carried between calls.
  2. The request — VideoPlaybackAbrRequest, preferred and selected formats, buffered ranges and the protobuf wire format.
  3. UMP and decoding — framing, part identifiers and the YoutubeSabrResponse produced by the decoder.
  4. Media, segments, and the index — headers, compressed payloads, segment assembly and initialization timelines.
  5. The session driver — one-transaction semantics, redirects, backoff, attestation and recovery limits.
  6. Control parts reference — the wire-level control parts currently recognized by SabrResponseDecoder.

Current class map ​

AreaCurrent classes
Player responseYoutubeStreamExtractor, YoutubeSabrInfo, YoutubeSabrInfo.Format
Session and requestsYoutubeSabrSession, YoutubeSabrRequest, YoutubeSabrRequest.Track, YoutubeSabrRequestHelper
Response and UMPYoutubeSabrResponse, SabrResponseDecoder, SabrStreamingResponseReader, UmpReader, SabrProto
Media assemblySabrMediaSegment, SabrMediaSegmentCollector, SabrMediaHeader, SabrFormatInitializationMetadata
TimelinesYoutubeSabrFormatTimeline, SabrSegmentIndex, SabrMp4SegmentIndexParser, SabrWebmSegmentIndexParser
DiagnosticsYoutubeSabrSessionDiagnostics, YoutubeSabrSession.TraceSnapshot
ErrorsSabrProtocolException, SabrRecoverableException, SabrAttestationException

The class map intentionally lists only classes present in the current PipePipeExtractor source. Older documentation referred to probe, profile and stream-state classes that are no longer part of this package.

The boundary ​

The extractor knows how to describe and drive a SABR transaction, but it does not turn the response into decoded audio or video. For the protocol's request and response shapes, BotGuard and attestation, continue with the SABR Guide.