Очевидный nvenc_h264

Незнаю, имеет ли проц аппаратное ускорение h264, отдельной видеокарты нет.

Поддерживает, через intel quick sync.

(H.264)

-preset ultrafast
спасет отца русской демократии

Theora

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

20 минут сколько весят в итоге?

lossless энкодеры — самый кошерный вариант. Пожать можно и потом. Но это если есть запас места.

Ещё можно попробовать MPEG2

20 минут сколько весят в итоге?

Очень сильно зависит от того, что на экране происходит, насколько сильно изменяется изображение. В динамичных играх получается около 150 мбит/с. То есть, 20 минут выходит 20*60*150000000/8/1024/1024 ≈ 21467 Мб. По гигу с небольшим на минуту, короче, если динамичное. Если снимать, скажем, десктоп с терминалом и подобным, как всякие команды вводятся, то где-то в 10–20 раз меньше.

ставь gstreamer vaapi и не мучайся, будет тебе фуллхд 60 фпс сразу в h264.

Попробуй mjpeg. Типа: ffmpeg -i blablabla... -c:v mjpeg -q:v 1 blabla.... Битрейт, правда, тоже при 60 фпс ой какой большой получается. У меня аж 100 с лишним мегабит/с. Да и проц жрёт. H.264 лучше, в общем. Во, кстати, старый добрый mpeg4 не так напрягает проц. Битрейт около 15 Мбит/с. Тоже, много, конечно, но это не 100. Также ... -c:v mpeg4 -q:v 1 ....

Странный совет.

Я вот думаю RLE и всякие lossless как выше советовали куда интереснее, чем mjpeg.

avconv обратно открыть qtrle не смог для перекодирования. Выше 43 fps не поднялось при записи происходящего в браузере webgl-мельтешения. Возможно OpenGL работающий как-то сильно мешает или сцена сложная.

Ещё попробовал вот такую тему:

avconv -y -f x11grab -r 60 -s 1280x720 -i :0.0+2,110 -vcodec libx264 -pre lossless_ultrafast -threads 0 /tmp/output.mkv

Терминал на 60fps пишет без нагрузки на проц, а мою хрень - на 36...43 fps максимум.

Странный совет.

Нормальный совет. У тебя встроенное видео в процессоре есть? Кодить оно умеет?

ну страдай тогда со всякими ffmpeg, че уж тут сказать.

ntfs сжатие

Сохранять кодеком без сжатия + сжатая файловая система. Хотя в линуксе со сжатием непонятно. В виндовс использовал нтфс-сжатие. Ну можно через сеть в вирт. комп с windows по самбе сохранять. Должно прокатить.

Кстати, у меня при кодировании через GStreamer цвета меняются. Я понимаю, что NV12 не эквивалентно сырому RGB, но всё равно в глаза бросается. Может, есть какая-то магия, сохраняющая цвета по максимуму?

ну есть еще i420, и что используется для видеоконверта? стандартный videoconvert или vaapipostproc, даже замечал что качество меняется если указывать или не указывать свойство format для vaapipostproc

Как-то так:

ximagesrc use-damage=1 ! videoconvert ! video/x-raw,format=NV12,framerate=25/1 ! \
vaapih264enc ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse ! \
matroskamux ! progressreport ! \
filesink location=`date +"/tmp/screen-recoring-%Y%m%d-%H%M%S.mkv"`

I420 ситуацию не меняет вообще никак. Да и вряд ли просто смена поможет, ведь все NV12, YV12, I420 отличаются только тем, где сами значения U и V хранятся.

а если так

ximagesrc use-damage=1 ! vaapipostproc ! video/x-raw,format=NV12,framerate=25/1 ! \
vaapih264enc ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse ! \
matroskamux ! progressreport ! \
filesink location=`date +"/tmp/screen-recoring-%Y%m%d-%H%M%S.mkv"`

ximagesrc use-damage=1 ! vaapipostproc format=i420 ! video/x-raw,framerate=25/1 ! \
vaapih264enc ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse ! \
matroskamux ! progressreport ! \
filesink location=`date +"/tmp/screen-recoring-%Y%m%d-%H%M%S.mkv"`

До меня, кажется, начало доходить. Проблема в снижении разрешения цвета вдвое. В варианте с videoconvert цвета усредняются, но от этого цвет текста смазывается. В варианте с vaapipostproc цвета просто берутся как есть из точек. Из-за этого пропадают вертикальные линии в красной обводке сообщений на LOR'е, но зато цвета текста ближе к тому, что я обычно вижу.

В остальном разницы я не заметил, но всё равно спасибо за время.

Врубай венду и используй свободный кодек Lagarith. На линукс его некому с плюсов на плюсы портировать.

Ребят, вот вы советуете эти лосслесы, а вы попробуйте сграбить фулскрин при 60 фпс, какой там битрейт? 100? Чего? Мегабайт в одну секнду? Куда это складывать-то? Даже пяиминутный ролик вытянет в 30 гигов. Это с huffyuv, но с lagarith будет немногим легче, к тому же он гораздо сильнее нагружает процессор.

Я за mpeg4. Старый добрый mpeg4 part 2.

Необучаемые всё продолжали советовать софтварное уг, когда у него есть аппаратный кодер специально для таких задач.

Про многотерабайтные HDD слышал?

Ребят, вот вы советуете эти лосслесы, а вы попробуйте сграбить фулскрин при 60 фпс, какой там битрейт? 100? Чего? Мегабайт в одну секнду? Куда это складывать-то? Даже пяиминутный ролик вытянет в 30 гигов.

И нормально. Больше не всегда и надо. Потом отрежешь не нужное и качество от этой операции не пострадает, внезапно. И если через несколько лет потребуется пережать в новый кодек с потерями, то не придётся последовательно кодировать разными потерьными кодеками.

Это с huffyuv, но с lagarith будет немногим легче, к тому же он гораздо сильнее нагружает процессор.

Лагарифм работает со многими цветовыми палитрами - выбирай что надо а не что дали, тем и пользуйся, матерясь. FFV1 тормозит намного сильнее и работает в один поток, а лагарифм, в нескольких, и разработан он был несколько лет назад, и уже тогда мощности среднего компа для него хватало.

Я за mpeg4. Старый добрый mpeg4 part 2.

Когда ничего больше нет, или железо не тянет, ничего другого и не остаётся.

Используйте ffmpeg вместо avconv, что-то вроде:

ffmpeg -video_size 1200x720 -framerate 60 -f x11grab -i :0 -c:v libx264 -crf 18 -preset veryfast testvideo.mkv

Если все еще будет не слишком быстро, то veryfast можно на superfast заменить.

Ты умеешь патчить DEB-ки? Ну там sudo apt-get build-dep gstreamer, mkdir build && cd build, apt-get source gstreamer, patch -p1 < ssr-videoconvert.patch, fakeroot ./debian/rules binary

Если да - используй Gstreamer-vaapi, проц почти не используется. Только надо пропатчить патчами хорошего проекта Gears On Gallium.

Если не умеешь - используй Simple Screen Recorder. Но кастомная сборка Gstreamer лучше!

Проблема действительно в цветовой субдискретизации. Нужно использовать цветовое пространство без субдискретизации, ну или с меньшей. Так что попробуйте поиграться с форматом, скажем, Y444, или вообще RGB. Мой старый Intel не хочет железно кодировать такое.

Аппаратные кодеки H.264 вряд ли что-то кроме 4:2:0 будут поддерживать. Слишком специфично, почти никому не нужно.

Для меня странные цвета не то чтобы действительно проблемой были, просто всегда замечал, что они странные, но было лень копать до причин.

Мой старый Intel Sandy Bridge не умеет, а вот AMD, вроде, поддерживает 4:2:2 и 4:4:4.

Маловероятно что ктото аппаратно поддерживал 4:2:2 и тем более 4:4:4. Просто в этом нету смысла, в H264 (как и во многих других кодеках) жмется только Y компонента, а UV сохраняют как есть. Тоесть сам кодек заточен под 4:2:0 - если начинать жать в 4:4:4 то битрейт вырастит очень сильно ...

процом - x264

а вообще, пиши obs

лосслесс

QT RLE, как советовали выше, в этом плане действительно лучше, особенно на статичных сценах.

Кстати, huffyuv очень хорошо жмётся архиватором. Статичные сцены раз в 500 и больше можно сжать. Из 1.6 ГБ видео, продолжительностью 22.5 секунды, у меня вышел .lrz файл размером всего 3.1 МБ.

У ffmpeg есть кодер libx264rgb. Не пробовал, правда, воспроизводить в плеерах, но цвета кодит корректно. Формат пиксела выбирается bgr0 (24 бита). Обратный декодинг тем же ffmpeg'ом в PNG показывает, что всё ок.

Там ещё и лосслесс пресет есть.

Можно и -pix_fmt yuv444p

Внезапно, лучший в этом плане — Microsoft Video 1. Правда, в ffmpeg его реализация очень плохая, такая, что лучше бы ее вообще не было. У меня есть 11-минутный скринкаст, который в 7-zip-архиве весит 1.6 МБ.

Но он же lossy, не?

Да.

Это спецолимпиада такая, вместо сжатия в кодеке использовать архиватор?

Это скринкаст 2006 года, записанный на слабом компьютере. Я его недавно откопал, и он меня очень удивил своим размером. Выглядит очень прилично, никаких блочных артефактов, размер очень маленький, 15 кадров в секунду при разрешении 1280×1024.

Кстати, huffyuv очень хорошо жмётся архиватором.

Значит кодек для современного железа необходимо дорабатывать, потому что он сам архиватор для видео, а тут оказывается что плохо архивирует. Решение есть но некому портировать его из виндовых плюсов на линуксовые. Кстати, отличный копроматик, когда кто-то начинает орать «твой ЯП говно потому что не плюсы и на них не похож».

жмется только Y компонента, а UV сохраняют как есть

А как же chroma prediction?

Prediction - это способ компресси данных (Prediction - LRE), он не приводит к частичной потерии информации, как следствие он не может гарантировать сжатие данных.

LRE — это что?

он не приводит к частичной потерии информации

То есть ты имел в виду, что квантования chroma компонент не производится? Это было бы очень странно, так как смысла в детальной chroma при смазанной luma нет. Глупо тратить место на бесполезные данные.

вон в ffmpeg впилили vaapi(в avconv есть давно), работает не плохо, немного тестов и инструкция: http://www.gearsongallium.com/?p=3135

Прошу прощения не LRE а RLE - Run-length encoding

Да chroma не квантуется (и вообще не подвергается DCT), смысл ее квантовать когда у нас в I420 на 4 Y пикселя только 1UV + квантование ведь идет по частотным состовляющим, а если произвести DCT по UV которые уже сильно разрежены то искажения будут довольно существенные.

Странно. Я в описании H.264 неоднократно видел: «The value of QP C for a chroma component is determined from the current value of QP Y and the value of chroma_qp_index_offset (for Cb) or second_chroma_qp_index_offset (for Cr).»

Или ты о конкретной реализации кодера говоришь?