forum.opennet.ru

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

Оглавление

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

Скрыто модератором, Аноним (1), 14:38 , 17-Мрт-21, (1) –2
Уважаю zlib, никаких zlib-ng в моей системе не будет , Аноним (-), 14:42 , 17-Мрт-21, (3) –23 //

О да, 16-разрядные системы и несовместимых с ANSI C компиляторы это ваше все , Аноним (4), 14:52 , 17-Мрт-21, (4) +21 //

Ты такие слова знаешь, ну прям вааащее, Аноним (5), 15:02 , 17-Мрт-21, (5) –15
вообчето используются они , alexrayne (?), 16:33 , 17-Мрт-21, (14) –1 //

Старые версии zlib для таких систем никуда не денутся , Аноним (29), 18:01 , 17-Мрт-21, (29) +2

Да А где они Может там есть старая рабочая жаба Или нетскейп Где все это, Аноним (35), 19:16 , 17-Мрт-21, (35)

В архивах, которые несложно нагуглить , Аноним (29), 19:28 , 17-Мрт-21, (36)

Ногугли ка мне архив с нетскейпом который я смогу собрать под ппц, Аноним (-), 20:13 , 17-Мрт-21, (39)

А нетшкаф хоть когда-то был под ппц Чтобы что-то гуглить - это наверное должно , Аноним (-), 22:18 , 17-Мрт-21, (56)

ок, давай любой чтоб под арм или все, позиция ногуглю любой архив провалилась , Аноним (-), 19:00 , 18-Мрт-21, (169)

Так это, в демьяне под ARM браузеры собраны не хуже чем под все остальное Можеш, Аноним (178), 23:22 , 18-Мрт-21, (178)

Я не говорю о софте который у меня был до твого рождения, но ты даже популярные , Аноним (-), 03:32 , 19-Мрт-21, (212)

Проблемы мамонтов с PDP11 меня не интересуют Да вот как-то лис старинных версий , Аноним (-), 13:04 , 19-Мрт-21, (233)
p s опеннет конечно же испортил урлу, вводить надо с последним слэшом , Аноним (234), 13:07 , 19-Мрт-21, (234)

Нам всем очень интересно, что на твоей системе есть, а чего нет и не будет Прод, Аноним (135), 08:22 , 18-Мрт-21, (135) +1

Это конечно всё очень полезно, только zlib в основном из-за сжатия веб страниц ж, Аноним (7), 15:18 , 17-Мрт-21, (7) –4 //

Угу, гуглу это расскажи А то чего-то для них трафик основная статья расходов Д, Аноним (9), 15:33 , 17-Мрт-21, (9) +2 //

И все труды gzip множатся на ноль из за маленький изображений с весом более 1, Аноним (12), 16:09 , 17-Мрт-21, (12) +5 //

Для начала1 gzip в картинках вообще не встречается 2 гугл webp любит, там совс, Аноним (58), 22:20 , 17-Мрт-21, (58) –2

Расскажи это PNG , Аноним (179), 23:23 , 18-Мрт-21, (179) +2

deflate gzip Гзип как бы deflate некие свои хидеры А png это deflate , Аноним (-), 03:20 , 19-Мрт-21, (211) +1

Наверное не знаешь вообще ничего Все что ты видишь перед собой, в той или иной , Аноним (-), 17:02 , 17-Мрт-21, (21) //

Или же знаю по крайней мере больше тебя Во всяком случае, deflate очень медленн, Аноним (7), 17:08 , 17-Мрт-21, (23) –2 //

Ты даже не знаешь как работает пнг, Аноним (-), 17:53 , 17-Мрт-21, (27)

Может быть Это не делает deflate менее опциональным , Аноним (7), 18:18 , 17-Мрт-21, (31) –3

Спасибо за ыкспердное мнение , Аноним (35), 19:14 , 17-Мрт-21, (34)

Таки можно приколоться и сделать нежатый png Или RLE-only Однако для декодиров, Аноним (58), 22:22 , 17-Мрт-21, (59)

Я ещё могу понять, что неэффективный тут по коэффициенту сжатия всё равно всех , topin89 (ok), 02:06 , 27-Мрт-21, (280)

На сжатие он медленный, особенно на 9чку Не для сжатия текстур скажем так На р, Аноним (7), 02:24 , 27-Мрт-21, (281)

И да, помимо веб-страниц он использовался примерно только в png zlib и был сдел, Аноним (7), 17:11 , 17-Мрт-21, (24) –1 //

Вот ты ламер Он используется много где А просто потому что долгое время это бы, Аноним (58), 22:25 , 17-Мрт-21, (60) +2

Прости, но 8230 С каких пор коммерческие поигручечки из 90х считается за и, Аноним (7), 22:42 , 17-Мрт-21, (67) –2

С таких каких я в них играю, например Да ну, эксперт в треде, все в машину Им н, Аноним (81), 23:04 , 17-Мрт-21, (81) +2

Опять некрофильствуешь Я практически уверен что они кокнулись ещё в 90 да, я в, Аноним (7), 23:12 , 17-Мрт-21, (85) –1

Черта с два Живее всех живых И просто для понимания, в PS5, кажется, один из и, Аноним (-), 04:51 , 18-Мрт-21, (119) +1

Хотя, что касается снаппи 8230 Будем считать, что это было тёмное время Нет, , Аноним (7), 23:04 , 17-Мрт-21, (82) –2

Будем считать, что у кого-то в гугле NIH очень зудел Ващет быстрее Но проблема , Аноним (-), 12:40 , 18-Мрт-21, (154)

Это на примере тестовых файлов предоставленных авторами snappy и результат бенчм, Аноним (7), 14:01 , 18-Мрт-21, (157)

Верить авторам алгоритмов стоит с оговорками Особенно если они из гугола Вообще, Аноним (-), 23:42 , 18-Мрт-21, (180)

Штук 5, но в целом согласен Более того, я подозреваю, что зависимость от zlib т, Аноним (7), 14:23 , 19-Мрт-21, (244)

Это, имхо, врядли PNG ща много где юзается Ну и без zlib он как бы ни о чем Е, Аноним (249), 03:56 , 20-Мрт-21, (249)

brotli почему-то до сих пор по умолчанию нету в nginx, и многие забывают его пос, Аноним (25), 17:24 , 17-Мрт-21, (25) +3 //

Бротли дебильноват с архитектурной точки зрения, т к юзает огромный статистичес, timur.davletshin (ok), 21:24 , 17-Мрт-21, (45) //

Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов Пока , Анонимленьлогиниться (?), 22:07 , 17-Мрт-21, (53)

Оно мультитридинг научилось или будем шило на мыло опять менять, как с заменов J, timur.davletshin (ok), 22:45 , 17-Мрт-21, (69)

КМК мультитрединг скорее к апликухе больше Ничего страшного, AVIF их всех зохава, Аноним (-), 22:56 , 17-Мрт-21, (78)

Да вообще не факт Критически важно только для CDN, где уменьшение трафика карти, timur.davletshin (ok), 23:03 , 17-Мрт-21, (80)

Кроме этого страницы еще быстрее грузиться видите ли будут Особенно актуально в, Аноним (81), 23:06 , 17-Мрт-21, (83)

А что меньше батарею жрёт Аппаратный декодер JPEG или AVIF, который есть у с, timur.davletshin (ok), 23:13 , 17-Мрт-21, (87)

Декодирование картинок обчыно не является сушественным процентом времяпровождени, Аноним (-), 05:04 , 18-Мрт-21, (121)

Декодирование сжатого потока тоже не является, но его одноко же зачем-то оптимиз, timur.davletshin (ok), 05:26 , 18-Мрт-21, (128)

Когда у тебя 10 000 юзерей и им надо пожать ответ сервера - вот тут скорость уже, Аноним (-), 23:46 , 18-Мрт-21, (181)
Так об чём и речь я вёл Страдания на тему я видосики посмотрела 15 минут и мой , timur.davletshin (ok), 00:25 , 19-Мрт-21, (186)
Ну так потому корпы и пилят сабж Он греется и еще по over 9000 поводов Плюс-мин, Аноним (205), 02:43 , 19-Мрт-21, (205)
Давай, в студию модели без спайвари, милый Про него я даже не сомневаюсь Линукс, timur.davletshin (ok), 07:23 , 19-Мрт-21, (218) –1
Nokia N900 из винтажных , motorola droid если maemo leste вкорячить помощнее, , Аноним (-), 13:21 , 19-Мрт-21, (235)
Да-да, ты ещё не забудь вспомнить первый линуксофон Где-то у меня валяется, так, timur.davletshin (ok), 13:31 , 19-Мрт-21, (237)
А какое-нибудь Maemo не только живое и софт до сих пор обновляется, но и вон там, Аноним (-), 04:04 , 20-Мрт-21, (250) –1

Avif шляпа с любой стороны -- дефективный формат исключительно для экономии траф, Аноним (7), 23:20 , 17-Мрт-21, (90)

Не догоняю какие к тому фундаментальные предпосылки У av1 самого по себе очень , Аноним (-), 05:11 , 18-Мрт-21, (122)

Нет, мусор это грязные артефакты lossy-lossy кодирования, например Vp8 вместе, Аноним (7), 12:11 , 18-Мрт-21, (150)

У AV1 во первых артефакты очень не паливные, а во вторых есть lossless режим, на, Аноним (-), 23:52 , 18-Мрт-21, (182)

Я не отрицаю, что для такого битрейта результат очень впечатляющий Но av1 реаль, Аноним (7), 14:16 , 19-Мрт-21, (243)

У него в принципе очень крутое соотношение битрейт-качество Для этого и делался, Аноним (-), 04:32 , 20-Мрт-21, (251)
Субсамплинг вообще ни при чём, и, уж тем более, если исходное изображение и так , Аноним (7), 01:47 , 21-Мрт-21, (264)
Тогда и терять нечего, по большому счету Забойный аргумент правоты, что сказать , Аноним (265), 06:25 , 21-Мрт-21, (265)
Ну т е оскорбления -- это всё, на что ты способен Ясно, понятно Я показал теб, Аноним (7), 12:17 , 21-Мрт-21, (270)

есть еще совсем новый jpeg xl, Аноним (118), 04:35 , 18-Мрт-21, (118)

И что там с патентами После истории с gif и патентами на LZW, когда пришлось пр, Анонимленьлогиниться (?), 09:12 , 18-Мрт-21, (138)

Глупости не говорите Jpeg2k это тоже вейвлет кодирование, оно очень неплохо раб, Аноним (7), 12:25 , 18-Мрт-21, (151)

Это совсем не то, что заявляли авторы 2k и какие картинки в примеры они выводили, Анонимленьлогиниться (?), 15:49 , 18-Мрт-21, (159)

Не только в себя, любое лосси перекодирование выглядит очень хорошо Если не жаб, Аноним (7), 16:48 , 18-Мрт-21, (163)
И этоНет, он артефачит и не может нормально детектить края, перерисовывает части, Аноним (7), 16:56 , 18-Мрт-21, (164)

Как раз технологически там для этого очень даже приличные вещи типа CDEF есть И, Аноним (-), 00:04 , 19-Мрт-21, (183)
Файл и получается более мелким Вот на давешнем примере avif100 900kbavif90 225k, Аноним (7), 14:43 , 19-Мрт-21, (245)
Avif99 402kb кстати, но реально он выглядит хуже максимально без видимых искаже, Аноним (7), 17:15 , 19-Мрт-21, (247)
Але, гараж, если хочется качество сравнивать, в lossy варианте размер файлов дол, Аноним (-), 04:38 , 20-Мрт-21, (252)

Очень красноречивая картинка, спасибо Avif рулит , Аноним (203), 02:22 , 19-Мрт-21, (203)

Очень красиво обмакнули в ушат того умника с его раржыпегом Было бы странно есл, Аноним (-), 13:25 , 19-Мрт-21, (236)
При том секрет обмакивания раскрыт Умник тестил фото и видео на рисованых анима, Аноним (265), 06:28 , 21-Мрт-21, (266)

Это вопрос клиенту, использующему библиотеку вы ведь понимаете, что в библиотек, Анонимленьлогиниться (?), 09:17 , 18-Мрт-21, (139)

Смеялся А вот моя ядерная реализация из ядра линукс не параллелится Шта делат, timur.davletshin (ok), 09:44 , 18-Мрт-21, (142)

В ядре очень уж протухшие версии, у меня вот тоже вопрос -- почему , Аноним (7), 12:27 , 18-Мрт-21, (152)

Там не протухшие, а собственные реализации Как и всего остального, например тех, timur.davletshin (ok), 12:38 , 18-Мрт-21, (153)

Очень плохо Пока апстрим уходит на десятилетия вперёд а также исправляет ошибк, Аноним (7), 12:44 , 18-Мрт-21, (156)

Скорее наоборот Там будет самая вылизанная Твой уход на десятилетия вперёд ник, timur.davletshin (ok), 16:03 , 18-Мрт-21, (161)

Long таки даёт ощутимую экономию раза в 3 - например, из файла 2 6гб получается , Аноним (7), 18:32 , 21-Мрт-21, (272)
Как я понял, long режим с расширенным окном позволяет практически моментально де, Аноним (7), 22:43 , 21-Мрт-21, (274)

В ядре сильно другие constraints Вас же не устроит если ядро при каком-нибудь а, Аноним (-), 03:34 , 19-Мрт-21, (213)

Из-за подобной нерасторопности страдают пользователи Причём, вполне вероятно, с, Аноним (7), 15:16 , 19-Мрт-21, (246)

Ничего они не страдают - кернел threaded как черти что Это врядли Такие вещи вн, Аноним (-), 04:46 , 20-Мрт-21, (253)

Ну хорошо, вы много знаете случаев, когда 1 ГБ с скорости недостаточно Ну так вы, Анонимленьлогиниться (?), 15:53 , 18-Мрт-21, (160)

У меня домашний массив больше 400 выдаёт обычный домашний NAS на базе старого п, timur.davletshin (ok), 16:08 , 18-Мрт-21, (162)
Возмём средний ссд, сколько там, 3ГБ с А нет, уже 5 ГБ с чтение и запись , 15Г, Аноним (7), 18:37 , 18-Мрт-21, (168)

Справедливости ради, скорость интерфейса и скорость работы даже в режиме линейно, timur.davletshin (ok), 07:05 , 19-Мрт-21, (216)

Скорость ограничена только скоростью памяти, в 4 канальном режиме это порядка бо, Аноним (7), 11:27 , 19-Мрт-21, (228)

А теперь наша очередь Обнаружен эксперт в алгоритмах от вебмакакинга Как мистер, Аноним (184), 00:17 , 19-Мрт-21, (184) +1

Давай начнём с малого Как кэш делится между ядрами , timur.davletshin (ok), 00:28 , 19-Мрт-21, (187)

А вот это уже зависит от довольно много чего Бывают разные реализации, уровн, Аноним (-), 02:49 , 19-Мрт-21, (206)

По твоей теории, если всё упирается в ОЗУ, никакого проку от распараллеливания б, timur.davletshin (ok), 07:04 , 19-Мрт-21, (215)

На распаковку, именно современного быстрого алгоритма - не особо Если это нечто, Аноним (-), 13:31 , 19-Мрт-21, (238)
Ближе к телу, меньше абстрактных измышлений, разговор был конкретно про ядерную , timur.davletshin (ok), 13:33 , 19-Мрт-21, (239)
Ядерная реализация используется в том числе и для распаковки кернела вроде , Аноним (-), 04:47 , 20-Мрт-21, (254)

Мне кажется, вы путаете воркеры каких-нибудь файловых систем, вроде той же btrfs, timur.davletshin (ok), 00:40 , 19-Мрт-21, (192)

Сам алгоритм может, конечно, сделать то же самое по смыслу, но вообще такая функ, Аноним (-), 02:51 , 19-Мрт-21, (207)

Автор малость смухлевал так для повышения сжатия В принципе это даже малость ра, Аноним (58), 22:27 , 17-Мрт-21, (61)

Спасибо, кэп , timur.davletshin (ok), 22:46 , 17-Мрт-21, (71)

Что значит забывают Так его не поставить по-человечески Нет в репах - ни RHE, Анонимленьлогиниться (?), 22:05 , 17-Мрт-21, (52) +1 //

В смысле - не поставить А libbrotli1 в дебиане - это чего , Аноним (58), 22:29 , 17-Мрт-21, (62) +1

Я не про libbrotli1, а про nginx-module-brotli Что вам толку от либы, когда ngi, Анонимленьлогиниться (?), 09:05 , 18-Мрт-21, (137) +1

Ну я для себя и клиентов поддерживаю ppa в котором вместе с nginx ом собираю и n, hefenud (ok), 22:34 , 18-Мрт-21, (175)

Что мешает выложить в апстрим дистрибутива, сделав доступным для всех пользовате, Анонимленьлогиниться (?), 10:35 , 19-Мрт-21, (223)

Все и выложено и доступно, я же не из воздуха собираю И ppa общедоступный, ничто, hefenud (ok), 10:38 , 19-Мрт-21, (224)

Да собссно нжинкс не настолько сложно компилится, если это ну вот реально надо , Аноним (184), 00:18 , 19-Мрт-21, (185)

А попробуй стать гуглем - и узнаешь в чем прикол , Аноним (-), 22:57 , 17-Мрт-21, (79) //

А нам-то что с того Попробуешь, все равно не получится Да и гуглю оно больше дл, пох. (?), 08:53 , 19-Мрт-21, (220)

По другим причинам - ты не соберешь такую же распределенную штуку Ну вот нет у , Аноним (-), 13:53 , 19-Мрт-21, (240)

Правила русского языка, в соответствии с которым чего-то пишется через дефис , Кочегар (ok), 02:15 , 18-Мрт-21, (113) –3 //

Докапываться до орфографии как минимум неприлично Это занятие для людей, у кото, Аноним (7), 02:39 , 18-Мрт-21, (114) +2 //

Безграмотно писать 8212 выказывать неуважение к собеседнику Это удел людей, , Кочегар (ok), 03:02 , 18-Мрт-21, (115) –3

Езли тобе бизграматнасть мира выглядетт выкказываньем ниуваженья ктебе, та кем т, Ordu (ok), 09:34 , 18-Мрт-21, (140) +1
Ты саписетник штоли Нисмиши аднаклетачнае, Аноним (-), 11:50 , 18-Мрт-21, (148)

Ну и зачем эти полумеры типа zlib-ng когда есть Zstandard Переходите на него, а, Аноним (10), 15:43 , 17-Мрт-21, (10) –6 //

Так zlib они и не трогали, в чём претензия , Аноним (11), 15:48 , 17-Мрт-21, (11) +3
Говорят что LZO очень недооцененная штука Вот если будет что-то такое - обязате, Аноним (51), 22:01 , 17-Мрт-21, (51) //

lzo все-таки не для длинной сетевой передачи, а для задачи сжимать хоть чуть-чу, Анонимленьлогиниться (?), 22:12 , 17-Мрт-21, (55) +2
LZO для несколько других задач, он скорее с LZ4 сравним Жмет чуть получше, но и, Аноним (-), 22:32 , 17-Мрт-21, (63) –1 //

Ну дык жеж , Аноним (-), 00:58 , 18-Мрт-21, (108)

Самое главное из статьи непонятно сжатые модным нг файлы консервативным zlib , Аноним (13), 16:20 , 17-Мрт-21, (13) –1 //

Прочитал то ее хоть Сказано же - весь прирост из-за SSE AVX2 и чего только не , Аноним (15), 16:34 , 17-Мрт-21, (15) +2 //

огигиналы, наверное, про if defined не слышали или боятся код определения фи, InuYasha (??), 16:37 , 17-Мрт-21, (16) –2 //

Ну, понимаешь, любую фичу можно поюзать в объеме когда от своей крутизны станет , Аноним (-), 22:52 , 17-Мрт-21, (76) –1

Ну почему Если писать красиво и грамотно - любой код читаем и понимаем Приверы, InuYasha (??), 10:26 , 18-Мрт-21, (144)

Просто старинные компилеры дофига не умели или страдали дурными багами и требова, Аноним (188), 00:29 , 19-Мрт-21, (188)

Зачем in place В один хедер их все засунуть и оставить Huang A - The Hardware, InuYasha (??), 10:34 , 19-Мрт-21, (222)

Ну, может, в случае если функция в целом одинакова для всех, но вон тем и вон эт, Аноним (-), 13:59 , 19-Мрт-21, (241)

Случаи разные и их много, согласен Не буду же я все варианты придумывать-перечи, InuYasha (??), 14:14 , 19-Мрт-21, (242)

А вот Оберхамер прямо примерно это в коде и сделал ifdef ами, злыдень Поэтому т, Аноним (-), 05:07 , 20-Мрт-21, (255)

Оригиналы не только слышали, как вот ты, например, но еще и в курсе, что никаким, пох. (?), 16:56 , 18-Мрт-21, (165) –1

I understand your frustration gifНу, экстраполируй за ifdef-ы, что-ли Мне прих, InuYasha (??), 21:02 , 18-Мрт-21, (174)

похоже, нет приходилось ли тебе хоть раз в жизни писать код, который вызывает i, пох. (?), 09:12 , 19-Мрт-21, (221) –1

Ну не, такого говнокода я не писал Разве что - если где-то указатель выходил в , InuYasha (??), 10:39 , 19-Мрт-21, (225)

Это нормальный код Просто на неправильном процессоре он не должен выполниться А, пох. (?), 11:21 , 19-Мрт-21, (227) –1

Нахрен мне чужой быдлокод Своего мегатонны Я что-то пойму - ты админ 124 1, InuYasha (??), 12:24 , 19-Мрт-21, (231)

Он и админ и программист Уровня бох W пох Извини, пох, ты не против побыть мем, Аноним (-), 15:49 , 20-Мрт-21, (260)
Я админ opensource систем Кажется, это то, чему когда-то был посвящен данный са, пох. (?), 23:11 , 20-Мрт-21, (263)

С Exchange то Хвалящий винду Странный какой-то админ опенсорсных систем Кто , Аноним (267), 06:33 , 21-Мрт-21, (267)

Просто эстетикой его кодер на заморачивался и явно написал первое что ему в бошк, Аноним (-), 16:12 , 20-Мрт-21, (261) +1

Судя по тому, как ты это описал, это то, чем я и нормальные программисты пользую, InuYasha (??), 13:54 , 21-Мрт-21, (271)

Возможно Однако советую глянуть у Cyan а в блоге автор LZ4 Там еще очень зло, Аноним (275), 10:30 , 26-Мрт-21, (275)

Эх, заставил меня вспомнить как я проект доброй сотней сырцов с -w3 перевёл на -, InuYasha (??), 11:42 , 26-Мрт-21, (277)

Вынести в какой-нибудь хидер типа compiler-features h, чтобы взгляд не оскорблял, Аноним (-), 05:11 , 20-Мрт-21, (256)

Автор конкретного процитированного куска думал что это - портабельно Но недодума, пох. (?), 23:06 , 20-Мрт-21, (262)

Интринсики и портабельно - ну, э, лол С такими вещами это бывает Специфичное зн, Аноним (-), 06:51 , 21-Мрт-21, (268)

открою страшную тайну чем раньше в помойку летит поделка недоумка, неспособного, пох. (?), 10:53 , 21-Мрт-21, (269) –1

Знаешь, пох, с таким подходом - софтом вообще лучше не пользоваться, в нем баги , Аноним (275), 10:34 , 26-Мрт-21, (276)

я _только_что_ напоролся Переоптимизированный для amd64 код умудряется порождат, пох. (?), 19:51 , 27-Мрт-21, (282)

Можно , Аноним (17), 16:49 , 17-Мрт-21, (17) +1
Конечно Иначе нафиг он уперся, можно сразу zstd какой-нибудь было взять С его , Аноним (68), 22:42 , 17-Мрт-21, (68) –1
а твой консервативный zlib однопоточный пойду натру свой pbzip2 и 12 ядерный кир, kissmyass (?), 19:39 , 18-Мрт-21, (170)

Как это приятно видеть на фоне нынешней растомании , Аноним (18), 16:51 , 17-Мрт-21, (18) +3 //

Ага, а потом куча вирусор поплывет по интернету через какие нибудь уязвимости, ИмяХ (?), 16:56 , 17-Мрт-21, (19) –7 //

Ну когда же они поплывут Уже сколько лет обещают и все никак не плывут , Аноним (-), 17:05 , 17-Мрт-21, (22) +3 //

Heartbleed Не, не слышал, ведь ты тогда ещё в школу ходил и не знал даже про op, Аноним (26), 17:51 , 17-Мрт-21, (26) –5

А когда он стал вирусом , Аноним (-), 17:58 , 17-Мрт-21, (28) +6

Не понимаю, школьники или сифанатики минусуют и плюсуют По факту же - heartblee, Аноним (26), 23:59 , 17-Мрт-21, (103) –2

Вполне конкретный пример маркетингового булшита и набивания цены всякому хламу , Аноним (-), 05:15 , 18-Мрт-21, (123) +2

Ну вот нет же, Вы даже не ответили, как так вышло, что данные из-за Heartbleed п, Аноним (26), 09:41 , 18-Мрт-21, (141) –1

Факт вы занимаетесь софистикой и маркетинговым булшитом Ну как, полегчало , Аноним (188), 00:30 , 19-Мрт-21, (189) +1

10, InuYasha (??), 10:40 , 19-Мрт-21, (226)

И где вирусы на его основе Вот именно вирус на основе heartbleed сделать - на у, Аноним (-), 22:33 , 17-Мрт-21, (64)

sarcasm А где вирус для браузера на основе Spectre sarcasm Между вирусом, чер, Аноним (26), 23:50 , 17-Мрт-21, (96)
Первая попавшаяся с хабра статья https habr com ru post 218661 , Аноним (26), 23:54 , 17-Мрт-21, (99)

И где там вирусы которые обещал тот тупизень , Аноним (-), 05:17 , 18-Мрт-21, (125)

Вирусы никто не обещал, ты сам себе напридумывал невесть чего А там всего лишь , Аноним (26), 09:44 , 18-Мрт-21, (143)

И даже тут вранье у маркетоида - https www opennet ru openforum vsluhforumID3 , Аноним (188), 00:31 , 19-Мрт-21, (190)

Они только про оптимизацию или есть всё же шанс дождаться там поддержки Zip64 De, mumu (ok), 17:02 , 17-Мрт-21, (20) –1
Nenuzhno 3, B (?), 18:18 , 17-Мрт-21, (30) –7 //

Элементарно, Ватсон Не нравится - не используй , Аноним (-), 05:18 , 18-Мрт-21, (126) +1

Интересно было бы увидеть сравнение с zopfli , qc (?), 18:21 , 17-Мрт-21, (32) +1 //

Парсер у них вероятно старый от zlib, C (?), 18:47 , 17-Мрт-21, (33) +1 //

Вроде на странице гихаба зопфли написано что он медленный но сжимает лучше злиба, qc (?), 19:41 , 17-Мрт-21, (38) //

там казнитьнильзяпамилавать написано, стремновато если честно, Аноним (51), 21:59 , 17-Мрт-21, (50)

Zophli ровно обратную задачу решает хрен с ней с скоростью, зато максимально пл, Аноним (-), 22:39 , 17-Мрт-21, (66) +2 //

Спасибо за разъяснения , qc (?), 23:51 , 17-Мрт-21, (97)

Вредителям из zlib желаю тяжелого коронавируса, а всем дистрибутивам перейти на , Аноним (37), 19:29 , 17-Мрт-21, (37) –9 //

Ага, сидят и видят как бы не принять улучшение в проект, Аноним (40), 20:48 , 17-Мрт-21, (40) +2
вы это пожелали человеку, который сделал свободную реализацию deflate, вылизал е, edo (ok), 23:28 , 19-Мрт-21, (248) +4

лол, Аноним (41), 20:52 , 17-Мрт-21, (41) –2 //

В чём , омоним (?), 21:30 , 17-Мрт-21, (47) +1 //

смишная нируская фамилия наверное, Аноним (-), 22:10 , 17-Мрт-21, (54)
Там от силы 20 строчек кода , Аноним (41), 23:23 , 17-Мрт-21, (91) –1 //

Гагаг, фу лол, надо было 21 так чтоли получается , Аноним (-), 14:44 , 18-Мрт-21, (158)
А вот 5 строк, принёсшие Криске Касперски мировую известность code int main , n00by (ok), 12:50 , 20-Мрт-21, (259)

Потестил с lzbench Результаты code lzbench 1 8 64-bit Linux Assembled by P , омоним (?), 20:58 , 17-Мрт-21, (42) +3 //

То есть оно ещё и жмёт лучше Сууупер , Аноним (37), 21:37 , 17-Мрт-21, (48) //

Наоборот же - хуже - Оригинальный файл 202372260 байтов Сжатый zlib -1 11590, омоним (?), 21:52 , 17-Мрт-21, (49) //

Имхо - баг зарепортите им -1 и -2 в zlib не интересны вот практически никогда , Анонимленьлогиниться (?), 22:19 , 17-Мрт-21, (57)

Почему это Они гарантируют более высокую скорость и совместимость с deflate Лучш, омоним (?), 22:35 , 17-Мрт-21, (65)

Там разница в пределах погрешности А zophli все-равно обоих натянет - если ждат, Аноним (68), 22:49 , 17-Мрт-21, (74)

Ну так они и не мой файл использовали - Когда-нибудь поднатужусь, и встрою в l, омоним (?), 23:09 , 17-Мрт-21, (84)

А твой файл вообще очень синтетический походу Процент сжатия злобный, скорость , Аноним (-), 05:21 , 18-Мрт-21, (127)

Худшее там - в пределах погрешности Так-то даже в 7zip если форсировать однотред, Анонимленьлогиниться (?), 09:03 , 18-Мрт-21, (136)

Примерно однохренственно оно жмет Если надо суперсжатие в этот формат любой цен, Аноним (68), 22:46 , 17-Мрт-21, (70)

Зачем, если есть lbzip2 , Аноним (43), 21:18 , 17-Мрт-21, (43) –1 //

Тогда уже лучше lzip алгоритм xz - жмёт лучше, быстрее, тоже умеет восстановле, timur.davletshin (ok), 21:26 , 17-Мрт-21, (46)
Bzip2 в 2020 году вообще совсем ни о чем Жмет заурядно Упаковка не быстрая Ра, Аноним (68), 22:47 , 17-Мрт-21, (72) +1 //

Для начала bzip2 умеет какую-то хоть возможность восстанавливать архивы Из новы, timur.davletshin (ok), 22:55 , 17-Мрт-21, (77) –1 //

Довольно маргинальную И если это реально было надо - есть утилиты реализующие к, Аноним (81), 23:12 , 17-Мрт-21, (86) –1

Алло, гараж, речь про архиватор была Повторю, А-Р-Х-И-В-А-Т-О-Р используют для , timur.davletshin (ok), 23:19 , 17-Мрт-21, (88) –1

Если надо именно это - логично с recovery info каким делать, по типу par какого , Аноним (-), 23:30 , 17-Мрт-21, (93)

https www nongnu org lzip xz_inadequate html 8212 просто так, навеяло Неком, timur.davletshin (ok), 00:07 , 18-Мрт-21, (105) –3

Я бы на вашем месте эту писульку не упоминал почём зря -- автор там, как минимум, Аноним (7), 01:39 , 18-Мрт-21, (111)

Давай я тебе рандомно побью архив и мы посмотрим, как ты его восстановишь, догов, timur.davletshin (ok), 04:58 , 18-Мрт-21, (120)

Если это меня беспокоит, я, для начала, RAID1 на btrfs юзаю И наткнувшись на ду, Аноним (188), 00:35 , 19-Мрт-21, (191)

Для начала, raid1 с btrfs - тупое говно-решение Если тебе нужно восстановление,, timur.davletshin (ok), 00:44 , 19-Мрт-21, (194)

Я думаю что моя квалификация позволяет принимать мне решения как мне хранить мои, Аноним (208), 03:06 , 19-Мрт-21, (208)
Это и называется апломб Но ты продолжай юзать raid в btrfs, он же ни у кого не , timur.davletshin (ok), 07:15 , 19-Мрт-21, (217)
ты бы лучше расписал детали, что и где у тебя пошло не так - хоть какая-то польз, пох. (?), 11:32 , 19-Мрт-21, (229) –1
Я тебе даже расписывал как я его на машине с битой RAM гонял, в DUP конфигурации, Аноним (-), 05:19 , 20-Мрт-21, (257)
я Тимура спрашивал, вообще-то То что в твоем специфическом случае оно работало , пох. (?), 19:56 , 27-Мрт-21, (283)
Самое крутое - на выдернутой без отмонтирования флехе видимо слетел erase block,, Аноним (-), 05:27 , 20-Мрт-21, (258)

Это все круто, только имеет смысл в очень некоторых применениях Видите ли смотр, Аноним (-), 05:31 , 18-Мрт-21, (129)

А что такое там происходит с данными в tar, что ваш убер архиватор не может пото, timur.davletshin (ok), 05:43 , 18-Мрт-21, (131)

Если декомпрессор вернул отлуп что ошибка в данных, до попытки парсинга tar дело, Аноним (193), 00:44 , 19-Мрт-21, (193)

Извините, вы читать не умеете , timur.davletshin (ok), 00:46 , 19-Мрт-21, (195)
Удачи Один RAID1 предлагает, другой вообще несколько копий всего держит Линукс, timur.davletshin (ok), 00:49 , 19-Мрт-21, (196)

Ну а нафиг мне полувосстановленный рабочий проект например Что с ним делать До, Аноним (-), 03:16 , 19-Мрт-21, (210)

А если заголовок побит, то всё , timur.davletshin (ok), 00:51 , 19-Мрт-21, (197)

Зависит от У zip, например, заголовков как таковых два Один конденсировано в, Аноним (-), 03:14 , 19-Мрт-21, (209)
Поменьше болтовни, про tar c gz bz2 я и без тебя знаю, побольше про свой любимый, timur.davletshin (ok), 07:01 , 19-Мрт-21, (214)
Увы, я не верю в серебряные пули - и поэтому предпочитаю формат под задачу выбир, Аноним (-), 01:35 , 05-Апр-21, (285)

Речь идёт об алгоритме, который работает в том числе на слабых IoТ устройствах и, timur.davletshin (ok), 05:53 , 18-Мрт-21, (132)

Им bz2 совсем не друг, там проблемы со всем и сразу - и плотное сжатие все хотят, Аноним (-), 00:57 , 19-Мрт-21, (198)

Смотри Взять lzma вместо bz2 -- первый жмёт быстрее и лучше второго, добавить п, Аноним (7), 23:50 , 17-Мрт-21, (95) –1

Вперёд Миру нужен ещё один формат архивов , timur.davletshin (ok), 23:54 , 17-Мрт-21, (98) –1

Так там тот же тар Просто сжат получше , Аноним (7), 00:09 , 18-Мрт-21, (106) –1
Не, блин, будем до упора пользоваться ископаемой архаикой, тормозной как трактор, Аноним (-), 05:33 , 18-Мрт-21, (130)

Ты par видимо не застал, его одно время форсили Там один криво реализованный ал, timur.davletshin (ok), 06:04 , 18-Мрт-21, (133)

Когда ничего лучше не было - форсили А так то алгоритмы сжатия, вот, развиваютс, Аноним (-), 01:02 , 19-Мрт-21, (199)

Было бы здорово, если бы было можно прицепить парити к файлу Ну там по типу ntf, Аноним (7), 23:35 , 17-Мрт-21, (94) –2

Весь уровень знаний в одной фразе , timur.davletshin (ok), 23:55 , 17-Мрт-21, (100)

Ну сорян, я правда не слышал чтобы какое-либо парити хотя бы по типу кода рида-с, Аноним (7), 00:06 , 18-Мрт-21, (104) –1

Так еще и по bz2 ыксперд Десять салом онов из десяти D , Аноним (-), 01:03 , 18-Мрт-21, (109) –1

Меня почему-то раздражает твоя тупость Хотя я не часто встречаю таких самонадея, Аноним (7), 01:41 , 18-Мрт-21, (112)

Удивительно, но моя мудрость спровоцирована твоей глупостью , Аноним (-), 11:54 , 18-Мрт-21, (149)

Да, его нет Парити обеспечивали ленточные накопители, под которые tar и проекти, timur.davletshin (ok), 06:08 , 18-Мрт-21, (134)

Что это пар не взлетело А что же я каждый день на файлообменных форумах вижу ег, Аноним (7), 19:46 , 18-Мрт-21, (171)

Правда нужно учитывать что на ссд скорее всего вылетать будут блоки не 512 байт , Аноним (7), 19:53 , 18-Мрт-21, (172)

1 FEC делается _постранично_ И вылетает страница, если FEC не выдюжил вон то к, Аноним (-), 01:04 , 27-Мрт-21, (278)

Я не знаю, по каким местам вы шастаете кстати, а где , но в дикой природе я ег, timur.davletshin (ok), 20:00 , 18-Мрт-21, (173)

варезник, небосьтам критично свойство архиватора нарезать мелкими ломтиками, ну , пох. (?), 20:00 , 27-Мрт-21, (284)

Да нет там ничего такого, он просто состояние компрессора каждый блок сбрасывает, Аноним (-), 01:06 , 19-Мрт-21, (200) +2

bzip вообще не нужен, xz на низких степенях сжатия -3 и около того жмёт быстре, Твоя мама (?), 23:57 , 17-Мрт-21, (102) +1 //

Справедливости ради, на некоторых входных данных bzip2 сжимает эффективнее, чем , edo (ok), 20:15 , 21-Мрт-21, (273) +1

Я не пойму, почему столько негатива Если будет гарантировать совместимость на у, timur.davletshin (ok), 21:19 , 17-Мрт-21, (44) +3 //

Да даже хрен с ним с ABI, нехай API формат данных останется тем же А софт мож, Аноним (68), 22:48 , 17-Мрт-21, (73) //

Если формат данных разный, то это очередные пердоли, как с gzip и zlib, когда ал, timur.davletshin (ok), 22:51 , 17-Мрт-21, (75) –1 //

Так при чем тут ABI ABI это _бинарный_ интерфейс программа - либа На уровне , Аноним (-), 23:19 , 17-Мрт-21, (89) –1

Ну что ты городишь Ну вот тебе, например, libjpeg-turbo бинарно совместим с lib, timur.davletshin (ok), 23:23 , 17-Мрт-21, (92)

И чего Со своей стороны я считаю что опенсорсникам хватит и совместимости API , Аноним (-), 01:10 , 19-Мрт-21, (202)

Изменение, например, порядка аргументов меняет их размещение в регистрах Добавл, uis (ok), 11:17 , 18-Мрт-21, (147)

Что сказать-то хотел, кэп , timur.davletshin (ok), 12:42 , 18-Мрт-21, (155)

Что бинарной совместимости не жди, uis (ok), 12:12 , 19-Мрт-21, (230)

Я об этом догадывался , Аноним (-), 01:08 , 19-Мрт-21, (201)

Неужели в GCC автовекторизатор на -O3 работает настолько плохо , Аноним (116), 03:36 , 18-Мрт-21, (116) //

Обычно хуже, чем ручками, uis (ok), 11:13 , 18-Мрт-21, (146) +1
он вообще никак не работает Что бы там секта свидетелей -O9 не бормотала Собст, пох. (?), 17:14 , 18-Мрт-21, (166) //

Есть ещё промежуточный вариант - интринсики Чуть удобнее ассемблера Это да , Аноним (204), 02:37 , 19-Мрт-21, (204) //

теперь тебе надо не только знать ассемблер и архитектуру три разных, как в этом, пох. (?), 08:41 , 19-Мрт-21, (219)

Наоборот же Интринсики описываются в h файле и имеют тот же самый С-интерфей, Аноним (204), 12:50 , 19-Мрт-21, (232) +2
Немного не так Теперь надо знать возможности архитектуры и желаемую операцию, Аноним (-), 01:24 , 27-Мрт-21, (279)

смузихлёбов хлебом не корми, дай что-нибудь обозвать старым и устаревшим и выбро, Аноним (116), 03:41 , 18-Мрт-21, (117) –2 //

а оно у них все равно не собирается на тех платформах Или ты думал, в сказку по, пох. (?), 17:16 , 18-Мрт-21, (167)

А сжатие как Если не ухудшилось, то хорошо, годно , uis (ok), 11:12 , 18-Мрт-21, (145)
собрал и установил, собранные с обычным zlib проги норм работают без пересборки, макпыф (ok), 22:53 , 18-Мрт-21, (176) +2
Я думал zlib уже давно оптимизирован по самые уши, а тут оно вон что Жду в дист, Аноним (179), 23:17 , 18-Мрт-21, (177)
Да уж Тоже мне бинарная совместимость Попытался через LD_LIBRARY_PATH замени, Аноним (286), 03:07 , 03-Янв-22, (286)

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

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ообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	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ообщить модератору