CN101151671B - Playing apparatus and method - Google Patents

Abstract

A reproduction device, when incorporated in a home theater system, acquires and judges whether a device such as a speaker (600) to be connected to it has reproduction capability via HDMI. If the device to be connected has reproduction capability, the user is asked whether to make the device to be connected to perform decoding through the decoder to be connected. If the user decides to perform reproduction through a decoder to be connected, channel output of a digital story read from a recording medium is performed on HDMI regardless of the recording capability of the local device.

Description

Playing device and method

technical field

The invention relates to audio stream reading technology. the

Background technique

The audio stream reading technology is a technology for allowing a playback device to read a compression-encoded audio stream from a recording medium such as an optical disc, and output the read audio stream to another device. Usually, the playback device is equipped with a decoder for decompressing the compressed coded audio stream, using the decoding of the decoder to obtain digital audio in non-compressed LPCM format, and converting the obtained non-compressed LPCM format digital audio or analog audio The signal is output to another device. the

The TV or speakers in the home theater system take the uncompressed LPCM format digital audio or analog audio signal output from the playback device in this way, and output sound/voice. Documents identified below disclose a prior art for reading an audio stream recorded on a recording medium and playing the read audio stream. the

Document 1: Japanese Patent Application Publication No.2000-228656

Contents of the invention

The problem to be solved by the present invention

However, in some home theater systems, the playback device is connected to an expensive AV amplifier with decoding capabilities. the

Here, this expensive AV amplifier is used by people who love high-quality audio. Therefore, a decoder circuit connected to an expensive amplifier is made of expensive hardware material for preventing noise from occurring. On the other hand, in a decoder circuit embedded in a playback device, low-priced hardware materials are used for circuit boards and the like, thereby providing poor noise immunity. the

Therefore, if the decoding is performed by the playback device instead of the AV amplifier, and the decoding result is output, the output audio has a lower quality with noise even though the decoder on the AV amplifier side is expensive. the

One solution to the above problem is to improve the production line by adding such playback devices that output compressed audio streams, which is aimed at people with such expensive AV amplifiers. However, since the number of such people is small, improving the production line in the above-mentioned manner will increase the burden on product manufacturers. the

Accordingly, an object of the present invention is to provide a playback device that can maximize the capabilities of an expensive AV amplifier when the expensive AV amplifier is included together with the playback device in a home theater system. the

means of solving problems

In order to solve the above problems, the present invention provides a playback device for reading an audio stream in an encoded state from a recording medium and playing the read audio stream. whether it has playback capability; an inquiry unit for inquiring whether the user should perform decoding using a decoder embedded in the connection partner device if the judging unit judges that the connection partner device has playback capability; and a transmission unit, for transmitting the audio stream from the recording medium by keeping the audio stream in an encoded state if the user indicates that decoding should be performed using a decoder of the connection partner device in response to the inquiry to the connected partner device. the

Effect of the present invention

With the above structure, if the user indicates that decoding should be performed using the decoder of the connection partner device, the playback device transmits the audio stream from the recording medium to the connection partner device by keeping the audio stream in an encoded state regardless of the decoding capability of the playback device itself . This enables the AV amplifier connected to the playback device to perform decoding instead of the playback device itself if it is an expensive AV amplifier for high-quality audio and has a decoding capability. With this structure, if the AV amplifier has a decoder that prevents noise from occurring, it is possible to cause the AV amplifier to perform decoding to realize high-quality audio output. the

As described above, when the playback apparatus of the present invention is incorporated into a home theater system that also includes an expensive AV amplifier, it is possible to maximize the capacity of the decoder of the AV amplifier. Therefore, this makes it possible to easily develop and sell such a playback device that can be supported by a wide range of users, including ordinary users as well as users who prefer high-quality audio, without modifying the production line. the

Description of drawings

Fig. 1 shows the use of recording medium of the present invention;

Figure 2 shows the internal structure of BD-ROM;

Figure 3 shows the file structure with the extension "m2ts" appended;

Figure 4 shows the processing that TS packets constituting an AVClip undergo before they are written to a BD-ROM;

Figure 5 shows the relationship between the physical unit of a BD-ROM and the source packages that constitute a file scope;

Figure 6 shows the elementary stream being composited into an AVClip;

Figure 7 shows the internal structure of Clip information;

Figure 8 shows the EP_map settings on the video stream of the movie;

Figure 9 shows the data structure of the PlayList information;

Figure 10 shows the relationship between AVClip and PlayList information;

Figure 11 shows the structure of the file sound.bdmv;

Fig. 12 shows the internal structure of local memory 200;

Figure 13 shows the elementary stream being composited into a SubClip;

Figure 14 shows the PID allocation diagram in the BD-ROM standard;

Figure 15A shows the internal structure of secondary audio stream;

Figure 15B shows an example of an audio frame;

Figure 15C shows the internal structure of metadata;

Figure 15D shows an example of gain control information;

Figure 16 shows how to control the volume of the primary audio stream through the metadata in the secondary audio stream;

Figure 17 shows the data structure of PlayList information;

Figure 18 shows the internal structure of the Subpath (secondary path) information with a close-up;

Figure 19 shows the relationship between the SubClip in the local storage 200, the PlayList information in the local storage 200, and the MainClip in the BD-ROM;

Figure 20 shows the EP_map and PlayItem time axis set for MainClip and the EP_map and SubPlayItem time axis set for SubClip composed of main and secondary audio streams;

Figure 21 shows the internal structure of STN_table;

Figure 22A shows the Stream_attribute corresponding to the video stream;

Figure 22 B shows the Stream_attribute corresponding to the primary audio stream and the secondary audio stream;

Figure 22C shows the Stream_entry of the video stream;

Figure 22D shows the Sub_entry of the secondary audio stream;

Figure 22E shows the internal structure of Comb_info_Secondary_audio_Primary_audio related to a pair of Stream_entry and Stream_attribute of the secondary audio stream;

Figure 23 shows the description of the primary audio stream according to Comb_info_Secondary_audio_Primary_audio;

Fig. 24 shows the virtual package produced by rendering apparatus 300;

Figure 25 shows the internal structure of the reproducing device of the present invention;

Figure 26 shows the function of controller 22;

Figure 27A shows the bit allocation in PSR1;

Figure 27B shows the bit allocation in PSR14;

Figure 27C shows the bit allocation in PSR31;

Fig. 28 is a flowchart showing the PlayList reproduction process performed by the PlayList (playlist) processing unit;

Figure 29A shows the state transition of the value set in PSR1;

Fig. 29B is the flowchart of "process when playback condition changes" in PSR1;

Figure 30 is a flow chart showing the detailed process of step S5;

Figure 31 is a flowchart showing the process for setting PSR1 when a flow change is required;

Figure 32A shows the state transition of the value set in PSR14;

Fig. 32B is the flowchart of "process when playback condition changes" in PSR14;

Fig. 33 is a flowchart showing the detailed process of step S35;

Figure 34 is a flowchart showing the process for setting the PSR 14 when a flow change is required;

Fig. 35 A shows the connection form of reproduction device 300, AV amplifier 500 and speaker 600;

FIG. 35B shows how the number of channels changes in each of the reproducing apparatus 300, the AV amplifier 500, and the speaker 600;

Figure 36A shows the DIB;

Figure 36B shows the values that can be set in each field of the DIB;

FIG. 36C shows a communication sequence using DIB between the reproducing apparatus 300 and the AV amplifier 500;

Figure 37 shows the internal structure of PSR15 in PSR group 23;

Fig. 38 is a flowchart showing the processing procedure of the controller 22 in the second embodiment;

Figure 39 shows a menu for receiving a determination on whether to perform transfer port output;

Figure 40 shows a menu for receiving a determination on whether to perform transfer port output;

Figure 41 is a flowchart showing the process for setting player capabilities for audio in PSR15 according to the DIB;

Figure 42 is a flowchart showing the process for setting player capabilities for audio in PSR15 according to the DIB;

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

Figure 43B shows the internal structure of PSR31 in the third embodiment;

Figure 44 shows the internal structure of the PlayList Mark information included in the PlayList information;

Figure 45 shows the description of the chapter position according to PL Mark information;

Fig. 46 is a flowchart of the processing procedure of the Java ^™ application program in the third embodiment;

Figure 47 is a flowchart showing the process of chapter searching;

Figure 48 is a flowchart showing the process of chapter skipping;

Fig. 49 is a flowchart of a Java ^™ application program in the fourth embodiment;

FIG. 50 shows an example of displaying a menu with an "update button". the

Symbol Description

100BD-ROM

200 local memory

300 reproduction device

400 TV sets

500AV amplifier

600 speakers

1aBD-ROM drive

1b bus

2a, 2b read buffer

3a, 3b demultiplexer

4 video codecs

5 video side

6a, 6b buffer

7a, 7b audio decoder

8 down-mixing/down-sampling

9a, 9b Mixer

10a switch

10b encoder

11Interactive Graphics decoder

12 interactive graphics surface

13 Display Graphics (Presentation Graphics) decoder

14 display graphic surface

15JPEG decoder

16 still image (Still) surface

17 combination units

18a, 18b STC generation unit

19a, 19b ATC generation unit

21 memory

22 controllers

23PSR group

24PID conversion unit

25 communication unit

26 operation receiving unit

27 HDMI sending/receiving unit

41 playlist processing unit

42 process execution unit

43 process execution unit

44 hybrid control unit

Detailed ways

first embodiment

Embodiments of the recording medium of the present invention are described below. First, use of the recording medium of the present invention will be explained. Fig. 1 shows the use of the recording medium of the present invention. In FIG. 1 , the recording medium of the present invention is a local storage 200 . The local storage 200 is used to provide movies to a home theater system including the playback device 300 , the television 400 , the AV amplifier 500 , and the speakers 600 . the

The BD-ROM 100, local storage 200, and playback device 300 will now be explained. the

The BD-ROM 100 is a recording medium in which movies are recorded. the

The local storage 200 is a hard disk embedded in the reproducing apparatus for storing content distributed from a movie distributor's server. the

Playback device 300 is a network-compatible digital home appliance, and has a function of playing back the contents of BD-ROM 100 . The reproducing apparatus 300 can also combine the content downloaded from the movie distributor's server via the network with the content recorded on the BD-ROM 100 so as to expand/update the content of the BD-ROM 100. By the so-called "virtual package" technology, it is possible to combine the content recorded on the BD-ROM 100 with the content recorded on the local storage 200, and it is possible to process the data recorded on the BD-ROM 100 without recording Data on BD-ROM 100. the

So far, the use of the recording medium of the present invention has been described. the

From now on, reproduction of the recording medium of the present invention will be described. The recording medium of the present invention can be obtained by improving the file system on the BD-ROM. Figure 2 shows the file/directory structure of a BD-ROM. In FIG. 2, the file/directory structure of the BD-ROM includes a BDMV directory under the root directory. the

<BD-ROM overview>

Figure 2 shows the internal structure of a BD-ROM. The fourth row of Fig. 2 shows a BD-ROM. The third line shows the tracks on the BD-ROM. Fig. 2 shows the tracks in a horizontally extended state, although actually they are formed helically in order from the inner circumference to the outer circumference. A track includes a lead-in area, a label area, and a lead-out area. The volume label area in Figure 2 has a layer model, including the physical layer, file system layer and application layer. The first line of Fig. 2 shows the application layer format (application format) of the BD-ROM represented by the directory structure. In the first line of Fig. 2, the BD-ROM includes a BDMV directory under the root directory. the

The BDMV directory includes files (“index.bdmv” and “MovieObject.bdmv”) to which the extension “bdmv” is appended. Under the BDMV directory, there are six subdirectories: PLAYLIST directory, CLIPINF directory, STREAM directory, BDBJ directory, BDJA directory and AUXDATA directory. the

The PLAYLIST directory includes files ("00001.mpls") to which the extension "mpls" is appended. the

The CLIPINF directory includes files ("00001.clpi") with the extension "clpi" appended. the

The STREAM directory includes files ("00001.m2ts") to which the extension "m2ts" is appended. the

The BDBJ directory includes files ("00001.bobj") to which the extension "bobj" is appended. the

The BDJA directory includes files (“00001.jar”) to which the extension “jar” is appended. the

The AUXDATA directory contains files ("sound.bdmv"). the

It can be understood from the above directory structure that various types of files are stored in the BD-ROM. the

<BD-ROM Structure 1: AVClip>

First, a file having the extension "m2ts" will be explained. Figure 3 shows the file structure with the extension "m2ts" appended. A file ("00001.m2ts") to which the extension "m2ts" is appended stores an AVClip. AVClip is a digital stream in MPEG2 transport stream format. Digital streams are generated by converting digitized video and audio (first line above) into elementary streams composed of PES packets (second line above), and converting elementary streams into TS packets (third line above), similarly Convert Presentation Graphics (PG) streams for subtitles, etc. and Interactive Graphics (IG) streams for interactive purposes (first line below, second line below) into TS packets (third line), and then finally composite these TS packets to form a digital stream. the

The PG stream is a graphics stream constituting subtitles written in a certain language. Have multiple streams for multiple languages, such as English, Japanese, and French. The PG stream is composed of function segments such as: PCS (Presentation Control Segment); PDS (Palette Definition Segment); WDS (Window Definition Segment); ODS (Object Definition Segment); and END (Display End Setting Segment). ODS (Object Definition Segment,) is a functional segment that defines a graphic object as a subtitle. the

A WDS is a functional fragment that defines the drawing area of a graphics object on the screen. PDS (Palette Definition Segment) is a functional segment that defines the color for drawing graphic objects. The PCS is a functional piece that defines page control when subtitles are displayed. Such page controls include Insert/Cut, Fade In/Fade Out, Color Change, Scrolling, and Wipe-In/Out. Display effects can be obtained through the page control of the PCS, such as fading out the current subtitle while displaying the next subtitle. the

The IG stream is a graphics stream for gaining interactive control. The interactive control defined by the IG stream is an interactive control compatible with the interactive control on the DVD reproducing apparatus. The IG stream is composed of functional sections such as: ICS (Interactive composition section); PDS (Palette Definition section); ODS (Object Definition section); and END (Display End Settings section). ODS (Object Definition Segment) is a functional segment that defines a graphic object. Buttons on the interactive screen are drawn through multiple such graphics objects. PDS (Palette Definition Segment) is a functional segment that defines colors when drawing graphic objects. ICS (Interaction Composition Snippet) is a functional snippet that realizes a state change in which a button state is changed according to a user operation. The ICS includes a button command that is executed when a confirmation operation is performed on the button. the

An AVClip is composed of one or more "STC_Seuences". "STC_Seuences" is a part of the system time base interval excluding the system clock (STC), which is the system standard time for the AV stream. The system time base discontinuity of the STC is the point at which the discontinuity_indicator of the PCR packet is ON, and the discontinuity_indicator of the PCR packet carries a PCR (program clock reference) for the decoder to refer to to obtain the STC. the

Next, how to write an AVClip with the above structure to a BD-ROM will be explained. Fig. 4 shows the processing that TS packets constituting an AVClip undergo before being written to a BD-ROM. The first line of Fig. 4 shows TS packets constituting an AVClip. the

As shown in the second row of FIG. 4 , 4-byte TS_extra_header (shaded part in the drawing) is appended to each 188-byte TS packet constituting the AVClip to generate each 192-byte source packet. TS_extra_header includes Arrival_Time_Stamp as information indicating the time at which the TS packet is input to the decoder. the

The AVClip shown in the third line includes one or more "ATC_Sequences", each of which is a sequence of source packets. "ATC_Sequence" is the sequence of source packets, and Arrival_Time_Clocks referenced by Arrival_Time_Stamps contained in ATC_Sequence do not include the "Arrival Time Base Break". In other words, "ATC_Sequence" is the sequence of source packets in which the Arrival_Time_Clocks referenced by the Arrival_Time_Stamps contained in the ATC_Sequence are consecutive. the

This ATC_Sequence constitutes an AVClip, and is recorded on the BD-ROM with the file name "xxxxx.m2ts". the

As with normal computer files, AVClips are divided into one or more file extents and recorded in areas on the BD-ROM. The fourth line shows how to record AVClip on BD-ROM. In the fourth line, each file extent constituting the file has a data length equal to or greater than a predetermined length called Sextent. the

Sextent is the minimum data length of each file range, and divides the AVClip into multiple file ranges to be recorded. the

It is assumed here that the time required for the optical pickup to jump to the position on the BD-ROM is obtained by the following equation:

Tjump = Taccess + Overhead. the

"Taccess" is the required time corresponding to the jump distance (distance to the physical address of the jump destination). the

TS packets read from a BD-ROM are stored in a buffer called a read buffer, and then output to a decoder. When the input to the read buffer is performed by a bit rate called Rud and the number of sectors in an ECC block is represented by Secc, "Toverhead" is obtained by the following equation:

Toverhead≤(2*Secc*8)/Rud=20msec. the

The TS packets read from the BD-ROM are stored in the read buffer as source packets, and then supplied to the decoder at a transfer rate called "TS_Recording_rate". the

In order to maintain the transfer rate of TS_Recording_rate while supplying TS packets to the decoder, it is necessary to continuously output TS packets from the read buffer to the decoder during Tjump. Here, source packets are output from the read buffer instead of TS packets. As a result, when the size ratio of TS packets to source packets is 192/188, it is necessary to continuously output source packets from the read buffer at a transfer rate of "192/188×TS_Recording_rate" during Tjump. the

Therefore, the occupancy of the buffer capacity of the read buffer that does not generate underflow is represented by the following equation:

Boccupied≥(Tjump/1000×8)×((192/188)×TS_Recording_rate). the

The input rate to the read buffer is represented by Rud, and the output rate from the read buffer is represented by TS_Recording_rate × (192/188). Therefore, the occupancy rate of the read buffer is obtained by performing "(input rate) - (output rate)", and thus obtained by "(Rud-TS_Recording_rate)×(192/188)". the

The time "Tx" required to occupy the read buffer by "Boccupied" is obtained by the following equation:

Tx=Boccupied/(Rud-TS_Recording_rate×(192/188)). the

When reading from a BD-ROM, TS packets must be continuously input at the bit rate Rud for a duration of "Tx". As a result, when an AVClip is divided into multiple file ranges to be recorded, the minimum data length Sextent of each range is obtained by the following equation:

Sextent＝Rud×Tx

＝Rud×Boccupied/(Rud-TS_Recording_rate×(192/188)) 

≥Rud×(Tjump/1000×8)×((192/188)×TS_Recording_rate) 

/(Rud-TS_Recording_rate×(192/188)) 

≥(Rud×Tjump/1000×8)×TS_Recording_rate×192

/(Rud×188-TS_Recording_rate×192). the

therefore,

Sextent≥(Tjump×Rud/1000×8)×

(TS_Recording_rate×192/(Rud×188−TS_Recording_rate×192)). the

If each file range constituting the AVClip has a data length equal to or greater than the Sextent calculated as a value that does not cause decoder underflow, even if the file ranges constituting the AVClip are scattered on the BD-ROM, the The decoder supplies TS packets so that data is continuously read out during reproduction. the

Fig. 5 shows the relationship between the physical unit of the BD-ROM and the source packages constituting one file range. As shown in the second row, a plurality of sectors are formed on the BD-ROM. As shown in the first line, the source packages that make up the scope of the file are divided into groups, each group including 32 source packages. Each set of source packets is then written to a set of three contiguous sectors. A group of 32 source packets is 6144 bytes (=32×192), which is equivalent to the size of three sectors (=2048×3). The 32 source packets stored in three sectors are called "aligned units". Writing to the BD-ROM is performed in units of aligned units. the

In the third row, an error correction code is attached to each chunk of each 32 sectors. Chunks with error correction codes are called ECC chunks. As for accessing the BD-ROM in units of aligned units, the reproducing device can obtain 32 complete source packages. So far, the process of writing an AVClip to a BD-ROM has been described. the

<type of elementary stream>

Figure 6 shows elementary streams that are composited into an AVClip. the

As shown in Figure 6, what is composited into AVClip is: a high-quality video stream with a PID of 0x1011; a main audio stream with a PID of 0x1100 to 0x111F; a PG stream with a PID of 0x1200 to 0x121F; and a video stream with a PID of 0x1400 to 0x141F PID's IG stream. Packets constituting an elementary stream are assigned a corresponding PID, and are demultiplexed based on the PID. Hereinafter, an AVClip in which such high-quality video streams are composited is called a "MainClip", and an AVClip played back simultaneously with the MainClip is called a "SubClip". the

<BD-ROM Structure 2: Clip Information>

Next, the file to which the extension "clpi" is appended will be described. The file (00001.clpi) to which the extension "clpi" is appended stores Clip information. Clip information is management information on each AVClip. Figure 7 shows the internal structure of Clip information. As shown on the left side of the figure, the Clip information includes:

i) "ClipInfo()" storing information about AVClip;

ii) "Sequence Info()" that stores information about the ATC sequence and the STC sequence;

iii) "Program Info()" that stores information about the Program Sequence; and

iv) "Characteristic Point Info(CPI())". the

"ClipInfo" includes "application_type" indicating the application type of the AVClip referenced by the Clip Information. "TS_recording_rate" indicating whether a video is included or whether a still image (slideshow, slide show) is included is system bit rate information of the AVClip. the

Sequence Info is information about one or more STC-Sequence and ATC-Sequence contained in AVClip. The reason why these pieces of information are provided is to notify the playback device of the system time base gap and the arrival time base gap in advance. That is, if there is such a discontinuity, PTS and ATS having the same value may appear in the AVClip. This may be the cause of the defective reproduction. Sequence Info is provided to indicate from where to which STC or ATC is sequential in the transport stream. the

Program Info is information indicating a section (called "ProgramSequence") of a program whose content is constant. Here, "Program" is a group of elementary streams having in common a time axis for synchronous reproduction. The reason for providing Program Info is to notify the playback device in advance of the point at which the program content changes. It should be noted here that the point at which the program content changes is, for example, the point at which the PID of the video stream changes, or the point at which the type of the video stream changes from SDTV to HDTV. the

Characteristic Point Info will be explained from now on. Lead cu2 represents details of the CPI structure. As indicated by the lead cu2, the CPI consists of Ne EP_map_for_one_stream_PIDs: EP_map_for_one_stream PID[0]...EP_map_for_one_stream_PID[Ne-1]. These EP_map_for_one_stream_PIDs are EP_maps of elementary streams belonging to AVClip. EP_map is information indicating the number of packets (SPN_EP_start) in which the Access Unit appears at the entry position of one elementary stream in association with the entry time (PTS_EP_start). Lead cu3 in the figure indicates details of the internal structure of EP_map_for_one_stream_PID. the

It can be understood from this that EP_map_for_one_stream_PID is composed of Ne EP_High (EP_high(0)...EP_High(Nc-1)) and Nf EP_low (EP_low(0)...EP_low(Nf-1)). Here, EP_High is used to indicate the high bit of SPN_EP_start and PTS_EP_start of Access Unit (Non_IDRI image, IDR image), and EP_low is used to indicate the low bit of SPN_EP_start and PTS_EP_start of Access Unit (Non_IDR I image, IDR image). the

Lead cu4 in the figure indicates details of the internal structure of EP_High. As shown in lead cu4, EP_High(i) consists of "ref_to_EP_Low_id[i]" as the reference value of EP_low, "PTS_EP_High[i]" indicating the high bit of the PTS of Access Unit (Non_IDR I image, IDR image) and indicating Access Unit (Non_IDR I picture, IDR picture) SPN high "SPN_EP_High[i]" configuration. Here, "i" is an identifier of a given EP_High. the

Lead cu5 in the figure indicates details of the structure of EP_Low. As shown in lead cu5, EP_Low(i) is indicated by "is_angle_change_point(EP_Low_id)" indicating whether the corresponding Access Unit is an IDR Picture, "I_end_position_offset(EP_Low_id)" indicating the size of the corresponding Access Unit, indicating Access Unit(Non_IDRI image, "PTS_EP_Low(EP_Low_id)" of the low bit of the PTS of the IDR picture); and "SPN_EP_Low(EP_Low_id)" of the low bit of the SPN indicating the Access Unit (Non_IDR I picture, IDR picture). Here, "EP_Low_id" is an identifier for identifying a given EP_Low. the

<Clip information description 2: EP_Map> 

Here, EP_Map will be explained with specific examples. Figure 8 shows the EP_map settings on the movie's video stream. The first line shows a plurality of pictures (IDR picture, I picture, B picture, and P picture defined in MPEG4-AVC). The second row shows the timeline of these images. The fourth line shows the packet sequence, and the third line indicates the setting of EP_map. the

It is assumed here that in the time axis of the second row, an IDR picture or an I picture exists at each time point t1...t7. The interval between the adjacent time points of t1...t7 is about 1 second. The EP_map for this movie is set to indicate t1 to t7 as entry times (PTS_EP_start), and to indicate entry positions (SPN_EP_start) associated with the entry times. the

<PlatList information>

Next, the PlatList information will be explained. The file (00001.mpls) to which the extension "mpls" is attached is a file storing PlatList (PL) information. the

Fig. 9 shows the data structure of PlayList information. As shown in lead line mp1 of FIG. 9, the PlatList information includes: MainPath information (MainPath()) defining MainPath (main path); and PlayListMark information (PlayListMark()) defining chapters. the

<PlatList information description 1: MainPath information> 

First, MainPath will be explained. MainPath is a display path defined in terms of video stream and audio stream which are main images. the

As indicated by arrow mp1, MainPath.PlayItem information #1...PlayItem information #m is defined by a plurality of pieces of PlayItem information. PlayItem information defines one or more logical playback sections constituting MainPath. The lead hs1 in the figure indicates the details of the structure of the PlayItem information. As shown by the lead line hs1, the PlayItem information is composed of the following parts: "Clip_Information_file_name" indicating the file name of the playback section information of the AVClip to which the IN point and the OUT point of the playback section belong; "Clip_codec_identifier" indicating the AVClip encoding method; indicating whether the PlayItem is "is_multi_angle" that is multi-angle; "connection_condition" that indicates whether the current PlayItem is seamlessly connected with the previous PlayItem; "ref_to_STC_id[0]" that indicates the unique STC_Sequence targeted by the PlayItem; time information that indicates the start point of the playback section "In_time"; "Out_time" which is time information indicating the end point of the reproduction section; "UO_mask_table" indicating which user operation should be masked by the PlayItem; "PlayItern_random_access_flag" indicating whether to allow random access to the middle point of the PlayItem; "Still_mode" which continues the static display of the last image after reproduction ends; and "STN_table". Among these, time information "In_time" indicating the start point of the reproduction section and time information "Out_time" indicating the end point of the reproduction section constitute a display path. Display route information consists of "In_time" and "Out_time". the

Fig. 10 shows the relationship between AVClip and PlayList information. The first line shows the time axis saved by PlayList information. The second to fifth lines show video streams referenced by EP_map. the

The PlayList information includes two pieces of PlayItem information: PlayItem information #1; and PlayItem information #2. Two playback sections are defined by "In_time" and "Out_time" contained in PlayItem information #1 and PlayItem information #2. When arranging these playback sections, a time axis different from the AVClip time axis is defined. That is, the PlayList timeline displayed in the first row. According to the understanding here, by defining PlayItem information, it is possible to define a display path different from that of AVClip. the

The above-mentioned Clip information and PlayList information are classified into "static scenario". This is because Clip information and PlayList information define a PlayList as a static reproduction unit. This completes the description of the static script. the

"Dynamic script" will be explained from now on. The dynamic scenario is scenario data that dynamically defines the playback control of the AVClip. Here, "dynamically" means that the content of reproduction control is changed due to a state change in the reproduction apparatus, or due to a key event from the user. BD-ROM adopts two modes as the working environment of reproduction control. The first working environment is similar to a DVD playback device, and is a command-based execution environment. Another working environment is that of a Java ^™ virtual machine. The first working environment is called HDMV mode. The second working environment is called BD-J mode. Since both work environments are available, dynamic scripts are written to conform to one of these work environments. A motion scenario written in the HDMV mode is called a "Movie Object", and a motion scenario written in the BD-J mode is called a "BD-J Object".

First explain the Movie Object. the

<Movie Object>

The Movie Object is stored in the file "MovieObject.bdmv" shown in Figure 2, and includes a sequence of navigation instructions. the

The navigation command sequence is a sequence of navigation commands that implement conditional branching, set a status register in the playback device, acquire a value set in the status register, and the like. The following navigation commands can be written into the Movie Object. the

PlayPL instruction

Format: PlayPL(first argument, second argument)

As a first argument, a PlayList number is written to designate a PlayList to be reproduced. As the second argument, PlayItem contained in PlayList, time given in PlayList, Chapter, or Mark is written to designate a reproduction start position. the

The PlayPL function that uses PlayItem to designate a playback start position in the PL time axis is called "PlayPLatPlayItem()". the

The PlayPL function that uses Chapter to designate the playback start position in the PL time axis is called "PlayPLatChapter()". the

The PlayPL function that uses time information to specify a reproduction start position in the PL time axis is called "PlayPLatSpecifiedTime()". the

The writing format of navigation commands in Movie Object is similar to the writing format of navigation commands in DVD. This enables efficient transfer of disc content from DVD to BD-ROM. Movie Object is disclosed as prior art in the international publications identified below. Please refer to the International Publication for Movie Object details. the

International Publication: WO 2004/074976

The Movie Object has been explained so far. BD-J Object is explained below. the

<BD-J Object>

BD-J Object is a dynamic script of BD-J mode written in the Java ^TM programming environment, and stored as a file "00001.bobj". BD-J Object differs from Movie Object in that it does not contain commands written directly into it. That is to say, in Movie Object, the control process is directly written into the navigation instruction. On the contrary, in BD-J Object, the control process is defined indirectly through the description for the Java ^TM application written in the application management table. This indirect definition enables efficient execution of the sharing of the control process, where multiple dynamic scripts share the control process.

Playback of PlayList using Movie Object is realized by writing a navigation command (PlayPL command) instructing playback of PlayList. Playback of PlayList using BD-J Object is realized by integrating PlayList management table indicating playback process of PlayList in BD-J Object. the

Here, a Java ^™ application in the BD-J mode will be explained. It is assumed here that in the BD-J mode, the Java2Micro_Edition (J2ME) Personal Basis Profile (PBP 1.0) and the Globally Excutable MHP specification (GEM1.0.2) of packaged media objects are fully installed on the Java ^TM platform.

Java ^™ applications in BD-J mode are controlled through the Application Manager via the xlet interface. The xlet interface has four states: "loaded", "paused", "active" and "destroyed".

The Java ^™ platform described above includes standard Java ^™ libraries for displaying image data conforming to JFIF (JPEG), PNG, and the like. With this structure, a Java ^TM application can realize a GUI framework different from that realized by IG streaming in the HDMV mode. GUI frameworks in Java ^™ applications include the HAVi framework defined in GEM1.0.2 and the remote control navigation mechanism in GEM1.0.2.

With such a structure, Java ^™ applications can realize screen display in which moving images are displayed on the screen together with buttons, text, and online display (contents of BBS), and can perform operations on the display screen.

The essence of the Java ^™ application program is the Java ^™ archive file (00001.jar) stored in the BDJA directory under the BDMV directory shown in FIG. 2 .

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

International Publication: WO 2004/045840 A1

WO 2005/036555A1

WO 2005/036546A1

BD-J Object has been explained so far. the

<sound.bdmv>

sound.bdmv will be explained. sound.bdmv is a file for storing audio data which is output as a tick sound when operating a menu drawn in an IG stream or a GUI frame of a Java ^™ application (this audio data will be referred to as sound data).

Figure 11 shows the structure of the file sound.bdmv. The file sound.bdmv includes Sound Data() and Sound Index(). Sound Data( ) includes pieces of sound data (sound_data(0), sound_data(1)...). Among these sound data, sound_data(0) is the sound source of the first click output when the menu is operated, and sound_data(1) is the sound source of the second click output when the menu is operated. These sound data are identified by an identifier called sound_ID. the

Sound Index() includes: the number of sounds (number_of_sound_entries), the index to sound_data (0), the index to sound_data (1)... . the

Each index includes: sound_attributes indicating attributes of sound such as mono or stereo; sound_data_start_address indicating an address of corresponding sound data; and sound_data_length indicating a continuous length of corresponding sound data. the

As shown in Figs. 2 to 6, the source of the sound used in the movie is composited into the AVClip as the main audio stream. This setup is done for the purpose of providing the main audio stream, which provides the sound/speech in the movie while reading the video stream. On the other hand, the file sound.bdmv in which the click sound for the menu operation performed by the user is stored is recorded separately from the AVClip on the BD-ROM. Since the file sound.bdmv is recorded separately from the AVClip, when an attempt is made to output sound data during reading of the AVClip, the optical pickup jumps to read the file sound.bdmv. When this happens, reading of the AVClip is interrupted, and reproduction of the AVClip is interrupted. the

In order to prevent such interruption of AVClip reproduction, it is necessary to preload the file sound.bdmv into the buffer when the AVClip is not being reproduced. That is, it is necessary to preload the sound data of the file sound.bdmv before AVClip playback. This completes the description of the file sound.bdmv. the

<Index.bdmv>

Index.bdmv is a table indicating Movie Objects or BD-J Objects constituting subtitles. the

Index.bdmv defines the Movie Object or BD-JObject that is part of subtitles. the

The international publication described below discloses Index.bdmv. Please refer to the international publication on Index.bdmv for details. the

International Publication: WO 2004/025651A1

The BD-ROM 100 has been explained so far. the

<local storage 200> 

Next, the local storage 200 as the recording medium of the present invention will be explained. FIG. 12 shows the internal structure of the local storage 200 . As shown in FIG. 12, the recording medium of the present invention can be produced by improving the application layer. the

The fourth row of FIG. 12 shows the local storage 200 . The third row shows the tracks on local storage 200 . FIG. 12 shows the tracks in a horizontally extended state, although actually they are formed spirally in order from the inner circumference to the outer circumference of the local storage 200 . A track consists of a lead-in area, a label area and a lead-out area. The volume label area in FIG. 12 has a layer model including a physical layer, a file system layer and an application layer. The first row of FIG. 12 shows the application layer format (application format) of the local storage 200 represented by the directory structure. the

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

With this structure, in which directories assigned to a specific provider include directories corresponding to BD-ROMs, download data for each BD-ROM is stored separately. Similar to the information stored in the BD-ROM, under the subdirectory "disc#1", the following information is stored: PlayList information ("00002.mpls"); Clip information ("00002.clpi"); AVClip ("00002. m2ts"); BD-J Object ("00002.bobj"); Java ^™ Archive ("00002.jar"); Tick Data ("sound.bdmv") and Movie Object ("MovieObject.bdmv").

Next, PlayList information, Clip information, and AVClip which are components of the local storage 200 will be described. the

<Local storage 200 structure 1: AVClip>

The AVClip ("00002.m2ts") in the local storage 200 constitutes a SubClip. the

A SubClip is an AVClip including an elementary stream that is decoded and reproduced simultaneously with a MainClip. SubClips are classified into "primary audio stream", "secondary audio stream", "Presentation Graphics (PG) stream" and "Interactive Graphics (IG) stream" (hereinafter SubClip may also be referred to as Out-of-MUX stream). the

In this embodiment, it is assumed that "00002.m2ts" shown in FIG. 12 is a SubClip in which a sub audio stream, a PG stream, and an IG stream are composited. The secondary audio stream will be described in detail below. the

<Out-of-MUX stream description 1: Secondary audio stream>

When the primary audio stream is an audio stream including primary sound/voice, the secondary audio stream is an audio stream including secondary sound/voice. When the SubClip is reproduced, after the sound/voice of the primary audio stream is mixed with the sound/voice of the sub audio stream, the sound/voice for reproduction is output. The sound/voice to be included in the secondary audio stream includes, for example, "commentary sound/voice". When the main sound/voice contained in the primary audio stream is the sound/voice of the movie, and the secondary sound/voice contained in the secondary audio stream is the director's commentary sound/voice, when mixed with the commentary sound/voice Then output the sound/voice of the movie. the

The secondary audio stream is recorded only on the local storage 200 for reproduction, not on the BD-ROM. The main audio stream can be recorded on the BD-ROM and/or local storage 200 . The encoding codec used for the primary audio stream may be different from the encoding codec used for the secondary audio stream. the

Figure 13 shows Elementary Streams composited into SubClips. In FIG. 13 , PG streams with PIDs "0x1200" to "0x121F", IG streams with PIDs "0x1400" to "0x141F", and sub audio streams with PIDs "0x1A00" to "0x1A1F" are multiplexed. Here, the PIDs of the PG stream and the IG stream in the SubClip are the same as the PIDs of the PG stream and the IG stream in the MainClip, but any one of the PIDs of the 32 secondary audio streams is the same as any of the PIDs of the 32 main audio streams are all different because they differ in the high order byte. the

Fig. 14 shows the PID assignment diagram of the BD-ROM standard. According to Figure 14, "0x0100" is assigned to "program_map", "0x1001" is assigned to "PCR", "0x1011" is assigned to the video stream, and the range from "0x1100" to "0x111F" is assigned to the main audio stream , assign the range from "0x1200" to "0x121F" to the PG stream, the range from "0x1400" to "0x141F" to the IG stream, and the range from "0x1A00" to "0x1A1F" to the secondary audio stream. It can be understood from the PID allocation diagram that the range allocated to the primary audio stream is different from the range allocated to the secondary audio stream. the

Fig. 15A shows the internal structure of the secondary audio stream. the

As shown in FIG. 15A, the secondary audio stream is composed of a plurality of audio frames. Fig. 15B shows an example of an audio frame. The audio frames of the secondary audio stream include metadata. the

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

The down mix information is information for down mix. Downmixing is a conversion in which the number of audio reproduction channels is modulated to be smaller than the number of encoding channels. The downmix information defines a conversion coefficient matrix for downmixing, thereby enabling a reproducing apparatus to perform downmixing. For example, downmixing enables reproduction of a 5.1-channel audio stream in 2 channels. the

The gain control information is used to increase or decrease the gain of the audio output of the main audio stream. In this embodiment, the gain control information is only used to reduce the gain. Fig. 15D shows an example of gain control information. It can be understood from this that the metadata of the secondary audio stream can reduce the output of the primary audio stream simultaneously reproduced with the secondary audio stream in real time. When combining (mixing) the primary and secondary audio streams, it is not necessary to control the gains of the two audio streams in real time. Since the paired primary and secondary audio streams are known in advance, it is only necessary to reduce the gain of the primary audio stream when mixing (combining) them, without changing the gain of the secondary audio stream. the

Only valid gain control information can be stored during the period from the time specified by "mark_time_stamp" of PlayListMark. the

Figure 16 shows how the volume of the primary audio stream can be controlled through metadata in the secondary audio stream. In Figure 16, the first line shows the time axis, the second line shows the reproduction output of the primary audio stream that can be mixed, the third line shows the reproduction output of the secondary audio stream, and the fourth line shows the composite in the secondary audio stream. Metadata in . the

The metadata set in the audio frame corresponding to the reproduction time t1 suppresses the volume of the reproduction output of the main audio stream as a whole. The metadata set in the audio frame corresponding to the reproduction time t2 restores the volume of the reproduction output of the main audio stream. With this arrangement of setting the metadata at the reproduction times t1 and t2, it is possible to avoid a situation where the volume of the reproduction output of the primary audio stream is combined with the volume of the secondary audio stream to cause damage to the speaker. the

When gain adjustment for mixing is performed in real time using the gain control information of the secondary audio stream, only for the gain control information stored in each audio frame of the secondary audio stream, it is necessary to specify to decrease the gain of the primary audio stream by a predetermined amount. amount. For example, this method of always ensuring proper gain control is more convenient than the case of performing hybrid rendering by using dedicated rendering to jump into periods between the rendering times t1 and t2. the

<Local storage 200 structure 2: PlayList information>

Next, the PlayList information in the local storage 200 will be explained. The file (00002.mpls) to which the extension "mpls" is appended is information defining a PlayList (PL) by combining two types of display paths called MainPath and Subpath. Fig. 17 shows the data structure of PlayList information. As shown in FIG. 17, the PlayList information includes: MainPath information (MainPath( )) defining a MainPath; PlayListMark information (PlayListMark( )) defining a chapter; and Subpath information (Subpath( )) defining a Subpath. The internal structure of PlayList information and PlayItem information is the same as that of BD-ROM, and its description is omitted here. the

<PlayList information description 1: Subpath information> 

While MainPath is a display path defined in terms of MainClip as a main image, Subpath is a display path defined in terms of SubClip synchronized with MainPath. the

Figure 18 shows a close-up of the internal structure of the Subpath information. As indicated by arrow hc0, each Subpath includes: SubPath_type indicating the type of SubClip; and one or more pieces of SubPlayItem information (...SubPlayItem()...). the

Lead hc1 indicates details of the structure of SubPlayItem information. As shown by lead hc1, the SubPlayItem information includes: "Clip_information_file_name", "Clip_codec_identifier", "ref_to_STC_id[0]", "SubPlayItem_In_time", "SubPlayItem_Out_time", "sync_PlayItem_id" and "sync_start_PTS_of_PlayItem."

"Clip_information_file_name" is information that uniquely specifies a SubClip corresponding to a SubPlayItem by a file name in which Clip information is written. the

"Clip_codec_identifier" indicates the encoding method of the AVClip. the

"ref_to_STC_id[0]" uniquely indicates the STC_Sequence that is the target of the PlayItem. the

"SubPlayItem_In_time" is information indicating the starting point of the SubPlayItem on the playback time axis of the SubClip. the

"SubPlayItem_Out_time" is information indicating the end point of the SubPlayItem on the playback time axis of the SubClip. the

"sync_PlayItem_id" is information that uniquely specifies a PlayItem to be synchronized with a SubPlayItem among the PlayItems constituting the MainPath. "SubPlayItem_In_time" appears on the playback time axis of the PlayItem specified by "sync_PlayItem_id". the

"sync_start_PTS_of_PlayItem" indicates the position of the start point of the SubPlayItem specified by "SubPlayItem_In_time" on the reproduction time axis of the PlayItem specified by "sync_PlayItem_id". the

<Subpath information details 1: SubPath_type>

So far, the Subpath information has been explained. From now on, SubPath_type will be explained. SubPath_type is set to a value between 0 and 255 to indicate the type of SubPath defined by the SubPath information. the

When SubPath_type is set to 5, it indicates that the SubPath defined by the SubPath information is the main audio display path. The main audio display path is used when an audio stream to be replaced by the main audio stream referenced by MainPath(PlayItem) is stored in SubPath(SubPlayItem) before its reproduction. the

When SubPath_type is set to 6, it means that the current SubPath information defines the display path for the added or replaced Presentation Graphics. Here, "adding or replacing" involves adding a PG stream to one PG stream that can be reproduced by PlayItem information, or replacing a PG stream with any PG stream that can be reproduced by PlayItem information. the

When the SubPath_type is set to 7, it indicates that the current SubPath information defines an Interactive Graphics (interactive graphics) display path for addition or replacement. Here, "adding or replacing" refers to adding an IG stream to one IG stream capable of being reproduced by PlayItem information, or replacing an IG stream with any IG stream capable of being reproduced by PlayItem information. the

When SubPath_type is set to 8, it indicates that the current SubPath information defines a secondary audio display path for addition. Here, "addition" refers to addition of a secondary audio stream to be mixed with reproduced sound/voice of a primary audio stream capable of being reproduced by PlayItem information. the

For example, when performing mixed reproduction of the primary and secondary audio streams, two audio decoders and two mixers need to be operated, so it is necessary to acquire the playback type of the player in advance, unlike the case of reproducing only the normal primary audio stream . For this, the player is notified of the existence of the sub audio stream to be reproduced synchronously before reproduction using the PID of SubPath_type or STN_table. the

So far, SubPath_type has been explained. the

<Subpath information details 2: the relationship between the three parties> 

It should be noted that the "three parties" mentioned here are the SubClip in the local storage 200, the PlayList information in the local storage 200, and the MainClip in the BD-ROM. the

FIG. 19 shows the relationship among SubClips in the local storage 200, PlayList information in the local storage 200, and MainClips in the BD-ROM. In FIG. 19 , the first row shows SubClips in the local storage 200 . As shown in the first row, the SubClip in the local storage 200 is any one of the sub audio stream, the PG stream and the IG stream. Make any of these streams undergo synchronous reproduction as a Subpath. the

The second row of Fig. 19 shows two time axes defined by PlayList information. Among these time axes, the lower time axis is a PlayItem time axis defined by PlayItem information, and the upper time axis is a SubPlayItem time axis defined by SubPlayItem information. the

As shown in FIG. 19, "SubPlayItem_Clip_information_file_name" of the SubPlayItem information indicates one of ".m2ts" files stored in the STREAM directory for specifying the reproduction section of the SubClip. the

"SubPlayItem_In_time" and "SubPlayItem_Out_time" are used to define the start point and end point of the reproduction section. the

The arrow "sync_PlayItem_id" is used to designate synchronization, that is, to designate a PlayItem to be synchronized. The arrow "sync_start_PTS_of_PlayItem" is used to determine the position of "SubPlayItem_In_time" in the PlayItem time axis. the

Fig. 20 shows EP_map and PlayItem time axis set for MainClip and EP_map and SubPlayItem time axis set for SubClip. the

In FIG. 20 , the middle row and the lower fourth row to the lower first row show the PlayItem time axis, image sequence, MainClip time axis, EP_map, and TS packet sequence shown in FIG. 10 . the

In addition, the upper first line to the upper third line show the TS packet sequence, EP_map and SubClip time axis, and the upper fourth line shows the SubItem time axis. the

So far, the SubPath information has been explained. the

<STN_stable>

The only one belonging to the PlayList information in the local storage 200 is STN_stable. Next, the PlayList information in the local storage 200 will be described. the

STN_stable is a table indicating reproducible streams among a plurality of elementary streams composited in an AVClip specified by Clip_Information_file_name in PlayItem information and in an Out_of_MUX stream specified by Clip_Information_file_name in the information. More specifically, STN_stable is generated by associating Stream_attributes respectively corresponding to a plurality of Elementary Streams composited in MainClip and to Out_of_MUX streams composited in SubClip with Stream_entries. the

Figure 21 shows the internal structure of STN_table. As shown in FIG. 21 , STN_stable includes a plurality of pairs (entry-attribute) of entries and attributes of STN_stable, and the number of pairs (number_of_video_stream_entries, number_of_audio_stream_entries, number_of_PG_stream_entries, number_of_IG_stream_entries) is displayed. the

In STN_table, each entry-attribute pair corresponds to any one of video stream, primary audio stream, secondary audio stream, PG stream, and IG stream that are allowed to be reproduced by PlayItem, as indicated by brackets "{". In particular, it should be noted here that the pair of Stream_entry and Stream_attribute in the secondary audio stream is associated with Comb_info_Secondary_audio_Primary_audio. the

The entry-attribute will now be described in detail. the

Fig. 22A shows Stream_attribute corresponding to a video stream. the

The Stream_attribute for a video stream includes: "Video_format" indicating a video stream display method; "frame_rate" indicating a video stream display frequency; and the like. the

Fig. 22B shows Stream_attribute corresponding to the primary audio stream and the secondary audio stream. the

The Stream_attribute for the primary audio stream and the secondary audio stream includes: "Stream_coding_type" indicating the audio stream encoding method; "audio_presentation_type" indicating the channel structure of the corresponding audio stream; "Sampling_frequency" indicating the sampling frequency of the corresponding audio stream; and "audio_language_code" representing the language attribute of the audio stream. the

Fig. 22C shows the Stream_entry of the video stream. As shown, the Stream_entry for the video stream includes: "ref_to_Stream_PID_of_Main_Clip" indicating the PID for the demultiplexed video stream. the

Stream_attribute for the Main Audio Stream, IG Stream, and PG Stream composited in MainClip has the format shown in Fig. 22C. the

Fig. 22D shows Sub_entry for a stream (referred to as a sub audio stream in the following description) composited in a SubClip. The Stream_entry for the sub audio stream includes "ref_to_Sub_Path_id" indicating SubPath information referencing the sub audio stream; "ref_to_Sub_Clip_entry_id" indicating the SubClip in which the sub audio stream is composited; and "ref_to_stream_PID_of_Sub_Clip" indicating the PID for demultiplexing the sub audio stream . the

Fig. 22E shows the internal structure of Comb_info_Secondary_audio_Primary_audio associated with a pair of Stream_entry and Stream_attribute of the secondary audio stream. [ n]. the

Fig. 23 shows the description of the primary audio stream according to Comb_info_Secondary_audio_Primary_audio. In Figure 23, 32 secondary audio streams are shown on the right and 32 primary audio streams are shown on the left. An arrow ym1 indicates a specification according to Comb_info_Secondary_audio_Primary_audio of the secondary audio stream #1. In this way, Comb_info_Secondary_audio_Primary_audio set for each secondary audio stream uniquely specifies one or more primary audio streams that can be mixed with the reproduction output of the secondary audio stream. This structure makes it possible to set whether or not to mix secondary audio streams according to the audio property at the time of editing. For example, it is possible to set not to mix the secondary audio stream with the primary audio stream having a predetermined attribute during reproduction, and to set to mix the secondary audio stream with the primary audio stream having attributes other than the predetermined attribute during reproduction. the

So far, the PlayList information in the local storage 200 has been explained. This completes the description of the local storage 200 . the

<virtual package>

The virtual package will be explained from now on. FIG. 24 shows a virtual package generated by the reproducing apparatus 300. Referring to FIG. In FIG. 24 , the upper left shows the recorded content of the BD-ROM, and the lower left shows the recorded content of the local storage 200 . Also, the structure of the virtual package is shown on the right. the

The playback device obtains a virtual file system by combining AVClip, Clip information, and PlatList information stored in the BD-ROM and the local storage 200 . the

More specifically, for this combination, the reproduction means:

i) Virtually add the PlayList (00002.mpls) in the local storage to the MPLS directory in the BD-ROM;

ii) Virtually add the Clip information (00002.clpi) in the local storage to the CLPI directory in the BD-ROM;

iii) Virtually add the AVClip#2 information (00002.m2ts) in the local storage to the STREAM directory in the BD-ROM;

Through the above combinations, the virtual package shown on the right side of Fig. 24 is generated. the

So far, the recording medium has been explained. The reproducing apparatus will be explained from now on. the

Fig. 25 shows the internal structure of the reproducing apparatus of the present invention. The reproducing device of the present invention is industrially produced according to the internal structure shown in FIG. 25 . The reproducing apparatus of the present invention is mainly composed of two parts, a system LSI and a driving device, and can be industrially produced by mounting these parts in a case and on a substrate. The system LSI is an integrated circuit including various processing units that perform the functions of the reproducing apparatus. The playback device produced in this way includes: BD-ROM drive 1a, bus 1b, read buffers 2a and 2b, demultiplexers (demultiplexers) 3a and 3b, video decoder 4, video plane 5, buffer 6a, 6b and 6c, audio decoders 7a and 7b, downmixing/downsampling (DownSample) 8, mixers 9a and 9b, switch 10a, encoder 10b, interactive graphics decoder 11, interactive graphics surface 12, display graphics decoder 13 , display graphics plane 14, JPEG decoder 15, still image plane 16, combination unit 17, STC generation units 18a and 18b, ATC generation units 19a and 19b, memory 21, controller 22, PSR group 23, PID transformation unit 24, A communication unit 25 , an operation reception unit 26 , and an HDMI transmission/reception unit 27 . the

The BD-ROM drive 1a performs loading/ejecting of the BD-ROM, and performs access to the BD-ROM. the

The bus 1 b transfers thereon TS packets read from the BD-ROM, and TS packets read from the local storage 200 . the

The read buffer 2a is a FIFO memory in which TS packets read from the BD-ROM 100 or from the local storage 200 are stored in a first-in first-out method. the

The read buffer 2b is a FIFO memory in which TS packets read from the local storage 200 are stored in a first-in first-out method. the

The demultiplexer 3a outputs the TS packet having the PID notified from the PID conversion unit 24 among the TS packets transmitted on the bus and having the PIDs 0x1011, 0x1100-0x111F, 0x1200-0x121F, and 0x1400-141F to the video decoder 4 , audio decoder 7a, IG decoder 11 and PG decoder 13. the

The demultiplexer 3b demultiplexes the TS packets with PID 0x1A00-0x1A1F among the TS packets transmitted on the bus 1b, that is, the TS packets constituting the secondary audio stream. Realized by comparing the reference value of the PID written in the stream_entry with the PID of the TS packet transmitted on the bus 1b, and outputting the TS packet having the PID matched in the comparison to the audio decoder 7b via the buffer 6b. The demultiplexing performed by the demultiplexer 3b, wherein the stream_entry is the stream_entry corresponding to the stream number stored in the PSR 14 among the stream_entries of the secondary audio stream including the STN_table. It should be noted here that if there is only one reproducible secondary audio stream, it is only necessary to compare the high byte "1A" of the PID reference value written in stream_entry with the high byte "1A" of the PID of the TS packet transmitted on the bus 1b. Compare. This is because only the upper byte of the PID indicating that it is a secondary audio stream needs to be referenced since there are no other secondary audio streams. the

If there are multiple reproducible secondary audio streams, in addition to comparing the high-order byte "1A" of the PID reference value written in stream_entry with the high-order byte "1A" of the PID of the TS packet transmitted on the bus 1b , it is also necessary to write the low byte of the PID reference value in the stream_entry (the value ranging from 0x00 to 0x1F) with the low byte of the PID of the TS packet transmitted on the bus 1b (the value ranging from 0x00 to 0x1F) Compare. This is because since there are multiple secondary audio streams, it is necessary to refer to the lower byte of the PID so that the secondary audio streams are uniquely identified. the

Here, since the TS packets read from the BD-ROM and the local storage 200 are transmitted on the bus 1b, the demultiplexer 3a and the demultiplexer 3b treat these TS packets read from the BD-ROM and the local storage 200 as A Transport Stream process and store them in a buffer as a Transport Stream. The PIDs allocated to the TS packets constituting the primary audio stream appear in a range different from the range in which the PIDs allocated to the TS packets constituting the secondary audio stream appear in the PID allocation map. With this structure, when these TS packets are input as one transport stream, the demultiplexer 3a and the demultiplexer 3b can output the primary audio stream and the secondary audio stream as different elementary streams. Here, the demultiplexer 3a and the demultiplexer 3b can supply a plurality of audio streams composited in one transport stream to a decoder by performing the same process as when demultiplexing them. Therefore the demultiplexer 3a and the demultiplexer 3b can provide the primary audio stream and the secondary audio stream from one transport stream to the corresponding decoder. the

There may be cases where only one demultiplexer is provided for installation. In this case, it is effective to assign different PIDs to the primary audio stream and the secondary audio stream. the

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

The video decoder 4 decodes a plurality of PES packets output from the demultiplexer 3 a to obtain uncompressed images, and writes the obtained images into the video plane 5 . the

The video plane 5 is a plane for storing uncompressed images. A "plane" is a storage area for storing one screen of pixel data in a reproduction device. The resolution of video plane 5 is 1920×1080. The image data stored in the video plane 5 is composed of a plurality of pieces of pixel data, and each piece of pixel data is represented by a 16-bit YUV value. the

The buffer 6a stores therein the TS packets having the PID of the audio stream to be reproduced out of the TS packets output from the demultiplexer 3a and having PIDs in the range from 0x1100 to 0x111F in the first-in-first-out method, and The stored TS packets are supplied to the audio decoder 7a. the

The buffer 6b stores therein the TS packets having the PID of the audio stream to be reproduced among the TS packets output from the demultiplexer 3b and having PIDs in the range from 0x1A00 to 0x1A1F in the first-in-first-out method, and The stored TS packets are supplied to the audio decoder 7b. the

The buffer 6c is a memory for preloading therein the file sound.bdmv read from the BD-ROM/local storage. It is preferable to perform preloading to the buffer 6c when loading a BD-ROM or when changing a title. This is because when trying to read the file sound.bdmv during reproduction of the AVClip, the optical pickup performs a seek to read a file different from the AVClip. On the other hand, when a BD-ROM is loaded or when a name is changed, an AVClip is hardly reproduced. Therefore, if the file sound.bdmv is always read when the BD-ROM is loaded or when the name is changed, the response of the device increases, and the reproduction of the AVClip is not easily interrupted. the

The audio decoder 7a converts the TS packets stored in the buffer 6a into PES packets, decodes the PES packets to obtain uncompressed audio data in LPCM state, and outputs the obtained audio data. This enables a digital output to the main audio stream. the

The audio decoder 7b converts the TS packets stored in the buffer 6b into PES packets, decodes the PES packets to obtain uncompressed audio data in LPCM state, and outputs the obtained audio data. This enables a digital output to the secondary audio stream. the

Down-mixing/down-sampling 8 converts the digital audio output from the audio decoder 7a so as to match the digital audio output from the audio decoder 7b in terms of audio properties. Here, the audio properties are the sampling frequency and/or the number of channels. make them compatible with each other. Based on the gain control information extracted by the audio decoder 7b, the downmixing/downsampling 8 or the mixer 9a also performs a process of reducing the gain on the primary audio stream side according to the metadata composited in the secondary audio stream. the

The mixer 9a mixes the digital audio in the LPCM state output from the audio decoder 7a with the digital audio in the LPCM state output from the audio decoder 7b. the

The mixer 9b mixes the digital audio in the LPCM state output from the mixer 9a with the sound data stored in the buffer 6c. Mixing is performed by the mixer 9b when the CPU 22 decodes a navigation instruction for outputting a tick or a bytecode for outputting a tick. the

The switch 10a switches between the following (a) and (b) operations, wherein the (a) operation is demultiplexing the TS packets of the primary audio stream demultiplexed by the demultiplexer 3a and demultiplexing by the demultiplexer 3b. The TS packets of the secondary audio stream are supplied to the audio decoders 7a and 7b, and the (b) operation is not supplied to the audio decoders 7a and 7b, but only the elementary stream is output to other devices. Such an operation of not supplying the TS packets of the main audio stream to the audio decoders 7a and 7b but outputting only the elementary stream to other devices is called "pass-through output". A conversion unit (not shown) that converts TS packets into elementary streams (removing TS/PES headers) is embedded in the switch 10a. the

When the audio data of the LPCM state obtained by decoding by the audio decoder 7a and the audio decoder 7b and mixing by the mixer 9b is transmitted as surround sound/speech through a digital interface such as S/PDIF, the encoder 10b converts the mixed LPCM encoded and compressed into Dolby Digital (DD) format or Dolby Theater System (DTS) format. the

The interactive graphics (IG) decoder 11 decodes the IG stream read from the BD-ROM 100 or the local storage 200, and writes the obtained uncompressed graphics into the IG plane (IG plane) 12. the

The interactive graphics (IG) plane 12 is a plane in which uncompressed graphics obtained by the IG decoder 11 are written. In addition, characters or graphics drawn by application programs are also written on the IG surface 12 . the

Display graphics (PG) decoder 13 decodes the PG stream read from BD-ROM 100 or local storage 200, and writes the obtained uncompressed graphics to PG plane 14. the

The display graphics (PG) plane 14 is a memory having an area of one screen, and stores one screen of uncompressed graphics. the

The JPEG decoder 15 decodes JPEG data recorded in the BD-ROM 100 or the local storage 200, and writes the obtained data in the still image plane 16. the

The still image plane 16 is a plane in which uncompressed graphics obtained by decoding JPEG data are written. In addition, characters or graphics drawn by application programs are also written on the IG surface 12 . Graphical data is used as "wallpaper" for GUI frame compositions written by Java ^(TM ) applications.

The combining unit 17 combines the data stored in the IG plane 12, the data stored in the PG plane 14, the data stored in the video plane 5, and the data stored in the still image plane 16 to obtain a synthesized image. the

The STC generating units 18a and 18b generate a system clock (STC) according to an instruction of the controller 22, and adjust the operation time of each decoder. the

The ATC generation units 19a and 19b generate an arrival clock (ATC) according to an instruction of the controller 22, and adjust the operation time of the demultiplexer. The memory 21 is a memory for storing current PL information and current Clip information. The current PL information is PL information currently being processed among pieces of PlayList information stored in the BD-ROM. The current Clip information is Clip information currently being processed among pieces of Clip information stored in the BD-ROM/local storage. the

The controller 22 realizes the reproduction control of the BD-ROM by decoding the Java ^TM application program referred to by the MovieObject or BD-J Object stored in MovieObject. playback control of PL information). The controller 22 also executes the above-mentioned ATS control and STC control.

The PSR group 23 is a register embedded in the reproducing apparatus, and is composed of 64 player setting/status registers (PSR) and 4096 general-purpose registers (GPR). Of the values (PSR) set in the player setting/status register, PSR4 to PSR8 are used to indicate the current reproduction point. the

The PID conversion unit 24 converts the stream numbers of the primary audio stream and the secondary audio stream into PIDs based on the STN table, and notifies the demultiplexers 3a and 3b of the PIDs obtained by the conversion. the

The communication unit 25 realizes a communication function in the reading device. When a URL is specified by a Java ^™ application in BD-J mode, the communication unit 25 establishes a TCP connection or an FTP connection with the website of the specified URL. The establishment of this connection enables the Java ^(TM) application to download data from the website.

The operation receiving unit 26 receives an operation specification from the user, and notifies the controller 22 of user operation information representing an operation specified by the user. the

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

So far, the hardware configuration of the reproducing apparatus of the present invention has been explained. From now on, the software structure of the reproducing apparatus of the present invention will be explained. the

FIG. 26 shows the controller 22 shown in FIG. 25 in functional terms. FIG. 26 shows the function of the controller 22 . As shown in FIG. 26, the controller 22 includes a playlist processing unit 41, process execution units 42 and 43, a mixing control unit 44, and an ATC/ATC that makes the ATC generating units 19a and 19b and the STC generating units 18a and 18b generate ATC and STC, respectively. STC control unit. the

These components are based on the processing performed by the PSR group 23 . PSR1, PSR14 and PSR31 are explained below. the

<PSR1>

Figure 27A shows the bit allocation in PSR1. the

As shown in FIG. 27A, the lower 8 bits (b0-b7) of the 32 bits of PSR1 represent a stream number, and identify one of a plurality of primary audio streams whose entry is written in the STN table of the current PlayItem. When the value set in PSR1 is changed, the reproducing apparatus reproduces the main audio stream corresponding to the set value after the change. PSR1 is set to "0xFF" as an initial value, and then can be set to a value ranging from "1" to "32" by the reproducing apparatus. The value "0xFF" is an unspecified value, and indicates that there is no primary audio stream or that the primary audio stream is not selected. When PSR1 is set to a value ranging from "1" to "32", the set value is interpreted as the stream number of the main audio stream. the

<PSR14>

Figure 27B shows the bit allocation in PSR14. the

As shown in FIG. 27B, the lower 8 bits (b0-b7) of the 32 bits of PSR14 represent a stream number, and identify one of a plurality of secondary audio streams whose entry is written in the STN_table of the current PlayItem. When the value set in PSR14 is changed, the reproducing apparatus reproduces the sub audio stream corresponding to the set value after the change. The PSR14 sets "0xFF" as an initial value, and can then be set to a value ranging from "1" to "32" by the reproducing apparatus. The value "0xFF" is an unspecified value, and indicates that there is no secondary audio stream or that the secondary audio stream is not selected. When PSR14 is set to a value ranging from "1" to "32", the set value is interpreted as the stream number of the secondary audio stream. the

<PSR31>

Figure 27C shows the bit allocation in PSR31. the

As shown in FIG. 27C, bit 16 to bit 19 (b16-b19) of 32 bits of PSR31 represent player profile information. When bits 16 to 19 are "0000"b, they indicate that the reproducing device is transmitted within the grace period, where ""b indicates a bit value. Here, the grace period is a time during which a reproducing apparatus without a predetermined function can be transmitted. Functions that can be omitted in the playback device transmitted during the grace period include an audio mixing function. Therefore, if bits 16 to 19 (b16-b19) of PSR31 are set to "0000"b, that is, if the player profile information is "0000"b, it means that predetermined functions including the audio mixing function are not installed in the reproduction device. the

When the player profile information is "0001"b, it indicates that the reproducing device is transmitted after the grace period. Since a reproduction device shipped after the grace period is basically required to install all functions to be provided, the player profile information of "0001"b indicates that the reproduction device has a hybrid function installed. the

When the player profile information is "0011"b, it indicates that the reproducing apparatus has installed all the functions to be provided. Such renditions have all features installed regardless of whether they were shipped before or after the grace period. Therefore, when the player profile information is "0011"b, it indicates that the reproduction apparatus is equipped with a sound mixing function. the

The PSR may include information indicating the number of channels for which the reproducing apparatus can perform mixing, as information indicating a mixing function. the

Alternatively, the PSR may include information representing the number of audio output channels that are finally output. For example, if an interface such as HDMI is connected for use, 5.1-channel LPCM audio as a decoding result can be output as LPCM. However, if the interface is, for example, S/PDIF, audio is output as 2-channel (L/R) instead of 5.1-channel, and compression by an encoder is required for this. Therefore, if it is judged that the encoder is connected to S/PDIF after the mixer (for example, not connected to HDMI), the number of audio output channels of the final output can be set to 5.1 channels. If there is no encoder after the mixer, the number of audio output channels finally output after mixing can be set to 2 channels. the

So far, the PSR group 23 has been described. the

From now on, the playlist processing unit 41, the procedure execution unit 42, and the procedure execution unit 43 will be explained. the

<Functional Structure Details 1: Playlist Processing Unit>

A playlist (PlayList) processing unit 41 realizes PL reproduction. Playlist processing unit 41 reproduces the part corresponding to the interval from In_time to Out_time of the PlayItem information of the video stream and the main audio stream, and makes it synchronized, and the playlist processing unit 41 makes the audio decoder 7b reproduce the corresponding SubPlayItem of the secondary audio stream. A part of the interval from Sub_PlayItem_In_time to Sub_PlayItem_Out_time of the information. the

Fig. 28 is a flowchart showing the PlayList reproduction process performed by the PlayList processing unit. the

In this flowchart, PL information (.mpls) is first read (step S101), and then steps S102 to S110 are performed. Steps S102 to S110 constitute a loop in which steps S103 to S110 are repeatedly executed for each piece of PI information constituting the current PL information until it is judged "Yes" in step S109. In this loop processing, the processing target PlayItem is called PlayItem#x (PI#x). PlayItem#x is initialized by the start PlayItem set as the current PL information (step S102). The condition for ending the loop is that PlayItem#x is the last PlayItem of the current PL information (step S109). If it is judged in step S109 that PlayItem#x is not the last PlayItem of the current PL information, PlayItem#x is set as the next PlayItem in the current PL information (step S110). the

In steps S103 to S110 repeatedly executed in the loop processing, the Clip information specified by the Clip_information_file_name of PlayItem#x is read onto the memory (step S103), and the In_time of PlayItem#x is converted into an I image address using the EP_map of the current Clip information u (step S104), use the EP_map of current Clip information to convert the Out_time of PlayItem#x into I image address v (step S105), obtain the next I image address of I image address v, and the previous address of the obtained address The address is set to address w (step S107), instructing the BD-ROM 100 or local storage 200 to read the TS packet from I picture address u to address w (step S108). the

On the other hand, the video decoder is instructed to output from the mark_time_stamp of the current PLMark up to the Out_time of PlayItem #x (step S106). In steps S105 to S108, the part of the AVClip specified by PlayItem#x is reproduced. the

After that, it is judged whether PlayItem#x is the last PlayItem of the current PL information (step S109). the

If it is judged in step S109 that PlayItem#x is not the last PlayItem of the current PL information, PlayItem#x is set as the next PlayItem in the current PL information (step S110), and control returns to step S103. Since the above-described steps S103 to S110 are repeated, each piece of PI information constituting the current PL information is sequentially reproduced. the

<Functional Structure Details 2: Process Execution Unit 42> 

When it is necessary to change one piece of PlayItem information to another, or when the user instructs to change the stream number through operation, the process execution unit 42 executes a predetermined stream selection process, and writes the new stream number into PSR1. The playback device plays back the main audio stream based on the stream number written in PSR1. The setting of PSR1 thus enables the selection of the primary audio stream. the

The following is the reason why the stream selection process is performed when PlayItem information is changed. Since the STN_table is provided corresponding to each piece of PlayItem information, there may arise a case where the main audio stream reproducible according to one piece of PlayItem information cannot be reproduced according to another piece of PlayItem information. the

As shown in FIG. 29A, the process execution unit 42 causes PSR1 to change state. Figure 29A shows the state transition of the value set in PSR1. It should be noted here that in FIG. 29A , the term "valid" means that the value of PSR1 is equal to or less than the number of entries written in STN_table of PlayItem, and is decodable. the

The term "invalid" means that (a) the value of PSR1 is "0", (b) the value of PSR1 is greater than the number of entries written in PlayItem's STN_table, or (c) even if the number of entries written in PlayItem's STN_table Quantities in the range "1" to "32" are also not decodable. the

The boxes drawn in dashed lines in FIG. 29A represent the process for determining the value of the PSR when the state changes. The procedure for setting a value for the PSR is classified into a "procedure when a playback condition changes" and a "procedure when a stream is requested to change". the

"Process when playback conditions change" is a process to be executed when the state of the reproducing device is changed due to something happening to the device. the

"Process when stream change is requested" is a process to be performed when the user requests some change (in FIG. 29A, "change stream"). the

"Process when playback conditions change" and "Process when stream change is requested" are stream selection processes, which will be described in detail with reference to flowcharts. the

Arrows in Figure 29A symbolically indicate state transitions of the PSR. the

Annotations attached to the arrows indicate the events that trigger each state transition. That is, FIG. 29A indicates that if an event such as "load disc", "change stream", "start playlist playback", "cross play item (Play Item) boundary", or "stop playlist playback" , a state transition of PSR1 occurs. It should be understood by referring to FIG. 29A that the above procedure is not executed when a state transition of "invalid→invalid" or "valid→invalid" occurs. On the other hand, state transitions of "invalid→valid" and "valid→invalid" pass through the dotted line box. That is, when PSR1 is set to "valid", the above-described "procedure when playback condition changes" and "procedure when stream change is requested" are performed. the

The events that trigger state transitions are described below. the

The event "disk loaded" indicates that the BD-ROM has been loaded into the playback device. In such a load, PSR1 is immediately set to the unspecified value "0xFF". The event "playlist play start" indicates that playback processing based on the PlayList has started. When such an event occurs, "procedure when playback condition changes" is executed, and PSR1 is set to "valid". the

The event "Stop Playlist Playback" indicates that playback processing based on the PlayList has ended. It should be understood that when such an event occurs, the "procedure when the playback condition changes" is not executed, and PSR1 is set to "disabled". the

The event "change XXX" indicates that the user is requested to change XXX (in FIG. 29A, flow). If this event occurs while PSR1 is "invalid" (indicated by "cj1" in FIG. 29A), PSR1 is set to the required value. Even if the value set in this way represents a valid stream number, the value set in PSR1 is treated as an "invalid" value. That is, the PSR never goes from inactive to active in a state transition triggered by the event "change XXX". the

On the other hand, if the event "change stream" (indicated by "cj2" in FIG. 29A) occurs while PSR1 is "valid", then the "procedure when stream change is requested" is executed and PSR1 is set to the new value . Here, the value set at the time of performing the "procedure when flow change is required" may not be the value expected by the user. This is because the "procedure when a stream change is requested" has a function to exclude invalid values. If the event "change flow" occurs while PSR1 is "valid", PSR1 does not change from valid to invalid. This is because the "procedure when stream change is required" ensures that PSR1 does not become "invalid". the

The event "Crossing a Play Item Boundary" indicates that a Play Item (Play Item) boundary has been passed. Here, the play item boundary is the boundary between two consecutive play items, that is, the position between the end point of the previous play item and the start point of the next play item in two consecutive play items. If the event "PlayItem Boundary Crossed" occurs while PSR1 is "Active", "Process When Playback Condition Changes" is executed. After the "procedure when playback conditions change" is executed, the status of PSR1 either returns to "valid" or changes to "invalid". Since the STN_table is provided corresponding to each PlayItem, if a PlayItem changes, reproducible elementary streams also change. The object of state transition is to set PSR1 to the most appropriate value for each PlayItem by executing the "procedure when playback conditions change" every time reproduction of the PlayItem is started. the

In the state transition described above, the "procedure when the playback condition changes" is executed as shown in FIG. 29B. Fig. 29B is a flowchart of "Process when playback conditions change". This procedure sets a value in PSR1 by performing two decision steps S1 and S2. the

In step S1, it is judged whether the number of entries in the STN_table is "0". If it is judged that the number of entries in the STN_table is "0", the value of PSR1 is maintained (step S3). the

In step S2, if it is judged in step S1 that the number of entries in STN_table is not "0", it is judged whether the number of entries in STN_table is equal to or greater than PSR1 and condition (A) is true. Here, the condition (A) is that the reproduction device can reproduce the primary audio stream identified by PSR1. If the judgment result of step S2 is affirmative, the value of PSR1 is maintained (step S4). If the value of PSR1 is larger than the number of entries in STN_table or condition (A) is not satisfied, processing is performed to set PSR1 (step S5). the

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

In this flowchart, steps S6 and S7 constitute a loop, in which step S8 is repeatedly executed for all primary audio streams. In this loop, the main audio stream to be processed is called main audio stream i. In step S8, it is checked whether the primary audio stream i satisfies the conditions (a), (b) and (c). the

The condition (a) is that the playback device can play back the primary audio stream i, and it is judged whether the condition is satisfied by comparing the stream_coding_type of the PSR15 and the primary audio stream i. the

Condition (b) The language attribute of the main audio stream i is the same as the language setting in the playback device, and whether the condition is satisfied by checking whether the audio_language_code of the main audio stream i written in STN_stable is equal to the value set in the PSR. the

The condition (c) that the channel attribute of the main audio stream i is surround and the reproduction device can reproduce it is judged by comparing the PSR15 with the audio_presentation_type, stream_coding_type of the main audio stream i. the

According to ways (i) and (ii), this flowchart assigns priorities to the main audio stream, wherein (i) which condition among multiple conditions is met by the main audio stream i; (ii) how many conditions are met. the

After the processing is repeatedly performed for all primary audio streams, steps S9 to S13 are performed. In step S9, it is judged whether no primary audio stream satisfies the condition (a) is true. If judged true, an unspecified value (0xFF) is set for PSR1 (step S14). the

In step S10, it is judged whether there is a primary audio stream satisfying all conditions (a), (b) and (c). If the judgment is positive, the stream number of the primary audio stream that satisfies all the conditions (a), (b) and (c) is set in PSR1. the

Here, if multiple primary audio streams satisfy all conditions (a), (b) and (c), it is necessary to determine one of them to be set in PSR1. In step S15, it is determined according to the order of entries in the STN_table. That is, in step S15, if there are multiple primary audio streams with the same codec, language attribute and channel attribute, refer to the STN_table and select the primary audio stream whose entry order in the STN_table is the first. the

Therefore, the person in charge of editing can control the priority of streams to be reproduced by changing the order of entries in the STN_table. the

If no primary audio stream satisfies all of the conditions (a), (b) and (c), control goes to step S11 where it is judged whether there is a primary audio stream satisfying the conditions (a) and (b). If it is determined that there are primary audio streams satisfying the conditions (a) and (b), among these streams, the primary audio stream whose entry order in the STN_table is the first is set in PSR1 (step S16). the

If there is no primary audio stream that meets all of the conditions (a), (b) and (c), and there is no primary audio stream that meets the conditions (a) and (b), then control proceeds to step S12, where it is judged whether there is A primary audio stream that satisfies conditions (a) and (c). If it is determined that there are primary audio streams satisfying the conditions (a) and (c), among these streams, the primary audio stream whose entry order in the STN_table is the first is set in PSR1 (step S17). the

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), and there is no primary audio stream that satisfies conditions (a) and (c) If there is a primary audio stream, then the control proceeds to step S13, and it is judged in step S13 whether there is a primary audio stream satisfying the condition (a). If it is judged that there is a primary audio stream satisfying the condition (a), among these streams, the primary audio stream whose entry order in the STN_table is the first is set in PSR1 (step S18). the

So far, "the process when the playback condition changes" has been explained. From now on, "the procedure when the request flow is changed" will be explained. Fig. 31 is a flowchart showing the procedure for setting PSR1 when a stream change is required. The flowchart of FIG. 31 differs from the flowchart of FIG. 29B in that X is used in place of PSR1 in some places. “X” is a value determined according to user operation information output from the operation receiving unit 26 or a button command output from the PG decoder 13 . the

In step S19 of the flowchart, it is judged whether the number of entries in the STN_table is equal to or greater than X, and whether the condition (A) is true. Here, the condition (A) is that the reproducing device can reproduce the primary audio stream identified by PSR1. It is judged by comparing PSR15 with the stream_coding_type of the main audio stream. If the judgment result of step S19 is affirmative, X is set to PSR1 (step S21). the

If X is greater than the number of entries in the STN_table or the condition (A) is not satisfied, it is judged whether X is 0xFF. Here, if X is not 0xFF, it is considered that the number of the primary audio stream that the user wants to select is invalid, and the value X determined according to the user operation is ignored, and the value set in PSR1 is kept (step S23). the

If X is 0xFF, PSR1 is set (step S24). The processing procedure of step S24 is the same as the process shown in Figure 30 (in the steps shown in Figure 30, the judgment in step S9 is not needed in "the process when the flow is required to be changed". This is because in the "when the flow is required to change" process when changing", if no primary audio stream satisfies the conditions (a), (b) and (c), the X set by the user is not set to PSR1, and the value set in PSR1 is maintained). the

<Functional Structure Details 3: Process Execution Unit 43> 

When it is necessary to change one piece of PlayItem information to another, or when the user instructs to change the stream number through operation, the process execution unit 43 executes a predetermined stream selection process, and writes the new stream number into the PSR14. The playback device plays back the main audio stream based on the stream number written in PSR14. Therefore, the setting of PSR14 enables the selection of the primary audio stream. the

The process execution unit 43 causes the PSR 14 to realize the state transition as shown in FIG. 32A. the

Fig. 32A shows the state transition of the value set in PSR14. It should be noted here that in FIG. 32A , the term "valid" means that the value of PSR14 is equal to or less than the number of entries written in STN_table of PlayItem, and is decodable. the

The term "invalid" means that (a) the value of PSR14 is "0", (b) the value of PSR14 is greater than the number of entries written in the PlayItem's STN_table, or (c) even though there are entries written in the PlayItem's STN_table Amounts in the range "1" to "32" are also undecodable. the

The boxes drawn in dashed lines in FIG. 32A represent the process for determining the value of the PSR when the state changes. The procedure for setting a value for the PSR is classified into a "procedure when a playback condition changes" and a "procedure when a stream is requested to change". the

"Process when playback conditions change" is a process to be executed when the state of the reproducing device is changed due to something happening to the device. the

"Process when stream change is requested" is a process to be performed when the user requests some change (in FIG. 32A, "change stream"). the

"Process when playback conditions change" and "Process when stream change is requested" are stream selection processes, which will be described in detail with reference to flowcharts. the

The arrows in Figure 32A symbolically indicate the state transitions of the PSR. the

Callouts attached to the arrows indicate the events that trigger each state transition. That is, Figure 32A indicates that if an event such as "load disc", "change stream", "start playlist playback", "cross play item boundary", or "change primary audio stream" occurs, the PSR14 event occurs state transition. It should be understood by referring to FIG. 32A that the above-described process is not performed when a state transition of "invalid→invalid" or "valid→invalid" occurs. On the other hand, state transitions of "invalid→valid" and "valid→valid" pass through the dotted line box. That is, when the PSR 14 is set to "VALID", the above-described "procedure when playback condition changes" or "procedure when stream change is requested" is performed. the

The events that trigger state transitions are described below. the

The event "disk loaded" indicates that the BD-ROM has been loaded into the playback device. On such a load, PSR14 is immediately set to the unspecified value "0xFF". the

The event "playlist play start" indicates that playback processing based on the PlayList has started. When such an event occurs, "procedure when playback condition changes" is executed, and PSR14 is set to "valid". the

The event "stop playlist playback" indicates that playback processing based on PlayList has been terminated. It should be understood that when such an event occurs, "the process when the playback condition changes" is not executed, and PSR14 is set to "invalid". the

The event "Change XXX" indicates that the user requested a change of XXX (in FIG. 32A, flow). If this event occurs when PSR1 is "invalid" (indicated by "cj1" in Figure 32A), then PSR14 is set to the required value. Even if the value set in this way represents a valid stream number, the value set in PSR14 is treated as an "invalid" value. That is, the PSR never goes from inactive to active in a state transition triggered by the event "change XXX". the

On the other hand, if the event "change stream" (indicated by "cj2" in FIG. 32A) occurs while PSR14 is "valid", then the "procedure when stream change is requested" is executed and PSR14 is set to the new value . Here, the value set when performing the "procedure when flow change is required" may not be the value expected by the user. This is because the "procedure when a stream change is requested" has a function to exclude invalid values. If the event "change flow" occurs while PSR14 is "valid", PSR14 does not change from valid to invalid. This is because the "procedure when a stream change is requested" ensures that PSR14 does not become "invalid". the

The event "playitem boundary crossed" indicates that a playitem boundary has been passed. Here, the play item boundary is the boundary between two consecutive play items, that is, the position between the end point of the previous play item and the start point of the next play item in two continuous play items. If the event "play item boundary crossed" occurs when PSR 14 is "valid", then "procedure when playback condition changes" is performed. After the "procedure when playback condition changes" is executed, the state of PSR 14 either returns to "valid" or transitions to "inactive" if an event "play item boundary crossed" or "primary audio stream changed" occurs. The purpose of the state transition is to set the PSR14 to the most appropriate value for each PlayItem by executing the "procedure when playback conditions change" every time reproduction of the PlayItem is to be started or each time the main audio stream is changed. the

In the state transition described above, the "procedure when the playback condition changes" is executed as shown in FIG. 32B. This process sets a value in PSR14 by performing two decision steps S31 and S32. the

In step S31, it is judged whether the number of entries in the STN_table is "0". If it is judged that the number of entries in the STN_table is "0", the value of PSR14 is held (step S33). the

In step S32, if it is judged in step S31 that the number of entries in STN_table is not "0", then it is judged whether the number of entries in STN_stable is equal to or greater than PSR14, and whether condition (A) and condition (B) are true . Here, the condition (A) is that the playback device can play back the primary audio stream identified by PSR14, and the condition (B) is that the combination of Primary_Audio_Stream_Number and Second_Audio_Stream_Number is allowed in the STN_table. If the judgment result of step S32 is negative ("No" in step S32), the value set in PSR14 is maintained (step S34). If the judgment result of step S32 is affirmative (YES in step S32), a process of setting PSR14 is performed (step S35). the

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

In this flowchart, steps S36 and S37 constitute a loop in which step S38 is repeatedly executed for all secondary audio streams. In this loop, the sub-audio stream to be processed is referred to as sub-audio stream i. In step S38, it is checked whether the secondary audio stream i satisfies the conditions (a), (b) and (c). the

The condition (a) is that the reproduction device can reproduce the sub-audio stream i, and it is judged whether or not the condition is satisfied by comparing the register (PSR15) indicating the reproduction capability of the audio stream with the stream_coding_type of the sub-audio stream i. the

Condition (b) primary audio stream can be mixed with secondary audio stream, and whether write Comb_info_Secondary_audio_Primary _audio by checking the stream number that is set in PSR14 to judge whether to meet this condition. the

The condition (c) is that the language attribute of the secondary audio stream i is the same as the language setting in the playback device, and whether the condition is satisfied is determined by checking whether the audio_language_code of the secondary audio stream i written in the STN_table is equal to the value set in the PSR. the

According to methods (i) and (ii), this flow chart assigns priorities to secondary audio streams, where (i) indicates which condition among multiple conditions the secondary audio stream i satisfies, and (ii) indicates how many conditions are met. the

After the processing is repeatedly performed for all secondary audio streams, steps S39 to S41 and steps S44 to S46 are performed. In step S39, it is judged whether no secondary audio stream satisfies the conditions (a) and (b) are true. If judged true, an unspecified value (0xFF) is set for PSR14 (step S44). the

In step 40, it is judged whether there is a secondary audio stream satisfying all conditions (a), (b) and (c). If the judgment is affirmative, the stream number of such a secondary audio stream satisfying all conditions (a), (b) and (c) is set in PSR14. the

Here, if there are multiple secondary audio streams satisfying all the conditions (a), (b) and (c), it is necessary to determine one of them to be set in the PSR14. In step S45, it is determined according to the order of entries in the STN_table. That is, in step S45, if there are multiple secondary audio streams identical in codec, language attribute, and channel attribute, refer to the STN_table and select the secondary audio stream whose entry order in the STN_table is the first. the

Therefore, by changing the order of entries in the STN_table, the person in charge of editing can control the priority of streams to be reproduced. the

If there is no secondary audio stream satisfying all conditions (a), (b) and (c), control goes to step S41 where it is judged whether there is a secondary audio stream satisfying conditions (a) and (b). If it is determined that there are secondary audio streams satisfying the conditions (a) and (b), among these streams, the secondary audio stream whose entry order in the STN_table is the first is set in the PSR14 (step S46). the

So far, "the process when the playback condition changes" has been explained. From now on, "the procedure when the request flow is changed" will be explained. Fig. 34 is a flowchart showing the procedure for setting the PSR 14 when a stream change is required. The flowchart of FIG. 34 differs from the flowchart of FIG. 32B in that, in some places, X is used instead of PSR14. “X” is a value determined according to user operation information output from the operation receiving unit 26 or a button command output from the PG decoder 13 . the

In step S49 of the flowchart, it is judged whether the number of entries in the STN_table is equal to or greater than X, and whether the conditions (A) and (B) are true. If the judgment result of step S49 is affirmative, X is set to PSR14 (step S51). the

If either X is greater than the number of entries in the STN_table or conditions (A) and (B) are not satisfied, it is judged whether X is 0xFF (step S52 ). Here, if X is not 0xFF, it is considered that the number of the secondary audio stream that the user wants to select is invalid, and the value X determined according to the user operation is ignored, and the value set in PSR14 is maintained (step S53). the

If X is 0xFF, PSR14 is set (step S54). The processing procedure of step S54 is the same as the procedure shown in FIG. 33 (in the steps shown in FIG. 30 , the judgment in step S39 is not needed in “the process when the flow is required to be changed”. This is because in the “when the flow is required to If there is no sub-audio stream that satisfies the conditions (a), (b) and (c), X set by the user cannot be set to PSR14, and the value set in PSR14 remains). the

This completes the description of the process execution unit 43 . the

<Functional Structure Details 4: Hybrid Control Unit 44> 

If the player profile information is 0001h or 0011h, the mixing control unit 44 controls the mixers 9a and 9b to mix the reproduction output of the primary audio stream with the reproduction output of the secondary audio stream or the reproduction output of the sound data. the

When the current reproduction point in the PlayItem time axis is within the time period from In_time to Out_time of the SubPlayItem information, and when the sub-audio stream is valid in the STN_Table of the current PlayItem information, the mixing control unit 44 controls the mixer 9a to combine the audio The reproduction output of the decoder 7a is mixed with the reproduction output of the audio decoder 7b because the audio decoder 7b is decoding the secondary audio stream with the stream number stored in the PSR14. the

If the attribute of the primary audio stream is "surround", it is possible to mix the reproduction output of the secondary audio stream after performing downmixing so that in components such as L, R, C, LS, RS, LR, RR, and LFE Only keep desired portions. Here, when the secondary audio stream is, for example, a commentary of a movie director, by changing the channel of the primary audio stream mixed with the secondary audio stream from L to C and to R, the user can feel as if the director is by his side. Such mixing is called panning. In roaming, use the sound/speech of the secondary audio stream which has fewer channels than the primary audio stream (for example, monophonic). the

When a confirmation operation is performed on a button drawn by a Java ^™ application, or when a confirmation operation is performed on a button drawn by an IG stream, the mixing control unit 44 controls the mixer 9b to output sound data with reproduction of the main audio stream , or mixed with the result of mixing the reproduction output of the primary audio stream and the reproduction output of the secondary audio stream.

As described above, according to the present embodiment, the demultiplexer 3b can obtain the TS packets transmitted on the bus 1b, refer to the upper byte of the PID, and input the TS packets to the decoder dedicated to the secondary audio stream. With this structure, the demultiplexer 3b can demultiplex only the PES packets constituting the secondary audio stream, and input the PES packets to a decoder different from that dedicated to the primary audio stream. the

Since the packets constituting the primary audio stream and the packets constituting the secondary audio stream can be input to different decoders, for example, only the gain of the packets constituting the primary audio stream can be down-converted, down-mixed, or reduced. This makes it possible to use only the components that make up the primary audio stream even when the secondary audio stream is read from the local storage 200 while the primary audio stream is read from the BD-ROM 100, and the two streams are supplied to two corresponding decoders. Packets undergo special processing in real time. the

Second embodiment

The second embodiment of the present invention relates to selecting means for decoding the primary audio stream in the reproduction device 300 and the AV amplifier 500 of the home theater system. the

FIG. 35A shows the connection form of the reproducing apparatus 300, the AV amplifier 500 and the speaker 600. The connection form in the home theater system is classified into a form in which the reproducing apparatus 300 is directly connected to the speaker 600 without connecting to the AV amplifier 500 in between (connection form (1)), and a form in which the reproducing apparatus 300 is connected to the speaker 600 via the AV amplifier 500 form(join form(2)). the

In the former connection form (1), LPCM obtained by decoding by the reproduction device 300 is supplied to the speaker 600 . On the other hand, in the latter connection form (2), the reproduction device 300 performs only pass-through output, and the LPCM obtained by decoding by the AV amplifier 500 is supplied to the speaker 600 . the

When two or more connection types are available in a home theater system, the number of channels in each device of the home theater system changes. the

FIG. 35B shows how the number of channels changes in each of the reproducing apparatus 300, the AV amplifier 500, and the speaker 600. The first row of FIG. 35B shows each of BD-ROM 100 , reproduction device 300 , AV amplifier 500 and speaker 600 . Regarding the decoding capabilities of these devices, the playback device 300 can decode up to 5.1 channels, the AV amplifier 500 can decode up to 7.1 channels, and the speaker 600 can decode up to 7.1 channels. the

The second to fourth rows show by which device and how the downmix is done when the BD-ROM 100 has 7.1-channel and 5.1-channel main audio streams. The second row shows that the BD-ROM 100 has a 7.1-channel main audio stream and that it is decoded by the playback device 300. In this case, the playback device 300 reads the 7.1-channel main audio stream from the BD-ROM 100, decodes and downmixes it to 5.1-channel, and then outputs the down-mixed 5.1-channel LPCM. The AV amplifier 500 converts the down-mixed 5.1-channel LPCM into 7.1-channel, and outputs the converted 7.1-channel LPCM to the speaker 600 . the

The third row shows the case where the BD-ROM 100 has a main audio stream of 5.1 channels. In this case, the reproduction device 300 decodes the 5.1-channel main audio stream, and outputs LPCM as the decoding result to the AV amplifier 500 without downmixing. AV amplifier 500 converts 5.1-channel LPCM into 7.1-channel, and outputs the converted 7.1-channel LPCM to speaker 600 . the

The fourth row shows the case where the BD-ROM 100 has a 7.1-channel main audio stream and is output by the playback device 300 through the transfer port. In this case, decoding is performed by the AV amplifier 500, and 7.1-channel sound/voice that is the decoding result of the AV amplifier 500 is supplied to the speaker 600 and output as sound/voice. the

These outputs are compared below. In the case of the second row, the reproducing device 300 converts the sound/voice from 7.1 channels to 5.1 channels, and then the AV amplifier 500 converts it from 5.1 channels to 7.1 channels, and converts the 7.1-channel sound/voice Output to speaker 600. With this configuration, although the audio stream recorded on the BD-ROM 100 is 7.1 channel, the audio quality of the final output sound/voice in the case of the second row is almost the same as that of the final output sound/voice in the case of the third row The audio quality is no different. the

On the other hand, in the case of the fourth row, since the AV amplifier 500 having a 7.1-channel decoding capability is used to decode the 7.1-channel audio stream, high-quality output is expected. the

In the present embodiment, in such an output form, when the device to which the reproducing device is connected has a reproducing capability, the reproducing device performs port output so that the device performs decoding. the

The DIB (Decoder Information Block) of HDMI is used to determine how high a reproduction capability or decoding capability the device of the connection partner has, or to determine whether to perform stream output. Figure 36A shows the DIB. the

As shown in FIG. 36A, the DIB includes: "encoding type" showing the encoding method by which output to the AV amplifier 500 can be performed; "channel count" showing the number of channels that can be decoded by the device connected to the other party; displaying "Channel/Speaker Configuration" for the arrangement of the speakers; and "Sampling Frequency" showing the frequency that the connected partner's device can reproduce. the

Fig. 36B shows values that can be set in each field of DIB. the

In the example of FIG. 36B , the row of "encoding type" shows encoding methods DTS-HD, MLP, and DD+ by which the device of the connection partner can decode. In the actual writing of "Coding Type", four parameters "CT0", "CT1", "CT2" and "CT3" are used. Also, the row of "Channel Count" shows 5.1ch, 7.1ch, and 2ch, which are the number of channels that can be decoded by the connected partner's device. the

Also, the row for "Channel/Speaker Configuration" shows "L/R/C/LS/RS/LFE", "L/R/C/LS/RS/LR/RR/LFE" and "L/R" , which represent the physical arrangement of the loudspeakers for 5.1ch, 7.1ch, and 2ch, respectively. the

The row of "sampling frequency" shows sampling frequencies "48KHz", "192KHz", and "96KHz". the

FIG. 36C shows a communication sequence between the reproduction apparatus 300 and the AV amplifier 500 using the DIB. the

When the reproducing device 300 is connected with the AV amplifier 500, the HDMI transmission/receiving unit 27 of the reproducing device 300 and the AV amplifier 500 perform mutual authentication shown by "◎1", and then as shown in "◎2", it acts as a receiver DIB is received from the AV amplifier 500 . After referring to the DIB, if it is confirmed that the AV amplifier 500 can decode the main audio stream, the playback device 300 can output the main audio stream to the AV amplifier 500 through the port output, as shown in "◎3". If the AV amplifier 500 cannot decode the main audio stream, it either transmits the LPCM decoded by the reproducing device, or does not reproduce the stream. the

Modifications to the reproducing apparatus in the second embodiment will be described below. the

FIG. 37 shows the internal structure of PSR15 in PSR group 23. the

Like PSR1, PSR14, and PSR31 described in the first embodiment, PSR15 is 32 bits long. the

Bits b0 to b3 show whether the reproducing device is capable of decoding and reproducing the LPCM audio stream. When the four bits are "0001"b, it indicates that the reproducing device is capable of reproducing a 48/96 Hz LPCM audio stream having stereo properties. When the four bits are "0010"b, it indicates that the reproducing device is capable of reproducing a 48/96Hz LPCM audio stream with surround properties. When the four bits are "0101"b, it indicates that the reproducing apparatus is capable of reproducing an LPCM audio stream of any frequency having a stereo property. When the four bits are "0110"b, it indicates that the reproducing apparatus is capable of reproducing an LPCM audio stream of any frequency having a surround property. the

Bits b4 to b7 of PSR15 show whether the reproducing device is capable of decoding and reproducing the DD/DD+ audio stream. When the lower two bits of the four bits are "01"b, it indicates that the reproducing apparatus can reproduce at most two channels (2ch) of the basic data (independent sub-stream) of the DD/DD+ audio stream. When the lower two digits of the four bits are "10"b, it indicates that the reproducing apparatus is capable of reproducing basic data (independent substreams) of a DD/DD+ audio stream of multi-channel (the number of channels is greater than 2ch). the

When the upper two digits of the four digits are "01"b, it indicates that the reproduction device can reproduce the extension data (non-independent substream) of the DD/DD+ audio stream of two channels (2ch) at most. When the lower two digits of four bits are "10"b, it indicates that the reproducing apparatus is capable of reproducing the extension data (non-independent substream) of the DD/DD+ audio stream of multiple channels (the number of channels is greater than 2ch). the

When the upper two bits of the four bits are "00"b, it indicates that the reproducing device cannot reproduce the extension data (non-independent substream) of the DD/DD+ audio stream. the

Bits b8 to b11 of PSR15 show whether the reproducing device can decode and reproduce the DTS-HD audio stream. When the lower two bits of the four bits are "01"b, it indicates that the reproducing apparatus can reproduce up to two channels (2ch) of the basic data (core substream) of the DTS-HD audio stream. When the lower two bits of the four bits are "10"b, it indicates that the reproducing apparatus is capable of reproducing multiple channels of the basic data (core substream) of the DTS-HD audio stream. the

When the upper two bits of the four bits are "01"b, it indicates the ability of the reproduction device to reproduce extended data (extended sub-stream) of a DTS-HD audio stream of a maximum of two channels (2ch). When the upper two bits of the four bits are "10"b, it indicates that the reproducing apparatus is capable of reproducing extended data (extended substream) of a DTS-HD audio stream of multiple channels. the

When the upper two bits of the four bits are "00"b, it indicates that the reproduction device cannot reproduce the extension data (extension substream) of the DTS-HD audio stream. the

Bits b12 to b15 of PSR15 show whether the reproducing device is capable of decoding and reproducing the DD/MLP audio stream. When the lower two bits of the four bits are "01"b, it indicates that the reproducing apparatus can reproduce DD audio streams of two channels (2ch) at most. When the lower two bits of the four bits are "10"b, it indicates that the reproducing apparatus is capable of reproducing a DD audio stream of multiple channels. the

When the upper two bits of the four bits are "01"b, it indicates that the reproducing apparatus can reproduce at most two channels (2ch) of the MLP audio stream. When the upper two bits of the four bits are "10"b, it indicates that the reproducing device is capable of reproducing multiple channels of the MLP audio stream. the

When the upper two bits of the four bits are "00"b, it indicates that the reproducing device cannot reproduce the MLP audio stream. the

As described above, the PSR 15 can define for each encoding method whether or not the reproducing apparatus can handle basic data and extended data. Here, "2ch" used in the description of the PSR15 refers to two channels of L and R, respectively. the

With this definition of PSR 15, the controller 22 in the second embodiment executes reproduction control of the main audio stream in accordance with the flow shown in FIG. 38 . FIG. 38 is a flowchart showing the processing procedure of the controller 22 in the second embodiment. the

In step S61, it is judged whether or not the reproduction device has been activated. If it is judged that the reproduction device has been activated, the device of the partner via HDMI connection is authenticated (step S62). When the connected devices successfully authenticate each other, control moves to step S63. Step S63 is a loop in which it is repeatedly judged whether or not the DIB has been received. If it is judged that the DIB has been received (YES in step S63), the controller 22 identifies the reproduction capability and the number of speakers (arrangements) of the connection partner by referring to the DIB received from the connection partner (step S64). Then, in step S65, it is judged whether or not the connection partner has reproduction capability. If it is judged that the connection partner has reproduction capability, the controller 22 displays a menu for receiving a port output request (step S67), and judges whether the user requests port output (step S68). the

It should be noted here that if it is recognized by referring to the DIB that the device connected to the speaker (AV amplifier in many cases) has a decoding capability, the port output may be automatically set (YES in step S68), thereby making the connection The other party's device performs decoding without allowing user settings. the

In addition, it may be set in advance that if the device of the connection partner is recognized to have a decoding capability by referring to the device setting menu (initial setting menu) of the reproducing device 300, the port output is automatically set (YES in step S68). the

39 and 40 show menus for receiving a determination as to whether to perform transfer port output. Each of the menus shown in FIGS. 39 and 40 is composed of a message supposed to attract the user's attention: "In your theater system, audio decoding is available at the connection destination device"; or "When the connection destination device XXX executes When audio decoding, you can enjoy high-quality audio"; and "Yes" and "No" buttons for receiving determination as to whether to allow the connection destination device to perform decoding. the

In the message shown in the menu of FIG. 40, "XXX" can be filled with the product name or the model number of the AV amplifier 500. Alternatively, "XXX" may be filled in the product name or the model of the TV set 400 and the model of the AV amplifier 500, allowing the user to choose among them. This enables the user to select the device that will perform the decoding. Furthermore, if the user has two or more AV amplifiers, it is preferable to display the product name and/or model number of the AV amplifier so that the user can select one among them. the

When the user confirms on the "Yes" button of the menu to indicate the port output, the player capability for audio is set in the PSR15 according to the DIB (step S71), and the process execution unit 42 is made to execute the decoding capability according to the AV amplifier 500 The process of selecting the main audio stream (step S72). After that, the main audio stream of the AVClip read from the BD-ROM is output through the port output (step S73). the

If the user does not perform the operation of causing the AV amplifier 500 to perform decoding, the controller 22 sets the PSR 15 according to the decoding capability of the reproduction device itself, makes the reproduction execution unit 42 perform the process of selecting the main audio stream (step S69), and makes the decoding by the reproduction device The sound/speech (LPCM) of is output (step S70). the

41 and 42 are flowcharts showing the procedure for setting the player capability of audio in PSR15 according to DIB. the

In the flowchart of FIG. 41, in step S200, it is judged whether or not DIB.CODING_TYPE indicates DD+. the

If it is judged that DIB.CODING_TYPE indicates DD+, then the control moves to step S201, where it is judged whether the channel count of DIB has a value greater than 2. If the determination at step S201 is affirmative, control moves to step S203 where "capability" of the dependent sub-stream is set to 10b: surround capability. the

If NO in step S201, control moves to step S205 where "capability" of the dependent sub-stream is set to 01b: stereo capability. the

In the flowchart of FIG. 42, in step S82, it is judged whether or not DIB.CODING_TYPE indicates MLP. If it is judged that DIB.CODING_TYPE indicates MLP (YES in step S82), control moves to step S91 where it is judged whether or not the channel count of the DIB has a value greater than 2. the

If the determination at step S91 is affirmative ("YES" in step S91), control moves to step S93 where "capability" of the MLP is set to 10b: surround capability. If NO in step S91, control moves to step S94 where the "capability" of the MLP is set to 01b: stereo capability. the

It should be noted here that although the channel count of the DIB is used in the judgment of steps S201 and S91 in FIGS. 41 and 42 , the channel/speaker configuration may be used instead. the

As described above, according to the present embodiment, information on the capability of the connection partner device is obtained via a digital interface such as HDMI, and the PSR 15 is set in accordance with the obtained capability information. Also, a main audio stream is selected from the BD-ROM disc/local storage, and pass-through output of the selected main audio stream is performed. This enables efficient use of decoder resources of the connected counterpart device to achieve high-quality audio reproduction. Also, since AV amplifiers and speakers are often developed/sold as a set. In such cases, the AV amplifier provides adjustments to match the characteristics of the speakers. Therefore, even if the reproducing device is capable of decoding using its internal decoder, it is possible to cause the AV amplifier connected to the reproducing device to perform decoding to obtain an acoustically higher quality reproduction result. the

third embodiment

The local storage 200 in the first embodiment is a hard disk embedded in the reproducing apparatus, whereas the local storage 200 in the third embodiment is an SD memory card as a portable recording medium. The present embodiment relates to improvement when a dynamic scenario is recorded in a portable recording medium used by a reproduction apparatus. the

An SD memory card is a portable recording medium that has a secure area and a non-secure area. A file on a local storage such as those shown in the first embodiment is recorded in a non-secure area after it is encoded, and a key is recorded in a secure area. The key cannot be read from the secure area unless the reader's authenticity has been confirmed by authentication performed by the SD memory card. This structure prevents unauthorized copying of files from a non-secure area, and enables reading of files only when the BD-ROM is accessible. the

A dynamic scenario is a program such as a Java ^TM application program or a Movie Object explained in the first embodiment, which causes the reproduction device to perform reproduction through PlayList information. Dynamic scenarios can be recorded on the BD-ROM 100 or the local storage 200 . When a dynamic scenario is recorded on a portable recording medium, it means that the dynamic scenario can be accessed by any reproduction apparatus installed in various locations. Therefore, the dynamic scenario can be accessed by the playback device 300 installed in the car.

Fig. 43A shows the reproducing device 300 installed in an automobile. The reproduction device 300 and the television 400 constitute a car audio system. The portable local storage 200 can be installed in the playback device 300 together with the BD-ROM 100. the

When the reproducing device 300 is installed in a car, it is preferable to clearly indicate that the reproducing device 300 is operated similarly to a CD reproducing device. In order to clearly indicate that the reproducing apparatus 300 is operated like a CD reproducing apparatus, the PSR 31 in this embodiment is constructed as shown in FIG. 43B. the

Fig. 43B shows the internal structure of PSR31 in the third embodiment. When the reproducing apparatus is installed in a car, the player profile information of the PSR31 in the third embodiment is set to "1000"b by the manufacturer's engineer or by the end user. When the profile information of PSR31 is set to "1000"b, the profile information indicates that the reproducing apparatus is operated as an audio profile player. Here, "audio profile player" indicates that the reproducing device is not adapted to be operated via an interactive screen, but is operated like a CD player (that is, the reproducing device is a BD-ROM reproducing The reproduction control of the content is performed by the linear operation of the content, and the reproduction control of the content is not prepared via the GUI or the like, or the reproduction device temporarily shifts to such a mode when it detects that the car is running). the

When the reproducing apparatus is similar to a CD player, content is reproduced through operations performed in units of chapters, such as chapter skipping and chapter searching. Chapters are defined by PlayListMark information shown in FIG. 17 . the

The PlayList Mark information is explained below. the

Fig. 44 shows the internal structure of PlayList Mark information contained in PlayList information. As shown by the lead line pm0 in the accompanying drawing, the PlayList Mark information includes multiple pieces of PL Mark information (#1-#n). PLMark information (PL Mark()) specifies a given position on the PL time axis as a chapter point. As shown by lead line pm1 in the drawing, the PlayList Mark information includes: "ref_to_PlayItem_Id" indicating a PlayItem that is an object of chapter designation; and "Mark_time_stamp" indicating a chapter position in the PlayItem by a time notation. the

Fig. 45 shows the designation of chapter positions according to PL Mark information. The second to fifth lines of FIG. 45 show EP_map and AVClip shown in FIG. 10 . the

The first line shows PL Mark information and PL timeline. Two pieces of PL Mark information #1 and #2 are displayed in the first row. Arrows kt1 and kt2 indicate the designation of PlayItem through ref_to_PlayItem_Id in PL Mark information. According to the arrow, it can be understood that the ref_to_PlayItem_Id in the PL Mark information specifies the PlayItem to be referenced. Also, Mark_time_stamp indicates the times of chapters #1 and #2 on the PL time axis. In this way, PL Mark information defines chapter points on the PlayItem time axis. the

So far, the PL Mark information has been explained. From now on, improvements to dynamic scripts will be explained. the

In the case where a program is embedded in a reproduction device, it is known at the manufacturing stage whether the program is for use in a car or in a home theater system. However, when a dynamic scenario (Movie Object, Java ^TM application) is provided to the playback device via the BD-ROM 100 or the portable local storage 200, it cannot be known in advance whether the program is used in a car or in a home theater system. This is because the user determines whether the BD-ROM 100 or the local storage 200 as an SD memory card is to be used for the reproduction device.

For this reason, when setting the player profile information to designate the audio profile player, Movie Object or Java ^(TM) application needs to control the reproduction device operation to be operated like a CD player. On the other hand, when the player profile information is set to others, it is preferable to operate the reproducing apparatus via an interactive screen.

Fig. 46 is a flowchart of the processing procedure of the Java ^™ application in this embodiment.

In step S149, it is judged whether or not PSR31 is set to designate an audio profile player. If the judgment result in step S149 is negative, playback of PlayList is started (step S150). Control then moves to the loop in step S151. the

Step S151 constitutes a loop waiting for a menu call operation. If it is judged that a menu call operation has been performed, the menu is displayed (step S152), and steps S153 to S156 are performed. In step S153, it is judged whether or not a focus moving operation has been performed. If it is judged that a focus moving operation has been performed, the focus is moved to another button (step S155). the

In step S154, it is judged whether the operation of confirming on the button has been performed. If it is judged that an operation for confirming on the button has been performed, processing corresponding to the button is performed (step S156). the

If it is judged in step S149 that the PSR 31 is set to designate the audio profile player (YES in step S149), the PlayList of audio notification is reproduced to notify the user to perform linear CD-like reproduction. Control then moves to the loop consisting of steps S158 to S159. the

In step S158, it is judged whether or not a numerical value has been input. In step S159, it is judged whether the forward skip key or the backward skip key has been operated. the

If it is judged in step S158 that a numerical value has been entered, control moves to step S160, where a chapter search function is performed. If it is judged in step S159 that the skip forward key or the skip backward key has been operated, control moves to step S161, where a chapter skip function is performed. the

In the examples provided above, a Java ^(TM) application was used. When a MovieObject is used, steps S153 to S155 are performed using a navigation command in an IG stream or a navigation command of a Movie Object. The operation in this case is similar to that in the case of a Java ^™ application, so description is omitted.

A description of the procedures of chapter search and chapter skip is provided below with reference to flowcharts. Fig. 47 is a flowchart showing the procedure of chapter search. the

First, the PL Mark information corresponding to the input value is set as the current PL Mark (step S125). Secondly, in step S126, the PI written in the ref_to_PlayItem_Id of the current PL Mark is set to PlayItem#x (step S126). In step S127, the Clip information specified by Clip_information_file_name of PlayItem#x is read. In step S128, the Mark_time_stamp of the current PLMark is converted into an I picture address u by using the EP_map of the current Clip information. the

In step S129, Out_time of PlayItem#x is converted into I picture address v using EP_map of current Clip information. In step S130, the decoder is instructed to output data extending from the Mark_time_stamp of the current PLMark to the Out_time of PlayItem#x. So far, chapter search has been explained. From now on, the description chapters will be skipped. Fig. 48 is a flowchart showing the procedure of chapter skipping. the

In step S132, it is judged which one of the skip forward key and the skip backward key is pressed. If it is judged that the backward jump key is pressed, control moves to step S133, where the direction flag is set to -1. If it is judged that the skip forward key is pressed, control moves to step S134, where the direction flag is set to +1. the

In step S135, the current PI number and the current PTM are converted to specify the current PL Mark. In step S136, the result obtained by adding the value of the direction flag to the current PLMark number is set as the current PLMark number. Here, in the case of the forward jump key, the direction flag has been set to +1, so the current PL Mark number is increased; in the case of the backward jump key, the direction flag has been set to -1, so the current PL Mark number decrease. After the PL Mark information is set in this way, the TS packet is read by performing steps S126 to S130, as shown in FIG. 47 . the

So far, the procedure of the playback device in playback based on PL Mark information has been described. the

As described above, according to the present embodiment, when the PSR 31 is set to designate the audio profile player, dynamic scripts such as Movie Object or Java ^™ application can be used, thereby enabling the user to reproduce PlayList. With this structure, the user can operate the BD-ROM in the same manner as a music CD. More specifically, the chapter search/skip function corresponds to the function of search/skip songs in a music CD. Furthermore, when the dynamic script is run on a rendering device that is not configured as an audio profile player, interactive rendering is available through a GUI-based menu that is displayed, assuming an image is output. In the case of performing reproduction via an interface such as HDMI, which enables monitoring of the status of a connected device, the following functions are available. That is to say, it is possible to monitor the ON/OFF of the power supply of the monitor, or monitor the selection of the input source image, and if it is detected that the monitor monitor does not display the reproduced image, the PSR31 can be set to specify the audio profile player, or the reproduction can be paused, or The reproduction device 300 together with the monitor display can be turned off.

Fourth embodiment

The fourth embodiment relates to how to obtain PlayList information, Clip information, or AVClip information described in the first embodiment. Central to the acquisition process is the Java ^(TM) application. This is because the Java( ^TM) application is able to form a connection on the network and submit the desired file from the server device.

Connections for retrieving files from the server can be established using the open connection methods provided in the Java ^™ software library called Java ^™ .net. The following is an example of this connection when the URL of the file in the server is http://xxx.com/vp_data/0.m2ts.

example:

The new Java ^TM .net.URL (http://xxx.com/vp_data/0.m2ts.

OpenConnection()

Fig. 49 is a flowchart of the Java ^™ application in the fourth embodiment. In step S181, playback of the PlayList in the BD-ROM is started. After that, in step S182, "Organization" and "Disc-id" are read from the BD-ROM, where "Organization" indicates the company or organization that distributes the BD-ROM, and "Disc-id" is the identifier of the BD-ROM .

In step S183, it is judged whether or not it is true that the local storage 200 does not have an area corresponding to the Organization or Disc-id read in step S182. the

If it is judged that the local storage 200 does not have such an area, control transfers to step S184, where it is judged whether the player profile of the PSR31 is not "0000" b is true. the

If the judgment result in step S183 or step S184 is "No", then the current processing ends. If the local device 200 does not have an area corresponding to Organization or Disc-id, and if audio mixing can be performed, the judgment results in both step S183 and step S184 are "Yes". the

If the judgment results in both step S183 and step S184 are "Yes", a menu with an "update button" is displayed (step S185). Then, wait for confirmation on "update button" (step S186). the

Fig. 50 shows an example of displaying a menu with an "update button". In FIG. 50, the button "update" is the above-mentioned "update button". If an operation is performed to confirm on the "update button", the Disc-id and PlayList-id are sent to the server device in step S187. the

Disc-id is identification information of a BD-ROM, and PlayList-id is identification information of a PlayList being played back. The server device uses this information to select additional content to acquire on the content provider's database. The selected additional content is sent back to the rendering device over the network. Additional content includes a set of files (PlayList information, Clip information, and AVClip) to be recorded on the local storage 200 . the

In step S188, the reception of additional content is waited for. If additional content is received, control moves to step S189 where PlayList information, Clip information, and AVClip constituting the received additional content are written to the local storage 200 . After that, if the download from the server device is completed and the mix has become available in reproduction, the user is notified that the mix is available in reproduction (step S190). Processing then enters a loop, waiting for the user to request mixing (step S191). If the user requests mixing, control moves to step S192, where playback of the PlayList is stopped, and a Virtual Package is constructed. the

Asks the server if an update is available, and whether downloading for the updated content can be performed at any time. For example, they can be run periodically when loading a disc or rendering content. In addition, the user can inquire whether to reproduce the content immediately after preparing to start reproduction (immediately after preparing to reproduce the virtual package). the

As described above, according to the present embodiment, when a PlayList is initially reproduced, an AVClip is reproduced while downloading is performed, and the user can observe a reproduced image of the PlayList while waiting for data to be downloaded into the local storage 200 . This prevents the user from idly waiting for data to be downloaded into the local storage 200 even if the data as one file in the local storage 200 has several hundred megabytes. the

Here, a condition for deleting the extra content from the local storage 200 may be set in the reproducing apparatus 300 as an initial setting, and the reproducing apparatus 300 may delete the extra content according to the initial setting. For example, it may be preferable to initially set up an input specifying the time of receipt, and delete the extra content at a predetermined time (eg, automatically delete the extra content after one month has passed). the

Alternatively, when the BD-ROM is ejected, the user may be asked whether to delete the extra content from the local storage 200, and if the user answers in the affirmative, the extra content may be deleted. the

Furthermore, when the BD-ROM is a partial disc (partial disc) having a read-only area and a writable area, additional content in the local storage 200 can be written in the rewritable area of the partial disc. the

<Supplementary note>

So far, the best mode known to the applicants for carrying out the invention at the time of filing the application has been described. However, the present invention can be further improved or modified in terms of the following technical problems. It should be noted here that whether improvement or modification is made is optional, depending on the implementation of the present invention. the

<Settings to be made for additional content>

Preferably, the rendering device is initially set to delete additional content from local storage 200 after a few months or years after downloading. the

<Substitute for PID>

In the first embodiment, the PID is used to distinguish the primary audio stream from the secondary audio stream. In case of using MPEG2-PS instead, it is preferable that the PES headers of the primary audio stream and the secondary audio stream have different stream_ids. the

Only the primary audio stream and the secondary audio stream are required to be identifiable at the system stream level, so that both audio streams are identifiable by a demultiplexer. Alternatively, only the PID of one stream is required to be changed before the two streams are combined into one, so that the two streams can be identified. the

<Implementation of control process>

The control process described by using the flow chart in the above embodiment and the control process of the functional components described in the above embodiment all meet the requirements of the "program invention", because the above control process is implemented using hardware resources. And is the creation of technical ideas utilizing the laws of nature. the

Generation of the program of the present invention

The program of the present invention is an object program (object program) that can be run on a computer. The object program is composed of one or more program codes that enable the computer to execute each step or each process of the functional unit in the flowchart. There are various types of program code, such as processor's native code and Java ^TM byte code. There are also various forms of implementing the steps of the program code. For example, when each step can be realized by using an external function, a call statement for calling the external function is used as the program code. Program codes implementing a step may belong to different object programs. In a RISC processor in which instruction types are limited, each step of the flowchart can be realized by combining arithmetic operation instructions, logical operation instructions, branch instructions, and the like.

The program of the present invention can be generated as follows. First, a software developer uses a programming language to write a source program that implements each flow chart and functional component. In this process, the software developer uses class structures, variables, array variables, calls to external functions, etc. that conform to the statement structure of the programming language he/she uses. the

Send the written source program to the compiler as a file. A compiler compiles a source program and produces an object program. the

Compilation performed by the compiler includes processes such as statement structure analysis, optimization, resource allocation, and code generation. In sentence structure analysis, characters and phrases, sentence structures, and the meaning of source programs are analyzed, and the source programs are converted into intermediate programs. In optimization, intermediate programs undergo processes such as basic block setup, control flow analysis, and data flow analysis. In resource allocation, in order to adapt to the instruction set of the target processor, the variables of the intermediate program are allocated to the registers or memory of the target processor. In code generation, each intermediate instruction in the intermediate program is converted into program code, and an object program is obtained. the

After generating the object program, the programmer activates the linker. The linker allocates memory space for the object program and associated library programs and links them together to generate a load module. The generated load module is based on the assumption that it is read by a computer and causes the computer to execute the procedures and functional parts shown in the flowcharts. The program of the present invention can be generated in this way. the

USE OF THE PROCEDURE OF THE INVENTION

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

(i) Used as an embedded program

When the program of the present invention is used as an embedded program, a load module as a program and a basic input/output system (BIOS) program and various middleware (operating systems) are written in the instruction ROM. The program of the present invention is used as a control program of the reproducing apparatus 300 when the instruction ROM is embedded in the control unit and executed by the CPU. the

(ii) as an application

When the reproducing apparatus 300 is a hard disk embedded type, a basic input/output system (BIOS) program is embedded in an instruction ROM, and various middleware (operating systems) are preinstalled in the hard disk. Furthermore, a boot ROM for activating the system from a hard disk is provided in the reproducing apparatus 300 . the

In this case, only the load module is supplied to the reproducing apparatus 300 via a transportable recording medium and/or a network, and installed in a hard disk as an application program. This enables the reproducing apparatus 300 to perform booting by the boot ROM to activate the operating system, and then cause the CPU to run the installed load module as one application, thereby enabling the use of the program of the present invention. the

As described above, when the reproducing apparatus 300 is embedded in a hard disk, the program of the present invention can be used as an application program. Therefore, the program of the present invention can be individually transmitted, rented, or provided via a network. the

<Controller 22>

The components such as the controller 22 described in the above embodiments can be realized as one system LSI. the

A system LSI is obtained by realizing bear chips on a high-density substrate and packaging them. A system LSI is also obtained by realizing a plurality of carrier chips on a high-density substrate and packaging them so that the plurality of carrier chips have the appearance of one LSI (such a system LSI is called a multi-chip module). the

The system LSI has a QFP (Quad Flat Package) type and a PGA (Pin Grid Array) type. In the QFP type system LSI, the pins are connected to the four sides of the package. In the PGA type system LSI, many pins are connected to the whole bottom. the

These pins are used to interface with other circuits. A system LSI connected to other circuits through, for example, pins of an interface serves as the core of the reproduction apparatus 300 . the

The carrier chip packaged in the system LSI includes a front-end unit, a back-end unit and a digital processing unit. The front-end unit digitizes the analog signal. The back-end unit converts digital data obtained through digital processing into an analog format and outputs the analog data. the

The internal structural components shown in the above embodiments are realized in a digital processing unit. the

As explained in "Using as an embedded program" above, a load module as a program, a basic input/output system (BIOS) program, and various middleware (operating systems) are written in the instruction ROM. The main improvement of the embodiment is achieved by the load module as a program. The system LSI of the present invention can thus be produced by packaging an instruction ROM in which a load module as a program is stored as a carrier chip. the

Regarding the specific implementation method, it is best to use SoC implementation or SiP implementation. SoC (System on Chip) implementation is a technique for printing multiple circuits on a chip. SiP (System in Package) implementation is a technology for packaging multiple circuits with resin or the like. Through these processes, the system LSI of the present invention can be produced in accordance with the internal structure of the reproducing apparatus 300 described in each of the above embodiments. the

It should be noted here that although the term LSI is used here, it may also be called IC, LSI, VLSI, super LSI, etc., depending on the level of integration. the

Furthermore, part or all of the components of each reproduction device may be realized as one chip. An integrated circuit is not limited to SoC implementation or SiP implementation, but may also be implemented by a dedicated circuit or a general-purpose processor. Furthermore, integrated circuits can be realized by using FPGAs (Field Programmable Gate Arrays) that can be reprogrammed after manufacture, or reconfigurable processors that can reconfigure connections and settings of circuit cells within LSIs. Also, as semiconductor technology improves or shifts to other technologies, a technology for integrated circuits that replaces LSI may appear in the near future. In this case, new technologies can be incorporated in the integration of the functional blocks constituting the present invention described above. Such possible technologies include biotechnology. the

Industrial applicability

The recording medium and reproducing apparatus of the present invention can be mass-produced according to their internal structures shown in the above embodiments. Therefore, the recording medium and reproducing apparatus of the present invention have industrial applicability. the

Claims (3)

1. a playing device is used for reading the audio stream of encoding state and the audio stream that broadcast is read from recording medium, and described playing device comprises:

Judging unit is used for judging whether connect the other side's device has decoding capability;

Inquiry unit has decoding capability if be used for the described connection of described judgment unit judges the other side device, inquires then whether the user should use the demoder that is embedded in described connection the other side device to carry out decoding;

Status register;

Selected cell, be used for the decoding capability of described connection the other side device is arranged on described status register, if and be used in response to described inquiry, described user indication should use the demoder of described connection the other side device to carry out decoding, then selects the audio stream that will play according to the attribute that is arranged on described decoding capability in the described status register and audio stream; And

Transmission unit is used for reading selected audio stream from described recording medium, and is transferred to described connection the other side device by described audio stream being remained on encoding state with the audio stream that will be read.

2. playing device according to claim 1, wherein

Select a plurality of audio streams of described selected cell on being recorded in described recording medium to be play by described connection the other side device, have the linguistic property identical and audio stream that have the multichannel attribute with described playing device itself, wherein,

Audio stream by the encoding state of described transmission unit transmission is the audio stream of being selected by described selected cell.

3. a player method is used for reading the audio stream of encoding state and the audio stream that broadcast is read from recording medium, and described player method comprises the following steps:

Judge whether connect the other side's device has decoding capability;

If described determining step judges that described connection the other side device has decoding capability, inquire then whether the user should use the demoder that is embedded in described connection the other side device to carry out decoding;

The decoding capability of described connection the other side device is arranged in the status register, if and in response to described inquiry, described user indication should use the demoder of described connection the other side device to carry out decoding, then selects the audio stream that will play according to the attribute of described decoding capability in the status register that is arranged on computing machine and audio stream; And

Read selected audio stream from described recording medium, and be transferred to described connection the other side device with the audio stream that will be read by described audio stream being remained on encoding state.

Images