fix(YouTube): Fix issues related to playback by replace streaming data

[zainarbani]

Integration changes

Todo:

• Refactor
• Test if the URLs really work as is (because usually they need post processing like in NewPipe)
• Check if properly optimized (make request as early as possible in parallel)
• Test what can be ticked in bug(YouTube): Spoof client patch - various side effects (watch history, auto resume playback, ...) #3208 (edit: it appears that all issues are fixed)
• Using iOS client as streaming data sources (more playable videos than VR and other).

[YT-Advanced]

Uhm so what is the different with current approach 👀

[oSumAtrIX]

Patches the response

[zainarbani]

Another backup plan maybe 🤷‍♂️

[0xrxL]

Another backup plan maybe 🤷‍♂️

This approach can fix at least one of still existing issues with client spoofing? For example brand account history or HDR with vp9 codec?

[LisoUseInAIKyrios]

I don't have a brand account, but it seems this PR would fix that since it's replacing response data. HDR probably is not fixed.

[oSumAtrIX]

The VR client supports hdr streams. The more important question is, if the streams work because usually they need additional post processing as seen by NewPipeExtractor for example. YouTube may apply the post processing from the original request though which could work without any further changes

[zainarbani]

@0xrxL HDR vp9.2 works, though i don't remember if vr client has av01 format

[zainarbani]

HDR on VR client could be fixed by replacing player config with android one, but its not the only things that missing from vr player response fields. Also VR client lack of kids videos (maybe other as well).

As for iOS client, i've tried to replace the player config but video playback doesn't work which im not sure what happened.

[ghost]

Currently, NewPipe cannot play 18+ content. This PR can cause problems

[zainarbani]

@Pamilg9 Its fixed by adding Auth headers.

edit: contentCheck/racyCheck on innertube body may required too.

[LisoUseInAIKyrios]

If there are any issues with replacing streams for any specific video or situation, then it should be possible to fall back to using the existing client type spoofing approach.

[zainarbani]

If there are any issues with replacing streams for any specific video or situation, then it should be possible to fall back to using the existing client type spoofing approach.

Agreed, i think the worst scenario is we got zero streaming data from client list, or streaming data simply unplayable at all.

[LisoUseInAIKyrios]

The client spoof hooks are called before the fetch stream hook. And the stream replacement hook needs some of the post data passed into it's hook. Which means by the time it's fetching the streams it's too late to fall back to spoof the client if the stream fetch fails.

So falling back to client spoofing would need more work. Specifically, it would need another hook that is called before all the client spoof hooks, and it also has all the data needed to fetch the streams.

[LisoUseInAIKyrios]

This PR fixes VP9 HDR video for my device.

The Settings UI needs consideration on how to present everything, since without fallback functionality it requires choosing between either Client spoofing or Stream spoofing, but not both.

The AVC override works for both spoof types.

[LisoUseInAIKyrios]

For now, the stream replacement is shown in the UI as a third spoof type (Replace streams, iOS, Android VR) since fall back functionality does not work just yet.

[oSumAtrIX]

The stream spoofing should ideally replace the client spoof patch entirely to reduce the complexity of the patch to it's minimum. Patching the request comes with issues fixed by patching the response. The only concern is that the streams returned by our custom request may not work because the custom request is not done properly, but so far the original request is sufficient for YouTube to post process the URLs from the custom request to make them playable currently.

[zainarbani]

Implementing pre-fetch streaming data maybe a good idea, faster load while scrolling shorts/general videos. but i think VideoIdHook patch no longer detect the next videoId with /initplayback being blocked. There's a way to invalidate /initplayback reponse data instead blocking it, but i don't quite remember if this methods allow videoId hook patch work normally again. I can do some test if needed

[zainarbani]

@oSumAtrIX Do we neeed to follow this way? adding poToken on innertube body and uri params

[YT-Advanced]

@oSumAtrIX Do we neeed to follow this way? adding poToken on innertube body and uri params

If u want to add another client, like ANDROID or WEB, u have to add potoken. Otherwise, it is not necessary

[ghost]

NewPipe has playback issues. Still not fixed

[zainarbani]

NewPipe has playback issues. Still not fixed

We're not using NewPipe atm, and what kind of issue?

[LisoUseInAIKyrios]

NewPipe has playback issues. Still not fixed

We're not using NewPipe atm, and what kind of issue?

https://www.github.com/TeamNewPipe/NewPipe/issues/11139
https://www.github.com/TeamNewPipe/NewPipe/issues/11382

But both of these issues are because NewPipe does not use any YT user authentication. Those issues do not apply here.

[oSumAtrIX]

What if you go incognito?

[oSumAtrIX]

Thanks for all involved!