Разработка видеохостинга на Erlang

    Представляем вашему вниманию доклад Максима Лапшина, сделанный им на конференции Application Developer Days. Мы собрали воедино видео и аудио, слайды презентации, а также стенограмму доклада. Последнее потребовало огромных усилий, но оно явно того стоит. Сорокаминутный доклад можно «услышать» в несколько раз быстрее.

    Свел видео и презентацию в единый ролик, а также записал стенограмму Стас Фомин (человек и пароход локомотив :)).

    Аннотация


    Максим Лапшин (erlyvideo), разработчик масштабируемых веб-сервисов, рассказал о разработке сервера видеостриминга на Erlang. Речь идет об open-source проекте ErlyVideo — набирающем популярность надежном, масштабируемом и бесплатном сервере для трансляции любого видео — от охранных камер до видеоконференций. Особый интерес представляет именно технология, ведь именно выбор такого малоизвестного языка как Erlang, обеспечил высокую надежность, масштабируемость и скорость разработки.

    Erlang — надежный объектный язык для создания сетевых сервисов. Принятые в нём концепции процессов и немутабельности данных, делают его единственной платформой в которой одновременно существует и сборка мусора, и фиксированное время смерти объекта. Семантика языка одна из самых простейших среди распространенных на рынке.

    Эти особенности делают Erlang прекрасным выбором для обслуживания statefull клиентов: видеостриминговый сервер (erlyvideo), самый распространенный jabber-сервер (ejabberd), покерные серверы (OpenPoker) и т.п. В докладе рассмотрено, почему же именно на Erlang такое делать очень удобно.

    Видео




    Подкаст


    Ссылка на подкаст.

    Презентация


    Ссылка на PDF со слайдами.

    Стенограмма


    Стенограмму по видеозаписи записал Стас Фомин.

    Что такое стриминг?

    Добрый день, меня зовут Максим Лапшин, я автор видеостримингового сервера ErlyVideo, написанного на Erlang, и сегодня я бы хотел вам рассказать, что это за продукт, зачем он был сделан, … что это такое, зачем я все это сделал.

    Итак, что такое стриминг вообще.
    Слайд:
    Ютуб — это не стриминг
    Что такое YouTube? Там хранится огромное количество разного видео, но это не стриминговый проект, там нет стриминга. Там просто десятисекундные ролики, которые выдаются вам nginx-oм, ну или другим вебсервером.

    Каждый браузер заходит, получает какой-то ролик и его проигрывает. Но это не имеет никакого отношения к потоковому видео. Где же тогда все это используется, к чему это все?

    Пользовательское ТВ
    Слайд:
    Пользователь загружает видеофайлы
    • Составляет плейлист
    • По запросу других плейлист начинает проигрываться
    • Если никому не нужно, то видео не играется
    Давайте рассмотрим задачу пользовательского телевидения, которая у меня недавно стояла. Значит, идея в чем — пользователь загружает свои файлы, почти как в ютуб, потом формирует из них плейлист, который он хочет, чтобы показывался как телепрограмма на обычном телевидении.

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

    Почему же не сделать это все на обычном nginxe?

    Вроде как обкатанная технология, у того же ютуба работает, но нет, не работает.

    Что делает стример?
    Слайд:
    Что делает стример?
    • Распаковывает видео и аудио из файловых контейнеров
    • Упаковывает в транспортный контейнер
    • Посылает кадры синхронно с реальным временем
    Проблема вся в том, что необходимо имеющиеся файлы отдавать в видеопоток. Потому что необходимо монотонно всем пользователям показывать одно и тоже.

    Для этой задачи как раз нужен стример, то есть сервер потокового видео, который сделает вот что.
    1. Он заберет нужные файлы, из тех контейнеров, в которых они лежат у вас на диске.
    2. Упакует их в транспортный контейнер, по которому можно будет доставить видео тем пользователям, которые пришли на него посмотреть.
    3. И очень важно понимать, что он посылает кадры синхронно с реальным временем.
    Значит, если вы зашли, вы за полчаса получаете реального времени по часам вы получите полчаса реального времени, которые из файла. Если вы просто скачиваете файл, вы бы могли гораздо быстрее скачать.

    Отступление про кодеки

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

    Контейнер — это то, во что упаковываются уже закодированные данные. Например, если вы встретили h264 или AAC, то это видео и аудиокодеки, соответственно. А MP4 … — нет такого кодека, это контейнер, в который можно убрать абсолютно любое видео и абсолютно любой звук.
    Слайд:
    • Кодек — формат представления сжатых аудио и видео данных
    • Контейнер — формат упаковки одного и более потоков аудио и видео в файле или в потоке
    • H.264/AAC — лучшие кодеки
    • MP4 — самый компактный файловый контейнер
    Этапы User TV
    Слайд:
    Этапы User TV
    • Скачать плейлист
    • Распаковать файл
    • Упаковать кадры в транспортный контейнер (RTMP, MPEG-TS,…)
    • Зачистить всe, когда уйдут клиенты
    • Позволить обновить код, не отключая клиентов
    Итак, чем же занимается сервер, показывая пользовательское телевидение? Он скачивает плейлисты, распаковывает файлы, перепаковывает их, зачищает все, и очень важная вещь, про которую я отдельно не упомянул, это то, что в этой задаче очень важно обновлять код, не отключая клиентов, потому что бывает до тысячи, … многих тысяч клиентов, которые пришли посмотреть интересное видео. Если мы захотим в этот момент выкатить апдейт под них, то эти тыщи клиентов опять к нам придут, реконнектится.

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

    Традиционные способы решения

    На чем это обычно люди делают, такие решения? Традиционные способы решения, это традиционные инструменты — Java, С++, на них есть продукты, которые занимаются потоковым видео. Это например, Red5, бесплатный, платная Wowza, написанная на Java, либо это rtmpd, написанный на C++.

    Парсинг mp3 на Java

    В чем проблема…? Ну вот пример я привел, это маленький кусочек кода, как парсится RTMP на Java, это маленький кусочек кода, одна сотая файла.

    Вот так выглят любой сервер на Java, можно присматриваться — это малая, малая, часть файла. Вникнуть в это очень сложно.
    if (id3v1 instanceof ID3V1_1Tag) {
       try {
         // Add the track property
         graph.add(mp3Resource, processor.resolveIdentifier(IdentifierProcessor.TRCK),
             factory.createLiteral("" + ((ID3V1_1Tag) id3v1).getAlbumTrack()));
       } catch (GraphException graphException) {
         throw new ParserException(
             "Unable to add track number to id3v1 resource.",
             graphException);
       } catch (GraphElementFactoryException graphElementFactoryException) {
         throw new ParserException(
             .... ещѐ 600 строк кода
             graphElementFactoryException);
       }
     }
    

    Парсинг mp3 на Erlang

    Это все, что нужно написать на Erlange, чтобы декодировать MP3. Все. Пять строчек. Оно уже все распаковано и можно отправлять пользователям.

    decode(<<2#11111111111:11, VsnBits:2, LayerBits:2, _:1, BitRate:4, _/binary>> = Packet) ->
      Layer = layer(LayerBits),
      Version = version(VsnBits),
      <<Frame:(framelength(bitrate({Version,Layer}, BitRate))/binary, Rest/binary>> = Packet,
      {ok, Frame, Rest}.

    Соответственно, что мы получаем — уже начиная с самого начала, с распаковки файла, что-то не то, и в Java, и в C++, очень много кода, очень много накладной логики мы пишем в нашем коде.

    Но все становится…, весь этот синтаксический сахар, все это становится, совершенно неважным, когда к нам приходят тысячи клиентов.

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

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

    В случае C++, у нас есть другая проблема, Java позволяет как-то защитить код за счет отсутствия прямой работы с памятью. В C++ ошибка в одном месте, особенно если у вас многотредное приложение, она вам может разрушить все приложение, и вы никогда не отладите этот баг. Вы можете быть гарантированно уверены, что в любой программе на C++, особенно многотредной, есть баг, который вы еще просто не нашли, даже не рассчитываете, что он там есть.

    И другая проблема, что когда у вас начинаются тысячи клиентов, вам необходимо сложно организовывать ввод-вывод. Вам недостаточно просто использовать треды, и просто писать в сокет, вам необходимо использовать сложные библиотеки либо eventы, которые используют разные сложные механизмы.
    Слайд:
    Проблемы классических решений при тысячах клиентов
    • Управление памятью: утекание, либо преждевременное высвобождение
    • Контроль за ресурсами клиентов
    • Хаотическое разрушение системы при сбое в одном месте
    • Ввод/вывод при обслуживании тысяч клиентов

    Что же получается? Сервер Red5 валится под сотней пользователей. Эх, тут к сожалению, не красная получилось
    image
    Уже на ста пользователях сервер валится и не обслуживает клиентов. Почему? Да потому, что он написан плохо, при его разработке люди не учитывали, вопрос ввода-вывода, и вот, он просто перестает обслуживать.

    В случае с Wowza, у нас возникают другие проблемы, которые возникали у моих клиентов — у них Вовза течет, несмотря на то, что в яве есть сборщик мусора, где-то какая-то ссылка осталась, ресурсы не освобождаются, сервер разбухает, и вот так вот страшно выглядит.
    image
    Как это получается? Ну например, у нас стриминговый сервер обслуживает еще какой-то канал доставки сообщений. Пользователь логинится, обьект, который для него был создан, регистрируется по какому-то каналу в списке, ссылка на него запоминается, тест на обьект будет держаться, пользователь отключается, но мы забыли, мы забыли убрать ссылку на него. Все.

    Его данные остались навсегда, мы не можем получить информацию, что надо отключить. И все, до рестарта сервера.
    Слайд:
    epoll/kqueue сложны для долгих соединений из-за управления памятью.
    Что же касается ввода-вывода, то механизмы epoll/kqueue, для которых есть библиотеки libevent, это единственный способ обслуживать тысячи сокетов, они очень, очень сложны, для … когда у вас начинается сложная бизнес-логика…, потому что эффективное управление памятью в event-ной модели, по-моему, безумно сложно.
    image
    Вот, получается такая конструкция с С++ным сервером. Вы гарантированно начинаете ваш рабочий день с того, что вы выгребаете core-ки, сохранившиеся за ночь на файловой системе и хорошо, если вам хватило жесткого диска.

    Корни проблем

    В чем-то корни этих проблем которые кроются, общие для традиционных решений. Во-первых, это общая память.
    image
    Вот, к сожалению, картинка опять не видна.

    Общая память, которая разделяется между всеми объектами, которые есть в системе. Кто угодно может пойти куда угодно, взять ссылку на что угодно, и в итоге, получается вот такая конструкция, когда все объекты перекрестно друг на друга ссылаются, и нам гораздо сложнее в этой ситуации контролировать память, кто и что захватил, и кому что нужно.
    image
    Надо понимать, что, эти проблемы нас не интересуют, когда мы пишем сайт на PHP. Они нас не интересуют, по той причине, что ваше приложение, которое работает при обслуживании веб-сервиса, живет одну секунду максимум. Через одну секунду, все, что оно использовало, можно уничтожить, потому, что это все становится ненужным, у нас уже новый запрос, новое соединение.
    Слайд:
    Web-подход → «пускай течет, скоро прибьем» → не работает.
    Здесь такого не будет, клиенты подключенные часами, днями и даже больше. И необходимо, чтобы ваш код код работал эффективно, не утекая, неделями.

    Erlang решает эти проблемы радикально

    Erlang оказался платформой, которая, на удивление, радикально решила эти проблемы, и практически полностью закрыла те проблемы, про которые я говорил.

    Это было сделано на 90 % из-за его концепции процессов.
    Слайд:
    Процессы
    • Параллельные потоки выполнения
    • Изолированная область памяти
    • Обмен через посылку сообщений
    • Переменные неизменяемые
    • Нет данных вне процессов
    Процессы в Erlange, это что-то типа тредов, в обычных системах. Они легковесны, они гораздо меньше места занимают, и самое важное — они абсолютно изолированы.

    Каждый процесс в Erlange, это такая коробочка, из которой ничего наружу не вытекает. И мы точно знаем, что вся память, которая есть в системе, гарантированно принадлежит какому-то процессу. Не может быть данных вне процесса. То есть всегда, если есть какой-то гигабайтный кусок памяти, вроде бы ничейный, но мы знаем, что за процесс им владеет и можем его прибить, чтобы эти данные освободить.
    Вопрос: А ведь бинари по ссылке передается между процессами?
    Ну это тонкости реализации, а на самом деле эти бинари можем отследить всегда. Они исследуются.
    Вопрос: А чем и как?
    Мы знаем, процессу известно, на какие бинари и какого размера он ссылается.

    Поэтому, что у нас получается: все данные, которые есть в системе, хранятся исключительно внутри перечислимых процессов. Можно перебрать все процессы в системе, чтобы узнать, кто сожрал всю память, и прекратить это издевательство над системой.
    Слайд:
    Все данные хранятся внутри перечислимых объектов
    Следующая особенность процессного подхода к организации данных внутри и потоков выполнения, заключается в том, что ошибки которые возникают, жестко ??? процесса. Если у нас есть ошибка, которую мы не обработали, которую мы не захотели ее перехватывать, мы решили, пуская она сыпется дальше, нас не интересует ее судьба, это фатальная ошибка, наш процесс завершается. И что самое главное, это очень-очень похоже на освобождение, уничтожение объекта, потому что это известная по времени процедура, то есть мы знаем, что раз ошибка возникла, то процесс все, прекратился. Это будет не через час, не через два дня, это будет прямо сейчас. И важно понимать, что процессы, которые заказали…, которые хотят следить за его состоянием, другие процессы, соседние, они получат об этом информацию, что их сосед умер.
    Слайд:
    Обработка ошибок
    • Их можно ловить
    • Если не ловить, то завершается процесс
    • Соседи об этом узнают через сообщения
    • Гарантированная зачистка ресурсов
    В итоге получается, что у нас можно следить за состоянием процессов. Например, мы запускаем отдельно процесс, который обслуживает соединения с пользователем, начинаем за ним следить, и если там была какая-нибудь ошибка, наша ошибка в коде, скорее всего, то процесс, который за ним следит, узнает, «ага, у нас умер процесс обслуживающий сокет». Значит, в принципе, нет дальше смысла обслуживать пользователя, все равно уже нечем его обслуживать, и надо каскадно завершить все те процессы, которые были созданы для его обслуживания.

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

    Зачем это нужно? Например у вас есть один из самых важных процессов в системе, это демон, это процесс, который слушает сокет. Он закрепился на сокет, и принимает соединения от системы. Вы можете быть уверены, что он то будет работать гарантировано, иначе вся ваша система вся может отвалится (???). Вот если он отвалился, уже нет смысла ваш сервер терзать.
    Слайд:
    Слежение за процессами
    • Связи
    • Супервизоры
    • appmon
    К сожалению, я не смогу показать на своем ноутбуке, у меня нет переходника, но я хотел бы показть такую вещь, как app monitor. Это поставляющися, опять таки с платформой механизм, который позволяет вам графически, посмотреть список всех процессов, которые есть у вас, с их деревом. То есть мы можем…, это очень полезная вещь, когда вы можете видеть, что к вам приходит пользователь, у вас создался объект под него, он запросил какие-то ресурсы, под них просто залез (???) в какие-то процессы… Пользователь уходит, процессы остаются — фактически это утечка процессов, а с помощью app monitora, все это видится очень наглядно.

    Но, к сожалению, не покажу вам. :(

    В Erlang настоящее горячее обновление кода

    А еще в эрланге есть, наверное единственное из всех существующих платформ, настоящее, горячее обновление кода. Выглядит это так — клиенты не отключаются, они продолжают работать, в случае с видеостримером, они продолжают получать видео, в случае с онлайн-играми не теряется соединение, а код уже обслуживает новый.
    Слайд:
    Без отключения клиентов!
    Других систем, которые позволяют такое делать я не знаю.

    Какие результаты использования Erlang?

    И что же в итоге получилось, после того, как я решил воспользоваться эрлангом для создания своего сервера? Получился наш видеостриминговый серве Erlyvideo, которые сейчас находится в двойке-тройке лучших, в своей области, по набору реализованных фич, по скорости развития, по стабильности и эффективности.
    Слайд:
    Erlyvideo:
    • Мультипротокольный сервер
    • Держит тысячи клиентов на одном сервере
    • Существующая инфраструктура для плагинов
    Например, совершенно нормально обслуживает тысячи клиентов с одного сервера, сейчас стоит в продакшне у BD (???) и работает.

    Оказалось, очень эффективно и просто, за счет динамической типизации языка, которая естественно, динамическая, потому что мы не можем узнать, что это за другой процесс, поэтому все общение между процессами сводится к обмену сообщениями. Поэтому этот язык… можно говорить о динамической типизации этого языка.

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

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

    В итоге, Erlyvideo прекрасно решает озвученную задачу, сервер может стоять неделями, и без рестартов и без каких-либо утечек памяти, с этим нет никаких проблем. У меня, например, даже месяцами стоит, и не пухнет, сохнарая память на той же отметке.

    Выводы

    Слайд:
    Задачи потокового видео имеют специфику, отличающую их от веба:
    • Необходимы инструменты эффективные и высокоуровневые одновременно
    • Erlang прекрасно вписывается в эту нишу
    • Практическое использование показало эффективность выбора
    В итоге, какие же выводы можно сделать из применения Erlanga для этой задачи?

    Задачи передачи потокового видео в интернете, имеются свою специфику, которая очень сильно отличает их от веба. И к сожалению, многие решения обкатанными и надежными, и такими понятными… и кажется, что вы легко найдете для них программистов, несут в себе, в своей структуре, корни проблем, которые изначально пресечены в Erlange.

    У вас не будет этих проблем, потому что… просто в силу специфики организации кода.

    Поэтому в задачу обслуживания statefull клиентов, эрланг вписывается очень хорошо. И, практическое применение, показало крайнюю эффективность этого выбора.

    Применимость erlang

    Ну понятно, что ниша потокового видео это достаточно узкая вещь, этих продуктов всего штук пять на рынке, и в принципе, этого наверное достаточно. Нет смысла писать другой сервер потокового видео на эрланге.
    Слайд:
    • Видеостриминг (erlyvideo)
    • Jabber-сервер (ejabberd)
    • Банковский процессинг (Приват Банк)
    • Онлайн игры (Online Poker)
    Однако, у него есть другие ниши применимости, например, на том же эрланге сделан самый лучший сервер Jabbera, это ejabberd, он настолько крут, что вот в яндексе, например, несмотря на жуткую антипатию к эрлангу, решили применять его, да, Яш? Сильно Гриша не любит Эрланг (bobuk)? Он очень ругался, плевался, но выбора у них не осталось — это говорит очень многое о продукте. Также, например, достоверно известно, банки делают системы банковского процессинга. Я не знаю, конечно, какие именно детали, детали конечно не раскрываются, но я знаю, что у того же Приват-банка, есть еще ряд компаний, переводящих свои системы долгоживущего процессинга на эрланг, потому что им оказывается это удобным.

    Ну и конечно, онлайн-игры. Ко мне регулярно обращаются люди, после нашего успеха с раскручиванием топовой вконтактовской игрушки, то есть обращаются люди «нам бы сделать, чтобы у нас работало хорошо и удобно».

    Я смотрю на их проблемы, и понимаю, что им стоит реализовывать свою игрушку на эрланге, скорее всего. Потому что бизнес-логики не очень много, но она очень специфичная, и все те проблемы, которые я описывал, они соскребают использую обычные технологии, рельсы там, или джаву.

    И вот даже есть онлайн-реализация покера на эрланге.

    Вопросы?

    Так что, в целом, у меня наверно все, вот такой вот доклад получился. Если у вас есть какие-нибудь вопросы, я с радостью на них отвечу.
    Слайд:


    Сессии ответов и вопросов не влезла в размер хабропубликации, поэтому ее надо искать на сайте конференции по ссылке «стенограмма».
    Share post

    Comments 82

      +1
      Запостили не весь текст «тем, что вы можете в ней много и час».
        +1
        Да, к сожалению, весь текст не влез. Я обрезал все вопросы-ответы отсюда.
        +1
        Видимо ограничение на размер статьи.
        А вообще очень интересно. Вопрос такой, ErlyVideo именно для webTV заточен и свой YouTube на нём делать не резон?
          +5
          Ютуб не резон делать на чём-либо кроме nginx (или чего-то похожего), потому что 10-минутные ролики лучше всего раздаются HTTP сервером.

          Erlyvideo нужен для более специфичных видеозадач: двухсторонняя связь, прямой эфир и т.п.
            +1
            вот только в ютуб все сложнее. Они стримают данные в зависимости от наполнения буфера, т.е. с ютуба ты качаешь файлики не на скорости канала.
              +1
              ты хочешь сказать, что их HTTP сервер учитывает скорость скачивания?

              Он же просто тупо отдает файл, всё.
                0
                Он учитывает скорость просмотра. Начало отдаётся быстро, дальше медленнее.
                  0
                  А на ютубе это разве не в плеере сделано?
          +1
          Хм. Докладчик первым же делом сообщает то, что это не видеохостинг, как написано в заголовке.
            +1
            Докладчик первым делом сообщает, что ютюб — это не стриминг. Про хостинг, вроде, не было речи.
              +1
              Тут, насколько я понял, хотели привести отличие видеохостинга (чем является ютуб) от видеостриминга. И первые же слайды это подтверждают.
            +2
            А какое сейчас максимальное количество видеопотоков может выдержать 1 сервер erlyvideo?
              +7
              Ярослав: 2500 с одного гигабитного линка раздавалось. Лично я на большем не проверял, но клиенты говорили о 4000 соединениях.
              +1
              У нас rtmpd отдавал 3 Гбита на однопроцессорном сервере и не падал :)
              Ваш проект очень интересний но для раздачи для >10k потоков без RTMFP/Stratus/Cirrus не обойтись.
              Просто при >10k потоков получается банально дорого платить за траф атацентру/Amazon'у

                0
                а что, есть успешный опыт применения rtmfp? кстати, это не единственное решение для раздачи flash через p2p — есть проект lavina.tv, где это делается с помощью плагина для браузера и специального сервера.
                  +1
                  Успешного нет — только тестинг. Плагин для браузера — нам не подходит (в случае lavina).
                0
                Можно ли использовать для аудиостриминга?
                  +1
                  Да, можно раздавать аудио через RTMP, т.е. на флешки.
                    +1
                    С недостатком указанным на erlyvideo.org/usage/flv_streams?

                    Еще вопрос, возможно глупый, так как сталкиваюсь впервые с этим.

                    Есть ли возможность сделать что-то вроде управляемого радио — т.е. отправлять команду на переключение вещания из другого источника или файла?
                      +2
                      flv_streams — это про т.н. псевдостриминг, когда иммитируется flv файл, а вместо него отдается бесконечный поток.

                      rtmp — это именно стриминговый протокол, который нигде не закешируется.

                      Управляемое радио сделать можно, у меня есть несколько различных реализаций, включая пульт микшера, с которого можно менять громкость голоса ведущего и музыки. До продакшна это всё не дошло по причине отсутствия заказчиков.
                        0
                        Спасибо за ответы.

                        А можно взглянуть на реализации или они коммерческие?
                          0
                          реализации микшера?
                          Как я сказал, «радиопульт» дальше тестового стенда не ушел.
                  –7
                  Всем хорош сервер, кроме одного — написан на Эрланге. Ну где я найду разработчика на Эрланге?

                  Чем хороши Red5/Wowza/Stratus — приложение можно разворачивать быстро и на знакомых языках.

                  Однозначно, если строить что-то могучее типа платформы видеостриминга, то Эрливидео — правильный выбор.
                  Но если кол-во юзеров менее 100-200, то проще обойтись Вовзой/Red5.

                    +7
                    Там же, где и разработчика, который в состоянии писать на Джаве под видеостриминговый сервер.

                    Это старый и очень опасный миф, что раз Wowza на Java, то вы хлоп и взяли пачку дешевых ребят из под Томска, которые всё наклепают.

                    На моей практике оказалось найти программиста на эрланге для erlyvideo для контрактной работы гораздо проще, быстрее и дешевле, чем программиста на джаве.
                      0
                      А почему сразу Томск :(
                      0
                      Ого, как кого-то задело.
                        –1
                        Даже простой обзор вокруг меня обозначает десяток разработчиков на яве/с++/перле/пхп, но ни одного на Эрланге.

                        Хотя я понимаю цель использования Эрланга — с учетом GPL использованных компонентов это единственный способ зарабатывать деньги на доработке/кастомизации.
                          +3
                          вопрос не в их наличии, а в их квалификации. Если вокруг вас ни одного программиста на эрланге, то очень вероятно, что ни одного джава-программиста, квалифицированного настолько, что бы писать под ту же Wowza.

                          Про GPL не понял.
                            –5
                            Не надо брать на себя слишком много — я вполне могу оценить квалификацию разработчиков, у которых не один успешный проект.

                            Про GPL подумайте.
                              +3
                              Как я понимаю, речь о том, что знание любого языка является «o» маленьким по сравнению с опытом и знаниями, которые нужны программисту, чтобы не налажать в многопоточной программе, работающей в режиме 24/7/365.

                              Потому что ошибки в синтаксисе выявляются сразу, и они дешевы, а тех же вариаций race conditions или утечек не счесть, и выявить их очень сложно и дорого.

                              И получается дешевле отправить разработчика учить erlang, который помешает писать неправильно, чем разрешить писать на знакомом но обычном языке, и при этом набивать кучу шишек в многопоточности за ваш счёт.
                                –2
                                В теории я, пожалуй, соглашусь. На практике возникает несколько вопросов:
                                1) Сколько времени занимает изучение эрланга до состояние на 4-? Дни? Недели? Месяцы?
                                2) Возникает вопрос — если Эрланг настолько крут, то почему используют с++/ява? Не будем про «инерцию и тупых менеджеров» — с++/ява используются потому, что экономически эффективнее.
                                3) И финальное — в «серебряные пули» я не верю. Не бывает инструментов без недостатков. Где эти недостатки у Эрланга?
                                • UFO just landed and posted this here
                                    +3
                                    1) две недели, наверное.

                                    2)… или потому что:
                                    — боятся рисковать своим местом
                                    — не знали про ерланг
                                    — сами новички в этой области, думали, что раз парень легко написал популярную flash-игрушку, то и многопоточный сервер ему по зубам
                                    — посчитали затраты на обучение языку, но не посчитали затраты на обучение concurrency и внутренним хитростям проекта.

                                    В общем тезис про экономическую эффективность выглядит очень неубедительно и поверхностно :)

                                    3) Пожалуйста. Не верьте. Но это не мешает решению заточенному под задачу быть эффективнее, чем универсальное решение. Так оно обыно и происходит.
                                    (а недостатки erlang проявляются если начать на нём писать 3d игрушки или операционки.)
                                +1
                                И успешные проекты — да хоть сто. Если эти успешные проекты не в Concurrency Programming (что весьма вероятно, так как а в этой области мало «успешных» проектов), то они никак не помогут просчитывать дедлоки и race conditions. Тут только опыт и шишки за счёт заказчика.
                                  –2
                                  Это вообще о чем? Читайте контекст — он рулез.

                                  Для написания приложений под вовзу/ред5 мне не нужен гуру распределенных высоконагруженных сервисов. Достаточно обычного ява-программера.

                                  А что, у господин Лапшин знаменит какими-то еще высоконагруженными и concurrent проектами? Или эрливидео это «опыт и шишки»?
                                    +1
                                    Да контекст рулит. Как уже говорил, «опыт и шишки» будут у любителей обычных языков.

                                    А erlang во время обучения сразу показывает как надо писать такие штука, а потом сам по себе ограничивает манёвр, затрудняя написание опасных кусков кода, из-за которых можно набить шишки:
                                    — нет расшаренной памяти — нет проблем с совместным доступом, локами, семафорами. Скажем да лёгкому распараллеливанию.
                                    — на один ресурс один процесс — скажем нет race conditions
                                    — про утечку уже говорили.
                                    — вынуждает писать код без обработки ошибок => сразу понимаешь, что процесс может упасть => вынужден использовать супервизоры => продукт получается устойчивым даже к непредвиденным ошибкам
                              +4
                              Ололо. Вы сами-то пробовали писать на Эрланге?
                              В докладе говорится о том, что начать писать на нем очень просто, и мне используемые абстракции кажутся сильно проще, чем оные в JS и Python (не говоря уже о плюсах и иже с ними).
                              Вопрос в том, стоит ли считать программистом того, кто не в силах изучить эрланг, мне кажется.
                                –2
                                А правильно — давайте считать только того программистом, кто может изучить Эрланг.

                                Самому не смешно?
                                  0
                                  А еще Лобачевский только для того развил неевклидову геометрию, чтобы потом быть монополистом в решении задач из этой области.
                                  Точно так же Форд построил конвейер по сборке машин исключительно для того, чтобы иметь монополию на запчасти и бензин (ага, овсом-то уже не покормишь).
                                  Ваша позиция, как мне кажется, основывается исключительно на предположении о том, что Вы и люди вокруг вас и сами идеальны, и используют настолько идеальные инструменты, что внесение хоть крупицы нового в эту систему принесет сплошные страдания. В то же время есть такая вещь как прогресс, сопротивление которому, как правило, приводит к не очень приятным последствиям.
                                    0
                                    Никогда не понимал и не пойму людей, которые приписывают свои мысли другим. Хотя есть простой способ — спросить.
                                      0
                                      «Хотя я понимаю цель использования Эрланга — с учетом GPL использованных компонентов это единственный способ зарабатывать деньги на доработке/кастомизации.»
                                      Очень жаль, что Вам так и не удастся понять самого себя.
                                        +1
                                        Своя версия того, что имелось ввиду, есть?
                                        Не надо стесняться ее огласить. За это не минусуют.

                                          +1
                                          Из-за особенностей моего способа восприятия текста и, возможно, формулировки Ваших фраз я не могу понять суть вопроса. Суть предъявы мне тоже до сих пор неясна.
                                            –1
                                            Ну все уже понятно.

                                            «Хотя я понимаю цель использования Эрланга — с учетом GPL использованных компонентов это единственный способ зарабатывать деньги на доработке/кастомизации.» — для понимания этой фразы требуется некоторое понимание специфики работы видео в инете всего такого. Простых выкриков «Эрланг — рулез» недостаточно.

                                            Конкретизирую — автор ЭрлиВидео не стал с нуля реализовывать полноценный стек кодеков (что разумно), а воспользовался уже готовыми компонентами имени ffmpeg. Кроме этого (мне сейчас недосуг смотреть) наверняка в ЭрлиВидео присутствуют другие GPL компоненты, которые препятствуют продаже этого продукта в виде closed-source решения.

                                            Я далек от мысли, что перед нами альтруист в лице автора ЭрлиВидео. Очевидно, человек хочет зарабатывать своим трудом деньги. Если бы использовался С++ или Ява или Питон — разработчиков куча, они сами и кастомизируют под себя ЭрлиВидео.
                                            Если продукт написан на Эрланге, то однозначно проще заказать разработчику доработку, чем искать спеца по Эрлангу+потоковому видео.

                                            Теперь понятен смысл, почему Эрланг? И почему в нем деньги?

                                            Да и лукавит автор жостко в свое презентации — ссылается на утечки памяти и общие недостатки явы и с++. Но почему-то умалчивает, что стек кодеков реализован на с/с++ и ассемблере. Почему же не на эрланге, раз он такой весь из себя?

                                              +2
                                              Внимательный читатель/слушатель мог бы найти в докладе ответы на оба Ваших вопроса.
                                              Вот, например, о закрытии исходников.
                                              А близость синтаксиса эрланга простой околочеловеческой логике делает изучение этого языка быстрым (пара дней, параллельно с изучением того кода, который нужно доработать) и приятным способом повысить свою квалификацию. Метод, конечно же, для тех, у кого нет религиозных предубеждений против функционального программирования.
                                                0
                                                Не знаю, где вы увидели вопросы. Непонятно, кому адресованы ответы.
                                                Еще более неочевидны слова о «докладе», хотя ссылка ведет на другой пост. Странная смесь.

                                                Про изучение эрланга хотелось бы не общих слов, а конкретики — «Вася начал разбирать и править код на Эрланге через Х часов или дней».
                                                +1
                                                То, что вы говорите — наглая ложь, говорящая о полном непонимании вопросов видео.

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

                                                Бред насчёт «для Red5/Wowza хватит обычного программиста» я уже неоднократно видел на практике и успешно помогал этим людям с переходом на erlyvideo.
                                                  0
                                                  «Что ж вы так убиваетесь? Вы ж так никогда не убьетесь.»

                                                  Поглядим вдумчиво на комплект ерлисервера:
                                                  ExtJS — купили лицензию или GPL?
                                                  FlowPlayer — купили лицензию ил GPL?
                                                  JQuery — MIT или GPL?
                                                  Sizzle CSS — MIT или GPL?

                                                  Смотри далее:
                                                  amf имени Руслана Бабаева — под GPL
                                                  упоминание Takumo Mori в GPL файле. Takumo Mori — это ваше второе имя?

                                                  И кто из нас врет? Научись в уважительном тоне общаться — это иногда помогает. Некоторым.

                                                  И так, между делом: куда делась лицензия на BluePrint?
                                                    +3
                                                    Чего-то мне подсказывает, что ни ExtJS, ни FlowPlayer, jQuery ни имеют ни какого отношения к стримминг серверу, и максимум могут использоваться для какой-нибудь админки или чего-нибудь такого. Или все это нужно для того, чтобы отправлять поток-видео?

                                                    При чем здесь код на Erlang для реализации стрмминга, и какие-то надстроечки для админки, которые можно поставить вместе с open source версией стрмминг сервера.

                                                    Давайте отличать уже мух от котлет и не нести чепухи. Стыдно же.
                                                      0
                                                      extjs, jwplayer, кстати, куплены.
                                                      Насчёт остального этот идиот настолько мимо, что даже обсуждать не хочется.
                                                  +2
                                                  Я думаю, если немного подумать, а не передергивать, то станет ясно, чем отличаются кодеки, плееры и ffmpeg от стримминг сервера, а так же, чем контейнер отличается от кодека. Отсюда сразу получится ответить на вопрос, а почему ffmpeg написан на Си, а не на Erlang или Python.

                                                  Если почитать какую-нибудь книжку по Эрлангу, то может в голову придти мысль (вот она уже обсуждаемая), что для целого класса серверов лучше использовать не Twisted Python (кажется ничего лучше Twisted с тех пор, когда я им пользовалось так и не появилось), а Erlang, и совсем не по той причине, что Erlang программистов меньше.
                                        0
                                        Я erlang за неделю освоил + немножко OTP. Ничего сложного, правда.
                                0
                                Используете ли вы кластеризацию beam?
                                Если нет, как вы распространяете контент от источника к конечным нодам?
                                Если да, насколько существенны сетевые лаги между нодами в стриминговых приложениях?
                                  0
                                  Нет, OTP кластеризацию я не использую, мне она оказалось не нужна.
                                  Контент перераспределяется по протоколам типа RTMP или MPEG-TS.

                                  Существенность сетевых лагов зависит от того, что гоняете. Если нужна сеть распределения контента, то скорее всего это однонаправленное вещание, а следовательно дополнительные 300 мс задержки обычно не критичны.
                                    0
                                    Спасибо. Можете ли посоветовать какой-либо проект на эрланге, в который можно было бы с пользой повонзаться, имея крайне маленький опыт разработки на этом языке?
                                      0
                                      Наверное из простых — egitd, недавно была хорошая статья про его оптимизацию, неплохо раскрывающая его кишки.

                                      Остальные проекты достаточно объёмны. И начните с задачи для себя, которую вы хотите решить.
                                        0
                                        Я понял, спасибо. Задача для себя плоха тем, что можно случайно начать использовать неудобный другим стиль написания кода, хотя это уже субъективные проблемы…
                                  0
                                  О. Еще такой вопрос.
                                  В докладе говорится о переносе вычислений в нативный код.
                                  Есть ли безопасные для виртуальной машины и в то же время производительные способы сделать это кроме написания порт-драйвера?
                                    +1
                                    Самый простой и действительно работающий способ — делается консольная программа, с которой общаешься через pipe. Накладные расходы исчезают на фоне того, чем она занимается.

                                    Например, микшер видео для конференции — это то, что пишется на C, потому что libx264. Можно поступить наивно и разместить его в том же приложении, особенно весело будет поверить во всякие Xuggler и т.п. Однако в том же libavformat/libavcodec регулярно находятся проблемы, потому что проект очень бурно развивается, следовательно эти проблемы вполне могут проехаться вам по памяти и подпортить JVM в рантайме.

                                    Шансов отладить это — ноль. Самый надежный способ такую штуку вынести наружу, кормить её данными и забирать готовое.

                                    Результат такой, что в случае падения микшера люди почти ничего не замечают.
                                    0
                                    О! Сколько недостатков у RED и Wowza расписали…

                                    А мне нравится стриминг от Amazon S3: Дёшево и сердито без заморочек на масштабирование. Пример:

                                    ru.administrating.tv (Через прокси видео не работает)
                                      +2
                                      Amazon S3 имеет много плюсов, но это ОЧЕНЬ дорого. Просто фантастически дорого: дешевле купить стойку серверов у Хетцнера, чем у Amazon.

                                      Плюс по факту S3 — это хранилище, а не CDN. Ну и всё это совершенно не имеет отношения к обсуждению. S3 — это HTTP сервер, а не «стриминг».
                                        0
                                        >Плюс по факту S3 — это хранилище, а не CDN. Ну и всё это совершенно не имеет отношения к обсуждению. S3 — это HTTP сервер, а не «стриминг».

                                        — Не совсем так.

                                        «You can create distributions to either download your content using the HTTP or HTTPS protocols, or stream your content using the RTMP protocol.»

                                        aws.amazon.com/cloudfront/

                                        P.S. ClodFront конечно не S3…
                                          0
                                          Кстати, в России тоже есть CDN — NGENIX и мы, CDNvideo
                                          0
                                          >Amazon S3 имеет много плюсов, но это ОЧЕНЬ дорого. Просто фантастически дорого: дешевле купить стойку серверов у Хетцнера, чем у Amazon.

                                          Для каких объемов трафика и рода контента, позвольте поинтересоваться?
                                            0
                                            У хетцнера 5 ТБ стоит что-то в районе 5 евро. У амазона это несравненно дороже.
                                        +1
                                        «Erlang — надежный объектный язык для создания сетевых сервисов.» — может быть он функциональный, нет?
                                          +2
                                          Обычно в термин «функциональный» вкладывают много умных концепций, подразумевая что надо их освоить и тогда они упростят программирование.
                                          В эрланге реализована лишь малая доля тех идей, которые есть во многих других функциональных языках, он проектировался прежде всего для продакшна, что бы по ночам инженеры могли спать спокойно.
                                            0
                                            Пардон, но erlang уж точно не объектный — я не просто мимо проходил, есть опыт разработки OTP систем.
                                              0
                                              Да, это не Java. Но надо отметить, что некоторая, можно сказать, извращенная, объектность в его процессах явно наблюдается.
                                                0
                                                Процессы инкапсулируют состояние. Процессы могут получать сообщения. Почему процессы не могут быть аналогами объекта?
                                                  0
                                                  Процессы в ерланге — как раз самые что ни на есть каноничные объекты, согласно каноническому определению ООП. Это уже во всяких плюсах и жавах понятие объекта извратили.
                                                    0
                                                    Говорят, Алан Кей злился когда ему эрланг показали. Напоминает «существо двуногое, прямоходящее, без перьев»
                                                    0
                                                    > erlang уж точно не объектный
                                                    Да ладно, вылитый Smalltalk, щедро смазанный прологом
                                                    0
                                                    Кстати, а что Вы скажете про Lua и Haskell? :)
                                                  +2
                                                  Отличное выступление, отличная статья. Грамотно подведено к используемому инструменты. Гармонично вписался механизм мониторинга процессов.
                                                    +1
                                                    Спасибо
                                                    0
                                                    После этого доклада на ADD взялся за изучение Erlang. Не жалею.
                                                      0
                                                      Дело полезное, специалисты востребованы.
                                                      0
                                                      Проект конечно интересный, но вот не люблю такие презентации, в которых, чтобы положительно преподнести свою разработку, а самое выбранную технологию, надо опустить другие технологии.
                                                        0
                                                          +1
                                                          nginx, кстати, в корку каждый день не падает :) Хотя написан на сях, и с epoll.

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