fix(download): refuse SABR streams instead of crashing post-processing#66
fix(download): refuse SABR streams instead of crashing post-processing#66Priveetee wants to merge 1 commit into
Conversation
|
The old dash/http path are all deprecated now. Only SABR and HLS (only available on web_safari) are usable. That means if refuse SABR, users setting youtube extraction endpoint to mweb or web won't be able to download anymore. I think maybe easier - always fetch data from web_safari, and only use HLS for downloading before SABR download landing. What's your opionion? |
|
I use an alternative way: always use hls for now. |
|
@InfinityLoop1308 Sorry for the late answer, it was night here :) Yeah I agree with you. Refusing SABR was only meant to stop the current crashy path, but if we can force/download through HLS for now, that is better for users than blocking downloads entirely. So your temporary HLS path makes sense to me. For the real implementation, I’m working on proper SABR download support. It needs more than just passing the SABR endpoint to the current downloader: it has to drive the SABR session, request the selected audio/video formats, collect init/media segments, and then write/mux them correctly. So yeah, HLS for now, real SABR download later. |
Fixes InfinityLoop1308/PipePipe#2569
Summary
Force SABR currently exposes YouTube streams with
DeliveryMethod.SABR, but the download stack still expects normal downloadable resources.This PR refuses SABR downloads early in both the normal download dialog and the playlist/batch download path, with a clear message instead of letting the current downloader crash during post-processing.
Problem
SABR streams are not direct media URLs.
When Force SABR is enabled, the extractor exposes audio/video streams whose
contentis theserverAbrStreamingUrl. That URL is the SABR session endpoint used by playback. It is not a plain WebM/MP4/DASH resource that the downloader canGETand pass toWebMReaderorMp4DashReader.Before this change, the downloader could start a mission with that SABR endpoint anyway. The downloaded bytes were then not a valid WebM/MP4 resource, so post-processing failed with errors like:
There is also a cache-related variant of the same bug: if a video was opened while Force SABR was enabled, its
StreamInfocan stay inInfoCachefor a while. Disabling Force SABR after that does not necessarily refresh the already cached stream list immediately, so the download dialog may still receive SABR streams.Changes
DeliveryMethod.SABRbefore starting a normal single-video download.DeliveryMethod.SABRbefore starting playlist/batch downloads throughDirectDownloader.Validation
Build:
./gradlew :app:compileDebugJavaWithJavac./gradlew :app:assembleDebuggit diff --checkLocal code validation:
upstream/dev/v5.2.1-beta2.StreamInfostill exposing SABR streams after Force SABR was disabledNotes
This is intentionally not the real SABR download implementation.
A proper SABR downloader is coming, but it needs more implementation and a lot more testing. It cannot just reuse the current direct downloader path. It needs to drive a
YoutubeSabrSession, request the selected audio/video formats, collect init/media segments, write or mux them correctly, and handle the same SABR session/protection behavior that playback already has to deal with.So this PR only closes the crashy unsupported path for now. Users still need to disable Force SABR and reopen the video with fresh non-SABR streams if they want to download before real SABR download support lands.