The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Выпуск мультимедиа-пакета FFmpeg 6.1"
Отправлено Аноним, 24-Ноя-23 05:16 
> Непонятно, к чему этот ответ и ведь становится всё-таки. Технически мы сделали
> то, что требуется энкодеру. Пустота в младших битах теперь-10-битного-исходника нас не
> волнует, пока не видно бандинга. Энкодер к этой пустоте интереса тоже не испытывает.

Мой пойнт:
1) Исходник от этого лучше не стал и битов в нем столько сколько было, столько есть.
2) Единственный реальный профит с этого маневра - задействуется более точный code path энкодера, где меньше ошибок округления и проч.

> Проблема в том, что первое объясняет, почему повышение разрядности в принципе работает.

Насколько я понял из их объяснений, предсказания становятся более точными. Кодек такого плана грубо говоря пытается максимально предугадать текущий кадр из предыдущих и может быть следующих кадров, а также референсов (сие специфично для AV1/VP9). А ошибка от предсказания кодируется и передается как текущий кадр. И чем там меньше - тем лучше сжатие будет, соответственно.

В этом смысле - у 265 вроде бы нет части продвинутых предикторов как у AV1. Большая часть фич AV1 как раз про улучшения предсказаний, на чем и получается снижение residuals. И чем лучше это сделано тем меньше размер энного кадра. Если хорошо угадалось, размер энного кадра может быть издевательский.

> А вывод про AV1 сделан уже тобой самостоятельно и, например, не объясняет,
> почему от повышения разрядности в H.265 пользы меньше, чем в H.264,
> несмотря на более продвинутое предсказание.

Вот это кстати интересный вопрос. Я не настолько в 265 заинтересован чтобы детально копать как там унутрях процессинг сделан на тему ошибок округлений и проч. И я вполне допускаю идею что эффект варьируется в зависимости от того как кишки процессинг делали. Но эту рукоятку неплохо иметь под рукой - с более высокими разрядностями процессинг медленнее.

Для AV1 с его фичами скорость и рукоятки важнее. Из-за брутфорса немеряного числа вариантов кодирования он ессно медленнее в нащупывании оптимального представления. Это одна из причин по которым есть теории что "революции" с падением битрейта в разы скоро кончатся - кодеки станут слишком медленными с 1 стороны, diminishing returns с другой.

>> Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1?

Вот этот эффект я могу на 100% подтвердить для libaom+сабж. Я экспериментировал и - оно и мельче, и выглядит лучше. Это довольно редкое комбо в мире кодеков и я очень хорошо это запомнил, а 10-bit входит в базовый профайл AV1, как я понимаю compat не портится.

> Гхм, хороший монитор пригодится, чтобы видеть меньше бандинга, а не наоборот.

Офисный испортит картинку и так и сяк, разница не очевидна. Кстати в BBB этот эффект на именно движущейся картинке - малозаметен. Но на стопкадре, при HQ таргете кодирования все ж бесит, если знать что ищешь. Если целью было сделать визуально-идеальную картинку... ну... она или идеальная, или уж нет. Найти артефакт сжатия - вполне критерий для такого goal.

> Вообще, 8 бит* для SDR-видео немного не хватает и почему-то именно в
> тёмных местах. Гамма-коррекция должна контраст-между-соседними-уровнями-яркости делать
> одинаковым для глаза на всём диапазоне яркости, но она не идеально
> справляется (плюс старые стандарты не изменить), да и в реальности не
> все условия из телевизионщических стандартов соблюдаются.

Ну и вот в результате - для AV1 даже на Q, когда битрейта точно хватает - если стопкадр на fade in рассматривать, таки, в темноте видно дискретизацию. А на 10bit - как в оригинале, идеально.

Учитывая что мувик еще и меньше получается, я для себя пришел к выводу что в энных случаях я таки готов убить на 30-40% больше времени ради такого "перфекционизма".

> Но решение есть - создавать видео с более высокой разрядностью (избегать видимого
> квантования), а потом при понижении разрядности дизерить его во избежание бандинга.

Дизеринг так то нагадит сжатию, увы. Кодек либо грохнет шумодавом, либо если не грохнет, предикторам это что-то типа шума - ошибка предсказания подскочит, файло станет заметно жирнее за счет роста residuals. А вон то круто тем что файло и визуально лучше и мельче, необычное сочетание требующиее объяснения "как это возможно?!".

> Вообще "дизерить при каждом понижении разрядности" - универсальное правило для
> фото-видео-звука... и проектирования 6-битных матриц мониторов.

К сожалению это может нагнуть сжимаемость картинки, нагадив предикторам. Хинт: денойз повышает сжимаемость материала. В случае САБЖА для видео в темноте можно попытаться скроить достаточно агресивный пайплайн из 3-мерных денойзеров и решарперов, в виде когда это с одной стороны делает кодеку проще, с другой не особо убивает картинку, особенно в движении, да и шумовые артефакты разогнаные кодеком - сомнительная радость, чтобы идеально сохранять ЭТО.

> В исходнике BigBuckBunny наверняка так и сделано (один ползунок в Blender?). Но
> подмешанный высокочастотный шум плохо переживает перекодирование (а если переживает,
> то жрёт битрейт) и бандинг всё-таки вылезает.

Не вижу там никакого особого шума честно говоря. Просто очень плавный computer-generated градиент в начале мувика. Он неравномерный - и потому ошибки дискретизации на этом могут вылезти вполне видимыми "контурами". На движущейся картинке маскируется, fade in близок к идеалу. Но если знать что ищешь, в стопкадре, с хорошим моником, в темноте, таки, найдется. А с 10 битами таки - визуально как оригинал.

> Но если при перекодировании поднять разрядность, то мы частично вернёмся**
> к тому, с чего начали - к нормальным >8-битным градиентам без дизеринга. Точнее,
> теперь за дизеринг для 8-битных экранов отвечает плеер.

Для меня первое выглядело не столько дизерингом сколько просто "дискретностью", плоские регионы, явно "дискретные", как изолинии на карте. Как будто 1-2 бита LSB местами просто профакались при процессинге. А любой дизеринг с которым сталкивается кодек должен портить сжатие - весьма заметно предикторы нагибает.

> В x264/x265 ещё можно было тёмным местам задать качество повыше через --aq-mode=3
> (Auto-variance AQ with bias to dark scenes).

У AV1 тоже такая штука есть. Но мануально твикать вот именно его - на любителя: в зависимости от мувика может получиться как лучше так и хуже, эффект весьма зависит от характера контента. И результат варьируется от неплохого улучшения до "что это за фигня?!". Если кодить в fire and forget его лучше не трогать. Если хочется максимум для конкретного мувика, вариант. Но вообще AV1 даже и без этого мастеркласс может дать по битрейт-качество.

> * на самом деле ещё хуже - 7.88 бит (16-235).
> ** Получается, для этого трюка достаточно выкидывания высоких частот энкодером - о
> предварительной ручной отмене дизеринга можно не думать. Думать (о фильтрации в
> vapoursynth, например) придётся, если только исходник уже пострадал от бандинга.

Я таки подозреваю что конкретика в ощибке может здорово варьироваться от кишок кодера. Может програмеры в x265 решили что раз он не быстрый то возьмем дескать разрядность с запасом, в большем числе мест - и тогда относительный выигрыш от маневра просядет. Но таком случае они, вероятно, заметно нагнули скорость в дефолтном code path. Ну как, lanes в SIMD либо столько либо столько. И если не влезло в байт - ну, упс, значит это заметно медленнее. x265 в этом смысле проще, у него меньше продвинутых фишек и его время не так сильно жмет. Ну так он в результате и оказыается под кривой AV1 - хоть что с ним делай, а фич у формата меньше. Так что реально он скорее конкурент VP9 какому получился. Вот только тот бесплатный и даже уже по сути устаревший, однако. И продать такое - но с кучей патентов и за деньги - по моему исо уже совсем охамело с такими соотношениями.

Кстати качнул сравнения MSU за 2022 - и я уж не знаю в чем фокус, может гугл им там не заплатил, или конкуренты доплатили, или там что, но libaom у них был супер-архаичной версии. Он и жал куда хуже - и делал это намного тормознее. Так что их результаты тестов для libaom там имеют нулевую real world ценность: на практике соотношения у libaom намного лучше. В чем пойнт бенчить именно так - ну а кто их там знает. Довольно забавно что одного из самых сильных конкурентов так беспардонно задвинули, и все как бы честно - ну кто там циферку версии будет в деталях изучать?! А я вот дотошный и знаю какой путь оно за это время прошло. Ну и корректирую мои выводы на тему валидности такого бенча соответственно.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру