CN1768387B - 记录方法,播放装置及播放方法 - Google Patents

Abstract

BD-ROM包含记录于其中的播放列表、应用程序和BD-J对象，所述播放列表包含AV剪辑和播放列表信息。该应用程序是一种以用于虚拟机的编程语言写成的程序，并且指定了生存周期，在该生存周期期间可以由所述虚拟机执行该应用程序。该BD-J对象包含播放列表管理表。该播放列表管理表指示了在该生存周期期间与该应用程序的执行同时进行的播放列表的播放控制。

Description

记录方法，播放装置及播放方法

技术领域

本发明涉及用于控制虚拟机中应用程序执行的应用程序控制技术的领域，并且更具体地，涉及用于将该控制技术应用于例如BD-ROM的记录介质和BD-ROM播放装置的应用技术，并且其中该BD-ROM用于发行电影作品。

背景技术

用于虚拟机的应用程序控制技术，例如Java(TM)编程，已经在个人计算机软件行业中得到了广泛应用。目前，如何将从个人计算机软件发展而来的Java(注册商标，在下文中用TM表示)编程用于实现BD-ROM(蓝光光盘只读存储器)播放装置中的播放控制是一个研究的热点。

在下面专利文件1中叙述的技术是一种公知的关于一种类似的播放装置的传统技术。

＊专利文件1：日本专利公开No.2813245

发明内容

本发明要解决的问题

同时，Java(TM)编程所创建的应用程序的运行并不稳定，运行状态会根据资源使用状态和CPU负载而改变。因此，经常会发生资源短缺，而这会导致应用程序的启动失败或者导致应用程序异常终止，从导致装置发生中断。在个人计算机软件行业中，人们可能并不将这视为严重问题。但是，在制造例如BD-ROM播放装置这样的消费品的领域中，这种现象将会被视作质量问题。因此，许多制造商都不愿意使用Java(TM)编程来实现装置控制。(注：中断是指这样一种状态，其中，装置中的软件停止工作并且显示屏变为黑屏)

本发明的目的是提供一种记录介质，当控制记录介质的应用程序异常终止时，或者当该应用程序发生启动故障时，所述记录介质可以实现失效保护。

根据本发明的一个方面，提供一种记录方法，用于在记录介质上，其中记录应用程序、数字流、与所述应用程序和数字流有关的标题、以及管理信息，其中所述应用程序是使用编程语言编写的用于虚拟机的程序，

在执行所述记录时指定了生存周期，该生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间可以由所述虚拟机执行所述应用程序，以及

所述管理信息包括指示了与所述标题有关的所述数字流的播放控制的信息，在所述生存周期期间，与所述应用程序的执行同时进行所述数字流的播放控制。

根据本发明的另一个方面，提供一种播放装置，包括：

虚拟机单元，用于执行已经从记录介质读入工作存储器的应用程序；

播放控制引擎单元，用于播放记录于所述记录介质上的、并且与记录在所述记录介质中的标题有关的数字流；以及

应用程序管理器，用于当到达所述应用程序的生存周期时，将所述应用程序从所述记录介质读入所述工作存储器并且使所述虚拟机单元执行所述应用程序，以及同时，使所述播放控制引擎单元根据记录于所述记录介质中的管理信息播放与所述标题有关的所述数字流，其中，所述生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间，所述应用程序可以被读入所述虚拟机单元的工作存储器并且可以被所述虚拟机单元执行。

根据本发明的再一个方面，提供一种用于计算机的播放方法，所述计算机包含虚拟机单元以及播放控制引擎单元，所述虚拟机单元用于执行已被从记录介质读入工作存储器的应用程序，所述播放控制引擎单元用于播放记录于所述记录介质上的、并且与记录在所述记录介质中的标题有关的数字流，所述播放方法使所述计算机执行以下所述步骤：

当到达所述应用程序的生存周期时，将所述应用程序从所述记录介质读入所述工作存储器并且使所述虚拟机单元执行所述应用程序，其中，所述生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间，所述应用程序可以被读入所述虚拟机单元的工作存储器并且可以被所述虚拟机单元执行，并且同时

使所述播放控制引擎单元根据记录于所述记录介质上的管理信息播放与所述标题有关的所述数字流。

根据本发明的再一个方面，提供一种系统集成电路，其被嵌入播放数字流的播放装置，所述数字流记录在所述记录介质中并且与记录在所述记录介质中的标题有关，所述系统集成电路包含：

虚拟机单元，用于执行已被从记录介质读入工作存储器的应用程序；以及

应用程序管理器，用于当到达所述应用程序的生存周期时，将所述应用程序从所述记录介质读入所述工作存储器并且使所述虚拟机单元执行所述应用程序，并且与此同时，使所述播放控制引擎单元根据记录于所述记录介质上的管理信息播放与所述标题有关的所述数字流，其中，所述生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间，所述应用程序可以被读入所述虚拟机单元的工作存储器并且可以被所述虚拟机单元执行。

解决这些问题的方法

通过一种记录介质可以实现上述目的，在该介质中记录有应用程序、数字流、与所述应用程序和数字流有关的标题、以及管理信息，其中所述应用程序是用编程语言编写的用于虚拟机的程序，并且定义了一个生存周期，该生存周期在记录在所述记录介质中的标题的播放周期内，并且在该生存周期内，所述应用程序可以被读入所述虚拟机的工作存储器并且可以被所述虚拟机执行，并且所述管理信息指示了与所述标题有关的所述数字流的播放控制，在所述生存周期期间，与所述应用程序的执行同时执行所述数字流的播放控制。

本发明的作用

根据本发明的记录介质，由于定义了在所述应用程序的生存周期期间与应用程序的执行同时执行的数字流的播放控制，如果发生应用程序的启动故障或者如果该应用程序在执行过程中异常终止，那么同时执行的数字流的播放会继续进行，其提供了一种状态，在该状态中“屏幕上仍然显示某些图像”。通过这种安排，可以避免装置发生中断这种最坏情况。这至少在一定程度上可以使装置的制造商感到放心。

这种放心感可以把对质量问题放心不下的制造商推向通过Java(TM)应用程序的播放装置控制的开发。通过这种强有力的推动作用，播放装置将会变得更便宜并且种类更多，并且BD-ROM的内容也将得到丰富，而这也会引领内容相关行业的增长。

附图简述

图1显示了本发明的播放装置的一种使用形式；

图2显示了用于BD-ROM的文件/目录结构；

图3显示了播放列表信息的构建；

图4显示了AV剪辑时间轴和PL时间轴之间的关系；

图5显示了通过四个Clip_information_file_name实现的批说明；

图6显示了PLMark信息的内部结构；

图7显示了通过PLMarks定义章；

图8显示了子路径信息的内部结构；

图9显示了如何在子播放项时间轴上做出同步说明和播放周期的定义；

图10显示了电影对象的内部结构；

图11显示了BD-J对象的内部结构；

图12A显示了存储于Java(TM)存档文件中的程序和数据；

图12B显示了类文件的内部结构；

图13显示了盘内容中的状态改变；

图14显示了HDMV模式中包含动态脚本的两个标题；

图15显示了BD-J模式(BD-J对象)中包含动态脚本的标题的内部结构；

图16显示了不包含播放列表管理表的一个标题；

图17显示了从HDMV模式中标题到BD-J模式中标题的一个转移；

图18显示了从BD-J模式中标题到HDMV模式中标题的一个转移；

图19显示了index.bdmv的内部结构；

图20A显示了应用程序管理表的内部结构；

图20B显示了应用程序管理表中包含的信息元素的含义；

图21A显示了整个盘的时间轴；

图21B显示了时间轴是如何构建的；

图22A和22B在整个BD-ROM的时间轴上显示了由一个BD-J对象标识的标题播放周期，而该BD-J对象是由标识符“bobj_id”标识的；

图23显示了在图22B中所示时间轴上定义的一种典型的生存周期；

图24显示了包含三个标题的盘内容，所述三个标题为：主标题、在线购物标题以及游戏标题；

图25A和25B显示了应用程序管理表和生存周期的实例；

图26显示了三种运行属性(预发送、自动运行和暂停)以及前一个标题的三种可能的状态(未运行、运行中和暂停)；

图27A显示了播放列表管理表的内部结构；

图27B显示了播放列表管理表中包含的信息元素的含义；

图28显示了转移目的地标题的三种可能的状态((i)不具有播放列表管理表；(ii)具有播放列表管理表和自动播放：以及(iii)具有播放列表管理表和预发送)与前一个标题中PL的两种可能的状态(未播放以及正在播放)的六种组合；

图29A显示了播放列表管理表和应用程序管理表的描述实例；

图29B显示了如何基于图29A中所示播放列表和应用程序管理表，使播放列表被播放和执行应用程序；

图30A显示了播放列表管理表的描述的一个实例；

图30B显示了是如何基于图30A中所示脚本播放播放列表以及执行应用程序；

图31A至31C显示了播放列表时间轴和标题播放周期之间的关系；

图32显示了本发明的播放装置的内部结构；

图33以层结构的方式显示了CPU 24中的硬件和存储于其中的软件；

图34是由呈现引擎31对模块管理器34所执行的处理的说明；

图35显示了应用程序管理器36所执行的处理；

图36显示了用户事件管理器37至缺省操作管理器40；

图37显示了Java(TM)虚拟机39的内部结构；

图38显示了应用程序终止的四种模式；

图39是一个流程图，该图显示了应用程序管理器36的工作步骤；

图40显示了播放列表管理表和应用程序管理表的具体实例；

图41A显示了实施例2中BD-J对象的内部结构；

图41B显示了错误管理表的内部结构；

图42显示了错误管理表中五个标记的含义；

图43A显示了其中写有错误管理表的两个标题(标题#1，标题#2)；

图43B显示了根据图43A所示的应用程序和错误管理表进行的应用程序执行和播放列表播放的进行过程；

图44是一个流程图，该图显示了实施例2中应用程序管理器36的工作步骤；

图45是一个流程图，该图显示了实施例2中应用程序管理器36的工作步骤；

图46是一个流程图，该图显示了由应用程序管理器36执行的通知的工作步骤；

图47是一个流程图，该图显示了实施例3中应用程序管理器36的工作步骤；

图48A显示了基于母级别的选择算法的内容；

图48B显示了基于音频语言的选择算法的内容；

图48C显示了基于对于视频的播放器配置的选择算法的内容；

图49是过程的说明，在该过程中，标题无界应用程序选择PL；

图50是一个流程图，该图显示了由播放控制引擎32执行的PL播放工作步骤；

图51是一个流程图，该图显示了角改变步骤和向回跳读/向下跳读的工作步骤；

图52是一个流程图，该图显示了当判断出调用了向回跳读/向下跳读API时执行的处理步骤；

图53是一个流程图，该图详细显示了呈现引擎31的处理步骤；

图54是一个流程图，该图显示了子播放项的处理步骤。

符号描述

1  BD-ROM驱动器

2  读取缓冲器

3  解复用器

4  视频解码器

5  视频平面

6  P图像解码器

7  呈现图像平面

8  合并单元

9  字体生成器

10 I图像解码器

11 开关

12 互动图像平面

13 合并单元

14 CLUT单元

15 CLUT单元

16 音频解码器

22 用户事件处理单元

23 PSR集合

24 CPU

25 脚本存储器

26 本地存储器

33 HDMV模块

34 模块管理器

35 BD-J模块

36 用程序管理器

37 UO控制器

38 Java(TM)虚拟机

41 PLMT处理器

42 许可控制器

52 用户类加载器

53 方法区域

54 工作存储器

55a，55b，…55n 线程

56a，56b，…56n Java(TM) 堆栈

具体实施方式

实施例1

接下来的内容描述了本发明的记录介质的实施例。首先，将会描述本发明的记录介质的使用形式。在图1中，本发明的记录介质是BD-ROM 100。BD-ROM 100用于向一个家庭影院系统提供内容，其中该家庭影院系统包含播放装置200、遥控器300和电视400。

其中，遥控器300配有一些键，例如播放(Play)、停止(Stop)、暂停开始(Pause On)、暂停结束(Pause Off)、静止结束(Still Off)向前播放(Forward Play，带有速度的说明)、向后播放(Backward Play，带有速度的说明)、音频变换(Audio Change)、字幕变换(SubTitleChange)以及角度变换(Angle Change)，并且这些键用于接收这些功能的指令，还有一些键，例如向上移动(Move Up)、向下移动(MoveDown)向右移动(Move Right)以及向左移动(Move Left)，这些键用于接收在菜单操作期间使焦点发生移动的指令，另外还有弹出键(Pop Up)，用于接收显示菜单的指令，以及用于接收数字输入的数字键。

到现在为止，已经对本发明的记录介质的使用形式进行了描述。

接下来将描述本发明的记录介质的制造。可以通过BD-ROM上文件系统的改进实现本发明的记录介质。图2显示了用于BD-ROM的文件/目录结构。如图中所示，对于BD-ROM，在根目录下提供BDMV目录。

BDMV目录具有扩展名为“bdmv”的文件(“index.bdmv”、“MovieObject.bdmv”、“BD-JObject.bdmv”)。在BDMV目录下，有四个子目录：播放列表(PLAYLIST)目录、CLIPNF目录、流(STREAM)目录以及BDJA目录。该播放列表目录具有扩展名为“mpls”的文件(“00001.mpls”、“00002.mpls”、“00003.mpls”)。

CLIPNF目录具有扩展名为“clpi”的文件(“00001.clpi”、“00002.clpi”、“00003.clpi”)。流目录具有扩展名为“m2ts”的文件(“00001.m2ts”、“00002.m2ts”、“00003.m2ts”)。BDJA目录具有扩展名为“jar”的文件(“00001.jar”、“00002.jar”、“00003.jar”)。通过上面的描述可以知道，该目录结构可以使得在BD-ROM上记录不同类型的文件。

在图2中，扩展名为“m2ts”的文件(“00001.m2ts”、“00002.m2ts”、“00003.m2ts”，…)包含可以分为例如主剪辑和子剪辑的AV剪辑。主剪辑是通过将多个基本流复用到一起而获得的，这些基本流是例如视频流、音频流、构成字幕的呈现图像流(PG流)，以及构成菜单的互动图像流(IG流)。

子剪辑是对应于一种基本流的数字流，其中这些基本流是例如音频流、图像流以及文本字幕流(TextStream)。扩展名为“clpi”的文件(“00001.clpi、“00002.clpi”、“00003.clpi”，…)是与AV剪辑有一一对应关系的管理信息。作为管理信息，剪辑信息具有关于如下方面的信息：AV剪辑中流的编码格式、帧速率、比特率、分辨率等等，以及指示GOP的起始位置的“EP_map”。

扩展名为“mpls”的文件(“00001.mpls”、“00002.mpls”、“00003.mpls”，…)是包含播放列表信息的文件。播放列表信息是通过指出AV剪辑而定义播放列表的信息。图3显示了播放列表信息的构造。如图3的左手侧所示，播放列表信息包含主路径信息、PL Mark信息以及子路径信息。

主路径信息(MainPath())包含多条如虚线箭头“mp1”所指示的播放项信息(PlayItem())。播放项(Play Item)是通过在一个或多个AV剪辑时间轴上指定“In_time”和“Out_time”从而定义的播放周期。将多个播放项信息合并在一起就定义了一个包含多个播放周期的播放列表(PL)。图3中的虚线箭头“mp2”指示了播放项信息的内部结构的局部放大图。如图3中所示，播放项信息包含指示相应的AV剪辑的“Clip_information_file_name”、“In_time”以及“Out_time”。图4显示了AV剪辑和PL之间的关系。该图的第一行指示了AV剪辑的时间轴，并且第二行指示了PL的时间轴。PL信息包含三条播放项信息：“PlayItem#1”、“PlayItem#2”以及“PlayItem#3”。PlayItem#1、PlayItem#2和PlayItem#3的In_time和Out_time定义了三个播放周期。通过安排这三个播放周期，就定义了一个不同于AV剪辑时间轴的时间轴。这个时间轴就是第二行所示的PL时间轴。从中可以明显地看出，可以通过定义播放项信息从而定义一个不同于AV剪辑时间轴的时间轴。

基本地，只指定了一个AV剪辑。但是，可以由一个批说明来指定多个AV剪辑。通过播放项信息中的多个Clip_information_file_name获得该批说明。图5显示了通过四个Clip_information_file_name获得的批说明。在图5中，第一行到第四行指示了四个AV剪辑时间轴(AV剪辑#1、#2、#3和#4的时间轴)，并且第五行指示了一个PL时间轴。由包含在播放项信息中的四个Clip_information_file_name指定这四个时间轴。通过这样一种构造，由包含在播放项中的In_time和Out_time定义了这四个播放周期，并且可以有选择性地播放这四个周期。这使得可以通过PL时间轴定义这样一个周期(所谓的多角度周期)，其中可以提供多个可变换角度的图像。

PLMark信息(PLMark())是将PL时间轴上一段给定周期指定为一个章节的信息。图6显示了PLMark信息的内部结构。如图中虚线“pm1”所指示的，PLMark信息包含“ref_to_PlayItem_Id”和“Mark_time_stamp”。图7显示了通过PLMark定义章节。在图7中，第一行指示一个AV剪辑时间轴，并且第二行指示一个PL时间轴。在图7中，箭头“pk1”和“pk2”分别指示PLMark中一个播放项的说明(ref_to_PlayItem_Id)和一个时间点的说明(Mark_time_stamp)。通过这些说明，在PL时间轴上定义了三个章节。到目前为止，已经解释了PLMark。接下来将解释子路径信息。

子路径信息(SubPath())是通过指定子剪辑时间轴上的In_Time和Out_Time从而定义一个或多个播放周期的信息。图8显示了内部结构。如图8中的虚线“sh1”所指示的，子路径信息包含多个子播放项信息(SubPlayItem())。如虚线“sh2”所指示的，子播放项信息包含“Clip_information_file_name”、“In_time”、“Out_time”、“Sync_PlayItem_Id”以及“Sync_start_Pts_of_PlayItem”。由Clip_information_file_name”、“In_time”和Out_time”指定子剪辑时间轴上的In_time和Out_time。“Sync_PlayItem_Id”和“Sync_start_Pts_of_PlayItem”用于同步说明以将子剪辑时间轴上的播放周期与PL时间轴同步。通过该同步说明，子剪辑时间轴和PL时间轴同步进行。

图9显示了如何做出同步说明和在子播放项(Sub Play Item)时间轴上定义一个播放周期。在图9中，第一行指示了PL时间轴，并且第二行指示了子播放项时间轴。在图9中，SubPlayItem.In_time和SubPlayItem.Out_time分别指示了播放周期的开始点和结束点。由此可以理解，播放周期也是被定义在子剪辑时间轴上。对应于箭头Sn1的Sync_PlayItem_Id指示播放项的同步说明，并且对应于箭头sn2的Sync_start_Pts_of_PlayItem指示PL时间轴上播放项中一个时间点的说明。

BD-ROM上的播放列表信息的特征在于它可以定义一个多角度周期和一个同步周期，其中在该多角度周期内可以在多个AV剪辑之间切换，并且在该同步周期内AV剪辑可以与子剪辑之间同步。上述的剪辑信息和播放列表信息可以归类为“静态脚本”。这是因为剪辑信息和播放列表信息定义了一个PL，而该PL是一个静态播放单元。上述是对静态脚本的描述。

接下来描述“动态脚本”。动态脚本是一种动态地定义AV剪辑的播放控制的脚本数据。这里，“动态地”意味着播放控制可以根据播放装置的状态变换或用户通过键盘输入的事件进行变换。BD-ROM假定了两种模式作为播放控制的操作环境。第一种模式是一种类似于DVD播放装置的操作环境的操作环境，并且是一种基于命令的执行环境。第二种模式是一种Java(TM)虚拟机的操作环境。在这两种操作环境中，第一种操作环境称作HDMV模式，第二种操作环境称作BD-J模式。由于这两种工作环境的存在，所以通过假定两种操作环境中的任意一种写动态脚本。假设HDMV模式的动态脚本称作电影对象，并且由管理信息对其进行定义。另一方面，假定BD-J模式的动态脚本称作BD-J对象。

首先将解释电影对象。

<电影对象>

电影对象存储在文件“Movie Object.bdmv”中。图10显示了Movie Object.bdmv的内部结构。如图10的最左侧部分所示，MovieObject.bdmv包含指示编码序列“MOBJ”的“type_indicator”、“version_number”以及一个或多个电影对象“Movie Objects()”。图10中的虚线vh1指示了电影对象的内部结构的局部放大图。“MovieObjects()”包含指示其自身数据长度的“length”、指示其中所含电影对象的数量的“number_of_mobjs”，以及其数量由number_of_mobjs指示的多个电影对象。由标识符mobj_id标识电影对象，而这些电影对象的数量由number_of_mobjs指示。图10中的虚线vh2指示了由标识符mobj_id标识的一个给定Movie Object[mobj_id]的内部结构的局部放大图。

如虚线所指示的，电影对象包含：“resume_intention_flag”，它指示在执行一次菜单调用之后是否继续播放；“menu_call_mask”，它是指示是否应该屏蔽菜单调用的信息；“Title_search_flag”，它指示是否应该屏蔽标题搜索功能；“number_of_navigation_command”，它指示导航命令的数量；以及其数量由“number_of_navigation_command”指示的多个导航命令。

导航命令序列包含实现以下功能的命令：条件转移；设置播放装置中的状态寄存器；获得该状态寄存器中设置的值等等。以下是可以写入电影对象的命令。

PlayPL命令

格式：PlayPL(第一变量，第二变量)

作为第一变量的播放列表号可以用于指示一个将被播放的PL。包含在PL中的播放项、PL中的给定时间、一个章节或者一个掩码，作为第二变量可以用于指示播放起始位置。

使用播放项在PL时间轴上指定播放起始位置的PlayPL函数被称作PlayPLatPlayItem()。

使用一个章节在PL时间轴上指定播放起始位置的PlayPL函数被称作PlayPLatChapter()。

使用时间信息在PL时间轴上指定播放起始位置的PlayPL函数被称作PlayPLatPlayItem()。

JMP命令

格式：JMP变量

JMP命令用于这样一个转移：该转移丢弃当前正在执行的动态脚本而执行一个由该变量指定的转移目的动态脚本。JMP命令有两种类型：直接地指定转移目的动态脚本的直接指向类型；以及间接地指向转移目的动态脚本的间接指向类型。

电影对象中导航命令的描述格式类似于DVD中的导航命令的描述格式。因此，可以有效地实现将盘内容从DVD上转移到BD-ROM上。电影对象是一种在以下的国际出版物中公开的现有技术。详细内容可以参考国际出版物。

国际公开WO 2004/074976。

到目前为止，已经对电影对象进行了描述。接下来将描述BD-J对象。

<BD-J对象>

BD-J对象是在Java(TM)编程环境中写出的BD-J模式中的一种动态脚本。

图11显示了BD-J Object.bdmv的内部结构。如图11的最左侧所示，BD-J Object.bdmv包含指示码序列“BOBJ”的“type_indicater”，“version_number”以及一个或多个BD-J对象“BD-J Object()”。图11中的虚线“bh1”指示了BD-J Object()的内部结构的局部放大图。“BD-J Object()”包含指示其自身数据长度的“length”、指示其中所包含BD-J对象的数量的“number_of_bobjs”，以及数量由number_of_bobjs所指示的多个BD-J对象。通过标识符bobj_id标识数量由number_of_bobjs所指示的多个BD-J对象。图11中的虚线bh2指示了由标识符bobj_id标识的一个给定BD-J Object[bob_id]()的内部结构的局部放大图。

如带有虚线指示的图中所示，BD-J对象包含“resume_intention_flag[bobj_id]”、“menu_call_mask[bobj_id]”、“Title_search_flag[bobj_id]”、“Application_Management_Table[bobj_id]”以及“Playlist_Management_Table[bobj_id]”。BD-J对象也包含“resume_intention_flag”、“menu_call_mask”以及“Title_search_flag”，在这点上BD-J对象大致上与电影对象相同。

BD-J对象与电影对象之间的区别在于，在BD-J对象中命令不被直接写。也就是说，在电影对象中，控制过程是直接写入导航命令中。与此不同地是，BD-J对象通过允许Java(TM)应用程序的说明被写入“Application_Management_Table[bobj_id]”从而间接地定义了控制过程。通过这样一种间接定义提供了对公用控制过程的有效共享，并且使得多个动态脚本可以共享一个公用控制过程。

另外，在电影对象中，根据写入在电影对象中的用于命令执行PL播放的导航命令(PlayPl命令)执行PL播放。与此不同地是，在BD-J对象中，通过将指示PL播放过程的“Application_Management_Table[bobj_id]”包含到BD-J对象中从而使得PL播放过程被写入。而且，还可以通过将PL过程包含到从应用程序管理表指出的一个应用程序中，从而写入PL播放过程。也就是说，既可以通过将播放列表播放过程写入到播放列表管理表中，也可以通过将其写入到应用程序中从而将该播放列表播放过程包含进来。

这里，将对Java(TM)应用程序进行描述。Java(TM)应用程序包含一个或多个加载到虚拟机的堆区域(也称作工作存储器)中的xlet程序。Java(TM)应用程序包含多个xlet程序和数据。到目前为止，已经对Java(TM)应用程序的构造进行了描述。

Java(TM)应用程序的重要主体是存储在如图2中所示的BDMV目录下的BDJA目录中的Java(TM)存档文件(00001.jar、00002.jar)。接下来将参考图12A和12B描述Java(TM)存档文件。

<Java(TM)存档文件>

每个Java(TM)存档文件(图2中所示的00001.jar、00002.jar)都是通过将一个或多个类文件和一个或多个数据文件合并在一起而形成的。图12A显示了存储在存档文件中的程序和数据。通过将多个文件安排到椭圆框所指示的目录结构中，由Java(TM)存档器对图12A中所示的数据进行了配置。该椭圆框所指示的目录结构包含根、Java(TM)以及图像目录。common.pkg安排在根目录下，类文件(aaa.class、bbb.class)安排在Java(TM)目录下，并且menu.jpg安排在图像目录下。Java(TM)存档器通过将上述这些文件合成为一个而形成每个Java(TM)存档文件。当从BD-ROM中读出这样的类文件和数据时，会对它们进行扩充并且将它们视作安排在目录中的文件。每个Java(TM)存档文件名字中的五位数字“zzzzz”指示了应用程序ID。当将这样一个Java(TM)存档文件被读取到高速缓存中时，可以通过参考附带到文件名字上的数字来提取出任意一个Java(TM)应用程序所包含的程序和数据。这些类文件(图12A中所示的aaa.class、bbb.class)是对应于上述xlet程序的类文件。对应于类文件的实例的xlet程序定义了BD-J模式中的播放过程。

xlet程序是这样一种Java(TM)程序：它可以使用符合Java(TM)媒体框架(JMF)的接口，并且可以根据例如JMF的格式，执行响应于键盘事件的处理。因为xlet程序可以执行JMF格式的处理，所以它可以通过生成对应于一个MPLS文件的实例(JMF播放器实例)，从而命令播放装置播放一个播放列表。另外，xlet程序可以通过写入对功能API的调用从而命令BD-ROM播放装置执行对于BD-ROM播放装置来说是唯一的处理。

此外，xlet程序可以执行用于访问一个WWW网站并且从该网站上下载内容的步骤。这使得可以播放一些原创作品，其中这些作品是通过将所下载的内容与播放列表播放结合到一起从而生成的。

接下来将描述xlet程序的类文件。图12B显示了类文件的内部结构。如图12B中所示，类文件包含“常数池”、“接口”以及“方法1、2、3…n”。类文件中的方法可以分为以下几种：一种方法(事件听者方法)，通过该方法可以预先记录触发一种操作的键盘事件；用于命令JMF播放步骤的方法(JMF播放器实例的方法)；以及调用BD-ROM播放装置的功能API的方法。在这些方法中，使用分配给他们自己的局部变量或者用于调用他们自己的参数，写入这些用于计算等的步骤。到目前为止，已经对Java(TM)存档文件进行了描述。应该注意到，尽管在本实施例中，应用程序所包含的程序和数据存储于Java(TM)存档文件中，但是这些程序和数据也可以存储于LZH文件或zip文件中。

到目前为止，已经对BD-J模式中的动态脚本进行了描述。

<BD-ROM中的状态改变>

只读盘中提供的盘内容，例如DVD视频，具有一种以顶级菜单为中心的结构。这样一种盘内容中的状态改变是唯一的，这是因为播放从顶级菜单标题转移到每个标题并且随后返回到顶级菜单标题。图13显示了盘内容的状态改变。图13中的方框代表了标题。这里，每个标题是对应于状态改变中一个“状态”的播放单元，并且该“状态”对于盘内容来说是唯一的。标题可以分为以下几类：加载BD-ROM后首先播放的“FirstPlayTitle”(首先播放标题)、组成顶级菜单的“Top_menuTitle”(顶级菜单标题)以及通用标题“Title”。图13中的箭头jh1、jh2、jh3、jh4、jh5、jh6、jh7以及jh8象征性地指示了标题之间的转移。根据图13中所示的状态改变，在加载BD-ROM后马山播放“FirstPlayTitle”，然后出现跳转到“Top_menuTitle”的转移，并且然后等待顶级菜单上的选择。在用于发行电影的记录介质(例如BD-ROM)的行业中，经常一加载这样一种记录介质就播放动态商标。该动态商标象征着电影的制片商或发行人。“FirstPlayTitle”的作用就在于在加载BD-ROM之后立即播放动态商标。

然后，如果用户选择了菜单上的一个标题，那么就播放所选择的标题。然后播放返回到顶级菜单标题。反复执行这样一种播放步骤，直到弹出该BD-ROM。这是只有该盘内容才有的状态改变。

具有这种状态改变的标题包含HDMV模式中的动态脚本或BD-J模式中的动态脚本。图14显示了包含HDMV模式中的动态脚本的两个标题。图14的第一行指示了一个由标识符“Title_id”标识的标题(Title_id)。第二行指示了一个电影对象(Movie Object)序列，其包含一个或多个构成标题的电影对象。第三行指示了电影对象所包含的导航命令序列。

图13中所示的从一个标题到另一个标题的转移是通过预先在一个电影对象中写入一个导航命令(JumpTitle命令)而实现的，该导航命令指示播放装置跳转到另一个标题。另外，图14的第四行指示了属于该标题的播放列表。该播放列表与该标题之间的这种从属关系是通过预先在一个电影对象中写入一个导航命令(PlayPL命令)而实现的，该导航命令指示播放该播放列表。

通过使一个播放列表属于一个标题，对于HDMV模式中的标题，可以定义一个伴随有一个视频播放的电影。这就是由HDMV模式中动态脚本所定义的标题的结构。

接下来将描述包含BD-J模式中动态脚本的标题的内部构造。图15显示了包含BD-J模式中动态脚本(BD-J对象)的标题的内部构造。

第一行指示了一个由标识符“Title_id”标识的标题。第二行指示了组成该标题的唯一BD-J对象。第三行指示了BD-J对象中提供的应用程序管理表和播放列表管理表。第四行指示了一个由第三行中应用程序管理表操作的应用程序。该应用程序包含一种命令播放装置跳转到另一个标题的方法(一种调用JumpTitle API的方法)，如第五行所指示的那样。因此，如图13中所示的跳转到另一个标题的转移是通过JumpTitleAPI调用方法而实现的。另一方面，因为在第三行中写入播放列表管理表，所以在执行该应用程序的同时播放一个播放列表，如第四行中所指示的那样。

该BD-J对象包含应用程序管理表和播放列表管理表。这使得可以在执行应用程序的同时执行PL播放，如第四行中所指示的那样。这种应用程序和PL播放的同时执行是BD-J模式中标题的一个特点。

并不是所有的BD-J对象都包含播放列表管理表。播放列表管理表是一种任意的成分。一些BD-J对象包含播放列表管理表，而其它BD-J对象不包含。图16显示了并不包含播放列表管理表的标题。在这样一个仅包含应用程序管理表但不包含播放列表管理表的BD-J对象中，仅定义了应用程序操作，如第四行中所指示的那样。通过这样一种应用程序操作的定义，就定义了一种标题，其中这种标题仅有控制步骤而并不伴随有PL播放。

图14显示了从HDMV模式中一个标题转移到HDMV模式中一个标题。但是应该注意到，如图17中所示，也可以实现从HDMV模式中一个标题转移到BD-J模式中一个标题。类似地，尽管图15显示了从BD-J模式中一个标题转移到BD-J模式中一个标题，也可以实现从BD-J模式中一个标题转移到HDMV模式中一个标题，如图18中所示。

在上述的标题的内部结构中，由图2中所示的index.bdmv定义标题所包含的电影对象或BD-J对象。接下来将描述index.bdmv。

index.bdmv是指示标题所包含的电影对象或BD-J对象的一个表。

图19显示了index.bdmv的内部结构。如图19中所示，index.bdmv包含具有值“INDX”的“type_indicator”、“version_number”、指示从文件起始位置到索引的相对地址的“Indexes_start_address”以及“Indexes()”。“Indexes()”分别对应于不同的标题。如图19中虚线箭头“ix1”所示，“Indexes()”包含“length”、“FirstPlayback(){FirstPlayback_mobj_id_ref}”、“TopMenu(){TopMenu_mobj_id_ref}”、“number_of_Titles”以及“Title[0]()…Title[number_of_Titles-1]()”。

“FirstPlayback(){FirstPlayback_mobj_id_ref}”是FirstPlayTitle的索引，并且存储该FirstPlayTitle所包含的电影对象的电影对象标识符参照值(FirstPlayback_mobj_id_ref)。“TopMenu(){TopMenu_mobj_id_ref}”是TopMenuTitle的索引，并且存储该TopMenuTitle所包含的电影对象的电影对象标识符参照值(TopMenu_mobj_id_ref)。

“Title[0]()…Title[number_of_Titles-1]()”是除FirstPlayTitle和TopMenuTitle之外的标题的索引，并且它们的数量为number_of_Title。“Title[0]()…Title[number_of_Titles-1]()”由标识符Title_id标识。

由标识符Title_id标识的索引表示为Title[Title_id]()。图19中的虚线ix2指示了Title[Title_id]()的局部放大图。

如图19中所示，“Title[Title_id]()”包含：“Title_Playback_Type[Title_id]”，它指示了标题播放类型，它是通过例如该“Title[Title_id]()”是否包含一个转移来示出的；“Title_access_Flag[Title_id]”，它指示了是否允许执行标题的服务函数；以及唯一地指示了该标题所包含的电影对象的“Title_mobj_id_ref[Title_id]”。这里，如果标题所包含的动态脚本是BD-J对象，那么由“Title_bobj_id_ref[Title_id]”代替“Title_mobj_id_ref[Title_id]”。“Title_bobj_id_ref[Title_id]”唯一地指示了该标题所包含的BD-J对象。

下面的国际公开对Index.bdmv进行了详细公开。详细内容请参考国际公开。

国际公开WO 2004/025651 A1。

<应用程序管理表>

包含在BD-J对象表中的应用程序管理表和播放列表管理表是本实施例的主要元素。接下来将对这些表进行详细描述。首先，将要描述应用程序管理表(AMT)。

图20A显示了应用程序管理表的内部结构。如图20A中所示，应用程序管理表包含“life_cycle”、“apli_id_ref”、“run_attribute”以及“run_priority”。

图20B显示了应用程序管理表所包含的信息元素的含义。

“life_cycle”指示了应用程序的“生存周期”。

“apli_id_ref”通过与“应用程序标识符”一致写入到其中的参照值指示了具有上述生存周期的应用程序。该应用程序标识符由Java(TM)存档文件中提供的作为文件名的五位数字值“zzzzz”表示，。该五位数字值被写入“apli_id_ref”中。

“run_attribute”指示了应用程序在生存周期内的运行属性。这些运行属性可以分为以下几类：自动运行、预发送以及暂停。

“run_priority”指示应用程序在生存周期内的“运行优先级”。BD-J对象使用这些信息控制应用程序的运行。

<生存周期>

接下来将描述应用程序管理中所定义的生存周期。

生存周期意味着这样一个周期：在该周期内，应用程序存活于虚拟机的工作存储器上，并且用BD-ROM的全部内容的时间轴代表该周期。这里，名词“存活”指这样一种状态：其中已经将应用层程序所包含的xlet程序加载到工作存储器中，从而可以由虚拟机执行该应用程序。

当在Java(TM)虚拟机上运行应用程序时，有一点很重要，那就是在时间轴上清楚地定义由应用程序提供的服务的起点和终点。应用程序管理表的“life_cycle”中定义了服务的这些起点和终点。

下面的内容显示了是如何对如图13所示改变状态的盘内容定义标题的生存周期。假设在加载BD-ROM之后，以图13中箭头jh1、jh2、jh3、jh4…所指示的数字的上升的顺序进行转移，并且弹出了BD-ROM。可以将以加载为开始到以BD-ROM弹出为结束的连续时间段视作一个时间轴。将该时间轴定义为整个盘的时间轴。图21A显示了整个盘的时间轴。图21B显示了该时间轴是如何构建的。如图21B中所示，整个盘的时间轴包含：播放FirstPlayTitle的周期；播放TopMenuTitle的周期；播放Title#1的周期……一个标题包含一个或多个电影对象或一个BD-J对象。因此，可以将每个标题的播放周期定义为这样一个周期，期间激活了电影对象或BD-J对象中的任意一个对象的周期。

也就是说，FirstPlayTitle、TopMenuTitle以及其它标题中的每一个都包含动态脚本。因此，可以将每个标题的播放周期定义为这样一个周期，期间可以将标题所包含的电影对象或BD-J对象中的任意一个对象激活为当前电影对象或当前BD-J对象，并且可以在播放装置中对该对象进行解码并执行。图22A在整个BD-ROM的时间轴上显示了由BD-J对象标识的标题播放周期，该BD-J对象由标识符“bobj_id”标识。这里，如果一个标题包含由标识符“bobj_id”标识的BD-J对象，那么可以将BD-ROM时间轴上的激活了由标识符“bobj_id”标识的BD-J对象的周期视作标题的播放周期。

类似地，如果一个标题包含由标识符“mobj_id”标识的电影对象，那么可以将BD-ROM时间轴上的激活了由标识符“mobj_id”标识的电影对象的周期视作标题的播放周期。

激活了电影对象或BD-J对象的周期一直持续到执行标题转移(JumpTitle)。也就是说，一直将动态脚本视作当前电影对象或当前BD-J对象，直到执行了一个标题转移(JumpTitle)，其中该动态脚本是执行的目标。因此，将一直持续到电影对象或BD-J对象中发生JumpTitle的周期视作标题播放周期。

接下来将描述标题播放周期和PL时间轴之间的关系。如前面所述，在电影对象或BD-J对象中，可以将PL播放步骤写为处理步骤。如果已经写入了PL播放步骤，那么上述PL时间轴的全部或部分属于标题播放周期。假设在图22A所示的例子中的BD-J对象中写入了一个播放列表管理表。那么，如图22B中所示，PL时间轴属于对应于BD-J对象的标题播放周期。因为可以进一步在PL时间轴上定义多个章(章#1、#2、#3)，所以BD-ROM时间轴上存在有域(全部BD-ROM-Title-PL-Chapter)。可以使用这些域从而写入应用程序的生存周期。这里应该注意到，因为播放列表播放与应用程序的执行同时开始，所以标题转移可能发生在播放列表的播放过程中。在这种情况下，仅部分播放列表时间轴而不是整个播放列表时间轴属于一个标题播放周期。也就是说，究竟是仅部分播放列表时间轴还是整个播放列表时间轴属于一个标题播放周期取决于标题转移发生的时间。

图23显示了在图22B中所示时间轴上定义的一种典型的生存周期。如图23中所示，有三种典型应用程序：标题边界应用程序，它的生存周期是一个标题；章节边界应用程序，它的生存周期是标题内的一个章节；以及无边界应用程序，它的生存周期是整个BD-ROM的时间轴。

在这三种应用程序中，可以使用标题的标识符定义标题边界应用程序的生存周期。另外，可以使用下述两种标识符的组合定义章节边界应用程序的生存周期：该章节所属于的标题的标识符和该章节的标识符。

即使平台正在运行，还是可以在被定义为标题或章节的生存周期结束之后从应用程序重新获得资源。这样一种构建确保了可以重新获得资源，并且由此稳定了平台的运行。

接下来将通过一个具体的例子描述如何将生存周期写入到应用程序管理表中，其中该例子包含将在以后实现的用作材料的盘内容作为材料。用作材料的盘内容包含三种不同类型的标题：主图像作品所包含的主标题(标题#1)；在线购物所包含的在线购物标题(标题#2)；以及游戏应用程序所包含的游戏标题(标题#3)。图24显示了包含三种标题的盘内容：主标题、在线购物标题以及游戏标题。图24的左手侧显示了Index.bdmv，并且图24的右手侧显示了这三个标题。

图24的右手侧的虚线框显示了指示每个应用程序所述标题的从属关系。在这三个标题中，标题#1包含应用程序#1、应用程序#2以及应用程序#3。另外，标题#2包含应用程序#3和应用程序#4，并且标题#3包含应用程序#5。在图24所示的例子中，由标题#1和标题#2都运行应用程序#3。

图25A显示了每个应用程序的生存周期，而这些生存周期都是基于图24的虚线框所示的从属关系而得到的。在图25A中，水平轴指示标题播放周期，而垂直轴方向安排应用程序的生存周期。这里，应用程序#1和应用程序#2仅属于标题#1，并且因此这些应用程序的生存周期限制在标题#1内。应用程序#4仅属于标题#2，并且因此该应用程序的生存周期限制在标题#2内。应用程序#5仅属于标题#3，并且因此该应用程序的生存周期限制在标题#3内。应用程序#3属于标题#1和标题#2，因此该应用程序的生存周期延伸在标题#1和标题#2上。图25B显示了标题#1、标题#2和标题3的应用程序管理表，其中这些表是根据图25A中所示生存周期而写入的。按照这种方式写入应用程序管理表之后，当启动标题#1的播放时将应用程序#1、应用程序#2以及应用程序#3加载到工作存储器中。然后，当启动标题#2的播放时，将应用程序#1和应用程序#2从工作寄存器中删除，这会导致仅有应用程序#3保留在工作寄存器中。类似地，可以进行控制从而当启动标题#2的播放时将应用程序#4加载到工作寄存器中，并且当启动标题#3的播放时，将应用程序#3和应用程序#4从工作寄存器中删除。

进一步，可以进行控制从而当播放标题#3时将应用程序#5加载到工作寄存器中，并且当标题#3的播放终止时，将应用程序#5从工作寄存器中删除。

通过这种构造，可以使得将应用程序加载到工作存储器中的次数最小化。这是因为如果在标题之间发生一个转移，那么同时位于转移源和转移目的地中的应用程序会存储于工作存储器中，而且不位于转移源而仅位于转移目的地中的应用程序也会加载到工作存储器中。这样一种降低加载数据次数的构造使得可以实现无边界应用程序，这种应用程序使得人们并不会意识到标题之间的边界。

接下来将描述应用程序的运行属性。这些运行属性包含：自动运行，它指示具有这种属性的应用程序会自动地开始运行；预发送，它指示具有这种属性的应用程序不是自动运行的目标但是可以存储于虚拟机的工作存储器中；以及暂停，它指示具有这种属性的应用程序存储于虚拟机的工作存储器中但是并未分配给该应用程序CPU功率。

当一个对应的标题发生转移时，具有“自动运行”属性的应用程序被加载到工作存储器中并且被执行。当一个标题转移到另一个标题时，管理应用程序的管理体(应用程序管理器)将一个应用程序加载到虚拟机的工作存储器中并且执行该应用程序，其中该应用程序存活于转移目的地标题中并且已经将它的运行属性设置为自动运行。这意味着当标题发生转移时该应用程序自动地启动运行。

运行属性“预发送”是一种连续属性，并且指示转移源标题中应用程序的状态被保持。这还是一种指示了可以执行一个对应的应用程序的属性。可以从另一个应用程序调用运行属性被设置为“预发送”的应用程序。当从另一个正在运行的应用程序中调用一个程序时，管理体(应用程序管理器)判断该应用程序的应用程序ID是否已经写入到应用程序管理表并且是否该应用程序的运行属性被设置为“预发送”。如果该应用程序的运行属性被设置为“预发送”，那么管理体将该应用程序加载到工作存储器中。如果调用目的地应用程序的应用程序ID未写入到应用程序管理表中，那么管理体并不将该应用程序加载到工作存储器中。只有那些属性设置为“预发送”的应用程序才可以被从另一个程序中调用。“预发送”是一种缺省的运行属性，当没有明确指明运行属性时就指派给应用程序这种属性。因此，当应用程序的运行属性为指示没有说明的“—”时，这就意味着应用程序的运行属性为“预发送”。

“暂停”指示了给具有这种属性的应用程序分配了资源但是未给它分配CPU功率。属性“暂停”是有效的，例如在以下方面：当执行一个游戏标题时，实现通过一条便道的处理。

图26显示了这三种运行属性(预发送、自动运行和暂停)和前一个标题的三种可能的状态(未运行、运行中以及暂停)之间的组合。如果前一个状态是“未运行”并且运行属性是“自动运行”，那么应用程序在转移目的地标题中启动。

如果前一个状态是“未运行”并且运行属性是“预发送”或“暂停”，那么不进行操作并且保持该状态。

如果前一个状态是“运行中”并且运行属性是“预发送”或“自动运行”，那么不进行操作并且保持该状态。

如果将运行属性设置为“暂停”，那么该应用程序的状态是暂停。如果前一个状态是“暂停”并且转移目的地标题的运行属性是“暂停”，那么就保持“暂停”。如果前一个状态是“暂停”并且转移目的地标题的运行属性是“预发送”或“自动运行”，那么在转移目的地标题中再继续该应用程序。在应用程序管理表中定义生存周期和运行属性使得可以执行同步控制以在标题播放周期期间运行Java(TM)应用程序。这使得可以实现和提供各种用于播放图像和执行程序的应用程序。

应该注意到，如果前一个状态是“暂停”并且转移目的地标题的运行属性是“预发送”，那么前一个状态“暂停”可以被保持。

最后，将描述每个应用程序的“运行优先级”。

运行优先级的值为0到255。当存储器资源变得短缺或当CPU负载较高时，应用程序管理器可以使用运行优先级来决定强制终止哪个应用程序，或者决定哪个应用程序重新获得资源。应用程序管理器终止具有低级别运行优先级的应用程序，而保持具有高级别运行优先级的应用程序的运行。

还可以将运行优先级用于对由于请求正在播放的一个PL从而彼此发生冲突的应用程序进行仲裁。这里假设一个应用程序正在对一个播放列表进行快进操作，而另一个应用程序向该播放列表发出了暂停请求。那么，对分配给这两个应用程序的运行优先级的级别进行比较。如果快进应用程序具有较高运行优先级级别，那么就继续进行该快进操作。如果暂停请求应用程序具有较高运行优先级级别，那么正在快进的PL就会被暂停。

使用上述的生存周期、运行属性以及运行优先级，可以在编写程序时将可以在虚拟机上运行的应用程序的数量限制为预定的数量或更少。这使得应用程序可以稳定地工作。

<播放列表管理表>

到目前为止，已经描述了应用程序管理表。接下来将描述播放列表管理表。播放列表管理表显示了应该在应用程序的生存周期期间与每个应用程序的执行同时进行的播放控制。应用程序的运行是不稳定的。可能会发生启动故障或异常终止。在本实施例中，为每个应用程序生存周期都提供了一个播放列表管理表并将其作为发生启动故障或异常终止时发挥作用的失效保护机制。播放列表管理表是一种信息，它定义了当一个应用程序生存周期开始时应该执行的播放控制。这里所描述的播放控制是一种基于播放列表信息的AV剪辑的播放。也就是说，通过执行基于播放列表信息的播放控制，可以同时进行应用程序的执行和播放列表的播放。在前面我们曾经说过，为每个应用程序的生存周期都提供了一个播放列表管理表。但是，这里应该注意到，播放列表管理表仅与标题边界应用程序一致地被提供。这是因为标题无边界应用程序的生存周期延伸到所有标题，所以在标题无边界应用程序中无法控制同时进行应用程序的执行和播放列表的播放。

对于章节边界应用程序来说，并不需要定义播放列表的播放。这是因为定义章节边界应用程序的生存周期是以该应用程序的执行是从播放列表内一个章节开始为前提的。通过上述内容我们可以理解，与包含一个或多个标题的生存周期一致地定义播放列表管理表。

图27A显示了播放列表管理表的内部结构。如图27A中所示，播放列表管理表包含“PL_id_ref”和“Playback_Attribute”。

图27B显示了播放列表管理表所包含的信息元素的含义。

“PL_id_ref”通过与PL标识符一致地写入到其中的参照值指示了在应用程序生存周期期间可以被播放的PL。该PL标识符由一个在文件YYYYY.MPLS中提供的作为文件名的五位数字值“YYYYY”所表示。其中写入了YYYYY的“PL_id_ref”指示了可以在一个对应的标题中播放的PL。

“Playback_Attribute”是类似于应用程序管理表中运行属性的一种属性，并且它定义了当标题启动时如何播放“PL_id_ref”中写入的PL。PL的播放属性可以分为以下几类：“自动播放”、“预发送”等等。

“自动播放”是这样一种属性：它指示当对应的标题发生转移时，播放具有“自动播放”属性的播放列表。当一个标题转移到另一个标题时，管理应用程序的管理体(应用程序管理器)开始播放这样一种播放列表：可以在转移目的地标题中播放该播放列表并且该播放列表的播放属性已经设置为自动播放。这意味着当标题发生转移时其播放属性被设置为自动播放的播放列表会自动地被激活。

与运行属性“预发送”的情况一样，“预发送”也是一种连续属性，并且指示转移源标题中PL的状态被保持。“预发送”还是一种指示可以播放一个对应的播放列表的属性。例如，假设将要连续播放两个标题，并且转移源标题的播放列表管理表中一个播放列表的播放属性设置为自动播放，并且在转移目的地标题的播放列表管理表中，该播放列表的播放属性被设置为预发送。这里，假设可以播放该播放列表两个小时，并且该播放列表播放一小时之后发生转移。在这种情况下，其中播放列表的播放属性在转移目的地标题中被设置为预发送，转移目的地标题对该播放列表的播放是从紧接着已经播放一小时部分之后的位置开始的。由此我们可以理解，即使在标题之间发生转移，通过将转移目的地标题中一个播放列表的播放属性设置为预发送，就可以在转移目的地标题中继续播放该播放列表。这使得多个转移标题可以连续地播放一个公用的播放列表，从而使得可以容易地实现“在多个标题中播放的公用播放列表”。当存在多个转移目的地标题时，通过将这些转移目的地标题中播放列表的播放属性设置为预发送，就可以在这些转移目的地标题中继续播放一个公用的播放列表。

这里应该注意到，因为不需要确保在标题的边界处实现无缝播放，所以对于上述在多个标题中播放一个公用播放列表这种情况，允许在转移附近打断播放列表的播放。

另外，当另一个应用程序发出请求时，其播放属性设置为“预发送”的一个播放列表可以被马上播放。当播放请求是从另一个正在运行的应用程序发出时，管理体(应用程序管理器)判断目标播放列表的PL_id_ref是否已经写入到播放列表管理表并且是否该播放列表的播放属性被设置为“自动播放”或“预发送”。如果被设置为“自动播放”或“预发送”，那么管理体将播放该播放列表。如果播放列表的PL_id_ref未写入到播放列表管理表，那么管理体就不播放该播放列表。当另一个应用程序发出请求时，只有那些其播放属性设置为“自动播放”或“预发送”的播放列表才可以播放。“预发送”是一种缺省播放属性，当没有明确指明播放属性时就给播放列表赋予这种属性。因此，当应用程序的播放属性为指明没有说明的“—”时，这就意味着该播放列表的播放属性为“预发送”。

图28显示了转移目的地标题的三种可能存在的状态((i)不具有播放列表管理表：(ii)具有播放列表管理表和自动播放；以及(iii)具有播放列表管理列表和预发送)和前一个标题中PL的两种可能存在的状态(未播放以及正在播放)之间的六种组合形式。

在图28所示的这六种组合形式中，在“前一种状态＝未播放”和“转移目的地标题具有播放列表管理表，并且播放属性为自动播放”的这种组合中，播放列表的播放在转移目的地标题中自动地启动。

另外，在“前一种状态＝正在播放”和“转移目的地标题不具有播放列表管理表”这种组合中，播放列表的播放在转移目的地标题中停止。在除上述两种之外的其它组合形式中，转移源标题中的状态可以被保持。基于播放列表管理表，仅当在转移源标题中未播放该播放列表并且播放列表的播放属性在转移目的地标题中设置为自动播放时，才会启动播放列表的播放。因此，并不需要每次在标题之间发生转移时都启动播放列表的播放。因此，即使在标题之间发生多次转移，也可以使得启动播放列表播放的次数最小化。

接下来将参考图29A中所示具体的例子，描述如何写播放列表和应用程序管理表。在该具体例子中，使用了两个连续标题(标题#1和标题#2)。在标题#1的表中，将应用程序#1和应用程序#2写为自动运行程序。在标题#2的表中，将应用程序#2和应用程序#3写为自动运行程序。假设在标题#1的播放列表管理表中，将播放列表#1写为自动播放的播放列表，并且在标题#2的播放列表管理表中，将播放列表#2写为自动播放的播放列表。图29B显示了如何根据图29A中所示的播放列表和应用程序管理表播放这些播放列表以及执行应用程序。

根据按照上述方式设置的播放列表和应用程序管理表，当标题#1启动时，应用程序#1和#2自动地启动，并且自动地启动播放列表#1的播放。

根据按照上述方式设置的播放列表和应用程序管理表，就应用程序#1而言，在表中对标题#1进行了描述，但是在表中没有对标题#2进行描述。因此，应用程序#1的执行就会停止。类似地，就播放列表#1而言，在表中对标题#1进行了描述，但是在表中没有对标题#2进行描述。因此，播放列表#1的播放就会停止。

就播放列表#2和应用程序#3而言，在表中没有对标题#1进行描述，但是在表中对标题#2进行了描述。因此，播放列表#2的播放和应用程序#3的执行会自动地启动。可以将一个转移用于使将要播放的一个播放列表变为另一个播放列表。按照这种方式，通过使用播放列表和应用程序管理表使得提前在编写程序阶段就可以在转移定义改变将要播放的播放列表的处理。

另外在图29A所示的例子中，应用程序#1、应用程序#2以及应用程序#3的运行优先级分别为200、128和200。这样一种运行优先级的分配使得可以裁决要被执行的不同应用程序之间的冲突，其中这些应用程序由于发出控制播放列表#1或播放列表#2的请求从而彼此发生冲突。这里假设应用程序#1是对播放列表#1进行快进，而应用程序#2发出使播放列表#1暂停的请求。那么，通过对应用程序管理表中分配给这些应用程序的运行优先级进行比较从而进行裁决。因此，应用程序#1对播放列表#1的控制得以继续，而拒绝了应用程序#2提出的请求。可以在编写程序阶段定义这样一个处理。在播放列表管理表中使用运行优先级使得播放装置可以在出现播放列表所引发的冲突时进行裁决。

接下来描述了播放列表管理表的描述的一个具体例子。图30A显示了播放列表管理表的描述的一个例子。按照如下所述为两个连续标题(标题#1、标题#2)写出了表。在标题#1的播放列表管理表中，将播放列表#1写为自动运行播放列表，并且将播放列表#2写为可播放的播放列表。在标题#1的应用程序管理表中，将应用程序#1写为自动运行应用程序，并且将应用程序#2写为可执行的应用程序。在标题#2的播放列表管理表中，将播放列表#2和播放列表#3写为可播放的播放列表。在标题#2的应用程序管理表中，将应用程序#3写为自动播放应用程序。图30B显示了如何基于图30A中所示的播放列表和应用程序管理表而播放这些播放列表以及执行这些应用程序。根据如上述方式设置的播放列表和应用程序管理表，当标题#1启动时，写为自动运行应用程序的应用程序#1自动地启动。另外，因为在标题#1的应用程序管理表中将应用程序#2写为可执行应用程序，所以通过从应用程序#1发出的调用yd1来启动应用程序#2。

在标题#2的应用程序管理表中，并没有描述应用程序#1和#2，但是将应用程序#3写为了自动运行应用程序。因此，在标题#1和标题#2之间的边界处，应用程序#1和#2的执行会停止，并且应用程序#3会自动地启动。在标题#1的播放列表管理表中，将播放列表#1和#2写为可播放的播放列表。在这些可播放的播放列表中，给播放列表#1赋予了自动播放属性。因此，播放列表#1在标题#1启动时会自动地播放。

在标题#1的播放列表管理表中，将播放列表#1和#2写为可播放的播放列表。因此，应用程序#1可以通过请求播放列表#2的播放从而停止播放列表#1的播放并且启动播放列表#2的播放，从而实现了播放列表改变。在标题#2的播放列表管理表中，将播放列表#2和#3写为可播放的播放列表，并且不存在附带有自动播放属性的播放列表。因此，在标题#1启动时自动地启动的播放列表#1的播放在标题#1期间会持续，但是在标题#2开始时会自动地停止。

但是，如果播放列表#2的播放在标题#1期间一直持续，那么它在标题#2中也会持续。在标题#2的播放列表管理表中，将播放列表#2和#3写为可播放的播放列表。因此，在标题#2中运行的应用程序#3可以通过请求播放列表#3的播放从而停止播放列表#2的播放并且启动播放列表#3的播放，从而实现了播放列表改变。

接下来，将参考图31A到31C描述如何通过播放列表管理表定义标题播放周期。

图31A显示了一个标题的标题播放周期，其中该标题的播放属性设置为自动播放。如果播放属性设置为自动播放，那么当标题的播放启动时自动播放PL的播放也会启动。这里，即使应用程序正常运行并且正常终止，也会根据PL时间轴确定标题播放周期。

图31B显示了这样一种情况：在播放列表管理表中播放属性设置为自动播放，并且应用程序异常终止。在该异常终止后，并不运行任何应用程序，但是会继续自动播放Pl的播放。在这种情况下也是根据PL时间轴确定标题播放周期。

图31C显示了这样一种情况，在播放列表管理表中播放属性设置为自动播放，并且主应用程序未能启动。在这种情况下也是基于PL时间轴确定标题播放周期，这是因为自动播放Pl会被播放而无论应用程序是否出现启动故障。

通过上述这种在播放列表管理表中将播放属性设置为自动播放的安排，可以使得即使启动一个Java(TM)应用程序需要5到10秒，但是在启动期间屏幕上会有显示。也就是说，即使启动一个应用程序需要时间，但是在启动期间屏幕上会有显示。这就缓解了由应用程序启动的耗费时间的处理所导致的启动延迟。

通过定义应用程序和播放列表管理表使得可以进行同步控制以在标题播放期间运行Java(TM)应用程序。这使得可以实现和提供多种用于播放图像和执行程序的应用程序。到目前为止，已经对记录介质进行了描述。接下来将描述本发明的播放装置。

图32显示了本发明的播放装置的内部结构。本发明的播放装置是基于图32中所示内部结构进行工业制造的。本发明的播放装置主要包含两个部分：系统LSI和驱动装置。工业制造是通过将这两部分装入装置的机柜和板中实现的。系统LSI是一种集成电路，它包含用于执行播放装置的函数的多种处理单元。按照这样一种方式制造出的播放装置包含BD-ROM驱动器1、读取缓冲器2、解复用器3、视频解码器4、视频平面5、P图像解码器6、呈现图像平面7、合并单元8、字体生成器9、I图像解码器10、开关11、互动图像平面12、合并单元13、CLUT单元14、CLUT单元15、音频解码器16、网络设备17、本地存储器18、读取缓冲区19、解复用器20、指令ROM21、用户事件处理单元22、PSR装置23、CPU 24、脚本存储器25、本地存储器26以及开关27。

首先，将描述用于播放记录于BD-ROM上的AV剪辑的器件(BD-ROM驱动器1至音频解码器16)。

BD-ROM驱动器1执行BD-ROM的加载/弹出以及对BD-ROM进行访问。

读取缓冲器2是一种FIFO存储器，其中从BD-ROM读取的TS包按照先进先出的方式存储。

解复用器(De-mux)3从读取存储器2中提取TS包，并且将TS包转换为PES包。对于通过这种转换从而获得的PES包。解复用器3将其中那些由CPU 24对PID进行了设置的PES包从通过转换获得的PES包中输出到视频解码器4、P图像解码器6、I图像解码器10以及音频解码器16中的任意一个。

视频解码器4对从解复用器3输出的多个PES包进行解码，将其解码成一种非压缩格式的图像，并且将这些图像写到视频平面5上。

视频平面5是一种用于存储非压缩格式图像的平面。该平面是播放装置中一种用于存储屏幕画面的象素数据的存储区域。视频平面5的分辨率是1920x1080。存储于视频平面5中的图像数据包含由音频解码器16比特YUV值表示的象素数据。在视频平面5中，可以对视频流中每帧播放图像进行缩放。这里，“缩放”是指将每帧播放图像的尺寸变为视频平面5的1/4(四分之一)和1/1(全屏)。可以在BD-J模式中根据CPU 24的指令执行这样一种缩放。这使得可以通过在一个角落或以全屏方式等等显示视频流的播放图像从而实现对屏幕的不同安排。

P图像解码器6将从BD-ROM读出的呈现图像流解码为非压缩图像，并且将这些非压缩图像写入到呈现图像平面7上。对图像流的解码产生出现在屏幕上的字幕。

呈现图像平面7是一种具有一个屏幕大小的存储器区域，并且可以存储一个屏幕的非压缩图像。视频平面5的分辨率是1920x1080。存储于呈现图像平面7中的非压缩图像的每个象素都是由一个8比特索引颜色(inde color)表示。在使用CLUT(颜色查询表)对索引颜色进行转换之后就可以显示存储于呈现图像平面7中的非压缩图像。

合并单元8将存储于视频平面5中的非压缩图像数据(i)与存储于呈现图像平面7中的数据合并到一起。

字体生成器9使用字符字体将包含在文本ST流中的文本代码扩展为位图，并且将这些位图写到呈现图像平面7上。

I图像解码器10将在HDMV模式中从BD-ROM或本地存储器18读出的IG流解码为非压缩图像，并且将这些非压缩图像写到互动图像平面12上。

开关11有选择地将字体生成器9生成的字体序列或通过P图像解码器6进行解码从而得到的图像写到呈现图像平面7上。

互动图像平面12存储那些由I图像解码器10进行解码从而得到的非压缩图像。互动图像平面12还存储那些应用程序在BD-J模式中绘制的字符和图像。

合并单元13将存储于互动图像平面12中的数据与从合并单元8中输出的合成图像(非压缩图像数据和存储于呈现图像平面7中数据的结合)合并在一起。这种合并使得由应用程序写到I图像解码器10上的字符和/或图像可以叠加到非压缩图像数据上。

CLUT单元14将存储于视频平面5中的非压缩图像的索引颜色转换为Y、Cr和Cb值。

CLUT单元15将存储于互动图像平面12中的非压缩图像的索引颜色转换为Y、Cr和Cb值。

音频解码器16对从解复用器3输出的PES包进行解码，并且按照非压缩格式输出音频数据。

到目前为止，已经对用于播放AV剪辑的器件进行了描述。接下来将描述与BD-J模式中操作相关的器件(网络设备17至解复用器20)。

网络设备17用于实现播放装置中的通信功能。当BD-J模式中的Java(TM)应用程序指定一个URL时，网络设备17就会与具有该URL的网站建立TCP连接、FTP连接等等。建立这样一种连接使得该Java(TM)应用程序可以从该网站下载数据。

本地存储器18是一种用于存储元数据以及由除BD-ROM之外的其它记录介质或通信介质提供的内容的硬盘，这些内容例如通过网络设备17建立的连接从网站上下载的内容。该元数据用于通过将下载内容限制在本地存储器18中从而对这些下载内容进行管理。BD-J模式中的一个应用程序可以通过访问本地存储器18从而使用下载内容的一段执行多种过程。

读取缓冲器19是一种FIFO存储器。如果存储于本地存储器18中的下载内容包含一个子剪辑，那么读取缓冲器19就将按照先进先出的方式存储该子剪辑所包含的TS包。

解复用器(De-mux)20从读取缓冲器19中提取TS包，并且将这些TS包转换为PES包。对于通过这种转换从而获得的PES包，解复用器3将其中那些具有期望的PID的PES包从通过转换获得的PES包中输出到字体生成器9、I图像解码器10以及音频解码器16中。

通过网络设备17到解复用器20的上述操作，可以按照与记录于BD-ROM上内容相同的方式对Java(TM)应用程序从网络下载的内容进行播放。接下来将描述用于实现播放装置中集成控制的器件(指令ROM 21至开关27)。

指令ROM 21存储有定义了播放装置的控制的软件。

用户事件处理单元22将用户事件输出到CPU 24，所述用户事件是通过遥控器上或播放装置的前面板上的键盘操作指示的。

PSR集合23是一种嵌入到播放装置中的寄存器，并且包含64个播放器状态寄存器(PSR)和4096个通用寄存器(GPR)。在播放器状态寄存器中所设置的值中(所设置的值称作PSR)，PSR 4和PSR 8用于表示当前播放位置。

PSR 4被设置为从1到100的值，以指示当前播放位置所属的标题，而设置为0时，用于指示当前播放位置属于顶级菜单。

当PSR 5被设置为从1到999的值，以指示当前播放位置所属章节的章节号，而设置为0xFFFF时，用于指示播放装置中的章节号是无效的。

PSR 6被设置为从1到999的值，以指示当前播放位置所属的PL(当前PL)的PL号。

PSR7被设置为从1到255，以指示当前播放位置所属的播放项(当前播放项)的播放项号。

PSR 8被设置为从1到0xFFFFFFFF，以使用45KHZ的时间精度指示当前播放位置(当前PTM(呈现时间))。使用上述的PSR 4至PSR 8，可以在图21A中所示的整个BD-ROM的时间轴上标识当前播放位置。

CPU 24运行存储于指令ROM 21中的软件并且控制整个播放装置。基于用户事件处理单元22输出的用户事件和PSR集合23中不同PSR中设置的值，控制的内容动态地进行改变。

脚本存储器25存储当前PL信息和当前剪辑信息。当前PL信息是记录在BD-ROM上的多条PL信息中作为当前处理目标的那条PL信息。当前剪辑信息是记录在BD-ROM上的多条剪辑信息中作为当前处理目标的那条剪辑信息。

本地存储器26是一种高速缓冲存储器，用于暂时存储记录在BD-ROM上的数据从而弥补从BD-ROM读取数据时的缓慢性。由于有本地存储器26的存在，可以在BD-J模式中高效地执行应用程序。

开关27用于有选择地将从BD-ROM或本地存储器中读取的数据输入到读取缓冲器2、读取缓冲器19、脚本存储器25和本地存储器26中的任意一个。

到目前为止，已经描述了本实施例的播放装置的硬件结构。接下来将描述本实施例的播放装置的软件结构。

图33按照层结构的形式显示了硬件和存储于CPU 24中的软件。如图33中所示，播放装置的层结构包含：

a)作为BD播放器设备的第一层；

b)作为BD播放器模型的第二层；以及

c)作为应用程序运行时间环境的第三层。

图32中所示播放装置的硬件结构属于第一层。作为BD播放器设备的第一层包含：一个“解码器”，它包含视频解码器4、P图像解码器6、I图像解码器10以及音频解码器16；一个“平面”，它包含视频平面5、呈现图像平面7以及互动图像平面12；BD-ROM，BD-ROM的文件系统；本地存储器18以及本地存储器18的文件系统。

作为BD播放器模型的第二层包含：

b2)包含播放控制引擎32的层；以及

b1)包含虚拟文件系统30和呈现引擎31的层，并且该层向高于其自身的层提供功能的API。

作为应用程序运行时间环境的第三层包含：

c1)其中具有模块管理器34的层；

c2)其中具有HDMV模块33和BD-J模块35的层。

在图33中所示的层模型中，模块管理器34位于最上层。模块管理器34具有一个直接通向播放控制引擎32的旁路ur1，该旁路越过了HDMV模块33和BD-J模块35。在如图33中所示的层模型中，由于该旁路的存在，模块管理器34的形状为一个倒写的字符“L”，并且使用户事件管理器37嵌入到其中。

BD-J模块35是一种Java(TM)平台，具有以Java(TM)虚拟机38为中心的构造。多种系统程序和应用程序都在该Java(TM)虚拟机38所包含的工作存储器中工作。位于Java(TM)虚拟机38之上的应用程序管理器36和时间听者管理器39(缺省操作管理器40)都是这种系统程序。应用程序管理器36包含一个PLMT处理器41。另外，在BD-J模块35和播放控制引擎32之间有一个许可控制器42。

首先将描述属于第二层的虚拟文件系统30至模块管理器34。图34显示了虚拟文件系统30到模块管理器34所执行的处理。

虚拟文件系统30是一种用于对存储于本地存储器18中的下载内容按照BD-ROM的盘内容的处理方式进行处理的一种虚拟文件系统。存储于本地存储器18中的下载内容包含子剪辑、剪辑信息以及播放列表信息。下载内容中的播放列表信息与记录在BD-ROM上的播放列表信息的区别在于，它可以指定剪辑信息而无论这些剪辑信息是存储于BD-ROM上还是存储于本地存储器18上。并且对于这种指定，虚拟文件系统30上的播放列表信息不需要通过全路径指定BD-ROM或本地存储器18上的一个文件。这是因为BD-ROM或本地存储器18上的文件系统被视作一种虚拟文件系统(虚拟文件系统30)。因此，通过这里所指定的作为存储剪辑信息的文件的文件体的五位数值，可以将播放项信息中的Clip_Information_file_name和子播放项信息中的Clip_Information_file_name用于指定虚拟文件系统30或BD-ROM上的一个AV剪辑。对于通过虚拟文件系统30从本地存储器18中读取的数据，当将这些数据动态地与存储于BD-ROM中的数据合并到一起时，可以生成多种形式的播放。在本实施例中，因为将本地存储器18和BD-ROM合并的盘内容与BD-ROM的盘内容同等对待，所以可以认为“BD-ROM”也指一种虚拟记录介质，并且这种虚拟记录介质是本地存储器18和BD-ROM的合并。

呈现引擎31执行AV播放功能。播放装置中的AV播放功能是一组从CD和DVD播放器继承而来的传统功能。这些AV播放功能包含：播放、停止、暂停开始、暂停结束、静止结束、向前播放(具有速度说明)、向后播放(具有速度说明)、视频变换、字幕变换以及角度变换。为了实现这些AV播放功能，呈现引擎31控制视频解码器4、P图像解码器6、I图像解码器10以及音频解码器16从而对对应于一段期望时间的一部分AV剪辑进行解码，并且这部分AV剪辑已经被读取到读取缓冲器2中。这里，期望时间可以是由PSR8(当前PTM)指定的时间。通过这种构造，可以播放对应于任意一段时间的一部分AV剪辑。

播放控制引擎(PCE)32所执行的功能包含：(i)播放列表播放控制功能；以及(ii)通过PSR集合23从而获得和设置状态的状态获得/设置功能。在呈现引擎31所执行的AV播放功能中，播放列表播放控制功能是根据当前PL信息和剪辑信息而执行的播放启动和播放停止等等。该功能(i)和(ii)响应于由HDMV模块33、模块管理器34和BD-J模块35发出的功能调用而执行。

也就是说，如果播放控制引擎32接收到命令它播放一个PL的功能调用，那么它就通过虚拟文件系统30，从BD-ROM或本地存储器18中读取对应于该功能调用中所指定的PL的播放列表信息。然后，播放控制引擎32参考该段播放列表信息中包含的播放项信息，通过虚拟文件系统30从BD-ROM或本地存储器18中读取该播放项信息的Clip_Information_file_name中叙述的剪辑信息。图34中的符号◎1、◎2、◎3以及◎4分别指示了以下内容：通过虚拟文件系统30读取播放列表信息(◎1)；对播放列表信息所包含的播放项信息进行解码(◎2)；通过虚拟文件系统30读取剪辑信息(◎3)；对剪辑信息进行解码(◎4)。在按照上述方式对剪辑信息和播放列表信息进行解码之后，通过虚拟文件系统30将AV剪辑所包含的TS包转移到呈现引擎31。在将TS包转移到呈现引擎31之后，呈现引擎31将AV剪辑所包含的TS包输出到解码器从而可以在平面上显示它们。图34中的符号☆1、☆2、☆3、☆4以及☆5分别指示以下内容：读取AV剪辑所包含的TS包(☆1、☆2)；从虚拟文件系统30将这些TS包转移到呈现引擎31(☆3)；将这些TS包输出到解码器(☆4)；以及将通过解码器得到的解码结果输出到平面(☆5)。

HDMV模块33是用于执行HDMV模式的主体。如果HDMV模块33从模块管理器34接收到一个激活请求(activate(mobj_id)，其中mobj_id指定了一个转移目的地MovieObject(电影对象))，那么它就将该MovieObject(mobj_id)存储到本地存储器26中，对该MovieObject中写入的导航命令进行解码，并且根据解码结果向播放控制引擎32发出一个功能调用。在图34中，带有符号▽2、▽3以及▽4的箭头分别指示以下内容：从模块管理器34接收“activate(mobj_id)”(▽2)；对MovieObject中写入的导航命令进行解码(▽3)；以及向播放控制引擎32发出一个功能调用(▽4)。

模块管理器34持有从BD-ROM读取的Index.bdmv并且执行转移控制。该转移控制包括向当前标题所包含的动态脚本发出一个终止事件，以及向转移目的地标题所包含的动态脚本发出一个激活事件。如果一个MovieObject执行一个指定title_id的JumpTitle(跳转标题)命令(JumpTitle(title_id))，那么模块管理器34向当前标题所包含的MovieObject发出一个终止事件，并且发出一个activate(mobj_id)事件从而激活对应于title_id的标题所包含的MovieObject。在图34中，带有符号▽0、▽1以及▽2的箭头分别指示以下内容：执行一个JumpTitle命令(▽0)；模块管理器34参考Index.bdmv(▽1)；以及发送一个通知从而激活转移目的地标题所包含的MovieObject(▽2)。这些工作步骤也适用于其中BD-J对象调用JumpTitleAPI(JumpTitle(title_id))的情况。在这种情况下，向当前标题所包含的BD-J对象发出一个终止事件，并且向BD-J模块35发出一个activate(mobj_id)从而激活对应于title_id的标题所包含的BD-J对象。

到目前为止，已经描述了呈现引擎31至模块管理器34。接下来将参考图35描述应用程序管理器36。图35显示了应用程序管理器36。

每当标题之间发生转移时，应用程序管理器36就会命令Java(TM)虚拟机38启动这样一个应用程序：它未在转移源标题中运行，但是对于转移目的地标题却具有运行属性“自动运行”。同时，应用程序管理器36终止这样一个应用程序：它在转移源标题中运行，但是在转移目的地标题中却没有生存周期。通过参考当前BD-J对象的应用程序管理表从而进行这样的启动控制和终止控制。这里如果在标题之间发生一个转移，那么模块管理器34会发出activate(bobj_id)的通知。当接收到该通知时，应用程序管理器36将当前BD-J对象设置为对应于该bobj_id的BD-J对象，并且参考当前BD-J对象的应用程序管理器表。这使得应用程序管理器36可以识别那些自动启动和自动终止的应用程序。在图35中，符号☆0、☆1、☆2以及☆3分别指示以下内容：发生一次TitleJump(标题跳转)(☆0)；通知activate(bobj_id)(☆1)；参考应用程序管理表(☆2)；以及命令Java(TM)虚拟机38启动一个应用程序(☆3)。通过该启动一个应用程序的命令，Java(TM)虚拟机38把xlet程序从本地存储器26读取到工作存储器(☆4、☆5)。

到目前为止，已经描述了应用程序管理器36。接下来将参考图36描述用户事件管理器37至缺省操作管理器40。

用户事件管理器37将用户事件处理单元22接收到的用户事件分为：(i)播放控制的用户事件以及(ii)键盘事件。播放控制的用户事件是用于发出以下命令的用户事件：播放、停止、暂停开始、暂停结束、静止结束、向前播放(具有速度说明)、向后播放(具有速度说明)、视频变换、字幕变换以及角度变换。键盘事件是指示按下了以下这些键的用户事件：向上移动、向下移动、向右移动、向左移动以及数字键。用户事件管理器37发出一个功能调用，从而使播放控制引擎32根据播放控制的用户事件执行播放控制功能。该功能调用称作UO(用户操作)，并且通过位于模块管理器34的旁路上的UO控制器37a发送到播放控制引擎32，而不通过HDMV模块33和BD-J模块35。这使得可以无延迟地执行用于播放、停止、暂停开始、暂停结束等等的播放控制。在图36中，符号☆1、☆2以及☆3分别指示以下内容：用户事件管理器37将用户事件分为(i)播放控制的用户事件以及(ii)键盘事件(☆1、☆2)；以及根据播放控制的用户事件被发送到播放控制引擎32的功能调用(☆3)。

Java(TM)虚拟机38将应用程序所包含的xlet程序加载到工作存储器，对该xlet程序进行解码，并且根据解码结果控制较低的层。更具体地说，在对较低层的控制中，Java(TM)虚拟机38向BD中间件(middleware)(未示出)发出一种JMF方法，从而对应于BD播放装置的功能调用可以替换现有的功能调用，并且在该替换之后将该功能调用发送到播放控制引擎32。

事件听者管理器39对键盘事件进行分析并且分发这些事件。图36中的实线箭头◇1和◇2指示了由事件听者管理器39所进行的事件分发。如果要被分发的事件是已经在xlet程序的事件听者中登记了的键盘事件，那么事件听者管理器39就将该事件分发到由BD-J对象间接指向的一个xlet程序。xlet程序中的事件听者具有对应于已经在其中登记了的JMF的键盘事件。因此，可以通过这样一种登记的键盘事件启动该xlet程序。如果要被分发的事件是未在事件听者中登记的键盘事件，那么事件听者管理器39就将该事件分发到缺省操作管理器40。因为在BD-ROM播放装置中可能会出现包含未在事件听者中登记的键盘事件的各种键盘事件，所以上述安排是用于对每种键盘事件都可以进行适当地处理而不会出现故障。

当事件听者管理器39将未在xlet程序的事件听者中登记的键盘事件分发到缺省操作管理器40时，缺省操作管理器40向播放控制引擎32发出对应于该未在事件听者中登记的事件的一个功能调用。图36中的箭头◇3指示了由缺省操作管理器40发出的该功能调用。

PLMT处理器41是应用程序管理器36的一个组成部分，并且如果从模块管理器34接收到activate(bobj_id)，那么它就参考由bobj_id标识的BD-J对象的播放列表管理表。并且如果将具有播放属性“自动播放”的PL写入到BD-J对象的播放列表管理表中，那么PLMT处理器41就输出到播放控制引擎32以播放该自动播放PL。但是，如果播放控制引擎32发出一种指示PL播放的结束的通知事件，那么PLMT处理器41就会将发出该通知事件的时刻认做标题结束点。图36中的箭头Δ1和Δ2分别指示了以下内容：向播放控制引擎32发出一个功能调用PLayPL(Δ1)；从播放控制引擎32输出一个通知事件(Δ2)。

以上就是对BD-J模块35中层结构的全部描述。这里应该注意到，在本实施例中省去了对许可控制器42的描述，我们会在实施例3中对其进行详细描述。

<Java(TM)虚拟机38的内部结构>

接下来将描述Java(TM)虚拟机38的内部结构。图37显示了Java(TM)虚拟机38的内部结构。如图37中所示，Java(TM)虚拟机38包含了如图32所示的CPU 24、用户类加载器52、方法区域53、工作存储器54、线程55a、55b，…55n以及Java(TM)堆栈56a、56b，…56n。

用户类加载器52从本地存储器26等等中读取属于BDJA目录的Java(TM)存档文件中的类文件，并且将这些读取的类文件存储到方法区域53中。这种由用户类加载器52对类文件的读取是通过应用程序管理器36指定一个文件路径并且命令用户类加载器52按照该路径读取类文件而实现的。如果该文件路径指示本地存储器26，那么用户类加载器52从本地存储器26将一个应用程序所包含的Java(TM)存档文件中的一个类文件读取到工作存储器上。如果该文件路径指示虚拟文件系统30中的一个目录，那么用户类加载器52从BD-ROM或本地存储器18上将一个应用程序所包含的Java(TM)存档文件中的一个类文件读取到工作存储器上。图35中所示的应用程序激活控制(☆3、☆4以及☆5)是通过用户类加载器52对类文件的读取而实现的。如果所指定读取的类文件并未存储于本地存储器26，那么用户类加载器52就通知应用程序管理器36出现一个读取故障。

方法区域53存储由用户类加载器52从本地存储器26读取的类文件。

工作存储器54被称作堆区域，用于存储各种类文件的实例。图33中所示的应用程序管理器36和事件听者管理器39是位于工作存储器54中的常驻应用程序。工作存储器54还存储对应于存储于方法区域53中的类文件的实例以及常驻类型实例。这些实例是应用程序所包含的xlet程序。当这样的xlet程序存储于工作存储器54中之后，应用程序就做好了运行的准备。在图33、35和36中所示的层模型中，工作存储器54位于高于Java(TM)虚拟机38的一个层。但是，按照这种方式描述工作存储器54中的应用程序管理器36和事件听者管理器39是为了易于理解。实际上，线程55a、55b，…55n将应用程序管理器36和事件听者管理器39作为实例执行。

线程55a、55b，…55n是用于执行存储于工作存储器54中的方法的逻辑执行体。线程55a、55b，…55n将存储于本地变量或操作数堆栈中的变量作为操作数从而执行计算，并且将计算结果存储到这些本地变量或操作数堆栈中。箭头ky1、ky2以及kyn象征性地指示了从工作存储器54向线程55a、55b，…55n提供的方法。尽管物理执行体仅是一个CPU，但是Java(TM)虚拟机中最多可以提供64个线程作为逻辑执行体。只要逻辑执行体的数量不超过64，那么就可以生成新线程或删除现有线程。在Java(TM)虚拟机38的工作期间可以增加或降低工作线程的数量。因为在必要时可以增加线程的数量，所以可以允许多个线程并行执行一个实例，由此提高了该实例的执行速度。在图37中，CPU 24和线程之间具有“一对多”的关系。但是，如果有多个CPU，那么这种关系可以为“多对多”。线程55a、55b，…55n对这些方法的执行是通过下述方式实现的：将该方法所包含的字节码转换为CPU 24的原生码，并且将这些原生码发送到CPU 24。这里省略了对这种转换为原生码的描述，这是因为这样就偏离了本发明的主题。

基于一对一的关系，与线程55a、55b，…55n一致地提供了Java(TM)堆栈56a、56b，…56n，并且每个堆栈都具有一个程序计数器(图37中的PC)和一个或多个帧。该“程序计数器”指示了当前执行的实例的一个部分。该“帧”是一对一分配给对方法的调用的堆栈系统区域。每帧包含：用于存储在有过一次的调用中使用的参数的“操作数堆栈”；以及该被调用的方法使用的“局部变量堆栈(图37中的本地变量)”。因为每次执行调用时就会使一帧进入Java(TM)堆栈56a、56b，…56n，所以当一个方法递归调用其自身时也会使一帧进入堆栈。当调用一个JMF播放器实例播放方法时，或当调用一个JumpTitle API调用时，对应于该调用的一帧会进入Java(TM)堆栈56a、56b，…56n。作为参数存储于这些帧的操作数堆栈中的信息包含：(i)播放方法将要播放的MPLS文件的文件名；(ii)指示JumpTitle API调用的跳转目的地的title_id等等。

接下来将详细描述应用程序管理器36和它的组成部分PLMT处理器41如何在上述的Java(TM)虚拟机38的内部结构中进行工作。

在模块管理器34输出一个请求激活一个由bobj_id标识的BD-J对象的事件(activatred[bobj_id])之后，应用程序管理器36就将具有该bobj_id的BD-J对象设置为当前BD-J对象，其中该应用程序管理器36是工作存储器54中的一个实例。然后，应用程序管理器36对转移源标题中的执行状态和当前BD-J对象中应用程序的运行属性进行检查，并且确定(i)要自动启动的应用程序以及(ii)要自动终止的应用程序。

确定(i)要自动启动的应用程序是通过以下方式实现的：在当前BD-J对象的应用程序管理表中搜索在转移源标题中未运行但是在当前BD-J对象中具有自动运行属性的应用程序的apli_id_ref。如果找到这样的apli_id_ref，应用程序管理器36就命令用户类加载器52读取属于由该apli_id_ref标识的应用程序的Java(TM)存档文件的类文件，这使得可以在工作存储器54中生成对应于该类文件的实例。这使得其生存周期位于当前标题中的应用程序做好了启动的准备。然后，当线程55a、55b，…55n被引发执行该应用程序的方法时，该应用程序就会启动。

确定(ii)要自动终止的应用程序是通过以下方式实现的：在当前BD-J对象的应用程序管理表中搜索在转移源标题中运行但是在当前BD-J对象中并不具有生存周期的应用程序的apli_id_ref。如果找到这样的apli_id_ref，应用程序管理器36就终止具有apli_id_ref的应用程序所包含的xlet程序。这使得可以重新获得以下这些资源：(i)工作存储器54中原来被该应用程序占据的一个区域，或者(ii)Java(TM)堆栈56a、56b，…，56n中那些原来被用于执行该应用程序的方法的帧。

应用程序管理器36的一个组成部分PLMT处理器41对转移源标题中的播放状态和当前标题中播放列表的播放属性进行检查，并且确定(i)要被自动播放的播放列表以及(ii)要被自动终止的播放列表。

确定(i)要自动播放的播放列表是通过以下方式实现的：在播放列表管理表中搜索在转移源标题中未播放但是在当前标题中具有自动播放属性的播放列表。如果找到这样的播放列表，PLMT处理器41就将要被播放的播放列表的Pl_id_ref作为参数从而执行用于播放列表播放的功能调用。通过执行该调用，可以在Java(TM)堆栈56a、56b，…56n中生成具有存储在操作数堆栈中的Pl_id_ref的帧。并且线程55a、55b，…55n执行用于播放列表的播放的功能调用。通过执行该功能调用，呈现引擎31开始对该播放列表进行播放。

确定(ii)要自动终止的播放列表是通过以下方式实现的：在播放列表管理表中搜索在转移源标题中播放但是并未写入到当前标题的播放列表管理表中的播放列表。如果找到这样的播放列表，PLMT处理器41就执行一种用于停止播放该播放列表的功能调用，并且从Java(TM)堆栈56a、56b，…56n中删除对应于用于播放该播放列表的功能调用的帧。

应用程序可以按照四种模式在工作存储器54中终止。图38显示了应用程序终止的这四种模式。在第一种模式中，当发生资源短缺并且应用程序管理器36发出一个终止事件时应用程序终止(☆1)。在第二种模式中，当应用程序通过应用程序管理器36从另一个应用程序接收到一个终止事件时该应用程序终止(☆2)。在第三种模式中，当应用程序管理表中写入的生存周期结束并且应用程序管理器36发出一个终止事件时应用程序终止(☆3)。在第四种模式中，当应用程序自身激活终止处理时该应用程序终止(☆4)。在这四种模式中的三种中，由应用程序管理器36终止该应用程序。由此我们可以理解，应用程序管理器36在控制应用程序的工作方面发挥了中心作用。如果发出一个终止事件不会使应用程序终止，那么应用程序管理器36可以强制性地终止该应用程序从而重新获得资源。这种可以强制性重新获得资源的权力是应用程序管理器36的一个特性。到目前为止，我们已经对BD-J模块35的组成部分进行了描述。(流程图的描述)

上述内容只是对应用程序管理器36进行了概况性描述。图39和40中详细显示了应用程序管理器36的处理。接下来将参考流程图更加详细地描述应用程序管理器36的处理步骤。

图39是显示应用程序管理器36的步骤的流程图。图39所示的步骤包含一个主环路，而该主环路包含步骤S1、S2、S3和S4。在步骤S1中，对是否发生了一个标题跳转进行判断。如果判断出发生了一个标题跳转，那么应用程序管理器36改变标题(步骤S7)，参考转移目的地标题的应用程序管理表，并且终止在转移源标题中运行但并不存在于转移目的地标题中的应用程序(步骤S8)。然后，应用程序管理器36参考转移目的地标题的播放列表管理表，并且终止正在转移源标题中播放而并不存活于转移目的地标题中的播放列表(步骤S9)。

然后，应用程序管理器36命令PLMT处理器41判断是否有一个在转移源标题中未播放而在转移目的地标题中具有自动播放属性的PL(步骤S10)。如果判断出有这样一个PL，那么PLMT处理器41就命令播放控制引擎32播放该自动播放PL(步骤S11)。如果没有这样的PL，那么就不播放自动播放PL。

随后的步骤包含步骤S12至S18，用于激活在转移目的地标题中具有生存周期的应用程序。在该工作步骤中，应用程序管理器36命令启动一个自动运行应用程序(步骤S14)，并且如果该自动运行应用程序成功地启动(步骤S15中为“YES”)，那么就将自动播放PL的播放图像转换为四分之一(1/4)(步骤S18)。

如果步骤S15中判断为“NO”，那么就执行包含S14至S17的环路。该环路中的控制变量具有一个重新启动计数器。该重新启动计数器定义了一个应用程序重新启动的次数。在步骤S12中对该重新启动计数器进行重新设置，并且在步骤S16中判断重新启动计数器是否为0。如果在步骤S16中判断出重新启动计数器不是0，那么在步骤S17中就对该重新启动计数器进行减法操作。只要重新启动计数器不是0，该自动运行应用程序就在包含步骤S14到S17的环路处理中反复启动。这样一种重复就确保了可以激活应用程序。

在步骤S2，判断是否终止了一个主应用程序。如果判断出终止了主应用程序，那么控制就转移到步骤S5并且判断该主应用程序是否正常终止。如果判断出主应用程序异常终止，那么就执行步骤S19和S20。如果判断出主应用程序正常终止，那么控制就返回到包含步骤S1到S4的主环路，而不执行步骤S19和S20。

在步骤S19，判断是否正在播放一个自动播放PL。如果判断出正在播放一个自动播放PL，那么应用程序管理器36就命令播放控制引擎32将该自动播放PL的播放图像转换为全屏(步骤S20)。然后，控制转移到步骤S16。通过控制转移到步骤S16，即使应用程序异常中断，也可以执行包含步骤S14至S17的环路处理。这使得应用程序可以反复启动直到在步骤S12中设置的重新启动计数器变为0。

在步骤S4中，判断在BD驱动器1中是否存在BD-ROM。如果不存在BD-ROM，那么应用程序管理器36就命令终止所有应用程序(步骤S6)。

图40显示了播放列表管理表和应用程序管理表的具体例子。在图40中，第一行显示了一个标题的播放图像，第二行显示了该标题的时间轴，第三行显示了一个PL的播放的过程，并且第四行显示了一个应用程序的执行。第四行指示了当标题开始时应用程序#1启动，并随后在时刻t1进入到操作状态。另一方面，当标题开始时播放列表#1启动播放。因此，如第一行左手侧所示，在应用程序启动延迟期间，即在标题启动之后和应用程序进入操作状态之前的期间，以全屏图像显示播放列表#1的播放图像gj1。当应用程序#1在时刻t1进入操作状态时，显示一个合成图像gj2，它包含：作为子屏的PL的播放图像；以及作为母屏的应用程序的执行图像。该例子中应用程序的执行图像是用于一种游戏的屏幕，其中安排有启动按钮、继续按钮以及电源指示器。另外，将该应用程序的执行图像显示为一个Java(Tm)应用程序，执行在互动图像平面12上画出一个图像的处理。为了执行该画图处理，Java(TM)应用程序需要画图库和字符库。此后，只要同时进行该应用程序的执行和该PL的播放，就显示该母-子屏。

在该例子中，应用程序#1随后异常终止，并且应用程序管理器36在时刻t2探测到该异常终止。箭头br1象征性地指示了该探测。当它发生时，应用程序管理器36在步骤S20将PL的播放图像转换为全屏。在图40中，在时刻t3转换为全屏。如第一行的右手侧所示，按照全屏图像的方式显示播放图像gj3。

如上所述，根据本实施例，通过将播放列表管理表中的播放属性设置为自动播放的这种安排，即使一个启动了的Java(TM)应用程序需要花费5到10秒才能进入到操作状态，在启动期间在屏幕上也有显示。“屏幕上有显示”的这种状态缓解了开始执行一个标题时发生的启动延迟。

另外，如果发生应用程序启动故障，或者如果应用程序异常终止，那么还会继续播放在播放列表管理表中定义的播放列表，这也提供了其中“屏幕上有显示”的状态。通过这种安排，可以避免装置出现黑屏这种最坏情况。这至少在一定程度上可以使装置的制造商感到放心。

实施例2

实施例2涉及一项改进，其中在编写程序期间就定义了错误终止的恢复处理。为了定义这样一种恢复处理，在本实施例的记录介质中，在一个BD-J对象中提供了一个错误管理表。图41A显示了该BD-J对象的内部结构。如图41A中所示，该BD-J对象除了包含应用程序和播放列表管理表之外，还包含一个错误管理表(Error ManagementTable[bobj_id])。图41B显示了该错误管理表的内部结构。如图41B中所示，该错误管理表包含数量由Number_of_recovery指示的多条恢复信息(recovery())。图41B中的虚线“em1”指示了由标识符“recovery_id”标识的一条给定的恢复信息的内部结构的局部放大图。由虚线“em1”指示的该条给定恢复信息包含：参照值“Apli_id_ref”，它唯一地标识了对应于该条恢复信息的应用程序的标识符；以及五个标记“Restart_Application_flag”、“Continuous_Playback_flag”、“Select_Title_flag”、“Notify_Event_flag”以及“Reboot_flag”。图42显示了这五个标记的含义。接下来将描述错误管理表中这五个标记的含义。

当将“Restart_Application_flag”设置为0时，它指示了当一个应用程序异常终止时，该应用程序并不重新启动，并且当将它设置为除“0”之外的整数“n”时，它指示了重复n次进行重新启动。该标记的缺省值为“0”。

当将“Continuous_Playback_flag”设置为“0”时，它指示了当应用程序异常终止时并不继续播放列表的播放，并且当将它设置为“1”时，它指示了当应用程序异常终止时继续播放列表的播放，而当将它设置为“2”时，它指示了当应用程序异常终止时继续播放列表的播放并且这种播放是按照全屏图像和正常速度进行的。该标记的缺省值为“0”。

当将“Select_Title_flag”设置为“0”时，它指示了当应用程序异常终止时在标题之间不发生转移，并且当将它设置为除“0”之外的整数“n”时，它指示了当前标题跳转到以“n”作为其标题号的标题。该标记的缺省值为“0”。

当将“Notify_Event_flag”设置为“0”时，它指示了当应用程序异常终止时不输出事件，并且当将它设置为除“0”之外的整数“n”时，它指示了输出事件序号为“n”的事件。该标记的缺省值为“1”。

当将“Reboot_flag”设置为“0”时，它指示了当应用程序异常终止时并不执行播放装置的引导程序，并且当将它设置为“1”时，它指示了执行播放装置的引导程序。

可以在编写程序期间通过上述标记提前定义当应用程序异常终止时需要执行的恢复处理。现在，给出了错误管理表的说明的一个具体例子。图43A显示了两个标题(标题#1、标题#2)，并且其中写入了错误管理表。在标题#1的应用程序管理表中，将应用程序#1写为一种AutoRun(自动运行)应用程序。并且在标题#1的错误管理表中，写入了当应用程序#1异常终止时需要用到的一条恢复信息。在标题#1的播放列表管理表中，将播放列表#1写为一种AutoPlay(自动播放)播放列表。

在标题#2的应用程序管理表中，将应用程序#2写为一种AutoRun应用程序。并且在标题#2的错误管理表中，写入了应用程序#2的一条恢复信息。

图43B显示了根据图43A中所示应用程序和错误管理表从而执行的一个应用程序的执行进度和一个播放列表的播放进度。因为应用程序#1的恢复信息指示了Continuous_Playback_flag＝2，所以当应用程序#1异常终止时播放列表继续播放，并且该播放是按照全屏图像和正常速度进行的。

另一方面，应用程序#2的恢复信息指示Notify_Event_flag＝2，所以当应用程序#2异常终止时输出序号为“2”的事件。

使用这样的恢复信息描述，可以为每个标题和每个应用程序定义应用程序异常终止时需要执行的处理。

通过向BD-J对象中加入错误管理表，本实施例的应用程序管理器36根据图44和45中所示的流程图执行处理。图44是显示了实施例2中应用程序管理器36的工作步骤的流程图。与图39中的情况相同，该流程图包含了一个主环路，而该主环路包含步骤S1、S2、S3以及S4。当在主环路中选择了一个标题时，就执行步骤S21至S27的过程。

在步骤S21，应用程序管理器36使PLMT处理器41判断在转移目的地标题中是否有播放列表管理表。如果在转移目的地标题中存在播放列表管理表，那么应用程序管理器36就使播放控制引擎32启动在转移源标题中并未播放但是在转移目的地中具有AutoPlay属性的一个PL的播放(步骤S22)，并且然后判断该播放是否成功(步骤S23)。如果在步骤S23中判断出该播放是成功的，那么执行步骤S25到S28的过程。如果在步骤S23中判断出该播放并不成功，那么控制就转移到图45中所示的流程图。

如果在转移目的地标题中没有播放列表管理表，那么应用程序管理器36就使播放控制引擎32停止在转移源标题中正在播放的一个PL的播放(步骤S24)，并且执行步骤S25到S28的处理。

在步骤S25，判断在转移目的地标题中是否有应用程序管理表。如果在转移目的地标题中有应用程序管理表，那么应用程序管理器36就启动转移目的地标题中的AutoRun应用程序(步骤S26)，并且在步骤S27，判断该应用程序是否成功地启动，如果在步骤S27中判断出应用程序成功地启动，那么控制就返回到包含步骤S1到S4的环路。如果判断在步骤S27中应用程序未成功启动，那么控制就转移到图45中所示的流程图。

图45的流程图显示了当一个应用程序异常终止时执行的工作步骤。在步骤S30中，判断发生异常终止的该应用程序所属的标题中是否有错误管理表。如果在步骤S30中判断出该标题中没有错误管理表，那么控制就返回到包含步骤S1到S4的环路。

如果在步骤S30中判断出该标题中有错误管理表，那么控制就转移到步骤S44然后返回到包含步骤S1到S4的环路。在步骤S31，判断错误管理表中的Restart_Application_flag是否为“0”。如果判断出错误管理表中的Restart_Application_flag不为“0”，那么执行包含步骤S40到S44的环路处理。在该环路处理中，将重新启动计数器设置为写入到Restart_Application_flag的值“n”(步骤S40)，并且然后执行包含步骤S41到S44的环路。该环路处理中的控制变量是该重新启动计数器。当应用程序成功启动(步骤S44中为“Yes”)并且重新启动计数器变为“0”时(步骤S41中为“Yes”)，该环路处理结束。在该环路处理中，只要在步骤S41或S44中判断出为“No”，那么就重复对该重新启动计数器进行减法操作(步骤S42)并且重复启动该AutoRun应用程序。通过这种重复，可以重新启动异常终止的应用程序。如果判断出Restart_Application_flag是“0”，那么就执行步骤S32。

在步骤S32，判断Continuous_Playback_flag是“0”、“1”还是“2”。如果判断出Continuous_Playback_flag是“2”，那么就按照全屏方式显示AutoPlay PL的播放图像(步骤S33)，并且控制返回到包含步骤S1到S4的主环路。

如果判断出Continuous_Playback_flag是“1”，那么就按照四分之一屏幕的方式继续AutoPlay PL的播放图像(步骤S34)，并且控制返回到包含步骤S1到S4的主环路。

如果判断出Continuous_Playback_flag是“0”，那么控制就转移到步骤S35。

在步骤S35，判断错误管理表中select_title_flag是否不为“0”。如果判断出select_title_flag为“0”，那么控制转移到步骤S37。如果判断出select_title_flag不为“0”，那么就将转移目的地标题设置为写在select_title_flag中的值“n”(步骤S36)，并且控制转移到如图44中所示的步骤S37，

在步骤S37，判断错误管理表中Notify_Event_flag是否不为“0”。如果判断出Notify_Event_flag为“0”，那么控制转移到步骤S39。如果判断出Notify_Event_flag不为“0”，那么就生成由Notify_Event_flag的值“n”标识的事件“n”(步骤S38)，并且控制转移到包含步骤S1到S4的主环路，如图44中所示。在步骤S39，判断判断错误管理表中Boot_flag是否不为“0”。如果判断出Boot_flag为“0”，那么控制转移到包含步骤S1到S4的主环路。如果判断出Boot_flag不为“0”，那么控制就转移到图44的开始处，并且执行播放装置的引导程序。

如上所述，根据本实施例，可以由程序编写者而不是装置制造者定义当应用程序异常终止时播放装置应该如何执行操作。

这里应该注意到，可以将这样一个程序嵌入到播放装置中：在播放一个不具有错误管理表的标题期间，当一个应用程序异常终止时，该程序就执行一种恢复处理。

另外，在标题跳转API中可以提供指定Restart_Application_Flag至Reboot_Flag中任何一个的参数，从而应用程序管理器36可以执行对应于在标题跳转API中提供的参数的恢复处理。

实施例3

在实施例1中我们描述过了，可以将BD-J对象中的播放列表管理表用于定义Java(TM)虚拟机中PL的播放。本实施例则将重点放在通过应用程序的JMF方法的PL的播放。这样做所带来的一个问题是播放列表管理表。也就是说，因为在播放列表管理表中已经描述了是否可以播放一个PL，所以在某些标题中可以播放该PL，而在另外一些标题中则不能播放该PL。另外，还有这样一种情况，其中从版权保护的角度出发，我们希望禁止某种特定的应用程序对一个PL进行播放，尽管我们已经将该PL定义为可以播放。为了实现这种对PL的播放的限制，在实施例3中，许可控制器42和应用程序管理器36执行以下处理。

如果一个应用程序请求播放一个PL，那么许可控制器42就执行与该应用程序的互相认证，并且判断请求播放该PL的应用程序是否被授权播放该PL。如果该应用程序被授权播放该PL，那么许可控制器42就请求控制机32播放该PL。如果未授权该应用程序播放该PL，那么许可控制器42就向请求PL播放的应用程序输出一个响应事件，该事件指示了请求未被许可。通过这种由许可控制器42判断是否许可应用程序发出的播放PL的请求，如果发行人所发行的PL被请求用另一个发行人所发行的应用程序播放，那么该请求就可能会被拒绝。这使得不能使用非授权的应用程序播放一个PL。许可控制器42所做出的判断是基于允许播放的PL和应用程序的组合以及不允许播放的PL和应用程序的组合，并且在记录于BD-ROM中的许可文件中定义了这些组合。这里省略了对这样一种文件的详细描述，因为它偏离了本申请的主题。

在实施例3中，应用程序管理器36响应于一个应用程序发出的请求，通知可以在当前播放时间点播放的一个PL。图46是一个流程图，它显示了应用程序管理器36所做出的这种通知的步骤。在该流程图中，在一个应用程序启动期间，对该应用程序是否发出了通知一个可播放PL的请求(GetPL)进行监视(步骤S45)。如果判断出该应用程序发出了这样一种请求，那么继续判断在当前播放点所属的标题所包含的BD-J对象中是否存在播放列表管理表(步骤S46)。如果在该播放列表管理表中写入了一个PL，那么就将写入到播放列表管理表中的该PL作为可播放PL通知给请求播放的该应用程序(步骤S47)。

如果在播放列表管理表中未写入一个PL，那么就向请求播放的该应用程序发送一条PL的播放不可用的通知(步骤S48)。到目前为止，已经描述了实施例3中应用程序管理器36所执行的步骤。

接下来将描述当请求一个PL的播放时应用程序管理器36所执行的步骤。在实施例3中，应用程序管理器36根据图47所示流程图执行处理。

在图47中，应用程序管理器36判断是否有一个应用程序请求对一个PL的播放(步骤S51)。如果有请求一个PL的播放的应用程序，那么应用程序管理器36就使得许可控制器42执行一种认证，从而判断请求该播放的应用程序是否被授权播放该PL(步骤S52)。如果该应用程序被授权播放该PL，那么应用程序管理器36就命令播放控制引擎32启动该播放(步骤S53)，并且等待由播放控制引擎32发出的指示成功的响应(步骤S54)。

当接收到这样一种播放请求时，播放控制引擎32检查播放列表信息的真实性。该检查包含：检查其中存储有播放列表信息、剪辑信息以及AV剪辑的BD-ROM和本地存储器18是否构成一个适当的播放列表；以及由播放列表信息中clip_Information_file_name指定的该剪辑信息和AV剪辑是否存储于BD-ROM和本地存储器18上。在其中clip_Information_file_name并未指向一个适当文件的情况下，或者在其中包含BD-ROM和本地存储器18的虚拟包中存在矛盾并且无法构建一个适当的播放列表的情况下，播放控制引擎32会返回一个指示“错误”的响应。

如果在上述工作步骤之后返回一个“成功”响应，那么就向请求播放的应用程序发出一个指示播放PL成功的事件(步骤S55)。如果并未返回一个“成功”响应，那么就向请求播放的应用程序发出一个指示播放PL失败的事件(步骤S56)。另一方面，如果在步骤S52判断出请求播放的应用程序未被授权播放该PL，那么就向请求播放的应用程序发出一个指示无法播放PL的事件(步骤S57)。

如上所述，本实施例使得如果对每个标题都定义了是否可以播放一个播放列表，并且如果某些应用程序被授权可以播放一个播放列表，而其它应用程序不具有这种授权，那么就可以响应于一个应用程序发出的请求从而适当地执行一个播放列表的播放。这使得可以通过组合应用程序的执行和播放列表的播放来提供多种内容表示。

实施例4

在实施例1中我们描述过，通过使我们期望播放的播放列表附加有播放属性“AutoPlay”，可以命令播放装置在启动标题时播放该AutoPlay PL。但是，本实施例涉及一种改进，其中在BD-ROM中记录了一种无边界应用程序，并且当标题启动时，使得该无边界应用程序选择要自动启动的标题。

无边界应用程序是这样一种应用程序：它与播放装置中的常驻应用程序(例如播放控制引擎32)相同，并且响应于该播放控制引擎32发出的请求从而执行一个处理，该处理是从写在播放列表管理表中的多条播放列表信息中选择一条与播放装置侧的PSR设置值相匹配的播放列表信息，并且通知该条被选中的播放列表信息。

为了使无边界应用程序选择一个PL，将播放列表管理表中的关于请求这样一个选择的标题的所有播放属性都设置为“未指定”。这是因为将“所有属性未指定”用作一种触发事件，使得播放控制引擎32请求该无边界应用程序选择一个PL。

无边界应用程序所进行的选择是基于在编写程序期间所定义的选择算法。图48A到48C通过表的形式显示了嵌入到无边界应用程序中的选择算法的内容。该表指示了对应于PL的PSR值的范围，当PSR具有该值时，该PL将被播放。在这些图中，图48A显示了基于母级别的选择算法的内容。在该播放装置中母级别被设置为PSR(13)。更具体地说，将指示用户年龄的一个整数设置在PSR(13)中，并且播放装置将该整数视为母级别。在图48A中，PSR(13)的值可以分为三个范围：小于14；大于等于14并且小于18；以及大于等于18。另外，为这些范围中的每种都指示了一个要被播放的播放列表。因此，基于这样一种选择算法，如果PSR设置值小于14，那么无边界应用程序就选择播放列表#1；如果PSR设置值大于等于14并且小于18，那么无边界应用程序就选择播放列表#2；并且如果PSR设置值大于等于18，那么无边界应用程序就选择播放列表#3。

图48B显示了基于音频语言的选择算法的内容。在播放装置中将音频语言设置到PSR(16)。更具体地说，将一个整数设置在PSR(16)中，并且播放装置认为该整数指定了用于音频播放的语言。在图48B中，PSR(16)的值可以分为三种范围：英语；日语；以及其它。另外，为这些范围中的每种都指示了一个要被播放的播放列表。因此，基于这样一种选择算法，如果PSR(16)设置值指示英语，那么无边界应用程序就选择播放列表#1；如果PSR(16)设置值指示日语，那么无边界应用程序就选择播放列表#2；并且如果PSR(16)设置值指示除英语和日语之外的其它语言，那么无边界应用程序就选择播放列表#3。

图48C显示了基于用于视频的播放器配置的选择算法的内容。在播放装置中将用于视频的播放器配置设置到PSR(14)。更具体地说，将一个整数设置在PSR(14)中，并且播放装置认为该整数指定了用于视频播放的环境。在图48C中，PSR(14)的值可以分为三种范围：分辨率525x600的电视系统信箱；分辨率525x600的电视系统；以及分辨率1920x1080的电视系统。另外，为这些范围中的每种都指示了一个要被播放的播放列表。因此，基于这样一种选择算法，如果PSR(14)设置值指示分辨率525x600的电视系统信箱，那么无边界应用程序就选择播放列表#1；如果PSR(14)设置值指示分辨率525x600的电视系统，那么无边界应用程序就选择播放列表#2；并且如果PSR(14)设置值指示分辨率1920x1080的电视系统，那么无边界应用程序就选择播放列表#3。通过使用一种计算机描述语言描述如图48A到48C所示的条件转移就可以生成如图48A到48C所示的选择算法。

到目前为止，已经描述了本实施例中记录介质的一种改进。接下来将描述本实施例中播放装置的一种改进。该改进主要包含对应用程序管理器36和播放控制引擎32的改进。

当标题之间发生转移时，应用程序管理器36参考播放列表管理表并且判断在该播放列表管理表中是否存在AutoRun PL。如果没有AutoRun PL，那么应用程序管理器36就将该播放列表管理表转移到播放控制引擎32中，并且请求播放控制引擎32自动播放写在该播放列表管理表中的一个PL。

当播放控制引擎32接收到播放列表管理表时，它会请求无边界应用程序选择PL。当播放控制引擎32从无边界应用程序接收到该无边界应用程序响应于该请求从而发送的可播放PL的列表时，它判断在该表中所列出的PL中是否有一个写在从播放项转移而来的播放列表管理表中的PL。并且如果在这些由无边界应用程序选择的PL中有一个写在播放列表管理表中的PL，那么播放控制引擎32就自动播放该PL。

图49显示了标题无边界应用程序选择PL的过程。在图49的左手侧，显示了播放装置中软件的层结构。在图49的右手侧，显示了BD-ROM的内容。在图49中，符号◎1、◎2、◎3、◎4分别代表以下内容：应用程序管理器36发出的在播放列表管理表中没有自动播放的通知(◎1)；播放控制引擎32发出的指示可播放PL的请求(◎2)；标题无边界应用程序对PSR设置值的获取(◎3)；以及标题无边界应用程序向播放控制引擎32发出的关于可播放PL的通知(◎4)。

这里在图49中应该注意到，出于方便的考虑将标题无边界应用程序写到BD-ROM上。因为标题无边界应用程序是一种Java(TM)应用程序，所以更接近于实际情况的描述是：标题无边界应用程序是一种由Java(TM)虚拟机38的工作存储器54中线程55执行的一种实例。

根据上述的本实施例，使得位于标题边界处的一个应用程序做出上述判断。这使得播放装置中的播放控制引擎32在启动一个标题后的较早阶段就可以从记录于BD-ROM上的众多PL中识别这样一个PL：它满足播放装置中设置的条件。这使得即使不预先确定具有“AutoPlay”播放属性的应用程序，也可以在该标题的起始处确定一个要被播放的PL。即使在BD-J模式中也可以实现例如语言信用和母锁定的播放控制。

这里应该注意到，尽管在本实施例中选择算法将PSR值和播放列表联系在一起，但是还可以预先定义当播放装置中的PSR设置值超出假定范围时要被播放的播放列表。

实施例5

在实施例4中，标题无边界应用程序具有一种用于根据PSR设置值选择要被播放的PL的选择算法。本实施例涉及一种改进，其中当一个PL具有多角度周期时，使得标题无边界应用程序可以从该多角度周期包含的多个角度中选择一个角度。本实施例中的标题无边界应用程序将多个PSR值范围与要被播放的角度联系到了一起。在本实施例中，如果当前播放时间点位于一个多角度周期中，那么播放控制引擎32就请求标题无边界应用程序选择一个要被播放的角度。当标题无边界应用程序接收到这样一个请求时，它就获得当前所设置的PSR值，执行一种选择算法，并且选择对应于所获得的设置值的一个角度。标题无边界应用程序向播放控制引擎32通知选择的结果，从而播放控制引擎32播放该选择的角度。

如上所述，根据本实施例，负责编写程序的人可以定义一种用于根据PSR值选择角度的算法。这使得负责编写程序的人可以使用多种角度写出多种应用程序。

实施例6

实施例6涉及实现BD-J模式中PL的播放的同步的一种改进。当调用PlayPLAPI函数时，播放控制引擎32根据PL信息执行工作步骤。如果PL具有两个小时的播放周期，那么上述的工作步骤在这两个小时内就会一直持续。这样所引发的一个问题是，在Java(TM)虚拟机38返回一个响应“成功”的时刻和播放控制引擎32实际上结束该过程的时刻之间存在一段间隙。在一个调用之后，主要用于执行事件驱动过程的Java(TM)虚拟机38立即就返回一个指示成功或失败的响应。但是，因为播放控制引擎32实际上在两个小时之后才结束处理，所以并不能通过一个调用之后立即就被返回的响应“成功”确认该处理的结束。如果在PL播放期间执行了快进、后退或跳读，那么该周期就会从两个小时变为小于或多于两个小时。当出现上述情况时，就更加难以识别处理的结束。

播放控制引擎32独立于应用程序进行工作。因此，应用程序管理器36不能准确地确定PL播放结束的时刻。所以，在本实施例中，无论应用程序是否终止，只要在工作存储器中有一个JMF播放器实例，也就是说只要BD-J模块35被授权对呈现引擎31进行控制，那么就会一直等待由播放控制引擎32发出的通知事件。如果从播放控制引擎32接收到了一个通知事件，那么就可以确定标题已经终止，并且命令模块管理器34转移跳转到下一个标题。通过这样一种安排，可以将播放控制引擎32结束一个PL播放的时刻视为标题终止的时刻。

接下来将参考图50到54中所示流程图，具体描述播放控制引擎32所执行的控制工作步骤。

图50是一个流程图，显示了播放控制引擎32所执行的PL播放的步骤。该播放步骤主要包含对呈现引擎31的控制(步骤S106)和对BD-ROM驱动器1或本地存储器18的控制(步骤S108)。在该流程图中，将处理目标播放项指示为播放项#x。在该流程图中，首先读取当前PL信息(.mpls)(步骤S101)，并且执行步骤S102到S110的过程。步骤S102到S110组成了一种环路处理，其中对于当前PL信息所包含的每条PI信息都重复执行步骤S103到S110，直到在步骤S109中判断为“YES”。在该环路处理中，将处理目标播放项指示为播放项#x(PI#x)。如果当前PL的起始处的播放项设置为播放项#x，那么就对该播放项#x进行初始化(步骤S102)。对于上述环路处理来说，结束的条件是判断出播放项#x是当前PL中的最后播放项(步骤S109)。如果播放项#x不是当前PL中的最后播放项，那么就将当前PL中的下一个播放项设置为播放项#x(步骤S110)。

步骤S103到S110按照如下方式在环路处理中重复执行。将播放项#x的Clip_information_file_name指定的剪辑信息读入到脚本存储器25中(步骤S103)。使用当前剪辑信息的EPmap将播放项#x的In_time转换为一个I图像地址“u”(步骤S104)。使用当前剪辑信息的EPmap将播放项#x的Out_time转换为一个I图像地址“v”(步骤S105)。将I图像地址“v”的下一个I图像地址减1，并将得到的结果地址设置为地址“W”(步骤S107)。命令BD-ROM驱动器1或本地存储器从I图像地址“u”到地址“W”的位置处读取TS包(步骤S108)。

另一方面，命令呈现引擎31输出数据，并且这些数据的范围是从当前PLMark的mark_time_stamp到播放项#x的Out_time(步骤S106)。通过执行步骤S105到S108，可以播放由播放项#x指定的一部分AV剪辑。

在此之后，判断该播放项#x是否为当前PL中的最后播放项(步骤S109)。

如果判断出播放项#x不是当前PL中的最后播放项，那么就将当前PL中的下一个播放项设置为播放项#x(步骤S110)，并且控制返回到步骤S103。重复上述步骤S103到S110从而按顺序播放该PL包含的播放项。

图51是一个流程图，显示了角度改变步骤和用于向回跳读/向下跳读的步骤。该流程图与图50中所示的步骤并行执行，并且重复执行包含步骤S111到S112的环路处理。在该环路的步骤S111中，判断从Java(TM)虚拟机38中是否发出了一个请求角度改变的API。并且如果判断出发出了请求角度改变的API，那么就将当前剪辑信息变为另外一个。

在图51的步骤S115中，判断播放项#x的is_multi_angles是否为“ON”。该is_multi_angles是一种指示播放项#x是否对多角度做好了准备的标记。如果在步骤S115中判断为“NO”，那么控制就转移到步骤S113。如果在步骤S115中判断为“YES”，那么就执行步骤S116到S119。步骤S116到S119是按照以下方式执行的。用变量“y”代替角度改变之后的角度号(步骤S116)。将播放项#x中第“y”个Clip_information_file_name指定的一条剪辑信息读取到脚本存储器21(步骤S117)。使用当前剪辑信息的EP_map将当前PTM转换为一个I图像地址“u”(步骤S118)。使用当前剪辑信息的EP_map将播放项#x的Out_time转换为I图像地址“v”(步骤S119)。在如上面所述改变I图像地址“u”和“v”之后，就停止与本处理同时执行的图50中所示处理，然后控制转移到步骤S106。通过转移到步骤S106，从另一个AV剪辑读取TS包，并且改变了视频内容。

另一方面，在图51的环路中的步骤S112中，判断从Java(TM)虚拟机38中是否调用了一个向回跳读/向下跳读API。并且如果判断出调用了向回跳读/向下跳读API，那么就执行图52的流程图中所示的步骤。图52是一个流程图，显示了当判断出发出了向回跳读/向下跳读API时执行的步骤。可以按照多种方式实现用于执行向回跳读或向下跳读的步骤。因此，应该注意到这里仅描述了一个这样的例子。

在步骤S121，通过对PSR指示的当前PI号和当前PTM进行转换从而获得当前标记信息。在步骤S122，判断按下的键是否为向下跳读或是向回跳读。如果按下的是向下跳读，那么在步骤S123中将方向标记设置为“+1”。如果按下的是向回跳读，那么在步骤S124中将方向标记设置为“-1”。

在步骤S125中，将当前PLMark编号设置为通过将当前PLMark号与方向标记的值相加而得到的数量。这里，如果按下的是向下跳读键，那么就将方向标记设置为“+1”，并且因此当前PLMark增加。如果按下的是向回跳读键，那么就将方向标记设置为“-1”，并且因此当前PLMark减小。

在步骤S126中，将当前PLMark的ref_to_PlayItem_Id中描述的PI设置到播放项#x。在步骤S127，读取播放项#x的Clip_information_file_name指定的剪辑信息。在步骤S128，使用当前剪辑信息的EP_map将当前PLMark的mark_time_stamp转换为一个I图像地址“u”。另一反面，使用当前剪辑信息的EP_map将播放项#x的Out_time转换为一个I图像地址“v”。在步骤S130，命令呈现引擎31输出数据，并且这些数据的范围是从当前PLMark的mark_time_stamp到播放项#x的Out_time。停止与本处理并行执行的图50中所示的处理，并且然后控制转移到图50的步骤S107。通过这种方式，在改变I图像地址“u”和“v”并且命令播放另一部分之后，控制转移到步骤S107。通过转移到步骤S107，从另一个AV剪辑读取TS包，并且改变了视频的内容。

图53是一个流程图，详细显示了呈现引擎31的工作步骤。在该流程图中，将I图像的PTS设置到当前PTM之后(步骤S131)，执行包含步骤S132到步骤S137的环路处理。

接下来将描述包含步骤S132到S137的环路处理。在该环路处理中，反复输出对应于当前PTM的图像和音频并且反复更新当前PTM。在该环路处理中，步骤S136定义了该环路处理结束所必需的条件。也就是说，步骤S136定义了必须要由该环路处理结束当前PTM就是PI#x的Out_time。

在步骤S133，判断Java(TM)虚拟机38是否调用了快退API或快进API。如果判断出调用了快退API或快进API，那么就在步骤S138中判断所调用的API是快进还是快退。如果是快进，那么将下一个I图像的PTS设置到当前PTM(步骤S139)。通过将当前PTM设置到下一个I图像的PTS，可以实现每秒以向前跳读的方式播放AV剪辑。通过这种安排，可以按照两倍速度或其它速度向前播放AV剪辑。如果是快退，那么就判断当前PTM是否已经到达了播放项#x的Out_time(步骤S140)。如果判断出当前PTM未到达播放项#x的Out_time，那么就将前一个I图像的PTS设置到当前PTM(步骤S141)。以这种方式，通过将读取目的地地址A设置到前一个I图像，可以实现每秒以向后跳读的方式播放AV剪辑。通过这种安排，可以按照两倍速度或其它速度向后播放AV剪辑。可以通过多种方式实现快进或快退的步骤。因此，应该注意到这里仅描述了一个这样的例子。

在步骤S134，判断是否调用了菜单调用API。如果判断出调用了菜单调用API，那么就暂停当前播放过程(步骤S142)，并且执行用于菜单过程的菜单程序(步骤S143)。通过该过程，如果执行了菜单调用，那么就可以暂停播放过程，并且执行用于菜单过程的菜单程序。

在步骤S135，判断是否有一个在sync_PlayItem_id中已经为其指定了了播放项#x(PlayItem#x)的子播放项#y(SubPlayItem#y)。如果判断出存在这样一个子播放项#y，那么控制就转移到图54中所示的流程图。图54是一个流程图，它显示了子播放项的工作步骤。在该流程图中，首先在步骤S146中判断当前PTM是否是子PI#y的Sync_start_PTS_of_PlayItem。如果判断出当前PTM是子PI#y的Sync_start_PTS_of_PlayItem，那么控制就转移到步骤S153，并且在该步骤中命令播放控制引擎32执行子播放项#y的播放过程。

如果在步骤S136中判断为“YES”，那么就执行步骤S144和S145。在步骤S144中，判断是否满足下述两个条件：(i)虚拟机文件系统30输出了文件事件的通知结束；以及(ii)解码器输出了解码事件的通知结束。如果上述两个条件都得到满足，那么就将流事件的通知结束输出到播放控制引擎32。

图54中包含步骤S147到S152的流程图显示了基于子播放项#y的工作步骤。

在步骤S147中，读取由子播放项#y的Clip_information_file_name指定的剪辑信息。在步骤S148，使用当前剪辑信息的EP_map将子播放项#y的In_time转换为地址α。在步骤S149，使用当前剪辑信息的EP_map将子播放项#y的Out_time转换为地址β。在步骤S150中，命令解码器输出子播放项的In_time到Out_time。将I图像地址β的下一个I图像地址减1，并且将得到的结果设置到地址γ(步骤S151)。命令BD-ROM驱动器1或本地存储器18从子剪辑#z中地址α到地址γ的位置读取TS包(步骤S152)。

现在，回到图50，我们将继续描述播放控制引擎32的过程。在步骤S19中，判断呈现引擎31是否已经完成了播放控制。步骤S131中将一直判断为“NO”，直到图53的流程图中所示过程执行到最后一个播放项#x。当完成了图53的流程图中所示过程时，在步骤S131中判断为“YES”，并且控制转移到步骤S114。在步骤S114，通知事件将被输出到Java(TM)虚拟机38中。通过该输出，Java(TM)虚拟机38可以识别出播放已经进行了两个小时。

根据上述的本实施例，应用程序管理器36可以识别出播放已经连续进行了两个小时的时刻。这使得应用程序管理器36可以命令Java(TM)虚拟机38执行一个与播放列表的播放的结束同步的处理。

注意事项

上述内容并未对本发明的所有实施例都进行了描述。还可以通过例如实施例(A)、(B)、(C)、(D)等等实现本发明。在本申请的权利要求中定义的本发明是上述实施例的扩展或总结，或者是对上述实施例的修改。这些扩展或总结的程度是基于提交本申请时本发明的技术领域中的技术水平。

在上述所有实施例中，用BD-ROM代表了用于实现本发明的光盘。但是，用于实现本发明的光盘的特征在于记录在光盘上的动态脚本和索引表，并且这些特性并不依赖于BD-ROM的物理特性。因此，任何可以用于记录动态脚本和索引表的记录介质都可应用于本发明。例如，可以使用例如DVD-ROM、DVD-RAM、DVD-RW、DVD-R、DVD+RW、DVD+R、CD-R以及CD-RW的光盘，或者例如PD或MO的磁光盘。另外，本发明还可以使用半导体存储卡，例如闪存(TM)卡(compact flash card)、智能介质(smart media)、记忆棒(memory stick)、多媒体卡(multimedia card)或者PCM-CIA卡。而且，本发明还可以使用(i)磁记录盘，例如软磁盘(flexible disk)、超磁盘(SuperDisk)、Zip或Clik！，或者(ii)可移动硬盘驱动器，例如ORB、Jaz、SparQ、SyJet、EZFley或者微驱动器。进一步，本发明可以使用嵌入到装置中的硬盘。

在所有上述实施例中，播放装置在将记录于BD-ROM上的AV剪辑输出到TV之前先要对这些AV剪辑进行解码。但是，播放装置可能仅包含一个BD-ROM驱动器，而除BD-ROM之外的器件则位于TV中。在这种情况下，可以将播放装置和TV包含到一个家庭网络中，并且通过IEEE 1394将该播放装置和TV连接到该家庭网络中。另外，在上述实施例中，该播放装置是一种由于使用的原因从而要求将其连接到一个TV的类型的播放装置。但是，该播放装置还可以是这样一种类型：其中该播放装置中内置一个显示器。进一步，可以将每个实施例中实现了一种实质性过程的播放装置的一部分视作本发明的播放装置。每个这样的播放装置都是本申请中描述的一种发明。并且因此，基于每个实施例中所示播放装置的内部结构对播放装置所进行的制造，都应该被视作是对本申请中所描述发明的实施。另外，无论是出于营利目的还是免费对每个实施例中所示播放装置进行转移、出租或是引入，都应该被视作是对本发明的实施。进一步，通过直接的显示、产品目录或发行手册等等方式将该播放装置提供、转移或出租给普通用户，也都应该被视作是对本发明的实施。

对于其工作步骤在每个流程图中得到了显示的程序来说，应该将该程序视作一个独立的发明，这是因为如每个流程图中所示，该程序为了对信息进行处理使用了具体的硬件资源。在每个实施例中，为了实现本发明的程序，已经将该程序嵌入到播放装置中。但是，该程序与播放装置之间是可以分离的，并且可以将该程序用作分立实体从而实现每个实施例中所示的独立程序。可以将这种将每个实施例中所示程序分立实体从而实施本发明的方法分为以下几类，例如：(1)制造该程序：(2)出于营利目的或免费对该程序进行转移；(3)出租该程序；(4)引入该程序；(5)通过双向电子通信线路向公众提供该程序；以及(6)通过直接的显示、产品目录或发行手册等等方式将该程序提供、转移或出租给普通用户。

我们认为在每个流程图的步骤中按照时间顺序执行的相关于时间的元素在识别本发明方面起到了实质性的作用。因此，我们还认为流程图中所示工作步骤起到了公开播放方法的使用形式的作用。因此，我们认为按照时间顺序实施流程图的步骤从而实现本发明的目的，实施本发明以及获得本发明的效果，也都是对本发明的实施。

当AV剪辑记录于BD-ROM上时，我们希望给该AV剪辑所包含的每个TS包都附上一个扩展报头。该扩展报头称作TP_extra_header，它包含“Arribval_Time_Stamp”和“copy_permission_indicator”，并且具有四字节的数据长度。将具有TP_extra_header的TS包(此后称作具有EX的TS包)按照32个一组进行分组，并且将其写入到三个段中。这32个具有EX的TS包的一组有6144个字节(＝32x192)。每组的这种尺寸大小正好与这三个段中每个段的尺寸大小相同，其中每个段的尺寸大小也是6144个字节(＝2048x3)。存储于这三个段中这32个具有EX的TS包的一组称作“对准单元”。

当将播放装置200用于一个家庭网络时(其中该装置通过IEEE1394连接到该网络)，该播放装置按照下述传输过程传输该对准单元。也就是说，发射机侧的一台设备将TP_extra_header从对准单元中所含每个具有EX的播放控制引擎32TS包中除去，根据DTCP标准对TS包的每个部分都进行编码，并且输出编码后的TS包。当输出编码后的TS包时，该设备将同步包插入到编码后的TS包。基于TP_extra_header的Arribval_Time_Stamp所指示的时间确定将同步包插入到编码后的TS包中的位置。当输出这些TS包时，播放装置200输出DTCP_Descriptor。该DTCP_Descriptor指示了TP_extra_header中的复制许可/禁止设置。这里，通过描述DTCP_Descriptor从而指示“复制禁止”使得在将播放装置通过IEEE 1394连接到一个家庭网络从而对其进行使用时，其它设备不能记录这些TS包。

在所有上述实施例中，记录于记录介质上的数字流是AV剪辑。但是，该数字流可以是符合DVD视频标准或DVD视频记录标准的VOB(视频对象)。该VOB是通过将视频流以及音频流复用到一起从而获得的程序流，并且该程序流符合ISO/IEC13818-1标准。另外，AV剪辑中的视频流可以符合MPEG4或WMV系统。进一步，音频流可以符合线性PCM系统、杜比AC3系统、MP3系统、MPEG-AAC系统、Dts或WMA(视窗(TM)媒体音频)。

在所有上述实施例中，可以通过对模拟广播所发出的模拟视频信号进行编码从而获得视频作品。另外，视频作品还可以是包含通过数字广播方式发出的传输流的流数据。

另外，还可以通过对存储在视频带上的模拟/数字视频信号进行编码从而获得内容。进一步，还可以通过对直接从摄像机获得的模拟/数字视频信号进行编码从而获得内容。进一步，可以通过发行服务器所进行的发行从而获得数字作品。

BD-J模块35可以是一种嵌入到用于接收卫星广播的设备中的Java(TM)平台。当BD-J模块35是Java(TM)平台时，本发明的播放装置也执行用于MHP的STB所执行的过程。

此外，BD-J模块35可以是一种嵌入到用于执行移动电话的过程控制的设备中的Java(TM)平台。当BD-J模块35是Java(TM)平台时，本发明的播放装置也执行移动电话所执行的过程。

在层模型中，HDMV模式可以位于BD-J模式上。这尤其是因为对HDMV模式中动态脚本进行分析和基于该动态脚本执行控制工作步骤仅使播放装置承担了轻的负载，并且在BD-J模式上执行HDMV模式并不存在任何问题。另外，在播放装置或电影作品的开发过程中，仅通过一种模式就可以保证操作。

此外，可以仅在BD-J模式上执行播放过程。这是因为如实施例5中所示，可以同步于BD-J模式中PL的播放执行播放控制，并且因此不一定要提供HDMV模式。

通过在一种互动图像流中提供导航命令可以实现PL之间的转移，并且其中该互动图像流会被复用到一个AV剪辑中。

在实施例1中，将标题无边界应用程序定义为这样一种标题：它的生存周期延伸到属于一个BD-ROM的所有标题。但是，也可以将标题无边界应用程序定义为这样一种标题：它的生存周期延伸到属于多个BD-ROM的所有标题。

在实施例1中，在生成应用程序管理表时，我们希望将可以同时执行的应用程序数量限制到，例如4或更少。

应该将可以同时执行的应用程序数量限制到例如4或更少的原因如下。有多个配有数字广播调频器功能的BD-ROM播放装置，并且用于实现这种调频器功能的应用程序通常位于存储器中。为了给常驻应用程序提供操作的空间，所以就应该将可以同时执行的应用程序数量限制到，例如4或更少。我们希望在这四个应用程序中，第一个是标题无边界应用程序，第二个是标题无边界程序，并且第三个是章节边界应用程序。

在实施例2中，这样定义错误管理表，从而当一个应用程序异常终止时，会执行一个恢复过程。但是，当一个应用程序异常终止时，可能会执行多个恢复过程。也就是说，当一个应用程序异常终止时，播放装置可以连续执行播放列表的播放、应用程序的重新启动以及事件的输出。

另外，可以这样构建错误管理表从而为每个标题而并不为每个应用程序都定义一个恢复过程。

AV剪辑可以具有一种复用到其中的互动图像流，用于显示菜单和通过该菜单接收互动操作。因此，仅通过描述一个导航命令就可以生成顶级菜单标题，其中该导航命令为了实现显示该顶级菜单和接收互动操作仅需要命令播放电影对象中的一个AV剪辑。

在上述每个实施例中，只是举例说明了目录/文件结构和文件中的数据结构。作为本发明的特征之一的管理信息并不依赖于目录/文件结构和文件中的数据结构。因此，例如，对于作为BD-J模式中一种操作脚本的BD-J对象来说，可以将其作为一个具有标识符“bobj_id”和“BD-J”的文件(zzzzz.BD-J)包含到BDJA目录中，并且可以仅将标识符“bobj_id”存储到BD-J Object.bdmv的BD-JObject[n]()。

工业应用性

个人可以将本发明的记录介质和播放装置可以用于家庭影院系统中。但是，还可以将本发明的记录介质和播放装置应用于工业领域，这是因为它具有在上述实施例中公开的内部结构，并且很明显的是，可以对本发明的记录介质和播放装置进行批量生产。因此，本发明的记录介质和播放装置具有工业应用性。

Claims (3)

1.一种记录方法，用于在记录介质上记录应用程序、数字流、与所述应用程序和数字流有关的标题、以及管理信息，其中所述应用程序是使用编程语言编写的用于虚拟机的程序，

在执行所述记录时指定生存周期，该生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间可以由所述虚拟机执行所述应用程序，以及

所述管理信息包括指示了与所述标题有关的所述数字流的播放控制的信息，在所述生存周期期间，与所述应用程序的执行同时进行所述数字流的播放控制。

2.一种播放装置，包括：

虚拟机单元，用于执行已经从记录介质读入工作存储器的应用程序；

播放控制引擎单元，用于播放记录于所述记录介质上的、并且与记录在所述记录介质中的标题有关的数字流；以及

应用程序管理器，用于当到达所述应用程序的生存周期时，将所述应用程序从所述记录介质读入所述工作存储器并且使所述虚拟机单元执行所述应用程序，以及同时，使所述播放控制引擎单元根据记录于所述记录介质中的管理信息播放与所述标题有关的所述数字流，其中，所述生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间，所述应用程序可以被读入所述虚拟机单元的工作存储器并且可以被所述虚拟机单元执行。

3.一种用于计算机的播放方法，所述计算机包含虚拟机单元以及播放控制引擎单元，所述虚拟机单元用于执行已被从记录介质读入工作存储器的应用程序，所述播放控制引擎单元用于播放记录于所述记录介质上的、并且与记录在所述记录介质中的标题有关的数字流，所述播放方法使所述计算机执行以下所述步骤：

当到达所述应用程序的生存周期时，将所述应用程序从所述记录介质读入所述工作存储器并且使所述虚拟机单元执行所述应用程序，其中，所述生存周期在记录在所述记录介质中的标题的播放周期内，并且在所述生存周期期间，所述应用程序可以被读入所述虚拟机单元的工作存储器并且可以被所述虚拟机单元执行，并且同时

使所述播放控制引擎单元根据记录于所述记录介质上的管理信息播放与所述标题有关的所述数字流。

Images