ЗАПИСЫВАЮЩЕЕ УСТРОЙСТВО, СПОСОБ ЗАПИСИ, УСТРОЙСТВО ВОСПРОИЗВЕДЕНИЯ, СПОСОБ ВОСПРОИЗВЕДЕНИЯ, НОСИТЕЛЬ ЗАПИСИ И ПРОГРАММА Российский патент 2014 года по МПК H04N5/92 H04N13/00 G06K9/36 G11B20/12 H04N19/60 

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

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

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

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

Специализированное устройство необходимо для отображения стереоскопического изображения. Пример такого устройства для стереоскопического визуального отображения включает в себя IP (Integral Photography - интегральная фотосъемка) систему стереоскопического изображения, разработанную компанией NHK (Nippon Hoso Kyokai).

Данные стереоскопического изображения составлены данными изображения множества точек наблюдения (данные изображения, зафиксированные с множества точек наблюдения). Поскольку количество точек наблюдения больше и поскольку диапазон, покрываемый этими точками наблюдения, шире, то объект может рассматриваться с большего числа направлений. То есть может быть реализовано телевидение такого рода как “телевидение, в котором можно заглянуть внутрь объекта”.

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

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

Пример такого носителя большой емкости включает в себя Blu-Ray (зарегистрированный товарный знак) Disk (в дальнейшем также называемый как BD), такой как BD-ROM (Blu-Ray (зарегистрированный товарный знак) - ROM (Read Only Memory - постоянное запоминающее устройство).

Список ссылок

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

PTL 1: Публикация №2005-348314 нерассмотренной заявки на патент Японии.

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

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

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

Данные изображения стереоизображения составлены из двух потоков данных: потока данных левого изображения и потока данных правого изображения. Если два потока данных записаны на BD «как есть», то может быть невозможно воспроизвести потоки данных в уже существующем BD-проигрывателе.

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезные результаты изобретения

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

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

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

Фиг.2 является схемой, иллюстрирующей пример съемки.

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

Фиг.4 является схемой, иллюстрирующей пример опорных изображений.

Фиг.5 является схемой, иллюстрирующей пример конфигурации TS.

Фиг.6 является схемой, иллюстрирующей другой пример конфигурации TS.

Фиг.7 является схемой, иллюстрирующей еще один пример конфигурации TS.

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

Фиг.9 является схемой, иллюстрирующей структуру главного пути (Main Path) и дополнительного пути (Sub Path).

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

Фиг.11 является схемой, иллюстрирующей синтаксис файла PlayList (список файлов для воспроизведения).

Фиг.12 является схемой, иллюстрирующей пример способа для использования параметра "reserved_for_future_use", показанного на фиг.11.

Фиг.13 является схемой, иллюстрирующей значения величин параметра "3D_PL_type".

Фиг.14 является схемой, иллюстрирующей значения величин параметра "View_type".

Фиг.15 является схемой, иллюстрирующей синтаксис файла PlayList(), показанного на фиг.11.

Фиг.16 является схемой, иллюстрирующей синтаксис параметра "SubPath", показанного на фиг.15.

Фиг.17 является схемой, иллюстрирующей синтаксис параметра "SubPlayItem(i)", показанного на фиг.16.

Фиг.18 является схемой, иллюстрирующей синтаксис параметра "PlayItem()", показанного на фиг.15.

Фиг.19 является схемой, иллюстрирующей синтаксис параметра "STN_table()", показанного на фиг.18.

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

Фиг.21 является схемой, иллюстрирующей пример конфигурации модуля декодера, показанного на фиг.20.

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

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

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

Фиг.25 является схемой, иллюстрирующей пример модулей доступа "Access Units".

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

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

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

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

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

Фиг.31 является схемой, иллюстрирующей пример конфигурации генерирующего модуля для трехмерного видеоизображения 3D video TS, обеспеченного в записывающем устройстве.

Фиг.32 является схемой, иллюстрирующей другой пример конфигурации генерирующего модуля для трехмерного видеоизображения 3D video TS, обеспеченного в записывающем устройстве.

Фиг.33 является схемой, иллюстрирующей еще один пример конфигурации генерирующего модуля для трехмерного видеоизображения 3D video TS, обеспеченного в записывающем устройстве.

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

Фиг.35 является схемой, иллюстрирующей процесс декодирования.

Фиг.36 является схемой, иллюстрирующей структуру закрытой группы кадров Close GOP (Group Of Pictures - группа кадров).

Фиг.37 является схемой, иллюстрирующей структуру открытой группы кадров Open GOP.

Фиг.38 является схемой, иллюстрирующей максимальное количество кадров и полукадров в структуре GOP.

Фиг.39 является схемой, иллюстрирующей структуру Close GOP.

Фиг.40 является схемой, иллюстрирующей структуру Open GOP.

Фиг.41 является схемой, иллюстрирующей пример начального положения декодирования, установленного в "ЕР_map".

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

Фиг.43 является схемой, иллюстрирующей принцип поиска кадра.

Фиг.44 является схемой, иллюстрирующей структуру аудиовизуального потока AV, записанного на оптический диск.

Фиг.45 является схемой, иллюстрирующей пример потока Clip AV.

Фиг.46 является схемой, концептуально иллюстрирующей пример параметра "ЕР_map", соответствующего потоку Clip AV, показанному на фиг.45.

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

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

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

Первый вариант осуществления изобретения

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

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

Как показано на фиг.1, эта система воспроизведения составлена с помощью соединения устройства 1 воспроизведения и устройства 3 отображения, использующих кабельный интерфейс HDMI (High Definition Multimedia Interface - мультимедийный интерфейс высокой четкости) или подобный. Оптический диск 2, такой как диск BD, загружается в устройство 1 воспроизведения.

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

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

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

Способ отображения первого типа является способом отображения трехмерного изображения, в котором данные трехмерного изображения составлены из данных изображения, обозреваемых левым глазом (изображение L), и данных изображения, обозреваемых правым глазом (изображение R), при этом изображение L и изображение R отображаются попеременно.

Способ отображения второго типа является способом отображения трехмерного изображения путем отображения левого изображения L и правого изображения R, которые генерируются, используя данные оригинального изображения, которое является изображением, служащим как оригинал для генерирования трехмерного изображения, и данные глубины Depth. Данные трехмерного изображения, используемые в способе отображения второго типа, составлены из данных оригинального изображения и данных глубины Depth, которые придаются оригинальному изображению для генерирования левого изображения L и правого изображения R.

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

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

Для записывания таких потоков на оптический диск 2 применяется, например, способ кодирования Н.264 AVC (Advanced Video Coding)/MVC (Multi-view Video coding).

Профиль Н.264 AVC/MVC

В способе Н.264 AVC/MVC определяются поток изображения, называемый Базовое представление видеоданных, и поток изображения, называемый зависимое представление видеоданных. В дальнейшем Н.264 AVC/MVC, по мере необходимости, будет просто определяться как MVC.

Фиг.2 является схемой, иллюстрирующей пример съемки.

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

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

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

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

H.264/AVC кодирующее устройство 21 кодирует поток #1 видеоданных, например, как Н.264 AVC/ поток видеоданных с высоким профилем. H.264/AVC кодирующее устройство 21 выводит поток видеоданных AVC, полученный путем кодирования и используемый как базовый поток представления видеоданных, к H.264/AVC декодирующему устройству 22 и мультиплексору 25.

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

Вычислительный модуль 23 для расчета глубины рассчитывает глубину на основе потока #1 видеоданных и потока #1 видеоданных и выводит данные вычисленной глубины к мультиплексору 25.

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

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

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

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

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

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

В том случае, когда зависимое представление видеоданных, которое используется вместе с базовым представлением видеоданных в способе отображения первого типа, необходимо отличать от зависимого представления видеоданных с использованием глубины (Depth), которое применяется вместе с базовым представлением видеоданных в способе отображения второго типа, то первое рассматривается как представление D1 видеоданных, а последнее рассматривается как представление D2 видеоданных.

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

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

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

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

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

В дальнейшем, главным образом, будет дано описание случая, в котором зависимое представление видео является представлением D1 видеоданных. Простое упоминание зависимого представления видео соответствует представлению D1 видеоданных. Аналогично, представление D2 видеоданных записывается на оптический диск 2 и воспроизводится таким же способом, как и для представления D1 видеоданных.

Пример конфигурации TS

Фиг.5 является схемой, иллюстрирующей пример конфигурации TS.

Потоки базового представления видеоданных, зависимого представления видеоданных, первичного звукового сигнала, базового PG (Presentation Graphics - презентационная графика), зависимого PG, базового IG (Interactive Graphics - интерактивная графика) и зависимого IG объединяются в главном TS (Main TS), показанном на фиг.5. Таким образом поток зависимого представления видеоданных может быть включен в Main TS вместе с потоком базового представления видеоданных.

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

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

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

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

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

Фиг.6 является схемой, иллюстрирующей другой пример конфигурации TS.

Потоки базового представления и зависимого представления видеоданных объединяются в главном TS (Main TS), показанном на фиг.6.

С другой стороны, потоки первичного звукового сигнала, базового PG, зависимого PG, базового IG и зависимого IG объединяются в дополнительном TS (Sub TS).

Таким образом, потоки видеоданных могут быть объединены в Main TS, а потоки PG и IG могут быть объединены в Sub TS.

Фиг.7 является схемой, иллюстрирующей еще один пример конфигурации TS.

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

С другой стороны, поток зависимого представления видеоданных включен в Sub TS.

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

Потоки базового представления видеоданных, первичного звукового сигнала, PG и IG объединяются в Main TS, в части В, показанной на фиг.7. С другой стороны, потоки зависимого представления видеоданных, базового PG, зависимого PG, базового IG и зависимого IG объединяются в Sub TS.

PG и IG, включенные в состав Main TS, являются потоками для двухмерного воспроизведения. Потоки, включенные в состав Sub TS, являются потоками для трехмерного воспроизведения.

Таким образом, поток PG и поток IG могут быть потоками, не используемыми совместно для двухмерного воспроизведения и трехмерного воспроизведения.

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

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

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

Фиг.8 является схемой, иллюстрирующей пример управления потоками AV (аудиовизуальными), осуществляемого устройством 1 воспроизведения.

Управление потоками AV осуществляется путем использования двух слоев Playlist и Clip, как показано на фиг.8. Потоки AV могут быть записаны в локальную память устройства 1 воспроизведения, а также на оптический диск 2.

Здесь пара из одного потока AV и информации клипа (Clip), которая является информацией, сопутствующей потоку AV, рассматривается как один объект, который определяется как клип (Clip). В дальнейшем, файл, сохраняющий поток AV, определяется как файл потока AV. Аналогично, файл, сохраняющий информацию Clip, определяется как файл информации Clip.

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

Playlist является набором интервалов воспроизведения потока AV. Один интервал воспроизведения в потоке AV называется PlayItem (элемент воспроизведения). PlayItem выражается парой точек, точкой IN и точкой OUT интервала воспроизведения на оси времени. Как показано на фиг.8, список воспроизведения файлов составлен из одного или множества элементов воспроизведения.

Первый слева список воспроизведения на фиг.8 составлен из двух элементов воспроизведения, при этом участок первой половины и участок последней половины потока AV, включенных в клип на левой стороне, определяются, соответственно, этими двумя элементами воспроизведения.

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

Третий слева список воспроизведения составлен из двух элементов воспроизведения, и некоторый участок потока AV, включенный в клип на левой стороне, и определенный участок потока AV, включенный в клип на правой стороне, определяются, соответственно, этими двумя элементами воспроизведения.

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

В списке воспроизведения путь воспроизведения, составленный из массива из одного или более элементов воспроизведения, определяется как главный путь (Main Path).

Аналогично, в списке воспроизведения путь воспроизведения, составленный из массива из одного или более подпунктов воспроизведения, параллельных главному пути, определяется как дополнительный путь (Sub Path).

Фиг.9 является схемой, иллюстрирующей структуру главного пути (Main Path) и дополнительного пути (Sub Path).

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

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

Идентификаторы (IDs) устанавливаются в списке воспроизведения, составляющем главный путь, в порядке расположения от заголовка. Идентификаторы (IDs) также устанавливаются для дополнительных путей SubPath_id=0, SubPath_id=1, SubPath_id=2 в порядке от заголовка.

В примере, показанном на фиг.9, один подэлемент воспроизведения SubPlayItem включается в Sub Path с идентификатором SubPath_id=0, а два подэлемента воспроизведения включаются в Sub Path с идентификатором SubPath_id=1. Аналогично, один подэлемент воспроизведения включается в Sub Path с идентификатором SubPath_id=2.

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

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

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

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

В потоке клипа Clip AV, имеющем отношение к одному из пунктов воспроизведения, поток видеоданных, нулевой или более потоки звуковых данных, которые воспроизводятся в синхронизации с нулевым или более потоками битовых данных заголовка (PG) и нулевым или более потоками интерактивной графики (IG), объединяются.

Кроме того, один подэлемент воспроизведения SubPlayItem относится к потоку видеоданных, потоку звуковых данных, потоку PG или подобному потоку, отличному от потока клипа Clip AV, относящегося к элементу воспроизведения PlayItem (другому потоку),

Управление потоками клипа Clip AV, использующих такой список воспроизведения, элемент воспроизведения и подэлемент воспроизведения, описаны, например, в публикации нерассмотренной заявки на патент Японии №2008-252740 и публикации нерассмотренной заявки на патент Японии №2005-348314.

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

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

Как показано на фиг.10, файлы иерархически управляются с помощью структуры каталога. Один корневой каталог создан на оптическом диске 2. В подчинении корневому каталогу находится область, которая управляется одной записывающей/воспроизводящей системой.

Каталог BDMV располагается под корневым каталогом.

Индексный файл (Index file), который является файлом с установленным именем "Index.bdmv", и файл MovieObject, который является файлом с установленным именем "MovieObject.bdmv", находятся непосредственно под каталогом BDMV.

Под каталогом BDMV обеспечиваются следующие каталоги: BACKUP, PLAYLIST, CLIPINF, STREAM и т.д.

Файлы Playlist, описывающие список воспроизведения, хранятся в каталоге PLAYLIST. Имя, составленное из пятизначного числа, и расширения ".mpls", устанавливается для каждого файла списка воспроизведения. Имя файла "00000.mpls" устанавливается для одного файла списка воспроизведения, показанного на фиг.10.

Файлы информации клипа сохраняются в директории CLIPINF. Имя, составленное из пятизначного числа, и расширения ".cpli", устанавливается для каждого файла информации клипа.

Имена файлов "00001.cpli", "O0002.cpli", и "00003.cpli" устанавливаются, соответственно, для трех файлов информации клипа на фиг.10. В дальнейшем файлы информации клипа, в случае необходимости, определяются как файлы "cpli".

Например, файл "00001.cpli" с расширением "cpli" является файлом, в котором описывается информация о клипе базового представления видеоданных.

Файл "O0002.cpli" с расширением "cpli" является файлом, в котором описывается информация о клипе представления D2 видеоданных.

Файл "00003.cpli" с расширением "cpli" является файлом, в котором описывается информация о клипе представления D1 видеоданных.

Файлы потока (Stream files) сохраняются в директории STREAM. Имя, составленное из пятизначного числа, и расширения ".m2ts", или имя, составленное из пятизначного числа, и расширения ".ilvt", устанавливаются для каждого файла потока. В дальнейшем файл, для которого устанавливается расширение ".m2ts", в случае необходимости, определяется как файл m2ts. Аналогично, файл, для которого устанавливается расширение ".ilvt", определяется как файл ilvt.

Файл с расширением m2ts "00001.m2ts" является файлом для двухмерного воспроизведения. Считывание потока базового представления видеоданных выполняется с помощью определения этого файла.

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

Файл с расширением ilvt "10000.ilvt" является файлом для воспроизведения B-D1. Считывание потока базового представления видеоданных и потока представления D1 видеоданных выполняется с помощью определения этого файла.

Файл с расширением ilvt "20000.ilvt" является файлом для воспроизведения B-D2. Считывание потока базового представления видеоданных и потока представления D2 видеоданных выполняется с помощью определения этого файла.

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

Синтаксис каждой части данных

Фиг.11 является схемой, иллюстрирующей синтаксис файла PlayList (список файлов для воспроизведения).

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

Индикатор типа файла type_indicator на фиг.11 представляет тип файла "xxxxx.mpls".

Номер версии version_number представляет номер версии"хххх.mpls". Номер версии version_number составлен из четырехзначного числа. Например, "0240" представляет версию "3D Spec version", установленную в файле PlayList для трехмерного воспроизведения.

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

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

ExtensionData_start_adress представляет стартовый адрес ExtensionData() с количеством относительных байтов от первого байта файла PlayList, равным единице.

160 бит reserved_for_future_use (зарезервировано для будущего использования) содержатся после ExtensionData_start_adress.

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

Параметры, относящиеся к Main Path, Sub Path и т.д., хранятся в файле PlayList(). Содержимое PlayList() будет описано ниже.

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

Личные данные могут быть вставлены в ExtensionData().

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

Как показано на фиг.12, в файле PlayList описываются двухбитовые 3D_PL_type и однобитовые view_type.

Параметр "3D_PL_type" представляет тип файла со списком воспроизведения PlayList.

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

Фиг.13 является схемой, иллюстрирующей значения величин параметра "3D_PL_type".

Значение 00 параметра "3D_PL_type" представляет список воспроизведения PlayList для двухмерного воспроизведения.

Значение 01 параметра "3D_PL_type" представляет список воспроизведения PlayList для трехмерного воспроизведения B-D1 типа.

Значение 10 параметра "3D_PL_type" представляет список воспроизведется PlayList для трехмерного воспроизведения B-D2 типа.

Например, в том случае, когда значение параметра "3D_PL_type" составляет 01 или 10, информация 3DPlayList регистрируется в ExtensitionData() файла PlayList. Например, как информация 3DPlayList регистрируется информация о считывании потока базового представления видеоданных и поток зависимого представления видеоданных с оптического диска 2.

Фиг.14 является схемой, иллюстрирующей значения величин параметра “View_type”.

В случае выполнения трехмерного воспроизведения, значение 0 параметра "View_type" означает, что поток базового представления видеоданных является левым потоком представления видеоданных. В случае выполнения двухмерного воспроизведения значение 0 параметра "View_type" означает, что поток базового представления видеоданных является потоком AVC видеоданных.

Значение 1 параметра "View_type" означает, что поток базового представления видеоданных является правым потоком представления видеоданных.

Описание параметра "View_type" в файле PlayList дает возможность устройству 1 воспроизведения идентифицировать, является ли поток базового представления видеоданных левым L или правым R потоком представления видеоданных.

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

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

Фиг.15 является схемой, иллюстрирующей синтаксис файла PlayList(), показанного на фиг.11.

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

16-битовая область "reserved_for_future_use" подготовлена после длины "length".

Параметр "number_of_PlayItems" является 16-битовым полем, показывающим количество пунктов воспроизведения, существующих в списке воспроизведения. В случае примера, показанного на фиг.9, количество пунктов воспроизведения составляет 3. Значение PlayItem_id назначается от 0 в том порядке, как пункты воспроизведения PlayItem() появляются в списке воспроизведения. Например, на фиг.9 назначаются PlayItem_id=0, 1 и 2.

Параметр "number_of_SubPaths" является 16-битовым полем, показывающим количество SubPaths, существующих в списке воспроизведения. В случае примера, показанного на фиг.9, количество SubPath составляет 3. Значение SubPath_id назначается от 0 в том порядке, как SubPath() появляются в списке воспроизведения. Например, на фиг.9 назначаются SubPath_id=0, 1 и 2. В дальнейшем предложение PlayItem() определяется с помощью количества элементов воспроизведения PlayItems, a предложение SubPaths() определяется с помощью количества SubPaths.

Фиг.16 является схемой, иллюстрирующей синтаксис параметра "SubPath()", показанного на фиг.15.

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

16-битовая область "reserved_for_future_use" подготовлена после длины "length".

Параметр "SubPath_type" является 8-битовым полем, показывающим тип применения Sub Path. Параметр "SubPath_type" используется для отображения типа, например, является ли Sub Path звуковым сигналом, заголовком битовой матрицы или текстовым заголовком.

15-битовая область "reserved_for_future_use" подготовлена после "SubPath_type".

Параметр "is_repeat_SubPath" является однобитовым полем, определяющим способ воспроизведения Sub Path, и отображает, выполняется ли неоднократно воспроизведение Sub Path во время воспроизведения Main Path, или воспроизведение Sub Path выполняется однократно. Например, это поле используется в том случае, когда распределения по времени клипа, относящегося к Main Path, и клипа, относящегося к Sub Path, являются различными (в случае, когда Main Path используется как путь для демонстрации слайдов неподвижных изображений, и когда Sub Path используется как путь для звукового сигнала, служащего, например, в качестве BGM).

8-битовая область "reserved_for_future_use" подготовлена после "is_repeat_SubPath".

Параметр "number_of_SubPlayItems" является 8-битовым полем, показывающим количество SubPlayItem (количество записей), существующих в одном Sub Path. Например, параметр "number_of_SubPlayItems" для показанных на фиг.9 SubPlayItem при SubPath_id=0, составляет 1, a "number_of_SubPlayItem" для SubPlayItem при SubPath_id=1 составляет 2. В последующем предложение SubPlayItem() определяется с помощью количества SubPlayItem.

Фиг.17 является схемой, иллюстрирующей синтаксис параметра "SubPlayItem(i)", показанного на фиг.16.

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

"SubPlayItem(i)" на фиг.17 описывается для обоих случаев: когда SubPlayItem относится к одному клипу и когда SubPlayItem относится к множеству клипов.

Описание будет дано для случая, когда SubPlayItem относится к одному клипу.

Параметр "Clip_Information_file_name[0]" представляет клип, к которому будут обращаться.

Параметр "Clip_codec_identifier[0]" представляет способ сжатия/восстановления данных для клипа. Параметр "reserved_for_future_use" присоединяется после "Clip_codec_identifier[0]".

Параметр "is_multi_Clip_entries" является флажком, показывающим, регистрируются или нет множество клипов. Если флажок "is_multi_Clip_entries" занимает свое положение, то система обращается к синтаксису для случая, когда SubPlayItem обращается к множеству клипов.

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

Параметр "SubPlayItem_IN_time" представляет начальное положение интервала воспроизведения Sub Path, a "SubPlayItem_OUT_time" представляет конечное положение.

Параметры "sync_PlayItem_id" и "sync_start_PTS_of_PlayItem" представляют время, когда Sub Path запускает воспроизведение на оси времени Main Path.

Параметры "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_Infomation_file_name[0]".

Параметр "Clip_codec_identifier[SubClip_entry_id]" представляет способ сжатия/восстановления данных для клипа,

Параметр "ref_to_STC_id[SubClip_entry_id]" является информацией о точке прерывания STC (точке прерывания на оси системного времени). Параметр "reserved_for_future_use" присоединяется после "ref_to_STC_id[SubClip_entry_id]".

Фиг.18 является схемой, иллюстрирующей синтаксис параметра "PlayItem()", показанного на фиг.15.

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

Параметр "Clip_Information_file_name[0]" представляет имя файла информации о том клипе, который будет определяться элементом списка воспроизведения PlayItem. Следует заметить, что то же самое 5-значное число включено в имя файла с расширением mt2s, т.е. файла, включающего в себя клип, и в имя файла информации о клипе, соответствующей ему.

Параметр "Clip_codec_identifier[0]" представляет способ сжатия/восстановления клипа. Параметр "reserved_for_future_use" присоединяется после "Clip_codec_identifier[0]". Параметры "is_multi_angle" и "connection_condition" присоединяются после "reserved_for_future_use".

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

Параметр "IN_time" представляет начальное положение интервала воспроизведения элемента списка воспроизведения, a "OUT_time" представляет его конечное положение.

Параметры "UO_mask_table()" "PlayItem_random_access_mode" и "still_mode" присоединяются после "OUT_time".

Параметр "STN_table()" включает в себя информацию о потоке AV, определяемом с помощью целевого элемента списка воспроизведения. Аналогично, в том случае, когда существует Sub Path, который должен воспроизводиться, в то же время являясь связанным с целевым элементом PlayItem списка воспроизведения, информация о потоке AV, определяемом подпунктом списка воспроизведения SubPlayItem и составляющем Sub Path, также присоединяется.

Фиг.19 является схемой, иллюстрирующей синтаксис параметра "STN_table()", показанного на фиг.18.

Параметр "STN_table()" устанавливается как атрибут элемента PlayItem списка воспроизведения.

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

Параметр "number_of_video_stream_entries" представляет количество потоков, которые внесены (зарегистрированы) в таблице STN_table() и которые снабжены "video_stream_id".

Параметр "video_stream_id" является информацией для идентификации потока видеоданных. Например, поток базового представления видеоданных определяется с помощью этого параметра "video_stream_id".

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

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

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

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

Параметр "number_of_PG_txtST_stream_entries" представляет количество потоков, снабженных "PG_txtST_stream_id", которые внесены в таблицу STN_table(). В числе этих потоков вводятся PG stream и text caption file (txtST), полученные при выполнении кодирования длительности последовательности импульсов в заголовке битовой матрицы. Параметр "PG_txtST_stream_id" является информацией для идентификации заголовка потока, a "PG_txtST_stream_number" является номером потока заголовка, который используется для переключения заголовка и который наблюдается пользователем.

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

Идентификаторы ID Main TS и Sub TS также регистрируются в таблице STN_table(). В параметре "stream_attribute()" описывается, что идентификатор ID не является идентификатором первичного потока, но является идентификатором TS.

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

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

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

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

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

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

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

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

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

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

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

Фиг.21 является схемой, иллюстрирующей пример конфигурации модуля 56 декодера, показанного на фиг.20.

Фиг.21 иллюстрирует конфигурацию для обработки видеосигнала. В декодирующем модуле 56 также выполняется процесс декодирования звукового сигнала. Результат выполненного процесса декодирования звукового сигнала выводится к устройству 3 отображения через путь, который не показан.

Фильтр 101 типа PID (пропорционально-интегрально-дифференциальное (ПИД-регулирование)) устанавливает, является ли TS, подаваемое из дисковода 52, или локального запоминающего устройства 54, Main TS или Sub TS, на основе ПИД-регулирования пакетов, составляющих TS, или идентификатор потока. Фильтр 101 типа PID выводит Main TS к буферу 102 и выводит Sub TS к буферу 103.

Фильтр 104 типа PID последовательно считывает пакеты Main TS, хранящиеся в буфере 102, и сортирует их на основе ПИД- регулирования пакетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модуль 112 генерирования плоскости видеоизображения В генерирует плоскость базового представления видеоданных на основе данных, поставляемых от переключателя 111, и выводит их в объединяющий модуль 130.

Модуль 113 генерирования плоскости видеоизображения D генерирует плоскость зависимого представления видеоданных на основе данных, поставляемых от переключателя 111, и выводит их в объединяющий модуль 130.

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

Декодер 116 В IG декодирует пакеты, составляющие базовый IG поток, сохраняемый в буфере 115 В IG, и выводит данные, полученные через декодирование, к модулю 117 генерирования плоскости В IG.

Модуль 117 генерирования плоскости В IG генерирует плоскость базового IG на основе данных, поставляемых из декодера 116 В IG, и выводит их в объединяющий модуль 130.

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

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

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

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

Декодер 124 В PG декодирует пакеты, составляющие базовый PG поток, сохраняемый в буфере 123 В PG, и выводит данные, полученные через декодирование, к модулю 125 генерирования плоскости В PG.

Модуль 125 генерирования плоскости В PG генерирует плоскость базового PG на основе данных, поставляемых из декодера 124 В PG, и выводит их в объединяющий модуль 130.

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

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

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

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

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

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

Первый пример T-STD (Система транспортного потока. Целевой декодер.)

Сейчас будет дано описание конфигурации декодера и его окружения в конфигурации, проиллюстрированной на фиг.21.

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

На фиг.22 конфигурации, аналогичные тем, которые показаны на фиг.21, обозначаются теми же самыми цифровыми ссылками. Фиг.22 иллюстрирует PID-фильтр 104, буфер 106 видео В, переключатель 107, буфер 108 видео D, переключатель 109, видеодекодер 110 и буфер 151 DPB (Decoded Picture Buffer - Буфер декодированного кадра). Хотя буфер 151 DPB не показан на фиг.21, этот буфер 151 DPB, который сохраняет данные декодированного изображения, обеспечивается на последующем каскаде видеодекодера 110.

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

Например, PID=0 присваивается как фиксированное значение PID для пакетов, составляющих поток базового представления видеоданных. Аналогично, фиксированное значение, отличающееся от нуля, присваивается как PID для пакетов, составляющих поток зависимого представления видеоданных.

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

Пакеты, выводимые в буфер 106 видео В, сохраняются в VSB₁ через ТВ (Transport buffer - транспортный буфер)) и MB (Multiplexing Buffer - мультиплексирующий буфер). Данные элементарного потока базового представления видеоданных сохраняются в VSB₁.

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

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

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

Пакеты, выводимые в буфер 108 видео D, сохраняются в VSB₂ через ТВ₂ и МВ₂. Данные элементарного потока зависимого представления видеоданных сохраняются в VSB₂.

Переключатель 109 последовательно считывает пакеты базового представления видеоданных, сохраняемые в VSB₁ буфера 106 видео В, и пакеты, составляющие поток зависимого представления видеоданных, сохраняемые в VSB₂ буфера видео D, и выводит их к видеодекодеру 110.

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

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

В пакете, который сохраняет данные некоторого кадра базового представления видеоданных, и пакете, который сохраняет данные некоторого кадра зависимого представления видеоданных, соответствующего ему, та же самая временная информация с помощью PCR-синхронизации (Program Clock Reference - временная отметка программы) устанавливается на время кодирования. Даже если поток базового представления видеоданных и поток зависимого представления видеоданных включены в различные TS, одинаковая временная информация устанавливается для пакетов, которые сохраняют данные изображений, соответствующих друг другу.

Временная информация может быть DTS (Decoding Time Stamp - отметка времени декодирования) и PTS (Presentation Time Stamp - отметка времени воспроизведения), при этом она устанавливается для каждого пакета PES (Packetized Elementary Stream - пакетизированный элементарный поток).

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

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

В том случае, когда структура GOP потока базового представления видеоданных и структура GOP потока зависимого представления видеоданных являются такими же, как описано ниже, то кадры, соответствующие друг другу в порядке декодирования, также соответствуют друг другу в порядке отображения.

В том случае, когда передача пакетов осуществляется последовательно, DTS₁ пакета, считанного из VSB₁ буфера 106 видео В в определенный момент времени, и DTS₂? пакета, считанного из VSB₂ буфера 108 видео D в непосредственно в следующий момент времени, относятся к одному и тому же времени, как показано на фиг.22.

Переключатель 109 выводит пакеты базового представления видеоданных, считанных из VSB₁, буфера 106 видео В, или пакеты зависимого представления видеоданных, считанных из VSB₂, буфера 108 видео D, к видеодекодеру 110.

Видеодекодер 110 последовательно декодирует пакеты, поставляемые от переключателя 109, и вызывает сохранение с помощью буфера DPB 151 данных кадра базового представления видеоданных, или данных кадра зависимого представления видеоданных, полученных через декодирование.

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

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

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

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

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

Аналогично, согласно модели декодера, показанной на фиг.22, даже в том случае, когда поток базового представления видеоданных и поток зависимого представления видеоданных включаются в различные TS, пакеты могут быть доставлены к видеодекодеру 110 с корректным распределением по времени благодаря одинаковым DTS.

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

Второй пример

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

Фиг.24 иллюстрирует переключатель 111, модуль 161 генерирования левой L видеоплоскости и модуль 162 генерирования правой R видеоплоскости, в добавление к конфигурации, показанной на фиг.22. PID-фильтр 105 также показан в предыдущей ступени перед переключателем 107. Избыточное описание будет опущено в случае необходимости.

Модуль 161 генерирования левой L видеоплоскости, который генерирует плоскость левого L представления видео, обеспечивается вместо модуля 112 генерирования видеоплоскости В, показанного на фиг.21.

Модуль 162 генерирования правой R видеоплоскости, который генерирует плоскость правого R представления видео, обеспечивается вместо модуля 113 генерирования видеоплоскости D, показанного на фиг.21.

В этом примере переключателю 111 необходимо выводить видеоданные левого L представления видео и видеоданные правого R представления видео, производя их идентификацию.

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

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

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

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

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

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

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

Модуль 161 генерирования левой L видеоплоскости генерирует плоскость левого L представления видео на основе данных, поставляемых от переключателя 111, и выводит их в объединяющий модуль 130.

Модуль 162 генерирования правой R видеоплоскости генерирует плоскость правого R представления видео на основе данных, поставляемых от переключателя 111, и выводит их в объединяющий модуль 130.

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

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

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

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

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

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

Во время кодирования в H.264 AVC/MVC параметр "view_id" устанавливается в блоке доступа Access Units, составляющих поток результата кодирования. С помощью параметра "view_id" может быть идентифицирован компонент представления, соответствующий каждому блоку Access Unit.

Фиг.25 является схемой, иллюстрирующей пример блока доступа Access Units.

Блок доступа Access Unit #1 на фиг.25 является блоком, включающим в себя данные базового представления видеоданных. Блок доступа Access Unit #2 является блоком, включающим в себя данные зависимого представления видеоданных. Access Unit является блоком, включающим в себя данные, например, одного изображения, таким образом доступ может быть осуществлен в блоках кадров.

С кодированием в Н.264 AVC/MVC данные каждого изображения базового представления видеоданных и зависимого представления видеоданных сохраняются в таких блоках доступа Access Units. Во время кодирования в Н.264 AVC/MVC заголовок MVC добавляется к каждому компоненту представления, как показано в Access Unit #2. Заголовок MVC включает в себя параметр "view_id".

В случае примера, показанного на фиг.25, для Access Unit #1 может быть идентифицировано с помощью параметра "view_id", что компонент представления, сохраняемый в блоке доступа Access Unit, является зависимым представлением видеоданных.

С другой стороны, как показано на фиг.25, никакого заголовка MVC не добавляется к базовому представлению видеоданных, которое является компонентом представления, сохраняемым в Access Unit #1.

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

Устройство 1 воспроизведения определено (установлено) распознавать, что параметр "view_id" компонента представления без заголовка MVC равен нулю, и распознавать этот компонент представления как базовое представление видеоданных. Значение, отличающееся от нуля, устанавливается как параметр "view_id" для зависимого представления видеоданных во время кодирования.

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

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

Третий пример

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

В примере, показанном на фиг.26, модуль 112 генерирования плоскости видеоизображения В обеспечивается вместо модуля 161 генерирования левой L видеоплоскости, показанного на фиг.24, а модуль 113 генерирования плоскости видеоизображения D обеспечивается вместо модуля 162 генерирования правой R видеоплоскости. Переключатель 171 обеспечивается в последующей ступени модуля 112 генерирования плоскости видеоизображения В и модуля 113 генерирования плоскости видеоизображения D. В конфигурации, показанной на фиг.26, также пункт назначения для вывода данных переключается на основе параметра "view_type".

Переключатель 111 выводит к модулю 112 генерирования плоскости видеоизображения В данные, полученные с помощью декодирования пакета базового представления видеоданных, на основе данных, сохраняемых в DPB 151. Аналогично, переключатель 111 выводит данные, полученные с помощью декодирования пакета зависимого представления видеоданных, к модулю 113 генерирования плоскости видеоизображения D.

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

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

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

Параметр "view_type", описываемый в файле PlayList со списком воспроизведения, поступает из контроллера 51 к переключателю 171.

В том случае, когда значение параметра "view_type" составляет 0, переключатель 171 выводит плоскость базового представления видеоданных, поступающую из модуля 112 генерирования плоскости видеоизображения В, к объединяющему модулю 130 как плоскость левого L представления видеоданных. Значение 0 параметра "view_type" означает, что поток базового представления видеоданных является потоком левого L представления видеоданных.

Кроме того, в этом случае переключатель 171 выводит плоскость зависимого представления видеоданных, поступающую из модуля 113 генерирования плоскости видеоизображения D, к объединяющему модулю 130 как плоскость правого R представления видеоданных.

С другой стороны, в том случае, когда значение параметра "view_type" составляет 1, переключатель 171 выводит плоскость зависимого представления видеоданных, поступающую из модуля 113 генерирования плоскости видеоизображения D, к объединяющему модулю 130 как плоскость левого L представления видеоданных. Значение 1 параметра "view_type" означает, что поток базового представления видеоданных является потоком правого R представления видеоданных.

Кроме того, в этом случае переключатель 171 выводит плоскость базового представления видеоданных, поступающую из модуля 112 генерирования плоскости видеоизображения В, к объединяющему модулю 130 как плоскость правого R представления видеоданных.

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

Первый пример модели объединения плоскостей

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

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

Пакеты, составляющие поток IG, включенные в Main TS или Sub TS, вводятся в переключатель 181. Пакеты, составляющие поток IG, которые вводятся в переключатель 181, включают в себя пакет базового представления видеоданных и пакет зависимого представления видеоданных.

Пакеты, составляющие поток PG, включенные в Main TS или Sub TS, вводятся в переключатель 182. Пакеты, составляющие поток PG, которые вводятся в переключатель 182, включают в себя пакет базового представления видеоданных и пакет зависимого представления видеоданных.

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

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

Аналогично, PG базового представления отображается с помощью объединения с базовым представлением видеоданных, а PG зависимого представления отображается с помощью объединения с зависимым представлением видеоданных, таким образом пользователь наблюдает текст заголовка или подобное изображение в трехмерном представлении, так же как и видео.

Переключатель 181 выводит пакеты, составляющие базовый поток IG, к декодеру 116 В IG, и выводит пакеты, составляющие зависимый поток IG, к декодеру 120 D IG. Переключатель 181 имеет функции переключателя 114 и переключателя 118, показанных на фиг.21. На фиг.27 иллюстрация отдельных буферов пропущена.

Декодер 116 В IG декодирует пакеты, составляющие базовый поток IG, поступающий от переключателя 181, и выводит данные, полученные через декодирование, к модулю 117 генерирования плоскости В IG.

Модуль 117 генерирования плоскости В IG генерирует плоскость базового IG на основе данных, поставляемых из декодера 116 В IG, и выводит их в объединяющий модуль 130.

Декодер 120 D IG декодирует пакеты, составляющие зависимый поток IG, поступающий от переключателя 181, и выводит данные, полученные через декодирование, к модулю 121 генерирования плоскости D IG. Базовый поток IG и зависимый поток IG могут декодироваться одним декодером.

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

Переключатель 182 выводит пакеты, составляющие базовый поток PG к декодеру 124 В PG, и выводит пакеты, составляющие зависимый поток PG к декодеру 128 D PG. Переключатель 182 имеет функции переключателя 122 и переключателя 126, показанных на фиг.21.

Декодер 124 В PG декодирует пакеты, составляющие базовый поток PG, поступающий от переключателя 182, и выводит данные, полученные через декодирование, к модулю 125 генерирования плоскости В PG.

Модуль 125 генерирования плоскости В PG генерирует плоскость базового PG на основе данных, поставляемых из декодера 124 В PG, и выводит их в объединяющий модуль 130.

Декодер 128 D PG декодирует пакеты, составляющие зависимый поток PG, поступающий от переключателя 182, и выводит данные, полученные через декодирование, к модулю 129 генерирования плоскости D PG. Базовый поток PG и зависимый поток PG могут декодироваться одним декодером.

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

Видеодекодер 110 последовательно декодирует пакеты, поставляемые от переключателя 109 (фиг.22 и далее), и выводит данные базового представления видео или данные зависимого представления видео, полученные через декодирование, к переключателю 111.

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

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

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

Объединяющий модуль 130 включает в себя суммирующие модули со 191 по 194 и переключатель 195.

Суммирующий модуль 191 накладывает плоскость зависимого PG, поставляемую из модуля 129 генерирования плоскости D PG, на плоскость зависимого представления видео, поставляемую из модуля 113 генерирования плоскости видеоизображения D, таким образом, чтобы объединить плоскости и вывести результат этого объединения к суммирующему модулю 193. Процесс преобразования цветовой информации (CLUT - Color Look Up Table - таблица преобразования цветовой палитры) осуществляется на плоскости зависимого PG, поставляемой из модуля 129 генерирования плоскости D PG к суммирующему модулю 191.

Суммирующий модуль 192 накладывает плоскость базового PG, поставляемую из модуля 125 генерирования плоскости В PG, на плоскость базового представления видео, поставляемую из модуля 112 генерирования плоскости видеоизображения В, таким образом, чтобы объединить плоскости, и выводит результат этого объединения к суммирующему модулю 194. Процесс преобразования цветовой информации и процесс коррекции, использующий значение смещения, выполняется на плоскости базового PG, поставляемой из модуля 125 генерирования плоскости В PG к суммирующему модулю 192.

Суммирующий модуль 193 накладывает плоскость зависимого IG, поставляемую из модуля 121 генерирования плоскости D IG, на результат объединения, полученный в суммирующем модуле 191, таким образом, чтобы объединить их и вывести результат этого объединения как плоскость зависимого представления видео. Процесс преобразования цветовой информации осуществляется на плоскости зависимого IG, поставляемой из модуля 121 генерирования плоскости D IG к суммирующему модулю 193.

Суммирующий модуль 194 накладывает плоскость базового IG, поставляемую из модуля 117 генерирования плоскости В IG, на результат объединения, полученный в суммирующем модуле 192, таким образом, чтобы объединить их, и вывести результат этого объединения как плоскость базового представления видео. Процесс преобразования цветовой информации и процесс коррекции, использующий значение смещения, осуществляются на плоскости базового IG, поставляемой из модуля 121 генерирования плоскости D IG к суммирующему модулю 194.

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

В том случае, когда значение параметра "view_type" составляет 0, переключатель 195 выводит плоскость базового представления как плоскость левого L представления и выводит плоскость зависимого представления как плоскость правого R представления. Параметр "view_type" поступает из контроллера 51 к переключателю 195.

Кроме того, в том случае, когда значение параметра "view_type" составляет 1, переключатель 195 выводит плоскость базового представления как плоскость правого R представления и выводит плоскость зависимого представления как плоскость левого L представления. Какая из поставляемых плоскостей является плоскостью базового представления или плоскостью зависимого представления, идентифицируется на основе параметров PID и "view_id".

Таким образом, в устройстве 1 воспроизведения выполняется объединение плоскостей базового представления, плоскостей зависимого представления и плоскостей видеоизображения, IG и PG.

На стадии, когда завершение объединения всех плоскостей видеоизображения, IG и PG закончено, на основе параметра "view_type" определяется, является ли результат объединения плоскостей базового представления левым L представлением или правым R представлением, и выводятся плоскость правого R представления и плоскость левого L представления видеоизображения.

Аналогично, на стадии, когда завершение объединения всех плоскостей видеоизображения, IG и PG закончено, на основе параметра "view_type" определяется, является ли результат объединения плоскостей зависимого представления левым L представлением или правым R представлением, и выводятся плоскость правого R представления и плоскость левого L представления.

Второй пример

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

В конфигурации, показанной на фиг.28, конфигурации, аналогичные показанным на фиг.27, обозначаются одинаковыми цифровыми ссылками. Конфигурация объединяющего модуля 130, показанная на фиг.28, отличается от конфигурации на фиг.27. Кроме того, функционирование переключателя 111, показанного на фиг.28, отличается от функционирования переключателя 111, показанного на фиг.27. Модуль 161 генерирования левой L видеоплоскости обеспечивается вместо модуля 112 генерирования плоскости видеоизображения В, а модуль 162 генерирования правой R видеоплоскости обеспечивается вместо модуля 113 генерирования видеоплоскости D. Избыточное описание будет опущено.

Одинаковое значение параметра "view_type" поступает из контроллера 51 к переключателю 111, а также к переключателям 201 и 202 объединяющего модуля 130.

Переключатель 111 осуществляет переключение аналогично переключателю 111 на фиг. 24 адресов назначения для вывода данных, полученных с помощью декодирования пакета базового представления видео, и данных, полученных с помощью декодирования пакета зависимого представления видео, на основе параметра "view_type".

Например, в том случае, когда значение параметра "view_type" составляет 0, переключатель 111 выводит данные, полученные с помощью декодирования пакета базового представления видео к модулю 161 генерирования левой L видеоплоскости. В этом случае переключатель 111 выводит данные, полученные с помощью декодирования пакета зависимого представления видео к модулю 162 генерирования правой R видеоплоскости.

С другой стороны, в том случае, когда значение параметра "view_type" составляет 1, переключатель 111 выводит данные, полученные с помощью декодирования пакета базового представления видео к модулю 162 генерирования правой R видеоплоскости. В этом случае переключатель 111 выводит данные, полученные с помощью декодирования пакета зависимого представления видео к модулю 161 генерирования левой L видеоплоскости.

Модуль 161 генерирования левой L видеоплоскости генерирует плоскость левого L представления видео на основе данных, поставляемых от переключателя 111, и выводит их в объединяющий модуль 130.

Модуль 162 генерирования правой R видеоплоскости генерирует плоскость правого R представления видео на основе данных, поставляемых от переключателя 111, и выводит их в объединяющий модуль 130.

Объединяющий модуль 130 включает в себя переключатель 201, переключатель 202 и суммирующие модули с 203 по 206.

Переключатель 201 переключает адреса назначения для вывода данных плоскости базового IG, поставляемой из модуля 117 генерирования плоскости В IG, и плоскости зависимого IG, поставляемой из модуля 121 генерирования плоскости D IG, на основе параметра "view_type".

Например, в том случае, когда значение параметра "view_type" составляет 0, то переключатель 201 выводит плоскость базового IG, поставляемую из модуля 117 генерирования плоскости В IG, к суммирующему модулю 206 как плоскость левого L представления. В этом случае переключатель 201 выводит плоскость зависимого IG, поставляемую из модуля 121 генерирования плоскости D IG, к суммирующему модулю 205 как плоскость правого R представления.

С другой стороны, в том случае, когда значение параметра "view_type" составляет 1, то переключатель 201 выводит плоскость зависимого IG, поставляемую из модуля 121 генерирования плоскости D IG, к суммирующему модулю 206 как плоскость левого L представления. В этом случае переключатель 201 выводит плоскость базового IG, поставляемую из модуля 117 генерирования плоскости В IG, к суммирующему модулю 205 как плоскость правого R представления.

Переключатель 202 переключает адреса назначения для вывода данных плоскости базового PG, поставляемой из модуля 125 генерирования плоскости В PG, и плоскости зависимого PG, поставляемой из модуля 129 генерирования плоскости D PG, на основе параметра "view_type".

Например, в том случае, когда значение параметра "view_type" составляет 0, то переключатель 202 выводит плоскость базового PG, поставляемую из модуля 125 генерирования плоскости В PG, к суммирующему модулю 204 как плоскость левого L представления. В этом случае переключатель 202 выводит плоскость зависимого PG, поставляемую из модуля 129 генерирования плоскости D PG, к суммирующему модулю 203 как плоскость правого R представления.

С другой стороны, в том случае, когда значение параметра "view_type" составляет 1, то переключатель 202 выводит плоскость зависимого PG, поставляемую из модуля 129 генерирования плоскости D PG, к суммирующему модулю 204 как плоскость левого L представления. В этом случае переключатель 202 выводит плоскость базового PG, поставляемую из модуля 125 генерирования плоскости В PG, к суммирующему модулю 203 как плоскость правого R представления.

Суммирующий модуль 203 накладывает плоскость PG правого R представления, поставляемую из переключателя 202, на плоскость правого R представления видео, поставляемую из модуля 162 генерирования правой R видеоплоскости, таким образом чтобы объединять плоскости, и выводит результат объединения к суммирующему модулю 205.

Суммирующий модуль 204 накладывает плоскость PG левого L представления, поставляемую из переключателя 202, на плоскость левого L представления видео, поставляемую из модуля 161 генерирования левой L видеоплоскости, таким образом чтобы объединить плоскости, и выводит результат объединения к суммирующему модулю 206.

Суммирующий модуль 205 накладывает плоскость IG правого R представления, поставляемую из переключателя 201, на плоскость, являющуюся результатом объединения, полученного в суммирующем модуле 203, таким образом чтобы объединить плоскости и выводит результат объединения как плоскость правого R представления.

Суммирующий модуль 206 накладывает плоскость IG левого L представления, поставляемую из переключателя 201, на плоскость, являющуюся результатом объединения, полученного в суммирующем модуле 204 таким образом, чтобы объединить плоскости, и выводит результат объединения, как плоскость левого L представления.

Таким способом в устройстве 1 воспроизведения определяется, является ли каждая плоскость базового представления и плоскость зависимого представления видео, IG и PG плоскостью левого L представления или плоскостью правого R представления, перед объединением с другой плоскостью.

После того, как определение было выполнено, объединение плоскостей видеоизображения, IG и PG осуществляется таким образом, чтобы объединять одну с другой плоскости левого L представления, а также объединять одну с другой плоскости правого R представления.

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

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

Видеокодирующее устройство 311 имеет такую же конфигурацию, как и кодирующее устройство 11 MVC на фиг.3. Видеокодирующее устройство 311 кодирует множество элементов видеоданных в соответствии с Н.264 AVC/MVC, таким образом генерируя поток базового представления видео и поток зависимого представления видео и выводит их в буфер 312.

Например, видеокодирующее устройство 311 устанавливает DTS (data transfer system - система передачи данных) и PTS с одинаковым PCR как опорные значения во время кодирования. То есть видеокодирующее устройство 311 устанавливает одинаковое значение DTS в пакете PES (пакета в составе пакетированного элементарного потока), который сохраняет данные определенного изображения базового представления видео и пакете PES, который сохраняет данные определенного изображения зависимого представления видео, соответствующие изображению в порядке декодирования.

Аналогично, видеокодирующее устройство 311 устанавливает одинаковое PTS для пакета PES, который сохраняет данные определенного изображения базового представления видео и пакета PES, который сохраняет данные изображения зависимого представления видео, соответствующие изображению в порядке отображения.

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

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

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

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

Кодирующее устройство 315 данных кодирует описанные выше различные типы данных, не являющихся видеоданными и звуковыми данными, например такими как файл со списком воспроизведения PlayList, и выводит полученные в результате кодирования данные в буфер 316.

Кодирующее устройство 315 данных устанавливает параметр "view_type", представляющий, является ли поток базового представления видео потоком левого L представления или потоком правого R представления, в файл со списком воспроизведения PlayList, в соответствии с кодированием, выполненным видеокодирующим устройством 311. Информация, показывающая, является ли поток зависимого представления видеопотоком левого L представления или потоком правого R представления, может быть установлена вместо типа потока базового представления видео.

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

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

Модуль 318 коррекции ошибок кодирования добавляет код для коррекции ошибок к мультиплексированным данным с помощью модуля 317 мультиплексирования.

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

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

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

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

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

В модуле 332 изготовления мастер-диска для записи подготавливается мастер-диск, выполненный из стекла или подобного материала, на который накладывается записывающий материал, включающий в себя фоторезист или подобный материал. Таким образом изготавливается мастер-диск для записи.

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

В модуле 334 изготовления металлического мастер-диска такой процесс, как гальванопластика осуществляется на мастер-диске, то есть изготавливается металлический мастер-диск, на который переносятся питы, имеющиеся на стеклянном мастер-диске. Кроме того, из этого металлического мастер-диска изготавливается металлическая матрица, которая используется как пресс-форма.

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

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

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

Второй вариант осуществления изобретения

Операция 1 потока видеоизображения Н.264 AVC/MVC Profile

В стандарте BD-ROM (Blu-Ray Disk), который является стандартом оптического диска 2, кодирование трехмерного 3D видеоизображения реализуется с использованием H.264 AVC/MVC Profile, как описывалось выше.

Кроме того, в стандарте BD-ROM поток базового представления видеоизображения рассматривается как поток видеоизображения левого L представления, а поток зависимого представления видеоизображения рассматривается как поток видеоизображения правого R представления.

Базовое представление видео кодируется как видеопоток Н.264 AVC/MVC Profile, таким образом оптический диск 2, который является диском, совместимым с трехмерным изображением, может воспроизводиться даже в морально устаревшем устройстве воспроизведения или устройстве воспроизведения, совместимом только с двухмерным воспроизведением. То есть может быть гарантирована обратная совместимость.

В частности, только поток базового представления видео может быть декодирован (воспроизведен) даже в декодере, несовместимом с Н.264 AVC/MVC. То есть поток базового представления видео является потоком, который может быть надежно воспроизведен даже в существующем двухмерном устройстве воспроизведения типа BD.

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

Фиг.31 является схемой, иллюстрирующей пример конфигурации генерирующего модуля TS для трехмерного видеоизображения 3D video TS, обеспеченного в записывающем устройстве.

Генерирующий модуль для трехмерного видео 3D video TS, показанный на фиг.31, включает в себя кодирующее устройство 401 MVC, модуль 402 удаления заголовка MVC и мультиплексор 403. Данные видео #1 левого L представления и данные видео #1 правого R представления, которые сняты с помощью способа, описанного со ссылкой на фиг.2, вводятся в кодирующее устройство 401.

Аналогично MVC кодирующему устройству 11 на фиг.3, MVC кодирующее устройство 401 кодирует данные видео #1 левого L представления с использованием Н.264 AVC и выводит AVC видеоданные, полученные через кодирование, как поток базового представления видео. Таким же образом MVC кодирующее устройство 401 генерирует поток зависимого представления видео на основе данных видео #1 левого L представления и данных видео #2 правого R представления и выводит их.

Вывод потока базового представления видео из MVC кодирующего устройства 401 составлен из блоков доступа Access Units, каждый из которых сохраняет данные изображения базового представления видео. Аналогично, вывод потока зависимого представления видео из MVC кодирующего устройства 401 составлен из блоков доступа Access Units, каждый из которых сохраняет данные изображения зависимого представления видео.

Каждый из блоков доступа Access Units, составляющих поток базового представления видео, и каждый из блоков доступа Access Units, составляющих поток зависимого представления видео, включает в себя заголовок MVC, который описывает параметр "view_type" для идентификации компонента представления, сохраняемого в нем.

Фиксированное значение, составляющее 1 или более, используется как значение параметра "view_type", описываемого в заголовке MVC зависимого представления видео. Это также относится к примерам на фиг.32 и 33.

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

Выходные данные потока базового представления видео из MVC кодирующего устройства 401 подаются к модулю 402 удаления заголовка MVC, а поток зависимого представления видео подается к мультиплексору 403.

Модуль 402 удаления заголовка MVC удаляет заголовки MVC, включенные в отдельные блоки доступа Access Units, составляющие поток базового представления видео. Модуль 402 удаления заголовка MVC выводит к мультиплексору 403 поток базового представления видео, составленный из блоков доступа Access Units, из которых были удалены заголовки MVC.

Мультиплексор 403 генерирует TS, включающий в себя поток базового представления видео, поставляемый из модуля 402 удаления заголовка MVC, и поток зависимого представления видео, поставляемый из MVC кодирующего устройства 401, и выводит их. В примере, показанном на фиг.31, TS, включающий в себя поток базового представления видео, и TS, включающий в себя поток зависимого представления видео, выводятся по отдельности, однако эти потоки могут выводиться вместе в одном TS, как описывалось выше.

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

Альтернативно, вся конфигурация, показанная на фиг.31, может быть включена в состав MVC кодирующего устройства, как показано на фиг.3. То же самое относится и к конфигурациям, показанным на фиг.32 и 33.

Фиг.32 является схемой, иллюстрирующей другой пример конфигурации генерирующего модуля TS для трехмерного видеоизображения 3D video TS, обеспеченного в записывающем устройстве.

Генерирующий модуль для трехмерного видеоизображения 3D video TS, показанный на фиг.32, включает в себя модуль 411 обработки смешивания, MVC кодирующее устройство 412, разделяющий модуль 413, модуль 414 удаления заголовка MVC и мультиплексор 415. Данные видео #1 левого L представления и данные видео #2 правого R представления вводятся в модуль 411 обработки смешивания.

Модуль 411 обработки смешивания располагает отдельные изображения левого L представления и отдельные кадры правого R представления в порядке кодирования. Отдельные кадры зависимого представления видео кодируются с обращением к соответствующим кадрами базового представления видео. Таким образом, в результате расположения в порядке кодирования, кадры левого L представления и кадры правого R представления располагаются попеременно.

Модуль 411 обработки смешивания выводит кадры левого L представления и кадры правого R представления, расположенные в порядке кодирования, к MVC кодирующему устройству 412.

MVC кодирующее устройство 412 кодирует отдельные кадры, поставляемые из модуля 411 обработки, используя Н.264 AVC/MVC, и выводит поток, полученный через кодирование, к разделяющему модулю 413. Поток базового представления видео и поток зависимого представления видео уплотняются в поток, выходящий из MVC кодирующего устройства 412.

Поток базового представления видео, включенный в состав потока, выходящего из MVC кодирующего устройства 412, составлен из блоков доступа Access Units, каждый из которых хранит данные кадра базового представления видео. Аналогично, поток зависимого представления видео, включенный в состав потока, выходящего из MVC кодирующего устройства 412, составлен из модулей доступа Access Units, каждый из которых хранит данные кадра зависимого представления видео.

Каждый из блоков доступа Access Units, составляющих поток базового представления видео, и каждый из блоков доступа Access Units, составляющих поток зависимого представления видео, включает в себя заголовок MVC, который описывает параметр "view_id" для идентификации содержащегося в нем компонента представления видео.

Разделяющий модуль 413 отделяет поток базового представления видео от потока зависимого представления видео, которые мультиплексированы в поток, поставляемый из MVC кодирующего устройства 412, и выводит их. Поток базового представления видео, который выводится из разделяющего модуля 413, поставляется в модуль 414 удаления заголовка MVC, а поток зависимого представления видео поставляется в мультиплексор 415.

Модуль 414 удаления заголовка MVC удаляет заголовки MVC, включенные в состав отдельных блоков доступа Access Units, составляющих поток базового представления видео, поставляемого из разделяющего модуля 413. Модуль 414 удаления заголовка MVC выводит в мультиплексор 415 поток базового представления видео, составленный из блоков доступа Access Units, из которых были удалены заголовки MVC.

Мультиплексор 415 генерирует TS, включающий в себя поток базового представления видео, поставляемый из модуля 414 удаления заголовка MVC, и поток зависимого представления видео, поставляемый из разделяющего модуля 413, и выводит их.

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

Генерирующий модуль для трехмерного видео 3D video TS, показанный на фиг.33, включает в себя AVC кодирующее устройство 421, MVC кодирующее устройство 422, и мультиплексор 423. Данные видео #1 левого L представления вводятся в AVC кодирующее устройство 421, а данные видео #2 правого R представления вводятся в MVC кодирующее устройство 422.

AVC кодирующее устройство 421 кодирует данные видео #1 левого L представления, используя H.264/AVC, и выводит AVC видеопоток, полученный с помощью кодирования и служащий в качестве потока базового представления видео, в MVC кодирующее устройство 422 и мультиплексор 423. Отдельные блоки доступа Access Units, составляющие поток базового представления видео, выводятся из AVC кодирующего устройства 421, при этом они не содержат заголовки MVC.

MVC кодирующее устройство 422 декодирует поток базового представления видео (AVC видеопоток), поставляемый из AVC кодирующего устройства 421, чтобы генерировать данные видео #1 левого L представления.

Кроме того, MVC кодирующее устройство 422 генерирует поток зависимого представления видео на основе данных видео #1 левого L представления, полученных через декодирование, и данных видео #2 правого R представления, вводимых в него извне, и выводит их в мультиплексор 423. Отдельные блоки доступа Access Units, составляющие поток зависимого представления видео, выводятся из MVC кодирующего устройства 422, при этом они включают в себя заголовки MVC.

Мультиплексор 423 генерирует TS, включающее в себя поток базового представления видео, поставляемый из AVC кодирующего устройства 421, и поток зависимого представления видео, поставляемый из MVC кодирующего устройства 422, и выводит их.

AVC кодирующее устройство 421, показанное на фиг.33, имеет функцию H.264/AVC кодирующего устройства 21 на фиг.3, а MVC кодирующее устройство 422 имеет функции H.264/AVC кодирующего устройства 22 и кодирующего устройства 24 зависимого представления видео, показанных на фиг.3. Аналогично, мультиплексор 423 имеет функцию мультиплексора 25, показанного на фиг.3.

Генерирующий модуль для трехмерного видео 3D video TS, имеющий такую конфигурацию, обеспечивается в записывающем устройстве, вследствие чего может быть запрещено кодирование заголовка MVC каждого блока доступа Access Unit, сохраняющего данные базового представления видео. Кроме того, заголовок MVC, в котором параметр "view_id" устанавливается на 1 или более, может быть включен в каждый блок доступа Access Unit, сохраняющий данные зависимого представления видео.

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

Фиг.34 иллюстрирует переключатель 109 и видеодекодер 110, описанные со ссылкой на фиг.22 и далее. Блок доступа Access Unit #1, включающий в себя данные базового представления видео, и блок доступа Access Unit #2, включающий в себя данные зависимого представления видео, считываются из буфера и доставляются к переключателю 109.

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

В стандарте H.264/MVC сторона декодера рассчитывает порядок декодирования отдельных блоков доступа Access Units, используя параметр "view_id", включенный в состав заголовков MVC. Кроме того, в базовом представлении видео определено, что минимальное значение постоянно устанавливается как значение "view_id" во время кодирования. Декодер начинает декодирование с блока Access Unit, включающего в себя заголовок MVC, в котором установлено минимальное значение "view_id", таким образом, существует возможность декодировать базовое представление видео и зависимое представление видео в правильном порядке.

В этой связи можно отметить, что кодирование заголовка MVC запрещается в блоке Access Unit, хранящем базовое представление видео, поставляемого к видеодекодеру 110 устройства 1 воспроизведения.

Поэтому в устройстве 1 воспроизведения определяется, что компонент представления, сохраняемый в блоке Access Unit без заголовка MVC, должен распознаваться по параметру "view_id", который в этом случае равен 0.

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

Переключатель 109 на фиг.34 сначала выводит блок доступа Access Unit #1, в котором распознано, что минимальное значение 0 установлено как "view_id", в видеодекодер 110, и вызывает выполнение декодирования.

Кроме того, после завершения декодирования блок доступа Access Unit #1 переключатель 109 выводит блок доступа Access Unit #1, в котором Y, равное фиксированному значению, большему 0, устанавливается как параметр "view_id", в видеодекодер 110, и вызывает выполнение декодирования. Кадр зависимого представления видео, сохраняемый в блоке Access Unit #2, является кадром, соответствующим изображению базового представления видео, сохраняемого в блоке доступа Access Unit #1.

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

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

Например, как показано на фиг.35, в том случае, когда заголовки MVC добавляются соответственно к базовому представлению видео и зависимому представлению видео, и когда сначала выполняется декодирование базового представления видео, базовое представление видео не может быть воспроизведено в традиционном устройстве для воспроизведения. Заголовок MVC является неопределенными данными для декодера H.264/AVC, установленного в традиционном устройстве для воспроизведения. В том случае, когда вводятся такие неопределенные данные, некоторые декодеры не могут игнорировать данные, и обработка может быть не выполнена.

Следует заметить, что на фиг.35 параметр "view_id" базового представления видео обозначается как X, a "view_id" зависимого представления видео обозначается как Y, причем Y больше, чем X.

Кроме того, даже в том случае, когда кодирование заголовков MVC запрещается, устройство 1 воспроизведения может быть запрограммировано, чтобы сначала выполнять декодирование базового представления видео, а затем выполнять декодирование соответствующего зависимого представления видео за счет создания такого определения, при котором параметр "view_id" базового представления видео рассматривается как 0. То есть декодирование может быть выполнено в правильном порядке.

Операция 2

О структуре GOP (Group Of Pictures - группа кадров)

В стандарте H.264/AVC структура GOP в стандарте для видео MPEG-2 не определена.

Поэтому в стандарте BD-ROM для обработки потока видеоданных H.264/AVC определена структура GOP потока видеоданных H.264/AVC и реализованы различные типы функций, использующих структуры GOP, такие как произвольный доступ.

В потоке базового представления видео и потоке зависимого представления видео, которые являются потоками видеоданных, полученных через кодирование с использованием H.264/MVC, определение структуры GOP не существует как в потоке видеоданных H.264/AVC.

Поток базового представления видео является потоком видеоданных H.264/AVC. Таким образом, структура GOP потока базового представления видео является такой же, как и структура GOP потока видеоданных H.264/AVC, определяемого в стандарте BD-ROM.

Структура GOP потока зависимого представления видео также определяется как структура, аналогичная структуре GOP потока базового представления видео, т.е. структура GOP потока видеоданных H.264/AVC определяется в стандарте BD-ROM.

Структура GOP потока видеоданных H.264/AVC, определяемая в стандарте BD-ROM, имеет следующие характеристики.

1. Характеристики структуры потока

(1) Открытая структура GOP/ закрытая структура GOP

Фиг.36 является схемой, иллюстрирующей структуру закрытой структуры GOP (Close GOP).

Отдельные кадры на фиг.36 являются кадрами, составляющими поток видеоданных H.264/AVC. Закрытая структура GOP включает в себя IDR (Instantaneous Decoding Refresh - мгновенное обновление декодирования) кадр.

Кадр IDR является 1-кадром, который является первым декодированным в GOP, включающим в себя IDR-кадр. Во время декодирования IDR-кадра все элементы информации о декодировании, такие как состояние буфера опорного кадра (151 DPB - Decoded Picture Buffer - буфер декодированного изображения на фиг.22), а также номера кадра и РОС (Picture Order Count - порядок счета изображения), управляемые до настоящего времени, сбрасываются.

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

Кроме того, среди кадров текущей GOP для последующих (будущих) кадров по отношению к IDR-кадру в порядке отображения запрещено обращение к кадрам предыдущей GOP за пределами IDR-кадра. В H.264/AVC разрешается, чтобы Р-кадр после 1-кадра в порядке отображения обращалось к кадру перед 1-кадром.

Фиг.37 является схемой, иллюстрирующей структуру открытой GOP (Open GOP).

Как показано на фиг.37, в текущей GOP, которая является открытой GOP, кадрам перед I-кадрам, являющимся не-IDR-кадром (I-кадр, который не является IDR-кадром) в порядке отображения среди кадров текущей GOP, разрешается обращаться к кадрам предыдущей GOP.

Кроме того, среди кадров текущей GOP кадрам после I-кадра, не являющегося IDR-кадром, в порядке отображения запрещается обращаться к кадрам предыдущей GOP по ту сторону I-кадра, не являющегося IDR-кадром.

(2) SPS и PPS надежно кодируются в первом блоке доступа Access Unit группы кадров GOP.

SPS (Sequence Parameter Set - набор параметров последовательности) является информацией заголовка последовательности, которая включает в себя информацию о кодировании всей последовательности. В начале декодирования определенной последовательности необходим SPS, включающий в себя информацию по идентификации последовательности. PPS (Picture Parameter Set - набор параметров кадра) является информацией заголовка кадра, включающей в себя информацию о кодировании всего кадра.

(3) Максимум 30 наборов PPS могут быть закодированы в первом блоке доступа Access Unit группы кадров GOP. В том случае, когда множество PPS кодируются в первом блоке доступа, идентификатор (pic_parameter_set_id) каждого PPS не должен быть одинаковым.

(4) Максимум 1 PPS может быть закодирован в блоке доступа, отличном от первого блока доступа Access Unit группы кадров GOP.

2. Характеристики структуры опорных кадров

(1) Требуется, чтобы кадры I, P и В были кадрами, составленными, соответственно, только сегментами I, P и В.

(2) Требуется, чтобы кадр В непосредственно перед опорным кадром (I или Р кадр) в порядке отображения был надежно закодирован непосредственно после опорного кадра в порядке кодирования.

(3) Требуется, чтобы поддерживался (был одинаковым) порядок кодирования и порядок отображения опорного кадра (I или Р кадру).

(4) Обращение к кадру В из кадра Р запрещается.

(5) В том случае, когда неопорный В кадр (В1) находится перед неопорным кадром (В2) в порядке кодирования, требуется чтобы В1 также находился перед В2 в порядке отображения.

Неопорный В кадр является кадром В, к которому не обращаются другие последующие кадры в порядке кодирования.

(6) Опорный В кадр может обращаться к предыдущему или последующему опорному кадру (I или Р кадру) в порядке отображения.

(7) Неопорный В кадр может обращаться к предыдущему или последующему опорному кадру (I или Р кадру) в порядке отображения или к опорному В кадру.

(8) Требуется, чтобы максимальное количество последовательных В кадров составляло 3.

3. Характеристики, относящиеся к максимальному количеству кадров и полукадров в структуре GOP.

Максимальное количество кадров и полукадров в структуре GOP определяется в соответствии с частотой кадров видеоизображения, как показано на фиг.38.

Как показано на фиг.38, в том случае, когда чересстрочная развертка выполняется, например, с частотой кадров 29,97 кадров в секунду, максимальное количество полукадров, которые могут быть отображены кадрами одной GOP, составляет 60. Аналогично, в том случае, когда выполняется прогрессивная построчная развертка с частотой кадров 59,94 кадров в секунду, максимальное количество кадров, которые могут быть отображены кадрами одной GOP, составляет 60.

Структура GOP, имеющая вышеуказанные характеристики, также определяется как структура GOP потока зависимого представления видео.

Кроме того, соответствие между структурой некоторого GOP потока базового представления видео и структурой соответствующего GOP потока зависимого представления видео определяется как ограничивающее условие.

Фиг.39 является схемой, иллюстрирующей структуру закрытой GOP (Close GOP) потока базового представления видео или потока зависимого представления видео, определяемого описанным выше способом.

Как показано на фиг.39, в текущей GOP, который является закрытым, для предыдущих (прошедших) кадров по отношению к IDR-кадру или опорному кадру среди кадров текущей GOP, запрещаются обращения к кадрам предыдущей GOP. Опорный кадр будет описано ниже.

Кроме того, из кадров текущей GOP для последующих (будущих) кадров по отношению к IDR-кадру или опорному кадру в порядке отображения запрещаются обращения к кадрам предыдущей GOP по ту сторону IDR-кадра или опорного кадра.

Фиг.40 является схемой, иллюстрирующей структуру открытой GOP (Open GOP) потока базового представления видео или потока зависимого представления видео.

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

Кроме того, среди кадров текущей GOP кадрам после опорного кадра, не являющегося IDR-кадром, в порядке отображения запрещается обращаться к кадрам предыдущей GOP за пределами опорного кадра, не являющегося IDR-кадром.

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

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

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

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

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

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

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

Параметр "ЕР_map"

С использованием структур GOP потока базового представления видео и потока зависимого представления видео начальное положение декодирования во время произвольного доступа или быстрого воспроизведения видео может быть установлено в параметре "ЕР_map". "ЕР_map" содержится в файле информации клипа Clip Information.

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

1. Положение опорного кадра, расположенного после SubsetSPS, или положение IDR-кадра, расположенного после SubsetSPS, рассматривается как положение, которое может быть установлено для потока зависимого представления видео.

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

2. В том случае, когда некоторый кадр потока зависимого представления видео устанавливается в параметре "ЕР_map" как начальное положение декодирования, соответствующий кадр потока базового представления видео также устанавливается в параметре "ЕР_map" как начальное положение декодирования.

Фиг.41 является схемой, иллюстрирующей пример начального положения декодирования, установленного в параметре "ЕР_map" и удовлетворяющего вышеописанным двум ограничивающим условиям.

На фиг.41 кадры, составляющие поток базового представления видео, и кадры, составляющие поток зависимого представления видео, проиллюстрированы в порядке декодирования.

Среди кадров потока зависимого представления видео, кадр P₁, показанный с помощью цвета, является опорным кадром, или IDR-кадром. SubsetSPS включается в состав блока доступа Access Unit непосредственно перед блоком доступа, включающим в себя данные кадра P₁.

В показанном на фиг.41 примере, как обозначено белой стрелкой #11, кадр P₁ устанавливается как начальное положение декодирования в параметре "ЕР_map" потока зависимого представления видео.

Кадр Р₁₁, который является кадром потока базового представления видео, соответствующего кадру P₁, является IDR-кадром. Как обозначено белой стрелкой #12, кадр Р₁₁, используемый как IDR-кадр, также устанавливается как начальное положение декодирования в параметре "ЕР_map" потока базового представления видео.

В случае начала декодирования от кадра P₁ и кадра Р₁₁, в ответ на инструкцию произвольного доступа или быстрого воспроизведения видео, сначала выполняется декодирование кадра Р₁₁. Кадр Р₁₁, который является IDR-кадром, может быть декодирован без обращения к другому кадру.

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

После этого декодирование выполняется по порядку, т.е. следующий кадр за кадром P₁ базового представления видео, следующий кадр за кадром Р₁₁ зависимого представления видео, …, и т.д.

Поскольку структуры соответствующих GOP являются одинаковыми, и декодирование начинается с соответствующих положений, то кадры, устанавливаемые в параметре "ЕР_map", и последующие кадры могут быть декодированы без проблем как для базового представления видео, так и для зависимого представления видео. Соответственно, может быть реализован произвольный доступ.

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

Фиг.42 является схемой, иллюстрирующей проблему, которая возникает в том случае, когда структура GOP зависимого представления видео не определяется.

В примере, показанном на фиг.42, кадр P₂₁, выделенный цветом, является TDR-кадром базового представления видео и устанавливается в параметре "ЕР_map" как начальное положение для декодирования.

Предположим случай, когда кадр Р₃₁, который является кадром зависимого представления видео, соответствующего кадру Р₂₁, не является опорным кадром в случае начала декодирования с кадра P₂₁ базового представления видео. В том случае, когда структура GOP не определяется, нет гарантии того, что кадр зависимого представления видео, соответствующего IDR-изображению базового представления видео, является IDR-кадром или опорным кадром.

В этом случае, даже после того, как декодирование кадра P₂₁ базового представления видео закончилось, кадр P₃₁ не может быть декодирован. Связь в направлении оси времени также необходима для декодирования кадра Р₃₁, но кадры, расположенные слева от пунктирной линии, проходящей в вертикальном направлении (предыдущие изображения в порядке декодирования), не декодируются.

Кадр Р₃₁ не может быть декодирован, и соответственно, другие кадры зависимого представления видео, которые обращаются к кадру Р₃₁, не могут быть декодированы.

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

Начальное положение для декодирования устанавливается с помощью параметра "ЕР_map" не только для базового представления видео, но также и зависимого представления видео, вследствие чего устройство 1 воспроизведения может легко определить начальное положение для декодирования.

В том случае, когда только определенный кадр базового представления видео устанавливается в параметре "ЕР_map" как начальное положение для декодирования, для устройства 1 воспроизведения нужно определить кадр зависимого представления видео, соответствующий кадру начального положения для декодирования, используя вычисление, которое усложняет процесс.

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

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

Как показано на фиг.43, когда выполняются произвольный доступ или сложное воспроизведение видео, осуществляется поиск опорного кадра, не являющегося IDR, или IDR-кадра, и определяется начальное положение для декодирования.

Сейчас будет описан параметр "ЕР_map". Будет дано описание случая, когда начальное положение для декодирования базового представления видео устанавливается в параметре "ЕР_map". Аналогично, начальное положение для декодирования зависимого представления видео устанавливается в параметре "ЕР_map" зависимого представления видео.

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

TS, включающий в себя поток базового представления видео, составлен из целого числа выровненных блоков (Aligned Units), имеющих размер 6144 байт.

Каждый из выровненных блоков составлен из 32 исходных пакетов (Source Packets). Каждый исходный пакет имеет размер 192 байта. Один исходный пакет составлен из 4-байтного дополнительного заголовка транспортного пакета (TP_extra header) и 188-байтного транспортного пакета (Transport Packet).

Данные базового представления видео являются пакетизированными по стандарту MPEG2 пакетами PES. Пакет PES формируется за счет добавления заголовка пакета PES к участку данных пакета PES. Заголовок пакета PES включает в себя идентификатор ID потока, который определяет тип первичного потока, передаваемого с помощью пакета PES.

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

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

Параметр "ЕР_map" используется для поиска адреса данных, с которого должно быть запущено считывание данных в файле Clip AV stream, когда дается метка времени точки доступа клипа. Параметр "ЕР_map" является списком точек входа, выделенных из элементарного потока и транспортного потока.

Параметр "ЕР_map" имеет информацию адреса для поиска точки входа, в которой должно начаться декодирование в потоке AV. Один фрагмент данных ЕР в параметре "ЕР_map" составлен из пары PTS и адреса в потоке AV блока доступа Access Unit, соответствующего этому PTS. В AVC/I-I.264 данные одного изображения сохраняются в одном блоке доступа Access Unit.

Фиг.45 является схемой, иллюстрирующей пример потока Clip AV.

Поток Clip AV, показанный на фиг.45, является видеопотоком (потоком базового представления видео), составленным из исходных пакетов, идентифицированных с помощью PID=х. В этом видеопотоке каждый исходный пакет распознается с помощью PID, включенного в заголовок транспортного пакета в исходном пакете.

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

Например, исходный пакет, который имеет номер XI исходного пакета, и который включает в себя первый байт произвольно доступного IDR-кадра потока видеоданных, распознаваемых с помощью PID=х, расположен в положении PTS=pts(xl) на оси времени потока Clip AV stream.

Аналогично, исходный пакет, включающий в себя первый байт следующего произвольно доступного IDR-кадра, рассматривается как исходный пакет, имеющий номер Х2 исходного пакета и расположенный в положении PTS=pts(x2).

Фиг.46 является схемой, концептуально иллюстрирующей пример параметра "ЕР_map", соответствующего потоку Clip AV, показанному на фиг.45.

Как показано на фиг.46, параметр "ЕР_map" составлен из компонентов: stream_PID, PTS_EP_start, и SPN_EP_start.

stream_PID представляет PID транспортного пакета для передачи потока видеоданных.

PTS_EP_start представляет PTS блока доступа Access Unit, запускаемого из произвольно доступного IDR-кадра.

SPN_EP_start представляет адрес исходного пакета, включающего в себя первый байт блока доступа Access Unit, который соотносится со значением PTS_EP_start.

PID потока видеоданных сохраняется в stream_PID, при этом генерируется EP_map_for_one_stream_PID(), который является таблицей с информацией, показывающей соответствие между PTS_EP_start и SPN_EP_start.

Например, в EP_map_for_one_stream_PID[0] потока видеоданных с PID=х, PTS=pts(x1) и исходный пакет номер XI, PTS=pts(x2) и исходный пакет номер Х2, …, и PTS=pts(xk) и исходный пакет номер Xk описываются соответствующим способом.

Такая таблица также генерируется для отдельных потоков видеоданных, мультиплексированных в один и тот же поток Clip AV. Параметр "ЕР_map", включающий в себя сгенерированные таблицы, сохраняется в файле информации клипа, соответствующем потоку Clip AV.

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

Как описано выше, исходный пакет образован в таком виде, когда 4-байтный заголовок добавлен к 188-байтному транспортному пакету. Участок транспортного пакета составлен из участка заголовка (ТР header) и участка полезной информации. SPN_EP_start представляет номер исходного пакета, включающего в себя первый байт блока доступа Access Unit, который запускается с IDR-кадра.

В AVC/H.264 блок доступа Access Unit, т.е. кадр, запускается с разграничителя AU (Access Unit Delimiter). Разграничитель AU следует за SPS и PPS. После этого хранится участок заголовка или весь участок данных секции IDR-кадра.

Значение параметра "payload_unit_start_indicator" в заголовке ТР транспортного пакета, составляющее 1, означает, что новый пакет PES запускается из payload - полезной информации этого транспортного пакета. Блок доступа Access Unit запускается из этого исходного пакета.

Такой параметр "ЕР_map" подготавливается для каждого потока базового представления видео и потока зависимого представления видео.

Операция 3

РОС (Picture Order Count - порядок подсчета кадров) устанавливается для отдельных кадров, образующих поток базового представления видео и поток зависимого представления видео во время кодирования. РОС является значением, представляющим порядок отображения кадров.

В AVC/H.264 РОС определяется следующим образом: «Переменная, имеющая значение, которое является неубывающим при увеличивающемся положении кадра в порядке вывода по отношению к предыдущему IDR-кадру в порядке декодирования, или по отношению к предыдущему кадру, содержащему операцию управления памятью, которая помечает все эталонные кадры как «неиспользуемые в качестве опорных».

Во время кодирования РОС, установленный для кадра потока базового представления видео и РОС, установленный для кадра потока зависимого представления видео, управляются унифицированным способом.

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

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

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

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

Например, устройство 1 воспроизведения способно обрабатывать кадр, в котором установлен РОС=1, среди кадров потока базового представления видео, и кадр, в котором установлен РОС=1, среди кадров потока зависимого представления видео, как кадры, соответствующие друг другу.

Кроме того, Picture Timing SEI (Supplemental Enhancement Information - дополнительная информация для коррекции изображения) устанавливается для отдельных кадров, образующих поток базового представления видео и поток зависимого представления видео. SEI является дополнительной информацией, включающей в себя вспомогательную информацию о декодировании, которая определяется с помощью H.264/AVC.

Picture Timing SEI, который является одним из параметров SEI, включает в себя информацию времени, такую как время считывания из СРВ (Coded Picture Buffer - буфер кодированных кадров) во время кодирования, и время считывания из DPB (DPB - буфер 151 декодированного кадра на фиг.22) во время кодирования. Кроме того, Picture Timing SEI включает в себя информацию о времени отображения и информацию о структуре кадров.

Во время кодирования параметр Picture Timing SEI, установленный для кадров потока базового представления видео, и Picture Timing SEI, установленный для кадров потока зависимого представления видео, управляются унифицированным способом.

Например, в том случае, когда Т1 устанавливается как время считывания из СРВ для первого кадра в порядке кодирования потока базового представления видео, Т1 также устанавливается как время считывания из СРВ для первого кадра в порядке кодирования потока зависимого представления видео.

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

Соответственно, устройство 1 воспроизведения способно обрабатывать компоненты представления, в которых одинаковые параметры Picture Timing SEI устанавливается как компоненты представления, соответствующие друг другу в порядке декодирования.

РОС и Picture Timing SEI включаются в первичный поток базового представления видео и зависимого представления видео и к ним обращается видеодекодер 110 в устройстве 1 воспроизведения.

Видеодекодер 110 способен идентифицировать компоненты представления, соответствующие друг другу, на основе информации, включенной в первичный поток. Кроме того, видеодекодер 110 способен осуществлять процесс декодирования в правильном порядке декодирования на основе параметра Picture Timing SEI, а также в правильном порядке отображения на основе РОС.

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

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

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

ЦП (центральный процессор) 501, ПЗУ (постоянное запоминающее устройство) 502, ОЗУ (оперативное запоминающее устройство) 503 соединяются между собой через шину 504.

Интерфейс 505 ввода/вывода дополнительно присоединяется к шине 504. Модуль 506 ввода, включающий в себя клавиатуру, мышь и т.д., и модуль 507 вывода, включающий в себя дисплей, громкоговоритель и т.д., присоединяются к интерфейсу 505 для ввода/вывода. Кроме того, запоминающее устройство 508, включающее в себя жесткий диск, энергонезависимую память и т.д., модуль 509 связи, включающий в себя интерфейс компьютерной сети, или подобное устройство, и накопитель 510, который приводит в движение сменный носитель 511, присоединяются к шине 504.

В компьютере, имеющем вышеописанную конфигурацию, центральный процессор 501 загружает программу, хранящуюся в запоминающем устройстве 508 в ОЗУ 503 через интерфейс 505 ввода/вывода и шину 504, выполняет ее, в результате чего, например, осуществляются вышеописанные последовательности процессов.

Программа, выполняемая ЦП 501, обеспечивается, например, с помощью записи на сменный носитель 511, или через проводную или беспроводную среду передачи, такую как локальная сеть, Интернет или цифровое ТВ-вещание, и устанавливается в запоминающее устройство 508.

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

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

Список ссылочных позиций.

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

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

3 - устройство отображения,

11 - декодер MVC,

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

22 - декодирующее устройство H.264/AVC,

23 - вычислительный модуль для расчета глубины (Depth),

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

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

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

52 - дисковод,

53 - память,

54 - локальное запоминающее устройство,

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

56 - декодирующий модуль,

57 - устройство ввода операций.

Изобретение относится к записывающему устройству, хранящему поток базового изображения и поток расширенного изображения, полученные с помощью кодирования видеоданных множества точек наблюдения. Технический результат заключается в том, что данные на носителе с использованием заявленного кодирования записи могут быть воспроизведены в устройстве, являющемся несовместимым с воспроизведением видеоданных множества точек наблюдения. В блоке доступа Access Unit, содержащем базовое представление видео, кодирование заголовка MVC запрещается. Для компонента представления, содержащегося в модуле доступа Access Unit без заголовка MVC, определение выполняется таким образом, что его параметр "view_id" распознается как 0. Настоящее изобретение может быть применимо к устройству для воспроизведения, совместимому со стандартом BD-ROM. 5 н. и 2 з.п. ф-лы, 48 ил.

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

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

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

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

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

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

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