Удивительно, но за несколько дней напряжённого кодинга удалось получить на базе OpenH264 рабочее решение, которое демонстрирует компрессию до 13% для видеороликов H.264 и 22% на произвольных файлах JPEG. Повторим, это честное lossless-сжатие, когда сжатый файл можно вернуть в исходное состояние с точностью до бита.
Исходный код Pied Piper (losslessh264) опубликован на Github под свободной лицензией BSD.
Смотревшим сериал «Кремниевая долина» вообще не нужно объяснять, что делает кодек Pied Piper. Разработчики скопировали из фильма всё: и его функциональность (компрессия и декомпрессия файлов без потери качества), и даже название. Разница только в том, что здесь не киношный вымысел, а реальность. Кодек создавался как будто в шутку, но он действительно работает.
«Шуточная» разработка способна сэкономить нешуточные деньги для Dropbox, ведь эта компания хранит на своих серверах экзабайты файлов сотен тысяч корпоративных клиентов и индивидуальных пользователей. Даже экономия в 1% позволяет избавиться как минимум от полусотни серверных стоек, что тут говорить о сжатии на 13-22%.
Неудивительно, что Dropbox бросила на этот проект сразу десятерых программистов. Они доводят до ума версию кодека, первоначально созданную во время хакатона.
Даниэль Райтер Хорн
Один из ведущих разработчиков Даниэль Райтер Хорн (Daniel Reiter Horn) говорит, что алгоритм исправляет некоторые устаревшие неэффективные методы кодирования, которые применяются для сжатия файлов H.264 и JPEG: «Например, почти все файлы JPEG сегодня сжимаются алгоритмом Хаффмана, но хорошо известно, что применение дополнительного арифметического кодера к существующим файлам JPEG даёт дополнительное сжатие на 10% без ущерба для файла. Наш алгоритм Pied Piper пытается достичь ещё большего эффекта, это более эффективный алгоритм кодирования, полностью совместимый с существующими форматами».
Реализация дополнительной степени компрессии за счёт анализа предыдущих и последующих блоков с пикселами в кадре
На схеме показано, что для реализации дополнительного сжатия используется более глубокий анализ предыдущих и последующих блоков с пикселами в кадре.
P.S. Вероятно, проект Pied Piper кому-то напоминает алгоритм архивации Бабушкина, но здесь всё-таки код открыт и каждый может самостоятельно проверить кодек в деле.
Комментарии (16)
Self_Perfection
29.08.2015 17:17+4Возможность lossless компресии jpeg изображений — не новость
www.maximumcompression.com/data/jpg.phpDjOnline
29.08.2015 22:12+4Именно. Уже кучу лет существует и PackJpg (PackArc), и StuffIt, и WinZip, и Jpeg Arithmetic Coding в том же imagemagick, которые демонстрируют тот же уровень сжатия Jpeg в 22-30%.
Вот с h264 вообще смешно, там изначально используется арифметическое кодирование, и лишь в еденицах каких-то специальных файлов идёт CAVLC вместо CABAC, то есть изначально файлы более похожи на divx/xvid/mpeg4 ASP.
Master255
29.08.2015 20:19-2Очень хорошая новость!
Нужно заострить внимание на этом у разработчиков h264, h265. Создать тему на doom9. Что бы новые cmd версии кодеков вышли уже с исправлением.
Ну а потом желательно, что бы хотя бы это мог воспроизводить кодек для виндовс. Именно тот, который поможет воспроизводить файлы данного типа всем плеерам на компе.
Для кодинга можно media coder (название программы) настроить к внедрению. У них там всегда последние cmd кодеки используются. Проект умеренно коммерческий.
Все остальные сами подтянутся :-)
п.с.: это же нереально круто! сайты будут быстрее открываться! Видео через интернет быстрее загружаться! Это 90% чем люди занимаются в интернете)))DjOnline
30.08.2015 11:01+1Как я написал выше, для h264/h265 это не нужно, там изначально используется арифместическое кодирование, если только кто-то специально не сказал использовать CAVLC вместо CABAC например для слабого процессора, что автоматически приравнивание сжатие к уровню Mpeg4-ASP.
skeeet
30.08.2015 06:12+2Я просто оставлю оригинальный твит, из которого все это раздули тут.
https://twitter.com/leahculver/status/634950310159515648/photo/1
kefirfromperm
31.08.2015 08:29+2Интересно только, с какой скоростью он это все кодирует? Мало достичь высокой степени сжатия, важно сделать это быстро.
DjOnline
31.08.2015 13:32+1https://docs.google.com/spreadsheets/d/1i3-cuVSWzsXWZR-ZpEzOYOaSyV9ajz-IK4fxLMzyOaY/edit#gid=6 докрутить вниз до таблицы JPG, второй столбец секунды, третий результат сжатия.
StiffIt 8 секунд, 72%
PackJpg 6 секунд, 76%
WinZip 2 секунды, 77%
JpegCrop 1 секунда, 84%
Скорость алгоритмов WinZip выглядит наиболее оптимально по уровню сжатия/времени.
DmitryVergeles
18.09.2015 15:05+1@aliza, спасибо за статью. по ее следам мы решили углубиться в технические детали проекта и тоже написали статью
Детали DropBox H.264 lossless-сжатия
Protos
Интересно было бы если бы в ОС был встроен алгоритм автосжатия, а при открытии файла (или открытия а полноэкранном режиме) обратная операция
WerewolfPrankster
Да ладно!
LuckyStarr
Это? А еще задолго до этого было: en.wikipedia.org/wiki/DriveSpace Касаемо MS, естественно.
Aingis
Можно и отдельные папки сжимать. Так, amirul в своём посте про загрузку Windows (http://geektimes.ru/post/106684/) предлагал это для ускорения. Правда, надо смотреть, что упор идёт именно в диск, а не процессор. (Я у себя такого не наблюдал.)