>>139597
Эх, чувствую bait, но всё же…
О том.
Назовём lossless [без потерь] такое кодирование с источника, при котором соответвтвующий результат декодирования бит-в-бит идентичен результату декодирования источника. Иначе таковое кодирование назовём lossy [с потерями]. Проблема с AV1 и заключается в том, что использованый теми людьми энкодер в lossless не может; он не может добиться результата абсолютно идентичного источнику. Мы не видим видим бесконечный PSNR.
>Сам факт того что видео начали кодировать, перебирать и перезаписывать кадры это уже lossy compression
Нет. Ни разу не. Ни коим образом не следует.
>А время кодирования AV1 только подтверждает тот факт что видео кодируется с потерями.
Опять же, нет. Скорее это наводит на мысли о высоких радиусах поиска движения, большом количестве разнообразных макроблоков, прочих фичах.
Можно сказать ffmpeg -i in.mp4 -c:v libx264 -crf 0 -preset fast out.mp4
и это будет достаточно быстро и lossless (но весить будет много, скорее всего). Можно сказать ffmpeg -i in.mp4 -c:v libx264 -crf 0 -preset placebo out.mp4
, и кодироваться будет долго, и всё же будет lossless. А ещё можно сказать ffmpeg -i in.mp4 -c:v libx264 -crf 24 -preset placebo -x264-params "me_range=1024" out.mp4
, и кодироваться будет очень, очень и очень долго вследствие раздутого радиуса предсказания движения и алгоритма TESA, default’ного для placebo preset, но результат lossless не будет никогда, поскольку major quality [разница с источником/смотримость(психовизуальные оптимизации и прочее)] контроллер здесь — это CRF.
Также всё зависит от источника. При тех же алгоритмах, той же частоте кадров источника, том же разрешении источника, том же CRF (а возможно, и той же квантизации) на кадр в x264 какая-нибудь статичная картинка будет кодироваться в 15 раз быстрее, чем видео с большим количеством движения и scenecut’ов.
>Но кто сказал что если кодировщик сможет использовать все ядра процессора под полной нагрузкой, это даст прирост скорости?
Даст. По сравнению с тем, если бы кодировщик работал только на одном ядре одним потоком, очевидно же. Чем выше и эффективней распаралеливаемось — тем лучше. В особенности учитывая то, что значительно мощнее одно электронное ядрышко уже, наверное, не станет.
Одно дело, когда можно задействовать только 2 ядра i7, другое же дело, когда 56 ядер двух xeon’ов. Очевидно, что если задача хорошо распаралеливаема, то счастливый обладатель платиновых xeon’ов исполнит за 5 минут то, что обладатель i7 будет делать час. Чего разумеется не произойдёт, если задача распаралеливаема плохо. Поэтому, чем выше распаралеливаемость — тем лучше: можно увеличить скорость путём увеличения количества вычислительных единиц, можно в разы сократить время исполнения задачи, в ином же случае — нельзя.
>Боюсь без нового метода подсчёта-записи кадров и алгоритма сжатия данных при кодировании эта технология не сможет набрать популярности.
AV1 — открыт, за него не нужно компаниям (как за AVC некогда и HEVC) башлять патентообладателям деньги, а главное — он делает актуальную для многих задачу — эффективное по размеру видеокодирование в низком качестве — чуть ли не лучше всех. Хотя, лучше ли оно HEVC, в особенности, если дело касается среднего количества потерь и преодаления установленных на кодировщеке libx265 разработчиками ограничений, — не знаю. AV1, к тому же, поддерживает очень крупные макроблоки, что плюс для Ultra HD. Где-то видел, мол, Netflix, Youtube и прочие уже внедряют, Мицгол недавно писал, мол, в Firefox его поддержку добавят скоро (лучше бы поддержку HEVC добавили). А значит и остальные браузеры тоже не без поддержки останутся. Если крупные игроки начнут его и спользовать, то — хотя бы среди них — станет. Помешать может люто медленное кодирование.
И наверное помешает. Потому что оценивать кодировщики, мне кажется, следует не сколько по preset/эффективность(размер/качество), сколько по time/эффективность, и оценивают. Здесь в высоком и среднем качестве/сжатии иные более новые и эффективные стандарты проиграют AVC с треском. Отчего оно, в частности, повсеместно и используется до сих пор; и будет использоваться ещё, вследствие стабильности, времени/эффективности(размер/качество), всеобщей поддерживаемости и предсказуемости. Ещё следует помнить, что, скажем, CRF 24 у libvpx и libx264 — это ни разу не одинаковые значения PSNR и SSIM и ни разу не одинаковое визуальное качество.
