CN1867999B - Recording method, reproducing device, reproducing method - Google Patents

Abstract

BD-ROMs store multiple branchable titles and Java applications. Java applications are programs written in an application language for virtual machines, with a predefined lifecycle for virtual machine execution. Each title includes an application management table that lists applications with a lifecycle defined for each title.

Description

Recording method, reproducing device, reproducing method

technical field

The present invention belongs to the technical field of playback control technology that simultaneously executes the playback of digitized video and the execution of application programs, and further relates to the case where the playback control technology is applied to recording media, consumer playback devices, and programs. Application Technology. the

Background technique

In the video business using recording media, there is a sales strategy in which digitized video works and applications for online purchase are simultaneously recorded on recording media and sold. The producer has a planning point of view as to whether it is possible to incorporate the structure of character goods related to online sales of video works on one recording medium, and to increase the sales of character goods through the synergistic effect of video works and applications. It is desired that an application program execution environment with a higher degree of freedom be equipped on recording media and playback devices that will appear in the future every time this content is realized. the

Here, in order to realize the simultaneous execution of the digitized video work and the application for online shopping, a technique for operating the application in response to playback of the digital video is required. "Signalling" of the DVB-MHP standard is known as a technique for operating a Java application based on reproduction of a digital stream. The so-called signaling is to define the time when the application should be started and the time to be terminated in the playback time axis of the digital stream, and send information called AIT (application Information Table) at this time, so that the playback device performs an application based on the AIT. control. the

However, the playback progress of the disc content can be performed in the reverse direction of the playback time axis. By retrograde I mean going backwards by rewinding the timeline. When the application program is to be started and terminated several times before and after the time when the application program should be terminated, the reverse movement and forward movement are repeated several times, loading and erasing to the working memory are performed several times, and an unnecessary read load is generated. the

Contents of the invention

It is an object of the present invention to provide a playback device capable of avoiding an unnecessary read load even if there is a playback backtracking on the playback time axis. the

The above object is achieved by the recording method. In the recording method, an index table, an application program, and an action mode object are recorded in the recording medium, the index table represents the corresponding relationship between the title and the action mode object, the action mode object includes an application program management table, and the application program is a virtual machine-oriented In the program described in the programming language, the application program management indicates one or more application programs whose life span is the title corresponding to the operation mode object. the

The reproducing device of the present invention executes an application program whose life span is the corresponding title in the recording medium, and is characterized in that it includes: a module manager that selects a title to be a branch target title from a plurality of titles based on an index table, and the module , for executing an application program; an index table, an application program, and an action mode object are recorded in the recording medium, the index table represents the correspondence between the title and the action mode object, and the action mode object includes an application program management table, The application program is a program described in a programming language oriented to a virtual machine, the application program management represents one or more application programs with corresponding titles as life spans, the module has an application program manager, and the application program When the program manager selects the branch target title, it refers to the application program management table to determine whether there is an application whose life range is the title corresponding to the branch target title, and only if there is an application program whose life range is the corresponding title , start the application. the

Description of drawings

The reproducing method of the present invention executes an application program that uses the corresponding title as the live area in the recording medium, and is characterized in that it includes: a management step of selecting a title to be a branch target title from a plurality of titles based on an index table; and a module Step, for executing the application program, an index table, an application program and an action mode object are recorded in the recording medium, the index table represents the corresponding relationship between the title and the action mode object, and the action mode object includes the application program management table , the application program is a program described in a programming language oriented to a virtual machine, the application program management represents more than one application program with the corresponding title as the survival interval, and the module step selects the branch target title In this case, the application management table is referred to to determine whether there is an application whose live range is the title corresponding to the branch target title, and only if there is an application whose live range is the corresponding title, the application is started. the

A title is composed of a time axis and a control procedure. Since branching from title to title is specified by a branch instruction, even if rewinding occurs within the time axis in one title, for example, the branch source title before the branch execution based on the branch instruction Before, reproduction was not retrograde. A title is a "retrograde unit that cannot be played back", and if the life span of the application program is defined based on this title, loading and erasing to the work memory will not be repeated several times. Since the repetition of reading and discarding is not performed, it is possible to avoid generation of redundant reading load. the

Fig. 1 is a diagram showing the usage behavior of the playback device of the present invention;

Fig. 2 is a diagram showing the file/directory structure in the BD-ROM;

Figure 3 is a diagram representing the relationship between the AVClip time axis and the PL time axis;

Figure 4 is a diagram representing the unified specification through 4 Clip_Information_file_name;

Figure 5 is a diagram representing chapter definitions based on PLmark;

FIG. 6 is a diagram showing the definition and synchronization designation of playback intervals on the SubPlayItem time axis;

Figure 7 (a) is a diagram representing the internal structure of the Movie object;

Figure 7(b) is a diagram representing the internal structure of a BD-J object;

Figure 7(c) is a diagram representing the internal structure of a Java application;

Figure 8 (a) is a diagram representing programs and data contained in the Java archive;

Fig. 8 (b) is a diagram showing an example of an xlet program;

Figure 9(a) is a diagram representing a series of titles of the top menu, title#1, title#2;

FIG. 9(b) is a diagram showing a time axis in which the time axes of PlayList#1 and PlayList#2 match;

Fig. 10 is a figure representing the content of the disk containing three titles of main title, online shopping title and game title;

Fig. 11 is a diagram showing an example of reproduced images of the three titles shown in Fig. 10;

Fig. 12 (a) is a graph of the survival interval of each application program according to the affiliation shown by the dotted line in Fig. 10;

Figure 12(b) is a diagram of an example of the application management table described for specifying the life span of Figure 12(a);

Figure 13 (a) is a diagram showing an example of startup attribute setting;

Figure 13(b) is a diagram showing an application program (application#2) that starts to start due to an application program call from another application program;

Figure 14 (a), (b) is a diagram showing an example of a meaningful application management table and life span for suspend (Suspend);

Figure 15 is a diagram showing the possible combinations of the three forms (Persistent, AutoRun, Suspend) of the start attribute and the three forms of the application state (non-start, start, suspend) in the previous title;

Fig. 16 is a diagram showing the internal structure of the playback device of the present invention;

Fig. 17 (a) is a diagram showing how to identify the Java application program existing on the BD-ROM on the local storage 29;

Figure 17(b) is a diagram representing the application of Figure 17(a);

Fig. 18 is a diagram described by substituting components composed of software and hardware stored in the ROM 24 into a layer structure;

FIG. 19 is a schematic diagram of the processing by the presentation engine 31 to the module manager 34;

FIG. 20 is a diagram that models the situation based on the processing of the application manager 36;

Fig. 21 is the figure that shows working memory 37～default operation manager 40;

Fig. 22 is a diagram showing the control process when branching based on the application program manager 36;

Fig. 23 is a flowchart representing the processing procedure of application program termination processing;

Fig. 24 is a diagram showing the process of application program termination;

FIG. 25(a) is a diagram representing an application management table defining a life span on a PL time axis;

Figure 25(b) is a diagram representing the life span of the application program according to the application program management table in Figure 25(a);

Figure 26(a) shows the title time axis set based on the PL time axis;

Figure 26(b) shows the title timeline determined based on the life span of the main application;

Fig. 26(c) is a diagram showing a title time axis based on the life interval setting of a plurality of applications;

FIG. 27 is a flow chart showing the processing procedure of the application manager 36 during title reproduction;

Fig. 28 (a) is a figure representing the menu level realized by BD-ROM;

Figure 28(b) is a diagram representing a MOVIE object for implementing a menu hierarchy;

Fig. 29 is a schematic diagram of the index table and the situation of branching from the index table to each Movie object;

Fig. 30 (a) represents the branch under the situation that described index table as Fig. 29 (b);

Fig. 30(b) is a diagram showing a branch when a non-AV title is forcibly terminated;

Fig. 31 is a flowchart representing the processing procedure of the module manager 34;

FIG. 32 is a diagram showing an example of an operation of forced termination of an application by the application manager 36;

FIG. 33 is a flowchart showing the PL reproduction process based on the playback control engine 32;

Figure 34 is a flow chart representing the receiving process of angle switching, Skip Back, and Skip Next;

Figure 35 is a flow chart showing the processing procedure when Skip Back and Skip NextAPI are called;

FIG. 36 is a flow chart showing the details of the processing procedure based on the presentation engine 31;

Fig. 37 is a flowchart representing the reproduction process of SubPlayItem;

FIG. 38 is a flowchart showing the processing procedure of the application program manager 36 of the fifth embodiment;

Fig. 39 is a diagram showing an example of a data management table;

Figure 40 is a diagram representing an execution module assumed by a BD-J object;

Fig. 41 (a) is the figure that shows the survival interval that the Java archive file in the local memory 29 lives;

Fig. 41(b) is a diagram showing a data management table described for specifying the life span of the Java archive file in Fig. 41(a);

Figure 42 is a diagram representing Java archive file embedding based on a carousel method;

Figure 43(a) is a diagram showing AVClip embedding based on the interleave method;

Figure 43(b) is a diagram representing three types of read-in attributes;

FIG. 44(a) is a diagram showing an example of a data management table;

Fig. 44(b) is a diagram showing transition of storage contents of the local memory 29 allocated based on the data management table of Fig. 44(a);

FIG. 45(a) is a diagram showing a comparison of the memory sizes of the local memory 29 in the old and new playback devices;

Fig. 45(b) is a diagram showing an example of a data management table in which the read-in priority is set;

Fig. 46 is a figure showing the processing procedure based on the preloading control of the application program manager 36;

FIG. 47(a) is a diagram showing an example of a data management table defining applications whose application IDs are the same but whose reading priorities are different from each other;

Fig. 47 (b) is the change figure of the stored content of the local storage 29 based on the distribution of the data management table of Fig. 47 (a);

FIG. 48(a) is a diagram showing an example of a data management table described as adding the same applicationID to the application program to be preloaded and the application program to be loaded;

FIG. 48(b) is a diagram showing changes in storage contents of the local storage 29 in a playback device with a small memory scale;

FIG. 48(c) is a diagram showing changes in storage contents of the local storage 29 in a playback device with a large memory scale;

FIG. 49 is a diagram showing a processing procedure of loading processing by the application manager 36 based on the data management table;

FIG. 50 is a diagram showing the processing procedure of the application program manager 36 when the current playback time reaches the life span of the application program q;

FIG. 51 is a schematic diagram of how to load an application program based on the Java virtual machine 38;

Fig. 52(a) is a diagram showing the internal structure of the BD-J object of the seventh embodiment;

FIG. 52(b) is a diagram showing an example of a playlist management table;

FIG. 52(c) is a diagram showing what kind of processing the playback device performs when there is a PL whose playback attribute is set to AutoPlay in the playlist management table of the branch target title;

Fig. 53(a) is a diagram showing a title time axis in a non-AV title when the playback attribute is set to indicate non-automatic playback;

FIG. 53(b) is a diagram showing a title time axis of a non-AV title whose playback attribute is set to AutoPlay;

FIG. 53(c) is a diagram showing a situation where the application program is forcibly terminated by setting the playback attribute expression "AutoPlay" in the playlist management table;

Fig. 53(d) is a diagram showing a case where the main application fails to start when the playback attribute is set to "AutoPlay" in the playlist management table;

FIG. 54 is a diagram showing the processing procedure of the application program manager 36 of the seventh embodiment;

FIG. 55 is a schematic diagram showing what kind of playback is performed by setting "playback attribute = AutoPlay" in the playlist management table;

Figure 56 (a), (b) is a diagram representing the relationship between the processing of the application program and the startup attribute;

FIG. 57 is a schematic diagram of how to load an application program based on the Java virtual machine 38 of the eighth embodiment;

Figure 58 (a), (b) is a figure showing an example of the reading priority of the ninth embodiment;

Fig. 59(a) is a diagram showing a data management table to which a group attribute is added;

FIG. 59(b) is a diagram showing access to the local storage 29 based on the application management table;

Fig. 60 is a diagram showing changes in allocation units of the application management table. the

Detailed ways

(first embodiment)

Next, an embodiment of the playback device of the present invention will be described. First, in the embodiment of the playback device of the present invention, an action mode is used. FIG. 1 is a diagram showing usage behavior of the playback device of the present invention. In FIG. 1 , the playback device of the present invention is a playback device 200 , which forms a home theater system together with a television 300 and a remote controller 400 . the

This BD-ROM 100 is used to supply video content to a home theater system formed by the playback device 200 , the remote controller 300 , and the television 400 . the

The above is the description of the mode of use of the playback device of the present invention. the

Next, a recording medium BD-ROM to be played back by the playback device of the present invention will be described. With the BD-ROM, the disc content supplied to the home theater system consists of a plurality of titles that can be branched from each other. Each title consists of one or more playlists and a dynamic control process using the playlists. the

A playlist is composed of one or more digital streams and playback paths in the digital streams, and is an access unit on the BD-ROM having the concept of a "time axis". Since the above-mentioned playlist and dynamic control process are included, the title has both the concept of the unique time axis of the digital stream and the nature of the computer program. the

Fig. 2 is a diagram showing a file/directory structure in a BD-ROM. In this figure, the BD-ROM has a BDMV directory under the root directory. the

In the BDMV directory, there are files with the extension bdmv (index.bdmv, MovieObject.bdmv) and files with the extension BD-J (00001.BD-J, 00002.BD-J, 00003.BD-J) . Further, four subdirectories called PLAYLIST directory, CLIPINF directory, STREAM directory, and BDAR directory exist under the BDMV directory. the

In the PLAYLIST directory there are files with the extension mpls added (00001.mpls, 00002.mpls, 00003.mpls). the

In the CLIPINF directory, there are files with the extension clpi added (00001.clpi, 00002.clpi, 00003.clpi). the

There are files (00001.m2ts, 00002.m2ts, 00003.m2ts) with the extension m2ts added in the STREAM directory. the

There are files (00001.jar, 00002.jar, 00003.jar) with the extension jar added in the BDAR directory. It can be seen that from the above directory structure, a plurality of files of different categories are arranged on the BD-ROM. the

In this figure, files (00001.m2ts, 00002.m2ts, 00003.m2ts...) to which the extension m2ts is added store AVClips. AVClip has MainClip and SubClip categories. MainClip is a digital stream obtained by multiplexing multiple element streams such as video streams, audio streams, presentation graphics streams, and interactive graphics streams. the

SubClip is a digital stream equivalent to only one element stream, such as an audio stream, a graphics stream, and a text subtitle stream. the

The files (00001.clpi, 00002.clpi, 00003.clpi, . . . ) to which the extension "clpi" is added are management information corresponding to AVClips one-to-one, respectively. Since it is management information, the Clip information includes information such as the encoding format, frame rate, bit rate, and resolution of the stream in the AVClip, and EP_map indicating the position of the cue. the

The files (00001.mpls, 00002.mpls, 00003.mpls...) to which the extension "mpls" is added are files storing playlist information. The playlist information is information for defining a playlist with reference to an AVClip. The PlayList is composed of MainPath information, PLMark information, and SubPath information. the

MainPath information is composed of a plurality of PlayItem information. The PlayItem refers to a playback section defined by specifying In_Time and Out_Time on the time axis of one or more AVClips. By arranging a plurality of PlayItem information, a playlist (PL) composed of a plurality of playback sections is defined. FIG. 3 is a diagram showing the relationship between AVClip and PL. The first level represents the time axis that AVClip has, and the second level represents the time axis that PL has. The PL information includes three PlayItem information of PlayItem#1, #2, and #3, and three playback intervals are defined by In_Time and Out_Time of these PlayItem#1, #2, and #3. Arranging these playback sections defines a time axis different from the AVClip time axis. It is the PL time axis represented by the second level. Thus, by defining PlayItem information, it is possible to define a time axis different from that of AVClip. the

In principle, one AVClip can be specified, but multiple AVClips can also be specified collectively. This unified designation is performed by a plurality of Clip_Information_file_names in the PlayItem information. FIG. 4 is a diagram showing collective designation by four Clip_Information_file_names. In the figure, the first to fourth levels represent four AVClip time axes (the time axes of AVClip #1, #2, #3, and #4), and the fifth level represents the PL time axis. These four time axes are specified by four Clip_Information_file_names that PlayItem information has. In this way, four playback sections that can be played back alternatively are defined by the In_Time and Out_Time of the PlayItem. As a result, a section (so-called multi-angle section) consisting of switchable multiple-angle videos is defined on the PL time axis. the

The PLmark information is information for specifying an arbitrary section on the PL time axis as a chapter. FIG. 5 is a diagram showing chapter definitions based on PLmark. In this figure, the first level represents the AVClip time axis, and the second level represents the PL time axis. The arrows pk1 and 2 in the figure represent the PlayItem designation (ref_to_PlayItem_Id) and the designation of a moment (mark_time_stamp) in PLmark. Three chapters (Chapter #1, #2, #3) are defined on the PL time axis by these designations. the

SubPath information is composed of a plurality of SubPlayItem information. The SubPlayItem information defines a playback section by designating In_Time and Out_Time on the time axis of the SubClip. In addition, the SubPlayItem information can specify synchronization to synchronize playback sections on the SubClip time axis with the PL time axis, and the PL time axis and the SubPlayItem information time axis can be synchronized by this synchronization specification. FIG. 6 is a diagram showing definition of playback intervals and designation of synchronization on the time axis of a SubPlayItem. In the figure, the first level represents the PL time axis, and the second level represents the SubPlayItem time axis. In the figure, SubPlayItem.IN_time indicates the start point of the playback section, and SubPlayItem.Out_time indicates the end point of the playback section. From this, it can be seen that playback intervals are also defined on the SubCLip time axis. The Sync_PlayItem_Id in the arrow Sn1 indicates the synchronization specification for the PlayItem, and the sync_start_PTS_of_PlayItem in the arrow Sn2 indicates the specification of a moment on the PlayItem in the PL time axis. the

It is possible to define a multi-angle section in which a plurality of AVClips can be switched, and a synchronization section in which AVClip-SubClips can be synchronized, which is a characteristic of playlist information in a BD-ROM. The above Clip information and playback information are classified into "static scenario (scenario)". This is because the PL, which is a unit of still playback, is defined by the above Clip information and PlayList information. This concludes the description of the static script. the

Next, the "dynamic scenario" will be described. The term "dynamic scenario" refers to scenario data that dynamically defines playback control of an AVClip. The so-called "dynamic" refers to the change of the state of the playback device and the content change of the playback control from the user's key event. In the BD-ROM, two modes are assumed as the operation environment of this playback control. The first is an operating environment very similar to that of a DVD playback device, and is an execution environment of a command library. The second is the operating environment of the Java virtual machine. The first of these two motion environments is called HDMV mode, and the second is called BD-J mode. Since there are these two action environments, one of the action environments is assumed to describe the dynamic script. A dynamic scenario assuming the HDMV mode is called a Movie object, and is defined by management information. On the other hand, a dynamic scenario assuming the BD-J mode is called a BD-J object. the

First, let's describe the Movie object. the

<Movie object>

The Movie object is a constituent element of the "title" and is stored in the file MovieObject.bdmv. Fig. 7(a) is a diagram showing the internal structure of the Movie object. A Movie object is composed of a command string including attribute information and a plurality of navigation commands. the

Attribute information includes: on the PL timeline, when a MenuCall (menu call) is performed, information indicating whether to restart playback after the MenuCall (resume_intention_flag); on the PL timeline, information indicating whether to mask the MenuCall (menu_call_mask) ; and the information (title_search_flag) indicating whether to shield the title search. A Movie object can have both properties of "time axis" and "program control", so that various titles such as a title that executes main playback can be described through this Movie object. the

The navigation command sequence is composed of a command sequence for realizing conditional branching, setting of a status register in the playback device, acquisition of a set value of the status register, and the like. The commands that can be described in the Movie object are shown below. the

PlayPL instruction

Format: PlayPL(first argument, second argument)

The first argument is the number of the playlist, and the PL to be played back can be specified. The second argument can specify the playback start position using PlayItem included in the PL and arbitrary time, Chapter, and Mark in the PL. the

The PlayPL function for specifying the playback start position on the PL time axis with PlayItem is called PlayPLatPlayItem();

The PlayPL function for specifying the playback start position on the PL time axis by Chapter is called PlayPLatChapter();

The PlayPL function for specifying the playback start position on the PL time axis using time information is called PlayPLatSpecifiedTime(). the

JMP instruction

Format: JMP Argument

The JMP command discards (discards) the current dynamic script on the way, and executes a branch of the branch target dynamic script as an argument. The form of the JMP instruction has a direct reference form that directly specifies the branch target dynamic script and an indirect reference form that indirectly specifies the branch target dynamic script. the

Since the description of the navigation command in the Movie object is very similar to the description method of the navigation command in the DVD, the operation of migrating the disc content on the DVD to the BD-ROM can be performed efficiently. For the Movie object, there is a prior art described in the following International Publication. For details, refer to the International Publication Gazette. the

International Publication Gazette WO2004/074976

This concludes the above description of the Movie object. Next, the BD-J object will be described. the

<BD-J object>

Files (00001.BD-J, 00002.BD-J, 00003.BD-J) to which the extension BD-J is added constitute a BD-J object. The BD-J object is a dynamic script of the BD-J mode described in the Java programming environment. Fig. 7(b) is a diagram showing the internal structure of a BD-J object. As shown in the figure, the BD-J object is composed of the same attribute information and application management table as the Movie object. A BD-J object is almost the same as a Movie object in having attribute information. Unlike Movie objects, BD-J objects do not directly describe commands. That is, in the Movie object, the control process is directly described by the navigation instruction. On the other hand, in the BD-J object, the control procedure is indirectly specified by defining the Java application whose lifespan is defined in the title in the application management table. Through such indirect specification, it is possible to effectively commonize the control procedure in which the control procedure is shared among a plurality of titles. the

FIG. 7(c) is a diagram showing an internal structure of a Java application. In this figure, an application program is composed of one or more xlet programs loaded in a heap area (also referred to as a work memory) of a virtual machine. In this work memory, one or more threads operate, and an application program is composed of an xlet program and a thread loaded in the work memory. The above is the composition of the application program. the

What corresponds to the substance of this application program are Java archive files (00001.jar, 00002.jar) stored in the BDAR directory under the BDMV directory. Next, the Java archive file will be described. the

Java archive files (00001.jar, 00002.jar) are Java archive files that store programs and data constituting Java applications. Fig. 8(a) is a diagram showing programs and data contained in an archive file. The data in this figure is organized into a plurality of files configured with the directory structure shown in the box by java archiving. The directory structure shown in the box consists of root directory, java directory, and image directory. Configure common.pkg in the root directory, configure aaa.class and bbb.class in the java directory, and configure menu.jpg in the image directory. The java archive file is obtained by organizing these through the java archive. These data are decompressed every time they are read from the BD-ROM to the cache, and are handled as a plurality of files arranged in a directory on the cache. The 5-digit value of "xxxxx" in the file name of the Java archive file indicates an application ID (applicationID). When reading this Java archive file into the cache, the program and data constituting an arbitrary Java application can be taken out by referring to the numerical value in the file name. the

The xlet program is included in one file in the Java archive. the

The Xlet program is a Java program that can use the JMF (Java Media Frame Work) interface. The Xlet program is composed of a plurality of functions such as EventListner that receives a key event, and performs processing based on the received key event in accordance with a method such as JMF. the

Fig. 8(b) is a diagram showing an example of an xlet program. JMF A "BD://00001.mpls" is a method for instructing the Java virtual machine to generate a player instance (player instance) for reproducing PL. A.play is a method to instruct playback to the JMF player instance. The JMF player instance is generated based on a JMF library (library). The description of the Xlet program is not limited to the PL of the BD-ROM, but is a description of the JMF applicable to the entire content having a time axis. Since this kind of description is possible, software that is good at Java programming can be urged to create a BD-J object. the

JumpTitle() in Figure 8(b) is the call of the application program API. This application API instructs the playback device to branch to another title (title#1 in the figure). The term "application API" here refers to an API (Application Interface) provided by the BD-ROM playback device. In addition to the JumpTitle command, by calling the application program API, processing specific to the BD-ROM playback device can be described in the xlet program. the

In the BD-J mode, PL playback is specified through the JMF interface. Since the PL time axis is defined by this JMF player instance, the title time axis is defined by the title having the JMF player instance. In addition, in the BD-J mode, branching from title to title is specified by calling the JumpTitle API. Since the JumpTitleAPI call can be said to be a call to specify the end time of the title, an application having such a JMF player instance and the JumpTitleAPI call specifies the start and end of the title in the BD-J mode. This application is referred to as a main reproduction application. the

This concludes the description of the dynamic scenario in the BD-J mode. A title that combines PL playback and program control is defined by the dynamic scenario in the BD-J mode. In addition, in this embodiment, the program and data constituting the application program are organized into a Java archive file, but it may be an LZH file or a zip file. the

<Title Timeline> 

After the description of the static scenario and the dynamic scenario constituting the title is completed, what kind of time axis is defined by these will be described. The time axis defined by the title is called "title time axis". The so-called title timeline is constituted by the PL commanded for playback by the Movie object or the BD-J object. An example here is a title as shown in FIG. 9( a ). The title is a series of titles of top menu→title#1→title#2→top menu, top menu→title#3→top menu. Among these titles, if title#1 instructs playback of PlayList#1 and PlayList#2, title#2 instructs playback of PlayList#3, and title#3 instructs playback of PlayList#4, as shown in FIG. 9(b), title# 1 has a time axis in which the time axes of PlayList#1 and PlayList#2 are added. Similarly, title#2 has a time axis composed of a PlayList#3 time axis, and PlayList#3 has a time axis composed of a PlayList#4 time axis. Seamless reproduction is guaranteed on the PL timeline of these title timelines, but seamless reproduction does not need to be guaranteed between title timelines. It is necessary to define a period (service period) during which the Java application can exist in the work memory of the virtual machine on such a title time axis every time the Java application operates. In the BD-J mode, each time a Java application operates, it is necessary to define a service period of the Java application on a time axis branching from each other. The definition of this service period is a point of attention every time programming for BD-J is performed. the

Finally, the IndexTabel stored in index.bdmv is described. The IndexTable is a table that associates title numbers, Movie objects, and BD-J objects, and is an indirect reference table referred to when branching from dynamic scenarios to dynamic scenarios. IndexTable consists of Indexes for multiple tags. Each Index describes the identifier of the dynamic scenario corresponding to the tag. By referring to such an IndexTable, branching can be realized without strictly distinguishing between a Movie object and a BD-J object. The details of the IndexTable are described in the following International Publication Gazette. For details refer to the bulletin. the

International Open Gazette WO2004/025651A1 Gazette

This concludes the description of the files recorded on the BD-ROM. the

<application management table>

An application having a JMF player instance and calling JumpTitleAPI defines the title timeline as above, but when operating another application that does not have a JMF player instance and calling JumpTitleAPI on the title timeline, specify the timeline from the timeline The "service start point and end point" where the application-based service starts and where in the time axis the application-based service ends is important. In the present embodiment, the period from the start of the application-based service to its termination is defined as "the life of the application". Information for defining the existence of an application exists in the application management table of the BD-J object. The application management table will be described in more detail later. the

The application management table (AMT) is information indicating the applications that can exist in the work memory of the virtual machine in the title time axis of each title. Existence in the work memory refers to a state where the xlet program constituting the application program can be read out to the work memory and executed by a virtual machine. The dotted arrow at1 in FIG. 7(b) closes up the internal structure of the application management table. As shown in this internal structure, the application management table is composed of a "living period", an "applicationID" indicating an application having the title as a living period, and an "activation attribute" of the application. the

In the near future, the content of the disc to be implemented will be selected as the subject matter, and a specific example will be used to explain the life range description in the application program management table. Here, the disc content as the subject includes three different characteristics, namely, the main title (title#1) constituting the main video, the online shopping title (title#2) constituting the online shopping, and the game title (title#3) constituting the game application. title. FIG. 10 is a diagram showing disc contents including three titles: a main title, an online shopping title, and a game title. In this figure, the IndexTable is depicted on the right and three headers are depicted on the left. the

The dotted boxes on the right indicate the affiliation of which title each application belongs to. Among the three titles, title#1 consists of three applications: application#1, application#2, and application#3. title#2 contains application#3 and application#4, and title#3 contains application#5. FIG. 11 is a diagram showing an example of reproduced images of the three titles shown in FIG. 10 . In the reproduced images of these three titles, there is a shopping cart-based video (car cr1)1 on the main title and online shopping title in Fig. 11(a), (b), and the game in Fig. 11(c) There is no car image on the title. Since the car cr1 needs to be publicly displayed in the main title and the online shopping title, application#3 as a car application is started in both title#1 and title#2. In addition to the above-mentioned car application, the applications activated by such multiple titles also have menu display by imitating the MASCOT (Automated Process Computer Operations Test) proxy application and menu call operation that appear in video works. menu application. the

When the life span of each application is graphed based on the membership relationship shown by the dotted line in FIG. 10 , it will be as shown in FIG. 12( a ). In this figure, the horizontal axis represents the title time axis, and the life span of each application is arranged in the direction of the vertical axis. Here, since application#1 and application#2 only belong to title#1, these survival intervals remain in title#1. Since application#4 only belongs to title#2, its survival range only stays within title#2. Since application#5 only belongs to title#3, its survival range only stays within title#3. Since application#3 belongs to title#1 and title#2, its survival interval passes through title#1-title#2. If the application management table is described according to the survival interval, the application management tables of title#1, #2, and #3 become as shown in FIG. 12(b). When the application management table is described in this way, application#1, application#2, and application#3 are loaded in the work memory when playback of title#1 starts. And, when title#2 starts, application#1 and application#2 are deleted from the work memory, and only application#3 is set as the control. Similarly, when title#2 starts, application#4 is loaded into the work memory, and when title#3 starts, application#3 and application#4 are deleted from the work memory. the

Furthermore, during playback of title#3, application#5 is loaded into the work memory, and when the playback of title#3 is terminated, application#5 is deleted from the work memory. the

When there is a branch between titles, the application program that exists between the branch source and the branch target is stored in the work memory, and the application program that exists only in the branch target and not in the branch source can be read into the work memory. Therefore, the number of times the application program is read into the work memory is the necessary minimum number of times. In this way, by reducing the number of reads, an application that does not recognize the boundaries of titles, that is, an application without boundaries can be realized. the

Next, the startup properties of the application will be described. The startup attributes include "AutoRun" for automatic startup, "Persistent" for objects that are not automatically started, but can also be placed on the working memory of the virtual machine. Although they are placed on the working memory of the virtual machine, CPU functions cannot be performed. "Suspend" of the assigned rate. the

"AutoRun" reads the application program into the work memory together with the branch of the corresponding title, and indicates the lifetime of the content to be executed. If there is a branch from a certain title to other titles, the management entity (application manager) that performs application management will exist in the branch target title, and the application whose startup attribute is set to AutoRun will work on the virtual machine Read from memory for execution. Thus, the application starts automatically with the title branch. Examples of applications that set the startup attribute to AutoRun include applications that have JMF player instances and JumpTitle API calls. This is because such an application is an application for specifying the title time axis, and unless such an application is automatically activated, the concept of the title time axis becomes unclear. the

The startup attribute "Persisten" is a continuation attribute indicating that the state of the application in the source header of the continuation branch is continued. In addition, it is an attribute indicating that it can also be loaded in the work memory. In the case where the startup attribute is "Persistent", the application to which the startup attribute is added allows calls from other applications. When the management subject (application manager) that manages the application program is invoked from the application program being started, the application ID of the application program is described in the application program management table, and it is judged whether the startup attribute is "Persistent". If "Persistent", the application is loaded in the work memory. On the other hand, in the case where the application ID of the calling target application is not described on the application management table, the application is not loaded in the work memory. Application-based calls are limited to applications that have this "Persistent" added. the

Since "Persistent" is the default startup attribute added without explicitly specifying the startup attribute, if the startup attribute of an application is not specified "——", it refers to the startup attribute of the application is the Persistent. the

Describe how these startup attributes are represented in the application in Figure 11. FIG. 13 is an example of setting the activation attributes for the three application programs in FIG. 12 . Among the three applications shown in FIG. 12, application#2 is an application called from another application and starts to start, as shown in FIG. 13(b). The remaining application#1 and application#3 are applications that are automatically started simultaneously with the start of title#1. In this case, as shown in FIG. 13( a ), the startup attributes application#1 and application#3 in the application management table are set to "AutoRun", and application#2 is set to "Persistent". At this time, application#1 and application#3 are automatically loaded and executed in the work memory when branching to title#1. On the other hand, since the startup attribute of application#2 is "Persistent", it is interpreted as a negative meaning of "application#3 is an application program that can be loaded on the work memory of the virtual machine". Therefore, application#2 is loaded and executed on the working memory of the virtual machine when there is a call from application#1. With the above-mentioned lifetime and startup attributes, the number of applications that can operate on the virtual machine can be limited to 4 or less, and the total number of threads can be limited to 64 or less, so stable operation of applications can be guaranteed. the

Next, Suspend will be explained. the

The so-called Suspend refers to the situation where the application is placed in a state where resources are allocated but CPU power is not allocated. This Suspend is useful for processing that passes through a side pass during the execution of a game title, for example. 14(a)(b) are diagrams showing examples where Suspend is meaningful. As shown in Figure 14(b), there are three titles (title#1, title#2, title#3), among which title#1 and title#3 execute the game application, but the title#2 in the middle is a bypass, use for video reproduction. In the bypass, the execution of the game is interrupted due to the need to realize video reproduction. Since the score in the process is counted in the game application, it is necessary to maintain the storage of resources before and after title#2. At this time, the application management table is described so that the game application is suspended at the start time of title#2, and application#2 is restarted at the start time of title#3. Thus, since application#2 allocates resources in title#2, the storage of resources is maintained. However, since the CPU power is not allocated, application#2 will not be executed by the virtual machine. Thereby, in the execution of the game title, execution bypass processing is realized. the

FIG. 15 is a diagram showing possible combinations of the three possible modes of activation attributes (Persistent, AutoRun, Suspend) and the three modes of the application state (non-starting, running, and Suspend) in the immediately preceding title. If the startup attribute is "AutoRun" when the most recent previous state is "non-start", the application is started in the branch target title. the

If the previous state is "non-starting" and the startup attribute is "Persistent" or "Suspend", then the application program in the branch target title does not do anything and continues the state. the

When the most recent state is "starting", if the start attribute is "Persistent" or "Suspend", the application in the branch target title does not do anything and continues the state. the

If the startup attribute is "Suspend", the state of the application is suspended. When the most recent state is "Suspend", if the start attribute of the branch destination title is "Suspend", the suspension is maintained. If "Persistent", "AutoRun", in the branch target header, restart the application. By defining the lifetime and start attributes in the application management table, it is possible to perform synchronous control to operate Java applications along the title time axis, and it is possible to deliver various applications accompanying video playback and application execution. This concludes the description of the recording medium. Next, the playback device of the present invention will be described. the

Fig. 16 is a diagram showing the internal structure of the playback device of the present invention. The playback device of the present invention is industrially produced based on the internal structure shown in this figure. The reproduction device of the present invention is mainly composed of two parts of a system LSI and a driving device, and can be industrially produced by mounting these parts on the case and the substrate of the device. The system LSI is an integrated circuit that integrates various processing units that realize the functions of the playback device. The playback device produced in this way is composed of BD-ROM drive 1, read buffer 2, demultiplexer 3, video decoder 4, video plane 5, P-Graphics decoder 9, presentation graphics plane 10, compositing unit 11, Font generator 12, I-Graphics decoder 13, switch 14, interactive graphics plane 15, synthesis unit 16, HDD 17, read buffer 18, demultiplexer 19, audio decoder 20, scenario memory 21 , CPU22, key event processing unit 23, instruction ROM24, switch 25, CLUT unit 26, PSR group 28, and local storage 29. the

The BD-ROM drive 1 loads/injects the BD-ROM and accesses the BD-ROM. the

The read buffer 2 is a FIFO memory, and stores TS packets read from the BD-ROM in a first-in first-out manner. the

A demultiplexer (De-MUX) 3 fetches TS packets from the read buffer 2, and converts the TS packets constituting the TS packets into PES packets. And, output the packet with the PID set by the CPU 22 among the PES packets obtained by conversion to one of the video decoder 4, the audio decoder 20, the P-Graphics decoder 9, and the I-Graphics decoder 13. one. the

The video decoder 4 decodes a plurality of PES packets output from the demultiplexer 3 to obtain uncompressed images, and writes them into the video plane 5 . the

Video plane 5 is a plane for storing images in uncompressed form. The term "plane" refers to a memory area for storing pixel data of one screen in a playback device. When a plurality of planes are provided on the playback device, and storage contents of these planes are added for each pixel to perform video output, video output can be performed after synthesizing a plurality of video contents. The resolution in the video plane 5 is 1920×1080, and the image data stored in the video plane 5 is composed of pixel data represented by 16-bit YUV values. the

The P-Graphics decoder 9 decodes the presentation graphics stream read from the BD-ROM or HDD 17 , and writes uncompressed graphics into the presentation graphics plane 10 . By decoding the graphics stream, subtitles are displayed on the screen. the

The presentation graphics plane 10 is a memory having an area of one screen, and can store uncompressed graphics for one screen. The resolution of this plane is 1920×1080, and each pixel of the uncompressed graphics in the presentation graphics plane 10 is represented by an 8-bit index color. The uncompressed graphics stored in the presentation graphics plane 10 are provided for display by converting the index color using CLUT (ColorLookupTable). the

The compositing unit 11 composites the uncompressed image data (i) with the content stored in the presentation graphics plane 10 . the

The font generator 12 expands the text code included in the textST stream into a bitmap using a character font. the

The I-Graphics decoder 13 decodes the interactive graphics stream read from the BD-ROM or HDD 17 , and writes uncompressed graphics on the interactive graphics plane 15 . the

The switch 14 is a switch for selectively writing one of the font string generated by the font generator 12 and the graphics decoded by the P-Graphics decoder 9 to the presentation graphics plane 10 . the

The interactive graphics plane 15 writes the uncompressed graphics obtained by decoding by the I-Graphics decoder 13 . the

The compositing unit 16 synthesizes the storage content of the interactive graphics plane 10 and the synthesized image (combined image data in an uncompressed state and the content representing the storage content of the graphics plane 7) that is the output of the compositing unit 8 . the

The HDD 17 is a built-in medium that stores SubClips, Clip information, and Playlist information downloaded via a network or the like. Playlist information on HDD 17 is different in that it can be specified even if it is Clip information existing in either BD-ROM or HDD 17 . The playlist information on the HDD17 does not need to specify the file on the BD-ROM through the full path (full path) every time it is specified. This is because the HDD 17 is integrated with the BD-ROM, and is recognized by the playback device as one virtual drive (called a virtual package). Therefore, Clip_nformation_file_name in PlayItem information and Clip_Information_file_name in SubPlayItem information can specify an AVClip on HDD 17 or BD-ROM by specifying a 5-digit numerical value corresponding to the file body of a file storing Clip information. By reading the recorded content of the HDD and dynamically combining it with the recorded content of the BD-ROM, various reproductions can be produced. the

The read buffer 18 is a FIFO memory, and stores TS packets read from the HDD 17 in a first-in first-out format. the

A demultiplexer (De-MUX) 19 takes out TS packets from the read buffer 18, and converts the TS packets into PES packets. And, among the PES packets obtained by the conversion, a packet having a desired streamPID is output to the font generator 12 . the

The audio decoder 20 decodes the PES packets output from the demultiplexer 19, and outputs audio data in uncompressed form. the

The scenario memory 21 is a memory for storing current PL information and current Clip information. The term "current PL information" refers to information that is currently processed among the plurality of PL information recorded on the BD-ROM. The current Clip information refers to information that is currently processed among a plurality of Clip information recorded on the BD-ROM. the

The CPU 22 executes software stored in the command ROM 24 to control the entire playback device. the

The key event processing unit 23 outputs a key event for the key operation performed on the remote controller or the front panel of the playback device. the

The command ROM 24 stores software specifying control of the playback device. the

The switch 25 is a switch for selectively inputting various data read from the BD-ROM and the HDD 17 to any one of the read buffer 2, the read buffer 18, the script memory 21, and the local memory 29. the

The CLUT unit 26 converts the index color in the uncompressed graphics stored in the video plane 5 into Y, Cr, and Cb values. the

The CLUT unit 27 converts the index color in the uncompressed graphics stored in the interactive graphics plane 15 into Y, Cr, and Cb values. the

The PSR group 28 is a register built into the playback device, and is composed of 64 player status registers (PSR) and 4096 general-purpose registers (GPR). Among the setting values (PSR) of the player status register, PSR4 to PSR8 represent the current playback time. the

When PSR4 is set to a value of 1 to 100, it indicates the title to which the current playback time belongs, and when it is set to 0, it indicates that the current playback time is the top menu. the

When PSR5 is set to a value of 1 to 999, it indicates the chapter number to which the current playback time belongs, and when it is set to 0xFFFF, it indicates that the chapter number is invalid in the playback device. the

PSR6 is set to a value of 0 to 999, indicating the number of the PL (current PL) to which the current playback time belongs. the

PSR7 is set to a value of 0 to 255, and indicates the number of the Play Item (current PlayItem) to which the current playback time belongs. the

The PSR8 is set to a value of 0 to 0xFFFFFFFF to represent the current playback time (current PTM (Presentation Time)) with a time precision of 45 KHz. The current playback time is determined by the above PSR4 to PSR8. the

The local storage 29 is a cache memory for temporarily storing the recorded content of the BD-ROM because reading from the BD-ROM is slow. Due to the presence of this local storage 29, it is possible to efficiently execute applications in the BD-J mode. FIG. 17( a ) is a diagram showing how to identify a Java archive file existing in the BD-ROM on the local storage 29 . In the table of FIG. 17( a ), the left column shows the file names on the BD-ROM, and the right column shows the file names on the local storage 29 . Comparing the right column and the left column, it can be seen that the file in the local storage 29 is specified by omitting the file path of the directory designation "BDJA". the

Fig. 17(b) is a diagram showing the application of Fig. 17(a). This application example stores the data stored in the file in the form of header + data. Use the file path in local storage 9 for the header. As shown in FIG. 17(b), since a part of the file path in the BD-ROM is omitted for the file path in the local storage 29, by storing the file path in the header, the location of each data can be clarified. location in the BD-ROM. the

The above is the hardware configuration of the playback device of this embodiment. Next, the software configuration of the playback device in this embodiment will be described. the

FIG. 18 is a diagram for describing a part composed of software and hardware stored in the ROM 24 into a layer structure. As shown in this figure, the layer structure of the playback device is composed of the following a), b), c), d-1), d-2), e), and f). That is, there are two levels: a) at the physical hardware level, b) the presentation engine 31 that controls playback based on AVClips, and c) the playback control engine 32 that controls playback based on PlayList information and Clip information. On the topmost level there is e) a module manager 34 that executes branching between titles. the

Between the HDMV module 33 and the module manager 34, d-1) the HDMV module 33 that decodes and executes a Movie object, and d-2) the BD-J that decodes and executes a BD-J object. Module 35 is placed on the same level. the

The BD-J module 35 is a so-called Java platform, which is a Java virtual machine 38 including a working memory 37. . First, the presentation engine 31 to the module manager 34 will be described first. FIG. 19 is a schematic diagram of processing by the presentation engine 31 to the module manager 34 . the

The presentation engine 31 performs an AV reproduction function. The so-called AV playback function of the playback device refers to the traditional function group inherited from DVD players and CD players, including playback start (Play), playback stop (Stop), pause (Pause ON), and release of pause (Pause). Off), release of still function (Still off), fast forward with speed designation (Forward Play(speed)), rewind with speed designation (Backward Play(speed)), sound switching (Audio Change), sub-video switching (Subtitle Change), angle switch (Angle Change) functions. In order to realize the AV reproduction function, the display engine 31 controls the video decoder 4, the P-Graphics decoder 9, the I-Graphics decoder 13 and the audio decoder 20, so as to read out the AVClip on the read buffer 2. Decoding of the portion corresponding to the desired time of day. By interpreting the position indicated by PSR8 (current PTM) as the desired time, any time can be reproduced in the AVClip. ⊚1 in the figure is based on the modeling of the start of decoding by the presentation engine 31 . the

The playback control engine (Playback Control Engine (PCE)) 32 executes the functions of the playlist playback function (i) and the status acquisition/setting function (ii) in the playback device. The so-called PL playback function refers to the start and stop of playback in the AV playback function performed by the presentation engine 31 based on the current PL information and Clip information. These functions (i) to (ii) are executed by application calls from the HDMV module 33 to the BD-J module 35 . That is, the playback control engine 32 executes its own function according to an instruction based on a user operation or an instruction from an upper layer position in the layer module. In FIG. 19 , the arrows marked with ◎2◎3 represent in a model the reference of the playback control engine 32 to the Clip information and the Playlist information. the

2、

3、

 4的箭头，将来自模块管理器34的分支目标Movie对象的通知(2)、Movie对象中描述的导航指令的译码(3)、对于重放控制引擎32的应用程序调用(4)模式化来表示。  HDMV module 33 is the executive subject of MOVIE mode, if notify from module manager 34 the Movie object that forms branch target, then the Movie object that will form branch target title is read in the local memory 29, and described in this Movie object The navigation command is decoded, and the application program call to the playback control engine 32 is executed according to the decoded result. Figure 19 with

2,

3.

The arrow of 4 models the notification (2) of the branch target Movie object from the module manager 34, the decoding of the navigation instruction described in the Movie object (3), and the application call (4) to the playback control engine 32 To represent.

2的箭头将JumpTitle指令的执行(0)、模块管理器34进行的IndexTable参考(1)和分支目标Movie对象(2)的通知模式化来表示。  The module manager 34 holds the index table read from the BD-ROM, and performs branch control. In this branch control, when the HDMV module 33 executes the JumpTitle command, or when the title jump API is called from the BD-J module 35, it receives the jump number as the jump destination, and sends the jump number to the HDMV module 33 or the BD-J Module 35 notifies the Movie object or BD-J object constituting the title. belt in the picture 0, 1,

The arrow 2 represents the execution of the JumpTitle instruction (0), the reference of the IndexTable by the module manager 34 (1), and the notification of the branch target Movie object (2).

The above is the description of the presentation engine 31 to the module manager 34 . Next, the application program manager 36 will be described with reference to FIG. 20 . FIG. 20 is a diagram showing the application program manager 36 . the

The application manager 36 executes the start control of the application referring to the application management table, and the control when the title is normally terminated. the

The so-called activation control refers to reading the BD-J object every time the BD-J module as the branch target is notified from the module manager 34, and performs local storage 29 by referring to the application program management table in the BD-J object. access. In addition, the start control is a control to read the xlet program constituting the application program having the current playback time as the life span to the working memory. ☆1, ☆2, and ☆3 in FIG. 20 represent the notification (1) of the branch destination BD-J object in the activation control, the reference to the application management table (2), and the activation instruction to the Java virtual machine 38, and represent them as models. . By this start instruction, the Java virtual machine 38 reads the xlet program from the local memory 29 to the work memory 37 (☆5). the

Termination control of a title includes control for normal termination and control for abnormal termination. The control during the normal control includes calling the jump title API by the application program constituting the title, and requesting the main body of the branch control (module manager 34 ) to switch to the branch target title. Notification to the module manager 34 in this termination control is shown schematically by arrow ☆6. Here, every time the title is normally terminated, the application programs constituting the title may be started as they are. This is because it is judged whether to terminate the application in the branch target header. Although not mentioned in depth in this embodiment, the application manager 36 performs processing of reading the Java archive file ( 8 ) from the BD-ROM to the local storage 29 . The readout to the local memory 29 is modeled as ☆8. the

This concludes the description of the application program manager 36 . Next, the work memory 37 to the default operation manager 40 will be described with reference to FIG. 21 . the

The work memory 37 is a group area in which xlet programs constituting application programs are arranged. The working memory 37 originally exists in the Java virtual machine 38, but in FIG. 21, for the convenience of drawing, the working memory 37 is described in the upper layer of the Java virtual machine 38. The xlet program on the working memory 37 contains EventListner and JMF player instances. the

The Java virtual machine 38 loads the xlet program constituting the application program on the work memory 37, decodes the xlet program, and executes processing based on the decoding result. As described above, since the xlet program includes a method for instructing the creation of a JMF player instance and a method for instructing the execution of the JMF player instance, the control of the lower layer is performed in order to realize the processing contents instructed by these methods. When commanding to create a JMF player instance, the Java virtual machine 38 obtains the JMF player instance associated with the YYYY.MPLS file on the BD-ROM. Also, when the execution of the JMF method in the JMF player instance is commanded, the JMF method is issued to the BD middleware and replaced with an application call corresponding to the BD playback device. And, a replaced application program call is issued to the playback control engine 32 . the

The event monitoring manager 39 analyzes events (key events) generated by user operations, and distributes the events. The solid line arrows ◇1 and ◇2 in the figure are represented in a model based on the allocation of the event listening manager 39 . In the case of key events such as SRART, STOP, SPEED registered on the Event Listner in the xlet program, events related to the xlet program that are indirectly referenced through the BD-J object are dispatched. START, STOP, and SPEED are events corresponding to JMF. Since these key events are registered on the Event Listner of the xlet program, the xlet program can be started through this key event. When the key event is not registered in the Event Listner, the key event is assigned to the default operation manager 40. This is because there are various events that are not registered in the Event Listner among the key events generated in the BD-ROM playback device such as audio switching and angle switching, and even if these key events are generated, processing without omission is performed. the

If the default operation manager 40 distributes a key event not registered on the Event Listner in the xlet program from the event listener manager 39, then the playback control engine 32 executes an application program call corresponding to the Event Listner unregistered event. The application call based on the default operation manager 40 is represented schematically by the arrow ◇3 in the figure. In addition, although the Event Listner unregistered event is distributed by the event monitoring manager 39 and the default operation manager 40 in FIG. 21 , the playback control engine 32 can also directly receive the EventListner unregistered event to carry out playback control (in the figure ◇4). the

(Description of Flowchart)

The above description of the application manager 36 is merely an outline. The flowcharts of FIG. 22 and FIG. 23 show the processing of the application program manager 36 in more detail. After that, the processing procedure of the application program manager 36 will be described in more detail with reference to these flowcharts. the

FIG. 22 is a diagram showing a control procedure at the time of branching by the application manager 36 . This flowchart is the process of activating or terminating the application program (referred to as the application program x) that satisfies the conditions constituted by steps S2 to S5. the

In step S2, it is judged whether there is an application program x, although the application program x is non-started in the branch source title, but exists in the branch target title, and the startup attribute in the branch target title is the AutoRun attribute, and if the application program x exists x, the cache sensing for the local memory 29 is performed. As a result of the cache sensing, if the application program x exists in the local storage 29 ("Yes" in step S7), the application program x is read from the local storage 29 to the work memory 37 (step S8). If it does not exist in the local storage 29, after the application x is read from the BD-ROM to the local storage 29, the application x is read from the local storage 29 to the work memory 37 (step S9). the

In step S3, it is judged whether there is an application program x that is started in the branch source title and does not exist in the branch target title. If it exists, the application x is deleted from the work memory 37 and terminated (step S10). the

In step S4, it is judged whether there is an application program of branch source Suspend, branch target AutoRun or Persistent. If it exists, restart application x (step S11). the

In step S5, it is judged whether there is an application program whose branch source title is activated and whose branch target is Suspend. If it exists, suspend application x (step S12). the

The processing of the application program manager 36 every time each application program is terminated is as shown in FIG. 23 . Fig. 23 is a flowchart showing the processing procedure of application termination processing. This figure shows a loop process (step S15 ) in which the processes of step S16 to step S20 are repeated for each of the plurality of application programs to be terminated. In this loop process, the application manager 36 issues a termination event to terminate the running application (step S16), sets a timer (step S17), and proceeds to a loop process consisting of steps S18 to S20. If the Event Listner receives the termination event, the corresponding xlet program starts termination processing. When the termination process is terminated, the xlet program is released from the work memory 37 and terminated. the

During the continuation of the loop processing of step S18 to step S20, the timer keeps counting. In this loop processing, step S18 is to judge whether the sending target application program is terminated, and if it is terminated, the processing of the application program is terminated. Step S19 is to judge whether the timer expires. If the timer expires, then in step S20, the sending destination application program is deleted from the working memory 37 to forcibly terminate the application program. the

The processing of the above module manager 34 is explained with reference to FIG. 24 . the

Fig. 24 is a diagram schematically showing a procedure for terminating an application program. The first level in the figure represents the application manager 36 and the second level represents the three applications. The application program on the left side of the second level in FIG. 24 indicates an application program that has successfully terminated after receiving the termination event. The middle application program in the second level in FIG. 24 indicates an application program that fails to terminate processing after receiving a termination event. The application on the second level and on the right is an application that cannot receive termination events because EventListner is not installed. the

Arrows ep1 and ep2 from the first level to the second level indicate transmission of termination events by the application program manager in a pattern, and arrow ep3 in a pattern indicates activation of termination processing. the

The third level is the state after the state transition when the termination processing is successful, and the application program is terminated by its own termination processing. If there are any application programs such as these xlet programs that have not been terminated within a predetermined period, the application program manager 36 forcibly deletes these from the work memory 37 . The fourth level represents forced termination based on the application program manager 36 . It is also a task of the application manager 36 to specify this fourth level of forced termination. the

As described above, according to the present embodiment, since the application started in the branch source title and not existing in the branch target title is automatically terminated, even if the playback is performed complicatedly by the conditional branch, no exceeding The number of applications that reproduce the resource limit of the device is started. Since the operation of the application before and after branching can be ensured, more disc contents in which the application is executed while reproducing the digital stream can be distributed. the

(second embodiment)

In the first embodiment, the life span of the application coincides with the title time axis, but in the second embodiment, a part of the PL time axis is proposed as the life span of the application. Since a part of the PL time axis is represented by chapters, by describing the start point and end point by chapters, it is possible to specify the life span of the application. Fig. 25(a) is a diagram showing an application program management table defining life spans on the PL time axis. In FIG. 25( a ), three applications are described in the application management table, among which application#2 specifies Chapter#2 to Chapter#3 of title#1 as the life span, and specifies AutoRun in the startup attribute. Therefore, application#2 starts at the beginning of Chapter#2 and terminates at the end of Chapter#3 as shown in FIG. 25(b). the

On the other hand, application#3 specifies Chapter#4 to Chapter#6 of title#1 as the survival interval. Therefore, application#3 starts at the beginning of Chapter#4 and terminates at the end of Chapter#6 as shown in FIG. 25(b). the

In order to perform processing according to the application management table described in this way, the application manager 36 of this embodiment judges whether there is an application program whose life span starts from the chapter start point every time the chapter start point specified by Plmark is reached, and if exists, then the application is loaded into the working memory 37. the

Equally, when arriving at chapter starting point at every turn, judge whether there is the application program that life interval terminates in the chapter before this chapter, if exist, then release this application program from working memory 37. the

If the lifetime of the application is managed in units of chapters, the lifetime of the application can be specified with finer precision. However, it must be noted that there can be a time axis inversion on the disc content. The so-called reverse is to make the time axis go backwards by rewinding. If the reverse and forward are repeated at chapter boundaries, loads and discards to the work memory are performed several times, resulting in an unnecessary read load. Therefore, in the present embodiment, the startup timing of the application program is the moment when the normal playback by the playback control engine 32 starts when the title is entered. The playback of PL here includes normal playback and trick playback. The so-called skill reproduction includes fast forward, rewind, skip to the next (SkipNext), and jump to the previous (SkipBack). While the fast-forward, rewind, SkipNext, and SkipBack are being performed, application startup is not started, but after normal playback is started, application startup is started. By using the instant when normal playback starts as a reference, when there are arrivals before and after the live intervals as described above, there is no need to repeat the activation of the above-mentioned application programs. In addition, when the life span is title, processing may be performed using the instant when normal playback starts as a reference for starting the application. the

As described above, according to the present embodiment, since the generation interval of the application can be specified in units of chapters smaller than the PL, fine application control can be realized. the

(Modification of the second embodiment)

In Fig. 25, priority is added to each application. The priority takes a value from 0 to 255. In the case of resource usage conflicts between applications, each time the application manager 36 executes, one of the applications will be forcibly terminated, or one of the applications will be scrambled. When processing resources, the value of the above priority becomes the judgment material. In the example of FIG. 25, since the priority of application#1 is 255, and the priorities of application#2 and application#3 are 128, when application#1-application#2 conflicts, the application manager 36 performs forced termination priority. The processing of low-level application#2. the

(third embodiment)

The disc content provided by the BD-ROM is composed of a plurality of titles that can branch from each other. In addition to each title consisting of one or more PLs and a control procedure using the PL, there are non-AV titles consisting only of a control procedure for the playback device. This embodiment describes the non-AV title. the

For such non-AV titles, the problem is how to determine the title time axis. Fig. 26(a) shows the title time axis determined from the PL time axis. In this case, the PL time axis is the title time axis, and the life span of the application is determined on the title time axis. If there is no PL time axis as the reference, the title time axis should be determined as shown in Figs. 26(b) and (c). the

Fig. 26(b) shows the title time axis determined from the life span of the main application. The main application is the only application whose startup attribute is set to AutoRun in the title and is automatically started when the title is started. For example, a program called a startup application corresponds to this. The so-called startup application refers to an application that starts other applications. the

The consideration in FIG. 26(b) is that the title timeline continues as long as the main application is started, and the timeline is terminated when the main application is terminated. Fig. 26(c) is a diagram showing a title time axis determined from the life spans of a plurality of applications. There are cases where one application is started at the start point of the title, but the application repeatedly calls other applications, and the application further calls the other applications. At this time, as long as one of the application programs is started, the title time axis is considered to continue, and if no application program is activated, the title time axis is considered to be terminated. In this way, when the title time axis of a non-AV system title is determined, regardless of whether it is an AV title or a non-AV system title, branching to a predetermined title can be uniformly performed at the same time as the termination of the title time axis. In addition, the title time axis in the non-AV title is merely an assumed imaginary time axis when compared with the AV title. Therefore, the playback device can go backward or locate at any position on the time axis of the title in the non-AV title. the

The above is the improvement on the recording medium in this embodiment. Next, improvements to the playback device in this embodiment will be described. the

In order to terminate the title in the above-mentioned procedure, the application manager 36 of the third embodiment performs processing as shown in FIG. 27 . FIG. 27 is a flowchart showing the processing procedure of the application manager 36 when reproducing a title. In this flowchart, the loop structure repeats steps S21 to S23 during title playback. the

In step S21, it is judged whether the title jump API has been called, and if called, a branch to the jump target title is requested to the module manager 34 (step S27). the

In step S22, it is determined whether or not there is a main application responsible for invoking the application in the title, and if there is, whether or not it is activated is checked (step S25). If not started, it is interpreted as "termination of the title", and the module manager 34 is notified of termination (step S26). the

Step S23 is a step executed when there is no main application program ("No" in step S22), and it is judged whether or not any application program is activated. If yes, it is also interpreted as "termination of the title", and the termination is notified to the module manager 34 (step S26). the

As described above, according to the present embodiment, even if the title is not reproduced along with the PL, it is possible to execute the process of not branching during the execution of the application, but branching after the execution of the application is terminated. the

(Fourth Embodiment)

This embodiment relates to an improvement in realizing the same menu control on a BD-ROM as on a DVD. Fig. 28(a) is a diagram showing menu levels realized by the BD-ROM. In the menu hierarchy in this figure, a TopMenu is placed on the top layer, and the structure of the TitleMenu, SubTitleMenu, and AudioMenu in the lower layer can be selected from the TopMenu. Arrows sw1 , 2 , and 3 in the figure schematically represent menu switching based on button selection. The "TopMenu" refers to a menu provided with buttons (buttons sn1, sn2, and sn3 in the figure) for receiving one of audio selection, subtitle selection, and title selection. the

The so-called TitleMenu refers to a menu provided with buttons for accepting the selection of a movie version of a video work (title), selection of a director's cut version, or selection of a game version. AudioMenu is a menu provided with buttons for accepting audio reproduction in Japanese or English, and SubTitleMenu is a menu provided with buttons for accepting subtitle display in Japanese or English. the

Fig. 28(b) shows a MOVIE object for operating a menu having this level. In Figure 28(b), FirstPlayOBJ, TopMenu OBJ, AudioMenu OBJ, SubTitleMenu OBJ are stored in MovieObject.bdmv. the

The FirstPlay object (FirstPlay OBJ) is a dynamic scenario that is automatically executed when the BD-ROM is loaded into the playback device. the

The TopMenu object (TopMenu OBJ) is a dynamic script that controls the actions of the TopMenu. When the user requests a menu call, it is the TopMenu object that is called. The TopMenu object includes an instruction for changing the state of the buttons in the TopMenu according to an operation from the user, and a branch instruction for branching according to a certain operation on the button. This branch instruction implements menu switching from TopMenu to TitleMenu, from TopMenu to SubTitleMenu, and from TopMenu to AudioMenu. the

The AudioMenu object (AudioMenu OBJ) is a dynamic script that controls the behavior of the AudioMenu, including instructions to change the state of the buttons in the AudioMenu according to user operations, and instructions to update the sound settings according to the determined operation of the buttons. the

The SubTitleMenu object (SubTitleMenu OBJ) is a dynamic script that controls the behavior of the SubTitleMenu, including instructions to change the state of the buttons in the SubTitleMenu according to user operations, and instructions to update the PSR for subtitle setting according to the confirmation operation on the buttons. the

The TitleMenu object (TitleMenu OBJ) is a dynamic script that controls the actions of the TitleMenu, including instructions for changing the state of the buttons in the TitleMenu and branch instructions for branching according to the determined operation on the buttons. the

Through these MOVIE objects for menus, it is possible to realize the behavior of the menu as realized in DVD. Above is the MOVIE object related to the menu control. the

Fig. 29 is a schematic diagram of an index table and branches from the index table to each Movie object. The left side of the figure shows the internal structure of the index table. The index table in this embodiment includes FirstPlayINDEX, TopMenuINDEX, Audio MenuINDEX, Subtitle MenuINDEX, titleMenuINDEX, title#1 to #mINDEX, title#m+1 to Nindex, and title#0INDEX. The arrows bc1 and 2 in the figure represent the branch from Index Table to FirstPlayOBJ and the branch from FirstPlayOBJ to TopMenu, and the patterns of arrows bc3, 4 and 5 represent the branches from TopMenu to TitleMenu, SubTitleMenu and AudioMenu. Arrows bc6, 7, and 8 schematically represent branches from TitleMenu to Movie objects. the

FirstPLayINDEX, TopMenuINDEX, Audio MenuINDEX, SubtitleMenuINDEX, and title MenuINDEX are Indexes for FirstPLay OBJ, TopMenuOBJ, Audio MenuOBJ, Subtitle MenuOBJ, and title MenuOBJ respectively, and describe these identifiers. the

Title#1~#mINDEX is the index of the title from the first to the mth title in the BD-ROM, and describes the identifier (ID) of the MOVIE object as the branch target when selecting these title numbers from 1 to m . the

Title#m+1～#nINDEX is the index of the title from m+1 to n in the BD-ROM, and describes the BD-J as the branch target when selecting these title numbers from m+1 to n The object's identifier (ID). the

Title#0INDEX is an INDEX specifying a Movie object or a BD-J object to be a branch destination when the BD-J object is forcibly terminated. In this embodiment, the identifier for TopMenuOBJ is stored in this title#0INDEX. the

FIG. 30( a ) shows a branch when Index Table is described as in FIG. 29 . Since the Index Table is described in this way, the identifiers of the Movie objects #1 to #m are extracted from the title#1 to title#m INDEX when the branch instruction with the labels title#1 to title#m as branch targets is executed. When executing a branch instruction using labels title#m+1 to title#n as a branch, identifiers of BD-J objects #m+1 to #n are extracted from title#m+1Index to title#nIndex. Since the identifiers of BD-J objects #m+1 to #n are 5-digit numerical values representing title names, "00001.BD-J, 00002.BD-J, 00003.BD-J..." are extracted, and The dynamic script of the title name is read into the memory and executed. It is branch processing using an index table. the

Fig. 30(b) is a diagram showing a branch at the time of forced termination at the time of BD-J object execution. In the branch at the time of forced termination, the identifier is extracted from title#0Index, and the dynamic scenario of the identifier is executed by the playback device. If the identifier is the identifier of the top menu title, the top menu OBJ is automatically selected when the application program is forcibly terminated. the

The above is the improvement on the recording medium in this embodiment. Next, improvements to the playback device in this embodiment will be described. The module manager 34 in the playback device performs processing as shown in FIG. 31 in response to the improvement of the recording medium described above. FIG. 31 is a flowchart showing the processing procedure of the module manager 34 . This flow chart constitutes a loop process consisting of step S31 and step S32, and when one of step S31 or step S32 is "Yes", the corresponding process is executed. the

Step S31 judges whether there is a title jump API call. If there is a call of the title jump API, then obtain the title number j (step S33) as the branch target label, and obtain the IDj (step S34) from the index of the title number j in the index table, and make the HDMV module 33 or BD - The J module 35 executes the Movie object or the BD-J object of IDj (step S35). the

Step S32 judges whether to terminate from application program manager 36 notification title, if notification ("yes" in step S32), then make HDMV module 33 or module manager 34 execute the top menu OBJ (step S36) that constitutes the top menu title . the

An example of the operation of the forced termination of the application by the application manager 36 described above will be described with reference to FIG. 32 . The title to be reproduced here is a non-AV title of a game application including stacked tiles. The lower level in FIG. 32 shows the title timeline constituted by the life cycle of the application, and the upper level shows the images displayed on the title timeline. When the non-AV title is a game application, one screen of the game application is displayed in the live area of the game application as shown on the upper left side of FIG. 32 . If the application has an error and terminates abnormally, the application manager 36 terminates the game application forcibly according to the flowchart in FIG. 23 and notifies the module manager 34 of the termination of the title. If the title termination is notified, the module manager 34 branches to the top menu title. In this way, an image as shown on the upper right side of FIG. 32 is displayed, and the user's operation is awaited. the

As described above, according to the present embodiment, when a non-AV title that includes a program but does not include a digital stream is terminated, control to branch to the top menu title can be performed. As a result, downtime and bang up can be avoided even if the application terminates with an error. the

(fifth embodiment)

Improvements related to how synchronization with PL playback is achieved in BD-J mode. In an example of FIG. 8( b), when the Java virtual machine 38 decodes the JMF player instance (A.play;) that instructs the reproduction of the JMF player instance, the Java virtual machine 38 calls the PL playback API, Immediately after the call, a "success" response is returned to the application. the

The playback control engine 32 executes processing based on PL information when calling the PL playback API. If the PL has a playback time of two hours, the above-described processing continues for the two-hour period. What becomes problematic here is the interval between when the Java virtual machine 38 returns a successful response and when the playback control engine 32 actually terminates processing. Since the Java virtual machine 38 is the processing subject of the driver event, it returns a response indicating playback success or playback failure immediately after the call. When the time taken for the access response to be returned to the application is used as a reference, it is not possible to sense the end of processing after the elapse of two hours. If Fast Forward, Rewind, or Skip is performed during PL playback, the 2-hour playback period changes around 2 hours, making it more difficult to detect the end of the process. the

Since the playback control engine 32 operates independently of the application program, it cannot interpret the termination of PL playback as the termination of the title in the termination judgment like the third embodiment. Therefore, in this embodiment, although the application program has been terminated, as long as there is a JMF player instance on the working memory 37, that is, while the BD-J module 35 has control of the presentation engine 31, the playback control engine 32 Waits for the reproduction termination event. And, if there is a playback end event, it is interpreted as the end of the title, and the module manager 34 is notified to branch to the next title. Thus, the time when the playback control engine 32 terminates PL playback can be regarded as the end of the title. the

Next, a specific control procedure by the playback control engine 32 will be described with reference to the flowcharts in FIGS. 33 to 37 . the

FIG. 33 is a flowchart showing the PL playback control process by the playback control engine 32. This playback process mainly includes control of the presentation engine 31 (step S46) and control of the BD-ROM drive 1 or HDD 17 (step S48). Let PlayItem to be processed in this flowchart be PlayItem#x. In this flowchart, the current PL information (.mpls) is read (step S41), and then the processing of steps S42 to S50 is executed. Here, steps S42 to S50 repeat the loop processing of steps S43 to S50 for each piece of PI information constituting the current PL information until "YES" in step S49. The PlayItem to be processed in this loop processing is called PlayItem#x (PI#x). This PlayItem#x is initialized by setting it as the head PlayItem of the current PL (step S42). The termination requirement of the above-mentioned loop processing is that the PlayItem#x is the last PlayItem of the current PL (step S49), and if it is the last PlayItem, the next PlayItem of the current PL is set as PlayItem#x (step S50). the

Repeated steps S43 to S50 in the loop process read the Clip information specified by the Clip_information_file_name of PlayItem#x into the script memory 21 (step S43), and use the Epmap of the current Clip information to convert the In_time of PlayItem#x to I picture address u (step S44), use the EP_map of current Clip information to convert the Out_time of PlayItem#x into I picture address v (step S45), and after obtaining the next I picture of address v obtained by these conversions, The previous address is set as address w (step S47). Using the address w thus calculated, the BD-ROM drive 1 or the HDD 17 is instructed to read the TS packets from the I picture address u to the address w (step S48). the

On the other hand, the presentation engine 31 is instructed to output from the mark_time_stamp of the current PLMark to the Out_time of PlayItem#x (step S46). Through the steps S45 to S48 described above, the part indicated by PlayItem#x is played back in the AVClip. the

After that, it is judged whether or not PlayItem#x is the last PI of the current PL (step S49). the

If PlayItem#x is not the last PI of the current PL, the next PlayItem in the current PL is set as PlayItem#x (step S50), and returns to step S43. By repeating the above steps S43 to S50, the PIs constituting the PL are sequentially reproduced. the

Fig. 34 is a flow chart showing the angle switching process and the process of Skip Back and Skip Next. This flowchart is parallel to the processing procedure in FIG. 33, and the loop processing consisting of steps S51 to S52 is repeated. In step S51 in this cycle, judge whether the API of request angle switching is called from Java virtual machine 38, if there is the calling of angle switching API, then perform the operation of switching current Clip information. the

Step S55 of FIG. 34 is a judging step. It is judged whether is_multi_angles of PlayItem#x is ON. The so-called is_multi_angles is a sign indicating whether PlayItem#x corresponds to multi-angles. If step S55 is "No", then proceed to step S53. If step S55 is "Yes", execute steps S56 to S59. Steps S56～step S59 substitute the angle number after switching into the argument y (step S56), and read the Clip information specified by the Clip_information_file_name of the yth Clip_information_file_name in PlayItem#x to the script memory 21 (step S57), use the current Clip information The EP_map of the current PTM converts the current PTM into an I image address u (step S58), and uses the EP_map of the current Clip information to convert the Out_time of PLayItem#x into an I image address v (step S59). In this way, after changing the I picture addresses u and v, the process proceeds to step S46. By going to step S46, TS packets are read from other AVClips, so the video content is switched. the

On the other hand, step S52 in the cycle of Fig. 34 judges whether to call the API that meaning is Skip Back/Skip Next from Java virtual machine 38, if call, then carry out the processing procedure of the flowchart of Fig. 35. Fig. 35 is a flow chart showing the processing procedure when calling Skip Back, Skip Next API. Each time Skip Back and Skip Next are executed, there are various processing procedures. Note that what is described here is just an example. the

Step S61 obtains the current Mark information by converting the current PI number represented by PSR and the current PTM. Step S62 judges whether the key pressed is the Skip Next key or the Skip Back key, if it is the Skip Next key, then in step S63 the direction mark is set to +1, if it is the Skip Back key, then in the step S64 the direction mark is set Set to -1. the

Step S65 sets the current PLMark number to the current PLMark number with the value of the direction flag added. Here, if it is the SkipNext key, the direction mark is set to +1, so the current PLMark is increased. If it is the Skip Next key, the direction flag is set to -1, so the current PLMark is subtracted. the

In step S66, the PI described in ref_to_PlayItem_Id of the current PLMark is set to PlayItem#x, and in step S67, the Clip information specified by the Clip_information_file_name of PlayItem#x is read. In step S68, the EP_map of the current Clip information is used to convert the mark_time_stamp of the current PLMark into an I picture address u. On the other hand, in step S69, the Out_time of PlayItem #x is converted to the I picture address v using the EP_map of the current Clip information. Step S70 commands the presentation engine 31 to output from the mark_time_stamp of the current PLMark to the Out_time of PlayItem#x, and then proceeds to step S47 in FIG. 33 . Like this, after changing the I picture address u, v, after ordering the reproduction of other parts, enter into step S47, so become and read out TS packet from other AVClip, realize switching video content. the

FIG. 36 is a flowchart showing the details of the processing procedure by the presentation engine 31 . In this flowchart, after the PTS of the I picture is set as the current PTM (step S71), a loop process consisting of steps S72 to S77 is executed. the

Next, the loop processing in step S72 to step S77 will be described. This loop process repeats reproduction output of images and audio corresponding to the current PTM, and updating of the current PTM. Step S76 in this loop process specifies the termination requirements of the loop process. In other words, step S76 regards the fact that the current PTM is Out_time of PI#x as the termination requirement of the loop processing. the

Step S73 judges whether to call the fast-forward API or the fast-reverse API from the Java virtual machine 38 . If so, then in step S78, the judgment of fast forward or fast rewind is carried out, if fast forward, then the PTS of the next I picture is set as the current PTM (step S79). In this way, by setting the current PTM as the PTS of the next I picture, an AVClip can be reproduced quickly within one second. As a result, the AVClip is quickly reproduced in the forward direction at double speed or the like. If fast rewind, it is judged whether the current PTM has reached the Out_time of PlayItem#x (step S80). If not reached, then the PTS of the previous I picture is set as the current PTM (step S81). By setting the read-side address A as the previous I-picture in this way, an AVClip can be quickly reproduced within one second in the backward direction. As a result, the AVClip is played back in the reverse direction at double speed or the like. In addition, there are various processing procedures for performing fast forward and rewind. Note that what is described here is just an example. the

Step S74 judges whether the menu call API is called, and if called, suspends the current playback process (step S82), and executes the menu program for menu processing (step S83). Through the above processing, when the menu is called, the processing for displaying the menu is executed after the playback processing is interrupted. the

Step S75 judges whether there is a SubPlayItem#y specifying PlayItem#x by Syn_PlayItem_id, and if so, proceeds to the flowchart of FIG. 37 . Fig. 37 is a flowchart showing the playback procedure of SubPlayItem. In this flow chart, first in step S86, it is judged whether the current PTM is sync_start_of_PlayItem of SubPlayItem#y. If so, in step S93, the playback control engine 32 is notified to perform playback processing based on SubPlayItem#y. the

Steps S87 to S92 in FIG. 37 are flowcharts showing playback processing based on SubPlayItem#y. the

In step S87, the Clip information specified by Clip_information_file_name of SubPlayItem#y is read. In step S88, the In_time of SubPlayItem#y is converted into an address α using the EP_map of the current Clip information. On the other hand, in step S89, the Out_time of SubPlayItem#y is converted to the address β using the EP_map of the current Clip information. Step S90 instructs the decoder to output from In_time of SubPlayItem#y to Out_time of SubPlayItem#y. Find the next I-picture at address β obtained by these conversions, and set the previous address as address γ (step S91), and use the address γ calculated in this way to command BD-ROM drive 1 or HDD 17 from SubClip# Reading of TS packets from address α to address γ of z (step S92). the

In addition, return to FIG. 33 to continue the description of the processing of the playback control engine 32 . Step S53 is based on the judgment of whether playback control by the presentation engine 31 is completed, and if the processing of the flowchart in FIG. 36 is performed for the last PlayItem#x, the result of step S53 is "No". After the processing of the flowchart in FIG. 36 is terminated, step S53 becomes "Yes", and the process proceeds to step S54. Step S54 is an output of a playback termination event to the Java virtual machine 38, and the Java virtual machine 38 can know the lapse of the playback time of two hours through the output. the

The above is the processing of the reproduction control engine 32 and the presentation engine 31 in this embodiment. Next, the processing procedure of the application program manager 36 in this embodiment will be described. FIG. 38 is a flowchart showing the processing procedure of the application manager 36 of the fifth embodiment. the

The flowchart of FIG. 38 improves the flowchart of FIG. 27 . The point of improvement is that step S24 is added between step S21-step S22, and step S101 is executed when step S24 is "Yes". the

Step S24 judges whether there is a JMF player instance in the working memory 37, if not, proceed to step S22. If it exists, go to step S101. Step S101 judges whether a playback termination event has been output from the playback control engine 32, and if so, the module manager 34 is notified of the title termination (step S26) after eliminating the Java player instance in the work memory (step S102). If there is no notification, the loop processing consisting of steps S21 to S24 is repeated. the

In the above flowchart, as long as there is a JMF player instance on the work memory 37 ("Yes" in step S24), step S22 and step S23 are skipped. Therefore, for example, even if all the applications are terminated, it is interpreted that the title is continuing. the

As described above, according to the present embodiment, the application manager 36 can grasp the elapsed time of the playback time of two hours, so that the menu can be displayed on the termination condition of PL playback, and branching to other titles can be realized according to the operation on the menu. control. the

(sixth embodiment)

The sixth embodiment relates to an improvement in which a data management table is set on a BD-J object. the

The data management table (DMT) is a table showing that Java archive files to be loaded on the local storage 29 are associated with read attributes and read priorities on the title time axis. The existence in the local storage 29 means that the Java archive file constituting the application program can be read from the local storage 29 and transferred to the working memory 37 in the Java virtual machine 38 . Fig. 39 is a diagram showing an example of a data management table. As shown in the figure, the data management table shows the "lifetime" of the application, the "applicationID" for identifying the application having the lifecycle, and the "read attribute" and "read priority" of the application. the

As described above, the application management table has a concept called a life span, and the data management table also has the same concept of a life span. Setting the same concept as the application management table in the data management table may seem wasteful, but it has meaning. the

Fig. 40 is a diagram showing an execution model assumed by a BD-J object. The execution model in this figure is composed of BD-ROM, local storage 29, and Java virtual machine 38, and shows the relationship among BD-ROM, local storage 29, and work memory 37. Arrow my1 indicates reading from BD-ROM → local storage 29 , and arrow my2 indicates reading from local storage 29 → work memory 37 . Notes on the arrows indicate at what timing these reads were performed. Based on the note, the reading between the BD-ROM → the local storage 29 is a so-called "pre-reading", which must be performed before the application program is needed. the

In addition, based on the annotation, it is clear that reading between the local storage 29→work storage 37 is performed when the application program is required. "When needed" refers to the time (1) when the lifetime of the application program arrives and the time (2) when another application program or the application manager 36 instructs the call of the application program. the

Arrow my3 indicates release of the area occupied by the application program in the work memory 37 , and arrow my4 indicates release of the area occupied by the application program in the local storage 19 . Notes on the arrows indicate at which timing these readings are performed. Based on the annotation, it is clear that the work memory 37 is released simultaneously with the termination of the application program. On the other hand, the release on the local storage 29 is performed when the Java virtual machine 38 does not need it. The so-called unnecessary moment is not the "end moment". It refers to "the moment when there is no possibility of restart after termination", that is, the moment when the title terminates. The above-mentioned release time in the read-in/release work memory 37 is judged from the life span in the application program management table. However, the "time before the application is required" and "the time when there is no possibility of restarting after termination" cannot be specified. Therefore, in the authorization stage, since the time is defined on the time axis of the entire disc content, in this embodiment, the interval in which each application exists is described in a data management table different from the application management table. That is, by defining "the time before the application is required" as the start point of the life span in the data management table, and "the time when there is no possibility of restart after termination" as the end point of the data management table, it is possible to Migration of stored content on the above-mentioned local storage 29 is specified. It is the descriptive meaning of the data management table. the

The description of the life span of the local storage 29 based on the data management table will be described. The content of the disk to be created here is composed of three titles (title#1, title#2, title#3). On the time axis of these titles, it is considered that the local storage 29 should be used at the timing shown in FIG. 41(b). . At this time, the Java archive files constituting application#1 and application#2 are read into the local storage 29 at the start point of the title#1 time axis, and application#1 and application #2 is resident on local storage 29 . And, at the starting point of the time axis of title#2, the Java archive file constituting application#1 is released from the local storage 29, and instead of this, the Java archive file constituting application#3 is read into the local storage 29 to perform resident (afterwards, the Java archive that constitutes the application is handled in the same manner as the application). The description of the data management table at this time expresses the application program that should be resident in the local storage 29 by describing the application ID of the application program in association with the life span as shown in FIG. 41( a ). In Figure 41(a), it can be seen that the applicationID of application#1 is described corresponding to title#1, the applicationID of application#2 is described corresponding to title#1 and title#2, and the applicationID of application#2 is described corresponding to title#3 applicationID of application#3. Thus, the time transition occupied by the local storage 29 is defined by the authorized person. the

As a combination of the data management table and the application management table, it is preferable that the life span specified in the application management table be a small reproduction unit, and the life span defined in the data management table be a large reproduction unit. The large playback unit is preferably a non-seamless playback unit such as title or PL. On the other hand, as a small playback unit, a seamless playback unit such as a chapter in the PL is preferable. If the life span of the application program is defined for each title and PL, since the application program exists in the work memory 29, the application program can be retrieved at any time during the reproduction of the title. In this way, even if the life span of the application program is finely defined, the application program can be immediately read to the work memory on the virtual machine, so even if the application program is frequently started and terminated, the application program can be executed smoothly. . the

Next, the read attribute will be described. the

In FIG. 2, it is assumed that the Java archive is recorded in a recording area different from that of the AVClip. However, this is just an example. The Java archive file may be embedded in the recording area occupied by the AVClip in the BD-ROM. There are two types of embedding methods: carousel and cross unitization. the

The so-called "circulation" here refers to a broadcasting method that is converted to repeat the same content in order to realize dialogue broadcasting. Although the BD-ROM does not store broadcast data, in this embodiment, a JAVA archive file is stored in imitation of a cyclic broadcast format. Fig. 42 is a diagram showing loop-based Java archive embedding. The first level is the Java archive embedded in the AVClip, and the second level represents fragmentation. The third level represents TS packetization, and the fourth level represents the TS packet string that constitutes the AVClip. The segmented and TS-packetized data ("D" in the figure) is embedded in an AVClip. Java archives multiplexed in AVClip are read in low frequency each time they are read by looping. Since this low-frequency reading takes about 2 to 3 minutes, the playback device takes 2 to 3 minutes to read the Java archive file. ``

Figure 43 shows a diagram of cross-based Java archive embedding. The first level is the AVClip to be embedded, the second level is the Java archive file interleaved with the AVClip, and the third level is the AVClip configuration in the recording area of the BD-ROM. As shown in the figure, the Java archive files to be embedded in the stream are interleaved and recorded at the intervals forming the divisions (AVClip2/4, 3/4 in the figure) of XXXXX.m2ts constituting the AVClip. By interleaving Java archives multiplexed on AVClip, read out in high frequency band compared with loop. Since this high frequency band is read, the playback device reads the Java archive file in a short period of time. the

The Java archive file after cycle and crossover is not loaded in advance. When the current playback time reaches the portion of the AVClip recording area in the BD-ROM in which the looped/interleaved Java archive is embedded, it is loaded into the local storage 29 of the playback device. The recording form of the Java archive file has the forms shown in FIG. 42 and FIG. 43(a) in addition to the form shown in FIG. 2, so the read attribute is set as shown in FIG. 43(b). As shown in FIG. 43(b), the read attributes include "Preload" indicating that the title is loaded into the local storage 29 before title playback, "Load. Indicates "Load.InterLeave" that is loaded in an interleaved manner during Title playback. A suffix is used in the read attribute to represent a cycle or intersection, but it can also be omitted. the

A specific description example of the life span in the data management table will be described with reference to FIG. 44 . Fig. 44(a) is a diagram showing an example of a data management table. FIG. 44(b) is a diagram showing changes in the storage content of the local storage 29 based on the assignment of the data management table. In this figure, the vertical axis represents the occupied area in the local memory 29, and the horizontal axis represents the PL time axis within one title. In the data management table, application#1 is described as the life span of the PL time axis in one title as a whole, so Chapter#1 to Chapter#5 of the title occupy the area in the local memory 29 . application#2 is described as making Chapter#1~Chapter#2 in PL#1 in the title the life range in the data management table, so Chapter#1~Chapter#2 in the title occupies the area in the local storage 29 . Since application#3 is described as having Chapter#4-Chapter#5 in PL#1 in the title as the live range in the data management table, Chapter#4-Chapter#5 in the title occupies the area in the local storage 29. area. This concludes the above description of the life span in the data management table. the

Next, the read priority will be described. The reading priority refers to a priority for determining whether reading into the local storage 29 is good or bad. There are multiple values for the read priority. When it is desired to set the superiority and inferiority of two levels, a value indicating mandatory (Mandatory) and a value indicating optional (optional) are set as the reading priority. At this time, Mandatory refers to a high read priority, and optional refers to a low read priority. When it is desired to set the superiority and inferiority of three levels, a value indicating Mandatory, a value indicating optional: high, and optional: low is set as the reading priority. Mandatory indicates the highest read priority, optional: high indicates the medium read priority, and optional: low indicates the lowest read priority. A specific description example of the read priority in the data management table will be described with reference to FIGS. 45( a ) and ( b ). In this specific example, the assumed memory size of the local storage 29 is as shown in FIG. 45(a). FIG. 45(a) is a diagram showing a comparison of the memory sizes of the local storage 29 in the old and new playback devices. Arrow mk1 indicates the memory size of the old playback device, and arrow mk2 shows the memory size of the new playback device. According to the comparison of the arrows, it is assumed that the memory size of the local storage 29 in the new playback device is more than three times the memory size of the old playback device. In this way, when the memory size varies, the application programs are classified into two groups as shown in FIG. 45 . The first application (#1, #2) that should be read regardless of the memory size. The second one is an application program (#3, #4) that does not want to be loaded by the old playback device, but wants to be loaded by the new playback device. If the applications to be read are classified into these two groups, the read priority=Mandatory is set on the application belonging to the former, and the read priority=Optional is set on the application belonging to the latter. Fig. 45(b) is a diagram showing an example of a data management table in which read priorities are set. If the data management table is set in this way, and application#1 to application#4 are recorded on the BD-ROM, the playback on all playback devices with a memory size can be guaranteed, and at the same time, it can be used on a playback device with a large memory size. The playback device plays back an application using data of a larger size. the

The above is the improvement on the recording medium of this embodiment. Next, improvements to the playback device in this embodiment will be described. The application program manager 36 performs processing in the processing procedure shown in FIG. the

FIG. 46 is a diagram showing the processing procedure of the preload control by the application program manager 36 . This flow chart constitutes a loop process in which the data management table in the title to be reproduced is read (step S111), the data management table has the highest reading priority, and at the same time, the application with the smallest applicaitonID is set as the application After program i (step S112), after passing through the judgment of step S113, step S114, repeat the processing that application program i is preloaded on the local memory 29 (step S115), until it is judged that step S116 is "No" And step S117 is "NO". the

Step S113 judges whether the read-in attribute of the application program i is preloading, and step S114 judges whether the read-in priority of the application program is Mandatory or Optional. If it is judged as preloading in step S113, and the read priority is judged as Mandatory in step S114, then the application program is preloaded into the local storage 29 (step S115). If it is determined in step S113 that the read attribute is load, steps S114 to S115 are skipped. the

In step S116 of the two steps defining the termination requirements of the loop processing, it is judged whether or not there is an application program k having the next highest application ID and the same reading priority as the application program I. If there is such an application k, this application k is set as application i (step S119). the

Step S117 judges whether there is an application program with the second-lowest read-in priority in the data management table in the two steps of specifying the termination requirements of the loop processing, and if it exists, the smallest application program with the second-lowest read-in priority is selected. The applciationID is selected as application k (step S118), and this application k is set as application i (step S119). As long as these steps S116 and S117 are "YES", the above-mentioned processing of steps S113 to S115 is repeated. In step S116 and step S117, if there is no corresponding application program, the processing of this flowchart is terminated. the

Step S120 to step S123 are processes executed when it is determined in step S14 that the read priority=Optional. the

Step S120 judges whether there is an application j with the same applicationID and high read-in priority. the

Step S121 judges whether the residual capacity of the local storage 29 is higher than the size of the application program i. In the case of "No" in step S120 and "Yes" in step S121, in step S115, the application program i is preloaded into the local memory 29. If "No" in step S120 and "No" in step S121, the process proceeds to step S116 without loading the application program i on the local storage 29 . the

In this way, if the judgment of step S120-step S121 is not “Yes” for the data whose priority level=Optional is read, preloading to the local storage 29 is not performed. The old playback device with a small memory size reads about 2 to 3 application programs, and the judgment in step S121 is "No", but even if the new playback device with a large memory size has loaded more The judgment does not become a "no". As described above, in the old playback device, only Mandatory applications are loaded into the local storage 29, and Mandatory applications and Optional applications are loaded into the new playback device. the

Step S122 is a step executed when the determination in step S120 is YES. In the local storage 29, if there is an application j with the same applicationID and a high read-in priority, it is judged whether the sum of the remaining capacity of the local storage 29 and the size of the application j exceeds the size of the application i (step S122 ), if it exceeds, preloading is performed by overwriting the application j on the local storage 29 with the application i (step S123). If it is low, the process proceeds to step S116 without preloading the application program i into the local storage 29 . the

An example of the reading process by step S115 and step S123 will be described with reference to FIG. 47( a ). FIG. 47( a ) is a diagram showing an example of a data management table assumed in this specific example. The three applications in the figure are stored in three files respectively, with the same applicationID (applicationID=1), but different reading priorities (mandatory, optional: high, optional: low). If such a data management table is to be processed, the application program whose reading priority=Mandatory is read into the local storage 29 by step S115. However, for the application whose reading priority=Optional, after the judgments in steps S120 to S122, the reading is performed in step S123. In step S123 different from step S115, since the preloading is performed so that it overwrites the application program with the same applicationID already existing in the local storage 29, one of the plurality of application programs is exclusively loaded into the local storage 29 in. the

i) After reading in the application program with read-in priority=mandatory, when reading in the application program with read-in priority=optional:high each time, if step S122 judges as "no", then keep it in the local storage 29 Read in applications with priority = mandatory. After reading in the application program with read-in priority=mandatory, when reading in the application program with read-in priority=option:high each time, if step S122 is judged as "yes", then by reading in priority=optional: high to overwrite the application with read-in priority=mandatory, and keep the read-in priority=optional:high application in the local storage 29. the

ii) after reading in the application program with read-in priority=optional:high, when reading in the application program with read-in priority=optional:low each time, if step S122 judges as "no", then the local storage 29 Applications with read-in priority = Mandatory are reserved in . After reading in the application program of read-in priority=optional:high, when reading in the application program of read-in priority=optional:low each time, if step S122 judges as "yes", then by reading in priority= The application program with optional: low overrides the application program with read-in priority = optional: high (step S123 ), and the application program with read-in priority = optional: low is reserved in the local storage 29 . the

As long as the capacity of the local storage 29 allows, the process of covering the application program on the local storage 29 is repeated, so the storage content of the local storage 29 becomes mandatory=optional: high=>optional: low as shown in Figure 47 (b). . Since Java archive files of different sizes can be loaded into the local storage 29 according to the size of the memory, for a playback device with a small memory size, Java archive files of thumbnail images having the necessary minimum resolution are loaded into the local storage 29. Among them, for a playback device with a medium memory size, the Java archive file of an SD image with a medium resolution is loaded into the local storage 29, and for a playback device with a large memory size, an HD image with a high resolution is loaded. The Java archive file is loaded into the local memory 29. With this loading, images with different resolutions can be displayed according to the size of the memory, and the expressive range of title production by the authorized person can be widened. the

FIG. 48 is a diagram showing a specific example of reading processing of the reference data management table. The two applications in the figure represent two applications to which the same applicationID (application#3) has been added. One of them is embedded in AVClip, and the read priority is set to mandatory. On the other hand, it is recorded in a file different from AVClip, and the recording priority is set to Optional. Since the former application is embedded in the AVClip, the life span corresponding to the embedded portion is described as a life span (title#1: chapter#4 to #5). Among these applications, application#2 and application#3 have added read-in attributes representing loading. Since application#2 uses Chapter #1-Chapter#2 as the life span, and application#3 uses Chapter#4-Chapter#5 as the life span, one of them resides exclusively in the local storage 29 on the title timeline. Fig. 48(b) is a diagram showing application#2 and application#3 stored exclusively at different times on the title time axis. This is for the purpose of playback on a playback device with only a minimum necessary memory size in consideration. If the data management table of such content is the object of processing, the application manager 36 performs different processing according to the size of the memory through the above-mentioned flowchart of FIG. 46 . the

Since read priority=load, the latter application is loaded onto the local storage 29 . Through this process, the application manager can load data into the local storage 29 as long as the storage size is Mandatory. What becomes a problem here is the time of reading by a playback device with a large memory size. Regardless of the size of the memory, it is a waste of the memory size not to read application#3 before reaching Chapter#4~Chapter#5. Therefore, the same application#3 is added to the same application#3 in the data management table of the figure, and recorded on the BD-ROM, and the same applicationID is added thereto. the

Since the former application read-in priority=Optional, preloading is performed as long as it is YES in step S121 (step S115). Thus, a playback device with a large memory size can load the same application program as the application program embedded in the AVClip into the local storage without waiting for the arrival of title#1, Chapter#4 to Chapter#5 (FIG. 48(c) )). the

The above is the processing at the time of preloading. Next, the processing procedure at the time of loading will be described. the

Fig. 49 is a diagram showing the processing procedure of loading processing based on the data management table. In this flowchart, the loop processing consisting of steps S131 to S133 is repeated while the playback of the title is continued. the

Step S131 is to judge whether the live interval of the application having the startup attribute indicating AutoRun has arrived. If arrival, then set the application program with the startup attribute that represents AutoRun as application program q (step S134), send the startup indication that shows startup application program q to Java virtual machine 38, and read out from local memory 29 to working memory 37. Application q (step S135). the

Step S133 judges whether the reproduction of the PL in the title is completely terminated. This determination is made by whether or not there is a playback termination event from the playback control engine 32 as in the fifth embodiment. If terminated, the processing of this flowchart is terminated. the

Step S132 judges whether there is a call from the starting application. If yes, set the call target application as application q (step S136), and judge whether the current playback time is within the life span of application q in the application management table (step S137). If it is not in the survival interval, it will display that the startup failed (step S148), and return to the loop processing composed of steps S131 to S133. If it is a live range, the loading process is performed according to the flowchart in FIG. 50 . the

Step S138 in FIG. 50 judges whether or not the current playback time is the life span of the application q in the data management table. If it is not in the live area, the application program q cannot be loaded into the local storage 29 . At this time, an instruction to start the application q is issued to the Java virtual machine 38, and the application q is directly read from the BD-ROM to the work memory 37 without passing through the local memory 29. At this time, since a header search for reading the application program occurs, PL playback is interrupted (step S145). the

If it is the life span, then in step S139, it is judged whether the read-in attribute has been added to the application program. The so-called no read-in attribute means no loop or cross-application q. However, placing an application on the local storage 29 is allowed even if the read-in attribute is not added. Therefore, the application program is read out after knowing that playback has been interrupted. That is, after the application program is read from the BD-ROM to the local storage 29, the application program is read to the work memory 37 (step S140). the

Step S141 to step S146 are processes performed when the determination of step S139 is "YES". In step S141, it is determined whether the application program is preloaded by referring to the read-in attribute. If preloading is performed, go to step S135. the

Step S142 is a judging step executed when the read-in attribute is loading, and it is judged whether to loop or cross application q. If interleaved, the Java virtual machine 38 is caused to execute cache sensing (step S143). If the application program q exists in the local memory 29, the process proceeds to step S135, and the application program q is loaded onto the Java virtual machine 38. the

If there is no application program on the local storage 29, exception processing branching to the top menu title and the like is performed (step S144). If the loop is performed, a timer is set (step S148), and the Java virtual machine 38 is caused to execute cache sensing (step S146) until the timer expires (step S147). If the application program q appears on the local storage 29, then enter step S135 of FIG. 49, and the application program q is loaded on the Java virtual machine 38. If overtime, then carry out branching to the exception processing (step S144) of top menu title etc. the

FIG. 51 is a diagram schematically showing how to load an application program by the Java virtual machine 38 . the

Arrows ◎1 and 2 represent the reading of a Java archive file that exists on the application management table and that exists on the data management table and that has a read attribute indicating loop and crossover. Arrow ◎1 indicates the sensing of the local memory 29 performed in steps S65 and S67. This local storage 29 sensing is performed in the local storage 29 because there may be data embedded in the local storage 29 by looping or crossing. Arrow ⊚2 indicates reading corresponding to step S135 , and indicates loading from the local storage 29 to the work memory 37 when the application program exists in the local storage 29 . An arrow with a x indicates that there is no data on the local storage 29 . the

1、2表示：在应用程序管理表上生存、但是不在数据管理表中生存、且读入属性不存在的Java归档文件的读入。  arrow

1 and 2 represent: the reading of a Java archive file that exists in the application management table but does not exist in the data management table and whose read attribute does not exist.

1对应于步骤S145中的读入，表示：基于Java虚拟机38的来自BD-ROM的直接读取的请求。箭头

2表示基于该要求的从BD-ROM向工组存储器37的Java归档文件读出。  arrow

1 corresponds to the reading in step S145 and indicates a request for direct reading from the BD-ROM by the Java virtual machine 38 . arrow

2 indicates reading of the Java archive file from the BD-ROM to the group storage 37 based on the request.

Arrows ☆1, 2, and 3 indicate the reading of a Java archive file that exists in the application management table and data management table, but does not have the read attribute. the

Arrow ☆1 corresponds to the reading in step S140, and indicates a direct reading request from the BD-ROM by the Java virtual machine 38. Arrow ☆2 indicates the reading of the Java archive file to the local storage 29 based on this request. Arrow ☆3 indicates reading of the Java archive file from the local storage 29 to the work memory 37 . the

As described above, according to the present embodiment, since the number of applications concurrently resident on the local storage 29 can be set to a predetermined number or less, cache loss at the time of reading from the local storage 29 can be avoided as much as possible. Since the reading of the application program without cache loss can be ensured, the application program is not read from the BD-ROM every time the application program is invoked until playback of the AVClip is stopped. Since AVClip playback is not interrupted midway, seamless playback of AVClip can be guaranteed. the

(seventh embodiment)

In the third embodiment, the time axis of the non-AV title is determined according to the lifetime of the application program. However, the operation of the application program is unstable, and there may be startup failure and abnormal termination. This embodiment proposes a failure safety mechanism in the case of startup failure or abnormal termination. Fig. 52(a) is a diagram showing the internal structure of a BD-J object according to the seventh embodiment. Compared with Fig. 7(b), this figure is new in that the playlist management table is added. the

Fig. 52(b) is a diagram showing an example of a playlist management table. As shown in the figure, the playlist management table is composed of designation of PLs and playback attributes of the PLs. The designation of the PL indicates the playable PL in the title time axis of the corresponding title. The playback attribute of the PL indicates whether to automatically play back the designated PL simultaneously with the start of title playback (the PL automatically played back in this way is called a default PL). the

Next, how to define the title time axis by the playlist management table will be described with reference to FIG. 53 . FIG. 53( a ) is a diagram showing the time axis of a title in a non-AV title when the playback attribute is set to indicate non-automatic playback. At this time, since the default PL is not played back, the title time axis is also determined from the lifetime of the application for non-AV titles. the

Fig. 53(b) is a diagram showing a title time axis of a non-AV title whose playback attribute is set to AutoPlay. If the playback attribute is set to indicate AutoPlay, the playback control engine 32 starts playback of the default PL at the same time as playback of the non-AV system title starts. However, even if the application program operates normally and terminates normally, the title time axis is determined based on the PL time axis. the

Fig. 53(c) shows a case where the playback attribute is set to "AutoPlay" in the playlist management table and the application terminates abnormally. Due to this abnormal termination, no application programs are operated, but the playback of the default PL continues. At this time, the PL time axis of the default PL is the title time axis. the

Fig. 53(d) shows a case where the playback attribute indication "AutoPlay" is set in the playlist management table and the main application fails to start. At this time, since the playback of the default PL by the playback control engine 32 is performed regardless of failure to start the application, the time axis of the default PL becomes the title time axis. the

As described above, if the playback attribute of the playlist management table is set to "AutoPlay", even if it takes 5 to 10 seconds to start the Java application, it will be changed to "copy anyway" during the start-up. what state". By setting the "status of what to copy anyway", it is possible to compensate for the start-up delay at the start of title execution. ``

The above is the improvement on the recording medium in this embodiment. Next, improvements to the playback device of this embodiment will be described. the

Fig. 52(c) is a diagram showing what kind of processing the playback device performs when there is a PL whose playback attribute is set to AutoPlay in the playlist management table of the branch destination title. As shown in the figure, if the PL whose playback attribute is set to AutoPlay exists in the playlist management table of the branch target title, the application manager 36 in the BD-J module 35 instructs the playback control engine 32 to set The reproduction of the AutoPlayPL starts immediately after the branch. In this way, the PL whose playback attribute is AutoPlay commands the start of playback immediately after the title branch. the

The application program manager 36 performs processing as shown in FIG. 54 in response to the improvement of the recording medium described above. the

FIG. 54 is a flowchart showing the processing procedure of the application manager 36 of the seventh embodiment. In the flowchart of FIG. 38 , steps S103 and S104 are added before step S21, step S100 is added between steps S21 and S22, and step S105 is added between steps S23 to S26. the

Step S103 judges whether the playback attribute of the playlist management table of the corresponding title is AutoPlay. If it is AutoPlay, the playback control engine 32 is caused to start playback control of the default PL (step S104). the

Step S100 judges whether or not the presentation engine 31 is playing back. If playback is in progress, go to step S101. the

Step S105 is a judging step executed when the result of step S23 is "Yes" and step S25 is "No", and indicates whether the playback attribute is AutoPlay or not. If not, the module manager 34 is notified of the title termination. If it is AutoPlay, proceed to step S101 and continue processing. the

Fig. 55 is a diagram schematically showing how playback is performed by setting "playback attribute = AutoPlay" in the playlist management table. Here, the title to be reproduced is a non-AV title of a game application including tiles that are superimposed and dropped. In this non-AV title, if the playback attribute of the playlist management table is set to AutoPlay, default PL playback by the playback control engine 32 also starts. Since the execution of the game application and the playback of the default PL are performed in parallel, as shown on the upper left side of FIG. 55 , a composite image is displayed in which the game application screen is the foreground and the default PL playback image is the background. Assume that the game application terminates abnormally midway. Although the game application is forcibly terminated by the application manager 36, the playback of the default PL continues, so the title becomes a state of copying something. By specifying the playback attribute in the playlist management table, even when the game application in the non-AV system title terminates abnormally, it is possible to maintain the operation without damage and stoppage. the

(eighth embodiment)

In the first embodiment, the BD-J object has two titles, the data management table and the application management table, but this embodiment discloses a form in which these are integrated into one table. In this integration, as shown in FIG. 56(a), the read attribute item in the data management table is discarded, and an attribute called Ready attribute is set in the start attribute instead. The Ready attribute is a type of start attribute included in calls from other applications and calls from the application manager 36 , indicating that the application is preloaded on the local storage 29 . the

Fig. 56(b) is a diagram showing the relationship between application processing and activation attributes. As shown in the first embodiment, the processing of the application program includes: whether to preload (1), the current playback time is automatically activated when the effective period comes, or activated by other calls (2), depending on the playback progress of the title Carrying out loading (3), there is a difference whether there is survival or not, and according to these differences, five forms as shown in Fig. 56(b) appear. Among them, the case of setting the startup attribute to AutoRun is the case of performing preloading, "automatic startup", and the case of performing loading, "automatic startup". the

On the other hand, setting the start attribute to the Ready attribute indicates a case where preloading or loading is performed, and the start item is "call start". the

Also, there will be no types that live in the working memory 37 but are not loaded in the local memory 29 . This is because the live range of the work memory 37 and the live range of the local memory 29 are integrated in the application data management table. the

Since the Ready attribute is added as the startup attribute, the application manager 36 preloads the application whose startup attribute is set to AutoRun and the application whose startup attribute is set to the Ready attribute before playing back the title. Processing in memory 29 . Thus, even if the read attribute is not set, processing of preloading the application program into the local storage 29 can be performed. the

FIG. 57 is a diagram schematically showing how to load an application program by the Java virtual machine 38 according to the eighth embodiment. Based on FIG. 51 , a representation diagram of the reading in this figure is made. the

Arrows ◎1 and 2 indicate the reading of a Java archive file which exists in the application/data management table and whose startup attribute is set to the Ready attribute. the

Arrows ☆1, 2, and 3 indicate the loading of an application that exists in the application/data management table and whose activation attribute is Persistent. the

1、2的箭头的读入。这是因为应用程序·数据管理表一体化了应用程序管理表和数据管理表，所以不能表现应用程序管理表＝生存、数据管理表＝不存在的组合。  These arrows ◎1, 2 and arrows ☆1, 2, 3 are described in Fig. 51, but they do not exist in Fig. 57 and are equivalent to those described in Fig. 51

1, 2 Arrow reading. This is because the application/data management table is an integration of the application management table and the data management table, so the combination of application management table=existence and data management table=absence cannot be expressed.

As described above, according to this embodiment, since the data management table and the application management table can be organized into one table (application data management table), processing by the application manager 36 can be simplified. In addition, the application/data management table can be further simplified by not having the read priority. the

(Ninth Embodiment)

In the first embodiment, when an application program is read into the local storage 29, the read priority is referred to, and the read process is assigned superiority or inferiority according to the read priority. On the other hand, the ninth embodiment is an embodiment in which the reading priority is indicated by a combination of information meaning Optional and a numerical value from 0 to 255. the

58( a ) and ( b ) are diagrams showing an example of read priority in the ninth embodiment. 255 and 128 are examples of read priorities ranging from 0 to 255, which means that application#2 has a higher read priority than application#3 in this example. the

In this embodiment, as in the first embodiment, the application manager 36 first reads into the local storage 29 an application to which a read priority indicating Mandatory is added. the

Afterwards, for the application to which the read priority indicating Optional is added, it is judged whether or not the capacity in the local storage 29 exceeds the size of the application. If it exceeds, the application program to which the read priority=Optional is added is read into the local storage 29 as it is. If it is small, among the data constituting the application program, the application program with the highest value indicating the reading priority is read into the local storage 29 . Then, the application program whose reading priority is low is read to the remaining area in the local storage 29 . the

Thus, even if the entire application program of the optional process does not have the capacity to be stored in the local storage 29 of the playback device, a part thereof can be stored in the local storage 29 . the

(tenth embodiment)

In the first embodiment, the application manager 36 exclusively loads the applications to which the same applicationID is added into the local storage 29 according to the read-in priority, but in the tenth embodiment, by applying a group attribute to the application, Exclusive loading. Fig. 59 is a diagram showing a data management table to which group attributes are added. The group attribute can have two settings of not being an exclusive group and being an exclusive group. In the case of an exclusive group, describe its group number. "-" in title#1 in Fig. 59(a) indicates that there is no exclusive group. On the other hand, "group#1" of title#2 and #3 has an exclusive group, and title#2 and #3 indicate the exclusive group belonging to group#1. The above is the improvement of the recording medium of this embodiment. the

The playback device according to this embodiment checks the group attributes of the applications in the local storage 29 after reading each application into the local storage 29 based on the data management table. Similarly, if two or more applications belonging to the exclusive group exist on the local storage 29 , one of them is deleted from the local storage 29 . the

Thereby, the use efficiency of the local memory 29 can be improved. As a specific example of an exclusive group, a group consisting of a start-up application program and an application program started by the program corresponds. Since the application program activated by this application program is limited to one in principle, only the activated + 1 application programs should exist on the local storage 29 . If there are more than three application programs, the application program manager 36 needs to delete it from the local storage 29, so the group attribute of each application is set, and whether the application program existing on the local storage 29 is started +1 for the verification of the app. the

Fig. 59(a) is a diagram showing access to the local storage 29 based on the application management table. In this figure, since the group attribute of application#2 and application#3 set to read priority=Optional is group#1, these applications belong to the same exclusive group. Of the three applications, application#1 is the startup application described above, and since application#2 and application#3 are the startup applications, a group attribute is added so that only one of them exists in the local storage 29 . The application manager 36 refers to the group attributes of application#2 and application#1=3, and deletes any one from the local storage 29 . This deletion creates free space on the local storage 29. the

(Eleventh Embodiment)

In the first embodiment, the application management table is provided for each title, but in the present embodiment, it is proposed to change the allocation unit of the application management table. Fig. 60 is a diagram showing changes in allocation units. In this figure, the first level shows the three application management tables recorded on the BD-ROM, the second level shows the title unit, the third level shows the disc unit, and the fourth level shows the disc setup composed of a plurality of BD-ROMs. unit. The arrows in the diagram schematically represent the allocation of application management tables. Referring to the arrows, it can be seen that the application management tables #1, #2, #3 in the first level are assigned to the titles #1, #2, #3 shown in the second level, respectively. In addition, the application management table #4 is assigned in units of disks, and the application management table #5 is assigned to the entire disk setting. In this way, by setting the unit of the application management table to a unit larger than the title, it is possible to define the period during which the application to be stored and one of the plurality of BD-ROMs is loaded during the period when one BD-ROM is loaded. survival app. the

(refer to)

The above description should not represent all forms of implementation of the present invention. The present invention can also be carried out by implementing the following modified forms of (A) (B) (C) (D) . . . The respective inventions in the claims of the present application are descriptions that expand or generalize the above-described plural embodiments and modifications thereof. The procedures of expansion and generalization are based on the characteristics of the technical level at the time of application of the technical field of the present invention. the

(A) In all the embodiments, the optical disc of the present invention is implemented as a BD-ROM. However, the optical disc of the present invention has characteristics in recorded dynamic scenarios and index tables, and these characteristics do not depend on the physical properties of the BD-ROM. If the recording medium on which the dynamic script and the index table are recorded, it may be any recording medium. For example, optical disks such as DVD-ROM, DVD-RAM, DVD-RW, DVD-R, DVD+RW, DVD+R, CD-R, and CD-RW, and optical disks such as PD and MO may be used. Also, a semiconductor memory card such as a compact flash card, smart media, memory stick, multimedia card, or PCM-CIA card may be used. It can also be a floppy disk, SuperDisk, Zip, Clik! Such as a magnetic recording disk (i), ORB, Jaz, SparQ, SyJet, EZFley, a removable hard disk drive (ii) such as a micro drive, and a built-in hard disk drive may also be used. the

(B) The playback device in all the embodiments decodes the AVClip recorded on the BD-ROM and then outputs it to the TV. However, the playback device may be only a BD-ROM drive, and the TV has In addition to other components, in this case, playback devices and TVs can be integrated into a home network connected by IEEE1394. In addition, the playback device in the embodiment is a drive used in connection with a television, but may also be a playback device integrated with a display. Furthermore, in the playback device of each embodiment, only the part that becomes the essential part of the processing may be used as the playback device. Since these playback devices are all inventions described in this specification, even in any of these forms, the act of manufacturing a playback device based on the internal structure of the playback device shown in each embodiment is also included in the specification of this application. Acts of implementation of the invention described in. Transfer (sell if paid, donate if free), lending, and input of the playback device described in each embodiment are all embodiments of the present invention. Acts of proposing these transfers and leases to general users through storefront display, catalog offer, and brochure distribution are also implementation acts of this playback device. the

(C) Since the information processing based on the programs shown in the respective flowcharts is realized concretely using hardware resources, the individual programs showing the processing procedures in the above-mentioned flowcharts are established as inventions. All the embodiments have shown the implementation of the program of the present invention in the form of being incorporated into the playback device, but the program shown in each embodiment may be implemented separately from the playback device. Acts of implementing individual programs include the act of producing these programs (1), the act of transferring the program with compensation or free of charge (2), the act of lending (3), the act of importing (4), and the act of sending the program via two-way electronic communication lines to The act of offering to the public (5), and the act of proposing transfer and rental of programs to general users through (6) storefront display, catalog offer, and brochure distribution. the

(D) The "time" element of each step executed in time series in each flow chart is regarded as an essential item for specifying the invention. Thus, it can be seen that the processes based on these flow charts disclose the usage manner of the reproduction method. If the original purpose of the present invention is achieved by performing the processing of each step in time series and the processing of these flow charts, and the functions and effects are achieved, it is of course equivalent to the implementation behavior of the recording method of the present invention. the

(E) A menu (ChapterMenu) for displaying a list of Chapters and a MOVIE object for controlling its behavior may be recorded on the BD-ROM and branched from the top menu. In addition, it can also be called by pressing the Chapter key of the remote control key. the

(F) It is preferable to add an extension header to each TS packet constituting an AVClip every time it is recorded on a BD-ROM. The extension header is called TP_extra_header, contains "Arribval_Time_Stamp" and "copy_permission_indicator", and has a data length of 4 bytes. TS packets with TP_extra_header (hereinafter referred to as TS packets with EX) are grouped every 32 and written into three sectors. A group consisting of 32 EX-attached TS packets is 6144 bytes (=32×192), which coincides with three sector sizes of 6144 bytes (=2048×3). The 32 TS packets with EX contained in three sectors are called "Aligned Unit". the

When using a local network connected via IEEE1394, the playback device 200 transmits the Aligned Unit through the following transmission process. That is, the device on the sending side extracts the TP_extra_header from each of the 32 TS packets with EX included in the AlignedUnit, encrypts the TS packet header according to the DTCP standard, and outputs it. Every time a TS packet is output, an isochronous packet is inserted at an arbitrary position between the TS packets. This insertion position is based on the time indicated by Arribval_Time_Stamp of TP_extra_header. Along with the output of the TS packets, the playback device 200 outputs the DTCP_Descriptor. DTCP_Descriptor indicates the copy permission setting in TP_extra_header. If DTCP_Descriptor is described here so that it means "copy prohibited", then TS packets will not be recorded on other devices when using a local network connected via IEEE1394. the

(G) In each embodiment, the digital stream recorded on the recording medium is an AVClip, but it may be a DVD-Video standard or a VOB (video object) of the DVD-Video recording standard. VOB is an ISO/IEC13818-1 standard program stream obtained by multiplexing a video stream and an audio stream. In addition, the video stream in AVClip can also be MPEG4 and MMV. Further, the audio stream can also be Linear-PCM, Dolby-AV3, MP3, MPEG-AAC, Dts, WMA (Windows media audio). the

(H) The video work in each embodiment can also be obtained by encoding an analog video signal broadcast by analog broadcasting. It may also be stream data constituted by a transport stream broadcast by digital broadcasting. the

In addition, the content can also be obtained by encoding an analog/digital video signal recorded on a video tape. Furthermore, it is also possible to encode the analog/digital video signal directly obtained from the camera to obtain the content. In addition, it may also be a digital work sent through a sending server. the

(I) The BD-J module 35 may be a Java platform embedded in the device for satellite broadcast reception. If the BD-J module 35 is the Java platform, the playback device of the present invention also serves as an MHP STB. the

Furthermore, a Java platform embedded in the device may be used to control the processing of the mobile phone. If the BD-J module 35 is the Java platform, the playback device of the present invention also functions as a mobile phone. the

(K) In the layer model, the MOVIE mode can also be arranged on the BD-J mode. This is because the interpretation of the dynamic scenario and the execution of the control process based on the dynamic scenario in the MOVIE mode are light on the playback device, so that no problem occurs even if the MOVIE mode is executed in the BD-J mode. This is because motion assurance is accomplished in one mode at the time of development of a reproduction device and a video work. the

Furthermore, playback processing may be performed only in BD-J mode. As shown in the fifth embodiment, since playback control synchronized with playback of PL can be performed in BD-J mode, this is the reason why it is not necessary to forcibly set MOVIE mode. the

(L) Branching from a certain PL to another PL can also be realized by setting a navigation command on an interactive video stream to be multiplexed on an AVClip. the

Industrial Availability

The playback device of the present invention can be used for personal use as in a home theater system. However, the present invention discloses an internal structure in the above-mentioned embodiments, and since mass production is possible with this internal structure, it can be practically used industrially. Therefore, the playback device of the present invention has industrial applicability. the

Claims (5)

1. recording method, recording indexes table, application program and pattern object is characterized in that in recording medium,

Said concordance list is represented the corresponding relation between title and the pattern object,

Said pattern object comprises the application program management table,

Said application program is to use the program of describing towards the programming language of virtual machine,

Said application program management is expressed with the interval for survival application program more than 1 of the title corresponding with said pattern object.

2. recording method according to claim 1 is characterized in that, said recording method is to said recording medium archive file, and this archive file stores constitutes application's data and program;

The combination that with the interval for survival application program of said each title is the title number of being inscribed by the identifier of the archive file that stores said application program and only table indicating shows.

3. transcriber is carried out in recording medium with the interval for survival application program of the title of correspondence, it is characterized in that, comprising:

Module management based on concordance list, is selected to the title of branch target title from a plurality of titles,

Module is used for executive utility;

In recording medium, record concordance list, application program and pattern object,

Said concordance list is represented the corresponding relation between title and the pattern object,

Said pattern object comprises the application program management table,

Said application program is to use the program of describing towards the programming language of virtual machine,

Said application program management is expressed with the interval for survival application program more than 1 of the title of correspondence,

Said module has application manager; Said application manager is under the situation of having selected the branch target title; The reference applications admin table judges whether to exist with the interval for survival application program of the title corresponding with the branch target title; Only for survival under the situation of interval application program, start this application program existing with the title of correspondence.

4. transcriber according to claim 3 is characterized in that:

The termination control of said application manager is following control: under the situation of having selected the branch target title; Reference table judges whether to exist in the application program in startup not with the interval for survival application program of branch target title; For survival under the situation of interval application program, stop existing not with the interval for survival application program of branch target title with the branch target title.

5. reproducting method is carried out in recording medium with the interval for survival application program of the title of correspondence, it is characterized in that, comprising:

Management process based on concordance list, is selected to the title of branch target title from a plurality of titles; And the module step, be used for executive utility,

In recording medium, record concordance list, application program and pattern object,

Said concordance list is represented the corresponding relation between title and the pattern object,

Said pattern object comprises the application program management table,

Said application program is to use the program of describing towards the programming language of virtual machine,

Said application program management is expressed with the interval for survival application program more than 1 of the title of correspondence,

Said module step is under the situation of having selected the branch target title; The reference applications admin table judges whether to exist with the interval for survival application program of the title corresponding with the branch target title; Only for survival under the situation of interval application program, start this application program existing with the title of correspondence.

Images