ГОСТ Р МЭК 61883-8-2016 Аудио-/видеоаппаратура бытового назначения. Цифровой интерфейс. Часть 8. Передача цифровых видеоданных согласно рекомендации ITU-R BT.601

ГОСТ Р МЭК 61883-8-2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

АУДИО-/ВИДЕОАППАРАТУРА БЫТОВОГО НАЗНАЧЕНИЯ. ЦИФРОВОЙ ИНТЕРФЕЙС

Часть 8

Передача цифровых видеоданных согласно рекомендации ITU-R ВТ.601

Consumer audio/video equipment. Digital interface. Part 8. Transmission of ITU-R BT.601 style digital video data

ОКС 33.160.01,

35.200

Дата введения 2017-11-01

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту МЭК 61883-8:2014* "Аудио-/видеоаппаратура бытового назначения. Цифровой интерфейс. Часть 8. Передача цифровых видеоданных согласно рекомендации ITU-R ВТ.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 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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, в данных, касающихся конкретного стандарта. На это время стандарт будет:

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

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

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

- изменен.

1 Область применения

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

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

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

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

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

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

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

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

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

2 Нормативные ссылки

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

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

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 1394а-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 specifcation version 4.2 (Основная спецификация набора команд для цифрового интерфейса управления аудио/видеосигналами (AV/C). Версия 4.2)

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

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

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

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

ITU-R ВТ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 ВТ.601 (ВТ.601 МСЭ-Р)]

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

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

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

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

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

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

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

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

3 Сокращения и условные обозначения

3.1 Сокращения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 Система счисления

3.2.1 Числовые значения

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

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

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

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

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

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

Рисунок 1 - Порядок следования бит в составе байта

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

Рисунок 2 - Порядок следования байт в структуре квадлета

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

Рисунок 3 - Порядок следования квадлет в составе октлета

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

4 Эталонная модель передачи данных

4.1 Обзор модели

При существующих в настоящее время стандартах на сжатие данных DV (цифрового видео) и MPEG2 для IEEE 1394 транспортировки имеются трудности на уровне системы в практической пользовательской сети аудио- и видеосигналов. Оба стандарта предлагают чрезмерное сжатие для простой транспортировки по широкомасштабной широкополосной информационной сети и соответственно имеют сложности в кодировании и декодировании сигналов. Каждый из них хорош для определенной цели, но для простой транспортировки видеосигналов излишне дорог. Стандартное видеооборудование стыкуется с кабелями для аналоговых сигналов, передающими ряд форматов сигналов, и поэтому цифровые интерфейсы должны иметь низкую стоимость и иметь универсальную функцию соединения. Таким образом, аналоговый выход с любого DVD плеера будет подключаться к любому ТВ приемнику, и изготовители оборудования видят в этом практическую целесообразность. Цифровые интерфейсы могли бы обеспечить много дополнительных возможностей, но обеспечение каждого входа функцией декодирования DV и MPEG2 во всех существующих стандартах и решениях является необоснованно дорогим. Общей практикой является изменение на стыке внутри вещательного оборудования по BT.601-5/ВТ.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, механизм транспортировки, представленный в настоящем стандарте, менять не придется.

4.2 Сжатие

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

4.3 Заголовок изохронного пакета

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

Рисунок 4 - Заголовок изохронного пакета

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

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

4.4 Заголовок CIP

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

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

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

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

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

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

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

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

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

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

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

Рисунок 5 - Заголовок CIP

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

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

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

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

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

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

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

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

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

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

Рисунок 6 - Поле FDF

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

4.5 Определение потока

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

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

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

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

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

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

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

Таблица 1 - Видеорежим

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

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

Таблица 2 - Режим сжатия

________________

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

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

Таблица 3 - Цветовое пространство

4.6 Пакетизация

4.6.1 Формат исходного пакета

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

Рисунок 7 - Общий формат исходного пакета

Поле 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 - Кодирование типа исходного пакета

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

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

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

Рисунок 8 - Исходный пакет видеоданных

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

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

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

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

Таблица 5 - Ссылки для определения видеоданных

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

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

Рисунок 9 - Специальная информация режима сжатия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 10 - Пакетизация видеоданных цветового пространства

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

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

Рисунок 11 - Пакетизация видеоданных цветового пространства

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

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

Рисунок 12 - Пакетизация видеоданных цветового пространства

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

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

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

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

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

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

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

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

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

Рисунок 13 - Исходный пакет потока информации и метаданных

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

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

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

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

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

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

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

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

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

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

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

Поле Ver должно быть установлено на для обозначения версии 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 (Общая длина) резервируют и должны быть установлены на .

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

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

Рисунок 14 - Определение полей информационного потока

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

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

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

Таблица 6 - Частота кадров

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

Таблица 7 - Форматное соотношение

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

Таблица 8 - Режим построчной/чересстрочной развертки

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 15 - Определения полей вспомогательных данных

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 (значение даты записи): А 1, если поля даты записи содержат действительную информацию.

DS (декретное время): А 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: А.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 Специальная информация видеорежима

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.7 Метод передачи пакетов

4.7.1 Пакетная передача для режима сжатия

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 Метод передачи без блокировки

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

0NMAX_VDSP,

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

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

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

Packet_arrival_time_LEvent_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] - время, мкс, прихода на передатчик исходного пакета видеоданных изохронного пакета М. Первый исходный пакет видеоданных изохронного пакета имеет М=0.

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

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

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

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

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

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

ACTUAL_TRANSFER_DELAY >= TRANSFER_DELAY + (N * VDSP_DURATION),

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

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

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

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

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

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

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

Блоки распределения ширины полосы/пропускной способности = Максимальное количество квадлет в пакете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 без дополнительной назначаемой полосы, когда при этом уравнение [А] становится:

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

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

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

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

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

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

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

4.7.2 Пакетная передача для режима сжатия

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

4.7.3 Пакетная передача для режима сжатия

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

4.7.4 Пакетная передача для режима сжатия

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

Приложение A
(справочное)

Синхронизация аудио-, видеосигналов

A.1 Логическое объединение потоков аудио- и видеосигналов

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

A.2 Временная синхронизация аудио- и видеопотоков

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

Устройство, которое поддерживает данную спецификацию, а также производит аудиопотоки, соответствующие МЭК 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 мс.

Приложение B
(обязательное)

Дополнительные параметры видеорежима

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

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

Таблица B.1 - Дополнительные параметры видеорежима, 1 из 2

Таблица B.2 - Дополнительные параметры видеорежима, 2 из 2

Приложение C
(справочное)

Использование регистров управления разъемом МЭК 61883-1 выше S400

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

Приложение D
(обязательное)

Дополнение оценки совместимости

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

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

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

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

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

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

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

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

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

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

Приложение E
(справочное)

Типовой исходный пакет SIM

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

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

Рисунок Е.1 - Типовой исходный пакет SIM

Приложение F
(справочное)

Формирование TRANSFER_DELAY

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

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

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

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

Приложение G
(обязательное)

Дескрипторный блок CCI стандарта Торговой ассоциации (ТА) 1394

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

Рисунок G.1 - Дескрипторный блок CCI

OUI - 3-байтовый OUI 1394 ТА, 00A02D.

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

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

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

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

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

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

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

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

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

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

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

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

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов национальным и межгосударственным стандартам

Таблица ДА.1

Библиография

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

Электронный текст документа

и сверен по:

, 2020