НОСИТЕЛЬ ЗАПИСИ, УСТРОЙСТВО ЗАПИСИ, СПОСОБ ЗАПИСИ И УСТРОЙСТВО ВОСПРОИЗВЕДЕНИЯ

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

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

Предшествующий уровень техники

В последние годы были установлены стандарты DVD следующего поколения, например, стандарт диска Blu-ray и стандарт HD DVD (DVD высокой плотности), знакомя пользователей с оптическими дисками высокого разрешения и звуком высокого качества. На этих оптических дисках записываются многочисленные аудиопотоки (например, 32 аудиопотока) с целью поддержки любого сочетания формата кодирования, количества каналов и атрибута языка.

В данном случае, форматы кодирования включают в себя такие, как Dolby AC3, Dolby digital Plus, MLP, DTS, DTS-HD и Linear PCM, и каналы включают в себя такие, как монофонический, стереофонический и многоканальный.

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

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

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

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

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

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

Если нет аудиопотока, который удовлетворяет всем этим условиям, выбирается аудиопоток, который удовлетворяет условиям А и В.

Если нет аудиопотока, который удовлетворяет обоим условиям А и В, выбирается аудиопоток, который удовлетворяет условиям А и С.

Если нет аудиопотока, который удовлетворяет обоим условиям А и С, выбирается аудиопоток, который удовлетворяет условию А.

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

Патентная литература 1: международная публикация WO2004-114658.

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

В последние годы для различных назначений были разработаны новые форматы кодирования аудиопотоков (новый аудиокодек, ниже упоминаемый как «NAC»). Задачей NAC является обеспечение кодирования со сжатием, которое достигает более высокого качества звука, и начинает применяться NAC, такой как кодек с более высоким коэффициентом сжатия или кодек с новой функцией.

При таких обстоятельствах существует потребность введения NAC в стандарты DVD следующего поколения, такие как стандарт Blu-ray Disc и стандарт HD DVD, чтобы повысить привлекательность DVD следующего поколения.

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

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

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

Краткое изложение существа изобретения

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

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

Эффект, достигаемый изобретением

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

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

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

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

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

фиг.1 изображает внутреннюю структуру BD-ROM;

фиг.2 схематически изображает структуру файла, к которому присоединяется расширение «m2ts»;

фиг.3 изображает элементарные потоки, которые мультиплексируются в AVClip;

фиг.4 изображает структуру данных информации PlayList;

фиг.5 изображает внутреннюю структуру ES_table;

фиг.6А изображает stream_entry для главного аудиопотока;

фиг.6B изображает stream_attributes, соответствующие главному аудиопотоку;

фиг.7 изображает примерную структуру ES_table, которая включает в себя stream_entry-stream_attributes аудиопотока, кодированного с использованием NAC;

фиг.8 изображает внутреннюю структуру информации управления AVClip;

фиг.9 изображает внутреннюю структуру устройства 1000 проигрывания;

фиг.10 изображает функции контроллера 100;

фиг.11А изображает назначение битов в PSR1;

фиг.11В изображает назначение битов в PSR15;

фиг.11С изображает назначение битов в PSR31;

фиг.12 представляет собой блок-схему последовательности операций, изображающую обработку выбора PlayList, в случае, если команды навигации, хранимые в файле программы BD, включают в себя команду навигации, которая проигрывает PlayList, version_number которого равен 2,3 или выше;

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

фиг.14А изображает переход состояния набора значений в PSR1;

фиг.14В представляет собой блок-схему последовательности операций «процедуры, когда меняется условие проигрывания»;

фиг.15 представляет собой блок-схему последовательности операций, изображающую подробную процедуру установки PSR1 (этап S305);

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

фиг.17 изображает пример экрана меню;

фиг.18А изображает возможность проигрывателя, установку языка и возможность окружающего звука устройства проигрывания;

фиг.18В изображает записанное содержимое ES_table;

фиг.18С изображает stream_entry-stream_attributes шести аудиопотоков;

фиг.19 изображает структуры данных BD-ROM 1а и HDD 1b;

фиг.20 изображает элементарные потоки, которые мультиплексируются в AVClip во втором варианте осуществления;

фиг.21 изображает внутреннюю структуру ES_table во втором варианте осуществления;

фиг.22А изображает внутреннюю структуру Comb_info_Secondary_audio_Primary_audio;

фиг.22В изображает пример Comb_info_Secondary_audio_Primary_audio;

фиг.23 изображает внутреннюю структуру устройства 3000 записи;

фиг.24 изображает синтаксис stream_attributes();

фиг.25 изображает синтаксис stream_code_inf();

фиг.26 представляет собой пример таблицы, указывающей соответствие между кодированными методом Хаффмана значениями (H) и значениями полей;

фиг.27 изображает процедуру декодирования; и

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

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

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

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

1. Внутренняя структура BD-ROM

Фиг.1 изображает внутреннюю структуру BD-ROM. На четвертой строке фиг.1 показан BD-ROM. Третья строка изображает дорожки на BD-ROM. Фиг.1 изображает дорожки в состоянии, когда они располагаются горизонтально, хотя в действительности они формируются спирально в очередности от внутренней окружности к внешней окружности. Дорожки включают в себя вводную зону, зону тома и выводную зону. Зона тома на фиг.1 имеет модель уровней, которая включает в себя физический уровень, уровень файловой системы и уровень приложений. Первая строка на фиг.1 изображает формат уровня приложений BD-ROM, представленный структурой каталогов. Как показано на фиг.1, BD-ROM включает в себя каталог BDMV под корневым каталогом. Каталог BDMV включает в себя индексный файл (index.bdmv) и файл объекта-фильма (Movie Object.bdmv), каталог PLAYLIST, каталог CLIPINFO, каталог STREAM, каталог BDBJ и каталог BDJA.

1.1. Индексный файл (index.bdmv)

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

1.2. Каталог STREAM

Каталог STREAM включает в себя файлы, к которым присоединено расширение «m2ts». Фиг.2 схематически изображает структуру файла, к которому присоединено расширение «m2ts». Файл, к которому присоединено расширение «m2ts», хранит AVClip. AVClip представляет собой цифровой поток в формате транспортного потока MPEG2.

Как показано на фиг.2, оцифрованное видео и аудио (1-я строка сверху) преобразуются в элементарный поток, состоящий из пакетов PES (2-я строка сверху), и дополнительно преобразуются в TS-пакеты (3-я строка сверху). Аналогично, поток графики (PG) представления для субтитров или т.п. и поток интерактивной графики (IG) для интерактивных целей (1-я строка снизу, 2-я строка снизу) преобразуется соответственно в TS-пакеты (3-я строка). Цифровой поток генерируется мультиплексированием этих TS-пакетов.

В данном случае, как показано на фиг.1, каталог STREAM хранит файл (00001.m2ts (с NAC)) и файл (00002.m2ts (без NAC)). Отличие между этими двумя файлами заключается в том, включен ли или нет аудиопоток, кодированный с использованием нового формата аудиокодирования (новый аудиокодек: ниже упоминаемый как «NAC») (например, DRA) в цифровой поток. Более конкретно, все аудиопотоки, включенные в файл (00002.m2ts (без NAC)), были кодированы в существующем формате кодирования, таком как Dolby AC-3, Dolby Digital Plus, MLP, DTS, DTS-HD или линейный PCM (ниже упоминаемые как «обычно кодированные потоки»). С другой стороны, файл (00001.m2ts (с NAC)) включает в себя в дополнение к аудиопотокам, кодированным в таком существующем формате кодирования, аудиопоток, кодированный в NAC (ниже упоминаемый как «NAC-поток»).

Теперь, как показано на фиг.2, PG-поток представляет собой поток графики, составляющей субтитр. Существует множество PG-потоков, которые согласуются соответственно с множеством языков (например, английский, японский и французский). Каждый PG-поток состоит из функциональных сегментов, таких как: PCS (сегмент управления представлением); PDS (сегмент определения палитры); WDS (сегмент определения окна); ODS (сегмент определения объекта) и END (окончание сегмента установок отображения). ODS (сегмент определения объекта) представляет собой функциональный сегмент, который определяет графический объект в виде субтитра. WDS представляет собой функциональный сегмент, который определяет область рисования графического объекта на экране. PDS (сегмент определения палитры) представляет собой функциональный сегмент, который определяет цвет при рисовании графического объекта. PCS (сегмент управления представлением) представляет собой функциональный сегмент, который определяет управление страницами при отображении субтитра. Такое управление страницами включает в себя вставку/вырезку, введение/выведение изображения, изменение цвета, прокручивание и появление/исчезновение. С управлением страницами посредством PCS можно достигать эффекта отображения, например, выведение текущего субтитра, во время отображения следующего субтитра.

IG-поток представляет собой поток графики для достижения интерактивного управления. Интерактивное управление, определяемое IG-потоком, представляет собой интерактивное управление, которое совместимо с интерактивным управлением на устройстве проигрывания DVD. IG-поток состоит из функциональных сегментов, таких как: ICS (сегмент интерактивного составления); PDS (сегмент определения палитры); ODS (сегмент определения объекта) и END (окончание сегмента установок отображения). ODS (сегмент определения объекта) представляет собой функциональный сегмент, который определяет графический объект. Кнопка на интерактивном экране рисуется множеством таких графических объектов. PDS (сегмент определения палитры) представляет собой функциональный сегмент, который определяет цвет при рисовании графического объекта. ICS (сегмент интерактивного составления) представляет собой функциональный сегмент, который достигает изменения состояния, при котором состояние кнопки изменяется в соответствии с операцией пользователя. ICS включает в себя команду кнопки, которая исполняется тогда, когда операция подтверждения выполняется на кнопке.

AVClip состоит из одной или более «STC_Sequences». «STC_Sequence» представляет собой раздел, который не включает в себя неоднородность системной временной шкалы часов системного времени (STC), которые представляют собой стандартное время системы для AV-потока. Неоднородность временной шкалы системы STC представляет собой точку, в которой является включенным discontinuity_indicator PCR-пакета, который переносит PCR (отсчет программного времени), на который ссылается декодер, для получения STC.

Далее, фиг.3 изображает элементарные потоки, которые мультиплексируются в AVClip.

Как показано на фиг.3, в AVClip мультиплексируются: видеопоток с высоким качеством изображения, имеющий PID 0x1011; главные аудиопотоки, имеющие PID 0x1100-0x111F; PG-потоки, имеющие PID 0x1200-121F; и IG-потоки, имеющие PID 0x1400-0x141F. Пакетам, составляющим элементарные потоки, назначаются соответствующие PID, и они демультиплексируются на основе PID.

1.3. Каталог PLAYLIST

1.3.1. Структура данных файлов, к которым присоединяется расширение «mpls»

Каталог PLAYLIST хранит файлы PlayList, к которым присоединяется расширение «mpls». Каждый файл PlayList, к которому присоединяется расширение «mpls», хранит информацию PlayList (PL). Информация PlayList представляет собой информацию, определяющую логический путь проигрывания AVClip.

В данном случае, как показано на фиг.1, каталог PLAYLIST хранит файл «00001.mpls (с NAC)» и файл «00002.mpls (без NAC)». Информация PlayList, хранимая в файле «00001.mpls (с NAC)», соответствует AVClip, хранимому в файле (00001.m2ts (с NAC)), и включает в себя информацию о NAC-потоках. С другой стороны, файл (00002.mpls (без NAC)) соответствует AVClip, хранимому в файле (00002.m2ts (без NAC)), и не включает в себя информацию о NAC-потоках.

Фиг.4 изображает структуру данных информации PlayList. Как показано на фигуре, информация PlayList включает в себя: Version_number, который определяет версию информации PlayList, информацию MainPath (MainPath()), которая определяет MainPath; и информацию PlayListMark (PlayListMark()), которая определяет главу.

Version_number устанавливается на разные числа в зависимости от того, поддерживает ли информация PlayList NAC, т.е., включает ли в себя информация PlayList информацию о NAC-потоках или нет. Version_number, хранимый в файле (00001.mpls), т.е. Version_number информации PlayList, поддерживающей NAC, устанавливается, например, на «2.3». С другой стороны, Version_number, хранимый в файле (00002.mpls), т.е. Version_number информации PlayList, не поддерживающей NAC, устанавливается, например, на «1.0» или «2.0».

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

Как указано передней линией mp1, MainPath состоит из множества порций информации PlayItem: информация #1 PlayItem … информация #m PlayItem. Информация PlayItem определяет один логический раздел проигрывания, который составляет MainPath.

Передняя линия hs1 на чертеже указывает крупный план структуры информации PlayItem. Как указано передней линией hs1, информация PlayItem состоит из: «Clip_Information_file_name», которая указывает имя файла информации раздела проигрывания AVClip, к которой принадлежат точка IN и точка OUT раздела проигрывания; «Clip_codec_identifier», которая указывает способ кодирования AVClip; «is_multi_angle», которая указывает, является ли PlayItem многоракурсным или нет; «connection_condition», которая указывает, соединять ли плавно или нет текущий PlayItem и предыдущий PlayItem; «ref_to_STC_id[0]», которая однозначно указывает STC_Sequence, предназначенную для PlayItem; «In_time», которая представляет собой временную информацию, указывающую начальную точку раздела проигрывания; «Out_time», которая представляет собой временную информацию, указывающую конечную точку раздела проигрывания; «UO_mask_table», которая указывает, какая операция пользователя должна маскироваться PlayItem; «PlayItem_random_access_flag», которая указывает, разрешить или нет случайный доступ к средней точке в PlayItem; «Still_mode», которая указывает, продолжать или нет неподвижное отображение последнего изображения после того, как закончится проигрывание PlayItem; и «ES_table». Из них временная информация «In_time», указывающая начальную точку раздела проигрывания, и временная информация «Out_time», указывающая конечную точку раздела проигрывания, составляют путь проигрывания. Информация пути представления состоит из «In_time» и «Out_time».

1.3.1.1. Структура данных «ES_table»

Ниже описываются подробности «ES_table».

ES_table представляет собой таблицу, которая указывает проигрываемые (воспроизводимые) потоки из множества элементарных потоков, мультиплексируемых в AVClip, задаваемые Clip_Information_file_name в информации PlayItem. Более конкретно, «ES_table» состоит из ассоциирования stream_attributes с stream_entries, соответствующих проигрываемым элементарным потокам из множества элементарных потоков, мультиплексируемых в MainClips.

Фиг.5 изображает внутреннюю структуру ES_table. Скобки «{» указывают для каждого типа потоков (например, видеопотоков, главные аудиопотоков, PG-потоков и IG-потоков) пары stream_entry и stream_attributes, соответствующие проигрываемым потокам. Идентификатор (id) присоединяется к каждому потоку для идентификации потока в числе одного типа потоков. ES_table, показанная на фиг.5, включает в себя пару stream_entry и stream_attributes (stream_entry-stream_attributes) для видеопотока, и множество пар stream_entry и stream_attributes (stream_entry-stream_attributes) для главных аудиопотоков, PG-потоков и IG-потоков, соответственно.

Также, ES_table включает в себя: number_of_video_stream_entries, которое указывает число проигрываемых видеопотоков; number_of_audio_stream_entries, которое указывает число проигрываемых главных аудиопотоков; number_of_PG_stream_entries, которое указывает число проигрываемых PG-потоков; и number_of_IG_stream_entries, которое указывает число проигрываемых IG-потоков.

Ниже описываются подробности stream_entry-stream_attributes. Фиг.6А изображает stream_entry для главного аудиопотока. Как показано на фигуре, stream_entry для главного аудиопотока включает в себя «ref_to_Stream_PID_of_Main_Clip», которая указывает PID, используемый для демультиплексирования главного аудиопотока.

Фиг.6В изображает stream_attributes, соответствующие главному аудиопотоку. Stream_attributes главного аудиопотока включает в себя: «coding_type», который указывает формат кодирования аудиопотока; «presentation_type», который указывает структуру канала соответствующего аудиопотока; «sampling_frequency», который указывает частоту дискретизации соответствующего аудиопотока; и «audio_language_code», который указывает атрибут языка аудиопотока.

1.3.1.1.1. ES_table файла (00001.mpls)

Ниже описывается ES_table файла (00001.mpls). В случае, если ES_table включает в себя stream_entry-stream_attributes потока NAC, важно, как определяется очередность stream_entry-stream_attributes проигрываемых аудиопотоков.

В определенной очередности в ES_table stream_entry-stream_attributes аудиопотока, который был кодирован, с использованием существующего формата кодирования (AC3, DTS, LPCM или т.п.), с одного и того же аудиоисточника, так как источник NAC-потока должен быть непосредственно перед stream_entry-stream_attributes NAC-потока. Например, в случае, если NAC-поток представляет собой аудио для голоса за кадром на японском языке для главного видео, предпочтительно, чтобы аудиоисточником аудиопотока непосредственно перед NAC также было аудио для голоса за кадром на японском языке для главного видео.

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

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

Фиг.7 изображает примерную структуру ES_table, которая включает в себя stream_entry-stream_attributes NAC-потока. Как показано на фиг.7, первый stream_attributes (id=1) главного аудиопотока описывает AC3 как coding_type, многоканальный - как presentation_type, и японский - как audio_language_code. stream_attributes (id=2) описывает NAC как coding_type, многоканальный - как presentation_type, и японский - как audio_language_code. Также, предполагается в данном случае, что аудиопоток (id=1) и аудиопоток (id=2) были кодированы с одного и того же аудиоконтента.

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

1.4. Каталог CLIPINFO

Каталог CLIPINFO включает в себя файл, к которому присоединяется расширение «clip». Каждый файл информации о клипе, к которому присоединяется расширение «clip», хранит информацию управления AVClip.

В данном случае, как показано на фиг.1, каталог CLIPINFO включает в себя файл (00001.clip (с NAC)) и файл (00002.clip (без NAC)). Информация управления, хранимая в файле (00001.clip (с NAC)), соответствует AVClip, хранимому в файле (00001.m2ts (с NAC)) и включает в себя информацию о NAC-потоке. С другой стороны, информация управления, хранимая в файле (00002.clip (без NAC)), соответствует AVClip, хранимому в файле (00002.m2ts (без NAC)), и не включает в себя информацию о NAC-потоке.

Фиг.8 изображает внутреннюю структуру информации управления AVClip. По существу, информация управления AVClip соответствует AVClip на однозначной основе и включает в себя: «ClipInfo()», которая хранит информацию о AVClip; «Sequence Info()», которая хранит информацию о ATC-последовательности и STC-последовательности; «Program Info()», которая хранит информацию о последовательности программ; и «Characteristic Point Info(CPI())».

Program Info включает в себя: number_of_es, указывающую число элементарных потоков, включенных в AVClip; stream_pid, каждая из которых указывает PID каждого элементарного потока; и stream_code_info(), указывающую информацию об атрибутах в соответствии с типом элементарного потока.

Так как AVClip, хранимый в файле (00001.m2ts), включает в себя аудиопоток, кодированный в NAC, stream_code_info() информации управления, хранимой в файле (00001.clip (с NAC)), описывает информацию об атрибутах аудиопотока, который поддерживает NAC.

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

Вышеописанная информация PlayList и информация Clip классифицируются как «статический сценарий». Это потому, что информация Clip и информация PlayList определяют PlayList, который представляет собой статический блок проигрывания. Это завершает описание статического сценария.

Ниже описывается «динамический сценарий». Динамический сценарий представляет собой данные сценария, которые динамически определяют управление проигрыванием AVClip. В данном случае «динамически» указывает то, что содержимое управления проигрыванием изменяется вследствие изменения состояния устройства проигрывания или вследствие ключевого события от пользователя. BD-ROM предполагает два режима в качестве рабочих сред для управления проигрыванием. Первая рабочая среда похожа на среду устройства проигрывания DVD и представляет собой среду исполнения на основе команд. Другой средой является рабочая среда виртуальной машины Java™. Первая рабочая среда называется режим HDMV. Вторая рабочая среда называется режим BD-J. Так как доступны эти две рабочие среды, динамический сценарий пишется для соответствия одной из этих рабочих сред. Динамический сценарий, написанный для соответствия режиму HDMV, называется «объект-фильм», и динамический сценарий, написанный для соответствия режиму BD-J, называется «объект BD-J».

Сначала описывается объект-фильм.

1.5. Объект-фильм

Объект-фильм хранится в файле «MovieObject.bdmv», показанном на фиг.1, и включает в себя последовательность команд навигации.

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

Команда PlayPL

Формат: PlayPL(1-й аргумент, 2-й аргумент)

В качестве 1-го аргумента записывается номер PlayList для задания проигрывания PlayList. В качестве 2-го аргумента записываются PlayItem, включенный в PlayList, заданный момент времени в PlayList, Chapter или Mark для задания начального положения проигрывания.

Функция PlayPL, использующая PlayItem для задания начального положения проигрывания на временной оси PL, упоминается как «PlayPLatItem()».

Функция PlayPL, использующая Chapter для задания начального положения проигрывания на временной оси PL, упоминается как «PlayPLatChapter()».

Функция PlayPL, использующая временную информацию для задания начального положения проигрывания на временной оси PL, упоминается как «PlayPLatSpecifiedTime()».

Формат записи команды навигации в объекте-фильме напоминает формат записи команды навигации в DVD. Это делает возможным эффективно переносить содержимое диска с DVD на BD-ROM. Определенная ниже международная публикация в качестве предшествующего уровня техники описывает объект-фильм. За подробностями в отношении объекта-фильма, обращайтесь к международной публикации WO 2004/074976.

До сих пор описывался объект-фильм. Нижеследующее описывает объект BD-J.

1.6. Объект BD-J

Объект BD-J представляет собой динамический сценарий режима BD-J, который записывается в среде программирования Java™, и хранится в файле «00001.bobj». Объект BD-J отличается от объекта-фильма тем, что он не содержит команду, непосредственно записанную в нем. Т.е. в объекте-фильме процедура управления непосредственно записывается в команду навигации. В противоположность этому, в объекте BD-J процедура управления определяется косвенно, причем спецификации для приложений Java™ пишутся в таблице управления приложениями. Такое косвенное определение позволяет совместно использовать процедуру управления, в которой процедура управления совместно используется множеством динамических сценариев, подлежащих эффективному выполнению.

Проигрывание PlayList, используя объект-фильм, достигается посредством записи команды навигации (команды PlayPL), которая инструктирует на воспроизведение PlayList. Проигрывание PlayList, используя объект BD-J, достигается включением таблицы управления PlayList, которая указывает процедуры проигрывания PlayList, в объект BD-J.

Ниже описываются приложения Java™ в режиме BD-J. Предполагается в данном случае, что на платформе Java™ в режиме BD-J полностью установлены персональный основной профиль (PBP 1.0) технологии Java2Micro_Edition (J2ME) и спецификация (GEM 1.0.2) глобально исполняемой MHP для целевых объектов упакованной среды передачи.

Приложения Java™ в режиме BD-J управляются менеджером приложений через интерфейс xlet. Интерфейс xlet имеет четыре состояния: «загруженный», «приостановленный», «активный» и «уничтоженный».

Вышеописанная платформа Java™ включает в себя стандартную библиотеку Java™ для отображения данных изображения, соответствующих JFIF (JPEG), PNG или т.п. С такой структурой приложения Java™ могут достигать инфраструктуры GUI, которая отличается от GUI, достигаемого IG-потоком в режиме HDMV. Инфраструктура GUI в приложениях Java™ включает в себя инфраструктуру HAVi, определенной в GEM1.0.2 и механизм навигации с дистанционным управлением в GEM1.0.2.

С такой структурой приложения Java™ могут осуществлять отображения экрана, на котором движущееся отображается на экране вместе с кнопками, текстом и онлайновым отображением в режиме реального времени (содержимого BBS), основываясь на инфраструктуре HAVi, и можно выполнять операции на отображаемом экране, используя дистанционное управление.

Сущностью приложений Java™ является архивный файл Java™ (00001.jar), хранимый в каталоге BDJA под каталогом BDMV, показанным на фиг.1.

Международные публикации WO 2004/045840 A1, WO 2005/036555 A1 и WO 2005/036546 A1 в качестве предшествующего уровня техники описывают объект BD-J. Подробности в отношении объекта BD-J раскрыты в этих международных публикациях.

До сих пор описывался объект BD-J.

2. Устройство проигрывания

2.1. Структура аппаратных средств

Фиг.9 изображает внутреннюю структуру устройства 1000 проигрывания. Устройство проигрывания настоящего изобретения состоит, главным образом, из двух частей: системной LSI; и приводного устройства, и может производиться промышленным способом посредством установки этих частей в корпус и на подложку. Системная LSI представляет собой интегральную схему, которая включает в себя различные блоки обработки, которые выполняют функции устройства проигрывания. Устройство проигрывания, производимое таким образом, включает в себя: привод 10 BD-ROM, буфер 20 считывания, системный целевой декодер 300, блок 40 добавления плоскости, кодер 50, цифроаналоговый (Ц/А) преобразователь 60, память 70, блок 80 преобразования PID, набор 90 PSR, контроллер 100, блок 110 приема операции и блок 120 передачи/приема HDMI.

Привод 10 BD-ROM считывает данные с BD-ROM 1, основываясь на запросе считывания, введенным с контроллера 100. AVClip, считанный с BD-ROM 1, передается на буфер 20 считывания, и информация управления (индексный файл, файл PlayList и файл информации Clip) и файл MovieObject.bdmv и файл объекта BD-J (ниже также упоминаемый как «файлы программ BD») передаются в память 70.

Буфер 20 считывания представляет собой память FIFO, в которой сохраняются TS-пакеты, считанные с BD-ROM 1, по способу обратного магазинного типа.

Системный целевой декодер 300 демультиплексирует TS-пакеты, хранимые в буфере 20 считывания и декодирует потоки. Информация, необходимая для декодирования потоков, включенных в TS-пакеты, такая как тип кодека и атрибут потока, передается с контроллера 100.

Конкретно, системный целевой декодер 300 включает в себя демультиплексор 301, блок 302 генерирования ATC, блок 303 генерирования STC, декодер 304 плоскости интерактивной графики (IG-декодер), плоскость 305 интерактивной графики (IG-плоскость), декодер 306 графики представления (PG-декодер), плоскость 307 графики представления (PG-плоскость), видеодекодер 308, плоскость 309 видео, декодер 310 JPEG, плоскость 311 неподвижного изображения, переключатель 312 и аудиодекодер 313.

Демультиплексор 301 извлекает TS-пакеты, хранимые в буфере 20 считывания, и получает PES-пакеты из извлеченных TS-пакетов. Демультиплексор 301 затем выводит из числа полученных PES-пакетов PES-пакеты, имеющие PID, объявленные блоком 80 преобразования PID, на один из видеодекодера 308, аудиодекодера 313, IG-декодера 304 и PG-декодера 306.

Блок 302 генерирования ATC генерирует часы времени поступления (ATC) в соответствии с инструкцией контроллера 100 и настраивает временные соотношения работы демультиплексора 301.

Блок 303 генерирования STC генерирует часы системного времени (STC) в соответствии с инструкцией контроллера 100 и настраивает временные соотношения работы каждого декодера.

IG-декодер 304 декодирует поток интерактивной графики, вводимый от демультиплексора 301, и записывает несжатые данные интерактивной графики в IG-плоскость 305 в момент времени представления (PTS).

IG-плоскость 305 представляет собой плоскость для хранения графических данных.

PG-декодер 306 декодирует поток графики представления, вводимый от демультиплексора 301, и записывает несжатые данные графики представления в PG-плоскость 307 в момент времени представления (PTS).

PG-плоскость 307 представляет собой плоскость для хранения графических данных.

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

Плоскость 309 видео представляет собой плоскость для хранения несжатого изображения. «Плоскость» представляет собой область памяти в устройстве проигрывания для хранения данных пикселов одного экрана. Разрешение плоскости 5 видео составляет 1920×1080. Данные изображения, хранимые в плоскости 309 видео, состоят из множества порций данных пикселов, каждая из которых представлена 16-битовым значением YUV.

Декодер 310 JPEG декодирует графические данные (например, данные JPEG) и записывает полученные данные в плоскость 311 неподвижного изображения.

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

Переключатель 312 переключается между (а) подачей на аудиодекодер 313 TS-пакетов главного аудиопотока, демультиплексированного демультиплексором 301, и (b) не подачей на аудиодекодеры 313, но выводом аудиопотоков на другие устройства (сквозной вывод).

Аудиодекодер 313 декодирует PES-пакеты, вводимые от демультиплексора 301, и выводит несжатые аудиоданные. Аудиодекодер 313 может декодировать NAC-поток.

Блок 40 добавления плоскости генерирует видеосигнал посредством мгновенного наложения плоскости 309 видео, PG-плоскости 307, IG-плоскости 305 и плоскости 311 неподвижного изображения и выводит сгенерированный сигнал изображения на устройство отображения, такое как цифровой TV.

Кодер 50, когда аудиоданные в состоянии LPCM, которое получается в результате декодирования аудиодекодером 313, посылаются в виде окружающего звука/голоса через цифровой интерфейс, такой как S/PDIF, кодирует и сжимает LPCM в формат Dolby Digital (DD) или формат театральной системы Dolby (DTS).

Ц/А преобразователь 60 преобразует аудиоданные в состояние LPCM, которое получается в результате декодирования аудиодекодером 313, в аналоговые данные и выводит преобразованные данные на внешнее устройство.

Память 70 представляет собой память для хранения информации текущего PL, информации текущего Clip и т.п. в дополнение к файлам программы BD. Информация текущего PL представляет собой информацию PlayList, которая обрабатывается в настоящий момент из множества порций информации PlayList, хранимой на BD-ROM. Информация текущего Clip представляет собой информацию Clip, которая обрабатывается в настоящий момент, из множества порций информации Clip, хранимой на BD-ROM.

Блок 80 преобразования PID преобразует номер потока главных аудиопотоков, хранимых в наборе 90 PSR, в PID, основываясь на ES_table, и уведомляет демультиплексор 301 о PID в качестве результатов преобразования.

Набор 90 PSR представляет собой регистр, встроенный в устройство проигрывания, и состоит из 64 регистров установок/состояния проигрывателя (PSR) и 4096 регистров общего назначения (GPR). Среди набора значений (PSR) в регистрах установок/состояний проигрывателя PSR4-PSR8 используются для представления текущей точки проигрывания.

Контроллер 100 включает в себя CPU 100а и ROM 100b инструкций.

CPU 100а осуществляет управление проигрыванием BD-ROM посредством декодирования объекта-фильма и приложения Java™, к которому обращается объект BD-J, хранимый в MovieObject.bdmv, и выполнения проигрывания PlayList в соответствии с результатом декодирования (т.е. управление проигрыванием в соответствии с информацией текущего PL). CPU 100а также выполняет вышеупомянутое управление ATC и STC.

ROM 100b инструкций хранит программное обеспечение, определяющее управление устройством проигрывания.

Блок 110 приема операции принимает детализацию операции от пользователя и уведомляет контроллер 100 об информации о пользовательском событии, которая указывает операцию, заданную пользователем.

Блок 120 передачи/приема HDMI принимает от устройства, подсоединенного через HDMI (мультимедийных интерфейс высокого разрешения), информацию, касающуюся устройства. Также, блок 120 передачи/приема HDMI передает цифровое несжатое видео, которое получается в результате декодирования видеодекодером 308, на устройство через HDMI вместе с аудиоданными LPCM или сжатыми аудиоданными.

До сих пор объяснялась аппаратная конструкция устройства 100 проигрывания. Ниже описывается структура программных средств устройства 100 проигрывания.

2.2. Структура программных средств

Фиг.10 изображает функции контроллера 100. Как показано на фиг.10, контроллер 100 включает в себя блок 101 исполнения программ, блок 102 управления проигрыванием, блок 103 исполнения процедур и блок 104 управления ATC/STC, который вызывает блоком 302 генерирования ATC и блоком 303 генерирования STC генерирование ATC и STC, соответственно.

Эти компоненты выполняют процессы, основанные на наборе 90 PSR. Нижеследующее объясняет PSR1, PSR15 и PSR31.

<PSR1>

Фиг.11А изображает назначение битов в PSR1.

Как показано на фиг.11А, младшие восемь битов (b0-b7) из 32 битов PSR1 представляют номер потока и идентифицируют один из множества главных аудиопотоков, элементы которых записываются в ES-таблицу текущей позиции проигрывания. Когда изменяется значение, установленное в PSR1, устройство 1000 проигрывания проигрывает главный аудиопоток, соответствующий установленному значению после изменения. PSR1 устанавливается на «0xFF» в качестве начального значения и затем может устанавливаться на значение в диапазоне от «1» до «32» устройством 1000 проигрывания. Значение «0xFF» представляет собой неустановленное значение и указывает, что нет главного аудиопотока, или что главный аудиопоток не был выбран. Если PSR1 устанавливается на значение в диапазоне от «1» до «32», установленное значение интерпретируется как номер потока главного аудиопотока.

<PSR15>

Фиг.11В изображает назначение битов в PSR15.

Как показано на фиг.11В, PSR15 включает в себя возможность DRA, возможность Dolby Lossless, возможность DTS-HD, возможность Dolby Digital Plus и возможность LPCM.

Возможность DRA включает в себя расширение DRA и ядро DRA. Каждое из расширения DRA и ядра DRA, если установлено в 01b, указывает, что устройство проигрывания способно проигрывать стереофоническое аудио в формате DRA, и, если установлено в 10b, указывает, что устройство проигрывания способно проигрывать окружающее аудио в формате DRA. Если установлено в 00b, каждое из расширения DRA и ядра DRA указывает, что устройство проигрывания неспособно декодировать аудиопотоки в формате DRA.

<PSR31>

Фиг.11С изображает назначение битов в PSR31.

Как показано на фиг.11С, младшие 16 битов (b0-b15) из 32 битов PSR31 представляют информацию о версии проигрывателя. Если младшие 16 битов равны «0000 0010 0000 0000b», они указывают, что версия устройства проигрывания является 2.0, 2.1 или 2.2. Если младшие 16 битов равны «0000 0010 0011 0000b», то они указывают, что версия устройства проигрывания является 2.3.

До сих пор описывался набор 90 PSR.

Ниже описывается блок 101 исполнения программ, блок 102 управления проигрыванием и блок 103 исполнения процедур.

Блок 101 исполнения программ

Блок 101 исполнения программ исполняет программы, хранимые в файле программ BD, хранимом в памяти 70. Конкретно, блок 101 исполнения программ, основываясь на событии пользователя, введенном от блока 110 приема операции, инструктирует блок 102 управления проигрыванием на проигрывание PlayList или инструктирует блок 103 исполнения процедур на получение/установку состояния набора 90 PSR.

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

Сначала программа BD проверяет значение версии проигрывателя в PSR 31 (этап S101) и оценивает, поддерживает ли или нет устройство проигрывания NAC. Более конкретно, программа BD оценивает, является ли или нет номер версии, указанный версией проигрывателя в PSR 31, не меньше номера версии, указанного Version_number в PlayList (00001.mpls) (этап S102).

Если номер версии, указанный версией проигрывателя в PSR 31, не меньше номера версии, указанного при помощи Version_number в PlayList (00001.mpls) (ДА на этапе S102), программа BD инструктирует блок 102 управления проигрыванием на проигрывание PlayList (00001.mpls).

Если номер версии, указанный версией проигрывателя в PSR 31, меньше номера версии, указанного при помощи Version_number в PlayList (00001.mpls) (НЕТ на этапе S102), программа BD инструктирует блок 102 управления проигрыванием на проигрывание PlayList (00002.mpls), имеющий Version_number 1.0 или 2.0.

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

Блок 102 управления проигрыванием

Блок 102 управления проигрыванием управляет проигрыванием AVClip посредством управления приводом 10 BD-ROM и системным целевым декодером 300. Например, блок 102 управления проигрыванием обращается к информации PlayList, хранимой в памяти 70, основываясь на инструкции проигрывания, введенной от блока 101 исполнения программ, на управление обработкой проигрывания AVClip.

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

На данной блок-схеме последовательности операций сначала считывается информация текущего PL (.mpls) (этап S201), и затем выполняются этапы S202-S210. Этапы S202-S210 составляют цикл, в котором этапы S203-S210 выполняются циклически для каждой порции информации PI, которая составляет информацию текущего PL до тех пор, пока не будет выполнена оценка Да на этапе S209. В этом циклическом процессе PlayItem цели процесса упоминается как PlayItem#x (PI#x). PlayItem#x инициализируется установкой на начальную PlayItem информации текущего PL (этап S202). Условием окончания цикла является то, что PlayItem#x является последняя PlayItem информации текущего PL (этап S209). Если на этапе S209 выполнена оценка, что PlayItem#x не является последней PlayItem информации текущего PL, PlayItem#x устанавливается на следующую PlayItem в информации текущего PL (этап S210).

На этапах S203-S210, которые циклически выполняются в процессе цикла, информация Clip, задаваемая Clip_information_file_name в PlayItem#x, считывается в память (этап S203), In_time в PlayItem#x преобразуется в адрес u I-изображения, используя EP_map информации текущего Clip (этап S204), Out_time в PlayItem#x преобразуется в адрес v I-изображения, используя EP_map информации текущего Clip (этап S205), получают адрес I-изображения следующего за адресом v I-изображения, и адрес, который предшествует полученному адресу на единицу, устанавливается на адрес w (этап S207), и привод 1 BD-ROM или локальное запоминающее устройство 200 инструктируется на считывание TS-пакетов с адреса u по адрес w I-изображения (этап S208).

С другой стороны, видеодекодер или т.п. инструктируется на вывод из mark_time_stamp текущего PLMark в Out_time в PlayItem#x (этап S206). На этапах S205-S208 воспроизводится часть AVClip, заданная посредством PlayItem#x.

После этого оценивается, является ли или нет PlayItem#x последней PlayItem информации текущего PL (этап S209).

Если на этапе S209 оценивается, что PlayItem#x не является последней PlayItem информации текущего PL, PlayItem#x устанавливается на следующую PlayItem в информации текущего PL (этап S210), и управление возвращается на этап S203. Когда повторяются вышеописанные этапы S203-S210, последовательно воспроизводится каждая порция информации PI, которая составляет информацию текущего PL.

Блок 103 исполнения процедур

Блок 103 исполнения процедур, когда возникает необходимость изменения порции информации PlayItem на другую, или когда пользователь инструктировал посредством операции на изменение номера потока, исполняет заданную процедуру выбора потока и записывает новый номер потока в PSR1. Устройство 1000 проигрывания проигрывает главный аудиопоток в соответствии с номером потока, записанным в PSR1. Установка PSR1, таким образом, позволяет выбирать главный аудиопоток.

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

Блок 103 исполнения процедур приводит к изменению состояния PSR1, как показано на фиг.14А. Фиг.14А изображает переход состояния значения, установленного в PSR1. Необходимо заметить в данном случае, что на фиг.14А термин «действительный» означает, что значение PSR1 равно или меньше числа stream_entries, записанных в ES_table PlayItem, и является декодируемым.

Термин «недействительный» означает, что (а) значение PSR1 равно «0», (b) значение PSR1 больше числа stream_entries, записанных в ES_table PlayItem, или (с) декодирование не является доступным, даже если число stream_entries, записанных в ES_table PlayItem, находится в диапазоне от «1» до «32».

Рамки, нарисованные пунктирными линиями на фиг.14А, указывают процедуру для определения значения PSR, когда изменяется состояние. Процедура установки значения в PSR классифицируется на «процедуру, когда меняется условие проигрывания» и «процедуру, когда запрашивается изменение потока».

«Процедура, когда меняется условие проигрывания» представляет собой процедуру, подлежащую исполнению, когда устройство проигрывания изменило состояние из-за некоторого события, которое произошло с устройством.

«Процедура, когда запрашивается изменение потока» представляет собой процедуру, подлежащую исполнению, когда пользователь запрашивает некоторое изменение (на фиг.14А «Изменить поток»).

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

Стрелки на фиг.14А символически указывают переход состояния PSR.

Примечания, присоединенные к стрелкам, указывают события, которые запускают каждый переход состояния. Т.е., фиг.14А указывает, что переход состояния PSR1 происходит тогда, когда происходит событие, такое как «Загрузить диск», «Изменить поток», «Начать проигрывание PlayList», «Пересечь границу PlayItem» или «Завершить проигрывание PlayList». Ссылаясь на фиг.14А, понятно, что вышеупомянутые процедуры не выполняются тогда, когда происходит переход состояния «недействительный > недействительный» или «действительный > недействительный». С другой стороны, переходы состояния «недействительный > действительный» и «действительный > действительный» выполняются через рамки с пунктирными линиями. Т.е., вышеупомянутая «процедура, когда меняется условие проигрывания» или «процедура, когда запрашивается изменение потока» выполняется тогда, когда PSR1 установлен на «действительный».

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

Событие «Загрузить диск» указывает, что BD-ROM был загружен в устройство проигрывания. При такой загрузке PSR1 один раз устанавливается на непредусмотренное значение (0xFF).

Событие «Начать проигрывание PlayList» указывает, что начался процесс проигрывания, основанный на PlayList. Когда происходит такое событие, исполняется «процедура, когда меняется условие проигрывания», и PSR1 устанавливается на «действительный».

Событие «Завершить проигрывание PlayList» указывает, что завершен процесс проигрывания, основанный на PlayList. Понятно, что, когда происходит такое событие, не исполняется «процедура, когда меняется условие проигрывания», и PSR1 устанавливается на «недействительный».

Событие «ИзменитьХХХ» указывает, что пользователь запросил изменение ХХХ (на фиг.14А, Поток). Если происходит это событие, когда PSR1 является «недействительным» (указано посредством «cj1» на фиг.14А), PSR1 устанавливается на запрашиваемое значение. Даже если значение, которое устанавливается таким образом, указывает действительный номер потока, значение, установленное в PSR1, рассматривается как «недействительное» значение. Т.е., при переходе состояния, запускаемого событием «ИзменитьХХХ», PSR никогда не меняется с «недействительного» на «действительный».

С другой стороны, если событие «Изменить поток» происходит тогда, когда PSR1 является «действительным» (указано посредством «cj2» на фиг.14А), исполняется «процедура, когда запрашивается изменение потока», и PSR1 устанавливается на новое значение. В данном случае, значение, установленное тогда, когда исполняется «процедура, когда запрашивается изменение потока», не может быть значением, требуемым пользователем. Это потому, что «процедура, когда запрашивается изменение потока» имеет функцию исключения недействительного значения. Если событие «Изменить поток» происходит тогда, когда PSR1 является «действительным», PSR1 никогда не меняется с «действительного» на «недействительный». Это потому, что «процедура, когда запрашивается изменение потока» гарантирует, что PSR1 не станет «недействительным».

Событие «Пересечь границу PlayItem» указывает, что была пересечена граница позиции проигрывания. В данном случае, граница позиции проигрывания представляет собой границу между двумя последовательными позициями проигрывания, а именно положение между окончанием предыдущей позиции проигрывания и началом последующей позиции проигрывания, среди двух последовательных позиций проигрывания. Если событие «Пересечь границу PlayItem» происходит тогда, когда PSR1 является «действительным», исполняется «процедура, когда меняется условие проигрывания». После исполнения «процедуры, когда меняется условие проигрывания» состояние PSR1 или возвращается в «действительное» или переходит в «недействительное». Так как ES_table обеспечивается в соответствии с каждой позицией проигрывания, если меняется позиция проигрывания, также меняется проигрываемый элементарный поток. Целью перехода состояния является установка PSR1 на наиболее подходящее значение для каждой позиции проигрывания посредством исполнения «процедуры, когда меняется условие проигрывания» каждый раз, когда начинается воспроизведение позиции проигрывания.

При вышеописанном переходе состояния «процедура, когда меняется условие проигрывания» исполняется так, как показано на фиг.14В. Фиг.14В представляет собой блок-схему последовательности операций «процедуры, когда меняется условие проигрывания». Процедура устанавливает значение в PSR1 посредством выполнения двух этапов выполнения оценки, S301 и S302.

На этапе S301 оценивается, равно ли число stream_entries в ES_table «0». Если оценивается, что число stream_entries в ES_table равно «0», значение PSR1 сохраняется (этап S330).

На этапе S302, который исполняется, если оценивается на этапе S301, что число stream_entries в ES_table не равно «0», оценивается, является ли число stream_entries в ES_table равным или больше PSR1, и является ли достоверным условие (А). В данном случае, условие (А) заключается в том, что устройство проигрывания имеет возможность воспроизводить главный аудиопоток, идентифицируемый PSR1. Если результат оценки на этапе S302 является положительным, значение PSR1 сохраняется (этап S304).

Если или значение PSR1 больше числа stream_entries в ES_table, или не удовлетворяется условие (А), процесс выполняется для установки PSR1 (этап S305).

Фиг.15 представляет собой блок-схему последовательности операций, изображающую подробную процедуру этапа S305. На этой блок-схеме последовательности операций этапы S401 и S402 составляют цикл, в котором этап S403 выполняется циклически для всех главных аудиопотоков. В этом цикле главный аудиопоток цели процесса упоминается как главный аудиопоток i. На этапе S404 проверяется, удовлетворяет ли главный аудиопоток i условиям (а), (b) и (с).

Условие (а) заключается в том, что устройство проигрывания имеет возможность воспроизводить главный аудиопоток i, и оценивается, удовлетворяется ли условие, посредством сравнения PSR15 с coding_type главного аудиопотока i.

Условие (b) заключается в том, что атрибут языка главного аудиопотока i одинаков с установкой языка в устройстве проигрывания, и оценивается, выполняется ли условие, посредством проверки, равен ли audio_language_code главного аудиопотока i, записанного в ES_table, значению, установленному в PSR 16.

Условие (с) заключается в том, что атрибутом канала главного аудиопотока i является окружающий звук, и устройство проигрывания имеет возможность воспроизводить его, и оценивается, удовлетворяется ли условие, посредством сравнения PSR15 с presentation_type и coding_type главного аудиопотока i.

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

После того как процесс будет циклически выполнен для всех главных аудиопотоков, выполняются этапы S404-S408. На этапе S404 оценивается, является ли достоверным то, что главный аудиопоток не выполняет условие (а). Если оценивается, что это достоверно, неопределенное значение (0xFF) устанавливается в PSR1 (этап S409).

На этапе S405 оценивается, имеются ли главные аудиопотоки, которые удовлетворяют всем условиям (a), (b) и (c). Если оценка является положительной (Да на этапе S405), номера потоков таких главный аудиопотоков, которые удовлетворяют всем условиям (а), (b) и (с), устанавливаются в PSR1 (этап S410).

В данном случае, если имеется множество главных аудиопотоков, которые удовлетворяют всем условиям (a), (b) и (c), то необходимо определить один из них, который устанавливается в PSR1. На этапе S410 определяется, основываясь на очередности stream_entries в ES_table. Т.е., на этапе S410, если имеется множество главных аудиопотоков, в которых одинаковые кодек, атрибут языка и атрибут канала, выполняется ссылка на ES_table, и выбирается главный аудиопоток, который является первым по очередности stream_entries в ES_table.

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

Если нет главных аудиопотоков, которые удовлетворяют всем условиям (a), (b) и (c), управление переходит на этап S406, на котором оценивается, имеются ли главные аудиопотоки, которые удовлетворяют условиям (а) и (b). Если оценивается, что имеются главные аудиопотоки, которые удовлетворяют условиям (а) и (b) (Да на этапе 406), главный аудиопоток среди них, который является первым по очередности stream_entries в ES_table, устанавливается в PSR1 (этап S411).

Если нет главного аудиопотока, который удовлетворяет всем условиям (а), (b) и (с), и нет главного аудиопотока, который удовлетворяет условиям (а) и (b), управление переходит на этап S407, на котором оценивается, имеются ли главные аудиопотоки, которые удовлетворяют условиям (а) и (с). Если оценивается, что имеются главные аудиопотоки, которые удовлетворяют условиям (а) и (с) (Да на этапе S407), главный аудиопоток среди них, который является первым по очередности из stream_entries в ES_table, устанавливается в PSR1 (этап S412).

Если нет главного аудиопотока, который удовлетворяет всем условиям (а), (b) и (с), нет главного аудиопотока, который удовлетворяет условиям (а) и (b), и нет главного аудиопотока, который удовлетворяет условиям (а) и (с), управление переходит на этап S408, на котором оценивается, имеются ли главные аудиопотоки, которые удовлетворяют условию (а). Если оценивается, что имеются главные аудиопотоки, которые удовлетворяют условию (а) (Да на этапе S408), главный аудиопоток среди них, который является первым по очередности из stream_entries в ES_table, устанавливается в PSR1 (этап S413).

До сих пор объяснялась «процедура, когда меняется условие проигрывания». Ниже описывается «процедура, когда запрашивается изменение потока». Фиг.16 представляет собой блок-схему последовательности операций, изображающую процедуру установки PSR1, когда запрашивается изменение потока. Блок-схема последовательности операций на фиг.16 отличается от блок-схемы последовательности операций на фиг.14В тем, что в некоторых местах Х используется вместо PSR1. «Х» представляет собой значение, определенное на основе информации о событии пользователя, выводимой с блока 110 приема операции, или команды кнопкой, выводимой с IG-декодера 304.

На этапе S501 блок-схемы последовательности операций оценивается, является ли число stream_entries в ES_table равным или больше Х, и является ли условие (А) достоверным. В данном случае, условие (А) заключается в том, что устройство проигрывания имеет возможность воспроизведения главного аудиопотока, идентифицированного посредством PSR1. Оценивается посредством сравнения PSR15 с coding_type главного аудиопотока. Если результат оценки этапа S501 является положительным, Х устанавливается в PSR1 (этап S502).

Если или Х больше числа stream_entries в ES_table, или условие (А) не удовлетворяется (Нет на этапе S502), оценивается, является ли Х равным 0xFF (этап S503).

В данном случае, если Х не равен 0xFF (Нет на этапе S503), считается, что число главного аудиопотока, которое пользователь намеревается выбрать, является недействительным, и значение Х, которое определяется на основе операции пользователя, пренебрегается, и сохраняется значение, установленное в PSR1 (этап S504).

Если Х равен 0xFF (Да на этапе S503), устанавливается PSR1 (этап S505). Процедура обработки этапа S505 одинакова процедуре, показанной на фиг.15 (Среди этапов, показанных на фиг.15, оценка на этапе S404 не требуется в «процедуре, когда запрашивается изменение потока». Это потому, что в «процедуре, когда запрашивается изменение потока», если нет главного аудиопотока, который удовлетворяет условиям (а), (b) и (с), Х, который устанавливается пользователем, не устанавливается в PSR1, и сохраняется значение, установленное в PSR1).

Как выбирается аудиопоток, поддерживающий NAC

Ниже описывается способ выбора аудиопотока, который поддерживает NAC. Приложение BD-J, определяемое файлом JAR (00001.jar), представляет собой программу, исполняемую тогда, когда проигрывается PlayList. Приложение BD-J вызывает отображение устройством проигрывания меню для приема от пользователя операции для выбора NAC-потока и вызывает исполнение устройством проигрывания функции установки аудиопотока NAC. Когда выполняется операция выбора в меню пользователем, функция установки аудиопотока NAC устанавливает PSR 1 на номер потока NAC-потока.

Фиг.17 изображает пример экрана меню. Если от пользователя принимается операция для выбора NAC-потока, т.е., когда выбирается кнопка «Да», PSR1 устанавливается на номер потока NAC-потока.

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

3. Конкретный пример выбора аудиопотока существующим устройством проигрывания

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

Фиг.18А изображает возможность проигрывателя, установку языка и возможность окружающего звука в устройстве проигрывания. Как показано на фиг.18А, предполагается, что существующее устройство проигрывания способно декодировать LPCM и выводить окружающий звук формата AC-3, неспособно декодировать NAC-поток, и установлено с его установкой языка для указания звука на японском языке.

Предположим, что BD-ROM, имеющий записанную ES_table, показанную на фиг.18В, загружается в вышеописанное устройство проигрывания. Эта ES_table описывает stream_entry-stream_attributes шести аудиопотоков, как показано на фиг.18С.

Сначала, основываясь на ES_table, показанной на фиг.18В, устройство проигрывания проверяет, удовлетворяет ли каждый аудиопоток условиям (а), (b) и (с). В данном случае, аудиопоток 1 удовлетворяет только условию (а) из трех условий. Аудиопоток 2 удовлетворяет условиям (а) и (с) из трех условий. Удовлетворяющий только условию (с) и не удовлетворяющий условию (а) аудиопоток 3 нормально не должен быть целью выбора. Однако, так как существующее устройство проигрывания, как предполагается, ошибочно оценивает себя способным декодировать NAC-поток, оценивается, что аудиопоток 3 удовлетворяет условиям (а) и (с), и аудиопоток 3 также является целью выбора. Аудиопоток 4 удовлетворяет условиям (а) и (b). Аудиопоток 5 удовлетворяет условиям (а), (b) и (с). Аудиопоток 6 удовлетворяет условиям (b) и (с). Кроме того, как описано выше, так как существующее устройство проигрывания, как предполагается, ошибочно оценивает себя способным декодировать NAC-поток, аудиопоток 6, как оценивается, удовлетворяет условиям (а), (b) и (с).

Теперь ясны условия, которым удовлетворяют аудиопотоки, и пятому и шестому аудиопотокам, которые удовлетворяют всем условиям (а), (b) и (с), присваивается наибольший приоритет. Когда имеется множество аудиопотоков с наивысшим приоритетом, выбирается аудиопоток, который является первым в очередности stream_entries в ES_table. Следовательно, в данном случае выбирается аудиопоток 5.

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

Как описано выше, согласно настоящему варианту осуществления (а) информация Clip и AV-данные, которые поддерживают NAC, и (b) информация Clip и AV-данные, которые не поддерживают NAC, были сохранены на BD-ROM 1, и информация PlayList, информация Clip и AV-данные выбираются в соответствии с возможностью проигрывания устройства проигрывания. В результате, устройство проигрывания, поддерживающее NAC, проигрывает AV-данные, включающие NAC, используя информацию PlayList и информацию Clip, которые поддерживают NAC, тогда как устройство проигрывания, не поддерживающее NAC, проигрывает AV-данные, не включающие NAC, используя информацию PlayList и информацию Clip, которые не поддерживают NAC. Следовательно, может быть предотвращено неуспешное проигрывание устройством проигрывания, не поддерживающим NAC, из-за присутствия NAC-потока в AV-данных.

Также, в случае, если существующее устройство проигрывания, не поддерживающее NAC, ошибочно проигрывает PlayList, поддерживающий NAC, и ошибочно оценивает, что NAC удовлетворяет условию А при выборе проигрываемого аудиопотока (т.е. NAC-потока, которому присвоен наивысший приоритет), устройство проигрывания не выбирает NAC-поток в качестве аудиопотока для проигрывания.

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

Также, в случае, если языком, зарегистрированным в audio_language_code в качестве атрибута языка, является, например, китайский язык, может возникнуть проблема. Это потому, что ISO 639-2/T определяет только один вид китайского языка в качестве audio_language_code, хотя в действительности существуют различные виды китайских языков, такие как мандаринский, кантонский, шанхайский, фуцзяньский и тайванский диалекты. Следовательно, например, когда три вида аудиопотоков на китайском языке, которые на кантонском, шанхайском и фуцзяньском диалектах, соответственно, мультиплексируются в один AV-поток, одинаковое значение, которое представляет «китайский язык», регистрируется для audio_language_code для этих аудиопотоков. В результате, эти языки могут не отличаться один от другого, основываясь на audio_language_code.

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

Также, в случае если стандарт интерфейса, такой как S/PDIF или HDMI, не поддерживает NAC, устройство проигрывания не может выводить NAC-поток на внешнее устройство (выполнять сквозной вывод). Таким образом, чтобы вывести NAC-поток в цифровом формате, аудиопоток NAC необходимо преобразовать после декодирования в формат, который может передаваться, используя существующий стандарт интерфейса (например, двухканальный LPCM и т.д.), а затем выводиться. Другими словами, даже если количество каналов NAC-потока составляет, например, 5.1 каналов, только двухканальное LPCM может выводиться в качестве цифрового выхода, используя S/PDIF.

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

Модификация

BD-ROM 1 был записан с файлом (00001.m2ts), хранящим цифровой поток, включающий в себя NAC-поток, мультиплексированный в нем, и файлом (00002.m2ts), хранящим цифровой поток, не включающий в себя NAC-поток, мультиплексированный в нем.

Однако, в случае, если единственным различием между файлом (00001.m2ts) и файлом (00002.m2ts) является, мультиплексируется ли NAC-поток в сохраняемый цифровой поток или нет, т.е. аудиопотоки, видеопотоки и т.п., за исключением того случая, когда NAC-поток один и тот же, запись обоих файлов (00001.m2ts) и (00002.m2ts) излишне увеличивает размер AV-данных, подлежащих записи на BD-ROM 1. Ниже описывается модификация, использующая функцию виртуального контейнера для решения этой проблемы.

Виртуальный контейнер представляет собой метод обработки данных, которые не записываются на BD-ROM 1, как если бы данные записывались на него посредством объединения записываемого содержимого BD-ROM с записываемым содержимым локального запоминающего устройства (например, HDD) в устройстве 1000 проигрывания.

Фиг.19 изображает структуру данных BD-ROM 1а и HDD 1b.

Различие между BD-ROM 1 и BD-ROM 1а заключается в том, сохраняются ли файлы с именем файла «00002» или нет. В BD-ROM 1а каждый каталог непосредственно под каталогом BDMV включает в себя файлы, имеющие имя файла, содержащее «00001». Также, цифровой поток, хранимый в файле (00001.m2ts), включает в себя NAC-поток, и файл (00001.mpls (с NAC)) и файл (00001.clip (с NAC)) соответствуют файлу (00001.m2ts) и содержат информацию о NAC-потоке.

С другой стороны, в HDD 1b есть подкаталог «организация» под корневым каталогом и под подкаталогом «организация» есть подкаталог «disc#1». Каталог «организация» распределяется для конкретного поставщика фильма. Каталог «disc#1» распределяется для каждого BD-ROM, обеспеченного поставщиком.

Каталог «disc#1» хранит файл (00001.mpls (без NAC)), соответствующий файлу (00001.m2ts) и не включающий в себя информацию о NAC-потоке, файл (00001.clip (без NAC)) и файл информации управления объединением, который хранит информацию управления объединением.

Информация управления объединением однозначно указывает файлы, составляющие виртуальный контейнер из числа файлов, включенных в каталог «disc#1» на HDD 1b. Файл информации управления объединением включает в себя информацию о положении хранения каждого файла на HDD 1b, составляющего виртуальный контейнер. Каждая порция информации о положении хранения состоит из «идентификатора» для доступа к каждому файлу в качестве виртуального контейнера и «пути файла», указывающего положение хранения файла на HDD 1b.

Ниже описывается, как динамически переключаться между (а) файлом (00001.mpls (с NAC)) и файлом (00001.clip (с NAC)), которые поддерживают NAC, и (b) файлом (00001.mpls (без NAC)) и файлом (00001.clip (без NAC)), которые не поддерживают NAC.

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

Приложение BD-J (не показано), вызываемое посредством «Первого названия проигрывания», оценивает, имеет ли или нет устройство проигрывания возможность декодирования NAC-потока, основываясь, например, на значении поля, возможности проигрывателя PSR 15, которое указывает, является ли способным или нет декодировать NAC-поток.

Если оценивается, что устройство проигрывания способно декодировать NAC-поток, устройство проигрывания начинает проигрывание, используя файл (00001.m2ts), файл (00001.mpls (с NAC)), файл (00001.clip (с NAC)) и т.п., записанные на BD-ROM.

Если оценивается, что устройство проигрывания не способно декодировать NAC-поток, приложение BD-J создает виртуальный контейнер, основанный на информации управления объединением. В данном случае, файл (00001.mpls (без NAC)) и файл (00001.clip (без NAC)) имеют общие имена файлов с файлом (00001.mpls (с NAC)) и файлом (00001.clip (с NAC)). Следовательно, если каталог, указанный «идентификатором» для доступа к файлу (00001.mpls (без NAC)) в качестве виртуального контейнера, и каталог файла (00001.mpls (с NAC)) являются одинаковыми, файл (00001.mpls (с NAC)) может быть заменен файлом (00001.mpls (без NAC)). Подобная обработка выполняется с файлом (00001.clip (без NAC)) и файлом (00001.clip (с NAC)).

Как описано выше, если устройство проигрывания не поддерживает NAC, приложение BD-J создает виртуальный контейнер, таким образом заменяя файл (00001.mpls (с NAC)) и файл (00001.clip (с NAC)) файлом (00001.mpls (без NAC)) и файлом (00001.clip (без NAC)), и начинает проигрывание.

Устройство проигрывания, способное декодировать NAC-поток, выполняет проигрывание, используя информацию PlayList, Clip и другие, которые поддерживают NAC. С другой стороны, устройство проигрывания, неспособное декодировать NAC-поток, заменяет файл (00001.mpls (с NAC)) и файл (00001.clip (с NAC)) файлом (00001.mpls (без NAC)) и файлом (00001.clip (без NAC)) перед проигрыванием. Таким образом, даже если информация PlayList и Clip без информации о NAC не включена в BD-ROM 1а, информация PlayList и Clip все же может использоваться для выполнения проигрывания.

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

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

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

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

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

Как показано на фиг.20, в AVClip мультиплексируются: видеопоток с высоким качеством изображения, имеющий PID 0x1011; главные аудиопотоки, имеющие PID 0x1100-0x110F; вспомогательные аудиопотоки, имеющие PID 0x1110-0x111F; PG-потоки, имеющие PID 0x1200-0x121F; и IG-потоки, имеющие PID 0x1400-0x141F.

Нижеследующее описывает подробности «ES_table» в настоящем варианте осуществления.

Фиг.21 изображает внутреннюю структуру ES_table. По существу, она аналогична ES_table, показанной на фиг.5. Отличие от ES_table на фиг.5 заключается в том, что каждый stream_entry-stream_attributes включает в себя Comb_info_Sequence_audio_Primary_audio.

Фиг.22А изображает внутреннюю структуру Comb_info_Secondary_audio_Primary_audio. Comb_info_Secondary_audio_Primary_audio включает в себя number_of_primary_audio_stream_ref_entries, которые указывают общее число главных аудиопотоков, которые могут быть объединены; и Primary_audio_stream_id_ref[0]-[n], который указывает номера потоков главных аудиопотоков, которые могут быть объединены во время проигрывания.

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

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

Фиг.22В изображает пример Comb_info_Secondary_audio_Primary_audio. Как показано на фиг.21, аудиопоток, который был кодирован в формате AC3 и имеет номер потока 00000001, является первым в очередности элемента, и после него находится элемент аудиопотока, который был кодирован в NAC и имеет номер потока 00000010.

Третий вариант осуществления

В третьем варианте осуществления описывается вариант осуществления устройства записи и способа записи настоящего изобретения.

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

Фиг.23 изображает внутреннюю структуру устройства 3000 записи. Как показано на фигуре, устройство 3000 записи включает в себя видеокодер 3001, блок 3002 производства материала, блок 3003 генерирования сценария, блок 3004 производства программ BD, блок 3005 мультиплексирования и блок 3006 обработки формата.

Видеокодер 3001 создает видеопотоки посредством кодирования видеоизображений, таких как несжатое растровое изображение согласно стандарту сжатия, такому как MPEG4-AVC и MPEG2.

Блок 3002 производства материала создает потоки, такие как аудиопотоки, потоки графики представления и потоки интерактивной графики. Более конкретно, блок 3002 производства материала создает аудиопотоки посредством кодирования несжатого аудио с линейной PCM и т.п. согласно стандарту сжатия, такому как AC3, DTS или NAC.

При создании NAC-потока блок 3002 производства материала также создает обычно кодированный поток, который кодируется с этого же аудиоисточника, что и NAC-поток. В данном случае, язык и количество каналов устанавливается такими, чтобы они были одинаковыми у NAC-потока и обычно кодированного потока.

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

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

Блок 3003 создания сценария создает сценарии в формате, соответствующем стандарту BD-ROM, согласно информации о потоках, созданных блоком 3002 производства материала, или операции пользователя. В данном случае, сценарии соответствуют файлам, таким как индексный файл, файл объекта-фильма и файл PlayList.

В данном случае, описывается синтаксис stream_attributes() в ES_table. Фиг.24 изображает синтаксис stream_attributes(). Каждый stream_attributes(), показанный на фиг.7, генерируется на основе данного синтаксиса. Coding_type stream_attributes указывает тип каждого элементарного потока, т.е., если элементарный поток представляет собой видеопоток, в котором был сжат один из элементарных потоков по стандарту MPEG4-AVC, MPEG2 и VC1, и, если элементарным потоком является аудиопоток, в котором элементарный поток был сжат по одному из AC3, DTS, LPCM и NAC.

Если coding_type представляет собой одно из MPEG4-AVC, MPEG2 и VC1, за coding_type следует поля video_format и frame_rate.

Если coding_type представляет собой одно из AC3, DTS, LPCM и NAC, за coding_type следует поля presentation_type, sampling_frequency и audio_language_code.

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

Однако с данной структурой полей необходимо отметить следующее: если coding_type уже был определен, поток может проигрываться, так как поля, следующие за coding_type, могут считываться соответствующим образом; однако, например, если в дополнение к определенному NAC, в будущем добавиться другой NAC (ниже упоминаемое как «неопределенный NAC»), может возникнуть проблема. Это потому, что, хотя неопределенный NAC может быть зарегистрирован как coding_type в структуре поля, маловероятно, что устройство проигрывания, которое не распознает неопределенный NAC, сможет провести дополнительный анализ stream_attributes.

Ввиду этого, если установлен неопределенный NAC, поле coding_type интерпретируется как заполнение, как показано на фиг.24. Конкретно, устройство проигрывания, не поддерживающее неопределенный NAC, обрабатывает поле coding_type, содержащее неопределенный NAC, как неизвестное, и, таким образом, считывает coding_type в качестве данных заполнения в соответствии с длиной поля, описанной посредством stream_attributes_length.

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

Кроме того, при генерировании ES_table stream_entry NAC-потока, который был кодирован с этого же аудиоисточника, что и обычно кодированный поток, регистрируется непосредственно после регистрации stream_entry обычно кодированного потока в ES_table. Код языка и количество каналов устанавливаются одинаковыми у NAC-потока и обычно кодированного потока.

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

Блок 3004 производства программ BD программирует программы BD конкретно посредством создания исходного кода программ BD в соответствии с запросом пользователя при помощи пользовательского интерфейса (например, GUI). В данном случае, созданные программы BD представляют собой программы, описанные в первом варианте осуществления, такие как программы BD, которые реализуют функцию установки аудиопотока NAC.

Блок 3005 мультиплексирования мультиплексирует многочисленные потоки, такие как видеопотоки, аудиопотоки, потоки графики представления, потоки интерактивной графики и т.п., описанные в данных сценария BD-ROM, в AVClip в формате MPEG2-TS.

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

Здесь описывается синтаксис stream_code_inf(). Фиг.25 изображает синтаксис stream_code_inf(). Stream_code_inf() генерируется на основе этого синтаксиса. Stream_code_inf() включает в себя: stream_code_info_length, который указывает длину поля stream_code_inf(); coding_type, который указывает тип зарегистрированного элементарного потока; и поля, в которых регистрируется информация атрибутов в соответствии с каждым coding_type.

В данном случае, как и в случае синтаксиса stream_attributes(), если добавляется новый неопределенный NAC, поле будет интерпретироваться как заполнение.

Ссылаясь обратно на фиг.23, блок 3006 обработки формата упорядочивает нижеследующее в формате, согласующемся со стандартом BD-ROM, таким образом генерируя изображение диска в формате UDF, который представляет собой файловую систему, согласующуюся со стандартом BD-ROM: данные сценария BD-ROM, генерируемые блоком 3003 генерирования сценария, файл программ BD, хранящий программы BD, созданные блоком 3004 производства программ BD; и AVClip, файл информации Clip и т.п., сгенерированные блоком 3005 обработки мультиплексированием. Сгенерированное изображение диска преобразуется в данные для штамповки BD-ROM, и BD-ROM могут изготавливаться посредством выполнения обработки штамповкой по этим данным.

Дополнительные замечания

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

(1) Ниже описывается способ уменьшения количества вычислений DRA. DRA представляет собой один из форматов сжатия аудио, над которым Китай работает для его стандартизации, и он собирается ввести его в некоторые продукты, такие как стереофонические наушники и оборудование караоке.

При добавлении DRA к аудиокодеку, такому как AC3 или DTS, уже включенному в стандарты, предпочтительно, чтобы его количество вычислений было снижено до такого количества, которое не более чем в AC3 или DTS.

Ниже конкретно описывается способ определения количества вычислений, необходимого для DRA. Количество вычислений DRA увеличивается с увеличением значения, обозначенного как (Fs × Ch × nCtr). В данном случае, Fs означает частоту дискретизации аудиосигнала, Ch означает количество каналов аудиосигнала, и nCtr означает число исключительной обработки.

Нижеследующее описывает подробности nCtr. Согласно DRA кодирование методом Хаффмана используется в различных областях для сжатия размера данных. Фиг.26 представляет собой пример таблицы, указывающей соответствие между кодированными методом Хаффмана значениями (H) и значениями полей. Как показано на фиг.26, когда целевым полем (Х) сжатия является один из алфавитов A-Z, кодированные методом Хаффмана значения (H) от A до D определяются как 0b, 01b, 0010b и 0011b, соответственно, тогда как алфавиты кроме A-D вместе определяются как 00000b. Другими словами, если поле имеет одно из значений A-D, существует код Хаффмана, соответствующий значению; все другие значения рассматриваются как исключения и определяются как 00000b согласно коду Хаффмана.

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

Фиг.27 изображает процедуру декодирования. Кодированное методом Хаффмана значение (H) декодируется (HuffDec) в соответствии с таблицей на фиг.26, получая значение (этап S701). После этого определяется, является ли значение исключительным значением (другой алфавит) (этап S702). Если определяется, что значение не является исключительным значением (Нет на этапе S702), значение, которое представляет собой значение, полученное в результате декодирования Хаффмана, становится Х, описанным выше (этап S703).

Если оценивается, что значение является исключительным значением (Да на этапе S702), исполняется исключительная обработка (этап S704).

При рассмотрении количества вычислений важно осуществить следующее: когда значения обрабатываются нормальной обработкой, т.е., когда зарегистрированным значением (Х) является одно из A-D, значение Х может быть определено с относительно небольшим объемом обработки в соответствии с таблицей кодов Хаффмана, показанной на фиг.24; однако, когда зарегистрированным значением (Х) является исключительное значение, т.е. другой алфавит (кодированное методом Хаффмана значение равно 00000b), происходит обработка исключения, и, как правило, объем обработки, необходимый для этой обработки исключения, больше объема обработки вышеописанного декодирования Хаффмана. Другими словами, чтобы ограничить количество вычислений в DRA, предпочтительно ограничить количество обработок исключений, указанное как nCtr. Следовательно, предпочтительно, чтобы сохранить количество вычислений DRA менее заданного количества, ограничить значение nCtr не большим, чем заданное значение, или также ввиду увеличения объема обработки в зависимости от числа Ch и частоты дискретизации, ограничить значение (Fs × Ch × nCtr) не большим, чем заданное значение.

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

Фиг.28 изображает зависимость между блоком доступа к видео и блоком доступа к аудио, в случае если две порции AV-данных проигрываются последовательно (плавное проигрывание). На фиг.28 из двух порций плавно соединенных AV-данных TS1 представляет собой первую порцию AV-данных, и TS2 представляет собой вторую порцию AV-данных, плавно проигрываемых непосредственно после первой порции AV-данных, причем блоки доступа, расположенные в очередности отображения видео, т.е. по очередности PTS (временной метки представления). Например, если видео является типа 24P, каждый блок доступа указывает 1/24 секунды. Однако каждый блок доступа к аудио имеет длительность, отличную от длительности видео, и, таким образом, блок доступа пересекает точку соединения видео (точка соединения).

В данном случае, согласно стандартам BD-ROM блоку доступа к аудио в TS1 и блоку доступа к аудио в TS2 разрешено перекрывать друг друга на временной оси в точке соединения (наложение звука).

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

Хотя количество вычислений упомянутого выше DRA вычисляется как (Fs × Ch × nCtr), как описано выше, предпочтительно, чтобы значение nCtr или (Fs × Ch × nCtr) было установлено на значение, которое не больше заданного значения, чтобы избежать увеличения объема обработки в точке соединения. Например, для блоков доступа к аудио в TS1 и TS2, перекрывающих друг друга в точке плавного соединения, nCtr или (Fs × Ch × nCtr) могут ограничиваться половиной значения ограничения nCtr или (Fs × Ch × nCtr) неперекрывающейся части; или сумма значения nCtr или (Fs × Ch × nCtr) перекрывающего блока доступа к аудио в TS1 и значения nCtr или (Fs × Ch × nCtr) перекрывающего блока доступа к аудио в TS2 может ограничиваться заданным значением.

(3) Согласно вышеописанным вариантам осуществления возможность DRA поля, которая указывает, является ли или нет DRA проигрываемым, недавно определена, как возможность NAC, в возможности проигрывателя PSR15 устройства 1000 проигрывания. Однако, не ограничиваясь этим, возможность NAC является допустимой до тех пор, пока она связана с тем, является ли или нет NAC проигрываемым. Например, возможность NAC может определяться для указания, когда имеются 48 кГц и 96 кГц для NAC, является ли каждый из них проигрываемым или нет, поддерживается ли только двухканальное проигрывание или также поддерживается многоканальное проигрывание и т.п.

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

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

Промышленная применимость

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

Список позиций

1 - BD-ROM

10 - привод BD-ROM

20 - буфер считывания

300 - системный целевой декодер

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

302 - блок генерирования ATC

303 - блок генерирования STC

304 - декодер плоскости интерактивной графики

305 - плоскость интерактивной графики

306 - декодер графики представления

307 - плоскость графики представления

308 - видеодекодер

309 - плоскость видео

310 - декодер JPEG

311 - плоскость неподвижного изображения

312 - переключатель

313 - аудиодекодер

40 - блок добавления плоскости

50 - кодер

60 - Ц/А преобразователь

70 - память

80 - блок преобразования PID

90 - набор PSR

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

101 - блок исполнения программ

102 - блок управления проигрыванием

103 - блок исполнения процедур

104 - блок управления ATC/STC

110 - блок приема операции

120 - блок передачи/приема HDMI.