Форматы изображений и видео вроде JPEG, HEIC и AV1 давно стали частью нашей повседневности. Мы снимаем на смартфон, пересылаем фото в мессенджерах, заливаем видео в облако — и редко задумываемся, почему одинаковый кадр может весить в три раза меньше, но выглядеть так же.
Если вы хотите разобраться, как современные кодеки экономят место, почему файлы стали компактнее и зачем это вообще понадобилось, то эта статья для вас.
Историческая справка
Вы наверняка сталкивались с такими словами, как JPEG, PNG, может быть, даже HEIC, но вряд ли задумывались, откуда они взялись и зачем вообще нужны разные форматы изображений. Почему мы не можем просто хранить фото «как есть» — без всех этих сокращений и кодеков? Ответ прост: если бы мы хранили изображения в их исходном виде, даже одна фотография занимала бы сотни мегабайт. Интернет времён 90-х просто не справился бы с таким объёмом данных.
Тогда цифровая фотография переживала момент становления. Память стоила дорого, интернет был медленным, а цифровые камеры снимали в разрешении, которое сегодня бы не впечатлило даже бюджетный домофон с камерой. Тогда и появился JPEG — формат, который буквально спас раннюю цифровую эпоху.
Громкое заявление, да, но не менее громкий формат, который используется везде. Он позволял делать снимки, которые потом влезали на крошечные по современным меркам карточки памяти и при этом выглядели достаточно чётко, чтобы распечатать или отправить по email. Алгоритм сжатия был с потерями, то есть картинка режется, чтобы уменьшить объём. Формат разбивал изображение на блоки и превращал их в набор частот с помощью дискретного косинусного преобразования (DCT), а потом отбрасывал то, что человеческий глаз всё равно не заметит.
Как результат, картинка выглядит всё так же, а файл становился +- в десять раз меньше. Ещё одна крутая фишка — режим Progressive. Изображение сначала отображается в низком качестве и постепенно дорабатывается. В эпоху dial-up-модемов это было как-то так: вы видели, что фото точно загрузится, и могли подождать, пока прогрузится лицо собеседника из ICQ.
С течением времени пользовательский аппетит рос, добавилось высокое качество цветопередачи, поддержка новых функций. Главное, возникла необходимость снизить нагрузку на ограниченные каналы связи мобильных устройств и стримингов. И технологии не стояли на месте. К середине 2010-х JPEG начал сдавать позиции — мобильные камеры снимали в десятки мегапикселей, а видео стало 4K. Apple представила HEIC, основанный на видеокодеке HEVC (H.265). Он вдвое эффективнее по сжатию, поддерживает 16-битный цвет и позволяет хранить не просто снимок, а целую сцену — с Live-эффектом или изменением освещения.
Следующим шагом стал AV1 — формат, разработанный чтобы вырваться из-под патентных ограничений альянсом AOMedia. В него входит Google, Mozilla, Microsoft и другие гиганты. AV1 сжимает данные ещё лучше — примерно на 15% эффективнее HEIC, при этом полностью бесплатен. Сегодня AV1 активно внедряют YouTube, Netflix и браузеры (от Chrome до Firefox).
Его кодирование сложнее и энерговместимее, но это уже не та проблема, что была в 1990-х. Теперь важно другое — чтобы потоковое видео грузилось мгновенно, не ело трафик и не роняло качество при плохом соединении.
Как устроено сжатие в JPEG, HEIC и в современных кодеках вроде AV1
Рассмотрим подробно, как устроено сжатие в наиболее популярных форматах JPEG, HEIC и современных кодеках, таких как AV1, чтобы понять технические принципы блочного и предсказательного сжатия, компенсации движения, трансформаций частоты, а также роль chroma subsampling и quantization. Также объясним, чем отличаются контейнеры от кодеков и почему HEIC использует контейнер HEIF, а AV1 — это преимущественно видеокодек.
Блочное сжатие в JPEG
Многие не знают, что JPEG — это не столько формат, сколько алгоритм. Большинство JPEG-изображений, которые вы видите, представлены в формате JFIF (JPEG File Interchange Format). Внутри JFIF применяется алгоритм сжатия JPEG.
По сути, задача сводится к тому, чтобы: сохранить нужное и выбросить ненужное. Но как сделать так, чтобы глаз не замечал разницы? Сначала картинку переводят из RGB в цветовое пространство YCrCb — там яркость (Y) выделена отдельно от двух цветовых каналов (Cr, Cb), потому что человеческий глаз гораздо чувствительнее к изменениям яркости, чем к мелким цветовым деталям. От этого цветовые каналы можно хранить с большей потерей — это называется chroma subsampling.
Дальше изображение режут на блоки 8×8 пикселей и применяют к каждому блоку дискретное косинусное преобразование (DCT). DCT переводит значения пикселей в «частоты»: в углу матрицы оказываются низкие частоты — крупные формы и фон, в другой части — высокие частоты — шум и мелкие детали. Многие высокочастотные коэффициенты оказываются малыми или близкими к нулю, их можно отбросить практически без видимой потери качества.
Квантование — главный lossy-шаг. Каждую DCT-матрицу делят поэлементно на матрицу квантования и округляют. Чем жёстче квантование, тем больше нулей и тем сильнее сжатие, но тем заметнее артефакты. Именно при агрессивном квантовании появляются характерные квадраты 8×8 и «ореолы» у резких контуров (эффект Гиббса).
После квантования данные считывают «зигзагом». Сначала идут низкие частоты, затем высокие, потом применяют run-length encoding для длинных серий нулей. В конце поток кодируется Хаффманом. Фотографии сжимают в 5–15 раз без явного ухудшения восприятия. Управлять компромиссом «размер ↔ качество» удобно через матрицу квантования или параметр качества.
Сжатие HEIC
Как и JPEG, HEIC возник из практической потребности: сохранить максимум полезной информации при минимуме байтов. Но если JPEG для «отброса незаметного», то HEIC уже контейнер и набор видеотехник, которые позволяют хранить не только изображение, но и сцену, слои и метаданные — аккуратно и компактно.
HEIC — это контейнер HEIF, в котором чаще всего используются кадры, закодированные по видеокодеку HEVC (H.265). Apple впервые сделала HEIC форматом по умолчанию в iOS 11 и macOS High Sierra в 2017 году, и с тех пор он стал массовым в мобильной фотографии. По сути, на нём та же задача — уменьшить объём файлов при сохранении качества. В этом контейнере, в одном файле можно хранить несколько кадров (burst, live photo), вспомогательные изображения (depth map, alpha-канал), слои редактирования и стандартные метаданные (EXIF/XMP). Файл может не только показывать картинку, но и передавать данные для постобработки.
Технически HEIC — это современный формат, который использует более продвинутые технологии сжатия, чем старый JPEG. Вместо фиксированных маленьких блоков HEIC работает с блоками разного размера, что позволяет точнее сохранять детали. Он также применяет разные способы прогнозирования изображения и улучшенные алгоритмы кодирования, например, энтропийное кодирование — CABAC вместо статичного Хаффмана. Благодаря этому файлы HEIC на 40–50% меньше JPEG при том же качестве. Встроенные фильтры уменьшают размытости и искажения, делая картинку чище (deblocking, SAO).
Главные плюсы
Поддержка глубины цвета и HDR — формально стандарт допускает до 16 бит на выборку (хотя на практике большинство устройств оперируют 8/10/12 битами).
Альфа, depth и мультикадры — используется для хранения обычных фотографий, Live Photo, панорам и портретных снимков с глубиной резкости.
Поддержка прозрачности — может хранить изображения с прозрачным фоном. Это нужно для графики, дизайна, веба и приложений с наложением элементов.
Ограничения тоже имеются. HEVC окружён патентными пулами и лицензионной историей, поэтому в некоторых экосистемах нужны или доп. кодеки/расширения, или платная установка (например, HEVC extension в Windows). Да и в реальном обмене иногда удобнее конвертировать в JPEG/PNG.
Современный видеокодек AV1
Любите смотреть видео на YouTube? А вы знали, что скорость загрузки ваших видосиков и то, что их не дёргает каждую секунду, зависит от технологий сжатия и доставки контента?
Один из таких оберегов — AV1. Выпущен он был в 2018 году и стал следующей ветвью после VP9 и HEVC, особенно для интернет-стриминга и высоких разрешений.
Здесь нефиксированные блоки, множество вариантов блочной структуры и размеров трансформов для энкодера. Методы у AV1 продвинутые: он предсказывает содержимое внутри каждого кадра и между кадрами, а также позволяет разбивать видео на блоки разных размеров. Биты распределяются туда, где они важнее. А мы имеем лучшее качество при меньшем битрейте. Он поддерживает 10-битный цвет, HDR и способен передавать видео высокого качества даже при низкой скорости соединения.
Экономия трафика привела к нагрузке на процессор. Сложнее кодирование и воспроизведение → нужен более мощный CPU. Поэтому на старте его внедрение шло медленно. Буст дал рост аппаратной поддержки в GPU и SoC и теперь AV1 на устройствах и в браузерах. Для одиночных изображений используют формат AVIF. Это по сути AV1-кадры в контейнере на базе ISOBMFF, т. к. для фото AVIF даёт лучшее сжатие и расширенные возможности.
Из интересного: AOMedia уже анонсировала следующее поколение, AV2 с датой готовности примерно до конца 2025 года. Авторы заявляют существенный прирост эффективности кодирования — порядка 30% меньшего битрейта при том же качестве по VMAF — а также улучшения для AR/VR, split-screen и работы с контентом экранного типа. Скорее всего, AV2 потребует обновлённой аппаратной поддержки, чтобы раскрыть свои преимущества в массовых сценариях.
Особенность |
HEIC (HEIF + HEVC) |
JPEG (JPG) |
PNG |
|---|---|---|---|
Тип сжатия |
Обычно с потерями (используется HEVC intra-кодирование), поддержка lossless в некоторых случаях |
С потерями (DCT + квантование) |
Без потерь (lossless) |
Глубина цвета |
Теоретически до 16 бит на канал |
В большинстве случаев — 8 бит на канал |
Поддерживает 1, 2, 4, 8 или 16 бит на канал — то есть до 48 бит на пиксель (без альфа) или до 64 бит (с альфа) |
Прозрачность (альфа-канал) |
Поддерживается как дополнительный компонент внутри HEIF-контейнера |
Не поддерживается |
Поддерживается, включая альфа-канал |
Анимация / мультиизображения |
Поддерживает хранение нескольких изображений, серий и живых фото (image sequences в контейнере) |
Нет — одно изображение на файл |
Поддерживается (расширение APNG) |
Метаданные |
Расширенная поддержка: Exif, XMP, метаданные HDR, информация об альфа, глубине, редактировании |
Поддерживает Exif, IPTC, XMP |
Метаданные поддерживаются в текстовых блоках (текстовые чанки) |
Совместимость / распространённость |
Хорошая на современных устройствах iOS / Android; веб и Windows поддержка частичная, требует кодеков/расширений |
Максимальная совместимость — поддерживается почти повсеместно |
Широко поддерживается, особенно в веб и графических инструментах |
Типичное применение |
Смартфон-фото, живые снимки, компактное хранение с дополнительной информацией |
Универсальное фото, обмен, публикации |
Графика, логотипы, интерфейсы, изображения с прозрачностью |
Поддержка HDR / расширенного динамического диапазона |
Возможна (зависит от реализации и метаданных) |
Ограниченная/нетипичная |
Ограниченная |
Размер файла при равном визуальном качестве |
Как правило самый компактный, особенно для фото с деталями |
Средний |
Самый большой (из-за lossless-хранения) |
Причины, почему файлы стали меньше
Если посмотреть на то, почему фото и видео стали занимать меньше места, то всё упирается не в одно изобретение, а в эволюцию сразу нескольких технологий. Сначала — кодеки. Старые форматы, вроде JPEG и H.264, были рассчитаны на другие реалии — тогдашние процессоры, скорости сети и сценарии хранения. Стандарты, вроде HEVC (H.265) и AV1, стали умнее: они используют предсказательное кодирование, когда часть изображения восстанавливается на основе соседних блоков или предыдущих кадров. Теперь применяются переменные размеры макроблоков, адаптивное квантование и сложные модели движения.
Дальше — вычислительные мощности. Ростом производительности CPU и появление аппаратных ускорителей помогли тяжёлым алгоритмам. Сейчас кодирование и декодирование происходит на уровне железа — через встроенные блоки в чипсетах смартфонов и видеокарт. Это не только ускорило обработку, но и снизило энергопотребление. Может, вы не заметили, но аппаратное ускорение стало стандартом: iPhone, Android-смартфоны, YouTube, Netflix — все уже работают с HEVC или AV1 под «капотом».
Ещё одна причина — профили и пресеты кодеков. Кодек — это набор возможностей, а профиль определяет, какие из них будут использованы в конкретном случае. Пресет задаёт баланс между скоростью и качеством. Смартфоны выбирают быстрые инструменты для HEIC, чтобы снимки можно было оперативно загрузить в облако или отправить через мессенджер, без ожидания длительной обработки. Другой профиль применяется для архивных фото или профессиональной печати. Здесь HEIC с меньшей компрессией и более высоким качеством. Видеосервисы делают то же самое: выбирают пресет под конкретное устройство и канал связи, чтобы поток подстраивался под реальные условия сети.
И, наконец, экономия трафика и конкуренция за скорость загрузки сделали уменьшение размера файлов приоритетом не только для производителей, но и для платформ. Telegram, WhatsApp*, Instagram* и другие мессенджеры автоматически перекодируют файлы при отправке, уменьшая разрешение и битрейт с помощью оптимальных профилей, чтобы фото или видео открывались мгновенно и не «весили» лишнего.
Менее популярные механизмы и альтернативы
Конечно, всё, что я перечислил выше, это не единственные форматы. Существуют десятки других инструментов для изображений и видео, каждый со своими особенностями. Вот некоторые примеры.
Изображения
PNG (Portable Network Graphics): Популярен для веб-графики. Поддерживает прозрачность и сжатие без потерь (логотипы, иконки, короче там, где важна чёткость контуров).
GIF (Graphics Interchange Format): Используется для анимации и простых изображений с ограниченным количеством цветов до 256 (анимированные эмоции, мемы, открытки с добрым утром).
WebP: Формат изображений от Google. Сжимает как с потерями (аналог JPEG), так и без потерь (аналог PNG), (поддерживает анимацию и прозрачность).
AVIF: Новый формат, основанный на кодеке AV1.
TIFF (Tagged Image File Format): Используется в полиграфии и профессиональной фотографии. Поддерживает сжатие без потерь, слои и цветовые профили, сохраняя высокое качество.
RAW: Необработанные данные, полученные прямо с матрицы цифровой камеры. Сохраняет максимум информации, позволяя фотографам производить гибкую обработку. Каждый производитель камер может иметь свой RAW-формат (например, CR2, NEF).
SVG (Scalable Vector Graphics): Векторные изображения, можно масштабировать без потери качества.
BMP (Bitmap): Стандартный растровый формат Windows, сохраняющий изображения без сжатия, что приводит к очень большим размерам файлов.
Видеокодеки
H.265 (HEVC): Эффективнее, чем AVC, но непопулярный из-за лицензионных отчислений.
VP9: Кодек, который AV1 превосходит по сжатию на 30% (от Google).
VVC (H.266): Ещё более высокое сжатие, чем AV1, но и более требовательный.
VVC тоже требует лицензионных отчислений, так что может повторить незавидную судьбу HEVC.
Такие механизмы и форматы занимают свои ниши. Они находят себя, например, при работе с контентом в 360°, с анимированными и прозрачными изображениями или в обработке с сохранением максимума деталей.
Небольшой тест
Если провести тест на 700 JPEG-ов общим размером ≈2825 MiB (снимки примерно 4000×3000 пикселей) и пропустить их через современные программы для сжатия на обычном ноутбуке с процессором Pentium Gold, 2 ядрами и 32 ГБ RAM, запустив по два параллельных процесса и отключив многопоточность энкодеров, картина получается такая:
2m05.338s 488MiB AVIF-AOM-s9
6m48.650s 502MiB WebP-m4
8m07.813s 479MiB AVIF-AOM-s8
12m16.149s 467MiB WebP-m6
12m44.386s 752MiB JXL-l0-q85-e4
13m20.361s 1054MiB JXL-l0-q90-e4
18m08.471s 470MiB AVIF-AOM-s7
3m21.332s 2109MiB JXL-l1-q__-e_
14m22.218s 1574MiB JXL-l0-q95-e4
32m28.796s 795MiB JXL-l0-q85-e7
39m4.986ss 695MiB AVIF-RAV1E-s9
53m31.465s 653MiB AVIF-SVT-s9
Кстати, забыл упомянуть, что большинство фото (что-то снятое на улице, страницы журналов и всякие предметы) снималось на средненький Android и такой же средненький фотик от Samsung.
По сочетанию скорости и итогового размера выиграли AVIF (реализация libaom) и WebP. Примеры из прогонов: AVIF-AOM s9 — ~2 мин 05 с и итог 488 MiB; WebP-m4 — ~6 мин 48 с / 502 MiB; AVIF-AOM s8 — ~8 мин 07 с / 479 MiB; при более медленных пресетах WebP (m6) можно получить ещё меньший размер (467 MiB) за счёт времени кодирования. В тех же тестах JPEG-XL чаще получался либо медленнее, либо давал большие файлы — самый быстрый JXL-прогон выглядел как простая «перезапись» без реального перекодирования, а другие конфигурации выдавали значительно большие размеры и дольше шли.
Реализации AV1-энкодеров сильно отличаются. RAV1E и SVT на этом железе кодировали заметно дольше: порядка 39–53 минут, и при этом итоговые файлы были не лучше, чем у libaom в быстрой конфигурации. То есть на практике libaom-AVIF дал лучший результат на таком железе.
Вывод простой: WebP остаётся хорошим вариантом, если важна совместимость и быстрое декодирование. JPEG-XL в этих экспериментах уступал по одной из метрик. При выборе формата в ориентируйтесь не только на цифры сжатия, но и на то, есть ли надёжные реализации энкодеров/декодеров для вашей инфраструктуры.
*Принадлежит компании Meta, которая запрещена в России как экстремистская.
© 2025 ООО «МТ ФИНАНС»
Комментарии (111)
Anfisapi
18.10.2025 13:06статья прикольная, но где-то потерялись моменты, где сжимать точно не нужно и до каких размеров
aprezi
18.10.2025 13:06тема png не раскрыта
GCU
18.10.2025 13:06PNG без потерь, под капотом фильтрация для предсказания по трём соседним пикселям + DEFLATE
Технически лучше чем GIF и BMP, на сегодняшний день сожран WebP как и большинство других растровых форматов.
orekh
18.10.2025 13:06PNG не сожран, как никак единственный стандартный формат без потерь качества сейчас.
На одном крупном сайте, где художники продают картиночки, без объявления нововведений сделали пережатие в WebP. Большинство, котрое просто скроллит картинки, конечно не заметило. Однако среди тех, кто продаёт и покупает, начались брожения - художники стали картинки прятать от сжатия сайта в аттачментах, кто-то из богатых клиентов громко объявил об уходе и стал переманивать на другую платформу.
Сайт немного повозился с WebP, сделал ему lossless-сжатие, но, боже, кому нужно скачанный WebP коллекционировать? Чтобы он открывался в браузере вместо просмотрщика картинок (который его не видит вообще), да ещё и гадать - lossless он или тебя развели с lossy.
Так что от WebP там отказались.GCU
18.10.2025 13:06Технически WebP сложнее в реализации, но степень сжатия без потерь там обычно выше чем у PNG. В большинстве случаев на сайте можно обойтись только WebP, полностью заменив JPG/PNG/GIF.
ganzmavag
18.10.2025 13:06Но там же совсем крохи разницы будут, если сжатие без потерь там и там. А плюсы в чем?
MountainGoat
18.10.2025 13:06Да, без потерь он всего на 30% меньше, чем PNG. Можно не заморачиваться.
Maccimo
18.10.2025 13:06всего на 30% меньше, чем PNG.
По ссылке написано 23%, а не 30% и это ссылка на другую статью. В этой второй статье некоторые примеры странные. Например, какие-то графики с полупрозрачностью, где она ни к селу ни к городу.
Глава «Disadvantages of PNG» по вашей ссылке выглядит довольно натянуто.
Dimmirslr
18.10.2025 13:06Проблема WebP не в алгоритме, а в его социальном статусе - он до сих пор воспринимается как формат для веба, а не как формат для хранения. И пока его не начнут нативно поддерживать все операционные системы и графические редакторы на уровне PNG, он так и останется нишевым решением для оптимизации сайтов
Wolframium13
18.10.2025 13:06Его ещё не все сайты поддерживают (нельзя отправить в сообщении, загрузить в галерею и т.п.)
muxa_ru
18.10.2025 13:06На одном крупном сайте, где художники продают картиночки, без объявления нововведений сделали пережатие в WebP.
Поделитесь, пожалуйста, ссылочкой.
Мне для коллекции.
orekh
18.10.2025 13:06patreon.com это (но думаю, что вы искали что-то другое)
muxa_ru
18.10.2025 13:06Я собираю примеры.
https://www.reddit.com/r/patreon/comments/1iythio/patreon_started_brutally_compressing_my_images/ - оно?
Есть где-нибудь описания событий?
orekh
18.10.2025 13:06Да, оно. Началось 27.02.2025, закончилось примерно 06.04.2025. Между этими датами происходили какие-то шатания: то там ломали поддержку заголовка accept без webp, то запихивали webp в файлы с расширением .png, то возвращали png ненадолго. Хронологию событий вряд-ли кто вёл, но можно найти посты на патреоне за то время, где в каментах люди сообщают о проблеме, и увидеть как за тот период художники стали пользоваться аттачментами. Я так вообще из дискорд-сообществ это наблюдал.
MountainGoat
18.10.2025 13:06Может и правильно, но если у вас в 2025 подсмотрщик картинок не открывает WebP - его надо поменять.
moscowman
18.10.2025 13:06Я как-то решил ради интереса пережать 1 минуту скачанного 4К видео фильма (6 разных фильмов было) в
H264 -preset VerySlow
H265 -preset placebo
AV1 -strict experimental
с помощью ffmpeg на процессоре.И знаете что, умолчу про время кодирования AV1, но качество круче всех оказалось у H264.
Далее, что для меня удивительно, почти всегда, по размеру выигрывал H265.
Да, размер H264 оказался примерно на треть больше, но я свой архив фильмов оставил в нём.muxa_ru
18.10.2025 13:06как оценивали качество?
moscowman
18.10.2025 13:06С помощью того-же ffmpeg один и тот-же кадр сохранял в PNG.
На телевизоре разница конечно-же не заметна, но вот на мониторе при переключении слоёв в редакторе изображений, вообще без проблем. Качество H265/AV1 вообще никакое.
Но готов сделать сноску, для перекодирования записи монитора, если это текст, AV1 для меня топ.
Loco2k
18.10.2025 13:06Начиная с h264 у кодеков есть оптимизации под текст. Там туча опций.
У вас скорее всего роль играли дефолтные настройки ффмпег
moscowman
18.10.2025 13:06Блин, дайте пожалуйста ваши правильные команды для того, чтобы качество видео H265/AV1 сравнилось с H264.
Для сравнения, базовая команда для H264 была такой:ffmpeg.exe -i "видео.фильм" -c:a copy -c:s copy -map 0:0 -map 0:1 -vcodec libx264 -preset VerySlow
Меня все уверяют, что новые кодеки лучше, но не могут привести доказательства.Loco2k
18.10.2025 13:06Они не лучше, у них меньше битрейт. Psnr метрики смотрите, а не глазами. И вообще зачем вам кодеки?
Старый контент транскодировать только портить. Для нового используйте самый передовой кодек, если нет вопроса совместимости
ZirakZigil
18.10.2025 13:06Psnr метрики смотрите, а не глазами
Вот так точно делать не надо при сравнениях со старыми кодеками. они активнее жрут детали и очень легко могут дать psnr выше чем у нового. Я в своё время немного игрался со сжатием, так для определённых семплов (типа старых фильмов) я на своём недожипеге легко получал "лучшее" качество чем h265 вообще без каких-либо оптимизаций под тест.
А так да, максимально качественный исходник жмётся максимально новым кодеком, жизнь становится проще.
Loco2k
18.10.2025 13:06psnr на низком битрейте не будет показателен. надо брать несжатый исходник и делать битрейт побольше (ну не 1мбит)
ZirakZigil
18.10.2025 13:06Конкретно там был крёстный отец, пожатый h265 из исходников до 9500 мбит/с с прицелом на максимальное сохранение деталей. Против него был мой недожипег, не помню с каким, но, очевидно, сравнительно огромным битрейтом и, очевидно же, сильно худшим качеством. Мой недожипег выигрывал. Оно и понятно, он всё зерно замылил, вот, вроде, шума и немного, и метрика "хорошая".
Loco2k
18.10.2025 13:06так если битрейт выше, то и качество выше. я вот сейчас наделал вариантов из студийного мастера с помощью хендбрейк. вопервых там не выдерживается битрейт, но примерно совпадает. по метрикам разница между кодеками становится сильно заметна только на низких битрейтах (ну контент такой видимо). psnr даёт хороший результат при битрейте от 8М на 264, ниже всё плохо. и глазами и метрикой. хотя psnr убогая метрика.
вообще все эти изыскания в кодеках удел Нетфликс, Ютуба и спутниковых b2c операторов (там еще интереснее). цифровой релиз фильма это отдельная история и обьем файла там не так важен (блюрей большой)Maccimo
18.10.2025 13:06и спутниковых b2c операторов (там еще интереснее).
Разве там есть пространство для манёвра?
Принимающая железяка ведь должна уметь это декодировать.
andreymal
18.10.2025 13:06Вы ж даже битрейт не указали, фиг знает что там у ffmpeg по умолчанию прописано
Сравнивать надо хотя бы или с одинаковым средним битрейтом (тогда предполагается, что новые кодеки будут качественнее), или с одинаковым качеством (тогда предполагается, что новые кодеки дадут меньший средний битрейт)
Ну и в любом случае повторное сжатие уже сжатого контента неизбежно приведёт к дальнейшему ухудшению качества независимо от кодека, для сравнения кодеков нужно брать изначально несжатый исходник
moscowman
18.10.2025 13:06Я указал хоть что-то, хотя бы пресеты, у H264/H265 они отвечают за максимальное качество. Я указал, что перекодировал 4K фильм.
У меня вышло что H264 с максимальным качеством явно лучше H265.
Вы же опять о сферическом коне в вакууме из, не побоюсь этого слова, МУСОРНЫХ статей, которые хвалят новый формат, но не приводят ни команды ни свой опыт.
Поделитесь, что вы перекодировали для сравнения и Вашу команду для H265. Я перепроверю у себя и если Вы правы, то на словах от меня БЧС Вам непременно будет.andreymal
18.10.2025 13:06Пресеты отвечают за скорость кодирования, один и тот же пресет даст абсолютно разные качества на разных битрейтах
Наличие 4К никак не отменяет того факта, что этот ваш фильм почти гарантированно является сильно сжатым (никто ж вам не даст настоящий исходник)
moscowman
18.10.2025 13:06Вообще-то почти на 100% гарантировано, что Вы нигде не получите не сжатый исходник.
Я взял для перекодирования максимально качественную картинку, более 4К мне негде смотреть.
Поэтому опять вижу словеса в небеса и не более.
Давайте перекодируем какой-нибудь Ваш самый нулёвый исходник, но не мультик. И сравним. Я буду только рад, если удастся сэкономить место на диске, без потери качества в сравнении с H264.andreymal
18.10.2025 13:06В ветке ниже вы принципиально отказались формулировать какие-либо объективные и конкретные критерии сравнения кодеков, ограничившись абстрактными и субъективными «многовато» и «(не) вижу», так что я не вижу смысла что-либо делать, пока вы сами не прекратите свои словеса в небеса
dgenisley
18.10.2025 13:06H264 оказался примерно на треть больше
нечестно получается. итоговый файл по весу должен совпадать.
AV1 -strict experimental
это не пресет
Как уже писали, если видео изначально сжато, то могут начать происходить всякие странности.
Кстати, я сам затестил только что кодеки (но на мелких отрывках, input: дрон летает над пляжем, 4к, х264 100М битрейт). Одинаковый итоговый вес, настройки кодировщика эквивалентны. Сжатие до 10М битрейта, чтобы было наглядно.
х264 ожидаемо убил картинку напрочь. А вот х265 и ав1 почти не отличались. Вот это меня удивило. Хотя... наверное, от типа контента зависит.
moscowman
18.10.2025 13:06Что значит нечестно?
У Вас в приоритете битрейт, у меня в приоритете качество.
Размер на треть больше при качестве гораздо лучшем у H264 меня устраивает.
Вы же гонитесь за размером файлика.andreymal
18.10.2025 13:06у меня в приоритете качество
Тогда почему вы вообще что-то куда-то кодируете?
Просто ничего не делайте — и качество останется максимально возможным
moscowman
18.10.2025 13:0680 гигов видео для любимого фильма многовато, с учётом того, что такой не один, пытался оптимизировать коллекцию.
Разницу в кадре "оригинала" 4K и H264 надо выискивать на мониторе, а вот H265, как оказалось, выискивать не надо, всё видно очень хорошо. Хотя поток на кодирование обоим кодекам отдавался идентичный.
На примере JPG картинок, качество 80% от исходника меня устраивает, разницу я должен искать, а вот 50% я вижу моментально, если переключать слои. Опять же, если не брать пограничные случаи типа текста, где всё гораздо жёстче и там наверняка будет PNG.andreymal
18.10.2025 13:0680 гигов видео для любимого фильма многовато
Значит вы согласны на ухудшение качества ради уменьшения размера (то есть битрейта).
Какова длительность этого любимого фильма и сколько конкретно для вас не «многовато»?
moscowman
18.10.2025 13:06Все мои посты говорят о том, что я согласен на то, когда не вижу разницы между исходником и целью.
Разницу в H265 я вижу отчётливо и не напрягаясь при покадровом изучении, H264 - не вижу.
andreymal
18.10.2025 13:06я согласен на то, когда не вижу разницы между исходником и целью
Значит вы согласны в качестве такой цели взять исходник и потратить 80 гигов на свой любимый фильм.
Пока вы продолжаете предъявлять требования, которые противоречат друг другу — никакого конструктива у нас не получится
muxa_ru
18.10.2025 13:06Просто ничего не делайте — и качество останется максимально возможным
Это очень правильное замечание, потому что не существует абстрактного УЛУЧШЕНИЯ. Есть ИЗМЕНЕНИЕ которое должно изменить один параметр, попутно изменив другие. И запланированное нам изменение будет УЛУЧШЕНИЕМ, а незапланированное - УХУДШЕНИЕМ,
ZirakZigil
18.10.2025 13:06Ну так поизучайте опции кодека, запустите его так чтобы он знал, что ему можно ради качества выплюнуть "на треть больший по объёму файл", потом сравнивайте.
А то получается, что Петя копает в полтора раза быстрее Васи, но Пете вы позволяете копать час, а Васе два, а потом заявляете, что Вася больше Пети копает.
muxa_ru
18.10.2025 13:06То есть, не по количеству изменившихся пикселей, а органолнептически?
moscowman
18.10.2025 13:06Берётся скриншот оригинала и скриншоты всех вариантов перекодирования. Всё в PNG.
Далее на нулевом слое редактора изображений оригинал, а затем получившиеся варианты. Ну и перещёлкиваем их.
Квадратики видны без лупы. Никого из милиции даже возбуждать с этим девайсом не пришлось. Разница видна почти моментально.
Опять-же уточню, я не кодировал мультик Остров сокровищ, я специально выбирал художественные сцены с мелкими деталями. Старался, чтобы в кадре были волосы.Loco2k
18.10.2025 13:06во-первых берите не скриншот, а I-frame (AVidemux в помощь)
во-вторых в профессиональной среде не используют ффмпег для кодирования :)andreymal
18.10.2025 13:06А какой смысл брать I-фреймы, если зритель в основном видит P/B-фреймы, которых большинство?
Loco2k
18.10.2025 13:06чтобы нивелировать влияние плеера\декодера
ZirakZigil
18.10.2025 13:06Оно вряд ли различимо на глаз. Энкодер и так делает проход декодером, и адаптирует результат как раз чтобы не получалось, что после декода что-то неожиданное было.
Loco2k
18.10.2025 13:06я больше про то, чтобы у него был один и тот же кадр. и специфику плеера не надо исключать (улучшалки всякие как вариант). на счёт софта конкретно не скажу. а вот телевизоры и stb что только не делают по-умолчанию
andreymal
18.10.2025 13:06Кадр можно выдрать с помощью того же ffmpeg (правда, у меня цвета немного гуляют почему-то, но оценить общее качество по шкале шакалов это не помешает)
Loco2k
18.10.2025 13:06мои комменты выше это предположения на счёт косяков в методике тестирования через png скрины. psnr выше 38 почти не шакалит. но вообще транскодирование для уменьшения места на диске это глупость (если не из непожатого исходника), стоимость хранения падает со временем
moscowman
18.10.2025 13:06Я нигде не утверждал что я профессионал.
Я везде просил профессионалов помочь мне со строкой для перекодирования.
Я, как любитель, тупо взял 2 пресета заточенные на максимальное качество и увидел, что H265 это не то, что я хотел получить. Мыло мне не надо.
А все профессионалы так и молчат. Хотя я им предложил сделать тест на их исходном видео с их командами, чтобы доказать обратное. Но это очень секретное знание, которое судя по ответам недоступно даже профессионалам.
Поэтому остаюсь на H264.andreymal
18.10.2025 13:06Я везде просил профессионалов помочь мне со строкой для перекодирования.
И когда вас попросили озвучить конкретные требования, которым эта строка для перекодирования должна соответствовать, вы их озвучивать отказались. Неудивительно, что все мало-мальски компетентные профессионалы решили вас проигнорировать
moscowman
18.10.2025 13:06Такое ощущуение, что Вы отвечаете на что-то своё, не читая мои буквы.
Конкретные требования были озвучены неоднократно, избавиться от квадратиков по сравнению с пресетами максимального качества у 264/265.
У 264 с максимальным пресетом, "квадратиков" нет, у 265 есть, но объём меньше примерно на треть.
Задача такая, при сравнимом качестве 264/265 получить меньший размер на выходе. Но качество на первом месте, только потом битрейт и прочее.
Ещё раз другими словами, мы не должны терять в качестве видимом на глаз и в тоже время на только на втором месте стремимся сэкономить на объёме файла.andreymal
18.10.2025 13:06избавиться от квадратиков
качество на первом месте
Вам на всё это уже был дан ответ: просто ничего не делайте — и у вас останется исходник в максимально возможном качестве
меньший размер на выходе
Насколько меньший? Если 80 гигов сожмётся в 79.999 гигов — это устраивающий вас результат? Если нет, то почему?
moscowman
18.10.2025 13:06Блин, я не думал что на Хабре есть тролли. Теперь знаю, что есть.
С троллями не общаюсь. Удачи.
Maccimo
18.10.2025 13:06Не вижу троллинга со стороны вашего оппонента. А вот вы старательно изображаете разговор глухого с немым.
Loco2k
18.10.2025 13:06Так если не используют ффмпег, какую команду вы хотите?
MSU VQMT Free вам в помощь, и вот эта статья elecard.com/ru/page/article_interpretation_of_metrics
DenisDangerous
18.10.2025 13:06265 куда качественнее, хз как у вас так получилось. видео с экшн камеры в 1440р@60 вывожу. Для 264 нужно не менее 100мбит чтобы не было ощутимых артефактов, а для 265 достаточно 20. С фильмами попроще в целом потому что там ДД куда ниже, нет ярких насыщенных цветов и жмутся они эффективнее из-за этого
daggert
18.10.2025 13:06Странное у вас сжатие. Я занимаюсь видеонаблюдением и разница 265/264 это ну 20% от силы, при сравнимом качестве изображения
AlexSpirit
18.10.2025 13:06Это потому что обычно H.264 на камерах идёт с профилем high, а H.265 с main, а то и base. Но на коробке с камерой гордое H.265 есть и обязательно крупными буквами.
gorod0k
18.10.2025 13:06Сильно зависит от самого видео и так же сильно от настроек сжатия под конкретное видео. Единичный случай ни о чем вообще не говорит
Dimmirslr
18.10.2025 13:06Все правильно сделали. Для домашнего архива, где место не так критично как качество, сохранение в максимально близком к оригиналу виде (или с минимальным пережатием проверенным кодеком) самая здравая стратегия. Пережимать уже сжатое все равно что делать ксерокопию с ксерокопии, лучше не станет
Loco2k
18.10.2025 13:06Использование видеокодека для фото в мобильных устройствах решает вопрос энергопотребления, и упрощает аппаратную реализацию кодера.
qiper
18.10.2025 13:06Ответ прост: если бы мы хранили изображения в их исходном виде, даже одна фотография занимала бы сотни мегабайт. Интернет времён 90-х просто не справился бы с таким объёмом данных.
Неправда, тем более про 90-е
xpadd93
18.10.2025 13:06Странно никто не использует формат https://ru.wikipedia.org/wiki/JPEG_2000
15432
18.10.2025 13:06Не прижился, ещё на лекциях @3Dvideo нам рассказывал, что формат более приятен человеческому глазу, ибо вместо пиксельных артефактов у него происходит плавное размытие. Вейвлетное кодирование, однако
Melirius
18.10.2025 13:06Думали, что приятен, оказалось, что не особо: рингинг делает изображение напоминающим страшный сон или галлюцинацию.
3Dvideo
18.10.2025 13:06Слишком мало преимущество в сжатии при заметном увеличение сложности (тогда это было важно) и не самой высокой гибкости
vanxant
18.10.2025 13:06вейвлеты далеко не панацея. Наверное встречались с форматами wmv (windows media video) и wma (аудио)? Так вот, был ещё wmp для изображений. На моднейших вейвлетах, как и остальные два. Только он оказался заметно хуже jpeg-а при том же размере файла или заметно (процентов на 30) больше при одинаковом качестве.
xpadd93
18.10.2025 13:06Аналогично аудиоформат "wav", "amr" размер меньше.
13 лет назад, была популярный видеоформат "flv" - кодекс Sorenson Spark.
Alexey_U
18.10.2025 13:06А файлы стали меньше...
Меня пробило на персональные видеорегистраторы. Для велосипеда и для ношения. Да ещё с художественным видео, чтобы потом, сидя зимой, можно было погружаться в лето, в поездку на велосипеде. И столкнулся с таким, который использует не просто h.264, а ещё и пишет с VBR. Что это даёт? 5 минут могут занимать не 700 мегабайт, а бывает что и 40, и даже меньше. Конкретно у этого видеорегистратора есть минус - слишком низкая частота видеопотока. Вместо листвы зелёная масса, номера читаются только вблизи.
Да, h.265 даёт маленький объем видео, а также нередко потерю деталей. Как-то писал про то, что перекодировать большое видео не смог, снятая на видео белка просто исчезает при попытке уменьшить объем видео до приемлемого размера.
Думаю что давно пора создать ещё один формат, в котором в одном видео чередовались бы кодеки, частота видеопотока, звука, постоянный или переменный битрейт. Также есть проблемы с перекодированием видео, снятого при плохой освещённости. И вот такая сборная солянка помогла бы делать видео с приемлемым качеством и, возможно, с минимальным объёмом для сюжетов в видео.
Daddy_Cool
18.10.2025 13:06Это ж надо вначале понять, что важно на видео, а что нет. Сегодня в парке фоткал белку, так там другие люди были рядом, вот их можно было бы и убрать.
Alexey_U
18.10.2025 13:06Вы это серьёзно? Необходимо получить видео, максимально приближённое к исходному. А не отредактированное с убиранием или добавлением чего-то. Кодирование, а не редактирование.
А вот видео с бегущей белкой кодируется так, как будто это движение чего-то вообще не имеет никакого значения, и безжалостно удаляется.
muxa_ru
18.10.2025 13:06А не отредактированное с убиранием или добавлением чего-то. Кодирование, а не редактирование.
Полагаю, скоро это всё будет упаковано в одни функционал и кнопку "улучшить качество", а разработчики сервиса/софта просто не поймут о чём Вы говорите.
Daddy_Cool
18.10.2025 13:06"Думаю что давно пора создать ещё один формат, в котором в одном видео чередовались бы кодеки, частота видеопотока, звука"
ОК, возьмём звук. Пусть у нас... Видео где барабанщик играет на сцене, у него развешаны тарелки, они дают множество высоких частот.
Если ваша задача продемонстрировать качество тарелок - нужно будет сохранить частоты, а самого драммера можно будет и размыть. А если вам пофиг, что там звучит - а барабанщик ваш друг/ребенок на которого хочется посмотреть, то надо сохранять качество видео. А если вам интересна игра света от софита, то вообще фокус будет на чем-то еще.
Кодирование с потерями оно такое - теряется то, что неважно, а что неважно? Вопрос к человеку.Alexey_U
18.10.2025 13:06Думаю что если грамотно создать контейнер (формат видео с кучей различных кодеков), то нормальная программа сама сможет разобраться, где нужно писать 96 кГц при 24 битах, а где и поменьше битрейт пойдёт. Не везде же тарелочки с флейтами звучат, и нет необходимости отдавать огромный объем под звук. Думаю что и с видео разберётся. И не будет из темноты выходить призрак без ног, с каждым шагом отращивая их. В конце концов даже если была бы возможность делать это вручную, уже было бы неплохо.
Gutt
18.10.2025 13:06Думаю что давно пора создать ещё один формат, в котором в одном видео чередовались бы кодеки, частота видеопотока, звука, постоянный или переменный битрейт.
Называется Matroska (MKV). Правда, не уверен, что такого Франкенштейна хоть какой-то плеер сможет проиграть, слишком пограничный случай. А вообще современные кодеки с переменным битрейтом должны подстраиваться под изменения сцены.
Alexey_U
18.10.2025 13:06MKV проиграть в смартфоне могут, во всяком случае VLC ни с какими вариантами не вешался, в компьютере тоже, но это не кодек, это контейнер. И речь идёт о том, чтобы в одном видеофайле были разные кодеки.
Теоретически h.265 и av1 должны быть отличными. Они как бы то, что надо, но не совсем что надо. Сцены разные бывают. И для сохранения некоторых сцен перекодированный из h.264 в h.265 видеофайл получался больше исходного размера. Речь же идёт о сжатии, а не об увеличении объёма файла. Возможно именно эти сцены для видео лучше оставить без сжатия, в том же h.264, но при обычном кодировании конечный файл здоровенный получается, а основное тело видео прекрасно сжимается этим h.265 с меньшим битрейтом. Вот о чём речь. То есть хотелось бы что-то вроде h.265 -h.264 (оригинал) - h.265. Уже по- разному пробовал. Либо теряются детали, либо смысл в перекодировании теряется. Не хотелось бы всё на дисках огромной ёмкости хранить. Будь то HDD или оптические. Смысл в том, чтобы уйти от объёма, сохранив качество.
За объем у нас отвечает битрейт, за качество он же, но если для уменьшения объёма битрейт нужно уменьшать, для сохранения второго нужно увеличивать. Сейчас же всё видео пишется одним кодеком либо с одним битрейтом, либо с переменным. Остальные варианты, как показала практика, чаще всего не варианты. Итог - валяются 40 гигабайт видео всего лишь из-за одной короткой сцены. Без перекодирования мегабайт 20. То есть из-за такой маленькой сцены конечный объем раз в ...дцать больше, чем может быть. В других случаях смирился с потерями, не художественное видео. Но и там, конечно, не хотелось бы терять детали.
Loco2k
18.10.2025 13:06Потребительские форматы h26* и пр. не созданы для транскодирования. Берите топовый регистратор с хорошим кодером. Либо у вас должен быть большой запас по битрейту, скажем 30Мбит транскодите в 10.
Alexey_U
18.10.2025 13:06Камера до 60 Мбит. Я не помню с каким разрешением снимал. Проблема в деталях, из-за которых из-за монокодека и монобитрейта конечный размер файла большой.
Вот я и мечтаю, что у кого-нибудь мысль в голову придёт разработать контейнер (если точнее - кто-то прочитает что пишу и создаст это), в котором будут и несколько кодеков, и несколько битрейтов. А где-то просто чтобы был кусок оригинала.
Для тёмных сцен нужен большой битрейт, для светлых меньше. И переменным битрейтом это не решается. И даже фильтры не везде приемлемы. Есть ситуации, когда нужно создать видео с парой кусочков по 9 ГБ, и между ними обзор, где 40 мегабайт будет выше крыши. А вот из-за кодека и битрейта этих 9-гигабайтных кусков видео может увеличиться ещё гигабайт на 60 для сохранения качества. Вот и получаются обычные текстовые обзоры со вставками в окошках проигрывателей, либо ссылок на облако, откуда можно скачать эти куски видео.
orekh
18.10.2025 13:06Переменный битрейт именно это и решает. Можно сделать видео, где одна минута будет ужата в хлам, а другая будет неотличима от оригинала. Только обычно все хотят достигнуть в среднем по видео одинакового качества, если нужна эффективность качества на бит. Или постоянного битрейта, если есть ограничения на скорость записи или передачи видео. Потому есть только настройки качества в среднем и верхней или нижней границы битрейта. Ведь угадать когда тебе будет нужен высокий битрейт - это надо экстрасенсом быть?
Alexey_U
18.10.2025 13:06Вы примерно представляете, как это работает? Сделаете нижнюю границу низкой, а верхнюю на пару порядков выше, кодек все статические сцены сделает под нижнюю границу, а быстрые раза в 1.5-2 выше сделает битрейт. Вот и всё.
Вы с преобразованием Фурье знакомы? Познакомьтесь, это и есть нужный экстрасенс.
orekh
18.10.2025 13:06примерно представляете, как это работает?
Только примерно. Энкодер приблизительно оценивает сложность статического кадра, или разницу между кадрами, или сложность движения, и сохраняет каждый соответствующий тип кадра с разной точностью.
все статические сцены сделает под нижнюю границу, а быстрые раза в 1.5-2 выше сделает битрейт. Вот и всё.
А вам нужно наоборот? Насколько я понял, вам нужно записать статическое видео темноты около часа где ничего не происходит, а потом мелькнувшую перед камерой белку, так чтобы она не размылась - самое то для VBR. Можно наверное количество ключевых кадров уменьшить.
Loco2k
18.10.2025 13:06Это всё решается в рамках h264. Просто у вас самый примитивный кодер, как на деш телефонах. VBR с прицелом на качество, супер длинный GOP. Двупроходное кодирование с буфером в 5сек для анализа и пр. Есть еще момент что VBR будет ограничен буфером на плеере в итоге. Так что как в любом случае будут ограничения. Попробуйте CBR с максимальным битрейтом и потом подбирайте кодек, если есть задача экономии диска. Но было бы разумней не транскодировать, а вырезать мусор (без транскодирования) после сьемки
Ilya_JOATMON
18.10.2025 13:06Ожидал увидеть в статье описание алгоритмов, которые позволили новым форматам обойти jpeg. Прочитал СЕО воду.
Maccimo
18.10.2025 13:06СЕО воду
Больше похоже на нейро-воду.
Destructive
18.10.2025 13:06Автор даже поленился самостоятельно сжать картинки в JPEG и HEIC для визуального сравнения, вместо этого вставил какую-то шакальную картинку, по которой то и сравнить ничего невозможно.
evalazarev
18.10.2025 13:06А зачем нужно стараться, где-то напрягаться, если есть старая добрая оценка степени сжатия картинок в шакалах?
Destructive
18.10.2025 13:06Если бы он сделал сравнение степеней сжатия картинок в шакалах не только для JPEG, но и для HEIC - это был бы новый уровень!
Maccimo
18.10.2025 13:06редко задумываемся, почему одинаковый кадр может весить в три раза меньше, но выглядеть так же.
В качестве примера этому можно взять заглавное изображение с котэ.
Это PNG на 115 Кб. Если натравить на него OptiPNG с ключом-o7, то размер снизится до 79 Кб, а если сохранить изображение как 80% раствор JPG, то и вовсе до 42 Кб.если бы мы хранили изображения в их исходном виде, даже одна фотография занимала бы сотни мегабайт.
Возьмём кадр в разрешении 8K (7680x4320), сделаем каждый пиксель 24-битным, никакого сжатия. И даже в этом случае у нас получится 768043203 = 99 532 800, т.е. 95 мегабайтов. А тогда подобных гигантских разрешений и в помине не было.
Память стоила дорого
Какая память? Дисковая, оперативная?
В эпоху dial-up-модемов это было как-то так: вы видели, что фото точно загрузится, и могли подождать, пока прогрузится лицо собеседника из ICQ.
Ы?
Не было в аське никаких лиц в диалапную эпоху. Не генерируйте текст про то, о чём не имеете ни малейшего представления.Instagram* и другие мессенджеры
Так это мессенджер? )
Соглашусь с другими ораторами, прочтя заголовок ожидал техническую статью, а получил мусор.
Dimmirslr
18.10.2025 13:06За кадром остался главный инженерный компромисс: битрейт против циклов CPU. AV1 сжимает отлично, но попробуйте закодировать им что-нибудь на слабом железе "на лету" и вся экономия выйдет боком через раскаленный процессор и севшую батарейку. Магии не бывает, есть только физика и математика
erazor
18.10.2025 13:06Домашнюю видеобиблиотеку всю переконвертировал в h.264/aac, как самый поддерживаемый формат для видео - проигрывается и на десктопных и на мобильных клиентах и в браузерах.
С другими вариантами не получалось "универсального" решения...
Gutt
18.10.2025 13:06Ага, пока не попытаешься импортировать во встроенную галерею изображений и видео на iOS. И тут оказывается, что MKV с h.264 оно не кушает, ему Quicktime или MP4 как контейнер подавай.
erazor
18.10.2025 13:06Именно так, именно в mp4. Поэтому все скачанные mkv перегоняю в mp4-контейнер через ffmpeg. А для пятиканального звука AC1 есть несвободная реализация энкодера AAC.
В итоге проигрывается везде, где я смог протестить
REPISOT
18.10.2025 13:06JPEG, HEIC и AV1 давно стали частью нашей повседневности
HEIC - это прерогатива айфонщиков, у меня ни одной картинки HEIC не хранится. А когда присылают, еще не сразу поймешь, что это, ищешь конвертер, чтобы посмотреть...
AV1 - первый раз слышу.
Alexey_U
18.10.2025 13:06AV1 уже давно есть. Только у меня ни один конвертер/кодер не сделал ни одного файла в таком формате, постоянно ошибка. Только просмотреть могу. С heic на самсунге никогда с просмотром проблем не испытывал, равно как и на iPhone 7 с heif и hdr10+.
REPISOT
18.10.2025 13:06уже давно есть
Я и не говорю, что их еще не изобрели. Я говорю, что фраза
давно стали частью нашей повседневности
сильно преувеличена. Опять-таки, "давно есть" не равно "стали частью повседневности", потому что какова доля видео в таком формате? Я вот до сих пор не встречал.
проблем не испытывал, равно как и на iPhone 7
С чего бы там взяться проблемам, если это "их" формат? Проблемы у всех остальных, кому айфонщики фото скидывают, потому что нативной поддержки в ОС на ПК их нет. Сколько там айфонщиков по данным мвидиа? 25%? Вот для них - да - стали частью повседневности.
Alexey_U
18.10.2025 13:06Вы невнимательны. Вот почему. Потому что на самсунге с heic нет проблем, а это не его формат, а на айфоне с heif и hdr10+, и это не его формат.
MountainGoat
18.10.2025 13:06AV1 - первый раз слышу.
Youtube уже 2 года как перешёл по умолчанию для видео 1080 и меньше.
DarkWorker
18.10.2025 13:06Так примеры с JXL под 85 и 90 не рациональны, он и на 70% качества покажет идеальный результат в сравнении с конкурентами и весить будет меньше.
vanxant
18.10.2025 13:06В статье толком не раскрыт формат webp от гугла. Это, можно сказать, JPEG 2.0 каким он должен был быть. Тут вам и блоки 4х4 и 16х16, и альфа-канал, и нормальный алгоритм сжатия без потерь... Правда, прибитый гвоздями YUV 4:2:0
Kollubov
18.10.2025 13:06Пара замечаний. Во-первых, по заголовку - "почему файлы стали меньше". Не замечаю такого явления. Наоборот - когда-то нормально заходила авишка на 700 мегов полуторачасового фильма. Потом меньше 1,4 гигабайта на полный метр качать стало западло. Затем 2,1 гигабайта на полтора часа стало хорошим тоном. Сейчас полтора гига на 40-минутный эпизод сериала считаю в принципе приемлемым качеством, но не идеалом такового. Я понимаю, что разрешения увеличиваются, HD, то-се. Но "файлы стали меньше" - это не тру заголовок.
С изображениями то же самое. Когда-то в веб-мастеринге было железное правило - вся страница HTML должна весить не больше 100 килобайт, чтобы не задерживать пользователей. Сегодня бонтон другой - чтобы одна фотка на странице весила не больше 200-250 килобайт, дабы не задерживать пользователей.
Так что файлы-то становятся больше - другое дело, что если бы форматы не оптимизировали, они становились бы еще больше.
sse
18.10.2025 13:06К сожалению, на многих ширпотребных одноплатниках поддерживается аппаратно исключительно h.264, попытки h.265 превращают видео в слайдшоу, про av1 и говорить нечего, ситуация еще хуже. Так что конкретно там прогресс не то чтобы высок. Если у кого-то есть более позитивный отзыв, пишите, было бы интересно узнать про конкретную программно-аппаратную конфигурацию у вас
muxa_ru
У вас при подготовке текста куда-то пропал блок с минусами и последствиями процесса "шла битва за каждый байт и приходилось придумывать всё новые и новые форматы"