[Enhancement] SABR support

[unixfox]

Continuation of #4251, support SABR instead of DASH in the frontend.

In combination with Invidious companion.

Related issues:

• [YouTube] Coordinating efforts on SABR implementation TeamNewPipe/NewPipe#12248
• [Bug]: Audio formats are not available for this video / 360p only streams - SABR FreeTubeApp/FreeTube#7119
• [youtube] web only has SABR formats yt-dlp/yt-dlp#12482

Interesting links:

• https://github.com/LuanRT/yt-sabr-shaka-demo
• https://github.com/davidzeng0/innertube/blob/main/googlevideo/ump.md

[unixfox]

I have come to the conclusion that we only have two options. Each one have their upside and their downside.

First option: keeping DASH

Create a converter that will convert requests from DASH to SABR on the server side.

Advantages

• [BIG] No need to touch anything on the frontend side of Invidious. We can keep video.js, the current Invidious API. All 3rd party apps relying on Invidious will continue without changing anything.

Disadvantages

• [BIG] This processing will require more compute power because SABR comes with encryption, does not manage the video streams the same way as DASH.
  I'm not sure if this is going to work well on public instances and may require a beefier server than before.
• We will need to implement some kind of algorithm by ourselves, and we won't be able to reuse what alternatives projects using youtube.js are doing with SABR: freetube and so on.
  I also fear this may become a nightmare to maintain.

Second option: fully embrace SABR

• Switch from video.js to Shaka.js. (support for vp9 too)
• Implement the potoken generation on the client side using youtube.js.
• Implement SABR on the client side using youtube.js.

Advantages

• [BIG] We can reuse the work done by others using youtube.js for SABR: freetube and LuanRT/yt-sabr-shaka-demo
• This won't require a lot of compute power on the server side. And may very well reduce the bandwidth used and the compute power used, since a lot will be moved on the client side.

Disadvantages

• [BIG] This will be a big task to migrate to Shaka.js.
• This will probably be the end of 3rd party clients (clipious, yattee and more) unless they start to implement SABR themselves because at one point the workarounds for DASH will support working. They may continue using the 360p stream, but this will be a bit ugly to watch.
• Doing the potoken generation on the client side, not creating an open proxy for www.youtube.com and avoid having the IP blocked due to too many potoken generated. Will be a challenging task.
• The code of Google blackbox, Google anti bot system, will need to be executed on the browser watching the video. It's probably not that great for the privacy since we don't know what they are collecting.
• This will require JavaScript for video playback.

---

I'm personally more in favor of the second option because I want more public instances to be available and not the reverse.

But the first option will definitively work great for private usage. Although, in my opinion, if you are the only one using Invidious, you might as well use Freetube or Newpipe.

And for the 3rd party clients, that was bound to happen, that will stop working at some point. Now, not even one public instance have a public API opened.

[syeopite]

Ideally doing both approaches would be nice and the instance maintainer and user can choose whether they'll want full SABR or converted SABR.

If SABR absolutely requires doing all that client-side then I'm a bit hesitant to fully endorse that approach since that would mean weakening the core idea of Invidious: privacy.

Users should at least be able to choose between the more private but harder to compute conversion of SABR to DASH and the less private but better experience approach of a full SABR player.

Still the second option will make development much easier.

I'm not too familiar with the specifics but could a full SABR player still work well with server side processing logic?

[unixfox]

@syeopite IMO maintaining both approaches will be hard and tedious to do.

I already created the companion in the mindset of reducing the maintenance to do at invidious.

The biggest issue is that getting knowledge and being good at implementing SABR is hard. It's the same thing as the new potoken and so on. I personally do not fully understand everything.

I'm personally able to adapt an existing project (https://github.com/LuanRT/yt-sabr-shaka-demo) in order to integrate it into Invidious. But doing it everything from scratch, it's going to be hard.

But we can however keep the current implementation as long as possible, alongside SABR on the client side.
Maybe people using it will get a subpart experience because YouTube may start to force SABR on more clients, but I think there will still be some clients that will continue to not have SABR forced, at least from the many available clients: https://github.com/zerodytrash/YouTube-Internal-Clients

[jasondefuria]

I was browsing github an saw that this user seems to have incorporated SABR support into their own k8s build. https://github.com/acheong08/invidious-sabr-player

Perhaps worth a view to see incorporation?

[unixfox]

@jasondefuria thanks but it's just using https://github.com/LuanRT/yt-sabr-shaka-demo. a demo project that we already know about.

we are waiting to see what the other projects (freetube & piped) are going to do in order to implement something concrete in invidious.

[Figim]

Helper pr: yt-dlp/yt-dlp#13515
Other: etwoo/youtube-unthrottle@76b48d0

Freetube: FreeTubeApp/FreeTube#7145

[unixfox]

Luan released a full working version of a video player with SABR support: https://github.com/LuanRT/kira

This actually implement what I suggested as second option.

We could technically implement what Luan did in Invidious itself.