Расщепляем QuickTime на атомы

11

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

Предыдущие серии: начало и продолжение.

Одной из ключевых задач создаваемой технологии была десакрализация мультимедиа. Из чего-то возвышенно-футуристического её следовало превратить в обычный тип данных. И в еще один формат файлов, которые могли бы быть использованы в любой системе любой компьютерной платформы, “в настоящем и будущем”.

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

Свобода (настоящая) обеспечивается четко определенными правилами и жесткой базовой структурой технического устройства или общества. В социумах эту роль играют своды законов, продуманных и проверенных реальностью, которые выполняются строго и неукоснительно. Поскольку идеально только то, чего нет, все выявляемые “баги” должны немедленно браться “в работу”, изучаться и исправляться. Но я отвлекся.

Формат файла QuickTime обеспечивает максимальную (полную) свободу для размещаемых в нем данных. Свобода данных проще чем свобода социума, поэтому её базовые принципы могут быть заложены на этапе разработки. Формат выдержал проверку временем, хотя и в него пришлось вносить изменения. Это случилось один раз за почти 30 лет существования технологии.

Мир изменился. В 1990 году никто и представить себе не мог, что когда-нибудь появятся файлы больше 4 гигабайт. Не уверен что это повод для гордости, но этот барьер мир успешно преодолел. В QTFF все чаще стали пытаться впихнуть данные объемом в 5 или 6 гигабайт. Ничего хорошего из этого не получалось, и поднялся злобный вой на весь Интернет.

В итоге, в формат QTFF и в QuickTime были внесены небольшие изменения. Совместимость обновленного формата с старым абсолютная.

Если данным станет тесно в 18,4 экзабайтах (максимум адресуемого пространства для 64-битной адресации), изменений в QTFF потребуется еще меньше. Экзабайт это миллион терабайт, 10 в 18-й степени байт. Насколько я знаю, объём крупнейших в мире банков данных уже измеряется в петабайтах (это 10 в 15-й степени байт), может быть уже в десятках петабайт. До 18 экзабайт еще очень далеко.

Подробности? Если вам они интересны, я вами горжусь.

Структура QTFF

Файл-вездеход состоит из… атомов. Разработчики формата назвали индивидуальные куски данных (chunks, говоря по-русски) атомами. Атом в QTFF может состоять или из данных, или из других атомов. В физике атомы устроены иначе, но цифровые технологии – иные миры. Законы в которых устанавливает создатель. Кроме того, атом в QTFF – всего лишь термин. По моему, удачный.

Кстати, и у создателей QTFF, и у физиков, термин “атом” противоречит смыслу слова, от которого он произошел. С древнегреческого слово “атом” переводится как “неделимый”.


У каждого типа атомов уникальный идентификатор, обозначаемый особым типом данных, который на своей родине называется OSType, а за её пределами – FOURCC.

Описанию этого типа и его истории ниже посвящен целый раздел, но если не вдаваться в детали, это двуликий Янус среди типов данных. Это одновременно и целое число без знака, размером в 32 бита, и 4-символьная мнемоника.

Вот абстрактная структура QTFF-файла (приведены мнемоники типов атомов):

Файл QTFF тоже можно считать атомом: от состоит из двух атомов, ‘moov’ и ‘mdat’. Самый важный из них – ‘moov’. Он состоит из атома-заголовка, и одной или нескольких дорожек. В дорожке могут быть представлены самые разные данные: видео, аудио, эффекты, текст, и вообще что угодно.

Пусть мнемоника ‘moov’ не введёт вас в заблуждение – это не только видео или аудио, это могут быть совершенно любые синхронизированные данные. Результаты исследования на полиграфе (подозреваемого или подопытного), результаты слежения за каким-то объектом в природе, что угодно.

Это фиксация в файле процессов с привязкой их к общей шкале времени. Представление данных в дорожке и их интерпретация – забота codec’ов. (от Code-Decode).

Естественно, ни QuickTime Player, ни другие стандартные инструменты для пользователя, об этих вариантах QTFF совершенно не в курсе. Для работы с этими узкоспециальными данными требовались немалые усилия программистов – QuickTime предоставлял только удобную структуру файла и набор API (интерфейс программиста приложений – функции, структуры данных, константы) для создания, редактирования и воспроизведения QTFF.

К сожалению, это многообещающее направление было упущено руководством Apple, и в разных областях человеческой деятельности появились свои собственные форматы и наборы API для работы с ними. Я работал с QuickTime исключительно в области его типичных приложений (аудио, видео, конверсия графических и видео форматов), но другие применения QuickTime видел – они ничем не уступают специализированным решениям. Просто об этой стороне QuickTime мало кто знал.

Дорожка (‘trak’) – атом с целой иерархией. А то, что заключено в прямоугольные скобки, может быть абсолютно любыми по сложности и структуре комбинациями атомов. Если в операционной системе, где “исполняется” пришедший извне файл, не установлен codec для работы с дорожками определенного типа, она не будет исполнена. Если непонятны все дорожки, открытие файла завершится сообщением об ошибке.

Объемов памяти уже давно достаточно для установки в систему сотен codec’ов, для самых разных вариантов медиа.

FOURCC

Забавно, но факт: об этом типе данных в сети сведений выше крыши. Только, если не знать как все было на самом деле, возникает стойкое убеждение в том, что FOURCC изобрела Microsoft. Иногда (часто), вскользь, упоминается и Apple, применяющая этот тип данных в QuickTime. Украли, наверное, у Microsoft.

Впрочем, процесс забвения пока еще не зашел слишком далеко, да и Microsoft давно уже не та. Моё сообщение об этом типе данных не единственное. В англоязычной википедии, например, этот тип данных описан вполне прилично (хоть и не так подробно, как нравится мне).

FOURCC расшифровывается как “Four Characters Code”. Используется как идентификатор для самых разных целей, в различных форматах файлов и программном обеспечении.

По своей сути это 4-байтовое число, с диапазоном значений от 0 до 4 294 967 295. Но это для компьютера. Ему проще работать с числами.

Есть у FOURCC и “человеческое” лицо. Для людей (программистов и прочих посвященных) это комбинация из 4 символов, мнемоническое обозначение типа объекта. Мнемоники для человека удобнее чисел.

Например, ‘trak’ или ‘mdat’.

FOURCC впервые появились (не говорить же про такую мелочь “изобрели”) в 1982 или 1983 на Apple, в команде разрабатывавшей Mac. На Mac’е этот тип данных называется OSType, им обозначали типы файлов, ресурсов и тому подобные объекты, многих из которых в macOS уже нет. По мнению вики, OSType появился в 1984, вместе с Mac’ом.

В 1985 году компания Electronic Arts использовала FOURCC в IFF (Interchange File Format), формате разработанном для применения на Amiga канадской компании Commodore, в качестве тэгов для обозначения типов данных.

Microsoft впервые применила этот формат в начала 90-х, в RIFF, собственной реализации Amiga IFF для процессоров от Intel. Порядок байт в Intel и Motorola отличается, little- и big-endian.

Строение атома

До внедрения в QuickTime поддержки 64-битных архитектур, атомы в QTFF были устроены только так:

Байты 0-3 размер атома плюс 4 байта размера плюс 4 байта обозначения типа;
Байты 4-7 тип атома, FOURCC;
Байты 8..n данные

Обратите внимание: даже если в атоме данные нулевой длины, значение размера будет 8, это важно для последующего изложения.

Для поддержки данных объемом более 4 гигабайт был разработан еще один формат атомов:

Байты 0-3 всегда 0x00000001;
Байты 4-7 тип атома, FOURCC;
Байты 8-15 размер атома плюс 16 байт заголовков;
Байты 16..n данные.

32-битные атомы никогда не начинаются с 0x00000001, поэтому переделывать старые файлы нет необходимости.

Кроме 0x00000001, значением первых 4 байтов может быть 0x00000000, что означает “атом занимает всю оставшуюся часть файла”. Размер атома в таких случаях не имеет значения.

Если данные, не умещающиеся в 18 экзабайт, станут реальностью, появятся атомы “поколения 0x00000002”.

В продолжении – ответ на вопрос “зачем Apple Computer понадобился QuickTime для Windows?”

Лучший комментарий

11 комментариев Оставить свой

  1. 1

    Спасибо Олег!

  2. 1

    Прочитал статью, интересно, спасибо.

  3. 1
    Inguaruz

    Вот бы ещё серию статей о программировании под mac от Вас, Олег

  4. 3
    Divanodaff

    Ничерта не понял, но было интересно ?

    • 0

      arran, Жаль что сейчас это уже не тот поезд. Но помечтаю — хотел бы я чтоб Олег писал на собственном ресурсе, и все кто любят и ждут его статьи читали его именно там, а не между статей о зарядке или даже того хуже, о том о чем нельзя говорить вслух (подсказка — генеральный спонсор проплаченных рекламных статей что нельзя комментировать, ибо осквернять святые статьи комментами богохульными — грех). Зашквар что карты легли именно так, надеюсь время расставит все правильней. Олегу спасибо большое за интересный матерьял, уважаю и желаю благ.

  5. 0

    Спасибо за такой интересный контент, Олег! По сравнению с новостями это просто царские статьи

  6. 0

    Amiga канадской компании Commodore

    Что вы имеете ввиду? Коммодурь — американская компания. Амига их детище. Как доверять статье, где такое ляпы ??

    • 0
      Олег Свиргстин

      stanpi, про компанию «Коммодурь» не в курсе, а вот Commodore была основана в Торонто, Онтарио. Это Канада. В поисках более благоприятного налогового климата, компания перенесла штаб-квартиру в США, как и многие другие канадские компании (Metrowerks из Quebec, например). Её также корректно называть канадской, как и американской.

      • 0

        Олег, Абсолютно верно в отношении Комода, Но если вспомнить про Амигу, она мало имела отношения к коммодору, который ее и потопил. А восхищались бы сейчас ее решениями, которые были опережающими время тогда, да и сейчас они вполне себе…
        Да, прошу прощения за некоторую грубость, что то пошло не так =)

        • 0
          Олег Свиргстин

          stanpi, Я тоже чуть не нагрубил, так что все ОК. Вот за что я люблю общаться «не по телефону».

Авторизуйтесь Чтобы оставить комментарий