Компания Intel опубликовала (https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.6.0) выпуск библиотеки SVT-AV1 0.6 (https://github.com/OpenVisualCloud/SVT-AV1) (Scalable Video Technology AV1), предоставляющей альтернативные кодировщик и декодировщик для формата кодирования видео AV1, в которых задействованы присутствующие в современных CPU Intel средства аппаратного распараллеливания вычислений. Основной задачей SVT-AV1 является достижение уровня производительности, пригодного для перекодирования видео на лету и применения в сервисах, отдающих видео по запросу (VOD). Код развивается в рамках проекта OpenVisualCloud, который также разрабатывает кодировщики SVT-HEVC (https://github.com/OpenVisualCloud/SVT-HEVC) и SVT-VP9 (https://github.com/OpenVisualCloud/SVT-VP9), и распространяется (https://github.com/OpenVisualCloud/) под лицензией BSD.
Для использования SVT-AV1 необходим как минимум процессор Intel Core пятого поколения (Intel Xeon E5-v4 и более новые CPU). Для кодирования 10-битовых потоков AV1 с качеством 4K требуется 48 Гб ОЗУ, 1080p - 16 Гб, 720p - 8 Гб, 480p - 4 Гб. Из-за усложнения применяемых в AV1 алгоритмов, для кодирования данного формата требуется существенно больше ресурсов, чем для других форматов, что не позволяет применять штатный кодировщик AV1 для перекодирования в реальном времени. Например, штатный кодировщик от проекта AV1
требует (https://www.opennet.dev/opennews/art.shtml?num=48429) в 5721, 5869 и 658 раз больше вычислений по сравнению с кодировщиками x264 (профиль "main"), x264 (профиль "high") и libvpx-vp9.
Из изменений в новом выпуске SVT-AV1 отмечается добавление начальной реализации декодировщика (ранее поддерживалось только кодирование) и поддержка статического связывания библиотеки. Также реализованы новые оптимизации SIMD, поддержка децимации (https://ru.wikipedia.org/wiki/%D0%94%D0%... с использованием 2x2 фильтров, поддержка сегментации, возможность адаптивного QP-масштабирования (https://github.com/OpenVisualCloud/SVT-AV1/pull/3) и адаптивной трансформации блоков INTRA.
URL: https://github.com/OpenVisualCloud/SVT-AV1/releases
Новость: https://www.opennet.dev/opennews/art.shtml?num=51018
Intel не умеет в сжатие ОЗУ чанков?
У интел исторически все плохо с программными проектами. Иногда даже удивляешься как у них это получается.
Обычное экстенсивное развитие, давят мощностью своих процессоров, в том числе и в угоду безопасности, вместо того чтобы писать оптимизированный софт. Единственный успешный с этой точки зрения проект - это ICC, который пытается лютый говнокод скомпилировать во что-то, что интеловский процессор сможет переварить лучше конкурентов.
> это ICC, который пытается лютый говнокод скомпилировать во что-то, что интеловский процессор сможет переварить лучше конкурентовАга, помню, это который 10 лет назад отключал SIMD оптимизации, если вендор в cpuid не совпадал с Intel. Дмитрий Беседин тогда же выпустиил патч, который отключал эту проверкух.
То-то в той-же рассылке glibc частенько всплывают работники Intel с оптимизациями.
"средства аппаратного распараллеливания"
Те, что рекомендуют отключать для устранения аппаратных уязвимостей от Интел?
Скорее, имеются ввиду AVX всякие.
Штатный кодировщик на новых АМД будет работать быстрее.
свобода нового поколения - видео будет тупо не на чем перекодировать (откуда обычный пользователь возьмет 1024-ядерный проц и миллион ГБ памяти)
Будет кодировать не в реальном времени на том, что имеет. Это же обычный пользователь, а не youtube.
Подожди лет десять, и будет у тебя если не 1024 ядра, то 12 уж точно и несколько десятков гигов оперативки. Закон Мура внезапно споткнулся, упал и откинул копыта, и если раньше для преодоления таких проблем с нехваткой производительности было достаточно пары лет, то сегодня надо поболе.Но реально, это даже лучше в перспективе: пока закон Мура работал, мощности реально росли, и технику реально приходилось менять, сейчас же её менять придётся реже, и, вероятно, это будет дешевле, потому что спрос будет эластичнее. Правда надо подождать некоторое время, пока на развалах появятся б/у Ryzen'ы и рынок перестроится под новые условия.
Ох уж эти аналитики опеннета, когда речь заходит о видеокодеках :)
- "Ненужно! Пока исходники либы не опубликуют!"
- "Ненужно, пока спецификация не утверждена"
- "Ненужно, даже реалтайм декодера нет"
- "Ненужно, кодирование в 10000 медленнее x264, да выкинуть к чертям, реалтайм енкодер не появится никогда!"
- "Ненужно, аппаратных реализаций нет"
(вы находитесь здесь)
- "ненужно, в моем смартфоне 8к видео AV1 не играется!"Я понимаю, хейтить Intel это модно на открытых ресурсах - маркетинг, Meltdown/Spectre/закладки в процессорах и тп, но блин, там работают десятки тысяч сотрудников, имейте толику уважения к тем талантливым инженерам, которые шарят в оптимизации.
Тех талантливых инженеров уже лет двадцать как выгнали на мороз, заменив талантливыми маркетолухами, которые шарят в оптимизации расходов, в результате чего мы имеем 9 несовместимых между собой по сокету поколений одного и того же камня, пораженного раком^W мельдаунами/спектрами/эль-уан-ти-эфами и напичканного блоатварью ME с неясной функциональностью. Позвольте поинтересоваться, вашей криокамерой 486 рулит? Пора бы на управляющем модуле батарейку заменить.
Вообще то и для 4К H265 в 60 фпс реалтайме нужен процессор что-то типа двух! xeon platinum разогнанные до 3.5 ггц или же один Intel Xeon W-3175X на частоте 5.5 ггц.То есть AV1 в текущем состоянии не нужный для конечного потребителя трешак
Забыл добавить что они будут на своем максимуме TDP и пожиранию электричества. Какова цена такого видео на процессорах? В той же Японии где 4к телевидение популярно используют или PCIE карты с аппаратным чипом типа MB86M31 или отдельные готовые хардварные кодировщики от Fujitsu и т.п.Так что ваш Интоль да как и Омуде до этого еще как до луны пешком.
Прикол AV1 в том, что он жмёт сильнее. Ради этого только кодеки и создаются, что бы это 4к видео можно было куда-нибудь доставить не только по 10g линку...
Это в софтварных енкодерах оно показывае лучше картинку при намного меньшем битрейте, хардварные же работают по принципу лучшей скорости кодирования при среднем качестве и таком же битрейте или же идентичном качестве но уже куда выше требования к битрейту (в случае h264 хардварный запросит порядка 25 мбит за такое же качество где на софте нужно всего 6 мбит). У первых упор на качество за битрейт, у вторых на скорость кодирования в ущерб битрейту, это все равносильно и к av1, магии не существует.
Ну а эта штука будет давать битрейт поменьше, чем h264 (который тоже для реалтайма обычно хардварно жмут), а что хуже, чем софтварь - и хрен бы с ним, всё равно где-то компромисс придётся допускать.
Хотелось бы увидеть это в браузере, желательно не на движке Chromium, от засилия которого уже тошнит.
Но, боюсь, неофициальные билды chromium-vaapi это лучшее, что мы увидим в ближайшие годы на Linux
Есть подозрение и надежды, что Falcon (QupZilla) и Otter используют родные библиотеки (gstreamer?). Если так, то там значит как уж вы настроите у себя в системе. gst-vaapi или как его там, и может всё будет.
Вам что, религия не позволит отдать распаковку/отображение какому-нибудь mpv или ещё чему?
>штатный кодировщик от проекта AV1 требует в 5721, 5869 и 658 раз больше вычислений по сравнению с кодировщиками x264 (профиль "main"), x264 (профиль "high") и libvpx-vp9.А таки какой профит взамен?
? EBITDA grow for ...
Грубо говоря в 2 раза ниже требование к битрейту при идентичной картинке.
Профит - размер. Но поскольку все "низковисящие фрукты" уже сорваны, то дальнейшее повышение уровня сжатия требует всё больше и больше ресурсов.
И когда они опубликуют сорцы шейдеров для vp8? Хочу декодировать видео на видеоядре SNB.