Patent Application
20090125810
The invention relates to the field of transferring multimedia content to and from optical storage.
US 2004/0013416 shows an optical disk player that retrieves audio, video and application data from optical disk using an MPEG/MPEG2 format. In MPEG based systems, the head of the drive is busy reading MPEG data from the disc cannot be moved freely during operation. As a result, accessing application data in accordance with this patent document will generally require interruption of any audio/video presentation that a user is experiencing, or alternatively require very large data buffers.
It would be desirable to be able to retrieve audio and video data from an optical disk at the same time as application data, without the user experiencing any interruption of an audio/video presentation.
Preferably, a storage and retrieval format is used that interleaves all types of data into a transport stream, including audio, video and application data. Preferably the application data repeats. An example of a data format that can be used for the application data is a carousel.
The invention will now be described by way of non-limiting example with reference to the drawing in which:
The invention is most likely to be useful in optical disk environments, particularly in the blu-ray disk (BD) such as documented in Blu-ray Disc Founders, “The Blu-ray Disc Format,” August 2004. This document can be found at the official web site of the Blu-ray Disc Association—http://www.blu-raydisc.com/assets/downloadablefile/2b_bdrom_audiovisualapplication-12841.pdf.
In BD, transport streams can hold multiple elementary streams. The logical format is a file system, in other words like the DVD (Digital Video Disc) or the Universal Disk Format (UDF) version 2.5. Within that file system, there is room for much more data, so bigger files can be stored. Bandwith is also higher. The data rate can go as high as 25 Mega-bits/s. Transport streams containing high definition (“HD”) video can be read.
BD format standardization for video streams and interactivity includes Java programs that can do things while the user is watching a program. One possible application is to provide extra textual and photographic information on the actors of a movie or the participants of a sports event. This information can be shown on a part of the screen while the video is shown in a scaled way in the remainder of the screen (picture in picture). Another possible alternative is that the information can be shown semi-transparently on top of the video.
The Java program may require additional data while an HD video stream is being read and decoded from the disc. In the UDF format, typically application data and Java byte code are stored in different places from data for audio/video presentations. For data from the audio/video streams, allocation rules—i.e. rules regarding where to put the audio/video stream data on the disc—ensure uninterrupted playback of the audio and video. For Java program data, such rules do not apply. In other words, it cannot be predicted what data an interactive program needs next. Therefore, if the host platform needs application data or additional program code for an application program, it has to interrupt the audio/video presentation to get that data or code. Herein, the term “application data” will be used to mean application data and/or code.
The transport stream 111 goes to demultiplexer 105, which separates out the audio, video and subtitle data 114, which are output to the user at 107, 108, and 109, respectively. The application data is demultiplexed to a unit 104. Unit 104 processes the packets in the elementary stream that contains all the file system data. These packets are generated on recording by a packetizer 208, which will be discussed further below with reference to
The decoded files 103 are stored in application memory 102, where they are used for application execution and rendering at 106. Files can be delivered from the stream via streamed packets. Preferably the application data is stored and retrieved in a repeating format, such as the DSM-CC format, formerly used only in broadcasting. The use of MHP/DSM-CC file formats in broadcasting has been documented in Steven Morris, “Interactive TV Web” http://qq.mhp-interative.org/tutorial/mhp/filesystems.shtml (2002).
The DSM-CC format, used for broadcast content, allows application code and data, including a directory tree, to be stored in a format called a “carousel.” The term carousel is used, in analogy with an old-fashioned carnival ride, to indicate that the data is presented in a repeating fashion, as if the receiver were watching a rotating carousel. The advantage of this format is that all necessary data is presented fairly frequently, so that an application program can use it without pausing to wait for new data. It is desirable to store and retrieve application data with respect to an optical disc as part of a transport stream transport stream, where the application is organized within the transport stream in a repeating format, such as the carousel of the broadcast DSM-CC.
The carousel uses a small part of the bandwidth available to the complete transport stream. As an example, 20% of the available bandwidth of a high-definition MPEG2 audio & video stream can be used for the carousel with only a minimal effect on the video quality. This would be 5 Mbit/second for Blu-ray. With a repetition cycle of 32 seconds this would allow 32*5/8=20 Mbyte of data to be available to the application program including some overhead for the protocol used (such as DSM-CC). Using 20 Mbyte of data without a carousel would require the addition of 20 Mbyte of cache memory in each system.
Caching is known in the art prior art. Caching all the data a program might ever need is an alternative solution, but it restricts the maximum size of the data to the size of the cache. For a system to use DSM-CC, some caching of retrieved section of data is also needed. Typically this cache size is related with the size of the files in the carousel and the number of files that a system can retrieve concurrently from the stream. With the example numbers used above, if the data would consist of 100 files of size 100-1000 Kbyte, a buffer of 2 Mbyte would allow 2-10 files to be retrieved at the same time. The choice of the buffer size influences the performance in terms of latency of the carousel.
The exact information that is retrieved from the carousel is under user control via the application program, e.g. using remote control keys.
While
At 301, is an example of a file structure for some application data and code. The file structure includes files aaa and bbb in directory d1; files ccc and eee in directory d2; and directory d2 in directory d1. This is just an example of a file structure. More or less files might be used. More or less directories might be used. The directories might be nested differently. Those of ordinary skill in the art know how to design file structures as necessary for particular applications.
At 302, the data from the file structure 301 are shown cut into pieces. Directory d1 is shown cut into 2 pieces, both labeled, d1. File aaa is shown cut into four pieces, each labeled a. File bbb is shown cut into four pieces, each labeled b. Directory d2 is shown cut into 2 pieces, each labeled d2. File ccc is shown cut into 3 pieces, each labeled c. File eee is shown cut into four pieces, each labeled e. These numbers of pieces are also only examples. Files or directories might be cut into more or less pieces, in accordance with known DSM-CC technology.
Each piece from 302 is concatenated into a carousel cycle shown at 303. At 304, the carousel cycle is shown repeated three times, forming an elementary stream. Three times is also just an example. More or less repetitions might be desirable depending on the needs of the application.
The elementary stream is packetized to yield packets 305. Again, the number of packets shown is only an example. More or less packets might be used. Those of ordinary skill in the art know how to determine how many packets and what size packets are necessary, in order to make the application work.
At 306, the packets of application data and code (D) are interleaved with packets of video data (V), audio data (A), and subtitle data (S) to form a transport stream. This transport stream is then made into a transport file 307, which becomes a part 309 of a file structure 308. The file structure 308 is then stored in the optical disk file system 113.
An application program 406 resides in an optical disk player 405. The user 404 will typically interact with the application program 406 via a remote control or other similar mechanism, though other user input devices might also be used. The application program will also communicate with the area 403.
In order to support the application 406, the transport file stream 307 is retrieved from the optical disk file system 113. The file structure 301 is reconstructed from the transport stream 307 to support the application program 406.
Audio, video and/or subtitle data are also communicated at 408 to the television or other similar consumer electronics device.
An example of an application area for the invention is High Definition-Digital Video Disks (HD-DVD).
From reading the present disclosure, other modifications will be apparent to persons skilled in the art. Such modifications may involve other features which are already known in the design and use of optical recording techniques and which may be used instead of or in addition to features already described herein. Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present application also includes any novel feature or novel combination of features disclosed herein either explicitly or implicitly or any generalization thereof, whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims may be formulated to such features during the prosecution of the present application or any further application derived therefrom.
The word “comprising”, “comprise”, or “comprises” as used herein should not be viewed as excluding additional elements. The singular article “a” or “an” as used herein should not be viewed as excluding a plurality of elements. The word “or” should be construed as an inclusive or, in other words as “and/or”.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB06/50659 | 3/2/2006 | WO | 00 | 8/31/2007 |
| Number | Date | Country | |
|---|---|---|---|
| 60658252 | Mar 2005 | US |
