Андрюха, я понял чем ты налошил: надо было делать не SphinxQL, а расширяемый XML язык, который бы ходил по SOAP-у в Corba транспорте. Тогда тебе проблема как шарить данные между соседними тредами показалась бы совершенно незначительной =)
Обычно в термин «функциональный» вкладывают много умных концепций, подразумевая что надо их освоить и тогда они упростят программирование.
В эрланге реализована лишь малая доля тех идей, которые есть во многих других функциональных языках, он проектировался прежде всего для продакшна, что бы по ночам инженеры могли спать спокойно.
Самый простой и действительно работающий способ — делается консольная программа, с которой общаешься через pipe. Накладные расходы исчезают на фоне того, чем она занимается.
Например, микшер видео для конференции — это то, что пишется на C, потому что libx264. Можно поступить наивно и разместить его в том же приложении, особенно весело будет поверить во всякие Xuggler и т.п. Однако в том же libavformat/libavcodec регулярно находятся проблемы, потому что проект очень бурно развивается, следовательно эти проблемы вполне могут проехаться вам по памяти и подпортить JVM в рантайме.
Шансов отладить это — ноль. Самый надежный способ такую штуку вынести наружу, кормить её данными и забирать готовое.
Результат такой, что в случае падения микшера люди почти ничего не замечают.
вопрос не в их наличии, а в их квалификации. Если вокруг вас ни одного программиста на эрланге, то очень вероятно, что ни одного джава-программиста, квалифицированного настолько, что бы писать под ту же Wowza.
Нет, OTP кластеризацию я не использую, мне она оказалось не нужна.
Контент перераспределяется по протоколам типа RTMP или MPEG-TS.
Существенность сетевых лагов зависит от того, что гоняете. Если нужна сеть распределения контента, то скорее всего это однонаправленное вещание, а следовательно дополнительные 300 мс задержки обычно не критичны.
Там же, где и разработчика, который в состоянии писать на Джаве под видеостриминговый сервер.
Это старый и очень опасный миф, что раз Wowza на Java, то вы хлоп и взяли пачку дешевых ребят из под Томска, которые всё наклепают.
На моей практике оказалось найти программиста на эрланге для erlyvideo для контрактной работы гораздо проще, быстрее и дешевле, чем программиста на джаве.
flv_streams — это про т.н. псевдостриминг, когда иммитируется flv файл, а вместо него отдается бесконечный поток.
rtmp — это именно стриминговый протокол, который нигде не закешируется.
Управляемое радио сделать можно, у меня есть несколько различных реализаций, включая пульт микшера, с которого можно менять громкость голоса ведущего и музыки. До продакшна это всё не дошло по причине отсутствия заказчиков.
смотри, очень важная тема — получить список процессов и их регистрацию напрямую из ets таблицы.
gproc лезет через сервер к содержимому таблицы или как?
Он же просто тупо отдает файл, всё.
В эрланге реализована лишь малая доля тех идей, которые есть во многих других функциональных языках, он проектировался прежде всего для продакшна, что бы по ночам инженеры могли спать спокойно.
Плюс по факту S3 — это хранилище, а не CDN. Ну и всё это совершенно не имеет отношения к обсуждению. S3 — это HTTP сервер, а не «стриминг».
Например, микшер видео для конференции — это то, что пишется на C, потому что libx264. Можно поступить наивно и разместить его в том же приложении, особенно весело будет поверить во всякие Xuggler и т.п. Однако в том же libavformat/libavcodec регулярно находятся проблемы, потому что проект очень бурно развивается, следовательно эти проблемы вполне могут проехаться вам по памяти и подпортить JVM в рантайме.
Шансов отладить это — ноль. Самый надежный способ такую штуку вынести наружу, кормить её данными и забирать готовое.
Результат такой, что в случае падения микшера люди почти ничего не замечают.
В erlyvideo нет чужих GPL компонент, так что прежде чем раззевать варежку, стоит поглядеть самостоятельно.
Бред насчёт «для Red5/Wowza хватит обычного программиста» я уже неоднократно видел на практике и успешно помогал этим людям с переходом на erlyvideo.
Про GPL не понял.
Остальные проекты достаточно объёмны. И начните с задачи для себя, которую вы хотите решить.
Как я сказал, «радиопульт» дальше тестового стенда не ушел.
Контент перераспределяется по протоколам типа RTMP или MPEG-TS.
Существенность сетевых лагов зависит от того, что гоняете. Если нужна сеть распределения контента, то скорее всего это однонаправленное вещание, а следовательно дополнительные 300 мс задержки обычно не критичны.
Это старый и очень опасный миф, что раз Wowza на Java, то вы хлоп и взяли пачку дешевых ребят из под Томска, которые всё наклепают.
На моей практике оказалось найти программиста на эрланге для erlyvideo для контрактной работы гораздо проще, быстрее и дешевле, чем программиста на джаве.
rtmp — это именно стриминговый протокол, который нигде не закешируется.
Управляемое радио сделать можно, у меня есть несколько различных реализаций, включая пульт микшера, с которого можно менять громкость голоса ведущего и музыки. До продакшна это всё не дошло по причине отсутствия заказчиков.
Erlyvideo нужен для более специфичных видеозадач: двухсторонняя связь, прямой эфир и т.п.
gproc лезет через сервер к содержимому таблицы или как?