Ютуб у меня перестал лагать :)

Короче в firefox 115 ESR килобиты и вечная подгрузка раз в секунду, в firefox 127 такая же херня.

Выстави «user agent» как в chromium, https://www.linux.org.ru/forum/talks/17678114?cid=17684459. Может и у тебя сработает, кто знает.

p.s. У меня с воспроизведением в firefox никаких проблем (1080p), как я уже писал, и я там ничего не менял в принципе, за исключением давнишнего перехода на m.youtube.

Выстави «user agent» как в chromium

Так я и пишу что у меня всё норм стало, мне никаких больше манипуляций делать не надо. Я хромым не пользовался, он просто стоял, зашёл включил принудительно флаг для quic и всё, зашёл в акк ютуба и всё просто работает. Ничего больше не делал, чистый браузер, даже расширений никаких нет.

Опять же, у кого-то работает всё нормально и никогда проблем и не было, а кого-то затронуло, вот мне попался полудохлый CDN если верить нашим СМИ и официальному ответу ютуба, они сами там пишут что местами проблемы с железками, а местами всё норм. Вот и всё.

UDP: Тьфу я тебя не так понял, ты имеешь в виду что это ютуб режет и если ему иной юзагент сунуть то разлагается… Ну попробувом ща

Принудительно включил этот tcp over udp

бессмысленно, он по умолчанию включен, видно по F12 (инструменты разработчика) > сеть, включить показ колонки протокола если нету

Но я даже смотреть не буду откуда именно сейчас трафик мне по нормальному летит.

Зря, надо же знать с каких GGC трафик не замедляется.

Принудительно включил этот tcp over udp
chrome://flags/#enable-quic

у меня на дебиан ночная сборка ff после новостей от ростелекома (у меня ростелеком) Ютюб логать перестал. Но в закладки оставил.

А сначала я хотел CDNы у себя заблокировать дабы оно пыталось трафик откуда то ещё брать, а оно вот так расчехлилось.

CDN разве можно как то заблокировать? без потерь всего трафика?

CDN разве можно как то заблокировать? без потерь всего трафика?

А хрен его знает, хотел попробовать, но заработал первый вариант.

CDN разве можно как то заблокировать?

Есть, например, расширение Decentraleyes.

видно по F12 (инструменты разработчика)

Не видно, у меня не показывает протокол

бессмысленно

Смысленно, без явного выставление в Ebabled плохо грузит и в chromium

Нюанс видимо где-то в логике работы всего этого. Видимо предложение сменить юзер агент в ФФ тоже про это (у меня не сработало), когда браузер сообщает сервакам что я могу и хочу сейчас quic в первую очередь, ну оно на то и «переключает», а если есть хоть что непонятное то идёт обычный http2 ибо http3 работает на уровне приложения и если нет 100500% гарантий что всё поддерживается, то на него ничего не переключается. Но это мысли в слух.

Суть проста, если трафик прёт по UDP через quic то всё работает, если у этого на пути где подножка то не работает. Всот и всё =)

Финт с юзерагентом не прошёл, там видимо надо филигранно подобрать его агент этот и браузер иметь нужный так что-бы всё сошлось. И ютуб отдал трафик в виде UDP и ФФ его смог корректно принять. М что знаем что на слова проддержка фичи одно, а на деле другое )))

Ну да ладно, вникать в это смысла нет, работает и ладно.

Ну блин, я надеялся, что будет решение для yt-dlp, а тут опять про браузер… А в нём у меня и так не лагает.

Под твоей темой, в похожих, тема «Ютуб закроют? (2014)».

2014…

Оглянись, незнакомый прохожий,
Мне твой взгляд неподкупный знаком
Может, я это, только моложе -
Не всегда мы себя узнаём…

почитал оно подменяет собой популярные не меняющиеся источники js кода вроде jQuery, но самого жирного и важного контента это не касается 😭.

Попробуй подсобрать всё это

• https://curl.se/docs/http3.html

И потом закачать вот так

yt-dlp 'ВИДИВА' --external-downloader curl --external-downloader-args '--http3'

Я было хотел всё это потыкать, но пока лениво, в дебиане по който хер собирают без этого новомодного хттптри. Хотя проверь, может у тебя и так всё рабоатет curl --http3 https://example.com/

p.s хотя щас обновлюсь и попробую, вдруг прокатит. Если что подсоберу что нужно.

Ух, значит ты нашел способ пофиксить проблему вызванную кэширующими серверами компании Google Global Cache (GGC) о которых сообщал «Ростелеком». Отлично.
Теперь ждем заявления «Ростелеком» что компания Google отказывается принимать UDP пакеты с территории России.

Чёйта? Я не понял. Повторюсь, у кого-то всё просто работает, а у меня проблемы из за какой то там железки кеширующией, без неё всё норм, вот и всё. Это как с игровыми серверами, ты ищешь плохие с большим пингом и блокируешь их тебе остаются хорошие, вот и всё. Просто кешиерующие сервера не работаеют кажется с quic из за особенностей http3 и вот. Ну, как я понял. Ничего тут особенного нет, чисто техническая приблуда и всё. И да, об этом не только ростелеком сообщал, а и гугель сообщал, мол у нас проблемы с железками, кому-то будет норм, но те кто эти проблемные железки обслуживают могут страдать, от аниме вместо видео =)

Теперь ждем заявления «Ростелеком» что компания Google отказывается принимать UDP пакеты с территории России.

А не, соединение http3 может начаться с http2, а уже потом в UDP полетит трафик и уже в браузере долбя процессор в сотку будет этот бутерброд распаковываться, http3 это ужас на колёсиках, но тут оно работает просто потому что кешировать шифрованный трафик не получится, а видимо внутренних проксей для http2/http3 у гугла нету, не осилили, даже nginx патчить надо для этого и то. Ой короче, сырая недоделка сейчас работает в пользу только потому что это сырая недоделка.

--external-downloader curl --external-downloader-args '--http3' пробовал — не помогло. Правда я не пересобирал.

Недавно кстати были какие-то странные проблемы с доступом к Steam у ДомРу, там похожий случай был, трафик резался, то проходил нормально, то не проходил. Помогало переключение на udp и правильная настройка mtu. В прошлом месяце эти проблемы пропали.

https://github.com/ValveSoftware/steam-for-linux/issues/10297

Проверил Ютуб, проблем никаких нет, yt-dlp тоже нормально качает.

В том и суть, кого затронуло, а кого и нет. Щас чемоданы соберём всем лором и к тебе домой поедем с компукретами подмышкой, будем у тебя интеренты качать ^.^

Прикол был в том, что это затронуло только пользователей Линукса, а так как тех кто пользуется Линуксом не так уж много, а игроков ещё меньше, то провайдер первое время вообще отнекивался мол обращений слишком мало. В общем люди примерно 3 или 4 месяца без доступа к Steam были.

Гы, как раз жена попросила накачать кучу роликов в хорошем разрешении, а yt-dlp еле тянет… Однако через бесплатный Proton VPN очень даже прилично так подсасывает (до 10 мегабит), хотя и пришлось пару раз переподключиться (падала скорость до 200 килобит).

а yt-dlp еле тянет

Для статистики, а в браузере как?

Ткнул в первый 1080p60 (vp9) — норм. ESR 115.

А у меня и не начинал. Тот самый firefox-esr 115.

Оно походу идёт в обход кеширующих серверов ибо у http3 с этим мягко говоря проблемы

Кеширующие сервера для ускорения вообще-то, и без них должно быть намного медленнее чем с ними.

а yt-dlp еле тянет

И варнинги про nsig extraction failed пишет? Это к тому что на ютубе обновилась js-защита от качалок и надо обновить yt-dlp чтоб он это учёл. Но, возможно, yt-dlp ещё не пофиксили и сначала надо ждать фикса.

кучу роликов

А тут тогда всё просто - качай все одновременно, раз каждый по отдельности тебе канал не забивает.

Если это и правда замедление от РКНа, на которое ты намекаешь, то и правда появляется надежда что государство, в рамках борьбы с обходами интернет-санкций, побочно защитит нас и от этих дурацких http3.

И варнинги про nsig extraction failed пишет? Это к тому что на ютубе обновилась js-защита от качалок и надо обновить yt-dlp чтоб он это учёл. Но, возможно, yt-dlp ещё не пофиксили и сначала надо ждать фикса.

Т.е., тут целая тема нарисовалась https://www.linux.org.ru/forum/talks/17678114. где «лучшие» умы ЛОРа ) бьются над проблемой, а ты взял и раскрыл ‘интригу’?

Откуда мне знать что там за интрига? Лично у меня последние недели (не помню точно сколько) эти варнинги про nsig стали время от времени проскакивать, а пишет их именно анализатор ютубовских js, нужный для обхода именно ютубовских замедлений против качалок.

И варнинги про nsig extraction failed пишет?

Вроде нет.

надо обновить yt-dlp чтоб он это учёл

Всегда самый свежий.

качай все одновременно

Да, как положено, через yt-dlp -a ролики.txt. Хотя, думаю, в следующий раз надо попробовать натолкать в плейлист и качать его.

Кстати, какая-то дурацкая неочевидная тема, что если расширение (.txt) не добавить к файлу, то скачает только первую ссылку.

Не знал про -a. Но судя по описанию он по очереди качает, или нет?

Я имел ввиду параллельно все видео, допустим качаешь 50 видео, каждое 50кбайт/с, итого 25мбит канал утилизируешь.

Кеширующие сервера для ускорения вообще-то, и без них должно быть намного медленнее чем с ними.

Вариантов несколько. Возможно есть несколько типов кеширующих серверов для http1/2 и http3 и проблемы с первыми (пока), для http3 надо отдельный огород городить. Ну и много всего без всяких кеширующих штук работает, потоковое видео со всех концов планеты, просто сайты отдающие видео. Тут, быстрее это не нам, быстрее это гуглу, это ему кеши нужны, а не нам. Но, на деле конечно и нам ибо у них там на это всё завязано.

С учётом что как и в каком виде всё там отдаётся и как и в каком виде по желанию чьей пятки разработчика и/или админа, как работает клиент-серверная модель, я даже вкуривать не собираюсь. Проще говоря, вот так лагает, а вот так не лагает. Что там происходит под капотом и на каком этапе логика сервера решает что и как отдавать, а клиента что и как получать развернуть конечно можно если очень хочется и явно сказать вот тут вот так потому что вот эдак, но смысла заниматься этим нет. Ща виртулкки обработки трафика переподымут с другим наполнением и весь детектив будет на смарку.

P.S

• хороший трафик в хроме у меня идёт из MSK ISP: PJSC MegaFon
• тормозной трафик в фарефоксе у меня идёт из ISP:Google LLC

Мой провайдер не мегафон :) Может рупоры сами подняли кеш сервера?

И там и там HTTPS3

И кажется тут да, хороший и быстрый трафик мне прётся с кеш сервера в Москве, а плохой напрямую от гугла

Хороший трафик

nslookup rr1---sn-hxb54vo-bvwl.googlevideo.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
rr1---sn-hxb54vo-bvwl.googlevideo.com	canonical name = rr1.sn-hxb54vo-bvwl.googlevideo.com.
Name:	rr1.sn-hxb54vo-bvwl.googlevideo.com
Address: 31.173.129.76
Name:	rr1.sn-hxb54vo-bvwl.googlevideo.com
Address: 2a03:d000:2660:2::c

Плохой

nslookup rr18---sn-n8v7znsy.googlevideo.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
rr18---sn-n8v7znsy.googlevideo.com	canonical name = rr18.sn-n8v7znsy.googlevideo.com.
Name:	rr18.sn-n8v7znsy.googlevideo.com
Address: 173.194.182.36
Name:	rr18.sn-n8v7znsy.googlevideo.com
Address: 2a00:1450:4011:56::24

По какому такому принципу два браузера лезут в разные места или двум браузреам разным дозволяют подключаться к разным местам я понятия не имею, где то логика эта прописана, где-то эти CDN выдаются браузеру, рыть лень. А может вообще случайно :D

P.S. Сам HTTP3 ещё разный бывает то какой трафик будет зависит от связки клиент сервер и опций соединения там целый паровозик параметров и некоторые из них могут быть настолько неоптимальны для некоторых случаев что мама не горюй. Может фаерфокс не умеет в параллельные стримы или ещё во что и получается каша вместо нормальной работы, хер его знает. Себе я починил, а там пускай сами чинят :)

Всё :)

Ну вот и выяснилось, лагает там где кеш-сервера нет.

За выбор кеш-сервера отвечает гугл, скорее всего он видит что у тебя неугодный браузер и специально отдаёт плохой источник.

скорее всего он видит что у тебя неугодный браузер и специально отдаёт плохой источник.

Вот он жопшник, гугель этот, атата по попе :D

А тут была тема где выясняли что гугл замедляет ютуб если он открыт в firefox ну как, видео вроде не замедлял (вроде), зато интерфейс тупил или что-то в этом роде. Ну ты видел наверное этот детектив, не так давно было тут обсуждение =)

лагает там где кеш-сервера нет

Ну вот, а то уже на роскомнадзор бочку катили. Типа власти врали, когда говорили, что кеширующее оборудование гугла в России сыпется от старости без ремонта и замены.

Но судя по описанию он по очереди качает, или нет?

Да, по очереди.

Я имел ввиду параллельно все видео

А как это делать?

Остаётся вопрос. Если всё-таки придётся переподключить VPN, то он продолжит закачку (разумеется, в том же каталоге)? По очереди хорошо получается — не надо ничего думать, он просто пропустит уже скачанные (и уже соединённые [video+audio]) файлы.

Ещё к слову вариант, у меня заработало нормально в firefox по f12 открыаваем отладку, видим тормоза и fetc зарос/ответ к videoplayback блокируем этот адрес (правой кнопкой мыши и там видно будет в меню), перезагружаем страницу, если тормозит опять, то снова блочим новый CDN, там уже другой будет и так пока не вуаля, подхватился быстрый гыгыгы =)

Сейчас попробую для yt-dlp сделать блокировку тормозных CDN может оно тоже начнёт подхватывать более быстренькие.

А как это делать?

id=0
while read x; do
  id=`expr $id + 1`
  yt-dlp "$x" >> yt-dlp-$id.log 2>&1 &
done < url-list.txt

например так. Ну или просто открыть 50 терминалов и запустить в каждом чтоб можно было логи нагляднее смотреть.

Насчёт докачки не знаю, можно потестить даже на одном потоке. Может опции какие есть.

А чё, интересная мысль, учитывая, что теперь без впна скорость медленная.

Вопрос. А ютуб отдаёт полную скорость на каждый одновременный запрос с одного айпишника?

что теперь без впна скорость медленная.

ютуб отдаёт специальный m3u плейлист, специально для тебя исходя из того откуда и через что и как ты смотришь и там вшит твой внешний ip и всякая другая твоя инфа. Из него уже по кусочкам генеируется видеопоток который ты сможешь запрашивать и будет он с одного CDN, на уровне браузера если CDN блокировать оно попытается подобрать другой, а вот на уровне yt-dlp оно что взяло то и взяло, никакой динамики, выдрало этот m3u и качает его кусочки склеивая в одно видео, а CDN то там вшит уже.

И нет просто взять и подменить CDN с медленного на быстрый сохранив остальное тело УРЛа не прокатит, оно вообще ничего не отдаст, я только что проверял.

выдрало этот m3u и качает его кусочки склеивая в одно видео

Я указываю в конфиге точную цифру цельного видео-файла mp4 и аудио-файла m4a, зачем что-то склеивать из кусочков?

Типа власти врали, когда говорили, что кеширующее оборудование гугла в России сыпется от старости без ремонта и замены.

Слушай:

1. под раздачу попал не только ютуб, а и некоторые другие видеосервисы. Их-то сервера не связаны с кеш серверами ютуб

2. покажи быстрорастущую нагрузку с ру сегмента на ютубчики. Чтобы доказать то, что кеширующие сервера перестали справляться. А то вдруг это правда местные дропают пакеты на гугл сервера. А сейчас не дропают, а задержку добавляют, чтобы палива не было

Порнхаб тоже тормозить начал (у меня ТТК его блочит, но мне друг рассказал)

Именно за этот видеохостинг я и говорил xD. Да, централизовано провы это безобразие устраивают. О том и речь

Забей, там разница между фрагментированным и цельным файлом по факту очень расплывчатая (зависит как от формата так и от http-клиента), и если ты не занимаешься разработкой видеохостинга то и незачем в эти детали вдаваться.

Качать параллельно несколько фрагментов одного видео я бы не стал, да и yt-dlp это вроде не делает ни при каких обстоятельствах, так что можно считать что файл всегда один (распараллелить его нельзя). Хотя теоретически можно и один (который точно один, например iso качаешь с файлхостинга) файл порезать хоть на 100 частей с помощью http range и качать в 100 потоков.

Качать параллельно несколько фрагментов одного видео я бы не стал

Тут я потерял нить твоего рассуждения.

зачем что-то склеивать из кусочков?

Тебе как клиенту это без разницы. Если 10 часовое видео смотрят в 90% случаев максимум от силы 1% времени то нет никакого смысла держать в кэше многогигабайтный файл и отдавать его потоком, можно хранить самый горячий кусочек поближе к потребителю, а если что так уж и быть докинуть другие кусочки. В любом случае это внутреняя кухня завтра она может поменяться в любую сторону.

В торентах ты тоже качаешь например просто ISO, но никакого ISO нету, есть его кусочки.

Я думал, речь идёт о разных форматах. Там есть, например, live и stream, когда идёт трансляция, то мы смотрим live, а потом вроде бы остаётся стрим, и это основной формат, он каким-то образом фрагментирован для более удобного просмотра онлайн. А есть целые файлы — их менее удобно смотреть онлайн через mpv, они хуже подкачиваются и соответственно прокручиваются. Вот их я и качаю.

dns over quic - это шифрованное соединение. они трафик режут, если видят что он на гугловидео точка ком идет. других предположений нет. скоро по айпи резать начнут, и способ перестанет работать. придется тогда покупать сервак и ставить на нем shadowsocks

и чё ты там в 2024 в .iso качаешь

Никто ничего не режет. Кто они? =)

dns over quic

куик упакован в обычный UDP, ты даже номер пакета не узнаешь. UDP трафика до жопки, никто его не режет. Чёт ты тут выдумываешь. Ну или я тебя не понял.

Я про то что если у тебя 10 разных видео то можно их качать параллельно - 10 потоков. Но если у тебя видео одно, то, несмотря на теоретическую возможность, я б не стал пытаться его параллелить - гугл такое скорее всего быстро палит и пресекает.