Replace the plain /youtubei/v1/player request (made through the proxy,
and therefore bound to the proxy's egress IP) with an encrypted Onesie
request using the WEB client. Onesie is proxied by YouTube's "trusted
bandaid", so the returned player response - and the server_abr_streaming_url
inside it - is not tied to our egress IP. Media is still pulled over SABR
(sabr_scheme_plugin.js); only how the player response is obtained changes.
- sabr_onesie.js: new module, window.fetchOnesiePlayerResponse(). Builds the
WEB player request, encrypts it (OnesieInnertubeRequest + OnesieRequest),
POSTs to the onesie endpoint through /proxy, parses ONESIE_HEADER/ONESIE_DATA
UMP parts, gunzips/decrypts, returns the raw player response JSON. Adapted
from googlevideo/examples/onesie-request and invidious-secret-companion's
WEB-client variant.
- sabr_helpers.js: add decryptResponse() (AES-CTR + HMAC verify), companion to
the existing encryptRequest().
- sabr_loader.js: expose window.YT so a VideoInfo can be built from the raw
onesie player response.
- sabr_player.js: in loadVideo(), fetch the player response via Onesie and wrap
it in new YT.VideoInfo(...); fall back to innertube.getInfo() on failure.
- player.ecr: load sabr_onesie.js before sabr_player.js.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Segment index parsers (mp4/webm) declared the per-segment URI array with
`var` inside the loop, so every SegmentReference's getUris() closure
captured the same function-scoped binding and returned the LAST segment's
URL. YouTube received the final segment's startTimeMs/sq for every
segment, replied with policy-only UMP (no media), and the player looped
forever on a black screen ("SABR throttled by YouTube"). Use `let`
(block-scoped, fresh per iteration) to match FreeTube's `const`.
Also scope the big centered play button styling to
`.shaka-play-button-container`; the bare `.shaka-play-button` selector
also matched the control-bar play button (48px siblings), oversizing it
to ~54px and pushing it out of alignment.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Revert "Fix Youtube and Invidious links not rewinding their time when video timestamp is rewinded"
This reverts commit c3ee8a5d90df83d6e53b78b6d6e9669729b391aa.
When switching between Listen and Watching the timestamp in the url of
the listen of watch button is now updated automatically.
This means if you switch between listening and viewing you keep in sync
with time.
`update_ticker_count` used to use STORAGE_KEY_STREAM to get the number of notifications which is a boolean value, now it uses STORAGE_KEY_NOTIF_COUNT which is an integer
This PR adds a configuration option to control the preloading of video data on
page load with the HTML5 'preload'[1] attribute on the `<video>` element.
The option is enabled by default, meaning that the `preload` attribute's value
will be 'auto'. If users want to prevent preloading of video data, they
can disable the option, which will set the attribute value to 'none'.
[1](https://www.w3schools.com/tags/att_video_preload.asp)
Closes issue 4110
Trying to watch an already watched video will make the video start 15
seconds before the end of the video. This is not very comfortable when
listening to music or watching/listening playlists over and over.
Multiple users have reported that the fields parameter is slowing down API
response times significantly. As most API endpoints are already optimized to
make as few requests as possible to Youtube, there is no point in limiting the
output. Furthermore, the added processing might be part of the broader memory
leak problem (See 1438).
In addition, the small increase in data output is not much of an issue compared
to the huge video proxy that lies next to this API.
No related issue tracked
