|
Разработан новый Lossless видео-кодек, Битэкзактный |
|
|
|
Mar 22 2018, 08:38
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Здравствуйте! Решил поделиться с общественностью своими наработками в области сжатия видео без потери качества. Разработан битэкзактный 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
|
|
|
|
|
Mar 24 2018, 04:02
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 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 Но потом понял, что это слишком легко, часть коэффициентов - особенно сильно ВЧ можно обнулить, те что более НЧ проквантовать, 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-Transformhttps://github.com/VadimKirilchuk/jawelet/w...velet-Transform3) всякие научные статьи учёных деятелей (индусских в основном), чьи перлы просочились через интернет 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.jsphttp://www.keil.com/support/man/docs/armasm/или хотя-бы для начала: https://www.compel.ru/lib/ne/2012/6/3-bogat...yadre-cortex-m47) И смотреть чё делается в критических местах: ASM-листинги компилируемой программы
Сообщение отредактировал __inline__ - Mar 24 2018, 04:06
|
|
|
|
|
Mar 25 2018, 03:59
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Фото плеера:
Принципиальная схема (элементы, помеченные как NC - отсутствуют):
Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата):
video1.zip ( 1.01 мегабайт )
Кол-во скачиваний: 15и
video2.zip ( 744.68 килобайт )
Кол-во скачиваний: 15
|
|
|
|
|
Mar 26 2018, 09:16
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 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
|
|
|
|
|
Mar 26 2018, 09:33
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Цитата(petrov @ Mar 26 2018, 10:20) А Хаффман у вас адаптивный используется? Хороший вопрос! Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
huffman.txt ( 5.45 килобайт )
Кол-во скачиваний: 47Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана.
Сообщение отредактировал __inline__ - Mar 26 2018, 09:35
|
|
|
|
|
Mar 26 2018, 09:52
|
Гуру
Группа: Свой
Сообщений: 2 220
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937
|
Цитата(__inline__ @ Mar 26 2018, 12:33) Хороший вопрос! Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет?
huffman.txt ( 5.45 килобайт )
Кол-во скачиваний: 47Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана. Я не специалист, самому интернесно у знающих людей спросить, если не адаптивный, может для ваших элементов сжимаемых статистика чужого Хаффмана плохо подходит? Ещё как ваш алгоритм восстанавливается после ошибок, нет ли катастрафического распространения, больших выпадений?
|
|
|
|
|
Mar 26 2018, 10:20
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 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 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием.
|
|
|
|
|
Mar 26 2018, 12:17
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 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. Конечно, если жать белый шум, то выигрыша не даст Пробовал применить 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
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|