Как нам построить маленькую радиостанцию в большой сети

В этой статье не будет описываться, как можно быстро настроить icecast в различных Linux системах для разных задач. Нет. В этой статье хотелось бы осветить маленькую историю одного небольшого проекта по выводу эфирной радиостанции в глобальную сеть. С какими проблемами пришлось столкнуться и как мы их решали.

Итак. Маленькая предистория — есть радио-холдинг из нескольких эфирных музыкальных радиостанций с головным офисом в столице нашей родины Москве. Сами радиостанции вещают себе в FM диапазоне столицы, имеют свою аудиторию и вполне себе счастливы своим слушателем. Но вот незадача — на дворе 2012 год, а направление интернет вещания развивается не шатко не валко. Дальше будет много слов и маленьких историй в рамках одной основной, если заинтересовало, добро пожаловать под кат.

Постановка задачи давно назрела, как для генерального директора всего холдинга, так и для многих программных директоров самих радиостанций. Но была небольшая проблема — холдинг ни в каком виде не видел способов монетизации этого сервиса, а раз нет монетизации, нет и никаких бюджетов для того, что бы построить безумное решение. Почему задача назрела — существовавший сервис на тот момент (весна 2012 года) не удовлетворял никаким требованиям надёжности, качества и удобства. Как раз к весне 2012 года в холдинге произвели смену руководства технического департамента и IT службы. Мне судьба и мои коллеги «подарили» возможность руководить IT службой этой компании.
Итак.

Предварительная ситуация


Вещание в Интернет в компании обеспечивал небольшой комплекс серверов:
  • 1 раздающий сервер (FreeBSD, допиленный icecast, thanscoder, 3 Gbit ethernet, M IX Бутлерова)
  • 2 сервера энкодирования, установленных в студийном комплексе (он же головной офис) в Москве и кодирующих аналог/AES источники в MP3 потоки на основной раздающий сервер (Windows XP, icecast, edcast)

Далее сигнал в формате MP3 отправлялся не совсем прямо — для каждой из радиостанций, а их было 5, формировался поток в 256 kbit/s и публиковался на локальном icecast сервера энкодривания, после чего, основной сервер раздачи через NAT самостоятельно забирал эти потоки и транскодировал их в дополнительные (64, 96, 128, 320). Это по серверной части, по клиентской части всё было ещё хуже — никакого flash/html клиента не существовало в принципе, был написан небольшой FAQ выложенный на сайте радиостанций, как подключаться к потокам и на этом всё «облизывание» клиентов заканчивалось. Нужно добавить, что работала эта конструкция ни шатко не валко, практически ежедневно мы наблюдали «срывы» потоков основной радиостанции холдинга при достижении 3-3,5 тысяч слушателей, как правило «срывы» возникали в течении дня по несколько раз. Причины сбоев были различными, то transcoder встанет, то почему то сервер решит, что он не видит удалённую точку монтирования, то ещё что-то. Короче заняться было явно чем.
На мой логичный вопрос адресованный инженерам, которые осуществляли поддержку всего этого хозяйства — а что ж так «не логично» то всё выстроено? Последовал обычный ответ — ну так исторически сложилось. Нужно отметить, что «допиливанием» icecast занимался внешний аутсорсовый сотрудник из Новосибирска. Отличный парень, знает FreeBSD вдоль и поперёк, пишет на C or C++, но понимания в мультимедиа у него не такое большое, а как строить большие вещательные платформы в сети, да ещё и без единой точки сбоя он точно не знал. Да и не надо оно ему, ему деньги не за это платят. Плюс разница во времени, короче точка перелома была пройдена в тот момент, когда в наш кабинет с начальником технического департамента вошёл Генеральный и сказал — ребят, что-то у меня не играет с iPhone наша радиостанция в сети, давайте, что-нибудь уже сделайте. Отвечать ему было нечем — ну реально же не играет, потому, что опять, что-то там отвалилось и т.д.

Сначало нужно подумать


Любой администратор скажет вам при виде icecast, что тут думать, тут «запиливать» надо. Но это не наш случай. Нам так уже «исторически» запилили, что нужно эти конюшни привести к какому-то нормальному уровню. Основные проблемы существовавшие на тот момент:
  • низкий уровень резервирования — по сути не резервирован был ни один компонент системы
  • отсутствие системы хоть какой-то балансировки нагрузки – все потоки на один сервер, все клиенты на один сервер. А там посмотрим, удержит он их или нет.
  • большое количество недиагносцируемых сбоев
  • проведение диагностики затруднено в силу недостаточной документированности кастомизаций icecast and FreeBSD core + устаревший продукт (FreeBSD какой-то там лохматой версии) + проблемы с этим продуктом в виде не совсем «верно» реализованных частей стэка TCP/IP, которые вылезают, как раз при высоких нагрузках с большим количеством сессий
  • полное отсутствие FM обработки сигнала — это считается очень непрофессиональным в радийной среде, если нужно пояснение в личку или комментарии
  • отсутствие flash/html клинета для проигрывания прямо на сайте радиостанций
  • отсутствие системы мониторинга

Короче копать куда есть, теперь как это всё привести к какому-то разумному виду.

Хватит думать – пора «запиливать»


Решение требовалось системное – что приходит на ум любому управленцу из IT когда он сталкивается с не совсем профильной задачей – правильно, а давайте отдадим на аутсорс за деньги. Некоторые, не особенно чистые на руку управленцы ещё и свой интерес в стоимость аутсорса успевают засунуть, но мы не об этом. Мы с моим начальником рассматривали сразу оба решения, т.е. или мы делаем это сами и как, или мы отдаём это на аутсорс, тогда возникает вопрос – а сколько это будет стоить? Так вот, вопрос аутсорса отпал сам собой, как только мы посчитали сколько будет стоить отдать вещание в сети третьей стороне и забыть об этой задаче навсегда. Компании которые предоставляют подобные услуги публично представляют такие цены на свои услуги, что крупные игроки радио рынка к ним не придут никогда, это факт. Доходность даже крупных радиостанций входящих в десятку в Москве конечно позволит им отдаться на этих условиях, но всё равно будет значимой статьёй расходов и это при отсутствии нормальной монетизации. Есть сервисы предлагающие сразу и вещание и монетизацию в виде размещения различных видов рекламы, но и у них цены на услуги достаточно высоки, а вопрос возврата инвестиций стоит очень остро, поэтому было сказано – НЕТ. На это мы пойти не можем, тем более, что нанимали нас с целью уменьшения операционных расходов максимально доступными способами, а тут всё будет с точностью наоборот. Короче, отказались мы от этой идеи.
Строим сами – как?
  • Резервирование – увеличиваем количество раздающих серверов до 4 с встраиванием механизма балансировки на уровень icecast-kh. Выносим энкодирующий софт на платформу виртуализации. Вынимаем icecast первого уровня раздачи с энкодеров и ставим его на отдельную виртуальную машину. Резервируем каналы интернет в центральный офис
  • Балансировка – балансируем нагрузку в зависимости от наполнения точек монтирования средствами icecast-kh
  • В качестве энкодирующего софта предложено использовать Omnia AX/E, он позволяет закрыть, как потребности в энкодировании, так и FM обработке звука
  • полный отказ от транскодирования на основных серверах раздачи, сервер должен получать уже полностью готовый поток и только его раздавать
  • Полный отказ от FreeBSD на серверах и переход на какой-то из Linux (в итоге выбрали Ubuntu 12.04 LTS)
  • написание силами соседнего департамента полноценного flash/html клиента для проигрывания на сайте, разработка клиентов для мобильных платформ iOS+Andriod
  • предоставление клиентам не только MP3, но и AACv2+ потоков для прослушивания в сетях мобильных операторов
  • установка системы активного мониторинга с возможностью изменения файлов по событию


Почему так?
Попытки ставить какие-либо балансировки нагрузки перед icecast несущими большое количество потоков, на мой взгляд абсолютно бессмысленны. Если у вашего сервера есть гигабитный канал связи, при сравнительно слабеньком процессоре и небольшом количестве оперативной памяти Icecast его забьёт полностью, только подтаскивайте клиентов. Так что вы будете балансировать? Несколько гигабитных потоков, а что делать с единой точкой отказа? Какой выход – балансируем только на сетевом уровне средствами коммутаторов, если у вас есть port channel. При трёх гигабитных каналах вы сможете рассчитывать на 2,7 гигабита в секунду, при четырёх каналах на все 4, ну и так далее. Распределение нагрузки между серверами, дабы не перегружать точки монтирования может осуществлять сам icecast, его KH версия. На практике оказалось, что icecast не удерживает более 3200-3500 на одной точке монтирования 128 kbit/s MP3 – причина, насколько мы понял, в высокой нагрузке на ядра процессоров. Дело в том, что icecast по умолчанию обрабатывает одну точку монтирования на одном ядре. В случае если точек монтирования больше чем количество ядер в системе он начинает их разделять по ядрам, но опять же, не равномерно, а по точкам монтирования на одно ядро. Если процессоры у вас не очень скоростные, то больше 3000 одновременных на одну точку монтирования нагружать не стоит, можно воспользоваться хитростью – перебрасывать по достижению этой величины на скрытую точку монтирования на этом же сервере, но с другим именем. В обычном icecast эта «извращённая» логика отлично работает. KH версия требует, что-бы у другой точки монтирования был и другой источник.
Второе, я считаю, что создавать монструозный сервер для задач вещания означает абсолютно не учитывая возможности горизонтального роста платформы в целом, что не совсем верно, в дальнейшем всё равно аукнется и ещё как. Поэтому был выбран вариант именно с горизонтальным масштабированием.
Почему хотели кодировать проприетарным софтом – не хотели городить огород в виде отдельных компонентов FM обработки и энкодинга, ну и внедрение AXIA LiveWire было очень «вкусным» дополнением к решению этой задачи. Плюсом было ещё и то, что после тестирования нескольких энкодеров стало понятно, что AXIA отличается от бесплатных именно качеством сжатия, т.е. по сравнению с lame и т.д. она лучше звучит. Долго объяснять «почему?» не хотелось бы, лучше потом или в комментариях.

Начинаем «мотылять»


С чем столкнулись сразу – стало понятно, что нужно как-то измерять количество слушателей, причём и одновременных и накопленных за сутки, день, неделю и т.д. В процессе выяснения чётко стало понятно, что оставлять такое разнообразие потоков и многие из них крайне «толстые» (320 например), мы просто не можем. Вот это и было первым серьёзным камнем преткновения, причём убедить программных директоров и остальных топов оказалось сильно проще чем рядовых инженеров отвечавших за реализацию этой задачи в прошлом. «Аудиофильское» состояние души отказывалось понимать объективную реальность. Не мытьём так катаньем нам удалось это сделать, крови это стоило большой и душевных ран оставило немало. Но слава Богу никого не уволили и не испортили карму с подчинёнными. Начали приводить всё в порядок. Пришли к следующим стандартным потокам для каждой из 5 радиостанций – 128 & 64 kbit/s MP3, 56 & 48 kbit/s AACv2+.
Долгое время не трогали основной раздающий сервер, приводили в порядок внутреннюю инфраструктуру. Наконец в один из дней весной 2013 мы с моим подчинённым утром метнулись на M IX и устроили обрушение всего и вся с дальнейшим поднятием. Получилось неплохо. Сразу выяснились плюсы внедрения Linux в связке с icecast-kh – он реально начал слабее грузить процессоры при тех же нагрузках. Разница было до 20%. Это много. Плюс, сразу разнесли нагрузку на 4 сервера и в течении дня начали подключать их к единой DNS записи.
Из-за затруднений у отдела разработки с получением нормального плеера мы решили дополнить балансировку нагрузки ещё и механизмом Round&Robin в DNS. Он конечно не самый надёжный, но пока не об этом.

Я ухожу оставляя горы окурков… Итоги


В ноябре месяце 2013 года моя трудовая деятельность в этой славной компании закончилась. Чем могу гордиться и что осталось не сделанным в рамках этой задачи.
Общий поток фермы из 4 серверов превысил 2,5 Gbit/s в пике днём и продолжал медленно повышаться от месяца к месяцу. До всех телодвижений, которые были произведены он не превышал 1,2-1,3. По факту компания обслуживала не всех кто хотел получить сервис, а только тех кто успевал первым.
По предварительной статистике мы смогли «пробить» показатель полмиллиона уников за неделю, эти цифры уже можно как-то продавать. Был обкатан механизм размещения intro файлов, которые проигрывают рекламный ролик каждому подключившемуся пользователю, пока без отслеживания кому уже проиграли, а кому нет, но это был первый опыт размещения.
Нагрузка начала более равномерно разноситься по серверам, и это сказалось на качестве сервиса. Перебои возникали только в результате реальных сбоев сети и других проблем, но уже не были вызваны некорректной настройкой самих сервисов или другими проблемами.
За счёт появления качественных потоков с низким битрейтом началось смещение количества клиентов с мобильных платформ в сторону их увеличения. Это радует меня как инженера – ведь это по сути будущая модель доставки в целом для радиостанций.
Внутренние icecast были отстрелены и создан единый внутренний icecast для раздачи по всем серверам дистрибуции + он же использовался некоторыми региональнами партнёрами, как резервный источник сигнала. Это не раз и не два нас спасало, да и региональщики сказали спасибо за надёжный сервис резерва.

Чем гордиться не могу.
Остались не реализованными планы по внедрению полноценного перехода на Omnia AX/E – полностью отказали в финансировании. Вынуждены были в итоге городить огород с аппаратными FM процессорами найденными на складе, древними как ммм, ну вы поняли. Осталась проблема мониторинга – отказ в финансировании, решили внедрять PRTG, на Nagios & more просто не было человеческих ресурсов, эта задача потянула за собой невозможность оперативной реакции на выход из строя любого из серверов и недопущению у большого количества клинетов многих минут тишины. Не получилось внедрить нормальную систему аналитики log файлов раздающих серверов – под нормальной понимается система способная посчитать кроме обычных параметров ещё и чисто медийные данные, аля AQH и другие. Единственная система из известных мне это Casterstat, все остальные заточены под обработку в первую очередь Web серверов и не совсем подходят. Так и не были до конца разработаны полноценные плеера для большинства мобильных платформ, смогли закончить только под iOS, но хоть так, тем более, что задача была не у нас.
Я не знаю как оценить в степени завершённости, но внедрить полноценную систему баллансировки на основе pls механизма плееров у нас не получилось в первую очередь из-за проблем со стороны отдела отвечавшего за разработку плеера. Но это не важно, винить нам их не в чем да и не за что.
Нужно понимать, что это далеко не единственная задача, которую решал технический департамент и IT служба за время моей работы в этой компании, поэтому не стоит удивляться такой длительности. Это я типа оправдываюсь.

Если кого-то заинтересовала тема IT в мультимедиа сфере, то могу продолжить рассказы на какие-то другие темы, благо опыт есть.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 41

    +3
    Очень странная ситуация.
    По идее, одного сервера должно хватить. Самое прожорливое — это енкодинг (в среднем ядро на поток).
    Подсказка, nginx+ffmpeg+icecast
      +3
      Ээээ… грустно это, действительно не понятно зачем весь этот огород.

      Существует замечательное, недооцененное, стабильно работающее (проверенное временем) решение в виде «Liquidsoap». Который все транскодирует на лету, в придачу полноценное управление плейлистами, джинглами, своим (довольно приятным) языком программирования сетки вещания. Возможностью навешивания сервисов типа голосования, стола заказов и т.п. А уж после него ставь icecast на горизонтальной архитектуре масштабирования серверов и… все! Вопрос только в канале (но судя по посту, 3 Гбит/сек довольно серьезная цифра).

      При этом мониторинг (я уж не знаю требований в данном случае) в виде «работает нода фермы или нет» делается ну буквально за день программистом со знаниями протокола HTTP (заголовки, что да как).
        +3
        Тут довольно странная для IT ситуация — всё то что вы написали про liquidsoap мы прекрасно знали, но вот незадача — он нам не нужен в рамках эфирной радиостанции. Все его «плюшки» в виде программирования, управление плэйлистами, джинглы и т.д. в рамках полноценной эфирной радиостанции выполняет профессиональный софт — ротатор/scheduler + playout. То есть, у меня не было задачи в формировании потока, была задача — уже сформированный поток привести к «божескому» виду и возможности массового потребления. Единственное отличие от того, что вы предлагаете сделать на liquidsoap было в том, что уже имея сформированный «поток» он был не MP3 или что-то ещё, а AES или аналог. Теперь по поводу сжатия и FM обработки (FM processing) — готов отписать отдельную маленькую статью, но по сути он реально нужен. Сжатие — тут будет ещё сложнее, большинство инженеров, музыкальных и программных редакторов страдают «аудиофилией» в большей или меньшей степени. Они чётко услышат разницу в сжатии разными MP3 и AAC кодеками. Доходит иногда до смешного — они готовы обсуждать оттенки выраженности тех или иных частотных характеристик у каждого из кодеков. Поэтому, как вы выражаетесь — весь этот огород был нужен. Тут ещё нужно учесть одну особенность, есть такое понятие в среде инженеров обслуживающих радио и телевиденье, как broadcast решение. Оно означает или сильную зарезервированность, или крайне простое и надёжное решение. По сути, как правило, мы строим что-то по надёжности приближающееся к подводной лодке, но без 100% резерва. Часть задач могут быть не зарезервированы вовсе или иметь холодный резерв, но они никогда не являются ключевыми.
        Про мониторинг — вы скорее всего правы и спорить или оправдываться бессмысленно, но я не программист вообще, ну не более простеньких shell скриптов, а программисты способные это сделать в этой организации были загружены на 200%.
        Вот как-то так.
        Но спасибо за коммент, честно не ждал такого количества просмотров. Сильно мотивирует дальше писать более системно и развёрнуто, для лучшего понимания broadcast решений.
          0
          >ротатор/scheduler + playout

          Империя?
            0
            Не совсем вас понял, извините.
              0
                0
                Нет.
                Был на всех радиостанциях RCS www.rcsworks.com/en/ версия была старая, но вполне себе рабочая. Но из-за его подписного сервиса лицензирования, т.е. платежи каждый квартал и всё такое, несмотря на его удобство начали процесс перехода на другой софт. Выбор стоял между DigiSpot tract.digispot.ru/ или Synadyn www.synadyn.com/text.php?id=6. В качестве scheduler рассматривались варианты PowerGold www.powergold.com/ и Digiton Rotator www.synadyn.com/text.php?id=7. Итог — при мне мы перевели 2-е из пяти радиостанций на связку PowerGold + DigiSpot, но закончить перевод всего комплекса мы не успели. Насколько я знаю сейчас все станции холдинга работают на PowerGold + DigiSpot, кроме единственной чисто интернет радиостанции.
                  0
                  спасибо за ответ
                    0
                    Дигиспот = Джин от компании Тракт. Сами на нем работаем, как и ЕМГ, РМГ и многие другие холдинги в стране.

                    А поверголд тоже продается по подписке, платить ежегодно, так что непонятно от чего уходили и к чему пришли.
                      0
                      Объём платежей. Он не сопоставим с PG.
                        0
                        Купили бы Ротатор от Дигитона, он без подписки, или Маг от Тракта. Поверголд тоже совершенно недешевый
                          0
                          Ротатор не устроил по ряду параметров наших музредов. На Маге, хмммм, давайте Вы уж сами на нём как-нибудь поработаете. PG по сравнению с RCS это сущие копейки.
                            0
                            А кто Вам сказал что мы Маг используем? На PG и работаем. Прекрасный софт, своих денег стоит, хоть и немалых. А селектор давно себя изжил уже в России
          +3
          Далее сигнал в формате MP3 отправлялся не совсем прямо — для каждой из радиостанций, а их было 5, формировался поток в 256 kbit/s
          …и транскодировал их в дополнительные (64, 96, 128, 320)
          «Аудиофильское» состояние души отказывалось понимать объективную реальность.
            –1
            Это для вас смешно, а для аудиофила есть разница ))))
              +2
              Для любого человека смешно, из 256 получается 320.
                +1
                Аудиофилы не транскодируют 256кбит/с в 320кбит/с. Качество от этого не улучшится, а ухудшится.
                  +1
                  Да и дело не только в битрейтах. перекодировать формат с потерями(lossy) — кощунство.
                    0
                    Хотите устроим слепое тестирование)))) при этом указав ширину потока для слушателей, но не сказав, что источник один? Вот я посмотрю, как вы будете устраивать в сторонке facepalm. Ещё раз повторюсь, я прекрасно всё понимаю, НО долбанная вводная «исторически сложилось» меняет представление о реальности.
                      0
                      Речь не идет об обычных слушателях. Речь о сотрудниках компании — профессиональных аудиофилах, различающих на слух кодеры (не говоря уж о битрейтах). И вот эти вот сотрудники, ведомые своей филией, хотят отстоять битрейт 320 перекодированный из 256.
                        +1
                        Очень печально читать про такое. Ощущение, что у людей какая-то деградация потребности в качественном звуке.
                  +2
                  Ваше решение лучше, хотя бы тем, что оно работает. В остальном — одни facepalm-ы.

                  — мониторинга нет (любой сисадмин обмажет мониторингом за пол дня-один день)
                  — крайне неудачный выбор битрейтов: 128 & 64 kbit/s MP3, 56 & 48 kbit/s AACv2+. (Тут, наверное, и без пояснений всё понятно — 64 никто не будет слушать, а 56 и 48 между собой не особо отличаются)
                  — резервные каналы для региональных радиостанций в 128 kpbs? без комментариев
                  — балансировка через dns (21-й век на дворе, где anycast? где haproxy? где ipvs?)
                  — в icecast сам по себе протокол примитивный, в 2013-м году я бы попробовал организовать вещание через hls, из минусов разве что задержка чуть больше(в зависимости от размера чанка), в остальном — одни плюсы — простота протокола; легкость построения cdn, меньше ресурсов(не удивился если бы всё поместилось в один сервер), нативная поддержка под iOS и android. (http://en.wikipedia.org/wiki/HTTP_Live_Streaming#Supported_players_and_servers).
                    0
                    Мониторинг опускаю — не причина для споров.
                    Битрейты — тут решение одновременно и компромиссное и функциональное, разница между 56 AACv2+ и 48 AACv2+ есть, называется она parametric stereo, всё что выше 48 она просто не включается. 64 MP3 — ХА скажу я вам, порядка 7% слушателей сидели на нём и не жужжали, хотя прекрасно понимаю, что это странное решение с их стороны, но однако же. Для нас было важно постараться не потерять уже существовавших клиентов и новых приобрести. Тут нужно учитывать фактор «исторически сложилось» и отсутствие финансирования на задачу.
                    Резервный канал — для регионалов формировалась 256 потоки, просто статья не об этом и эту мелочь опустил.
                    Балансировка DNS — принципиально она не нужна, целиком и полностью согласен, при такой архитектуре обычно балансируют ещё смешнее — pls файлы. У меня такой возможности просто не было. К слову, и HAproxy и иже с ними — единая точка отказа, потоки несколько великоваты, как мне кажется, но это уже скорее проще обсудить в личке. Я не настолько силён в HTTP highload.
                    HLS — нагрузка не самая большая проблема, её можно было разнести и на один сервер и какое то время так и делали на icecast, основная проблема — отсутствие масштабирования, как такового, плюс резервирование, его там нет. Второе — icecast я знал и как на нём построить подобную схему понимал чётко. Что делать с HLS, кристального понимания не было, хотя о протоколе знал, но всё равно спасибо. Нативная поддержка — и для icy она тоже нативна. Anycast — а смысл? Точка нахождения всей «фермы» один ЦОД. Но за мысль спасибо, буду думать как строить на похожей архитектуре географически разнесённые решения.
                      +1
                      7% не так уж и много, если легаси — ок. По мне так, самые ходовые битрейты — 128 mp3, 64 aac, 48 aac+ и для пользователей мобильного интернета 32 aac+.
                      Лень дальше обсуждать, но назвать HLS немасштабируемым и нерезервируемым?! Это же идеальный случай и для первого, и для второго.
                        0
                        К слову, и HAproxy и иже с ними — единая точка отказа

                        это не так. особенно, если использовать ipvs + direct routing.

                        потоки несколько великоваты

                        20Gbit/s — легко.

                        0
                        в 2013-м году я бы попробовал организовать вещание через hls

                        простите, а как?

                        hls — это mpeg-ts, порезанный на куски.
                          0
                          а что мешает передавать в нем только audio без видео?
                            0
                            Погуглил и достаточно быстро нашел пример работающего радио www.addictradio.net/en/labs/
                              0
                              технически — ничего. просто mpeg-ts для этого избыточен + большой вопрос в каком кодеке это аудио положить.
                              вот по вашей же ссылке сразу 2 кодека.

                              и большой вопрос чем играть hls в браузере.

                              имхо, для аудио проще с обычным progressive download.
                                0
                                проще — да, лучше? не факт.

                                в браузере играть можно отдельным флеш/жс плеером
                                .
                                навскидку одни плюсы: хлс идет через стандартный порт, хлс кешируется(в т.ч. промежуточными прокси), хлс автоподстраивается под полосу переключаясь на более быстрый или более медленные потоки, у хлс нет проблемы «отстающих» клиентов, в отличии от айскаста того же, хлс поддерживается мобильными устройствами из коробки.

                                минус, очевидный: винамп не играет хлс
                          0
                          В статье много воды и почти никакой конкретики.

                          1. Что за холдинг такой, что при загрузке каналов в 3 гбит/сек и максимальном битрейте в 128 кбит/сек у вас уже свыше 21 тысячи слушателей? Это не ВКПМ, это не РМГ, а у остальных крупных игроков (ЕМГ, Крутой Медиа и НМГ) таких цифр сроду никогда и не было.
                          2. Статья о чем? Динамическую обработку сигнала не сделали, резервирование не сделали (фолбек в айскасте не считаем, это не резерв) — упадет один из серверов и что? Часть слушателей просто отпадет и не подключится, пока записи в ДНС не обновятся (и то спасибо раунд-рубину)
                          3. На платной Омнии свет клином сошелся? Да и без IP Драйверов для Livewire от Аксии — вам не ввести сигналы в омнию. Есть бесплатный, например, StereoTool — прекрасно справляется с задачей программного процессора. Да и тот же ВКПМ уже давно готовит сигнал уже у себя в аппаратных, на спутник подается ровный обработанный сигнал
                          4. 56 и 48 кбит/сек в аас+ действительно нет разницы. Сделайте 64 и 32 кбит. Также можно развивать Ogg — например в 160 или 192 кбит/сек. Европа+ вон в 256 кбит дают поток в мп3.
                          5. Про то, что айскаст распределяет каждый маунт на отдельное ядро — бред еще тот. Есть пример 2ядерной машинки, на ней работает айскаст kh, на нем работают 7 (!) маунтов, на некоторых по 5к слушателей — все прекрасно работает. Просто отлично)
                          6. Балансировка через файлы плейлистов Pls — без комментариев. Это не броадкаст решения, это примитивизм…
                            0
                            1) ММХ — ещё нужно отвечать? В пике по 16-17 к. клиентов днём по всем радиостанциям.
                            2) Динамическая обработка сигнала — в статье чётко указано «Вынуждены были в итоге городить огород с аппаратными FM процессорами найденными на складе, древними как ммм, ну вы поняли».
                            3) На платной Omnia свет несомненно не сошёлся клином, но профессионально сделать процессинг бесплатной версии StereoTool вы не сможете, а если сможете результат будет явно другим нежели у Omnia. Плюс, стоимость в 17тр не Бог весть что для крупного холдинга, как я думал в начале. ВКПМ — кто вам сказал про ровный звук на спутник?
                            4) Без комментариев
                            5) Какая частота каждого ядра этой «мега» машинки?
                            6) Примитивизм — БЕЗ СОМНЕНИЯ! Нет бюджета — нет броадкаст решения, не мне Вам объяснять.

                            Такое впечатление что задел за живое или как минимум обвинил Вас лично во всех смертных грехах? Или конструктив или ничего. По вашей статье про региональное радио у меня тоже масса вопросов, особенно по поводу стоимости применённых решений и их целесообразности. Однако я их не задал, я просто прочитал и поставил для себя «галочку» — можно сделать и так, и люди делают и довольны.
                              0
                              1. 94.25.53.134 — ровно 3005 слушателей, время — прайм
                              2. А для чего?
                              3. Расскажите, как в платной версии с FM «прибамбасами» (типа КСС, РДС, и прочее) вы сделаете звук «профессиональнее»? www.stereotool.com/ — тут можно увидеть КОНКРЕТНЫЕ отличия бесплатной и платной версий
                              4. Вам выше не я один это отметил
                              5. Вы же про количество ядер говорили, при чем здесь частота? Ядер 2, процессор не самый свежий Пень. А вообще — 2.7 ГГц
                              6. Когда нет контраргументов — начинается переход на личности.
                              7. Про региональное радио я никогда и ничего не писал. Про интернет-станции — да. Успешно работают, к слову.

                                0
                                ПО ВКПМ — я там работаю, к слову, поэтому и знаю какой сигнал на спутниках.
                                  0
                                  Не поленился, посчитал полосу текущую — около 320 мбит/сек при 3005 слушателей на всех маунтах. Это в 10 раз меньше чем 3 гбит/сек
                                    0
                                    Значит Мамонтова вы должны знать, он был моим начальником в ММХ.
                                    Остальные сервера по mp3.nashe.ru посмотрите, всё увидите сами. Прайм это около 13-14 часов, сейчас идёт набор слушателей.
                                      0
                                      я по домену и смотрел — именно 3к слушателей.

                                      Прайм уже в 13 наступает, а осталось полчаса. С 3к до 17к как то сложно набрать аудиторию за полчаса, поверьте.
                                        –2
                                        Всё в личку, больше комментировать не буду.
                                          0
                                          Не будете или нечем уже?

                                          Хотелось увидеть более информативную статью, а не выпячивание собственного Эго
                                          0
                                          Хотя, увидел. 2 сервера — со 132 по 134 включительно. Слушателей сейчас — чуть менее 11900. С этим прекрасно справился бы и один сервер с 2мя портами, либо 2 по 1 гбит. Маунтов тоже много — 19 на каждом сервере. У вас 19-ядерная машинка?
                                            0
                                            вернее 4 сервера, как Вы в личке и указали. В этом ошибся

                              Only users with full accounts can post comments. Log in, please.