Исходное сообщение
"Сравнение видеокодеков Ogg Theora и H.264" Отправлено PereresusNeVlezaetBuggy, 27-Фев-10 01:18
>[оверквотинг удален] >У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем >распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно >с -9 заметно. Чисто техническая заморочка. Дело в том что LZ >ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда >более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее, >фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За >это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь, >у вас нет времени поискать максимально возможное совпадение в огромном словаре >на много мегов + применить добавочные техники - степень сжатия резонно >страдает). Алгоритм Лемпеля-зива не «ищет повторные данные в потоке», по крайней мере, в базовой реализации. Там используется другая схема работы: по мере чтения _битового_ потока ищется самый длинный совпадающий с текущим читаемым куском элемент словаря, записывается его код, затем «хвост», а новый элемент (найденный + хвост) попадает в словарь. Это сильно упрощённо, конечно. :) Не изучал детально сорцы современных архиваторов, но, насколько я себе представляю возможность LZ* - используются разные настройки словаря, плюс возможно использование уже готового словаря ("мультимедийное сжатие RAR"). А так, простенький LZ-архиватор пишется на голом Си за два часа: час курения алгоритма, полчаса кодинг, полчаса дебаг. :)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>[оверквотинг удален] >>У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем >>распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно >>с -9 заметно. Чисто техническая заморочка. Дело в том что LZ >>ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда >>более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее, >>фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За >>это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь, >>у вас нет времени поискать максимально возможное совпадение в огромном словаре >>на много мегов + применить добавочные техники - степень сжатия резонно >>страдает). > Алгоритм Лемпеля-зива не «ищет повторные данные в потоке», по крайней мере, в > базовой реализации. Там используется другая схема работы: по мере чтения _битового_ > потока ищется самый длинный совпадающий с текущим читаемым куском элемент словаря, > записывается его код, затем «хвост», а новый элемент (найденный + хвост) > попадает в словарь. Это сильно упрощённо, конечно. :) > Не изучал детально сорцы современных архиваторов, но, насколько я себе представляю возможность > LZ* - используются разные настройки словаря, плюс возможно использование уже готового > словаря ("мультимедийное сжатие RAR"). А так, простенький LZ-архиватор пишется на голом > Си за два часа: час курения алгоритма, полчаса кодинг, полчаса дебаг. > :)
	Введите код, изображенный на картинке: