Ландшафт сжатия: lossless и lossy, изображение и видео, production и delivery

TL;DR

Сжатие превращает огромную гору пиксельных данных в файл поменьше, и индустрия делит эту задачу по двум осям: даёт ли файл при распаковке в точности те же байты (lossless) или только приблизительно те же пиксели (lossy, информация выкинута так, чтобы зритель не заметил), и предназначен ли файл для production (монтаж, архив, внутренняя передача) или для delivery (та версия, которую реально смотрит зритель). Ошибиться квадрантом – значит либо переплачивать в десять раз за хранение и трафик, либо уничтожить исходник, который вы как раз должны были сохранить. Сжатие видео фундаментально отличается от сжатия фото: оно использует тот факт, что кадр номер 1 234 почти идентичен кадру номер 1 235 – поэтому час кино сжимается «на пиксель» лучше, чем одна фотография. Эта статья раскладывает весь ландшафт, называет кодеки в каждом углу и даёт правило в одну строчку, которым можно пользоваться без диплома по обработке сигналов.

Зачем это нужно

Если вы делаете, продаёте или эксплуатируете что-то, связанное с видео, каждый файл вашего пайплайна сидит ровно в одном из четырёх квадрантов ландшафта сжатия, и разница в стоимости между правильным и неправильным выбором – минимум порядок величины. Студия, которая мастерит в H.264, сэкономит пару терабайт сегодня и потеряет каждый монтажный проход завтра, когда артефакты начнут стекаться. Стриминговый стартап, который доставляет в ProRes, не выигрывает в качестве и переплачивает CDN бюджет небольшой компании каждый месяц. Эти решения касаются продакт-менеджеров, фаундеров, маркетинга и операционных команд чаще, чем они сами замечают, – потому что любой вопрос «в каком формате?» – это в реальности вопрос о квадранте. К концу статьи вы будете знать названия четырёх квадрантов, кодеки, которые в них живут, и одно правило, которое размещает любой файл в правильном квадранте без догадок.

Две оси ландшафта

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

Первая ось называется точностью. Lossless-кодек – это такой, у которого распакованный файл математически идентичен исходнику, бит в бит, без потерь. Lossy-кодек делает файл меньше, потому что энкодер выбросил часть исходной информации, которую зритель, по предположению автора, не заметит. Размен прямой: lossless сохраняет всё, но сжимает слабо (типично 2:1–4:1), lossy сжимает агрессивно (50:1–1 000:1) ценой невозвратимой потери части информации.

Полезная аналогия: lossless-сжатие – как вакуумный пакет, который ужимает свитер, чтобы он влез в меньший ящик; когда вы вытащите свитер, это будет ровно тот же свитер. Lossy-сжатие – как протокол совещания, в котором записаны все решения, но опущены отвлечённые разговоры; протокол сильно короче, но восстановить по нему оригинальную беседу нельзя.

Вторая ось – назначение. Файл production – это файл, который будут редактировать, грейдить по цвету, перекодировать, ремиксить или класть в архив. Его могут открыть и пересохранить дюжину раз, прежде чем он сделает свою работу. Файл delivery – это версия, которую зритель скачивает или смотрит. Он закодирован один раз, декодируется миллиарды раз и больше не редактируется.

Если положить две оси на одну схему, получится матрица 2×2. Production-lossless – для архивов, лабораторий реставрации и мастер-копий, которые хранят навсегда. Production-lossy (он же «visually lossless» или «мезонинный» / mezzanine) – для монтажа и обмена между студиями, где нужна быстрая прокрутка и чистая перекодировка, но мелкая потеря деталей, которую колорист всё равно не увидит, допустима. Delivery-lossy – то, что получает каждый зритель в мире: Netflix, YouTube, Zoom, ваше CCTV-приложение – всё живёт здесь. Delivery-lossless – крошечный угол для медицинской визуализации, криминалистики, ряда научных приборов; кроме них там почти никого нет.

Нажмите, чтобы увеличить

Сжатие изображений против сжатия видео

Перед тем как обходить квадранты, нужно ещё одно различие, потому что кодеки в каждом квадранте делятся ещё и на «для статичных картинок» и «для движущихся».

Статичное изображение – это один кадр: сетка пикселей без оси времени. Единственная работа компрессора – использовать тот факт, что близкие в пространстве пиксели обычно похожи: небо в верхней половине фотографии – почти один и тот же оттенок синего пиксель за пикселем. Это называется пространственной избыточностью (spatial redundancy). JPEG, PNG, WebP, AVIF и JPEG XL – все это image-кодеки. Они сжимают внутри одного кадра, точка. (Глубже о пространственной избыточности – в статье spatial pixel redundancy.)

Движущееся видео – это последовательность кадров, которая воспроизводится 24+ раза в секунду. Видеокодек умеет всё то же, что и image-кодек: сжать каждый кадр, используя пространственную избыточность, – но получает второй инструмент, которого у image-кодеков нет. Соседние кадры видео обычно почти идентичны. Кадр номер 1 234 в фильме почти такой же, как кадр номер 1 235; различаются только мелкие детали, которые сместились. Компрессор использует это: хранит один полный кадр, а потом – только разницу между ним и следующими несколькими кадрами. Это называется временной избыточностью (temporal redundancy), и именно благодаря ей сжатие видео настолько агрессивнее, чем сжатие фото. 1 (См. temporal pixel correlation – там разобрана сама механика.)

Если применить image-кодек к каждому кадру видео – рассматривать видео как флипбук из JPEG-ов – получится Motion JPEG, MJPEG. Технически это видеокодек, но он игнорирует временную избыточность и платит за это битрейтом в 3–5 раз большим, чем у современного видеокодека при том же визуальном качестве. 2 MJPEG сегодня используется в основном в дешёвых камерах видеонаблюдения и как запасной вариант в научных камерах; его главное достоинство – независимость каждого кадра, что делает монтаж тривиальным. Все остальные мейнстрим-видеокодеки – H.264, H.265, AV1, VP9 – используют временное сжатие и обходят MJPEG с большим запасом.

Практический вывод короток. Если файл – это одна картинка, берёте image-кодек. Если файл – это видео и его не планируется монтировать покадрово, почти всегда берёте видеокодек с временным сжатием. Исключение – квадрант production-lossless из матрицы выше, где часть рабочих процессов до сих пор предпочитает all-intra-видеокодеки (кодеки, которые сжимают каждый кадр независимо), чтобы монтажная программа могла мгновенно прыгнуть на любой кадр. Эти кодеки мы назовём в следующем разделе.

Квадрант 1 – production lossless

Lossless-production-кодеки – это банковская ячейка видеоиндустрии. Их задача – сохранить мастер-копию исходного материала так, чтобы все будущие поколения монтажей, перекодировок и архивных копий могли быть сгенерированы без потери качества. Сжатие умеренное – типично 1,5:1 – 4:1, – потому что кодеку запрещено выбрасывать какую-либо информацию.

Главные кодеки этого угла – FFV1, JPEG 2000 в lossless-режиме, HuffYUV, UT Video, Lagarith для видео плюс PNG, TIFF, lossless WebP и JPEG XL в lossless-режиме для статичных картинок. FFV1 – самый важный. Это lossless intra-frame-видеокодек, open-source, без роялти, стандартизированный IETF как RFC 9043 (FFV1 версий 0, 1, 3). 3 В декабре 2023 года Библиотека Конгресса США повысила FFV1 в контейнере Matroska (.mkv) с уровня «Acceptable» до своего высшего ранга – «Preferred Format» для долгосрочного хранения видео. 4 Большинство национальных вещательных архивов, Библиотека Конгресса и Public Broadcasting в США используют FFV1 в Matroska для архивирования оцифровок аналоговой плёнки и плёночных переводов. Коэффициент сжатия FFV1 на типичном вещательном контенте – между 2:1 и 3:1; этого достаточно, чтобы стоимость архивного хранения была устойчивой, и при этом ни один исходный сэмпл не теряется.

Когда lossless реально нужен: оцифровка аналоговых архивов, научная съёмка (где значения пикселей – это измерения, а не впечатления), криминалистическое видео, медицинская визуализация по DICOM, реставрационные проекты, где мастер должен пережить любую монтажную систему, и любые случаи, где файл представляет истину, а не эстетику.

Когда lossless не нужен: обычный монтаж цифрового материала, где визуально безупречного production-кодека хватит и он будет быстрее и меньше, и любой случай, где 200+ Mbps на хранение трудно оправдать. Частая ошибка: команды тянутся к FFV1, потому что слово «lossless» звучит безопасно, в результате платят за хранение в десять раз больше, чем заплатили бы за visually-lossless мезонин, и в конце пайплайна никакой измеримой пользы не получают.

Квадрант 2 – production lossy (мезонинный / промежуточный уровень)

Здесь живёт большая часть профессиональной видеоработы. Мезонинный кодек – он же intermediate codec – это lossy-кодек, спроектированный быть visually lossless и all-intra. «Visually lossless» означает, что зритель не может уверенно отличить сжатый файл от оригинала на обычном профессиональном мониторе. «All-intra» – что каждый кадр закодирован независимо, без ссылок на другие кадры, ровно как в image-кодеке. Именно all-intra-структура делает файл быстрым на прокрутке, быстрым на повторных кодировках после монтажа и свободным от поколенческой потери качества при многократных пересохранениях. 5

Три имени, которые надо знать в этом квадранте, – Apple ProRes, Avid DNxHD / DNxHR и набирающий силу JPEG XS. ProRes 422 идёт примерно на 147 Mbps на 1080p / 29,97 fps; ProRes 422 HQ – около 220 Mbps; ProRes 422 LT – около 102 Mbps; ProRes 422 Proxy – около 45 Mbps. 6 Старшие профили ProRes (4444 и 4444 XQ) несут альфа-канал и поднимают битрейт выше 500 Mbps на 1080p – используются в VFX-работе. Avid DNxHR – эквивалентное семейство от Avid; HQX 10-бит и HQ соответствуют по качеству ProRes 422 HQ. 7 Netflix явно принимает и ProRes 422 HQ, и DNxHR HQX как форматы доставки от постпродакшен-партнёров. 8

JPEG 2000 в lossy-режиме – доминирующий кодек для цифровой дистрибуции в кинотеатры (Digital Cinema Package, DCP, который получает каждый коммерческий кинозал). Тот же JPEG 2000 – основа SMPTE-формата Interoperable Master Format (IMF), стандартного интерчендж-пакета, в котором студии вроде Netflix и Amazon получают один мастер плюс метаданные с описанием всех региональных версий. 9

JPEG XS – новичок этой группы, стандартизирован как ISO/IEC 21122. Это low-latency, low-complexity, visually-lossless кодек, специально построенный для живого видео по IP-сети. Целевые коэффициенты сжатия – 2:1 – 10:1 при end-to-end-задержке менее одной миллисекунды, что делает его пригодным для broadcast-контрибуции и удалённой режиссуры по SMPTE ST 2110-сетям. 10 AWS Elemental Live добавили JPEG XS для облачной контрибуции в 2023 году, и JPEG XS стал стандартной опцией в любом новом ST 2110-объекте.

Частая ошибка в этом квадранте – путать ProRes и DNxHR с delivery-кодеками. На бумаге они похожи – все они выдают MP4-или-MOV файл, – но ProRes 422 HQ примерно в 40–50 раз тяжелее, чем H.264, который вы доставили бы из него. Отправить ProRes-мастер на телефон зрителя вместо delivery-кодировки – это сжечь его месячный тариф мобильной связи за один спортивный хайлайт.

Нажмите, чтобы увеличить

Квадрант 3 – delivery lossy (то, что видит зритель)

Каждое видео, которое вы когда-либо смотрели на телефоне, ноутбуке или телевизоре, вышло из этого квадранта. Delivery-кодеки сильно оптимизированы, по большей части глубоко запатентованы и награждаются за одно: упаковать максимум воспринимаемого качества в минимум битрейта.

Текущие поколения delivery-кодеков – H.264 / AVC (выпущен в 2003, до сих пор рабочая лошадка открытого интернета), H.265 / HEVC (2013, большой прирост качества, но патентный кошмар), VP9 (Google, 2013, активно используется YouTube), AV1 (AOMedia, 2018, уже мейнстрим) и H.266 / VVC (2020, технически отличный, медленно разворачивается). Каждое поколение даёт примерно на 30–50% лучшее сжатие при том же качестве, что предыдущее, хотя темп улучшений замедляется. 11 (Полный таймлайн – история кодеков H.120 до AV2.)

Современный delivery-кодек сжимает типичный 1080p-поток до 2–8 Mbps – отношение примерно 200:1 – 750:1 к несжатому видео. 1080p-стрим Netflix в H.264 идёт на 4–6 Mbps; 4K HDR в AV1 – на 8–15 Mbps. 12 В декабре 2025 года Netflix сообщил, что AV1 покрывает около 30% всего стриминга, что AV1-сессии потребляют примерно на треть меньше полосы, чем эквивалентные H.264-сессии, и дают на 45% меньше прерываний из-за буферизации. 13 В июле 2025 года Netflix запустил в production AV1 с Film Grain Synthesis (FGS), сообщив, что контент с плёночным зерном идёт примерно на 66% меньшем битрейте, чем без FGS, и при этом ощутимо лучшего качества. 14

Image-эквиваленты этого квадранта – JPEG (1992, рабочая лошадка), WebP (Google, 2010), AVIF (AOMedia, 2019, image-формат на основе AV1) и JPEG XL (ISO/IEC 18181, финализирован в 2021). Lossy-WebP-файлы обычно на 25–34% меньше JPEG-ов при том же качестве. 15 AVIF сжимает ещё агрессивнее, но декодирование дольше; JPEG XL разменивает часть степени сжатия на быстрый декод и lossless-перекодирование из существующих JPEG-ов.

Delivery-кодеки – это место, где живёт большая часть инженерных усилий индустрии, и решения, которые они принимают, касаются затрат, линейно растущих с размером аудитории. Переход стримингового сервиса с H.264 на AV1 типично экономит 30–50% на egress-трафике при том же качестве – реальная регулярная экономия, которая отбивает миграцию за один-два квартала на любом значимом масштабе.

Частая ошибка в этом квадранте – транскодировать между двумя lossy-кодеками не задумываясь о поколенческой потере. Каждый раз, когда lossy-файл декодируется и кодируется заново – H.264 → H.265 или H.264 → H.264 на другом битрейте, – теряется дополнительное качество. Два-три поколения транскодов обычно невидимы, десять – складываются в заметные артефакты. Это техническая причина, по которой production-пайплайны настаивают на lossless или visually-lossless мастере, из которого всё остальное генерируется в один шаг – а не из delivery в delivery.

Квадрант 4 – delivery lossless (крошечный угол)

Четвёртый квадрант существует, но людей в нём очень мало. Delivery-lossless – это стрим, который должен быть восстановлен бит-в-бит на экране зрителя. Битрейты тут слишком высокие для обычных потребительских каналов – 1080p-lossless требует примерно 200 Mbps, – поэтому сценариев, оправдывающих такое, мало.

Реальные обитатели угла: телемедицина и DICOM-совместимые медицинские вьюверы, где регулятор требует пиксель-в-пиксель воспроизведения изображения, использованного для диагноза; криминалистика и судебка, где цепочка доказательств зависит от хэш-идентичного воспроизведения; научные приборы, где значения пикселей – это измерения; вещательные контрибуционные линки между двумя студиями на одной площадке, где полоса фактически бесплатна, а цена любой потери качества – нет. Например, проекты Фора Софт в телемедицине часто требуют lossless DICOM-вьюверного пути рядом с обычным lossy-просмотром: эти два пути сосуществуют, потому что выполняют совершенно разные задачи.

Для всех остальных – каждого потребительского стримингового сервиса, каждой видеоконференции, каждого CCTV-потока, каждого социального видео – delivery-lossless избыточен и в меню не значится. Lossy-delivery-кодеки достигают качества картинки, неотличимого от lossless на телефоне или телевизоре, при менее чем одном проценте битрейта; инженерный и экономический ответ единогласен.

Четыре квадранта в одной сравнительной таблице

Числа выше – типичные для 1080p на современных частотах кадров; и production-, и delivery-битрейты растут примерно линейно с количеством пикселей, поэтому 4K-production-поток ближе к одному гигабиту в секунду.

Правило, помещающееся в одной строке

Весь ландшафт сворачивается в одно предложение, которое можно применить к любому новому файлу.

«Если файл – это источник истины, из которого всё остальное генерируется, берите lossless-кодек; иначе – lossy. Если файл будет отредактирован ещё раз, прежде чем его увидит зритель, берите production-уровень; иначе – delivery.»

Два «да/нет» – четыре ответа – квадрант определён. Правило достаточно острое, чтобы решать большую часть споров, и достаточно тупое, чтобы для его применения не нужен был senior-инженер в комнате. Деталь, какой именно кодек брать внутри квадранта, – предмет отдельных статей: есть сравнительная таблица кодеков и отдельный decision tree по выбору кодека в 2026.

Нажмите, чтобы увеличить

Пайплайн, который связывает четыре квадранта

В нормальном пайплайне «production → delivery» один и тот же материал проходит через три из четырёх квадрантов в строгом порядке, и в реальном цеху никогда не пропускают шаги и не кодируют один и тот же контент дважды в разных lossy-кодеках.

Камера пишет в production-lossy-интермедиат (ProRes, DNxHR или эквивалент производителя). Монтажная система читает с этого интермедиата, применяет нарезку, цветокор, аудио-микс и VFX и выгружает production-lossless-мастер (или близкий к lossless) – золотую копию. Мастер архивируется в production-lossless-квадранте (FFV1 или JPEG 2000 lossless в Matroska- или MXF-обёртке). Транскодер читает мастер один раз и производит каждый delivery-lossy-вариант, который может получить зритель: low-bitrate H.264 как fallback, 1080p H.265 средний уровень, 4K AV1 верхний уровень, аудио-только потоки, отдельные языковые дорожки. Плеер зрителя берёт нужный вариант в реальном времени в зависимости от полосы.

Эта форма «один мастер → много доставок» – и есть причина, по которой production- и delivery-уровни разделены. Если поменять кодек на полпути – взять H.264-файл от контрибьютора и перекодировать в AV1 для delivery, – поколенческая потеря складывается, и вы тратите полосу на артефакты, которых оригинальная камера никогда не записывала. Лекарство всегда одно: вернуться к мастеру и закодировать заново оттуда.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт с 2005 года делает видеопродукты – стриминговые платформы, WebRTC-конференц-связь, OTT- и Internet-TV-приложения, системы видеонаблюдения, e-learning и telemedicine, AR/VR, – и матрица из четырёх квадрантов – это карта, которой мы пользуемся при скоупинге любого нового проекта. Стриминговый стартап обычно живёт в delivery-lossy-квадранте с маленьким production-lossy-следом для генерации превью и трейлеров. OTT-платформа, которая принимает фиды от студий, должна уметь и production-lossy-инджест (ProRes / DNxHR / JPEG 2000), и delivery-lossy на выходе. Продукт видеонаблюдения – delivery-lossy на каждом шаге, но иногда нуждается в forensic-export-пути, который переходит в lossless-обёртку для доказательной базы. Телемедицинскому продукту почти всегда нужен DICOM-совместимый lossless-вьюверный путь рядом с обычным lossy-просмотром. Мы не верим в one-size-fits-all видеостек; матрица выше – причина.

Ключевые выводы

• Сжатие делится по двум осям: lossless / lossy и production / delivery – итого четыре квадранта.
• Lossy-кодек выбрасывает информацию, которую зритель не должен заметить; lossless возвращает каждый исходный бит.
• Сжатие видео обходит сжатие фото, потому что использует похожесть соседних кадров, а не только соседних пикселей.
• Production-кодеки (ProRes, DNxHR, FFV1, JPEG 2000) в ~50× тяжелее delivery-кодеков (H.264, H.265, AV1) и служат совсем другой задаче.
• Правильный кодек определяют два «да/нет»: это источник истины – и будет ли он отредактирован ещё раз.
• Никогда не транскодируйте lossy → lossy, если можно вернуться к мастеру: поколенческая потеря накапливается незаметно, пока вдруг не становится очевидной.

Что читать дальше

• Зачем сжимать видео: математика битрейта
• Spatial pixel redundancy: что внутри одного кадра
• Temporal pixel correlation: избыточность между кадрами