Hacker News Digest

Для сжатия фотографий с потерями в вебе AVIF почти всегда даёт файлы меньше, чем JPEG XL: при настройках усилия по умолчанию лучший результат JPEG XL обычно на 15–25% больше, а при максимальных настройках разрыв сокращается до 6–20%. Бывают исключения, где JPEG XL близок к AVIF или даже обгоняет его, поэтому для конкретного изображения стоит пробовать оба формата. Для скриншотов и иллюстраций AVIF заметно лучше: эквивалентный JPEG XL больше на 30–90% при обычных настройках и на 20–70% при максимальных. Для изображений с прозрачностью AVIF тоже выигрывает: версия libjxl больше на 31–44% и 61–70% соответственно, а jixel всегда кодирует прозрачность без потерь, из-за чего файлы в 2–3 раза крупнее, чем у AVIF.

Выбор кодера JPEG XL сильно влияет на результат: новый jixel обычно даёт меньшие файлы, чем libjxl, кроме изображений с детальной прозрачностью. AVIF в целом быстрее кодируется и требует меньше памяти с учётом размера файла, а декодируется в 2–3 раза быстрее JPEG XL при среднем качестве, хотя на очень высоких качествах разрыв сокращается. Повышенные настройки усилия оправданы для AVIF и jixel, но не для libjxl: они намного медленнее, расходуют больше памяти и почти не улучшают результат, иногда даже увеличивая файл. Режим 4:2:0 у AVIF не стоит делать значением по умолчанию — он редко уменьшает размер и затрудняет достижение высокого качества, хотя быстрее кодируется и декодируется; лучше использовать 4:4:4. Настройки качества работают надёжно у всех кодеров.

Анимированный AVIF по сути представляет собой переупаковку видео AV1 — MP4 можно преобразовать в AVIF и обратно без потерь, поэтому он так хорошо работает с движением. Однако в Chrome и Safari он воспроизводится плохо, хотя в Firefox всё в порядке: это чисто проблема реализации. При этом анимированный AVIF поддерживает прозрачность, чего нет у видео AV1.

Обсуждение дополняет статью практическими данными о качестве энкодеров, проблемами рендеринга в браузерах и специфическими сценариями использования (анимации, HDR, архивация), при этом подтверждая преимущество AVIF в размере файлов для веба.

• Спор: Пользователь @PaulHoule заметил потерю деталей в бликах на фото F1 в AVIF, однако @jaffathecake пояснил, что это было вызвано некорректной работой WASM-рендерера в браузере без поддержки JPEG XL, а не самим форматом.

• Спор: По мнению @linolevan, текущие энкодеры JPEG XL недостаточно оптимизированы: использование более качественного энкодера позволило ему уменьшить размер lossless-скриншота на 39% и иллюстрации на 30% по сравнению с результатами в статье.

• Совет: Для достижения максимального сжатия AVIF с сохранением прозрачности PNG @Metricon рекомендует использовать ffmpeg с параметрами: libaom-av1, crf 25, cpu-used 3 и специфическими настройками sharpness и chroma-deltaq.

• AVIF считается более подходящим форматом для замены GIF и создания анимаций с прозрачностью, так как он фактически является переупакованным видео AV1, оптимизированным под движение.

• JPEG XL обладает уникальным преимуществом в виде возможности эффективного транскодинга существующих JPEG-файлов, что делает его ценным для архивации фото.

• Совет: По опыту @yhjc2692, медленная работа libjxl на высоких настройках (efforts >7) связана с итеративной оптимизацией метрики Butteraugli; для ускорения процесса он разработал GPU-порт gjxl (CUDA/Metal).

• AVIF выигрывает на маленьких изображениях, в то время как JPEG XL предпочтительнее для lossless-сжатия, высокобитрейтных изображений и прогрессивного рендеринга.

• Контейнерная архитектура AVIF может упростить будущий переход на новые кодеки (AV2, AV3) без необходимости повторного внедрения формата на сайтах.

I think people are really forgetting that JXL's encoders are bad right now. For instance, in TFA Jake presents- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) — @linolevan

Перевод: Мне кажется, люди забывают, что энкодеры JXL сейчас работают плохо. Например, в статье Джейк приводит скриншот Firefox с lossless JXL размером 66,9 кБ, в то время как с более качественным энкодером его можно сжать до 40,7 кБ (на 39% меньше).

PipePipe — это независимо развивается как форк NewPipe, начатый в начале 2022 года. Проект не синхронизируется с оригиналом: не получает его обновления и не вносит изменения в него, что позволяет быстро исправлять ошибки и часто добавлять новые функции. В отличие от таких форков, как Tubular, PipePipe идёт своим путём, что делает его более гибким и независимым.

Приложение расширяет возможности NewPipe: интегрирует SponsorBlock для пропуска рекламы, восстанавливает дизлайки через ReturnYouTubeDislike, показывает оригинальные нелокализованные названия видео и поддерживает вход в аккаунт для доступа к премиум-контенту. Добавлены danmaku-наложения для live-чатов, поддержка AV1 и VP9 кодеков, режим музыкального плеера с фоновым воспроизведением, продвинутые фильтры поиска и блокировка шортс и платных видео. Управление улучшено жестами свайп-для-перемотки, долгим нажатием для ускорения и таймером сна. Плейлисты можно скачивать целиком, искать и сортировать локально. Доступно в F-Droid и IzzyOnDroid, развитие поддерживается через Ko-Fi и Liberapay. Wiki и благодарности сообществу указаны в репозитории.

Пользователи подтверждают, что PipePipe успешно заменяет NewPipe с поддержкой SponsorBlock, но возникают вопросы по надежности, конфиденциальности и альтернативам на других платформах. PipePipe эффективно решает проблему пропущенных спонсорских блоков, отсутствовавших в NewPipe, и обеспечивает стабильную работу после обновлений YouTube. Разработчик PipePipe активно поддерживает проект, быстро реагируя на изменения YouTube, что делает его надежнее других форков. Спор: Некоторые пользователи отключают SponsorBlock из-за чрезмерного пропускания контента (например, в видео Tony Iommi), считая его раздражающим; другие ценят эту функцию как ключевое преимущество. Спор: Возникает вопрос о конфиденциальности: Return YouTube Dislike в PipePipe отправляет данные о просматриваемых видео третьей стороне без анонимизации, в отличие от SponsorBlock, и опция отключения не работает. Совет: Пользователи рекомендуют Materialious для самостоятельного хостинга — сохраняет историю просмотров и работает на всех устройствах через браузер без установки приложений. Совет: Для iOS предложены альтернативы вроде KiraTuno и Morphe, но они не решают проблему отсутствия полноценного клиента, как PipePipe на Android. Совет: Для Apple TV надежного решения нет: SponsorBlock в контейнере только глушит рекламу, но не пропускает её, снижая удобство. Morphe и ReVanced — популярные альтернативы: Morphe использует yt-dlp, как и PipePipe; ReVanced сохраняет рекомендации и Shorts, что важно для некоторых пользователей. Спор: Некоторые пользователи сталкиваются с блокировкой IP YouTube в PipePipe и NewPipe, возможно, из-за CGNAT, тогда как официальное приложение YouTube работает без проблем с тем же IP. Функция таймера сна для прослушивания перед сном считается ключевым преимуществом PipePipe, отсутствующим в большинстве других клиентов. Совет: Для десктопа пользователи ищут аналоги SponsorBlock в браузерах, но прямых решений, сопоставимых с PipePipe, в обсуждении не представлено. Спор: Есть этическое возражение: один пользователь считает, что использование SponsorBlock — это кража у создателей контента; другие видят в нём инструмент улучшения опыта без прямого ущерба.

JPEG XL — технически впечатляющий кодек, превосходящий JPEG и более универсальный, чем WebP, но его место в браузерах под вопросом. Хотя он был отклонён Chrome в 2023 году, появление Rust-декодера в Firefox и Chrome может сигнализировать о пересмотре позиции, особенно на фоне уязвимости WebP 2023 года. Однако автор, ранее поддерживавший JPEG XL, теперь считает, что его преимущества для веба исчерпаны. По объёму веб-контента подавляющее большинство изображений обслуживается с потерями, а без потерь JPEG XL выигрывает лишь около 11,9% перед WebP — на искусственном наборе данных (157 Мп фото, 10 Мп иллюстраций, 27 Мп книг), неrepresenting типичный веб. Это слишком мало, чтобы оправдать внедрение нового кодекса в браузеры, особенно учитывая, что в lossy-сжатии JPEG XL уступает конкурентам.

Современные энкодеры, включая AV1, достигли лучшего соотношения скорости и качества на бит благодаря perceptual tuning на основе человеческих испытаний. AVIF теперь доминирует во всём диапазоне fidelity, нивелируя единственное реальное преимущество JPEG XL. Автор отмечает, что дискуссия вокруг JPEG XL часто отражает желание большего выбора для разработчиков, а не техническую необходимость, особенно на фоне политики вокруг Google и AV1. Тем не менее, JPEG XL остаётся ценным для профессиональных сценариев вне веба — фотографии, печать, медицинская визуализация — где его возможности могут быть востребованы. В браузерах же его внедрение сейчас не кажется оправданным.

Обсуждение подтверждает сомнения автора в перспективах JPEG XL для веба, добавляя данные о производительности, сложности реализации и ограничениях аппаратного декодирования, а также подчёркивая политические и патентные факторы, влияющие на его принятие, но указывает на потенциальные ниши в профессиональном фото‐ и RAW‐рабочем процессе. libjxl и cjpegli позволяют получать компактные, высококачественные изображения даже для контента с высоким частотным спектром, например комиксов, где другие кодеки требуют компромиссов. WebP‐lossless ограничен 8‐битным RGB, поэтому отдельный формат для истинно lossless‐изображений остаётся необходимым. JXL‐preview в macOS сильно нагружает процессор и память из‐за вычисления «prime», что делает его потенциальным вектором DoS даже для небольших файлов. JXL выигрывает в lossless‐сжатии над WebP и PNG, но в lossy‐режиме часто уступает AVIF и даже обычному JPEG. Аппаратные декодеры AVIF ограничены профилем Main (4:2:0), что делает его менее подходящим для фотосъёмки, где предпочтителен 4:4:4 и 10‐бит. Спор: Некоторые считают, что отсутствие поддержки браузерами препятствует использованию JXL вне веба, в то время как другие указывают, что основные сценарии (например, отправка фото по e‐mail) всё равно требуют транс‐кодирования. Спор: Вопрос открытости: JXL полностью открытый, тогда как AVIF основан на AV1, который хотя и royalty‐free, но имеет патентные споры (Sisvel/Access, Dolby vs Snap), что меняет баланс сравнения. Камеры пока не поддерживают JPEG XL; поддержка ограничивается HEIF, а JPEG остаётся доминирующим форматом из‐за совместимости. Adobe включил JPEG XL в PDF, что может заставить браузеры добавить поддержку формата для корректного отображения PDF‐документов. Совет: Для веб‐публикаций рекомендуется удалять метаданные и транскодировать в уже поддерживаемый формат, поскольку экономия трафика от JXL не компенсирует совместимостиных проблем.

• Леонардо — бывший исследователь видеокодирования, ветеран стандартизации и предприниматель.

• Образование: классическая школа (Лицей Салезиан Вальсаличе), инженер-электронщик (Политех Турина, MSc), межкультурный опыт (Токийский университет, PhD по электрическим коммуникациям).

• Христианско-католическое воспитание сформировало убеждение о миссии, выходящей за личные интересы. В начале карьеры, когда цифровые медиа только зрели, видел свою миссию в разработке интероперабельных технологий цифровых медиа — на благо общества и для использования индустрией.

• Нужна была организация, создающая стандарты цифровых медиа, чтобы потребители могли бесшовно общаться, а индустрия работать на глобальном рынке совместимых продуктов и сервисов. Так в 1987 была задумана, а в 1988 создана группа Moving Picture Experts Group (MPEG).

• Через четыре года MPEG запустила цифровую эру: MPEG‑1 для интерактивных медиа (Video CD), цифрового аудио (MP2) и персональной музыки (MP3). С середины 1990‑х MPEG‑2 стал инфраструктурой для цифрового ТВ по кабелю, спутнику, эфирным сетям и на DVD. MPEG‑4 (первый релиз — 1998) открыл путь интернет‑дистрибуции медиа. Далее последовали семейства стандартов: MPEG‑7, MPEG‑21, MPEG‑A, MPEG‑H, MPEG‑I и др.

• Я председательствовал в группе, добившись более 200 стандартов, роста участия в 20 раз (с 29 экспертов) и расширения тематики от медиа к геномике — «рожденным цифровыми» данным мира.

• 2 июня 2020 я закрыл MPEG и ушел, так как «темные силы» перехватили управление. Ещё до этого у MPEG иссяк импульс — технологически и бизнес‑wise.

• Участники обвиняют MPEG в «патентной мафии»: десятилетиями тормозили отрасль патентами на h.264/265, MP3 и др.
• Основатель MPEG Леонардо Чьярильоне жалуется на «тёмные силы», но критики считают это лицемерием: он сам годами защищал FRAND-роялти.
• Пока MPEG задыхалась в лицензиях, открытые кодеки (AV1, даже несмотря на спорные патенты) и перспективные AI-кодеки (DCVC-RT и др.) начали вытеснять старые стандарты.
• Некоторые считают, что разработка кодеков дорога (сотни инженеров и кластеры CPU), но без патентных оков прогресс мог бы быть быстрее.