-
-
Notifications
You must be signed in to change notification settings - Fork 629
fix(YouTube - Spoof video streams): Use webview to generate a PoToken for web client streams #6313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
|
@oSumAtrIX Thank you very much for your work. But as I mentioned in other PR, the following is related to pr. We can also create a fork of Extractor. Ytdlp-ejs solution. Revanced can use Quick.js (recommended). Otherwise it will be http 403Beginning very soon, you'll need to have the JavaScript runtime Deno or quickJS installed to keep YouTube downloads working as normal. You can pass "JavaScript runtime" outside of NewPipeExtractor like ytdlandroid. (works very well) yausername/youtubedl-android#338 Potoken can be created with or without auth. Some clients, such as web_creator (requires cookies) , will only work with authentication. Not all clients support authentication via cookies. MicroG cookies may not work with web clients New potoken improvement (Beta)YouTube switched to using content-bound poToken, i.e. the poToken is generated for each video using the video's ID. Video ID is used instead of standard Vistordata for Potoken. If not done, it will be http 403 . Does not require any special changes to the Extractor. We need to do this for ReVanced Caption Potoken. For web clients**Potoken support could also be implemented for "Caption". Newpipe has not done it yet. But if a Potoken is created in the application using Webview, can you do it in ReVanced? Ytdlnis has done this. However, ytdlnis uses yt-dlp, but Potoken is created in the application (manually) Web client can request SABR. Newpipe does not implement this yet. Ytdlp and FreeTube did it.**YTdlp pr; yt-dlp/yt-dlp#13515 Other: etwoo/youtube-unthrottle@76b48d0 Freetube: FreeTubeApp/FreeTube#7145 Libretube implements this but will modify it in Extractor and then release it |
|
A background webview runtime is all that's needed technically speaking and it would also be future proof since runtimes can break. I don't know about SABR much and I wouldn't know how to replace urls. The question is how the YouTube app can work with web urls for now |
LibreTube is working on SABR and you can't wait for their integration. |
|
YouTube already can handle sabr. The point is how we can "patch" the app. Before SABR, we basically just have to replace an array of playable URLs. I dont know anything about sabr but i believe its not just URLs. Maybe it is, dunno. If the patch side is figured out, its as simple as leaving the heavy lifting to efforts like libretube, ytdlp, newpipe (thankfully) |
libre-tube/LibreTube@66bb46d |
|
from what i saw SABR is more than just a playback URL. The server sends some kind of client specific config and "streams" video bytes. It could require us to either:
|
If you apply the Libretube "SABR streams" PR on ReVanced, you can use a custom NewPipe Extractor fork for this. You will need to manually build this. It does url extraction and more. The author has kept it as a test and they don't think it's necessary to release it yet. Later, the Official Extractor will support it. https://github.com/FineFindus/NewPipeExtractor/tree/feat/sabr |
|
For now I will use whatever NewPipe uses. It's more stable |
|
It may be useful for SABR: Server-Based Smart Adaptive Bit Rate (SABR) Streaming With Statistical Multiplexing👇 |
It is intended to spoof the video streams to the web client. For this NewPipeExtractor is used with a PoTokenProvider implementation from NewPipe which uses a background WebView to pass BotGuard. It is assumed, that issues like playback, audio tracks and co would go away. However, NewPipe is not authenticating against YouTube, so some changes may be necessary.
The PR is not ready yet:
Continuation of #5912