The OpenNET Project / Index page

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

Первый официальный выпуск rav1e, кодировщика AV1 на языке Rust

09.11.2019 21:42

Состоялся первый выпуск нового высокопроизводительного кодировщика формата кодирования видео AV1 - rav1e 0.1, совместно развиваемого сообществами Xiph и Mozilla. Кодировщик написан на языке Rust и отличается от эталонного кодировщика libaom значительным увеличением скорости кодирования и повышенным вниманием к обеспечению безопасности. Код проекта распространяется под лицензией BSD.

Формат AV1 заметно опережает x264 и libvpx-vp9 по уровню сжатия, но из-за усложнения алгоритмов требует существенно больше времени для кодирования (по скорости кодирования libaom отстаёт от libvpx-vp9 в сотни раз, а от x264 в тысячи раз). Кодировщик rav1e предоставляет 11 уровней производительности, наивысшие из которых позволяют добиться скорости, близкой к кодированию в режиме реального времени. Кодировщик доступен как в форме утилиты командной строки, так и в виде библиотеки.

Поддерживаются все основные возможности AV1, включая поддержку внутренне- и внешне-кодированных кадров (intra- и inter-кадров), суперблоков 64x64, цветовой субдискретизации 4:2:0, 4:2:2 и 4:4:4, 8-, 10- и 12-разрядного кодирования глубины цвета, RDO (Rate-distortion optimization) оптимизации искажений, различные режимы предсказания межкадровых изменений и выявления трансформаций, управление скоростью потока и выявление усечения сцены.

 
  1. Главная ссылка к новости (https://www.reddit.com/r/AV1/c...)
  2. OpenNews: Google открыл код libgav1, нового декодировщика для формата AV1
  3. OpenNews: Выпуск кодировщика видео SVT-AV1 0.6, развиваемого компанией Intel
  4. OpenNews: Третий выпуск dav1d, декодировщика AV1 от проектов VideoLAN и FFmpeg
  5. OpenNews: Альянс AOMedia опубликовал заявление, касающееся попыток сбора отчислений за AV1
  6. OpenNews: Увидел свет первый выпуск открытого видеокодека нового поколения AV1
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51837-av1
Ключевые слова: av1, video
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (164) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Анонидзе (?), 22:06, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • –8 +/
    Есть же уже Dav1d
     
     
  • 2.3, Аноним (3), 22:09, 09/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +24 +/
    Только dav1d — декодер.
     
     
  • 3.110, Анонидзе (?), 18:08, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    То есть декодер сделали раньше кодировщика?
     
     
  • 4.111, Аноним (3), 18:18, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > То есть декодер сделали раньше кодировщика?

    Есть по меньшей мере 3 кодировщика помимо сабжа (больше) и 3 декодировщика. Dav1d только декодировщик, работает быстрее libaom (референсной реализации). Спеки открыты, каждый пилит как хочет.

     

  • 1.2, Аноним (3), 22:08, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +5 +/
    А чё с аналогичными кодировщиками не сравнили? Ну, x265 там хотя бы, и libaom или как там его. Зачем сравнивать несравниваемое?
     
     
  • 2.6, антонимус (?), 22:22, 09/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    x265 ограничен глубиной цвета от 8 до 16 битов на пиксель.
     
     
  • 3.7, Аноним (3), 22:32, 09/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Сабж не ограничен? Я так картиночки сохранял, емнип пришлось взять tga вместо tiff. Не встречал больше 10 на практике, но 12 вроде уже в ходу (для сравнения, у мониторов ограничение 10 с хаками было, не в курсе как сейчас).
     
  • 3.35, хотел спросить (?), 04:26, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    а это плеать что?

    цветовой субдискретизации 4:2:0, 4:2:2 и 4:4:4, 8-, 10- и 12-разрядного кодирования глубины цвета

     

  • 1.4, Блокнот.exe (?), 22:15, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +/
    А Раст стоит учить?
     

     ....большая нить свёрнута, показать (88)

  • 1.12, NaN (?), 22:48, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +5 +/
    Там же половина на асме.
     
     
  • 2.103, Аноним (95), 16:23, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –3 +/
    И даже это не помогло... так лагуч Rust.
     
     
  • 3.125, Аноним (122), 02:57, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    Хмм, а чего тогда не на сишке то написали оптимизированные оптимизации, зачем было тратить время на асм? Раст же виноват
     
     
  • 4.155, Аноним (144), 21:06, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    А, кто же ещё. Ну не помянутый же Си...
    Оптимизация - должна быть комплексно...
    А, выросшим на Rust - откуда уметь даже просто ассемблерные оптимизации полноценно - пиши не пиши теперь на ассемблере..., и основной то код на Rust - никто не отменял.
    Не отмажитесь - тут уже таки: «Раст виноват».
     
     
  • 5.185, Аноним (122), 17:52, 16/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Когда научишься связно излагать - возвращайся
     
     
  • 6.186, Аноним (186), 00:33, 17/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Хамов никто не спрашивал же. +Вперёд - учиться читать.
     

  • 1.13, Аноним (14), 22:49, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +11 +/
    Основная половина кодировщика написана на ассемблере. Смените название поста ;)
     
     
  • 2.15, анонн (ok), 22:58, 09/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    > Основная половина кодировщика написана на ассемблере. Смените название поста ;)

    Основная половина mem/strcpy/strstr в glibc написана на асм, смените название либы

     
     
  • 3.18, Crazy Alex (ok), 23:26, 09/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +11 +/
    Ей можно - она не НА, а ДЛЯ C.
     
  • 3.27, Аноним (27), 01:58, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –2 +/
    >Основная половина mem/strcpy/strstr в glibc написана на асм

    но ведь это ложь

     
     
  • 4.31, анонн (ok), 02:42, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +2 +/
    Но ведь это аноним i386 memcpy S https sourceware org git p glibc git a blob ... большой текст свёрнут, показать
     
     
  • 5.37, Аноним (66), 06:07, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    Но это половина не основная, а расширенная (см. extension). Кроме того, её возможно вообще выкинуть.
     
  • 2.34, burjui (ok), 03:57, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    Только подавляющая часть ассемблера - в директориях x86 и arm, что достаточно прозрачно намекает на то, что на ассемблере написаны специально оптимизированные версии алгоритмов и функций, а не основное мясо кодировщика.
     
     
  • 3.38, Аноним (66), 06:16, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –4 +/
    Названия каталогов явно говорят о том, что в них содержится оптимизация под конкретные архитектуры. Что именно там оптимизировано и где (и что) мясо -- непонятно как из тех названий следует (а изучение содержимого каталогов и файлов -- это задача как раз делавшего исходное утверждение).
     
  • 3.49, Аноним (49), 13:42, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Так ведь описанное —  и есть основное мясо кодировщика.
     

  • 1.21, Аноним (19), 23:37, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +/
    А кодирование AV1 на GPU, TPU и FPGA будет?
     
     
  • 2.25, Аноним (25), 00:58, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Будут аппаратные декодеры и кодировщики во всех новых GPU и SoC.
     
     
  • 3.56, Аноним (55), 14:37, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Аноним гарантирует?
     
     
  • 4.73, iPony129412 (?), 17:36, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +2 +/
    А куда они денутся. Тут даже VP9 появился при гораздо меньшей поддержке.
     
     
  • 5.105, Аноним (95), 16:35, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    При наличии уже даже OpenCL - давно нет смысла тратить транзисторы на codecs.
     
     
  • 6.106, Аноним (95), 16:37, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    (а, если и сделают - реально будет на OpenCL, из маркетинговых соображений это умолчат)
     
  • 6.176, iPony129412 (?), 08:47, 14/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > При наличии уже даже OpenCL - давно нет смысла тратить транзисторы на codecs.

    Бред https://trac.ffmpeg.org/wiki/HWAccelIntro#FFmpegAPIImplementationStatus

    > ​OpenCL can be used for a number of filter

     
     
  • 7.189, Аноним (189), 00:46, 18/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Бред у вас, я того что по ссылке - и не отрицал...
    go to школа учиться читать.
     

  • 1.28, Аноним (27), 02:07, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +/
    надо будет попробовать, сравнив с hevc
     
     
  • 2.99, Аноним (27), 15:24, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +2 +/
    короче, проверил
    при аналогичном качестве видео занимает в ~8 раз меньше места на диске по сравнению с hevc
    но есть недостатки:
    1) работает слишком медленно, почему-то использует только одно ядро процессора, несмотря на опции
    2) принимает на вход только в y4m формате, который занимает слишком много места на винте
     
     
  • 3.107, Аноним (107), 16:45, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    2) принимает на вход только в y4m формате, который занимает слишком много места на винте
    это референсный инкодер (commandline), подразумевается что либу запилят во что-то типа fmpeg (я надеюсь C биндинги будут), поэтому это вообще ни разу не недостаток.
    про первое - оч странно, какие опции использовали. Надо бы баг им запилить) должно все использовать.
     
     
  • 4.113, Аноним (3), 20:00, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Корми в пайпе, типа такого:

    ffmpeg -v 0 -i source.mp4 -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout |

     

  • 1.30, Ivan_83 (ok), 02:41, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • –1 +/
    svt-av1 по любому быстрее должен быть.
     
  • 1.36, Аноним (-), 06:02, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • –6 +/
    >Код проекта распространяется под лицензией BSD.

    Вот такое вот БЗДунство растаманов меня сильно огорчает. Ибо ничего лучше GPL v3+ нети никогда не будет.

     
     
  • 2.39, dimqua (ok), 07:57, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • –1 +/
    Откуда ты знаешь, ты GPLv4 видел, а GPLv5? :-)
     
  • 2.41, Аноним (41), 09:24, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –6 +/
    Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете.
     
     
  • 3.48, Аноним (48), 13:34, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –2 +/
    Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт
     
     
  • 4.58, Аноним (-), 15:56, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    >Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт

    Не прибежит. Проприетарщики выбирают БЗДу. А с БЗДы на ГПЛ в можно. С БЗДы в любое направление можно.

     
     
  • 5.93, КО (?), 10:19, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    >А с БЗДы на ГПЛ в можно

    Не совсем, в BSD есть одно требование, на которое в GPL кладут болт.

     
     
  • 6.112, Аноним (95), 19:45, 11/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Это должно быть аж не требовать раскрытия исходников Или вы про 3-й claus... большой текст свёрнут, показать
     
     
  • 7.130, Аноним (-), 10:36, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    У противника Свободы бомбануло. Ничо FSF будет давить проприетарщиков и колаборантов-БЗДунов революционными методами.
     
     
  • 8.162, Аноним (162), 23:41, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Значит вы противник прогресса А, напомните то как в устах таких говнюков ... большой текст свёрнут, показать
     
  • 3.57, Аноним (-), 15:50, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    >Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете.

    Расскажи это пацыкам, которые переписали утилиту ls. Вместе посмеёмся.

     
  • 2.60, Аноним (41), 16:02, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    > GPL v3+

    Я правильно понимаю, что ты, придя, скажем, в банк, подписываешь абсолютно чистые листы А4, а уже потом банк печатает на эти листы абсолютно любые условия? Потому что "+" в GPLv3+ именно то и означает, что ты передал столлману пачку листов А4 со своей подписью внизу. Ну а он в них может вписать любой свой маразматический бред.

     
     
  • 3.69, Аноним (19), 17:24, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Не столлману, а форкеру. Форкер может апгрейднуть версию. А может и не апгреднуть
     

  • 1.50, Простой парень (?), 14:00, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • –1 +/
    Проблема не в том, какой язык лучше, а в том, какое место он может занять. Вот смотрите: приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере. Чёткая иерархия, каждому языку есть место, согласно тому, какие задачи на нём проще решать. Проблема в том, что это складывается стихийно, а не предсказуемым образом. Разработчики языка исходят из того, что они могут сделать, какие у них есть идеи, а не из того, какие задачи стоят перед современным языком. Вот раст пока не нашёл свою нишу, но то что развитие с++ зашло в тупик, подталкивает разработчиков испытывать новые языки у себя в проектах, и только поэтому раст держится.
     
     
  • 2.54, Аноним (41), 14:28, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +2 +/
    Аналогия, где языки представляются различными инструментами молоток чтоб забива... большой текст свёрнут, показать
     
  • 2.79, Аноним (27), 19:31, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    >развитие с++ зашло в тупик

    и в чём это проявляется?

     
     
  • 3.82, Простой парень (?), 20:40, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    >>развитие с++ зашло в тупик
    > и в чём это проявляется?

    map, unordered_map - этого мало? А то что конструктора для std::string из форматированной строки до сих пор нет, это что? Эти все конференции где тучи высоколобых с упорством достойным лучшего применения спорят о какой то никому кроме них не нужной сpaни, мало?

     
     
  • 4.85, Аноним (27), 21:37, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    https://www.youtube.com/watch?v=fT3OALUyuhs
     
  • 3.163, Lex (??), 23:53, 12/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    С каждыми "новыми плюшками", синтаксис плюсОв становится всё монструозней и уродливей.
    Хотя, и с джавой примерно аналогично.
     
  • 2.89, nelson (??), 23:39, 10/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +3 +/
    > приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере

    Среда выполнения си на ассемблере, говорите? Правду говорят, что обучение программированию питоном до добра не доводит )

     

  • 1.83, Аноним (83), 21:06, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +1 +/
    А как там у Rust с экспортом? Можно библиотеку с ABI использовать в сишной программе просто линконув их?
     
     
  • 2.86, Ordu (ok), 23:01, 10/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +3 +/
    #[no_mangle]
    fn print_int(i: i32) {
        println!("{}", i);
    }

    Такое вполне можно вызывать из C. Но если ты заботишься о кроссплатформенности кода, то вместо i32 тебе лучше использовать std::os::raw::c_int.

     

  • 1.87, Аноним (87), 23:03, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +2 +/
    Абсолютно безграмотная фраза, спутаны сущности формата и кодировщика Формат пре... большой текст свёрнут, показать
     
  • 1.114, Аноним (95), 20:01, 11/11/2019 [ответить] [﹢﹢﹢] [ · · · ]      [к модератору]
  • +/
    Всё же хотелось бы и тестов, ладно фиг с ними с тормозами Rust, но что - на счёт самого сжатия?...
    И патентов...
     
  • 1.116, Аноним (87), 20:58, 11/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    Что-то ебилдов не видно — ни в портеже, ни в оверлеях, ни на багтрекере нет. Деплой зоопарка растолиб оказался гентушникам не под силу?
     
     
  • 2.126, Аноним (122), 03:00, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Какой такой зоопарк? В расте статическую линковку делают обычно,.
     
     
  • 3.129, Аноним (-), 10:31, 12/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • –1 +/
    >Какой такой зоопарк? В расте статическую линковку делают обычно,.

    Поэтому helloworl! на Расте весит 5 Мегабайт?

     
     
  • 4.134, анонн (ok), 13:03, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > Поэтому helloworl! на Расте весит 5 Мегабайт?

    Странно.




    % rustc -V                                                                        
    rustc 1.38.0
    % cat hello.rs

    fn main() {
      println!("Hello World!");
    }
    % rustc hello.rs
    % ll hello
    -rwxr-x---  1 анонн  wheel   286K 12 Nov. 16:59 hello
    % readelf -d hello|grep NEED                                                  
    0x0000000000000001 NEEDED               Shared library: [libthr.so.3]
    0x0000000000000001 NEEDED               Shared library: [libgcc_s.so.1]
    0x0000000000000001 NEEDED               Shared library: [libc.so.7]

    % strip hello
    % ll hello
    -rwxr-x---  1 анонн  wheel   215K 12 Nov. 16:59 hello

    % rustc hello.rs -O -C lto
    % strip hello
    % ll hello
    -rwxr-x---  1 анонн  wheel   189K 12 Nov. 17:00 hello



    Попробуйте собирать не из под Виндовс.

     
     
  • 5.140, Anonymoustus (ok), 16:19, 12/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    >> Поэтому helloworl! на Расте весит 5 Мегабайт?
    > % ll hello
    > -rwxr-x---  1 анонн  wheel   189K 12 Nov. 17:00
    > hello
    >
    > Попробуйте собирать не из под Виндовс.

    Всё равно же много.

    У меня в Виндовс хелловорлд на Сишечке, собранный посредством TCC (Tiny C Compiler by Fabrice Bellard), весит 2048 байт. TCC, конечно, не мейнстрим вроде GCC, но пусть будет убойным примером ради высшей справедливости.

    Если собирать обычным GCC (была использована версия 4.7.2), то получается 34816 байт статически слинкованного сабжа.

     
     
  • 6.145, анонн (ok), 19:43, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Учитывая, что libc вообще-то рантайм библиотека для этой самой сишечки, а не рас... большой текст свёрнут, показать
     
     
  • 7.148, Anonymoustus (ok), 20:05, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Ничего нормального в этом нет, просто все уже привыкли к жирному тормознутому го... большой текст свёрнут, показать
     
     
  • 8.156, анонн (ok), 21:19, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Для PE32 классика же http www phreedom org research tinype Конкретно у себя ... текст свёрнут, показать
     
     
  • 9.164, Ordu (ok), 23:56, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    gt оверквотинг удален Тут как минимум пять байт лишние Второй вызов int 21h н... текст свёрнут, показать
     
  • 5.184, Аноним (122), 17:51, 16/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    Нужно с opt-level=3 собирать чтобы работыл dead code elimination
     
  • 3.133, Аноним (87), 11:56, 12/11/2019 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    Дикий зоопарк совершенно, который при запуске сборки начинает качаться с репозиториев на жидхабе неконтролируемым образом. Для сборки сабжа нужно скачать 138 (!) пакетов с библиотеками, все из которых для включения в Gentoo нужно оформить в виде ебилдов. Это уже привязка к облаку какая-то пошла, в оффлайне build-система раста растеряется и ничего не сможет сделать.

    Статическая линковка помогает только в случае распространения бинария от разработчика к пользователю. В большинстве дистрибутивов unix-подобных ОС принята другая модель, в которой от разработчика берутся только исходники и далее подготавливаются мэйнтейнерами для автономной сборки на build-фермах. Сабж довольно сложно деплоить таким образом.

     
     
  • 4.137, Аноним (-), 15:37, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Слыхал поговорку: "Linux писан сишными прогоаммистами, и для сишных программистов Linux".
    UNIX - BSD - Linux - это множество кусков сишного кода. При всём уважении к языку Rust, но всё же этот язык является чужеродным элементом в Unix-подобных системах.
     
     
  • 5.154, Аноним (87), 21:05, 12/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Проблема не в языке, а в том, что используемая сабжем build-система, cargo, включает в себя средство установки компонентов из удалённого репозитория, что в UNIX-подобных ОС является прерогативой исключительно пакетного менеджера. В экосистеме UNIX отлично живут программы на любых языках, где build-системе достаточно скормить каталог с исходниками и она его автономно и предсказуемо соберёт, но ситуация, когда эта build-система при сборке внезапно (в man cargo-build нигде не сказано о возможной сетевой активности, а также нет опции для её отключения) начинает самостоятельно ломиться во внешний мир и что-то непонятное из него тащить, абсолютно недопустима.
     
     
  • 6.182, пох. (?), 07:29, 15/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    как будто в неюниксоподобных это не так разумеется, там тоже можно нагадить в ... большой текст свёрнут, показать
     
     
  • 7.183, Аноним (87), 18:54, 15/11/2019 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > как будто в неюниксоподобных это не так

    Там обычно нет пакетного менеджера с исключительной прерогативой установки компонентов из внешнего мира. Вместо этого программы поставляются в виде отдельного инсталлятора, который всё чаще самой программы не содержит, а лезет за ней в веб. Вероятно, по образу и подобию этих инсталляторов и сделан вышеупомянутый cargo.

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

    Как же тогда софт собирается в nixos и guixsd, где /usr и /lib вообще отсутствуют?

    > афтыри раньше программировали на nodejs

    Похоже на то: js-макакам вообще никакие правила не писаны.

     

  • 1.161, Аноним (161), 23:02, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    Ну, hevc не такой уж медленный. У меня на Pentium 4 он кодит 576p с пресетом fast аж целый 1 fps. Мне не проблема подождать пару часов, чтобы закодить 6-минутный ролик. Другое дело, что декод 576p 1500k в realtime уже не тянет. Результат не посмотреть, только для других делать. Меньшие разрешения идут.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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