Сообщества VideoLAN и FFmpeg опубликовали (http://www.jbkempf.com/blog/post/2018/First-release-of-dav1d) первый выпуск библиотеки dav1d с реализацией альтернативного свободного декодировщика формата кодирования видео AV1 (https://www.opennet.ru/opennews/art.shtml?num=48345). &...Выпуск 0.1 позиционируется как первая версия, пригодная для повседневного использования. Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS) и распространяется (https://code.videolan.org/videolan/dav1d) под лицензией BSD. Реализована поддержка архитектур x86, x64, ARMv7 и ARMv8, и операционных систем Linux, Windows, macOS, Android и iOS.
Библиотека dav1d поддерживает все возможности AV1, включая расширеные виды субдискретизации (https://ru.wikipedia.org/wiki/%D0%A6%D0%... и все заявленные в спецификации параметры управления глубиной цвета (8, 10 и 12 бит). Работа библиотеки протестирована на большой коллекции файлов в формате AV1. Ключевой особенностью dav1d является ориентация на достижение максимально возможной производительности декодирования и обеспечение качественной работы в многопоточном режиме. В тестах библиотека заметно опережает штатный декодировщик libaom, предлагаемый проектом AV1.
Плюсом dav1d также является более компактная реализация: dav1d включает в 10 раз меньше кода по сравнению с libaom, а размер бинарного файла меньше в три раза. В процессе декодирования dav1d потребляет в 4 раза меньше памяти.Из последних достижений проекта отмечается добавление поддержки инструкций SSSE3 для ускорения работы на старых системах и реализация
ассемблерных оптимизаций для архитектуры ARMv8 (в однопоточном режиме libaom и dav1d на устройствах ARMv8 пока показывают примерно одинаковую производительность, но при многопоточной работе лидирует dav1d). Ведутся эксперименты по задействованию шейдеров для ускорения некоторых операций.Напомним, что видеокодек 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%.
URL: http://www.jbkempf.com/blog/post/2018/First-release-of-dav1d
Новость: https://www.opennet.ru/opennews/art.shtml?num=49763
> библиотека заметно опережает штатный декодировщик libaomСтоит уточнить что опережает оно только libaom 1.0 релизнутый при царе горохе. А текущая версия их кода - и близко не опережает текущую версию libaom, так что маркетинговый булщит в новости - засчитан.
А, еще и система сборки мезон, требует гадский пихтон. Тоже мне, сишный проект, блин. Маркетинг и хипстота во все поля.
meson сейчас майнстримная система сборки. То, что они решили использовать meson, только плюс.
Странно, а им собирается что-то кроме частей Gnome? Штука хорошая, там пыхтон как нельзя кстати, но что-то я ее не вижу во многих проектах.
Какой-то манагер в RH наслушался свеженанятых пыхтонрастмакак и принял мегарешение. Карманные проекты редхата и взяли под козырек. Сразу весь "майнстрим" и спалился, оптом.
ну вот mesa на него переползла, например
Ага, только на мезон они переползли с Autotools. ЛЮБАЯ система сборки будет лучше, чем это, конечно, они будут ее нахваливать.
если вам не нужна переносимость и линукс ваш новый стандарт - тогда да, любая другая лучше
(99% использования autotools - не по назначению, а просто неосиляторы makefile, результаты всех миллионов тестов отправляются ими в /dev/null, они все равно могли бы работать только в линуксе и только с ведром 4.19 с наираспоследними версиями всего)ну ничего, вот парень из гугляпа знает жисть - жаба для сборки единственного с++ файла - вот как надо! Главное - никогда не читать документацию, копипаста со стековерфлоу наше всьо.
Что там сейчас модно - а, точно, meson. Вот и подходящий вопрос, сейчас только имя проекта поменяю...
> meson сейчас майнстримная система сборки.Я не знаю для кого оно там майнстримное, кроме шестерок редхата и визгливых бидономакак. На лично мое мнение - может убираться откуда пришло.
> То, что они решили использовать meson, только плюс.
Скорее, характеристика авторов прожекта. Ну и с практической точки зрения - вот ты это будешь билдить, майнстримщик? А потом тестить и гонять? С багрепортами и проч? Я бы погонял что-то такое "сам по себе" - но с такими билдсистемами и гнилым маркетингом - пожалуй пешком постою.
Лучше cmake или meson и более-менее нормальная воспроизводимость сборки, чем портянки на баше для генерации make-портянок, которые фейлятся не с разрешимыми или хотя бы разумными ошибками, а с чем-то неадекватным из-за неверных аргументов cc или ld
Забавно, как же тогда ядро собирается, без cmake и meson? Или они ещё не знают, что у них всё плохо и надо брючки подвернуть?
Более того - meson еще и не умеет генерить make файлы. Только какую-то НЕХ для другой НЕХ под названием Ninja. Поэтому предлагается вкатить еще и вот это вот. С аргументом что он дескать быстрее.Особенно прикольно когда этим козыряют проекты из 5 файлов. Там конечно очень важно, 100 миллисекунд проект собирается, или целых 120. Так что вот ща нинзю побежим разучивать, дескать.
Впрочем, в чемпионате идиотии всех победил парень из гугла. Этот гений рационального мышления воткнул что-то на яве (gradle, чтоли) для билдовки программы из... (барабанная дробь!) ОДНОГО c++ файла! Народ повертел пальцем у виска и решил что gcc -O3 file.cpp значительно проще чем установка явы со всеми прибамбасами :)
> Впрочем, в чемпионате идиотии всех победил парень из гугла. Этот гений рационального мышления воткнул что-то на яве (gradle, чтоли) для билдовки программы из... (барабанная дробь!) ОДНОГО c++ файла!доставьте ссылку, пожалуйста.
> Впрочем, в чемпионате идиотии всех победил парень из гугла.В Debian не могут больше актуализировать пакет с языком программирования Scala. https://github.com/scala/scala/archive/v2.12.8.tar.gz
Архивчик занимает всего ничего: 6.5 MBА чтобы собрать стала требоваться система сборки sbt: https://www.scala-sbt.org/download.html
Архивчик sbt-1.2.7.tgz занимает... 45 MB !!!Что же нужно, чтобы собрать такую джава-энтерпрайзную систему сборки...
Ловлю фейспалмы от чтения этого треда. Жгите ещё, пацаны!
мэйкфайлы руками пишут лохи, автоконф для дедов, симейк слишком сложно, линукс ваш новый стандарт!
Тулкитодpoчеры должны страдать.
А автолулзы требуют гадский perl. А plain Makefile больше не пишут.
> А текущая версия их кода - и близко не опережает текущую версию libaomПри наличии AVX2 таки опережает, где-то в два раза. Но без AVX2 где-то в те же два раза отстаёт, SSSE3 не очень помогает.
SSE дорожка сырая недопилка. Увы и ах пока что беспоелезн на всем старше Haswell.
> При наличии AVX2 таки опережает,Пруф? А то у них прямо на сайте же и написано что отстает, потому что дескать оптимизаций еще нет. Тем временем в libaom оптимизаций навернули. В основном AVX2 и SSE4_1 для тех кто поновее и SSE2 для тех кто постарее. И немного SSSE3.
> SSSE3 не очень помогает.
Вообще это от много чего зависит. Прежде всего от кода. В ряде случаев AVX2 варианты оказываются тормознее других SSE подвидов. А иногда быстрее. А иногда примерно однофигственно. Раз на раз не приходится. В libaom несколько раз забивали на AVX2 фрагменты в нескольких местах, после того как все попытки сделать их быстрее чем уже имевшиеся варианты проваливались. Недавно как раз какой-то кусочек на AVX2 не смог SSSE3 с рядом размеров блоков уделать, хоть там что.
На сегодняшних master-ветках:$ ffmpeg -i av1-720p.webm -map 0:v -f null -
...
[libaom-av1 @ 0x5619a9a00f40] 1.0.0-1028-g78e6b2cb8
...
frame= 3745 fps= 62 q=-0.0 Lsize=N/A time=00:02:36.19 bitrate=N/A speed=2.57x$ ffmpeg -c:v libdav1d -i av1-720p.webm -map 0:v -f null -
...
[libdav1d @ 0x559e6bac2700] libdav1d 0.1.0-1-g73067e5
...
frame= 3745 fps=168 q=-0.0 Lsize=N/A time=00:02:36.19 bitrate=N/A speed= 7x
Проц — haswell.
По опыту оптимизаций можно сказать, что зачастую оптимизированный код, в котором вообще не используется AVX/SSE, оказывается быстрее или на уровне кода с использованием AVX/SSE по целому ряду причин.
Вот только лицензия BSD огорчает.
Не думал что доживу до подобных комментариев.
Отдавать свой продукт корпорастам или нет - это дело программиста.
Тебе дали свободу делать с этим все, что угодно, что не так?
Такое впечатление что разработчики VideoLAN и ffmpeg не корпорасты, а работяги, которые каждый вечер после после смены на заводе и врубают vim и кодят для души.
> Такое впечатление что разработчики VideoLAN и ffmpeg не корпорасты, а работяги, которые
> каждый вечер после после смены на заводе и врубают vim и кодят для души.А судя по бложикам и кодингу - в vlc те еще околокорпоративные фрукты. Поэтому то гнилым маркетингом размахивать лезут, то какие-то хипста-решения вот вываливают, то критиканят VP9 размахивая тем что h.264 стандарт, наплевывая на проблемы окружающих с тем что он запатентован и с тем что полпланеты доят, так что возникает ощущение что ребятки порой вообще интересы своих работодателей продавливают, а vlc - так, побочный продукт, чтоли.
Выбор цвета столбцов в гистограмме - уровень бог
Синий явно лишний, почему бы не сделать его каким-нибудь приятным, например зеленым? ))
Почему бы вам обоим мониторы не подстроить? Ну, или если не поможет - к окулисту не сходить?
Стало страшно смотреть в твой подстроенный монитор.
> Ведутся эксперименты по задействованию шейдеров для ускорения некоторых операций.Всегда было интересно, почему не сделать кодер/декодер полностью на чём-то вроде OpenCL/Vulkan. Проприетарные и/или платные реализации есть, а вот в опенсорсе реализаций не встречал. Тем более, что AV1 - типа кодек будущего и я не вижу препятствий сделать полноценную реализацию на том же Vulkane.
>я не вижу препятствий сделать полноценную реализацию на том же Vulkane.Сделай. Или заставь других более убедитильными доводами.
Потому что на GPU нетривиально написать производительный код, в котором много зависимостей по данным. Ну или когда на каждый пиксель надо читать много других пикселей. Проприетарные энкодеры (если речь про NVENC), и те, для которых есть опенсорсные драйвера (Intel VAAPI, AMD VCE) - это отдельный аппаратный блок с весьма ограниченными возможностями программирования.
Даже невозможно. Производительность окажется ограниченной моделью обработки.
(имея в виду, что GPU это паралл.-выч. оборудование по модели с общей памятью )
Приколу ради запускал opencl реализацию перекодирования фильмов в mp4 для ffmpeg.
Так софтварная на 1800 рязане обгоняет, почему-то OpenCl для RX 560 (хотя последний и загружен на 6-7%). Долго думал...
"Эталонный вариант", если можно так выразится не делается с привязкой к сторонним технологиях по причине дальновидности. Т.к. AV1 - "типа кодек будущего", то соответственно нацелен на встраивание в оборудование для широкого потребления: телевизоры, тв-приставки, спутниковые тюнеры, где нет OpenCL/Vulkan.
Сейчас в каждом новом SOC включая бюджетные есть OpenCL/Vulkan. Через пару лет чипы без оного придется поискать в дикой природе.
> Сейчас в каждом новом SOC включая бюджетные есть OpenCL/Vulkan.Таки не в каждом. В половину дешевых чипов до сих пор мали галимый пихают. Потому что лицензировали при царе горохе, что-то новое лицензировать жаба давит, а андроид кой-как с GL ES все же работает - ну и оки.
> Всегда было интересно, почему не сделать кодер/декодер полностью на чём-то вроде OpenCL/Vulkan.Ну вот представь себе, есть у тебя грейдер. Он может тонну грунта за раз своротить, мощная штука. Но вот ворочается и ездит он все же медленно. И пока он своим ходом доползет до места назначения... поэтому его и грузят на тягач.
У GPU довольно паршиво с flow control и всем что не есть массово параллельный счет оптом - CPU общего назначения из них никакие. Ну а сложный кодек - не состоит только из SIMD вычислений, там полно ветвлений по условиям и проч, что для GPU не сказать что удобно :)
> Проприетарные и/или платные реализации есть,
И даже они в основном выгружают счет тяжедых частей, а не так чтобы вообще целиком.
> а вот в опенсорсе реализаций не встречал.
Для VP8/9 кто-то на гитхабе пытался сделать даже.
> Тем более, что AV1 - типа кодек будущего и я не вижу препятствий сделать
> полноценную реализацию на том же Vulkane.Как бы Vulkan изначально вообще не апи для счета. Хотя compute шейдеры ему и можно скормить. Но это мигом делает прогу привязанной к "геймерским" конфигурациям и обрекает разработчиков выкусить много нового по части глюков дров GPU, на уровне игроделов. Проприетарии подслащивают себе эту горькую пилюлю барыжингом...
С libaom на райзен 2700х элекардовское 4к видео лагает дико и жрёт только 4 ядра.
> С libaom на райзен 2700х элекардовское 4к видео лагает дико и жрёт
> только 4 ядра.А он у тебя какой версии? Libaom в смысле. Если 1.0 то это тухляк невероятный по состоянию на сейчас.
aom-1.0.0.1023
он у нас во фряхе каждую неделю по два раза обновляется %)
Годная новость. Софтовый декодер будут и дальше совершенствовать, и скоро он станет юзабельным. А вот чипсеты для мобильных устройств с харварной поддержкой завезут, вероятно, не скоро.
Например, в следующем поколении Снэпдрагонов (через год).
Завезли проверяйте в 888
> Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)А что, на пихтоне и жлобоскрипте такое написать не получится? Странно. А в телевизоре^W интернете сказали, что браузер — это новая универсальная платформа для прогрессивных приложений. Даже пример показали: прогрессивное веб-приложение https://squoosh.app/ (а вот хакер, скреатививший шедевр: avatars3.githubusercontent.com/u/7694752 ).
говорят что можно, только скорость обработки никто не отменял. си побыстрее будет раза в 2, а то и в 3 в данном случае. низкоуровневые языки это вам не просто так)) хотя про питон не скажу ничего плохого. там где нужен он оч хорош. а там где нужна большая скорость обработки лучше компилируемыми. и си тут как раз в тему. можно еще дельфи вспомнить. но что то я про него в последнее время совсем мало слышу.
Да я шучу. :)Думаю, что в данном случае на С (и с ассемблерными вставками) будет быстрее на два-три порядка, а не в два-три раза. :)
> си побыстрее будет раза в 2, а то и в 3 в данном случаелол, 2-3...
js помедленнее Си будет в 2-10 раз (зависит от задачи), python3 примерно в 15-20 раз
Нихрена, JS медленнее PyPy. Уточняйте интерпретатор пожалуйста.
Вот и стал Си языком низкого уровня.... а у меня в зачетке была строчка 'Программирование на "ЯВУ"'
> Вот и стал Си языком низкого уровня.... а у меня в зачетке
> была строчка 'Программирование на "ЯВУ"'Всё, что на вид достаточно похоже на человеческий (английский) язык, это ЯВУ по ГОСТу. ))
>> Вот и стал Си языком низкого уровня.... а у меня в зачетке
>> была строчка 'Программирование на "ЯВУ"'
> Всё, что на вид достаточно похоже на человеческий (английский) язык, это ЯВУ по ГОСТу. ))Для "когнитивного диссонансу" можно вспомнить HLA
HLA (High Level Assembly, от автора "The Art of Assembly Language")
program cmdline;
#include( "stdio.hhf" );
#include( "args.hhf" );static
s:string;
begin cmdline;
// Grab the whole command line and print it:
arg.CmdLn();
stdout.put( "Command line = '", (type string eax), "'" nl );// Display the number of command line parameters:
arg.c();
stdout.put( "argc=", (type int32 eax ), nl );
// Print each of the individual command line parmeters:
mov( eax, ecx );
:)Хотя в принципе, все более-менее известные (MASM/TASM/NASM/YASM/FASM) имели кучу высокоуровневых примочек (чего только стоит макросы LOCAL var1,var2 , вместо "православных" [ebp-x], [ebp-y]).
У MASM/TASM макросы позволяли писать такое:
.while GetMessage(ADDR msg, 0,0,0)
.if !TranslateAccelerator(hwnd, hAccel, ADDR msg)
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.endif
.endwИли довольно небезызвестное "uses REG":
new_explosion proc uses edi edi from_x:dword, from_y:dword
LOCAL color:DWORD
и вроде-как-ассемблер-а-не-компилятор собирал сам весь стэкфрейм, вставлял автоматически PUSH edi/esi вначале и POP EDI/ESI; LEAVE; RETN N перед каждым (простым) ret (для которого им же генерировалось правильный N).
В общем, "Cи с регистрами".
>>> Вот и стал Си языком низкого уровня.... а у меня в зачетке
>> Всё, что на вид достаточно похоже на человеческий (английский) язык, это ЯВУ по ГОСТу. ))
> Для "когнитивного диссонансу" можно вспомнить HLA
> Хотя в принципе, все более-менее известные (MASM/TASM/NASM/YASM/FASM) имели кучу высокоуровневыхВообще любой ассемблер это содержал(-ит), имея в виду что ассемблер это автокод плюс расширения, и вот они как раз "ВУ".
Даже на ДВК или ЕС ЭВМ. ))
> Для "когнитивного диссонансу"http://flatassembler.net/docs.php?article=fasmg
What is flat assembler g?
...
This is a bare engine that by itself has no ability to recognize and encode instructions of any processor, however it has an ability to become an assembler for any CPU architecture.
...Да, Томаш созрел.
Ну и нахрена заведомую чушь нести? Всему своё место. Тут, вон, тоже на ассемблере не всё пишут, а по необходимости.Веб-приложение, кстати, тоже так сделано - UI на HTML/JS, а для тяжёлой работы использует вполне себе сишные кодеки - WebAssembly в помощь :-) Правда, работать они будут в несколько раз медленнее натива, потому что в WebAssembly поддержку SSE и многопоточность до сих пор не завезли, но там, где оно не нужно - скорость от нативно скомпилированных сей отличается меньше чем вдвое.
Никто и не сомневался что ваш вебассембли не взлетит.
Ну, он не то чтобы мой... Просто из вебовских костылей он, пожалуй, наиболее явный, логичный и последовательный. А фичи в него постепенно подвозят, и всякие SSE - штуки приятные, но нужные отнюдь не всем.
Как можно считать логичным приблуду для веба не умеющую взаимодействовать ни с сетью ни с пользователем?
Так из них никто напрямую не умел за исключением браузерных плагинов (не к ночи будь помянуты с их дырами). Но это, как минимум, шустро и бескостыльно считает и не прибито к конкретному ЯП.А бирджи для взаимодействия генерируются автоматом, тем же emscripten. И это примерно последнее место, где там возникают проблемы. Ну и планы на что-то более нативное у них есть, и судя по текущей истории - шуршат они неспешно, но планомерно, что лично мне нравится гораздо больше, чем странные шатания в собственно джаваскриптовой части.
>А что, на пихтоне и жлобоскрипте такое написать не получится?С декодирование в облаке на Амазоне - Любой каприз за Ваши деньги. :)
P.S. Этак скоро до того дойдет - чтоб фильм скачанный с Ютуба перекодировать, придется кластер поднимать.
> С декодирование в облаке на Амазоне - Любой каприз за Ваши деньги. :)А что, ты потом результат декодирования еще и прокачать сможешь? В реальном времени? Или куда декодированное девать потом предлагается?
А то весь пойнт aom - в том чтобы меньше бандвиза по сети качать. А если нежатое видео по сети гнать... зачем вам тогда aom?! :D
Имелось ввиду перекодировать, например в mp4. Для просто посмотреть не так интересно.
> А что, на пихтоне и жлобоскрипте такое написать не получится?да, я тоже не понимаю, фигня какая-то.
Ну хотя бы на яве?
> А что, на пихтоне и жлобоскрипте такое написать не получится? Странно.Эти фаготы для сборки мезоногуно затребовали. ФакЪ.
>Плюсом dav1d также является более компактная реализация: dav1d включает в 10 раз меньше кода по сравнению с libaomчерез пару годиков разбухнет до сравнимых размеров
Без энкодера таки не разбухнет наверное, но и кодировать соответственно не сможет.
Ждем конкурирующего проекта GoL1aph
> с ассемблерными вставками (NASM/GAS)Когда же они эту дурь из головы выбросят? Компиляторы давно уже починили - пользуйтесь же интринсиками наконец!
На обычном асме такие оптимизации писать может быть просто удобнее.