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'ы записал, вот и шлет в этот порт весь мультикаст, что видит. А вообще решение от левых квериеров (неправильно сконфигурированного оборудования клиента) -- запустить свой там где ему и место, исходя из топологии сети. Если это не негодяй какой-нить, от негодяев уже эксес листы только помогут. Да вообще, зачем негодяям мультикаст?