Comments 26
Интересная штука, но всё таки больше склонен к тому что Java больше подойдет для этого(я имею ввиду вместо Python).
Хотяя… в общеи настоящие джедаи конечно не меняют своего мнения, но впринципе с Java разработка будет быстрее, а в этом случае это делается именно для того чтобы сделать на Python, а не чтобы сделать быстрее. Запутался :) В общем всё круто, обязательно попробую.
Я не думаю, что разработка может быть быстрее на Java или каком-то еще языке программирования. Современные framework'и дают примерно равное время разработки (объем усилий).
Это делается на Python, потому что для меня так удобнее. Я не вижу недостатков такого решения (или знаю как такие недостатки обойти).
Это делается на Python, потому что для меня так удобнее. Я не вижу недостатков такого решения (или знаю как такие недостатки обойти).
GIL не сильно смущает? Как он влияет на производительность?
Сам сервер однопотоковый, это сильно упрощает дизайн и облегчает производительность (event-driven). RTMP как таковой с трудом можно разделить на нормальную многопоточную обработку, в отдельный поток можно вынести независимую задачу (например, перекодирование видео). План состоит в создании автоматически (или полуавтоматически) кластеризуемого решения. Тогда на одном сервере запускаем столько FMSPy, сколько там ядер. Используем столько серверов, сколько нам нужно. Все это работает как единый организм, распределяя нагрузку внутри себя так, чтобы все сервера были загружены примерно одинаково.
Так что нет, GIL не смущает.
Так что нет, GIL не смущает.
И когда допишут стриминг с камеры/сервера, сколько % она по сравнению с red5 выдаст?
Пока не допишем, ясно не будет. Целью является сопоставимая или лучшая производительность. Хотя непосредственно оптимизация в планах отложена на чуть более поздний этап оп времени.
Nerezus, вы можете помочь! Если не непосредственно участием в разработке, то, например, организацией тестирования производительности. Мы (все вместе) смогли бы несомненно сделать его лучше.
Nerezus, вы можете помочь! Если не непосредственно участием в разработке, то, например, организацией тестирования производительности. Мы (все вместе) смогли бы несомненно сделать его лучше.
Мне уже нравится идея!
Если нужна помощь в тестирование, то я могу помочь :)
Если нужна помощь в тестирование, то я могу помочь :)
Тестируйте, пожалуйста, устанавливайте, пробуйте, ищите баги и т.п.! Все, что получится, пишите в трекер на fmspy.org/ в виде тикетов. (Чтобы создать тикет, надо зарегистрироваться). Спасибо!
UFO just landed and posted this here
Ну, наверное, это не совсем то, что должно входить в ядро FMSPy. Это типичная задача для приложения к FMSPy: мы получаем по RTMP потоковый звук от пользователя, на сервере проделываем микширование и выдаем (публикуем) в качестве стрима. В FMSPy должны быть все возможности для этого: захват живого стрима, публикация стрима. Микширование и кодирование/декодирование потока, наверное, будет выходить за рамки FMSPy, но для этого стоить использовать готовые возможности Python, например, интерфейс с GStreamer.
Спасибо! Полезное дело.
Сколько сейчас разработчиков вовлечено в проект?
1 (одна) шт. :)
Документацию для разработчиков побольше.
Майкл Клишин очень давно зарекался портировать Red5 на руби (или написать с нуля, в подробностях не уверен) — тогда я совсем слабо представлял цель подобного шага.
И сейчас мне интересен вопрос, а какова всё-таки цель проекта? Почему не Red5 или Wowza (хоть он и платный, но с божескими ценами и умеет H.264, а не только сраный nellymoser)
И сейчас мне интересен вопрос, а какова всё-таки цель проекта? Почему не Red5 или Wowza (хоть он и платный, но с божескими ценами и умеет H.264, а не только сраный nellymoser)
Если брать Wowza/FMS — все-таки есть уверенность, что нужно open-source решение, которое бы позволяло технологию вперед. У FMS/Wowza есть свои проблемы с надежностью и не всегда полной поддержкой.
Если брать Red5/rtmpy/Milenia Grafter и другие open-source проекты: Red5 — тормозит и глючит (опыт реального использования под нагрузкой). С моей точки зрения это монстр, который может жить только в руках создателей. Rtmpy — на начальном этапе развития, у FMSPy есть общий код с ним, близкие проекты. Но путь Rtmpy меня не устраивает. Milenia как-то тихо загибается в непонятном пути развития.
RTMP — очень полезная технология, которая может иметь множество применений. Нужно только ее развитие. FMSPy — это не только сервер RTMP, это еще и протокол RTMP, который можно использовать в любом Twisted-приложении.
Если брать Red5/rtmpy/Milenia Grafter и другие open-source проекты: Red5 — тормозит и глючит (опыт реального использования под нагрузкой). С моей точки зрения это монстр, который может жить только в руках создателей. Rtmpy — на начальном этапе развития, у FMSPy есть общий код с ним, близкие проекты. Но путь Rtmpy меня не устраивает. Milenia как-то тихо загибается в непонятном пути развития.
RTMP — очень полезная технология, которая может иметь множество применений. Нужно только ее развитие. FMSPy — это не только сервер RTMP, это еще и протокол RTMP, который можно использовать в любом Twisted-приложении.
Стриминг бы побыстрее :)
wow! акуительно.
Я уже давно имею дело с Wowza Media Server на работе. Минусов практически нет.
Imho, вот что важно реализовать в FMSPy:
1. Возможность переопределять как методы play(), publish() и т.д. так и события.
2. Ретрансляция. Это очень важно.
3. Многопоточность, минимальные блокировки.
4. SharedObject'ы.
5. Поддержка записи в flv.
Ориентироваться лучше на Wowza.
Imho, вот что важно реализовать в FMSPy:
1. Возможность переопределять как методы play(), publish() и т.д. так и события.
2. Ретрансляция. Это очень важно.
3. Многопоточность, минимальные блокировки.
4. SharedObject'ы.
5. Поддержка записи в flv.
Ориентироваться лучше на Wowza.
Судя по роадмэпу, работы остановились? :(
Sign up to leave a comment.
FMSPy, релиз Alpha (0.1)