> Для себя можно и не использовать (если более быстрый seeking не нужен,
> потому что тайлы и его ускоряют), но это именно очень незначительно,

Я для контролируемого времени seeking нечто типа -g 300 подгоняю или около того (в терминах ffmpeg. Время seek контролируемое получается. Тоже конечно немного битрейта теряет.

> 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 просело но реально мизер. Еще вроде кто-то упоминал потенциал для артефактов на границе стыковки тайлов.

> использовались тайлы, а где нет, даже если попиксельно рассматривать каждый кадр
> (какая то разница есть, но сказать где хуже или лучше невозможно),

Где-то народ писал что стыковка тайлов в каких-то случаях может быть не идеальная и это как бы known issue. И да, на >=1080p тайлы в умеренном количестве ничем не плохи. На более мелком - ну вот хз, если то что вы пишете верно то гугл или жестит в пользу "времени появления видео в AV1" сделав это приоритетным, или все же смог в какой-то момент подрихтовать алго уменьшив потери до приемлимых. Что libaom что сабж - moving target, живые и эволюционирующие проекты, знания могут и устареть - так что спасибо за измерения.

> притом это и для 8 тайлов не заметить, где чуть большая просадка, не то что для 2.

Ну я в конечном итоге предпочитаю доверять больше всего - глазам. Придирчиво рассмотрев что накодилось. В этом смысле CRF=30..32 в сабже почти гарантированно идеальный, даже на стопкадре артефактов не видно. Для большинства видео можно CRF до 36-40 затянуть без особых последствий. Если что у сабжа идеи на тему CRF отличаются от x26x и некоторых других, это про именно сабж.

> не использовать, но их влияние на качество минимальное, большинство других параметров
> кодирования и то дадут большую разницу,

Раньше довольно заметную разницу давали на <=720p, откуда и та идея. На >=1080p они скорее полезны из-за распараллеливания процесса - при мизерном уроне.

> на смартфонах можно даже временами эти линии и разрывы с тайлами
> увидеть, но у AV1 их реализация намного лучше и я подобного не замечал.

Ну вот народ утверждает что в принципе стыковка тайлов _может_ быть не идеальной и заметной и с AV1. Хотя лично я этот эффект в заметном объеме на сабже не видел, даже зная что искать. Тут такое дело что не весь контент одинаковый, и на каком-то те или иные артефакты (не)заметнее. Скажем "ringing" и нестыковка границ с которой CDEF борется не палится на фильмообразном контенте, но на "скринкасте" - это все все гораздо критичнее.

> Все же есть некоторая маркетинговость графиков, там во первых среднее из всех
> метрик, что очень не рекомендуется делать для нормальных результатов, используется 96
> ядерный процессор, ну а большинство других кодеров столько не могут загрузить,

Тем не менее, САБЖ оказался довольно резвый и в более скромных конфигах, при том делая весьма приятную картинку. Про AVX2 и 48 гигов было нагнано с три короба! Мне сабж весьма понравился по сочетанию свойств.

> x264 к примеру после 12 потоков практически не параллелится,

Да оно ему с его сложностью процессинга не очень то и надо, имхо. Тем более с риском потери битрейт-качество, которое у него и так ни о чем по современным меркам. Он же даже VP9 не побьет, на вашей же кривой видно что VP9 и x265 примерно равны по силе в challenging условиях.

> Да и по соотношению качества пресетов несоответствия, особенно быстрых, svt-av1 с первых
> версий имел баг с блочностью на сложных кадрах или когда какие
> то резкие движения и он особенно часто проявляется на p7 и быстрее,

Ну я с настолько быстрыми не экспериментировал, мне фоновый транскод для себя более интересен, а это 2..4 в общем случае.

> штука неприятная если это видео например для распространения будет или как архивное.

Кто ж архивное то видео на 7 пресете жмет? Там самый край - 4й. Более высокие используют довольно жесткие tradeoff вносящие приличный урон в битрейт-качество.

> а там сейчас большинство обсуждений, доработок и ресерчей происходит и многие
> разработчики кодеков также сидят.

Они и много где еще сидят, особенно нормальные, опенсорсные, а не нубы-хайпонашки с аниме и чем там еще (мне такой кейс не интересен).

> Doom9 же почти вымирающий, а по av1 туда минимум какой то информации попадает,

Просто он больше о транскоде DVD и народец там довольно проприетарный. Но ряд дельных идей по сабжу там все же есть, в относительно концентрированом виде и сравнительно валидное. А разработчики с дискордом могут идти куда подальше имхо. Псевдоопенсорс с закрытым знанием и лизом проприетарных ботинок - нахрен не упал.

> не совсем актуальным, да и из того что публикуется не все
> там правильно или было проверено.

Ну как бы сабж довольно таки moving target - но ряд идей все же достаточно базовые и остаются.

> Тут зависит от битрейта, для средне-низких или для чистого/плоского контента, как я
> уже написал, то av1 неплох, но вот если есть очень качественный исходник с кучей
> мелких деталей и нужно добиться архивного качества,

У меня есть и несколько скринкастов, с мелким текстом и проч. Который кроме всего прочего жутко чувствителен к subsampling например. Там мелкие детали так критичны что одно время libvpx делал libaom с ffmpeg! Ибо тот еще не умел в ffmpeg RGB/HBD/444 и проч а как yuv420 мклкие детали типа текста портятся by design и это видно. В актуальных версиях починено.

Не могу сказать ничего плохого о сабже с разумными пресетами (2..4) на таком контенте, с CRF в районе 30-36 или типа того. Опять же отличить от оригинала довольно сложно.

> покадровом это очень явно,

Не замечал такой эффект на моем контенте. Но как бы контента много и разного и на глобальных выводах настаивать не буду.

> ну а чтобы какой то film grain сохранить оригинальный или шум, речи совсем не идет,

Я честно говоря не понимаю зачем все это извращение надо - я совершенно не ностальгирую по техническим дефектам. Но таки CRF в районе <=30 и это вроде более-менее делает, просто битрейта будет больше. У AV1 есть синтез film grain но я с этим не развлекался. Мне технические дефекты на видео не вперлись.

> вот x26x подобное вполне могут, если знать что крутить и если
> это не низкобитрейтное кодирование.

Хызы, я немного крутил x265 и он мне совсем не понравился. Не понимаю что такого крутого в этой штуке варезники находят. И зачем мне все это знание на патентованый формат который даже в вебе потом хрен выложишь. Вот x264 по своим временам крутая штука был. Но реально в более-менее challenging ситуациях он не побьет даже VP9 непатентованый.

> У Ютуба очень облегченный для декодирования профиль av1, все что тяжелое практически
> не используется, ну и да, чтобы максимально широко было доступно декодирование

За это их видимо и лю. Пока у всех икает и лагает, у них как раз очень разумный набор компромиссов под real world с всеми его заскоками.

> на любой микроволновке, а кодируется там хардварно, асиками, так что скорее
> и дальше надолго подобные настройки останутся,

А откуда эти сведения про асики? Судя по тому сколько времени занимает транскод - они это в софте делали и бэклог немеряный. А асику душно будет столько памяти выделять на всякие реф-фреймы и проч, под реалтайм кодеры очень урезаные. У гугли в libaom есть rtc варинат и как я понимаю они его сразу в ASIC и отливают high-level synthesys'ом прямо из того сорца. Но это реалтаймный пресет, он многим жертвует ради скорости.

> А по скачиванию, ну любым даунлоадером или yt-dlp, тут все обычно.

Мне скорее интересно было кто разблюдовку на тайлы кажет и при том не очень монструозный по зависимостям и сложности сборки.

> В Chrome и остальных браузерах практически сразу dav1d и был, это в
> андройде свой использовался gav1, но сейчас в новых версиях тоже на dav1d меняют,

Во всяком случае у гугли есть своя либа декодирования av1, и вроде ее не списали в утиль? Или таки - списывают в пользу dav1d?

> подобное, а для десктопов чтобы декодер не весь процессор отжирал его
> как то ограничивают

Ну как бы чудес не бывает и что с атомом малохольным в нетбуке не делай а 4K в AV1 он все же не сжует. Особенно 32 бит которые.