>Я не согласен с "очень незначительно" - в терминах битрейта при равном качестве ощутимо может быть. За что и не рекомендуют при кодировании "для себя".Для себя можно и не использовать (если более быстрый seeking не нужен, потому что тайлы и его ускоряют), но это именно очень незначительно, что опять же не очень сложно и проверить любому кто минимально знаком как считать метрики и кодировать, для примера взял один из сэмплов, 1080p пресет 4:
Размер --- VMAF -- MS-SSIM - Тайлы (columns|rows log2)
33984647 89.963493 0.996456 1 0 (всего 2)
33983309 89.960426 0.996454 0 0 (нет тайлов)
33972823 89.919441 0.996441 1 2 (2x4, всего 8)
Как можно заметить размеры файлов практически одинаковые (и соответственно битрейт), разброс минимальный, оценки метрик тоже очень близкие и опять 2 тайла дало чуть лучший результат, но это скорее погрешность, потому что и размер чуть больше, по покадровым графикам метрики можно сказать сливаются, никаких просадок на каких то определенных кадрах не замечено, визуально невозможно определить где использовались тайлы, а где нет, даже если попиксельно рассматривать каждый кадр (какая то разница есть, но сказать где хуже или лучше невозможно), притом это и для 8 тайлов не заметить, где чуть большая просадка, не то что для 2.
Для более медленных пресетов может и будет чуть больше разница и когда нужно выжать максимум и тайлы не важны совсем, то их можно не использовать, но их влияние на качество минимальное, большинство других параметров кодирования и то дадут большую разницу, тайлы для определенных форматов могут быть вредными или очень заметными, например для HEVC с хардварным кодированием на смартфонах можно даже временами эти линии и разрывы с тайлами увидеть, но у AV1 их реализация намного лучше и я подобного не замечал.
>С тех пор он в общем то стал еще лучше. И таки редкий случай когда это не гнилой пиар - а вполне честные данные. Реально шустрая для своей плотности сжатия штука.
Все же есть некоторая маркетинговость графиков, там во первых среднее из всех метрик, что очень не рекомендуется делать для нормальных результатов, используется 96 ядерный процессор, ну а большинство других кодеров столько не могут загрузить, x264 к примеру после 12 потоков практически не параллелится, ну и понятно откуда тут взялась такая разница в скорости.
Да и по соотношению качества пресетов несоответствия, особенно быстрых, svt-av1 с первых версий имел баг с блочностью на сложных кадрах или когда какие то резкие движения и он особенно часто проявляется на p7 и быстрее, просто на случайных кадрах есть выпавшие очень заметные блоки, притом даже x264 на этих же кадрах такого не позволяет, хотя может общее среднее качество и будет чуть похуже.
Ну и вот на этот баг уже десятки репортов висит и так ничего не исправляется, а уже годы прошли и притом это может случайно вылезти даже на самых медленных пресетах и там подобное не сразу и не заметить, если прямо по кадрам не сравнивать, но штука неприятная если это видео например для распространения будет или как архивное.
>Я не пользуюсь дискордом и мне похрен на него. Но на кодирование сабжем в CRF дельный материалец попадался, я на нем и забазировался.
Дискорд неудобен что он закрыт от поиска извне и если в определенных конфах не сидеть, то информация оттуда никуда и не выходит, ну а там сейчас большинство обсуждений, доработок и ресерчей происходит и многие разработчики кодеков также сидят.
Doom9 же почти вымирающий, а по av1 туда минимум какой то информации попадает, вот Блюсворд тут временами просыпается из годовой спячки и бывает что-то публикует, но все это часто через короткий промежуток становится уже не совсем актуальным, да и из того что публикуется не все там правильно или было проверено.
>У меня несколько нежатых "raw" последовательностей есть - я иногда балуюсь тестами открытых кодеков для себя. И могу сказать что с вон тем зацитированым куском командлайна напрягаюсь уже отличить сжатое от оригинала. И не, никакие мелкие детали он не грохает. Даже чат с фонтом с субпиксельным сглаживанием - норм вроде, от оригинала так сразу не отличишь.
Тут зависит от битрейта, для средне-низких или для чистого/плоского контента, как я уже написал, то av1 неплох, но вот если есть очень качественный исходник с кучей мелких деталей и нужно добиться архивного качества, то пока что любой av1 кодировщик тут не готов, даже на самых медленных пресетах, я и на -3 кодировал и с 0 для aom, при обычном просмотре это может и не заметить, но при покадровом это очень явно, ну а чтобы какой то film grain сохранить оригинальный или шум, речи совсем не идет, тут разве что синтезированный может помочь, но у него куча своих недостатков и что паттерны бывают достаточно заметны и что его трудно подобрать под исходник, да и вместе с зерном там и прочие детали отфильтровываются, а вот x26x подобное вполне могут, если знать что крутить и если это не низкобитрейтное кодирование.
>Интересно нафига? Чтоб смартфоны всякие в софте на относительно хилом но многоядерном проце жевали?
У Ютуба очень облегченный для декодирования профиль av1, все что тяжелое практически не используется, ну и да, чтобы максимально широко было доступно декодирование на любой микроволновке, а кодируется там хардварно, асиками, так что скорее и дальше надолго подобные настройки останутся, до каких то следующих поколений и обновлений этих кодировщиков.
А по скачиванию, ну любым даунлоадером или yt-dlp, тут все обычно.
>Может там декодер другой юзается? Ну скажем ffmpeg'овский dav1d? А в хроме гугл какую-то свою либу двигал
В Chrome и остальных браузерах практически сразу dav1d и был, это в андройде свой использовался gav1, но сейчас в новых версиях тоже на dav1d меняют, скорее всего какой то режим экономии энергии или что-то подобное, а для десктопов чтобы декодер не весь процессор отжирал его как то ограничивают
