Здравствуйте!
Решил поделиться с общественностью своими наработками в области сжатия видео без потери качества.

Разработан битэкзактный 4,5 ступенчатый Lossless Bitexact кодек видео под названием "PackMan" rev.0.

Кодек соперничает с MSU и Lagarith, исходники открыты и доступны для платформ:

- ПК (ДОС, все Винды)
- ARM Cortex-M4 (STM32F407), только декодер

Конвейер кодера:

Нажмите для просмотра прикрепленного файла

Декодер - обратим.

Подробное описание здесь: http://vrtp.ru/index.php?act=categories&am...mp;article=3713

Про nanoPlayer здесь: http://vrtp.ru/index.php?showtopic=29688&st=90
и здесь: http://vrtp.ru/index.php?act=categories&am...mp;article=3712

Макет плеера:



Релиз будет скоро спаян, печатные платы есть:



Принципиальная схема плеера: http://vrtp.ru/index.php?act=Attach&ty...t&id=769410

Исходники кодера и декодера + билды под форточки, ДОС, скрипт, тестовый образец:

Нажмите для просмотра прикрепленного файла

Исходники декодера для STM32F407, вывод оптимизирован, параллельно играет FLAC с asm-оптимизацией:
Нажмите для просмотра прикрепленного файла

Кодек зарелижен, оттестирован. Битэкзактный на уровне 6 бит (специфика железа)

Замечания, пожелания, эксперименты и предложения по улучшению сжатия кодера и/или скорости декодера приветствуются!

не смотрели насколько будет лучше/медленнее/прожорливее по памяти:
1) арифметическое кодирование вместо хаффмана, раз уж вэйвлеты вместо DCT,
2) 3D wavelet ещё и вдоль временной оси, на 4/8 кадров.
3) ну и опциональное квантование можно где-то после третьей стадии добавить, чтобы "легким движением руки lossless превращается..."
?

Можно привести список избранной литературы, которую вы использовали, чтобы начинающие могли в теории разобраться?

делал, жмёт лучше (пример: 205 вместо 240 МБ), но на ПК (3 ГГц) скорость воспроизведения декодированного видео в 2 раза медленее.
Реализация: "Д. Мастрюков, "Монитор", N1, 1994. Алгоритмы сжатия информации. Адаптивное арифметическое кодирование. Демонстративная программа."


Встроенной РАМы STM32F407 не хватит.


Изначально планировал Lossy Но потом понял, что это слишком легко, часть коэффициентов - особенно сильно ВЧ можно обнулить, те что более НЧ проквантовать, Low оставить без изменений. Да, была фантастика - сжатие в несколько десятков раз, но c артефактами вокруг чётких контуров.

У меня есть пара идей как усовершенствовать кодек. Первая идея даже не требует изменения алгоритма декодера. Вторая - с пересмотром алгоритмов обоих.



Интернет. Без шуток...

0) http://compression.ru/

1) описание JPEG, JPEG2000 - трудностей с поиском не должно возникнуть

2) Хабр:
https://habrahabr.ru/post/168517/
https://habrahabr.ru/post/169615/
и
https://habrahabr.ru/post/142242/
https://habrahabr.ru/post/142492/
и
https://github.com/VadimKirilchuk/jawelet/w...velet-Transform
https://github.com/VadimKirilchuk/jawelet/w...velet-Transform

3) всякие научные статьи учёных деятелей (индусских в основном), чьи перлы просочились через интернет

4) github.com , pudn.com - исходные тексты кодеров Хаффмана, RLE, арифметик-кодера. Много нерабочего говнокода!!! Надо проверять на правильность работы и фильтровать!

5) Ну и конечно, сам Бог велел:
https://hightech.in.ua/content/art-c-cpp-co...ler-for-windows или http://pmg.org.ru/gamedev/djgpp.htm - на выбор.

6) Ну и без этого не достичь большой скорости декодирования:
http://infocenter.arm.com/help/index.jsp
http://www.keil.com/support/man/docs/armasm/

или хотя-бы для начала:
https://www.compel.ru/lib/ne/2012/6/3-bogat...yadre-cortex-m4

7) И смотреть чё делается в критических местах: ASM-листинги компилируемой программы

Фото плеера:
Нажмите для просмотра прикрепленного файла

Принципиальная схема (элементы, помеченные как NC - отсутствуют):
Нажмите для просмотра прикрепленного файла

Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата):
Нажмите для просмотра прикрепленного файла
и
Нажмите для просмотра прикрепленного файла

Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264):
Нажмите для просмотра прикрепленного файла

Чрезвычайно похоже на JPEG-2000, кроме Inter-Frame Difference.
Интересно было бы посмотреть какую-нибудь таблицу сравнения вашего кодека с аналогами хотя бы по эффективности кодирования. Понятно, что сравнение производительности кодеков для конкретных МК, фрагментов, параметров сжатия — достаточно трудоемкая задача.

Еще хотелось бы понять цель вашей разработки. Конкретного железа на фотографиях. Задача в том, чтобы на дисплей небольшой железки выводить короткие фрагменты видео (заставку к примеру)?

Я конечно могу привести таблицу, но поверят ли? Проще проверить было самому.

Тесты:

1)
"Винни-Пух": 211 МБ С учётом 6 бит из 8: 158.25 МБ
PackMan rev.0: 59.6 МБ
PackMan rev.1: 56.9 МБ
Lagarith: 69.4 МБ
MSU: 46 МБ

2)
"Yurizan Beltran": 406 МБ С учётом 6 бит из 8: 304.5 МБ
PackMan rev.0: 106 МБ
PackMan rev.1: 102 МБ
Lagarith: 98.5 МБ
MSU: 97.7 МБ

3)
"Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ
PackMan rev.0: 225 МБ
PackMan rev.1: 211 МБ
Lagarith: 240 МБ
MSU: 178 МБ

4)
"Ashton Pierce": 877 МБ С учётом 6 бит из 8: 657.75 МБ
PackMan rev.0: 234 МБ
PackMan rev.1: 228 МБ
Lagarith: 242 МБ
MSU: 247 МБ

Во втором случае кодек проиграл всем остальным по сжатию.
В четвертом случае - победил всех.
В большинстве случаев разработанный кодек между Lagarith и MSU по степени сжатия, при этом не уступающий в скорости кодирования-декодирования (про MSU лучше вообще не вспоминать, там где нужна скорость декодирования)

Реализовал улучшенный вариант кодера: PackMan rev.1, декодер остался тем же. Когда отлажу, выложу.



Я смотрел на ней[железке] весь сериал "Space Cobra" все 31 эпизодов по 25 минут каждый.

А Хаффман у вас адаптивный используется?

Хороший вопрос! Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
Нажмите для просмотра прикрепленного файла

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

Я не специалист, самому интернесно у знающих людей спросить, если не адаптивный, может для ваших элементов сжимаемых статистика чужого Хаффмана плохо подходит?

Ещё как ваш алгоритм восстанавливается после ошибок, нет ли катастрафического распространения, больших выпадений?

Адаптивный.

В разработанном устройстве "nanoPlayer" и на ПК ошибок нет и быть не может (при условии, если настройка режимов ядра и периферии выполнены корректно).
Если же говорить о линии связи или промежуточном агенте переноса информации (радиоволны, оптоволокно и прочее...), то в данном кодеке используется форсированная вставка ключевого фрейма - каждый 12-й кадр, что даёт время восстановления 1 секунду при 12 FPS.

В новой ревизии 1 кодека, ключевой кадр может идти чаще, но не реже, чем 1 раз на 12 кадров.



Ok, спасибо!
Я перепробовал 4 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием.

Переформулирую вопрос. Чем Вас не устраивали готовые кодеки? Зачем потребовалось изобретать велосипед. Даже с учетом некоторого выигрыша в степени сжатия. Академический интерес или прикладной?

Осмелюсь предположить, что на живой картинке адаптивный Хаффман даст несущественный выигрыш. На мультиках, вероятно, в нем есть толк. Измерял для (M)JPEG. Адаптивный давал до 50% выигрыша на очень сильном сжатии, когда от картинки мало что оставалось. При небольшом сжатии 1,5-2% от силы. Как он будет себя вести для lossless в сущности не знаю, только догадываюсь.

Рассматривал JPEG2000 Lossless, его программная реализация (которая есть в открытом виде) - очень громоздка для переноса на МК STM32F407 и алгоритм просто не пошёл (из-за применения менеджера кучи для данных и кода). К тому же, кодек MJPEG2000 Lossless проигрывает по степени сжатия даже тому же Lagrith.

Dirac - тоже жмет хуже Lagarith и требует много вычислительных ресурсов.

HuffYUV - прост, но хуже всех жал.

MSU - нет исходников

Lagarith - хотел вначале портировать его, но мой кодек его обскакал по сжатию (в анимешных мультфильмах)

Остался 1 путь - написать свой, взяв всё лучшее со всех.

Я - человек науки, поэтому тут ещё дополнительно академический интерес.



Жал много фильмов, мультфильмов, коэффициент сжатия был не ниже 2. Обычно от 2.8 - 3.
Конечно, если жать белый шум, то выигрыша не даст

Пробовал применить ZLIB, слишком затратно по времени на декодирование. LZH тоже. Так что только энтропийное кодирование.

----------------------------------

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

Если исходный сигнал у нас - это RGB, то блоков конвеера у нас 5:

1) преобразование YCbCr
2) WaveLet преобразование
3) Difference преобразование (межкадровое вычитание)
4) Huffman
5) RLE

Просчитал, возможно 64 комбинации, они на рисунке ниже.
Написал кодер, прогнал вариант 3):

"Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ
PackMan rev.0: 225 МБ
PackMan rev.1: 211 МБ

получилось 187 МБ против 211, что неплохо!
Причем задача декодирования нисколько не усложняется, а наоборот даже - в некоторых случаях конвейер декода будет короче, номер стратегии пишется в хедер - каждый номер определяет жестко заданный порядок декодирования . Это немаловажно для STM32F407.

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

Нажмите для просмотра прикрепленного файла)

Спасибо за ответ.


Уточню, т.к. мне показалось, что вы неверно меня поняли.
Имел в виду не коэффициент сжатия, а сравнение сжатия по Хаффману адаптивное и со стандартными таблицами. Включая адаптивное, получал прирост 1-2% к уже имеющемуся коэффициенту сжатия. Когда слов для Хаффмана становилось совсем мало (при сильном сжатии), то и стандартные таблицы сильно проигрывают. Если их пересчитать, то можно сжать порой вполовину лучше. При этом, правда, картинка будет непригодна для использования в большинстве применений. В вашем же случае, стандартных таблиц нет, их можно наработать на тестовых целевых фрагментах.

По поводу «Мульти-Стратегического кодека». Имхо, игра не стоит свеч. Все-таки для lossless выжимание процентов не так актуально, как для сжатия с потерями.

Lagarith, HuffYUV, MSU - это же всё древние кодеки. Где сравнение с AV1 или хотя бы VP9?

если не заметили, речь про stm32f4.
про AV1 нагуглилось вот это:

даже то что у ТС разрешение в 4 раза меньше, т.е. в 16 раз меньше пикселей, думаю не особо поможет.
а помимо вычислительной мощности есть ещё требования к памяти.

AV1 и VP9 - не lossless.

MSU - не древний, живёт и процветает до сих пор. http://www.compression.ru/video/ls-codec/
Lagarith я бы не сказал что древний

Ну если топикстартер считает, что AV1 и VP9 не могут в lossless, тогда всё понятно ...
https://trac.ffmpeg.org/wiki/Encode/VP9#LosslessVP9
https://aomediacodec.github.io/av1-spec/

На самом деле у меня появились подозрения ещё когда я попытался найти оригиналы видеороликов под названием "Yurizan Beltran" и "Ashton Pierce". Или это был "хитрый троллинг" ?

Для общего восприятия может быть стоит ознакомиться вот с этим списком:
https://en.wikipedia.org/wiki/List_of_codec...deo_compression


По ссылке:

Эта лаборатория уже давно забила на свой кодек и занимается 3D Video - http://www.compression.ru/video/3d_video.htm (при том что их алгоритмы по большей части уже реализованы в OpenCV и даже на GPU) и сравнением чужих кодеков - http://www.compression.ru/video/codec_comp...n/index_en.html. Благодаря удачному доменному имени, видимо, кто-то даже покупает у них эти сравнительные анализы кодеков.
Lagarith конечно посвежее чем MSU, но ему тоже уже больше 10 лет.

Вам осталось сделать ещё один небольшой рывок - доказать, что AV1 и VP9 битэкзактны. Есть сомнения по поводу.
Ну и глупо искать по нарицательным именам конкретные видеоролики, тем более версии, заточенные под 160x128.

Но ваш намёк понял - вот вам моё встречное напутствие: встречного ветра и якорь вам в...

Всё-же уделил время на VP9 и затестил его в режиме лосслесс через ffmmpeg:



Результат обнадёжил : 390 МБ против моих:

Packman rev.0: 234 МБ
rev. 1: 228 МБ
Мультистратегический: 224 МБ

Лагариф и МСУ также лучше: 242 и 247 МБ соответственно.

Так что хвалёный VP9 на лосслесс оказался хуже "старых" добрых MSU и Lagarith. И жмёт ещё долго, по сравнению с PackMan и Lagarith.

Выводы я сделал.

Чтоб не быть голословным: сделал и закачал архив(ссылка ниже), в котором результаты сжатия трёх кодеков:
- VP9: 18.1 МБ
- Lagarith: 12.8 МБ
-PackMan v.2 (мульти-стратегический): 12.6 МБ

Исходное видео: 52.3 МБ что при пересчёте с 8 на 6 бит на компоненту - в эквиваленте 39.23 МБ (младшие 2 бита каждой цветовой компоненты оригинального видео =0).

Там же бат-скрипты, утилита для воспроизведения ffplay и новая версия кодера/декодера PackMan (мультистратегический).

На более длинных видео - результат будет ещё лучше в пользу PackMan

Архив:
https://dropfiles.org/2Sn

пароль к архиву 13169

Усовершенствованный вариант Lossless видео-кодека "PackMan" - с мульти-стратегическим конвейером. Теперь жмёт ещё лучше! Не совместим с ранними версиями !
Исходники усовершенствованного кодера/декодера, там же и билды под Win32, DOS:
Нажмите для просмотра прикрепленного файла

Исходники усовершенствованного декодера для nanoPlayer:
Нажмите для просмотра прикрепленного файла

Вариант печатной платы (4-слойка) герберы:
Нажмите для просмотра прикрепленного файла

Демонстрационное видео на ЮТУБ:
http://www.youtube.com/watch?v=ZCZwsP3rf8Y

Спасибо, что сравнили с VP9, он как и AV1 всё-таки предназначен больше для сжатия с потерями.

Крутяк..
Например при проигрывании звука шум -40дб не воспринимается и системы воспроизведения например с 0.5% искажений считаются качественными, в картинках то же самое: многое просто не воспримится или находится на уровне искажений например, сравнимых с светильником рядом с телевизором. Интересен этот баланс. Или как это использовать для создания оптимальных систем сжатия. Безусловно к сжатию видео с Марса, например, это не относится. Не знаю готов ли кто платить за это...

Всем привет!

В связи с освоением процессора STM32H743 на базе отладочной платы Nucleo-H743, были сделаны перенос и модификация Lossless кодека PackMan на разрешение 320x240.
Ветка получила кодовое название "PackMan320".

Подробнее вместе с исходными текстами программ тут: http://vrtp.ru/index.php?showtopic=29688&st=150

Видео(PackMan320 + FLAC) : http://www.youtube.com/watch?v=s2a_DqrIFaw

Ну и попутно ещё сделал декодеры MP4(точнее H.264, пофиксил, у китайцев в коде была ошибка, приводящая к артефактам ) и MP3. Видео: http://www.youtube.com/watch?v=x3sADTqlfj8

Более подробнее - там же: http://vrtp.ru/index.php?showtopic=29688&st=150

Вот зачем все это софтверно, когда давно есть дешевые Hi3516, Hi3518, ... 59A у которых аппаратное решение кодек/декодер, меньшее потребление, кроме H.264 есть там и покруче H.265. Модифицированный Lossless кодек не даст выигрыша более нескольких процентов, и куда его? На полку?

Это здОрово, что есть уже аппаратное решение.
Но в моём случае - возможность воспроизведения видео-потоков PackMan и H264 - это "ОДНА ИЗ ВСЕХ" возможностей, которых много. Поэтому гибче софтово было решить.