The OpenNET Project / Index page

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

Первый официальный выпуск 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
Тип: Программы
Ключевые слова: av1, video
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (170) 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 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А Раст стоит учить?
     
     
  • 2.5, Иван (??), 22:17, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    однозначно, по перфомансу не уступает Си, безопасность на высшем уровне, никаких UB
     
     
  • 3.8, IRASoldier_registered (ok), 22:33, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п. Слишком частые релизы для того, чтобы можно было в спокойный, неторопливый продакшен.
     
     
  • 4.23, Ordu (ok), 00:02, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п.

    Есть такое. Rust 2015 и Rust 2018. Ты можешь взять распоследний rustc и сказать ему, что тебя интересует rust 2015, и будет тебе rust 2015.

    Впрочем они сломали rust 2018 в последней версии раста, переведя из разряда варнингов в разряд еггогов ругань нового борроу-чекера. Но они предупреждали заранее и эти варнинги довольно долго мозолили глаза, было время всё исправить.

    Они так же планируют сломать rust 2015, через некоторое время, сейчас там пока продолжают быть варнинги.

    Но это, по-моему, единственное что они ломали. Дело не в стабильности языка, дело в стабильности библиотек. Есть всякие там std, tokio и ряд других, которые достаточно стабильны, но их не так уж и много. Но для того, чтобы набрать достаточное количество и разнообразие стабильных библиотек расту потребуется ещё не меньше пяти лет, а может и лет десять. Это не быстро, потому что такое количество кода требует очень много человекочасов.

     
     
  • 5.95, Аноним (95), 14:40, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    - Вот смешные пошли программисты...
    "Дело не в стабильности языка"

    (Или это только растаманы? Впрочем, само это название тут: пожалуй - намекает)

     
     
  • 6.117, Аноним (117), 21:27, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Проблем со стабильностью языка не должно вроде быть пока все обратно совместимо, разве нет? Комментарий выше говорит про некоторые примеры когда обратная совместимость в последнее время ломалась, но вроде в целом выглядит все не так страшно, если честно. Насколько я понимаю они там говорят что обратная совместимость у вас сломается только если у вас уже баг в коде.
     
     
  • 7.119, Аноним (119), 00:52, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мы о разном.
     
  • 5.122, Аноним (122), 02:49, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это не просто варнинги, это баги старого чекера. Так что это не прихоть
     
     
  • 6.127, Ordu (ok), 03:02, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не просто варнинги, это баги старого чекера. Так что это не
    > прихоть

    Я не говорю, что это прихоть, или что так не надо было делать. Но в контексте разговора о стабильности языка, это явное указание на его нестабильность, вне зависимости от причин её.

     
  • 3.9, Блокнот.exe (?), 22:41, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что такое UB?
     
     
  • 4.10, Иван (??), 22:42, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Undefined behavior
     
  • 3.14, Аноним (14), 22:51, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Только вот перформанс сильно хуже C, а UB просто не называют UB. В остальном норм, поиграться полезно
     
     
  • 4.16, анонн (ok), 23:00, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Только вот перформанс сильно хуже C, а UB просто не называют UB.

    Ну раз аноним так говорит, то так оно и есть.


     
     
  • 5.22, ПомидорИзДолины (?), 23:49, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как там рекурсивный захват мьютексов из стандартной библиотеки поживает?
     
     
  • 6.33, burjui (ok), 03:37, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Никак, для этого есть:
    https://docs.rs/parking_lot/0.9.0/parking_lot/type.ReentrantMutex.html
    Любой желающий может написать RFC, чтобы включили в std, а пока разработчики решают более важные проблемы, т.к. язык ещё относительно молод.

    Только, ради всего святого, не надо гундеть про 3rd party (это я не лично вам, а всем "критикам"). parking_lot - стандарт де-факто в Rust.

     
  • 5.44, asdasd (?), 12:31, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения / уменьшения счетчика атомарные, что ни разу не быстро.
     
     
  • 6.52, Аноним84701 (ok), 14:21, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения
    > / уменьшения счетчика атомарные, что ни разу не быстро.

    Хм, т.е. на самом деле "занятия любовью" с владениями/заимствованиями -- это чисто из любви к мазохизму, а не потому что при этом компилятор может отслеживать владельца (ссылки) и автоматически вставлять освобождалку памяти при выходе владельца за пределы области видимости?


     
  • 6.80, Ordu (ok), 20:15, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кто это тебе сказал такое Rc и Arc -- это один из способов выделять память, но ... текст свёрнут, показать
     
     
  • 7.96, Аноним (95), 14:49, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ага... Проверка индексов массивов в runtime, и всё прочее
    - типа бесплатно?...


    Так что ничего не удивительно что:

    цитата:"из-за усложнения алгоритмов требует существенно больше времени для кодирования (по скорости кодирования libaom отстаёт от libvpx-vp9 в (!)сотни раз, а от x264 в (!)тысячи раз)"

    Т.к."усложнения алгоритмов" - без публичного сравнения по скорости с полноценно оптимизированным вариантом на Си(+SIMD+Asm) это деза, как причина таких убер-тормозов.

     
     
  • 8.98, Ordu (ok), 15:14, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты читал вообще о чём речь Речь идёт о счётчиках ссылок, а не о массивах и инде... текст свёрнут, показать
     
     
  • 9.108, Аноним (95), 16:55, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для начала скажу - не тыкай другим, хамя Да, ну - потому наверное в Си её и... текст свёрнут, показать
     
     
  • 10.115, Ordu (ok), 20:37, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скажи ещё раз, мне нравится эротичный звук твоего голоса Что значит не делают ... текст свёрнут, показать
     
     
  • 11.118, Аноним (118), 00:47, 12/11/2019 Скрыто модератором
  • –1 +/
     
     
  • 12.121, Ordu (ok), 02:21, 12/11/2019 Скрыто модератором
  • –1 +/
     
     
  • 13.141, Аноним (141), 16:19, 12/11/2019 Скрыто модератором
  • –2 +/
     
     
  • 14.142, Аноним (141), 16:20, 12/11/2019 Скрыто модератором
  • +/
     
  • 14.143, Ordu (ok), 18:06, 12/11/2019 Скрыто модератором
  • +/
     
     
  • 15.144, Аноним (144), 19:32, 12/11/2019 Скрыто модератором
  • +/
     
     
  • 16.153, Ordu (ok), 20:59, 12/11/2019 Скрыто модератором
  • +/
     
  • 15.150, Аноним (144), 20:50, 12/11/2019 Скрыто модератором
  • +/
     
     
  • 16.151, Аноним (144), 20:52, 12/11/2019 Скрыто модератором
  • +/
     
  • 16.152, Ordu (ok), 20:57, 12/11/2019 Скрыто модератором
  • +/
     
     
  • 17.166, Аноним (166), 04:08, 13/11/2019 Скрыто модератором
  • +/
     
  • 16.160, анонн (ok), 22:20, 12/11/2019 Скрыто модератором
  • +/
     
  • 8.104, Аноним (3), 16:30, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Раст тут ни при чём Говорю же, сладкое с мягким сравнивают ... текст свёрнут, показать
     
     
  • 9.109, Аноним (95), 17:05, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Раст тут ни при чём Говорю же, сладкое с мягким сравнивают Rust в отличие... текст свёрнут, показать
     
  • 8.135, Аноним (135), 15:00, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    - типа бесплатно На x86 со времен Core2 примерно Когда сравнивали драйвер 1... текст свёрнут, показать
     
     
  • 9.168, Аноним (168), 04:23, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Будь вы даже хоть бейсиковцем но, DOS времён вам бы и то - было бы понятно что ... текст свёрнут, показать
     
  • 4.32, burjui (ok), 03:29, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    "Тут Аноним взмахнул волшебной палочкой, и в комментарии появились пруфы" (С) Джоан Рофлинг
     
  • 4.47, Аноним (47), 13:12, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В некоторых кейсах Rust быстрее. Например проблема алиасинга разрешается на этапе компиляции, а не в рантайме. Возможности статического анализа у Rust значительно шире. Это позволит в будущем автоматически применять более глубокие и сложные алгоритмические оптимизации. C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. И это часто ведет к значительному усложнению кода, снижению читаемости. Но обычно разработчик просто забивает, т.к. это требует анализа и потерь времени.
     
     
  • 5.63, Аноним (63), 16:43, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.

    Вот только пока код писался на сях, программисты не забывали про оптимизацию, а с появлением всяких растов и прочих питонов решили, что оптимизацией теперь должен заниматься кто угодно, только не они. В итоге мы имеем калькуляторы, требующие гиг оперативки ("Не, ну а чо, она же дИшОвая").

     
     
  • 6.64, Аноним84701 (ok), 16:52, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Угу, а тож никто не помнит и ни разу не видел шЫдевры оптимизации while n 0 ... текст свёрнут, показать
     
     
  • 7.66, Аноним (66), 17:03, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.
    >> Вот только пока код писался на сях, программисты не забывали про оптимизацию,
    > Угу, а тож никто не помнит и ни разу не видел шЫдевры
    > "оптимизации":
    > while(n>0) { n= read(fd, buf + pos, 1); size++; buf = realloc(buf,
    > size); }

    [CODE]
    while(n>0) {
        n= read(fd, buf + pos, 1);
        size++;
        old_buf = buf;
        buf = realloc(buf, size);
        assert (old_buf == buf);
        old_buf = buf;
    }
    [/CODE]
    Простите за мой французский.

     
     
  • 8.68, Аноним84701 (ok), 17:24, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gt оверквотинг удален Учитывая, что код был демонстрационно-от балды основн... текст свёрнут, показать
     
     
  • 9.70, Аноним (66), 17:30, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Давай прямо assert сработает или нет ... текст свёрнут, показать
     
     
  • 10.71, Аноним84701 (ok), 17:34, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Давай криво Код после твоей правки - по прежнему нерабочий Мне не очень понятн... текст свёрнут, показать
     
     
  • 11.74, Аноним (66), 17:44, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это не правка Это намёк Честно, не пойму, прикалываешься ты, или нет С одной ... текст свёрнут, показать
     
     
  • 12.84, Аноним84701 (ok), 21:18, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хм, похоже, кто-то за деревьями не видит леса вот поэтому при непонятках все же... текст свёрнут, показать
     
     
  • 13.88, Anonymoustus (ok), 23:32, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Такие примеры мне нравятся Сразу с тестами ... текст свёрнут, показать
     
     
  • 14.92, Аноним (66), 07:40, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё бы интерполировать результаты с учётом затрат на обработку ISR, генерируемог... текст свёрнут, показать
     
  • 14.180, Аноним (180), 17:09, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А, ещё фанатик Rust с розовыми очками Не сильно надейтесь на все эти бенчмар... текст свёрнут, показать
     
  • 13.91, Аноним (66), 07:30, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не будешь, потому что понимаешь, что не даст Потому и сменил тему на стоимость ... текст свёрнут, показать
     
     
  • 14.94, Аноним84701 (ok), 12:15, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    code char buf malloc 1 ... текст свёрнут, показать
     
     
  • 15.101, Аноним (66), 15:40, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не стоит выдавать допущение за истину Ты тут где-то выше хвалился скоростью ПС-... текст свёрнут, показать
     
  • 10.120, Ordu (ok), 01:42, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Этот assert имеет квантовую природу, он сработает и не сработает Доступ к указа... текст свёрнут, показать
     
     
  • 11.131, Аноним (66), 10:42, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Добавим педантизму Possible undefined behavior ranges from ignoring the situati... текст свёрнут, показать
     
     
  • 12.132, Ordu (ok), 11:44, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Или он сработает каждый раз Или не разу Компилятор может его выкинуть из кода,... текст свёрнут, показать
     
     
  • 13.136, Аноним (66), 15:04, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты всерьёз предполагаешь, что написавший сработает на 16й итерации собира... текст свёрнут, показать
     
     
  • 14.138, Ordu (ok), 16:11, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так у него взорвётся, если чё Я предпочитаю такие вещи изучать так https gcc... текст свёрнут, показать
     
     
  • 15.170, Аноним (66), 11:17, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вполне предсказуемый результат трансляции Плоская модель памяти, сегментные рег... текст свёрнут, показать
     
  • 4.77, Аноним (77), 17:58, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто сказал, что хуже?
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gcc-rust.h
    https://www.techempower.com/benchmarks/
     
     
  • 5.97, Аноним (95), 15:00, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кто сказал, что хуже?

    Я сказал.
    Тут же выше: http://www.opennet.ru/opennews/art.shtml?num=51837#96
    "... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... ..."

    P.S.
    А, бенчмаркам верят только те - кому выгодно верить в *конкретный* бенчмарк...
    Сколько было уже таких людей несосчитать... то C# такой же по скорости, то ранее - Джаба с JITом;
    а, по факту - выше головы никому не прыгнуть.

     
     
  • 6.124, Аноним (122), 02:55, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И бенчмаркам никаким верить нельзя, и головой думать не нужно. Весело наверное в твоем мире жить
     
     
  • 7.146, Аноним (144), 19:46, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По вам и видно чем вы думаете...
     
  • 4.123, Аноним (122), 02:52, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > сильно хуже

    да конеш. https://github.com/ixy-languages/ixy-languages/

     
  • 3.26, Аноним (26), 01:11, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Если -20-60% условной производительности(и это без компиляторной магии си) это "не уступает", то можете использовать, только про си не упоминайте, уместнее тогда сравнивать с го и джава.
     
     
  • 4.169, Аноним (169), 04:49, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С чего такие цифры Они просто явно не учитывают умение доп-но оптимизировать р... текст свёрнут, показать
     
  • 3.55, Аноним (55), 14:30, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > никаких UB

    И как, бишь, D его B при целочисленном переполнении?

     
     
  • 4.100, Аноним (95), 15:30, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Чтоооо А, баги компилятора , а кривые руки программиста у растманов не знаю... текст свёрнут, показать
     
  • 2.19, Аноним (19), 23:34, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Стоит. Заметил, что я стал в своих программах на полноценном ООП отказываться от наследования в пользу композиции. Правда можно было бы и сделать нормальное наследование через композицию, но таких ЯП я не знаю.
     
     
  • 3.20, Аноним (19), 23:35, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    *на полноценном ЯП
     
  • 3.29, Crazy Alex (ok), 02:19, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и при чём тут Rust? Это отнюдь не вчера появившаяся идея. Я её у Саттера, кажется, первый раз встретил, а судя по википедии - она была ещё в книжке Банды Четырёх от 95-го года, и это много лет как совершенно базовый принцип, где-то рядом с single responsibility.
     
     
  • 4.81, a3k (?), 20:17, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это как-то само доходит после опыта поддержки хоть немного большого ООП-кода с изменяющимися требованиями.
     
  • 2.40, Ц (?), 08:47, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    C++ будет быстрее. Учите лучше его.
     
     
  • 3.43, Нонон (?), 12:04, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ассемблер быстрее. Учите лучше его.
     
     
  • 4.46, JL2001 (ok), 12:49, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ассемблер быстрее. Учите лучше его.

    он не оптимизируется автоматически, непереносим, долог в написании и рефакторинге, порождает множество ошибок в силу ограниченности человеческого разума и больших размеров программ

     
  • 4.51, Аноним (66), 14:15, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ассемблер быстрее. Учите лучше его.

    Лучше так не шутите, ведь подобные утверждения начинают повсюду копировать. Человек может написать боле быстрый код чем оптимизатор, но далеко не каждый.

     
     
  • 5.102, Аноним (95), 16:07, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Незнающий ассемблер и более того его оптимизации - ни на каком языке, не сможет... текст свёрнут, показать
     
     
  • 6.128, Аноним (66), 10:12, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Впрочем, речь то была про ассемблер и забытость его критичной важности.

    Напомню: "Ассемблер быстрее". В то время как это лишь мнемоническая запись машинного кода. Надо ли понимать, как работает железо? Для определённых категорий это, безусловно, необходимый навык. Именно понимание даёт возможность написать "быстрее", но никак не ассемблер.

     
     
  • 7.149, Аноним (144), 20:34, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не только понимание как работает железо, но и - как компиляторы А, ассембрер э... текст свёрнут, показать
     
     
  • 8.171, Аноним (66), 11:53, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ассемблер это ассемблер Трансляция мнемоник выполняется 1 в 1 в машинный код К... текст свёрнут, показать
     
     
  • 9.172, Аноним (172), 13:17, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, вперёд без знания и практики перечисленного мной - максимально оптимизиров... текст свёрнут, показать
     
     
  • 10.173, Аноним (66), 14:15, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Перечислен был некий загадочный опыт оптимизации , в то время как оптимизирова... текст свёрнут, показать
     
     
  • 11.174, Аноним (174), 20:41, 13/11/2019 Скрыто модератором
  • +/
     
     
  • 12.175, Аноним (66), 07:40, 14/11/2019 Скрыто модератором
  • +/
     
  • 3.45, JL2001 (ok), 12:47, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > C++ будет быстрее. Учите лучше его.

    не будет, ты просто не напишешь рабочую программу
    https://habr.com/ru/post/472780/

     
     
  • 4.78, Аноним (78), 18:28, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты эту ссылку из новости в новость тягаешь, не надоело еще? "Мы написали говнокод, хахаха, он работает неочевидным образом". Да подобным примерам на питоне и js целые сайты посвящены.
     
  • 4.90, Анонии (?), 06:46, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А мужики-то и не знали! Писали себе программы на C++, а оказывается, это невозможно было!
     
  • 2.67, Wilem (?), 17:18, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подобные вопросы лучше задавать гуглу. Если ты это делаешь на опеннете то ты либо тут первый раз, либо наслаждаешься неминуемым срачем (что не плохо, в общем-то - весело). Практической пользы немного, тк мало экспертов, в основном тут просто любители линукса.
     

     ....большая нить свёрнута, показать (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 Мегабайт?

    Странно.

    [code]
    % 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
    [/code]
    Попробуйте собирать не из под Виндовс.

     
     
  • 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:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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