The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первый стабильный выпуск zlib-ng, высокопроизводительного форка zlib , opennews (??), 17-Мрт-21, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


7. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –4 +/–
Сообщение от Аноним (7), 17-Мрт-21, 15:18 
Это конечно всё очень полезно, только zlib в основном из-за сжатия веб страниц жив. И, я слышал, brotli его заменил. А трафик так и вовсе бесплатный теперь -- не то, что раньше. Но интересно как так получается, что gz быстрее zlib, когда это одно и то же (по-сути). Или я чего то не знаю, или подобрали специальные кейсы.
Ответить | Правка | Наверх | Cообщить модератору

9. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +2 +/–
Сообщение от Аноним (9), 17-Мрт-21, 15:33 
Угу, гуглу это расскажи. А то чего-то для них трафик основная статья расходов. Думаешь чего они с сжатием возятся, для прикола?! И мобильные операторы тоже почему-то пипеткой этот "бесплатный" отмеряют. А то эфир видите ли делится на всю толпу и поэтому ограниченый ресурс.
Ответить | Правка | Наверх | Cообщить модератору

12. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +5 +/–
Сообщение от Аноним (12), 17-Мрт-21, 16:09 
И все труды gzip множатся на ноль из за маленький изображений... с весом более 10 Мб, а так же из за видеорекламы.
Ответить | Правка | Наверх | Cообщить модератору

58. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –2 +/–
Сообщение от Аноним (58), 17-Мрт-21, 22:20 
Для начала
1) gzip в картинках вообще не встречается.
2) гугл webp любит, там совсем zip'а/deflate'а нет.
3) Грузить 10метровые картинки на нагруженных страницах гугол не любит.
Ответить | Правка | Наверх | Cообщить модератору

179. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +2 +/–
Сообщение от Аноним (179), 18-Мрт-21, 23:23 
> gzip в картинках вообще не встречается

Расскажи это PNG.

Ответить | Правка | Наверх | Cообщить модератору

211. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Аноним (-), 19-Мрт-21, 03:20 
> Расскажи это PNG.

deflate != gzip ;). Гзип как бы deflate + некие свои хидеры. А png это deflate + некие свои хидеры. При чем тут gzip? В png нет заголовков оного, кукуйте.

Ответить | Правка | Наверх | Cообщить модератору

21. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 17-Мрт-21, 17:02 
> Или я чего то не знаю,

Наверное не знаешь вообще ничего. Все что ты видишь перед собой, в той или иной мере использует zlib, вся твоя графика без нее работать не будет, даже твой глубоко консольный пакетный менеджер без нее не может. Игры и инторнеты и подавно.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

23. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –2 +/–
Сообщение от Аноним (7), 17-Мрт-21, 17:08 
Или же знаю по крайней мере больше тебя? Во всяком случае, deflate очень медленный и неэффективный, как ни крути.
Ответить | Правка | Наверх | Cообщить модератору

27. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 17-Мрт-21, 17:53 
Ты даже не знаешь как работает пнг
Ответить | Правка | Наверх | Cообщить модератору

31. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –3 +/–
Сообщение от Аноним (7), 17-Мрт-21, 18:18 
Может быть. Это не делает deflate менее опциональным.
Ответить | Правка | Наверх | Cообщить модератору

34. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (35), 17-Мрт-21, 19:14 
Спасибо за ыкспердное мнение.
Ответить | Правка | Наверх | Cообщить модератору

59. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (58), 17-Мрт-21, 22:22 
> Ты даже не знаешь как работает пнг

Таки можно приколоться и сделать нежатый png. Или RLE-only. Однако для декодирования произвольного inflate все же понадобится.

p.s. а таки png устарел... ну вот не лучшая либа по сжатию это, словарик мелкий, скорость распаковки так себе. Тот же zstd и жмет лучше и декомпрессится быстрее одновременно.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

280. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от topin89 (ok), 27-Мрт-21, 02:06 
Я ещё могу понять, что неэффективный (тут по коэффициенту сжатия всё равно всех делает PAQ8) или неоптимальный (где, судя по всему, хорош Zstandard), но с каких это пор он медленный?
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

281. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 27-Мрт-21, 02:24 
На сжатие он медленный, особенно на 9чку. Не для сжатия текстур скажем так. На распаковку достаточно ок конечно.
Ответить | Правка | Наверх | Cообщить модератору

24. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –1 +/–
Сообщение от Аноним (7), 17-Мрт-21, 17:11 
И да, помимо веб-страниц он использовался примерно только в png (zlib и был сделан для png).
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

60. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +2 +/–
Сообщение от Аноним (58), 17-Мрт-21, 22:25 
Вот ты ламер. Он используется много где. А просто потому что долгое время это было 1 приличной опенсорс либой сжатия.

Ну например, формат данных HMM III (и IV) пожат тем самым deflate'ом. О чем прозрачно намекает копирайт Адлера и проч в коде их бинаря (статически влинковано, при том уязвимая версия, трололо, удачной игры по сети!).

Ответить | Правка | Наверх | Cообщить модератору

67. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –2 +/–
Сообщение от Аноним (7), 17-Мрт-21, 22:42 
Прости, но… С каких пор коммерческие поигручечки (из 90х!) считается за "используется"? Им ведь ровно всё равно, чем жать, многие и не жмут даже нули -- в итоге все эти гигабайты сейвов сжимающиеся в 100000 раз валяются на диске как есть, ровно то же самое и с текстурами. Допустим, может использоваться для _медленного_ сжатия текстур где-то, допустим. Ну и? А вот в левелдб используется снаппи, дальше что? Этот же снаппи может использоваться опционально и не очень ещё в десятке проектов. Странно, почему не дефлейт, он же такой хороший и универсальный?
Ответить | Правка | Наверх | Cообщить модератору

81. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +2 +/–
Сообщение от Аноним (81), 17-Мрт-21, 23:04 
> Прости, но… С каких пор коммерческие поигручечки (из 90х!) считается за "используется"?

С таких каких я в них играю, например.

> 100000 раз валяются на диске как есть, ровно то же самое
> и с текстурами.

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

Но факт в том что они вот настолько считают это ценностью. И игроделы это юзают. В смысле коммерческие проприетарные, конечно.

> Допустим, может использоваться для _медленного_ сжатия текстур где-то,
> допустим. Ну и? А вот в левелдб используется снаппи, дальше что?

А ничего. Snappy вообще один из самых бестолковых алгоритмов. Единственное его "достоинство" - NIH. В остальном он не делает ни LZ4, ни LZO, ни другие сравнимые. Ни по скорости ни по сжатию.

> Этот же снаппи может использоваться опционально и не очень ещё в
> десятке проектов. Странно, почему не дефлейт, он же такой хороший и универсальный?

Потому что это алгоритмы из сильно рахных категорий. Snappy в принципе степень сжатия deflate не получит на большинстве типов данных. Куды гольному LZ с туповатым битстримом супротив LZ+Huffman по сжатию? Но по скорости декодирования - отпедалить два алгоритма (LZ + Huffman), очевидно, дольше чем один. Особенно актуально для распаковки LZ, которая сама по себе довольно быстрая операция в силу принципов работы.

Ответить | Правка | Наверх | Cообщить модератору

85. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –1 +/–
Сообщение от Аноним (7), 17-Мрт-21, 23:12 
>RadGameTools

Опять некрофильствуешь? Я практически уверен что они кокнулись ещё в 90 (да, я в курсе, что в начале нулевых было ещё пара игрушек с bik).

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

>из сильно рахных категорий

По-моему, это несколько упрощённая и понерфленная версия zlib, возможно, именно благодаря нему появился brotli. А то и zstd (наш спаситель).

Никакого отношения это всё ни к чему не имеет, deflate пусть универсальный, но с любой стороны дорогой и медленный даже сегодня, что говорить о ситуации 30 лет назад.

Ответить | Правка | Наверх | Cообщить модератору

119. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Аноним (-), 18-Мрт-21, 04:51 
> Опять некрофильствуешь? Я практически уверен что они кокнулись ещё в 90 (да,
> я в курсе, что в начале нулевых было ещё пара игрушек с bik).

Черта с два! Живее всех живых. И просто для понимания, в PS5, кажется, один из их форматов В ЖЕЛЕЗО ВХАРДКОЖЕН. В смысле, там после SSD хардварный декодер. Выжимает гигов 5, чтоли, в секунду. Что дает совсем иные понятия о времени loading крутых тяжелых гамез.

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

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

Это разные классы алгоритмов. Snappy - в той же категории что LZ4, LZO, LZ5, Lizard, lsza ... (имя им легион). Одностадийный LZ, без хаффмана (арифметика, ANS, rangecoder, в общем entropy coding). Вторая фаза - кодирование за LZ энтропийным кодером повышает сжатие, но это два алгоритма друг за другом, поэтому медленнее. Особенно на распаковку.

Фэйл в том что по параметрам snappy вообще совсем ничем не интересен. Он ну вот не делает сравнимые алгоритмы. Вроде бы совсем ни в чем, кроме NIH синдрома у гугла. Поэтому и не встречается почти, кроме пары гуглопроектов.

> По-моему, это несколько упрощённая и понерфленная версия zlib, возможно, именно благодаря
> нему появился brotli. А то и zstd (наш спаситель).

Это другой класс алгоритмов - LZ без entropy coding. Точнее, zlib, zstd, lzma и ко - попросту двухступенчатые алгоритмы. Сперва примерно такой же по смыслу LZ, но его выход потом отдается фазе entropy coding. Поэтому декомпрессия медленнее, надо 2 разных алгоритма сжевать вместо 1.

Нагляднее всего это в формате Lizard (потомок LZ5) видно, там даже LZ в чистом виде очень странно складывает результат, в 5 разных субпотоков (которые опционально можно huffman'у отдать, каждый отдельно конечно).

> Никакого отношения это всё ни к чему не имеет, deflate пусть универсальный,
> но с любой стороны дорогой и медленный даже сегодня, что говорить о ситуации 30 лет назад.

Ну да, он медленноват и не очень хорошо жмет, словарик мелкий. В эпоху DOS оперативки видите ли было сильно меньше...

Ответить | Правка | Наверх | Cообщить модератору

82. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –2 +/–
Сообщение от Аноним (7), 17-Мрт-21, 23:04 
Хотя, что касается снаппи… Будем считать, что это было тёмное время. Нет, конечно, на сжатие он в 2 и более раз быстрее, но он ведь на распаковку медленнее zlib и жмёт при этом в 2 раза хуже. Но суть в том, что медленное ресурсоёмкое сжатие походит не везде и не для всего, а так конечно может быть использовано любое сжатие где угодно. Но вот на уровне стандарта или формата файла zlib только в png.
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

154. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 12:40 
> Хотя, что касается снаппи… Будем считать, что это было тёмное время.

Будем считать, что у кого-то в гугле NIH очень зудел.

> Нет, конечно, на сжатие он в 2 и более раз быстрее, но
> он ведь на распаковку медленнее zlib

Ващет быстрее. Но проблема в том что сравнимые алгоритмы либо
- Жмут лучше а распаковываются примерно как оно.
- Жмут примерно так же, но распаковываются быстрее.

Есть такая штука - pareto frontier. Грубо говоря, некая кривая, "степень сжатия vs скорость распаковки". Чем лучшем сжатие, тем, естественно, сложнее это потом быстро распаковывать из-за более продвинутого алгоритма и трюков формата. Проблема snappy в том что он находится не на этой кривой state of art'а, а где-то здорово под ней, не демонстрируя стоящих результатов вообще ни с каким выбором этих соотношений. И пойнт этого дизайна вызывает вопросы, если это нечто новое. Ну, предполагается что если кто-то новое дизайнит то оно чем-то лучше старого, чтоли. А так алгоритмов такого класса и без гугля было навалом, fastlz, quicklz, lzo, примерно в то же время lz4 вылупился, более длинный список - в lzbench можно посмотреть, "fast" кодеки.

> и жмёт при этом в 2 раза хуже.

Если это на примере тех XMLок с ratio в 4%, там очень специфичный результат. Когда инфо настолько избыточное, входной поток в декомпрессоре почти отсутствует и не рушит кэш, и алгоритм сильно втапливает. И чем лучше сжатие тем больше выигрыш на этом. Однако если коэффициент сжатия более вменяемый, скажем, 30-50%, такая халяве не наступает, входные данные достаточно интенсивно вымывают кэш, алгоритмы более-менее в равных условиях без дискриминаци по сжатию, и соотношения вообще совсем другие - snappy уделает zlib'а по скорости в пару раз на распаковке, просто потому что там декомпрессор тривиальный, в отличие от. Это неудачные/специфичные тестовые данные, сильно избыточнее типового случая.

> Но суть в том, что медленное ресурсоёмкое сжатие походит не везде и не для всего,

Поэтому для этого и были всякие LZO а потом и LZ4 - но у них есть фатальный недостаток: их накодил не гугл. Впрочем, этот недостаток оказался фатальным только для гугля - ну вот заурядный  и юзает в основном пара карманных проектов гугля.

> а так конечно может быть использовано любое сжатие где угодно. Но вот на уровне стандарта
> или формата файла zlib только в png.

Очень распостраненный формат сжатия на самом деле. Всякие gzip и ко - deflate. Или вон ресурсы и сэйвы HMMIII/IV. А на самом деле в силу халявной лицензии и существования дочерта лет - таки встречается в каждой дырке. И стандартной и не очень. В маздае installshield злибом сетапы паковал. "Installshield CAB". Это не то же самое что MS CAB, другой формат. Впрочем, последний тоже как один из вариантов алгоритма deflate допускает (называется MSZIP, но суть та же что и обычно). Эксплорер кстати .zip сразу жрет, куды ж он без поддержки inflate такой красивый? Или этого тоже мало?

Оно настолько распостранено - что классификаторы неизвестных файлов и проч даже ловят хидеры zlib и проч и выдают нечто типа "zlib-compressed data", как generic классификацию даже если они не знают формат лично. Либу нашару вывалили много лет назад - ей и попользовался все кому не лень, их легион. Достаточно попробовать zlib у себя в системе удалить целиком, посмотрев сколько от него depends...

Ответить | Правка | Наверх | Cообщить модератору

157. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 14:01 
>Ващет быстрее. Но проблема в том что сравнимые алгоритмы

Это на примере тестовых файлов предоставленных авторами snappy и результат бенчмарка предоставленного авторами snappy. Глубоко я не копал.

>Есть такая штука - pareto frontier. Грубо говоря, некая кривая, "степень сжатия vs скорость распаковки".

Только zstd сжимает как lzma9 (или даже лучше, часто ощутимо), даже быстрее lzma9, и распаковывает всё равно  в десятки раз быстрее (без преувеличения), в связи с чем меня всегда очень интересовало где это штука была и как это про неё забыли. А, может быть, она не имеет никакого отношения ко сжатию, и теоретические ограничения вызваны лишь текущими представлениями, нет?

> распостраненный формат сжатия

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

-Qt/kde
-glib/gtk
-cairo/mesa (те самые сжатые текстуры и тут пролезли? deflate для текстур использовать… изверги)
-библиотеки шрифтов
-cmake
-разные эмуляторы (они опционально поддерживают сжатые gzip файлы, по крайней мере, часть из них)
-libxml2 (не в курсе, с какими целями)
-python/ruby/perl/nodejs
-git/openssh/rsync и браузеры
-gnupg
-libavif и gpac (не знаю, насколько опционально)
-mkvtoolnix (допустим)
-gcc/gdb/llvm (без deflate тут никуда понятно *сарказм*)

И что-то всё, кончились пользователи deflate. Из 1300 приложений это не так и много.

Ответить | Правка | Наверх | Cообщить модератору

180. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 23:42 
> авторами snappy. Глубоко я не копал.

Верить авторам алгоритмов стоит с оговорками. Особенно если они из гугола.

> Только zstd сжимает как lzma9 (или даже лучше, часто ощутимо),

Вообще-то чаще всего таки хуже. Особенно с всеми фичами. Но не сильно. А распаковка *сильно* быстрее. Что и делает zstd интересным. И он соответственно ближе к этой кривой. Но все же он как движок сжатия в целом чуть менее плотный. Я их плотно срвнивал на очень разных данных с сравнимыми параметрами.

> даже быстрее lzma9, и распаковывает всё равно  в десятки раз быстрее (без преувеличения)

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

> она не имеет никакого отношения ко сжатию, и теоретические ограничения вызваны
> лишь текущими представлениями, нет?

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

>> распостраненный формат сжатия
> Я смотрел, что там от zlib зависит.

Дофига всего. Он в куче стандартов, форматов и программ на самом деле.

> Это не самый эффективный формат с любой стороны.

Словаря 32 кило на современных данных видите ли маловато бывает.

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

Просто он часто оказывается "good enough". Сжатие уже не позорное, скорость не как у LZMA все же, лицензия на шару, и есть под все что шевелится. А раньше особо и альтернатив не было. А так то zstd появился потому, что его автор нащупал почву для улучшений.

Если кто не знает, автор ZSTD теоретически должен был стать маркетологом. Практически его занесло на компрессионные ресурсы, ему вштырило, он возьми и сделай LZ4. Народ сказал - офигеть, дайте две! И чувак решил сменить карьеру, круто и всерьез. Сейчас он в Facebook эксперт по сжатию. А ты чего думаешь они к btrfs привинтили? (ага, девы оной тоже там есть).

> -gcc/gdb/llvm (без deflate тут никуда понятно *сарказм*)

Сжатие дебажных символов, etc. Оно опциональное вроде.

> И что-то всё, кончились пользователи deflate. Из 1300 приложений это не так и много.

Там еще inter-dependencies по цепочке, половина либ ими пользуется. Хотите TIFF читать? Оок, а zip - один из валидных субформатов. А сколько из 1300 программ в PNG умеет? Небось каждая вторая? Ну а без libpng это не получится и та depends на zlib ессно. Сюрприз!

Ответить | Правка | Наверх | Cообщить модератору

244. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 19-Мрт-21, 14:23 
>сколько из 1300 программ в PNG умеет

Штук 5, но в целом согласен. Более того, я подозреваю, что зависимость от zlib там много где может быть именно из-за png. У tiff поддержка zlib/lzma/zstd как раз опциональная, я тут рассматриваю только обязательные зависимости. По остальному мне нечего сообщить.

Ответить | Правка | Наверх | Cообщить модератору

249. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (249), 20-Мрт-21, 03:56 
>>сколько из 1300 программ в PNG умеет
> Штук 5,

Это, имхо, врядли. PNG ща много где юзается. Ну и без zlib он как бы ни о чем. Есть минимальные генераторы нежатых версий без этого, но вот прочитать произвольный png без zlib таки будет обломно.

> tiff поддержка zlib/lzma/zstd как раз опциональная,

Настолько же как в PNG. Вы можете записать PNG без сжатия (некая кантата с чексуммами все же будет все-равно, но при желании минимальная генерация PNG решается без zlib в зависимостях).

А если произвольный файл захотеть открыть - и там и там *может* (но не обязан, я нежатые PNG и в диком виде встречал) быть пожат zlib. И если это было так - ну вы и обломаетесь. Чем облом в одном и другом случае так уж отличается?

> я тут рассматриваю только обязательные зависимости. По остальному мне нечего сообщить.

Возможно скроить нежатый png без zlib в обязаловку. Ну, примерно как нежатый тифф. И прочитать его тоже без zlib соответственно.

Ответить | Правка | Наверх | Cообщить модератору

25. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +3 +/–
Сообщение от Аноним (25), 17-Мрт-21, 17:24 
brotli почему-то до сих пор по умолчанию нету в nginx, и многие забывают его поставить.
Про бесплатность трафика не соглашусь, это бесплатно только для пользователя и для сайтов с трафиком ≤1ТБ (обычно до 1 ТБ бесплатно у многих хостингов).
На amazon aws 1 ГБ стоит $0.09 (первый 1 ГБ бесплатен). То есть 6500₽ за 1 ТБ.
На google cloud 1 ГБ стоит $0.06.
Несмотря на цены, почему-то aws много кто (вне СНГ) использует.
На digital ocean 1 ГБ стоит $0.01 (после 1000ГБ).
На hetzenr у vps после бесплатных 20 ТБ 1 терабайт стоит всего лишь €1.19. У выделенных с 10 Гбит/с после 20 ТБ так же.
На hetzner у выделенных серверов с 1 Гбит/с бесплатный неограниченный трафик.
У Селектел 1 ГБ = 1.0₽.
Кстати, безлимитный 1 Гбит/с в России находил только за 20000—25000₽ в месяц (всех обыскал).
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

45. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 17-Мрт-21, 21:24 
Бротли дебильноват с архитектурной точки зрения, т.к. юзает огромный статистический текстовый словарь. Хренов на мобильных платформах и для больших бинарных файлов. Короче, это для веб-доставки HTML+JS, но не алгоритм общего применения.
Ответить | Правка | Наверх | Cообщить модератору

53. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Анонимленьлогиниться (?), 17-Мрт-21, 22:07 
Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов.. Пока разве что curl поддерживает zstd http compression.
Ответить | Правка | Наверх | Cообщить модератору

69. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 17-Мрт-21, 22:45 
> Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов.. Пока разве
> что curl поддерживает zstd http compression.

Оно мультитридинг научилось или будем шило на мыло опять менять, как с заменов JPEG на корявый WEBP, не умеющий без прореживания цвета?

Ответить | Правка | Наверх | Cообщить модератору

78. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 17-Мрт-21, 22:56 
> Оно мультитридинг научилось или будем шило на мыло опять менять,

КМК мультитрединг скорее к апликухе больше.

> как с заменов JPEG на корявый WEBP, не умеющий без прореживания цвета?

Ничего страшного, AVIF их всех зохавает. Там это, кажется, учли. А так прикольный формат - даже, вот, анимации есть с неких пор. Но софтом поддерживается охренеть как: ffmpeg может выдать анимированный webp (да, так можно). Но вот проигрывать его или юзать как input не умеет. Write-only формат!!!1111 который понимается только хромом и, вроде, совсем новыми лисами с недавних пор. Остальной софт не одупляет, так что отредактировать это - ну, ой.

Ответить | Правка | Наверх | Cообщить модератору

80. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 17-Мрт-21, 23:03 
> Ничего страшного, AVIF их всех зохавает.

Да вообще не факт. Критически важно только для CDN, где уменьшение трафика картинок на 30% может быть актуальным. С другой стороны, на пережимание там в несколько раз больше выч. ресурсов тратиться будет. Эл-во вроде сильно дешевле не становится.

Ответить | Правка | Наверх | Cообщить модератору

83. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (81), 17-Мрт-21, 23:06 
> Да вообще не факт. Критически важно только для CDN, где уменьшение трафика
> картинок на 30% может быть актуальным. С другой стороны, на пережимание
> там в несколько раз больше выч. ресурсов тратиться будет. Эл-во вроде
> сильно дешевле не становится.

Кроме этого страницы еще быстрее грузиться видите ли будут. Особенно актуально вон тем мобильным юзерам на каком там еще GPRS который едва достреливает.

Ответить | Правка | Наверх | Cообщить модератору

87. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 17-Мрт-21, 23:13 
А что меньше батарею жрёт? Аппаратный декодер JPEG или AVIF, который есть у... скольких процентов?
Ответить | Правка | Наверх | Cообщить модератору

121. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 05:04 
> А что меньше батарею жрёт? Аппаратный декодер JPEG или AVIF, который есть у...
> скольких процентов?

Декодирование картинок обчыно не является сушественным процентом времяпровождения системы, по поводу чего я готов поспорить с тем что этот вопрос вообще достоин внимания. Ну разве что какую-нибудь огроменную мегаанимацию на дофига мегов декодировать (я не смотрел сделали ли в спеках AVIF анимации). Но это уже экзотика. В всех остальных случаях это не особая проблема.

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

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

Ответить | Правка | Наверх | Cообщить модератору

128. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 18-Мрт-21, 05:26 
> Декодирование картинок обчыно не является сушественным процентом времяпровождения системы

Декодирование сжатого потока тоже не является, но его одноко же зачем-то оптимизируют (про это же новость?)... и, не стоит забывать про серверы, эти картинки кто-то же ещё сжимает и аппаратных кодировщиков на серверах вроде ещё не придумали. Во сколько раз тормознее AV1 в сравнении с libjpeg-turbo?

Ответить | Правка | Наверх | Cообщить модератору

181. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 23:46 
> Декодирование сжатого потока тоже не является, но его одноко же зачем-то оптимизируют
> (про это же новость?)...

Когда у тебя 10 000 юзерей и им надо пожать ответ сервера - вот тут скорость уже начнет интересовать. Как и при распаковке 100500 гигов, ну там бэкапа какого-нибудь допустим.

> Во сколько раз тормознее AV1 в сравнении с libjpeg-turbo?

Да пофиг имхо - юзер файл будет дольше искать чем он кодироваться будет, так что не особо крутая проблема. Вот с _видео_ это уже да, AV1 таки неспешный. Впрочем, гитовую версию на эту тему пиляют жестко и разогнали основательно. Жмет то плотно! Бандвиз экономить ессно охота.

Ответить | Правка | Наверх | Cообщить модератору

186. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 00:25 
> Когда у тебя 10 000 юзерей и им надо пожать ответ сервера
> - вот тут скорость уже начнет интересовать. Как и при распаковке
> 100500 гигов, ну там бэкапа какого-нибудь допустим.

Так об чём и речь я вёл.

>> Во сколько раз тормознее AV1 в сравнении с libjpeg-turbo?
> Да пофиг имхо - юзер файл будет дольше искать чем он кодироваться
> будет, так что не особо крутая проблема.

Страдания на тему "я видосики посмотрела 15 минут и мой телефон стал горячим, это нормально?", а потом "через n-месяцев у него корпус треснул от вздувшейся батареи" ты ещё не слышал? Современные телефоны вообще стали высокотехнологичным неремонтопригодным ненадёжным мусором. Даже тот же размер лопат — "берите больше, чаще будете из рук ронять, мы же этому только рады". Да не надо мне про гориллы лечить, корпус разлетается чаще, я тут эту драму лично наблюдал у сестры - третья лопата за год, все относительно верхнего диапазона от одного южнокорейского производителя. Уже не выдержал, когда попросили через две недели после предыдущего опять данные перенести и сказал, что "сколько ты ещё их бить будешь? Под твою руку максимум 5 дюймов". Вот и программисты аналогичным дрочерством занимаются. Куда вы гоните этот зоопарк новых форматов, даже лучшая половина которых никогда не будет аппаратно реализована?

Ответить | Правка | Наверх | Cообщить модератору

205. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (205), 19-Мрт-21, 02:43 
> Так об чём и речь я вёл.

Ну так потому корпы и пилят сабж.

> Страдания на тему "я видосики посмотрела 15 минут и мой телефон стал горячим, это нормально?",

Он греется и еще по over 9000 поводов. Плюс-минус 1 пофиг. Но вы как раз можете выкинуть ваш одноразовый крап и купить новый, такой же одноразовый, с аппаратным декодером. Производители железа одобряют.

> а потом "через n-месяцев у него корпус треснул от вздувшейся батареи" ты ещё не слышал?

Бедные хомяки, накупили одноразовую гадость с спайварью и еще чем-то недовольны. Айда за новым, зря чтоли батарею несменную делали?! Но вы ж хотели чтобы это бумажное фуфло гнулось о ж...у в заднем кармане - ну и получайте. Заодно как раз декодер в новом аппаратный будет, спрашивайте в аптеках...

> Современные телефоны вообще стали высокотехнологичным неремонтопригодным ненадёжным мусором.

А это не те ли пользователи, покупающие всякий шит и ставящие кривые поделки от вебмакак этому способствовали?

> Даже тот же размер лопат — "берите больше, чаще будете из рук ронять, мы же этому только
> рады". Да не надо мне про гориллы лечить, корпус разлетается чаще,

Горилы тоже ухитряются раскокать. Физику не на...шь. Если нечто стекло, оно таки относительно хрупкое. А, вы хотели дисплей хитрой формы, с заподвыподвертом? Может еще и оригинальный? Вот и заплатите за него 50% нового девайса. А кули - такую дисплейную сборку только производитель аппарата и умеет.

> Куда вы гоните этот зоопарк новых форматов, даже лучшая половина которых

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

> никогда не будет аппаратно реализована?

В случае AV1 - вон та куча производителей железа вписались в проект не для красоты. Спецом для них есть забавная опция сборки - RTC (real-time вариант кодека). Там забавные ограничения. Типа плавучку не использовать, RAM не жрать, и вообще. Догадываешься почему? Этот вариант подразумевает транстялцию в аппаратный блок. И уже есть чипы с поддержкой AV1. Да что там, даже новые десктопные видяхи. И нвидия и амд. Интель тоже вроде в новых процах сделал. Зря они чтоли туда вписались?

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

218. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –1 +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 07:23 
> Бедные хомяки, накупили одноразовую гадость с спайварью и еще чем-то недовольны.

Давай, в студию модели без спайвари, милый.

> В случае AV1 - вон та куча производителей железа вписались в проект не для красоты.

Про него я даже не сомневаюсь. Линуксоидам же опять страдать 10 лет без аппаратной поддержки. Я уже не говорю о том, что даже сейчас кодирование готового видосика зачастую дольше монтажа идёт.

> А это не те ли пользователи, покупающие всякий шит и ставящие кривые поделки от вебмакак этому способствовали?

А писатели кода кто? Тут половина анонимусов вебмакакингом занимается.

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

235. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 13:21 
> Давай, в студию модели без спайвари, милый.

Nokia N900 (из винтажных), motorola droid если maemo leste вкорячить (помощнее, клава лучше), pinephone (из более новых)... ах, не хомячненько? В фантик не завернуто? И вообще может повозиться потребоваться? Ну пардон, все и сразу - не бывает! А хорошего - понемногу. Ну а вы в вашем праве бегать с своим цифровым ошейником и радоваться автоматическому штрафу по геолокации, или что вы там предпочитаете. Папуасы с блестящими бусами и тифозным одеялом от "доброго" белого человека.

> Про него я даже не сомневаюсь. Линуксоидам же опять страдать 10 лет
> без аппаратной поддержки.

Да мне класть, на десктопе системный проц 1080p жует на раз, на ноуте 720p с ютубовским битрейтом тоже катит. А если аппаратную поддержку приспичит так что вот прям спать не смогу, амд уже это вроде пилит как раз. Ну, вот, GPUшку новую амдшную куплю тогда. Пока лениво - и так играется, а для остального и того что есть хватает выше крыши.

> Я уже не говорю о том, что даже сейчас кодирование готового видосика зачастую
> дольше монтажа идёт.

Так это ж не я его кодирую а компьютер. Раньше сроду на ночь оставляли перекодирование на ночь, я и сейчас не обломлюсь batch в фон отправить, а закончится - ну, когда-то закончится, какая мне разница, я его караулить не собираюсь все-равно. Это именно плотное "финальное" сжатие, когда хочется потом это выложить и смотреть с маргинальным битрейтом и проч.

> А писатели кода кто? Тут половина анонимусов вебмакакингом занимается.

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

Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

237. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 13:31 
Да-да, ты ещё не забудь вспомнить первый линуксофон. Где-то у меня валяется, так ни раз и не звонил через него толком. На разработку прошивки забили, разрабов фактически кинули. Там ни спайвари, ни рабочего софта не было.
Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

250. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –1 +/–
Сообщение от Аноним (-), 20-Мрт-21, 04:04 
> Да-да, ты ещё не забудь вспомнить первый линуксофон. Где-то у меня валяется,
> так ни раз и не звонил через него толком. На разработку прошивки забили,
> разрабов фактически кинули. Там ни спайвари, ни рабочего софта не было.

А какое-нибудь Maemo не только живое и софт до сих пор обновляется, но и вон там в сторонке Maemo Leste прикольный народ пиляет. А кто там кого кинул можно еще поспорить, глядя на то как мусорное ведро лихо "бэкапит" пароль от точки доступа на свой сервак, а эпл вообще неюзабелен без активации. О том что у них тотал контроль и говорить неудобно. Захотят да и выключат всем неугодным ифоны к хренам. Они там единственная и непререкаемая ауторити, а остальные как максиуму папуасы с иллюзией контроля над происходящим. Если кому нравится вот так - это его право, но тогда чего ныть что начинают откровенно держать за дурака? Денег много не бывает, так что лоха логично доить комплексно. Так что незаменяемая батарейка - мастхэв! А крякнутый при ее опухании экран - фича :)

Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

90. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 17-Мрт-21, 23:20 
Avif шляпа с любой стороны -- дефективный формат исключительно для экономии трафика на мобильниках. Для сжатия изображений vp9/av1 и h265 подходят ещё меньше vp8(чёртовы лестницы на градиентах!). Я видел текущие результаты jpeg-xl, и похоже он всех захавает. Потому что по качеству картинки он намного выше jpeg и не имеет артефактов вносимых видеокодеками. А размер файла меньше. Не "отличить от оригинала" будет на 25% меньше чем у жпег (у жпег это около 50% от лосслесс), так ещё и мусор весь скроет.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

122. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 05:11 
> Avif шляпа с любой стороны -- дефективный формат исключительно для экономии трафика
> на мобильниках. Для сжатия изображений vp9/av1 и h265 подходят ещё меньше
> vp8(чёртовы лестницы на градиентах!).

Не догоняю какие к тому фундаментальные предпосылки. У av1 самого по себе очень крутое и сильное кодирование, и он умеет и без subsampling и high-bd, так что лестницы быть не обязаны.

И у него есть 1 жирный плюс: либа для декодирования по сути уже в браузере.

> Я видел текущие результаты jpeg-xl, и похоже он всех захавает.

Когда и если - тогда и поговорим. Для него еще либу отдельно надо переть. Тогда как AV1 фокс и хром уже жрут и декоднуть по сути I-frame оного - им в общем то почти ничего не стоит, уже все по сути на месте. И патентами не обложено. А вот в webp был тупняк, только 4:2:2 и 8-bit, это ограничение VP8. Он другое не умел тупо.

> (у жпег это около 50% от лосслесс), так ещё и мусор весь скроет.

При том этим мусором как обычно окажутся какие-нибудь мелкие детали. Потом еще окажется что дятлы из jpeg патенты продолбали, так что в браузеры не попадет чуть менее чем никогда (ждать 25 лет всем впадлу, извините). Или до них после смачного пинка с AV1 стало доходить где все их патентных троллей видали?

Ответить | Правка | Наверх | Cообщить модератору

150. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 12:11 
Нет, "мусор" это грязные артефакты lossy-lossy кодирования, например. Vp8 вместе с ними теряет детали, да. А av1, помимо скрытия деталей, разбавляет всё жутчайшим мылом и неспособностью определить контур (что проявляется и на vp8, только куда в меньшей мере), из-за чего изображение превращается черте во что, ещё и половину цвета теряет (при этом, webp, несмотря на прореживание цвета, умудряется не потерять цвета).
Ответить | Правка | Наверх | Cообщить модератору

182. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 23:52 
> Нет, "мусор" это грязные артефакты lossy-lossy кодирования, например.

У AV1 во первых артефакты очень не паливные, а во вторых есть lossless режим, насколько я помню. И если в VP8 радости с него сильно меньше из-за 8bit с 4:2:2 YUV т.к. это единственное что VP8 умел как формат, то AV1 в этом аспекте сильно продвинутее (это упущение еще в VP9 исправили).

> Vp8 вместе с ними теряет детали, да. А av1, помимо скрытия деталей, разбавляет всё жутчайшим
> мылом и неспособностью определить контур

Само по себе это ниоткуда не следует опять же. Там на самом деле очень сильные алгоритмы, а какой-нибудь CDEF как раз артефакты гасит что надо. Не видев ориганил вообще хрен поймешь в чем прикол. Даже блин в стопкадре сильно сжатого видео.

> ещё и половину цвета теряет (при этом, webp, несмотря на прореживание
> цвета, умудряется не потерять цвета).

Это у вас видимо что-то с конверсией в YUV и может даже 4:2:2 low bit depth если прога протупила. FFmpeg в частности этим страдает. Очень стебно получается когда _некоторые_ видео в VP9 лучше AV1 выглядят, из за вот этого вот. Но это косяк ffmpeg'а, его пока просто не обучили кодировать в HBD/sRGB colorpace/etc/etc.

Ответить | Правка | Наверх | Cообщить модератору

243. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 19-Мрт-21, 14:16 
Я не отрицаю, что для такого битрейта результат очень впечатляющий. Но av1 реально вымывает детали (чёрное на тёмном особенно страдает) и перерисовывает части изображения, что вкупе с неспособностью детектить края (и я так смотрю это так во всех реализациях кодеров, libaom просто наиболее эффективный и меньше артефактов выдаёт) приводит к значительным искажениям, которые сразу режут глаз. Допустим, контур чёрный, и тут полоса в 5 белых пикселей выходит за него.

Ну это что такое? И это state of the art? Jctvc 10 летней давности справляется намного, намного лучше! Хотя размытая полоса светлых пикселей толщиной примерно в 0.3 пикселя есть и у него, но она хотя бы прозрачная и не такая толстая. И части изображения не перерисовываются, Тёмные участки изображения не исчезают даже на в разы меньшем битрейте…

А что касается цветов, это, возможно, из-за проблем с rgb, да. Но дело не только в ffmpeg -- libwebp от него не зависит, но у него ровно та же беда. При этом, у кодера webp есть параметр use-sharp-yuv, и вот он исправляет цвета, и, по-моему, даже избавляет их от прореживания (jpeg-xl ощутимо их прореживает с понижением битрейта). В bpg, я заметил, это искажение цветов убирает параметр colorspace=rgb (кодирует при этом аж на треть дольше), а в libaom я такого что-то не вижу. Это всё грустно, в jpeg при этом всё нормально с цветами и никаких искажений. Это не похоже на баг, поскольку проявляется во всех приложениях. На самых разных файлах, и это искажение цвета очень ощутимое.

Ответить | Правка | Наверх | Cообщить модератору

251. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 20-Мрт-21, 04:32 
> Я не отрицаю, что для такого битрейта результат очень впечатляющий.

У него в принципе очень крутое соотношение битрейт-качество. Для этого и делался.

> Но av1 реально вымывает детали (чёрное на тёмном особенно страдает)

Весь пойнт lossy сжатия - выкинуть то что не видно без палива. Если хотелось не это - ну, av1 и в лосслесс умеет. AVIF по наследству вроде тоже. А то что размер файла не такой гламурный, ну так за перфекционизм придется платить.

> и перерисовывает части изображения,

Любой lossy кодек выдает изображение отличающееся от оригинала. Более того - весь пойнт метрик типа SSIM нечто типа количественной оценки этсамого. И вопрос соответственно сводится к соотношению битрейт/качество, которое у AV1 и AVIF весьма непозорные и покрывают всю палитру от нечто для GPRS линков до lossless. И да, вон там на скрине - муть по-моему не у AV1, а? Спасибо тому кто до ресурса по компрессии дошел и раскопал там это.

> что вкупе с неспособностью детектить края (и я так смотрю
> это так во всех реализациях кодеров,

Вообще-то если кто не заметил, вон там на скрине края у AVIF проработаны сильно лучше конкурентов... у него как раз формат позволяет это все обыграть.

> libaom просто наиболее эффективный и меньше артефактов выдаёт)

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

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

На вон той фотке глаз режет что угодно кроме AVIF-а, имхо...

> Допустим, контур чёрный, и тут полоса в 5 белых пикселей выходит за него.

Бред сивой кобылы. В нормальном виде он на этом сделает мелкие блоки + CDEF'ом еще более правдоподобно закодит нежели остальные. Они так то все block based, а cdef очень неглупый хак от гуру в процессинге картинок типа Монти ващет, это на основе фичи из Daala, кажется, но потом еще совместно толпой доработано.

> Ну это что такое? И это state of the art?

Ну, э, как насчет воспроизводимого теста где вашу сказку увидеть вообще можно? Ну там скрин проблемы, исходную картинку, копипаст команды энкодинга? Хочу вообще посмотреть на границу 5 пикселов слепленую AV1 и посмотреть что там вообще было.

> Jctvc 10 летней давности справляется намного, намного лучше!

1) Пруф? С скринами side by side и воспроизводимым тестом?
2) Это на основе H.265? Тогда в браузерах этого не будет. Хотя вы можете оплатить всей планете патенты, но на рокфеллера вы не похожи.
3) без поддержки браузерами ради чего весь этот танец с бубном вообще?

> хотя бы прозрачная и не такая толстая. И части изображения не
> перерисовываются, Тёмные участки изображения не исчезают даже на в разы
> меньшем битрейте…

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

> А что касается цветов, это, возможно, из-за проблем с rgb, да. Но
> дело не только в ffmpeg -- libwebp от него не зависит,

Libwebp by design умеет кодировать только в intra-VP8. Со всеми лимитами того формата.

> но у него ровно та же беда.

А VP8 внезапно ничего кроме YUV 4:2:2 и не умел никогда. На уровне своих форматов, о великий гуру! Собссно в AVIF это вроде бы учли. Как и в VP9/AV1, где в формате есть HBD и варианты без субсэмплинга и даже с sRGB. Для VP9 в ffmpeg это работает, для av1 вроде не прикрутили еще, но родной кодер av1 все это ессно умеет.

Грубо говоря фичи формата одно, их прикрученность к ffmpeg и прочему софту - другое.

> При этом, у кодера webp есть параметр use-sharp-yuv, и вот он исправляет цвета, и, по-моему,
> даже избавляет их от прореживания

Как он их может избавлять если VP8 отродясь ничего кроме YUV в 422 не умел? И sRGB ему не светит, что, таки, обречено несколько похабить комповые скриншоты с мелким цветным контрастным текстом и проч. Хотя на фотах особенно не видно, собственно, 422 делался телевизионщиками под real world контент.

> (jpeg-xl ощутимо их прореживает с понижением битрейта).

Чудес не бывает, квантизация грубеет.

> В bpg, я заметил, это искажение цветов убирает параметр colorspace=rgb

Сразу видно computer-generated картинку. Которые, для начала, не основной юзкейс для photo-realistic кодеров. Извините, всех напрягают огроменный фоты которые юзери льют, а не скрины полутора хикки-извращенцев с какой там еще мангой.

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

На самом деле зависит от. Варианты кодирования без subsampling появились сильно опосля и опциональны, а на размере как вон там AV1 был он вообще выглядит как непонятная куча квадратиков.

> Это не похоже на баг, поскольку проявляется во всех приложениях. На самых разных файлах, и
> это искажение цвета очень ощутимое.

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

Ответить | Правка | Наверх | Cообщить модератору

264. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 21-Мрт-21, 01:47 
Субсамплинг вообще ни при чём, и, уж тем более, если исходное изображение и так 420. Слишком много цитат, и ты неправ практически в каждой из них, вообще непонятно к чему ты это всё написал. Ты нормальный? Сними розовые очки. Как vp8 качественно не кодирует, так и vp9 кодирует ещё хуже, а av1 это развитие vp9. У libaom версия 2020-11-25 v2.0.1 и в прошлый раз было ровно то же самое, вряд ли что-то изменилось.

Короче
https://i.postimg.cc/3RvRD3Hw/out1.png
https://i.postimg.cc/Cx9pnkMj/out2.png

Размеры не может показать для bpg и jxl, но по размерам
bpg27~avif60
bpg35~avif30

Ответить | Правка | Наверх | Cообщить модератору

265. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (265), 21-Мрт-21, 06:25 
> Субсамплинг вообще ни при чём, и, уж тем более, если исходное изображение и так 420.

Тогда и терять нечего, по большому счету.

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

Забойный аргумент правоты, что сказать.

> Ты нормальный? Сними розовые очки. Как vp8 качественно не кодирует, так
> и vp9 кодирует ещё хуже

Вопрос про нормальность возвращается автору. Если у вас VP9 кодирует хуже VP8 вы делаете что-то не так. Про tune-content=screen для вашей хикки-гадости вы тоже видимо не доперли, очень типично для "гуру кодирования" с характерным матерьяльцем.

> а av1 это развитие vp9.

С добавлениям из thor и daala а также достаточно уникальными технологиями типа CDEF, ранее вообще нигде не существовашими.

> https://i.postimg.cc/3RvRD3Hw/out1.png
> https://i.postimg.cc/Cx9pnkMj/out2.png

Где командлайны? Ну и я угадал - хикки с их "видео" матерьяльцем детектятся влет. И хикки не пробовали VP9 и AV1 врубать режим для screen контента? Ваша хрень - вообще не видео по большому счету. Рисованая или computer-generated анимация - да. Видео - черта с два! Нормальные люди под видео подразумевают нечто вообще совсем другое.

И эффективность сжатия этой лабуды по большому счету интересует полутора хикки с варезом. Это точно не основной контент для кодеков. Мне например плевать как он жмется.

> Размеры не может показать для bpg и jxl, но по размерам

Давайте в следующий раз обсуждать _видео_ кодеки на примере _видео_? А photo-realistic кодеки - на фотографическом материале? А то как пример леночки показал там как раз таки полный порядок. А ваши дерганые анимашки - не фото и не видео, для начала. Так, графика какая-то.

Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

270. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 21-Мрт-21, 12:17 
Ну т.е. оскорбления -- это всё, на что ты способен? Ясно, понятно. Я показал тебе, что видеокодеки полное и абсолютное уг для графики (и это только маленький пример, есть куча других) и ты начал маняврировать. Видео это не только фильмы которые можно замылить (а это всё, чем сегодня занимаются это кодеки даже на высоком битрейте), но и CGI. Да и для фильмов они уг. Да, VP8 тоже меньше мылит видео на достаточном битрейте, лестницы градиентов на vp9 никуда не делись, а av1 выглядит всё так же убого в сравнении с h265 (который тоже мыло ещё то из-за того же sao) и h265 при этом выдаёт максимально чётенькую картинку при появлении мелких деталей в кадре. Требования к битрейту при этом взлетают до небес, но ни в одном из кодеков я ещё не видел такой чёткой картинки в фильмах -- фильм был пятилетней давности, снятый на 4к (ALEXA XT по-моему, старая камера уже тоже). Этот кодек позволяет в полной мере использовать высокий битрейт. Гугло же думает только об экономии и его не заботит комфорт зрителя, как и нетфликс и остальных шилей. Все пользователи уже отстегнули роялти мпегу и по несколько раз в каждой железке, ничто не мешает им использовать ИП. Но жадные нетфликсы жлобятся перечислять гроши за качественно разработанный кодек (при этом у нетфликса качество от h265 заметно выросло из того что я видел).
Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

118. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (118), 18-Мрт-21, 04:35 
есть еще совсем новый jpeg xl
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

138. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Анонимленьлогиниться (?), 18-Мрт-21, 09:12 
> есть еще совсем новый jpeg xl

И что там с патентами? После истории с gif и патентами на LZW, когда пришлось проблему срочно затыкать всякими libungif (помните такой? Я вот да, пишем формально gif, но не сжимаем) и изобретением png, дураков связываться с насмерть запатентованными алгоритмами с требованием платить куче консорциумов бабло за каждую релизацию кодера или декодера как бы нет. Т.е. там где необходимо свяжуться, но в свободном вебе - обойдутся.

Jpeg 2000 кстати так и не взлетел, почему Jpeg XL должен? Проще взять AVIF, там ксть и нормальные свободные реализации декодера (libaom), гарантии отсутствия проблем с патентами и прочее.

Ответить | Правка | Наверх | Cообщить модератору

151. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 12:25 
Глупости не говорите. Jpeg2k это тоже вейвлет кодирование, оно очень неплохо работает для сжатия без потерь, но и только. Jpeg xl позволяет делать очень сильное и качественное сжатие без искажений, avif это только искажения и потеря деталей. На низких битрейтах это выгодно, да. Но у нас до сих пор нет кодека для качественного кодирования, выбор до сих пор между jpeg (при всех его недостатках) и png (при всех его недостатках), и, кроме того, jpeg при кодировании lossy-lossy не очень хорошо справляется.
Ответить | Правка | Наверх | Cообщить модератору

159. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Анонимленьлогиниться (?), 18-Мрт-21, 15:49 
> Глупости не говорите. Jpeg2k это тоже вейвлет кодирование, оно очень неплохо работает
> для сжатия без потерь, но и только. Jpeg xl позволяет делать

Это совсем не то, что заявляли авторы 2k и какие картинки в примеры они выводили. Но индустрия не взяла.

Ну в 2k хотя бы DCT, а не вейвлеты. Я помню кучу экспериментальных кодеков на вейвлетах, в 200х годах это была очень популярная тема - в т.ч. видео кодеки экспериментальные были. Не взлетел ни один. Да, блоки явно не лезут, а что делать с потерей четкости - так и не нашлось решения. Артефакты вейвлет-сжатия на практике оказались менее приятными.

> очень сильное и качественное сжатие без искажений, avif это только искажения
> и потеря деталей. На низких битрейтах это выгодно, да. Но у

А почему вы так считаете? Повысьте битрейт. Как раз AVIF отлично масштабируется вверх. Это в Jpeg XL чуть битрейт понизишь, и артефакты глаза колят.

https://encode.su/attachment.php?attachmentid=7765&d=1594548444

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

> нас до сих пор нет кодека для качественного кодирования, выбор до
> сих пор между jpeg (при всех его недостатках) и png (при
> всех его недостатках), и, кроме того, jpeg при кодировании lossy-lossy не
> очень хорошо справляется.

Вот то что lossy-lossy кодирвание в JPEG XL хорошее, это я знаю: но это не то чтобы так уж востребовано, просто авторы специально заточили его под такой юзкейз, чтобы показать, что если им пережать 1000 раз подряд, качество почти не изменится. Но это.. не очень жизненный пример, на самом деле.

Ответить | Правка | Наверх | Cообщить модератору

163. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 16:48 
>не очень жизненный пример

Не только в себя, любое лосси перекодирование выглядит очень хорошо. Если не жабить битрейт. Если жабить, то оно выглядит кошмарно (я надеюсь, над этим ещё поработают) в сравнении с avif(libaom) и в частности в сравнении с bpg(jctvc). А это значит, можно уже убитый жпег перекодировать в жпег-хл без артефактов, можно при этом сделать и ресайз (более качественный). Чисто практически bpg очень значительно превосходит всех конкурентов как в плане сжатия файлов, так и в плане качества результата. Он нормально определяет края (удивительно), сохраняет цвета при работе в rgb (у его кодировщика есть такой параметр), позволяет различные варианты субсамплинга. На очень сильном сжатии (avif_q70-bpg_q25) теряет намного меньше деталей и ближе к оригиналу, меньше искажений. После этого на avif смотреть тошно, но увы, webp ещё хуже (на любом битрейте).

Ответить | Правка | Наверх | Cообщить модератору

164. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 16:56 
И это

>AVIF хорош всегда,

Нет, он артефачит и не может нормально детектить края, перерисовывает части изображения, портит цвета. На любом битрейте. Разве что с градиентами получше вебп. Жпег-хл лишён всех этих недостатков, хоть и не позволяет жабить битрейт.

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

183. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 00:04 
> Нет, он артефачит и не может нормально детектить края,

Как раз технологически там для этого очень даже приличные вещи типа CDEF есть. И никаких проблем проработать границы нет, блоки переменного размера.

А чтобы lossless - там вообще +1 слой residuals (ошибок) кодируют относительно prediction. Файл ессно крупнее становится.

> перерисовывает части изображения, портит цвета.

Совершенно не обязано происходить. Скорее неоптимальности реализации кодека или того как либу подцепили.

> На любом битрейте. Разве что с градиентами получше вебп.
> Жпег-хл лишён всех этих недостатков, хоть и не позволяет жабить битрейт.

Если он не позволяет жабить битрейт, зачем он тогда? Пойнт сжатия с потерями чтобы было мелким но почти как оригинал. Иначе смысл?

Ответить | Правка | Наверх | Cообщить модератору

245. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 19-Мрт-21, 14:43 
Файл и получается более мелким. Вот на давешнем примере:

avif100=900kb
avif90=225kb (меньше нет смысла, но все дефекты за исключением адового замыливания проявляются и на q99)
jpeg95=430kb
jpegxl100=700kb
jpegxl96=295kb
jpegxl95=259kb (есть едва заметное прореживание цвета)
webp95=305kb (и скажем честно он выглядит не сильно лучше jpeg90(332kb))

Пока, к сожалению, совершенно не вариант, и для lossless кодирования avif тоже не подходит. Это libaom, остальные в раза 2 хуже.

Ответить | Правка | Наверх | Cообщить модератору

247. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 19-Мрт-21, 17:15 
Avif99=402kb кстати, но реально он выглядит хуже максимально (без видимых искажений, на исходном файле) пережатого jpeg с 380kb. Т.е. лучше он уже просто не может сам по себе.
Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

252. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 20-Мрт-21, 04:38 
> Файл и получается более мелким.

Але, гараж, если хочется качество сравнивать, в lossy варианте размер файлов должен быть сравнимый. Иначе это сравнения шила с мылом.

Как бы размер файла при lossy - "любой". От почти ноль до довольно жирного. Чем больше выкинуто тем меньше файл и хуже качество. И очевидно сравнивать разные кодеки имеет смысл только подогнав размер картинки до сравнимого и сравнив качество. Или как вариант пытаться догнать метрики до одинаковых (скажем одинаковая ошибка SSIM) и сравнить при этом размер файлов.

Если что - абстрактное качество=95 в нотациях одного и другого кодека вообще не обязано совпадать. Разработчики под этим могут иметь в виду что угодно и как оно там на внутренности действует вообще зависит от причуд конкретных разработчиков. Но вон те соотношения иллюстрируют соотношения сил, их в том виде не обманешь.

Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

203. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (203), 19-Мрт-21, 02:22 
Очень красноречивая картинка, спасибо. Avif рулит.
Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

236. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 13:25 
> Очень красноречивая картинка, спасибо. Avif рулит.

Очень красиво обмакнули в ушат того умника с его раржыпегом. Было бы странно если не рулил с таким набором технологий. А *peg в последнее время только ублажением патентных троллей занимается.

Ответить | Правка | Наверх | Cообщить модератору

266. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (265), 21-Мрт-21, 06:28 
При том секрет обмакивания раскрыт. Умник тестил фото и видео на рисованых анимашках. Ничерта умнее этот чудак не придумал.
Ответить | Правка | Наверх | Cообщить модератору

139. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Анонимленьлогиниться (?), 18-Мрт-21, 09:17 
>> Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов.. Пока разве
>> что curl поддерживает zstd http compression.
> Оно мультитридинг научилось или будем шило на мыло опять менять, как с
> заменов JPEG на корявый WEBP, не умеющий без прореживания цвета?

Это вопрос клиенту, использующему библиотеку (вы ведь понимаете, что в библиотеке автоматически активировать треды как бы нельзя)?

Штатная реализация zstandard умеет параллелится из коробки, посмотрите zstd -T. Отлично работает, напр. в 8 тредов реально почти в 8 раз быстрее.

Для декомпрессии параллельность не требуется, там и так 1 ГБ/с скорость разжатия. Быстрее только LZ4/LZO...

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

142. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 18-Мрт-21, 09:44 
> Для декомпрессии параллельность не требуется

Смеялся...

> Штатная реализация zstandard умеет параллелится из коробки

А вот моя ядерная реализация из ядра линукс не параллелится. Шта делать прикажете?

Ответить | Правка | Наверх | Cообщить модератору

152. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 12:27 
В ядре очень уж протухшие версии, у меня вот тоже вопрос -- почему?
Ответить | Правка | Наверх | Cообщить модератору

153. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 18-Мрт-21, 12:38 
> В ядре очень уж протухшие версии, у меня вот тоже вопрос --
> почему?

Там не протухшие, а собственные реализации. Как и всего остального, например тех же алгоритмов шифрования. Т.е. openssl может конечно и свой алгоритм использовать, но куда интереснее пробросить ядерную реализацию через драйвер с аппаратной поддержкой. Собственно, если память не изменяет, даже таких существует два метода проброса.

Ответить | Правка | Наверх | Cообщить модератору

156. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 12:44 
Очень плохо. Пока апстрим уходит на десятилетия вперёд (а также исправляет ошибки, что немаловажно), в ядре будет оставаться багованная копия доисторического кода.
Ответить | Правка | Наверх | Cообщить модератору

161. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 18-Мрт-21, 16:03 
> Очень плохо. Пока апстрим уходит на десятилетия вперёд (а также исправляет ошибки,
> что немаловажно), в ядре будет оставаться багованная копия доисторического кода.

Скорее наоборот. Там будет самая вылизанная. Твой уход на десятилетия вперёд никому в деле архивирования вообще ни разу не упёрся. Там нужны стабильность формата, надёжность реализации и оптимизированность уж в последнюю очередь. А фрагментированность того же LZMA/LZMA2 стала ярким примером цирка с конями про "уход на десятилетия без оглядки назад".

Ответить | Правка | Наверх | Cообщить модератору

272. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 21-Мрт-21, 18:32 
Long таки даёт ощутимую экономию раза в 3 - например, из файла 2.6гб получается файл 210мб, у стандартного zstd3 файл 428мб, у lzma9/7zultra файл 370мб (сжимает долго, дедуплицирует только то что рядом, копии файлов будут сжаты несколько раз). Умолчательной троечки (которая быстрая) достаточно чтобы сравниться с lrz и получить файл ещё меньше чем у lrz-lzma9 на типичном использовании (220мб). В частности, этой экономией можно воспользоваться в каких-нибудь initramfs (файлы по гигабайту и больше) или squashfs (медленно работает с lzma9 и сжатие очень плохое получается). У фекбука огромные ДЦ, он, также как и гугл, использует кастомное ПО и кастомные ядра с кастомными параметрами конфигурации. Вопросы формата при внутреннем использовании никого не интересуют, важна только эффективность. Если образ будет в 5 раз меньше, он будет быстрее передаваться и быстрее загружаться, этого достаточно, особенно, при таких объёмах. Эффективность повышается. Бонусом он ещё и меньше места займёт на стораджах. И это касается всех данных.
Ответить | Правка | Наверх | Cообщить модератору

274. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 21-Мрт-21, 22:43 
Как я понял, long режим с расширенным окном позволяет практически моментально дедуплицировать и пережать 2гб данных. Вот я сжимаю файлов на 4.7гб, zstd достаточно быстро выплёвывет 2.160гб файл, lrzip достаточно долго пакует, но выдаёт файл 1.175гб, при этом zpaq (не твиканый особо -- я не разбирался в параметрах) даёт 1.330гб и lrz-lzo 1.522гб. Неплохо бы zstd запихнуть в lrz, интереса для. В оригинале это был rar на 2.5гб.
Ответить | Правка | Наверх | Cообщить модератору

213. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 03:34 
> В ядре очень уж протухшие версии, у меня вот тоже вопрос -- почему?

В ядре сильно другие constraints. Вас же не устроит если ядро при каком-нибудь ауте памяти вылетит как апликуха, с вообще всем, правда? И так далее. Это и много чего еще заставляет ядерщиков юзать довольно кастомные реализации, не сильно похожие на general purpose либы предполагающие что вокруг есть операционка с типовыми facilities. А если это операционка как раз, унутрях кернела стандартного libc например ни разу не обязано быть, etc.

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

246. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 19-Мрт-21, 15:16 
Из-за подобной нерасторопности страдают пользователи. Причём, вполне вероятно, сам фейспук использует собственные патчи с более свежей версией.
Ответить | Правка | Наверх | Cообщить модератору

253. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 20-Мрт-21, 04:46 
> Из-за подобной нерасторопности страдают пользователи.

Ничего они не страдают - кернел threaded как черти что.

> Причём, вполне вероятно, сам фейспук использует собственные патчи с более свежей версией.

Это врядли. Такие вещи вне апстрима таскать чревато кучей грабель. Кернель - не гребаная юзермодовая апликуха, и наворачивать там такие facilities в обход апстрима весьма грабельно.

Ответить | Правка | Наверх | Cообщить модератору

160. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Анонимленьлогиниться (?), 18-Мрт-21, 15:53 
>> Для декомпрессии параллельность не требуется
> Смеялся...

Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?

>> Штатная реализация zstandard умеет параллелится из коробки
> А вот моя ядерная реализация из ядра линукс не параллелится. Шта делать
> прикажете?

Ну так вы же не можете затащить полноценную библиотеку в ядро. Все будут сильно против, и будут правы. там место урезанной реализации. А треды.. наверное, можно добавить, если это кто-то сделает. Главное что сам формат и алгоритм позволяют.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

162. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 18-Мрт-21, 16:08 
>>> Для декомпрессии параллельность не требуется
>> Смеялся...
> Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?

У меня домашний массив больше 400 выдаёт (обычный домашний NAS на базе старого пролиант микросервер). Упирается именно в скорость сжатия (ядерная реализация zstd), которое я использую в целях экономии места (те же фотки-равки на процентов 15 поджимаются, а это уже десятки гигов) и просто из-за того, что гигабитка банально у меня не тянет даже такой поток. Перейду на новое железо и там уже, думаю, это будет реальной скоростью по кабелю. Про промышленное применение я вообще молчу.

Ответить | Правка | Наверх | Cообщить модератору

168. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 18-Мрт-21, 18:37 
> Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?

Возмём средний ссд, сколько там, 3ГБ/с? А нет, уже 5 ГБ/с (чтение и запись), 15ГБ/с в 2019 только продемонстрировали. Производительность имеет значение.

Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

216. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 07:05 
>> Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?
> Возмём средний ссд, сколько там, 3ГБ/с? А нет, уже 5 ГБ/с (чтение
> и запись), 15ГБ/с в 2019 только продемонстрировали. Производительность имеет значение.

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


Ответить | Правка | Наверх | Cообщить модератору

228. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (7), 19-Мрт-21, 11:27 
Скорость ограничена только скоростью памяти, в 4 канальном режиме это порядка больше 100, и нынешние процессоры уже позволяют использовать память в 8-канальном режиме. Скорость интерфейса 10 летней давности именно 15GB/s, нынешняя ревизия интерфейса позволяет что-то там порядка 256GB/s. Цифры не всегда соответствуют по другим причинам. Optane там ещё жив?
Ответить | Правка | Наверх | Cообщить модератору

184. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Аноним (184), 19-Мрт-21, 00:17 
> Смеялся...

А теперь наша очередь. Обнаружен эксперт в алгоритмах от вебмакакинга!

Как мистер эксперт думает, во что ща упирается распаковка хорошего быстрого алго? А вот и неправильно! В RAM и cache miss. Проц достаточно быстро ворочается, хорошее алго на распаковку достаточно легкое. И все упирается в то что проц RAM ждет дофига если cache hit не случился. Откуда и дикий boost по скорости вон у того чудака с 3% ratio. Там входной поток почти не выносит кэш, все доступы к нему без cache miss - вот вам неиллюзорная накрутка перфоманса. На более вменяемых данных тот эксперт бенчмаркинга ессно получит совсем другие цифры и соотношения.

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

По той же причине ассемблерщикам слабо побить LZ4. А, собственно, в каком месте они профит могут извлечь? :)

> А вот моя ядерная реализация из ядра линукс не параллелится. Шта делать прикажете?

На распаковку это пофиг относительно. А так кернел умеет же в воркеры. И какой-нибудь btrfs по дефолту их по числу ядер вешает, например. Там и на сжатие и не только хватит. Это же касается и прочих ядерных facilities, ядро давно уже threaded как черти что.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

187. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 00:28 
> Что ожидается с многопоточности? А, загадить кэш кучей инстансов этого хлама...

Давай начнём с малого. Как кэш делится между ядрами?

Ответить | Правка | Наверх | Cообщить модератору

206. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 02:49 
> Давай начнём с малого. Как кэш делится между ядрами?

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

В любом случае, конкуренция нескольких потоков за дефицитный ресурс (RAM bandwidth) очень врядли может улучшить состояние дел. Вот испортить лишним оверхедом, дополнительными переключениями контекстов и вымыванием кэша - почему бы и нет?

Ответить | Правка | Наверх | Cообщить модератору

215. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 07:04 
По твоей теории, если всё упирается в ОЗУ, никакого проку от распараллеливания быть не должно, а он есть...
Ответить | Правка | Наверх | Cообщить модератору

238. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 13:31 
> По твоей теории, если всё упирается в ОЗУ, никакого проку от распараллеливания
> быть не должно, а он есть...

На распаковку, именно современного быстрого алгоритма - не особо. Если это нечто неоптимальное и тормозное унутрях - еще может быть. Но всякие LZ4 и прочие ZSTD сделаны так чтобы минимизировать это, будучи как можно быстрее на распаковку.

Ну и вообще - окружения разные бывают. Бредить многоядерностью круто. Но если я допустим кернель сжал ZSTD, оно запускается на вполне конкретном проце. Одном. И распаковывается там же. И хренли толку с той кучи ядер ЕСЛИ ОНИ ЕЩЕ НЕ ЗАБУТЯВЛЕНЫ?! Поэтому если алго тормоз - я буду туповэйить декомпресс кернеля. На каком-нибудь LZMA это вполне заметно даже на x86, а на ARM уже просто назойливо и неприятно. Но возможно вам больше нравится пыриться на графики, туповэйтя загрузку своих телевизоров и что там еще?

Ответить | Правка | Наверх | Cообщить модератору

239. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 13:33 
Ближе к телу, меньше абстрактных измышлений, разговор был конкретно про ядерную реализацию zstd.
Ответить | Правка | Наверх | Cообщить модератору

254. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 20-Мрт-21, 04:47 
> Ближе к телу, меньше абстрактных измышлений, разговор был конкретно про ядерную реализацию zstd.

Ядерная реализация используется в том числе и для распаковки кернела вроде.

Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

192. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 19-Мрт-21, 00:40 
> ядро давно уже threaded как черти что.

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

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

207. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 02:51 
> Мне кажется, вы путаете воркеры каких-нибудь файловых систем, вроде той же btrfs,
> которая данные делит на блоки и каждый блок отдельно сжимает и,
> если нужно, шифрует. Я же вёл речь про реализацию самого алгоритма.

Сам алгоритм может, конечно, сделать то же самое по смыслу, но вообще такая функциональность не только ему нужна и подход как у ядерщиков как раз логичнее смотрится. Хотя, конечно, можно самому таскать половину функциональности операционки и либ, nih штука злобная.

Ответить | Правка | Наверх | Cообщить модератору

61. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (58), 17-Мрт-21, 22:27 
Автор малость смухлевал так для повышения сжатия. В принципе это даже малость работает - ценой переноса данных заранее на клиент, в либу бротли с ее словарем. С zstd так тоже можно, как впрочем и с почти любым алго. Т.е. если zlib'у словарь заранее подпихать на стороне клиента он тоже лучше жать начнет. Но у него словарь 32 кило максимум - с современными вебмакаками это уже маловато, они либы на мегабайты хотят - у словаря склероз, сжатие страдает.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

71. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от timur.davletshin (ok), 17-Мрт-21, 22:46 
> Автор малость смухлевал так для повышения сжатия...

Спасибо, кэп )))

Ответить | Правка | Наверх | Cообщить модератору

52. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Анонимленьлогиниться (?), 17-Мрт-21, 22:05 
Что значит "забывают"? Так его не поставить по-человечески. Нет в репах - ни RHEL (включая rpmfusion), ни Debian, ни прочих не-серверных дистрибутивах. Компилять из сорцов, чтобы оно потом в usr/local болталось, нормально не управлялось, забывалось, ломалось при обновлении nginx и brotli (да-да, даже в рамках стабильного RHEL нынче доступны несколько веток nginx и появляются новые мажорные релизы)? Да нах это счастье надо. Будет распространяться нормально - будут ставить.

А пока текущая политика nginx "купите nginx plus, там это есть, а в обычном халявном nginx.. упс, катитесь подальше, нищебрoды" или какие-то еще причины мешают его нормально распространять штатно в дистрибутивах - так и будет.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

62. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Аноним (58), 17-Мрт-21, 22:29 
В смысле - не поставить?! А libbrotli1 в дебиане - это чего?
Ответить | Правка | Наверх | Cообщить модератору

137. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Анонимленьлогиниться (?), 18-Мрт-21, 09:05 
> В смысле - не поставить?! А libbrotli1 в дебиане - это чего?

Я не про libbrotli1, а про nginx-module-brotli. Что вам толку от либы, когда nginx с ней не собран?

Вы ничего такого не поставите из коробки, чтобы в nginx можно было поддержку brotli сжатия в дополнение к zlib включить.

Ответить | Правка | Наверх | Cообщить модератору

175. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от hefenud (ok), 18-Мрт-21, 22:34 
Ну я для себя и клиентов поддерживаю ppa в котором вместе с nginx'ом собираю и nginx-module-brotli, и некоторые еще необходимые мне модули которые не собирают ни в родных репах nginx'а, ни в репах Debian/Ubuntu.

И все ставится и обновляется совершенно штатно. При выходе свежей версии mainline у nginx обновляю пакет, дурное дело не хитрое

Ответить | Правка | Наверх | Cообщить модератору

223. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Анонимленьлогиниться (?), 19-Мрт-21, 10:35 
> Ну я для себя и клиентов поддерживаю ppa в котором вместе с
> nginx'ом собираю и nginx-module-brotli, и некоторые еще необходимые мне модули которые
> не собирают ни в родных репах nginx'а, ни в репах Debian/Ubuntu.
> И все ставится и обновляется совершенно штатно. При выходе свежей версии mainline
> у nginx обновляю пакет, дурное дело не хитрое

Что мешает выложить в апстрим дистрибутива, сделав доступным для всех пользователей дебиан, RHEL и тп? Почему же каждый для себя должен делать? Вот из таких мелочей все и складывается..

Ответить | Правка | Наверх | Cообщить модератору

224. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от hefenud (ok), 19-Мрт-21, 10:38 
Все и выложено и доступно, я же не из воздуха собираю.
И ppa общедоступный, ничто не мешает взять и добавить его или форкнуть его и собирать самому по готовому
Ответить | Правка | Наверх | Cообщить модератору

185. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (184), 19-Мрт-21, 00:18 
> Вы ничего такого не поставите из коробки, чтобы в nginx можно было
> поддержку brotli сжатия в дополнение к zlib включить.

Да собссно нжинкс не настолько сложно компилится, если это ну вот реально надо. Тоже мне проблему развели.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

79. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 17-Мрт-21, 22:57 
> Про бесплатность трафика не соглашусь, это бесплатно только для пользователя и для
> сайтов с трафиком ≤1ТБ

А попробуй стать гуглем - и узнаешь в чем прикол.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

220. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от пох. (?), 19-Мрт-21, 08:53 
>> Про бесплатность трафика не соглашусь, это бесплатно только для пользователя и для
>> сайтов с трафиком ≤1ТБ
> А попробуй стать гуглем - и узнаешь в чем прикол.

А нам-то что с того? Попробуешь, все равно не получится.

Да и гуглю оно больше для мороченья голов менеджерам менеджерами чем для чего-то еще. Да, в абсолютных числах это милионы, зал аплодирует (премию не дадут, в гугле не принято. дадут грамоту с подписью старшего менеджера). А по факту - 4% экономии. После того как миллионы вбуханы в прогибание под себя интернета и запихивание ненужнобротли всем в задницы (это даже если предположить что труд макаки ничего не стоит, что, безусловно, неверно - с учетом того, в скольки местах ненужное пришлось внедрять, и сколько высокооплачиваемых манагеров в этом задействовали).
А планомерно убирать ненужные гигабайты js и миллиарды картиночек - нее, это вот слишком сложно, и вообще на инновацию не тянет, грамоту не дадут.

Ответить | Правка | Наверх | Cообщить модератору

240. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 19-Мрт-21, 13:53 
> А нам-то что с того? Попробуешь, все равно не получится.

По другим причинам - ты не соберешь такую же распределенную штуку. Ну вот нет у тебя архитектов и инженеров для этого, и денег на них у тебя нет, на 10% от номинала они не пойдут к тебе. Но это другой аспект. Тем не менее, как-то вот получается что траф терабайтами оптом народ напрягает и это денег стоит. Васяны с своими несколькими тб в месяц, конечно, никого не напрягают - там какой % использования канала? Эвон сколько васянов можно оверсельнуть. Потому и "дешево". А попробуй duty ratio ближе к 100%, всегда - и тут окажется что условия уже совсем другие и стоит это эвон сколько. И тут уже вопрос сколько клиентов оно сервировать может такое.

> Да и гуглю оно больше для мороченья голов менеджерам менеджерами чем для чего-то еще.

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

> менеджера). А по факту - 4% экономии.

А по факту 4% в масштабах гугла это овердохрена и вообще, если профакивать 4% тут, 4% там, то вскоре это сольется до уровня мцст какого-нибудь. Акуле, пинать #%$ на рабочем месте все горазды.

> А планомерно убирать ненужные гигабайты js

JS являет собой крайне незначительный % трафика по сравнению с ютубовским видео. А вот когда вопрос в том что мы сегодня оптимизируем, вон те 4% или вон те 0.04% - гуглменеджеры таки не совсем дятлы и могут в управление ресурсами.

> и миллиарды картиночек - нее, это вот слишком сложно,

Они работают над этим! Чему пруфом - avif. А почему им это должно быть сложно, если они весь видеокодек сделали?! Поюзать его i-frames для картинок - когда он уже написан - ни в раз не проблема.

> и вообще на инновацию не тянет, грамоту не дадут.

Тю, avif и av1 в гугле в почете.

Ответить | Правка | Наверх | Cообщить модератору

113. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –3 +/–
Сообщение от Кочегар (ok), 18-Мрт-21, 02:15 
> Или я чего то не знаю

Правила русского языка, в соответствии с которым "чего-то" пишется через дефис.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

114. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +2 +/–
Сообщение от Аноним (7), 18-Мрт-21, 02:39 
>> Или я чего то не знаю
> Правила русского языка, в соответствии с которым "чего-то" пишется через дефис.

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

Ответить | Правка | Наверх | Cообщить модератору

115. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  –3 +/–
Сообщение от Кочегар (ok), 18-Мрт-21, 03:02 
>>> Или я чего то не знаю
>> Правила русского языка, в соответствии с которым "чего-то" пишется через дефис.
> Докапываться до орфографии как минимум неприлично. Это занятие для людей, у которых
> в жизни больше ничего нет.

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

Ответить | Правка | Наверх | Cообщить модератору

140. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +1 +/–
Сообщение от Ordu (ok), 18-Мрт-21, 09:34 
Езли тобе бизграматнасть мира выглядетт выкказываньем ниуваженья ктебе, та кем ты ся мниш, интиресно?
Ответить | Правка | Наверх | Cообщить модератору

148. "Первый стабильный выпуск zlib-ng, высокопроизводительного фо..."  +/–
Сообщение от Аноним (-), 18-Мрт-21, 11:50 
> Безграмотно писать — выказывать неуважение к собеседнику.

Ты саписетник штоли ? Нисмиши аднаклетачнае

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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