CN101640059A - Playback apparatus for performing application-synchronized playback - Google Patents

Abstract

A playback device for playing a digital stream in combination with an application program includes a package management unit for generating package information by merging files recorded on a first recording medium and a second recording medium according to the merging management information, and a selection unit, Used to detect a plurality of playable titles from package information, and select one of the detected titles as the current title. After the application program requests the package management unit to update the merge management information by specifying the new merge management information, before updating the package information, the package management unit will make the file referenced from the newly specified merge management information read-only, and the playback of the digital stream due to the selection When the current title selected by the unit changes and stops, the package management unit generates new package information by combining files recorded on the first and second recording media according to newly designated merge management information.

Description

Playback device for performing application-synchronized playback

This application is a divisional application filed on July 21, 2005 with application number 200580024823.7 and titled "Playback Apparatus for Executing Synchronous Playback of Application Programs".

technical field

The invention belongs to the technical field of synchronous playback of digital streams and application programs.

Background technique

Application-synchronized playback is a technology for playing a digital stream while running a Java(registered trademark) application in a playback device or the like for playing video, and belongs to consumer products that will attract a large number of products manufactured in the future. Technical areas of concern. Applications and digital streams for synchronization are associated with each other in playback units called "titles". A conventional playback device is described below. A conventional playback device is composed of a virtual file system unit, a module manager, a playback unit, and a platform unit.

The virtual file system unit manages a plurality of recording media accessed by a playback device, such as optical recording media (such as DVD-ROM, BD-ROM, the latter will be described later as an example) and magnetic recording media (such as hard disks), and generates a whole The package information of the content recorded on these recording media is displayed accurately.

Each piece of package information is called a virtual package, which is submitted in playback/execution of streams and applications (hereinafter simply referred to as "applications") recorded on these recording media as if they were actually recorded in a single in the bag.

The module manager selects one of the titles as the current title.

The playback unit plays the digital stream constituting the current title (ie recorded on the optical or magnetic recording medium) from the digital stream indicated by the package information.

The platform unit executes the application program constituting the current title (ie, recorded on an optical or magnetic recording medium) from among the application programs indicated by the package information.

According to the above structure, digital streams and application programs recorded on different recording media such as BD-ROM and hard disk can be treated as a single (virtual) package, and the playback apparatus can realize playback control in units of titles.

Titles in the above structure are used not only for the digital stream recorded on the BD-ROM for playback but also for the digital stream recorded on the hard disk. Since a hard disk is a rewritable recording medium, constituent elements of a title may be partially replaced by playback, for example, when package information is newly generated using a newly captured digital stream.

It is largely considered that such a replacement causes a situation where it is difficult to recover, for example, a video interruption generated by an abnormal operation of a playback unit during playback.

If the playback unit in the playback device sequentially checks, for example, the data stream for playback and the consistency of elements of playback control information, it can be expected to partially replace the playback object by playback. However, assuming that the types of information to be checked are different, this imposes a large burden on the playback unit.

In order to absolutely guarantee stable operation of the device, it is ideal to restart the device itself when there is a change in the recorded content on the hard disk, like when you install software. However, assuming that rebooting a device anywhere takes seconds to minutes of processing time, this is not something users can easily afford.

Contents of the invention

An object of the present invention is to provide a playback device capable of stable playback even when there is a change in a playback object.

In order to solve the above problems, the present invention is a playback device for playing a digital stream combined with an application program, which includes a package management unit for combining files recorded on the first recording medium and the second recording medium according to the combination management information. The package management unit generates package information, and the selection unit detects a plurality of playable titles from the package information, and selects one of the detected titles as a current title. After the application program requests the package management unit to update the merge management information by specifying the new merge management information, the package management unit will make the file referenced from the newly specified merge management information read-only before updating the package information, and the playback of the digital stream due to the current title When stopped by the selection unit change, the package management unit generates new package information by combining files recorded on the first and second recording media according to newly designated merge management information.

With the above structure, the present invention guarantees that in the case where an application program requests the package management unit to update the merge management information by designating new merge management information, the content of the file referenced from the newly designated merge management information will None of the changes were changed because the package management unit made the files referenced from the newly specified merge management information read-only before updating the package information. Also, by updating the package information when digital stream playback is stopped due to current title change, abnormal operation of the playback apparatus will not be caused even if, for example, a digital stream for playback/execution or an application program is replaced due to updating.

Thus, since playback control can be realized by dynamically combining files recorded on both the first and second recording media while ensuring stable operation of the playback device, the expressive breadth of a movie production is expanded.

Here, the package management unit may be configured to update the package information if the information in the permission tag (tag) of the application program requesting the update indicates that the application program has been allocated the right to update the package information, and if the information indicates that the update package information has not been allocated rights, the update request is rejected and exception handling is performed.

This structure can prevent update of package information requested by unauthorized applications.

Description of drawings

Fig. 1 is a system diagram;

Figure 2 shows the internal structure of the BD-ROM 100;

Figure 3 systematically shows how to construct a file with the extension "m2ts";

Figure 4 shows the structure of PL information;

Figure 5 shows the relationship between AVClip and PL;

Figure 6 shows batch specification using four Clip_Information_file_names;

Figure 7 shows the internal structure of PLMark information;

Figure 8 shows the chapter definition using PLMarks;

Figure 9 shows the internal structure of Subpath information;

Figure 10 shows the synchronization specification and playback interval definition on the SubClip time axis;

Figure 11A shows the program data contained in the archive file;

Figure 11B shows the internal structure of the class file;

Figure 12 shows the internal structure of the BD-J object;

Figure 13 shows the internal structure of INDEX.BDMV;

Figure 14 shows the directory structure in the local storage;

Fig. 15 has shown the type of playlist playback time axis defined by the PL information stored in the local memory;

Figure 16A shows an AVClip stored on a BD-ROM and a Java application and an AVClip stored in a local storage;

Figure 16B shows a Java application and AVClip #1-#4 treated as a single title;

Figure 17 shows a typical internal structure of a merge management information file;

Fig. 18 shows the hardware configuration of the playback device;

Fig. 19 depicts elements rearranged in a layered structure consisting of hardware and software stored on the instruction ROM 21;

Fig. 20 has shown the internal structure of Java virtual machine 30;

Figure 21 shows the state transitions produced by title changes;

Fig. 22 has shown the virtual package information that is typically generated by the virtual file system unit 38;

Figure 23A shows the time axis of the entire disc;

Figure 23B shows the structure of the time axis of the entire disc;

Fig. 24 is a flowchart of download processing performed by a Java application;

Figure 25 is a flowchart of the update "prepare" process;

Fig. 26 is a flowchart of the virtual package "update" process;

Figure 27 is a flowchart of the processing performed by the module manager;

Figure 28 is a flowchart of the PL playback process;

Figure 29 shows how virtual package information is updated during a title change;

Figure 30 shows the Java application that sends the current merged management information file to the server;

Figure 31 shows the Java application for downloading content files, new merged management information files and new signature information files;

Figure 32 has shown the Java application program that makes update request to virtual file system unit 38;

Figure 33 shows the replacement of merge management and signature information files, and the mapping of content files;

34A is a flowchart of the processing performed by the playback control engine when the playback of the current title is suspended after a title call;

34B is a flowchart of processing performed by the playback control engine when playback of the original title continues after playback of the called title ends;

Fig. 35 shows the merge management information file in Embodiment 3;

Fig. 36 has shown the Java application program about embodiment 3, and this application program requests to update the virtual package;

Figure 37 shows a typical additional content list displayed to a user by a resident application using a merged management information file;

FIG. 38 is a flowchart of the flow of processing from loading of a BD-ROM to playback according to Embodiment 3;

Figure 39 shows the valid intervals specified when a virtual package update is requested;

40 is a flowchart of the processing flow from loading of BD-ROM (or restart of playback device) to playback in Embodiment 4;

Figure 41 shows a license request file for screening virtual package update requests;

Figure 42 shows the access restrictions imposed on directories in local storage for merging;

Figure 43 shows a Java application whose lifecycle is restricted to a single title and a Java application whose lifecycle lasts multiple titles;

Figure 44 shows the processing performed on a title-unbound application when a virtual package is updated during a title change;

FIG. 45 is a flow chart of title change processing for applications considering unbound titles; and

Fig. 46 is a flowchart of virtual package update after INDEX.BDMV file change.

Detailed ways

Example 1

Embodiments of recording media related to the present invention are described below. First, one usage form among the implementation forms of the playback apparatus related to the present invention will be described. Fig. 1 shows a typical usage form of the playback device related to the present invention. In FIG. 1 , a playback device related to the present invention is a playback device 200 . The playback device 200 is used to provide movie works in a home theater system composed of, for example, the playback device 200 , a remote controller 300 , and a television 400 .

Typical forms of use of the playback apparatus of the present invention are as described above. Next, a recording medium for playback by the playback apparatus pertaining to the present invention will be described. In the given example, the recording medium played back by the playback apparatus pertaining to the present invention is the BD-ROM 100 (optical recording medium). Figure 2 shows the internal structure of the BD-ROM 100.

The fourth level in FIG. 2 shows the BD-ROM 100, while the third level shows the tracks on the BD-ROM. The track depicted in Figure 2 results from a track spiral from the inner to the outer circumference of the BD-ROM, which has been drawn for the sides. The track consists of a lead-in area, a volume area and a lead-out area. The volume area in FIG. 2 has a layered structure consisting of a physical layer, a file system layer and an application layer. Expressing the application format of the BD-ROM using a directory structure gives the first level in FIG. 2 . The BDMV directory is placed under the root directory of the first level in the BD-ROM.

The INDEX.BDMV file is arranged in the BDMV directory, and there are five subdirectories under the BDMV directory, which are called PLAYLIST directory, CLIPINF directory, STREAM directory, BDJA directory, and BDBJ directory.

The STREAM directory stores files forming the main stream, to which the extension "m2ts" is assigned (00001.m2ts).

A file (00001.mpls) with the extension "mpls" exists in the PLAYLIST directory.

A file (00001.clpi) with the extension "clpi" exists in the CLIPINF directory.

A file (00001.jar) with the extension "jar" exists in the BDJA directory.

A file (00001.bdbj) with the extension "bdbj" exists in the BDBJ directory.

These files are described next.

AVClips

First, a file (00001.m2ts) with an extension "m2ts" is described. Figure 3 systematically shows how to construct a file with the extension "m2ts". This file stores the AVClip. AVClip (middle level) is formed by multiplexing TS packets, and the video stream composed of multiple video frames (picture pj1, pj2, pj3) and the audio stream composed of multiple audio frames (first level above) are first converted into PES packets (the second level above), and then converted into TS packets (the third level above), and display subtitle graphics (P graphics or PG) streams (first level below) and dialog interactive graphics (I Graphics or IG) streams (first level below) are converted into TS packets (third level below) to generate the TS packets.

In addition to AVClips obtained by multiplexing as shown in FIG. 3, there are also AVClips not produced by multiplexing. These are called SubClips, and include AVClips constituting an audio stream, a graphics stream, or a text subtitle stream (TextST stream), or the like.

clip information

A file (00001.clpi) with an extension of "clpi" is a piece of clip information corresponding to an AVClip. Clip information is management information that contains EP_map showing the head position of a GOP, and information such as the encoding format, frame rate, bit rate, and resolution of a stream in an AVClip.

PL information

A file (00001.mpls) with an extension of "mpls" stores Play List (PL) information. PL information defines a PlayList by referring to an AVClip. Figure 4 shows the structure of PL information. As shown on the left side of the figure, PL information consists of MainPath information, PLMark information and SubPath information.

The MainPath information "MainPath( )" is composed of PlayItem information "PlayItem( )" indicated by the arrow mpl. PlayItems are playback intervals defined by specifying In_time and Out_time on one or more AVClip timelines. The placement definition of pieces of PlayItem information is a list consisting of a number of playback intervals. Arrow mp2 in Fig. 4 shows a close-up of the internal structure of the playitem information. As shown in FIG. 4, the PlayItem information is composed of In_time, Out_time, and Clip_Information_file_name showing the corresponding AVClip. Figure 5 shows the relationship between AVClip and PL. The first level shows the time axis of the AVClip, and the second level shows the time axis of the PL. The PL information includes three pieces of PlayItem information (PlayItem#1-#3), where three playback intervals are defined by In_times and Out_times of PlayItem#1, #2, and #3. A time axis different from AVClip is defined when these playback intervals are arranged in lines. This is the PL timeline shown at the second level. It is thus allowed to define a time axis other than AVClip by definition in PlayItem Information.

Usually, one AVClip is assigned at any one time, although batch assignment of multiple AVClips is also possible. Batch designation of AVClip is performed using Clip_Information_file_names in PlayItem Information. Figure 6 shows specifying an AVClip in batches using four Clip_Information_file_names. The first to fourth levels in the figure show four AVClip time axes (time axes AVClips#1-#4), while the fifth level shows the PL time axis. Four time axes are specified by these four Clip_Information_file_names included in the PlayItem information. This allows four alternative playable playback intervals defined by In_times and Out_times. As a result, intervals consisting of a plurality of switchable angle videos (so-called multi-angle intervals) are defined on the PL time axis.

PLMark information "PLMark()" specifies an arbitrary interval on the PL time axis as a chapter. Fig. 7 shows the internal structure of PLMark information, which includes ref_to_playitem_id and Mark_time_stamp indicated by arrow pm1. Figure 8 shows the chapter definition using PLMark. The first hierarchy in Fig. 8 shows the AVClip time axis, and the second hierarchy shows the PL time axis. Arrows pk1 and pk2 in FIG. 8 show designation of a play item (ref_to_playitem_id) and a time point (Mark_time_stamp) in PLMark. Due to these designations three chapters (Chapters#1-#3) are defined on the PL time axis. This completes the description of PLMark.

SubPath information is described next.

SubPath information "SubPath()" defines one or more playback intervals by specifying In_time and Out_time on the SubClip time axis, and has the internal structure shown in FIG. 9 . The SubPath information is composed of subplayitem information "SubPlayItem()" indicated by the arrow sh1. In the close-up marked by arrow sh2, the sub play item information is composed of Clip_Information_file_name, In_time, Out_time, Sync_PlayItem_Id, and Sync_Start_PTS_of_PlayItem. In_times and Out_times on the SubClip time axis are specified using Clip_Information_file_name, In_time and Out_time included in the SubPlayItem information. Sync_PlayItem_Id, and Sync_Start_PTS_of_PlayItem are used to synchronize playback intervals on the SubClip time axis and the PL time axis. This allows processing on the SubClip time axis and the PL time axis to be performed in synchronization with each other.

Fig. 10 shows synchronization designation and definition of playback intervals on the SubClip time axis. The first level in Fig. 10 shows the PL time axis, and the second level shows the SubClip time axis. SubPlayItem.In_time and SubPlayItem.Out_time in Fig. 10 show the start and end of the playback interval, respectively. It is thus obvious that the playback interval is also defined on the SubClip time axis. Sync_PlayItem_Id marked by an arrow Sn1 shows a synchronization indication of a PlayItem, and Sync_Start_PTS_of_PlayItem marked by an arrow Sn2 specifies a point during a PlayItem on the PL time axis.

A feature of PL information in a BD-ROM is that it makes it possible to define a multi-angle interval that allows switching of AVClips and a synchronization interval that allows AVClips and SubClips to be synchronized. Clip information and PL information are classified as "static scenario".

"Dynamic script" is described below. "Dynamic" here means that the content of the playback control changes due to user key events, state changes in the playback apparatus 200, and the like. With BD-ROM, playback control can be described using the same description as Java applications. That is, with a BD-ROM, a Java application acts as a dynamic script.

java application

The Java application is described below. A Java application program consists of one or more xlet programs loaded in the heap area (also called working memory) of the virtual machine. The application program is composed of an xlet program and data loaded in the work memory. The Java application structure is as described above.

The actual Java application is a Java archive file (00001.jar) stored in the BDJA directory under the BDMV directory in FIG. 2 . The Java archive file is described below with reference to FIG. 11 .

Java archive file

A Java archive file (00001.jar in Figure 2) is a collection of one or more class files and data files. Figure 11A shows the programs and data collected in the archive files. The data in FIG. 11A is a number of files collected by the Java Archive and arranged in the directory structure shown inside the boxes. The directory structure consists of a root directory, a Java directory, and an image directory, where common.pkg files, class files (aaa.class, bbb.class), and menu.jpg files are placed in their respective directories. A Java Archive file is the result of the Java Archive Storage gathering these files together. Class files and data are expanded when reading from a BD-ROM into the cache, and are treated as a plurality of files existing in a directory in the cache. The five-digit value "00001" in the file name of the Java archive shows the identifier (ID) of the Java archive, and the BD-J object uses this value to refer to the Java archive. By referring to this numerical value in the file name when reading a Java archive file into the cache, it is possible to extract data and programs constituting an arbitrary Java application.

The class files (aaa.class, bbb.class) in FIG. 11A correspond to the above xlet programs. The xlet programs (ie, instances) using these class files define playback procedures in the work mode (BD-J) supported by the Java platform. The xlet program is a Java program capable of using a Java Multimedia Framework (JMF) interface, and performs processing based on key events according to JMF or the like.

In addition, xlet programs can also perform the process of visiting websites and downloading content. This allows the replay of original productions created by mixing downloads and lists.

Next, the class file of the xlet program is described. Figure 11B shows the internal structure of the class file. As shown in FIG. 11B , this class file is similar to a normal class file and consists of a constant pool, an interface, and methods 1, 2, 3...n. The methods in the class file include those triggered by pre-documented key events (EventListener) and those used to call Application Programming Interface (API) functions in the playback apparatus 200 . Calculation procedures and the like in these methods are described by using local variables assigned to specified methods and arguments that appear when the methods are called. The Java archive files are described above.

Next, a file with the extension "bdbj" is described. This file (00001.bdbj) stores BD-J objects. The BD-J object is information that defines a title by associating an AVClip defined in PL information with an application. Figure 12 shows the internal structure of a BD-J object. BD-J object shows application management table and PL information reference value. The application management table shows Java applications whose life cycle is defined by the BD-J object by enumerating the IDs of individual Java applications (Application IDs) and the IDs of Java archive files belonging to a particular application title. In other words, each application consists of one or more Java archives.

The PL information reference value shows PL information to be displayed when starting a title.

Files with the extension "bdbj" are as described above.

Next, the INDEX.BDMV file is described.

INDEX.BDMV is management information related to the entire BD-ROM. This file contains information such as an organization ID identifying a supplier of a movie work and a disc ID assigned to an individual BD-ROM provided by the supplier. When the disc is loaded, first the disc is uniquely identified in the playback device by reading INDEX.BDMV. INDEX.BDMV may additionally include a table that maps multiple playable titles in a BD-ROM to a BD-J object defining a single title. The following describes the types of titles recordable to the BD-ROM, the types including FirstPlayTitle, Top_menuTitle, and titles #1-#3.

FirstPlayTitle is responsible for playing the BD-ROM's dynamic title before doing anything else when the BD-ROM is loaded. FirstPlayTitle thus enables playback of a dynamic logo representing the creator and/or distributor of a cinematic work when a BD-ROM is loaded.

Top_menuTitle consists of an AVClip and an application that plays the topmost menu of the menu hierarchy in the BD-ROM.

Titles #1, #2, and #3 correspond to ordinary movie works.

In other words, INDEX.BDMV shows the correspondence of FirstPlayTitle, Top_menuTitle, and Titles #1-#3 to a single BD-J object.

Figure 13 shows the internal structure of INDEX.BDMV. This file shows the correspondence of FirstPlayTitle information, Top_menuTitle information, Title #1 information, Title #2 information, and Title #3 information with Title IDs and BD-J objects defining these titles. BD-J objects defining titles can be identified using title information, and PL information and applications for synchronization can be derived from these BD-J objects. This completes the description of the BD-ROM.

BD-ROM is not the only recording medium used by the playback device related to the present invention.

A hard disk (local storage) integrated with the playback device is also used during playback. The data recorded in the local storage is described below.

Figure 14 shows the directory structure in local storage. In this directory structure, a subdirectory "organization#1" is located under the root directory, and there are subdirectories "disc#1" and "disc#2" under this directory. The organization#1 directory is assigned to a specific supplier of a film production. The disc#1 and disc#2 directories are allocated to different BD-ROMs provided by each supplier. The organization ID and disc ID shown in the INDEX.BDMV file in each BD-ROM are used for these directory names.

Providing a directory corresponding to BD-ROMs in a directory corresponding to a specific provider allows download data related to individual BD-ROMs to be stored independently. PL information, clip information, and AVClip are stored under these subdirectories, similar to those stored on a BD-ROM. A Java archive file, a BD-J object, a merge management information file, and a signature information file also exist additionally.

Compared with the PL information on the BD-ROM that only relates to the AVClip on the BD-ROM, the PL information in the local storage includes information related to the AVClip on the BD-ROM and in the local storage; The specific example of the added PL information is PL INFO#2 in FIG. 14 .

Here, the PL information (playitem information #1-#4) in the local storage is constituted by four pieces of playitem information. In the case where the headline (play item information #1) refers to the clip information on the BD-ROM and the remaining three (play item information #2-#4) refer to the clip information in the local storage, the PL information can be retrieved from the BD-ROM. AVClips in and in local storage define a single stream sequence, as shown in FIG. 15 .

Fig. 15 shows the types of playlist playback time axis defined by PL information stored in the local storage. The first level shows the playback time axis of AVClip#1 stored on the BD-ROM, while the second level shows the playback time axis of the PlayList defined in the PL information stored in the local storage, the third, the fourth and fifth levels respectively display playback timelines of AVClips #2, #3, and #4 stored in the local storage.

In the case where PlayItem information #2, #3, and #4 specify AVClip #2, #3, and #4 as playback intervals, the PL information in the local storage can define AVClips on the BD-ROM and in the local storage. for a single data stream sequence.

As described above, an AVClip on a BD-ROM and in local storage can be defined as a single stream sequence, and by combining this stream sequence with an application on a BD-ROM or in local storage, an AVClip and a The application programs recorded on the BD-ROM or in the local storage constitute a single title. As shown in FIG. 16A, in the case where AVClip#1 is recorded on the BD-ROM and AVClip#2-#4 and Java applications are recorded in local storage, these AVClips and Java applications can be recorded as shown in FIG. 16B Treated as a single title.

Next, the merge management information will be described. The merge management information uniquely shows all the files constituting the virtual package in the disc#1 and #2 directories in the local storage, and is stored in a specified file (hereinafter referred to as "merge management information file"). Fig. 17 shows a typical internal structure of a merge management information file. The merge management information file is composed of storage location information of each file constituting the virtual package in the local storage. The storage location information is composed of an identifier for accessing each file as a virtual package and a file path indicating a storage location of each file in the local storage.

Next, the signature information file is described. The signature information file displays the supplier's electronic signature on the consolidated management information file. A commonly used electronic signature is obtained by calculating a hash value of information to be tamper-proof and encrypting the hash value with some kind of secret key.

This completes the description of local storage.

Embodiments related to the playback apparatus of the present invention are described below. Fig. 18 shows the hardware configuration of the playback device. Playback transpose by BD-ROM drive 1, read buffer 2, demultiplexer (Demux) 3, video decoder 4, video plane 5, graphics display (P-graphics) decoder 6, graphics display (P-graphics) plane 7, composition unit 8, font generator 9, interactive graphics (I-graphics) decoder 10, switch 11, interactive graphics (I-graphics) plane 12, composition unit 13, color look-up table (CLUT) unit 14, color look-up table (CLUT) unit 15, audio decoder 16, network equipment 17, local memory 18, read buffer 19, demultiplexer (Demux) 20, instruction ROM 21, user event (UE) processing unit 22, player status register (PSR) group 23 , central processing unit (CPU) 24 , script memory 25 , local memory 26 , and switch 27 .

First, elements related to playback of AVClip recorded on the BD-ROM 100 (BD-ROM drive 1-audio decoder 16) will be described.

The BD-ROM drive 1 loads/ejects BD-ROMs, and accesses the BD-ROM 100.

The read buffer 2 is a first-in-first-out (FIFO) memory in which Transport Stream (TS) packets read from the BD-ROM 100 or the local storage 18 are stored on a first-in-first-out basis.

Demux 3 reads TS packets from read buffer 2, and converts these TS packets into Packetized Elementary Stream (PES) packets. The PES packets with the packet identifier (PID) set by the CPU 24 are then output to one of the video decoder 4, P graphics decoder 6, I graphics decoder 10, and audio decoder 16.

Video decoder 4 decodes PES packets output from Demux 3 to obtain pictures in uncompressed format, and writes these pictures into video plane 5 .

Video plane 5 is used to store uncompressed pictures. A plane is a storage area in a playback device for storing pixel data for one screen. The video plane 5 has a resolution of 1920×1080, and picture data stored therein is composed of pixel data expressed in 16-bit YUV. In Video Plane 5, the playback video in each frame of the video stream can be scaled. Scaling involves changing each frame of the playback video to 1/4 (quarter) or 1/1 (full scale) of the entire video plane 5 . Scaling is performed in accordance with an instruction from the CPU 24 in the BD-J mode, thereby allowing screen generation whereby the playback image of the video stream is shifted to a corner of the screen or projected onto the entire screen.

The P-graphics decoder 6 decodes the P-graphics stream read from the BD-ROM, and writes uncompressed graphics into the P-graphics plane 7 . Subtitles appear on the screen as the graphics stream is decoded.

The P-graphics plane 7 is a memory with storage space for one screen of data capable of storing one screen of uncompressed graphics. This plane has a resolution of 1920×1080, where pixels of uncompressed graphics in P-graphics plane 7 are expressed by 8-bit indexed colors. Uncompressed graphics stored in the P-graphics plane 7 are submitted for display by converting indexed colors using the CLUT.

The compositing unit 8 composites the uncompressed picture data stored in the video plane 5 and the storage content of the P graphics plane 7 .

The font generator 9 expands the text code included in the TextST stream in the bitmap using a character font, and writes the expanded code into the P graphics plane 7 .

The I-graphics decoder 10 decodes an I-graphics stream read from a BD-ROM or a local storage 18 in DVD-like mode, and writes uncompressed graphics into an I-graphics plane 12 .

The switch 11 selectively writes one of the font sequence generated by the font generator 9 and the graphics decoded by the P graphics decoder 6 into the P graphics plane 7 .

The I-graphics plane 12 is written with uncompressed graphics resulting from decoding by the I-graphics decoder 10 . Characters and graphics drawn by an application program are written in the I graphics plane 12 in BD-J mode using αRGB full color.

The compositing unit 13 composites the storage content of the I graphics plane 12 and the composite image output from the compositing unit 8 (ie, composites uncompressed picture data and the storage content of the P graphics plane 7). This compositing allows characters and graphics written to the I graphics decoder 10 by an application program to be superimposed on the uncompressed picture data and displayed.

The CLUT unit 14 converts indexed colors in uncompressed graphics stored in the video plane 5 into Y/Cr/Cb.

CLUT unit 15 converts indexed colors in uncompressed graphics stored in I graphics plane 15 to Y/Cr/Cb . When operating in BD-J mode (ie, a mode for playing digital streams in synchronization with Java applications), the CLUT unit 15 converts αRGB full color into Y/Cr/Cb. Note that a Java application can be bound or not bound to a title, and bound or not bound to a disc.

The audio decoder 16 decodes the PES packets output from the Demux3 and outputs uncompressed audio data.

The elements related to AVClip playback are as described above. The following describes elements (network device 17 - Demux 20 ) operating in BD-J mode.

The network device 17 realizes the communication function in the playback device. In the case where the application specifies a URL in the BD-J mode, the network device 17 establishes a Transmission Control Protocol (TCP) or File Transfer Protocol (FTP) connection or the like to the website indicated by the URL. Since the connection is established the Java application is downloaded from the website.

The local storage 18 is a hard disk for storing content downloaded from a website through a connection established by the network device 17, content provided from communication and recording media other than the BD-ROM, and metadata. Metadata is information for binding and managing downloaded content in the local storage 18 . By accessing the local storage 18, applications in the BD-J mode can perform many processes using the downloaded content. The local storage 18 also stores merge management information files.

The read buffer 19 is a FIFO memory that stores TS packets constituting the SubClip on a first-in-first-in basis when the SubClip is included in downloaded content stored on the BD-ROM 100 or in the local storage 18 .

The Demux 20 reads TS packets from the read buffer 19, and converts the read TS packets into PES packets. The PES packets with a specific PID are then output to the P graphics decoder 6, the font generator 9, and the audio decoder 16.

The above elements 17-20 allow content downloaded by a Java application over the network to be played in a manner similar to content recorded on a BD-ROM. Elements (command ROM 21 - switch 27) for realizing centralized control in the playback apparatus are described below.

The instruction ROM 21 stores software that defines controls related to the playback device.

In response to key operations of the remote controller of the playback device or the front panel, the UE processing unit 22 outputs user events for performing these operations to the CPU 24 .

The PSR group 23 is a group of registers inside the playback device, consisting of 64 player status registers (PSR) and 4096 general purpose registers (GPR). PSR4-8 are used to indicate the current playback point.

PSR 4 indicates the title of the current playback point by being set to a value of 1-100. Setting PSR 4 to "0" means that the current playback point is the top menu.

PSR 5 indicates the chapter number of the current playback point as it is set to a value of 1-999. Setting PSR 5 to "0xFFFF" indicates that the chapter number in the playback device is zero.

The PSR 6 indicates the number of the PL (current PL) to which the current playback point belongs as a value set to 0-999.

PSR 7 indicates the number of the PlayItem (current PlayItem) to which the current playback point belongs due to being set to a value of 0-255.

The PSR 8 indicates the current playback point (current display time or "PTM") using a time precision of 45KHz by virtue of being set to a value of 0-0xFFFFFFFF. PSR 4-8 allows the current playback point to be identified on the time axis of the entire BD-ROM shown in FIG. 23A.

The CPU 24 runs software stored in the instruction ROM 21 to perform control related to the entire playback device. These controls change dynamically depending on user events output from the UE processing unit 22 and the PSR values in the PSR group 23 .

The script memory 25 is used to store current PL information and current clip information. The current PL information is a currently processed piece of PL information recorded on the BD-ROM. The current clip information is a currently processed piece of clip information recorded on the BD-ROM.

Assuming low-speed reading from the BD-ROM, the local storage 26 is a cache memory that temporarily stores the recorded content of the BD-ROM. The provision of local storage 26 allows applications in BD-J mode to run efficiently.

The switch 27 selectively supplies data read from the BD-ROM and the local storage 18 to one of the read buffer 2 , the read buffer 19 , the script memory 25 and the local storage 26 .

The hardware configuration regarding the playback apparatus of this embodiment is as described above. The software structure in the playback apparatus related to the present embodiment will be described below.

FIG. 19 depicts elements rearranged in a layered structure consisting of hardware and software stored on the instruction ROM 21. As shown in FIG. 19, the layered structure of the playback device is composed of a first layer (BD layer), a second layer (BD player model), and a third layer (application runtime environment).

The hardware configuration of the playback device shown in FIG. 18 belongs to the first layer. In this hardware configuration, the "BD player" of the first layer in FIG. A "plane" consisting of Video Plane 5, P Graphics Plane 7 and I Graphics Plane 12, BD-ROM 100 and associated file system, local storage 18 and associated file system, and network device 17.

The "BD player model" at the second layer is composed of a lower layer for the display engine 31 and virtual file system unit 38 and an upper layer for the playback control engine 32, and provides API functions related to higher levels.

The PSR group 23 and the script memory 25 shown in FIG. 18 exist inside the playback control engine 32 .

The "application runtime environment" at the third layer is composed of a layer including a module manager 33 stacked on a layer including a DVD-like module 29a and a Java platform 29b.

The elements in this software structure are described below.

DVD-like module 29a, Java platform 29b

The DVD-like module 29a decodes the navigation command, and executes function calls related to the playback control engine 32 based on the decoded result.

The Java platform 29b is a so-called Java platform having a hierarchical structure composed of a Java virtual machine 30 and middleware (not shown) run by the Java virtual machine.

Java virtual machine 30

The Java virtual machine 30 loads the xlet program constituting the application program into the work memory, decodes the xlet program, and executes control on the lower layer according to the decoding result. In order to execute these controls, the Java virtual machine 30 issues a method to the middleware, causes the middleware to replace the method with a function call corresponding to the BD playback device, and issues the function call to the playback control engine 32 .

Internal Structure of Java Virtual Machine 30

The internal structure of the Java virtual machine 30 is described below. FIG. 20 shows the internal structure of the Java virtual machine 30. As shown in Figure 20, Java virtual machine 30 is made of CPU 24, user class loader 52, method area 53, work memory 54, thread 55a, 55b, ... 55n, and Java stack 56a, 56b, ... 56n.

The user class loader 52 reads class files in the Java archive files in the BDJA directory from the local storage 26 or the like, and stores the read class files in the method area 53 . The class file is read by the user class loader 52 because the module manager 33 sends a read command specifying the file path to the user class loader 52 to be executed. If the file path indicates the local storage 26, the user class loader 52 reads the class files in the Java archive making up the application from the local storage 26 into the working storage 54. If the file path indicates a directory in the file system, the user class loader 52 reads the class files in the Java archive making up the application from the BD-ROM or the local storage 18 into the work memory 54 .

The method area 53 stores class files read from the local storage 26 by the user class loader 52 .

The work memory 54 is a so-called accumulation area that stores instances of various types of files. The work memory 54 stores instances corresponding to resident application programs and class files read into the method area 53 . One example is an xlet program constituting an application program that is made executable by placing the xlet program in the work memory 54 .

Threads 55 a , 55 b , . . . 55 n are logical execution entities for executing methods stored in working memory 54 . They perform calculations using local variables and arguments stored as operands in the operand stack, and store calculation results in local variables or the operand stack. Arrows ky1, ky2, and kyn in FIG. 20 symbolically indicate that methods are provided from working memory 54 to threads 55a, 55b, . . . 55n. Although the CPU is the only physical execution entity, there can be up to 64 logical execution entities or threads in the Java virtual machine 30 . Threads can be newly created and existing threads can be deleted within this numerical limit, and the number of worker threads can vary while the Java virtual machine 30 is working. Being able to appropriately increase the number of threads also makes it possible to run instances in parallel using multiple threads per instance, and thereby speed up the execution of the instances.

Java stacks 56a, 56b, . . . 56n exist one-to-one with threads 55a, 55b, . . . 55n, and each have a program counter ("PC" in FIG. 20) and one or more frames. The program counter shows which part of the instance is currently executing. A frame is a stack-type area allocated to each call of a method, and consists of an operand stack for storing arguments that occur simultaneously with the call and a local variable stack used by the called method ("local variables" in Figure 20 )composition. Since frames are stacked on the Java stack 56a, 56b, . . . 56n whenever a call is made, the frames of methods that recursively call themselves are also stacked one on top of the other.

The internal structure of the Java virtual machine is as described above. The Java virtual machine with the above structure acts as an event-driven execution entity. This completes the description of the Java Virtual Machine.

Display Engine 31

The display engine 31 performs an AV playback function. The AV playback function of the playback device is a traditional function group inherited from DVD players and CD players, including play, stop, pause start (PAUSEON), pause end (PAUSE OFF), mute (STILL OFF), fast forward playback (x2, x4, etc.), rewind playback (x2, x4, etc.), audio change, subtitle change, and angle change. In order to realize these AV playback functions, the display engine 31 controls the video decoder 4, the P graphics decoder 6, the I graphics decoder 10 and the audio decoder 16 to decode a part of the AVClip read into the read buffer 2, the part Corresponds to the expected time. Any point in the AVClip can be made playable by decoding the place indicated by PSR8 (current PTM) to the expected time.

Playback Control Engine 32

The playback control engine 32 performs various functions including (i) playback control of the playlist and (ii) collecting/setting the state of the PSR group 23 . The playback control function includes causing the display engine 31 to perform play and stop in the above AV playback function based on the current PL information and clip information. Functions (i) and (ii) are executed according to function calls from DVD-like module 29a and Java platform 29b.

Next, the synchronization of the processing executed by the playback control engine 32 and the processing executed by the Java virtual machine will be described. The playback control engine 32 executes processing based on PL information when a function is called. This processing is performed for the duration of the AVClip for playback, regardless of whether the playback time is 15 minutes or 30 minutes. The problem here is that there is a delay (time lag) between the time when the Java virtual machine 30 returns a successful response and the time when the playback control engine 32 actually finishes processing. The Java Virtual Machine 30 as an event-driven execution entity returns a response indicating whether the playback is successful immediately after the call, and the playback control engine 32 ends the playback of the AVClip and the PlayItem after the 15 or 30 minute playback duration elapses. Thus, the time for a successful response to be returned to the application cannot be used as a basis for measuring the end of processing after 15 or 30 minutes. Measuring the end of the process becomes more difficult when fast-forwarding or rewinding is performed during PL playback, since playback times of 15 or 30 minutes vary. In view of this, when the playback of each PlayItem or AVClip ends, the playback control engine 32 outputs an event indicating the end of playback of the PlayItem and AVClip to the application. This output lets the application know at what point playback control engine 32 has ended PlayItem or AVClip playback.

Module Manager 33

The module manager 33 reads INDEX.BDMV and selects one of pieces of title information in INDEX.BDMV as current title information. The module manager 33 reads the BD-J object indicated by the current title information, and controls the playback control engine 32 to perform playback control based on the PL information described in the BD-J object. The module manager 33 also controls the Java virtual machine 30 to read and execute the Java archive file described in the BD-J object.

If the playback of the digital stream based on the PL information and the execution of the application end, or if the user invokes a menu, the module manager 33 reads title information defining another title, and selects this piece of title information as current title information. The process of selecting another piece of title information as the current title information based on digital stream playback or user menu calling is called "title change".

The state transition shown in Fig. 21 can be realized by repeatedly performing title changes. The oval window in Fig. 21 represents a title.

The titles include "FirstPlayTitle" for playback when the BD-ROM is loaded for the first time, "Top_menuTitle" constituting the top menu, and other general titles. Arrows jh1 , jh2 , jh3 , jh4 , jh5 , jh6 , jh7 and jh8 in FIG. 21 symbolically indicate transitions between titles.

The state transition shown in Fig. 21 includes playing FirstPlayTitle when the BD-ROM is loaded, then transitioning to Top_menuTitle and waiting for selection from the top menu.

When the user selects from the menu, the individual titles are played according to the selection before returning to Top_menuTitle again. The process of repeating this process infinitely until the disc is ejected is a state transition unique to the contents of the disc. This state transition is realized under the control of the above-mentioned module manager 33 .

This completes the description of the Java Virtual Machine 30, the Display Engine 31, the Playback Control Engine 32, and the Module Manager 33. Control of the playback control engine 32 by the Java virtual machine 30 is performed through a virtual package. In order to realize the control of the playback control engine 32 through the virtual package, the playback device includes a network management module 37 and a virtual file system unit 38 . These elements are described next.

Network Management Module 37

The network management module 37 downloads the data needed to generate the virtual package from the website managed by the provider of the movie work according to the method call from the application program. This data includes files (PL information, clip information, AVClip, Java archive files, etc.) to replace or add to the merge management information file, signature information file, and files on the BD-ROM. When the application program in the working memory 54 makes a download request, the network management module 37 downloads the data required to generate the virtual package through the network, and writes the downloaded data into the local memory 18 .

Virtual File System Unit 38

The virtual file system unit 38 is an element belonging to the second layer in FIG. 19 that generates a virtual package according to a method call from an application program. The generation of the Virtual Package includes the processing of managing the state of AVClips constituting the Virtual Package and the processing of generating Virtual Package information.

Virtual package information

The virtual package information extends the volume management information on the BD-ROM. The volume management information referred to here defines a directory structure existing on a recording medium, and is composed of directory management information related to directories and file management information related to files.

The virtual package information expands the directory structure on the BD-ROM by adding new file management information to the volume management information showing the directory structure. The file management information added to the volume management information relates to PL information, clip information, AVClip, and Java archive files existing in the local storage 18 . The process of generating the virtual package information to which the file management information has been added and providing the virtual package information to the playback control engine 32 allows the playback control engine to recognize files stored in the local storage 18 as existing on the BD-ROM. PL information, clip information, AVClip and Java archive files. FIG. 22 shows virtual package information typically generated by the virtual file system unit 38. On the upper left of Fig. 22 is the directory structure on the BD-ROM, which is the same as Fig. 2 . At the bottom left is the directory structure in the local storage 18, which is the same as in FIG. 14 . File management information related to PL information, clip information, AVClip, and Java archive files in the local storage 18 is added to the volume management information on the BD-ROM.

in particular:

i) The file management information related to the playlist information #2 (00002.mpls) in the local storage 18 is added to the directory management information in the PLAYLIST directory;

ii) File management information related to clip information #2, #3, and #4 (00002.clip, 00003.clip, 00004.clip) in the local storage 18 is added to directory management information in the CLIPINF directory;

iii) File management information related to AVClip#2, #3 and #4 (00002.m2ts, 00003.m2ts, 00004.m2ts) in the local storage 18 is added to the directory management information in the STREAM directory;

iv) The file management information related to the Java archive file "00002.jar" in the local storage 18 is added to the directory management information in the BDJA directory;

The virtual package information is thus obtained. In other words, virtual package information is volume management information that has been added in the above manner.

This virtual package information is then provided to the playback control engine 32, whereby the playback control engine can process the files in the local storage 18 on the same basis as the PL information on the BD-ROM, clip information, AVClip, and Java archive files. PL information, clip information, AVClip, and Java archive files. The generation of virtual package information is as described above.

The timing of virtual package information update is described below.

Assume that the BD-ROM is ejected after the transfer is performed in numerical order of reference signs indicated by arrows jh1 , jh2 , jh3 , jh4 , etc. in FIG. 21 . This allows the continuous time gap from loading to ejecting of the BD-ROM to be seen as a single time axis. This time axis is taken as the time axis of the entire disc. FIG. 23A shows the time axis of the entire disc, and FIG. 23B shows the structure of the time axis. As shown in FIG. 23B, the time axis of the entire disc is composed of intervals at which FirstPlayTitle is played, intervals at which Top_menuTitle is played, and intervals at which normal titles (Title #1, etc.) are played. Regarding the way of defining the playback intervals of these titles, since each title consists of only one BD-J object, the interval for which any given BD-J object is valid can be taken as the title's playback interval. The gaps between these playback intervals, or the slight intervals when changing from one title to another (ie "title change") are when the virtual package information is updated.

Next, a process of downloading a new merge management and signature information file and a content file performed by a Java application is described using FIG. 24 .

The Java application first sends the current merge management information file to the server (step S11), thereby requesting download, and judges whether data from the server has been received (step S12). When the data is downloaded, the Java application program creates a new directory in the corresponding optical disc directory, and writes the downloaded combined management information file and signature information file into the new directory (step S13). It should be noted that if the file name of the downloaded merge management and signature information file is not consistent with the existing merge management and signature information file in the CD directory, the downloaded file can be directly placed under the existing directory (CD #1 file) without Create a new directory. The downloaded AVClip, clip information, PL information, and Java archive files are written into corresponding directories (step S14). The Java application then calls the update request method using the file path of the new merge management and signature information file as an argument (step S15). The Java application judges whether the return value is false (step S16), and if false, terminates the process. If the return value is false, the Java application executes processing using the updated virtual package information (step S17).

It is to be noted that although the above processing has been described in terms of the Java application sending the current merge management information file to the server when download is requested, the Java application may send only the ID of the merge management information file.

Next, an update "preparation" process performed by the virtual file system unit 38 upon receiving an update request is described using FIG. 25 .

The virtual file system unit 38 first reads the new merge management and signature information file using the file path serving as an argument when the method is called (step S21), and verifies the signature to check whether the new merge management information file has been falsified (step S22). Execution terminates abnormally if the signature cannot be verified. If the signature is verified, the virtual file system unit 38 checks the authority of the calling application (step S23). Executes abnormal termination if the calling application is not authorized. If the calling application is authorized, the virtual file system unit 38 judges whether the file specified by the new merge management information file actually exists in the local storage (step S24). Execution terminates abnormally if these files do not exist. If these files exist, the virtual file system unit 38 makes the new merge management and signature information file and all files in the local storage referred from the new merge information file read-only (step S25).

FIG. 26 is a flowchart of the virtual package "update" process performed by the virtual file system unit 38 . The virtual file system unit 38 first identifies the disc directory corresponding to the loaded BD-ROM, and replaces the disc directory with the new merge management and signature information file specified by the file path serving as an argument when the Java application calls the update request method. Merge management and signature information files (step S31). The virtual file system unit 38 then adds the file management information of the PL information specified by the merge management information file in the local storage 18 to the directory management information in the PLAYLIST directory (step S32), and executes a loop of steps S33 to S37. This loop includes repeating steps S34 to S36 for each piece of clip information existing in the local storage 18 . Here, one piece of clip information used for loop processing is assumed to be clip information x. The virtual file system unit 38 identifies the AVClip corresponding to the clip information x (step S34), and the file management information of the clip information x specified by the merge management information file in the local storage 18 is added to the directory management information in the CLIPINF directory (step S34). S35), and the file management information of AVClipx specified by the merge management information file in the local storage 18 is added to the directory management information in the STREAM directory (step S36). By repeating the above processing for all clip information and AVClips in the local storage 18, file management information related to clip information and AVClips is added to the volume management information. The volume management information thus obtained is virtual package information. The virtual file system unit 38 provides the virtual package information to the application program that made the virtual package call (step S38), and ends the processing.

FIG. 27 is a flowchart of processing executed by the module manager 33 .

The module manager 33 first selects FirstPlayTitle as the current title (step S41), designates the BD-J object corresponding to the current title as the current BD-J object (step S42), and makes the playback control engine 32 based on the current title in the current BD-J object. The described PL information performs PL playback (step S43). The module manager 33 then causes the Java platform 29b to run the Java application whose life cycle is the current title in the application management table of the current BD-J object (step S44), and causes the Java platform 29b to terminate the Java application whose life cycle is not the current title. Java application program (step S45). The module manager 33 then judges whether the PL playback based on the current PL information has been completed (step S46), and if completed, the module manager 33 identifies the next title (step S47), and selects this title as the current title (step S48 ). If the current PL playback has not been completed, the module manager 33 judges whether a title call has occurred (step S49), and moves to step S47 if so. If a title call has not occurred, the module manager 33 judges whether a title jump has occurred (step S50), and if so, moves to step S47. If a title jump has not occurred, the module manager 33 judges whether the main application for the current title has ended (step S51) and moves to step S47 if so. If the main application has not ended, the module manager 33 returns to step S46.

FIG. 28 is a flowchart of playback processing executed by the playback control engine 32 . The playback control engine 32 executes the loop of steps S62 to S68 after setting the first piece of play item information in the current PL information as the play item i (step S61). The control variable in this loop is the variable i. The playback control engine 32 increments the control variable i by "1" at step S68 after executing steps S62 to S66 until the variable i exceeds the number of playitems (step S67).

Next, steps S62 to S66 are described. The playback control engine 32 sets the AVClip described in Clip_information_file_name in PlayItem i to AVClipj (step S62), and instructs the drive device and decoder to play AVClipj from PlayItem.In_time to PlayItem.Out_time (step S63). The playback control engine 32 judges whether there is a sub play item k of the specified play item i in Sync_PlayItem_Id (step S64), and directly moves to step S67 if the sub play item does not exist. If the sub-play item k exists, then the playback control engine 32 sets the AVClip described by the Clip_information_file_name of the sub-play item k to AVClip h (step S65), instructs the drive device and the decoder to replay the AVClip from Sync_Start_PTS_of_PlayItem to Out_time (step S65) S66), and move to step S67.

As this process is repeated for all playitem information constituting the PL information, the stream sequence defined by the PL information is played.

Figure 29 shows how virtual package information is updated during title changes.

The first level in FIG. 29 shows the title playback interval on the time axis, the second level shows the Java application whose life cycle is Title #1, the third level shows the digital stream, and the fourth level shows the virtual file system unit 38. state.

Upon accepting the update request from the Java application, the virtual file system unit 38 is placed in the "ready" state, and the processing shown in FIG. 25 is executed.

After executing this process, the virtual file system unit 38 waits for a title change in the "ready" state. When a title change occurs, the virtual file system unit 38 is placed in the "update" state, and performs the process shown in FIG. 26 to update the virtual package before reverting to the "stable" state. If Title #1 is selected again from Top_menuTitle after the virtual file system unit 38 has returned to the "stable" state, then Title #1 is played using the updated virtual package.

Here, a title change occurs when the module manager 33 selects a different title as the current title, for example due to the end of the playback of the stream sequence or a menu call by the user.

The above processing is schematically described using FIGS. 30 to 33 .

Fig. 30 shows a Java application that sends the current merge management information file to the server. Files shown under ROOT are located in local storage, while files under BDMV are located in virtual packages.

Fig. 31 shows a Java application for downloading a content file, a new merge management information file, and a new signature information file. "00012.clpi" and "00012.m2ts" are downloaded content files, and the merge management and signature information files stored in the newMF directory have been newly downloaded.

FIG. 32 shows a Java application requesting the virtual file system unit 38 to update the existing merge management and signature information file to the latest downloaded file. The update request is made by specifying the new merge management and signature information file using the file path.

Fig. 33 shows the replacement of merge management and signature information files and the mapping of content files. The replacement of the old merge management and signature information files during the update is shown on the left side of FIG. 33 . On the right side of Fig. 33 is shown the mapping of content files after title change.

Note that the read-only attribute of files referenced from the old merge management information but not from the new merge management information is removed, thereby making these files writable by Java applications.

The merge management information file includes information indicating the location of content added to the local storage. The information indicating the location of the additional content includes a content ID, a directory path of a directory in which the content is stored, or a file path of a single content file. File name mapping information may be described in the merge management information file when mapping these files to the virtual package, thereby allowing access to these files under different file names in the virtual package. Here, the file name mapping information maps the file name (including the file path) in the virtual package with the file name (including the file path) in the local storage.

In this case, a virtual package is generated by the virtual file system unit 38 as a virtual package medium composed of files whose file names in the virtual package described in the file name mapping information have been changed to Added to the file structure on the BD-ROM. Files in the virtual package that are accessed by Java applications are designated as files in the virtual package rather than files on the BD-ROM or in local storage. When a Java application program requests access to a file in the virtual package, the virtual file system unit 38 switches the access destination to the local storage or the BD-ROM based on the file name mapping information. If a desired file is described in the file name mapping information, the access destination becomes the corresponding file in the local storage. If the desired file is not described in the file name mapping information, the access destination becomes the corresponding file on the BD-ROM.

In other words, the author of the Java application does not need to know the medium (BD-ROM or local storage) on which the individual files are stored, because the virtual file system unit 38 assigns the access purpose of the file specified by the Java application in the virtual package to can switch to the medium that actually stores the file, thereby reducing the burden of program authoring.

According to the present embodiment, the virtual package is updated during title change, which means that the replacement of the playback object will not cause abnormal operation of the playback device.

Example 2

This embodiment relates to improvement when performing title calling. Title invocation causes the called title to play after first pausing the current title, then resume the original title after playback of the called title has ended. Since title calling is predicated on continuing playback, the playback control engine 32 saves the system parameters for playback control stored in the PSR into the backup PSR when the title is called, and after the playback of the called title ends, Restore saved parameters to PSR.

Below is a list of system parameters stored in the PSR. PSR 0 to PSR 12 store system parameters showing playback status, PSR 13 to PSR 19 store system parameters set as preferred by the player, and PSR20 to PSR32 are backup PSRs.

PSR0: I graphics stream number

PSR1: audio stream number

PSR2: P graphics stream/TextST stream number

PSR3: angle number

PSR4: current title number

PSR5: current chapter number

PSR6: current playlist ID

PSR7: current play item ID

PSR8: Replay time information

PSR9: Navigation Timer

PSR10: Select key information

PSR11: current page ID in I graphics stream

PSR12: User style IDs in P graphics stream and TextST stream

PSR13: audio-visual age level (parental level)

PSR14: Subtitle Support Information

PSR15: Player Settings (Audio)

PSR16: Language code of the audio stream

PSR17: Language code for P graphics stream and TextST stream

PSR18: Language code for the menu

PSR19: Player version information

PSR20: backup of PSR0

PSR21: backup of PSR1

PSR22: backup of PSR2

PSR23: backup of PSR3

PSR24: backup of PSR4

PSR25: backup of PSR5

PSR26: backup of PSR6

PSR27: backup of PSR7

PSR28: backup of PSR8

PSR29: backup of PSR9

PSR30: Backup for PSR10

PSR31: backup of PSR11

PSR32: backup of PSR12

Updating the virtual package information during a title call results in a difference in the virtual package information before and after the call.

Since the virtual package information will change when the original title is restored, an error may occur if the playback control engine 32 attempts to play the original title using the backup values. This problem is avoided by clearing the backup PSR when the Java application requests an update. However, assuming that changes have no effect depending on the contents of the merge management information file, the decision on whether to clear system parameter values can be left to the Java application.

FIG. 34A is a flowchart of processing performed by the playback control engine 32 when the playback of the current title is suspended after a title call. FIG. 34B is a flowchart of processing performed by the playback control engine 32 when playback of the original title continues after playback of the called title ends.

When the playback of the current title is suspended, the playback control engine 32 saves PSR 0-12 to PSR 20-32 (step S71).

When continuing the playback of the original title after the playback of the called title ends, the playback control engine 32 first judges whether the virtual package has been updated (step S81). If not updated then PSR 20-32 is recovered to PSR 0-12 (step S83), if the virtual package information has been updated then initialize PSR20-32 (step S82) before performing step S83.

According to the present embodiment, the backup PSR is initialized when the virtual package information has been updated during title invocation, thereby eliminating the risk of a playback error when the playback of the original title is continued. Thus, the playback control engine 32 is stably operated.

Note that the system parameter values in the PSR can be forcibly cleared when the virtual package information is updated, rather than leaving the decision to the Java application.

Example 3

The present embodiment relates to a method for managing versions of merge management information and specifying additional content for merge from a resident application in a playback device. Fig. 35 shows typical contents of a merge management information file related to this embodiment. In Embodiment 1, the merge management information file (or more precisely the merge management information stored therein) is updated by rewriting the old merge management information, thereby causing the old information to be erased. In this embodiment, new merge management information is continuously added to the file, and old information is not rewritten even for the same disc ID. Thus, if the virtual file system unit 38 cancels the generation of the virtual package and reverts to the original BD-ROM, information reflecting this state is retained in the merge management information file. In this case, the corresponding unit in the merge target directory of the merge management information file is left blank or a character string indicating the original BD-ROM is written.

Keep the previous merge management information (history) in the merge management information file by not overwriting the old merge management information when performing the update, and then if the user wants the old version of the virtual package, he can refer to the previous merge management information to generate the old version . Also, a virtual package previously generated by a user can be generated not only from a Java application but also from a resident application in the playback device with reference to the merge management information file (or rather the old merge management information stored therein).

Another example of the use of previously merged management information by the resident application includes displaying a list of additional content so that the user can delete unwanted additional content from the resident application. Since the merge management information file can be used to distinguish directories storing additional content, it is also possible to retrieve and delete additional content from applications other than the Java application storing the additional content (ie, resident applications).

FIG. 36 shows a Java application requesting virtual package update regarding this embodiment. The difference from Embodiment 1 lies in the fact that merge management information is continuously added without rewriting old information even if merge management information for the target disc ID already exists. When a virtual package update is requested, the Java application is allowed to identify the latest piece of merged management information in the merged management information file by adding date information. Date information is not limited to dates, and may simply be consecutive numbers.

Figure 37 shows a typical additional content list displayed to the user by a resident application using a merged management information file. Here, the displayed additional content list is based on the merge management information file shown in FIG. 35 . It is ideal to display information that enables the user to grasp the additional content involved. Additional content in Fig. 37 is displayed as a content name. Although only date information is added to the consolidated management information in FIG. 36, a summary of additional content may also be added since the resident application can perform such a display. In this case, a feed of additional content is provided for input with the content ID when a Java application requests a virtual package update. These feeds can specify file paths to files containing the respective feeds, rather than simply including direct input of strings. The management information store content feeds are thus merged in addition to the date of update, and the resident application can display these feeds in an additional content list along with date information.

Rather than having a Java application specify a content feed, meta information showing what a particular content is about can be appended to the content itself, and the resident application can read this information and display a feed based on the read information.

The "Add" column in Fig. 37 shows the date when each additional content was first merged with the BD-ROM. This information can also be read from the merge management information.

Note that the date when the add-on was first merged can be kept separately from the merge management information. These dates can also be determined from the date the directory storing the additional content was created. When one of the selection buttons displayed in the additional content list is pressed, the resident application writes the directory path/disc ID and selection date of the selected content into the merge management information file as corresponding merge management information. In other words, the most recently selected additional content becomes the latest merged management information. If the original BD-ROM is selected, a value indicating the original BD-ROM or a blank cell is inserted into the merge target directory of the merge management information file. When one of delete buttons displayed in the additional content list is pressed, the resident application reads the directory of the additional content for deletion with reference to the merge management information file, and deletes the directory. Merge management information corresponding to the content ID of the content is also deleted from the merge management information file.

FIG. 38 is a flowchart of the flow of processing from loading of the BD-ROM to playback in this embodiment. The virtual file system unit 38 first checks the disc ID of the loaded BD-ROM (step S91), reads the merge management information file (step S92), and judges whether there is a merge management corresponding to the disc ID of the loaded BD-ROM. information (step S93). If the judgment is negative (step S93=No), playback is performed using only the original BD-ROM (step S94). If the judgment is affirmative (step S93=Yes), a virtual package is generated using the latest merge management information (step S95). During the generation of the virtual package, the virtual file system unit 38 judges whether an error has been detected (step S96). If the judgment is affirmative (step S96=YES), the virtual file system unit 38 judges whether there is previous merge management information corresponding to the disc ID of the BD-ROM (step S97). If the judgment is affirmative (step S97=Yes), a virtual package is generated using the version of the merge management information preceding the latest merge management information (step S98). If the judgment is negative (step S97=NO), playback is performed using only the original BD-ROM (step S94). If no error is detected at step S96, playback is performed using the generated virtual package (step S99). Typical errors include errors in the latest merge management information and non-existent data streams referenced from playlists, etc.

According to the present embodiment, by saving previous merge management information in a merge management information file, a virtual package can be generated from a resident application in a playback device using an old version of merge management information with reference to the content history of the merge management information file. If an error occurs during the generation of the virtual package, the problem can be avoided by generating an older version of the virtual package as an alternative course of action.

Example 4

The present embodiment relates to a method for designating an effective period of a virtual package when a Java application requests virtual package update, and performing playback using the virtual package only within the effective period.

Fig. 39 shows the valid period specified when a virtual package update is requested. The Java application specifies the content ID for the incorporated additional content and the expiration date for use of the virtual package. For example, if a user wants to play the content as a virtual package until the disc is ejected and then after reloading the disc with just the original BD-ROM, the value indicating that the virtual package is valid until the disc is ejected is not available in the request from the Java application. It is specified in the argument at the time of virtual package update.

FIG. 40 is a flowchart of the flow of processing from loading of the BD-ROM (or restart of the playback device) to playback in this embodiment. The virtual file system unit 38 first checks the disc ID of the loaded BD-ROM (step S101), reads the merge management information file (step S102), and judges whether there is a merge management corresponding to the disc ID of the loaded BD-ROM. information (step S103). If the judgment is negative (step S103=No), playback is performed using only the original BD-ROM (step S104). If the judgment is affirmative (step S103=Yes), the virtual file system unit 38 judges whether the corresponding merge management information is within the validity period (step S105). If no longer valid, the corresponding merge management information is deleted (step S106), and playback is performed using only the original BD-ROM (step S104). If still valid, the corresponding merge management information is used to generate a virtual package (step S107), and playback is performed using the virtual package (step S108).

It should be noted that a mode in which only the Java mode virtual package is generated is also conceivable as an application of the present embodiment. If only the Java mode is specified when creating a virtual package is requested from a Java application, when there is transition from the DVD-like mode to the Java mode, the virtual file system unit 38 creates a virtual package and then shifts to the Java mode. Conversely, when there is a transition from the Java mode to the DVD-like mode, the virtual file system unit 38 transitions to the DVD-like mode after canceling the virtual package and reverting to the original BD-ROM.

According to the present embodiment, it is possible to specify the effective period of playback using a virtual package, thereby allowing playback using only one virtual package (i.e., a virtual package that is prohibited once the BD-ROM is ejected), and generating Limited virtual packages.

It should be noted that in this embodiment, the valid period is specified when requesting the update of the virtual package, and the valid period can also be specified when requesting to generate the virtual package after the BD-ROM is loaded.

Example 5

The following is a specific description about the authority to invoke the application program in step S23 in FIG. 25 of Embodiment 1. Specifically, the present embodiment relates to a method of rejecting a virtual package update request from an unauthorized Java application.

Figure 41 shows a license request file used to filter virtual package update requests. As described above, virtual package update is performed on the basis of an update request from a Java application. However, when the update is performed on the basis of a request from an unauthorized Java application, there is a risk that the contents of the disc are illegally updated because viewing restrictions are changed or playback of video clips that can only be viewed under certain conditions is allowed . In view of this, the virtual package update according to the present embodiment can only be requested by a Java application having an update permission which is information showing that the permission requesting the update has been granted. Whether or not there is an update license is judged by checking the content of the license request file corresponding to the Java application that issued the request. Specifically, the class loader restricts the functions of Java applications according to the contents of each license request file. For example, the update request is processed if the value of the update attribute in the permission request file is "true" and rejected if it is "false".

Figure 42 shows the access restrictions imposed on directories in local storage for merging. If the content of the directory for merging is changed by an unauthorized Java application, there is a risk that the content of the virtual package is illegally changed even if the update request is filtered. In view of this, permission for local storage access is also restricted on the basis of the contents of each permission request file. For example, if the read and write attribute values in the permission request file are both "true", downloaded content can be written and stored files can be read and edited. However, file access restrictions will be imposed on Java applications with a permission request file with one or both of the read and write attributes false, or without a permission request file.

According to the present embodiment, it is possible to prevent unauthorized Java applications from updating virtual packages and changing contents of directories in local storage.

The following is a concrete example of using a license request file to restrict virtual package updates. Consider an example where a directory in local storage is assigned to a particular supplier of a movie production. Specifically, it is assumed that contents provided by A studio, B studio, and C company are simultaneously stored in the local storage and on the BD-ROM. Here, Company C is a supplier of digital magazines. A problem arises when merging the content in the local storage and the BD-ROM, for example if the content provided by studio B is merged with the content provided by studio A. In view of this, only the update permission of the C company is granted (ie, the update attribute value in the permission request file is set to "true"), thereby allowing various services to be made available. Studio A and Studio B are only able to merge their own content.

Example 6

The present embodiment relates to a method for updating a virtual package during a title change in a case where a Java application operates on a plurality of titles.

Figure 43 shows a Java application whose lifecycle is limited to a single title and a Java application whose lifecycle lasts for multiple titles. The life cycle of the Java application is displayed in the application management information, and the module manager 33 manages the start and end of the Java application based on the application management information. Java applications include those that exist only within the title in which they start (hereinafter referred to as "title-bound applications") and those that can exist on multiple titles (hereinafter referred to as "title-bound applications"). Unbound application"). The application management information includes title number, application ID and information showing whether a specific Java application is bound or not.

In the application management information shown in FIG. 43, for example, Java application #1 is bound and Java application #2 is not bound in Title #1. The module manager 33 terminates the binding of the Java application #1 along with the end of the title #1. On the other hand, the unbound Java application #2 is allowed to survive after the end of Title #1, and a decision whether to terminate the application is made based on the application management information of the next Title. Since the example of application management information in FIG. 43 shows that Java application #2 can exist in both Title #1 and Title #2, the application is allowed to survive during the transition from Title #1 to Title #2. However, since the Java application #2 is title-bound in Title #2, the module manager 33 terminates the application along with the end of the title.

Fig. 44 shows the processing performed on an application not bound to a title when a virtual package is updated during a title change. As shown in FIG. 43, title-unbound applications that can exist in both the title before the title change and the title after the title change continue to work during the title change. However, if a virtual package update is requested, all applications including title-unbound applications are terminated during the title change. After updating the virtual package, the title-unbound application is then restarted together with the title-bound application belonging to the next title.

Fig. 45 is a flowchart of title change processing in consideration of unbound title applications. When title playback starts (step S111), the virtual file system unit 38 first judges whether virtual package update has been requested from the Java application during playback of the current title (step S112). If the judgment is affirmative (step S112=Yes), the virtual file system unit 38 performs update preparation (step S113). When a title change occurs (step S114), the virtual file system unit 38 judges whether or not an update request has been processed (step S115). If the judgment is affirmative (step S115=Yes), all applications including the title-unbound application are terminated (step S116), and the virtual package is updated (step S117). Then the next title is played after the title change (step S118). If a virtual package update has not been requested at step S112 or if an update request has not been processed at S115, the module manager 33 simply terminates the title binding application when a title change occurs (step S119).

Since this embodiment guarantees that all applications are terminated during the update of the virtual package, it is possible to Prevents any loss of continuity after a virtual package update.

Note that if a Java application capable of existing on multiple discs ("disc-unbundled application") is working when a title change occurs after a virtual package update is requested, by treating the virtual Package updates, disc-unbound applications can continue to work without being forcibly terminated.

It should also be noted that after a title change occurs, the module manager 33 can manage the start and end of the title-unbound application based on the application management information updated after the virtual package update is completed, without terminating the title-unbound application during the update. custom application. In this case, before the update is completed, the title-unbound application is made to refer to the pre-update virtual package.

Example 7

This embodiment relates to the update of the virtual package after the INDEX.BDMV file is changed. Upon receiving a virtual package update request from a Java application, the virtual file system unit 38 confirms that the INDEX.BDMV file exists in the directory for merging. If the INDEX.BDMV file exists, the virtual file system unit 38 reads the INDEX.BDMV file in preparation for the update. Then the existing INDEX.BDMV file is invalidated and the new INDEX.BDMV file is enabled. If a resident application such as a BD player performs a title search or a Java application collects title information, this new INDEX.BDMV file is used before a title change. In other words, notifying the Java application and the user in advance after updating the title structure makes it possible to prevent the title from changing to a title that will cease to exist after the update or to an unexpected title.

Fig. 46 is a flowchart of virtual package update after INDEX.BDMV file change. First, when a title is played in Java mode (step S121), the virtual file system unit 38 judges whether the Java application has requested a virtual package update (step S122), and if requested, the virtual file system unit 38 receives the request and executes Updating preparation (step S123). While checking whether the file and directory structures are correct, the virtual file system unit 38 judges whether the INDEX.BDMV file exists (step S124). If the INDEX.BDMV file exists, the virtual file system unit 38 invalidates the existing INDEX.BDMV file and validates the new INDEX.BDMV file (step S125) before judging whether a title call has occurred (step S126). The title change is performed from a resident application in the BD player or from a Java application referring to the INDEX.BDMV file validated in step S125. The virtual file system unit 38 performs an update when a title change occurs (step S127).

Thus, although the virtual package update is not performed until the title change occurs after the update request, the new INDEX.BDMV file can be made available before the title change. This means that after an update request, the list of titles displayed during a title search will have changed before the title change occurred.

Since the user then selects a title based on the changed title list, errors caused by selecting a title that will cease to exist after the update can be prevented. It is thus possible to update the virtual package without problems during a title change, even if the title structure is changed due to the update.

It should be noted that the update of the virtual package after the change of the INDEX.BDMV file can be performed after restarting the BD player.

transform

The playback apparatus related to the present invention has been described above based on the preferred embodiments, although the present invention is of course not limited to these embodiments.

The above embodiments have been described with respect to the playback device whose only function is to play a recording medium, although the present invention is not limited thereto. For example, the present invention may be a recording/playback device having recording and playback functions.

Files can be placed in local storage using any type of structure as long as the correspondence with the files on the BD-ROM for merging is clearly shown.

In the above embodiments, Java (registered trademark) is used as the programming language of the virtual machine, although it is also possible to use programming languages other than Java, and such examples include Perl Script, ECMA Script, and B-Shell, etc., which are compatible with UNIX ( registered trademark) operating system.

The above embodiments have been described with regard to a playback device that plays a BD-ROM, although of course the same as above can be realized in the case where necessary data on a BD-ROM is recorded on a writable optical recording medium as described in the above embodiments. Effect.

Also, it is of course possible to realize the same as above in the case where the necessary data on the BD-ROM as described in the above embodiment is recorded on a portable recording medium (such as an SD card, a compact flash memory, etc.) other than an optical recording medium. Effect.

Industrial applicability

The playback devices constituting the present invention can be manufactured operationally, continuously and repeatedly in the manufacturing industry. The playback device finds particular application in the film and consumer goods industry with respect to video content production.

Claims (2)

1. a limit and executory application program are play the replay device of digital stream in interlock, limit mutually, and described replay device comprises:

Assure the reason unit, be used for according to the merging management information that writes down on the re-writable recording medium, make up file that is recorded on the recording medium and the file that is recorded on the re-writable recording medium, thereby generation package informatin, and the indicated file of the employed merging management information of the generation of described package informatin being become read-only, the indication of described merging management information is used to be combined to the file of described recording medium;

Selected cell, but be used for detecting a plurality of play title from described package informatin, and select one of them as current title;

Processing unit is used to carry out and the relevant application program of described current title; And

The playback Control Engine, be used for according to described current title appointment and be included in playlist information in the described package informatin, the playback of control figure stream, wherein

When specifying different by performed described application program and being recorded in new merging management information on the described re-writable recording medium with the employed merging management information of the generation of described package informatin, ask described when assuring the reason unit and carrying out the renewal of package informatin of described generation

The described reason unit of assuring,

Before upgrading described package informatin, with the new merging management information of described appointment indicated, be recorded in file on the described re-writable recording medium become read-only, and,

Selection at the new current title that carries out owing to described selected cell, make the playback Control Engine stop the digital stream playback time that carries out according to the playlist information of indicating in the described current title, new merging management information according to described appointment, combination is recorded in the file and the file that is recorded on the described re-writable recording medium on the described recording medium, generate new package informatin

Described re-writable recording medium comprises a plurality of CDs and relies on the district,

The described described a plurality of CDs of reason unit marks of assuring rely on CD dependence district corresponding with the described recording medium that is loaded in the district, and rely in the district at the CD that is identified, described merging management information is converted to the new merging management information of described application program appointment.

2. a limit and executory application program are play the playback method of digital stream in interlock, limit mutually, and described playback method comprises:

Package informatin generates step, be used for according to the merging management information that writes down on the re-writable recording medium, make up file that is recorded on the recording medium and the file that is recorded on the re-writable recording medium, thereby the generation package informatin, described merging management information indication is used to be combined to the file of described recording medium;

Attribute change step becomes the indicated file of the employed merging management information of the generation of described package informatin read-only;

Select step, but be used for detecting a plurality of play title, and select one of them as current title from described package informatin;

Treatment step is used to carry out and the relevant application program of described current title; And

The playback controlled step, be used for according to described current title appointment and be included in playlist information in the described package informatin, the playback of control figure stream, wherein

When specifying different by performed described application program and being recorded in new merging management information on the described re-writable recording medium with the employed merging management information of the generation of described package informatin, when asking the renewal of package informatin of described generation,

Before upgrading described package informatin, by described attribute change step, with the new merging management information of described appointment indicated, be recorded in file on the described re-writable recording medium become read-only, and,

In selection owing to the new current title in the described selection step, make the playback controlled step stop the digital stream playback time that carries out according to the playlist information of indicating in the described current title, generate in the step at described package informatin, new merging management information according to described appointment, combination is recorded in the file and the file that is recorded on the described re-writable recording medium on the described recording medium, generate new package informatin

Described re-writable recording medium comprises a plurality of CDs and relies on the district,

Described package informatin generates in the step, identify described a plurality of CD and rely on CD dependence district corresponding in the district with the described recording medium that is loaded, and rely in the district at the CD that is identified, described merging management information is converted to the new merging management information of described application program appointment.

Images