RU2298845C2 - Data storage carrier, having information for controlling buffered state of markup document, and also method and device for reproducing data from data storage carrier - Google Patents

Abstract

FIELD: data carriers.

SUBSTANCE: device, which reproduces audio/video data, using markup document in interactive mode, includes buffer, which buffers markup document, and buffer administrator, which controls preliminary load of markup document and provides information about condition of buffer buffering in response to report signal. Markup document may be provided via network or from carrier for data storage, which includes information for controlling buffering condition of markup document.

EFFECT: increased efficiency.

20 cl, 17 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a storage medium having information that is used to control the buffering state of a markup document, as well as a method and apparatus for reproducing data from a storage medium.

State of the art

Currently, interactive DVDs having markup documents for playing their content interactively are widely used on the market. Typically, content recorded on an interactive DVD is played in two different modes. One of these two modes is the video presentation mode, in which the content is displayed in the same way as the content of data recorded on a regular DVD. Another mode is an interactive mode in which content is displayed through a display window defined by interactive DVD layout documents.

If the user selects the interactive mode, then the Web browser installed in the DVD player displays the markup documents recorded on the interactive DVD. Content selected by the user is displayed through a display window defined by markup documents. For example, if the content is the name of a movie, then the movie is displayed on the display window, and various components of additional information, such as a script, a summary and photographs of actors and actresses, can be displayed on the rest of the screen. Such additional information includes image files or text files.

1 shows an interactive DVD on which audio and video data is recorded. Audio and video and many markup documents are recorded on the tracks of an interactive DVD as a bit stream in the MPEG standard. Here, markup documents may include markup resources, including various image files or image files inserted into markup documents.

Figure 2 shows the discontinuous playback of data from the interactive DVD of figure 1. That is, FIG. 2 shows the load on the buffer memory that is used to buffer audio-video data and the load on the cache that is used to cache Web resources.

Turning to FIG. 1 and 2, with reference to which a method for loading audio-video data into memory and displaying audio-video data is described. The information picker searches for the STARTUP.HTM markup document and loads the found STARTUP.HTM markup document into the cache. Then STARTUP.HTM is activated. At the same time, the audio-video data 1 selected by the user is loaded into the buffer memory and then displayed. After that, audio-video data 2 is loaded into the buffer memory, after which it is displayed. After buffering of the audio-video data 2 is completed, the information pickup device goes to the place on the interactive DVD where the audio-video data 3 is recorded and starts buffering the audio-video data 3. At this point, the user can request A.HTM markup document 4. In this case, the information pickup device stops buffering the audio-video data 3, searches for the A.HTM markup document 4 and loads the A.HTM markup document 4 into the cache. When searching for A.HTM markup document 4 and loading it into the cache, the display of audio-video data 3 is not allowed. Thus, the amount of data that can be buffered in the buffer memory is significantly reduced, since the audio-video 3 still occupies the space in the buffer memory. When the markup document 4 on A.HTM is activated and the audio-video data buffering 3 is completed, the audio-video data is buffered 5. Then, the information pickup device goes to the place where the audio-video data is recorded 6. In the above method, all the data that has been buffered so far may disappear. In other words, when requesting playback of DVD video images from a standard interactive DVD in synchronization with markup documents, for example, when a creative biography of a specific actor or actress is requested to be displayed, whenever he or she appears on the screen, the information pickup device stops the buffering of the audio and video data and starts searching and caching the corresponding markup documents, as a result of which the images can be played intermittently.

SUMMARY OF THE INVENTION

Accordingly, according to one aspect of the present invention, there is provided a storage medium comprising control information for controlling the buffering state of markup documents used to play audio and video data interactively, as well as a device and method for playing audio and video data from a storage medium.

Additional aspects and / or advantages of the present invention are partially described below, the essence of which can be partially understood from this description or as a result of the practical implementation of the invention.

To provide the above and / or other aspects of the present invention, there is provided a device for reproducing audio and video data using a markup document in an interactive mode, the device comprising a buffer that buffers the markup document, and a buffer manager that controls the preliminary loading of the markup document into the buffer and outputs status information buffering a buffer in response to a report signal.

The device may further comprise a content decoder that interprets the markup document and outputs a report signal, where the buffer manager informs the content decoder, reporting buffer buffer status information in response to the report signal. A content decoder can generate a report signal using an application programming interface (API).

The API can be used to notify the content decoder whether the markup document has been preloaded successfully or not, or whether the markup document is currently being downloaded. The API can return a value of 0 if the preload of the markup document is successful, return a value of 1 when the preload of the markup document has failed, and return a value of 2 if the markup document is still loading. The buffer manager, using the API, can inform the content decoder about the buffering state of the markup document.

The content decoder, using the API, can create a report signal that includes at least one of the parameter: the file path and the markup document attribute. The API can be an API in the form [obj] .isCached (URL, resType), where URL is a parameter indicating the file path for the markup document, and resType is a parameter indicating the attribute of the markup document.

The buffer manager may preload the markup document into the buffer in response to a fetch signal. The content decoder can output a sample signal, and the buffer manager can inform the content decoder whether the command to preload the markup document included in the sample signal has been successfully received. A content decoder using the API can create a fetch signal.

The content decoder, using the API, can check if the preloading of the markup document is completed. An API can be an API in the form of [obj] .allDone. An API in the form of [obj] .allDone can return true to the content decoder if the preload of the markup document is completed, and return the content decoder to false if the preload of the markup document is not completed.

The buffer manager can send the markup document from the buffer to the content decoder in response to the playback signal.

The content decoder may output a release signal to the buffer manager, indicating that the markup document therein received from the buffer in response to the playback signal is not used.

The buffer manager may delete the markup document from the buffer in response to a discard signal issued by the content decoder. A content decoder can create a drop signal using the drop API.

A content decoder can generate a report signal using the API as progressNameOfFile to determine the file name of the markup document currently being loaded. A content decoder can generate a report signal using the API in the form of progressLengthOfFile to determine how loaded the markup document is currently pre-loading. A content decoder can generate a report signal using the remainLengthOfFile API to determine how much of the markup document currently being loaded is left to load before it is fully loaded. A content decoder can generate a report signal using an API of type totalLoadingSize to determine the total load of the markup document to be preloaded. A content decoder can generate a report signal using an API of the remainLoadingSize type to determine how much of the total load of the markup document should still be loaded.

To provide the above and / or another aspect of the present invention, there is provided yet another buffer control device that buffers a markup document for playing audio and video data interactively, the device comprising a buffer manager that controls the preloading of the markup document into a buffer and outputs buffer information, including buffering information of the markup document, where the buffering information includes information indicating that preloading the markup document narrow was successfully completed, information indicating that the preloading of the markup document failed, and information indicating that the preloading of the markup document is still in progress.

The buffer information may further include information indicating whether a command to preload the markup document has been successfully received. The buffer information may further include information indicating whether pre-loading of the markup document is completed.

In order to provide the above and / or other aspect of the present invention, there is provided the following apparatus for recording and / or reproducing audio-video data using a markup document in an interactive mode, the device comprising: an audio-video buffer that buffers the audio-video data; an audio video reproducing mechanism that decodes the audio video data; and Enhanced Audio-Video Buffer (ENAV), which preloads the markup document to play the audio-video data interactively; an ENAV mechanism that identifies information about the buffering state of the markup document and decodes the markup document, as well as means for obtaining the markup document.

In this device, you can use the block I / O method in response to receiving a markup document from the storage medium and the unpacked I / O method in response to receiving a markup document from the network.

To provide the above and / or other aspect of the present invention, there is provided a method of reproducing audio and video data interactively using a markup document, the method comprising buffering the markup document to preload the markup document and outputting information about the buffering state of the markup document in response to the report signal. The method may further comprise reproducing audio and video data interactively using a pre-loaded markup document.

The output of buffering status information may include returning a value of 0 in response to a successful preload of a layout document, returning a value of 1 in response to a failed preload of a layout document, and returning a value of 2 if the preliminary loading of the layout document is still ongoing.

To provide the above and / or other aspect of the present invention, another method for reproducing audio and video data interactively using a markup document is provided, the method comprising issuing a command to preload the markup document using a sampling signal and receiving a response indicating whether the command was successfully transmitted to preload a markup document using a sample signal. The method may further comprise reproducing audio and video data interactively using a pre-loaded markup document.

In order to provide the above and / or other aspect of the present invention, there is provided yet another method of reproducing audio and video data interactively using a markup document, the method comprising requesting whether the preliminary loading of the markup document using the application programming interface (API) is completed and receiving the return value True if the preload of the markup document is completed, and the return value is false if the preload The markup document is not complete. The method may further comprise reproducing audio and video data interactively using a pre-loaded markup document.

To provide the above and / or other aspect of the present invention, there is provided a method for managing a markup document for use in reproducing audio and video data in an interactive mode, the method comprising buffering a markup document for preloading a markup document in response to a sample signal, outputting a buffering state of the markup document in response to the signal report, presenting the markup document for decoding in response to the extraction signal and deleting the markup document in response to the signal tbrasyvaniya.

The method may further comprise marking the markup document as a document not to be further used in response to a release signal. The method may also further comprise providing a response indicating whether the command to preload the markup document included in the sample signal has been successfully transmitted.

The output of the buffering state may include the return of a signal indicating whether the preloading of the markup document is completed. The output of the buffering state may include the return of a signal indicating whether the markup document was preloaded successfully or not, or that the markup document is still preloaded.

To provide the above and / or other aspect of the present invention, there is provided another method for managing a markup document for use in reproducing audio and video data in an interactive mode, the method comprising creating a sampling signal for preloading the markup document, creating a report signal for determining the buffering state of the markup document, creating an extraction signal to represent the markup document for decoding and create a discard signal to delete the document once tags.

The method may further comprise generating a release signal in response to the fact that the markup document is no longer present. Creating a report signal may include generating a report signal using an application programming interface (API) to determine one or more of the conditions: whether the preloading of the markup document is successful, whether the preloading of the markup document is still ongoing, and whether the preloading of the markup document is already completed.

In order to provide the above and / or other aspect of the present invention, there is provided a computer-readable medium with encoded work instructions for implementing one or more of the methods described above by a computer.

To provide the above and / or other aspect of the present invention, there is provided a method in a computer system for processing audio and video data interactively using a markup document, the method comprising controlling a content decoder to generate a report signal to determine information about the buffering state of the markup document, and in response to report signal - control by the buffer manager to issue a response indicating whether the markup document was preloaded successfully or not, or or whether pre-loading of the markup document is still ongoing.

To provide the above and / or other aspect of the present invention, another method is provided in a computer system for processing audio-video data interactively using a markup document, the method comprising controlling a content decoder to create a sample signal for preloading the markup document and, in response to the sample signal - managing the buffer manager to issue a response indicating that the command to preload the markup document has been successfully accepted.

To provide the above and / or other aspect of the present invention, there is provided the following method in a computer system for processing audio and video data interactively using a markup document, the method comprising controlling a content decoder to generate a request to determine whether preloading of the markup document has been completed, and, the response to the specified request is the management of the buffer administrator to issue a response indicating whether the preliminary loading of the markup document is completed.

In order to provide the above and / or other aspect of the present invention, there is provided a computer-readable medium comprising audio-video data, a markup document that is provided for reproducing the audio-video data interactively, and control information that is provided for identifying the buffer status information of the markup document to be preloaded.

The control information may include an application programming interface (API) that generates a report signal used to identify the buffering state of the markup document. The API can be an API in the form of [obj] .isCached (URL, resType), which generates a report signal, where URL is a parameter indicating the path of the markup document file, and resType is a parameter indicating the markup document attribute.

The control information may include an API that returns a value of 0 in response to a successful preload of a markup document, a value of 1 in response to an unsuccessful preload of a markup document, and a value of 2 in response to a situation where the preload of the markup document is still ongoing.

The control information may include an API that generates a sampling signal used to issue a command to preload the markup document. The API, using a fetch signal, may return a response indicating that the command to preload the markup document was transmitted successfully.

The control information may include an API that is used to determine whether preloading of the markup document is completed.

In order to provide the above and / or other aspect of the present invention, there is provided a programmed media for storing data to enable an interactive method for reproducing audio and video data using markup documents executed by a computer, wherein the storage medium contains first program code for performing buffering markup documents for preloading markup documents and a second program code for outputting information and indicating whether buffering of markup documents is complete.

To provide the above and / or other aspect of the present invention, there is provided another medium for storing data encoded with program codes to enable the method for reproducing audio and video data interactively using markup documents executed by a computer, the medium for storing data containing the first program code that issues a command for preloading markup documents using a sampling signal and a second program code that first informs whether successfully command the prefetch markup documents using the sample signal.

In order to provide the above and / or other aspect of the present invention, there is provided another medium for storing data encoded with program codes to enable the method for reproducing audio and video data interactively using markup documents executed by a computer, the medium for storing data containing the first program code, which is used by the content decoder to check if the buffer manager has completed preloading documents and using an application programming interface (API), and a second program code that returns a true value to the content decoder in response to preloading the markup documents successfully completed by the buffer administrator by using the API, and otherwise returns the value “ Lying".

Brief Description of the Drawings

These and / or other aspects and advantages of the invention can be understood and easily appreciated from the following description of aspects of the present invention together with the accompanying drawings, in which:

фиг.1 - схема, иллюстрирующая интерактивный DVD, на котором записаны аудиовидеоданные;

figure 1 is a diagram illustrating an interactive DVD on which recorded audio and video data;

FIG. 2 is a diagram illustrating interrupted data playback from the interactive DVD shown in FIG. 1;

figure 3 is a block diagram of a device for reproducing data from a storage medium that performs a preload or delete operation in accordance with markup documents;

4 is a diagram illustrating a directory structure of a DVD 300 that supports preloading or deletion in accordance with markup documents;

5 is a diagram illustrating the space of a DVD 300 volume that supports preloading or deletion in accordance with markup documents;

6 is a flowchart illustrating a method for preloading or deleting markup documents;

FIG. 7 is a flowchart illustrating a method for interpreting preload information, that is, operation 602 of FIG. 6;

Fig. 8 is a flowchart illustrating a method for preloading targeted files, i.e., operation 603 of Fig. 6;

FIG. 9A is a flowchart illustrating another method for preloading targeted files, i.e., operation 603 of FIG. 6;

FIG. 9B is a flowchart illustrating another method for preloading targeted files, i.e., operation 603 of FIG. 6;

10 is a flowchart illustrating a method for deleting at least one intended file previously loaded and stored in memory;

11 is a flowchart illustrating a method of deleting a file from the cache, that is, operation 1002 of FIG. 10;

12 is a diagram illustrating the results of the preload method described with reference to FIG. 3-11, where the audio-video data and HTML documents are recorded on an interactive DVD in the same manner as in FIG. 1;

FIG. 13 and 14 are block diagrams of an apparatus for reproducing data from a storage medium according to an embodiment of the present invention;

FIG. 15 is a diagram illustrating a method for controlling the buffering state of a markup document in a cache using a cache manager according to an embodiment of the present invention; FIG.

16 is a flowchart illustrating a method for controlling the buffering state of a markup document using a content decoder and a cache manager according to an embodiment of the present invention;

17 is a diagram illustrating an interactive DVD on which audio-video data and markup documents according to an embodiment of the present invention are recorded;

Fig. 18 is a diagram illustrating the directory structure of the interactive DVD shown in Fig. 17;

Fig.19 is a diagram illustrating the structure of the volume and file structure of the interactive DVD shown in Fig.17; and

FIG. 20 is a diagram illustrating a method for reproducing markup documents and audio and video data from an interactive DVD shown in FIG. 17, according to an embodiment of the present invention.

Best Mode for Carrying Out the Invention

Turning now to a more detailed description of embodiments of the present invention, examples of which are shown in the accompanying drawings, where like reference numbers refer to like elements throughout the drawings. The options described below help to explain the present invention through reference to the drawings.

Devices and methods for preloading data and deleting preloaded data are disclosed by the present applicant in Korean Patent Application No. 2002-57393, filed September 19, 2002. Although its contents are incorporated herein by reference, to further illustrate the present invention, the nature of this application is further described.

Figure 3 shows a device for reproducing data from a storage medium that performs a preload or delete operation in relation to markup documents. The device supports an interactive mode in which the stream of audio and video data is reproduced from a storage medium, such as a DVD 300, by decoding the audio and video data recorded on the DVD 300 and then displaying the decoded data in a display window specified by the markup documents. The device includes a reader 1, a first memory 2, a second memory 3, an audio-video decoder 4, and a presentation mechanism 5. During interactive mode, the audio-video screen is displayed embedded in the layout screen. Layout documents are displayed on the markup screen, and the audio-video screen is obtained by playing back the audio-video data.

Presentation engine 5 supports extensions for JavaScript or JavaApplet communication tags in order to interpret and execute preloaded information recorded using communication tags, a JavaScript application programming interface (API) or JavaApplet (API), and deletion information recorded using a JavaScript API or JavaApplet API.

The reader 1 reads the markup documents or audio and video data from the DVD 300. The first memory 2 is, for example, a buffer memory that buffers the audio and video data read by the reader 1. The second memory 3 is, for example, a cache that caches the received pre-loaded file. The audio-video decoder 4 decodes the audio-video data stored in the first memory 2, and outputs a stream of audio-video data. The presentation engine 5 interprets the preload information contained in the markup documents read by the reader 1 and issues a request to the reader 1 or an Internet server (not shown) for files to be preloaded into the second memory 3 based on the interpreted preload information loading. To synchronize the display of files and audio-video data, pre-downloaded files are read from the second memory 3 and displayed together with the stream of audio-video data coming out of the audio-video decoder 4. Files are deleted from the second memory 3 as a result of interpretation of the deletion information.

DVD 300 contains audio or audio / video data, as well as markup documents containing preload information and / or deletion information. In addition, a preload list file and / or a deletion list file may be recorded on the DVD 300.

A preload list file includes a list of files to be preloaded and the size of each file to be preloaded. Files to be preloaded represent markup documents that are reproduced synchronously with the corresponding audio-video data. Files to be preloaded can be recorded on the DVD 300. However, files to be preloaded can also be stored on an Internet server accessible via the Internet.

The preload information contains a command to read the files to be preloaded, for example, from the DVD 300, and then store these files in the cache 3. Preload information can be set using the link tag, which includes the path and file attributes with a preload list and inserted in the title tag. On the other hand, preload information can be set using the JavaScript application programming interface (API) or JavaApplet (API), which has the function path and / or attribute of the file with the preload list and allows playback of the file with the preload list as functional parameters. Preloading information can also be set using the JavaScript API or JavaApplet API, which has the function path and / or attribute of each file to be preloaded and allows files to be played back, in which case there is no need to have a file with a preload list.

The file with the list of deletions includes a list of files to be deleted, together with information about the location of each file to be deleted, that is, the file name and path of each file to be deleted. The deletion information is a command to delete files from the second memory 3. Deletion information can be set using the JavaScript API or JavaApplet API, which has the location information of the file with the deletion list as a function parameter and allows deletion of the files listed in the deletion list file. On the other hand, deletion information can be set using the JavaScript API or JavaApplet API, which has the location information of each file to be deleted as a function parameter and allows the deletion of files, in which case there is no need to have a file with a list of deletions.

4 shows a directory structure of a DVD 300. Referring to FIG. 4, a root directory includes a VIDEO_TS video directory of a DVD having audio and video data and an interactive DVD_ENAV directory of a DVD having data to support an interactive function.

In the video directory VIDEO_TS of a DVD disc, the title information VIDEO_TS.IFO is recorded regarding all video titles recorded on the DVD 300, navigation information VTS_01_0.IFO for the first video title and audio and video data VTS_01_0.VOB, VTS_01_1.VOB, ... forming the first video title. A detailed description of the DVD VIDEO_TS video directory structure is disclosed in the DVD-Video standard (DVD-Video for read-only memory disc 1.0).

DVD_ENAV.IFO navigation information regarding all interactive information in general and the STARTUP.HTM startup document are recorded in the DVD_ENAV interactive directory of a DVD disc. In addition, the STARTUP.PLD file with the preload list, the A.HTM file to be preloaded, and the A.PNG image file inserted into A.HTM are also provided in the interactive directory DVD_ENAV of the DVD. Other files to be preloaded or graphic files inserted into them can also be recorded in the DVD_ENAV interactive directory of a DVD disc.

FIG. 5 shows the space of a DVD 300 volume. Referring to FIG. 5, the volume space contains a control information area that includes control information for a DVD 300 volume space and files recorded on a DVD 300, a DVD video data area where data is recorded video captions, and an interactive data area DVD, which is provided for reproducing audio and video data during an interactive mode.

The files stored in the video directory VIDEO_TS of the DVD disc of FIG. 4, that is, VIDEO_TS.IFO, VTS_01_0.IFO, VTS_01_0.VOB, VTS_01_1.VOB, ... are recorded in the DVD video data area. Files stored in the DVD_ENAV interactive directory of the DVD, i.e. STARTUP.HTM, STARTUP.PDL, A.HTM and A.PNG, are recorded in the interactive data area of the DVD.

6 shows a method for reproducing data from a storage medium. At operation 601, the reader 1 reads an HTML document from the DVD 300, which is a markup document recorded on the DVD 300 when the interactive mode is selected. In operation 602, the presentation engine 5 interprets the preload information included in the HTML document and requests that the reader 1 or the Internet server preload the files. In response to this request, in operation 603, files to be preloaded are stored in the second memory 3.

The reader 1 reads the audio and video data corresponding to the HTML document read in operation 601 from the DVD 300 and stores the read audio and video data in the first memory 2, which is a buffer memory, in operation 604. The audio-video decoder 4 decodes the audio-video data stored in the first memory 2 into the audio-video stream in operation 605. In operation 606, the presentation engine 5 reads from the second memory 3 pre-loaded files and displays the decoded stream of audio and video data in a display window that is specified by an HTML document is read m reader 1 in operation 601.

FIG. 7 shows a method for interpreting preload information, which method corresponds to operation 602 of FIG. 6. In operation 701, the presentation engine 5 determines the path of the preload list file included in the HTML document, and in operation 702 reads the preload list file following the found path. In operation 703, the submission engine 5 determines the files to be preloaded that are listed in the preload list file. Here, identifying files to be preloaded means identifying paths and attributes of files to be preloaded.

On Fig shows a method of preloading files, and this method corresponds to operation 603 of Fig.6. In operation 801, the presentation engine 5 identifies the path recorded in the link tag of the file with the preload list and retrieves the file with the preload list. In operation 802, the presentation engine 5 interprets a preload list file that includes a preload tag with paths and file attributes to be preloaded as parameters, and preloads the specified files.

On figa shows another way to preload files, and this method corresponds to operation 603 of Fig.6. In operation 901a, the presentation engine 5 interprets the API inserted into the body tag using parameters specifying the paths of the files to be preloaded and reads the files to be preloaded using the specified API. In operation 901b, the presentation engine 5 preloads by interpreting the file with the preload list, which includes the paths and attributes of the files to be preloaded. Since the presentation engine 5 can determine the attributes of the files to be pre-processed, it can process the files to be pre-processed based on their attributes and store the processed files in memory.

On Figv shows another way to preload files, and this method corresponds to operation 603 of Fig.6. In operation 901b, the presentation engine 5 preloads the files to be preloaded into memory using an API inserted in the body tag and having paths and attributes of the files to be preloaded as parameters. Since the attribute of the file to be preloaded is identified, the submission mechanism 5 can process the file to be preloaded, taking into account its attribute, and then remember the file to be preloaded in memory.

Figure 10 shows a method of deleting one or more preloaded files that are stored in memory. In operation 1001, the submission engine 5 interprets the deletion information included in the HTML document, identifies the files to be deleted based on the deletion list file, and deletes the identified files from the second memory 3 in operation 1002. Although the pre-processing list file and the list file deletions are integrated into a single file, that is, STARTUP.PLD, it is obvious that the list of files to be preloaded and the list of files to be deleted can be implemented as two separate files, and not in the integrated view in a single file.

Figure 11 shows a method of deleting one or more files from the cache, and this method corresponds to operation 1002 of figure 10. The list of files to be deleted can be written to the file with the list of deletions. In operation 1101, files are deleted from the second memory 3 using an API having, as a parameter, a file path with a list of deletes. Here, deleting files can be a process of physically deleting files from the second memory 3, a process of including a flag in these files indicating that these files can be deleted from the second memory 3, or that these files can be overwritten by other data without physically deleting the files from the second memory 3.

On Fig shows the results of the preload process on an interactive DVD, where the audio and video HTML documents are recorded in the same manner as in figure 1. That is, FIG. 12 shows the load of the first memory 2, where the audio-video data encoded according to the MPEG standard is buffered, and the load of the second memory 3, where the Web resource is cached. Turning to FIG. 1 and 12, where the reader 1 searches and reads STARTUP.HTM, and the presentation engine 5 interprets the preloaded information included in STARTUP.HTM, so that A.HTM is preloaded (4) into memory 3. When STARTUP.HTM is loaded into the second memory 3, it is activated, the audio and video data are loaded (1) into the first memory 2, and then displayed. When the buffering of the audio-video data is completed (2), the reader 1 goes to the place where (3) the audio-video data is recorded and starts buffering (3) the audio-video data. At this point, if the user requests (4) A.HTM, then the presentation engine 5 reads (4) A.HTM from the second memory 3 and displays (4) A.HTM. In this case, the reader 1 does not need to stop buffering (3) the audio and video data, search (4) A.HTM on the DVD 300, and then load (4) the A.HTM document into the second memory 3. Therefore, the reader 1 can continue buffering (3) audio and video data. When the reader 1 completes the buffering (5) of the audio-video data and goes to the place where the (6) audio-video data is recorded, the amount of data buffered in the first memory 2 can be reduced. However, the amount of data that was buffered in the first memory 2 is sufficient so that the buffered data does not turn out to be understaffed. In other words, even when there is a need to display DVD video images played from an interactive DVD during an interactive mode in synchronization with HTML documents, the reader 1 should not stop buffering the audio and video data and then search and cache HTML documents. The reason for this is that HTML documents are already pre-loaded into the second memory 3. For example, synchronized display can be used when there is a need to display a creative biography of a particular actor or actress whenever he or she appears on the screen.

Again, the above device, a storage medium and processes for preloading data and deleting preloaded data are described by the present applicant in Korean Patent Application No. 02-57393, filed September 19, 2002. The following describes storage media, as well as a method and apparatus for reproducing data from storage media according to the present invention.

13 is a block diagram of an apparatus for reproducing data from a storage medium according to an embodiment of the present invention. The device of FIG. 13, by analogy with the device of FIG. 3, reproduces data from a storage medium. In addition, the device of FIG. 13 supports interactive mode, performs preprocessing, and includes an audio-video buffer 20, an audio-video playback mechanism 40, an advanced audio-video (ENAV) buffer 30, and an ENAV mechanism 50.

The audio-video buffer 20, which corresponds to the first memory 2 of FIG. 3, buffers the audio-video data read from a storage medium, for example, a disk 100 or a network, for example, the Internet. The audio-video playback engine 40 decodes the buffered audio-video data to produce an audio-video data stream. The ENAV buffer 30 is, for example, a cache corresponding to the second memory 3 of FIG. 3. Buffer 30 ENAV buffers markup documents read from disk 100 or from the network. The ENAV engine 50, which corresponds to the presentation engine 5 of FIG. 3, preloads and controls the buffering state of the markup documents stored in the ENAV buffer 30. In addition, the ENAV engine 50 interprets or decodes the markup documents stored in the ENAV buffer 30. The ENAV mechanism 50 allows reproducing an audio-video data stream exiting the audio-video playback engine 40 in an interactive mode.

FIG. 14 is a detailed block diagram of the ENAV mechanism 50 of FIG. 13 according to an embodiment of the present invention. The ENAV mechanism 50 includes a buffer manager 51 that controls the ENAV buffer 30 and the content decoder 52 that interprets the markup documents.

The content decoder 52 may comprise an interpretation mechanism that analyzes and interprets markup documents, and a browser that extracts markup documents from the interpretation mechanism and / or network. Here, markup documents correspond to markup sources of various types, from text markup data written in HTML, CSS, or JAVASCRIPT, to binary data such as image data, audio data, or a Java program referenced by markup documents. Markup documents are retrieved from disk 100 or network by the buffer manager 51 in the ENAV engine 50.

As for preloading or deleting markup documents, the buffer manager 51 controls the buffering state of the markup documents in a predetermined manner according to the present invention. According to an embodiment of the present invention, the buffer manager 51 responds to a signal provided by the content decoder 52. For example, the buffer manager 51 may act differently in response to various signals provided by the content decoder 52. These signals may include, for example, a sample signal, a playback signal, a release signal, a drop signal, and a report signal.

15 shows a buffer manager 51 that controls the buffering state of markup documents processed by ENAV buffer 30 according to an embodiment of the present invention. For example, five different signals may be input into the buffer manager 51 from the content decoder 52, namely, a sample signal, a playback signal, a release signal, a drop signal, and a report signal.

The sampling signal is used to preload the markup documents into the ENAV buffer 30. If the markup documents are already pre-loaded into the ENAV buffer 30, then the I / O manager can prevent the corresponding markup documents from reading from the disk or from the network. The I / O manager represents a reader (not shown) that reads data from the disk, or a network data receiver / transmitter (not shown) that receives data from the network. The reader reads files from the disk, and the network data receiver / transmitter receives the given data from the network and / or transmits the given data to the network using, for example, the HTTP protocol.

Turning to FIG. 15, the I / O manager can be configured to operate in the following ways. If an HTTP request is issued, the I / O manager uses unpacked I / O. If a request is made for files on disk, the I / O manager uses block I / O. To reproduce markup documents from the network, the I / O manager selects the unpacked method in order to receive multiple markup documents at once. However, if at this time a lot of markup documents are read at once, then to move between places where markup documents are recorded, a data pickup device (not shown) in the reader will be required. Accordingly, the reading speed of the corresponding markup documents can be reduced several times. Thus, if it is necessary to read from a disk of a plurality of markup documents, a sequential block input / output method is selected in which a plurality of markup documents are sequentially read from a disk.

The playback signal is used to issue a request to send data from the ENAV buffer 30 to the content decoder 52. If the set data is read from the disk or downloaded from the network, then the content decoder 52 may be locked until the reading or loading of the set data is completed.

The release signal indicates that the set data sent from the ENAV buffer 30 to the content decoder 52 in accordance with the above playback signal is no longer required. For example, if a given markup document is accessed five times in response to a playback signal, then a release signal is generated five times. The counter value increases whenever a playback signal is generated, and decreases whenever a release signal is created. When the counter value corresponding to the specified markup document reaches 0, that is, when all reproduced markup documents are released, the released markup documents are deleted from the ENAV buffer 30 in accordance with the discarding signal, which is described below.

A drop signal indicates that the specified markup documents stored in the ENAV buffer 30 may be deleted from the ENAV buffer 30, for example, because they will no longer be used. Thus, in response to the discard signal, predetermined markup documents are discarded from the ENAV buffer 30.

According to an aspect of the present invention, if the markup documents are associated with another application and a playback signal has been generated, and the release signal has not been generated, then the markup documents will not be deleted from the ENAV buffer 30 even if a discard signal has been generated by the specified application.

The report signal is used, for example, to check whether markup documents read in response to the sample signal are successfully loaded into the ENAV buffer 30; whether some of the corresponding markup documents were read due to errors; and / or whether appropriate markup documents are not currently being read.

According to an embodiment of the present invention, the above and / or other signals of the present invention are provided using an API corresponding, for example, to a script recorded in a markup document. The following are examples, but not limitation, of the API options used to create many different signals used in the present invention.

<[obj] .preload (URL, resType>

Description:

This API is used to preload files or read files and store them in the 30 ENAV buffer. The parameters of this API include information about the location of the file with the preload list or information about the location of the files to be preloaded, as well as attributes of the files to be preloaded. This API generates a sampling signal and can be applied to all files that can be read from disk (disc: //) or from the network (http: //). It’s clear that the API can be used to preload the file.

Options:

URL =: preload list file path or paths of files to be preloaded

ResType =: attributes of files to be preloaded

Return Values:

If the preload command succeeds, the value 0 is returned. Otherwise, the value -1 is returned. For example, a value of -1 is returned if the preload command was not successfully completed.

Examples:

The request navigator.preload ("disc: //dvd_enav/a.htm", "text / xml") refers to a request to download files from "disc: //dvd_enav/a.htm". The files to be preloaded are text files written in XML.

The request navigator.preload ("disc: //dvd_enav/a.pld", "xml / preload") refers to the request to preload the files listed in the file with the preload list from "disc: //dvd_enav/a.pld" . The files listed in the preload list file are preload files written in XML.

<[obj] .discard (URL, resType>

Description:

This API is used to delete files from the 30 ENAV buffer. The parameters of this API include information about the location of the file with the list of deletions or information about the location of the files to be deleted, as well as the attributes of the files to be deleted. This API creates a drop signal. It is understood that the API can be used to delete a file.

Options:

URL =: file path with a list of deletions or file paths to be deleted

ResType =: attributes of files to be deleted

Return Values:

If the discard command is successful, the value 0 is returned. Otherwise, the value -1 is returned. For example, if the discard command was not successful, then -1 is returned.

Examples:

Inquiry

navigator.discard ("disc: //dvd_enav/a.htm", "text / xml") refers to a request to delete files from "disc: //dvd-enav/a.htm". These files are text files written in XML.

Inquiry

navigator.discard ("disc: //dvd-enav/a.pld", "xml / preload") refers to the request to delete files listed in the file with the list of deletions "disc: //dvd_enav/a.pld" from the cache -memory. These files are list files written in XML.

<[obj] .isCached (URL, resType)>

Description:

This API is used to check, for example, whether files have been successfully stored / loaded in the 30 ENAV buffer. The parameters of this API include information about the location of the list file or information about the location of the files to be searched / checked, as well as the attributes of the files to be checked. This API generates a report signal and can be applied to all files that are read from disk (disc: //) or from the network (http: //). It’s clear that the API can be used to check the status of a file.

Options:

URL =: path of the list file or path of files to be scanned

ResType =: attributes of files to be checked.

Return Values:

If the file listed in the list file or the file to be checked is successfully stored / loaded in the 30 ENAV buffer, then the value 0 is returned. If the file being checked was not loaded successfully, that is, the file was not preloaded, then the value 1 is returned. If the file is still being read / loaded, or during the preloading of the files there was no failure, and at least one of the files is still being read / loaded, the value 2 is returned.

Examples:

Inquiry

navigator.isCached ("disc: //dvd_enav/a.htm", "text / xml") refers to a query to check whether the file "disc: //dvd_enav/a.htm" is remembered. This file is a text file written in XML. Inquiry

navigator.isCached ("disc: //dvd_enav/a.pld", "xml / preload") refers to a request to check whether the files referenced by the list file "disc: //dvd_enav/a.pld" are remembered. These files are list files written in XML.

<[obj] .progressNameOfFile>

Description:

This API is used to return, for example, the universal resource identifier (URI) of the file that is currently being preloaded.

Return value: file path or URI

<[obj] .progressLengthOfFile>

Description:

This API indicates how much of the pre-loaded file is currently loaded.

Return value: value represented in bytes.

<[obj] .remainLengthOfFile>

Description:

This API indicates how much of the currently preloaded file should still be loaded.

Return value: value represented in bytes.

<[obj] .totalLoadingSize>

This API indicates, for example, the general download of files to be preloaded.

Return value: value represented in bytes.

<[obj] .remainLoadingSize>

Description:

This API indicates, for example, how much of the total download of files to be preloaded needs to be downloaded.

Return value: value represented in bytes.

<[obj] .allDone>

Description:

This API indicates, for example, whether the device for reproducing data from the storage medium has completed preloading.

Return Values:

If the specified device successfully completed the preload, this API returns TRUE. Otherwise, FALSE is returned. For example, if the preload is not completed, that is, if the preload has failed or is still ongoing, then the value FALSE is returned.

As described above, according to one aspect of the present invention, a playback signal and a release signal are generated whenever appropriate markup documents are used. For example, the content decoder 52 presents the image "disc: //dvd_enaval/a.png" using a display device (not shown) by interpreting <img src = "disc: //dvd_enaval/a.png"> and creating a playback signal, with in order to force the buffer manager 51 to reproduce the corresponding image from the ENAV buffer 30. Similarly, the content decoder 52 generates a release signal when the presentation of the corresponding image is completed.

FIG. 16 shows a method for managing a buffer state executed by a content decoder 52 and a buffer manager 51 according to an embodiment of the present invention. In operation 1601, the content decoder 52 creates a sample signal in response to a preload command. In operation 1602, the buffer manager 51 starts reading the designated markup documents in response to a sample signal. In operation 1603, the content decoder 52 determines, for example, whether all markup documents have been read, and / or generates a report signal to determine, for example, the buffering state of the markup documents. In operation 1604, when an error occurs, it is processed. In operation 1605, the buffer manager returns a signal indicating the buffering state of the markup documents in response to the report signal. In operation 1606, the content decoder 52 creates an extraction signal for using markup documents. In operation 1607, the buffer manager 51 sends the indicated markup documents to the content decoder 52 in response to the extraction signal. In operation 1608, the content decoder 52 presents designated markup documents. In operation 1609, if the designated markup documents are no longer used, the content decoder 52 generates a release signal. In operation 1610, the buffer manager 51 decreases the current counter value by 1 to show, for example, the use of the corresponding one / more of the designated markup documents. In operation 1611, the content decoder 52 creates a discard signal to delete designated markup documents. In operation 1612, the buffer manager 51 deletes the designated markup documents from the ENAV buffer 30 in response to a drop signal.

On Fig shows a medium for storing data, for example, a disk on which recorded audio and video data and markup documents, according to a variant of the present invention. The storage medium further comprises control information that is used to identify information about the buffering state of the markup document to be preloaded. For example, the STARTUP.HTM start document includes a STARTUP.PLD file with a preload list for continuous playback of files from A.HTM to D.HTM.

The control information may include an API that returns a value of 0 in response to a successful preload of a markup document, a value of 1 in response to an unsuccessful preload of a markup document, and a value of 2 if the markup document is still preloaded. The control information may further include an API that generates a sampling signal for issuing a command to preload the markup document. This API can send back a response indicating whether the command to preload the markup document has been successfully transmitted. The control information may further include an API that is used to determine if preloading of the markup document has completed. This API can return TRUE in response to the completion of preloading the markup document and FALSE if the preloading of the markup document is not completed.

On Fig shows the directory structure of the disk of Fig according to a variant of the present invention. Referring to FIG. 18, reference documents of the start document STARTUP.PLD are included in the DVD_ENAV directory.

On Fig shows the structure of the volume and file structure of the disk of Fig according to a variant of the present invention. Referring to FIG. 19, in the DVD interactive data area, reference documents STARTUP.PLD are contained.

FIG. 20 shows a predetermined order in which markup documents and audio-video data recorded on the disc of FIG. 17 are reproduced. For example, at the beginning of each script, using the isCached API, it checks to see if the link files of the preload list file corresponding to the script were read. If the reading of the referenced files was successful, then HTM documents are read and played. After that, markup documents that have already been played are discarded using the Discard API.

For example, to continuously play back data from STARTUP.HTM, A.HTM, and D.HTM documents, the STARTUP.PLD file is defined as follows.

Using the above STARTUP.PLD, STARTUP.HTM is displayed on the screen indicating the start of the interactive presentation. An example of STARTUP.HTM, which is processed by the device of FIG. 15, is as follows.

According to one aspect of the present invention, A.HTM and B.HTM markup documents may include images. According to one aspect of the present invention, as shown in FIG. 18 and 20, the markup documents necessary for presentation, for example, A.HTM, i.e. all markup documents in A.PLD and referred to as files to be preloaded, are deleted from the ENAV buffer 30 after presentation.

It is understood that a system in which the present invention is used also includes a permanent or removable storage device such as magnetic and optical disks, RAM, ROM, carrier signal carrier, etc., in which a processing method can be stored and distributed. and data structures of the present invention. Operations can also be distributed, for example, by downloading over a network such as the Internet.

Although several embodiments of the present invention have been shown and described herein, it should be apparent to those skilled in the art that they may be modified within the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.

Industrial applicability

According to the present invention, images can, for example, be represented using only pre-loaded files when the content is processed using a method that can determine the status of the pre-loaded content, even in cases where physical disk defects or disconnected connections result in unsuccessful or incomplete preloading files to the buffer. Accordingly, the reliability of reproduction of content increases. That is, according to an aspect of the present invention, the audio and video data can be suitably presented interactively even if the markup documents have not been preloaded in whole or an error has occurred during the preloading of the markup documents.

Claims (82)

1. A device for reproducing audio and video data using a markup document in an interactive mode, comprising: a buffer that buffers the markup document, and a buffer manager that controls the loading of the markup document with the buffer and displays information about the buffer buffering state in response to the report signal. 2. The device according to claim 1, further comprising a content decoder that interprets the markup document and outputs a report signal in which the buffer manager informs the content decoder by providing buffer buffering information in response to the report signal. 3. The device according to claim 2, in which the content decoder generates a report signal using an application programming interface (API). 4. The device according to claim 3, in which the API serves to notify the content decoder about whether the markup document was pre-loaded successfully or unsuccessfully, or whether the markup document is still downloading. 5. The device according to claim 4, in which the API returns 0 if the preloading of the markup document is successful, returns 1 if the preloading of the markup document is unsuccessful, and returns 2 if the markup document is still loading. 6. The device according to claim 2, in which the content decoder generates a report signal using an API that includes at least one parameter: the file path and the markup document attribute. 7. The device according to claim 2, in which the content decoder generates a report signal using the API in the form of [obj] .isCached (URL, resType), where URL is a parameter indicating the path of the markup document file, and resType is a parameter indicating the document attribute markup. 8. The device according to claim 2, in which the buffer manager informs the content decoder about the buffering state of the markup document using the API. 9. The device according to claim 1, in which the administrator of the buffer preloads the markup document into the buffer in response to the sample signal. 10. The device according to claim 9, further comprising a content decoder that interprets the markup document and outputs a sample signal, in which the buffer manager informs the content decoder whether the command to preload the markup document included in the sample signal was successfully received. 11. The device of claim 10, in which the content decoder creates a sample signal using the API. 12. The device according to claim 11, in which the buffer manager informs the content decoder about whether the said command was successfully received using the API. 13. The device according to claim 1, further comprising a content decoder that interprets the markup document, wherein the content decoder checks whether the preloading of the markup document is completed using the API. 14. The device according to item 13, in which the API is an API in the form of [obj] .allDone. 15. The device according to 14, in which the API in the form of [obj] .allDone returns the value "true" to the content decoder if the preliminary loading of the markup document is completed, and returns the value "false" to the content decoder if the preliminary loading of the marking document is not completed. 16. The device according to claim 1, further comprising a content decoder that interprets the markup document, in which the buffer manager sends the markup document from the buffer to the content decoder in response to the playback signal. 17. The device according to claim 1, additionally containing a content decoder that interprets the markup document, in which the content decoder outputs a release signal to the buffer manager, indicating that the markup document taken from the buffer in response to the playback signal is not used. 18. The device according to 17, in which the content decoder outputs a release signal to the buffer manager in accordance with the markup document, which is no longer displayed on the screen of the display device. 19. The device according to claim 1, further comprising a content decoder that interprets the markup document, in which the buffer manager deletes the markup document from the buffer in response to a discard signal output from the content decoder. 20. The device according to claim 19, in which the content decoder creates a drop signal using the drop API. 21. The device according to claim 2, in which the content decoder generates a report signal using the API in the form of progressNameOfFile to determine the file name of the markup document pre-loaded at the moment. 22. The device according to claim 2, in which the content decoder generates a report signal using the API in the form of progressLengthOfFile to determine which part of the currently pre-loaded markup document is already pre-loaded. 23. The device according to claim 2, in which the content decoder generates a report signal using the API in the form of remainLengthOfFile to determine which part of the currently pre-loaded markup document should be pre-loaded. 24. The device according to claim 2, in which the content decoder generates a report signal using the API in the form of totalLoadingSize to determine the total load of the markup document to be preloaded. 25. The device according to claim 2, in which the content decoder generates a report signal using the API in the form of remainLoadingSize to determine how much of the total load of the markup document should be preloaded. 26. A device for managing a buffer that buffers a markup document for playing audio and video data interactively, comprising a buffer manager that controls preloading of the markup document with a buffer and outputs buffer information including buffering information of the markup document, in which the buffering information includes in itself: information indicating that the preload of the markup document has been completed successfully; information indicating that the preliminary loading of the markup document failed; and information indicating that preloading the markup document is still in progress. 27. The device according to p, in which the administrator of the buffer displays the buffer information using the application programming interface. 28. The device according to p, in which the information of the buffer further includes information indicating whether the command to preload the markup document has been successfully received. 29. The device according to p, in which the information of the buffer further includes information indicating whether the preloading of the markup document is completed. 30. A device for recording and / or reproducing audio and video data using a markup document in an interactive mode, comprising: an audio-video buffer that buffers the audio-video data; an audio-video playback engine that decodes audio-video data; Enhanced Audio-Video (ENAV) buffer that preloads a markup document for interactive playback of audio and video data; ENAV mechanism that identifies information about the buffering state of the markup document and decodes the markup document; and means for obtaining a markup document. 31. The device according to item 30, in which the device uses a block input / output method in response to receiving a markup document from a storage medium and an unpacked input / output method in response to receiving a markup document from the network. 32. A method for reproducing audio and video data interactively using a markup document, the method comprising: buffering the markup document to preload the markup document and outputting information about the buffering state of a markup document in response to a report signal. 33. The method of claim 32, further comprising generating a report signal for determining buffering status information of the markup document. 34. The method of claim 33, wherein generating the report signal comprises generating a report signal using an application programming interface (API). 35. The method according to clause 34, in which the API includes as a parameter at least one of: a file path and an attribute of a markup document. 36. The method according to clause 34, in which the API is used to determine whether the markup document buffering has completed successfully or unsuccessfully for preloading the markup document, or whether the markup document is still buffered. 37. The method according to claim 33, wherein generating the report signal comprises generating a report signal using the API in the form [obj] .isCached (URL, resType), where URL is a parameter indicating the path of the markup document file, and resType is a parameter indicating markup document attribute. 38. The method of claim 32, wherein the output of the buffering status information includes returning a value of 0 in response to a successful preload of a markup document, returning a value of 1 in response to an unsuccessful preload of a markup document, and returning a value of 2 if the document The markup is still preloaded. 39. The method of claim 32, further comprising reproducing audio and video data interactively using a pre-loaded markup document. 40. A method of reproducing audio and video data interactively using a markup document, the method comprising: issuing a command to preload the markup document using a sampling signal and receiving a response indicating whether the command to preload the markup document using the sample signal has been successfully transmitted. 41. The method of claim 40, wherein issuing a command to preload the markup document includes creating a sample signal using an application programming interface (API). 42. The method of claim 40, wherein the receiving response comprises receiving a response indicating whether the command included in the sample signal has been successfully received using the API. 43. The method of claim 40, further comprising reproducing audio and video data interactively using a pre-loaded markup document. 44. A method for reproducing audio and video data interactively using a markup document, the method comprising: a request about whether the preloading of the markup document using the application programming interface (API) is completed; and receiving the return value “true” in response to the completion of preloading the markup document and the return value “false” in case the preloading of the markup document is not completed. 45. The method according to item 44, in which the API is an API in the form of [obj] .allDone. 46. The method according to item 44, further comprising reproducing audio and video data in an interactive mode using a pre-loaded markup document. 47. A method for managing a markup document for use in reproducing audio and video data in an interactive mode, the method comprising: buffering the markup document to preload the markup document in response to a sample signal; displaying the buffering state of the markup document in response to a report signal; presenting the markup document for decoding in response to the extraction signal and Deleting a markup document in response to a drop signal. 48. The method according to clause 47, further comprising marking the markup document as a document not further used in response to a release signal. 49. The method according to clause 47, further comprising issuing a response indicating whether the command to preload the markup document included in the sample signal has been successfully transmitted. 50. The method of claim 47, wherein the output of the buffering state comprises returning a signal indicating whether pre-loading of the markup document has been completed. 51. The method according to clause 47, in which the output of the buffering state includes the return of a signal indicating that the preloading of the markup document has completed successfully or unsuccessfully, or whether the markup document is still preloading. 52. A method for managing a markup document for use in reproducing audio and video data in an interactive mode, the method comprising: creating a sampling signal for preloading the markup document; creating a report signal to determine the buffering state of the markup document; creating an extraction signal to represent the markup document for decoding and creating a drop signal to delete the markup document. 53. The method according to paragraph 52, further comprising creating a release signal in response to the fact that the markup document is no longer present. 54. The method of claim 52, wherein generating the report signal comprises generating a report signal using an application programming interface (API) to determine one or more of the following: have the markup document preloaded successfully, is the markup document still preloaded and Whether the preload of the markup document has been completed. 55. Computer-readable media encoded by working instructions for implementing a method for reproducing audio and video data interactively using a markup document executed by a computer, the method comprising: buffering the markup document to preload the markup document and outputting information about the buffering state of a markup document in response to a report signal. 56. Computer-readable media encoded by work instructions for implementing a method for reproducing audio and video data interactively using a markup document executed by a computer, the method comprising: issuing a command to preload the markup document using a sampling signal and receiving a response indicating whether the command to preload the markup document using the sample signal has been successfully transmitted. 57. Computer-readable media encoded by working instructions for implementing a method for reproducing audio and video data interactively using a markup document executed by a computer, the method comprising requesting whether the preloading of the markup document using the application programming interface (API) is completed and receiving the return value “true” in response to the completion of the preliminary loading of the markup document and the return value “false” in the event that the pre The loading of the markup document is not completed. 58. Computer-readable media encoded by work instructions for implementing a method for reproducing audio and video data interactively using a markup document executed by a computer, the method comprising: buffering the markup document to preload the markup document in response to a sample signal; displaying the buffering state of the markup document in response to a report signal; presenting the markup document for decoding in response to the extraction signal and Deleting a markup document in response to a drop signal. 59. Computer-readable media encoded by work instructions for implementing a method for reproducing audio and video data interactively using a markup document executed by a computer, the method comprising: creating a sampling signal for preloading the markup document; creating a report signal to determine the buffering state of the markup document; creating an extraction signal to represent the markup document for decoding and creating a drop signal to delete the markup document. 60. A method in a computer system for processing audio and video data interactively using a markup document, the method comprising: managing a content decoder to generate a report signal for determining buffering status information of a markup document; and in response to the report signal, the buffer manager controls to issue a response indicating whether the markup document was preloaded or failed, or if the markup document is still preloaded. 61. A method in a computer system for processing audio and video data interactively using a markup document, the method comprising: managing a content decoder to create a sample signal for preloading the markup document; and in response to the sample signal, controlling the buffer manager to issue a response indicating whether the command to preload the markup document has been successfully received. 62. A method in a computer system for processing audio and video data interactively using a markup document, the method comprising: managing the content decoder to create a request for determining whether the preloading of the markup document is completed; and in response to the request, the management of the buffer manager to issue a response indicating whether the preloading of the markup document has been completed. 63. A storage medium containing audio and video data; a markup document that is provided for reproducing audio and video data in an interactive mode; and control information that is provided for identifying information about the buffering state of the markup document to be preloaded. 64. The storage medium according to claim 63, wherein the control information includes an application programming interface (API) that generates a report signal used to identify the buffering state of the markup document. 65. The storage medium according to claim 63, wherein the control information includes an API in the form of [obj] .isCached (URL, resType), which creates a report signal, where URL is a parameter indicating the path of the markup document file, and resType - A parameter indicating the attribute of the markup document. 66. The storage medium according to claim 63, wherein the control information includes an API that returns a value of 0 in response to a successful preload of a markup document, a value of 1 in response to an unsuccessful preload of a markup document, and a value of 2 if The markup document is still preloaded. 67. The storage medium according to claim 63, wherein the control information includes an API that generates a sampling signal used to issue a command to preload the markup document. 68. The storage medium according to item 67, in which the API returns a response indicating whether the command to preload the markup document using the sample signal was successfully transmitted. 69. The storage medium according to item 63, in which the control information includes an API that is used to determine whether preloading of the markup document. 70. A storage medium encoded with program codes to enable the implementation of a method for reproducing audio and video data in an interactive mode using markup documents performed by a computer, the storage medium comprising: first program code for buffering markup documents for preloading markup documents; a second program code for outputting information indicating whether the buffering of markup documents is completed. 71. The storage medium according to item 70, in which the first program code is executed in response to a sample signal used to issue a preload command. 72. The storage medium according to item 70, in which the second program code is executed in accordance with the application programming interface (API), requesting whether the buffering of markup documents is completed. 73. The storage medium according to item 70, in which the second program code is executed in accordance with the API in the form of [obj] .allDone, requesting whether the buffering of markup documents is completed. 74. A storage medium encoded with program codes to enable the implementation of a method for reproducing audio and video data interactively using markup documents performed by a computer, the storage medium comprising: a first program code that issues a command to preload markup documents using sample signal; a second program code that informs whether a command to preload markup documents has been successfully issued using a sample signal. 75. The storage medium according to item 74, in which the first program code creates a sample signal and outputs the sample signal to the buffer manager to preload the markup documents in response to receiving the sample signal. 76. The storage medium according to claim 74, wherein the second program code informs the content decoder whether the command to preload the markup documents using the application programming interface (API) was successfully issued to the buffer manager. 77. A storage medium encoded with program codes to enable the implementation of a method for reproducing audio and video data interactively using markup documents performed by a computer, the storage medium comprising: a first program code that is used to verify the content of the decoder whether buffer manager preloading markup documents by using an application programming interface (API); and a second program code that returns true to the content decoder in response to preloading the markup documents successfully completed by the buffer administrator by using the API, otherwise returns false to the content decoder. 78. The storage medium according to item 77, in which the API is an API in the form of [obj] .allDone. Priority on points: 10/17/2002 - claims 1-4, 6-13, 16-20, 26-29, 32-37, 39, 44, 46-65, 67-69. 04/29/2003 - pp. 14-15, 21-25, 45. 08/25/2003 - pp. 5, 30, 31, 38, 66, 70-78. 09/01/2003 - pp.40-43.

Images