#c #c #compression
#c #c #сжатие
Вопрос:
Кто-нибудь знает о бесплатной (не GPL), прилично производительной библиотеке сжатия, которая поддерживает пакетно-ориентированное сжатие в C / C ?
Под пакетно-ориентированной я подразумеваю функцию, которая есть у QuickLZ (GPL), где несколько пакетов потока могут быть сжаты и распакованы по отдельности, в то время как история сохраняется по пакетам для достижения разумного сжатия.
Я бы предпочел коэффициент сжатия, а не загрузку процессора, если загрузка процессора не смешна, но мне было трудно найти эту функцию вообще, так что все, что представляет интерес.
Комментарии:
1. Для чего полезно иметь пакетно-ориентированное сжатие? Когда вы сохраняете словарь из предыдущих пакетов, вам в любом случае необходимо распаковать все предыдущие пакеты.
2. Конечно, вам нужно распаковать «все предыдущие пакеты». Но многие приложения заинтересованы в каждом отдельном пакете сами по себе, по мере их поступления. Алгоритм сжатия, с другой стороны, заинтересован в данных в виде потока, чтобы обнаружить энтропию, и, таким образом, хочет со временем улучшить их состояние. Цель должна быть достаточно очевидной: позволить отправителю передавать пакеты, содержащие подробные (т. е. низкоэнтропийные) данные, и иметь алгоритм сжатия, автоматически минимизирующий фактические отправленные биты.
3. Цель сжатия, ориентированного на пакеты, для меня все еще не очевидна. Должно быть легко разделить распакованный поток на исходные пакеты, если вам нужно это сделать.
4. Я думаю, что OP хочет гарантии, что он получит небольшие фрагменты распакованных данных своевременно, вместо того, чтобы ждать полной распаковки перед получением каких-либо данных.
5. Что вы подразумеваете под «свободным (не-GPL)»? Соответствует ли лицензия BSD требованиям?
Ответ №1:
основная deflate() функция zlib принимает flush параметр, который позволяет использовать различные режимы очистки. Если вы передаете Z_SYNC_FLUSH в конце каждого пакета, это должно привести к желаемому эффекту.
Подробности объясняются в руководстве по zLib.
bzip2 также имеет функцию очистки, которая может позволить вам делать подобные вещи. Смотрите http://www.bzip.org/1.0.5/bzip2-manual-1.0.5.html#bzCompress
Комментарии:
1. Да. И лицензия zlib НЕ является авторским левым. Это больше похоже на BSD или MIT, чем на GPL. В принципе, вы просто не можете 1) удалить уведомление об авторских правах при распространении исходного кода или 2) Изменить его и по-прежнему называть его ZLib.
2. На самом деле это довольно хороший способ сделать это;
Z_SYNC_FLUSHсохраняет состояние сжатия и просто записывает достаточное количество данных, чтобы принимающая сторона могла прочитать то, что было написано до сих пор. Я думаю, что принятие через полтора года все же лучше, чем никогда 🙂3. Я также хотел бы добавить на этом этапе, что code.google.com/p/lzham (начиная с alpha8) поддерживает очистку в стиле zlib и может использоваться одним и тем же способом с различными характеристиками производительности.
Ответ №2:
Snappy от Google может быть хорошим вариантом, если вам нужна скорость больше, чем сжатие, и вы просто хотите сэкономить небольшое количество места.
В качестве альтернативы, Илья Муравьев некоторое время назад разместил небольшой фрагмент кода сжатия под названием BALZ в открытом доступе. Она вполне подходит для многих типов данных.
Оба они поддерживают очистку потока и независимые переменные состояния для выполнения нескольких параллельных потоков между пакетами.
Комментарии:
1. Так ли это? Я не могу найти это в Snappy — похоже, он просто сжимается с помощью функции без состояния. BALZ — это командная строка, а не библиотека, и похоже, что она просто передает stdin фрагментами, вообще не поддерживая материал типа packet?
Ответ №3:
Новый протокол Google SPDY использует zlib для сжатия отдельных сообщений и поддерживает состояние zlib в течение срока действия соединения для достижения лучшего сжатия. Я не думаю, что существует отдельная библиотека, которая точно обрабатывает это поведение, но есть несколько реализаций SPDY с открытым исходным кодом, которые могли бы показать вам, как это делается.
Комментарии:
1. Интересно и разумно предложить это для этого вопроса. Вы случайно не знаете, как можно разумно отправлять небольшие сообщения?
Ответ №4:
Общедоступный алгоритм Crush Ильи Муравьева обладает аналогичной производительностью и степенью сжатия, что и QuickLZ, Crush немного мощнее. Алгоритмы концептуально тоже похожи, Crush содержит немного больше хитростей.
Алгоритм BALZ, который уже упоминался ранее, также принадлежит Илье Муравьеву.
Смотрите http://compressme.net /
Ответ №5:
возможно, вы могли бы использовать lzma compression SDK, он написан и размещен в открытом доступе Игорем Павловым.
И поскольку она может сжимать потоковые файлы и имеет сжатие из памяти в память, я думаю, что можно сжать поток пакетов (возможно, с некоторыми изменениями), но не уверен.
Комментарии:
1. Существует множество библиотек сжатия с открытым исходным кодом, которые можно использовать бесплатно. Сжатие также является высокотехничной процедурой. Просто предполагая, что lzma, которая специально написана для максимально возможной производительности на больших наборах данных, может быть легко модифицирована для работы с небольшими пакетами данных (совсем другая проблема), потребуется нечто большее, чем «возможно» и «не уверен».