WO2005036545A1 - 再生装置、プログラム、再生方法 - Google Patents

再生装置、プログラム、再生方法 Download PDF

Info

Publication number
WO2005036545A1
WO2005036545A1 PCT/JP2004/015333 JP2004015333W WO2005036545A1 WO 2005036545 A1 WO2005036545 A1 WO 2005036545A1 JP 2004015333 W JP2004015333 W JP 2004015333W WO 2005036545 A1 WO2005036545 A1 WO 2005036545A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
title
read
playback
cache
Prior art date
Application number
PCT/JP2004/015333
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 JP2005514678A priority Critical patent/JP4091078B2/ja
Priority to US10/572,873 priority patent/US8131130B2/en
Priority to KR1020067007251A priority patent/KR100937790B1/ko
Priority to EP04773784A priority patent/EP1675117A4/en
Publication of WO2005036545A1 publication Critical patent/WO2005036545A1/ja
Priority to US12/110,452 priority patent/US7630615B2/en
Priority to US12/110,473 priority patent/US7623769B2/en

Links

Classifications

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

Definitions

  • the present invention is an invention belonging to the technical field of reproduction control technology that simultaneously executes reproduction of a digitized movie work and execution of an application. It is deeply concerned with applied technology when applied to consumer playback devices and programs. Background art
  • the life cycle of an application is the period from the start of the application service to the end of the service. If such a period is set in a small unit like a chapter, services by various applications can be executed alternately. However, if the live range of the application is defined in detail, the number of times the application is read from the recording medium increases. On the other hand, optical disc media for distributing movie works, such as BD-ROM and DVD, generally have a low reading speed. If the number of readings at such a slow speed increases, the reading of the video stream that constitutes the main part of the movie work is affected, and the movie playback tends to be interrupted. Although various services will be realized, simultaneous execution that hinders video playback will greatly discourage users and will be shunned by movie producers. Disclosure of the invention
  • An object of the present invention is to provide a playback apparatus that can determine a live range of an application in small units.
  • the above object has a module for executing an application, a playback control engine unit for playing back a digital stream belonging to one title, and a module manager for controlling branching between a plurality of titles, wherein the title is a tape.
  • the table includes, for each title, an application whose life cycle is the title, and the module includes a virtual machine unit, a cache, and an application manager that loads the application into the cache.
  • the section manager is achieved by a reproducing apparatus characterized in that, if there is a branch between titles, an application having the title as a live section is read into a cache.
  • the application Since the application is loaded into the cache in units of titles and the process of deleting the application from the cache is performed, the application can be read out to the virtual machine at any time in the title. Since the application can be read to the virtual machine at any time, the number of times that the application is read from the recording medium can be reduced even if the life span of the application is determined in small units such as chapters. In addition, reading from the optical disk to the cache is performed at the time of a title branch, which does not require seamless playback guarantee. I can put it.
  • the application manager reads the application whose read priority is set to Mandatory into the cache and stores the key after reading. It is desirable that the playback device be configured to read into the cache an application for which the read priority is optionally set according to the cache free space. Either the application corresponding to the memory size, which is the minimum standard, or the application corresponding to the operating environment with a larger memory size, It can be loaded into the memory of the playback device according to the memory size of the device and the read priority of each application. With such a road, it is possible to provide the soil that can guarantee the operation of the minimum standard while at the same time exerting the authoring staff's willingness to produce.
  • the plurality of applications are given different read priorities and the same identifier, and the application manager assigns the same identifier based on the size of the cache and the read priority assigned to each application.
  • One of the multiple applications may be exclusively loaded into the cache. ⁇
  • 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 Clip_Information-file-names.
  • FIG. 5 is a diagram showing a chapter definition by PLmark.
  • FIG. 6 is a diagram showing a playback section definition on the SubPlayltem time axis and synchronization designation.
  • FIG. 7A shows the internal structure of a Movie object.
  • FIG. 7B shows the internal structure of the BD-J object.
  • FIG. 7 (c) is a diagram showing the internal configuration of the Java application.
  • FIG. 8 (a) is a diagram showing programs and data stored in a Java archive file.
  • FIG. 8B shows an example of an xlet program.
  • Figure 9 (a) shows a series of titles, including the top menu, title # l, and title # 2.
  • FIG. 9 (a) shows a series of titles, including the top menu, title # l, and title # 2.
  • FIG. 9 (b) is a diagram showing a time axis obtained by adding the time axes of PlayList # 1 and PlayList # 2.
  • FIG. 10 is a diagram showing a disc content including three titles, a main title, an online shopping title, and a 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 ablation 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 illustrating 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 possible modes (Persistent, AutoRun, Suspend) of the startup attribute and three modes of the application state in the immediately preceding title (non-starting, running, Suspend).
  • FIG. 16 is a diagram showing the internal configuration of the playback device according to the present invention.
  • FIG. 17 (a) 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. 18 is a diagram in which a portion composed of software and hardware stored in the ROM 24 is replaced with a layer configuration.
  • FIG. 19 is a diagram schematically illustrating the processing performed 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. is there.
  • 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 that defines a live range on the 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 26 (b) shows the title time axis determined from the life span of the main application.
  • Figure 26 (c) is a diagram showing the title time axis determined from the life span 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 realizing a menu hierarchy.
  • FIG. 29 is a diagram schematically illustrating an Index Table and a branch from the Index Table to each Movie object.
  • FIG. 30 (a) shows the branches when the Index Table is described as shown in FIG. 29 (b).
  • FIG. 30 (b) is a diagram showing a branch when a non-AV title is forcibly terminated.
  • FIG. 31 is a flowchart showing the processing procedure of the module manager 34.
  • Figure 32 shows the application manager 36 killing the application. It is a figure showing an example of operation of end.
  • FIG. 33 is a flowchart showing a PL playback procedure by the 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 a processing procedure when the SkipBack, SkipNext API is 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. 39 is a diagram illustrating an example of the data management table.
  • FIG. 40 is a diagram showing an execution model assumed by the BD-J object.
  • FIG. 41 (a) is a diagram showing a live range indicating the existence of a Java archive file in the local memory 29.
  • FIG. 41 (b) is a diagram showing a data management table described for specifying the Java archive file live range in FIG. 41 (a).
  • Figure 42 is a diagram showing embedding of a Java archive file by carouseling.
  • FIG. 43 (a) is a diagram showing AVClip embedding by in-leaving.
  • 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 local memory 29 due to the allocation of the data management template 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 pre-control by the application manager 36.
  • FIG. 47 (a) is a diagram showing an example of a data processing table defining a plurality of applications having the same applicationID but different read priorities.
  • FIG. 47 (b) is a diagram showing the transition of the storage content of the oral memory 29 due to the assignment of the data management table of FIG.
  • 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 local memory 29 in a playback device having a small memory scale.
  • FIG. 48 (c) is a diagram showing the transition of the storage contents of the local memory 29 in a playback device having a large 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. 51 is a diagram schematically showing how an application is read by the Java virtual machine 38.
  • FIG. 52A shows 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 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.
  • 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. 6 is a diagram illustrating an ittle time axis.
  • 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 activation of the main application has failed.
  • FIG. 54 is a flowchart showing a processing procedure of the application manager 36 according to the seventh embodiment.
  • Figures 56 (a) and 56 (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. 58 (a) and 58 (b) 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 assigned.
  • 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 a partition of the allocation unit of the application management table. BEST MODE FOR CARRYING OUT THE INVENTION
  • 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 controller 400.
  • the BD-ROM 100 contains a playback device 200, a remote control 300, and a TV 400 It is used for supplying movie works to the home theater system formed by.
  • the disc content supplied to the home theater system by the BD-ROM is composed of multiple titles that can branch off from each other. Each evening consists of one or more playlists and a dynamic control procedure using these playlists. .
  • a playlist is an access unit on a BD-ROM that includes one or more digital streams and a playback path in the digital streams, and has a concept of "time axis".
  • the title combines the concept of a timeline specific to digital streams with the characteristics of a computer program, because it includes the above play list and dynamic control procedures.
  • FIG. 2 is a diagram showing a file 'directory structure in a BD-ROM.
  • the BD-ROM has a BDMV directory below the Root directory.
  • the BDMV directory contains files with the extension bdmv.
  • STREAM directory There are four subdirectories called the STREAM directory and the BDAR directory.
  • the PLAYLIST directory contains files with the extension mpls.
  • the STREAM directory contains files with the extension m2ts.
  • AVClip (O0001.m2ts, 00002.m2ts, 00003.m2ts) stores an AVClip.
  • AVClip has types such as MainCLip and SubClip.
  • MainClip is a digital stream obtained by multiplexing a plurality of elementary streams such as a video stream, an audio stream, a presentation graphics stream, and an interactive graphics stream.
  • SubClip is a digital stream that corresponds to only one elementary stream, such as an audio stream, a graphics stream, and a text subtitle 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 the AVClip, the frame rate, the bit rate, the resolution, and the like, and the EP-map indicating the start position.
  • the playlist information is information that defines a playlist with reference to the AVClip.
  • the playlist is composed of MainPath information, PLMark information, and SubPath information.
  • MainPath information is composed of multiple Playltem information.
  • Playltem is a playback section defined by specifying In-Time and Out-Time on one or more AVClip time axes.
  • a playlist (PL) consisting of multiple playback sections is defined.
  • FIG. 3 is a diagram showing the relationship between AVClip and PL. The first level shows the time axis of AVClip, and the second level shows the time axis of PL.
  • the PL information includes three pieces of Playltem information, Playltem #l, # 2, and # 3, and three playback sections are defined by the In_time and Out_time of these Playltems # 1, # 2, and # 3. .
  • a time axis different from the AVClip time axis is defined. This is the PL shown in the second row It is a time axis.
  • the definition of the Playltem information enables the definition of a time axis different from that of the AVClip.
  • AVClip is basically one, but it is also possible to specify multiple AVClips at once. This batch, designation,
  • FIG. 11 is a diagram illustrating batch designation performed by Clip_Information_file_name.
  • the first to fourth rows show four AVClip time axes (time axes of AVClips # 1, # 2, # 3, and # 4), and the fifth row shows PL time. Show the axis.
  • These four time axes are specified by four Clip-Information-file-names in Playltem information.
  • four playback sections that can be played back alternatively are defined by the In-time and Out_time of the Playltem.
  • a section composed of switchable multiple andal videos is defined on the PL time axis.
  • 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.
  • Arrows pkl, 2 in the figure indicate the Playltem designation (ref_to—Playltem—Id) in PLmark and the one-time designation (mark_time—stamp).
  • three chapters (Chapter #l, # 2, # 3) are defined on the PL time axis.
  • SubPath information is composed of a plurality of SubPlayltem information.
  • the SubPlayltem information defines a playback section by specifying In_Time and Out_Time on the time axis of the SubClip.
  • the SubPlayltem information can be specified to synchronize the playback section on the SubClip time axis with the PL time axis.
  • the PL time axis and the SubPlayltem information time axis can proceed in synchronization. become.
  • FIG. 6 is a diagram showing the definition of a playback section on the SubPlayltem time axis and the designation of synchronization. In the figure, the first row shows the PL time axis, and the second row shows the SubPlayltem time axis.
  • SubPlayltem.IN-time indicates the start point of the playback section
  • SubPlayltem.Out-time indicates the end point of the playback section. This shows that the playback section is also defined on the SubClip time axis.
  • Sync—Playltem—Id is Indicates the synchronization designation for Playltem, indicated by arrow Sn2
  • sync—start—PTS—of—Playltem indicates a point in time on Playltem on the PL time axis.
  • a dynamic scenario is scenario data that dynamically defines AVClip playback control.
  • “Dynamic” means that the contents of playback control change due to a state change in the playback device or a key event from the user.
  • the BD-ROM assumes two modes as the operating environment for this playback control. The first is an operating environment that is very similar to the operating environment of DVD playback devices, and is a command-based execution environment. The second is the operating environment of the Java virtual machine. The first of these two operating environments is called HDMV mode. The second is called BD-J mode. Since there are these two operating environments, the dynamic scenario is described assuming one of these operating environments.
  • a dynamic scenario assuming the HDMV mode is called a Movie object and is defined by management information.
  • a dynamic scenario that assumes the BD-J mode is called a BD-J object.
  • the Movie object is a component of the "Title"
  • 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 information (resume—intention_flag) that indicates whether or not playback is intended to be resumed after MenuCall when a MenuCall is made on the PL time axis.
  • the axis consists of information indicating whether MenuCall is masked (menu_call-mask) and information indicating whether title search is masked (title-search-flag).
  • a Movie object can have both properties of "time axis" + "programmatic control", and various types of titles, such as those that execute the main part playback, can be described by this Movie object. become.
  • 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 Movie objects are shown below. PlayPL command
  • the first argument is the playlist number, which can specify the PL to be played.
  • the second argument can specify the playback start position using 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 by the time information is called PlayPLatSpecified TimeO.
  • the JMP command is a branch that discards the current dynamic scenario on the way (discard) and executes the branch destination dynamic scenario as an argument.
  • the navigation command description for the Movie object is described on the DVD. It is very similar to the description method of navigation commands that can be used, so that the task of porting disc contents on a DVD to BD- ⁇ ⁇ can be performed efficiently.
  • the Movie object there is a prior art described in the following International Publication. See this International Publication for details. International Publication WO 2004/074976 This concludes the description of the Movie object.
  • the BD-J object will be described. - ⁇ BD-J object>
  • FIG. 7B 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 Movie objects is that BD-J objects do not directly describe commands.
  • the control procedure in the Movie object was directly described by the navigation command.
  • the Java application whose lifetime is the title is defined in the application management table.
  • the control procedure is indirectly defined by the control procedure, and the control procedure can be efficiently shared by 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 that are spoken in the virtual machine 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 loaded in the work memory.
  • the above is the configuration of the application.
  • the real thing of this application is the Java archive file stored in the BDAR directory under the BDMV directory.
  • Java archive files (00001.jar, 00002.jar) are archive files that store programs and data that make up Java applications.
  • FIG. 8 (a) 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;
  • the directory structure shown in the frame consists of a root directory, a java directory, and an image directory. menu.jpg is placed.
  • a java archive file can be obtained by putting them together in a java archiver.
  • Such data is expanded when it is read from the BD-ROM into 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 file indicates the application ID (applicationlD).
  • 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. 8 (b) is a diagram showing an example of an xlet program.
  • JMF A "BD7 / 00001.mpls"; is a Java temporary It is a method for commanding a virtual machine.
  • A.play is a method for instructing a JMF player instance to play. Such JMF player instance generation is 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 contents with 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 and the APK Appliation Interface supplied by the BD-ROM playback device In addition to the JumpTitle command, processing specific to the BD-ROM playback device can be described in the xlet program by calling the function API.
  • 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 branch from the title to the title in BD-J mode is specified by the JumpTitleAPI call. Since the Jump itleAPI call determines the end point of the title, so to speak, such a JMF player instance and an application having the JumpTitleAPI call will govern the start and end of the title in BD-J mode. Such an application is referred to as a main playback application.
  • the above is the description of the dynamic scenario in the BD-J mode.
  • the dynamic scenario in the BD-J mode defines a title that combines PL playback and programmatic control.
  • the programs and data constituting the application are collected in a Java archive file, but may be an LZH file or a zip file.
  • the timeline defined by the title is called the "title timeline”.
  • the title time axis is composed of a PL whose playback is ordered by a Movie object or BD-J object.
  • An example here is the title shown in Fig. 9 (a).
  • This title is a series of titles such as “Top menu 1” title # l ⁇ title # 2 ⁇ Top menu, Top menu 1 ”title # 3 ⁇ Top menu.
  • title # l is for PlayList # 1
  • title # 2 is for PlayList # 3
  • title # 4 is for PlayList # 4 as shown in Fig.
  • PlayList Add the time axis of #l and PlayList # 2, and title # l will have a time axis.
  • title # 2 has a time axis consisting of PlayList # 3 time axis
  • title # 3 has a time axis consisting of PlavList # 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.
  • the period (service period) during which the Java application can exist in the work memory of the virtual machine must be defined on such a title time axis.
  • the service period of the Java application must be defined on a 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 evening 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.
  • 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 ⁇ ⁇ ⁇ When operating on the axis, it is important to clearly define the "service start point 'end point'" where the application service starts from the time axis and where the application service ends on the time axis. become. In the present embodiment, the period from the start of the service by the application to the end of the service is defined as "survival of the application". Information for defining the survival of the application exists in the application management table in the BD-J object. The following describes the application management table in more detail.
  • the application management table is information indicating applications that can survive on the work memory of the virtual machine in the title time axis of each title. Survival in the work memory refers to the state in which the xlet program that constitutes the application 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 “start attribute” of the application.
  • FIG. 10 is a diagram showing disc contents including three titles: a main title, an online shopping title, and a game title. In the figure, the right side describes the IndexTable, and the left side describes three titles.
  • FIG. 11 is a diagram showing an example of the reproduced images of the three titles shown in FIG. In the playback images of these three titles, the main title in Fig. 11 (a) and (b) and the online shopping title have images (cart crl) imitating a shopping cart. There is no cart video in the game title of (c).
  • the application # 3 which is a cart program, is started in both title # l and title # 2.
  • Such applications that start with multiple titles include the cart app described above, an agent app that imitates a mascot appearing in a movie, and a menu app that displays a menu in response to a menu call operation. is there.
  • Fig. 12 (a) When the life span of each application is transformed 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, and the live range of each application is arranged in the vertical axis direction.
  • application # l and application # 2 belong only to title # l, so their live range remains within title # l. Since application # 4 belongs to title # 2 only, these live ranges remain within title # 2. Since application # 5 belongs to title # 3 only, these live ranges remain in title # 3. Since application # 3 belongs to title # l and title # 2, their life span extends from title # l to title # 2.
  • 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 startup attributes include "AutoRun”, which indicates automatic startup, "Persistent”, which indicates that it is not the target of automatic startup, but may be placed in the virtual machine's private memory, and is placed in the virtual machine's work memory. There is “Suspend” where CPU power cannot be allocated.
  • AutoRun is a live range indicating that the application is read into the work memory and executed at the same time as the corresponding title branch.
  • the management entity application manager
  • the management entity determines the application that is alive in that branch destination title and whose startup attribute is set to AutoRun. Read into the work memory of the virtual machine and execute. This will automatically launch the application along with the title branch.
  • Applications that set the startup attribute to AutoRun include applications that have a JMF player instance and a JumpTitle API call. Because, Such an application is an application that governs the title time axis, and unless such an application is automatically started, the concept of the title time axis becomes ambiguous.
  • the start attribute “Persistent” is a continuation attribute, and indicates that the application state at the branch source title is to be continued. It is an attribute indicating that it can be loaded into the work memory. If the launch attribute is “Persistent”, the application to which this launch attribute is assigned is allowed to be called from other applications.
  • the management entity application manager
  • the management entity that performs application management determines whether or not a call is made from a running application, the application ID of the application is described in the application management table, and the startup attribute is “Persistent”. Is determined. If "Persistent”, load the application into work memory. On the other hand, if the applicationID 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 with this “Persistent”.
  • “Persistent” is the default startup attribute given when the startup attribute is not explicitly specified, so if the startup attribute of a certain application is "11", the startup attribute of the application is activated. The attribute means that it is persistent.
  • FIG. 13 is an example of setting the startup attributes for the three applications in FIG. Of the three applications shown in FIG. 12, application # 2 is assumed to be an application that is started only when an application is called from another application, as shown in FIG. 13 (b). The remaining application # l and application # 3 are assumed to be applications that are automatically started when title # l starts.
  • the start attribute of each application in the application management table is "Application Auto" for application # l and applicauon # 3, and "Persistent" for application # 2. And set it.
  • application # l and application # 3 are automatically loaded into the work memory and executed when branching to title # l.
  • application # 2 is a persistent attribute, so the negative meaning is that application # 3 is an application that can be loaded on the work memory of the virtual machine. Therefore, application # 2 is loaded into the virtual machine's work memory and executed only after a call from application # l.
  • 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.
  • Suspend means that an application is placed in a state where resources are allocated but CPU power is not allocated. Such Suspend is useful for realizing a process of passing through a side path during the execution of a game title, for example.
  • Figures 14 (a) and 14 (b) show examples where Suspend is significant. As shown in Figure 14 (b), there are three titles (titie # l, title # 2, title # 3), of which title # l and title # 3 execute the game app, but title # 2 is a side bus that implements video playback. In a side bus, it is necessary to realize video playback, which interrupts game execution. In the game application, scores in the middle are counted, so we want to keep the stored value of the resource 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.
  • application # 2 in title # 2 has its resources allocated, so the stored values of the resources are maintained.
  • application # 2 is not executed by the virtual machine. As a result, a process of executing a side path during the execution of the game title is realized.
  • FIG. 15 is a diagram showing combinations that can be taken by three modes (Persistent, AutoRun, Suspend) that the startup attribute can take, and three modes of the application state in the immediately preceding title (non-started, running, Suspend). If the previous state is "not running” In this case, if the launch attribute is "AutoRun", the application will be launched at the branch target title.
  • the application state will be Suspend. If the immediately preceding state is "Suspend”, Suspend will be maintained if the activation attribute of the branch destination title is "Suspend”. If "Persistent” / AutoRun ", the application will resume at the branch target title.
  • the title time axis As the application progresses, it becomes possible to perform synchronous control by operating the Java application, and to send out various applications with video playback and program execution to the world. 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 reproducing apparatus 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 produced by mounting these parts on a cabinet and a board of the device.
  • the system LSr 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, read buffer 2, demultiplexer 3, video decoder 4, video plane 5, P-Graphics decoder 9, Presentation Graphics plane 10, synthesizing unit 11, and font generator.
  • I-Graphics decoder 13 Switch 14
  • Interactive Graphics plane 15 Synthesizer 16 HDD 17, Lead buffer 18, Demultiplexer 19, Audio decoder 20, Scenario memory It consists of 21, CPU 22, key event processing section 23, instruction ROM 24, switch 25, CLUT section 26, GLUT section 27, PSR set 28, and local memory 29.
  • the BD-ROM drive 1 performs loading / ejection of the BD-ROM and executes access to the BD-ROM.
  • the read buffer 2 is a FIFO memory in which TS buckets read from the BD-ROM are stored in a first-in first-out manner.
  • the demultiplexer (De-MUX) 3 extracts a TS bucket from the red buffer 2 and converts a TS packet constituting the TS packet into an ES packet.
  • the PES packet with the PID set by the CPU 22 is transferred to one of the video decoder 4, audio decoder 20, P-Graphics decoder 9, and I-Graphics decoder 13. Output.
  • the video decoder 4 decodes the plurality of PES buckets output from the demultiplexer 3 to obtain an uncompressed picture and writes the picture in the video plane 5. .
  • 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 device, 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. By decoding the graphics stream, subtitles will appear on the screen.
  • 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 1080, and each pixel of uncompressed graphics in the Presentation Graphics plane 10 is represented by an 8-bit index color.
  • CLUT Color Lookup Table
  • the combining unit 11 combines the uncompressed picture data (i) with the contents stored in the Presentation Graphics plane 10.
  • the font generator 12 expands the text code included in the textST stream into a bitmap using the character font.
  • 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 Graphics plane 1o.
  • the switch 14 selectively writes a font sequence generated by the font generator 12 or graphics obtained by decoding by the P-Graphics decoder 9 to the Presentation Graphics plane 10. It is a switch.
  • the synthesizing unit 16 synthesizes the contents stored in the Interactive Graphics plane 10 with the synthesized image (composite of the uncompressed picture data and the contents stored in the Presentation Graphics plane 7) output from the synthesizing unit 8. I do.
  • the HDD 17 is a built-in medium for storing SubClip, Clip information, and playlist information downloaded via a network or the like.
  • the playlist information in the HDD 17 is different in that it can be specified regardless of whether the clip information exists in the BD-ROM or the HDD 17.
  • the playlist information on the HDD 17 does not need to specify the file on the BD-ROM with the full path. This is because the HDD 17 is integrated with the BD-ROM and recognized by the playback device as one virtual drive (called a virtual package). Therefore, the Clip_Information_file_name in the Playltem information and the Clip_Information_file_name in the SubPlayltem information specify the five-digit numerical value corresponding to the file body of the file storing the Clip information.
  • AVClip on BD-ROM can be specified. Read the recorded contents of this HDD, and read the BD-ROM By dynamically combining this with the recorded contents of, various playback variations can be created.
  • the read buffer 18 is a FIFO memory, and stores TS packets read from the HDD 17 in a first-in first-out manner.
  • the demultiplexer (De-MUX) 19 takes out the TS packet from the read buffer 18 and converts the TS packet into a PES bucket. Then, of the PES packets obtained by the conversion, those having the desired streamPID are output to the font generator 12.
  • the audio decoder 20 decodes the PES packet output from the demultiplexer 19 and outputs uncompressed audio data.
  • the scenario memory 21 is a memory for storing the current PL information and the current Clip information.
  • the current PL information is the information currently being processed from the multiple PL information recorded on the BD-ROM.
  • the current Clip information refers to information currently being processed, such as multiple Clip information recorded on the BD-ROM.
  • the CPU 22 executes software stored in the instruction ROM 24 to control the entire playback device.
  • the key event processing section 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 command ROM 24 stores software for controlling the playback device.
  • Switch 25 selectively inputs various data read from BD-ROM and HDD 17 to any of read buffer 2, read buffer 18, scenario memory 21 and local memory 29. It is a switch to do.
  • the CLUT unit 26 converts the index colors in the uncompressed graphics stored in the video plane 5 into Y, Cr, Cb values.
  • the CLUT unit 27 converts the index colors in the uncompressed graphics stored in the Interactive Graphics plane 15 into Y, Cr, Cb values.
  • the ken 811 set 28 is a register built into the playback device, consisting of 64: Player Status Register (PSE) and 4096 General Purpose Register (GPE). Become. Of the Player Status Register settings (PSR), PSR4 to PSR8 are used to represent the current playback point.
  • PSR Player Status Register settings
  • PSR4 indicates the title to which the current playback point belongs by being set to a value from 1 to L00, and indicates that the current playback point is the top menu by being set to 0.
  • PSR5 indicates the chapter number to which the current playback point belongs by being set to a value of 1 to 999, and indicates that the chapter number is invalid in the playback device by being set to OxFFFF.
  • PSR6 when set to a value from 0 to 999, indicates the number of the PL (current PL) to which the current S raw point belongs.
  • PSR7 when set to a value from 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 time point (power Rent. PTM (Presentation TiMe)) using a time accuracy of 45 KHz.
  • the current playback point is specified.
  • FIG. 17 is a diagram showing how the 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.
  • a part of the file path in the BD-ROM is omitted and used as the file path. Therefore, by storing the file path in the header,
  • the location 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), and e).
  • Playback Control Engine ⁇ 2 which performs playback control based on playlist information and Clip information.
  • the decryption of the Movie object 'HDMV module 33 which is the execution subject' and the d-2) the decryption of the BD-J object 'BD-J module 3 and 5 are on the same level.
  • the BD-J module 35 is a so-called Java platform, which has a core configuration of a Java virtual machine 38 including a work memory 37, and has an application manager 36, an event listener manager 39, and a default operation manager. It consists of 40.
  • the Presentation Engine 31 to Module Manager 34 will be described.
  • FIG. 19 is a diagram schematically illustrating the processing by the Presentation Engine 31 to the module manager 34.
  • 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). Off), Canceling Still function (still of £>, Fast forward with speed specification (Forward Play (speed)), Rewind with speed specification (Backward Play (speed)), Audio switching (Audio Change), These are functions such as subtitle change and angle change.
  • the Presentation Engine 31 has a video decoder 4, a P-Graphics decoder 9, and a P-Graphics decoder 9, which decode the portion of the AVClip read on the read buffer 2 at the desired time. Controls I-Graphics decoder 13 and audio decoder 20. By decoding the part indicated by PSR8 (Power PTM) as a desired time, it is possible to reproduce an arbitrary point in the AVClip.
  • PSR8 Power PTM
  • the playback control engine (PCE) 32 executes various functions such as a playlist playback function (i) and a status 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, playback start and playback are performed according to the current PL information and Clip information.
  • These functions (i) to (ii) are executed in response to a function call from the HDMV module 33 to the BD-J module 35. That is, the reproduction 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 show the Playback Control Engine 32 referring to the Clip information and the playlist information.
  • the HDMV module 33 is the execution entity of the MOVIE mode, and when the module manager 34 notifies the movie object constituting the branch destination, the Movie object constituting the branch destination title is read out to the oral memory 29.
  • 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 in Fig. 19 indicate the branch target Movie object from the module manager 34 (2), decode navigation commands described in the Movie object (3), and playback. Function call (4) to 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 uses the JumpTitle command in the HDMV mode.
  • the module 33 is executed, or when the title jump API is called from the BD-J module 35, the title number of the jump destination is received, and the Movie object or the Movie object constituting the title is received.
  • the BD-J object is notified to the HDMV module 33 or the BD-J module 35.
  • Arrows marked with V0, V1, and V2 in the figure schematically show execution of the JimipTitle command (0), reference of IndexTable by module manager 3.4 (1), and notification of branch destination Movie object (2). I have.
  • FIG. 20 is a diagram showing the application manager 36.
  • the application manager 36 controls the startup of the application with reference to the application management table and controls when the title ends normally.
  • Start control means that every time a BD-J object to be branched to is notified from the module manager 34, the BD-J object is read and the application management table in the BD-J object is referred to. Perform local memory 29 access. Then, the control is to read the xlet program, which constitutes the application whose live period is the current playback point, into the work memory.
  • Reference numerals 1, 2, and 3 in FIG. 20 schematically show the notification of the branch destination BD-J object in the start control (1), the application management table reference (2), and the start instruction to the Java virtual machine 38. 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 at the time of normal end and control at the time of abnormal end.
  • 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 entity (module manager 34).
  • An arrow 6 schematically shows the notification of the module manager 34 in this end control.
  • the applications that make up the title may remain running. Because quit the application This is because whether or not to do so is determined at the branch destination title.
  • the application manager 36 reads the Java archive file from the BD-ROM to the local memory 29 (8).
  • Reference numeral 8 schematically illustrates the reading from the oral memory 29.
  • the work memory 37 is a heap area in which xlet programs constituting the application are arranged.
  • the work memory 37 originally exists in the Java virtual machine 38, but in FIG. 21, the work memory 37 is described in the upper layer of the Java virtual machine 38 for convenience of drawing.
  • the xlet program on the work memory 37 includes EventListner and a JMF player instance.
  • the Java virtual machine 38 loads the xlet program constituting the application into the work memory 37, decodes the xlet program, and executes processing according to the decoding result.
  • the xlet program includes a method for instructing the creation of a JMF player instance, and a method for instructing the execution of this JMF player instance, so the 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 is ordered, the Java virtual machine 38 obtains a JMF player instance associated with the YYYY.MPLS file on the BD-ROM.
  • this JMF method is issued to the BD middle player, and replaced with a function call supported by the BD playback device. Then, the function call after the replacement is issued to the Playback Control Engine 32.
  • Event Listner Manager 39 analyzes events (key events) generated by user operations and sorts the events. Solid arrows 1 and ⁇ > 2 in the figure schematically show the distribution by the Event Listner Manager 39.
  • Key events such as START, STOP, SPEED, etc. registered in the Event Listner in the xlet program are related to the xlet program indirectly referenced by the BD-J object. Distribute vents. 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. If the key event is a key event that is not registered in Event Listner, this key event is allocated to Default Operation Manager 40. There are various key events that occur in the BD-ROM playback device, such as audio switching and angle switching, that are not registered in the Event Listner, and even if these key events occur, perform processing without omission. That's why.
  • Event Listner unregistered events were sorted by Event Listner Manager 39 and Default Operation Manager 40, but Playback Control Engine 32 directly received Event Listner unregistered events and performed playback control. (04 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 application X) that satisfies the conditions of steps S2 to S5.
  • Step S.2 is not activated at the branch source title, but survives at the branch destination title. Then, it is determined whether or not the application X whose startup attribute in the branch destination title is the AutoRxm attribute exists. If there is, the cache sense for the local memory 29 is performed. As a result of the cache sense, if the application X is on the local memory 29 (Yes in step S7), the application X is read from the local memory 29 to the park memory 37 (step S8). If it is not in the local memory 29, the application x is read from the BD-ROM into 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 not alive in the branch destination title. If there is, the application X is deleted from the work memory 37 and the process is terminated (step S10).
  • -Step S4 is to determine whether or not there is an application of branch source SuspencU branch destination AutoRun or Persistent. If it exists, Resume Application X (step S11).
  • step S5 it is determined whether or not the application of the branch destination Suspend is running at the branch source title. If it exists, the application X is suspended (step S12).
  • FIG. 23 is a flowchart illustrating a processing procedure of the application termination processing.
  • This figure shows a loop process in which the processes from step S16 to step S20 are repeated for each of a plurality of applications to be completed (step S15).
  • the application manager 36 issues a terminate event for terminating the running application (step S16), sets a timer (step S17), and executes steps S18 to S18. Move to a loop process consisting of 20.
  • the Event Listner receives this terminate event, the corresponding xlet program starts the termination process.
  • the xlet program is released from the work memory 37, and ends.
  • step S18 is for judging whether or not the issuance application has been completed. If it has been completed, the processing for this application ends.
  • 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 the process of terminating the application.
  • the first tier in this figure shows the application manager 36, and the second tier shows three applications.
  • the application on the left 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 the termination process.
  • the application on the right indicates 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 row shows the state after the state transition when the termination process is successful. This application is terminated by its own termination process. If there are applications such as these xlet programs which do not end within a predetermined period, the application 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 in the branch source title and that is not alive in the branch destination title is automatically terminated. Even if progressing, resources in the playback device No application is launched beyond the limits of the application. Since the application operation before and after branching can be guaranteed, it is possible to distribute a lot of disk contents that execute the application while playing the digital stream. ,
  • Fig. 25 (a) is a diagram showing an application management table that defines the live sections on the PL time axis.
  • application ⁇ is specified as the live range from Chapter # 2 to Chapter # 3 of title # l, and the startup attribute AutoRxm is specified. Therefore, application # 2 is started at the start of Chapter # 2 and ends at the end of Chapter # 3, as shown in Figure 25 (b).
  • application # 3 the title # l from Chaptei # 4 to Chapter # 6 are specified as live areas. Therefore, application # 3 is started at the starting point of Chapter # 4 and ends at the ending point of Chapter # 6, as shown in Fig.25 (b), as shown in Fig.25 (b).
  • the application manager 36 Since the application manager 36 according to the present embodiment performs processing based on the application management table described in this way, every time it reaches the chapter start point specified by PLmark, the live range starts from the chapter start point. It is determined whether or not the application exists, and if so, the application is loaded into the work memory 37.
  • the application is started at the moment when normal playback by the Playback Control Engine 32 is started after entering the title.
  • the PL playback includes normal playback and trick playback.
  • Trick playback includes fast forward, rewind, SkipNext, and SkipBack.
  • the application is not started but the application is started only after the normal playback is started.
  • the moment of the normal playback start as a reference, the application startup will not be unnecessarily repeated even if there is a crossing before and after the live range as described above. It should be noted that the process of setting the instant of the normal reproduction to be the starting reference of the application may be executed even when the live range is the title.
  • the live range of the application can be defined in units of chapters, which is smaller than the PL, so that precise application control can be realized.
  • each application is assigned a priority. This priority takes a value from 0 to 255. If there is contention among resources between applications, which application is forcibly terminated, and which application deprives resources When the application manager 36 performs such a process, it becomes a judgment material.
  • the priority of application # l is 255
  • the priority of application # 2 is 128, so in the event of a conflict between application # l and application # 2, the application manager 36 Process to forcibly terminate application # 2 with low
  • the disc content provided by the BD-ROM is composed of multiple It consists of titles.
  • 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.
  • this non-AV title will be described.
  • Figure 26 (a) shows the title time axis determined from the PL time axis.
  • 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 that serves as this criterion, the title time axis should be defined as shown in Figures 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 whose startup attribute is set to AutoRun in the title and is automatically started at the start of the title.
  • this is a launcher application.
  • a launcher application is an application program that launches another application.
  • the idea in Fig. 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 title time axis determined from the life span of multiple applications. One application is started at the beginning of the title, but there are cases where this application calls another application, and this application calls another application.
  • FIG. 27 is a flowchart showing a processing procedure of the application manager 36 during title playback. In this flowchart, during title playback, step s 2 1
  • Step S23 is repeated to form a loop structure.
  • Step S21 is a determination as to whether or not the title jump API has been called. If called, a branch to the jump destination title is requested to the module manager 34 (step S27).
  • Step S22 is to determine whether or not there is a main application that is responsible for calling the application in the title, and if so, confirms whether or not it has been started (step S22). Five). If not started, it is interpreted as "end of title" and module manager 34 is notified of the end (step S26).
  • Step S23 is a step executed when there is no main application ( ⁇ in step S22), and it is determined whether or not any application has not been started. If so, it also interprets it as "end of title” and notifies module manager 34 of the end (step S26).
  • FIG. 28 (a) is a diagram showing a menu hierarchy realized by a BD-ROM.
  • the menu hierarchy in this figure has a structure in which TpMenu is placed at the top level, and from this TopMenu, lower-level TitleMenu, SubTitleMenu, and AudioMenu can be selected. Arrows swl, 2, and 3 in the figure schematically show menu switching by button selection.
  • TopMenu is for audio selection, subtitle selection, title selection It is a menu with buttons (buttons snl, sn2, sn3 in the figure) to accept which one to perform.
  • the TitleMenu is a menu with buttons that accept the selection of a movie, such as selecting the movie version of the movie (title), the director's cut version, or the game version.
  • 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 the MOVIE object for operating a menu having such a hierarchy.
  • MovieObject.bdmv stores FirstPlay OBJ, TopMenu OBJ, AudioMenu OBJ, and SubTitleMenu OBJ.
  • the FirstPlay object (FirstPlay OBJ) is a dynamic scenario that is automatically executed when a BD-ROM is dictated to a playback device.
  • TopMenu object (TopMenu OBJ) is a dynamic scenario that controls the behavior of TopMenu. It is this TopMenu object that is invoked when the user requests a menu call. TopMenu objects include those that change the state of buttons in the TopMenu in response to user operations, and branch commands that branch in response to button operations. This branching command realizes a user switching from TopMenu to TitleMenu, TopMenu to SubTitleMenu, TopMenu to AudioMenu.
  • the AudioMenu object (AudioMenu OBJ) is a dynamic scenario that controls the behavior of the AudioMenu.
  • the SubTitleMenu object (SubTitleMenu OBJ) is a dynamic scenario that controls the behavior of the SubTitleMenu.
  • a command that changes the state of the button in the SubTitleMenu in response to an operation from the user, and a subtitle setting in response to a finalization operation on the button Contains the command to update the PSR for
  • the TitleMenu object (TitleMemi OBJ) is a dynamic scenario that controls the behavior of the TitleMenu, and includes a command that changes the state of a button in the TitleMenu and a branch command that branches in response to a decision operation on the button.
  • Figure 29 is a diagram schematically showing the Index Table and the branch from the Index Table to each Movie object.
  • the left side shows the internal structure of the Index Table.
  • the Index Table in the present embodiment includes-FirstPLaylNDEX, IpMenuINDEX, Audio MenuINDEX, Subtitle Me dish INDEX, title MenuINDEX, title # l to #mINDEX, title # m + l to #nINDEX, and title # 0INDEX.
  • Arrows bcl, 2 in the figure schematically show the branch from Index Table to FirstPlayOBJ and the branch from FirstPlayOBJ to TopMenu
  • arrows bc3, 4, and 5 show the branches from TopMenu to TitleMenu, SubTitleMenu, and AudioMenu. This is schematically shown.
  • Arrows bc6, 7, and 8 schematically show branches from TitleMenu to Movie objects.
  • FirstPLaylNDEX, TopMenuINDEX, Audio MenuINDEX, Subtitle MenuINDEX, title MenuINDEX are indexes for FirstPLayOBJ, TopMenuOBJ, Audio MenuOBJ, Subtitle MenuOBJ, title MenuOBJ, respectively, and these identifiers are described.
  • title # l to #mINDEX are the indexes of the titles entered from the 1st to the mth in the BD-ROM, and the identifiers of the MOVIE objects to be branched to when the title numbers from 1 to m are selected. ID) is described.
  • title # m + l ⁇ # nINDEX is an index for the titie that is the nth entry from the m + 1 on the BD-ROM.When the title number from m + 1 to n is selected, The identifier (ID) of the new BD-J object is described.
  • title # 0INDEX is an INDEX that specifies the Movie object or BD-J object to be branched to when the BD-J object is forcibly terminated. Book In the embodiment, the identifier for TopMemiOBJ is stored in title # 0INDEX.
  • FIG. 30 (a) shows the 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 to title # m as the branch destination, the identifiers of the Movie objects #l to #m are obtained from title # llndex to title # mlndex. Taken out. When executing the branch command with the label title # m + l to title # n as a branch, the identifier of the BD-J object # m + l to #n is extracted from title # m + llndex to title # nlndex.
  • BD-J objects # m + l to #n are five-digit numbers that represent file names, "00001.BD-J, 00002.BD-J, 00003.BD-J" It will be fetched and the dynamic scenario with that file name will be read into memory and executed. This is the branching process using the Index Table.
  • FIG. 30 (b) is a diagram showing a branch at the time of forced termination when executing a BD-J object.
  • the identifier is extracted from title # 01ndex, and the playback device executes the dynamic scenario with that identifier. If this identifier is the identifier of the top menu title, the top menu OBJ will be automatically selected when the application is forcibly terminated.
  • the above is an improvement on the recording medium in the present embodiment.
  • improvements to the playback device according to the present embodiment will be described.
  • the module manager 34 in the playback device performs processing according to the processing procedure shown in FIG.
  • FIG. 31 is a flowchart showing the processing procedure of the module manager 34. This flowchart constitutes a loop process consisting of step S31 and step S32, and when either step S31 or step S32 becomes Yes, the corresponding process is executed. is there.
  • Step S31 is to determine whether or not the title jump API has been called. If there is a call to the title jump API, a title number] ′ that is a branch destination label is obtained (step S33), and IDj is extracted from the index of the title number j in the Index Table (step S3). 4), IDj Movie Objek Or the BD-J object is executed by the HDMV module 33 or the BD-J module 35 (step S35).
  • Step S32 is for determining whether or not the end of the title is notified from the application manager 36. If notified (Yes in step S32), the top menu constituting the top menu title The OBJ is executed by the HDMV module 33 or the module manager 34 (step S36).
  • the title to be played here is a non-AV title that includes a game application that stacks 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 in the life cycle of this game app, as shown in the upper left of Fig. 32.
  • 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 module manager 34 branches to the top menu title. Then, an image as shown on the upper right side of FIG. 32 is displayed, and the operation waits for the user.
  • it is possible to control to branch to the top menu title even at the end of a non-AV title that includes a program but does not include a digital stream. As a result, even if the application program terminates with an error, it is possible to avoid occurrence of blackout / hangup.
  • BD-J mode it relates to the improvement of how to achieve synchronization with PL playback.
  • the Java virtual machine 38 decodes the JMF player instance (A.play;) that instructs playback of the JMF player instance, the Java virtual machine 38 calls the PL playback API. And right after the call Access to the application.
  • 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 process described above will continue during those 2 hours. The problem here is how long the Java virtual machine 38 returns a success response and how long the Playback Control Engine
  • 3 2 is the gap with the time to actually finish 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, but since the actual processing by the Playback Control Engine 32 ends after 2 hours, However, if the time to return a success response to the application is used as a reference, the end of the process after 2 hours cannot be detected. When fast forward, rewind, and skip are performed in PL playback, the playback time of 2 hours fluctuates around 2 hours, and it becomes more difficult to detect the end of processing.
  • Playback Control Engine 3 2 operate with the Abu 1] Ke one Chillon and stand-alone, the termination judgment as in the third embodiment, it is impossible to interpret the end of PL playback tie bets Le ends. Therefore, in this embodiment, whether or not the application is terminated, as long as the JMF player instance exists in the private memory 37, that is, the control right of the Presentation Engine 31 is controlled by the BD_J module 35. While waiting for a playback end event from Playback Control Engine 32. If there is a playback end event, it interprets that the title has ended, and notifies the module manager 34 to branch to the next title. By doing so, the point at which Playback Control Engine 32 ends PL playback can be used as the end of the title.
  • FIG. 33 is a flowchart showing a PL playback procedure by the Playback Control Engine 32.
  • This playback procedure includes control of the Presentation Engine 31 (step S46) and control of the BD-ROM drive 1 or HDD 17 (step S46).
  • the Playltem to be processed in this flowchart is Playltem # x.
  • This flowchart reads the current PL information (.mpls) (Step S41), and thereafter, the processing of steps S42 to S50 is executed.
  • Steps S42 to S50 repeat the processing of Steps S43 to S50 for each PI information constituting the current PL information until Step S49 becomes Yes.
  • the Playltem to be processed in this loop processing is called PlayItem # x (PI # x). This Playltenrffx is initialized by being set to the first Playltem of the current PL (step S42).
  • this Playltem # x becomes the last Playltem of the current PL (step S49), and if it is not the last Playltem, the next Playltem in the current PL is It is set to Playltem # x (step S50).
  • Steps S43 to S50 which are repeatedly executed in the loop processing, read the Clip information specified by the Clip_information_file__name of Playltem # x into the scenario memory 21 (step S43), and the In-time of Playltem # x Is converted to I-picture address u using the EPmap of the current Clip information (step S44), and Out-time of Playltem # x is converted to I-picture address V using the EP_map of the current Clip information. (Step S45), find the next I-picture of the address V obtained by these conversions, set the address immediately before that address to the address w (Step S47), and calculate in this way. Using the address w, the reading of the TS packet from the I picture address u to the address w is instructed to the BD-ROM drive 1 or the HDD 17 (step S48).
  • the presentation engine 31 is instructed to output from mark_time_stamp of the current PLMark to Out-time of Playltem # x (step S46).
  • 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 (step S49).
  • Playltem # x is current: If not the last PI of the PL, the next Playltem in the current PL is set to Playltem # (step S50), and the process returns to step S43. By repeating the above steps S43 to S50, PL Are reproduced sequentially.
  • FIG. 34 is a flowchart showing an angle switching procedure and SkipBack, SkipNext procedures. This flowchart is performed in parallel with the processing procedure of FIG. 33, and repeats the loop processing consisting of 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—multi_angles is a flag indicating whether Playltem # x supports multi-angles. 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 into a variable y (step S56), and the y-th Clip—information—file—name in Playitem # x is specified.
  • the Clip information is read out to the scenario memory 21 (step S57), the current PTM is converted to an I picture address u using the EP_map of the current Clip information (step S58), and the Out_time of Playltem # x is set to the current It is converted to an I picture address v using the EP-map of the Clip information (step S59).
  • the flow shifts 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 or not an API meaning SkipBack / SkipNext has been called from the Java virtual machine 38.
  • the processing procedure of the flowchart is executed.
  • FIG. 35 is a flowchart showing a processing procedure when the SkipBack, SkipNext API is called.
  • the processing procedures for executing SkipBack and SkipNext are various. It is to be noted that the description here is only an example.
  • Step S.61 1 is to determine the power PI number indicated by the PSR and the current PTM To obtain the current Mark information.
  • 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 pressed.
  • step S64 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 it is the SkipNext key, the direction flag is set to +1 and the power mark PLMark will be incremented. If it is a SkipBack key, the direction flag is set to -1, so the current PLMark will be decremented.
  • step S66 the PI described in the ref—to—Playltem_ld of the current PLMark is set to Hayltem # x.
  • step S67 the Clip—information of Playltem # x; Read information.
  • step S68 the mark-time-stamp of the current PLMark is converted to an I-picture address u using the EP-map of the current Clip information.
  • step S69 Out-time of Playltem # x is converted to I-picture address V using EP_map of current Clip information.
  • step S70 the output up to the mark-time-stamp of the current PLMark or the Out-time of Playltem # x 3 ⁇ 4: After instructing the Presentation Engine 31, the process proceeds to step S47 in FIG.
  • the I-picture addresses u and v are changed, and the reproduction of another part is ordered, and then the process proceeds to step S47.Therefore, the TS bucket is read from another AVClip, and the video contents are read. Switching 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 termination requirements of the loop processing. That is, step S76 makes the loop processing end requirement that the current PTM is the Out_time of PI # x.
  • step S73 it is determined whether or not the fast forward API or the fast reverse API has been called from the Java virtual machine 38. If called, 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). By setting the current PTM to the PTS of the next I picture in this way, the AVClip can be played every second. As a result, the AVClip is reproduced in the forward direction at a double speed or the like. If it is a quick reverse, it is determined whether the current ⁇ has reached the Out-time of Playltem # x (step S80). If not reached, the PTS of the immediately preceding I picture is set to the current PTM (step S81).
  • the AVClip By setting the read destination address A to the previous I picture in this way, the AVClip can be played back one second at a time in the backward direction. As a result, the AVClip is reproduced in the reverse direction at a double speed or the like.
  • the processing procedures for executing fast-forward and rewind are various. Please note that this is only an example.
  • 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). With 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 Hayltem # x exists according to sync-Playltem_id. If so, the flow shifts to the flowchart of FIG. FIG. 37 is a flowchart showing the playback procedure of SubPlayltein.
  • 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 a playback process based on SubPlayItem # y.
  • Steps S87 to S92 in Fig. 37 are performed based on SubPlayItem # y. It is a flowchart which shows a process.
  • step S87 the Clip information specified by Clip—information—file—name of SubPlayItem # y is read.
  • step S88 the In_time of SubPlayItem # is converted to an address ⁇ using the EP-map of the current Clip information.
  • step S89 the Out-time of SubPlayItem # y is converted to an 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.
  • the I-picture next to address 0 obtained by these conversions is obtained, and one before that address is set to address y (step S91), and the SubClip is calculated using the address y calculated in this way. This is to instruct the BD-ROM drive 1 or the HDD 17 to read the TS packet from the address ⁇ to the address in #z (step S92).
  • 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 in FIG. become. Only after the processing of the flowchart in FIG. 36 is completed, step S53 becomes Yes and the process proceeds to step S54.
  • Step S54 is the output of the reproduction end event to the Java virtual machine 38, which allows the Java virtual machine 38 to know the lapse of the reproduction time of 2 hours.
  • FIG. 38 is a flowchart showing a processing procedure of the application manager 36 according to the fifth embodiment.
  • the flowchart of FIG. 38 is an improvement of the flowchart of FIG. The improvement is that step S 24 is added between step S 21 1 and step S 22, and when step S 24 becomes Yes, there is a step S 101 executed. It is.
  • step S24 the JMF player instance is stored in the work memory 37. This is a determination as to whether or not there is any data. 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 so, the Java player instance in the work memory is deleted, and then (Step In step S102, the end of the title is notified to the module manager 34 (step S26). If not notified, the loop processing consisting of steps S21 to S24 is repeated.
  • the ablation manager 36 can know the point of time when the playback time of 2 hours has elapsed, a menu is displayed in the end condition of the PL playback, and the menu is displayed. Control to branch to another title in accordance with the operation can be realized.
  • the sixth embodiment relates to an improvement of providing a data management table 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.
  • "Survival in oral memory 29" means that the Java archive file that constitutes the application is read from local memory 29 and can be transferred to work memory 37 in Java virtual machine 38.
  • 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, and the data management table has the same concept of a live range.
  • Application At first glance, it seems wasteful to have the same concept as the Yon 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 consists of a BD-ROM, a local memory 29, and a Java virtual machine 38, and shows the relationship between the BD-ROM, the oral memory 29, and the work memory 37.
  • Arrow myl indicates reading between BD-ROM and local memory 29, and arrow my2 indicates reading between oral memory 29 and work memory 37.
  • the annotations on the arrows indicate when these readings occur. According to the annotation, reading between the BD-ROM and the local memory 29 is so-called "look-ahead" and must be performed before the application is needed.
  • reading from the local memory 29 to the work memory 37 is performed when the application becomes necessary.
  • “When needed” means the point in time when the life span of the application has arrived (1), and the point in time when an application call is instructed by another application or the application manager 36 (2).
  • Arrow my3 indicates release of the application occupied area in work memory 37
  • arrow my4 indicates release of the application occupied area in local memory 29.
  • the annotations on the arrows indicate when these readings are made.
  • 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 needed for the Java virtual machine 38. This point when it is no longer needed is not an "end point.” It means “at the end when there is no possibility of restart", that is, when the corresponding title ends.
  • the release point in the work memory 37 is determined 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 title # 2
  • the time axis of these titles at the timing shown in Fig. 41 (b), You want to use local memory 29.
  • the Java archive files that make up the application # l and application # 2 are read into the local memory 29, and the title # l time axis continues, application # l and application # 2 In the oral memory 29.
  • the Java archive files that make up application # l are released from local memory 29, and the Java archive files that make up application ⁇ are read into oral memory 29 instead.
  • a rough playback unit is preferably a non-seamless playback unit such as a title or PL.
  • a seamless playback unit such as a chapter in a PL is desirable.
  • Java archive file was recorded in a separate recording area from AVCIip. But this is only an example. Java archive files may be embedded in the recording area occupied by AVCIip on BD-ROM. There are two types of embedding modes: carouseling and interleaving unitization.
  • 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 AVCIip, and the second row shows sectioning.
  • the third row shows the TS bucketing, and the fourth row shows the TS bucket sequence forming the AVCIip.
  • the sectioned and TS bucketed data ("D" in the figure) is embedded in AVCIip.
  • Java archive files multiplexed on AVCIip by the carousel will be read at low bandwidth when read. Since reading at this low bandwidth takes a long period of time, typically 2-3 minutes, the playback device will read the Java archive file in 2-3 minutes.
  • FIG. 43 shows the Java archive file embedding by interleaving.
  • FIG. The first row shows the AVClip to be embedded
  • the second row shows the Java archive file interleaved with the AVClip
  • the third row shows the AVClip arrangement in the recording area of the BD-ROM.
  • the Java archive file to be embedded in the stream is interleaved, and between the divided parts (AVClip 2/4, 3/4 in the figure) constituting XXXXX.m2ts constituting AVClip It is recorded.
  • Java archive files multiplexed on AVClip by interleaving will be read at a higher bandwidth than carouseling. Because of this high bandwidth reading, the playback device reads the Java archive file in a relatively short time.
  • Carouseled Java archive files are not pre-seen.
  • the current playback time reaches the portion where the carouselized and interleaved Java archive file is embedded in the recording area of the AVClip on the BD-ROM, 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 it is read into the local memory 29 prior to the title playback, and that the read attribute is read in the carousel format during the title playback.
  • FIG. 44 (a) is a diagram showing an example of the data management table.
  • FIG. 44 (b) is a diagram showing the transition of the contents stored in the roll memory 29 due to the allocation of the data management table.
  • the vertical axis indicates the occupied area in the local memory 29
  • the horizontal axis indicates the PL time axis in one title.
  • application # l is described so that the entire PL time axis within one title is set as a live range.
  • Cliapter # 1 to Cliapter # 5 occupy the area in the local memory 29.
  • the read priority is a priority that determines the priority of reading to the local memory 29. There are multiple values for read priority. To set two levels of priority, set the value indicating Mandatory and the value indicating optional as the read priority. In this case, Mandatory means higher read priority and optional means lower read priority.
  • FIG. 45 (a) is a diagram showing the memory size of the local memory 29 in the old and new playback devices in comparison.
  • the arrow mkl indicates the memory size in the old playback device, and the arrow mk2 indicates the memory size in the new playback device.
  • FIG. 45 (b) is a diagram showing an example of a data management table in which read priorities are set.
  • the application manager 36 performs the processing according to the processing procedure shown in FIG.
  • FIG. 46 is a diagram showing a processing procedure of preload control by the application manager 36.
  • This flowchart reads the data management table in the title to be played back (step S111), and sets the application with the lowest applicationID to the application i while having the highest read priority in the data management table (step S111).
  • step S1 13 and step S114 After performing the determinations in step S1 1 2), step S1 13 and step S114, the application i is preloaded into the local memory 29 (step S1 15).
  • 1 16 is No and Step SI 17 is looped until it is determined as No.
  • Step S116 of the two steps defining the end requirement of the loop processing is to determine whether or not there is an application k having the next highest applicationID and the same read priority as the application i. . If such an application k exists, the application k is made an application i (step S119).
  • step S117 is a determination as to whether or not there is an application having the next lowest read priority in the data management table. Then, among the applications having the second lowest read priority, the application k with the smallest applicationID is selected (step S118), and the application k is set as the application i (step S119). As long as these steps S116 and S117 are set to Yes, the above-described processing of steps S113 to S115 is repeated. In steps S116 and S117, if there is no corresponding application, the process of this flowchart ends.
  • Step S120 is a judgment as to whether or not there is an application having the same applicationID and a high read priority; j.
  • Step S1221 is a step of determining whether or not the remaining capacity of the local 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 proceeds to Step S116 without being preloaded in the local memory 29.
  • step S120-step S12.1 the data of the read priority -Optional will be pre-loaded to the oral memory 29 unless the judgment in step S120-step S12.1 becomes "Yes". Is not done.
  • the old playback device with a small memory scale reads only two or three applications, and the judgment in step S121 is No. However, the new playback device with a large memory scale loads more applications. Even so, the judgment in step S1221 is not No. As described above, only the Mandatory application is read into the local memory 29 in the old playback device, and the Mandatory application and the Optional application are read into the new playback device.
  • Step S122 is a step executed when it is determined to be Yes in step S122.
  • an application j having the same applicationlD and having a high read priority exists in the local memory 29
  • 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 this is the case (step S122). If it exceeds, the application j is preloaded by overwriting the application j on the local memory 29 using the application i (step S122). If it is less, the application i is not preloaded into the local memory 29, and the process directly proceeds to step S116.
  • FIG. 47 (a) is a diagram showing an example of a data management table assumed in this specific example.
  • Java archive files of different sizes can be loaded into the local memory 29 according to the memory size, so for playback devices with a small memory size, Java archive files with thumbnail images with the minimum necessary resolution
  • a Java file containing SD images with a medium resolution is used.
  • a high resolution is used.
  • a Java archive file having an HD image with the image can be imported to the local memory 29.
  • FIG. 48 is a diagram showing a specific example of the reading process with reference to the data management table.
  • the two applications in this figure are two applications with 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 separate file 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). Of these applications, application # 2 and application # 3 have a read attribute indicating load.
  • 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 in consideration of reproduction with a reproduction device having a minimum necessary 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 size 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 is performed by a playback device having a large memory size. Despite the large memory size, the inability to read application # 3 until it reaches Chapter 4 to Chapter # 5 is a waste of memory size. Therefore, in the data management table in this figure, preload the same application # 3.
  • the read attribute indicating the ID is added and recorded on the BD-ROM, and the same applicationID 3 ⁇ 4: is assigned to these.
  • FIG. 49 is a diagram showing a processing procedure of the load processing based on the data management table.
  • the loop processing consisting of steps S131 to S133 is repeated while title reproduction is continued.
  • Step S1311 is for determining whether or not the life span of the application having the startup attribute indicating AutoRun has arrived. If the application arrives, the application having the startup attribute indicating AutoRmi is set to the application q (step SI34), a start instruction to start the application q is issued to the Java virtual machine 38, and the application q is executed. The data is read from the oral memory 29 to the work memory 37 (step S135).
  • Step S133 is a determination as to whether or not the reproduction of all PLs in the title has been completed. 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 processing of this flowchart ends.
  • Step S132 is a determination as to whether or not a call from the running application has been received. If there is, the called application is set to application q (step S1336), and it is determined whether or not the current playback point is a live range of application q in the application management table (step S1337). ). If it is not a live range, the start failure is displayed (step S148), and the process returns to the loop consisting of steps S13.1 to S133. Live range Then, the load processing is performed according to the flowchart of 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 read directly from the BD-ROM to the work memory 37 without passing through the local memory 29. . In this case, PL playback is interrupted because a head seek for reading the application occurs (step S145).
  • step S139 it is determined whether a read attribute is added to the application.
  • the absence of the read attribute means that the application q is not carouseled or interleaved. However, even if the read attribute is not added, the local memory
  • 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 it has been preloaded, the process proceeds to step S135.
  • Step S142 is a determination step performed when the read attribute is "load”, and determines whether the application q is carouseled or interleaved. If interleaved, the Java virtual machine 38 executes the cache sense (step S144). If the application q exists in the local memory 29, the process proceeds to step S135 to load the application q into 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). Carouseled If so, the timer is set (step S148), and the cache sense is executed by the Java virtual machine 38 (step S146) until the timer times out (step S147). If the application q appears in the local memory 29, the process proceeds to step S135 in FIG. 49 to load the application q 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 illustrating how an application is read by the Java virtual machine 38.
  • Arrows ⁇ 1,2 indicate the reading of a Java archive file that is alive in the application management template, alive in the data management table, and has a read attribute indicating force-rucelling and interleaving.
  • the arrow ⁇ 1 indicates the local memory 29 sense performed in steps S65 and S67.
  • the local memory 29 sense means that the data embedded by the carousel or the interleaving may be present in the local memory 29 because the data 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.
  • Arrow Vl, 2 indicates that a Java archive file that is alive in the application management table but not 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.
  • Arrow # 2 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 exists.
  • Arrow 1 corresponds to the reading in step S140, and Indicates a request for direct read from the BD-ROM by the virtual machine 38.
  • the arrow ⁇ 2 indicates the reading of the Java archive file to the local memory 29 according to the request.
  • Arrow 3 indicates reading of the Java archive file from the local memory 29 to the work memory 37.
  • the number of applications resident simultaneously on the local memory 29 can be specified so as to be equal to or less than a predetermined number.
  • a cache miss can be avoided as much as possible. Since application reading without cache miss can be guaranteed, the application is not read from the BD-ROM until the AVClip playback is stopped when the application is called. Since AVClip playback is not interrupted, seamless playback of AVClip can be guaranteed.
  • the time axis of the non-AV system title is determined based on the survival area of the application.
  • the behavior of the application is unstable, and there may be startup failure or abnormal termination.
  • the present embodiment proposes a Fail Safe mechanism in a case where a startup failure or abnormal termination has occurred.
  • FIG. 52 (a) shows the internal structure of a BD-J object according to the seventh embodiment. What is new in this figure compared to Fig. 7 (b) is that a playlist management template has been added.
  • FIG. 52 (b) is a diagram showing an example of the playlist management table.
  • the playlist management table includes a PL specification and a playback attribute of the PL.
  • the designation of PL indicates the PL that can be played back on the title time axis of the corresponding title.
  • the PL playback attribute indicates whether the specified PL is automatically played at the same time as the start of title playback (the PL automatically played in this manner is called the default PL).
  • FIG. 53 (a) shows the title time axis for non-AV titles when the playback attribute is set to indicate non-automatic playback.
  • FIG. 53 (a) shows the title time axis for non-AV titles when the playback attribute is set to indicate non-automatic playback.
  • the title time axis is determined from the live range of the application, like the non-AV title.
  • FIG. 53 (b) is a diagram showing the title time axis of a non-AV title in which the playback attribute is set to AutoPlay. If the playback attribute is set to indicate AutoPlay, the Playback Control Engine 32 starts playback of the default PL at the same time as playback of the non-AV title starts. However, even if the application operates normally and terminates normally, the title time axis is determined based on the PL time axis.
  • FIG. 53 (c) shows a case where the playback attribute is set to indicate “AutoPlay” in the playlist management table and the application ends abnormally. As a result of this abnormal termination, no application is running, but the playback of the default PL continues. Also in this case, the PL time axis of the default PL becomes the title time axis.
  • 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, since the default PL playback by the Playback Control Engine 32 is performed irrespective of the failure to start the application, the time axis of the default PL becomes the title time axis.
  • FIG. 52 (c) is a diagram showing 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 The Title branch Immediately thereafter, it instructs the Playback Control Engine 32 to start playback of this AutoHayPL. In this way, a 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 S 103 and S 104 are added before step S 1, and step S 100 is added between steps S 21 and S 22. , 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 template 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 S104).
  • step S100 it is determined whether or not reproduction is being performed by Presentation Engine 31. If the data is being reproduced, the process proceeds 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 module manager 34 of the end of the title. If it is AutoPlay, the flow shifts to step S101 to continue the processing.
  • the titles to be replayed here are non-AV titles that include a game abuse of stacking falling tile pieces.
  • the playback attribute in the playlist management table is set to AutoPlay
  • the default PL playback by the Playback Control Engine 32 also starts. Since the execution of the game app and the playback of the default PL are performed in parallel, the foreground is the screen of the game app and the background is the playback screen of the default PL, as shown in the upper left of Figure 55. A composite image as an image is 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 is in a state where something is reflected because the default PL is continuously played.
  • By specifying the playback attribute in such a playlist management table even if the game application in the non-AV title ends abnormally, it is possible to maintain the operation without hangup / blackout.
  • the BD-J object has two tables, a data management table and an application management table.
  • This embodiment discloses a form in which these are integrated into one table.
  • the item of read attribute in the data management table is abolished, and an attribute of ready attribute is provided in the start attribute instead.
  • the Ready attribute is a type of an activation attribute indicating that an application 3 is loaded in the local memory 29 in advance in preparation for a call from another application or a call from the application manager 36.
  • Figure 56 (b) is a diagram showing the relationship between application handling and startup attributes.
  • the application is handled by whether it is pre-speaked (1), automatically started when the current playback point reaches the valid section, or It is activated on call (2), loaded according to the progress of title playback (3), or alive. These differences cause the difference as shown in Fig. 56 (b). Five modes emerge. Of these, the start attribute is set to AutoRun when preloading is performed and “automatic start”, and when loading is performed and "automatic start”.
  • the activation attribute is set to the; Ready attribute when preloading or loading is performed and the activation item indicates "call activation".
  • the work memory 37 is alive, but the memory is not loaded into the oral memory 29. "This is because there is no work memory 37 in the application's data management table. This is because the section and the live range of the local memory 29 are integrated. Since the Ready attribute has been added as a start attribute, the application manager 36 can execute an application whose start attribute is set to AutoRun and an application whose start attribute is set to Ready before the title playback. Processing for preloading to the local memory 29 is performed. By doing so, it is possible to perform processing in which the application is pre-stored in the local memory 29 without providing a 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 and 2 indicate 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 the reading of an application that is alive in the application's data management table and whose startup attribute is Persistent.
  • the data management table and the application management table can be combined into one table (application ⁇ ⁇ ⁇ data management table), the processing by the application manager 36 is simplified. can do. Note that the application's data management table may be further simplified by eliminating the read priority.
  • the read priority when the application is read into the local memory 29, the read priority is referred to, and the read processing is given priority according to the read priority.
  • the ninth embodiment information meaning Optional and 0 to 255 This is an embodiment in which the read priority is represented by a combination with numerical values up to.
  • FIGS. 58 (a) and (b) are diagrams showing an example of the read priority according to the ninth embodiment.
  • 255 and 128 are examples of the read priority from 0 to 255.
  • application # 2 means that the read priority is higher than application # 3.
  • the application manager 36 first reads the application to which the read priority indicating Mandatory is assigned to the local memory 29.
  • FIG. 59 is a diagram showing a data management table to which a group attribute has been added.
  • 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" of title # 2, # 3 indicates that there is an exclusive group, and that title # 2, # 3 belong to the exclusive group of roup # l.
  • the above is the recording according to the present embodiment. It is a medium improvement.
  • the playback device After reading each application into the local memory 29 based on the data management template, 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 local 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 started by this application is limited to one in principle, only one launcher + 1 application exists in the local memory 29. If there are three or more applications, the application manager 36 must delete them from the local memory 29. It checks whether the existing application is a launcher + 1 application.
  • FIG. 59 (a) is a diagram showing access to the local memory 29 based on the application management table.
  • group attribute of application # 2 and application # 3 set as read priority -Optional is group # l, these applications belong to the same exclusive group.
  • application # l is the launcher application described above, and application # 2 and application # 3 are the applications started by this, so only one of them is on the oral memory 29.
  • Group attributes have been assigned to exist.
  • the application manager 36 refers to the group attributes of application # 2 and application # 3, and performs processing to delete one of them from the local memory 29. Such a deletion creates a margin in the local memory 29.
  • FIG. 60 is a diagram showing variations of the allocation unit.
  • the first row shows three application management tables recorded on the BD-ROM
  • the second row shows title units
  • the third row shows disk units
  • the fourth row shows.
  • the arrows in the figure schematically show the assignment of the application management table. Referring to this arrow, application management tables # 1, # 2, and # 3 in the first row are assigned to titles # 1, # 2, and # 3 shown in the second row. You can see that it is.
  • application management table # 4 is allocated for each disk, and application management table # 5 is allocated for the entire disk set.
  • the optical disk according to the present invention is implemented as a BD-ROM.
  • the optical disk of the present invention has a feature in 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 disks, and magneto-optical disks such as PDs and MOs.
  • a semiconductor memory card such as a compact flash card, a smart media, a memory stick, a multimedia card, a PCM-CIA card, or the like may be used.
  • Magnetic recording disk such as flexible disk, SuperDisk, Zip, Clik !, etc., and removable hard disk drive (ii) such as ORB, Jaz, SparQ, SyJet, EZFley, micro drive, etc. Good.
  • a hard disk with a built-in device may be used.
  • the playback device in all embodiments decodes the AVClip recorded on the BD-ROM and outputs it to the TV.
  • the playback device is only a BD-ROM drive, and the other components are the TV.
  • the playback device and the TV can be incorporated in a home network connected by IEEE 1394.
  • 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 devices are manufactured based on the internal configuration of the playback device described in each embodiment.
  • the act is an act of practicing the invention described in the specification of the present application.
  • the transfer of the playback device described in each embodiment at no charge (free for sale, sale for free, and gift for free), lending, and importing are also implementations of the present invention.
  • the act of offering the transfer or lending to general users through in-store display, solicitation of catalogs, and pamphlet distribution is also the practice of the playback device.
  • a Menu (Chapter Menu) for displaying a list of Chapters and a MOVIE object that controls its behavior may be recorded on the BD-ROM so that branching from the Top Menu is possible. It may be called up by pressing the Chapter key of the remote control key.
  • TP_extra — TS buckets with headers (hereinafter abbreviated as TS packets with EXs) are grouped into 32 packets and written to three sectors.
  • the 32 EX-attached TS packets contained 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. In other words, the sender's device removes the TP-extra-header from each of the 32 EX-attached TS packets included in the Aligned Unit, encrypts the TS packet itself based on the DTCP standard, and outputs it. When outputting TS buckets, isochronous packets are inserted anywhere between TS buckets. This insertion point is based on the time indicated in Arribval—Time—Stamp of TP_extra_header. is there. The playback device 200 outputs a DTCP_Descriptor with the output of the TS packet.
  • DTCP_Descriptor indicates the copy permission setting in TP_extm_header. If the DTCP-Descriptor is described to indicate “copy prohibited” here, the TS packet 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.
  • the digital stream may be a DVD-Video standard or a DVD-Video Recording standard VOB (Video Object).
  • VOB is a program stream conforming to the ISO / IEC13818-1 standard obtained by multiplexing a video stream and an audio stream.
  • the video stream in AVClip may be in the 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 may be obtained by encoding an analog video signal broadcasted by analog broadcasting. It may be stream data composed of a transport stream broadcast by digital broadcasting.
  • the content may be obtained by encoding an analog / digital video signal 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 BD-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 also performs processing as an MHP STB.
  • the playback device may be a Java platform embedded in a device for processing control of a mobile phone. If the BD-J module 35 is such a Java platform, 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 no problems occur even if the MOVIE mode is executed in the BD-J mode. Because there is no.
  • operation can be guaranteed in only one mode.
  • the reproduction process may be executed only in the BD-J mode. As described in the fifth embodiment, even in the BD-J mode, playback control synchronized with PL playback can be performed. Therefore, it is not necessary to provide the MOVIE mode strongly.
  • a navigation command may be provided in the interactive graphics stream to be multiplexed in the AVClip, 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 present invention discloses the internal configuration in the above-described embodiment, and it is clear that mass production is performed based on this internal configuration. From this, the playback device according to the present invention has industrial applicability.

Abstract

BD-ROM再生装置は、AVClipを含むタイトルの再生と、アプリケーションの実行とを同時に行うものであり、アプリケーションを実行するBD-Jモジュール３５と、1つのタイトルに帰属するAVClipを再生するPlayback Control Engine３２と、複数タイトル間の分岐を制御するモジュールマネージャ３４とを備えている。前記タイトルは、データ管理テーブルを含み、データ管理テーブルは、アプリケーションの読込優先度を各タイトル毎に示し、前記BD-Jモジュール３５は、Java仮想マシン３８と、ローカルメモリ２９と、ローカルメモリ２９にアプリケーションをロードするアプリケーションマネージャ３６とを含む。アプリケーションマネージャ３６は、各アプリケーションの読込優先度と、ローカルメモリ２９のメモリ規模とに応じて、アプリケーションをローカルメモリ２９に読み込む。

Description

明細書
再生装置、 プログラム、 再生方法 技術分野 本発明は、 デジタル化された映画作品の再生と、 アプリケーショ ンの実行とを同時に実行する、 再生制御技術の技術分野に属する発明であり、 本再生制御技術を民生用の再生装置、 プログラムに応用する場合の応用技術に 深く係る。 背景技術
上述したような同時実行させるにあたっては、 デジタルストリームの時間軸 においてアプリケーションの生存区間をどう定めるかが問題になる。 アプリケ —ションの生存区間とは、 アプリケ一ションによるサービスを開始してから、 サービスを終了するまでの期間をいう。 かかる期間をチャプターのように細か い単位に定めれば、 様々なアプリケーションによるサービスをかわるがわる実 行することができる。 しかしアプリケーションの生存区間を細かく定めれば、 記録媒体からのアプリケーション読み出し回数も増える。 一方、 BD-ROM、 DVD のような映画作品頒布用の光ディスク媒体は、 概して読出速度が遅い。 このような遅い速度による読み出しの回数が増えれば、 映画作品本編を構成す るビデオストリームの読み出しに影響が生じ、 動画再生が途切れがちになる.。 多様なサービスが実現されるとはいえ、 動画再生の妨げがあるような同時実行 では、 ユーザを大きく落胆させることになり、 また映画作品の制作者からは、 敬遠されることになる。 発明の開示
本発明の目的は、 アプリケーションの生存区間を細かい単位に定めることが できる再生装置を提供する:ことである。
上記目的は、 アプリケーションを実行するモジュールと、 1 つのタイ トルに 帰属するデジタルストリームを再生する再生制御エンジン部と、 複数タイ トル 間の分岐を制御するモジュールマネージャとを備え、 前記タイ トルは、 テープ ルを含み、 テーブルは、 タイ トルを生存区間としたアプリケーションを、 タイ トル毎に示し、 前記モジュールは、 仮想マシン部と、 キャッシュと、 キヤッシ ュにアプリケーションをロードするアプリケーションマネージャとを含み、 ァ プリケーシヨンマネージャは、 タイ トル間の分岐があれば、 そのタイ トルを生 存区間としているアプリケーションをキャッシュに読み込むことを特徴とする 再生装置により達成される。
タイ トルを単位にしてアプリケーションをキヤッシュにロードし、 キヤッシ ュからアプリケーションを削除するとの処理を行うので、 タイ トルにおいては アプリケ一ションがいつでも仮想マシンに読み出せる状態になる。 仮想マシン へのアプリケーション読み出しはいつでも行なえるので、 チャプターといった 細かい単位でアプリケーションの生存区間を定めたとしても、 記録媒体からの アプリケーションの読み出し回数を減らすことができる。 また、 光ディスクか らキャッシュへの読み出しは、 シームレス再生の保証が不要な、 タイ トル分岐 時になされるので、 アプリケーション読み出しによる中断をユーザに意識させ ることなく、 アプリケーションをいつでも実行できる容易に準備しておくこと ができる。
ここでキャッシュをもった再生装置を標準化しょうとすると、 そのメモリ規 模をどの程度にするかの判断に迷う。 こうした標準化を考える場合、 ミニマム スタンダードとなるメモリ規模を決め、 あらゆる再生装置にその実装を義務付 けるというのが一般的である。 しかし動作環境となるメモリ規模を小さく抑制 すると、 アプリケーションの動作環境に重い制約を与えることになり、 ォ一サ リング担当者側の制作意欲を封殺する結果を招きかねない。
動作保証を維持しつつも、 ォ一サリング担当者側の制作意欲を封殺させない ようにするには、 アプリケーションマネージャは、 読込優先度がマンダトリイ に設定されたアプリケーションを、 キャッシュに読み込み、 読込後におけるキ ャッシュの空き容量に応じて、 読込優先度がオプショナルに設定されたアプリ ケ一シヨンをキャッシュに読み込むように再生装置を構成することが望ましい。 ミニマムスタンダードたるメモリ規模に応じたアプリケーション、 より大き いメモリ規模の動作環境に応じたアプリケーションのうちどちらかを、 再生装 置のメモリ規模と、 各アプリケーションの読込優先度'とに応じて、 再生装置の メモリにロードすることができる。 かかるロードにより、 ミニマムスタンダ一 ドでの動作を動作を保証しつつも、 ォーサリング担当者の制作意欲を如何なく 発揮できるような土壌を提供することができる。
前記複数アプリケーションには、 相異なる読込優先度と、 同じ識別子とが付 与されており、 アプリケーションマネージャは、 キャッシュの規模と、 各アブ リケーシヨンに付与された読込優先度とに基づいて、 同じ識別子をもった複数 のアプリケーションのうち 1つを排他的にキヤッシュに読み込むようにしても よい。 ·
複数アプリケーションのうち、 メモリ規模に応じた唯一のものがキャッシュ にロードされるので、 再生装置のグレードに応じて、 より高品位のアプリケー シヨンを動作させることができ、 タイ トル制作の幅が広がる。 図面の箇単な説明
図 1は、 本発明に係る再生装置の使用行為についての形態を示す図である。 図 2は、 BD-ROMにおけるファイル 'ディ レクトリ構成を示す図である。 図 3は、 AVClip時間軸と、 PL時間軸との関係を示す図である。
図 4は、 4つの Clip_Information— file— nameによりなされた一括指定を示す 図である。
図 5は、 PLmarkによるチャプター定義を示す図である。
図 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の時間軸を足し合わせた時間軸を示 す図である。
図 1 0は、 本編タイ トル、 オンラインショッビングタイ トル、 ゲームタイ ト ルという 3つのタイ トルを含むディスクコンテンツを示す図である。
図 1 1は、図 10に示した 3つのタイ トルの再生画像の一例を示す図である。 図 1 2 (a) は、 図 10の破線に示される帰属関係から各アプリケーション の生存区間をグラフ化した図である。
図 1 2 (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上でどのように識別するかを示す図である。
図 1 7 (b) は、 図 17 (a) の応用を示す図である。
図 1 8は、 ROM24に格納されたソフトウエアと、ハードウェアとからなる 部分を、 レイァ構成に置き換えて描いた図である。
図 1 9は、 Presentation Engine 3 1〜モジュールマネージャ 34による処 理を模式化した図である。
図 20は、 アプリケーションマネージャ 36による処理を模式化した図であ る。
図 21は、 .ワークメモリ 37〜Default Operation Manager 40を示す図で ある。
図 22は、 アプリケーションマネージャ 36による分岐時の制御手順を示す 図である。
図 23は、 アプリケーション終了処理の処理手順を示すフローチャートであ る。
図 24は、 アプリケーション終了の過程を模式的に示した図である。
図 25 (a) は、 PL 時間軸上に生存区間を定めたアプリケーション管理テ 一ブルを示す図である。
図 25 (b) は、 図 25 (a) のアプリケーション管理テーブルに基づき、 アプリケーションの生存区間を示した図である。
図 26 (a) は、 PL時間軸から定まるタイ トル時間軸を示す。
図 26 (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オブジェク卜が想定している実行モデルを示す図である。 図 41 (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) のデータ管理テーブルの割り当てによる口一 カルメモリ 29の格納内容の変遷を示す図である。
図 48 (a) は、 プリロードされるべきアプリケーション、 ロードされるべ きアプリケーションに同一の applicationIDを付与するよう記述されたデータ 管理テーブルの一例を示す図である。
図 48 (b) は、 メモリ規模が小さい再生装置におけるローカルメモリ 29 の格納内容の変遷を示す図である。
図 48 (c) は、 メモリ規模が大きい再生装置におけるローカルメモリ 29 の格納内容の変遷を示す図である。
図 49は、 データ管理テーブルに基づくアプリケーションマネージャ 36に よるロード処理の処理手順を示す図である。
図 50は、 アプリケーション qの生存区間に、 現在の再生時点が到達した場 合のアプリケーションマネージャ 36による処理手順を示す図である。
図 51は、 Java仮想マシン 38によるアプリケ一ションの読み込みがどのよ うにして行われるかを模式化した図である。
図 52 (a) は、 第 7実施形態に係る BD-Jオブジェクトの内部構成を示す 図である。
図 52 (b) は、 プレイリスト管理テーブルの一例を示す図である。
図 52 (c) は、 分岐先タイ トルのプレイリスト管理テーブルにおいて、 再 生属性が AutoPlayに設定された PLが存在する場合、 再生装置がどのような 処理を行うかを示す図である。
図 53 (a) は、 再生属性が非自動再生を示すよう設定された場合の非 AV 系タイ トルにおけるタイ トル時間軸を示す図である。
図 53 ( b ) は、 再生属性が AutoPlayに設定された非 AV系タイ トルのタ ィ トル時間軸を示す図である。
図 53 (c) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 アプリケーションが強制終了した場合を示す図である。 図 53 (d) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 メインアプリの起動に失敗したケースを示す図である。 図 54は、 第 7実施形態に係るアプリケーシヨンマネージャ 36の処理手順 を示すフローチャートである。
図 55は、 プレイリスト管理テーブルにおいて" 再生属性 = AutoPlay" に設 定されることにより、 どのような再生が行われるかを模式化した図である。 図 56 (a) (b) は、 アプリケーションの扱いと、 起動属性との関係を示し た図である。
図 57は、 第 8実施形態に係る Java仮想マシン 38によるアプリケーショ ンの読み込みがどのようにして行われるかを模式化した図である。
図 58 (a) (b)は、第 9実施形態に係る読込優先度の一例を示す図である。 図 59 (a) は、 グループ属性が付与されたデータ管理テーブルを示す図で ある。
図 59 (b) は、 アプリケーション管理テーブルに基づくローカルメモリ 2 9に対するアクセスを示す図である。
図 60は、 アプリケーション管理テーブルの割当単位のパリェ一ションを示 す図である。 発明を実施するための最良の形態
(第 1実施形態）
以降、 本発明に係る再生装置の実施形態について説明する。 先ず始めに、 本 発明に係る再生装置の実施行為のうち、 使用行為についての形態を説明する。 図 1は、 本発明に係る再生装置の、 使用行為についての形態を示す図である。 図 1において、本発明に係る再生装置は再生装置 200であり、テレビ 300、 リモコン 400と共にホームシアターシステムを形成する。
この BD-ROM 100は、 再生装置 200、 リモコン 300、 テレビ 400 により形成されるホームシアターシステムに、 映画作品を供給するという用途 に供される。
以上が本発明に係る再生装置の使用形態についての説明である。
続いて本発明に係る再生装置の再生の対象となる、記録媒体である 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)がある Q
CLIPINFディ レクトリには、 拡張子 clpiが付与されたファイル
(00001.clpi，00002.clpi，00003.clpi)がある。
STREAMディ レクトリには、 拡張子 m2tsが付与されたファイル
(00001.m2ts，00002.m2ts,00003.ni2ts)がある。
BDARディ レクトリには、 拡張子： jarが付与されたファイル (00001.jar,00002.jar，00003jar)がある。 以上のディ レクトリ構造により、 互い に異なる種別の複数ファイルが、 BD-ROM上に配置されていることがわかる。 本図において拡張子. m2tsが付与されたファイル
(O0001.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がもつ時間軸を示し、第 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つの Clip— Information— file— nameにて、 これら 4つの時間軸が指定されている。 こ うすることで、 Playltemが有する In— time，Out_timeにより、 択一的に再生可 能な 4つの再生区間が定義されることになる。 これにより、 PL時間軸には、 切り換え可能な複数アンダル映像からなる区間 (いわゆるマルチアンダル区間） が定義されることになる。
PLmark情報は、 PL時間軸のうち、 任意の区間を、 チャプターとして指定 する情報である。 図 5は、 PLmarkによるチャプター定義を示す図である。 本 図において第 1段目は、 AVClip時間軸を示し、 第 2段目は PL時間軸を示す。 図中の矢印 pkl，2は、 PLmarkにおける Playltem指定 (ref_to— Playltem— Id) と、 一時点の指定 (mark_time— stamp)とを示す。 これらの指定により PL時間 軸には、 3つのチャプター (Chapter#l,#2,#3)が定義されることになる。
SubPath情報は、複数の SubPlayltem情報からなる。 SubPlayltem情報は、 SubClipの時間軸上に In_Time，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が定義されるからである。 以上で静的シ ナリオについての説明を終わる。 ―
続いて" 動的なシナリオ" について説明する。 動的シナリオとは、 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)、タイ トル サーチをマスクするかを示す情報 (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-Ε Μ に移植するという作業を効率的に行うことがで きる。 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アイに common.pkg 、 javaティ レクトリに aaa.class,bbb. class 、 imageアイ レクトリに、 menu.jpgが配置されている。 java了一カイプファィ ルは、 これらを； javaアーカイバでまとめることで得られる。 かかるデータは、 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 プログラムの一例を示す図である。 JMF A" BD7/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再生装置 により供給される APKAppliation Interface)である。 JumpTitleコマンドの他 にも、 ファンクション APIのコールにより、 BD-ROM再生装置特有の処理を xletプログラムに記述することができる。
BD-Jモードにおいて PL再生は、 JMFインターフェイスにより規定される。 この JMFプレーヤィンスタンスは、 PL時間軸を定めるものだから、 タイ トル 時間軸は、 この JMFプレーヤインスタンスをもったタイ トルから定まる。 ま た
BD-Jモードにおいてタィ トルからタイ トル.への分岐は JumpTitleAPIのコ ールにより規定される。 Jump itleAPI コールは、 いわばタイ トルの終了時点 を定めるものなので、 こうした 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 は PlavList#4 時間軸からなる時間軸を持つことになる。 これらタイ トル時間 軸における PL時間軸ではシ一ムレス再生が保証されるが、 タイ トル時間軸間 ではシームレス再生の保証は必要でなくなる。 Javaアプリケーションを動作さ せるにあたっては、 Javaアプリケーシ aンを、仮想マシンのワークメモリ上に 存在させてもよい期間 (サービス期間)を、 こうしたタイ トル時間軸上に定義せ ねばならない。 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プレーヤインス タンスゃ JmnpTitleAPIのコールをもたないその他のアプリケ一ションを、 夕 ィ トル時間軸上で動作させる場合、 時間軸の何処からアプリケーションによる サービスを開始し、 時間軸の何処でアプリケーションに—よるサービスを終える かという" サービスの開始点'終了点" を明確に規定することが重要になる。本 寒施形態では、 アプリケーションによるサービスが開始してから、 終了するま でを、" アプリケーションの生存" として定義する。 アプリケーションの生存を 定義するための情報は、 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、 appUcation#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#2 をワークメモリから削除して application#3 の みにするという制御を行う。 これと同様に title#2 の再生開始時において application#4 をワークメモリ にロー ドしておき、 title#3 の開始時に application#3,#4をワークメモリから削除するという制御を行いうる。
更に、 title#3の再生中において application#5をワークメモリにロードして おき、 title#3の再生終了時に application#5をワークメ'モリから削除するとい う制御を行いうる。
タイ トル間分岐があった場合でも、 分岐元一分岐先において生存しているァ プリケーシヨンはワークメモリ上に格納しておき、 分岐元にはなく、 分岐先に のみ存在するアプリケーションをワークメモリに読み込めば良いから、 アプリ ケージヨンをワークメモリに読み込む回数は必要最低数になる。 このように、 読込回数を少なくすることにより、 タイ トルの境界を意識させないアプリケー シヨン、 つまりアンバウンダリなアプリケーションを実現することができる。 続いてアプリケーションの起動属性について説明する。 起動属性には、 自動 的な起動を示す 「AutoRun」、 自動起動の対象ではないが、 仮想マシンのヮ一 クメモリに置いて良いことを示す 「Persistent」、 仮想マシンのワークメモリに はおかれるが、 CPUパワーの割り当ては不可となる 「Suspend」 がある。
「AutoRun」 は、 対応するタイ トルの分岐と同時に、 そのアプリケーション をワークメモリに読み込み、 且つ実行する旨を示す生存区間である。 あるタイ トルから、 別のタイ トルへの分岐があると、 アプリケーション管理を行う管理 主体 (アプリケーションマネージャ）は、 その分岐先タイ トルにおいて生存して おり、 かつ起動属性が AutoRunに設定されたアプリケーションを仮想マシン のワークメモリに読み込み実行する。 これによりそのアプリケーションは、 タ ィ トル分岐と共に自動的に起動されることになる。 起動属性を AutoRun に設 定しておくアプリケーションとしては、 JMF プレーヤインスタンス及ぴ JumpTitleAPIコールをもつようなアプリケーションが挙げられる。何故なら、 このようなアプリケーションは、 タイ トル時間軸を律する側のアプリケ一ショ ンであり、 このようなアプリケーションを自動的に起動にしないと、 タイ トル 時間軸の概念が曖昧になってしまうからである。
起動属性 「Persistent」 は、 継続属性であり、 分岐元 titleにおけるアプリケ ーシヨンの状態を継続することを示す。 またワークメモリにロードしてよいこ とを示す属性である。 起動属性が 「Persistent」 である場合、 この起動属性が 付与されたアプリケーションは、 他のアプリケーションからの呼び出しが許可 されることになる。アプリケーション管理を行う管理主体 (アプリケーションマ ネージャ）は、起動中のアプリケーションから呼出があ ¾と、 そのアプリケーシ ヨンの applicationIDが、 アプリケーション管理テーブルに記述されていて、 起動属性が 「Persistent」 であるか否かを判定する。 「Persistent」 であれば、 そのアプリケーションをワークメモリにロードする。 一方、 その呼出先アプリ ケーシヨンの applicationIDがアプリケーション管理テーブルに記述されてい ない場合、 そのアプリケーションはワークメモリにロードされない。 アプリケ ーションによる呼出は、 この 「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、 applicauon#3は I AutoRun」、— application#2は、 「Persistent」 と設定しておく。 この場合、 application#l、 application#3は、 title#lへの分 岐時において自動的にワークメモリにロードされ、 実行されることになる。 一 方 application#2は、 起動属' f生が Persistentなので、 「application#3は仮想マ シンのワークメモリ上にロードしてよいアプリケーション」 であるとの消極的 な意味に解される。 故に、 application#2は、 application#lからの呼出があつ て初めて仮想マシンのワークメモリにロードされ、 実行されることになる。 以 上の生存区間 ·起動属性により、仮想マシン上で動作し得るアプリケーションの 数を 4個以下に制限し、 総スレツド数を 64個以下に制限することが可能なの で、 アプリケーシヨンの安定動作を保証することができ—る。
続いて Suspendについて説明する。
Suspend とは、 リソースは割り付けられているが、 CPUパワーは割り当て られない状態にアプリケーションが置かれることをいう。 かかる Suspendは、 例えばゲームタイ トルの実行中に、 サイ ドパスを経由するという処理の実現に 有意義である。 図 1 4 ( a ) ( b ) は Suspendが有意義となる事例を示す図で ある。 図 1 4 ( b ) に示すように、 3 つのタイ トル (titie#l、 title#2、 title#3) があり、そのうち title#l、 title#3はゲームアプリを実行するが、途中の 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つのパーツからな り、 これらのパーツを装置のキャビネット及び基板に実装することで工業的に 生産することができる。 システム LSrは、 再生装置の機能を果たす様々な処理 部を集積した集積回路である。 こうして生産される再生装置は、 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、 CLUT部 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パケットを ESパケットに変換す る。 そして変換により得られた： PESパケットのうち、 CPU 2 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 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 Graphicsプレーン 1 oに書き込む。
スィ ッチ 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) 1 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情報のう 、 現在処理対象に なっているものをいう。
CPU2 2は、 命令 ROM 2 4に格納されているソフトウェアを実行して、 再 生装置全体の制御を実行する。
キーイベント処理部 2 3は、 リモコンや再生装置のフロントパネルに対する キー操作に応じて、 その操作を行うキーイベントを出力する。
命令 ROM 2 4は、再生装置の制御を規定するソフトウ アを記憶している。 スィツチ 2 5は、 BD-ROM及ぴ HDD 1 7から読み出された各種データを、 リードバッファ 2、 リードバッファ 1 8、 シナリオメモリ 2 1.、 ローカルメモ リ 2 9のどれかに選択的に投入するスィツチである。
CLUT部 2 6は、 ビデオプレーン 5に格納された非圧縮グラフィクスにおけ るインデックスカラーを、 Y,Cr,Cb値に変換する。
CLUT部 2 7は、 Interactive Graphicsプレーン 1 5に格納された非圧縮グ ラフイクスにおけるインデックスカラーを、 Y,Cr，Cb値に変換する。
卩811セット 2 8は、 再生装置に内蔵されるレジスタであり、 64個の: Player Status Register(PSE)と、 4096個の General Purpose Register (GPE)とから なる。 Player Status Registerの設定値 (PSR)のうち、 PSR4〜PSR8は、 現在 の再生時点を表現するのに用いられる。
PSR4は、 1〜： L00の値に設定されることで、 現在の再生時点が属するタイ ト ルを示し、 0 に設定されることで、 現在の再生時点がトップメニューであるこ とを示す。
PSR5は、 1〜999の値に設定されることで、 現在の再生時点が属するチヤプ ター番号を示し、 OxFFFFに設 されることで、 再生装置においてチャプター 番号が無効であることを示す。
PSR6は、 0〜999の値に設定されることで、 現在の S生時点が属する PL (力 レント 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 ) は、 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上の所在を明らかにすることができる。
以上が、 本実施形態に係る再生装置のハードウェア構成である。 続いて本実 施形態に係る再生装置のソフトウ ア構成について説明する。
図 1 8は、 ROM 2 4に格納されたソフトウエアと、ハードウエアとからなる 部分を、 レイァ構成に置き換えて描いた図である。 本図に示すように、 再生装 置のレイァ構成は、 以下の a),b)，c),d-l),d-2)，e) からなる 9 つまり、
a)物理的なハードウェア階層の上に、
b) AVClipによる再生を制御する Presentation Engine 3 1、
c)プレイ リス ト情報及び Clip 情報に基づく再生制御を行う Playback Control Engine ύ 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 Manager 4 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 Off)、 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は、 プレイ リストの 再生機能 (i)、再生装置における状態取得ノ設定機能 (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が付された矢印は、 JimipTitle コマンドの実行 (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 における 1, 2, 3は、起動制御における分岐先 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上の YYYY.MPLSフアイルに関連付けられ た JMFプレーヤインスタンスを得る。 また、 JMFプレーヤインスタンスにお ける JMFメソッ ドの実行が命じられれば、この JMFメソッ ドを BDミ ドルゥ ヱァに発行して、 BD 再生装置が対応しているファンクションコールに置き換 させる。 そして置換後のファンクションコールを Playback Control Engine 3 2に発行する。
Event Listner Manager 3 9は、 ユーザ操作により生じたイベント（キーィべ ント）を解析し、 イベントの振り分けを行う。 図中の実線矢印 1，<>2は、 この Event Listner Manager 3 9による振り分けを模式的に示す。 START、 STOP, SPEED等、 xletプログラム内の Event Listnerに登録されたキーイベントな ら、 BD-Jォブジヱクトにより間接参照されている xletプログラムにかかるィ ベントを振り分ける。 START、 STOP, SPEEDは、 JMFに対応したイベント であり、 xletプログラムの Event Listnerには、 これらのキーイベントが登録 されているので、 本キーイベントにより xletプログラムの起動が可能になる。 キーィベントカ Event Listner非登録のキーィベントである場合、 本キ一^ f ベ ントを 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非登録ィベント を受け取り、 再生制御を行ってもよい (図中の 04)。
(フローチャートの説明）
以上のアプリケーションマネージャ 3 6についての説明は、 その概要に触れ たに過ぎない。 アプリケーションマネージャ 3 6の処理を更に詳しく示したの が図 2 2、 図 2 3のフローチャートである。 以降、 これらのフローチャートを 参照してアプリケーションマネージャ 3 6の処理手順についてより詳しく説明 する。
. 図 2 2は、 アプリケーションマネージャ 3 6による分岐時の制御手順を示す 図である。 本フローチャードは、 ステップ S 2〜ステップ S 5がなす条件を満 たすアプリケーション（アプリケーション X という）を、 起動又は終了させると いう処理である。
ステップ S.2は、 分岐元タイ トルで非起動だが、 分岐先タイ トルで生存して いて、分岐先タイ トルにおける起動属性が AutoRxm属性のアプリケーション 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は、 分岐元 SuspencU 分岐先 AutoRun又は Persistentのァプ リケーシヨンが存在するか否かの判定である。 もし存在するなら、 アプリケー シヨン Xを Resumeする（ステップ S 1 1 )。
ステップ S 5は、分岐元タイ トルで起動中で、分岐先 Suspendのアプリケー シヨンが存在するか否かの判定である。 もし存在すれば、 アプリケーション X を Suspendする（ステップ S 1 2 )。
個々のアプリケーシ 3ンを終了させるにあたってのァプリケーションマネー ジャ 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は、 アプリケーション終了の過程を模式的に示—した図である。 本図に おける第 1段目は、 アプリケーションマネージャ 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^^は、 title#lの Chapter#2から Chapter#3 までが生存区間に指定され、 起動属性に AutoRxmが規定されている。 このた め application#2は、 図 2 5 ( b ) に示すように、 Chapter#2の始点で起動さ れ、 Chapter#3の終点で終了することになる。
一方 application#3は、 title#lの Chaptei#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 2 1は、タイ トルジャンプ APIが呼び出されたか否かの判定であ り、 呼び出されれば、 ジャンプ先タイ トルへの分岐を ΐジュールマネージャ 3 4に要求する（ステップ S 2 7)。
ステップ S 2 2は、 タイ トル内のアプリケ一ション呼出を担っているような メインアプリが存在するか否かの判定であり、 もし存在するなら、 それの起動 の有無を確認する（ステップ S 2 5)。 起動してなければ、" タイ トルの終わり" であると解釈し、 モジュールマネージャ 3 4に終結を通知する（ステップ S 2 6)。
ステップ S 2 3は、メインアプリがない場合に実行されるステップであり（ス テツプ S 2 2で Νο)、 どのアプリケ一シヨンも起動してない状態かどうかを判 定する。 もしそうなら、 同じく" タイ トルの終わり" であると解釈し、 モジュ ールマネージャ 3 4に終結を通知する（ステップ S 2 6)。
以上のように本実施形態によれば、 PL再生を伴わないタイ トルであっとし ても、 アプリケーション実行中は分岐せず、 アプリケーション実行が終了して 初めて分岐するという処理が可能になる。
(第 4実施形態）
本実施形態は、 DVDと同様のメニュー制御を BD-ROM上で実現する場合の 改良に関する。 図 2 8 ( a ) は、 BD-ROM により実現されるメニュー階層を 示す図である。 本図におけるメニュー階層は、 T pMenu を最上位に配し、 こ の TopMenuから下位の TitleMenu、 SubTitleMenu, AudioMenuを選択でき る構造になっている。 図中の矢印 swl，2,3は、 ボタン選択によるメニュー切り 換えを模式的に示す。 TopMenu とは、 音声選択、 字幕選択、 タイ トル選択の 何れを行うかを受け付けるボタン（図中のボタン snl，sn2,sn3)を配置したメニ ユーである。
TitleMenu とは、 映画作品 (title)の劇場版を選択するか、 ディ レクターズカ ット版を選択するか、 ゲーム版を選択するか等、 映画作品の選択を受け付ける ポタンを配置したメニューである。 AudioMenu とは、 音声再生を日本語で行 うか、 英語で行うかを受け付けるボタンを配置したメニュー、 SubTitleMenu とは、 字幕表示を日本語で行うか、 英語で行うかを受け付けるポタンを配置し たメニューである。
こうした階層をもったメニューを動作させるための MOVIEオブジェクトを 図 2 8 ( b ) に示す。図 2 8 ( b ) において MovieObject.bdmvには、 FirstPlay OBJ, TopMenu OBJ、 AudioMenu OBJ, SubTitleMenu OBJが格納されて いる。
FirstPlayオブジェクト（FirstPlay OBJ)は、 再生装置への BD-ROMの口一 ディング時に自動的に実行される動的シナリオである。
T pMenuォブジヱクト（TopMenu OBJ)は、 TopMenuの挙動を制御する動的 シナリオである。 ユーザがメニューコールを要求した際、 呼び出されるのはこ の TopMenuォブジェクトである。 TopMenuォブジェクトは、 ユーザからの操 作に応じて TopMenu中のボタンの状態を変えるものや、 ポタンに対する確定 操作に応じて分岐を行う分岐コマンドを含む。 この分岐コマンドは、 TopMenu から TitleMenu、 TopMenuから SubTitleMenu、 TopMenuから AudioMenu というメ；ユー切り換えを実現するものである。
AudioMenuォブジェクト（AudioMenu OBJ)は、 AudioMenuの挙動を制御 する動的シナリォであり、 ユーザからの操作に応じて AudioMenu中のボタン の状態を変えるコマンドゃ、 ボタンに対する確定操作に応じて音声設定を更新 するコマンドを含む。
SubTitleMenuオブジェクト（SubTitleMenu OBJ)は、 SubTitleMenuの挙動 を制御する動的なシナリオであり、 ュ一ザからの操作に応じて SubTitleMenu 中のポタンの状態を変えるコマンドや、 ボタンに対する確定操作に応じて字幕 設定用の PSRを更新するコマンドを含む。 TitleMenuォブジヱクト（TitleMemi OBJ)は、 TitleMenuの挙動を制御する 動的シナリオであり、 TitleMenu中のボタンの状態を変えるものや、 ボタンに 対する確定操作に応じて分岐を行う分岐コマンドをふくむ。
これらのメニュー用 MOVIEォブジェクトにより、 DVDで実現されている ようなメニューの挙動を実現することができる。 以上がメニュー制御に関連す る MOVIEオブジェクトである。
図 2 9は、 Index Tableと、 Index Tableから各 Movieオブジェクトへの分 岐とを模式化した図である。 本図では左側に Index Tableの内部構成を示して いる。 本実施形態における Index Table には、― FirstPLaylNDEX、 I pMenuINDEX, Audio MenuINDEX、 Subtitle Me皿 INDEX、 title MenuINDEX、 title#l〜#mINDEX、 title#m+l〜#nINDEX、 title#0INDEX を含む。 図中の矢印 bcl,2 は、 Index Table から FirstPlayOBJ への分岐 と， FirstPlayOBJから TopMenuへの分岐とを模式的に示し、 矢印 bc3，4，5は、 TopMenuかち TitleMenu、 SubTitleMenu, AudioMenuへの分岐を模式的に 示している。 矢印 bc6，7，8は、 TitleMenuから各 Movieオブジェクトへの分岐 を模式的に示している。
FirstPLaylNDEX , TopMenuINDEX, Audio MenuINDEX、 Subtitle MenuINDEX, title MenuINDEXは、それぞれ、 FirstPLayOBJ、TopMenuOBJ, Audio MenuOBJ, Subtitle MenuOBJ, title MenuOBJについての Indexで あり、 これらの識別子が記述される。
title#l~#mINDEXは、 . BD-ROMにおいて 1から m番目にエントリーされ ている titleについての Indexであり、これら 1から mまでの title番号の選択 時において分岐先となる MOVIEォブジヱクトの識別子 (ID)が記述される。 title#m+l~#nINDEXは、 BD-ROMにおいて m+1から n番目にエントリ 一されている titieについての Indexであり、 これら m+1から nまでの title 番号の選択時において分岐先となる BD-Jォブジヱクトの識別子 (ID)が記述さ れる。
title#0INDEXは、 BD-Jォブジヱクトの強制終了時において分岐先になるベ き Movieォブジェクト又は BD-Jオブジェクトを規定する INDEXである。 本 実施形態では、 TopMemiOBJ についての識別子が、 この title#0INDEXに格 納されている。
図 3 0 ( 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の呼び出しがあれば、 分岐先ラベルである タイ トル番号]'を取得し（ステップ 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は、 アブ1〕ケ一シヨンとスタンドアローンで 動作するため、 第 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)とよぶ。この Playltenrffxは、カレント 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#xがカレント： PLの最後の PIでなければ、 カレント PLにおける 次の Playltemを、 Playltem# に設定して（ステップ 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— multi_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)、 Playitem#x における y 目の Clip— information— file— name で指定されている Clip情報をシナリオメモリ 2 1に読み出し（ステップ S 5 7)、 カレント PTMを、 カレント Clip情報の EP_mapを用いて Iピクチャァドレ ス uに変換し（ステップ S 5 8)、 Playltem#xの Out_timeを、 カレント 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に設定する c ステップ S 6 5は、カレント PLMarkの番号に方向フラグの値を足した番号 を、 カレント PLMarkの番号として設定する。 ここで SkipNextキーであるな ら方向フラグは +1に設定されているので力レント PLMarkはインクリメント されることになる。 SkipBackキーであるなら方向フラグは- 1に設定されてい るので、 カレント PLMarkはデクリメントされることになる。
ステップ S 6 6では、 カレント PLMarkの ref— to— Playltem_ldに記述され ている PI を、 Hayltem#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 は順方向に早く再生 されることになる。 早戻しであるなら、 カレント ΡΪΜ が Playltem#x の Out— timeに到達したかを判定する（ステップ S 8 0)。 もし到達してないのなら、 1つ前の Iピクチャの PTSをカレント PTMに設定する（ステップ 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 により、 Hayltem#x を指定した SubPlayItem#yが存在するか否かの判定であり、 もし存在すれば、 図 3 7のフ ローチャートに移行する。 図 3 7は、 SubPlaylteinの再生手順を示すフローチ ヤートである。 本フローチャートでは、 先ずステップ 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# の In_timeを、 アドレス αに変換する。 —方ステップ S 8 9では、 SubPlayItem#yの Out— timeを,カレント Clip情報 の EP— map を用いて、 ア ド レス /3 に変換する。 ステップ S 9 0は、 SubPlayItem#yの In_timeから SubPlayItem#yの Out_timeまでの出力をデ コーダに命じる。 これらの変換で得られたァドレス 0の次の Iピクチャを求め て、 そのァドレスの 1つ手前をァドレス yに設定し（ステップ S 9 1 )、 そうし て算出されたアドレス yを用いて、 SubClip#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 2 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；)、 ステツ 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^^を構 成する Javaアーカイブファイルを口一カルメモリ 2 9に読み込んで、 常駐さ せるというものである（以降、 アプリケーションを構成する Javaアーカイブフ アイルは、 アプリケーションと同義に扱う。）。 この場合のデータ管理テーブル の記述は、 図 4 1 ( a ) の通りであり、 アプリケーションの applicationlDを、 その生存区間に対応づけて記述することで、 ローカルメモリ 2 9に常駐すべき アプリケーションを表現する。図 4 1 ( a )では、 application#lの applicationlD が title#l と対応づけられて記述されており、 application#2の applicationlD は title#l、 title#2と対応づけられ、 application#3の applicationlDは title#3 と対応づけられて記述されていることがわかる。 こうすることで、 ローカルメ モリ 2 9占有の時間的遷移がォーサリング担当者により規定されることになる c データ管理テーブル、 アプリケーション管理テーブルの組合せとしては、 ァ プリケーシヨン管理テーブルに規定する生存区間は、 細かい再生単位にし、 デ 一夕管理テーブルに規定する生存区間は、 大まかな再生単位にすることが望ま しい。 大まかな再生単位には、 タイ トル、 PL といった非シームレスな再生単 位が望ましい。 一方、 細かい再生単位としては、 PL 内のチャプターというよ うにシームレスな再生単位が望ましい。 アプリケーションの生存区間をタイ ト ル毎、 PL毎に定めれば、 アプリケーションはローカルメモリ 2 9上に存在す るので、 そのタイ トルの再生中においてアプリケーションは何時でも取り出せ る状態になる。 そうであれば、 アプリケーションの生存区間を細かく定めたと しても、 アプリケーションを即座に、 仮想マシン上のワークメモリに読み出す ことができるので、 アプリケーシヨンの起動 '終了が頻繁になされたとしても、 スムーズなアプリケーション実行を実現することができる。
次に、 読込属性について説明する。
図 2において Javaアーカイブフアイルは、 AVCIipとは別の記録領域に記録 されることを前提にしていた。 しかしこれは一例に過ぎない。 Javaアーカイブ ファイルは、 BD-ROMにおいて AVCIipが占める記録領域に埋め込まれること がある。 この埋め込みの態様には、 カルーセル化、 インターリーブユニット化 という 2種類がある。
ここで" カル一セル化" とは、 対話的な放送の実現のために同一内容を繰り 返しするという放送方式に変換することである。 BD-ROM は、 放送されたデ 一夕を格納するものではないが、 本実施形態では、 カルーセルの放送形式に倣 つて JAVAアーカイブファイルを格納するようにしている。 図 4 2は、 カルー セル化による Javaアーカイブファイル埋め込みを示す図である。第 1段目は、 AVCIip中に埋め込む Javaアーカイブファイルであり、 第 2段目は、 セクショ ン化を示す。 第 3段目は、 TSバケツ ト化、 第 4段目は、 AVCIip を構成する TSバケツト列を示す。 こうしてセクション化、 TSバケツト化されたデータ（図 中の" D" )が、 AVCIipに埋め込まれるのである。 カルーセルにより AVCIipに 多重化された Javaアーカイブファイルは、 読み出すにあたって、 低帯域で読 み出されることになる。 この低帯域での読み出しは、 概して 2〜3分というよ うに長期間を要するため、再生装置は Javaァ一カイブファィルを 2〜3分をか けて読み込むことになる。
図 4 3は、 .インタ一リーブ化による Javaアーカイブファイル埋め込みを示 す図である。 第 1段目は、 埋め込まれるべき AVClip、 第 2段目は、 AVClipに インターリーブ化された Javaアーカイブファイル、 第 3段目は、 BD-ROMの 記録領域における AVClip配置である。 本図に示すように、 ストリームに埋め 込まれるべき Javaアーカイブファイルは、 インターリーブ化され、 AVClipを 構成する XXXXX.m2tsを構成する分割部分 (図中の AVClip 2/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" と、 タイ トル再生中に、 インタ一リーブ化方式で読み込まれる旨を示す" Load.InterLeave" とがある。 読込属性には、 カルーセル化されているか、 ィ ンターリーブ化されているかが添え字で表現されているが、 これを省略しても よい。
データ管理テーブルにおける生存区間の具体的な記述例について、 図 4 4を 参照しながら説明する。 図 4 4 ( a ) は、 データ管理テーブルの一例を示す図 である。 図 4 4 ( b ) は、 かかるデータ管理テ一ブルの割り当てによるロー力 ルメモリ 2 9の格納内容の変遷を示す図である。 本図は、 縦軸方向にローカル メモリ 2 9における占有領域を示し、 横軸を、 1つのタイ トル内の PL時間軸 としている。 データ管理テーブルにおいて application#l は、 1つのタイ トル 内の PL時間軸全体を生存区間とするよう記述されているので、 このタイ トル の Cliapter#l〜Cliapter#5 においてローカルメモリ 2 9内の領域を占有する ことになる。 データ管理テーブルにおいて application#2 は、 タイ トル内の PL#1における Chaptei#l〜Cliapter#2を生存区間とするよう記述されている ので、このタイ トルの Chapter#l〜Chapter#2において口一カルメモリ 2 9内 の領域を占有することになる。データ管理テーブルにおいて application#3は、 タイ トル内の PL#1における Chapter#4〜Chapter#5を生存区間とするよう記 述されているので、このタイ トルの Chapter#4〜Chapter#5において口一カル メモリ 2 9内の領域を占有することになる。 以上で、 データ管理テーブルにお ける生存区間についての説明を終える。 続いて読込優先度について説明する。 読込優先度とは、 ローカルメモリ 2 9 への読み込みに対する優劣を決める優先度である。 読込優先度には複数の値が ある。 2段階の優劣を設けたい場合、 Mandatoryを示す値、 optionalを示す値 を読込優先度に設定する。 この場合、 Mandatoryは高い読込優先度を意味し、 optional は、 低い読込優先度を意味する。 3 段階の優劣を設けたい場合、 Mandatoryを示す値、 optional:high、 optional: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 )、 データ管理テーブルにおいて最 も高い読込優先度をもちつつ、 applicationID が最も小さいアプリケーション をアプリケーション 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 I 1 7が Noと判定されるまで、 繰り返すというループ処理を構成 している。
ステップ S 1 1 3は、 アプリケージョン iの読込属性がプリロードであるか 否かの判定であり、 ステップ S 1 1 4は、 アプリケーションの読込優先度が =Mandatoryであるか Optionalであるかの判定である。 ステップ S 1 1 3に おいてプリロードと判定され、 ステップ S 1 1 4において読込優先度が Mandatoryと判定されれば、アプリケ一ションは口一カルメモリ 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をアプリケーション iにする（ス テツプ 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, optional： high, optional -low) 0 こつしたテ一夕管埋テーフノレが処理 対象であると、 ステップ 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のアプリケーシ ョンを読み込んだ後、読込優先度 = optioiial: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#5を生存区間にしているので、 タイ トル時間軸においてどちらか一 方が排他的に口一カルメモリ 2 9上に常駐することになる。 図 4 8 ( b ) は、 タイ トル時間軸上の別々の時点において、排他的に格納される application#2、 application#3 を示す図である。 これは必要最低限のメモリ規模しかもたない 再生装置での再生を念頭に置いた配慮である。 こうした内容のデータ管理テー ブルが処理対象であるとアプリケーションマネージャ 3 6は、 上述した図 4 6 のフローチャートによりメモリ規模に応じて異なる処理を行う。
後者のアプリケーションは、 読込優先度 =ロードであるので、 ローカルメモ リ 2 9にロードされる。 かかる処理により、 Mandatoryなメモリ規模さえあれ ば、 アプリケーションマネージャはデータをローカルメモリ 2 9にロードする ことができる。 ここで問題になるのは、 メモリ規模が大きい再生装置による読 み込み時である。 メモリ規模が大きいにも拘らず、 Chaptei 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 ) )o
以上がプリ口一ド時における処理である。 続いてロード時における処理手順 について説明する。
図 4 9は、 データ管理テーブルに基づくロード処理の処理手順を示す図であ る。 本フローチャートは、 ステップ S 1 3 1〜ステップ S 1 3 3からなるル一 プ処理を、 タイ トル再生が継続されている間、 繰り返すというものである。 ステップ S 1 3 1は、 AutoRunを示す起動属性を有したアプリケーションの 生存区間が到来したか否かの判定である。 もし到来すれば、 AutoRmiを示す起 動属性を有したアプリケーションをアプリケーション q にして（ステップ S I 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によるアプリケーションの読み込みがどのよ うにして行われるかを模式化した図である。
矢印 ©1,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からのダイレクトリードの要求を示す。 矢印 ▽2はその要求による、 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 モジュ rル 3 5内のアプリケ一ションマネージャ 3 6は、 タイ トル分岐 直後にこの AutoHayPLの再生を開始するよう Playback Control Engine 3 2 に指示する。 このように再生属性が AutoPlayの PLは、 タイ トル分岐直後に 再生開始が命じられることになる。
上述した記録媒体の改良に対応するため、 アプリケーションマネージャ 3 6 は図 5 4に示すような処理手順で処理を行う。
図 5 4は、 第 7実施形態に係るアプリケーションマネージャ 3 6の処理手順 を示すフローチャートである。 本フローチャートは、 図 3 8のフローチャート においてステップ S 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 1 0 4)。
ステップ 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 0 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に予めアプリケーシ 3ン をロードしておく旨を示す起動属性の類型である。
図 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#2は、 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は、 同じ applicationlD が付与されたアプリケーションを、 読込優先度に従い排他的に ローカルメモリ 2 9にロードするとしたが、 第 1 0実施形態は、 アプリケ一シ ヨンにグループ属性を与えることにより、 排他的なロードを実現する。 図 5 9 は、 グループ属性が付与されたデータ管理テーブルを示す図である。 グループ 属性には、 排他グループなし、 排他グループあり、 といった、 2通りの設定が 可能であり、 排他グループありの場合、 そのグループ番号が記述される。 図 5 9 ( a ) における title#lの 「一」 は、 排他グループが存在しないことを示す。 一方、 title#2,#3の「group#l」は、排他グループがあり、 title#2，#3は、 roup#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のグループ属性は、 group#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!等の磁気記録デ ィ ス ク G)、 ORB,Jaz,SparQ,SyJet,EZFley,マイクロ ドライブ等のリム一バルハードディ スクドライブ (ii)であってもよい。 更に、機器内蔵型のハードディスクであって もよい。
(B) 全ての実施形態における再生装置は、 BD-ROMに記録された AVClipを デコードした上で TVに出力していたが、 再生装置を BD-ROM ドライブのみ とし、 これ以外の構成要素を TVに具備させてもい、 この場合、 再生装置と、 TVとを IEEE 1394で接続されたホームネッ トワークに組み入れることができ る。 また、 実施形態における再生装置は、 テレビと接続して利用されるタイプ であったが、 ディスプレイと一体型となった再生装置であってもよい。 更に、 各実施形態の再生装置において、 処理の本質的部分をなす部分のみを、 再生装 置としてもよい。 これらの再生装置は、 何れも本願明細書に記載された発明で あるから、 これらの何れの態様であろうとも、 各実施形態に示した再生装置の 内部構成を元に、 再生装置を製造する行為は、 本願の明細書に記載された発明 の実施行為になる。 各実施形態に示した再生装置の有償'無償による譲渡 (有償 の場合は販売、 無償の場合は贈与になる)、 貸与、 輸入する行為も、 本発明の実 施行為である。 店頭展示、 カタログ勧誘、 パンフレッ ト配布により、 これらの 譲渡や貸渡を、 一般ユーザに申し出る行為も本再生装置の実施行為である。
(C)各フローチャートに示したプログラムによる情報処理は、ハ一ドウ： Lァ資 源を用いて具体的に実現されていることから、 上記フローチャートに処理手順 を示したプログラムは、 単体で発明として成立する。 全ての実施形態は、 再生 装置に組み込まれた態様で、 本発明に係るプログラムの実施行為についての実 施形態を示したが、 再生装置から分離して、 各実施形態に示したプログラム単 体を実施してもよい。 プログラム単体の実施行為には、 これらのプログラムを 生産する行為 (1)や、 有償'無償によりプログラムを譲渡する行為 (2)、 貸与する 行為 (3)、輸入する行為 (4)、双方向の電子通信回線を介して公衆に提供する行為 (5)、 店頭展示、 カタログ勧誘、 パンフレッ ト配布により、 プログラムの譲渡や 貸渡を、 一般ユーザに申し出る行為 (6)がある。
(D)各フ口—チャートにおいて時系列に実行される各ステツプの「時」の要素 を、 発明を特定するための必須の事項と考える。 そうすると、 これらのフロー チャートによる処理手順は、再生方法の使用形態を開示していることがわかる。 各ステップの処理を、 時系列に行うことで、 本発明の本来の目的を達成し、 作 用及び効果を奏するよう、 これらのフローチヤ一卜の処理を行うのであれば、 本発明に係る記録方法の実施行為に該当することはいうまでもない。
(E)Chapterを一覧表示するための Menu(Chapter Menu)と、 これの挙動を 制御する MOVIEオブジェクトとを BD-ROMに記録しておき、 Top Menuか ら分岐できるようにしてもよい。またリモコンキーの Chapterキーの押下によ り呼出されるようにしてもよい。
(F)BD-ROMに記録するにあたつて、 AVClipを構成する各 TSパケットには、 拡張へッダを付与しておくことが望ましい。 拡張へッダは、 TP_extra— header と呼はれ、 『Arribval— Time— Stamp』 と、 『copyj»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— Time— Stampに示される時刻に基づいた位置で ある。 TSパケッ トの出力に伴い、 再生装置 2 0 0は DTCP_Descriptorを出力 する。 DTCP_Descriptor は、 TP_extm_header におけるコピー許否設定を示 す。 ここで 「コピー禁止」 を示すよう DTCP— Descriptor を記述しておけば、 IEEE1394を介して接続されたホームネットワークでの利用時において TSパ ケットは、 他の機器に記録されることはない。
(G)各実施形態において、 記録媒体に記録されるデジタルス ト リ一ムは AVClip であったが.、 DVD-Video 規格、 DVD-Video Recording 規格の VOB(Video Object)であつてもよい。 VOBは、 ビデオストリーム、 オーディオ ストリームを多重化することにより得られた ISO/IEC13818-1規格準拠のプロ グラムストリームである。 また AVClipにおけるビデオストリームは、 MPEG4 や WMV方式であってもよい。 更にオーディオストリームは、 Linear-PCM方 式、 Dolby-AC3方式、 MP3方式、 MPEG-AAC方式、 Dts、 WMA(Windows media audio)であつてもよい。
(H)各実施形態における映像作品は、アナ口グ放送で放送されたアナ口グ映像 信号をエンコードすることにより得られたものでもよい。 デジタル放送で放送 されたトランスポートストリ一ムから構成されるストリームデータであっても よい。
またビデオテープに記録されているアナログ/デジタルの映像信号をェンコ 一ドしてコンテンツを得ても良い。 更にビデオカメラから直接取り込んだアナ ログ/デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、 配信サーバにより配信されるデジタル著作物でもよい。
(I) BD-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モードを設けなくてもよいという理由による。
(L)AVClip に多重化されるべきィンタラクティブグラフィクスストリームに ナビゲーシヨンコマンドを設けて、 ある PLから別の PLへの分岐を実現して も良い。 産業上の利用可能性
本発明に係る再生装置は、 ホームシアターシステムでの利用のように、 個人的 な用途で利用されることがありうる。 しかし本発明は上記実施形態に内部構成 が開示されており、 この内部構成に基づき量産することが明らかなので、 資質 において工業上利用することができる。このことから本発明に係る再生装置は、 産業上の利用可能性を有する。

Claims

請求の範囲
1 . デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行 とを同時に行う再生装置であつて、
アプリケーションを実行するモジュールと、
1 つのタイ トルに帰属するデジタルストリームを再生する再生制御エンジン 部と、
複数タイ トル間の分岐を制御するモジュールマネージャとを備え、 前記タイ トルは、 テーブルを含み、
テーブルは、 タイ トルを生存区間としたアプリケーションを、 タイ トル毎に 示し、
前記モジュールは、 仮想マシン部と、 キャッシュと、 キャッシュにアプリケ ーションをロードするアプリケーシ 3ンマネージャとを含み、
アプリケーションマネージャは、 タイ トル間の分岐があれば、 そのタイ トル を生存区間としているアプリケーシ 3ンをキヤッシュに読み込む
ことを特徴とする再生装置。
2. 前記アプリケーションには、 読込優先度が付与されており、
読込優先度には、マンダトリィを示す値と、オプショナルを示す値とがあり、 アプリケーションの.それぞれには、 異なる識別子が付与されており、 アプリケーションマネージャは、 読込優先度がマンダトリィに設定されたァ プリケーシヨンを、 キヤッシュに読み込み、 読込後におけるキヤッシュの空き 容量に応じて、 読込優先度がオプショナルに設定されたアプリケーションをキ ャッシュに g¾み込む
ことを特徴とする請求項 1記載の再生装置。
3. 前記複数アプリケーションには、 相異なる読込優先度と、 同じ識別子と が付与されており、
アプリケ ションマネージャは、 キャッシュの規模と、 各アプリケーションに付与された読込優先度とに基づ いて、 同じ識別子をもった複数のアプリケ一ションのうち 1つを排他的にキヤ ッシュに読み込む
、 ことを特徴とする請求項 1記載の再生装置。
4. 前記複数アプリケーションは、
同じ識別子をもつた複数のアプリケーションのうち読込優先度が最も高いも のをキヤッシュに読み込み、 その後、
1)同じ識別子をもつアプリケーションのうち次順位の読込優先度をもつもの がキヤッシュに読み込めるか否かの判定と、
2)判定結果が肯定的である場合、 キャッシュ上のアプリケーションを上書き することにより、 同じ識別子をもつアプリケーションのうち次順位の読込優先 度をもつものをキヤッシュに読み込むとの処理とを、
" 否" であるとの判定結果が得られるまで繰り返す、 ことを特徴とする請求 項 3記載の再生装置。
5. 前記複数アプリケーションには、 同じ識別子と、 相異なる読出属性とが 付与されており、
前記アプリケ一ションマネージャは、
キャッシュのメモリ規模が所定の容量より大きい場合、 読出属性がプリロー ド属性に設定されたアプリケーションをキャッシュにロードして、 その代わり に読出属性が口一ド属性に設定されたアプリケーションをキャッシュに口一ド せず、
キャッシュのメモリ規模が所定の容量より小さい場合、 読出属性がプリ口一 ド属性に設定されたアプリケーションをキャッシュにプリロードせず、 その代 わりに読出属性が口一ド属性に設定されたアプリケーションをキャッシュに口 ードする、 ことを特徴とする請求項 1記載の再生装置。
6. ロード.属性を有するアプリケーションは、 デジタルストリームを構成す るセグメン卜の合間に、 ィンターリーブ式に記録されていて、 アプリケ一ションマネージャは、
デジタルストリームの読み込み時において、 ロード属性を有するアプリケー シヨンをキャッシュに読み込む、 ことを特徴とする請求項 5記載の再生装置。
7. ロード属性を有するアプリケーションは、 カルーセル形式でデジタルス トリームに多重化されていて、
アプリケーションマネージャは、
デジタルストリームの読み込み時において、 ロード属性を有するアプリケー シヨンをキャッシュに読み込む、 ことを特徴とする請求項 5記載の再生装置。
8. 前記アプリケーションマネージャは、 他のアプリケーションからのァプ リケーシヨン呼出が命じられた場合、 呼出先となるアプリケーションに、 ロー ド属性が付されているか否かを判定し、
付されている場合、 前記仮想マシン部にキャッシュセンスを行わせ、 ロード 属性が付与されたアプリケーションがキャッシュ内にあればアプリケーション に読み込ませる、 ことを特徴とする請求項 1記載の再生装置。
9. 前記ロード属性が付与されたアプリケーションには、 デジタルストリ一 ムを構成するセグメントの合間に、インターリーブ式に記録されているものと、 カルーセル形式でデジタルストリームに多重化されているものとがあり、 呼出先となるアプリケーションが、 カル一セル形式でデジタルストリームに 多重化されている場合、 前記仮想マシン部のキヤッシュセンスは、
他のアプリケーションからの呼出指示時から所定のタイムアウト時間が経過 するまで継続してなされる、 ことを特徴とする請求項 8記載の再生装置。
1 0. 前記アプリケーションマネージャは、
呼出先となるアプリケーションに、 口一ド属性が付されていないと判定され た場合、 デジタルストリーム再生を中断して記録媒体からキャッシュに、 呼出先アブ リケーションを読み出す処理を行い、
呼出先アプリケーションを記録媒体から仮想マシンに直接読み出すよう仮想 マシン部に指示する、 ことを特徴とする請求項 1記載の再生装置。
1 1 . 前記テーブルは、 各アプリケーションの属性を示し、
前記アプリケーションマネージャは、
他のアプリケ一ションによる呼出指示があった際、 呼出先アプリケーション は現在の再生時点において生存しているか否かをテーブルを参照して判定し、 生存していないと判定された場合、 デジタルストリーム再生を中断した上、 呼出先アプリケーションを記録媒体から仮想マシン部に直接読み出すよう仮想 マシン部に指示し、
記録媒体からキャッシュへの、 呼出先アプリケーションの読み出しは、 生存 して ると判定された場合になされる、 ことを特徴とする請求項 1 0記載の再 生装置。
1 2. 前記タイ トル分岐が生じた際、 前記アプリケーションマネージャは、 分岐元タイ トルにおいて生存しているが、 分岐先タイ トルにおいて生存してい ないアプリケーシヨンをキヤッシュから削除する
ことを特徴とする請求項 1記載の再生装置。
1 3. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実 行とを同時にコンピュータに実行させるプログラムであって、
前記タイ トルは、 テーブルを含み、
テーブルは、 タイ トルを生存区間としたアプリケーションを、 タイ トル毎に 示し、
タイ トル間の分岐があれば、 そのタイ トルを生存区間としているアプリケ一 シヨンをコンピュータ内のキャッシュに読み込むよう、 コンピュータを制御す る ことを特徴とするプログラム。
1 4. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実 行とを同時にコンピュータに実行させる再生方法であって、
前記タイ トルは、 テーブルを含み、
テーブルは、 タイ トルを生存区間としたアプリケーションを、 タイ トル毎に 示し、
タイ トル間の分岐があれば、 そのタイ トルを生存区間としているアプリケー ションをコンピュータ内のキヤッシュに読み込むよう、 コンピュータを制御す る
ことを特徴とする再生方法。
PCT/JP2004/015333 2003-10-10 2004-10-12 再生装置、プログラム、再生方法 WO2005036545A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2005514678A JP4091078B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、記録方法、再生方法
US10/572,873 US8131130B2 (en) 2003-10-10 2004-10-12 Recording medium, playback apparatus, recording method, and playback method
KR1020067007251A KR100937790B1 (ko) 2003-10-10 2004-10-12 기록매체, 재생장치, 기록방법, 재생방법
EP04773784A EP1675117A4 (en) 2003-10-10 2004-10-12 PLAYBACK DEVICE, PROGRAM AND METHOD
US12/110,452 US7630615B2 (en) 2003-10-10 2008-04-28 Recording medium, playback apparatus, recording method, and playback method
US12/110,473 US7623769B2 (en) 2003-10-10 2008-04-28 Recording medium, playback apparatus, recording method, and playback method

Applications Claiming Priority (4)

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

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/110,452 Division US7630615B2 (en) 2003-10-10 2008-04-28 Recording medium, playback apparatus, recording method, and playback method

Publications (1)

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

Family

ID=34436929

Family Applications (5)

Application Number Title Priority Date Filing Date
PCT/JP2004/015339 WO2005036555A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法
PCT/JP2004/015337 WO2005036547A1 (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/015333 WO2005036545A1 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法

Family Applications Before (4)

Application Number Title Priority Date Filing Date
PCT/JP2004/015339 WO2005036555A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法
PCT/JP2004/015337 WO2005036547A1 (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 再生装置、プログラム、再生方法

Country Status (7)

Country Link
US (10) US7515812B2 (ja)
EP (9) EP1675118A4 (ja)
JP (6) JP4182110B2 (ja)
KR (7) KR101059343B1 (ja)
CN (2) CN101840718B (ja)
TW (1) TW200518070A (ja)
WO (5) WO2005036555A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008537273A (ja) * 2005-03-03 2008-09-11 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 光ディスクアプリケーション用のストリームファイルシステム
US7515812B2 (en) 2003-10-10 2009-04-07 Panasonic Corporation Recording medium, reproduction device, program, and reproduction method
JP2011018277A (ja) * 2009-07-10 2011-01-27 Sharp Corp プログラム実行装置、プログラム実行方法、コンテンツ再生装置、プログラムおよび記録媒体
CN102917246A (zh) * 2012-08-31 2013-02-06 北京视博云科技有限公司 一种基于虚拟机的应用数据提供方法、装置及系统
US9661259B2 (en) 2013-03-28 2017-05-23 Mitsubishi Electric Corporation Playback device, control method, and program

Families Citing this family (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8218951B2 (en) 2003-10-30 2012-07-10 Samsung Electronics Co., Ltd. Storage medium storing program management information, and reproducing method and apparatus
CA2761989C (en) * 2003-11-10 2013-11-26 Panasonic Corporation Recording medium, playback apparatus, program, playback method, system integrated circuit
KR20050066265A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
KR20050066264A (ko) 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
JP4626799B2 (ja) * 2004-07-12 2011-02-09 ソニー株式会社 再生装置および方法、情報提供装置および方法、データ、記録媒体、並びにプログラム
CN101814310B (zh) * 2004-07-22 2012-11-28 松下电器产业株式会社 重放装置和重放方法
TWI451406B (zh) * 2004-07-22 2014-09-01 Panasonic Corp 用以實施應用程式同步化播放之播放裝置、播放方法及播放程式
KR100694123B1 (ko) * 2004-07-30 2007-03-12 삼성전자주식회사 동영상 데이터와 어플리케이션 프로그램이 기록된 저장매체 및 그 재생 장치 및 방법
KR100677132B1 (ko) 2004-09-09 2007-02-02 삼성전자주식회사 동영상 재생 및 프로그래밍 기능을 위한 멀티미디어데이터를 기록한 저장 매체, 그 재생 장치 및 재생 방법
EP1810294B1 (en) 2004-11-09 2018-11-28 Thomson Licensing Bonding contents on separate storage media
KR20060059572A (ko) * 2004-11-29 2006-06-02 삼성전자주식회사 플레이리스트를 자동 재생하기 위한 정보를 포함하는 저장매체, 그 재생 장치 및 재생 방법
JP5265920B2 (ja) 2004-12-06 2013-08-14 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 複数の記憶媒体にインターラクティブ性を拡張する方法と装置
KR20060081336A (ko) * 2005-01-07 2006-07-12 엘지전자 주식회사 기록매체에서의 디지털 인증방법
KR20060085154A (ko) * 2005-01-21 2006-07-26 엘지전자 주식회사 기록매체, 로컬 스토리지를 이용한 기록매체의 재생방법과재생장치
US8249416B2 (en) 2005-01-28 2012-08-21 Panasonic Corporation Recording medium, program, and reproduction method
EP1696321A1 (en) 2005-02-23 2006-08-30 Deutsche Thomson-Brandt Gmbh Method and apparatus for executing software applications
EP2317516B1 (en) * 2005-02-04 2013-04-17 Panasonic Corporation Readout apparatus, recording method and readout method
US7844355B2 (en) * 2005-02-18 2010-11-30 Panasonic Corporation Stream reproduction device and stream supply device
WO2006090300A1 (en) 2005-02-28 2006-08-31 Koninklijke Philips Electronics N.V. Fallback mechanism for data reproduction
US20090019468A1 (en) * 2005-03-09 2009-01-15 Vvond, Llc Access control of media services over an open network
US20080022343A1 (en) 2006-07-24 2008-01-24 Vvond, Inc. Multiple audio streams
US9176955B2 (en) * 2005-03-09 2015-11-03 Vvond, Inc. Method and apparatus for sharing media files among network nodes
US7698451B2 (en) * 2005-03-09 2010-04-13 Vudu, Inc. Method and apparatus for instant playback of a movie title
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
US8904463B2 (en) * 2005-03-09 2014-12-02 Vudu, Inc. Live video broadcasting on distributed networks
US8219635B2 (en) * 2005-03-09 2012-07-10 Vudu, Inc. Continuous data feeding in a distributed environment
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
US8099511B1 (en) 2005-06-11 2012-01-17 Vudu, Inc. Instantaneous media-on-demand
US8020084B2 (en) * 2005-07-01 2011-09-13 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US8799757B2 (en) * 2005-07-01 2014-08-05 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
JP5373772B2 (ja) 2008-04-16 2013-12-18 パナソニック株式会社 記録媒体、記録装置、記録方法、及び再生装置
KR101486772B1 (ko) * 2008-06-04 2015-02-04 삼성전자주식회사 재생 위치에 따라 디지털 컨텐츠를 관리하는 방법과 장치및 실행하는 방법 및 장치
JP2010009408A (ja) * 2008-06-27 2010-01-14 Sony Corp 情報処理装置、およびデータ処理方法、並びにプログラム
CN102027544B (zh) * 2008-07-16 2013-11-06 松下电器产业株式会社 再生装置、再生方法及程序
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
WO2010052857A1 (ja) * 2008-11-06 2010-05-14 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
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 삼성전자주식회사 가상 이미지 파일 처리 방법 및 장치
EP2254119B1 (en) 2009-05-20 2019-03-13 Sony DADC Austria AG Method for copy protection
EP2254118A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254120A1 (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
US9263085B2 (en) 2009-05-20 2016-02-16 Sony Dadc Austria Ag Method for copy protection
EP2254116A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254117B1 (en) 2009-05-20 2018-10-31 Sony DADC Austria AG Method for copy protection
JP2012527712A (ja) 2009-05-20 2012-11-08 ソニー デーアーデーツェー オーストリア アクチェンゲゼルシャフト コピープロテクションのための方法
US20120109871A1 (en) * 2009-07-14 2012-05-03 Pioneer Corporation Reproducing apparatus and method, and computer program
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 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 受信装置、受信方法、送信装置、送信方法、プログラム、及びテレビジョン受像機
KR20140018743A (ko) * 2012-08-03 2014-02-13 삼성전자주식회사 디스크리스 어플리케이션 재생 장치 및 기록 장치, 재생 방법 및 기록 방법과 디스크리스 어플리케이션을 기록한 정보저장매체
KR20140039504A (ko) * 2012-09-24 2014-04-02 삼성전자주식회사 블루레이 디스크 재생 장치 및 블루레이 디스크 로딩 방법
WO2014057833A1 (ja) * 2012-10-10 2014-04-17 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム
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 阿里巴巴集团控股有限公司 一种图片加载方法及装置
EP3310066A1 (en) * 2016-10-14 2018-04-18 Spotify AB Identifying media content for simultaneous playback
JP7119858B2 (ja) * 2018-09-28 2022-08-17 ブラザー工業株式会社 工具寿命管理装置、工作機械、表示処理方法及びコンピュータプログラム

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 自動プログラム開始装置
JPH11219313A (ja) * 1998-02-02 1999-08-10 Mitsubishi Electric Corp コンテンツ先読み方法
JP2001022625A (ja) * 1999-07-09 2001-01-26 Sony Corp データ記録装置、データ記録方法、データ取得装置、データ取得方法
WO2001035416A2 (en) * 1999-11-10 2001-05-17 Koninklijke Philips Electronics N.V. Record carrier, device and method for playing back a record carrier, device for recording a record carrier
JP2002269929A (ja) * 2001-03-08 2002-09-20 Hitachi Ltd ディスク装置
JP2002369154A (ja) * 2001-04-02 2002-12-20 Matsushita Electric Ind Co Ltd ディジタル映像コンテンツの映像再生装置、映像再生方法、映像再生プログラム、パッケージメディア
JP2003032637A (ja) * 2001-07-16 2003-01-31 Sharp 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 光重合反応開始剤
JPH0759608B2 (ja) 1990-08-06 1995-06-28 株式会社クラレ イミド化アクリル樹脂粒子体の処理方法
JPH0491078A (ja) 1990-08-06 1992-03-24 Kao Corp イミダゾール誘導体
JP2609749B2 (ja) 1990-08-31 1997-05-14 日本電気アイシーマイコンシステム株式会社 電流供給回路
JP2798490B2 (ja) 1990-09-03 1998-09-17 日本電気アイシーマイコンシステム株式会社 発振回路
EP0788105B1 (en) * 1995-08-21 1999-10-20 Matsushita Electric Industrial Co., Ltd. Multimedia optical disk for easily realizing branch reproduction to parental lock section with a little amount of control information and reproducing device therefor
CN100351911C (zh) 1995-08-21 2007-11-28 松下电器产业株式会社 根据交互控制实现意外性场景展开的多媒体光盘再生装置
CN1103486C (zh) * 1995-08-21 2003-03-19 松下电器产业株式会社 能永久保持图象内容新鲜感的光盘的再生装置及再生方法
MX9702848A (es) * 1995-08-21 1997-07-31 Matsushita Electric Ind Co Ltd Disco optico de multimedia que permite a un desarrollador de titulos coordinar el uso de funciones especiales de reproduccion y un dispositivo de reproduccion para este disco.
EP0777230A1 (de) * 1995-12-04 1997-06-04 Markus Zwickl CDs enthaltend zusätzliche Textinformation
EP0935249B1 (en) * 1996-04-12 2006-05-24 Matsushita Electric Industrial Co., Ltd. Multimedia optical disc storing both video titles provided with AV functions and video titles with no such functions which can instantly distinguish between such kinds of titles, and a reproduction apparatus and reproduction method for such disc
CN1260970C (zh) * 1996-05-09 2006-06-21 松下电器产业株式会社 用于多媒体光盘的记录方法、再生装置及再生方法
JPH1063362A (ja) 1996-08-16 1998-03-06 Nec Corp レジューム要因別に複数のプログラム状態を保持可能なサスペンドレジューム方法
JP3948051B2 (ja) 1997-04-30 2007-07-25 ソニー株式会社 編集装置及びデータ編集方法
JP3655433B2 (ja) 1997-06-20 2005-06-02 パイオニア株式会社 コンピュータ読み取り可能な記録媒体及び情報再生装置
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
KR20020022085A (ko) 1999-07-13 2002-03-23 썬 마이크로시스템즈, 인코포레이티드 응용프로그램 라이프사이클에 따른 응용프로그램 관리방법 및 장치
US6874145B1 (en) * 1999-07-13 2005-03-29 Sun Microsystems, Inc. Methods and apparatus for implementing an application lifecycle design for applications
JP3756708B2 (ja) * 1999-09-30 2006-03-15 株式会社東芝 情報処理端末装置およびそのファイル管理方法
CN1225905C (zh) 1999-10-29 2005-11-02 公共电视公司 交互式节目回放
DK1224806T3 (da) 1999-10-29 2004-02-16 Opentv Corp System og en metode til optagelse af "pushed" dataindhold
JP2001238161A (ja) 2000-02-25 2001-08-31 Sony Corp 情報付加装置、情報付加方法および記録媒体
US7200857B1 (en) * 2000-06-09 2007-04-03 Scientific-Atlanta, Inc. Synchronized video-on-demand supplemental commentary
CN1383678A (zh) 2000-04-21 2002-12-04 索尼公司 编码设备和方法、记录介质和程序
GB0016062D0 (en) * 2000-06-30 2000-08-23 Koninkl Philips Electronics Nv Playback of applications with non-linear time
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
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 分散電源用発電機の出力方法
CN1229990C (zh) * 2001-04-02 2005-11-30 松下电器产业株式会社 数字影像内容的影像再生装置、影像再生方法
KR100771264B1 (ko) 2001-05-12 2007-10-29 엘지전자 주식회사 스크립트 파일이 포함 기록된 기록매체와, 그 재생장치 및방법
EP1309195B1 (en) 2001-10-29 2007-11-14 Humax Co., Ltd. Method for recording a digital broadcast program and time-based playback of a recorded broadcast program and apparatus therefor
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
CN100414537C (zh) * 2002-02-07 2008-08-27 三星电子株式会社 包含显示模式信息的信息存储介质、再现装置及其方法
JP4532810B2 (ja) 2002-02-22 2010-08-25 キヤノン株式会社 画像処理装置、画像処理装置の制御方法、プログラム、及びコンピュータ読み取り可能な記憶媒体
JP2003249057A (ja) 2002-02-26 2003-09-05 Toshiba Corp デジタル情報媒体を用いるエンハンスド・ナビゲーション・システム
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
RU2320030C2 (ru) * 2002-06-24 2008-03-20 Эл Джи Электроникс Инк. Носитель записи со структурой данных для управления воспроизведением записанных на нем видеоданных нескольких каналов воспроизведения и способы и устройства записи и воспроизведения
DE10228103A1 (de) 2002-06-24 2004-01-15 Bayer Cropscience Ag Fungizide Wirkstoffkombinationen
TWI234392B (en) * 2002-08-26 2005-06-11 Samsung Electronics Co Ltd Apparatus for reproducing AV data in interactive mode, method of handling user input, and information storage medium
EP2246857A3 (en) * 2002-09-12 2010-12-01 Panasonic Corporation Recording medium, playback device, program, playback method, and recording method
EP1576460B1 (en) * 2002-11-26 2012-01-11 Panasonic Corporation Apparatus for managing removable storage media that can be connected thereto, and method and program for managing removable storage media
JP3908724B2 (ja) * 2002-12-09 2007-04-25 株式会社東芝 情報再生装置及び情報再生方法
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
JP4091104B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4117019B2 (ja) 2003-10-10 2008-07-09 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4091105B2 (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
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 複合集電体およびその製造方法
JP2007265851A (ja) 2006-03-29 2007-10-11 Molex Inc ケーブル用コネクタ

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 自動プログラム開始装置
JPH11219313A (ja) * 1998-02-02 1999-08-10 Mitsubishi Electric Corp コンテンツ先読み方法
JP2001022625A (ja) * 1999-07-09 2001-01-26 Sony Corp データ記録装置、データ記録方法、データ取得装置、データ取得方法
WO2001035416A2 (en) * 1999-11-10 2001-05-17 Koninklijke Philips Electronics N.V. Record carrier, device and method for playing back a record carrier, device for recording a record carrier
JP2002269929A (ja) * 2001-03-08 2002-09-20 Hitachi Ltd ディスク装置
JP2002369154A (ja) * 2001-04-02 2002-12-20 Matsushita Electric Ind Co Ltd ディジタル映像コンテンツの映像再生装置、映像再生方法、映像再生プログラム、パッケージメディア
JP2003032637A (ja) * 2001-07-16 2003-01-31 Sharp Corp データ放送受信装置

Non-Patent Citations (1)

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

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8437625B2 (en) 2003-10-10 2013-05-07 Panasonic Corporation Playback apparatus program and playback method
US7515812B2 (en) 2003-10-10 2009-04-07 Panasonic Corporation Recording medium, reproduction device, program, and reproduction method
US7623769B2 (en) 2003-10-10 2009-11-24 Panasonic Corporation Recording medium, playback apparatus, recording method, and playback method
US7630615B2 (en) 2003-10-10 2009-12-08 Panasonic Corporation Recording medium, playback apparatus, recording method, and playback method
US7702222B2 (en) 2003-10-10 2010-04-20 Panasonic Corporation Playback apparatus program and playback method
US7715696B2 (en) 2003-10-10 2010-05-11 Panasonic Corporation Recording medium, playback apparatus, program, and playback method
US8107788B2 (en) 2003-10-10 2012-01-31 Panasonic Corporation Recording medium, playback device, recording method and playback method
US8131130B2 (en) 2003-10-10 2012-03-06 Panasonic Corporation Recording medium, playback apparatus, recording method, and playback method
US8509596B2 (en) 2003-10-10 2013-08-13 Panasonic Corporation Recording medium, playback apparatus, program, and playback method
US8406604B2 (en) 2003-10-10 2013-03-26 Panasonic Corporation Playback apparatus, recording method, and playback method
JP2008537273A (ja) * 2005-03-03 2008-09-11 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 光ディスクアプリケーション用のストリームファイルシステム
JP2011018277A (ja) * 2009-07-10 2011-01-27 Sharp Corp プログラム実行装置、プログラム実行方法、コンテンツ再生装置、プログラムおよび記録媒体
CN102917246A (zh) * 2012-08-31 2013-02-06 北京视博云科技有限公司 一种基于虚拟机的应用数据提供方法、装置及系统
CN102917246B (zh) * 2012-08-31 2015-01-14 北京视博云科技有限公司 一种基于虚拟机的应用数据提供方法、装置及系统
US9661259B2 (en) 2013-03-28 2017-05-23 Mitsubishi Electric Corporation Playback device, control method, and program

Also Published As

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

Similar Documents

Publication Publication Date Title
JP4117006B2 (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: 200480029696.5

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): BW GH 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: 2005514678

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020067007251

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2004773784

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004773784

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007089146

Country of ref document: US

Ref document number: 10572873

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1020067007251

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 10572873

Country of ref document: US