Перейти к содержанию

Разработан новый Lossless видео-кодек

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

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

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

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

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

[attachment=111671:_1.jpg]

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

Подробное описание здесь: 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

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

[attachment=111672:PackMan_Codec.zip]

Исходники декодера для STM32F407, вывод оптимизирован, параллельно играет FLAC с asm-оптимизацией:
[attachment=111673:nanoPlay_PackMan.zip]

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

Замечания, пожелания, эксперименты и предложения по улучшению сжатия кодера и/или скорости декодера приветствуются! help.gif
Изменено пользователем __inline__

Поделиться сообщением


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(__inline__ @ Mar 22 2018, 11:38) <{POST_SNAPBACK}>
...пожелания...


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(_pv @ Mar 22 2018, 09:09) <{POST_SNAPBACK}>
не смотрели насколько будет лучше/медленнее/прожорливее по памяти:
1) арифметическое кодирование вместо хаффмана, раз уж вэйвлеты вместо DCT,


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

Цитата(_pv @ Mar 22 2018, 09:09) <{POST_SNAPBACK}>
2) 3D wavelet ещё и вдоль временной оси, на 4/8 кадров.

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

Цитата(_pv @ Mar 22 2018, 09:09) <{POST_SNAPBACK}>
3) ну и опциональное квантование можно где-то после третьей стадии добавить, чтобы "легким движением руки lossless превращается..."

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

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

Цитата(petrov @ Mar 22 2018, 10:16) <{POST_SNAPBACK}>
Можно привести список избранной литературы, которую вы использовали, чтобы начинающие могли в теории разобраться?


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

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__

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Фото плеера:
[attachment=111720:nanoPlayer.jpg]

Принципиальная схема (элементы, помеченные как NC - отсутствуют):
[attachment=111721:nanoP.gif]

Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата):
[attachment=111722:video1.zip]
и
[attachment=111723:video2.zip]

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264):
[attachment=111724:nanoPlay...PEG_H264.zip]

Поделиться сообщением


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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(x736C @ Mar 25 2018, 12:31) <{POST_SNAPBACK}>
Чрезвычайно похоже на 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, декодер остался тем же. Когда отлажу, выложу.

Цитата(x736C @ Mar 25 2018, 12:31) <{POST_SNAPBACK}>
Еще хотелось бы понять цель вашей разработки. Конкретного железа на фотографиях. Задача в том, чтобы на дисплей небольшой железки выводить короткие фрагменты видео (заставку к примеру)?


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А Хаффман у вас адаптивный используется?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(petrov @ Mar 26 2018, 10:20) <{POST_SNAPBACK}>
А Хаффман у вас адаптивный используется?

Хороший вопрос! sm.gif Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
[attachment=111746:huffman.txt]

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(__inline__ @ Mar 26 2018, 12:33) <{POST_SNAPBACK}>
Хороший вопрос! sm.gif Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
[attachment=111746:huffman.txt]

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


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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(petrov @ Mar 26 2018, 09:52) <{POST_SNAPBACK}>
Ещё как ваш алгоритм восстанавливается после ошибок, нет ли катастрафического распространения, больших выпадений?

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

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


Цитата(thermit @ Mar 26 2018, 10:01) <{POST_SNAPBACK}>
Адаптивный.

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

Поделиться сообщением


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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(x736C @ Mar 26 2018, 11:25) <{POST_SNAPBACK}>
Переформулирую вопрос. Чем Вас не устраивали готовые кодеки? Зачем потребовалось изобретать велосипед. Даже с учетом некоторого выигрыша в степени сжатия. Академический интерес или прикладной?

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

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

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

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

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

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

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

Цитата(x736C @ Mar 26 2018, 11:25) <{POST_SNAPBACK}>
Осмелюсь предположить, что на живой картинке адаптивный Хаффман даст несущественный выигрыш. На мультиках, вероятно, в нем есть толк. Измерял для (M)JPEG. Адаптивный давал до 50% выигрыша на очень сильном сжатии, когда от картинки мало что оставалось. При небольшом сжатии 1,5-2% от силы. Как он будет себя вести для lossless в сущности не знаю, только догадываюсь.


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

Пробовал применить 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.

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

[attachment=111748:Multi_S.jpg])
Изменено пользователем __inline__

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация