RU2393556C2 - Recording medium, device of reproduction and methods of recording and reproduction - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: audio stream is recorded onto medium. Audio stream includes multiple packets of packed elementary stream, to every of which packet identifier is connected, including upper field and lower field. Upper field indicates that audio stream that contains packet is the secondary audio stream, output data of reproduction of which may be mixed with output data of primary audio stream reproduction.

EFFECT: simplified identification of the secondary audio stream.

20 cl, 50 dwg

Description

FIELD OF THE INVENTION

The present invention relates to the field of technology, including the technology of mixing (mixing) of audio signals.

BACKGROUND OF THE INVENTION

An audio mixing technique is a technology for reading, from one or more recording media, a primary audio stream containing primary sound / voice and a secondary audio stream containing secondary sound / voice, decoding the primary and secondary audio stream, respectively, combining decoding results to generate uncompressed digital audio data , and output uncompressed digital audio data.

The technology allows you to provide many of the digital streams that make up the movie through various media and, for example, makes it possible to attach a director’s comment to the movie, increasing the freedom to create options for one movie. Therefore, the technology allows you to create a large number of options from one movie.

The following document, as prior art, discloses a technology for reading digital streams from recording media and reproducing readable digital streams.

Document 1: Japanese Patent Application Laid-Open No. 2000228656

SUMMARY OF THE INVENTION

OBJECTS RESOLVED BY THE INVENTION

However, in a model of a reproducing apparatus that performs such mixing of audio signals, a situation is possible where, while the primary audio stream is read from an optical disc, the secondary audio stream must be read from another recording medium. In this case, it may happen that the transport stream packet (TP packet) read from the optical disk and the TP packet read from another recording medium are transmitted on the same bus. When this happens, it is not obvious which one or more of the plurality of TP packets constitute the primary audio stream or the secondary audio stream. While it is possible to process TP packets as a whole, it is difficult to process either TP packets constituting the primary audio stream or TP packets constituting the secondary audio stream.

If the TP packets that make up the primary audio stream and the secondary audio stream are processed as a single unit, and the primary audio stream and the secondary audio stream are output with the same gain, quality-critical damage can occur, such as speaker failure, if adverse parameters overlap each other friend.

Therefore, it is an object of the present invention to provide a recording medium that can, if the TP packets constituting the primary audio stream and the secondary audio stream are transmitted on the same bus, process two types of TP packets separately.

MEANS OF SOLVING TASKS

To solve the above-described problem, the present invention provides a recording medium on which playlist information and an audio stream are recorded, wherein the playlist information contains main path information and subtree information, wherein the main path information defines one among the plurality of digital streams as the main stream and determines the main playback section for the main stream, the sub-stream information defines another of the plurality of digital streams as a substream and for this substream, the playback subsection, which should be synchronized with the main playback section, the main stream includes the video stream multiplexed in it and the primary audio stream, the audio stream being set as a sub-stream and includes many packets, each of which is attached with an identifier a packet, which includes an upper field and a lower field, and the upper field indicates that the audio stream is a secondary audio stream, the reproduced output of which can be eshany reproducible output of the Primary audio stream.

EFFECTS OF THE INVENTION

In the above structure, in which the upper field of the packet identifier indicates that the audio stream is a Secondary audio stream, the reproduced output of which can be combined with the reproduced output of the Primary audio stream, the demultiplexing module of the reproducing device can introduce packets via the bus, refer to the upper field of each packet identifier and , according to the pointer of the upper field, output packets to the decoding module allocated for the Secondary audio streams.

The demultiplexing module can accordingly separate packetized elementary stream packets (PEP packets) constituting the Secondary audio streams using demultiplexing and send PEP packets to a decoding module, which is not a decoding module dedicated to the Primary audio streams.

With such a structure in which the packets constituting the Primary audio streams and the packets constituting the Secondary audio streams are separated and fed to various decoding modules, it is possible to down-convert, down-mix, or reduce the gain of only the packets that make up the Primary audio streams. This allows you to subject special processes in real time only the packets that make up the Primary audio stream, even when reading the Secondary audio stream from the recording medium, while the Primary audio stream is read from the optical disk, and feed two streams to two corresponding decoding modules. In addition, the bottom field identifies one among the plurality of Secondary audio streams using its serial number. With this structure, if many different languages are available for the narration text, the narration text can be reproduced in a language similar to them.

LIST OF DRAWINGS

FIG. 1 shows the use of a recording medium in accordance with the present invention.

FIG. 2 shows the internal structure of a BD-ROM.

FIG. 3 shows the structure of the file to which the extension "m2ts" is assigned.

FIG. Figure 4 shows what processes the TP packets constituting the audio / video clip undergo before they are recorded on the BD-ROM.

FIG. 5 shows the relationships between the physical BD-ROM module and the Source packets constituting one contiguous portion of the file.

FIG. 6 shows elementary streams that are combined into an audio / video clip.

FIG. 7 shows the internal structure of the Clip information.

FIG. 8 shows the settings of the card_TV on the movie video stream.

FIG. 9 shows a data structure of information of a Playlist.

FIG. 10 shows the relationships between the audio / video clip and the Playlist information.

FIG. 11 shows the structure of the sound.bdmv file.

FIG. 12 shows the internal structure of local storage 200.

FIG. 13 shows elementary streams that are combined into a subclip.

FIG. 14 shows an IP destination map in the BD-ROM standard.

FIG. 15A shows the internal structure of the Secondary audio stream.

FIG. 15B shows an example of an audio data frame.

FIG. 15C shows the internal structure of metadata.

FIG. 15D shows an example of gain control information.

FIG. 16 shows how the sound volume of the Primary audio stream is controlled by metadata in the Secondary audio stream.

FIG. 17 shows a data structure of information of a Playlist.

FIG. 18 shows the internal structure of the Subtrain information in detail.

FIG. 19 shows the relationships between the Subclip on the local storage device 200, the Playlist information on the local storage device 200, and the Main Clip on the BD-ROM.

FIG. 20 shows the TV map and the time axis of the Playback Element that are set for the Main Clip, and the map_TV and the timeline of the Playback Subelement that are set for the Subclip composed of the Primary and Secondary audio streams.

FIG. 21 shows the internal structure of the STN_table.

FIG. 22A shows a Stream_ attribute corresponding to a video stream.

FIG. 22B shows the Stream_ attribute corresponding to the Primary audio stream and Secondary audio stream.

FIG. 22C shows a Stream_ record for video streams.

FIG. 22D shows Sub Records for Secondary Audio Streams.

FIG. 22E shows the internal structure of the Secondary_Audio_Connection_ Information_ of the Primary_ Audio signal, which is mapped to the Stream_ record and Stream_ attribute for the Secondary audio stream.

FIG. 23 shows the requirements for the Primary audio streams in accordance with the Primary Audio_Connection_ Information_ of the Primary Audio_ Signal.

FIG. 24 shows a virtual packet that is generated by the reproducing apparatus 300.

FIG. 25 shows the internal structure of a reproducing apparatus in accordance with the present invention.

FIG. 26 shows the functions of the control unit 22.

FIG. 27A shows the distribution of bits in RUS1.

FIG. 27B shows the bit allocation in RUSP14.

FIG. 27C shows the bit allocation in RUSP31.

FIG. 28 is a flowchart showing a procedure for reproducing a Playlist using the playlist processing module.

FIG. 29A shows the state transition of a set of values in RUS1.

FIG. 29B is a flowchart of “Procedures for Changing Playback Parameters” in RUSP1.

FIG. 30 is a flowchart showing the detailed procedure of step S5.

FIG. 31 is a flowchart showing a procedure for installing RUSP1 if a flow change is requested.

FIG. 32A shows the state transition of a set of values in RUSP14.

FIG. 32B is a flowchart of a "Procedures for Changing Playback Parameters" in RUSP14.

FIG. 33 is a flowchart showing the detailed procedure of step S35.

FIG. 34 is a flowchart showing a procedure for installing the RUSP14 if a flow change is requested.

FIG. 35A shows a connection model of a reproducing apparatus 300, an audio / video amplifier 500, and speakers 600.

FIG. 35B shows how the number of channels varies in each of the reproducing apparatus 300, the audio / video amplifier 500, and the speakers 600.

FIG. 36A shows the structure of the IDB.

FIG. 36B shows the values that can be set in each IDB field.

FIG. 36C shows a communication sequence using an IDB between the reproducing apparatus 300 and the audio / video amplifier 500.

FIG. 37 shows the internal structure of RUSP15 in the set of 23 RUSP.

FIG. 38 is a flowchart showing a processing procedure in the control unit 22 in the second embodiment.

FIG. 39 shows a menu for deciding whether to perform transit output.

FIG. 40 shows a menu for deciding whether to perform transit output.

FIG. 41 is a flowchart showing procedures for setting the player's ability to play an audio signal in the RUSP15 according to the IED.

FIG. 42 is a flowchart showing procedures for establishing a player's ability to play an audio signal in the RUSP15 in accordance with an IED.

FIG. 43A shows an example of a reproducing apparatus 300 installed in an automobile.

FIG. 43B shows the internal structure of the RUSP31 in the third embodiment.

FIG. 44 shows the internal structure of the information of the Playlist Tag contained in the information of the Playlist.

FIG. 45 shows a specification of a segment position by means of the Label CB information.

FIG. 46 is a flowchart of a Java ™ application processing flowchart in a third embodiment.

FIG. 47 is a flowchart showing a chapter search procedure.

FIG. 48 is a flowchart showing a chapter skip procedure.

FIG. 49 is a flowchart of a Java ™ application in a fourth embodiment.

FIG. 50 shows an example of displaying a menu having a “refresh button”.

DESCRIPTION OF REFERENCE POSITIONS

100 BD-ROM

200 local storage

300 playback device

400 tv

500 audio / video amplifier

600 speakers

1a BD-ROM drive

1b bus

2a, 2b read buffers

3a, 3b decompression modules

4 video decoding module

5 video plane

6a, 6b buffers

7a, 7b audio decoding modules

8 downmix / downsampling module

9a, 9b mixing modules

10a switch

10b coding module

11 interactive graphics decoding module

12 plane interactive graphics

13 graphical decoding module

14 plane graphic representation

15 JPEG decoding module

16 plane saver

17 merge module

18a, 18b CT generation modules

19a, 19b TPO generation modules

21 memories

22 control module

23 set of RUSP

24 IP conversion module

25 communication module

26 operation receiving module

27 HDMI transmit / receive module

41 Playlist processing module

42 module execution procedures

43 module execution procedures

44 mixing control module

PREFERRED EMBODIMENTS FOR CARRYING OUT THE INVENTION

First Embodiment

An embodiment of a recording medium in accordance with the present invention is described below. First, the use of a recording medium in accordance with the present invention will be described. FIG. 1 shows the use of a recording medium in accordance with the present invention. In FIG. 1, a recording medium in accordance with the present invention is a local storage device 200. Local storage device 200 is used to supply a movie to a home theater system composed of a playback device 300, a television 400, an audio / video amplifier 500, and speakers 600.

Now will be described the BD-ROM 100, the local storage device 200 and the playback device 300.

The BD-ROM 100 is a recording medium on which a movie is recorded.

Local storage device 200 is a hard disk drive that is built into the playback device and is used to store content (informationally meaningful content) that is distributed from the movie distributor’s server.

The playback device 300 is a digital household appliance that supports network connectivity and has the function of reproducing content of the BD-ROM 100. The playback device 300 is also configured to combine content that is downloaded from the server of the movie provider through the network with content recorded on the BD-ROM 100, to expand / update the content of the BD-ROM 100. When using a technology called the “virtual package”, it is possible to combine the content recorded on the BD-ROM 100 with the content recorded on the local storage minal device 200 and to process data that is not recorded on the BD-ROM 100 as if they were recorded on the BD-ROM 100.

The use of a recording medium in accordance with the present invention has so far been described.

Next, manufacturing of a recording medium in accordance with the present invention will be described. A recording medium in accordance with the present invention can be obtained by improving the BD-ROM file system. FIG. 2 shows a BD-ROM file / directory structure. In FIG. 2, the BD-ROM file / directory structure includes a BDMV directory under the root directory.

<BD-ROM scheme>

FIG. 2 shows the internal structure of a BD-ROM. Fourth Row of FIG. 2 shows a BD-ROM. The third line shows the tracks on the BD-ROM. FIG. Figure 2 shows the tracks as horizontally propagating, although in reality they form a spiral in the direction from the inner circle to the outer circle. Tracks include the start area, the volume area, and the end area. The volume region of FIG. 2 has a multi-level model, which includes the physical layer, the file system layer, and the application layer. The 1st row in FIG. 2 shows an application level format (application format) of a BD-ROM, presented as a directory structure. In the first row in FIG. 2 BD-ROM includes the BDMV directory under the root directory (ROOT).

The BDMV directory includes files that are assigned the extension "bdmv" ("index.bdmv" and "MovieObject.bdmv"). There are six subdirectories in the BDMV directory: the PLAYLIST directory, the CLIPINF directory, the STREAM directory, the BDBJ directory, the BDJA directory, and the AUXDATA directory.

The PLAYLIST directory includes a file that is assigned the extension "mpls" ("00001.mpls").

The CLIPINF directory includes a file that is assigned the extension "clpi" ("00001.clpi").

The STREAM directory includes a file that is assigned the extension "m2ts" ("00001.m2ts").

The BDBJ directory includes a file that is assigned the extension "bobj" ("00001.bobj").

The BDJA directory includes a file that is assigned the extension "jar" ("00001.jar").

The AUXDATA directory includes the file "sound.bdmv".

From the above directory structure, it is understood that many different types of files are stored on the BD-ROM.

<BD-ROM 1 Structure: Audio / Video Clip (AVClip)>

First, files with the extension "m2ts" will be explained. FIG. 3 shows the structure of the file to which the extension "m2ts" is assigned. A file that is assigned the extension "m2ts" ("00001.m2ts") stores an audio / video clip. The Audio / Video clip is a digital stream in the MPEG2 transport data stream format. The digital stream is generated by converting digital video and audio (upper 1st line) into an elementary stream composed of PEP packets (upper 2nd line), and by converting an elementary stream into TP packets (upper 3rd line) and, similarly by converting a graphic presentation stream (CGP) for subtitles or the like and an interactive graphics stream (CGI) for interactive purposes (lower 1st line, lower 2nd line) into TP packets (3rd line) and then, in conclusion by multiplexing these TP packets.

A CGP stream is a graphic stream composing subtitles written in a certain language. There are many threads, which, in turn, correspond to many languages, for example English, Japanese and French. The CST flow is composed of functional segments such as: CMS (Presentation Management Segment); SOP (Palette Definition Segment); COO (Window Definition Segment); COOb (Object Definition Segment) and KOH (END of Display Settings Segment). COOb (Object Definition Segment) is a functional segment that defines a graphic object as subtitles.

COO is a functional segment that defines the drawing area of an object on the screen. SOP (Palette Definition Segment) is a functional segment that determines the color when rendering a graphic object. SOF is a functional segment that defines page management when displaying subtitles. Such page management includes Insert / Cut, Flush, Color Change, Scroll, and gradually change one image to another. With page management with the help of EMS, it is possible to get display effects, for example, the gradual disappearance of the current subtitle when the next subtitle is displayed.

The GIS stream is a graphical stream for providing interactive control. The interactive control defined by the SGI stream is an interactive control that is compatible with the interactive control in a digital multifunction disc (DVD) playback device. The SGI stream is composed of functional segments, such as: LMS (Interactive Composition Segment); SOP (Palette Definition Segment); COOb (Object Definition Segment); and CON (END of Display Settings Segment). COOb (Object Definition Segment) is a functional segment that defines a graphic object. A button on an interactive screen is drawn using a variety of such graphic objects. SOP (Palette Definition Segment) is a functional segment that determines the color when rendering a graphic object. SIK (Interactive Composition Segment) is a functional segment that provides state changes, whereby the state of the button changes in accordance with the user's action. CEC includes a button command, which is executed if the confirmation action is performed by pressing the button.

An audio / video clip is composed of one or more "ST_sequences". "CT_sequence" is a section that does not include breaking the system time axis of the System Timer (CT), which is the standard system time for an audio / video (AV) stream. The gap of the system time axis CT is the point at which the burst indicator of the VOP packet that carries the VOP (Timestamp of the program), which the decoding module accesses to receive the CT, is in the ON state.

Next, it will be explained how the audio / video clip of the above construction is recorded on the BD-ROM. FIG. Figure 4 shows what processes the TP packets constituting the audio / video clip undergo before they are recorded on the BD-ROM. The 1st row in FIG. 4 shows TP packets constituting an audio / video clip.

As shown in the 2nd row in FIG. 4, a 4-byte optional TP_heading (shaded parts in the drawing) is attached to each 188-byte TP packet constituting the audio / video clip to form each 192-byte Source packet. The optional TP_head includes the Arrival_TimeStamp, which is information indicating the time at which the TP packet is input to the decoding module.

The Audio / Video clip, which is shown on the 3rd line, includes one or more "TP_ sequences", each of which is a sequence of Source packets. "TPO_sequence" is a sequence of Source packets where the Receipt Timers (TPO) referenced by the Arrival_TimeStamps are included in the TPO_Sequence and do not include “breaking the time axis of the receipt”. In other words, “TP_Sequence” is a sequence of Source packets, where the Receipt_Timers referred to by the Receipt_Times included in the TP_Sequence are continuous.

Such TV_ sequences consist of an audio / video clip and are recorded on the BD-ROM with the file name “xxxxx.m2ts”.

An audio / video clip, as is the case with regular computer files, is divided into one or more continuous parts (extents) of the file, which are then recorded in an area on the BD-ROM. The 4th line shows how the audio / video clip is recorded on the BD-ROM. On the 4th line, each contiguous portion of the file making up the file has a data size that is equal to or larger than a predetermined size, called the S-band.

The S-band is the minimum data size of each contiguous portion of a file, the audio / video clip being divided into a plurality of contiguous portions of the file to be recorded.

Assume that the time it takes for the optical head to go to the position on the BD-ROM is obtained from the following equation:

Transit_Time = Access_Time + Delay_Time.

"Access_Time" is the required time, which is consistent with the transition distance (distance to the physical address of the transition destination).

The TP packets read from the BD-ROM are stored in a buffer called a read buffer, and then output to a decoding module. "Cost-time" is obtained from the following equation if the input to the read buffer is performed at a bit rate called Rud and the number of sectors in the ECC block is represented by Secc:

Delay_time ≤ (2 × Secc × 8) / Rud = 20 ms.

The TP packets read from the BD-ROM are stored in the read buffer in the form of Source packets and then fed to the decoding module with a transmission speed called "TP_Record_Rate".

In order to keep the transmission rate equal to TP_Record_Speed, while TP packets are supplied to the decoding module, it is necessary that during the Transition_Time TP packets are continuously output from the read buffer to the decoding module. In the present description, Source packets, not TP packets, are output from the read buffer. As a result, if the ratio of the sizes of the TS packet to the Source packet is 192/188, it is necessary that during the Transition Time the Source packets should be continuously output from the read buffer with the transmission rate "192/188 × TP_Record_Rate".

Accordingly, the amount of occupied buffer capacity of the read buffer, which does not cause emptying, is represented by the following equation:

Buffer_fill ≥ (Transition_time / 1000 × 8) × ((192/188) × TP_Record_Speed).

The intensity of the incoming stream to the read buffer is represented as Rud, and the intensity of the outgoing stream from the read buffer is represented as Write_TP Speed × (192/188). Therefore, the fill rate of the read buffer is obtained by executing "(incoming flow rate) - (outgoing flow rate)", and thus, is obtained by "(Rud - TP_Record_Speed) × (192/188)".

The time "Tx" required to fill the read buffer using "Fill buffer" is obtained from the following equation:

Tx = Buffer_Fill / (Rud - TP_Record_Speed × (192/188)).

Reading from the BD-ROM, it is necessary to continue to input TP packets with a data rate of Rud in the “Tx” time period. As a result, the minimum data size S-range of each continuous part, if the audio / video clip is divided into many continuous parts of the file that must be recorded, is obtained from the following equations:

S-range = Rud × Tx

= Rud × Buffer_fill / (Rud - TP_Record_Speed × (192/188))

≥ Rud × (Transition_time / 1000 × 8) × ((192/188) × TP_Record_Speed) / (Rud - TP_Record_Speed × (192/188))

≥ (Rud × Transition_time / 1000 × 8) × TP_Record_Speed × 192 / (Rud × 188 - TP_Record_Record × 192].

Hence,

S-band ≥ (Transition_Time × Rud / 1000 × 8) × (TP_Record_Speed × 192 / (Rud × 188 - TP_Record_Speed × 192)).

If each continuous part of the file that makes up the audio / video clip has a data size that is equal to or larger than the S-band, which is calculated as a value that does not cause the decoding module to be empty, even if the continuous parts of the file that make up the audio / video clip are located on a BD-ROM discrete, TP packets are continuously fed to a decoding module so that data is read continuously during playback.

FIG. 5 shows the relationships between the physical BD-ROM module and the Source packets constituting one contiguous portion of the file. As shown in row 2, many sectors are formed on the BD-ROM. The source packages that make up the contiguous part of the file, as shown in line 1, are divided into groups, each of which is composed of 32 Source packages. Each group of Source packets is then written into a set of three consecutive sectors. A group of 32 Source packets is 6144 bytes (= 32 × 192), which is equal to the size of three sectors (= 2048 × 3). The 32 Source Packages stored in these three sectors are called the Aligned Module. Writing to the BD-ROM is performed in units of Aligned Modules.

In the 3rd line, an error correction code (ECC) is assigned to each block of 32 sectors. The block with the error correction code is referred to as the ECC block. Since there is access to the BD-ROM in units of Aligned Modules, the playback device can receive 32 complete Source packets. So far, the process of recording an audio / video clip on a BD-ROM has been described.

<Types of Elementary Streams>

FIG. 6 shows elementary streams that are combined into an audio / video clip.

As shown in FIG. 6, combined into an audio / video clip: a video stream with high image quality having a packet identifier (IP) 0x1011; Primary audio streams having IP identifiers from 0x1100 to 0x111F; CGP streams having IP identifiers from 0x1200 to 0x121F; and SGI streams having IP identifiers from 0x1400 to 0x141F. The packets constituting the elementary streams are assigned corresponding IPs and are demultiplexed based on the identifiers of the IPs. Subsequently, the audio / video clip into which such a video stream with high image quality is multiplexed is called the “Main Clip”, and the audio / video clip that is played simultaneously with the Main Clip is called the “Subclip”.

<BD-ROM 2 Structure: Clip Information>

Next, files that are assigned the extension "clpi" will be described. A file (00001.clpi), which is assigned the extension "clpi", stores the Clip information. Clip Information is the management information for each audio / video clip. FIG. 7 shows the internal structure of the Clip information. As shown on the left side of the drawing, the Clip information includes:

i) “Clip Information ()”, storing information regarding the audio / video clip;

ii) "Sequence Information ()" storing information regarding the TPo sequence and CT sequence;

iii) "Program Information ()" storing information regarding the Program Sequence; and

iv) "Characteristic Point Information (CPI ())."

“Clip Information” includes “application_type” indicating the type of audio / video clip application that is mentioned in the Clip information. "TP_Record_ Speed", which indicates whether the content is video data or still pictures (slide show), is system information about the bit rate of the audio / video clip.

Sequence Information is information regarding one or more CT sequences and TPO Sequences contained in an audio / video clip. This information is provided to pre-notify the playback device of a break in the system time axis and a break in the arrival time axis. That is, if such a gap is present, there is a possibility that the VMP and VMA, which have the same value, are detected in the audio / video clip. This may result in poor quality playback. Sequence information is provided to indicate where and where in the transport information stream CT or TPo follow.

Program information is information that indicates the section (called "Program Sequence") of the program where the content is persistent. Here, the "Program" is a group of elementary streams that share a common time axis for synchronized playback. This Program Information is provided to pre-notify the playback device of the point at which the contents of the Program change. It should be noted that the point at which the contents of the Program changes is, for example, the point at which the IP of the video stream changes, or the point at which the type of video stream changes from SDTV to HDTV.

Next, Characteristic Point Information (CPI) will be described. The directional line cu2 indicates a detailed image of the structure of the ICT. As the directional line cu2 shows, the ИХТ is composed of the number of Ne cards_TV_for_one_one_IP_flow_IP: (card_TV_for_one_one_IP_flow_0 [0] ... card_TV_for_one_ one_flow_IP [Ne-1]). These TV__ cards for one_ Stream_IP_ are maps of entry points (TV_ cards) of elementary streams that are part of an audio / video clip. Card_TV is information that indicates, together with the time of entry (VMP_ begin_TV), the number of the packet (NPP_ begin_TV) at the entry position in the case when the Access Module is present in one elementary stream. The directional line cu3 in the drawing indicates a detailed image of the internal structure of the card_TV_for_ one_IP_flow.

From this it is clear that the card_TV_for_ one_IP_flow_ is composed of the number Ne Upper_TV (Upper_TV (0) ... Upper_TV (Ne-1)) and Nf Lower_TV (Lower_TV (0) ... Lower_TV (Nf-1)). Here, Upper_TV plays the role of indicating the high bits of the NPL_start_TV and VMP_start_TV of the Access Module (I-image without IDR, IDR image), Lower_TV plays the role of indicating the low bits of the NPL_start_TV and VMP_start_TV of the Access Module (I-image without IDR, IDR image).

The directional line cu4 in the drawing indicates a detailed image of the internal structure of Upper_TV. As the directional line cu4 shows, Upper_TV (i) is composed of: "link_to_Identifier_Lower_TV [i]", which is the reference value for Lower_TV; "VMP_Upper_TV [i]", which indicates the high bits of the VMP Access Module (I-image without IDR, IDR-image); and "UPC_Upper_TV [i]", which indicates the high bits of the NCC Access Module (I-image without IDR, IDR-image). Here, “i” is the identifier of this Upper_TV.

The directional line cu5 in the drawing indicates a detailed image of the Lower_TV structure. As the directional line cu5 shows, Bottom_TV (i) is composed of: "is_or_point_of_changing_view (identifier_Lower_TV)", which indicates whether the corresponding Access Module is an IDR image; "Offset_item_end_I-image (identifier_Lower_TV)", which indicates the size of the corresponding Access Module; "Lower_TV_VMP_ (Lower_TV_ID)", which indicates the lower bits of the Access Module VMP (I-picture without IDR, IDR-picture); and "NPV_Lower_TV (identifier_Lower_TV)", which indicates the lower bits of the NPP Access Module (I-image without IDR, IDR-image). Here, "Lower_TV_ID" is an identifier for identifying a given Lower_TV.

<Clip Information Explanation 2: TV_ Map>

Here, TV_map will be explained by a typical example. FIG. 8 shows the settings of the card_TV on the movie video stream. The 1st line shows a lot of images (IDR image, I-image, B-image and P-image specified in MPEG4 audio / video clip). The 2nd line shows the time axis for the images. The 4th line shows the sequence of packets, and the 3rd line shows the settings of the card_TV.

It is assumed that on the time axis in the 2nd row, an IDR image or I-image is present at each time instant t1 ... t7. The interval between adjacent times t1 ... t7 is approximately one second. The TV_card used for the movie is a setting for indicating t1 - t7 as the input times (TMP_T_START_) and indicating the position of the input (NTP_START_TV) together with the input times.

<Playlist Information>

Next will be described the information of the Playlist. The file (00001.mpls), which is assigned the extension "mpls", is a file storing information from the Playlist (ST).

FIG. 9 shows a data structure of information of a Playlist. As shown by the directional line mp1 in FIG. 9, the information of the Playlist includes: Information of the Main Path (Main_Tract ()), which defines the Main Path; and PlayList Tag information (PlayList_Label ()), which defines the chapter.

<Explanation of Play List Information 1: Main Path Information>

First, the Main Path will be described. The Main Path is the presentation path, which is defined in terms of the video stream as the main image and audio stream.

As indicated by the arrow mp1m, the Main Path is defined by a plurality of pieces of information of the Playlist: Information_Item Playback # 1 ... information_Item Playback # m. Information_Item_Playback defines one or more logical sections of the reproduction, which make up the Main Path. The directional line hs1 in the drawing indicates a detailed image of the information structure of the Playback Element. As shown by the hs1 directional line, the Information of the Playback Element is composed of: "Clip_Information_file_name" indicating the name of the information file of the playback section of the audio / video clip to which the INPUT and the EXIT point of the playback section belong; "Clip_codec identifier", which indicates a method for encoding an audio / video clip; "is_or_multi-angle", which indicates whether the Playback Element is multi-angle; "join_condition", which indicates whether the current Playback Item and the previous Playback Item are seamlessly connected; "ST__ID_ID [0]", which uniquely indicates the ST_Sequence designated by the Playback Element; "Entry_time", which is time information indicating a starting point of a playback section; "Exit_time", which is time information indicating the end point of a playback section; "DP_mask_table", which indicates which user action (DP) should be masked in accordance with the Playback Element; a "random_access_to_to_playback_element" flag, which indicates whether random access to the midpoint in the playitem is permitted; "Screensaver mode", which indicates whether the display of the last image continues after playback of the Playback Item is completed; and "STN_table". Among them, the temporary information “Entry_time” indicating the start point of the playback section, and the temporary information “Exit_time” indicating the end point of the playback section, constitute the presentation path. The presentation path information is composed of "ENTRY_TIME" and "EXIT_TIME".

FIG. 10 shows the relationships between the audio / video clip and the Playlist information. The 1st line shows the time axis contained in the information of the Playlist. 2nd - 5th lines show the video stream to which the map_TV belongs.

The information of the Playlist includes two parts of the information of the Playback Element: Information_Item_Playback # 1 and information_Item_Playback # 2. The two playback sections are defined by "ENTRY_Time" and "EXIT_Time" included in the information of the Playback_Element # 1 and the Playback_Element # 2 information. If these playback sections are ordered, the time axis is set different from the time axis of the audio / video clip. It is the time axis of the Playlist, which is shown in the 1st row. As is clear from this, it is possible, by setting the information of the Playback Element, to set the presentation path different from the audio / video clip.

The above Clip information and Playlist information are classified as “static script”. The fact is that the Clip information and the Playlist information define the Playlist, which is a static playback module. This completes the description of the static scenario.

In the future, the "dynamic scenario" will be explained. The dynamic scenario corresponds to the scenario data, which dynamically determine the playback control of the audio / video clip. Here, “dynamically” means that the essence of the change in the playback control is caused by a change in the state of the playback device or is the result of pressing the button by the user. BD-ROM provides two modes of operating environment for playback control. The first operating environment resembles that of a DVD and is a command-based runtime. Another is the Java ™ virtual machine operating environment. The first operating environment is called the HDMV mode. The second operating environment is called the BD-J mode. Due to the fact that these two operating environments are accessible, a dynamic script has been written to satisfy one of these operating environments. A dynamic script written to satisfy the HDMV mode is named “Object Movie”, and a dynamic script written to satisfy the BD-J mode is called “Object BD-J”.

First, the Movie Object will be described.

<Movie Object>

The Movie object is stored in the file "MovieObject.bdmv", which is shown in FIG. 2, and includes a navigation command sequence.

A navigation command sequence is a sequence of navigation commands that perform a conditional transition, setting the state register in the playback device to a certain state, requesting a set of values in the state register, and so on. The following navigation commands can be recorded in the Movie Object.

PlayPL team

Format: PlayPL (1st parameter, 2nd parameter)

The 1st parameter is the number of the Playlist for specifying the Playlist to be played. As the 2nd parameter of the Playback item included in the Playlist, the time in the Playlist, Chapter or Mark is given to specify the starting position of the play.

The PlayPL function using the Playback Element to set the start position of the playback on the time axis of the CB is referred to as "PlayPLatPlayItem ()".

The PlayPL function, which uses the Chapter to establish the starting position of the playback on the time axis of the CB, is referred to as "PlayPLatChapter ()".

The PlayPL function, using time information to establish the starting position of the playback on the time axis CB, is referred to as "PlayPLatSpecifiedTime ()".

The format for recording a navigation command in a Movie Object resembles the format for recording a navigation command on a DVD. This allows you to efficiently transfer disc content from DVD to BD-ROM. The following international publication, as prior art, discloses the Object of the Film. Please refer to this international publication for the details of the Movie Object.

International Publication: WO 2004/074976

The Movie Object has so far been described. The following describes the BD-J Object.

<BD-J Object>

The BD-J object is a dynamic BD-J mode script that is written in the Java ™ programming environment and stored in the file "00001.bobj". A BD-J object differs from a Movie Object in that it does not contain a command directly written to it. That is, in the Movie Object, the control procedure is explicitly written in the navigation command. In contrast, the BD-J Object defines the control procedure implicitly, in accordance with the technical requirements for Java ™ applications, being recorded in the application management table. Such an implicit description makes it possible to share the control procedure, whereby the control procedure is shared by many dynamic scenarios for efficient execution.

Playing a Playlist using an Object A movie is done by writing a navigation command (PlayPL command) that instructs you to play a Playlist. Playback of the Playlist using the BD-J Object is performed by including the Playlist list management table, which indicates the playback procedures of the Playlist, as part of the BD-J Object.

Java ™ applications in BD-J mode will now be described. It is assumed that the fully installed Java ™ platform in BD-J mode is Java for Portable Devices (J2ME), Personal Basis Profile (PBP 1.0) and Universal MHP Execution Specifications (GEM 1.0.2) for media layout purposes.

Java ™ applications in BD-J mode are managed using the Application Administrator (management tool) through the xlet interface. The xlet interface has four states: loaded, paused, active, and torn.

The Java ™ platform described above includes a standard Java ™ library for displaying image data that complies with JFIF (JPEG), PNG, or a similar format. With this design, Java ™ applications can provide a graphical user interface (GUI) infrastructure that is different from the GUI provided by the HDMV SGI stream. The GUI infrastructure in Java ™ applications includes the home audio and video equipment (HAVi) interaction infrastructure defined in GEM 1.0.2, and the remote control navigation mechanism in GEM 1.0.2.

With this design, Java ™ applications can provide on-screen visualization in which a moving image is displayed on the screen along with buttons, texts, and interactive visualization (BBS content), and actions can be performed on the displayed screen.

The real expression for Java ™ applications is the archived Java ™ file (00001.jar) stored in the BDJA directory located in the BDMV directory, as shown in FIG. 2.

The following international publications disclose Object BD-J as prior art. Please refer to these international publications for details of the BD-J Object.

International Publications: WO 2004/045840 A1

WO 2005/036555 A1

WO 2005/036546 A1

The BD-J Object has so far been described.

<sound.bdmv>

Sound.bdmv will be described. sound.bdmv This is a file for storing audio data that is displayed as click sound when a menu drawn in the SGI stream or the Java ™ GUI infrastructure is enabled (such audio data is referred to as audio data).

FIG. 11 shows the structure of the sound.bdmv file. The sound.bdmv file includes Sound Data () and Sound Index (). Audio Data () includes many pieces of audio data (audio_data (0), audio_data (1) ...). Among these pieces of audio data, audio_data (0) is the sound source for the 1st click sound that is displayed when the menu is activated, and audio_data (1) is the sound source for the 2nd click sound that is displayed when the menu is activated. This audio data is recognized using identifiers called Sound_IDs.

Sound Index () includes: number of sounds (number of sound_records), index for sound_data (0), index for sound_data (1) ...

Each index includes: sound_attributes, which indicate a sound attribute, for example monophonic or stereo; audio_s_ start_address, which indicates the address of the corresponding part of the audio data; and audio_data duration, which indicates the continuous duration of the corresponding portion of the audio data.

As shown in FIG. 2-6, the sources of sounds used in the movie are combined in the audio / video clip as the Primary audio stream. This is done in order to supply the Primary audio stream, which provides sound / voice in the movie, while reading the video stream. On the other hand, the sound.bdmv file, in which the click sound is stored for user actions with the menu, is recorded on the BD-ROM separately from the audio / video clip. Due to the fact that the sound.bdmv file is recorded separately from the audio / video clip, if an audio attempt is made to output during reading the audio / video clip, the optical head switches to reading the sound.bdmv file. When this happens, reading the audio / video clip is interrupted and playback of the audio / video clip is interrupted.

To prevent such an interruption in the playback of the audio / video clip, you must first load the sound.bdmv file into the buffer at the moment when the audio / video clip is not playing. That is, you must first download the sound data from the sound.bdmv file before playing the audio / video clip. This completes the description of the sound.bdmv file.

<Index.bdmv>

Index.bdmv is a table that indicates the Movie Object or BD-J Object that make up the title.

Index.bdmv defines a Movie Object or a BD-J Object, which is a component of the Title.

The following international publication discloses Index.bdmv as prior art. Please refer to the international publication for the details of Index.bdmv.

International Publication: WO 2004/025651 A1

The BD-ROM 100 has so far been described.

<Local Storage Device 200>

The following describes a local storage device 200, which is a recording medium in accordance with the present invention. FIG. 12 shows the internal structure of local storage 200. As shown in FIG. 12, a recording medium in accordance with the present invention can be created by improving the level of applications.

The fourth row in FIG. 12 shows a local storage 200. The third line shows the tracks on the local storage 200. FIG. 12 shows tracks in the form of horizontally propagating, although in reality they form a spiral in the direction from the inner circle to the outer circle of the local storage 200. The tracks include a start region, a volume region, and an end region. The volume region of FIG. 12 has a multi-level model that includes a physical layer, a file system layer, and an application layer. The 1st row in FIG. 12 shows an application layer format (application format) of a local storage device 200, presented as a directory structure.

In the directory structure shown in FIG. 12, under the root directory there is a subdirectory "organization # 1". In addition, the directory "organization # 1" has a subdirectory "disc # 1". The organization # 1 directory is assigned to a particular movie provider. A "disc # 1" directory is assigned to each BD-ROM provided by the vendor.

With this structure, in which the directory assigned to a particular vendor includes directories that correspond to the BD-ROM, the downloaded data for each BD-ROM is stored separately. Similar to the information stored on the BD-ROM, in the subdirectory "disc # 1", the following information is stored: Information of the Playlist ("00002.mpls"); Clip information ("00002.clpi"); audio / video clip ("00001.m2ts"); Object BD-J ("00002.bobj"); Java ™ archive file ("00002.jar"); click sound data ("sound.bdmv") and Movie Object ("MovieObject.bdmv").

The following describes Playlist information, Clip information, and the audio / video clip that are components of the local storage device 200.

<Local Storage Device Structure 200 1: Audio / Video Clip>

The audio / video clip ("00002.m2ts") on the local storage device 200 constitutes a subclip. A subclip is an audio / video clip that includes an elementary stream that is decoded and played simultaneously with the Main Clip. The subclip is classified into “Primary Audio Stream”, “Secondary Audio Stream”, “Graphic Presentation Stream (CGP)” and “Interactive Graphics Stream (CGI)” (hereinafter, the Subclip may also be referred to as Non-Multiplexed Stream).

In the present embodiment, it is assumed that “00002.m2ts” shown in FIG. 12 is a Subclip into which the Secondary audio stream, SGP stream, and SGI stream are multiplexed. In the future, the Secondary audio stream will be described in detail.

<Unmultiplexed Stream 1 Explanation: Secondary Audio Stream>

While the Primary audio stream is an audio stream that includes what is called the primary sound / voice, the Secondary audio stream is an audio stream that includes what is called the secondary audio / voice. When the Subclip is played, the sound / voice for playback is output after the sound / voice of the Primary audio stream is mixed with the sound / voice of the Secondary audio stream. The sound / voice to be included in the Secondary audio stream includes, for example, “comment sound / voice”. If the main sound / voice included in the Primary audio stream is the sound / voice of the movie, and the secondary sound / voice included in the Secondary audio stream is the sound / voice of the director’s comment, the sound / voice of the movie is output after it is mixed with the sound / voice of comment.

The secondary audio stream is recorded only on the local storage device 200 for playback, but not recorded on the BD-ROM. The primary audio stream may be recorded on the BD-ROM and / or on the local storage device 200. The codec for encoding the Primary audio stream may be different from the codec for encoding the Secondary audio stream.

FIG. 13 shows elementary streams that are combined into a subclip. In FIG. 13 SGP streams having IP identifiers "0x1200" - "0x121F", SGI streams having IP identifiers "0x1400" - "0x141F", and Secondary audio streams having IP identifiers "0x1A00" - "0x1A1F" are multiplexed. Here the identifiers of the IPs of the SGP streams and the SGI streams in the Subclip are the same as the identifiers of the IPs of the SGP streams and the SGI streams in the Main Clip, but any of the identifiers of the IP 32 Secondary audio streams is not the same as any of the identifiers of the IP 32 Primary audio streams, as they differ in high byte.

FIG. 14 shows an IP destination map in the BD-ROM standard. According to FIG. 14, “0x0100” is assigned to “program_card”, “0x1001” is assigned to “GP”, “0x1011” is assigned to video stream, area from “0x1100” to “0x111F” is assigned to Primary audio streams, range from “0x1200” to “0x121F” assigned to SGP streams, a region from "0x1400" to "0x141F" is assigned to SGI streams, and a region from "0x1A00" to "0x1A1F" is assigned to Secondary audio streams. As understood from the IP destination map, the area assigned to the Primary audio streams is different from the area assigned to the Secondary audio streams.

FIG. 15A shows the internal structure of the Secondary audio stream. As shown in FIG. 15A, The secondary audio stream is composed of a plurality of frames of audio data. FIG. 15B shows an example of an audio data frame. The secondary audio stream audio data frame includes metadata.

FIG. 15C shows the internal structure of metadata. As shown in FIG. 15C, metadata is composed of “downmix information” and “gain control information”.

Downmix information is downmix information. Downmixing is a conversion in which the number of audio channels is adjusted to be less than the number of encoding channels. The downmix information defines a matrix of transform coefficients for the downmix so that the reproducing apparatus can perform the downmix. For example, down-mix allows 5.1-channel audio to be played on 2 channels.

The gain control information is used to increase or decrease the gain of the outputted audio signal of the Primary audio stream. In the present embodiment, gain control information is used only to reduce gain. FIG. 15D shows an example of gain control information. As is clear from this, the metadata of the Secondary audio stream can weaken in real time the output of the Primary audio stream, which is played simultaneously with the Secondary audio stream. When combining (mixing) the Primary and Secondary audio streams, there is no need to control in real time the gains of the two audio streams. Due to the fact that the Primary and Secondary audio streams in a pair are known in advance, there is only a need for their mixing (combining) in order to reduce the gain of the Primary audio stream without changing the gain of the Secondary audio stream.

It is possible to store only valid gain control information for a length of time starting from the time specified by the "setting_time_stamp" of the Playlist Tag.

FIG. 16 shows how the sound volume of the Primary audio stream is controlled by metadata in the Secondary audio stream. In FIG. 16 The 1st line shows the time axis, the 2nd line shows the playback output signal of the Primary audio stream that can be mixed, the 3rd line shows the playback output signal of the Secondary audio stream and the 4th line shows the metadata included in the Secondary audio stream.

The metadata located in the audio data frame, which corresponds to the playback time t1, suppresses the sound volume of the playback output signal of the Primary audio stream as a whole. The metadata located in the audio data frame, which corresponds to the playback time t2, restores the sound volume of the playback output signal of the Primary audio stream. With such a distribution in which the metadata is located at the playback times t1 and t2, it is possible to avoid a situation in which the sound volume of the output signal of the Primary audio stream is combined with the sound volume of the output signal of the Secondary audio stream, which leads to damage to the speaker.

If the correction of the gain during mixing is performed in real time using the information of the gain control of the Secondary audio stream, it is only necessary to determine for the gain control information stored in each frame of the audio data of the Secondary audio stream, which gain of the Primary audio stream is reduced by a predetermined value. This method, which always guarantees proper gain control, is more convenient than, for example, in the case of performing mixed playback by switching between playback times t1 and t2 using special playback.

<Structure of Local Storage Device 200 2: Playlist Information>

Next, Playlist information on the local storage device 200 will be described. The file (00002.mpls) to which the extension “mpls” is assigned is information that defines a Playlist (ST) by combining two types of presentation paths called Main Path and Subtract. FIG. 17 shows a data structure of information of a Playlist. As shown in FIG. 17, the Information of the Playlist includes: information of the Main Path (Main Path ()), which defines the Main Path; Playlist Mark information (Playlist Mark ()), which defines the chapter; and Subtrack information (Subtrack ()), which defines the Subtrack. The internal structures of the Playlist information and the Playback Item information are the same as those on the BD-ROM, and their description is omitted here.

<Explanation of Playlist Information 1: Subtrain Information>

While the Main Path is the presentation path, which is determined on the basis of the Main Clip, which is the Main image, the Subtrack is the presentation path, which is determined on the basis of the Subclip synchronized with the Main path.

FIG. 18 shows the internal structure of the Subtrain information in detail. As indicated by the arrow hc0, each Sub-path includes: Sub-type_type, which indicates the type of the Subclip; and one or more pieces of information of the Play Subitem (... Playback Subitem () ...).

The directional line hc1 indicates a detailed image of the information structure of the Subplayitem. As the directional line hc1 indicates, the Information of the Playback Sub-element includes: "clip_information_file_name", "clip_codec_ID", "ST_Link_ID" [0] "," Entry_Play_Item ",“ Playback_Sync_ ”, and“ Sync_Sync__of_Multiple_Sync_Sync_Sync_Sync_Sync_Sept from

"Clip_information_file_name" is information that uniquely identifies a Subclip that corresponds to the Play Subitem by writing the name of the Subclip information file.

"Clip_Codec_ID" indicates a method for encoding an audio / video clip.

"ST_LINK_ID [0]" uniquely indicates an ST_Sequence, which is the destination of the Playback Element.

"Entry_PartItem_Playback" is information that indicates the starting point of the Playback Subitem on the axis of the playback time of the Subclip.

"Exit_Part_Item_Playback" is information that indicates the end point of the Playback Subitem on the axis of the playback time of the Subclip.

"Synchronization_ID of Playback Element" is information that uniquely sets, among the Playback Elements constituting the Main Path, the Playback Element with which the Playback Subitem should be synchronized. "Entry_Part_Item_Playback" is represented on the playback time axis of the Playback Item specified by the "sync_ID of the Playback_Telement_."

"Synchronization_VMP_first_Play_Play_” indicates the position of the start point of the Play Sub-element specified by the Entry_Play_Play-Sub_Time on the time axis of the Playback of the Playback item specified by the “Sync_ID of the Playback_element."

<Subtract 1 Information Detailing: Subtract_type>

So far, the information has been described. Next will be explained the type_Subpart. The value of Type_Subparture is set from 0 to 255 to indicate the type of Sub-trace, which is determined by the information of the Sub-trace.

If Subtrack type is set to 5, this indicates that the Subtrack defined by the Subtrack information is the presentation path of the Primary audio signal. The presentation path of the Primary audio signal is used when the audio stream to which the Primary audio stream to which the Main Path (Playback Item) belongs before it is played is stored in the Subtrack (Playback Subelement).

If Subtract_type is set to 6, this indicates that the information of the current Subtract determines the presentation path of the Graphics Presentation Tools for adding or replacing. Here, “adding or replacing” refers to adding a CGP stream to CGP streams that can be reproduced using the Information of the Playback Element, or replacing the CGP stream with any of the CGP streams that can be reproduced using the information of the Playback Element.

If Subtract_type is set to 7, this indicates that the information of the current Subtract determines the presentation path for the GUI Tools to add or replace. Here, “adding or replacing" refers to adding an SGI stream to the SGI streams that can be reproduced using the Information of the Playback Element, or replacing the SGI stream with any of the SGI streams that can be reproduced using the information of the Playback Element.

If Subtract_type is set to 8, this indicates that the information of the current Subtract determines the presentation path of the Secondary audio signal to be added. Here, “adding” refers to adding a Secondary audio stream that must be mixed with sound / voice when playing the Primary audio stream that can be played back using the Information of the Playback Element.

For example, when mixed playback of the Primary and Secondary audio streams is performed, two audio decoding modules and two mixing devices must be involved, and therefore, the playback type of the player must be requested in advance, which is different from the case when only a single Primary audio stream is played. In this case, Sub-type_type or IP STN_table are used to notify the player before playing that there is a Secondary audio stream that should be played synchronously with the Primary audio stream.

Up to now, type_Subparture has been described.

<Subtraction 2 Information Detailing: Tripartite Relationships>

It should be noted that the “three sides” mentioned here are Subclip on local storage 200, Play List information on local storage 200, and Main Clip on BD-ROM.

FIG. 19 shows the relationships between the Subclip on the local storage device 200, the Playlist information on the local storage device 200, and the Main Clip on the BD-ROM. In FIG. 19 The 1st line shows the Subclip on the local storage 200. As shown in the 1st line, the Subclip on the local storage 200 is any Secondary audio stream, SGP stream and SGI stream. Any of these streams undergoes synchronous reproduction as a subtree.

The 2nd row in FIG. 19 shows two time axes that are determined by the Playlist information. Of these, the lower time axis is the time axis of the Playback Element defined by the information of the Playback Element, and the upper time axis is the time axis of the Playback Element defined by the information of the Playback Subitem.

As shown in FIG. 19, the "Clip_information_file_name of the Subplayitem_Playback" information of the Playback Subitem indicates one of the ".m2ts" files stored in the STREAM directory to define a playback section for the Subclip.

"Entry_Part_Item_Playback" and "Entry_Time_Sub-element_Playback" play the role of determining the starting point and end point of the playback section.

The arrow "Synchronization_ID_Item_Play_Play_" plays the role of establishing synchronization, namely, specifying the Playback Item to be synchronized. The arrow "synchronization_VMP_first_Item_Play_Playback" performs the role of detecting the position "Entry_Path_Part_Play_" on the time axis of the Playback Element.

FIG. 20 shows the TV_ map and the time axis of the Playback Element that are set for the Main Clip, and the map_TV and the timeline of the Playback Subelement that are set for the Subclip.

In FIG. 20, the middle line and the lines from the lower 4th to the lower 1st show the time axis of the Playback Element, the sequence of images, the time axis of the Main Clip, the map_TV and the sequence of TP packets shown in FIG. 10.

In addition, the lines from the top 1st to top 3rd show the sequence of TP packets, the TV_map and the Subclip time axis, and the top 4th line shows the Sub-element time axis.

So far, the information has been described.

<STN_table>

The STN_table is unique to the information of the Playlist on the local storage device 200. The following describes the information of the Playlist on the local storage device 200.

STN_table is a table that indicates playing streams among the set of elementary streams combined in the audio / video clip specified by the Clip_Information_file_name in the Information of the Playback Element, and among the Unified streams specified in the Clip_Information_file_name in the information. Namely, the STN table is generated by linking the Stream_ attributes to the Stream_ records correspondingly corresponding to the set of elementary streams united in the Main Clips, and Unified streams united in the Subclips.

FIG. 21 shows the internal structure of the STN_table. As shown in FIG. 21, the STN table includes a plurality of pairs (record-attribute) of the STN table and attribute record and shows the number of pairs (number of video stream records, number of audio stream records, number of stream SGP records, number of stream SGI records).

In the STN_table, as indicated by the brackets "{", each entry-attribute pair corresponds to any of the video stream, Primary audio stream, Secondary audio stream, CGP stream and CGI stream that are allowed to be played in accordance with the Playback Element. In particular, it should be noted here that the Stream_record and Stream_attribute pairs in the Secondary audio stream are associated with the Secondary_audible_signal_signal__signal__signal__signal_ audio_information_information.

The attribute record will now be described in detail.

FIG. 22A shows a Stream_ attribute corresponding to a video stream.

The Stream_ Attribute for the video stream includes: "video_format", which indicates a method for displaying the video stream; "frame_frequency", which indicates the display frequency of the video stream; and so on.

FIG. 22B shows Stream_ Attributes corresponding to the Primary Audio Stream and Secondary Audio Stream.

Stream_ Attributes for the Primary and Secondary audio streams include: "stream_encoding_type", which indicates a method for encoding an audio stream; "audio_representation_type" which indicates the channel structure of the corresponding audio stream; "Sample rate", which indicates the sample rate of the corresponding audio stream; and "audio_language_code", which indicates the language attribute of the audio stream.

FIG. 22C shows a Stream_ record for video streams. As shown in FIG. 22C, the Stream_ entry for the video stream includes a “Primary_Clip_ Stream_IP_ID_link” that indicates the UI used to demultiplex the video stream.

The Stream_ Attributes for the Primary Audio Stream, SGI Stream, and SGP Stream, multiplexed in the Main Clip, have the format shown in FIG. 22C.

FIG. 22D shows the Subrecords for streams (hereinafter referred to as Secondary Audio Streams) multiplexed into a Subclip. The Stream_ Record for the Secondary audio stream includes a “Sub_Link_ID_link" that indicates the Sub-stream information that relates to the Secondary audio stream; "Subclip_record_id" link, which indicates the Subclip into which the Secondary audio stream is multiplexed; and a "Subclip_ Stream_IP_ID" link, which indicates the UI used to decompress the Secondary audio stream.

FIG. 22E shows the internal structure of the Secondary_Audio_Connection_ Information_ of the Primary_ Audio signal to which the Stream_ record and Stream_ attribute for the Secondary audio stream are mapped. Primary_Audio_Connection_Information_ of the Primary_ Audio signal is composed of: the number of_record_links_to_ Primary_ audio streams, which indicates, for each Secondary audio stream, the total number of Primary audio streams that can be combined with the Secondary audio streams; and reference_to_ Primary_Audio_ID_ identifier [0] ... [n], which indicate the stream numbers of the Primary audio streams that may be combined during playback.

FIG. 23 shows the requirements for the Primary audio streams in accordance with the Primary Audio_Connection_ Information_ of the Primary Audio_ Signal. In FIG. 23, 32 Secondary audio streams are shown on the right and 32 Primary audio streams are shown on the left. Arrow ym1 indicates the requirements in accordance with Secondary_Audio_Connection_ Information of Primary_Audio_ for Secondary Audio Stream # 1. Thus, the Information_Connection_Secondary_Audio_Signal_ of the Primary_Audio Signal that is assigned to each Secondary audio stream uniquely defines one or more Primary audio streams with which the secondary audio stream playback output can be mixed. This design allows you to set, during development, whether to mix the Secondary audio stream depending on the attribute of the audio signal. For example, it is possible to instruct not to mix the Secondary audio stream during playback with Primary audio streams that have a predetermined attribute, and to prescribe mixing the Secondary audio stream during playback with Primary audio streams that have attributes other than the predetermined attribute.

The Play List information on the local storage device 200 has been explained so far. This completes the explanation of the local storage device 200.

<Virtual Package>

In the future, a virtual package will be described. FIG. 24 shows a virtual packet that is generated by the reproducing apparatus 300. In FIG. 24, the upper left part shows the recorded contents of the BD-ROM, and the lower left part shows the recorded contents of the local storage device 200. In addition, the right part shows the structure of the virtual package.

The playback device receives a virtual file system by combining audio / video clips, Clip information and Playlist information stored on the BD-ROM and on the local storage device 200.

More specifically, for this combination, the playback device:

i) virtually adds a Playlist (00002.mpls) on the local storage device to the MPLS directory on the BD-ROM;

ii) virtually adds the Clip information (00002.clpi) on the local storage device to the CLPI directory on the BD-ROM and

iii) virtually adds the audio / video clip # 2 (00002.m2ts) on the local storage device to the STREAM directory on the BD-ROM.

With the combination described above, a virtual package is generated, shown on the right side of FIG. 24.

The recording medium has so far been described. Next, a playback device will be described.

FIG. 25 shows the internal structure of a reproducing apparatus in accordance with the present invention. A reproducing apparatus in accordance with the present invention is manufactured industrially based on the internal structure shown in FIG. 25. The playback device in accordance with the present invention in General consists of two parts: system LSI (large integrated circuit) and the drive device and can be manufactured industrially by mounting these parts in the housing and on the substrate. System LSI is an integrated circuit in which a variety of processing modules are placed that perform the functions of a playback device. A reproducing device thus manufactured includes: a BD-ROM drive 1a, a bus 1b, read buffers 2a and 2b, demultiplexing units 3a and 3b, a video decoding unit 4, a video plane 5, buffers 6a, 6b and 6c, modules 7a and 7b audio decoding, Downmix / Downsample module 8, mixing modules 9a and 9b, switch 10a, encoding module 10b, interactive Graphics decoding module 11, interactive graphics plane 12, Graphic Presentation decoding module 13, Graphic plane 14 Presentation, JPEG decoding module 15, splash plane 16, combining module 17, CT generation modules 18a and 18b, TV generation modules 19a and 19b, memory 21, control module 22, RUSP set 23, IP conversion module 24, communication module 25 , an operation receiving unit 26 and an HDMI transmit / receive unit 27.

The BD-ROM drive 1a loads / ejects the BD-ROM and accesses the BD-ROM.

The bus 1b carries the TP packets read from the BD-ROM and the TP packets read from the local storage 200.

The read buffer 2a is a reverse store type memory in which TP packets read from the BD-ROM 100 or from the local storage device 200 are stored in a first-in-first out manner.

The read buffer 2b is a reverse store type memory in which the TP packets read from the local storage 200 are stored in a first-in-first out manner.

The demultiplexing module 3a outputs TP packets having IP identifiers, information about which is provided from the IP conversion module 24, from the number of TP packets that are transmitted over the bus and have IP identifiers 0x1011, 0x1100-0x111F, 0x1200-0x121F, and 0x1400-0x141F , to the video signal decoding module 4, the audio signal decoding module 7a, the SGI decoding module 11, and the GPS decoding module 13.

The demultiplexing module 3b demultiplexes TP packets having IP 0x1A00-0x1A1F, namely TP packets constituting the Secondary audio stream, from among TP packets transmitted on the bus 1b. Demultiplexing using demultiplexing module 3b is achieved by comparing the IP control values recorded in the streaming records, which, from the streaming records of the Secondary audio streams contained in the STN table, correspond to the stream numbers stored in RUSP14 with the identifiers of the TP packets transmitted on the 1b bus, and output TP packets that have identifiers of IP, for which a match is found by comparison, to the module 7b decoding the audio signal through the buffer 6b. It should be noted here that if there is only one Secondary audio stream being played back, it is necessary to compare only the high byte “1A” of the control value of the IP recorded in the stream_ record with the high byte “1A” of the IP of the TP packet transmitted via bus 1b. The fact is that since there is no other Secondary audio stream, you need to refer only to the high byte of the IP, which indicates that it is a Secondary audio stream.

If there are many reproducible Secondary audio streams, it is necessary to compare the low byte (value in the range from 0x00 to 0x1F) of the control value of the IP recorded in the stream_ record with the low byte (value in the range of 0x00 to 0x1F) of the IP packet transmitted over the 1b bus in addition to comparing the high byte "1A" of the control value of the IP recorded in the stream_ record with the high byte "1A" of the IP of the TP packet transmitted over bus 1b. The fact is that since there are many Secondary audio streams, it is necessary to refer to the lower byte of the IP to uniquely identify the Secondary audio stream.

Here, since the TP packets read from the BD-ROM and the local storage 200 are transmitted over the bus 1b, the demultiplexing module 3a and the demultiplexing module 3b can consider these TP packets read from the BD-ROM and the local storage 200 as one transport data stream and save them to the buffer as one transport data stream. IPs assigned to TP packets constituting the Primary audio stream are presented in a separate area in the IP destination map, starting from the zone in which IPs assigned to TP packets constituting the Secondary audio stream are presented. With this design, while these TP packets are input as one transport data stream, the demultiplexing unit 3a and the demultiplexing unit 3b can output the Primary audio stream and the Secondary audio stream as different elementary streams. Here, the demultiplexing unit 3a and the demultiplexing unit 3b can supply a plurality of audio streams multiplexed into a single transport data stream to a decoding unit, performing the same procedure as when they were demultiplexed. Accordingly, it is possible for the demultiplexing module 3a and the demultiplexing module 3b to deliver the Primary audio stream and the Secondary audio stream to the corresponding decoding modules in a manner compatible with the demultiplexing module, which demultiplexes only those TP packets that have a predetermined IP from one transport data stream.

It may happen that only one demultiplexing module is provided for installation. In this case, it is also effective to assign different IPs to the Primary audio stream and Secondary audio stream.

So far, the BD-ROM drive 1a, the bus 1b, the read buffers 2a and 2b, and the demultiplexing modules 3a and 3b have been described.

The video decoding unit 4 decodes a plurality of PEP packets received at the output of the demultiplexing unit 3a to obtain uncompressed images, and writes the received images to the video plane 5.

Video plane 5 is a plane for storing uncompressed images. A “plane” is a region of memory in a reproducing apparatus for storing image data of a single screen. The resolution of the video plane 5 is 1920 × 1080. Image data stored in video plane 5 is composed of many pieces of image element data, each of which is represented by a 16-bit YUV value (YUV format: Y is brightness, U, V are color-difference signals).

The buffer 6a stores, in addition to the TP packets received at the output of the demultiplexing module 3a and having IP identifiers in the range from 0x1100 to 0x111F, TP packets having IP identifiers of the audio streams that will be played back using the first-come-first-serve technique, and delivers the stored TP packets to the audio decoding module 7a.

The buffer 6b stores, in addition to the TP packets received at the output of the demultiplexing module 3b and having IP identifiers in the range from 0x1A00 to 0x1A1F, TP packets having IP identifiers of the audio streams that will be played back using the first-come-first-serve technique, and delivers the stored TP packets to the audio decoding module 7b.

Buffer 6c is the memory for preloading the sound.bdmv file that is read from the BD-ROM / local storage device. Preferably, preloading to buffer 6c is performed when the BD-ROM is loaded or when the titles change. The fact is that when you try to read the sound.bdmv file while playing an audio / video clip, the optical head searches to read a file other than the audio / video clip. On the other hand, when the BD-ROM loads or when the titles change, the audio / video clip is difficult to play. Therefore, if the sound.bdmv file is always read, when loading the BD-ROM or when changing the titles, the sensitivity of the device increases, and the playback of the audio / video clip is less prone to interruptions.

The audio decoding unit 7a converts the TP packets stored in the buffer 6a into PEP packets, decodes the PEP packets to obtain uncompressed audio data in the form of LPCM, and outputs the received audio data. This achieves digital output for the Primary Audio Stream.

The audio decoding unit 7b converts the TP packets stored in the buffer 6b into PEP packets, decodes the PEP packets to obtain uncompressed audio data in the form of LPCM, and outputs the received audio data. This achieves the digital output for the Secondary audio stream.

The Downmix / Downsample module 8 converts the digital audio data received at the output of the audio decoding module 7a to match the digital audio data received at the output of the decoding module 7b according to the attributes of the audio signal. Here, the attributes of the audio signal are the sampling frequency and / or the number of channels. This is done for their compatibility with each other. The downmix / downsample module 8 or mix module 9a, according to the gain control information extracted by the audio decoding unit 7b, also performs a gain reduction process on the side of the Primary audio stream in accordance with the metadata multiplexed into the Secondary audio stream.

The mixing module 9a mixes the digital audio data in the form of LPCM obtained at the output of the audio decoding module 7a with the digital audio data in the form of LPCM received at the output of the audio decoding module 7b.

The mixing module 9a mixes the digital audio data in the form of LPCM received at the output of the mixing module 9a with the audio data stored in the buffer 6c. Mixing by the mixing unit 9b is performed when the central processing unit (CPU) 22 decodes a navigation command that is intended to output a click sound, or a byte code that is intended to output a click sound.

The switch 10a switches between (a) delivery, to the audio decoding modules 7a and 7b, the TP packets of the Primary audio stream demultiplexed by the demultiplexing module 3a, and the TP packets of the Secondary audio stream demultiplexed by the demultiplexing module 3b, and (b) “not delivery "to the modules 7a and 7b decoding the audio signal, and the output only elementary streams to other devices. This operation is not the delivery of TP packets of the Primary audio stream to the audio decoding modules 7a and 7b, but the output of only elementary streams to other devices is called “transit output”. A conversion module (not illustrated) that converts TP packets to elementary streams (which removes TP / PEP headers) is integrated in switch 10a.

Encoding module 10b, when LPCM-encoded audio data obtained by decoding with audio decoding module 7a and audio decoding and mixing module 7b with mixing module 9b is sent as surround sound / voice through a digital interface, for example S / PDIF, Encodes and compresses mixed LPCM to Dolby Digital (DD) format or Dolby Theater System (DTS) format.

The Interactive Graphics Decoding (SGI) module 11 decodes the SGI stream read from the BD-ROM 100 or the local storage device 200 and writes the received uncompressed graphic images to the SGI plane 12.

The Interactive Graphics Plane 12 (SGI) is a plane onto which uncompressed graphics obtained using the SGI decoding module 11 are recorded. In addition, symbols or graphics drawn by applications are recorded on the SGI plane 12.

The Graphics Presentation Decoding (GPS) decoding unit 12 decodes the GPS stream read from the BD-ROM 100 or the local storage device 200, and writes the received uncompressed graphic images to the GPS plane 12.

Plane 14 Graphic Representation (CGP) is a plane representing a region of memory for the contents of one screen, and stores the contents of one screen uncompressed graphic images.

The JPEG decoding unit 15 decodes the JPEG data recorded on the BD-ROM 100 or the local storage device 200, and writes the received data to the splash plane 16.

The screen saver plane 16 is a plane onto which uncompressed graphic images obtained by decoding JPEG data are recorded. In addition, symbols or graphics drawn by applications are recorded on the SGI plane 12. The graphic data is used as the “wallpaper” in the graphical user interface (GUI) shell written using the Java ™ application.

The combining module 17 combines the data stored in the CGI plane 12, the data stored in the CGP plane 14, the data stored in the video plane 5, and the data stored in the splash plane 16 to obtain a complex image.

CT generation modules 18a and 18b generate a System Timer (CT) in accordance with the instructions of the control unit 22 and adjusts the execution time of each decoding unit.

The TPO generation modules 19a and 19b generate an Incoming Timer (TPO) in accordance with the instructions of the control unit 22 and adjust the execution time of the operations of the demultiplexing unit. A memory 21 is a memory for storing current CB information and Clip information. The current SV information is the SV information that is currently being processed, among a plurality of pieces of Play List information stored on the BD-ROM. The current Clip information is the Clip information that is currently being processed, among a plurality of pieces of Clip information stored on the BD-ROM / local storage.

The control unit 22 provides BD-ROM playback control by decoding a Java ™ application called a Movie Object or a BD-J Object stored in MovieObject.bdmv, and performing playback of the Playlist according to the decoding result (i.e., playback control according to the current CB information). The control unit 22 also performs the aforementioned TPo control and CT control.

The set of 23 RUSPs is a register built into the playback device and is composed of 64 Player Setup / Status Registers (RUSP) and 4096 general purpose registers (RON). Among the values (RUSP) set in 63 Player Settings / Status Registers, RUSP4-RUSP8 are used to represent the current playback point.

The IP conversion module 24 converts the stream numbers of the Primary audio streams and the Secondary audio streams into IP identifiers, based on the STN table, and provides information about these IP identifiers obtained as a result of the conversion to demultiplexing modules 3a and 3b.

The communication module 25 provides a communication function in a reader. If the URL (unified index of the information resource) is specified by the Java ™ application in BD-J mode, the communication module 25 establishes a TCP connection or an FTP connection to the WEB node using the specified URL. Establishing such a connection enables a Java ™ application to download data from a Web site.

The operation receiving unit 26 receives the user action specifications and provides the User Action information that indicates the action specified by the user to the control unit 22.

The HDMI transmit / receive unit 27 receives from the device connected via HDMI (High Definition Multimedia Interface) information related to the device and transmits digital uncompressed video information obtained by decoding by the video decoding unit 4 to the device via HDMI, together with LPCM audio data.

Still explained the design of the playback device in accordance with the present invention. Next will be explained the software design of the playback device in accordance with the present invention.

The control module 22 shown in FIG. 25 is shown in FIG. 26 as functions. FIG. 26 shows the functions of the control unit 22. As shown in FIG. 26, the control unit 22 includes a Play List processing unit 41, procedure execution units 42 and 43, a mixing control unit 44, and a Tv / CT control module that calls the Tv generation modules 19a and 19b and the Tg generation modules 18a and 18b to generate the Tv and CT, respectively.

These nodes perform processes based on a set of 23 RUSP. The following explains RUSP1, RUSP14 and RUSP31.

<RUSP1>

FIG. 27A shows the distribution of bits in RUS1.

As shown in FIG. 27A, the lower eight bits (b0-b7) of 32 bits of RUS1 represent the stream number and identify the only one of the plurality of Primary audio streams whose entries are listed in the STN table of the current Playback Item. If the set of values in RUS1 changes, the playback device reproduces the Primary audio stream corresponding to the set of values after the change. RUSP1 is set to "0xFF" as the initial value, and then can be set to a value from the range from "1" to "32" by the playback device. The value "0xFF" is an undefined value and indicates that there is no Primary audio stream or that the Primary audio stream has not been selected. If RUSP1 is set to a value from the range "1" to "32", the set of values is interpreted as the stream number of the Primary audio stream.

<RUSP14>

FIG. 27B shows the bit allocation in RUSP14.

As shown in FIG. 27B, the lower eight bits (b0-b7) of 32 bits of the RUSP14 represent the stream number and identify the only one of the plurality of Secondary audio streams whose entries are listed in the STN table of the current Playback Item. If the set of values in РУСС14 changes, the playback device reproduces the Secondary audio stream corresponding to the set of values after the change. РУСС14 is set to "0xFF" as the initial value, and then can be set to a value from the range from "1" to "32" by the playback device. The value "0xFF" represents an undefined value and indicates that there is no Secondary audio stream or that the Secondary audio stream has not been selected. If RUSP14 is set to a value from the range "1" to "32", the set of values is interpreted as the stream number of the Secondary audio stream.

<RUSP31>

FIG. 27C shows the bit allocation in RUSP31.

As shown in FIG. 27C, bits 16-19 (b16-b19) of the 32 bits of the RUSP31 represent the Player Profile information. If bits 16-19 are "0000" b, they indicate that the playback device is shipped during the grace period, where "" b denotes the values of the bits. Here, the grace period is the period during which playback devices can be shipped without predetermined functions. Functions that may be omitted from playback devices sent during the grace period include a function for mixing audio signals. As a result, if bits 16-19 (b16-b19) of РУСС31 are set to “0000” b, namely if the Player Profile information is “0000” b, this indicates that the predefined functions, including the audio mixing function, are not installed in the playback device.

If the Player Profile information is “0001” b, this indicates that the playback device is shipped after a grace period. Since playback devices shipped after the grace period are generally required to be equipped with all the functions provided, the information of the Player Profile, which is “0001” b, indicates that the playback device is equipped with mixing.

If the Player Profile information is “0011” b, this indicates that the playback device is equipped with all the functions provided. Such a playback device is equipped with all the functions regardless of whether it is shipped before or after the grace period. As a result, if the Player Profile information is “0011” b, this indicates that the playback device is equipped with a sound mixing function.

The RUSP may include, as information indicative of the mixing function, information that indicates the number of channels with which the playback device can perform mixing.

Alternatively, the RSSI may include information that indicates the number of output audio channels in the final output signal. For example, if an interface, such as HDMI, is connected for use, the 5.1-channel LPCM audio signal that results from decoding can be output as LPCM. However, if the interface is, for example, S / PDIF, the audio signal is output as 2-channel (Left / Right), and not as 5.1-channel, which requires compression using the encoding module. Accordingly, if it is assumed that the mixing module is accompanied by an encoding module connected to S / PDIF (for example, not connected to HDMI), the number of audio output channels in the final output signal can be set to 5.1 channels. If the mixing module is not accompanied by an encoder, the number of audio output channels in the final output signal after mixing can be set to 2 channels.

So far, a set of 23 RUSP has been described.

Next, a Play List List processing module 41, a procedure execution module 42, and a procedure execution module 43 will be described.

<Functional Design Detail 1: Playlist processing module>

The Playlist List processing module 41 provides SV playback. The Playlist Processing module 41 reproduces portions of the video stream and the Primary audio stream that correspond to the section from the Entry_Time to the _Exit of the Playback Item information, and to be in sync with it, the Playlist List processing module 41 causes an audio signal decoding module 7b to reproduce a portion of the Secondary audio stream that corresponds to the section from the Entry_Sub-Element_Play_Time to the Exit_Sub-Element_Play_ Time of the Sub-Play Information .

FIG. 28 is a flowchart showing a procedure for reproducing a Playlist using the playlist processing module.

In this flowchart, first the current CB information (.mpls) is read (step S101), and then steps S102-S110 are performed. Steps S102-S110 constitute a cycle in which steps S103-S110 are repeatedly performed for each piece of Information of the Playback Element (EV), which make up the current information CB, until there is an assessment of Yes in step S109. In this cyclic process, the Playback Element, which is the object of the process, is referred to as the Playback_ Element # x (EV # x) variable. Playback Element # x is initialized by setting in the initial Playback Element the current CB information (step S102). The condition for ending the cycle is that the Playback Element # x is the last Playback Element of the current CB information (step S109). If it is concluded in Step S109 that the Playback Element # x is not the last Playback Element of the current CB information, the Playback Element # x is set to the next Playback Element in the current CB information (step S110).

In steps S103-S110, which are repeatedly executed in a cyclic process, the Clip information specified by the file_information_file_name of the Playback Element_x # x is read into memory (step S103), the Entry_Rep time_ of the Playback Element_x # x is converted to the I-picture address u using the TV card of the current Clip information 410 (step 10) ), The Entry_Time of the Playback Element # x is converted to the I-image address v using the TV card of the current Clip information (step S105), the I-image address following the I-image address v and the address that precedes hews the received address by one, is assumed to be equal to the address w (step S107), and the BD-ROM 100 or the local storage device 200 are instructed to read the TP packets from the address u of the I-image to the address w (step S108).

On the other hand, a video decoding module or the like receives a command to output data from setting the time_stamp of the current CB Mark to the Exit_Time of the Playback Element # x (step S106). In steps S105-S108, a portion of the audio / video clip specified by the Playback Element # x is reproduced.

After that, it is evaluated whether the Playback Element # x is the last Playback Element of the current CB information (step S109).

If it is concluded in Step S109 that the Playback Element # x is not the last Playback Element of the current CB information, the Playback Element # x is set to the next Playback Element in the current CB information (step S110), and control returns to step S103. Since the above steps S103-S110 are repeated, each piece of EV information that constitutes the current CB information is sequentially reproduced.

<Functional Design Part 2: Module 42 Procedure Execution>

Module 42 of the execution of procedures, if there is a need to replace part of the information of the Playback Element with another, or if the user instructs, by means of an action, to change the stream number, executes the predetermined stream selection procedure and writes a new stream number in РУСС1. The playback device reproduces the Primary audio stream according to the stream number recorded in RUSP1. Thus, the installation of RUSP1 makes it possible to select the Primary audio stream.

The basis for the execution of the flow selection procedure when changing the information of the Playback Element is as follows. Since the STN table is provided in accordance with each piece of information of the Playback Element, it may happen that the Primary audio stream that is reproducible according to the piece of information of the Playback Element cannot be reproduced according to another piece of information of the Playback Element.

The module 42 of the execution of procedures leads to the transition RUSP1 in the state, which is shown in FIG. 29A. FIG. 29A shows a state change of a set of values in RUS1. It should be noted here that in FIG. 29A, the term "valid" means that the value of RUS1 is equal to or less than the number of entries recorded in the STN_ table of the Playback Element, and is decoded.

The term "invalid" means that (a) the value of RUSP1 is "0", (b) the value of RUSP1 is greater than the number of records entered in the STN table of the Playback Element, or (c) decoding is not available even if the number of records entered in the STN table The Playback item ranges from "1" to "32".

The blocks drawn in dashed lines in FIG. 29A, indicate a procedure for determining an RSSI value when a state changes. The procedure for setting the RUSP value is divided into "Procedure when changing playback parameters" and "Procedure when requesting a change in Stream".

A “procedure for changing playback parameters” is a procedure that should be executed if the state of the state reproducing device has changed due to some event that has occurred with the device.

A "Procedure for requesting a change of Stream" is a procedure that should be executed if the user has requested any change (in Fig. 29A "Change Stream").

"Procedure when changing playback parameters" and "Procedure when requesting a change in Stream" are the procedures for selecting a stream and will be described in detail with reference to flowcharts.

The arrows in FIG. 29A symbolically indicate a change in state of the RUSP.

The notes attached to the arrows indicate the events that trigger each state change. That is, FIG. 29A shows that a change in state of the RUS1 occurs if an event such as “Downloading a Disc”, “Changing a Stream”, “Starting Playback of a Playlist”, “Crossing the border of a Playback Item” or “Stopping Playback of a Playlist” occurs. When considering FIG. 29A, it is understood that the above procedures are not performed if a state transition of the type “Invalid -> Invalid” or “Valid -> Invalid” occurs. On the other hand, state transitions of the type "Invalid -> Permissible" and "Permissible -> Permissible" pass through the dotted blocks. That is, the aforementioned “Procedure when changing playback parameters” and “Procedure when requesting a change in Stream” are executed when RUSP1 becomes “Valid”.

The following describes the events that trigger a state change.

The “Disk Download” event indicates that the BD-ROM has been loaded into the playback device. With this load, RUSP1 is immediately set to an undefined value (0xFF). The event "Start Playback of the Playlist" indicates that the playback process has begun, based on the Playlist. When such an event occurs, the "Procedure for changing playback parameters" is executed, and RUSP1 becomes "Valid".

The “Stop playing Playlist” event indicates that the playback process based on the Playlist has been terminated. It is clear that when such an event occurs, the "Procedure when changing the playback parameters" is not executed, and RUSP1 becomes "Invalid".

The event "Change XXX" indicates that the user requested a change XXX (in Fig. 29A Stream). If this event occurs when RUSP1 is "Invalid" (indicated by "cj1" in Fig. 29A), RUSP1 is set to the value that is requested. Even if the value set in this way indicates a valid stream number, the set of values in RUS1 is treated as the value "Invalid". That is, when a state change is triggered by the "Change XXX" event, the RUSP never changes from Invalid to Permissible.

On the other hand, if the "Flow Change" event occurs when RUSP1 is "Valid" (indicated by "cj2" in Fig. 29A), the "Procedure for requesting a change in Stream" is executed, and RUSP1 is set to a new value. Here, the set of values when executing the "Procedure when requesting a change in the Stream" may not be the value specified by the user. The fact is that the "Procedure when requesting a change in the Stream" has the purpose of excluding an invalid value. If the "Flow Change" event occurs when RUSP1 is "Valid", RUSP1 never changes from Valid to Invalid. The fact is that the "Procedure for requesting a change in the Flow" ensures that RUSP1 does not become "Inadmissible."

The event "Crossing the border of the Playback Element" means that the border of the Playback Element has been passed. Here, the boundary of the Playback Element is the boundary between two consecutive Playback Elements, namely the position between the end of the previous Playback Element and the beginning of the next Playback Element between two consecutive Playback Elements. If the event "Crossing the boundary of the Playback Element" occurs when RUSP1 is "Valid", the "Procedure when changing playback parameters" is executed. After executing the “Procedure when changing the playback parameters”, the state of РУСС1 either returns to “Permissible” or switches to “Invalid”. Since the STN_table is provided in accordance with each Playback Item, if the Playback Item changes, the reproduced elementary stream also changes. The change of state is intended to set RUSP1 to the most appropriate value for each Playback Element by executing the "Procedure when changing playback parameters" each time the Playback Element starts to play.

In the above-described state change, the “Procedure for changing playback parameters” is executed as shown in FIG. 29B. FIG. 29B is a flowchart of “Procedures for Changing Playback Parameters”. The procedure sets the value in PSR1 by performing two evaluation steps, S1 and S2.

In step S1, it is judged whether the number of entries in the STN_table is “0”. If it turns out that the number of entries in the STN_table is “0”, the value of RUSP1 is stored (step S3).

In step S2, which is executed if it is determined in step S1 that the number of records in the STN table is not "0", it is judged whether the number of records in the STN table is equal to or greater than the RUSP1, and whether condition (A) is satisfied. Here, condition (A) is for the playback device to be able to play the Primary audio stream defined in RUS1. If the evaluation result in step S2 is positive, the value of RUSP1 is stored (step S4). If either the value of RUSP1 is greater than the number of entries in the STN_table, or condition (A) is not satisfied, the installation process of RUSP1 is performed (step S5).

FIG. 30 is a flowchart showing the detailed procedure of step S5.

In this flowchart, steps S6 and S7 constitute a cycle in which step S8 is repeatedly executed for all Primary audio streams. In this loop, the Primary audio stream that is the object of the process is referred to as the Primary audio stream i. In step S8, it is checked whether the Primary audio stream i satisfies conditions (a), (b) and (c).

Condition (a) is for the reproducing apparatus to be able to play the Primary audio stream i, and whether this condition is satisfied, is evaluated by comparing RUSP15 with the encoding type of the Primary audio stream i stream.

Condition (b) is that the language attribute of the Primary audio stream i is the same as the language installed in the playback device, and if this condition is satisfied, is evaluated by checking whether the audio_ language_code of the Primary audio stream i recorded in the STN_table is equal to specified in RUSP.

Condition (c) is that the channel attribute of the Primary audio stream i corresponds to surround sound and the playback device has the ability to reproduce it, and whether this condition is satisfied is estimated by comparing RUSP15 with the type of presentation_of the audio signal, the type of encoding_ of the stream of Primary audio stream i.

Based on the pattern (i) which conditions, among the set of conditions, satisfy the Primary audio stream i and (ii) how many conditions are satisfied, this flowchart sets the priorities for the Primary audio stream.

After the process is repeatedly performed for all Primary audio streams, steps S9-S13 are performed. At step S9, it is judged whether it is true that there is no Primary audio stream satisfying condition (a). If it turns out that this is true, an indefinite value (0xFF) is set in RUSP1 (step S14).

In step S10, it is judged if there are Primary audio streams that satisfy all conditions (a), (b) and (c). If the result of this assessment is positive, the stream numbers of those Primary audio streams that satisfy all conditions (a), (b) and (c) are set in RUS1.

Here, if there are many Primary audio streams that satisfy all conditions (a), (b) and (c), it is necessary to determine among them one that is installed in RUSP1. This is determined in step S15, based on the order of the entries in the STN table. That is, in step S15, if there are a plurality of Primary audio streams that have the same codec, language attribute and channel attribute, the STN table is accessed and the Primary audio stream is selected, which is the first in the order of the entries in the STN table.

Therefore, it is possible for the person responsible for the development to manage the priority levels of the streams that will be played by changing the order of the entries in the STN_table.

If there is no Primary audio stream that satisfies all conditions (a), (b) and (c), control proceeds to step S11, in which it is evaluated whether there are Primary audio streams that satisfy conditions (a) and (b). If it turns out that there are Primary audio streams that satisfy conditions (a) and (b), the Primary audio stream from among them, which is the first in the order of entries in the STN_table, is set in RUSP1 (step S16).

If there is no Primary audio stream that satisfies all conditions (a), (b) and (c), and there is no Primary audio stream that satisfies conditions (a) and (b), control proceeds to step S12, where it is judged if there are Primary Audio streams that satisfy conditions (a) and (c). If it turns out that there are Primary audio streams that satisfy conditions (a) and (c), the Primary audio stream from among them, which is the first in the order of entries in the STN_table, is set in RUSP1 (step S17).

If there is no Primary audio stream that satisfies all conditions (a), (b) and (c), there is no Primary audio stream that satisfies conditions (a) and (b), and there is no Primary audio stream that satisfies conditions (a) and (c ), control proceeds to step S13, in which it is judged if there are Primary audio streams that satisfy condition (a). If it turns out that there are Primary audio streams that satisfy condition (a), the Primary audio stream from among them, which is the first in the recording queue in the STN table, is set in RUSP1 (step S18).

Until now, the "Procedure for changing playback settings" has been explained. Next will be explained "Procedure when requesting a thread change." FIG. 31 is a flowchart showing a procedure for installing RUSP1 if a flow change is requested. The block diagram of FIG. 31 differs from the block diagram in FIG. 29B in that in some places X is used instead of RUSP1. "X" is a value determined based on the User Action information received at the output of the operations receiving module 26 or a button command received at the output of the graphical representation decoding module 13.

In step S19, the flowchart evaluates whether the number of entries in the STN_table is equal to or greater than X, and whether condition (A) is satisfied. Here, condition (A) is for the reproducing apparatus to be able to reproduce the Primary audio stream determined by RUSP1. This is evaluated by comparing RUSP15 with the primary_ audio stream codec_type_type. If the result of the evaluation in step S19 is positive, X is set to RUS1 (step S21).

If either X is greater than the number of entries in the STN_table, or condition (A) is not satisfied, it is evaluated whether X is 0xFF. Here, if X is not equal to 0xFF, it is considered that the number of the Primary audio stream that the user intends to select is invalid, and the X value that is determined based on the user’s action is ignored, and the set of RUSP1 values is stored (step S23).

If X is 0xFF, RUSP1 is set (step S24). The processing procedure in step S24 is the same as the procedure shown in FIG. 30. (Among the steps shown in Fig. 30, the evaluation in step S9 is not required in the “Procedure for requesting a change in Stream.” The fact is that in the “Procedure for requesting a change in Stream”, if there is no Primary audio stream that satisfies the conditions ( a), (b) and (c), then X, which is set by the user, is not installed in RUSP1, and the set of values of РУСС1 is saved.)

<Functional Design Detail 3: Module 43 Procedure Execution>

Module 43 of the execution of procedures, if there is a need to replace part of the information of the Playback Element with another, or if the user instructs, by means of an action, to change the stream number, executes a predetermined stream selection procedure and writes a new stream number in РУСС14. The playback device reproduces the Primary audio stream according to the stream number recorded in RUSP14. Thus, the installation of RUSP14 makes it possible to select the Primary audio stream.

The module 43 of the execution of the procedures leads to the transition RUSP14 in the state, as shown in FIG. 32A.

FIG. 32A shows the change in state of a set of values in RUSP14. It should be noted here that in FIG. 32A, the term "valid" means that the value of RUSP14 is equal to or less than the number of entries recorded in the STN_ table of the Playback Element, and is decoded.

The term "invalid" means that (a) the value of РУСС14 is equal to "0", (b) the value of РУСС14 is greater than the number of entries recorded in the STN_table of the Playback Element, or (c) decoding is not available even if the number of entries entered in the STN_table The Playback item ranges from "1" to "32".

The blocks drawn in dashed lines in FIG. 32A, indicate a procedure for determining an RSSI value when a state changes. The procedure for setting the RUSP value is divided into "Procedure when changing playback parameters" and "Procedure when requesting a change in Stream".

A “procedure for changing playback parameters” is a procedure that should be executed if the state of the state reproducing device has changed due to some event that has occurred with the device.

A "Procedure for requesting a change in Stream" is a procedure that must be executed if the user requests any change (in Fig. 32A "Change Stream").

"Procedure when changing the playback parameters" and "Procedure when requesting a change in the Stream" are the procedures for selecting a stream and will be described in detail with reference to the flowchart.

The arrows in FIG. 32A symbolically indicate a state change of the RUSP.

The notes attached to the arrows indicate the events that trigger each state change. That is, FIG. 32A indicates that a change in state of the RUSP14 occurs if an event such as “Downloading a Disc”, “Changing a Stream”, “Starting Playback of a Playlist”, “Crossing the Boundary of a Playback Item” or “Change of the Primary Audio Stream” occurs. When considering FIG. 32A, it is understood that the above procedures are not performed if a state transition of the type "Invalid-> Invalid" or "Valid-> Invalid" occurs. On the other hand, a state transition of the type "Invalid-> Permissible" and "Permissible-> Permissible" pass through the dotted blocks. That is, the aforementioned “Procedure for changing playback parameters” and “Procedure for requesting a change in Stream” are executed when the RUSP14 becomes “Valid”.

The following describes the events that trigger a state change.

The “Disk Download” event indicates that the BD-ROM has been loaded into the playback device. With this load, RUSP14 is immediately set to an undefined value (0xFF).

The event "Start Playback of the Playlist" indicates that the playback process has begun, based on the Playlist. When such an event occurs, the "Procedure when changing the playback parameters" is executed, and RUSP14 becomes "Valid".

The “Stop playing Playlist” event indicates that the playback process based on the Playlist has been terminated. It is clear that when such an event occurs, the "Procedure when changing the playback parameters" is not executed, and RUSP14 becomes "Invalid".

The event "Change XXX" indicates that the user requested a change XXX (in Fig. 32A Stream). If this event occurs when RUSP1 is "Invalid" (indicated by "cj1" in Fig. 32A), RUSP14 is set to the value that is requested. Even if a value that is set in this way indicates a valid stream number, the set of values in the RUSP14 is treated as an "Invalid" value. That is, when a state change is triggered by the "Change XXX" event, the RUSP never changes from "Invalid" to "Permissible".

On the other hand, if the "Flow Change" event occurs when the RUSP14 is "Valid" (indicated by "cj2" in Fig. 32A), the "Procedure when requesting a change in the Stream" is executed, and the RUSP14 is set to a new value. Here, the set of values when executing the "Procedure when requesting a change in the Stream" may not be the value specified by the user. The fact is that the "Procedure when requesting a change in the Stream" has the purpose of excluding an invalid value. If the "Flow Change" event occurs when RUSP14 is "Valid", RUSP14 never changes from Valid to Invalid. The fact is that the "Procedure for requesting a change in the Flow" ensures that RUSP14 does not become "Inadmissible."

The event "Crossing the border of the Playback Element" means that the border of the Playback Element has been passed. Here, the boundary of the Playback Element is the boundary between two consecutive Playback Elements, namely the position between the end of the previous Playback Element and the beginning of the next Playback Element between two consecutive Playback Elements. If the event "Crossing the boundary of the Playback Element" occurs when the RUSP14 is "Valid", the "Procedure when changing playback parameters" is executed. After executing the “Procedure when changing playback parameters”, the state of РУСС14 either returns to “Permissible” or, if the event “Crossing the boundary of the Playback Element” or “Changes in the Primary Audio Stream” occurs, it goes into “Invalid”. The change of state is intended to set RUSP14 to the most suitable value for each Playback Element by executing the "Procedure when changing playback parameters" each time the Playback Element starts to play, or each time the Primary Audio Stream changes.

In the above-described state change, the “Procedure for changing playback parameters” is executed as shown in FIG. 32B. The procedure sets the value in RUSP14 by performing two evaluation steps, S31 and S32.

At step S31, it is judged whether the number of entries in the STN_table is “0”. If it turns out that the number of entries in the STN_table is “0”, the value of РУСС14 is stored (step S33).

In step S32, which is executed if it is determined in step S31 that the number of records in the STN table is not “0”, it is judged whether the number of records in the STN table is equal to or greater than the RUSP14, and whether conditions (A) and (B) are satisfied . Here, condition (A) is for the playback device to be able to play the Primary audio stream as defined by РУСС14, and condition (B) is that the combination of Primary_Audio Stream_Number and Secondary_Audio Stream_Number is valid in the STN_table. If the evaluation result in step S32 is negative (NO in step S32), the value of РУСС14 is stored (step S34). If the evaluation result in step S32 is positive (YES in step S32), the installation process of РУСС14 is performed (step S35)

FIG. 33 is a flowchart showing the detailed procedure of step S35.

In this flowchart, steps S36 and S37 constitute a cycle in which step S38 is repeatedly performed for all Secondary audio streams. In this loop, the Secondary audio stream that is the object of the process is referred to as Secondary audio stream i. At step S38, it is checked whether the Secondary audio stream i satisfies conditions (a), (b) and (c).

Condition (a) is for the playback device to be able to play the Secondary audio stream i, and whether this condition is satisfied, is evaluated by comparing the register indicating the ability to play the audio stream (РУСС15) with the encoding type_of the stream of the Secondary audio stream i.

Condition (b) is that the Primary audio stream can be mixed with the Secondary audio stream, and whether this condition is met, is evaluated by checking whether the stream number set in RUSP14 is recorded in the Secondary_audible_signal_ audio__information_ of the Primary_audio signal.

Condition (c) is that the language attribute of the Secondary audio stream i is the same as the language installed in the playback device, and whether this condition is satisfied, is evaluated by checking whether the audio language code of the Secondary audio stream i recorded in the STN table is equal to the set values in RUSP.

Based on the pattern (i) which conditions, among the set of conditions, the Secondary audio stream i satisfies and (ii) how many conditions are satisfied, this flowchart sets the priorities for the Secondary audio stream.

After the process is repeatedly performed for all the Secondary audio streams, steps S39-S41 and steps S44-S46 are performed. At step S39, it is judged whether it is true that there is no Secondary audio stream satisfying conditions (a) and (b). If it turns out that this is true, an indefinite value (0xFF) is set in RUSP14 (step S44).

At step S40, it is judged if there are Secondary audio streams that satisfy all conditions (a), (b) and (c). If this is evaluated positively, the stream numbers of those Secondary audio streams that satisfy all conditions (a), (b) and (c) are set in RUSP14.

Here, if there are many Secondary audio streams that satisfy all conditions (a), (b) and (c), it is necessary to determine among them one that is installed in RUSP14. This is determined in step S45, based on the order of the entries in the STN table. That is, in step S45, if there is a plurality of Secondary audio streams that have the same codec, language attribute and channel attribute, the STN table is accessed and the Secondary audio stream is selected, which is the first in the order of the entries in the STN table.

Therefore, it is possible for the person responsible for the development to manage the priority levels of the streams that will be played by changing the order of the entries in the STN_table.

If there is no Secondary audio stream that satisfies all conditions (a), (b), and (c), control proceeds to step S41, in which it is evaluated whether there are Secondary audio streams that satisfy conditions (a) and (b). If it turns out that there are Secondary audio streams that satisfy conditions (a) and (b), the Secondary audio stream from among them, which is the first in the order of entries in the STN_table, is set in RUSP14 (step S46).

Until now, the "Procedure for changing playback settings" has been explained. Next will be explained "Procedure when requesting a thread change." FIG. 34 is a flowchart showing a procedure for installing the RUSP14 if a flow change is requested. The block diagram of FIG. 34 differs from the block diagram in FIG. 32B, in that in some places X is used instead of RUSP14. "X" is a value determined based on the User Action information received at the output of the operations receiving module 26 or a button command received at the output of the graphical representation decoding module 13.

At step S49, the flowchart evaluates whether the number of entries in the STN table is equal to or greater than X, and whether conditions (A) and (B) are satisfied. If the result of the evaluation in step S49 is positive, X is set to RUSP14 (step S51).

If either X is greater than the number of entries in the STN table, or conditions (A) and (B) are not met, it is judged whether X is 0xFF (step S52). Here, if X is not equal to 0xFF, it is considered that the number of the Secondary audio stream that the user intends to select is invalid, and the X value that is determined based on the user's action is ignored, and the set of RUSP14 values is saved (step S53).

If X is 0xFF, RUSP14 is set (step S54). The processing procedure in step S54 is the same as the procedure shown in FIG. 33. (Among the steps shown in Fig. 30, the evaluation in step S39 is not required in the “Procedure for requesting a change in Stream.” The fact is that in the “Procedure for requesting a change in Stream”, if there is no Secondary audio stream that satisfies the conditions ( a), (b) and (c), then the X that is set by the user is not installed in РУСС14, and the set of values of РУСС14 is saved.)

This completes the explanation of the procedure execution unit 43.

<Functional Design Detail 4: Mix Control Module 44>

The mixing control module 44, if the Player Profile information is 0001h or 0011h, controls the mixing modules 9a and 9b to mix the playback output of the Primary audio stream with the output signal of the Secondary audio stream or the audio data output signal.

When the current playback point on the time axis of the Playback Element is in the time interval from the Entry_to the time_Output information of the Subplayitem, and when the Secondary audio stream is valid in the STN_Table of the information of the current Playback element, the mixing control unit 44 controls the mixing unit 9a to mix the output from the playback unit 7a decoding an audio signal with a playback output signal from an audio decoding unit 7b since the module 7b decoding the audio signal decodes the Secondary audio stream having the stream number stored in RUSP14.

If the primary audio stream attribute is “surround”, the secondary audio stream playback output signal can be mixed after down-mixing, such that only the required components are saved from among the components, such as L, R, C, LS, RS, LR, RR and LFE Here, if the Secondary audio stream is, for example, a comment by the director of the movie, changing the channel of the Primary audio stream with which the Secondary audio stream should be mixed, from L to C and to R, it is possible to give the user the feeling that the director is in reality near the user. This kind of mixing is called panning. When panning, the sound / voice of the Secondary audio stream (for example, monaural) with fewer channels than the Primary audio stream is used.

If the confirmation operation is performed by clicking on the button drawn by the Java ™ application, or if the confirmation operation is performed by clicking on the button drawn by the SGI stream, the mixing control module 44 controls the mixing module 9b to mix the audio data with the output signal of the playback of the Primary audio stream or with the result mixing the output signal of the playback of the Primary audio stream and the output signal of the playback of the Secondary audio stream.

As described above, in accordance with the present embodiment, the demultiplexing unit 3b may receive a TP packet that is transmitted over the bus 1b related to the high byte of the IP and apply the TP packet to the decoding module allocated for the Secondary audio streams. With this design, the demultiplexing unit 3b can only demultiplex the SES packets that make up the Secondary audio stream and feed the SES packets to a decoding module other than the decoding module allocated to the Primary audio streams.

Since it is possible to supply packets that make up the Primary audio stream and packets that make up the Secondary audio stream, respectively, to different decoding modules, it is possible, for example, to downconvert, downmix, or reduce the gain of only the packets that make up the Primary audio stream. This allows you to subject special processes in real time only the packets that make up the Primary audio stream, even when reading the Secondary audio stream from the local storage device 200, while the Primary audio stream is read from the BD-ROM 100, and feed two streams to two corresponding decoding modules .

Second Embodiment

A second embodiment of the present invention relates to selecting a device for decoding a Primary audio stream from a playback device 300 and an audio / video amplifier 500 in a home theater system.

FIG. 35A shows a connection model of a playback device 300, an audio / video amplifier 500, and speakers 600. A connection model in a home theater system is divided into a model in which a playback device 300 is directly connected to speakers 600 without connecting to an audio / video amplifier 500 between them ( connection model (1)), and a model in which the playback device 300 is connected to the speakers 600 via an audio / video amplifier 500 (connection model (2)).

In the first connection model (1), the LPCM obtained by decoding by the reproducing apparatus 300 is supplied to the speakers 600. On the other hand, in the second connection model (2), the reproducing device 300 reproduces only the transit output, and the LPCM obtained by decoding using an audio / video amplifier 500, is supplied to the speakers 600.

The number of channels changes in each device in the home theater system when two or more connection models are available in the home theater system.

FIG. 35B shows how the number of channels varies in each of the reproducing apparatus 300, the audio / video amplifier 500, and the speakers 600. The first row in FIG. 35B shows each of the BD-ROM 100, the reproducing apparatus 300, the audio / video amplifier 500, and the speakers 600. With regard to the ability of these devices to decode, the reproducing apparatus 300 is capable of decoding up to 5.1 channels, the audio / video amplifier 500 up to 7.1 channels and 600 speakers - up to 7.1 channels.

The 2nd-4th lines show which device and how down-mixing is performed when the BD-ROM 100 contains 7.1-channel and 5.1-channel Primary audio streams. The 2nd line shows a situation where the BD-ROM 100 contains a 7.1 channel Primary audio stream, and it is decoded by the playback device 300. In this case, the reproducing apparatus 300 reads the 7.1-channel Primary audio stream from the BD-ROM 100, decodes and down-mixes it to 5.1 channels, and outputs an LPCM corresponding to the down-mix to 5.1 channels. The A / V amplifier 500 converts the LPCM corresponding to down-mix to 5.1 channels to 7.1 channels and outputs the converted 7.1-channel LPCM to 600 speakers.

The 3rd line shows the situation where the BD-ROM 100 contains a 5.1-channel Primary audio stream. In this case, the reproducing apparatus 300 decodes the 5.1 channel Primary audio stream and outputs the LPCM as a result of decoding to the audio / video amplifier 500 without downmixing. The 500 A / V amplifier converts 5.1-channel LPCM to 7.1 channels and outputs the converted 7.1-channel LPCM to 600 speakers.

The 4th line shows a situation where the BD-ROM 100 contains a 7.1-channel Primary audio stream, and it is output by the playback device 300 using the transit output. In this case, decoding is performed by the audio / video amplifier 500, and the 7.1-channel audio / voice, which is the result of decoding the audio / video amplifier 500, is supplied to the speakers 600 and output as sound / voice.

These output signals are compared as follows. In the case of the 2nd line, the playback device 300 converts 7.1-channel audio / voice to 5.1 channels, then the audio / video amplifier 500 converts it from 5.1 channels to 7.1 channels and outputs 7.1-channel audio / voice to 600 speakers. that in this design, the audio stream recorded on the BD-ROM 100 is 7.1-channel, the sound quality of the sound / voice ultimately outputted in the case of the 2nd line is hardly different from the sound quality of the sound / voice ultimately output in case of the 3rd row.

On the other hand, in the case of the 4th row, since the audio / video amplifier 500, which is capable of decoding 7.1 channels, causes decoding of the 7.1-channel audio stream, a high-quality output signal is expected.

In the present embodiment, with this output method, when the device to which the playback device is connected has a playback ability, the playback device transits a signal output so that the device performs decoding.

HDI (Decoding Module Information Block) HDMI is used to determine the degree of playback ability or decoding ability of a paired device or to determine whether to perform stream output. FIG. 36A shows an IDD.

As shown in FIG. 36A, the IDB includes an “Encoding Type” that shows an encoding method by which it is possible to output to an audio / video amplifier 500, “Number of Channels”, which shows the number of channels through which a coupled device can decode, “ Channel / Speaker Distribution ", which shows the location of the speakers, and" Sample Rate ", which shows the frequency at which a paired device can play.

FIG. 36B shows the values that can be set in each IDB field.

In the example of FIG. 36B, the "Encoding Type" line shows decoding methods of DTS-HD, MLP and DD +, by which a coupled device can decode. When actually recording the "Coding Type", four parameters are used: "TK0", "TK1", "TK2" and "TK3". In addition, the line "Number of Channels" shows 5.1k, 7.1k and 2k, which are the number of channels through which a device connected to a pair can decode.

In addition, the “Channel / Speaker Allocation” line shows “L / R / C / LS / RS / LFE”, “L / R / C / LS / RS / LR / RR / LFE” and “L / R”, which indicate the physical placement of the speakers for 5.1k, 7.1k and 2k, respectively.

The Sample Rate line shows the sample rates of 48KHz, 192KHz, and 96KHz.

FIG. 36C shows the sequence of communication lines using the IDU between the playback device 300 and the audio / video amplifier 500.

который, что обозначено как

принимает ИБД от аудио/видео-усилителя 500, который должен быть приемником. Если после обращения к ИБД подтверждается, что аудио/видео-усилитель 500 обладает способностью декодировать Первичный аудиопоток, устройство 300 воспроизведения может выводить Первичный аудиопоток на аудио/видео-усилитель 500 посредством транзитного вывода, что обозначено как

Если аудио/видео-усилитель 500 не обладает способностью декодировать Первичный аудиопоток, то или передается LPCM, декодированный с помощью устройства воспроизведения, или поток не будет воспроизводиться.When the playback device 300 is connected to the audio / video amplifier 500, the HDMI transmit / receive unit 27 of the playback device 300 performs mutual authentication with the audio / video amplifier 500, which is indicated by

which that is designated as

receives an IDU from an audio / video amplifier 500, which must be a receiver. If, after accessing the IDB, it is confirmed that the audio / video amplifier 500 has the ability to decode the Primary audio stream, the playback device 300 can output the Primary audio stream to the audio / video amplifier 500 through a transit output, which is indicated by

If the A / V amplifier 500 does not have the ability to decode the Primary audio stream, then either LPCM decoded by the playback device is transmitted, or the stream will not play.

The following describes the improvement of the playback device to the second embodiment.

FIG. 37 shows the internal structure of RUSP15 in the set of 23 RUSP.

RUSP15 has a length of 32 bits, as was the case with RUSP1, RUSP14 and RUSP31 explained in the first embodiment.

Bits b0-b3 indicate whether the playback device has the ability to decode and play back LPCM audio streams. When the four bits are "0001" b, this indicates that the playback device has the ability to play back LPCM 48 / 96Hz audio streams having the stereo audio attribute. When the four bits are "0010" b, this indicates that the playback device is capable of reproducing 48 / 96Hz LPCM audio streams having a surround attribute. When the four bits are “0101” b, this indicates that the playback device is capable of reproducing LPCM audio streams of any frequency having a stereo sound attribute. When the four bits are “0110” b, this indicates that the playback device is capable of reproducing LPCM audio streams of any frequency having a surround attribute.

The RUS415 bits b4-b7 indicate whether the playback device has the ability to decode and play back DD / DD + audio streams. When the two least significant bits of the four bits are “01” b, this indicates that the playback device is capable of reproducing up to two channels (2k) of main data (independent sub-streams) of the DD / DD + audio streams. When the two least significant bits of the four bits are “10” b, this indicates that the playback device is capable of reproducing many channels (channels, the number of which is more than 2k) of the main data (independent substreams) of the DD / DD + audio streams.

When the two high-order bits of the four bits are “01” b, this indicates that the playback device has the ability to play up to two channels (2k) of extension data (dependent substreams) of the DD / DD + audio streams. When the two high-order bits of the four bits are “10” b, this indicates that the playback device has the ability to play many channels of extension data (dependent sub-streams) of the DD / DD + audio streams.

When the two high-order bits of the four bits are “00” b, this indicates that the playback device does not have the ability to reproduce the extension data (dependent substreams) of the DD / DD + audio streams.

The b8-b11 RUSP15 bits indicate whether the playback device has the ability to decode and play DTS-HD audio streams. When the two least significant bits of the four bits are “01” b, this indicates that the playback device has the ability to play up to two channels (2k) of the main data (Base Substreams) of the DTS-HD audio streams. When the two least significant bits of the four bits are “10” b, this indicates that the playback device is capable of reproducing many channels of the main data (Base Substreams) of the DTS-HD audio streams.

When the two high-order bits are “01” b, this indicates that the playback device has the ability to play up to two channels (2k) of extension data (Extension substreams) of the DTS-HD audio streams. When the two high-order bits are “10” b, this indicates that the reproducing apparatus has the ability to play many channels of extension data (Extension substreams) of the DTS-HD audio streams.

When the two high-order bits of the four bits are “00” b, this indicates that the playback device does not have the ability to reproduce the extension data (Extension substreams) of the DTS-HD audio streams.

The bits B12-B15 RUSP15 indicate whether the playback device has the ability to decode and play back DD / MLP audio streams. When the two least significant bits of the four bits are “01” b, this indicates that the playback device has the ability to play up to two channels (2k) of DD audio streams. When the two least significant bits of the four bits are “10” b, this indicates that the playback device has the ability to play many channels of DD audio streams.

When the two high-order bits of the four bits are “01” b, this indicates that the playback device has the ability to play up to two channels (2k) of MLP audio streams. When the two high-order bits of the four bits are “10” b, this indicates that the playback device has the ability to play many channels of MLP audio streams.

When the two high-order bits of the four bits are “00” b, this indicates that the playback device does not have the ability to play MLP audio streams.

As described above, RUSP15 can determine, for each encoding method, whether the playback device has the ability to process the main data and extension data. Here, “2k” used in the explanation of RUSP15 denotes two channels for left (L) and right (R), respectively.

With such a definition of RUSP15, the control unit 22 in the second embodiment performs playback control of the Primary audio stream in accordance with the flowchart shown in FIG. 38. FIG. 38 is a flowchart showing a processing procedure in the control unit 22 in the second embodiment.

At step S61, it is judged if the device has been activated. If it turns out that the device has been activated, the paired device via HDMI is authenticated (step S62). When the connected devices are successfully mutually authenticated, control proceeds to step S63. Step S63 is a cycle in which it is repeatedly evaluated whether the IDU is received. If it turns out that the IDU has been received (YES in step S63), the control unit 22 recognizes, by referring to the IDU received from the coupled device, the playback ability and the number of speakers (placement) of the coupled device (step S64). Then, in step S65, it is judged whether the paired device has reproducing ability. If it turns out that the coupled device has playback capability, the control unit 22 displays a menu for receiving a request for transit output (step S67) and finds out if the user requested a transit output (step S68).

It should be noted here that if it is revealed, when accessing the IDB, that the device (in many cases, an audio / video amplifier) connected to the speaker has the ability to decode, the transit output can be set automatically (YES in step S68) so that the connected in a couple, the device performed decoding, preventing the user from installing it.

Additionally, it can be preliminarily established that if it is revealed, when accessing the device settings menu (initial settings menu) of the playback device 300, that the coupled device has the ability to decode, then the transit output is set automatically (YES in step S68).

FIG. 39 and 40 show menus for deciding whether to perform transit output. Each menu shown in FIG. 39 and 40, consists of a message that is intended to attract the attention of the user: "In your cinema system, audio decoding is available on the attached target device"; or “You can enjoy high-quality sound when decoding the audio signal on the connected XXX target device,” and the “YES” and “NO” buttons to decide whether to allow the connected target device to decode.

In the message shown in the menu of FIG. 40, “XXX” can be populated with the product name or model number of the audio / video amplifier 500. Or, “XXX” can be populated with the product name or model number of the TV 400 in the same way as those for the audio / video amplifier 500, allowing user to select one of them. This allows the user to select a device that should perform decoding. Additionally, if the user has two or more audio / video amplifiers, it is preferable that the product names and / or model numbers of the audio / video amplifiers be displayed so that the user can select one of them.

When the user confirms by pressing the “YES” button in the menu to give a command for transit output, the Player's ability for the audio signal is set in RUSP15 according to the ISD (step S71), and the module 42 executes the procedures to execute the procedure for selecting the Primary audio stream according to the ability to decode audio a video amplifier 500 (step S72). After that, the Primary audio stream of the audio / video clip read from the BD-ROM is output by the transit output (step S73).

If the user does not take actions to force the audio / video amplifier 500 to perform decoding, the control unit 22 sets the РУСС15 in accordance with the decoding ability of the playback device itself, calls the procedure execution unit 42 to execute the Primary audio stream selection procedure (step S69), and outputs audio / voice (LPCM) decoded by the playback device (step S70).

FIG. 41 and 42 are flowcharts showing procedures for establishing the player's ability to play an audio signal in the RUSP15 in accordance with the IED.

In the flowchart of FIG. 41, in step S200, it is judged whether the IDB indicates. CODING TYPE DD +.

If it turns out that the IDB.CODING_TYPE indicates DD +, control proceeds to step S201, where it is evaluated whether the Number of IDD channels has a value greater than 2. If the evaluation result of step S201 is positive, control proceeds to step S203, where “capacity” Dependent Substream is set to 10b: Surround capable.

If this is evaluated as “NO” in step S201, control proceeds to step S205, in which the “ability” of the Dependent Sub-stream is set to 01b: Stereo-capable.

In the flowchart of FIG. 42, in step S82, it is judged whether the IDB indicates the MLP CODING TYPE. If it turns out that the IDB.CODING_TYPE indicates MLP (YES in step S82), control proceeds to step S91, where it is evaluated whether the Number of IDB channels has a value greater than 2.

If the evaluation result of step S91 is positive (YES in step S91), control proceeds to step S93, where the “ability” of the MLP is set to 10b: Surround-capable. If it is rated “NO” in step S91, control proceeds to step S94, in which the “ability” of the MLP is set to 01b: Stereo-capable.

It should be noted here that although the Number of IDB channels is used in the estimates in steps S201 and S91 in FIG. 41 and 42, Channel / Speaker Distribution may be used instead.

As described above, according to the present embodiment, the ability information of the coupled device is obtained through a digital interface such as HDMI, and the RUSP15 is set according to the received ability information. Additionally, the Primary audio stream is selected from the BD-ROM / local storage device, and the output of the selected Primary audio stream is transited. This allows you to effectively use the capabilities of the decoding module of a coupled device to provide high-quality sound reproduction. Also because audio / video amplifiers and speakers are often designed / sold as a set. In this case, the AV amplifier provides settings that match the characteristics of the speakers. Accordingly, even if the reproducing apparatus can decode using the internal decoding module, it is possible to decode the audio / video amplifier connected to the reproducing apparatus in order to obtain a higher quality reproducing result in terms of acoustics.

Third Embodiment

The local storage device 200 in the first embodiment is a hard disk drive integrated in the reproducing device, while the local storage device 200 in the third embodiment is an SD flash card, which is a portable recording medium. The present embodiment relates to a significant change in the case where a dynamic script is recorded on a portable recording medium for use in a reproducing apparatus.

An SD flash card is a portable recording medium that includes a safe area and an insecure area. Files on the local storage device, such as those shown in the first embodiment, are written to the insecure area after they are encoded, and the encryption key is written to the safe area. An encryption key cannot be read from a secure area unless the reader is authenticated through authentication using an SD card. This design prevents unauthorized copying of files from an insecure area and makes it possible to read files only when the BD-ROM is also available.

A dynamic script is a program, for example, a Java ™ application or a Movie Object, described in the first embodiment, which causes the playback device to perform playback through the information of the Playlist. The dynamic script can be recorded on the BD-ROM 100 or on the local storage device 200. When the dynamic script is recorded on a portable recording medium, this means that the dynamic script is available to any of the playback devices located in different places. Accordingly, the dynamic scenario can be accessed using the playback device 300, which is installed in the car.

FIG. 43A shows a reproducing apparatus 300 mounted in a car. The playback device 300 and the television 400 constitute a car audio system. The portable local storage device 200 may be mounted in the playback device 300 together with the BD-ROM 100.

When the reproducing apparatus 300 is installed in the car, it is preferable to clearly indicate that the reproducing apparatus 300 is controlled like a compact disc (CD) reproducing apparatus. To clearly indicate that the playback device 300 is controlled like a CD player, the RUSP31 in the present embodiment is constructed as shown in FIG. 43B.

FIG. 43B shows the internal structure of the RUSP31 in the third embodiment. When the playback device is installed in the car, the Player Profile information in the RUSP31 in the third embodiment is set to “1000” by the manufacturer’s engineer or end user. When the Profile information in RUSP31 is set to "1000" b, the Profile information indicates that the playback device is being controlled as a Player with an Audio Profile. Here, “Player with Audio Profile” means that the playback device is not suitable for use through an interactive screen, but is controlled like a CD player (that is, the playback device is a BD-ROM playback device that only controls the playback of content in a linear mode like a playback device CDs and is not ready to control the reproduction of content through a GUI or the like, or the playback device temporarily goes into this mode when it is detected that the car is moving).

When the playback device is similar to a CD player, content is played back using operations that are performed in units of chapters, such as skipping a chapter and searching for a chapter. The chapter is determined by the Playlist Tag information shown in FIG. 17.

The following describes the Playlist Tag information.

FIG. 44 shows the internal structure of the information of the Playlist Tag contained in the information of the Playlist. As indicated by the directional line pm0 in the drawing, the Playlist Tag information includes a plurality of pieces of CB Mark information (# 1- # n). Information of the CB Mark (Label CB ()) defines the set position on the time axis of the CB as a chapter point. As indicated by the directional line pm1 in the drawing, the information of the CB Mark includes: "Reference_ID_to_Playback_Item", which indicates the Playback Item that is the subject of the chapter specification; and "timestamp_set", which indicates the position of the chapter in the Playback Element in a temporary representation.

FIG. 45 shows a specification of the position of the chapter by means of the Mark information CB. 2nd to 5th rows in FIG. 45 show the TV_ card and the audio / video clip shown in FIG. 10.

1st Line shows CB Mark information and CB time axis. Two pieces of information Marks CB # 1 and # 2 are shown on the 1st line. Arrows kt1 and kt2 indicate the specifications of the Playback Item using the Identifier_link_to_Playback_ Element in the information of the Tag CB. As is clear from these arrows, the Link_ID_to_Play_Item in the Information of the CB Mark defines the Playback Item that is being accessed. In addition, the time_stamp setting indicates the times of Chapters # 1 and # 2 on the CB time axis. Thus, the CB Mark information identifies segment points on the time axis of the Playback Element.

Until now, the Label information has been described. Next, a significant change in the dynamic scenario will be described.

In the case of a program that is built into the playback device, it is known at the manufacturing stage whether the program is used in a car or in a home theater system. However, in the case of a dynamic scenario (Movie Object, Java ™ application) that is specified by the playback device via the BD-ROM 100 or portable local storage device 200, it cannot be known in advance whether the program is used in a car or in a home theater system. The fact is that the user determines in which playback device the BD-ROM 100 or the local storage device 200, which is an SD flash card, will be used.

Therefore, when the Player Profile information is set up for a specific Player with an Audio Profile, the Movie Object or Java ™ application must control a playback device that needs to be served like a CD player. On the other hand, when the Player Profile information is set differently, it is preferable that the playback device is served through an interactive screen.

FIG. 46 is a flowchart of a Java ™ application processing procedure in the present embodiment.

In step S149, it is judged if the RUSP31 sets a specific player with an audio profile. If the evaluation result in step S149 is negative, the Playlist starts to play (step S150). Then, control proceeds to a loop in step S151.

Step S151 forms a loop waiting for the operation of the Menu call. If it turns out that the menu call has been executed, the menu is displayed (step S152), and steps S153-S156 are performed. In step S153, it is judged whether the focus move action has been performed. If it turns out that the Focus move action was performed, the focus moves to another button (step S155).

At step S154, it is judged whether the confirmation action by the button is performed. If it turns out that the confirmation action by the button has been performed, the process according to the button is executed (step S156).

If it turns out in step S149 that the RUSP31 sets up a specific player with an audio profile (YES in step S149), an Audio Alert Play List is played to notify the user that linear CD-like playback is being performed. Then, control proceeds to a cycle formed from steps S158-S159.

At step S158, it is judged whether a number has been entered. At step S159, it is judged whether the Go To Go button or Go To Go button has been activated.

If it is determined in step S158 that a number has been entered, control proceeds to step S160, in which the segment search function is executed. If it turns out at step S159 that the Go-Forward key or Go-Back key has been activated, control proceeds to step S161, in which the segment skip function is executed.

The example above uses the Java ™ application. When the Movie Object is used, steps S153-S155 are performed using the navigation commands in the SGI stream or the navigation commands of the Movie Object. The steps in this case are similar to those for the Java ™ application, and the explanation is omitted.

The following is an explanation of the chapter search and chapter skipping procedures with links to flowcharts. FIG. 47 is a flowchart showing a segment search procedure.

First, the correspondence of the CB Mark information to the entered value is set to the current CB Label (step S125). Secondly, in step S126, the EV recorded in

Link_ID on the PlayItem_Item is set to the Playback Item # x (step S126). At step S127, the Clip information specified by the Clip_file_name of the Playback Item # x is read. In step S128, setting the time_stamp of the current CB Tag is converted to the u-image address u using the TV_card of the current Clip information.

In step S129, the Output_Time of the Playback Item # x is mapped to the I-image address v using the TV_card of the current Clip information. In step S130, the decoding module receives a command to output data extending from setting the timestamp of the current STB to the Time_Out of Playback Item # x. The search for a chapter has so far been described. The following will explain the omission of the chapter. FIG. 48 is a flowchart showing a procedure for skipping a chapter.

At step S132, it is judged which of the Go_Front and Go_Back keys has been pressed. If it turns out that the Go_Back key has been pressed, control proceeds to step S133, where the direction flag is set to -1. If it turns out that the Go Forward key has been pressed, control proceeds to step S134, where the direction flag is set to +1.

In step S135, the current EM number and the current PTM are converted to set the current NE Label. At step S136, the result of adding the value of the direction flag to the number of the current Mark CB is set to the number of the current Mark CB. Here, in the case of the Go_Front button, the direction flag was set to +1, so the number of the current CB Mark increased; and in the case of the Go_Back button, the direction flag was set to -1, so the number of the current CB Mark decreased. After the CB Tag information is set in this manner, the TP packets are read by performing steps S126-S130, as in FIG. 47.

Until now, the procedure of the reproducing apparatus during reproduction based on the information of the CB Mark has been explained.

As described above, according to the present embodiment, when the RUSP31 is installed in a specific Player with an Audio Profile, a dynamic script, such as a Movie Object or Java ™ application, can be used so that the user can play the Playlist with the speed equivalent to that of a compact playback device disks. With this design, the BD-ROM can be controlled by the user in the same way as a music CD. More specifically, a segment search / skip function corresponds to a song search / skip function on a music CD. In addition, when a dynamic script is run on a playback device that is not installed in the Player with Audio Profile, interactive playback from the GUI menu is available, which will be displayed under the assumption that the images are displayed. In the case where playback is performed through an interface, such as HDMI, which makes it possible to monitor the status of connected devices, the following is available. That is, it is possible to monitor the power of the monitor display ON / OFF or to monitor the selection of the input image supplied to the input, and if it is found that the monitor display does not display reproducible images, the RUSP31 can be installed in the Player with Audio Profile, or playback can be paused, or the device 300 Playback can be turned off along with the monitor display.

Fourth Embodiment

The fourth embodiment relates to how to obtain Playlist information, Clip information or Audio / Video clip information described in the first embodiment. The core of the data collection process is the Java ™ application. The fact is that the Java ™ application has the ability to create a network connection and access the file on the server device.

A connection to request a file from a server can be established using the openConnection method provided in the Java ™ software library called Java ™ .net. The following is an example of such a connection when the file URL on the server is http: //xxx.com/vp_data/0.m2ts.

Example:

new java ™ .net.URL. (http://xxx.com/vp_data/0.m2ts.

openConnection ()

FIG. 49 is a flowchart of a Java ™ application in a fourth embodiment. In step S181, the Playlist from the BD-ROM starts to play. After that, in step S182, “Organization” and “Disk ID” are read from the BD-ROM, where “Organization” is information indicating a corporation or organization that is the distributor of the BD-ROM, and “Disk ID” is the identifier of the BD-ROM .

At step S183, it is judged whether it is true that the local storage device 200 does not have an area corresponding to the Organization or the Drive ID read in step S182.

If it turns out that the local storage device 200 does not have such an area, control proceeds to step S184, in which it is judged whether the Player Profile in the RUSP31 is not “0000” b.

The current process ends if the evaluation result in step S183 or in step S184 is “NO”. If the local storage device 200 does not have an area corresponding to the Organization or the ID of the Disk, and if audio signals can be mixed, the result of the evaluation in both steps, S183 and S184, is “YES”.

If the evaluation result in both steps S183 and S184 is “YES”, a menu having a “refresh button” is displayed (step S185). Then, confirmation of the “update button” is expected (step S186).

FIG. 50 shows an example of displaying a menu having a “refresh button”. In FIG. 50, the Refresh button is the aforementioned “refresh button”. If the confirmation action of the “upgrade button” is performed, the Disc ID and the Play List ID are transmitted to the server device in step S187.

The Disc Identifier is the identification information of the BD-ROM, and the Play List Identifier is the identification information of the reproduced Play List. The server device uses this information to select additional content to be requested in the content provider database. The selected additional content is sent back to the playback device through the network. Additional content includes a number of files (Play List information, Clip information and Audio / Video clip) for recording on the local storage device 200.

At step S188, additional content is expected to be received. If the additional content is received, the control proceeds to step S189, where the Playlist information, the Clip information and the Audio / Video clip constituting the received additional content are recorded on the local storage device 200. After that, if the download from the server device is completed and mixing has become available when playback, the user is notified that mixing is available during playback (step S190). Then, the process enters the wait loop of the user mix request (step S191). If the user requests mixing, control proceeds to step S192, in which the playback of the Playlist is stopped and a virtual package is created.

Contacting the server with a request as to whether the update is available and downloading content for the update can be performed at any time. For example, they can be executed evenly while a disk is loading, or while content is being played. In addition, the user can be interviewed about whether to play the content immediately after the playback is ready to begin (immediately after the virtual package is ready for playback).

As described above, according to the present embodiment, when the Playlist is played from the very beginning, the Audio / video clip is played during the download, and the user can watch the playback picture of the Playlist while waiting for data to be downloaded to the local storage device 200. This is not makes the user bored waiting for data to be downloaded to local storage 200, even if the data is several hundred megabytes in the form of a file n local memory 200.

Here, the condition for removing additional content from the local storage device 200 can be set in the playback device 300 as an initial setting, and the playback device 300 can delete additional content in accordance with this initial setting. For example, it is preferable that the initial setting specifies the reception of time entry and deletion of additional content at a predetermined time (for example, automatic deletion of additional content after one month).

Alternatively, when the BD-ROM is unloaded, the user may be asked whether to remove additional content from the local storage 200, and additional content may be deleted if the user responds positively.

Further, when the BD-ROM is an incomplete disk having a read-only area and a recording area, additional content on the local storage device 200 may be recorded in the recording area of the incomplete disk.

<Additional Notes>

So far, the best embodiment of the present invention has been described, as far as the applicant knows at the time of filing this application. However, further improvements or changes to the present invention may be made depending on subsequent technical issues. It should be noted here that in any case, such improvements or changes are optional and depend on implementing the present invention.

<Required Additional Content Agreement>

Preferably, the playback device is initially configured to remove additional content from the local storage device 200 months or years after it is downloaded.

<Replacement for IP>

In a first embodiment, an IP is used to distinguish between a Primary audio stream and a Secondary audio stream. In the case of using MPEG2-PS instead, it is preferable that the headers of the PEP packets of the Primary audio stream and the Secondary audio stream have different stream identifiers.

It is only required that the Primary audio stream and Secondary audio stream are distinguishable at the system stream level, so that two audio streams are distinguishable for one decompression module. As an option, it is only required that before two streams are combined into one, the IP of one of the streams is changed so that the two streams can be distinguishable.

<Implementation of Management Procedures>

Both the control procedures explained in the above embodiments using the flowcharts and the control procedures of the functional nodes explained in the above embodiments satisfy the requirements of the “invention-program” because the above control procedures are specifically implemented using hardware resources and are a technical idea using natural laws.

■ Production of the Program of the Present Invention

The program of the present invention is an object program that can be executed on a computer. An object program is composed of one or more program codes that direct a computer to perform each step in a flowchart or procedure of functional components. There are various types of program codes, such as native processor code and JAVA ™ bytecode. There are also various forms of implementation of program code steps. For example, when each step can be implemented using an external function, call operators to call external functions are used as program codes. Software codes that implement one step may belong to different object programs. In a RISC processor in which instruction types are limited, each step of the flowchart may be implemented by combining an arithmetic instruction, a logical instruction, a jump instruction, etc.

The program of the present invention can be produced as follows. First, a software developer writes, using a programming language, a source program that implements each flowchart and functional component. In this writing, the software developer uses the class structure, variables, array variables, calls to external functions, and so on, which are consistent with the sentence structure of the programming language that he / she uses.

The written source program is sent to the compiler as files. The compiler translates the source program and generates an object program.

Translation performed by the compiler includes processes such as structural analysis of the proposal, optimization, resource allocation, and code generation. Structural analysis of the sentence analyzes the symbols and expressions, the sentence structure and semantics of the original program, and the original program is converted into an intermediate program. During optimization, the middleware undergoes processes such as setting the base element, analyzing control logic, and analyzing data flows. When allocating resources, to adapt to the instruction sets of the object processor, variables in the middleware are allocated to the register or memory of the object processor. When generating the code, each intermediate command in the intermediate program is converted into program code, and an object program is obtained.

After the object program is generated, the programmer calls the linker. The linker allocates memory areas for object programs and related library programs and links them together to generate a boot module. The generated boot module is based on the assumption that it is read by a computer and instructs the computer to execute the procedures specified in the flowcharts and procedures of the functional components. In this way, the program of the present invention can be produced.

■ Use of the Program of the Present Invention

The program of the present invention can be used as follows.

(i) Use as Firmware

When the program of the present invention is used as an embedded program, the boot module in the form of a program is written to the instruction ROM together with the program of the Basic input / output system (BSVV) and various pieces of middleware (operating system). The program of the present invention is used as the control program of the playback device 300, since the instruction ROM is integrated in the control module and the CPU is executed.

(ii) Use as an Application

When the reproducing apparatus 300 is a model with a built-in hard disk, a Basic Input / Output System (BSVV) program is embedded in the instruction ROM, and various pieces of middleware (operating system) are pre-installed on the hard disk. In addition, a boot ROM is provided in the reproducing apparatus 300 for starting the system from a hard disk.

In this case, only the boot module is supplied to the playback device 300 via the mobile recording medium and / or over the network, and is installed on the hard disk as a single application. This enables the playback device 300 to bootstrap using the boot ROM to start the operating system, and then instruct the CPU to execute the installed boot module as a single application so that the program of this application can be used.

As described above, when the reproducing apparatus 300 is a model with a built-in hard disk, the program of the present invention can be used as a single application. Accordingly, it is possible to separately transmit, lend for temporary use or deliver through the network the program of the present invention.

<Control Module 22>

Components, such as the control module 22 described above in the embodiments, may be implemented as a single system LSI.

System LSI is obtained by performing a silicon crystal on a high density substrate and their arrangement. A system LSI is also obtained by performing multiple silicon crystals on a high-density substrate and arranging them such that many silicon crystals have the appearance of a single LSI (such a system LSI is called a multi-chip module).

System LSI is of type QFP (flat case with terminals on four sides) and type PGA (case with matrix arrangement of pin outputs). In a QFP-type system LSI, contacts are fixed on four sides of the chassis. In a PGA-type system LSI, many pins are fixed across the bottom.

These contacts act as an interface with other circuits. System LSI, which is connected to other circuits through such contacts as an interface, plays the role of the core of the device 300 playback.

The silicon crystal enclosed in the system LSI includes an external interface module, an internal interface module, and a digital processing module. The external interface module digitizes analog signals. The internal interface module converts digital data obtained as a result of discrete processes into an analog format and outputs analog data.

The internal structure components shown in the above embodiments are implemented in a digital processing module.

As described above in the section "Using as an embedded program", a boot module in the form of a program, a program of the Basic input / output system (BSVV) and various parts of the middleware (operating system) are written in the ROM of commands. An important significant change in the embodiments is achieved thanks to the boot module in the form of a program. Therefore, there is the possibility of producing a system LSI of the present invention by composing an instruction ROM in which a boot module is stored as a program in the form of a silicon crystal.

As for the specific implementation method, it is preferable to use the implementation of SoC or the implementation of IC. Implementation of SoC (System on Crystal) is a technology for printing multiple circuits on a chip. The implementation of the ICS (System in Enclosure) is a technology for packaging a variety of circuits using resin or the like. By these technologies, the system LSI of the present invention can be produced based on the internal structure of the reproducing apparatus 300 described in each embodiment above.

It should be noted here that although the term LSI is used here, it can be called IP, LSI, super-LSI, ultra-LSI or the like, depending on the degree of integration.

Additionally, part or all of the components of each playback device can be made in the form of a single crystal. The integrated circuit is not limited to the implementation of SoC or the implementation of IC, but can be obtained using a specialized circuit or universal processor. It is also possible to perform an integrated circuit using FPGA (Programmable Gate Array), which can be reprogrammed after its manufacture, or a processor with a variable structure, which can reconfigure the connection and settings of circuit elements inside the LSI. Moreover, technology for an integrated circuit that replaces LSIs may appear in the near future as the semiconductor technology improves or expands into other technologies. In this case, a new technology may be included in the integration of the functional blocks constituting the present invention, as described above. Such possible technologies include biotechnology.

INDUSTRIAL APPLICABILITY

The recording medium and playback device in accordance with the present invention can be produced in series based on their internal structures shown in the embodiments above. As such, the recording medium and playback device in accordance with the present invention have industrial applicability.

Claims (20)

1. The recording medium onto which the playlist information and the audio stream are recorded, wherein
playlist information contains main path information and subtree information,
main path information sets one of a plurality of digital streams as the main stream and determines a main playback section for the main stream,
the subtree information sets another of the plurality of digital streams as a substream and determines, for this substream, a playback sub-section to be synchronized with the main playback section,
the main stream includes a video stream and a primary audio stream multiplexed therein,
an audio stream is defined as a sub-stream and includes a plurality of packets, each of which is attached a packet identifier that includes an upper field and a lower field, and
the upper field indicates that the audio stream is a secondary audio stream, and the reproduced output of the secondary audio stream is mixed with the reproduced output of the primary audio stream. 2. The recording medium according to claim 1, in which the lower field of the packet identifier indicates the corresponding audio stream, which is one of many secondary audio streams. 3. The recording medium according to claim 1, in which
the main path information includes a stream table that contains records correspondingly corresponding to the secondary audio streams,
each entry in the stream table contains a control value of the packet identifier corresponding to the secondary audio stream of this record, and
in the flow table, the records are arranged in the order in which the secondary audio streams corresponding to the records are selected. 4. The recording medium according to claim 1, in which each of the recordings correspondingly corresponding to the secondary audio streams is associated with association information that indicates the stream number of the primary audio stream, the reproduced output of which can be mixed with the reproduced output of the secondary audio stream of this record. 5. The recording medium according to claim 1, in which each secondary audio stream includes metadata that performs control of increasing or decreasing the gain of the output audio signal of the primary audio stream. 6. The recording medium according to claim 1, wherein the sub-track information indicates the point in time at which the metadata begins to perform gain control, either as the starting point of the playback sub-section or as the end point of the playback sub-section. 7. The recording medium according to claim 1, wherein the sub-track information includes type information that indicates that the audio stream specified by the sub-channel information itself is a secondary audio stream. 8. A playback device for reproducing the main stream and the substream in accordance with the information of the playlist, while the main playback section is defined for the main stream and the playback subsection is defined for the sub stream
playlist information defines a play section for each of the plurality of digital streams and contains main path information and sub-track information, the playback device comprising
the first reading module, configured to read, in accordance with the information of the main path, one or more packets that make up the main playback section of the main stream,
a second reading module, configured to read, in accordance with the information of the subtree, one or more packets that make up the sub-stream of the sub-stream,
a demultiplexing module, configured to access the upper fields of the packet identifiers respectively contained in the packets read by the first reading module and the second reading module, and to demultiplex the packets into the first packets and second packets, which respectively comprise the primary audio stream and the secondary audio stream,
a first decoding module, configured to decode the first packets constituting the primary audio stream,
a second decoding module, configured to decode the second packets constituting the secondary audio stream, and
an offset unit configured to mix decoding results that are uncompressed digital data, a first decoding unit and a second decoding unit. 9. The playback device of claim 8, in which
the main path information includes a stream table that contains records correspondingly corresponding to the secondary audio streams,
each record in the stream table contains a control value of the packet identifier corresponding to the secondary audio stream of this record,
wherein the playback device contains
a module for executing procedures, configured to select, according to a predetermined procedure, the secondary audio stream to be reproduced from among the plurality of secondary audio streams, and
a status register configured to store the stream number of the selected secondary audio stream, wherein
demultiplexing performed by the demultiplexing module includes comparing the upper field of the packet identifier reference value recorded in the record included in the stream table that corresponds to the stream number and the upper field of the packet identifier read by the second reading module and outputting the packet constituting the secondary audio stream, read by the second reading module, to the second decoding module, if the comparison showed that the two upper fields correspond to each other. 10. The playback device according to claim 9, in which
each record is associated with association information, which indicates the stream number of the primary audio stream, the reproduced output of which can be mixed with the reproduced output of the secondary audio stream of this record,
the status register stores the stream number of the currently playing primary audio stream,
a predetermined procedure for the module execution of the procedures includes an assessment of whether the stream number of the primary audio stream stored in the status register matches the stream number of the primary audio stream specified in the association information, and
the mixing module performs the offset, if it turns out in the specified procedure that the stream number of the primary audio stream stored in the status register corresponds to the stream number of the primary audio stream specified in the association information. 11. The playback device of claim 8, in which
the status register includes a register that stores profile information of the playback device,
profile information indicates whether an offset function is set in the reproducing apparatus,
the mixing module performs the offset if the profile information indicates that the offset function is installed in the playback device, and does not perform the offset if the profile information indicates that the mixing function is not installed in the playback device. 12. The playback device of claim 8, further comprising
a conversion module, configured to perform downmix and / or downsampling with respect to uncompressed digital data that results from decoding the primary audio stream,
wherein the mixing module mixes the outputted audio signal of the secondary audio stream with the result of downmixing and / or downsampling performed by the conversion module. 13. The playback device according to item 12, in which
each secondary audio stream includes metadata, and
the conversion module controls the increase or decrease in the gain of the output audio signal of the primary audio stream in accordance with these metadata. 14. The reproducing apparatus of claim 8, wherein the sub-track information indicates a point in time at which the metadata begins to perform gain control, either as a starting point of a reproducing subsection or as an ending point of a reproducing subsection. 15. The reproducing apparatus of claim 8, further comprising an auxiliary mixing module configured to mix the click sound corresponding to the user action with the reproduced output of the primary audio stream with which the reproduced output of the secondary audio stream was mixed by the bias module. 16. The playback device of claim 8, further comprising
a transmit / receive module, configured to transmit, to the server device, a pair of the identifier of the optical disk and the identifier of the information of the playlist recorded on the optical disk so that the server device transmits information of the playlist based on this pair of identifiers,
playlist information is received by the transmission / reception unit and recorded on the auxiliary recording medium. 17. The playback device of claim 8, in which
when the second reader module reads the plurality of secondary audio streams, the demultiplexing module addresses the lower fields in addition to the upper fields of the packet packet identifiers constituting the plurality of secondary audio streams, detects among the packet identifiers of the packets constituting the plurality of secondary audio streams, one or more packet identifiers, the upper field and the lower field of which are predetermined values, and outputs one or more packets that correspond to aruzhennym one or more packet identifiers, the second decoding unit. 18. The playback device of claim 8, in which
the main path information includes a stream table that has records correspondingly corresponding to secondary audio streams,
each record in the stream table contains a control value of the packet identifier corresponding to the secondary audio stream of this record,
wherein the playback device contains
a module for executing procedures, configured to select, according to a predetermined procedure, the secondary audio stream to be reproduced from among the plurality of secondary audio streams, and
a status register configured to store the stream number of the selected secondary audio stream, wherein
demultiplexing performed by the demultiplexing module includes comparing the upper field and the lower field of the control value of the packet identifier recorded in the entry included in the flow table that corresponds to the stream number and the upper field and lower field of the packet identifier of the packet read by the second reading module, and output of the packet constituting the secondary audio stream, read by the second reading module, to the second decoding module, if the comparison showed that the two upper fields correspond to each other y. 19. A recording method comprising the steps of:
receive information from the playlist, and the information of the playlist contains information of the main path and the information of the subtree, and
write the received information of the playlist to the recording medium, while the main path information sets one of the many digital streams as the main stream and determines the main playback section for the main stream,
the subtree information sets another of the plurality of digital streams as a substream and determines, for this substream, a playback sub-section to be synchronized with the main playback section,
the main stream includes a video stream and a primary audio stream multiplexed therein,
moreover, at the recording stage, when recording information of the playlist on the recording medium, an audio stream specified as a sub-stream is recorded on the recording medium,
wherein the audio stream includes a plurality of packets, each of which is attached a packet identifier that includes an upper field and a lower field, and
the upper field indicates that the audio stream is a secondary audio stream, and the reproduced output of the secondary audio stream is mixed with the reproduced output of the primary audio stream. 20. A playback method for reproducing a main stream and a substream in accordance with the information of the playlist, wherein the main playback section is defined for the main stream and the playback subsection is defined for the sub stream,
playlist information defines a play section for each of the plurality of digital streams and contains main path information and sub-track information, the reproducing method comprising the steps of
read, in accordance with the information of the main path, one or more packets that make up the main playback section of the main stream,
read, in accordance with the information of the subtree, one or more packets that make up the sub-stream of the sub-stream,
refer to the upper fields of the packet identifiers respectively contained in the packets read at the stages of reading the packets, and demultiplex the packets into the first packets and second packets, which respectively comprise the primary audio stream and the secondary audio stream,
decode the first packets constituting the primary audio stream,
decode the second packets constituting the secondary audio stream, and
mixing the decoding results, which are uncompressed digital data, of the first decoding module and the second decoding module.

Images