Передача мультикаста через беспроводную сеть что это?
Передача видео Multicast: простые решения сложных проблем
Построение или оптимизация IP-сетей для передачи видеопотоков в формате Multicast могут нередко сопровождаться проблемами. Примеры их решения в первую очередь заинтересуют системных администраторов и специалистов, обслуживающих небольшие корпоративные и ведомственные сети — они ориентированы на быстрое развертывание и минимальные затраты, поскольку основаны на бесплатном ПО
Илья Назаров
Системный инженер
компании «Интелком лайн»
Рассмотрим некоторые конкретные задачи, которые могут возникнуть при работе с IP-сетями.
Обеспечение надежности передачи Multicast
Первая и наиболее распространенная проблема, возникающая при передаче не только видеопотоков, но и вообще любого трафика реального времени, — это вариация задержки и потери пакетов. В случае если причина тому — перегруженность каналов, то, как правило, есть возможность обойти проблему путем расширения пропускной способности или настройки QoS.
На сегодня различные возможности QoS реализованы практически на любом сетевом оборудовании. С принципами их работы и примерами настроек можно ознакомиться в Интернете, поэтому рассматривать их не будем. Сложности возникают, когда даже при обеспечении гарантированной пропускной способности на канале все равно возникают потери пакетов. Такая ситуация типична для каналов последней мили, где потери пакетов происходят вследствие ошибок на физическом уровне. Наиболее актуальной данная проблема является для операторов услуг IPTV, которые не всегда могут обеспечить качественный канал до оборудования абонента Производители решений IPTV решают данную проблему, встраивая возможность повторной отправки потерянного пакета. В общем случае для этого используются специальные серверы, кэширующие видеопотоки, которые устанавливаются на периферийных узлах. Абонентские устройства (set top box) отслеживают состояние потоков и при возникновении потерь пакетов запрашивают повторную передачу этих пакетов у ближайшего сервера. Если поток передается в формате Multicast, повторные пакеты передаются абонентскому устройству в виде Unicast, чтобы не нагружать каналы других пользователей.
В настоящее время ведутся разработки стандартного протокола Pragmatic General Multicast (RFC 3208), который также предназначен для отслеживания потерь пакетов Multicast и повторной их отправки. Некоторые производители сетевого оборудования и операционных систем уже реализуют функционал PGM в своих продуктах.
Передача поверх сетей Unicast
Другая проблема, которая часто случается при построении сетей вещания, — отсутствие поддержки маршрутизации Multicast на некоторых сегментах сети. Такая ситуация может возникнуть, например, если источник и приемник находятся в разных сегментах сети, соединяемых через Интернет или посредством арендованного IP VPN. В подобном случае применяются технологии туннелирования. Для этих целей разработано множество протоколов и стандартов, на особенностях которых не будем заострять внимание, отметим лишь, что туннель может быть маршрутизирующим или коммутирующим. В первом случае маршрутизаторы на концах туннеля должны поддерживать протоколы передачи IP Multicast (PIM), во втором — поток передается прозрачно на уровне кадров Ethernet.
В качестве примера можно привести популярную утилиту OpenVPN с открытым исходным кодом, которая может работать в любом из этих режимов. Режим маршрутизации здесь используется по умолчанию, в этом случае создается виртуальный TUN-интерфейс с присвоенным IP-адресом. Для настройки туннеля в режиме коммутации требуется, во-первых, установить пакет утилит Bridge UtiIs, во-вторых, произвести дополнительные изменения в файле конфигурации. Вместо TUN указываем тип интерфейса ТАР (этот тип используется для прозрачной передачи кадров Ethernet) и указываем сценарии инициализации и отключения туннеля:
dev tap0
up «/etc/openvpn/up.sh»
down «/etc/openvpn/down.sh»
В сценарии инициализации (up.sh) включаем виртуальный интерфейс в режиме прозрачной передачи кадров и присваиваем ему соответствующий идентификатор bridge:
/sbin/ip link set tap0 up promise on
/usr/sbin/brctl addif br0 tap0
В сценарии отключения (down.sh) отвязывается идентификатор и отключается интерфейс:
/usr/sbin/brctl delif br0 tap0
/sbin/ip link set tap0 down
При этом в файле /etc/network/interfaces уже должны быть прописаны настройки интерфейса bridge:
auto br0
iface br0 inet static
bridge_ports eth0
На интерфейсе br0 при этом можно настроить IР-адрес, который будет использоваться для удаленного доступа на сам сервер. Таким образом, туннельный интерфейс и интерфейс локальной сети (eth0) оказываются в одной группе с общим идентификатором br0, и трафик между этими интерфейсами будет передаваться прозрачно, аналогично тому, как это делает обычный коммутатор.
Объединение доменов
Одна из самых сложных задач при использовании IP Multicast возникает, когда требуется объединить несколько существующих изолированно друг от друга сетей в единый домен, где получатели потоков должны иметь возможность принимать потоки как из своей сети, так и из присоединенной сети. Главная неприятность, с которой в этой ситуации могут столкнуться администраторы сети, — это пересечение адресного пространства. Если повторяющихся адресов не так уж и много, то можно просто поменять адреса (если есть такая возможность). Но что делать, если такой возможности нет?
Один из способов решения данной проблемы — использование статического NAT на границе доменов. В этом случае при передаче потока из одного домена в другой адрес потока меняется. Но следует убедиться, что используемое оборудование поддерживает трансляцию адресов Multicast. Используя трансляцию, нужно также настроить статическую подписку IGMP на пограничных интерфейсах, поскольку маршрутная информация между доменами передаваться не будет.
Другой способ — использование технологии SSM (Source Specific Multicast) на базе протокола PIM. В этом случае маршрутизация каждого потока в сети осуществляется не по адресу группы рассылки Multicast (G), а по каждой уникальной паре «источник — группа» (S,G). Таким образом, для потоков, имеющих одинаковые адреса Multicast, но разные IP-адреса источников, создаются отдельные маршруты. При использовании SSM следует озаботиться еще и тем, чтобы приложения, принимающие потоки, также могли различить их по адресам источников. Чтобы приложение могло подписаться на необходимые потоки, нужно, чтобы оно использовало протокол IGMP версии 3.
Использование шлюза
Кардинальным решением при объединении доменов вещания будет использование специального шлюза. Такой вариант, несмотря на дороговизну, обладает наибольшей гибкостью и иногда является единственным способом решить проблему совместимости. Шлюз может не только осуществлять трансляцию адресов, но и полностью преобразовывать потоки на более глубоком уровне. Например, можно, принимая постоянный поток RTP из одного домена, осуществлять его перекодировку (transcoding) на лету и добавить возможность подписки на поток по протоколу RTSP в другом домене. При этом для приема и передачи потоков можно использовать адреса и Multicast, и Unicast, а также их комбинации при дублировании потоков. Решения IPTV и VoD различных производителей, как правило, содержат в себе подобный функционал, чтобы обеспечить совместимость с различными абонентскими устройствами и сетевой инфраструктурой.
Разнообразные варианты работы шлюза рассмотрим на примере еще одной популярной утилиты с открытым исходным кодом — VLC media player. Многие пользуются этой программой как обычным видеопроигрывателем, даже не подозревая, насколько богатым функционалом она обладает. Для настройки VLC в качестве шлюза можно пользоваться как графическим интерфейсом, так и командной строкой. Синтаксис командной строки зависит от используемой ОС и может различаться в зависимости от версии программы. В версии 2.0.0 для Windows строка запуска может выглядеть так (одной строкой):
В качестве первого аргумента программе передается адрес принимаемого потока (это также может быть имя файла или устройства видеозахвата), следующие за ним аргументы — список опций. В данном случае мы подписываемся на поток RTP с адресом 239.1.1.1 и портом UDP 5004, перекодируем его (опция transcode), используя видеокодек MPEG-2 и аудиокодек MPEG Audio, и передаем уже с другим адресом — 239.2.2.2 и портом 1234.
Еще один вариант использования:
Опция duplicate позволяет дублировать потоки, используя разные IP-адреса и UDP-порты. В данном примере мы принимаем тот же поток и передаем его в двух экземплярах: с адресами 239.2.2.2 и 192.168.1.1. Указывая в качестве параметра dst-адреса Unicast, можно также решить проблему с передачей потока через сети, которые не поддерживают маршрутизацию Multicast.
Изучайте протоколы!
Мы рассмотрели далеко не полный список проблем, связанных с передачей IP Multicast. Но в любой ситуации поиск решения не составит труда, если специалист обладает хорошими знаниями принципов работы технологий и протоколов. Поэтому главной рекомендацией будет доскональное изучение стандартов и постоянное совершенствование своих знаний, что позволит избежать большинства проблем или свести к минимуму расходы на их решение.
Источник: Журнал «Системы безопасности» #4, 2012
Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast
Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.
В этой серии статей сосредоточимся на следующем:
Содержание серии статей про мультикаст
- Общее понимание Multicast
- Протокол IGMP
- Протокол PIM
- PIM Dense Mode
- PIM Sparse Mode
- SPT Switchover — переключение RPT-SPT
- DR, Assert, Forwarder
- Автоматический выбор RP
- SSM
- BIDIR PIM
- Мультикаст на канальном уровне
- IGMP Snooping
- MVR
- Дополнительно: Микровыпуск СДСМ. Подготовка лаборатории для работы с мультикаст в GNS3
На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.
В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.
Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.
Уже гораздо позже я пришёл в к следующему правилу:
И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.
Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Общее понимание Multicast
Как известно, существуют следующие типы трафика:
Unicast Одноадресная рассылка — один отправитель, один получатель. (пример: запрос HTTP-странички у WEB-сервера). Broadcast Широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (пример: ARP-запрос). Multicast Многоадресная рассылка — один отправитель, много получателей. (пример: IPTV). Anycast Одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (пример: Anycast DNS).
Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.
Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.
Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.
Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.
Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.
Сформулируем два основных принципа мультикастовой рассылки:
- отправитель посылает только одну копию трафика, независимо от количества получателей;
- трафик получают только те, кто действительно заинтересован в нём.
В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.
Пример 1
Начнём с самого простого случая:
Пример 1
На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.
При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене. Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.
Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?». Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.
Содержимое мультикастового трафика
Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.
Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.
В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.
Зависимость нагрузки на сеть от количества пользователей при передаче юникаст и мультикаст трафика
Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?
Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.
Пример 2
Добавим в схему коммутатор и ещё несколько клиентов:
Пример 2
Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.
В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.
Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).
Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.
| Адрес | Значение |
|---|---|
| 224.0.0.0 | Не используется |
| 224.0.0.1 | Все узлы данного сегмента |
| 224.0.0.2 | Все мультикастовые узлы данного сегмента |
| 224.0.0.4 | Данный адрес выделялся для покойного протокола DVMRP |
| 224.0.0.5 | Все OSPF-маршрутизаторы сегмента |
| 224.0.0.6 | Все DR маршрутизаторы сегмента |
| 224.0.0.9 | Все RIPv2-маршрутизаторы сегмента |
| 224.0.0.10 | Все EIGRP-маршрутизаторы сегмента |
| 224.0.0.13 | Все PIM-маршрутизаторы сегмента |
| 224.0.0.18 | Все VRRP-маршрутизаторы сегмента |
| 224.0.0.19-21 | Все IS-IS-маршрутизаторы сегмента |
| 224.0.0.22 | Все IGMP-маршрутизаторы сегмента (v2 и v3) |
| 224.0.0.102 | Все HSRPv2/GLBP-маршрутизаторы сегмента |
| 224.0.0.107 | PTPv2 — Precision Time Protocol |
| 224.0.0.251 | mDNS |
| 224.0.0.252 | LLMNR |
| 224.0.0.253 | Teredo |
| 224.0.1.1 | NTP |
| 224.0.1.39 | Cisco Auto-RP-Announce |
| 224.0.1.40 | Cisco Auto-RP-Discovery |
| 224.0.1.41 | H.323 Gatekeeper |
| 224.0.1.129-132 | PTPv1/PTPv2 |
| 239.255.255.250 | SSDP |
Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.
Вот, собственно, самые базисные вещи касательно мультикаста.
Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.
Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.
Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.
Использование протоколов PIM и IGMP на участках сети
WI-FI. Multicast.
Опции темы
- Подписаться на эту тему…
Поиск по теме
WI-FI. Multicast.
Знатоки есть, а еще лучше живые примеры доказательства.
Интересует передача мультикаст потока пор вай фаю. А именно.
. одна точка доступа с маршрутизатором и поддержкой мультикаст.
. телек будет рабоать на 2 компах ?
Витя, я ни*** не понял, чего ты понаписал!
фсмысле айпи тиви новотелекомовское по вайфай?
любой D Link дешего и сердито
можно dir300 только прошивку обновить для этого придется, иначе может тормозить
у меня стоит dir 320. по проводу на ПК и два ноута по вафле, на всех все показывает
Знатоки есть, а еще лучше живые примеры доказательства.
Интересует передача мультикаст потока пор вай фаю. А именно.
. одна точка доступа с маршрутизатором и поддержкой мультикаст.
. телек будет рабоать на 2 компах ?
да будет работать на двух компах
разные каналы
какие тебе доказательства нужны?
это работает, по хорошему надо конечно wireless qos настраивать, но для пары компов и без него работает норм
по проводу мультикаст пашет — тут не вопрос а меня интересует передача мультикаста по вафаю — без проводов
для чего?
дома тв смотреть что ли))
ну если денег много то да
нет то и длинк сканает
работает, ты подумай, с чего бы это не работало то, а?
так я и говорю, что по проводу тока один комп, а еще 2 по вафле, и на всех 3 работает
Сань, ну вот например на DLinke 300 со старой прошивкой не работает, точнее работает но через раз.
Пробовал:
Lynksys WRTG54 (в том числе с OpenWRT, в том числе W2)
Cisco 1231 (bridge mode. т.е. 1 комп)
ADSL модем Huawei (модель не помню, но с антенной)
ADSL модем Zyxel HTW660 (вроде так).
лучше всех показал себя Zyxel. Если емУ установить параметр bacon interval (см. google) в 1, то он старался . где-то около 0,5 минут артефактов было минимум. потом он сдался. Вот только битрэйт канала сказать не могу (не помню. 2 года назад это было). Но вроде не меньше 5Мбит/сек.
мой вердикт: у всех не хватает процессора (у всех, кто мог ее показывать загрузка была под 100%) + буферов на большой поток мелких пакетов.
PS на Lynksys WRTG54 можно смотреть телек с небольшими артефактами, если воткнуть кабель во встроенный свитч. Что как бы намекает, что такой поток мультикаста это «дофига» для такого устройства вне зависимости от layer2.
Как организовать домашний кинотеатр с помощью роутера
Содержание
Содержание
Домашние кинотеатры давно уже перестали быть предметом роскоши. Качество, которое лет пять назад могли себе позволить только владельцы дорогих медиацентров, сегодня доступно многим. Сегодня вопрос «быть или не быть домашнему кинотеатру» звучит скорее как «Как и из чего собрать домашний кинотеатр». И если с воспроизведением звука и изображения все более-менее понятно, то с выбором основы домашнего кинотеатра не так просто – вариантов много: медиаплеер, смарт-телевизор, DVD-плеер, AV-ресивер. А мы сделаем домашний кинотеатр с помощью роутера. Для этого может даже не потребоваться никаких вложений – достаточно использовать возможности, уже заложенные в технику.
Роутер для домашнего кинотеатра: плюсы и минусы
Всевозможные носители музыки и видео потихоньку уходят в прошлое, источником медиаконтента все чаще является Интернет — IPTV, Youtube, социальные сети и т. д. Здесь роутеру «все карты в руки». Если у устройства есть USB-порт, то подключенный жесткий диск вполне может превратить роутер в полноценную медиатеку. С помощью DLNA медиаконтент с диска будет доступен на всех устройствах, поддерживающих эту технологию. И для всего этого не требуется приобретение каких-то устройств — роутер сегодня есть практически в каждой квартире.
Однако, минусы у такого решения тоже есть:
- Роутер предоставляет лишь сетевой доступ, он не раздает данные по общепринятым аудио- и видео- стандартам. Поэтому все устройства, желающие получить данные от такого головного устройства, должны быть «умными» — подключаться к сети (Wi-Fi или Ethernet) и иметь какую-нибудь операционную систему с браузером, плеером, набором кодеков, файл-менеджером и т. д. И крайне желательно, чтобы была возможность обновить все это «добро», а производитель оперативно реагировал на изменения кодеков и стандартов, выкладывая соответствующие обновления. Для телевизоров этот момент не столь принципиален — «умных» из них сегодня три из четырех. А вот у проекторов могут возникнуть проблемы с доступом к медиатеке, и тогда потребуется приобретение смарт-приставки.
- Возможна потеря качества сигнала при передаче. Во-первых, сигнал может просто «потеряться» из-за загруженности Wi-Fi или недостаточной пропускной способности сети. Иногда это можно решить приоритезацией трафика или переходом на диапазон 5 ГГц вместо 2,4. В крайнем случае можно подключить устройство кабелем RJ-45 (если у него есть соответствующий разъем). А вот вторая причина может оказаться более проблемной: если ваша аудиосистема не «умная» и звук на нее идет, допустим, через «умный» телевизор, то на качество звука может влиять аудиовыход. Большинство телевизоров способно «отдавать» звук только через стандарт S/PDIF (в лучшем случае), который не поддерживает передачу несжатого многоканального звука. Проще говоря, аудиофилам такой домашний кинотеатр наверняка не понравится.
- Настройки роутера недостаточно для просмотра IPTV на телевизоре — потребуется еще приобретение IPTV-приставки.
Пример организации домашнего кинотеатра на роутере
Роутер должен иметь порты USB и поддерживать подключение внешних жестких дисков. Некоторые старые роутеры не поддерживают жесткие диски объемом более 1 ТБ — если это ваш случай, обновите прошивку.
IPTV-приставку лучше использовать ту, которую порекомендует провайдер — ее будет проще настроить. Кроме того, некоторые провайдеры ставят специально изготовленные для них приставки с нестандартной прошивкой, и использование сторонних может привести к ошибкам.
Смарт-приставку (медиаплеер) для проектора следует подбирать по параметрам — она должна уметь подключаться к локальной сети через Wi-Fi или Ethernet, иметь раздельный выход аудио- и видеосигнала и пульт ДУ. Желательны также поддержка DLNA и полноценный выход в Интернет, что есть далеко не во всех приставках.
Ну и разумеется, домашний кинотеатер невозможно представить без качественной аудиосистемы. В данной конфигурации необходимо, чтобы среди входов аудиосистемы был соответствующий выходу телевизора (чаще всего это S/PDIF).
Настройка IPTV на роутере
Еще несколько лет назад эта задача представляла собой натуральные танцы с бубном и покорялась только опытнейшим шаманам. Но с тех пор на роутерах сменилась не одна прошивка и сегодня для возможности просмотра IPTV-каналов зачастую достаточно разрешить мультикаст (многоадресную маршрутизацию) в настройках роутера.
Еще имеет смысл поискать в настройках «IGMP-proxy» (есть не во всех роутерах и не во всех прошивках) и включить его, если нашелся.
Иногда может понадобиться явно указать, к какому порту роутера подключен IPTV-модуль. В этих случаях следует найти пункт меню «Подключение мультимедиа устройств», «IPTV» и выбрать там используемый порт.
Чуточку сложнее, если провайдер выдает для IP-телевидения тегированную виртуальную сеть (VLAN). В этом случае, кроме указания порта, к которому подключен IPTV-приемник, надо будет еще задать параметры VLAN ID, полученные от провайдера. Для некоторых роутеров (например, D-link) потребуется создать VLAN c заданным ID и проассоциировать его с нужным портом:
Как видите, ничего сложного. Еще потребуется настроить приставку IPTV, но это в большинстве случаев также не вызывает затруднений. Обычно достаточно указать способ подключения (Ethernet/Wi-Fi) и задать автоматическое получение IP-адреса (Автоматический с DHCP). А чаще всего эти параметры уже стоят по умолчанию, и для работы IPTV-приставки ее достаточно просто подключить к роутеру и включить в сеть.
Приоритезация трафика на роутере — настройка QoS
К Wi-Fi сегодня что только не подключено: компьютеры, бытовая техника, смартфоны и планшеты. Неудивительно, что скорость подключения порой начинает «проседать», даже если ваш роутер — единственный на ближайшие 100 метров. Но одно дело падение скорости при фоновом скачивании большого файла, и совсем другое – оно же, но при просмотре фильма. Вполне логично возникает желание распределить нагрузку на сеть между разными потребителями, и это вполне можно сделать с помощью технологии QoS (Quality of Service — Качество обслуживания).
Настроить QoS на роутере несложно. Для этого службу надо включить, а потом настроить правила для каждого из видов интернет-активности:
Не следует путать QoS с контролем пропускной способности. В последнем случае роутер ограничивает пропускную способность для некоторых клиентов четко заданным числом. И даже если канал совершенно свободен, клиент не сможет скачивать на скорости, большей, чем заданная. А QoS оперирует приоритетами: если клиент имеет низкий приоритет, но канал при этом пуст, он будет подключен на максимальной скорости, которая упадет, как только подключится клиент с большим приоритетом.
Увы, поддержка QoS есть не во всех роутерах. Кроме того, QoS не поможет, если причина падения скорости — не одновременное подключение к роутеру множества устройств, а загруженность диапазона другими Wi-Fi сетями. В этом случае скорее поможет смена диапазона (если роутер двухдиапазонный, и у клиента есть поддержка 5 ГГц) либо подключение клиента кабелем RJ-45.
Настройка DLNA на роутере
DLNA (Digital Living Network Alliance — Сетевой Альянс Цифровой жизни) — технология, упрощающая доступ к медиафайлам для всех устройств в сети, поддерживающих DLNA. Она сходна с представлением общего доступа к определенным папкам, однако намного проще в настройке, поэтому с ней не возникает проблем, связанных с правами пользователей.
Настройка DLNA также весьма проста: достаточно подключить жесткий диск к порту USB и включить в настройках «DLNA-сервер» или «Медиа-сервер» и задать имя сервера, под которым он будет виден на других устройствах. Также можно выбрать доступ ко всему устройству или только к отдельным папкам.
Теперь на смарт-телевизоре среди прочих источников должен появиться DLNA-сервер с заданным именем.
Возможно, то, что получилось в результате описанных настроек, и не дотягивает до полноценных домашних кинотеатров, собранных на основе дорогих AV-ресиверов и Hi-Fi аудиосистем. Но для того, чтобы ознакомиться с популярными видеороликами, посмотреть свежевышедшую серию популярного Интернет-сериала или поностальгировать на любимый фильм из своей медиатеки – этого вполне достаточно. А главное – для этого, вполне возможно, даже не придется ничего покупать – достаточно правильно соединить и настроить уже имеющуюся технику.
Настройка Multicast в системах видеонаблюдения
Настройка Multicast в системах видеонаблюдения
Мультикаст (multicast) – технология передачи данных, позволяющая доставить одни и те же данные большому числу пользователей, не перегружая при этом источник данных и сеть.
При использовании multicast в системе видеонаблюдения камера или видеосервер отправляет в сеть один единственный поток данных, который затем дублируется маршрутизатором или коммутатором с функцией маршрутизации мультикаст-трафика.
Поток может приниматься практически неограниченным количеством пользователей. Например, поток с видеосервера может приниматься на десятках рабочих мест операторов видеонаблюдения, не нагружая при этом ни видеосервер, ни сетевой порт видеосервера.
Для применения технологии multicast необходимо выполнение следующих условий:
- реализация передачи multicast-трафика в видеокамерах либо в ПО видеонаблюдения на серверах;
- использование управляемых коммутаторов либо маршрутизаторов, с функцией маршрутизации мультикаст-трафика (IGMP snooping);
- настройка источников (камер, серверов), приемников (УРМ) и коммутаторов/маршрутизаторов.
Преимуществами мультикаста являются:
- сравнительно небольшие требования к пропускной способности линии связи, идущей от источника трафика;
- возможность подключения большого количества получателей трафика (десятки, сотни и даже тысячи);
- стабильная работа источника трафика, т.к. подключение/отключение получателей никак не сказывается на работе источника.
Главным же недостатком мультикаста , применительно к видеонаблюдению, является отсутствие преимуществ перед традиционным юникаст. Вызвано это тем, что у IP-камеры один получатель данных – видеосервер, а у видеосервера, по понятным причинам, небольшое количество получателей видео даже если еть центральный пост, к тому же, как правило, на каждом мониторе отображается разный набор камер.
Также мультикаст не пригоден для работы с архивами видеосервера с удаленных рабочих мест. При просмотре архива подразумевается выборочное воспроизведение записей на разных рабочих местах. Это, в свою очередь, вынуждает использовать «традиционный» Unicast и, соответственно, увеличивать трафик сети.
Но если вы все же хотите использовать в своей системе мультикаст, нужно его включить. Однако перед включением обязательно проверьте, что сСетевое оборудование не блокирует мультикаст трафик, а в настройках вашего VLC плеера нет флажка RTP поверх RTSP (TCP).
Для разного оборудования для видеонаблюдения мультикаст включается по разному. Приведем несколько примеров.
Dahua
Адрес UDP по умолчанию — 224.1.2.3, диапазон изменения — 224.X.X.X.to 239.X.X.X
OMNY PRO
Включение мультикаст выполняется в WEB интерфейсе.
Заходим Configuration—Advance Set—Access Platform—PU SetRegister Server> вводим адреса между 224—239 сегментом, например, 224.168.1.100, указываем порт 10102.
Сохраняем, устройство перезагружается. Открываем VLC плеер для проверки (Media /открыть URL/сеть) и вводим строку запроса udp://@224.168.1.100:10102 (соответствующий адрес и порт).
Новые модели имеют другое расположение настроек мультикаст:
Configuration>>network management>>Network Service>>MUC
OMNY Base
Включение мультикаст выполняется в WEB интерфейсе. Путь Settings/Network/RTSP — Multicast Settings / Enable Multicast, затем вводим адреса между 224—239 сегментом, например, 224.1.2.3, указываем порт 10000 и сохраняем.
Открываем VLC плеер для проверки (Медиа/открыть URL/сеть) и вводим строку запроса как RTSP.
Убедитесь, что в настройках вашего VLC плеера нет флажка RTP поверх RTSP (TCP).
Вот, пожалуй, и все. Мы же напоминаем, что наша компания «Запишем всё» с 2010 года занимается проектированием, монтажом, обслуживанием и ремонтом систем видеонаблюдения и видеодомофонов в Москве и Подмосковье.
Мы работаем быстро, качественно и по доступным ценам. Перечень услуг и цены на их вы можете посмотреть здесь.
Звоните +7 (499) 390-28-45 с 8-00 до 22-00 в любой день недели, в том числе и в выходные. Мы будем рады Вам помочь!
