У нас rtmpd отдавал 3 Гбита на однопроцессорном сервере и не падал :)
Ваш проект очень интересний но для раздачи для >10k потоков без RTMFP/Stratus/Cirrus не обойтись.
Просто при >10k потоков получается банально дорого платить за траф атацентру/Amazon'у
а что, есть успешный опыт применения rtmfp? кстати, это не единственное решение для раздачи flash через p2p — есть проект lavina.tv, где это делается с помощью плагина для браузера и специального сервера.
flv_streams — это про т.н. псевдостриминг, когда иммитируется flv файл, а вместо него отдается бесконечный поток.
rtmp — это именно стриминговый протокол, который нигде не закешируется.
Управляемое радио сделать можно, у меня есть несколько различных реализаций, включая пульт микшера, с которого можно менять громкость голоса ведущего и музыки. До продакшна это всё не дошло по причине отсутствия заказчиков.
Всем хорош сервер, кроме одного — написан на Эрланге. Ну где я найду разработчика на Эрланге?
Чем хороши Red5/Wowza/Stratus — приложение можно разворачивать быстро и на знакомых языках.
Однозначно, если строить что-то могучее типа платформы видеостриминга, то Эрливидео — правильный выбор.
Но если кол-во юзеров менее 100-200, то проще обойтись Вовзой/Red5.
Там же, где и разработчика, который в состоянии писать на Джаве под видеостриминговый сервер.
Это старый и очень опасный миф, что раз Wowza на Java, то вы хлоп и взяли пачку дешевых ребят из под Томска, которые всё наклепают.
На моей практике оказалось найти программиста на эрланге для erlyvideo для контрактной работы гораздо проще, быстрее и дешевле, чем программиста на джаве.
Даже простой обзор вокруг меня обозначает десяток разработчиков на яве/с++/перле/пхп, но ни одного на Эрланге.
Хотя я понимаю цель использования Эрланга — с учетом GPL использованных компонентов это единственный способ зарабатывать деньги на доработке/кастомизации.
вопрос не в их наличии, а в их квалификации. Если вокруг вас ни одного программиста на эрланге, то очень вероятно, что ни одного джава-программиста, квалифицированного настолько, что бы писать под ту же Wowza.
Как я понимаю, речь о том, что знание любого языка является «o» маленьким по сравнению с опытом и знаниями, которые нужны программисту, чтобы не налажать в многопоточной программе, работающей в режиме 24/7/365.
Потому что ошибки в синтаксисе выявляются сразу, и они дешевы, а тех же вариаций race conditions или утечек не счесть, и выявить их очень сложно и дорого.
И получается дешевле отправить разработчика учить erlang, который помешает писать неправильно, чем разрешить писать на знакомом но обычном языке, и при этом набивать кучу шишек в многопоточности за ваш счёт.
В теории я, пожалуй, соглашусь. На практике возникает несколько вопросов:
1) Сколько времени занимает изучение эрланга до состояние на 4-? Дни? Недели? Месяцы?
2) Возникает вопрос — если Эрланг настолько крут, то почему используют с++/ява? Не будем про «инерцию и тупых менеджеров» — с++/ява используются потому, что экономически эффективнее.
3) И финальное — в «серебряные пули» я не верю. Не бывает инструментов без недостатков. Где эти недостатки у Эрланга?
2)… или потому что:
— боятся рисковать своим местом
— не знали про ерланг
— сами новички в этой области, думали, что раз парень легко написал популярную flash-игрушку, то и многопоточный сервер ему по зубам
— посчитали затраты на обучение языку, но не посчитали затраты на обучение concurrency и внутренним хитростям проекта.
В общем тезис про экономическую эффективность выглядит очень неубедительно и поверхностно :)
3) Пожалуйста. Не верьте. Но это не мешает решению заточенному под задачу быть эффективнее, чем универсальное решение. Так оно обыно и происходит.
(а недостатки erlang проявляются если начать на нём писать 3d игрушки или операционки.)
И успешные проекты — да хоть сто. Если эти успешные проекты не в Concurrency Programming (что весьма вероятно, так как а в этой области мало «успешных» проектов), то они никак не помогут просчитывать дедлоки и race conditions. Тут только опыт и шишки за счёт заказчика.
Да контекст рулит. Как уже говорил, «опыт и шишки» будут у любителей обычных языков.
А erlang во время обучения сразу показывает как надо писать такие штука, а потом сам по себе ограничивает манёвр, затрудняя написание опасных кусков кода, из-за которых можно набить шишки:
— нет расшаренной памяти — нет проблем с совместным доступом, локами, семафорами. Скажем да лёгкому распараллеливанию.
— на один ресурс один процесс — скажем нет race conditions
— про утечку уже говорили.
— вынуждает писать код без обработки ошибок => сразу понимаешь, что процесс может упасть => вынужден использовать супервизоры => продукт получается устойчивым даже к непредвиденным ошибкам
Ололо. Вы сами-то пробовали писать на Эрланге?
В докладе говорится о том, что начать писать на нем очень просто, и мне используемые абстракции кажутся сильно проще, чем оные в JS и Python (не говоря уже о плюсах и иже с ними).
Вопрос в том, стоит ли считать программистом того, кто не в силах изучить эрланг, мне кажется.
А еще Лобачевский только для того развил неевклидову геометрию, чтобы потом быть монополистом в решении задач из этой области.
Точно так же Форд построил конвейер по сборке машин исключительно для того, чтобы иметь монополию на запчасти и бензин (ага, овсом-то уже не покормишь).
Ваша позиция, как мне кажется, основывается исключительно на предположении о том, что Вы и люди вокруг вас и сами идеальны, и используют настолько идеальные инструменты, что внесение хоть крупицы нового в эту систему принесет сплошные страдания. В то же время есть такая вещь как прогресс, сопротивление которому, как правило, приводит к не очень приятным последствиям.
«Хотя я понимаю цель использования Эрланга — с учетом GPL использованных компонентов это единственный способ зарабатывать деньги на доработке/кастомизации.»
Очень жаль, что Вам так и не удастся понять самого себя.
Из-за особенностей моего способа восприятия текста и, возможно, формулировки Ваших фраз я не могу понять суть вопроса. Суть предъявы мне тоже до сих пор неясна.
«Хотя я понимаю цель использования Эрланга — с учетом GPL использованных компонентов это единственный способ зарабатывать деньги на доработке/кастомизации.» — для понимания этой фразы требуется некоторое понимание специфики работы видео в инете всего такого. Простых выкриков «Эрланг — рулез» недостаточно.
Конкретизирую — автор ЭрлиВидео не стал с нуля реализовывать полноценный стек кодеков (что разумно), а воспользовался уже готовыми компонентами имени ffmpeg. Кроме этого (мне сейчас недосуг смотреть) наверняка в ЭрлиВидео присутствуют другие GPL компоненты, которые препятствуют продаже этого продукта в виде closed-source решения.
Я далек от мысли, что перед нами альтруист в лице автора ЭрлиВидео. Очевидно, человек хочет зарабатывать своим трудом деньги. Если бы использовался С++ или Ява или Питон — разработчиков куча, они сами и кастомизируют под себя ЭрлиВидео.
Если продукт написан на Эрланге, то однозначно проще заказать разработчику доработку, чем искать спеца по Эрлангу+потоковому видео.
Теперь понятен смысл, почему Эрланг? И почему в нем деньги?
Да и лукавит автор жостко в свое презентации — ссылается на утечки памяти и общие недостатки явы и с++. Но почему-то умалчивает, что стек кодеков реализован на с/с++ и ассемблере. Почему же не на эрланге, раз он такой весь из себя?
Внимательный читатель/слушатель мог бы найти в докладе ответы на оба Ваших вопроса. Вот, например, о закрытии исходников.
А близость синтаксиса эрланга простой околочеловеческой логике делает изучение этого языка быстрым (пара дней, параллельно с изучением того кода, который нужно доработать) и приятным способом повысить свою квалификацию. Метод, конечно же, для тех, у кого нет религиозных предубеждений против функционального программирования.
Не знаю, где вы увидели вопросы. Непонятно, кому адресованы ответы.
Еще более неочевидны слова о «докладе», хотя ссылка ведет на другой пост. Странная смесь.
Про изучение эрланга хотелось бы не общих слов, а конкретики — «Вася начал разбирать и править код на Эрланге через Х часов или дней».
«Что ж вы так убиваетесь? Вы ж так никогда не убьетесь.»
Поглядим вдумчиво на комплект ерлисервера:
ExtJS — купили лицензию или GPL?
FlowPlayer — купили лицензию ил GPL?
JQuery — MIT или GPL?
Sizzle CSS — MIT или GPL?
Смотри далее:
amf имени Руслана Бабаева — под GPL
упоминание Takumo Mori в GPL файле. Takumo Mori — это ваше второе имя?
И кто из нас врет? Научись в уважительном тоне общаться — это иногда помогает. Некоторым.
И так, между делом: куда делась лицензия на BluePrint?
Чего-то мне подсказывает, что ни ExtJS, ни FlowPlayer, jQuery ни имеют ни какого отношения к стримминг серверу, и максимум могут использоваться для какой-нибудь админки или чего-нибудь такого. Или все это нужно для того, чтобы отправлять поток-видео?
При чем здесь код на Erlang для реализации стрмминга, и какие-то надстроечки для админки, которые можно поставить вместе с open source версией стрмминг сервера.
Давайте отличать уже мух от котлет и не нести чепухи. Стыдно же.
Я думаю, если немного подумать, а не передергивать, то станет ясно, чем отличаются кодеки, плееры и ffmpeg от стримминг сервера, а так же, чем контейнер отличается от кодека. Отсюда сразу получится ответить на вопрос, а почему ffmpeg написан на Си, а не на Erlang или Python.
Если почитать какую-нибудь книжку по Эрлангу, то может в голову придти мысль (вот она уже обсуждаемая), что для целого класса серверов лучше использовать не Twisted Python (кажется ничего лучше Twisted с тех пор, когда я им пользовалось так и не появилось), а Erlang, и совсем не по той причине, что Erlang программистов меньше.
Используете ли вы кластеризацию beam?
Если нет, как вы распространяете контент от источника к конечным нодам?
Если да, насколько существенны сетевые лаги между нодами в стриминговых приложениях?
Нет, OTP кластеризацию я не использую, мне она оказалось не нужна.
Контент перераспределяется по протоколам типа RTMP или MPEG-TS.
Существенность сетевых лагов зависит от того, что гоняете. Если нужна сеть распределения контента, то скорее всего это однонаправленное вещание, а следовательно дополнительные 300 мс задержки обычно не критичны.
Спасибо. Можете ли посоветовать какой-либо проект на эрланге, в который можно было бы с пользой повонзаться, имея крайне маленький опыт разработки на этом языке?
Я понял, спасибо. Задача для себя плоха тем, что можно случайно начать использовать неудобный другим стиль написания кода, хотя это уже субъективные проблемы…
О. Еще такой вопрос.
В докладе говорится о переносе вычислений в нативный код.
Есть ли безопасные для виртуальной машины и в то же время производительные способы сделать это кроме написания порт-драйвера?
Самый простой и действительно работающий способ — делается консольная программа, с которой общаешься через pipe. Накладные расходы исчезают на фоне того, чем она занимается.
Например, микшер видео для конференции — это то, что пишется на C, потому что libx264. Можно поступить наивно и разместить его в том же приложении, особенно весело будет поверить во всякие Xuggler и т.п. Однако в том же libavformat/libavcodec регулярно находятся проблемы, потому что проект очень бурно развивается, следовательно эти проблемы вполне могут проехаться вам по памяти и подпортить JVM в рантайме.
Шансов отладить это — ноль. Самый надежный способ такую штуку вынести наружу, кормить её данными и забирать готовое.
Результат такой, что в случае падения микшера люди почти ничего не замечают.
Обычно в термин «функциональный» вкладывают много умных концепций, подразумевая что надо их освоить и тогда они упростят программирование.
В эрланге реализована лишь малая доля тех идей, которые есть во многих других функциональных языках, он проектировался прежде всего для продакшна, что бы по ночам инженеры могли спать спокойно.
Процессы в ерланге — как раз самые что ни на есть каноничные объекты, согласно каноническому определению ООП. Это уже во всяких плюсах и жавах понятие объекта извратили.
Проект конечно интересный, но вот не люблю такие презентации, в которых, чтобы положительно преподнести свою разработку, а самое выбранную технологию, надо опустить другие технологии.
Разработка видеохостинга на Erlang