>Они минимальны в процентах метрики. Но если инвертировать вопрос и задаться вопросом "на сколько отличается битрейт при равном качестве картинки" (одинаковый SSIM/VMAF/визуальное качество/wahtever) - разница более заметная. Точно не 1% по битрейту. Тут на опеннете кто-то чертил в прошлой новости, просто 2 линии до пересечения с кривой, маппинг 2 точек с 1 стороны в 2 точки с другой. И с другой стороны вовсе не 1% будет.

Конечно тут сильно зависит от контента и от пресета, если не путаю на P4 тестировали (один из оптимальных пресетов, дальше там все уменьшающаяся эффективность за очень большой рост времени кодирования) и он в среднем был около 1% или даже чуть меньше для двух тайлов, это среднее для десятка разных видео сэмплов по BD-Rate, т.е. на каких то может быть чуть больше, на каких то использование тайлов может давать даже лучшие оценки метрик, но если использовать еще больше тайлов, то там да, в основном результаты ухудшаются.
Суть в том что это может немного влиять на качество, но очень незначительно и если нет задачи выжать самый возможный максимум от кодировщика и когда время кодирования не имеет значения, то вполне себе можно их использовать, ну или если это просто для личного использования и скорости декодирования и так хватает.
А так разница между пресетами или даже многими другими опциями будет намного больше, с тайлами нет раздутия битрейта для такого же качества на 30%, да или даже 10%, если их не накидывать до предела.

>Для тяжелого кодека где мы убиваемся за битрейт-качество это таки - важный фактор, иначе зачем мы проц грели вообще?! Утяжеление на идентичном crf файла будет не 1% а уже несколько, может даже десяток. Ибо инверсный маппинг точек на кривой - довольно крут, и "небольшое" изменение транслированое в битрейт становится ощутимым.

Ну с SVT-AV1 тяжесть очень расплывчата, у него выбор пресетов от -3 (в форке, т.е. -3, -2, -1, 0, 1 и т.п.) до 13 и на быстрых пресетах он подходит для стриминга и даже при достаточном количестве потоков обгоняет более старые кодеки по скорости (может за исключением уж самых быстрых пресетов), при обычно лучшем качестве.
Не всегда и не всем нужно максимально возможное качество от av1, бывает что важнее лучшее соотношение скорости и качества, можно глянуть старые слайды от интела где они показывают как svt-av1 всех уделывает по скорости/качеству (кроме может vvc на медленных режимах)
https://user-images.githubusercontent.com/12956286/183626151...
Да и тем более для архивного и визуально lossless кодирования av1 все еще недозрел, он все еще очень уж много мелких деталей отбрасывает и не важно какой из открытых кодировщиков использовать, хотя ситуация немного улучшается и даже комьюнити помогает патчами уменьшить это смазывание и эффект пластиковости, но до x26x еще далеко, а вот для низких битрейтов с приемлемой картинкой av1 хорош.

>А это как определялось? Памятуя как меня тут жестко наели с свойствами САБЖА, что по требуемому CPU, что по RAM, думаю что вы поймете мой скепсис и желание верифицировать данные.

Определялось что, количество тайлов у Ютуба или скорость декодирования?
С Ютуба можно просто скачать случайное av1 видео и посмотреть в аналайзерах, кстати там обычно даже для 360p и 480p используется два тайла, для 720p четыре (2x2), для 1080p - 8 (4x2), для 4к - 32 (8x4) и т.п., но иногда по какому то принципу используется только вертикальное деление, для HDR в основном замечал, ну и еще Ютуб не использует CDEF (один из тяжелых фильтров, который хорошо подчищает и блочность и артефакты на краях, но кодирование и особенно декодирование ощутимо замедляет)
А по скорости декодирования, проще ffmpeg использовать с опциями `-benchmark -stream_loop -1` с выводом в NUL/null, там покажет fps или еще общее время декодирования, если без `-stream_loop -1`

>Я пробовал, но мне не понравилось увеличение файлов для равного качества. И вон то не мои идеи, а выжимка doom9 и гайдов по кодированию сабжем.

При кодировании и просто добавлением тайлов размеры обычно очень близкие, как минимум для свежих aomenc и svt-av1 это должно быть так, ну про метрики я уже писал. А про doom9, это не лучшее место с информацией по av1, большинство гайдов переносится из других комьюнити и различных каналов дискорда и много чего там неактуально или не совсем верно, да и подано достаточно скудно, насколько помню там только Блюсворд более подробно по параметрам отписывался, часть там нормальной информации, часть додумок или неверной или уже на данный момент устаревшей.

>А так есть еще frame-parallel MT и проч, несколько ядер декодер и так жрать сможет. А подразумевать EPYC для декодирования все же слегка перебор :)

В основном это очень влияет на декодирование в браузерах, особенно для стримов, например Twitch недавно начал тестировать av1 и вот там у очень многих людей даже на 1080p60 av1 без тайлов были постоянные дропы при софтверном кодировании в Chrome и на остальных браузерах на основе Chromium, особенно почему то страдают Райзены первых поколений (Zen/Zen2), даже восьмиядерные, не говоря про 1440p+, ну и мы потом делали свои тесты и тайлы тут сильно помогают (с дополнительным fast-decode совсем проблем нет, но он тоже не бесплатен для качества, да и для hw кодировщиков подобное не включить одним кликом), на Firefox дело почему то получше, видимо там максимальный приоритет и больше ресурсов отдается декодированию.