repstosw 18 22 марта, 2018 Опубликовано 22 марта, 2018 (изменено) · Жалоба Здравствуйте! :) Решил поделиться с общественностью своими наработками в области сжатия видео без потери качества. :yeah: Разработан битэкзактный 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 Исходники декодера для STM32F407, вывод оптимизирован, параллельно играет FLAC с asm-оптимизацией: nanoPlay_PackMan.zip Кодек зарелижен, оттестирован. Битэкзактный на уровне 6 бит (специфика железа) Замечания, пожелания, эксперименты и предложения по улучшению сжатия кодера и/или скорости декодера приветствуются! Изменено 22 марта, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 78 22 марта, 2018 Опубликовано 22 марта, 2018 · Жалоба не смотрели насколько будет лучше/медленнее/прожорливее по памяти: 1) арифметическое кодирование вместо хаффмана, раз уж вэйвлеты вместо DCT, 2) 3D wavelet ещё и вдоль временной оси, на 4/8 кадров. 3) ну и опциональное квантование можно где-то после третьей стадии добавить, чтобы "легким движением руки lossless превращается..." ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 22 марта, 2018 Опубликовано 22 марта, 2018 · Жалоба ...пожелания... Можно привести список избранной литературы, которую вы использовали, чтобы начинающие могли в теории разобраться? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 24 марта, 2018 Опубликовано 24 марта, 2018 (изменено) · Жалоба не смотрели насколько будет лучше/медленнее/прожорливее по памяти: 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-листинги компилируемой программы Изменено 24 марта, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 25 марта, 2018 Опубликовано 25 марта, 2018 · Жалоба Фото плеера: Принципиальная схема (элементы, помеченные как NC - отсутствуют): Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата): video1.zip и video2.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 25 марта, 2018 Опубликовано 25 марта, 2018 · Жалоба Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264): nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 25 марта, 2018 Опубликовано 25 марта, 2018 · Жалоба Чрезвычайно похоже на JPEG-2000, кроме Inter-Frame Difference. Интересно было бы посмотреть какую-нибудь таблицу сравнения вашего кодека с аналогами хотя бы по эффективности кодирования. Понятно, что сравнение производительности кодеков для конкретных МК, фрагментов, параметров сжатия — достаточно трудоемкая задача. Еще хотелось бы понять цель вашей разработки. Конкретного железа на фотографиях. Задача в том, чтобы на дисплей небольшой железки выводить короткие фрагменты видео (заставку к примеру)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 26 марта, 2018 Опубликовано 26 марта, 2018 (изменено) · Жалоба Чрезвычайно похоже на 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 минут каждый. Изменено 26 марта, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 26 марта, 2018 Опубликовано 26 марта, 2018 · Жалоба А Хаффман у вас адаптивный используется? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 26 марта, 2018 Опубликовано 26 марта, 2018 (изменено) · Жалоба А Хаффман у вас адаптивный используется? Хороший вопрос! :) Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет? huffman.txt Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана. Изменено 26 марта, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 26 марта, 2018 Опубликовано 26 марта, 2018 · Жалоба Хороший вопрос! :) Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет? huffman.txt Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана. Я не специалист, самому интернесно у знающих людей спросить, если не адаптивный, может для ваших элементов сжимаемых статистика чужого Хаффмана плохо подходит? Ещё как ваш алгоритм восстанавливается после ошибок, нет ли катастрафического распространения, больших выпадений? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
thermit 1 26 марта, 2018 Опубликовано 26 марта, 2018 · Жалоба Адаптивный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 26 марта, 2018 Опубликовано 26 марта, 2018 · Жалоба Ещё как ваш алгоритм восстанавливается после ошибок, нет ли катастрафического распространения, больших выпадений? В разработанном устройстве "nanoPlayer" и на ПК ошибок нет и быть не может (при условии, если настройка режимов ядра и периферии выполнены корректно). Если же говорить о линии связи или промежуточном агенте переноса информации (радиоволны, оптоволокно и прочее...), то в данном кодеке используется форсированная вставка ключевого фрейма - каждый 12-й кадр, что даёт время восстановления 1 секунду при 12 FPS. В новой ревизии 1 кодека, ключевой кадр может идти чаще, но не реже, чем 1 раз на 12 кадров. Адаптивный. Ok, спасибо! Я перепробовал 4 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 26 марта, 2018 Опубликовано 26 марта, 2018 · Жалоба Переформулирую вопрос. Чем Вас не устраивали готовые кодеки? Зачем потребовалось изобретать велосипед. Даже с учетом некоторого выигрыша в степени сжатия. Академический интерес или прикладной? Осмелюсь предположить, что на живой картинке адаптивный Хаффман даст несущественный выигрыш. На мультиках, вероятно, в нем есть толк. Измерял для (M)JPEG. Адаптивный давал до 50% выигрыша на очень сильном сжатии, когда от картинки мало что оставалось. При небольшом сжатии 1,5-2% от силы. Как он будет себя вести для lossless в сущности не знаю, только догадываюсь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 26 марта, 2018 Опубликовано 26 марта, 2018 (изменено) · Жалоба Переформулирую вопрос. Чем Вас не устраивали готовые кодеки? Зачем потребовалось изобретать велосипед. Даже с учетом некоторого выигрыша в степени сжатия. Академический интерес или прикладной? Рассматривал 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. Восклицательным знаком помечены те варианты, которые были распознаны как оптимальные по сжатию. (подсчитал статистику по стратегиям ) Изменено 26 марта, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться