УСТРОЙСТВО ОБРАБОТКИ ИНФОРМАЦИИ, СПОСОБ ОБРАБОТКИ ИНФОРМАЦИИ, ПРОГРАММА И НОСИТЕЛЬ ЗАПИСИ

Область техники, к которой относится изобретение

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

Уровень техники

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

Для представления 3D-изображения необходимо специальное устройство. Примером такого устройства является 3D-видеосистема IP (интегральная фотография) 3D, разработанная компанией NHK (Японская радиовещательная корпорация).

Видеоданные 3D-изображения включают видеоданные, получаемые на основе мультивидовых видеоданных (видеоданные изображений, фиксируемых с нескольких точек зрения). При увеличении числа точек зрения и распределении этих точек зрения в области большего размера предмет можно рассматривать с нескольких разных направлений. Таким образом, можно реализовать так называемое «телевидение изнутри» ("look-in TV").

Из всей совокупности видов 3D-изображений минимальным числом точек зрения обладает стереоизображение, имеющее две точки зрения (так называемое 3D-изображение). Видеоданные стереоизображения включают данные левого изображения для наблюдения левым глазом и данные правого изображения для наблюдения правым глазом.

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

К примерам таких носителей записи большой емкости относятся диски «Блю-рей» (Blu-Ray (R)) (далее именуемые также "BD"), такие как BD-ROM (Блю-рей (R))-(постоянное запоминающее устройство).

Однако в стандарте BD не определен способ записи и воспроизведения видеоданных 3D-изображения, включая стереоизображения.

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

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

Из уровня техники известен патентный документ WO 2007/047736 (PTL 2), в котором в поток мультивидовых видеоданных вставлено сообщение с дополнительной информацией для улучшения (SEI), которое содержит флаг, указывающий, какой из потоков - базовый или дополнительный поток - является потоком для левого изображения, а какой - потоком правого изображения.

Список литературы

Патентная литература

PTL 1: Публикация нерассмотренной Заявки на патент Японии No. 2007-095249

PTL 2: Публикация заявки РСТ WO 2007/047736.

Сущность изобретения

Техническая проблема

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

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

Решение проблемы

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

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

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

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

Преимущества изобретения

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

Краткое описание чертежей

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

Фиг. 2 иллюстрирует пример фиксации изображения.

Фиг. 3 представляет блок-схему, иллюстрирующую пример конфигурации кодирующего устройства для мультивидового видеокодирования (MVC).

Фиг. 4 иллюстрирует пример опорного изображения.

Фиг. 5 иллюстрирует пример управления аудиовизуальным (AV) потоком.

Фиг. 6 иллюстрирует структуры Главного пути и Дополнительного пути.

Фиг. 7 иллюстрирует пример структуры управления файлом, записанным на оптическом диске.

Фиг. 8 иллюстрирует синтаксис файла PlayList.

Фиг. 9 иллюстрирует синтаксис записи SubPath(), показанной на фиг. 8.

Фиг. 10 иллюстрирует пример параметра SubPath_type.

Фиг. 11 иллюстрирует синтаксис записи SubPlayItem(i), показанной на фиг. 9.

Фиг. 12 иллюстрирует синтаксис записи PlayItem(), показанной на фиг. 8.

Фиг. 13 иллюстрирует синтаксис таблицы STN_table(), показанной на фиг. 12.

Фиг. 14 иллюстрирует пример параметра application_type.

Фиг. 15 иллюстрирует пример установки параметров application_type и SubPath_type.

Фиг. 16 иллюстрирует другой пример установки параметров application_type и SubPath_type.

Фиг. 17 иллюстрирует еще один пример установки параметров application_type и SubPath_type.

Фиг. 18 иллюстрирует пример задания параметра stream_id с использованием приложения Java (зарегистрированный товарный знак).

Фиг. 19 иллюстрирует синтаксис файла PlayList.

Фиг. 20 иллюстрирует использование параметра reserved_for_future_use, показанного на фиг. 19.

Фиг. 21 иллюстрирует смысл величин параметра 3D_PL_type.

Фиг. 22 иллюстрирует смысл величин параметра view_type.

Фиг. 23 представляет блок-схему примера конфигурации устройства воспроизведения.

Фиг. 24 иллюстрирует пример конфигурации декодера, показанного на фиг. 23.

Фиг. 25 иллюстрирует структуру для обработки потока видеоданных.

Фиг. 26 иллюстрирует пример блока доступа.

Фиг. 27 предлагает блок-схему примера конфигурации модуля обработки программы.

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

Фиг. 29 иллюстрирует пример, в котором параметр view_type записан в таблице РМТ.

Фиг. 30 иллюстрирует пример, в котором параметр view_type записан в элементарном потоке.

Фиг. 31 иллюстрирует структуру блока доступа.

Фиг. 32 представляет блок-схему примера конфигурации аппаратуры компьютера.

Описание вариантов осуществления

ПРИМЕР КОНФИГУРАЦИИ СИСТЕМЫ ВОСПРОИЗВЕДЕНИЯ

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

Как показано на фиг. 1, система воспроизведения включает устройство 1 воспроизведения и дисплей 3, соединенные одно с другим с использованием, например, кабеля HDMI (мультимедийный интерфейс высокой четкости). В устройстве 1 воспроизведения установлен оптический диск 2, например BD.

На оптическом диске 2 записаны потоки, необходимые для представления на дисплее стереоизображения, имеющего две точки зрения (в большинстве случаев именуется или "3D-изображение").

Устройство 1 воспроизведения служит плеером для воспроизведения 3D-изображения на основе потоков, записанных на оптическом диске 2. Устройство 1 воспроизведения осуществляет воспроизведение потоков, записанных на оптическом диске 2, и управляет дисплеем 3, таким как телевизионный приемник, для представления воспроизводимого 3D-изображения на экране дисплея. Аналогично устройство 1 воспроизведения осуществляет воспроизведение звука и передает его через, например, громкоговоритель, входящий в состав дисплея 3.

Для представления 3D-изображений на дисплее были разработаны разнообразные способы. В настоящем примере для представления 3D-изображений на дисплее используют приведенные далее способы типа 1 и типа 2.

При использовании для представления изображения на дисплее способа типа 1 данные 3D-изображения включают данные изображений, наблюдаемых левым глазом (L-изображения), и данные изображений, наблюдаемых правым глазом (R-изображений). В этом случае 3D-изображение представляют на дисплее путем поочередного представления L-изображений и R-изображений на этом дисплее.

При использовании для представления изображения на дисплее способа типа 2 3D-изображение, представляют на дисплее посредством L-изображений и R-изображений, генерируемых с использованием данных исходного изображения (т.е. изображения, на основе которого нужно создать 3D-изображение) и данных глубины (Depth). Данные 3D-изображения, используемые способом типа 2 для представления изображения на дисплее, включают данные исходного изображения и данные глубины. Применение данных Depth глубины к исходному изображению дает возможность генерировать L-изображения и R-изображения.

При представлении изображения на дисплее способом типа 1 пользователю для просмотра 3D-изображения необходимы специальные очки. Однако при представлении изображения на дисплее способом типа 2 пользователь может просматривать 3D-изображения без очков.

Оптический диск 2 включает поток данных, на основе которого можно представлять 3D-изображения на дисплее с использованием любого способа представления изображения на дисплее - типа 1 или типа 2.

В качестве способа кодирования для записи такого потока данных на оптическом диске 2 применяют, например, способ согласно стандарту Н.264 AVC (Усовершенствованное видеокодирование (Advanced Video Coding))/MVC (Мультивидовое видеокодирование (Multi-view Video Coding)) Profile.

Стандарт H.264 AVC/MVC Profile

В стандарте H.264 AVC/MVC Profile определены поток данных изображения, именуемый «Базовый поток видеоданных» ("Base view video"), и поток данных изображения, именуемый «Зависимый поток видеоданных» ("Dependent view video"). В дальнейшем стандарт H.264 AVC/MVC Profile будет, где это возможно, называться просто "MVC".

Фиг. 2 иллюстрирует фиксацию изображения.

Как показано на фиг. 2, изображение одного и того же предмета фиксируют камерой для L-изображений и камерой для R-изображений. Элементарные потоки видеоданных, фиксируемые камерой для L-изображений и камерой для R-изображений, поступают на входы кодирующего устройства стандарта MVC.

Фиг. 3 представляет блок-схему, иллюстрирующую пример конфигурации кодирующего устройства для мультивидового видеокодирования (стандарт MVC).

Как показано на фиг. 3 кодирующее устройство 11 стандарта MVC включает кодирующее устройство 21 стандарта H.264/AVC, декодер 22 стандарта H.264/AVC, блок 23 вычисления глубины (Depth), кодирующее устройство 24 для зависимого потока видеоданных и мультиплексор 25.

Поток видеоданных video #1, фиксируемый камерой для L-изображений, поступает в кодирующее устройство 21 стандарта H.264/AVC и блок 23 вычисления глубины. В дополнение к этому поток видеоданных #2, фиксируемый камерой для R-изображений, поступает в блок 23 вычисления глубины и в кодирующее устройство 24 для зависимого потока видеоданных. В альтернативном варианте поток video #2 может быть введен в кодирующее устройство 21 стандарта H.264/AVC и блок 23 вычисления глубины, а поток video #1 может быть введен в блок 23 вычисления глубины и в кодирующее устройство 24 для зависимого потока видеоданных.

Кодирующее устройство 21 стандарта H.264/AVC кодирует поток video #1 и преобразует его тем самым в, например, поток видеоданных H.264 AVC/High Profile. Это кодирующее устройство 21 стандарта H.264/AVC передает кодированный AVC-поток видеоданных в декодер 22 стандарта H.264/AVC и в мультиплексор 25 в виде базового потока видеоданных.

Декодер 22 стандарта H.264/AVC декодирует AVC-поток видеоданных, поступающий от кодирующего устройства 21 стандарта H.264/AVC, и передает полученный в результате декодирования поток video #1 в кодирующее устройство 24 для зависимого потока видеоданных.

Блок 23 вычисления глубины вычисляет глубину Depth на основе потока video #1 и потока video #2 и передает вычисленную глубину Depth в мультиплексор 25.

Кодирующее устройство 24 для зависимого потока видеоданных кодирует поток video #1, поступающий от декодера 22 стандарта H.264/AVC, и поток video #2, поступающий извне, и передает в виде зависимого потока видеоданных.

Применение кодирования с предсказанием, согласно которому в качестве опорного изображения используется другой поток, для базового потока видеоданных не допускается. Однако, как показано на фиг. 4, допускается кодирование с прогнозированием зависимого потока видеоданных, используя базовый поток видеоданных в качестве опорного изображения. Например, в варианте кодирования, когда L-изображение служит базовым потоком видеоданных, а R-изображение используется в качестве зависимого потока видеоданных, объем данных в полученном зависимом потоке видеоданных меньше, чем в полученном базовом потоке видеоданных.

Отметим, что поскольку кодирование осуществляется с использованием стандарта H.264/AVC, прогнозирование равным образом выполняется для базового потока видеоданных в направлении оси времени. Более того, для зависимого потока видеоданных выполняют прогнозирование в направлении оси времени в дополнение к прогнозированию между видами. Поэтому для декодирования зависимого потока видеоданных сначала необходимо декодировать соответствующий базовый поток видеоданных, который был использован в качестве опорного потока во время кодирования.

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

Мультиплексор 25 осуществляет мультиплексирование базового потока видеоданных, поступающего от кодирующего устройства 21 стандарта H.264/AVC, зависимого потока видеоданных (данные, относящиеся к глубине Depth), поступающего от блока 23 вычисления глубины, и зависимого потока видеоданных, поступающего от кодирующего устройства 24 для зависимого потока видеоданных, в виде, например, транспортного потока MPEG2 TS. Базовый поток видеоданных и зависимый поток видеоданных могут быть мультиплексированы в одном транспортном потоке MPEG2 TS. В альтернативном варианте эти базовый поток видеоданных и зависимый поток видеоданных могут быть включены в разные транспортные потоки MPEG2 TS.

Мультиплексор 25 передает на выход сформированный им транспортный поток TS (MPEG2 TS). Этот транспортный поток TS с выхода мультиплексора 25 записывают на оптическом диске 2 посредством устройства записи вместе с дополнительными данными управления. Оптический диск 2 с записанными на нем такими данными передают в устройство 1 воспроизведения.

Если зависимый поток видеоданных, используемый вместе с базовым потоком видеоданных согласно способу отображения типа 1, нужно отличить от зависимого потока видеоданных (данные глубины Depth), используемого вместе с базовым потоком видеоданных согласно способу отображения типа 2, первый из указанных зависимых потоков обозначается «зависимый поток D1» ("D1 view video"), а последний обозначается «зависимый поток D2» ("D2 view video").

Кроме того, процесс воспроизведения 3D-изображения с использованием способа отображения типа 1 на основе базового потока видеоданных и зависимого потока D1 обозначается «воспроизведение B-D1» ("B-D1 reproduction"). Процесс воспроизведения 3D-изображения с использованием способа отображения типа 2 на основе базового потока видеоданных и зависимого потока D2 обозначается «воспроизведение B-D2» ("B-D2 reproduction").

Когда устройство 1 воспроизведения осуществляет воспроизведение B-D1 в ответ на, например, команду пользователя, это устройство 1 воспроизведения считывает базовый поток видеоданных и зависимый поток D1 с оптического диска 2 и воспроизводит эти базовый поток видеоданных и зависимый поток D1.

В дополнение к этому, когда устройство 1 воспроизведения осуществляет воспроизведение B-D2, это устройство 1 воспроизведения считывает базовый поток видеоданных и зависимый поток D2 с оптического диска 2 и воспроизводит эти базовый поток видеоданных и зависимый поток D2.

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

Базовый поток видеоданных представляет собой AVC-поток видеоданных, кодированный с использованием стандарта H.264/AVC. Соответственно любой плеер, поддерживающий формат BD, может воспроизводить базовый поток видеоданных и может представлять на дисплее 2D-изображение.

Ниже рассмотрен главным образом случай, когда зависимый поток видеоданных представляет зависимый поток D1. В последующем описании термин «Зависимый поток видеоданных» обозначает зависимый поток D1. Как и поток D1, зависимый поток D2 также записывают на оптическом диске 2 и воспроизводят с этого диска.

Формат приложения

Фиг. 5 иллюстрирует пример управления AV-потоком, осуществляемого устройством 1 воспроизведения.

Как показано на фиг. 5, управление AV-потоком осуществляется с использованием двух уровней: Playlist и Clip. Такой AV-поток может быть записан в локальной памяти устройства 1 воспроизведения в дополнение к оптическому диску 2.

Здесь пара, составленная из AV-потока и информации о Клипе (Clip Information), сопровождаемой этим AV-потоком, считается объектом. Этот объект именуется «Клип» ("Clip"). В последующем файл, где записан AV-поток, называется «файл AV-потока» ("AV stream file"). Кроме того, файл, где записана информация о Клипе, называется «файл информации о Клипе» ("Clip Information file").

AV-поток развернут по оси времени. В общем случае точку доступа к каждому Клипу указывают с использованием метки времени в списке Playlist. Файл информации о Клипе служит для определения адреса AV-потока, по которому должно начаться декодирование.

Список Playlist представляет набор интервалов AV-потока для воспроизведения. Один воспроизводимый интервал AV-потока именуется "PlayItem". Интервал PlayItem ограничен посредством пары, составленной из точки входа IN и точки выхода OUT для этого воспроизводимого интервала на оси времени. Как показано на фиг. 5 список PlayList включает один или несколько интервалов PlayItems.

Как показано на фиг. 5, первый список PlayList слева включает два интервала PlayItems. Эти два интервала PlayItems относятся к первой половине и ко второй половине AV-потока, включенного в левый Клип.

Второй список PlayList слева включает один интервал PlayItem. Этот интервал PlayItem относится ко всему AV-потоку, включенному в правый Клип.

Третий список PlayList слева включает два интервала PlayItems. Эти два интервала PlayItems относятся к части AV-потока, включенной в левый Клип, и части AV-потока, включенной в правый Клип.

Например, когда левый интервал PlayItem, включенный в первый список PlayList слева, задан программой навигации на диске в качестве точки воспроизведения, воспроизводится первая половина AV-потока, включенного в левый Клип, на который ссылается этот интервал PlayItem. Как описано выше, этот список PlayList используется в качестве информации управления воспроизведением, которая управляет воспроизведением AV-потоков.

В списке PlayList путь воспроизведения, образованный одним или несколькими смежными интервалами PlayItems, назван «Главный путь» ("Main Path").

Кроме того, в списке PlayList путь воспроизведения, образованный одним или несколькими смежными интервалами SubPlayItems и параллельный Главному пути, назван «Дополнительный путь» ("Sub Path").

Фиг. 6 иллюстрирует структуру Главного пути и Дополнительного пути.

Список PlayList может включать Главный путь (Main Path) и один или несколько Дополнительных путей (Sub Path).

Описанным выше базовым потоком видеоданных управляют как потоком, обозначенным в списке PlayList в качестве входящего в состав Главного пути. В дополнение к этому зависимым потоком видеоданных управляют как потоком, обозначенным в списке SubPlayList в качестве входящего в состав Дополнительного пути.

На фиг. 6 список PlayList включает один Главный путь, составленный из трех смежных интервалов PlayItems, и три Дополнительных пути.

Интервалам PlayItems, составляющим Главный путь, последовательно назначают идентификаторы (ID) начиная от указанного первого интервала PlayItem. Аналогично назначают последовательные идентификаторы ID Дополнительным путям начиная от первого Дополнительного пути, а именно Subpath_id=0, Subpath_id=1 и Subpath_id=2.

В примере, показанном на фиг. 6, Дополнительный путь, имеющий идентификатор Subpath_id=0, включает один интервал SubPlayItem, а Дополнительный путь, имеющий идентификатор Subpath_id=1, включает два интервала SubPlayItems. Далее, Дополнительный путь, имеющий идентификатор Subpath_id=2, включает один интервал SubPlayItem.

AV-поток Клипа, обозначенный интервалом PlayItem, включает по меньшей мере поток видеоданных (главные видеоданные).

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

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

Такой AV-поток Клипа может включать или не включать один или несколько потоков IG (Интерактивная графика) для воспроизведения синхронно с воспроизведением потока видеоданных, включенного в AV-поток Клипа. Этот IG-поток используется для представления на дисплее графики, такой как кнопки, на которые должен воздействовать пользователь.

В AV-потоке Клипа, на который ссылается один интервал PlayItem, мультиплексированы следующие потоки: поток видеоданных, ни одного, один или несколько аудиопотоков для воспроизведения синхронно с воспроизведением указанного потока видеоданных, ни одного, один или несколько презентационных PG-потоков и ни одного, один или несколько интерактивных IG-потоков.

Кроме того, интервал SubPlayItem ссылается, например, на поток видеоданных, аудиопоток или презентационный PG-поток из состава потока, отличного от AV-потока Клипа, указанного интервалом PlayItem (другой поток).

Такой способ управления AV-потоком с использованием списка PlayList и интервалов PlayItem и SubPlayItem описан в, например, публикациях нерассмотренных Заявок на патент Японии No. 2008-252740 и 2005-348314.

Структура каталогов

Фиг. 7 иллюстрирует пример управляющей структуры файла, записанного на оптическом диске 2.

Как показано на фиг. 7, файлами управляют иерархически с использованием структуры каталогов. На оптическом диске 2 создают один корневой каталог. Имея корневой каталог, можно управлять файлами посредством единой системы записи и воспроизведения.

Под корневым каталогом записывают каталог BDMV.

Непосредственно в каталог BDMV записывают индексный (Index) файл под именем "Index.bdmv" и файл MovieObject под именем "MovieObject.bdmv".

В каталог BDMV создают резервный каталог (BACKUP), директорий списков воспроизведения (PLAYLIST), каталог информации о Клипах (CLIPINF) и каталог потоков (STREAM).

В каталог списков PLAYLIST записаны файлы списков PlayList, каждый из которых включает список PlayList. Каждому файлу PlayList списков присвоено имя, составленное из 5-значного числа и расширения ".mpls". Файлу списков PlayList, показанному на фиг. 7, присвоено имя "00000.mpls".

В каталоге CLIPINF информации записаны файлы информации о Клипах. Каждому такому файлу информации о Клипах присвоено имя, составленное из 5-значного числа и расширения ".clipi".

На фиг. 7 три файла с информацией о клипах имеют имена "00001.clipi", "00002-clipi" и "00003.clipi". В последующем файл с информацией о клипе будет, где это возможно, именоваться «clpi-файл» ("dpi file").

Например, clpi-файл с именем "00001.clpi" включает информацию, относящуюся к Клипу базового потока видеоданных.

clpi-файл с именем "00002.clpi" включает информацию, относящуюся к Клипу видеоданных потока D2.

clpi-файл с именем "00003.clpi" включает информацию, относящуюся к Клипу видеоданных потока D1.

Файлы потоков записывают в каталог STREAM потоков. Каждому из файлов потоков присваивают имя, составленное из 5-значного числа и расширения ".m2ts" или из 5-значного числа и расширения ".ilvt". В последующем файл с расширением ".m2ts" будет, где это возможно, именоваться «m2ts-файл» ("m2ts file"). Кроме того, файл с расширением ".ilvt" будет, где это возможно, именоваться «ilvt-файл» ("ilvt file").

m2ts-файл с именем "00001.m2ts" представляет собой файл, используемый для воспроизведения 2D-изображения. При определении этого файла происходит считывание базового потока видеоданных.

m2ts-файл с именем "00002.m2ts" представляет собой файл, относящийся к потоку D2 видеоданных. m2ts-файл с именем "00003.m2ts" представляет собой файл, относящийся к потоку D1 видеоданных.

Ilvt-файл с именем "10000.ilvt" представляет собой файл, используемый для воспроизведения B-D1. При задании этого файла происходит считывание базового потока видеоданных и потока D1 видеоданных.

Ilvt-файл с именем "20000.ilvt" представляет собой файл, используемый для воспроизведения B-D2. При задании этого файла происходит считывание базового потока видеоданных и потока D2 видеоданных.

В дополнение к каталогам, показанным на фиг. 7, в каталоге BDMV создан каталог для хранения файла аудиопотоков.

Синтаксис каждого блока данных

Фиг. 8 иллюстрирует синтаксис записи PlayList(), присутствующей в файле списка PlayList.

Параметр «длина» ("length") обозначает не имеющее знака 32-битовое целое число, представляющее число байтов начиная от байта, следующего сразу же после поля длины, и до последнего байта в записи PlayList(). Таким образом, параметр «длина» представляет число байтов от «зарезервированных для использования в будущем» (reserved_for_future_use) до последнего байта списка PlayList.

Сразу же вслед за параметром «длина» расположены 16 бит, зарезервированных для использования в будущем (reserved_for_future_use).

16-битовое поле "number_of_PlayItems" (число интервалов) указывает число интервалов PlayItems, включенных в список PlayList. В примере, показанном на фиг. 6, число интервалов PlayItems равно трем. Каждый раз, когда запись PlayItem() появляется в списке PlayList, ее идентификатору PlayItem_id присваивают очередное последовательное значение начиная от «0». Например, на фиг. 6 идентификаторам присвоены значения PlayItem_id=0, 1 и 2.

16-битовое поле "number_of_SubPaths" (число Дополнительных путей) указывает число Дополнительных путей, включенных в список PlayList. В примере, приведенном на фиг. 6, число Дополнительных путей равно трем. Каждый раз, когда запись SubPath() появляется в списке PlayList, ей присваивают очередное последовательное значение начиная от «0». Например, на фиг. 6 идентификаторам присвоены значения PlayItem_id=0, 1 и 2. В последующем операторе "for" к PlayItem() обращаются число раз, равное числу интервалов PlayItems, а к SubPath() обозначаются число раз, равное числу Дополнительных путей.

Фиг. 9 иллюстрирует синтаксис записи SubPath(), показанной на фиг. 8.

Параметр «длина» ("length") обозначает не имеющее знака 32-битовое целое число, представляющее число байтов начиная от байта, следующего сразу же после поля длины, и до последнего байта в записи Sub Path(). Таким образом, параметр «длина» представляет число байтов от «зарезервированных для использования в будущем» (reserved_for_future_use) до последнего байта списка PlayList.

Сразу же вслед за параметром «длина» расположены 16 бит, зарезервированных для использования в будущем (reserved_for_future_use).

8-битовое поле "SubPath_type" (тип Дополнительного пути) указывает тип приложения, выполняющего обработку с использованием рассматриваемого Дополнительного пути. Например, параметр SubPath_type служит для указания, что представляет Дополнительный путь - «аудио» ("audio"), «растровые титры» ("bitmap caption") или «текстовые титры» ("text caption"). Параметр SubPath_type более подробно описан ниже со ссылками на фиг. 10.

Сразу же после параметра "SubPath_type" следуют 15 бит для использования в будущем (reserved_for_future_use).

1-битовое поле "is_repeat_SubPath" (повтор Дополнительного пути) указывает способ воспроизведения Дополнительного пути. Иными словами, это поле повтора "is_repeat_SubPath" указывает, происходит ли воспроизведение Дополнительного пути многократно или только один раз во время воспроизведения Главного пути. Например, такое поле повтора "is_repeat_SubPath" используется, если время, когда воспроизводится Клип, обозначенный Главным путем, отличается от времени, когда воспроизводится Клип, обозначенный Дополнительным путем, (например, когда Главный путь представляет путь слайд-шоу демонстрации неподвижных изображений, а Дополнительный путь представляет аудиопуть для музыкального сопровождения (BGM)).

Сразу же за параметром повтора "is_repeat_SubPath" следуют 8 бит для использования в будущем (reserved_for_future_use).

8-битовое поле "number_of_SubPlayItems" (число Дополнительных интервалов) указывает число таких интервалов SubPlayItems (число входов), включенных в Дополнительный путь. Например, на фиг. 6 параметр числа интервалов number_of_SubPlayItems для интервала SubPlayItem, имеющего идентификатор SubPath_id=0, равен единице, а параметр числа интервалов number_of_SubPlayItems для интервала SubPlayItem, имеющего идентификатор SubPath_id=1, равен двум. В дальнейшем, в операторе "for" запись SubPlayItem() обозначает число раз, равное числу Дополнительных интервалов SubPlayItems.

Фиг. 10 иллюстрирует пример параметра типа пути SubPath_type.

На фиг. 10 параметр "Out_of_mux" (внешнее мультиплексирование) указывает, что поток, обозначенный Дополнительным путем (поток, обозначенный дополнительным интервалом SubPlayItem, входящим в состав Дополнительного пути), и поток, обозначенный Главным путем (поток, обозначенный интервалом PlayItem, входящим в состав Главного пути) ,мультиплексированы в разные транспортные потоки TS.

Напротив, параметр "In_of_mux" (внутреннее мультиплексирование) указывает, что поток, обозначенный Дополнительным путем, и поток, обозначенный Главным путем, мультиплексированы в один и тот же транспортный поток TS.

Значения параметра типа SubPath_type=0 и SubPath_type=1 зарезервированы.

Параметр типа SubPath_type=2 указывает «Путь аудиопрезентации для просматриваемого слайд-шоу» ("Audio presentation path of the Browsable slide show").

Параметр типа SubPath_type=3 указывает «Меню презентации интерактивной графики» ("Interactive graphics presentation menu").

Параметр типа SubPath_type=4 указывает «Путь презентации текстовых субтитров» ("Text subtitle presentation path") (путь презентации текстовых титров).

Параметр типа SubPath_type=5 указывает «2-й путь аудиопрезентации» ("2nd Audio Presentation path") (путь для обозначения 2-го аудиопотока). Например, второй аудиопоток, обозначенный Дополнительным путем, имеющим параметр типа SubPath_type=5, служит комментариями (голосовыми) режиссера видео.

Параметр типа SubPath_type=6 указывает «2-й путь видеопрезентации» ("2nd Video Presentation path") (путь для обозначения 2-го видеопотока). Например, второй аудиопоток, обозначенный Дополнительным путем, имеющим параметр типа SubPath_type=6, служит комментариями (движущееся изображение) режиссера видео.

Параметр типа SubPath_type=7 указывает путь одного или нескольких элементарных потоков (ES) (Первичный аудио/PG/IG/Вторичный аудио) или путь презентации картинки-в-картинке.

Параметры типа с SubPath_type=8 по SubPath_type=11 определяют Дополнительные пути SubPaths для приложения, выполняющего воспроизведение 3D-изображения. В этом примере различные значения устанавливают в соответствии со структурой мультиплексирования зависимых потоков видеоданных, обозначенных параметром Subpath.

Параметр типа SubPath_type=8 указывает «внешнее мультиплексирование 3D SubPath с диска» ("Out-of-mux 3D SubPath from Disc"), что означает, что зависимый поток видеоданных, обозначенный Дополнительным путем, записан на оптическом диске 2 и мультиплексирован в составе транспортного потока TS, отличного от транспортного потока TS, в котором мультиплексирован базовый поток видеоданных, обозначенный Главным путем.

Параметр типа SubPath_type=9 указывает «внутреннее мультиплексирование 3D SubPath с диска» ("In-mux 3D SubPath from Disc"), что означает, что зависимый поток видеоданных, обозначенный Дополнительным путем, записан на оптическом диске 2 и мультиплексирован в составе того же самого транспортного потока TS, в котором мультиплексирован базовый поток видеоданных, обозначенный Главным путем.

Параметр типа SubPath_type=10 указывает «внешнее мультиплексирование 3D SubPath из локальной памяти» ("Out-of-mux 3D SubPath from Local Storage"), что означает, что зависимый поток видеоданных, обозначенный Дополнительным путем, записан в локальной памяти и мультиплексирован в составе транспортного потока TS, отличного от транспортного потока TS, в котором мультиплексирован базовый поток видеоданных, обозначенный Главным путем.

Как описано более подробно ниже, устройство 1 воспроизведения может осуществлять 3D-воспроизведение посредством загрузки зависимого потока видеоданных с сервера и использования этого зависимого потока видеоданных совместно с базовым потоком видеоданных, записанным на оптическом диске 2.

Параметр типа SubPath_type=11 указывает «внутреннее мультиплексирование 3D SubPath из локальной памяти» ("In-mux 3D SubPath from Local Storage"), что означает, что зависимый поток видеоданных, обозначенный Дополнительным путем, записан в локальной памяти и мультиплексирован в составе того же самого транспортного потока TS, в котором мультиплексирован базовый поток видеоданных, обозначенный Главным путем. В этом случае базовый поток видеоданных также записан в локальной памяти.

Параметры типа с SubPath_type=12 по SubPath_type=255 являются резервными.

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

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

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

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

Фиг. 11 иллюстрирует синтаксис записи SubPlayItem(i), показанной на фиг. 9.

Параметр «длина» ("length") обозначает не имеющее знака 16-битовое целое число, представляющее число байтов начиная от байта, следующего сразу же после поля длины, и до последнего байта в записи Sub playItem().

На фиг. 11 по отдельности изображены два случая: случай, когда параметр SubPlayItem ссылается на один Клип, и случай, когда этот параметр SubPlayItem ссылается на несколько Клипов.

Далее рассмотрен случай, когда параметр SubPlayItem ссылается на один Клип.

Параметр Clip_lnformation_file_name[0] (имя файла с информацией о Клипе) указывает Клип, на который дается ссылка.

Параметр Clip_codec_identifier[0] (идентификатор способа кодирования/декодирования Клипа) указывает способ кодирования/декодирования для рассматриваемого Клипа. Сразу же вслед за параметром Clip_codec_identifier[0] следует зарезервированное поле (reserved_for_future_use).

Параметр "is_multi_Clip_entries" («несколько входных клипов») представляет собой флаг, указывающий присутствие/отсутствие регистрации мультиклипа. Если этот флаг "is_multi_Clip_entries" установлен, применяется синтаксис для случая, когда параметр SubPlayItem ссылается на несколько Клипов.

Параметр ref_to_STC_id[0] представляет информацию, относящуюся к точке прерывания STC (точка прерывания на основе системного времени).

Параметр SubPlayItem_IN_time (время начала интервала SubPlayItem) указывает точку начала интервала воспроизведения на Дополнительном пути. Параметр SubPlayItem_OUT_time (время окончания интервала SubPlayItem) указывает точку окончания интервала воспроизведения на Дополнительном пути.

Параметры sync_PlayItem_id (синхронизация интервала) и sync_start_PTS_of_PlayItem (синхронизация начала воспроизведения интервала) указывают время начала, когда Дополнительный путь начинает воспроизведение, на временной оси Главного пути.

Параметры SubPlayItem_IN_time, SubPlayItem_OUT_time, sync_PlayItem_id и sync_start_PTS_of_PlayItem совместно используются Клипом, на который ссылается интервал SubPlayItem.

Далее описан случай, когда результат оператора "if (is_multi_Clip_entries==1b" является истинным, а интервал SubPlayItem ссылается на несколько Клипов.

Параметр num_of_Clip_entries (число входных Клипов) указывает число Клипов, на которые ссылается интервал. Это число имен файлов Clip_Information_file_name[SubClip_entry_id] представляет число Клипов, исключая файл с именем Clip_lnformation_file_name[0].

Параметр Clip_codec_identifier[SubClip_entry_id] (идентификатор способа кодирования/декодирования Клипа) указывает этот способ кодирования/декодирования.

Параметр ref_to_STC_id[SubClip_entry_id] представляет информацию, относящуюся к точке прерывания STC (точка прерывания на основе системного времени). Сразу же за этим параметром ref_to_STC_id[SubClip_entry_id] следует поле reserved_for_future_use, зарезервированное для последующего использования.

Фиг. 12 иллюстрирует синтаксис записи PlayItem(), показанной на фиг. 8.

Параметр «длина» ("length") обозначает не имеющее знака 16-битовое целое число, представляющее число байтов начиная от байта, следующего сразу же после поля длины, и до последнего байта в записи PlayItem().

Параметр Clip_lnformation_file_name[0] (имя файла с информацией о Клипе) указывает имя файла с информацией о Клипе, на который ссылается параметр PlayItem. Отметим, что имя mt2s-файла, содержащего сам Клип, и имя файла с информацией о Клипе, соответствующего этому mt2s-файлу, включают одно и то же 5-значное число.

Параметр Clip_codec_identifier[0] (идентификатор способа кодирования/декодирования Клипа) указывает способ кодирования/декодирования, использованный для этого Клипа. Сразу же за этим параметром Clip_codec_identifier[0] следует поле reserved_for_future_use, зарезервированное для использования в будущем. Сразу же после этого зарезервированного поля reservedfor_future_use следуют параметры is_multi_angle (множественность угла) и connection_condition (состояние соединения).

Параметр ref_to_STC_id[0] представляет информацию, относящуюся к точке прерывания STC (точка прерывания на основе системного времени).

Параметр IN_time (время начала) указывает точку начала воспроизведения интервала PlayItem, а параметр OUT_time (время окончания) указывает точку окончания воспроизведения интервала PlayItem.

Сразу же после параметра OUT_time следуют параметры UO_mask_table() (таблица маски), PlayItem_random_access_mode (режим произвольного доступа к интервалу PlayItem) и still_mode (режим неподвижного изображения).

Таблица STN_table() (таблица STN) включает информацию относительно AV-потока, на который ссылается целевой интервал PlayItem. Кроме того, если имеет место Дополнительный путь, воспроизводимый в соответствии с целевым интервалом PlayItem, таблица STN_table() дополнительно включает информацию об AV-потоке, на который ссылается интервал SubPlayItem, входящий в состав Дополнительного пути.

Фиг. 13 иллюстрирует синтаксис таблицы STN_table(), показанной на фиг. 12.

Таблица STN_table() представляет атрибуты интервала PlayItem.

Параметр «длина» ("length") обозначает не имеющее знака 16-битовое целое число, представляющее число байтов начиная от байта, следующего сразу же после поля длины, и до последнего байта в таблице STN_table(). Сразу же вслед за параметром «длина» расположены 16 бит, зарезервированных для использования в будущем (reserved_for_future_use).

Параметр number_of_video_stream_entries (число входных потоков видеоданных) указывает число потоков, включенных (зарегистрированных) в таблице STN_table() и имеющих присвоенные им идентификаторы video_stream_id потоков видеоданных.

Идентификатор video_stream_id потока видеоданных представляет информацию для идентификации каждого такого потока. Например, этим параметром video_stream_id может быть задан идентификатор ID базового потока видеоданных. Идентификатор ID зависимого потока видеоданных может быть определен в таблице STN_table() или может быть получен посредством вычислений, как описано ниже.

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

Параметр number_of_audio_stream_entries (число входных аудиопотоков) указывает число потоков из состава первого аудиопотока, включенных в таблицу STN_table() в качестве входов. Каждому из этих потоков присвоен свой идентификатор audio_stream_id аудиопотока. Этот идентификатор audio_stream_id представляет информацию для идентификации каждого из этих аудиопотоков. Параметр audio_stream_number (число аудиопотоков) указывает число аудиопотоков, которые используются для переключения аудиопрограмм и могут быть представлены для восприятия пользователем.

Параметр number_of_audio_stream2_entries (число входных аудиопотоков 2) указывает число потоков в составе второго аудиопотока, которому назначен идентификатор audio_stream_id2 аудиопотока, включенный в таблицу STN_table(). Этот идентификатор audio_stream_id2 предоставляет информацию для идентификации каждого из рассматриваемых аудиопотоков. Параметр audio_stream_number указывает число аудиопотоков, которые используются для переключения аудиопрограмм и могут быть представлены для восприятия пользователем. В этом примере воспроизводимый звук можно переключать.

Параметр number_of_PG_txtST_stream_entries (число входных потоков PG_txtST) указывает число потоков с назначенными им идентификаторами PG_txtST_stream_id, включенных в таблицу STN_table(). В таблице STN_table() зарегистрированы PG-поток, полученный в результате кодирования растровых титров, например суб-картинки DVD, посредством кодирования длин серий, и файл текстовых титров (textST). Параметр PG_txtST_stream_number указывает число потоков титров, которые используются для переключения титров и могут быть видимы для пользователя.

Параметр number_of_IG_stream_entries (число входных IG-потоков) указывает число потоков с присвоенными им идентификаторами IG_stream_id, включенных в таблицу STN_table(). В таблице STN_table() зарегистрирован IG-поток. Параметр IG_stream_number указывает число потоков графики, которые используются для переключения графики и могут быть видимы для пользователя.

В таблице STN_table() зарегистрированы также идентификаторы ID главного транспортного потока TS и дополнительного транспортного потока TS, описанные ниже. Эти идентификаторы ID являются идентификаторами не элементарных потоков, а именно транспортных потоков TS. Эту информацию записывают в параметре stream_attribute() (атрибуты потоков).

Фиг. 14 иллюстрирует пример параметра application_type (тип приложения).

Параметр application_type (тип приложения) записывают в файле информации о Клипе (ClipInfo()). Такой файл информации о Клипе создают для каждого Клипа.

Параметр "application_type=0" зарезервирован.

Параметр "application_type=1" указывает, что транспортный поток TS (Клип), соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для киноприложения.

Параметр "application_type=2" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для слайд-шоу на временной основе.

Параметр "application_type=3" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для просматриваемого слайд-шоу.

Параметр "application_type=4" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для просматриваемого слайд-шоу для Дополнительного пути.

Параметр "application_type=5" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS с интерактивной графикой для Дополнительного пути.

Параметр "application_type=6" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для текстовых субтитров (данные текстовых титров) для Дополнительного пути.

Параметр "application_type=7" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для Дополнительного пути, включающего один или несколько элементарных потоков ES.

Параметр "application_type=8" указывает, что транспортный поток TS, соответствующий файлу с информацией о Клипе, включающему этот оператор, представляет собой транспортный поток TS для приложений с воспроизведением 3D-изображения.

Параметры с "application_type=9" по "application_type=255" зарезервированы.

Как описано выше, среди значений параметра application_type имеется значение, назначенное приложению, осуществляющему 3D-воспроизведение. Соответственно, это приложение, осуществляющее 3D-воспроизведение, способно идентифицировать транспортный поток TS, который оно может обработать, на основе значения параметра application_type.

Пример установки значений параметров Application_type и SubPath_type

Фиг. 15 иллюстрирует пример установки значений параметров Application_type и SubPath_type.

В главном транспортном потоке Main TS, показанном на фиг. 15, мультиплексированы базовый поток видеоданных, зависимый поток видеоданных, первичный аудиопоток, базовый PG-поток, зависимый PG-поток, базовый IG-поток и зависимый IG-поток. Как и в этом примере, зависимый поток видеоданных и базовый поток видеоданных могут быть включены в главный транспортный поток Main TS.

На оптическом диске 2 записаны главный транспортный поток Main TS и дополнительный транспортный поток Sub TS. Главный транспортный поток Main TS включает в себя по меньшей мере базовый поток видеоданных. Дополнительный транспортный поток Sub TS включает в себя потоки, отличные от базового потока видеоданных, и используется совместно с главным транспортным потоком Main TS.

Как и для видеоданных, для представления на дисплее 3D-изображения формируют базовые и зависимые потоки также для каждого вида данных - презентационной графики (PG) и интерактивной графики (IG).

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

Например, если базовый поток видеоданных является потоком левого (L) изображения, а зависимый поток видеоданных является потоком правого R изображения, поток базового вида является потоком L-изображения для каждого вида графики - PG и IG. Кроме того, PG-поток и IG-поток для зависимого вида представляют собой потоки графики для R-изображения.

Напротив, если базовый поток видеоданных является потоком R-изображения и зависимый поток видеоданных является потоком L-изображения, поток базового вида является потоком R-изображения для каждого вида графики - PG и IG Кроме того, PG-поток и IG-поток для зависимого вида представляют собой потоки графики для L-изображения.

Параметр application_type для главного транспортного потока Main TS (параметр application_type, записанный в файле информации о Клипе, соответствующем этому главному TS) равен 1.

Базовый поток видеоданных, включенный в состав главного транспортного потока Main TS, представляет собой поток, обрабатываемый не только приложением, осуществляющим 3D-воспроизведение, но и обычным киноприложением, осуществляющим 20-воспроизведение, как указано выше. Для транспортного потока TS, обрабатываемого киноприложением и приложением для 3D-воспроизведения, значение параметра application_type устанавливают равным 1.

Кроме того, поскольку зависимый поток видеоданных включен в один транспортный поток TS с базовым потоком видеоданных, значение параметра SubPath_type для дополнительного пути, ссылающегося на этот зависимый поток видеоданных, равно 9. В этом примере зависимый поток видеоданных записан на оптическом диске 2.

Фиг. 16 иллюстрирует другой пример установки значений параметров Application_type и SubPath_type.

В главном транспортном потоке Main TS, показанном на фиг. 16, мультиплексированы базовый поток видеоданных и зависимый поток видеоданных.

Значение параметра application_type для главного транспортного потока Main TS установлено равным 1.

Кроме того, поскольку зависимый поток видеоданных включен в один транспортный поток TS с базовым потоком видеоданных, значение параметра SubPath_type для дополнительного пути, ссылающегося на этот зависимый поток видеоданных, равно 9. В этом примере, как и в примере, описанном выше, зависимый поток видеоданных записан на оптическом диске 2.

В дополнительном транспортном потоке Sub TS, показанном на фиг. 16, мультиплексированы первичный аудиопоток, базовый PG-поток, зависимый PG-поток, базовый IG-поток и зависимый IG-поток.

Поскольку с этим транспортным потоком TS работает приложение для 3D-воспроизведения, значение параметра application_type для дополнительного транспортного потока Sub TS равно 8.

Фиг. 17 иллюстрирует еще один пример установки значений параметров Application_type и SubPath_type.

В главном транспортном потоке Main TS, показанном на фиг. 17, мультиплексированы базовый поток видеоданных, первичный аудиопоток, базовый PG-поток, зависимый PG-поток, базовый IG-поток и зависимый IG-поток.

Значение параметра application_type для главного транспортного потока Main TS равно 1.

Дополнительный транспортный поток Sub TS, показанный на фиг. 17, включает в себя зависимый поток видеоданных.

Поскольку зависимый поток видеоданных включен в транспортный поток TS, отличный от транспортного потока TS, куда входит базовый поток видеоданных, значение параметра SubPath_type для дополнительного пути, ссылающегося на указанный зависимый поток видеоданных, равно 8. В этом примере, как и в примере, описанном выше, зависимый поток видеоданных записан на оптическом диске 2.

Таким образом, значение параметра, указывающее на транспортный поток TS, обрабатываемый приложением для 3D-воспроизведения, устанавливают равным значению параметра application_type в файле с информацией о Клипе, соответствующем дополнительному транспортному потоку Sub TS, обрабатываемому этим приложением для 3D-воспроизведения.

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

Отметим, что в стандарте BD число транспортных потоков TS, которые можно одновременно считывать с оптического диска 2, ограничено двумя.

Кроме того, в просматриваемом слайд-шоу, как описано выше, аудиопоток, используемый в качестве музыкального сопровождения, указан на Дополнительном пути (параметр SubPath_type=2) отдельно от потока видеоданных, на который ссылается Главный путь. При воспроизведении слайд-шоу поток видеоданных, на который ссылается Главный путь, и аудиопоток, на который ссылается Дополнительный путь, считывают одновременно.

Ниже обсуждается 3D-представление слайд-шоу из неподвижных изображений. Если базовый поток видеоданных и зависимый поток видеоданных для рассматриваемых изображений включены в разные транспортные потоки TS, можно считывать два транспортных потока TS. Однако аудиопоток, используемый в качестве музыкального сопровождения, считать невозможно.

Соответственно, во время работы в режиме просматриваемого слайд-шоу (Application_type=3) допускается только установка значений параметра "SubPath_type=9" или "SubPath_type=11". Таким образом, значения 8 или 10, указывающие, что зависимый поток видеоданных включен в транспортный поток TS, отличный от транспортного потока, в который входит базовый поток видеоданных, не используются для параметра SubPath_type для Дополнительного пути, ссылающегося на зависимый поток видеоданных, включенный в транспортный поток TS, обрабатываемый приложением просматриваемых слайд-шоу.

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

Определение параметра stream_id

Как показано на фиг. 13, таблица STN_table управляет идентификаторами ID потоков (stream_id), на которые ссылаются параметры PlayItem и SubPlayItem.

Идентификатор video_stream_id, управляемый таблицей STN_table, представляет идентификатор ID базового потока видеоданных, а идентификатор PG_txtST_stream_id представляет идентификатор ID базового PG-потока. Кроме того, идентификатор IG_stream_id представляет идентификатор ID базового IG-потока.

Здесь, для зависимого потока видеоданных идентификаторы stream_id не зарегистрированы в таблице STN_table. Эти идентификаторы stream_id могут быть вычислены с использованием идентификатора stream_id базового потока видеоданных.

Например, идентификатор stream_id зависимого потока видеоданных может быть определен с использованием следующего уравнения (1):

Идентификатор stream_id зависимого PG-потока может быть определен с использованием следующего уравнения (2):

Идентификатор stream_id зависимого IG-потока может быть определен с использованием следующего уравнения (3):

В качестве параметра х в уравнениях (1)-(3) можно использовать любую величину. Вместо параметра x в уравнениях (1)-(3) могут быть подставлены различные величины.

Величину x можно идентифицировать из таблицы STN_table. В альтернативном варианте значение x может быть заранее задано в устройстве 1 воспроизведения.

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

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

В стандарте BD разнообразные процессы с использованием потока могут быть реализованы посредством приложений JAVA (зарегистрированный товарный знак).

Например, при выполнении обработки некоторого потока приложение JAVA (зарегистрированный товарный знак) передает команды драйверу для считывания этого потока через API (прикладной программный интерфейс), указав идентификатор stream_id потока, как показано на фиг. 18.

Драйвер рассматривает этот идентификатор stream_id, заданный приложением JAVA (зарегистрированный товарный знак) через интерфейс API, в качестве идентификатора stream_id базового потока видеоданных. Далее драйвер определяет идентификатор stream_id зависимого потока видеоданных посредством вычислений с использованием заданного stream_ID. Кроме того, драйвер считывает базовый поток видеоданных и зависимый поток видеоданных на основе найденных идентификаторов stream_id.

Таким образом, даже при представлении 3D-изображения на дисплее число идентификаторов stream_ID, заданных приложением JAVA (зарегистрированный товарный знак) через интерфейс API, может быть равно единице. Более того, нет необходимости расширять интерфейс API с целью задать два идентификатора stream_ID для базового потока видеоданных и зависимого потока видеоданных.

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

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

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

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

Пример операторов в файле PlayList

Фиг. 19 иллюстрирует синтаксис файла PlayList.

Файл PlayList хранится в директории PLAYLIST списков, показанном на фиг. 7, и имеет расширение ".mpls".

Операторы, показанные на фиг. 8, включены в файл PlayList.

На фиг. 19 параметр type_indicator (индикатор типа) указывает тип файла "xxxxx.mpls".

Параметр version_number (номер версии) указывает номер версии файла "xxxxx.mpls". Этот номер версии представляет собой 4-значное число. Например, файл Playlist для 3D-воспроизведения имеет номер версии "0240", что означает версию "3D Spec version".

Параметр PlayList_start_address (адрес начала списка PlayList) указывает первый адрес PlayList(), представляющий собой адрес байта, относящегося к первому байту файла PlayList.

Параметр PlayListMark_start_address (адреса начала PlayListMark) указывает первый адрес PlayListMark(), представляющий собой адрес байта, относящегося к первому байту файла PlayList.

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

Сразу после параметра ExtensionData_start_address следует поле из 160 бит, зарезервированных на будущее (reserved_for_future_use).

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

Запись PlayList(), сохраняющая параметры, относящиеся к Главному пути и к Дополнительному пути, показана на фиг. 8.

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

Запись ExtensionData() позволяет вставить частные данные.

Фиг. 20 иллюстрирует примеры операторов в списке PlayList.

Как показано на фиг. 20, в файле PlayList записаны 2-битовый параметр 3D_PL_type и 1-битовый параметр view_type. Например, параметры view_types внесены в запись AppInfoPIayList(), показанную на фиг. 19.

Параметр 3D_PL_type указывает тип списка PlayList.

Параметр view_type указывает, является ли базовый поток видеоданных, воспроизведением которого управляет список PlayList, потоком L-изображения (левый вид) или потоком R-изображения (правый вид). В альтернативном варианте параметр view_type указывает, является ли зависимый поток видеоданных потоком L-изображения или R-изображения.

Фиг. 21 иллюстрирует смысл величин параметра 3D_PL_type.

Величина "00" параметра 3D_PL_type указывает на список PlayList для 2D-воспроизведения.

Величина "01" параметра 3D_PL_type указывает на список PlayList для 3D-воспроизведения в формате B-D1.

Величина "10" параметра 3D_PL_type указывает на список PlayList для 3D-воспроизведения в формате B-D2.

Например, когда величина параметра 3D_PL_type равна 01 или 10, информация 3DPlayList зарегистрирована в записи ExtenstionData() в файле PlayList. К примерам зарегистрированной информации 3DPlayList относится имя clpi-файла, соответствующего Клипу зависимого потока видеоданных (например, "00002.clpi" в примере, показанном на фиг. 7).

Фиг. 22 иллюстрирует значения величин параметра view_type.

При выполнении 3D-воспроизведения величина "0" параметра view_type указывает, что базовый поток видеоданных является потоком L-изображения. И, напротив, в случае 2D-воспроизведения величина "0" указывает, что базовый поток видеоданных является AVC-потоком видеоданных video stream.

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

Поскольку параметр view_type включен в файл PlayList, устройство 1 воспроизведения может идентифицировать, является ли базовый поток видеоданных потоком L-изображения или потоком R-изображения.

Например, когда устройство 1 воспроизведения передает видеосигнал дисплею 3 по HDMI-кабелю, это устройство 1 воспроизведения должно идентифицировать, является ли видеосигнал сигналом правого (R) изображения или сигналом левого (L) изображения, и передать этот видеосигнал на выход.

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

Пример конфигурации устройства 1 воспроизведения

Фиг. 23 представляет блок-схему примера конфигурации устройства 1 воспроизведения.

Контроллер 51 выполняет подготовленную программу управления и управляет всей работой устройства 1 воспроизведения.

Например, контроллер 51 управляет дисководом 52 для считывания файла PlayList с целью 3D-воспроизведения. Кроме того, контроллер 51 дает команду дисководу 52 на считывание главного транспортного потока Main TS и дополнительного транспортного потока Sub TS на основе идентификатора ID, зарегистрированного в таблице STN_table, и передачу этих главного (Main TS) и дополнительного (Sub TS) транспортных потоков декодеру 56.

Дисковод 52 под управлением контроллера 51 считывает данные с оптического диска 2 и передает эти данные одному из блоков - контроллеру 51, запоминающему устройству 53 или декодеру 56.

Запоминающее устройство 53 сохраняет данные, необходимые контроллеру 51 для осуществления разнообразных процессов по мере надобности.

Локальная память 54 построена, например, на основе HDD (накопитель на жестком магнитном диске). Эта локальная память 54 сохраняет, например, зависимый поток видеоданных, загружаемый от сервера 72. Поток, сохраняемый в локальной памяти 54, передают по мере необходимости в декодер 56.

По командам контроллера 51 Интернет-интерфейс 55 устанавливает связь с сервером 72 через сеть связи 71 и загружает данные от сервера 72. После этого Интернет-интерфейс 55 передает загруженные данные в локальную память 54.

С сервера 72 загружают данные, используемые для обновления данных, записанных на оптическом диске 2. Таким образом, загруженный зависимый поток видеоданных может быть использован совместно с базовым потоком видеоданных, записанным на оптическом диске 2. Это позволяет реализовать 3D-воспроизведение материала, отличного от материала, записанного на оптическом диске 2. Когда происходит загрузка зависимого потока видеоданных, обновляют информацию списка PlayList по мере необходимости.

Декодер 56 осуществляет декодирование потока, поступающего от дисковода 52 или из локальной памяти 54, и выделяет видеосигнал. Затем декодер 56 передает выделенный видеосигнал дисплею 3. Кроме того, дисплею 3 передают по заданному маршруту аудиосигнал.

Блок 57 ввода содержит устройства ввода, такие как кнопки, клавиши, сенсорная панель, поворотный переключатель или мышь, и приемник, получающий, например, инфракрасный сигнал от заданного устройства дистанционного управления. Блок 57 ввода определяет операцию, выполненную пользователем, и передает соответствующий этой операции сигнал контроллеру 51.

Фиг. 24 иллюстрирует пример конфигурации декодера 56.

На фиг. 24 представлена конфигурация для обработки видеосигнала. В декодере 56 осуществляется также процесс декодирования аудиосигнала. Результат декодирования аудиосигнала передают дисплею 3 по определенному маршруту (не показан).

PID-фильтр 101 определяет, когда транспортный поток TS, поступающий от дисковода 52 или локальной памяти 54, является главным Main TS или дополнительным Sub TS транспортным потоком, с использованием идентификатора PID пакета в транспортном потоке TS или идентификатора ID самого этого потока. Этот PID-фильтр 101 передает главный транспортный поток TS буферу 102 и передает дополнительный транспортный поток Sub TS в буфер 103.

PID-фильтр 104 последовательно считывает пакет из главного транспортного потока Main TS, записанного в буфере 102, и направляет этот пакет в соответствии с его идентификатором PID.

Например, PID-фильтр 104 передает пакет базового потока видеоданных, включенного в главный транспортный поток Main TS, в В-видеобуфер 106 и передает пакет зависимого потока видеоданных переключателю 107.

Кроме того, PID-фильтр 104 передает пакет базового IG-потока, включенного в главный транспортный поток Main TS, переключателю 114 и передает пакет зависимого IG-потока переключателю 118.

PID-фильтр 104 передает пакет базового PG-потока, включенного в главный транспортный поток Main TS, переключателю 122 и передает пакет зависимого PG-потока переключателю 126.

Как показано на фиг. 15, базовый поток видеоданных, зависимый поток видеоданных, базовый PG-поток, зависимый PG-поток, базовый IG-поток и зависимый IG-поток могут быть мультиплексированы в главном транспортном потоке Main TS.

PID-фильтр 105 последовательно считывает пакет из дополнительного транспортного потока Sub TS, записанного в буфере 103, и направляет пакет в соответствии с его идентификатором PID.

Например, PID-фильтр 105 передает пакет зависимого потока видеоданных, включенный в дополнительный транспортный поток Sub TS, переключателю 107.

Кроме того, PID-фильтр 105 передает пакет базового IG-потока, включенного в дополнительный транспортный поток Sub TS, переключателю 114 и передает пакет зависимого IG-потока переключателю 118.

PID-фильтр 105 передает пакет базового PG-потока, включенного в дополнительный транспортный поток Sub TS, переключателю 122 и передает пакет зависимого PG-потока переключателю 126.

Как показано на фиг. 17, зависимый поток видеоданных может быть включен в дополнительный транспортный поток Sub TS. Кроме того, как показано на фиг. 16, базовый PG-поток, зависимый PG-поток, базовый IG-поток и зависимый IG-поток могут быть мультиплексированы в дополнительном транспортном потоке Sub TS.

Переключатель 107 передает пакет зависимого потока видеоданных, поступающий от PID-фильтра 104 или PID-фильтра 105, в D-видеобуфер 108.

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

Переключатель 109 передает пакет, считываемый из В-видеобуфера 106 или из D-видеобуфера 108, видеодекодеру 110.

Этот видеодекодер 110 осуществляет декодирование пакета, поступающего от переключателя 109, для выделения видеоданных базового потока или видеоданных зависимого потока. Затем видеодекодер 110 передает выделенные данные переключателю 111.

Этот переключатель 111 передает данные, выделенные путем декодирования пакета видеоданных базового потока, в генератор 112 В-видеоплоскости, и передает данные, выделенные путем декодирования пакета видеоданных зависимого потока, в генератор 113 D-видеоплоскости.

Генератор 112 В-видеоплоскости генерирует плоскость видеоданных базового потока с использованием данных от переключателя 111 и передает созданную таким образом плоскость сумматору 130.

Генератор 113 D-видеоплоскости генерирует плоскость видеоданных зависимого потока с использованием данных от переключателя 111 и передает созданную таким образом плоскость сумматору 130.

Переключатель 114 передает пакет базового IG-потока, поступающий от PID-фильтра 104 или PID-фильтра 105, в B-IG буфер 115.

B-IG декодер 116 осуществляет декодирование пакета базового IG-потока, записанного в B-IG буфере 115, и передает декодированные данные в генератор 117 B-IG плоскости.

Генератор 117 B-IG плоскости формирует плоскость базового IG-потока с использованием данных, поступающих от B-IG декодера 116, и передает созданную таким образом плоскость сумматору 130.

Переключатель 118 передает пакет зависимого IG-потока, поступающий от PID-фильтра 104 или PID-фильтра 105, в D-IG буфер 119.

D-IG декодер 120 осуществляет декодирование пакета зависимого IG-потока, записанного в D-IG буфере 119, и передает декодированные данные в генератор 121 D-IG плоскости.

Генератор 121 D-IG плоскости формирует плоскость зависимого IG-потока с использованием данных, поступающих от D-IG декодера 120, и передает созданную таким образом плоскость сумматору 130.

Переключатель 122 передает пакет базового PG-потока, поступающий от PID-фильтра 104 или PID-фильтра 105, в B-PG буфер 123.

B-PG декодер 124 осуществляет декодирование пакета базового PG-потока, записанного в B-PG буфере 123, и передает декодированные данные в генератор 125 B-PG плоскости.

Генератор 125 B-PG плоскости формирует плоскость базового PG-потока с использованием данных, поступающих от B-PG декодера 124, и передает созданную таким образом плоскость сумматору 130.

Переключатель 126 передает пакет зависимого PG-потока, поступающий от PID-фильтра 104 или PID-фильтра 105, в D-PG буфер 127.

D-PG декодер 128 осуществляет декодирование пакета зависимого PG-потока, записанного в D-PG буфере 127, и передает декодированные данные в генератор 129 D-PG плоскости.

Генератор 129 D-PG плоскости формирует плоскость зависимого PG-потока с использованием данных, поступающих от D-PG декодера 128, и передает созданную таким образом плоскость сумматору 130.

Сумматор 130 осуществляет суммирование плоскости базового потока видеоданных, поступающей от генератора 112 В-видеоплоскости, плоскости базового IG-потока, поступающей от генератора 117 B-IG плоскости, и плоскости базового PG-потока, поступающей от генератора 125 B-PG плоскости, путем наложения этих плоскостей одну на другую в заданном порядке. Таким образом, сумматор 130 генерирует плоскость базового вида.

Кроме того, сумматор 130 осуществляет суммирование плоскости зависимого потока видеоданных, поступающей от генератора 113 D-видеоплоскости, плоскости зависимого IG-потока, поступающей от генератора 121 D-IG-плоскости, и плоскости зависимого PG-потока, поступающей от генератора 129 D-PG плоскости, путем наложения этих плоскостей одну на другую в заданном порядке. Таким образом, сумматор 130 генерирует плоскость зависимого вида.

Сумматор 130 передает данные плоскости базового вида и плоскости зависимого вида на выход. Выходные видеоданные от сумматора 130 поступают в дисплей 3. Этот дисплей 3 осуществляет 3D-отображение путем поочередного представления плоскости базового вида и плоскости зависимого вида.

Фиг. 25 иллюстрирует структуру для обработки потока видеоданных.

На фиг. 25 для компонентов, идентичных или аналогичных компонентам, показанным на фиг. 24, использованы те же самые позиционные обозначения. После видеодекодера 110 расположен не показанный на фиг. 24 буфер 151 декодированного изображения DPB (Decoded Picture Buffer) для сохранения декодированных видеоданных изображения. Описание таких же компонентов не повторяется, где это возможно.

Кроме того, в примере, представленном на фиг. 25, вместо генератора 112 В-видеоплоскости, показанного на фиг. 24, изображен генератор 161 L-видеоплоскости. Вместо генератора 113 D-видеоплоскости, показанного на фиг. 24, представлен генератор 162 R-видеоплоскости.

Генератор 161 L-видеоплоскости формирует плоскость L-изображения. Кроме того, генератор 162 R-видеоплоскости формирует плоскость R-изображения.

В этом примере переключатель 111 должен отличать видеоданные L-изображения от видеоданных R-изображения и передавать эти видеоданные на выход.

Иными словами, переключатель 111 определяет, какие из данных, полученных в результате декодирования пакета видеоданных базового потока, и данных, полученных в результате декодирования пакета видеоданных зависимого потока, являются видеоданными L-изображения или R-изображения.

Для различения между L-изображением и R-изображением используют параметр view_type, показанный на фиг. 20 и 22. Например, контроллер 51 передает параметр view_type, записанный в файле PlayList, переключателю 111.

Когда значение параметра view_type равно "0", переключатель 111 декодирует пакет базового потока видеоданных с идентификатором PID=0 из данных, записанных в буфере DPB 151, и передает полученные данные генератору 161 L-видеоплоскости. Как отмечено выше, значение "0" параметра view_type указывает, что базовый поток видеоданных является потоком левого (L) изображения. Например, пакету видеоданных базового потока присвоен идентификатор PID, равный 0, а пакету видеоданных зависимого потока присваивают идентификатор PID, отличный от 0.

В таком случае переключатель 111 декодирует пакет зависимого потока видеоданных, имеющий идентификатор PID, отличный от 0, и передает декодированные данные генератору 162 R-видеоплоскости.

Напротив, когда значение параметра view_type равно "1", переключатель 111 декодирует пакет базового потока видеоданных с идентификатором PID=0 из данных, записанных в буфере DPB 151, и передает полученные данные генератору 162 R-видеоплоскости. Значение "1" параметра view_type указывает, что базовый поток видеоданных является потоком правого (R) изображения.

В таком случае переключатель 111 декодирует пакет зависимого потока видеоданных, имеющий идентификатор PID, отличный от 0, и передает декодированные данные генератору 161 L-видеоплоскости.

Генератор 161 L-видеоплоскости формирует плоскость L-видео с использованием данных, поступающих от переключателя 111, и передает сформированную плоскость сумматору 130. Сумматор 130 должным образом суммирует эту плоскость L-видео от генератора 161 L-видеоплоскости с другими данными L-видео. Суммарную плоскость передают дисплею 3 в качестве данных L-изображения.

Генератор 162 R-видеоплоскости формирует плоскость R-видео с использованием данных, поступающих от переключателя 111, и передает сформированную плоскость сумматору 130. Сумматор 130 должным образом суммирует эту плоскость R-видео от генератора 162 R-видеоплоскости с другими данными R-видео. Суммарную плоскость передают дисплею 3 в качестве данных R-изображения.

Элементарные потоки базовых видеоданных и зависимых видеоданных, кодированные с использованием стандарта Н.264 AVC/MVC profile, не включают информацию (поле), указывающую, представляет ли этот поток L-изображение или R изображение.

Соответственно, введя параметр view_type в файл PlayList, устройство записи позволяет устройству 1 воспроизведения определить, какой из потоков - базовый поток видеоданных или зависимый поток видеоданных, является потоком левого (L) изображения, а какой - потоком правого (R) изображения.

Устройство 1 воспроизведения может определить, какой из потоков - базовый поток видеоданных или зависимый поток видеоданных, является потоком L-изображения, а какой - потоком R-изображения, и переключить направление передачи выходного сигнала в соответствии с результатом такого определения.

Даже если каждая из плоскостей - IG-плоскость и PG-плоскость, имеет L-изображение и R-изображение, устройство 1 воспроизведения может определить, какой из потоков видеоданных является потоком L-изображения, а какой потоком R-изображения. Соответственно, устройство 1 воспроизведения может легко суммировать плоскости L-изображения и суммировать плоскости R-изображения.

В некоторых случаях, когда видеосигнал передают на выход с использованием HDMI-кабеля, сигнал L-изображения необходимо отличить от сигнала R-изображения и передать на выход. В таком случае устройство 1 воспроизведения способно выполнить это требование.

Данные, полученные путем декодирования пакета базового потока видеоданных, записанного в буфере DPB 151, можно отличать от данных, полученных путем декодирования пакета зависимого потока видеоданных, с использованием идентификатора view_id вместо идентификатора PID.

Когда кодирование осуществляется с использованием стандарта H.264 AVC/MVC profile, блок доступа (Access Unit), формирующий кодированный поток, имеет присвоенный ему идентификатор view_id. Использование такого идентификатора view_id позволяет определить, к какому компоненту изображения относится каждый блок доступа.

Фиг. 26 показывает пример блока доступа.

На фиг. 26 блок доступа #1 (Access Unit #1) представляет собой блок, включающий в себя данные базового потока видеоданных. Зависимый блок #2 (Dependent Unit #2) представляет собой блок, включающий в себя данные зависимого потока видеоданных. Например, блок доступа (зависимый блок для зависимого вида) генерируют путем суммирования данных кадра, что делает возможным доступ по принципу картинка за картинкой.

При кодировании видеоданных с использованием стандарта H.264 AVC/MVC profile в таком блоке заключены данные кадра для каждого - базового и зависимого, потока видеоданных. Как показано зависимым блоком #2 (Dependent Unit #2), при кодировании с использованием стандарта Н.264 AVC/MVC profile к каждому компоненту изображения добавлен MVC-заголовок. Такой MVC-заголовок включает идентификатор view_id.

В примере, приведенном на фиг. 26, для зависимого блока #2 можно с использованием идентификатора view_id определить, что составляющая изображения, записанная в этом блоке, является видеоданными зависимого потока.

Однако, как показано на фиг. 26, к видеоданным базового потока, представляющим собой составляющую изображения, записанную в блоке доступа #1, не добавлен MVC-заголовок.

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

Устройство 1 воспроизведения настраивают таким образом, чтобы это устройство 1 воспроизведения считало, что составляющая изображения, не имеющая добавленного к ней MVC-заголовка, содержит идентификатор view_id, равный 0, и является видеоданными базового потока. Для видеоданных зависимого потока при кодировании устанавливают отличное от 0 значение идентификатора view_id.

Таким образом, устройство 1 воспроизведения может идентифицировать видеоданные базового потока с использованием идентификатора view_id, равного 0. Напротив, устройство 1 воспроизведения может идентифицировать видеоданные зависимого потока с использованием идентификатора view_id, значение которого реально установлено отличным от 0.

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

Пример конфигурации устройства записи

Фиг. 27 представляет блок-схему примера конфигурации модуля 201 обработки программы.

Конфигурация видеокодирующего устройства 211 аналогична конфигурации кодирующего устройства 11 стандарта MVC, показанной на фиг. 3. Видеокодирующее устройство 211 кодирует несколько блоков видеоданных с использованием стандарта Н.264 AVC/MVC profile. Таким образом, видеокодирующее устройство 211 генерирует базовый поток видеоданных и зависимый поток видеоданных и передает созданные потоки в буфер 212.

Аудиокодирующее устройство 213 кодирует входной аудиопоток и передает кодированные данные в буфер 214. Аудиопоток для записи на диск вместе с базовым потоком видеоданных и зависимым потоком видеоданных вводят в аудиокодирующее устройство 213.

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

Например, кодирующее устройство 215 данных устанавливает значение параметра application_type в файле информации о Клипе, соответствующем дополнительному транспортному потоку Sub TS, включающему зависимый поток видеоданных, равное 8. Параметр "application_type=8" указывает на приложение, выполняющее 3D-воспроизведение с использованием зависимого потока видеоданных.

Кроме того, кодирующее устройство 215 данных устанавливает в списке PlayList величину параметра SubPath_type, значение которого указывает, мультиплексирован ли зависимый поток видеоданных в одном транспортном потоке TS с базовым потоком видеоданных, и в каком месте записан этот зависимый поток видеоданных. Местом, где записан зависимый поток видеоданных, может быть либо оптический диск 2, либо локальная память 54.

Более того, когда устройство 1 воспроизведения вычисляет зависимый поток видеоданных с использованием идентификатора ID базового потока видеоданных, кодирующее устройство 215 данных устанавливает величину x, используемую для таких вычислений, в заданном месте, например в таблице STN_table().

Кодирующее устройство 215 данных устанавливает в файле PlayList параметр view_type, указывающий, является ли базовый поток видеоданных потоком L-изображения или потоком R-изображения в соответствии с кодированием, осуществляемым в видеокодирующем устройстве 211.

Мультиплексор 217 осуществляет мультиплексирование видеоданных, аудиоданных и данных, отличных от данных потоков, записанных в соответствующих буферах, с синхросигналом. Затем мультиплексор 217 передает мультиплексированные данные в устройство 218 кодирования данных в коде с коррекцией ошибок.

Это устройство 218 кодирования в коде с коррекцией ошибок присоединяет такой код с коррекцией ошибок к данным, мультиплексированным посредством мультиплексора 217.

Модулятор 219 осуществляет модуляцию данных, поступающих от устройства 218 кодирования данных в коде с коррекцией ошибок, и передает модулированные данные на выход. Эти выходные данные модулятора 219 служат программой, записываемой на оптическом диске 2, так что ее можно воспроизвести с диска посредством устройства 1 воспроизведения.

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

Фиг. 28 иллюстрирует примеры конфигураций, включающих модуль 201 обработки программы.

Часть конфигурации, показанной на фиг. 26, может быть расположена в устройстве записи.

Сигнал записи, генерируемый модулем 201 обработки создания программы, подвергают мастерингу в модуле 231 предварительного мастеринга. В результате происходит генерация сигнала, имеющего формат, подходящий для записи на оптическом диске 2. Полученный сигнал передают в модуль 233 записи эталонного диска.

Эталонный диск заранее установлен в устройстве 232 для изготовления эталонных дисков. Эталонный диск может быть выполнен, например, из стекла. На эталонный диск наносят записывающий материал, такой как фоторезист. В результате изготавливается записывающий диск.

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

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

В литьевой машине 235 в литьевую форму заливают материал, такой как РММА (полиметилметакрилат или акрилат) или PC (поликарбонат), и отверждают залитый материал в форме. В альтернативном варианте на металлический штамп наносят, например, 2Р (отверждаемую в ультрафиолетовых лучах полимерную смолу). Затем этот материал 2Р отверждают, облучая его ультрафиолетом. Таким образом, ямки, созданные на металлическом штампе, могут быть перенесены на оттиск, изготовленный из полимерной смолы.

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

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

Местонахождение параметра view_type

Как показано на фиг. 20, приведенное выше описание относится к случаю, когда параметр view_type, указывающий является ли базовый поток видеоданных потоком L-изображения или потоком R-изображения, записан в списке PlayList. Однако этот параметр view_type может быть записан и в другом месте, отличном от списка PlayList.

Например, базовый поток видеоданных и зависимый поток видеоданных могут быть мультиплексированы в одном и том же транспортном потоке TS или в разных транспортных потоках TS. Затем эти поток TS или потоки TS передают по радио в режиме вещания или через сеть связи. В таком случае параметр view_type записывают в, например, PSI, что представляет собой информацию о программах, базовом потоке видеоданных или зависимом потоке видеоданных (элементарный поток).

Фиг. 29 иллюстрирует пример, когда параметр view_type записан в РМТ (Таблица структуры программы), включенной в PSI (Информация, специфическая для программы).

Как показано на фиг. 29, в качестве MVC-дескриптора можно заново определить запись MVC_video_stream_descriptor(). Тогда параметр view_type можно внести в эту запись MVC_video_stream_descriptor(). Отметим, что значение маркера descriptor_tag установлено, например, 65.

В таком случае кодирующее устройство 215 данных в модуле 201 обработки программ генерирует таблицу РМТ с записанным в ней параметром view_type и передает созданную таким образом таблицу РМТ на выход. Таблица РМТ с выхода кодирующего устройства 215 данных поступает через буфер 216 в мультиплексор 217, где ее мультиплексируют вместе с базовым потоком видеоданных и зависимым потоком видеоданных. Транспортный поток TS, полученный в результате мультиплексирования, передают по радио в режиме вещания или через сеть.

При приеме этого транспортного потока TS устройство 1 воспроизведения определяет, является ли базовый поток видеоданных, мультиплексированный в составе этого транспортного потока TS, потоком L-изображения или потоком R-изображения на основе параметра view_type, записанного в таблице РМТ. После этого устройство 1 воспроизведения переключает направление передачи выходных данных, полученных в результате декодирования, как показано на фиг. 25.

Параметр view_type может быть записан вместо таблицы РМТ и в другом месте, например в составе таблицы SIT (Таблица информации выбора).

Фиг. 30 иллюстрирует пример, когда параметр view_type записан в составе элементарного потока.

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

Фиг. 31 иллюстрирует структуру блока доступа (Access Unit).

Как показано на фиг. 31, блок доступа в составе видеоданных базового потока, включающий данные кадра базового потока видеоданных, имеет такую же структуру, как и зависимый блок в составе видеоданных зависимого потока, включающий данные кадра зависимого потока видеоданных. Каждый блок доступа включает разграничитель, обозначающий границу между блоками доступа, а также SPS, PPS, SEI и данные картинки. Например, к данным картинки зависимого блока из состава видеоданных зависимого потока добавлен MVC-заголовок, показанный на фиг. 26.

В таком случае кодирующее устройство 215 модуля 201 обработки программ генерирует информацию SEI, включающую в себя записанный в ней параметр view_type, и передает эту информацию SEI видеокодирующему устройству 211 по некоторому маршруту (не показан). Видеокодирующее устройство 211 добавляет информацию SEI с выхода кодирующего устройства 215 данных к указанным данным каждой картинки базового потока видеоданных и зависимого потока видеоданных, полученным посредством кодирования данных L-изображения и данных R-изображения в соответствии со стандартом Н.264 AVC/MVC profile, как показано на фиг. 31.

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

После считывания информации SEI устройство 1 воспроизведения определяет, является ли базовый поток видеоданных потоком L-изображения или потоком R-изображения на основе значения параметра view_type, записанного в составе SEI. Затем устройство 1 воспроизведения выполняет описанную выше обработку данных, иллюстрируемую фиг. 25, например переключение направления передачи данных, полученных в результате декодирования.

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

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

Центральный процессор ЦПУ 301, ПЗУ (ROM (постоянное запоминающее устройство)) 302 и ОЗУ (RAM (оперативное запоминающее устройство)) 303 соединены одно с другими посредством шины 304.

Кроме того, с шиной 304 соединен интерфейс 305 ввода/вывода. Этот интерфейс 305 ввода/вывода имеет входное устройство 306, включающее, например, клавиатуру и мышь, и выходное устройство 307, включающее, например, дисплей и соединенный с ним громкоговоритель. Кроме того, с шиной 304 соединены запоминающее устройство 308, включающее накопитель на жестком диске и энергонезависимую память, устройство 309 связи, включающее, например, сетевой интерфейс, и привод 310 для работы со сменным носителем 311 записи.

В компьютере, имеющем описанную выше конфигурацию, процессор ЦПУ 301 загружает программу, хранящуюся в запоминающем устройстве 308, в ОЗУ (RAM) 303 через интерфейс 305 ввода/вывода и шину 304. После этого происходит выполнение описанной выше последовательности процессов.

Программы для выполнения процессором ЦПУ 301 поступают через, например, сменный носитель 311 записи, на котором записаны эти программы, или по кабельной или беспроводной линии связи, такой как локальная сеть связи, Интернет или система цифрового вещания, после чего эти программы инсталлируют в запоминающем устройстве 308.

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

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

Перечень позиционных обозначений

1 - устройство воспроизведения

2 - оптический диск

3 - дисплей

11 - кодирующее устройство стандарта MVC

21 - кодирующее устройство стандарта H.264/AVC

22 - декодер стандарта H.264/AVC

23 - устройство вычисления глубины

24 - кодирующее устройство для зависимого потока видеоданных

25 - мультиплексор

51 - контроллер

52 - дисковод

53 - запоминающее устройство

54 - локальная память

55 - Интернет-интерфейс

56 - декодер

57 - блок ввода операции