Расщепляем QuickTime на атомы
В предыдущих сериях цикла я делал комплименты формату файлов 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?"
