чем открыть поток udp
Чем открыть поток udp
Новые темы необходимо создавать только в корневом разделе! В дальнейшем они будут обработаны модераторами.
Если Вы выложили новую версию программы, пожалуйста, сообщите об этом модератору нажав на вашем сообщении кнопку «Жалоба».
Последнее обновление программы в шапке: 20.10.2021
Краткое описание:
Просмотр IP-телевидения на Android.
Смотрите IPTV Вашего интернет-провайдера или телевидение из любого другого интернет-источника на телефоне или планшете!
Обсуждение и выкладывание плейлистов на 4PDA запрещены.
В теме присутствует разработчик alders Варез запрещен!
В списке приведены устройства со стандартными заводскими прошивками, в случае кастомных прошивок поведение может отличаться.
Почему на одном телефоне/планшете работает без прокси, а на другом нет?
К сожалению, многие Андроид-устройства не могут принимать мультикаст, это ограничение прошивки, и ничего с этим поделать нельзя. Используйте прокси или ищите альтернативную прошивку с поддержкой мультикаста.
Вчера все работало, сегодня нет, почему? Прошивка не менялась.
Если вы используете открытый плейлист с форумов, то это обычное явление, т.к. открытые плейлисты очень часто банятся провайдерами при увеличении нагрузки на сервер. Если вы смотрите телевидение от интернет-провайдера через UDP-прокси, то убедитесь, что прокси запущен и работает, и IP-адрес компьютера с прокси не изменился. Также, вполне возможно, что проблемы на стороне провайдера, для проверки откройте этот же плейлист на компьютере при помощи IP-TV Player для Windows.
Программа работает везде где есть Wi-Fi или только в локальной сети конкретного провайдера?
Зависит от плейлиста. С плейлистами интернет-провайдеров скорее всего будет работать только в локальной сети провайдера. С открытыми плейлистами, с плейлистами сервисов типа Батон-ТВ и т.д. работать будет везде, где есть Wi-Fi. С некоторыми плейлистами возможна работа даже по 3G.
Требуется Android: 4.0+
IP-TV и UDP Proxy, UDP-to-HTTP
И начнём мы с роутеров, так как в первую очередь организация домашней сети начинается именно с них и именно от их возможностей зависит, сможете вы смотреть IPTV вашего провайдера, или нет.
Поддержка UDP Proxy имеется в таких моделях роутеров как ASUS, Zyxel Keenetic, Mikrotik, Eltex и др. Также Udpxy — Linux-прокси существует как отдельный компонент, доступный для загрузки и установки на альтернативные прошивки маршрутизаторов: OpenWRT, DD-WRT, Gargoyle и прочих им подобных. Можно попробовать найти и установить такую прошивку, подходящую для модели и аппаратной версии вашего роутера, и произвести необходимые настройки.
Настройка Proxy на Wi-Fi роутере (маршрутизаторе)
Пример настройки HTTP-прокси на маршрутизаторе Eltex WB-2
Пример настройки UDPXY на роутере D-Link DIR-615
Пример настройки UDPXY на роутере SNR-CPE-W4N
Пример настройки UDP-прокси на интернет-центре Keenetic Ultra
После всех соответствующих настроек интернет-центра нужно указать (прописать) вручную IP-адрес и номер порта в настройках ваших устройств (виджетов, приложений, или программ), через которые вы хотите смотреть IPTV посредством прокси-сервера домашнего роутера. Если все данные указаны и введены вами верно, то телеканалы будут доступны для просмотра уже не по протоколу UDP, а по TCP.
Настройка Proxy на компьютере (прокси-сервер в домашней локальной сети)
Если ваш роутер поддерживает приём и передачу мультикастового трафика IPTV (например TP-Link, или D-Link с официальной заводской прошивкой), но в нём нет настроек UDP Proxy, то в качестве прокси-сервера можно использовать небольшую утилиту, установленную на один из персональных компьютеров, подключенных к этому Wi-Fi роутеру, то есть к малой локальной сети. При этом не важно какое подключение используется — проводное, или беспроводное.
Для этого нужно скачать специальную утилиту: UDP-to-HTTP Proxy для компьютеров под управлением ОС Windows.
Запускаем UDP-to-HTTP Proxy.exe и переходим к настройкам:
Далее указываем вручную IP-адрес и номер порта (в нашем конкретном случае это — 192.168.1.2:1234 ) в настройках ваших устройств, виджетов, приложений, или программ, через которые вы желаете смотреть IP-телевидение, используя прокси-сервер на компьютере. Если данные указаны и введены верно, то начнётся воспроизведение телеканалов.
Примечание: Иногда в некоторых приложениях, как например, в настройках виджета OTT-Player для Smart TV, нужно указывать IP-адрес и номер порта следующим образом: http://192.168.1.1:1234
Очень большим плюсом использования UDP Proxy в небольшой домашней сети как на Wi-Fi роутерах, так и на компьютерах является надёжность доставки пакетов трафика IPTV по Wi-Fi и возможность воспроизведения его практически на любых устройствах, а также значительно стабильнее транслируются телеканалы в HD качестве — без подвисаний и различных визуальных, звуковых артефактов.
Помочь в выборе подходящего Wi-Fi маршрутизатора вам помогут статьи на нашем сайте:
Строим IPTV/OTT сервис: защита контента
В этой статье я хочу рассказать, как защищают видео контент, какие технологии для этого применяют. Речь пойдет в основном про интернет вещание, но придется затронуть и про DVB, и про Multicast, чтобы было понятнее, в чем разница.
Stalker Middleware, которую мы установили в прошлой статье, имеет интеграцию с нашей системой защиты контента, а так же с NGINX X-accel и Secure Link.
Статья рассчитана не только для профессионалов, но и для тех, кто еще ничего не знает про IPTV/OTT.
Есть два подхода к вещанию видео контента:
Broadcast
Наша компания работает с вещанием видео через интернет, поэтому тут кратко, просто чтобы было понятнее, в чем разница между скрэмблированием видео на источнике и управляемоей раздачи видео.
Multicast у меня в Broadcast попал, потому что, во-первых, это форма широкого вещания, во-вторых, я говорю не только про передачу пакетов в IP-сетях, но и затрагиваю DVB.
При Broadcast вещании нет обратной связи между источником и клиентом, поэтому есть только один способ защитить контент — заскрэмблировать все на источнике. Чтобы клиент смог посмотреть защищенный контент, ему нужно узнать ключ, который периодически меняется. Ключи рассылаются клиентам вместе с контентом таким образом, что только получатель может его расшифровать. Как правило, для этого используют модули условного доступа (CAM-модули), а такая система называется — система условного доступа.
С таким способом защиты контента встречались практически все, кто пользуется услугами платного ТВ. Спутниковые вещатели уже много лет используют такой способ защиты, вынуждая периодически менять карты доступа и/или CAM-модули (или даже приемники, если CAM-модуль встроенный).
Главный недостаток таких систем в том, что ключами можно делится (Кардшаринг). Без обратной связи, нельзя проверить подлинность карты или модуля, да и узнать о существовании и количестве злоумышленников технически невозможно.
В IPTV сетях вместо CAM-модулей используется специальный софт, он общается с CAS-сервером и получает ключи. Такой подход практически исключает кражу контента, т.к. общение с CAS-сервером происходит по защищенному Unicast-соединению, а у приемника нету карты или модуля, который можно обмануть или подделать. Управляемое сетевое оборудование позволяет ограничить количество каналов, просматриваемых одновременно (как правило, операторы разрешают просмотр 2-6 каналов одновременно), поэтому весь контент проблематично, как это делают при спутниковом/кабельном вещании.
Говорить тут особо не о чем. Технология принципиально не меняется уже много лет. Старые системы взламывают, появляются новые. Недостатки есть, но в целом система работает.
Unicast
При Unicast вещании можно использовать Broadcast подход: скрэмблируем поток на источнике, а ключи раздаем через интернет. В таком случае, все то же самое, что и у IPTV, только вещаем не мультикастом, а по HTTP.
А можно по-другому ограничить доступ к контенту: использовать уникальные для каждого пользователя токены. Идея заключается в том, что Middleware отдает каждому пользователю уникальные ссылки для просмотра, а видеосервер проверяет эти токены через Middleware API.
Такая схема требует меньше серверов и софта, что дает хорошую экономию и на старте, и во время эксплуатации. Сам контент не шифруется, но получить доступ к нему не получится без разрешения от Middleware. Портал выдает одноразовые ссылки, перехват которых не имеет значения — открыть ссылку сможет только то устройство, которое запросило ссылку. А от банального перехвата трафика спасает HTTPS.
«Но ведь контент остается открытым, ничто не мешает его сохранить на диск или ретранслировать другим пользователям.» — скажете вы.
Да, конечный пользователь может сохранять сегменты к себе на диск и даже организовать трансляцию другим пользователям. Но, у одноразовых ссылок есть срок жизни. Настроить и забыть не получится. Придется регулярно получать новые ссылки от Middleware. Да и в статистике будет видно, что пользователь 24/7 смотрит один и тот же канал. Подозрительно.
Так как раздача контента по HTTP процесс контролируемый, значит мы можем отслеживать количество одновременных соединений. А это значит, что два канала уже не получится смотреть одновременно (если, конечно, не позволяет тарифный план).
Чтобы ретранслировать весь ваш контент, придется зарегистрировать количество учетных записей, равное количеству телеканалов и настроить ботов, которые будут получать актуальные временные ссылки эмулируя работу приставки. Тут придется проявить фантазию, иначе по логам можно будет легко вычислить таких пользователей. Вот представьте, из одного датацентра (/24 сети) появилось 100 пользователей, которые 24/7 смотрят одни и те же каналы. Придется такой ботнет раскидать по разным датацентрам и настроить какую-нибудь систему ротации каналов между учетными записями, чтобы не было подозрительно. Можно обсудить в комментариях, как стырить контент и остаться незамеченными.
«Но ведь телеканалы не позволяют транслировать их в кабельных/локальных/интернет сетях без шифрования сертифицированной CAS-системой.» — добавьте вы.
Не будем в рамках этот статьи разбираться с юридическими нюансами. У разных телеканалов разные требования, бывают каналы, позволяющие открытую трансляцию, кроме телеканалов наши клиенты вещают видео с камер наблюдения, которое тоже нужно защищать от чужих глаз.
Система авторизации может применяться для передачи видео между серверами, датацентрами если вы агрегатор контента, а не вещаете напрямую клиентам.
Многие клиенты приходят к нам именно ради системы авторизации.
Ладно, хватит теории, давайте займемся практикой.
Stalker имеет несколько встроенных механизмов для защиты видео. Они имеют ряд ограничений: не совместимы с некоторым протоколами (например, RTSP), не могут полноценно защищать HLS потоки и не учитывают одновременные подключения. Зато не требуют специализированного видеосервера.
Если в настройка телеканала включить временные ссылки, но не установить галочку напротив «NGINX secure link» или «Flussonic support», то Stalker будет использовать X-Accel-Redirect для доступа к контенту.
Данная конфигурация подходит для защиты HTTP MPEG-TS потоков, т.к. между сервером и клиентом устанавливается только одно TCP соединение. Посмотрим, как выглядит конфигурация NGINX:
Stalker генерирует ссылку вида: stalker/ch/TOKEN123, где TOKEN123 — уникальный, одноразовый пароль. Когда клиент открывает эту ссылку, NGINX делает rewrite на файл chk_tmp_tv_link.php, который проверяет валидность токена и возвращает ссылку на поток с помощью заголовка X-Accel-Redirect.
Исходный код файла chk_tmp_tv_link.php:
Согласно документации, для использования временных ссылок, необходимо задавать URL канала в формате: 192.168.1.1:8888/127.0.0.1:8899/udp/239.1.1.1:1234, где 192.168.1.1:8888 — это сервер udpxy, с установленным NGINX.
Как мы знаем из конфигурации NGINX, /get/ — это internal location, что означает, что доступ сюда можно получить только через X-Accel-Redirect заголовок, полученный от бэкенда.
Далее, с помощью нехитрого регулярного выражения, NGINX начинает проксировать (proxy_pass) на локальную (или удаленную) udpxy.
Как видите, защита контента от несанкционированного доступа — это просто. Один rewrite, один location с параметром internal и небольшой бэкенд скрипт — все это доступно «из коробки» и отлично работает. Подробнее о работает X-Accel вы можете почитать в официальной документации NGINX.
NGINX Secure links в Stalker
Теперь поставим галочку «NGINX secure link»
Stalker защищает доступ к HTTP MPEG-TS потокам и ссылки на m3u8 плейлисты. Сами же чанки и медиа плейлисты остаются незащищенными и с помощью tcpdump/wireshark можно легко узнать адреса медиа плейлистов и подключаться к ним напрямую.
Самый простой и, главное, более надежный способ защитить потоки — включить интеграцию с Flussonic. Настройка со стороны Сталкера не требуется, стоит лишь поставить галочку «Flussonic» в настройках канала, а со стороны Flussonic требуется лишь указать адрес Сталкера.
Flussonic — это видеосервер нашей разработки, широко применяющийся во многих OTT и IPTV сервисах. Наши сильные стороны — это управление доступом и учет сессий, запись архива. Подробнее у нас на сайте.
У нас реализован механизм идентификации пользователей и отслеживания подключений с помощью авторизационных бэкендов. По протоколам HLS и HDS используются HTTP механизмы отслеживания сессий, а по протоколам RTMP, RTSP и MPEG-TS обрабатываются постоянные TCP сессии. Также отслеживается экспорт архива в формате MPEG-TS и MP4.
Stalker — это и есть авторизационный бэкенд. Когда клиент приходит за видео, мы передаем бэкенду не только IP-адрес и имя канала, но и другую важную информацию:
— Token
— HTTP Referer
— Количество открытых сессий на этом потоке
— Общее количество открытых сессий на сервере
— Запрашиваемый протокол: (hls, dash, hds, rtmp, rtsp, mpegts или mp4)
— Тип подключения (новое соединение или продлевается текущее)
— Тип запрашиваемого контента (живой поток, архив, скриншоты или обращение к API)
— User-Agent
— query string
— Адрес и порт сервера, куда пришел запрос
Эта информация позволяет бэкенду гибко контролировать доступ. Можно использовать все данные, чтобы строить сложные правила.
В ответ, Сталкер возвращает не просто да/нет, но и информацию о сроке действия разрешения (или запрета), id пользователя и количество одновременных соединений для этого пользователя.
Flussonic сохраняет ответ и на время действия разрешения не посылает повторных запросов в бэкенд. Так как статья получается итак затянутой, я не буду показывать как настроить авторизацию во Flussonic через Stalker, это очень просто и у нас есть краткая, но исчерпывающая документация по этому вопросу.
Подводим итоги.
В большинстве случаев для защиты контента от несанционнированого просмотра в интернете можно обойтись без шифрования, делается это легко бесплатными средствами популярной Middleware, а можно и настроить интеграцию с видеосервером, убрав со Stalker лишнюю роль и нагрузку.
Расскажите в комментариях, какими средствами защиты контента вы пользуетесь? Интересно не только про ТВ-вещание, но и VOD-сервисы, видеонаблюдение.
Судя по количеству просмотров первой статьи цикла «Строим OTT/IPTV сервис», еще не все построили свои решения и мне не стоит затягивать со следующими статьями.
Дальше надо бы поговорить про вставку видео на сайт, этот вопрос не такой простой, как может показаться. Прочитайте нашу статью «Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)», она рассказывает о современных средствах передачи и просмотра потокового видео в браузере. А еще мы запустили бесплатный сервис сбора статистики для всех наших клиентов.
Вещание udp-потока (IPTV) на заданые адреса
Внутренняя подсеть, в которой есть udp-поток. Есть машинка, которая имеет доступ к этой подсети и имеет белый айпишник. Необходимо, чтобы этот поток «выбрасывался» из этой подсети в мир, причем чтобы его могли «видеть» только 2 машины (находятся в других городах).
Вопрос чтобы «только 2» я решу с помощью iptables, а вот как сделать захват и вещание? Подойдет любое решение _кроме_ VLC.
port forwarding же, не?
Вопрос чтобы «только 2» я решу с помощью iptables,
Вот тут бабушка надвое сказала, если мутикаст.
Реальное решение udpproxy. Там и iptables поможет.
я так понял что можно в принципе юникастом, а на месте провайдер разберется. так же можно? или не?
Какой мультикаст через интернет по чужим неконтролируемым сетям?
Я так понимаю оно хавает поток и преобразует его в http? Вопрос в том, что смогут ли на другом конце его преобразовать в udp и запустить мультикастом?
Теоретически да. Черезе ffmpeg. Но могут быть грабли, поэтому возможно придется ретранслировать в мультикаст через «любимый» vlc
Мде. Все равно вариант с udpxy отпал, т.к. на выходе нужен именно udp поток. Щас ковыряюсь с VLC.
Вот так у меня запускалась трансляция.
Попробуйте на основе этого заваять что-то своё.
Еще из разряда извращений. Может попробовать поднять open-vpn bridge?
Спасибо за скрипт. На счет бриджа я посмотрю что можно сделать, но это маловероятно, ввиду особенности местной сети и некоторого оборудования:)
оно хавает поток и преобразует его в http?
смогут ли на другом конце его преобразовать в udp и запустить мультикастом?
Потоки сформированные устройствами TELEVIEW могут приниматься на один из самых распространенный медиаплееров в сети — «VLC media player» Для этого необходимо выполнить следующие действия:
Убедитесь, что в качестве IP адреса назначения в устройстве TELEVIEW указан адрес компьютера с установленным VLC или компьютер с VLC находится в зоне доступа к мультикаст потоку формируемому устройством TELEVIEW.
Так, например, если IP компьютера 192.168.0.10, то в штатной программе управления устройствами TELEVIEW – “DVCrypt” при настройке IP выхода тестируемого устройства, в поле IP вводим «192.168.0.10» затем выбираем нужный порт и протокол (Полную процедуру настройки IP входов и выходов устройств можно посмотреть здесь )
Запускаем плеер и в меню «Медиа» выбираем «Открыть URL»
В закладке «Сеть» в поле «Введите сетевой адрес» вводим строку в формате «протокол://@:порт», где протокол и порт, это протокол и порт выбранные при настройке IP выхода тестируемого устройства TELEVIEW. Т.е. для нашего примера это будет выглядеть как «udp://@1234»
Если при настройке устройства TELEVIEW был бы выбран протокол RTP или RTP+, то строка в поле URL должна была бы выглядеть как «rtp://@1234»