The OpenNET Project / Index page

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

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


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

Оглавление

Google представил библиотеку jpegli для более эффективного сжатия JPEG-изрбражений , opennews (??), 04-Апр-24, (0) [смотреть все]

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


5. "Google представил библиотеку jpegli для более эффективного с..."  +8 +/–
Сообщение от DZgas (?), 04-Апр-24, 12:00 
Потому что сначала надо было придумать эти avif webp jpeg XL что бы брать от туда технологии, которые можно применить в jpeg
Точно так же как с AQ-3 из HEVC в AVC
Или та же технология butteraugli придуманная для jpeg XL и далее используемая в другом гугл jpeg кодировщике guetzli
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

8. "Google представил библиотеку jpegli для более эффективного с..."  –4 +/–
Сообщение от Аноним (4), 04-Апр-24, 12:04 
Фичи можно было изначально для джпега разрабатывать , без прокладок и памперсов .
Ответить | Правка | Наверх | Cообщить модератору

24. "Google представил библиотеку jpegli для более эффективного с..."  +4 +/–
Сообщение от Аноним (24), 04-Апр-24, 13:00 
> без прокладок и памперсов

А как ты тогда тут комментить будешь?

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

13. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (1), 04-Апр-24, 12:16 
> Точно так же как с AQ-3 из HEVC в AVC

Можно подробнее? В интернете мало инфы.

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

69. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/–
Сообщение от DZgas (?), 04-Апр-24, 17:13 
инфы нет вообще, только документация и сами кодеки x264 x265 с всвроенными инструкциями. (в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264. Единственное описание на какой то мёртвой вики, на которую ссылается весь интернет, это дизинформация.. такие дела, тыкай сам.)
AQ-3 в AVC позволяет кодировать тёмные гардиенты (в темноте) без артефактов блочности
Ответить | Правка | Наверх | Cообщить модератору

92. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 04-Апр-24, 20:07 
> в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264

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

В целом: "deadzone quantizer ... [какие-то нехорошие слова, дублирующие картинку]. It has the benefit during compression of ensuring that noisy low-level signals are not allocated bits unnecessarily" - https://www.sciencedirect.com/topics/engineering/quantizer

Разговор о том, как его отменяют другие параметры. По крайней мере, один параметр. По крайней мере, в 2006-2007:
https://forum.doom9.org/showthread.php?p=883221#post883221
https://forum.doom9.org/showthread.php?p=1072878#post1072878

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

97. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 04-Апр-24, 20:19 
http://akuvian.org/src/x264/overview_x264_v8_5.pdf

Судя и по этому, --trellis 1 (пресет <=faster) или 2 (пресет <=slow) заменяет deadzone quantizer с его настройками (--deadzone-inter --deadzone-intra), поэтому ими не стоит забивать голову.

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

107. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от DZgas (?), 04-Апр-24, 21:54 
Короче, алгоритм уменьшает коэффициенты, мыля картинку. Я это к чему говорю, в 2024 году можно обойтись без него, deadzone-inter=0 deadzone-intra=0 trellis=0
заместо этого алгоритма,
Используем пре-фильтр hqdn3d=luma_spatial=1:chroma_spatial=1:chroma_tmp=3:luma_tmp=3
либо намного более сложный nlmeans=3:7:7:5:5
параметры какие хочешь... к чему я это.
На тестах которые я проводил. AVC на разрешениях ниже чем 720p и при идентичном качестве картинки, работает быстрее и эффективнее чем HEVC, без проблем распараеливаясь на 12+ потоков (суммарно при 100%). Такие дела. (разрешения выше 720p не пригодны для avc. HEVC AV1 там это всё.)
Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

118. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/–
Сообщение от Аноним (118), 05-Апр-24, 00:14 
AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во всяком случае, я могу утверждать это про x264. А вот x265 терпимо и на sd и на hd+. Но там это, новый босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1 и совершенно идеален.

>без проблем распараеливаясь

не без проблем, если ты кодируешь avc больше чем в ~4 потока на fullhd качество кодирования улетает в пол.

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

142. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (-), 05-Апр-24, 06:16 
> AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во
> всяком случае, я могу утверждать это про x264. А вот x265
> терпимо и на sd и на hd+. Но там это, новый
> босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1
> и совершенно идеален.

А, вот почему ISO так судорожно кодеки строгает? А чего у вашего босса поджилки трясутся и из носа сопля свисает? Неужто получше никого не нашли?! И вот это чмище теперь попробует устроить патентный рэкет всему раёну? :)

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

145. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (118), 05-Апр-24, 09:08 
Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на пустом месте как vp9/av1, толку от качества, если битрейт улетает в небеса, а без битрейта сыпет жуткими глитчами), не размывает картинку так сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный, чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель уже известен.
Ответить | Правка | Наверх | Cообщить модератору

186. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (-), 07-Апр-24, 03:33 
> Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на
> пустом месте как vp9/av1,

Это все - абстрактные блабла. И вот что-что а AV1 в раздувании битрейта я бы уж точно не обвинил, а svt-av1 лично мне так очень понравился.

Да и VP9 субъективно - где-то на уровне x265 по битрейт-качество. При том что в массы пошел раньше. Одна из причин по которым H.265 непонятное бессмысленное УГ, с более плохими условиями использования, недопилеными реализациями, злыми условиями лицензинга, а с пришествием 266 это заодно еще - кидок тех кто все же развелся и заплатил, вынести лохов в obsolete с такой скоростью это круто придумано! А теперь их попытаются отрекетировать еще раз, объяснив что надо доплатить? Удачи! Думаю они будут в восторге, а у AOM чего может прибавиться участников :). Так можно дожать до этого даже и броадкомы с квалкомами пожалуй.

> толку от качества, если битрейт улетает в небеса,

У лично меня в AV1 и VP9 ничего никуда не улетает. Если вы не смогли в параметры кодирования - это не их баг.

> а без битрейта сыпет жуткими глитчами), не размывает картинку так
> сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный,

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

Для сравнения AOM создал - целую экосистему next gen. Когда даже хардварный декодер можно получить на довольно халявных условиях. И генерится это все - прямо из сорцов libaom, через high-level synthesis. Попробуйте с фраунхофера и прочих жуликов такое получить?! В AOM и вписались интел/амд/нвидия/арм и куча имен помельче. И теперь вот это все будет - практически во всех новых разработках. А вон те что предложут? А, рэкет за очередную пулю из непонятного материала, с почетным правом сделать ловомой объем самим? А оно точно в таком виде надо? :)

> чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют
> в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель
> уже известен.

HEVC едва-едва рубается с древним VP9, примерно на равных. Куды этой пакости до AV1, у него половины эффективных тулсов уменьшения битрейта на уровне формата потока нет. Отсталый прямо на момент дизайна формат. Потому исо и страгает новые в истеричном темпе, контроль над ситуацией утекает из их кривых лапок.

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

190. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (118), 07-Апр-24, 09:32 
Это всё хорошо, но hevc абсолютно повсюду уже 12 лет. Это вечность. И никуда уходить не собирается, это до сих пор единственный вариант для качественного контента до повсеместного распространения декодеров h266 ещё несколько лет пройдёт. А ты, наверное, хотел как с mpeg2? Так он лет 10 использовался, bd заменил dvd и до-свидания.
Ответить | Правка | Наверх | Cообщить модератору

123. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 05-Апр-24, 00:37 
Но это ведь не замена, это фильтры для удаления такого-то шума в таких-то исходниках. Плюс решение не тюнить качество/размер_файла до посинения.

Хз, должен ли deadzone с его обнулением коэффициентов бить именно по высоким частотам. Trellis должен, но против этого предлагается тюнить psy-rd'ы.

Как фанаты этого дела выбирают под себя глубину крольчьей норы?.. Субъективная оптимизация* упирается в человеческие возможности - человека хватит на отсматривание нескольких десятков наборов настроек. Объективная оптимизация по хорошей метрике вроде VMAF или SSIMULACRA2 упирается в несовершенство метрики, да и крутят на практике только один параметр: crf или qp для отрезка видео[1][2]. Что как бы намекает на рецепт хорошего качества - перейти на самый новый кодек (независимо от разрешения), а с его тормознутостью будет уже не до тестирования кучи настроек.

> без проблем распараеливаясь на 12+ потоков

А если x265 с проблемами, то можно пойти по пути гуглокодеков - смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно, скармливая им по куску из видео (заранее разрезать на сцены) (всё это кое-как автоматизировали в av1an).

* оптимизация в математическом смысле - как максимизация функции типа визуальное_качество(настройка_1, настройка_2, ...)

[1] https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v...
[2] https://github.com/alexheretic/ab-av1

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

187. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (-), 07-Апр-24, 04:16 
> А если x265 с проблемами, то можно пойти по пути гуглокодеков -
> смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно,
> скармливая им по куску из видео (заранее разрезать на сцены) (всё
> это кое-как автоматизировали в av1an).

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

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

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

193. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 07-Апр-24, 15:11 
> На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть.

Но я не про тайлы (независимые части кадра для распараллеливания), а про "чанки", про видео, нарезанное по некоторым кадрам - по некоторым переходам между сценами. Если целиться на определённое качество, а не определённый битрейт, то особых проблем быть не должно. Может, есть смысл в гипотетической конструкции типа "2-й проход - параллельно по чанкам, 1-й - по всему видео, файл со статистикой как-то разрезать", но до такого никто не доходил.

> Однако при убогом формате потока еще и дополнительно нагнуть...

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

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

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

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




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

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