Я проверял множество раз на разных видео. Через прокси всегда тарифная скорость. Без прокси всегда еле еле 120килобайт. И до GGC, и трансгранично. На том видосе именно GGC попался, я это знаю.
Хром без QUIC демонстрирует те же 120-200 килобайт буферизации, что и yt-dlp без прокси с такими ж паузами. Всё сходится.
Тест в curl так же показывает, что мой ISP тригерится на googlevedeo.com.
Всё очевидно. -Это НЕ косяк yt-dlp и не защита гугла от ботов.
Благодарю, этот тест выдает HTTP/3 Check established a QUIC connection for all attempts made with the given endpoint.
А вот судя по about:networking www.youtube.com идет по протоколу http2, rr3---sn-oxuctoxu-n8vl.googlevideo.com - http3, rr4---sn-c0q7lnz7.googlevideo.com - http1.1. Интересно…
Давайте поотлаживаем, если хотите.
Я делаю так и не вижу проблем на своём канале.
Должен работать, проблем с ним не вижу. До ≈начала этого года блокировали QUIC, возможно, где-то блокировки сохраняются на какие-то направления.
Что-то сказать можно по дампам трафика.
если вы поставите себе jdownloader2 и гудбайдпи при этом поможет от глюков при скачивании им файлов 1080р с ютуба, то тогда есть смысл поотлаживать. но не поможет, потому что он, насколько я понимаю, качает с ютуба как-то по другому, не так как браузер и yt-dlp
Я не вижу проблем на своём канале.
Скачивание видео с youtube обычными качалками, а не специализированными, вроде yt-dlp, замедляется самим youtube уже несколько лет как. И 50 кб/с похоже на скорость замедления самим сервисом.
В yt-dlp встроен интерпретатор javascript, чтобы проходить challenge’ы со стороны youtube, он симулирует работу браузера, скачивая небольшими кусками, использует разные user-agent’ы, и т.п.
нет, не похоже. я уже ответил на это ваше предположение. я много лет качаю с ютуба кучи видео, а вот эта вот фигня началась несколько дней назад
Этот тест проверяет наличие поддержки QUIC на заданном сервере, а не на клиенте. В вашем случае на самом www.http3check.net. Результат не зависит от используемого браузера. Вот результат запуска в браузере links. 
это вопрос скорее к [In progress] Youtube Issue/Suggestions/Questions thread - Page 153 - JDownloader Community - Appwork GmbH
когда опять/снова будут резать скорость в моей деревне проверю и jDownloader2
но там тупо нет никаких настроек в отличии от yt-dlp
даже выбрать IPv6 нельзя руками. автоматом он почему то его не использует…
Вот здесь еще можно проверить QUIC:
Надеюсь, редкий отпечаток поможет. Завтра затестю в Linux Live на ростелекомовском интернете. В любом случае, yt-dlp+curl+quic не очень хороший инструмент из-за ограничения уже гугла (2xrealtime), но для кого-то это может быть лучше, чем ничего (15 кбайт/с).
Мои вопросы по поводу ECH в curl и какую либу используют хромобраузеры для QUIC спецы видно проглядели. 
Может, как раз quiche. Upd: да, quiche. Но свой на C++, а не Rust. И гугловский BoringSSL.
спорно. у меня вот Хром без прокси на других сайтах нормально показывает рабочий http3 но на http3.is не хочет (причем favicon.ico он почему то по http3 скачал.) https://www.flickr.com/photos/200778714@N04/53881958522/sizes/o/
как впрочем и на https://one.one.one.one/cdn-cgi/trace тоже пишет http2
так что только F12 == включить “протокол” и смотреть что там на самом деле
Та же фигня
VPN/proxy и варианты с антиDPI никто не отменял если уж очень надо на ПК
вот что делать с ТВ/приставками у кого роутер не позволяет поставить zapret/bydpi/etc это уже вопрос
На линуксе byedpi какой-то сложный (разработчик сам признавал) и вроде бы медленный в плане ресурсов. Рабочие VPN/proxy не так-то просто найти.
А ведь трафик с Ютуба должен иметь специфический вид. И если Ютуб решат заблокировать наглухо, то и блокировать наверное разумно опираясь на анализ трафика. Тогда ни один способ обхода не поможет. Но я признаю, что слабо разбираюсь во всем этом. Просто мысль такая пришла.
буду благодарен если проверите.
