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

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

Здравствуйте! :)

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

 

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

 

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

 

- ПК (ДОС, все Винды)

- ARM Cortex-M4 (STM32F407), только декодер

 

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

 

post-99126-1521707331_thumb.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

 

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

 

3712_0.jpg

 

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

 

post-59-1521632139.jpg

 

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

 

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

 

PackMan_Codec.zip

 

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

nanoPlay_PackMan.zip

 

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

 

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

Изменено пользователем repstosw

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


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

не смотрели насколько будет лучше/медленнее/прожорливее по памяти:

1) арифметическое кодирование вместо хаффмана, раз уж вэйвлеты вместо DCT,

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

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

?

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


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

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

 

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

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


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

не смотрели насколько будет лучше/медленнее/прожорливее по памяти:

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

Изменено пользователем repstosw

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


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

Фото плеера:

post-99126-1521950265_thumb.jpg

 

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

post-99126-1521950304_thumb.png

 

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

video1.zip

и

video2.zip

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


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

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

nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip

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


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

Чрезвычайно похоже на JPEG-2000, кроме Inter-Frame Difference.

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

 

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

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


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

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

Изменено пользователем repstosw

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


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

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

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

huffman.txt

 

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

Изменено пользователем repstosw

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


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

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

huffman.txt

 

Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью 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 путь - написать свой, взяв всё лучшее со всех.

 

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

 

Осмелюсь предположить, что на живой картинке адаптивный Хаффман даст несущественный выигрыш. На мультиках, вероятно, в нем есть толк. Измерял для (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.

 

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

 

post-99126-1522066647_thumb.jpg)

Изменено пользователем repstosw

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


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

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...