RealResident

зачем рвать? СТП его уже порвало, найти разрыв, а дальше все так же.

Включить cdp, если не включено и помостреть кто чей сосед.

Что бы провайдер начал страдать подобной ерундой, а на сколько я понял, вы хотите работать именно с провайдером, а не купить 100 подключений, надо провайдера серьезно в этом заинтересовать. И заинтересовать финансово именно манеджеров. С технической точки все эти ваши игры можно вообще подмешивать в клиентский трафик. Будет что-то вроде "каждое новое tcp соединение будет натиться новым IP, при чем кроме вашего трафика с этого IP будет идти живой клиентский трафик" и так по кругу по /17 или сколько есть у провайдера. Стоимость железа... посмотрите сколько ASA гигабитная стоит. А по хорошому все это такая... ерунда. Ну вот вообще ни разу не интересно, неужели в синтере заинтересовались в этом? Наверно менеджер неопытный попался, который даже не понял что от него хотят. У нас была одна такая -- продавала ВПН клиентам с одной точкой подключения к сети... И ведь покупали, даже приоретизацию докупали для трафика, которому некуда идти. В крупных провайдерах вашему проекту надо такую цепочку служб/отделов/департаментов пройти, что не удивидельно что Вас динамили. Более мелкие провайдеру скажут "чушь какая-то, нет, не интересно", потому как цепочка поменьше и менеджер, что с вами работает быстро получит разъяснения о чем идет речь и куда отправлять с подобными просьбами. Сейчас вы клянетесь, что будет все тихо и спокойно, а через 6 месяцев проект не понравиться и сольете все эти IP ботнетовцам. Вот весело будет технорям потом вычищать IPы из бан листов. Нет, с технической точки зрения просьбы подобные отсылаются на юг, прямо и без сожалений. Кроме того, даже если какой-то менеджер заинтересуется сильно откатом, технари будут настойчиво советовать ему подумать ещё раз стоит ли откат места где он сейчас работает. Если стоит, то значит менеджер ни разу не директор, а потому с подобными авантюрами будет послан коротко, в письменном виде и не стесняясь в выражениях. Можно и развернуто послать, но тогда с копией его/её непосредственному начальнику. Вам не мидлов надо искать, а смолов (это откуда я взял что гигабита хватит), при чем готовтесь к ротации партнеров.

Любой маршрутизатор cisco с "ip sla" (а без ip sla бывает?), который и будет переключать провайдеров. Какой трафик? Сколько бит и пакетов в секунду? А от микротиков приходится избавляться :(. При эксплуатации порядка 50 микротиков, раз в месяц какой-нить да приходится передергивать. PC решение замечательно, но это не разовая работа по настройке. Там же наверняка и фаервол надо иногда менять и DMZить что-нить, а человек неопытный, начитавшись интернетов, может и занастроить такой PC до смерти. Хотя на cisco молиться тоже не стоит. Сейчас там индусы пишут ПО и косяков немерянно. Не считая того, что некоторые вещи, абсолютно ожидаемые и нужные, особенно при работе с двумя провайдерами, на ней просто нельзя сделать не извернувшись. Вещи, которые на бзде нетграфом или на линуксе модулем для иптаблез решается 10-ю строками кода. Хотя безусловный плюс cisco -- это то, что на ней очень многие вещи можно сделать даже не понимая что происходит. "Мне нужно следать два провайдера" -- "отлично, вот вам 5 строк, поменяйте здесть и здесь".

iptvportal"Удобный портал для IPTV STB (для персонального использования)" -- это заработает? Что бы можно было посмотреть как оно выглядит. У клиента именно это и будет? В смысле пользовательского интерфейса.

Ясно, думаю что они скорее против скрамблирования (сокрытия) информации, а вот открытие информации... это уже либеральная пресса, викиликс, юникс вобщем :). Ну нет, так нет, вычеркиваем dvblast значит. А какие-нибудь подробности или комментарии разработчиков по этому вопросу есть опубликованные? Вообще странно. Библиотека скрамблирования есть, а программа скрамблирующая -- не их путь. У каждого свои тараканы.

Так ведь dvblast уже давно вокруг csa ходит, уже и библиотека есть для кодирования/декодирования CSA на том же videolan, ну или притворяются что есть, ждем когда сподобятся. А системы такие есть, деньги за них хотят правда.

Ну я бы не удивлялся такой скорости. Есть разница в "перекодировании по-честному" и "перекодировании с тюнингом кодера". После тюнинга канал после переключения начинает показывать с квадратов и в зависимости от динамичности картинки квадраты постепенно собираются в картинку. На канале "говорящая голова" срезка битрэйта с 1500-2000 до 500 не играет особой роли: там и резкое движение камеры происходит раз в три часа, а появляющиеся при этом небольшие квадраты и мазки по краям объектов воспринимаются как задумка оператора показать неразбериху и панику, творящуюся в динамичной сцене. На каналах же а-ля "MTV UK", где идет частая смена картинки и постоянные "резкие" спецэффекты эти размытости начинают немного мешать, так же как и, например, на TLC, где бабы постоянно размахивают цветными платьями и разноцветными лазаньями. Сегодня попробовал на 4-х головом i3 10 каналов пережать с битрэйтом 500 -- вполне себе, если не придираться, ну явно лучше, чем на youtube и там, где другой альтернативы нет и такое ТВ тоже ТВ. А вообще, конечно, баловство все это, потому как на топовых каналах битрэйт, уже пережатый по-честному, доходит до 3000 и в эти моменты проц подскакивает серьезно. Но в целом все это сглаживается: у одного канала скакнуло, у двух других наоборот упало, в итоге смотреть можно. Хотя бывали откровенные шахматные доски секунд на 5, ну и, конечно, эта задержка с прорисовкой вновь включенного канала. Я полагаю, что поиздевавшись над кодеком, растянув key-фреймы на пару минут, да и ещё раздавая по хттп, где key-фрэйм просто не может потеряться можно и больше выжать и битрэйт (честный, до срезки) дожать до 500 (в среднем, не резанный битрэйт, без cabac'а, в районе 700-1500 у среднего канала, с cabac'ом 500-900, но у последнего свои неприятности).

С помощью unicast маршрутизации никак. Либо запускайте обычную multicast маршрутизацию (как это обычно делается), либо меняйте интерфейс для мультикастных пакетов у сокета в который вещает getstream (так как getstream не поддерживает такую функциональность, то только перезапуском getstream'a). После открытия socket'a как ни колдуй над unicast маршрутизацией, если программа открывшая сокет не вызывает setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF...), интерфейс куда посылаются пакеты, будет оставаться тем же, что был выбран при открытии сокета (по-умолчанию). В этой ситуации самый простой вариант решения проблемы: а) route add -net 224.0.0.0/4 dev dummy0 б) запустить smcroute; в) smcroute'ом прописывать статические мультикастные маршруты в нужный интерфейс, например: smcroute -a dummy0 10.0.0.3 239.255.90.90 vlan22 г) проверить таблицу мультикастной маршрутизации: ip mroute show (10.0.0.3, 239.255.90.90) Iif: dummy0 Oifs: vlan22 ... Все, меняя статические маршруты можно направлять мультикастный трафик в нужный интерфейс. Но обычно это делается по-человечески, то есть настроив динамическую мультикастную маршрутизацию.

100% с периодическим отваливанием консоли, если RT99 приоритет дадите перекодировщику. В потоках, соответственно, будет пусто -- иногда будут фотографии показываться. Пережатие видео очень дорогая процедура, в основном из-за отсутствия бесплатной реализации алгоритма mp2-->mp4p11. То есть во всех этих пережимателях идет не перевод из мп2 в мп4, а mp2-->raw-->mp4. А вообще чем перекодировать не имеет особого значения ffmpeg или vlc или ещё какой-либо врапер библиотек обработки медиа потоков. Все они используют одни и те же алгоритмы из одних и тех же библиотек и процессор 99% времени проводит в коде этих библиотек, а не в враперах.

А есть смысл в оскаме именно от Юрика? Что-то не въехал я в его главное преимущество в "быстром переключении каналов". Или в плане дре Юрик впереди планеты всей? Или это своего рода адаптированный для пространства ру оскам? На каких картах выигрыш по сравнению с обычным оскам?

Тогда на циске все нормально: Это же те самые группы куда ТВ запускается? Все ок, циска честно по этим строкам и будет передавать мультикаст от каждого каждому. Мож поискать проблемы на клиенте. Врят ли это в неуправляемых коммутаторах проблема -- igmp, судя по всему, доходит.

У вас в 22-ом влане тишина полная. Квериер надо в 22-ом влане запускать, а не указывать IP 22-ого влана. И снуфинг надо в 22-ом влане включать, точнее включить глобально и не выключать на влане. sh ip ig sn vl 22? 22-ой влан вообще жив? sh vl id 22

А как сама перекодировка? Поток не раваливается? Я как-то пробовал им пережать, видео, правда -- закончилось тем, что ффмпег (факинг фэст?) сначала набирает в буферы пакеты, а потом векторной арифметикой параллельно пережимает все эти пакеты и выплевыет в сеть. В итоге vlc ещё нормально читает поток, если пребуфер побольше поставить, а dib заикаться начинает.

Тут ещё вопрос "а что делает в этих вланах мультикаст?", если это клиентский влан между его точками, то может он ему нужен? Если это ваш влан и там должен ходить мультикаст, то запустите свой квеирер с приоритетом повыше, другие квериеры должны затыкаться как только услышат запрос от квериера с меньшим, чем их, IP. А вообще написали же: фильтруйте igmp на 224.0.0.1, 224.0.0.22, 224.0.0.2 (угу, на DVMRP тоже igmp snooping смотрит) и, возможно, 224.0.0.13 (ALL-PIM-ROUTERS). Вообще не понял как это левый мультикаст к querier'у может идти. sh ip ig sn mr скорее всего там мультикастные маршрутизаторы определились, а то, что квериер -- это не страшно. При чем порт как маршрутизаторный определился не на этом коммутаторе, а на том, что дальше, тот что потупее и увидев querier сразу его в mrouter'ы записал, вот и шлет в этот порт весь мультикаст, что видит. А вообще решение от левых квериеров (неправильно сконфигурированного оборудования клиента) -- запустить свой там где ему и место, исходя из топологии сети. Если это не негодяй какой-нить, от негодяев уже эксес листы только помогут. Да вообще, зачем негодяям мультикаст?

Так, в качестве нечто такого летающего в воздухе, а что если между udpxy и пользователем ещё apache с mod_proxy поставить. Сразу решится вопрос с живучестью при большом числе коннектов (на udpxy только один коннект будет приходить) и авторизовать на апаче можно будет и вопрос про 700-900-1500 исходящего хттп трафика отпадет, при чем решение масштабируемое и легко множится... Сдается мне mod_proxy подправить надо будет немного, а может уже есть правленный?

Прошу прощения, но не смог удержаться... Костантин, какую же вы все-таки чушь пишете... Интересно посмотреть на клиента, готового заплатить за железку, разжимающую 90 мп2/мп4 одновременно. Процентов 90 клиентов настолько привыкли к халяве, что 1500 руб. не хотят платить за один декодер мп4. До вас до сих пор не дошло, что если клиента жаба душит заплатить за прибор, декодирующий 5 каналов (или сколько у них там телевизоров в квартире), то за 90 каналов клиент ну вот ни как платить не будут. Конечно всем интересен такой девайс... рублей за 500-600. Константин, вы бы не пороли чушь и вернулись бы обратно к установке домофонов что ли. Не то это место, где ваша пыль может хоть немного помешать узреть абсолютно некомпетентного человека, ни в техническом плане, ни в плане коммерции.

Смотрите ежа в мешке не купите вместо кота. А то знаю я этих любителей продать дорого и анонимно. А если серьезно, ни кто не в курсе чем они там пришивают карты к ресиверу? Может есть догадки или девелоперская документация по этим мега-ресиверам попадалась. А вообще эту привязку вроде как хакнули. По крайней мере есть в инете конторы с реальным адресом, куда можно приехать и купить комплект из ресиверов + wifi-dvb-карты с wifi-щаринг станцией для HD пакета. Значит какнули, раз шарят ключики.

Я бы для начала ядро посвежее поставил (руками или обновил через пакеты) и отключил бы все в ethtool -k eth0, прежде чем куда-то глубже лезть.

Только на циске такое? На циске сталкивался, например, с модулем WS-X6148-GE-TX, для 76-ой или 73-ей или для обоих. Во время перехода рынка со 100М на гигабит, циска выпустила несколько подстав. Взяла 100М модуль и сменила только морду у него: выпаяла 100М и вставила гигабиты, в результате получился гигабитный модуль, в котором порты поделены на блоки по 8 портов и на каждый такой блок максимум трафика, что может идти -- 1Г. То есть, если пользователь в первом порту тянет 600М, то пользователь во втором получит 400М, на самом деле они по-честному поделят, но смысл в том, что сумма трафика на 1-8 портах не может превышать гигабита, сумма на 9-16 не больше гигабита и т.д.

Убери пиды из конфигурации dvblast'a, размер идущего потока больше 1,5 Мбит?

server801 Покажи cat /proc/cpuinfo | grep bogomips. Ты ещё чего-нить крутил кроме размера буфера в драйвере dvb и последующим увечением vmalloc? Если не жалко, выложи свой /proc/config[.gz]. Хотя, если у тебя там 32х12к богомипсов, то конфиг ядра и не нужен, наверно. :)

angelora, у тебя два demux в одном /dev/dvb/adapter*? Или все нормально и система карту видет как две карты? Расскажи что за карта такая TeVii-S464. Чего-то совмес не хочется лезть в гугл и искать как там что как видит какую железку. Ты сейчас задал вопрос к очень узкой группе пользователей, тех что работали именно с этой картой, а учитывая, что пользователи getstream'a обычно используют карты по 5 копеек, потому как все что нужно от карты -- это бездумно слить в драйвер потоки, отфильтровав ненужные, то задал вопрос ещё и не в том топике. breusovok, не обязательно, есть карты со двумя демуксерами, тюнерами и т.д. и встренным делителем.

dvblast что пишет? Поймал он спутник или нет? В сети трафик нормальный пошел? Нормальный в смысле не 15-50кб. А вообще этих пидов явно не достаточно для раскрытия канала, нет ни EMM, ни EMC. dvblast вроде не только по пидам, но и по прог_айди умеет вещать, нет? Вы передаете только видео и звук, а самого интересного, что и позволяет прогдвб раскрывать каналы с ключей с шары у вас нет. А вообще что за вопрос? Можно столько проблем сейчас на нуле информации придумать. Трафик-то сам пошел? И главный вопрос: dvblast умеет по прог_айди вещать всё вместе со служебными каналами?

Все, спасибо, разобрался. я лопух. В секции newcamd не указал в port какой ident и provider раздавать. Getstream похоже caid берет от newcamd, а не из потока.