Разработан новый Lossless видео-кодек, Битэкзактный Опции

[__inline__]

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

Разработан битэкзактный 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

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

 PackMan_Codec.zip ( 738.09 килобайт ) Кол-во скачиваний: 28


Исходники декодера для STM32F407, вывод оптимизирован, параллельно играет FLAC с asm-оптимизацией:
 nanoPlay_PackMan.zip ( 1.05 мегабайт ) Кол-во скачиваний: 23


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

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

Сообщение отредактировал __inline__ - Mar 22 2018, 08:38

[_pv]

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

[petrov]

...пожелания...

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

[__inline__]

не смотрели насколько будет лучше/медленнее/прожорливее по памяти:
1) арифметическое кодирование вместо хаффмана, раз уж вэйвлеты вместо DCT,

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

2) 3D wavelet ещё и вдоль временной оси, на 4/8 кадров.

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

3) ну и опциональное квантование можно где-то после третьей стадии добавить, чтобы "легким движением руки lossless превращается..."

Изначально планировал 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-листинги компилируемой программы

Сообщение отредактировал __inline__ - Mar 24 2018, 04:06

[__inline__]

Фото плеера:


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


Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата):
 video1.zip ( 1.01 мегабайт ) Кол-во скачиваний: 15

и
 video2.zip ( 744.68 килобайт ) Кол-во скачиваний: 15

[__inline__]

Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264):
 nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip ( 4.43 мегабайт ) Кол-во скачиваний: 24

[x736C]

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

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

[__inline__]

Чрезвычайно похоже на 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 минут каждый.

Сообщение отредактировал __inline__ - Mar 26 2018, 09:18

[petrov]

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

[__inline__]

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

Хороший вопрос! Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
 huffman.txt ( 5.45 килобайт ) Кол-во скачиваний: 47


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

Сообщение отредактировал __inline__ - Mar 26 2018, 09:35

[petrov]

Хороший вопрос! Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
 huffman.txt ( 5.45 килобайт ) Кол-во скачиваний: 47


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

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

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

[thermit]

Адаптивный.

[__inline__]

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

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

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

Адаптивный.

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

[x736C]

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

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

[__inline__]

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

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

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

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

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

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

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

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

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

Жал много фильмов, мультфильмов, коэффициент сжатия был не ниже 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.

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

)

Сообщение отредактировал __inline__ - Mar 26 2018, 12:23