Comments 23
вот незадача — OBS заставляет ваш ноутбук задыхаться
У меня ультрабюджетный ноутбук на Intel N100. И вот уж OBS его задыхаться точно не заставляет, в режиме записи 1920x1080@60 потребляет максимум процентов 10 процессорного времени.
Вы же используете аппаратное ускорение кодирования видео при записи? Используете же? Если следовать вашей истории про индуса, то разность в качестве аппартного и софтверного кодирования не играет роли, тогда почему бы и да?
Да, всё включается само, без всяких переключателей. При запуске программа по очереди проверяет кодеки Nvidia, AMD и Intel - и если хоть один работает, молча использует его вместо обычного программного. От вас ничего не нужно, если вы сами не выбрали кодек вручную.
По качеству: x264 при том же битрейте обычно жмёт лучше, чем аппаратные кодеки. Но для записи важнее не грузить процессор, особенно на слабом железе. Поэтому аппаратное ускорение и включено по умолчанию, когда оно доступно.
Изменено:
Забыл добавить: у N100 встроенная графика с Quick Sync, так что в теории аппаратное ускорение там доступно. А вот сработает оно или нет на конкретной машине - зависит от двух вещей: собран ли именно тот ffmpeg, что идёт с программой, с поддержкой QSV (это есть не во всех сборках), и стоит ли на ноутбуке актуальный драйвер Intel Graphics. Если что-то из этого не так, проверка тихо проваливается, и программа откатывается на софтверный кодек - возможно, отсюда и разница с OBS, если она у кого-то будет.
так я про OBS и спрашивал, использовался ли там аппаратный кодек. Потому что странно называть OBS прожорливым в режиме софтверного кодирования, сравнивая с программой, использующей аппаратное кодирование...
Я запутался уже как то даже. Если мы говорим про тесты то ни там ни там я кодеки на настраивал. и там и там все по умолчанию, изменил лишь разрешение видео и фпс. Хотя наверное стоило бы
100% используется. Сталкивался с подобной проблемой изнутри несколько раз, руками (до эпохи ЛЛМ). Не только непосредственно запись в видео, а просто сам по себе захват рабочего стола.
В общем случае чтобы это работало быстро и меньше грузило комп, нужно, чтобы максимум работы делалось аппаратно (видеокартой например). В очень упрощённом виде картинка рабочего стола в ОС лежит либо в видеопамяти, либо в общей памяти (если ноут/разделяемая память) в формате RGB. Для видео её надо:
Опционально — отмасштабировать (если разрешение записи отличается от разрешения экрана)
Перегнать из RGB в YCbCr (яркость + дельта красного + дельта синего) — видео в RGB редкость
Сделать субдискретизацию — инфа о яркости в оригинальном разрешении, а о цвете (дельты красного/синего) — в 1/4. Бывает видео и без этой штуки, но оно очень редкое
Закодировать кодеком (H264/H265/AV1 и прочие)
Записать полученную порцию данных на диск
То есть у нас тут участвует куча железяк (проц, оперативка, видеочип, видеопамять, диск) и то, про что все любят забывать — каналы связи между ними.
Если всё делать аппаратно, будет хорошо. Но если выбирать, то самое тяжёлое тут — кодек.
Однако помимо самих вычислений есть ещё проблема перекачки данных между памятью через PCIe — это касается компов где RAM (основная оперативная память) и VRAM (память видеокарты) разделены. Типовой рабочий стол будет создавать поток данных в 1,5 Гбит/с (1920 * 1080 * 30 к/с * 3 канала * 8 бит в байте = 1,492992 гбит/с). Впрочем, компов с общей памятью это тоже касается: просто так копировать такой поток тоже небесплатно.
Так вот. Если реализация всего этого конвейера корявая — она уже на 1 этапе будет копировать всё в RAM, что нагрузит шину, и далее будет грузить CPU предобработкой и кодированием. Если реализация более‑менее вменяемая — она будет делать копирование из VRAM в другую область VRAM (копия рабочего стола), потом делать предобработку, потом копировать в RAM, потом из RAM обратно в VRAM (1,5 + 1,5 гбит/с = 3 гбит/с нагрузки) и там пинать аппаратный кодек. А результат обратно в RAM (впрочем, он уже мелкий) и оттуда в диск.
То есть даже если используется аппаратный кодек там всё равно есть чему положить слабый CPU. Шина памяти узкая (за раз копируется мало), операций копирования нужно вызвать много, всё, приехали. Поток данных толстый — любой лишний мув съедает ресурсы.
И вот если всё делается на месте без копирований — цепляемся напрямую к буферу рабочего стола, не копируем, сразу преобразуем, субдискретизируем и пихаем его в аппаратный кодек тут же на видеокарте, и только потом сжатый поток крошечного размера скидываем в RAM чтобы проц просто скинул его на диск — вот тогда получается вкусно.
Судя по всему — софт автора — это оно.
Но засунуть весь этот конвейер в видеокарту и предусмотреть все возможные конфигурации железа пользователей (разделяемая/общая память, nvenc, quick sync и прочие; разные ОС) — довольно геморное занятие. И автоперебор на тему «что прокатит то юзаем» — это один из вариантов. Правда, нужно чтобы автоматом остальная часть конвейера собиралась под удавшуюся реализацию.
PS. Софт огонь, попробую устроить ему стресс‑тест
Здравствуйте, я разработчик открытого магазина приложений FlowStore. Вы будете не против если я добавлю вашу программу в каталог? Все будет скачиваться строго через ваш GitHub. Кстати, протестировал программу. Работает реально быстро!
Ссылка на проект: https://codeberg.org/PXStudio/FlowStore
Здравствуйте, не против
Отличная прога. Таки не понял, как установить русский язык
TL;DR - "я написал очередной лончер ffmpeg для записи с экрана". Okay...
так и не понял в чем принцип вашего решения и почему OBS так не может… Было бы неплохо разобраться в этом, раз уж пишете об этом статью. А так получается просто самореклама какая-то.
А по скринам и не скажешь что ваша программа особо лучше. Хоть я бы не стал так прямо доверять цифрам в task manager, но там разница в 2 раза примерно.
Это хорошо, но не особо помогает слабым пк. Потому что те же игры на них сжирают скорее всего 90% и тут уже неважно хочет OBS 50% или ваша 30%. Так и так не хватит.
Вы правы, в статье не хватает объяснения, за счёт чего разница. Если коротко: HomRec - это не "OBS с урезанными фичами", а другой подход. OBS - это: сцены, фильтры, рендеринг превью, стриминг. Всё это постоянно работает в фоне, даже если вы просто пишете экран. HomRec делает одну задачу: захват -> кодирование -> файл. Нет рендеринга сцены, нет лишних слоёв. Всё нативно на C++, в одном exe. Поэтому на слабом железе он оставляет больше ресурсов тому, что вы записываете. А ресурсы к слову это не только CPU :)
Кхм. Дергать ffmpeg можно в терминале.
Для простой записи экрана или с вебкамеры реально не нужны ни OBS, ни другой софт. Раньше это было сложновато, сегодня распознать названия источников видео и аудио и склепать простой скрипт для записи потока данных многократно проще, тот же ChatGPT для этого вполне торт.
В целом - неплохо. Но мне хватает встроенной записи экрана в Windows 11
Сразу извиняюсь, я не особо "в теме" как говорится. Никогда не пользовался OBS и даже не видел что это такое. Но для записи экрана или его фрагментов вот уже много лет использую Simple Screen Recorder. Может быть надо было просто использовать его, а не изобретать велосипед?
UPD: sorry, посмотрел, он оказывается только для Linux. А тут как я понял нужен Windows. Просто у меня никогда не было Windows, вот и произошла можно сказать "профдеформация" ;-) -- я на автомате считаю что если что-то есть для Linux, то значит пусть и через пень-колоду, с костылями, но есть и для всего остального.
Simple Screen Recorder - отличная штука для Linux, согласен. но под Windows его нет, а HomRec как раз для Windows. так что велосипед не велосипед, а просто свой вариант для тех, кто сидит на Windows со слабым железом :)
Кстати это решает вопрос по поводу переноса программы под Linux (deb)
Если нужна отличная штука не только под Linux, но и под Windows, то рекомендую vokoscreenNG. Тоже опенсорс, тоже на С++, только использует не ffmpeg, а GStreamer. Не имеет той универсальности как у OBS, но зато из коробки есть туча опций и настроек именно для записи скринкастов. Linux-версии есть как под Иксы, так и под Вейланд.
Я написал программу для записи экрана, которой не нужен мощный ПК