AU2012202934B2 - An Integrated Circuit and a Method for Decoding a Digital Stream - Google Patents

Abstract

Abstract A playback apparatus for playing back a stream sequence, comprising: a playback unit; a package management unit 5 operable to, when digital streams which constitute the stream sequence are recorded on separate recording media, set each digital stream to an enable status of being recognizable by playback unit or a disable status of being unrecognizable by the playback unit; an application 10 execution unit operable to execute an application to control access to any of the recording media; and an API operable to, in response to a call from the application executed by the application execution unit, return information to the application, the information relating 15 to a digital stream among the digital streams that is in the disable status; wherein the playback unit starts playing back the stream sequence if at least one of the digital streams is in the enable status; the package management unit changes, while one digital stream is being 20 played back by the playback unit, a remaining digital stream to the enable status or the disable status according to a request from the application execution unit; and the application acquires the information by receiving a response corresponding to the call. 33386761 (GHMatters) P62611.AU2 18/05/12

Description

AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION Standard Patent Applicant: Panasonic Corporation Invention Title: AN INTEGRATED CIRCUIT AND A METHOD FOR DECODING A DIGITAL STREAM The following statement is a full description of this invention, including the best method for performing it known to me/us: -2 AN INTEGRATED CIRCUIT AND A METHOD FOR DECODING A DIGITAL STREAM Related Applications 5 This application is a divisional application of Australian application no. 2010249289 filed 10 December 2010, itself a divisional application of Australian application no. 2005241787 filed 10 May 2005, the disclosures of both of which are incorporated herein by 10 reference. Most of the disclosures of applications nos. 2005241787 and 2010249289 are also included herein, but reference may be made to the specification of those applications as filed or accepted to gain further understanding of the invention claimed herein. 15 Technical Field The present invention relates to an integrated circuit and a method for decoding a digital stream. 20 Background Art A Virtual Package is a technique of constructing a virtual package by dynamically combining a digital stream recorded on a read-only recording medium such as a BD-ROM 15 and a digital stream recorded on a rewritable recording 25 medium such as a hard disk, in order to develop the contents of the read-only recording medium. Suppose the 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 3 digital stream recorded on the BD-ROM constitutes a movie work and the digital stream recorded on the hard disk constitutes a sequel to the 20 movie work. This being the case, by constructing the above Virtual Package, the movie 5 work recorded on the BD-ROM and the sequel recorded on the hard disk can be treated as one long feature film and submitted for playback. For example, Japanese Patent Application Publication No. 2002-369154 describes a conventional technique about 10 Virtual Packages. Summary of the Invention According to a first broad aspect of the present invention, there is provided a playback method, 15 comprising: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a first writable recording medium as a recording destination 20 but not yet having been recorded into the first writable recording medium; accessing and playing back a second digital stream among the plurality of digital streams that has already been recorded in a second recording medium; 25 executing an application; downloading the first digital stream to the first writable recording medium during the playing back of the second digital stream; 44649331 (GHMatters) P62611.AU.2 2/07/13 -4 setting, in response to a call from the application being executed, the downloaded first digital stream to a second status in which playback access is enabled, and setting the downloaded first digital stream to a read-only 5 attribute; and accessing and playing back the downloaded first digital stream set to the read only attribute and to the second status, in which playback access is enabled. In one embodiment, after playback of the first 10 digital stream set to the read only attribute and to the second status, in which playback access is enabled, is completed, in response to a call from the application being executed, the setting cancels the read-only attribute of the first digital stream, and the playback is method further comprises deleting the first digital stream set to the first status. In another embodiment, the method further comprises notifying, after the playback of the first digital stream set to the second status, in which playback access is 20 enabled, and the read-only attribute is completed, the application of completion of the playback. In still another embodiment, the method further comprises returning, in response to a call from the application being executed, information to the 25 application, the information relating to the first digital stream set to the first status. According to a second broad aspect of the present invention, there is provided a playback apparatus, comprising: 30 a manager that sets, among a plurality of digital streams, a first digital stream to a first status in which 44649331 (GHMatters) P62611.AU.2 2/07/13 playback access is disabled, the first digital stream having a first writable recording medium as a recording destination but not yet having been recorded into the first writable recording medium; 5 a player that accesses and plays back a second digital stream among the plurality of digital streams, that has already been recorded in a second recording medium; an application executer that executes an application; 10 and a downloader that downloads the first digital stream to the first writable recording medium during the playing back of the second digital stream; wherein the manager sets, in response to a call from 15 the application being executed, the downloaded first digital stream to a second status in which playback access is enabled, and sets the first downloaded digital stream to a read-only attribute, and the player accesses and plays back the first 20 downloaded digital stream set to the read only attribute and to the second status, in which playback access is enabled. According to a third broad aspect of the present invention, there is provided a program for use in a 25 computer for executing a playback method, the program causing the computer to perform: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a 30 first writable recording medium as a recording destination but not yet having been recorded into the first writable 4464933_1 (GHMatters) P62611 AU2 2/07113 recording medium; accessing and playing back a second digital stream, among the plurality of digital streams, that has already been recorded in a second recording medium; s executing an application; downloading the first digital stream to the first writable recording medium during the playing back of the second digital stream; setting, in response to a call from the application io being executed, the downloaded first digital stream to a second status in which playback access is enabled, and setting the first digital stream to a read-only attribute; and accessing and playing back the first digital stream 15 set to the read only attribute and to the second status, in which playback access is enabled. The invention also provides a computer readable recording medium, comprising this program. According to a fourth broad aspect of the present 20 invention, there is provided a playback method, comprising: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a 25 first writable recording medium as a recording destination but not yet having been recorded into the first writable recording medium; setting, among the plurality of digital streams, a second digital stream to a second status in which playback 30 access is enabled, the second digital stream having the first writable recording medium as a recording destination 4464933_1 (GHMatters) P62611.AU.2 2/07/13 and having already been recorded into the first writable recording medium, and setting the second digital stream to a read-only attribute; accessing and playing back the second digital stream; s executing an application; downloading the first digital stream to the first writable recording medium during playback of the second digital stream; setting, in response to a call from the application 10 being executed, the downloaded first digital stream to the second status, and setting the downloaded first digital stream to a read-only attribute; and accessing and playing back the downloaded first digital stream set to the read only attribute and to the 15 second status, in which playback access is enabled. In one embodiment, a digital stream, which has already been recorded in a second recording medium, is further accessed and played back in the accessing and the playing back. 20 According to a fifth broad aspect of the present invention, there is provided a playback apparatus, comprising: a manager that sets, among a plurality of digital streams, a first digital stream and a second digital 25 stream to a first status in which playback access is disabled and a second status in which playback access is enabled, respectively, the first digital stream having a first writable recording medium as a recording destination but not yet having been recorded into the first writable 30 recording medium, the second digital stream having a first writable recording medium as a recording destination and 4464933_1 (GHMatters) P62611 .AU.2 2/07/13 - 7A having already been recorded into the first writable recording medium, and set an attribute of the second digital stream to a read-only attribute; a player that accesses and plays back the second 5 digital stream; an application executer that executes an application; and a downloader that downloads the first digital stream to the first writable recording medium during playback of io the second digital stream; wherein the manager sets, in response to a call from the application being executed, the downloaded first digital stream to the second status, and sets the downloaded first digital stream to a read-only attribute; 15 and the player accesses and plays back the downloaded first digital stream set to the read only attribute and to the second status, in which playback access is enabled. The player may further access and play back a digital 20 stream that has already been recorded in a second recording medium. According to a sixth broad aspect of the present invention, there is provided a playback program for use in a computer for executing a playback method, the program 25 causing the computer to perform: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a first writable recording medium as a recording destination 30 but not yet having been recorded into the first writable recording medium; 44649331 (GHMatters) P62611.AU.2 2/07/13 - 7B setting, among the plurality of digital streams, a second digital stream to a second status in which playback access is enabled, the second digital stream having the first writable recording medium as a recording destination 5 and having already been recorded into the first writable recording medium, and setting the second digital stream to a read-only attribute; accessing and playing back the second digital stream; executing an application; 10 downloading the first digital stream to the first writable recording medium during playback of the second digital stream; setting, in response to a call from the application being executed, the downloaded first digital stream to the is second status, and setting the downloaded first digital stream to a read-only attribute; and accessing and playing back the downloaded first digital stream set to the read only attribute and to the second status, in which playback access is enabled. 20 In one embodiment, a digital stream, which has already been recorded in a second recording medium, is further accessed and played back in the accessing and the playing back. The invention also provides a computer readable 25 recording medium, comprising this playback program. Brief Description of the Drawings In order that the present invention be more clearly ascertained, embodiments will now be described, by way of 30 example, with reference to the accompanying drawings, in which: 4464933_1 (GHMatters) P62611.AU.2 2/07113 - 8 FIG. 1 shows an example of use of a playback apparatus according to an embodiment of the present invention. FIG. 2 shows an internal structure of a BD-ROM. 5 FIG. 3 schematically shows a structure of an AVClip. FIG. 4 shows a structure of PL information. FIG. 5 shows a relationship between an AVClip time axis and a PL time axis. FIG. 6 shows batch specification using four io ClipInformation file names. FIG. 7 shows an internal structure of PLmark information. FIG. 8 shows chapter definitions using PLmarks. FIG. 9 shows an internal structure of SubPath is information. FIG. 10 shows sync specification and playback section definitions on a SubPlayItem time axis. FIG. 11A shows programs and data housed in a Java (TM) archive file. 20 FIG. 11B shows an internal structure of a class file. FIG. 12 shows an internal structure of the playback apparatus according to the present invention. FIG. 13A shows a directory structure in a Local Storage 18. 25 FIG. 13B shows an internal structure of a stream storage location information file. FIG. 14 depicts elements composed of hardware and software stored on a ROM 24 rearranged in a layer 3338676_1 (GHMatters) P62611.AU.2 18/05/12 -9 structure. FIG. 15 shows an internal structure of a Java (TM) virtual machine 30. FIG. 16 shows an exemplary creation of Virtual s Package information by a Virtual FileSystem unit 38. FIG. 17 shows an example of status management by the Virtual FileSystem unit 38. FIG. 18 shows generation of Virtual Package information that reflects status management. 10 FIG. 19 shows creation of a Virtual Package by the Virtual FileSystem unit 38 when a network management module 37 is in a process of downloading. FIG. 20A shows what kinds of PlayList playback time axis are defined by PL information stored in the Local 15 Storage. FIG. 20B shows a concept of Progressive PlayList information. FIG. 21 shows generation of an instance by a management information conversion module 39. 20 FIG. 22 shows a call of a Play method in a PlayList object. FIG. 23 schematically shows a result of an inquiry by a getMissingStreams method. FIG. 24 schematically shows a call of an enableClip 25 method. FIG. 25 schematically shows a call of a disableClip method. FIG. 26 is a flowchart of processing when creating a Virtual Package. 33386761 (GHMatters) P62611 .AU.2 18/05/12 - 10 FIG. 27A is a flowchart of processing when calling an enableClip method. FIG. 27B is a flowchart of processing when calling a disableClip method. 5 FIG. 28 is a flowchart of a playback procedure by a Playback Control Engine 32. FIG. 29 is a flowchart of processing by an application. FIGS. 30A and 30B respectively show the progress of 10 download by the network management module 37 and the progress of playback by the Playback Control Engine 32. FIGS. 31A and 31B respectively show the progress of download by the network management module 37 and the progress of playback by the Playback Control Engine 32. 15 FIGS. 32A and 32B respectively show the progress of download by the network management module 37 and the progress of playback by the Playback Control Engine 32. FIGS. 33 shows the progress of download by the network management module 37 and the progress of playback 20 by the Playback Control Engine 32. Detailed Description of the Invention (First Embodiment) The following describes an embodiment of a recording 25 medium according to the present invention. Firstly, a form of use out of the forms of an act of working of a playback apparatus according to the present invention is described below. FIG. 1 shows an exemplary form of use of the playback apparatus according to the present invention. 33386761 (GHMatters) P62611.AU.2 18/05112 - 11 In FIG. 1, the playback apparatus according to the present invention is a playback apparatus 200. The playback apparatus 200 is submitted for use in supplying movie works in a home theatre system that includes a remote s control 300 and a television 400. An exemplary form of use of the playback apparatus according to the present invention is as described above. A recording medium targeted for playback by the playback apparatus according to the present invention is described 10 next. The recording medium played by the playback apparatus according to the present invention is a BD-ROM. FIG. 2 shows an internal structure of the BD-ROM. The BD-ROM is shown at the fourth tier in the drawing, while a track on the BD-ROM is shown at the third 15 tier. The track depicted here results from a track spiralling from an inner circumference to an outer circumference of the BD-ROM having been drawn out to the sides. This track is made up of a lead-in area, a volume area, and a lead-out area. The volume area in FIG. 2 has 20 a layered structure made up of a physical layer, a filesystem layer, and an application layer. Expressing a format of the application layer (application format) of the BD-ROM using a directory structure gives the first tier in FIG. 2. A BDMV directory is placed under a ROOT 25 directory in the BD-ROM, as shown at the first tier. Under the BDMV directory exist four subdirectories known as a PLAYLIST directory, a CLIPINF directory, a 33386761 (GHMatters) P62611.AU.2 18/05/12 - 12 STREAM directory, and a BDJA directory. The STREAM directory stores a file forming a main part of a digital stream, with an extension "M2TS" being assigned to this file (00001.M2TS). s The PLAYLIST directory stores a file (00001.MPLS) with an extension "MPLS". The CLIPINF directory stores a file (00001.CLPI) with an extension "CLPI". These files are described next. 10 <AVClip> The file with the extension "M2TS" is described firstly. FIG. 3 schematically shows how the file with the extension "M2TS" is structured. The file with the extension "M2TS" (00001.M2TS, 00002.M2TS, 00003.M2TS, .. 15 stores an AVClip. The AVClip (middle tier) is constituted by multiplexing TS packets resulting from the conversion of a video stream composed of a plurality of video frames (pictures pjl, pj2, pj3) and an audio stream composed of a plurality of audio frames (upper first tier) firstly to 20 PES packets (upper second tier) and then to TS packets (upper third tier) and the conversion of a subtitle Presentation Graphics stream (PG stream at the lower first tier) and an Interactive Graphics stream (IG stream at the lower first tier) to TS packets (lower third tier) in the 25 same manner. Apart from the AVClip obtained through multiplexing 33386761 (GHMatters) P62611 AU.2 18105/12 - 13 as shown in FIG. 3, there also exist AVClips that do not result from multiplexing. Such AVClips are called SubClips, and include AVClips constituting an audio stream, a graphics stream, a text subtitle stream 5 (TextSTStream), and the like. <Clip Information> The file with the extension "CLPI" (00001.CLPI) is a piece of Clip information corresponding to an AVClip. Clip 10 information, being management information, contains an EPmap showing a head location of a GOP and information such as an encoding format, a frame rate, a bit rate, and a resolution of streams in the AVClip. 15 <PlayList Information> The file with the extension "MPLS" (00001.MPLS) stores PlayList (PL) information. The PL information defines a playlist by referring to AVClips. FIG. 4 shows a structure of the PL information. As shown on the left side 20 of the drawing, the PL information includes MainPath information, PLMark information, and SubPath information. The MainPath information (MainPath() is composed of a plurality of pieces of PlayItem information (PlayItem(), as indicated by the arrows mpl. A PlayItem 25 is a playback section defined by specifying an InTime and an OutTime on one or more AVClip time axes. A playlist 33386761 (GHMetters) P62611.AU.2 18/05/12 - 14 (PL) composed of a plurality of playback sections is defined by placing a plurality of pieces of PlayItem information. The arrows mp2 in FIG. 4 show a close up of an internal structure of PlayItem information. As shown in 5 the drawing, the PlayItem information is composed of an Intime, an Outtime, and a Clip_informationfile name showing a corresponding AVClip. FIG. 5 shows a relationship between an AVClip and a PL. The first tier shows a time axis of the AVClip, while the second tier 10 shows a time axis of the PL. The PL information includes three pieces of PlayItem information PlayItems#l, #2, and #3, with three playback sections being defined by the In-times and Outtimes of PlayItems#l, #2, and #3. A different time axis from the AVClip is defined when these is playback sections are arranged in line. This is the PL time axis shown at the second tier. Defining a different time axis from the AVClip is thus enabled by the definitions in the PlayItem information. As a rule, one AVClip is specified at any one time, 20 though batch specification of a plurality of AVClips is also possible. Batch specification of AVClips is performed using a plurality of Clip_Informationfilenames in PlayItem information. FIG. 6 shows the batch specification of AVClips using four ClipInformationfilenames. The 25 first to fourth tiers in the drawing show four AVClip time axes (time axes of AVClips#1, #2, #3, and #4), while the 33386761 (GHMatters) P62611 AU-2 18/05112 - 15 fifth tier shows a PL time axis. The four time axes are specified with four ClipInformation filenames included in the PlayItem information. This allows four alternatively playable playback sections to be defined by s an Intime and Outtime of the PlayItem. As a result, a section composed of a plurality of pieces of switchable angle video (so-called multi-angle section) is defined on the PL time axis. The PLMark information (PLmarko) specifies an 1o arbitrary section on a PL time axis as a chapter. FIG. 7 shows an internal structure of the PLMark information, which includes a reftoPlayltemId and a Marktime_stamp, as indicated by the arrows pml. FIG. 8 shows the definition of chapters using PLmarks. The first tier in 15 the drawing shows the AVClip time axis, while the second tier shows the PL time axis. The arrows pk1 and pk2 in FIG. 8 show the specification of a PlayItem (reftoPlayItemId) and a point in time (marktime_stamp) in PLMarks. Three chapters (Chapters#1, #2, and #3) are 20 defined on the PL time axis as a result of these specifications. This completes the description of PLmarks. The SubPath information is described next. The SubPath information (SubPath () defines one or more playback sections by specifying an InTime and an 25 OutTime on a SubClip time axis, and has an internal structure shown in FIG. 9. As illustrated, the SubPath 33386761 (GHMatters) P62611.AU.2 18/05/12 - 16 information is composed of a plurality of pieces of SubPlayItem information (SubPlayItem() as indicated by the arrows shl. In a close up marked by the arrows sh2, SubPlayItem information is composed of a s Clipinformationfilename, an In_ time, an Outtime, a SyncPlayItemId, and a Sync startPtsofPlayItem. An InTime and an OutTime on the SubClip time axis are specified using the Clipinformationfilename, the Intime, and the Outtime included in the SubPlayItem 1o information. The SyncPlayItemId and the SyncstartPtsofPlayItem specify synchronization of a playback section on the SubClip time axis with the PL time axis. This allows processing on both the SubClip time axis and the PL time axis to proceed in sync with one another. 15 FIG. 10 shows the sync specification and the definition of a playback section on the SubClip time axis. The first tier in the drawing shows the PL time axis, while the second tier shows the SubClip time axis. A SubPlayItem.INtime and a SubPlayItem.Outtime in the 20 drawing respectively show the start and end of a playback section. Thus, it is apparent that a playback section is also defined on the SubClip time axis. A SyncPlayItemId marked by the arrow Snl shows the sync specification of a PlayItem, while a syncstartPTSof_Playltem marked by the 25 arrow Sn2 specifies a point during the PlayItem on the PL time axis. 3338676_1 (GHMatters) P62611 AU 2 18/05/12 - 17 A feature of PL information in BD-ROMS is that it makes possible the definition of multi-angle sections that enable AVClips to be switched and sync sections that enable AVClips and SubClips to be synchronized. Clip S information and PL information described above are classified as "static scenarios". The following describes "dynamic scenarios". Here, "dynamic" refers to the fact that the contents of playback controls changes due to user key events and status changes io in the playback apparatus 200. With BD-ROMs, playback controls can be described using a same description as Java (TM) applications. That is, with BD-ROMs, Java (TM) applications act as dynamic scenarios. 15 <Java (TM) Applications> The following describes Java (TM)applications. A Java (TM) application is composed of one or more xlet programs loaded in a heap area (also called a work memory) of a virtual machine. An application is constituted from the 20 xlet programs loaded in the work memory, as well as data. The structure of the Java (TM) application is as described above. An actual Java (TM) application is a Java (TM) archive file (00001.jar, 00002.jar) stored in the BDJA 25 directory under the BDMV directory shown in FIG. 2. Java (TM) archive files are described below with reference to 33386761 (GHMatters) P62611.AU.2 18/05/12 - 18 FIG. 11. <Java (TM) Archive File> The Java (TM) archive file (00001.JAR in FIG. 2) is a 5 collection of one or more class files and data files etc. FIG. 11A shows programs and data collected in the archive file. The data in FIG. 11A is a plurality of files collected by a java (TM) archiver and arranged into a directory structure shown within the frame. This directory 10 structure includes a Root directory, ajava (TM) directory, and an image directory, with a common.pkg file, class files (aaa.class, bbb.class), and a menu.jpg file being placed within the respective directories. The Java (TM) archive file is a result of the java (TM) archiver having 15 collected these files together. The class files and data are expanded when read from the BD-ROM to a cache, and treated in the cache as a plurality of files existing in directories. The five-digit numerical value "zzzzz" in the filename of the Java (TM) archive file shows an ID of the 20 application (application ID) . By referring to this numerical value in the filename when the Java (TM) archive file has been read to the cache, it is possible to extract data as well as programs constituting an arbitrary Java (TM) application. 25 The class files (aaa.class, bbb.class) in FIG. 11A correspond to the above xlet programs. Playback procedures 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 19 in an operating mode (BD-J) supported by a Java (TM) system requirement are defined using xlet programs which are instances of these class files. An xlet program is a Java (TM) program capable of using a JMF (Java (TM) Media 5 FrameWork) interface, and performs processing based on key events in accordance with JMF etc. The xlet program is capable of JMF processing, and so can instruct the playback apparatus 200 to play back a PlayList by generating a JMF instance (PlayList Object) corresponding 10 to an MPLS file. Also, the xlet program can execute processes that are unique to the BD-ROM playback apparatus 200 by writing calls for API functions. Furthermore, the xlet program can execute procedures for accessing websites and downloading content. This 15 enables playback of original works created by mixing downloaded content with playlists. The class file of the xlet program is described next. FIG. 11B shows an internal structure of the class file. As shown in FIG. 11B, this class file, similar to a normal 20 class file, is composed of a constant pool, an interface, and methods 1, 2, 3, ... , n. The methods in the class file include methods (EventListeners) that are triggered by preregistered key events and methods for calling API functions in the BD-ROM playback apparatus 200. 25 Computation procedures and the like in these methods are described by employing local variables allocated to a 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 20 given method and arguments when the method is called. The Java (TM) archive file is as described above. This completes the description of the BD-ROM. The following describes an internal structure of the playback apparatus 5 according to the present invention. <Playback Apparatus> FIG. 12 shows the internal structure of the playback apparatus according to the present invention. The playback 10 apparatus according to the present invention is manufactured based on this internal structure. The playback apparatus according to the present invention is roughly made up of two parts that are a system LSI and a drive device. The playback apparatus according to the is present invention can be manufactured by mounting these parts on a cabinet and substrate of the apparatus. The system LSI is an integrated circuit including various processing units for achieving the functions of the playback apparatus. The playback apparatus manufactured in 20 this way includes a BD-ROM drive 1, a Read Buffer 2, a demultiplexer 3, a Video Decoder 4, a Video Plane 5, a P Graphics Decoder 6, a Presentation Graphics Plane 7, a composition unit 8, a Font Generator 9, an I-Graphics Decoder 10, a switch 11, an Interactive Graphics Plane 12, 25 a composition unit 13, a CLUT unit 14, a CLUT unit 15, an Audio Decoder 16, a Network Device 17, a Local Storage 18, 33386761 (GHMatters) P6261 1.AU.2 18/05112 - 21 a Read Buffer 19, a demultiplexer 20, an instruction ROM 21, a user event processing unit 22, a PSR set 23, a CPU 24, a scenario memory 25, a Local Memory 26, and a switch 27. 5 Elements pertaining to playback of AVClips recorded on the BD-ROM (the BD drive 1 - the Audio Decoder 16) are described firstly. The BD-ROM drive 1 loads/ejects the BD-ROM, and accesses the BD-ROM. 10 The Read Buffer 2 is a FIFO memory in which TS packets read from the BD-ROM are stored on a first-in first-out basis. The demultiplexer (De-MUX) 3 reads TS packets from the Read Buffer 2 and converts these TS packets to PES 15 packets. PES packets having PIDs set by the CPU 24 are then output to any of the Video Decoder 4, the P-Graphics Decoder 6, the 1-Graphics Decoder 10, and the Audio Decoder 16. The Video Decoder 4 decodes a plurality of PES 20 packets output from the demultiplexer 3 to obtain pictures in uncompressed format, and writes these pictures to the Video Plane 5. The Video Plane 5 is for storing uncompressed pictures. A plane is a memory area in the playback 25 apparatus for storing one screen worth of pixel data. The Video Plane 5 has a 1920 X 1080 resolution, with stored 3338676_1 (GHMatters) P62611.AU 2 18/0512 - 22 picture data being constituted from pixel data expressed by 16-bit YUV. In the Video Plane 5, playback video in a video stream can be scaled per frame. Scaling involves changing playback video per frame to either 1/4 (quarter) s or 1/1 (full-scale) of the entire Video Plane 5. Such scaling is executed in a BD-J mode in accordance with an instruction from the CPU 24, enabling screen production whereby a playback image of a video stream is relegated to a corner of the screen or projected over the whole screen. 10 The P-Graphics Decoder 6 decodes a Presentation graphic stream read from the BD-ROM and writes uncompressed graphics to the Presentation Graphics Plane 7. Subtitles appear on the screen as a result of the graphics stream being decoded. is The Presentation Graphics Plane 7, being a memory with room for one screen worth of data, is able to store one screen worth of uncompressed graphics. This plane has a 1920 X 1080 resolution, with each pixel of the uncompressed graphics on the Presentation Graphics Plane 7 20 being expressed by an 8-bit index color. The uncompressed graphics stored on the Presentation Graphics Plane 7 are submitted for display by converting such index colors using a CLUT (Color Lookup Table). The composition unit 8 composites uncompressed 25 picture data (i) stored on the Video Plane 5 with the storage contents of the Presentation Graphics Plane 7. 3338676_1 (GHMatters) P62611.AU.2 1 8/0511 2 - 23 The Font Generator 9 uses a character font to expand text code included in a textST stream in a bitmap, and writes the expanded code to the Presentation Graphics Plane 7. The I-Graphics Decoder 10 decodes an IG stream read from 5 the BD-ROM or the Local Storage 18 in an HDMV mode, and writes uncompressed graphics to the Interactive Graphics Plane 12. The switch 11 selectively writes one of a font sequence generated by the Font Generator 9 and graphics 10 resulting from the decoding by the P-Graphics Decoder 6, to the Presentation Graphics Plane 7. The Interactive Graphics Plane 12 is written with uncompressed graphics resulting from the decoding by the I-Graphics Decoder 10. Characters and graphics drawn by an 15 application are written onto the Interactive Graphics Plane 12 in the BD-J mode. The composition unit 13 composites the storage contents of the Interactive Graphics Plane 12 with a composite image output from the composition unit 8 (i.e. 20 composition of uncompressed picture data and storage contents of the Presentation Graphics Plane 7). This compositing enables characters and graphics written to the I-Graphics Decoder 10 by an application to be overlaid on uncompressed picture data and displayed. 25 The CLUT unit 14 converts index colors in the uncompressed graphics stored on the Video Plane 5 to 3338676_1 (GHMatters) P62611 AU.2 18/05/12 - 24 Y/Cr/Cb. The CLUT unit 15 converts index colors in the uncompressed graphics stored on the Interactive Graphics Plane 12 to Y/Cr/Cb. 5 The Audio Decoder 16 decodes PES packets output from the demultiplexer 3 and outputs uncompressed audio data. The elements pertaining to AVClip playback are as described above. The following describes elements pertaining to operations in the BD-J mode (the Network 10 Device 17 - the De-mux 20). The Network Device 17 realizes a communication function in the playback apparatus. In the case of a Java (TM) application specifying an URL in the BD-J mode, the Network Device 17 establishes a TCP or FTP connection etc. 15 with a website indicated by the URL. The Java (TM) application is made to download from the website as a result of such a connection being established. The Local Storage 18 is a hard disk for storing content supplied from communication media and recording 20 media other than the BD-ROM, such as content downloaded from a website via a connection established by the Network Device 17, together with metadata. The metadata is information for binding and managing downloaded content in the Local Storage 18. By accessing the Local Storage 18, 25 an application in the BD-J mode can perform a variety of processes using the downloaded content. 33386761 (GHMatters) P62611.AU.2 18/05/12 - 25 The Read Buffer 19 is a FIFO memory that stores TS packets constituting a SubClip on a first-in first-out basis in the case of such a SubClip being included in the downloaded content stored on the Local Storage 18. 5 The demultiplexer (De-MUX) 20 reads TS packets from the Read Buffer 19 and converts the read TS packets to PES packets. PES packets having specific PIDs are then output to the Font Generator 9, the I-Graphics Decoder 10, and the Audio Decoder 16. 10 The above elements from the Network Device 17 to the De-mux 20 enable content downloaded by a Java (TM) application via a network to be played in a similar manner to content recorded on the BD-ROM. The following describes elements for realizing collective controls in the playback 15 apparatus (the instruction ROM 21 - the switch 27). The instruction ROM 21 stores software that defines controls relating to the playback apparatus.--> The user event processing unit 22, in response to a key operation of the remote control or the front panel of 20 the playback apparatus, outputs a user event for performing a corresponding operation to the CPU 24. The PSR set 23 is a set of registers internal to the playback apparatus, and is composed of 64 Player Status Registers (PSRs) and 4096 General Purpose Registers 25 (GPRs). PSR4 to PSR8 are used to express a current playback point. 3338676_1 (GHMtters) P62611.AU.2 18/05/12 - 26 PSR4 indicates a title of the current playback point as a result of having been set to a value from 1 to 100. Setting PSR4 to 0 indicates that the current playback point is a top menu. 5 PSR5 indicates a chapter number of the current playback point as a result of having been set to a value from 1 to 999. Setting PSR5 to OxFFFF indicates a null chapter number in the playback apparatus. PSR6 indicates a number of a PL (current PL) to which 10 the current playback point belongs as a result of having been set to a value from 0 to 999. PSR7 indicates a number of a PlayItem (current Playltem) to which the current playback point belongs as a result of having been set to a value from 0 to 255. is PSR8 indicates the current playback point (current PTM (Presentation TiMe)) using 45 KHz time accuracy, as a result of having been set to a value from 0 to OxFFFFFFFF. These PSR4 to PSR8 enable the current playback point to be identified on the time axis shown in FIG. 8. 20 The CPU 24 runs software stored in the instruction ROM 21 to execute controls relating to the entire playback apparatus. These controls change dynamically depending on user events output from the user event processing unit 22 and each PSR value in the PSR set 23. 25 The scenario memory 25 is for storing current PL information and current Clip information. The current PL 3338676_1 (GHMatters) P62611.AU.2 18105/12 - 27 information is a piece of PL information recorded on the BD-ROM that is currently targeted for processing. The current Clip information is a piece of Clip information recorded on the BD-ROM that is currently targeted for 5 processing. The Local Memory 26 is a cache memory for temporarily storing the recorded contents of the BD-ROM, given a low reading speed from the BD-ROM. The provision of the Local Memory 26 allows an application in the BD-J mode to run 10 efficiently. The switch 27 selectively delivers data read from the BD-ROM and the Local Storage 18 to one of the Read Buffer 2, the Read Buffer 19, the scenario memory 25, and the Local Memory 26. 15 The hardware structure of the playback apparatus according to this embodiment is as described above. The following describes a filesystem structure in the playback apparatus according to this embodiment. FIG. 13A shows a directory structure in the Local Storage 20 18. In this directory structure, a subdirectory "DLDAT" is located under a ROOT directory, and under this are subdirectories "PKGO0001" and "PKGO0002". "PKGO0001" and "PKGO0002" are each a volume label of a BD-ROM, and 25 indicate that a directory corresponding to a BD-ROM having a volume label "PKGO0001" and a directory corresponding to 3338676_1 (GHMatters) P62611.AU.2 18105/12 - 28 a BD-ROM having a volume label "PKGO0002" are present on the Local Storage 18. The subdirectory "PKGO0001" shows a location of downloaded data corresponding to the BD-ROM with the volume label "PKGO0001". Providing subdirectories 5 in a directory corresponding to each BD-ROM allows downloaded data relating to each BD-ROM to be stored separately. Under these subdirectories are stored PlayList information, Clip information, and AVClips, similar to what is stored on the BD-ROM. There also additionally 10 exist a Java (TM) archive file and a stream storage location information file. It is supposed here that while an AVClip recorded on the BD-ROM corresponds to a movie work, an AVClip recorded on the Local Storage 18 corresponds to a trailer of a is movie work currently showing at theaters. Since trailers are changed with time, a trailer of a movie work currently showing at theaters is recorded on the Local Storage 18 as an AVClip. The stream storage location information file is 20 explained next. The stream storage location information file is information showing a list of files constituting a Virtual Package. FIG. 13B shows an internal structure of the stream storage location information file. The stream storage location information file is made up of storage 25 location information of each AVClip and Clip information constituting the Virtual Package. Each piece of storage 3338676_1 (GHMatters) P62611 AU.2 18/05/12 - 29 location information is composed of identifiers of AVClips and Clip information and file paths indicating the storage locations of the AVClips and Clip information in the Local Storage 18. By referring to the storage location 5 information, it is possible to check whether all AVClips and Clip information which constitute the Virtual Package have already been prepared when creating the Virtual Package. The filesystem structure of the playback apparatus 10 according to this embodiment is as described above. The following describes a software structure in the playback apparatus according to this embodiment. FIG. 14 depicts elements composed of hardware and software stored on the ROM 24 rearranged in a layer structure. As 15 shown in FIG. 14, the layer structure of the playback apparatus is composed of a) a first layer (BD Player Device), b) a second layer (BD Player Model), and c) a third layer (Application Runtime Environment). A hardware structure of the playback apparatus shown 20 in FIG. 12 belongs to the first layer. The "BD Player Device" at the first layer in the drawing includes a "decoder" composed of the Video Decoder 4, the P-Graphics Decoder 6, the I-Graphics Decoder 10, and the Audio Decoder 16, a "plane" composed of the Video Plane 5, the 25 Presentation Graphics Plane 7, and the Interactive Graphics Plane 12, the BD-ROM and its filesystem, and the 33386761 (GHMatters) P62611.AU.2 18/05/12 - 30 Local Storage 18 and its filesystem. The "BD Player Model" at the second tier is composed of b1) a layer for a Presentation Engine 31 and a Virtual FileSystem 38 and b2) a layer for a Playback Control 5 Engine 32, with API functions being provided in relation to higher levels. The PSR set 23 and the scenario memory 25 shown in FIG. 12 exist inside the Playback Control Engine 32. The "Application Runtime Environment" at the third tier is 10 composed of cl) a stack layer that includes an HDMV module 29a and a BD-J module 29b. The following describes the elements in this software structure. is <HDMV Module 29a, BD-J Module 29b> The HDMV module 29a decodes navigation commands and executes function calls in relation to the Playback Control Engine 32 based on the decoding result. The BD-J module 29b is a so-called Java (TM) platform 20 having a hierarchical structure composed of dl-l) a Java (TM) virtual machine 30 and d1-2) middleware for the Java (TM) virtual machine to operate. <Java (TM) Virtual Machine 30> 25 The Java (TM) virtual machine 30 loads xlet programs constituting applications into a work memory, decodes the 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 31 xlet programs, and performs controls on lower layers in accordance with the decoding results. To perform these controls, the Java (TM) virtual machine 30 issues a method to the middleware, has the middleware replace the method 5 with a function call corresponding to the BD playback apparatus, and issues the function call to the Playback Control Engine 32. <Internal Structure of the Java (TM) Virtual Machine 30> 10 The following describes an internal structure of the Java (TM) virtual machine 30. FIG. 15 shows the internal structure of the Java (TM) virtual machine 30. As shown in FIG. 15, the Java (TM) virtual machine 30 is constituted from the CPU 24 shown in FIG. 12, a user class loader 52, is a method area 53, a work memory 54, threads 55a, 55b,... 55n, and Java (TM) stacks 56a, 56b,... , 56n. The user class loader 52 reads class files in Java (TM) archive files in the BDJA directory from the Local Memory 26 or the like and stores the read class files in 20 the method area 53. The reading of a class file by the user class loader 52 is performed as a result of an application manager 36 sending a read instruction specifying a file path to the user class loader 52. If the file path indicates the Local Memory 26, the user class 25 loader 52 reads a class file in a Java (TM) archive file constituting an application from the Local Memory 26 to 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 32 the work memory 54. If the file path indicates a directory in a FileSystem, the user class loader 52 reads a class file in a Java (TM) archive file constituting an application from the BD-ROM or the Local Storage 18 to the 5 work memory 54. The method area 53 store class files read from the Local Memory 26 by the user class loader 52. The work memory 54 is a so-called heap area storing instances of various class files. The work memory 54 10 stores instances corresponding to resident applications and class files read to the method area 53. Such an instance is an xlet program constituting an application that is made executable by placing the xlet program in the work memory 54. 15 The threads 55a, 55b, ... , 55n are logical execution entities for executing methods stored in the work memory 54. These threads perform calculations using local variables and arguments stored in operand stacks as operands, and store calculation results in local variables 20 or operand stacks. The arrows kyl, ky2, ... , kyn in the drawing symbolically indicate the supply of methods from the work memory 54 to the threads 55a, 55b, ... , 55n. Whereas the CPU is the sole physical execution entity, there may be up to 64 logical execution entities or 25 threads in the Java (TM) virtual machine 30. Threads can be newly created and existing threads deleted within this 3338676_1 (GHMatters) P62611.AU 2 18/05/12 - 33 numerical limit, and the number of operational threads can be varied while the Java (TM) virtual machine 30 is operating. Being able to appropriately increase the number of threads also makes it possible to run instances in s parallel using a plurality of threads for each instance, and thereby speed up the execution of instances. The Java (TM) stacks 56a, 56b, ... , 56n exist in a one-to-one ratio with the threads 55a, 55b, ... , 55n, and each has a program counter ("PC" in the drawing) and one 10 or more frames. The program counters show which part of an instance is currently being executed. A frame is a stack type area allocated to each call for a method, and is composed of an operand stack for storing arguments occurring at the time of the call and a local variable 15 stack ("local variable" in the drawing) for use by the called method. Since frames are stacked on the Java (TM) stacks 56a, 56b, ... , 56n whenever a call is made, the frames of a method that calls itself recursively also get stacked one on top of the other. 20 The internal structure of the Java (TM) virtual machine is as described above. The Java (TM) virtual machine having the above structure serves as an event driven execution entity. This completes the description of the Java (TM) virtual machine. 25 <Presentation Engine 31> 33386761 (GHMatters) P62611.AU.2 18/05/12 - 34 The Presentation Engine 31 executes AV playback functions. The AV playback functions of a playback apparatus are a traditional group of functions inherited from DVD players and CD players, including Play, Stop, 5 Pause On, Pause Off, Still Off, Forward Play (speed), Backward Play (speed), Audio Change, Subtitle Change, and Angle Change. To realize these AV playback functions, the Presentation Engine 31 controls the Video Decoder 4, the P-Graphics Decoder 6, the I-Graphics Decoder 10, and the 10 Audio Decoder 16 to decode a portion of an AVClip read to the Read Buffer 2 that corresponds to a desired time. By having the place indicated by PSR8 (current PTM) decoded as the desired time, arbitrary points in an AVClip can be rendered playable. 15 <Playback Control Engine 32> The Playback Control Engine (PCE) 32 executes various functions including (i) playback controls on PlayLists and (ii) acquiring/setting the status of the PSR set 23. The 20 playback control function for PLs involves having the Presentation Engine 31 execute Play and Stop out of the above AV playback functions, in accordance with current PL information and Clip information. These functions (i) and (ii) are executed according to function calls from the 25 HDMV module 29a and the BD-J module 29b. Synchronization of the processing by the Playback 33386761 (GHMatters) P62611.AU.2 18/05112 - 35 Control Engine 32 with the processing by the Java (TM) virtual machine is described next. The Playback Control Engine 32 executes processing based on PL information when a function is called. This processing is performed for the s duration of the AVClip for playback, whether the playback time is 15 minutes or 30 minutes. A problem here is a time lag between when the Java virtual machine 30 returns a success response and when the Playback Control Engine 32 actually ends the processing. The Java virtual machine 30, io being an event-driven execution entity, returns a response indicating whether playback was successful or not immediately after the call, whereas the Playback Control Engine 32 ends the playback of the AVClip and PlayItem after the 15 or 30-minute playback duration has elapsed. 15 Thus, the time at which a success response is returned to an application cannot be used as a basis for gauging the end of processing 15 or 30 minutes later. Gauging the end of processing becomes all the more difficult when fast forwarding or rewinding is performed during PL playback 20 since the playback time of 15 or 30 minutes is then subject to change. In view of this, the Playback Control Engine 32 outputs events indicating the end of PlayItem and AVClip playback to an application when playback of a respective PlayItem or AVClip ends. This output enables 25 the application to know the points at which the Playback Control Engine 32 concluded PlayItem and AVClip playback. 33386761 (GHMatters) P6261 1.AU.2 18/05112 - 36 This completes the description of the Java (TM) virtual machine, the Network Device 31, and the Playback Control Engine 32. The controls on the Playback Control Engine 32 by the Java virtual machine are performed via a s Virtual Package. To realize the controls on the Playback Control Engine 32 via a Virtual Package, the playback apparatus includes the following elements (a network management module 37, a Virtual FileSystem unit 38, a management information conversion module 39, and a method 10 execution module 40). These elements are described next. <Network Management Module 37> The Network Management Module 37 downloads data required for creating Virtual Packages from websites 15 administrated by the providers of movie works, in accordance with method calls from applications. This data includes stream storage location information files, PlayList information, Clip information, and AVClips. When download requests are made by applications in the Work 20 memory 54, the network management module 37 downloads data required for creating Virtual Packages via a network and writes the downloaded data to the Local Storage 18. An order of writing in the download is: a stream storage location information file PlayList information a 25 plurality of pieces of Clip information a plurality of AVClips. 33386761 (GHMatters) P62611.AU.2 16/05/12 - 37 Once the writing of the PlayList information to the plurality of pieces of Clip information has completed, the creation of a Virtual Package becomes possible. 5 <Virtual FileSystem Unit 38> The Virtual FileSystem unit 38 is an element belonging to the second layer that creates Virtual Packages in accordance with method calls from applications. The creation of a Virtual Package includes a 10 process to manage a status of each AVClip constituting the Virtual Package and a process to generate Virtual Package information. 1. Virtual Package Information 15 Virtual Package information expands volume management information on the BD-ROM. The volume management information referred to here defines a directory - file structure existing on a recording medium, and is composed of directory management information relating to 20 directories and file management information relating to files. The Virtual Package information expands the directory - file structure on the BD-ROM, by adding new file management information to the volume management 25 information showing the directory - file structure of the BD-ROM. The file management information added to the 3338676_1 (GHMatters) P62611 .AU-2 18/05/12 - 38 volume management information relates to PlayList information, Clip information, and AVClips existing on the Local Storage 18. Generating the Virtual Package information to which this file management information has s been added and providing this Virtual Package information to the Playback Control Engine 32 enables the Playback Control Engine 32 to recognize the PlayList information, the Clip information, and the AVClips stored on the Local Storage 18 as existing on the BD-ROM. FIG. 16 shows an 10 exemplary generation of Virtual Package information by the Virtual FileSystem unit 38. At the top left of FIG. 16 is the directory - file structure on the BD-ROM, this being the same as FIG. 2. At the bottom left is the directory file structure on the Local Storage 18, this being the 15 same as FIG. 13A. File management information relating to the PlayList information, the Clip information, and the AVClips on the Local Storage 18 is added to the volume management information on the BD-ROM. Specifically: 20 i) file management information relating to a PlayList (00002.MPLS) on the Local Storage 18 is added to the directory management information of the MPLS directory in the BD volume management information; ii) file management information relating to Clip 25 information#2, #3, and #4 (00002.CLPI, 00003.CLPI, 00004.CLPI) on the Local Storage 18 is added to the 33386761 (GHMatters) P62611.AU.2 18/05/12 - 39 directory management information of the CLPI directory in the BD volume management information; and iii) file management information relating to AVClips#2, #3, and #4 (00002.M2TS, 00003.M2TS, 00004.M2TS) 5 on the Local Storage 18 is added to the directory management information of the STREAM directory in the BD volume management information. Virtual Package information is thus obtained. In other words, Virtual Package information is volume 10 management information that has been generated as a result of the above addition. This Virtual Package information is then provided to the Playback Control Engine 32, which is thereby able to treat the PlayList information, the Clip information, and 15 the AVClips on the Local Storage 18 on an equal basis with PlayList information, Clip information, and AVClips on the BD-ROM. The generation of Virtual Package information is as described above. The following describes status management by the Virtual FileSystem unit 38. 20 2. enable and disable "Status management" mentioned here is management of whether an AVClip which constitutes a Virtual Package is in an enable status or a disable status. When a piece of 25 PlayItem information in PlayList information is targeted for multi-angle, each AVClip which forms a multi-angle 33366761 (GHMatters) P62611 .AU.2 18/05112 - 40 section is subjected to enable/disable status management. When SubPlayItem information is present in PlayItem information, an AVClip indicated by a Clipinformation file name of the SubPlayItem information s is subjected to enable/disable status management, too. FIG. 17A shows an example of status management by the Virtual FileSystem unit 38. As illustrated, an AVClip has two statuses that are "enable" and "disable". "Enable" indicates that Clip information and an AVClip 10 corresponding to the Clip information exist on the Local Storage 18 and the AVClip is set in Read Only Mode. Meanwhile, "disable" indicates that Clip information exists on the Local Storage 18 but an AVClip corresponding to the Clip information is either absent on the Local 15 Storage 18 (Missing Stream) or, even if present, deletable. An AVClip in the disable status is treated as deletable. Accordingly, when the capacity of the Local Storage 18 is not enough, an AVClip in the disable status 20 is subjected to deletion. Therefore, when an AVClip is downloaded to the Local Storage 18, the Playback Control Engine 32 treats the downloaded AVClip as nonexistent, unless the Virtual FileSystem unit 38 changes the AVClip to the enable 25 status. Since the Playback Control Engine 32 does not recognize the AVClip on the Local Storage 18 in the 33386761 (GHMatters) P62611.AU-2 18/05/12 - 41 absence of an action of the Virtual FileSystem unit 38, the Playback Control Engine 32 can be prevented from proceeding in playback in an unstable state. 5 3. Read Only Mode and Cancellation Read Only Mode is described next. The change to Read Only Mode is performed by rewriting file management information in volume management information on the Local Storage 18. A target of this rewriting is file management 10 information in the PACKAGE00001 directory under the DLDAT directory in the Local Storage 18. Rewriting all file attributes in such file management information to Read only, an AVClip on the Local Storage 18 can be kept from being rewritten. As a result, the AVClip will not be is rewritten even when an application tries to access the AVClip on the Local Storage 18 during playback by the Playback Control Engine 32, with it being possible to maintain the sameness of the AVClip during playback. When an AVClip on the Local Storage 18 is made 20 recognizable by the Playback Control Engine 32, an attribute of a file storing this AVClip on the Local Storage 18 is set to Read-only. Accordingly, even if an application on the Java (TM) virtual machine directly accesses the Local Storage 18, the contents of the AVClip 25 will not be changed. Cancellation of Read Only Mode is explained next. 33386761 (GHMatters) P62611.AU.2 18105/12 - 42 Cancellation of Read Only Mode is performed by rewriting file management information in volume management information on the Local Storage 18, in the same way as setting to Read Only Mode. A target of this rewriting is 5 file management information in the PACKAGE00001 directory under the DLDAT directory in the Local Storage 18. By changing an attribute of such file management information from Read-only to Re-writable, an AVClip on the Local Storage 18 is made rewritable any time. Accordingly, by 10 changing the file management information in the Local Storage 18 to Re-writable immediately after the playback by the Playback Control Engine 32 ends, the AVClip on the Local Storage 18 can be targeted for deletion. This completes the description of the status management. 15 4. Relationship between Status Management and Virtual Package Information The contents of this status management can be reflected onto the generation of the Virtual Package 20 information. Which is to say, file management information for an AVClip which is set to the disable status in the status management is not added to the volume management information of the BD-ROM, and only file management information for an AVClip which is set to the enable 25 status in the status management is added to the volume management information of the BD-ROM. Providing such 33386761 (GHMatters) P62611 AU.2 1805/12 - 43 generated Virtual Package information to the Playback Control Engine 32 enables the Playback Control Engine 32 to recognize only the AVClip which is in the enable status. Suppose, of AVClip#1 on the BD-ROM and AVClips#2, 5 #3, and #4 on the Local Storage 18, AVClips#l and #2 are in the enable status whereas AVClips#3 and #4 are in the disable status. This being the case, the Virtual FileSystem unit 38 generates Virtual Package information as shown in FIG. 18. FIG. 18 shows the generation of 10 Virtual Package information that reflects the status management. In the drawing, file management information for AVClip#2 is added to the directory management information in the STREAM directory in the BD volume management information, but file management information 15 for AVClips#3 and #4 is not added to the directory management information in the STREAM directory in the BD volume management information. When, of the four AVClips shown at the bottom left of FIG. 18, 00002.M2TS corresponding to AVClip#2 is in the enable status and 20 00003.M2TS and 00004.M2TS corresponding to AVClips#3 and #4 are in the disable status, a file attribute of 00002.M2TS corresponding to AVClip#2 is set to Read-only whilst file attributes of 00003.M2TS and 00004.M2TS corresponding to AVClips#3 and #4 are set to Re-writable 25 in the Local Storage 18, as shown in the drawing. As a result of providing such generated Virtual Package 3338676_1 (GHMatters) P62611.AU-2 18/05112 - 44 information to the Playback Control Engine 32, the Playback Control Engine 32 will not recognize AVClips#3 and #4 which are in the disable status. As mentioned above, when Clip information exists but 5 a corresponding AVClip does not exist on the Local Storage 18, the AVClip is set to the disable status. However, if not only the AVClip but also the Clip information does not exist on the Local Storage 18 despite that a file path corresponding to the Clip information is present in a 10 stream storage location information file, it is impossible to create a Virtual Package. That is, the absence of essential Clip information in a Virtual Package affects the entire Virtual Package. is 5. Provision of Virtual Package Information The following describes how the Virtual Package information generated in the above processes 1 to 4 is provided. Suppose PlayList information, Clip information#2 to 20 #4, and AVClip#2 have already been downloaded but AVClips#3 and #4 have not been downloaded, as shown in FIG. 18. If the generation of Virtual Package information is requested in such a state, the Virtual FileSystem unit 38 performs an operation shown in FIG. 19. FIG. 19 shows 25 the creation of the Virtual Package by the Virtual FileSystem unit 38 in the case where the download by the 33386761 (GHMatters) P62611.AU.2 18/05/12 - 45 network management module 37 is still in progress. When the creation of the Virtual Package is requested in the state shown in the drawing ( 1 VPCreate), the Virtual FileSystem unit 38 reads directory management information 5 and file management information from the BD-ROM and the Local Storage 18 ( 2, 3), and creates the Virtual Package. The Virtual FileSystem unit 38 then provides the Virtual Package information to the Playback Control Engine 32 ( 4), and to the application ( 5). This enables the Playback 10 Control Engine 32 to create one stream sequence from the AVClips on the BD-ROM and the Local Storage 18 through the Virtual Package. The Virtual Package information provided to the application indicates that Clip information#3 and #4 exist 15 but AVClips#3 and #4 do not exist. Accordingly, the application can recognize that AVClips#3 and #4 constitute the stream sequence but are nonexistent streams (Missing Streams). This completes the description of the Virtual 20 FileSystem unit 38. <Management Information Conversion Module 39> The management information conversion module 39 is a piece of middleware in the BD-J Module 29b. When an 25 application requests generation of an instance of PlayList information in the Virtual Package, the management 33386761 (GHMatters) P62611.AU.2 18/05/12 - 46 information conversion module 39 generates the instance of the PlayList information in JMF format in the Work memory 54 of the Java (TM) virtual machine (PlayList object in the Work memory 54 shown in FIG. 15). 5 This instance (PlayList object) has a "data unit" which is the PlayList information and a plurality of "method units". A plurality of methods in a PlayList object have the Playback Control Engine 32 perform various playback 10 operations such as Play, Stop, Pause On, Pause Off, Still Off, Forward Play (speed), Backward Play (speed), Audio Change, Subtitle Change, and Angle Change. By calling these methods, the application can initiate or stop playback of a stream sequence defined by the PlayList. 15 The PlayList information played back by the PlayList object is described below. This PlayList information is PlayList information existing on the Local Storage 18. While PlayList information on the BD-ROM refers only to AVClips on the BD-ROM, PlayList information on the Local 20 Storage 18 is called "Progressive PlayList information" that refers to both AVClips on the BD-ROM and AVClips on the Local Storage 18. Suppose the Progressive PlayList information is made up of five pieces of PlayItem information#1 to #5. When 25 the three pieces of PlayItem information#l-#3 refer to Clip information on the BD-ROM whilst the remaining two 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 47 pieces of PlayItem information#4 and #5 refer to Clip information on the Local Storage 18, the Progressive PlayList information can define one stream sequence from an AVClip on the BD-ROM and AVClips on the Local Storage 5 18, as shown in FIG. 20A. FIG. 20A shows a PlayList playback time axis that is defined by PL information stored on the Local Storage. The first tier in the drawing shows a playback time axis of an AVClip recorded on the BD-ROM, and the second tier shows a 10 PlayList playback time axis defined by PL information stored on the Local Storage. The third tier shows a playback time axis of AVClip#2 recorded on the Local Storage, the fourth tier shows a playback time axis of AVClip#3 recorded on the Local Storage, and the fifth tier 15 shows a playback time axis of AVClip#4 recorded on the Local Storage. When PlayItem information#4, PlayItem information#5, and PlayItem information#6 in the PlayList information specifyAVClip#2, AVClip#3, andAVClip#4 as playback 20 sections, then the Progressive PlayList information can define the AVClip on the BD-ROM and the AVClips on the Local Storage 18 as one stream sequence. Here, the term "Progressive" in the Progressive PlayList information means that, if at least one of the AVClips 25 referenced by the PlayItem information which constitutes the PlayList information is in the enable status, the 33386761 (GHMatters) P62611.AU.2 18/05/12 - 48 playback of the stream sequence can be started even when the other AVClips are in the disable status. FIG. 20B shows a concept of Progressive PlayList information. The second to fifth tiers in FIG. 20B 5 correspond to the second to fifth tiers in FIG. 20A. In the case where the AVClip at the third tier in FIG. 20A and FIG. 20B is in the enable status but the AVClips at the fourth and fifth tiers are in the disable status, of the four AVClips referenced by the Progressive PlayList 10 information, AVClips#l and #2 are playable though AVClips#3 and #4 are not playable. Accordingly, the playback of the stream sequence can be started. Thus, Progressive PlayList information has a characteristic in that playback can be started speculatively if at least one is AVClip is playable. In a stage where the Virtual FileSystem unit 38 has created a Virtual Package, when an application on the Work memory 54 requests generation of an instance of the Progressive PlayList information shown in FIG. 20, the 20 management information conversion module 39 performs processing shown in FIG. 21. FIG. 21 shows generation of an instance by the management information conversion module 39. When the application calls a generation method to 25 request the generation of an instance of PlayList information included in the Virtual Package (@1), the 33386761 (GHMatters) P62611 AU.2 18/05/12 - 49 management information conversion module 39 reads the PlayList information from the scenario memory 25 (@2), and generates a PlayList object by setting this Progressive PlayList information as a data unit and adding 5 method units, on the Work memory 54 (@3). Once such a PlayList object has been obtained on the Work Memory 54, the application can instruct the Playback Control Engine 32 to play back the stream sequence defined by the PlayList information, by calling a method of the PlayList 10 object. FIG. 22 shows a call of a Play method in the PlayList object. By calling a Play method (@4), a PL playback function call is made to the Playback Control Engine 32 (@5). As a result, the Playback Control Engine 32 reads 15 the AVClips referenced by the PlayList information which is requested to be played back (AVClip#1 on the BD-ROM and AVClip#2 on the Local Storage 18) (@6, 7), and supplies these AVClips to the decoder in sequence. This completes the description of the management information conversion 20 module 39. <Method Execution Module 40> The method execution module 40 is one of the elements of the middleware in the BD-J Module 29b, and executes 25 various methods in response to method calls from an application existing in the Java (TM) virtual machine 30. 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 50 There are various methods that are executed by the method execution module 40. Characteristic methods used in the present invention are a getMissingStreams method, an enableClip method, a disableClip method, and a s getDisableClips method. These methods are explained below. 1. getMissingStreams Method The getMissingStreams method is a method for inquiring of the Virtual FileSystem unit 38 about the 10 existence of any AVClip which is a Missing Stream, while download by the network management module 37 is still in progress. Suppose the Virtual Package information shown in FIG. 19 is provided to an application on the Work Memory 54. 15 Missing Streams known at the time of the Virtual Package creation are AVClips#3 and #4. After this, when the application calls the getMissingStreams method to inquire of the Virtual FileSystem unit 38 about latest Missing Streams, the method execution module 40 performs the 20 processing shown in FIG. 23. FIG. 23 schematically shows a result of this inquiry. In the drawing, the getMissingStreammethod is called as shown by ©1, and the Virtual FileSystem unit 38 returns AVClip#4 as a return value. Before the getMissingStreams 25 method call, AVClips#3 and #4 are Missing Streams. After the getMissingStreams method call, on the other hand, only 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 51 AVClip#4 is a Missing Stream. This indicates that AVClip#3 is no longer a Missing Stream (i.e. the download of AVClip#3 has completed). In this way, an extent of elimination of Missing Streams as the download progresses s can be detected. 2. enableClip Method The enableClip method is a method for, when an AVClip which was a Missing Stream at the time of Virtual Package 10 creation has become no longer a Missing Stream, setting the AVClip to the enable status. Suppose the enableClip method is called for AVClip#3 as it becomes apparent that AVClip#3 is no longer a Missing Stream in FIG. 23. In this case, the method 15 execution module 40performsprocessingshowninFIG.24. FIG.24 schematically shows a call of the enableClip method. When the enableClip method is called for AVClip#3 (@3), the application has AVCLip#3 changed to the enable status, and a success response is returned to the application (@2). 20 In this way, AVClips which are no longer Missing Streams in the creation of a Virtual Package can be changed to the enable status. When an AVClip is set to the enable status, the method execution module 40 has Virtual Package information 25 including the AVClip which is newly set to the enable status, provided to the application and the Playback 3338676_1 (GHMatters) P62611.AU 2 18/05/12 - 52 Control Engine 32. This allows the Playback Control Engine 32 and the application to recognize and access the AVClip newly set to the enable status. 5 3. disableClip Method The disableClip method is a method for setting an AVClip which is in the enable status, to the disable status. Suppose an event that the playback of AVClip#2 has completed is notified by the Playback Control Engine 32 io during the playback of the Progressive PlayList information shown in FIG. 20. In this case, upon the notification of the completion of the playback of AVClip#2, the method execution module 40 performs processing shown in FIG. 25. FIG. 25 schematically shows a 15 call of the disableClip method. In the drawing, when notified of the completion of the playback of AVClip#2 as a result of the progress of the playback by the Playback Control Engine 32 using an end of Clip event (©l), the application calls the disableClip method for AVClip#2 20 (@2) to change AVClip#2 to the disable status. In this way, when the playback of the AVClip has completed, the AVClip can be changed to the disable status. AVClip#2 changed to the disable status is targeted for deletion. In the case where AVClips which constitute trailers are 25 sequentially downloaded, by setting AVClips which have been played back in a stream sequence defined by 33386761 (GHMatters) P62611.AU.2 18/05/12 - 53 Progressive PlayList information to the disable status one by one, these AVClips can be submitted for deletion. When an AVClip is set to the disable status, the method execution module 40 has Virtual Package information s fromwhich the AVClip newly set to the disable status has been removed, provided to the application and the Playback Control Engine 32. As a result, the Playback Control Engine 32 will not recognize the AVClip set to the disable status. It should be noted here that, when deleting an 10 AVClip on the Local Storage 18, the middleware checks a write permission of an application which requests the deletion before executing the deletion, in order to prevent an erroneous loss of AVClips. 15 4. getDisableClips Method The getDisableClips method is a method for inquiring about the existence of any AVClip in the disable status. By calling this method, an application can obtain information as to whether any AVClip is currently in the 20 disable status. One example of use is given below. Upon receiving a chapter skip request from a user during playback of a Progressive PlayList, the application uses this method to judge whether a jump destination AVClip is in the disable 25 status. If the AVClip is in the disable status, a warning message such as "you cannot jump to this chapter because 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 54 download is not completed" is displayed without performing a chapter skip. In this way, special playback such as a chapter skip can be performed during playback of a Progressive PlayList. 5 This completes the description of the methods executed by the method execution module 40. Details of processing of the aforementioned elements are described below, with reference to flowcharts. FIG. 26 is a flowchart showing a procedure when 10 creating a Virtual Package. A judgment is made as to whether whole Clip information corresponding to AVClips stored in a stream storage location information file is stored on the Local Storage 18 (step Sl). If there is any Clip information which is not present, a false response is 15 returned to a call of a Virtual Package by an application (step S10). When not only the AVClips but also the Clip information does not exist in the Local Storage despite that a file path corresponding to the Clip information is included in the stream storage location information file, 20 it is impossible to create a Virtual Package. If all pieces of Clip information written in the stream storage location information file are stored on the Local Storage 18 (step Sb: YES), on the other hand, file management information of PlayList information in the 25 Local Storage 18 is added to directory management information of a PLAYLIST directory in BD volume 33386761 (GHMatters) P62611 AU.2 18/05/12 - 55 management information (step S2), and file management information of Clip information in the Local Storage 18 is added to directory management information of a CLPINF directory in the BD volume management information (step 5 S3) . After this, a loop of steps S4 to S8 is executed. This loop repeats steps S6 to S8 for each piece of Clip information on the Local Storage 18 (steps S4, SS). A piece of Clip information subjected to the operation of the loop is denoted as Clip information x. 10 In the loop, an AVClip corresponding to Clip information x is specified (step S6), and a judgment is made as to whether this AVClip is in the enable status or the disable status (step S7). If the AVClip is in the enable status, file management information of AVClip x on 15 the Local Storage 18 is added to directory management information of a STREAM directory in the BD volume management information (step S8). If the AVClip is in the disable status, on the other hand, step S8 is skipped. As a result of repeating the above operation for each piece 20 of Clip information and AVClip, file management information for each AVClip which is in the enable status is added to the BD volume management information. The BD volume management information obtained as a result of this addition is Virtual Package information. The Virtual 25 Package information is provided to the application which has called the Virtual Package and the Playback Control 33386761 (GHMatters) P62611.AU.2 18/05/12 - 56 Engine 32 (step 59). This completes the procedure. FIG. 27A is a flowchart showing a procedure when calling the enableClip method. When this method is called, AVClip y which is to be set to the enable status is 5 specified from an argument in the call (step S14), and judgments of steps S15 and S16 are performed in this order. Step S15 is a judgment as to whether AVClip y is stored on the Local Storage 18, and step S16 is a judgment as to whether a file path of AVClip y is written in the 10 stream storage location information file. Any of when AVClip y is not stored on the Local Storage 18 and when the file path of AVClip y is not written in the stream storage location information file, a false response is returned to the caller, and the procedure ends (step S19). is If AVClip y is stored on the Local Storage 18 and the file path of AVClip y is written in the stream storage location information file, AVClip y is set to the enable status. Also, a file attribute of a file storing AVClip y in the Local Storage 18 is set to Read-Only, to set AVClip y to 20 Read Only Mode (step S17). After this, a success response is returned (step S18). FIG. 27B is a flowchart showing a procedure when calling the disableClip method. When this method is called, AVClip y which is to be set to the disable status 25 is specified from an argument in the call (step S21), and judgments of steps S22 and S23 are performed in this 33386761 (GHMatters) P62611 AU.2 18/05/12 - 57 order. Step S22 is a judgment as to whether AVClip y is being played back, and step S23 is a judgment as to whether a file path of AVClip y is not written in the stream storage location information file. Any of when 5 AVClip y is being played back and when the file path of AVClip y is not written in the stream storage location information file, a false response is return to the caller, and the procedure ends (step S26). If AVClip y is not being played back and the file path of AVClip y is 10 written in the stream storage location information file, on the other hand, AVClip y is set to the disable status. Also, a file attribute of a file storing AVClip y is set to Re-writable, to cancel Read Only Mode of AVClip y (step S24). After this, a success response is returned (step 15 S25). FIG. 28 is a flowchart showing a playback procedure by the Playback Control Engine 32. In this flowchart, a loop of steps S33 to S42 is performed with a beginning piece of PlayItem information in PlayList information 20 being set as PlayItem i. A control variable in the loop of steps S33 to S42 is variable i. An operation of performing steps S33 to S42 and then incrementing control variable i is conducted until variable i exceeds a number of PlayItems (Number Of PlayItem) (step S41). 25 Steps S32 to S40 are described below. An AVClip shown in a Clip information file name in PlayItem information i 3338676_1 (GHMatters) P62611 AU.2 18/05/12 - 58 is set as AVClip j (step S33), which is targeted for playback. Step S34 is a judgment as to whether AVClip j is in the enable status or not. If AVClip j is not in the enable status, the procedure is terminated at this point. 5 If AVClip j is in the enable status, the drive device and the decoder are instructed to play AVClip j from a PlayItem. In-time to a PlayItem.Outtime (step S35). Step S36 is a judgment as to whether there exists SubPlayItem k specifying PlayItem information i in 10 SyncPlayItem id. If this SubPlayItem does not exist, the procedure directly moves to step S41. If the SubPlayItem exists, the AVClip shown by the Clipinformation file name of SubPlayItem k is set as AVClip h (step S38), and a judgment is made as to whether AVClip h is in the enable 15 status (step S39). If AVClip h is in the enable status, the drive device and the decoder are instructed to play AVClip h from a Sync_StartPTSofPlayItem to Outtime, and then the procedure moves to step S41 (step S40). If AVClip h is not in the enable status, step S40 is 20 skipped. A stream sequence defined by the PlayList information is played back as a result of this process being repeated for all of the PlayItem information constituting the PlayList information. FIG. 29 is a flowchart showing a procedure of an application. First, 25 the application requests download of a stream storage location information file, PlayList information, Clip 33386761 (GHMetters) P62611.AU.2 18/05/12 - 59 information, and AVClips (step S51). The application then requests creation of a Virtual Package (step S52). Step S53 is a judgment as to whether the creation request results in a success. The Virtual Package creation request 5 is repeated until the Virtual Package creation results in a success. Once the creation of the Virtual Package has resulted in a success, step S55 is performed. Step S55 is a judgment as to whether Virtual Package information 10 contains any Missing Stream. In detail, if Clip information exists but an AVClip corresponding to the Clip information does not exist, that AVClip is acquired as a Missing Stream (step S56). After this, a Play method of Progressive PlayList 15 information is called in step S57, and a judgment is made as to whether the Play method results in success (step S58). If the Play method results in false, the procedure ends. If the Play method results in success, a loop of steps S59 to S61 is performed. 20 Step S59 is a call of the getMissingStreams method. Step S60 is a judgment as to whether, upon notification of a Missing Stream in response to the call of step 559, download of any previously acquired Missing Stream has completed. 25 Step S61 is a judgment as to whether an event showing completion of playback of an AVClip occurs. The 3338676_1 (GHMatters) P6261 1.AU.2 18/05/12 - 60 application repeats steps S59 to S61 while the playback is being performed by the Playback Control Engine 32. If there is an AVClip the download of which has completed in the above repetition (step S60: YES), the 5 enableClip method is called for that Missing Stream which has been downloaded (step S62) . This allows the AVClip which has been downloaded to be promptly set to the enable status. If there is anyAVClip the playback of which has 10 completed (step S61: YES), the application judges whether that AVClip is a trailer or not. If the AVClip is a trailer, the application calls the disableClip method for the AVClip. This allows a trailer AVClip which has been played back, to be promptly set to the disable status. 15 <Operation> An operation of the playback apparatus when playing back the PlayList information shown in FIG. 20 is described below. FIGS. 30 to 33 show the progress of 20 download by the network management module 37 and the progress of playback by the Playback Control Engine 32. The first tier shows the progress of download by the network management module 37, and the second tier shows the progress of playback by the Playback Control Engine 25 32. The third tier shows an actual time axis, and the fourth tier shows method calls by the application. 3338676t (GHMatters) P62611.AU.2 18/05/12 - 61 As shown at the first tier, the download by the network management module 37 is composed of download of the PlayList information shown in FIG. 20, download of Clip information#1 to #4, and download of AVClips#l to #4. 5 FIG. 30A: current time = time tO Time tO is a time at which the download of the PlayList information and Clip information#1 to #4 has completed. Accordingly, the creation of a Virtual Package 10 becomes possible. Since the PlayList information in the Virtual Package references AVClip#l and AVClip#1 is in the enable status, the playback of the stream sequence begins at to. 15 FIG. 30B: current time = time tl Time tl is a time at which the playback of AVClip#l referenced by PlayList#l is still in progress but the download of AVCLip#2 has completed. Since the download of AVClip#2 has completed, AVClip#2 is no longer in the 20 disable status. The application can set AVClip#2 to the enable status by calling the enableClip method. As a result of the call, PlayItem#4 corresponding to AVClip#2 is targeted for playback. 25 FIG. 31A: current time = time t2 Time t2 is a time at which the playback of AVClip#2 33386761 (GHMatters) P62611.AU.2 18/05/12 - 62 referenced by PlayList#1 is still in progress but the download of AVCLip#3 has completed. Since the download of AVClip#3 has completed, AVClip#3 is no longer in the disable status. The application can set AVClip# 3 to the 5 enable status by calling the enableClip method. As a result of the call, PlayItem#5 corresponding to AVClip#3 is targeted for playback. FIG. 31B: current time = time t3 Time t3 is a time at which the playback of AVClip#2 10 has completed. Since the playback of AVClip#2 has completed and AVClip#2 is a trailer, AVClip#2 referenced by the PlayItem can be subjected to deletion. This being so, the disableClip method is called for AVClip#2, to make AVClip#2 subjected to deletion. As a result, the Playback is Control Engine 32 can treat AVClip#2 as nonexistent. FIG. 32A: current time = time t4 Time t4 is a time at which the playback of AVClip#3 referenced by PlayList#1 is still in progress but the 20 download of AVClip#4 has completed. Since the download of AVClip#4 has completed, AVClip#4 is no longer in the disable status. The application can set AVClip#4 to the enable status by calling the enableClip method. As a result of the call, PlayItem#6 corresponding to AVClip#4 25 is targeted for playback. 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 63 FIG. 32B: current time = time t5 Time t5 is a time at which the playback of AVClip#3 has completed. Since the playback of AVClip#3 has completed and AVClip#3 is a trailer, AVClip#3 referenced 5 by PlayItem#5 can be subjected to deletion. This being so, the applicationmakes AVClip#3 subjected to deletion by calling the disableClip method for AVClip#3. As a result, the Playback Control Engine 32 can treat AVClip#3 as nonexistent. 10 FIG. 33: current time = time t6 Time t6 is a time at which the playback of AVClip#4 has completed. Since the playback of AVClip#4 has completed and AVClip#4 is a trailer, AVClip#4 referenced 15 by PlayItem#6 can besubjectedtodeletion. This being so, the applicationmakes AVClip#4 subjected to deletion by calling the disableClip method for AVClip#4. As a result, the Playback Control Engine 32 can treat AVClip#4 as nonexistent. 20 According to this embodiment, the download by the network management module 37 and the playback by the Playback Control Engine 32 are performed in parallel, and a downloaded AVClip is changed from the disable status to the enable status to have the AVClip played by the 25 Playback Control Engine 32. This makes it possible to realize "follow-up playback" of proceeding playback so as 33386761 (GHMatters) P62611.AU.2 18/05/12 - 64 to follow the progress of download. Also, any of the downloaded digital streams, the playback of which has completed, is changed from the enable status to the disable status, to have the played s digital stream deleted. This makes it possible to realize "follow-up deletion" of proceeding the deletion so as to follow the progress of playback. Thus, "follow-up playback" of proceeding playback so as to follow the progress of download and "follow-up deletion" 10 of proceeding deletion so as to follow the progress of playback become possible. Therefore, even in the case where a communication rate of a communication line connecting the playback apparatus is low and a capacity of the Local Storage 18 internal to the playback apparatus is 15 small, a digital stream recorded on the BD-ROM and a digital stream downloaded on the Local Storage 18 can be successively played back as one stream sequence. Though the present invention has been described by way of the above embodiment, the present invention is not 20 limited to such. The present invention can be realized with any of the following modifications. The invention of each of the claims of this application includes extension and generalization of the above embodiment and its modifications below. The degree of extension and 25 generalization depends upon the state of the art in the technical field of the present invention at the time when 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 65 this application was filed. (A) The embodiment does not mention specific data structures of directory management information and file management information in the description of the Virtual 5 FileSystem unit 38. However, in the case where the filesystem in the BD-ROM is prescribed by ISO/IEC 13346, the directory management information may be constituted by a "directory file" and a "file entry". The directory file is made up of a file descriptor showing a directory name 10 of a subordinate directory and a file descriptor showing a file name of a subordinate file. The file entry is made up of a descriptor tag, an ICB tag, an allocation descriptor length, an extension attribute, and an allocation descriptor. is The file management information may be composed of file entries. The allocation descriptor shows a storage location of each extent constituting a file. In this case, Virtual Package information is generated by adding a file descriptor of a file name of an AVClip on 20 the Local Storage to a directory file corresponding to the STREAM directory in the volume management information of the BD-ROM, and adding a file entry of the AVClip on the Local Storage to under the STREAM directory in the volume management information of the BD-ROM. 25 (B) The embodiment describes the case where the BD ROM is used as a recording medium. However, the present 3338676_1 (GHMatters) P62611 AU.2 18/05/12 - 66 invention is applicable to any recording medium that is capable of recording an AVClip and PlayList information. Examples of such a recording medium include: an optical disc such as a DVD-ROM, a DVD-RAM, a DVD-RW, a DVD-R, a 5 DVD+RW, a DVD+R, a CD-R, or a CD-RW; a magneto-optical disk such as a PD or an MO; a semiconductor memory card such as a CompactFlash (TM) card, a SmartMedia card, a Memory Stick card, a MultiMediaCard, or a PCMCIA card; a magnetic disk such as a flexible disk, SuperDisk, Zip, or 10 Clik!; a removable hard disk drive such as ORB, Jaz, SparQ, SyJet, EZFley, or Microdrive, and a hard disk drive internal to an apparatus. (C) The embodiment describes the case where the playback apparatus decodes an AVClip recorded on the BD 15 ROM and outputs the decoded AVClip to the television. As an alternative, the playback apparatus may be equipped with only a BD-ROM drive, with the remaining construction elements being provided in the television. In this case, the playback apparatus and the television can be 20 incorporated in a home network connected with an IEEE 1394 connector. The embodiment describes the case where the playback apparatus is connected to the television, but the playback apparatus may instead be integrated with a display device. Also, the playback apparatus may include 25 only an element which constitutes an essential part of processing. Each of these forms of playback apparatus is 33386761 (GHMatters) P62611.AU 2 18/05/12 - 67 an invention described in this specification. Accordingly, regardless of the form of the playback apparatus, an act of manufacturing a playback apparatus based on the internal structure of the playback apparatus described in s the embodiment is an act of working of the present invention. Also, any act of assigning with charge (i.e. for sale) or without charge (i.e. as a gift), leasing, and importing the playback apparatus is an act of working of the present invention. Likewise, an act of offering for io assignment or lease of the playback apparatus using storefront displays, catalogs, or brochures is an act of working of the present invention. (D) Information processing using programs shown in the flowcharts is actually realized using hardware 15 resources. Accordingly, the programs which describe the operational procedures shown in the flowcharts are themselves an invention. The embodiment describes the case where the programs are incorporated in the playback apparatus, but the programs can be implemented 20 independently of the playback apparatus. Acts of working of the programs include (1) an act of manufacturing, (2) an act of assigning with or without charge, (3) an act of leasing, (4) an act of importing, (5) an act of providing to the public via a bi-directional electronic 25 communications network, and (6) an act of offering for assignment or lease using storefront displays, catalogs, 33386761 (GHMatters) P62611.AU.2 18/05/12 - 68 or brochures. (E) The time elements of the steps which are executed in a time series in each of the flowcharts can be regarded as the necessary elements of the present invention. This s being so, a playback method shown by these flowcharts is an invention. If the processing shown in each flowchart is carried out by performing the steps in a time series so as to achieve the intended aim and the intended effect, this is an act of working of the recording method of the 10 present invention. (F) The embodiment describes the case where an AVClip is used as a digital stream recorded on the recording medium, but the present invention can also be realized with a VOB (Video Object) of the DVD-Video Format or the 15 DVD-Video Recording Format. The VOB is a program stream that complies with the ISO/IEC 13818-1 Standard and is obtained by multiplexing a video stream and an audio stream. Also, the video stream in the AV Clip may be an MPEG4 video stream or a WMV video stream. Further, the 20 audio stream in the AV Clip may be a Linear PCM audio stream, a Dolby AC-3 audio stream, an MP3 audio stream, an MPEG-AAC audio stream, a dts audio stream, or a WMA (Windows (TM) media audio) audio stream. (G) The movie work described in the embodiment may be 25 obtained by encoding an analog video signal broadcast by analog broadcasting. Also, the movie work may be stream 3338676_1 (GHMatters) P62611 AU.2 18/05/12 - 69 data constituted by a transport stream broadcast by digital broadcasting. Alternatively, an analog/digital video signal recorded on a videotape may be encoded to obtain content. Also, an analog/digital video signal 5 directly captured by a video camera may be encoded to obtain content. A digital work distributed by a distribution server is applicable too. (H) The BD-J module 29b may be a Java (TM) platform that is embedded in an apparatus for receiving satellite 10 broadcasts. When the BD-J module 29b is such a Java (TM) platform, the playback apparatus according to the present invention also performs processes as an STB for MHP. Further, the BD-J module 29b may be a Java (TM) platform that is embedded in an apparatus for performing process is control of a mobile phone. When the BD-J module 29b is such a Java (TM) platform, the playback apparatus according to the present invention also performs processes as a mobile phone. (I) In a layer model, the HDMV mode may be positioned 20 on the BD-J mode. Especially the analysis of the dynamic scenario in the HDMV mode and the execution of the control procedure based on the dynamic scenario put light load on the playback apparatus. Accordingly, there is no problem in executing the HDMV mode on the BD-J mode. Also, in the 25 development of a playback apparatus or a movie work, operations can be guaranteed by only one mode. 3338676_1 (GHMatters) P62611.AU.2 18/05/12 - 70 Further, the playback process may be executed only in the BD-J mode. This is because playback controls can be performed in sync with playback of a PL in the BD-J mode, and therefore the HDMV mode may be omitted. 5 (J) An AVClip downloaded onto the Local Storage 18 may be bonus video or an interview of a producer or an actor. (K) The embodiment describes the case where an application calls the getMissingStream method to check 10 whether a Clip is a Missing Stream or Rewritable. Instead, java (TM) libraries such as java (TM).net and java (TM).io may be used. In such a case, it is practical to use the following methods a), b), and c). 15 a) Analyze the contents of a Binding Unit Manifest File (stream location storage information) using XML Parser. (Example of the Binding Unit Manifest File) 20 <Progressive> <ProgressiveAsset VPFilename = "BDMV/STREAM/01000 .m2ts"> ~ identifier <BUDAFile name = "2/1/streams/o.m2ts"></BUDAFile> file path 25 </ProgressiveAsset> <ProgressiveAsset VPFilename = "BDMV/STREAM/0l001.m2ts"> 33386761 (GHMatters) P62611.AU.2 18/05/12 - 71 <BUDAFile name = "/l//streams/1.m2ts"></BUDAFile> </ProgressiveAsset> <ProgressiveAsset VPFilename = "BDMV/STREAM/01002.m2ts"> <BUDAFile name = "1/1/streams/2.m2ts"></BUDAFile> 5 </ProgressiveAsset> </Progressive> Note that "BUDA" is an abbreviation of a Binding Unit Data Area which is an area in a Local Storage for storing files used for a Virtual Package. 10 b) Check whether xxxxx.m2ts exists in a file path (stream storage location) described in a Binding Unit Manifest File using java (TM) .io. 1s (Example) new java (TM).io.File("1/l/streams/o.m2ts").exists() ; //Missing Stream when false c) Check whether a size of a file on a server matches 20 a size of a file on a Local Storage using java (TM) .net, java (TM) .io, to judge completion of download. (Example) 2S new java (TM).net.URL(http://xxx.com/vpdata/ o .m2ts) .openConnection () .getContentLength () ==new java (TM) .io.File("I/1/stream/O.m2ts") .lebgth(); 33386761 (GHMatters) P62611.AU.2 16/05/12 - 72 // download can be judged as complete when match Industrial Applicability The playback apparatus according to the present s invention may be used personally as in a home theatre system. However, the playback apparatus according to the present invention may also be used industrially since the internal structure thereof is disclosed in the above embodiment and it is apparent that the playback apparatus 10 according to the present invention will be manufactured in volume. For this reason, the playback apparatus according to the present invention has industrial applicability. Modifications within the scope of the invention may be readily effected by those skilled in the art. It is to 15 be understood, therefore, that this invention is not limited to the particular embodiments described by way of example hereinabove. In the claims that follow and in the preceding description of the invention, except where the context 20 requires otherwise owing to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, that is, to specify the presence of the stated features but not to preclude the presence or addition of further 25 features in various embodiments of the invention. Further, any reference herein to prior art is not intended to imply that such prior art forms or formed a part of the common general knowledge in Australia or any other country. 33386761 (GHMatters) P62611.AU.2 18/05/12

Claims (17)

1. A playback method, comprising: setting, among a plurality of digital streams, a s first digital stream to a first status in which playback access is disabled, the first digital stream having a first writable recording medium as a recording destination but not yet having been recorded into the first writable recording medium; io accessing and playing back a second digital stream among the plurality of digital streams that has already been recorded in a second recording medium; executing an application; downloading the first digital stream to the first is writable recording medium during the playing back of the second digital stream; setting, in response to a call from the application being executed, the downloaded first digital stream to a second status in which playback access is enabled, and 20 setting the downloaded first digital stream to a read-only attribute; and accessing and playing back the downloaded first digital stream set to the read only attribute and to the second status, in which playback access is enabled. 25

2. A playback method as claimed in claim 1, wherein after playback of the first digital stream set to the read only attribute and to the second status, in which playback access is enabled, is completed, in response to a 4464933_1 (GHMatters) P62611 .AU.2 2/07/13 - 74 call from the application being executed, the setting cancels the read-only attribute of the first digital stream, and the playback method further comprising: s deleting the first digital stream set to the first status.

3. A playback method as claimed in either claim 1 or 2, further comprising: 10 notifying, after the playback of the first digital stream set to the second status, in which playback access is enabled, and the read-only attribute is completed, the application of completion of the playback. 15

4. A playback method as claimed in any one of claims 1 to 3, further comprising: returning, in response to a call from the application being executed, information to the application, the information relating to the first digital stream set to 20 the first status.

5. A playback apparatus, comprising: a manager that sets, among a plurality of digital streams, a first digital stream to a first status in which 25 playback access is disabled, the first digital stream having a first writable recording medium as a recording destination but not yet having been recorded into the first writable recording medium; a player that accesses and plays back a second 4464933_1 (GHMatters) P62611 AU.2 2/07/13 - 75 digital stream among the plurality of digital streams, that has already been recorded in a second recording medium; an application executer that executes an application; 5 and a downloader that downloads the first digital stream to the first writable recording medium during the playing back of the second digital stream; wherein the manager sets, in response to a call from io the application being executed, the downloaded first digital stream to a second status in which playback access is enabled, and sets the first downloaded digital stream to a read-only attribute, and the player accesses and plays back the first 15 downloaded digital stream set to the read only attribute and to the second status, in which playback access is enabled.

6. A program for use in a computer for executing a 20 playback method, the program causing the computer to perform: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a 25 first writable recording medium as a recording destination but not yet having been recorded into the first writable recording medium; accessing and playing back a second digital stream, among the plurality of digital streams, that has already 4464933_1 (GHMatters) P62611.AU.2 2107113 - 76 been recorded in a second recording medium; executing an application; downloading the first digital stream to the first writable recording medium during the playing back of the 5 second digital stream; setting, in response to a call from the application being executed, the downloaded first digital stream to a second status in which playback access is enabled, and setting the first digital stream to a read-only attribute; 10 and accessing and playing back the first digital stream set to the read only attribute and to the second status, in which playback access is enabled. is

7. A playback method, comprising: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a first writable recording medium as a recording destination 20 but not yet having been recorded into the first writable recording medium; setting, among the plurality of digital streams, a second digital stream to a second status in which playback access is enabled, the second digital stream having the 25 first writable recording medium as a recording destination and having already been recorded into the first writable recording medium, and setting the second digital stream to a read-only attribute; accessing and playing back the second digital stream; 4464933_1 (GHMatters) P62611.AU.2 2/07/13 - 77 executing an application; downloading the first digital stream to the first writable recording medium during playback of the second digital stream; s setting, in response to a call from the application being executed, the downloaded first digital stream to the second status, and setting the downloaded first digital stream to a read-only attribute; and accessing and playing back the downloaded first io digital stream set to the read only attribute and to the second status, in which playback access is enabled.

8. A playback method as claimed in claim 7, wherein a digital stream, which has already been recorded in a is second recording medium, is further accessed and played back in the accessing and the playing back.

9. A playback apparatus, comprising: a manager that sets, among a plurality of digital 20 streams, a first digital stream and a second digital stream to a first status in which playback access is disabled and a second status in which playback access is enabled, respectively, the first digital stream having a first writable recording medium as a recording destination 25 but not yet having been recorded into the first writable recording medium, the second digital stream having a first writable recording medium as a recording destination and having already been recorded into the first writable recording medium, and set an attribute of the second 4464933_1 (GHMatters) P62611.AU.2 2/07/13 - 78 digital stream to a read-only attribute; a player that accesses and plays back the second digital stream; an application executer that executes an application; s and a downloader that downloads the first digital stream to the first writable recording medium during playback of the second digital stream; wherein the manager sets, in response to a call from 10 the application being executed, the downloaded first digital stream to the second status, and sets the downloaded first digital stream to a read-only attribute; and the player accesses and plays back the downloaded 15 first digital stream set to the read only attribute and to the second status, in which playback access is enabled.

10. A playback apparatus as claimed in claim 9, wherein the player further accesses and plays back a digital 20 stream that has already been recorded in a second recording medium.

11. A playback program for use in a computer for executing a playback method, the program causing the 25 computer to perform: setting, among a plurality of digital streams, a first digital stream to a first status in which playback access is disabled, the first digital stream having a first writable recording medium as a recording destination 4464933_1 (GHMatters) P62611.AU 2 2/07/13 - 79 but not yet having been recorded into the first writable recording medium; setting, among the plurality of digital streams, a second digital stream to a second status in which playback s access is enabled, the second digital stream having the first writable recording medium as a recording destination and having already been recorded into the first writable recording medium, and setting the second digital stream to a read-only attribute; io accessing and playing back the second digital stream; executing an application; downloading the first digital stream to the first writable recording medium during playback of the second digital stream; 15 setting, in response to a call from the application being executed, the downloaded first digital stream to the second status, and setting the downloaded first digital stream to a read-only attribute; and accessing and playing back the downloaded first 20 digital stream set to the read only attribute and to the second status, in which playback access is enabled.

12. A playback program as claimed in claim 11, wherein a digital stream, which has already been recorded in a 25 second recording medium, is further accessed and played back in the accessing and the playing back.

13. A computer readable recording medium, comprising a program as claimed in claim 6. 4464933_1 (GHMatters) P62611 .AU.2 2/07/13 - 80

14. A computer readable recording medium, comprising a playback program as claimed in either claim 11 or 12. 5

15. A playback apparatus substantially as herein described with reference to the accompanying drawings.

16. A playback method substantially as herein described with reference to the accompanying drawings. 10

17. A playback program for use in a computer substantially as herein described with reference to the accompanying drawings. 44649331 (GHMatters) P62611 AU.2 2/07/13