Детали DropBox H.264 lossless-сжатия

Недавно нам на глаза попалась статья В Dropbox разработали алгоритм lossless-сжатия для файлов H.264 и JPEG ^[1] и мы решили протестировать это решение и получить какие-то ощутимые технические детали.

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

Так же, эффекта от данного вида сжатия можно ожидать в двух случаях: если в файле в качестве кодера используется CAVLC или если файл закодирован блоками PU и TU максимального размера. А это возможно только в том случае, если кодек H.264 настроен на максимально быстрое кодирование.

О проекте «Pied Piper»

Одним из самых «тяжеловесных» среди всех видов данных является видео, и неудивительно, что сервисы, которые связаны с обработкой, передачей или его хранением, задумываются о компрессии. Однако пути решения этой проблемы могут быть различными. В августе 2015 компания DropBox опубликовала свое видение – свой, пока еще не финальный, алгоритм для видеофайлов стандарта H.264. Деятельность компании главным образом связана с хранением файлов своих пользователей. Пользователю неинтересно, в каком виде они хранятся, а важно лишь то, что обратно, при скачивании, он получит в точности те же файлы, что были загружены. Поэтому алгоритм, предложенный DropBox – без потерь качества. Кроме того, результат компрессии не является видеофайлом исходного формата.

В данной статье попробуем определить эффективность алгоритма при сжатии различных файлов. В качестве вспомогательного инструмента будем использовать ZOND 265 компании Solveig Multimedia (это мы и есть ), анализатор видеофайлов H.264 и H.265.

Все файлы, полученные в статье (исполняемый файл компрессора, скомпилированный для Linux Ubuntu x64 12.04, тестовые видеофайлы) можно скачать по этой ссылке ^[2].

Оценка эффективностьи компрессора проекта «Pied Piper»

Исходные коды и тестовые файлы компрессора доступны на сайте GitHub ^[3]. Для начала скомпилируем компрессор и оценим тестовые файлы. Затем посмотрим эффективность на файлах, встречающихся в реальной жизни.

Компрессия

Четкие инструкции по компиляции компрессора проекта «Pied Piper» доступны только для Linux, это по сути один файл – скрипт «piedpiper_make». Поэтому загружаем Linux Ubuntu x64 и вводим три команды:


git clone https://github.com/danielrh/losslessh264.git


cd ./lossless264


./piedpiper_make


После компиляции в текущей папке появятся файлы компрессора:

h264dec – исполняемый файл компрессора и декомпрессора,
libopenh264.so.0, libopenh264.so – вспомогательные динамическая библиотека и ссылка на нее.

Компрессия осуществляется командой:


./h264dec ./source-file.264 ./destination-file.pip,


Декомпрессия:


./h264dec ./compressed-file.pip ./decompressed-file.264.


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

Тестовые файлы проекта «Pied Piper»

Согласно репозиторию Git, в качестве тестов разработчики использовали несколько файлов – «black.264», «tibby.264», «walk.264», «BA1_FT_C.264», «BAMQ2_JVC_C.264». Загрузив их в Zond 265, видим, что они сжаты одним и тем же образом (см. скриншоты Zond 265, вкладка «Bitstream», рис. 1-3 для файла «tibby.264»). Основная особенность – использование CAVLC (PPS, entropy_coding_mode_flag: 0) и отсутствие B-кадров (SPS,max_num_reorder_frames: 0). Для тестов эффективности взяты первые три файла.

Рис. 1. Блок Sequence Parameter Set (SPS) файла «tibby.264»

Рис. 2. Блок Picture Parameter Set файла «tibby.264»

Рис. 3. Структура видеопотока файла «tibby.264»

Другие тестовые файлы

Пользователи могут получить видеофайлы несколькими способами: снять его камерой (например, своего телефона), скачать его с различных видеосервисов (youtube, vk, vimeo, facebook и т.д.), воспользоваться программой с функцией перекодирования.

В качестве ролика с телефона взят файл с обычного Android-смарфона, это файл «VID_20150917_131139.264». Он так же не содержит B-кадров, но в качестве арифметического компрессора использует CABAC, а не CAVLC. На файлах, скачанных с youtube (они содержат B-кадры и используют CABAC), компрессор выдает ошибку, поэтому не будем включать их в тестирование.

В качестве программы с функцией перекодирования взята консольная утилита ffmpeg (модуль «libx264»). Забегая вперед, сжатие наблюдалось только с пресетом «ultrafast», с пресетом «superfast» сжатия уже не получалось. Тестовые файлы – «tractor-ultrafast.264», «tractor-superfast.264».
Кроме указанных, в таблицу включены еще три файла с целью оценить, оставит ли предложенный алгоритм эффективным включение опций «CABAC» и кодирования блоками PU и TU максимального размера: «black-cabac.264», «tibby-cabac.264» и «tibby-cabac-max-blocks».

Результаты тестирования

Результаты тестирования сведены в таблицах 1 и 2. Данные о количестве блоков PU и TU для таблицы получены программой Zond 265 (вкладка «Stream Stats»). На рис. 4 изображен скриншот с данными для файла «tibby.264».

Рис. 4. Данные о блоках PU и TU для файла «tibby.264»

Таблица 1. Результаты тестов эффективности компрессии компрессора проекта «Pied Piper»

Таблица 2. Результаты тестов эффективности компрессии компрессора проекта «Pied Piper»

Как видно из таблиц, предложенный алгоритм проекта «Pied Piper» в опубликованной версии эффективен в двух случаях: если в файле в качестве кодера используется CAVLC или если файл закодирован блоками PU и TU максимального размера. А это возможно только в том случае, если кодек H.264 настроен на максимально быстрое кодирование. Очевидно, при этом файлы будут получаться довольно больших размеров. Таковы файлы, получающиеся кодеком ffmpeg с libx264 с пресетом «ultrafast».

Спасибо за внимание, будем рады обсудить результаты. Это наша первая экспертная статья, не судите строго.

Автор: DmitryVergeles

Источник ^[4]