Конкретно этот трабл скорее всего можно пофиксить малым значением -probesize.
В общем, что касается первых файлов в записи, то поддержку таких потоков я добавил, но это еще надо протестировать, я вам напишу, как будет полностью готово. А вот что касается последующих файлов, тут нам надо разобраться, у меня они отлично просматриваются, перекодируются итд.
В общем, проблема понятна. Ваш поток начинается с intermediate фреймов. Вот именно такие фреймы и попадают первыми в записанный flv. Заголовок H264 и ключевой фрейм идут уже после 4х промежуточных фреймов.
Эта проблема касается именно первого записанного файла, последующие записываются правильно.
Строго говоря, в записанном flv есть все, чтобы нормально воспроизводиться и перекодироваться, но ffmpeg ожидает, что заголовок H264 будет в начале файла.
В любом случае я сделаю так, чтобы этой проблемы не было при любом потоке. Спасибо.
Кстати одна дама из команды разработчиков ядра несколько лет назад расшила таки синхронные операции ввода-вывода с использованием т.н. retry-model. Т.е. вместо ожидания появления на странице прочитанных с блочного устройства данных у нее происходил полный возврат с некоторым кодом (готово- не готово). Таким образом, у нее заработали асинхронные операции через пейджкеш. Но ее патч выкинули в конце концов.
Кроме того, открытие файла в Linux в любом случае синхронно. При большой иерархии это имеет значение, получите кучу синхронных рандомных сиков. А при синхронном чтении через пейджкеш срабатывает readahead, так что в реальные тормоза не такие уж и большие.
Покрутите параметр -probesize чтобы ffmpeg не подвисал на чтении потока при отсутствии аудио или видео. Чем он меньше, тем меньше задержка перед началом передачи потока на сервер.
С камеры можно захватывать самим ffmpeg'ом, я приводил пример. И вешать оно ничего не должно, если только вы не производите перекодировку видео.
Это надо смотреть на конкретном примере. Из того, что я вижу, это отсутствие ключевого фрейма вначале трансляции (можно решить опцией wait_key on). Ошибка декодирования h264 говорит о том, что, вероятно, есть проблема с самим закодированным потоком.
По rtmpdump я вообще не вижу ошибки. Это его стандартная ругань, когда у него экспайрится таймаут. Т.е. он просто не дождался данных.
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, если логика простая.
В общем, что касается первых файлов в записи, то поддержку таких потоков я добавил, но это еще надо протестировать, я вам напишу, как будет полностью готово. А вот что касается последующих файлов, тут нам надо разобраться, у меня они отлично просматриваются, перекодируются итд.
Эта проблема касается именно первого записанного файла, последующие записываются правильно.
Строго говоря, в записанном flv есть все, чтобы нормально воспроизводиться и перекодироваться, но ffmpeg ожидает, что заголовок H264 будет в начале файла.
В любом случае я сделаю так, чтобы этой проблемы не было при любом потоке. Спасибо.
github.com/arut/nginx-rtmp-module/wiki/Debug-log
С камеры можно захватывать самим ffmpeg'ом, я приводил пример. И вешать оно ничего не должно, если только вы не производите перекодировку видео.
PS: я Роман, а не Артур
По rtmpdump я вообще не вижу ошибки. Это его стандартная ругань, когда у него экспайрится таймаут. Т.е. он просто не дождался данных.
Но, повторюсь, поставьте 0.8 сначала.
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, если логика простая.
Спасибо
Используйте ffmpeg, который будет читать mjpeg, перекодировать и вещать на сервер.
Как-то так:
ffmpeg -i http://camera.example.com/cam.mpjg -c:v libx264 -an -f flv rtmp://localhost/myapp/mystream