Формат движущегося фото 1.0

Motion Photos — это отдельные файлы, содержащие неподвижное фотографическое изображение и короткое видео, включающее аудиозапись. Этот тип носителя позволяет пользователю просматривать неподвижное изображение с высоким разрешением, а также видео и звук, чтобы передать настроение и атмосферу, в которой было сделано изображение.

Зависимости

Ниже приведены нормативные ссылки для этой спецификации:

• Ключевые слова для использования в RFC для обозначения уровней требований
• T.81 (09/92) Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном (JPEG)
• ISO/IEC 23008-12:2022 Высокоэффективное кодирование и доставка мультимедиа в гетерогенных средах. Часть 12. Формат файла изображения (HEIC)
• Формат файла изображения AV1 (AVIF) (AVIF)
• Формат изображения Ultra HDR v1.0 | Разработчики Android (Ultra HDR)
• ISO 16684-1:2011(E) Спецификация XMP, часть 1 (XMP)
• Спецификация Adobe XMP, часть 3. Хранение в файлах (XMP)
• ISO/IEC 14496-10:2022 Кодирование аудиовизуальных объектов. Часть 10. Расширенное кодирование видео (AVC).
• ISO/IEC 23008-2:2023 Высокоэффективное кодирование и доставка мультимедиа в гетерогенных средах. Часть 2. Высокоэффективное кодирование видео (HEVC)
• Спецификация битового потока и процесса декодирования AV1 (AV1)
• ISO/IEC 14496-1:2010 Кодирование аудиовизуальных объектов. Системы
• ISO/IEC 14496-12:2015 Формат медиафайлов ISO Box (ISOBMFF)
• ISO/IEC 14496-14:2020 Кодирование аудиовизуальных объектов. Часть 14. Формат файла MP4 (MP4).
• Формат файлов Apple QuickTime (MOV)

Введение

Использование слов «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» соответствует стандарту IETF, определенному в RFC2119 .

Формат движущегося фото

Файлы Motion Photo состоят из основного файла неподвижного изображения JPEG , HEIC или AVIF и добавленного к нему вторичного видеофайла. Основное изображение содержит метаданные XMP камеры, описывающие, как отображать файл неподвижного изображения и содержимое видеофайла, а также метаданные XMP контейнера, описывающие, как найти содержимое видеофайла.

Файл изображения может иметь карту усиления, как в случае с файлами Ultra HDR JPEG .

Шаблон имени файла

Авторам следует использовать имя файла, соответствующее следующему регулярному выражению:

^([^\\s\\/\\\\][^\\/\\\\]*MP)\\.(JPG|jpg|JPEG|jpeg|HEIC|heic|AVIF|avif)

Читатели могут игнорировать метаданные XMP, добавленный видеофайл или содержимое видео, если не соблюдается шаблон.

Кодирование медиаданных

Первичное изображение содержит каталог метаданных XMP элемента контейнера, определяющий порядок и свойства последующего медиафайла в файловом контейнере. Каждому файлу в контейнере соответствует соответствующий медиа-элемент в каталоге. Элемент мультимедиа описывает расположение в файловом контейнере и основные свойства каждого объединенного файла.

XMP-атрибуты

Два набора метаданных XMP используются для определения дополнительной семантической информации для формата Motion Photo. Метаданные могут появляться в любом порядке.

Метаданные камеры

Метаданные камеры кодируют информацию о том, как представить основные части изображения и видео движущегося фото.

• URI пространства имен: http://ns.google.com/photos/1.0/camera/
• Префикс пространства имен по умолчанию — Camera

В метаданных XMP файла неподвижного изображения могут присутствовать следующие атрибуты:

Поведение презентации

Если Camera:MotionPhotoPresentationTimestampUs отсутствует в пакете XMP, читатели должны использовать временную метку презентации, непосредственно предшествующую временной метке, ближайшей к середине видеодорожки, то есть длительность видеодорожки, разделенную на 2.

Если Camera:MotionPhotoPresentationTimestampUs присутствует в пакете XMP, а «application presentationTimestampUs "application/motionphoto-image-meta" присутствует в видео, то же значение должно появиться в поле primaryImageFrameScoreDescr этой дорожки. Если Camera:MotionPhotoPresentationTimestampUs отсутствует в пакете XMP и присутствует дорожка метаданных, то значение дорожки метаданных должно быть -1.

Элемент контейнера

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

• URI пространства имен: http://ns.google.com/photos/1.0/container/
• Префикс пространства имен по умолчанию — Container

Каталог может содержать только один элемент основного изображения, и он должен быть первым элементом в каталоге.

Элемент элемента

Элементы медиа-элемента описывают, как каждый элемент должен использоваться приложением.

• URI пространства имен: http://ns.google.com/photos/1.0/container/item/
• Префикс пространства имен по умолчанию — Item

Первым медиа-элементом должно быть основное изображение. Он должен содержать атрибут Mime , определяющий один из типов MIME изображений, перечисленных в разделе «Значения типа MIME элемента». Длина основного элемента может быть определена путем анализа основного изображения на основе его типа MIME, начиная с начала файлового контейнера.

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

Каждый элемент мультимедиа должен содержать атрибут Mime . Вторичные элементы мультимедиа также должны содержать атрибуты длины.

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

Расположение ресурсов элемента мультимедиа в контейнере определяется путем суммирования значений Length предшествующих ресурсов вторичного элемента с длиной кодировки основного изображения плюс Padding , если оно указано.

Элемент: Значения типов MIME

Атрибут Item:Mime определяет тип MIME каждого элемента мультимедиа.

Пункт:Семантические значения

Атрибут Item:Semantic определяет специфическое для приложения значение каждого элемента мультимедиа в каталоге контейнера.

Движущиеся фотографии с основным изображением Ultra HDR

В соответствии с правилами семантического значения элемента, определенными в этой спецификации и спецификации изображения Ultra HDR , движущиеся фотографии с основным изображением Ultra HDR также должны включать элемент мультимедиа с семантикой элемента "GainMap" . Кроме того, авторы, кодирующие движущиеся фотографии, должны поместить элемент элемента усиления перед элементом элемента видео.

Поведение, специфичное для образа ISOBMFF

Движущиеся фотографии с изображениями на основе ISOBMFF (например, изображения HEIC и AVIF) должны иметь такую ​​структуру, чтобы часть изображения файла заканчивалась полем верхнего уровня «Видеоданные Motion Photo», описываемым с использованием семантики языка синтаксического описания. определено в ISO/IEC 14496-1:2010(E), пункт 8:

// Box as defined in ISO/IEC 14496-12:2015: 4.2
aligned(8) class MotionPhotoVideoData extends Box('mpvd') {
  bit(8) data[];
}

где поле «данные» содержит все байты видео. Специальное значение «0» не допускается для размера поля данных Motion Photo Video. (Определение размера класса, расширяющего Box, см. в ISO/IEC 14496-12:2015:4.2. )

XMP изображения ISOBMFF также должен определить значение атрибута Padding основного медиа-элемента, равное размеру в байтах заголовка блока данных Motion Photo Video, то есть заголовкам размера и имени.

На рисунке 1 показана структура этого блока для примера движущейся фотографии на основе HEIC:

Рис. 1. Иллюстрация блоков верхнего уровня образца изображения HEIC в одном файле движущейся фотографии HEIC. Обратите внимание, что порядок полей в основном приведен только для иллюстрации (см. соответствующие стандарты о том, как создавать HEIF или видеофайлы); тем не менее, поле «mpvd» должно идти после всех полей файла изображения HEIC.

Содержимое видеоконтейнера

Файл видеоконтейнера, добавляемый к основному изображению, должен включать хотя бы одну основную видеодорожку. Эта дорожка является обязательной и содержит видео, закодированное в формате AVC , HEVC или AV1 . Разрешение основного видеокадра не определено. Цветовое пространство видео, функция передачи и разрядность могут различаться. Например, видео SDR может иметь 8-битную глубину цвета, цветовое пространство BT.709 и функцию передачи sRGB. Или HDR-видео может иметь 10-битную глубину цвета, цветовое пространство BT.2100 и функцию передачи HLG или PQ, а также метаданные HDR и дорожки метаданных.

Файл видеоконтейнера может содержать одну дополнительную дорожку вторичного видео с более высоким разрешением. Читателям следует использовать его содержимое для отображения замен основного неподвижного изображения, закодированного в изображении JPEG или HEIC. Эта дорожка может содержать видео с более низкой частотой кадров, закодированное в AVC, HEVC или AV1. Разрешение вторичного видеокадра не определено.

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

Файл видеоконтейнера может содержать одну дополнительную 16-битную моно- или стереозвуковую дорожку с частотой 44 кГц, 48 кГц или 96 кГц, закодированную в формате AAC. Читатели должны показывать эту аудиодорожку при отображении основной видеодорожки.

Вторичная видеодорожка, если она присутствует, всегда должна идти после основной видеодорожки. В отношении других треков других ограничений по порядку нет. Индекс основной видеодорожки должен быть ниже индекса любой вторичной видеодорожки. То есть, если первичная видеодорожка имеет номер дорожки 2, то любая вторичная видеодорожка должна иметь номер дорожки больше или равный 3.

Отслеживание метаданных видео с оценкой машинного интеллекта

Авторы могут дополнительно добавить дорожку метаданных в файл видеоконтейнера с типом «мета». Дорожка метаданных должна содержать ровно один образец, содержащий поток байтов в формате, описанном в разделе «Синтаксис» .

Если дорожка метаданных присутствует, запись таблицы образцов описания для этой дорожки (т. е. поле «stsd», расположенное по адресу «mdia.minf.stbl.stsd» относительно поля «trak») должна содержать один атом, указывающий образец записи текстовых метаданных (т. е. поле «метт»). Поле «mett» должно иметь строку типа MIME, равную «application/motionphoto-image-meta».

Синтаксис

Если эта дорожка метаданных определена, ее содержимое должно состоять из потока байтов, соответствующего спецификации MotionPhotoMetadataDescriptor , описанной здесь с использованием семантики языка синтаксического описания, определенного в пункте 8 ISO/IEC 14496-1:2010(E).

// BaseDescriptor as defined in ISO/IEC 14496-1:2010(E): 7.2.2.2
abstract aligned(8) expandable((1<<28) - 1) class BaseDescriptor
    : bit(8) tag=0 {
  // Empty. To be filled by classes extending this class.
}

// Score data for a frame.
class MotionPhotoFrameScoreDescriptor extends BaseDescriptor
    : bit(8) tag=MotionPhotoFrameScoreDescrTag {
  // The frame's score in the range [0, 1].
  float(32) score;

  // The frame's presentation timestamp in microseconds.
  int(64) presentationTimestampUs;
}

// Score data for a track.
class MotionPhotoTrackScoreDescriptor extends BaseDescriptor
    : bit(8) tag=MotionPhotoTrackScoreDescrTag {
  // The number of scored frames in the track.
  unsigned int(32) numScoredFrames;

  // The track's frames' score data. They must be in ascending order with
  // respect to the presentation timestamp.
  MotionPhotoFrameScoreDescriptor trackFrameScoreDescr[numScoredHighResFrames];
}

// Score data for a motion photo.
class MotionPhotoScoreDescriptor extends BaseDescriptor
    : bit(8) tag=MotionPhotoScoreDescrTag {

  // Machine-intelligence model version used to calculate the scores. Writers
  // using a scoring model should set this field to 1 or greater. Writers not
  // using any scoring model should set this field to 0.
  unsigned int(32) modelVersion;

  // The primary image's frame score data.
  MotionPhotoFrameScoreDescriptor primaryImageFrameScoreDescr;

  // The high-resolution motion photo frames' score data.
  MotionPhotoTrackScoreDescriptor highResTrackScoreDescr;
}

// Flag data for a track.
class MotionPhotoTrackFlagsDescriptor extends BaseDescriptor
    : bit(8) tag=MotionPhotoTrackFlagDescrTag {
  // Set to true to indicate the video frames have been stabilized and don't
  // require readers of the track to apply any further stabilization.
  bit(1) isStabilized;
}

// Flags for a motion photo.
class MotionPhotoFlagsDescriptor extends BaseDescriptor
        : bit(8) tag=MotionPhotoFlagDescrTag {
  // The low-resolution motion photo track's flag data.
  MotionPhotoTrackFlagDescriptor lowResTrackFlagsDescr;

  // The high-resolution motion photo track's flag data.
  MotionPhotoTrackFlagDescriptor highResTrackFlagsDescr;
}

// Container for motion photo metadata, like stabilization indicators and
// quality scoring.
class MotionPhotoMetadataDescriptor extends BaseDescriptor
    : bit(8) tag=MotionPhotoMetadataDescrTag {
  // Scoring data for the still and high-res frames.
  MotionPhotoScoreDescriptor motionPhotoScoreDescr;

  // Flags for the low-res and high-res frames.
  MotionPhotoFlagDescriptor motionPhotoFlagDescr;
}

// Class tags for MotionPhotoData using the "User Private" tag space 0xC0-0xFE
// for descriptors defined in ISO/IEC 14496-1:2010(E): 7.2.2.1, Table 1.
// 0xC0 MotionPhotoMetadataDescrTag
// 0xC1 MotionPhotoScoreDescrTag
// 0xC2 MotionPhotoTrackScoreDescrTag
// 0xC3 MotionPhotoFrameScoreDescrTag
// 0xC4 MotionPhotoFlagsDescrTag
// 0xC5 MotionPhotoTrackFlagDescrTag