Разработчики из проектов VideoLAN и FFmpeg представили (http://www.jbkempf.com/blog/post/2018/Introducing-dav1d) библиотеку dav1d с реализацией нового свободного декодировщика для формата кодирования видео AV1 (https://www.opennet.dev/opennews/art.shtml?num=48345). Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS) и распространяется (https://code.videolan.org/videolan/dav1d) под лицензией BSD. Для сборки применяется инструментарий meson.
Ключевыми целями проекта является обеспечение переносимости кода для большинства существующих платформ и достижение максимально возможной производительности декодирования. По замыслу разработчиков высокая производительность программного декодировщика позволит сгладить отсутствие аппаратных механизмов ускорения, наблюдаемое на начальном этапе внедрения видеокодека AV1. Среди задач также упоминается сохранение компактности кода и корректная поддержка работы в многопоточных приложениях.
В библиотеке dav1d планируют реализовать все расширенные возможности AV1, включая все виды субдискретизации (https://ru.wikipedia.org/wiki/%D0%A6%D0%... и параметров управления глубиной цвета. Проектом также планируется создание инструментария, похожего на MFT. В настоящее время реализована поддержка архитектур x86, x64, ARMv7 и ARMv8, и операционных систем Linux, Windows, macOS, Android и iOS.
Библиотека уже готова для тестирования, но пока не пригодна для повседневного использования.
Напомним, что видеокодек AV1 (https://aomedia.googlesource.com/av1-spec/) разработан альянсом Open Media (http://www.aomedia.org/) (AOMedia), в котором представлены такие компании, как Mozilla, Google, Microsoft, Intel, ARM, NVIDIA, IBM, Cisco, Amazon, Netflix, AMD, VideoLAN, 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%.Штатный эталонный декодировщик AV1 (libaom) является исследовательским проектом и во многих областях требует улучшения и оптимизации. Разработчики VideoLAN, VLC и FFmpeg выступили с совместной инициативой по созданию нового стабильного высокопроизводительного открытого декодировщика. Консорциум Open Media одобрил это начинание и выступил спонсором проекта. Реализация получилась очень компактной: dav1d включает в 10 раз меньше кода по сравнению с libaom, а размер бинарного файла меньше в три раза. В процессе декодирования dav1d потребляет в 4 раза меньше памяти. В многопоточном режиме работы dav1d опережает libaom 1.0.0, но пока отстаёт от HEAD-ветки libaom. Данное отставание обусловлено не использованием на данном этапе развития dav1d оптимизаций на языке ассемблера.
URL: http://www.jbkempf.com/blog/post/2018/Introducing-dav1d
Новость: https://www.opennet.dev/opennews/art.shtml?num=49379
>>библиотеку dav1d с реализацией нового свободного декодировщика для формата кодирования видео AV1. Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)
>>Данное отставание обусловлено не использованием на данном этапе развития dav1d оптимизаций на языке ассемблера.Ассемблер для галочки что-ли?
Там из ассемблера пока только motion compensation.
> Ассемблер для галочки что-ли?В горячих кусках кода SIMD asm или intrinsics дают отличия по скорости от сишного кода в разы. В логе комитов libaom совершенно нормально видеть разницу раз в 15 для C vs SSE4.1 asm какой-нибудь.
> Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)
> Данное отставание обусловлено не использованием на данном этапе развития dav1d оптимизаций на языке ассемблера.Противоречие.
В оригинале "having *almost* no assembly code yet"
Проц он грузит мама дорогая
Потому что ВСЁ считается на проце? А интересно, когда появится железо с поддержкой этого формата?
и драйвера с использованием аппаратных блоков GPU/ALU в NVIDIA/AMD
С другой стороны на процессоре вентилятор тихий, а вот залезть в турбину видеокарты и сменить не выходит :)
Железо как правило поддерживает только несколько популярных профилей, в остальных случаях хорошо если там хотя бы часть вычислений получается оффлоадить.
так оно же в процессе разработки пока только, потреблястам переживать о своём процессорике пока рано.
AV1 изначально создавался с упором на сжатие, а не скорость кодирования/декодирования, он в принципе не сможет догнать h264 по скорости. Хотя, надеюсь, со временем он станет юзабельным с программным декодирование (на последних процессорах по крайней мере).
Больше того - он создавался как конкурент и следующее поколениепосле h.265, который сам не быстр
Из бюджеток amlogic arm выпелен ваш h265.
Вообще не "наш" ни разу. Сдохнуть ему побыстрее всместе с мпеглой, м долгой жизни AV1
Amlogic чипы в медиаплеерах уже умеют использовать аппаратно ваш av1, а вот h264 и h265 выпелен из-за дороговизны отчислений.
Are you serious? Есть пруфы? Ладно там h265, потерпим, но кому нужен медиаплеер без поддержки h264? Зачем компании делать продукт, который заведомо неконкурентоспособен? Скорее всего просто попалась конкретная железка, в которой h264 сломан.
Нужен медиаплеер ... под контент. А обладатели контента, хоть тот же гугл с ютубом, внезапно h.265 на этом самом вертели. Потому что не собираются никакие роялти MPEG LA платить, за сам факт того что видео в сеть грузят.
>В многопоточном режиме работы dav1d опережает libaom 1.0.0, но пока отстаёт от HEAD-ветки libaomкакой интересный этот кодек, AV1. Открытый, бесплатный, свободный от патентов и все такое, но пользоваться им на практике ты не сможешь, потому что ему даже для декодирования нужны несколько ядер, что уж говорить про кодирование. А смогут - правильно, разработавшие его в порыве альтруизма ютубы с нетфликсами. Добро пожаловать в дивный новый мир.
(только не надо говорить, что вот сейчас появятся аппаратные реализации и все станет хорошо. Современные видеокарты только-только научились кодировать FullHD AVC в более-менее хреновом качестве, а тут речь идет о намного более трудной задаче на разрешениях 4K+)
Он же типа непатентованный, а значит всякие нвидии, амд и армы встроят в свои устройства аппаратные блоки.AVC же патентованный, а значит за каждую карту эти корпорации законодателями вынуждены отчислять. То есть вкладываться в реализацию чужого кодека смысла не имеет. Тут же можно один раз вложиться и до выпуска следующего открытого рубить капусту на продаже конкурентоспособных устройств.
Или не вложиться и проиграть конкурентам.
Хотя я думаю, что новый кодек на основе автоэнкодеров не за горами.
> а значит за каждую карту эти корпорации законодателями вынуждены отчислятькак будто бы нам ТВОИХ денег при этом должно быть жалко?
да, должно быть: это МОИ деньги, которые не станут ТВОИМИ, потому что ты потратишь их на лицензионные отчисления.
> да, должно быть: это МОИ деньги, которые не станут ТВОИМИ, потому что
> ты потратишь их на лицензионные отчисления.Вот такая вот фиговая у него корпорация. Даже жадничать нормально не умеет.
в нвидию верю, амд, ну, может в скором времени выкатит, а вот пока армы запият, да пока всё это попадёт в телефоны, да в телеприставки, да в синглборды ихнте... Ой мама...Опять же удручает то, что с каждым таким новым форматом наше железо (вполне мощное на текущий момент) превращается в тыкву. Пример - смотрел недавно ролик от 8bit-guy, шде он пытался раскочегарить какой-то мак, ещё совсем недавно топовый. Так вот, всё кроме видео там летает. И именно видео (даже 720p h264 с трудом тянет) делает эту железяку бессмысленной для домашного использования.
В консорциум входят Google с Apple. Не думаю, что вопрос аппаратной поддержки кодека в телефонах сильно задержится.
Гугл не может впихнуть в армовские процессоры поддержку кодека. Да и сам кодек, насколько я понял. гораздо более требователен к ресурсам, много считать надо. Армовские графические процессоры до сих пор поддержку 4к имеют только на бумаге, ставя колом любой андроид и линукс колом. В телефонах уже тепловыми трубками температуру сбрасывают. Что дальше, вентиляторы в телефон вставлять? :) А тут откуда-то ещё мощи взять надо. Это не энвидия, взял пару модулей накинул, места куча, пару ватт в требования накинул. Тут всё кроме самого проца упирается всё в размеры и температуру.
>> Что дальше, вентиляторы в телефон вставлять? :)да ну... жидкость или фреонку сразу :D
ну не знаю про ARM и 4K. Odroid C2 (ARM Mali™-450 MP3 GPU). Телика 4К нет. Но так даже по-моему еще тяжелее, там как приходится масштабировать в FullHD. Нагрузка на CPU возросла. Около 20% на каждом из 4-х ядер. Вроде тянет норм. А вот на i5-3550 все гораздо печальнее.
mali 2017/2018 годов выпуска умеет в 4к. Для Intel Quick Sync нужен минимум KabyLake Intel 7xxx процессоры для 4к.
>Армовские графические процессоры до сих пор поддержку 4к имеют только на бумагеА китайцы уже второй год продают ТВ-приставки на обновлённых 4×Сortex-A7 + Mali-400 чипсетах с аппаратным декодированием 4К, в т.ч. HEVC (Allwinner H3, например), и даже не знают, что у них там всё плохо.
У всех этих приставок поддерживается только такая-то комбинация кодека и всего что унутре. Шаг вправо-шаг влево и ты смотришь на слайдшоу. Это разве поддержка? Так, для галочки.
В какой консорциум входит Apple?)
Точнее, в альянс - вот в этот самый, Open Media,этот кодек продвигающий. Можете на их сайте на страничке Members глянуть.
> в нвидию верю, амд, ну, может в скором времени выкатит, а вот пока армы запият, да пока всё это попадёт в телефоны, да в телеприставки, да в синглборды ихнте...Ну посмотри как внедрялись VP9 и h265 в железки и подумай.
> А смогут - правильно, разработавшие его в порыве альтруизма ютубы с нетфликсами.ну вот мы вам еще и декодер проспонсировали, чем вы недовольны?
самостоятельно закодировать - таки да, не сможете, ну, точнее, сможете к пенсии, ее вам снова отодвинули, чтоб времени точно хватило.
И наш ценный контент любители тырить не будут. Его, правда, во все времена тырили профессионалы (у которых нет проблем с мощностями для кодера), но мы уже отписали победный прессрелиз и подняли цену своих ненужноакций аж на 2%
Full HD AVC видеокарты умеют уже больше 10 лет. Современные уже умеют 10-bit HEVC в 4к. Не знаю в каком вы десятилетии живёте.А то, что более новый и более качественный кодек требует больше системных ресурсов - в этом нет ничего страшного. Так было с ASP, AVC, HEVC и всеми остальными кодеками. К тому же, текущая реализация кодека далека от оптимальной. О чем, собственно, написано в статье.
> только не надо говорить, что вот сейчас появятся аппаратные реализации и все станет хорошо.Сейчас появятся аппаратные реализации и всё станет хорошо.
> Современные видеокарты только-только научились кодировать FullHD AVC в более-менее хреновом качестве, а тут речь идет о намного более трудной задаче на разрешениях 4K+.Вы бы из криокамеры периодически выглядывали. 4K@60 fps уже давно есть, все стримеры на них сидят.
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
https://en.wikipedia.org/wiki/Nvidia_NVENC
+ https://en.wikipedia.org/wiki/Unified_Video_Decoder
(но лучше тут: https://www.x.org/wiki/RadeonFeature/#index8h2 )
>Открытый, бесплатный, свободный от патентов и все такое,С этого момента подробнее пожалуйста.На сколько я слышал есть патенты, но Гугл договорился на разовую выплату.Консорциум MPEG владеет свыше 3000 патентов и некоторые вещи принципиально сейчас обойти не возможно,хотя некоторые патенты вообще по идее им выдаваться не должны были ,но опять же попробуй с ними потягаться в суде.Как я помню один из патентов который предъявлялся к иску описывал механизм индексного перемещения по файлу,без него не в одном кодеке не будет быстрой перемотки.
Компании, входящие в Open Media Group, создали общий пул патентов и договорились предоставлять всем безвозмездное неограниченное право ими пользоваться. В случае, если кто-то из участников начинает преследование в суде, то его лицензия на патенты отзывается. Так что патенты есть, но по факту пользоваться могут все и никто за лицензию платить не должен.Насколько я знаю, с действующими патентами MPEG LA этот пул не пересекается, т.к. кодек специально разрабатывался, чтобы те патенты не использовать.
Так и h.265 4к ты тоже одним ядром ну никак не вытянешь, а если там профиль немного не стандартный то железо тебе ничего не заоффлоадит.
У меня видео с парадом победы на 75 лет с рутрекера (h.265, 4к) на 4-х ядерных райзернах нормально не играет в mpv, только на 8-ми ядреном райзене, но почему то его оно грузит всего на 3 ядра.
У меня тоже 4к летало, пока я не установил Линукс. Теперь тормозит даже 720р сжатое некоторыми кодеками. 4к тормозит всегда.
Вы что-то не так делаете. 4K AVC у меня декодировался даже софтварно на старичке Sandy Bridge. Сейчас поставил проц поновее - хватает и для софтварного декодирования 4K HEVC, пример раскладки по ядрам (в сумме тут ~180%, т.е. хватило бы двух быстрых ядер):
```
PID USER VIRT RES SHR SWAP %CPU P nTH TIME PR NI S COMMAND
16584 user 3822,6m 687,7m 70,5m 13,5 1 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16585 user 3822,6m 687,7m 70,5m 13,5 5 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16583 user 3822,6m 687,7m 70,5m 13,0 8 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16587 user 3822,6m 687,7m 70,5m 13,0 1 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16593 user 3822,6m 687,7m 70,5m 13,0 2 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16594 user 3822,6m 687,7m 70,5m 12,5 5 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16582 user 3822,6m 687,7m 70,5m 12,0 7 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16586 user 3822,6m 687,7m 70,5m 12,0 10 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16588 user 3822,6m 687,7m 70,5m 11,5 4 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16589 user 3822,6m 687,7m 70,5m 10,0 1 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16590 user 3822,6m 687,7m 70,5m 10,0 4 44 0:02 20 R mpv 4K-10bit-HEVC.mkv
16591 user 3822,6m 687,7m 70,5m 9,5 4 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16592 user 3822,6m 687,7m 70,5m 9,0 3 44 0:02 20 S mpv 4K-10bit-HEVC.mkv
16560 user 3822,6m 687,7m 70,5m 3,0 9 44 0:00 20 S mpv 4K-10bit-HEVC.mkv
16570 user 3822,6m 687,7m 70,5m 1,5 0 44 0:00 20 S mpv 4K-10bit-HEVC.mkv
```
А аппаратному вообще на проц по фигу, на Geforce 1050 декодируется без проблем даже на совсем дохлом по современным меркам AMD, которому уже много лет.
У меня мобильный процессор последнего поколения - j5005. Есть 720р/1080р, которое воспроизводится без задержек, а есть 720р/1080р, которое воспроизводится покадрово. 4к всё с тормозами. На Windows всё летало, я даже не задумывался каким кодеком там что сжато.
На рутрекере есть это видео о котором я говорил.
Я вот понять не могу чего ему на 4-х ядерном не хватает.
Про аппаратное речи нет, это видео точно аппаратно не поддерживается.
Проверю. Который 70 лет? А что ему мешает аппаратно поддерживаться? Профиль 5.1, 10-ти битный HEVC 4:2:0 - так это же на уровне любого UHD Blu-ray диска, а уж они аппаратно декодируются где угодно (NVidia: 750/950 и выше, AMD: Polaris и выше, встройка Raven Ridge и выше (в теории), Intel: Kaby Lake и выше, ну и почти любой Mediatek и Qualcomm не старее трех лет). Да и netflix в таком же формате вещает.Софтварно одного ядра на 4K HEVC совершенно точно не хватит. Два - если частоты под 5 Ghz, три и выше, если современные - уже без проблем. Хотя у меня Sandy Bridge, 4 ядра @ 4.5 Ghz софтварно не мог - видимо, из-за отсутствия AVX2.
Парад в честь 70-летия Великой Победы / 70th Anniversary of the Great Victory Parad
16.58 GB
http://rutracker.org/forum/viewtopic.php?t=5028122Он даже на 1030 аппаратно не поддерживается, хз почему.
Для встройки 2200g у меня пока нет дров.
> http://rutracker.org/forum/viewtopic.php?t=5028122Да, его и проверял. Обычный 4K HEVC 5.1 профиля, легче UHD блюриков (на них битрейт выше), 12-ти битных кодирований или 4K примера от Sony по ссылке в посте ниже (где 60 fps и высокий битрейт).
> Он даже на 1030 аппаратно не поддерживается, хз почему.
Ну вообще 1030 в плане видео несколько обрезок, например там нет фиксированного блока кодирования. Пруфы: https://forums.geforce.com/default/topic/981372/geforce-basi...-/ https://developer.nvidia.com/video-encode-decode-gpu-support...
Не-обрезки начинаются с 1050.Но в данном случае, вероятно, проблема в попытке декодировать через что-нибудь старое типа vdpau. Оно просто не умеет 10-ти и 12-ти битные форматы, VP8 и VP9 и так далее. Он устарел, не поддерживается и не развивается. В случае нвидии предлагается брать декодер на базе nvdec. Проще всего проверить в ffmpeg, собранном с nvdec (там он местами называется по старому, cuda).
> Для встройки 2200g у меня пока нет дров.
По моим данным, все там должно быть нормально с декодером (и в плане аппаратно, и в плане поддержки va-api). Проверить не могу, у меня старая карточка AMD, которая 10 bit HEVC не умеет, только 8.
vo=direct3d,vaapi,gpu,vdpau,sdl,xv,x11
opengl-early-flush=no
opengl-dwmflush=windowed
opengl-glfinish
vo-direct3d-disable-shaders
hwdec=auto-copy
vd-lavc-check-hw-profile=yes
vd-lavc-dr=yes
vd-lavc-fast=yes
vd-lavc-show-all=no
vd-lavc-skiploopfilter=all
vd-lavc-threads=0
video-aspect=-1
deinterlace=yesЕсли gpu vdpau поменять местами - тоже работает, но появляется рассинхрон звука.
Лучше всего работает с gpu и отключённым деинтерлейсом, если его не выключить то нагрузка на проц ощутимо выше и дропы появляются.Видюхи меня не интересуют, мне и гт730 было много. К тому же 1050 вряд ли есть с пассивом.
nvdec требует куду, у меня её нет или я не разбирался :)
> vo=direct3d,vaapi,gpu,vdpau,sdl,xv,x11direct3d??
А vaapi-то как работает? Вывод vainfo можно? Не через libva-vdpau-driver и далее через vdpau ли??
Еще раз, на нвидии надо использовать nvdec/cuda декодер. На других - vaapi. Не надо использовать vdpau или vaapi-поверх-vdpau.
https://wiki.archlinux.org/index.php/Hardware_video_accelera...
Все на этом видео будет аппаратно декодироваться, если драйверы в порядке, просто не надо привлекать сюда vdpau. Он умер несколько лет как, никем не поддерживается, там нет текущих форматов - забудьте о нем навсегда.
> nvdec требует куду, у меня её нет или я не разбирался :)
На нвидия это сейчас единственный полноценный аппаратный декодер, остальное костыли. Хотите нвидию - берите куду. Не хотите куду - не берите нвидию, 2200g должен декодировать этот файл на чистом vaapi. Все просто :)
Проверять лучше всего на чистом ffmpeg, в 4.0+ поддерживается nvdec: http://ffmpeg.org/index.html#news
Когда заработает, уже играть через mpv, собранным со свежим ffmpeg, где это работает. И все будет ок.
дриект3д и ваапи просто фейлятся и в дело идёт то что за ними.
директ - это для венды, стараюсь делать универсальные конфиги.libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/nvidia_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exitnvdec/cuda - на фре нет, и мой интерес в том, чтобы всё таки программно тянуло, потому что AV1 ещё не скоро в железе будет, тем более в дешманском.
Почему такая не любовь к vdpau?
> Почему такая не любовь к vdpau?vdpau был в свое время разработан nvidia и ей же был заброшен в пользу nvdec (https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-N... и т.п.). Тут нет какой-то особой нелюбви, просто он устарел и не поддерживатся / развивается. А va-api, разработанный интелом получился универсальным и открытым, в итоге и на AMD картах заместили свой собственный XvBA на va-api. По этой же причине в софте (chromium уже, firefox в процессе) используют именно va-api.
В целом, можно делать что угодно, но суровая реальность такова, что ускорения 10-ти битного HEVC, а также VP8 и VP9 в vdpau на нвидии не получить. Нвидия уже года 3 как не разрабатывает vdpau, фичи добавляются только в nvdec. Так что если так уж хочется использовать нвидию, стоит брать nvdec.
В треде на форонике дополнительно поясняют, что человек, который сделал vdpau больше не работает в nvidia, и это был линукс-специфичный код. nvdec - переносимый код, общий между виндой и линуксом. Реализация его с точки зрения API также одинакова: mpv с декодером cuda работает одинаково на разных ОС - в некотором роде, это довольно круто. На предыдущих технологиях (DXVA под виндой, vaapi/vdpau/xvba под линуксом) такое не было возможно.
> На рутрекере есть это видео о котором я говорил.
> Я вот понять не могу чего ему на 4-х ядерном не хватает.Проверил. Софтварно ситуация на мощном проце ничем не отличается от UHD блюрика, расклад по top на динамичной сцене идентичен приведенному выше.
Проверил также аппаратное декодирование с geforce 1050 на старом хилом amd'шном проце - все работает, потребляет какие-то копейки (~8% проигрыватель и еще 5% остальное в системе) - меньше, чем даже соневское демонстрационное 4K 60 fps видео: https://4kmedia.org/sony-camping-in-nature-4k-demo/ (а оно потребляет порядка 12% +8% на той же системе, грузя раза в полтора больше, чем типичный 24 fps UHD блюрей).
> (только не надо говорить, что вот сейчас появятся аппаратные реализации и все станет хорошо. Современные видеокарты только-только научились кодировать FullHD AVC в более-менее хреновом качестве, а тут речь идет о намного более трудной задаче на разрешениях 4K+)Ну здрасьте приехали. Декодировать 4K AVC видеокарты умеют уже много лет, и года 3 как не запинаются даже на 10-ти битном 4K HEVC (Geforce 750, Geforce 950 например - вышли летом 2015). А современные поколения умеют даже такую экзотику, как VP9. Научатся и AV1, думаю, когда стандарт устоится. У него спецификации-то только несколько месяцев назад вышли, железо так быстро не появляется.
>>В многопоточном режиме работы dav1d опережает libaom 1.0.0, но пока отстаёт от HEAD-ветки libaom
> какой интересный этот кодек, AV1. Открытый, бесплатный, свободный от патентов и все
> такое, но пользоваться им на практике ты не сможешь, потому что
> ему даже для декодирования нужны несколько ядер, что уж говорить про
> кодирование. А смогут - правильно, разработавшие его в порыве альтруизма ютубы
> с нетфликсами.Как раз нетфликс и ютуб нормально не смогут до появления железных реализаций.
В этой новости прекрасно всё. Прям эталон OpenSource движения, каким он должен быть. И даже в репозиторий приятно сходить почитать. Полный когнитивный диссонанс после того, как потыкал палочкой в новый, молодёжный, продвинутый раст на котором сваяли gecko driver и плюхнули в https://hg.mozilla.org/mozilla-unified/file/tip/testing/geck.../ - там страх и глючный ужас.
Самое безумное - что это началось со свихнувшейся Мозиллы и присоединившегося к ним Циско. А сейчас глядишь на список участников - оторопь берёт, там вообще все значимые конторы
А можно более точных указаний на "страх и глючный ужас"? Я заглянул в рандомные .rs файлики, они написаны так, что их можно читать начиная с любого места. Все сорцы я не просматривал, но видимо в каком-то из них сокрыт "страх и ужас" -- мне очень интересно, потому что пока мне не приходилось сталкиваться с нечитабельным rust-кодом, а чтение нечитабельного кода на языке, на мой взгляд, очень важно для того, чтобы обрести экспертные навыки для работы с языком.
dav1d - ну и название!
"dav" как будто ещё одна реализация WebDAV, "1" - версия, "d" - debug.
Давид
+1. Давид (dav1d) победивший Голиафа (AV1)
Солиднее dAV1d
Не, d там чтобы быть позже присоединённым к одному известному менеджеру инициализации :)
скажи спасибо, что не systemd-av1d
Сто лет как интринсики починили в gcc, а они всё свои вложенные макросы на asm городят...
Гугл выкинул gcc из Android NDK (не хватает денег, чтобы поддерживать аж целых 2 компилятора).
Если что, интринсики есть и в шланге.Все надеятся сделать лучше, чем может компилятор. И далеко не у всех получается.
> Если что, интринсики есть и в шланге.
> Все надеятся сделать лучше, чем может компилятор. И далеко не у всех
> получается.У авторов, без сомнения, получится. Это те же люди, что писали кодировщики и декодеры для VP9, и x264.
всё правильно сделали. gcc хоть и лучше оптимизирует, но это наверстают. А вот то, что clang - это изначально кросскомпилятор - это оч хорошо, можно выкинуть то, что поставляется в ndk и использовать системный шланг из пакетов. Так я собирал su на 32битном компе, хотя ндк его не поддерживает.
Си жив, ураааа! Не зря я его начал изучать.
https://lvee.org/ru/abstracts/282
http://0x1.tv/20180824G
Че там слышно про кодировшик (coder) для AV1?
То что сейчас в ffmpeg неприменимо по временным затратам.
Ну как как. 2 года для 10 минутного ролика.
На данынй момент кодировщик есть только один - libaom. Он же используется в ffmpeg.
> На данынй момент кодировщик есть только один - libaom. Он же используется
> в ffmpeg.Это не совсем так, есть еще rav1e, https://github.com/xiph/rav1e
Они бы лучше в свой VLC добавили возможность стриминга opus и vorbis по протоколу rtsp. А то оно из lossy подлерживает только mp3 и aac.
Проверил, VLC v3.0.3. Создались профили для вещания: WebM+Opus и Ogm+Opus.
> Проверил, VLC v3.0.3. Создались профили для вещания: WebM+Opus и Ogm+Opus.А что толку от профилей, ты результат проверь, то есть можно ли получить твой стрим. Документация на сайте утверждает что не поддерживается: https://www.videolan.org/streaming-features.html
Да и практика тоже показала что не работает.
видеокарты подешевеют, так как при аппаратном встраивании av1 не нужно будет платить отчисления копирастам
Ты реально решил что кодек встроен в видеокарту? Он в драйверах взаимодействует с логикой гпу. Ну да некоторые инструкции добавили в гпу для удобства написания аппаратных кодеров/декодеров.
> Ты реально решил что кодек встроен в видеокарту?Встроен. Точнее, блоки фиксированной логики, выполняющие определенные части процесса кодирования или декодирования.
Но не определенного кодека, там нет костыля в виде единного DRM
По-вашему, поддержка H264, H265 и VC1 из видеокарт исчезнет? Как платили за них, так и будете.И потом, реализация блоков кодирования/декодирования тоже не бесплатна, так что новые ВК будут однозначно дороже. Просто *дополнительно* к стоимости кремния платить дань за патенты не надо.
Да какая там дань, за патенты на кодеки платится вроде сколько-то центов или максимум несколько долларов с устройства, 99% цены устройства едва ли зависит от них.
>за патенты на кодеки платится вроде сколько-то центов или максимум несколько долларов с устройстваАга, несколько центов, а под 100 долларов с устройства не хочешь.Такая сумма всплывала
по иску к Сони от общества защиты покупателей в США.Правда это было начало 2000 ,к защитникам обратился покупатель с вопросом почему ДВД проигрыватель в Европе стоит на 90 долларов (по курсу) дешевле чем в США.Те и ответили патентные выплаты сэр,в Европе отчеслений по програмнымм декодерами нет .
2.5 доллара за h264 с чипа + еще несколько раз за остальные форматы. Это только видеопроцессор, потом к этому добавит процент сборщик видеокарты, потом дистрибьютор, потом магазин и + налоги.
В итоге переплачивать придется гораздо больше чем несколько долларов.Если в драйверах еще программная реализация (потому что аппаратно не все умеют) есть то еще раз плати.
И не забудь что ты заплатил так же за за кодеки которые в операционную систему встроены.
Кодирует он однако со скоростью несколько кадров в час. И вряд ли это можно будет радикально улучшить, не растеряв при этом преимуществ. Так что в хозяйстве эта штука бесполезна, в отличие от старого доброго x264.
Главное чтобы декодировал быстро (хотя и в это не верится), а то что для комфортнго кодирования видео нужен Core i9 вроде норма жизни.
Это, на самом деле, не так важно.
Закодировать надо 1 раз (и кодирование отнсительно легко параллелится), а пересылать по сети и декодировать - возможно, сотни миллионов раз.
Медленность кодирования в софте это решаемая проблема уже сейчас - достаточно распараллелить это кодирование на тысячи ядер (читай виртуальных машин). А через два-три года подходящие GPU будут на фермах в ходу и проблема кодирования уйдет.
Лучше бы декодирование HEVC отоптимизировали. Столкнулся сегодня впервые в жизни с видео в этом формате (прислали с айфона, они теперь сразу в него снимают, но FullHD, не 4K), MPV проигрывает со скоростью около 0.5-2 кадра в секунду, в VLC всё непрерывно утопает в серой фигне. До этого с тормозами в видео никогда не сталкивался. Страшно подумать как будет тормозить этот AV1...
Как бы задача AV1 - убить HEVC
>Ключевыми целями проекта является обеспечение переносимости кода для большинства существующих платформ
>Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)/0
поясни, где ты увидел протворечие
Опять пишут про тесты кодека. Обогнал по качеству бла бла бла. Если тестовый материал взять специфичный можно сказать что MPEG-1 лучший кодек.