Add after-sponsor buffering

[playsenge]

Hello! While I love SponsorBlock, there's a minor issue/suggestion. When I am watching a video with a sponsorship coming up at the beggining, when it skips after the sponsorship it hasn't buffered yet and has to load the part after the sponsorship. It's instead buffering the sponsorship (which is useless).

Hopefully this can get accepted!

Thanks, senge.

[ajayyy]

Sadly, I do not think this is possible

[elypter]

it might be possible on an alternative youtube frontend that directly integrates sponsorblock. there are currently no plans that i know of for invidious or others to implement it though.

[playsenge]

Well, if they don't know about this or no one requests it to them they are not going to do it :P

[elypter]

it would be either your or the repositorys owner to ask for upstream changes. regardless i already asked 2 weeks ago and it was beyond the maintainers scope. so realisitcly you are only going to see this change if you do it yourself.

[NDevTK]

@playsenge I have been trying implement this as it seems practical to do. Progress: https://gist.github.com/NDevTK/be7df78ac1b6e3dbf12ef97afa941c18

[NDevTK]

Sorry about the delay this issue has not been forgotten about.

[NDevTK]

tbh I did forget... may look into this more if I remember :)

[ccuser44]

The sponsor buffering should also not load the content inside the skippable sections to save bandwith.

This could be done via directly modifying the yt loader javascriot

[NDevTK]

Seems like there would be compatibility issues with that. If it went that far it should modify the video source so that skipping is instant.

[ajayyy]

Some notes from working on waveform editor implementation that might be helpful for this:

Hijacking fetch function will be able to take over the fetch request. Requests follow a pattern, and for after-sponsor buffering, playback URLs for future chunks could be pre-fetched from the m3u8 playlist and returned instantly when YouTube itself tries to fetch it to create an instant buffer effect.

videoplayback video requests all are almost the same except for a few fields that vary

Ensuring the correct resolution is pulled would be important. Data should be accessible from ytInitialPlayerResponse or /player requests made through fetch. However, this data doesn't seem to have a direct url to an m3u8 right now. Will need to look into how/if yt-dlp derives one from the data that is there. Or the range somehow has to be calculated from the indexRange or initRange variables in ytInitialPlayerResponse.

Fetch function is already being hijacked by document script for other reasons, so can reuse this injection point.

[NDevTK]

I would prefer something that's not hijacking network requests. Maybe something like quickly changing the currentTime to end of sponsor then changing it back will make there player do the work.

[ccuser44]

I would prefer something that's not hijacking network requests. Maybe something like quickly changing the currentTime to end of sponsor then changing it back will make there player do the work.

Changing the time back and forth is more hacky

[NDevTK]

I agree network way is "less hacky" still never ended up getting it working :/

• [ ] Convert end of sponsor time to byte range
• [ ] Fetch end buffer using first url as template (for each format) and cache in memory.
• [ ] Detect when requested url is for the correct part of the video and respond from cache.

[ajayyy]

I've done more research on DASH range requests and I don't see an easy way to predict what ranges for each chunk YouTube will use. It seems to vary, and there is no manifest file for non live videos

Edit: However, maybe it can fetch an arbitrary large-ish range from YouTube and then cut off the range as needed when YouTube makes it's fetches. Wouldn't be that hard to test if that works.

[JxxIT]

@NDevTK Hi, any progress on this? Thanks for looking into this!

[NDevTK]

Yeah so this is still a thing... I don't use the extension and making this change would increase the risk of YouTube playback breaking. One fix that might work would be to get a faster internet connection if this is not practical in your area you have two options.

• Go someone else
• Use virtual desktop infrastructure (VDI) this makes it so the pointless buffering is handled by the remote server

Hope this helps, NDevTK Support.

[JxxIT]

I'm working on implementing this.