Hнда..
Ivan Kuvshinov
Печально, печально..
КИА
Vladimir Leonov
IK> И это называется эха - не сдохла..
IK> Печально, печально..
А есть о чем поговорить?
[pionээr] [nodes over 100]
Ivan Kuvshinov
IK>> Печально, печально..
Поговорить всегда есть о чём. Hе появилось ли какого-нибудь нового метода
сжатия, или эксперементального компилятора, сделавшего прорыв в BWT и как там
и подобном?
Hу или, хотя бы видео/аудио без потерь.
КИА
Ivan Kuvshinov
И вообще, у меня из-за ентого молчания босс эху грохнул, вот - подписываюсь
теперь..
Кстати, я как-то уже спрашивал, про способы записи чисел не фиксированной
длинны. Hу так, что бы можно было определить где оно кончается (но не по
началу следующего как в префиксном): какие есть варианты?
КИА
Dmitry Belyavsky
Ivan Kuvshinov <k...@mail.cnt.ru> wrote:
VL>> А есть о чем поговорить?
IK> И вообще, у меня из-за ентого молчания босс эху грохнул, вот - подписываюсь
IK> теперь..
IK>
IK> Кстати, я как-то уже спрашивал, про способы записи чисел не фиксированной
IK> длинны. Hу так, что бы можно было определить где оно кончается (но не по
IK> началу следующего как в префиксном): какие есть варианты?
ASN1-нотация?
--
SY, Dmitry Belyavsky (ICQ UIN 11116575)
Ivan Kuvshinov
IK>> кончается (но не по началу следующего как в префиксном): какие есть
IK>> варианты?
DB> ASN1-нотация?
Конкретизируй, я в написанной ниже мути понял только, что это что-то сложно и
большое.
ASN.1
Abstract Syntax Notation One
Формальный язык абстрактного описания синтаксиса 1 - это язык, определяющий
способ передачи данных по различающимся коммуникационным системам. ASN.1
гарантирует, что полученные данные есть именно те данные, которые были
посланы. Используется общий синтаксис для спецификации протоколов прикладного
уровня (связь программа-программа).
Каждая из систем связи содержит одинаковую схему кодирования-декодирования
(согласно ASN.1), написанную на языке, используемом на этой системе. Когда
система собирается передать данные другой системе, первая система кодирует
данные согласно ASN.1, передает их, а вторая система получает, затем
декодирует данные, используя декодер, написанный на языке, используемом в
данной системе.
ASN.1 является стандартом, принятым ISO/ITU, основанным на модели OSI. Впервые
определен в 1984 как часть X.409 комитета CCITT; пересмотрен в 1995; стал
отдельным стандартом, X.208, в 1998.
ASN.1 делится на две части:
(1) правила синтаксиса для описания содержания сообщения в терминах типов
данных и последовательности или структуры содержания сообщения и
(2), как Вы фактически кодируете каждый элемент данных в сообщении.
ASN.1 определен в двух стандартах ISO для приложений, предназначенных для
Соединения Открытых Систем (OSI):
ISO 8824/ITU X.208 определяет синтаксис (например, какой элемент данных в
сообщении идёт первым и к какому типу данных он принадлежит)
ISO 8825/ITU X.209 определяет основные правила кодирования
КИА
Vladimir Leonov
VL>> А есть о чем поговорить?
IK> Поговорить всегда есть о чём. Hе появилось ли какого-нибудь нового
IK> метода сжатия, или эксперементального компилятора, сделавшего прорыв в
IK> BWT и как там и подобном?
/dev/null
IK> Hу или, хотя бы видео/аудио без потерь.
Тогда не подходит. :-)
ЗЫ: Hу раз начали поднимать траффик. то можешь рассказать, как вообще
происходит сжатие? А то я чайник в этом... кроме rar a и rar e не знаю ничего.
:-)
[pionээr] [nodes over 100]
Vladimir Leonov
IK> кончается (но не по началу следующего как в префиксном): какие есть
IK> варианты?
У меня такое подозрение, что тут можно беспорядки устраивать. :-)
[pionээr] [nodes over 100]
Dmitry Belyavsky
IK>>> Кстати, я как-то уже спрашивал, про способы записи чисел не
IK>>> фиксированной длинны. Hу так, что бы можно было определить где оно
IK>>> кончается (но не по началу следующего как в префиксном): какие есть
IK>>> варианты?
DB>> ASN1-нотация?
IK> большое.
Ну как... В общих чертах: сначала обозначается, что мы кодируем (число,
строку...), потом - длину (смотреть в более подробном англоязычном описании,
там достаточно понятно), потом - само число в фиксированном порядке байт.
Ivan Kuvshinov
DB> (число, строку...), потом - длину (смотреть в более подробном
DB> англоязычном описании, там достаточно понятно), потом - само число в
DB> фиксированном порядке байт.
А смысл писать длинну числа? В первых, это такое же конкретное ограничение на
длинну и ничем не лучше, чем просто отдать вместо одного байта несколько. Hет,
конечно смысл есть, но речь шла именно о форме записи самих чисел - оно само
может нести информацию о том где оно кончается, ну наподобие строк
оканчивающихся нулём или префиксного кодирования (для префиксного, опять же
дополнительное число требуется как маркер конца и оно лишь разделять числа друг
от друга, но не показать длинну одного). Грубо говоря, для нужной формы записи
длинна числа будет изменяться в зависимости от потребностей и оно будет лишь
чуть больше по размеру чем обычное число, выражающее то же значение.
КИА
Ivan Kuvshinov
VL> происходит сжатие? А то я чайник в этом... кроме rar a и rar e не знаю
VL> ничего.
Hу да, на примере крутейшего архиватора WIC, ищи в инете, он даже архивы Rar'а
жмёт наполовину. ;-)
КИА
Michael Mamaev
Четвеpг Янваpь 05 2006 06:08, Vladimir Leonov wrote to Ivan Kuvshinov:
IK>> И это называется эха - не сдохла..
IK>> Печально, печально..
VL> А есть о чем поговоpить?
Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего так и не
пpидyмали?
Майкл
Vladimir Leonov
VL>> rar e не знаю ничего.
IK> Hу да, на примере крутейшего архиватора WIC, ищи в инете, он даже
IK> архивы Rar'а жмёт наполовину. ;-)
Шутка?
[pionээr] [nodes over 100]
Ivan Kuvshinov
VL> Шутка?
Wic действительно есть, я как-то им сжимал, но - не без этого. ;-)
КИА
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Dmitry!
Friday January 06 2006, Dmitry Belyavsky writes to "Ivan Kuvshinov":
DB>>> ASN1-нотация?
IK>> Конкретизируй, я в написанной ниже мути понял только, что это
IK>> что-то сложно и большое.
DB> Hу как... В общих чертах: сначала обозначается, что мы кодируем
DB> (число, строку...), потом - длину (смотреть в более подробном
DB> англоязычном описании, там достаточно понятно), потом - само число в
DB> фиксированном порядке байт.
а где его взять? дело в том, что я пишу библиотеку сериализации и хотелось бы
придерживаться при этом общепринятых стандартов, в частности чтобы работать со
всевозможными сетевыми протоколами. network byte order я уже использую, а что
ещё стандартизировано? например, порядок битов в байте какой должен быть?
Bulat, mailto:bulat_z-AT-mail.ru
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Ivan!
Thursday January 05 2006, Ivan Kuvshinov writes to Vladimir Leonov:
IK> Кстати, я как-то уже спрашивал, про способы записи чисел не
IK> фиксированной длинны. Hу так, что бы можно было определить где оно
IK> кончается (но не по началу следующего как в префиксном): какие есть
IK> варианты?
я использую 7+1 метод - в каждом байте 7 бит отводятся на запись чисда и
старший бит - признак того, что этот байт в представлении - последний
Vladimir Leonov
IK>>> Печально, печально..
VL>> А есть о чем поговоpить?
MM> Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего так и
MM> не пpидyмали?
Мне кажется, что и не скоро придумают. Hадобности острой нет. Вот раньше, когда
компы поменьше были надобность была огромная. Понапридумывали архиваторов, mp3
и т.д. Сейчас всё это только для телефонов нужно, а там нового не будут
выдумывать, проще использовать уже имеющееся ибо это дешевле. А вообще, имхо,
если так быстро компы и дальше будут развиваться, то скоро люди забудут что
такое архиватор. :-)
[pionээr] [nodes over 100]
Vladimir Leonov
VL>> Шутка?
IK> Wic действительно есть, я как-то им сжимал, но - не без этого. ;-)
Вот я тоже думаю, что такая шутка не может без потерь сжимать.
[pionээr] [nodes over 100]
Dmitry Belyavsky
Bulat Ziganshin <Bulat.Z...@p126.f4.n5093.z2.fidonet.org> wrote:
DB>> Hу как... В общих чертах: сначала обозначается, что мы кодируем
DB>> (число, строку...), потом - длину (смотреть в более подробном
DB>> англоязычном описании, там достаточно понятно), потом - само число в
DB>> фиксированном порядке байт.
BZ>
BZ> а где его взять? дело в том, что я пишу библиотеку сериализации и хотелось бы
BZ> придерживаться при этом общепринятых стандартов, в частности чтобы работать со
BZ> всевозможными сетевыми протоколами. network byte order я уже использую, а что
BZ> ещё стандартизировано? например, порядок битов в байте какой должен быть?
http://www.oss.com/asn1/organizations.html
Ключевые слова для гугления - DER, ASN1.
Есть ряд библиотек. На C/C++ заниматься - жуть на лапках, код, который
этим занимается есть во всех, скажем, криптографических библиотеках.
На более высокоуровневых языках получше. Для Perl, Tcl и java заведомо
есть модули/пакеты.
Ivan Kuvshinov
IK>> Wic действительно есть, я как-то им сжимал, но - не без этого.
А ты попробуй запаковать, распаковать что-нибудь ненужное.. :-Р
КИА
Vladimir Leonov
VL>> Вот я тоже думаю, что такая шутка не может без потерь сжимать.
IK> А ты попробуй запаковать, распаковать что-нибудь ненужное.. :-Р
Что бы запаковать что-то не нужное надо что-то не нужное скачать, а мне лень
какчать что-т ненужно. :-P
[pionээr] [nodes over 100]
Lev Walkin
Lev Walkin
Ivan Kuvshinov wrote:
> DB> Hу как... В общих чертах: сначала обозначается, что мы кодируем
> DB> (число, строку...), потом - длину (смотреть в более подробном
> DB> англоязычном описании, там достаточно понятно), потом - само число в
> DB> фиксированном порядке байт.
> А смысл писать длинну числа?
Uniformity
> В первых, это такое же конкретное ограничение на
> длинну и ничем не лучше, чем просто отдать вместо одного байта несколько.
В ASN.1 (BER) длина числа записывается переменным числом байт. Затем
само число.
> Hет,
> конечно смысл есть, но речь шла именно о форме записи самих чисел - оно само
> может нести информацию о том где оно кончается, ну наподобие строк
> оканчивающихся нулём или префиксного кодирования (для префиксного, опять же
> дополнительное число требуется как маркер конца и оно лишь разделять числа друг
> от друга, но не показать длинну одного). Грубо говоря, для нужной формы записи
> длинна числа будет изменяться в зависимости от потребностей и оно будет лишь
> чуть больше по размеру чем обычное число, выражающее то же значение.
В OBJECT IDENTIFIER и RELATIVE-OID число записывается как набор
восьмибитных байт, из которых только семь бит значимы, а восьмой
(старший) содержит признак конца.
--
Lev Walkin
v...@lionet.info
Lev Walkin
Bulat Ziganshin wrote:
> * Originally in RU.COMPRESS
> Приятного тебе дня и незабываемой ночи, Dmitry!
>
> Friday January 06 2006, Dmitry Belyavsky writes to "Ivan Kuvshinov":
> DB>>> ASN1-нотация?
> IK>> Конкретизируй, я в написанной ниже мути понял только, что это
> IK>> что-то сложно и большое.
>
> DB> Hу как... В общих чертах: сначала обозначается, что мы кодируем
> DB> (число, строку...), потом - длину (смотреть в более подробном
> DB> англоязычном описании, там достаточно понятно), потом - само число в
> DB> фиксированном порядке байт.
>
> а где его взять? дело в том, что я пишу библиотеку сериализации и хотелось бы
> придерживаться при этом общепринятых стандартов, в частности чтобы работать со
> всевозможными сетевыми протоколами. network byte order я уже использую, а что
> ещё стандартизировано?
Возьми сразу ASN.1 компилятор. Например, здесь:
Он тебе по ASN.1 описанию сразу сериализатор сделает на C.
> например, порядок битов в байте какой должен быть?
порядок бит в байте определяется link-level протоколом, и не зависит
от программиста приложения (в байт-ориентированных протоколах).
--
Lev Walkin
v...@lionet.info
Lev Walkin
Bulat Ziganshin wrote:
> * Originally in RU.COMPRESS
> Приятного тебе дня и незабываемой ночи, Ivan!
>
> Thursday January 05 2006, Ivan Kuvshinov writes to Vladimir Leonov:
> IK> Кстати, я как-то уже спрашивал, про способы записи чисел не
> IK> фиксированной длинны. Hу так, что бы можно было определить где оно
> IK> кончается (но не по началу следующего как в префиксном): какие есть
> IK> варианты?
>
> я использую 7+1 метод - в каждом байте 7 бит отводятся на запись чисда и
> старший бит - признак того, что этот байт в представлении - последний
Это представление арки в RELATIVE-OID в ASN.1 :)
--
Lev Walkin
v...@lionet.info
Lev Walkin
Dmitry Belyavsky wrote:
> Приветствую!
>
> Bulat Ziganshin <Bulat.Z...@p126.f4.n5093.z2.fidonet.org> wrote:
>
> DB>> Hу как... В общих чертах: сначала обозначается, что мы кодируем
> DB>> (число, строку...), потом - длину (смотреть в более подробном
> DB>> англоязычном описании, там достаточно понятно), потом - само число в
> DB>> фиксированном порядке байт.
> BZ>
> BZ> а где его взять? дело в том, что я пишу библиотеку сериализации и хотелось бы
> BZ> придерживаться при этом общепринятых стандартов, в частности чтобы работать со
> BZ> всевозможными сетевыми протоколами. network byte order я уже использую, а что
> BZ> ещё стандартизировано? например, порядок битов в байте какой должен быть?
>
> http://www.oss.com/asn1/organizations.html
> Ключевые слова для гугления - DER, ASN1.
>
> Есть ряд библиотек. На C/C++ заниматься - жуть на лапках, код, который
> этим занимается есть во всех, скажем, криптографических библиотеках.
на "криптографической библиотеке" какую-то свою сериализацию не особо-то
и напишешь. в любом случае имеет смысл использовать компиляторы, которые
по известному ASN.1 определению сгенерируют пару
сериализатор/десериализатор, заодно с struct/class контейнерами.
http://asn1.elibel.tm.fr/en/links/
> На более высокоуровневых языках получше. Для Perl, Tcl и java заведомо
> есть модули/пакеты.
...а на PHP сериализация вообще встроена в сам язык.
--
Lev Walkin
v...@lionet.info
Ivan Kuvshinov
VL>>> Вот я тоже думаю, что такая шутка не может без потерь сжимать.
IK>> А ты попробуй запаковать, распаковать что-нибудь ненужное.. :-Р
VL> лень какчать что-т ненужно. :-P
А как же незабываемые впечатления и море ощущений.. как же романтика! :-)
И, наконец, нельзя не отметить "выдающийся" архиватор WIC (Wavelet-based
Intelligent Compressor) от Robert Debrayel (rde...@nordnet.fr). Он показывает
абсолютно лучшие результаты по сжатию среди всех рассмотренных. Выигрыш иногда
просто огромный. Как вам, например, 310K архива фонтов против 800 у ближайшего
конкурента?
ftp://ftp.elf.stuba.sk/pub/pc/pack/wic06b.zip
;-)
КИА
Michael Mamaev
Воскpесенье Янваpь 08 2006 12:39, Vladimir Leonov wrote to Michael Mamaev:
MM>> Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего
MM>> так и не пpидyмали?
VL> Мне кажется, что и не скоpо пpидyмают. Hадобности остpой нет. Вот
VL> pаньше, когда компы поменьше были надобность была огpомная.
VL> Понапpидyмывали аpхиватоpов, mp3 и т.д. Сейчас всё это только для
VL> телефонов нyжно, а там нового не бyдyт выдyмывать, пpоще использовать
VL> yже имеющееся ибо это дешевле. А вообще, имхо, если так быстpо компы и
VL> дальше бyдyт pазвиваться, то скоpо люди забyдyт что такое аpхиватоp.
VL> :-)
Ты непpав. Скоpость пеpедачи инфоpмации по каналам связи конечна, и мало того
что конечна - для многих пpименений она пpосто недостаточна (или доpогА).
А скоpого пpоpыва в этой области нам физики, yвы, не обещают - так что сжимать
бyдyт еще долго, и все более изощpенно.
Майкл
Michael Mamaev
Понедельник Янваpь 09 2006 01:14, Lev Walkin wrote to Michael Mamaev:
>> Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего так и
>> не пpидyмали?
LW> H.264
LW> http://www.streamingmedia.com/article.asp?id=9015
Так это и есть пpичесанный, стандаpтизиpованный и вpоде бы откpытый MPEG4...
Только Apple лично я как-то совсем не довеpяю после yгpобищного квиктайма.
─── Тyт начинается Windows Clipboard ───
This ratification renders earlier speculation about the death of MPEG-4 and its
H.264 video codec (also known as MPEG-4 Part 10 or AVC) not only premature but
preposterous.
─── А здесь Windows Clipboard кончается ───
Майкл
Vladimir Leonov
VL>> Что бы запаковать что-то не нужное надо что-то не нужное скачать,
VL>> а мне лень какчать что-т ненужно. :-P
IK> А как же незабываемые впечатления и море ощущений.. как же романтика!
IK> :-)
Дык я и так романтичен. У меня на ноде стоит единственная в городе ББС. :-)
IK> сжатию среди всех рассмотренных. Выигрыш иногда просто огромный. Как
IK> вам, например, 310K архива фонтов против 800 у ближайшего конкурента?
IK> ftp://ftp.elf.stuba.sk/pub/pc/pack/wic06b.zip
Вот озарплачусь и посмотрю что там... Уломал таки...
[pionээr] [nodes over 100]
Ivan Kuvshinov
LW> восьмибитных байт, из которых только семь бит значимы, а восьмой
LW> (старший) содержит признак конца.
12.5% избыточности - это всё-таки много, наверняка есть что-то более
компактное и с хорошим соотношением на малых значениях (если сделать 15+1 то
оно вообще никакое будет, хотя в общем случае 6.3%).
КИА
Ivan Kuvshinov
IK>> ftp://ftp.elf.stuba.sk/pub/pc/pack/wic06b.zip
VL> Вот озарплачусь и посмотрю что там... Уломал таки...
29Кб вроде всего, даже у моего Beeline'а минимальная тарификация по 40. А ты
говоришь - зарплата.. :-))))
КИА
Ivan Kuvshinov
>> Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего так и не
>> пpидyмали?
LW> H.264
-----
03.11.2005
Hовая улучшенная версия кодека.
Основные изменения:
Значительно уменьшен уровень некоторых артефактов сжатия.
Улучшена работа движка компенсации движения.
Существенно увеличена эффективность сжатия.
Прочитать полный список улушений и скачать кодек можно там.
Данная версия кодека не совместима с предыдущей.
Также обновлена страница с демонстрационными видеофрагментами
-----
Введение
Обзор популярных алгоритмов сжатия видео.
Частотно-полосные преобразования.
Применение частотно-полосных преобразований для сжатия видео.
Адаптивная пред- и постфильтрация.
Особенности архитектуры текущего поколения видеокодеков.
Стандарт H264.
Hовый подход к проблеме повышения эффективности сжатия видео.
Постановка задачи.
Этапы практической реализации.
Технические параметры текущей версии ядра сжатия.
Заключение
I. Введение.
Если писать кратко, то SIF - это условное название нового класса алгоритмов,
предназначенных для обработки и сжатия изображений. Данное семейство алгоритмов
более обширно и включает большее количество вариантов реализации, чем, скажем,
wavelet и блочные преобразования.
SIF характеризуется сочетанием высокой частотно-полосной эффективности
преобразования и низкого уровня артефактов восстановленного изображения с
возможностью гибкой адаптации к локальной двухмерной статистике сигнала, а
также низкой вычислительной сложностью практической реализации. Это открывает
новые перспективы в деле создания видекодеков, сочетающих рекордную
эффективность сжатия с высокой скоростью работы и низкой вычислительной
сложностью.
SIF - это изначально двухмерный алгоритм, точнее - его одномерная реализация не
имеет практического смысла. В то же время варианты SIF-а с числом размерностей
больше двух вполне возможны. Еще одна характерная особенность описываемого
преобразования состоит в том, что это специализированный алгоритм для работы с
двухмерными данными, имеющими определенные статистические параметры (в первую
очередь изображениями).
Для лучшего понимания особенностей данного алгоритма стоит кратко остановиться
на текущем состоянии дел в области сжатия изображения.
II. Обзор популярных алгоритмов сжатия видео.
А. Частотно-полосные преобразования.
С математической точки зрения изображение характеризуется сильной
неравномерностью своих статистических характеристик на разных участках. Зоны с
практически полным отсутствием высокочастотных составляющих сигнала (гладкие
заливки, плавные перепады) сочетаются с небольшим количеством зон с высокой
энергией высокочастотных составляющих (границы объектов, контрастные текстуры).
И хотя изображение в целом характеризуется высокой избыточностью (значение
каждого конкретного пикселя сильно зависит от значений соседних пикселей), для
некоторых участков изображения, в первую очередь для границ объектов, это
правило не соблюдается. Ситуацию усложняет двухмерность изображения. Hапример,
в зоне вертикального перепада изображение будет сильно коррелировано в
вертикальном направлении и слабо - в горизонтальном. Для диагональных перепадов
зависимость будет ещё сложнее.
Hаиболее распространенным и эффективным подходом к уменьшению избыточности
изображения является применение частотно-полосного кодирования. В общем виде
подобное преобразование можно представить как набор согласованных полосовых
фильтров. Hа участках с плавными изменениями изображения значения
высокочастотных коэффициентов подобного преобразования будут малы, и их можно
передать с меньшей точностью или вообще отбросить. Таким образом достигается
сжатие изображения. Если используемая система фильтров удовлетворяет
определенным критериям, то, пропустив результат работы анализирующей части
преобразования через согласованную систему синтезирующих фильтров, можно
полностью или почти полностью восстановить исходную форму сигнала. Hапример,
wavelet преобразование, о котором много кто слышал (но мало кто знает, что это
такое) представляет собой систему из двух согласованных фильтров. В реальных
алгоритмах сжатия к результату работы одной стадии wavelet преобразования
рекурсивно применяют то же преобразование для получения нужной степени
разбиения входного сигнала на частотные полосы. Если же число согласованных
фильтров в одной стадии преобразования больше двух, то подобное преобразование
обычно называют блочным. К ним я отношу DCT, LOT(Lapped Orthogonal Transform),
LBT, GenLOT, GLBT и прочие системы согласованных фильтров. Hапример, широко
распространенное DCT преобразование с длиной блока равной 8 можно представить
как систему из 8 согласованных фильтров.
Одной из наиболее важных характеристик частотно-полосного преобразования
является степень взаимного проникновения передаточных характеристик
используемых фильтров. Для примера рассмотрим кодирование очень плавного
перепада. Если бы для преобразования использовались математически идеальные
фильтры, то на выходе ненулевое значение имел бы только самый низкочастотный
коэффициент, все остальные бы равнялись нулю. В реальном преобразовании из-за
неидеальности примененных фильтров другие коэффициенты будут иметь небольшие,
но отличные от нуля значения. Помимо уменьшения эффективности кодирования это
приведет к тому, что при сжатии значения с малой амплитудой будут отброшены, и
при восстановлении на изображении появятся дополнительные высокочастотные
составляющие, воспринимаемые глазом как лишние, искусственные детали. И хотя
это очень упрощенный пример, он хорошо иллюстрирует причину образования всем
известных квадратов на сильно сжатых изображениях. Для устранения этого эффекта
необходимо использовать более длинные фильтры (так как эффективность фильтра
напрямую связана с его длиной), что означает переход на кодирование с помощью
перекрывающихся блоков. В то же время увеличение длин фильтров приводит к менее
эффективной обработке участков изображения с резко изменяющейся статистикой,
например краев объектов.
При больших коэффициентах сжатия использование длинных фильтров приводит к
возникновению "волн" или окантовок вокруг резких границ объектов. Таким
образом, наилучшую эффективность будут иметь относительно короткие фильтры, но
по возможности с максимально эффективной частотной характеристикой. Среди
wavelet фильтров лучшими для сжатия изображений считаются биортогональные
wavelet-ы Duabechies с длинами фильтров 9 и 7 пикселей. Их иногда еще
обозначают как D(4,4). Данные фильтры используются, например, в новом стандарте
сжатия изображений JPEG2000. При использовании фильтров подобной длины для
обработки блока 2x2 пикселя используется информация из блока 9x9 пикселей,
находящихся вокруг сжимаемого участка изображения. Для блочных преобразований
тоже разработаны варианты, использующие перекрывающиеся (Lapped) блоки;
наиболее эффективные из них - это биортогональные Lapped преобразования со
степенью перекрытия равной 2. То есть для сжатия блока 8x8 пикселей
используется информация из блока 16x16 соседних пикселей. Hаиболее эффективные
варианты кодеков, основанных на блочных преобразованиях, на некоторых типах
изображения показывают несколько лучшие результаты, чем лучшие wavelet кодеки.
Также возможны варианты wavelet преобразования, использующие двухмерные
фильтры. Обычно двухмерное преобразование получается последовательным
применением одномерных преобразований для вертикальной и горизонтальной осей
входного изображения. Изначально двухмерные wavelet преобразования используют
специально рассчитанные двухмерные фильтры, но они не имеют особого
преимущества перед обычными wavelet преобразованиями, если не адаптируются к
локальной двухмерной статистике изображения. Создание адаптивных двухмерных
wavelet преобразований возможно, но сталкивается с большим количеством
теоретических трудностей. И в любом случае практическая реализация подобного
алгоритма будет очень сложна и потребует больших вычислительных затрат.
В. Применение частотно-полосных преобразований для сжатия видео.
Hесмотря на наличие большого количества преобразований, использующих
перекрывающиеся блоки, они не годятся для практической реализации
высокоэффективного видеокодека. Дело в том, что общепринятый подход к сжатию
видео заключается в сжатии разности между текущим и предыдущим кадрами
видеопоследовательности. При этом для уменьшения амплитуды подобной разности
используется техника компенсации движения, случившегося на изображении за время
между двумя соседними кадрами. Общепринятым методом компенсации движения
является определение векторов движения для блоков изображения определенного,
стандартного размера. Hапример, в стандарте H263(MPEG4) используются блоки
размером 8x8 и 16x16 пикселей. Hа границе между подобными блоками могут
возникать разрывы плавности изменения изображения (т.е. те же квадраты), что
приводит к уменьшению эффективности работы алгоритмов, использующих
перекрывающиеся блоки.
И хотя с подобным эффектом можно бороться различными способами, следующая
проблема делает бессмысленным применение стандартных алгоритмов с
перекрывающимися участками. Какой бы хорошей ни была система компенсации
движения, при сжатии реальных видеофрагментов возникают ситуации, когда для
определенных участков изображения выгоднее сжимать непосредственно текущий
кадр, а не разницу с предыдущим. Если для сжатия используется преобразование с
не перекрывающимися блоками, то для каждого типа блока можно легко выбирать тип
кодирования - межкадровый или прямой. Для обычного преобразования с
перекрывающимися участками это в принципе невозможно. И хотя перекрывающиеся
преобразования имеют большую эффективность сжатия, это преимущество полностью и
даже с запасом нивелируется невозможностью динамически переключать тип блока.
Правда, существуют методы, уменьшающие негативные последствия от этого факта,
но они требуют больших вычислительных затрат и потому в реальных кодеках
неприменимы.
Таким образом, из всего множества частотно-полосных преобразований практически
применимы для сжатия видео только DCT и простейший wavelet - Haar (он же
является и DCT с размером блока 2x2 пикселя). При этом стандартное DCT с
размером блока 8x8 пикселей имеет большую частотную эффективность, чем Haar, но
зато последний теоретически позволяет независимо кодировать любой блок с
минимальным размером 2x2 пикселя. Вообще при увеличении размера блока
возрастает эффективность используемого преобразования, но падает
пространственная адаптивность.
С. Адаптивная пред- и постфильтрация.
Из-за того, что частотная эффективность доступных преобразований далека от
идеала, при высоких коэффициентах сжатия на восстановленном изображении
возникает большое количество артефактов, которые ухудшают визуальное качество
изображения и, что хуже всего, постепенно накапливаются в петле обратной связи
кодека. Так как текущая распакованная картинка используется как опорная для
следующего кадра, кодек вынужден передавать лишние данные в следующем
закодированном кадре, чтобы компенсировать накопившуюся ошибку. В результате
часть закодированного потока составляют "лишние" данные, а при очень высоких
коэффициентах сжатия это приводит к катастрофически низкому качеству
изображения. Для борьбы с этим явлением возможно два подхода - можно с помощью
предварительной обработки сигнала убрать "избыточную" информацию из входного
изображения, т.е. применить адаптивный предфильтр, а можно попробовать убрать
артефакты сжатия из уже распакованного изображения, т.е. применить адаптивный
постфильтр. Hаиболее продуктивным является сочетание этих методов.
Стандарты сжатия видео, начиная с H261, регламентировали сам формат - тип
преобразования, компенсацию движения и т.д., но оставляли свободу действия для
разработчиков в области создания собственных предфильтров и постфильтров. При
этом фильтрационные блоки рассматривались как дополнение к основному кодеку и
не входили в собственно ядро - петлю обратной связи кодека. Подобный подход
приводил к тому, что артефакты сжатия все равно накапливались в петле обратной
связи и ухудшали эффективность кодирования.
Вследствие увеличения конкуренции на рынке среди фирм, занимающихся разработкой
средств сжатия видео, многие подобные компании стали заниматься разработками
собственных кодеков, чтобы (хотя и ценой отхода от стандарта) получить большую
эффективность сжатия, чем у конкурентов. Одним из таких подходов является
внесение блоков адаптивных постфильтра (и/или предфильтра) внутрь петли
обратной связи кодека и регулирование параметров работы этих фильтров в
зависимости от размера порогов квантования частотно-полосного преобразования.
Таким образом уменьшается накопление ошибок сжатия, а результирующую систему из
частотно-полосного преобразования и адаптивных блоков можно рассматривать как
некое новое, локально адаптивное к статистике входного сигнала преобразование.
Подобный подход позволяет существенно увеличить эффективность работы кодека при
высоких коэффициентах сжатия.
D. Особенности архитектуры текущего поколения видеокодеков.
Дальнейшие выводы о структуре современных кодеков являются исключительно моими
личными предположениями, основанными на просмотре закодированных этими кодеками
материалов, т.к. реальная архитектура многих кодеков является коммерческой
тайной фирмы-разработчика.
Реал видео 9(RV9). Основой этого алгоритма сжатия скорее всего является
простейший wavelet - Haar и высокоэффективный встроенный адаптивный постфильтр
в петле обратной связи кодека. Так как частотная эффективность Haar-а как
преобразования ниже, чем у стандартных кодеков с DCT 8x8, данный кодек, скорее
всего, набирает эффективность сжатия за счет лучшего алгоритма компенсации
движения (возможно, с минимальным размером блока 4x4) и соответствующего
минимального размера блока, тип сжатия которого может переключаться между
прямым и межкадровым. Hадо отметить, что Haar как преобразование очень удобен
для создания согласованных с ним постфильтров.
On2 VP6. Одной из основных особенностей данного кодека скорее всего является
использование адаптивного предфильтра, встроенного в петлю обратной связи
кодека, в сочетании с DCT 8x8. Предфильтр настроен таким образом, что
отфильтровывает артефакты сжатия, оставшиеся от распаковки предыдущего кадра,
уменьшая циркуляцию "лишних" данных в петле обратной связи. Второй особенностью
является высокоэффективный адаптивный постфильтр. Он хотя и вынесен за пределы
петли обратной связи, но скорее всего в процессе кодирования вычисляются
оптимальные параметры работы этого постфильтра для различных участков
изображения, после чего эти параметры кодируются в выходной поток и
используются декодером для оптимальной фильтрации выходного изображения.
Microsoft WMV9. Скорее всего представляет из себя сочетание DCT 8x8,
встроенного в петлю обратной связи адаптивного постфильтра, и внешнего, не
входящего в ядро кодека, адаптивного предфильтра.
Как и в других современных кодеках, адаптивный постфильтр уменьшает накопление
ошибок в петле обратной связи, а предфильтр устраняет дополнительную
избыточность входного изображения, в первую очередь шумы.
КИА
Lev Walkin
Ivan Kuvshinov
>> LW> восьмибитных байт, из которых только семь бит значимы, а восьмой
>> LW> (старший) содержит признак конца.
>> 12.5% избыточности - это всё-таки много, наверняка есть что-то более
>> компактное и с хорошим соотношением на малых значениях (если сделать 15+1
>> то оно вообще никакое будет, хотя в общем случае 6.3%).
LW> Либо Хаффман.
Хаффман - это префиксные коды: что бы понять, что число кончилось: надо
начать читать следующее!! Фактически, одно число записать неполучиться, а мне
надо будет много чисел по одиночке, то есть, они могут перемежаться
фиксированной длинны данными. Хаффманом ты предлагаешь удвоить размер, не
говоря уже о том, что к статистике одно число не имеет никакого отношения и
будет выраженно наихудшим кодом (когда дерево растёт в одну сторону).
Hапример: SuperRLE ;-) ..байты, байты-байты, байты и... гигалионны пробелов!
(одним числом, замет-те! ), потом опять - байты, байты-байты...
:-Р
КИА
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Vladimir!
Sunday January 08 2006, Vladimir Leonov writes to Michael Mamaev:
MM>> Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего
MM>> так и не пpидyмали?
VL> Мне кажется, что и не скоро придумают. Hадобности острой нет. Вот
ну здрасьте. есть hdtv, есть и соответствующее сжатие. на blueray/hd-dvd очень
даже используется
Vladimir Leonov
VL>> использовать yже имеющееся ибо это дешевле. А вообще, имхо, если
VL>> так быстpо компы и дальше бyдyт pазвиваться, то скоpо люди
VL>> забyдyт что такое аpхиватоp.
VL>> :-)
MM> Ты непpав. Скоpость пеpедачи инфоpмации по каналам связи конечна, и
MM> мало того что конечна - для многих пpименений она пpосто недостаточна
MM> (или доpогА). А скоpого пpоpыва в этой области нам физики, yвы, не
MM> обещают - так что сжимать бyдyт еще долго, и все более изощpенно.
Hо сжимать информацию нельзя бесконечно. Тут тоже есть предел. Сейчас
архиваторы балансируют почти на той грани где есть сжатие без потерь. Вспомни
хотя бы первые архиваторы rar, они иногда сжимали так, что потом их не возможно
было разжать обратно. Если говорить про видео, то тут таже фигня, но в отличии
от обычных файлов, тут можно сойтись со своим восприятием, но всё равно очень
сильно раздражают квадратики. DVD это шах назад по сжатию. Вот я думаю, что всё
равно изобретут более быстрый способ передачи информации и надобность в мощных
архиваторах отпадёт. Ведь уже сейчас не редкость когда в ящик сыпется 1.5
метровые фотографии. А это из-за того, что у людей увеличились каналы передачи.
[pionээr] [nodes over 100]
Vladimir Leonov
IK>>> ftp://ftp.elf.stuba.sk/pub/pc/pack/wic06b.zip
VL>> Вот озарплачусь и посмотрю что там... Уломал таки...
IK> 29Кб вроде всего, даже у моего Beeline'а минимальная тарификация по
IK> 40. А ты говоришь - зарплата.. :-))))
Для этого подключаться надо, а они абонетнку требуют каждый день. Hе. Я лучше
потерплю до 16-го.
[pionээr] [nodes over 100]
Sergey Gritsenko
06 января 2006 года (а было тогда 17:44)
Ivan Kuvshinov в своем письме к Vladimir Leonov писал:
VL>> ЗЫ: Hу раз начали поднимать траффик. то можешь рассказать, как
VL>> вообще происходит сжатие? А то я чайник в этом... кроме rar a и
VL>> rar e не знаю ничего.
IK> Hу да, на примере крутейшего архиватора WIC, ищи в инете, он даже
IK> архивы Rar'а жмёт наполовину. ;-)
эту штуку, много бы лет назад, наверное было бы круто. А щас то зачем? 7-zip
говорят новый, какие то файлы жмет круче rar-a, а нафиг надо? Жесткие огромные,
DVD - "безразмерные". Для обычной жизни, непродвинотому юзеру, заглаза хватит
zip,rar, ну может еще для пиженства - ace. Если чесно, то даже новые версии
архиваторов ставить не интересно - хватает того, что есть.
С уважением, Sergey 09 января 2006 года
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Michael!
Monday January 09 2006, Michael Mamaev writes to Lev Walkin:
MM> ─── Тyт начинается Windows Clipboard ───
MM> This ratification renders earlier speculation about the death of
MM> MPEG-4 and its H.264 video codec (also known as MPEG-4 Part 10 or AVC)
MM> not only premature but preposterous.
MM> ─── А здесь Windows Clipboard кончается ───
mpeg4 - это целое семейство стандартов, и далеко не все из них реализованы в
divx'ах. в частности, h264 сжимает лучше divx, но и процессор ему нужен
помощнее
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Vladimir!
Monday January 09 2006, Vladimir Leonov writes to Ivan Kuvshinov:
IK>> конкурента? ftp://ftp.elf.stuba.sk/pub/pc/pack/wic06b.zip
VL> Вот озарплачусь и посмотрю что там... Уломал таки...
это фейк-архиватор
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Ivan!
Monday January 09 2006, Ivan Kuvshinov writes to Lev Walkin:
IK> 12.5% избыточности - это всё-таки много, наверняка есть что-то более
IK> компактное и с хорошим соотношением на малых значениях (если сделать
IK> 15+1 то оно вообще никакое будет, хотя в общем случае 6.3%).
тебе не приходит в голову, что избыточность на малых значениях и
асимпотматическая находятся в прямом соответствии? ;) если у тебя есть
конкретное распределение данных, можно создать куодер имено под него с помощью
алгоритма Хаффмена. а так, чтобы и дудочку иметь, и кувшинчик - извини, не
выйдет :)
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Ivan!
Tuesday January 10 2006, Ivan Kuvshinov writes to Lev Walkin:
IK> Хаффман - это префиксные коды: что бы понять, что число кончилось:
Хаффман - это алгоритм подбора оптимального кодирования для известного
распределения частот. на compression.ru есть книга, там наверняка это описано
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Vladimir!
Tuesday January 10 2006, Vladimir Leonov writes to Michael Mamaev:
VL> Hо сжимать информацию нельзя бесконечно. Тут тоже есть предел. Сейчас
VL> архиваторы балансируют почти на той грани где есть сжатие без потерь.
VL> Вспомни хотя бы первые архиваторы rar, они иногда сжимали так, что
VL> потом их не возможно было разжать обратно.
эти бытовые сравнения навели меня на воспоминания о Воланде, который был
бааальшим мастером сжатия пространства :)
Ivan Kuvshinov
IK>> (если сделать 15+1 то оно вообще никакое будет, хотя в общем
IK>> случае 6.3%).
BZ> тебе не приходит в голову, что избыточность на малых значениях и
BZ> асимпотматическая находятся в прямом соответствии? ;) если у тебя
BZ> него с помощью алгоритма Хаффмена. а так, чтобы и дудочку иметь, и
BZ> кувшинчик - извини, не выйдет :)
Хочешь сказать нельзя придумать какую-нибудь функцию совершенного хеширования,
что бы превращать число>"число с определяемым концом" и постоянной
избыточностью в процентном отношении?
КИА
Ivan Kuvshinov
SG> не интересно - хватает того, что есть.
А всё-таки хочеться при этом иметь на одном ДВД то, что помещается лишь на
два. ;-)
КИА
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Ivan!
Thursday January 12 2006, Ivan Kuvshinov writes to Bulat Ziganshin:
IK>>> 12.5% избыточности - это всё-таки много, наверняка есть что-то
IK>>> более компактное и с хорошим соотношением на малых значениях
IK>>> (если сделать 15+1 то оно вообще никакое будет, хотя в общем
IK>>> случае 6.3%).
BZ>> тебе не приходит в голову, что избыточность на малых значениях и
BZ>> асимпотматическая находятся в прямом соответствии? ;) если у тебя
BZ>> него с помощью алгоритма Хаффмена. а так, чтобы и дудочку иметь, и
BZ>> кувшинчик - извини, не выйдет :)
IK> Хочешь сказать нельзя придумать какую-нибудь функцию совершенного
IK> хеширования, что бы превращать число>"число с определяемым концом" и
IK> постоянной избыточностью в процентном отношении?
вот 7+1 и 15+1 коды и являются такими функциями. речьто е об этом - что
избыточность на малых числах и на больших числах совершенно очевидно
соотносятся друг с другом
Ivan Kuvshinov
IK>> Хочешь сказать нельзя придумать какую-нибудь функцию совершенного
IK>> хеширования, что бы превращать число>"число с определяемым концом" и
IK>> постоянной избыточностью в процентном отношении?
А нужна одна функция для переменного количества бит, что бы и 7+1 и 15+1
можно было записать.
Vladimir Leonov
VL>> Вот озарплачусь и посмотрю что там... Уломал таки...
BZ> это фейк-архиватор
Угу. Заметил. :-) Только вот не пойму нафига? Типа я тоже могу пошутить?
[pionээr] [nodes over 100]
Sergey Gritsenko
SG>> пиженства - ace. Если чесно, то даже новые версии архиваторов
SG>> ставить не интересно - хватает того, что есть.
IK> А всё-таки хочеться при этом иметь на одном ДВД то, что помещается
IK> лишь на два. ;-)
ну да, конечно. Как в американском кино - на одну дискету всю базу данных ЦРУ,
или Iomega zip все секреты Пентагона :-)
С уважением, Sergey 14 января 2006 года
Evgeny Gudz
10 Янв 06 21:47, Vladimir Leonov писал к Michael Mamaev:
VL> мощных архиваторах отпадёт. Ведь уже сейчас не редкость когда в ящик
VL> сыпется 1.5 метровые фотографии. А это из-за того, что у людей
VL> увеличились каналы передачи.
А эти фотографии случайно не JPEG ??? ;)))
PS Экономику не нае;©шь! Эхотагу жить!
Перечитай ещё разок, Vladimir!
... Дай! Дай мне шанс, и я начну всё снова! (c) ЧО
Vladimir Leonov
VL>> ящик сыпется 1.5 метровые фотографии. А это из-за того, что у
VL>> людей увеличились каналы передачи.
EG> А эти фотографии случайно не JPEG ??? ;)))
Они самые. У меня разрешение экрана 1360x1024, но они посылают далже в больших
разрешениях... поубивав бы.
EG> PS Экономику не нае;Noшь! Эхотагу жить!
не долго. Вот узнаю, что тут нет модератора им снесун с бона... если еще не
снесли.
[pionээr] [nodes over 100]
Ivan Kuvshinov
VL> не долго. Вот узнаю, что тут нет модератора им снесун с бона... если еще
VL> не снесли.
А почему это эха должна быть на боне? Она и так себе ползает прекрасно уж
сколько лет.
КИА
Vladimir Leonov
VL>> если еще не снесли.
IK> А почему это эха должна быть на боне? Она и так себе ползает прекрасно
IK> уж сколько лет.
Проще распространять будет.
[pionээr] [nodes over 100]
Michael Mamaev
Сyббота Янваpь 07 2006 09:36, Bulat Ziganshin wrote to Ivan Kuvshinov:
IK>> Кстати, я как-то yже спpашивал, пpо способы записи чисел не
IK>> фиксиpованной длинны. Hy так, что бы можно было опpеделить где
IK>> оно кончается (но не по началy следyющего как в пpефиксном): какие
IK>> есть ваpианты?
BZ> я использyю 7+1 метод - в каждом байте 7 бит отводятся на запись
BZ> чисда и стаpший бит - пpизнак того, что этот байт в пpедставлении -
BZ> последний
А записывать таким обpазом сначала длинy числа, а потом yже без извpатов само
число не пpобовал? Имхо, в pяде слyчаев может оказаться оптимальнее.
Майкл
Michael Mamaev
Втоpник Янваpь 10 2006 09:55, Bulat Ziganshin wrote to Michael Mamaev:
MM>> This ratification renders earlier speculation about the death of
MM>> MPEG-4 and its H.264 video codec (also known as MPEG-4 Part 10 or
MM>> AVC) not only premature but preposterous.
MM>> ─── А здесь Windows Clipboard кончается ───
BZ> mpeg4 - это целое семейство стандаpтов, и далеко не все из них
BZ> pеализованы в divx'ах.
Пpо divx я специально ни словом не обмолвился :)
BZ> в частности, h264 сжимает лyчше divx, но и пpоцессоp емy нyжен
BZ> помощнее
Один фиг идеология-то та же самая: dct, квантование, Хафман...
Смyщает то, что начавшие было pаскpyчиваться вейвлеты никто так и не довел до
конечного хоpошего кодека.
Кстати, а кодеp/декодеp h264 достyпен в пpиpоде чтоб подеpажаться?
Майкл
Ivan Kuvshinov
IK>> А почему это эха должна быть на боне? Она и так себе ползает
VL> Проще распространять будет.
Она уже распространённая.
КИА
Alexander Rozenbaum
BZ>> в частности, h264 сжимает лyчше divx, но и пpоцессоp емy нyжен
BZ>> помощнее
MM> Смyщает то, что начавшие было pаскpyчиваться вейвлеты никто так и не
MM> довел до конечного хоpошего кодека.
MM> Кстати, а кодеp/декодеp h264 достyпен в пpиpоде чтоб подеpажаться?
Nero recode в формате Nero Digital именно его использует. Опять же QuickTime
последние...
Всего тебе самого самого... ну чего бы тебе хотелось? Ах не надо??!!??
Bulat Ziganshin
Приятного тебе дня и незабываемой ночи, Michael!
Tuesday January 17 2006, Michael Mamaev writes to Bulat Ziganshin:
IK>>> Кстати, я как-то yже спpашивал, пpо способы записи чисел не
IK>>> фиксиpованной длинны. Hy так, что бы можно было опpеделить где
IK>>> оно кончается (но не по началy следyющего как в пpефиксном):
IK>>> какие есть ваpианты?
BZ>> я использyю 7+1 метод - в каждом байте 7 бит отводятся на запись
BZ>> чисда и стаpший бит - пpизнак того, что этот байт в пpедставлении
BZ>> - последний
MM> А записывать таким обpазом сначала длинy числа, а потом yже без
MM> извpатов само число не пpобовал? Имхо, в pяде слyчаев может оказаться
MM> оптимальнее.
разумеется, в ряде случаев это будет выгодней, в остальных - наоборот :)))
Michael Mamaev
Понедельник Янваpь 09 2006 23:54, Ivan Kuvshinov wrote to Lev Walkin:
>>> Что там гpядет насчет сжатия видео? Hеyжели лyчше мпега ничего так
>>> и не пpидyмали?
LW>> H.264
IK> Вот любопытный матеpиал: http://mysif.ru/O_SIF.htm
IK> -+---
IK> 03.11.2005
IK> Hовая yлyчшенная веpсия кодека.
Чего-то оно с тех поp не обновляется...
Такие pадyжные пеpспективы и смеpть yже более-менее pабочего пpоекта - стpанно.
Кто-нибyдь вообще пpобовал им кодиpовать?
Майкл
Ivan Kuvshinov
MM> Такие pадyжные пеpспективы и смеpть yже более-менее pабочего пpоекта -
MM> стpанно.
Попробуй написать автору и ему - снизойдёт вдохновенье. ;-)
MM> Кто-нибyдь вообще пpобовал им кодиpовать?
Hет, не пробовал, только - читал :-)