WO2005036555A1 - 記録媒体、再生装置、プログラム、再生方法 - Google Patents

記録媒体、再生装置、プログラム、再生方法 Download PDF

Info

Publication number
WO2005036555A1
WO2005036555A1 PCT/JP2004/015339 JP2004015339W WO2005036555A1 WO 2005036555 A1 WO2005036555 A1 WO 2005036555A1 JP 2004015339 W JP2004015339 W JP 2004015339W WO 2005036555 A1 WO2005036555 A1 WO 2005036555A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
title
playback
attribute
branch
Prior art date
Application number
PCT/JP2004/015339
Other languages
English (en)
French (fr)
Inventor
Wataru Ikeda
Hiroaki Iwamoto
Tomoyuki Okada
Original Assignee
Matsushita Electric Industrial Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to CN2004800296950A priority Critical patent/CN1867998B/zh
Priority to EP04773789A priority patent/EP1677302A4/en
Priority to US10/573,173 priority patent/US7515812B2/en
Priority to JP2005514682A priority patent/JP3825463B2/ja
Priority to KR1020067007232A priority patent/KR101059343B1/ko
Publication of WO2005036555A1 publication Critical patent/WO2005036555A1/ja
Priority to US12/393,001 priority patent/US8107788B2/en
Priority to US12/797,804 priority patent/US8406604B2/en

Links

Classifications

    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/12Formatting, e.g. arrangement of data block or words on the record carriers
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327Table of contents
    • G11B27/329Table of contents on a disc [VTOC]
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/21Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213Read-only discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2541Blu-ray discs; Blue laser DVR discs

Definitions

  • Control technologies for virtual machines such as Java programs have permeated various technology fields, including communications and broadcasting.
  • technology for operating Java applications in accordance with digital video playback has already been established, and various services involving menu control by Java applications are attracting the interest of viewers.
  • An object of the present invention is to provide a playback device that can avoid a long title boundary due to repeated application port-do application termination.
  • the recording medium is characterized in that the branch destination title has an automatic start attribute for automatically starting the application.
  • the auto-start attribute in this recording medium indicates that when the application is not running at the branch source, the application is automatically started. Only launch the application.
  • Application startup is limited to the combination of the non-starting branch source and the automatic startup attribute of the branching destination, so the branching between the titles makes the playback complicated, and the application startup process is performed redundantly Not in Since redundant application startup can be avoided, title boundaries can be shortened. This makes it possible to realize smooth playback control without making the user aware of the title boundary. For this reason, it is particularly effective when providing long-form content that covers multiple titles or series content recorded on multiple BD-ROMs, such as a DVD-BOX.
  • FIG. 1 is a diagram showing a mode of use of the playback device according to the present invention.
  • FIG. 2 is a diagram showing a file 'directory structure on a BD-ROM.
  • FIG. 3 is a diagram showing the relationship between the AVClip time axis and the PL time axis.
  • FIG. 4 is a diagram showing a batch specification made by four Clips—Information_file—names.
  • FIG. 5 is a diagram showing a chapter definition by PLraark.
  • FIG. 6 is a diagram showing a playback section definition on the SubPlayltem time axis and synchronization designation.
  • FIG. 7 (a) is a diagram showing the internal structure of the] Movie object.
  • FIG. 7B shows the internal structure of the BD-J object.
  • FIG. 9 (a) is a diagram showing a series of titles such as a top menu, title # l, and title # 2.
  • FIG. 9B is a diagram showing a time axis obtained by adding the time axes of PlayList # 1 and PlayList # 2.
  • Figure 10 is a diagram showing the disc contents including three titles: main title, online shopping title, and game title.
  • FIG. 11 is a diagram showing an example of the reproduced images of the three titles shown in FIG.
  • FIG. 12 (a) is a graph in which the life span of each application is graphed from the membership shown by the broken line in FIG.
  • FIG. 12 (b) is a diagram showing an example of an application management table described in order to define the live range of FIG. 12 (a).
  • FIG. 13A is a diagram showing an example of the activation attribute setting.
  • FIG. 13 (b) is a diagram showing an application (application # 2) that is started for the first time when an application is called from another application.
  • FIGS. 14 (a) and 14 (b) are diagrams showing an example of an application management table and a live range in which Suspend is significant.
  • FIG. 15 is a diagram showing combinations of three modes (Persistent, AutoRun, and Suspend) that the startup attribute can take and three modes of the application state in the immediately preceding title (non-start, running, and Suspend).
  • FIG. 16 is a diagram showing the internal configuration of the playback device according to the present invention.
  • FIG. 17A is a diagram showing how the Java archive file existing on the BD-ROM is identified on the oral memory 29.
  • FIG. 17 (b) is a diagram showing an application of FIG. 17 (a).
  • FIG. 19 is a diagram schematically illustrating processing by the Presentation Engine 31 to the module manager 34. .
  • FIG. 20 is a diagram schematically illustrating a process performed by the application manager 36.
  • FIG. 21 is a diagram showing the work memory 37 to the Default Operation Manager 40.
  • FIG. 22 is a diagram showing a control procedure at the time of branching by the application manager 36.
  • FIG. 23 is a flowchart showing the processing procedure of the application termination processing.
  • FIG. 24 is a diagram schematically showing a process of terminating the application.
  • FIG. 25 (a) is a diagram showing an application management table in which a live range is defined on a PL time axis.
  • FIG. 25 (b) is a diagram showing the life cycle of the application based on the application management table of FIG. 25 (a).
  • Figure 26 (a) shows the title time axis determined from the PL time axis.
  • Figure 2 (b) shows the title time axis determined from the life span of the main application.
  • Figure 26 (c) is a diagram showing a title time axis determined from the life spans of multiple applications.
  • FIG. 27 is a flowchart showing the processing procedure of the application manager 36 during title playback.
  • FIG. 28A is a diagram showing a menu hierarchy realized by the BD-ROM.
  • FIG. 28 (b) is a diagram showing a MOVIE object for implementing the menu hierarchy.
  • FIG. 29 is a diagram schematically showing an Index Table and branching from the Index Table to each Movie object.
  • FIG. 30 (a) shows a branch when the Index Table is described as shown in FIG. 29 (b).
  • Figure 30 (b) shows the branch when the non-AV title is forcibly terminated.
  • FIG. 31 is a flowchart showing a processing procedure of the module manager 34.
  • FIG. 32 is a diagram showing an operation example of application termination by the application manager 36.
  • Fig. 33 is a flowchart showing the PL playback procedure using Playback Control Engine 32.
  • FIG. 34 is a flowchart showing a procedure for accepting angle switching, SkipBack, and SkipNext. .
  • FIG. 35 is a flowchart showing the processing procedure when SkipBack and SkipNext API are called.
  • FIG. 36 is a flowchart showing details of the processing procedure by the Presentation Engine 31.
  • FIG. 37 is a flowchart showing the playback procedure of SubPlayltem.
  • FIG. 38 is a flowchart showing a processing procedure of the application manager 36 according to the fifth embodiment.
  • FIG. 41 (b) is a diagram showing a data management template described in order to define the Java archive file live range in FIG. 41 (a).
  • Figure 42 is a diagram showing the embedding of a Java archive file by carouselization. .
  • FIG. 43 (a) is a diagram showing AVClip embedding by interleaving.
  • FIG. 43 (b) is a diagram showing three types of read attributes.
  • FIG. 44A shows an example of the data management table.
  • FIG. 44 (b) is a diagram showing the transition of the storage contents of the roll memory 29 due to the assignment of the data management table of FIG. 44 (a).
  • FIG. 45 (a) is a diagram showing the memory size of the local memory 29 in the old and new playback devices in comparison.
  • FIG. 45 (b) is a diagram showing an example of a data management table in which read priorities are set.
  • FIG. 46 is a diagram showing a processing procedure of preload control by the application manager 36.
  • FIG. 47 (a) is a diagram showing an example of a data management table defining a plurality of applications having the same applicationID but different read priorities.
  • Fig. 47 (b) shows the low power due to the allocation of the data management table in Fig. 47 (a).
  • 11 is a diagram showing changes in the contents stored in the memory 29.
  • FIG. 48 (a) is a diagram showing an example of a data management table in which an application to be preloaded and an application to be loaded are described to be given the same applicationID.
  • FIG. 48 (b) is a diagram showing the transition of the storage contents of the oral memory 29 in the playback device having a small memory scale.
  • FIG. 49 is a diagram showing a processing procedure of the load processing by the application manager 36 based on the data management table.
  • -FIG. 50 is a diagram showing a processing procedure by the application manager 36 when the current playback time reaches the live range of the application q.
  • FIG. 52 (a) is a diagram showing the internal structure of a BD-J object according to the seventh embodiment.
  • FIG. 52 (b) is a diagram showing an example of the playlist management table.
  • FIG. 52 (c) is a diagram showing what processing is performed by the playback device when a PL whose playback attribute is set to AutoPlay exists in the playlist management table of the branch destination 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 (c) is a diagram illustrating a case where the playback attribute is set to indicate "AutoPlay” in the playlist management table and the application is forcibly terminated.
  • FIG. 53 (d) is a diagram showing a case where the playback attribute is set to indicate “AutoPlay” in the playlist management table and the main application fails to start.
  • FIG. 54 is a flowchart showing the processing procedure of the application manager 36 according to the seventh embodiment.
  • Figure 56 (a) and (b) show the relationship between application handling and startup attributes.
  • FIG. 57 is a diagram schematically illustrating how an application is read by the Java virtual machine 38 according to the eighth embodiment.
  • FIGS. 58A and 58B are diagrams showing an example of the read priority according to the ninth embodiment.
  • FIG. 59 (a) is a diagram showing a data management table to which a group attribute has been added.
  • FIG. 59 (b) is a diagram showing access to the local memory 29 based on the application management table.
  • -FIG. 60 is a diagram showing the parity of the allocation unit of the application management table.
  • FIG. 1 is a diagram showing a mode of use of the playback device according to the present invention.
  • a reproducing apparatus according to the present invention is a reproducing apparatus 200, and forms a home theater system together with a television 300 and a remote control 400.
  • the disk content supplied to the home theater system by the BD-ROM is composed of multiple titles that can branch off from each other.
  • Each title is composed of one or more playlists and a dynamic control procedure using the playlists.
  • FIG. 2 is a diagram showing a file 'directory structure on a BD-ROM.
  • the BD-ROM has a BDMV directory under the Root directory.
  • the BDMV directory contains 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). Under this BDMV directory, there are four subdirectories called a PLAYLIST directory, a CLIPINF directory, a STREAM directory, and a BDAR directory.
  • the PLAYLIST directory contains files (00001.mpls, 00002.mpls, 00003mpls) with the extension mpls.
  • the CLIPINF directory contains files with the extension clpi (O0001.clpi, 00002.clpi, 00003.clpi).
  • the STREAM directory contains files (00001.m2ts, 00002.m2ts, 0003.m2ts) with the extension m2ts.
  • the BDAE directory contains files (00001.; jar, 00002.jar, 00003jar) with the extension jar. From the above directory structure, it can be seen that a plurality of files of different types are arranged on the BD-ROM.
  • AVClip (00001.m2ts, 00002.m2ts, 00003.m2ts) stores an AVClip.
  • AVClip has types such as MainCLip and SubClip.
  • MainClip is a digital stream obtained by multiplexing multiple elementary streams such as a video stream, an audio stream, a presentation graphics stream, and an interactive graphics stream.
  • the files with the extension “clpi” (00001.clpi, 00002.clpi, 00003.clpi) are management information corresponding to AVClips on a one-to-one basis. Because of the management information, the Clip information has information such as the encoding format of the stream in AVClip, the frame rate, the bit rate, the resolution, and the like, and the EP map indicating the cue position.
  • a time axis different from the AVClip time axis is defined. This is the PL time axis shown in the second row.
  • the definition of the Playltem information enables the definition of a time axis different from that of the AVClip.
  • PLmark information is information that designates an arbitrary section on the PL time axis as a chapter.
  • FIG. 5 is a diagram showing a chapter definition by PLmark.
  • the first row shows the AVClip time axis
  • the second row shows the PL time axis.
  • the arrow pkl, 2 in the figure indicates the Playltem designation (ref-to-Playltem_ld) and the temporary point designation (mark_time_stamp) in PLmark.
  • three chapters (Chaptei # 1, # 2, and # 3) are defined on the PL time axis.
  • the Movie object is a component of the "Title" and is stored in the file MovieObject.bdmv.
  • FIG. 7A shows the internal structure of a Movie object.
  • the Movie object consists of attribute information and a command sequence consisting of multiple navigation commands.
  • the attribute information is a clear report (resume-intention-flag) indicating whether or not playback is intended to be resumed after a MenuCall when a MenuCall is made on the PL time axis, and masks the MenuCall on the PL time axis (Menu call mask), title search W
  • the navigation command sequence is a command sequence that implements conditional branching, setting of the status register in the playback device, acquisition of the setting value of the status register, and the like.
  • the commands that can be described in the Movie object are shown below.
  • PlayPL (1st argument, 2nd argument)-The 1st argument is the playlist number, which can specify the PL to be played.
  • the second argument can specify the playback start position using the Playltem included in the PL, an arbitrary time in the PL, Chapter, and Mark.
  • PlayPLatPlayltemO The PlayPL function that specifies the playback start position on the PL time axis by Playltem.
  • the PlayPL function that specifies the playback start position on the PL time axis is defined by Chapter in PlayPLatChapterO,
  • the JMP command is a branch that discards the current dynamic scenario on the way (discard) and executes the destination dynamic scenario as an argument.
  • the description of the navigation command in the Movie object is very similar to the description method of the navigation command in the DVD, so that the task of porting the disc content on the DVD to the BD-ROM can be performed efficiently. it can.
  • Movie objects there are prior arts described in the following International Publications. Exists. See this International Publication for details. International Publication WO 2004/074976 This concludes the description of the Movie object. Next, the BD-J object will be described.
  • FIG. 7- (b) is a diagram showing the internal configuration of a BD-J object.
  • 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 that it has attribute information.
  • the difference from the Movie object is that the BD-J object does not directly describe commands. In other words, the control procedure in the Movie object was directly described by the navigation command.
  • the control procedure is indirectly specified by defining a Java application whose life cycle is the title on the application management table.
  • the control procedure can be efficiently shared, that is, the control procedure can be shared among a plurality of titles.
  • FIG. 7 (c) is a diagram showing the internal configuration of the Java application.
  • the application consists of one or more xlet programs loaded in the virtual machine's heap area (also called work memory).
  • work memory also called work memory
  • one or more threads are running, and the application is composed of xlet programs and threads that are loaded into the work memory.
  • the above is the configuration of the application.
  • the entity of this application is the Java archive files (00001.jar, 00002.jar) stored in the BDAR directory under the BDMV directory.
  • the Java archive file will be described.
  • FIG. 3 is a diagram showing programs and data stored in an archive file.
  • the data in this figure is a collection of multiple files in which the directory structure shown in the frame is arranged by the java archiver.
  • the directory structure shown in the box is composed of a root directory, a java directory, and an image directory.
  • the root directory has com.mon.pk power
  • the java directory has aaa.class, bbb.class
  • the image directory has , Menujpg is arranged.
  • a java archive file can be obtained by putting them together in a] 'ava archiver.
  • Such data is expanded when it is read out from the BD-ROM to the cache, and is treated as multiple files placed in the directory on the cache.
  • the five-digit number "xxxxx" in the file name of the Java archive file indicates the application ID (applicationlD).
  • applicationlD application ID
  • the program and data that make up any Java application can be extracted by referring to the numerical value in the file name.
  • One file that is bundled together in a Java archive file is the xlet program.
  • the xlet program is a Java program that can use the JMF (Java Media Frame Work) interface.
  • the xlet program consists of a plurality of functions such as EventListner that receives key events, and performs processing based on the received key events according to a method such as JMF.
  • FIG. 8B shows an example of the xlet program.
  • JMFA "BD: //00001.mpls"; is a method that instructs the Java virtual machine to create a player instance that plays the PL.
  • A.play is a method that instructs the JMF player instance to play.
  • Such JMF player instance generation is performed based on the JMF library.
  • the description of the xlet program is not limited to the PL of the BD-ROM, but is the description of the JMF applicable to all content with a time axis. Since such a description is possible, it is possible to encourage a software house that is skilled in Java programming to create a BD-J object.
  • JumpTItleO in Fig. 8 (b) is a function API call.
  • This function API instructs the playback device to branch to another title (title # l in the figure).
  • the function API is an API (Appliation Interface) supplied by the BD-ROM playback device.
  • the function API is an API (Appliation Interface) supplied by the BD-ROM playback device.
  • the Anchor API By calling the Anchor API, the processing unique to the BD-ROM playback device can be described in the xlet program.
  • PL playback is specified by the JMF interface. Since this JMF player instance defines the PL time axis, the title time axis is determined from the title having this JMF player instance. Also
  • the timeline defined by the title is called the "title timeline”.
  • the title time axis is composed of a Movie object or a PL whose playback is ordered by a BD-J object.
  • One example here is the title shown in Fig. 9 (a).
  • This title is a series of titles: top menu> title # l ⁇ title # 2 ⁇ top menu, top menu 2- ⁇ title # 3 top menu.
  • PlayList # 2 title # 2 commands PlayList # 3 commands PlayList # 4
  • PlayList # l as shown in Fig. 9 (b).
  • Title # l has a time axis obtained by adding the time axes of PlayList # 2 and PlayList # 2.
  • title # 2 has a time axis composed of PlayList # 3 time axis
  • title # 3 has a time axis composed of PlayLis # 4 time axis.
  • Seamless playback is guaranteed on the PL time axis in these title time axes, but seamless playback is not required between title time axes.
  • service period the period during which the Java application can exist on the work memory of the virtual machine
  • the service period of the Java application must be defined on the time axis that branches off from each other. The definition of this service period is a point to keep in mind when programming for BD-ROM.
  • IndexTable is a table that associates title numbers with Movie objects and BD-J objects, and is an indirect reference table that is referenced when branching from a dynamic scenario to a dynamic scenario.
  • IndexTable consists of Index for each of multiple labels. Each Index describes the identifier of the dynamic scenario corresponding to the label. By referring to such an IndexTable, branching can be realized without strictly discriminating between the Movie-object and the BD-J object. Details of IndexTable are described in the following International Publication. See this gazette for details. International Publication WO 2004/025651 A1 The above is an explanation of files recorded on a BD-ROM.
  • JMF player instances and applications with JumpTitleAPI calls govern the title time axis, but other applications without JMF player instance ⁇ JumpTitleAPI calls operate on the title time axis.
  • the period from the start of the service by the application to the end thereof is defined as “survival of the application”.
  • Information for defining the survival of the application exists in the application management template of the BD-J object.
  • the application management table will be described in more detail.
  • the application management table is information indicating an application that can survive on the work memory of the virtual machine in the title time axis of each title. Survival in work memory is the Xlet program is read into the work memory and can be executed by the virtual machine.
  • the broken arrow atl in FIG. 7 (b) shows a close-up of the internal configuration of the application management table. As shown in this internal configuration, the application management table includes “live range”, “applicationID” indicating an application whose title is the live range, and “activation attribute” of the application.
  • the disc content used here is the main title of the main video (title # l), the online shopping title of online shopping (title # 2), and the title of the game application (title # 3) It includes three titles with different characteristics.
  • FIG. 10 is a diagram showing disc content including three titles: a main title, an online shopping title, and a game title. In the figure, IndexTable is described on the right side, and three titles are described on the left side.
  • FIG. 11 is a diagram showing an example of the reproduced images of the three titles shown in FIG.
  • title # l consists of three applications, application # l, application # 2, and application # 3.
  • title # 2 includes two applications, application # 3 and application # 4, and title # 3 includes application # 5.
  • FIG. 11 is a diagram showing an example of the reproduced images of the three titles shown in FIG.
  • the cart program application # 3 is started in both title # l and title # 2. .
  • an application app that simulates a mascot appearing in a movie work, a menu that displays a menu in response to a menu call operation, etc. There is an app.
  • Fig. 12 (a) When the life span of each application is graphed from the membership shown by the broken line in Fig. 10, the result is as shown in Fig. 12 (a).
  • the horizontal axis is the title time axis.
  • the live range of each application is arranged along the vertical axis.
  • application # l and application # 2 belong only to title # l, so their survival sections remain within title # l. Since application # 4 belongs to title # 2 only, these live ranges remain within title # 2.
  • application # 5 belongs to title # 3 only, so these live ranges remain in title # 3. Since application # 3 belongs to title # l and title # 2, their survival range extends from title # l to title # 2.
  • the application management table for title # 1, # 2, and # 2 is as shown in Fig. 12 (b). If the application management table is described in this way, application # l, application # 2, and application # 3 are loaded into the work memory at the time of starting playback of title # l. At the start of title # 2, application # l and application? ⁇ Are deleted from the work memory and only application # 3 is controlled. Similarly, control can be performed such that application # 4 is loaded into a single memory at the start of playback of title # 2 and application # 3, # 4 is deleted from the work memory at the start of title # 3. .
  • control can be performed such that application # 5 is loaded into the work memory during the playback of title # 3, and application # 5 is deleted from the work memory when the playback of title # 3 is completed.
  • the surviving application at the branch source—branch destination is stored in the work memory, and the application that is not at the branch source but exists only at the branch destination is stored in the work memory.
  • the number of times the application is read into the work memory is the minimum required. As described above, by reducing the number of times of reading, it is possible to realize an application that is not conscious of the title boundary, that is, an unready application.
  • the startup attributes include "AutoRun”, which indicates automatic startup, "Persistent”, which indicates that it can be placed in the virtual machine's primary memory, which is not the target of automatic startup, and is placed in the virtual machine's work memory. However, there is a “Suspend” where CPU power cannot be allocated.
  • the launch attribute “Persistent” is a continuation attribute, and indicates that the state of the application at the branch source title is to be continued. Also, it is a genus indicating that it can be loaded into work memory. If the launch attribute is “Persistent”, the application to which this launch attribute is assigned will be allowed to be called from other applications.
  • the management entity application manager
  • the management entity that manages the application checks whether the applicationlD of the application is described in the application management table and the startup attribute is "Persistent”. judge. If “Persistent”, load the application into work memory. On the other hand, if the applicationlD of the called application is not described in the application management table, the application will not be loaded into the work memory. Calls by applications are limited to applications to which this “Persistent” is assigned.
  • Persistent is the default startup attribute that is assigned when the startup attribute is not explicitly specified, so if the startup attribute of a certain application is "-one", the startup attribute of that application is started.
  • the attribute means this Persistent.
  • FIG. 13 is an example of setting the startup attributes for the three applications in FIG.
  • application # 2 is the application that is started only when an application is called from another application as shown in Figure 13 (b). I do.
  • the remaining application # l and application # 3 are started automatically when title # l starts Suppose it is an application.
  • the start attribute of each application in the application case management table is set to "AutoRun" for application # l and application # 3. Is set as I PersistentJ.
  • application # l and application # 3 are automatically loaded into the work memory and executed when branching to title # l.
  • application # 3 is an application that can be loaded on the work memory of the virtual machine. Therefore, application # 2 will be loaded into the virtual machine's work memory and executed only after a call from application # l.
  • ⁇ survival interval '' startup attribute the number of applications that can run on the virtual machine can be limited to 4 or less, and the total number of threads can be limited to 64 or less. Can be guaranteed.
  • FIGS. 14 (a) and 14 (b) are diagrams showing examples in which Suspend is significant.
  • Fig. 14 (b) there are three titles (title # l, title # 2, title # 3), of which title # l and title # 3 execute the game T-pre Title # 2 is a side path, which realizes video playback.
  • title # l title # 2
  • title # 3 title # 3
  • T-pre Title # 2 is a side path, which realizes video playback.
  • the side path it is necessary to realize video playback, which interrupts game execution.
  • scores in the middle are counted, so we want to keep the stored value of resources before and after title # 2.
  • the application management table is described such that the game application is suspended at the start of title # 2 and application # 2 is resumed at the start of title # 3.
  • the resource value is maintained for application # 2 in title # 2 because the resource is allocated.
  • application # 2 is not executed by the virtual machine because the CPU is not allocated. As a result, a process of executing the side pass during the execution of the game title is realized.
  • FIG. 15 shows three modes that the startup attribute can take (Persistent, AutoRun, Suspend), and three modes of the application status in the last title (non-start, running, Suspend)
  • FIG. 7 is a diagram showing combinations that can be taken. If the last state is "not running”, and the startup attribute is "AutoRun", the application will be started in the branch destination title.
  • the launch attribute is "Suspend”
  • the state of the application will be suspended. If the previous state is "Suspend”, the start attribute of the branch title is Suspend, and if it is "Persistent” AutoRun ", the application is resumed at the branch title. Will be done.
  • the live range and the start attribute in the application management table it becomes possible to perform synchronous control of operating a Java application along with the progress of the title time axis. Along with that, various applications can be launched. The above is the description of the recording medium. Next, the playback device according to the present invention will be described.
  • FIG. 16 is a diagram showing the internal configuration of the playback device according to the present invention.
  • the playback device according to the present invention is industrially produced based on the interior shown in the drawing.
  • the playback device according to the present invention mainly includes two parts, a system LSI and a drive device, and can be industrially manufactured by mounting these parts on a cabinet and a board of the device.
  • a system LSI is an integrated circuit that integrates various processing units that perform the functions of a playback device.
  • the playback devices produced in this way include a BD-ROM drive 1, a lead buffer 2, a demultiplexer 3, a video decoder 4, a video plane 5, a P-Graphics decoder 9, a Presentation Graphics plane 10, a synthesizing unit 11, and a font generator.
  • the BD-ROM drive 1 reads / ejects the BD-ROM and accesses the BD-ROM.
  • the read buffer 2 is a FIFO memory in which TS packets read from the BD-ROM are stored in a first-in first-out manner.
  • the demultiplexer (De-MUX) 3 extracts a TS packet from the lead buffer 2 and converts the TS bucket constituting this TS bucket into a PES bucket. Then, of the PES buckets obtained by the conversion, those having the PID set by the CPU 22 are output to one of the video decoder 4, the audio decoder 20, the P-Graphics decoder 9, and the I-Graphics decoder 13.
  • Video plane 5 is a plane for storing uncompressed pictures.
  • a plane is a memory area for storing pixel data for one screen in a playback device. If a plurality of planes are provided in the playback apparatus, and the stored contents of these planes are added for each pixel and video output is performed, the video output can be performed after combining the video content.
  • the resolution in the video plane 5 is 1920 ⁇ 1080, and the picture data stored in the video plane 5 is composed of pixel data represented by a 16-bit YUV value.
  • the P-Graphics decoder 9 decodes the presentation graphics stream read from the BD-ROM and HDD 17 and writes the uncompressed graphics to the Presentation Graphics plane 10. Subtitles will appear on the screen due to the decoding of the graphics stream.
  • the Presentation Graphics plane 10 is a memory having an area for one screen, and can store uncompressed graphics for one screen.
  • the resolution in this plane is 1920 x 1080, and each pixel of the non-compressed graphics in the Presentation Graphics plane 10 is represented by an 8-bit index color.
  • CLUT Color Lookup Table
  • the synthesizing unit 11 synthesizes the uncompressed picture data (i) with the contents stored in the Presentation Graphics plane 10.
  • the font generator 12 expands the text code contained in the textST stream into a bitmap using character fonts.
  • the I-Graphics decoder 13 decodes the interactive graphics stream read from the BD-ROM or the HDD 17 and writes uncompressed graphics to the Interactive Grannies plane 15.
  • the switch 14 is a switch for selectively writing any one of the font sequence generated by the font generator 12 and the graphics obtained by the decoding of the P-Graphics decoder 9 to the Presentation Graphics plane 10.
  • the synthesizing unit 16 combines the storage contents of the Interactive Graphics plane 10 with the synthesized image (uncompressed picture data and the storage contents of the Presentation Graphics plane 7) output from the synthesizing unit 8. Are synthesized.
  • the HDD 17 is a built-in medium in which SubClip, Clip information, and playlist information downloaded via a network or the like are stored.
  • the playlist information in the HDD 17 differs from the BD-ROM and the HDD 17 in that it can be specified as Clip information.
  • the playlist information on the HDD 17 does not need to specify the file on the BD-ROM with a full path. This is because the HDD 17 is recognized by the playback device as a single virtual drive (called a virtual package) together with the BD-ROM.
  • Clip_Information_file_name in Playltem information and Clip_Information_file_name in SubPlayltem information specify HDD 17 and BD-ROM by specifying a 5-digit numerical value corresponding to the file pod of the file storing the Clip information.
  • the above AVClip can be specified.
  • the read buffer 18 is a FIFO memory, in which TS buckets read from the HDD 17 are stored in a first-in first-out manner.
  • the audio decoder 20 decodes the PES packet output from the demultiplexer 19 and outputs uncompressed ⁇ : audio data.
  • the scenario memory 2.1 is a memory for storing current PL information and current clip information.
  • the current PL information refers to the current PL to be processed among the multiple PL information recorded on the BD-ROM.
  • the current Clip information refers to the information currently being processed from among the multiple Clip information recorded on the BD-ROM.
  • the key processing unit 23 outputs a key event for performing an operation in response to a key operation on the remote control or the front panel of the playback device.
  • the instruction ROM 24 stores software for controlling the playback device.
  • Switch 25 is used for selectively reading each data read from BD-ROM and HDD I7 to read buffer 2, read buffer 18, scenario memory 21 or local memory 29. This is the switch to be put in.
  • PSR4 when set to a value between 1 and 100, indicates the title to which the current playback point belongs, and when set to 0, indicates that the current playback point is the top menu.
  • PSR7 when set to a value of 0 to 255, indicates the number of the PlayItem (current PlayItem) to which the current playback point belongs.
  • PSR8 is set to a value from 0 to OxFFFFFF to indicate the current playback point (current PTM (Presentation TiMe)) using a time accuracy of 45 KHz.
  • the current playback point is specified by the above PSR4 to PSR8.
  • the oral memory 29 is a cache memory for temporarily storing the recorded contents of the BD-ROM because reading from the BD-ROM is slow.
  • the presence of the local memory 29 improves the efficiency of application execution in the BD-J mode.
  • FIG. 17 (a) is a diagram showing how a Java archive file existing on the BD-ROM is identified on the local memory 29.
  • the left column shows the file names on the BD-ROM
  • the right column shows the file names on the local memory 29.
  • FIG. 17 (b) is a diagram showing an application of FIG. 17 (a).
  • data stored in a file is stored in the format of header + data. What is used for the header is the file path in the local memory 29.
  • Fig. 17 (b) in the oral memory 29, a part of the file path in the BD-ROM is omitted for the file path, and by storing the file path in the header, The location of the data on the BD-ROM can be clarified.
  • FIG. 18 is a diagram in which a portion composed of software and hardware stored in the ROM 24 is replaced with a layer configuration.
  • the layer configuration of the playback device consists of the following a), b), c), d-l), d-2), e), and £). That is,
  • Playback Control Engine CJ 2 which performs playback control based on playlist information and Clip information There are two hierarchies,
  • the HDMV module 33 which is the subject of decryption and execution of the Movie object, and d-2) the BD-J module 3, which decrypts and executes the BD-J object 5 is on the same level.
  • the BD-J module 35 is a so-called Java platform, and has a configuration in which a Java virtual machine 38 including a work memory 37 is a core, an application manager 36, an event listener manager 39; It consists of Default Operation Manager 40.
  • a Java virtual machine 38 including a work memory 37 is a core, an application manager 36, an event listener manager 39; It consists of Default Operation Manager 40.
  • FIG. 19 is a diagram schematically illustrating the processing by the Presentation Engine 31 to the module manager 34.
  • the Presentation Engine 31 performs the AV playback function.
  • the AV playback function of the playback device is a group of traditional functions followed by DVD players and CD players, and starts playback (Play), stops playback (Stop), pauses (Pause On), and releases pause ( Pause Of £), Release of Still function (still of £), Fast forward with speed specification (Forward Play (speed)), Rewind with speed specification (Backward Play (speed)), Audio switching (Audio Change), This function is called Subtitle Change or Angle Change.
  • the Presentation Engine 31 decodes the video decoder 4, P-Graphics decoder 9, and I-Video so as to decode the part corresponding to the desired time in the AVClip read on the read buffer 2.
  • the playback control engine (PCE) 32 executes various functions such as a playlist playback function 0) and a state acquisition setting function (ii) in the playback device.
  • the playback function of the PL means that, of the AV playback functions performed by the Presentation Engine 31, the playback start and playback stop are performed according to the current PL information and Clip information.
  • These functions (i) to (ii) are based on the HDMV module 33 Execute in response to a call.
  • the playback control engine 32 executes its own function in response to an instruction from a user operation or an instruction from a higher layer in the layer model.
  • arrows marked with ⁇ 2 and ⁇ 3 schematically indicate the reference of Playback Control Engine 32 to Clip information and playlist information.
  • the HDMV module 33 is the execution entity of the MOVIE mode, and when notified of a Movie object constituting a branch destination from the module manager 34, reads out a Movie object constituting a branch destination title into the local memory 29. Then, the navigation command described in the Movie object is decoded, and a function call to the Playback Control Engine 32 is executed based on the decoding result.
  • arrows marked with V2, V3, and V4 indicate branch target Movie objects from the module manager 34 (2), navigation described in the Movie object; decoding of commands (3), A function call (4) to Playback Control Engine 32 is schematically shown.
  • the module manager 34 holds the Index Table read from the BD-ROM and performs branch control.
  • this branch control receives the title number of the jump destination, and This is to notify the HDMV module 33 or the BD-J module 35 of the Movie object or BD-J object constituting the title.
  • Arrows marked with V0, V1, and V2 in the figure schematically show execution of the JumpTitle command (0), reference of the IndexTable by the module manager 34 (1), and notification of the branch destination Movie object (2). I have.
  • FIG. 20 is a diagram showing the application manager 36.
  • the application manager 36 controls the start of the application with reference to the application management table and the control when the title ends normally.
  • Start control means that every time a BD-J object that is a branch destination is notified from the module manager 34, the BD-J object is read, and the local application is referred to by referring to the application management table in the BD-J object. Performs memory 29 access. And configure an application with the current playback point as the 'live range'
  • the control is to read the xlet program into the work memory.
  • ⁇ l, 2, and ir3 'in Fig. 20 represent the notification of the branch target BD-J object in the start control (1), refer to the application management table (2), and the start instruction to the Java virtual machine 38. Shown. In response to this start instruction, the Java virtual machine 38 reads the xlet program from the local memory 29 to the work memory 37 (5).
  • Title end control includes control for normal termination and control for abnormal termination.
  • the control at the time of normal termination includes a control in which a jump title API is called by an application constituting a title and a switch to a branch destination title is requested to a branch control main body (module manager 34). .
  • Arrow 6 schematically shows the notification of the module manager 34 in this end control.
  • the application composing the title may be left running. This is because whether to terminate the application is determined by the branch destination title.
  • the application manager 36 performs a process of reading a Java archive file from the BD-ROM to the local memory 29 (8).
  • Reference numeral 8 schematically illustrates the reading to the oral memory 29.
  • the Java virtual machine 38 loads the xlet program constituting the application into the private memory 37, decrypts the xlet program, and executes a process according to the decryption result.
  • the xlet program includes a method for instructing the generation of a JMF player instance and a method for instructing the execution of this JMF player instance, control for the lower layer is performed so as to realize the processing contents instructed by these methods. I do. If a JMF player instance creation is ordered, the Java virtual machine 38 will execute the JMF player associated with the YYYYMPLS file on the BD-ROM. Get key instance. Also, if execution of the JMF method in the JMF player instance is ordered, this JMF method is issued to the BD middleware,
  • the Event Listner Manager 39 analyzes events (key events) generated by user operations and sorts the events.
  • the solid arrows 01 and 02 in the figure indicate this Event
  • the distribution by Listner Manager 39 is schematically shown. If a key event such as STAET, STOP, SPEED, etc. registered in the Event Listner in the xlet program, the event related to the xlet program indirectly referenced by the BD-J object can be sorted. START, STOP, and SPEED are events corresponding to JMF. Since these key events are registered in the Event Listner of the xlet program, the xlet program can be started by this key event. The key event
  • this key event is distributed to Default Operation Manager 40.
  • key events that occur in the BD-ROM playback device, such as audio switching and folder switching, which are not registered in the Event Listner. Even if these key events occur, perform processing without omission. That's why.
  • Event Listner non-registered events were sorted by Event Listner Manager 39 and Default Operation Manager 40, but Playback Control Engine 32 directly received Event Listner non-registered events and performed playback control. (4 in the figure).
  • FIG. 22 is a diagram showing a control procedure at the time of branching by the application manager 36.
  • This flowchart is a process of starting or terminating an application (referred to as an application X) that satisfies the conditions of steps S2 to S5.
  • step S2 it is determined whether or not the application is not activated in the branch source title but is alive in the branch destination title and the activation attribute in the branch destination title is an application X having the AutoRim attribute. For example, cache sense for the local memory 29 is performed. As a result of the cache sense, if the application X is on the oral memory 29 (Yes in step S7), the application X is read from the oral memory 29 to the work memory 37 (step S8). If it is not in the local memory 29, the application X is read from the BD-ROM to the local memory 29, and then the application X is read from the local memory 29 to the work memory 37 (step S9).
  • step S3 it is determined whether or not there is an application X that is running in the branch source title and is non-existent in the branch destination title. If it exists, the application case X is deleted from the work memory 37 and the process is terminated (step S10).
  • step S4 it is determined whether or not there is a branch source Suspend, a branch destination AutoRxm, or a Persistent application. If it exists, Resume Application X (Step S11).
  • step S18 is for judging whether or not the application to be issued has been completed. If the application has been completed, the processing for this application is completed. In step S19, it is determined whether or not the timer has timed out. If timed out, in step S20, the application to be issued is deleted from the work memory 37, and the application is forcibly terminated.
  • FIG. 24 is a diagram schematically showing a process of terminating the application.
  • the first tier in this figure shows the application manager 36, and the second tier shows three applications.
  • the left-hand application shows the application that received the terminate event and successfully completed the termination process.
  • applications in the middle row indicate applications that received a terminate event but failed to terminate.
  • the application on the right shows an application that could not receive a terminate event because EventListner was not implemented.
  • the arrows epl and ep2 between the first stage and the second stage schematically show the issuance of the terminate event by the application manager, and the arrow ep3 schematically shows the start of the termination process.
  • the third stage is the state after the state transition when the termination process is successful. This abridgement is terminated by its own termination process. If there are applications such as these xlet programs that do not end within a predetermined period, the abbreviation manager 36 forcibly removes them from the work memory 37.
  • the fourth row shows the forced termination by the application manager 36. It is one of the missions of the Application Manager 36 to specify the forced termination in the fourth stage.
  • an application that is started at the branch source title and is not alive at the branch destination title is automatically terminated. Even if it progresses, resources on the playback device No application launch beyond the limit is done. Since application operation before and after branching can be guaranteed, it is possible to distribute a lot of disc contents that execute an application while reproducing a digital stream.
  • the application manager 36 In order to perform processing based on the application management table described in this way, the application manager 36 according to the present embodiment starts a live range from the chapter start point each time the chapter start point specified by PLmark is reached. It is determined whether or not the application exists, and if so, the application is loaded into the work memory 37.
  • the life span of the application can be specified with finer precision.
  • disc content can have a reverse time axis. Retrograde is a volume By returning, the time axis advances in the opposite direction. If this reversal and progress are repeated at the chapter boundary, loading and discarding of the private memory are repeated many times, resulting in extra read load. Therefore, in the present embodiment, the application is started at the moment when the normal playback by the Playback Control Engine 32 is started after entering the title.
  • PL playback includes normal playback and trick playback.
  • the trick playback includes fast forward, rewind, SkipNext, and SkipBack.
  • the application is not started, and the application is started only after the normal reproduction is started. Normally, based on the moment of the start of reproduction, even if there is a crossing before and after the life cycle as described above, the application startup will not be repeated more than necessary. Note that the process of setting the instant of the normal playback as the reference for starting the application may be executed even when the survival area is title.
  • the alive range of the ablation can be defined in units of chapters, which is smaller than the PL, so that it is possible to realize precise a-precision control.
  • each application is assigned a priority. This priority takes a value from 0 to 255. If there is a conflict between resource usage among applications, which application is forcibly terminated, and from which application the resource is When the application manager 36 performs the process of stealing, it is used as a source of judgment.
  • application # l has a priority of 255
  • application # 2 and application # 3 have a priority of 128, so in the event of a conflict between application # l and application # 2, the application manager 36 has priority. Perform the process of forcibly terminating application # 2 with low degree.
  • the disc content provided by the BD-ROM is composed of a plurality of titles that can be mutually branched.
  • Each title includes one or more PLs and a control procedure using this PL, as well as a non-AV title that only includes control procedures for the playback device. In the present embodiment, this non-AV title will be described.
  • Figure 26 (a) shows the title time axis determined from the PL time axis. Show. In this case, the PL time axis becomes the title time axis, and the live range of the application is determined on this title time axis. If there is no PL time axis as a reference, the title time axis should be defined as shown in Figure 26 (b) and (c).
  • Figure 26 (b) shows the title time axis determined from the life span of the main application.
  • the main application is the only application that has the start attribute set to AutoRun in the title and is automatically started when the title starts.
  • this is a launcher application.
  • a launcher application is an application program that launches another application.
  • Figure 26 (b) is that the title time axis is assumed to be continuous as long as the main application is running, and the time axis is terminated when the main application ends.
  • Figure 26 (c) is a diagram showing a tight time axis determined from the life span of multiple applications. One application is started at the beginning of the title, but this application calls another application, and this application repeatedly calls another application. There is a case that is. In this case, the idea is that the title time axis is continued as long as any application is running, and the title time axis ends when a state arrives in which no application is started. It is.
  • the title time axis of a non-AV title is determined, the title will be set to the title at the same time as the end of the evening title axis, regardless of whether it is an AV title or a non-AV title.
  • the process of branching can be performed uniformly.
  • the title time axis for non-AV titles is merely an imaginary time axis for comparison with AV titles. Therefore, the playback device cannot go backward on the title time axis of a non-AV title or search for an arbitrary position.
  • FIG. 27 is a flowchart showing the processing procedure of the application manager 36 during title playback. This flowchart has a loop structure in which steps S21 to S23 are repeated during title playback.
  • Step S1 is for determining whether or not the title jump API has been called. If called, the module manager 34 is requested to branch to the jump destination title (step S27).
  • Step S22 is a determination as to whether or not there is a main application that is responsible for calling the application in the title, and if so, confirms whether it has been started (step S25). ). If it has not been started, it is interpreted as "end of title", and the end is notified to module manager 34 (step S26).
  • Step S23 is a step executed when there is no main application (No in step S22), and it is determined whether or not any application is running. If so, it also interprets it as "end of title" and notifies module manager 34 of the end (step S26). -As described above, according to the present embodiment, even if the title does not involve PL playback, it is possible to perform processing in which branching is performed only after application execution is completed, without branching during application execution.
  • FIG. 28 (a) is a diagram showing a menu hierarchy realized by the BD-ROM.
  • the menu hierarchy in this figure has a structure in which TopMenu is arranged at the top level, and lower TitleMenu, SubTitleMenu, and AudioMenu can be selected from this TopMenu.
  • Arrows swl, 2, and 3 in the figure schematically show menu switching by button selection.
  • TbpMerm is a menu in which buttons (buttons snl, sn2, sn3 in the figure) for selecting whether to perform audio selection, subtitle selection, or title selection are arranged.
  • the TitleMenu is a menu with buttons to accept the selection of a movie, such as selecting the movie version of the movie (title), selecting the director's cut version, selecting the game version, etc. .
  • AudioMenu is a menu with buttons to accept audio playback in Japanese or English.
  • SubTitleMenu is a menu with buttons to accept subtitles in Japanese or English. It is.
  • Figure 28 (b) shows a MOVIE object for operating a menu having such a hierarchy.
  • MovieObject.bdmv stores FirstPlay OBJ, TpMenu OBJ, AudioMenu OBJ, and SubTitleMenu OBJ.
  • the FirstPla object (FirstPlay OBJ) is used to load BD-ROMs to playback devices. This is a dynamic scenario that is automatically executed at the time of logging.
  • the IpMenu object (TopMenu OBJ) is a dynamic scenario that controls the behavior of TbpMenu. It is this IbpMenu object that is invoked when the user requests a menu call.
  • the IbpMenu object includes one that changes the state of a button in the TopMenu in response to a user operation, and a branch command that branches in response to a button operation. This branch command realizes menu switching from TopMenu to TitleMenu, TopMenu to SubTitleMentu TopMenu to AudioMenu.
  • the AudioMenu object (AudioMenu OBJ) is a dynamic scenario that controls the behavior of AudioMenu. Commands that change the state of buttons in AudioMenu in response to user operations, and audio settings in response to button operations. Includes the command to update.
  • the TitleMemi object (TitleMenu OBJ) is a dynamic scenario that controls the behavior of TitleMemi, and includes a command that changes the state of the button in itleMenu and a branch command that branches in response to a decision operation on the button.
  • Arrows bcl, 2 in the figure schematically show the branch from Index Table to FirstPlayOBJ, and: Branch from FirstPlayOBJ to TpMenu, and arrows bc3,4,5 show the arrows from TpMenu to TitleMenu, SubTitleMenu, AudioMenu. Are schematically shown. Arrows bc6, 7, and 8 schematically show branches from the TitleMenu to each Movie object.
  • FirstPLaylNDEX, TopMen INDEX, Audio Menu INDEX, Subtitle Menu INDEX, title Menu INDEX are indexes for FirstPLayOBJ, IbpMenu OBJ, Audio Menu OBJ, Subtitle Menu OBJ, title Menu OBJ, respectively, and these identifiers are described.
  • title # l ⁇ # mINDEX is the index of the title entered from the 1st to the mth in the BD-ROM.
  • the title of the MOVIE object to be branched to when selecting the title numbers from 1 to m is selected.
  • An identifier (ID) is described.
  • title # m + l ⁇ # nINDEX is the index of the title entered from the m + 1 to the nth entry on the BD-ROM, and becomes the branch destination when selecting these title numbers from m + 1 to n Describes the identifier (ID) of the BD-J object.
  • the title # 0 INDEX is an INDEX that specifies a Movie object or a BD-J object to be a branch destination when the BD-J object is forcibly terminated.
  • the identifier of TopMenuOBJ is stored in title # 0INDEX.
  • FIG. 3 (a) shows a branch when the Index Table is described as shown in FIG. Since the Index Table is described in this way, when executing the branch command with the label title # l ⁇ title # m as the branch destination, the identifier of the Movie object # l ⁇ # m is obtained from title # llndex: ⁇ title # mlndex. Taken out.
  • the identifier of the BD-J object # m + l to #n is extracted from title # m + llndex to title # nlndex.
  • Step S31 is to determine whether or not the title jump API has been called. If the title jump API is called, the title number j which is the branch destination label is obtained (step S33), and the IDj is extracted from the index of the title number j in the Index Table (step S34). ), The HDMV module 33 or the BD-J module 35 executes the Movie object or the BD-J object of IDj (step S35).
  • step S32 it is determined whether or not the title and the end are notified from the application manager 36. If notified (Yes in step S32), the top menu OBJ constituting the top menu title is set to the HDMV. The module 33 or the module manager 34 is executed (step S36).
  • the titles to be played here are non-AV titles, including game apps that stack falling tile pieces.
  • the lower part of Fig. 32 shows the title time axis consisting of the live range of the application, and the upper part shows the image displayed on the title time axis.
  • the non-AV title is a game app
  • one screen of the game app is displayed as shown in the upper left of Fig. 32 in the life span of this game app. If the game application has a bug and terminates abnormally, the application manager 36 forcibly terminates the game application according to the flowchart in FIG. 23 and notifies the module manager 34 of the end of the title.
  • the Playback Control Engine 32 executes the processing procedure based on the PL information when the PL playback API is called. If the PL has a playback time of 2 hours, the above process will continue during these 2 hours. What matters here is a gap between the time when the Java virtual machine 38 returns a success response and the time when the Playback Control Engine 32 actually finishes processing. Since the Java virtual machine 38 is an event-driven processing entity, it returns a response indicating success or failure of playback immediately after the call.However, since the actual processing by Playback Control Engine 32 ends after two hours, If the time taken to return a success response to the application is used as a reference, it will not be possible to detect the end of processing after 2 hours. If fast forward, rewind, or skip is performed in PL playback, the playback period of 2 hours fluctuates around 2 hours, making it more difficult to detect the end of processing.
  • PlayItem # x (PI # x).
  • This Play tem #x is initialized by being set to the first Play tem of the current PL (step S42).
  • the termination requirement of the loop processing described above is that this Playltem # x becomes the last Playltem of the current PL (step S49). If it is not the last Playltem, the next Playltem in the current PL is Playltem # x Is set to (Step S50).
  • the presentation engine 31 is instructed to output from mark_time_stamp of the current PLMark to Out_time of Playltem # x (step S46).
  • the presentation engine 31 is instructed to output from mark_time_stamp of the current PLMark to Out_time of Playltem # x (step S46).
  • Playltem # x is the last PI of the current PL (scan Step S4 9).
  • step S50 the next Playltem in the current PL is set to Playltem # x (step S50), and the process returns to step S43.
  • the PIs constituting the PL are sequentially reproduced.
  • FIG. 34 is a flowchart showing the angle switching procedure and the SkipBack and SkipNext procedures. This flowchart is performed in parallel with the processing procedure of FIG. 33, and repeats a loop process including steps S51 to S52. Step S51 in this loop is to determine whether or not the API for requesting angle switching has been called from the Java virtual machine 38. If there is a call for the angle switching API, the current Clip information is switched. Perform the operation.
  • Step S55 in FIG. 34 is a determination step, which determines whether is-multi-angles of Playltem # x is on. is—nmlti-angles is a flag indicating whether Playltem # x supports multi-angle, and if step S55 is No, the process proceeds to step S53. If step S55 is Yes, execute steps S56 to S59. In steps S56 to S59, the angle number after the switching is substituted for the variable y (step S56), and the Clip information specified by the y-th Clip_information_file-name in Playltem # x is stored in the scenario memory.
  • Step S57 Read out to 1 (Step S57), convert the current PTM to I picture address u using EP_map of current Clip information (Step S58), and convert Outjime of Playltem # to EP of current Clip information. — Convert to I-picture address V using map (step S59). After the I picture addresses u and v are changed in this way, the flow shifts to step S46. By shifting to step S46, a TS packet is read from another AVClip, so that the video content is switched.
  • step S52 in the loop of FIG. 34 is a determination as to whether an API meaning SkipBack SkipNext is called from the Java virtual machine 38, and if it is called, the process of FIG.
  • the processing procedure of the flowchart is executed.
  • FIG. 35 is a flowchart showing a processing procedure when the SkipBack, SkipNext API is called.
  • SkipBack SkipNext API
  • step S61 the current Mark information is obtained by converting the current PI number indicated by the PSR and the current PTM.
  • step S62 it is determined whether the pressed key is the SkipNext key or the SkipBack key. If the key is the SkipNext key, the direction flag is set to +1 in step S63, and the SkipBack key is set. If so, the direction flag is set to -1 in step S64.
  • step S65 the number obtained by adding the value of the direction flag to the number of the current PLMark is set as the number of the current PLMark. If the key is a SkipNext key, the direction flag is set to +1 and the current PLMark is incremented. If the key is a SkipBack key, the direction flag is set to -1, so the current PLMark will be decremented.
  • step S66 PI described in ref—to_PlayItem—Id of the current PLMark is set in Playltem # x, and in step S67, Clip information specified by Clip_information_file_name of Playltem # x is read.
  • step S68 mark-time-stamp of the current PLMark is converted to I-picture address u using EP-map of the current Clip information.
  • step S69 the Out-time of Playltem # x is converted to an I-picture address V using the EP-map of the current Clip information.
  • step S70 the output to the Mark-time-stamp of the current PLMark and the Out-time of Playltem # x is instructed to the Presentation Engine 31, and then the flow proceeds to step S47 in Fig. 33. .
  • the I-picture addresses u and v are changed, and the reproduction of another part is ordered.
  • the process proceeds to step S47, so that the TS bucket is read from another AVClip, and the video content is switched. Is realized.
  • FIG. 36 is a flowchart showing details of the processing procedure by the Presentation Engine 31.
  • a loop process including steps S72 to S77 is executed.
  • Step S76 in this loop processing defines the requirements for terminating the loop processing. In other words, step S76 is force. Rent The PTM makes Out # time of PI # x a termination requirement of the loop processing.
  • Step S73 is whether the fast forward API or the fast reverse API is called from the Java virtual machine 38. Is determined. If a call is made, it is determined in step S78 whether fast forward or fast reverse. If fast forward, the PTS of the next I picture is set to the current PTM (step S79).
  • Step S74 is a determination as to whether the menu call API has been called. If so, the current playback process is suspended (step S82), and the menu program for menu processing is executed. (Step S83). According to the above processing, when a menu menu call is made, the processing for menu display is executed after the reproduction processing is interrupted.
  • step S75 it is determined whether or not SubPlayItem # y specifying Playltem # x exists according to sync-Playltem-id, and if so, the flow shifts to the flowchart of FIG. FIG. 37 is a flowchart showing the playback procedure of SubPlayltem.
  • step S86 it is determined whether or not the current PTM is sync-start_PTS-of_j) layItem of SubPlayItem #. If so, in step S93, the playback control engine 32 is notified to perform the playback process based on SubPlayItem # y.
  • Steps S87 to S92 of FIG. 37 are flowcharts showing a reproduction process based on SubPlayItem # y.
  • step S87 the Clip information specified by Clip—information—file—name of SubPlayItem # y is read.
  • EP map of the current Clip information Is used to convert the Injime of SubPlayItem # y to an address.
  • step S89 Out_time of SubPlayItem # y is converted to address] 3 using the EP-map of the current Clip information.
  • a step S90 instructs the decoder to output from In-time of SubPlayItem # y to Out-time of SubPlayItem # y.
  • Step S53 is a determination as to whether or not the playback control by Presentation Engine 31 has been completed. As long as the processing of the flowchart of FIG. 36 is performed for the last Playltem # x, step S53 is No. become. Only after the processing of the flowchart in FIG. 36 is completed is step S53. YES and the process moves to step S54. Step S54 is the output of the reproduction end event to the Java virtual machine 38, and from this output, the Java virtual machine 38 can know the lapse of the reproduction time of 2 hours.
  • step S24 is added between step S1 and step S22, and when step S24 becomes Yes, there is a step S101 to be executed.
  • Step S24 is for determining whether or not the JMF player instance exists in the work memory 37. If not, the process proceeds to step S22. If there is, go to step S101.
  • Step S101 is a determination as to whether or not a playback end event has been output from the Playback Control Engine 32.If the event has been output, the Java player instance in the work memory is deleted and then (Step S101). S 102), the end of the title is notified to the module manager 34 (step S 26). If not notified, a loop consisting of steps S21 to S24 is repeated. Return.
  • steps S22 and S23 are skipped as long as a JMF player instance exists in the work memory 37 (Yes in step S24). Therefore, the title is interpreted as ongoing even if all applications are terminated.
  • the application manager 36 can know the lapse of the playback time of 2 hours, so that the menu is displayed as the PL playback end condition, and this menu is displayed. It is possible to realize a control of branching to another title in response to an operation on.
  • the sixth embodiment relates to an improvement of providing a data management template in a BD-J object.
  • the data management table is a table indicating the Java archive file to be loaded on the local memory 29 in the title time axis in association with the read attribute and the read priority. "Surviving in local memory 29" means that the Java archive files that make up the application are read from local memory 29 and can be transferred to work memory 37 in Java virtual machine 38 State.
  • FIG. 39 is a diagram showing an example of the data management table. As shown in this figure, the data management table contains the “live range” of the application, the “applicationID” that identifies the application that has the live range, the “read attribute” of the application, and the “read priority”. Is shown.
  • the application management table has the concept of a live range
  • the data management table has the same concept of a live range. At first glance, it seems wasteful to have the same concept as the application management table in the data management table, but this is intentional.
  • FIG. 40 is a diagram illustrating an execution model assumed by a BD-J object.
  • the execution model in this figure is composed of a BD-ROM, a local memory 29, and a Java virtual machine 38, and shows a relationship between the BD-ROM, the local memory 29, and the work memory 37.
  • the arrow myl indicates reading between the BD-ROM and the local memory 29, and the arrow my2 indicates reading between the local memory 29 and the work memory 37.
  • the annotations above the arrows indicate when these readings occur.
  • reading between BD-ROM and oral memory 29 is a so-called "look-ahead" and must be done before the application is needed.
  • the arrow my3 indicates the release of the application occupied area in the work memory 37
  • the arrow my4 indicates the release of the application occupied area in the local memory 29.
  • the annotations on the arrows indicate when these readings occur.
  • the release on the work memory 37 is performed at the same time as the end of the application.
  • the release on the oral memory 29 is made when it is no longer necessary for the Java virtual machine 38. The point where this is no longer needed is not the "end point". It means "when it is finished and there is no possibility of restarting", that is, when the corresponding title is finished.
  • the release point in the work memory 37 is known from the live range in the application management table.
  • the disc content to be produced here consists of three titles (title # l, title # 2, title # 3).
  • Title # l Java that configures application # l and application # 2 at the start point of the time axis
  • the archive file is read into the local memory 29, and application # l and application # 2 are resident in the local memory 29 while the title # l time axis is continuing.
  • the Java archive files that make up application # l are released from oral memory 29, and the Java archive files that make up application # 3 are stored in local memory 29 instead.
  • Fig. 41 (a) The description of the data management table in this case is as shown in Fig. 41 (a).
  • the application ID of the application is described in association with its live range, thereby expressing the application that should reside in the local memory 29. .
  • the applicationID of application # l is described in association with title # l
  • the applicationID of application # 2 is associated with title # l and title # 2
  • the applicationID of application # 3 It can be seen that is described in association with title # 3. In this way, the temporal transition of the local memory 29 occupation is specified by the authoring person.
  • the live range specified in the application management table be a fine reproduction unit
  • the live range specified in the data management table be a rough reproduction unit.
  • Non-seamless playback units such as titles and PLs are desirable for rough playback units.
  • a seamless playback unit such as a chapter in a PL is desirable. If the lifespan of the application is determined for each title and for each PL, the application exists in the local memory 29, so that the application can be taken out at any time during playback of the title. In that case, even if the life span of the application is finely defined, the application can be immediately read out to the work memory on the virtual machine, so even if the application is started and terminated frequently. Thus, it is possible to realize smooth application execution.
  • the Java archive file was recorded in a separate recording area from the AVClip. But this is only an example.
  • the Java archive file may be embedded in the recording area occupied by the AVClip on the BD-ROM.
  • FIG. 42 is a diagram showing the embedding of a Java archive file by carouselization.
  • the first row shows a Java archive file to be embedded in AVClip, and the second row shows sectioning.
  • the third tier shows TS packetization, and the fourth tier shows a TS packet sequence constituting the AVClip.
  • the sectioned and TS bucketed data (“D" in the figure) is embedded in the AVClip.
  • FIG. 43 is a diagram showing embedding of Java archive files by interleaving.
  • the first row is the AVClip to be embedded
  • the second row is the Java archive file interleaved with the AVClip
  • the third row is the AVClip arrangement in the recording area of the BD-ROM.
  • the Java archive file to be embedded in the stream is interleaved and recorded between the divided parts (AVClip2 / 4, 3/4 in the figure) that constitute XXXXX.m2ts that constitute AVClip.
  • the Java archive file multiplexed on the AVClip by interleaving will be read out at a higher bandwidth than the dynamic roux celling. Because of this high bandwidth reading, the playback device reads the Java archive file in a relatively short time.
  • Java interleaved archive files are not preloaded.
  • the current playback time reaches the portion of the AVClip recording area on the BD-ROM where the carousel / interleaved Java archive file is embedded, it is loaded into the local memory 29 of the playback device. .
  • the recording format of the Java archive file there are those shown in Fig. 42 and Fig. 43 (a) in addition to those shown in Fig. 2, so the read attribute is set as shown in Fig. 43 (b). Can be done.
  • the read attribute is “Preload” indicating that the read is to be read into the mouth-cal memory 29 prior to the title playback, and during the title playback, There are "Load.
  • Carousel indicating that the data is read using the carousel method
  • "LoadlnterLeave” indicating that the data is read using the interleaving method during title playback.
  • the read attribute whether it is carouseled or interleaved is indicated by a subscript, but this may be omitted.
  • FIG. 44 (a) shows an example of the data management table.
  • FIG. 44 (b) is a diagram showing a change in the storage content of the local memory 29 due to the assignment of the data management table.
  • the occupied area in the local memory 29 is shown on the vertical axis, and the horizontal axis is the PL time axis in one title.
  • application # l is described so that the entire PL time axis in one title is set as a live range.Therefore, in this title, Chaptei # l to Chaptei # 5, the local memory 29 Will occupy the area.
  • the read priority is a priority that determines the priority of reading to the local memory 29.
  • the read priority has a plurality of values.
  • FIG. 45 (a) is a diagram showing the memory size of the oral memory 29 in the old and new playback devices in comparison.
  • Arrow mkl indicates the memory size of the old playback device
  • arrow mk2 indicates the memory size of the new playback device. From the comparison of the arrows, it is assumed that the memory size of the local memory 29 in the new playback device is three times or more that of the old playback device. In this way, when memory size varies, applications are classified into two groups as shown in Figure 45. The first is an application (# 1, # 2) that should be read regardless of the memory size. The second is an application (# 3, # 4) that does not want to read on the old playback device but wants to read on the new playback device.
  • FIG. 45 (b) is a diagram showing an example of a data management table in which read priorities are set.
  • FIG. 46 is a diagram showing a processing procedure of preload control by the application manager 36.
  • the data management table in the title to be played is read (steps S1, 1, 1), and the application having the lowest applicationlD while having the highest read priority in the data management table is designated as application i.
  • Step S1 1 2 the judgment of Step S1 13 and Step S114, and preloading the application i to the local memory 29 (Step S115).
  • the loop processing is repeated until step S116 is determined to be No and step S117 is determined to be No.
  • Step S113 is a determination as to whether or not the read attribute of the application i is preload. -Mandatory or Optional. If the read priority is determined to be Mandatory in step S113 and the read priority is determined to be Mandatory in step S114, the application is preloaded in the local memory 29 (step S113). 1 5). If it is determined in step S113 that the read attribute is “speak”, steps S114 to S115 are skipped.
  • Step S116 of the two steps that define the requirements for terminating the loop processing determines whether or not an application k with the next highest application ID and the same read priority as application i exists. It is. If such an application; k exists, the application k is made an application (step S119).
  • Steps S120 to S123 are processing executed when it is determined in step S114 that the read priority is ⁇ Optional. '
  • step S120 it is determined whether or not there is an application having the same application ID and a high read priority; j.
  • Step S122 is a step of determining whether or not the remaining capacity of the oral memory 29 exceeds the size of the application i. If step S120 is No and step S122 is Yes, application i will be preloaded into local memory 29 in step S115. If step S120 is No and step S122 is No, the application i will proceed to step S116 without being preloaded into the oral memory 29.
  • Step S122 is a step executed when it is determined to be Yes in step S122. If an application j having the same applicationlD and a high read priority exists in the local memory 29, whether the sum of the remaining capacity of the local memory 29 and the size of the application j exceeds the size of the application i It is determined whether or not it is not (Step S122), and if it exceeds, the application on the oral memory 29 is overwritten by using the application i; . If it is less, the application i is not preloaded into the oral memory 29, and the process directly proceeds to step S116. An example of the reading process in steps S115 and 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.
  • an application with a read priority of Mandatory is read into the local memory 29 in step S115.
  • an application whose read priority is Optional is read in step S123 after the determination in steps S120 to S122.
  • preloading is performed so as to overwrite the application of the same applicationlD already in the local memory 29, so one of the multiple applications is exclusively It will be loaded into local memory 29.
  • Java files of different sizes can be loaded into the local memory 29 according to the memory size.Thus, for playback devices with a small memory size, thumbnail images with the minimum necessary resolution A Java archive file with an SD image with a medium resolution is used for a playback device with a medium memory size, and a high resolution is used for a playback device with a large memory size. Java archive files with HD images can be imported to local memory 29.
  • FIG. 48 is a diagram illustrating a specific example of the reading process with reference to the data management table.
  • the two applications in this figure are two applications that have the same applicationID (application # 3). One of them is embedded in the AVClip, and the read priority is set to mandatory. The other is recorded in a file different from the AVClip, and the read priority is set to Optional. Since the former application is embedded in the AVClip, the live range corresponding to the embedded portion is described as a live range (title # l: chapter # 4 ⁇ # 5). Among these applications, application # 2 and application # 3 are provided with a read attribute indicating a mouth.
  • Fig. 48 (b) is a diagram showing application # 2 and application # 3 stored exclusively at different time points on the title time axis. This is a consideration given to playback on a playback device that has only the minimum required memory size. If the data management table having such contents is to be processed, the application manager 36 performs different processing according to the memory scale according to the flowchart of FIG. 46 described above.
  • the application manager can load data into the local memory 29 as long as the required memory size is sufficient.
  • the problem here is when reading by a playback device with a large memory size. Despite having a large memory scale, the inability to read application # 3 until it reaches Chapter # 4 to Chapter # 5 is a waste of memory scale. Therefore, in the data management table in this figure, the same application # 3 is given a read attribute indicating preload and recorded on the BD-ROM, and these are given the same applicationID.
  • step S121 Since the former application has a read priority of ⁇ Optional, it is preloaded only when step S121 becomes Yes (step S115). In this way, the playback device having a large memory size loads the same application embedded in the AVClip into the local memory 29 without waiting for the arrival of title # 1, Chapter # 4 to Chapter # 5. ( Figure 48 (c)).
  • FIG. 49 is a diagram showing a processing procedure of the load processing based on the data management table.
  • the loop processing consisting of step S131 to step S133 is repeated while the tile playback is continued.
  • Step S1311 is for judging whether or not the live section of the application having the start attribute indicating AutoRun has arrived. If it arrives, the application having the startup attribute indicating AutoRun is set to the application q (step S134), and a motion instruction to start the application q is issued to the Java virtual machine 38, and the application q Is read from the local memory 29 to the work memory 37 (step S135).
  • -Step S133 is a determination as to whether or not all PLs in the title have been reproduced. This determination is made based on whether or not a playback end event has been received from the Playback Control Engine 32, as described in the fifth embodiment. If completed, the process of this flowchart ends.
  • step S132 it is determined whether or not a call has been made from the running application. If there is, the called application is set to the application q (step S136), and it is determined whether or not the current reproduction time point is a live range of the application q in the application management table (step S133). ). If it is not a live range, a start failure is displayed (step S148), and the process returns to the loop consisting of steps S131 to S133. If it is a live range, load processing is performed according to the flowchart in FIG.
  • Step S138 in FIG. 50 is a judgment indicating whether or not the current reproduction time point is a live range of the application q in the data management table. If it is not a live range, application q cannot be loaded into local memory 29. In this case, a start 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. In this case, since a head seek for reading the application occurs, the PL playback is interrupted (step S145).
  • step S139 it is determined whether a read attribute is added to the application. Absence of read attribute means that The location q means that it is not carouseled or interleaved. However, even if the read attribute is not added, it is permissible to place the application q in the oral memory 29. Therefore, the application is read out, knowing that the playback has been interrupted. That is, the application is read from the BD-ROM to the oral memory 29, and then the application is read to the work memory 37 (step S140).
  • Steps S141 to S146 are processing performed when step S139 is determined to be Yes.
  • step S141 it is determined whether or not the application is preloaded by referring to the read attribute. If preloaded, the process moves to step S135. —
  • Step S142 is a determination step executed when the read attribute is load, and determines whether application q is carouseled or interleaved. If interleaved, the cache sense is executed by the Java virtual machine 38 (step S144). If the application q exists in the local memory 29, the process proceeds to step S 135, and the application q is sent to the Java virtual machine 38.
  • step S144 If there is no application in the local memory 29, exception processing such as branching to the top menu title is performed (step S144). If the carousel is used, a timer is set (step S148), and the cache sense is executed by the Java virtual machine 38 (step S148) until the timer times out (step S148). 4 6). If the application q appears in the local memory 29, the process proceeds to step S135 in FIG. 49, and the application q is loaded into the Java virtual machine 38. If a timeout occurs, exception processing such as branching to the top menu title is performed (step S144).
  • FIG. 51 is a diagram schematically showing how an application is read by the Java virtual machine 38.
  • Arrows ⁇ I, 2 indicate the reading of Java archive files that are alive in the application management table, are alive in the data management table, and have read attributes indicating force-rucelling and interleaving.
  • the arrow ⁇ 1 indicates the local memory 29 sense performed in steps S65 and S67. This local memory 29 sense stores data embedded by carousel or interleaving In this case, the internal memory 29 is sensed because it may exist in the local memory 29.
  • the arrow ⁇ 2 is a read corresponding to step S135, and indicates a load from the local memory 29 to the work memory 37 when the application exists in the local memory 29.
  • the arrow with X indicates that there is no data in the local memory 29.
  • the arrow Vl, 2 indicates that a Java archive file that is alive in the application management table but is not alive in the data management table and has no read attribute exists.
  • An arrow VI corresponds to the reading in step S145, and indicates a request for direct reading from the BD-ROM by the Java virtual machine 38.
  • the arrow V2 indicates that the Java archive file is read from the BD-ROM to the work memory 37 according to the request.
  • Arrows 1, 2, and 3 indicate that a Java archive file that is alive in the application management table and alive in the data management table but has no read attribute is read.
  • Arrow 1 corresponds to the reading in step S140, and indicates a request for direct reading from the BD-ROM by the Java virtual machine 38.
  • Arrow 2 indicates the read of the Java archive file to the oral memory 29 according to the request.
  • Arrow 3 indicates the reading of the Java file from the local memory 29 to the work memory 37.
  • FIG. 52 (a) shows the internal structure of a BD-J object according to the seventh embodiment. What is different from FIG. 7 (b) is that a playlist management table has been added.
  • FIG. 5.2 (b) is a diagram showing an example of the playlist management table. As shown in this figure, the playlist management table includes a PL specification and a playback attribute of the PL.
  • FIG. 53 (a) shows the title time axis in a non-AV title when the playback attribute is set to indicate non-automatic playback.
  • the title time axis is determined from the live range of the application, as in the non-AV title.
  • FIG. 53 (d) shows a case in which the playback attribute is set to indicate “AutoPlay” in the playlist management table, and the activation of the main application has failed. Also in this case, the default PL playback by the Playback Control Engine 32 is performed irrespective of the failure to start the application, so the time axis of the default PL is the title time axis. '
  • the playback attribute of the playlist management table is set to "AutoPlay", it takes 5 to 10 seconds to start the Java application. However, while it is being activated, it will be in a state where something is being shown for the time being. This "state in which something is in the picture" can supplement the startup delay at the start of title execution.
  • FIG. 52 (c) is a diagram illustrating what processing is performed by the playback device when there is a PL whose playback attribute is set to AutoPlay in the playlist management table of the branch destination title.
  • the application manager 36 in the BD-J module 35 Immediately thereafter, it instructs the Playback Control Engine 32 to start playback of this AutoPlayPL. In this way, the PL whose playback attribute is AutoPlay is instructed to start playback immediately after the title branch.
  • the application manager 36 performs the processing according to the processing procedure shown in FIG.
  • FIG. 54 is a flowchart showing the processing procedure of the application manager 36 according to the seventh embodiment. This flowchart is different from the flowchart of FIG. 38 in that steps S103 and S104 are added before step S21, so that steps S21 and S22 are interposed. Step S100 is added, and step S105 is added between step S23 and step S26.
  • Step S103 is to determine whether or not the playback attribute of the playlist management table of the corresponding title is AutoPlay. If it is AutoPlay, the playback control for the default PL is started by the Playback Control Engine 32 (Step S.I0 Step S1000 determines whether or not the playback is being performed by the Presentation Engine 31. If, go to step S101.
  • Step S105 is a determination step executed when Step S23 is Yes and Step S25 is No, and indicates whether or not the playback attribute is AutoPlay. If not, notify the module manager 34 of the end of the title. If it is AutoPlay, the process proceeds to step S1-1, and the process is continued.
  • FIG. 7 is a diagram schematically illustrating what kind of reproduction is performed by the reproduction.
  • the title to be played here is a non-AV title including a game application that stacks falling tile pieces.
  • the playback attribute of the playlist management table is set to AutoPlay
  • the default PL playback by the Playback Control Engine 32 is also started. Since the execution of the game application and the playback of the default PL are performed in parallel, a composite image with the foreground as the screen of the game application and the background as the playback image of the default PL is shown in the upper left part of Fig. 55. Will be displayed. It is assumed that this game application ends abnormally on the way.
  • the game application is forcibly terminated by the application manager 36, but the title PL is in a state where something is reflected because the default PL is continuously played.
  • the BD-J object has two tables, a data management table and an application management table.
  • the present embodiment discloses a form in which these are integrated into one table. .
  • the item of the read attribute in the data management table is abolished, and an attribute called the ready attribute is provided in the start attribute instead.
  • the Ready attribute is a type of an activation attribute indicating that an application is pre-loaded into the oral memory 29 in preparation for a call from another application or a call from the application manager 36.
  • Fig. 56 (b) is a diagram showing the relationship between application handling and startup attributes.
  • the application is handled by whether it is preloaded (1), automatically started when the current playback point reaches the valid section, or responded to a call from another. It is either activated (2), loaded according to the progress of the title regeneration (3), or alive, and these differences lead to the five aspects shown in Fig. 56 (b). Appear.
  • the startup attribute is set to AutoRun when preloading is performed and "automatic startup", and when loading is performed and "automatic startup”.
  • the application manager 36 can load the application whose start attribute is set to AutoRun and the application whose start attribute is set to Ready before starting the title playback. Preloads the memory 29. By doing so, it becomes possible to preload the application into the local memory 29 without providing the read attribute.
  • FIG. 57 is a diagram schematically illustrating how an application is read by the Java virtual machine 38 according to the eighth embodiment. The reading in this figure is based on Figure 51.
  • Arrows ⁇ 1,2 indicate the reading of a Java archive file that is alive in the application's data management table and whose startup attribute is set to the Ready attribute. Arrows 1, 2, and 3 indicate that an application whose application attribute is “Persistent” is loaded in the application's overnight management table.
  • the processing by the application manager 36 can be simplified. Can be. It should be noted that the application's data management table may be further simplified by eliminating the read priority.
  • the ninth embodiment is an embodiment in which the read priority is represented by a combination of information meaning Optional and a numerical value from 0 to 255.
  • FIG. 59 is a diagram showing a data management table to which group attributes have been assigned.
  • the group attribute can be set in two ways, such as no exclusive group and exclusive group. If there is an exclusive group, the group number is described. In Fig. 59 (a), “#" in title # l indicates that there is no exclusive group. On the other hand, “group # l” in title # 2 and # 3 indicates that there is an exclusive group, and title # 2 and # 3 ′ indicate that the group belongs to the exclusive group called group # l.
  • the playback device After reading each application into the local memory 29 based on the data management table, the playback device according to the present embodiment verifies the group attribute of the application in the local memory 29. If there are two or more applications belonging to the same exclusive group in the local memory 29, one of them is deleted from the oral memory 29.
  • a specific example of an exclusive group is a group consisting of a launcher application and an application started by this application. Since the number of applications activated by this application is limited to one in principle, the local memory 29 is a chopstick that has only one launcher + 1 application. If there are three or more applications, the application manager 36 must perform the process of deleting them from the local memory 29. The application checks whether the existing application is a launcher + 1 application.
  • FIG. 60 is a diagram showing variations of the allocation unit.
  • the first row shows the three applications recorded on the BD-ROM.
  • the management table is shown.
  • the second row shows the title unit
  • the third row shows the disk unit
  • the fourth row shows the disk set unit composed of multiple BD-ROMs.
  • the arrows in the figure schematically show the assignment of the application management table. Referring to this arrow, the application management tables # 1, # 2, and # 3 in the first row are assigned to titles # 1, # 2, and # 3, respectively, shown in the second row. You can see it.
  • application management table # 4 is allocated for each disk, and application management table # 5 is allocated for the entire disk set. In this way, by setting the allocation unit of the application management table to a unit larger than the title, an application that survives while one BD-ROM is being loaded or one of the multiple BD-ROMs is loaded. An application can be defined that survives while it is being served.
  • the optical disc according to the present invention is implemented as a BD-ROM.
  • the optical disc of the present invention is characterized by a recorded dynamic scenario and an index table. -Does not depend on the physical properties of the ROM. Any recording medium that can record the dynamic scenario and the Index Table may be used. For example,
  • Optical discs such as DVD-ROM, DVD-RAM, DVD-RW, DVD-R, DVD + RW, DVD + R, CD-R, and CD-RW; and magneto-optical discs such as PD and MO may be used.
  • a semiconductor memory card such as a compact flash card, a smart media, a memory stick, a multimedia card, a PCM-CIA card, etc. may be used.
  • a magnetic recording disk (i) such as a flexible disk, SuperDisk, Zip, Clik !, or a removable hard disk drive such as an ORB, Jaz, SparQ, SyJet, EZFley, or a micro drive may be used.
  • a hard disk with a built-in device may be used.
  • the playback device in all the embodiments decodes the AVClip recorded on the BD-ROM and outputs it to the TV, but the playback device is only a BD-ROM drive, and the other components are
  • the TV may be provided.
  • the playback device and the TV can be incorporated in a home network connected by IEEE1394.
  • the playback device in the embodiment is of a type used by connecting to a television, but may be a playback device integrated with a display.
  • only the portion that forms an essential part of the processing may be used as the playback device.
  • the playback device is manufactured based on the internal configuration of the playback device described in each embodiment regardless of any of these aspects.
  • the act is an act of practicing the invention described in the specification of the present application.
  • the transfer of the playback device shown in each embodiment at no charge (free of charge, sales and free of charge is a gift), lending, and import are also implementations of the present invention.
  • the act of inviting the general user to transfer or lend these items by displaying them at stores, soliciting logs, and distributing pamphlets is also an act of implementing the playback device.
  • (E) Menu for displaying a list of chapters (Chapter Menu) and its behavior are controlled.
  • the MOVIE object to be controlled may be recorded on a BD-ROM so that it can be branched from the Tbp Menu. It may be called by pressing the Chapter key of the remote control key.
  • TP-extra-header When recording on a BD-ROM, it is desirable to add an extension header to each TS bucket constituting the AVClip.
  • the extension header is called TP-extra-header, and has a data length of 4 bytes including U Arribval-Time-Stamp, u copy_j> ermission_indicator and 3 ⁇ 4 :.
  • TP_extra — TS buckets with headers (hereinafter abbreviated as EX-attached TS packets) are grouped in groups of 32 and written to three sectors.
  • the 32 TS packets with EX in 3 sectors are called "Aligned Unit".
  • the playback device 200 When used in a home network connected via IEEE1394, the playback device 200 transmits Aligned Units by the following transmission processing.
  • the sender device removes the TP-extra-header from each of the 32 EX-attached TS packets included in the Aligned Unit, encrypts the TS bucket body based on the DTCP standard, and outputs it.
  • isochronous packets are inserted everywhere between TS buckets. This insertion point is based on the time indicated in the Arribval-ime-Stamp of the TP-extra-header.
  • the playback device 200 outputs DTCP_Descriptor with the output of the TS bucket.
  • DTCP_Descriptor indicates copy permission / prohibition setting in TP-extra-header. If the DTCP_Descriptor is described to indicate “copy prohibited” here, the TS bucket will not be recorded on other devices when used in a home network connected via IEEE1394.
  • the digital stream recorded on the recording medium is the AVClip, but may be a DVD-Video standard or a DVD-Video Recordin standard VOB (Video Object).
  • VOB is a program stream conforming to the ISO / IEC13818-1 standard, obtained by multiplexing video streams and audio streams.
  • the video stream in AVClip may be in MPEG4 or WMV format.
  • the audio stream may be a Linear-PCM system, a Dolby-AC3 system, an MP3 system, an MPEG-AAC system, Dts, or WMA (Windows media audio).
  • the video work in each embodiment is an analog video signal broadcast on analog broadcast. It may be obtained by encoding a signal. It may be stream data composed of a transport stream broadcast by digital broadcasting. Also, the contents may be obtained by encoding analog / digital video signals recorded on a video tape. Furthermore, the content may be obtained by encoding an analog / digital video signal directly taken from a video camera. Alternatively, it may be a digital work distributed by a distribution server.
  • the DBD-J module 35 may be a Java platform embedded in a device for receiving satellite broadcasting. If the BD-J module 35 is such a Java platform, the playback device according to the present invention is Also, it can be used as STB for MHP.- Further, it may be a Java platform embedded in a device for processing control of a mobile phone.This BD-J module 35 is a Java platform. If so, the playback device according to the present invention will also serve as a mobile phone.
  • the MOVIE mode may be placed above the BD-J mode.
  • the interpretation of the dynamic scenario in the MOVIE mode and the execution of control procedures based on the dynamic scenario place a light burden on the playback device, so that there is no problem if the MOVIE mode is executed in the BD-J mode. Because.
  • only one mode of operation guarantee is required.
  • the reproduction process may be executed only in the BD-J mode.
  • the playback control synchronized with the PL playback can be performed, so that the MOVIE mode does not have to be provided.
  • a navigation command may be provided in the interactive graphics stream to be multiplexed on the DAVClip, and a branch from one PL to another PL may be realized.
  • the playback device according to the present invention may be used for personal use, such as in a home theater system.
  • the internal configuration of the present invention is disclosed in the above embodiment, and since it is clear that mass production is performed based on this internal configuration, the present invention can be industrially used in terms of quality. From this, the reproducing apparatus according to the present invention has industrial applicability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

 BD-ROMには、分岐可能な複数タイトルと、各タイトルの再生時に実行可能なJavaアプリケーションとが記録されている。タイトルは、AVClipと、アプリケーション管理テーブルとを有しており、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、アプリケーション管理テーブルは、アプリケーションと、対応するタイトルにおけるアプリケーションの起動属性とを対応づけて示し、起動属性には、分岐元におけるアプリケーションの状態を継続させる継続属性(Persistent)と、分岐元においてアプリケーションが非起動状態である場合、当該アプリケーションを自動的に起動させるAutoRun属性とがある。

Description

明細書 記録媒体、 再生装置、 プログラム、 再生方法 技術分野
本発明は、 仮想マシンを対象にしたプログラムの起動を制御する、 起動制御技 術の技術分野に属する発明であり、 本起動制御技術を記録媒体、 民生用の再生装 置、 プログラムに応用する場合の応用技術に深く係る。 ' 背景技術
Javaプログラム等、 仮想マシンを対象にした制御技術は、 通信、 放送を初め、 様々な技術分野に浸透している。 特に放送分野においては、 デジタル映像の再生 に従って、 Javaアプリケーシヨンを動作させるという技術が既に確立されており、 Javaアプリケーションによるメニュー制御を伴った様々なサービスが、視聴者の 興味を集めている。
放送分野から更に発展して、現在ディスクコンテンツにおける再生制御を Java プログラミングで実現するための様々な工夫が検討されている。 ここでディスク コンテンツの再生進行は、 一本の再生時間軸に沿った単純なものではなく、 ある 再生時間軸から別の再生時間軸への分岐が有り得る複雑なものである。 このディ スクコンテンツにおいてこの分岐の単位は、 タイトルと呼ばれる。 タイ トルは、 1つ以上の再生時間軸をもち、アプリケーションはこのタイトル内の時間軸上に、 起動時点、 終了時点が定義されることになる。 ここで、 あるタイ トル内の時間軸 に沿ってアプリケーションを動作させようとすると、 タイ トルからタイ トルへの 分岐が発生した際、 現在起動中のアプリケーションを全て終了させたり、 更に、 改めてアプリケーションを起動しなおすという手間が多く発生する。 ここで、 1 つのタイ トル終了から、 次のタイ トル開始までをタイトルバゥンダリというが、 多くのアプリケーションを起動させたり、 終了させる必要があると、 このタイ ト ルバウンダリの期間が異様に長くなり、 分岐先タィ トルの再生がなかなか開始し ないという事態が生じる。 発明の開示 本発明の目的は、 アプリケ一シヨン口一ドゃアプリケ一ション終了が何度も繰 り返されることによる、 タイトルバゥンダリの長期間化を避けることができる再 生装置を提供することである。
上記目的は、 アプリケーションと、 対応するタイ トルにおけるアプリケーショ ンの起動属性とを対応づけて示す管理テ―ブルが記録されており、起動属性には、 分岐元タイ トルにおいてアプリケーションが非起動状態である場合、 当該分岐先 タイトルにおいてアプリケ一シヨンを自動的に起動させる自動起動属性がある、 ことを特徴とした記録媒体により達成される。 この記録媒体における自動起動属 性は、 分岐元においてアプリケーションが非起動状態である場合、 当該アプリケ ーシヨンを自動的に起動させる旨を示しているので、 分岐元非起動一分岐先自動 起動属性の組合せのみアプリケーションを起動する。アプリケーションの起動は、 分岐元非起動一分岐先自動起動属性の組合せ時に限られるので、 タイ トル間の分 岐により、 再生が複雑に進行し.たとしても、 アプリケーション起動処理が冗長に 行われることにない。 冗長なアプリケーション起動を避けることができるので、 タイトルバウンダリを短期間にすることができる。 これによりタイトルバウンダ リをユーザに意識させないスムーズな再生制御を実現することができる。 このた め、 複数タイトルにわたるような長編もののコンテンツや、 DVD— BOX のよう に、 複数 BD-ROMに記録されたシリーズ物コンテンツを提供する場合に真価を 発揮する。 図面の箇単な説明
図 1は、 本発明に係る再生装置の使用行為についての形態を示す図である。 図 2は、 BD-ROMにおけるファイル 'ディ レクトリ構成を示す図である。
図 3は、 AVClip時間軸と、 PL時間軸との関係を示す図である。
図 4は、 4つの Clip— Information_file— nameによりなされた一括指定を示す図 である。
図 5は、 PLraarkによるチャプター定義を示す図である。
図 6は、 SubPlayltem時間軸上の再生区間定義と、同期指定とを示す図である。 図 7 ( a ) は、 ] Movieオブジェクトの内部構成を示す図である。
図 7 (b ) は、 BD-Jオブジェクトの内部構成を示す図である。
図 7 ( c ) は、 Javaアプリケーションの内部構成を示す図である。 図 8 (a) は、 Javaアーカイブファイルに収められているプログラム、 データ を示す図である。
図 8 (b) は、 xletプログラムの一例を示す図である。
図 9 (a) は、 トップメニュー、 title#l、 title#2といった一連のタイトルを示 す図である。
図 9 (b) は、 PlayList#l、 PlayList#2の時間軸を足し合わせた時間軸を示す 図である。
図 10は、 本編タイ トル、 オンラインショッピングタイトル、 ゲームタイトル という 3つのタイ トルを含むディスクコンテンツを示す図である。
図 1 1は、 図 10に示した 3つのタイ トルの再生画像の一例を示す図である。 図 12 (a) は、 図 1 0の破線に示される帰属関係から各アプリケーションの 生存区間をグラフ化した図である。
図 12 (b) は、 図 12 (a) の生存区間を規定するため、 記述されたアプリ ケ一ション管理テーブルの一例を示す図である。
図 13 (a) は、 起動属性設定の一例を示す図である。
図 13 (b) は、 他のアプリケーションからのアプリケーション呼出があって 初めて起動するアプリケーション (application#2)を示す図である。
図 14 (a) (b) は、 Suspend が有意義となるアプリケーション管理テープ ル、 生存区間の一例を示す図である。
図 1 5は、 起動属性がとり得る三態様 (Persistent, AutoRun, Suspend)と、 直前タィトルにおけるアプリケーション状態の三態様 (非起動、起動中、 Suspend) とがとりうる組合せを示す図である。
図.1 6は、 本発明に係る再生装置の内部構成を示す図である。
図 1 7 (a) は、 BD-ROMに存在している Javaアーカイブファイルを、 口一 カルメモリ 29上でどのように識別するかを示す図である。
図 17 (b) は、 図 17 (a) の応用を示す図である。
図 18は、 ROM24に格納されたソフトウエアと、ハードウェアとからなる部 分を、 レイァ構成に置き換えて描いた図である。
図 19は、 Presentation Engine 31〜モジュールマネ一ジャ 34による処理 を模式化した図である。 .
図 20は、アプリケーションマネージャ 36による処理を模式化した図である。 図 21は、 ワークメモリ 37〜Default Operation Manager 40を示す図であ る。
図 22は、 アプリケーションマネージャ 36による分岐時の制御手順を示す図 である。
図 23は、アプリケーション終了処理の処理手順を示すフローチャートである。 図 24は、 アプリケーション終了の過程を模式的に示した図である。
図 25 (a) は、 PL時間軸上に生存区間を定めたアプリケーション管理テ一 ブルを示す図である。
図 25 (b) は、 図 25 (a) のアプリケーション管理テーブルに基づき、 ァ プリケーシヨンの生存区間を示した図である。
図 26 (a) は、 PL時間軸から定まるタイ トル時間軸を示す。
図 2 (b) は、 メインとなるアプリケーションの生存区間から定まるタイ ト ル時間軸を示す。
図 26 (c) は、 複数アプリケーションの生存区間から定まるタイ トル時間軸 を示す図である。
図 27は、 タイ トル再生時におけるアプリケーションマネージャ 36の処理手 順を示すフローチャートである。
図 28 (a) は、 BD-ROMにより実現されるメニュー階層を示す図である。 図 28 (b) は、 メニュー階層を実現するための MOVIEオブジェクトを示す 図である。
図 29は、 Index Tableと、 Index Tableから各 Movieオブジェクトへの分岐 とを模式化した図である。
図 30 (a) は、 図 29 (b) のように Index Tableが記述された場合におけ る分岐を示す。
図 30 (b) は、 非 AV系タイ トルが強制終了した際における分岐を示す図で める。
図 31は、モジュールマネージャ 34の処理手順を示すフローチャートである。 図 32は、 アプリケーションマネージャ 36によるアプリケーション強制終了 の動作例を示す図である。
図 33は、 Playback Control Engine 32による PL再生手順を示すフローチヤ
—トである。 図 34は、 アングル切換、 SkipBack,SkipNextの受付手順を示すフローチヤ一 トである。 .
図 35は、 SkipBack,SkipNextAPIがコールされた際の処理手順を示すフロー チャートである。
図 36は、 Presentation Engine 31による処理手順の詳細を示すフローチヤ ートである。
図 37は、 SubPlayltemの再生手順を示すフローチヤ一トである。
図 38は、 第 5実施形態に係るアプリケーションマネージャ 36の処理手順を 示すフローチャートである。
図 39は、 データ管理テーブルの一例を示す図である。 - 図 40は、 BD-Jォブジェクトが想定している実行モデルを示す図である。 図 4 (a) は、 口一カルメモリ 29における Javaアーカイブファイル生存 を示す生存区間を示す図である。
図 41 (b) は、 図 41 (a) での Javaアーカイブファイル生存区間を規定 するため、 記述されたデータ管理テ一プルを示す図である。
図 42は、 カル一セル化による Javaアーカイブファイル埋め込みを示す図で あ。。
図 43 (a) は、 インターリーブ化による AVClip埋め込みを示す図である。 図 43 (b) は、 読込属性の 3つの類型を示す図である。
図 44 (a) は、 データ管理テーブルの一例を示す図である。
図 44 (b) は、 図 44 (a) のデータ管理テーブルの割り当てによるロー力 ルメモリ 29の格納内容の変遷を示す図である。
図 45 (a) は、 新旧再生装置におけるローカルメモリ 29のメモリ規模を対 比して示す図である。
図 45 (b) は、 読込優先度が設定されたデータ管理テーブルの一例を示す図 である。
図 46は、 アプリケーションマネージャ 36によるプリロード制御の処理手順 を示す図である。
図 47 (a) は、 applicationID が同一であるが、 読込優先度は互いに異なる 複数のアプリケーションを規定するデータ管理テーブルの一例を示す図である。 図 47 (b) は、 図 47 (a) のデータ管理テーブルの割り当てによるロー力 ルメモリ 2 9の格納内容の変遷を示す図である。
図 4 8 ( a ) は、 プリロードされるべきアプリケーション、 ロードされるべき アプリケーションに同一の applicationIDを付与するよう記述されたデータ管理 テーブルの一例を示す図である。
図 4 8 ( b ) は、 メモリ規模が小さい再生装置における口一カルメモリ 2 9.の 格納内容の変遷を示す図である。
図 4 8 ( c ) は、 メモリ規模が大きい再生装置におけるローカルメモリ 2 9の 格納内容の変遷を示す図である。
図 4 9は、 データ管理テーブルに基づくアプリケ一ションマネージャ 3 6によ るロード処理の処理手順を示す図である。 - 図 5 0は、 アプリケーション qの生存区間に、 現在の再生時点が到達した場合 のアプリケーションマネージャ 3 6による処理手順を示す図である。
図 5 1は、 Java仮想マシン 3 8によるアプリケ一ションの読み込みがどのよう にして行われるかを模式化した図である。
図 5 2 ( a ) は、 第 7実施形態に係る BD-Jオブジェクトの内部構成を示す図 である。
図 5 2 ( b ) は、 プレイリスト管理テーブルの一例を示す図である。
図 5 2 ( c ) は、 分岐先タイトルのプレイリスト管理テ一ブルにおいて、 再生 属性が AutoPlayに設定された PLが存在する場合、 再生装置がどのような処理 を行うかを示す図である。
図 5 3 ( a ) は、 再生属性が非自動再生を示すよう設定された場合の非 AV系 タイトルにおけるタイトル時間軸を示す図である。
図 5 3 ( b ) は、 再生属性が AutoPlayに設定された非 AV系タイ トルのタイ トル時間軸を示す図である。
図 5 3 ( c ) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 アプリケーションが強制終了した場合を示す図である。 図 5 3 ( d ) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 メインアプリの起動に失敗したケースを示す図である。 図 5 4は、 第 7実施形態に係るアプリケ一シヨンマネージャ 3 6の処理手順を 示すフローチャートである。
図 5 5は、 プレイリスト管理テ一プルにおいて" 再生属性 = AutoPlay" に設定 されることにより、 どのような再生が行われるかを模式化した図である。
図 56 (a) (b) は、 アプリケーションの扱いと、 起動属性との関係を示した 図である。
図 57は、 第 8実施形態に係る Java仮想マシン 38によるアプリケーション の読み込みがどのようにして行われるかを模式化した図である。
図 58 (a) (b) は、 第 9実施形態に係る読込優先度の一例を示す図である。 図 59 (a) は、 グループ属性が付与されたデータ管理テーブルを示す図であ る。
図 59 (b) は、 アプリケーション管理テーブルに基づくローカルメモリ 29 に対するアクセスを示す図である。 - 図 60は、 アプリケーション管理テーブルの割当単位のパリエーションを示す 図である。
発明を実施するための最良の形態
(第 1実施形態)
以降、 本発明に係る再生装置の実施形態について説明する。 先ず始めに、 本発 明に係る再生装置の実施行為のうち、 使用行為についての形態を説明する。 図 1 は、 本発明に係る再生装置の、 使用行為についての形態を示す図である。 図 1に おいて、 本発明に係る再生装置は再生装置 2 0 0であり、 テレビ 3 0 0、 リモコ ン 4 0 0と共にホームシアターシステムを形成する。
この BD-ROM 1 0 0は、 再生装置 2 0 0、 リモコン 3 0 0、 テレビ 4 0 0に より形成されるホームシアターシステムに、 映画作品を供給するという用途に供 される。
以上;^本発明に係る再生装置の使用形態についての説明である。
続いて本発明に係る再生装置の再生の対象となる、 記録媒体である BD-ROM について説明する。 BD-ROM により、 ホームシアターシステムに供給されるデ イスクコンテンツは、 互いに分岐可能な複数タイ トルから構成される。 各タイ ト ルは、 1つ以上のプレイリストと、 このプレイリストを用いた動的な制御手順と からなる。
プレイリストとは、 1つ以上のデジタルストリームと、 そのデジタルストリー ムにおける再生経路とから構成され、"時間軸" の概念をもつ BD-ROM上のァク セス単位である。以上のプレイリストと、動的な制御手順とを包含しているため、 タイトルはデジタルストリーム特有の時間軸の概念と、 コンピュータプログラム 的な性質とを併せもっている。 '
図 2は、 BD-ROMにおけるファイル 'ディ レクトリ構成を示す図である。 本図 において BD-ROMには、 ; Rootディ レクトリの下に、 BDMVディ レクトリがあ る。
BDMV ディ レク ト リ には、 拡張子 bdmv が付与されたフ ァ イ ル (index.bdmv,MovieObject.bdmv)と、 拡張子 BD-J が付与されたフ ァイル (00001.BD-J,00002.BD-J,00003.BD-J)がある。そしてこの BDMVディ レクトリ の配下には、更に PLAYLISTディ レクトリ、 CLIPINFディ レクトリ、 STREAM ディレクトリ、 BDARディ レクトリと呼ばれる 4つのサブディ レクトリが存在す る。 PLAYLIST ディ レク ト リ には、 拡張子 mpls が付与されたフ ァ イル (00001.mpls,00002.mpls,00003mpls)がある。
CLIPINF ディ レク ト リ には、 拡張子 clpi が付与されたフ ァ イ ル (O0001.clpi,00002.clpi,00003.clpi)がある。
STREAM ディ レク ト リ には、 拡張子 m2ts が付与されたフ ァ イル (00001.m2ts,00002.m2ts,00003.m2ts)がある。
BDAE デ ィ レク ト リ には、 拡張子 jar が付与されたフ ァ イ ル (00001.;jar,00002.jar,00003jar)がある。 以上のディ レクトリ構造により、 互いに 異なる種別の複数ファイルが、 BD-ROM上に配置されていることがわかる。
本 図 に お い て 拡 張 子 .m2ts が 付 与 さ れ た フ ァ ィ ル
(00001.m2ts,00002.m2ts,00003.m2ts )は、 AVClipを格納している。 AVClip には、 MainCLip、 SubClip といった種別がある。 MainCLip は、 ビデオストリ ーム、 オーディオスト リーム、 プレゼンテーショングラフィクスストリーム、 ィ ンタラクティブグラフィクスストリームというような複数エレメンタリストリー ムを多重化することで得られたデジタルストリームである。
SubClipは、 オーディオストリーム、 グラフィクスストリーム、 テキスト字幕 ストリーム等、 1 つのエレメンタリストリームのみにあたるデジタルストリーム である。
拡張子" clpi" が付与されたファイル (00001.clpi,00002.clpi,00003.clpi ) は、 AVClipのそれぞれに 1対 1に対応する管理情報である。管理情報故に、 Clip 情報は、 AVClip におけるスト リ一ムの符号化形式、 フレームレート、 ビッ ト レ —ト、 解像度等の情報や、 頭出し位置を示す EP— mapをもっている。
拡 張 子 " mpls " が 付 与 さ れ た フ ァ イ ル
(00001.mpls,00002.mpls,00003.mpls )は、 プレイリスト情報を格納したフ アイルである。 プレイリスト情報は、 AVClip を参照してプレイリストを定義す る情報である。 プレイリストは、 MainPath情報、 PLMark情報、 SubPath情報 から構成される。
MainPath情報は、 複数の Playltem情報からなる。 Playltemとは、 1つ以上 の AVClip時間軸上において、 In_Time,Out— Timeを指定することで定義される 再生区間である。 Playltem情報を複数配置させることで、 複数再生区間からな るプレイリスト(PL)が定義される。 図 3は、 AVClipと、 PLとの関係を示す図で ある。第 1段目は AVClipがもつ B#間軸を示し、第 2段目は、 PLがもつ時間軸を 示す。 PL情報は、 Playltem#l,#2,#3という 3つの Playltem情報を含んでおり、 これら Playltem#l,#2,#3の In— time,Out_timeにより、 3つの再生区間が定義さ れることになる。 これらの再生区間を配列させると、 AVClip 時間軸とは異なる 時間軸が定義されることになる。 これが第 2段目に示す PL時間軸である。 この ように、 Playltem情報の定義により、 AVClipとは異なる時間軸の定義が可能に なる。
AVClipに対する指定は、 原則 1つであるが、複数 AVClipに対する一括指定も あ り 得 る 。 こ の一括指定 は 、 Playltem 情報 に お け る 複数の Clip— Information— file_name に よ り な さ れ る 。 図 4 は 、 4 つ の Clip_Information_file_nameによりなされた一括指定を示す図である。本図にお いて第 1段目〜第 4段目は、 4つの AVClip時間軸 (AVClip#l,#2,#3,#4の時間軸) を示し、 第 5 段目は、 PL 時間軸を示す。 Playltem 情報が有する、 4 つの Clipjnformation— file— nameにて、 これら 4つの時間軸が指定されている。 こう することで、 Playltemが有する In— time,OutJimeにより、択一的に再生可能な 4つの再生区間が定義されることになる。 これにより、 PL時間軸には、切り換え 可能な複数アングル映像からなる区間 (いわゆるマルチァンダル区間)が定義され ることになる。
PLmark情報は、 PL時間軸のうち、 任意の区間を、 チャプターとして指定す る情報である。 図 5は、 PLmarkによるチャプター定義を示す図である。 本図に おいて第 1段目は、 AVClip時間軸を示し、第 2段目は PL時間軸を示す。 図中の 矢印 pkl,2は、 PLmarkにおける Playltem指定 (ref— to— Playltem_ld)と、一時点 の指定 (mark_time_stamp)とを示す。 これらの指定により PL時間軸には、 3つ のチャプター (Chaptei#l,#2,#3)が定義されることになる。
SubPath情報は、 複数の SubPlayltem情報からなる。 SubPlayltem情報は、 SubClipの時間軸上に In_ hne,Out_Timeを指定することで再生区間を定義する。 また SubPlayltem情報は、 SubClip時間軸上の再生区間を、 PL時間軸に同期さ せるという同期指定が可能であり、 この同期指定により、 PL 時間軸と、 SubPlayltem 情報時間軸とは同期して進行することになる。 図 6は、 SubPlayltem時間軸上の再生区間定義と、 同期指定を示す図である。本図におい て第 1段目は、 PL時間軸を示し、 第 2段目ほ SubPlayltem時間軸を示す。 図中 の SubPlayltem.IN— timeは再生区間の始点を、 SubPlayltem.Out— timeは再生 区間の終点をそれぞれ示す。 これにより SubClip時間軸上にも再生区間が定義さ れている;!とがわかる。 矢印 Snlにおいて Sync— Playltem— Idは、 Playltemに 対する同期指定を示し、矢印 Sn2において sync— start_PTS— of— Playltemは、 PL 時間軸における Playltem上の一時点の指定を示す。
複数 AVClip の切り換えを可能とするマルチアングル区間や、 AVClip— SubClip を同期させ得る同期区間の定義を可能とするのが、' BD-ROM における プレイリスト情報の特徴である。 以上の Clip情報及びプレイリスト情報は、" 静 的シナリォ" に分類される。何故なら、 以上の Clip情報及びプレイリスト情報に より、 静的な再生単位である PLが定義されるからである <5 以上で静的シナリオ についての説明を終わる。
続い " 動的なシナリオ" について説明する。 動的シナリオとは、 AVClip の 再生制御を動的に規定するシナリオデータである。"動的に" というのは、再生装 置における状態変化やユーザからのキ一イベントにより再生制御の中身がかわる ことをいう。 BD-ROMでは、 この再生制御の動作環境として 2つのモ一ドを想 定している。 1つ目は、 DVD再生装置の動作環境と良く似た動作環境であり、 コ マンドベースの実行環境である。 2つ目は、 Java仮想マシンの動作環境である。 これら 2つの動作環境のうち 1つ目は、 HDMVモードと呼ばれる。 2つ目は、 BD-Jモードと呼ばれる。 これら 2つの動作環境があるため、 動的シナリオはこ のどちらかの動作環境を想定して記述される。 HDMV モードを想定した動的シ ナリオは Movieオブジェクトと呼ばれ、 管理情報により定義される。 一方 BD- J モードを想定した動的シナリオは BD-Jォブジヱタトと呼ばれる。
先ず初めに Movieォプジヱクトについて説明する。
< Movieオブジェクト >
Movie オブジェク トは、" タイ トル" の構成要素であり、 フ ァイル MovieObject.bdmvに格納される。 図 7 ( a ) は、 Movieオブジェクトの内部構 成を示す図である。 Movieォブジェクトは、 属性情報、 複数のナビゲーシヨンコ マンドからなるコマンド列からなる。
属性情報は、 PL時間軸において、 MenuCallがなされた際、 MenuCall後の再 生再開を意図しているか否かを示す清報 (resume一 intention— flag)、 PL時間軸に おいて MenuCallをマスクするかを示す情報 (menu call mask),タイトルサーチ W
をマスクするかを示す情報 (title— search— flag)からなる。 Movieォブジェクトは、" 時間軸" +" .プログラム的制御" という 2つの性質を併せ持つことができるで、 本編再生を実行するもの等、多様な種類のタイトルがこの Movieォブジヱクトに より記述されることになる。
ナビゲーシヨンコマンド列は、 条件分岐、 再生装置における状態レジスタの設 定、 状態レジスタの設定値取得等を実現するコマンド列からなる。 Movieォブジ ェクトにおいて記述可能なコマンドを以下に示す。
PlayPLコマンド
書式:: PlayPL (第 1引数, 第 2引数) - 第 1引数は、プレイリストの番号で、再生すべき PLを指定することができる。 第 2引数は、 その PLに含まれる Playltemや、 その PLにおける任意の時刻、 Chapter, Markを用いて再生開始位置を指定することができる。
Playltem により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatPlayltemO,
Chapter により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatChapterO,
時刻情報により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatSpecified TimeOという。
JMPコマンド
書式: JMP引数 .
JMPコマンドは、現在の動的シナリォを途中で廃棄し (discard),引数たる分岐 先動的シナリオを実行するという分岐である。 JMP命令の形式には、分岐先動的 シナリオを直接指定している直接参照のものと、 分岐先動的シナリオを間接参照 している間接参照のものがある。
Movie ォブジェクトにおけるナピゲーシヨンコマンドの記述は、 DVD におけ るナビゲーシヨンコマンドの記述方式と良く似ているので、 DVD 上のディスク コンテンツを、 BD-ROM に移植するという作業を効率的に行うことができる。 Movieォブジェク卜については、 以下の国際公開公報に記載された先行技術が存 在する。 詳細については、 本国際公開公報を参照されたい。 国際公開公報 W0 2004/074976 以上で Movieォブジェクトについての説明を終える。続いて BD-Jォブジェク トについて説明する。
<BD-Jオブジェクト >
拡張子 BD-Jが付与されたファィル (00001.BD-J,00002.BD-J,00003.BD-J)は、 BD-Jォブジェクトを構成する。 BD-Jォブジェクトは、 Javaプログラミング環 境で記述された、 BD-Jモードの動的シナリオである。 図 7- ( b ) は、 BD-Jォブ ジェク卜の内部構成を示す図である。 本図に示すように BD-Jォブジェクトは、 Movie すブジェクト同様の属性情報、 アプリケーション管理テーブルからなる。 属性情報を有している点で BD-Jォブジェクトは Movieォブジ工クトとほぼ同じ である。 Movieォブジェクトとの違いは、 BD-Jォブジェクトはコマンドが直接 記述されていない点である。 つまり Movieオブジェクトにおいて制御手順は、 ナ ピゲーシヨンコマンドにより直接記述されていた。 これに対し BD-Jオブジェク トでは、 そのタイ トルを生存区間としている Javaアプリケ一ションをアプリケ ーション管理テーブル上に定めることにより、間接的に制御手順を規定している。 このような間接的な規定により、 複数タイ トルにおいて制御手順を共通化すると いう、 制御手順の共通化を効率的に行うことができる。
図 7 ( c ) は、 Javaアプリケーションの内部構成を示す図である。 本図におい てアプリケーションは、 仮想マシンのヒープ領域 (ワークメモリとも呼ばれる)に ロードされた 1つ以上の xletプログラムからなる。 このワークメモリでは、 1つ 以上のスレツドが動作しており、 ワークメモリに口一ドされた xletプログラム、 及び、 スレッドから、 アプリケーションは構成されることになる。 以上がアプリ ケ一ションの構成である。
このアプリケーションの実体にあたるのが、 BDMVディ レクトリ配下の BDAR ディ レクトリに格納された Java アーカイブファイル (00001.jar,00002.jar)であ る。 以降、 Javaアーカイブファイルについて説明する。
Javaアーカイブフアイル (00001.;jar,00002.;jar)は、 Javaアプリケーションを構 成するプログラム、データを格納したアーカイブファイルである。図 8 ( a )は、 アーカイブファイルにより収められているプログラム、 データを示す図である。 本図におけるデータは、 枠内に示すディ レクトリ構造が配置された複数ファイル を、 javaアーカイバでまとめたものである。枠内に示すディ レクトリ構造は、 root ディ レクトリ、 javaディ レクトリ、 imageディ レクトリとからなり、 rootティに com.mon.pk 力 javaアイレクトリに aaa.class,bbb .classが、 imageアイ レクト リに、 menujpgが配置されている。 ; javaアーカイブファイルは、 これらを]' ava アーカイバでまとめることで得られる。 かかるデータは、 BD-ROM からキヤッ シュに読み出されるにあたって展開され、 キャッシュ上で、 ディ レクトリに配置 された複数ファイルとして取り扱われる。 Javaアーカイブファイルのファイル名 における "xxxxx"という 5桁の数値は、 アプリケーションの ID(applicationlD)を 示す。 本 Javaアーカイブファイルがキャッシュに読み出された際、 このフアイ ル名にお:ける数値を参照することにより、 任意の Javaアプリケーションを構成 するプログラム, データを取り出すことができる。
Javaアーカイブファイルにおいて 1つにまとめられるファイルには、 xletプ ログラムがある。
xletプログラムは、 JMF(Java Media Frame Work)インターフェイスを利用す ることができる Javaプログラムであ 。 xletプログラムは、 キーイベントを受 信する EventListner等、 複数の関数からなり、 JMF等の方式に従って、 受信し たキーイベントに基づく処理を行う。
図 8 ( b )は、 xletプログラムの一例を示す図である。 JMFA"BD://00001.mpls"; は、 PLを再生するプレーヤインスタンスの生成を Java仮想マシンに命じるメソ ッドである。 A.playは、 JMFプレーヤインスタンスに再生を命じるメソッドで ある。 かかる JMFプレーヤインスタンス生成は、 JMFライブラリに基づきなさ れる。 xletプログラムの記述は、 BD-ROMの PLに限らず、 時間軸をもったコン テンッ全般に適用可能な JMFの記述である。このような記述が可能であるので、 Javaプログラミングに長けたソフトハウスに、 BD-Jォブジェクト作成を促すこ とができる。
図 8 ( b ) における JumpTItleO;は、 ファンクション APIのコールである。 こ のファンクション APIは、他のタイトルへの分岐 (図中では title#l)を再生装置に 命じるものである。 ここでファンクション APIとは、 BD-ROM再生装置により 供給される API(Appliation Interface)である。 JumpTitleコマンドの他にも、 フ アンクシヨン APIのコールにより、 BD-ROM再生装置特有の処理を xletプログ ラムに記述することができる。
BD-Jモ ドにおいて PL再生は、 JMFインターフヱイスにより規定される。 この JMFプレーヤインスタンスは、 PL時間軸を定めるものだから、 タイトル時 間軸は、 この JMFプレーヤインスタンスをもったタイ トルから定まる。 また
BD-Jモードにおいてタイトルからタイトルへの分岐は JumpTitleAPIのコ一 ルにより規定される。 JmnpTitleAPI コールは、 いわばタイトルの終了時点を定 めるものなので、 こうした JMFプレーヤインスタンス、 JumpTitleAPI コール をもったアプリケーションが、 BD-J モードにおいてタイ トルの開始及び終了を 律することになる。かかるアプリケーションを本編再生アプリケーションという。 以上が、 BD-Jモードにおける動的シナリオについての説明である。 この BD-J モード おける動的シナリオにより、 PL再生と、 プログラム的制御とを併せも つたタイ トルが定義されることになる。 尚、 本実施形態においてアプリケーショ ンを構成するプログラム、データは、 Javaアーカイブファイルにまとめられたが、 LZHファイル、 zipフアイルであつてもよい。
<タイトル時間軸〉
タイトルを構成する静的シナリオ、 動的シナリオについて説明を終えたところ で、 これらによりどのような時間軸が定義されるかについて説明する。 タイトル により定義される時間軸は、"タイトル時間軸"と呼ばれる。タイ トル時間軸とは、 Movieオブジェクト、 又は、 BD-Jォブジェクトにより再生が命じられる PLに より構成される。 ここで一例を挙げるのは、図 9 ( a )のようなタイ トルである。 このタイトルは、 トップメニュ >title#l→title#2→トップメニュー、 トツプメ 二 - ~~ title#3 トップメニューという一連のダイ トルである。 かかるタイトル のうち、 title#lは PlayList#l、 PlayList#2 title#2が PlayList#3、 title#3が PlayList#4の再生を命じるものなら、図 9 ( b )のように、 PlayList#l、 PlayList#2 の時間軸を足し合わせた時間軸を、 title#lはもつことになる。同様に title#2は、 PlayList#3時間軸からなる時間軸を、 title#3は PlayLis #4時間軸からなる時間 軸を持つことになる。 これらタイトル時間軸における PL時間軸ではシームレス 再生が保証されるが、 タイ トル時間軸間ではシームレス再生の保証は必要でなく なる。 Javaアプリケーションを動作させるにあたつては、 Javaアプリケ一ショ ンを、 仮想マシンのワークメモリ上に存在させてもよい期間 (サービス期間)を、 こうしたタイトル時間軸上に定義せねばならない。 BD-Jモードにおいて Javaァ プリケ一シヨンを動作させるにあたっては、 互いに分岐し合う時間軸上に、 Java アプリケーションのサービス期間を定義せねばならない。 このサービス期間の定 義が、 BD-ROM向けのプログラミングを行うにあたっての留意点になる。
最後に、 index.bdmvに格納された IndexTableについて説明する。 IndexTable は、 タイトル番号と、 Movieオブジェクト、 BD-Jォブジヱタトとを対応づける テーブルであり、 動的シナリオから動的シナリオへの分岐の際、 参照される間接 参照用テーブルである。 IndexTable は、 複数ラベルのそれぞれに対する Index からなる。 各 Indexには、 そのラベルに対応する動的シナリオの識別子が記述さ れている。 こうした IndexTableを参照することで、 Movie-ォブジェクト、 BD- J ォブジヱクトの違いを厳密に区別することなく、 分岐を実現することができる。 IndexTableについては、以下の国際公開公報に詳細が記載されている。詳細につ いては、 本公報を参照されたい。 国際公開公報 WO 2004/025651 A1公報 以上が BD-ROMに記録されているファイルについて説明である。
くアプリケーション管理テーブル >
JMFプレーヤィンスタンス、 JumpTitleAPIコールをもったアプリケーシヨン が、 タイトル時間軸を律することは上述した通りだが、 JMFプレーヤインスタン スゃ JumpTitleAPIのコールをもたないその他のアプリケーションを、 タイトル 時間軸上で動作させる場合、 時間軸の何処からアプリケーションによるサービス を開始し、 時間軸の何処でアプリケーシヨンによるサービスを終えるかという" サービスの開始点 ·終了点"を明確に規定することが重要になる。本実施形態では、 アプリケーションによるサービスが開始してから、終了するまでを、"アプリケー シヨンの生存" として定義する。 アプリケーションの生存を定義するための情報 は、 BD-J オブジェクトにおけるアプリケーション管理テ一プルに存在する。 以 降アプリケ一ション管理テーブルについてより詳しく説明する。
アプリケーション管理テーブル (AMT)は、 各タイトルが有しているタイ トル時 間軸において、 仮想マシンのワークメモリ上で生存し得るアプリケーションを示 す情報である。 ワークメモリにおける生存とは、 そのアプリケーションを構成す る xletプログラムが、 ワークメモリに読み出され、仮想マシンによる実行が可能 になっている状態をいう。 図 7 ( b ) における破線矢印 atlは、 アプリケ一ショ ン管理テーブルの内部構成をクローズアップして示す。 この内部構成に示すよう に、 アプリケーション管理テーブルは、 『生存区間』 と、 そのタイ トルを生存区間 としているアプリケ一ションを示す『applicationID』 と、 そのアプリケ一ション の 『起動属性』 とからなる。
近い将来、 実施されるであろうディスクコンテンツを題材に選んで、 アプリケ ーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。 ここで題材にするディスクコンテンツは、 映像本編を構成する本編タイ トル (title#l)、 オンラインショッピングを構成するオンラインショッピングタイ トル (title#2)、 ゲームアプリケーションを構成するゲームタイトル (title#3)という、性 格が異なる 3つのタイトルを含むものである。 図 1 0は、 本編タイトル、 オンラ ィンショッビングタイ トル、 ゲームタイ トルという 3つのタイ トルを含むディス クコンテンツを示す図である。 本図における右側には IndexTable を記述してお り、 左側には 3つのタイ トルを記述している。
右側における破線枠は、 各アプリケーションがどのタイ トルに属しているかと いう帰属関係を示す。 3 つのタイ トルのうち title#l は、 application#l、 application#2, application#3という 3つのアプリケーションからなる。 title#2 は、 application#3、 application#4という 2つのアプリケーション、 title#3は、 application#5を含む。 図 1 1は、 図 1 0に示した 3つのタイ トルの再生画像の 一例を示す図である。 これら 3つのタイ トルの再生画像において、 図 1 1 ( a ) ( b ) の本編タイ トル、 オンラインショッピングタイ トルには、 ショッピング力 一トを模した映像 (カート crl)lが存在するが、 図 1 1 ( c ) のゲームタイ トルに は、 カート映像が存在しない。 カート crlは、 本編タイ トル、 オンラインショッ ビングタイトルにおいて共通して表示しておく必要があるので、 カートプログラ ムたる application#3を、 title#l、 title#2の双方で起動するようにしている。 こ のように複数タイ トルで起動するようなアプリケーションには、 上述したカート アプリの他に、 映画作品に登場するマスコットを模したエージヱントアプリ、 メ ニューコール操作に応じてメニュー表示を行うメニューアプリがある。
図 1 0の破線に示される帰属関係から各アプリケーションの生存区間をグラフ 化すると、 図 1 2 ( a ) のようになる。 本図において横軸は、 タイ トル時間軸で あり、 縦軸方向に各アプリケーショ ンの生存区間を配置している。 ここで application#l、 application#2は、 title#lのみに帰属しているので、 これらの生 存区間は、 title#l内に留まっている。 application#4は、 title#2のみに帰属して いるので、 これらの生存区間は、 title#2内に留まっている。 application#5は、 title#3 のみに帰属しているので、 これらの生存区間は、 title#3 内に留まってい る。 application#3は、 title#l及び title#2に帰属しているので、 これらの生存区 間は、 title#l— title#2にわたる。 この生存区間に基づき、 アプリケーション管理 テーブルを記述すると、 title#l,#2,#2のアプリケーション管理テーブルは図 1 2 ( b )のようになる。このようにアプリケーション管理テーブルが記述されれば、 title#lの再生開始時において application#l、 application#2、 application#3を ワークメモリにロードしておく。 そして title#2 の開始時に application#l、 application?^をワークメモリから削除して application#3のみにするという制御 を行う。 これと同様に title#2の再生開始時において application#4をヮ一クメモ リにロードしておき、 title#3の開始時に application#3,#4をワークメモリから削 除するという制御を行いうる。
更に、 title#3の再生中において application#5をワークメモリにロードしてお き、 title#3の再生終了時に application#5をワークメモリから削除するという制 御を行いうる。
タイ トル間分岐があった場合でも、 分岐元—分岐先において生存しているアブ リケーシヨンはワークメモリ上に格納しておき、 分岐元にはなく、 分岐先にのみ 存在するアプリケ一ションをワークメモリに読み込めば良いから、 アプリケ一シ ヨンをワークメモリに読み込む回数は必要最低数になる。 このように、 読込回数 を少なくすることにより、 タイ トルの境界を意識させないアプリケーション、 つ まりアンパゥンダリなアプリケーションを実現することができる。
続いてアプリケーションの起動属性について説明する。 起動属性には、 自動的 な起動を示す 「AutoRun」、 自動起動の対象ではないが、 仮想マシンのヮ一クメ モリに置いて良いことを示す 「Persistent」、 仮想マシンのワークメモリにはおか れるが、 CPUパワーの割り当ては不可となる 「Suspend」 がある。
rAutoRunJ は、 対応するタイ トルの分岐と同時に、 そのアプリケーションを ワークメモリに読み込み、 且つ実行する旨を示す生存区間である。 あるタイ'トル から、別のタイトルへの分岐があると、 アプリケーション管理を行う管理主体 (ァ プリケーシヨンマネージャ)は、 その分岐先タイ トルにおいて生存しており、 かつ 起動属性が AutoRunに設定されたアプリケーションを仮想マシンのワークメモ リに読み込み実行する。 これによりそのアプリケーションは、 タイトル分岐と共 に自動的に起動されることになる。 起動属性を AutoRunに設定しておくアプリ ケーシヨンとしては、 JMFプレーヤインスタンス及び JumpTitleAPI コールを もつようなアプリケーションが挙げられる。 何故なら、 このようなアプリケ一シ ヨンは、 タイ トル時間軸を律 "る側のアプリケーションであり、 このようなァプ リケ一シヨンを自動的に起動にしないと、 タイ トル時間軸の概念が曖昧になって しまうからである。
起動属性 「Persistent」 は、 継続属性であり、 分岐元 titleにおけるアプリケー ションの状態を継続することを示す。 またワークメモリにロードしてよいことを 示す属 である。 起動属性が 「Persistent」 である場合、 この起動属性が付与さ れたアプリケーションは、 他のアプリケーションからの呼び出しが許可されるこ とになる。 アプリケーション管理を行う管理主体 (アプリケーションマネージャ) は、 起動中のアプリケーションから呼出があると、'そのアプリケーションの applicationlD が、 アプリケーション管理テーブルに記述されていて、 起動属性 が 「Persistent」 であるか否かを判定する。 「Persistent」 であれば、 そのアプリ ケーシヨンをワークメモリにロードする。 一方、 その呼出先アプリケーションの applicationlD がアプリケーション管理テーブルに記述されていない場合、 その アプリケーションはワークメモリにロードされない。 アプリケ一ションによる呼 出は、 この「Persistent」が付与されたアプリケーションに限られることになる。
「Persistent」 は、 起動属性を明示的に指定しない場合に付与されるデフオル トの起動属性であるから、 あるアプリケーションの起動属性が無指定 「—一」 で ある場合、そのアプリケーションの起動属性の起動属性はこの Persistentである ことを意味する。
これらの起動属性が、 図 1 1のアプリケーションにおいてどのように記述され ているかについて説明する。 図 1 3は、 図 1 2の 3つのアプリケーションに対す る起動属性の設定例である。 図 1 2に示した 3 つのアプリケーションのうち application#2 は、 図 1 3 ( b ) に示すように他のァプリケ一シヨンからのァプ ' リケ一シヨン呼出があって初めて起動するアプリケーションであるとする。 残り の application#l、 application#3は、 title#lの開始と同時に自動的に起動される アプリケーションであるとする。 この場合、 図 1 3 ( a ) に示すように、 アプリ ケ一シヨ ン管理テーブルにおける各アプリケーシ ョ ンの起動属性を、 application#l, application#3は 「AutoRun」、
Figure imgf000022_0001
は、 I PersistentJ と設定しておく。 この場合、 application#l、 application#3は、 title#lへの分岐 時において自動的にワークメモリにロードされ、 実行されることになる。 一方 application^^は、 起動属性が Persistentなので、 「application#3は仮想マシン のワークメモリ上にロードしてよいアプリケーション」 であるとの消極的な意味 に解される。 故に、 application#2は、 application#lからの呼出があって初めて 仮想マシンのワークメモリにロードされ、 実行されることになる。 以上の生存区 間'起動属性により、 仮想マシン上で動作し得るアプリケーションの数を 4個以 下に制限し、 総スレッ ド数を 64個以下に制限することが可能なので、 アプリケ ーシヨンの安定動作を保証することができる。
続いて Suspendについて説明する。
Suspend とは、 リソースは割り付けられているが、 CPUパワーは割り当てら れない状態にアプリケーションが置かれることをいう。かかる Suspendは、例え ばゲームタイ トルの実行中に、 サイドパスを経由するという処理の実現に有意義 である。 図 1 4 ( a ) ( b ) は Suspendが有意義となる事例を示す図である。 図 1 4 ( b ) に示すように、 3 つのタイトル (title#l、 title#2、 title#3)があり、 そ のうち title#l、 title#3はゲーム Tプリを実行するが、 途中の title#2はサイドパ スであり、 映像再生を実現するものである。 サイ ドパスでは、 映像再生を実現す る必要があるため、 ゲームの実行を中断させることになる。 ゲームアプリでは途 中のスコア等が計数されているため、 リソースの格納値は title#2 の前後で維持 したい。 この場合、 title#2の開始時点でゲームアプリを Suspendし、 title#3の 開始時点で application#2をレジュームするというようにアプリケーション管理 テ一ブルを記述する。 こうすることで title#2において application#2は、 リソ一 スは割り付けられているので、 リソースの格納値は維持される。 しかし、 CPUパ ヮ一は割り当てられない状態なので仮想マシンにより application#2は実行され ることはない。 これにより、 ゲームタイトルの実行中に、 サイドパスを実行する という処理が実現される。
図 1 5は、 起動属性がとり得る三態様 (Persistent、 AutoRun, Suspend)と、 直前タィ トルにおけるアプリケ一ション状態の三態様 (非起動、起動中、 Suspend) とがとりうる組合せを示す図である。 直前状態が" 非起動" である場合、 起動属 性が" AutoRun"であるなら、分岐先タィトルにおいてそのアプリケーションは、 起動されることになる。
直前状態が" 非起動" であり、 起動属性が" Persistent", " Suspend" である なら、 分岐先タイ トルにおいてそのアプリケーションは、 何ももせず、 状態を継 続することになる。
直前状態が" 起動中" である場合、 起動属性が" Persistent" AutoRun" で あるなら、 分岐先タイ トルにおいてそのアプリケーションは、 何もせず、 状態を 継続することになる。
起動属性が" Suspend" であるなら、 アプリケーションの状態は Suspendされ ることになる。 直前状態が" Suspend" である場合、 分岐先タイ トルの起動属性 力 Suspend" なら Suspendを維持することになる。" Persistent" AutoRun" であるなら、 分岐先タイ トルにおいてそのアプリケーションは、 レジュ一ムする ことになる。 アプリケ一ション管理テーブルにおいて生存区間及び起動属性を定 義することにより、 タイ トル時間軸の進行に沿って、 Javaアプリケーションを動 作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、 様々なアプリケーションを世に送り出すことができる。 以上が記録媒体について の説明である。 続いて本発明に係る再生装置について説明する。
図 1 6は、 本発明に係る再生装置の内部構成を示す図である。 本発明に係る再 生装置は、 本図に示す内部に基づき、 工業的に生産される。 本発明に係る再生装 置は、 主としてシステム LSIと、 ドライブ装置という 2つのパーツからなり、 こ れらのパーツを装置のキャビネット及ぴ基板に実装することで工業的に生産する ことができる。 システム LSIは、 再生装置の機能を果たす様々な処理部を集積し た集積回路である。 こうして生産される再生装置は、 BD-ROM ドライブ 1、 リ —ドバッファ 2、 デマルチプレクサ 3、 ビデオデコーダ 4、 ビデオプレーン 5、 P-Graphicsデコーダ 9、 Presentation Graphicsプレーン 1 0、 合成部 1 1、 フ オントゼネレ一タ 1 2、 I-Graphics デコーダ 1 3、 スィッチ 1 4、 Interactive Graphicsプレーン 1 5、 合成部 1 6、 HDD 1 7、 リードバッファ 1 8、 デマル チプレクサ 1 9、 オーディオデコーダ 2 0、 シナリオメモリ 2 1、 CPU 2 2、 キ —イベント処理部 2 3、 命令 ROM 2 4、 スィッチ 2 5、 01^1711部2 6、 GLUT 部 2 7、 PSRセット 2 8、 口一カルメモリ 2 9から構成される。 BD-ROM ドライブ 1は、 BD-ROM の口一ディング /ィジェクトを行い、 BD-ROMに対するアクセスを実行する。
リ一ドパッファ 2は、 FIFOメモリであり、 BD-ROMから読み出された TSパ ケッ卜が先入れ先出し式に格納される。
デマルチプレクサ (De-MUX) 3は、 リ一ドパッファ 2から TS パケットを取り 出して、 この TSバケツトを構成する TSバケツトを PESバケツトに変換する。 そして変換により得られた PESバケツトのうち、 CPU2 2から設定された PID をもつものをビデオデコーダ 4、オーディオデコーダ 2 0、 P-Graphicsデコーダ 9、 I-Graphicsデコーダ 1 3のどれかに出力する。
ビデオデコーダ 4は、 デマルチプレクサ 3から出力された複数 PES バケツト を復号して非圧縮形式のピクチャを得てビデオプレーン 5に書き込む。
ビデオ,プレーン 5は、 非圧縮形式のピクチャを格納しておくためのプレーンで ある。 プレーンとは、 再生装置において一画面分の画素データを格納しておくた めのメモリ領域である。 再生装置に複数のプレーンを設けておき、 これらプレー ンの格納内容を画素毎に加算して、 映像出力を行えば、 複数の映像内容を合成さ せた上で映像出力を行うことができる。ビデオプレーン 5における解像度は 1920 X 1080であり、 このビデオプレーン 5に格納されたピクチャデー夕は、 16ビッ トの YUV値で表現された画素データにより構成される。
P-Graphicsデコーダ 9は、 BD-ROM、 HDD 1 7から読み出されたプレゼンテ —シヨングラフィクスス ト リームをデコードして、 非圧縮グラフイクスを Presentation Graphicsプレーン 1 0に書き込む。 グラフィクスストリームのデ コードにより、 字幕が画面上に現れることになる。
Presentation Graphicsプレーン 1 0は、 一画面分の領域をもったメモリであ り、 一画面分の非圧縮グラフィクスを格納することができる。 本プレーンにおけ る解像度は 1920 X 1080であり、 Presentation Graphicsプレーン 1 0中の非圧 縮グラフィタスの各画素は 8 ビッ 卜のインデックスカラーで表現される。 CLUT(Color Lookup Table)を用いてかかるインデックスカラーを変換すること により、 Presentation Graphicsプレーン 1 0に格納された非圧縮グラフィクス は、 表示に供される。
合成部 1 1は、 非圧縮状態のピクチャデータ (i)を、 Presentation Graphicsプ レーン 1 0の格納内容と合成する。 フォントゼネレ一タ 1 2は、 文字フォントを用いて textST ストリームに含ま れるテキストコードをビットマップに展開する。
I-Grap icsデコーダ 1 3は、 BD-ROM又は HDD 1 7から読み出されたインタ ラクティブグラフィクスストリームをデコードして、 非圧縮グラフイクスを Interactive Granniesプレーン 1 5に書き込 。
スィッチ 1 4は、 フォントゼネレ一夕 1 2が生成したフオント列、 P-Graphics デコーダ 9のデコ一ドにより得られたグラフィ タスの何れかを選択的に Presentation Graphicsプレーン 1 0に書き込むスイッチである。
Interactive Graphicsプレーン 1 5は、 I-Graphicsデコ一夕 1 3によるデコー ドで得られた非圧縮グラフィクスが書き込まれる。 - 合成部 1 6は、 Interactive Graphicsプレーン 1 0の格納内容と、 合成部 8の 出力である合成画像 (非圧縮状態のピクチャデータと、 Presentation Graphicsプ レーン 7の格納内容とを合成したもの)とを合成する。
HDD 1 7は、 ネットワーク等を介してダウンロードされた SubClip、 Clip 情 報、 プレイリスト情報が格納される内蔵媒体である。 この HDD 1 7中のプレイ リスト情報は BD-ROM及ぴ HDD 1 7のどちらに存在する Clip情報であつても、 指定できる点で異なる。この指定にあたって、 HDD 1 7上のプレイリスト情報は、 BD-ROM 上のファイルをフルパスで指定する必要はない。 本 HDD 1 7は、 BD-ROMと一体になって、 仮想的な 1つのドライブ (バーチャルパッケージと呼 ばれる)として、 再生装置により認識されるからである。 故に、 Playltem情報に お け る Clip— Information— file— name 及 び SubPlayltem 情 報 の Clip_Information_file_nameは、 Clip情報の格納したファイルのフアイルポディ にあたる 5桁の数値を指定することにより、 HDD 1 7、 BD-ROM上の AVClip を指定することができる。 この HDDの記録内容を読み出し、 BD-ROMの記録内 容と動的に組み合わせることにより、 様々な再生のバリエーションを産み出すこ とができる。
リードバッファ 1 8は、 FIFO メモリであり、 HDD 1 7から読み出された TS バケツトが先入れ先出し式に格納される。
デマルチプレクサ (De-MUX) l 9は、 リードバッファ 1 8から TS バケツトを 取り出して、 TSパケットを PESパケットに変換する。 そして変換により得られ た PESパケットのうち、 所望の streamPIDをもつものをフォントゼネレ一夕 1 2に出力する。
オーディオデコーダ 2 0は、 デマルチプレクサ 1 9から出力された PES パケ ットを復号して、 非圧縮形^:のオーディオデータを出力する。
シナリオメモリ 2 .1は、カレントの PL情報や力レントの Clip情報を格納して おくためのメモリである。 カレント PL情報とは、 BD-ROMに記録されている複 数 PL情報のうち、 現在処理対象になっているものをいう。 カレント Clip情報と は、 BD-ROMに記録されている複数 Clip情報のうち、 現在処理対象になつてい るものをいう。
CPU 2 2は、 命令 ROM 2 4に格納されているソフトゥヱァを実行して、 再生 装置全体の制御を実行する。 ·
キ一ィベント処理部 2 3は、 リモコンや再生装置のフロントパネルに対するキ —操作に応じて、 その操作を行うキーイベントを出力する。
命令 ROM 2 4は、 再生装置の制御を規定するソフトウエアを記憶している。 スィッチ 2 5は、 BD-ROM及び HDD I 7から読み出された各.種デー夕を、 リ 一ドバッファ 2、 リードバッファ 1 8、 シナリオメモリ 2 1、 ローカルメモリ 2 9のどれかに選択的に投入するスィッチである。
CLUT部 2 6は、 ビデオプレーン 5に格納された非圧縮グラフィクスにおける ィンデックスカラーを、 Y,Cr,Cb値に変換する。
GLUT部 2 7は、 Interactive Graphicsプレーン 1 5に格納された非圧縮ダラ フィクスにおけるインデックスカラーを、 Y,Cr,Cb値に変換する。
PSR セッ ト 2 8は、 再生装置に内蔵されるレジスタであり、 64個の Player Status Register(PSR)と、 4096個の General Purpose Register (GPR)とからな る。 Player Status Registerの設定値 (PSR)のうち、 PSR4〜; PSR8は、 現在の再 生時点を表現するのに用いられる。
PSR4は、 1〜100の値に設定されることで、現在の再生時点が属するタイトル を示し、 0 に設定されることで、 現在の再生時点がトップメニューであることを 示す。
PSR5は、 1〜999の値に設定されることで、現在の再生時点が属するチヤプタ 一番号を示し、 OxFFFFに設定されることで、 再生装置においてチャプター番号 が無効であることを示す。 '
PSR6は、 0〜999の値に設定されることで、 現在の再生時点が属する PL (力レ W
ント PL)の番号を示す。
PSR7 は、 0〜255 の値に設定されることで、 現在の再生時点が属する Play Item (力レント Play Item)の番号を示す。
PSR8は、 0〜OxFFFFFFFFの値に設定されることで、 45KHzの時間精度を 用いて現在の再生時点 (力レント PTM(Presentation TiMe))を示す。以上の PSR4 〜PSR8により、 現在の再生時点が特定されることになる。
口一カルメモリ 2 9は、 BD-ROMからの読み出しは低速である故、 BD-ROM の記録内容を一時的に格納しておくためのキャッシュメモリである。 かかるロー カルメモリ 2 9が存在することにより、 BD-J モードにおけるアプリケーション 実行は、 効率化されることになる。 図 1 7 ( a ) は、 BD-ROM に存在している Javaアーカイブファイルを、ローカルメモリ 2 9上でどのように識別するかを示 す図で る。 図 1 7 ( a ) の表は、 左欄に BD-ROM上のファイル名を、 右欄に ローカルメモリ 2 9上のファイル名をそれぞれ示している。 これら右欄、 左欄を 比較すれば、ローカルメモリ 2 9におけるファイルは、ディ レクトリ指定" BDJA" を省いたファイルパスで指定されていることがわかる。
図 1 7 ( b ) は、 図 1 7 ( a ) の応用を示す図である。 本応用例は、 ヘッダ + データという形式で、 ファイルに格納されているデータを格納するというもので ある。 何をヘッダに用いるかというと、 ローカルメモリ 2 9におけるファイルパ スを用いる。 図 1 7 ( b ) に示したように、 口一カルメモリ 2 9では BD-ROM におけるファイルパスの一部を省略したものをファイルパスに用いるから、 当該 ファイルパスをヘッダに格納することで、 各データにおける BD-ROM上の所在 を明らかにすることができる。
以上が、 本実施形態に係る再生装置のハードウ Xァ構成である。 続いて本実施 形態に係る再生装置のソフトウヱァ構成について説明する。
図 1 8は、 ROM 2 4に格納されたソフトウエアと、ハードウエアとからなる部 分を、 レイァ構成に置き換えて描いた図である。 本図に示すように、 再生装置の レイァ構成は、 以下の a),b),c),d-l),d-2),e),£)からなる。 つまり、
a)物理的なハードウヱァ階層の上に、
b) AVClipによる再生を制御する Presentation Engine 3 1、
c)プレイリスト情報及び Clip情報に基づく再生制御を行う Playback Control Engine CJ 2、 という 2つの階層があり、
最上位の階層に
e)タイドル間の分岐を実行するモジュールマネージャ 3 4がある。
これら HDMVモジュール 3 3、 モジュールマネージャ 3 4の間に、 d-l)Movieオブジェクトの解読 ·実行主体である HDMVモジュール 3 3と、 d-2)BD-Jォブジェクトの解読'実行を行う BD-Jモジュール 3 5とが同じ階層 に置かれている。
BD-Jモジュール 3 5は、 いわゆる Javaプラッ トフオームであり、 ワークメモ リ 3 7を含む Java仮想マシン 3 8を中核にした構成になっていて、 アプリケ一 シヨンマネージャ 3 6、 Event Listner Manager 3 9; Default Operation Manager4 0から構成される。 先ず初めに、 Presentation Engine 3 1〜モジュ —ルマネージャ 3 4について説明する。 図 1 9は、 Presentation Engine 3 1〜 モジュールマネージャ 3 4による処理を模式ィ匕した図である。
Presentation Engine 3 1は、 AV再生機能を実行する。 再生装置の AV再生機 能とは、 DVDプレーヤ、 CDプレーヤから踏襲した伝統的な機能群であり、 再生 開始 (Play)、再生停止 (Stop)、一時停止 (Pause On)、一時停止の解除 (Pause Of£)、 Still機能の解除 (still of£)、速度指定付きの早送り(Forward Play(speed))、速度指 定付きの巻戻し (Backward Play (speed)), 音声切り換え (Audio Change), 副映像 切り換え (Subtitle Change),ァングル切り換え (Angle Change)といつた機能であ る。 AV再生機能を実現するべく、 Presentation Engine 3 1は、 リードバッファ 2上に読み出された AVClipのうち、 所望に時刻にあたる部分のデコードを行う よう、 ビデオデコーダ 4、 P-Graphics デコーダ 9、 I-Graphics デコーダ 1 3、 オーディオデコーダ 2 0を制御する。 所望の時刻として PSR8(力レント PTM)に 示される箇所のデコードを行わせることにより、 AVClip において、 任意の時点 を再生を可能することができる。 図中の ©1は、 Presentation Engine 3 1による デコード開始を模式ィ匕して示す。 .
再生制御ェンジン (Playback Control Engine(PCE)) 3 2は、 プレイリストの再 生機能 0)、 再生装置における状態取得 設定機能 (ii)といつた諸機能を実行する。
PLの再生機能とは、 Presentation Engine 3 1が行う AV再生機能のうち、 再生 開始や再生停止を、カレント PL情報及び Clip情報に従って行わせることをいう。 これら機能 (i)〜(ii)は、 HDMVモジュール 3 3〜: BD-Jモジュール 3 5からのファ ンクシヨンコールに応じて実行する。 つまり再生制御エンジン 3 2は、 ユーザ操 作による指示、 レイヤモデルにおける上位層からの指示に応じて、 自身の機能を 実行する。 図 1 9において、 ©2,©3が付された矢印は、 Clip情報及びプレイリ スト情報に対する Playback Control Engine 3 2の参照を模式的に示す。
HDMVモジュール 3 3は、 MOVIEモードの実行主体であり、モジュールマネ ージャ 3 4から分岐先を構成する Movieォプジェクトが通知されれば、分岐先夕 ィトルを構成する Movieオブジェクトをローカルメモリ 2 9に読み出して、この Movieォブジヱクトに記述されたナビゲーシヨンコマンドを解読し、 解読結果に 基づき Playback Control Engine 3 2に対するファンクションコールを実行する。 図 1 9において V2,V3,V4が付された矢印は、モジュールマネージャ 3 4からの 分岐先 Movieォブジ: クトの通知 (2)、 Movieォブジヱクトに記述されたナビゲ ーショ ;コマンドの解読 (3)、 Playback Control Engine 3 2に対するファンクシ ヨンコール (4)を、 模式的に示レている。
モジュールマネージャ 3 4は、 BD-ROMから読み出された Index Tableを保持 して、 分岐制御を行う。 この分岐制御は、 JumpTitleコマンドを HDMVモジュ —ル 3 3が実行した場合、 又は、 タイトルジャンプ APIが BD-Jモジュール 3 5 からコールされた場合、 そのジャンプ先となるタイ トル番号を受け取って、 その タイトルを構成する Movieォブジェクト又は BD-Jオブジェクトを HDMVモジ ユール 3 3又は BD-Jモジュール 3 5に通知するというものである。 図中の V0, V1,V2が付された矢印は、 JumpTitleコマンドの実行 (0)、 モジュールマネージ ャ 3 4による IndexTable参照 (1)、分岐先 Movieォブジェクト(2)の通知を模式的 に示している。
以上が Presentation Engine 3 1〜モジュールマネージャ 3 4についての説明 である。 続いてアプリケーションマネージャ 3 6について、 図 2 0を参照しなが ら説明する。 図 2 0は、 アプリケーションマネージャ 3 6を示す図である。
アプリケーションマネージャ 3 6は、 アプリケーション管理テーブルを参照し たアプリケーションの起動制御、タイトルの正常終了時における制御を実行する。 起動制御とは、 モジュールマネージャ 3 4から分岐先となる BD-Jオブジェク トが通知される度に、 その BD-Jオブジェクトを読み出し、 その BD-Jオブジェ クト内のアプリケーション管理テーブルを参照してローカルメモリ 2 9アクセス を行う。 そして現在の再生時点を'生存区間とするアプリケーションを構成する xletプログラムを、 ワークメモリに読み出すという制御である。 図 2 0における ☆l, 2, ir3'は、 起動制御における分岐先 BD-Jォブジヱクトの通知 (1)、 アプリ ケーション管理テ一ブル参照 (2)、 Java仮想マシン 3 8に対する起動指示を模式 化して示す。 この起動指示により Java仮想マシン 3 8は、 ローカルメモリ 2 9 からワークメモリ 3 7に xletプログラムを読み出す ( 5)。
タイトルの終了制御には、 正常終了時の制御と、 異常終了時の制御とがある。 正常終了時の制御には、 タイ トルを構成するアプリケーションによりジャンプタ ィ トル APIがコールされて、 分岐先タイトルへの切り換えを分岐制御の主体 (モ ジュールマネージャ 3 4)に要求するという制御がある。 この終了制御における、 モジュールマネージャ 3 4通知を模式化して示したのが矢印 6である。 ここで タイトルを正常終了するにあたって、 タイトルを構成するアプリケーションは、 起動されたままであってもよい。 何故なら、 アプリケーションを終了するか否か は、 分岐先タイトルにおいて判断するからである。 本実施形態では深く触れない が、 アプリケーションマネージャ 3 6は、 BD-ROM からローカルメモリ 2 9に Java アーカイブファイルを読み出す (8)との処理を行う。 この口一カルメモリ 2 9への読み出しを模式化したのが 8である。
以上がアプリケーションマネージャ 3 6についての説明である。 続いてワーク メモリ 3 7 -Default Operation Manager 4 0について、 図 2 1を参照しながら 説明する。
ワークメモリ 3 7は、アプリケーションを構成する xletプログラムが配置され るヒープ領域である。 ワークメモリ 3 7は、 本来 Java仮想マシン 3 8内に存在 するが、 図 2 1では、 作図の便宜上、 ワークメモリ 3 7を Java仮想マシン 3 8 上位層に記述している。 ワークメモリ 3 7上の xlet プログラムには、 EventListnerや、 JMFプレーヤィンスタンスが含まれる。
Java仮想マシン 3 8は、 アプリケーションを構成する xletプログラムをヮ一 クメモリ 3 7にロードして、 xletプログラムを解読し、 解読結果に従った処理を 実行する。 上述したように xletプログラムは、 JMFプレーヤィンスタンス生成 を命じるメソッド、 この JMFプレーヤインスタンスの実行を命じるメソッドを 含むので、 これらのメソッドで命じられた処理内容を実現するよう、 下位層に対 する制御を行う。 JMFプレーヤインスタンス生成が命じられば、 Java仮想マシ ン 3 8は、 BD-ROM上の YYYYMPLSフアイルに関連付けられた JMFプレー ャインスタンスを得る。 また、 JMFプレーヤインスタンスにおける JMFメソッ ドの実行が命じられれば、 この JMFメソッドを BD ミ ドルウェアに発行して、
BD再生装置が対応しているファンクションコールに置き換させる。 そして置換 後のファンクションコールを Playback Control Engine 3 2に発行する。
Event Listner Manager 3 9は、 ユーザ操作により生じたイベント(キーィベン ト)を解析し、ィベントの振り分けを行う。図中の実線矢印 01,02は、この Event
Listner Manager 3 9による振り分けを模式的に示す。 STAET、 STOP, SPEED 等、 xletプログラム内の Event Listnerに登録されたキーィベン卜なら、 BD-J オブジェクトにより間接参照されている xletプログラムにかかるイベントを振り 分ける。 START、 STOP, SPEED は、 JMF に対応したイベントであり、 xlet プログラムの Event Listnerには、これらのキーイベントが登録されているので、 本キ—イベントにより xlet プログラムの起動が可能になる。 キ—イベントが
Event Listner 非登録のキ一ィベントである場合、 本キーイベントを Default Operation Manager 4 0に振り分ける。 音声切り換え、 ァンダル切り換え等、 BD-ROM再生装置において生じるキーイベントには、 Event Listnerに登録され ていない多様なものがあり、 これらのキーイベントが生じたとしても、 漏れの無 い処理を実行するためである。
Default Operation Manager 4 0は、 xletプログラム内の Event Listnerに登 録されてないキーイベントが Event Listner Manager 3 9から振り分けられると、 その Event Listner 非登録ィ ベン ト に対応するフ ァ ンクシ ョ ンコールを Playback Control Engine 3 2に対して実行する。 この Default Operation Manager 4 0によるファンクションコ一ルを模式的に示したのが、 図中の矢印◊ 3である。 尚、 図 2 1において Event Listner非登録ィベントは Event Listner Manager 3 9、 Default Operation Manager 4 0により振り分けられたが、 Playback Control Engine 3 2がダイレクトに Event Listner非登録イベントを 受け取り、 再生制御を行ってもよい (図中のぐ4)。
(フローチャートの説明)
以上のアプリケーションマネージャ 3 6についての説明は、 その概要に触れた に過ぎない。 アプリケーションマネージャ 3 6の処理を更に詳しく示したのが図 2 2、 図 2 3のフローチャートである。 以降、 これらのフローチャートを参照し てアプリケーションマネージャ 3 6の処理手順についてより詳しく説明する。 図 2 2は、. アプリケーションマネージャ 3 6による分岐時の制御手順を示す図 である。 本フローチャートは、 ステップ S 2〜ステップ S 5がなす条件を満たす アプリケーション (アプリケーション X という)を、 起動又は終了させるという処 理である。
ステップ S 2は、 分岐元タイ トルで非起動だが、 分岐先タイ トルで生存してい て、 分岐先タィトルにおける起動属性が AutoRim属性のアプリケーシヨン Xが 存在するか否かの判定であり、 もしあれば、 ローカルメモリ 2 9に対するキヤッ シュセンスを行う。 キャッシュセンスの結果、 アプリケーション Xが口一カルメ モリ 2 9上に有れば (ステップ S 7で Yes)、口一カルメモリ 2 9からワークメモリ 3 7にアプリケーション Xを読み込む (ステップ S 8)。 ローカルメモリ 2 9に無 ければ、 , BD-ROMからローカルメモリ 2 9にアプリケーション Xを読み込んだ 上で、 ローカルメモリ 2 9から.ワークメモリ 3 7にアプリケーション Xを読み込 む (ステップ S 9)。
ステップ S 3は、 分岐元タイ トルで起動中で、 分岐先タイトルで非生存のァプ リケーシヨン Xが存在するかどうかの判定である。 もし存在するのなら、 アプリ ケーシヨン Xをワークメモリ 3 7から削除して終了させる(ステップ S 1 0 )。 ステップ S 4は、 分岐元 Suspend, 分岐先 AutoRxm又は Persistentのアプリ ケーシヨンが存在するか否かの判定である。 もし存在するなら、 アプリケ一ショ ン Xを Resumeする(ステップ S 1 1 )。
ステップ S 5は、分岐元タイ トルで起動中で、分岐先 Suspendのアプリケーシ ヨンが存在するか否かの判定である。 もし存在すれば、 アプリケーション X を Suspendする(ステップ S 1 2)。
個々のアプリケーションを終了させるにあたってのアプリケーションマネージ ャ 3 6の処理は、 図 2 3に示すものとなる。 図 2 3は、 アプリケーション終了処 理の処理手順を示すフローチャートである。 本図は、 終了すべき複数アプリケー シヨンのそれぞれについて、 ステップ S 1 6〜ステップ S 2 0の処理を繰り返す ループ処理になっている(ステップ S 1 5 )。 本ループ処理においてアプリケーシ ヨンマネージャ 3 6は起動中アプリケーションを終了するような terminateィベ ントを発行し (ステップ S 1 6 )、 タイマセットして (ステップ S 1 7 )、 ステップ S 1 8〜ステップ S 2 0からなるループ処理に移行する。 この terminateイベント を Event Listnerが受信すれば、 対応する xletプログラムは、 終了プロセスを起 動する。終了プロセスが終了すれば、 その xletプログラムはワークメモリ 3 7か ら解放され、 終了することになる。
ステップ S 1 8〜ステップ S 2 0のループ処理の継続中、 タイマはカウントダ ゥンを継続する。 本ループ処理においてステップ S 1 8は、 発行先アプリケ一シ ョンが終了したか否かの判定であり、 もし終了していればこのアプリケ一シヨン に対する処理を終える。 ステップ S 1 9は、 タイマがタイムアウトしたか否かの 判定でぁリ、 タイムアウトすれば、 ステップ S 2 0において発行先アプリケ一シ ョンをワークメモリ 3 7から削除してアプリケーションを強制終了する。
以上のモジュールマネージャ 3 4の処理を、 図 2 4を参照しながら説明する。 図 2 4は、 アプリケーション終了の過程を模式的に示した図である。 本図にお ける第 段目は、 アプリケーションマネージャ 3 6を、 第 2段目は、 3つのアブ リケーシヨンを示す。図 2 4の第 2段目、左側のァプリケーシヨンは、 terminate ィベントを受信して終了プロセスに成功したアプリケーションを示す。 図 2 4の 第 2段目、 中列のアプリケーションは、 terminateイベントを受信したが終了プ 口セスに失敗したアプリケーションを示す。 第 2段目、 右側のアプリケーション は、 EventListnerが実装されていないので、 terminateイベントを受信すること ができなかったアプリケーションを示す。
第 1段目一第 2段目間の矢印 epl,ep2は、 アプリケーションマネージャによる terminateイベント発行を模式的に示し、 矢印 ep3は、 終了プロセス起動を模式 的に示している。
第 3段目は、 終了プロセス成功時における状態遷移後の状態であり、 このアブ リケ一シヨンは、 自身の終了プロセスにより終了することになる。 これら xletプ ログラムのように、 所定の期間内に終了しないアプリケーションがあれば、 アブ リケ一シヨンマネージャ 3 6は、 それらを強制的にワークメモリ 3 7から取り除 く。 第 4段目は、 アプリケーションマネージャ 3 6による強制終了を示す。 かか る第 4段目の強制終了を規定するのも、 アプリケーションマネージャ 3 6の 1つ の使命といえる。
以上のように本実施形態によれば、 分岐元タイトルで起動しており、 分岐先タ ィ トルで生存していないアプリケーションは、 自動的に終了させられるので、 条 件付き分岐により再生が複雑に進行する場合でも、 再生装置におけるリソースの 限界を越える数のアプリケーション立ち上げはなされ無い。 分岐前後におけるァ プリケ一シ.ヨン動作を保証することができるので、 デジタルストリームを再生さ せながら、 アプリケ一シヨンを実行させるようなディスクコンテンツを多く頒布 することができる。
(第 2実施形態)
第 1実施形態においてアプリケーションの生存区間は、 タイ トル時間軸と一致 していたが、 第 2実施形態は、 PL時間軸の一部をアプリケーションの生存区間 とすることを提案する。 PL時間軸の一部は、チャプターにより表現されるので、 チャプターにて開始点、 終了点を記述することにより、 アプリケーションの生存 区間を規定することができる。 図 2 5 ( a ) は、 PL時間軸上に生存区間を定め たアプリケーション管理テーブルを示す図である。 図 2 5 ( a ) においてアプリ ケーシ ン管理テーブルには、 3つのアプリケーションが記述されており、 この うち application#2は、 title#lの Chaptei*2から Chapter#3までが生存区間に 指定され、 起動属性に AutoRunが規定されている。 このため applications^は、 図 2 5 ( b ) に示すように、 Chaptei#2の始点で起動され、 Chaptei#3の終点で 終了することになる。
一方 application#3は、 title#lの Chapter#4から Chapter#6までが生存区間 に指定されている。 このため application#3は、 図 2 5 ( b ) に示すように、 図 2 5 ( b ) に示すように、 Chapter#4の始点で起動され、 Chapter#6の終点で終 了することになる。
こうして記述されたアプリケーション管理テーブルに基づき、 処理を行うため 本実施形態に係るアプリケーシヨンマネージャ 3 6は、 PLmarkにより指示され るチャプター開始点に到達する度に、 そのチャプター開始点から生存区間が始ま るアプリケーションが存在するか否かを判定し、 もし存在すればそのアプリケー シヨンをワークメモリ 3 7にロードする。
同様に、 チャプター開始点に到達する度に、 そのチャプターの直前のチヤプタ —で生存区間が終わるアプリケーションが存在するか否かを判定し、 もし存在す ればそのアプリケーションをワークメモリ 3 7から解放する。
チャプターという単位でアプリケーションの生存を管理すれば、 アプリケーシ ヨンの生存区間をより細かい精度で指定することができる。 しかしディスクコン テンッには、 時間軸の逆向がありうることに留意せねばならない。 逆行とは、 巻 戻しにより時間軸を逆向きに進行することである。 チャプターの境界でこの逆行 と、 進行とが繰り返されれば、 ヮ一クメモリへのロード、 廃棄が何度もなされ、 余分な読出負荷が生じる。 そこで本実施形態では、 アプリケーションの起動時期 を、 タイトルに入って Playback Control Engine 3 2による通常再生が開始され た瞬間にしている。 ここで PLの再生には、 通常再生、 トリック再生がある。 ト リック再生とは、早送り、巻戻し、 SkipNext,SkipBackがある。かかる、早送り、 巻戻し、 SkipNext,SkipBackがなされている間、 アプリケーション起動を開始せ ず、 通常再生が開始されて初めて、 アプリケーションを起動するのである。 通常 再生開始の瞬間を基準にすることにより、 上述したような生存区間前後の行き来 があった場合でも、 アプリケーションの起動が必要以上に繰り返されることはな い。尚、通常再生開始の瞬間を、アプリケーションの起動基準にするとの処理は、 生存区 が titleである場合にも、 実行してよい。
以上のように本実施形態によれば、 PL より小さい、 チャプターの単位でアブ リケーションの生存区間を規定することができるので、 緻密なァ.プリケ一シヨン 制御を実現することができる。
(第 2実施形態の変更例) '
図 2 5では、 各アプリケーションに優先度が付与されている。 この優先度は、 0〜255の値をとり、アプリケーション間でリソースの使用が競合等が競合した場 合、 どちらのアプリケーションを強制的に終了させるか、 また、 どちらのアプリ ケ一ションからリソースを奪うかという処理をアプリケ一ションマネージャ 3 6 が行うにあたって、 判断材料になる。 図 2 5の一例では、 application#l の優先 度は 255,application#2、 application#3の優先度は 128なので、 application#l -application#2 の競合時において、 アプリケ一ションマネージャ 3 6は優先度 が低い application#2を強制終了するとの処理を行う。
(第 3実施形態)
BD-ROM により供されるディスクコンテンツは、 互いに分岐可能な複数タイ トルから'構成される。各タイ トルは、 1つ以上の PLと、 この PLを用いた制御手 順とからなるもの以外に、 再生装置に対する制御手順のみからなる非 AV系タイ トルがある。 本実施形態は、 この非 AV系タイ トルについて説明する。
こうした非 AV系タイ トルのタイトルでは、 どのようにタイ トル時間軸を定め るのかが問題になる。 図 2 6 ( a ) は、 PL時間軸から定まるタイトル時間軸を 示す。 この場合 PL時間軸がタイ トル時間軸になり、 このタイ トル時間軸上にァ プリケーションの生存区間が定まる。 この基準となる PL時間軸がない場合、 タ ィ トル時間軸は図 2 6 ( b ) ( c ) のように定めるべきである。
図 2 6 ( b ) は、 メインとなるアプリケーションの生存区間から定まるタイト ル時間軸を示す。 メインアプリとは、 タイトルにおいて起動属性が AutoRunに 設定され、 タイトル開始時に自動起動される唯一のアプリケーションであり、 例 えばランチャ一アプリと呼ばれるものがこれにあたる。 ランチャーアプリとは、 他のアプリケーションを起動するアプリケーションプログラムである。
この図 2 6 ( b ) の考え方は、 メインアプリが起動している限り、 タイ トル時 間軸は継続していると考え、 メインアプリが終了すれば、 時間軸を終結させると いうものである。 図 2 6 ( c ) は、 複数アプリケーションの生存区間から定まる タイト 時間軸を示す図である。 タイ トルの開始点で起動されるのは 1つのアブ リケーシヨンであるが、 このアプリケーションが他のァプリケ一ションを呼び出 し、 更にこのアプリケ一ションが別のアプリケーションを呼び出すとの処理が繰 り返されるというケースがある。 この場合、 どれかのアプリケーションが起動し ている限り、 タイ トル時間軸は継続していると考え、 どのアプリケーションも起 動していない状態が到来すれば、 そこでタイ トル時間軸は終結するという考え方 である。 このように非 AV系タイ トルのタイ トル時間軸を定めれば、 AVタイトル であっても、 非 AV系タイ トルであっても、 夕ィ トル時間軸の終結と同時に、 所 定のタイトルに分岐するという処理を画一的に行うことができる。 尚非 AVタイ トルにおけるタイ トル時間軸は、 AV タイトルと対比する上で、 想定した架空の 時間軸に過ぎない。 故に再生装置は、 非 AVタイトルにおけるタイトル時間軸上 を逆行したり、 任意の位置に頭出しすることができない。
以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。
上述したような手順でタイトル終了を行うため第 3実施形態に係るアプリケー シヨンマネージャ 3 6は、 図 2 7に示すような処理で処理を行う。 図 2 7は、 タ ィ トル再生時におけるアプリケーションマネージャ 3 6の処理手順を示すフロー チャートである。 本フローチャートは、 タイトル再生中、 ステップ S 2 1〜ステ ップ S 2 3を繰り返すというループ構造になっている。
ステップ S 1は、タイ トルジャンプ APIが呼び出されたか否かの判定であり、 呼び出されれば、 ジャンプ先タイ トルへの分岐をモジュールマネージャ 3 4に要 求する(ステップ S 2 7)。
ステップ S 2 2は、 タイトル内のアプリケーション呼出を担っているようなメ インアプリが存在するか否かの判定であり、 もし存在するなら、 それの起動の有 無を確認する(ステップ S 2 5 )。 起動してなければ、" タイ トルの終わり" である と解釈し、 モジュールマネージャ 3 4に終結を通知する(ステップ S 2 6)。
ステップ S 2 3は、メインアプリがない場合に実行されるステップであり(ステ ップ S 2 2で No)、 どのアプリケーションも起動してない状態かどうかを判定す る。 もしそうなら、 同じく" タイ トルの終わり" であると解釈し、 モジュールマ ネ一ジャ 3 4に終結を通知する(ステップ S 2 6)。 - 以上のように本実施形態によれば、 PL再生を伴わないタイ トルであっとして も、 ア リケーション実行中は分岐せず、 アプリケーション実行が終了して初め て分岐するという処理が可能になる。
(第 4実施形態)
本実施形態は、 DVDと同様のメニュー制御を BD-ROM上で実現する場合の改 良に関する。 図 2 8 ( a ) は、 BD-ROM により実現されるメニュー階層を示す 図である。 本図におけるメニュー階層は、 TopMenu を最上位に配し、 この TopMenuから下位の TitleMenu、 SubTitleMenu, AudioMenuを選択できる構 造になっている。 図中の矢印 swl,2,3は、 ボタン選択によるメニュー切り換えを 模式的に示す。 TbpMerm とは、 音声選択、 字幕選択、 タイ トル選択の何れを行 うかを受け付けるポタン (図中のボタン snl,sn2,sn3)を配置したメニューである。
TitleMenu とは、 映画作品 (title)の劇場版を選択するか、 ディ レクタ一ズカツ ト版を選択するか、 ゲーム版を選択するか等、 映画作品の選択を受け付けるボタ ンを配置したメニューである。 AudioMenu とは、 音声再生を日本語で行うか、 英語で行うかを受け付けるボタンを配置したメニュー、 SubTitleMenuとは、 字 幕表示を日本語で行うか、 英語で行うかを受け付けるボタンを配置したメニュー である。
こうした階層をもったメニューを動作させるための MOVIEォブジェクトを図 2 8 ( b )に示す。図 2 8 ( b )において MovieObject.bdmvには、 FirstPlay OBJ、 T pMenu OBJ, AudioMenu OB J、 SubTitleMenu OBJが格納されている。
FirstPla ォブジェクト(FirstPlay OBJ)は、 再生装置への BD-ROMのローデ ィング時に自動的に実行される動的シナリオである。
I pMenuォブジヱクト(TopMenu OBJ)は、 TbpMenuの挙動を制御する動的シ ナリオである。 ユーザがメニューコールを要求した際、 呼び出されるのはこの IbpMenuォプジェクトである。 IbpMenuォプジェクトは、 ユーザからの操作に 応じて TopMenu中のボタンの状態を変えるものや、 ボタンに対する確定操作に 応じて分岐を行う分岐コマンドを含む。 この分岐コマンドは、 TopMenu から TitleMenu, TopMenuから SubTitleMentu TopMenuから AudioMenuという メニュー切り換えを実現するものである。
AudioMenuォブジヱクト(AudioMenu OBJ)は、 AudioMenuの挙動を制御す る動的シナリオであり、 ユーザからの操作に応じて AudioMenu中のボタンの状 態を変えるコマンドや、 ポタンに対する確定操作に応じて音声設定を更新するコ マンド¾含む。
SubTitleMenuォブジェクト(SubTitleMenu OBJ)は、 SubTitleMenuの挙動を 制御する動的なシナリォであり、 ユーザからの操作に応じて SubTitleMenu中の ポタンの状態を変えるコマンドや、 ポタンに対する確定操作に応じて字幕設定用 の PSRを更新するコマンドを含む。
TitleMemiオブジェクト(TitleMenu OBJ)は、 TitleMemiの挙動を制御する動 的シナリオであり、 itleMenu中のポタンの状態を変えるものや、 ポタンに対す る確定操作に応じて分岐を行う分岐コマンドをふくむ。
これらのメニュー用 MOVIEオブジェクトにより、 DVDで実現されているよ うなメニュ一の挙動を実現することができる。 以上がメニュ一制御に関連する MOVIEオブジェクトである。
図 2 9は、 Index Tableと、 Index Tableから各 Movieオブジェクトへの分岐 とを模式化した図である。本図では左側に Index Tableの内部構成を示している。 本実施形態における Index Table には、 FirstPLayINDEX、 TopMenuINDEX, Audio MenuINDEX、 Subtitle MenuINDEX, title Menu励 EX、 title#l〜 #mINDEX、 title#m+l〜#nINDEX、 title#0INDEX を含む。 図中の矢印 bcl,2 は、 Index Tableから FirstPlayOBJへの分岐と,: FirstPlayOBJから T pMenuへ の分岐とを模式的に示し、 矢印 bc3,4,5 は、 T pMenu から TitleMenu, SubTitleMenu, AudioMenuへの分岐を模式的に示している。 矢印 bc6,7,8は、 TitleMenuから各 Movieォプジェクトへの分岐を模式的に示している。 FirstPLaylNDEX、 TopMen INDEX, Audio MenuINDEX、 Subtitle MenuINDEX, title MenuINDEXは、それぞれ、 FirstPLayOBJ, IbpMenuOBJ, Audio MenuOBJ, Subtitle MenuOBJ, title MenuOBJについての Indexであ り、 これらの識別子が記述される。
title#l~#mINDEXは、 BD-ROMにおいて 1から m番目にエントリーされて いる titleについての Indexであり、これら 1から mまでの title番号の選択時に おいて分岐先となる MOVIEォブジ Xクトの識別子 (ID)が記述される。
title#m+l~#nINDEXは、 BD-ROMにおいて m+1から n番目にエントリー されている titleについての Indexであり、 これら m+1から nまでの title番号 の選択時において分岐先となる BD-Jオブジェクトの識別子 (ID)が記述される。 title#0INDEXは、 BD-Jォブジヱクトの強制終了時において分岐先になるべき Movieォブジェクト又は BD-Jォブジヱクトを規定する INDEXである。 本実施 形態では、 TopMenuOBJについての識別子が、 この title#0INDEXに格納され ている。
図 3り ( a ) は、 図 2 9のように Index Tableが記述された場合における分岐 を示す。 Index Tableがこのように記述されているので、 ラベル title#l~title#m を分岐先とした分岐コマンドの実行時には、 title#llndex:〜 title#mlndex から Movieォブジェクト #l〜#mの識別子が取り出される。ラベル title#m+l〜title#n を分岐とした分岐コマンドの実行時には、 title#m+llndex〜title#nlndex から BD-J オブジェク #m+l〜#n の識別子が取り出される。 BD-J ォブジェクト #m+l〜#n の識別子は、 フ ァ イ ル名を表す 5 桁の数値であるので、 『00001.BD-J,00002.BD-J,00003.BD-J' · ·』が取り出され、そのファイル名の動 的シナリオがメモリに読み出されて、実行されることになる。これが Index Table を用いた分岐処理である。
図 3 0 (b ) は、 BD-J ォブジヱクト実行時の強制終了時における分岐を示す 図である。 強制終了時における分岐では、 title#01ndexから識別子が取り出され て、 その識別子の動的シナリオが再生装置により実行される。 この識別子が、 ト ップメニュータイ トルの識別子なら、 アプリケーション強制終了時には、 自動的 にトップメニュー OBJが選択されることになる。 以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。 上述した記録媒体の改良に対応 するため、 再生装置内のモジュールマ'ネ一ジャ 3 4は図 3 1に示すような処理手 順で処理を'行う。 図 3 1は、 モジュールマネージャ 3 4の処理手順を示すフロ一 チャートである。 本フローチャートは、 ステップ S 3 1、 ステップ S 3 2からな るループ処理を構成しており、 ステップ S 3 1又はステップ S 3 2のどちらかが Yesになった際、 対応する処理を実行するものである。
ステップ S 3 1は、タイトルジャンプ APIの呼び出しがあつたか否かの判定で ある。 もしタイ トルジャンプ APIの呼び出しがあれば、 分岐先ラベルであるタイ トル番号 j を取得し(ステツプ S 3 3)、 Index Table におけるタイ トル番号 j の Indexから、 IDjを取り出して(ステツプ S 3 4)、 IDjの Movieォプジェクト又は BD-Jォブジェクトを、 HDMVモジュール 3 3又は BD-Jモジュール 3 5に実行 させる(ステップ S 3 5)。
ステップ S 3 2は、 タイトル.終了がアプリケーションマネージャ 3 6から通知 されたか否かの判定であり、 もし通知されれば (ステップ S 3 2で Yes)、 トップメ ニュータイ トルを構成するトップメニュー OBJを HDMVモジュール 3 3又はモ ジュールマネージャ 3 4に実行させる(ステップ S 3 6)。
以上のアプリケーションマネージャ 3 6によるアプリケーション強制終了の動 作例を、 図 3 2を参照しながら説明する。 ここで再生すべきタイトルは、 落下す るタイル片を積み重ねるというゲームアプリを含む非 AV系タイトルである。 図 3 2の下段は、 アプリケーションの生存区間からなるタイ トル時間軸を示し、 上 段は、 タイ トル時間軸において表示される画像を示す。 非 AV系タイ トルがゲ一 ムアプリである場合、 このゲームアプリの生存区間において、 図 3 2の上段左側 のように、 ゲームアプリの一画面が表示される。 ゲームアプリにバグがあり、 異 常終了すると、 アプリケーションマネージャ 3 6は図 2 3のフローチャートに従 つてゲームアプリを強制終了させ、 タイトルの終了をモジュールマネージャ 3 4 に通知する。 タイ トル終了が通知されると、 モジュールマネージャ 3 4はトップ メニュータイ トルに分岐する。 そうすると、 図 3 2の上段右側に示すような画像 が表示され、 ユーザの操作待ちになる。 以上のように本実施形態によれば、 ·プログラムが含むが、 デジタルストリーム は含まないような非 AV系タイ トルの終了時においても、 トップメニュータイ ト ルに分岐するという制御が可能になる。 これによりアプリケーションプログラム がエラ一終了したとしても、 ブラックァゥトゃハングアップの発生を回避するこ とができる。
(第 5実施形態)
BD-Jモードにおいて、 PL再生との同期をどのように実現するかという改良に 関する。 図 8 ( b ) の一例において JMFプレーヤインスタンスの再生を命じる JMF プレーヤインスタンス (A.play;)を Java仮想マシン 3 8が解読した場合、 Java仮想マシン 3 8は: PL再生 APIをコールして、 コール直後に" サクセス" を示す応答をアプリケーションに返す。
Playback Control Engine 3 2は、 PL再生 APIがコールされれば、 PL情報に 基づく処理手順を実行する。 PLが 2時間という再生時間を有するなら、 この 2 時間の間、 上述した処理は継続することになる。 ここで問題になるのは、 Java 仮想マシン 3 8がサクセス応答を返す時間と、 Playback Control Engine 3 2が 実際に処理を終える時間とのギヤップである。 Java仮想マシン 3 8は、 ィベント ドリブンの処理主体であるためコール直後に再生成功か、 再生失敗かを示す応答 を返すが、 Playback Control Engine 3 2による実際の処理終了は 2時間経過後 であるので、 サクセス応答をァプリケーシヨンに返す時間を基準にしたのでは、 2時間経過後にあたる処理終結を感知しえない。 PL再生において早送り、巻戻し、 Skipが行われると、この 2時間という再生期間は 2時間前後に変動することにな り、 処理終結の感知は更に困難になる。
Playback Control Engine 3 2は、 アプリケーションとスタンドアローンで動 作するため、 第 3実施形態のような終了判定では、 PL再生の終了をタイトル終 了と解釈することができない。 そこで本実施形態では、 アプリケーションが終了 してようがいまいが、 ワークメモリ 3 7に JMFプレーヤィンスタンスがある.限 り、つまり、 Presentation Engine 3 1の制御権を BD-Jモジュ一ル 3 5が掌握し ている間、 Playback Control Engine 3 2から再生終結イベントを待つ。 そして 再生終結イベントがあれば、 タイ トルが終了したと解釈して、 次のタイ トルへの 分岐を行うようモジュールマネージャ 3 4に通知する。 こうすることにより、 Playback Control Engine 3 2が PL再生を終結した時点を、タイ トルの終端とす ることができる。
以降図 3 3〜図 3 7のフローチャートを参照して、 Playback Control Engine 3 2による具体的な制御手順を説明する。
図 3 3は、 Playback Control Engine 3 2による PL再生手順を示すフローチヤ ートである。 この再生手順は、 Presentation Engine 3 1に対する制御 (ステップ S 4 6 )と、 BD-ROM ドライブ 1又は HDD 1 7に対する制御 (ステップ S 4 8 ) とを主に含む。本フローチャートにおいて処理対象たる Playltemを Playltem#x とする。本フ口一チヤ一トは、 カレント PL情報 (.mpls)の読み込みを行い(ステツ プ S 4 1 )、 その後、 ステップ S 4 2〜ステップ S 5 0の処理を実行するというも のである。 ここでステップ S 4 2〜ステップ S 5 0は、 ステップ S 4 9が Yesに なるまで、 カレント PL情報を構成するそれぞれの PI情報について、 ステップ S 4 3〜ステップ S 5 0の処理を繰り返すというループ処理を構成している。 この ル一プ処理において処理対象となる Playltemを、 PlayItem#x(PI#x)とよぶ。 こ の Play tem#xは、 カレント PLの先頭の Playltemに設定されることにより、初 期化される(ステップ S 4 2 )。 上述したループ処理の終了要件は、 この Playltem#xがカレント PLの最後の Playltemになることであり(ステップ S 4 9)、 もし最後の Playltemでなければ、 カレント PLにおける次の Playltemが Playltem#xに設定される(ステツプ S 5 0)。
ループ処理において繰り返し実行されるステップ S 4 3〜ステップ S 5 0は、 Playltem#xの Clip— information_file— nameで指定される Clip情報をシナリオメ モリ 2 1に読み込み (ステツプ S 4 3)、 Playltem#xの In_timeを、カレント Clip 情報の EPmap を用いて、 I ピクチャアドレス u に変換し(ステップ S 4 4 )、 Playltem#xの Out_timeを、 カレント Clip情報の EP— mapを用いて、 Iピクチ ャアドレス Vに変換して(ステップ S 4 5 )、 これらの変換で得られたァドレス V の次の Iピクチャを求めて、 そのアドレスの 1つ手前をァドレス wに設定し(ス テツプ S 4 7)、 そうして算出されたアドレス wを用いて、 Iピクチャアドレス u からァドレス wまでの TSバケツトの読み出しを BD-ROMドライブ 1又は HDD 1 7に命じるというものである(ステップ S 4 8)。
一方、 Presentation Engine 3 1 に対しては、 カ レン ト PLMark の mark_time_stampから Playltem#xの Out_timeまでの出力を命じる(ステップ S 4 6 )。 以上のステップ S 4 5〜ステップ S 4 8により、 AVClip において、 Playltem#xにより指示されている部分の再生がなされることになる
その後、 Playltem#xがカレント PLの最後の PIであるかの判定がなされる(ス テツプ S 4 9)。
Playltem# がカレント PLの最後の PIでなければ、 カレント PLにおける次 の Playltemを、 Playltem#xに設定して(ステツプ S 5 0)、 ステップ S 4 3に戻 る。 以上のステップ S 4 3〜ステップ S 5 0を繰り返することにより、 PL を構 成する PIは順次再生されることになる。
図 3 4は、 アングル切り換え手順及び SkipBack,SkipNext の手順を示すフロ 一チャートである。 本フローチャートは、 図 3 3の処理手順と並行してなされる ものであり、 ステップ S 5 1〜S 5 2からなるループ処理を繰り返すというもの である。 本ループにおけるステップ S 5 1は、 アングル切り換えを要求する API が、 Java仮想マシン 3 8からコールされたか否かの判定であり、 アングル切り換 え APIのコールがあれば、 カレント Clip情報を切り換えるという操作を実行す る。
図 3 4のステップ S 5 5は、 判定ステップであり、 Playltem#x の is— multi— angles がオンであるか否かの判定を行う。 is— nmlti一 angles とは、 Playltem#x がマルチアングルに対応しているか否かを示すフラグであり、 もし ステップ S 5 5が Noであるならステップ S 5 3に移行する。 ステップ S 5 5が Yes であるなら、 ステップ S 5 6〜ステップ S 5 9を実行する。 ステップ S 5 6 〜ステップ S 5 9は、切り換え後のアングル番号を変数 yに代入して (ステップ S 5 6)、 Playltem#xにおける y番目の Clip_information_file— nameで指定されて いる Clip情報をシナリオメモリ 2 1に読み出し(ステップ S 5 7)、カレント PTM を、 カレント Clip情報の EP_mapを用いて Iピクチャアドレス uに変換し(ステ ップ S 5 8)、 Playltem# の Outjimeを、 カレント Clip情報の EP— mapを用 いて I ピクチャアドレス Vに変換する(ステップ S 5 9)というものである。 こう して Iピクチャアドレス u,vを変化した後、 ステップ S 4 6に移行する。 ステツ プ S 4 6への移行により、 別の AVClipから TSパケットが読み出されるので、 映像内容が切り換わることになる。
—方、 図 3 4のループにおけるステップ S 5 2は、 SkipBack SkipNextを意味 する APIが Java仮想マシン 3 8からコールされたか否かの判定であり、 もしコ —ルされれば、 図 3 5のフローチャートの処理手順を実行する。 図 3 5は、 SkipBack,SkipNextAPIがコールされた際の処理手順を示すフローチヤ一トであ る。 SkipBack,SkipNextを実行するにあたっての処理手順は多種多様なものであ る。 ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
ステップ S 6 1は、 PSRで示される力レント PI番号、 及び、 カレント PTM を変換することにより、 カレント Mark情報を得る。 ステップ S 6 2は、 押下さ れたのが SkipNext キ一であるか、 SkipBack キーであるかの判定であり、 SkipNext キーであるならステップ S 6 3において方向フラグを +1 に設定し、 SkipBackキーであるならステップ S 6 4において方向フラグを- 1に設定する。 ステップ S 6 5は、カレント PLMarkの番号に方向フラグの値を足した番号を、 カレント PLMarkの番号として設定する。 ここで SkipNextキーであるなら方向 フラグは +1に設定されているのでカレント PLMarkはインクリメントされるこ とになる。 SkipBackキーであるなら方向フラグは- 1に設定されているので、 力 レント PLMarkはデクリメントされることになる。
ステ プ S 6 6では、 カレント PLMarkの ref— to_PlayItem— Idに記述されて いる PI を、 Playltem#x に設定し、 ステップ S 6 7では、 Playltem#x の Clip_information_file_nameで指定される Clip情報を読み込む。 ステップ S 6 8では、 カ レント Clip 情報の EP— map を用いて、 カ レント PLMark の mark— time— stampを、 Iピクチャァドレス uに変換する。一方ステップ S 6 9で は、 Playltem#xの Out— timeを,カレント Clip情報の EP— mapを用いて, Iピク チヤア ドレス V に変換する。 ステップ S 7 0は、 カ レント PLMark の mark— time— stamp 力、ら Playltem#x の Out— time までの出力を Presentation Engine 3 1に命じた上で、 図 3 3のステップ S 4 7に移行する。 こうして Iピク チヤアドレス u,vを変化して、 別の部分の再生を命じた上でステップ S 4 7への 移行するので、 別の AVClipから TSバケツトが読み出されることになり、 映像 内容が切り換えが実現する。
図 3 6は、 Presentation Engine 3 1による処理手順の詳細を示すフローチヤ ートである。 本フローチャートは、 Iピクチャの PTSをカレント PTMに設定し た後で (ステップ S 7 1 )、 ステップ S 7 2〜ステップ S 7 7からなるループ処理 を実行するものである。
続いてステップ S 7 2〜ステップ S 7 7におけるループ処理について説明する。 このループ処理は、カレント PTMにあたるピクチャ、オーディオの再生出力と、 カレント PTMの更新とを繰り返すものである。 本ループ処理におけるステップ S 7 6は、 ループ処理の終了要件を規定している。 つまりステップ S 7 6は、 力. レント PTMが PI#xの Out— timeであることをループ処理の終了要件にしている, ステップ S 7 3は、 早送り API、 又は、 早戻し APIが Java仮想マシン 3 8か らコールされたか否かの判定である。 もしコールされれば、 ステップ S 7 8にお いて早送りか早戻しかの判定を行い、 早送りであるなら、 次の Iピクチャの PTS をカレント PTMに設定する(ステップ S 7 9)。 このようにカレント PTMを、 次 の Iピクチャの PTSに設定することで、 1秒飛びに AVClipを再生してゆくこと ができる。 これにより、 2倍速等で AVClip は順方向に早く再生されることにな る。 早戻しであるなら、 カレント PTMが Playltem#xの Out— timeに到達した かを判定する(ステップ S 8 0)。 もし到達してないのなら、 1つ前の Iピクチャの PTSをカレント FTMに設定する(ステップ S 8 1 )。 このように読出先アドレス Aを、 1つ前の Iピクチャに設定することで、 AVClipを後方向に 1秒飛びに再生 してゆくことができる。 これにより、 2倍速等で AVClip は、 逆方向に再生され ることになる。 尚、 早送り、 巻戻しを実行するにあたっての処理手順は多種多様 なものである。 ここで説明するのはあくまでも一例に過ぎないことに留意された い。
ステップ S 7 4は、 メニューコール APIがコールされたか否かの判定であり、 もしコールされれば、 現在の再生処理をサスペンドして(ステップ S 8 2 )、 メニ ユー処理用のメニュープログラムを実行する(ステップ S 8 3)。 以上の処理によ り、 メニューメニューコールがなされた場合は、 再生処理を中断した上で、 メニ ユー表示のための処理が実行されることになる。
ステップ S 7 5は、 sync— Playltem— id により、 Playltem#x を指定した SubPlayItem#yが存在するか否かの判定であり、 もし存在すれば、 図 3 7のフロ 一チャートに移行する。 図 3 7は、 SubPlayltemの再生手順を示すフローチヤ一 トである。本フローチャートでは、先ずステップ S 8 6において、 カレント PTM は SubPlayItem# の sync— start_PTS— of_j)layItemであるか否かを判定する。も しそうであれば、 ステップ S 9 3において SubPlayItem#yに基づく再生処理を 行うよう Playback Control Engine 3 2に通知する。
図 3 7のステップ S 8 7〜ステップ S 9 2は、 SubPlayItem#yに基づく再生処 理を示すフローチャートである。
ステップ S 8 7では、 SubPlayItem#yの Clip— information— file— nameで指定 される Clip情報を読み込む。ステップ S 8 8では、カレント Clip情報の EP— map を用いて、 SubPlayItem#yの Injime を、 ァドレス に変換する。 一方ステツ プ S 8 9では、 SubPlayItem#yの Out_timeを,カレント Clip情報の EP— mapを 用いて、 アドレス ]3に変換する。 ステップ S 9 0は、 SubPlayItem#yの In— time から SubPlayItem#yの Out— timeまでの出力をデコーダに命じる。 これらの変 換で得られたアドレス i3の次の Iピクチャを求めて、 そのアドレスの 1つ手前を アドレスァに設定し(ステップ S 9 1 )、 そうして算出されたアドレス yを用いて、 SubCUp#zにおけるアドレス αからアドレス Ίまでの TSバケツトの読み出しを BD-ROM ドライブ 1又は HDD 1 7に命じるというものである(ステップ S 9 2)。 また図 3 3に戻って Playback Control Engine 3 2の処理の説明の続きを行う。 ステップ S 5 3は Presentation Engine 3 1による再生制御が完了したかの判定 であり、 最後の Playltem#xに対して、 図 3 6のフローチャートの処理が行われ ている限り、 ステップ S 5 3が Noになる。 図 3 6のフローチャートの処理が終 了して初めて、 ステップ S 5 3.は Yesになりステップ S 5 4に移行する。 ステツ プ S 5 4は、 Java仮想マシン 3 8への再生終結ィベントの出力であり、 この出力 により、 2時間という再生時間の経過を Java仮想マシン 3 8は知ることができ る。
以上が本実施形態における Playback Control Engine 3 2、 Presentation Engine 3 1の処理である。続いて本実施形態におけるアプリケーションマネージ ャ 3 6処理手順について説明する。 図 3 8は、 第 5実施形態に係るアプリケーシ ョンマネージャ 3 6の処理手順を示すフローチャートである。
図 3 8のフローチャートは、 図 2 7のフローチャートを改良したものである。 その改良点は、ステップ S 1一ステップ S 2 2間にステップ S 2 4が追加され、 このステップ S 2 4が Yesになった際、 実行されるステップ S 1 0 1が存在する 点である。
ステップ S 2 4は、 JMFプレーヤインスタンスがワークメモリ 3 7に存在する か否かの判定であり、 もし存在しなければステップ S 2 2に移行する。 存在すれ ば、 ステップ S 1 0 1に移行する。 ステップ S 1 0 1は、 Playback Control Engine 3 2から再生終結イベントが出力されたか否かの判定であり、もし出力さ れれば、 ワークメモリ中の Javaプレーヤィンスタンスを消滅させた上で (ステツ プ S 1 0 2 )、 タイ トル終了をモジュールマネージャ 3 4に通知する(ステップ S 2 6 )。通知されねば、 ステップ S 2 1〜ステップ S 2 4からなるループ処理を繰 り返す。
以上のフローチャートにおいて、 ワークメモリ 3 7に JMFプレーヤインス夕 ンスが存在する限り(ステップ S 2 4で Yes)、 ステップ S 2 2、 ステップ S 2 3は スキップされる。 そのため、 たとえ全てのアプリケーションが終了したとしても タイトルは継続中と解釈される。
以上のように本実施形態によれば、 2時間という再生時間の経過時点をアプリ ケ一シヨンマネージャ 3 6は把握することができるので、 PL再生の終了条件に メニュ一を表示して、 このメニューに対する操作に応じて他のタイ トルに分岐す るという制御を実現することができる。
(第 6実施形態) - 第 6実施形態は、 BD-J オブジェクトにデータ管理テ一プルを設ける改良に関 する。 ,
データ管理テーブル (DMT)は.、 そのタイ トル時間軸においてローカルメモリ 2 9上にロードすべき Javaアーカイブファイルを、 読込属性と、 読込優先度とに 対応づけて示すテーブルである。" ローカルメモリ 2 9における生存" とは、 その アプリケーションを構成する Javaアーカイブファイルがローカルメモリ 2 9か ら読み出され、 Java仮想マシン 3 8内のワークメモリ 3 7への転送が可能になつ ている状態をいう。 図 3 9は、 データ管理テーブルの一例を示す図である。 本図 に示すようにデータ管理テーブルは、 アプリケーションの 『生存区間』 と、 その 生存区間をもったアプリケーションを識別する 『applicationID』 と、 そのアプリ ケーシヨンの 『読込属性』 と、 『読込優先度』 とを示す。
上述したようにアプリケーション管理テーブルには、 生存区間という概念があ り、 データ管理テーブルにも同じ生存区間という概念がある。 アプリケーション 管理テーブルと同じ概念を、 データ管理テーブルに設けておくというのは一見無 駄のように思えるがこれには意図がある。
図 4 0は、 BD-J オブジェクトが想定している実行モデルを示す図である。 本 図における実行モデルは、 BD-ROM、 ローカルメモリ 2 9、 Java仮想マシン 3 8からなり、 BD-ROM、 ローカルメモリ 2 9、 ワークメモリ 3 7という三者の関 係を示す。 矢印 mylは、 BD-ROM→ローカルメモリ 2 9間の読み込みを示し、 矢印 my2は、 ローカルメモリ 2 9→ワークメモリ 3 7間の読み込みを示す。矢印 上の注釈は、 これらの読み込みが、 どのようなタイミングでなされるかを示す。 注釈によると、 BD-ROM→口一カルメモリ 2 9間の読み込みは、 いわゆる" 先読 み" であり、'アプリケーションが必要となる以前の時点に行われねばならない。 また注釈によると、 口一カルメモリ 2 9—ワークメモリ 3 7間の読み込みは、 アプリケ一シヨンが必要になった際になされることがわかる。" 必要になった際" とは、 アプリケーションの生存区間が到来した時点 (1)、 アプリケーションの呼出 が他のアプリケーション又はアプリケーシヨンマネージャ 3 6から指示された時 点 (2)を意味する。
矢印 my3は、ワークメモリ 3 7におけるアプリケーションの占有領域の解放を 示し、矢印 my4は、 ローカルメモリ 2 9におけるアプリケーションの占有領域の 解放を示す。 矢印上の注釈は、 これらの読み込みが、 どのようなタイミングでな されるかを示す。 注釈によると、 ワークメモリ 3 7上の解放は、 アプリケ一ショ ン終了と同時になされることがわかる。 一方口一カルメモリ 2 9上の解放は、 Java仮想マシン 3 8にとつて必要でなくなつた時点でなされる。この必要でなく なった時点とは、" 終了時点" ではない。" 終了した上、 再起動の可能性もない時 点"であること、つまり該当する titleが終了した時点を意味する。上述した読込- 解放のうち、 ワークメモリ 3 7における解放時点は、 アプリケーション管理テ一 ブルにおける生存区間から判明する。 しかし" アプリケーションが必要となる以 前の時点"、" 終了した上、 再起動の可能性もない時点" については、 規定し得な い。 そこで、 ォ一サリング段階において、 かかる時点をディスクコンテンツ全体 の時間軸上で規定しておくため、 本実施形態では各アプリケーションが生存して いる区間を、 アプリケーション管理テーブルとは別に、 データ管理テーブルに記 述するようにしている。 つまり" アプリケーションが必要となる以前の時点" を データ管理テーブルにおける生存区間の始点と定義し、"終了した上、再起動の可 能性もない時点" をデータ管理テ一プルの終点と定義することにより、 上述した 口一カルメモリ 2 9上の格納内容の遷移をォーサリング時に規定しておくことが できる。 これがデータ管理テーブルの記述意義である。
データ管理テーブルによる口一カルメモリ 2 9生存区間の記述について説明す る。 ここで制作しょうとするディスクコンテンツは 3 つのタイ トノレ (title#l、 title#2、 title#3)からなり、 これらタイトルの時間軸において、 図 4 1 ( b ) に示 すようなタイミングで、 ローカルメモリ 2 9を使用したいと考える。 この場合、 title#l時間軸の開始点において application#l、 application#2を構成する Java ァーカイブフアイルをローカルメモリ 2 9に読み込み、 title#l時間軸の継続中、 application#l、 application#2 をローカルメモリ 2 9に常駐させておく。 そして title#2時間軸の始点で、 application#lを構成する Javaアーカイブファイルを口 一カルメモリ 2 9から解放して、代わりに application#3を構成する Javaァ一力 イブファイルをローカルメモリ 2 9に読み込んで、 常駐させるというものである (以降、 アプリケーションを構成する Javaアーカイブファイルは、 アプリケ一シ ヨンと同義に扱う。)。 この場合のデータ管理テーブルの記述は、 図 4 1 ( a ) の 通りであり、 アプリケーションの applicationIDを、 その生存区間に対応づけて 記述することで、ローカルメモリ 2 9に常駐すべきアプリケーションを表現する。 図 4 1 ( a ) では、 application#lの applicationIDが title#lと対応づけられて 記述されており、 application#2の applicationIDは title#l、 title#2と対応づけ られ、 application#3の applicationIDは title#3と対応づけられて記述されてい ることがわかる。 こうすることで、 ローカルメモリ 2 9占有の時間的遷移がォ一 サリング担当者により規定されることになる。
データ管理テーブル、 アプリケーション管理テーブルの組合せとしては、 ァプ リケーシヨン管理テーブルに規定する生存区間は、 細かい再生単位にし、 データ 管理テーブルに規定する生存区間は、 大まかな再生単位にすることが望ましい。 大まかな再生単位には、 タイ トル、 PL といった非シームレスな再生単位が望ま しい。 一方、 細かい再生単位としては、 PL 内のチャプターというようにシーム レスな再生単位が望ましい。 アプリケーションの生存区間をタイ トル毎、 PL毎 に定めれば、 アプリケ一ションはローカルメモリ 2 9上に存在するので、 そのタ ィ トルの再生中においてアプリケーションは何時でも取り出せる状態になる。 そ うであれば、 アプリケーションの生存区間を細かく定めたとしても、 アプリケー シヨンを即座に、 仮想マシン上のワークメモリに読み出すことができるので、 ァ プリケーシヨンの起動 '終了が頻繁になされたとしても、スムーズなアプリケ一シ ョン実行を実現することができる。
次に、 読込属性について説明する。
図 2において Javaアーカイブフアイルは、 AVClipとは別の記録領域に記録さ れることを前提にしていた。 しかしこれは一例に過ぎない。 Java了一カイブファ ィルは、 BD-ROMにおいて AVClipが'占める記録領域に埋め込まれることがある。 この埋め込みの態様には、 カルーセル化、 インターリーブユニット化という 2種 類がある。
ここで" カルーセル化" とは、 対話的な放送の実現のために同一内容を繰り返 しするという放送方式に変換することである。 BD-ROM は、 放送されたデータ を格納するものではないが、 本実施形態では、 カルーセルの放送形式に倣って JAVA アーカイブファイルを格納するようにしている。 図 4 2は、 カル一セル化 による Javaアーカイブファイル埋め込みを示す図である。 第 1段目は、 AVClip 中に埋め込む Javaアーカイブファイルであり、 第 2段目は、 セクション化を示 す。 第 3段目は、 TSパケット化、 第 4段目は、 AVClipを構成する TSパケット 列を示す。 こうしてセクション化、 TSバケツト化されたデータ(図中の" D" )が、 AVClipに埋め込まれるのである。カル一セルにより AVClipに多重化された Java アーカイブファイルは、読み出すにあたって、低帯域で読み出されることになる。, この低帯域での読み出しは、 概して 2〜3分というように長期間を要するため、 再生装置は Javaアーカイブファイルを 2〜3分をかけて読み込むことになる。 図 4 3は、 ィンタ一リーブ化による Javaアーカイブファイル埋め込みを示す 図である。 第 1段目は、 埋め込まれるべき AVClip、 第 2段目は、 AVClipにイン ターリーブ化された Javaアーカイブファイル、第 3段目は、 BD-ROMの記録領 域における AVClip配置である。 本図に示すように、 ストリームに埋め込まれる べき Java アーカイブファイルは、 インターリーブ化され、 AVClip を構成する XXXXX.m2ts を構成する分割部分 (図中の AVClip2/4,3/4)の合間に記録される。 インターリーブ化により AVClipに多重化された Javaァーカイブファィルは、力 ルーセル化と比較して、 高い帯 ¾で読み出されることになる。 この高い帯域での 読み出しであるため、 再生装置は Javaアーカイブファイルを比較的短期間に読 み込むことになる。
力ルーセノレ化'インターリーブ化された Javaアーカイブファイルは、 プリロー ドされるのではない。 BD-ROMにおける AVClipの記録領域のうち、 カルーセル ィ匕 ·インターリーブ化された Javaアーカイブフアイルが埋め込まれた部分に、現 在の再生時点が到達した際、 再生装置のローカルメモリ 2 9にロードされる。 Javaアーカイブファイルの記録態様には、 図 2に示すものの他に、 図 4 2、 図 4 3 ( a ) に示すものがあるので、 読込属性は、 図 4 3 ( b ) に示すように、 設定 されうる。 図 4 3 (b ) に示すように、 読込属性は、 タイトル再生に先立ち、 口 —カルメモリ 2 9に読み込まれる旨を示す" Preload" と、 タイ トル再生中に、 カルーセル化方式で読み込まれる旨を示す" Load. Carousel" と、 タイ トル再生 中に、 インターリ一ブ化方式で読み込まれる旨を示す" LoadlnterLeave" とが ある。 読込属性には、 カルーセル化されているか、 インターリーブ化されている かが添え字で表現されているが、 これを省略してもよい。
データ管理テーブルにおける生存区間の具体的な記述例について、 図 4 4を参 照しながら説明する。 図 4 4 ( a ) は、 データ管理テーブルの一例を示す図であ る。 図 4 4 ( b ) は、 かかるデータ管理テーブルの割り当てによるローカルメモ リ 2 9の格納内容の変遷を示す図である。 本図は、 縦軸方向にローカルメモリ 2 9における占有領域を示し、横軸を、 1つのタイ トル内の PL時間軸としている。 データ管理テーブルにおいて application#lは、 1つのタイ トル内の PL時間軸全 体を生存区間とするよう記述されているので、 このタイ トルの Chaptei#l〜 Chaptei#5においてローカルメモリ 2 9内の領域を占有することになる。 データ 管理テーブルにおいて application#2は、タイトル内の PL#1における Chaptei#l 〜Chapter#2 を生存区間とするよう記述されているので、 このタイ トルの Chapter#l~Chapter#2においてローカルメモリ 2 9内の領域を占有することに なる。 データ管理テーブルにおいて application#3は、 タイ トル内の PL#1にお ける Chaptei#4〜Chapter#5を生存区間とするよう記述されているので、この夕 ィトルの Chapter#4〜Chapter#5 においてローカルメモリ 2 9内の領域を占有 することになる。 以上で、 データ管理テーブルにおける生存区間についての説明 を終える。 続いて読込優先度について説明する。 読込優先度とは、 ローカルメモリ 2 9へ の読み込みに対する優劣を決める優先度である。読込優先度には複数の値がある。 2段階の優劣を設けたい場合、 Mandatoryを示す値、 optionalを示す値を読込優 先度に設定する。 この場合、 Mandatory は高い読込優先度を意味し、 optional は、 低い読込優先度を意味する。 3段階の優劣を設けたい場合、 Mandatoryを示 す値、 optional:high、 optionaI:lowを示す値を読込優先度に設定する。 Mandatory は、 最も高い読込優先度を示し、 optional:high は、 中程度の読込優先度、 optional:lowは、 最も低い読込優先度を示す。 データ管理テーブルにおける読込 優先度の具体的な記述例について、 図 4 5 ( a ) ( b ) を参照しながら説明する。 この具体例で、 想定している口一カルメモリ 2 9のメモリ規模は、 図 4 5 ( a ) に示すようなものである。 図 4 5 ( a ) は、 新旧再生装置における口一カルメモ リ 2 9のメモリ規模を対比して示す図である。 矢印 mkl は旧再生装置における メモリ規模を、 矢印 mk2 は新再生装置におけるメモリ規模をそれぞれ示す。 こ の矢印の対比から、 新再生装置におけるローカルメモリ 2 9のメモリ規模は、 旧 再生装置のそれと比較して、 三倍以上である状態を想定している。 このようにメ モリ規模にバラツキがある場合、 アプリケーションは、 図 4 5に示すような 2つ のグループに分類される。 1つ目は、 どのようなメモリ規模であっても読み込む んでおくべきアプリケーション (#1,#2)である。 2つ目は、 旧再生装置での読み込 みは望まないが、新再生装置での読み込みは希望するアプリケーション (#3,#4)で ある。 読み込もうとするアプリケーションが、 これら 2つめグループに分類され れば、 前者に帰属するアプリケーションに、 読込優先度二 Mandatoryを設定し、 後者に属するアプリケーションに、読込優先度 ^Optionalを設定する。図 4 5 (b ) は、 読込優先度が設定されたデータ管理テーブルの一例を示す図である。 データ 管理テーブルをこのように設定した上で、 application#l〜 application#4 を BD-ROM に記録すれば、 あらゆるメモリ規模の再生装置での再生を保証しつつ も、 メモリ規模が大きい再生装置では、 より大きなサイズのデータを利用したァ プリケ一ションを再生装置に再生させることができる。
以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。 上述した記録媒体の改良に対応 するため、 アプリケーションマネージャ 3 6は図 4 6に示すような処理手順で処 理を行う。
図 4 6は、 アプリケーションマネージャ 3 6によるプリロード制御の処理手順 を示す図である。 本フローチャートは、 再生すべきタイ トルにおけるデータ管理 テーブルを読み込み (ステップ S 1 1, 1 )、 データ管理テーブルにおいて最も高い 読込優先度をもちつつ、 applicationlD が最も小さいアプリケーションをアプリ ケ一シヨン iにした上で (ステップ S 1 1 2)、 ステップ S 1 1 3、 ステップ S 1 1 4の判定を経た上で、 アプリケーション iをローカルメモリ 2 9にプリロードす る(ステップ S 1 1 5)という処理を、ステップ S 1 1 6が No及ぴステップ S 1 1 7が Noと判定されるまで、 繰り返すというループ処理を構成している。
ステップ S 1 1 3は、 アプリケーション iの読込属性がプリロードであるか否 かの判定であり、 ステップ S 1 1 4は、 アプリケーションの読込優先度が -Mandatoryであるか Optionalであるかの判定である。 ステップ S 1 1 3にお いてプリ口 ドと判定され、ステップ S 1 1 4において読込優先度が Mandatory と判定され lば、 アプリケーションはローカルメモリ 2 9にプリロードされるこ とになる(ステップ S 1 1 5)。 もしステップ S 1 1 3において読込属性が口一ド であると判定されれば、 ステップ S 1 1 4〜ステップ S 1 1 5はスキップされる ことになる。
ループ処理の終了要件を規定する 2 つのステップのうちステップ S 1 1 6は、 applicationIDが次に高く、アプリケーション iと同一読込優先度のァプリケ一シ ョン kが存在するか否かを判定するものである。 そのようなアプリケーション; k が存在するなら、そのアプリケーション kをアプリケーシ §ン丄にする(ステップ S 1 1 9)。
ループ処理の終了要件を規定する 2 つのステップのうちステップ S 1 1 7は、 データ管理テーブルにおいて次に低い読込優先度をもつアプリケーションが存在 するか否かの判定であり、 もし存在すれば、 その次に低い読込優先度をもつアブ リケ一シヨンのうち、 最も小さい applicationIDをアプリケーシヨン kを選んで (ステップ S 1 1 8)、 そのアプリケーション kをアプリケーション iにする(ステ ップ S 1 1 9)。 これらステップ S 1 1 6、 ステップ S 1 1 7が Yesになっている 限り、 上述したステップ S 1 1 3〜ステップ S 1 1 5の処理は繰り返されること になる。 ステップ S 1 1 6、 ステップ S 1 1 7において、 該当するアプリケ一シ ョンが無くなれば本フローチャートの処理は終了することになる。
ステップ S 1 2 0〜ステップ S 1 2 3は、 ステップ S 1 1 4において読込優先 度 ^Optionalであると判定された場合に、 実行される処理である。 '
ステップ S 1 2 0は、 同じ applicationIDをもち、 読込優先度が高いァプリケ ーシヨン; jが存在するか否かの判定である。
ステップ S 1 2 1は、 口一カルメモリ 2 9の残り容量がアプリケーション iの サイズを上回るか否かを判定するステップである。 ステップ S 1 2 0が No、 ス テツプ S 1 2 1が Yesである場合、 ステップ S 1 1 5においてアプリケーション iがローカルメモリ 2 9にプリロードされることになる。ステップ S 1 2 0が No、 ステップ S 1 2 1が Noである場合、 アプリケーション iは口一カルメモリ 2 9 にプリロードされずそのままステップ S 1 1 6に移行することになる。
こうしておくと、読込優先度 = Optionalのデータは、 ステップ S 1 2 0—ステ ップ S 1 2 1の判定が Yesにならないと、 ローカルメモリ 2 9へのプリロードが なされない。 メモリ規模が小さい旧再生装置は、 2〜3個のアプリケーションを読 み込んだ 度で、 ステップ S 1 2 1の判定は Noになるが、 メモリ規模が大きい 新再生装置は、 更に多くのアプリケーションを読み込んだとしても、 ステップ S 1 2 1の判定は Noにならない。 以上のように、 旧再生装置では、 口一カルメモ リ 2 9に Mandatoryのアプリケーションのみが読み込まれ、 新再生装置には、 Mandatoryのアプリケ一シヨンと、 Optionalのアプリケ一ションとが読み込ま れることになる。
ステップ S 1 2 2は、 ステップ S 1 2 0において Yesと判定された場合に実行 されるステップである。 同じ applicationlDをもち、 読込優先度が高いアプリケ ーシヨン jがローカルメモリ 2 9上に存在する場合、 ローカルメモリ 2 9の残り 容量と、,アプリケーション jのサイズとの和が、 アプリケーション iのサイズを 上回るか否かを判定し(ステップ S 1 2 2 )、 もし上回れば、 アプリケーション i を用いて口一カルメモリ 2 9上のアプリケーション ; jを上書きすることによりプ リ口一ドする(ステップ S 1 2 3 )。下回る場合は、 アプリケーション iは口一カル メモリ 2 9にプリロードされずそのままステップ S 1 1 6に移行することになる。 ステップ S 1 1 5、 ステップ S 1 2 3による読込処理の一例を、 図 4 7 ( a ) を参照しながら説明する。 図 4 7 ( a ) は、 この具体例が想定しているデータ管 理テーブルの一例を示す図である。 本図における 3つのアプリケーションは、 そ れぞれ 3 つのファイルに格納されており、 applicationlD は同じであるが (applicationID=l) 、 読 込 優 先 度 は 互 い に 異 な る (mandatory,optionai:Jiigh,optional:low)。 こつしたァータ管理テ一プ レが処理メ寸 象であると、 ステップ S 1 1 5により、読込優先度 = Mandatoryのアプリケ一シ ョンはローカルメモリ 2 9に読み込まれる。 しかし読込優先度 = Optionalのァプ リケ一シヨンについては、 ステップ S 1 2 0〜ステップ S 1 2 2の判定を経た上 で、 ステップ S 1 2 3において読み込まれる。 ステップ S 1 1 5と違いステップ S 1 2 3では、 既にローカルメモリ 2 9にある同じ applicationlDのアプリケー シヨンを上書きしてゆくよう、 プリロードがなされるので、 複数アプリケーショ ンのうち 1つが排他的に、 ローカルメモリ 2 9にロードされることになる。 i)読込優先度 ^mandatoryのアプリケーションを読み込んだ後、 読込優先度 = optional:high のアプリケーションを読み込むにあたって、 ステップ S 1 2 2が Noと判定されればれば、 読込優先度 = mandatoryのアプリケ一シヨンがロー力 ルメモリ 2 9に残ることになる。読込優先度 = mandatoryのアプリケーションを 読み込んだ後、読込優先度 =optional:highのアプリケ一ションを読み込むにあた つて、 ステップ S 1 2 2が Yesと判定されれば、読込優先度 =optional:highのァ プリケーシヨンにより、読込優先度 = mandatoryのアプリケーションは上書きさ れ、読込優先度 =optional:highのアプリケーションがローカルメモリ 2 9に残る ことになる。
ii)読込優先度 =optional:highのアプリケーションを読み込んだ後、読込優先度 =optional:lowのアプリケーションを読み込むにあたって、— ステップ S 1 2 2が Noと判定されればれば、 読込優先度 = Mandatoryのアプリケーションが口一力 ルメモリ 2 9に残ることになる。読込優先度 = optional:highのアプリケーション を読み込んだ後、 読込優先度 ^optional:lowのアプリケーションを読み込むにあ たって、 ステップ S 1 2 2が Yesと判定されれば、 読込優先度 =optional:lowの アプリケーションにより、読込優先度 =optional:highのアプリケーションは上書 きされ (ステップ S 1 2 3 )、 読込優先度 = optional:low のアプリケーションが口 一カルメモリ 2 9に残ることになる。
口一カルメモリ 2 9の容量が許す限り、 ローカルメモリ 2 9上のアプリケ一シ ョンを上書きしてゆくとの処理が繰り返されるので、 ローカルメモリ 2 9の格納 内容は、 図 4 7 ( b ) に示すように、 mandatory =optional:high=>optional:low と遷移してゆくことになる。 メモリ規模に応じて、 サイズが異なる Javaァ一力 イブファイルを口一カルメモリ 2 9に口一ドすることができるので、 メモリ規模 が小さい再生装置については、 必要最小限の解像度をもったサムネール画像を有 する Javaアーカイブファイルを、 メモリ規模が中程度の再生装置については、 中程度の解像度をもった SD画像を有する Javaアーカイブファイルを、 メモリ 規模が大規模である再生装置については、 高解像度をもった HD 画像を有する Javaアーカイブファイルをローカルメモリ 2 9に口一ドすることができる。かか るロードにより、 メモリ規模に応じて解像度が異なる画像を表示させることがで き、 ォーサリング担当者によるタイ トル制作の表現の幅が広がる。 図 4 8は、 データ管理テーブルを参照した読取処理の具体例を示す図である。 本図における 2つのアプリケーションは、 同じ applicationID(application#3)が 付与された' 2 つのアプリケーションを示す図である。 そのうち一方は、 AVClip 中に埋め ¾まれていて、 読込優先度が mandatory に設定されている。 他方は、 AVClipとは別ファィルに記録されていて、 読込優先度が Optionalに設定されて いる。 前者のアプリケーションは、 AVClip に埋め込まれているので、 その埋込 部分にあたる生存区間が、 生存区間 (title#l:chapter#4〜#5)として記述されてい る。 これらのアプリケーションのうち application#2、 application#3には、 口一 ドを示す読込属性が付与されている。 application#2 は Chapter#l〜Chapter#2 を生存区間にしており、 application#3は Chapter#4〜 Chapter^を生存区間に しているので、 タイ トル時間軸においてどちらか一方が排他的に口一カルメモリ 2 9上に常駐することになる。 図 4 8 ( b ) は、 タイ トル時間軸上の別々の時点 において、 排他的に格納される application#2、 application#3 を示す図である。 これは必要最低限のメモリ規模しかもたない再生装置での再生を念頭に置いた配 慮である。 こうした内容のデータ管理テーブルが処理対象であるとアプリケ一シ ヨンマネージャ 3 6は、 上述した図 4 6のフローチャートによりメモリ規模に応 じて異なる処理を行う。
後者のアプリケーションは、 読込優先度 ==ロードであるので、 口一カルメモリ 2 9にロードされる。 かかる処理により、 Mandatoryなメモリ規模さえあれば、 アプリケーションマネージャはデータをローカルメモリ 2 9にロードすることが できる。 ここで問題になるのは、 メモリ規模が大きい再生装置による読み込み時 である。 メモリ規模が大きいにも拘らず、 Chapter#4〜Chapter#5に到達するま で application#3を読み込めないというのは、 メモリ規模の無駄になる。 そこで 本図のデータ管理テーブルには、 同じ application#3にプリロードを示す読込属 性を付与して BD-ROMに記録しておき、 これらに同じ applicationIDを付与し ている。
前者のアプリケーションは、読込優先度 ^Optionalであるので、 ステップ S 1 2 1が Yesになった場合に限り、 プリロードされる(ステップ S 1 1 5 )。 こうす ることで、 メモリ規模が大きい再生装置は、 title#l、 Chapter#4〜Chapter#5の 到達を待つことなく、 AVClip に埋め込まれているのと同じアプリケーションを ローカルメモリ 2 9にロードすることができるのである(図 4 8 ( c ) )。
以上がプリロード時における処理である。 続いてロード時における処理手順に ついて説明する。
図 4 9は、データ管理テーブルに基づくロード処理の処理手順を示す図である。 本フローチャートは、 ステップ S 1 3 1〜ステップ S 1 3 3からなるループ処理 を、 タイ ドル再生が継続されている間、 繰り返すというものである。
ステップ S 1 3 1は、 AutoRunを示す起動属性を有したアプリケーションの生 存区間が到来したか否かの判定である。 もし到来すれば、 AutoRunを示す起動属 性を有したアプリケーションをアプリケーション qにして (ステップ S 1 3 4)、 アプリケーション qを起動する旨の 動指示を Java仮想マシン 3 8に発行して、 アプリケーション qをローカルメモリ 2 9からワークメモリ 3 7に読み出させる (ステップ S 1 3 5)。 - ステップ S 1 3 3は、 タイ トル内 PLの再生が全て終了したかの判定である。 この判定は、 第 5実施形態に示したように、 Playback Control Engine 3 2から の再生終結イベントがあつたか否かでなされる。 もし終了すれば、 本フローチヤ ートの処理を終了する。
ステップ S 1 3 2は、 起動中アプリケーションからの呼出があつたか否かの判 定である。 もしあれば、呼出先アプリケーションをアプリケーション qにして(ス テツプ S 1 3 6)、 現在の再生時点は、 アプリケーション管理テーブルにおける アプリケーション qの生存区間であるか否かを判定する(ステップ S 1 3 7)。 も し生存区間でなければ、 起動失敗を表示して (ステップ S 1 4 8)、 ステップ S 1 3 1〜ステップ S 1 3 3からなるループ処理に戻る。 生存区間であれば、 図 5 0 のフローチャートに従い、 ロード処理を行う。
図 5 0におけるステップ S 1 3 8は、 現在の再生時点がデータ管理テーブルに おけるアプリケーション qの生存区間であるか否かを示す判定である。 もし生存 区間でなければ、 アプリケーション qはローカルメモリ 2 9にロードすることが できない。 この場合、 アプリケーション qを起動する旨の起動指示を Java仮想 マシン 3 8に発行し、 ローカルメモリ 2 9を介することなく、 直接アプリケーシ ヨン qを BD -ROMからワークメモリ 3 7に読み出させる。 この場合アプリケ一 シヨンを読み出すためのへッドシークが発生するから、 PL再生は中断すること になる(ステップ S 1 4 5)。
もし生存区間であれば、 ステップ S 1 3 9において、 アプリケーションには読 込属性が付加されているか否かを判定する。 読込属性がないということは、 アブ リケーシヨン qは、 カルーセル化、 若しくはインターリーブ化されていないこと を意味する。 しかし読込属性が付加されていなくても、 口一カルメモリ 2 9にァ プリケ一シヨン qを置くことは許される。 そこで再生中断を承知の上、 アプリケ ーシヨンの読み出しを行う。 つまり BD-ROMから口一カルメモリ 2 9へとァプ リケーシヨンを読み出した上で、 アプリケーションをワークメモリ 3 7に読み出 す (ステップ S 1 4 0)。
ステップ S 1 4 1〜ステップ S 1 4 6は、 ステップ S 1 3 9が Yesと判定され た場合になされる処理である。 ステップ S 1 4 1では、 読込属性を参照すること で、 アプリケーションがプリロードされているか否かを判定する。 プリロードさ れていれば、 ステップ S 1 3 5に移行する。 —
ステップ S 1 4 2は、 読込属性がロードである場合に実行される判定ステップ であり、,アプリケーシヨン qがカルーセル化されているか、 インタ一リーブ化さ れているかを判定する。 インターリーブ化されていれば、 キャッシュセンスを Java仮想マシン 3 8に実行させる(ステップ S 1 4 3)。 ローカルメモリ 2 9にァ プリケーシヨン qが存在すれば、 ステップ S 1 3 5に移行して、 アプリケーショ ン qを Java仮想マシン 3 8に口一ドさせる。
ローカルメモリ 2 9にアプリケ一シヨンがなければ、 トップメニュータイトル に分岐する等の例外処理を行う(ステップ S 1 4 4)。 カルーセル化されていれば、 タイマをセットし (ステップ S 1 4 8)、 そのタイマがタイムァゥトするまで (ステ ップ S 1 4 7)、キャッシュセンスを Java仮想マシン 3 8に実行させる(ステップ S 1 4 6)。 もしローカルメモリ 2 9にアプリケーション qが出現すれば、 図 4 9 のステップ S 1 3 5に移行して、 アプリケーション qを Java仮想マシン 3 8に ロードさせる。 タイムアウトすれば、 トップメニュータイトルに分岐する等の例 外処理を行う(ステップ S 1 4 4)。
図 5 1は、 Java仮想マシン 3 8によるアプリケ一ションの読み込みがどのよう にして行われるかを模式化した図である。
矢印 ©I, 2 は、 アプリケーション管理テーブルに生存していて、 データ管理テ 一ブルに生存しており、力ルーセル化,インターリーブ化を示す読込属性が存在す る Javaアーカイブファイルの読み込みを示す。 矢印 ©1 は、 ステップ S 6 5、 6 7においてなされるローカルメモリ 2 9センスを示す。 このローカルメモリ 2 9センスは、 カルーセル又はインタ一リーブ化により埋め込まれたデータが、 口 一カルメモリ 2 9に存在するかもしれないため口一カルメモリ 2 9内をセンスす るというものである。矢印 ©2は、ステップ S 1 3 5に対応する読み込みであり、 アプリケーションがローカルメモリ 2 9に存在していた場合の、 ローカルメモリ 2 9からワークメモリ 3 7へのロードを示す。 X付きの矢印は、 ローカルメモリ 2 9にデータがない場合を示す。
矢印 Vl,2 は、 アプリケーション管理テーブルに生存しているが、 データ管理 テーブルに生存しておらず、 読込属性が存在しない Javaァーカイブファィルの 就み込みを示す。
矢印 VIは、 ステップ S 1 4 5における読み込みに対応するものであり、 Java 仮想マシン 3 8による BD-ROMからのダイレクトリードの要求を示す。矢印 V2 はその要求による、 BD-ROMからワークメモリ 3 7への Javaアーカイブフアイ ル読み出しを示す。
矢印 1,2,3は、アプリケーション管理テ一ブルに生存していて、データ管理テ 一ブルに生存しているが、 読込属性が存在しない Javaアーカイブファイルの読 み込みを示す。
矢印 1は、 ステップ S 1 4 0における読み込みに対応するものであり、 Java 仮想マシン 3 8による BD-ROMからのダイレクトリードの要求を示す。矢印 2 はその要求による、 口一カルメモリ 2 9への Javaアーカイブファイルの読み出 しを示す。 矢印 3 はローカルメモリ 2 9からワークメモリ 3 7への Javaァー 力イブファイルの読み出しを示す。
以上のように本実施形態によれば、 ローカルメモリ 2 9上で同時に常駐される アプリケーションの数が所定数以下になるように規定しておくことができるので、 口一カルメモリ 2 9からの読み出し時におけるキヤッシュミスを極力回避するこ とができる。 キャッシュミスのないアプリケーション読み出しを保証することが できるので、アプリケーション呼出時にあたては、 AVClipの再生を止めてまで、 BD-ROMからアプリケーションを読み出すことはなくなる。 AVClip再生を途切 れさせないので、 AVClipのシ一ムレス再生を保証することができる。
(第 7実施形態)
第 3実施形態では、 非 AV系タイトルの時間軸をアプリケーションの生存区間 に基づき定めることにした。 しかしアプリケーションの動作というのは不安定で あり、 起動の失敗や異常終了がありうる。 本実施形態は、 起動失敗、 異常終了が あった場合の Fail Safe機構を提案するものである。 図 5 2 ( a ) は、 第 7実施 形態に係る BD-Jオブジェクトの内部構成を示す図である。 図 7 ( b ) と比較し て本図が新規なのは、 プレイリスト管理テーブルが追加されている点である。 図 5.2 ( b ) は、 プレイリスト管理テーブルの一例を示す図である。 本図に示 すようにプレイリスト管理テーブルは、 PLの指定と、その PLの再生属性とから なる。 PL の指定は、 対応するタイ トルのタイ トル時間軸において、 再生可能と なる PLを示す。 PLの再生属性は、 指定された PLを、 タイトル再生の開始と同 時に自動再生するか否かを示す (こうして自動再生される PLをデフオルト PLと いう)。
次にプレイリスト管理テーブルによりタイトル時間軸がどのように規定される かを、 図 5 3を参照しながら説明する。 図 5 3 ( a ) は、 再生属性が非自動再生 を示すよう設定された場合の非 AV系タイ トルにおけるタイトル時間軸を示す図 である。 この場合、デフォルト Pl^は再生されないから、非 AV系タイ トル同様、 アプリケーションの生存区間からタイ トル時間軸が定まる。
図 5 3 ( b ) は、 再生属性が AutoPlayに設定された非 AV系タイ トルのタイ トル時間軸を示す図である。 再生属性が AutoPlay を示すよう設定されれば、 Playback Control Engine 3 2は非 AV系タイ トルの再生開始と同時に、デフオル ト PLの再生を開始する。 しかしアプリケーションが正常に動作し、 正常終了し たとしても、 このタイ トル時間軸は、 PL時間軸を基準にして定められる。
図 5 3 ( c ) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 アプリケーションが異常終了した場合を示す。 かかる異常 終了により、どのアプリケーションも動作してない状態になるが、デフォルト PL の再生は継続する。 この場合も、 デフオルト PLの PL時間軸がタイ トル時間軸 になる。
図 5 3 ( d ) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、 Playback Control Engine 3 2によるデフォルト PL再生は、アプリケーションの 起動失敗とは関係なしに行われるので、 デフォルト PLの時間軸がタイ トル時間 軸になる。'
以上のようにプレイリスト管理テ ブルの再生属性を、" AutoPlay" に設定し ておけば、 Javaアプリケーションの起動に、 5〜10秒という時間がかかったとし ても、 その起動がなされている間、" とりあえず何かが写っている状態" になる。 この" とりあえず何かが写っている状態" によりタイトル実行開始時のスタート アップディ レイを補うことができる。
以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。
図 5 2 ( c ) は、 分岐先タイ トルのプレイリスト管理テーブルにおいて、 再生 属性が AutoPlayに設定された PLが存在する場合、 再生装置がどのような処理 を行うかを示す図である。 本図に示すように、 再生属性が AutoPlayに設定され た PLが、分岐先タイ トルのプレイリスト管理テーブルに存在すれば、 BD-Jモジ ユール 3 5内のアプリケーションマネージャ 3 6は、 タイ トル分岐直後にこの AutoPlayPLの再生を開始するよう Playback Control Engine 3 2に指示する。 このように再生属性が AutoPlayの PLは、 タイ トル分岐直後に再生開始が命じ られることになる。
上述した記録媒体の改良に対応するため、 アプリケーションマネージャ 3 6は 図 5 4に示すような処理手順で処理を行う。
図 5 4は、 第 7実施形態に係るアプリケ一ションマネージャ 3 6の処理手順を 示すフローチャートである。 本フローチャートは、 図 3 8のフローチャートにお いてステップ S 2 1の前にステップ S 1 0 3、 ステップ S 1 0 4を追加し、 ステ ップ S 2 1と、 ステップ S 2 2との間にステップ S 1 0 0を追加し、 ステップ S 2 3—ステップ S 2 6間に、 ステップ S 1 0 5を追加したものである。
ステップ S 1 0 3は、 対応するタイトルのプレイリスト管理テーブルの再生属 性が AutoPlayであるか否かの判定である。 もし AutoPlayなら、 デフォルト PL に対する再生制御を Playback Control Engine 3 2に開始させる(ステップ S . I 0 ステップ S 1 0 0は、 Presentation Engine 3 1による再生中であるか否かを 判定する。 もし再生中であるなら、 ステップ S 1 0 1に移行する。
ステップ S 1 0 5は、 ステップ S 2 3が Yes、 ステップ S 2 5が Noである場 合に実行される判定ステップであり、再生属性が AutoPlayであるか否かを示す。 もし否であるなら、 タイトル終了をモジュールマネージャ 3 4に通知する。 もし AutoPlayであるなら、 ステップ S 1 Ό 1に移行して、 処理を継続する。
図 5 5は、 プレイリスト管理テーブルにおいて" 再生属性 = AutoPlay" に設定 されることにより、 どのような再生が行われるかを模式化した図である。 ここで 再生すべきタイ トルは、 落下するタイル片を積み重ねるというゲームアプリを含 む非 AV系タイトルである。 この非 AV系タイ トルにおいて、 プレイリスト管理 テ一ブルの再生属性が AutoPlayに設定されていれば、 Playback Control Engine 3 2によるデフォルト PL再生も開始する。 ゲームアプリの実行と、 デフォルト PL再生とが並列的になされるので、 図 5 5の上段の左側に示すように、 前景を ゲームアプリの画面とし、 背景をデフォルト PLの再生画像とした合成画像が表 示されることになる。 このゲームアプリは途中で異常終了したとする。 ゲームァ プリはアプリケーシヨンマネージャ 3 6により強制終了させられるが、 デフオル ト PLの再生が継続してなされるため、 タイ トルは、 何かが写っている状態にな る。このようなプレイリスト管理テーブルにおける再生属性の指定により、非 AV 系タイ トル内のゲームアプリが異常終了した場合でも、 ハングアップやブラック ァゥトがない動作を維持することができる。
(第 8実施形態)
第 1実施形態において BD-Jオブジェクトは、 データ管理テーブル、 アプリケ ーシヨン管理テーブルという 2つのテーブルを具備していたが、 本実施形態は、 これらを 1つのテ一ブルに統合するという形態を開示する。 かかる統合にあたつ て、 図 5 6 ( a ) に示すように、 データ管理テーブルにおける読込属性という項 目を廃し、 代わりに起動属性に Ready属性という属性を設ける。 Ready属性と は、 他のアプリケーションからの呼出又はアプリケーションマネージャ 3 6から の呼出に備えて、 口一カルメモリ 2 9に予めアプリケーションをロードしておく 旨を示す起動属性の類型である。
図 5 6 (b ) は、 アプリケーションの扱いと、 起動属性との関係を示した図で ある。 第 1実施形態に示したようにアプリケーションの扱いには、 プリロードさ れるか否か (1)、 現在の再生時点が有効区間に到来した際自動的に起動されるか、 他からの呼出に応じて起動されるか (2)、 タイ トル再生進行に従ってロードされる か (3)、 生存しているかという違いがあり、 これらの違いにより、 図 5 6 (b) に 示すような 5つの態様が出現する。 このうち起動属性が AutoRunに設定される のは、 プリロードがなされ、" 自動起動" である場合、 及び、 ロードがなされ、" 自動起動" である場合である。
一方、 起動属性が Ready属性に設定されるのは、 プリロード、 又は、 ロードが なされ、 起動項目が" 呼出起動" を示している場合である。
尚、 ワークメモリ 3 7では生存しているが、 口一カルメモリ 2 9にはロードさ れない" との類型が存在し得ない。 これは、 アプリケーション'データ管理テープ ルでは、 ワークメモリ 3 7の生存区間と、 ローカルメモリ 2 9の生存区間とがー 体だからである。
起動属性として、 この Ready属性を追加されたので、 アプリケーションマネー ジャ 3 6はタイトル再生に先立ち、 起動属性が AutoRun に設定されたアプリケ ーシヨン、及び、起動属性が Ready属性に設定されたアプリケーションをロー力 ルメモリ 2 9にプリロードするとの処理を行う。 こうすることにより、 読込属性 を設けなくても、 アプリケーションをローカルメモリ 2 9にプリロードしておく との処理が可能になる。
図 5 7は、 第 8実施形態に係る Java仮想マシン 3 8によるアプリケーション の読み込みがどのようにして行われるかを模式化した図である。 本図における読 み込みは、 図 5 1をベースにして作図している。
矢印 ©1,2は、 アプリケーション 'データ管理テーブルに生存していて、 起動属 性が Ready属性に設定されている Javaアーカイブフアイルの読み込みを示す。 矢印 1,2,3は、 アプリケーション'デ一夕管理テーブルに生存していおり、 起 動属性が Persistentであるアプリケーションの読み込みを示す。
これらの矢印 ©1,2、 矢印 1,2,3は、 図 5 1でも記述されていたものだが、 図 5 1に記述していた、 Vl,2 の矢印に該当する読み込み" は、 図 5 7では存在し ない。 これは、 アプリケーション 'データ管理テーブルは、 アプリケーション管理 テーブル、 データ管理テーブルを一体化したものなので、 アプリケーション管理 テ一ブル =生存、 データ管理テープル =非存在という組合せは表現し得ないから である。
以上のように本実施形態によれば、 データ管理テーブル、 アプリケーション管 理テーブルを 1つのテーブル (アプリケーシヨン'データ管理テーブル)にまとめる ことができるので、 アプリケーションマネージャ 3 6による処理を簡略化するこ とができる。尚、読込優先度をなくすことによりアプリケーシヨン'データ管理テ 一ブルをより簡略化にしても良い。
(第 9実施形態)
第 1実施形態では、 アプリケーションを口一カルメモリ 2 9に読み込むにあた つて、 読込優先度を参照して、 この読込優先度に従い、 読み込み処理に優劣を与 えた。 これに対し第 9実施形態は、 Optionalを意味する情報と、 0から 255まで の数値との組合せにより読込優先度を表す実施形態である。
図 5 8 ( a ) ( b ) は、 第 9実施形態に係る読込優先度の一例を示す図である。 255、 128 は、 0 から 255 までの読込優先度の一例であり、 本例における application?^は、 application#3より読込優先度が高いことを意味する。
本実施形態においてアプリケーションマネージャ 3 6は、 第 1実施形態同様、 先ず Mandatoryを示す読込優先度が付与されたアプリケーシヨンをローカルメ モリ 2 9に読み込む。
その後、 Optionalを示す読込優先度が付与されたアプリケーションに対しては、 ローカルメモリ 2 9における容量が、 アプリケーションのサイズを上回るか否か を判定する。 もし上回るなら、読込優先度 -Optionalが付与されたアプリケーシ ヨンをそのままローカルメモリ. 2 9に読み込む。 もし下回るなら、 アプリケーシ ョンを構成するデータのうち、 読込優先度を表す数値が高いアプリケーションを ローカルメモリ 2 9に読み込む。 そして、 口一カルメモリ 2 9における残りの領 域に、 読込優先度を表す数値が低いアプリケーションを読み出す。 こうすることで Optional扱いのアプリケーションについては、 全体を格納す る容量が再生装置のローカルメモリ 2 9になくても、 その一部分をローカルメモ リ 2 9に格納しておくことができる。
(第 1 0実施形態)
第 1実施形態においてアプリケーションマネージャ 3 6は、同じ applicationID が付与されたアプリケーションを、 読込優先度に従い排他的に口一カルメモリ 2 9にロードするとしたが、 第 1 0実施形態は、 アプリケーションにグループ属性 を与えることにより、 排他的なロードを実現する。 図 5 9は、 グループ属性が付 与されたデータ管理テーブルを示す図である。 グループ属性には、 排他グループ なし、 排他グループあり、 といった、 2通りの設定が可能であり、 排他グループ ありの場合、 そのグループ番号が記述される。 図 5 9 ( a ) における title#l の 「一」は、排他グループが存在しないことを示す。一方、 title#2,#3の「group#l」 は、 排他グループがあり、 title#2,#3'は、 group#l という排他グループに帰属し ていることを示す。 以上が本実施形態に係る記録媒体の改良である。 本実施形態に係る再生装置は、 データ管理テーブルに基づいて各アプリケーシ ョンをローカルメモリ 2 9に読み込んだ後、 ローカルメモリ 2 9のアプリケーシ ョンにおけるグループ属性.をベリフアイする。 同じ排他グループに帰属するアブ リケーシヨンが、 ローカルメモリ 2 9上に 2つ以上存在していれば、 そのうち一 方を口一カルメモリ 2 9から削除する。
こうすることにより、 ローカルメモリ 2 9の利用効率を向上させることができ る。 排他グループの具体例としては、 ランチャーアプリと、 このアプリにより起 動されるアプリとからなるグループが相応しい。 本アプリケーションにより起動 されるアプリケーションは、原則 1つに限られるので、ローカルメモリ 2 9には、 ランチャ一 + 1個のアプリケーションのみが存在する箸である。 もし 3つ以上の アプリケーションが存在していれば、 これをローカルメモリ 2 9から削除すると いう処理をアプリケーションマネージャ 3 6は行う必要があるので、 各アプリケ ーシヨンのグループ属性を設け、 ローカルメモリ 2 9上で存在するアプリケーシ ョンがランチャ一 + 1個のアプリケーションになっているかどうかのチヱックを 行うのである。
図 5 9 ( a ) は、 アプリケーション管理テーブルに基づく口一カルメモリ 2 9 に対するアクセスを示す図である。 本図において、読込優先度 = Optionalと設定 された application#2、 application#3のグループ属性は、 roup#lであるので、 これらのアプリケーションは、 同じ排他グループに属することになる。 3つのァ プリケーシヨンのうち、 application#l は上述したランチャーアプリケーション であり、 application#2、 application#3 は、 これにより起動されるアプリケーシ ヨンであるので、 どちらかのみが口一カルメモリ 2 9上に存在するよう、 グルー プ属性が付与されている。 アプリケーションマネージャ 3 6は、 これら application#2、 application#3のグル一プ属性を参照して、 どちらか 1つをロー カルメモリ 2 9から削除するとの処理を行う。 かかる削除により口一カルメモリ 2 9に余白が生まれる。
(第 1 1実施形態)
第 1実施形態では、 アプリケーション管理テーブルをタイトル毎に持たせると したが、 本実施形態では、 このアプリケーション管理テーブルの割当単位を変更 させることを提案する。 図 6 0は、 割当単位のバリエーションを示す図である。 本図において第 1段目は、 BD-ROMに記録されている 3つのアプリケーション 管理テーブルを示し、 第 2段目は、 タイ トル単位、 第 3段目は、 ディスク単位、 第 4段目は、複数 BD-ROMからなるディスクセット単位を示す。図中の矢印は、 アプリケーション管理テーブルの割り当てを模式化して示している。 この矢印を 参照すると、第 1段目におけるアプリケーション管理テーブル #1,#2,#3のそれぞ れは、第 2段目に示した title#l,#2,#3のそれぞれに割り当てられていることがわ かる。 また、 ディスク単位ではアプリケーション管理テーブル #4が割り当てられ ており、ディスクセット全体に対しはアプリケーション管理テーブル #5が割り当 てられている。 このようにアプリケーション管理テーブルの割当単位を、 タイ ト ルより大きい単位にすることにより、 1つの BD-ROMがローディングされてい る間、 生存するようなアプリケーションや複数 BD-ROMのうちどれかがローデ ィングされている間、生存するようなアプリケーシヨンを定義することができる。
(備考)
以上の説明は、 本発明の全ての実施行為の形態を示している訳ではない。 下記 (A)(B)(C)(D)……の変更を施した実施行為の形態によっても、 本発明の実施は可 能となる。 本願の請求項に係る各発明は、 以上に記載した複数の実施形態及びそ れらの変形形態を拡張した記載、 ないし、 一般化した記載としている。 拡張ない し一般化の程度は、 本発明の技術分野の、 出願当時の技術水準の特性に基づく。
(A)全ての実施形態では、本発明に係る光ディスクを BD-ROMとして実施した が、 本発明の光デイスクは、 記録される動的シナリオ、 Index Tableに特徴があ り、 この特徴は、 BD-ROM の物理的性質に依存するものではない。 動的シナリ ォ、 Index Tableを記録しうる記録媒体なら、 どのような記録媒体であってもよ い。 例えば、
DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R, CD-RW等の 光ディスク、 ; PD,MO等の光磁気ディスクであってもよい。 また、 コンパクトフ ラッシュカード、スマートメディァ、メモリスティック、マルチメディァカ一ド、 PCM-CIA カード等の半導体メモリカードであってもよい。 フレシキブルディス ク、 SuperDisk,Zip,Clik!等の磁気記録デイスク (i)、 ORB,Jaz,SparQ,SyJet,EZFley, マイクロドライブ等のリムーバルハ一ドディスクドライブ )であつてもよい。更 に、 機器内蔵型のハードディスクであってもよい。 (B) 全ての実施形態における再生装置は、 BD-ROMに記録された AVClipをデ コードした上で TVに出力していたが、再生装置を BD -ROMドライブのみとし、 これ以外の構成要素を TVに具備させてもい、 この場合、 再生装置と、 TVとを IEEE1394 で接続されたホームネットワークに組み入れることができる。 また、 実施形態における再生装置は、 テレビと接続して利用されるタイプであつたが、 ディスプレイと一体型となった再生装置であってもよい。 更に、 各実施形態の再 生装置において、 処理の本質的部分をなす部分のみを、 再生装置としてもよい。 これらの再生装置は、 何れも本願明細書に記載された発明であるから、 これらの 何れの態様であろうとも、 各実施形態に示した再生装置の内部構成を元に、 再生 装置を製造する行為は、 本願の明細書に記載された発明の実施行為になる。 各実 施形態に示した再生装置の有償'無償による譲渡 (有償の場合は販売、 無償の場合 は贈与になる)、 貸与、 輸入する行為も、 本発明の実施行為である。 店頭展示、 力 夕ログ勧誘、 パンフレッ ト配布により、 これらの譲渡や貸渡を、 一般ユーザに申 し出る行為も本再生装置の実施行為である。
(C)各フローチャートに示したプログラムによる情報処理は 、一ドウヱァ資源 を用いて具体的に実現されていることから、 上記フローチャートに処理手順を示 したプログラムは、 単体で発明として成立する。 全ての実施形態は、 再生装置に 組み込まれた態様で、 本発明に係るプログラムの実施行為についての実施形態を 示したが、 再生装置から分離して、 各実施形態に示したプログラム単体を実施し てもよい。 プログラム単体の実施行為には、 これらのプログラムを生産する行為 (1)や、 有償'無償によりプログラムを譲渡する行為 (2)、 貸与する行為 (3)、 輸入す る行為 (4)、双方向の電子通信回線を介して公衆に提供する行為 (5)、店頭展示、 力 タロダ勧誘、 パンフレッ ト配布により、 プログラムの譲渡や貸渡を、 一般ユーザ に申し出る行為 (6)がある。
(D)各フローチャートにおいて時系列に実行される各ステップの「時」の要素を、 発明を特定するための必須の事項と考える。 そうすると、 これらのフローチヤ一 トによる処理手順は、 再生方法の使用形態を開示していることがわかる。 各ステ ップの処理を、 時系列に行うことで、 本発明の本来の目的を達成し、 作用及び効 果を奏するよう、 これらのフローチャートの処理を行うのであれば、 本発明に係 る記録方法の実施行為に該当することはいうまでもない。
(E)Chapterを一覧表示するための Menu(Chapter Menu)と、 これの挙動を制 御する MOVIEォブジェクトとを BD-ROMに記録しておき、 Tbp Menuから分 岐できるようにしてもよい。またリモコンキーの Chapterキーの押下により呼出 されるようにしてもよい。
(F) BD-ROMに記録するにあたって、 AVClipを構成する各 TSバケツトには、 拡張へッダを付与しておくことが望ましい。 拡張へッダは、 TP— extra— headerと 呼はれ、 U Arribval— Time— Stamp』 と、 u copy_j>ermission_indicator』 と ¾:含み 4 バイトのデータ長を有する。 TP_extra— header付き TSバケツト(以下 EX付き TSパケットと略す)は、 32個毎にグループ化されて、 3つのセクタに書き込まれ る。 32個の ; EX付き TSパケットからなるグループは、 6144バイ ト(=32 X 192) であり、 これは 3個のセクタサイズ 6144パイ ト(=2048 X 3)と一致する。 3個の セクタに収められた 32個の EX付き TSパケットを" Aligned Unit" という。
IEEE1394を介して接続されたホームネットワークでの利用時において、 再生 装置 2 0 0は、以下のような送信処理にて Aligned Unitの送信を行う。つまり送 り手側の機器は、 Aligned Unitに含まれる 32個の EX付き TSパケットのそれ それから TP— extra— headerを取り外し、 TSバケツト本体を DTCP規格に基づき 暗号化して出力する。 TSバケツ卜の出力にあたっては、 TSバケツト間の随所に、 isochronous パケッ トを挿入する。 この挿入箇所は、 TP— extra— header の Arribval— ime— Stampに示される時刻に基づいた位置である。 TSバケツトの出 力に伴い、 再生装置 2 0 0は DTCP_Descriptorを出力する。 DTCP_Descriptor は、 TP— extra—headerにおけるコピー許否設定を示す。 ここで 「コピー禁止」 を 示すよう DTCP_Descriptorを記述しておけば、 IEEE1394を介して接続された ホームネッ トワークでの利用時において TSバケツトは、 他の機器に記録される ことはない。
(G)各実施形態において、 記録媒体に記録されるデジタルストリームは AVClip であつたが、 DVD-Video規格、 DVD-Video Recordin 規格の VOB(Video Object) であってもよい。 VOBは、 ビデオストリーム、 オーディォストリームを多重化す ることにより得られた ISO/IEC13818-1規格準拠のプログラムストリームである。 また AVClipにおけるビデオストリームは、 MPEG4や WMV方式であってもよ い。 更にオーディオストリームは、 Linear-PCM方式、 Dolby-AC3方式、 MP3 方式、 MPEG-AAC方式、 Dts、 WMA(Windows media audio)であってもよい。
(H)各実施形態における映像作品は、アナ口グ放送で放送されたアナ口グ映像信 号をエンコードすることにより得られたものでもよい。 デジタル放送で放送され たトランスポートストリームから構成されるストリームデータであってもよい。 またビデオテープに記録されているアナログ /デジタルの映像信号をェンコ一 ドしてコンテンツを得ても良い。 更にビデオ力メラから直接取り込んだアナ口グ /デジタルの映像信号をエンコードしてコンテンツを得ても良い。 他にも、 配信 サーバにより配信されるデジタル著作物でもよい。
(DBD-J モジュール 3 5は、 衛星放送受信のために機器に組み込まれた Java プラットフォームであってもよい。 BD-Jモジュール 3 5がかかる Javaプラット フォームであれば、 本発明に係る再生装置は、 MHP用 STBとしての処理を兼用 することになる。 - 更に携帯電話の処理制御のために機器に組み込まれた Javaプラットフオーム であってもよい。 かかる BD-Jモジュール 3 5がかかる Javaプラットフォーム であれば、 本発明に係る再生装置は、 携帯電話としての処理を兼用することにな る。
(K)レイァモデルにおいて、 BD-Jモードの上に MOVIEモードを配置してもよ い。 特に MOVIEモードでの動的シナリオの解釈や、 動的シナリオに基づく制御 手順の実行は、 再生装置に対する負担が軽いので、 MOVIEモードを BD-Jモー ド上で実行させても何等問題は生じないからである。 また再生装置や映画作品の 開発にあたって、 動作保証が 1つのモードで済むからである。
更に BD-Jモードだけで再生処理を実行してもよい。 第 5実施形態に示したよ うに、 BD-Jモードでも PLの再生と同期した再生制御が可能になるから、強いて MOVIEモードを設けなくてもよいという理由による。
(DAVClip に多重化されるべきインタラクティブグラフィクスストリームにナ ピゲーシヨンコマンドを設けて、 ある PLから別の PLへの分岐を実現しても良 い。
産業上の利用可能性
本発明に係る再生装置は、 ホームシアターシステムでの利用のように、 個人的な 用途で利用されることがありうる。 しかし本発明は上記実施形態に内部構成が開 示されており、 この内部構成に基づき量産することが明らかなので、 資質におい て工業上利用することができる。 このことから本発明に係る再生装置は、 産業上 の利用可能性を有する。

Claims

請求の範囲
1 . 分岐可能な複数タイ トルと、 各タイトルの再生時に実行可能なアプリケ一 シヨンとが記録された記録媒体であって、
タイトルは、 デジタルストリームと、 管理テーブルとを有しており、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
管理テーブルは、 アプリケーションと、 対応するタイ トルにおけるアプリケ一 シヨンの起動属性とを対応づけて示し、
起動属性には、 ·
分岐元タイ トルにおいてアプリケーションが非起動状態である場合、 当該分岐 先タイトルにおいてアプリケ一ションを自動的に起動させる自動起動属性がある、 ことを特徴とする記録媒体。 .
2. デジタルストリームを含むタイトルの再生と、 アプリケーションの実行と を同時に行う再生装置であって、
1つのタイトルに帰属するデジタルストリームを再生する再生制御エンジン部 と、
複数タイ トル間の分岐を制御するモジュールマネージャと、
アプリケーションを実行するモジュールとを備え、
アプリケーションには、 起動属性が前記タイ トル毎に付与されており、 モジュールは、
タイ トル間の分岐が発生した際、 分岐元タイ トルにおけるアプリケーションの 状態と、 分岐先タイトルにおけるアプリケーションの起動属性とに基づき、 分岐 先タイトルにおけるアプリケーションの状態を制御するアプリケーションマネー ジャと
を備えることを特徴とする再生装置。
3. アプリケーションに付与された起動属性が状態継続を示しており、 当該ァ プリケーシヨンが分岐元タイ トルにおいて非起動である場合、
前記アプリケーションマネージャは、 分岐先タイ トルにおいても、 当該アプリ ケ一ションを非起動にしておき、
アプリケ"シヨンに付与された起動属性が状態継続を示しており、 当該アプリ ケーションが分岐元タイ トルにおいて起動中である場合、
前記アプリケーションマネージャは、 分岐先タイ トルにおいても、 当該アプリ ケーシヨンを起動中にする
ことを特徴とする請求項 2記載の再生装置。
4. アプリケーションに付与された起動属性が自動起動を示しており、 当該ァ プリケーションが分岐元タィ トルにおいて非起動である場合、
前記アプリケーションマネージャは、 分岐先タイ トルにおいて、 当該アプリケ ーシヨンを起動し、
アプリケーションに付与された起動属性が自動起動を示しており、 当該アプリ ケーションが分岐 タィ トルにおいて起動中である場合、
前記アプリケーションマネージャは、 分岐先タイ トルにおいて、 当該アプリケ ーシヨンの状態を継続する
ことを特徴とする請求項 2記載の再生装置。
5. アプリケーションに付与された起動属性がサスペンドを示しており、 当該 アプリケーシヨンが分岐元タイ トルにおいて起動中である場合、
前記アプリケーションマネージャは、 分岐先タイ トルにおいて、 再生装置のリ ソースを当該アプリケーションに占有させるが、 再生装置の CPUパワーはァプ リケーシヨンに割り当てない状態に前記アプリケーションを遷移させる
ことを特徴とする請求項 2記載の再生装置。
6. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行と を同時にコンピュータに実行させるプログラムであって、
アプリケーションには、 起動属性が前記タイトル毎に付与されており、 プログラムは、
タイ トル間の分岐が発生した際、 分岐元タイ トルにおけるアプリケーションの 状態と、 分岐先タイトルにおけるアプリケーションの起動属性とに基づき、 分岐 先タイ トルにおけるアプリケーションの状態をコンピュータに制御させる ことを特徴とするプログラム
7. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行と を同時にコンピュータに実行させる再生方法であって、
アプリケーションには、 起動属性が前記タイ トル毎に付与されており、 再生方法は、
タイ トル間の分岐が発生した際、 分岐元タイ トルにおけるアプリケーションの 状態と、 分岐先タイトルにおけるアプリケーションの起動属性とに基づき、 分岐 先タイ トルにおけるアプリケーションの状態をコンピュータに制御させる ことを特徴とする再生方法。
PCT/JP2004/015339 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法 WO2005036555A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CN2004800296950A CN1867998B (zh) 2003-10-10 2004-10-12 记录方法、再现装置、再现方法
EP04773789A EP1677302A4 (en) 2003-10-10 2004-10-12 INFORMATION MEDIUM, REPRODUCTION DEVICE, PROGRAM, AND REPRODUCTION METHOD
US10/573,173 US7515812B2 (en) 2003-10-10 2004-10-12 Recording medium, reproduction device, program, and reproduction method
JP2005514682A JP3825463B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法。
KR1020067007232A KR101059343B1 (ko) 2003-10-10 2004-10-12 기록매체, 재생장치, 기록방법, 재생방법
US12/393,001 US8107788B2 (en) 2003-10-10 2009-02-25 Recording medium, playback device, recording method and playback method
US12/797,804 US8406604B2 (en) 2003-10-10 2010-06-10 Playback apparatus, recording method, and playback method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2003352913 2003-10-10
JP2003-352913 2003-10-10
JP2003379758 2003-11-10
JP2003-379758 2003-11-10

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US11/573,173 A-371-Of-International US20090107221A1 (en) 2004-07-02 2004-07-02 Hardness tester with indenter of hard metal or compound and oscillating crown for testing at high load and method of comparative assesment of the hardness/depth profile
US12/393,001 Division US8107788B2 (en) 2003-10-10 2009-02-25 Recording medium, playback device, recording method and playback method

Publications (1)

Publication Number Publication Date
WO2005036555A1 true WO2005036555A1 (ja) 2005-04-21

Family

ID=34436929

Family Applications (5)

Application Number Title Priority Date Filing Date
PCT/JP2004/015333 WO2005036545A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法
PCT/JP2004/015330 WO2005036554A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法
PCT/JP2004/015335 WO2005036546A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法
PCT/JP2004/015339 WO2005036555A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法
PCT/JP2004/015337 WO2005036547A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法

Family Applications Before (3)

Application Number Title Priority Date Filing Date
PCT/JP2004/015333 WO2005036545A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法
PCT/JP2004/015330 WO2005036554A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法
PCT/JP2004/015335 WO2005036546A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/015337 WO2005036547A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法

Country Status (7)

Country Link
US (10) US7715696B2 (ja)
EP (9) EP1944771A3 (ja)
JP (6) JP4117006B2 (ja)
KR (7) KR100937790B1 (ja)
CN (2) CN101840718B (ja)
TW (1) TW200518070A (ja)
WO (5) WO2005036545A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008532197A (ja) * 2005-02-28 2008-08-14 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ データ再生のためのフォールバックメカニズム
WO2006061743A3 (en) * 2004-12-06 2008-10-16 Koninkl Philips Electronics Nv Method, device, and recording medium for extending interactivity to multiple storage media
WO2009128246A1 (ja) 2008-04-16 2009-10-22 パナソニック株式会社 記録媒体、記録装置、記録方法、及び再生装置
US20090269030A1 (en) * 2004-07-30 2009-10-29 Samsung Electronics Co., Storage medium including av data and application program, and apparatus and method using the same
EP2180477A1 (en) 2004-07-22 2010-04-28 Panasonic Corporation Playback apparatus and playback method
WO2010052857A1 (ja) * 2008-11-06 2010-05-14 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
JP2011159314A (ja) 2005-02-23 2011-08-18 Thomson Licensing ソフトウエア・アプリケーションを実行するための方法および装置
EP2387037A1 (en) 2005-01-28 2011-11-16 Panasonic Corporation Reproduction device for mixing a primary audio stream with a secondary audio stream
JP2020055054A (ja) * 2018-09-28 2020-04-09 ブラザー工業株式会社 工具寿命管理装置、工作機械、表示処理方法及びコンピュータプログラム

Families Citing this family (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200518070A (en) * 2003-10-10 2005-06-01 Matsushita Electric Ind Co Ltd Recording medium, reproduction device, program, and reproduction method
US8218951B2 (en) * 2003-10-30 2012-07-10 Samsung Electronics Co., Ltd. Storage medium storing program management information, and reproducing method and apparatus
ATE389935T1 (de) * 2003-11-10 2008-04-15 Matsushita Electric Ind Co Ltd Aufzeichnungsmedium, wiedergabeeinrichtung, programm, wiedergabeverfahren und systemintegrierte schaltung
KR20050066265A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
KR20050066264A (ko) 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
JP4626799B2 (ja) * 2004-07-12 2011-02-09 ソニー株式会社 再生装置および方法、情報提供装置および方法、データ、記録媒体、並びにプログラム
CN101916579A (zh) * 2004-07-22 2010-12-15 松下电器产业株式会社 用于执行应用程序同步重放的重放装置
KR100677132B1 (ko) * 2004-09-09 2007-02-02 삼성전자주식회사 동영상 재생 및 프로그래밍 기능을 위한 멀티미디어데이터를 기록한 저장 매체, 그 재생 장치 및 재생 방법
WO2006051037A1 (en) * 2004-11-09 2006-05-18 Thomson Licensing Bonding contents on separate storage media
KR20060059572A (ko) * 2004-11-29 2006-06-02 삼성전자주식회사 플레이리스트를 자동 재생하기 위한 정보를 포함하는 저장매체, 그 재생 장치 및 재생 방법
KR20060081337A (ko) * 2005-01-07 2006-07-12 엘지전자 주식회사 비밀키를 이용한 암호화 및 복호화 방법
KR20060085154A (ko) * 2005-01-21 2006-07-26 엘지전자 주식회사 기록매체, 로컬 스토리지를 이용한 기록매체의 재생방법과재생장치
CN102081944B (zh) * 2005-02-04 2012-12-26 松下电器产业株式会社 读取装置、记录方法及读取方法
EP1783769A4 (en) * 2005-02-18 2011-11-30 Panasonic Corp CONTINUOUS REPRODUCTION DEVICE AND CONTINUOUS POWER SUPPLY DEVICE
CN101133646B (zh) * 2005-03-03 2010-05-19 皇家飞利浦电子股份有限公司 用于光盘应用的流文件系统
US20080022343A1 (en) * 2006-07-24 2008-01-24 Vvond, Inc. Multiple audio streams
US8904463B2 (en) * 2005-03-09 2014-12-02 Vudu, Inc. Live video broadcasting on distributed networks
US7698451B2 (en) * 2005-03-09 2010-04-13 Vudu, Inc. Method and apparatus for instant playback of a movie title
US20090025046A1 (en) * 2005-03-09 2009-01-22 Wond, Llc Hybrid architecture for media services
US7937379B2 (en) * 2005-03-09 2011-05-03 Vudu, Inc. Fragmentation of a file for instant access
US20090019468A1 (en) * 2005-03-09 2009-01-15 Vvond, Llc Access control of media services over an open network
US8219635B2 (en) * 2005-03-09 2012-07-10 Vudu, Inc. Continuous data feeding in a distributed environment
US9176955B2 (en) * 2005-03-09 2015-11-03 Vvond, Inc. Method and apparatus for sharing media files among network nodes
US7191215B2 (en) * 2005-03-09 2007-03-13 Marquee, Inc. Method and system for providing instantaneous media-on-demand services by transmitting contents in pieces from client machines
US8099511B1 (en) 2005-06-11 2012-01-17 Vudu, Inc. Instantaneous media-on-demand
US8799757B2 (en) * 2005-07-01 2014-08-05 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US8020084B2 (en) * 2005-07-01 2011-09-13 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US20080238938A1 (en) * 2005-08-29 2008-10-02 Eklund Don Effects for interactive graphic data in disc authoring
JP4972933B2 (ja) * 2005-12-28 2012-07-11 ソニー株式会社 データ構造、記録装置、記録方法、記録プログラム、再生装置、再生方法および再生プログラム
US20070223889A1 (en) * 2006-03-16 2007-09-27 Dandekar Shree A Embedded high definition media management module for information handling systems
JP2007328692A (ja) * 2006-06-09 2007-12-20 Canon Inc 代数演算方法及びその装置、プログラム
US8296812B1 (en) 2006-09-01 2012-10-23 Vudu, Inc. Streaming video using erasure encoding
EP1923781A1 (en) * 2006-11-14 2008-05-21 Thomson Holding Germany GmbH & Co. OHG Method and device for sequentially processing a plurality of programs
US8015548B2 (en) * 2007-03-22 2011-09-06 Arcsoft, Inc. Method for obtaining context of corresponding Xlet while playing BD-J title
JP5406044B2 (ja) * 2007-12-17 2014-02-05 パナソニック株式会社 個別販売に用いられる記録媒体、記録装置、再生装置、それらの方法
KR100943907B1 (ko) * 2008-01-10 2010-02-24 엘지전자 주식회사 데이터 재생방법 및 기록재생장치 및 디지털 방송수신장치
EP2107567A1 (en) * 2008-04-04 2009-10-07 Deutsche Thomson OHG Data carrier carrying a set of machine-interpretable instructions and media content which is presented upon execution of said machine-interpretable instructions
US8380042B2 (en) * 2008-04-16 2013-02-19 Panasonic Corporation Reproduction device, reproduction method, and program
KR101486772B1 (ko) * 2008-06-04 2015-02-04 삼성전자주식회사 재생 위치에 따라 디지털 컨텐츠를 관리하는 방법과 장치및 실행하는 방법 및 장치
JP2010009408A (ja) * 2008-06-27 2010-01-14 Sony Corp 情報処理装置、およびデータ処理方法、並びにプログラム
JP5395074B2 (ja) * 2008-07-16 2014-01-22 パナソニック株式会社 再生装置、再生方法、プログラム
US8045429B2 (en) 2008-07-29 2011-10-25 Fujitsu Ten Limited Control apparatus and method for content reproducing
US8566869B2 (en) * 2008-09-02 2013-10-22 Microsoft Corporation Pluggable interactive television
US20100088602A1 (en) * 2008-10-03 2010-04-08 Microsoft Corporation Multi-Application Control
ES2536114T3 (es) * 2008-11-06 2015-05-20 Deluxe Media Inc. Marcadores de posición en una tabla de índices para actualizar un medio de almacenamiento portátil
KR101227289B1 (ko) * 2008-12-04 2013-01-29 미쓰비시덴키 가부시키가이샤 영상 정보 재생 방법, 영상 정보 재생 장치, 기록 매체 및 영상 컨텐츠
JP5433239B2 (ja) * 2009-01-15 2014-03-05 日本放送協会 放送型アプリケーションの起動システム
KR101862351B1 (ko) * 2009-01-21 2018-05-29 삼성전자주식회사 콘텐트 정보 제공 및 재생 방법 및 장치
KR20100111996A (ko) * 2009-04-08 2010-10-18 삼성전자주식회사 가상 이미지 파일 처리 방법 및 장치
US9263085B2 (en) 2009-05-20 2016-02-16 Sony Dadc Austria Ag Method for copy protection
EP2254117B1 (en) 2009-05-20 2018-10-31 Sony DADC Austria AG Method for copy protection
EP2254120A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254119B1 (en) 2009-05-20 2019-03-13 Sony DADC Austria AG Method for copy protection
EP2254116A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
CN102422355A (zh) 2009-05-20 2012-04-18 索尼达德克奥地利股份公司 用于拷贝保护的方法
EP2254118A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254121A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
JP5215255B2 (ja) * 2009-07-10 2013-06-19 シャープ株式会社 プログラム実行装置、プログラム実行方法、コンテンツ再生装置、プログラムおよび記録媒体
WO2011007417A1 (ja) * 2009-07-14 2011-01-20 パイオニア株式会社 再生装置及び方法、並びにコンピュータプログラム
US8401370B2 (en) * 2010-03-09 2013-03-19 Dolby Laboratories Licensing Corporation Application tracks in audio/video containers
JP2011216165A (ja) 2010-04-01 2011-10-27 Alpine Electronics Inc ビデオ再生装置、コンピュータプログラム及びレジューム再生方法
US8909029B2 (en) * 2010-10-13 2014-12-09 Sony Corporation Capturing playback key events in BD players
US8648959B2 (en) 2010-11-11 2014-02-11 DigitalOptics Corporation Europe Limited Rapid auto-focus using classifier chains, MEMS and/or multiple object focusing
JP6018797B2 (ja) * 2011-05-20 2016-11-02 日本放送協会 受信機
US8355305B1 (en) * 2011-07-14 2013-01-15 Disney Enterprises, Inc. System and method for initialization of media asset modules for improved execution sequence on a playback environment
JP5857636B2 (ja) * 2011-11-02 2016-02-10 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
JP6345424B2 (ja) * 2012-04-19 2018-06-20 サターン ライセンシング エルエルシーSaturn Licensing LLC 受信装置、受信方法、送信装置、送信方法、プログラム、及びテレビジョン受像機
KR20140018743A (ko) * 2012-08-03 2014-02-13 삼성전자주식회사 디스크리스 어플리케이션 재생 장치 및 기록 장치, 재생 방법 및 기록 방법과 디스크리스 어플리케이션을 기록한 정보저장매체
CN102917246B (zh) * 2012-08-31 2015-01-14 北京视博云科技有限公司 一种基于虚拟机的应用数据提供方法、装置及系统
KR20140039504A (ko) * 2012-09-24 2014-04-02 삼성전자주식회사 블루레이 디스크 재생 장치 및 블루레이 디스크 로딩 방법
EP2908539B1 (en) * 2012-10-10 2019-12-18 Saturn Licensing LLC Reception device, reception method, transmission device, transmission method, and program
CN105103232B (zh) 2013-03-28 2017-09-22 三菱电机株式会社 再现装置、控制方法以及程序
CN104679578B (zh) * 2015-03-12 2018-09-07 绚视软件科技(上海)有限公司 BD-java平台上的最小内存自适应机制及使用方法
CN104951340B (zh) * 2015-06-12 2018-07-06 联想(北京)有限公司 一种信息处理方法及装置
WO2017056194A1 (ja) * 2015-09-29 2017-04-06 株式会社 東芝 情報機器または情報通信端末および、情報処理方法
KR102401772B1 (ko) * 2015-10-02 2022-05-25 삼성전자주식회사 전자 장치에서 어플리케이션 실행 장치 및 방법
US10204059B2 (en) * 2016-09-29 2019-02-12 International Business Machines Corporation Memory optimization by phase-dependent data residency
CN106980579B (zh) 2016-09-30 2020-08-14 阿里巴巴集团控股有限公司 一种图片加载方法及装置
US10506268B2 (en) * 2016-10-14 2019-12-10 Spotify Ab Identifying media content for simultaneous playback

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH064166A (ja) * 1992-06-24 1994-01-14 Okayama Nippon Denki Software Kk ジョブの有効期間設定装置
JPH06230946A (ja) * 1993-02-07 1994-08-19 Fuji Xerox Co Ltd 自動プログラム開始装置
JPH1063362A (ja) * 1996-08-16 1998-03-06 Nec Corp レジューム要因別に複数のプログラム状態を保持可能なサスペンドレジューム方法
JP2001238161A (ja) * 2000-02-25 2001-08-31 Sony Corp 情報付加装置、情報付加方法および記録媒体
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
JP2002369154A (ja) * 2001-04-02 2002-12-20 Matsushita Electric Ind Co Ltd ディジタル映像コンテンツの映像再生装置、映像再生方法、映像再生プログラム、パッケージメディア
JP2003249057A (ja) * 2002-02-26 2003-09-05 Toshiba Corp デジタル情報媒体を用いるエンハンスド・ナビゲーション・システム
JP2004206863A (ja) * 2002-12-09 2004-07-22 Toshiba Corp 情報再生装置及び情報再生方法

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0491104A (ja) 1990-08-06 1992-03-24 Ootex Kk 光重合反応開始剤
JPH0491078A (ja) 1990-08-06 1992-03-24 Kao Corp イミダゾール誘導体
JPH0759608B2 (ja) 1990-08-06 1995-06-28 株式会社クラレ イミド化アクリル樹脂粒子体の処理方法
JP2609749B2 (ja) 1990-08-31 1997-05-14 日本電気アイシーマイコンシステム株式会社 電流供給回路
JP2798490B2 (ja) 1990-09-03 1998-09-17 日本電気アイシーマイコンシステム株式会社 発振回路
CN100351911C (zh) * 1995-08-21 2007-11-28 松下电器产业株式会社 根据交互控制实现意外性场景展开的多媒体光盘再生装置
EP0788104B1 (en) * 1995-08-21 1999-02-24 Matsushita Electric Industrial Co., Ltd. Multimedia optical disk capable of preserving freshness of image content for long time and its reproduction apparatus and method
WO1997007511A1 (fr) * 1995-08-21 1997-02-27 Matsushita Electric Industrial Co., Ltd. Disque optique multimedia pour lequel le producteur coordonne le mode vision/ecoute, notamment une reproduction speciale a la demande, dispositif reproducteur et procede de reproduction du disque
US5915067A (en) * 1995-08-21 1999-06-22 Matsushita Electric Industiral Co., Ltd. Multimedia optical disc facilitating branch reproduction to parental lock sections using reduced control information and a reproducing device for said disc
EP0777230A1 (de) * 1995-12-04 1997-06-04 Markus Zwickl CDs enthaltend zusätzliche Textinformation
WO1997039451A1 (fr) * 1996-04-12 1997-10-23 Matsushita Electric Industrial Co., Ltd. Disque optique multimedia contenant des titres d'images de sorte qu'il soit possible de determiner instantanement si des fonctions av sont necessaires pour leur reproduction, appareil et procede pour reproduire ceux-ci
CN1260970C (zh) * 1996-05-09 2006-06-21 松下电器产业株式会社 用于多媒体光盘的记录方法、再生装置及再生方法
JP3948051B2 (ja) 1997-04-30 2007-07-25 ソニー株式会社 編集装置及びデータ編集方法
JP3655433B2 (ja) * 1997-06-20 2005-06-02 パイオニア株式会社 コンピュータ読み取り可能な記録媒体及び情報再生装置
JPH11219313A (ja) 1998-02-02 1999-08-10 Mitsubishi Electric Corp コンテンツ先読み方法
WO1999050771A1 (en) 1998-03-31 1999-10-07 International Business Machines Corporation A method and apparatus for creating an electronic commerce system
JPH11296381A (ja) * 1998-04-08 1999-10-29 Matsushita Electric Ind Co Ltd 仮想マシン及びコンパイラ
JP3262539B2 (ja) 1998-06-15 2002-03-04 株式会社ディジタル・ビジョン・ラボラトリーズ データ放送方式及び同方式に適用されるデータ受信装置
EP0989743A1 (en) * 1998-09-25 2000-03-29 CANAL+ Société Anonyme Application data table for a multiservice digital transmission system
JP2000149514A (ja) * 1998-11-10 2000-05-30 Alpine Electronics Inc ディスク再生装置
US7634787B1 (en) * 1999-06-15 2009-12-15 Wink Communications, Inc. Automatic control of broadcast and execution of interactive applications to maintain synchronous operation with broadcast programs
JP2001022625A (ja) 1999-07-09 2001-01-26 Sony Corp データ記録装置、データ記録方法、データ取得装置、データ取得方法
US6874145B1 (en) 1999-07-13 2005-03-29 Sun Microsystems, Inc. Methods and apparatus for implementing an application lifecycle design for applications
JP2003504753A (ja) 1999-07-13 2003-02-04 サン・マイクロシステムズ・インコーポレイテッド アプリケーションライフサイクルに従ってアプリケーションを管理するための方法および装置
JP3756708B2 (ja) * 1999-09-30 2006-03-15 株式会社東芝 情報処理端末装置およびそのファイル管理方法
AU770163B2 (en) 1999-10-29 2004-02-12 Opentv, Corp. System and method for recording pushed data
AU770707B2 (en) 1999-10-29 2004-02-26 Opentv, Corp. Playback of interactive programs
JP2003514335A (ja) 1999-11-10 2003-04-15 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 記録担体、記録担体を再生する装置、記録担体を再生する方法、記録担体を記録する装置及び記録担体を記録する方法
US7200857B1 (en) * 2000-06-09 2007-04-03 Scientific-Atlanta, Inc. Synchronized video-on-demand supplemental commentary
EP2546833A3 (en) 2000-04-21 2014-08-20 Sony Corporation Information processing apparatus, method and computer program
GB0016062D0 (en) 2000-06-30 2000-08-23 Koninkl Philips Electronics Nv Playback of applications with non-linear time
GB2370658A (en) 2000-12-29 2002-07-03 Metadyne Ltd A modular software framework
JP2002238161A (ja) 2001-02-14 2002-08-23 Yanmar Diesel Engine Co Ltd 分散電源用発電機の出力方法
JP2002269929A (ja) 2001-03-08 2002-09-20 Hitachi Ltd ディスク装置
KR20030007706A (ko) * 2001-04-02 2003-01-23 마츠시타 덴끼 산교 가부시키가이샤 디지털 영상 콘텐츠의 영상재생 장치, 영상재생 방법,영상재생 프로그램, 패키지 미디어
KR100771264B1 (ko) 2001-05-12 2007-10-29 엘지전자 주식회사 스크립트 파일이 포함 기록된 기록매체와, 그 재생장치 및방법
JP2003032637A (ja) 2001-07-16 2003-01-31 Sharp Corp データ放送受信装置
DE60223483T2 (de) 2001-10-29 2008-09-18 Humax Co. Ltd., Yougin Verfahren zum aufzeichenen eines digitalen Rundfunkprogramms und zeitbasierter Wiedergabe eines aufgezeichneten Rundfunkprogramms und zugehörige Vorrichtung
JP3921593B2 (ja) 2001-11-30 2007-05-30 ソニー株式会社 情報処理装置および方法、プログラム格納媒体、プログラム、並びに情報記録媒体
TW200300928A (en) * 2001-11-30 2003-06-16 Sony Corportion Information processing method and apparatus, program storage medium, program and information recording medium
US6968445B2 (en) 2001-12-20 2005-11-22 Sandbridge Technologies, Inc. Multithreaded processor with efficient processing for convergence device applications
GB0130534D0 (en) 2001-12-20 2002-02-06 Aspex Technology Ltd Improvements relating to data transfer addressing
AU2003206150A1 (en) * 2002-02-07 2003-09-02 Samsung Electronics Co., Ltd Information storage medium containing display mode information, and reproducing apparatus and method therefor
JP4532810B2 (ja) 2002-02-22 2010-08-25 キヤノン株式会社 画像処理装置、画像処理装置の制御方法、プログラム、及びコンピュータ読み取り可能な記憶媒体
JP3990928B2 (ja) 2002-03-19 2007-10-17 キヤノン株式会社 テレビジョン放送受信装置、再生方法及びプログラム
US7814025B2 (en) * 2002-05-15 2010-10-12 Navio Systems, Inc. Methods and apparatus for title protocol, authentication, and sharing
DE10228103A1 (de) 2002-06-24 2004-01-15 Bayer Cropscience Ag Fungizide Wirkstoffkombinationen
WO2004001751A1 (en) * 2002-06-24 2003-12-31 Lg Electronics Inc. Recording medium having data structure including navigation control information for managing reproduction of video data recorded thereon and recording and reproducing methods and apparatuses
BR0313688A (pt) * 2002-08-26 2005-06-21 Samsung Electronics Co Ltd Mìdia de armazenamento de informações, método de processamento de uma entrada de usuário em um modo interativo em que dados de av são reproduzidos com um documento de marcação, aparelho para reprodução de dados de av em um modo interativo, dispositivo de reprodução, e método de processamento de uma entrada de usuário em um modo interativo
CA2497697C (en) * 2002-09-12 2013-07-09 Matsushita Electric Industrial Co., Ltd. Recording medium, playback device, program, playback method, and recording method
US7715695B2 (en) * 2002-11-26 2010-05-11 Panasonic Corporation Apparatus for managing removable storage media that can be connected thereto, and method, program, and system LSI for managing removable storage media
KR101027200B1 (ko) 2003-02-21 2011-04-06 파나소닉 주식회사 기록매체, 재생장치, 기록방법 및 재생방법
KR100957799B1 (ko) 2003-03-06 2010-05-13 엘지전자 주식회사 대화형 디스크의 재생환경 설정방법
US7563748B2 (en) 2003-06-23 2009-07-21 Cognis Ip Management Gmbh Alcohol alkoxylate carriers for pesticide active ingredients
KR101014665B1 (ko) * 2003-10-06 2011-02-16 삼성전자주식회사 프리로드 정보가 기록된 정보저장매체, 그 재생장치 및재생방법
TW200518070A (en) 2003-10-10 2005-06-01 Matsushita Electric Ind Co Ltd Recording medium, reproduction device, program, and reproduction method
JP4117019B2 (ja) 2003-10-10 2008-07-09 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4091105B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4091104B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
US7467197B2 (en) * 2005-01-20 2008-12-16 International Business Machines Corporation Workflow anywhere: invocation of workflows from a remote device
JP2007265851A (ja) 2006-03-29 2007-10-11 Molex Inc ケーブル用コネクタ
JP2007265850A (ja) 2006-03-29 2007-10-11 Konica Minolta Holdings Inc 有機エレクトロルミネッセンス素子の製造方法及び製造装置
JP2007265852A (ja) 2006-03-29 2007-10-11 Matsushita Electric Ind Co Ltd 複合集電体およびその製造方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH064166A (ja) * 1992-06-24 1994-01-14 Okayama Nippon Denki Software Kk ジョブの有効期間設定装置
JPH06230946A (ja) * 1993-02-07 1994-08-19 Fuji Xerox Co Ltd 自動プログラム開始装置
JPH1063362A (ja) * 1996-08-16 1998-03-06 Nec Corp レジューム要因別に複数のプログラム状態を保持可能なサスペンドレジューム方法
JP2001238161A (ja) * 2000-02-25 2001-08-31 Sony Corp 情報付加装置、情報付加方法および記録媒体
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
JP2002369154A (ja) * 2001-04-02 2002-12-20 Matsushita Electric Ind Co Ltd ディジタル映像コンテンツの映像再生装置、映像再生方法、映像再生プログラム、パッケージメディア
JP2003249057A (ja) * 2002-02-26 2003-09-05 Toshiba Corp デジタル情報媒体を用いるエンハンスド・ナビゲーション・システム
JP2004206863A (ja) * 2002-12-09 2004-07-22 Toshiba Corp 情報再生装置及び情報再生方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1677302A4 *

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8036513B2 (en) * 2004-07-22 2011-10-11 Panasonic Corporation Playback apparatus and playback method
EP2214171A1 (en) 2004-07-22 2010-08-04 Panasonic Corporation Playback apparatus and playback method
EP2216783A1 (en) 2004-07-22 2010-08-11 Panasonic Corporation Playback apparatus and playback method
US8347099B2 (en) 2004-07-22 2013-01-01 Panasonic Corporation Playback apparatus and playback method
EP2180477A1 (en) 2004-07-22 2010-04-28 Panasonic Corporation Playback apparatus and playback method
EP2216782A1 (en) 2004-07-22 2010-08-11 Panasonic Corporation Playback apparatus and playback method
EP2214169A1 (en) 2004-07-22 2010-08-04 Panasonic Corporation Playback apparatus and playback method
EP2216781A1 (en) 2004-07-22 2010-08-11 Panasonic Corporation Playback apparatus
EP2214170A1 (en) 2004-07-22 2010-08-04 Panasonic Corporation Playback apparatus and playback method
EP2214172A1 (en) 2004-07-22 2010-08-04 Panasonic Corporation Playback apparatus and playback method
US8805162B2 (en) * 2004-07-30 2014-08-12 Samsung Electronics Co., Ltd. Storage medium including AV data and application program, and apparatus and method using the same
US20090269030A1 (en) * 2004-07-30 2009-10-29 Samsung Electronics Co., Storage medium including av data and application program, and apparatus and method using the same
US8125859B2 (en) 2004-12-06 2012-02-28 Koninklijke Philips Electronics N.V. Method and device for extending interactivity to multiple storage media
WO2006061743A3 (en) * 2004-12-06 2008-10-16 Koninkl Philips Electronics Nv Method, device, and recording medium for extending interactivity to multiple storage media
EP2387037A1 (en) 2005-01-28 2011-11-16 Panasonic Corporation Reproduction device for mixing a primary audio stream with a secondary audio stream
US9137507B2 (en) 2005-02-03 2015-09-15 Thomson Licensing Method and apparatus for executing software applications
US9509969B2 (en) 2005-02-23 2016-11-29 Thomson Licensing Method and apparatus for executing software applications
US9204117B2 (en) 2005-02-23 2015-12-01 Thomson Licensing Method and apparatus for executing software applications
JP2011159314A (ja) 2005-02-23 2011-08-18 Thomson Licensing ソフトウエア・アプリケーションを実行するための方法および装置
JP2008532197A (ja) * 2005-02-28 2008-08-14 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ データ再生のためのフォールバックメカニズム
JP2013175274A (ja) * 2005-02-28 2013-09-05 Koninklijke Philips Nv データ再生のためのフォールバックメカニズム
US8787131B2 (en) 2005-02-28 2014-07-22 Koninklijke Philips N.V. Fallback mechanism for data reproduction
WO2009128246A1 (ja) 2008-04-16 2009-10-22 パナソニック株式会社 記録媒体、記録装置、記録方法、及び再生装置
US8165458B2 (en) 2008-11-06 2012-04-24 Panasonic Corporation Playback device, playback method, playback program, and integrated circuit
JP5368470B2 (ja) * 2008-11-06 2013-12-18 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
WO2010052857A1 (ja) * 2008-11-06 2010-05-14 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
JP7119858B2 (ja) 2018-09-28 2022-08-17 ブラザー工業株式会社 工具寿命管理装置、工作機械、表示処理方法及びコンピュータプログラム
JP2020055054A (ja) * 2018-09-28 2020-04-09 ブラザー工業株式会社 工具寿命管理装置、工作機械、表示処理方法及びコンピュータプログラム

Also Published As

Publication number Publication date
EP1944771A3 (en) 2010-01-06
JP4262296B2 (ja) 2009-05-13
KR101051843B1 (ko) 2011-07-26
US20080304811A1 (en) 2008-12-11
JPWO2005036546A1 (ja) 2006-12-28
US7715696B2 (en) 2010-05-11
TW200518070A (en) 2005-06-01
EP1944772A3 (en) 2010-01-06
EP1675117A4 (en) 2010-01-06
JP4091078B2 (ja) 2008-05-28
EP1672637A1 (en) 2006-06-21
US7630615B2 (en) 2009-12-08
KR101051846B1 (ko) 2011-07-25
US7623769B2 (en) 2009-11-24
EP1675118A1 (en) 2006-06-28
EP2239737A2 (en) 2010-10-13
EP2267711A3 (en) 2013-04-17
WO2005036545A1 (ja) 2005-04-21
US8107788B2 (en) 2012-01-31
JPWO2005036555A1 (ja) 2006-12-28
KR20080043888A (ko) 2008-05-19
JPWO2005036554A1 (ja) 2006-12-28
US20080205859A1 (en) 2008-08-28
CN101840718A (zh) 2010-09-22
KR100937792B1 (ko) 2010-01-20
EP1944772A2 (en) 2008-07-16
JPWO2005036547A1 (ja) 2006-12-28
KR20070017099A (ko) 2007-02-08
JP4262250B2 (ja) 2009-05-13
JP3825463B2 (ja) 2006-09-27
CN101702320B (zh) 2011-11-23
KR20080043887A (ko) 2008-05-19
EP1675118A4 (en) 2010-01-06
US20090165024A1 (en) 2009-06-25
KR100937790B1 (ko) 2010-01-20
US8509596B2 (en) 2013-08-13
KR100937791B1 (ko) 2010-01-20
EP2267711A2 (en) 2010-12-29
WO2005036554A1 (ja) 2005-04-21
US8406604B2 (en) 2013-03-26
EP1677302A4 (en) 2007-03-14
KR101059343B1 (ko) 2011-08-24
KR20070026322A (ko) 2007-03-08
US8131130B2 (en) 2012-03-06
US7515812B2 (en) 2009-04-07
US8437625B2 (en) 2013-05-07
WO2005036547A1 (ja) 2005-04-21
US20100202278A1 (en) 2010-08-12
KR20070028290A (ko) 2007-03-12
CN101840718B (zh) 2013-01-23
EP1675117A1 (en) 2006-06-28
EP2239737A3 (en) 2010-11-17
EP1672637A4 (en) 2010-02-24
US20070274680A1 (en) 2007-11-29
EP1944771A2 (en) 2008-07-16
KR20070028289A (ko) 2007-03-12
US7702222B2 (en) 2010-04-20
KR101059290B1 (ko) 2011-08-24
US20070089146A1 (en) 2007-04-19
EP1675119A4 (en) 2010-01-06
EP1675119A1 (en) 2006-06-28
KR20090088969A (ko) 2009-08-20
JP2008287864A (ja) 2008-11-27
US20100014832A1 (en) 2010-01-21
US20100260016A1 (en) 2010-10-14
WO2005036546A1 (ja) 2005-04-21
US20070089156A1 (en) 2007-04-19
JP4182110B2 (ja) 2008-11-19
TWI352342B (ja) 2011-11-11
US20060282612A1 (en) 2006-12-14
EP1677302A1 (en) 2006-07-05
CN101702320A (zh) 2010-05-05
JPWO2005036545A1 (ja) 2006-12-28
JP4117006B2 (ja) 2008-07-09

Similar Documents

Publication Publication Date Title
JP4182110B2 (ja) 再生装置、プログラム、再生方法。
KR101076198B1 (ko) 기록매체, 재생장치, 기록방법, 재생방법
JP4012563B2 (ja) 記録媒体、再生装置、プログラム、再生方法。
JP4117019B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4091105B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4091104B2 (ja) 記録媒体、再生装置、記録方法、再生方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480029695.0

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005514682

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020067007232

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2004773789

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006282612

Country of ref document: US

Ref document number: 10573173

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2004773789

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10573173

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1020067007232

Country of ref document: KR