У меня есть видео со стационарной камеры. И разрешение, и FPS довольно высоки. Я получаю данные в формате Байера и использует 10 бит на пиксель. Поскольку на моей платформе нет 10-битного типа данных, исходные данные хранятся в памяти с использованием 16-битных слов. Я хочу реализовать какое-то сжатие данных без потерь перед их передачей по сети.
- Камера не движется, поэтому большие части последовательных кадров практически идентичны, но все же не полностью, из-за неизбежного шума (шумоподавление не вариант, так как предполагается, что он не имеет потерь и не должен «терять» даже шум ).
- Из-за высокого FPS даже части, которые меняются, мало меняются между любыми двумя последовательными кадрами.
- Впрочем, похоже, что камера тоже немного качается. Очень мало, но, тем не менее, даже неподвижные объекты не совсем так в пространстве изображения.
- Сжатие должно быть сделано на лету, поэтому я не могу собрать много кадров и сжать их все вместе, но я могу просмотреть 1 кадр назад и использовать его в качестве ссылки.
Исходя из вышеизложенного, моей первой мыслью было упаковать данные в биты, чтобы эти 6 избыточных бит не были потрачены впустую на каждое слово. Однако я подумал, что если я использую какое-то энтропийное кодирование (например, Хаффмана и т. Д.), Эта избыточность будет автоматически учтена, поэтому дополнительная упаковка не требуется. Итак, я сделал следующее:
- Взял двоичную разницу между двумя последовательными кадрами. Исходный диапазон данных был 0 ~ 1023 (например, 10-бит без знака). Разностные данные становятся подписанными, и диапазон увеличивается до -1023 ~ 1023, но разброс данных (или каков правильный математический термин) становится намного меньше, чем в исходных данных, на самом деле, большинство значений, что неудивительно, близко к нулю ,
- Прикладное рисование кодирования к разнице. Из того, что я понимаю, это выглядит как хороший выбор для наборов данных, в основном небольших числовых значений.
Это дает мне примерно 60% уменьшение размера для кадров 1280x720, и моя тестовая система (Linux в VirtualBox на одном ядре) может делать ~ 40 таких сжатий в секунду (без особой оптимизации). Не так здорово, но разумно, я думаю (или это?).
Есть ли лучшие способы? Любые распространенные ошибки, которые я сделал? Какие общие шаги я пропустил? Кадры с более высоким разрешением могут быть использованы позже - следует ли ожидать более высоких коэффициентов сжатия для больших размеров кадров?
UPD .:
- Я использовал эту библиотеку для кодирования Райса. Библиотека очень медленная (сам автор описывает ее как нечто для изучения, а не для реального использования), например, она читает и записывает биты один за другим в циклах, что снижает производительность. Первоначально он дал мне всего ~ 20 FPS, после некоторой базовой оптимизации он стал 40 FPS (как сообщалось выше), позже я оптимизировал его еще немного, он стал 80. Это на одном ядре i7 без векторизации.
- Что касается векторизации, хотя, к сожалению, я не мог придумать способ векторизации кода Райса (даже не знаю, возможен ли он вообще - не смог найти никаких данных о коде Райса, что я смог найти в коде Хаффмана, говорит о том, что он последовательный и не может быть эффективно векторизован, что может применяться к коду Райса, а также к другим кодам переменной длины).
- Я также попробовал совершенно другой подход: разбить данные на маленькие кусочки (например, по 64 пикселя за штуку) и использовать простое подавление нуля . Мы находим наибольшее число в блоке, записываем количество битов, необходимых для его представления, в начало блока (в моем случае для этого потребовалось 4 дополнительных бита), затем уменьшаем все числа в блоке до одинакового числа. биты. Я ожидал, что степень сжатия будет плохой, но если части будут маленькими, у многих из них не будет пиковых шумов, поэтому их двоичная разница может быть уменьшена до примерно 4 ~ 6 битов на значение, и это было, фактически, только примерно на 5% хуже, чем в коде Райса, но в два раза быстрее (например, 160 FPS для моего случая). Я пытался векторизовать его, но я вроде как сосал векторизацию, так что, возможно, из-за этого я мог добиться лишь примерно 1,8 увеличения скорости.
Поскольку отрицательные числа не имеют ведущих нулей, я применил зигзагообразное кодирование после двоичной разницы и до подавления Райса / нуля.