Комментарии 15
А вы не пробовали на ffmpeg решение построить? Мой опыт говорит, что получается немного проще. У меня некоторые вещи с gstteamer не получилось сделать, были проблемы с некоторыми кодеками.
Выбор пал на Gstreamer в первую очередь по причине штатного плагина к нему, работающим с нашей платой видеозахвата Blackmagic intensity pro. У ffmpeg есть определенные проблемы с этой платой (из коробки она не работает, а нормального пакета поддержки нет).
Да, Вы правы, решение с ffmpeg будет выглядеть проще, но Gstreamer — продукт немного другой. Ffmpeg это готовое решение для работы с видео, в то время как gstreamer это библиотека (или фреймворк, в зависимости от источника). На мой взгляд gstreamer гибче, это подтверждается количеством ПО, разработанного на его основе, а в перспективе можно без проблем на его основе собрать любой медиакомбайн.
Стоит отметить, что представленные в посте примеры вызова gstreamer считаются пригодными для прототипирования, а в продакшне принято использовать как библиотеку к тому же языку Си (пример).
Да, Вы правы, решение с ffmpeg будет выглядеть проще, но Gstreamer — продукт немного другой. Ffmpeg это готовое решение для работы с видео, в то время как gstreamer это библиотека (или фреймворк, в зависимости от источника). На мой взгляд gstreamer гибче, это подтверждается количеством ПО, разработанного на его основе, а в перспективе можно без проблем на его основе собрать любой медиакомбайн.
Стоит отметить, что представленные в посте примеры вызова gstreamer считаются пригодными для прототипирования, а в продакшне принято использовать как библиотеку к тому же языку Си (пример).
pass=17? При лайве? Зачем?
Ради снижения нагрузки, при постоянном битрейте нагрузка была в 3 раза выше.
А что за параметр такой? CRF?
Это Encoding pass/type.
По дефолту он = 0 (Constant Bitrate Encoding)
Вот полный список значений:
По дефолту он = 0 (Constant Bitrate Encoding)
Вот полный список значений:
(0): cbr - Constant Bitrate Encoding
(4): quant - Constant Quantizer (debuggin$
(5): qual - Constant Quality
(17): pass1 - VBR Encoding - Pass 1
(18): pass2 - VBR Encoding - Pass 2
(19): pass3 - VBR Encoding - Pass 3
Спасибо! Я несколько раз игрался с GS, и для трансляций тоже, но как-то, подружится так и не удалось, и остановился на ffmpeg, хотя подозреваю, что сделал все кривовато.
Так как тут с высокой вероятностью будут пробегать профессионалы, спрошу у них всех.
Проблема: я делаю трансляцию и видеозапись, используя HDV-камеры (MPEG2, 1440x1080) и ноутбуки с Firewire входом (дешево, никаких лишних редких плат), откуда хватаю поток dvgrab-ом.
При этом гонюсь за двумя зайцами
* записать исходный видеопоток без искажений (перекодировок, фреймдроппов, и т.п.). Это самое ценное, ибо у меня обычно приоритет — качественная запись (смонтированая потом с кучей других источников), обрабатывать потом буду неспешно с AVISynth-фильтрами, а каждый рассинхрон выносит мне мозг.
* параллельно транслировать, если есть сеть — если вдруг отвалится, дропнуть пропущенное и нагнать (чтобы не сильно отставать, для общения с аудиторией текстом-чатом-твиттером).
Простые схемы с tee, или ffmpeg tee приводили к жесткой пайповой связке, и если тормозила трансляция в сеть, то тормозил и dvgrab, возникал рассинхрон и т.п.
Я стал просто писать файлы dvgrabом, и при поднятии трансляции в отдельных процессах вычислять последний файл, мотать к концу и стримить.
Оно работает, но наверно можно как-то более правильно сделать?
Так как тут с высокой вероятностью будут пробегать профессионалы, спрошу у них всех.
Проблема: я делаю трансляцию и видеозапись, используя HDV-камеры (MPEG2, 1440x1080) и ноутбуки с Firewire входом (дешево, никаких лишних редких плат), откуда хватаю поток dvgrab-ом.
При этом гонюсь за двумя зайцами
* записать исходный видеопоток без искажений (перекодировок, фреймдроппов, и т.п.). Это самое ценное, ибо у меня обычно приоритет — качественная запись (смонтированая потом с кучей других источников), обрабатывать потом буду неспешно с AVISynth-фильтрами, а каждый рассинхрон выносит мне мозг.
* параллельно транслировать, если есть сеть — если вдруг отвалится, дропнуть пропущенное и нагнать (чтобы не сильно отставать, для общения с аудиторией текстом-чатом-твиттером).
Простые схемы с tee, или ffmpeg tee приводили к жесткой пайповой связке, и если тормозила трансляция в сеть, то тормозил и dvgrab, возникал рассинхрон и т.п.
Я стал просто писать файлы dvgrabом, и при поднятии трансляции в отдельных процессах вычислять последний файл, мотать к концу и стримить.
Оно работает, но наверно можно как-то более правильно сделать?
Уточните пожалуйста, через какой протокол и куда вы транслировали видео?
Теоретически, если правильно сделать tee и проставить в нужных местах queue, то должно всё получиться, максимум настройки буферов у оных элементов подкрутить.
Теоретически, если правильно сделать tee и проставить в нужных местах queue, то должно всё получиться, максимум настройки буферов у оных элементов подкрутить.
Обычный rtmp, раньше на yatv, теперь видимо на twitch.…
Как бы настроить queue для трансляции, чтобы вообще не трогать запись (сдох интернет и фиг с ним) — там еще специфика в том, я снимаю без операторов на десяток устройств в пяти разных залах, и нет никого кто постоянно следит и может что-то починить… поэтому если трансляция сдохнет, то даже через час она не должна остановить запись на диск.
Как бы настроить queue для трансляции, чтобы вообще не трогать запись (сдох интернет и фиг с ним) — там еще специфика в том, я снимаю без операторов на десяток устройств в пяти разных залах, и нет никого кто постоянно следит и может что-то починить… поэтому если трансляция сдохнет, то даже через час она не должна остановить запись на диск.
По моим тестам следующий код работает в Вашем случае, протестировать на задержки в сети не было возможности, единственно — если при этом именно рвётся связь (падает принимающая сторона, например), то всё тоже естественно останавливается:
Самый безопасный с точки зрения записи вариант — воспользоваться тем же nginx-rtmp-module в качестве ретранслятора по этой директиве. В таком случае все проблемы с сетью будут Вам без разницы. С этим модулем уже год как работаем, проблем никогда не было, на днях выдержали 16 часовую трансляцию без единого сбоя, только без записи файла на стороне gstreamer, несжатый поток нам не нужен, и для устойчивости вынес запись на nginx.
К сожалению, прямого варианта не нашел, rtmpsink в случае прекращения приёма на другой стороне заканчивает работу.
gst-launch audiotestsrc ! \
tee name=at ! queue ! audioresample ! voaacenc bitrate=64 ! audio/mpeg,rate=22050,channels=1 ! flvmux streamable=1 name=mux \
videotestsrc ! tee name=vt ! queue ! videorate ! videoscale ! x264enc bitrate=700 tune=zerolatency pass=17 ! \
mux. mux. ! queue ! rtmpsink location="rtmp://localhost/live/test" at. !\
queue ! filesink location="/tmp/aud.audio" vt. ! \
queue ! filesink location="/tmp/vid.video"
Самый безопасный с точки зрения записи вариант — воспользоваться тем же nginx-rtmp-module в качестве ретранслятора по этой директиве. В таком случае все проблемы с сетью будут Вам без разницы. С этим модулем уже год как работаем, проблем никогда не было, на днях выдержали 16 часовую трансляцию без единого сбоя, только без записи файла на стороне gstreamer, несжатый поток нам не нужен, и для устойчивости вынес запись на nginx.
К сожалению, прямого варианта не нашел, rtmpsink в случае прекращения приёма на другой стороне заканчивает работу.
надо будет сравнить разницу c ffmpeg. Отпишу позже результат
Советую глянуть вот этот плагин для gstreamer
gitorious.org/vaapi/gstreamer-vaapi/
с ним планшет на атоме 2014 года выпуска отлично справляется с трансляцией full hd потока и при этом остаётся холодным.
gitorious.org/vaapi/gstreamer-vaapi/
с ним планшет на атоме 2014 года выпуска отлично справляется с трансляцией full hd потока и при этом остаётся холодным.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Отладка и оптимизация скриптов gstreamer на примере онлайн трансляции (live streaming)