Проект 8mb.local повторяет сценарий популярного онлайн-сервиса 8mb.video, который ужимает ролики под лимиты мессенджеров, но делает это полностью на вашей машине: файлы не загружаются на сторонние серверы. Внутри FFmpeg 6.1.1 с аппаратным кодированием на GPU и автоперекодированием при промахе мимо целевого размера, а запуск сводится к одной Docker-команде либо Windows-установщику. Docker-образ проекта уже скачивали около 570 тыс. раз, однако заявления о качестве сжатия пока не подтверждены измерениями.

image
image
image

Что произошло

Представлен 8mb.local — self-hosted веб-версия онлайн-сервиса 8mb.video для сжатия видео под лимиты мессенджеров, а в августе 2026 года у проекта вышла версия v142 под названием «Faster Hardware Encoding, Reliable GPU Detection, and Improved Job Recovery». Интерфейс построен на SvelteKit, серверная часть — на FastAPI с очередью задач Celery и Redis, прогресс кодирования транслируется в реальном времени через SSE. Под капотом FFmpeg 6.1.1: аппаратное кодирование через NVIDIA NVENC, Intel Quick Sync и AMD AMF на Windows либо VAAPI на Linux с автоматическим откатом на CPU-кодеки x264, x265 и SVT-AV1; поддерживаются кодеки AV1, HEVC (H.265) и H.264 в контейнерах MP4 и MKV. Целевой размер задаётся пресетами 8, 25, 50 и 100 МБ, и если результат превышает цель более чем на 2%, файл автоматически перекодируется с меньшим битрейтом. Поднять сервис можно одной Docker-командой: образ jms1717/8mblocal размещён на Docker Hub, набрал около 570 тыс. загрузок, веб-интерфейс слушает порт 8001; для Windows есть нативный установщик с WebView2 без Docker.

Контекст

Оригинальный 8mb.video решает бытовую задачу — вписать видео в ограничения Discord и мессенджеров, но взамен требует загрузить файл на чужие серверы и мириться с их очередями. 8mb.local переносит этот сценарий на собственное железо, что вписывается в устойчивый тренд локализации облачных утилит: тонкие SaaS-обёртки вокруг FFmpeg теряют преимущество, а раздача одной Docker-командой приносит сотни тысяч установок почти без маркетинговых затрат. Алгоритмической новизны в проекте нет: весь «интеллект» — это системная интеграция готового FFmpeg с аппаратными энкодерами, а ценность строится на приватности и удобстве, а не на новом методе сжатия. При этом это фича, а не бизнес: видимой монетизации у проекта нет.

Почему это важно для индустрии

Для билдеров это воспроизводимый шаблон local-first утилиты: схема «веб-интерфейс плюс очередь задач плюс FFmpeg с GPU-кодированием» собрана из общедоступных компонентов и показывает, как упаковать тяжёлую локальную обработку медиа в обычный веб-сервис с SSE-прогрессом и HTTP API. Folder Watch и API превращают сжатие видео в вызываемый шаг автоматизации, а UX-паттерн «подгони под размер» с пресетами и автоперекодированием можно переиспользовать в пайплайнах публикации контента. Для облачных сервисов сжатия это эрозия ценности формата «загрузите файл к нам»: скорость локального GPU ограничена только железом, и если тренд продолжится, по той же формуле ожидаемо появятся self-hosted аналоги других популярных онлайн-утилит. Есть и ограничитель: некоммерческая лицензия CC BY-NC 4.0 мешает встраивать проект в коммерческие продукты и, вероятно, удержит его в любительской нише.

Почему это важно для пользователей

Чтобы ужать видео под лимит Discord или мессенджера, не обязательно заливать оригинал в облако: сервис поднимается одной командой docker run с образом jms1717/8mblocal — веб-интерфейс откроется на порту 8001 — либо ставится Windows-версия с WebView2 без Docker. Внутри пакетная обработка, обрезка, выбор кодека (AV1 на RTX 40 и 50 даёт лучшее качество при том же размере файла), Folder Watch для автосжатия целой папки и живые логи FFmpeg. Очередей и лимитов нет, целевой размер выбирается готовыми пресетами, а локальное сжатие обычно быстрее, чем выгрузка исходника на сторонний сервис. Практические нюансы: для NVENC нужен драйвер NVIDIA версии 550 или новее, на macOS доступен только CPU-режим, а качество результата придётся оценивать на глаз — встроенных измерителей в проекте нет.

Что пока неизвестно / ограничения

Около 570 тыс. загрузок образа и 904 звезды на GitHub — сигналы интереса, а не доказательства качества сжатия. Формулировка «надёжные алгоритмы сжатия без потери качества там, где это возможно» остаётся маркетинговой: сжатие под целевой размер по определению lossy, и в источниках нет ни метрик вроде VMAF или SSIM, ни сравнительных замеров скорости. Автоперекодирование с меньшим битрейтом при превышении цели более чем на 2% — жадный контроль битрейта без заявленных гарантий сходимости и без учёта итогового качества, поэтому при жёстком лимите картинка может заметно деградировать. Утверждения релиза v142 о скорости и надёжности не сопровождаются методикой измерений, так что их воспроизводимость по доступным данным проверить нельзя.

Источники

Автор

Look at AI, редакция