dirkf

But maybe just patch into `YouTubeDL.urlopen()`, as a `BaseHandler` doesn't seem to be able to change the URL of the `Request` being processed?

Actually #6385 and #6526 are a more basic problem where the `../` sequence is embedded in the path and not RFC-bustingly directly after the host part as in OP's problem....

Working in yt-dl git master, where there is no `../` sequence in the media link. #6385 is a similar problem and I guess they can be solved together. Also, this...

Selecting the same actual format `dash-fastly_skyfire_sep-audio-4479401a` provokes the error in yt-dl, which prefers a DASH format where the downloader explicitly calls `urljoin()`. Then we have #3355 because no path munging...

Working in yt-dl with commit https://github.com/ytdl-org/youtube-dl/commit/e8de54bce50f6f77a4d7e8e80675f7003d5bf630.

https://github.com/ytdl-org/youtube-dl/issues/31334#issuecomment-1469376055.

Check the penultimate line of the patch code above to see where the contraband fragment comes from. This mechanism is used to pass options with a URL from a user-facing...

For devs out of region, note that the API used by the extractor isn't geo-blocked, and so the various media links tested in the patch code can easily be inspected....

From the yt-dl thread, a new API should be used. The `htmlandroid` links include a `sz` query parameter that implies the size would be ~ 550x300. >my patch doesn't touch...

That URL actually links to a [SMIL manifest playable in many media players](https://github.com/ytdl-org/youtube-dl/issues/31841#issuecomment-1474831575). Try putting it in your FF or Chrome-alike URL bar.