Провальные алгоритмы

[pilferer]

Вот, извиняюсь, такое у меня в первый раз, и не знаю с кем поделиться.
Пришла однажды в голову идея, и решил я, написать алгоритм сжатия видео файлов на основе этой идеи. Оформить все в заголовочный файл и продать тысяч эдак за 250 евро. Размечтался уже, как деньги потрачу...

Идея такова. Имеем пикселы экрана (допустим, с разрешением 1024х768=786432 пикселов), каждый пиксел кодируется 24 битами. В отображении видео, картинка меняется примерно 3 раза в секунду (не путать с тактовой частотой). Изменение общей картинки(кадра) у меня было основано на изменении каждого пиксела (три раза в секунду). Изменение каждого пиксела у меня должно было происходить так: прибавляю число к уже имеющимуся в пикселе, новое значение соответствует новому цвету, это отображается. И так три раза за секунду. То число которое прибавляется, берется из этого сжатого файла сжатого по моей методе. И в этом файле также имеются числовые значения, которые надо прибавлять, для каждого пиксела экранной матрицы (786432 пикселов). Для каждого пиксела, соответственно, свой массив. И таких массивов у меня должно быть 786432.

Начал я просчитывать, какой объем файла в итоге должен получиться, исходя из приблизительных расчетов, что сжимать я буду фильм длительностью 90 минут.

Для одного пиксела с координатами (0,0): Одна секунда фильма должна кодироваться 9 байтами (у нас уже есть три родных байта, и мы изменяем их, прибавляя поочередно по три байта, три раза). В 90 минутном фильме у нас 5400 секунд. Умножаем 9 байт на 5400 секунд, получаем 48600 байт. Это для одного пиксела. А у нас их аж 786432. Умножаем 48600 байт на 786432 пикселей и получаем 38 220 595 200 байта. Это соответственно 37 324 800 Кб, 36 450 Мб, 36Гб.

Значит 90 минутный видео файл, сжатый по моей методе, должен весить иж 36 гигабайт.
И понял я, что нет у меня теперь городской собственной квартиры, загородного дома и двух иномарок...

[Алексей++]

pilferer, любое сжатие основывается на удалении избыточной информации (ну а для фильмов - часть и с потерей качества). Если объём получился больше, значит ты не удалил, а добавил эту избыточную ))

[Вад]

Как минимум, избыточная информация никуда не девалась. Вот если бы потом каждый кадр кодировался в JPEG (пусть даже без потери качества) - была бы разновидность MJPEG. А так - размер значений в пикселах diff-кадров уменьшается, разброс этих значений, соответственно, уменьшается тоже, но этим никто не пользуется. Хотя такие данные хорошо сжимаются (собственно, большинство кодеков так или иначе использует опорные и промежуточные кадры, разве что не работают с пикселами в rgb - это неэффективно).

[Dimka]

Если мне память не изменяет, в MP3 используют особенности человеческого слуха: после громкого звука рецепторы не успевают быстро адаптироваться под восприятие тихих звуков, поэтому тихий звук после громкого некоторое малое время может идти с пониженным bitrate - всё равно человек не сможет его воспринять во всех тонкостях.

У зрительных рецепторов такой эффект точно есть (всякий знает, что после яркого света в тёмном помещении сначала плохо видно, потом нормально, а после тёмного помещения на ярком свету глаза режет). Используется ли это в видеокодеках?

[RXL]

Dimka, если под кодеками считать кодеки MPEG-подобных алгоритмов, то не используется. В зависимости от уровня MPEG: (1) используется только разница между опорным и текущим кадрами; (2) сперва вычисляются общие для смежных кадров области и их траектория движения; (4) объекты становятся все более сложными. Принципы сжатия у них общие, похожие на JPEG: перевод в цветоразностный формат, дробление на блоки (потеря части информации на границах блоков), косинусное преобразование, загрубление результата (в зависимости от степени сжатия - на этом этапе и идет основная потеря качества) и сжатие по Хафману (из-за него темные кадры сжимаются много лучше ярких, а монотонные - лучше детализированных).
А вообще, если интересно - поройся в дебрях стандарта MPEG-4 - у него полно фишек.