WO2013012287A2

WO2013012287A2 - Method for receiving media and device thereof

Info

Publication number: WO2013012287A2
Application number: PCT/KR2012/005820
Authority: WO
Inventors: 김경호; 김진필; 차이바카; 이현재
Original assignee: 엘지전자 주식회사
Priority date: 2011-07-20
Filing date: 2012-07-20
Publication date: 2013-01-24
Also published as: US20140331268A1; US9774899B2; CA2842271C; KR20140061352A; WO2013012287A3; KR101964649B1; CA2842271A1; US20160345041A1; US9258590B2

Abstract

A method for receiving media according to one embodiment of the present invention comprises the following steps: selecting a receiving channel; receiving a media transport stream transmitted through the receiving channel; generating a media storage stream based on the received media transport stream; and recording the media storage stream. The media transport stream comprises at least one sync bite which represents data removed from the media transport stream.

Description

Method of receiving media and apparatus thereof

The present invention relates to a media receiving apparatus and a receiving method, and more particularly, to a media receiving apparatus and a receiving method for efficiently recording and playing a received media transport stream.

Currently, digital broadcasts such as terrestrial, cable, satellite, or digital multimedia broadcasting (DMB) are mostly streaming AV content using MPEG-2 Transport Stream (TS).

In addition, digital broadcasting is developing in a direction in which more capacity is required, such as stereo 3D video broadcasting, ultra high definition (UHD) broadcasting, multi-view 3D video broadcasting, hologram broadcasting, and the like.

On the other hand, according to this trend, the digital broadcast receiver receives a high capacity media transport stream and provides a service for playing or storing it to the user.

However, since high capacity media transport streams are optimized for transport, they may be inefficient in playback and recording.

One embodiment of the present invention is to provide a method and apparatus for receiving and efficiently recording a media transport stream such as MPEG-2 TS.

Another embodiment of the present invention is to provide a method and apparatus for recording a media transport stream such as MPEG-2 TS, etc., which can reduce waste of storage space while maintaining playback compatibility and performance.

In accordance with another aspect of the present invention, there is provided a media reception method comprising: selecting a reception channel; Receiving a media transport stream transmitted over the receive channel; Generating a media storage stream based on the received media transport stream; And recording the media storage stream, wherein the media storage stream includes at least one sync byte representing the data removed from the media transport stream.

In addition, a media receiving apparatus according to an embodiment of the present invention for achieving the above object, the media receiving apparatus, comprising: a receiver for selecting a channel and receiving a media transport stream transmitted through the selected channel; A control unit for generating a media storage stream based on the received media transport stream; And a storage unit for recording the media storage stream, wherein the media storage stream includes at least one sync byte representing data removed from the media transport stream.

According to an embodiment of the present invention, in receiving a media transport stream such as MPEG-2 TS, some unnecessary data is removed during playback or recording from among the received streams, and a sync byte indicating this is included in the media storage stream for storage. This reduces the storage capacity of the media file while ensuring playback compatibility.

In addition, according to another embodiment of the present invention, information about some removed data may be explicitly or implicitly included in the media storage stream, thereby making it possible to restore the data.

Meanwhile, according to an embodiment of the present invention, some unnecessary data may be removed simultaneously with file indexing for storing a media transport stream, thereby improving storage space utilization while maintaining a recording speed.

1 is a block diagram illustrating a configuration of a media transmission and reception system according to an embodiment of the present invention.

2 is a block diagram illustrating a configuration of a receiving apparatus according to an embodiment of the present invention.

3 is a flowchart illustrating a media reception method according to an embodiment of the present invention.

4 is a diagram for explaining the configuration of an MPEG-2 TS.

5 illustrates a mechanism in which stuffing data and null packets are removed from a media transport stream according to an embodiment of the present invention.

FIG. 6 illustrates packet format syntax of a media storage stream and sample format syntax using the same when a null packet is removed according to an embodiment of the present invention. FIG. 7 illustrates various types of MPEG2TSConstructor that may be included in the syntax of FIG. Constructor format syntax.

8 illustrates a packet format of a media storage stream when null packets and stuffing bytes are removed according to another embodiment of the present invention.

9 is a flowchart illustrating a method of removing a null packet from a media transport stream according to an embodiment of the present invention.

10 is a flowchart illustrating a method of restoring an original media transport stream from a media storage stream from which null packets have been removed according to another embodiment of the present invention.

11 is a block diagram illustrating a file system structure of a receiving apparatus capable of recording a media storage stream according to an exemplary embodiment of the present invention.

12 to 13 are experimental data for comparing and explaining the effect of securing the storage space according to an embodiment of the present invention.

14 is a block diagram showing an IPTV receiver configuration according to an embodiment of the present invention.

15 is a block diagram showing another embodiment of the configuration of the IPTV receiver according to the present invention, and shows the configuration of the IPTV receiver in functional blocks.

The following merely illustrates the principles of the invention. Therefore, those skilled in the art, although not explicitly described or illustrated herein, can embody the principles of the present invention and invent various devices that fall within the spirit and scope of the present invention. Furthermore, all conditional terms and embodiments listed herein are in principle clearly intended for the purpose of understanding the concept of the invention and are not to be limited to the specifically listed embodiments and states. Should be.

In addition, it is to be understood that all detailed descriptions, including the principles, aspects, and embodiments of the present invention, as well as listing specific embodiments, are intended to include structural and functional equivalents of these matters. In addition, these equivalents should be understood to include not only equivalents now known, but also equivalents to be developed in the future, that is, all devices invented to perform the same function regardless of structure.

Thus, for example, it should be understood that the block diagrams herein represent a conceptual view of example circuitry embodying the principles of the invention. Similarly, all flowcharts, state transitions, pseudocodes, and the like are understood to represent various processes performed by a computer or processor, whether or not the computer or processor is substantially illustrated on a computer readable medium and whether the computer or processor is clearly shown. Should be.

The functionality of the various elements shown in the figures, including functional blocks represented by a processor or similar concept, can be provided by the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functionality may be provided by a single dedicated processor, by a single shared processor or by a plurality of individual processors, some of which may be shared.

In addition, the explicit use of terms presented in terms of processor, control, or similar concept should not be interpreted exclusively as a citation to hardware capable of running software, and without limitation, ROM for storing digital signal processor (DSP) hardware, software. (ROM), RAM, and non-volatile memory are to be understood to implicitly include. Other hardware for the governor may also be included.

In the claims of this specification, components expressed as means for performing the functions described in the detailed description include all types of software including, for example, a combination of circuit elements or firmware / microcode, etc. that perform the functions. It is intended to include all methods of performing a function which are combined with appropriate circuitry for executing the software to perform the function. The invention, as defined by these claims, is equivalent to what is understood from this specification, as any means capable of providing such functionality, as the functionality provided by the various enumerated means are combined, and in any manner required by the claims. It should be understood that.

The above objects, features, and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, whereby those skilled in the art may easily implement the technical idea of the present invention. There will be. In addition, in describing the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram illustrating a configuration of a media transmission and reception system according to an embodiment of the present invention. The illustrated transmission and reception system may include a transmission device 100 and a reception device 200.

Referring to FIG. 1, the transmitter 100 and the receiver 200 may transmit and receive data using a broadcast based or IP (Internet Protocol) based transmission system.

The transmitting device 100 may receive the content from the content provider, convert the content, transmit the content, or store the content in a media DB (media DataBase).

For example, the media transport stream provided from the content provider may be an MPEG-2 Transport Stream (MPEG-2 TS) widely adopted in various application fields as a media transport stream according to the MPEG-2 standard, and may be a transmission device ( 100 may convert the MPEG-2 TS into a media file format defined by ISO, and then transmit the data through a network such as a broadcasting network or an internet network, or store it in the media DB.

Meanwhile, the reception apparatus 200 may receive a media transport stream from the transmission device 100, convert the received media transport stream, play the converted media transport stream, or store the media transport stream in a local storage medium. The reception device 200 may be, for example, a network TV, a smart TV, an IPTV, a set-top box, or the like, and may be implemented in a smartphone, a laptop, and the like as necessary.

For example, the reception apparatus 200 may convert a media transport stream received from the transmission apparatus 100 into an MPEG-2 TS format, process the same, and then play or store it in the local storage medium. In particular, the receiving device 200 may index and store MPEG-2 TS encapsulated in a media file format.

The MPEG-2 TS targets lossy transport systems, such as digital video broadcasting environments such as Digital Video Broadcasting (DVB) or Advanced Television System Committee (ATSC). The MPEG-2 TS-based media is widely used, and its encoding and decoding engines are usefully used in digital video broadcasting environments.

However, there is redundancy unnecessary for playback and storage in the MPEG-2 TS-based media file format currently used. For example, in order to broadcast a fixed bitrate CBR (Constant Bitrate) coded MPEG-2 TS stream, data for maintaining bitrate is present in a codec layer or an encapsulation layer in the media stream. However, the data is not used for reproduction or storage of the image. Nevertheless, the current MPEG-2 TS system cannot resiliently remove such unnecessary redundancy.

Therefore, according to an exemplary embodiment of the present invention, the reception apparatus 200 reduces redundancy of MPEG-2 TS-based media at the same time as storing or playing the received media transport stream, thereby reducing waste of storage space and increasing efficiency. Can improve.

To that end, the receiving device 200 may perform compression or conversion for redundancy removal on MPEG-2 TS-based media and store the media storage stream format in local storage.

In addition, the receiving device 200 may record the compressed or converted media storage stream in the local storage. The receiving device 200 may perform the compression or conversion at the same time as the file indexing process and record the data in the local storage.

The receiving device 200 may play the recorded media storage stream according to a user request. In addition, the reception apparatus 200 may restore the removed data to generate an original transport stream and transmit the restored stream to the outside through a network.

2 is a block diagram illustrating a configuration of a receiving apparatus according to an embodiment of the present invention. The receiving apparatus 200 illustrated includes a receiving unit 210, a control unit 220, a display unit 230, and a storage unit 240. ).

Referring to FIG. 2, the receiver 210 receives an MPEG-2 TS media transport stream.

The controller 220 may remove some data from the input MPEG-2 TS media transport stream, convert the data into a storage stream, and store the data in the storage 240. The storage stream may include at least one sync byte indicating that some data has been removed.

Here, MPEG-2 TS is defined for use in lossy systems, and has a fixed packet size of 188 bytes to satisfy the requirements of an Asynchronous Transfer Mode (ATM) network. The timing and buffering model is mainly fixed. Focus on the channel at the bit rate.

However, streams transmitted in accordance with network requirements may contain unnecessary data for storing and playing back already transmitted streams. Accordingly, the method for receiving a media transport stream according to an embodiment of the present invention can remove data unnecessary for storing and playing back a previously received transport stream, and store the data in a media file format compatible with the MPEG-2 TS system.

For example, the unnecessary data removed from the MPEG-2 TS is syntax-based redundancy, which is a specific syntax element included in the header of the MPEG-2 TS, stuffing bytes, or nulls. It may be a packet.

Meanwhile, as described above, the reception apparatus 200 may insert information about data removed from the MPEG-2 TS into a media stream having a storage format using sync bytes. The storage format may be compatible with the MPEG-2 TS format.

For example, the control unit 220 of the reception apparatus 200 removes a specific null packet from the MPEG-2 TS, and inserts a sync byte indicating the presence of a null packet at a position where the null packet is removed, thereby removing the stored stream. The capacity can be reduced.

Hereinafter, exemplary embodiments of a media receiving method according to the present invention will be described in detail with reference to FIGS. 3 to 11.

FIG. 3 is a flowchart illustrating a media receiving method according to an embodiment of the present invention in conjunction with a block diagram showing a configuration of a transmitting apparatus according to an embodiment of the present invention shown in FIG. 2. do.

Referring to FIG. 3, the receiving unit 210 of the receiving device 200 receives a media transport stream (S110). The receiver 210 may receive a media transport stream in the form of MPEG2 TS from an internet network or a broadcast network through HTTP. To this end, the receiver 210 may include a tuner, a demodulator, or a network interface. The received media transport stream may be delivered to the controller 220.

The controller 220 removes some data from the received media transport stream (S120).

For example, the controller 220 may remove redundancy data unnecessary for reproduction or storage of the input MPEG-2 TS.

Referring to the configuration of the MPEG-2 TS shown in FIG. 4, a transport packet consists of a header of 4 bytes and a payload of 184 bytes following the header, so that the size of 188 bytes is independent of the intended transmission mechanism. Have

The header includes an 8-bit sync byte, a 1-bit transport error indicator, a 1-bit unit start indicator, and a 1-bit transport packet priority. ), 13-bit PID (Packet Identification), 2-bit scramble control (transport scrambling control), 2-bit adaptation field control (AFC) and 4-bit continuity counter (continuity counter) can be included. .

By the packetization mechanism of MPEG-2 TS having a fixed size of 188 bytes per packet as described above, byte stuffing can be used.

For example, if the Program Specific Information (PSI) transport stream packet is partially filled or if the Program Elementary Stream (PES) packet only partially fills the TS packet, unnecessary stuffing bytes as described above are included in the MPEG-2 TS. Can be.

That is, the stuffing byte may repeatedly insert bytes having a value of 0xFF into the payload of MPEG-2 TS in order to satisfy a fixed bit rate of 188 bytes per packet, thus unnecessary for storage and playback. Can generate data capacity.

In addition, unnecessary null packets may be inserted into the MPEG-2 TS to achieve a fixed bandwidth or the required muxiplexing ratio. In this case, the decoder removes null packets as described above and then performs decoding.

For example, when the PID included in the header is 0x1FFF, this may indicate that the packet is a null packet, and the payload of the null packet may be filled with all zeros or 0xFF bytes.

According to an embodiment of the present invention, the control unit 220 of the receiving apparatus 200 removes unnecessary data as described above, for example, stuffing bytes or null packets, from the received MPEG-2 TS, thereby saving storage space. It can be secured.

However, the stuffing byte and the null packet of the MPEG-2 TS are just examples according to an exemplary embodiment of the present invention, and the present invention is not limited thereto. In addition to the above-described data, the reception apparatus 200 may store and reproduce the data. Unnecessary data can be removed from the MPEG-2 TS.

Thereafter, the controller 220 generates a media storage stream based on the media transport stream from which data is removed (S130). The media storage stream may be recorded in the storage unit 240 and may have an MPEG2-TS compatible format that can be reproduced by the receiving apparatus 200 or another device as necessary.

For example, the controller 220 may reconstruct the MPEG-2 TS from which unnecessary data is removed in step S120 into a media storage stream according to the ISO / IEC 14496-12 ISO Base Media file format. Since the reconstructed media storage stream is small and maintains compatibility with the existing MPEG2-TS format, a general MPEG-2 TS decoder can play the reconstructed media storage stream without any problem.

Here, the controller 220 allocates a sync byte representing the removed data and inserts it into the media storage stream (S140).

For example, the controller 220 may allocate information signaling the data removed in step S120 as a specific value of the sync byte, and include the sync byte in the media storage stream. Since the sync byte is an essential component of MPEG2-TS, signaling for data removal can be performed without additional data through signaling using the sync byte.

The controller 220 may play back a voice or video by referring to the sync byte of the media storage stream. In playback, data removed from the media transport stream may be ignored depending on the value assigned to the sync byte.

Meanwhile, the controller 220 may restore the removed data based on the sync byte.

For example, when the removed data includes the aforementioned null packet, the controller 220 may restore the media storage stream to the transport stream originally received by restoring the removed null packet based on the sync byte. .

In addition, according to another embodiment of the present invention, when the removed data includes the stuffing byte described above, the controller 220 may place information for restoring the original transport stream behind the sync byte. Accordingly, the controller 220 may restore the original transport stream by restoring the null packet and the stuffing byte based on the sync byte and the restoration information.

Thereafter, the controller 220 records the media storage stream including the sync byte in the storage 240 (S150).

For example, the controller 220 may receive an MPEG2-TS media transport stream corresponding to a program reserved for recording by a user, generate a media storage stream, and record the media storage stream in the storage 240. In addition, the media storage stream recorded in the storage unit 240 may be played in response to a recording scheduled program play request of the user.

In addition, the controller 220 may transmit the media storage stream recorded in the storage 240 to an external device through a network interface. When the external device supports the playback of MPEG2-TS, since the external device can play the media storage stream from which unnecessary data has been removed without problem, the media storage stream recorded by the controller 220 may be used by other devices that comply with the MPEG standard. It can have high compatibility with.

Here, the storage unit 240 may store a program for processing and controlling each signal in the control unit 240, or may store a signal processed image, audio, or data signal. In addition, the storage unit 240 may perform a function for temporarily storing an image, audio, or data signal input from the receiver 210. In addition, the storage unit 240 may store information on a predetermined broadcast channel through a channel storage function.

To this end, the storage unit 240 may be, for example, a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (for example, SD). Or a storage medium of at least one type of XD memory, etc.), RAM, ROM (EEPROM, etc.).

FIG. 5A illustrates a media transport stream (MPEG2 TS) received by the receiver 210. Each packet may contain 1 byte of sync byte and 187 bytes of data byte.

5 (b) shows a media storage stream generated from a media transport stream. As illustrated in FIG. 5B, the controller 220 may generate a media storage stream having a new format in which stuffing bytes and null packets are removed from the media transport stream.

First, the first packet will be described. A, B, and C may be stuffing bytes allocated as 0xFF, and L, M, and N may be data bytes including actual data.

The controller 220 may first parse the first packet, remove the stuffing bytes A, B, and C from the media transport stream, and generate a media storage stream having a data portion of L, M, and N only.

In this case, the controller 220 may allocate the sync byte of the packet from which the stuffing byte has been removed, to a specific value in the media storage stream. For example, 0x02 may be allocated to the sync byte of the packet from which the stuffing byte has been removed.

In addition, the controller 220 may configure recovery information for restoring the removed stuffing byte. For example, the restoration information may include entry_count and offset_length_table.

The control unit 220 may place the restoration information after the sync byte, and the restoration information may be used to restore the original media transport stream.

The entry_count of the restoration information may indicate the number of data byte intervals separated by stuffing bytes.

Offset_length_table of the restoration information may include a table that sequentially indicates the length of each data byte interval.

Meanwhile, in FIG. 5A, the controller 220 determines that the second packet of the media transport stream is a null packet, and may remove the same and insert it into the media storage stream as shown in FIG. 5B.

The controller 220 may allocate the sync byte of the packet from which the null packet is removed, to a specific value in the media storage stream.

For example, the sync byte of the packet from which the null packet is removed may be allocated to 0x01 as shown in FIG. 5 (b), but another value may be assigned. For example, the sync byte of a packet from which null packets have been removed may be assigned to 0xFF.

In particular, when a sync byte of a packet from which a null packet is removed is allocated as 0xFF, other devices supporting the existing standard can ignore the packet during playback, thereby improving playback compatibility.

Meanwhile, since the third packet of FIG. 5 (a) is a data packet, the controller 220 may insert the same into the media storage stream as shown in FIG. 5 (b) while maintaining the sync byte at 0x47.

As shown in FIG. 6, the media storage stream recorded by the controller 220 may have a packet format according to sync bytes.

Each packet may include packet data according to a preceding byte, a sync byte, a trailing byte, and a sync byte.

The preseeding byte represents additional data that the receiving device 200 may add in front of the packet data. For example, the additional data may include a time stamp.

The sync byte indicates the format of transport stream packet data following the sync byte.

If the sync byte is 0x47, 187 bytes of data following the sync byte may include remaining data except for the sync byte in the MPEG2-TS packet of the received media transport stream as it is in the packet field. If packet data is actually input to the streaming channel, this value should always be set to 0x47.

In addition, when the sync byte is 0x00 or 0x01, the data following the sync byte includes header data length, number of constructors, transmission error indicator, payload unit start indicator, transmission priority, packet identifier, transmission scrambling control, and adaptive field control. , And at least one MPEG2 TS constructor. When the MPEG2 TS sample constructor is used, the MPEG2 TS sample constructor may point to a track that is indexed by a track reference index field in a track reference box whose reference type is hint.

7 illustrates various formats of the MPEG2 TS Constructor. The MPEG2 TS constructor may include an MPEG2 TS constructor (MPEG2TConstructor) having a configuration type field, an MPEG2 TS immediate constructor (MPEG2TSImmediateConstructor), an MPEG2 TS sample constructor (MPEG2TSSampleConstructor), and an MPEG2 TS FF duplicate constructor (MPEG2TSReplicatedFFConstructor). Each constructor may include a plurality of fields according to the purpose.

Here, the MPEG2 TS Constructor, the MPEG2 TS Immediate Constructor, and the MPEG2 TS Sample Constuctor may follow a format defined in ISO 14496-12.

Meanwhile, the MPEG2 TS FF Replication Constructor (MPEG2TSReplicatedFFConstructor) may include a duplicated count field indicating how many times a particular value is repeated, for example, 0xFF bytes. By using this, the reception apparatus 200 may briefly indicate a plurality of 0xFF bytes in the received media transport stream using the MPEG2 TS FF copy constructor. The reception device 200 may repeatedly generate 0xFF data and include the packet in the packet when there is an MPEG2 TS FF copy constructor at the time of reproduction.

For example, the reception apparatus 200 may remove 0xFF bytes repeated in the transport stream packet instead of the null packet, and may indicate this by using the MPEG2 TS FF replication constructor. Using the MPEG2 TS FF copy constructor for the media storage stream format has the effect of further reducing the capacity of the media storage stream from which null packets have been removed.

Also, for storage efficiency, the MPEG2 TS FF copy constructor may be used only when the number of repeated bytes is greater than or equal to a certain size. For example, the MPEG2 TS FF copy constructor may be included in the media storage stream data only when 0xFF is repeated more than the size of the copy count field. Accordingly, when unnecessary data is repeated in the receiver storage device or the storage device of the server, it may be removed as necessary.

In FIG. 6, when the sync byte is 0x00 or 0x01, the packet data following it may include such MPEG2 TS constructors in the form of an array of num_constructors size. One or a plurality of stream packets may be configured by a single or a combination of MPEG2 TS constructors.

For example, the MPEG2 TS Immediate Constructor may include a PES header. In addition, the MPEG2 TS Sample Constructor may reference data in an associated media track. In addition, when the MPEG2 TS Replicated FF constructor is not used, the sum of the header data length value and the value of the data length field for all the constructors of one MPEG2 TS packet is the stream packet. It can be 187 minus one byte from the length of.

On the other hand, if the sync byte is 0xFF, the sync byte indicates that the null packet at that position has been removed. Thus, there may be no 187 bytes of packet data following the sync byte 0xFF. In this way, the control unit 220 may implicitly indicate that the null packet in the media storage stream has been removed by removing the data. It can also be indicated explicitly through the 0xFF value assignment for the sync byte.

The trailing byte indicates additional data that the reception apparatus 200 may add after the packet data. For example, the additional data may include a checksum indicating whether there is an error.

Referring to FIG. 8, the case where the sync byte of the media storage stream packet is 0x47 or 0x00 and the overlapping format are the same as in FIG. 6, and thus description thereof will be omitted.

If the sync byte is 0x01, the sync byte may indicate that the null packet is removed, as in the case of 0xFF in FIG. The size of the discarded null packet may be 187 bytes.

On the other hand, if the sync byte is 0x02, the sync byte may indicate that the stuffing byte has been removed.

Here, the packet from which the stuffing byte is removed may include recovery information for reconstructing the stuffing byte.

The restoration information may include entry_count information of the data sections separated by the removed stuffing byte, offset information of each data section, and length information of each section.

Accordingly, the controller 220 may restore the original media transport stream from the media storage stream from which the stuffing byte has been removed.

For example, the controller 220 may restore the original media transport stream packet by arranging data sections having a length of length for each offset in the packet and filling the remaining portions with stuffing bytes of 0xFF. .

Referring to FIG. 9, first, the receiver 210 receives a media transport stream (S200). As described above, the receiver 210 may receive a media transport stream such as an MPEG2 TS transmitted through a broadcast channel or an internet network according to a user request. The receiver 210 may transfer the received media transport stream to the controller 220.

The controller 220 sequentially acquires packets from the received media transport stream (S210).

The controller 220 may select a media transport stream of a program that the user reserves or requests for storage from among the received media transport streams, and obtain packets included in the media transport stream for storage of the media transport stream.

The controller 220 determines whether the obtained packet is a null packet (S220). A null packet can typically contain a fixed data pattern, for example zeros. Accordingly, the controller 220 may determine whether the packet is a null packet based on whether the fixed data pattern exists in the packet.

In addition, the controller 220 may separately include a null packet detector for determining a null packet. The null packet detector acquires a null packet by detecting a preamble of the media transport stream packet data received at the receiver 210 and determining whether subsequent data bits are equal to a fixed data pattern, for example, consecutive zeros. It can be transmitted to the control unit 220.

When it is determined that the packet is null, the controller 220 allocates a sync byte corresponding to the null packet to a specific value, for example, 0xFF (S230), and stores the allocated sync byte in the storage 240 (S240). .

The controller 220 may remove the packet data corresponding to the null packet from the media transport stream received by the receiver 210 and record the packet data in the media storage stream format in the storage 240. At this time, the controller 220 may include the sync byte allocated with 0xFF in the media storage stream so as to correspond to the null packet and record it.

On the other hand, if it is determined that the packet is not a null packet, the control unit 220 extracts packet data from the packet (S250), and allocates sync bytes according to the contents of the data (S260).

If it is determined that the packet data is general packet data instead of a null packet, the controller 220 may designate a sync byte corresponding to the data of the packet in order to store the packet in a media storage stream format.

The sync byte may be determined according to the content of the packet data. For example, when the above-described MPEG2-TS constructor is needed to store or reproduce packet data, or when the packet data includes header information or the like, the controller 220 may designate a sync byte as 0x00. When the packet data completely includes only video or audio data of MPEG-2 TS, the controller 220 may designate a sync byte as 0x47.

The controller 220 determines whether the currently acquired packet is the last packet of the received media transport stream (S280).

In the case of the last packet, the controller 220 may finish recording the media storage stream, perform the necessary processing, and then terminate the operation. The controller 220 may play back the stored media storage stream or transmit the stored media storage stream to another device or another storage medium according to a user request.

If it is not the last packet, step S210 is performed again to sequentially obtain the next packet of the received media transport stream.

Through this process, the reception apparatus 200 may reduce the storage space while storing the received media transport stream in a format compatible with the existing MPEG-2 TS decoding system.

For example, the receiving device 200 or another MMPEG-2 TS playable device can simply play back the media storage stream recorded by the above method.

For example, the controller 220 may receive a playback selection of a media storage stream, and sequentially obtain media storage stream data selected from the storage 240 according to sync bytes.

Here, the controller 220 may acquire the sync byte first, and if the sync byte is 0xFF, ignore the packet according to the MPEG-2 TS standard and process a packet corresponding to the next sync byte. If it is not 0xFF, the controller 220 can reproduce the corresponding packet data up to the next sync byte.

Accordingly, the method of receiving a media transport stream according to the present invention can record an MPEG-2 TS format of a received media transport stream without additional information while recording in a media storage stream in which unnecessary null packets are removed.

Meanwhile, the information about the media storage stream may be separately stored in a hint track in the media storage stream for later transmission, but is not limited thereto.

Meanwhile, according to an embodiment of the present invention, unnecessary null packets or stuffing packets may be removed to be recoverable.

Referring to FIG. 10, first, the controller 220 determines transport stream restoration (S300).

The controller 220 may determine the restoration of the media transport stream that was originally received according to the user input. The controller 220 may load the media storage stream from the storage 240 to restore the media transport stream.

The controller 220 sequentially acquires sync bytes from the media storage stream (S310), and determines whether the sync byte value is 0xFF (S320).

If the value of the sync byte is not 0xFF, the controller 220 restores the sync byte according to the packet data since it is not a null packet (S330). The sync byte may be designated, for example, 0x47 indicating a transport stream packet.

The controller 220 inserts packet data up to the next sync byte into the transport stream to be restored (S340).

On the other hand, if the sync byte is confirmed to be 0xFF, the control unit 220 determines to be a null packet (S350), and restores the sync byte (S370). Since the null packet is also a transport stream packet for bandwidth maintenance, the sync byte may be designated as 0x47.

In response to the restored sync byte, the controller 220 generates a null packet and inserts the generated null packet into the transport stream (S370).

Thereafter, the controller 220 determines whether the restoration is completed (S380). When the restoration ends, the controller 220 may transmit the restored transport stream to the outside. If the restoration is not finished, step S310 may be performed again.

In this way, the reception apparatus 200 enables the restoration of the media transport stream from the media storage stream from which null packets have been removed using the sync byte.

Referring to FIG. 11, a file system may be divided into a user level, a kernel level, and a hardware level.

The user level DMA program module 300 forwards file system requests originating from applications in the user domain to the kernel level and receives the responses.

In addition, each block constituting the kernel level is a core of an operating system, and when a receiver 200 is driven, a hardware driver is driven, security of hardware and a processor in an image display device, efficient management of system resources, and memory management. , At least one of providing an interface to hardware by hardware abstraction, multiprocessing, and schedule management according to the multiprocessing.

Such kernel-level blocks may be implemented based on various operating systems (OS) such as Unix-based (Linux) and Windows-based. In addition, as an open OS kernel, it may be implemented as a general-purpose kernel usable in other electronic devices.

The media transport stream reception method according to an embodiment of the present invention may be performed by the kernel level MPEG-2 TS compression module 310.

The MPEG-2 TS compression module 310 receives the MPEG-2 TS media transport stream in response to a request input through the system call module 305 from the user level, and eliminates null packets or stuffing bytes according to an embodiment of the present invention. May be performed and transferred to the file system 320.

In addition, the MPEG-2 TS compression module 310 may transfer data, in which each MPEG-2 TS packet or consecutive packets are combined, to a user level MPEG-2 TS system decoder using a DMA channel.

Meanwhile, the kernel may optionally provide an interface named / DEV / MP2T, for example, to directly access the file system through the MPEG-2 TS compression module 310 without the help of a DMA channel.

The file system 320 indexes the media storage stream file in which unnecessary data is removed from the MPEG-2 TS compression module 310 and compressed, and stores the media storage stream file in the hardware storage device 350 through the device driver 340. To this end, the file system 320 may be subjected to process control of the control assistance system 315.

The file system 320 is connected to the character module 335 and the block module 330 for data processing. The block module 330 may need a buffer cache 325 to store as much as the unit size because data is transmitted in a specific block unit. In addition, the character module 335 transmits data in character units, which are basic data units of the kernel, and thus may not require a buffer.

The device driver 340 controls the device connected through the hardware controller 345. The device driver 340 may store data indexed by the file system 320 in the storage device 350 through the hardware controller 345.

Through such user level, kernel level, and hardware level system configuration, null packets are removed by the MPEG-2 TS compression module 310 and compressed and stored in the storage device 350 at the same time as file indexing. Therefore, according to an embodiment of the present invention, it is possible to secure storage space only by removing null packets without a delay time caused by compression. Therefore, efficient storage space utilization is possible.

12 shows a media transport stream as an experiment target, and FIG. 13 shows the size and compression ratio of data according to each experiment result.

In each column of FIG. 13, segments (byte area duration, sec), original size (bytes), size in which null packets are removed (bytes), compression ratio (%) when null packets are removed, and stuffing bytes are removed. The size (bytes), the compression rate (%) when stuffing bytes are removed, the size (bytes) when compressed with a gzip application, and the compression rate (%) of gzip.

As can be seen in FIG. 13, it can be seen that the size of the media storage stream from which null packets or stuffing bytes have been removed results in a significant storage capacity reduction than the original size. In addition, it can be determined that the compression ratio due to the reduction of the storage capacity does not differ significantly from gzip, which is a compression only application. In particular, the media storage stream format according to an embodiment of the present invention has the compatibility that can be played as it is without decompression process, such as gzip, thereby reducing the storage capacity and bring the effect of being able to play without delay in existing playback devices Can be.

Media receiving and processing methods as described with reference to FIGS. 1 to 13 may be performed by an IPTV receiver according to an embodiment of the present invention.

Hereinafter, the configuration of an IPTV receiver according to an embodiment of the present invention will be described in more detail with reference to FIGS. 14 and 15.

The IPTV receiver according to an embodiment of the present invention may include a separate tuner or the like for receiving terrestrial broadcasting, cable broadcasting, satellite broadcasting, or the like. However, in the present invention, for the convenience of description, a description will be given of the configuration of receiving an IPTV service provided using an IP network.

On the other hand, ITF represents an Open IPTV Terminal Function, which may mean a receiver composed of a function module required to support the IPTV service.

The IPTV receiver includes a network interface 901, a TCP / IP manager 902, a service delivery manager 904, a PVR manager 905, Demultiplexer (908), Data Decoder (907), Audio / Video Decoder (912), A / V Display & OSD Module (915), Application Manager ( Application Manager (913, 914), Service Information Database (SI & Metadata DB) 911, Service Discovery Manager (909), Service Control Manager (903), Metadata Manager (Metadata Manager) 910 and a content database unit (Content DB) (906).

Referring to FIG. 18, the network interface unit 901 receives packets received from a network and transmits the packets to the network. That is, the network interface unit 901 receives a service, media content, etc. from a service provider through a network.

The TCP / IP manager 902 is involved in packet transmission from the source to the destination for the packet received by the IPTV receiver and the packet transmitted by the IPTV receiver. In addition, the TCP / IP manager 902 classifies the received packet to correspond to an appropriate protocol, and sends it to the service delivery manager 904, the service discovery manager 909, the service control manager 903, and the metadata manager 910. Output sorted packets.

The service delivery manager 904 is responsible for controlling the received service data. For example, RTP / RTCP can be used to control real-time streaming data.

When transmitting the real-time streaming data using the RTP, the service delivery manager 904 parses the received data packet according to the RTP and transmits it to the demultiplexer 908 or under the control of the service manager 914. The content database unit 906 stores the content. The service delivery manager 904 also feeds back the network reception information to the server side providing the service using RTCP.

The demultiplexer 908 demultiplexes the received packet into audio, video, program specific information (PSI) data, and the like, and transmits the demultiplexer 908 to the audio / video decoder 912 and the data decoder 907, respectively.

The data decoder 907 decodes service information such as, for example, program specific information (PSI). That is, the data decoder 907 receives and decodes the demultiplexed PSI section, the program and service information protocol (PSIP) section, or the service information (DVB-SI) section from the demultiplexer 908.

In addition, the data decoder 907 decodes the received sections to create a database of service information, and stores the database of the service information in the service information database unit 911.

An audio / video decoder 912 decodes the video data and the audio data received at the demultiplexer 908. The audio data and the video data decoded by the audio / video decoder 912 are provided to the user through the display unit 915.

The application manager manages the overall state of the IPTV receiver, provides a user interface, and manages other managers. For this purpose, the application manager includes a user interface manager 913 and a service manager 914.

The user interface manager 913 provides a graphical user interface (GUI) for a user using an OSD (On Screen Display), etc., and receives a key input from a user to perform a receiver operation according to the input. For example, upon receiving a key input related to channel selection from a user, the key input signal is transmitted to the service manager 914.

The service manager 914 controls a manager associated with a service, such as a service delivery manager 904, a service discovery manager 909, a service control manager 903, and a metadata manager 910.

In addition, the service manager 914 creates a channel map and selects a channel using the channel map according to a key input received from the user interface manager 913. The service manager 914 receives service information of a channel from the data decoder 907 and sets an audio / video packet identifier (PID) of the selected channel to the demultiplexer 908.

The service discovery manager 909 provides information necessary to select a service provider that provides a service. Upon receiving a signal regarding channel selection from the service manager 914, the service discovery manager 909 finds a service using the information.

The service control manager 903 is responsible for selecting and controlling services. For example, the service control manager 903 uses IGMP or RTSP when the user selects a Live Broadcasting service such as a conventional broadcasting method, and uses RTSP when selecting a service such as VOD (Video On Demand). Can be used to select and control services.

The RTSP protocol may provide a trick mode for real time streaming. In addition, the service control manager 903 may initiate and manage a session through the IMC gateway using an IP multimedia subsystem (IMS) or a session initiation protocol (SIP). The protocols are one embodiment, and other protocols may be used depending on implementation.

The metadata manager 910 manages metadata associated with a service and stores the metadata in the service information database unit 911.

The service information database unit 911 stores service information decoded by the data decoder 907, metadata managed by the metadata manager 910, and information necessary to select a service provider provided by the service discovery manager 909. do. In addition, the service information database unit 911 may store setup data for the system.

The service information database unit 911 and the content database unit 906 may be implemented using nonvolatile memory (NVRAM) or flash memory, respectively, and are two logically separated areas on the same storage area. Can be implemented.

The PVR manager 905 is a module for recording and playing back live streaming content. The PVR manager 905 may collect metadata about the recorded content and generate additional information provided to the user such as a thumbnail image or an index.

The function of the controller of the IPTV receiver capable of removing null packets according to an embodiment of the present invention is the TCP / IP manager 902, the service delivery manager 904, the PVR manager 905, the

application manager

913, 914, a service discovery manager 909, a service control manager 903, and a metadata manager 910 may be divided into a plurality of modules.

For example, the TCP / IP manager 902 filters the SD & S information using the target package information as described above, so that the network interface unit 901 corresponds to a specific package (for example, a package to which an IPTV receiver is subscribed). Only the payload or segment may be requested to the server and received.

Alternatively, the TCP / IP manager 902 filters the SD & S information received by the multicast method using the target package information so that only payloads or segments corresponding to a specific package are parsed and processed by the data decoder 907. can do.

15 is a block diagram showing another embodiment of the configuration of the IPTV receiver according to the present invention, and shows the configuration of the IPTV receiver in functional blocks. The solid line arrow shown in FIG. 15 corresponds to the data path, and the dotted line arrow corresponds to the control signal path.

Cable modem, DSL modem, etc (1001) is an interface that allows the ITF to be connected to the IP network at the physical level, and demodulates the signal transmitted through the physical medium to restore the digital signal.

The Ethernet NIC 1002 restores the signal received through the physical interface to IP data, and the IP Network Stack 1007 processes each layer according to the IP Protocol stack.

Meanwhile, the XML Parser 1009 parses an XML Document among received IP data, and the File Handler 1008 processes data transmitted in the form of File through FLUTE among the received IP data.

The SI Handler 1011 processes the part corresponding to the IPTV service information among the received File type data and stores it in the storage 1012, and the EPG Handler 1010 corresponds to the IPTV EPG information among the received File type data. The portion may be processed and stored in Storage 1012.

The storage 1012 stores various data such as the SI and the EPG.

The SI Decoder 1013 receives the SI data from the Storage 1012 and analyzes it to obtain channel map information. The EPG Decoder 1014 analyzes the EPG data stored in the Storage 1012 to restore necessary information for the EPG configuration. do.

The ITF Operation Controller 1015 is a main controller that controls the operation of an ITF such as a channel change or an EPG display.

The channel service manager 1016 may perform an operation such as changing a channel according to a user input, and the application manager 1017 may perform an application service such as an EPG display according to the user input.

The MPEG-2 Demultiplexer 1003 may extract MPEG-2 Transport Stream data from the received IP datagram and deliver the MPEG-2 Transport Stream data to the corresponding module according to the packet identification information (PID).

Also, the MPEG-2 PSI / PSIP Parser 1004 extracts and parses PSI / PSIP data including packet identification information (PID) of A / V data or access information about a program element from the MPEG-2 Transport Stream. Can be.

Meanwhile, the A / V Decoder 1005 decodes the input audio and video data and transmits the decoded audio and video data to the display module 1006. The display module 1006 may output decoded A / V data or an application.

In the above description, a media transmission / reception method and apparatus according to an embodiment of the present invention have been described taking an example in which a media transport stream transmitted / received between a transmitting device 100 and a receiving device 200 is an MPEG-2 TS. The present invention is not limited thereto and may be applied to various transport stream formats in addition to the MPEG-2 TS.

The above-described method for receiving a media transport stream according to the present invention can be stored in a computer-readable recording medium that is produced as a program for execution on a computer. Examples of the computer-readable recording medium include ROM, RAM, CD- ROMs, magnetic tapes, floppy disks, optical data storage, and the like, and also include those implemented in the form of carrier waves (eg, transmission over the Internet).

The computer readable recording medium can be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. In addition, functional programs, codes, and code segments for implementing the method can be easily inferred by programmers in the art to which the present invention belongs.

In addition, although the preferred embodiment of the present invention has been shown and described above, the present invention is not limited to the specific embodiments described above, but the technical field to which the invention belongs without departing from the spirit of the invention claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or prospect of the present invention.

Claims

In a method for receiving media,

Selecting a receiving channel;

Receiving a media transport stream transmitted over the receive channel;

Generating a media storage stream based on the received media transport stream; And

Recording the media storage stream;

The media storage stream includes at least one sync byte representing data removed from the media transport stream.

How to receive media.
The method of claim 1,

The removed data is a null packet included in the received media transport stream.

How to receive media.
The method of claim 2,

The media storage stream further includes a second sync byte different from at least one sync byte representing the removed data and packet data corresponding to the second sync byte.

How to receive media.
The method of claim 3,

If the second sync byte is a specific value, the packet data includes media stream configuration information.

How to receive media.
The method of claim 4, wherein

The media stream configuration information includes repetition number information of the specific data in the media transport stream.

How to receive media.
The method of claim 1,

The removed data is a stuffing byte included in the received media transport stream.

How to receive media.
The method of claim 6,

The media storage stream further includes restoration information for restoring the removed stuffing byte.

How to receive media.
The method of claim 7, wherein

The restoration information is

Section number information, starting point information and interval length information for a plurality of data intervals in the packet including the removed stuffing byte

How to receive media.
The method of claim 1,

Playing the media storage stream;

The playing step

Obtaining a sync byte of the media storage stream; And

Playing packet data included in the media storage stream corresponding to the obtained sync byte, and acquiring a next sync byte if the sync byte indicates the removed data;

How to receive media.
The method of claim 1,

Restoring the media transport stream using the sync byte included in the media storage stream.

How to receive media.
In the media receiving apparatus,

A receiver for selecting a channel and receiving a media transport stream transmitted through the selected channel;

A control unit for generating a media storage stream based on the received media transport stream;

A storage unit for recording the media storage stream,

The media storage stream includes at least one sync byte representing data removed from the media transport stream.

Media Receiving Device.
The method of claim 11,

The sync byte implicitly indicates that data corresponding to the sync byte has been removed at the position of the sync byte.

Media Receiving Device.
The method of claim 11,

The removed data includes a null packet included in the received media transport stream.

Media Receiving Device.
The method of claim 13,

The sync byte has a specific value indicating that the null packet has been removed.

Media Receiving Device.
The method of claim 13,

The media storage stream further includes a second sync byte different from a sync byte representing the removed null packet, and media configuration information according to the second sync byte.

Media Receiving Device.
The method of claim 15,

The media configuration information includes repetition number information of specific data in the media transport stream.

Media Receiving Device.
The method of claim 16,

The control unit generates the media storage stream by removing the repeated specific data of the media transport stream, and inserts the media configuration information into the media storage stream.

Media Receiving Device.
The method of claim 11,

The controller plays the media storage stream,

The display apparatus may further include a display unit configured to display the played media storage stream.

Media Receiving Device.
The method of claim 18,

The control unit obtains the sync byte of the media storage stream and plays back using the packet data of the media storage stream corresponding to the current sync byte, and if the sync byte indicates the removed data, obtaining the next sync byte.

Media Receiving Device.
The method of claim 11,

The control unit restores the media transport stream using the sync byte included in the media storage stream.

Media Receiving Device.