Repository navigation
SABR extractor integration (follow-up to #66) #67
Description
Splitting this out of #66 (which kinda turned into the research log) to track the actual extractor implementation.
Docs (how SABR works end to end: protocol, UMP, attestation): https://priveetee.github.io/Docs-PipePipe/developer-guide/introduction
What's in it: the full SABR stack on the extractor side, gated behind a new DeliveryMethod.SABR so it only kicks in on SABR-only videos and stays out of the way otherwise:
- UMP reader + proto codec
VideoPlaybackAbrRequestbuilder + client profile- session / state (request number, playback cookie, buffered ranges, player time)
- UMP response decoder (media headers, init metadata, next-request policy, stream protection status)
- format selection by what the device can actually decode in hardware
Status: runs end to end with the client on a real device (Pixel 8). Token, download and decode all work. Memory is bounded (no more OOM on long 4K), and the session survives transient backoff interrupts.
Known limit: sustained playback is currently gated by a client-side player issue (tracked separately on the client repo: InfinityLoop1308/PipePipeClient#42), not by the extractor or the protocol. The extractor side is player-agnostic, so it has no media3 dependency.
PoC PR: #68
Activity
Priveetee commentedon Jun 5, 2026
hey @InfinityLoop1308 !
quick architecture call I'd like your take on before pushing the SABR integration further.
while talking with a maintainer from NewPipe, he pointed out that in our PoC the extractor drives part of playback: it runs the SABR session, builds the requests, does the HTTP, and manages state + reload + the po-token loop. their take is the extractor should only return what a client needs (the bits to build the request bodies + headers) and let the client own the protocol; they're doing a stream API refactor in that direction.
on our side the extractor already does more than pure parsing anyway (it calls our own decoder endpoint, fetches sponsorblock, runs the bilibili/niconico danmaku websockets, and
StreamingServicecarries session state), and we ship extractor + app as one composite build. so an extractor-driven SABR session is consistent with how PipePipe already works.so before I push further, am I going in the right direction here? honestly I'd personally rather keep the SABR session in the extractor (the current PoC), it fits how PipePipe already works. but you're the one who decides the architecture, so lmk if you'd prefer the client-driven split instead.
btw the PoC already plays end to end, and i've got reload handling + a live-metadata foundation on top locally.
InfinityLoop1308 commentedon Jun 5, 2026
just continue your work :) we don't care about np's design.
InfinityLoop1308 commentedon Jun 5, 2026
btw, if you prefer kotlin, just use it. (ofc java is ok as well)
Priveetee commentedon Jun 5, 2026
haha you really got me figured out 😭 honestly yes, I prefer Kotlin a thousand times over Java. thanks for the green light, it's definitely not falling on deaf ears, gonna make good use of it :)
and thanks for the answer on the np thing too, it had me a bit worried 😂
Priveetee commentedon Jun 6, 2026
cross-update from the client side (InfinityLoop1308/PipePipeClient#42 / client PR InfinityLoop1308/PipePipeClient#47): the sustained-playback stall that was gating everything turned out to be a client-side false-stall in the segment wait, not the extractor or the protocol. fixed it, so the full SABR stack now plays end to end AND all the way to completion on a Pixel 8, with working seek. the extractor side here is unchanged and holding up well.
Priveetee commentedon Jun 6, 2026
quick one, backward seeks needed a fix on this side (#69). the buffered tracking only ever went up (assumeBufferedUntil just extends), so rewinding onto a segment we'd already sent left the request telling the server we still had it, it sent nothing back and the thing hung. added rewindBufferedTo + prepareForRewind that walk the buffered head back to the target (contiguousMaxSegment + the observed timing window, not just the high water mark) so the server re-sends it. does the trick.
Priveetee commentedon Jun 6, 2026
cross-update: extractor side here is unchanged and holding. the client (InfinityLoop1308/PipePipeClient#47) just landed a fix where the default was picking AV1 (no HW AV1 on the Pixel) and falling back to 4K instead of the user's 1080p, now it honours the resolution. with that the full SABR stack is solid on Pixel 8 + Galaxy S25 + emulator (android 14/16), nothing pending on the extractor side.
Priveetee commentedon Jun 6, 2026
hey, this is a dev thread for the SABR work, not support, and unrelated to SABR anyway. if you want it triaged, open it on the main repo: https://github.com/InfinityLoop1308/PipePipe
SreerajSK990 commentedon Jun 6, 2026
sorry , deleted it
Priveetee commentedon Jun 6, 2026
Np ;) and thx for the understanding