KR100649399B1 - Method and system for providing digital broadcasting service over ip - Google Patents

Abstract

A method for supplying a digital broadcasting service through an IP(Internet Protocol) is provided to be capable of converting the transmission standard of TDMB(Terrestrial Digital Multimedia Broadcasting) into the transmission standard in the IP, and of servicing DMB contents over the Internet, while a user can watch the DMB contents through the wire/wireless Internet as high-quality multimedia contents are supplied to a wireless Internet service like WiBro(Wireless Broadband). A TDMB receiver(100) receives a TDMB signal. A TDMB-IP converter(200) converts type of the received TDMB signal into a type loadable on an IP. A streaming server(300) provides a TDMB stream through the IP. 'SLConfigDescriptor' information on media is mapped into an SDP(Session Description Protocol) type. The generated SDP is packetized into an FLUTE(File delivery over Unidirectional Transport) protocol by an FLUTE packetizer(240) and transmitted.

Description

Method and system for providing digital broadcasting service over IP

1 shows a structure of multiplexing multiple streams required for video service in terrestrial DMB,

2 illustrates a process of accessing multimedia content transmitted through a terrestrial DMB from a decoder perspective.

3 shows an embodiment according to the present invention for a system for providing terrestrial digital multimedia broadcasting (TDMB) over IP,

Figure 4 (a) defines the general structure of the payload format, showing the structure of the RTP packet,

4 (b) shows the structure of the AU header section and the structure of each AU header included in the RTP packet,

5 illustrates a mapping relationship between an SL packet header and an AU header of an RTP packet.

6 shows a mapping relationship between SLConfigDescriptor and SDP,

7 illustrates an embodiment according to the present invention for a service for providing terrestrial digital multimedia broadcasting through IP,

8 illustrates a process of accessing terrestrial digital multimedia broadcasting content transmitted through IP in terms of decoding.

9 (a) shows a case in which only one AU is included in an RTP packet and an SL header is inserted.

FIG. 9 (b) shows a case in which only one AU is included in the RTP packet and no SL header is inserted.

FIG. 9 (c) illustrates a case where several AUs are included in an RTP packet and an SL header is inserted.

9 (d) illustrates a case where several AUs are included in an RTP packet and an SL header is not inserted.

FIG. 10 illustrates a case in which only a video stream and an audio stream are transmitted to RTP without BIFS and OD information.

11 illustrates a session connection process using RTSP when transmitting content in consideration of a live broadcast service such as VOD,

FIG. 12 illustrates a case where an OCR information is inserted into an RTP packet and an information field indicating whether or not to insert OCR information is inserted into the SDP when there is no SL header in the RTP packet.

※ Explanation of code for main part of drawing

100: TDMB receiver 200: TDMB-IP converter

210: TDMB Decoder 220: SDP Generator

240: RTP packetizer 240: FLUTE packetizer

300: streaming server

The present invention relates to a method and a system for providing a digital broadcasting service through IP. More specifically, the transmission standard for terrestrial digital multimedia broadcasting (TDMB) using terrestrial is a transmission standard in IP (Internet Protocol). It is about how to convert.

Digital multimedia broadcasting (DMB) is a broadcasting service that digitally modulates various multimedia data such as voice, video, and data, and provides a new concept of mobile multimedia broadcasting service combining broadcasting and communication. DMB is classified into terrestrial DMB and satellite DMB according to transmission method and network configuration.

In addition, it is called a next-generation broadcast service because it is possible to provide sound quality and data service of CD level and to watch multimedia broadcasts of various channels while moving through small terminals such as mobile phones, PDAs, notebook computers, and car receivers.

Satellite DMB uses satellites, which are broadcasted by satellite DMB broadcasting centers and distributed to DMB terminals nationwide through radio waves. The terrestrial DMB transmits a program using a frequency from the ground, and uses a VHF channel 12 which is currently empty, and unlike a satellite DMB, a broadcast signal is transmitted through a terrestrial base station.

On the other hand, the wireless Internet is widely available, and the WiBro (Wireless Broadband Internet) service that can use the high-speed Internet while moving anywhere anytime is expected to be commercialized soon. The difference between Wibro service and existing wireless internet service is that data and multimedia contents can be transmitted and received while moving more than 60km / h.

In order to promote the dissemination of Wibro terminals capable of such a high speed mobile wireless Internet, various schemes have been envisioned, and various schemes for providing various multimedia contents through Wibro services have been considered. Although multimedia contents may be provided through individual content providers (CPs), a stable and continuous source of multimedia contents may be broadcast programs.

Accordingly, DMB content, which is currently under service, in particular, terrestrial DMB content that is provided free of charge, may be an important source of multimedia content that can be provided through Wibro service, or wireless or wired Internet service.

In order to provide various terrestrial DMB contents that are currently being serviced through an Internet service such as a Wibro network, a process of converting a terrestrial DMB transmission standard into a standard for IP transmission is required. However, there are no standards or regulations for this transformation yet.

The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a method and a system capable of providing broadcast DMB content through the Internet.

Another object of the present invention is to provide a method and system for converting a transmission standard of terrestrial digital multimedia broadcasting (TDMB) into a transmission standard in IP.

The present invention was created to achieve the above object, and a system for providing digital broadcast over IP according to an embodiment of the present invention includes a receiver for receiving a digital broadcast signal; A converter for converting the received broadcast signal into a form that can be carried on an IP; And a server for providing the converted broadcast stream through IP.

Also, a method for converting a digital broadcast into an IP transmission form according to another embodiment of the present invention includes: decoding a received digital broadcast signal; Generating SDP information based on structure information on media data extracted from the decoded broadcast data and first information related to first data describing the media data; And extracting the media data and the first data from the decoded broadcast data, and generating an RTP packet based on the extracted data, wherein the video service of the digital broadcast is MPEG-2. The content of the MPEG-4 standard is transmitted through the TS.

In addition, a method for accessing a digital broadcasting service transmitted through IP according to another embodiment of the present invention includes: receiving SDP information through a known UDP port; Receiving first data describing media data related to digital broadcasting based on the SDP information; And receiving the media data based on the SDP information and the first data.

Hereinafter, a preferred embodiment of a method and apparatus for providing a digital broadcasting service through IP according to the present invention will be described in detail with reference to the accompanying drawings.

First, the terrestrial DMB technology will be described.

Terrestrial DMB is based on the European digital audio broadcasting standard EUREKA-147 Digital Audio Broadcasting (DAB), which adds specifications for providing video services using Moving Picture Experts Group (MPEG) -4 technology. Complemented and added to the data broadcast standard.

Terrestrial DMB transmission and reception specification uses DAB transmission standard. In other words, the Orthogonal Frequency Division Multiplexing (OFDM) transmission technology, which is a digital modulation method developed for DAB, is used to improve transmission speed per bandwidth and prevent multipath interference, thereby showing excellent mobile reception performance.

Terrestrial DMB adopts H.264 / MPEG-4 Part 10 Advanced Video Coding (AVC) baseline profile level 1.3 for video compression, and MPEG-4 Part 3 for audio compression accompanying video. The included bit-sliced arithmetic coding (BSAC) scheme is adopted.

In addition, the terrestrial DMB adopts the Binary Format for Scenes (BIFS) Core2D graphics profile included in the MPEG-4 Part 1 System for data broadcasting, and MPEG-4 SL (Sync Layer) to multiplex such AV data. Packetization and MPEG-2 Transport Stream (TS) packetization are adopted.

1 shows a structure of multiplexing multiple streams required for video service in terrestrial DMB.

IOD and OD / BIFS generators follow the ISO / IEC 14496-1 standard. IOD (Initial Object Descriptor) is the first access point of all related streams and informs ES_ID (Elementary Stream ID) of OD (Object Descriptor) or BIFS (Binary Format for Scene). It includes the SL packet structure information, SLConfigDescriptor, and the decoder information, DecoderConfigDescriptor.

The OD informs the ES_ID constituting the object. The OD includes SLConfigDescriptor, which is structure information necessary for receiving media information such as video and audio, and DecoderConfigDescriptor (+ DecoderSpecificInfo), which is decoding information.

BIFS is a technical standard for performing interaction of graphic data, and efficiently expresses various interactions among various objects constituting a graphic screen, for example, a function of placing an object on the screen.

Video encoders follow the H.264 / AVC standard, and audio encoders follow the ISO / IEC 14496-3 BSAC standard. In addition, the Synchronization Layer (SL) packetizer enables the synchronization of multimedia streams including descriptors, which conforms to the ISO / IEC 14496-1 system standard.

For reference, the IOD / OD / BIFS and SLP described herein are elements used in the MPEG-4 system.

In FIG. 1, a section generator, a packetized elementary stream (PES) packetizer, and a transport stream (TS) multiplexer are elements used in an MPEG-2 system. The section generator mainly manages the multiplexing information, the PES packetizer has the function of matching media synchronization while generating independent streams for each ES according to the ISO / IEC 13818-1 system standard, and the TS multiplexer has PES and section information It is possible to bundle a stream into one stream to facilitate transmission and to synchronize the system.

Reed-Solomon (RS) encoders and Convolutional Interleaver (RS) encoders are communication techniques used in the DAB standard for error-resistant transmission.

That is, a terrestrial DMB video service system transmits MPEG-4 standard content using MPEG-2 TS.

2 illustrates a process of accessing multimedia content transmitted through a terrestrial DMB in terms of decoding.

First, a PAT (Program Association Table) of a TS stream, which is a starting point of multiplexing information, must be searched. Since the PAT includes a broadcasting channel ID (ID) currently being broadcast and a PID (Packet ID) of a PMT having additional information of the corresponding broadcasting channel, the position of the PMT (Program Map Table) can be known from the PAT. The PMT describes the positions of all streams necessary for the user to watch the content, that is, PIDs of video and audio TSs belonging to the corresponding broadcast channel.

In the existing MPEG-2 system, the stream is an ES of video or audio, but in the DMB system, since there is an MPEG-4 system between them, the PMT describes the connection relationship with the SLP stream or the IOD / OD / BIFS stream. Lose. Therefore, after reading the PMT, the decoder is similar to the content access method in the MPEG-4 system. That is, the PMT contains the IOD at the first position, and the ES_ID of the OD and the BIFS can be known inside the IOD, and the remaining PMTs include the types of streams connected to the PID and the respective ES_ID information.

The decoder searches the parts after the IOD of the PMT to access the ES_ID extracted from the IOD, finds the PID associated with the ES_ID, and finds the stream of the PID. That is, the decoder first finds the BIFS and the OD described in the IOD, finds the screen configuration information and the information on the stream of the object, finds and decodes the stream corresponding to the ES_ID constituting the OD, and provides the final content. Can be.

Figure 3 shows an embodiment according to the present invention for a system for providing terrestrial digital multimedia broadcasting (TDMB) over IP.

The system according to the present invention provides a TDMB receiver 100 for receiving a TDMB signal, a TDMB-IP converter 200 for converting the received TDMB signal into a form that can be carried on an IP, and providing a TDMB stream via IP. It consists of a streaming server 300. The TDMB-IP converter 200 includes a TDMB decoder 210, a session description protocol (SDP) generator 220, and a real-time transport protocol (RTP) packetizer 230, and file delivery over FLUTE. Unidirectional Transport) packetizer 240 may be further included. The TDMB decoder 210 may be included in the TDMB receiver 100.

The TDMB decoder 210 obtains IOD, OD, BIFS, video, and audio information for each service from an incoming TDMB service stream. OD, IOD information including DecoderConfigDescriptor and SLConfigDescriptor for BIFS, and SLConfigDescriptor information for media such as video and audio are mapped in SDP format by the SDP generator 220. The generated SDP is transmitted immediately or packetized and transmitted in FLUTE by the FLUTE packetizer 240. FLUTE is a standard for transmitting a file such as SDP in the Internet, and the FLUTE packetization is Request For Comments (RFC). Follow 3926.

The remaining information except the SLConfigDescriptor for A / V / OD / BIFS is RTP packetized. In this case, the RTP packetization format follows RFC 3640. BIFS information is RTP packetized, where the RTP packetization format follows RFC 3640. The video information is RTP packetized. At this time, the RTP packetization format follows RFC 3948. The audio information is RTP packetized. The RTP packetization format follows RFC 3640.

For reference, the Session Description Protocol (SDP) is an Internet Engineering Task Force (IETF) Multiparty Multi-media Session for the purpose of advertising the information needed by users to join a multimedia session on the Internet and defining the multimedia session in real time. Control) This is a protocol standardized by the Working Group. It is a protocol mainly used in the multicast backBone (MBone).

Here, a multimedia session consists of a multimedia sender, a receiver, and a data stream flowing from the sender to the receiver. Session Description refers to a well-defined format for conveying enough (capable of participating) information to participate in a multimedia session.

The SDP contains information about creating a session, inviting a session, and session description to define a multimedia session. The information includes an address and port for a media control server, a media type, and a media server address. SDP is described in the form <type> = <value>, and SDP with information about the session is advertised by other transport protocols. In particular, SDP can be used in a wide range because it can send various types of information together.

In addition, the Real-time Transport Protocol (RTP), unlike the Transmission Control Protocol (TCP) -based Hyper Text Transfer Protocol (HTTP) and FTP (File Transfer Protocol), which have strict timing requirements, is mainly used for real-time transmission of media streams. A protocol designed for this purpose, used by MBone and defined by IETF RFC1889.

RTP is delivered using UDP (User Datagram Protocol) and has a packet form. Here, UDP is a protocol that does not have a function of processing an error or recombining an order, but merely receives or throws data, and is mainly used for processing real-time multimedia information. Since TCP retransmits errors and aims to transmit complete data, TCP is not suitable for a real-time environment and UDP is used instead.

4 (a) defines a general structure of an effective payload format and shows the structure of an RTP packet.

RFC 3640 defines an RTP packet structure for carrying system streams such as MPEG-4 ES, for example MPEG-4 A / V, and BIFS, OD. As shown in Fig. 4A, the RTP packet is composed of an RTP header and an RTP packet effective load including an access unit (AU) header section, an auxiliary section, and an AU data section.

Here, AU (Access Unit) is a minimum unit that can be time stamped, and is pure data regarding audio, video, BIFS, and OD. One RTP packet may include a single fragment of one AU, or one or more AUs. The AU header section may include one or more AU headers or may be empty.

4 (b) shows the structure of the AU header section and the structure of each AU header included in the RTP packet. The AU header section includes AU_headers_length, n AU_headers, and padding bits, and each AU header includes AU_size, It consists of AU_Index / AU_Index_delta, CTS_flag, CTS_delta, DTS_flag, DTS_delta, RAP_flag, and Stream_state fields.

The AU header is created using the MIME format parameter, which may be empty. If the AU header is empty, there is no AU_headers_length field. AU_headers_length indicates the length in units of bits excluding padding bits. Padding bits are inserted such that the size of the AU header section is a multiple of 8 bits, and a maximum of 7 bits may be inserted.

The AU header is associated with one AU or a portion of the AU, contained within the AU data section in the RTP packet, with one AU header linked to one AU (or portion).

The AU_size field indicates the size of the associated AU in the AU data section in the same RTP packet. The AU_index field indicates the serial number of the associated AU (or part of the AU). AU_index_delta indicates a difference from the serial number of the preceding AU.

CTS_flag indicates the presence or absence of the CTS_delta field. The first AU header is 0 and the non-first AU header is 1. CTS_delta is a two's complement of an offset from the time stamp in the RTP header.

DTS_flag indicates the presence or absence of a DTS_delta field, and DTS_delta is two's complement of an offset from the CTS of the current AU. RAP_flag indicates whether the associated AU provides random access. Stream_state exists only when transmitting an MPEG-4 system stream, and does not exist when transmitting an MPEG-4 audio or video stream.

5 shows a mapping relationship between an SL packet header and an AU header of an RTP packet. Since the SL packet structure and the RTP packet structure defined in RFC 3640 are compatible with each other, FIG. 5 shows fields that can be connected to each other. The RTP packetizer 230 according to the present invention generates an RTP packet for OD, BIFS, audio, and video based on the information field connected to the AU header among the information in the SLConfigDescriptor. The AU-size field of the AU header is Since it has the same meaning as the accessUnitLength field of the SL packet header, the value can be used in the packetization process. In addition, the AU-Index / AU-Index-delta field of the AU header has a similar meaning to the AU-sequenceNumber field of the SL packet header, and the CTS-flag and CTS-delta fields of the AU header are the compositionTimeStampFlag and compositionTimeStamp fields of the SL packet header. The DTS-flag and DTS-delta fields of the AU header have the same or similar meanings as the decoding timeStampFlag and decodingTimeStamp fields of the SL packet header, respectively. The RAP-flag field of the AU header is the SL packet header. Since it has the same meaning as the randomAccessPointFlag field of, the value can be used in the packetization process.

FIG. 6 illustrates a mapping relationship between SLConfigDescriptor and SDP. FIG. 6 illustrates a mapping relationship between SLConfigDescriptor and SDP parameters for an RTP packet format defined in RFC 3640. The SDP generator 220 according to the present invention generates the SDP information by mapping the SLConfigDescriptor in the IOD and the OD information of the TDMB or inserting a field necessary for the TDMB service over the IP.

Since useRandomAccessPointFlag, durationFlag, AU_length, AU_seqNumLength, and accessUnitDuration of SLConfigDescriptor have the same meaning as randomAccessIndication, constantDuration, sizeLength, indexLength / indexDeltaLength, and constantSize of SDP, respectively, the SDP generator can use the value.

Here, the SizeLength is used to indicate how many bits the AU-size field is composed of and cannot exist together with the ConstantSize parameter. The indexLength / indexDeltaLength is used to indicate how many bits the AU-index and AU-Index-delta fields are composed of, respectively. The CTSDeltaLength / DTSDeltaLength is used to indicate how many bits the CTSDelta and DTSDeltaLength fields are configured, respectively.

In addition, the randomAccessIndication has a value of 0 or 1, and is used to indicate whether the RAP-flag field is used. The streamStateIndication is used to indicate how many bits the stream-state field is composed of. The streamStateIndication is not used to transmit audio or video when used for transmission of an MPEG-4 system stream. The constantDuration indicates whether each AU in the stream is transmitted at the same time interval. The constantSize is described in size when each AU in the stream is transmitted with the same byte size, and cannot be described with SizeLength.

7 illustrates an embodiment according to the present invention for a service for providing terrestrial digital multimedia broadcasting (TDMB) through IP.

The streaming server 300 is connected to the streaming server 300 by RTP packet for the SDP and OD / BIFS / Audio / Video generated by the TDMB-IP converter 200 through UDP / IP. Provided to multiple clients.

The n pieces of SDP information generated by the SDP generator 220 are provided to a plurality of clients connected to the streaming server 300 through a known UDP port. The SDP information includes service (program) name and information, number of services provided and service number (SDP number), connection address, UDP port number through which RTP packets are transmitted, and types of RTP packets transmitted through each UDP port (BIFS / OD / Audio / Video), structure information of the RTP packet, DecoderConfigDescriptor information (relative to BIFS / OD), and the like.

The SDP includes a session level description describing information such as a name of a session and an activation time of the session, and a media level description describing information such as a media name and a port.

Session-level description includes 'v = (protocol version)', 'o = (owner / creator and session identifier)', 's = (session name)', 'i = (session information)' , 'u = (URI of description)', 'e = (email address)', 'c = (connection information)', 'b = (bandwidth information)', 't = (time the session is active)', Fields such as 'a = (zero or more session attribute lines)' are included.

The media-level description begins with the field 'm = (media name and transport address)', where a field 'a = (zero or more media attribute lines)' is added to describe the media's attributes. Can be.

The SDP version is specified as <version> in the 'o = <username> <session id> <version> <network type> <address type> <address>' field, and the SDP id is specified as <session id>. In addition, the program name and program information appear in the 's =' and 'i =' fields of the SDP, respectively.

The connection address is represented by a 'c =' field, which includes a class-D IP address (224.0.0.0. ~ 239.255.255.255) if the session is multicast, otherwise the domain name (Domain name) or a unicast IP address.

The SDP generator 220 according to the present invention adds an attribute of 'a = sdpn' to specify the SDP number in the SDP, for example, in the case of 'a = sdpn: 1/3' Point to the first SDP.

Each media description starts with one 'm =' field and ends with the next 'm =' field (the description of the next media) or the end of the session description. The 'm =' field consists of 'm = <media> <port> / <number of ports> <transport> <fmt list>'.

Here, <media> refers to audio, video, application, data, control, etc., <port> / <number of ports> refers to a port through which a media stream is transmitted, and <transport> to RTP / AVP (UDP). RTP using the Audio / Video profile is recorded. In the future, other RTP profiles can be defined in the form of RTP / XYZ, and <fmt list> indicates the format of the effective load. For audio and video, RTP Audio / Video This is the media effective load defined in the profile (list of effective load types).

In the media level description, the 'a = rtpmap' field indicates an attribute of an effective load and is encoded in the order of: <payload type> <encoding name> / <clock rate>. In addition, the 'a = fmtp' field is used to transmit format-specific parameters. The fmpt is not interpreted at the SDP level and is used by defining a characteristic in a group using the media in relation to a specific media. To help.

As shown in FIG. 7, the fact that BIFS, OD, video, and audio are converted into RTP packets and transmitted through UDP ports 49228, 49230, 49232, and 49234, respectively, indicates that 'm =' and 'a = rtpmap:' of SDP. Transmitted through the field.

The SDP generator 220 according to the present invention uses information on the effective load of the RTP packet, for example, information on the AU header in the RTP packet (sizeLength, indexLength, indexDeltaLength, packetization_mode) using the SL packet structure information (SLConfigDescriptor). , streamtype, mode, etc.) are created in the 'a = fmtp:' field in the corresponding media level description in the SDP.

In addition, in the media level description of BIFS and OD, the SDP generator 220 generates an 'a = fmtp:' field including decoderConfigDescriptor information for BIFS and OD.

The decoderConfigDescriptor information includes information necessary for decoding data. In the TDMB service, the decoderConfigDescriptor information is transmitted through an IOD or an OD in the original TS PMT. DecoderConfigDescriptor information for BIFS and OD is transmitted through IOD, and decoderConfigDescriptor information for video and audio is transmitted through OD.

However, in the present invention, the decoderConfigDescriptor information is transmitted in SDP. Since the decoderConfigDescriptor information may be represented as a binary data string, a parameter such as 'decoderConfigDescriptor = XXXXXXX' is inserted into the 'a = fmtp:' field and transmitted. Here, 'XXXXXXX' is a temporary representation of the binary data string by the Base64 encoding method. The Base64 encoding method is an encoding method for converting binary data or ASCII data into 64 character strings. In SDP, this method is used to transmit a binary data string.

The media (audio and video data) streams and system streams (BIFS and OD data) in each service (program) are distinguished by the UDP port number defined in the SDP of each service, so no PID or ES_ID is required.

8 illustrates a process of accessing terrestrial digital multimedia broadcasting content transmitted through IP from a decoding point of view.

The client connected to the streaming server 300 in a wired or wireless manner acquires n pieces of SDP information from a known UDP port (step 1), and the SDP information of a desired service through the 'a = sdpn' field (the service in the SDP of FIG. 7). 1). The client obtains information related to reception of each information such as RTP header structure, port number for BIFS, OD, video, and audio from the SDP, and obtains DecoderConfigDescriptor information, which is information related to a decoding process, for BIFS and OD.

The client obtains the RTP packet structure information, the DecoderConfigDescriptor, the UDP port number, etc. using the SDP information of the BIFS and the OD. In the example of FIG. 7, the UDP port numbers of the BIFS and the OD are 49228 and 49230, respectively.

In addition, the client obtains a stream related to BIFS and OD from a corresponding UDP port (step 2), and obtains DecoderConfigDescriptor information and SLConfigDescriptor information related to audio and video from the received OD stream (step 3).

In addition, the client obtains the RTP packet structure information, DecoderConfigDescriptor, UDP port number, etc. by using the SDP information of the audio and video. In the example of FIG. 7, the UDP port numbers of the video and audio are 49232 and 49234, respectively. Thereafter, the client acquires and decodes RTP packets of video and audio through the corresponding UDP port (step 4).

On the other hand, when converting a TDMB stream for transmission over IP, i) with and without SL (SyncLayer) header in the RTP effective load, ii) only video and audio streams without BIFS, OD information are available. Iii) in case of a live service such as VOD (method of transmitting SDP to RTSP), iv) in the absence of SL header (method of transmitting PCR / OCR information). Should be.

First, the consideration of inserting the SL header into the RTP effective load portion.

In consideration of the receiver based on the MPEG-4 system standard, the TDMB-IP converter 200 according to the present invention has a function of inserting an SL header into the RTP effective load portion. Four cases are considered to describe the characteristics of when the SL header is inserted into and not inserted into the RTP effective load portion.

FIG. 9A illustrates a case in which only one AU is included in an RTP packet and an SL header is inserted.

Since the AU header is not included in the RTP packet, the TDMB-IP converter 200 inserts a parameter such as 'SLConfigDescriptor = XXXXXXX' into the attribute field when linking the SLConfigDescriptor information in the IOD and the OD to the SDP. shall. In addition, since there is no AU header in the RTP packet, parameters such as AU_size and AU_index do not appear in the attribute field (a = fmtp :) of the SDP.

FIG. 9B illustrates a case in which only one AU is included in the RTP packet and the SL header is not inserted.

Since the AU header and the SL header are not included in the RTP packet, the TDMB-IP converter 200 discards the SLConfigDescriptor information in the IOD and the OD, and AU_size in the attribute field (a = fmtp :) of the SDP as in the previous case. , Parameters such as AU_index do not appear.

FIG. 9 (c) illustrates a case where several AUs are included in an RTP packet and an SL header is inserted.

Since the AU header is included in the RTP packet, the TDMB-IP converter 200 should generate configuration information of the AU header when connecting the SLConfigDescriptor information in the IOD and the OD to the SDP. A parameter such as configuration information 'SLConfigDescriptor = XXXXXXX' should be inserted into the attribute field. Consider whether or not to duplicate the configuration information of the AU header. However, duplicate use is also possible.

FIG. 9 (d) shows a case where several AUs are included in an RTP packet and no SL header is inserted.

Since the Sync-header is not included in the RTP packet, the TDMB-IP converter 200 maps the IOD and SLConfigDescriptor information in the OD to the AU header configuration information when connecting to the SDP.

Next, this case is illustrated in FIG. 10 as a consideration for the case where only the video stream and the audio stream are transmitted to the RTP without the BIFS and OD information.

In this case, since OD and BIFS information are not transmitted, the related descriptor is not described in the SDP. In addition, DecoderConfigDescriptor information in the IOD is discarded, and DecoderConfigDescriptor information in the OD is inserted into an attribute field (a = fmtp :) included in the media level description of audio and video in the SDP.

Next, look at the case of a live broadcast service, such as VOD.

11 illustrates a session connection process using RTSP when transmitting content in consideration of a live service such as VOD.

The SDP is transmitted from the server to the terminal in step A. At this time, the SDP of the requested service may be transmitted in the DESCRIBE request step sent from the terminal, or all SDPs may be transmitted without a request for a special service from the terminal.

In addition, in step B, if there is a service specifically requested by the terminal, data (BIFS, OD, video, audio) for the corresponding service may be transmitted, or all data may be transmitted even if there is no request for a special service from the terminal.

Here, RTSP (Real-Time Streaming Protocol) is an application protocol standardized by extending the framework of HTTP to effectively transmit and control multimedia streams having real-time characteristics in a client / server environment in the IETF MMUSIC WG. It is used to execute and control stored information from VOD (Video On Demand) server, audio server, multimedia server, etc. RTSP is designed to control continuous media (audio and video) that is synchronized in time, and is not intended to carry a continuous stream on its own, but to allow stream control only. It is to utilize.

Finally, look at the case where there is no SL header.

If the SL header does not exist in the RTP effective load, OCR (Object Clock Reference) information transmitted for synchronization between packets is discarded. If the OCR information is to be transmitted or the receiver wants to receive it, the TDMB-IP converter 200 inserts the difference between the TimeStamp value and the OCR value of the RTP packet header into the CTS-delta of the AU header and transmits the difference. 12 is shown.

Since the RTP packet to which the OCR value is transmitted has no effective load, it can be seen that the receiving end transmits the OCR value to an RTP packet having an RTP effective load size of zero. The transmission period of the RTP packet for transmitting the OCR value is based on the TDMB standard, and the OCR value at the receiving end may be calculated as OCR = TimeStamp + OCR-delta.

Preferred embodiments of the present invention described above have been disclosed for the purpose of illustration, and those skilled in the art will improve, change, and substitute various other embodiments within the technical spirit and the technical scope of the present invention disclosed in the appended claims below. Or addition may be possible.

According to the embodiment of the present invention as described above, it is possible to convert the transmission standard of terrestrial digital multimedia broadcasting to the transmission standard in IP, to provide DMB content through the Internet, and to provide DMB content through wired and wireless Internet. It is possible to watch and provide high quality multimedia contents to wireless Internet services such as Wibro.

Claims (36)

delete delete delete delete delete delete delete delete delete delete Decoding a received digital broadcast signal Generating SDP information based on structure information on media data extracted from the decoded broadcast data and first information related to first data describing the media data; And extracting the media data and the first data from the decoded broadcast data and generating an RTP packet based on the extracted data. Here, the video service of the digital broadcast transmits the contents of the MPEG-4 standard through the MPEG-2 TS, The SDP information is generated as many as the number corresponding to the number of broadcast services provided, and each SDP information includes the number of broadcast services provided and the corresponding service number. How to convert. delete delete The method of claim 11, The number (n) and the service number (i) of the broadcast service are defined in the 'a = sdpn: i / n' field in the SDP information. The method of claim 11, And the version and the identifier of the SDP information are defined by the version and session_id parameters of the 'o' field in the SDP information. The method of claim 11, The media data includes audio data and / or video data, the first data includes OD data and BIFS data, the structure information includes Sync Layer structure information for the media data, and the first information. The method for converting the digital broadcast to the IP transmission form, characterized in that it includes decoding information for the OD and BIFS, Sync Layer structure information and IOD information. The method of claim 16, In the SDP information, the description of the RTP packet of the BIFS, OD, video, and audio data are distinguished from each other by the 'm' field. The method of claim 17, Ports through which the RTP packets of the BIFS, OD, video, and audio data are transmitted are defined with different values in the 'a = rtpmap:' field located under the 'm' field. How to convert to IP transmission form. The method of claim 17, Sync Layer structure information for BIFS, OD, video, and audio data included in the RTP packet is defined by the 'a = fmtp:' field located under the 'm' field. How to convert to transmission form. The method of claim 17, The decoding information for the BIFS and OD data included in the RTP packet is defined by the 'a = fmtp:' field located under the 'm' field. The method of claim 20, And the decoding information is defined as a value encoded by a Base64 method to a predetermined parameter in the 'a = fmtp:' field. The method of claim 16, The generating of the RTP packet may further include inserting Sync Layer structure information of data included in the packet into the RTP packet including the video or audio data. How to convert to transmission form. The method of claim 22, The generating of the SDP information may include encoding a Sync Layer structure information of the BIFS, OD, video, or audio data by a Base64 method in a 'a = fmtp:' field located under a corresponding 'm' field. The method of claim 1, further comprising the step of inserting into a parameter. The method of claim 16, The generating of the SDP information may include: when an Access Unit (AU) header is inserted into an RTP packet including the BIFS, OD, video, or audio data, a sync layer for the BIFS, OD, video, or audio data. And generating structure information of the inserted AU header on the basis of the structure information. The method of claim 16, When the Sync Layer structure information for the data is not inserted into the RTP packet including the BIFS, OD, video, or audio data, the SDP information does not include the Sync Layer structure information for the data. How to convert digital broadcast into IP transmission form. The method of claim 16, When the RTP packet for the BIFS and the OD data is not transmitted, the SDP information does not include the decoding information for the OD and the BIFS and the Sync Layer structure information. . The method of claim 26, The Sync Layer structure information of the audio and video data included in the OD data is encoded by the Base64 method and inserted into a predetermined parameter in the 'a = fmtp:' field located under the 'm' field. A method of converting a digital broadcast into an IP transmission form. The method of claim 16, The generating of the RTP packet may include: when the Sync Layer structure information for the data is not inserted into the RTP packet including the BIFS, OD, video, or audio data, the time stamp value and the OCR value of the corresponding RTP packet And inserting the difference into the AU header. The method of claim 28, And the difference is defined in a CTS-delta field of an AU header. The method of claim 28, The generating of the RTP packet further comprises inserting the OCR information at the head of an effective load in the RTP packet according to the second information. . delete delete delete delete delete delete

Images