1 ПОДГОТОВЛЕН Автономной некоммерческой организацией "Научно-технический центр сертификации электрооборудования" "ИСЭП" (АНО "НТЦСЭ "ИСЭП") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4, включая изменение 1 (2014-02)

2 ВНЕСЕН Техническим комитетом по стандартам ТК 452 "Безопасность аудио-, видео-, электронной аппаратуры, оборудования информационных технологий и телекоммуникационного оборудования. Устройства отображения информации"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 1 ноября 2016 г. N 1549-ст

4 Настоящий стандарт идентичен международному стандарту МЭК 61883-8:2014 "Аудио-/видеоаппаратура бытового назначения. Цифровой интерфейс. Часть 8. Передача цифровых видеоданных согласно рекомендации ITU-R BT.601" (IEC 61883-8:2014 "Consumer audio/video equipment - Digital interface - Part 8: Transmission of ITU-R BT.601 style digital video data", IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные и межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

1) Международная электротехническая комиссия (МЭК) является международной организацией по стандартизации, объединяющей все национальные электротехнические комитеты (национальные комитеты МЭК). Задача МЭК - продвижение международного сотрудничества во всех вопросах, касающихся стандартизации в области электротехники и электроники. Результатом этой работы и в дополнение к другой деятельности МЭК является издание международных стандартов, технических требований, технических отчетов, публично доступных технических требований (PAS) и руководств (в дальнейшем именуемых "публикации МЭК"). Их подготовка поручена Техническим комитетам. Любой национальный комитет МЭК, заинтересованный в объекте рассмотрения, с которым имеет дело, может участвовать в предварительной работе. Международные, правительственные и неправительственные организации, сотрудничающие с МЭК, также принимают участие в этой подготовке. МЭК близко сотрудничает с Международной организацией по стандартизации (ИСО) в соответствии с условиями, определенными соглашением между этими двумя организациями.

2) В формальных решениях или соглашениях МЭК выражено положительное решение технических вопросов, практически консенсус на международном уровне в соответствующих областях, так как в составе каждого Технического комитета есть представители от национальных комитетов МЭК.

3) Публикации МЭК принимаются национальными комитетами МЭК в качестве рекомендаций. Приложены максимальные усилия для того, чтобы гарантировать правильность технического содержания публикаций МЭК, однако МЭК не может отвечать за порядок их использования или за неверное толкование конечным пользователем.

4) В целях содействия международной гармонизации национальные комитеты МЭК обязуются применять публикации МЭК в их национальных и региональных публикациях с максимальной степенью приближения к исходным. Любые расхождения между любой публикацией МЭК и соответствующей национальной или региональной публикацией должно быть четко обозначено в последней.

5) МЭК не устанавливает процедуры маркировки знаком одобрения и не берет на себя ответственность за любое оборудование, о котором заявляют, что оно соответствует публикации МЭК.

6) Все пользователи должны быть уверены, что они используют последнее издание этой публикации.

7) МЭК или его директора, служащие или агенты, включая отдельных экспертов и членов его Технических комитетов и национальных комитетов МЭК, не несут никакой ответственности за причиненные телесные повреждения, материальный ущерб или другое повреждение любой природы вообще, как прямое так и косвенное, или за затраты (включая юридические сборы) и расходы, проистекающие из использования публикации МЭК, или ее разделов, или любой другой публикации МЭК.

8) Следует обратить внимание на нормативные ссылки, указанные в настоящем стандарте. Использование ссылочных международных стандартов является обязательным для правильного применения настоящего стандарта.

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

Настоящая консолидированная версия МЭК 61883-8 имеет индекс 1.1. Она включает первое издание (2008-11) [документы 100/1446/FDIS и 100/1476/RVD] и изменение 1 к нему (2014-02) [документы 100/2051/CDV и 100/2106/RVC]. Техническое содержание идентично базовому изданию и изменению к нему.

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

Настоящее издание подготовлено для удобства пользователя.

МЭК 61883-8 подготовлен техническим сектором 4: "Интерфейсы и протоколы цифровых систем" технического комитета 100 МЭК: "Аудио-, видео- и мультимедийные системы и оборудование".

Настоящий стандарт разработан в соответствии с Директивами ИСО/МЭК, частью 2.

Перечень всех частей серии стандартов МЭК 61883 под общим наименованием "Аудио-/видеоаппаратура бытового назначения. Цифровой интерфейс" можно найти на сайте МЭК.

Комитет принял решение, что содержание настоящего стандарта останется без изменений до конечной даты сохранения, указанной на сайте МЭК с адресом http://webstore.iec.ch, в данных, касающихся конкретного стандарта. На это время стандарт будет:

- подтвержден заново;

- аннулирован;

- заменен пересмотренным изданием или

- изменен.

Настоящий стандарт устанавливает протокол для транспортировки/передачи несжатых или сжатых видеоданных в формате 4:2:2 рекомендаций ITU-R BT.601 (МСЭ-Р BT.601) (включая совместимые расширения для данного формата при более высоких или более низких разрешениях других обычно используемых разрешений видеосигнала) по высокопроизводительной последовательной шине, как установлено стандартом IEEE 1394-1995 с изменениями IEEE 1394a-2000 и IEEE 1394b-2002 (изменения к IEEE 1394). Форматы данных для формирования пакетов видеоданных (инкапсуляции) совместимы с форматами, установленными МЭК 61883-1. Сопутствующие аудиоданные, если имеются, должны быть отформатированы согласно МЭК 61883-6.

Существует много обычно используемых форматов видеоданных, которые не поддерживаются согласно МЭК 61883, например, MPEG-4, Windows Media Format (WMF) и формат, используемый в автоматической навигации. Поддержка всех или большинства таких форматов в устройствах воспроизведения/визуализации потребовала бы введения множества видеокодеков. Эта нежелательная проблема, которой можно избежать, если источник конвертировать к формату 4:2:2 ITU-R BT.601 (МСЭ-Р BT.601) и при необходимости сжать данные с помощью кодека, поддерживаемого всеми устройствами-адресатами. Дополнительное преимущество состоит в том, что информацию, отображаемую на экране дисплея (OSD), можно смешивать с видеоданными до передачи в устройство воспроизведения/визуализации.

Поскольку формат 4:2:2 ITU-R BT.601 широко используется внутри современного аудио-/видеооборудования, настоящий стандарт разрешает прямую интеграцию IEEE 1394 в эти устройства и делает возможным продажи, которые включают условия использования передачи единичных видео источников на один или более дисплеев, таких как:

- бытовые электронный STB или DVD, преобразующие видеосигнал для просмотра посредством нескольких дисплеев в доме;

- автомобильная навигация и развлечение;

- аэронавигационное развлечение в полете.

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

- 1394 TA управляло списком кодеков сжатия управляла 1394 TA;

- ссылалась, как минимум, на один кодек сжатия видеосигнала.

Для применения настоящего стандарта необходимы следующие ссылочные документы. Для датированных ссылок применяют только указанное издание ссылочного документа, для недатированных ссылок применяют последнее издание ссылочного документа (включая любые изменения).

IEC 61883 (all parts) Consumer audio/video equipment - Digital interface [(все части) Бытовая аудио-/видеоаппаратура. Цифровой интерфейс]

IEC 61883-1 Consumer audio/video equipment - Digital interface - Part 1: General (Бытовая аудио-/видеоаппаратура. Цифровой интерфейс. Часть 1. Общие положения)

ISO/IEC 11172-2:1993 Information technology - Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s - Part 2: Video (Информационные технологии. Кодирование движущихся изображений и сопутствующего звукового сопровождения для цифровой запоминающей среды приблизительно со скоростью до 1,5 Мбит/с включительно. Часть 2. Видеосигналы)

IEEE Std. 1394-1995 with IEEE Std. 1394a-2000 Amendment 1 and IEEE Std. 1394b-2002 Amendment 2, Standard for a high performance serial bus (Стандарт для высокопроизводительной последовательной шины с изменением 1 IEEE 1394a-2000 и изменением 2 IEEE 1394b-2002)

IEEE Std. 1394a-2000 Standard for a high performance serial bus. Amendment 1 (Стандарт для высокопроизводительной последовательной шины. Изменение 1)

IEEE Std. 1394b-2002 Standard for a high performance serial bus. Amendment 2 (Стандарт для высокопроизводительной последовательной шины. Изменение 2)

1394 Trade Association 2004006, AV/C Digital interface command set general specification version 4.2 (Основная спецификация набора команд для цифрового интерфейса управления аудио/видеосигналами (AV/C). Версия 4.2)

1394 Trade Association 2003017 IIDC 1394-based digital camera specification version 1.31 (Спецификация цифровой камеры на основе IIDC 1394. Версия 1.31)

EIA/CEA-861-B 2002 A DTV profile for uncompressed high speed digital interfaces (Профиль цифрового ТВ сигнала для высокоскоростных цифровых интерфейсов без сжатия сигналов)

IEEE Std.1394.1-2004 Standard for high performance serial bus bridges (Стандарт для мостов высокопроизводительной последовательной шины)

ITU-R BT 601-5 1995 Studio encoding parameters of digital television for standard 4:3 and widescreen 16:9 aspect ratios (Параметры студийного кодирования цифрового телевидения для стандартного форматного соотношения 4:3 и широкоэкранного соотношения 16:9)

ITU-R BT 656-4 1998 Interfaces for digital component video signals in 525-line and 625-line television systems operating at the 4:2:2 level of recommendation ITU-R BT.601 [Интерфейсы для цифровых составляющих видеосигналов в телевизионных системах с 525 и 625 строками, работающих на уровне 4:2:2 согласно ITU-R BT.601 (BT.601 МСЭ-Р)]

ITU-R BT.709-4 2000 Parameter values for the HDTV standards for production and international program exchange (Значения параметров для стандартов телевидения высокой четкости (HDTV) для производства и международного обмена программами)

ITU-R BT.1358 1998 Studio parameters of 625 and 525 line progressive scan television systems (Студийные параметры 525- и 625-строчных телевизионных систем с построчной (прогрессивной) разверткой)

ITU-T H.263 1998 Video coding for low bit rate communication (Рекомендации ITU-T H.263 (МСЭ-Т H.263) 1998, Кодирование видеосигнала для связи с низкой битовой скоростью)

SMPTE 267M-1995 Television - Bit-parallel digital interface - Component video signal 4:2:2 16 x 9 aspect ratio (Телевидение. Цифровой параллельный интерфейс. Составляющий видеосигнал 4:2:2 при форматном соотношении 16 x 9)

SMPTE 274M-1998 Television - 1920 x 1080 scanning and analog and parallel digital interfaces for multiple picture rates (Телевидение. Сканирование 1920 x 1080 и аналоговые и параллельные цифровые интерфейсы для кратных частот кадров)

SMPTE 293M-1996 Television - 720 x 483 active line at 59,94 Hz progressive scan production - Digital representation (Телевидение. Активная строка 720 x 483 при выполнении построчной развертки с частотой 59,94 Гц. Цифровое представление)

SMPTE 296M-2001 Television - 1280 x 720 progressive image sample structure - Analog and digital representation and analog interface (Телевидение. Структура выборки прогрессивного изображения 1280 x 720. Аналоговое и цифровое представление и аналоговый интерфейс)

VESA, Monitor timing specification, VESA and industry standards and guidelines for computer display monitor timing, version 1.0, revision 0.8. (Спецификации синхронизации с помощью монитора. VESA и промышленные стандарты и руководства для синхронизации дисплея компьютера с помощью монитора)

В настоящем стандарте используют следующие сокращения, установленные МЭК 61883-1:

- AV/C - управление аудио- видеосигналом;

- BCD - двоично-десятичное число/код;

- BT.601 - рекомендации ITU-R BT.601-5 (МСЭ-Р BT.601-5) 1995;

- CIP - общий изохронный пакет;

- CSR - регистр состояний и команд;

- DAC - цифро-аналоговый преобразователь;

- DCT - дискретное косинусное преобразование;

- DV - цифровое видео/цифровой видеосигнал;

- ND - нет данных;

- OSD - визуализация на дисплее/экранное меню;

- OUI - уникальный идентификатор организации-поставщика;

- r - зарезервировано;

- MPEG - стандарт сжатия и кодирования (Экспертная группа по кинематографии);

- SIM - информация потока и метаданные;

- VDSP - исходный пакет данных видеосигнала/видеоданных;

- WMF - мультимедийный формат Windows.

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

Десятичные числа представлены арабскими цифрами без подстрочных индексов или их обозначений на английском языке. Шестнадцатеричные числа представлены цифрами от 0 до 9 и буквами A - F с нижним индексом 16. Если для определения основания системы счисления подстрочный индекс не нужен, его можно опустить. Для разборчивости шестнадцатеричные числа поделены на группы из четырех цифр с разделительным расстоянием между ними.

В качестве примера приведены два одинаковых, по-разному представленных, значения: 42 и 2A₁₆.

3.2.2 Упорядочение бит, байт и квадлет

В настоящем стандарте использованы функции последовательной шины IEEE 1394, и поэтому применены правила упорядочения в представлении структур данных, принятые для этой шины. Для содействия взаимодействию с шинами памяти, у которых могут быть разные правила упорядочения, в настоящем стандарте определен порядок и значимость бит в составе байт, байт в составе квадлет (32-битных слов) и квадлет в составе октлет (64-битных слов) с точки зрения их относительной позиции, а не физически адресуемой позиции.

В рамках байта наиболее значимый бит (msb) - это бит, который передается по последовательной шине первым, а наименее значимый бит (lsb) - это бит, передаваемый последним, как показано ниже. Значимость внутренних бит равномерно уменьшается от msb к lsb.

В рамках квадлета наиболее значимым байтом будет байт, передаваемый по последовательной шине первым, а наименее значимым - байт, который передается последним, как показано ниже.

В рамках октлета, который часто используют для заполнения адресов последовательной 64-битовой шины, наиболее значимым является квадлет, который передается по последовательной шине первым, а наименее значимым - квадлет, передаваемый по шине последним, как показано на рисунке ниже.

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

При существующих в настоящее время стандартах на сжатие данных DV (цифрового видео) и MPEG2 для IEEE 1394 транспортировки имеются трудности на уровне системы в практической пользовательской сети аудио- и видеосигналов. Оба стандарта предлагают чрезмерное сжатие для простой транспортировки по широкомасштабной широкополосной информационной сети и соответственно имеют сложности в кодировании и декодировании сигналов. Каждый из них хорош для определенной цели, но для простой транспортировки видеосигналов излишне дорог. Стандартное видеооборудование стыкуется с кабелями для аналоговых сигналов, передающими ряд форматов сигналов, и поэтому цифровые интерфейсы должны иметь низкую стоимость и иметь универсальную функцию соединения. Таким образом, аналоговый выход с любого DVD плеера будет подключаться к любому ТВ приемнику, и изготовители оборудования видят в этом практическую целесообразность. Цифровые интерфейсы могли бы обеспечить много дополнительных возможностей, но обеспечение каждого входа функцией декодирования DV и MPEG2 во всех существующих стандартах и решениях является необоснованно дорогим. Общей практикой является изменение на стыке внутри вещательного оборудования по BT.601-5/BT.656-4 МСЭ-Р и обеспечение универсального интерфейсного стандарта для транспортировки цифровых видеосигналов. Система кодирования по ITU-R BT.601-5 пересылает данные формата YUV через 8-битовый интерфейс между интегральными схемами, например, MPEG декодером и цифро-аналоговым преобразователем (DAC). Если декодер и DAC разделены шиной IEEE 1394 и находятся в отдельных корпусах, их стоимость будет меньше при условии, что устройство-источник и устройство-приемник (сток) не будут зависеть от механизма кодирования видеосигнала.

В настоящем стандарте представлен метод передачи видеосигналов формата YUV по шине IEEE 1394 на основании форматов, установленных в ITU-R BT.601-5. Необходимо ознакомиться со спецификациями ITU-R BT.601-5, ITU-R BT.656-4 и МЭК 61883 для уточнения следующих технических деталей.

Также существует возможность передачи данных в форматах YUV 4:4:4 и 24-битовой RGB (система цветопередачи "красный - зеленый - синий"). Это позволяет передавать видеосигнал без необходимости субдискретизации цветового пространства.

Правомерно передавать все видеорежимы как несжатые данные, при условии доступности полосы пропускания шины IEEE 1394. На практике некоторые видеорежимы в несжатом состоянии передать невозможно.

Данная модель также учитывает будущие разработки кодеков видеосигналов. Так как транспортировка видеоданных не зависит от кодирования исходного источника при введении новых кодеков, например MPEG-4, механизм транспортировки, представленный в настоящем стандарте, менять не придется.

Для обеспечения транспортировки видеосигналов высокой четкости при скоростях шины менее S1600 или для обеспечения транспортировки потоков нескольких видеосигналов важно, чтобы видеопоток был сжат. Такое сжатие не должно быть больше 10:1 и должно иметь минимальное влияние на отображаемое изображение. Так как для транспортировки некоторых режимов видеосигналов требуется сжатие, необходимо обращаться, по крайней мере, к одному кодеку сжатия, установленному настоящим стандартом. В таблице 2 приведен соответствующий кодек со сжатием видеосигнала. Наличие такого кодека в устройстве-источнике или устройстве-приемнике не требуется. В будущем могут быть добавлены другие кодеки со сжатием видеосигнала.

Квадлет заголовка изохронного пакета IEEE 1394 (tcode A₁₆) представлен на рисунке 4.

Поле флага должно быть установлено на 1₁₆, что указывает на то, что пакет имеет заголовок общего изохронного пакета (CIP), как определено в МЭК 61883-1. Контенты заголовка CIP описаны в 4.4.

Определение оставшихся полей не входит в область применения настоящего стандарта.

Определение заголовка CIP показано на рисунке 5

- SID - идентификатор исходного узла (узла передатчика);

- DBS - размер блока данных в квадлетах;

- FN - номер фракции

- QPC - количество заполнений квадлетами;

- SPH - заголовок исходного пакета;

- r - зарезервировано;

- DBC - счетчик непрерывности блоков данных;

- FMT - код формата;

- FDF - поле, зависящее от формата;

- SYT - отметка времени синхронизации кадров видеосигналов.

Значение полей заголовка CIP:

- SID означает идентификатор (ID) исходного узла (узла источника). SID зависит от конфигурации шины;

- значение DBS зависит от режима передаваемого видеосигнала и используемого цветового пространства. Значение DBS зависит от режима сжатия цветового пространства и видеорежима. Значение DBS с режимом сжатия 0₁₆ можно рассчитать путем деления на четыре размера исходного пакета, приведенного в таблице 1. Другие режимы сжатия устанавливают в документации, предоставляемой поставщиком кодека;

- FN всегда должен иметь значение 0₁₆. В исходном пакете должен быть только один блок данных;

- QPC всегда должен иметь значение 0₁₆. Заполнения не должно быть;

- SPH должен быть 0₁₆. Заголовок исходного пакета не представлен;

- значение DBC всегда должно увеличиваться на количество исходных пакетов, находящихся в изохронном пакете, так как FN = 0₁₆. Данное поле обозначает значение счетчика первого блока данных в текущем изохронном пакете;

- значение FMT должно быть 000001₂. Такое значение указывает на то, что формат исходного пакета соответствует настоящему стандарту, а также что в заголовке CIP присутствует поле SYT;

- поле FDF кодируют, как показано на рисунке 6.

- поле SYT кодируют, как указано в МЭК 61883-1.

Поле ND используют для обозначения того, будет ли действительной полезная нагрузка данных изохронного пакета после заголовка CIP. Если ND установлен на 1₂ - это означает, что данные не действительны и их следует игнорировать; такую установку используют только при блокировке режима передачи (см. 4.7.1.3). Поле DBC заголовка CIP пакета, в котором ND установлен на 1₂, должно быть значением счетчика следующего действительного блока данных. Передача изохронного пакета с такой битовой установкой не вызовет увеличения значения DBC. Если ND установлен на 0₂ - это означает, что полезная нагрузка данных изохронного пакета после заголовка CIP действительна. ND должен быть установлен на 0₂ для всех изохронных пакетов при отсутствии режима блокировки передачи (см. 4.7.1.2).

Поток, соответствующий настоящему стандарту, управляется посредством трех ключевых параметров:

- видеорежим, см. таблицу 1. Дополнительная информация по каждому видеорежиму приведена в приложении B;

- режим сжатия, см. таблицу 2;

- цветовое пространство, см. таблицу 3.

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

В настоящем стандарте определены характеристики пакетизации и синхронизации для передачи данных в режиме сжатия 0₁₆.

Характеристики пакетизации и синхронизации для передачи данных в режиме сжатия 1₁₆ и 2₁₆ определены в соответствующей спецификации, указанной в таблице 2.

Использование видеорежима FF₁₆ не входит в область применения настоящего стандарта. Тем не менее, ожидается, что его использование будет определяться путем согласования до передачи.

Поле режима сжатия кодируют согласно таблице 2. Использование режима сжатия FF₁₆ не входит в область применения настоящего стандарта. Тем не менее, ожидается, что его использование будет определяться путем согласования до передачи.

--------------------------------

<1> Цифры в квадратных скобках означают номер первоисточника в разделе "Библиография".

Поле цветового пространства кодируют согласно таблице 3. Использование цветового пространства FF₁₆ не входит в область применения настоящего стандарта. Тем не менее, ожидается, что его использование будет определяться путем согласования до передачи.

В потоке, который соответствует настоящему стандарту, каждый изохронный пакет IEEE 1394 включает заголовок CIP, за которым следует ноль или большее количество пакетов. Общий формат исходного пакета при всех режимах сжатия и для всех типов исходных пакетов представлен на рисунке 7. Он состоит из единичного квадлета специальной информации о типе, за которым следуют данные. Размер каждого исходного пакета зависит от режима сжатия, видеорежима и режима цветового пространства. Разрешенные режимы видео, сжатия и цветового пространства приведены в таблицах 1, 2 и 3 соответственно. В таблице 1 указан размер исходного пакета для каждого видеорежима и режима цветового пространства при режиме сжатия 0. Этот размер представляет собой общее количество байт на исходный пакет, т.е. специальную информацию о типе и данные исходного пакета. Все исходные пакеты заданного потока имеют такой размер.

Поле type обозначает тип данных, входящих в исходный пакет. Его кодируют согласно таблице 4.

Поле ver указывает версию исходного пакета. Его значение определяется в специальных разделах, приведенных ниже.

Содержимое поля type specific information (тип специальной информации) зависит от поля type. Его кодируют, как установлено в специальных разделах 4.6.2, 4.6.3 и 4.6.4.

Содержимое поля source packet data (данные исходного пакета) зависит от поля type. Его кодируют, как установлено в специальных разделах 4.6.2, 4.6.3 и 4.6.4.

4.6.2 Исходный пакет типа 0₁₆ - Исходный пакет видеоданных

4.6.2.1 Исходный пакет видеоданных

На рисунке 8 приведено определение и расположение полей в исходном пакете видеоданных.

Поле type должно быть установлено на 0₁₆ для обозначения исходного пакета видеоданных.

Поле ver должно быть установлено на 0₁₆ для обозначения версии 0 исходного пакета видеоданных.

Поле compression mode specific information (специальная информация режима сжатия) имеет разное определение для каждого из режимов сжатия. Перечень режимов сжатия приведен в таблице 2. Подробная информация о поле compression mode specific information (специальная информация режима сжатия) для режимов сжатия 0₁₆, 1₁₆, 2₁₆ и FF₁₆ приведена в 4.6.2.2, 4.6.2.3, 4.6.2.4 и 4.6.2.5 соответственно.

Поле video data (видеоданные) определяется комбинацией видеорежима, режима сжатия и цветового пространства. Ссылка на применяемое определение для форматирования поля video data (видеоданные) приведена в таблице 5.

4.6.2.2 Тип специальной информации режима сжатия 0₁₆

На рисунке 9 приведено определение и расположение полей в рамках поля type specific information (тип специальной информации) для исходных пакетов видеоданных, передаваемых в режиме сжатия 0₁₆.

Поле VDSPC (счетчик исходных пакетов видеоданных) содержит текущий счет исходных пакетов видеоданных. Оно прирастает на единицу при создании передатчиком каждого исходного пакета видеоданных. В начале потока первый создаваемый исходный пакет имеет VDSPC, равный 0. Так как ширина VDSPC составляет только 8 бит, то в него входит значение нижних 8 бит текущего счета.

Поле sol (начало строки) устанавливается в исходном пакете, который содержит первый пиксель видеостроки. Не требуется, чтобы начало видеостроки соответствовало началу изохронного пакета IEEE-1394.

Поле sav (начало активной части видеосигнала) устанавливается в исходном пакете, который содержит первый пиксель первой активной видеостроки каждого кадра (построчная развертка) или каждого поля (чересстрочная развертка). Данное поле может устанавливаться только в исходном пакете с установленным полем sol. Не требуется, чтобы начало активной видеостроки совпадало с началом изохронного пакета IEEE-1394.

Поле line number (номер строки) - это строка, в которой находятся видеоданные в исходном пакете, как определено в спецификации видеосигнала, приведенной в таблице 1 для заданного видеорежима. Если нумерация строк не определена спецификацией видеосигнала, поле line number должно вести последовательный счет строк в кадре, начиная с первой строки, передаваемой с номером строки.

4.6.2.3 Тип специальной информации режима сжатия 1₁₆

Определение поля type specific information (тип специальной информации) для данного режима сжатия установлено в соответствующих спецификациях, указанных в таблице 2.

4.6.2.4 Тип специальной информации режима сжатия 2₁₆

Определение поля type specific information (тип специальной информации) для данного режима сжатия определено в соответствующих спецификациях, указанных в таблице 2.

4.6.2.5 Тип специальной информации режима сжатия FF₁₆

Определение поля type specific information (тип специальной информации) для режима сжатия FF₁₆ не входит в область применения настоящего стандарта.

4.6.2.6 Пакетизация видеоданных в режиме сжатия 0₁₆

При передаче данных в режиме сжатия 0₁₆ передаваемые видеоданные представляют собой активные пиксели по горизонтали как для активных строк, так и для строк кадрового периода гашения (обратного хода луча) (за исключением случая, когда их не существует). Первый пиксель видеостроки всегда должен быть первым пикселем в исходном пакете, и каждая видеострока всегда должна быть заполнена целым числом исходных пакетов. Количество пикселей в каждом исходном пакете зависит от видеорежима и цветового пространства и подробно определено в таблице 1. Изохронный канал IEEE 1394, используемый для передачи данных в соответствии с настоящим стандартом, должен передавать только один поток видеосигнала в одном изохронном канале 1394.

4.6.2.7 Пакетизация видеоданных в режиме сжатия 1₁₆

Пакетизация видеоданных для данного режима сжатия указана в соответствующих спецификациях, приведенных в таблице 2.

4.6.2.8 Пакетизация видеоданных в режиме сжатия 2₁₆

Пакетизация видеоданных для данного режима сжатия указана в соответствующих спецификациях, приведенных в таблице 2.

4.6.2.9 Пакетизация видеоданных в режиме сжатия FF₁₆

Пакетизация видеоданных для данного режима сжатия не входит в область применения настоящего стандарта.

4.6.2.10 Пакетизация видеоданных цветового пространства 0₁₆ - YUV 4:2:2 8 бит/отсчет

Для каждого пикселя существует отсчет Y. Каждый U и V отсчеты используют для двух пикселей. Нижний индекс n обозначает номер пикселя в пределах исходного пакета.

4.6.2.11 Пакетизация видеоданных цветового пространства 1₁₆ - YUV 4:4:4 8 бит/отсчет

Каждый пиксель содержит отсчеты Y, U и V. На рисунке 11 представлена схема расположения отсчетов. Нижний индекс n обозначает номер пикселя в пределах исходного пакета.

4.6.2.12 Пакетизация видеоданных цветового пространства 2₁₆ - RGB 8 бит/отсчет

Каждый пиксель содержит отсчеты R, G и B. На рисунке 12 представлена схема расположения отсчетов. Нижний индекс n обозначает номер пикселя в пределах исходного пакета.

4.6.2.13 Пакетизация видеоданных цветового пространства 3₁₆ - RGB 6 бит/отсчет

Пакетизация видеоданных для данного цветового пространства применяется только для режима сжатия 2₁₆ и указана в соответствующих спецификациях, приведенных в таблице 2.

4.6.2.14 Пакетизация видеоданных цветового пространства FF₁₆

Пакетизация видеоданных для данного цветового пространства не входит в область применения настоящего стандарта.

4.6.2.15 Пакетизация видеоданных видеорежима FF₁₆

Пакетизация видеоданных для данного видеорежима не входит в область применения настоящего стандарта.

4.6.3 Исходный пакет типа 1₁₆ - Исходный пакет информационного потока и метаданных (SIM)

4.6.3.1 Исходный пакет информационного потока и метаданных (SIM)

Исходный SIM пакет передается ровно один раз за видеокадр при всех режимах сжатия. Данный тип исходного пакета включает шесть типов данных. На рисунке 13 представлено определение и расположение полей исходного пакета информационного потока и метаданных.

При передаче режима сжатия 0₁₆ только исходный пакет SIM должен обозначать старт видеокадра, т.е. следующий исходный пакет видеоданных должен быть стартом первой строки видеоданных кадра.

В исходный пакет SIM включаются шесть типов данных:

- информационный поток;

- вспомогательные данные;

- специальная информация видеорежима;

- специальная информация режима сжатия;

- специальная информация цветового пространства;

- информация управления копированием.

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

Шесть бит зарезервированного поля и десять бит длины должны быть представлены для всех типов данных во всех исходных пакетах SIM. Если поле длины равно нулю, в исходном пакете SIM для данного типа данных отсутствуют байты данных. В приложении D приведен пример типового исходного пакета SIM.

Для обозначения исходного пакета SIM поле Type должно быть установлено на 1₁₆.

Поле Ver должно быть установлено на 1₁₆ для обозначения версии 1 исходного пакета SIM. Эта версия обратно совместима с версией 0. Все последующие версии должны быть обратно совместимыми, они должны только вводить дополнительные типы данных способом, совместимым с уже указанными версиями. Узел, получающий исходный пакет SIM с более поздним номером версии, чем тот, который он поддерживает, должен игнорировать дополнительные типы данных.

Поле Total Length (Общая длина) указывает количество действительных байт в части исходного пакета Source Packet Data (Данные исходного пакета). Его значение представляет собой сумму шести длин полей, 12 байт для длины и самих зарезервированных полей. Total Length (Общая длина) должна быть меньше или равной source packet size (размер исходного пакета) - 4, где source packet size (размер исходного пакета) определяется комбинацией видеорежима, режимов сжатия и цветового пространства. Так как существует ряд разных размеров исходных пакетов, маловероятно, чтобы Total Length (Общая длина) была равна source packet size (размер исходного пакета) - 4, поэтому все оставшиеся байты в исходном пакете за исключением обозначенных как Total Length (Общая длина) резервируют и должны быть установлены на 00₁₆.

4.6.3.2 Информационный поток

Тип данных информационного потока должен включаться во все исходные пакеты SIM. Определение полей в таком типе данных показано на рисунке 14.

Поле stream info length (длина потока информации) должно быть установлено на 14 (E₁₆) для указания, что информационный поток составляет 14 байт.

Поле video mode (видеорежим) кодируют в соответствии с таблицей 1. Для всех видеорежимов, за исключением режима FF₁₆, значения полей frame rate (частота кадров), P/I (построчная/чересстрочная развертка), vertical size (размер по вертикали), horizontal size (размер по горизонтали), transport vertical size (передаваемый размер по вертикали), transport horizontal size (передаваемый размер по горизонтали) являются фиксированными и приведены в приложении B. При использовании видеорежима FF₁₆ эти поля должны быть установлены на соответствующие значения, указанные в приведенных ниже таблицах. Если ни одно из значений не соответствует требуемому параметру, необходимо использовать значение, соответствующее отсутствию информации, т.е. все биты в нем должны быть установлены на 1₂. Действие, предпринимаемое узлом стока, принимающим поле, установленное на отсутствие информации, не входит в область применения настоящего стандарта.

Поле frame rate (частота кадров) кодируют в соответствии с таблицей 6.

Поле AR (форматное соотношение) представлено в приведенной ниже таблице 7.

Поле P/I указывает, какую развертку имеет видеопоток: построчную или чересстрочную. Поле P/I кодируют в соответствии с таблицей 8.

Поле vertical size (размер по вертикали) определяет значение в строках разрешающей способности видеопотока по вертикали. Данное число включает гашение обратного хода кадровой развертки, если применимо.

Поле horizontal size (размер по горизонтали) определяет значение в пикселях (не отсчетах) разрешающей способности видеопотока по горизонтали. Данное число включает гашение обратного хода построчной развертки, если применимо.

Поле transport vertical size (передаваемый размер по вертикали) определяет значение в строках разрешающей способности видеопотока по вертикали, которое передается в действительности. Для всех видеорежимов, определенных в настоящее время, за исключением FF₁₆, передается каждая строка и поэтому данное число учитывает любое гашение обратного хода кадровой развертки. Информация относительно возможной передачи гашения обратного хода кадровой развертки в видеорежиме FF₁₆ не входит в область применения настоящего стандарта.

Поле transport horizontal size (передаваемый размер по горизонтали) определяет значение в пикселях (не отсчетах) разрешающей способности видеопотока по горизонтали, которое передается в действительности. Для всех видеорежимов, определенных в настоящее время, за исключением FF₁₆, передается только активная часть каждых видеострок и поэтому данное число не учитывает какого-либо гашения обратного хода строчной развертки. Информация относительно возможной передачи гашения обратного хода строчной развертки в видеорежиме FF₁₆ не входит в область применения настоящего стандарта.

4.6.3.3 Вспомогательная информация

При передаче видеоданных, для которых существуют вспомогательные данные, тип данных вспомогательной информации должен включаться во все исходные пакеты SIM. Определение полей в таком типе данных представлено на рисунке 15.

Поле auxiliary data length (длина вспомогательных данных) должно устанавливаться на 14 (E₁₆) для указания того, что вспомогательные данные содержат 14 байт.

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

TC VAL: A 1, если поля временного кодирования содержат действительную информацию.

TC tens of frames: Значение в двоично-десятичном представлении (BCD) десятков кадров с временным кодированием.

TC units of frames: Значение в двоично-десятичном представлении (BCD) единиц кадров с временным кодированием.

Drop (удаление/игнорирование): A 1, если временной код основан на подсчете в режиме удаления.

TC tens of seconds: Значение в двоично-десятичном представлении (BCD) десятков секунд с временным кодированием.

TC units of seconds: Значение в двоично-десятичном представлении (BCD) единиц секунд с временным кодированием.

TC tens of minutes: Значение в двоично-десятичном представлении (BCD) десятков минут с временным кодированием.

TC units of minutes: Значение в двоично-десятичном представлении (BCD) единиц минут с временным кодированием.

TC tens of hours: Значение в двоично-десятичном представлении (BCD) десятков часов с временным кодированием.

TC units of hours: Значение в двоично-десятичном представлении (BCD) единиц часов с временным кодированием.

RD VAL (значение даты записи): A 1, если поля даты записи содержат действительную информацию.

DS (декретное время): A 1, если время записи основано на декретном времени.

tens of time zone: Значение в двоично-десятичном представлении (BCD) десятков значений времени записи во временной зоне.

units of time zone: Значение в двоично-десятичном представлении (BCD) единиц значений времени записи во временной зоне.

tens of day: Значение в двоично-десятичном представлении (BCD) десятков дат записи в день.

units of day: Значение в двоично-десятичном представлении (BCD) единиц дат записи в день

day of week: День недели, от 0 (воскресенье) до 6 (суббота).

tens of month: Значение в двоично-десятичном представлении (BCD) десятков дат записей в месяц.

units of month: Значение в двоично-десятичном представлении (BCD) единиц дат записей в месяц.

tens of year: Значение в двоично-десятичном представлении (BCD) десятков дат записей в год.

units of year: Значение в двоично-десятичном представлении (BCD) единиц дат записей в год.

hundreds of year: Значение в двоично-десятичном представлении (BCD) сотен дат записей в год.

thousands of year: Значение в двоично-десятичном представлении (BCD) тысяч дат записей в год.

RT VAL: A.1, если поля времени записи содержат действительную информацию.

RT tens of frames: Значение в двоично-десятичном представлении (BCD) десятков кадров с временем записи.

RT units of frames: Значение в двоично-десятичном представлении (BCD) единиц кадров с временем записи.

RT tens of seconds: Значение в двоично-десятичном представлении (BCD) десятков секунд с временем записи.

RT units of seconds: Значение в двоично-десятичном представлении (BCD) единиц секунд с временем записи.

RT tens of minutes: Значение в двоично-десятичном представлении (BCD) десятков минут с временем записи.

RT units of minutes: Значение в двоично-десятичном представлении (BCD) единиц минут с временем записи.

RT tens of hours: Значение в двоично-десятичном представлении (BCD) десятков часов с временем записи.

RT units of hours: Значение в двоично-десятичном представлении (BCD) единиц часов с временем записи.

4.6.3.4 Специальная информация видеорежима

Для всех видеорежимов, за исключением FF₁₆, отсутствуют поля данных, определенных в настоящее время для этого типа данных. Поэтому video mode specific info length (длина специальной информации видеорежима) должна быть 00₁₆, и в поле данных этого типа информации не содержаться байт данных.

Для видеорежима FF₁₆ первые три байта, следующие за полем длины, должны быть уникальным идентификатором (OUI) организации поставщика, который указывает передаваемую структуру типа данных специальной информации видеорежима. Поэтому video mode specific info length (длина специальной информации видеорежима) должна быть не менее 03₁₆. Оставшиеся поля этой структуры типа данных определяются организацией-поставщиком, обозначенным значением OUI.

4.6.3.5 Специальная информация режима сжатия

Для режима сжатия 0₁₆ отсутствуют поля данных, определенных в настоящее время для этого типа данных. Поэтому compression mode specific info length (длина специальной информации режима сжатия) должна быть 00₁₆, и в поле данных этого типа информации не должно содержаться байт данных.

Для режимов сжатия 1₁₆ и 2₁₆ длина и структура типа данных определена в соответствующих спецификациях, указанных в таблице 2.

Для режима сжатия FF₁₆ первые три байта, следующие за полем длины, должны быть уникальным идентификатором (OUI) организации-поставщика, который указывает передаваемую структуру типа данных специальной информации режима сжатия. Поэтому compression mode specific info length (длина специальной информации режима сжатия) должна быть не менее 03₁₆. Оставшиеся поля этой структуры типа данных определяются организацией-поставщиком, обозначенным значением OUI.

4.6.3.6 Специальная информация цветового пространства

Для всех режимов цветового пространства, за исключением FF₁₆, отсутствуют поля данных, определенных в настоящее время для этого типа данных. Поэтому color space specific info length (длина специальной информации цветового пространства) должна быть 00₁₆, и в поле данных этого типа информации не должно содержаться байт данных.

Для режима цветового пространства FF₁₆ первые три байта, следующие за полем длины, должны быть уникальным идентификатором (OUI) организации-поставщика, который указывает передаваемую структуру типа данных специальной информации режима цветового пространства. Поэтому color space specific info length (длина специальной информации цветового пространства) должна быть не менее 03₁₆. Оставшиеся поля этой структуры типа данных определяются организацией-поставщиком, обозначенным значением OUI.

4.6.3.7 Специальная информация об организации-поставщике

Если данное поле не используется, vendor specific info length (длина специальной информации об организации-поставщике) должна быть 00₁₆, и в поле данных этого типа информации не должно содержаться байт данных.

При использовании данного поля первые три байта, следующие за полем длины, должны быть уникальным идентификатором (OUI) организации-поставщика, который вводил в эксплуатацию данное устройство. В таком случае vendor specific info length (длина специальной информации об организации-поставщике) должна быть не менее 03₁₆. Оставшиеся поля этой структуры типа данных определяются организацией-поставщиком, обозначенным значением OUI.

4.6.3.8 Информация управления копированием (CCI)

Во все исходные пакеты SIM должен быть включен блок информации управления копированием.

Если CCI для передачи отсутствует, copy control specific info length (длина специальной информации управления копированием) должна быть 00₁₆, и в поле данных этого типа информации не должно содержаться байт данных.

При использовании данного поля первые три байта, следующие за полем длины, должны быть уникальным идентификатором (OUI) организации-поставщика, который определил информацию управления копированием. В таком случае copy control specific info length (длина специальной информации о возможности копирования) должна быть не менее 03₁₆. Оставшиеся поля этой структуры типа данных определяются организацией-поставщиком, обозначенным значением OUI.

В приложении H дано определение структуры дескриптора CCI, которая определена стандартом Торговой Ассоциацией 1394.

4.6.4 Исходный пакет типа 2₁₆ - Исходный пакет аудиоданных

4.6.4.1 Исходный пакет аудиоданных

Спецификация транспортирования аудиоданных в рамках того же потока 1394, в котором передаются видеоданные, будут в будущем введены в настоящий стандарт. До момента введения этого обновления рекомендуется передавать аудиоданные в виде отдельного потока 1394, описанного в МЭК 61833-6 [6]. Для этой цели зарезервирован исходный пакет типа 2₁₆. Предлагаемый метод синхронизации каналов видео- и аудио-1394 приведен в приложении A. Реальный метод синхронизации аудио-/видеосигналов является зависимым от реализации.

4.7.1.1 Общие представления о передаче

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

a) Готовый к передаче непустой пакет определяется как истинный, если один или более исходных пакетов видеоданных доставлены в рамках какого-либо изохронного цикла. Такой метод передачи называют передачей без блокировки, он описан в 4.7.1.2.

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

Так как заголовок исходного пакета (SPH) отсутствует, имеется только одна временная отметка, и она находится в поле SYT заголовка CIP. Если CIP содержит несколько исходных пакетов видеоданных, необходимо определить, какой из них соответствует данной отметке времени.

Поскольку поток включает исходный пакет SIM с частотой один пакет за кадр, требуется механизм, обеспечивающий генерацию временной отметки SYT с регулярным интервалом следования исходных пакетов видеоданных. Для этой цели используют поле VDSPC (счетчик исходных пакетов видеоданных) в исходном пакете видеоданных.

Передатчик готовит временную отметку для исходного пакета видеоданных, которая отвечает условию:

mod(VDSPC, SYT_INTERVAL) = 0,

где

VDSPC - текущий счет переданных исходных пакетов видеоданных.

SYT_INTERVAL означает количество исходных пакетов видеоданных между двумя последовательными действительными временными отметками SYT и включает один из исходных пакетов видеоданных с действительным SYT. Например, если между двумя последовательными действительными временными отметками SYT существуют два исходных пакета видеоданных, то SYT_INTERVAL будет равен 4. SYT_INTERVAL зависит от используемого видеорежима и цветового пространства. Значения SYT_INTERVAL приведены в таблице 1.

Приемник опознает исходный пакет видеоданных, для которого действительна временная отметка SYT, так как это исходный пакет, VDSPC которого решает следующее уравнение:

mod (VDSPC, SYT_INTERVAL) = 0.

Приемник отвечает за оценку синхронизации блоков данных между действительными временными отметками. Метод оценки синхронизации зависит от способа реализации.

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

Значение задержки передачи TRANSFER_DELAY составляет 875 мкс, что обеспечивает максимальное время ожидания передачи изохронного пакета через управляемое обнуление короткой шины, в худшем случае задержку пакетизации, и предусматривает возможность шифрования/дешифрования при необходимости. Отклонение значения TRANSFER_DELAY приведено в приложении F.

Передатчик отсчитывает синхроимпульсы генератора синхронизации, например, передний фронт синхроимпульсов для видеосигнала, путем отсылки к собственному времени цикла CYCLE_TIME. Он передает сумму этого времени цикла и TRANSFER_DELAY в поле SYT общего изохронного пакета (CIP). Если информация о синхронизации для CIP не требуется, в SYT должен быть указан код отсутствия информации, т.е. FFFF₁₆.

4.7.1.2 Метод передачи без блокировки

Передатчик должен формировать пакет в каждом номинальном изохронном цикле. Каждый пакет должен отвечать следующим условиям:

0 <= N <= MAX_VDSP,

где

N - количество исходных пакетов видеоданных в изохронном пакете.

MAX_VDSP приведен в таблице 1.

При стандартной работе передатчик не должен передавать события с опозданием и не должен передавать пакеты слишком рано. Результирующее условие можно выразить следующим образом:

Packet_arrival_time_L <= Event_arrival_time[0] + TRANSFER_DELAY

Event_arrival_time[N-1] <= Packet_arrival_time_F,

где

Packet_arrival_time_F - время, мкс, когда первый бит изохронного пакета поступает на приемник.

Packet_arrival_time_L - время, мкс, когда последний бит изохронного пакета поступает на приемник.

Event_arrival_time[M] - время, мкс, прихода на передатчик исходного пакета видеоданных изохронного пакета M. Первый исходный пакет видеоданных изохронного пакета имеет M = 0.

Так как MAX_VDSP всегда больше или равен SYT_INTERVAL для всех видеорежимов, будет существовать максимум одна временная отметка SYT в исходном пакете видеоданных.

4.7.1.3 Метод передачи с блокировкой

В передатчике может использоваться метод блокировки, когда будет существовать возможность передавать изохронные пакеты только одного размера. Для индикации отсутствия данных передатчик может передавать изохронный пакет с заголовком CIP или специальный непустой пакет с установкой признака ND (отсутствие данных) на 1₂ в его поле FDF и тем же размером фиктивных данных, что и непустой пакет.

Передатчик должен формировать пакет, состоящий из не более чем MAX_VDSP + 1 исходных пакетов.

При блокировке длительность последовательных исходных пакетов видеоданных в CIP должна добавляться к задержке передачи по умолчанию TRANSFER_DELAY.

Если CIP состоит из N исходных пакетов видеоданных, тогда

ACTUAL_TRANSFER_DELAY >= TRANSFER_DELAY + (N * VDSP_DURATION),

где

TRANSFER_DELAY - длительность исходного пакета видеоданных, зависит от видеорежима и цветового пространства. Длительность VDSP_DURATION для каждого видеорежима приведена в приложении B. Суммарная задержка для исходных видеопакетов MAX_VDSP также приведена в приложении B.

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

4.7.1.4 Распределение ширины полосы/пропускной способности

До передачи потока на администраторе изохронного ресурса должна быть зарезервирована достаточная ширина полосы/пропускная способность.

Для этой цели при расчете блоков распределения ширины полосы/пропускной способности используют следующее уравнение:

Максимальное количество байт в пакете = ((MAX_VDSP + 1) x Размер исходного пакета) + 20 [A]

Максимальное количество квадлет в пакете = (Максимальное количество байт в пакете/4)

Блоки распределения ширины полосы/пропускной способности = Максимальное количество квадлет в пакете x SPEED_FACTOR

Коэффициент скорости SPEED_FACTOR принимает следующие значения:

a) при S100 SPEED_FACTOR = 16

b) при S200 SPEED_FACTOR = 8

c) при S400 SPEED_FACTOR = 4

d) при S800 SPEED_FACTOR = 2

e) при S1600 SPEED_FACTOR = 1

f) при S3200 SPEED_FACTOR = 0,5 (это может привести к дробному результату блоков распределения ширины полосы/пропускной способности, в таком случае значение следует округлить до следующего целого числа).

Для обеспечения достаточной ширины полосы/пропускной способности для исходного пакета SIM, который передается один раз за кадр, к MAX_VDSP следует добавить 1. При стандартном методе передачи без блокировки исходные пакеты видеоданных, которые ниже MAX_VDSP, будут передаваться в каждом пакете; для некоторых видеорежимов это может обеспечить достаточную ширину полосы/пропускную способность для передачи исходного пакета SIM без дополнительной назначаемой полосы, когда при этом уравнение [A] становится:

Максимальное количество байт в пакете = (MAX_VDSP * Размер исходного пакета) + 20 [B]

Для цветового пространства 0₁₆ уравнение [A] требуется следующим видеорежимам:

g) режимы 49, 59, 60 и 61.

Для цветового пространства 1₁₆ и 2₁₆ уравнение [A] требуется следующим видеорежимам:

h) только режим 61.

Для режимов, которым уравнение [A] для расчета блоков распределения ширины полосы/пропускной способности не требуется, все же рекомендуется использовать его, так как в случае потери возможности передавать пакет (например, при отбрасывании пакета на старте цикла после обнуления шины) передатчик может "нагнать" за счет передачи MAX_VDSP событий в одном или более последовательных пакетах. Также, поскольку исходный пакет SIM передается единожды за кадр, распределение ширины полосы/пропускной способности, рассчитанное по уравнению [A], обеспечивает достаточную назначенную полосу так, что в изохронном пакете может быть послан один дополнительный исходный пакет видеоданных сверх MAX_VDSP без нарушения назначенной ширины полосы/пропускной способности, что справедливо для большинства изохронных пакетов. Если в большую часть времени эта дополнительная ширина полоса использоваться не будет, это обеспечит дополнительную пропускную способность, необходимую для более быстрого "подхвата" передачи.

Для всех режимов блоки (единицы) распределения ширины полосы/пропускной способности рассчитывают с использованием уравнения [A], а сами блоки (единицы) перечислены в приложении B.

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

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

Определение параметров синхронизации передачи для данного режима сжатия не входит в область применения настоящего стандарта.

Спецификация [5], устанавливающая требования к управлению аудио-/видеосигналами, предоставляет достаточные функциональные возможности для идентификации объединенных изохронных потоков 1394.

Временная синхронизация может быть обеспечена на основании применения принципов, приведенных ниже.

Устройство, которое поддерживает данную спецификацию, а также производит аудиопотоки, соответствующие МЭК 61883-6, должно гарантировать, что оба потока синхронизированы относительно временной отметки появления, т.е. аудио- и видеоданные, одновременно приходящие на передатчик, должны появляться на приемнике одновременно.

TRANSFER_DELAY для этих потоков являются отличными от задержки TRANSFER_DELAY, приведенной в настоящем стандарте, которая больше задержки, приведенной в МЭК 61883-6 [6]. Поэтому источник должен обеспечить задержку данных по МЭК 61883-6 до входа в систему 1394 на время, равное

(TRANSFER_DELAY для 601 поверх 1394) - (TRANSFER_DELAY для МЭК 61883-6).

Такая буферизация должна выполняться в области синхронизации аудиосигналов. Следует отметить, что МЭК 61883-6 обеспечивает возможность изменения TRANSFER_DELAY МЭК 61883-6; передатчик, который обеспечивает эту функциональную возможность, должен соответственно менять эту дополнительную задержку. Должна существовать возможность настраивать TRANSFER_DELAY МЭК 61883-6 на значение, которое больше значения, используемого в настоящем стандарте. В этом случае видеоданные будут задерживаться в области синхронизации видеосигналов за счет разницы в значениях TRANSFER_DELAY.

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

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

Примечание - Из-за ширины таблиц в данном приложении их будет две.

В МЭК 61883-1 [6] определен механизм конфигурирования изохронных потоков вплоть до S400 включительно. В стандарте IEEE 1394.1:2004 (Стандарт на мосты высокопроизводительной последовательной шины [9]), в приложении E, определен механизм расширения такой конфигурации для потоков вплоть до S3200.

Считается, что устройство, соответствующее настоящему стандарту, будет устройством, совместимым со спецификацией управления аудио-, видеосигналами (AV/C) [5].

Считается, что команда формата потока управления аудио-, видеосигналом AV/C STREAM FORMAT будет расширена с целью обеспечения идентификации и выбора видеорежима, режима сжатия и цветового пространства. Допустимы средства идентификации и выбора видеорежима, режима сжатия и цветового пространства, зависящие от реализации.

Устройство-источник, поддерживающее указанную выше спецификацию, должно поддерживать как минимум один видеорежим. В данном контексте видеорежим FF₁₆ является действительным (действующим) режимом.

Устройство-источник, поддерживающее указанную выше спецификацию, должно поддерживать как минимум один режим сжатия. В данном контексте режимы сжатия 0₁₆ и FF₁₆ являются действительными (действующими) режимами.

Устройство-источник, поддерживающее настоящий стандарт, должно поддерживать как минимум одно цветовое пространство. В данном контексте цветовое пространство FF₁₆ является действительным (действующим) цветовым пространством.

Устройство приема/стока, поддерживающее настоящий стандарт и обеспечивающее вывод, прямо или косвенно, видеопотока на дисплей, должно поддерживать как минимум один видеорежим. В данном контексте видеорежим FF₁₆ является действительным (действующим) режимом.

Устройство приема/стока, поддерживающее указанную выше спецификацию и обеспечивающее вывод, прямо или косвенно, видеопотока на дисплей, должно поддерживать как минимум один режим сжатия. В данном контексте режимы сжатия 0₁₆ и FF₁₆ являются действительными (действующими) режимами.

Устройство приема/стока, поддерживающее указанную выше спецификацию и обеспечивающее вывод, прямо или косвенно, видеопотока на дисплей, должно поддерживать как минимум одно цветовое пространство. В данном контексте цветовое пространство FF₁₆ являются действительным (действующим) цветовым пространством.

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

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

Представленный в настоящем приложении исходный пакет SIM является типовым примером такого пакета.

При установке видеорежима - 0, режима сжатия - 0 и цветового пространства - 0 sourse packet size (размер исходного пакета) составляет 644 байта (см. таблицу 1). Поэтому предполагается, что в конце исходного пакета резервируются байты [644 - (56 + 4)], т.е. имеется 584 резервных байта.

Параметр TRANSFER_DELAY формируется следующим образом:

Полученное значение округляют до 875 мкс, чтобы создать точно семь изохронных периодов, которые требуют только простое добавление к таймеру цикла, чтобы сгенерировать значение SYT.

Поправка на шифрование/дешифрование должна обеспечить пространство для гибкой реализации.

Обычно задержка пакетизации 601 намного меньше 140 мкс, но это значение для наихудшего случая.

Структура дескрипторного блока CCI (информации управления копированием) TA 1394 приведена на рисунке G.1. Определение установок полей, отличных от OUI и CCI_ID для конкретных величин, не рассматривается в настоящем стандарте.

OUI - 3-байтовый OUI 1394 TA, 00A02D₁₆.

CCI_ID_x - 3-байтовый назначенный идентификатор 1394 TA для данного дескрипторного блока CCI, 434349₁₆.

RMm - режим пересылки с сохранением используется в комбинации с системой защиты и управления копированием (CGMS) для определения функции пересылки или функции сохранения. Комбинация значений представлена ниже.

RS - состояние хранения кодируют следующим образом:

EPN - шифрование плюс неподтверждение кодируют следующим образом:

CGMS - кодируют следующим образом:

RC - управление перераспределением кодируют следующим образом:

ICT - признак ограничения изображения кодируют следующим образом:

ACS - кодируют следующим образом:

AST - признак окончания аналоговой передачи кодируют следующим образом:

DOT - признак только цифровой передачи кодируют следующим образом:

CC - счет копий кодируют следующим образом:

Примечание - Данное приложение может быть в будущем выделено в отдельную спецификацию TA 1394.

Дополнительная информация, относящаяся к настоящему стандарту, содержится в приведенных ниже документах: