Следуя прекрасным традициям великих инженеров-реверс-инженеров кодеков, теперь стало нормой описывать испытания и невзгоды этого процесса.

История

По сути, в течение многих лет никого в мире с открытым исходным кодом не интересовал кодек Cineform (он же CFHD, Cineform HD и т. Д.) - это нишевый вейвлет-кодек, который при загрузке на Youtube, Facebook или Vimeo не может декодироваться и поэтому явно не достаточно важно для этих сайтов пойти и лицензировать проприетарный декодер. Но недавно GoPro купила Cineform и сделала его выводом по умолчанию в GoPro Studio, их редакторе, а Adobe Premiere добавила его как вариант вывода. Похоже, что основная цель использования CFHD - позволить людям легко редактировать файлы 4K на недостаточно мощном оборудовании и / или системах с плохо работающими проприетарными (без аллитерации) декодерами H264 (серьезно, просто используйте libavcodec, это намного лучше, чем что-либо, на что кто-либо будет лицензировать ты).

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

Стандартизация (вроде)

Все изменилось в 2014 году со следующим заголовком: « Кодек GoPro® CineForm, стандартизованный SMPTE® в качестве стандарта VC-5 » - к сожалению, мир открытого исходного кода не любит платить SMPTE за стандарты, разработанные секретным клубом (подробнее в тот другой день). Но, тем не менее, похоже, что эти файлы однажды могут быть декодированы кем-то, кто захочет потратить деньги. К сожалению, примерно через 1,5 года по причинам, связанным с $ dayjob, мне пришлось стать личным участником SMPTE, чтобы овладеть некоторыми другими стандартами, и теперь у меня был доступ ко всем из них.

Содержимое SMPTE ST 2073 выглядело нормальным, было описание формата битового потока, основанное на 4-байтовых комбинациях тегов / значений, энтропийном кодировании, деквантизации, преобразовании; некоторые из которых потребовались бы годы, чтобы выяснить из двоичного файла. Этот документ во многом был похож на кодек Дирака BBC и легко мог быть реализован за выходные. Тем не менее, реальные файлы не во многом соответствовали документу, что было странно. Все это, конечно, было похоронено мелким шрифтом: «основная технология, лежащая в основе кодека GoPro CineForm, стандартизирована [sic]». Таким образом, в действительности существующие файлы не могли декодироваться декодером VC-5.

На практике может случиться так, что вам придется использовать декодер конкретного производителя, чтобы ваши устаревшие файлы CFHD играли вместе с вашими новыми файлами Standardised®. Это игра, в которую многие поставщики играют с SMPTE, намеренно или иным образом - они создают документ, который объясняет лишь часть того, как реализовать что-то в реальном мире, но создатель технологии может заявить, что их продукт основан на стандартах. Вы можете полагаться только на реализации конкретных производителей, чтобы все работало так, как задумано - AVC-Intra - хороший тому пример - я провел огромное количество реверс-инжиниринга, чтобы добавить это в x264.

Фактический обратный инжиниринг

Итак, основной реверс-инжиниринг начался в свободное от поездов время. Пара тегов присутствовала, но было много недокументированных. Некоторые теги также не работали так, как описано в спецификации, и было множество недокументированных тегов. Бинарный файл действительно объяснил, что это за некоторые из них:

В спецификации упоминается, что коэффициенты lowpass (в данном случае версия кадра размером 1/64) были записаны без квантования. К счастью, один из образцов, который у меня был, был в основном одноцветным, поэтому их было легко найти в шестнадцатеричном редакторе:

Оттуда можно было найти фактические теги для разграничения коэффициентов (0x00 0x04 0xf 0xf) и декодировать первое изображение (так раньше выглядел стационарный телефон для лиц младше 16 лет):

В спецификации указаны коэффициенты Run-length (RL) Variable-length-coded (VLC), и, к счастью, libavcodec уже поддерживает быстрое декодирование. Было довольно просто заимствовать существующий код из декодера DV для создания подписанных таблиц RL-VLC. Интересно, что декодер никогда раньше не поддерживал кодовые слова так долго, как CFHD (до 26 бит), и поэтому мне пришлось послать патч для этого.

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

Как ни странно, они начинаются с таблицы 9 (что случилось с 0–8?), Таблица 17 кажется такой же, как таблица 18, которая указана в спецификации. Также в таблице 9 было 3 escape-кодовых слова или, возможно, специальные кодовые слова - не совсем уверен, что там происходит.

После того, как все коэффициенты были декодированы, это был случай реализации деквантизации и декомпандирования, как описано, и реализации разделяемого вейвлета 2/6, как описано. В этой части спецификации были довольно хорошими (за исключением выравнивания, обсуждаемого ниже). Единственное, на выходе получилось очень темно. В спецификации говорилось о предварительном масштабировании одного из выходных сигналов преобразования - это, казалось, улучшило изображение, но предложенный уровень оказался неправильным. Сэмплы выглядели лучше, когда вы переходили на другой уровень. РЕДАКТИРОВАТЬ: оказывается, что спецификация подходит для этой части, хотя просто предлагает вам сделать сдвиг, когда он действительно является обязательным.

И вот финальная картинка, прекрасно играющая в FFplay:

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

Интересных вещей нет в спецификации

  • Интересная функция, в которой коэффициенты были предварительно выровнены по ширине mod-8, чтобы предположительно разрешить оптимизацию SIMD. Сначала было немного запутанно видеть эти дополнительные коэффициенты, но при выравнивании ширины по модулю 8 вычисления всегда давали правильное количество коэффициентов. Это избавляет от необходимости извлекать все ваши коэффициенты, а затем добавлять отступы обратно или отслеживать, где они должны быть в процессе извлечения; жаль, что его уронили. Стоимость кодирования этого заполнения незначительна.
  • Как определить форматы пикселей (см. Ниже)
  • Любые метаданные в десятках тегов
  • Куча тегов имеет повторяющееся или ненужное значение, не совсем понятно, почему

Интересные штучки в спец.

  • Одна из целей вейвлет-кодеков состоит в том, чтобы позволить декодерам выбирать декодирование только определенных поддиапазонов, чтобы показывать декодирование с более низким разрешением, но декодирование происходит намного быстрее. К сожалению, поток битов CFHD, похоже, не может сказать вам, насколько велики будут данные с коэффициентом пропускания верхних частот, что означает, что вам нужно выполнить декодирование RL-VLC, а затем отбросить все данные. VC-5 увеличивает длину, что значительно упрощает работу. В принципе, вы можете искать конец тега коэффициентов, но это вполне может произойти в данных коэффициента, не зная, экранирован ли он или гарантированно не произойдет, как в MPEG-2.
  • Также существует общее решение проблем с форматом битового потока.

Некоторые неизвестные

  • Существует по крайней мере один старый файл CFHD с более чем 10 обязательными поддиапазонами, которые, по-видимому, есть во всех других сэмплах. Не совсем уверен, что с ним происходит, яркость выглядит нормально, но цветность полностью нарушена. У него также есть тег, чтобы пометить кадр как повторяющийся, что говорит о том, что они пытались сделать вариант с более высоким сжатием. Также отмечен другой тип преобразования.
  • Непонятно, как различать форматы пикселей (RGB, YUV, Bayer) и т. Д. В начале файла есть тег, но у меня есть только несколько образцов для сравнения. На данный момент работают только образцы YUV422, а это большинство из имеющихся у меня. РЕДАКТИРОВАТЬ: YUV422 и RGB теперь работают, RGBA зависит от нового формата пикселей FFmpeg. Байер в какой-то момент.

Спасибо Косте Шишкову за совет и Стейнару Гундерсону за предоставленные образцы файлов. 2016 год - это год CFHD на настольных компьютерах Linux!