Требования к дискам имеют место быть лишь при использовании HLS. Собственно требования напряму. зависят от вашего потока :) Вообще логичнее размещать HLS location в tmpfs.
Полностью с вами согласен. Технологические стартапы — это другая вселенная. И основатели такого стартапа должны быть ключевыми людьми с технологической точки зрения. Стартап — это не (только) идея. Много раз приходилось слышать от бизнесменов, что идея ничего не стоит. В первую очередь стартап — это технологии, знания и команда. Так не может быть что вы придумали идею, нашли денег и набрали исполнителей по объявлению. Это работает для pets.com, но не сработало бы для google и linux.
да, конечно.
для этого вы можете либо
— использовать ffmpeg с правильными ключиками для захвата с камеры и передачи по rtmp на сервер
— либо использовать флешку — например старую версию jwplayer с возможностью захвата видео (в новой версии такой возможности нет). эта версия лежит у меня в примерах. можете написать свой flash-апплет
1) сначала с HLS разберусь, потом посмотрим
2) ваш вопрос теоретический или применительно к сабжу? HLS это и есть MPEG-TS, только разрезанный. Есть программа segmenter, которая может нарезать ваш MPEG-TS и создать плейлист m3u8. Все это и есть HLS. Это все конечно не относится к live-потоку.
Я знаю. Но появится проблема синхронизации. И это еще большой вопрос — что лучше — синхронизация или сериализация (=ретрансляция). Я думаю, второе гораздо лучше. Надо, конечно, сделать внутренюю ретрансляцию прозрачной для пользователя.
Но, еще раз повторю, вы еще попытайтесь упереться в проц. Если у вас pentium4 с 10G сетевухой, то именно так и произойдет. На ядре современного Xeon и 2G сетевухой такой проблемы просто нет.
1) Задействовать все ядра можно — надо настроить ретрансляцию потоков. Сейчас с этим придется повозиться, но в будущем я сделаю так, чтобы это было проще.
2) Очень вероятно (зависит конечно от вашего железа), даже на одном ядре вы упретесь в сеть, а не в проц.
3) Остальные ядра можно использовать для перекодирования (автоматический запуск ffmpeg, об этом упоминалось в статье)
Сергей спасибо за статью. Спрашивайте кому интересно — отвечу на вопросы. Я автор прокета. В будущем планирую написать более развернутую статью по модулю.
Лично я считаю, что если у вас в системе стоит одна актуальная версия libmysqlclient и вы ее (одну и ту же) везде используете, то это хорошо и удобно. Но вы можете считать иначе и перекомпиливать ее при обновлении. Это тоже решение, и я его, конечно, не отрицаю. Просто я расказал о другом решении.
Как раз затем, чтобы не перекомпиливать. Кстати сам клиент libmysqlclient написан так, что если есть желание перекомпиливать, ему можно достаточно удобно «подсунуть» нужные реализации функций ввода-вывода, они там удобо собраны в одну структуру и зовутся всегда через нее. Но это уже совсем другая история.
Происходит. Но тогда, когда переключение контекста не нужно, вызовы проксируются дальше — в libc. Например, в перехваченном read происходит вызов настоящего read и в некоторых случаях мы сразу же возвращаем его результат, ничего не переключаем.
Собственно, есть модуль nginx-mtask-module, который и делает ровно это в отрыве от конкретной библиотеки. Но, конечно, в каждом конкретном случае надо смотреть на библиотеку, что она там зовет.
Например так:
Представьте, что у вашего проекта куча пользователей, которые «живут» на разных бекендах (оставим за скобками смысл самого проекта, пусть у них там хранилище какое-нибудь). Вопрос — как хранить соответствие «пользователь-бекенд»? Самое простое решение — использовать хеш от имени. Но иногда (довольно часто) это не подходит и нужно хранить индивидуальные соответствия. Вот при помощи такого модуля вы можете получать номер бекенда из базы данных и сразу же проксировать соединение на нужный бекенд.
Или представьте, что у вы хотите проксировать соединение на скрипт, у которого нет доступа к БД (или вы не хотите давать ему такой доступ, или это не ваш адрес и вы вообще ничего не можете кроме как проксировать туда). Вот берете и передаете ему в аргументах все, что нужно, предварительно получив это из бд.
Еще пример — вы хотите регистрировать в БД все обращения по какому-либо урлу. Добавляете подзапрос на INSERT и проксируете как ни в чем не бывало. Что-то похожее делают спамеры, когда вы смотрите на их картинки во входящей почте. После этого они точно знают, что почту вы читаете и шлют вам спам с удвоенной силой.
Ну и самый общий случай — вообще логику многих веб-приложений можно частично реализовывать в NGINX, доступ к MySQL расширяет возможности таких «встроенных» приложений.
Сами локейшины с запросами могут быть закрыты для обычных юзеров (при помощи internal). Обращаться к ним проще всего через подзапросы или проксировать на них клиентские соединения с нужными проверенными аргументами.
а звука у вас нет скорее всего потому, что jwplayer кривой :)
у меня тоже проблема со звуком с ним.
а по поводу документации, ее пока нет.
есть большой README, где примеры и комментарии к ним.
дока будет как только у меня дойдут руки.
вероятно, у вас где-то прописан localhost
для этого вы можете либо
— использовать ffmpeg с правильными ключиками для захвата с камеры и передачи по rtmp на сервер
— либо использовать флешку — например старую версию jwplayer с возможностью захвата видео (в новой версии такой возможности нет). эта версия лежит у меня в примерах. можете написать свой flash-апплет
еще, вероятно, vlc способен на такие вещания.
2) ваш вопрос теоретический или применительно к сабжу? HLS это и есть MPEG-TS, только разрезанный. Есть программа segmenter, которая может нарезать ваш MPEG-TS и создать плейлист m3u8. Все это и есть HLS. Это все конечно не относится к live-потоку.
Но, еще раз повторю, вы еще попытайтесь упереться в проц. Если у вас pentium4 с 10G сетевухой, то именно так и произойдет. На ядре современного Xeon и 2G сетевухой такой проблемы просто нет.
Пушить поток можно конечно. Берете и пушите :)
2) Очень вероятно (зависит конечно от вашего железа), даже на одном ядре вы упретесь в сеть, а не в проц.
3) Остальные ядра можно использовать для перекодирования (автоматический запуск ffmpeg, об этом упоминалось в статье)
Представьте, что у вашего проекта куча пользователей, которые «живут» на разных бекендах (оставим за скобками смысл самого проекта, пусть у них там хранилище какое-нибудь). Вопрос — как хранить соответствие «пользователь-бекенд»? Самое простое решение — использовать хеш от имени. Но иногда (довольно часто) это не подходит и нужно хранить индивидуальные соответствия. Вот при помощи такого модуля вы можете получать номер бекенда из базы данных и сразу же проксировать соединение на нужный бекенд.
Или представьте, что у вы хотите проксировать соединение на скрипт, у которого нет доступа к БД (или вы не хотите давать ему такой доступ, или это не ваш адрес и вы вообще ничего не можете кроме как проксировать туда). Вот берете и передаете ему в аргументах все, что нужно, предварительно получив это из бд.
Еще пример — вы хотите регистрировать в БД все обращения по какому-либо урлу. Добавляете подзапрос на INSERT и проксируете как ни в чем не бывало. Что-то похожее делают спамеры, когда вы смотрите на их картинки во входящей почте. После этого они точно знают, что почту вы читаете и шлют вам спам с удвоенной силой.
Ну и самый общий случай — вообще логику многих веб-приложений можно частично реализовывать в NGINX, доступ к MySQL расширяет возможности таких «встроенных» приложений.