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

[x736C]

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

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

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

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

Сообщение отредактировал x736C - Mar 26 2018, 15:36

[enclis_]

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

[_pv]

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

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

Нам удалось воспроизвести видео с разрешением 720p@800 Кбит/с почти гладко на компьютере на базе процессора AMD FX8350

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

[__inline__]

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

AV1 и VP9 - не lossless.

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

[enclis_]

AV1 и VP9 - не lossless.

Ну если топикстартер считает, что 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

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

По ссылке:

News:
[19.09.2005] Выложена версия 0.6.0.
....

Эта лаборатория уже давно забила на свой кодек и занимается 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 лет.

[__inline__]

Ну если топикстартер считает, что 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.

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

[__inline__]

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

Код

rem VP9 кодек Lossless конфа
ffmpeg -i 0.avi -c:v libvpx-vp9 -lossless 1 output.webm

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

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

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

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

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

[__inline__]

Чтоб не быть голословным: сделал и закачал архив(ссылка ниже), в котором результаты сжатия трёх кодеков:
- 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

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

[__inline__]

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


Исходники усовершенствованного декодера для nanoPlayer:
 nanoPlay_PackMan2.zip ( 1.05 мегабайт ) Кол-во скачиваний: 21


Вариант печатной платы (4-слойка) герберы:
 nanoPlay_Gerber.zip ( 27.72 килобайт ) Кол-во скачиваний: 17


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

[enclis_]

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

[Wild]

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

Сообщение отредактировал Wild - May 16 2018, 14:51

[__inline__]

Всем привет!

В связи с освоением процессора 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

Сообщение отредактировал __inline__ - Aug 6 2018, 09:44

[Aner]

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

[__inline__]

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

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