Разработан новый Lossless видео-кодек, Битэкзактный Опции

[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 - это "ОДНА ИЗ ВСЕХ" возможностей, которых много. Поэтому гибче софтово было решить.