Сообщества VideoLAN и FFmpeg опубликовали выпуск библиотеки dav1d 0.6.0 с реализацией альтернативного свободного декодировщика формата кодирования видео AV1. Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS) и распространяется под лицензией BSD. Реализована поддержка архитектур x86, x86_64, ARMv7 и ARMv8, и операционных систем Linux, Windows, macOS, Android и iOS...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52521
На рынке есть процессоры с поддержкой апараного ускорения?
На десктопах нет.
Всякое мобилко-встраиваемое есть.
А ты видел на десктопах хоть один _процессор_ с хардварными (де)кодерами видео?
В SoC есть давным давно https://ru.wikipedia.org/wiki/Intel_Quick_Sync_Video
К словам придираться такое себе
В AMDшных APUшках, кажется, что-то есть. Но я от темы далёк. Так, что-то слышал краем уха. VCE / VCN называется или как-то так.
UVD скорее, который блок HW decoder в AMD GPU. А VCE/VCN - _энкодеры_.
> А ты видел на десктопах хоть один _процессор_ с хардварными (де)кодерами видео?Чего-то с более-менее новыми интеловскими интеграшками вроде так умеет, во всяком случае VP9 в VA-API они накодили.
Да они практически все с аппаратной поддержкой: 3dnow, разные SSE, AVX, AVX512, NEON, Altivec.
3dnow уже давно нет в природе. Да и не применялся он толком на практике.
в линуксах профит был приличный, а в остальном да.
Для AV1 - только какие то ARM пока что.H.265, H.264, VP9 в тех же райзенах есть. Кажется в интелах тоже, ноутбучных, где граффика есть.
В 1030 vp9 вроде нет, только 264 и 265.
> В тестах Facebook AV1 обогнал по уровню сжатия main profile H.264 (x264) на 50.3%, high profile H.264 на 46.2%, а VP9 (libvpx-vp9) на 34.0%.А по продолжительности энкодинга он сейчас как, все еще в 100 раз дольше?
Для скорости есть rav1e
От слова "равлик", да? Неужели настолько быстро?
Все просто: чем быстрее кодирование, тем хуже сжатие. В git версии официального av1 тоже вон realtime кодирование запилили, но оно разумеется и рядом не стояло по битрейт-качество с медленными скоростями. Зато, блин, быстро (заточено на трансляцию в HW IP и софт-кодирование при видеоконференсинге).
И SVT-AV1 от интела для реалтайм кодирования
Для скорости в ущерб эффективности сжатия. Только почему-то об этом все умалчивают, и правки новостей с указанием этой мелочи не принимают.
Спасибо кэп!
Уже не вспомню кодеки, но в хроме и лисе в линукс минт открывал один и тот же стрим, смотрел информацию для сисадминов, кажется av1 и vp9, точно не помню названия, и в каком браузере какой. Так вот, в мозилле сильно квадратился и размывался стрим. В чём может быть проблема?
Проблема в Firefox.
Возможно каких опций экспериментальных понапихал. На чистом профиле бы проверил.
В том то и дело, что я фф почти не пользуюсь, так что он относительно чистый. А в хроме напихано всякого, например h264ify, без которого ютуб сильно грузил проц.
> без которого ютуб сильно грузил проц.Это чего за проц такой? А то даже древний армовский планшет VP9 спокойно в софте жрет.
i5 7500, видяха gtx1060, linux mint 19.1. То ли по очереди одно ядро в 100 долбилось, то ли что-то похожее.
Ну так установлена мусорная система не поддерживающее аппаратное ускорение из коробки. А h264ify ставит древний кодек который требует меньше ресурсов для программного декодирования
Та же фигня - чистый хром жрет проц на 100% при просмотре ютуба.
>и обеспечение качественной работы в многопоточном режимемногопоточное декодирование, карл.
На*ик NASM, только GAS!
Нафиг meson - f*ck python! :P
> Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)Судя по
> Assembly 59.1% C 39.9% Other 1.0%таки наоборот – на Assembly (NASM/GAS) с сишными вставками (С99)
Я думал, это только в новостях про rav1e пишут такие нелепые комментарии. Вы на полном серьёзе измеряете вклад языка в структуру проекта количеством строк? Из проекта можно выкинуть ассемблер, заменив его на С, и он будет работать. А если из него выкинуть С, на ассемблере его никогда не допишут.
> Я думал, это только в новостях про rav1e пишут такие нелепые комментарии.
> Вы на полном серьёзе измеряете вклад языка в структуру проекта количеством строк?Привыкайте, на опеннете это делается именно так.
Интересно, что обсуждение rav1e вы вспомнили, но в точно такой же подветке и теме (только там C заменен на Rust) не комментировали. В отличие от:
https://www.opennet.me/openforum/vsluhforumID3/119745.html#45Тем более, фомрулировка "написано на" - вполне подразумевает основной ЯП проекта. Да и при чтении "c xxx вставками" ожидается немного другое соотношение: 90:10 или хотя бы 70:30 но никак не 40:60.
И так как на асме написано 60% всего кода (по метрике гитхаба) - по моему вполне логично назвать этот язык основным языком проекта.> Из проекта можно выкинуть ассемблер, заменив его на С, и он будет работать. А если из него выкинуть С, на ассемблере его никогда не допишут.
Из проекта можно выкинуть С, заменив его на ассемблер, и он будет работать. А если из него выкинуть ассемблер, на С его никогда не допишут.
Странно, ничем не хуже вашего "аргумента" получилось, только почему-то с "доказательством" обратного *чешет репу*
На C уже написан весь функционал декодера, ассемблерные вставки можно выкинуть ничего не дописывая, от этого будет потеряна только скорость работы.Аналогично и с rav1e: ассемблерные вставки частично дублируют реализованый на rust'е функционал. А строк в них больше из-за низкого уровня языка и нескольких реализаций одних и тех же фич для разных процессоров.
> так как на асме написано 60% всего кода (по метрике гитхаба)Вы исходите из того, что 60% строчек кода написано на одном языке, а 40% на другом. На самом деле, ситуация не совсем такая.
Очень условно, 40% строк написано на C, 15% на ассемблере amd64 с поддержкой avx512, 15% на ассемблере arm9, 15% на ассемблере x86 с SSE3, и т.п.
Но даже это не важно, код на Си всё равно тут основной, даже если бы по числу строк он не был бы на первом месте.> Из проекта можно выкинуть С, заменив его на ассемблер, и он будет работать. А если из него выкинуть ассемблер, на С его никогда не допишут
Сразу видно, что вы никогда не писали кроссплатформенную программу на C с оптимизирующими ассемблерными вставками. Сначала реализуется *весь* функционал на C, отлаживается и тестируется код.
Потом для критичных мест добавляют альтернативные ассемблерные реализации. Отдельно для каждой платформы, например, может оказаться, что для платформы A на ассемблере переписано 17 узких мест, для платформы B 15, для платформы C всего 3, а для остальных платформ ассемблерного кода не написали вовсе, так и используется только Си.
> Вы исходите из того, что 60% строчек кода написано на одном языке, а 40% на другом. На самом деле, ситуация не совсем такая.Вообще-то, мне просто хотелось посмотреть, как сильно разнятся мнения и ответы, о (по сути) одном и том же:
https://www.opennet.me/openforum/vsluhforumID3/119745.html#1 ;)
> Я думал, это только в новостях про rav1e пишут такие нелепые комментарии.Радует, что некоторые понимают нелепость этого. Но, я отмечу, тебе тоже есть куда расти над собой.
Ты понимаешь, что это спор не о сути проектов, а о смыслах слов? rav1e останется таким, какой он есть, вне зависимости от того, будем ли мы называть его проектом на C с ассемблерными вставками или проектом на ассемблере со вставками на C.
Споры о смыслах слов ведутся несколько иначе. (Конструктивные споры, по-крайней мере). Надо начать с вопроса о том, зачем вообще нам нужно классифицировать проекты по категориям "проекты на C" и "проекты на ассемблере". Когда по этому вопросу будет достигнуто соглашение, дальше всё будет довольно просто. Если же по этому вопросу не удастся придти к согласию, то всё остальное вообще бессмысленная трата времени и сотрясения воздуха. И я отмечу, что вполне возможна ситуация, когда к согласию придти не удастся: разные люди могут с разными целями классифицировать проекты на сишные и ассемблерные.
Например, я могу выделять класс проектов "ассемблерные", потому что мне важна кроссплатформенность, а ассемблер некроссплатформенен, с его портированием постоянно возникают проблемы вида "переписать заново". Или я могу выделять класс проектов "сишные" с точки зрения интероперабельности API: C'шное API минимумом усилий можно использовать из любого языка, какой бы я не выбрал. Но это ведь два _разных_ критерия классификации, их не стоит без большой нужды смешивать в рамках одной классификации. А люди постоянно так делают. Есть одна демонстрация ущербности такого подхода к составлению классификаций:
> В качестве образца, которому ни в коем случае не следует подражать, возьмём самую нелепую из всех известных классификаций — классификацию животных, приписываемую X. Борхесом китайской энциклопедии под названием «Небесная империя благодетельных знаний». На древних страницах этой энциклопедии, заверяет Борхес, написано — все животные делятся на: а) принадлежащих Императору, б) набальзамированных, в) прирученных, г) сосунков, д) сирен, е) сказочных, ж) бродячих собак, з) включённых в эту классификацию, и) бегающих как сумасшедшие, к) бесчисленных, л) нарисованных тончайшей кистью из верблюжьей шерсти, м) и прочих, н) только что разбивших кувшин, о) похожих издали на мух '...[1]
Прикинь как интересно было бы спорить о том, к какому классу принадлежит мумия слона, принадлежавшего императору -- к (a), (б), (в), (з), (и), (к), (л), (н), (о) или к какому? И я рекомендую сходить по ссылке и почитать целиком: это поможет выйти на метауровень и начать думать не о принадлежности выбранных элементов к каким-то классам, а о целях классификации и о выборе методов построения классификации, подходящих к целям.
AVIF\HEIC. Когда завезут поддержку в дистрибутивы? Без хардварных кодеков енкодер AV1 интересен только на тридриппере или 3950x. А вот с изображениями польза огромная!
В ImageMagick лет 5 как завезли.
> Без хардварных кодеков енкодер AV1 интересен только на тридриппереУпрлс? Даже на лаптопе 720p декодируется!
Сейчас бы смотреть 720р на 1440р экране с 70-80% нагрузки на ЦП.
> HEIC. Когда завезут поддержку в дистрибутивы?В Ubuntu 20.04 возможно условно работает в встроенном просмотрщике:
https://github.com/strukturag/libheif/issues/182#issuecommen...Ну и превью точно работают в Nautilus.
Так и не понял оценочный прирост производительности относительно прошлого релиза.
Сравним с 2019: https://news.ycombinator.com/item?id=19362098Шел 2020-й год... AV1 всё еще плох для реального использования по всем направлениям
1. Скорость кодирования - кошмар. Выигранное место не стоит того.
2. Куча народу не понимает, что "качество" не обязательно "высокий битрейт" и продолжает платить деньги за подписочные аккаунты ради битрейта. В этой ситуации стриминговые сайты проще продадут учётку для толстенных AVC стримов нежели даже HEVC, за который им же платить больше придётся.
3. Поддержка хардварных решений близка к нулю.
4. Пираты не просто не используют AV1 они и HEVC не используют и не будут ближайшее время.От того что AV1 свободен от патентных отчислений выигрывает кучка корпораций которая платила разным MPEG-LA. Потребитель контента этого не ощутит. Социальные сети не станут более бесплатными чем сейчас. На стриминговых сайтах цены не обвалятся.
Тут пожалуй самое страшное это всякие "тостеры и соковыжималки". Я про всякую консьюмерскую мелочь, на которой принято проигрывать файлы, хоть оно и не для этого, например консоли для игр во многом определяют форматы файлов и стримов.
Пока имеющиеся консоли этого поколения актуальны AVC никуда не исчезнет. Если в следующем поколении не появится поддержка AV1 то участь у него будет как у всех On2 кодеков. Замкнутость в мире браузера.А тем временем там вовсю изобретается VVC и пишутся новости разной степени доверия:
https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-pr...А воз и ныне там. Оно всё недоделанное и не пригодно пока еще для того чтобы вытеснить старенький AVC.
Единственное что проясняется в 2020-ом, у AV1 больше шансов чем у HEVC, раз уже его спешно собрались менять на VVC, но как замена AVC... нет на это потребуются долгие-долгие годы.
Качество равно высокий битрейт. Просто хорошее качество равно очень высокий битрейт, а высокий битрейт сам по себе не гарантирует качество никак. При равном битрейте программный x265 даёт картинку раза в 3 лучше программного x264, даже с выкрученными на качество твикалками. У меня есть стойкое подозрение, что повсеместно используются аппаратные энкодеры, и вот они в случае с avc гонят совершенно мусорную картинку. Аппаратные энкодеры hevc на много порядков более совершенны, и говорят, что av1 может быть ещё лучше (мол, операции не реализуемые эффективно в железе там не нужны будут).
> У меня есть стойкое подозрение, что повсеместно используются аппаратные энкодеры, и вот они в случае с avc гонят совершенно мусорную картинку. Аппаратные энкодеры hevc на много порядков более совершенны, и говорят, что av1 может быть ещё лучше (мол, операции не реализуемые эффективно в железе там не нужны будут).Обычно такие подзрения можно развеять вот этой программой. Очень хороший проект, рекомендую.
Через нее вы увидите параметры потока и что его сделало, редко кто-то лезет руками выковыривать оттуда метаданные. И вот по моему опыту в самых говняных энкодах будет на писано, что они сделаны через Handbrake.
Этот проект облюбовали те люди, которым лишь бы закодировать и те которые совсем не опытные и даже праметров энкодера не знают. С того же nvenc файлы будут просто большими да и аппаратныхенкодеров нету вроде всяких hi10p профилей. Одни main повсюду.> Качество равно высокий битрейт. Просто хорошее качество равно очень высокий битрейт, а высокий битрейт сам по себе не гарантирует качество никак.
Ага, а теперь объясните это глупому зрителю. Который устраивает воийны с тем же кранчироллом:
https://www.reddit.com/r/SubredditDrama/comments/5ywfph/rani.../А когда прибегают глупые псевдоэксперты сравнивая видео покадрово скриншотами? А потом устривают бойкоты и непродливают подписки?
Всё потому что кто-то скаяал поток через ffmpeg переложил из TS в MKV и увидел в медиаинфо параметры энкодера x264, да-да именно его.> При равном битрейте программный x265 даёт картинку раза в 3 лучше программного x264, даже с выкрученными на качество твикалками.
Везет вам... у меня через этот недоделанный кусок глюкалова получалось получить выигрыш в районе 5-10% к размеру файла с увеличением времени кодирования в 2 раза...
Просто как и многие вменяемые люди, умеющие читать чертову документацию, я не пользусь глупостями в роде ABR-2pass, потому что кодировать под одинаковый средний битрейт в 2020-м году... мы же не на диски это пишем, к чему такие точные размеры?
> Обычно такие подзрения можно развеять вот этой программой. Очень хороший проект, рекомендую.Ссылка отклеилась: https://mediaarea.net/ru/MediaInfo
>увидел в медиаинфо параметры энкодераНе, там другая история была, картинка просто резко похерела и это заметили многие. В том числе на видео которые ты только вчера смотрел нормально. Ну они решили взять пример с гугла и затыквить все файлы.
Сначала да. А потом понеслось...
> https://www.reddit.com/r/SubredditDrama/comments/5ywfph/rani...Посмотрел на обсуждаемые скриншоты и ужаснулся — не только с упавшего качества, но и с того, что было до его падения. Люди ещё и платят деньги за такое? На том же nyaa.si за торрент с такими квадратами релизеру бы плюнули в лицо.
Ну так вы еще американский Funimation не видели. Вот где жесть. Они там какие попало субтитры хардсабят и у них натурально видео на блоки разваливается. Эти криворучки еще и на видео меняют частоту кадров как попало, чтобы всё плыло...
> 4. Пираты не просто не используют AV1 они и HEVC не используют и не будут ближайшее время.AV1 уже начали использовать: https://nyaa.si/?q=av1&f=0&c=0_0
HEVC используют давно и уже почти наравне с AVC, см. там же.
Это анимешники же... у них в этой связи немножко свой мир. И это правильно, хотя бы потому что у них совершенно иные видеопоследовательности и соответственно параметры енкодера.AV1 с 39 штук на всём трекере - это считай что не используют. Они его уже больше год тестируют результаты не очень.
HEVC ни разу не на равне в HEVC идут бомжовые реенкоды для экономии места 720p - серия в 65МБ в ультра низких битрейтах и иногда рипы с BD и то не все.Я жду изменений в скорости времени кодирования. Для точности:
Если у меня есть CFQ однопроходовое на обоих кодеках и исходник скажем 1080p и у меня есть желание перекодировать в хорошем качестве, то при отсутствии визуальных отличий между двумя результатами, хотя бы даже по метрике SSIM я выбираю тот енкодер который этого добился быстрее, потому что место на дисках дешевое и оно дешевле потраченного времени процессором. Разница в несколько мегабайт не играет роли.
У AV1 с этим пока есть проблемы. x265 он тоже медленнее, но его я не желаю использовать еще и по причине того что реализация x265 мягко говоря не очень (по-правде она ужасная, в нней четверть опций не работает и еще четверть глючит). Тоже МГУ это подтверждает в последних исследованиях.
Я готов ждать время 1.5x или 2x по отношению к времени файла, но 4х.... тогда хочется купить себе процессор, который выполнит эту задачу со скоростью 2х, а они там есть в продаже?Короче ждем оптимизаций енкодеров под новые линейки процов еще.
> HEVC ни разу не на равне в HEVCHEVC ни разу не на равне c AVC
бытрофикс
> Это анимешники же... у них в этой связи немножко свой мир.Однако результатом их деятельности, энкодером x264, сейчас пользуются все.
> AV1 с 39 штук на всём трекере - это считай что не используют.
Это означает, что его начали использовать — ровно то, что было написано.
> результаты не очень.
Где это они "не очень"? Я вижу там 1080p рипы с битрейтом видеодорожки порядка 600кбит/с и без видимых артефактов, с идеально гладкими линиями. Всем предыдущим кодекам до такого как до луны.
> Я жду изменений в скорости времени кодирования.
Ну жди, лет через пять, возможно, что-нибудь и получится. Но для некоторых кодек юзабелен и сегодня: для кодирования выходящих раз в неделю серий текущей скорости libaom-av1 достаточно даже при максимальном качестве.
Есть аниме на котором без адовых замыливания и бандинга не получится. По-моему фурикури (оригинальный) из таких, хотя там sd. 1000kbps это битрейт для 480p, как ни крути.
Может получиться, если применить появившийся в AV1 шумогенератор. Правда, энкодеры пока не научились делать это автоматически.
> Где это они "не очень"? Я вижу там 1080p рипы с битрейтом видеодорожки порядка 600кбит/с и без видимых артефактов, с идеально гладкими линиями. Всем предыдущим кодекам до такого как до луны.Это всё сильно зависит от источника и от енкодера. От формата в меньшей степени.
Обилие мелких деталей, снег, пыль, то что должно быть в видео, но похоже на зернистый шум всё это приводит нынешние енкодеры AV1 в ужас. У них там оптимизация под мультипроходовое сжатие с фиксированным битрейтом и прочими закрытыми гопами для стриминга и еще оно рассчитывается (пока что, через 5 лет это как раз изменится) прежде всего для лайв-записей, не для мультиков.
Также я бы от себя не рекомендовал использовать AV1 для неанимешной цветной мультипликации старше 80-х годов. Впустую потраченное процессорное время. Да и вообще, снижение битрейта и экономия нескольких даже сотен мегабайт с современными каналами, бендвичем и ценой на диски - странное решение. Процессор дороже.
> Это означает, что его начали использовать — ровно то, что было написано.
39 это величина о-малое от общего числа раздач на том же ня, а кодек так-то не вчера появился.
> Обилие мелких деталей, снег, пыль, то что должно быть в видео, но похоже на зернистый шум всё это приводит нынешние енкодеры AV1 в ужасЭммммм, "в ужас" обилие мелких деталей приводит все энкодеры, без исключения - у них работа такая. av1 этим ничем от остальных не отличается, никак (если что - я вот прямо сейчас av1 гоняю).
> av1 этим ничем от остальных не отличается, никак (если что - я вот прямо сейчас av1 гоняю).Отличается. Попробуйте отделить шум каким-нибудь сильным шумодавом и кодировать отдельно с помощью утилиты noise_model из каталога examples в libaom.
> Короче ждем оптимизаций енкодеровav1 активно пилится: https://aomedia.googlesource.com/aom/+log/refs/heads/master
пссст, я тут по секрету скажу - именно оптимизация по скорости сейчас активно и пилится.