PipePipe's apparent circumvention of recent YouTube preroll ad enforcement (help/assistance request)

[ivo-doko]

Hello!

Recently, YouTube has rolled out a change which resulted in a few other extractors having to wait for the preroll ads to finish before the video can start playing. This is at least the case for FreeTube, as the release notes for the latest hotfix release state:

Video loading times have increased because YouTube's servers now return errors if you attempt to start a video before the preroll ads have finished. While FreeTube skips the ads, it still has to wait until the preroll ad sequence completes before the video can begin playing. This is a limitation imposed by YouTube’s servers, and it also affects other YouTube-related projects, such as yt-dlp.

However, since I use PipePipe on my Android device, I've noticed that it seems as if PipePipe isn't affected by this. I.e., it still loads and plays videos quickly, as if no waiting for preroll ads is taking place. This also seems to be the case when I install and run PipePipe in an Android emulator like BlueStacks.

(It is however possible that I don't know what I'm talking about and this perceived difference just isn't real, but given how readily apparent the difference in the waiting time before any video starts playing is, I currently find that hard to believe.)

I've created a related issue on FreeTube's repository, and I would be extremely grateful if PipePipe developers would be willing to provide any useful insight and tips regarding the possibility of incorporating what seems to be a better method of extraction used in PipePipe into other projects like FreeTube and/or yt-dlp.

[InfinityLoop1308]

Hi @ivo-doko, sorry for the late response.

The main difference is that we are using the android_sdkless player client instead of the po token based clients (like the web client). Earlier this year, many other 3rd party YouTube projects (including yt-dlp, NewPipe, etc.) were relying on clients that require a po token, an approach that tends to break easily.

However, in October, yt-dlp finally switched to using the android_sdkless client as default (see: yt-dlp/yt-dlp#14693). So I assume most other projects have now done the same or are in the process of updating, which should bring them to the same level of stability that we have.