[Tosha]

А зачем им тянуть мультикаст?

В смысле что это востребовано практически ни у кого, а тестить это приходится ну и суппортить как то тоже.

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

Гораздо проще взять готовое - а там мультикаст скорее всего есть. Да хоть linux ядро вкорячить, хоть freebsd...

 

То что в новых LG его нет говорит о том, что там собрана какая-то хреновина. С которой они будут иметь много проблем в поддержке. И не факт что там стабильно будут работать mpeg2ts @ HTTP @ tcp.

[Ivan_83]

Вот если бы ты ядро линуха собирал то знал бы что там мультикаст можно выключить и после этого никакого IGMP в ядре не будет как и прочих мелочей связанных с этим.

Некоторые андроды так собраны.

Естественно лыжа собирает на линухе, я бы оч удивился будь оно не так.

Но даже если у них своя ОС, сути это не меняет: мало иметь поддержку мультикаста в ядре, нужно ещё софт научить а потом оттестировать.

 

Насчёт mpeg2ts @ HTTP @ tcp я пожалуй немного загнул, там просто media @ HTTP @ tcp которая попадает на вход чего то типа гстримера/ффмпега, который уже это всё стрипает и отдаёт декодерам/сам декодирует потоки.

И это практически единый и основной функционал который идёт сразу после DVB и который вылизывают ибо это и DLNA и смартхрень из инета.

[DRiVen]

Те ты представь мировой рынок лыж, потом российский, потом тот сегмент потребителей которых это волнует и которые это осознают. Получится 0,000001%. Те переводя на русский это нахер никому не нужно.

Э... то есть категория "нахер никому не нужно" это кто-то типа вас, знающий весь спектр достоинств и недостатков? Я вообще про "народные массы" говорил, которых 80%, которые основной потребитель и которые "тиливизер хочут" "шоб программы все и интересные", а не вещание юникастом, OTT и VOD.

Те кто раздаёт мультикастом пусть отдаёт услугу через HDMI - те лепит свою "приставку" со всеми вытекающими.

Это так и есть, только лепят не сами, а разработчик платформы вещания. Или вы про CEC?

[Ivan_83]

Я вообще про "народные массы" говорил, которых 80%, которые основной потребитель и которые "тиливизер хочут" "шоб программы все и интересные", а не вещание юникастом, OTT и VOD.

Так вот, если у телека есть эзернет порт то производитель обязательно туда запихает DLNA клиента и сертифицирует и шильдик наклеит ибо это мастхэв в наше время, практически как DVB когда есть куда антенну подключить.

Дальше юзер может купить себе NAS накидать туда фильмов и всё будет как то показывать скорее всего, само.

Ради этого всё и затевалось.

 

Это так и есть, только лепят не сами, а разработчик платформы вещания. Или вы про CEC?

Нет, я про то что если ты вещаешь мультикастом то тебе придётся зону ответственности увеличить и отдавать ТВ юзеру через HDMI, те самому настраивать роутер, самому настраивать приставку.

СЕС тут почти не причём, просто приятное удобство.

[Tosha]

нужно ещё софт научить а потом оттестировать.

я полагаю что софт под IPTV пишут для смарта собственно сами вещатели контента. Производители телеков вообще этим не занимаются.

[Ivan_83]

Те ты думаешь что что они там на жабе корябают плеер который умеет мультикаст?

Так вот, НЕТ!

Как минимум в самсунге джава+хтпл. Доступ к сети весьма ограничен.

Внутри своё АПИ для плеера, ты ему урл и какие то параметры и он его играет.

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

[Butch3r]

Самсунг телеки без проблем понимают мультикаст. Вот только на дешевых моделях 1080p подсыпает на динамичных сценах.

Но вот как там реализована обработка мультикаста я не знаю.

[Ivan_83]

Пока поддерживают.

Подсыпает скорее всего потому что дефолтный размер буфера плеера так себе либо что то ещё не докрутили в сисцтл/настройках сетевухи.

Там включена поддержка в ядре мультикаста и в ихней либе/плеере парсер понимает udp:// и умеет ждоин/лив при старте/стопе воспроизведения, работа при воспроизведении практически та же сама что и в обычном хттп: читаем из сокета и перекладываем в буфер плеера.

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

[morfair]

после долгих раздумий решил вещать юникастом

А после подключения тестовой пачки юзеров загрустил от нагрузки на аплинки... Курю мультикаст и ограничение доступа к оному. Вопросов как всегда больше чем ответов. Настроил MVR на центральном свитче. А как тащить дальше? Так же MVR везде настраивать? А как быть со свитчами типа DES-2108, которые так не умеют?

 

Не придумали как защитить доступ к мультикасту?

[myth]

придумал. Телнетом отключаю порт от MVR/ISM Vlan

[morfair]

придумал. Телнетом отключаю порт от MVR/ISM Vlan

спасибо!

а мы буквально только что раскопали igmp radius auth, будем через радиус пробовать.

[pppoetest]

придумал. Телнетом отключаю порт от MVR/ISM Vlan

спасибо!

а мы буквально только что раскопали igmp radius auth, будем через радиус пробовать.

Работает, железобетонно.

[morfair]

придумал. Телнетом отключаю порт от MVR/ISM Vlan

спасибо!

а мы буквально только что раскопали igmp radius auth, будем через радиус пробовать.

Работает, железобетонно.

 

Ага, у нас только и длинки, и зухели, разные реквесты они шлют, к сожалению( Надо разруливать

[alibek]

А в случае igmp auth какая информация отправляется на RADIUS?

Порт и MAC-адрес подписчика?

Мы используем шифрование, но для некоторых задач igmp auth был бы удобен.

[myth]

igmp radius auth

Вот только у нас с десяток свитчей всего ее поддерживает

[pppoetest]

Порт и MAC-адрес подписчика?

+ ip nas'a, всё зависит, кмк, от реализации радиус-клиента Nas

[ShyLion]

на freeradius+perl+DB по вкусу решаются любые зоопарки

[morfair]

А в случае igmp auth какая информация отправляется на RADIUS?

Порт и MAC-адрес подписчика?

Мы используем шифрование, но для некоторых задач igmp auth был бы удобен.

 

Примерно так:

 

D-Link:

 

rad_recv: Access-Request packet from host 10.90.68.90 port 1033, id=23, length=96
       User-Name = "1C7508058FDC"
       User-Password = "1C7508058FDC"
       NAS-IP-Address = 10.90.68.90
       NAS-Identifier = "D-Link"
       NAS-Port-Type = Virtual
       Service-Type = Framed-User
       Framed-Protocol = PPP
       NAS-Port = 1
       Framed-IP-Address = 239.37.239.5

 

ZyXel:

 

rad_recv: Access-Request packet from host 10.90.68.81 port 1026, id=10, length=141
       User-Name = "1c7508058fdc"
       User-Password = "1c7508058fdc"
       Service-Type = Framed-User
       NAS-Port-Type = Virtual
       Called-Station-Id = "B0-B2-DC-B2-7B-B6"
       NAS-IP-Address = 10.90.68.81
       NAS-Port = 2
       Calling-Station-Id = "1C-75-08-05-8F-DC"
       Framed-IP-Address = 192.168.7.97
       NAS-Port-Id = "VLAN65/239.37.239.9"

 

А в случае igmp auth какая информация отправляется на RADIUS?

Порт и MAC-адрес подписчика?

Мы используем шифрование, но для некоторых задач igmp auth был бы удобен.

 

Как шифруете и расшифровываете, если не секрет? Поддержка со со стороны Middleware нужна? Мало наглядной инфы гуглится по этому поводу.

[alibek]

У нас используется Middleware IPTVPORTAL.RU.

Есть программный плеер, есть прошивки и плагины для аппаратных плееров (но мы используем только Dune и TVIP).

Плеер авторизуется на портале и периодически забирает с него ключи для расшифровки.

Контент мы получаем зашифрованным изначально, при необходимости можно шифровать свой контент, IPTVPORTAL дают софт бесплатно.