Скрин-каст.

ffmpeg

Можешь попробовать OBS - крайне популярен под оффтопик, вроде как есть версия под линух: https://obsproject.com/

ffmpeg. Видеокодек рекомендую использовать qtrle, если место на харде есть. Он практически не жрёт проц, и он lossless. В реалтайме снимаешь в него, дабы не проседал fps, а потом уже жмёшь хоть в h264, хоть во что нравится с хорошим коэффициентом сжатия и медленно для конечного распространения.

Вот так я пишу:

ffmpeg -f x11grab -r 25 -s 1920x1080 -i :0.0 -vcodec qtrle -r 25 -f mov filename.mov

где -r 25 — частота кадров видеоролика. То, что указано два раза — не ошибка, первый раз указывается для съёмки с экрана, а второй — для записи в ролик. -s 1920x1080 — разрешение. Формат этому кодеку нужен mov.

А в реалтайме жать сразу в конечный формат — не дело. Будет во-первых качество говно, во-вторых нагрузка на проц (и следовательно проседание фпс).

Если юзать SSR с glinject, то производительность падает незначительно.

не слушай людей, которые советуют ffmpeg для записи экрана.

Я на этом собаку съел. Посему коротко: НЕ используй его. Могу объяснить очень подробно всё, что касается этой темы.

Бери OBS и горя не знай. Благо, он нормально написан, у онтопиковой версии другая кодовая база (что не может не радовать).

Я лично писал 60фпс fullhd с 4 канальным звуком (2 на вход и 2 на выход), при этом еще и игра работала. Комп не топовый.

Почему? Ffmpeg в x264 ultrafast вполне хорош, не нагружает сpu и не мусорит диск как формат qtrle. Psych218

Могу объяснить очень подробно всё, что касается этой темы.

Ну и почему же не использовать ffmpeg? Пишу всегда им и горя не знаю. Всегда лучше иметь записи в lossless, а потом уже без всякого реалтайма и ультрафастов, гробящих качество, спокойно жать в любой кодек.

Насчёт OBS ничгео не скажу — не пользовался, ибо не понимаю, зачем, у ffmpeg нет недостатков (по крайней мере я их не нашёл).

OBS сам разве не использует ffmpeg?

Дано: компьютер.
Задача: захватить экран (1920x1080) и кодировать поток (30 фпс) с него в h264.
Выполняю с помощью ffmpeg - вроде бы всё нормально... Как только запускаю игру - начинает проседать фпс. Причём достаточно заметно.
Выполняю на этой же системе запись при помощи OBS - и о чудо! Мало того, что запись идет идеально, так еще и на 60фпс хватает, и на звук (который пшшшшаудио, ага)!

Что я делаю не так?

Хочу дополнительно обратить внимание, что за всю свою историю ффмпег-захвата экрана я использовал:

1) Различные билды, версии ffmpeg под разными ОС
2) Различные пресеты и доп. опции кодирования
3) Различные форматы и кодеки.

Хочу также заметить, что при достаточном IO (например отдельный жесткий диск) нужно писать в какой-нибудь lossless формат, мне лично понравился huffyuv. А из всех опробованных мною форматов с сжатием (неважно каким) самым производительным под онтопиком оказался... x264.

ответил выше

Выполняю с помощью ffmpeg - вроде бы всё нормально... Как только запускаю игру - начинает проседать фпс. Причём достаточно заметно.

Кодек-то какой? Тут важно, не какая программа, а какой кодек. А пока эти утверждения — не более, чем сравнение сферических коней в вакууме.

P.S. у меня ничего не проседает на ffmpeg, разница в fps в играх с ним и без него в пределах погрешности. Арч, ffmpeg из реп.

OBS сам разве не использует ffmpeg?

ffmpeg - многостаночник в вопросе видео если что.
OBS напрямую использует либы, которые использует ffmpeg (такие как libsw* и libav*).

Кодек-то какой?

кодек - h264, энкодер - x264

Ну да, если в реалтайме жать в h264, будет тормозить. ИЛИ будет качество говно. Два варианта, хоть какую программу используй, магии не случится. Третий только на кластере запускать. Для нормального качества/сжатия h264 надо жать не в реалтайме, он жмёт медленнее, чем fps в видео. Посему оптимальным вариантом и является запись в lossless, а потом уже для конечного использования не в реалтайме сжатие x264. Разница между OBS и ffmpeg наверняка была в параметрах для x264.

если есть карта интела можно жать h264 аппаратно через gstreamer-vaapi, нвидия тож умеет через ffmpeg, amd через gst-omx

Ну да, если в реалтайме жать в h264, будет тормозить. ИЛИ будет качество говно.

я в реалтайме жал пресетом lossless_ultrafast

Третий только на кластере запускать.

В самом конце я так и делал :)
Запустил сервак (16 ядер по 3ггц), подключил к нему dual band gigabit ethernet, забирал pipe из netcat поток, кодировал с нужными параметрами. Прикол в том, что сам ffmpeg (с каким бы кодеком не жал) грузит проц. И вероятнее всего это свзяно с самой архитектурой ffmpeg и/или x11grab.c(h)

нвидия тож умеет через ffmpeg, amd через gst-omx

о! не подскажешь как заюзать nvidia -> gst-omx?

да никак, только ffmpeg nvenc

Я после многих экспериментов остановился на таком варианте:

ffmpeg  -r 25 -s 1920x1080 -f x11grab -i :0.0 -vcodec libx264 -crf 0 -preset ultrafast  -pix_fmt yuv420p output.mov

25 fps вполне хватает для качественной картинки. Результаты можно посмотреть здесь.

нужно писать в какой-нибудь lossless формат

не нужно.

лично понравился huffyuv

Пробовал - 60-80 ГБ размер видео + потери времени на конвертацию. На Youtube также можно залить, но будет оооочень долго.

Я конечно попробую OBS, но врядли оно будет лучше.

есть карта интела можно жать h264 аппаратно через gstreamer-vaapi,

Жать или декодировать? Не поделишься готовым pipeline?

Скрин-каст. (комментарий)

Я после многих экспериментов остановился на таком варианте:

я тоже такой же вариант пробовал. Действительно, для скринкастов его хватает. Но не более того.
Подними фпс хотя-бы до 30, запусти какое-то ПО (а лучше всего игру), добавь запись звука. И ощути печаль и грусть.

не нужно

Что значит «не нужно»? Это типичный ЛОР-овский вброс или что? Кому-то, может, и нужно, кому-то и нет.

Я конечно попробую OBS, но врядли оно будет лучше.

ну я ж не настаиваю. Просто делюсь собственным опытом, видео-то писать тебе :)

Пробовал - 60-80 ГБ размер видео + потери времени на конвертацию.

А так — потери качества при этом самом ultrafast, либо раздувания размера конечного видео. Неужели 60–80гб на харде трудно найти для последующей обработки? Если устраивает такое качество, то при сжатии не в реалтайме, а после, можно тоже его получить, но с более низким битрейтом.

видеовыход на видеокарте(hdmi или дублируй монитор на второй выход)
тыкаешь в карту видеозахвата
ноль лагов

конечно чтоб еще и жесткий не нагружать-лучше иметь второй ПК с картой захвата куда все и тыкать,и оттуда уже сливать кудаугодно

банально вобщем

и да карта видеозахвата стоит копейки,также как и самый дешевый пк/сервер(до 10к)

дешевле проапгрейдить комп чем покупать карту видеозахвата. За эти карты цены ломят невменяемые если что.

запусти какое-то ПО (а лучше всего игру), добавь запись звука

Cкринкасты игрушек посмотри в отдельном плейлисте по той же ссылке. Все ок с качеством.

«не нужно»? Это типичный ЛОР-овский вброс

Это просто констатация факта. Нет профита писать в raw, когда можно использовать x264 ultrafast. Возможно последнее x265/vp9/daala его обгоняют уже по качеству и потреблении ресурсов, но надо пробовать.

Просто делюсь собственным опытом

Cпасибо, просто не могу понять почему ты продвигаешь не самый удачный вариант.

Cкринкасты игрушек посмотри в отдельном плейлисте по той же ссылке. Все ок с качеством.

тогда я в упор не могу понять в чём была проблема...

Cпасибо, просто не могу понять почему ты продвигаешь не самый удачный вариант.

для кого-то он может быть как раз удачным. Когда тебе есть куда (и с нужной скоростью) писать, но нагрузка на ЦП критична.

А писал на HDD или SSD?

потери качества при этом самом ultrafast

Почти незаметны на глаз, разве что меряться бенчмарками. 60-80 ГБ найти не проблема, но его потом надо еще и кодировать. Если записывать c x264, то размер более хорош для заливания на youtube (раз так в 5-10 меньше). А уже c youtube можно получить видео более-менее во всех нужных разрешениях и форматах.

Нерентабельно. Проще купить какой-то дешевый 240Гб ssd с длинной гарантией недалеко от дома, чтобы оперативно менять.

avermedia game capture hd 2

Сжимать в реальном времени, я пользуюсь таким, тут много зависит от версии libva и gst-vaapi

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 ! multiqueue ! video/x-raw,format=BGRx,framerate=25/1 ! vaapipostproc format=i420 ! video/x-raw,format=I420,framerate=25/1 ! multiqueue ! vaapiencode_h264 dct8x8=true ! vaapiparse_h264 ! multiqueue ! matroskamux name=muxer muxer. ! progressreport name=Rec_time ! filesink location=/file.mkv

На HDD.

Почти незаметны на глаз

При последующем кодировании из lossless можно получить то же качество, но при меньшем размере.

Можно, но ты теряешь время на кодирование из lossless. А размер сжатого видео не критичен сегодня. Так что профита 0.0, разве что в очень тяжелых играх с низким i/o.

Пишет черный екран и очень сильное потребление CPU, но за пример спасибо.

а если

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 ! multiqueue ! video/x-raw,format=BGRx,framerate=25/1 ! videoconvert ! video/x-raw,format=I420,framerate=25/1 ! multiqueue ! vaapiencode_h264 ! vaapiparse_h264 ! multiqueue ! matroskamux name=muxer muxer. ! progressreport name=Rec_time ! filesink location=/file.mkv

И не тормозило? Или на отдельный хард?

Я пробовал с помощью PlayClaw в оффтопике писать с замоденного по самые уши Minecraft в MJPEG. Получилось почти 4 гига на 8 минут.

А что нужно сделать, чтобы в gst-launch появилось omxh264enc? gst-omx вроде установлен.

посмотреть нет ли их в блеклисте

gst-inspect-1.0 -b

и дальше по инструкции

http://www.gearsongallium.com/?p=1238

Это починил, дальше ядро ругается:

[drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[drm:radeon_vce_cs_reloc [radeon]] *ERROR* buffer to small (6914048 / 13824000)

С ресурсами все стало очень хорошо, но пишет дальше одну черноту. vaapi работает, как и в предыдущем варианте. libva 1.5.1, gstreamer1-vaapi 0.5.10

Блин, у меня экран слишком большой xD 3840x1200 не хочет писать. Некоторые окна тоже, но я так понимаю, у них соотношение сторон нехорошее.

ну перед енкодером можно вставить скеил и ресайзить до нужного, мож тогда будет пахать

Не тормозило. Хард отдельный, да, не тот, на котором запускаемая игра, а ОС вообще на SSD.

Я ничего не трачу, я запускаю команду, мне компуктер делает результат. И как-то без разницы, сколько оно займёт. Задачи СРОЧНО ПРЯМ СЕЙЧАС опубликовать какое-то видео ни разу не стояло. Для таких случаев да, можно в реалтайме.

а можно только половину экрана записать? Например, только с 1 монитора? Я не понял, как захват экрана в этом gst-launch настраивается.
Пробовал разные настройки отсюда: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plu... но ничего не помогает

вот так можно скейлить

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 ! multiqueue  ! video/x-raw,format=BGRx,framerate=25/1  ! videoconvert ! videoscale  ! video/x-raw,format=NV12,framerate=25/1,heigth=600,width=800 ! multiqueue ! omxh264enc ! h264parse ! multiqueue ! matroskamux name=muxer muxer. ! progressreport name=Rec_time ! filesink location=/home/rec.mkv

скорее всего

ximagesrc display-name=:0 use-damage=0 startx=0 starty=0 endx=1079 endy=1919

start/end у меня не работало, но я нашел, что можно обрезать ненужное этой штукой: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plu...

Не знаю, на сколько оно влияет на производительность...
Еще такой вопрос: как при этом писать звук? С sink monitor пульсы.

странно что не работает, я с доты карту спокойно на 2 монитор мапил через старт\енд

gst-launch-1.0 -f ximagesrc display-name=:0 use-damage=0 startx=10 starty=812 endx=286 endy=1068 ! multiqueue ! videorate max-rate=10 ! glimagesink

звук да, через пульсу, у меня как-то так

gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 ! multiqueue ! video/x-raw,format=BGRx,framerate=25/1 ! vaapipostproc format=i420 ! video/x-raw,format=I420,framerate=25/1 ! multiqueue ! vaapiencode_h264 dct8x8=true ! vaapiparse_h264 ! multiqueue ! matroskamux name=muxer pulsesrc device-name=alsa_output.pci-0000_00_1b.0.analog-stereo.monitor ! audio/x-raw,channels=2 ! multiqueue ! vorbisenc quality=0.4 ! multiqueue ! muxer. muxer. ! progressreport name=Rec_time ! filesink location=/home/pont/rec_2015-09-16_184502.mkv

device-name,берется из

pacmd list | sed -n «s/.*<\(.*\\.monitor\)>/\\1/p» | head -1

Я нечего не понял. Есть какая-то русскоязычная документация по gst-launch? Не понимаю сам принцип, в котором надо располагать опции.