Несжатое видео Y´CbCr в файлах QuickTime
Первоначально опубликованный 14-го декабря 1999 как Ледяная Отгрузка Плавучей льдины 19, часть «Букв от Ледяной группы» Плавучей льдины документов разработки QuickTime.
Формат файла QuickTime позволяет хранение несжатых видеоданных Y´CbCr. Этот документ обеспечивает документацию и маркирует так, чтобы:
Несжатые видеофайлы Y´CbCr, записанные одним приложением, могут быть интерпретированы правильно другим. Это включает:
Y´CbCr окрашивают параметры (например, основные устройства, функция передачи, матрица)
разрядное расположение компонентов Y´CbCr
обработка значений компонентов из диапазона в данных
временное отношение компонентов Y´CbCr друг относительно друга (например, поле/информация о кадрах)
пространственные отношения компонентов Y´CbCr друг относительно друга (например, попиксельная пропорция, cositing)
пространственные отношения компонентов Y´CbCr относительно канонического центра изображения и канонической чистой апертуры (например, для выравнивания правильного образа во время составления композита)
Когда эти файлы оцифровываются или выводят использование определенного интерфейсного стандарта (например, NTSC, цифровые 525, PAL, цифровые 625), соответствующий компонент QuickTime (например, видео цифровой преобразователь, отобразите декомпрессор, видеовыход) может отобразить цвета, канонический центр изображения и каноническую чистую апертуру между файлом и видеосигналом предсказуемым и непротиворечивым способом.
Используя эти метки, приложение и разработчики устройства могут наконец уменьшить конечных пользователей следующих ворчащих проблем удобства пользования:
«Я получил этот файл на Mac, но это выглядит темным на PC».
«Я представил к этому файлу в приложении A; это играет хорошо в MoviePlayer, но похоже на снег в приложении B.»
«Я получил эти данные и взгляд цветов неправильно на моем мониторе».
«Я получил эти данные, но поля подкачиваются, когда я воспроизвожу их. Мое приложение имеет 6 различных связанных с полем средств управления, и я попробовал все 64 комбинации, но ни один из них не работает».
«Я получил и играл эти данные OK, но каждый раз, когда я пытаюсь представить или сделать эффекты с помощью этих данных, существуют запинающиеся прямые обратные проблемы движения».
«Я получил эти данные, и это смотрит, хлюпал или простирался горизонтально».
«Круги, которые я устанавливаю в своем приложении, не выглядят круговыми на видеомониторе».
«Я составляю подобные видеоматериалы, которые я получил с двумя различными устройствами, и видеоданные смещаются горизонтально. Никакая установка полученного размера изображения, кажется, не помогает».
Документация и метки, обрисованные в общих чертах выше, делают корректный обмен возможным. Для общего падежа оцифровки и репродуцирования производственной апертуры стандартных видеосигналов, также желательно сделать корректный обмен простым и недорогим путем сокращения количества перестановок меток, которые приложения и устройства должны поддерживать для взаимодействия с приемлемым числом других приложений и устройств.
С этой целью эта документация также определяет уровень соответствия, названного «производственным» уровнем. Когда приложение или устройство указывают, что может обработать формат с указанным:
тип сжатия и
стандарт видеоинтерфейса
на уровне производства соответствия тогда это значительно ограничивает метки, определенные в этом документе. На Уровне производства Соответствия мы детализируем ограничения.
Приложение или устройство, поддерживающее тип сжатия и стандарт видеоинтерфейса в этом документе, должны быть в состоянии обработать ту комбинацию на уровне производства соответствия. Приложение или устройство являются, конечно, бесплатными поддерживать дополнительные перестановки метки.
Идея здесь состоит в том, что все распаковали приложения Y´CbCr, и устройства поддерживают, по крайней мере, уровень производства соответствия. Это значительно упрощает обмен и разработку приложений.
В этом документе ограничение метки, явно не связанное с соответствием уровня производства, применяется в любом случае.
Обзор
Этот документ описывает типы сжатия для того, чтобы хранить, распаковал данные Y´CbCr в файле QuickTime:
Тип сжатия | FourCC | Описание |
|---|---|---|
k422YpCbCr8CodecType | '2vuy' | 8 битов за компонент 4:2:2 |
kComponentVideoCodecType | 'yuv2' | 8 битов за компонент 4:2:2 |
k444YpCbCr8CodecType | 'v308' | 8 битов за компонент 4:4:4 |
k4444YpCbCrA8CodecType | 'v408' | 8 битов за компонент 4:4:4:4 |
k422YpCbCr16CodecType | 'v216' | 10,12,14,16 битов за компонент 4:2:2 |
k444YpCbCr10CodecType | 'v410' | 10 битов за компонент 4:4:4 |
k422YpCbCr10CodecType | 'v210' | 10 битов за компонент 4:2:2 |
Тогда это описывает расширения ImageDescription, которые должны быть считаны и записаны с этими типами сжатия:
Расширение | Описание | Требуемый |
|---|---|---|
'colr' | цветные параметры | всегда требуемый |
'fiel' | поле/информация о кадрах | всегда требуемый |
'pasp' | попиксельная пропорция | требуемый, если неквадрат |
'хлопок' | чистая апертура | всегда требуемый |
Соглашения
Символы R, G, B, W, X, Y, и Z обозначают легкие измерения, линейно связанные с физическим сиянием. Символы R´, G´, B´, W´, X´ и Y´ обозначают легкие измерения, нелинейно связанные с физическим сиянием. Y является яркостью CIE, и Y´ является видео luma (часто ошибочно называемый яркостью в видео стандартах). Для нелинейных легких измерений, где нет никакой неоднозначности (например, Cb, Cr), мы опустим главный символ (´). Для получения дополнительной информации посмотрите расширение 'colr' ImageDescription.
пол (x) обозначает самое большое целое число, не больше, чем x.
перекройте (x), обозначает самое маленькое целое число не меньше, чем x.
Структуры ImageDescription и буферы изображения
При использовании типов сжатия, определенных в этом документе, набор другие поля ImageDescription как так:
Структура перечисления 1 ImageDescription.
struct ImageDescription |
{ |
long idSize; |
CodecType cType; // one of the compression types above |
long resvd1; |
short resvd2; |
short dataRefIndex; |
short version; // set to 2 |
short revisionLevel; // set to 0 |
long vendor; // set to your vendor type |
CodecQ temporalQuality; // not used -- set to 0 |
CodecQ spatialQuality; // set to codecLosslessQuality |
short width; // number of luma (Y´) sampling instants wide |
short height; // number of picture lines high (incl. both fields) |
Fixed hRes; // not used -- set to 72 << 16 |
Fixed vRes; // not used -- set to 72 << 16 |
long dataSize; // see below |
short frameCount; // set to 1 |
Str31 name; // see below for codec names |
short depth; // see below |
short clutID; // set to -1 |
}; |
Этот документ (за исключением приложения, которое будет упомянуто ниже) может только использоваться для интерпретации версии 2 ImageDescription. Если Вы захотите поддерживать другую версию (ниже или выше), то необходимо будет консультироваться с документацией для той версии. Нет никаких подразумеваемых форвардов или назад совместимости между версиями ImageDescription.
Если Вы хотите поддерживать существующее (версия 0 или 1) 'yuv2' или '2vuy' файлы в поле, предшествующие этому документу, затем видят Приложение: Назад Совместимость для подробных данных.
Если Ваш код требуют интерпретировать ImageDescription с версией, для которой Вы не имеете документации, отклоняете запрос. Например, компонент декомпрессора изображения QuickTime preDecompress() вызовы должны отклонить ImageDescriptions с любой версией, которая они не записаны для обработки.
Если Ваш код требуют интерпретировать ImageDescription с версией 2, но без требуемых расширений ImageDescription, то необходимо также отклонить запрос.
revisionLevel поле указывает назад совместимые изменения в версии. Этот документ описывает revisionLevel 0.
Мы используем термин «буфер» для описания изображения в памяти или в файле QuickTime. «Адрес» относится к адресу памяти или файловому смещению. Буфер изображения имеет строки высоты и является широкими пикселями ширины. «Пиксель» является luma выборка момента (мы проиллюстрируем это для 4:2:2 и 4:4:4 ниже). bytes_per_luma_instant количество, которое мы определим ниже для каждого типа сжатия, указывает число байт на пиксель.
Поле width должно быть кратным числом horiz_align_pixels. Мы определим horiz_align_pixels поскольку каждое сжатие вводит ниже. Декомпрессор изображения QuickTime должен отклонить ImageDescriptions, поле width которого не является кратным числом horiz_align_pixels.
width и height может быть далее ограничен установленным уровнем соответствия, как описано на Уровне производства Соответствия.
rowBytes количество, неявно связанное с каждым буфером изображения, указывает различие между адресом начала последующих строк в буфере изображения. Поскольку сжатие вводит в этом документе, rowBytes равно width*bytes_per_luma_instant. Нет никаких байтов клавиатуры в конце каждой строки.
Определить bytes_per_frame как height*width*bytes_per_luma_instant.
В файлах QuickTime, ImageDescription ('stsd' атом) dataSize поле не используется и должно быть установлено в 0. 'stsz' атом указывает число байтов в каждой выборке и должен быть установлен в bytes_per_frame поскольку сжатие вводит в этом документе.
Во время выполнения цифровой преобразователь видео QuickTime должен установить ImageDescription dataSize поле к 0, и должно возвратить размер изображения bytes_per_frame от VDCompressDone(). QuickTime установит dataSize поле ImageDescription передало декомпрессору изображения к фиксированному размеру изображения от 'stsz' атомов файла. Декомпрессор изображения QuickTime должен отклонить ImageDescriptions чей dataSize поле не равняется bytes_per_frame.
Как адресуют увеличения,
Y´, Cb и компоненты Cr каждой строки сохранены пространственно слева направо и временно самые ранние к последнему.
Строки поля или кадра (см. расширение 'fiel' ImageDescription ниже для получения информации поля/кадра) сохранены пространственно от начала до конца и временно самые ранние к последнему.
depth поле должно быть установлено в значение, определяющееся ниже для каждого типа сжатия. Несмотря на имя, поле глубины не имеет никакого прямого подключения к bytes_per_luma_instant; для типов сжатия в этом документе глубина главным образом используется, чтобы указать, имеет ли тип сжатия альфу.
Уровни изображения QuickTime и видео
Проблема
QuickTime носители имеет 32-разрядный TimeScale. Каждая выборка в QuickTime носители имеет 32-разрядную продолжительность. Вместе продолжительность и TimeScale позволяют Вам указать частоту кадров своих видеоданных.
Фильм в формате QuickTime имеет 32-разрядный TimeScale. Каждый элемент в списке редактирования дорожки QuickTime содержит 32-разрядную продолжительность в фильме TimeScale и 32-разрядное время носителей в носителях TimeScale. Поэтому точность границ редактирования дорожки определяется фильмом TimeScale. Фильм в формате QuickTime также имеет 32-разрядную продолжительность в фильме TimeScale.
Все 32-разрядные упомянутые выше количества являются подписанными значениями дополнения two.
Так как время носителей элемента списка редактирования дорожки (в носителях TimeScale) и продолжительность фильма (в фильме TimeScale) является 32-разрядными количествами, важно выбрать TimeScales, который не переполнит этих полей при нормальной эксплуатации. Во время выполнения также возникает эта проблема. Несмотря на то, что большая часть QuickTime, APIs для управления носителями и времена фильма использует 64-разрядные количества (например, TimeRecord, ICMFrameTime), некоторые внутренние вычисления времени QuickTime, использует только 32 бита, и некоторый QuickTime, APIs (например, CallMeWhen ()) не имеет никакой 64-разрядной версии.
Решения
PAL и цифровые 625 видео имеют точно 25 кадров в секунду. Носители TimeScale 25 и демонстрационные продолжительности носителей 1, вместе с фильмом TimeScale 25, обеспечивают 2 года времени в 32 битах. Это работает хорошо на фильмы только для видео.
NTSC и цифровые 525 видео имеют точно 30/1.001 кадры в секунду. Носители TimeScale 30 000 и демонстрационные продолжительности носителей 1 001, вместе с фильмом TimeScale 30 000, обеспечивают 19,9 часов времени в 32 битах.
30/1.001 уровень NTSC и цифровых 525 иногда приближается к (или ошибочный, чтобы быть) 29.97, который не равняется 30/1.001. Средняя скорость временного кода кадра отбрасывания (например, LTC и VITC, используемый в видео отрасли), более чем 24 часа точно 29.97, но использование временного кода кадра отбрасывания не изменяет уровень видеосигнала. Некоторые существующие фильмы имеют носители TimeScale 2 997, демонстрационные продолжительности носителей 100, и фильм TimeScale 2 997. Это обеспечивает 8,2 дней времени, прежде чем 32-разрядное переполнение, однако после 4,6 часов, это представление отклонится от фактического видео, синхронизирующего наполовину время кадра. Для дорожек с 2 997 масштабами времени, которые более длинны, чем 4,6 часа, точное кадром представление видео синхронизации только возможно, если кадрам позволяют иметь отличающиеся продолжительности.
Большинство приложений сегодня только имеет дело с материалом короче, чем 4,6 часа. Эти приложения должны быть в состоянии считать видеофильмы или с 2 997 или с 30 000 TimeScales. Они могут записать также, но 30 000 TimeScale предпочтены, так как это имеет достаточное время переполнения и точно моделирует видеосигнал.
Наконец, некоторые существующие фильмы имеют носители TimeScale 30, демонстрационные продолжительности носителей 1, и фильм TimeScale 30. Это обеспечивает 2 года времени в 32 битах, но представление отклоняет от NTSC 525 видео синхронизацию / цифровые 525 видео синхронизаций наполовину время кадра только после 16 секунд! Любые такие фильмы, предназначенные для 30/1.001 видео кадра/секунда, неправильно маркированы. Некоторые такие фильмы могут быть предназначены для устройств вывода графических данных, уровни которых являются действительно 30 кадрами/секунда, но обычно это сжатые фильмы низкой скорости передачи, где не требуется точная синхронизация. Поэтому читатель QuickTime, встречающийся с 30 фильмами кадра в секунду с типом сжатия из этого документа, но без требуемых расширений ImageDescription из этого документа, должен предположить, что уровень действительного образа является 30/1.001. Все новые фильмы с типами сжатия из этого документа должны быть созданы с расширениями из этого документа и должны избежать уровня изображения 30 для стандартного видео определения.
Форматы HDTV SMPTE (1920x1035, 1920x1080, 1280x720) имеют обоих 30 (или 60) разнообразие кадра/секунда и 30/1.001 (или 60/1.001) разнообразие кадра/секунда. Старайтесь должным образом маркировать данные HDTV в файлах QuickTime.
Аудио и видео
Для фильмов с аудиотреками и видеотреками, иногда желательно указать редактирования на аудиотреке при более прекрасной гранулярности, чем видеокадр. Так как все редактирования (независимо от дорожки) указаны на фильме TimeScale, необходимо выбрать TimeScale, удовлетворяющий потребности редактирований и на аудиотреках и на видеотреках.
Идеально, Вы выбрали бы TimeScale, который является наименьшим общим кратным аудио и видео носителей TimeScales. Аудиотреки обычно сделали, чтобы TimeScale равнялся числу аудио кадров в секунду (например, 22050, 44100, 48000). Для некоторых комбинаций общих аудио и видео носителей TimeScales это снова приведет к 32-разрядному переполнению времени. Этот компромисс должен быть сделан согласно потребностям приложения.
Пространственные отношения Y´CbCr
Для каждого 4:2:2 тип сжатия, мы опишем позицию двоичного разряда Y ´0, Y ´1, Cb и компонент Cr. Для этого документа «пиксели» в 4:2:2 подразумевают luma (Y´) выборка моментов. Крайний левый luma (Y´) выборка каждой строки в буфере QuickTime является Y ´0 выборок. Пространственные отношения этих четырех компонентов походят так:
Для каждого 4:4:4 или 4:4:4:4 тип сжатия, мы опишем позицию двоичного разряда Y´, Cb, Cr, и (для 4:4:4:4) альфа-компонент (A). В каждом «пикселе» существует выборка всех компонентов:
Численное значение Y´CbCr и цветные параметры
Поскольку каждое сжатие вводит ниже, мы определим, как следующие три канонических количества отображаются на численные значения того типа Y сжатия´, Cb и компоненты Cr:
EY´ : range [0, 1] |
ECb : range [-0.5, +0.5] |
ECr : range [-0.5, +0.5] |
В частности мы определим, как EY´, ECb и ECr отображаются на целочисленные значения типа сжатия, и как те целочисленные значения кодируются (без знака, смещает двоичный файл, подписанное дополнение two).
Каждый ImageDescription с этими типами сжатия должен включать 'colr' расширение с типом 'nclc'. Это расширение определяет цветные параметры для EY´, ECb и ECr.
Вместе, тип сжатия и 'colr' расширение позволяют требуемый дисплей и преобразование цветов данных изображения.
Мы определим два отображения/схемы кодирования. Каждый тип сжатия будет использовать одну из этих схем. Другой, немного отличающиеся схемы кодирования/отображения существуют в видео отрасли, так быть тщательными, который любые данные Y´CbCr Вы приносите в соответствия QuickTime.
Схема A: 'Широкий диапазон', отображающийся с Y без знака´, дополнительный Cb Туо, Cr
Схема A преобразовывает EY´, ECb и ECr в n-bit Y´, Cb и Cr (n> = 8) таким образом:
Y´ = floor(0.5 + (2n-1) * EY´) |
Cb = floor(0.5 + (2n-2) * ECb) |
Cr = floor(0.5 + (2n-2) * ECr) |
Для n=8 битов это уступает:
Y´ = floor(0.5 + 255 * EY´) Y´ = [0,255] as EY´ = [0,1] |
Cb = floor(0.5 + 254 * ECb) Cb = [-127,+127] as ECb = [-0.5, +0.5] |
Cr = floor(0.5 + 254 * ECr) Cr = [-127,+127] as ECr = [-0.5, +0.5] |
Y´ целое без знака. Cb и Cr являются дополнительными целыми числами со знаком two.
Значение-2n-1 (-128 для n=8 битов) может появиться в буфере вследствие отклонения от номинала фильтра. Писатель изображения QuickTime может использовать значение. Читатель изображения QuickTime должен ожидать значение.
Схема B: 'Видео диапазон', отображающийся с Y без знака´, двоичный файл смещения Cb, Cr
Схема B прибывает из отраслевых спецификаций цифрового видео, таких как Rec. ITU-R BT. 601-4. Все стандартные форматы лент цифрового видео (например, SMPTE D-1, SMPTE D-5) и все стандартные ссылки цифрового видео (например, SMPTE 259M-1997 последовательное цифровое видео) используют эту схему. Профессиональное хранение видео и технологическое оборудование от поставщиков, таких как Abekas, Accom и SGI также используют эту схему. MPEG 2, DVC и много других кодеков указывают источник пиксели Y´CbCr с помощью этой схемы.
Схема B преобразовывает EY´, ECb и ECr в n-bit Y´, Cb и Cr (n> = 8) таким образом:
Y´ = floor(0.5 + 2n-8*(219 * EY´ + 16)) |
Cb = floor(0.5 + 2n-8*(224 * ECb + 128)) |
Cr = floor(0.5 + 2n-8*(224 * ECr + 128)) |
Для n=8 битов это уступает:
Y´ = floor(0.5 + 219 * EY´ + 16) Y´ = [16,235] as EY´ = [0,1] |
Cb = floor(0.5 + 224 * ECb + 128) Cb = [16,240] as ECb = [-0.5, +0.5] |
Cr = floor(0.5 + 224 * ECr + 128) Cr = [16,240] as ECr = [-0.5, +0.5] |
Для n=10 битов это уступает:
Y´ = floor(0.5 + 876 * EY´ + 64) Y´ = [64,940] as EY´ = [0,1] |
Cb = floor(0.5 + 896 * ECb + 512) Cb = [64,960] as ECb = [-0.5, +0.5] |
Cr = floor(0.5 + 896 * ECr + 512) Cr = [64,960] as ECr = [-0.5, +0.5] |
Y´ целое без знака. Cb и Cr смещаются двоичные целые числа.
Определенный Y´, Cb и значения компонентов Cr v резервируются как сигналы синхронизации и не должны появляться в буфере:
0 <= v < 2n-8 |
2n - 2n-8 <= v < 2n |
Для n=8 битов это значения 0 и 255. Для n=10 битов это значения 0, 1, 2, 3, 1020, 1021, 1022, и 1023. Писатель изображения QuickTime ответственен за исключение этих значений. Читатель изображения QuickTime может предположить, что они не присутствуют.
Остающиеся значения компонентов (например, 1-15 и 241-254 для n=8 битов и 4-63 и 961-1019 для n=10 битов) размещают случайное отклонение от номинала фильтра и проскакивание в обработке изображений. В некоторых приложениях эти значения используются для переноса другой информации (например, прозрачность). Писатель изображения QuickTime может использовать эти значения, и читатель изображения QuickTime должен ожидать эти значения.
Типы сжатия
Тип сжатия определяет расположение памяти/файла компонентов Y´CbCr. Структуры ImageDescription с этими типами сжатия должны включать определенные расширения, описанные ниже для разрешения корректного обмена и преобразования данных изображения.
Мы покажем схему упаковки для каждого типа сжатия:
Байты пронумерованы от 0. Байт n+1 имеет адрес один выше, чем байт n.
Поскольку Вы перемещаетесь слева направо вдоль схемы, в которой говорится «Увеличивающийся Порядок Адреса», байты увеличиваются в адресе на 1.
Поскольку Вы перемещаетесь слева направо вдоль схемы, в которой говорится «Уменьшающийся Порядок Адреса», байты уменьшаются в адресе на 1.
Если отдельные биты каждого байта показаны, биты идут от старшего значащего бита до младшего значащего бита, поскольку Вы перемещаетесь направо, независимо от порядка байтов.
Если отдельные биты n-bit выборки компонента показаны, они пронумерованы от n-1 (старшего значащего) к 0 (младший значащий).
Мы показываем самое маленькое повторение, выровненный байтом пространственный образец выборок компонента.
Никакое дополнительное дополнение или выравнивание не должны быть выведены.
Нулевые биты
Некоторые типы сжатия ниже приводят нулевые биты, не использующиеся для кодирования данных изображения. Писатель изображения QuickTime должен поместить нуль в эти биты. Операции обработки изображений должны продолжать помещать нуль в эти биты. Читатель изображения QuickTime может предположить, что биты являются нулем.
'yuv2' по сравнению с '2vuy'
Мы определим два 8-разрядных 4:2:2 типы сжатия:
'2vuy' формат, длительно используемый профессиональными форматами видеоленты, протоколами передачи, технологическое оборудование (и компьютерный и не), и схемы сжатия. Это использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от от EY´, ECb и ECr к 8-разрядному Y´, Cb и Cr, таким образом, это не отбрасывает информации от ссылки цифрового видео. Его порядок компонента также соответствует, который передал по ссылке цифрового видео.
'yuv2' является форматом, используемым основанными на PC видеокартами с Y´CbCr к ER´, EG´ EB´ аппаратные средства преобразования, обычно использующиеся для ускорения распаковки MPEG. Macintosh встроенные видео цифровые преобразователи также использует 'yuv2'.
'2vuy' предпочтительный формат для аппаратной и программной разработки, для которой выбор иначе произволен.
'2vuy' 4:2:2 тип сжатия
Маркер ImageCompression.h для использования k422YpCbCr8CodecType.
Именем кодека к использованию является «Y'CbCr Компонента, 8-разрядный 4:2:2».
|
Пиксели 0-1 |
|||
|---|---|---|---|
|
Увеличение порядка адреса |
|||
|
Байт 0 |
Байт 1 |
Байт 2 |
8-разрядный Y ´1 |
|
8-разрядный Cb |
8-разрядный Y ´0 |
8-разрядный Cr |
8-разрядный Y ´1 |
Этот тип сжатия использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr. bytes_per_luma_instant 2. horiz_align_pixels 2. depth 24. Несмотря на имя, этот формат пикселя не является простым реверсированием байта 'yuv2'.
Существуют '2vuy' файлы в поле с версией меньше чем 2. Если Вы хотите поддерживать такие файлы, см. '2vuy'
тип сжатия 'yuv2' 4:2:2
Маркер ImageCompression.h для использования kComponentVideoCodecType.
Именем кодека к использованию является «Компонентное видео».
|
Пиксели 0-1 |
|||
|---|---|---|---|
|
Увеличение порядка адреса |
|||
|
Байт 0 |
Байт 1 |
Байт 2 |
Байт 3 |
|
8-разрядный Y ´0 |
8-разрядный Cb |
8-разрядный Y ´1 |
8-разрядный Cr |
Этот тип сжатия использует схему A («Широкий диапазон», Отображающийся с Y Без знака´, Дополнительный Cb Туо, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr. bytes_per_luma_instant 2. horiz_align_pixels 2. depth 24. Несмотря на имя, этот формат пикселя не является простым реверсированием байта '2vuy'.
Как описано в Техническом примечании «Формат пикселя QuickTime FourCCs», 'yuv2' формат файла эквивалентен 'yuvu' формату пикселя.
Существуют 'yuv2' файлы в поле с версией меньше чем 2. Если Вы хотите поддерживать такие файлы, см. 'yuv2' Назад Совместимость.
v308' 4:4:4 Тип Сжатия
Маркер ImageCompression.h для использования k444YpCbCr8CodecType.
Именем кодека к использованию является «Y'CbCr Компонента, 8-разрядный 4:4:4».
|
Пиксель 0 |
||
|---|---|---|
|
Увеличение порядка адреса |
||
|
Байт 0 |
Байт 1 |
Байт 2 |
|
8-разрядный Cr |
8-разрядный Y´ |
8-разрядный Cb |
Этот тип сжатия использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr. bytes_per_luma_instant 3. horiz_align_pixels 2. depth 24
v408' 4:4:4:4 Тип Сжатия
Маркер ImageCompression.h для использования k4444YpCbCrA8CodecType.
Именем кодека к использованию является «Y'CbCrA Компонента, 8-разрядный 4:4:4:4».
|
Пиксель 0 |
|||
|---|---|---|---|
|
Увеличение порядка адреса |
|||
|
Байт 0 |
Байт 1 |
Байт 2 |
Байт 3 |
|
8-разрядный Cb |
8-разрядный Y´ |
8-разрядный Cr |
8-разрядный A |
Этот тип сжатия использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr. bytes_per_luma_instant 4. horiz_align_pixels 2. depth 32.
В отсутствие другой информации примите (альфа), компонент ведет себя как Y´, как описано в RP SMPTE 157-1995. 16 абсолютно прозрачно, и 235 абсолютно непрозрачно, и каждый предназначается для линейного смешивания Y´, Cb и компоненты Cr на основе процента между 16 и 235.
v216' 4:2:2 Тип Сжатия
Маркер ImageCompression.h для использования k422YpCbCr16CodecType.
Именем кодека к использованию является «Y'CbCr Компонента, 10,12,14,16-разрядный 4:2:2».
|
Пиксели 0-1 |
|||||||
|---|---|---|---|---|---|---|---|
|
Увеличение порядка адреса |
|||||||
|
Байт 0 |
Байт 1 |
Байт 2 |
Байт 3 |
Байт 4 |
Байт 5 |
Байт 6 |
Байт 7 |
|
16-разрядный LE Cb |
16-разрядный LE Y ´0 |
16-разрядный LE Cr |
16-разрядный LE Y ´1 |
||||
Каждый n-bit компонент оставляют выровненным по ширине в слове с прямым порядком байтов на 16 битов. 16-n младшие значащие биты слова на 16 битов являются нулевыми битами (описанный выше). Этот тип сжатия использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr. bytes_per_luma_instant 4. horiz_align_pixels 2. depth 24.
n определяется требуемым 'sgbt' расширением:
|
8-разрядное целое число |
10, 12, 14, или 16 |
тип сжатия 'v410' 4:4:4
Маркер ImageCompression.h для использования k444YpCbCr10CodecType.
Именем кодека к использованию является «Y'CbCr Компонента, 10-разрядный 4:4:4».
3 10-разрядных компонента без знака упаковываются в 32-разрядное слово с прямым порядком байтов. Вот биты 32-разрядного слова с прямым порядком байтов в уменьшающемся порядке адреса:
|
Пиксель 0 |
|||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Уменьшение порядка адреса |
|||||||||||||||||||||||||||||||
|
Байт 3 |
Байт 2 |
Байт 1 |
Байт 0 |
||||||||||||||||||||||||||||
|
Cr |
Y´ |
Cb |
X |
X |
|||||||||||||||||||||||||||
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
2 X бита являются нулевыми битами, описанными выше. Этот тип сжатия использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr. bytes_per_luma_instant 4. horiz_align_pixels 2. depth 24.
v210' 4:2:2 Тип Сжатия
Маркер ImageCompression.h для использования k422YpCbCr10CodecType.
Именем кодека к использованию является «Y'CbCr Компонента, 10-разрядный 4:2:2».
12 10-разрядных компонентов без знака упаковываются в четыре 32-разрядных слова с прямым порядком байтов. Вот четыре 32-разрядных слова в увеличивающемся порядке адреса:
|
Пиксели 0-5 |
|||
|---|---|---|---|
|
Увеличение порядка адреса |
|||
|
Байты 0-3 |
Байты 4-7 |
Байты 8-11 |
Байты 12-15 |
|
32-разрядный Word 0 LE |
32-разрядный Word 1 LE |
32-разрядный Word 2 LE |
32-разрядный Word 3 LE |
Вот биты четырех 32-разрядных слов с прямым порядком байтов в уменьшающемся порядке адреса. Мы пронумеровали каждый компонент с его пространственным порядком. Поскольку Вы перемещаетесь слева направо в изображение QuickTime, Y´ идет от 0 до 5 и Cb, и Cr идут от 0 до 2. Y´ номер 0 Y ´0 выборок, как описано в Пространственных отношениях Y´CbCr.
|
Word 0 |
|||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Уменьшение порядка адреса |
|||||||||||||||||||||||||||||||
|
Байт 3 |
Байт 2 |
Байт 1 |
Байт 0 |
||||||||||||||||||||||||||||
|
X |
X |
Cr 0 |
Y´ 0 |
Cb 0 |
|||||||||||||||||||||||||||
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
Word 1 |
|||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Уменьшение порядка адреса |
|||||||||||||||||||||||||||||||
|
Байт 3 |
Байт 2 |
Байт 1 |
Байт 0 |
||||||||||||||||||||||||||||
|
X |
X |
Y´ 2 |
Cb 1 |
Y´ 1 |
|||||||||||||||||||||||||||
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
Word 2 |
|||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Уменьшение порядка адреса |
|||||||||||||||||||||||||||||||
|
Байт 3 |
Байт 2 |
Байт 1 |
Байт 0 |
||||||||||||||||||||||||||||
|
X |
X |
Cb 2 |
Y´ 3 |
Cr 1 |
|||||||||||||||||||||||||||
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
Word 3 |
|||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Уменьшение порядка адреса |
|||||||||||||||||||||||||||||||
|
Байт 3 |
Байт 2 |
Байт 1 |
Байт 0 |
||||||||||||||||||||||||||||
|
X |
X |
Y´ 5 |
Cr 2 |
Y´ 4 |
|||||||||||||||||||||||||||
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
X биты являются нулевыми битами, описанными выше. Этот тип сжатия использует схему B («Видео Диапазон», Отображающийся с Y Без знака´, Двоичный файл Смещения Cb, Cr) для получения от EY´, ECb и ECr к Y´, Cb и Cr.
bytes_per_luma_instant 8/3. horiz_align_pixels 48. depth 24.
Как описано в Структурах ImageDescription и Буферах Изображения, поле width должно быть кратным числом horiz_align_pixels поскольку все сжатие вводит в этом документе. Поскольку особый случай, применяющийся к 'v210' типу сжатия только, ширина, может быть кратным числом 2, который не является кратным числом horiz_align_pixels (48). Каждая строка видеоданных в буфере изображения увеличена к самой близкой (128-байтовой) границе на 48 пикселей. Биты использовали для Y´, Cb и компоненты Cr вне пиксельной ширины являются нулевыми битами.
Как пример, скажите, что ширина является 1280 (как это для 1280x720 видео HDTV, SMPTE 296M-1997). 1280 не является кратным числом 48. Таким образом, каждая строка в файле занимает 1 296 пикселей (3 456 байтов) вместо 1 280 пикселей. Скажите, что ширина является 1920 (как это для 1920x1080 видео HDTV, SMPTE 274M-1995). 1920 является кратным числом 48. Таким образом, каждая строка в файле занимает точно 1 920 пикселей (5 120 байтов).
Расширение 'colr' ImageDescription
Это расширение всегда требуется при использовании типов сжатия в этом документе. Это позволяет читателю правильно отображать видеоданные и преобразовывать его в другие форматы.
Цель 'colr' расширения состоит в том, чтобы позволить, Вы отобразить численные значения пикселей в файле к общему представлению раскрашиваете, какие изображения могут быть правильно сравнены, объединены и выведены на экран. Общим представлением является CIE трехцветные значения XYZ (определенный в Публикации CIE № 15.2).
'colr' расширение разработано для работы на многократные приложения обработки изображений, такие как видео и печать. Каждое приложение, управляемое его собственным набором исторических и экономических фактов, имеет свой собственный набор параметров, должен был отобразить от пиксельных значений до CIE XYZ. Поэтому 'colr' расширение имеет этот формат:
|
32-разрядный OSType |
Тип цветных параметров. Примеры: 'nclc' для видео, 'профессор' для печати. |
|
Содержание: размер и формат зависят от |
|
В настоящее время два значения colorParamType определяются:
'nclc': цветовая модель, используемая для всех текущих видеосистем, известных как «непостоянное кодирование яркости». Описанный ниже.
'профессор': цветовая модель, используемая для сканирования, печати и отображения, печатает изображения, этот тип 'colr' встраивает профиль ICC в ImageDescription. Это - цветовая модель, используемая ColorSync Apple. Содержание этого типа не определяется в этом документе. Свяжитесь Apple для получения дополнительной информации о 'профессоре' вводят 'colr' расширение.
Расширение 'nclc' 'colr' ImageDescription: параметры цвета Y´CbCr
'colr' расширение типа 'nclc' всегда требуется при использовании типов сжатия в этом документе. Это указывает цветные параметры канонического EY´, ECb и компоненты ECr, которые мы представили выше и отобразили на каждый тип сжатия.
Если Вы не знакомы с условиями и/или спецификациями ниже, но Вы знаете, что Ваши видеоданные прибыли из определенного вида видеосигнала и/или предназначаются, чтобы быть выведенными как определенный вид видеосигнала, мы обеспечиваем простую таблицу ниже показа оптимальных значений для установки в 'colr' расширении.
Все текущие видеосистемы используют эту модель:
R, G, и B являются трехцветными значениями (например, candelas/meter2), чье отношение к CIE трехцветные значения XYZ могут быть получены на набор основных устройств и белой точки, выбранной параметром основных устройств 'colr' расширения с помощью метода, описанного в RP SMPTE 177-1993. В наших целях R, G, и трехцветные значения B нормализованы к диапазону [0,1].
ER´, EG´ и EB´, также в диапазоне [0,1], связаны с R, G, и B нелинейной функцией передачи, маркированной как f () и g () выше. transferFunction параметр 'colr' расширения идентифицирует f () для Вашего изображения QuickTime.
f () обычно выполняется в камерах, и g () обычно выполняется в дисплеях, таким образом, ER´, EG´ и EB´ часто передаются как напряжение в видеосигналах. f (W) равен g-1 (RI (W)), где RI (представляющий намерение) является эмпирическим фактором, описанным в документах, таких как Чарльз Пойнтон «Восстановление гаммы», Человеческое Видение и Электронная Обработка изображений III, Продолжения Конференции SPIE/IS&T 3299 (Сан-Хосе, Калифорния, 26 - 30 января 1998), редактор Б. E. Rogowitz и T. N. Pappas (Беллингем, Вашингтон: SPIE, 1998).
Наконец, операция над матрицей на нелинейных компонентах (работа, называемая «непостоянным кодированием яркости»), получает нас между ER´, EG´, и EB´ и канонический EY´, ECb и компоненты ECr представили выше. Параметр матрицы 'colr' расширения идентифицирует матрицу для Вашего изображения QuickTime. EY´ находится в диапазоне [0,1] и ECb, и ECr находится в диапазоне [-0.5 0.5].
|
32-разрядный OSType |
'nclc' |
|
16-разрядный целочисленный индекс |
Координаты цветности CIE 1931 xy красной основной, зеленой основной, синей основной и белой точки. |
|
16-разрядный целочисленный индекс |
Нелинейная функция передачи от RGB до ER´ EG´ EB´ |
|
16-разрядный целочисленный индекс |
Матрица от ER´ EG´ EB´ к EY´ ECb ECr. |
Значения ниже соответствуют, те в последовательности выводят на экран расширение, определенное в MPEG 2 (Rec. Раздел ITU-T H.262 (1995 E) 6.3.6).
Основные устройства
Вот значения основных устройств:
|
|
Зарезервированный. |
|||||||||||||||
|
1 |
ITU-R рекомендации BT.709-2, SMPTE 274M-1995, и SMPTE 296M-1997.
|
|||||||||||||||
|
2 |
Основные устройства неизвестны. |
|||||||||||||||
|
3-4 |
Зарезервированный. |
|||||||||||||||
|
5 |
Технология EBU. 3213 (1981).
|
|||||||||||||||
|
6 |
SMPTE C Основные устройства от RP SMPTE 145-1993. Используемый в SMPTE 170M-1994, SMPTE 293M-1996, SMPTE 240M-1995, и временной цветной реализации SMPTE 274M-1995.
|
|||||||||||||||
|
7-65535 |
Зарезервированный. |
Следующие значения, от ITU-R Рекомендации Система BT.470-4 M и FCC 1953 года спецификация NTSC, являются устаревшими и никогда не использовались для кодирования любого цифрового изображения. Если Вам говорят, что Ваше изображение кодируется с этими значениями, Вы почти определенно хотите SMPTE C, основные устройства (кодируйте 6 выше), вместо этого:
|
x |
y |
|
|---|---|---|
|
зеленый |
0.21 |
0.71 |
|
синий |
0.14 |
0.08 |
|
красный |
0.67 |
0.33 |
|
белый (CIE Иллинойс. C) |
0.310 |
0.316 |
Следующие значения, от ITU-R Рекомендации Система BT.470-4 B, G, были заменены Технологией EBU. 3213 (кодируют 5 выше). Технология EBU. 3 213 значений используются для цифрового и составного видео PAL с 625 строками:
|
x |
y |
|
|---|---|---|
|
зеленый |
0.29 |
0.60 |
|
синий |
0.15 |
0.06 |
|
красный |
0.64 |
0.33 |
|
белый (CIE Иллинойс. D65) |
0.313 |
0.329 |
Функция передачи
Вот значения transferFunction (функционируйте f () в схеме выше). Функция передачи идентична для красного, зеленого цвета, и синий, и показана как отображение от W (например, R, G, B) к EW´ (например, ER´ EG´ EB´):
|
|
Зарезервированный. |
||||
|
1 |
ITU-R рекомендации BT.709-2, SMPTE 274M-1995, SMPTE 296M-1997, SMPTE 293M-1996 и SMPTE 170M-1994.
|
||||
|
2 |
Функция передачи неизвестна. |
||||
|
3-6 |
Зарезервированный. |
||||
|
7 |
SMPTE 240M-1995 и временная цветная реализация SMPTE 274M-1995.
|
||||
|
8-65535 |
Зарезервированный. |
Последовательность MPEG 2 выводит на экран расширение transfer_characteristics, определяет код 6, чья функция передачи идентична этому в коде 1. Писатели QuickTime должны отобразиться от 6 до 1 при преобразовании от transfer_characteristics до transferFunction.
BT.470-4 ITU-R рекомендации указал «принятое гамма значение получателя, для которого первичные сигналы предварительно исправлены» как 2,2 для NTSC и 2.8 для систем PAL. Эта информация является и неполной и устаревшей. Современные 525-и с 625 строками цифровой и системы NTSC/PAL используют функцию передачи с кодом 1 выше.
'colr' расширение заменяет ранее определенное расширение 'gama' ImageDescription. Писатели файлов QuickTime никогда не должны писать и в ImageDescription, и читатели файлов QuickTime должны проигнорировать 'gama', если присутствует 'colr'.
Некоторые основанные на Macintosh видеосистемы применяют дополнительную функцию передачи к входящим данным Y´CbCr во время получения так, чтобы, когда это преобразовывается в нелинейный R´G´B´ для дисплея на экране Macintosh во времени воспроизведения, это выглядело корректным данный функцию передачи бэкэнда графики Macintosh по умолчанию. Эта работа является в настоящее время не представимой или поддерживается 'colr' параметрами.
Матрица
Вот значения для матрицы. Мы показываем формулу для EY´ в диапазоне [0,1]. Можно получить формулу для ECb и ECr путем нормализации (EY´ - EB´) и (EY´ - ER´), соответственно, к диапазону [-0.5, +0.5]. Другими словами, если EY´ уравнение имеет форму:
|
EY´ = KG´EG´ + KB´EB´ + KR´ER´ |
Тогда формулы для ECb и ECr:
|
ECb = (0.5 / (1 - KB´)) (EB´ - EY´) |
|
ECr = (0.5 / (1 - KR´)) (ER´ - EY´) |
|
|
Зарезервированный. |
|
|
1 |
ITU-R рекомендации BT.709-2 (1125/60/2:1 только), SMPTE 274M-1995 и SMPTE 296M-1997.
|
|
|
2 |
Матрица неизвестна. |
|
|
3-5 |
Зарезервированный. |
|
|
6 |
ITU-R рекомендации BT.601-4, ITU-R рекомендации система BT.470-4 B и G, SMPTE 170M-1994 и SMPTE 293M-1996.
|
|
|
7 |
SMPTE 240M-1995 и временная цветная реализация SMPTE 274M-1995.
|
|
|
8-65535 |
Зарезервированный. |
Последовательность MPEG 2 выводит на экран расширение matrix_coefficients, определяет код 5, чья матрица идентична этому в коде 6. Писатели QuickTime должны отобразиться 5 - 6 при преобразовании от matrix_coefficients до матрицы.
Следующие значения, от FCC 1953 года спецификация NTSC, являются устаревшими. Если Вам говорят, что Ваше изображение кодируется с этими значениями, Вы почти определенно хотите SMPTE 170M-1994, значения (кодируйте 6 выше), вместо этого:
|
EY´ = 0,59 EG´ + 0,11 EB´ + 0.30 ER´ |
Следующие значения, от ITU-R Рекомендации BT.709-1, были заменены ITU-R Рекомендации BT.709-2 (кодируйте 1 выше):
|
EY´ = 0,7154 EG´ + 0,0721 EB´ + 0.2125 ER´ |
Выборка 'colr' настройки
Если Вы не знаете лучше, вот оптимальные значения для использования для некоторых общих форматов видеосигнала:
|
Формат видеосигнала |
|
|
|
|---|---|---|---|
|
Составьте NTSC (SMPTE 170M-1994) |
6 |
1 |
6 |
|
Цифровые 525 (SMPTE 125M-1995 (4:3 параллель), SMPTE 267M-1995 (16:9 параллель), SMPTE 259M-1997 (последовательный)) |
|||
|
720x483 прогрессивный 16:9 (SMPTE 293M-1996) |
|||
|
Составьте PAL (Rec. ITU-R BT. 470-4) |
5 |
1 |
6 |
|
Цифровые 625 (Rec. ITU-R BT. 656-3) |
|||
|
1920x1035 HDTV (SMPTE 240M-1995, SMPTE 260M-1992) |
6 |
7 |
7 |
|
1920x1080 HDTV временная цветная реализация (SMPTE 274M-1995) |
|||
|
1920x1080 HDTV (SMPTE 274M-1995) |
1 |
1 |
1 |
|
1280x720 HDTV (SMPTE 296M-1997) |
|||
|
Что-либо еще |
2 |
2 |
2 |
Некоторые цифровые видеосигналы могут перенести индекс видео (см. RP SMPTE 186-1995), который явно маркирует основные устройства, transferFunction, и матрица сигнала. Если Ваше видео, оцифровывающее аппаратные средства, может считать индекс видео, то используйте те значения для заполнения 'colr' расширения вместо значений по умолчанию выше. Если Ваши аппаратные средства видеовыхода могут вставить индекс видео, рассмотрите выполнение так согласно 'colr' дополнительным полям.
Расширение 'fiel' ImageDescription: поле/Информация о кадрах
Это расширение всегда требуется при использовании типов сжатия в этом документе. Это определяет временные и пространственные отношения каждой из строк высоты данных в буфере изображения. Эта информация требуется, чтобы правильно отображать и обрабатывать видеоданные (например, все еще структурировать, замедленное воспроизведение, CGI).
|
8-разрядное целое без знака |
1 для прогрессивного сканирования, 2 для 2:1 чередовался |
|
8-разрядное целое без знака |
Зависит от |
Мы даем каждую строку буфера, в порядке от самого низкого адреса до самого высокого адреса, числа
|
0 <= n <= |
Адрес байта строки n в буфере поэтому rowBytes*n.
Мы даем каждую строку буфера, в пространственном порядке сверху донизу, числе
|
0 <= S <= |
Строки, так пронумерованные, вызывают строками изображения. На дисплее строки изображения равномерно расположены с интервалами без разрывов. Для чересстрочных изображений строка в одном поле вертикально расположена точно на полпути между следующим выше и более низкими строками в другом поле. Когда Вы перемещаетесь от главной строки изображения до нижней строки изображения чересстрочного буфера или дисплея, Вы чередуетесь между полями на каждой строке.
Мы даем каждую строку буфера, во временном порядке от самого раннего до последнего, числа
|
0 <= T <= |
Для каждой установки полей и подробности, мы определим S (n) и T (n), которые отображаются от порядка адреса до пространственного и временного порядка, соответственно.
Если fields 1, тогда
буфер содержит прогрессивное изображение сканирования.
подробность 0.
S (n) =T (n) =n
Если fields 2, тогда
буфер содержит 2:1 чередованное изображение. существует четыре возможных упорядочивания адреса:
если (
detail== 1), тогдаT (n) =n: буфер содержит два поля во временном порядке
случай 1a: поле с более низким адресом содержит самую верхнюю строку
граница =
ceil(height/2)если (n> = граница), то S (n) = (n-граница) *2+1 еще S (n) = n*2
если (
detail== 6), тогдаT (n) =n: буфер содержит два поля во временном порядке
случай 2a: поле с более высоким адресом содержит самую верхнюю строку
граница =
floor(height/2)если (n> = граница), то S (n) = (n-граница) *2 еще S (n) = n*2+1
если (
detail== 9), тогдаS (n) =n: буфер содержит два поля, которые соткали вместе в пространственном порядке
случай 1b: поле, содержащее строку с самым низким адресом, временно ранее
если (n модификация 2 == 0), то T (n) =n/2 еще T (n) =
floor(n/2)+ceil(height/2)
если (
detail== 14), тогдаS (n) =n: буфер содержит два поля, которые соткали вместе в пространственном порядке
случай 2b: поле, содержащее строку с самым низким адресом, временно позже
f (n модификация 2 == 0), тогда T (n) =n/2 +
floor(height/2)еще T (n) =floor(n/2)
Ни один из битов выше непосредственно не подразумевает тип поля видеосигнала (F1 или F2). Условия F1 и F2 относятся к характеристике электрической формы волны видеосигнала для данного поля. Чтобы определить, является ли поле в файле QuickTime F1 или F2, необходимо знать тип видеосигнала и намеченную позицию буфера QuickTime в видео растре. Учитывая тип видеосигнала, можно получить растровую позицию из 'хлопка' расширение ImageDescription, описанное ниже.
Ни один из битов выше не соответствует часто неправильно используемому сроку «полевое преобладание». Часть видеоматериалов получает полевое преобладание, когда каждый передает границам кадра, на которых может быть отредактирована видеозапись. Полевым преобладанием является любой доминирующий F1 (редактирования падают между F2 и последующим F1), или доминантный признак F2 (редактирования падают между F1 и последующим F2). Как только видеоматериалы помещаются в файл QuickTime, его поля были сгруппированы в кадры, и редактирования только возможны на одной границе или другом. Таким образом для определения полевого преобладания видеоматериалов в файле QuickTime определите тип поля (F1 или F2) временно более раннего поля в каждом кадре файла QuickTime. Временно более раннее поле каждого кадра QuickTime является доминирующим полем, и временно более позднее поле каждого кадра QuickTime является недоминирующим полем.
Попиксельная пропорция, чистая апертура и пропорция изображения
Каждое изображение QuickTime имеет «попиксельную пропорцию», которая является пространством по горизонтали luma выборка моментов по сравнению с пространством по вертикали строк изображения, когда выведено на экран на дисплее. Это указано расширением 'pasp' ImageDescription. Приложения должны знать попиксельную пропорцию, чтобы нарисовать круглые круги, строки под указанным углом, и т.д.
Каждое изображение QuickTime имеет «чистую апертуру», которая является ссылочным прямоугольником, указанным относительно пикселей ширины и строк высоты изображения требуемым 'хлопком' расширение ImageDescription.
Используя попиксельную пропорцию и чистые апертурные размерности, мы можем получить «пропорцию изображения», которая является горизонталью к вертикальному отношению расстояния чистой апертуры на дисплее. Пропорция изображения обычно 4:3 или 16:9.
Чистая апертура используется для связи расположений в двух изображениях QuickTime. Учитывая два изображения QuickTime с идентичной пропорцией изображения, можно предположить, что верхний левый угол чистой апертуры каждого изображения является совпадающим, и правый нижний угол чистой апертуры каждого изображения является совпадающим.
Чистая апертура также обеспечивает детерминированное отображение между изображением QuickTime и областью видеосигнала (как замечено на дисплее), от которого это было получено или к которому это будет играться. Каждый стандарт видеоинтерфейса (например, NTSC, цифровые 525, PAL, цифровые 625) также определяет «чистую апертуру» с точки зрения ее электрического сигнала. Срок «чистая апертура» фактически происходит в видео отрасли (см. RP SMPTE 187-1995). Можно думать о чистой апертуре стандарта видеоинтерфейса как о закрепленной прямоугольной области на дисплее того стандарта. Учитывая изображение QuickTime и компонент видео QuickTime, реализовывая определенный интерфейсный стандарт (например, видео цифровой преобразователь, декомпрессор изображения, видеовыход), если изображение и стандарт имеют ту же пропорцию изображения, то компонент должен отобразить чистую апертуру изображения к чистой апертуре видеосигнала. Т.е.
верхний левый угол чистой апертуры изображения QuickTime отображается на верхний левый угол чистой апертуры на дисплее, и
правый нижний угол чистой апертуры изображения QuickTime отображается на правый нижний угол чистой апертуры на дисплее.
Пример. Скажите, что пользователь импортирует два клипа с 4:3 пропорция изображения в приложение NLE и выполняет переход, такой как плавно накладывание между двумя клипами. Приложение должно знать, как выровнять пиксели каждого исходного клипа в конечном результате. Даже если оба клипа имеют ту же ширину и высоту, они не обязательно представляют ту же область дисплея (или, эквивалентно, видеосигнал). Это вызвано тем, что клипы, возможно, были получены на различных видео устройствах цифрового преобразователя, оцифровывающих различные области входящего видеосигнала. Пользователь замечает, что один или оба из клипов кажутся «смещенными» в окончательном результате. Многократные поколения обработки производят еще более явные сдвиги.
'Хлопок' расширение ImageDescription устраняет эту проблему. Во-первых, метка цифровых преобразователей видео QuickTime получила клипы с расположением чистой апертуры от исходного видеосигнала. Затем, когда пользователь импортирует эти клипы и выполняет переход, приложение NLE использует чистую апертуру каждого входного клипа, чтобы выяснить, как соответствуют пиксели каждого клипа. Приложение NLE производит выходной клип с чистой апертурой, соответствующей двум входным клипам. Наконец, приложение NLE воспроизводит результат, и декомпрессор изображения QuickTime или компонент видеовыхода выравнивают чистую апертуру клипа к тому из выходного видеосигнала. Чистая апертура обеспечивает недостающие данные так, чтобы пользователь не видел сдвигов.
Идеально, все приложения и устройства оцифровали бы и вывели бы ту же область видеосигнала так, чтобы чистая апертура была фиксирована относительно пикселей ширины и строк высоты изображения. К сожалению, это находится далеко не так в отрасли сегодня. Расширение ImageDescription 'хлопка' предоставляет необходимую информацию так, чтобы корректный обмен файлами был возможен. На Уровне производства Соответствия этот документ указывает значительно ограниченный набор параметров ImageDescription, которые все новые устройства и приложения должны поддерживать как минимум, так, чтобы обмен файлами мог быть простым и недорогим.
Даже приложения, производящие синтетическое формирование изображений (например, приложения анимации) должны маркировать выходные клипы 'хлопком' расширением ImageDescription. Приложение должно позволить пользователю располагать объекты относительно (обычно 4:3, или 16:9) чистят апертуру. Например, это позволяет выводу многократных приложений анимации быть объединенным без ручного выравнивания. И это позволяет приложению синтезировать формирование изображений с помощью данных, первоначально полученных из видеосигналов (например, ключи, матовые стекла, данные ввода данных о движении, данные получения формы) и затем повторно комбинировать то формирование изображений с исходными видеосигналами без ручного выравнивания.
Термин «чистая апертура» не относится к:
Области "Safe Action" и "Safe Title", определенные в RP SMPTE 27.3-1989.
Область видео растра, который лишен полустрок.
Область видео растра, который лишен артефактов, таких как черные полосы от камер DV или панели мусора от микросхем сжатия.
Эти три элемента выше могут перенести другие расширения ImageDescription, но они выходят за рамки этого документа. Размер и расположение чистой апертуры фиксируются для данной видео стандартной частоты и частоты дискретизации; это не зависит от используемого оборудования получения или содержимое изображения полученного сигнала.
Некоторый NLE и много составляющих композит приложений позволяют пользователю масштабировать и панорамировать видеоклипы друг относительно друга для артистического эффекта. 'Хлопок' расширение ImageDescription не предназначается, чтобы использоваться с этой целью. Изображение QuickTime 'хлопок', который должно всегда указывать расширение ImageDescription, где то единственное изображение QuickTime должно быть выведено на экран относительно стандарта, чистит апертуру дисплея.
И для QuickTime и для стандартов видеоинтерфейса, «центр изображения» определяется как центр чистой апертуры.
Часто, приложения оцифровывают область видеосигнала, который немного больше, чем чистая апертура. В видео отрасли эту область вызывают «производственной апертурой», является cocentric с чистой апертурой и определяется для имения знакомого 720x486 и 720x576 размерности для 525-и форматов цифрового сигнала с 625 строками. Оцифровка производственной апертуры размещает связанные с краем артефакты фильтрации путем обеспечения фиксированной области, где такие артефакты позволяются (см. RP SMPTE 187-1995). Таким образом, нормально для изображения QuickTime иметь чистую апертуру, размерности которой отличаются от width и height.
Попиксельная пропорция, чистая апертура и пропорция изображения могут быть ограничены установленным уровнем соответствия, как описано на Уровне производства Соответствия
Расширение 'pasp' ImageDescription: попиксельная пропорция
Если попиксельная пропорция не квадратная (1:1), это расширение требуется при использовании типов сжатия в этом документе. Это указывает пространство по горизонтали luma выборка моментов по сравнению с пространством по вертикали строк изображения на дисплее:
|
32-разрядное целое число |
Пространство по горизонтали Luma выборка моментов |
|
32-разрядное целое число |
Пространство по вертикали строк изображения |
hSpacing и vSpacing имейте те же модули, но те модули являются неуказанными: только вопросы отношения. hSpacing и vSpacing май или может не быть в сокращенных условиях, и они могут сократить до 1/1. Они оба должны быть положительными.
Строки изображения определяются с помощью расширения 'fiel' ImageDescription выше.
Можно думать об этих значениях как об отношении ширины пикселя к высоте пикселя. Например, скажите, что Вы хотите нарисовать круг, кажущийся круглым на дисплее и чей диаметр является n горизонтальными пикселями (luma выборка моментов). Нарисуйте эллипс, который является n пикселями широкие и n*hSpacing/vSpacing пиксели (строки изображения) высоко. Заметьте, что vSpacing находится в знаменателе: чем больше пространство по вертикали пикселей (строки изображения), тем меньше вертикальных пикселей Вам нужно для соответствия данного числа горизонтальных пикселей (luma выборка моментов) на дисплее.
Попиксельная пропорция не является тем же как «пропорцией изображения», определяющейся в Попиксельной пропорции, Чистой Апертуре и Пропорции изображения выше. Примеры общих пропорций изображения 4:3 и 16:9.
Стандартные попиксельные пропорции определения
Существует широко распространенный беспорядок о попиксельной пропорции стандартных форматов видео определения. Если Ваше устройство передает один из них 4:3 форматы видео пропорции изображения, это корректные попиксельные пропорции:
|
4:3 стандартный формат определения |
|
|
|---|---|---|
|
«Квадратный пиксель» Аналоговое видео с 525 строками выбирается в (12+3/11) MHz (например, составной NTSC) Аналоговое видео с 625 строками выбирается в 14,75 МГц (например, составной PAL) |
1 |
1 |
|
«Неквадратные 525» Цифровые 525 (SMPTE 125M-1995, 13,5 МГц) Аналоговое видео с 525 строками выбирается в 13,5 МГц (например, составной NTSC) |
10 |
11 |
|
«Неквадратные 625» Цифровые 625 (Rec. ITU-R BT. 656-3, 13,5 МГц) Аналоговое видео с 625 строками выбирается в 13,5 МГц (например, составной PAL) |
59 |
54 |
luma частоты дискретизации, показанные выше (13,5 МГц, (12+3/11) MHz, и 14,75 МГц), повсеместны в видео отрасли. Кроме того, все существующие (и вероятно будущее) стандартное видеооборудование определения предполагает, что выборка 525 линейных сигналов в (12+3/11) MHz или 625 линейных сигналов в 14,75 МГц, приводит к квадратным пикселям. Поэтому для стандартных форматов определения мы получаем попиксельную пропорцию неквадратных пикселей (13,5 МГц в обоих случаях) путем взятия отношения 13,5 МГц и квадратной частоты дискретизации.
Типовые приложения управляют изображениями 720 пикселей шириной для неквадратных данных и 640 (с 525 строками) или 768 пикселей (с 625 строками) широкие изображения для квадратных данных. Обратите внимание на то, что 640/720 не равняется 10/11, и 768/720 не равняется 59/54. Если Вы захотите преобразовать изображения между квадратом и неквадратом с помощью ширин выше, то Вы должны будете или обрезать исходное изображение или дополнить конечное изображение: изображения с ширинами выше не представляют ту же базовую область видеосигнала. Необходимо поддержать центр изображения при выполнении этих дополнение или обрезка операций.
В теории форматные соотношения неквадратного пикселя выше, и поэтому также квадрат luma частоты дискретизации, заменяются новыми вычислениями в RP SMPTE 187-1995. Однако, потому что стандартные попиксельные пропорции определения от той спецификации не отражают фактические отношения, используемые никем существующим (и вероятно будущее) стандартное оборудование определения, необходимо использовать значения выше. По той же причине 13,5 МГц и 18 МГц чистят апертурные числа, которые мы представим в Типичной ширине, высоте, и 'хлопать', Настройки отличаются от тех по RP SMPTE 187-1995.
Вот сопоставимая диаграмма для существующих стандартных форматов определения с 16:9 пропорция изображения. За исключением формата на 18 МГц, форматы ниже электрически идентичны тем в таблице выше. Обычно Вы используете 16:9 форматы ниже путем нажатия на кнопку, маркированную «16:9» по стандарту 4:3 монитор; монитор берет тот же сигнал и выводит на экран, это вертикально сжалось. Чистые апертуры 16:9 форматы имеют то же число пикселей и строк как 4:3 форматы выше. Различие - то, что 16:9 камеры получат данные 16 единиц в ширину 9 единицами в высоту в чистую апертуру, и 16:9, мониторы выведут на экран чистую апертуру, таким образом, что это - 16 единиц в ширину 9 единицами в высоту на поверхности отображения, вместо 4 3. Так как чистая апертура все еще имеет то же число пикселей и строк, но теперь имеет различную пропорцию изображения, можно отобразиться 4:3 значения выше в 16:9 значения ниже путем простого умножения на (16/9) / (4/3) = (4/3). 18 МГц SMPTE 267M-1995 стандарт являются исключительными в той его чистой апертуре, имеет 4/3 как многие пиксели на строку так, чтобы пиксели могли сохранить попиксельную пропорцию с 525 строками 4:3 цифровое видео (10/11).
|
16:9 стандартный формат определения |
|
|
|---|---|---|
|
Аналоговое видео с 525 строками выбирается в (12+3/11) MHz (например, составной NTSC) Аналоговое видео с 625 строками выбирается в 14,75 МГц (например, составной PAL) |
4 |
3 |
|
Цифровые 525 (SMPTE 267M-1995, 13,5 МГц) Аналоговое видео с 525 строками выбирается в 13,5 МГц (например, составной NTSC) 720x483 прогрессивный 16:9 (SMPTE 293M-1996, 13,5 МГц) |
40 |
33 |
|
Цифровые 625 (Rec. ITU-R BT. 656-3, 13,5 МГц) Аналоговое видео с 625 строками выбирается в 13,5 МГц (например, составной PAL) |
118 |
81 |
|
Цифровые 525 (SMPTE 267M-1995, 18 МГц) Примечание там является большим количеством выборок на строку в 18 МГц |
10 |
11 |
Попиксельные пропорции с высоким разрешением
Проект форматов HDTV обладал преимуществом непредусмотрительности. Эти форматы определяют чистую апертуру, пропорция изображения которой точно 16:9. Смотря на число пикселей и строк в чистой апертуре, можно вычислить попиксельную пропорцию. Один не должен рассматривать luma частоту дискретизации.
Для 1920x1035 HDTV (SMPTE 240M-1995, SMPTE 260M-1992), чистый апертурный размер сомнителен. SMPTE 240M-1995 и SMPTE 260M-1992 указывают чистую апертуру 1 888 пикселей 1 017 строками. Однако SMPTE RP 187-1995 указывает чистую апертуру 1 888 пикселей 1 018 строками. 1018, кажется, более разумное значение: так как центр изображения расположен на полпути между двумя строками, чистая апертурная высота, которая является 0 модификациями 2, помещает верх и низ чистой апертуры на строках вместо между строками. Отраслевая практика решит. Вот значения:
|
Формат |
|
|
|---|---|---|
|
1920x1035 HDTV (SMPTE 240M-1995, SMPTE 260M-1992, 74,25 МГц (30 кадр/с) или 74.25/1.001 MHz (30/1.001 кадр/с)) согласно SMPTE 260M-1992 информативное приложение B |
113 |
118 |
|
1920x1035 HDTV (SMPTE 240M-1995, SMPTE 260M-1992, 74,25 МГц (30 кадр/с) или 74.25/1.001 MHz (30/1.001 кадр/с)) согласно RP SMPTE 187-1995 |
1018 |
1062 |
1920x1080 и 1280x720 HDTV является квадратным пикселем:
|
Формат |
|
|
|---|---|---|
|
1920x1080 HDTV (SMPTE 274M-1995, 148,5 МГц (60 кадров/секунда), 148.5/1.001 MHz (60/1.001 кадр/секунда), 74,25 МГц (30 кадров/секунда), 74.25/1.001 MHz (30/1.001 кадр/секунда)) |
1 |
1 |
|
1280x720 HDTV (SMPTE 296M-1997, 74,25 МГц (60 кадров/секунда), 74.25/1.001 MHz (60/1.001 кадр/секунда)) |
1 |
1 |
'Хлопок' расширение ImageDescription: чистая апертура
Это расширение всегда требуется при использовании типов сжатия в этом документе. Это определяет позицию изображения QuickTime чистая апертура, которую мы определили в Попиксельной пропорции, Чистой Апертуре и Пропорции изображения выше, относительно пикселей и строк изображения. Центр изображения определяется для падения на центр чистой апертуры. Это расширение позволяет ввод, вывод, обрабатывая и составляя композит видеоизображений с корректной регистрацией.
|
32-разрядное целое число |
ширина чистой апертуры, в пикселях |
|
32-разрядное целое число |
|
|
32-разрядное целое число |
высота чистой апертуры, в строках |
|
32-разрядное целое число |
|
|
32-разрядное целое число |
горизонтальное смещение чистого апертурного центра минус ( |
|
32-разрядное целое число |
|
|
32-разрядное целое число |
вертикальное смещение чистого апертурного центра минус ( |
|
32-разрядное целое число |
Эти параметры представлены как дробный N/D. Часть может или может не быть в сокращенных условиях. Мы обратимся к набору параметров fooN и еды как просто foo. Для horizOff и vertOff, D должен быть положительным, и N может быть положительным или отрицательным. Для cleanApertureWidth и cleanApertureHeight, и N и D должны быть положительными.
Каждая строка Вашего изображения QuickTime содержит пиксели 0 через width- 1, включительно. Рассмотрите строки своего изображения QuickTime в пространственном порядке (S от расширения 'fiel' ImageDescription выше) от 0 до height- 1, включительно.
Центр изображения Вашего изображения падает на:
|
pcX = |
|
pcY = |
Как правило, horizOff и vertOff нуль, таким образом, Ваше изображение QuickTime центрируется о центре изображения.
Крайний левый/самый правый пиксель и самая верхняя/самая нижняя строка чистого апертурного падения в:
|
pcX ± ( |
|
pcY ± ( |
Для изображений QuickTime, представляющих немасштабированное видео от некоторого стандарта видеоинтерфейса, необходимо установить horizOff к кратному числу horiz_align_pixels (который мы определили вместе с каждым типом сжатия), и необходимо установить cleanApertureWidth и cleanApertureHeight к чистой апертуре интерфейсного стандарта. Посмотрите Типичную ширину, высоту, и 'хлопните', Настройки ниже для чистой апертуры оценивает использованию. Например, если horiz_align_pixels 2, это гарантирует, что крайний левый Y´ выборка каждой строки Вашего изображения QuickTime (который всегда является Y ´0 выборок для 4:2:2 изображения, как объяснено в Пространственных отношениях Y´CbCr выше) отображает на расположение Y´ 0 выборок в видеосигнале.
Если Ваше изображение QuickTime представляет масштабируемое видео от некоторого стандарта видеоинтерфейса, чистые апертурные размерности которого являются caX рифом, и Вы применили масштабный коэффициент scaleX и scaleY (пиксели изображения QuickTime или строки на интерфейсные стандартные пиксели или строки), то заполните расширение 'хлопка' с:
|
|
|
|
Типичная ширина, высота и Настройки 'хлопка'
Как правило, приложение будет управлять изображениями QuickTime, ширина которых и высота соответствуют производственную апертуру определенного интерфейсного стандарта, чей 'хлопок' cleanApertureWidth и cleanApertureHeight соответствуйте чистую апертуру того стандарта, и чей 'хлопок' horizOff и vertOff нуль.
Таблица ниже воспроизводит расположение центра изображения, производственный размер апертуры и чистый апертурный размер для общих стандартов видеоинтерфейса.
Для 525-и форматов с 625 строками, размерности производства и чистых апертур зависят от luma частоты дискретизации. В расширении 'pasp' ImageDescription выше, мы объяснили, как luma частота дискретизации касается попиксельной пропорции и пропорции изображения. В том разделе мы также объяснили, почему чистые апертурные размерности ниже не соответствуют найденных в RP SMPTE 187-1995.
|
Видео с 525 строками |
Стандарты: |
SMPTE 170M-1994, SMPTE 125M-1995, SMPTE 267M-1995, SMPTE 259M-1997, SMPTE 293M-1996 |
|
Вертикальный центр: |
2:1 чередованный: на полпути между строкой 404 (поле 2) и 142 (поле 1). прогрессивный: на полпути между строкой 283 и 284. |
|
|
Горизонтальный центр: |
(963/1716) * (период строки) от 0H, или на полпути между luma демонстрационными 359 и 360 согласно ITU-R BT.601-4, или на полпути между luma демонстрационными 479 и 480 согласно SMPTE 267M-1995 (18 МГц).Примечание: SMPTE 267M-1995 (18 МГц), кажется, имеет ошибку в нем касающийся растрового центра и цифровой активной строки. |
|
|
Производственная апертура: |
12+3/11 выборка MHz: 640x486 13.5 Выборка MHz: 720x486 Выборка на 18 МГц: 960x486 |
|
|
Чистая апертура: |
12+3/11 выборка MHz: 640x480 13.5 Выборка MHz: (640* (11/10)) x480 Выборка на 18 МГц: (640* (11/10) * (4/3)) x480 |
|
|
Видео с 625 строками |
Стандарты: |
Rec. ITU-R BT. 470-4, Rec. ITU-R BT. 656-3 |
|
Вертикальный центр: |
на полпути между строкой 479 (поле 2) и 167 (поле 1) |
|
|
Горизонтальный центр: |
(983/1728) * (период строки) от 0H, или на полпути между luma демонстрационными 359 и 360 согласно ITU-R BT.601-4 |
|
|
Производственная апертура: |
Выборка на 14,75 МГц: 768x576 13.5 Выборка MHz: 720x576 |
|
|
Чистая апертура: |
Выборка на 14,75 МГц: 768x576 13.5 Выборка MHz: (768* (54/59)) x576 |
|
|
С 1125 строками (1920x1035) HDTV |
Стандарты: |
SMPTE 240M-1995, SMPTE 260M-1992 |
|
Вертикальный центр: |
на полпути между строкой 861 (поле 2) и 299 (поле 1) |
|
|
Горизонтальный центр: |
(2303/4400) * (период строки) от 0H, или на полпути между luma выборкой 1151 и 1152 от 0H согласно SMPTE 240M-1995, или на полпути между luma демонстрационными 959 и 960 из цифровой активной строки. |
|
|
Производственная апертура: |
1920x1035 |
|
|
Чистая апертура: |
1888x1018 или 1888x1017 (см. расширение 'pasp' ImageDescription для получения информации), |
|
|
С 1125 строками (1920x1080) HDTV |
Стандарты: |
SMPTE 274M-1995 |
|
Вертикальный центр: |
2:1 чередованный: на полпути между строкой 291 (поле 1) и 853 (поле 2). прогрессивный: на полпути между строкой 581 и 582. |
|
|
Горизонтальный центр: |
(2303/4400) * (период строки) от 0H, или на полпути между luma выборкой 1151 и 1152 от 0H согласно SMPTE 274M-1995, или на полпути между luma демонстрационными 959 и 960 из цифровой активной строки. |
|
|
Производственная апертура: |
1920x1080 |
|
|
Чистая апертура: |
1888x1062 |
|
|
С 750 строками (1280x720) HDTV |
Стандарты: |
SMPTE 296M-1997 |
|
Вертикальный центр: |
на полпути между строкой 385 и 386 |
|
|
Горизонтальный центр: |
(1799/3300) * (период строки) от 0H, или на полпути между luma демонстрационными 639 и 640 согласно SMPTE 296M-1997 |
|
|
Производственная апертура: |
1280x720 |
|
|
Чистая апертура: |
1248x702 |
Пример С 525 строками
Вот наиболее распространенные настройки для 525 линейных сигналов, выбранных в 13,5 МГц:
|
|
720 |
|
|
(640* (11/10)) |
|
|
0 |
|
|
486 |
|
|
480 |
|
|
0 |
Вот наиболее распространенные настройки для 525 линейных сигналов, выбранных в (12+3/11) MHz:
|
|
640 |
|
|
640 |
|
|
0 |
|
|
486 |
|
|
480 |
|
|
0 |
Эта схема показывает видео строки 525 линейных сигналов, чередованных в порядке строки изображения (пространственный порядок сверху донизу). Мы наложили изображение с 486 строками с настройками выше. Вертикальный центр изображения изображения QuickTime в (высота 1)/2 с тех пор vertOff 0. Вертикальный центр изображения стандарта видеоинтерфейса падает на полпути между строкой 404 (поле 2) и 142 (поле 1). Таким образом, верхние и нижние строки изображения QuickTime расположены
|
( |
строки изображения выше и ниже центра изображения:
Настройки ширины, высоты и расширения 'хлопка' тесно связаны с теми из расширения 'fiel' ImageDescription. Вот некоторые сценарии в качестве примера:
Скажите использование настроек, показанных выше. Самая верхняя строка Вашего изображения QuickTime с 486 строками передается на строке F2 (строка 283).
Скажите, что каждый кадр Вашего файла QuickTime содержит поле F1, временно сопровождаемое полем F2 (это вызывают преобладанием F1). Так как самая верхняя строка Вашего изображения QuickTime находится в F2, это передается во временно более позднем поле. Мы поэтому ожидали бы видеть случай 2a или 2b, как описано в 'fiel' расширении.
Скажите вместо этого, что каждый кадр Вашего файла QuickTime содержит поле F2, временно сопровождаемое полем F1 (преобладание F2). Так как самая верхняя строка Вашего изображения QuickTime находится в F2, это передается во временно более раннем поле. Мы поэтому ожидали бы видеть случай 1a или 1b в 'fiel' расширении.
Теперь Вы переключаетесь на различное изображение QuickTime с 486 строками, расширение 'хлопка' которого имеет a
vertOffиз 1. В отличие от схемы выше, самая верхняя строка Вашего изображения QuickTime передается на строке F1 (строка 21).Скажите, что каждый кадр Вашего файла QuickTime содержит поле F1, временно сопровождаемое полем F2 (преобладание F1). Так как самая верхняя строка Вашего изображения QuickTime находится в F1, это передается во временно более раннем поле. Мы поэтому ожидали бы видеть случай 1a или 1b, как описано в 'fiel' расширении.
Скажите вместо этого, что каждый кадр Вашего файла QuickTime содержит поле F2, временно сопровождаемое полем F1 (преобладание F2). Так как самая верхняя строка Вашего изображения QuickTime находится в F1, это передается во временно более позднем поле. Мы поэтому ожидали бы видеть случай 2a или 2b в 'fiel' расширении.
Пример С 625 строками
Вот наиболее распространенные настройки для 625 линейных сигналов, выбранных в 13,5 МГц:
|
|
720 |
|
|
(768* (54/59)) |
|
|
0 |
|
|
576 |
|
|
576 |
|
|
0 |
Вот наиболее распространенные настройки для 625 линейных сигналов, выбранных в 14,75 МГц:
|
|
768 |
|
|
768 |
|
|
0 |
|
|
576 |
|
|
576 |
|
|
0 |
Эта схема показывает 625 линейных сигналов, чередованных в порядке строки изображения. Мы наложили изображение с 576 строками с настройками выше. Вертикальный центр изображения изображения QuickTime в (высота 1)/2 с тех пор vertOff 0. Вертикальный центр изображения интерфейсного стандарта падает на полпути между строкой 479 (поле 2) и 167 (поле 1). Таким образом, верхние и нижние строки изображения QuickTime расположены
|
( |
строки изображения выше и ниже центра изображения:
Уровень производства соответствия
Уровень производства соответствия был представлен в Объеме выше. Когда приложение или устройство указывают, что может обработать формат с указанным:
тип сжатия, и
стандарт видеоинтерфейса (включая luma частоту дискретизации для 525/625)
на уровне производства соответствия, тогда:
ширина и высота соответствуют производственную апертуру, показанную для того стандарта видеоинтерфейса в Типичной ширине, высоте, и 'хлопают' Настройкам.
'хлопок'
cleanApertureWidthиcleanApertureHeightсоответствуйте чистую апертуру, показанную для того стандарта видеоинтерфейса в Типичной ширине, высоте, и 'хлопните' Настройкам.'хлопок'
horizOffиvertOff0.'pasp' hSpacing и vSpacing как описаны для стандарта видеоинтерфейса (и luma частота дискретизации) в расширении 'pasp' ImageDescription.
для 525-и 625 линейных сигналов, это соответствует точно Примеру С 525 строками и Примеру С 625 строками, данному в Типичной ширине, высоте и Настройках 'хлопка' выше.
основные устройства 'colr',
transferFunction, и матрица соответствует цветные параметры, показанные для того стандарта видеоинтерфейса в Выборке 'colr' Настройки.если интерфейсный стандарт является прогрессивным сканированием, то 'fiel'
полевой параметр равняется 1, и
подробность 0.
если стандарт чередования 2:1 чередован, то 'fiel'
полевой параметр равняется 2,
(подробность == 9) или (подробность == 14) (буфер содержит два поля, которые соткали вместе в пространственном порядке), и
значение определяется шириной, высотой, настройками 'хлопка' и полевым преобладанием видеоматериалов, как объяснено примером в Примере С 525 строками, данном в Типичной ширине, высоте, и 'хлопните' Настройкам выше.
Обратите внимание на то, что все параметры кроме полевого преобладания были ограничены выше к единственному значению. Поэтому все возможные перестановки параметров ImageDescription и параметров расширения ImageDescription были сокращены до 1 (прогрессивный сигнал сканирования) или 2 (2:1 чередованный сигнал с любым преобладанием) перестановки.
Приложение или устройство могут также хотеть указать качественные параметры такой как, может ли это ввод или вывод формат в полном тарифе, указанном стандартом видеоинтерфейса.
Приложение: назад совместимость
Вот то, что необходимо знать для поддержки существующий '2vuy' и 'yuv2' файлы в поле.
'2vuy' назад совместимость
Существуют некоторые существующие '2vuy' файлы, имеющие версию 0 или версию 1 и испытывающие недостаток в расширениях ImageDescription, описанных в этом документе. В целом не возможно получить все параметры. Если Вы хотите поддерживать такие файлы, вот лучшие предположения использованию:
если высота 486, файл был зарегистрирован от производственной апертуры цифрового источника с 525 строками с преобладанием F1 и точно параметрами, описанными на Уровне производства Соответствия. Так:
расширение 'pasp': попиксельная пропорция является 10/11.
расширение 'fiel': поля равняются 2, и подробность равняется 14.
'хлопок' и 'colr' расширение:
ширина: 720
высота: 486
'хлопок'
cleanApertureWidth: (640* (11/10))'хлопок'
cleanApertureHeight: 480'хлопок'
horizOff: 0'хлопок'
vertOff: 0'colr' colorParamType: 'nclc'
основные устройства 'colr': 6
'colr'
transferFunction: 1матрица 'colr': 6
если высота 576, файл был зарегистрирован от производственной апертуры цифрового источника с 625 строками с преобладанием F1 и точно параметрами, описанными на Уровне производства Соответствия. Так:
расширение 'pasp': попиксельная пропорция является 59/54.
расширение 'fiel': поля равняются 2, и подробность равняется 9.
'хлопок' и 'colr' расширение:
ширина: 720
высота: 576
'хлопок'
cleanApertureWidth: (768* (54/59))'хлопок'
cleanApertureHeight: 576'хлопок'
horizOff: 0'хлопок'
vertOff: 0'colr' colorParamType: 'nclc'
основные устройства 'colr': 5
'colr'
transferFunction: 1матрица 'colr': 6
'yuv2' назад совместимость
Существуют некоторые существующие 'yuv2' файлы, испытывающие недостаток в требуемых расширениях ImageDescription. В некоторых случаях эти файлы могут иметь ширину, которая не является кратным числом horiz_align_pixels (см. структуры ImageDescription и отобразите буферы).
В целом не возможно получить все параметры ImageDescription. Если Вы хотите поддерживать такие файлы, вот лучшие предположения использованию:
расширение 'pasp': попиксельная пропорция является 1/1.
расширение 'fiel': поля равняются 1, и подробность 0. Каждый буфер содержит одно из двух полей каждого кадра от стандартного видеосигнала определения, который таким образом похож на прогрессивный сигнал сканирования в половине вертикального разрешения видеосигнала.
'хлопок' и 'colr' расширение: если высота 240, файл был зарегистрирован из составного источника NTSC с этими параметрами:
ширина: 320
высота: 240
'хлопок'
cleanApertureWidth: 320'хлопок'
cleanApertureHeight: 240'хлопок'
horizOff: непредсказуемый (предполагают 0),'хлопок'
vertOff: непредсказуемый (предполагают 0),'colr' colorParamType: 'nclc'
основные устройства 'colr': 6
'colr'
transferFunction: 1матрица 'colr': 6
Если высота 288, файл был зарегистрирован из составного источника PAL с этими параметрами:
ширина: 384
высота: 288
'хлопок'
cleanApertureWidth: 384'хлопок'
cleanApertureHeight: 288'хлопок'
horizOff: непредсказуемый (предполагают 0),'хлопок'
vertOff: непредсказуемый (предполагают 0),'colr' colorParamType: 'nclc'
основные устройства 'colr': 5
'colr'
transferFunction: 1матрица 'colr': 6
'2vuy' предпочтительный формат для аппаратной и программной разработки, для которой выбор иначе произволен. Все новые '2vuy' и 'yuv2' файлы должны быть созданы с надлежащими расширениями и версией 2.
Приложение: проблемы, не решенные
Типы сжатия и расширения ImageDescription, описанные в этом документе, не адресуются:
Отдельные альфа-каналы, тегирующие вместе с данными Y´CbCr.
Параметризация альфа-поля, таким образом, можно сказать, является ли это нуль, не заботьтесь, или, если это используется, как это должно быть интерпретировано.
Используя эти 2 не заботятся о битах 10:10:10:2 упаковки, доступные как альфа.
Значение прямоугольников цифрового преобразователя видео QuickTime относительно видео стандартов.
Использование этих расширений за пределами несжатого Y´CbCr (например, DV, M-JPEG, все еще JPEG, координация JFIF). Многие расширения ImageDescription могут быть применены с очень небольшим дополнительным усилием к другим форматам; мы ценили бы любую обратную связь по возникающим проблемам.
Маркировка несжатого R´G´B´ пиксели. В частности R´G´B´ пиксели, полученные из с 525 строками, с 625 строками, или источники HD-видео, представляют различные основные устройства и не могут быть обменяны без надлежащей маркировки и преобразования.
Три, отличающиеся 10-разрядный, 4:2:2 форматы Y´CbCr, используемые:
Abekas A60 и Accom RTD
Accom WSD 2Xtreme
Сьерра Labs QuickFrame проекта
Маркируя пикселей Y´CbCr нестандартными основными устройствами, передайте функцию или матрицу, такой как
мог бы произойти с очень низкокачественными потребительскими камерами или другими устройствами.
мог бы произойти вследствие ошибок в обычно доступных частях, например, Зоран чипсеты JPEG.
История версии документа
| Дата | Примечания |
|---|---|
| 14.12.1999 | Новый документ, описывающий хранение несжатых видеоданных Y´CbCr в формате файла QuickTime. Первоначально опубликованный как Ледяная Отгрузка Плавучей льдины 19, «Буквы от Ледяной Плавучей льдины» технические документы. |