СИСТЕМЫ И СПОСОБЫ ДЛЯ ПЕРЕКЛЮЧЕНИЯ КАНАЛОВ
SYSTEMS AND METHODS FOR CHANNELS SWITCHING

Перекрестные ссылки на родственные заявки
Данная патентная заявка претендует на положительный эффект принадлежащей тому же правообладателю предварительной заявки США №60/865822 под заголовком «SYSTEMS AND METHODS FOR CHANNEL SWITCHING», поданной 14 ноября 2006 года. Эта предварительная патентная заявка включена в настоящий документ посредством ссылки.
Данная заявка во всех отношениях полностью включает посредством ссылки принадлежащие тому же правообладателю патентные заявки США № 11/527306, поданную 25 сентября 2006 года, и № 11/528303, поданную 26 сентября 2006 года.
Область техники, к которой относится изобретение
Данное изобретение относится к обработке мультимедийного сигнала и, в частности, касается способов видеокодирования и видеодекодирования кадров переключения каналов (CSF) для разрешения захвата и ресинхронизации видеопотока при сохранении эффективности сжатия.
Уровень техники
Системы мультимедийной обработки, такие как видеокодеры, могут кодировать мультимедийные данные с использованием способов кодирования на основе международных стандартов, таких как стандарты Экспертной группы по кинематографии (MPEG)-1, -2 и -4, стандарт H.263 Международного союза электросвязи (ITU)-Т, стандарт ITU-T H.264 и его аналог, ISO/IEC MPEG-4, часть 10, то есть стандарт усовершенствованного видеокодирования (AVC), каждый из которых целиком включен в настоящий документ посредством ссылки. Указанные способы кодирования в общем случае имеют своей целью сжатие мультимедийных данных для передачи и/или хранения. Сжатие в широком смысле слова можно рассматривать как процесс устранения избыточности из мультимедийных данных.
Видеосигнал можно описать на основе последовательности изображений, которые включают в себя кадры (целое изображение) или поля (например, чересстрочный видеопоток содержит поля чередующихся нечетных или четных строк изображения). Используемый здесь термин «кадр» относится к изображению, кадру или полю. Способы видеокодирования обеспечивают сжатие видеосигналов путем использования алгоритма сжатия без потерь или с потерями для сжатия каждого кадра. Внутрикадровое кодирование относится к кодированию кадра с использованием только данного кадра. Межкадровое кодирование относится к кодированию кадра на основе других, так называемых «опорных» кадров. Например, видеосигналы часто отличаются временной избыточностью, при которой близлежащие кадры во временной последовательности кадров имеют по меньшей мере несколько участков, которые полностью или по меньшей мере частично совпадают друг с другом.
Мультимедийные процессоры, такие как видеокодеры, могут кодировать кадр, разбивая его на блоки или «макроблоки», состоящие, например, из 16×16 пикселей. Кодер может дополнительно разбить каждый макроблок на субблоки. Каждый субблок может также содержать дополнительные субблоки. Например, субблоки макроблока могут включать в себя субблоки 16×8 и 8×16. Субблоки из субблоков 8×16 могут включать в себя субблоки 8×8, которые могут содержать субблоки 4×4 и т.д. Используемый здесь термин «блок» относится либо к макроблоку, либо к субблоку.
Кодеры используют преимущество временной избыточности между последовательными кадрами, применяя алгоритмы межкадрового кодирования на основе компенсации движения. Алгоритмы компенсации движения идентифицируют части одного или нескольких опорных кадров, которые, по меньшей мере, частично соответствуют одном блоку. Этот блок может быть сдвинут в кадре относительно участка совпадения опорного кадра (кадров). Этот сдвиг характеризуется одним или несколькими векторами движения. Любые отличия между данным блоком и участком частичного совпадения опорного кадра (кадров) могут быть охарактеризованы на основе одного или нескольких остатков. Кодер может закодировать кадр в виде данных, которые содержат один или несколько векторов движения, и остатки для конкретного варианта разбиения кадра. Конкретный вариант разбиения блоков для кодирования кадра можно выбрать путем приближенной минимизации функции затрат, которая, например, сопоставляет разрядность кодирования с искажением или воспринимаемым искажением для контента кадра, получающегося в результате кодирования.
Межкадровое кодирование позволяет обеспечить более эффективное сжатие, чем внутрикадровое кодирование. Однако межкадровое кодирование может создать проблемы, связанные с потерей опорных данных (например, опорных кадров или опорных полей) из-за канальных ошибок и т.п. Вдобавок к потерям опорных данных из-за ошибок эти опорные данные также могут оказаться недоступными из-за начального захвата или повторного захвата видеосигнала в кадре с межкадровым кодированием. В таких случаях декодирование данных, закодированных способом межкадрового кодирования, может оказаться невозможным или может привести к нежелательным ошибкам и их распространению. Эти сценарии могут привести к потере синхронизации видеопотока.
Наиболее общей формой кадра, которая предоставляет возможность ресинхронизации видеосигнала, является независимо декодируемый кадр с внутрикадровым кодированием. В стандартах MPEG-x и H.26x используется так называемая «группа изображений» (GOP), содержащая кадр с внутрикадровым кодированием (называемый также I-кадром) и P-кадры, кодированные на основе временного предсказания, или B-кадры, кодированные на основе предсказания «вперед/назад», которые обращаются к I-кадру и/или другим P- и/или В кадрам в группе GOP. Для увеличения степени сжатия желательно иметь более длинные группы GOP; но следует иметь в виду, что более короткие группы GOP позволяют обеспечить более быстрый захват и ресинхронизацию. Увеличение количества I-кадров позволяет обеспечить более быстрый захват и ресинхронизацию, правда, за счет меньшего сжатия.
Следовательно, имеется потребность в способах видеокодирования и видеодекодирования кадров переключения каналов (CSF), позволяющих обеспечить захват и ресинхронизацию видеопотока при сохранении эффективности сжатия.
Сущность изобретения
Предложены способы видеокодирования и видеодекодирования кадров переключения каналов (CSF), дающих возможность захвата и ресинхронизации видеопотока при сохранении эффективности сжатия. Согласно одному аспекту предложено устройство, содержащее процессор, использующийся для создания кадра переключения каналов (CSF) из одного или нескольких блоков уровня сетевой абстракции (NAL) для разрешения точек произвольного доступа в кодированном битовом потоке.
Другой аспект включает в себя компьютерный программный продукт, содержащий считываемый компьютером носитель с командами, заставляющими компьютер создавать кадр переключения каналов (CSF) из одного или нескольких блоков уровня сетевой абстракции (NAL) для разрешения точек произвольного доступа в кодированном битовом потоке.
Еще один аспект включает в себя устройство, содержащее процессор, использующийся для декодирования одного или нескольких смежных кадров, каждый из которых имеет одинаковый идентификационный номер кадра, причем первый кадр из смежных кадров является кадром точки произвольного доступа (RAP), а второй кадр не является кадром RAP.
Дополнительные аспекты изобретения станут более очевидными из подробного описания изобретения, в частности, взятого вместе с прилагаемыми чертежами.
Краткое описание чертежей
Фиг.1 - блок-схема примерной системы мультимедийной связи согласно конкретным конфигурациям;
фиг.2А - блок-схема примерного кодирующего устройства, которое можно использовать в системе по фиг.1;
фиг.2В - блок-схема примерного декодирующего устройства, которое можно использовать в системе по фиг.1;
фиг.3 - примерная взаимосвязь между сообщениями уровня синхронизации и медиапотоком реального времени, который выводится на устройство или выводится устройством в сети FLO;
фиг.4 - примерные уровни протокола для услуги реального времени в сети FLO;
фиг.5А-5В - примерные альтернативные взаимосвязи между пакетами уровня синхронизации и медиакадрами;
фиг.6 - примерный конечный автомат для обработки уровня синхронизации для отдельного потока в устройстве;
фиг.7 - примерный кадр переключения каналов (CSF);
фиг.8 - примерный кадр (CSF) с 3 блоками NAL;
фиг.9 - генератор кадра переключения каналов;
фиг.10 - процесс декодирования битового потока с кадрами CSF;
фиг.11 - генератор заголовка синхронизации, создающий заголовок синхронизации;
фиг.12А - генератор дополнительных полей генератора заголовка синхронизации;
фиг.12В - генератор типа адаптации генератора заголовка синхронизации;
фиг.13А - ассемблер общего медиазаголовка;
фиг.13В - ассемблер заголовка, отражающего специфику медиа;
фиг.14 - ассемблер каталога уровня синхронизации видео;
фиг.15 - ассемблер записи VSL;
фиг.16 - блок-схема процесса обработки с уровня синхронизации на медиауровень в устройстве;
фиг.17 - пример битового потока, созданного сетью с одинаковыми идентификационными номерами смежных кадров.
Изображения на чертежах в иллюстративных целях показаны в упрощенном виде и без соблюдения масштаба. Для облегчения понимания там, где возможно, использованы одинаковые ссылочные позиции для обозначения одинаковых элементов, являющихся общими для всех чертежей, за исключением того, что для различения некоторых элементов добавлены индексы, когда необходимо.
В прилагаемых чертежах показаны примерные конфигурации изобретения, причем их не следует рассматривать как ограничение объема изобретения, которое допускает другие, не менее эффективные конфигурации. Предполагается, что признаки или блоки из одной конфигурации можно с успехом включить в другие конфигурации без дополнительного перечисления.
Подробное описание изобретения
Сокращения
В последующем описании применяются следующие сокращения:
FLO - Связь только в прямом направлении;
IDR - мгновенное обновление декодирования;
IEC - Международная электротехническая комиссия;
IETF - Инженерная группа по развитию Интернет;
ISO - Международная организации по стандартизации;
ITU - Международный союз электросвязи;
ITU-T - Сектор стандартизации электросвязи ITU;
NAL - уровень сетевой абстракции;
RBSP - полезная нагрузка необработанной байтовой последовательности;
TIA - Ассоциации промышленности средств связи;
TM3 - Наземная мобильная мультимедийная многоадресная передача;
UINT - целое число без знака;
RAP - точка произвольного доступа;
PTS - отметка времени представления.
Используемый здесь термин «примерный» означает «служащий в качестве примера, варианта или иллюстрации». Любая конфигурация или техническое решение, описанное здесь как «примерное», не обязательно следует трактовать как предпочтительное или имеющее преимущество над другими конфигурациями или техническими решениями, а термины «ядро», «механизм», «машина», «процессор» и «блок обработки» используются как взаимозаменяемые.
Описанные здесь способы можно использовать для беспроводной связи, обработки данных, персональных электронных устройств и т.д. Примерное использование этих способов для беспроводной связи описано ниже.
Последующее подробное описание ориентировано на некоторые выборочные конфигурации изобретения. Однако изобретение может быть воплощено множеством различных путей, определенных и покрываемых формулой изобретения. В этом описании делаются ссылки на чертежи, в которых подобные компоненты обозначены везде одинаковыми ссылочными позициями.
Видеосигналы можно охарактеризовать на основе последовательности изображений, кадров и/или полей, каждый из которых может дополнительно включать в себя один или несколько сегментов (слайсов). Используемый здесь термин «кадр» имеет широкий смысл и может охватывать один или несколько кадров, полей, изображений и/или слайсов.
Конфигурации включают в себя системы и способы, которые облегчают переключение каналов в системе мультимедийной передачи. Мультимедийные данные могут включать в себя одно или несколько из следующего: ТВ- или киноизображение, звук, фотографические изображения, текст или аудиовизуальные данные любого другого подходящего типа.
На фиг.1 показана блок-схема примерной системы 100 мультимедийной связи согласно некоторым конфигурациям. Система 100 включает в себя кодирующее устройство 110, связанное с декодирующим устройством 150 через сеть 140. В одном примере кодирующее устройство 110 принимает мультимедийный сигнал от внешнего источника 102 и кодирует этот сигнал для передачи по сети 140.
В данном примере кодирующее устройство 110 содержит процессор 112, связанный с памятью 114 и приемопередатчиком 116. Процессор 112 кодирует данные от источника мультимедийных данных и подает их в приемопередатчик 116 для передачи по сети 140.
В этом примере декодирующее устройство 150 содержит процессор 152, связанный с памятью 154 и приемопередатчиком 156. Хотя декодирующее устройство 150 может иметь приемопередатчик 156 как для передачи, так и для приема, декодирующему устройству 150 необходим только приемник, такой как приемник 158. Процессор 152 может включать в себя один или несколько процессоров общего назначения и/или цифровой процессор сигналов. Память 154 может включать в себя одно или несколько запоминающих устройств на твердотельной основе или на дисках. Приемопередатчик 156 сконфигурирован для приема мультимедийных данных по сети 140 и предоставления их процессору 152 для декодирования. В одном примере приемопередатчик 16 включает в себя беспроводный приемопередатчик. Сеть 140 может содержать одну или несколько систем проводной или беспроводной связи, включая одно или несколько из следующего: сеть Ethernet, телефонные (например, обычные старые телефонные системы (POTS)) и кабельные системы, системы связи по линиям электросети и оптоволоконные системы, и/или беспроводную систему, содержащую одну или несколько из следующих систем: систему связи с множественным доступом и кодовым разделением каналов (CDMA или CDMA2000), систему с множественным доступом и частотным разделением каналов (FDMA), систему с множественным доступом и ортогональным частотным разделением каналов (OFDM), систему с множественным доступом и временным разделением каналов (TDMA), например GSM/GPRS (Пакетная радиосвязь общего назначения)/EDGE (усовершенствованная среда GSM для высокоскоростной передачи данных), система мобильной телефонной связи TETRA (наземная магистральная радиосвязь), широкополосная система с множественным доступом и кодовым разделением каналов (WCDMA), высокоскоростная система передачи данных (1xEV-DO или 1xEV-DO Gold multicast), система IEEE 802.11, система mediaFLO, система DMB, система DVB-H и т.п.
На фиг.2А показана блок-схема примерного кодирующего устройства 110, которое можно использовать в системе 100 по фиг.1 согласно некоторым конфигурациям. В данной конфигурации кодирующее устройство 110 содержит элемент 118 для межкадрового кодирования, элемент 120 для внутрикадрового кодирования, элемент 122, создающий опорные данные, и передающий элемент 124. Элемент 118 для межкадрового кодирования кодирует части видеоданных с использованием межкадрового кодирования с временным предсказанием (например, с использованием предсказания с компенсацией движения), обращаясь к другим частям видеоданных, расположенных в других временных кадрах. Элемент 120 для внутрикадрового кодирования кодирует части видеоданных, используя внутрикадровое кодирование, причем эти части могут декодироваться независимо без обращения к другим временно привязанным видеоданным. В некоторых конфигурациях элемент 120 для внутрикадрового кодирования может использовать пространственное предсказание для реализации преимуществ избыточности в других видеоданных, находящихся в том же временном кадре.
Генератор 122 опорных данных согласно одному аспекту создает данные, которые указывают, где находятся видеоданные, закодированные путем внутрикадрового кодирования и межкадрового кодирования, которые были созданы кодирующими элементами 120 и 118 соответственно. Например, опорные данные могут включать в себя идентификаторы субблоков и/или макроблоков, которые используются декодером для определения местоположения в кадре. Опорные данные могут также включать в себя порядковый номер кадра, используемый для определения местоположения кадра в последовательности видеокадров.
Передатчик 124 передает данные, закодированные путем межкадрового кодирования, данные, закодированные путем внутрикадрового кодирования, а в некоторых конфигурациях, и опорные данные по сети, такой как сеть 140 на фиг.1. Данные могут передаваться по одной или нескольким линиям связи. Термин «линии связи» используется в общем смысле и может включать в себя любые каналы связи, в том числе, но не только: проводные или беспроводные сети, виртуальные каналы, оптические линии связи и т.п. В некоторых конфигурациях данные, закодированные путем внутрикадрового кодирования, передаются по линии связи базового уровня, а данные, закодированные путем межкадрового кодирования, передаются по линии связи уровня улучшения. В некоторых конфигурациях данные, закодированные путем внутрикадрового кодирования, и данные, закодированные путем межкадрового кодирования, передаются по одной и той же линии связи. В некоторых конфигурациях один или несколько из следующих видов данных: данные, закодированные путем межкадрового кодирования, данные, закодированные путем внутрикадрового кодирования, и/или опорные данные, - могут передаваться по линии связи на боковой полосе частот. Например, можно использовать линию связи на боковой полосе частот, такую как сообщения SEI (формат дополнительной информационной поддержки) в стандарте H.264 или сообщения user_data в стандарте MPEG-2. В некоторых конфигурациях одно или несколько из нижеследующего: данные, закодированные путем внутрикадрового кодирования, данные, закодированные путем межкадрового кодирования, и/или опорные данные, - передаются по виртуальному каналу. Виртуальный канал может содержать пакеты данных с идентифицируемым заголовком пакета, который идентифицирует пакет данных как принадлежащий данному виртуальному каналу. Специалистам в данной области техники известны другие виды идентификации виртуального канала, такие как частотное разделение, временное разделение, кодовое расширение и т.д.
На фиг.2В показана блок-схема примерного декодирующего устройства 150, которое может быть использовано системой 100 по фиг.1 согласно некоторым конфигурациям. В данной конфигурации декодер 150 содержит приемный элемент 158, избирательный декодирующий элемент 160, элемент 162, определяющий опорные данные, и один или несколько детекторов доступности опорных данных, такие как элемент 164 - детектор переключения каналов, и элемент 166 - детектор ошибок.
Приемник 158 принимает кодированные видеоданные (например, данные, закодированные кодирующим устройством 110 по фигурам 1 и 2А). Приемник 158 может принимать кодированные данные по проводной или беспроводной сети, такой как сеть 140 по фиг.1. Данные могут приниматься по одной или нескольким линиям связи. В некоторых конфигурациях данные, закодированные путем внутрикадрового кодирования, принимаются по линии связи базового уровня, а данные, закодированные путем межкадрового кодирования, принимаются по линии связи уровня улучшения. В некоторых конфигурациях данные, закодированные путем внутрикадрового кодирования, и данные, закодированные путем межкадрового кодирования, принимаются по одной и той же линии связи. В некоторых конфигурациях один или несколько из следующих видов данных: данные, закодированные путем межкадрового кодирования, данные, закодированные путем внутрикадрового кодирования, и/или опорные данные, - могут приниматься по линии связи на боковой полосе частот. Например, можно использовать линию связи на боковой полосе частот, такую как сообщения SEI в стандарте H.264 или сообщения user_data в стандарте MPEG-2. В некоторых конфигурациях одно или несколько из нижеследующего: данные, закодированные путем внутрикадрового кодирования, данные, закодированные путем межкадрового кодирования, и/или опорные данные принимаются по виртуальному каналу. Виртуальный канал может содержать пакеты данных с идентифицируемым заголовком пакета, который идентифицирует пакет данных как принадлежащий данному виртуальному каналу. Специалистам в данной области техники известны другие виды идентификации виртуального канала.
Избирательный декодер 160 декодирует полученные видеоданные, закодированные путем межкадрового кодирования и внутрикадрового кодирования. В некоторых конфигурациях полученные данные содержат версию части видеоданных, закодированных путем межкадрового кодирования, и версию части видеоданных, закодированных путем внутрикадрового кодирования. Данные, закодированные путем межкадрового кодирования, могут быть декодированы после того, как декодированы опорные данные, на основе которых они были предсказаны. Например, данные, закодированные с использованием предсказания с компенсацией движения, содержат вектор движения и идентификатор кадра, идентифицирующий местоположение опорных данных. Если часть кадра, идентифицированная вектором движения и идентификатором кадра для версии, закодированной путем межкадрового кодирования, доступна (например, уже декодирована), то тогда избирательный декодер 160 может декодировать эту версию, закодированную путем межкадрового кодирования. Однако в том случае, если опорные данные не доступны, то тогда избирательный декодер 160 может декодировать версию, закодированную путем внутрикадрового кодирования.
Определитель 162 опорных данных согласно одному аспекту идентифицирует полученные опорные данные, которые указывают, где находятся видеоданные, закодированные путем внутрикадрового кодирования и межкадрового кодирования, в полученных закодированных видеоданных. Например, опорные данные могут включать в себя идентификаторы субблоков и/или макроблоков, которые используются избирательным декодером 160 для определения местоположения в кадре. Опорные данные могут также включать в себя порядковый номер кадра, используемый для определения местоположения кадра в последовательности видеокадров. Использование полученных опорных данных позволяет декодеру определить, доступны ли опорные данные, от которых зависят данные, закодированные путем межкадрового кодирования.
На доступность опорных данных может повлиять пользователь, переключающий канал в многоканальной системе связи. Например, приемнику 158 может быть доступно множество широковещательных передач видео при использовании одной или нескольких линий связи. Если пользователь дает команду приемнику 158 переключиться на другой широковещательный канал, то тогда опорные данные для данных, закодированных путем межкадрового кодирования, в новом канале могут не сразу оказаться доступными. Детектор 164 переключения каналов обнаруживает появление команды на переключение каналов и сигнализирует об этом избирательному декодеру 160. Затем избирательный декодер 160 может использовать информацию, полученную от определителя опорных данных, для идентификации того, доступны ли опорные данные версии, закодированной путем межкадрового кодирования, а затем идентифицирует местоположение ближайшей версии, полученной путем внутрикадрового кодирования, и избирательно декодирует эту идентифицированную версию, закодированную путем внутрикадрового кодирования.
На доступность опорных данных могут также повлиять ошибки в принятых видеоданных. Детектор 166 ошибок может использовать технологии обнаружения ошибок (например, прямое исправление ошибок) для идентификации неисправляемых ошибок в битовом потоке. Если неисправляемые ошибки имеются в опорных данных, от которых зависит версия, закодированная путем межкадрового кодирования, то тогда детектор 166 ошибок может просигнализировать об этом избирательному декодеру 160, идентифицируя, на какие видеоданные влияют эти ошибки. Затем избирательный декодер 160 может определить, декодировать ли версию, закодированную путем межкадрового кодирования (например, если опорные данные доступны), либо следует декодировать версию, закодированную путем внутрикадрового кодирования (например, если опорные данные недоступны).
В некоторых конфигурациях один или несколько элементов кодирующего устройства 110 по фиг.2А могут быть перекомпонованы и/или объединены. Эти элементы могут быть реализованы аппаратными средствами, программными средствами, программно-аппаратными средствами, межплатформенными программными средствами, микрокодом или любой их комбинацией. В некоторых конфигурациях один или несколько элементов декодера 150 по фиг.2В могут быть перекомпонованы и/или объединены. Эти элементы могут быть реализованы аппаратными средствами, программными средствами, программно-аппаратными средствами, межплатформенными программными средствами, микрокодом или любой их комбинацией.
Видео
TM
Некоторые описанные здесь конфигурации можно реализовать, используя видеокодирование MediaFLO для доставки видеоуслуг реального времени в системах TM3 c использованием спецификации радиоинтерфейса FLO «Спецификация радиоинтерфейса связи только в прямом направлении (FLO) для наземной мобильной мультимедийной многоадресной передачи», опубликованной в виде технического стандарта TIA-1099, которая целиком включена в настоящий документ посредством ссылки. Некоторые конфигурации определяют синтаксис и семантику битового потока, а также процесс декодирования для предоставления этих услуг через уровни 412 радиоинтерфейса FLO.
Приведенное здесь описание формирует по меньшей мере частично стандарт совместимости для мультимедийных многоадресных систем FLO, который помогает адаптивному устройству 304 FLO получать услугу (услуги) через любую сеть 302 FLO (фиг.3), удовлетворяющую этому стандарту.
Нормативные ссылки
Рекомендации H.264 ITU-T и/или Международный стандарт ISO/IEC 14496-10 усовершенствованного видеокодирования (называемый здесь «стандарт H.264/AVC») целиком включены сюда по ссылке, и на них можно ссылаться по конкретным аспектам.
Также для описанных здесь конфигураций применяются определения из параграфа 3 стандарта H.264/AVC. Вдобавок, кадр переключения каналов (CSF) в соответствии с описанными здесь примерными конфигурациями определяется как кодированное изображение, содержащее набор параметров последовательности и/или набор параметров изображения, и/или изображение мгновенного обновления декодирования. Кадр переключения каналов (CSF) может быть инкапсулирован в независимый пакет транспортного протокола для разрешения точек произвольного доступа в кодированном битовом потоке или для облегчения устранения ошибок. Кадры переключения каналов (CSF) определены ниже.
Условные обозначения, используемые здесь для операторов, системы записи, математических функций, синтаксических элементов, таблиц и процессов, соответствуют заданным в параграфе 5 стандарта H.264/AVC.
Некоторые описанные здесь конфигурации включают в себя описание объема, нормативных ссылок, определения терминов, сокращения и структуру изобретения, а также описание синтаксиса, семантики и процессов декодирования битового потока.
Формат битового потока низкого уровня сложности и декодирование для мультимедийной широковещательной передачи
В приведенном здесь описании среди прочего описываются примерный формат битового потока и процесс декодирования, который обеспечивает расширение низкого уровня сложности для мультимедийной широковещательной передачи. Битовый поток, соответствующий расширению низкого уровня сложности, описанному в указанной спецификации, согласуется с профилями в разделе А.2 стандарта H.264/AVC при следующих дополнительных ограничениях и расширениях: 1) Наборы параметров последовательности могут иметь profile_idc, равный 66 или 88; 2) Наборы параметров последовательности могут иметь constraint_set0_flag, равный 0; 3) Наборы параметров последовательности могут иметь constraint_set1_flag, равный 1; 4) Наборы параметров последовательности могут иметь constraint_set2_flag, равный 0; 5) Может присутствовать слайс типа В; и/или 6) Слайсы для В-изображений могут иметь nal_ref_idc, равный 0 (idc представляет индекс профиля).
Согласно другому аспекту этих конфигураций битовый поток соответствующий расширению низкого уровня сложности, описанному в этой спецификации, соответствует профилям в разделе А.2 стандарта H.264/AVC при следующих ограничениях и расширениях: 1) Наборы параметров последовательности могут иметь profile_idc, равный 66 или 88; 2) Наборы параметров последовательности могут иметь constraint_set0_flag, равный 1; 3) Наборы параметров последовательности могут иметь constraint_set1_flag, равный 0; 4) Наборы параметров последовательности могут иметь constraint_set2_flag, равный 1; 5) Может присутствовать тип В слайс типа В; и/или 6) Слайсы для В-изображений могут иметь nal_ref_idc, равный 0.
Кадр переключения каналов
TM
1
X
На фиг.7 показан примерный кадр 700 переключения каналов (CSF). Чтобы разрешить изменение канала в среде MediaFLO и облегчить устранение ошибок, кодирующие элементы 120 согласно некоторым конфигурациям могут вставлять кадры переключения каналов (CSF). Кадр 700 переключения каналов (CSF) может содержать до 3 или более блоков NAL: NAL… NAL, обозначенных ссылочными позициями 702 и 704. X может быть равен 2 или более. Тем не менее, CSF 700 может иметь только один блок NAL.
На фиг.8 показан примерный кадр CSF 800 с 3 блоками NAL. В этом примере кадр CSF 800 содержит 3 блока 802, 804 и 806 NAL. Если используются 3 блока NAL, то в некоторых ситуациях при их наличии может иметь место следующий порядок в битовом потоке: набор 812 параметров последовательности (SPS), набор 814 параметров изображения (PPS) и мгновенное обновление 816 декодирования (IDR). Блок IDR NAL может представлять собой блок IDR NAL с низким уровнем качества.
Такая компоновка CSF показана в Таблице 1. Таблица 1 определяет, какие типы блока NAL используются в данный момент для CSF 800. В данной примерной конфигурации типы блока NAL включают в себя номера 7, 8 и 5. Тем не менее, при других обстоятельствах тип 5 для IDR NAL можно заменить типом 1 NAL I-кадра (кодированный слайс). Полезная нагрузка RBSP обозначает полезную нагрузку необработанной байтовой последовательности, которая представлена в столбце под заголовком «синтаксическая структура RBSP». Столбец nal_unit_type представляет номер типа блока NAL, используемый здесь для кадра CSF. Столбец С представляет другие поддерживаемые структуры. Например, номера 2, 3 и 4 представляют участки А, В и С данных. Номер 1 также представляет блок 1 NAL кодированного слайса. Номер 0 не определен.
Таблица 1Блоки NAL и синтаксис RBSP для кадров переключения каналов
Контент блока NAL
Синтаксическая структура RBSP
Nal_unit_type
C
Набор параметров последовательности
seq_parameter_set_rbsp()
7
0
Набор параметров изображения
pic_paramete_set_rbsp()
8
1
Кодированные слайсы изображения IDR
slice_layer_with_partitioning_rbsp()
5
2, 3
Кодированный слайс
Slice_layer_with_partitioning_rbsp()
1
2, 3, 4
Синтаксис, семантика и процессы декодирования для этих блоков NAL соответствуют заданным в стандарте H.264/AVC.
Спецификации параметров кадра переключения каналов
Семантика битовых потоков кадров переключения каналов (CSF) предъявляет различные требования для ряда синтаксических элементов, переменных и функций, отличные от требований стандарта H.264/AVC.
На фиг.9 показан генератор 900 кадра переключения каналов (CSF). Генератор 900 CSF включает в себя генератор 902 набора SPS, генератор 904 набора PPS, генератор 906 обновления IDR и генератор 908 I-кадра. Следующие требования отличаются от стандарта H.264/AVC. Генератор 902 набора SPS допускает, чтобы блок NAL результирующего набора параметров последовательности (SPS) кадра CSF 800 имел pic_order_cnt_type, равный 0. Вдобавок, генератор 902 набора SPS допускает, чтобы блок NAL результирующего набора параметров последовательности (SPS) кадра CSF 800 имел флаг gaps_in_frm_num_value_allowed_flag, равный 0.
Генератор набора PPS создает блок NAL результирующего PPS. Генератор 908 I-кадра создает блок NAL I-кадра. Генератор 906 обновления IDR создает блок NAL результирующего IDR, так что синтаксический элемент pic_order_cnt_lsb для изображения IDR может быть ненулевым. Изображение IDR, PicOrderCnt(), равно изображению соответствующего Р-слайса PicOrderCnt(). Вдобавок, синтаксический элемент frame_num изображения IDR может быть ненулевым. frame_num изображения IDR равен frame_num соответствующего Р-слайса. frame_num следующего изображения может быть равен (frame_num+1)%MaxFrameNum.
Таким образом, генератор IDR включает в себя вычислитель 910 значения счетчика последовательности изображения (POC) для IDR, который устанавливает значение POC блока NAL IDR равным значению POC Р-слайса. Генератор IDR также включает в себя вычислитель 912 номера кадра изображения IDR, который устанавливает номер кадра изображения равным номеру кадра изображения Р-слайса. Генератор IDR в некоторых случаях обеспечивает также ненулевые значения номера кадра изображения и счетчика POC. Кодирующее устройство 110 отслеживает номер кадра в блоке 916, где frame_num изображения может быть равен (frame_num+1)%MaxFrameNum.
Кодирующее устройство 110 может отслеживать значение переменной PrevRefFrameNum, так что оно может быть установлено равным значению CSF frame_num минус 1.
Декодирование кадра переключения каналов
На фиг.10 показан процесс 1000 для декодирования битового потока с кадрами CSF. Процесс 1000 декодирования для I-слайсов в виде, заданном в параграфе 8 стандарта H.264/AVC, может быть использован для декодирования кадра переключения каналов (CSF), если блок NAL c IDR заменен блоком NAL с I-слайсом (кодированный слайс NAL типа 1), созданным генератором 908 I-кадра. Изображения в запрошенном канале с порядком вывода (отображения) перед кадром переключения каналов (CSF) могут быть отброшены. С точки зрения порядка вывода изменения в декодировании будущих изображений отсутствуют. Будущие изображения, следующие за кадром CSF, не могут использовать в качестве опорных кадров какие-либо изображения, выводимые перед кадром CSF.
В различных конфигурациях, приведенных ниже, блоки в блок-схемах выполняются в изображенном порядке, либо эти блоки или их части могут выполняться одновременно, параллельно или в другом порядке.
Таким образом, процесс 1000 декодирования начитается с блока 1002, где декодируется битовый поток с изображениями. За блоком 1002 следует блок 1004, где определяется, обнаружен ли кадр CSF. Если не обнаружен («НЕТ»), то тогда происходит циклический возврат из блока 1004 в блок 1002, где имеет место дополнительное декодирование битового потока.
Однако если в блоке 1004 результатом определения является «ДА», то тогда кадр CSF декодируется согласно I-слайсам и/или протоколу типов блока NAL. За блоком 1006 следует блок 1008, где определяется, имеются ли в порядке вывода какие-либо изображения запрошенного канала перед кадром CSF. Если определено «ДА», то эти изображения в блоке 1010 отбрасываются. За блоком 1010 следует блок 1012. Однако в том случае, если в блоке 1008 определено «НЕТ», то тогда за блоком 1008 следует блок 1012. В блоке 1012 определяется, имеется ли в порядке вывода какое-либо изображение в запрошенном канале после кадра CSF. Если определено «ДА», то в блоке 1014 в качестве не опорных кадров устанавливаются изображения перед кадром CSF в порядке вывода. За блоком 1010 следует блок 1012. Однако если определено «НЕТ», то тогда выполняется циклический возврат из блока 1012 в блок 1002. Также выполняется циклический возврат из блока 1014 в блок 1002, где имеет место стандартное декодирование. Не опорный кадр может быть установлен путем сброса кадра или путем принудительной установки кадра в качестве не опорного кадра.
Уровень синхронизации
TM
Система MediaFLO может поставлять контент по меньшей мере трех типов: в реальном времени, не в реальном времени и по технологии IP Datacast (например, многоадресная передача, одноадресная передача и т.д.). Сетевой интерфейс устройства многоадресной передачи (MDNI) для доставки услуги реального времени показан на фиг.4.
На фиг.3 показана примерная взаимосвязь между сообщениями уровня синхронизации и медиапотоком реального времени, выводимым на устройство 304 или выводимым устройством 304 в сети 302 FLO. Примерная сеть 302 FLO может поддерживать непрерывную доставку потокового контента в реальном времени на устройство 304. Каждый поток может доставляться по отдельности, причем соответствующий поток может быть идентифицирован как принадлежащий общей услуге или набору услуг посредством использования системной информации. Сеть 302 может дополнительно обеспечить данные, позволяющие устройствам синхронизировать медиапотоки реального времени друг с другом и согласовать их с требованиями к временному представлению контента. Уровень для объединения медиапотоков и данных синхронизации известен как уровень 406 синхронизации.
В устройстве 304, необходимом для доступа к услуге реального времени, для определения местоположения этой услуги используется системная информация. После обработки метаданных, относящихся к услуге, таких как, например, титул и номинальный режим представления, доступный в данный момент по этой услуге, устройство 304 может выбрать подходящий поток и воспроизвести принятый поток. Временные соотношения и синхронизация представления этих потоков могут регулироваться соответствующими протоколами.
Архитектура протоколов
На фиг.4 показаны примерные протокольные уровни 400 для услуги реального времени в сети 302 FLO. Услуга реального времени может использовать описанные здесь услуги уровня 408 кадрирования, а также описанный здесь уровень 410 шифрования/дешифрования потока. Он может состоять по меньшей мере из двух субуровней: уровень 404 медиакодека и уровень 406 синхронизации. Уровень 402 приложений реального времени показан на более высоком участке протокольных уровней 400.
Уровень 404 медиакодека поддерживает специализированные медиакодеки, которые не входят в объем данной конфигурации. Медиакодек подает последовательность медиакадров на уровень 406 синхронизации в сети. Каждый медиакадр может быть идентифицирован временной отметкой представления (PTS), которая обычно задает момент времени представления кадра, и соответствующим идентификатором (ID) кадра, который идентифицирует относительное положение кадра в последовательности кадров в суперкадре. Кодек источника видео может создавать множество медиакадров с одинаковыми PTS и ID кадра в суперкадре.
Для некоторых типов медиа, особенно для видео, уровень 404 медиакодека в сети 302 также подает метаданные на уровень 406 синхронизации, которые этот уровень в устройстве 304 может использовать для поддержки захвата и восстановления последовательности медиакадров, подлежащих доставке на уровень 404 медиакодека в устройстве 304.
Уровень 406 синхронизации отвечает за адаптацию медиакадров, как того требует тип медиа, и за обеспечение синхронизации медиа и временных соотношений представления. Уровень 406 синхронизации транспортирует последовательность пакетов уровня синхронизации. Пакет уровня синхронизации несет в себе либо медиакадр, либо кадр адаптации, как будет описано ниже. Пакет уровня синхронизации, несущий медиакадр, формируется путем добавления заголовка синхронизации (SH) к медиакадру. Заголовок синхронизации (SH) состоит из типа медиа, общего медиазаголовка и заголовка, отражающего специфику медиа, как более подробно описано ниже.
Дополнительно, уровень 406 синхронизации может нести некоторые метаданные, отражающие специфику каждого типа медиа. Эти метаданные переносятся двумя путями. Во-первых, как было замечено, в заголовок синхронизации пакетов уровня синхронизации могут быть включены специальные расширения, отражающие специфику медиа. Во-вторых, пакеты уровня синхронизации могут использоваться для переноса кадров адаптации, которые создаются на уровне 406 синхронизации и перемежаются пакетами уровня синхронизации, несущими медиакадры в том же потоке. Различные типы кадра адаптации идентифицируются идентификатором приложения в заголовке синхронизации для кадра приложения.
На фиг.5А и 5В показаны примерные альтернативные взаимосвязи между пакетами уровня синхронизации и медиакадрами согласно некоторым конфигурациям. На фиг.5А показан примерный пакет 500 уровня синхронизации, закодированный кодирующим устройством 110. В пакете 500 уровня синхронизации содержится, например, множество медиакадров 504, 506 и 510 переменной длины. Каждому медиакадру 504, 506 и 510 предшествует соответствующий заголовок 502 синхронизации (SH). Заголовок 502 синхронизации (SH) включает в себя три компоненты. Эти три компоненты содержат тип 520 медиа (MT), общий медиазаголовок (CMH) 522 и заголовок 524, отражающий специфику медиа (MSH), которые подробно описаны ниже.
В примере по фиг.5А кадр 508 адаптации вставлен между медиакадрами 506 и 510. Кадру 508 адаптации предшествует заголовок 512 синхронизации (SH), имеющий две компоненты. Эти две компоненты заголовка 512 синхронизации (SH) включают в себя тип 530 медиа (MT) и тип 532 адаптации (AT).
На фиг.5 показан второй примерный пакет 550 уровня синхронизации, закодированный кодирующим устройством 110. В пакете 550 уровня синхронизации содержится, например, множество медиакадров 564, 570 и 580 переменной длины. Каждому медиакадру 564, 570 и 580 предшествует соответствующий заголовок 560 синхронизации (SH) и заголовок 562 адаптации (AH). В примере на фиг.5В кадр 574 адаптации вставлен между кадрами 570 и 580. Кадру 574 адаптации предшествует заголовок 572 синхронизации (SH).
Опции конфигурации потока реального времени
Для потоков, обеспечивающих данные реального времени, опции конфигурации потока могут быть сконфигурированы следующим образом: 1) FASB_ALLOWED обозначает «не выбран»; 2) CHECKSUM_ACTIVE обозначает «конфигурируемый»; и 3) STREAM_ENCRYPTION_ACTIVE обозначает «конфигурируемый».
Интерфейсы уровня медиакодека и кадрирования
Услуга реального времени может состоять из потоковой компоненты более чем одного типа, например видео, аудио и текст, используемый для комментариев или ввода кодированных титров, причем это возможно в потоках на множестве языков и даже множестве их комбинаций. Каждая потоковая компонента может переноситься в отдельном потоке, либо множество потоковых компонент могут переноситься в едином потоке.
Что касается фиг.3, то здесь каждый тип контента кодируется и форматируется соответствующим образом. Здесь поддерживаются три типа потокового контента, однако специалистам в данной области техники очевидна возможность расширения представленных здесь концепций: видео (например, H.264); аудио (например, HE-AAC, версия 2); и/или синхронные данные (например, синхронный текст 3GPP PSS).
Кадры 508 или 574 адаптации, переносящие метаданные, связанные с потоком, рассматриваются как контент четвертого типа.
Интерфейс медиакодека в сети 302 подает последовательность медиакадров 504, 506, 510, 564, 570 и 580 на уровень 406 синхронизации. В устройстве 304 уровень 406 синхронизации подает последовательность медиакадров (например, 504, 506 и 510) в медиакодек. Медиакадры (например, 504, 506 и 510) могут быть выровнены по байтовым границам при прохождении через интерфейс между уровнем 406 синхронизации и уровнем 404 медиакодека как в устройстве 304, так и в сети 302.
Уровень 406 синхронизации в сети 302 добавляет заголовки уровня синхронизации (например, 502) в медиакадры (например, 504, 506 и 510) для создания пакетов синхронизации, перемежает их с пакетами синхронизации, доставляющими кадры 508 адаптации, и доставляет результирующие пакеты синхронизации на уровень 408 кадрирования для передачи. Пакеты синхронизации, несущие медиакадры видео, могут передаваться либо в компоненте модуляции базового уровня, либо в компоненте модуляции уровня улучшения, как это задается уровнем 404 медиакодека для видео. Другие пакеты синхронизации могут передаваться в компоненте базового уровня.
Уровень 406 синхронизации в устройстве 304 доставляет медиакадры (например, 504, 506 и 510) на уровень 404 медиакодека в порядке возрастания ID кадра в каждом суперкадре. На порядок доставки медиакадров видео накладываются некоторые дополнительные ограничения в том случае, когда имеется более одного медиакадра видео с одинаковым ID кадра.
MAX_RT
MAX_RT
Максимальный размер медиакадра (например, 504, 506 и 510) не может превышать P байт, где P - конфигурируемый параметр системы FLO, который может быть сконфигурирован для обеспечения возможности иметь множество различных размеров медиакадра.
В последующем описании определяется адаптация сервисных пакетов, предоставляемых медиакодеками для транспортировки через уровень 406 синхронизации для каждого типа медиа, и взаимодействия уровня 406 синхронизации с уровнем 408 кадрирования, отражающие специфику медиа.
Видеоконтент
Интерфейс сетевого медиакодека
Видеокадры могут создаваться с любой номинальной частотой, заданной в Таблице 8, приведенной ниже. Номинальная частота кадра может изменяться в суперкадре, например, потому, что контент из разных источников поступает в сеть с разной частотой кадров. Для каждого суперкадра уровень 404 медиакодека может указать уровню 406 синхронизации количество медиакадров, которое желательно представить пользователю. Видеокадры состоят из целого числа байтов. Следовательно, нет необходимости в байтовом выравнивании медиакадра, транспортирующего видеокадр.
Уровень 404 видеокодека может представлять видеокадры на уровень 406 синхронизации в порядке декодирования. Уровень 404 медиакодека может обеспечить с каждым видеокадром следующие метаданные для уровня 406 синхронизации: 1) PTS и ID кадра; 2) частоту кадров, связанную с данным кадром, которая идентифицирует мгновенную частоту, с которой видеокадры должны предоставляться пользователю; 3) является ли кадр точкой произвольного доступа (RAP), которую устройство 304 может использовать для захвата видеопотока; 4) является ли кадр опорным кадром; 5) содержит ли кадр существенную видеоинформацию или дополнительную видеоинформацию; и/или 6) предназначен ли кадр для передачи в компоненте базового уровня или компоненте уровня улучшения. Критерий, по которому определяется, является ли видеоинформация существенной или дополнительной, определяется уровнем 404 видеокодека.
Значение ID кадра может быть установлено равным нулю для первого видеокадра в суперкадре. Оно может либо оставаться тем же самым для каждого последующего видеокадра, представленного на уровень 406 синхронизации, либо возрастать вплоть до значения, равного количеству медиакадров, подлежащих представлению устройством 304.
Доставка кадров с одинаковым ID кадра через интерфейс связана с рядом ограничений. Первое ограничение состоит в том, что, если уровень 404 медиакодека создает один или несколько RAP-кадров и один или несколько альтернативных кадров с одинаковым ID кадра, то он может представить RAP-кадр (кадры) на уровень 406 синхронизации перед альтернативными кадрами. Второе ограничение заключается в том, что, если уровень 404 медиакодека создает два кадра с одним и тем же ID кадра, которые отличаются только уровнем качества видео, низкокачественный кадр может передаваться в компоненте базового уровня, а высококачественный кадр может передаваться в компоненте уровня улучшения.
Сетевой интерфейс уровня кадрирования
Уровень 406 синхронизации может сгруппировать пакеты синхронизации, переносящие видеокадры, в соответствии с тем, передаются ли они компоненте базового уровня или компоненте уровня улучшения. Каждая группа может обрабатываться отдельно.
Уровень 406 синхронизации может подать пакеты синхронизации для каждой группы на уровень 408 кадрирования в порядке возрастания ID кадра. Два пакета синхронизации с одинаковым ID кадра в одной и той же компоненте могут быть поданы на уровень 408 кадрирования в том порядке, в котором они были получены от уровня 404 медиакодека.
Интерфейс уровня кадрирования в устройстве
Устройство 304 может восстановить пакеты синхронизации, переданные из компонент базового уровня и уровня улучшения, а также может восстановить порядок, в котором они должны доставляться через интерфейс медиакодека в устройстве путем их совместной обработки.
Интерфейс медиакодека в устройстве
Уровень 406 синхронизации в устройстве 304 может представлять медиакадры видео (например, 504, 506 и 510) на уровень 404 медиакодека в порядке декодирования, определенном исходя из ID кадра согласно дополнительным рекомендациям (все или некоторые из которых могут быть исключены в альтернативных конфигурациях). Первая рекомендация состоит в том, что, если уровень 406 синхронизации обнаруживает медиакадр видео с установленным флагом RAP («RAP-кадр») и одним или несколькими кадрами, не являющимися RAP-кадром, и одинаковым ID кадра, то тогда дополнительно оценивается одно из двух условий. Первое условие (для первой рекомендации) состоит в том, что, если уровень 406 синхронизации не захватил видеопоток, то он может доставить RAP-кадр через интерфейс медиакодека (MCI) и может отбросить кадры, не являющиеся RAP-кадрами. В противном случае (второе условие), уровень 406 синхронизации может отбросить RAP-кадр и может доставить кадр (кадры), не являющиеся RAP-кадром, через интерфейс медиакодека (MCI), если это необходимо. RAP-кадр может являться кадром CSF.
Вторая рекомендация заключается в том, что, если уровень 406 синхронизации обнаруживает два медиакадра видео с идентичными заголовками уровня синхронизации (SH), он может доставить кадр, полученный на уровне улучшения, на уровень 404 медиакодека и отбросить кадр, полученный в базовом уровне.
Третья рекомендация состоит в том, что, если уровень 406 синхронизации обнаруживает медиакадр видео с существенной видеоинформацией и второй медиакадр видео с тем же самым ID кадра и дополнительной видеоинформацией, то рассматриваются два дополнительных условия. Согласно первому условию в третьей рекомендации, если уровень 404 медиакодека не поддерживает обработку дополнительной видеоинформации, то уровень 406 синхронизации может отбросить этот медиакадр видео и доставить медиакадр видео с существенной видеоинформацией на уровень 404 медиакодека. Согласно второму условию третьей рекомендации, если первое условие не выполняется, то уровень 406 синхронизации может доставить оба медиакадра видео на уровень 404 медиакодека.
На фиг.16 показана блок-схема процесса 1600 обработки с уровня 406 синхронизации на уровень 404 медиакодека в устройстве 304. Процесс 1600 начинается с блока 1602, где медиакадры видео предоставляются с уровня 406 синхронизации на уровень 404 медиакодека в порядке декодирования на основе идентификационного номера кадра. За блоком 1602 следует блок 1604, где определяется, имеются ли два смежных кадра с одинаковым идентификационным номером, и где один кадр является RAP-кадром (например, CSF), а другой не является RAP-кадром. Если результатом определения является «НЕТ», то выполняется циклический возврат из блока 1604 в блок 1602. Однако в случае, если определяется «ДА», то тогда за блоком 1604 следует блок 1606, где определяется, захватил ли уровень 406 синхронизации видеопоток. Если определено, что «ДА», то тогда за блоком 1606 следует блок 1608, где RAP-кадр отбрасывается, а кадры, не являющиеся RAP-кадрами, доставляются в интерфейс MCI в случае необходимости. Если определено «НЕТ», то тогда за блоком 1606 следует блок 1610, где RAP-кадр посылается в интерфейс MCI, а кадры, не являющиеся RAP-кадрами, отбрасываются.
На фиг.17 показан пример битового потока 1700, созданного сетью 302, где имеются смежные кадры с одинаковыми идентификационными номерами. Битовый поток 1700 аналогичен битовому потоку, показанному и описанному в связи с фиг.5А. В качестве примера, медиакадр 1704 включает в себя P-кадр (1) для канала, обозначенного как CH-CNN. Медиакадр 1704 включает в себя заголовок 1702 синхронизации (SH). Заголовок 1702 синхронизации (SH) аналогичен ранее описанному заголовку 502 синхронизации (SH).
В этом примере положим, что кадр CSF был вставлен для инициирования изменения канала, например, на канал CH-ESPN. Кадр CSF представлен медиакадром 1708 и включает в себя заголовок 1706 синхронизации (SH). Кадр CSF является RAP-кадром и имеет заголовок CMH 1720 с идентификационным номером кадра. В иллюстративных целях кадр адаптации с соответствующим заголовком SH показан после кадра CSF (медиакадр 1708). Медиакадр 1712 обозначен как кадр, не являющийся RAP-кадром, причем ему предшествует заголовок 1710 синхронизации (SH). В этом битовом потоке 1700 медиакадры 1708 и 1712 являются смежными. Кадр CSF предназначен для переключения каналов, например, на канал CH-ESPN. Для инициирования изменения канала медиакадр 1712 представляет собой P-кадр (2) и имеет CMH в заголовке 1710 синхронизации с идентификационным номером кадра, совпадающим с идентификационным номером кадра в заголовке 1706 синхронизации (SH) для кадра CSF (медиакадр 1708).
За медиакадром 1712 следует медиакадр 1716, имеющий заголовок 1714 синхронизации. Медиакадр 1716 может являться В-кадром. С точки зрения порядка вывода В-кадр предшествует Р-кадру. Таким образом, В-кадр отбрасывается или опускается (смотри фиг.10).
Что касается описания к фиг.10, медиакадр 1704 необходимо обозначить как не опорный кадр. Поскольку имеет место изменение канала, кадр 1704 не может служить в качестве опорного кадра для видеокадра в другом канале. Медиакадр 1704 может быть установлен в качестве не опорного кадра или удален из буфера. Тем не менее, могут быть использованы другие средства, исключающие использование медиакадра в качестве опорного кадра.
Аудиоконтент
Сетевой интерфейс медиакодека
Аудиокадры создаются с фиксированной частотой в соответствии с типом используемого аудиокодека. Однако частота аудиокадров может не быть кратной частоте суперкадров. Для каждого суперкадра уровень 404 медиакодека может указать уровню 406 синхронизации количество медийных кадров, которое желательно представить.
ID кадра может быть связан с каждым аудиокадром, представленным уровню 406 синхронизации. ID кадра может быть присвоен либо уровнем 404 медиакодека, либо уровнем 406 синхронизации. Значение ID кадра может быть установлено равным нулю для первого аудиокадра в суперкадре. Это значение может возрастать для каждого последующего аудиокадра, представляемого на уровень 406 синхронизации вплоть до значения, равного количеству медиакадров, представляемых устройством 304.
Уровень 404 медиакодека в сети 302 может представлять аудиокадры уровню 406 синхронизации в порядке их создания. Аудиокадр может состоять из нецелого числа байт. Уровень 404 медиакодека может обеспечить байтовое выравнивание в соответствии со средством, заданным для типа используемого аудиокодека.
Уровень 404 медиакодека может предоставить метаданные уровню 406 синхронизации вместе с каждым аудиокадром. Эти метаданные включают в себя ID кадра, если он присвоен уровнем 404 медиакодека.
Определение, является ли кадр RAP-кадром
Определяется, содержит ли кадр существенную аудиоинформацию или дополнительную аудиоинформацию. Критерий, по которому определяется, является ли аудиоинформация существенной или дополнительной, определяется уровнем 404 медиакодека.
Сетевой интерфейс уровня кадрирования
Пакеты синхронизации, содержащие аудиокадры, могут передаваться в компоненте модуляции, направляемой уровнем 404 медиакодека. Аудиокадры, полученные в каждой компоненте модуляции, могут быть представлены уровню 408 кадрирования в порядке их создания.
Интерфейс уровня кадрирования в устройстве
Уровень 406 синхронизации в устройстве 304 может обрабатывать пакеты синхронизации в порядке их приема через интерфейс уровня кадрирования.
Интерфейс медиакодека в устройстве
Уровень 406 синхронизации в устройстве 304 может представлять аудиокадры уровню 404 медиакодека в порядке их извлечения из пакетов синхронизации.
Контент синхронных данных
Сетевой интерфейс медиакодека
Кадры синхронных данных создаются с переменной частотой. Как правило, но не обязательно, имеется по меньшей мере один кадр синхронных данных на один суперкадр в потоке синхронных данных, как хорошо видно на фиг.3.
ID кадра может быть связан с каждым кадром синхронных данных, представленным уроню 406 синхронизации. ID кадра может присваиваться либо уровнем 404 медиакодека, либо уровнем 406 синхронизации. Значение ID кадра может быть установлено равным нулю для первого кадра синхронных данных в суперкадре. Это значение может возрастать для каждого последующего кадра синхронных данных, представленного уровню синхронизации, вплоть до значения, равного количеству медиакадров, представляемых устройством.
Уровень 404 медиакодека в сети может представлять кадры синхронных данных уровню 406 синхронизации в порядке их создания. Кадры синхронных данных могут состоять из нецелого количества байт. Байтовое выравнивание может быть обеспечено в соответствии со средством, заданным используемым типом синхронных данных. Метаданные, предоставляемые уровнем 404 медиакодека уровню 406 синхронизации вместе с каждым кадром синхронных данных, если таковые имеются, зависят от типа данных.
Сетевой интерфейс уровня кадрирования
Пакеты синхронизации, содержащие кадры синхронных данных, могут передаваться в компоненте модуляции, направленной уровнем 404 медиакодека. Кадры синхронных данных, принимаемые в каждой компоненте модуляции, могут быть представлены на уровень кадрирования в порядке их создания.
Интерфейс уровня кадрирования в устройстве
Уровень 406 синхронизации в устройстве может обрабатывать пакеты синхронизации в порядке из приема через интерфейс уровня кадрирования.
Интерфейс медиакодека в устройстве
Уровень 406 синхронизации в устройстве может представлять кадры синхронных данных на уровень 404 медиакодека в порядке их извлечения из пакетов синхронизации.
Захват на уровне синхронизации
На фиг.6 показан примерный конечный автомат 600 для обработки уровня 406 синхронизации для отдельного потока в устройстве согласно некоторым конфигурациям. Конечный автомат 600 иллюстрирует переходы из состояния в состояние, а также обработку, выполняемую в каждом состоянии.
Состояние выполнения захвата
Устройство 304 может войти в состояние 606 выполнения захвата в любом из следующих случаев: 1) захват сигнала FLO, обозначенный ссылкой 602; 2) прием от уровня 408 кадрирования индикации об изменении ID потока, обозначенный ссылкой 612; 3) потеря сигнала FLO, обозначенная ссылкой 610, при нахождении в состоянии 614 после захвата; 4) обнаружение медиакадра с ошибками, также обозначенное ссылкой 610, при нахождении в состоянии 614 после захвата; сигнализация об ошибках может осуществляться уровнем 408 кадрирования или ошибки могут быть обнаружены в результате контроля с помощью избыточного циклического кода (CRC), если обработка CRC сконфигурирована. Вдобавок, переход в состояние 606 выполнения захвата возможен при получении кадра, не являющегося RAP-кадром (обозначено ссылкой 604).
В случае передачи видеопотока устройство 304 может использовать информацию, предоставленную каталогом уровня синхронизации видео, если он доступен, чтобы определить природу медикадров, затронутых ошибкой. Устройство 304 способно определить, что процедуры устранения ошибок возможны без повторного перехода в состояние 614 выполнения захвата.
Состояние после захвата
После приема RAP-кадра (обозначено ссылкой 608), то есть при отсутствии ошибок, устройство 304 может перейти в состояние 614 после захвата. Переход в это же состояние происходит, когда не обнаружено ни одной ошибки в кадрах (обозначено ссылкой 616), при нахождении в состоянии 614 после захвата.
При нахождении в состоянии 614 захвата устройство 304 может обрабатывать медиакадры, предоставляемые уровнем 408 кадрирования. Достоверные медиакадры могут быть доставлены на уровень 404 медиакодека.
Заголовок синхронизации (SH)
На фиг.11 показан генератор 1110 заголовка синхронизации, создающий заголовок 1100 синхронизации. Генератор 1110 заголовка синхронизации включает в себя генератор 1130 типа медиаполя, который создает коды типа медиа. Коды типа медиа извлекаются для вставки в формат заголовка 1100 синхронизации, причем они включают в себя 00 для видео в блоке 1132, 01 для аудио в блоке 1134, 10 для синхронных данных в блоке 1136 и 11 для адаптации в блоке 1140. Генератор 1110 заголовка синхронизации также включает в себя генератор 1150 дополнительных полей. Генератор 1110 заголовка синхронизации также создает тип адаптации (AT), как показано на фиг.5А, с помощью генератора 1160 типа адаптации, показанного на фиг.12В.
Заголовок 1100 синхронизации состоит из поля 1102 типа медиа, за которым следуют дополнительные поля 1104, чей формат зависит от значения поля типа медиа, созданного генератором 1130 типа медиаполя. Генератор 1150 дополнительных полей показан на фиг.12А.
Общий формат заголовка 1100 синхронизации показан в таблице 2. Таблицы включают в себя имя поля, тип поля и присутствие поля. Присутствие поля указывает, является ли поле обязательным, условным и т.д. Тип поля указывает, является ли поле целочисленным без знака (UINT), переменной, битами и т.д.
Таблица 2Общий формат заголовка уровня синхронизации
Имя поля
Тип поля
Присутствие поля
MEDIA_TYPE (1102)
UINT(2)
Обязательное
Дополнительные поля (1104)
Переменная
Обязательное
MEDIA_TYPE
Поле 1102 MEDIA_TYPE идентифицирует тип медиакадра, переносимого пакетом уровня синхронизации, или определяет, что пакет уровня синхронизации несет кадр адаптации. Значения, определенные для поля MEDIA_TYPE, перечислены в Таблице 3.
Таблица 3Значения, определенные для MEDIA_TYPE
Имя
Значение
Видео
00
Аудио
01
TIMED_DATA
10
Адаптация
11
Дополнительные поля
На фиг.12А показан генератор 1150 дополнительных полей, входящий в генератор 1110 заголовка синхронизации. Генератор 1150 дополнительных полей включает в себя ассемблер 1200 общего медиазаголовка и ассемблер 1202 заголовка, учитывающего специфику медиа.
Формат дополнительных полей 1104 зависит от значения поля 1102 типа медиа. Ассемблер 1200 общего заголовка медиа формирует заголовок CMH (фиг.5А) в соответствии с элементами Таблицы 4. Ассемблер 1202 заголовка, отражающего специфику медиа, формирует заголовок MSH (фиг.5А) согласно элементам в Таблице 4. Общий формат полей заголовка для пакетов синхронизации, передающих медиакадры с видео, аудио или с синхронными данными, показан в Таблице 4.
Таблица 4Общий формат дополнительных полей заголовка уровня синхронизации для медиакадров
Имя поля
Тип поля
Присутствие поля
Общий медиазаголовок
Бит(22)
Обязательное
Имя поля
Тип поля
Присутствие поля
Заголовок, отражающий специфику медиа
Переменная
Условное
Общий формат полей заголовка для пакетов синхронизации, передающих кадры адаптации, показан в Таблице 5. На фиг.12В показан генератор 1160 типа адаптации, входящий в генератор 1110 заголовка синхронизации.
Таблица 5Общий формат дополнительных полей заголовка уровня синхронизации для кадров адаптации
Имя поля
Тип поля
Присутствие поля
ADAPTATION_TYPE
UINT(6)
Обязательное
Общий медиазаголовок
На фиг.13А показан ассемблер 1200 общего медиазаголовка. Ассемблер 1200 заголовка CMH включает в себя генератор 1302 отметки PTS, генератор 1304 идентификатора frame_id, генератор 1306 флага information_level_flag и генератор 1308 флага RAP_flag. Формат общего медиазаголовка (CMH) для пакетов уровня синхронизации, несущих медикадры, показан в Таблице 6. Общий медиазаголовок (CMH) предоставляет различную информацию. Информация CMH включает в себя: 1) информацию об отметках времени и ID медиакадра; 2) точки произвольного доступа в непрерывном потоке данных. Это поддерживает быстрый захват аудио- и видеопотоков и потока с синхронным текстом. Информация CMH также включает в себя: 3) индикацию не опорных кадров. Это позволяет в некоторых обстоятельствах отбрасывать медиакадры без их обработки (например, быстрая прокрутка вперед). Информация CMH также включает в себя: 4) индикатор уровня качества.
Формат общего медиазаголовка, создаваемого ассемблером 1200 общего медиазаголовка, показан в Таблице 6
Таблица 6Формат общего медиазаголовка
Имя поля
Тип поля
Присутствие поля
PTS
UINT(14)
Обязательное
FRAME_ID
UINT(6)
Обязательное
INAORMATION_LEVEL_FLAG
Бит(1)
Обязательное
RAP_FLAG
Бит(1)
Обязательное
Отдельные поля заголовка CMH определены ниже.
Поле PTS
Поле PTS является отметкой времени представления медиакадра, которая создается генератором 1302 PTS. Это поле задается в миллисекундах. Поле PTS добавляется к времени суперкадра для получения действительного момента времени представления медиакадра.
FRAME_ID
FRAME_ID представляет собой номер медиакадра в суперкадре, который создается генератором 1304 frame_id. Этот номер устанавливают равным 0 для первого медиакадра в суперкадре и увеличивают на единицу для каждого последующего медиакадра, который имеет другое значение для PTS.
INFORMATION_LEVEL_FLAG
INFORMATION_LEVEL_FLAG представляет собой бит, который указывает, несет ли медиакадр существенную информацию для этого медиакадра или дополнительную информацию, которую можно получить с помощью существенной информации. INFORMATION_LEVEL_FLAG создается генератором 1306 флага information_level_flag. Генератор 1306 создает INFORMATION_LEVEL_FLAG согласно следующим условиям. Если медиакадр несет существенную информацию (условие 1), то INFORMATION_LEVEL_FLAG может быть установлен равным 0. Если медиакадр несет дополнительный признак (условие 2), INFORMATION_LEVEL_FLAG может быть установлен равным 1. Если медиакодек не поддерживает уровень дополнительной информации (условие 3), то INFORMATION_LEVEL_FLAG может быть установлен равным 0, и это поле может быть проигнорировано устройством.
RAP_FLAG
Флаг RAP_FLAG сигнализирует о том, является ли медиакадр точкой произвольного доступа; при этом он создается генератором 1308 RAP_flag. Устройство 304 может использовать RAP_FLAG во время повторного захвата или переключения каналов, чтобы определить, можно ли начинать доступ к медиапотоку с указанным медикадром. Генератор 1308 RAP_flag создает RAP_FLAG согласно следующим условиям. Если (условие 1) MEDIA_TYPE установлен равным VIDEO или AUDIO и если данный медиакадр является точкой произвольного доступа, то RAP_FLAG может быть установлен равным 1. Если (условие 2) MEDIA_TYPE установлен равным VIDEO или AUDIO и если данный медиакадр не является точкой произвольного доступа, то RAP_FLAG может быть установлен равным 0. Если (условие 3) MEDIA_TYPE установлен равным TIMED_DATA, то RAP_FLAG может быть установлен равным 1 во всех медиакадрах.
Заголовки, отражающие специфику медиа
На фиг.13В показан ассемблер 1202 заголовка, отражающего специфику медиа. Ассемблер 1202 заголовка, отражающего специфику медиа (MSH), формирует форматы заголовка, отражающего специфику медиа (фиг.5А), для пакетов уровня синхронизации, несущих медиакадр, в соответствии с типом медиа. Типами медиа являются аудио, видео, синхронные данные и адаптация. Ассемблер 1202 заголовка MSH включает в себя генератор 1322 частоты кадров, генератор 1324 флага unreferenced_frame_flag и генератор 1326 резервного поля для типа медиа, предназначенного для видео.
Видео
Заголовок, отражающий специфику медиа (MSH), для пакетов уровня синхронизации, несущих медиакадры с видео, является медиазаголовком для видео. Формат медиазаголовка для видео задан в Таблице 7.
Таблица 7Медиазаголовок для видео
Имя поля
Тип поля
Присутствие поля
FRAME_RATE
UINT (3)
Обязательное
UNREFERENCED_FRAME_FLAG
Бит(1)
Обязательное
Зарезервировано
UINT(4)
Обязательное
Отдельные поля медиазаголовка для видео определены ниже.
FRAME_RATE
Поле FRAME_RATE представляет частоту, с которой кадры создаются сетью, причем это поле создается генератором 1322 частоты кадров в соответствии со значениями в Таблице 8. Значения, определенные для FRAME_RATE, показаны в Таблице 8.
Таблица 8Значения, определенные для FRAME_RATE
Частота кадров (кадров в секунду)
Значение
2400/1001 (23,976)
000
24
001
25
010
30000/1001 (29,97)
011
30
100
50
101
60000/1001 (59,94)
110
60
111
Частота FRAME_RATE представляет собой номинальную частоту отображения (кадров в секунду) при приеме полного видеопотока. Например, если видеопоток посылается с использованием как базового уровня, так и уровня улучшения, то FRAME_RATE является частотой после того, как оба потока данных полностью декодированы. Действительные частоты отображения могут отличаться друг от друга. Например, устройство, принимающее только базовый уровень передачи, может отображать кадры с пониженной частотой.
UNREFERENCED_FRAME_FLAG
Флаг UNREFERENCED_FRAME_FLAG представляет собой бит, который указывает, используется ли медиакадр в качестве опорного для восстановления других медиакадров, причем этот флаг создается генератором 1324 флага unreferenced_frame_flag. Генератор 1324 создает UNREFERENCED_FRAME_FLAG на основе следующих условий. Если медиакадр является опорным кадром (условие 1), то UNREFERENCED_FRAME_FLAG может быть установлен равным 0. Если медиакадр не является опорным кадром (условие 2), то UNREFERENCED_FRAME_FLAG может быть установлен равным 1.
RESERVED (зарезервировано)
Значение битов RESERVED может быть установлено равным 0, причем это значение создается генератором 1326 резервного поля, когда это необходимо.
Аудио
Ассемблер 1202 заголовка, отражающего специфику медиа, не создает заголовок, отражающий специфику медиа, для пакетов уровня синхронизации, несущих медиакадры с аудиоданными. Тем не менее, ассемблер 1202 заголовка, отражающего специфику медиа, может быть модифицирован, чтобы обеспечить указанный заголовок MSH для аудио.
Синхронные данные
Ассемблер 1202 заголовка, отражающего специфику медиа, включает в себя генератор 1332 timed_data_type. Заголовок, отражающий специфику медиа, для пакетов уровня синхронизации, несущих медиакадры с синхронными данными, представляет собой медиазаголовок синхронных данных. Формат медиазаголовка синхронных данных, создаваемый генератором 1332 timed_data_type, показан в таблице 9.
Таблица 9Формат медиазаголовка синхронных данных
Имя поля
Тип поля
Присутствие поля
TIMED_DATA_TYPE
UINT(8)
Обязательное
TIMED_DATA_TYPE
Поле TIMED_DATA_TYPE идентифицирует конкретный тип данных в медиакадре TIMED_DATA, причем оно создается генератором 1332 timed_data_type. Значения, определенные для TIMED_DATA_TYPE, заданы в Таблице 10.
Таблица 10Значения, определенные для TIMED_DATA_TYPE
Имя
Значение
charACTER_TEXT
0
Значения с 1 по 256 зарезервированы
ADAPTATION_TIPE
На фиг.12В показан генератор 1160 типа адаптации, входящий в генератор 1110 заголовка синхронизации. Генератор 1160 типа адаптации включает в себя ассемблер 1220 каталога video_sync_layer. Поле ADAPTATION_TIPE задает тип данных адаптации в кадре адаптации. Значения, определенные для поля ADAPTATION_TIPE, заданы в Таблице 11.
Таблица 11Значения, определенные для ADAPTATION_TIPE
Имя
Значение
video_sync_layer_directory
1
Все другие значения зарезервированы
Кадры адаптации
Структура тела кадра адаптации (например, 508) зависит от типа адаптации. Тело кадра адаптации для каждого типа адаптации задано в Таблице 11 и описано ниже.
Каталог уровня синхронизации видео (VSL)
Ассемблер 1220 каталога video_sync_layer создает каталог уровня синхронизации видео, который является необязательным кадром адаптации и может быть использован уровнем 406 синхронизации в устройстве, чтобы содействовать устранению ошибок, выполняемому видеокодеком. Например, он позволяет уровню 406 синхронизации определить, предназначался ли потерянный или поврежденный кадр в качестве опорного кадра. Информация об этом позволяет видеокодеку решить, следует ли обрабатывать последующие кадры вплоть до очередного опорного кадра или их надо отбросить.
Ассемблер 1160 каталога video_sync_layer, показанный на фиг.14, включает в себя модуль 1402 записей VSL_records, модуль 1412 бит RAP_flag_bits, модуль 1422 бит U_frame_flag_bits и резервный модуль 1432 для создания и формирования каталога video_sync_layer. Каталог video_sync_layer, если он имеется, может транспортироваться в виде кадра адаптации уровня синхронизации в компоненте базового уровня потока, транспортирующего видео, для которого он применяется. Этот каталог следует передавать по меньшей мере один раз в течение суперкадра. Формат каталога video_sync_layer задан в Таблице 12.
Таблица 12Каталог уровня синхронизации видео (VSL)
Имя поля
Тип поля
Присутствие поля
VSL_RECORDS
VSL_RECORD_TYPE
Обязательное
RAP-FLAG_BITS
BIT(60)
Обязательное
U_FRAME_FLAG_BITS
BIT(60)
Обязательное
Зарезервировано
BIT(переменная)
Условное
VSL_RECORD
На фиг.15 показан модуль 1402 записи VSL. Модуль 1402 записи VSL включает в себя модуль 1502 more_VSL_records, модуль 1504 frame_rate, модуль 1506 num_frames, модуль 1508 first_frame_PTS и модуль 1510 last_frame_PTS.
Модуль 1502 more_VSL_records может создавать и формировать одну или несколько записей VSL_RECORD для каталога. Формат VSL_RECORD задан в Таблице 13.
Таблица 13Формат VSL_RECORD
Имя поля
Тип поля
Присутствие поля
MORE_VSL_RECORDS
Бит(1)
Обязательное
FRAME_RATE
UINT(3)
Обязательное
NUM_FRAMES
UINT(6)
Обязательное
FIRST_FRAME_PTS
UINT(14)
Обязательное
LAST_FRAME_PTS
UINT(14)
Обязательное
MORE_VSL_RECORDS
Модуль 1502 more_VSL_records создает флаг MORE_VSL_RECORDS, который может быть установлен равным 0, если текущая запись VSL_RECORD является последней в каталоге уровня синхронизации видео.
Модуль 1502 more_VSL_records создает флаг MORE_VSL_RECORDS, который может быть установлен равным 1, если текущая запись VSL_RECORD не является последней в каталоге уровня синхронизации видео.
Количество записей VSL_RECORD в каталоге уровня синхронизации видео может быть на 1 больше, чем количество изменений номинальной частоты видеокадров в суперкадре.
FRAME_RATE
Модуль 1504 frame_rate создает и формирует поле FRAME_RATE, которое обеспечивает информацию о частоте кадров, используемую в записи VSL_RECORD. Таблица 8 задает значения, определенные для поля FRAME_RATE.
NUM_FRAMES
Модуль 1506 num_frames создает поле NUM_FRAMES, которое указывает количество медиакадров видео с разными значениями ID кадра с частотой кадров, заданной полем FRAME_RATE, в блоке последовательных медиакадров видео, начиная с FIRST_FRAME_PTS в суперкадре.
FIRST_FRAME_PTS
Модуль 1508 first_frame_PTS создает отметку времени FIRST_FRAME_PTS, которая является PTS первого медиакадра видео в блоке последовательных медиакадров видео с частотой кадров, задаваемой параметром FRAME_RATE.
LAST_FRAME_PTS
Модуль 1510 last_frame_PTS создает и формирует LAST_FRAME_PTS, которая является отметкой PTS последнего медиакадра видео в блоке последовательных медиакадров видео с частотой, задаваемой параметром FRAME_RATE, начиная с FIRST_FRAME_PTS.
RAP_FLAG_BITS
Модуль 1412 RAP_flag_bits создает биты RAP_FLAG_BITS. Каталог уровня синхронизации видео содержит 60 RAP_FLAG_BITS в соответствии с максимальным количеством медиакадров видео, равным 60, в суперкадре. Каждый бит поля RAP_FLAG_BITS соответствует конкретному медиакадру видео, определяемому ID кадра вплоть до значения, равного количеству отдельных видеокадров видео в суперкадре. Младший значащий бит соответствует первому медиакадру видео, покрываемому первой записью VSL_RECORD. За битами RAP_FLAG_BITS, покрываемыми первой записью VSL_RECORD, следуют биты RAP_FLAG_BITS, покрываемые второй и последующими записями VSL_RECORD, если они имеются, в порядке их передачи.
Каждый бит в поле RAP_FLAG_BITS каталога уровня синхронизации видео может быть установлен равным 1, если соответствующий медиакадр видео является точкой произвольного доступа и не сопровождается кадром, не являющимся RAP-кадром с тем же ID кадра. В противном случае, этот бит устанавливают равным 0. Биты, следующие за битом в RAP_FLAG_BITS, который соответствует последнему переданному медиакадру видео в суперкадре, могут быть установлены равными 0.
U_FRAME_FLAG_BITS
Модуль 1422 U_frame_flag_bits создает сообщение, содержащее 60 бит U_FRAME_FLAG_BITS в соответствии с максимальным количеством медиакадров видео, равным 60 в суперкадре. Каждый бит поля U_FRAME_FLAG_BITS соответствует конкретному медиакадру видео, идентифицируемому идентификатором кадра вплоть до значения, равного количеству отдельных медиакадров видео в суперкадре. Младший значащий бит соответствует первому медиакадру видео, покрываемому первой записью VSL_RECORD. За битами U_FRAME_FLAG_BITS, покрываемыми первой записью VSL_RECORD, следуют биты U_FRAME_FLAG_BITS, покрываемые второй и последующими записями VSL_RECORD, если они имеются, в порядке их передачи.
Каждый бит в поле U_FRAME_FLAG_BITS каталога уровня синхронизации видео может быть установлен равным 1, если соответствующий видеокадр не является опорным кадром. В противном случае, этот бит устанавливают равным 0. Биты, следующие за битом в U_FRAME_FLAG_BITS, который соответствует последнему переданному кадру в суперкадре, могут быть установлены равными 0.
RESERVED
За полем U_FRAME_FLAG_BIT следует минимальное количество зарезервированных бит (RESERVED), созданных модулем 1432 резервирования, которые необходимы для выравнивания последнего байта каталога синхронизации видео по границе байта. Сеть может установить резервные биты в каталоге синхронизации видео равными 0.
Специалистам в данной области техники очевидно, что информация и сигналы могут быть представлены с использованием любой из множества различных технологий и способов. Например, данные, инструкции, команды, информация, сигналы, биты, символы и элементарные посылки, на которые возможны ссылки по всему вышеприведенному описанию, могут быть представлены напряжениями, токами, электромагнитными волнами, магнитными полями или частицами, оптическими полями или частицами или любой их комбинацией.
Кроме того, специалистам в данной области техники ясно, что различные иллюстративные логические блоки, модули и алгоритмические шаги, описанные в связи с раскрытыми здесь примерами, могут быть реализованы в виде электронных аппаратных средств, программно-аппаратных средств, компьютерного программного обеспечения, межплатформенного программного обеспечения, микрокода или их комбинации. Чтобы наглядно проиллюстрировать эту взаимозаменяемость аппаратных и программных средств, различные иллюстративные компоненты, блоки, модули, схемы и шаги были описаны выше с точки зрения их функциональных возможностей. То, какими средствами: аппаратными или программными, реализуются эти функциональные возможности, зависит от конкретного приложения и проектных ограничений, накладываемых на систему в целом. Специалисты в данной области техники могут реализовать описанные функциональные возможности различными путями для каждого конкретного приложения, но такие решения по их реализации не должны интерпретироваться как выход за рамки объема раскрытых здесь способов.
Различные иллюстративные логические блоки, компоненты, модули и схемы, описанные в связи с раскрытыми здесь примерами, могут быть реализованы или выполнены с помощью процессора общего назначения, цифрового процессора сигналов (DSP), специализированной прикладной интегральной схемы (ASIC), вентильной матрицы, программируемой пользователем (FPGA), или другим программируемым логическим устройством, дискретной вентильной или транзисторной логики, дискретных аппаратных компонент или любой их комбинации, предназначенной для выполнения описанных здесь функций. Процессором общего назначения может быть микропроцессор, но в альтернативном варианте процессор может представлять собой любой известный процессор, контроллер, микроконтроллер или конечный автомат. Процессор также может быть реализован в виде комбинации вычислительных устройств, например комбинации процессора DSP и микропроцессора, множества микропроцессоров, одного или нескольких микропроцессоров в сочетании с ядром DSP или любой другой указанной конфигурации.
Блоки способа или алгоритма, описанного в связи с раскрытыми здесь примерами, могут быть непосредственно воплощены в аппаратных средствах, в одном или нескольких программных модулях, выполняемых одним или несколькими обрабатывающими элементами, или в комбинации того и другого. Программный модуль может находиться в ОЗУ (RAM), флэш-памяти, ПЗУ (ROM), стираемом программируемом ПЗУ (EPROM), электрически стираемом программируемом ПЗУ (EEPROM), регистрах, жестком диске, съемном диске, ПЗУ на компакт-диске (CD-ROM) или любой другой форме или комбинации носителей хранения, известных в данной области техники. Иллюстративный носитель хранения связан с процессором таким образом, чтобы процессор мог считывать с него информацию и записывать информацию на него. В альтернативном варианте носитель хранения может составлять с процессором единое целое. Процессор и носитель хранения могут находиться в прикладной специализированной интегральной схеме (ASIC). Схема ASIC может находиться в беспроводном модеме. В альтернативном варианте процессор и носитель хранения могут находиться в беспроводном модеме в виде дискретных компонент.
В одной или нескольких примерных конфигурациях описанные здесь функции могут быть реализованы аппаратными средствами, программными средствами, аппаратно-программными средствами или любой их комбинацией. При реализации программными средствами эти функции могут запоминаться или передаваться в виде одной или нескольких команд или кода на считываемой компьютером среде. Считываемый компьютером носитель включает в себя как машиночитаемый носитель, так и среду связи, в том числе любой носитель, который обеспечивает возможность пересылки компьютерной программы из одного места в другое. Носители хранения могут представлять собой любые доступные носители, к которым может получать доступ компьютер. Например, но не как ограничение, указанные машиночитаемые носители могут содержать ОЗУ, ПЗУ, электрически стираемое ППЗУ, ПЗУ на компакт диске или другое запоминающее устройство на оптическом диске, запоминающее устройство на магнитном диске или иные магнитные запоминающие устройства, либо любой другой носитель, который можно использовать для транспортировки или запоминания необходимого программного кода в виде команд или структур данных и который может быть доступен компьютеру. Также машиночитаемым носителем может быть названо любое соединение. Например, если программное обеспечение передается из Web-сайта, сервера или другого удаленного источника с использованием коаксиального кабеля, оптоволоконного кабеля, скрученной пары, цифровой абонентской линии (DSL) или беспроводных технологий, таких как инфракрасная, радио и микроволновая связь, то тогда коаксиальный кабель, волоконно-оптический кабель, скрученная пара, линия DSL или беспроводные технологии, такие как инфракрасная, радио и микроволновая связь, входят в определение носителя. Используемый здесь термин «диск» включает в себя компакт-диск (CD), лазерный диск, оптический диск, цифровой универсальный диск (DVD), гибкий диск и лазерный диск в синем диапазоне спектра, причем диски (disks) обычно воспроизводят данные на основе магнитных явлений, в то время как диски (discs) воспроизводят данные с помощью оптических лазеров. В объем понятия «машиночитаемый носитель» следует также включать комбинации из вышеописанного.
Приведенное выше описание раскрытых здесь примеров предложено для того, чтобы дать возможность специалистам в данной области техники выполнить или использовать раскрытые способы и устройство. Специалисты в данной области техники без труда предложат различные модификации этих примеров, при этом определенные здесь принципы можно применить к другим примерам, а также в них могут быть внесены дополнительные элементы.