Доступен выпуск rav1e 0.2, высокопроизводительного кодировщика формата кодирования видео AV1, развиваемого сообществами Xiph и Mozilla. Кодировщик написан на языке Rust и отличается от эталонного кодировщика libaom значительным увеличением скорости кодирования и повышенным вниманием к обеспечению безопасности. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52067
Мне больше кодировщики на C нравятся. Rust неплох, но мне не нравятся в коде такие места unsafe extern, pub unsafe extern fn, unsafe {
есть сомнения, что в C нет явного различия межу safe и unsafe-кодом, а то, что код на C unsafe, обычно узнают уже когда программа работает и начинаются утечки памяти, segfault, и т.д.
При программировании на Rust в safe режиме ощущения не те. Поэтому всем нравится больше на С, но с ним бывают сегфолты.
Без unsafe не бывает низкоуровневых вещей ни в каком языке. Другое дело, когда этот unsafe чётко очерчен и человек понимает, где он его использует, с какой целью использует, и берёт на себя все риски. Этого сильно не хватает в C/C++ и компенсируется RAII, линтерами и прочим, но лишь частично.
Это не "компенсируется" RAII и линтерами - в плюсах это works as expected. В идиоматическом плюсовом коде всёгда видно, что safe, что - нет. Ушёл в сишные дебри - unsafe, всё очень просто.
>В идиоматическом плюсовом коде всёгда видно, что safe, что -
> нет. Ушёл в сишные дебри - unsafe, всё очень просто.Я бы посмотрел, сколько у вас ушло бы времени на то чтобы начать писать идиоматичный безопасный код без UB и других прелестей, особенно будучи новичком или средним на руку программистом... И даже этот код иногда не защищён от сюрпризов (камень в сторону разработчиков стандарта и std и других библиотек с протекающими абстракциями). Особенно это сложно в условиях, когда бОльшая часть проектов использует C++98 или того хуже (Google, насколько знаю, любит использовать подмножество C в C++), а сам язык с каждым годом становится всё сложнее, обрастая условностями и UB.
Поэтому в современых реалиях проще сделать "умный" язык, чем делать идеального программиста который мог бы использовать "глупый" язык правильным образом (Golang хорошо показывает эту тенденцию, хоть он и с GC). Сделать C++ умным в полной мере не выйдет никогда, поэтому я и сказал, что RAII, линтёры, анализаторы и всякие безопасные обёртки частично решают проблему.
Покажите плиз, как у вас в низкоуровневом коде какое-нибудь заряжание DMA транзакции может быть "заведомо safe"? :)
Тянет писать говнокод?
Когда в ffmpeg появится?
Когда ваш патч будет принят. Вы же его уже отправили?
Да ну брось ты... Это чистая попытка хипстерства в Mozilla. Они просто видят, что ребятки хипстеры с JavaScript вот и придумали себе крутой язык, а то что он теоретический и практический на нем писать невозможно и ничего никто не пишет, так это другой вопрос. Короче дохлятина это ...
Я бекенд для сайтика пишу
Тем не менее он очень популярен сейчас.И даже если на практике он не устоится, то многие идеи, которые были популяризированны растом, обязательно найдут применение в будущем
# cd /usr/ports/multimedia/ffmpeg && make install clean
[x] RAV1E AV1 encoding via librav1e
Это что же получается, FreeBSD впереди планеты всей? Даже в gentoo такой радости ещё не завезли.
А что, configure у ffmpeg запустить уже rocket science? А там уже и укажите как вам его и с чем.
> А что, configure у ffmpeg запустить уже rocket science?Судя по комментариям
>> Когда в ffmpeg появится?
>> Даже в gentoo такой радости ещё не завезли.для современного линухоида - выходит таки да.
> А там уже и укажите как вам его и с чем.
Но ставить галочку в менюшке с описанием опции таки куда проще и быстрее выйдет. Особенно для ffmpeg, у которого этих опций много-много:
ASS_DESC= Subtitles rendering via libass
AOM_DESC= AV1 video encoding/decoding via libaom
ARIBB24_DESC= ARIB text and caption decoding via libaribb24
BEIGNET_DESC= DRM/VAAPI to OpenCL mapping for i965 + Beignet
BS2B_DESC= Bauer Stereophonic-to-Binaural filter
...
VFP_DESC= Vector Floating Point instructions
VIDSTAB_DESC= Video stabilization filter
VMAF_DESC= VMAF filter via libvmaf
XAVS2_DESC= AVS2 encoding via libxavs2pkg options ffmpeg|wc -l
93Да и результат вышеупомянотого фряшного "make config" и "make install" - это готовый к употреблению пакет для пакетника, а не кастомное чудо ручной сборки.
> для современного линухоида - выходит таки да.Ну не знаю, я из git собрал себе по приколу. Чтобы свежие libaom, libvpx и еще пару либ да и сам ffmpeg потестить. А галочки в менюшке мне не требуются. К тому же я и это и либы в очень кастомные диры клал, понятия не имею как так сделать в менб с галочками.
> configure у ffmpeg запустить уже rocket science?Наоборот, скатывание на более низкий уровень, где всё приходится делать руками. Как это собранное потом обновлять вместе со всеми библиотеками? Костылять монструозный шелл-скрипт? Я лучше в scm-ебилд допишу отсутствующие зависимости и ключи configure.
> Как это собранное потом обновлять вместе со всеми библиотеками?
> Костылять монструозный шелл-скрипт?Почему монструозный то? И зачем мне обновлять вообще все библиотеки? Чтобы посмотреть как я соберу вообще все глюки на планете в первых рядах? Спасибо, что-то не хочется :)
> Я лучше в scm-ебилд допишу отсутствующие зависимости и ключи configure.
Я не рвусь перекомпилить все и вся ради процесса. В упомянутом случае меня интересовал конкретный результат - свежие версии пары-тройки либ и ffmpeg'а.
А почему не с HEVC сравнивают?
Потому что сравнивать не выгодно) HEVC этот кодек сливает по всем фронтам (и скорость, и качество картинки).
С другой стороны - удачи догнать референсный кодек av1. Он все еще медленный, но жмет чертовски круто.
Как можно сравнивать кодек с форматом?
потому что формат в 10 раз хуже чем hevc
Ровно наоборот - в AV1 придумали ряд интересных фокусов, отсутствующих в других форматах.
1) Множество референсных кадров, кодируя очередной блок кодек может выбрать наиболее подходящий. H.26x так не умеют, ограничиваясь более примитивными вариантами, которые являются частными случаями этой идеи. А это более общая реализация. Но да, при кодировании кодеку приходится изучать какой из кадров лучше всего подходит как референс для этого куска. Это требует CPU.2) CDEF - это не просто deblocking, а направленный деблокинг. Как именно его делать - кодирует энкодер, который лучше знает что было в оригинале. Науке неизвестно почему до такого фокуса не додумались раньше, но это сильно понижает назойливость артефактов сжатия: теперь границы между блоками невозможно спалить даже при сильном сжатии, а артефакты из-за того что фильтр испортил оригинальный контент вознимают намного меньше - потому что энкодер еще при кодировании знал как это должно выглядеть и подсказал декодеру. H.26x так не умеют, это перцы из DAALA придумали. Еще не lapped transform, но кое-что общее есть: тоже о границах блоков и как сделать чтобы квадратиков не было.
Чем вообще плох HEVC?
надо sysvinit на rust переписать и вернуть в debian
Ну так перепиши
Поттеринг объявит rust вне закона выкинет из debian.
А может интегрирует в systemd.
systemdrust звучит как ругательство
Внезапно, кто то недавно решил переписать systemd (базовую часть) на раст https://github.com/KillingSpark/rustysd
https://github.com/riboseinc/riffol
Как его собрать не пуская cargo в интернет?
cargo vendor
Благодарю. В версии, которую я смотрел, не было ни этого, ни опции --offline, т.е. онлайн-режим сборки был безальтернативен.
> Формат AV1 заметно опережает x264 и libvpx-vp9 по уровню сжатияОпять этот бред. В прошлый раз ведь уже комментировали: https://www.opennet.me/openforum/vsluhforumID3/118965.html#87
В прошлый раз всем было пох, и видимо в этот тоже. Если какой-то вброс не работает, то многократные попытки вбросить его ничего не изменят. Попробуй переписать как-нибудь, если у тебя нет фактов, то попробуй хотя бы за эмоции людей зацепить.
Более того - можно просто взять кодеки, пожать самому и посмотреть на результат.Вот чесслово, собрать распоследний ffmpeg с какими там кому нравится либами, даже распоследними, в пределах сил человеческих. И таки VP9 ну вообще никак не устоит vs его же поздней инкарнации в виде AV1. А x264 даже и на более приличном битрейте выглядит мутной фигней, если попытаться приблизиться к битрейтам на которых AV1 оперирует.
Для сборки firefox-70.0.1 требуется 8G на диске.
Для сборки rust-1.40.0 требуется 9G на диске.
А для сборки firefox нужен rust! :-)
> А для сборки firefox нужен rust! :-)А для сборки rust-1.37.0 надо было 7G :-)
TinyC требовал 32 кб памяти =) Жаль что скатился проект
Почему скатился? Он просто не развивается. Идеален в своей простоте, как шарик =)
> и повышенным вниманием к обеспечению безопасностиЭто они так хитро обозвали управление памятью программ на Rust?
Просто мне скажите это переписывание на раст поможет устранить ступенчатые артефакты в тёмных сценах на градиентах? Нет конечно. Сделайте нормальное сжатие без градиентов и с нормальным движением маленьких не контрастных объектов. Наблюдать как желе из ступенек движется по экрану мне уже надоело.
А может, это не кодек виноват, а цветовой формат с limited range, в котором плавные тёмные градиенты в принципе невозможны? Предлагаю попробовать full (pc) range или цветность 10 бит на канал.
> Просто мне скажите это переписывание на раст поможет устранить ступенчатые артефакты в
> тёмных сценах на градиентах? Нет конечно. Сделайте нормальное сжатие без градиентов
> и с нормальным движением маленьких не контрастных объектов.Ну так это...
1) Юзайте bit depth под стать контенту. Если у вас офигенные градиенты, как насчет 10 или 12 битов?
2) Цветовое пространство правильное? PCшный контент например неважно выглядит в YUV, ему RGB надо.
3) Возможно дело в управлении битрейтом? Не знаю как в сабже, а в референсном может иметь смысл например CRF + ограничение битрейта сверху. Гугл для себя такой режим использует - и на это есть причины.
> в референсном может иметь смысл например CRF + ограничение битрейта сверхуВ рефренсном энкодере нет никакого CRF, это вообще термин исключительно кодеков x264 и x265.
Описанное называется режимом constrained quality.Путаницу ввёл ffmpeg, использовав ключ -crf для управления аналогичным функционалом отличных от x26* кодеков.
>повышенным вниманием к обеспечению безопасности
>кодировщикЯ, видимо, чего-то не догоняю. Кодировщики же сырую картинку потребляют, там парсить нечего.
кодировщик может стоять на сервере и ему можно подсунуть специально сформированный источник для получения контроля над сервером. Банальнейший пример - загрузка видео на любой видеохостинг.
> кодировщик может стоять на сервере и ему можно подсунуть специально сформированный источник
> для получения контроля над сервером. Банальнейший пример - загрузка видео на
> любой видеохостинг.И что характерно, САБЖ не умеет парсить, кхе-кхе, заковыристые входные форматы, в которых именно это может быть актуально. Этим все-равно видимо сишный ффмпег будет заниматься. Ну или как это задумано?
А зачем кодировщику гора лишнего функционала, тем более уже реализованного другими проектами? Задача кодировщика — кодировать, а не быть монструозным комбайном.