Pull to refresh

Comments 99

здорово что хлс сделан! осталось еще сильверлайт прикрутить и будет универсальный комбайн.
Справедливости ради, универсальным комбайн (при всех его текущих достоинствах) станет, когда RTMPT поддерживать будет. А это случится очень нескоро, если случится вообще. It's not planned for the near future.
А требования к дисковой какие? Сколько иопсов генерится при двухгигабитной отдаче?
Требования к дискам имеют место быть лишь при использовании HLS. Собственно требования напряму. зависят от вашего потока :) Вообще логичнее размещать HLS location в tmpfs.
Да, имелось в виду VoD. При нескольких терабайтах контента в tmpfs не позасовываешь.
Для террабайт, имхо, иные решения нужно использовать…
Жаль. При сильных нагрузках на дисковую помогает реально. Без него как в дисковую упирается сервер, сильно снижается скорость отдачи.
простите, а чем именно aio помогает, если мы упёрлись в диски?
Позволяет не блокировать процесс нгинкса на время операции ввода-вывода.
Т.е. в случае без аио процесс ждёт выполнения операции чтения или записи с диска, вместо отдачи статики например из озу.
ну aio в linux требует открытия файла с O_DIRECT, так что никакого кеширования в VFS у вас не будет.
на 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
Кстати одна дама из команды разработчиков ядра несколько лет назад расшила таки синхронные операции ввода-вывода с использованием т.н. retry-model. Т.е. вместо ожидания появления на странице прочитанных с блочного устройства данных у нее происходил полный возврат с некоторым кодом (готово- не готово). Таким образом, у нее заработали асинхронные операции через пейджкеш. Но ее патч выкинули в конце концов.
Ну я глубоко не копал, но эффект проседания скорости отдачи при 100% нагрузке дисковой наблюдал на практике. Проседало сильно, примерно на 30%. Centos 5.8
проще и правильнее воркеров побольше завести.
тем более, что при вышеописанной ситуации у вас уже куда большие проблемы имеются и решать надо их(например, через flashcache).
Побольше это сколько? На машине которая проседала было 8 воркеров. Какие там ещё проблемы то? Фешкэш хорош для БД. Но для VOD не очень.
Артур, спасибо как за само решение,
так и за статью: технология вещания расписана очень позновательно.

при использовании обязательно возникнут вопросы.
Отличное решение, и очень доступное!

Скажите, а возможно ли вещать из MJPEG-источника?
Вы про ip-камеру?
Используйте 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, который чёрт знает когда появится?
Если какой-то плеер умеет играть HLS, то это не значит, то он больше ничего не умеет. Единственное место, где нужен HLS — это говнодевайсы с закругленными уголками. Во всем остальном мире HLS — это нестандартное решение, которое опционально поддерживают некоторые продукты, причем делают это на свой страх и риск.

О альтернативах я кратенько писал: habrahabr.ru/post/153817/

Про jwplayer вообще смешно, пойду тоже какую-то хрень на флеше сделаю, может быть ее тоже будут приводить в аргументах.
ещё раз: какие альтернативы, если вы вещаете видео и хотите поддержку максимального количества платформ?

чтобы нормально работало из-за NAT/HTTP Proxy и дружило с CDN?
Не посдкажите как с помощью этого модуля проще всего транслировать очередь из видео-файлов?
Аналогично примеру с интернет-радио

for file in /var/videos/*; do 
    ffmpeg -re -i "$file" -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/myapp/mystream;
done
Подскажите, как решить проблему с переходом между файлами? Дело в том, что ffmpeg обрывает соединение в конце файла и модуль шлет плееру NetStream.Play.Stop и как следствие, обрыв вещания. Как сделать непрерывный поток?
play_restart off;

но это происходит не во всех плеерах
Интересно, планируется ли поддержка воспроизведения VOD через HLS с нарезкой на фрагменты на лету. Как это делает вовза. Было бы здорово.
Я думаю над этим. Но изначально цель была имнно в live вещании. Строго говоря, для VOD/HLS и медиа-сервер не нужен.
Но тем не менее, nginx-rtmp уже и не только лайв и не только rtmp. И как раз этой маленькой фичи не хватает для получения медиакомбайна.
А на самом деле продукт замечательный, присматриваемся к возможности использовании его на продакшне в CDNе…
Поддерживаю. Очень хочется такую фичу, чтобы была радость для iPad-ов без необходимости хранения дополнительной кучи чанков на сервере.
Меня часто просят об этом. В планах это есть. Осталось найти красивое решение.
Уж лучше стандарт использовать, чем неутвержденный драфт. Это я на rtsp намекаю, который я частично сделал в айскасте, но потом забил.
Очень круто! red5 слишком сложен и тяжел для моих целей, а вот такой модуль — то что нужно. Сейчас переделываю своё приложение и возник вопрос — в пределах одного соединения red5 позволял одновременно производить публикацию live-потока и воспроизводить его же (пытаюсь сделать loopback с вебкамеры, идущий через сервер — для тестовых целей). При использовании данного модуля — публикация проходит, что видно при использовании record, но поток не воспроизводится. Хотел узнать — было ли так задумано. Хотя, мне это не мешает — просто отдаю и принимаю поток через два разных соединения.

Отличный модуль.
Да, действительно, такой номер не пройдет. Может быть в будущих версиях я реализую это.
Спасибо
А я долго искал причину, даже засел со сниффером
Очень слоу пост. Тоесть нельзя принимать RTMP поток, писать его в файл и ретрансилировать по HLS?
Так как в гугле меня забанили, а на контакты вы не отвечаете, то спрошу здесь.

Во-первых, как мне отловить конец стрима?
Клиент получает 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, если логика простая.
Я собирал модуль из репозитория от 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. Но это мои влажные фантазии, поэтому мне проще будет написать патч (но с учетом асинхронной любви я этого не осиляю пока)
Ну и еще немного ошибок, которыми плюется 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
Это надо смотреть на конкретном примере. Из того, что я вижу, это отсутствие ключевого фрейма вначале трансляции (можно решить опцией wait_key on). Ошибка декодирования h264 говорит о том, что, вероятно, есть проблема с самим закодированным потоком.

По rtmpdump я вообще не вижу ошибки. Это его стандартная ругань, когда у него экспайрится таймаут. Т.е. он просто не дождался данных.

Но, повторюсь, поставьте 0.8 сначала.
Поток генерировался через wirecast / xsplit, проблема в том, что сервер отдает стрим не с кейфрейма
В 0.8 есть опция wait_key для решения этой проблемы.
Артур, большое спасибо за модуль!

Мы используем этот модуль в product окружении около полугода.
По сравнению с wowza/erly ваше решение — небо и земля.
Wowza при стриме потока больше 5 гигабит/с ухитрялась пожирать весь процессор на не слабом сервере (2 x E5-2620).
После перехода на модуль nginx, эти проблемы решились и теперь спокойно держим 2 x 8 гигабит/с на одном E3-1240.

ps. Один раз правда была проблема с утечкой памяти в модуле, но она быстро закрылась Артуром.
Да, Роман, вечно путаюсь с именами =)
А с erly video почему не срослось?
Роман, спасибо за модуль, как раз начал использовать его на шатком сервере для своих нужд, и работает все отлично.
Но есть некоторые проблемы с вещанием потока с камеры. То есть я использую примерно такую команду:
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 стабильно передавать видео с камеры напрямую(через DirectShow). При любом раскладе ни один из флеш-плееров не показывают изображение, только звук.

Но если передавать на сервер готовый файл(или любой другой входной поток — http/rtsp), при этом также транскодируя его на лету с параметром -re, то везде все и всегда воспроизводится прекрасно, hls сохраняется.

А про «вешать» я имел ввиду, что та конфигурация, которую мне пришлось использовать (webcam -> VLC -> rtsp stream out -> ffmpeg -> out nginx rtmp) очень сильно подвешивает систему, но работает. Видимо VLC кодирует менее эффективно.
Попробуйте проигрывать поток не флешом, а ffplay или ffmpeg с параметром -loglelve verbose.
ffplay само собой показывает, но это как бы все равно лишает всю затею смысла.
В итоге провозившись весть день ничего более предсказуемого, чем связка vlc(rtsp) + ffmpeg найти не удалось.
Хорошо, чот работает. Я иногда использую ffmpeg (или ffprobe) для проверки валидности потока. Он может сказать что не так.
Роман, вчера тестировал модуль для записи live-стрима (h264 + speex в flv). Пишет, нарезает… но полученные файлы не перевариаются потом при попытке перекодировать (ffmpeg: Could not find codec parameters (Video: h264) и игнорирует видео, cvlc — просто залипает). Воспроизводятся же эти файлы нормально.

Исходный поток ffmpeg нормально переваривает.

Подскажите, как побороть?
А где «битые файлы»? Где дампы заголовков в этих файлах? Я не Роман, но думаю он астралом тоже не умеет пользоваться.
В общем, проблема понятна. Ваш поток начинается с intermediate фреймов. Вот именно такие фреймы и попадают первыми в записанный flv. Заголовок H264 и ключевой фрейм идут уже после 4х промежуточных фреймов.

Эта проблема касается именно первого записанного файла, последующие записываются правильно.

Строго говоря, в записанном 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 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.

В общем, что касается первых файлов в записи, то поддержку таких потоков я добавил, но это еще надо протестировать, я вам напишу, как будет полностью готово. А вот что касается последующих файлов, тут нам надо разобраться, у меня они отлично просматриваются, перекодируются итд.
Спасибо за помощь, попробую разобраться.
Спасибо, попробую и отпишусь. Наверное, уже на следующей неделе.
К сожалению, еще не дошли руки, пригрузили другим.
Может, сегодня получится.
Провел короткий тест, похоже, все отлично — файлы записаны, ффмпег не ругается, конвертирует.

Еще потестирую, но, похоже, мне именно это и нужно было. Огромное спасибо!
Прекрасно. Тогда я смержу в мастер. Если что не так — пишите.
Очень интересное решение! Большое спасибо за проект и за этот пост :)
Держите в курсе разработки, думаю она здесь многим будет интересна.
Роман, привет!

А можно как-нибудь уменьшить задержку при вещании с веб-камеры? Или 3 секунды — это минимум?
Это настраивается на клиенте.
У JWPlayer, например, такая настройка «bufferlength: 1».
А есть возможноть сделать VOD HLS как в официальном HLS модуле для nginx?
Насколько я знаю, Роман — автор того самого HLS модуля для nginx :)
Так и есть. Когда узнал все встало на свои места.
UFO just landed and posted this here
Сейчас hls включен в основной модуль, ничего включать дополнительно не надо.
Где-то в доках осталось описание старого поведения?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Довольно странно, что работает звук. Звук должен быть в AAC.
UFO just landed and posted this here
Вот у меня так пишет
configuring additional modules
adding module in ~/build/nginx-rtmp-module
./configure: error: no ~/build/nginx-rtmp-module/config was found
Как быть, файл там есть?!
что пишет по nginx -V
а вообще советую почитать тут
Sign up to leave a comment.

Articles