itag-18 fallback videos (low res 360p) fail to seek later in videos

[t6fb3m59]

Official Instance

• The bug is reproducible on the official hosted instance, or is API-related.

Describe the bug

In short it's a piped-proxy issue with how it interprets the length of the video in bytes for the headers.

I have solved this on my fork's image: logicalkarma/piped-proxy.

Write-up from Claude:
Since handle_range_response_correction uses the upstream response's Content-Length as total_size, any range request with a non-zero start byte produces a malformed Content-Range header. The upstream Content-Length reflects the size of the returned chunk, not the full file, so the synthesized header has end < start and the wrong denominator. Curl ignores the header mismatch, and Librewolf typically dodges the bug because its eager-prefetch behavior issues a single open-ended range from byte 0 and never seeks past the buffer. Vanilla Firefox and Chromium both hit it on seek-past-buffer in itag-18 (360p progressive) playback, presenting as an indefinite "loading" spinner; in Chromium, DevTools shows the response aborting after ~700 bytes. The fix is to use the clen query parameter (canonical full file size) instead of the upstream Content-Length.

To Reproduce

1. Find a video that fallbacks to itag-18 (no configurable resolution - 360p)
2. Go somewhere towards the end of the video.
3. Player loads indefinitely

Expected behavior

1. Find a video that fallbacks to itag-18 (no configurable resolution - 360p)
2. Go somewhere towards the end of the video.
3. Player moves to the expected time and plays

Logs/Errors

No response

Browser, and OS with Version.

Anything that does not cache the entire video. All browsers except some privacy centric ones which avoid this bug unintentionally (Ironwolf, Librewolf).

Additional context

No response

[10203]

This appears to be due to YouTube switching over to a new streaming protocol SABR. It existed for a while, but is now enforced on mobile and web. Your fork of piped-proxy does not seem to fix the issue. NewPipeExtractor is introducing a fix of masking as an "ANDROID_VR" client, I expect that to be temporary until YouTube removes DASH altogether. From what I can tell, as not knowledgeable I am on this, SABR includes encryption and is a drastically different protocol from DASH or HLS, so implementing it into the front-end would not be easy. There currently are no examples of any youtube front-ends that have SABR support as far as I can tell.

[t6fb3m59]

I am pretty sure I tested and fixed this issue. The problem is not that itag-18 is used, but rather that the proxy handles it poorly and hands off broken delimiters for the dash segments because the reported size of the video is smaller than it. Please read the steps to reproduce vs actual behaviour and let me know if that clears it up.
As for SABR, FreeTube implements it as of ~ March and I have a fork with a usable, but at times buggy, implementation for Piped. Read up on Piped-LK in my repos for more info on this.

[10203]

For the record, I interpreted this as fixing videos falling back to itag-18. As of a few days ago all videos fallback, watching 360p videos is already pretty rough on a phone, but unwatchable on pc. I believe fixing video falling back to itag-18 should be a priority over anything else. I think most people can deal with weird playback bugs or slow loading, however when content is directly affected that's a lot more difficult to ignore. That is at least my opinion.

[t6fb3m59]

No worries. If I saw an issue with itag-18/ 360p in the title I would also instantly assume it's another "Piped sucks why can't I watch 4k" issue. I have been trying to mop up some of the simpler bugs I could find. I eventually gave up on making issues, this is the latest one I made. Everyone agrees SABR is a must if they know the current state of yt frontends. If you are looking for SABR feel free to give the experimental branch on my fork a try. It addresses any of the grievances I could find and come up with, just keep in mind that I treat it as a development environment. Make sure you read the readme on Piped-LK first. If you get a version that you like, I recommend not doing automatic updates for it. If you have issues with the branch, feel free to drop an issue on the repo.

[772810]

Thanks for all the fixes you've made in your fork @t6fb3m59. The experimental branch implementing SABR support has worked flawlessly in the months I've used it - seeking, full quality selection (and those pesky Firefox bugs.) Hope to see them upstream.