The OpenNET Project / Index page

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

Выпуск rav1e 0.3, кодировщика AV1 на языке Rust

09.02.2020 10:08

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

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

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

В новой версии:

  • Предложен более быстрый режим кодирования Speed 10;
  • Сокращён размер бинарных сборок (на платформе x86_64/Linux библиотека занимает около 3МБ);
  • Примерно на 14% сокращено время сборки;
  • Добавлен многопоточный фильтр для удаления блочных артефактов из видео (deblocking);
  • Для архитектуры x86_64 реализованы дополнительные оптимизации с использованием инструкций SIMD и расширено применение автовекторизации;
  • На 1/6 снижено число операций по выделению памяти;
  • В RDO (Rate-distortion optimization) улучшена логика подавления внутрикадровых искажений;
  • Некоторые операции переведены с использования арифметики с плавающей запятой на целочисленные вычисления;
  • На 1-2% улучшено качество кодирования на втором уровне скорости;
  • Добавлен новый фильтр предсказания направления движения (Intra edge);
  • Добавлена опция "-S" (--switch-frame-interval) для определения интервала переключения между кадрами;
  • Добавлена поддержка сборки для платформы wasm32-wasi (WebAssembly System Interface).


  1. Главная ссылка к новости (https://github.com/xiph/rav1e/...)
  2. OpenNews: Выпуск rav1e 0.2, кодировщика AV1 на языке Rust
  3. OpenNews: Sisvel формирует патентный пул для сбора отчислений за использование кодеков AV1 и VP9
  4. OpenNews: Выпуск кодировщика видео SVT-AV1 0.6, развиваемого компанией Intel
  5. OpenNews: Google открыл код libgav1, нового декодировщика для формата AV1
  6. OpenNews: Десятый выпуск dav1d, декодировщика AV1 от проектов VideoLAN и FFmpeg
Лицензия: CC-BY
Тип: Программы
Ключевые слова: rav1e, av1, video
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (140) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, leap42 (ok), 10:16, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    а почему на Rust? заходим в репо, видим что 57% кода это язык ассемблера. а кроме этих двух ещё есть Shell и Python.
     
     
  • 2.2, Аноним (2), 10:21, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Assembly 56.9%
    Rust 42.8%
    Действительно, почему))
     
     
  • 3.31, коржик (?), 13:24, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы построчно считаете? Сколько ассемблерных инструкций в одной строке раста?
     
  • 3.57, Андрей (??), 15:48, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Интересно, сколько там rust-строк (безопасных), а сколько в unsafe-блоках.
     
  • 2.6, proninyaroslav (ok), 10:48, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну и что? На асме (20 файлов) вынесены только платформо-зависимые вещи вроде SSE инструкций, т.е те участки кода, которые критичны ко времени выполнения и должны быть эффективными. Остальные 111 файлов написаны на расте, т.е вся логика кодировщика.
     
     
  • 3.9, mommy (?), 11:24, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Тоесть асмный код эффективный а раст это мусор? Ну я так и знал
     
     
  • 4.17, Аноним (17), 12:07, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +15 +/
    А раст "безопасный". Безопасно вызвать асм код это особое искусство!
     
     
  • 5.54, Аноним (-), 15:44, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    😃 😃 😃
     
  • 5.66, nelson (??), 17:01, 09/02/2020 Скрыто модератором
  • –6 +/
     
  • 4.26, proninyaroslav (ok), 12:30, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Асм эффективнее любого существующего языка. Конечно, в большинстве случаев компилятор сам умеет генерировать эффективный асм, но компилятор не всемогущ и не всегда предсказуем, особенно когда это касается спец-наборов инструкций типа SIMD/SSE/MMX. Их часто пишут вручную.
     
     
  • 5.39, A.Stahl (ok), 14:12, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дык человек-то ещё менее всемогущ и предсказуем, особенно когда это касается спец-наборов инструкций типа SIMD/SSE/MMX.
     
     
  • 6.41, proninyaroslav (ok), 14:21, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Дык человек-то ещё менее всемогущ и предсказуем, особенно когда это касается спец-наборов
    > инструкций типа SIMD/SSE/MMX.

    То есть вы хотите сказать что компилятор абсолютно всегда знает где применять SIMD, при этом не нарушая семантику программы, а программист, который знает с какими данными он работает и что хочет получить в итоге, используя SIMD, нет)? Ну тогда вы изобрели ИИ для компилятора, программисты в таком случае и не нужны (как и сами языки).

     
     
  • 7.76, Анонимиус (??), 19:17, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    На самом деле вы недооцениваете компиляторы, и переоцениваете человека. Как правило компиляторы С/С++ при должной квалификации программиста генерируют довольно хороший код, а код, написанный на ассемблере человекм, далеко не всегда работает заметно быстрее сгенерированного
     
     
  • 8.82, proninyaroslav (ok), 20:05, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, при должной квалификации и знания потрохов того компилятора, для которого ... текст свёрнут, показать
     
  • 8.115, VEG (ok), 11:31, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы переоцениваете компиляторы В любом оптимизированном кодеке будет много ассем... текст свёрнут, показать
     
  • 7.104, виндотролль (ok), 03:47, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну тогда вы изобрели ИИ для компилятора

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

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

     
     
  • 8.116, VEG (ok), 11:37, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ага, именно поэтому все самые быстрые кодеки всегда на низкоуровневых C Rust с к... текст свёрнут, показать
     
     
  • 9.128, виндотролль (ok), 18:12, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    От задачи зависит Теоретически, чем более высокоуровневый язык, тем круче оптим... большой текст свёрнут, показать
     
  • 4.45, Аноним84701 (ok), 14:49, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Все верно Здесь - считаем Здесь https sourceware org git p glibc git a tr... большой текст свёрнут, показать
     
  • 4.89, Аноним (89), 22:17, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    асмный код - это различная реализация одних и тех же процедур для разных платформ.
    Отдельные реализации для ARM32, ARM64, x86_64. Соответственно, один бинарник использует только часть кода, который относится только к платформе этого бинарника

    Код на Rust - один для всех платформ.

    Конечно, если у вас есть 3 версии реализации одного и того же - это у вас будет занимать больше места.

    Асмный код по кол-ву строк тоже больше места занимает зачастую, чем аналогичные операции на C/Rust/etc.

     
  • 4.121, Аноним (121), 13:10, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Покажите хотя бы один компилятор, который делает автоматическую оптимизацию в SIMD-инструкции?

    (Нет, vector extensions, которые идентичны написанию на асме, не считаются).

     
     
  • 5.137, Иван (??), 00:06, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пожалуйста:

    https://godbolt.org/z/eyj-xb

    GCC 9.2

     
  • 3.87, Аноним (87), 20:34, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > На асме (20 файлов) ... должны быть эффективными. Остальные 111 файлов написаны на расте

    Т.е. чтобы вызывать функции из 20-ти файлов на асме, требуется 111 неэффективных файлов на расте?!

     
  • 2.32, Аноним (32), 13:31, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >а почему на Rust? заходим в репо, видим что 57% кода это язык ассемблера.

    А потому, что Rust он же безопасный и в указатели на нём низзя-низзя, моветон. Поэтому на ассемблере.

     
  • 2.37, Аноним (37), 14:06, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Забавно то, что в декодере dav1d, написанном на С, аналогичная картина.

    Assembly 57.6%
    C 41.4%
    Other 1.0%

     
     
  • 3.48, нах. (?), 15:01, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    он НЕБЕЗОПАСТНЫЙ, как вы не можете этого понять!

     

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

  • 1.3, Аноним (3), 10:22, 09/02/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +2 +/
     
  • 1.4, Аноним (4), 10:39, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Что плохого в Rust? А то его здесь много критикуют.
     
     
  • 2.5, leap42 (ok), 10:41, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в Rust ничего плохого, просто проект в основном на ассемблере написан, а не на грибе (на нём видимо обвязка)
     
  • 2.7, Аноним (7), 11:17, 09/02/2020 Скрыто модератором
  • –4 +/
     
     
  • 3.8, коржик (?), 11:18, 09/02/2020 Скрыто модератором
  • +7 +/
     
     
  • 4.10, mommy (?), 11:25, 09/02/2020 Скрыто модератором
  • +2 +/
     
  • 4.59, emg81 (ok), 16:00, 09/02/2020 Скрыто модератором
  • +5 +/
     
  • 3.14, Аноним (4), 11:37, 09/02/2020 Скрыто модератором
  • +1 +/
     
  • 2.11, segesg (?), 11:27, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вокруг раста слишком много хайпа, многие не понимают сильных сторон этого языка. Зато понимают что язык сложный (это правда), особенно после питона и джава(скрипта), вот и "критикуют".
     
     
  • 3.13, Аноним (4), 11:36, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну вообще, конечно, управление памятью без сборщика мусора всегда было мечтой низкоуровнего программирования. И пусть, конечно, от unsafe не избавиться, но по крайней мере всех скелетов может запереть там
     
  • 3.25, proninyaroslav (ok), 12:22, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну плюсы тоже сложные, если использовать их правильно.
     
     
  • 4.74, Аноним (74), 19:11, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В том, собственно, и смысл. На плюсах просто начать писать, но научиться писать на них нормальный надежный код - задача не одного года обучения. Семантика Rust по сути форсит ряд практик безопасной разработки на C/C++ по умолчанию. В итоге начать хоть что-то писать на Rust сложнее (потому что всякая дичь, которую человек может написать особенно после привычки к GC, просто не будет компилироваться), но вот начать писать на нем вменяемый код легче.
     
     
  • 5.83, proninyaroslav (ok), 20:22, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я имел ввиду что некоторые тоже хейтят C++ за свою сложность, но продолжают писать и изучать. В случае раста "неосилил" приравнивается к отказу использовать его, ибо не отправдал надежд, и яростно хейтить за это. Просто многие из мира языков со сборкой мусора (довольно большая часть аудитории, которая инетерсуется растом) не понимают что языки с ручным или полуавтоматическим управлением памятью априори сложны, и новый модный язык не будет проще старомодного.
     
  • 2.28, нах. (?), 13:04, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    в самом rust может и ничего особенно плохого хотя лично мне идея кажется феерич... большой текст свёрнут, показать
     
     
  • 3.46, Илья (??), 14:52, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > ...хруст,  ...мурзилой, ...адептами, ...хрустеры

    Человек даже свой жаргон ненависти придумал. Читаю и радуюсь.

     
     
  • 4.47, нах. (?), 15:00, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    видимо, более сложные слова разбирать для тебя - задача невыполнимая, альтернативно-одаренный?

     
  • 4.75, Аноним (74), 19:15, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > жаргон ненависти

    Последствия любого упоминания Rust здесь мне напоминают двухминутку ненависти из 1984.

     
  • 3.49, Аноним (4), 15:03, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я, конечно, сам тоже скептик переписывания, но по-вашему никакого нового кода взамен существующего писать не надо, да?

    > еще один бесполезный кодировщик бесполезного формата

    Для вас бесполезного, а для кого-то может и нет, зачем же так категорично говорить

     
     
  • 4.52, нах. (?), 15:32, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если никакого _нового_ кода, не взамен существующего, не появилось на значительн... большой текст свёрнут, показать
     
     
  • 5.64, Аноним (4), 16:57, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не особо хорошо, да Хотя если честно, я все равно не пойму такой силы напа... большой текст свёрнут, показать
     
     
  • 6.69, нах. (?), 17:24, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну потому что задолбали уже всех белки-истерички, рассказывающие о том, как всем... большой текст свёрнут, показать
     
     
  • 7.73, Аноним (74), 18:54, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > ну потому что задолбали уже всех белки-истерички, рассказывающие о том, как всем настанет щщастье от переписывания на хруст. А щастья все нет и нет.

    Как минимум, на opennet редко кто врывается и что-то рассказывает про Rust. Здесь просто потоки ненависти в сторону Rust и все. Выдумали себе "сектантов" и воюете с ними.

    Rust не дает абсолютную безопасность. Я соглашусь, что это во многом маркетинговый лозунг. Но Rust дает семантику, благодаря которой ты думаешь о безопасности только тогда, когда об этом нужно думать  (а это менее 1% времени разработки), а не постоянно. Помимо этого он исправляет гору накопившихся проблем других языков путем внедрения накопившихся достижений функциональных языков (нет null, нет наследования типов, нет эксепшенов, нарушающих поток управления, но есть алгебраические типы, трейты, бесплатные итераторы и т.д.). Плюс к этому вокруг языка складывается современная удобная экосистема (единая система сборки, легкость в создании документации, тесты из коробки, причем тестируются даже примеры кода в доке и т.д).

    Никто не заставляет вас писать на Rust. Но хейтеры здесь почему-то выглядят как человек из той шутки: "я догнал вас только чтобы сказать, как вы мне безразличны". Пишут себе люди на Rust и пишут - вам какое дело? Если язык действительно плох, то пропадет и без вашей ненависти.

     
     
  • 8.84, Илья (??), 20:29, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не кормите троллей ... текст свёрнут, показать
     
  • 7.79, Аноним (4), 19:45, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как же нам тогда писать софт с меньшим числом досадных багов и уязвимостей? И какова судьба Си?
     
     
  • 8.81, Аноним (74), 19:56, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я достаточно изучил местную аудиторию, так что наверняка предложенные вам вариан... текст свёрнут, показать
     
  • 7.131, коржик (?), 20:10, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Он метил в замены C++ - а там, в общем-то, никто не мешает писать правильно.

    Как я не догадался?

    > Но, по-моему, идея была в том, чтобы заменить не язык, а дорогих программистов на нем - дешевыми.

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

     
     
  • 8.139, нах. (?), 10:32, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    у него будет больше времени на тяп-ляп Это плохо Управление памятью не являетс... текст свёрнут, показать
     
     
  • 9.148, коржик (?), 21:45, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Считать деньги это по вашему тяп ляп Биллинг, генерация документов и репортов ... текст свёрнут, показать
     
  • 3.86, proninyaroslav (ok), 20:31, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > ради _переписывания_ _уже_существующего_ кода

    Это болезнь любого нового (или не очень) языка. Язык просто ищет применение, а те кто изучает его ищут на чём попрактиковаться, так как коммерческая сторона этим языком либо не заинтересована, либо только в процессе прощупывания. Бывают, конечно, и фанатики которые хотят что всё вокруг было написано на их любимом языке (JS в том числе).
    Раст находится где то около процесса прощупывания и уже сейчас можно увидеть в т.ч brand new софт, который пилится гуглом, майкрософтом и некоторыми другими мелкими компаниями или сообществом.

     
     
  • 4.88, нах. (?), 22:16, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    нет Это новоизобретение именно модных-современных язычков Повторяю _все_ что ... большой текст свёрнут, показать
     
     
  • 5.93, proninyaroslav (ok), 22:36, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, хоть и раст изначально разрабатывался без определённой прикладной цели, но через 2 года он всё таки попал под крыло мозиллы и применение было сразу найдено - как безопасную замену плюсам с уклоном в функциональное программирование и системой сборки/переиспользования кода из коробки. Думаю, это достаточный повод иметь данный язык, хотя бы как альтернативу монополии плюсов.

    Тот же Го изначально разрабатывался в академическом кругу Plan 9 в виде языков Limbo и Newsqueak (причём они более развиты чем их наследник), но потом этот круг попал под крыло к гуглу, что дало шанс этим языкам в виде Го.

     
  • 5.94, Аноним (74), 22:47, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Откуда вы это берете Если это действительно просто троллинг, то прямо слишком т... большой текст свёрнут, показать
     
     
  • 6.114, нах. (?), 10:49, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    дружище, мы эти сказочки про дело-небыстрое слушаем уже лет семь, кажется В это... большой текст свёрнут, показать
     
     
  • 7.117, Аноним (117), 12:40, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У гугла подход простой 1 Перекупить ключевых разрабов у других компаний напо... большой текст свёрнут, показать
     
     
  • 8.120, нах. (?), 13:04, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    почему нет-то Они не хотели работать затак Они хотели работать за мало бабла ... большой текст свёрнут, показать
     
     
  • 9.125, Аноним (117), 14:07, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    почему нет-то c Спорно Проекты на Rust нередко обходят по производительности... большой текст свёрнут, показать
     
  • 5.106, Аноним (4), 04:52, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > так было с Си

    А вот и нет, Юникс был в начале на асме написан. А уж потом придумали Си и переписали на Си, и оказалось эффективнее и надежнее

     
     
  • 6.108, нах. (?), 07:14, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    то что было написано на асме- было примитивным монитором, с тремя командами ls c... большой текст свёрнут, показать
     
  • 5.107, Аноним (4), 04:54, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И только поколение миленниалов додумалось до идеи "сперва изобретем нескучный язычок, потом начнем "искать применения", авось найдутся".

    Как будто это просто очередной язычок, а про компайл-тайм гарантии безопасности вы забываете.

     
  • 3.98, имя (ok), 00:20, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ага, особенно Страуструп, писавший инновационную и нанотехнологичную 8230 науч... большой текст свёрнут, показать
     
     
  • 4.109, нах. (?), 07:29, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    afair, cfront использовался для какой-то вполне осмысленной деятельности, пусть ... большой текст свёрнут, показать
     
     
  • 5.122, имя (ok), 13:25, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > чтобы считать что от замены на хруст хоть что-то улучшилось, именно.
    > А количество cve каждый месяц почему-то по прежнему не меняется.

    https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+css

    За два года всего два разрыва, и те не use-after-free, как раньше пачками находили, а логические ошибки. Но ты продолжай верить, что это всё было зря.

    > Хромог и йож обходятся без хруста, и тормозят меньше.

    Смешно пошутил! Спасибо, нет, даже за вычетом прожорливости по памяти до сих пор у blink-браузеров с этим полный провал. Но у меня и вкладок поболе пятидесяти будет.

    > то еще какой хренью заниматься вместо работы?

    Вот тут соглашусь, впрочем: больно смотреть на все эти бесполезные коммиты про WebVR, WebAR, WebGPU и прочие GamepadAPI.

     
     
  • 6.123, нах. (?), 13:49, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > За два года всего два разрыва,

    А остальные не отнесли к css.

    Я просто смотрю на release notes шерстяного с очередным "а эти двадцатьпятьштук - нас не
    касаются//исправлены два года назад". Хватило одного программиста вместо сорока смузихлебов.

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

    А новая-модная мурзила на этом "старье" просто не работает. Никак.

     

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

  • 1.12, Аноним (12), 11:30, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Истина всегда где-то рядом. Важен лишь продуктивный симбиоз для решения конкретной задачи, а не крайности. Слесарный молоток - отличный инструмент, но мясо лучше отбивать кухонным. Таков путь!
     
  • 1.15, Аноним (15), 12:00, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я тут недавно выяснил, что для h264 минимальный битрейт порядка 10000kbps на 1080p, иначе получается сплошное мыло. Можно уменьшить, но на практике это так. Т.е все эти файлы — ­сплошной мусор. Стандартно рекомендуют что-то вроде 1080p : 4Mbps to 6Mbps, но это ни о чём, 6000 хватит разве что h265. Если ~2000 нужно только для 360p, эти значения очень занижены.

    Впрочем, можно проще, crf выставить в 17 (для h264, дефолт 23), 18 примерно минимальным для хоть какого-то качества. Для h265 crf минимум 21 (дефолт 27). Иначе на файлы можно смотреть только с расстояния в 10 метров.

    Это всё, кстати, подтверждается разного рода исследованиями в сети. Есть ли такие сравнения для сабжа? Кто-нибудь уже догадался прогнать файлы под каким-нибудь vmaf? Сравнить с h265, наконец?

     
     
  • 2.20, Аноним (17), 12:10, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто уже догадался что в качестве разных кодировщиков нет никакой разницы и не стал ничего проводить.
     
     
  • 3.24, Аноним (15), 12:18, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я могу сказать, что на 360p h265 битрейт ~300kbps равен ~1000kbps h264. И h265~400kbps соотносится с h264~1500kbps (что-то в районе). Т.е. разница есть, и она очень велика и заметна невооружённым глазом.

    пс. Чтобы получить достаточное качество на h265~300kbps ещё и придётся потвикать параметры, какие, я конечно же не скажу.

     
     
  • 4.29, нах. (?), 13:06, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > пс. Чтобы получить достаточное качество на h265~300kbps ещё и придётся потвикать параметры

    а заниматься тем же самым для h264 тебе было не с руки, поэтому и получили что получили.

     
     
  • 5.30, Аноним (15), 13:17, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> пс. Чтобы получить достаточное качество на h265~300kbps ещё и придётся потвикать параметры
    > а заниматься тем же самым для h264 тебе было не с руки,
    > поэтому и получили что получили.

    Визуально качество очень сильно отличается. Я твикал на предмет удобоваримой скорости кодирования и отсутствия специфических артефактов-глитчей, они особенно проявляются на низком битрейте. У h264 сразу лезут артефакты картинки без всяких глитчей. Визуальная разница между самыми медленными пресетами опять же есть и без всяких твиков.

     
     
  • 6.33, нах. (?), 13:34, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    разница вполне может быть вызвана тем, что самый медленный пресет все равно тв... большой текст свёрнут, показать
     
     
  • 7.36, Аноним (15), 14:06, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да не, x265 уделывает x264 целиком и полностью Особенно, на низком битрейте бр... большой текст свёрнут, показать
     
     
  • 8.53, нах. (?), 15:39, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    пресеты не особо менялись первые лет десять А дальше я перестал следить - полаг... большой текст свёрнут, показать
     
     
  • 9.78, artenox (?), 19:33, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Годнота попадается иногда Сканы с шумной кинопленки Имхо, будущее за 50p 60p ... текст свёрнут, показать
     
     
  • 10.90, нах. (?), 22:26, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ее сканировать уже нечем, к сожалению Это тебе не нескучный язык приспособить к... большой текст свёрнут, показать
     
  • 7.141, Thony (?), 11:10, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > P.S. отдельный вопрос - а где ты берешь несжатые исходники, на которых можно оценить какое-то там качество?

    Кстати, на счет этого -- для Canon существует такой твик фирмвари Magic Latern, который позволяет записывать RAW Video, каждый отдельный кадр в сыром виде как он снят с матрицы. Чистота получающегося видео просто обалденная.

     
  • 2.51, Ordu (ok), 15:29, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Это всё, кстати, подтверждается разного рода исследованиями в сети.

    Можно ссылочки? Мне очень методики сравнения интересны, я не понимаю как это можно делать, и было бы круто узнать.

     
     
  • 3.61, Аноним (15), 16:27, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть метрики навроде VMAF и PSNR, гуглится на раз. Насчёт информации на русском языке не уверен.
     
     
  • 4.68, нах. (?), 17:17, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Есть метрики навроде VMAF и PSNR, гуглится на раз. Насчёт информации на
    > русском языке не уверен.

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


     
     
  • 5.72, Аноним (15), 18:42, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнивать визуальные артефакты различных кодеков равноценно нельзя, но степень ... большой текст свёрнут, показать
     
     
  • 6.91, нах. (?), 22:29, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сравнивать визуальные артефакты различных кодеков равноценно нельзя, но степень отличия от
    > оригинала оценить вполне можно.

    дык а кому она нужна, степень эта?
    Если мы их глазом либо не видим, либо видим совсем не то что этот метод считает важным.

    > С PSNR, насколько я помню, проблема в том, что он артефакты считает за "детали", потеря этих
    > самых "деталей" иногда более предпочтительна.

    о том и речь.

    А продираться через детали математики - еще одна жизнь нужна :-(

     
     
  • 7.95, Аноним (15), 23:19, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну поэтому я просто проверяю скриптом битрейт и параметры у файлов из интернета ... большой текст свёрнут, показать
     
     
  • 8.96, artenox (?), 00:02, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Коммерческие кодеры Mainconcept не пишут параметры кодирования YouTube еще вы... текст свёрнут, показать
     
     
  • 9.99, Аноним (15), 00:26, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, просто пока что мне ещё не попадались хорошие файлы с удалённой инфой в инте... текст свёрнут, показать
     
     
  • 10.100, artenox (?), 00:41, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    CABAC, Ref MediaInfo показывает В Avidemux можно посмотреть сколько B кадров и ... текст свёрнут, показать
     
     
  • 11.101, Аноним (15), 00:56, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Точно Я дополню, спасибо Случайно взятый файл показал cabac ref 1 maxbitrate 1... текст свёрнут, показать
     
     
  • 12.103, artenox (?), 02:56, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю насчет ffprobe В Avidemux клавиши Up Down переход по ключевым I кадра... большой текст свёрнут, показать
     
     
  • 13.105, artenox (?), 04:15, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Причем, вместе с maxrate задается bufsize - это величина, на которую битрейт мож... текст свёрнут, показать
     
  • 8.113, нах. (?), 10:22, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    чорт, даже интересно стало - что это такое ты смотришь, что можно не смотреть ес... текст свёрнут, показать
     
     
  • 9.126, Аноним (15), 14:53, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос, скорее, про хранение Затем, что лучше не было, стриминговые сайты гонят... большой текст свёрнут, показать
     
     
  • 10.132, artenox (?), 20:42, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А ffmpeg тоже чертов Ведь в нем по умолчанию crf 28 ... текст свёрнут, показать
     
     
  • 11.133, artenox (?), 20:43, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И много кто не меняет эти умолчания, если форумы почитать ... текст свёрнут, показать
     
  • 11.134, Аноним (15), 21:47, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Абсолютли Надо же было додуматься до такого, 23 уже обращает всё в тыкву Я мог... текст свёрнут, показать
     
     
  • 12.135, artenox (?), 22:00, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Может скопипастить команду из форумов ... текст свёрнут, показать
     
  • 5.77, Ordu (ok), 19:28, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По ссылке 1 с википедии 2 , которая заодно третья ссылка в ddg при поиске по за... большой текст свёрнут, показать
     
     
  • 6.92, нах. (?), 22:31, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть, я бы на месте video service operator ещё бы подумал, стоит ли обращать внимание на
    > рекомендацию в пункте (c).

    ну вот, еще до одного дошло, что верить никому нельзя.

    imho, чем тратить недели на чтение первоисточников и разбирательства деталей, проще потратить (недели же) на пробные кодирования и ручной просмотр - если мы не нетфликс, и для себя это делаем, нас интересует не его выборка, а наша собственная.

     
     
  • 7.110, Ordu (ok), 09:44, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > imho, чем тратить недели на чтение первоисточников и разбирательства деталей, проще потратить (недели же) на пробные кодирования и ручной просмотр

    Хахаха, лол. Заменить выборку из 18 человек на выборку из 1 человека, это офигенно добавит к достоверности исследования, да. Если ты хочешь лучше, то тебе надо набрать своих человек 15, повторить исследование и сравнить результаты с тем, что указано в статье. В случае существенного расхождения набрать ещё человек тридцать и наковырять ещё данных.

    И, я отмечу, чтение первоисточников -- это несколько часов. А вот провести исследование -- это уже действительно недели. Я бы рассчитывал на месяц минимум, и заранее морально готовился бы к тому, что это может растянутся и на два-три месяца. Особенно если нет опыта проведения исследования на людях.

    > если мы не нетфликс, и для себя это делаем, нас интересует не его выборка, а наша собственная.

    Ты читать умеешь? Совет ориентирован на video service provider. Если ты раздаёшь видео себе, то тебе вообще никакие советы не нужны, бери и стримь. Если не понравится, потом подтюнишь.

     
     
  • 8.112, нах. (?), 10:17, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    естественно Мы же для этого человека делаем, а не для тех восемнадцати Иначе м... текст свёрнут, показать
     
     
  • 9.136, Ordu (ok), 22:21, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, но и потратил я на это не несколько часов, а несколько минут Ему нужен комп... текст свёрнут, показать
     
     
  • 10.138, нах. (?), 10:25, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ему нужно денег, и желательно - побольше Если пипл хавает дерьмо с лопаты - то ... текст свёрнут, показать
     
     
  • 11.146, Ordu (ok), 15:25, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе удалось уловить самые азы экономики Умница ... текст свёрнут, показать
     
  • 2.130, ksa242 (?), 18:52, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Scene rules * для 1080p рекомендуют минимум 8000 kbps, максимум 14000 kbps.

    * http://web.archive.org/web/20141227121239/http://scenerules.irc.gs/t.html?id=2011_X264.2.nfo

     
     
  • 3.151, Аноним (15), 21:36, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это больше похоже на правду, спасибо. То стриминговые стандарты, которых все придерживаются. Тот же гугл рекомендует что-то там двух/трёхкратный запас битрейта, ему ещё транскодировать в vp9. Проблема ещё и в том, что на 6-7.5 mbps можно получить вполне достойное качество, если не экономить на параметрах кодирования (и даже me=umh сойдёт, если он subme=10 вместо 3), но все экономят. У некоторых просто нет возможности делать медленный энкод, но на практике это ведь жадные торгаши, считающие каждую копейку за электричество и максимизирующие прибыль ценой катастрофического падения качества.

    Ремукс Паразитов на пиратбее fullhd@~30mbps (его не было, когда я в прошлый раз хотел посмотреть этот фильм), выглядит вполне ничего для h264.

     
  • 2.145, Аноним (145), 12:00, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну, это очень сильно зависит от исходника и что там в нём написано, его частоты ... большой текст свёрнут, показать
     
     
  • 3.149, Аноним (149), 22:51, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Анон, откуда такие познания в предмете? Что и кого почитать чтобы стать таким же как ты?
     
  • 3.152, Аноним (15), 22:18, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У x265 есть pmode его, вероятно, стоит выбрать вместо pme Проблема в том, что... большой текст свёрнут, показать
     

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

  • 1.27, vz_2 (?), 12:44, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какой тут безопасный и оптимизирующий компилятор, если половина кода ассемблера, хотя последний трудно назвать языком. Бедные растаманы.
     
  • 1.34, nelson (??), 13:44, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >> Кодировщик написан на языке Rust и отличается от эталонного кодировщика libaom значительным увеличением скорости кодирования

    на реализацию которого по сути забили - https://github.com/mozilla/aom
    rav1e 0.3 наполовину на асме, но увеличение производительности произошло волшебным образом при реализации логики на растишке, ага
    пиар растишки - это что-то за гранью. растишка к реализации видеокодеков имеет примерно такое же отношение как околомагазинный бухарик к самой растишке. для того, чтобы этот AV1 стал пригоден к использованию, необходима банальная аппаратная реализация наиболее ресурсоёмких частей алгоритма кодирования. ЯП реализации логики здесь вообще вторичен
    всё это уже проходили во времена то первых, то ли вторых пней, когда на мат. платах распаивали микросхемы кодеков по причине того, что пеньки не тянули кодировку-раскодировку видео

     
     
  • 2.55, нах. (?), 15:48, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > на реализацию которого по сути забили - https://github.com/mozilla/aom

    а чего реализовывать-то еще? Уже все реализовано, эталон ненужно создан.

    > rav1e 0.3 наполовину на асме, но увеличение производительности произошло волшебным образом
    > при реализации логики на растишке, ага

    интересно, в ее компиляторе хотя бы те же оптимизации что всеми скопипащены у icc - есть, или там любую подобную хрень надо писать на ассемблере?

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

    она бесполезна. Ты не хочешь за нее платить.

    > всё это уже проходили во времена то первых, то ли вторых пней,
    > когда на мат. платах распаивали микросхемы кодеков по причине того, что
    > пеньки не тянули кодировку-раскодировку видео

    нет, по причине того, что не было нормальных кодеков. Как только появился divX - волшебным образом те же "пеньки" стали пригодны для кодирования без всяких волшебных микросхем.

    Именно по этой причине никакой av1 не взлетит, да и 265 тоже маловероятно (ну там еще прибавилась человеческая тyпость и жадность, конечно - впрочем, av1 это они же в профиль) - уже существуют и используются кодеки, позволяющие обойтись без специализированных плат в массовом сегменте, и будет крайне трудно заставить людей заплатить за то, что им не нужно.

    А немассовый не окупит специализированные чипы и тем более.

    При этом закон Мура действовать перестал, производительность процессоров больше не удваивается за пару лет, поэтому шансов на светлое будущее тоже не предвидится.


     
     
  • 3.118, крок (?), 12:47, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кодеки были просто дорого, но вот аппаратные ускрители мпег2 стали ненужны в п2 тк там уже был ммх и все работало програмно
     
     
  • 4.119, нах. (?), 12:57, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    да нет, в том и прикол что mpeg2 отправился на свалку истории _раньше_ "аппаратных ускорителей". divx все испортил.

     
     
  • 5.124, artenox (?), 14:04, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    MPEG2 и по сей день лучше DivX/XviD'ов. По крайней мере, на битрейтах, на которых их обычно используют.
     
     
  • 6.147, Аноним (147), 19:12, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вам кажется. Не в последнюю очередь потому, что в MPEG-4 ASP пережимали в т.ч. и из MPEG-2, т.е. качество могло только упасть.
     
  • 2.102, Аноним (147), 01:06, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > на реализацию которого по сути забили - https://github.com/mozilla/aom

    Если что, это старое зеркало Мозиллы. Работа ведется здесь: https://aomedia.googlesource.com/aom

     

  • 1.35, Аноним (35), 13:52, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    - AV1 - требует слишком больших затрат на вычисления, а результат? Надо сравнивать конечный итог - это отношение различия изображений исходного и перекодированного к размеру выходного файла. Если выяснится что различие, составляет 1-2% в пользу AV1, а скорость в 1000 раз в пользу H264 то смысла в AV1 нет.
     
     
  • 2.38, Аноним (15), 14:09, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не понял, h264 это вообще мусор. Нужен бесплатный конкурент h265, и они пытаются его сделать. Сегодня в вебе vp9 и это адок ещё тот — он хуже h264 (который при этом лучше конкурентов своего времени).
     
     
  • 3.42, Аноним (42), 14:23, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это ты не понял. Всё незапатентованное можно запатентовать задним числом. Всё не под монополией можно подогнать под монополию. Всё общественное можно приватизировать и передать организациям связанным с гнилобергами. На любой товар и даже не на товар можно ввести налог в пользу всяких мигалкиных. Любую деятельность можно внести в перечень лицензированных.

    Думать что какой-то AV1, уступающий другим кодекам, и поэтому дотпоры до времени оказавшийся не нужным, иммунен против всего вышеперечисленного, просто наивно.

     
     
  • 4.44, Аноним (15), 14:31, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для AV1 передали свой патентный пул различные различные заинтересованные лица. Нельзя использовать алгоритмы mpeg, всё остальное можно. Всем заинтересованным в неуплате отчислений, вступившим в сговор, использование патентов участников лицензировано на "свободной" основе. Надо уже придумать что-то своё, а не пользоваться алгоритмами 100 летней давности.
     
  • 2.80, Аноним (80), 19:46, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > различие, составляет 1-2% в пользу AV1

    При кодировании с использованием libaom выигрыш по объёму относительно x264 получается весьма значительным, порядка 50%. Вдобавок, не вполне корректно сравнивать голые цифры PSNR и SSIM: подобно тому, как визуальное качество H.264 на голову опередило H.263 за счёт применения деблокинга на стороне декодера, AV1 ещё на одну голову выше за счёт сглаживания линий (CDEF), что позволяет даже на низких битрейтах не портить надписи и прочие контуры, чем страдают все кодеки предыдущих поколений.

     
  • 2.143, Аноним (143), 11:17, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    C H26x проблема - оно покрыто лицензионными ограничениями вдоль и поперёк.
     

  • 1.40, Аноним (42), 14:15, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >заметно опережает H.264

    А что с h.265 и h.266 (патентасты идут лесом, в большинстве государств алгоритмы непатентуемы, а США и Япония - ССЗБ)?

     
     
  • 2.43, Аноним (15), 14:24, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Все норм железки делают в Японии. Сга — основной рынок, в том числе для Китая. Пол мира сотрудничает с Сга во всём. Куда деваться?

    Если h266 будет принципиально и фактически превосходить av1 (пытающегося конкурировать с h265), то av1 окажется в роли сегодняшнего vp8.

     
     
  • 3.58, нах. (?), 15:52, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Все норм железки делают в Японии.

    даже жаль, что их никто не покупает, да?

    > Если h266 будет принципиально и фактически превосходить av1 (пытающегося конкурировать
    > с h265), то av1 окажется в роли сегодняшнего vp8.

    не окажется. Сегодняшний vp8 (в отличие от бесполезного 9, как раз "нашего ответа h265") - бытовой кодек. Доступен каждому васяну без дополнительных затрат, и будет воспроизводиться у любого другого васяна - тоже без дополнительных затрат.

     
     
  • 4.60, Аноним (15), 16:17, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "Бытовой" подразумевает в первую очередь бытовое применение. Т.е. h265 на сегодня _самый_ лучший и _самый_ бытовой на свете, а vp8/9 получили распространение только и исключительно от нежелания гугла платить роялти и способности того влиять на веб стандарты. И если предыдущая история mpeg по сей день нас чему-то учит, h266 ждёт такой же тотальный успех.

    >никто не покупает

    Вообще-то покупают, вон и память приличная до недавнего времени только заводами в Японии производилась, т.е. компоненты. И оптика, и аудио-аппаратура. В Китае просто дешевле и логистика уже построена, остальные производители понесли соответствующий урон с тех пор, как оказалось, что Китай не только мусор гнать способен.

     
     
  • 5.67, нах. (?), 17:15, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > "Бытовой" подразумевает в первую очередь бытовое применение.

    берем любую "бытовую" видео-камеру - там-тадам - h264 либо в .mov, либо в .mp4
    Без вариантов.

    Берем не совсем бытовую не совсем видео, где, казалось бы, могут уже не экономить копеек: https://www.dpreview.com/reviews/panasonic-lumix-dc-s1h-review ($4k - такая вот бытовая техника) - опять h264 и очень опционально - 265 - и это модель которая только-только до прилавков добралась (хз кто ЭТО покупает), выберешь на год старше - будет только 264.
    Потому что a) стандартные алгоритмы в стандартных корпусах b) а в общем-то и не надо никому ничего другого, и у всех уже есть софт для работы с h264.

    Перспективы av1, непригодного ни для просмотра ни для монтажа без спецускорителей, которых еще и нет в природе - на этом фоне выглядят не то что туманно, а вообще никак.

    > Вообще-то покупают, вон и память приличная до недавнего времени только заводами в Японии
    > производилась, т.е. компоненты.

    именно что "компоненты". И покупает их - китай. Провести вторичную отбраковку и распаять на модули - в Японии слишком дорого, результат никому окажется за те деньги не нужен.

    Ну и как-то между делом постепенно выясняется, что и компоненты незачем возить из Японии, их китайцы из песка и сами способны гнать потоком. Качеством, как обычно, похуже, ценой на рупь дешевле, потребители довольны до усеру.

     

  • 1.63, Аноним (63), 16:55, 09/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Че там, в огнелисе теперь будет нормальное гпу ускорение?
     
     
  • 2.70, нах. (?), 17:27, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Че там, в огнелисе теперь будет нормальное гпу ускорение?

    конечно нет. все деньги потрачены на чудо-кодек.

     
  • 2.71, Аноним (87), 17:35, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    шутишь? они же на безопасный раст переписывают.
     
  • 2.85, Аноним (42), 20:31, 09/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, будет GPU-ускорение. Ненормальное, небезопасное, но если хотите пользоваться сайтами, то придётся им дать доступ к GPU.
     
  • 2.97, Имя (?), 00:06, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Будет, пилят vaapi на wayland. Все новости проспал?
     
     
  • 3.111, Аноним (87), 09:49, 10/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. можно ещё лет 10 поспать, а потом они начнут останки FF на dust переписывать, изобретая AV100500, который в миллион раз медленнее x264, но жмёт на 0.001% сильнее.
     

  • 1.129, an (??), 18:35, 10/02/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +/
     
  • 1.142, Аноним (143), 11:16, 11/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Две строчки обвязки вокруг мнемоник ассемблера - но зато ОНОЖЕНАХРУСТЕ!!!111
     
     
  • 2.144, Гугляки... (?), 11:42, 11/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хруст - Это Артхаус.
     

  • 1.150, Аноним (150), 22:54, 11/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Rust же ради безопасности, стоило ли так заморачиваться, что написать другу половину кода на самом небезопасном языке
     

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



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

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