Зачем какому-то среднестатистическому пользователю использовать avif? В статье косвенно говорится кому это нужно, тем чьи сайты на первых местах в поисковиках.
Ну раз пользователь не видит оригинала, то значит ему можно подсовывать вообще какую-то дичь сгенерированную нейросетями, которая только отдалённо напоминает оригинал, но за то визуально круто выглядит, так что-ли? Будет весить такая картинка сгенерированная нейросетями 2кб например, хорошо же.
Я абсолютно против такого, пусть выглядит хуже, не важно как, главное чтобы было максимальное сходство с оригиналом, как бы весь смысл сжатия с потерями, как ни странно, сделать минимальные потери при максимальном сжатии.
1) Сейчас скорость кодирования можно сказать не учитывается, потому-что 1 раз закодировал, а посмотрели эту картинку например 10000 раз.
2) Тут согласен, жепег визуально может казаться лучше при слепом тестировании из-за добавления своего шума, тогда как webp и тем более avif не добавляют шума, а наоборот избавляются от того шума, что есть в исходнике. Например если фотка сильно пошарплена, тогда жепег 100% будет казаться лучше при слепом тестировании. Но если жепег такой, что видна блочность, тогда avif 100% лучше, ну а webp как повезёт (в зависимости от контента). Так же жепег сильно блочит градиенты, например небо на фотках.
Так же, слепое сравнение жепега и avif без сравнения с исходником такое себе занятие. А если сравнивать именно с исходником, то avif сохраняет куда больше инфы, тогда как при сравнении между собой без сравнения с исходником avif может показаться хуже жепега.
Привыкли мы уже к жепегу так сильно, что остальное кажется плохим, а оно не плохое, оно просто работает по другому. Например avif (av1) делает упор на мелкие детали и заметно мылит что-то слабо контрастное, но мы наоборот лучше видим потери в слабо контрастных участках, чем в мелких деталях, поэтому нужно использовать адаптивную квантизацию, чтобы выделять больше бит на слабо контрастные участки, тогда можно избежать "мыльца" при том что мелкие детали всё равно будут лучше чем у жепега.
Проблема в том, что разрабы браузеров почему-то не хотят использовать быстрый декодер (dav1d), который декодирует avif в 2-3 раза быстрее чем это делает референсный декодер aom. dav1d на ПК декодирует avif с такой же скорость, с которой декодируется heic/heif, а на arm скорее всего даже быстрее.
av1 (avif) на ПК декодируется с такой же скоростью что и hevc (h265) (heic/heif) при возможном лучшем качестве. На arm скорее всего декодируется быстрее чем hevc, я это пока не тестировал (протестирую). Аппаратная поддержка av1 уже есть.
Просто не нужно использовать на странице фотки 12мп, тогда проблем быть не должно, такие фотки использовать только в галереях, где они показываются по 1 штуке за раз.
А вот перестарались со сжатием в vvc (h266), говорят он в 2 раза медленее декодируется чем hevc. А vp9/av1 ориентированы на веб, поэтому ориентировались на быстрое декодирование. Для av1 просто нужно использовать декодер dav1d и всё.
Уже какое-то время есть плагин avif для фотошопа, с открытым исходным кодом от какого-то разраба. Минус этого плагина - нету предпросмотра, но с такой то скоростью кодирования возможно это и не минус.
Мне тоже не понятно почему в статье про это ни слова, тогда как именно от этого зависит итоговое качество картинки. Плюс кодера/декодера АМД в том, что он потребляет в разы меньше чем у Nvidia, он так сказать более аппаратный, тогда как у Nvidia используются cuda ядра, а не только аппаратный блок.
Так же, разница качества между АМД и Nvidia, может быть минимальная, за счёт оптимизаций кодера под низкую задержку, тогда как я тестировал наоборот с максимально возможным качеством, что даст задержку кодирования минимум 70мс, а по факту скорее всего в разы больше, что не подходит для таких сервисов.
Наверное убрали буферы, убрали b-кадры, оставили 1 референсный кадр и получили дичь, а не качество, иначе никак. Или буферы и иерархическая структура референсных кадров с b-кадрами, или низкая задержка и кодек обрезан под корень. А когда кодек так обрезан, нужно использовать х2 битрейт, чтобы качество не страдало.
Хотите верьте, хотите нет, по моим тестам кодер в AMD - дно, по сравнению с Nvidia, по крайней мере во всём, что до rx 6000, по сравнению с rtx 2000. А HEVC (h265) у АМД вообще мёртвый, он у них даёт качество хуже чем AVC (h264), тогда как hevc Nvidia даёт лучше качество чем их же avc и он на уровне avc закодированного кодером х264. RX 6000 я не тестировал, но сомневаюсь, что там они внезапно сделали кодер лучше чем у Nvidia. Nvidia постепенно улучшала свой кодер начиная с gtx 600 и только в rtx 3000 они оставили такой же кодер, как в rtx 2000.
Аппаратный кодер у АМД - дно, по сравнению с Nvidia, по крайней мере на всём, что до rx 6000, а rx 6000 я не тестировал, но сомневаюсь что там внезапно сильно подняли качество кодера, что оно стало лучше чем у Nvidia.
Только 1 вопрос. Какой максимальный битрейт вы можете отдать клиенту? То что написано в статье (20 мбит 60 фпс 1080р) - это, в зависимости от настроек кодера, либо мыльцо лютое, либо квадратики. Это и близко не то, что будет на локальной машине, на локальной машине и 720р будет лучше чем такое шакальное 1080р.
Давно пробовал playkey, диспетчер задач показывал скорость 30-35 мбит - картинка дичь, просто не хочется в такое играть и всё, лучше играть на минималках на своём ПК, чем в это. Такое качество подойдёт разве что для мобилок и планшетов, даже на ноуте с экраном 15.6 уже так себе, про мониторы 24-32 дюйма и тем более телевизоры и говорить нет смысла.
У меня интернет 250 мбит, торренты качает стабильно 25 МБ/с (200 мбит), бывает поднимается до 35 МБ/с (280 мбит) в зависимости от сидов, поэтому нужен поток хотя бы 80 мбит (в идеале 120-150 мбит), иначе только если бесплатно.
Объективно, в таком случае это должна быть игра в вакууме. Просто новая игра никак не связанная с серией GTA и тем более не ремастер. А ремастер в любом случае не должен быть хуже оригинала, на то он и ремастер. Объективно, сейчас подобная игра не стоит столько, сколько за неё просят, тем более их сделали три, на коленке за 2 года. Я бы не дал больше 2000р за эту трилогию, при том что GTA 5 у меня куплена в стиме за фулл прайс, без каких-либо скидок, а остальные куплены там же но на распродаже. Просто нету никакого смысла покупать это, когда есть оригинал.
Иметь в ремастере 2021 года текстуры хотя бы не хуже игры 2008 года (GTA 4) и при этом чтобы оно нормально работало на самых новых консолях - это завышенные ожидания?
Да если бы они сделали ремастеры используя только ассеты из GTA 4, GTA 5 - это и то лучше бы выглядело.
Смешной порт на мобилки, который выдаёт 80 fps на rtx 3090 в 4К. Чего уж мелочиться, нужно было добавить полное глобальное RT освещение и получать 30 fps на rtx 3090 в лучшем случае (как раз RT уже пытаются втулить в мобилки).
Если ЭТО реально дойдёт до мобилок, то думаю графон там будет хуже чем у тех портов, что есть сейчас, ну и нулевая дальность отрисовки конечно же, как без этого.
HEVC своими большими блоками превращает небо в набор этих блоков
Да не hevc, а мобилки со своим ущербным hevc. Вот небо из моих видео, ну где тут у hevc блоки? Конечно если бы я не делал avc оптимизированный под декодирование, то он был бы по лучше, меньше была бы блочность, но всё равно нету у hevc блоков, это проблема чисто кривых аппаратных кодеров.
AVCHEVCAV1
Тут битрейт вышел 423 мбит вместо 300, 2 проходный режим av1 явно не готовили к all-intra
И цвета почему-то другие, вот тут вообще хз почему, все цвета другие, а не только небо.
Кто из них тут лучше?
А скорость декодирования этого (гружу его на яндекс к остальным файлам) av1 в ffmpeg - 80 fps, получается 300 мбит были бы быстрее чем hevc 300 мбит
Жрал раньше, сейчас по крайней мере декодирование с помощью декодера libdav1d не медленнее чем у hevc, так же аппаратная поддержка уже есть в железе, остальное зависит от самих монтажек, когда они там соизволят добавить av1 и его аппаратное декодирование, если вообще соизволят. Там больше сложность для монтажек в его иерархической 3-4 уровневой структуре референсных кадров, но в all-intra этого нету в принципе.
за счет одинаковых блоков
Добавил в ту же папку скрины с анализатора с отображением разных типов блоков. А градиенты лучше скорее всего из-за блоков трансформации, ну и из-за того что аппаратный hevc решает ставить огромные блоки на небо, тогда как программный x265 так не делает. Так же тут поможет агрессивная адаптивная квантизация, она выделит больше бит для градиентов в ущерб качеству резких деталей, потому что визуально блочность на градиентах видна сильне чем на сложных мелких деталях. Но конечно в мобилках её нет, а если и есть, то не настраивается, в nvenc например настраивается, а у amd только вкл/выкл. У интела вообще нету, по крайней мере нету такого параметра в ffmpeg.
Можете просто снять статичный кадр с небом в avc и hevc all-intra, а я посмотрю что там по блокам, ну или просто скачайте Elecard StreamEye 2021 и сами потыкайте.
Уже какой раз говорю, что нету там одинаковых блоков, если это нормальный avc. Одинаковые блоки у h261/h262, может быть и у h263. У avc mb 16х16, с них начинается кодирование, а вот блоки предсказания от 16х16 до 4х4, а inter блоки предсказания могут быть ещё и 8х16/16х8, блоки трансформации точно не знаю, но вроде так же от 16х16 до 4х4, ну или от 8х8. Блоки трансформации это те блоки к которым применяется квантизатор, они могут быть меньше чем блоки предсказания, например предсказание 16х16, а трансформация 4х4.
Примерно так же у hevc, только там называется не mb и работает немного по другому. Типо там можно выбрать начальный размер, а не всегда начинать кодирование с максимального. Вибирать можно 64х64, 32х32, 16х16, потом так же идут блоки предсказания, только по сравнению с avc есть не только прямоугольные блоки, а ещё деление 3/1, например 32х24/24х32 и 32х8/8х32 (в мобилках конечно нету этого, там и прямоугольных в hevc может не быть). Потом так же блоки трансформации. Не знаю только может ли hevc в прямоугольные и 3/1 intra блоки, вроде как нет, только inter такие бывают, но в любом случае я в принципе кодировал без этих блоков, их включение в x265 кодере очень сильно замедляет кодирование.
Я просто не вижу смысла говорить про фиксированный размер mb в avc, ну фиксированный он и что с того? Качество предсказания, как не удивительно, зависит от блоков предсказания, а не mb, качество квантизации от блоков квантизации.
И да, вы не думайте что это программные кодеры делают отсебятину в плане размеров блоков, это всё есть в стандарте и на данный момент вроде как все кодеры avc в мобилках могут во все возможные размеры блоков предсказания, а вот в hevc не могут, бывает что в hevc у них нету таких блоков, которые есть в avc.
Для сравнения добавил в туже папку prores (конечно кодер не apple, а ffmpeg, так что качество по хуже, чем могло бы быть) и avc all-intra оптимизированный под быстрое декодирование.
Скорость кодирования подобрал, чтобы было близко к прорес: прорес - 45 фпс, avc - 47 фпс.
Скорость декодирования в ffmpeg: прорес - 207 фпс, avc - 278 фпс.
Качество лучше у avc, ну а у hevc сильно лучше качество. Вопрос, зачем нужен прорес, если он при меньшей скорости декодирования показывает хуже качество чем avc? В моём понимании прорес - это просто велосипед от apple смысла в котором нет. Просто изобрели очередной велосипед, который вышел даже хуже прошлых (стандарт avc вышел в 2003 году, prores в 2007 году). Плюс у avc/hevc аппаратная поддержка.
Так же hevc тоже можно оптимизировать под более быстрое декодирование, но там разница не такая большая как у avc. Вышло бы вместо 86 фпс (цифра из прошлого коммента) где-то 100-110 фпс. Жалко что в аппаратных кодерах так не оптимизируешь, но если бы у производителей была цель выдать поток под монтажки, то сделали бы и avc и hevc, так-как оптимизация заключается только в отключении некоторых фишек кодека, которые сильно влияют на скорость декодирования.
В теории можно использовать даже vp9/av1, если их нормально реализуют аппаратно, чтобы качество было лучше чем у avc для vp9 и на уровне или лучше чем у hevc для av1. Скорость декодирования vp9 находится между avc и hevc, скорость декодирования av1 на уровне или чуть меньше чем у не оптимизированного hevc. А вот с новым VVC (h266) такой финт не прокатит, говорят, что у него скорость декодирования в 2 раза меньше чем у hevc.
И как бы непонятно, что мешает 150mbps проигрываться так же, учитывая, что нагрузка на проц чуть ниже. В каком месте происходит проблема, где ключевые не all-intra?
Хз, не вникал в то, как декодеры распараллеливают вычисления, вникал как это делают кодеры, чтобы грамотно ставить параметры, грузить весь проц и сильно не терять в качестве.
У меня при декодировании в ffmpeg такие результаты: 300 мбит - 67 fps - 95% проц, 150 мбит - 96 fps - 95% проц, 75 мбит - 121 fps - 98% проц, 300 all-intra - 86 fps - 100% проц.
VLC player: 300 мбит - 75% проц - не тянет, подвисает на каждом ключевом кадре, 150 мбит - 55% проц, 75 мбит - 35% проц, 300 all-intra - 85% проц
Так что в итоге, большой битрейт медленнее декодируется или всё таки нет?
Для большей параллельности при кодировании/декодировании, каждая колонка кодируется не зависимо от других, из-за этого качество снижается, но можно грузить больше ядер проца.
Завтра могу скинуть свой видос, ускоренный до 60 фпс, чтобы было лучше видно разницу в загрузке проца в давинчи.
Зачем какому-то среднестатистическому пользователю использовать avif? В статье косвенно говорится кому это нужно, тем чьи сайты на первых местах в поисковиках.
Ну раз пользователь не видит оригинала, то значит ему можно подсовывать вообще какую-то дичь сгенерированную нейросетями, которая только отдалённо напоминает оригинал, но за то визуально круто выглядит, так что-ли? Будет весить такая картинка сгенерированная нейросетями 2кб например, хорошо же.
Я абсолютно против такого, пусть выглядит хуже, не важно как, главное чтобы было максимальное сходство с оригиналом, как бы весь смысл сжатия с потерями, как ни странно, сделать минимальные потери при максимальном сжатии.
1) Сейчас скорость кодирования можно сказать не учитывается, потому-что 1 раз закодировал, а посмотрели эту картинку например 10000 раз.
2) Тут согласен, жепег визуально может казаться лучше при слепом тестировании из-за добавления своего шума, тогда как webp и тем более avif не добавляют шума, а наоборот избавляются от того шума, что есть в исходнике. Например если фотка сильно пошарплена, тогда жепег 100% будет казаться лучше при слепом тестировании. Но если жепег такой, что видна блочность, тогда avif 100% лучше, ну а webp как повезёт (в зависимости от контента). Так же жепег сильно блочит градиенты, например небо на фотках.
Так же, слепое сравнение жепега и avif без сравнения с исходником такое себе занятие. А если сравнивать именно с исходником, то avif сохраняет куда больше инфы, тогда как при сравнении между собой без сравнения с исходником avif может показаться хуже жепега.
Привыкли мы уже к жепегу так сильно, что остальное кажется плохим, а оно не плохое, оно просто работает по другому. Например avif (av1) делает упор на мелкие детали и заметно мылит что-то слабо контрастное, но мы наоборот лучше видим потери в слабо контрастных участках, чем в мелких деталях, поэтому нужно использовать адаптивную квантизацию, чтобы выделять больше бит на слабо контрастные участки, тогда можно избежать "мыльца" при том что мелкие детали всё равно будут лучше чем у жепега.
Проблема в том, что разрабы браузеров почему-то не хотят использовать быстрый декодер (dav1d), который декодирует avif в 2-3 раза быстрее чем это делает референсный декодер aom. dav1d на ПК декодирует avif с такой же скорость, с которой декодируется heic/heif, а на arm скорее всего даже быстрее.
av1 (avif) на ПК декодируется с такой же скоростью что и hevc (h265) (heic/heif) при возможном лучшем качестве. На arm скорее всего декодируется быстрее чем hevc, я это пока не тестировал (протестирую). Аппаратная поддержка av1 уже есть.
Просто не нужно использовать на странице фотки 12мп, тогда проблем быть не должно, такие фотки использовать только в галереях, где они показываются по 1 штуке за раз.
А вот перестарались со сжатием в vvc (h266), говорят он в 2 раза медленее декодируется чем hevc. А vp9/av1 ориентированы на веб, поэтому ориентировались на быстрое декодирование. Для av1 просто нужно использовать декодер dav1d и всё.
Уже какое-то время есть плагин avif для фотошопа, с открытым исходным кодом от какого-то разраба. Минус этого плагина - нету предпросмотра, но с такой то скоростью кодирования возможно это и не минус.
Мне тоже не понятно почему в статье про это ни слова, тогда как именно от этого зависит итоговое качество картинки. Плюс кодера/декодера АМД в том, что он потребляет в разы меньше чем у Nvidia, он так сказать более аппаратный, тогда как у Nvidia используются cuda ядра, а не только аппаратный блок.
Так же, разница качества между АМД и Nvidia, может быть минимальная, за счёт оптимизаций кодера под низкую задержку, тогда как я тестировал наоборот с максимально возможным качеством, что даст задержку кодирования минимум 70мс, а по факту скорее всего в разы больше, что не подходит для таких сервисов.
Наверное убрали буферы, убрали b-кадры, оставили 1 референсный кадр и получили дичь, а не качество, иначе никак. Или буферы и иерархическая структура референсных кадров с b-кадрами, или низкая задержка и кодек обрезан под корень. А когда кодек так обрезан, нужно использовать х2 битрейт, чтобы качество не страдало.
Хотите верьте, хотите нет, по моим тестам кодер в AMD - дно, по сравнению с Nvidia, по крайней мере во всём, что до rx 6000, по сравнению с rtx 2000. А HEVC (h265) у АМД вообще мёртвый, он у них даёт качество хуже чем AVC (h264), тогда как hevc Nvidia даёт лучше качество чем их же avc и он на уровне avc закодированного кодером х264. RX 6000 я не тестировал, но сомневаюсь, что там они внезапно сделали кодер лучше чем у Nvidia. Nvidia постепенно улучшала свой кодер начиная с gtx 600 и только в rtx 3000 они оставили такой же кодер, как в rtx 2000.
Аппаратный кодер у АМД - дно, по сравнению с Nvidia, по крайней мере на всём, что до rx 6000, а rx 6000 я не тестировал, но сомневаюсь что там внезапно сильно подняли качество кодера, что оно стало лучше чем у Nvidia.
Только 1 вопрос. Какой максимальный битрейт вы можете отдать клиенту? То что написано в статье (20 мбит 60 фпс 1080р) - это, в зависимости от настроек кодера, либо мыльцо лютое, либо квадратики. Это и близко не то, что будет на локальной машине, на локальной машине и 720р будет лучше чем такое шакальное 1080р.
Давно пробовал playkey, диспетчер задач показывал скорость 30-35 мбит - картинка дичь, просто не хочется в такое играть и всё, лучше играть на минималках на своём ПК, чем в это. Такое качество подойдёт разве что для мобилок и планшетов, даже на ноуте с экраном 15.6 уже так себе, про мониторы 24-32 дюйма и тем более телевизоры и говорить нет смысла.
У меня интернет 250 мбит, торренты качает стабильно 25 МБ/с (200 мбит), бывает поднимается до 35 МБ/с (280 мбит) в зависимости от сидов, поэтому нужен поток хотя бы 80 мбит (в идеале 120-150 мбит), иначе только если бесплатно.
Объективно, в таком случае это должна быть игра в вакууме. Просто новая игра никак не связанная с серией GTA и тем более не ремастер. А ремастер в любом случае не должен быть хуже оригинала, на то он и ремастер. Объективно, сейчас подобная игра не стоит столько, сколько за неё просят, тем более их сделали три, на коленке за 2 года. Я бы не дал больше 2000р за эту трилогию, при том что GTA 5 у меня куплена в стиме за фулл прайс, без каких-либо скидок, а остальные куплены там же но на распродаже. Просто нету никакого смысла покупать это, когда есть оригинал.
Иметь в ремастере 2021 года текстуры хотя бы не хуже игры 2008 года (GTA 4) и при этом чтобы оно нормально работало на самых новых консолях - это завышенные ожидания?
Да если бы они сделали ремастеры используя только ассеты из GTA 4, GTA 5 - это и то лучше бы выглядело.
Смешной порт на мобилки, который выдаёт 80 fps на rtx 3090 в 4К. Чего уж мелочиться, нужно было добавить полное глобальное RT освещение и получать 30 fps на rtx 3090 в лучшем случае (как раз RT уже пытаются втулить в мобилки).
Если ЭТО реально дойдёт до мобилок, то думаю графон там будет хуже чем у тех портов, что есть сейчас, ну и нулевая дальность отрисовки конечно же, как без этого.
Да не hevc, а мобилки со своим ущербным hevc. Вот небо из моих видео, ну где тут у hevc блоки? Конечно если бы я не делал avc оптимизированный под декодирование, то он был бы по лучше, меньше была бы блочность, но всё равно нету у hevc блоков, это проблема чисто кривых аппаратных кодеров.
Кто из них тут лучше?
А скорость декодирования этого (гружу его на яндекс к остальным файлам) av1 в ffmpeg - 80 fps, получается 300 мбит были бы быстрее чем hevc 300 мбит
Жрал раньше, сейчас по крайней мере декодирование с помощью декодера libdav1d не медленнее чем у hevc, так же аппаратная поддержка уже есть в железе, остальное зависит от самих монтажек, когда они там соизволят добавить av1 и его аппаратное декодирование, если вообще соизволят. Там больше сложность для монтажек в его иерархической 3-4 уровневой структуре референсных кадров, но в all-intra этого нету в принципе.
Добавил в ту же папку скрины с анализатора с отображением разных типов блоков. А градиенты лучше скорее всего из-за блоков трансформации, ну и из-за того что аппаратный hevc решает ставить огромные блоки на небо, тогда как программный x265 так не делает. Так же тут поможет агрессивная адаптивная квантизация, она выделит больше бит для градиентов в ущерб качеству резких деталей, потому что визуально блочность на градиентах видна сильне чем на сложных мелких деталях. Но конечно в мобилках её нет, а если и есть, то не настраивается, в nvenc например настраивается, а у amd только вкл/выкл. У интела вообще нету, по крайней мере нету такого параметра в ffmpeg.
Можете просто снять статичный кадр с небом в avc и hevc all-intra, а я посмотрю что там по блокам, ну или просто скачайте Elecard StreamEye 2021 и сами потыкайте.
Уже какой раз говорю, что нету там одинаковых блоков, если это нормальный avc. Одинаковые блоки у h261/h262, может быть и у h263. У avc mb 16х16, с них начинается кодирование, а вот блоки предсказания от 16х16 до 4х4, а inter блоки предсказания могут быть ещё и 8х16/16х8, блоки трансформации точно не знаю, но вроде так же от 16х16 до 4х4, ну или от 8х8. Блоки трансформации это те блоки к которым применяется квантизатор, они могут быть меньше чем блоки предсказания, например предсказание 16х16, а трансформация 4х4.
Примерно так же у hevc, только там называется не mb и работает немного по другому. Типо там можно выбрать начальный размер, а не всегда начинать кодирование с максимального. Вибирать можно 64х64, 32х32, 16х16, потом так же идут блоки предсказания, только по сравнению с avc есть не только прямоугольные блоки, а ещё деление 3/1, например 32х24/24х32 и 32х8/8х32 (в мобилках конечно нету этого, там и прямоугольных в hevc может не быть). Потом так же блоки трансформации. Не знаю только может ли hevc в прямоугольные и 3/1 intra блоки, вроде как нет, только inter такие бывают, но в любом случае я в принципе кодировал без этих блоков, их включение в x265 кодере очень сильно замедляет кодирование.
Я просто не вижу смысла говорить про фиксированный размер mb в avc, ну фиксированный он и что с того? Качество предсказания, как не удивительно, зависит от блоков предсказания, а не mb, качество квантизации от блоков квантизации.
И да, вы не думайте что это программные кодеры делают отсебятину в плане размеров блоков, это всё есть в стандарте и на данный момент вроде как все кодеры avc в мобилках могут во все возможные размеры блоков предсказания, а вот в hevc не могут, бывает что в hevc у них нету таких блоков, которые есть в avc.
Для сравнения добавил в туже папку prores (конечно кодер не apple, а ffmpeg, так что качество по хуже, чем могло бы быть) и avc all-intra оптимизированный под быстрое декодирование.
Скорость кодирования подобрал, чтобы было близко к прорес: прорес - 45 фпс, avc - 47 фпс.
Скорость декодирования в ffmpeg: прорес - 207 фпс, avc - 278 фпс.
Качество лучше у avc, ну а у hevc сильно лучше качество. Вопрос, зачем нужен прорес, если он при меньшей скорости декодирования показывает хуже качество чем avc? В моём понимании прорес - это просто велосипед от apple смысла в котором нет. Просто изобрели очередной велосипед, который вышел даже хуже прошлых (стандарт avc вышел в 2003 году, prores в 2007 году). Плюс у avc/hevc аппаратная поддержка.
Так же hevc тоже можно оптимизировать под более быстрое декодирование, но там разница не такая большая как у avc. Вышло бы вместо 86 фпс (цифра из прошлого коммента) где-то 100-110 фпс. Жалко что в аппаратных кодерах так не оптимизируешь, но если бы у производителей была цель выдать поток под монтажки, то сделали бы и avc и hevc, так-как оптимизация заключается только в отключении некоторых фишек кодека, которые сильно влияют на скорость декодирования.
В теории можно использовать даже vp9/av1, если их нормально реализуют аппаратно, чтобы качество было лучше чем у avc для vp9 и на уровне или лучше чем у hevc для av1. Скорость декодирования vp9 находится между avc и hevc, скорость декодирования av1 на уровне или чуть меньше чем у не оптимизированного hevc. А вот с новым VVC (h266) такой финт не прокатит, говорят, что у него скорость декодирования в 2 раза меньше чем у hevc.
Хз, не вникал в то, как декодеры распараллеливают вычисления, вникал как это делают кодеры, чтобы грамотно ставить параметры, грузить весь проц и сильно не терять в качестве.
У меня при декодировании в ffmpeg такие результаты: 300 мбит - 67 fps - 95% проц, 150 мбит - 96 fps - 95% проц, 75 мбит - 121 fps - 98% проц, 300 all-intra - 86 fps - 100% проц.
VLC player: 300 мбит - 75% проц - не тянет, подвисает на каждом ключевом кадре, 150 мбит - 55% проц, 75 мбит - 35% проц, 300 all-intra - 85% проц
Так что в итоге, большой битрейт медленнее декодируется или всё таки нет?
https://disk.yandex.ru/d/e36Itp4Mpg30qg
Скорость кодирования, последняя строчка - это all-intra
Для большей параллельности при кодировании/декодировании, каждая колонка кодируется не зависимо от других, из-за этого качество снижается, но можно грузить больше ядер проца.
Завтра могу скинуть свой видос, ускоренный до 60 фпс, чтобы было лучше видно разницу в загрузке проца в давинчи.
Что-то явно не так, слишком большая разница, особенно 24 фпс на all-intra. Но монтажки как-то работают по своему, не как плееры.