This invention relates to methods of storing media data delivered through network, particularly video data, and methods of playing the stored media data.
There are various methods to stream media data, particularly video data, through a network for playing on a client workstation, for example, WMV™, Real™ Video, and so on. If multiple formats are involved, it is difficult to store the media data, and streaming the stored data whenever required.
Recorders using DVD and/or hard disk as the storage medium have been available in the market, and is replacing traditional video recorders in the consumer market. In the meantime, the digital AV transmission have also been implemented in countries like US and Japan. Various applications like DVB-T broadcast, video on demand (VOD) and IPTV are now available using digital AV transmission technology. However, existing devices are not able to record digital AV content from IP network, DVB, or AV encoder, and then broadcast such the recorded signals.
Therefore, it is an object of this invention to provide a method of encoding digital AV content so that such can be recorded. It is yet an object of this invention to resolve at least one or more of the problems as set forth in the prior art. As a minimum, it is an object of this invention to provide the public with a useful choice.
Accordingly, this invention provides a method of storing media data delivered to a client, said media data being encoded in at least one format, said method including the steps of:
Preferably, the method of this invention further includes the step of:
The method of this invention may further include the step of:
Preferably, the media data could be video or audio data.
Optionally, the media data delivered to the client via internet.
It is another aspect of this invention to provide a system of storing media data delivered to a client, said media data being encoded in at least one format, said system including:
Preferably, the system this invention further includes a second analyzer for analyzing the media data to extract random access attributes from the media data, said random attributes
Preferred embodiments of the present invention will now be explained by way of example and with reference to the accompanying drawings in which:
This invention is now described by way of example with reference to the figures in the following paragraphs.
Objects, features, and aspects of the present invention are disclosed in or are obvious from the following description. It is to be understood by one of ordinary skilled in the art that the present discussion is a description of exemplary embodiments only, and is not intended as limiting the broader aspects of the present invention, which broader aspects are embodied in the exemplary constructions.
Even though some of them may be readily understandable to one skilled in the art, the following Table 1 shows the abbreviations or symbols used through the specification together with their meanings so that the abbreviations or symbols may be easily referred to.
A general scheme of the encoding method of this invention, which may be named as Universal Stream Recording Engine USRE (11) is shown in
The following are a few examples of how the S can be set up according to various scenarios:
When an audio or video data stream is received by the USRE (11), the Source Stream S and timing information would be captured by the USRE (11) if the Media Stream's Stream Type is ES. The USRE (11) would then store the Media Streams in memory in additional with Unit Attributes (and optional Rap Attribute). After that, a software application can access this memory and perform playback, streaming or time shift feature. The detail process will be discussed on the following session.
The operation of the USRE (11) may be triggered by an Input Selector (IS) under two conditions:
USRE could also be triggered by user intervention (for example, request for timeshift, trickplay and recording functions), or to provide certain feature (start/stop when a scheduled recording commences/expires), which are described in the later sections.
USRE can give a serial number SI to the S upon startup, and the S can be stored in a Source Info File. As would be appreciated by a person skilled in the art, a startup data stream could be assigned any serial number of desire, in which the number “1” would be preferred due to ease of programming. The logical structure of the Source Info file of an embodiment of this invention is shown in
According to
For a particular Stream Type ES, a corresponding Timestamp t would be obtained from the clock of the AV encoder, as would be understood by a person skilled in the art.
For Stream Type TS, the TS packets can be buffered until a complete Packetized Elementary Stream (PES) defined in ISO 13818-1 can be found. The attributes of this PES is then parsed according to ISO/IEC 13818-1:2000 2.4.3.7 and create an Unit Attribute, which can later be stored in the Unit Attribute file. After the parsing of the Unit Attribute, all of the TS packets buffered will be passed to the Rap Flag (24) (single TS packet at a time) with this Unit Attribute. The step of RapFlag set (24) refers to the determination of whether Rapflag in the Unit Attribute is set, for example, to a non-zero value. A PES may comprise several TS packets. This set of TS packets are passed to step (26) together with the Unit Attribute. Rapflag in the Unit Attribute is set to correspond with the random-access-indicator bit in the PES header. One should note that only complete TS packets, preferably one TS packet at a time, are passed to the step (26).
If the Rap Flag for this Media Sample is set, it would be necessary to extract the Rap Attribute (24) according to
After the Rap Flag is handled, the Media Sample is written to Media Data File, and then the Unit Attributes are written to the Unit Attribute File (26 & 27) in binary format as would generally understood by a person skilled in the art.
If the particular Media Sample has a positive RapFlag, the Rap Attribute is written to RAP Attribute File in binary format as would generally understood by a person skilled in the art.
A player software could read the Source Info from Source Info File first. Then, for each Media Stream in the Source Info that is selected to be played by the player software, the Unit Attribute in Unit Attribute File would be read sequentially to obtain the Size (for example, in bytes) of data from the Media Data File. The RAP Attribute could be obtained from the RAP Attribute File if the RapFlag in the Unit Attribute for this Media Sample is set to be positive.
For each read operation from Source Info File, Unit Attribute File, Media Data File or RAP Attribute File, the offset the read pointer is incremented by the amount read so that the next read operation can read new data.
Therefore, the player would be able to obtain an exact replica of the Source Stream provided to USRE.
Most codec utilize temporal redundancy to archive compression. This may cause some samples dependent on other samples. The independent samples are so-called Random access point. After a seek operation, an RAP Media Sample near the seek time has to be decoded, otherwise the decoder will output corrupted data.
In this case, the player software first looks for the RAP Attribute from the RAP Attribute File with the largest Timestamp less than the time the user wanted to seek to. The Unit id of the RAP Attribute is then used to calculate the offset of the Unit Attribute of the corresponding Media Sample in the Unit Attribute File. The corresponding Unit Attribute's offset equals to the Unit id*Size of Unit Attribute. With the Unit Attribute and offset in the Media Data File of the Media Sample with RapFlag, the player can then obtain the RAP Media Sample and start playback.
As an example, the operation of a particular URSE of this invention is described below:
(10) The Input Selector (IS) triggers the start of the USRE for under two conditions:
Upon startup of the whole process, USRE (11) could be given the SI of S, which will be stored in the Source Info File. After the USRE (11) has been started, each Media Stream in SI of S will be handled according to the processes shown in
While the preferred embodiment of the present invention has been described in detail by the examples, it is apparent that modifications and adaptations of the present invention will occur to those skilled in the art. Furthermore, the embodiments of the present invention shall not be interpreted to be restricted by the examples or figures only. It is to be expressly understood, however, that such modifications and adaptations are within the scope of the present invention, as set forth in the following claims. For instance, features illustrated or described as part of one embodiment can be used on another embodiment to yield a still further embodiment. Thus, it is intended that the present invention cover such modifications and variations as come within the scope of the claims and their equivalents.