Может успеете прочитать до очередного удаления (не знаю в чем такой секрет большой - там наверное читы от нашей симуляции). У меня есть телевизор Самсунг с их нативным смарт ТВ (если честно, не знаю как точно называется эта ОС). Для этого ТВ сам же Самсунг (и только он) выпускает приложение Yutube.
Так вот все, что работает для Smarttube, Chrome, Youtube для Андроид не работает для этого приложения.
После изучения дампов понял, что вероятные отличительные особенности следующие:
Используется TLS 1.2 (кстати некоторые приложения Youtube TV - именно TV - работают вообще с TLS 1.1)
Адреса, на которые обращается приложения совсем другие, а именно
ни на какие youtube.com и известные другие адреса приложения не обращается. Вероятно адреса видео приходят оттуда или вообще оттуда загружаются.
разработчик zapret предлагает мне создавать два инстанса для обхода отдельно блокировки ютубла для самсунга (там нужно mss делать ) и остальных блокировок того же ютуба, но мне жалко оперативной памяти роутера.
пока телевизор стоит мертвый
блокировка на самсунг выглядит как черный экран в приложении Youtube.
я смог пробить пока загрузку картинок и списка видео. Но запуск видео пока не удалось вернуть.
у меня вот на РТ вообще перестал работать yt-dlp --proxy “” --force-ipv4 --downloader curl.exe --downloader-args “-4 --http3-only”
yt_dlp (есть свой проект по скачиванию контента) у меня сразу стал работать после вот этого решения. Параметры обхода теже
я так понимаю ТВ врядли понимает настройки прокси ?
тогда это в раздел Zapret - NTC
там и автор и может быть кто то с таким же провайдером или ТВ
на крайний случай ВПН на роутере помогает почти от всего
p.s. у меня нет особых проблем с ютубом
просто вот взяли и отрубили QUIC (до этого работал уже после начала замедления)
так что нет универсальных решений… провайдер+роутер+пк/тв у всех разные
да. прокси он не поддерживает.
я же вроде писал, что с автором запрета уже общался по этому поводу. просто надо строить отдельное решение именно под самсунг
просто вот взяли и отрубили QUIC
нет. у нас стандартная схема - по SNI рубят соединение либо через RST либо просто ничего не отвечает
QUIC я сразу на уровне роутера заблокировал, чтобы приложения не “бились” по нему
ну то есть с автором вы нашли решение для Самсунг ?
просто я не читал в теме про запрет и уж тем более не видел удаленные сообщения в теме “не для обсуждений”
у меня QUIC работает. если это не ютуб
это все к тому же что НЕТ универсальных решений
мой провайдер РТ например rutracker сам блокирует. а play.google.com забанен на ТСПУ но не у РТ == требуются две стратегии. не работающие вместе как я понял. а есть еще и магистральные …
Ростелеком всегда сильнее зверствовал в отношении ютуба по сравнению с мобильными операторами. У брата на ростелекоме yt-dlp без обхода давно отвалился, с curl и без.
Но вот какие наблюдения есть:
yt-dlp передаёт в curl только прямую ссылку, а первоначальный коннект и получение метаданных делает сам по HTTP2/TCP (который у всех режется ещё сильнее). К сожалению, непонятно на каком этапе у тебя ошибка, yt-dlp даже ссылку не может получить или открывается curl и показывает скорость 0? В принципе, метаданные по HTTP2 весят немного и даже при больших потерях и низкой скорости скачиваются. Лишь бы совсем не отрубили.
Иногда первый коннект curl/http3 залипает и висит на скорости 0. Надо повторить: Ctrl+C (завершение), стрелка вверх (прошлая команда). Возможно даже пару раз. Но обычно одного достаточно. Если и это не поможет, то да, значит QUIC резанули на ростелекоме. На йоте пока пашет. Только периодически соединение рвётся в сборках не с quiche (кстати, в начале всей этой заварушки не рвалось, а потом началось).
нет :). автор просто мне сообщил, как можно начать изучать способы обхода и как развернуть средства обхода
а способы конкретные придется искать самому. Я обязательно выложу, если у меня получится.
вообще интересно как общество смирилось спокойно. людей мало интересует. Вероятно главное что пиво есть в КБ
Интересно, а QUIC никак нельзя вернуть и обойти блокировку? посмотрел, что у меня твориться в локалке: zapret перепосылает постоянно TCP пакеты при передаче видео, т.к. клиенты не успевают подтверждать их.
Т.е. 80% сетевого трафика - перепосылка пакетов в видео потоках