Сжатие целочисленных данных без потерь

@AlexChek · Регистрация: 19.10.2018

Author24 — интернет-сервис помощи студентам

Нужно сжать массив/вектор int16_t. Нужен быстрый алгоритм сжатия, т.к. такой массив поступает примерно раз в секунду. Поэтому алгоритм Хафммана отпадает, по поводу LZ семейства не особо уверен, т.к. словарь, как и дерево в Хаффмане будет строиться долго (да и как его использовать для целых не особо понимаю) и ресурсозатратно, по поводу гладкости последовательности не знаю, поэтому дельта + RLE под вопросом. Поэтому не могли бы подсказать какие-то алгоритмы или реализации.

@nonedark2008 · 19.03.2020, 01:09

Сообщение от AlexChek

Нужно сжать массив/вектор int16_t

А какого характера данные? Если они окажутся случайными, то и сжимать их смысла нет.

Сообщение от AlexChek

такой массив поступает примерно раз в секунду

Такой - это какой? За секунду современный компьютер может сделать очень многое.

Сообщение от AlexChek

да и как его использовать для целых не особо понимаю

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

Сообщение от AlexChek

алгоритм Хафммана отпадает

Можно попробовать адаптивный алгоритм Хаффмана. Дерево строится "на лету", и его не нужно хранить.

@AlexChek · 19.03.2020, 01:19 **[ТС]**

В массиве хранится частоты сигнала (аудио) воспроизводимого за секунду. По поводу кода Хаффмана, мне ведь все равно придется находить вероятность для каждого числа из диапазона -32 768 до 32 767, разве нет? Если да, то это ведь очень ресурсозатратно и долго.
Т.е. мне каждую секунду приходят частоты, которые хранятся в массиве, который нужно сжать, а потом уже "распаковать".

@nonedark2008 · 19.03.2020, 09:03

Сообщение от AlexChek

В массиве хранится частоты сигнала (аудио) воспроизводимого за секунду

Какие у тебя ограничения? Битрейт? Требования к задержке? Почему ты думаешь, что поступающие данные можно и нужно сжать? Нужно первым делом проанализировать данные, прежде чем приступать к выбору алгоритма.

Сообщение от AlexChek

По поводу кода Хаффмана, мне ведь все равно придется находить вероятность для каждого числа из диапазона -32 768 до 32 767, разве нет?

Адаптивный алгоритм Хаффмана заметно выигрывает по производительности у обычного алгоритма. Но у меня есть сомнения по поводу эффективности сжатия именно аудиопотока.

@AlexChek · 19.03.2020, 17:01 **[ТС]**

Битрейт примерно 0.33 мбит/сек. Поэтому нужно сжимать

@nonedark2008 · 19.03.2020, 22:46

Сообщение от AlexChek

Битрейт примерно 0.33 мбит/сек. Поэтому нужно сжимать

Я бы не сказал, что это много, но не суть. А что с остальными вопросами? Максимальная задержка?

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

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

@AlexChek 0 / 0 / 0 Регистрация: 19.10.2018 Сообщений: 60
		1
	Сжатие целочисленных данных без потерь 19.03.2020, 00:30. Показов 1409. Ответов 5 Метки compression, с++ (Все метки) Нужно сжать массив/вектор int16_t. Нужен быстрый алгоритм сжатия, т.к. такой массив поступает примерно раз в секунду. Поэтому алгоритм Хафммана отпадает, по поводу LZ семейства не особо уверен, т.к. словарь, как и дерево в Хаффмане будет строиться долго (да и как его использовать для целых не особо понимаю) и ресурсозатратно, по поводу гладкости последовательности не знаю, поэтому дельта + RLE под вопросом. Поэтому не могли бы подсказать какие-то алгоритмы или реализации. 0

@nonedark2008 1394 / 1023 / 325 Регистрация: 28.07.2012 Сообщений: 2,813
	19.03.2020, 01:09	2
	Сообщение от AlexChek Нужно сжать массив/вектор int16_t А какого характера данные? Если они окажутся случайными, то и сжимать их смысла нет. Сообщение от AlexChek такой массив поступает примерно раз в секунду Такой - это какой? За секунду современный компьютер может сделать очень многое. Сообщение от AlexChek да и как его использовать для целых не особо понимаю Сжатие чисел ничем не отличается от сжатия текста. Просто в первом случае у тебя алфавит заметно больше. Но ничто тебе не мешает сжимать не числа, а, скажем, поток байтов. Сообщение от AlexChek алгоритм Хафммана отпадает Можно попробовать адаптивный алгоритм Хаффмана. Дерево строится "на лету", и его не нужно хранить. 0

@AlexChek 0 / 0 / 0 Регистрация: 19.10.2018 Сообщений: 60
	19.03.2020, 01:19 [ТС]	3
	В массиве хранится частоты сигнала (аудио) воспроизводимого за секунду. По поводу кода Хаффмана, мне ведь все равно придется находить вероятность для каждого числа из диапазона -32 768 до 32 767, разве нет? Если да, то это ведь очень ресурсозатратно и долго. Т.е. мне каждую секунду приходят частоты, которые хранятся в массиве, который нужно сжать, а потом уже "распаковать". 0

@nonedark2008 1394 / 1023 / 325 Регистрация: 28.07.2012 Сообщений: 2,813
	19.03.2020, 09:03	4
	Сообщение от AlexChek В массиве хранится частоты сигнала (аудио) воспроизводимого за секунду Какие у тебя ограничения? Битрейт? Требования к задержке? Почему ты думаешь, что поступающие данные можно и нужно сжать? Нужно первым делом проанализировать данные, прежде чем приступать к выбору алгоритма. Сообщение от AlexChek По поводу кода Хаффмана, мне ведь все равно придется находить вероятность для каждого числа из диапазона -32 768 до 32 767, разве нет? Адаптивный алгоритм Хаффмана заметно выигрывает по производительности у обычного алгоритма. Но у меня есть сомнения по поводу эффективности сжатия именно аудиопотока. 0

@AlexChek 0 / 0 / 0 Регистрация: 19.10.2018 Сообщений: 60
	19.03.2020, 17:01 [ТС]	5
	Битрейт примерно 0.33 мбит/сек. Поэтому нужно сжимать 0

@nonedark2008 1394 / 1023 / 325 Регистрация: 28.07.2012 Сообщений: 2,813
	19.03.2020, 22:46	6
	Сообщение от AlexChek Битрейт примерно 0.33 мбит/сек. Поэтому нужно сжимать Я бы не сказал, что это много, но не суть. А что с остальными вопросами? Максимальная задержка? Если не учитывать ограничений на задержку, то нужен алгоритм с производительностью сжатия/разжатия выше, чем 0.33 мбит/сек. Судя по графикам бенчмарков в сети, подойдет большое число различных алгоритмов сжатия, в том числе и некоторые разновидности LZ. Если честно, я уже и не знаю, чем тебе можно помочь. Возьми какой-нибудь готовый бенчмарк с алгоритмами и погоняй на нем свои данные. 0

Опции темы