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

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

Info

Publication number
WO2005036554A1
WO2005036554A1 PCT/JP2004/015330 JP2004015330W WO2005036554A1 WO 2005036554 A1 WO2005036554 A1 WO 2005036554A1 JP 2004015330 W JP2004015330 W JP 2004015330W WO 2005036554 A1 WO2005036554 A1 WO 2005036554A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
title
playback
management table
branch
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2004/015330
Other languages
English (en)
French (fr)
Inventor
Wataru Ikeda
Hiroaki Iwamoto
Tomoyuki Okada
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
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 US10/572,980 priority Critical patent/US7715696B2/en
Priority to CN200480029746XA priority patent/CN1867999B/zh
Priority to EP04773781A priority patent/EP1672637A4/en
Priority to JP2005514677A priority patent/JP4117006B2/ja
Priority to KR1020067007243A priority patent/KR101076198B1/ko
Priority to KR1020097016043A priority patent/KR101059290B1/ko
Publication of WO2005036554A1 publication Critical patent/WO2005036554A1/ja
Anticipated expiration legal-status Critical
Priority to US12/757,136 priority patent/US8509596B2/en
Ceased legal-status Critical Current

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 digitized video and execution of an application, and uses the reproduction control technology as a recording medium, a consumer reproduction device, and a program. Deeply related to applied technology when applied to '' Background technology
  • the reproduction progress of the disk content may have a reversal of the reproduction time axis. Retrograde means that the time axis advances in the reverse direction by rewinding. If this reversal and progress is repeated many times before and after the application should be started and terminated, and loading and discarding of work memory will occur, Again, resulting in extra read load.
  • An object of the present invention is to provide a reproducing apparatus capable of avoiding the occurrence of an extra reading load even if the reproduction is reversed in the reproduction time axis.
  • the above object is a recording medium in which a plurality of branchable titles and an application are recorded, wherein the application is a program described in a programming language for a virtual machine, and can be executed by the virtual machine.
  • a live section is defined in advance, and each title includes a management table, and the management table indicates an application having a title as a live section for each title.
  • a title consists of a time axis and a control procedure.Since the branch from the title to the title is specified by a branch command, even if there is a rewind in the time axis of one title, Playback does not reverse until the branch source title before the branch is made by the branch command.
  • the title is a "unit that cannot be reversed in playback.” Based on this title, if the life span of the application is specified, reading to the work memory and discarding will not be repeated many times. . Since reading and discarding are not repeated, unnecessary reading load can be avoided.
  • 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.
  • Figure 4 is a diagram showing the 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.
  • Figure 8 shows programs and data stored in a Java archive file.
  • FIG. 8B shows an example of the xlet program.
  • Figure 9 (a) is a diagram showing a series of titles such as the top menu, title # l, and title # 2.
  • FIG. 9B is a diagram showing a time axis obtained by adding the time axes of PlayLis #l and PlayList # 2.
  • FIG. 10 is a diagram showing disc contents 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 application management table described in order to define the life cycle of FIG. 12 (a).
  • FIG. 13A is a diagram showing an example of the activation attribute setting.
  • FIG. 13 (b) is a diagram showing an application (application # 2) that is started for the first time when an application is called from another application.
  • FIGS. 14 (a) and 14 (b) are diagrams showing an example of an application management table and a live range in which Suspend is significant.
  • FIG. 15 is a diagram showing combinations of three modes (Persistent, AutoRun, Suspend) that the startup attribute can take and three modes of the application state in the immediately preceding title (non-starting, running, and Suspend).
  • FIG. 16 is a diagram showing the internal configuration of the playback device according to the present invention.
  • FIG. 17A is a diagram showing how a Java archive file existing on the BD-ROM is identified on the local 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 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—Default Operation Manager 40.
  • FIG. 22 is a diagram showing a control procedure at the time of branching by the application manager 36.
  • FIG. 23 is a flowchart showing the processing procedure of the application termination processing.
  • FIG. 24 is a diagram schematically showing a process of terminating the application.
  • Fig. 25 (a) is a diagram showing an application management table 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 evening time axis determined from the life span of the main application.
  • Figure 26 (c) is a diagram showing a title time axis determined from the life spans of multiple applications.
  • FIG. 27 is a flowchart showing the processing procedure of the application manager 36 during title playback.
  • FIG. 28A is a diagram showing a menu hierarchy realized by the BD-ROM.
  • FIG. 28 (b) is a diagram showing a MOVIE object for implementing the menu hierarchy.
  • FIG. 29 is a diagram schematically showing an Index Table and branching from the Index Table to each Movie object.
  • FIG. 30 (a) shows a branch when the Index Table is described as shown in FIG. 29 (b).
  • FIG. 30 (b) is a diagram showing a branch when a non-AV title is forcibly terminated.
  • FIG. 31 is a flowchart showing a processing procedure of the module manager 34.
  • FIG. 32 is a diagram showing an operation example of application termination by the application manager 36.
  • Fig. 33 is a flowchart showing the PL playback procedure using Playback Control Engine 32. It is.
  • FIG. 34 is a flowchart showing a procedure for accepting andal 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 showing 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 oral memory 29.
  • FIG. 41 (b) is a diagram showing a data management table described in order to define the Java archive file live range in FIG. 41 (a).
  • Fig. 42 is a diagram showing the embedding of a Java archive file by carouselization.
  • FIG. 43 (a) is a diagram showing AVClip embedding by interleaving.
  • FIG. 43 (b) is a diagram showing three types of read attributes.
  • FIG. 44A shows an example of the data management table.
  • FIG. 44 (b) is a diagram showing the transition of the storage contents of the roll memory 29 due to the assignment of the data management table of FIG. 44 (a).
  • FIG. 45 (a) is a diagram showing the memory size of the local memory 29 in the old and new playback devices in comparison.
  • FIG. 45 (b) is a diagram showing an example of a data management table in which read priorities are set.
  • FIG. 46 is a diagram showing a processing procedure of pre-control by the application manager 36.
  • FIG. 6 is a diagram illustrating an example of a data management table that defines a plurality of applications.
  • FIGS. 47 (b) are diagrams showing changes in the contents stored in the roll memory 29 due to the allocation of the data management table in FIG. 47 (a).
  • 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 the 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 the 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 point has reached the live range of the application q.
  • FIG. 51 is a diagram schematically illustrating how an application is read by the Java virtual machine 38.
  • FIG. 52 (a) is a diagram showing the internal structure of a BD-J object according to the seventh embodiment.
  • FIG. 52 (b) is a diagram showing an example of the playlist management table.
  • FIG. 52 (c) is a diagram showing what processing is performed by the playback device when 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. 53 (b) is a diagram showing the title time axis of a non-AV title whose playback attribute is set to AutoPlay.
  • 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 the processing procedure of the application manager 36 according to the seventh embodiment.
  • Figures 56 (a) and (b) are diagrams showing 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 (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 variation of the allocation unit of the application management table.
  • FIG. 1 is a diagram showing a mode of use of a playback apparatus according to the present invention.
  • a reproducing apparatus according to the present invention is a reproducing apparatus 200, and forms a home theater system together with a television 300 and a remote control 400.
  • This BD-ROM 100 is used for supplying a movie work to a home theater system formed by a reproducing apparatus 200, a remote controller 300, and a television 400.
  • the disk content supplied to the home theater system by the BD-ROM is composed of a plurality of titles that can be branched to each other.
  • Each title contains one or more playlists and dynamic control procedures using these playlists. Consists of.
  • a playlist is an access unit on a BD-ROM that consists of one or more digital streams and a playback path in the digital streams, and has the concept of a "time axis". Since the above playlist and dynamic control procedure are included, the title combines the concept of the time axis peculiar to the digital stream and the characteristics of a computer program.
  • FIG. 2 is a diagram showing a file 'directory structure on a BD-ROM.
  • the BD-ROM has a BDMV directory in the Root directory Byon.
  • the BDMV directory contains a file with the extension bdmv (index.bdmv, MovieObject.bdmv) and a file with the extension BD-J (00001.BD-J, 00002 .BD-J, 00003.BD-J). Under this BDMV directory, there are four subdirectories called a PLAYLIST directory, a CLIPINF directory, a STREAM directory, and a BDAR directory.
  • the PLAYLIST directory contains files (O0001.mpls, 00002.mpls, 00003mpls) with the extension mpls.
  • the CLIPINF directory contains files with the extension clpi (O0001.clpi, 00002.clpi, 00003.clpi).
  • the STREAM directory contains files (00001.m2ts, 00002.m2ts, 00003.ni2ts) with the extension m2ts.
  • the BDAR directory contains files (00001.] 'Ar, 00002jar, 0003; iar) with the extension jar. From the above directory structure, it can be seen that a plurality of files of different types are arranged on the BD-ROM.
  • AVClip (00001.m2ts, 00002.m2ts, 00003.m2ts- ⁇ ⁇ ⁇ stores AVClip.
  • AVClip has types such as MainClip and SubClip.
  • MainCLip is a video stream, audio stream, presentation graphics This is a digital stream obtained by multiplexing multiple elementary streams such as streams, interactive graph. Streams. 4 015330
  • a SubClip is a digital stream corresponding to only one elementary stream, such as an audio stream, a graphics stream, a text subtitle stream, and the like.
  • the files with the extension “dpi” (00001.clpi, 00002.clpi, 00003.clpi-7) are management information corresponding to the AVClips on a one-to-one basis. Because of the management information, the Clip information has information such as the encoding format, the frame rate, the bit rate, and the resolution of the stream in the AVClip, and the EP-map indicating the cue 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 consists of multiple pieces of Hayltem information.
  • Playltem is a playback section defined by specifying In-hne and OutJThne 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. Three playback sections are defined by the Injime and Out-time of these Playltems # 1, # 2, and # 3. become.
  • a time axis different from the AVClip time axis is defined. This is the PL time axis shown in the second row.
  • the definition of the Playltem information enables the definition of a time axis different from that of the AVClip.
  • FIG. 4 is a diagram showing a collective specification made by four Clips—Information—file_names.
  • the first to fourth rows show four AVClip time axes (time axes of AVClips # 1, # 2, # 3, and # 4), and the fifth row shows the PL time axis. Is shown.
  • These four time axes are specified by four Clip-Information-file-names in Playltem information. like this By doing so, four playback sections that can be selectively played back are defined by the In_time and Out-time of the Playltem.
  • a section (a so-called multi-angle section) comprising a plurality of switchable angle videos is defined on the PL time axis.
  • PLmark information is information that designates an arbitrary section on the PL time axis as a chapter.
  • FIG. 5 is a diagram showing a chapter definition by PLmark.
  • the first row shows the AVClip time axis
  • the second row shows the PL time axis.
  • the arrow pkl, 2 in the figure indicates the Playltem specification (ref_to_PlayItem-Id) and the temporary point specification (mark-time_stamp) in PLmark.
  • three chapters (Chapter # 1, # 2, and # 3) are defined on the PL time axis. ⁇
  • SubPath information is composed of multiple pieces 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 SubPlayltera 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 advance in synchronization. Will be.
  • FIG. 6 is a diagram showing the definition of a playback section on the SubPlayltem time axis and the designation of synchronization. In this 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.
  • a playback section is also defined on the SubClip time axis.
  • Sync_PlayItem_Id indicates the synchronization specification for Playltem
  • sync-start- PTS_of_PlayItem indicates the specification of one point on the Playltem on the PL time axis.
  • the above-described Clip information and playlist information are classified into “static scenarios”. This is because the PL, which is a static playback unit, is defined by the above Clip information and Playlist information. This concludes the description of the static scenario.
  • a dynamic scenario is scenario data that dynamically defines the playback control of an AVClip.
  • “Dynamic” means playback equipment This means that the contents of playback control change due to status changes in the device or key events 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” and is stored in the file MovieObject.bdmv.
  • FIG. 7A shows the internal structure of a Movie object.
  • the movie object is composed of a command string composed of attribute information and a plurality of navigation commands.
  • the attribute information is information (resume—intention—flag) indicating whether or not playback is intended to be resumed after a MenuCall when a MenuCall is made on the PL time axis. Whether the MenuCall is masked on the PL time axis (Menu—call—mask) and information (title_search—flag) indicating whether to mask the title search.
  • a Movie object can have both the two characteristics of “time axis” + “programmatic control”, and various types of titles, such as those that execute the main part playback, must be described in 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.
  • the first argument is the playlist number, which can specify the PL to be played.
  • the second argument is Playltem included in the PL, any time in the PL, 0
  • the playback start position can be specified using Chapter and Mark.
  • Playl function that specifies playback start position on PL time axis by Playltem
  • the PlayPL function that specifies the playback start position on the PL time axis is defined by Chapter in PlayPLatChapterO,
  • the 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 destination dynamic scenario as an argument.
  • FIG. 7B is a diagram showing the internal configuration of a BD-J object. As shown in this figure, the BD-J object is T JP2004 / 015330
  • the BD-J object is almost the same as the Movie object in that it has attribute information.
  • the difference from Movie object is that commands are not directly described in BD-J objects. That is, the control procedure in the Movie object was directly described by the navigation command.
  • the control procedure is indirectly specified by specifying a Java application whose title is a live range in the application management table. By such an indirect rule, the control procedure can be efficiently shared, that is, the control procedure can be shared among a plurality of titles.
  • Fig. 7 (c) shows the internal structure of the Java application.
  • the application consists of one or more xlet programs loaded in the virtual machine's heap area (also called work memory).
  • work memory also called work memory
  • one or more threads are running, and an application is composed of xlet programs, threads, and threads that are loaded into the work memory.
  • the above is the configuration of the application.
  • the Java archive file will be described.
  • 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 are multiple files in which the directory structure shown in the frame is arranged; The directory structure shown in the box is composed of a root directory, a java directory, and an image directory.Common.pk is stored in the root directory, and aaa.class, bbb.ciass is stored in the java directory. .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 to the cache, and is treated as multiple files placed in a directory on the cache.
  • the five-digit number "xxxxx" in the file name of the Java archive file indicates the application ID (applicationlD). Show.
  • 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. 8B shows an example of the xlet program.
  • JMF ⁇ "BD: ⁇ 00001.mpls"; is a method that instructs the Java virtual machine to generate a player instance for playing the PL.
  • A.play is a method that instructs the JMF player instance to play. Such JMF player instance generation is performed based on the JMF library.
  • the description of the xlet program is not limited to the PL of the BD-ROM, but is the description of the JMF applicable to all content with a time axis. Since such a description is possible, it is possible to encourage software houses that are good at Java programming to create BD-J objects. '
  • JumpTItleO in Fig. 8 (b) is a function API call.
  • This function API instructs the playback device to branch to another title (title # l in the figure).
  • the function API is an APK application interface supplied by the BD-ROM playback device.
  • 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 title to title is specified by the call of JmnpTitleAPI. Since the JmnpTitleAPI call determines the end point of the title, so to speak, an application having such a JMF player instance or JumpTitleAPI call starts and ends the title in the BD-J mode. Will be governed. Such an application is called a main part reproduction 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 a BD-J object.
  • One example here is the title shown in Fig. 9 (a).
  • This title is a series of titles such as "Top Menu” title # l ⁇ title # 2 ⁇ Top Menu, Top Menu "title # 3 ⁇ Top Menu.
  • PlayList # l has a time axis that is the sum of the time axes of PlayList # 2.
  • title # 2 has a time axis composed of PlayLis # 3 time axis
  • title # 3 has a time axis composed of PlayList # 4 time axis.
  • Seamless playback is guaranteed on the PL time axis in these title time axes, but seamless playback is not necessary between title time axes.
  • IndexTable is a table that associates title numbers with Movie objects and BD-J objects, and is an indirect reference table that is referenced when branching from a dynamic scenario to a dynamic scenario.
  • IndexTable is the Index for each of multiple labels Consists of PT / JP2004 / 015330. Each Index describes the identifier of the dynamic scenario corresponding to the label. By referring to such IndexTable, branching can be realized without strictly discriminating the difference between Movie object and BD-J object. Details of IndexTable are described in the following International Publication. See this gazette for details. International Publication WO 2004/025651 A1 The above is an explanation of files recorded on a BD-ROM.
  • JMF player instances and applications with JumpTitleAPI calls govern the title timeline, but other applications without JMF player instance / JumpTitleAPI calls operate on the title timeline.
  • the period from the start of the service by the application to the end thereof is defined as “survival of the application”.
  • Information for defining the survival of the application exists in the application management table of the BD-J object.
  • the application management table will be described in more detail.
  • the application management table is information indicating an application that can survive on the work memory of the virtual machine on the title time axis of each title. Survival in the work memory means a 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 line arrow atl in FIG. 7B 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 the application whose title is the live range, and “start attribute” of the application.
  • FIG. 10 is a diagram showing disc content including three titles: a main title, an online shopping title, and a game title.
  • IndexTable is described on the right side, and three titles are described on the left side.
  • FIG. 11 is a diagram showing an example of the reproduced images of the three titles shown in FIG.
  • the cart program application # 3 is started with both title # l and title # 2. .
  • an application app that simulates a mascot appearing in a movie work, and an application that displays a menu in response to a menu call in addition to the cart app described above.
  • Fig. 12 (a) When the life span of each application is graphed from the membership shown by the broken line in Fig. 10, the result is as shown in Fig. 12 (a).
  • the horizontal axis is the title time axis, and the live ranges of each application are arranged in the vertical axis direction.
  • application # l and application # 2 belong only to title # l, so their survival sections remain within title # l. Since application # 4 belongs to title # 2 only, these live ranges remain within title # 2.
  • application # 5 belongs to title # 3 only, so these live ranges remain in title # 3.
  • application ⁇ belongs to title # 1 and title # 2, The interval ranges from title # l to title # 2.
  • the application management table for title # 1, # 2, and # 2 is as shown in Fig. 12 (b). If the application management table is described in this way, application # l, application # 2, and application # 3 are loaded into the work memory at the start of the playback of title # l. At the start of title # 2, application # l and application # 2 are deleted from the work memory and only application # 3 is controlled. Similarly, control can be performed such that application # 4 is loaded into the work memory at the start of playback of title # 2, and application # 3 and # 4 are deleted from the work memory at the start of title # 3.
  • control can be performed such that application # 5 is loaded into the work memory while title # 3 is being played, and application # 5 is deleted from the work memory when title # 3 is played.
  • the surviving abrication at the branch source and the branch destination is stored in the work memory, and the application that is not at the branch source but exists only at the branch destination is stored in the work memory.
  • the number of times the application is read into the work memory is the minimum required. In this way, by reducing the number of times of reading, it is possible to realize an application that does not recognize the boundaries of titles, that is, an application that is unbounded.
  • the startup attributes include "AutoRun”, which indicates automatic startup, "Persistent”, which indicates that it is not a target of automatic startup but can be placed in the virtual machine's work 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. If there is a branch from one title to another title, the application manager that manages the application is still alive in that branch destination title, and the startup attribute is set to AutoRun. Load the application into the virtual machine's work memory and execute it. This will automatically launch the application along with the title branch.
  • An application case that sets the startup attribute to AutoRun includes a JMF player instance and a JumpTitleAPI call.
  • the startup attribute “; Persistent” is a continuation attribute, indicating that the application state at the branch source titie is to be continued, and that it can be loaded into the work memory.
  • the startup attribute is “Persistent”. In some cases, applications with this startup attribute will be allowed to be called from other applications.
  • the management entity application manager
  • the management entity determines whether the applicationID of the application is described in the application management table and the startup attribute is "Persistent”. I do. 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 a default startup attribute given when the startup attribute is not explicitly specified, so if the startup attribute of a certain application is "1-", the startup attribute of that application is started.
  • the attribute means this Persistent.
  • FIG. 13 is an example of setting the startup attributes for the three applications in FIG. It is assumed that application ⁇ among the three applications shown in FIG. 12 is an application that is started only when an application calls an 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 application start attribute of each application in the application management template is appdcation # l, appucation # 3 is ⁇ Autojtiun '', and applicat; ion # 2 is , I Pei'sistentJ.
  • application # l and application # 3 are branched to title # l Sometimes it will be automatically loaded into work memory and executed.
  • application # 2 since application # 2 has a startup attribute of Persistent, it can be interpreted negatively that "application # 3 is an application that can be loaded on the work memory of the virtual machine". Therefore, application # 2 will be loaded into the virtual machine's work memory and executed only after a call from application # l.
  • the survival area-start attribute described above the number of applications that can run on the virtual machine can be limited to four or less, and the total number of threads can be limited to 64 or less. Can be guaranteed.
  • FIGS. 14 (a) and 14 (b) are diagrams showing examples in which Suspend is significant.
  • Fig. 14 (b) there are three titles (title # l, title # 2, title # 3), of which title # l and title # 3 execute the game app, but Title # 2 is a side path, which realizes video playback. In the side pass, it is necessary to realize video playback, which interrupts game execution. In the game app, scores in the middle are counted, so we want to keep the stored value of resources before and after title # 2.
  • the application management table is described to suspend the game application at the start of title # 2 and resume application # 2 at the start of title # 3.
  • the resource value is maintained for application # 2 in title # 2 because the resource is allocated.
  • application # 2 is not executed by the virtual machine because the CPU is not allocated. As a result, a process of executing a side pass during the execution of the game title is realized.
  • FIG. 15 is a diagram showing combinations of three possible modes of the startup attribute (Persistent, AutoRun, Suspend) and three modes of the application state in the immediately before title (non-starting, running, and Suspend). If the last state is “not started”, and the start attribute is "AutoRun”, the application will be started at the branch target title. If the last state is "not started” and the start attribute is "Persistent”"Suspend", the application does nothing and continues the state at the branch target title.
  • the launch attribute is "Suspend”
  • the state of the application will be suspended. If the previous 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.
  • FIG. 16 is a diagram showing the internal configuration of the playback device according to the present invention.
  • the playback device according to the present invention is industrially produced based on the interior shown in the drawing.
  • the playback device according to the present invention mainly includes two parts, a system LSI and a drive device, and can be industrially produced by mounting these parts on a cabinet and a substrate of the device.
  • a system LSI is an integrated circuit that integrates various processing units that perform the functions of a playback device.
  • the playback devices produced in this way include a BD-ROM drive 1, 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, synthesis unit 16, HDD 17, lead buffer 18, demultiplexer 19, audio decoder 20, scenario memory 21 , CPU 22, key event processing section 23, instruction ROM 24, switch 25, 01 ⁇ 1 section 26, CLUT section 27, PSR set 28, oral memory 29.
  • the BD-ROM drive 1 performs loading Z ejection of the BD-ROM and accesses the BD-ROM.
  • 15330 Read buffer 2 is a FIFO memory, which stores the TS data read from the BD-ROM. The packet is stored on a first-in first-out basis.
  • the demultiplexer (De-MUX) 3 extracts a TS bucket from the read buffer 2 and converts the TS bucket constituting the TS bucket into a PES packet. Then, among the PES packets obtained by the conversion, those set by the CPU 22: those having a PID are transferred to any of the video decoder 4, the audio decoder 20, the P-Graphics decoder 9, and the 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 apparatus, and the stored contents of these planes are added for each pixel and video output is performed, the video output can be performed after combining the video content.
  • the resolution in the video plane 5 is 1920 ⁇ 1080, and the picture data stored in the video plane 5 is constituted by pixel data represented by a 16-bit YUV value.
  • the P-Graphics decoder 9 decodes the presentation graphics stream read from the BD_ROM and HDD 17 and writes the uncompressed graphics to the Presentation Graphics plane 10. Subtitles appear on the screen due to the decoding of the graphics stream.
  • the Presentation Graphics plane 10 is a memory having an area for one screen, and can store uncompressed graphics for one screen.
  • the resolution in this plane is 1920 x 1080, and each pixel of uncompressed graphics in the Presentation Graphics plane 10 is represented by an 8-bit index color.
  • CLUT Color Lookup Table
  • the synthesizing unit 11 synthesizes the uncompressed picture data (i) with the contents stored in the Presentation Graphics plane 10.
  • Font generators 12 included in the textST stream using character fonts Expand the text code to be converted to a bitmap.
  • the I-Graphics decoder 13 decodes the interactive graphics stream read from the BD-ROM or the HDD 17 and inserts uncompressed graphics into the Interactive Graphics plane 15.
  • the switch 14 is a switch for selectively writing any one of the font sequence generated by the font generator 12 and the graphics obtained by decoding by the P-Graphics decoder 9 to the Presentation Graphics plane 10.
  • the non-compressed graphics obtained by decoding by the I'Graphics decoder 13 is written in the Interactive Graphics plane 15.
  • the synthesizing unit 16 synthesizes the contents stored in the Interactive Graphics plane 10 with the synthesized image (uncompressed picture data and the contents stored in the Presentation Graphics plane 7) output from the synthesizing unit 8. Combine.
  • the HDD 17 is a built-in medium that stores 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 a full path. This is because the HDD 17 is integrated with the BD-ROM and is recognized by the playback device as one virtual drive (called a virtual package). Therefore, 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 ROM can be specified. By reading the recorded contents of the HDD and dynamically combining it with the recorded contents of the BD-ROM, various reproduction variations can be produced.
  • the read buffer 18 is a FIFO memory in which TS packets read from the HDD 17 are stored in a first-in first-out manner.
  • a demultiplexer (De-MUX) 19 extracts a TS packet from the read buffer 18 and converts the TS bucket into a PES bucket. Then, among the PES packets obtained by the conversion, those having a desired streamPID are converted to a font generator 1 Output to 2.
  • 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 current PL information and current clip information.
  • the current PL information refers to the current PL to be processed among the multiple PL information recorded on the BD-ROM.
  • the current Clip information refers to the information currently being processed from among the multiple Clip information recorded on the BD-ROM.
  • the CPU 22 executes the 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 a key 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.
  • the switch 25 is a switch for selectively inputting various data read from the BD-ROM and the HDD 17 to any of the read buffer 2, the read buffer 18, the scenario memory 21 and the local memory 29. is there.
  • the CLUT unit 26 converts the index colors in the uncompressed graphics stored in the video plane 5 into Y, Cr, and Cb values.
  • the GLUT unit 27 converts the index color in the uncompressed Dallax stored in the Interactive Graphics plane 15 into Y, Cr, Cb values.
  • PSR4 indicates the title to which the current playback point belongs by being set to a value from 1 to: 100, and indicates that the current playback point is the top menu by being set to 0.
  • PSR5 when set to a value from 1 to 999, indicates the number of the chapter to which the current playback point belongs, and when set to OxFFFF, indicates that the chapter number is invalid in the playback device.
  • PSR6 when set to a value from 0 to 999, indicates the number of the PL (current PL) to which the current playback point belongs.
  • PSR7 when set to a value of 0 to 255, indicates the number of the PlayItem (current PlayItem) to which the current playback point belongs.
  • PSR8 is set to a value from 0 to OxFFFFFF to indicate the current playback point (current PTM (Presentation TiMe)) using a time accuracy of 45 KHz.
  • the current playback point is specified by the above PSR4 to PSR8.
  • FIG. 17 (a) is a diagram showing how the Java archive file existing on the BD-ROM is identified on the oral 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 to use the file path in the local memory 29.
  • the local memory 29 uses a part of the file path in the BD-ROM that is omitted for the file path. The location on the BD-ROM can be clarified.
  • the hardware configuration of the playback device according to the present embodiment has been described above. Next, the software configuration of the playback device according to the present embodiment will be described.
  • Fig. 18 is a diagram in which the software and hardware components stored in the OM 24 are replaced with a layer configuration.
  • the layer configuration of the playback device is composed of the following a), b), c), d-l), d-2), e), and £>. That is,
  • Playback Control Engine 32 which performs playback control based on playlist information and Clip information
  • the HDMV module 33 which is the subject of d-l) decryption and execution of Movie objects
  • the BD-J module 35 which performs d-2) decryption and execution of BD-J objects, are located in the same hierarchy.
  • the BD-J module 35 is a so-called Java platform, and has a configuration centered on a Java virtual machine 38 including a work memory 37, and includes an application manager 36, an event listener manager 39, It consists of Default Operation Manager 40.
  • FIG. 19 is a diagram schematically illustrating processing performed 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 03 ⁇ 4), Release of Still function (still of £), Fast forward with speed specification (Forward Play (speed)), Rewind with speed specification (Backward Play (speed)), Audio switching (Audio Change), It is a function called Subtitle Change (Angle Change).
  • the Presentation Engine 31 decodes the video decoder 4, P-Graphics decoder 9, and I-Video so as to decode the part corresponding to the desired time in the AVClip read on the read buffer 2. Controls the graphics decoder 13 and audio decoder 20. By decoding the part indicated by PSR8 (Power PTM) as the desired time, it is possible to reproduce any 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, the playback start and playback stop 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.
  • the playback control engine 32 executes its own function in response to an instruction from a user operation or an instruction from a higher layer in the layer model.
  • arrows marked with ⁇ 2 and ⁇ 3 schematically indicate the reference of the Playback Control Engine 32 to the Clip information and the playlist information.
  • the HDMV module 33 is the execution entity of the MOVIE mode.
  • a Movie object constituting a branch destination is notified from the module manager 34, the Movie object constituting the branch destination title is transferred to the oral memory 2.
  • 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 control engine 3
  • the function call (4) for 2 is schematically shown.
  • the module manager 34 holds the Index Table read from the BD-ROM and performs branch control.
  • the branch control receives the title number of the jump destination, This is to notify the HDMV module 33 or the BD-J module 35 of the Movie object or BD-J object that constitutes the evening.
  • Arrows marked with V0, ⁇ 1, and V2 in the figure schematically indicate execution of the JumpTitle command (0), reference of the IndexTable by the module manager 34 (1), and notification of the branch destination Movie object (2). ing.
  • FIG. 20 is a diagram showing the application manager 36.
  • the application manager 36 controls the start of the application with reference to the application management table and the control when the title ends normally.
  • Start control means that every time a BD-J object to be a branch destination 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.
  • the control is to read the xlet program that constitutes the application whose live period is the current playback point into the work memory.
  • ⁇ 1,- ⁇ 2, ⁇ 3 in Fig. 20 represent the notification of the branch destination BD-J object in the start control (1), refer to the application management table (2), and the start instruction to the Java virtual machine 38. Shown.
  • the Java virtual machine 38 reads the xlet program from the local memory 29 to the work memory 37 (5).
  • Title end control includes control for normal termination and control for abnormal termination.
  • the control at the time of normal termination is a control in which a jump title API is called by an application constituting a title, and a request is issued to a branch control entity (module manager 34) to switch to a branch destination title. is there.
  • 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. This is because whether to terminate the application is determined by the branch destination title.
  • the application manager 36 performs a process of reading a Java archive file from the BD ROM to the local memory 29 (8). 8 schematically illustrates the reading to the local memory 29.
  • the work memory 37 is a heap area in which xlet programs constituting the application are located.
  • 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 let program that constitutes the application into the private memory 37, decrypts the xlet program, and performs processing in accordance with the decryption result.
  • JP2004 / 015330 Execute.
  • 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.Therefore, control for the lower layer is performed so as to realize the processing contents instructed by these methods. I do. If a JMF player instance creation is ordered, the Java virtual machine 38 obtains a JMF player instance associated with the YYYY.MPLS file on the BD-ROM.
  • this JMF method is issued to the BD middleware, 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.
  • the Event Listner Manager 39 analyzes events (key events) generated by user operations and sorts the events.
  • a key event such as START, STOP, or SPEED
  • START, STOP, or SPEED is registered in the Event Listner in the xlet program
  • STAET, STOP, and SPEED are events corresponding to JMF. Since these key events are registered in the Event Listner of the xlet program, this key event enables the xlet program to be started.
  • the key event is a non-registered Event Listner event, this key event is distributed to Default Operation Manager 40.
  • the Default Operation Manager 40 sends a function call corresponding to the Event Listner unregistered event to the Playback Control Engine when an event not registered in the Event Listner in the xlet program is sorted from the Event Listner Manager 39. 3 Execute for 2.
  • the arrow ⁇ 3 in the figure schematically shows the function call by the Default Operation Manager 40.
  • Event Listner unregistered events are sorted by Event Listner Manager 39 and Default Operation Manager 40, but Playback Control Engine 32 directly registers Event Listner unregistered events. Receiving and playback control may be performed ( ⁇ in the figure).
  • FIG. 22 is a diagram showing a control procedure at the time of branching by the application manager 36.
  • an application (referred to as application X) that satisfies the conditions of steps S2 to S5 is started or terminated.
  • -Step S2 is a determination as to whether or not the application X with the AutoRun attribute, which is not started at the branch source title but is alive at the branch destination title and whose startup attribute at the branch destination title is AutoRun, exists.
  • 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 work memory 37 (step S8). If it is not in the oral 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 oral memory 29 into the work memory 37 (step S9).
  • step S3 it is determined whether or not there is a non-existent abbreviated X in the branch destination title, which is activated in the branch source title. If it exists, the application case X is deleted from the work memory 37 and the process is terminated (step S10). In step S4, it is determined whether there is a branch source Suspend, a branch destination AutoRun, or a persistent application. If it exists, Resume Application X (Step S11).
  • step S5 it is determined whether or not the application of the branch destination Suspend is being activated in the branch source title. If it exists, the application X is suspended (step S12).
  • FIG. Figure 23 shows the application termination process. It is a flowchart which shows the processing procedure of a process. 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 terminated (step S15).
  • the application manager 36 issues a terminate event for terminating the running application (step S16), sets a timer (step S17), and proceeds from step S18 to step S2. Move to the loop process consisting of 0.
  • the Event Listner receives this terminate event, the corresponding xlet program starts the termination process.
  • the let program is released from work memory 37 and ends.
  • step S18 is
  • step S19 it is determined whether or not the timer has timed out. If timed out, in step S20, the application to be issued is deleted from the work memory 37, and the application is forcibly terminated.
  • FIG. 24 is a diagram schematically showing a process of terminating the application.
  • the first level shows the application manager 36
  • the second level 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 to terminate.
  • the application on the right shows an application that could not receive a terminate event because EventListner was not implemented.
  • the arrows epl and ep2 between the first and second stages 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 is the state after the state transition when the termination process is successful, and this abridgement will be terminated by its own termination process. If there are applications such as these xlet programs that do not end within a predetermined period, 4 015330 The location manager 36 forcibly removes them from the work memory 37.
  • the fourth row shows the forced termination by the application manager 36. It is one of the missions of the Application Manager 36 to specify the forced termination in the fourth stage.
  • an application that is started at the branch source title and is not alive at the branch destination title is automatically terminated. Even if it progresses, the number of applications that exceed the resource limit of the playback device will not be launched. Since the application operation before and after branching can be guaranteed, it is possible to distribute a large amount of disk contents for executing an application while reproducing a digital stream.
  • FIG. 25 (a) is a diagram showing an application management table in which a live range is defined on the PL time axis.
  • Fig. 25 (a) three applications are described in the application case management table.
  • application # 2 is the live range from Chapter # 2 to Chapter # 3 of title # l.
  • AutoRun is specified in the startup attribute. Therefore, application # 2 is started at the start point of Chaptei # 2 and ends at the end point of Chapter # 3, as shown in Fig. 25 (b).
  • the application manager 36 In order to perform processing based on the application management table described in this manner, the application manager 36 according to the present embodiment starts a live range from the start point of the chapter each time the point reaches the start point of the chapter specified by PLmark. It is determined whether or not an application exists, and if so, the application is loaded into the work memory 37.
  • the life span of the application can be specified with finer precision.
  • disc content can have a reverse time axis. Retrograde means that the time axis advances in the reverse direction by rewinding. If this reversal and progress are repeated at chapter boundaries, the work memory will be loaded and discarded many times, resulting in extra read load. Therefore, in the present embodiment, the application is started at the moment when normal playback by the Playback Control Engine 3 starts after entering the title.
  • PL playback includes normal playback and trick playback.
  • the trick playback includes fast forward, rewind, SkipNext, and SkipBack.
  • the application is not started, and the application is started only after the normal reproduction is started. Normally, based on the moment of the start of reproduction, even if there is a crossing before and after the life cycle as described above, the application startup will not be repeated more than necessary. It should be noted that the process of setting the moment of normal reproduction start as the reference for starting the application may be executed even when the live range is title.
  • the live range of the abridgement 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 a conflict between resource usage among applications, which application is forcibly terminated, and which application takes the resource When the application manager 36 performs the process described above, it becomes a source of judgment.
  • application # l has a priority of 255
  • application # 2 has a priority of 128.
  • the application manager 36 performs the process of forcibly terminating the application # 2 with a low priority.
  • the disc content provided by the BD-ROM is composed of multiple titles that can branch off from each other. Each title is composed of one or more PLs and a control procedure using the PL. In addition to the titles, there are non-AV-type titles consisting only of control procedures for the playback device. In the present embodiment, this non-AV title will be described.
  • Figure 26 (a) shows the title time axis determined from the PL time axis.
  • 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 determined 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 that has the startup attribute set to AutoRun in the title and is automatically started when the title starts.
  • this is a launcher application.
  • a launcher application is an application program that launches another application.
  • Figure 26 (b) is that the title time axis is assumed to be continuous as long as the main application is running, and the time axis is terminated when the main application ends.
  • Figure 26 (c) is a diagram showing the title time axis determined from the life cycle of multiple applications. One application is started at the start of the title, but this application calls another application, and this application calls another application, and the process is repeated. There are cases. In this case, the title time axis is considered to be continuous as long as any application is running, and the title time axis is terminated when a state where no application is started arrives. is there.
  • the process of branching to the specified title at the end of the title time axis regardless of whether it is an AV title or a non-AV title can be performed uniformly.
  • the title time axis for non-AV titles is assumed to be imaginary for comparison with AV titles. 0 Just the time axis. Therefore, the playback device cannot go backward on the title time axis in a non-AV title or search for an arbitrary position.
  • FIG. 27 is a flowchart showing the processing procedure of the application manager 36 during title playback. This flowchart has a loop structure in which steps S21 to S23 are repeated during title playback.
  • Step S21 is a determination as to whether or not the title jump API has been called. If called, a request is made to the module manager 34 to branch to the jump destination title (step S27). ,
  • Step S22 is a determination as to whether or not there is a main application that is responsible for calling the application in the title, and if so, confirms whether it has been started (step S25). ). If it has not been started, it is interpreted as "end of title", and the end is notified to module manager 34 (step S26).
  • Step S23 is a step executed when there is no main application (No in step S22), and it is determined whether or not any application is running. If so, it also interprets it as "end of title” and notifies module manager 34 of the end (step S26).
  • FIG. 28 (a) is a diagram showing a menu hierarchy realized by the BD-ROM.
  • the menu hierarchy in this figure has a structure in which TbpMenu is placed at the top level, and lower-level TitleMenu, SubTitleMenu, and AudioMenu can be selected from this IbpMenu.
  • Arrows swl, 2, and 3 in the figure schematically show menu switching by button selection.
  • TopMenu is used to select audio, subtitle, or title. This is a menu with buttons (buttons snl, sn2, and sn3 in the figure) that accept whether or not they are displayed.
  • the TitleMenu is a menu with buttons that accept the selection of a movie, such as selecting the movie version of the movie (title), selecting the director's cut version, selecting the game version, etc. .
  • AudioMenu is a menu with buttons to accept audio playback in Japanese or English.
  • SubTitleMenu is a menu with buttons to accept subtitles in Japanese or English. It is.
  • Figure 28 (b) shows the MOVIE object for operating a menu having such a hierarchy.
  • MovieObject.bdmv stores FirstPlay OBJ, TbpMenu OBJ, AudioMenu OBJ, and SubTitleMenu OBJ.
  • the FirstPlay object (FirstPlay OBJ) is a dynamic scenario that is automatically executed when loading a BD-ROM to a playback device.
  • the TbpMenu 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 TbpMenu in response to user operations and branch commands that branch in response to button operations. This branch command realizes menu switching from TopMenu to TitleMenu. TopMenu to SubTitleMenu and TopMenu to AudioMenu.
  • the AudioMenu object (AudioMenu OBJ) is a dynamic scenario that controls the behavior of the AudioMenu. Commands that change the state of the buttons in the AudioMenu according to the operation of the user, and audio settings according to the final operation of the button. Contains the command to be updated. '
  • the SubTitleMenu object (SubTitleMenu OBJ) is a dynamic scenario that controls the behavior of the SubTitleMenu. It is a command that changes the state of the buttons in the SubTitleMenu according to the user's operation. Contains the command to update the PSR.
  • the TitleMenu object (TitleMenu OBJ) is a dynamic scenario that controls the behavior of the itleMenu, and includes the one that changes the state of the buttons in the itleMenu and the branch command that branches in response to the decision operation on the button.
  • the above is the MOVIE object related to menu control.
  • FIG. 29 is a diagram schematically illustrating an Index Table and branching 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 FirstPLayINDEX, TopMenuINDEX, Audio MenuINDEX, Subtitle MenuINDEX, title MenuINDEX. Title # l to #mINDEX, title # m + l to #nINDEX, and title # 0INDEX.
  • FirstPLaylNDEX, TopMenuINDEX, Audio MenuINDEX, Subtitle MenuINDEX, title MenuINDEX are indexes for FirstPLayOBJ, IbpMenuOBJ, 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, such as ⁇ and m.
  • An identifier (ID) is described.
  • title # m + l to #nINDEX is the index of the title entered from the m + 1 to nth entry on the BD-ROM, and becomes the branch destination when selecting the title numbers from m + 1 to n
  • the identifier (ID) of the BD-J object is described.
  • the title # 0 INDEX is an INDEX that specifies a Movie object or a BD-J object to be a branch destination at the time of forced termination of a BD-J object.
  • the identifier of TopMenuOBJ is stored in title # 0INDEX.
  • FIG. 30 (a) shows a branch when the Index Table is described as shown in FIG. Since the Index Table is described in this way, when executing a branch command with the label title # l to title # m as the branch destination, the identifier of the Movie object #l to #m is obtained from title # llndex to titie # mlndex. Taken out. Label title # m + l ⁇ title # n When the branch command is executed with the branch 15330, the identifiers of the BD-J objects # m + l to #n are extracted from title # m + llndex to title # nlndex.
  • BD-J objects # m + l to #n are five-digit numbers that represent file names, r00001.BD-J, 00002.BD-J, 00003.BD-J It is fetched and the dynamic scenario with that file name is read out to 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 of the 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 in the present embodiment will be described.
  • the module manager 34 in the playback device performs processing according to a processing procedure as 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. It is.
  • Step S31 is for judging whether or not the title jump A ⁇ I has been called. If there is a call to the title jump API, the title number] 'that is the 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) The HDMV module 33 or BD-J module 35 executes the Movie object or BD-J object of IDj (step S35).
  • step S32 it is determined whether or not the end of the title has been notified from the application manager 36. If the end has been notified (Yes in step S32), the top menu OBJ constituting the top menu title is changed to the HDMV module. 33 or the module manager 34 is executed (step S36).
  • the above-mentioned application manager 36 An example is described with reference to FIG.
  • the titles to be played here are non-AV titles, including game apps that stack falling tile pieces.
  • the lower part of Fig. 32 shows the title time axis consisting of the live range of the application, and the upper part shows the image displayed on the title time axis.
  • the non-AV title is a game app
  • one screen of the game app is displayed as shown in the upper left of Fig. 32 in the life cycle of this game app.
  • the application manager 36 forcibly terminates the game application according to the flowchart of FIG. 23 and notifies the module manager 34 of the end of the title. When the end of the title is notified, the module manager 34 branches to the top menu title.
  • Playback Control Engine 3 executes the processing procedure based on the PL information when the PL playback API is called. If the PL has a playback time of 2 hours, the above process will continue during these 2 hours. What matters here is a gap between the time when the Java virtual machine 38 returns a success response and the time when the Playback Control Engine 32 actually finishes processing. Since the Java virtual machine 38 is an event-driven processing subject, it returns a response indicating success or failure of playback immediately after the call, but the actual processing by Playback Control Engine 32 ends after 2 hours. 5330
  • Playback Control Engine 32 Since Playback Control Engine 32 operates standalone with the application, the end determination as in the third embodiment cannot interpret the end of PL playback as the end of title. Therefore, in this embodiment, whether or not the application is terminated, as long as the work memory 37 has JMF player instance, that is, the BD-J module 35 takes control of the Presentation Engine 31. While waiting, it waits for a playback end event from Playback Control Engine 32. If there is a reproduction end event, it interprets that the title is over and notifies module manager 34 to branch to the next title. By doing so, the point at which the Playback Control Engine 32 ends PL playback can be the end of the title.
  • FIG. 33 is a flowchart showing a PL playback procedure by the Playback Control Engine 32.
  • This playback procedure mainly includes control for the Presentation Engine 31 (step S46) and control for the BD-ROM drive 1 or the HDD 17 (step S48).
  • the Playltem to be processed is Playltem # x.
  • the current PL information (.mpls) is read (step S41), and then the processing of steps S42 to S50 is executed.
  • Step S42 to Step S50 are a loop in which the processing of Step S43 to Step S50 is repeated for each PI information constituting the current PL information until Step S49 becomes Yes. Make up the process.
  • PlayItem # x The Playltem to be processed in this loop processing is called PlayItem # x (PI # x).
  • This Playltem # x is initialized by being set to the first Playltem of the current PL (step S42).
  • the termination requirement of the loop processing described above is that this Playltem # 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 the Playltem # into the scenario memory 21 (Step S43), and execute the In- of the Playltem # x.
  • the time is converted into an I picture address u using the EPmap of the current Clip information (step S44), and the Out-time of Playltem # x is converted to the 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, and set one address before that to the address w (Step S47), and so on.
  • the BD-ROM drive 1 or the HDD 17 is instructed to read the TS packet from the I picture address u to the address w (step S48).
  • the presentation engine 31 is instructed to output from mark_time_stam of the current PLMark to Out_time of Playltem # x (step S46).
  • the presentation engine 31 is instructed to output from mark_time_stam of the current PLMark to Out_time of Playltem # x (step S46).
  • Playltem # x is the last PI of the current PL (step S49).
  • step S50 the next Playltem in the current PL is set to Playltem # x (step S50), and the process returns to step S43.
  • step S43 the PIs constituting the PL are sequentially reproduced.
  • FIG. 34 is a flow chart showing the angle switching procedure and the SkipBack and SkipNext procedures. This flowchart is performed in parallel with the processing procedure of FIG. 33, and repeats a loop process including steps S51 to S52. Step S51 in this loop is to determine whether or not the API for requesting angle switching has been called from the Java virtual machine 38. If there is a call for the angle switching API, the current Clip information is switched. Perform the operation.
  • Step S55 in FIG. 34 is a determination step, which determines whether is-multi-angles of Playltem # x is on. is— multi— angles is A flag indicating whether Playltem # x supports multi-angle, and if step S55 is No, the process moves to step S53. If step S55 is Yes, execute steps S56 to S59. In steps S56 to S59, the angle number after the switching is substituted for the variable y (step S56), and the y-th Clip in Playltem # x—the Clip information specified by information_file_nanie is stored in the scenario memory.
  • Step S57 Read out to 1 (Step S57), convert the current PTM into I picture address u using EP-map of current Clip information (Step S58), and convert Playjim # x Outjime to current Clip
  • the information is converted to an I-picture address V using the EP-map of the information (step S59).
  • step S46 By shifting to step S46, the TS bucket is read from another AVClip, so that the video content is switched.
  • step S52 in the loop of FIG. 34 is a determination as to whether an API meaning SkipBack / SkipNext has been called from the Java virtual machine 38, and if called, the process of FIG.
  • the processing procedure of the flowchart is executed.
  • FIG. 35 is a flowchart showing a processing procedure when the SkipBack, SkipNext API is called.
  • the processing procedures for executing SkipBack and SkipNext are various. It is to be noted that the description here is only an example.
  • step S61 the current Mark information is obtained by converting the current PI number indicated by the PSR and the current PTM.
  • step S62 it is determined whether the pressed key is the SkipNext key or the SkipBack key. If the pressed key is the SkipNext key, the direction flag is set to +1 in step S63, and the SkipBack key is pressed. If there is, in step S64, the direction flag is set to -1.
  • step S65 the number obtained by adding the value of the direction flag to the number of the current PLMark is set as the number of the current PLMark. If the key is a SkipNext key, the direction flag is set to +1 and the current PLMark is incremented. If the key is a SkipBack key, the direction flag is set to -1, so the current PLMark will be decremented.
  • step S66 the PI described in the ref—to—Playltem—Id of the current PLMark is set to Playltem #, and in step S67, the PI of Playltem # x is set.
  • mark_time_stamp of the current PLMark is converted to an I picture address u using the EP-map of the current Clip information.
  • Outjime of Playltem # x is converted into I-picture address V using the EP-map of the current Clip information.
  • step S70 the output from the current PLMark to the mark—time—stamp and the Playltein # x to the Out—time is instructed to the Presentation Engine 31, and then the flow proceeds to step S47 in FIG. I do. In this way, the I-picture addresses u and v are changed, and the reproduction of another part is ordered. Then, the process proceeds to step S47, so that the TS bucket is read from another AVClip, and the video content is switched. Is realized.
  • -FIG. 36 is a flowchart showing details of the processing procedure by Presentation Engine 31. In this flowchart, after the PTS of the I picture is set to the current PTM (step S71), a loop process including steps S72 to S77 is executed.
  • Step S76 in this loop processing defines the requirements for terminating the loop processing. That is, in step S76, the current PTM is the Out-time of PI # x, which is a requirement for terminating the loop processing.
  • Step S73 is to determine whether the fast forward API or the fast reverse API has been called from the Java virtual machine 38. If a call is made, it is determined in step S78 whether fast-forward or fast-reverse, and if fast-forward, the PTS of the next I-picture is set to the current PTM (step S79).
  • the AVClip By setting the current PTM to the PTS of the next I-picture, the AVClip can be played every second. As a result, the AVClip is played back in the forward direction at a double speed or the like. If it is fast reverse, it is determined whether or not the current PTM has reached 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). By setting the read destination address A to the immediately preceding I picture in this way, the AVClip can be played back one second at a time in the backward direction. This allows the AVClip to be played in the reverse direction at 2x speed, etc. Will be.
  • the processing procedures for executing fast-forward and rewind are various. It should be noted that the explanation here 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). According to the above processing, when a menu menu call is made, the processing for menu display is executed after the reproduction processing is interrupted.
  • step S75 it is determined whether or not SubPlayItem # y specifying Playltem # exists according to sync-Playltem_id. If there is, the process proceeds to the flowchart of FIG. FIG. 37 is a flowchart showing the playback procedure of SubPlayltem.
  • step S86 it is determined whether or not the current PTM is sync-start-PTS_of_j) layIteni of SubPlayItem # y. If so, in step S93, the playback control engine 32 is notified to perform the playback process based on SubPlayItem # y.
  • Steps S87 to S92 of FIG. 37 are flowcharts showing a reproduction process based on SubPlayItem # y.
  • step S87 the Clip information specified by Clip—information—file—name of SubPlayItem # y is read.
  • step S88 the In-time of SubPlayItem # y is converted into an address using the EP-map of the current Clip information.
  • step S89 the Outjime of SubPlayItem # is converted into an address using the EP_map of the current Clip information.
  • a step S90 instructs the decoder to output from In-time of SubPlayItem # y to Out-time of SubPlayItem # y.
  • step S91 The next I-picture of address 13 obtained by these conversions is obtained, and one immediately before that address is set to address y (step S91), and 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 a to the address # in the SubClip #z (step S92).
  • step S92 the description of the processing of the Playback Control Engine 32 will be continued.
  • step S53 it is determined whether or not the playback control by the Presentation Engine 31 has been completed, and the processing of the flowchart in FIG. 36 is performed on the last Playltem # x. As long as there is, step S53 becomes No. Only after the processing of the flowchart of FIG. 36 is completed is step S53 Yes and the operation moves to step S54.
  • Step S54 is the output of the reproduction end event to the Java virtual machine 38. From this output, the Java virtual machine 38 can 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 a modification of the flowchart of FIG. The improvement is that step S2 4 is added between step S2 1 and step S2 2, and when this step S2 4 becomes Yes, there is a step S101 to be executed. .
  • Step S24 is for determining whether or not the JMF player instance exists in the work memory 37. If not, the process proceeds to step S22. If there is, go to step S101. Step S101 is a determination as to whether or not the 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 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.
  • steps S22 and S23 are skipped as long as the JMF player instance exists in the work memory 37 (Yes in step S24). Therefore, the title is interpreted as ongoing even if all applications are terminated.
  • the application manager 36 can know the lapse of the playback time of 2 hours, the menu is displayed as the PL playback end condition, and the operation for this menu is performed.
  • the control of branching to another title can be realized in accordance with.
  • 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 showing the Java archive files to be loaded on the local memory 29 on the title time axis in association with the read attribute and the read priority.
  • "Survival in the oral memory 29" means that the Java archive file constituting the application is read from the local memory 29 and can be transferred to the work memory 37 in the 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
  • the data management table also has the same concept of a live range. At first glance, it seems wasteful to have the same concept as the application management table in the data management table, but this is intentional.
  • FIG. 40 is a diagram illustrating an execution model assumed by a BD-J object.
  • the execution model in this figure is composed of a BD-ROM, a local memory 29, and a Java virtual machine 38, and shows a relationship between the BD-ROM, the local memory 29, and the work memory 37.
  • Arrow myl indicates reading between BD_ROM and local memory 29, and arrow my2 indicates reading between 'local memory 29 and work memory 37'.
  • the annotations above the arrows indicate when these readings occur.
  • reading between the BD-ROM and the local memory 29 is a so-called "look-ahead" and must be done before the application is needed.
  • the reading from the local memory 29 to the work memory 37 is performed when the application is needed.
  • “When needed” means the point in time when the life span of the application has arrived (1), and the point in time when the application is instructed by another application or the application manager 36 (2).
  • the arrow my3 indicates the release of the application occupied area in the work memory 37
  • the arrow my4 indicates the release of the application occupied area in the local memory 29.
  • P2004 / 015330 Indicates release.
  • the annotations on the arrows indicate when these readings occur.
  • the release on the work memory 37 is performed at the same time as the termination of the application.
  • the release on the local memory 29 is performed when it is no longer necessary for the Java virtual machine 38. The point where this is no longer needed is not the "end point". It means "when it is finished and there is no possibility of restarting", that is, when the corresponding title is finished.
  • the release point in the work memory 37 is known from the live range in the application management table.
  • the disc content to be produced here consists of three titles (title # l, title # 2, title # 3). In the time axis of these titles, at the timing shown in Fig. 41 (b), You want to use local memory 29. In this case, at the start of the title # l time axis, read the Java files that constitute application # l and application # 2 into the local memory 29, and continue the title # l time axis, application # l, application # 2 is resident in local memory 29.
  • the Java archive file that constitutes application # l is released from the oral memory 2 9, and the Java file that constitutes application # 3 is released instead of the oral memory 2 9 And make it resident (hereafter, the Java archive files that make up the application are treated the same as the application).
  • the description of the data management table in this case is as shown in Fig. 41 (a), and the application ID of the application is associated with its life cycle. 04 015330 By describing, the application to be resident in the local memory 29 is expressed.
  • the live range specified in the application management table be a fine playback unit and that the live range specified in the data management table be a coarse playback unit.
  • Non-seamless playback units such as titles and PLs are desirable for rough playback units.
  • a seamless playback unit such as a chapter in a PL is desirable. If the lifespan of the application is determined for each title and for each PL, the application exists in the oral memory 29, and the application can be taken out at any time during the playback of the title. In that case, even if the life span of the application is finely defined, the application can be immediately read out to the work memory on the virtual machine, so even if the application is started and terminated frequently. Thus, it is possible to realize smooth application execution.
  • the Java archive file was recorded in a different recording area from the AVClip. But this is only an example.
  • the Java archive file may be embedded in the recording area occupied by the AVClip on the BD-ROM.
  • FIG. 42 is a diagram showing the embedding of a Java archive file by carouselization.
  • the first row is a Java archive file embedded in AVClip, and the second row shows sectioning. You.
  • the third row shows the TS bucketing, and the fourth row shows the TS bucket sequence forming the AVClip.
  • the sectioned and TS bucketed data (“D" in the figure) is embedded in AVCli.
  • FIG 43 is a diagram showing embedding of Java archive files by interleaving. The first row is the AVClip to be embedded, the second row is the Java archive file integrated into the AVClip, and the third row is the AVClip arrangement in the recording area of the BD-ROM. .
  • the Java archive file to be embedded in the stream is interleaved and recorded between the divided parts (AVClip2 / 4, 3/4 in the figure) that constitute XXXXX.m2ts that constitute AVClip.
  • You. Java archive files multiplexed on AVClip by interleaving will be read out at a higher bandwidth than in the case of powerful celling. Because of this high bandwidth reading, the playback device reads the Java archive file in a relatively short time.
  • Carcelled 'Interleaved Java archive files are not pre-spoken.
  • the current playback time reaches the part where the carousel-interleaved Java archive file is embedded, it is loaded into the local memory 29 of the playback device. .
  • the recording format of the Java archive file there are those shown in Fig. 42 and Fig. 43 (a) in addition to those shown in Fig. 2, so the read attribute is set as shown in Fig. 43 (b). Can be done.
  • the read attribute is "Preload” indicating that it is read into the oral memory 29 prior to the title playback, and that the read attribute is read in the carousel format during title playback.
  • FIG. 44 (a) shows an example of the data management table. 2004/015330.
  • FIG. 44 (b) is a diagram showing a change in the storage content of the local memory 29 due to the assignment of the data management table.
  • the occupied area in the local memory 29 is shown on the vertical axis, and the horizontal axis is the PL time axis in one title.
  • application # l is described so that the entire PL time axis in one title is a live range, so in Chapter # l to Captei # 5 of this title, the local memory 29 Area.
  • the read priority is a priority that determines the priority of reading to the local memory 29.
  • the read priority has a plurality of values. To set two levels of priority, set the value indicating Mandatory and the value indicating optional as the read priority.
  • Mandatory means higher read priority and optional means lower read priority.
  • To set three levels of priority set the value indicating Mandatory, the value indicating optional: high, and the value indicating optional: low as the read priority.
  • Mandatory indicates the highest read priority, optional: high indicates a medium read priority, and optional: low indicates the lowest read priority.
  • FIGS. 45 (a) and (b) the assumed memory size of the local memory 29 is as shown in FIG. 45 (a).
  • FIG. 45 (a) is a diagram showing the memory size of the oral memory 29 in the old and new playback devices in comparison.
  • Arrow mkl indicates the memory size of the old playback device
  • arrow mk2 indicates the memory size of the new playback device. From the comparison of the arrows, it is assumed that the memory size of the local memory 29 in the new playback device is three times or more that of the old playback device. This way If there is a variation in the size of the memory, the applications are divided into two groups as shown in Figure 45. The first is an application (# 1, # 2) that should be read regardless of the memory size. The second is the application (# 3, # 4) that does not want to be read by the old playback device but is desired to be read by the new playback device.
  • FIG. 45 (b) shows 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.
  • the data management table for the title to be played is read (step S111), and the application having the lowest application ID with the highest read priority in the data management table is set to application i (step S111).
  • step S111 the application having the lowest application ID with the highest read priority in the data management table is set to application i (step S111).
  • the loop processing is repeated until 6 is determined as No and Step S 1 17 is determined as No.
  • Step S116 of the two steps for defining the end requirement of the loop processing determines whether or not the application k having the next highest application ID and the same read priority as application i exists. is there. If such an application k exists, make the application k an application i (step
  • Step S117 of the two steps for defining the requirement for terminating the loop processing is to determine whether or not there is an application having the next lowest read priority in the data management table.
  • the application k with the lowest applicationID among the applications having the next lowest read priority is selected (step S118), and the application k is set as application i (step S119).
  • steps S116 and S117 are set to Yes, the above-mentioned processing of steps S113 to S115 is repeated.
  • steps S116 and S117 if there is no corresponding application, the processing of this flowchart ends.
  • step S120 it is determined whether or not there is an application having the same application ID and a high read priority; j.
  • Step S122 is a step of determining whether or not the remaining capacity of the oral memory 29 exceeds the size of the application i. If step S120 is No and step S122 is Yes, the application i is preloaded into the oral memory 29 in step S115. When Step S120 is No and Step S122 is No, the application i proceeds to Step S116 without being preloaded into the local memory 29.
  • step S120 step S122 becomes "Yes”.
  • the judgment in step S121 is No, but only a few applications have been read, but the memory scale is large. Even if the new playback device reads more applications, the determination in step S122 is not No. As described above, the old playback device reads only the Mandatory application into the oral memory 29, and the new playback device reads the Mandatory application and the Optional application.
  • Step S122 is a step executed when it is determined to be Yes in step S122. If the application j with the same applicationlD and high read priority is located on the local memory 29, the sum of the remaining capacity of the local memory 29 and the size of the application j will determine the size of the application i. It is determined whether or not it exceeds (step S122), and if it exceeds, the application i is used to overwrite the application on the local memory 29; j is overloaded (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. An example of the reading process in steps S115 and S123 will be described with reference to FIG. 47 (a). FIG.
  • step S115 an application with a read priority of Mandatory is read into the oral memory 29 in step S115.
  • an application whose read priority is Optional is read in step S123 after the determination in steps S120 to S122.
  • preloading is performed to overwrite the application of the same applicationlD already in local memory 29, so one of the multiple applications is excluded. Thus, the local memory 29 is loaded.
  • FIG. 48 is a diagram illustrating a specific example of the reading process with reference to the data management table.
  • the two applications in this figure have the same applicationID (application # 3)
  • FIG. 7 is a diagram showing two applications provided. 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). Among these applications, application # 2 and application # 3 have a read attribute indicating the 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 given to playback on a playback device that has only the minimum required memory size. If the data management table having such contents is to be processed, the application manager 36 performs different processing according to the memory scale according to the flowchart of FIG. 46 described above.
  • the application manager can load the data into the local memory 29 as long as the required memory size is sufficient.
  • the problem here is when reading by a playback device with a large memory size. Despite having a large memory scale, the inability to read application # 3 until it reaches Chapter # 4 to Chapter # 5 is a waste of memory scale. Therefore, in the data management table in this figure, the same application # 3 is given a read attribute indicating a pre-read and recorded on the BD-ROM, and the same applicationID is given 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 judging whether or not the live section of the application having the start attribute indicating AutoRun has arrived. If it arrives, the application having the startup attribute indicating AutoRun is set to the application q (step S134), and a start instruction to start the application q is issued to the Java virtual machine 38, and the application q Is read from the local memory 29 to the work memory 37 (step S135).
  • step S133 it is determined whether or not reproduction of all the 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 it is determined whether or not a call has been made from the running application. If there is, the called application is set to the application q (step S136), and it is determined whether or not the current reproduction time point is the live range of the application q in the application management table (step S1). 3 7). If it is not a live range, a start failure is displayed (step S148), and the process returns to the loop consisting of steps S131 to S133. If it is a live range, load processing is performed according to the flowchart in FIG.
  • Step S138 in FIG. 50 is a judgment indicating whether or not the current reproduction time point is a live range of the application q in the data management table. If it is not a live range, application q cannot be loaded into local memory 29. In this case, a start instruction to start the application q is issued to the Java virtual machine 38, and the application q is directly read from the BD-ROM to the work memory 37 without passing through the local memory 29. . In this case, since the head seek for reading the application occurs, the PL playback is interrupted (step S145).
  • step S139 the application reads It is determined whether an embedded attribute is added. Absence of the read attribute means that the abbreviation q is not carouseled or interleaved. However, even if the read attribute is not added, it is permissible to place the application q in the oral memory 29. Therefore, the application is read out after replay interruption. That is, the application is read from the BD-ROM to the oral memory 29, and then the application is read to the work memory 37 (step S140).
  • Steps S141 to S146 are processing performed when step S139 is determined to be Yes.
  • step S141 it is determined whether or not the application is preloaded by referring to the read attribute. If preloaded, the process moves to step S135.
  • Step S142 is a determination step executed when the read attribute is load, and determines whether the application q is carouseled or interleaved. If interleaved, the cache sense is executed by the Java virtual machine 38 (step S144). If the application q exists in the oral memory 29, the process proceeds to step S135, and the application q is loaded 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). If it is a carousel, a timer is set (step S148), and the cache sense is executed by the Java virtual machine 38 (step S148) until the timer times out (step S148). 4 6). If the application q appears in the local memory 29, the process proceeds to step S135 of 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 the application is read by the Java virtual machine 38.
  • Arrows ⁇ 1 and 2 indicate the reading of Java archive files that are alive in the application management table, live in the data management table, and have a read attribute indicating carousel or interleaving.
  • Arrow ⁇ 1, step S65 Shows oral memory 29 sense made in 67.
  • the oral memory 29 sense means that data embedded by the carousel or interleaving may be present in the oral memory 29 because the data may exist in the oral 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.
  • Arrows Vl and 2 indicate 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.
  • the arrow VI corresponds to the reading in step S145, and indicates a request for a direct read from the BD-ROM by the Java virtual machine 38.
  • the arrow V2 indicates that the Java archive file is read from the BD-ROM to the work memory 37 according to the request.
  • Arrows 1, 2, and 3 indicate that a Java archive file that is alive in the application management table and alive in the data management table but has no read attribute exists.
  • Arrow 1 corresponds to the reading in step S140, and indicates a request for direct reading from the BD-ROM by the Java virtual machine 38.
  • Arrow 2 indicates reading of the Java archive file into local memory 29 by the request.
  • the arrow 3 indicates the reading of the Java archive file from the oral 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 will not be 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.
  • FIG. 52 (a) shows the internal structure of a BD-J object according to the seventh embodiment. What is different from FIG. 7 (b) is that a playlist management table has been added.
  • FIG. 52 (b) is a diagram showing an example of the playlist management table. As shown in this figure, the playlist management table includes a PL specification and a playback attribute of the PL.
  • the designation of PL indicates the PL that can be reproduced on the title time axis of the corresponding title.
  • the playback attribute of the PL indicates whether or not the specified PL is automatically played at the same time as the start of title playback (the PL that is automatically played back in this manner is called a default PL).
  • 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.
  • the title time axis is determined from the live range of the application as in the case of non-AV titles.
  • FIG. 53 (b) shows the title time axis of a non-AV title whose playback attribute is set to AutoPlay. If the playback attribute is set to indicate AutoPlay, the Playback Control Engine 32 starts playback of the default PL at the same time as playback of a 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 such abnormal termination, no applications are running, but the playback of the default PL continues.
  • the PL time axis of the default PL is also 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, the default PL playback by Playback Control Engine 32 is 15330 The default PL time axis becomes the title time axis because it is performed regardless of the startup failure.
  • FIG. 52 (c) is a diagram illustrating what processing is performed by the playback device when a PL whose playback attribute is set to AutoPlay exists in the playlist management table of the branch destination title.
  • the application manager 36 in the BD-J module 35 The Playback Control Engine 32 is instructed to start the playback of this AutoPlayPL immediately after the torch branch. In this way, the PL whose playback attribute is AutoPlay is ordered to start playback immediately after the title branch.
  • the application manager 36 performs the processing according to the processing procedure shown in FIG.
  • FIG. 54 is a flowchart showing the processing procedure of the application manager 36 according to the seventh embodiment. This flowchart is different from the flowchart of FIG. 38 in that steps S103 and S104 are added before step S21, so that steps S21 and S22 are interposed. Step S100 is added, and step S105 is added between step S23_ and step S26.
  • Step S103 is to determine whether or not the playback attribute of the playlist management table of the corresponding title is AutoPlay. If it is AutoPlay, the playback control for the default PL is started by the Playback Control Engine 32 (step S104).
  • step S100 it is determined whether or not reproduction by Presentation Engine 31 is in progress. If the data is being reproduced, the process proceeds to step S101.
  • Step SI05 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 process proceeds to step S101, and the process is continued.
  • the title to be played here is a non-AV title, including a game application that stacks 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 is also started. Since the execution of the game application and the playback of the default PL are performed in parallel, a composite image with the foreground as the screen of the game application and the background as the playback image of the default PL is shown in the upper left part of Fig. 55. Will be displayed. It is assumed that this game application ends abnormally on the way.
  • the title PL is in a state where something is reflected because the reproduction of the default PL is continued.
  • 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 the read attribute in the data management table is abolished, and an attribute called the ready attribute is provided in the start attribute instead.
  • the Ready attribute is a type of an activation attribute indicating that an application is previously loaded in the oral memory 29 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 preloaded (1), whether it is automatically started when the current playback point reaches the valid section, PT / JP2004 / 015330 It is activated in response to a call from another (2), is loaded according to the progress of title playback (3), or is alive. Five modes appear as shown in (b).
  • the startup attribute is set to AutoRun when preloading is performed and "automatic startup", and when loading is performed and "automatic startup”.
  • the activation attribute is set to the Ready attribute when preloading or loading has been performed and the activation item indicates "call activation".
  • the working memory 37 does not exist in the working memory 37 and cannot be loaded into the local memory 29. This is because the application 'data management table uses the working memory 37' This is because the interval and the live range of the local memory 29 are separate.
  • the application manager 36 can execute an application with the start attribute set to AutoRun and an application with the start attribute set to Ready attribute before playing the title. Performs the process of preloading the low memory 29. By doing so, it is possible to perform a process of pre-storing the application 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 the reading of a Java archive file that is alive in the application's data management table and whose startup attribute is set to the Ready attribute. Arrows 1, 2, and 3 indicate the reading of an application that is alive in the application's data management table and whose startup attribute is Persistent.
  • the ninth embodiment is an embodiment in which the read priority is represented by a combination of information meaning Optional and a numerical value from 0 to 255.
  • 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 given into the oral memory 29 as in the first embodiment.
  • the capacity of the oral memory 29 exceeds the size of the application. If it exceeds, the application assigned with the read priority Optional is read into the local memory 29 as it is. If it is lower, the application having a higher numerical value representing the read priority among the data constituting the application is read into the local memory 29. Then, an application having a low numerical value representing the read priority is read out to the remaining area in the local memory 29. In this way, even for an application that is treated as Optional, even if the entire storage capacity is not in the local memory 29 of the playback device, a part of the application can be stored in the local memory 29.
  • FIG. 59 is a diagram showing a data management table to which group attributes have been assigned.
  • the group attribute can be set in two ways, such as no exclusive group and exclusive group. If there is an exclusive group, the group number is described. In Fig. 59 (a), "#" in title # l indicates that there is no exclusive group. On the other hand, "group # l" of title # 2, # 3 indicates that there is an exclusive group, and title # 2, # 3 belongs to the exclusive group of group # l.
  • the above is the improvement of the recording medium according to the present embodiment.
  • the playback device reads each application into the local memory 29 based on the data management table, and then verifies the group attribute of the application in the local memory 29. If two or more applications belonging to the same exclusive group exist 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 activated by this application is limited to one in principle, the local memory 29 has only the launcher + 1 application. If there are three or more applications, the application manager 36 must perform the process of deleting them from the local memory 29. It checks whether the existing application is a launcher + one application.
  • FIG. 59 (a) is a diagram showing access to the local memory 29 based on the application management table.
  • these applications belong to the same other group.
  • application # l is the launcher application described above
  • application # 2 and application # 3 are the applications started by this, so only one of them is local memory.
  • the application manager 36 refers to the group attributes of application # 2 and application # 3, and performs a process of deleting one of them from the local memory 29. Such a deletion creates a space 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 multiple tables.
  • the arrows in the figure schematically show the allocation of the application management table. Referring to this arrow, the first row of application management tables # 1, # 2, and # 3 are assigned to titles # 1, # 2, and # 3, respectively, shown in the second row. You can see it.
  • application management table # 4 is allocated for each disk, and application management table # 5 is allocated for the entire disk set.
  • allocation unit of the application management table is set to a unit larger than the title, any one of an application or a plurality of BD-ROMs that survive while one BD-ROM is being loaded is loaded. You can define an application that survives while it is being loaded.
  • the optical disc according to the present invention is implemented as a BD-ROM, but the optical disc of the present invention is characterized by a recorded dynamic scenario and an Index Table. It does not depend on the physical properties of the ROM.
  • Dynamic scenario 4 015330 For example, any recording medium that can record the Index Table may be used. For example,
  • Optical discs such as DVD-ROM, DVD-RAM, DVD-RW, DVD-R, DVD-RW, DVD + R, CD-R, and CD-RW, and magneto-optical discs such as PD and MO may be used.
  • a semiconductor memory card such as a compact flash card, smart media, memory stick, multimedia card, PCM-CIA card, etc. may be used.
  • a magnetic recording disk (i) such as a flexible disk, SuperDisk, Zip, Clik !, etc .; .
  • 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 A television may be provided.
  • the playback device and the V can be incorporated into a home network connected by IEEE1394.
  • the playback device in the embodiment is of a type used by connecting to a television, but may be a playback device integrated with a display.
  • only the portion that forms an essential part of the processing may be used as the playback device.
  • the playback device is manufactured based on the internal configuration of the playback device described in each embodiment.
  • the act is an act of practicing the invention described in the specification of the present application.
  • the transfer of the playback device shown in each embodiment at no charge (free of charge, sales and free of charge is a gift), lending, and import are also implementations of the present invention.
  • the act of inviting the general user to transfer or lend these items through store displays, solicitation of catalogs, or distribution of pamphlets is also an act of implementing 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 the Top Menu can be used for branching. It may be called by pressing the Chapter key of the remote control key.
  • TP-extra—TS buckets with header (hereinafter abbreviated as EX-attached TS packets) are grouped every 32 packets and written into three sectors.
  • the 32 TS packets with EX in 3 sectors are called "Aligned Unit".
  • the playback device 200 When used in a home network connected via IEEE1394, the playback device 200 transmits Aligned Units by the following transmission processing. In other words, the sender device removes the TP-extra-header from each of the 32 EX-attached TS packets included in the Aligned Unit, encrypts the TS packet itself based on the DTCP standard, and outputs it.
  • an isochronous field is used everywhere between the TS buckets. Purchase a kit. This input location is a position based on the time indicated in Arribval_Time_Stamp of TP_extra-header.
  • the playback device 200 With the output of the TS bucket, the playback device 200 outputs DTCP_Desci'iptor.
  • the digital stream recorded on the recording medium is the AVClip, but may be a DVD-Video standard or a VOB (Video Object) of the DVD-Video Recording standard.
  • VOB is a program stream compliant with the ISO / IEC13818-1 standard obtained by multiplexing a video stream and an audio stream.
  • the video stream in AVClip may be in MPEG4 or WMV format.
  • the audio stream may be a Linear-PCM system, a Dolby_AC3 system, an MP3 system, an MPEG-AAC system, Dts, or WMA (Windows media audio).
  • the video work in each embodiment 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. Also, the content may be obtained by encoding the analog digital video signal recorded on the video tape. Further, the content may be obtained by encoding an analog digital 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 built into the device for receiving satellite broadcasts. If the BD-J module 35 is such a Java platform, the playback device according to the present invention also serves 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 also serves as a mobile phone.
  • the MOVIE mode may be placed above the BD-J mode.
  • the interpretation of the dynamic scenario in the MOVIE mode and the execution of control procedures based on the dynamic scenario place a light burden on the playback device, so that there is no problem if the MOVIE mode is executed in the BD-J mode. Because. Also for playback devices and movie works 15330 This is because, in the development, only one mode of operation guarantee is required.
  • the reproduction process may be executed only in the BD-J mode.
  • the playback control synchronized with the PL playback can be performed, so that the MOVIE mode does not have to be provided.
  • a navigation command may be provided in the interactive graphics stream to be multiplexed on the DAVClip, and a branch from one PL to another PL may be realized.
  • the playback device according to the present invention may be used for personal use, such as in a home theater system.
  • the internal configuration of the present invention is disclosed in the above embodiment, and since it is clear that mass production is performed based on this internal configuration, the present invention can be industrially used in terms of quality. From this, the playback device according to the present invention has applicability in the g industry.

Landscapes

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

Abstract

　BD-ROMには、分岐可能な複数のタイトルと、Javaアプリケーションとが記録されている。Javaアプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されており、前記各タイトルは、アプリケーション管理テーブルを含み、アプリケーション管理テーブルは、タイトルを生存区間とするアプリケーションを、各タイトル毎に示す。

Description

明細書 記録媒体、 再生装置、 プログラム、 再生方法 技術分野
, 本発明は、 デジタル化された映像の再生と、 アプリケーションの実行とを同時に 実行する、 再生制御技術の技術分野に属する発明であり、 本再生制御技術を記録 媒体、 民生用の再生装置、 プログラムに応用する場合の応用技術に深く係る。 ' 背景技術
記録媒体を用いた映画ビジネスには、 デジタル化された映画作品と、 オンライ ンショッピング用のアプリケ一シヨンとを同じ記録媒体に記録して販売するとい う販売戦略がある。映画作品に関連するキャラクタ 'グッズを、オンラインで販売 するような仕組みを一枚の記録媒体に組み込めば、 映画作品と、 アプリケーショ ンとの相乗効果により、キャラクタ'グッズの売り上げを高めることができるので はないかという、 制作者側の目論見がある。 かかるコンテンツを実現するにあた つて、 今後登場する記録媒体及び再生装置には、 より自由度が高いアプリケーシ ョン実行環境の整備が要望されている。
ここでかかるデジタル化された映画作品と、 オンラインショッピング用のアブ リケ一シヨンとの同時実行を実現するには、 デジタル映像の再生に従って、 アブ リケーシヨンを動作させるという技術が必要になる。 デジタルストリームの再生 に従って、 Javaアプリケーションを動作させる技術としては、 DVB-MHP規格 における" シグナリング" が知られている。 シグナリングとは、 デジタルストリ ームの再生時間軸において、 アプリケーションを起動すべき時点、 終了させるベ き時点を定義しておき、 この時点に、 AIT(application Information Table)と呼ば れる情報を送信して、この AITに従った制御を再生装置に行わせるというもので ある。
しかしながらデイスクコンテンッの再生進行は、再生時間軸の逆向がありうる。 逆行とは、 巻戻しにより時間軸を逆向きに進行することである。 アプリケ一ショ ンを起動すべき時点、 終了させるべき時点の前後でこの逆行と、 進行とが何度も なされ、 いったりきたりが繰り返されれば、 ワークメモリへのロード、 廃棄が何 度もなされ、 余分な読出負荷が生じてしまう。
発明の開示
本発明の目的は、 再生時間軸において再生の逆行があつたとしても、 余分な読 出負荷の発生を避けることができる再生装置を提供することである。
上記目的は、 分岐可能な複数のタイトルと、 アプリケーションとが記録された 記録媒体であって、 前記アプリケーションは、 仮想マシン向けプログラミング言 語で記述されたプログラムであり、 仮想マシンによる実行が可能となる生存区間 が、 予め規定されており、 前記各タイトルは、 管理テーブルを含み、 管理テープ ルは、 タイ トルを生存区間とするアプリケーションを、 各タイトル毎に示すこと を特徴とする記録媒体により達成される。 ―
タイ トルは、 時間軸と制御手順とからなり、 タイトルからタイ トルへの分岐は 分岐コマンドで規定されているので、 たとえ一個のタイ トルにおける時間軸内に おいて巻戻しがあつたとしても、 当該分岐コマンドによる分岐がなされる前の、 分岐元タイ トルまで、再生は逆行することはない。 タイトルは、"再生の逆行が有 り得ない単位" であり、 このタイ トルを元に、 アプリケーションの生存区間を規 定すれば、 ワークメモリへの読み込み、 廃棄が何度も繰り返されることはない。 読み込み、 廃棄の繰り返しがなくなるので、 余分な読出負荷の発生を避けること ができる。
図面の簡単な説明
図 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) は、 PlayLis #l、 PlayList#2の時間軸を足し合わせた時間軸を示す 図である。
図 10は、 本編タイトル、 オンラインショッピングタイトル、 ゲームタイ トル という 3つのタイトルを含むディスクコンテンツを示す図である。
図 1 1は、 図 10に示した 3つのタイ トルの再生画像の一例を示す図である。 図 12 (a) は、 図 1 0の破線に示される帰属関係から各アプリケーションの 生存区間をグラフ化した図である。
図 12 (b) は、 図 1 2 (a) の生存区間を規定するため、 記述されたアプリ. ケーション管理テーブルの一例を示す図である。
図 13 (a) は、 起動属性設定の一例を示す図である。
図 13 (b) は、 他のアプリケーションからのアプリケーション呼出があって 初めて起動するアプリケーション (application#2)を示す図である。
図 14 (a) (b) は、 Suspend が有意義となるアプリケーション管理テープ ル、 生存区間の一例を示す図である。
図 15は、 起動属性がとり得る三態様 (Persistent, AutoRun、 Suspend)と、 直前タィトルにおけるアプリケーション状態の三態様 (非起動、起動中、 Suspend) とがとりうる組合せを示す図である。
図 16は、 本発明に係る再生装置の内部構成を示す図である。
図 17 (a) は、 BD-ROMに存在している Javaアーカイブファイルを、 ロー カルメモリ 29上でどのように識別するかを示す図である。
図 17 (b) は、 図 17 (a) の応用を示す図である。
図 18は、 ROM24に格納されたソフトウエアと、ハードウエアとからなる部 分を、 レイァ構成に置き換えて描いた図である。
図 1 9は、 Presentation Engine 31〜モジュールマネージャ 34による処理 を模式化した図である。
図 20は、アプリケーションマネージャ 36による処理を模式化した図である。 図 21は、 ワークメモリ 37—Default Operation Manager 40を示す図であ る。
図 22は、 アプリケーションマネージャ 36による分岐時の制御手順を示す図 である。
図 23は、アプリケーション終了処理の処理手順を示すフローチャートである。 図 24は、 アプリケーション終了の過程を模式的に示した図である。
図 25 (a) は、 PL時間軸上に生存区間を定めたアプリケーション管理テー プルを示す図である。
図 25 (b) は、 図 25 (a) のアプリケーション管理テーブルに基づき、 ァ プリケ一シヨンの生存区間を示した図である。 ' '
図 26 (a) は、 PL時間軸から定まるタイ トル時間軸を示す。
図 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" を示すよう設定され、 メインアプリの起動に失敗したケースを示す図である。 図 5 4は、 第 7実施形態に係るアプリケーションマネージャ 3 6の処理手順を 示すフローチャートである。
図 5 5は、 プレイリスト管理テーブルにおいて" 再生属性 =AutoPlay" に設定 されることにより、 どのような再生が行われるかを模式化した図である。
図 5 6 ( a ) ( b ) は、 アプリケーションの扱いと、 起動属性との関係を示した 図である。
図 5 7は、 第 8実施形態に係る Java仮想マシン 3 8によるアプリケーション の読み込みがどのようにして行われるかを模式化した図である。
図 5 8 ( a ) ( b ) は、 第 9実施形態に係る読込優先度の一例を示す図である。 図 5 9 ( a ) は、 グループ属性が付与されたデータ管理 一ブルを示す図であ る。
図 5 9 ( b ) は、 アプリケーション管理テーブルに基づくローカルメモリ 2 9 に対するアクセスを示す図である。
図 6 0は、 アプリケーション管理テーブルの割当単位のバリエーションを示す 図である。
発明を実施するための最良の形態
(第 1実施形態）
以降、 本発明に係る再生装置の実施形態について説明する。 先ず始めに、 本発 明に係る再生装置の実施行為のうち、 使用行為についての形態を説明する。 図 1 は、 本発明に係る再生装置の、 使用行為に'ついての形態を示す図である。 図 1に おいて、 本発明に係る再生装置は再生装置 2 0 0であり、 テレビ 3 0 0、 リモコ ン 4 0 0と共にホームシアターシステムを形成する。
この BD-ROM 1 0 0は、 再生装置 2 0 0、 リモコン 3 0 0、 テレビ 4 0 0に より形成されるホームシアターシステムに、 映画作品を供給するという用途に供 される。
以上が本発明に係る再生装置の使用形態についての説明である。
続いて本発明に係る再生装置の再生の対象となる、 記録媒体である BD-ROM について説明する。 BD-ROM により、 ホームシアターシステムに供給されるデ イスクコンテンツは、 互いに分岐可能な複数タイトルから構成される。 各タイ ト ルは、 1つ以上のプレイリストと、 このプレイリストを用いた動的な制御手順と からなる。
プレイリストとは、 1 つ以上のデジタルストリームと、 そのデジタルストリー ムにおける再生経路とから構成され、"時間軸" の概念をもつ BD-ROM上のァク セス単位である。以上のプレイリストと、動的な制御手順とを包含しているため、 タイトルはデジタルストリーム特有の時間軸の概念と、 コンピュータプログラム 的な性質とを併せもっている。
図 2は、 BD-ROMにおけるファイル 'ディ レクトリ構成を示す図である。 本図 において BD-ROMには、 Rootディ レクトリの卞に、 BDMVディ レクトリがあ る。
BDMV ディ レク ト リ には、 拡張子 bdmv が付 されたフ ァ イ ル (index.bdmv,MovieObject.bdmv)と、 拡張子 BD-J が付与されたフ ァ イル (00001.BD-J,00002.BD-J,00003.BD-J)がある。そしてこの BDMVディ レクトリ の配下には、更に PLAYLISTディ レクトリ、 CLIPINFディ レクトリ、 STREAM ディレクトリ、 BDARディ レクトリと呼ばれる 4つのサブディ レクトリが存在す る。
PLAYLIST ディ レク ト リ には、 拡張子 mpls が付与されたファイル (O0001.mpls，00002.mpls，00003mpls)がある。
CLIPINF ディ レク ト リ には、 拡張子 clpi が付与されたフ ァ イ ル (O0001.clpi,00002.clpi,00003.clpi)がある。
STREAM ディ レク ト リ には、 拡張子 m2ts が付与されたフ ァ イ ル (00001.m2ts,00002.m2ts,00003.ni2ts)がある。
BDAR デ ィ レク ト リ には、 拡張子 jar が付与されたフ ァ イ ル (00001.]'ar，00002jar，00003;iar)がある。 以上のディ レクトリ構造により、 互いに 異なる種別の複数ファィルが、 BD-ROM上に配置されていることがわかる。
本 図 に お い て 拡 張 子 .m2ts が 付 与 さ れ た フ ァ イ ル
(00001.m2ts,00002.m2ts,00003.m2ts- · · · は、 AVClipを格納している。 AVClip には、 MainCLip、 SubClip といった種別がある。 MainCLip は、 ビデオストリ —ム、 オーディオストリーム、 プレゼンテーショングラフィクスストリーム、 ィ ン夕ラクティブグラフ.ィクスストリームというような複数エレメンタリストリ一 ムを多重化することで得られたデジタルストリームである。 4 015330
SubClipは、 オーディオストリーム、 グラフィクスストリーム、 テキスト字幕 ストリーム等、 1 つのエレメンタリストリームのみにあたるデジタルストリーム である。
拡張子" dpi" が付与されたフアイル (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情報は、 複数の Hayltem情報からなる。 Playltemとは、 1つ以上 の AVClip時間軸上において、 In— hne,OutJThneを指定することで定義される 再生区間である。 Playltem 情報を複数配置させることで、 複数再生区間からな るプレイリスト（PL)が定義される。 図 3は、 AVClipと、 PLとの関係を示す図で ある。第 1段目は AVClipがもつ時間軸を示し、第 2段目は、 PLがもつ時間軸を 示す。 PL情報は、 Playltem#l,#2，#3という 3つの Playltem情報を含んでおり、 これら Playltem#l,#2，#3の Injime, 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_PlayItem— Id)と、一時点 の指定 (mark— time_stamp)とを示す。 これらの指定により PL時間軸には、 3つ のチャプター (Chapter#l，#2，#3)が定義されることになる。 ·
SubPath情報は、 複数の SubPlayltem情報からなる。 SubPlayltem情報は、 SubClipの時間軸上に In_Time，Out— Timeを指定することで再生区間を定義する。 また SubPlayltera情報は、 SubClip時間軸上の再生区間を、 PL時間軸に同期さ せるという同期指定が可能であり、 この同期指定により、 PL 時間軸と、 SubPlayltem 情報時間軸とは同期して進行することになる。 図 6は、 SubPlayltem時間軸上の再生区間定義と、 同期指定を示す図である。本図におい て第 1段目は、 PL時間軸を示し、 第 2段目は SubPlayltem時間軸を示す。 図中 の SubPlayltem.IN— timeは再生区間の始点を、 SubPlayltem.Out— timeは再生 区間の終点をそれぞれ示す。 これにより SubClip時間軸上にも再生区間が定義さ れていることがわかる。 矢印 Snlにおいて Sync_PlayItem_Idは、 Playltemに 対する同期指定を示し、矢印 Sn2において sync— start— PTS_of_PlayItemは、 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における任意の時刻、 0
Chapter, Markを用いて再生開始位置を指定することができる。
Playltem により PL 時間軸上の再生開始位置を指定した PlayPL 関数を
PlayPLatPlayItemO、
Chapter により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatChapterO,
時刻情報により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatSpecified TimeOという。
JMPコマンド
書式： JMP引数 '
JMPコマンドは、現在の動的シナリォを途中で廃棄し (discard),引数たる分岐 先動的シナリオを実行するという分岐である。 JMP命令の形式には、分岐先動的 シナリオを直接指定している直接参照のものと、 分岐先動的シナリオを間接参照 している間接参照のものがある。
Movie ォプジェクトにおけるナピゲ一シヨンコマンドの記述は、 DVD におけ るナビゲ一シヨンコマンドの記述方式と良く似ているので、 DVD 上のディスク コンテンツを、 BD-ROM に移植するという作業を効率的に行うことができる。 Movieオブジェクトについては、 以下の国際公開公報に記載された先行技術が存 在する。 詳細については、 本国際公開公報を参照されたい。 国際公開公報 W02004/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ォブジェクトは、 T JP2004/015330
Movie オブジェクト同様の属性情報、 アプリケーション管理テーブルからなる。 属性情報を有している点で BD-Jォブジ： Lクトは Movieォブジヱタトとほぼ同じ である。 Movieオブジェクトとの違いは、 BD-Jォブジェクドはコマンドが直接 記述されていない点である。つまり Movieォブジヱクトにおいて制御手順は、 ナ ピゲーシヨンコマンドにより直接記述されていた。 これに対し BD-Jオブジェク トでは、 そのタイトルを生存区間としている Javaアプリケーションをアプリケ ーシヨン管理テーブル上に定めることにより、間接的に制御手順を規定している。 このような間接的な規定により、 複数タイ トルにおいて制御手順を共通化すると いう、 制御手順の共通化を効率的に行うことができる。
図 7 ( c ) は、 Javaアプリケーションの内部構成を示す囪である。 本図におい てアプリケーションは、 仮想マシンのヒープ領域 (ワークメモリとも呼ばれる）に ロードされた 1つ以上の xletプログラムからなる。 このワークメモリでは、 1つ 以上のスレツドが動作しており、 ワークメモリに口一ドされた xletプログラム、 及ぴ、 スレッドから、 アプリケーションは構成されることになる。 以上がアプリ ケ一シヨンの構成である。
このアプリケーションの実体にあたるの力 BDMVディ レクトリ配下の BDAR ディ レクトリに格納された Java アーカイブファイル (00001.]'ar，00002.;jar)であ る。 以降、 Javaアーカイブファイルについて説明する。
Javaアーカイブフアイル (00001.jar,00002.jar)は、 Javaアプリケーションを構 成するプログラム、データを格納したアーカイブファイルである。図 8 ( a )は、 アーカイブファイルにより収められているプログラム、 データを示す図である。 本図におけるデータは、 枠内に示すディ レクトリ構造が配置された複数ファイル を、; javaアーカイバでまとめたものである。枠内に示すディ レクトリ構造は、 root ディ レクトリ、 javaディ レクトリ、 imageディ レクトリとからなり、 rootディに common.pk が、 javaティレクトリに aaa.class,bbb.ciass力 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λ"BD:〃00001.mpls"; は、PLを再生するプレーヤィンスタンスの生成を Java仮想マシンに命じるメソ ッドである。 A.playは、 JMFプレーヤインスタンスに再生を命じるメソッドで ある。 かかる JMFプレーヤインスタンス生成は、 JMFライブラリに基づきなさ れる。 xletプログラムの記述は、 BD-ROMの PLに限らず、 時間軸をもったコン テンッ全般に適用可能な JMFの記述である。このような記述が可能であるので、 Javaプログラミングに長けたソフトハウスに、 BD-Jオブジェクト作成を促すこ とができる。 '
図 8 ( b ) における JumpTItleO;は、 ファンクション APIのコールである。 こ のファンクション APIは、他のタイトルへの分岐 (図中では title#l)を再生装置に 命じるものである。 ここでファンクション APIとは、 BD-ROM再生装置により 供給される APKAppliation Interface)である。 JmnpTitleコマンドの他にも、 フ アンクシヨン APIのコールにより、 BD-ROM再生装置特有の処理を xletプログ ラムに記述することができる。
BD-Jモ一ドにおいて PL再生は、 JMFィンターフェイスにより規定される。 この JMFプレーヤインスタンスは、 PL時間軸を定めるものだから、 タイトル時 間軸は、 この JMFプレ一ャインスタンスをもったタイ トルから定まる。 また
BD-Jモ一ドにおいてタイトルからタイトルへの分岐は JmnpTitleAPIのコー ルにより規定される。 JmnpTitleAPI コールは、 いわばタイトルの終了時点を定 めるものなので、 こうした JMFプレーヤインスタンス、 JumpTitleAPI コ一ル をもったアプリケーションが、 BD-J モードにおいてタイ トルの開始及び終了を 律することになる。かかるアプリケーションを本編再生アプリケ一ションという。 以上が、 BD-Jモードにおける動的シナリオについての説明である。 この BD-J モードにおける動的シナリオにより、 PL再生と、 プログラム的制御とを併せも つたタイ トルが定義されることになる。 尚、 本実施形態においてアプリケ一ショ ンを構成するプログラム、データは、 Javaアーカイブファイルにまとめられたが、 LZHファイル、 zipフアイルであつてもよい。
くタイトル時間軸 >
タイ トルを構成する静的シナリオ、 動的シナリオについて説明を終えたところ で、 これらによりどのような時間軸が定義されるかについて説明する。 タイトル により定義される時間軸は、"タイトル時間軸"と呼ばれる。タイトル時間軸とは、 Movieォブジェクト、 又は、 BD-Jォプジェクトにより再生が命じられる PL に より構成される。 ここで一例を挙げるのは、図 9 ( a )のようなタイ トルである。 このタイ トルは、 トップメニュ一" title#l→title#2→トップメニュー、 トップメ 二ュ一" title#3→トップメニューという一連のタイ トルである。 かかるタイトル のうち、 title#lは PlayList#l、 PlayList#2、 title#2が PlayList#3、 title#3が PlayList#4の再生を命じるものなら、図 9 ( b )のように、 PlayList#l、 PlayList#2 の時間軸を足し合わせた時間軸を、 title#lはもつことになる。同様に title#2は、 PlayLis #3時間軸からなる時間軸を、 title#3は PlayList#4時間軸からなる時間 軸を持つことになる。 これらタイ トル時間軸における PL時間軸ではシームレス 再生が保証されるが、 タイ トル時間軸間ではシームレス再生の保証は必要でなく なる。 Javaアプリケーションを動作させるにあたっては、 Javaアプリケーショ ンを、 仮想マシンのワークメモリ上に存在させてもよい期間 (サービス期間)を、 こうしたタイ トル時間軸上に定義せねばならない。 BD-Jモードにおいて Javaァ プリケーシヨンを動作させるにあたっては、 互いに分岐し合う時間軸上に、 Java アプリケーションのサービス期間を定義せねばならない。 このサービス期間の定 義が、 BD-ROM向けのプログラミングを行うにあたっての留意点になる。
最後に、 index.bdmvに格納された IndexTableについて説明する。 IndexTable は、 タイトル番号と、 Movieオブジェクト、 BD-Jォブジェクトとを対応づける テーブルであり、 動的シナリオから動的シナリオへの分岐の際、 参照される間接 参照用テ一ブルである。 IndexTable は、 複数ラベルのそれぞれに対する Index P T/JP2004/015330 からなる。 各 Indexには、 そのラベルに対応する動的シナリオの識別子が記述さ れている。 こうした IndexTableを参照することで、 Movieオブジェクト、 BD-J オブジェクトの違いを厳密に区別することなく、 分岐を実現することができる。 IndexTableについては、以下の国際公開公報に詳細が記載されている。詳細につ いては、 本公報を参照されたい。 国際公開公報 WO 2004/025651 A1公報 以上が BD-ROMに記録されているファイルについて説明である。
くアプリケーション管理テーブル〉
JMFプレーヤィンスタンス、 JumpTitleAPIコールをもったアプリケーション が、 タイトル時間軸を律することは上述した通りだが、 JMFプレーヤインスタン スゃ JumpTitleAPIのコールをもたないその他のアプリケーションを、 タイ トル 時間軸上で動作させる場合、 時間軸の何処からアプリケーシヨンによるサービス を開始し、 時間軸の何処でアプリケーションによるサービスを終えるかという" サービスの開始点'終了点"を明確に規定することが重要になる。本実施形態では、 アプリケーションによるサービスが開始してから、終了するまでを、"アプリケ一 シヨンの生存" として定義する。 アプリケーションの生存を定義するための情報 は、 BD-J オブジェクトにおけるアプリケーション管理テーブルに存在する。 以 降アプリケーション管理テーブルについてより詳しく説明する。
アプリケーション管理テーブル (AMT)は、 各タイ トルが有しているタイ トル時 間軸において、 仮想マシンのワークメモリ上で生存し得るアプリケーションを示 す情報である。 ワークメモリにおける生存とは、 そのアプリケーションを構成す る xletプログラムが、 ワークメモリに読み出され、仮想マシンによる実行が可能 になっている状態をいう。 図 7 (b ) における破線矢印 atlは、 アプリケーショ ン管理テープルの内部構成をクローズアップして示す。 この内部構成に示すよう に、 アプリケーション管理テーブルは、 『生存区間』 と、 そのタイ トルを生存区間 としているアプリケーションを示す『applicationID』 と、 そのアプリケーション の 『起動属性』 とからなる。
近い将来、 実施されるであろうディスクコンテンツを題材に選んで、 アプリケ P T/JP2004/015330 ーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。 ここで題材にするディスクコンテンツは、 映像本編を構成する本編タイ トル
(title#l)、 オンラインショッピングを構成するオンラインショッピングタイ トル (title#2)、 ゲームアプリケーションを構成するゲームタイ トル (title#3)という、性 格が異なる 3つのタイトルを含むものである。 図 1 0は、 本編タイ トル、 オンラ ィンショッビングタイ トル、 ゲームタイトルという 3つのタイ トルを含むディス クコンテンツを示す図である。 本図における右側には IndexTable を記述してお り、 左側には 3つのタイ トルを記述している。
右側における破線枠は、 各アプリケーションがどのタイ トルに属しているかと いう帰属関係を示す。 3 つのタイ トルのうち title#l —は、 application#l、 application#2, application#3という 3つのアプリケーションからなる。 title#2 は、 application#3、 application#4という 2つのアプリケーション、 title#3は、 application#5を含む。 図 1 1は、 図 1 0に示した 3つのタイ トルの再生画像の 一例を示す図である。 これら 3つのタイ トルの再生画像において、 図 1 1 ( a ) ( b ) の本編タイ トル、 オンラインショッビングタイ トルには、 ショッピング力 一トを模した映像 (カート crl)lが存在するが、 図 1 1 ( c ) のゲームタイトルに は、 カート映像が存在しない。 カート crlは、 本編タイトル、 オンラインショッ ビングタイ トルにおいて共通して表示しておく必要があるので、 カートプロダラ ムたる application#3を、 title#l、 title#2の双方で起動するようにしている。 こ のように複数タイ トルで起動するようなアプリケーションには、 上述したカート アプリの他に、 映画作品に登場するマスコットを模したエージヱントアプリ、 メ ニューコール操作に応じてメ二ュ一表示を行うメニューアプリがある。
図 1 0の破線に示される帰属関係から各アプリケーションの生存区間をグラフ 化すると、 図 1 2 ( a ) のようになる。 本図において横軸は、 タイトル時間軸で あり、 縦軸方向に各アプリケーションの生存区間を配置している。 ここで application#l、 application#2は、 title#lのみに帰属しているので、 これらの生 存区間は、 title#l内に留まっている。 application#4は、 title#2のみに帰属して いるので、 これらの生存区間は、 title#2内に留まっている。 application#5は、 title#3 のみに帰属しているので、 これらの生存区間は、 title#3 内に留まってい る。 application^は、 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] は、 継続属性であり、 分岐元 titieにおけるアプリケー ションの状態を継続することを示す。 またワークメモリにロードしてよいことを 示す属性である。 起動属性が 「Persistent」 である場合、 この起動属性が付与さ れたアプリケーションは、 他のアプリケーションからの呼び出しが許可されるこ とになる。 アプリケーション管理を行う管理主体 (アプリケーションマネージャ） は、 起動中のアプリケーションから呼出があると、 そのアプリケーションの applicationID が、 アプリケーション管理テーブルに記述されていて、 起動属性 が 「Persistent」 であるか否かを判定する。 「Persistent」 であれば、 そのアプリ ケーシヨンをワークメモリにロードする。 一方、 その呼出先アプリケーションの applicationID がアプリケーション管理テ一ブルに記述されていない場合、 その アプリケーションはワークメモリにロードされない。 アプリケーションによる呼 出は、 この「Persistent」が付与されたアプリケーションに限られることになる。
「Persistent」 は、 起動属性を明示的に指定しない場合に付与されるデフオル トの起動属性であるから、 あるアプリケーションの起動属性が無指定 「一—」 で ある場合、そのアプリケーションの起動属性の起動属性はこの Persistentである ことを意味する。
これらの起動属性が、 図 1 1のアプリケーションにおいてどのように記述され ているかについて説明する。 図 1 3は、 図 1 2の 3つのアプリケーションに対す る起動属性の設定例である。 図 1 2に示した 3 つのアプリケーションのうち application^^ は、 図 1 3 ( b ) に示すように他のアプリケーションからのアブ リケーシヨン呼出があって初めて起動するアプリケーションであるとする。 残り の application#l、 application#3は、 title#lの開始と同時に自動的に起動される アプリケーションであるとする。 この場合、 図 1 3 ( a ) に示すように、 アプリ ケーシ ョ ン管理テ一プルにおける各アプリケーシ ョ ンの起動属性を、 appdcation#l、 appucation#3は 「Autojtiun」、 applicat;ion#2は、 I Pei'sistentJ と設定しておく。 この場合、 application#l、 application#3は、 title#lへの分岐 時において自動的にワークメモリにロードされ、 実行されることになる。 一方 application#2は、 起動属性が Persistentなので、 「application#3は仮想マシン のワークメモリ上にロードしてよいアプリケーション」 であるとの消極的な意味 に解される。 故に、 application#2は、 application#lからの呼出があって初めて 仮想マシンのワークメモリにロードされ、 実行されることになる。 以上の生存区 間-起動属性により、 仮想マシン上で動作し得るアプリケーションの数を 4個以 下に制限し、 総スレッド数を 64個以下に制限することが可能なので、 アプリケ —ションの安定動作を保証することができる。
続いて Suspendについて説明する。
Suspend とは、 リソースは割り付けられているが、 CPljパワーは割り当てら れない状態にアプリケーションが置かれることをいう。かかる Suspendは、例え ばゲームタイトルの実行中に、 サイドバスを経由するという処理の実現に有意義 である。 図 1 4 ( a ) ( b ) は Suspendが有意義となる事例を示す図である。 図 1 4 ( b ) に示すように、 3 つのタイ トル (title#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つのパーツからなり、 こ れらのパーツを装置のキャビネット及び基板に実装することで工業的に生産する ことができる。 システム LSIは、 再生装置の機能を果たす様々な処理部を集積し た集積回路である。 こうして生産される再生装置は、 BD-ROM ドライブ 1、 リ ードバッファ 2、 デマルチプレクサ 3、 ビデオデコーダ 4、 ビデオプレーン 5、 P-Graphicsデコーダ 9、 Presentation Graphicsプレーン 1 0、 合成部 1 1、 フ オントゼネレ一タ 1 2、 I-Graphics デコーダ 1 3、 スィッチ 1 4、 Interactive Graphicsプレーン 1 5、 合成部 1 6、 HDD 1 7、 リ一ドパッファ 1 8、 デマル チプレクサ 1 9、 オーディオデコーダ 2 0、 シナリオメモリ 2 1、 CPU 2 2、 キ 一イベント処理部 2 3、 命令 ROM 2 4、 スィッチ 2 5、 01^1で部2 6、 CLUT 部 2 7、 PSRセット 2 8、 口一カルメモリ 2 9から構成される。
BD-ROM ドライブ 1は、 BD-ROM のローデイング Zイジェク トを行い、 BD-ROMに対するアクセスを実行する。 15330 リ一ドバッファ 2は、 FIFOメモリであり、 BD-ROMから読み出された TSノ、。 ケットが先入れ先出し式に格納される。
デマルチプレクサ (De-MUX) 3は、 リードバッファ 2から TS バケツトを取り 出して、 この TSバケツトを構成する TSバケツトを PESパケットに変換する。 そして変換により得られた 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 X 1080であり、 Presentation Graphicsプレーン 1 0中の非圧 縮グラフィクスの各画素は 8 ビッ トのィンデックスカラーで表現される。 CLUT(Color Lookup Table)を用いてかかるインデックスカラ一を変換すること により、 Presentation Graphicsプレーン 1 0に格納された非圧縮グラフィクス は、 表示に供される。
合成部 1 1は、 非圧縮状態のピクチャデータ (i)を、 Presentation Graphicsプ レーン 1 0の格納内容と合成する。
フォントゼネレータ 1 2は、 文字フォントを用いて textST ストリームに含ま れるテキストコードをビットマップに展開する。
I-Graphicsデコーダ 1 3は、 BD-ROM又は HDD 1 7から読み出されたィンタ ラクティブグラフイクスストリームをデコードして、 非圧縮グラフィクスを Interactive Graphicsプレーン 1 5に ざ込 。
スィッチ 1 4は、 フォントゼネレータ 1 2が生成したフォント列、 P-Graphics デコーダ 9のデコードにより得られたグラフィ クスの何れかを選択的に Presentation Graphicsプレーン 1 0に書き込むスイッチである。
Interactive Graphicsプレーン 1 5は、 I'Graphicsデコーダ 1 3によるデコー ドで得られた非圧縮グラフィクスが書き込まれる。
合成部 1 6は、 Interactive Graphicsプレーン 1 0の格納内容と、 合成部 8の 出力である合成画像 (非圧縮状態のピクチャデータと、 Presentation Graphicsプ レーン 7の格納内容とを合成したもの）とを合成する。
HDD 1 7は、 ネットワーク等を介してダウンロードされた SubClip、 Clip情 報、 プレイリスト情報が格納される内蔵媒体である。 この HDD 1 7中のプレイ リスト情報は BD-ROM及び HDD 1 7のどちらに存在する Clip情報であつても、 指定できる点で異なる。この指定にあたって、 HDD 1 7上のプレイリスト情報は、 BD-ROM 上のファイルをフルパスで指定する必要はない。 本 HDD 1 7は、 BD-ROMと一体になつて、 仮想的な 1つのドライブ (バーチャルパッケージと呼 ばれる）として、 再生装置により認識されるからである。 故に、 Playltem情報に お け る Clip_Information_file— name 及 ぴ SubPlayltem 情 報 の Clip— Information— file_nameは、 Clip情報の格納したファイルのファイルボディ にあたる 5桁の数値を指定することにより、 HDD 1 7、 BD-ROM上の AVClip を指定することができる。 この HDDの記録内容を読み出し、 BD-ROMの記録内 容と動的に組み合わせることにより、 様々な再生のバリエーションを産み出すこ とができる。
リードバッファ 1 8は、 FIFOメモりであり、 HDD 1 7から読み出された TS パケットが先入れ先出し式に格納される。
デマルチプレクサ (De-MUX) 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は、 命令 ROM2 4に格納されているソフトゥヱァを実行して、 再生 装置全体の制御を実行する。 - キーイベント処理部 2 3は、 リモコンや再生装置のフロントパネルに対するキ 一操作に応じて、 その操作を行うキーィベントを出力する。
命令 ROM2 4は、 再生装置の制御を規定するソフトウェアを記憶している。 スィッチ 2 5は、 BD-ROM及び HDD 1 7から読み出された各種データを、 リ ードバッファ 2、 リードバッファ 1 8、 シナリオメモリ 2 1、 ローカルメモリ 2 9のどれかに選択的に投入するスィツチである。
CLUT部 2 6は、 ビデオプレーン 5に格納された非圧縮グラフィクスにおける インデックスカラーを、 Y,Cr，Cb値に変換する。
GLUT部 2 7は、 Interactive Graphicsプレーン 1 5に格納された非圧縮ダラ フィクスにおけるインデックスカラーを、 Y，Cr，Cb値に変換する。
PSR セット 2 8は、 再生装置に内蔵されるレジスタであり、 64個の Player Status Register(PSR)と、 4096個の General Purpose Register (GPR)とからな る。 Player Status Registerの設定値 (PSR)のうち、 PSR4〜PSR8は、 現在の再 生時点を表現するのに用いられる。
PSR4は、 1〜： 100の値に設定されることで、現在の再生時点が属するタイ トル を示し、 0 に設定されることで、 現在の再生時点がトップメニューであることを 示す。
PSR5は、 1〜999の値に設定されることで、現在の再生時.点が属するチヤプタ 一番号を示し、 OxFFFFに設定されることで、 再生装置においてチャプター番号 が無効であることを示す。 PSR6は、 0~999の値に設定されることで、 現在の再生時点が属する PL (力レ ント PL)の番号を示す。
PSR7 は、 0〜255 の値に設定されることで、 現在の再生時点が属する Play Item (力レント Play Item)の番号を示す。
PSR8は、 0〜OxFFFFFFFFの値に設定されることで、 45KHzの時間精度を 用いて現在の再生時点 (力レント PTM(Presentation TiMe))を示す。以上の PSR4 〜PSR8により、 現在の再生時点が特定されることになる。
ローカルメモリ 2 9は、 BD-ROMからの読み出しは低速である故、 BD-ROM の記録内容を一時的に格納しておくためのキャッシュメモリである。 かかるロー カルメモリ 2 9が存在することにより、 BD-J モードにおけるアプリケーション 実行は、 効率化されることになる。 図 1 7 ( a ) は、 BD-ROM に存在している Javaアーカイブファイルを、口一カルメモリ 2 9上でどのように識別するかを示 す図である。 図 1 7 ( a ) の表は、 左欄に BD-ROM上のファイル名を、 右欄に ローカルメモリ 2 9上のファイル名をそれぞれ示している。 これら右欄、 左欄を 比較すれば、ローカルメモリ 2 9におけるファィルは、ディ レクトリ指定" BDJA" を省いたファィルパスで指定されていることがわかる。
図 1 7 ( b ) は、 図 1 7 ( a ) の応用を示す図である。 本応用例は、 ヘッダ + データという形式で、 ファイルに格納されているデータを格納するというもので ある。 何をヘッダに用いるがというと、 ローカルメモリ 2 9におけるファイルパ スを用いる。 図 1 7 (b ) に示したように、 ローカルメモリ 2 9では BD-ROM におけるファイルパスの一部を省略したものをファイルパスに用いるから、 当該 ファイルパスをヘッダに格納することで、 各データにおける BD-ROM上の所在 を明らかにすることができる。
以上が、 本実施形態に係る再生装置のハードウ ア構成である。 続いて本実施 形態に係る再生装置のソフトウヱァ構成について説明する。
図 1 8は、： OM 2 4に格納されたソフトウエアと、ハードウエアとからなる部 分を、 レイァ構成に置き換えて描いた図である。 本図に示すように、 再生装置の レイァ構成は、 以下の a),b),c)，d-l),d-2)，e)，£>からなる。 つまり、
a)物理的なハードウヱァ階層の上に、
b)AVClipによる再生を制御する Presentation Engine 3 1、 04 015330 c)プレイリスト情報及び Clip情報に基づく再生制御を行う Playback Control Engine 3 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 0¾)、 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を保持 して、 分岐制御を行う。 この分岐制御は、 JmnpTitleコマンドを HDMVモジュ —ル 3 3が実行した場合、 又は、 タイトルジャンプ APIが BD-Jモジュール 3 5 からコールされた場合、 そのジャンプ先と'なるタイ トル番号を受け取って、 その 夕イ トルを構成する Movieォブジェクト又は BD-Jオブジェクトを HDMVモジ ユール 3 3又は BD-Jモジュール 3 5に通知するというものである。 図中の V0， ▽1,V2が付された矢印は、 JumpTitleコマンドの実行 (0)、 モジュールマネージ ャ 3 4による IndexTable参照 (1)、分岐先 Movieオブジェクト（2)の通知を模式的 に示している。
以上が Presentation Engine 3 1〜モジュールマネージャ 3 4についての説明 である。 続いてアプリケーションマネージャ 3 6について、 図 2 0を参照しなが ら説明する。 図 2 0は、 アプリケーションマネージャ 3 6を示す図である。
アプリケーションマネージャ 3 6は、 アプリケーション管理テーブルを参照し たアプリケーションの起動制御、タイトルの正常終了時における制御を実行する。 起動制御とは、 モジュールマネージャ 3 4から分岐先となる BD-Jオブジェク トが通知される度に、 その BD-Jオブジェクトを読み出し、 その BD-Jオブジェ クト内のアプリケーション管理テ一ブルを参照して口一カルメモリ 2 9アクセス を行う。 そして現在の再生時点を生存区間とするアプリケーションを構成する xletプログラムを、 ワークメモリに読み出すという制御である。 図 2 0における ^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は、 アプリケーションを構成する letプログラムをヮ一 クメモリ 3 7にロードして、 xletプログラムを解読し、 解読結果に従った処理を JP2004/015330 実行する。 上述したように 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，02は、この Event Listner Manager 3 9による振り分けを模式的に示す。 START、 STOP, SPEED 等、 xletプログラム内の Event Listnerに登録されたキーイベントなら、 BD-J オブジェクトにより間接参照されている xletプログラムにかかるィベントを振り 分ける。 STAET、 STOP, SPEED は、 JMF に対応したイベントであり、 xlet プログラムの Event Listnerには、これらのキーイベントが登録されているので、 本キ一イベントにより xlet プログラムの起動が可能になる。 キ一イベントが Event Listner 非登録のキ一ィベントである場合、 本キーィベントを Default Operation Manager 4 0に振り分ける。 音声切り換え、 アンダル切り換え等、 BD-ROM再生装置において生じるキーイベントには、 Event Listnerに登録され ていない多様なものがあり、 これらのキーイベントが生じたとしても、 漏れの無 い処理を実行するためである。
Default Operation Manager 4 0は、 xletプログラム内の Event Listnerに登 録されてないキ一ィベントが Event Listner Manager 3 9から振り分けられると、 その Event Listner 非登録イベン ト に対応するフ ァンクショ ンコールを Playback Control Engine 3 2に対して実行する。 この Default Operation Manager 4 0によるファンクションコールを模式的に示したのが、 図中の矢印◊ 3である。 尚、 図 2 1において Event Listner非登録ィベントは Event Listner Manager 3 9、 Default Operation Manager 4 0により振り分けられたが、 Playback Control Engine 3 2がダイレクトに Event Listner非登録ィベントを 受け取り、 再生制御を行ってもよい (図中の◊ 。
(フローチャートの説明）
以上のアプリケーションマネージャ 3 6についての説明は、 その概要に触れた に過ぎない。 アプリケーションマネージャ 3 6の処理を更に詳しく示したのが図 2 2、 図 2 3のフローチャートである。 以降、 これらのフローチャートを参照し てアプリケーションマネージャ 3 6の処理手順についてより詳しく説明する。 図 2 2は、 アプリケーションマネージャ 3 6による分岐時の制御手順を示す図 である。 本フローチャートは、 ステップ S 2〜ステップ S 5がなす条件を満たす アプリケ一ション（アプリケ一シヨン X という）を、 起動又は終了させるという処 理である。 - ステップ S 2は、 分岐元タイトルで非起動だが、 分岐先タイ トルで生存してい て、 分岐先タイ トルにおける起動属性が AutoRun属性のアプリケーション Xが 存在するか否かの判定であり、 もしあれば、 ローカルメモリ 2 9に対するキヤッ シュセンスを行う。 キャッシュセンスの結果、 アプリケーション Xがローカルメ モリ 2 9上に有れば (ステップ S 7で Yes)、ローカルメモリ 2 9からワークメモリ 3 7にアプリケーション Xを読み込む（ステップ S 8)。 口一カルメモリ 2 9に無 ければ、 BD-ROMからローカルメモリ 2 9にアプリケーション Xを読み込んだ 上で、 口一カルメモリ 2 9からワークメモリ 3 7にアプリケーション Xを読み込 む (ステップ S 9)。
ステップ S 3は、 分岐元夕ィトルで起動中で、 分岐先タィトルで非生存のアブ リケ一シヨン Xが存在するかどうかの判定である。 もし存在するのなら、 アプリ ケーシヨン Xをワークメモリ 3 7から削除して終了させる（ステップ S 1 0)。 ステップ S 4は、 分岐元 Suspend、 分岐先 AutoRun又は Persistentのアプリ ケーシヨンが存在するか否かの判定である。 もし存在するなら、 アプリケ一ショ ン Xを Resumeする（ステップ S 1 1 )。
ステップ S 5は、分岐元タィトルで起動中で、分岐先 Suspendのアプリケーシ ヨンが存在するか否かの判定である。 もし存在すれば、 アプリケーション X を Suspendする（ステップ S 1 2 )。
個々のアプリケーションを終了させるにあたってのアプリケーションマネージ ャ 3 6の処理は、 図 2 3に示すものとなる。 図 2 3は、 アプリケーション終了処 理の処理手順を示すフローチャートである。 本図は、 終了すべき複数アプリケー シヨンのそれぞれについて、 ステップ S 1 6〜ステップ S 2 0の処理を繰り返す ループ処理になっている（ステップ S 1 5)。 本ループ処理においてアプリケーシ ョンマネージャ 3 6は起動中アプリケーションを終了するような terminateィベ ントを発行し（ステップ S 1 6 )、 タイマセットして (ステップ S 1 7)、 ステップ S 1 8〜ステップ S 2 0からなるループ処理に移行する。 この terminateイベント を Event Listnerが受信すれば、 対応する xletプログラムは、 終了プロセスを起 動する。終了プロセスが終了すれば、 その letプログラムはワークメモリ 3 7か ら解放され、 終了することになる。
ステップ S 1 8〜ステップ S 2 0のループ処理の継続中、 タイマはカウントダ ゥンを継続する。 本ループ処理においてステップ S 1 8は、 発行先アプリケーシ
3ンが終了したか否かの判定であり、 もし終了していればこのアプリケ一シヨン に対する処理を終える。 ステップ 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プ ログラムのように、 所定の期間内に終了しないアプリケーションがあれば、 ァプ 4 015330 リケーシヨンマネージャ 3 6は、 それらを強制的にワークメモリ 3 7.から取り除 く。 第 4段目は、 アプリケーションマネージャ 3 6による強制終了を示す。 かか る第 4段目の強制終了を規定するのも、 アプリケーションマネージャ 3 6の 1つ の使命といえる。
以上のように本実施形態によれば、 分岐元タイトルで起動しており、 分岐先タ ィ トルで生存していないアプリケーションは、 自動的に終了させられるので、 条 件付き分岐により再生が複雑に進行する場合でも、 再生装置におけるリソースの 限界を越える数のアプリケーション立ち上げはなされ無い。 分岐前後におけるァ プリケ一シヨン動作を保証することができるので、 デジタルストリームを再生さ せながら、 アプリケーションを実行させるようなディスクコンテンツを多く頒布 することができる。
(第 2実施形態）
第 1実施形態においてアプリケーションの生存区間は、 タイ トル時間軸と一致 していたが、 第 2実施形態は、 PL 時間軸の一部をアプリケーションの生存区間 とすることを提案する。 PL時間軸の一部は、チャプターにより表現されるので、 チャプターにて開始点、 終了点を記述することにより、 アプリケーションの生存 区間を規定することができる。 図 2 5 ( a ) は、 PL時間軸上に生存区間を定め たアプリケーション管理テーブルを示す図である。 図 2 5 ( a ) においてアプリ ケ一シヨン管理テ一ブルには、 3つのアプリケーションが記述されており、 この うち application#2は、 title#lの Chapter#2から Chapter#3までが生存区間に 指定され、 起動属性に AutoRunが規定されている。 このため application#2は、 図 2 5 ( b ) に示すように、 Chaptei#2の始点で起動され、 Chapter#3の終点で 終了することになる。
一方 application#3は、 title#lの Chapter#4から Chapter#6までが生存区間 に指定されている。 このため application#3は、 図 2 5 ( b ) に示すように、 図 2 5 ( b ) に示すように、 Chaptei#4の始点で起動され、 Chaptei#6の終点で終 了することになる。
こうして記述されたアプリケーション管理テーブルに基づき、 処理を行うため 本実施形態に係るアプリケーションマネージャ 3 6は、 PLmarkにより指示され るチヤプタ一開始点に到達する度に、 そのチヤプタ一開始点から生存区間が始ま るアプリケーションが存在するか否かを判定し、 もし存在すればそのアプリケー シヨンをワークメモリ 3 7にロードする。
同様に、 チャプター開始点に到達する度に、 そのチャプターの直前のチヤプタ —で生存区間が終わるアプリケーションが存在するか否かを判定し、 もし存在す ればそのアプリケ一ションをワークメモリ 3 7から解放する。
チャプターという単位でアプリケ一シヨンの生存を管理すれば、 アプリケ一シ ョンの生存区間をより細かい精度で指定することができる。 しかしディスクコン テンッには、 時間軸の逆向がありうることに留意せねばならない。 逆行とは、 巻 戻しにより時間軸を逆向きに進行することである。 チャプターの境界でこの逆行 と、 進行とが繰り返されれば、 ワークメモリへのロード、 廃棄が何度もなされ、 余分な読出負荷が生じる。 そこで本実施形態では、 アプリケーションの起動時期 を、 タイ トルに入って Playback Control Engine 3 による通常再生が開始され た瞬間にしている。 ここで PLの再生には、 通常再生、 トリック再生がある。 ト リック再生とは、早送り、巻戻し、 SkipNext，SkipBackがある。かかる、早送り、 巻戻し、 SkipNext,SkipBackがなされている間、 アプリケーション起動を開始せ ず、 通常再生が開始されて初めて、 アプリケーションを起動するのである。 通常 再生開始の瞬間を基準にすることにより、 上述したような生存区間前後の行き来 があった場合でも、 アプリケーションの起動が必要以上に繰り返されることはな い。尚、通常再生開始の瞬間を、アプリケーションの起動基準にするとの処理は、 生存区間が titleである場合にも、 実行してよい。
以上のように本実施形態によれば、 PL より小さい、 チャプターの単位でアブ リケ一シヨンの生存区間を規定することができるので、 緻密なアプリケーション 制御を実現することができる。
(第 2実施形態の変更例）
図 2 5では、 各アプリケーションに優先度が付与されている。 この優先度は、 0〜255の値をとり、アプリケーション間でリソースの使用が競合等が競合した場 合、 どちらのアプリケーションを強制的に終了させるか、 また、 どちらのアプリ ケーションからリソースを奪うかという処理をアプリケーシヨンマネージャ 3 6 が行うにあたって、 判断材料になる。 図 2 5の一例では、 application#l の優先 度は 255，application#2、 appUcation#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 タイトルと対比する上で、 想定した架空の 0 時間軸に過ぎない。 故に再生装置は、 非 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で No)、 どのアプリケーションも起動してない状態かどうかを判定す る。 もしそうなら、 同じく" タイ トルの終わり" であると解釈し、 モジュールマ ネージャ 3 4に終結を通知する（ステップ S 2 6)。
以上のように本実施形態によれば、 PL再生を伴わないタイ トルであっとして も、 アプリケーション実行中は分岐せず、 アプリケーション実行が終了して初め て分岐するという処理が可能になる。
(第 4実施形態）
本実施形態は、 DVDと同様のメニュー制御を BD-ROM上で実現する場合の改 良に関する。 図 2 8 ( a ) は、 BD-ROM により実現されるメニュー階層を示す 図である。 本図におけるメニュー階層は、 TbpMenu を最上位に配し、 この IbpMenuから下位の 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、 TbpMenu OBJ, AudioMenu OBJ, SubTitleMenu OBJが格納されている。
FirstPlayォブジ工クト（FirstPlay OBJ)は、 再生装置への BD-ROMのローデ ィング時に自動的に実行される動的シナリオである。
TbpMenuォブジヱクト（TopMenu OBJ)は、 TopMenuの挙動を制御する動的シ ナリオである。 ユーザがメニューコールを要求した際、 呼び出されるのはこの TopMenuオブジェクトである。 TopMenuオブジェクトは、 ユーザからの操作に 応じて TbpMenu中のボタンの状態を変えるものや、 ボタンに対する確定操作に 応じて分岐を行う分岐コマンドを含む。 この分岐コマンドは、 TopMenu から TitleMenu. TopMenuから SubTitleMenu、 TopMenuから AudioMenuという メニュー切り換えを実現するものである。
AudioMenuォブジェクト（AudioMenu OBJ)は、 AudioMenuの挙動を制御す る動的シナリォであり、 ユーザからの操作に応じて AudioMenu中のボタンの状 態を変えるコマンドゃ、 ボタンに対する確定操作に応じて音声設定を更新するコ マンドを含む。 '
SubTitleMenuォブジェクト（SubTitleMenu OBJ)は、 SubTitleMenuの挙動を 制御する動的なシナリオであり、 ユーザからの操作に応じて SubTitleMenu中の ボタンの状態を変えるコマンドゃ、 ボタンに対する確定操作に応じて字幕設定用 の PSRを更新するコマンドを含む。
TitleMenuオブジェクト（TitleMenu OBJ)は、 itleMenuの挙動を制御する動 的シナリオであり、 itleMenu中のボタンの状態を変えるものや、 ボタンに対す る確定操作に応じて分岐を行う分岐コマンドをふくむ。 これらのメニュー用 MOVIEオブジェクトにより、 DVDで実現されているよ うなメニューの挙動を実現することができる。 以上がメニュー制御に関連する MOVIEオブジェクトである。
図 2 9は、 Index Tableと、 Index Tableから各 Movieォブジェクトへの分岐 とを模式化した図である。本図では左側に Index Tableの内部構成を示している。 本実施形態における Index Table には、 FirstPLayINDEX、 TopMenuINDEX, Audio MenuINDEX, Subtitle MenuINDEX, title MenuINDEX. title#l~ #mINDEX、 title#m+l〜#nINDEX、 title#0INDEX を含む。 図中の矢印 bcl，2 は、 Index Tableから FirstPlayOBJへの分岐と， FirstPlayOBJから TopMenuへ の分岐とを模式的に示し、 矢印 bc3，4,5 は、 TopMenu から itleMenu、 Sub itleMenu, AudioMenuへの分岐を模式的に示している。 矢印 bc6，7，8は、 TitleMenuから各 Movieオブジェクトへの分岐を模式的に示している。
FirstPLaylNDEX、 TopMenuINDEX, Audio MenuINDEX、 Subtitle MenuINDEX, title MenuINDEXは、それぞれ、 FirstPLayOBJ, IbpMenuOBJ, Audio MenuOBJ, Subtitle MenuOBJ, title MenuOBJについての Indexであ り、 これらの識別子が記述される。
title#l〜#mINDEXは、 BD-ROMにおいて 1から m番目にエントリーされて \、る titleについての Indexであり、これら 1から瓜までの title番号の選択時に おいて分岐先となる MOVIEオブジェクトの識別子 (ID)が記述される。
title#m+l〜#nINDEXは、 BD-ROMにおいて m+1から n番目にエントリー されている titleについての Indexであり、 これら m+1から nまでの title番号 の選択時において分岐先となる BD-Jォブジヱクトの識別子 (ID)が記述される。 title#0INDEXは、 BD-Jォブジヱクトの強制終了時において分岐先になるべき Movieォブジェクト又は BD-Jォブジェクトを規定する INDEXである。 本実施 形態では、 TopMenuOBJについての識別子が、 この title#0INDEXに格納され ている。
図 3 0 ( a ) は、 図 2 9のように Index Tableが記述された場合における分岐 を示す。. Index Tableがこのように記述されているので、 ラベル title#l〜title#m を分岐先とした分岐コマンドの実行時には、 title#llndex〜titie#mlndex から Movieォブジェクト #l〜#mの識別子が取り出される。ラベル title#m+l〜title#n 15330 を分岐とした分岐コマンドの実行時には、 title#m+llndex〜title#nlndex から BD-J オブジェクト #m+l〜#n の識別子が取り出される。 BD-J ォブジェクト #m+l〜#n の識別子は、 フ ァイル名を表す 5 桁の数値であるので、 r00001.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は、タイトルジャンプ A^Iの呼び出しがあつたか否かの判定で ある。 もしタイ トルジャンプ 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 は、 PL再生 APIがコ一ルされれば、 PL情報に 基づく処理手順を実行する。 PLが 2時間という再生時間を有するなら、 この 2 時間の間、 上述した処理は継続することになる。 ここで問題になるのは、 Java 仮想マシン 3 8がサクセス応答を返す時間と、 Playback Control Engine 3 2が 実際に処理を終える時間とのギヤップである。 Java仮想マシン 3 8は、 ィベント ドリブンの処理主体であるためコール直後に再生成功か、 再生失敗かを示す応答 を返すが、 Playback Control Engine 3 2による実際の処理終了は 2時間経過後 5330
であるので、 サクセス応答をアプリケーションに返す時間を基準にしたのでは、
2時間経過後にあたる処理終結を感知しえない。 PL再生において早送り、巻戻し、 Skipが行われると、この 2時間という再生期間は 2時間前後に変動することにな り、 処理終結の感知は更に困難になる。
Playback Control Engine 3 2は、 アプリケーションとスタンドアローンで動 作するため、 第 3実施形態のような終了判定では、 PL再生の終了をタイ トル終 了と解釈することができない。 そこで本実施形態では、 アプリケーションが終了 してようがいまいが、 ワークメモリ 3 7に JMFプレーヤィンスタンスがある限 り、つまり、 Presentation Engine 3 1の制御権を BD-Jモジュール 3 5が掌握し ている間、 Playback Control Engine 3 2から再生終結イベントを待つ。 そして 再生終結イベントがあれば、 タイ トルが終了したと解釈して、 次のタイトルへの 分岐を行うようモジュールマネージャ 3 4に通知する。 こうすることにより、 Playback Control Engine 3 2が PL再生を終結した時点を、タイ トルの終端とす ることができる。
以降図 3 3〜図 3 7のフローチャートを参照して、 Playback Control Engine 3 2による具体的な制御手順を説明する。
図 3 3は、 Playback Control Engine 3 2による PL再生手順を示すフローチヤ ートである。 この再生手順は、 Presentation Engine 3 1に対する制御 (ステップ S 4 6 )と、 BD-ROM ドライブ 1又は HDD 1 7に対する制御 (ステップ S 4 8 ) とを主に含む。本フローチャートにおいて処理対象たる Playltemを Playltem#x とする。本フローチャートは、 カレント PL情報 (.mpls)の読み込みを行い (ステツ プ S 4 1 )、 その後、 ステップ S 4 2〜ステップ S 5 0の処理を実行するというも のである。 ここでステップ S 4 2〜ステップ S 5 0は、 ステップ S 4 9が Yesに なるまで、 カレント PL情報を構成するそれぞれの PI情報について、 ステップ S 4 3〜ステップ S 5 0の処理を繰り返すというループ処理を構成している。 この ル―プ処理において処理対象となる Playltemを、 PlayItem#x(PI#x)とよぶ。 こ の Playltem#xは、 カレント PLの先頭の Playltemに設定されることにより、初 期化される（ステップ S 4 2 )。 上述したループ処理の終了要件は、 この Playltem# がカレント PLの最後の Playltemになることであり（ステップ S 4 9 )、 もし最後の Playltemでなければ、 カレント PLにおける次の Playltemが Playltem#xに設定される（ステップ S 5 0 )。
ループ処理において繰り返し実行されるステップ S 4 3〜ステップ S 5 0は、 Playltem# の 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_stam から 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#xに設定して（ステツプ S 5 0)、 ステップ S 4 3に戻 る。 以上のステップ S 4 3〜ステップ S 5 0を繰り返することにより、 PL を構 成する PIは順次再生されることになる。
図 3 4は、 アングル切り換え手順及ぴ SkipBack，SkipNextの手順を示すフ口 一チャートである。 本フローチャートは、 図 3 3の処理手順と並行してなされる ものであり、 ステップ S 5 1〜S 5 2からなるループ処理を繰り返すというもの である。 本ループにおけるステップ S 5 1は、 アングル切り換えを要求する API が、 Java仮想マシン 3 8からコールされたか否かの判定であり、 アングル切り換 え APIのコールがあれば、 カレント Clip情報を切り換えるという操作を実行す る。
図 3 4のステップ S 5 5は、 判定ステップであり、 Playltem#x の is— multi— angles がオンであるか否かの判定を行う。 is— 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)、 Playltem#xにおける y番目の Clip— information_file_nanieで指定されて いる Clip情報をシナリオメモリ 2 1に読み出し (ステップ S 5 7)、カレント PTM を、 カレント Clip情報の EP— mapを用いて Iピクチャアドレス uに変換し（ステ ップ S 5 8)、 Playltem#xの Outjimeを、 カレント Clip情報の EP一 mapを用 いて Iピクチャアドレス Vに変換する（ステップ S 5 9)というものである。 こう して Iピクチャアドレス u，vを変化した後、 ステップ S 4 6に移行する。 ステツ プ S 4 6への移行により、 別の AVClipから TSバケツトが読み出されるので、 映像内容が切り換わることになる。
一方、 図 3 4のループにおけるステップ S 5 2は、 SkipBack/SkipNextを意味 する APIが Java仮想マシン 3 8からコールされたか否かの判定であり、 もしコ ールされれば、 図 3 5のフローチャートの処理手順を実行する。 図 3 5は、 SkipBack, SkipNextAPIがコールされた際の処理手順を示すフローチャートであ る。 SkipBack,SkipNextを実行するにあたっての処理手順は多種多様なものであ る。 ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
ステップ S 6 1は、 PSRで示される力レント PI番号、 及び、 カレント PTM を変換することにより、 カレント Mark情報を得る。 ステップ S 6 2は、 押下さ れたのが SkipNext キーであるか、 SkipBack キーであるかの判定であり、 SkipNext キーであるならステップ S 6 3において方向フラグを +1 に設定し、 SkipBackキーであるならステップ S 6 4において方向フラグを- 1に設定する。 ステップ S 6 5は、カレント PLMarkの番号に方向フラグの値を足した番号を、 力レント PLMarkの番号として設定する。 ここで SkipNextキーであるなら方向 フラグは +1に設定されているのでカレント PLMarkはインクリメントされるこ とになる。 SkipBackキーであるなら方向フラグは- 1に設定されているので、 力 レント PLMarkはデクリメントされることになる。
ステップ S 6 6では、 カレント PLMarkの ref— to— Playltem— Idに記述されて いる PI を、 Playltem# に設定し、 ステップ 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の Outjimeを,カレント Clip情報の EP— mapを用いて, Iピク チヤア ド レス V に変換する。 ステップ S 7 0は、 カ レン ト PLMark の mark— time— stamp 力、り Playltein#x の Out— time までの出力を Presentation Engine 3 1に命じた上で、 図 3 3のステップ S 4 7に移行する。 こうして Iピク チヤアドレス u，vを変化して、 別の部分の再生を命じた上でステップ S 4 7への 移行するので、 別の AVClipから TSバケツトが読み出されることになり、 映像 内容が切り換えが実現する。 - 図 3 6は、 Presentation Engine 3 1による処理手順の詳細を示すフローチヤ ートである。 本フローチャートは、 Iピクチャの PTSを力レント PTMに設定し た後で (ステップ S 7 1 )、 ステップ S 7 2〜ステップ S 7 7からなるループ処理 を実行するものである。
続いてステップ S 7 2〜ステップ S 7 7におけるループ処理について説明する。 このループ処理は、カレント PTMにあたるピクチャ、オーディォの再生出力と、 カレント PTMの更新とを繰り返すものである。 本ループ処理におけるステップ S 7 6は、 ループ処理の終了要件を規定している。 つまりステップ S 7 6は、 力 レント PTMが PI#xの Out— timeであることをループ処理の終了要件にしている。 ステップ S 7 3は、 早送り API、 又は、 早戻し APIが Java仮想マシン 3 8か らコールされたか否かの判定である。 もしコールされれば、 ステップ S 7 8にお いて早送りか早戻しかの判定を行い、 早送りであるなら、 次の Iピクチャの PTS を力レント PTMに設定する（ステップ S 7 9)。 このように力レント PTMを、 次 の Iピクチャの PTSに設定することで、 1秒飛びに AVClipを再生してゆくこと ができる。 これにより、 2倍速等で AVClipは順方向に早く再生されることにな る。 早戻しであるなら、 カレント PTMが Playltem#xの Out_timeに到達した かを判定する（ステップ S 8 0)。 もし到達してないのなら、 1つ前の Iピクチャの PTSを力レント 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 により、 Playltem# を指定した SubPlayItem#yが存在するか否かの判定であり、 もし存在すれば、図 3 7のフロ 一チャートに移行する。 図 3 7は、 SubPlayltemの再生手順を示すフローチヤ一 トである。本フローチャートでは、先ずステップ S 8 6において、 カレント PTM は SubPlayItem#yの sync— start— PTS_of_j)layIteniであるか否かを判定する。も しそうであれば、 ステップ S 9 3において SubPlayItem#yに基づく再生処理を 行うよう Playback Control Engine 3 2に通知する。
図 3 7のステップ S 8 7〜ステップ S 9 2は、 SubPlayItem#yに基づく再生処 理を示すフローチャートである。
ステップ S 8 7では、 SubPlayItem#yの Clip— information— file— nameで指定 される Clip情報を読み込む。ステップ S 8 8では、カレント Clip情報の EP— map を用いて、 SubPlayItem#yの In— time を、 アドレス に変換する。 一方ステツ プ S 8 9では、 SubPlayItem# の Outjimeを,カレント Clip情報の EP_mapを 用いて、 アドレス に変換する。 ステップ S 9 0は、 SubPlayItem#yの In— time から SubPlayItem#yの Out— timeまでの出力をデコーダに命じる。 これらの変 換で得られたァドレス 13の次の Iピクチャを求めて、 そのァドレスの 1つ手前を アドレス yに設定し (ステップ S 9 1 )、そうして算出されたアドレス yを用いて、 SubClip#zにおけるアドレス aからアドレス Ίまでの 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；)、 ステップ S 2 2、ステップ S 2 3は スキップされる。 そのため、 たとえ全てのアプリケーションが終了したとしても タイトルは継続中と解釈される。
以上のように本実施形態によれば、 2時間という再生時間の経過時点をアプリ ケーシヨンマネージャ 3 6は把握することができるので、 PL再生の終了条件に メニューを表示して、 このメニューに対する操作に応じて他のタイ トルに分岐す るという制御を実現することができる。
(第 6実施形態） 0 第 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におけるアプリケーションの占有領域の P2004/015330 解放を示す。 矢印上の注釈は、 これらの読み込みが、 どのようなタイミングでな されるかを示す。 注釈によると、 ワークメモリ 3 7上の解放は、 アプリケーショ ン終了と同時になされることがわかる。 一方ローカルメモリ 2 9上の解放は、 Java仮想マシン 3 8にとつて必要でなくなつた時点でなされる。この必要でなく なった時点とは、" 終了時点" ではない。" 終了した上、 再起動の可能性もない時 点"であること、つまり該当する titleが終了した時点を意味する。上述した読込- 解放のうち、 ワークメモリ 3 7における解放時点は、 アプリケーション管理テー ブルにおける生存区間から判明する。 しかし" アプリケーションが必要となる以 前の時点"、" 終了した上、 再起動の可能性もない時点" については、 規定し得な い。 そこで、 ォーサリング段階において、 かかる時点をディスクコンテンツ全体 の時間軸上で規定しておくため、 本実施形態では各アプリケーションが生存して いる区間を、 アプリケーション管理テーブルとは別に、 データ管理テ一ブルに記 述するようにしている。 つまり" アプリケーションが必要となる以前の時点" を データ管理テーブルにおける生存区間の始点と定義し、"終了した上、再起動の可 能性もない時点" をデータ管理テ一プルの終点と定義することにより、 上述した 口一カルメモリ 2 9上の格納内容の遷移をォーサリング時に規定しておくことが できる。 これがデ一タ管理テ一ブルの記述意義である。
データ管理テーブルによるローカルメモリ 2 9生存区間の記述について説明す る。 ここで制作しょうとするディスクコンテンツは 3 つのタイ トル (title#l、 title#2、 title#3)からなり、 これらタイトルの時間軸において、 図 4 1 ( b ) に示 すようなタイミングで、 ローカルメモリ 2 9を使用したいと考える。 この場合、 title#l時間軸の開始点において application#l、 application#2を構成する Java ァ一力イブフアイルをローカルメモリ 2 9に読み込み、 title#l 時間軸の継続中、 application#l, application#2 をローカルメモリ 2 9に常駐させておく。 そして title#2時間軸の始点で、 application#lを構成する Javaアーカイブフアイルを口 一カルメモリ 2 9から解放して、代わりに application#3を構成する Javaァ一力 イブファイルを口一カルメモリ 2 9に読み込んで、 常駐させるというものである (以降、 アプリケーションを構成する Javaアーカイブファイルは、 アプリケーシ ヨンと同義に扱う。 ）。 この場合のデータ管理テーブルの記述は、 図 4 1 ( a ) の 通りであり、 アプリケーションの applicationIDを、 その生存区間に対応づけて 04 015330 記述することで、ローカルメモリ 2 9に常駐すべきアプリケーションを表現する。 図 4 1 ( a ) では、 application#lの applicationlDが title#lと対応づけられて 記述されており、 application#2の applicationlDは title#l、 title#2と対応づけ られ、 application#3の applicationlDは title#3と対応づけられて記述されてい ることがわかる。 こうすることで、 ローカルメモリ 2 9占有の時間的遷移がォー サリング担当者により規定されることになる。
データ管理テーブル、 アプリケーション管理テ一プルの組合せとしては、 ァプ リケーシヨン管理テーブルに規定する生存区間は、 細かい再生単位にし、 データ 管理テーブルに規定する生存区間は、 大まかな再生単位にすることが望ましい。 大まかな再生単位には、 タイ トル、 PL といった非シームレスな再生単位が望ま しい。 一方、 細かい再生単位としては、 PL 内のチャプターというようにシ一ム レスな再生単位が望ましい。 アプリケーションの生存区間をタイ トル毎、 PL毎 に定めれば、 アプリケーションは口一カルメモリ 2 9上に存在するので、 その夕 ィ トルの再生中においてアプリケーションは何時でも取り出せる状態になる。 そ うであれば、 アプリケーションの生存区間を細かく定めたとしても、 アプリケー シヨンを即座に、 仮想マシン上のワークメモリに読み出すことができるので、 ァ プリケーシヨンの起動'終了が頻繁になされたとしても、スムーズなアプリケ一シ ョン実行を実現することができる。
次に、 読込属性について説明する。
図 2において Javaアーカイブフアイルほ、 AVClipとは別の記録領域に記録さ れることを前提にしていた。 しかしこれは一例に過ぎない。 Javaアーカイブファ ィルは、 BD-ROMにおいて AVClipが占める記録領域に埋め込まれることがある。 この埋め込みの態様には、 カル一セル化、 インターリーブユニット化という 2種 類がある。
ここで" カルーセル化" とは、 対話的な放送の実現のために同一内容を繰り返 しするという放送方式に変換することである。 BD-ROM は、 放送されたデータ を格納するものではないが、 本実施形態では、 カルーセルの放送形式に倣って JAVA アーカイブファイルを格納するようにしている。 図 4 2は、 カル一セル化 による Javaアーカイブファイル埋め込みを示す図である。 第 1段目は、 AVClip 中に埋め込む Javaアーカイブファイルであり、 第 2段目は、 セクション化を示 す。 第 3段目は、 TSバケツト化、 第 4段目は、 AVClipを構成する TSバケツト 列を示す。 こうしてセクション化、 TSバケツト化されたデータ（図中の" D" )が、 AVCli に埋め込まれるのである。カルーセルにより AVClipに多重化された Java アーカイブファイルは、読み出すにあたって、低帯域で読み出されることになる。 この低帯域での読み出しは、 概して 2〜3分というように長期間を要するため、 再生装置は Javaアーカイブファイルを 2〜3分をかけて読み込むことになる。 図 4 3は、 ィンターリーブ化による Javaアーカイブファイル埋め込みを示す 図である。 第 1段目は、 埋め込まれるべき AVClip、 第 2段目は、 AVClipにイン タ一リ一ブ化された Javaアーカイブファイル、第 3段目は、 BD-ROMの記録領 域における AVClip配置である。 本図に示すように、 ストリームに埋め込まれる べき Java アーカイブファイルは、 インターリーブ化され、 AVClip を構成する XXXXX.m2ts を構成する分割部分 (図中の AVClip2/4,3/4)の合間に記録される。 インタ一リ一ブ化により AVClipに多重化された Javaアーカイブフアイルは、力 ルーセル化と比較して、 高い帯域で読み出されることになる。 この高い帯域での 読み出しであるため、 再生装置は Javaアーカイブフアイルを比較的短期間に読 み込むことになる。
カル一セル化'インターリーブ化された Javaアーカイブファイルは、 プリ口一 ドされるのではない。 BD-ROMにおける AVClipの記録領域のうち、 カルーセル ィ匕 'インターリーブ化された Javaアーカイブファイルが埋め込まれた部分に、現 在の再生時点が到達した際、 再生装置のローカルメモリ 2 9にロードされる。 Javaアーカイブファイルの記録態様には、 図 2に示すものの他に、 図 4 2、 図 4 3 ( a ) に示すものがあるので、 読込属性は、 図 4 3 ( b ) に示すように、 設定 されうる。 図 4 3 ( b ) に示すように、 読込属性は、 タイトル再生に先立ち、 口 一カルメモリ 2 9に読み込まれる旨を示す" Preload" と、 タイ トル再生中に、 カルーセル化方式で読み込まれる旨を示す" Load. Carousel" と、 タイ トル再生 中に、 インターリーブ化方式で読み込まれる旨を示す" Load.InterLeave" とが ある。 読込属性には、 カル一セル化されているか、 インターリーブ化されている かが添え字で表現されているが、 これを省略してもよい。
データ管理テーブルにおける生存区間の具体的な記述例について、 図 4 4を参 照しながら説明する。 図 4 4 ( a ) は、 データ管理テーブルの一例を示す図であ 2004/015330 る。 図 4 4 ( b ) は、 かかるデータ管理テーブルの割り当てによるローカルメモ リ 2 9の格納内容の変遷を示す図である。 本図は、 縦軸方向にローカルメモリ 2 9における占有領域を示し、横軸を、 1つのタイトル内の PL時間軸としている。 データ管理テーブルにおいて application#lは、 1つのタイ トル内の PL時間軸全 体を生存区間とするよう記述されているので、 このタイ トルの Chapter#l〜 C aptei#5においてローカルメモリ 2 9内の領域を占有することになる。 データ 管理テーブルにおいて application#2は、タイトル内の PL#1における Chapter#l ~ Chapter を生存区間とするよう記述されているので、 このタイ トルの Cliapter#l〜Cliapter#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 1 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 I 1 5 )。 もしステップ S 1 1 3において読込属性がロード 4 015330 であると判定されれば、 ステップ S 1 1 4〜ステップ S 1 1 5はスキップされる ことになる。
ループ処理の終了要件を規定する 2 つのステップのうちステップ S 1 1 6は、 applicationIDが次に高く、アプリケーション iと同一読込優先度のァプリケ一シ ヨン kが存在するか否かを判定するものである。 そのようなアプリケーション k が存在するなら、そのアプリケーション kをアプリケーション iにする（ステップ
Figure imgf000054_0001
ループ処理の終了要件を規定する 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 は同じであるが (applicationlD^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にロードされることになる。
0読込優先度 = mandatoryのアプリケーションを読み込んだ後、 読込優先度 = optional: igh のアプリケーションを読み込むにあたって、 ステップ S 1 2 2が Noと判定されればれば、 読込優先度 = mandatoryのアプリケーションが口一力 ルメモリ 2 9に残ることになる。読込優先度 -mandatoryのアプリケーションを 読み込んだ後、読込優先度 =optional:highのアプリケ一ションを読み込むにあた つて、 ステップ S 1 2 2が Yesと判定されれば、
Figure imgf000056_0001
のァ プリケーシヨンにより、読込優先度 = 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とは別フ 7ィルに記録されていて、 読込優先度が Optionalに設定されて いる。 前者のアプリケーションは、 AVClip に埋め込まれているので、 その埋込 部分にあたる生存区間が、 生存区間 (title#l:chapter#4〜#5)として記述されてい る。 これらのアプリケーションのうち application#2、 application#3には、 ロー ドを示す読込属性が付与されている。 application#2 は Chapter#l〜Chapter#2 を生存区間にしており、 application#3は Chapter#4〜Chaptei#5を生存区間に しているので、 タイトル時間軸においてどちらか一方が排他的に口一カルメモリ 2 9上に常駐することになる。 図 4 8 ( b ) は、 タイトル時間軸上の別々の時点 において、 排他的に格納される application#2、 application#3 を示す図である。 これは必要最低限のメモリ規模しかもたない再生装置での再生を念頭に置いた配 慮である。 こうした内容のデ一タ管理テーブルが処理対象であるとアプリケーシ ョンマネージャ 3 6は、 上述した図 4 6のフローチャートによりメモリ規模に応 じて異なる処理を行う。
後者のアプリケーションは、 読込優先度 =ロードであるので、 口一カルメモリ 2 9にロードされる。 かかる処理により、 Mandatoryなメモリ規模さえあれば、 アプリケーシヨンマネージャはデータをローカルメモリ 2 9にロードすることが できる。 ここで問題になるのは、 メモリ規模が大きい再生装置による読み込み時 である。 メモリ規模が大きいにも拘らず、 Chapter#4〜Chapter#5に到達するま で application#3を読み込めないというのは、 メモリ規模の無駄になる。 そこで 本図のデータ管理テーブルには、 同じ application#3にプリ口一ドを示す読込属 性を付与して BD-ROMに記録しておき、 これらに同じ applicationIDを付与し ている。
前者のアプリケーションは、読込優先度 =Optionalであるので、 ステップ S 1 2 1が Yesになった場合に限り、 プリロードされる（ステップ S 1 1 5 )。 こうす ることで、 メモリ規模が大きい再生装置は、 title#l、 Chapter#4〜Chapter#5の 到達を待つことなく、 AVClip に埋め込まれているのと同じアプリケーションを ローカルメモリ 2 9にロードすることができるのである (図 4 8 ( c ) )。
以上がプリロード時における処理である。 続いてロード時における処理手順に ついて説明する。
図 4 9は、データ管理テーブルに基づくロード処理の処理手順を示す図である。 本フローチャートは、 ステップ S 1 3 1〜ステップ S 1 3 3からなるループ処理 を、 タイ トル再生が継続されている間、 繰り返すというものである。
ステップ S 1 3 1は、 AutoRunを示す起動属性を有したアプリケーションの生 存区間が到来したか否かの判定である。 もし到来すれば、 AutoRunを示す起動属 性を有したアプリケーションをアプリケーション qにして（ステップ S 1 3 4)、 アプリケーション qを起動する旨の起動指示を Java仮想マシン 3 8に発行して、 アプリケーション qをローカルメモリ 2 9からワークメモリ 3 7に読み出させる (ステップ S 1 3 5)。
ステップ S 1 3 3は、 タイトル内 PLの再生が全て終了したかの判定である。 この判定は、 第 5実施形態に示したように、 Playback Control Engine 3 2から の再生終結イベントがあつたか否かでなされる。 もし終了すれば、 本フローチヤ —トの処理を終了する。
ステップ S 1 3 2は、 起動中アプリケーションからの呼出があつたか否かの判 定である。 もしあれば、呼出先アプリケーションをアプリケーション qにして（ス テツプ S 1 3 6)、 現在の再生時点は、 アプリケーション管理テ一ブルにおける アプリケーション qの生存区間であるか否かを判定する（ステップ S 1 3 7)。 も し生存区間でなければ、 起動失敗を表示して (ステップ S 1 4 8)、 ステップ S 1 3 1〜ステップ S 1 3 3からなるループ処理に戻る。 生存区間であれば、 図 5 0 のフローチャートに従い、 ロード処理を行う。
図 5 0におけるステップ S 1 3 8は、 現在の再生時点がデータ管理テーブルに おけるアプリケーシヨン qの生存区間であるか否かを示す判定である。 もし生存 区間でなければ、 アプリケーション qはローカルメモリ 2 9にロードすることが できない。 この場合、 アプリケーション qを起動する旨の起動指示を Java仮想 マシン 3 8に発行し、 ローカルメモリ 2 9を介することなく、 直接アプリケ一シ ヨン qを BD-ROMからワークメモリ 3 7に読み出させる。 この場合アプリケー シヨンを読み出すためのへッドシークが発生するから、 PL再生は中断すること になる（ステップ S 1 4 5)。
もし生存区間であれば、 ステップ S 1 3 9において、 アプリケーションには読 込属性が付加されているか否かを判定する。 読込属性がないということは、 アブ リケ一シヨン qは、 カルーセル化、 若しくはインターリーブ化されていないこと を意味する。 しかし読込属性が付加されていなくても、 口一カルメモリ 2 9にァ プリケ一シヨン qを置くことは許される。 そこで再生中断を承知の上、 アプリケ . ーシヨンの読み出しを行う。 つまり BD-ROMから口一カルメモリ 2 9へとァプ リケーシヨンを読み出した上で、 アプリケーションをワークメモリ 3 7に読み出 す (ステップ S 1 4 0)。
ステップ S 1 4 1〜ステップ S 1 4 6は、 ステップ S 1 3 9が Yesと判定され た場合になされる処理である。 ステップ S 1 4 1では、 読込属性を参照すること で、 アプリケーションがプリロードされているか否かを判定する。 プリロードさ れていれば、 ステップ S 1 3 5に移行する。
ステップ S 1 4 2は、 読込属性がロードである場合に実行される判定ステップ であり、 アプリケーション qがカルーセル化されているか、 インターリーブイ匕さ れているかを判定する。 インターリーブ化されていれば、 キャッシュセンスを Java仮想マシン 3 8に実行させる（ステップ S 1 4 3)。 口一カルメモリ 2 9にァ プリケーシヨン qが存在すれば、 ステップ S 1 3 5に移行して、 アプリケーショ ,ン qを Java仮想マシン 3 8にロードさせる。
ローカルメモリ 2 9にアプリケーションがなければ、 トップメニュータイ トル に分岐する等の例外処理を行う（ステップ S 1 4 4)。 カルーセル化されていれば、 タイマをセットし（ステップ S 1 4 8)、 そのタイマがタイムァゥトするまで (ステ ップ S 1 4 7)、キャッシュセンスを Java仮想マシン 3 8に実行させる（ステップ S 1 4 6)。 もしローカルメモリ 2 9にアプリケ一ション qが出現すれば、 図 4 9 のステップ S 1 3 5に移行して、 アプリケーション qを Java仮想マシン 3 8に ロードさせる。 タイムアウトすれば、 トップメニュータイトルに分岐する等の例 外処理を行う（ステップ S 1 4 4)。
図 5 1は、 Java仮想マシン 3 8によるアプリケーシヨンの読み込みがどのよう にして行われるかを模式ィ匕した図である。
矢印 ©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からのダイレクトリ一ドの要求を示す。矢印 V2 はその要求による、 BD-ROMからワークメモリ 3 7への Javaアーカイブフアイ ル読み出しを示す。
矢印 1,2，3は、 アプリケーション管理テーブルに生存していて、データ管理テ 一ブルに生存しているが、 読込属性が存在しない Javaアーカイブファイルの読 み込みを示す。
矢印 1は、 ステップ S 1 4 0における読み込みに対応するものであり、 Java 仮想マシン 3 8による BD-ROMからのダイレクトリードの要求を示す。矢印 2 はその要求による、 ローカルメモリ 2 9への Javaアーカイブファイルの読み出 しを示す。 矢印 3 は口一カルメモリ 2 9からワークメモリ 3 7への Javaァ一 カイプフアイルの読み出しを示す。
以上のように本実施形態によれば、 ローカルメモリ 2 9上で同時に常駐される アプリケーションの数が所定数以下になるように規定しておくことができるので、 ローカルメモリ 2 9からの読み出し時におけるキャッシュミスを極力回避するこ とができる。 キャッシュミスのないアプリケーシヨン読み出しを保証することが できるので、アプリケーション呼出時にあたては、 AVClipの再生を止めてまで、 BD-ROMからアプリケーションを読み出すことはなくなる。 AVClip再生を途切 れさせないので、 AVClipのシームレス再生を保証することができる。
(第 7実施形態） 30 第 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再生は、アプリケーションの 15330 起動失敗とは関係なしに行われるので、 デフォルト PLの時間軸がタイ トル時間 軸になる。
以上のようにプレイリスト管理テーブルの再生属性を、" AutoPlay" に設定し ておけば、 Javaアプリケーションの起動に、 5〜10秒という時間がかかったとし ても、 その起動がなされている間、" とりあえず何かが写っている状態" になる。 この" とりあえず何かが写っている状態" によりタイトル実行開始時のスタート アップディ レイを補うことができる。
以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。
図 5 2 ( c ) は、 分岐先タイトルのプレイリスト管理テーブルにおいて、 再生 属性が AutoPlayに設定された PLが存在する場合、 再生装置がどのような処理 を行うかを示す図である。 本図に示すように、 再生属性が AutoPlayに設定され た PLが、分岐先タィ トルのプレイリスト管理テーブルに存在すれば、 BD-Jモジ ユール 3 5内のアプリケーシ 3ンマネージャ 3 6は、 タイ トル分岐直後にこの AutoPlayPLの再生を開始するよう Playback Control Engine 3 2に指示する。 このように再生属性が AutoPlayの PLは、 タイトル分岐直後に再生開始が命じ られることになる。
上述した記録媒体の改良に対応するため、 アプリケーションマネージャ 3 6は 図 5 4に示すような処理手順で処理を行う。
図 5 4は、 第 7実施形態に係るアプリケーションマネージャ 3 6の処理手順を 示すフローチャートである。 本フローチャートは、 図 3 8のフローチャートにお いてステップ S 2 1の前にステップ S 1 0 3、 ステップ S 1 0 4を追加し、 ステ ップ S 2 1と、 ステップ S 2 2との間にステップ S 1 0 0を追加し、 ステップ S 2 3 _ステップ S 2 6間に、 ステップ S 1 0 5を追加したものである。
ステップ S 1 0 3は、 対応するタイトルのプレイリスト管理テーブルの再生属 性が AutoPlayであるか否かの判定である。 もし AutoPlayなら、 デフォルト PL に対する再生制御を Playback Control Engine 3 2に開始させる（ステップ S 1 0 4)。
ステップ S 1 0 0は、 Presentation Engine 3 1による再生中であるか否かを 判定する。 もし再生中であるなら、 ステップ S 1 0 1に移行する。 ステップ S I 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に予めアプリケーシヨンをロードしておく 旨を示す起動属性の類型である。
図 5 6 ( b ) は、 アプリケーションの扱いと、 起動属性との関係を示した図で ある。 第 1実施形態に示したようにアプリケーションの扱いには、 プリロードさ れるか否か (1)、 現在の再生時点が有効区間に到来した際自動的に起動されるか、 P T/JP2004/015330 他からの呼出に応じて起動されるか (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は、同じ applicationID が付与されたアプリケーションを、 読込優先度に従い排他的にローカルメモリ 2 9にロードするとしたが、 第 1 0実施形態は、 アプリケーションにグループ属性 を与えることにより、 排他的なロードを実現する。 図 5 9は、 グループ属性が付 与されたデータ管理テーブルを示す図である。 グループ属性には、 排他グループ なし、 排他グループあり、 といった、 2通りの設定が可能であり、 排他グループ ありの場合、 そのグループ番号が記述される。 図 5 9 ( a ) における title#l の 「一」は、排他グループが存在しないことを示す。一方、 title#2,#3の「group#l」 は、 排他グループがあり、 title#2,#3 は、 group#l という排他グループに帰属し ていることを示す。 以上が本実施形態に係る記録媒体の改良である。
本実施形態に係る再生装置は、 データ管理テーブルに基づいて各アプリケ一シ ヨンをローカルメモリ 2 9に読み込んだ後、 ローカルメモリ 2 9のアプリケ一シ ョンにおけるグループ属性をベリフアイする。 同じ排他グループに帰属するアブ リケーシヨンが、 ローカルメモリ 2 9上に 2つ以上存在していれば、 そのうち一 方をローカルメモリ 2 9から削除する。
こうすることにより、 ローカルメモリ 2 9の利用効率を向上させることができ る。 排他グループの具体例としては、 ランチャーアプリと、 このアプリにより起 動されるアプリとからなるグループが相応しい。 本アプリケーションにより起動 されるアプリケーションは、原則 1つに限られるので、ローカルメモリ 2 9には、 ランチャー + 1個のアプリケーションのみが存在する箦である。 もし 3つ以上の アプリケーションが存在していれば、 これをローカルメモリ 2 9から削除すると いう処理をアプリケーションマネージャ 3 6は行う必要があるので、 各アプリケ ーシヨンのグループ属性を設け、 ローカルメモリ 2 9上で存在するアプリケ一シ ヨンがランチャー + 1個のアプリケーションになっているかどうかのチェックを 行うのである。
図 5 9 ( a ) は、 アプリケーション管理テ一ブルに基づくローカルメモリ 2 9 に対するアクセスを示す図である。 本図において、読込優先度 = Optionalと設定 された application#2、 appUcation#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 の物理的性質に依存するものではない。 動的シナリ 4 015330 ォ、 Index Tableを記録しうる記録媒体なら、 どのような記録媒体であってもよ い。 例えば、
DVD-ROM，DVD-RAM,DVD-RW，DVD-R，DVD÷RW，DVD+R，CD-R, CD-RW等の 光ディスク、 PD，MO 等の光磁気ディスクであってもよい。 また、 コンパクトフ ラッシュカード、スマートメディア、メモリスティ ック、マルチメディアカード、 PCM-CIA カード等の半導体メモリカードであってもよい。 フレシキプルディス ク、 SuperDisk，Zip,Clik!等の磁気記録デイスク (i)、 ORB,Jaz,SparQ,SyJet,EZFley, マイクロドライブ等のリム一パルハ一ドディスクドライプ (ii)であつてもよい。更 に、 機器内蔵型のハードディスクであってもよい。
(B) 全ての実施形態における再生装置は、 BD-ROMに記録された AVClipをデ コードした上で TVに出力していたが、再生装置を BD-ROMドライブのみとし、 これ以外の構成要素を TVに具備させてもい、 この場合、 再生装置と、 Vとを IEEE1394 で接続されたホームネットワークに組み入れることができる。 また、 実施形態における再生装置は、 テレビと接続して利用されるタイプであつたが、 ディスプレイと一体型となった再生装置であってもよい。 更に、 各実施形態の再 生装置において、 処理の本質的部分をなす部分のみを、 再生装置としてもよい。 これらの再生装置は、 何れも本願明細書に記載された発明であるから、 これらの 何れの態様であろうとも、 各実施形態に示した再生装置の内部構成を元に、 再生 装置を製造する行為は、 本願の明細書に記載された発明の実施行為になる。 各実 施形態に示した再生装置の有償'無償による譲渡 (有償の場合は販売、 無償の場合 は贈与になる)、 貸与、 輸入する行為も、 本発明の実施行為である。 店頭展示、 力 タログ勧誘、 パンフレット配布により、 これらの譲渡や貸渡を、 一般ユーザに申 し出る行為も本再生装置の実施行為である。
(C)各フローチャートに示したプログラムによる情報処理は、ハードウヱァ資源 を用いて具体的に実現されていることから、 上記フローチャートに処理手順を示 したプログラムは、 単体で発明として成立する。 全ての実施形態は、 再生装置に 組み込まれた態様で、 本発明に係るプログラムの実施行為についての実施形態を 示したが、 再生装置から分離して、 各実施形態に示したプログラム単体を実施し てもよい。 プログラム単体の実施行為には、 これらのプログラムを生産する行為 T JP2004/015330
(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— ime一 Stamp』 と、 u copy_permissioii— 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_Desci'iptorを出力する。 DTCP_Descriptor 15330
は、 TP— extra— 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)各実施形態における映像作品は、アナ口グ放送で放送されたアナ口グ映像信 号をエンコードすることにより得られたものでもよい。 デジタル放送で放送され たトランスポートストリームから構成されるストリームデータであってもよい。 またビデオテ一プに記録されているアナ口グ Zデジ夕ルの映像信号をェンコ一 ドしてコンテンツを得ても良い。 更にビデオカメラから直接取り込んだアナ口グ zデジタルの映像信号をエンコードしてコンテンツを得ても良い。 他にも、 配信 サーバにより配信されるデジタル著作物でもよい。
(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モー ド上で実行させても何等問題は生じないからである。 また再生装置や映画作品の 15330 開発にあたって、 動作保証が 1つのモ一ドで済むからである。
更に BD-Jモードだけで再生処理を実行してもよい。 第 5実施形態に示したよ うに、 BD-Jモードでも PLの再生と同期した再生制御が可能になるから、強いて MOVIEモードを設けなくてもよいという理由による。
(DAVClip に多重化されるべきインタラクティブグラフィクスストリームにナ ピゲ一シヨンコマンドを設けて、 ある PLから別の PLへの分岐を実現しても良 い。
産業上の利用可能性
本発明に係る再生装置は、 ホームシアターシステムでの利用のように、 個人的な 用途で利用されることがありうる。 しかし本発明は上記実施形態に内部構成が開 示されており、 この内部構成に基づき量産することが明らかなので、 資質におい て工業上利用することができる。 このことから本発明に係る再生装置は、 g業上 の利用可能性を有する。

Claims

請求の範囲
1 . 分岐可能な複数のタイ トルと、 アプリケーションとが記録された記録媒体 であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述され'たプログラムであり、 仮想マシ ンによる実行が可能となる生存区間が、 予め規定されており、
前記各タイ トルは、 管理テーブルを含み、
管理テーブルは、
タイ トルを生存区間とするアプリケーションを、 各タイトル毎に示す ことを特徴とする記録媒体。
2. 前記記録媒体には、 アプリケーションを構成するデータ及びプログラムを 格納したアーカイブファイルが記録されており、
前記各タイトルを生存区間とするアプリケーションは、
前記そのアプリケーションを格納したアーカイブファイルの識別子と、 タイト ルを一意に示すタイ トル番号との組みにより表現される
ことを特徴とする請求項 1記載の記録媒体。
3. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行と を同時に行う再生装置であって、
複数タイ トル間の分岐を制御するモジュールマネージャと、
1つのタイトルに帰属するデジタルストリームを再生する再生制御エンジン部 と、
タイ トルの分岐が発生する度に、 分岐先タイ トルを生存区間としたアプリケー シヨンの起動制御、 及び、 分岐先タイトルを生存区間としていないアプリケーシ ョンの終了制御を行うアプリケーションマネージャとを備える
ことを特徴とする再生装置。
4. タイトルは、 アプリケーション管理テーブルを含み、 アプリケーション管理テーブルは、 対応するタイトルを生存区間にしている 1 つ以上のアプリケーションを示し、
前記アプリケーションマネージャによる起動制御には、
タイ トルの分岐があった場合、 分岐先タイ トルを生存区間にしているアプリケ —シヨンが存在するかをアプリケーション管理テーブルを参照して判定し、 生存 区間としたアプリケーションが存在する場合のみ、 当該アプリケーションを起動 する制御がある
ことを特徴とする請求項 3記載の再生装置。
5. 前記アプリケーションマネージャによる起動制御には、
1つのタイトルにおいて起動しているアプリケーションからアプリケーション 呼出があった場合、 呼出先アプリケーションが、 当該タイトルを生存区間にして いるか否かをテーブルを参照して判定し、 生存区間にしている場合のみ、 呼出先 アプリケーシヨンを起動する制御がある
ことを特徴とする請求項 4記載の再生装置。
6. タイ トルは、 テーブルを含み、
テーブルは、 対応するタイ トルを生存区間にしている 1つ以上のアプリケーシ ョンを示し、
前記アプリケーションマネージャによる終了制御には、
タイ トルの分岐があった場合、 起動中アプリケーションのうち、 分岐先タイ ト ルを生存区間にしていないものが存在するかをテーブルを参照して判定し、 当該 アプリケーションが存在する場合のみ、 当該アプリケーションを終了するよう制 御ことである
ことを特徴とする請求項 1記載の再生装置。
7. 前記分岐は、 タイ トルへのジャンプを再生装置に命じるアプリケーション インタ一フヱイスにより実現され、
前記アプリケーションは、 前記アプリケーションィンターフヱイスをコールす る手順を含み、 モジュールマネージャは、 仮想マシンによる前記手順の解読に応じて分岐を実 行する、 ことを特徴とする請求項 3記載の再生装置。
8. 前記再生制御ェンジンによるデジタルストリームの再生には、 トリック再 生と、 通常再生とがあり、
前記アプリケーションマネージャは、
分岐先タイトルにおいてデジタルストリームの通常再生が開始した時点に、 ァ プリケーションの起動処理を開始する
ことを特徴とする請求項 3記載の再生装置。
9. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行と を同時に、 コンピュータに実行させるプログラムであって、
タイ トルの分岐が発生する度に、 分岐先タイ トルを生存区間としたアプリケー シヨンの起動制御、 及び、 分岐先タイ トルを生存区間としていないアプリケ一シ ョンの終了制御をコンピュータに行わせる
ことを特徴とするプログラム。
1 0. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行 とを同時に、 コンピュータに実行させる再生方法であって、
タイ トルの分岐が発生する度に、 分岐先タイ トルを生存区間としたアプリケー シヨンの起動制御、 及び、 分岐先タイ トルを生存区間としていないアプリケ一シ ョンの終了制御をコンピュータに行わせる
ことを特徴とする再生方法。
PCT/JP2004/015330 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法 Ceased WO2005036554A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US10/572,980 US7715696B2 (en) 2003-10-10 2004-10-12 Recording medium, playback apparatus, program, and playback method
CN200480029746XA CN1867999B (zh) 2003-10-10 2004-10-12 记录方法、再现装置、再现方法
EP04773781A EP1672637A4 (en) 2003-10-10 2004-10-12 RECORDING MEDIA, PLAYING DEVICE, PROGRAM AND METHOD
JP2005514677A JP4117006B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、記録方法、再生方法
KR1020067007243A KR101076198B1 (ko) 2003-10-10 2004-10-12 기록매체, 재생장치, 기록방법, 재생방법
KR1020097016043A KR101059290B1 (ko) 2003-10-10 2004-10-12 기록매체, 재생장치, 기록방법, 재생방법
US12/757,136 US8509596B2 (en) 2003-10-10 2010-04-09 Recording medium, playback apparatus, program, and playback method

Applications Claiming Priority (4)

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

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10/572,980 A-371-Of-International US7715696B2 (en) 2003-10-10 2004-10-12 Recording medium, playback apparatus, program, and playback method
US12/757,136 Continuation US8509596B2 (en) 2003-10-10 2010-04-09 Recording medium, playback apparatus, program, and playback method

Publications (1)

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

Family

ID=34436929

Family Applications (5)

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

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/015339 Ceased WO2005036555A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法

Family Applications After (3)

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

Country Status (7)

Country Link
US (10) US7515812B2 (ja)
EP (9) EP2267711A3 (ja)
JP (6) JP4262250B2 (ja)
KR (7) KR100937792B1 (ja)
CN (2) CN101702320B (ja)
TW (1) TW200518070A (ja)
WO (5) WO2005036555A1 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006033067A (ja) * 2004-07-12 2006-02-02 Sony Corp 再生装置および方法、情報提供装置および方法、データ、記録媒体、並びにプログラム
WO2006082892A1 (ja) * 2005-02-04 2006-08-10 Matsushita Electric Industrial Co., Ltd. 読出装置、プログラム、読出方法
JP2009508277A (ja) * 2005-08-29 2009-02-26 ソニー株式会社 ディスクオーサリングにおけるインタラクティブグラフィックデータのためのエフェクト
US7515812B2 (en) 2003-10-10 2009-04-07 Panasonic Corporation Recording medium, reproduction device, program, and reproduction method
JP2010166335A (ja) * 2009-01-15 2010-07-29 Nippon Hoso Kyokai <Nhk> 放送型アプリケーションの起動システム
EP2270802A3 (en) * 2004-07-22 2011-01-19 Panasonic Corporation Playback apparatus for performing application-synchronized playback
EP1899970A4 (en) * 2005-07-01 2011-12-21 Microsoft Corp SYNCHRONIZATION ASPECTS OF INTERACTIVE MULTIMEDIA PRESENTATION MANAGEMENT
EP1899852A4 (en) * 2005-07-01 2012-01-04 Microsoft Corp SYNCHRONIZATION OF INTERACTIVE MULTIMEDIA PRESENTATION MANAGEMENT
JP2013009329A (ja) * 2011-05-20 2013-01-10 Nippon Hoso Kyokai <Nhk> 受信機
WO2014057833A1 (ja) * 2012-10-10 2014-04-17 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム

Families Citing this family (78)

* 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
DE602004012598D1 (de) 2003-11-10 2008-04-30 Matsushita Electric Industrial Co Ltd Aufzeichnungsmedium, wiedergabeeinrichtung, programm, wiedergabeverfahren und systemintegrierte schaltung
KR20050066265A (ko) 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
KR20050066264A (ko) 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
EP2180477A1 (en) 2004-07-22 2010-04-28 Panasonic Corporation Playback apparatus and playback method
KR100694123B1 (ko) * 2004-07-30 2007-03-12 삼성전자주식회사 동영상 데이터와 어플리케이션 프로그램이 기록된 저장매체 및 그 재생 장치 및 방법
KR100677132B1 (ko) * 2004-09-09 2007-02-02 삼성전자주식회사 동영상 재생 및 프로그래밍 기능을 위한 멀티미디어데이터를 기록한 저장 매체, 그 재생 장치 및 재생 방법
WO2006051037A1 (en) 2004-11-09 2006-05-18 Thomson Licensing Bonding contents on separate storage media
KR20060059572A (ko) * 2004-11-29 2006-06-02 삼성전자주식회사 플레이리스트를 자동 재생하기 위한 정보를 포함하는 저장매체, 그 재생 장치 및 재생 방법
KR101251943B1 (ko) * 2004-12-06 2013-04-08 코닌클리케 필립스 일렉트로닉스 엔.브이. 다수의 저장매체에 대한 상호작용성 확대방법 및 장치
KR20060081337A (ko) * 2005-01-07 2006-07-12 엘지전자 주식회사 비밀키를 이용한 암호화 및 복호화 방법
KR101049133B1 (ko) * 2005-01-21 2011-07-15 엘지전자 주식회사 기록매체, 기록매체의 재생방법과 재생장치
US8280233B2 (en) 2005-01-28 2012-10-02 Panasonic Corporation Reproduction device, program, reproduction method
EP1696321A1 (en) 2005-02-23 2006-08-30 Deutsche Thomson-Brandt Gmbh Method and apparatus for executing software applications
WO2006088145A1 (ja) * 2005-02-18 2006-08-24 Matsushita Electric Industrial Co., Ltd. ストリーム再生装置、ストリーム供給装置
JP5279276B2 (ja) * 2005-02-28 2013-09-04 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ データ再生のためのフォールバックメカニズム
EP1859624A2 (en) * 2005-03-03 2007-11-28 Koninklijke Philips Electronics N.V. Streamed file system for optical disc applications
US8219635B2 (en) * 2005-03-09 2012-07-10 Vudu, Inc. Continuous data feeding in a distributed environment
US7937379B2 (en) * 2005-03-09 2011-05-03 Vudu, Inc. Fragmentation of a file for instant access
US20090025046A1 (en) * 2005-03-09 2009-01-22 Wond, Llc Hybrid architecture for media services
US8904463B2 (en) * 2005-03-09 2014-12-02 Vudu, Inc. Live video broadcasting on distributed networks
US9176955B2 (en) * 2005-03-09 2015-11-03 Vvond, Inc. Method and apparatus for sharing media files among network nodes
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
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
US7698451B2 (en) * 2005-03-09 2010-04-13 Vudu, Inc. Method and apparatus for instant playback of a movie title
US8099511B1 (en) 2005-06-11 2012-01-17 Vudu, Inc. Instantaneous media-on-demand
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
WO2009078157A1 (ja) * 2007-12-17 2009-06-25 Panasonic Corporation 個別販売に用いられる記録媒体、記録装置、再生装置、それらの方法
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
CN102119420B (zh) 2008-04-16 2014-04-23 松下电器产业株式会社 记录介质、记录装置、记录方法及再现装置
KR101486772B1 (ko) * 2008-06-04 2015-02-04 삼성전자주식회사 재생 위치에 따라 디지털 컨텐츠를 관리하는 방법과 장치및 실행하는 방법 및 장치
JP2010009408A (ja) * 2008-06-27 2010-01-14 Sony Corp 情報処理装置、およびデータ処理方法、並びにプログラム
US8649653B2 (en) * 2008-07-16 2014-02-11 Panasonic Corporation Reproduction device, reproduction method, and program
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
US8671077B2 (en) * 2008-11-06 2014-03-11 Deluxe Digital Studios, Inc. Methods, systems and apparatuses for use in updating a portable storage medium
WO2010052857A1 (ja) * 2008-11-06 2010-05-14 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
KR101227289B1 (ko) * 2008-12-04 2013-01-29 미쓰비시덴키 가부시키가이샤 영상 정보 재생 방법, 영상 정보 재생 장치, 기록 매체 및 영상 컨텐츠
KR101862351B1 (ko) * 2009-01-21 2018-05-29 삼성전자주식회사 콘텐트 정보 제공 및 재생 방법 및 장치
KR20100111996A (ko) * 2009-04-08 2010-10-18 삼성전자주식회사 가상 이미지 파일 처리 방법 및 장치
EP2254116A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254119B1 (en) 2009-05-20 2019-03-13 Sony DADC Austria AG Method for copy protection
EP2254121A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254118A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
WO2010133353A2 (en) 2009-05-20 2010-11-25 Sony Dadc Austria Ag Method for copy protection
EP2254120A1 (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
US9263085B2 (en) 2009-05-20 2016-02-16 Sony Dadc Austria Ag Method for copy protection
JP5215255B2 (ja) * 2009-07-10 2013-06-19 シャープ株式会社 プログラム実行装置、プログラム実行方法、コンテンツ再生装置、プログラムおよび記録媒体
WO2011007417A1 (ja) * 2009-07-14 2011-01-20 パイオニア株式会社 再生装置及び方法、並びにコンピュータプログラム
US8401370B2 (en) * 2010-03-09 2013-03-19 Dolby Laboratories Licensing Corporation Application tracks in audio/video containers
JP2011216165A (ja) 2010-04-01 2011-10-27 Alpine Electronics Inc ビデオ再生装置、コンピュータプログラム及びレジューム再生方法
US8909029B2 (en) * 2010-10-13 2014-12-09 Sony Corporation Capturing playback key events in BD players
US8648959B2 (en) 2010-11-11 2014-02-11 DigitalOptics Corporation Europe Limited Rapid auto-focus using classifier chains, MEMS and/or multiple object focusing
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 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
WO2013157447A1 (ja) * 2012-04-19 2013-10-24 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及びプログラム
KR20140018743A (ko) * 2012-08-03 2014-02-13 삼성전자주식회사 디스크리스 어플리케이션 재생 장치 및 기록 장치, 재생 방법 및 기록 방법과 디스크리스 어플리케이션을 기록한 정보저장매체
CN102917246B (zh) * 2012-08-31 2015-01-14 北京视博云科技有限公司 一种基于虚拟机的应用数据提供方法、装置及系统
KR20140039504A (ko) * 2012-09-24 2014-04-02 삼성전자주식회사 블루레이 디스크 재생 장치 및 블루레이 디스크 로딩 방법
JP5901843B2 (ja) 2013-03-28 2016-04-13 三菱電機株式会社 再生装置、制御方法及びプログラム
CN104679578B (zh) * 2015-03-12 2018-09-07 绚视软件科技(上海)有限公司 BD-java平台上的最小内存自适应机制及使用方法
CN104951340B (zh) * 2015-06-12 2018-07-06 联想(北京)有限公司 一种信息处理方法及装置
WO2017056194A1 (ja) * 2015-09-29 2017-04-06 株式会社 東芝 情報機器または情報通信端末および、情報処理方法
KR102401772B1 (ko) * 2015-10-02 2022-05-25 삼성전자주식회사 전자 장치에서 어플리케이션 실행 장치 및 방법
US10204059B2 (en) * 2016-09-29 2019-02-12 International Business Machines Corporation Memory optimization by phase-dependent data residency
CN106980579B (zh) 2016-09-30 2020-08-14 阿里巴巴集团控股有限公司 一种图片加载方法及装置
US10506268B2 (en) * 2016-10-14 2019-12-10 Spotify Ab Identifying media content for simultaneous playback
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 自動プログラム開始装置
JP2001238161A (ja) * 2000-02-25 2001-08-31 Sony Corp 情報付加装置、情報付加方法および記録媒体
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
JP2002369154A (ja) * 2001-04-02 2002-12-20 Matsushita Electric Ind Co Ltd ディジタル映像コンテンツの映像再生装置、映像再生方法、映像再生プログラム、パッケージメディア
JP2003248637A (ja) * 2002-02-22 2003-09-05 Canon Inc 画像処理装置、画像処理装置の制御方法、プログラム、及びコンピュータ読み取り可能な記憶媒体
JP2003249057A (ja) * 2002-02-26 2003-09-05 Toshiba Corp デジタル情報媒体を用いるエンハンスド・ナビゲーション・システム
JP2004206863A (ja) * 2002-12-09 2004-07-22 Toshiba Corp 情報再生装置及び情報再生方法

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0491078A (ja) 1990-08-06 1992-03-24 Kao Corp イミダゾール誘導体
JPH0491104A (ja) 1990-08-06 1992-03-24 Ootex Kk 光重合反応開始剤
JPH0759608B2 (ja) 1990-08-06 1995-06-28 株式会社クラレ イミド化アクリル樹脂粒子体の処理方法
JP2609749B2 (ja) 1990-08-31 1997-05-14 日本電気アイシーマイコンシステム株式会社 電流供給回路
JP2798490B2 (ja) 1990-09-03 1998-09-17 日本電気アイシーマイコンシステム株式会社 発振回路
MX9702848A (es) 1995-08-21 1997-07-31 Matsushita Electric Industrial 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.
US5915067A (en) * 1995-08-21 1999-06-22 Matsushita Electric Industiral Co., Ltd. Multimedia optical disc facilitating branch reproduction to parental lock sections using reduced control information and a reproducing device for said disc
CN1103486C (zh) 1995-08-21 2003-03-19 松下电器产业株式会社 能永久保持图象内容新鲜感的光盘的再生装置及再生方法
EP0915470A3 (en) * 1995-08-21 2004-03-24 Matsushita Electric Industrial Co., Ltd. Multimedia optical disk, reproduction apparatus and method for achieving variable scene development based on interactive control
EP0777230A1 (de) * 1995-12-04 1997-06-04 Markus Zwickl CDs enthaltend zusätzliche Textinformation
CN1108612C (zh) 1996-04-12 2003-05-14 松下电器产业株式会社 多媒体光盘的再生装置和再生方法
WO1997042758A1 (en) 1996-05-09 1997-11-13 Matsushita Electric Industrial Co., Ltd. Multimedia optical disk, reproducing device, and reproducing method capable of superposing sub-video upon main video in well-balanced state irrespective of position of main video on screen
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 パイオニア株式会社 コンピュータ読み取り可能な記録媒体及び情報再生装置
JPH11219313A (ja) 1998-02-02 1999-08-10 Mitsubishi Electric Corp コンテンツ先読み方法
WO1999050771A1 (en) 1998-03-31 1999-10-07 International Business Machines Corporation A method and apparatus for creating an electronic commerce system
JPH11296381A (ja) 1998-04-08 1999-10-29 Matsushita Electric Ind Co Ltd 仮想マシン及びコンパイラ
JP3262539B2 (ja) 1998-06-15 2002-03-04 株式会社ディジタル・ビジョン・ラボラトリーズ データ放送方式及び同方式に適用されるデータ受信装置
EP0989743A1 (en) 1998-09-25 2000-03-29 CANAL+ Société Anonyme Application data table for a multiservice digital transmission system
JP2000149514A (ja) 1998-11-10 2000-05-30 Alpine Electronics Inc ディスク再生装置
US7634787B1 (en) * 1999-06-15 2009-12-15 Wink Communications, Inc. Automatic control of broadcast and execution of interactive applications to maintain synchronous operation with broadcast programs
JP2001022625A (ja) 1999-07-09 2001-01-26 Sony Corp データ記録装置、データ記録方法、データ取得装置、データ取得方法
US6874145B1 (en) 1999-07-13 2005-03-29 Sun Microsystems, Inc. Methods and apparatus for implementing an application lifecycle design for applications
CN1227588C (zh) 1999-07-13 2005-11-16 太阳微系统有限公司 用于根据应用生存周期管理该应用的方法和设备
JP3756708B2 (ja) * 1999-09-30 2006-03-15 株式会社東芝 情報処理端末装置およびそのファイル管理方法
BR0015152A (pt) 1999-10-29 2002-07-16 Opentv Corp Sistema e método para gravar dados empurrados
EP1234446B1 (en) 1999-10-29 2003-06-18 OpenTV, Corp. Playback of interactive programs
JP2003514335A (ja) 1999-11-10 2003-04-15 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 記録担体、記録担体を再生する装置、記録担体を再生する方法、記録担体を記録する装置及び記録担体を記録する方法
US7200857B1 (en) 2000-06-09 2007-04-03 Scientific-Atlanta, Inc. Synchronized video-on-demand supplemental commentary
KR100821019B1 (ko) 2000-04-21 2008-04-08 소니 가부시끼 가이샤 부호화 장치, 부호화 방법, 및 기록 매체
GB0016062D0 (en) * 2000-06-30 2000-08-23 Koninkl Philips Electronics Nv Playback of applications with non-linear time
GB2370658A (en) 2000-12-29 2002-07-03 Metadyne Ltd A modular software framework
JP2002238161A (ja) 2001-02-14 2002-08-23 Yanmar Diesel Engine Co Ltd 分散電源用発電機の出力方法
JP2002269929A (ja) 2001-03-08 2002-09-20 Hitachi Ltd ディスク装置
EP1381232A4 (en) * 2001-04-02 2005-09-28 Matsushita Electric Industrial Co Ltd VIDEO PLAYBACK DEVICE FOR DIGITAL VIDEO CONTENT, VIDEO PLAY PROCESS, VIDEO PLAY PROGRAM AND PACKAGING MEDIUM
KR100771264B1 (ko) 2001-05-12 2007-10-29 엘지전자 주식회사 스크립트 파일이 포함 기록된 기록매체와, 그 재생장치 및방법
JP2003032637A (ja) 2001-07-16 2003-01-31 Sharp Corp データ放送受信装置
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
TW200300928A (en) * 2001-11-30 2003-06-16 Sony Corportion Information processing method and apparatus, program storage medium, program and information recording medium
JP3921593B2 (ja) 2001-11-30 2007-05-30 ソニー株式会社 情報処理装置および方法、プログラム格納媒体、プログラム、並びに情報記録媒体
US6968445B2 (en) 2001-12-20 2005-11-22 Sandbridge Technologies, Inc. Multithreaded processor with efficient processing for convergence device applications
GB0130534D0 (en) 2001-12-20 2002-02-06 Aspex Technology Ltd Improvements relating to data transfer addressing
AU2003206150A1 (en) 2002-02-07 2003-09-02 Samsung Electronics Co., Ltd Information storage medium containing display mode information, and reproducing apparatus and method therefor
JP3990928B2 (ja) 2002-03-19 2007-10-17 キヤノン株式会社 テレビジョン放送受信装置、再生方法及びプログラム
US7814025B2 (en) * 2002-05-15 2010-10-12 Navio Systems, Inc. Methods and apparatus for title protocol, authentication, and sharing
DE10228103A1 (de) 2002-06-24 2004-01-15 Bayer Cropscience Ag Fungizide Wirkstoffkombinationen
RU2309467C2 (ru) * 2002-06-24 2007-10-27 Эл Джи Электроникс Инк. Носитель записи со структурой данных, включающей навигационно-управляющую информацию, для управления воспроизведением записанных на нем видеоданных и способы и устройства записи и воспроизведения
BR0313688A (pt) * 2002-08-26 2005-06-21 Samsung Electronics Co Ltd Mìdia de armazenamento de informações, método de processamento de uma entrada de usuário em um modo interativo em que dados de av são reproduzidos com um documento de marcação, aparelho para reprodução de dados de av em um modo interativo, dispositivo de reprodução, e método de processamento de uma entrada de usuário em um modo interativo
EP2246857A3 (en) * 2002-09-12 2010-12-01 Panasonic Corporation Recording medium, playback device, program, playback method, and recording method
KR20050086810A (ko) 2002-11-26 2005-08-30 마츠시타 덴끼 산교 가부시키가이샤 연결 가능한 리무버블 저장매체를 관리하기 위한 장치와리무버블 저장매체를 관리하기 위한 방법, 프로그램, 및시스템 ｌｓｉ
CN1754225B (zh) * 2003-02-21 2012-05-30 松下电器产业株式会社 再现设备、记录方法以及再现方法
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 삼성전자주식회사 프리로드 정보가 기록된 정보저장매체, 그 재생장치 및재생방법
JP4117019B2 (ja) 2003-10-10 2008-07-09 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4091104B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4091105B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
TW200518070A (en) 2003-10-10 2005-06-01 Matsushita Electric Industrial Co Ltd Recording medium, reproduction device, program, and reproduction method
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 有機エレクトロルミネッセンス素子の製造方法及び製造装置
JP2007265851A (ja) 2006-03-29 2007-10-11 Molex Inc ケーブル用コネクタ
JP2007265852A (ja) 2006-03-29 2007-10-11 Matsushita Electric Ind Co Ltd 複合集電体およびその製造方法

Patent Citations (8)

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

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8406604B2 (en) 2003-10-10 2013-03-26 Panasonic Corporation Playback apparatus, recording method, and playback method
US8437625B2 (en) 2003-10-10 2013-05-07 Panasonic Corporation 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
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
US8509596B2 (en) 2003-10-10 2013-08-13 Panasonic Corporation Recording medium, playback apparatus, program, and playback method
US8131130B2 (en) 2003-10-10 2012-03-06 Panasonic Corporation Recording medium, playback apparatus, recording method, and playback method
JP2006033067A (ja) * 2004-07-12 2006-02-02 Sony Corp 再生装置および方法、情報提供装置および方法、データ、記録媒体、並びにプログラム
US8660406B2 (en) 2004-07-22 2014-02-25 Panasonic Corporation Playback apparatus for performing application-synchronized playback
US8326120B2 (en) 2004-07-22 2012-12-04 Panasonic Corporation Playback apparatus for performing application-synchronized playback
US8391676B2 (en) 2004-07-22 2013-03-05 Panasonic Corporation Playback apparatus for performing application-synchronized playback
EP2270802A3 (en) * 2004-07-22 2011-01-19 Panasonic Corporation Playback apparatus for performing application-synchronized playback
WO2006082892A1 (ja) * 2005-02-04 2006-08-10 Matsushita Electric Industrial Co., Ltd. 読出装置、プログラム、読出方法
US8032007B2 (en) 2005-02-04 2011-10-04 Panasonic Corporation Reading device, program, and reading method
US8687943B2 (en) 2005-02-04 2014-04-01 Panasonic Corporation Readout apparatus, readout method, and recording method
EP1899852A4 (en) * 2005-07-01 2012-01-04 Microsoft Corp SYNCHRONIZATION OF INTERACTIVE MULTIMEDIA PRESENTATION MANAGEMENT
EP1899970A4 (en) * 2005-07-01 2011-12-21 Microsoft Corp SYNCHRONIZATION ASPECTS OF INTERACTIVE MULTIMEDIA PRESENTATION MANAGEMENT
JP2009508277A (ja) * 2005-08-29 2009-02-26 ソニー株式会社 ディスクオーサリングにおけるインタラクティブグラフィックデータのためのエフェクト
JP2010166335A (ja) * 2009-01-15 2010-07-29 Nippon Hoso Kyokai <Nhk> 放送型アプリケーションの起動システム
JP2013009329A (ja) * 2011-05-20 2013-01-10 Nippon Hoso Kyokai <Nhk> 受信機
WO2014057833A1 (ja) * 2012-10-10 2014-04-17 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム
JPWO2014057833A1 (ja) * 2012-10-10 2016-09-05 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム

Also Published As

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

Similar Documents

Publication Publication Date Title
JP4182110B2 (ja) 再生装置、プログラム、再生方法。
CN101393761B (zh) 再现装置、记录方法、以及再现方法
JP4012563B2 (ja) 記録媒体、再生装置、プログラム、再生方法。
JP4117019B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4091105B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4091104B2 (ja) 記録媒体、再生装置、記録方法、再生方法

Legal Events

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

Ref document number: 200480029746.X

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

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

Ref document number: 2005514677

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020067007243

Country of ref document: KR

REEP Request for entry into the european phase

Ref document number: 2004773781

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2004773781

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004773781

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10572980

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1020067007243

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 10572980

Country of ref document: US