Представьте, что вы — индус на отшибе мира, у которого старенький ноутбук 2016–2017 года. Вам захотелось записать на YouTube видео с вашего компа, но вот незадача — OBS заставляет ваш ноутбук задыхаться. Bandicam платный, а бесплатной версией себя долго не помучаешь. Как насчёт других аналогов? А вот фигушки! Если брать тот же ShareX, то он не дружит с играми и жрёт кадры.
В принципе, любой рекордер жрёт кадры, это неизбежно. Мораль проста: OBS идеален, если у тебя хороший ПК. А если нет... ну, тут ничего не поделаешь. Это не вина OBS — он решает другие задачи. Но для слабого железа нужен другой инструмент.
И после одной такой мысли я подумал: а как решить эту проблему? Я живу по принципу «Критикуешь — предлагай», и я предлагаю свою программу — HomRec, которая решила мою проблему с OBS. Она полностью опенсорсная, есть на GitHub и бесплатна для каждого. Я написал её полностью на C++, она работает с помощью ffmpeg и, как мне кажется, вообще ничем не уступает по качеству записи. А вот интерфейс знатно хромает.
Все тесты проходили на моём железе, кому интересны характеристики они ниже:
Intel Core i3 -1005G1 CPU @ 1.20GHz,
8GB DDR4
Intel UHD Graphics
Настройки у обоих программ одинаковые: 1280x720@30fps
Внутри программы всё устроено достаточно просто. Настройки помогают указать, как запись будет вестись: разрешение, частота кадров, кодек, куда сохранять файл и т.п. Никакой магии: открыл, выставил под себя, записываешь. По умолчанию уже стоит рабочий пресет, так что для старта достаточно просто нажать запись.
Отдельно есть оверлеи. Они исполняют базовые потребности: можно прикрепить картинку поверх экрана, вывести наложение действий клавиатуры, добавить текст. Это не полноценный редактор сцен как в OBS, но для записи геймплея или туториала вполне достаточно.
Дальше я вообще вошёл в азарт и внутри появился свой терминал. Через него можно выполнять разные задачи: управлять записью, вызывать плагины, а ещё там есть пакетный менеджер hom, через который ставятся дополнительные модули. Выглядит это проще, чем звучит: зашёл, написал команду — плагин установлен. Подробнее про команды и возможности позже распишу в документации.
Кстати, по поводу плагинов — они тоже присутствуют, как вы, скорее всего, уже поняли. Пишутся они на Lua 5.4. Изначально я планировал сделать для этого Python, но решил, что Lua больше подходит.
Я планирую выпускать обновления достаточно часто, как минимум потому, что я сам пользуюсь этой программой и мне тоже нужно больше функций. К слову, если вам понадобится что-то подобное, а его не будет — напишите в Issue на GitHub. Там сейчас ничего нет, но я обязательно прочитаю, если там что-нибудь появится ;)
Если у вас слабое железо и вы искали лёгкий рекордер — попробуйте. Исходники открыты, предложения и баги — в Issues.
Комментарии (12)
pxs_dev
29.08.2026 08:54Здравствуйте, я разработчик открытого магазина приложений FlowStore. Вы будете не против если я добавлю вашу программу в каталог? Все будет скачиваться строго через ваш GitHub. Кстати, протестировал программу. Работает реально быстро!
nickmanecannotbeempty
29.08.2026 08:54TL;DR - "я написал очередной лончер ffmpeg для записи с экрана". Okay...
homa4 Автор
29.08.2026 08:54Ага, а OBS это "лончер ffmpeg с GUI", удобно такое сказать про любую программу, да? ;-)
Newpson
У меня ультрабюджетный ноутбук на Intel N100. И вот уж OBS его задыхаться точно не заставляет, в режиме записи 1920x1080@60 потребляет максимум процентов 10 процессорного времени.
Вы же используете аппаратное ускорение кодирования видео при записи? Используете же? Если следовать вашей истории про индуса, то разность в качестве аппартного и софтверного кодирования не играет роли, тогда почему бы и да?
homa4 Автор
Да, всё включается само, без всяких переключателей. При запуске программа по очереди проверяет кодеки Nvidia, AMD и Intel - и если хоть один работает, молча использует его вместо обычного программного. От вас ничего не нужно, если вы сами не выбрали кодек вручную.
По качеству: x264 при том же битрейте обычно жмёт лучше, чем аппаратные кодеки. Но для записи важнее не грузить процессор, особенно на слабом железе. Поэтому аппаратное ускорение и включено по умолчанию, когда оно доступно.
Изменено:
Забыл добавить: у N100 встроенная графика с Quick Sync, так что в теории аппаратное ускорение там доступно. А вот сработает оно или нет на конкретной машине - зависит от двух вещей: собран ли именно тот ffmpeg, что идёт с программой, с поддержкой QSV (это есть не во всех сборках), и стоит ли на ноутбуке актуальный драйвер Intel Graphics. Если что-то из этого не так, проверка тихо проваливается, и программа откатывается на софтверный кодек - возможно, отсюда и разница с OBS, если она у кого-то будет.
Newpson
так я про OBS и спрашивал, использовался ли там аппаратный кодек. Потому что странно называть OBS прожорливым в режиме софтверного кодирования, сравнивая с программой, использующей аппаратное кодирование...
homa4 Автор
Я запутался уже как то даже. Если мы говорим про тесты то ни там ни там я кодеки на настраивал. и там и там все по умолчанию, изменил лишь разрешение видео и фпс. Хотя наверное стоило бы
VBDUnit
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. Софт огонь, попробую устроить ему стресс‑тест