Pull to refresh

Comments 82

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поглядим вдумчиво на комплект ерлисервера:
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 версией стрмминг сервера.

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

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

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

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

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

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

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

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

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

Плюс по факту S3 — это хранилище, а не CDN. Ну и всё это совершенно не имеет отношения к обсуждению. S3 — это HTTP сервер, а не «стриминг».
>Плюс по факту 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…
Кстати, в России тоже есть CDN — NGENIX и мы, CDNvideo
>Amazon S3 имеет много плюсов, но это ОЧЕНЬ дорого. Просто фантастически дорого: дешевле купить стойку серверов у Хетцнера, чем у Amazon.

Для каких объемов трафика и рода контента, позвольте поинтересоваться?
У хетцнера 5 ТБ стоит что-то в районе 5 евро. У амазона это несравненно дороже.
«Erlang — надежный объектный язык для создания сетевых сервисов.» — может быть он функциональный, нет?
Обычно в термин «функциональный» вкладывают много умных концепций, подразумевая что надо их освоить и тогда они упростят программирование.
В эрланге реализована лишь малая доля тех идей, которые есть во многих других функциональных языках, он проектировался прежде всего для продакшна, что бы по ночам инженеры могли спать спокойно.
Пардон, но erlang уж точно не объектный — я не просто мимо проходил, есть опыт разработки OTP систем.
Да, это не Java. Но надо отметить, что некоторая, можно сказать, извращенная, объектность в его процессах явно наблюдается.
Процессы инкапсулируют состояние. Процессы могут получать сообщения. Почему процессы не могут быть аналогами объекта?
Процессы в ерланге — как раз самые что ни на есть каноничные объекты, согласно каноническому определению ООП. Это уже во всяких плюсах и жавах понятие объекта извратили.
Говорят, Алан Кей злился когда ему эрланг показали. Напоминает «существо двуногое, прямоходящее, без перьев»
> erlang уж точно не объектный
Да ладно, вылитый Smalltalk, щедро смазанный прологом
Кстати, а что Вы скажете про Lua и Haskell? :)
Отличное выступление, отличная статья. Грамотно подведено к используемому инструменты. Гармонично вписался механизм мониторинга процессов.
После этого доклада на ADD взялся за изучение Erlang. Не жалею.
Дело полезное, специалисты востребованы.
Проект конечно интересный, но вот не люблю такие презентации, в которых, чтобы положительно преподнести свою разработку, а самое выбранную технологию, надо опустить другие технологии.
nginx, кстати, в корку каждый день не падает :) Хотя написан на сях, и с epoll.
Only those users with full accounts are able to leave comments. Log in, please.