Состоялся релиз rav1e 0.5.0, кодировщика формата кодирования видео AV1. Продукт развивается сообществами Mozilla и Xiph и отличается от эталонной реализации libaom, написанной на языках C/C++, увеличением скорости кодирования и повышенным вниманием к обеспечению безопасности (эффективность сжатия пока отстаёт). Продукт написан на языке программирования Rust и распространяется под лицензией BSD. Готовые сборки подготовлены для Windows и macOS (сборки для Linux временно пропущены из-за проблем с системой непрерывной интеграции)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56123
> Продукт написан на языке программирования Rust и распространяется под лицензией BSD
> Assembly 72.2%
> Rust 27.5%Круто, ничего не скажешь.
Фанатики никогда не отличались умом, но чтоб настолько...
А быстрее он именно из-за ассемблера.
> Dependency: NASM
>
> Some x86_64-specific optimizations require NASM 2.14.02 or newer and are enabled by default.И нет бы развивать язык, улучшать, например, скорость компиляции раста, которая сейчас ни к чёрту, нет, вместо этого люди занимаются бессмысленными выкриками "ещё один проект на расте". Сами того не понимая, вы, именно вы, лишний раз демонстрируете сообщество языка, которое отнюдь не привлекает.
> Фанатики никогда не отличались умом, но чтоб настолько...это не фанатик, это QwertyReg, а то что "настолько" он почти под каждой новостью доказывает.
И за что он такую антирекламу языка устроил?
не знаю, но в ЖЖ (указан в профиле) поциент утверждает что ему за это платят
Как прозаично.Отрадно, однако, наблюдать как его корчит в муках, пока он описывает так нелюбимых линуксоидов. Видно, человек занимается нелюбимым делом, ему это не нравится. И он этого достоин.
"Большая перемена" - аттракцион невиданной жадности
Ух елки. Я как то все мимо пропускал нападки на этого чудилу. Все не мог понять, чего его так не любят...
... а потом я зашел на его "бложик". Теперь мне нужна длительная реабилитация(
Соболезную вашей тонкой душевной организации. Тяжко вам, если от чужих постиков в интернет-блоге, куда вас не приглашали, вам так плохо. Вам бы в SJW записаться, там таких ох как любят.
;-D кто то не знает термин - сарказм?))))
А по поводу приглашения, так убери ссылку, закрой дверцу то).
> А по поводу приглашения, так убери ссылку, закрой дверцу то).Точно SJW-шник. Может, мне ещё нельзя в своём доме голым ходить, потому что вам с биноклем всё видно?
Ну и да, пытаться оправдать свой жиденький обкак сарказмом - это плохо, очень плохо.
Все, я пас, ты победил ))))) Ты и впрямь болен.
Не умею я с фанатичными стручками общаться.p.s. прошу тебя, не бросай писать статьи, я благодаря тебе на юмористические сайты заходить перестал)
Сейчас бы на опеннете не любить с фанатичными стручками общаться 🤣
За блог спасибо 🙏
Да не за что, обращайся
У вас логика сломалась, почините и попробуйте снова.
А вы ожидали только умных людей в интернете?
Ну не на уровне IQ кипятильника же. Должны же быть хоть какие то пределы.
Полноте, и на уровне кипятильника, и даже ниже.
А какое отношение имеет скорость компиляции к тому что сторонний проект написан на ассемблере? Я бы ещё понял если бы предложили улучшать оптимизации в llvm, чтобы было можно писать больше кода на языке высокого уровня, но это скорее всего приведёт как раз к снижению скорости компиляции.
> А какое отношение имеет скорость компиляции к тому что сторонний проект написан на ассемблереЯ про скорость компиляции кода на раст, а не про этот конкретный проект.
> Круто, ничего не скажешь.
> Фанатики никогда не отличались умом, но чтоб настолько...
> А быстрее он именно из-за ассемблера.А еще фанатики очень любят что-то нафантазировать и тут же гордо опровергнуть.
И нет бы развивать язык, улучшать, например, скорость компиляции плюсов с шаблонами, которая сейчас ни к чёрту, нет, вместо этого люди занимаются бессмысленными выкриками "раст нинужно! Растаманы дураки!". Сами того не понимая, вы, именно вы, лишний раз демонстрируете сообщество языка, которое отнюдь не привлекает.
> фанатики очень любят что-то нафантазировать и тут же гордо опровергнуть
>
> бессмысленными выкриками "раст нинужно! Растаманы дураки!".А вы это на личном примере решили продемонстрировать?
>> фанатики очень любят что-то нафантазировать и тут же гордо опровергнуть
>>
>> бессмысленными выкриками "раст нинужно! Растаманы дураки!".
> А вы это на личном примере решили продемонстрировать?Хм, какая занятная (на самом деле - нет) попытка перевода стрелок.
Только увы - при этом цитировать свой собстенный, немного измененный:
ru.wikipedia.org/wiki/Пародия
ru.wikipedia.org/wiki/Гипербола_(риторика)
текст явно не стоило.
И даже не столько из-за ассемблера, сколько из-за
>Использование инструкций AVX2 для значительного (до 13 раз) ускорения винеровского оценивания для 16 бит на >канал. Аналогично добавлено использование SIMD-инструкций, позволившее ускорить вычисления до 7 раз в >аналогичных условиях;72.2 + 27.5 = 99.7%. А остальные 0.3%? Питон? :)
нет, Other, новый язык, убийца питона
Что именно вас удивляет? Использование ассемблерных вставок?
Внезапно без ассемблерных инструкций или intrinsic быстрый кодек не напишешь
> скорость компиляции раста, которая сейчас ни к чёртуА Rust тут ни при чем, это вопросы к линковщику. Вы C / C++ начните линковать статично, а не so'шками и точно так-же будет.
Каждый занимается тем чем хочет
> Продукт написан на языке программирования Rust
> Assembly 72.2% Rust 27.5%
Эмпатическое смущение.
Новость от QwertyReg же.
Привет мастерам фигурного цитирования:> Продукт написан на языке программирования Rust с ассемблерными вставками (72.2% - ассемблер, 27.5% - Rust)
Но это же ассемблер с вставками на Rust
В каше из топора, топор в пищу не пригодился.
Ну, за синюю изоленту!
вообще то наоборот - на ассемблере со вставками на раст
Когда в мороженом встречаются вкрапления шоколада, никто не говорит, что шоколад с вкраплениями мороженого. Так и здесь - Asm со вставками на Rust.
> Когда в мороженом встречаются вкрапления шоколада, никто не говорит, что шоколад с
> вкраплениями мороженого. Так и здесь - Asm со вставками на Rust.https://www.opennet.dev/opennews/art.shtml?num=53002
> Выпуск dav1d 0.7, декодировщика AV1 от проектов VideoLAN и FFmpeg
> Код проекта написан на языке C (C99) с ассемблерными вставками
> Assembly 76.4% C 23.1% Meson 0.5%Эталонное опеннетное "Вы нипонимаете! Это другое!"
Косяк в одной новости не отменяет косяк в другой
Ау, вы на ассемблере что-нибудь писали? Просто код сильно многословнее и вещи, которые компилятор делает автоматически, приходится делать руками. И вы считаете число строк - в других языках в строку можно записать много операций, но в ассемблере принято не больше одной (иначе слишком сложно читать).Вы сравните количество функций, например, на C и на ассемблере. Например: были две функции по 10 строк, одну переписали на ассемблере и получилось 50 строк. По сути теперь 50% на C и 50% на ассемблере, а если считать по коду, то выйдет что 1/6 на C и 5/6 на ассемблере (на самом деле нет, т.к. переписанную функцию оставят и в C-варианте для переносимости).
А еще ВНЕЗАПНО на ассемблере код дублируется для всех архитектур. В dav1d это x86_64, arm32, arm64. Т.е как минимум нужно делить объем ассемблерного кода на 3.
А еще там 100% реализации есть на C (для платформ, под которые не написан ассемблерный вариант). А на ассемблере самодостаточной реализации нет!
TL;DR: обе новости правильные и это реализации на C / Rust с ассемблерными вставками.
> Ау, вы на ассемблере что-нибудь писали?Писал.
> Вы сравните количество функций, например, на C и на ассемблере.
Я сравниваю лишь реакцию местного "прогрессивного сообщества" на одинаковую формулировку новости:
"Продукт написан на языке программирования Rust (Assembly 72.2% Rust 27.5%) - это "наглое вранье! Это ассемблер с вкраплениями раста, фу, фу, фу!"А "Проект написан на Си(23%) с ассемблерными вставками(76%)" - "Вы не понимаете! Это другое!"(с)
Про другое ты сам придумал как и фантазии про местное сообщество.
Что, правда глаза колет?
> Про другое ты сам придумал как и фантазии про местное сообщество.Фантазии, говоришь? Придумал, говоришь?
> Но это же ассемблер с вставками на Rust
> вообще то наоборот - на ассемблере со вставками на раст
> Так и здесь - Asm со вставками на Rust
> или все же на ассемблере с Rust вставками?.
> Продукт написан на ассемблере со вставками на языке Rust.
> Продукт написан на ассемблере с обёрткой на расте.
> Все уже пошутили, но всё же 72.2% - ассемблер, 27.5% - Rust
> "Так вот, Петька, смотри - у тебя вставлен ассемблер, и у меня вставлен ассемблер. Но есть нюанс!!!"
> Ах да это же ассемблер! И немного bash^W rust'а.
> Ясно, код на ассемблере со вставками ржавого.
>> Продукт написан на языке программирования Rust
> 72.2% - ассемблер
> Как называется эта религия?А теперь зайди в новость о dav1d https://www.opennet.dev/opennews/art.shtml?num=53002
и поищи аналогичные возмущенные вопли "Это не Си, это код на ассмблере со вставками!".
Ну и загугли значение "Это другое" (подсказка: "Вы не понимаете! Это другое!" – ироничное высказывание в адрес лицемеров) и можешь спокойно и неторопясь обтекать.
Rust здесь это клей, которого понадобилось не больше, чем Си.
Ну что, сынку, помог тебе современный ЯП меньше пользоваться асмом?
Наличие библиотек уменьшает количество вкрапляемого кода? Даже с ними процент раста слишком невелик. Есть фактическое количество кода и его определенный процент. Если те же функции воткнуть в код не как функции, а как код на Си, то это не будет раст, если библиотека фактически Си или С++. Обе новости неправильные. Когда идет комбайн за основу берется то, чего больше в коде. А в данных случаях это ассемблер. Ты чтобы перенести это с х86 на e2k обосрешься обосновывать что тут дескать на Си написано. Объясни это компилятору - все свои заскоки.
Не в количестве дело, а том кто кого вызывает. Как когда-то, лет 20 назад, проще было быстро сделать интерфейс проги (меню и т.п.) на VB, а вызываемый на пунктах меню код, который составлял 99% всей проги, был написанный на C++. Так и тут похоже.
Ну, думаю, раньше и не говорили, что программа написана на VB.
Сейчас если не писать продающий текст, начальница-маркетолог 5 рублей в конце месяца не выпишетДля точности наверно нужно писать:
написан на NASM-е
(с использованием инфраструктуры языка Rust)
|| (обернутом в Rust)
|| (с объединением частей посредством языка Rust)
Три строчки на Rust делают больше работы, чем сотня строчек на asm
Работы тестировщикам и маркетологам?
Аппаратного ускорения на апельсинке в LibreELEC нет = ненужно
Качество на порядки ниже чем у libaom. При этом файлы более раздутые и больше артефактов.
На каком уровне оптимизации?
оптимизация в расте?!
А вы думаете в Расте нет оптемизации?
При чем здесь раст, больная тема? Кодек имеет несколько уровней сжатия, конечно на самом слабом он будет хуже другой библиотеки у которой этот уровень выставлен на максимум
Так в том и прикол, что при равной скорости кодирования rav1e выдаёт результат хуже всех и он даже хуже чем выдаёт x265. Пока что для качества оптимален aom (пресет 4 даёт нормальное качество при не совсем долгом кодировании), для скорости можно использовать svt-av1, в нём недавно добавили пресеты, которые кодируют со скоростью x264 medium и даже x264 veryfast и при этом качество по лучше.Я сравнивал качество rav1e, svt-av1, и aom на двух скоростях, 4-5 фпс и 1 фпс (1080р видео, проц у меня ryzen 5 5600h). Просто подбирал пресеты у всех кодеров так, чтобы была такая скорость кодирования. Для обоих скоростей получается по качеству:
1) aom
2) svt-av1 с небольшим отрывом, в зависимости от контента бывает по лучше чем aom, но редко
3) rav1e с большим отрывом, совсем плохое качество
Возможно на более медленных пресетах aom и svt-av1 полностью сравняются или svt будет даже лучше, но я не вижу смысла рассматривать такие скорости, плюс svt жрёт космическое кол-во оперативки по сравнению с aom и rav1e.
rav1e был конкурентом только когда aom был версии 1.0, ну и когда 2.0 тоже +- конкурировал, а сейчас он просто дико медленный по сравнению с aom и svt-av1 да ещё и качество хуже.
Кстати, сравнивать стоит с сопоставимыми кодеками, а именно h266. Как же достали эти сравнения с avc. 20 лет назад avc это конечно был прорыв, но с тех пор 20 лет прошло. А vp9 медленнее x265-veryslow (а он очень медленный, хоть и даёт хорошее качество), не знаю, как они там сравнивали. И Vp9 артефачит жёстко, в h265 хоть нормальную картинку выдаёт кодировщик.
h266 требует денег. av1 бесплатный.
Там вроде лицензируют пакетом h266 и h265. Учитывая, что h265 сегодня везде, h266 очевидно тоже будет везде. Ну и потом, с h264 же сравнивают, а он точно также требует отчислений. Что за избирательность ещё такая? Одно мыло нам гоже, а другое совсем нет… При этом, x265 с его кристально чистой картинкой, вообще стараются не вспоминать.
> h265 сегодня вездеВ браузерах только у apple. В то время как AV1 поддерживается во всех современных браузерах.
Кто и где мутит? Не могу зайти на сайт через разные луковые страны, а через какие-то могу. Может DoS-атаки? Я заход на другие сайты проверил.
Может DoS-атака на сайт?
Нормальность картинки проверяется на низких битрейтах. Я проверял картинка MPEG-1 720x400 (720x406) 25 кадров сек. c битрейтом 3096 kbps выглядит нормально если не придиратся.Вы не берёте в ращёт, что AVC1 и VP9 используются ещё и для видео потока в реальном времени. А с такими требованиями к оборудованию для AV1, моё предположение, проще поднять битрейт если качество важно и использовать AVC1 и VP9 тем более всё, что теже самые 3096 kbps 720p 30, 50, 60 кадров сек. c AVC1 и VP9 выглядят нормально. Для какго-то видео надо от 6000 kbps и выше, но надо знать с каким качеством сжимают видео - это влияет на размер битрейта. И, AVC1 бесплатен для не комерческого использования насколько я знаю.
Нужно знать параметры куда и для чего передаются видео данные. И уже подбирать кодек. Если потоковая передача то для меня VP8,9 и H265 не подходят процессор надо менять на более мощный. А mpeg-1,2 mpeg4, AVC1 нормально с зопасом процессора кодируют 720x400 (720x406) 25 кадров сек.Информация к размышлению:
"T2 allows for greater “spectral density” as Bob Hannent pointed out. That means that in the same bandwidth T2 beats S2. However, there is more flexibility in the frequency bandwidth of satellite transmissions than in terrestrial. So while T2 can hit just over 50 Mbps in 10 MHz, an S2 transmission can use more of the spectrum and push higher.I ran DVB-S2 32-APSK in the lab with 45 MHz of bandwidth. That pushed my bitrate up over 200 Mbps. With DVB-S2X going up to 256-APSK, the same spectral bandwidth can carry over 300 Mbps. Some S2/S2X modulators can do 70 MHz bandwidths, achieving 311 Mbps with 32-APSK and close to 500 Mbps with 256-APSK. A system like that could transmit an uncompressed SD signal.
S2 channels are often 21.5 MHz, so a standard S2 32-APSK transmission can hit around twice the bitrate of the maximum T2 transmission.
The thing is, a good quality MPEG2 HD program might use 12–15 Mbps. A good quality h.264 4K program might use 32 Mbps. A good quality HEVC 4K program might use 15 Mbps. S2 and T2 can both do this easily. So you shouldn’t really notice a program quality difference. Even a decent quality 8K program encoded with HEVC is possible on both"
А mpeg-1,2 mpeg4, AVC1 нормально с зопасом процессора кодируют 720x400 (720x406) 25 кадров сек. c битрейтом 3096 kbps.
С AVC1 плавающий битрейт где-то можно и ниже 3096 kbps завист от того, что показывается на видео.
И mpeg-1,2 может быть ниже 3096 kbps завист от, что на видео. Если говорящая голова без частых резких движений подойдёт битрейт и ниже 3096.
> 720x400Это в 30 раз меньше чем надо. А учитывая, что сложность mpegов, avc и vpX явно не линейная и не логарифмическая, то на нормальных человеческих разрешениях разница будет не настолько существенна.
Вы же не думаете, что гугл не умеет считать деньги? А ютубчик все переводит именно под AV1, а не vpX.
И это я еще про hdr ничего не говорил.
Я вот о чём. Сомневаюсь, что разница будет существенно меньше в скорости ( время ) кодирования и нагрузки на процессор между MPEG и AVC1 720p 3096 kbps и AV1 720p 3096 kbps по сравнению с MPEG и AVC1 720x400 3096 kbps и AV1 720x400 3096 kbps. Проверять надо.
Естествено с одинаковой частотой кадров.
MPEG, AVC1 оба сравниваем с AV1. Не между собой MPEG и AVC1.
Нормалные разрешения это какие имеются ввиду 4K и 8K 60 кадров сек. и 384 kbps? Триста восемдесят четыре.
На низких битрейтах кодеки пытаются выжать последнее, более менее-нормальную картинку они выдают на utramegaslowplacebo. Кстати, x265, который на низкие разрешения вообще не нацелен ни разу (720 это минимально адекватное для него), выдаёт весьма хорошую картинку на 400p с средним битрейтом 300kbps. Какие-то фильмы очень хорошо даже на 200kbps выглядят, даже не скажешь, что битрейта вообще нет (артефакты можно уменьшить). Тот же x264 ниже 1000kbps на 400p уже больно смотреть, в то же время 700kbps для x265 это уже очень высокое качество без излищнего мыла.С последним я не совсем согласен с оценкой хорошего качества, 4k нормального качества для h264 это порядка 50mbps легко, fullhd до 30mbps, h265 нормальное 4к будет уже в районе 35mbps и 1080 где-то 20mbps. В режиме 10 бит, да (может быть есть смысл в 12 на более современных кодеках). Это при условии, что не используются аппаратные энкодеры, только программные. Про 8к ничего не знаю, зависит ещё и от того, как качественно энкодер с ними работает. Получается, MPEG сопоставимого качества уже не впихнуть. Но спутниковое ТВ это и не лучшее качество, лучшее качество идёт в кинотеатры и на диски в пожатом виде. Последнее время лучшее качество стали требовать от нетфликса, из-за чего он тоже стал использовать h265.
Вот только сейчас всё чаще видно 1920х1080 60 кадров с битрейтом 2000-3000kbps, а не 720x406.
Если пересчитать битрейт в зависимости от кол-ва пикселей, взяв за основу 720x406 3000kbps, то получается для 1920х1080 надо примерно в 7 раз больший битрейт - это 21000kbps, а сейчас такой битрейт не всегда есть у 4k видео (3840х2160), у 1080р такой битрейт есть только на дисках blu-ray.
Вот поэтому и придумывают новые кодеки, чтобы можно было поднять разрешение, но не поднимать битрейт.
Просто сами сравните хотя бы 720р mpeg-1 и h264 c одинаковым битрейтом 3000кбит и сразу увидите насколько mpeg-1 плох. Но конечно разница в качестве между mpeg-1 и h264 больше, чем между h264 и av1, всё таки нельзя сжимать бесконечно, поэтому прирост качества от новых кодеков замедляется.
А так же, прирост качества зависит от самого видео, если в видео такая динамика, что межкадровое предсказание мало используется или почти не используется, тогда и прирост качества от нового кодека будет заметно меньше. Например записи игр, в особенности шутеров, ставят на колени любой кодек, им нужно в 2-3 раза больше битрейта чем фильмам, но конечно же никто не даёт им больше битрейта, поэтому смотрим на мыло и кубики.
Сейчас с выходом av1, vp9 можно забыть и не вспоминать (единственное, vp9 легче декодируется). В av1 кодируется быстрее (пресет 4 в aom, быстрее чем максимальный в vp9 и на уровне x265 slower) и качество лучше, но по сравнению с x265 совсем на чуть-чуть. В vp9 однопроходный режим битрейта в принципе дичь выдаёт, двухпроходный хоть что-то вменяемое, но всё равно такое, а юзабелен только двухпроходный режим crf.
Ну а сравнивают с avc, потому-что hevc в вебе не используется (исключение apple), а vp9 не популярный и их libvpx говно.
Я считаю, что av1 - это аналог hevc, потому-что в среднем экономит только 15-20% (в зависимости от контента может ни сколько не экономить, а может экономить много) по сравнению с hevc, а так же имеет сравнимую скорость кодирования/декодирования.
А вот vvc (h266) - это кодек следующего уровня, для него заявлено 50% экономии битрейта по сравнению с hevc, а по тестам вроде 30-40% уже есть, но главное что он в разы дольше кодируется и в 2 раза дольше декодируется чем hevc. Аналогом vvc скорее всего будет av2.
Написан на Rust с ассемблерными вставками, или все же на ассемблере с Rust вставками?
Первое, т.к. каркас программы написан на Rust, а на ассемблере только альтернативные реализации функций для ускорения на подходящем железе. Количество кода тут не имеет значения, в т.ч. потому, что для ассемблера множится на количество поддерживаемых архитектур.
Смотря что сравнивать, исходный код или готовых байтах
Не нужён этот AV1, вся его сложность в поиске деталей в кадре которые можно не очень заметно убрать, сгладить, замылить, все разумные пределы сжатия закончились на h265 и vp9.
Ага, закончились, как же.При том же качестве av1 жмет в 1,5 раза сильнее лучших профайлов 264 и vp9. А на 4к и 8к - в три раза.
Сжать можно хоть до 1 Кб, вопрос в качестве
Коммент не читай, сразу пиши.__при том же качестве__
Не вопрос. Вот годный варик:
https://engineerblog.ru/algoritm-arhivatsii-babushkina/
Не жмет, а выпиливает детализацию! пусть лучше будет четкая картинка с небольшими артефактами, все сглаженное в градиенты и заливки.
В отличие от форматов предыдущих поколений, AV1 умеет сглаживать линии, из-за чего даже на низких битрейтах надписи и края объектов выглядят хорошо при любых углах к горизонту, а не только при тех, которые доступны для вращения блоков.
предскажут по одному кадру, если следующие не совпадут тем хуже для них, наверняка что-то экстремистское
лол
Так-то сложность av1 не особо больше чем у h265, сейчас уже можно при одинаковой скорости кодирования получить av1 с качеством чуть лучше чем h265.
По сути av1 - это просто аналог h265 для веба, так-как h265 не поддерживается большинством браузеров.
У av1 как раз вся фишка в этом сглаживании/убирании шума, основные детали остаются без искажений, шум убирается. Он убирает шум основываясь на нескольких кадрах, поэтому не сильно шумное и не сильно динамичное видео после перекодирования в av1 выглядит чисто, но детали остаются, бывает даже становятся чётче, сам сравнивал. Если нужно оставить шум, то это или использовать генератор шума (говорят он неплох в svt-av1), или использовать h264 с большими битрейтами, h265 тоже мылит, если сравнивать с h264. При использовании больших битрейтов нету смысла использовать av1, av1 - это для 10-15 мбит 4к видео в интернете, когда h264 разваливается на кубы и рябит, а h265 не канает, потому-что нет поддержки браузерами.
vp9 в принципе можно забыть, он во всём хуже чем av1.
> Так-то сложность av1 не особо больше чем у h265, сейчас уже можно
> при одинаковой скорости кодирования получить av1 с качеством чуть лучше чем
> h265.Не просто больше, а в десятки раз больше. На чем это сейчас можно кодировать av1 со скоростью h265? почти любая видеокарта с nvenc_hevc легко тащит 10x скорость.
> можно кодировать av1 со скоростью h265? почти любая видеокарта с nvenc_hevc
> легко тащит 10x скорость.Ага и получать качество на уровне хорошего h264 (x264 с кастом настройками).
Я видеокарты в принципе не рассматриваю, мне не нужен hevc, который по качеству как avc.
Ну а при 10х, там будет совсем плохо, у меня на максимальном пресете при 1080р - 160-180 фпс, это получается 3х, ну или 6х если 30 фпс видос, по качеству заметно хуже чем x265, по VMAF на уровне x264.
Видеокарта rtx 3060.
Сейчас бы поговорить про nvenc, который вышел в тот же год, когда вышел av1. Имею ввиду turing видеокарты, до них hevc nvenc был совсем дно.
Ну и к этому же у nvenc ещё и настроек минимум. Режим постоянного качества вообще странный какой-то в плане распределения qp, просто бахает qp с огромным шагом (например i-кадр - 15, p-кадр - 23, b-кадр 30), из-за этого качество хуже чем если кодируешь битрейтом.
По тыкал, по сравнивал, и в итоге закодировал с x265 со скоростью 1 фпс, вместо nvenc со скоростью 40 фпс, лучше качество, чем скорость, всё таки один раз закодировал и на всю жизнь. А nvenc и прочее на видяхах - это для стримов и записей, когда нужно в рилтайм кодировать.
Если кто никогда не видел ассемблер и не в курсе, то текст программы на нём получается в 5-10 раз объёмнее в строках, чем аналог на Си. Это касается инструкций общего назначения. С SIMD дело обстоит иначе: ЯВУ, как правило, в них не транслируются, применяются вставки либо и интринсики.
>>>С SIMD дело обстоит иначе: ЯВУ, как правило, в них не транслируются, применяются вставки либо и интринсики.ну уж хоть вставки-то наверняка на расте?
"ассемблерные вставки" - устойчивое словосочетание, очевидное из контекста :) потому я его и сократил до одного слова.
Тоже отмечусь, раз такая пьянка.> Продукт написан на языке программирования Rust с ассемблерными вставками (72.2% - ассемблер, 27.5% - Rust), код распространяется под лицензией BSD.
Продукт написан на ассемблере со вставками на языке Rust.
Статья написана кириллицей со вставками на русском.
> Продукт написан на языке программирования Rust с ассемблерными вставками (72.2% - ассемблерПродукт написан на ассемблере с обёрткой на расте.
>> Продукт написан на языке программирования Rust с ассемблерными вставками (72.2% - ассемблер
> Продукт написан на ассемблере с обёрткой на расте.Да, а если бы писали на Великом Си, то было бы норм!
https://www.opennet.dev/opennews/art.shtml?num=53002
> Выпуск dav1d 0.7, декодировщика AV1 от проектов VideoLAN и FFmpeg
> Код проекта написан на языке C (C99) с ассемблерными вставками
> ...
> Assembly 76.4% C 23.1% Meson 0.5%Ведь "Это другое!" (с)
Прошу прощения за флуд, но Вы как-то недорабатываете - там выше не на все комментарии "Это другое!" написали.
> Прошу прощения за флуд,Ничего страшного - когда нечего возразить по существу, остается только флудить из под "совершенно другого" анонима.
> но Вы как-то недорабатываете - там выше не на все комментарии "Это другое!" написали.
Кто сказал, что это "недоработка", а не забота об окружающей среде посредством избегания чрезмерно резкого, одномоментного выброса метана?
>> Прошу прощения за флуд,
> Ничего страшного - когда нечего возразить по существу, остается только флудить из
> под "совершенно другого" анонима.Извините, но других анонимов у меня для Вас нет (с)
>> но Вы как-то недорабатываете - там выше не на все комментарии "Это другое!" написали.
> Кто сказал, что это "недоработка", а не забота об окружающей среде посредством
> избегания чрезмерно резкого, одномоментного выброса метана?Можно было-бы ограничится одним разом, раз уже так переживаете об окружающей среде.
Все уже пошутили, но всё же>72.2% - ассемблер, 27.5% - Rust
Это смешно.
> Это смешно.Это не смешно, это театр безопасности.
Да, Раст язык безопастный, к чему ирония - непонятно.
Так почти весь код написан на ассемблере, где тут rust даст безопасность? Только в 27%.
Видно, что человек пародирует реальных растоманов, пародирует удачно. Даже слово "безопасный" с буквой 'т'.
Вообще, это вроде бы именно то, для чего раст вполне годится. Это конечно не тот раст, о котором любят рассказывать в интернет, но раст nonetheless,
Не совсем понятна, на приведённых графиках, значительная оптимизация на уровнях 1-3.
У растаманов так принято. Ну добавили в одном месте проверок, значит абсолютно безопасный. Вот и тут также.
Сейчас так модно строить графики. Привыкай. И нет, к расту это никакого отношения не имеет. Так тупо везде
>>>Продукт написан на языке программирования Rust с ассемблерными вставками (72.2% - ассемблер, 27.5% - Rust)"Так вот, Петька, смотри - у тебя вставлен ассемблер, и у меня вставлен ассемблер. Но есть нюанс!!!"
>Использование инструкций AVX2"Тебе, Петька, вставили потолще и, так сказать, с предохранением"
Ах да это же ассемблер! И немного bash^W rust'а.
Colibri поддерживает? 3/4 проекта на ассемблере как-никак
Ясно, код на ассемблере со вставками ржавого
Почему сабж в Debian до сих пор не завезли? libaom есть, dav1d есть, а это - никак... Из-за Rust?
А зачем он там нужен? Эта версия 0.5, пусть до 1.0 доживет, а там видно будет.
Сам по себе rust никакой не блокер, в debian/stable нормально живет resvg, которая на rust 94.0%
Почему бы и нет? Ну, хотя бы потому, что он неплох, похоже?
libaom и dav1d недавно обновили до актуального состояния, первый сразу с 1.0 до 3.2.0, хотя по ченджлогу давно уже надо было минимум до 2.0.2 обновить.
В https://salsa.debian.org/multimedia-team/libavif/-/blob/mast... строка> # TODO: -DAVIF_CODEC_RAV1E=ON
больше года, но даже тестового репозитория с rav1e нет, в т.ч. и на deb-multimedia.org, странно...
А для чего он вам нужен то? В данный момент rav1e безоговорочный лузер, хоть как-то он конкурировал только с aom 1.0, в основном по скорости, может конкурировал с ранним svt-av1 по качеству, а сейчас он по сравнению с ними (aom 3.2 (скоро уже 3.3 будет), svt-av1 0.9.0) просто тормоз, да ещё и без качества. Качество у него до x265 то не дотягивает и начиная с версии 0.3 почти никак не меняется, как в принципе и скорость. Как видно на графиках, скорость на медленных пресетах не увеличилась, это потому-что весь прирост скорости на быстрых пресетах в основном за счёт уменьшения качества (хоть и не большого) этих пресетов и в целом их перенастройки.
Я слежу за aom начиная с 1.0, rav1e начиная с 0.2, может даже раньше, svt-av1 начиная с 0.7.5 и могу сказать, что по сравнению с aom и svt-av1, у rav1e можно сказать нету прогресса никакого.
> Продукт написан на языке программирования Rust с ассемблерными оптимизациями (72.2% - ассемблер, 27.5% - Rust)Хахаха. Набросил так набросил. Ни один пользователь опеннета не смог пройти мимо и не отписаться об этом. Зачот!
Оранжевые клованы зачеты друг-другу ставят. Спешите видеть, же.Верните мне мой 2005 год и нормальный опеннет, а не вот это капашение собак павлова.
Очевидно что владельцам ресурса текущая ситуация нравится и всячески ими поддерживается. Видимо они от неё получают материальную выгоду.
А, ну понятно: если не банят неприятные местным экспертам новости и пользователей, значит, имеют выгоду. Ведь не может быть так, чтобы "руководству" было просто пофиг на ваше ценное мнение.
Как-раз из-за rav1e и не люблю Rust. Периодически собираю для себя ffmpeg, и чтоб включить в него этот кодек нужно дополнительно несколько гиг места для сборки этой одной-единственной библиотеки. А так как собираю на ram-диске, это достаточно критично.
Вот почему они не могли написать этот кодек как все нормальные люди на c/c++?
На с/с++ уже есть, называется av1
Все нормальные люди постепенно отказываются от C/C++. Они, следовательно, нормальные. Кто-то же должен начинать этот переход к современной цивилизации.
Тем временем си набирает популярность, а плюсы становятся всё более юзабельными и являются выбором номер 1 для любого производительного ПО. Только нормальные люди упарываются по новым никому не известным сырым языкам без какой-либо значительной кодовой базы под ними. Самые нормальные, это очевидно.
Вот пример AVC1 720p, 60 кадров, 3096 килобит. Пример не совсем удачный сцены не яркие. И куда лучше? Для себя улучшение я вижу только за щёт понижения битрейта, а качество изображения чтобы оставалось такоеже. https://uploadfiles.net/1iUN/0001.zip Меня там нет это не моё. Взято только как пример.
Для чего Гугл сделал VP9 и начал делать и продолжает деалть AV1 для того, чтобы за использование кодека не плаптить. Вроде это основная мотивация Гугл.
Ну может как не основная цель на размере файлов сэкономить.
Теперь может и основная цель уменшение размера файлов. И наче можно было и на VP9 оставатся.
Наверно всёже пример не совсем удачный лицо у парня смазывается. И возможн при ярком овещении былобы другое качество картинки.
Размазывается.
А ещё не извесно с ками настройками сжимали видео. С максимальными, средними.
> Продукт написан на языке программирования Rust
> 72.2% - ассемблерКак называется эта религия?
>> Продукт написан на языке программирования Rust
>> 72.2% - ассемблер
> Как называется эта религия?Какистократия (англ. kakistocracy от др.-греч. κάκιστος «худший») — система управления, находящаяся в ведении худших, наименее квалифицированных, или самых недобросовестных граждан.[1][2]
Термин появился ещё в XVII веке.[3] Он также употреблялся английским автором Томасом Лавом Пикоком в 1829 году, и в первые десятилетия XXI века широко используется для критики популистских правительств, возникающих в разных демократиях по всему миру. С термином «какистократия» тесно связано понятие меритоцида — целенаправленного уничтожения лучших сил в обществе.
--
И я не про растоманов, а про тех кто ассемблер в глаза не видел, но мнение своё о нём высказал.
> Assembly 72.2%
> Rust 27.5%А как же хвалёная ржавая безопасность?
Или здесь ассемблер тоже безопасный?
> Исправление ошибки, приводившей к краху кодировщика при определённых размерах видео;ой, как же так получилось. раст же супер безопасный!
>Продукт написан на языке программирования Rust с ассемблерными оптимизациями (72.2% - ассемблер, 27.5% - Rust),Но ведь это не божественный GNU assembler с синтаксисом AT&T!
>код распространяется под лицензией BSD.
То что Мозилла не любит копилефт это плохо, очень плохо.
>Готовые сборки подготовлены для Windows и macOS (сборки для Linux временно пропущены из-за проблем с системой непрерывной интеграции).
Нет ГНУ/Линукса - нет кодировщика. Всё очень просто. Windows и macOS просто не нужны.
Github не учитывает файлы arm ассемблера с директивами С препроцессора, иначе кода на ассемблере стало бы ещё больше, а кода на скриптухе для неумеющих освобождать за собой память ещё меньше