Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 99
здорово что хлс сделан! осталось еще сильверлайт прикрутить и будет универсальный комбайн.
А требования к дисковой какие? Сколько иопсов генерится при двухгигабитной отдаче?
nginx aio поддерживается?
нет
Жаль. При сильных нагрузках на дисковую помогает реально. Без него как в дисковую упирается сервер, сильно снижается скорость отдачи.
простите, а чем именно aio помогает, если мы упёрлись в диски?
Позволяет не блокировать процесс нгинкса на время операции ввода-вывода.
Т.е. в случае без аио процесс ждёт выполнения операции чтения или записи с диска, вместо отдачи статики например из озу.
Т.е. в случае без аио процесс ждёт выполнения операции чтения или записи с диска, вместо отдачи статики например из озу.
ну aio в linux требует открытия файла с O_DIRECT, так что никакого кеширования в VFS у вас не будет.
на freebsd с этим лучше.
на freebsd с этим лучше.
Кроме того, открытие файла в Linux в любом случае синхронно. При большой иерархии это имеет значение, получите кучу синхронных рандомных сиков. А при синхронном чтении через пейджкеш срабатывает readahead, так что в реальные тормоза не такие уж и большие.
ну, не каждый open() приводит к сикам. и речь не о синхронном чтении, а о O_DIRECT.
The whole notion of «direct IO» is totally braindamaged. Just say no.
This is your brain: O
This is your brain on O_DIRECT:.
Any questions?
I should have fought back harder. There really is no valid reason for EVER
using O_DIRECT. You need a buffer whatever IO you do, and it might as well
be the page cache. There are better ways to control the page cache than
play games and think that a page cache isn't necessary.
So don't use O_DIRECT. Use things like madvise() and posix_fadvise()
instead.
Linus
The whole notion of «direct IO» is totally braindamaged. Just say no.
This is your brain: O
This is your brain on O_DIRECT:.
Any questions?
I should have fought back harder. There really is no valid reason for EVER
using O_DIRECT. You need a buffer whatever IO you do, and it might as well
be the page cache. There are better ways to control the page cache than
play games and think that a page cache isn't necessary.
So don't use O_DIRECT. Use things like madvise() and posix_fadvise()
instead.
Linus
Кстати одна дама из команды разработчиков ядра несколько лет назад расшила таки синхронные операции ввода-вывода с использованием т.н. retry-model. Т.е. вместо ожидания появления на странице прочитанных с блочного устройства данных у нее происходил полный возврат с некоторым кодом (готово- не готово). Таким образом, у нее заработали асинхронные операции через пейджкеш. Но ее патч выкинули в конце концов.
Ну я глубоко не копал, но эффект проседания скорости отдачи при 100% нагрузке дисковой наблюдал на практике. Проседало сильно, примерно на 30%. Centos 5.8
проще и правильнее воркеров побольше завести.
тем более, что при вышеописанной ситуации у вас уже куда большие проблемы имеются и решать надо их(например, через flashcache).
тем более, что при вышеописанной ситуации у вас уже куда большие проблемы имеются и решать надо их(например, через flashcache).
Артур, спасибо как за само решение,
так и за статью: технология вещания расписана очень позновательно.
при использовании обязательно возникнут вопросы.
так и за статью: технология вещания расписана очень позновательно.
при использовании обязательно возникнут вопросы.
Отличное решение, и очень доступное!
Скажите, а возможно ли вещать из MJPEG-источника?
Скажите, а возможно ли вещать из MJPEG-источника?
Вы про ip-камеру?
Используйте ffmpeg, который будет читать mjpeg, перекодировать и вещать на сервер.
Как-то так:
Используйте ffmpeg, который будет читать mjpeg, перекодировать и вещать на сервер.
Как-то так:
ffmpeg -i http://camera.example.com/cam.mpjg -c:v libx264 -an -f flv rtmp://localhost/myapp/mystreamКласс, попробую реализовать. А то камеру дёргают 4 клиента одновременно и кладут её…
простое проксирование http в случае с ip камерой скорее всего поможет.
Увы, только вещание — при проксировании на каждого клиента поднимается отдельный поток на камеру — и она падает…
не спасёт. надо вещать в hls и использовать кеширование на уровне nginx.
Ваш HLS нужен только фанбоям одной фирмочки из купертино, для устройств с закругленными уголками. Во всех остальных случаях вещать в HLS не надо.
FYI: hls умеет играть vlc, html5-плеер в android 4, jwplayer. ну и яблочные продукты.
ваша альтернатива? расскажете про mpeg dash, который чёрт знает когда появится?
ваша альтернатива? расскажете про mpeg dash, который чёрт знает когда появится?
Если какой-то плеер умеет играть HLS, то это не значит, то он больше ничего не умеет. Единственное место, где нужен HLS — это говнодевайсы с закругленными уголками. Во всем остальном мире HLS — это нестандартное решение, которое опционально поддерживают некоторые продукты, причем делают это на свой страх и риск.
О альтернативах я кратенько писал: habrahabr.ru/post/153817/
Про jwplayer вообще смешно, пойду тоже какую-то хрень на флеше сделаю, может быть ее тоже будут приводить в аргументах.
О альтернативах я кратенько писал: habrahabr.ru/post/153817/
Про jwplayer вообще смешно, пойду тоже какую-то хрень на флеше сделаю, может быть ее тоже будут приводить в аргументах.
Не посдкажите как с помощью этого модуля проще всего транслировать очередь из видео-файлов?
Интересно, планируется ли поддержка воспроизведения VOD через HLS с нарезкой на фрагменты на лету. Как это делает вовза. Было бы здорово.
Я думаю над этим. Но изначально цель была имнно в live вещании. Строго говоря, для VOD/HLS и медиа-сервер не нужен.
Но тем не менее, nginx-rtmp уже и не только лайв и не только rtmp. И как раз этой маленькой фичи не хватает для получения медиакомбайна.
А на самом деле продукт замечательный, присматриваемся к возможности использовании его на продакшне в CDNе…
А на самом деле продукт замечательный, присматриваемся к возможности использовании его на продакшне в CDNе…
Поддерживаю. Очень хочется такую фичу, чтобы была радость для iPad-ов без необходимости хранения дополнительной кучи чанков на сервере.
Очень круто! red5 слишком сложен и тяжел для моих целей, а вот такой модуль — то что нужно. Сейчас переделываю своё приложение и возник вопрос — в пределах одного соединения red5 позволял одновременно производить публикацию live-потока и воспроизводить его же (пытаюсь сделать loopback с вебкамеры, идущий через сервер — для тестовых целей). При использовании данного модуля — публикация проходит, что видно при использовании record, но поток не воспроизводится. Хотел узнать — было ли так задумано. Хотя, мне это не мешает — просто отдаю и принимаю поток через два разных соединения.
Отличный модуль.
Отличный модуль.
Так как в гугле меня забанили, а на контакты вы не отвечаете, то спрошу здесь.
Во-первых, как мне отловить конец стрима?
Клиент получает NetStream.Play.Start и потом с переменным успехом NetStream.Buffer.Full и NetStream.Buffer.Empty
События Stop или Unpublish я не получаю, хотя при этом поток-источник может рватся любое количество раз.
В принципе, в самом флеш-плеере все хорошо, а вот rtmpdump (и мое приложение с librtmp) от такого сходят с ума и не могут доливать поток после того, как тот был возобновлен. Особенно плохо моему приложению, которое не может дождаться конца потока. В принципе, можно было бы выставить таймаут, но это не вариант для живых аудиотрансляций — флеш при пропадании звука (уменьшении амплитуды сигнала меньше порогового уровня) просто перестает отсылать байтики — стрим вроде как и есть, он НЕ закрыт, но потока и нет. Отличить от случая, когда клиент закрыл браузер, я никак не могу.
Далее, дабы далеко не ходить, сама librtmp иногда сыпит ошибками:
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: HandleMetadata, error decoding meta data packet
Возникает вопрос — а сам поток хоть как-то проходит валидацию?
Возможно это как-то связано с клиентом-транслятором? Или, предположим, с лагами сети?
В общем, даже заявленный вами rtmpdump, иногда не желает работать.
В качестве источника пробовал wirecast + xsplit, других софтин для композа изображения и трансляции не знаю (ffmpeg умеет только хватать картинку, но не умеет делать композ изображения). Замечены подобные ошибки были при использовании wirecast, возможно дело в нем, однако вы заявляете совместимость и с ним. Если посоветуете другие бродкастеры — буду благодарен.
Ну и немного по статье:
> Директива exec позволяет запустить внешнее приложение в момент публикации входящего потока
Не знаю как у вас, а вот у меня ffmpeg очень любит долго читать rtmp-поток, а уже потом, переварив примерно 5 метров, начинать его процессинг. Если вещать только голос с микрофона, то это может занять минут 15. Причина тому — размер буффера в функции, где происходит детект потока. Победил написанием своего велосипеда, заполняя структуры потоков вручную, без использования автодетекта от libavcodec/libavformat.
> ffmpeg -re -i /var/videos/test.mp4 -c copy -f flv rtmp://localhost/myapp/mystream
А кто занимается таймингом потока в этом случае? По крайней мере раньше, ffmpeg отправлял все что есть на FMS на максимальной скорости, клиент за ним конечно же не успевал. Пришлось написать велосипед, который читал FLV по байтикам, смотрел на таймштамп пакетов и отправлял на сервер с задержкой, синхронизировавшись с локальными часами:
ffmpeg -i test.mp4 -c copy -f flv — | myStreamer target
> on_publish example.com/check_publisher;
А почему нельзя сделать авторизацию внутри сервера? Мне вот крайне неприятно дергать что-то по http, мне как минимум надо поднимать вебсервер и писать веб-приложение для этого. Хотел было в функции ngx_rtmp_live_publish проверять валидность имени потока и выдавать ошибку/переименовывать поток, но не понял как происходит разрегистрация стрима, на этом написание патча остановилась. Не поможете дописать?
Во-первых, как мне отловить конец стрима?
Клиент получает NetStream.Play.Start и потом с переменным успехом NetStream.Buffer.Full и NetStream.Buffer.Empty
События Stop или Unpublish я не получаю, хотя при этом поток-источник может рватся любое количество раз.
В принципе, в самом флеш-плеере все хорошо, а вот rtmpdump (и мое приложение с librtmp) от такого сходят с ума и не могут доливать поток после того, как тот был возобновлен. Особенно плохо моему приложению, которое не может дождаться конца потока. В принципе, можно было бы выставить таймаут, но это не вариант для живых аудиотрансляций — флеш при пропадании звука (уменьшении амплитуды сигнала меньше порогового уровня) просто перестает отсылать байтики — стрим вроде как и есть, он НЕ закрыт, но потока и нет. Отличить от случая, когда клиент закрыл браузер, я никак не могу.
Далее, дабы далеко не ходить, сама librtmp иногда сыпит ошибками:
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: DECODING ERROR, IGNORING BYTES UNTIL NEXT KNOWN PATTERN!
ERROR: HandleMetadata, error decoding meta data packet
Возникает вопрос — а сам поток хоть как-то проходит валидацию?
Возможно это как-то связано с клиентом-транслятором? Или, предположим, с лагами сети?
В общем, даже заявленный вами rtmpdump, иногда не желает работать.
В качестве источника пробовал wirecast + xsplit, других софтин для композа изображения и трансляции не знаю (ffmpeg умеет только хватать картинку, но не умеет делать композ изображения). Замечены подобные ошибки были при использовании wirecast, возможно дело в нем, однако вы заявляете совместимость и с ним. Если посоветуете другие бродкастеры — буду благодарен.
Ну и немного по статье:
> Директива exec позволяет запустить внешнее приложение в момент публикации входящего потока
Не знаю как у вас, а вот у меня ffmpeg очень любит долго читать rtmp-поток, а уже потом, переварив примерно 5 метров, начинать его процессинг. Если вещать только голос с микрофона, то это может занять минут 15. Причина тому — размер буффера в функции, где происходит детект потока. Победил написанием своего велосипеда, заполняя структуры потоков вручную, без использования автодетекта от libavcodec/libavformat.
> ffmpeg -re -i /var/videos/test.mp4 -c copy -f flv rtmp://localhost/myapp/mystream
А кто занимается таймингом потока в этом случае? По крайней мере раньше, ffmpeg отправлял все что есть на FMS на максимальной скорости, клиент за ним конечно же не успевал. Пришлось написать велосипед, который читал FLV по байтикам, смотрел на таймштамп пакетов и отправлял на сервер с задержкой, синхронизировавшись с локальными часами:
ffmpeg -i test.mp4 -c copy -f flv — | myStreamer target
> on_publish example.com/check_publisher;
А почему нельзя сделать авторизацию внутри сервера? Мне вот крайне неприятно дергать что-то по http, мне как минимум надо поднимать вебсервер и писать веб-приложение для этого. Хотел было в функции ngx_rtmp_live_publish проверять валидность имени потока и выдавать ошибку/переименовывать поток, но не понял как происходит разрегистрация стрима, на этом написание патча остановилась. Не поможете дописать?
Я стараюсь отвечать на все, что получаю.
1) конец стрима можно отловить как NetStream.Play.Stop. Начиная с версии 0.8 шлется именно эта нотификация.
Также можно включить NetStream.Play.UnpublishNotify (publish_notify on)
По поводу ошибок с rtmpdump, попробуйте самую новую версию nginx-rtmp 0.8. Там кое-что исправлено.
А вообще, если что-то не так, пишите багрепорты, поснифаем поток, посмотрим, что происходит.
Конкретно на такое еще никто не жаловался.
Сам поток (в смысле видео и аудио) валидацию, очевидно, не проходит т.к. это фактически равноценно раскодированию.
2) ffmpeg анализирует часть потока перед тем, как начать нормально работать. Это ему нужно для того, чтобы определить, какие аудио и видео каналы есть в потоке. Если, к примеру, вы вещаете только аудио, он будет ждать до упора, пока не найдет видео. Граница это регулируется настройкой -probesize, поставьте значение поменьше и все будет отрабатывать мгновенно.
3) Таймингом занимается сам ffmpeg, если ему указать опцию "-re". Она как раз и указана именно для случаев вещания видеофайлов
4) Логика авторизации может быть разной. Вообще ее, конечно, можно сделать и внутри, но внутри отдельного модуля, а не внутри свободно распространяемого сервера для решения общей задачи. Вы, кстати, можете зарегать хендлер в http{} секции nginx (для этого надо не забыть прописать «notify_method get»). Так вот в этом хендлере и реализовать всю вашу логику, например на lua или даже средствами самого nginx, если логика простая.
1) конец стрима можно отловить как NetStream.Play.Stop. Начиная с версии 0.8 шлется именно эта нотификация.
Также можно включить NetStream.Play.UnpublishNotify (publish_notify on)
По поводу ошибок с rtmpdump, попробуйте самую новую версию nginx-rtmp 0.8. Там кое-что исправлено.
А вообще, если что-то не так, пишите багрепорты, поснифаем поток, посмотрим, что происходит.
Конкретно на такое еще никто не жаловался.
Сам поток (в смысле видео и аудио) валидацию, очевидно, не проходит т.к. это фактически равноценно раскодированию.
2) ffmpeg анализирует часть потока перед тем, как начать нормально работать. Это ему нужно для того, чтобы определить, какие аудио и видео каналы есть в потоке. Если, к примеру, вы вещаете только аудио, он будет ждать до упора, пока не найдет видео. Граница это регулируется настройкой -probesize, поставьте значение поменьше и все будет отрабатывать мгновенно.
3) Таймингом занимается сам ffmpeg, если ему указать опцию "-re". Она как раз и указана именно для случаев вещания видеофайлов
4) Логика авторизации может быть разной. Вообще ее, конечно, можно сделать и внутри, но внутри отдельного модуля, а не внутри свободно распространяемого сервера для решения общей задачи. Вы, кстати, можете зарегать хендлер в http{} секции nginx (для этого надо не забыть прописать «notify_method get»). Так вот в этом хендлере и реализовать всю вашу логику, например на lua или даже средствами самого nginx, если логика простая.
Я собирал модуль из репозитория от Nov 16 11:28, события Stop не получал никогда. Судя по блогу, версия 0.8 вышла только в декабре, мне надо пересобрать все. Спасибо.
Сюда же спишу проблемы с некорректным потоком, просто проверить сейчас не могу.
Про валидацию я имел в виду размеры пакетов в самом FLV-контейнере, там хоть сигнатур для проверки и не густо, но можно определить по последним 4 байтам целостность потока. Сталкивался с тем, что java-апплет для снятия картинки с экрана иногда забывал дописывать кусочки данных (ну или пишет размер пакета некорректно), пришлось делать костылек.
Для уменьшения буфера детектирования я выставлял поля max_analyze_duration=4096; и io->max_packet_size=50000, получил минимальную задержку, чего с ffmpeg сделать не получалось (надо правда сказать, что это было достаточно давно, я тогда извращался еще с оригинальным FMS и rtmpd), а вот про опцию -re не знал, спасибо.
А вот теперь по поводу авторизации. Не знаю, как сильно это вяжется с идеологией проекта, но мне бы хотелось в идеале выставлять параметры всей сессии. Логика примерно такая:
1. пришел коннект, подключились к application -> я проверяю имя приложения
2. пришел запрос на публикацию -> я проверяю имя стрима, к примеру клиент шлет 7364589273645987346
3. я знаю, что этот ID от пользователя ХХХ, что опубликовать его надо как /vasya/videoBlog, а не как /live/7364589273645987346
4. я знаю, что длительность публикации должна быть не более 10 минут, аудио кодек только неллимосер, общий битрейт не более мегабита, а число клиентов не более 5 штук
5. если после любой проверки что-то не так — соединение закрывается.
6. опционально выставить SharedObject с данными, что currentClients=0 и считать в нем зрителей.
Т.е. в идеале не просто «да» или «нет» получать от логики, а иметь возможность самому заполнить структурку со всеми параметрами, которые только могут быть. Сделать плагинный интерфейс, как к примеру в pureftpd. Но это мои влажные фантазии, поэтому мне проще будет написать патч (но с учетом асинхронной любви я этого не осиляю пока)
Сюда же спишу проблемы с некорректным потоком, просто проверить сейчас не могу.
Про валидацию я имел в виду размеры пакетов в самом FLV-контейнере, там хоть сигнатур для проверки и не густо, но можно определить по последним 4 байтам целостность потока. Сталкивался с тем, что java-апплет для снятия картинки с экрана иногда забывал дописывать кусочки данных (ну или пишет размер пакета некорректно), пришлось делать костылек.
Для уменьшения буфера детектирования я выставлял поля max_analyze_duration=4096; и io->max_packet_size=50000, получил минимальную задержку, чего с ffmpeg сделать не получалось (надо правда сказать, что это было достаточно давно, я тогда извращался еще с оригинальным FMS и rtmpd), а вот про опцию -re не знал, спасибо.
А вот теперь по поводу авторизации. Не знаю, как сильно это вяжется с идеологией проекта, но мне бы хотелось в идеале выставлять параметры всей сессии. Логика примерно такая:
1. пришел коннект, подключились к application -> я проверяю имя приложения
2. пришел запрос на публикацию -> я проверяю имя стрима, к примеру клиент шлет 7364589273645987346
3. я знаю, что этот ID от пользователя ХХХ, что опубликовать его надо как /vasya/videoBlog, а не как /live/7364589273645987346
4. я знаю, что длительность публикации должна быть не более 10 минут, аудио кодек только неллимосер, общий битрейт не более мегабита, а число клиентов не более 5 штук
5. если после любой проверки что-то не так — соединение закрывается.
6. опционально выставить SharedObject с данными, что currentClients=0 и считать в нем зрителей.
Т.е. в идеале не просто «да» или «нет» получать от логики, а иметь возможность самому заполнить структурку со всеми параметрами, которые только могут быть. Сделать плагинный интерфейс, как к примеру в pureftpd. Но это мои влажные фантазии, поэтому мне проще будет написать патч (но с учетом асинхронной любви я этого не осиляю пока)
Ну и еще немного ошибок, которыми плюется livavcodec:
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x237a640] Stream discovered after head already parsed
[h264 @ 0x7f55ec045b40] Missing reference picture
[h264 @ 0x7f55ec045b40] decode_slice_header error
[h264 @ 0x7f55ec045b40] concealing 1200 DC, 1200 AC, 1200 MV errors
[h264 @ 0x7f55ec045b40] Missing reference picture
[h264 @ 0x7f55ec045b40] decode_slice_header error
[h264 @ 0x7f55ec045b40] concealing 1200 DC, 1200 AC, 1200 MV errors
[flv @ 0x237a640] max_analyze_duration 4096 reached at 23000
[flv @ 0x237a640] decoding for stream 1 failed
[flv @ 0x237a640] Estimating duration from bitrate, this may be inaccurate
[flv @ 0x23a0a40] Stream discovered after head already parsed
[h264 @ 0x23a1a40] Missing reference picture
[h264 @ 0x23a1a40] decode_slice_header error
[h264 @ 0x23a1a40] concealing 1200 DC, 1200 AC, 1200 MV errors
[flv @ 0x23a0a40] max_analyze_duration 4096 reached at 23000
[flv @ 0x23a0a40] decoding for stream 1 failed
[flv @ 0x23a0a40] Estimating duration from bitrate, this may be inaccurate
[flv @ 0x2488960] Stream discovered after head already parsed
[h264 @ 0x24898a0] reference picture missing during reorder
[h264 @ 0x24898a0] reference picture missing during reorder
[h264 @ 0x24898a0] Missing reference picture
[h264 @ 0x24898a0] decode_slice_header error
[h264 @ 0x24898a0] concealing 1200 DC, 1200 AC, 1200 MV errors
[h264 @ 0x24898a0] Missing reference picture
[h264 @ 0x24898a0] mmco: unref short failure
[h264 @ 0x24898a0] mmco: unref short failure
[flv @ 0x2488960] max_analyze_duration 4096 reached at 23000
[flv @ 0x2488960] decoding for stream 1 failed
А вот примерно так умирает rtmpdump
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 46 00 00 18 00 00 0b 08 F…
DEBUG2: 0000: af 01 21 00 49 90 02 19 00 23 80 ..!.I....#.
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 46 00 00 17 00 00 0b 08 F…
DEBUG2: 0000: af 01 21 00 49 90 02 19 00 23 80 ..!.I....#.
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 46 00 00 17 00 00 0b 08 F…
DEBUG2: 0000: af 01 21 00 49 90 02 19 00 23 80 ..!.I....#.
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 47 00 06 f6 00 00 05 09 G…
DEBUG2: 0000: 17 02 00 00 00…
DEBUG: ignoring too small video packet: size: 5
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG: RTMPSockBuf_Fill, recv returned -1. GetSockError(): 11 (Resource temporarily unavailable)
ERROR: RTMP_ReadPacket, failed to read RTMP packet header
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x14a0a40] negative cts, previous timestamps might be wrong
[flv @ 0x237a640] Stream discovered after head already parsed
[h264 @ 0x7f55ec045b40] Missing reference picture
[h264 @ 0x7f55ec045b40] decode_slice_header error
[h264 @ 0x7f55ec045b40] concealing 1200 DC, 1200 AC, 1200 MV errors
[h264 @ 0x7f55ec045b40] Missing reference picture
[h264 @ 0x7f55ec045b40] decode_slice_header error
[h264 @ 0x7f55ec045b40] concealing 1200 DC, 1200 AC, 1200 MV errors
[flv @ 0x237a640] max_analyze_duration 4096 reached at 23000
[flv @ 0x237a640] decoding for stream 1 failed
[flv @ 0x237a640] Estimating duration from bitrate, this may be inaccurate
[flv @ 0x23a0a40] Stream discovered after head already parsed
[h264 @ 0x23a1a40] Missing reference picture
[h264 @ 0x23a1a40] decode_slice_header error
[h264 @ 0x23a1a40] concealing 1200 DC, 1200 AC, 1200 MV errors
[flv @ 0x23a0a40] max_analyze_duration 4096 reached at 23000
[flv @ 0x23a0a40] decoding for stream 1 failed
[flv @ 0x23a0a40] Estimating duration from bitrate, this may be inaccurate
[flv @ 0x2488960] Stream discovered after head already parsed
[h264 @ 0x24898a0] reference picture missing during reorder
[h264 @ 0x24898a0] reference picture missing during reorder
[h264 @ 0x24898a0] Missing reference picture
[h264 @ 0x24898a0] decode_slice_header error
[h264 @ 0x24898a0] concealing 1200 DC, 1200 AC, 1200 MV errors
[h264 @ 0x24898a0] Missing reference picture
[h264 @ 0x24898a0] mmco: unref short failure
[h264 @ 0x24898a0] mmco: unref short failure
[flv @ 0x2488960] max_analyze_duration 4096 reached at 23000
[flv @ 0x2488960] decoding for stream 1 failed
А вот примерно так умирает rtmpdump
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 46 00 00 18 00 00 0b 08 F…
DEBUG2: 0000: af 01 21 00 49 90 02 19 00 23 80 ..!.I....#.
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 46 00 00 17 00 00 0b 08 F…
DEBUG2: 0000: af 01 21 00 49 90 02 19 00 23 80 ..!.I....#.
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 46 00 00 17 00 00 0b 08 F…
DEBUG2: 0000: af 01 21 00 49 90 02 19 00 23 80 ..!.I....#.
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG2: 0000: 47 00 06 f6 00 00 05 09 G…
DEBUG2: 0000: 17 02 00 00 00…
DEBUG: ignoring too small video packet: size: 5
DEBUG2: RTMP_ReadPacket: fd=4
DEBUG: RTMPSockBuf_Fill, recv returned -1. GetSockError(): 11 (Resource temporarily unavailable)
ERROR: RTMP_ReadPacket, failed to read RTMP packet header
Это надо смотреть на конкретном примере. Из того, что я вижу, это отсутствие ключевого фрейма вначале трансляции (можно решить опцией wait_key on). Ошибка декодирования h264 говорит о том, что, вероятно, есть проблема с самим закодированным потоком.
По rtmpdump я вообще не вижу ошибки. Это его стандартная ругань, когда у него экспайрится таймаут. Т.е. он просто не дождался данных.
Но, повторюсь, поставьте 0.8 сначала.
По rtmpdump я вообще не вижу ошибки. Это его стандартная ругань, когда у него экспайрится таймаут. Т.е. он просто не дождался данных.
Но, повторюсь, поставьте 0.8 сначала.
Артур, большое спасибо за модуль!
Мы используем этот модуль в product окружении около полугода.
По сравнению с wowza/erly ваше решение — небо и земля.
Wowza при стриме потока больше 5 гигабит/с ухитрялась пожирать весь процессор на не слабом сервере (2 x E5-2620).
После перехода на модуль nginx, эти проблемы решились и теперь спокойно держим 2 x 8 гигабит/с на одном E3-1240.
ps. Один раз правда была проблема с утечкой памяти в модуле, но она быстро закрылась Артуром.
Мы используем этот модуль в product окружении около полугода.
По сравнению с wowza/erly ваше решение — небо и земля.
Wowza при стриме потока больше 5 гигабит/с ухитрялась пожирать весь процессор на не слабом сервере (2 x E5-2620).
После перехода на модуль nginx, эти проблемы решились и теперь спокойно держим 2 x 8 гигабит/с на одном E3-1240.
ps. Один раз правда была проблема с утечкой памяти в модуле, но она быстро закрылась Артуром.
Роман, спасибо за модуль, как раз начал использовать его на шатком сервере для своих нужд, и работает все отлично.
Но есть некоторые проблемы с вещанием потока с камеры. То есть я использую примерно такую команду:
Я могу при одних и тех же обстоятельствах наблюдать разные проблемы:
Видео отправляется, но не проигрывается до того момента, пока не завершишь отправку потока на сервер. Сразу после этого отправленный в «буфер» поток воспроизводится. По наблюдениям так бывает, если добавить -an в параметры запуска ffmpeg.
Также при этом поведении не ведется запись hls.
Видео при трансляции с камеры вообще не воспроизводится во флеш-плеерах, иногда воспроизводится только звук.
Одновременно с этим, если отправлять на сервер реалтайм-поток любого файла, то все работает как нужно, в том числе, если захватывать поток rtsp или http.
Так как мне нужно было как-то вещать с камеры, то я делал захват через VLC, и скармливал rtsp-поток ffmpeg'у. В таком случае все работало как нужно, но безбожно весило компьютер.
Но есть некоторые проблемы с вещанием потока с камеры. То есть я использую примерно такую команду:
ffmpeg -f dshow -i video="Webcam":audio="Webcam Microphone" -c:v libx264 -c:a libmp3lame -ar 44100 -ac 1 -f flv rtmp://server/live/stream
Я могу при одних и тех же обстоятельствах наблюдать разные проблемы:
Видео отправляется, но не проигрывается до того момента, пока не завершишь отправку потока на сервер. Сразу после этого отправленный в «буфер» поток воспроизводится. По наблюдениям так бывает, если добавить -an в параметры запуска ffmpeg.
Также при этом поведении не ведется запись hls.
Видео при трансляции с камеры вообще не воспроизводится во флеш-плеерах, иногда воспроизводится только звук.
Одновременно с этим, если отправлять на сервер реалтайм-поток любого файла, то все работает как нужно, в том числе, если захватывать поток rtsp или http.
Так как мне нужно было как-то вещать с камеры, то я делал захват через VLC, и скармливал rtsp-поток ffmpeg'у. В таком случае все работало как нужно, но безбожно весило компьютер.
Да, ffmpeg я качал здесь ffmpeg.zeranoe.com/builds/
Собрано от вот так:
Собрано от вот так:
ffmpeg version N-47062-g26c531c Copyright (c) 2000-2012 the FFmpeg developers
built on Nov 25 2012 12:21:26 with gcc 4.7.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
Покрутите параметр -probesize чтобы ffmpeg не подвисал на чтении потока при отсутствии аудио или видео. Чем он меньше, тем меньше задержка перед началом передачи потока на сервер.
С камеры можно захватывать самим ffmpeg'ом, я приводил пример. И вешать оно ничего не должно, если только вы не производите перекодировку видео.
С камеры можно захватывать самим ffmpeg'ом, я приводил пример. И вешать оно ничего не должно, если только вы не производите перекодировку видео.
Видимо я плохо сформулировал.
Мне так и не удалось заставить ffmpeg стабильно передавать видео с камеры напрямую(через DirectShow). При любом раскладе ни один из флеш-плееров не показывают изображение, только звук.
Но если передавать на сервер готовый файл(или любой другой входной поток — http/rtsp), при этом также транскодируя его на лету с параметром -re, то везде все и всегда воспроизводится прекрасно, hls сохраняется.
А про «вешать» я имел ввиду, что та конфигурация, которую мне пришлось использовать (webcam -> VLC -> rtsp stream out -> ffmpeg -> out nginx rtmp) очень сильно подвешивает систему, но работает. Видимо VLC кодирует менее эффективно.
Мне так и не удалось заставить ffmpeg стабильно передавать видео с камеры напрямую(через DirectShow). При любом раскладе ни один из флеш-плееров не показывают изображение, только звук.
Но если передавать на сервер готовый файл(или любой другой входной поток — http/rtsp), при этом также транскодируя его на лету с параметром -re, то везде все и всегда воспроизводится прекрасно, hls сохраняется.
А про «вешать» я имел ввиду, что та конфигурация, которую мне пришлось использовать (webcam -> VLC -> rtsp stream out -> ffmpeg -> out nginx rtmp) очень сильно подвешивает систему, но работает. Видимо VLC кодирует менее эффективно.
Роман, вчера тестировал модуль для записи live-стрима (h264 + speex в flv). Пишет, нарезает… но полученные файлы не перевариаются потом при попытке перекодировать (ffmpeg: Could not find codec parameters (Video: h264) и игнорирует видео, cvlc — просто залипает). Воспроизводятся же эти файлы нормально.
Исходный поток ffmpeg нормально переваривает.
Подскажите, как побороть?
Исходный поток ffmpeg нормально переваривает.
Подскажите, как побороть?
А где «битые файлы»? Где дампы заголовков в этих файлах? Я не Роман, но думаю он астралом тоже не умеет пользоваться.
Пример двух подряд идущих файлов.
Любую другую информацию тоже предоставлю, но, мне нужно знать, какая информация нужна, и где ее посмотреть.
Любую другую информацию тоже предоставлю, но, мне нужно знать, какая информация нужна, и где ее посмотреть.
А вы не могли бы собрать дебаг и прислать error.log?
github.com/arut/nginx-rtmp-module/wiki/Debug-log
github.com/arut/nginx-rtmp-module/wiki/Debug-log
Положил лог и записанные файлы (с префиксом new-) туда же.
В общем, проблема понятна. Ваш поток начинается с intermediate фреймов. Вот именно такие фреймы и попадают первыми в записанный flv. Заголовок H264 и ключевой фрейм идут уже после 4х промежуточных фреймов.
Эта проблема касается именно первого записанного файла, последующие записываются правильно.
Строго говоря, в записанном flv есть все, чтобы нормально воспроизводиться и перекодироваться, но ffmpeg ожидает, что заголовок H264 будет в начале файла.
В любом случае я сделаю так, чтобы этой проблемы не было при любом потоке. Спасибо.
Эта проблема касается именно первого записанного файла, последующие записываются правильно.
Строго говоря, в записанном flv есть все, чтобы нормально воспроизводиться и перекодироваться, но ffmpeg ожидает, что заголовок H264 будет в начале файла.
В любом случае я сделаю так, чтобы этой проблемы не было при любом потоке. Спасибо.
Думал над таким вариантом, но, последующие файлы тоже не воспринимаются ffmpeg'ом почему-то…
с new-stream2-1355492018.flv разве есть проблемы? у меня с ним все ок
Да, его тоже не пережевывает. Может, ffmpeg'у чего не хватает?.. Пробовал на нескольких машинах.
ffmpeg version 0.10.3
built on Dec 14 2012 15:08:07 with gcc 4.5.4
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=native -O2 -pipe' --extra-cflags='-march=native -O2 -pipe' --extra-cxxflags='-march=native -O2 -pipe' --disable-static --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-vaapi --disable-vdpau --disable-ffplay --enable-runtime-cpudetect --enable-libmp3lame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-libfaac --enable-nonfree --enable-libdc1394 --disable-indev=v4l --disable-indev=v4l2 --disable-indev=alsa --disable-indev=jack --disable-outdev=alsa --disable-outdev=sdl --enable-pthreads --enable-libopencore-amrwb --enable-libopencore-amrnb --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libvpx --enable-libopenjpeg --disable-amd3dnow --disable-amd3dnowext --disable-altivec --disable-avx --disable-mmx2 --disable-vis --disable-neon --cpu=host --enable-hardcoded-tables
libavutil 51. 35.100 / 51. 35.100
libavcodec 53. 61.100 / 53. 61.100
libavformat 53. 32.100 / 53. 32.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 61.100 / 2. 61.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 6.100 / 0. 6.100
libpostproc 52. 0.100 / 52. 0.100
А что именно он говорит на этом файле? Укажите ему -loglevel verbose
Вот такое. Собрал 0.10.6, лог одинаковый.
Кстати, вчера я такого поведения не замечал. На этом файле ffmpeg подвисает просто, приходится выходить по ^C.
Кстати, вчера я такого поведения не замечал. На этом файле ffmpeg подвисает просто, приходится выходить по ^C.
ffmpeg version 0.10.6 Copyright (c) 2000-2012 the FFmpeg developers
built on Dec 14 2012 17:57:46 with gcc 4.5.4
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=native -O2 -pipe' --extra-cflags='-march=native -O2 -pipe' --extra-cxxflags='-march=native -O2 -pipe' --disable-static --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-vaapi --disable-vdpau --disable-ffplay --enable-runtime-cpudetect --enable-libmp3lame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-libfaac --enable-nonfree --enable-libdc1394 --disable-indev=v4l --disable-indev=v4l2 --disable-indev=alsa --disable-indev=jack --disable-outdev=alsa --disable-outdev=sdl --enable-pthreads --enable-libopencore-amrwb --enable-libopencore-amrnb --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libvpx --enable-libopenjpeg --disa libavutil 51. 35.100 / 51. 35.100
libavcodec 53. 61.100 / 53. 61.100
libavformat 53. 32.100 / 53. 32.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 61.100 / 2. 61.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 6.100 / 0. 6.100
libpostproc 52. 0.100 / 52. 0.100
[flv @ 0x626320] Format flv probed with size=2048 and score=100
[h264 @ 0x62c630] err{or,}_recognition separate: 1; 1
[h264 @ 0x62c630] err{or,}_recognition combined: 1; 10001
Конкретно этот трабл скорее всего можно пофиксить малым значением -probesize.
В общем, что касается первых файлов в записи, то поддержку таких потоков я добавил, но это еще надо протестировать, я вам напишу, как будет полностью готово. А вот что касается последующих файлов, тут нам надо разобраться, у меня они отлично просматриваются, перекодируются итд.
В общем, что касается первых файлов в записи, то поддержку таких потоков я добавил, но это еще надо протестировать, я вам напишу, как будет полностью готово. А вот что касается последующих файлов, тут нам надо разобраться, у меня они отлично просматриваются, перекодируются итд.
Спасибо за помощь, попробую разобраться.
Попробуйте бранч «record-keyframes».
Спасибо, попробую и отпишусь. Наверное, уже на следующей неделе.
Очень интересное решение! Большое спасибо за проект и за этот пост :)
Держите в курсе разработки, думаю она здесь многим будет интересна.
Держите в курсе разработки, думаю она здесь многим будет интересна.
Роман, привет!
А можно как-нибудь уменьшить задержку при вещании с веб-камеры? Или 3 секунды — это минимум?
А можно как-нибудь уменьшить задержку при вещании с веб-камеры? Или 3 секунды — это минимум?
А есть возможноть сделать VOD HLS как в официальном HLS модуле для nginx?
Сейчас hls включен в основной модуль, ничего включать дополнительно не надо.
Где-то в доках осталось описание старого поведения?
Где-то в доках осталось описание старого поведения?
Вот у меня так пишет
configuring additional modules
adding module in ~/build/nginx-rtmp-module
./configure: error: no ~/build/nginx-rtmp-module/config was found
Как быть, файл там есть?!
configuring additional modules
adding module in ~/build/nginx-rtmp-module
./configure: error: no ~/build/nginx-rtmp-module/config was found
Как быть, файл там есть?!
что пишет по nginx -V
а вообще советую почитать тут
а вообще советую почитать тут
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сервер онлайн-вещаний на базе nginx