feat(youtube): SABR extractor support

[Priveetee]

First real integration of the SABR extractor (supersedes the PoC #68). Pairs with the client SABR PR (coming) and the media3 migration InfinityLoop1308/PipePipeClient#45. Tracking: InfinityLoop1308/PipePipeClient#42.

Docs (how SABR works end to end): https://priveetee.github.io/Docs-PipePipe/developer-guide/introduction

Related:

• feat(player): migrate from ExoPlayer 2.18.7 to media3 1.10.1 PipePipeClient#45 (media3, the client SABR builds on it)
• [YouTube] Content Not Yet Suppoted (SABR) after 5.1.0 PipePipe#2330 ([YouTube] Content Not Yet Supported (SABR) after 5.1.0)
• [YouTube] Coordinating efforts on SABR implementation TeamNewPipe/NewPipe#12248 (coordinating SABR)

Summary

Adds the YouTube SABR (Server ABR) extraction path end to end: UMP wire reading, the proto request/response codecs, the typed UMP parts (media, policy, context, onesie...), response decoding + mp4/webm segment index parsing, and the session/state model the client pump drives. A new DeliveryMethod.SABR exposes it.

Changes

• DeliveryMethod.SABR delivery method.
• UMP reader + proto codec, response decoder, typed parts (media/policy/context/onesie/misc).
• media segment + mp4/webm index parsers, request builder + client profile, info/formats/probe + PO token provider interface.
• session, state and hardware-aware format selection; SABR wired into YoutubeStreamExtractor.
• reader-driven contiguous buffered-range reporting + play-head-aware byte-bounded eviction + reload budget, plus backward-seek re-request (rewindBufferedTo / prepareForRewind): the buffered head was one-way (assumeBufferedUntil only ever extends), so a rewind onto an already-sent segment left the request claiming we still had it and the server sent nothing back; this shrinks the head (contiguous + observed-timing) so the server re-sends from the target.
• SabrLiveMetadata getters (live foundation).
• YoutubeParsingHelper: Safari player request now uses the live web client version (the hardcoded one started returning page needs to be reloaded).

Why

YouTube serves some videos SABR-only; the old paths return "Content Not Yet Supported". This adds a real extractor path, with the client PR as the runnable counterpart.

Impact / Compatibility

The new sabr/ package and DeliveryMethod.SABR are additive. The one behavioural change is in YoutubeStreamExtractor: a FORCE_SABR_FOR_TESTING flag (currently true) routes every YouTube video through the SABR pipeline, so HLS/DASH/progressive are bypassed on purpose to stress-test SABR on everything. With the flag false (production default), HLS/DASH stay untouched and SABR only fills the SABR-only / no-HLS gap that upstream currently throws ContentNotSupportedException on. The Safari client-version fix also helps the existing logged-in path.

Validation

• ./gradlew :extractor:compileJava -x checkstyleMain
• Exercised end to end via the client on Pixel 8, Galaxy S25 and emulator (Android 14/16): probe -> session -> segments -> playback, including forward and backward seek.

Notes

• First real integration, not a PoC, but still WIP, residuals tracked in the client PR.
• Right now FORCE_SABR_FOR_TESTING = true on purpose: all YouTube playback goes through SABR with no HLS fallback, so we exercise the SABR path on every video. It flips back to false before merge (then HLS stays as fallback and SABR only covers the SABR-only gap).
• Not ready to merge yet, more testing coming.
• checkstyleMain excluded, fails repo-wide unrelated to this change.

[Priveetee]

bit of context since this isn't a fresh idea: the PoC #68 (and the client PoC InfinityLoop1308/PipePipeClient#43) were exactly that, throwaway PoCs to prove SABR actually plays end to end. they did their job, so i closed #68 rather than keep pushing onto a messy branch.

this is the real integration, rebuilt clean. the SABR extractor stands on its own here, and i reworked the buffering to be reader-driven (pacing + cache eviction follow what the player has actually read, not the play head, so it doesn't deadlock or blow up memory anymore), plus the Safari client-version fix and the live-metadata foundation. on the client side i split it too: the media3 migration is its own PR (InfinityLoop1308/PipePipeClient#45) and the SABR client sits on top.

still WIP, not for merge yet (FORCE_SABR_FOR_TESTING is on so every video goes through SABR while i hammer it), but this is where it continues from now :)

[Priveetee]

I've been working on this whenever I had some free time. I tested it a lot (u know me by now, im a little paranoid 🥲) on a S25, a Z Fold 5 and a Pixel 8, mostly the app/code itself, and found and fixed a shit load of bugs along the way 🫠: forward seeks, rewind after the stream buffered to the end, return from background, a crash on decoder init... u can see it all in the commit history.

Honestly I'm starting to reach my limits testing alone, so I think this is getting close to review-ready @InfinityLoop1308.

No rush at all, as we say in French: y a pas le feu au lac :)

If u want me to split this PR differently (or anything else really), don't hesitate to tell me.

One thing I'd really like your take on: how we wire SABR into the app. My take is it shouldn't be SABR-only, I'd rather marry both, keep the current delivery and have SABR live next to it (as an option / fallback) so we don't regress anyone.

But u might see it differently, so im genuinely curious what u think. Right now FORCE_SABR_FOR_TESTING is still true in YoutubeStreamExtractor so every video goes through SABR while I test, that's not the end state, I'll flip it back.

Last thing: it's pushed with private static final boolean DIAG = false; in YoutubeSabrSession. Flip it to true and it logs every SABR round (segments, buffered ranges, protection status), that's how I caught most of the bugs above.

Could be handy to hand a debug build to users who hit issues so their reports are actually useful.

[Priveetee]

Oh and I almost forgot the fun part 😄

I wrote actual docs for the extractor! the whole thing's in there: architecture, extraction flow, the info model, the downloader, paging, adding a service, the YouTube service... and then it dives deep into SABR (UMP framing, part-type decoding, building the VideoPlaybackAbrRequest, the session driver, the buffered-range model + seeking). plus a bunch of neat hand-drawn schemas to make it all click

Here

had a real blast writing it, curious what u think :) (If u have time of course)