Local API: Implement SABR for VODs

[PikachuEXE]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

Closes #7145
#7887

Description

Based on #7145 (Please read that PR first
Using https://github.com/LuanRT/googlevideo 4.0.4

• Implementation updated (different from Local API: Implement SABR for VODs #7145) to have playback session scoped stuff like SABR context & playbackCookie (SABR details)
• Player streaming timeout doubled (30s > 60s) to handle sometimes ~40MB response instead of ~10MB (at 2k quality, e.g. https://youtu.be/NmdXl7vXZ7g)
• New setting for enabling SABR in experimental section

Non-SABR

• Also updated the implementation for Wait for pre-roll ads to finish in /player request #7887 to show pre-roll ads time in toast
• Toast now updated to be possible to show updated messages (hard coded to refresh per 1s currently)

Screenshots

Lazy maybe add later?

Testing

A. SABR off

• Test pre-roll ads time toast
• Test various video playback (should be the same)

B. SABR on

• Test various video playback (should be the same)

Find custom builds at https://github.com/PikachuEXE/FreeTube/actions/workflows/build.yml?query=branch%3Asabr-pr
Find cutting edge custom builds (I only use this branch for testing fixes myself, but can be outdated once I finished testing): https://github.com/PikachuEXE/FreeTube/actions/workflows/build.yml?query=branch%3Acustom-builds%2Fsabr

Desktop

• OS:
• OS Version:
• FreeTube version:

Additional context

Remaining tasks

• Add/Update labels/tooltips/toasts & make them translatable (after text confirmed)
• Handle infinite player reload - Allow max 3 player reloads for the same video before fallback to older DASH, if player loaded the reload doesn't count
• Handle player reload during playback - Reload while keeping timestamp
• Handle SABR playback delay in the middle - keep toast for now
• Handle infinite SABR playback delay - reload player after (per req) backoff requested 5 times / cumulative delay going to be larger than timeout for request
• Handle infinite next request policy received - reload player after (per req) next request policy received 100 times
• Enable SABR by default
• Handle more edge cases if found

Post PR

• Remove download feature (broken anyway)

[efb4f5ff-1298-471a-8973-3d47447115dc]

Didnt test yet but im very sure this will close the SABR related issues

#7119
#6683

[absidue]

I really hope it being an experimental setting that is disabled by default is just because you have some things left in the remaining tasks section...

[PikachuEXE]

I don't think it should be enabled by default for the first release
Otherwise there might be too many feedbacks to be handled
Whether it should remain in experimental section depends on how many edge case found and not handled well (Might be moved or not before next release

[absidue]

If we are going to keep it as a setting for the moment, it definitely should stay in the experimental settings and we should have a very clear plan for getting rid of it ASAP. The MWEB workaround is a workaround and is unlikely to keep working forever, so if it breaks while we still allow people to not use SABR we will have to keep finding new workarounds, which quite frankly I don't want to have to do when we know that SABR is the proper solution.

If we keep it a setting I would suggest enabling it by default but having the setting there as a temporary opt-out, that way we'll get more feedback but people can also disable it temporarily if they have issues, until you've decided it is stable enough.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Both with and without SABR i get this error but that is on a server that is running through tor. If i connect to a normal server it does work

VirtualBoxVM_pCIApV5i4Z.mp4

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Im not seeing the return of audio tracks -> #6683

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[PikachuEXE]

Test fix not pushed this this PR yet: https://github.com/PikachuEXE/FreeTube/actions/runs/17907855602

[efb4f5ff-1298-471a-8973-3d47447115dc]

Seems to resolve #7921 but we have to check with users after release

[ArthurKun21]

Test fix not pushed this this PR yet: https://github.com/PikachuEXE/FreeTube/actions/runs/17907855602

Was using this and got hit with 404 earlier for a music

https://youtu.be/8tamOu8AwFE

bundle-1758589261369.log

It was only once so far.

[PikachuEXE]

Maybe last build - https://github.com/PikachuEXE/FreeTube/actions/runs/18607715883
Fixed issues in PikachuEXE#83 (maybe OS specific no idea)
Added a tweak to load less data for video/audio requests (no idea how to test if it really loads less data) taken from https://github.com/LuanRT/googlevideo/blob/googlevideo-v4.0.4/src/core/SabrStreamingAdapter.ts#L426

[ArthurKun21]

Hello, thanks for the work. Just wanna say for future reference.

The issue in PikachuEXE#83 like the video getting stuck in the link https://youtu.be/8sJCPuweieA was present in both windows and mac machine. But the issue was already fixed with the succeeding commits

[pnaf]

I just wanted to add that the stuck player issue in that link was also happening on Linux (I was also encountering the issue at the end of https://youtu.be/vBynw9Isr28, for example). So it seems less likely that this is an OS-specific issue.

The new build with the workaround did fix that issue for me. Thanks!

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[PikachuEXE]

Maybe last build 2 - https://github.com/PikachuEXE/FreeTube/actions/runs/18669891374
Fixed issues in PikachuEXE#83 with better fix and re-tested by issue opener
Previous fix might not work in some cases (but can't really find an example yet) but this one should work for all
Details in PikachuEXE#83 (comment)

[kommunarr]

Not sure why, but this video causes the SABR to get stuck in a loop refreshing the video constantly. Even after leaving it and trying to watch any other video, they also get stuck in a SABR loading loop until I terminate and restart FreeTube.

[PikachuEXE]

@kommunarr Sorry I can't reproduce SABR loop (reload loop?). It just starts playing right after backoff time
I have no idea if it's random or what (it's rare and doesn't happen again with the same video

[kommunarr]

Yes, an infinite reloading of the player. It still occurs consistently for me on that one video, although for unknown reasons, my other videos are still playing fine this session after encountering this error as opposed to last time. Here's what showed up in the console on the player reloading FWIW:

renderer.js:2 Player Error (category and code explainations here: https://shaka-player-demo.appspot.com/docs/api/shaka.util.Error.html)
Video ID: "i25z70gPuAU"
FreeTube player context: "loading dash/audio manifest and setting default quality in mounted"

Severity: CRITICAL (2)
Category: undefined (undefined)
Code: undefined (undefined)
Stack trace:
TypeError: Cannot read properties of null (reading 'Qa')
    at Of (renderer.js:2:460753)
    at Object.get [as isAudioOnly] (renderer.js:2:456898)
    at renderer.js:2:2399284
    at renderer.js:2:99774
    at renderer.js:2:101470
    at renderer.js:2:101711

[PikachuEXE]

If you see a toast about reading then it's handling SABR reload request (which is caused by unknown reason and hard to reproduce)
The error is raised due to reload (Running player.isAudioOnly() I guess and player is gone, so it's not causing it
I can try to make the error disappear

Update 1: Build with error fix (will still emit LOAD_INTERRUPTED but it's shaka behaviour): https://github.com/PikachuEXE/FreeTube/actions/runs/19053961955

[PikachuEXE]

After 3 reloads I coded it to fallback to non SABR...