реклама на сайте
подробности

 
 
2 страниц V   1 2 >  
Reply to this topicStart new topic
> Разработан новый Lossless видео-кодек, Битэкзактный
__inline__
сообщение Mar 22 2018, 08:38
Сообщение #1


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



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

Разработан битэкзактный 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 килобайт ) Кол-во скачиваний: 23


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


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

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

Сообщение отредактировал __inline__ - Mar 22 2018, 08:38
Go to the top of the page
 
+Quote Post
_pv
сообщение Mar 22 2018, 09:09
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 2 502
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954



не смотрели насколько будет лучше/медленнее/прожорливее по памяти:
1) арифметическое кодирование вместо хаффмана, раз уж вэйвлеты вместо DCT,
2) 3D wavelet ещё и вдоль временной оси, на 4/8 кадров.
3) ну и опциональное квантование можно где-то после третьей стадии добавить, чтобы "легким движением руки lossless превращается..."
?
Go to the top of the page
 
+Quote Post
petrov
сообщение Mar 22 2018, 10:16
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 2 194
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937



Цитата(__inline__ @ Mar 22 2018, 11:38) *
...пожелания...


Можно привести список избранной литературы, которую вы использовали, чтобы начинающие могли в теории разобраться?
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 24 2018, 04:02
Сообщение #4


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



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


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

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

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

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

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

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

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


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

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
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 25 2018, 03:59
Сообщение #5


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



Фото плеера:
Прикрепленное изображение


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


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

и
Прикрепленный файл  video2.zip ( 744.68 килобайт ) Кол-во скачиваний: 12
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 25 2018, 07:17
Сообщение #6


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264):
Прикрепленный файл  nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip ( 4.43 мегабайт ) Кол-во скачиваний: 21
Go to the top of the page
 
+Quote Post
x736C
сообщение Mar 25 2018, 11:31
Сообщение #7


Профессионал
*****

Группа: Участник
Сообщений: 1 258
Регистрация: 3-03-06
Пользователь №: 14 942



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

Еще хотелось бы понять цель вашей разработки. Конкретного железа на фотографиях. Задача в том, чтобы на дисплей небольшой железки выводить короткие фрагменты видео (заставку к примеру)?
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 26 2018, 09:16
Сообщение #8


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



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


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

Сообщение отредактировал __inline__ - Mar 26 2018, 09:18
Go to the top of the page
 
+Quote Post
petrov
сообщение Mar 26 2018, 09:20
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 2 194
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937



А Хаффман у вас адаптивный используется?
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 26 2018, 09:33
Сообщение #10


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



Цитата(petrov @ Mar 26 2018, 10:20) *
А Хаффман у вас адаптивный используется?

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


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

Сообщение отредактировал __inline__ - Mar 26 2018, 09:35
Go to the top of the page
 
+Quote Post
petrov
сообщение Mar 26 2018, 09:52
Сообщение #11


Гуру
******

Группа: Свой
Сообщений: 2 194
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937



Цитата(__inline__ @ Mar 26 2018, 12:33) *
Хороший вопрос! sm.gif Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
Прикрепленный файл  huffman.txt ( 5.45 килобайт ) Кол-во скачиваний: 39


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


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

Ещё как ваш алгоритм восстанавливается после ошибок, нет ли катастрафического распространения, больших выпадений?
Go to the top of the page
 
+Quote Post
thermit
сообщение Mar 26 2018, 10:01
Сообщение #12


Знающий
****

Группа: Участник
Сообщений: 770
Регистрация: 3-08-09
Пользователь №: 51 730



Адаптивный.
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 26 2018, 10:20
Сообщение #13


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



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

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

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


Цитата(thermit @ Mar 26 2018, 10:01) *
Адаптивный.

Ok, спасибо!
Я перепробовал 4 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием.
Go to the top of the page
 
+Quote Post
x736C
сообщение Mar 26 2018, 11:25
Сообщение #14


Профессионал
*****

Группа: Участник
Сообщений: 1 258
Регистрация: 3-03-06
Пользователь №: 14 942



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

Осмелюсь предположить, что на живой картинке адаптивный Хаффман даст несущественный выигрыш. На мультиках, вероятно, в нем есть толк. Измерял для (M)JPEG. Адаптивный давал до 50% выигрыша на очень сильном сжатии, когда от картинки мало что оставалось. При небольшом сжатии 1,5-2% от силы. Как он будет себя вести для lossless в сущности не знаю, только догадываюсь.
Go to the top of the page
 
+Quote Post
__inline__
сообщение Mar 26 2018, 12:17
Сообщение #15


Частый гость
**

Группа: Участник
Сообщений: 159
Регистрация: 5-09-17
Пользователь №: 99 126



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

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

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

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

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

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

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

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

Цитата(x736C @ Mar 26 2018, 11:25) *
Осмелюсь предположить, что на живой картинке адаптивный Хаффман даст несущественный выигрыш. На мультиках, вероятно, в нем есть толк. Измерял для (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.

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

Прикрепленное изображение
)

Сообщение отредактировал __inline__ - Mar 26 2018, 12:23
Go to the top of the page
 
+Quote Post

2 страниц V   1 2 >
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th June 2018 - 20:13
Рейтинг@Mail.ru


Страница сгенерированна за 0.01091 секунд с 7
ELECTRONIX ©2004-2016