The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск dav1d 0.6, декодировщика AV1 от проектов VideoLAN и FFmpeg

11.03.2020 13:21

Сообщества VideoLAN и FFmpeg опубликовали выпуск библиотеки dav1d 0.6.0 с реализацией альтернативного свободного декодировщика формата кодирования видео AV1. Код проекта написан на языке C (C99) с ассемблерными вставками (NASM/GAS) и распространяется под лицензией BSD. Реализована поддержка архитектур x86, x86_64, ARMv7 и ARMv8, и операционных систем Linux, Windows, macOS, Android и iOS.

Библиотека dav1d поддерживает все возможности AV1, включая расширенные виды субдискретизации и все заявленные в спецификации параметры управления глубиной цвета (8, 10 и 12 бит). Работа библиотеки протестирована на большой коллекции файлов в формате AV1. Ключевой особенностью dav1d является ориентация на достижение максимально возможной производительности декодирования и обеспечение качественной работы в многопоточном режиме.

В новой версии:

  • Реализованы специфичные для архитектуры ARM64 оптимизации, охватывающие многие операции при работе с глубиной цвета в 10 и 12 бит.
  • Добавлены оптимизации на базе инструкций AVX-512 для операций prep_bilin, prep_8tap, cdef_filter и mc_avg/w_avg/mask.
  • Добавлены оптимизации на базе инструкций SSSE3 для подавления цифрового шума.
  • Добавлены оптимизации на базе инструкций AVX2 для операции msac_adapt16.
  • Устранены редко проявляющиеся расхождения в поведении с эталонным декодировщиком AV1.
  • Улучшены оптимизации операций msac, cdef и looprestoration для ARM64.
  • Улучшены оптимизации AVX2 для cdef_filter.
  • Улучшены реализации операций itxfm и cdef_filter на языке С.

Напомним, что видеокодек AV1 разработан альянсом Open Media (AOMedia), в котором представлены такие компании, как Mozilla, Google, Microsoft, Intel, ARM, NVIDIA, IBM, Cisco, Amazon, Netflix, AMD, VideoLAN, Apple, CCN и Realtek. AV1 позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия. Для всего диапазона протестированных разрешений в среднем AV1 обеспечивает тот же уровень качества при уменьшении битрейта на 13% по сравнению с VP9 и на 17% по сравнению с HEVC. На высоких битрейтах выигрыш увеличивается до 22-27% для VP9 и до 30-43% для HEVC. В тестах Facebook AV1 обогнал по уровню сжатия main profile H.264 (x264) на 50.3%, high profile H.264 на 46.2%, а VP9 (libvpx-vp9) на 34.0%.

  1. Главная ссылка к новости (https://code.videolan.org/vide...)
  2. OpenNews: Выпуск rav1e 0.3, кодировщика AV1 на языке Rust
  3. OpenNews: Десятый выпуск dav1d, декодировщика AV1 от проектов VideoLAN и FFmpeg
  4. OpenNews: Google открыл код libgav1, нового декодировщика для формата AV1
  5. OpenNews: Выпуск кодировщика видео SVT-AV1 0.6, развиваемого компанией Intel
  6. OpenNews: Увидел свет первый выпуск открытого видеокодека нового поколения AV1
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/52521-dav1d
Ключевые слова: dav1d, av1, videolan, ffmpeg
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Василий (??), 13:32, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На рынке есть процессоры с поддержкой апараного ускорения?
     
     
  • 2.2, iPony129412 (?), 13:37, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На десктопах нет.
    Всякое мобилко-встраиваемое есть.
     
     
  • 3.4, Аноним (4), 13:44, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    А ты видел на десктопах хоть один _процессор_ с хардварными (де)кодерами видео?
     
     
  • 4.5, Аноним (5), 13:49, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    В SoC есть давным давно https://ru.wikipedia.org/wiki/Intel_Quick_Sync_Video
    К словам придираться такое себе
     
  • 4.7, A.Stahl (ok), 13:52, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В AMDшных APUшках, кажется, что-то есть. Но я от темы далёк. Так, что-то слышал краем уха. VCE / VCN называется или как-то так.
     
     
  • 5.36, Аноним (36), 04:52, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    UVD скорее, который блок HW decoder в AMD GPU. А VCE/VCN - _энкодеры_.
     
  • 4.35, Аноним (36), 04:52, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А ты видел на десктопах хоть один _процессор_ с хардварными (де)кодерами видео?

    Чего-то с более-менее новыми интеловскими интеграшками вроде так умеет, во всяком случае VP9 в VA-API они накодили.

     
  • 2.6, Аноним (6), 13:50, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Да они практически все с аппаратной поддержкой: 3dnow, разные SSE, AVX, AVX512, NEON, Altivec.
     
     
  • 3.9, Аноним (9), 14:02, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    3dnow уже давно нет в природе. Да и не применялся он толком на практике.
     
     
  • 4.16, колба (?), 17:11, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    в линуксах профит был приличный, а в остальном да.
     
  • 2.22, Ivan_83 (ok), 19:24, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для AV1 - только какие то ARM пока что.

    H.265, H.264, VP9 в тех же райзенах есть. Кажется в интелах тоже, ноутбучных, где граффика есть.
    В 1030 vp9 вроде нет, только 264 и 265.

     

  • 1.3, anonismus (?), 13:41, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В тестах Facebook AV1 обогнал по уровню сжатия main profile H.264 (x264) на 50.3%, high profile H.264 на 46.2%, а VP9 (libvpx-vp9) на 34.0%.

    А по продолжительности энкодинга он сейчас как, все еще в 100 раз дольше?

     
     
  • 2.8, Аноним (9), 13:59, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для скорости есть rav1e
     
     
  • 3.10, A.Stahl (ok), 14:18, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    От слова "равлик", да? Неужели настолько быстро?
     
     
  • 4.37, Аноним (36), 04:54, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все просто: чем быстрее кодирование, тем хуже сжатие. В git версии официального av1 тоже вон realtime кодирование запилили, но оно разумеется и рядом не стояло по битрейт-качество с медленными скоростями. Зато, блин, быстро (заточено на трансляцию в HW IP и софт-кодирование при видеоконференсинге).
     
  • 3.11, Аноним (11), 15:14, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И SVT-AV1  от интела для реалтайм кодирования
     
  • 3.31, Аноним (31), 03:53, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для скорости в ущерб эффективности сжатия. Только почему-то об этом все умалчивают, и правки новостей с указанием этой мелочи не принимают.
     
     
  • 4.43, MihaNix (?), 06:30, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо кэп!
     

  • 1.12, Dnina (ok), 15:47, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Уже не вспомню кодеки, но в хроме и лисе в линукс минт открывал один и тот же стрим, смотрел информацию для сисадминов, кажется av1 и vp9, точно не помню названия, и в каком браузере какой. Так вот, в мозилле сильно квадратился и размывался стрим. В чём может быть проблема?
     
     
  • 2.13, iPony129412 (?), 16:07, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проблема в Firefox.
    Возможно каких опций экспериментальных понапихал. На чистом профиле бы проверил.
     
     
  • 3.15, Dnina (ok), 17:11, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В том то и дело, что я фф почти не пользуюсь, так что он относительно чистый. А в хроме напихано всякого, например h264ify, без которого ютуб сильно грузил проц.
     
     
  • 4.39, Аноним (36), 04:57, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > без которого ютуб сильно грузил проц.

    Это чего за проц такой? А то даже древний армовский планшет VP9 спокойно в софте жрет.

     
     
  • 5.62, Dnina (ok), 22:15, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    i5 7500, видяха gtx1060, linux mint 19.1. То ли по очереди одно ядро в 100 долбилось, то ли что-то похожее.
     
     
  • 6.65, Аноним (65), 18:03, 04/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так установлена мусорная система не поддерживающее аппаратное ускорение из коробки. А h264ify ставит древний кодек который требует меньше ресурсов для программного декодирования
     
  • 4.64, Аноним (64), 08:52, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Та же фигня - чистый хром жрет проц на 100% при просмотре ютуба.
     

  • 1.14, Аноним (14), 16:11, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >и обеспечение качественной работы в многопоточном режиме

    многопоточное декодирование, карл.

     
  • 1.17, Аноним (-), 18:31, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На*ик NASM, только GAS!
     
     
  • 2.40, Аноним (36), 04:58, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нафиг meson - f*ck python! :P
     

  • 1.23, Аноним84701 (ok), 20:44, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)

    Судя по
    > Assembly 59.1%   C 39.9%   Other 1.0%

    таки наоборот – на Assembly (NASM/GAS) с сишными вставками (С99)

     
     
  • 2.25, burjui (ok), 21:45, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я думал, это только в новостях про rav1e пишут такие нелепые комментарии. Вы на полном серьёзе измеряете вклад языка в структуру проекта количеством строк? Из проекта можно выкинуть ассемблер, заменив его на С, и он будет работать. А если из него выкинуть С, на ассемблере его никогда не допишут.
     
     
  • 3.27, Аноним84701 (ok), 22:03, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я думал, это только в новостях про rav1e пишут такие нелепые комментарии.
    > Вы на полном серьёзе измеряете вклад языка в структуру проекта количеством строк?

    Привыкайте, на опеннете это делается именно так.
    Интересно, что обсуждение rav1e вы вспомнили, но в точно такой же подветке и теме (только там C заменен на Rust) не комментировали. В отличие от:
    https://www.opennet.ru/openforum/vsluhforumID3/119745.html#45

    Тем более, фомрулировка "написано на" - вполне подразумевает основной ЯП проекта. Да и при чтении "c xxx вставками" ожидается немного другое соотношение: 90:10 или хотя бы 70:30 но никак не 40:60.
    И так как на асме написано 60% всего кода (по метрике гитхаба) - по моему вполне логично назвать этот язык основным языком проекта.

    > Из проекта можно выкинуть ассемблер, заменив его на С, и он будет работать. А если из него выкинуть С, на ассемблере его никогда не допишут.

    Из проекта можно выкинуть С, заменив его на ассемблер, и он будет работать. А если из него выкинуть ассемблер, на С его никогда не допишут.
    Странно, ничем не хуже вашего "аргумента" получилось, только почему-то с "доказательством" обратного *чешет репу*


     
     
  • 4.33, Аноним (31), 03:59, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На C уже написан весь функционал декодера, ассемблерные вставки можно выкинуть ничего не дописывая, от этого будет потеряна только скорость работы.

    Аналогично и с rav1e: ассемблерные вставки частично дублируют реализованый на rust'е функционал. А строк в них больше из-за низкого уровня языка и нескольких реализаций одних и тех же фич для разных процессоров.

     
  • 4.44, edo (ok), 06:53, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > так как на асме написано 60% всего кода (по метрике гитхаба)

    Вы исходите из того, что 60% строчек кода написано на одном языке, а 40% на другом. На самом деле, ситуация не совсем такая.
    Очень условно, 40% строк написано на C, 15% на ассемблере amd64 с поддержкой avx512, 15% на ассемблере arm9, 15% на ассемблере x86 с SSE3, и т.п.


    Но даже это не важно, код на Си всё равно тут основной, даже если бы по числу строк он не был бы на первом месте.

    > Из проекта можно выкинуть С, заменив его на ассемблер, и он будет работать. А если из него выкинуть ассемблер, на С его никогда не допишут

    Сразу видно, что вы никогда не писали кроссплатформенную программу на C с оптимизирующими ассемблерными вставками. Сначала реализуется *весь* функционал на C, отлаживается и тестируется код.
    Потом для критичных мест добавляют альтернативные ассемблерные реализации. Отдельно для каждой платформы, например, может оказаться, что для платформы A на ассемблере переписано 17 узких мест, для платформы B 15, для платформы C всего 3, а для остальных платформ ассемблерного кода не написали вовсе, так и используется только Си.

     
     
  • 5.55, Аноним84701 (ok), 13:12, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы исходите из того, что 60% строчек кода написано на одном языке, а 40% на другом. На самом деле, ситуация не совсем такая.

    Вообще-то, мне просто хотелось посмотреть, как сильно разнятся мнения и ответы, о (по сути) одном и том же:
    https://www.opennet.ru/openforum/vsluhforumID3/119745.html#1 ;)

     
  • 3.54, Ordu (ok), 13:09, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Радует, что некоторые понимают нелепость этого Но, я отмечу, тебе тоже есть куд... большой текст свёрнут, показать
     

  • 1.24, livello (?), 21:00, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    AVIF\HEIC. Когда завезут поддержку в дистрибутивы? Без хардварных кодеков енкодер AV1 интересен только на тридриппере или 3950x. А вот с изображениями польза огромная!
     
     
  • 2.32, Аноним (32), 03:53, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В ImageMagick лет 5 как завезли.
     
  • 2.41, Аноним (36), 04:59, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Без хардварных кодеков енкодер AV1 интересен только на тридриппере

    Упрлс? Даже на лаптопе 720p декодируется!

     
     
  • 3.42, Аноним (42), 05:55, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сейчас бы смотреть 720р на 1440р экране с 70-80% нагрузки на ЦП.
     
  • 2.45, iPony129412 (?), 07:59, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > HEIC. Когда завезут поддержку в дистрибутивы?

    В Ubuntu 20.04 возможно условно работает в встроенном просмотрщике:
    https://github.com/strukturag/libheif/issues/182#issuecomment-567904200

    Ну и превью точно работают в Nautilus.

     

  • 1.28, Виталий (??), 00:09, 12/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так и не понял оценочный прирост производительности относительно прошлого релиза.
     
  • 1.29, Аноним (29), 01:05, 12/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сравним с 2019 https news ycombinator com item id 19362098 Шел 2020-й год ... большой текст свёрнут, показать
     
     
  • 2.30, Аноним (32), 03:52, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Качество равно высокий битрейт. Просто хорошее качество равно очень высокий битрейт, а высокий битрейт сам по себе не гарантирует качество никак. При равном битрейте программный x265 даёт картинку раза в 3 лучше программного x264, даже с выкрученными на качество твикалками. У меня есть стойкое подозрение, что повсеместно используются аппаратные энкодеры, и вот они в случае с avc гонят совершенно мусорную картинку. Аппаратные энкодеры hevc на много порядков более совершенны, и говорят, что av1 может быть ещё лучше (мол, операции не реализуемые эффективно в железе там не нужны будут).
     
     
  • 3.48, Аноним (29), 09:26, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Обычно такие подзрения можно развеять вот этой программой Очень хороший проект,... большой текст свёрнут, показать
     
     
  • 4.49, Аноним (29), 09:33, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Обычно такие подзрения можно развеять вот этой программой. Очень хороший проект, рекомендую.

    Ссылка отклеилась: https://mediaarea.net/ru/MediaInfo

     
  • 4.50, Аноним (32), 11:01, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >увидел в медиаинфо параметры энкодера

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

     
     
  • 5.58, Аноним (29), 14:34, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сначала да. А потом понеслось...
     
  • 4.56, Аноним (31), 14:17, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > https://www.reddit.com/r/SubredditDrama/comments/5ywfph/ranime_uproar_over_vid

    Посмотрел на обсуждаемые скриншоты и ужаснулся — не только с упавшего качества, но и с того, что было до его падения. Люди ещё и платят деньги за такое? На том же nyaa.si за торрент с такими квадратами релизеру бы плюнули в лицо.

     
     
  • 5.57, Аноним (29), 14:34, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так вы еще американский Funimation не видели. Вот где жесть. Они там какие попало субтитры хардсабят и у них натурально видео на блоки разваливается. Эти криворучки еще и на видео меняют частоту кадров как попало, чтобы всё плыло...
     
  • 2.34, Аноним (31), 04:11, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > 4. Пираты не просто не используют AV1 они и HEVC не используют и не будут ближайшее время.

    AV1 уже начали использовать: https://nyaa.si/?q=av1&f=0&c=0_0
    HEVC используют давно и уже почти наравне с AVC, см. там же.

     
     
  • 3.46, Аноним (29), 09:05, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это анимешники же у них в этой связи немножко свой мир И это правильно, хотя... большой текст свёрнут, показать
     
     
  • 4.47, Аноним (29), 09:06, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > HEVC ни разу не на равне в HEVC

    HEVC ни разу не на равне c AVC
    бытрофикс

     
  • 4.51, Аноним (31), 11:37, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Это анимешники же... у них в этой связи немножко свой мир.

    Однако результатом их деятельности, энкодером x264, сейчас пользуются все.

    > AV1 с 39 штук на всём трекере - это считай что не используют.

    Это означает, что его начали использовать — ровно то, что было написано.

    > результаты не очень.

    Где это они "не очень"? Я вижу там 1080p рипы с битрейтом видеодорожки порядка 600кбит/с и без видимых артефактов, с идеально гладкими линиями. Всем предыдущим кодекам до такого как до луны.

    > Я жду изменений в скорости времени кодирования.

    Ну жди, лет через пять, возможно, что-нибудь и получится. Но для некоторых кодек юзабелен и сегодня: для кодирования выходящих раз в неделю серий текущей скорости libaom-av1 достаточно даже при максимальном качестве.

     
     
  • 5.52, Аноним (32), 11:48, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Есть аниме на котором без адовых замыливания и бандинга не получится. По-моему фурикури (оригинальный) из таких, хотя там sd. 1000kbps это битрейт для 480p, как ни крути.
     
     
  • 6.53, Аноним (31), 13:05, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Может получиться, если применить появившийся в AV1 шумогенератор. Правда, энкодеры пока не научились делать это автоматически.
     
  • 5.59, Аноним (29), 14:44, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё сильно зависит от источника и от енкодера От формата в меньшей степени ... большой текст свёрнут, показать
     
     
  • 6.61, Говнокодер (?), 17:35, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Обилие мелких деталей, снег, пыль, то что должно быть в видео, но похоже на зернистый шум всё это приводит нынешние енкодеры AV1 в ужас

    Эммммм, "в ужас" обилие мелких деталей приводит все энкодеры, без исключения - у них работа такая. av1 этим ничем от остальных не отличается, никак (если что - я вот прямо сейчас av1 гоняю).

     
     
  • 7.63, Аноним (31), 01:44, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > av1 этим ничем от остальных не отличается, никак (если что - я вот прямо сейчас av1 гоняю).

    Отличается. Попробуйте отделить шум каким-нибудь сильным шумодавом и кодировать отдельно с помощью утилиты noise_model из каталога examples в libaom.

     
  • 4.60, Говнокодер (?), 17:32, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Короче ждем оптимизаций енкодеров

    av1 активно пилится: https://aomedia.googlesource.com/aom/+log/refs/heads/master

    пссст, я тут по секрету скажу - именно оптимизация по скорости сейчас активно и пилится.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру