KR20100081714A - A method for processing a digital broadcasting signal and an apparatus thereof - Google Patents

Abstract

PURPOSE: A method for processing a digital broadcasting signal and a device thereof are provided to more rapidly process configuration information of media stream respectively comprising transmitted service. CONSTITUTION: A EPG(Electronic Program Guide) manager(1316) comprises an EPG screen according to control of common metadata handler. A UI(User Interface) manager(1317) receives an input of a user and transmits the input. A service manager(1312) controls service connection which is being handled by controlling the EPG manager and the common metadata handler. A control unit processes a session for providing a service according to a service manager. A decoding unit decodes each media stream within received session according to control of the control unit.

Description

Method and processing a digital broadcasting signal and an apparatus

The present invention relates to a method and apparatus for processing a digital broadcast signal, and more particularly, to transmission and reception of session information for processing a digital broadcast signal including a service.

The services provided according to the needs of users are increasingly complicated and diversified. Data for such a service is included in a digital broadcast signal and transmitted according to various schemes at the transmitter side, and the receiver receives the digital broadcast signal transmitted corresponding to each scheme and provides data for the service to the user.

In addition, digital broadcast signals including data for service are transmitted and received by various media. In recent years, however, IP media have been in the spotlight.

In this regard, in order to finally extract and provide data for a service requested by a user from a received digital broadcasting signal, various reception information for the receiving side is required. However, there is a problem in that signaling information necessary for providing a service is transmitted separately from the corresponding service at the receiving side, which causes overhead in starting the service.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and an object of the present invention is to define signaling information regarding data for a service included in a digital broadcast signal transmitted and received through various media, which is common to the various media. We want to define signaling information in applicable binary format.

Another object of the present invention is to define signaling information in XML metadata format.

Another object of the present invention is to provide a method and apparatus for processing a digital broadcast signal including data for a service and signaling information thereof.

Another object of the present invention is to process data for a service more efficiently based on the signaling information defined above.

Hereinafter, in order to achieve the above object, an embodiment of a digital broadcast signal processing method according to the present invention comprises the steps of: receiving a digital broadcast signal; Extracting a session description descriptor (SDD) including description information for signaling a session including at least one media component from the received digital broadcast signal; Parsing session general information from the extracted session description descriptor (SDD) including general parameters that apply to the entire session; Parsing information from the parsed session general information about a media type providing detailed information of each media component constituting the session; Parsing information about a protocol through which each media component is transmitted from information about the type of the parsed media component; Parsing description information including parameters used for decoding each media component based on the information about the parsed media type and the information about the protocol; And accessing and consuming a service by decoding respective media components based on the parsed description information.

In this case, the method may further include parsing information for identifying a type of a codec of each media component based on the information about the parsed media type.

The session description descriptor may be included in at least one of a service description table and an IP / MAC notification table among a plurality of tables included in the received digital broadcast signal.

The session general information may include identifier information for identifying a corresponding session, version information of the corresponding session, information defining an address type of the corresponding session, and whether a connection exists at a session level. At least one of a flag indicating the information, information defining a connection address applicable to a component of the entire session according to the flag value, and at least one of detailed information about each media stream. Can be.

The information defining the connection address applicable to the component of the entire session according to the flag value includes information on the number of IP streams transmitted through the session and a target IP of interest. It may include at least one of the information of the address.

In addition, the media type may include at least one of audio and video.

The protocol information may include at least one of information for identifying a target port number to which the corresponding component is transmitted and information for identifying a type of an RTP payload.

In addition, each media stream may be transmitted as an elementary stream.

Another embodiment of a method for processing a digital broadcast signal according to the present invention comprises the steps of: receiving a digital broadcast signal; Extracting a delivery session general parameter element including description information for signaling a session including at least one media component from the received digital broadcast signal, wherein the extracted delivery session element is A session general parameter element containing general parameters that apply to the entire session, an IP address source element indicating a session level IP address, and each media component composing the session. Including a media element containing information; Extracting and parsing a session general parameter element from the extracted delivery session element; Extracting and parsing an IP address source element and a media element based on the parsed delivery session element; And accessing and consuming a service by decoding a session including a corresponding media component based on each parsed element.

The session general parameter element includes an element for providing domain information of a service provider providing the session, an element including an identifier for identifying the session, an element for defining version information of the session description, and content. It may include at least one or more of the elements defining a specific format of the item.

In addition, an element defining a specific format of the content item may indicate that the specific format of the content item is an elementary stream.

The media element may include an attribute defining a media level IP address, an attribute indicating a media level port number, an attribute indicating the number of ports, an attribute defining a maximum required bandwidth of the media stream, and a corresponding media type. Properties that include at least one or more of a preferred property that defines a preferred media stream, a media property element that defines the format of each media component, and a media property element that defines the detailed properties of the media component. It may include at least one of.

In addition, the media format element may include attributes including at least one of a media type attribute defining a media type of a corresponding media component, a transport protocol attribute defining a protocol through which the session is transmitted, and a protocol to which the session is transmitted. It may include at least one of the media format description element defining the corresponding detailed media format description.

One example of a digital broadcast receiver according to the present invention includes a tuner unit configured to receive a digital broadcast signal by tuning a channel; A demultiplexer for demultiplexing a session including each media stream from the received digital broadcast signal and common metadata including information about the session; A parser for parsing the demultiplexed session and common metadata; A common metadata handler unit for controlling a service manager using the parsed common metadata; An EPG manager unit configured to configure an EPG screen according to the control of the common metadata handler unit; A UI manager unit for receiving and transmitting a user input; A service manager unit controlling service access under the control of the EPG manager unit and the common metadata handle unit; A control unit controlling to process a session to provide a service under control of the service manager unit; And a decoder to decode each media stream in the received session under the control of the controller.

At this time, the channel database unit for storing the channel map associated with the service provided under the control of the service manager; It may further include a metadata storage for storing the common metadata parsed by the parser.

The apparatus may further include a display unit configured to receive and display each media stream decoded by the decoder unit.

One example of an IPTV receiver according to the present invention includes an IP interface unit for receiving and receiving an IP signal; A demultiplexer for demultiplexing a session including each media stream from the received IP signal and common metadata including information about the session; A parser for parsing the demultiplexed session and common metadata; A common metadata handler unit for controlling a service manager using the parsed common metadata; An EPG manager unit configured to configure an EPG screen according to the control of the common metadata handler unit; A UI manager unit for receiving and transmitting a user input; A service manager unit controlling service access under the control of the EPG manager unit and the common metadata handle unit; A control unit controlling to process a session to provide a service under control of the service manager unit; And a decoder to decode each media stream in the received session under the control of the controller.

Thus, according to the present invention,

First, there is an effect that can process the configuration information of the media stream constituting each service to be transmitted more quickly.

Second, there is an effect that can reduce the service providing time.

Third, there is an effect that can increase the efficiency of the system by the fast reception and processing of session description information.

Other objects, features and advantages of the present invention will become apparent from the following detailed description of embodiments with reference to the accompanying drawings. In addition, the terminology used in the present invention was selected as a general term widely used as possible now. However, in certain cases, the applicant arbitrarily selected a term, and in this case, the meaning is described in detail in the corresponding part. Therefore, the terms used in the present invention should be understood as meanings of the terms rather than simply names of the terms.

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

In the context of the present invention, digital broadcast signals are transmitted and received between the transmitting side and the receiving side in various ways. The various schemes include, for example, DVB-H, DVB-C / S / T, and IPTV schemes based on IP (internet protocol). Here, the digital broadcast signal includes service data for providing a service and signaling information thereof.

Hereinafter, for convenience of description, the service data will be described using a media stream as an example, and the media stream is also called an event. Here, the service data, that is, the media stream may be transmitted and received as at least one elementary stream (ES). At this time, each elementary stream (ES) is also called a session (session). In addition, signaling information of the media stream is hereinafter described as session description information for convenience of description. However, the technical spirit of the present invention is not limited to the above-mentioned name to be clear in advance.

First Embodiment

1 is a structural diagram illustrating a structure for receiving a service in digital video broadcasting of a mobile environment according to the present invention.

Relatedly, in digital video broadcasting (DVB-H) in a mobile environment, all media streams are encapsulated with an IP layer on an MPEG-2 transport stream (TS). To the elementary stream (ES).

Referring to FIG. 1, session description information, which is signaling information, is included in an SDP file, and the SDP file is accessible by Acquisition Fragments. The acquisition fragment is linked to the service fragment itself or to each scheduled event fragment (Schedule Event 1 to 4) included in the service fragment to access the corresponding SDP file. In FIG. 1, a French audio stream, an English audio stream, and a video stream are illustrated for each event. The session description information for each event is transmitted through a separate stream SDP stream.

In addition, in digital video broadcasting (DVB-H) in a mobile environment, an electronic service guide (ESG) based on TV anytime for service information and announcements. I adopt it. Therefore, the digital broadcast receiver preferentially receives and processes the electronic service guide (ESG) and provides the processed guide information so that a user can select a service.

Accordingly, when the user receives a request for service selection through the provided electronic service guide (ESG), the digital broadcast receiver includes at least one acquisition fragment in the electronic service guide (ESG) as shown in FIG. 1. It has a structure of receiving an SDP file including session description information of a corresponding service through acquisition fragments and receiving the service based on the SDP file. The structure transmits the session description information in a stream separate from the electronic service guide (ESG). Therefore, the transmitting side needs a separate FLUTE stream transmitting end for transmitting session description information necessary for providing a service, and the digital broadcast receiver is required for receiving session description information transmitted in the separate stream. Must have an element Therefore, in order to execute a specific service selected by a user, the digital broadcast receiver has to receive and process an SDP stream including session description information necessary for receiving the specific service. There may be a problem.

FIG. 2 is a structural diagram illustrating a layer 1 signaling structure required for receiving a service in terrestrial digital video broadcasting (DVB-T2) according to the present invention, and FIG. 3 is a terrestrial digital of FIG. It is a structural diagram shown for demonstrating the frame structure of video broadcasting.

Referring to FIG. 2, a T2 frame includes P1, P2 and at least one data symbol. The P1 includes P1 signaling indicating a transmission type and basic transmission parameters, and P2 enables reception and decoding of L1 post-signalling. L1 pre-signalling and L1 post-signalling that transmits parameters that can access physical layer pipes (PLP). The L1 post-signaling includes Configurable, Dynamic, Extension, Cyclic Redundancy Check (CRC), and L1 Padding. Accordingly, the transmitting side may transmit an MPEG-2 Transport Stream (MPEG-2 TS) or a Generic Substation Events (GSE) stream through the physical layer pipe (PLP).

Referring to FIG. 3, a frame structure for full terrestrial digital video broadcasting includes P1, L1 signaling, L1 signaling, common physical layer pipes (Common PLPs), and type 1 data physical layer pipes (data PLPs, type). 1), data physical layer pipes (type PLPs, type 2) and auxiliary streams (auxiliary streams) of the type 2 format, including dummy cells (dummy cells).

Hereinafter, a method of transmitting and receiving session information applicable to the above-described system according to the present invention will be described. Here, in the present specification, two methods are described as examples for convenience of description in transmitting and receiving session description information. The first method is a method of transmitting and receiving the session description information in a binary form according to an embodiment of the present invention, and the second method is an XML (eXtensible Markup Language) form according to another embodiment of the present invention. How to send and receive

First, a method of transmitting and receiving session description information in binary form will be described according to an embodiment of the present invention.

In the case of terrestrial digital video broadcasting (DVB-T2), it has a frame structure as shown in FIG. Here, data corresponding to the actual broadcast content are transmitted through physical layer pipes (PLPs). In this case, the common physical layer pipe (Common PLP) among the physical layer pipes is a region including data common to all the physical layer pipes (PLP) can be used for signaling purposes. For example, the common physical layer pipe may include a service description table (SDT) among a plurality of tables in the service information of the digital video broadcast as shown in FIG. 4. Here, the service description table SDT includes at least one service loop, and each service loop includes a descriptor loop. In the present specification, for convenience of description, session description information in binary form according to the present invention is described as being included in the descriptor loop. In addition, the descriptor including the session description information is called a session description descriptor (SDD), but is not limited to the above name.

Therefore, according to the present invention, the session description information, which is the configuration information of the media stream constituting each service transmitted through the physical layer pipe (PLP), is a session description descriptor (SDD) in the common physical layer pipe (Common PLP) at the transmitting and receiving side. ) Enables fast delivery and processing. That is, since the session description information is transmitted in the signaling stage, which is earlier than the case in which it is delivered as an IP packet on a transport stream (TS) or a GSE stream in the physical layer pipe (PLP), the digital broadcast receiver can quickly access a service. Can be. From the point of view of the receiver, for example, the service access time is shortened by processing at the front end of the demodulation part or demultipling part, rather than processing at the IP layer stage in the receiver structure to be described later. It is effective to let.

In the case of digital video broadcasting (DVB-H) in a mobile environment, the service is received by searching for an SDP file in the electronic service guide (ESG) in the form of FIG. 1 described above. In the digital video broadcasting (DVB-H) of the mobile environment, as described above, the session description descriptor (SDD) for each service may be signaled by including in the service description table (SDT). Here, the session description descriptor (SDD) may be included in one of the descriptors of the IP (IP / MAC Notification Table) and used for signaling.

As described above, the session description information may be signaled for each service by including the session description descriptor SDD in the service description table SDT. Therefore, according to the present invention, there is no need to receive and store an SDP file transmitted through a separate FLUTE stream on an IP layer in digital video broadcasting (DVB-H) in a conventional mobile environment. As a result, according to the present invention, by transmitting and receiving session information in a binary form of service information on a transport stream layer (TS layer), it is possible to increase efficiency by reducing service access time and thereby increasing service usage.

Here, if the session description information is added on the INT, it can be considered to transfer the session information for all services delivered by each IP platform (platform). Therefore, the session information specified on the electronic service guide (ESG) can be found and used on the session information delivered through INT. This also has the effect of reducing the service access time compared to the conventional method.

The above-described examples illustrate that processing at a signaling decoder stage rather than an IP layer stage in a receiver structure is possible, which is described as an effect of enabling fast service access.

Hereinafter, a case in which the session description descriptor SDD including the session description information is included in the service description table SDT according to an embodiment of the present invention will be described in detail. However, the case in which the session description information is included in the INT will not be described or described separately herein, but it will be apparent that the same may be applied in the following manner.

4 is a service description table including a service description descriptor (SDD) according to an embodiment of the present invention. This is a structural diagram shown to explain the structure of a section. For example, the service description table section is included in the service information (DVB-SI) of digital video broadcasting.

Hereinafter, each field constituting the service description table section will be described. For convenience of description, the name of each field is used as it is in English.

The table_id field indicates an identifier for identifying the table.

The section_syntax_indicator field is set to "1" (The section_syntax_indicator is a 1-bit field which shall be set to "1").

In the section_length field, the first two bits are "00", and "00" describes the number of bytes of the field including the CRC_32 field immediately starting from the section_length field. The section_length field is 1024 bytes, which is the maximum length of the entire section, so it will not exceed 1021 bytes (This is a 12-bit field, the first two bits of which shall be "00". It specifies the number of bytes of the section, starting immediately following the section_length field and including the CRC.The section_length shall not exceed 1021 so that the entire section has a maximum length of 1 024 bytes).

The transport_stream_id field provides a label for identifying a transport stream (TS) for service description table (SDT) information from any other multiplex in the transport system (This is a 16-bit field which serves as a label). for identification of the TS, about which the SDT informs, from any other multiplex within the delivery system).

The version_number field defines the version number of the sub_table. The version number is incremented by one if any change occurs in the transmitted sub_table. When the value reaches "31", it wraps around to "0". If the current_next_indicator is set to "1", it means that the version_number field is applicable to the current sub_table. If the current_next_indicator is set to "0", this means that the version_number field is applicable to the next sub_table. (This 5-bit field is the version number of the sub_table.The version_number shall be incremented by 1 when a change in the information carried within the sub_table occurs.When it reaches value "31", it wraps around to "0" .When the current_next_indicator is set to "1", then the version_number shall be that of the currently applicable sub_table.When the current_next_indicator is set to " 0 ", then the version_number shall be that of the next applicable sub_table).

The current_next_indicator field means that if the indicator indicates “1”, the sub_table is currently applicable. This 1-bit indicator, when set to "1" indicates that the sub_table is the currently applicable sub_table.When the indicates that the sent sub_table is not yet applicable, it is valid for the next sub_table. bit is set to "0", it indicates that the sub_table sent is not yet applicable and shall be the next sub_table to be valid).

A section_number field (8 bits) gives the number of the section. The value of section_number of the first section will be “0x00”. section_number will be incremented by 1 for each additional section with the values of the same table_id field, transport_stream_id field and original_network_id field (This 8-bit field gives the number of the section.The section_number of the first section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each additional section with the same table_id, transport_stream_id, and original_network_id).

This 8-bit field specifies the number of the last section (that is, the section), as the part of the sub_table describes the number of the last section (that is, the largest section number of the last section). with the highest section_number) of the sub_table of which this section is part).

The original_network_id field provides a label for identifying the network_id of the original delivery system (This 16-bit field gives the label identifying the network_id of the originating delivery system).

The service_id field provides a label for identifying the service from any other service in the transport stream (TS). (This is a 16-bit field which serves as a label to identify this service from any other service within the TS.The service_id is the same as the program_number in the corresponding program_map_section).

The EIT_schedule_flag field indicates that EIT schedule information for a service currently exists in a transport stream (TS) when the corresponding field value is set to '1'. If this field value is set to '0', this indicates that the EIT schedule information for the service does not exist in the current transport stream (TS) (This is a 1-bit field which when set to "1" indicates that EIT schedule information for the service is present in the current TS, see TR 101 211 [7] for information on maximum time interval between occurrences of an EIT schedule sub_table.If the flag is set to 0 then the EIT schedule information for the service should not be present in the TS).

The EIT_present_following_flag field indicates that EIT present / following information for a service exists in the current transport stream TS when the corresponding field value is set to '1'. If this field value is set to '0', this indicates that the EIT present / following information for the service does not exist in the current transport stream (TS) (This is a 1-bit field which when set to "1" indicates that EIT_present_following information for the service is present in the current TS, see TR 101 211 [7] for information on maximum time interval between occurrences of an EIT present / following sub_table). If the flag is set to 0 then the EIT present / following information for the service should not be present in the TS).

The running_status field indicates the state of a service. This is a 3-bit field indicating the status of the service as defined in table 6. For an NVOD reference service the value of the running_status shall be set to "0").

The free_CA_mode field indicates whether to scramble all component streams of a service. If the field value is set to '0', it indicates that all component streams of the service are not scrambled, and if the field value is '1', it is vice versa. when set to "0" indicates that all the component streams of the service are not scrambled.When set to "1" it indicates that access to one or more streams may be controlled by a CA system).

The descriptors_loop_length field provides the total length of bytes of the following descriptors (This 12-bit field gives the total length in bytes of the following descriptors).

The CRC_32 field contains a CRC value. The CRC value is the 32-bit field that contains the CRC value that gives a zero output of the registers in the decoder defined in annex B after processing the entire section).

5 illustrates a bitstream syntax of a session description descriptor (SDD) constructed according to an embodiment of the present invention. Here, the session description descriptor (SDD) is written in the form of MPEG-2 descriptor for convenience of description, but it is not necessarily written in the form of MPEG-2 descriptor and may be written in another form.

Referring to FIG. 5, as can be seen in the illustrated bitstream syntax, a session description descriptor (SDD) is common to general information about a session and media streams belonging thereto for each service. Description information such as parameters that can be applied as well as detailed information on each media stream are provided.

The descriptor_tag field is used to identify the descriptor.

The descriptor_length field represents the length of the descriptor.

The Session_ID field includes a unique identifier for identifying a session in association with a session description to be provided by a corresponding descriptor (unique identifier for the session).

The Session_Version field contains a version number of the session description (a version number for this session description).

The Address_type field includes an indicator indicating an address type. For example, the indicator included in the field may indicate whether the corresponding IP address is an IPv4 address or an IPv6 address.

The Session_level_connection_flag field includes a flag indicating whether a connection of a session level exists. For example, when the flag is Yes, the connection address applicable to the component of the whole session may be signaled through the Target_ip_address field and the Address_count field. That is, the Address_count field represents the number of IP streams transmitted through the session. For example, the address of each IP stream may have a value increased by one from the last bit from the Target_IP_address field given in the descriptor. The Target_IP_address field includes a target IP address targeted by the descriptor. For example, the target IP address includes an IP address of the service or a representative IP address of the session.

The Media_info_length field represents the length of the Media_info_byte field including detailed information about each media stream.

The Media_info_bytes field contains detailed information of each media stream.

A session constituting one content may consist of a plurality of media streams. It is conceivable for various combinations between multiple audio / video and other various types of media streams. Information about the various media streams may be carried in one Media_info_bytes structure, and a plurality of Media_info_bytes structures may be stored in the media_info loop of the session description descriptor SDD as many as the number of media streams.

6 illustrates bitstream syntax of a media_info_bytes field configured according to an embodiment of the present invention. Here, although the bitstream syntax of the media_info_bytes field according to the present invention is also written in the form of MPEG-2 descriptor, it is not necessarily written in the form of MPEG-2 descriptor.

Referring to FIG. 6, the bitstream syntax of the media_info_bytes field provides IP connection information and description information for each stream component for each service. For example, the bitstream syntax of the media_info_bytes field may be content of one elementary stream (ES). Hereinafter, each field constituting the media_info_bytes field will be described.

The Media_Type field includes information for identifying a media type of a corresponding component. For example, the media type may be audio, video, or the like.

The Preferred field contains information indicating whether the media stream is a preferred stream among media streams of the same media type. For example, if the value of the field is '1', it may indicate that the stream is a stream to be preferentially selected among a plurality of streams of the same media type.

The Address_type field includes an indicator indicating the address type of the corresponding component. For example, the address type may indicate whether the corresponding IP address is an IPv4 address or an IPv6 address.

The Target_Port_Num field includes information for identifying a target port number to which a corresponding component is transmitted. For example, the target port number may indicate a user datagram protocol (UDP) port number of an IP stream through which the corresponding component is transmitted.

The Port_Count field represents the number of port numbers transmitted through the session. The UDP port number of each IP stream may have a value increased by one from the last bit from the Target_Port_Num field given in the descriptor.

The Codec_Type field includes information for identifying a codec type of a corresponding component. For example, the codec type may include H.264, HE-AAC, and the like.

The Component_connection_flag field includes a flag indicating whether a connection of a corresponding component is present. For example, if the flag value is yes, the connection address through which the corresponding component is transmitted may be signaled through a Target_ip_address field and an Address_count field.

The Address_count field includes information indicating the number of IP streams transmitted through the session. For example, the address of each IP stream according to the number may have a value increased by one from the last bit from the Target_IP_address field given in the descriptor.

The Target_IP_address field contains a target IP address. For example, the target IP address may include an IP address of a corresponding service or a representative IP address of a corresponding session.

The MPEG-4_ES_ID field contains an identifier for identifying an MPEG-4 elementary stream (ES) of a corresponding component.

The attribute_length field includes information indicating the length of an attribute_byte field containing attribute information about each media stream.

The attribute_bytes field contains attribute information of each media stream.

The value of the attribute_bytes field of each of the above-described media streams may have various combinations of descriptions according to the media stream. 7 to 10 illustrate bitstream syntax of attribute information that may be included in the attribute_bytes field of FIG. 6 according to an embodiment of the present invention.

Referring to FIGS. 7 to 10, as attribute information that may be included in the attribute_bytes field, an AVC Video Description Bytes descriptor, an MPEG-4 Audio Description Bytes descriptor, and a Hiraki description byte (Hierarchy Description Bytes) descriptor and SVC Extension Description Bytes descriptor are demonstrated as an example. However, the present invention is not limited thereto. In addition, the name of each field of FIGS. 7 to 10 to be described later uses the English name as it is for convenience.

Each data model may include parameters that may be used when decoding audio components, video components, and the like. In addition, the description of each descriptor may be distinguished by the description_tag field, and the value of the description_tag field of the description bytes according to an embodiment of the present invention is illustrated and illustrated in each figure. However, this is illustrated for convenience of description, and the present invention is not limited thereto.

FIG. 7 is a bitstream syntax illustrated to describe AVC Video Description Bytes configured according to an embodiment of the present invention.

The descriptor_tag field is used to identify the descriptor.

The profile_idc, constraint_set0_flag, constraint_set1_flag, constrant_set2_flag, AVC_compatible_flags, and level_idc fields, except for the AVC_compatible_flags field, are the ITU-T Rec. H.264 | It will be coded according to the semantics of the corresponding fields as defined in ISO / IEC 14496-10 [11]. The semantics of the AVC_compatible_flags field are ITU-T Rec. H.264 | It exactly matches the semantics defined by 5 bits between the constraint_set2_flag and level_idc fields in the sequence parameter set defined in ISO / IEC 14496-10 [11]. The entire AVC video stream associated with MH_component_type_data () shall be coded according to the semantics for these fields defined in ITU- T Rec. H.264 | ISO / IEC 14496-10 [11] .The semantics of AVC_compatible_flags are exactly equal to the semantics of the field (s) defined for the 5 bits between the constraint_set2_flag and the level_idc field in the Sequence Parameter Set , as defined in ITU-T Rec.H.264 | ISO / IEC 14496-10 [11] .The entire AVC video stream to which the MH_component_type_data () is associated shall conform to the profile, level and constraints signaled by these fields) .

An AVC_still_present field (1 bit) indicates whether AVC still pictures exist in the AVC video stream. If this field value is set to '1', the AVC video stream will contain AVC still pictures and if it is set to '0' this will not. stream may include AVC still pictures.When set to '0', then the associated AVC video stream shall not contain AVC still pictures).

FIG. 8 is a bitstream syntax illustrated to explain MPEG-4 Audio Description Bytes configured according to an embodiment of the present invention.

The descriptor_tag field is used to identify the descriptor.

The MPEG-4_audio_profile_and_level field (8 bits) identifies a decimal representation of the MPEG-4 profile level indication. An 8-bit unsigned integer field that shall identify a decimal representation of the MPEG-4 Profile Level indication.This parameter shall be used to indicate the MPEG-4 Profile and Level combination of which the relevant MPEG-4 media codec is capable.The MPEG-4 Audio Profiles and Levels are listed in Table 1.12 of ISO / IEC 14496-3 and ISO / IEC 14496 -3 with Corrigendum No. 2 [15]).

FIG. 9 is a bitstream syntax illustrated to explain Hierarchy Description Bytes configured according to an embodiment of the present invention.

The descriptor_tag field is used to identify the descriptor.

The temporal_scalability_flag field is a flag indicating that the type of the scalable media stream is temporal. The spatial_scalability_flag field is a flag indicating that the type of the scalable media stream is spatial. The quality_scalability_flag field is a flag indicating that the type of the scalable media stream is quality. For example, only one flag field may be valid according to the scalable type of the media stream.

The hierarchical relation between the associated hierarchy layer and its hierarchy embedded layer is defined by the following table 2-45 on page 62 below.

The hierarchy_layer_index field defines a unique index of the associated elementary stream (ES) in the table of coding layer hierarchies. The indexes may be unique indexes within a single program definition. (The hierarchy_layer_index is a 6 bit field that defines a unique index of the associated elementary stream in a table of coding layer hierarchies.Indices shall be unique within a single program definition) .

The hierarchy_embedded_layer_index field defines the high key table index of the elementary stream (ES) required to be accessed before decoding of the elementary stream associated with the hierarchy_descriptor. The hierarchy_embedded_layer_index is a 6 bit field that defines the hierarchy table index of the elementary stream that needs to be accessed before decoding of the elementary stream associated with this hierarchy_descriptor.This field is undefined if the hierarchy_type value is 15 (base layer).

The hierarchy_channel field indicates the intended channel number associated with the program element in the sequential set of transport channels. The hierarchy_channel is a 6-bit field that indicates the intended channel number for the associated program element in an ordered set of transmission channels The most robust transmission channel is defined by the lowest value of this field with respect to the overall transmission hierarchy definition).

FIG. 10 is a bitstream syntax diagram illustrating SVC extension description bytes configured according to an embodiment of the present invention.

The descriptor_tag field is used to identify the descriptor.

profile_idc field, the field is ITU-T Rec. H.264 | This field shall all be coded according to the semantics for these fields defined in ITU-T Rec. H.264 | ISO / IEC 14496-10 [11]).

The SVC_compatible_flags field is ITU-T Rec. H.264 | These 45 bits shall be coded exactly as defined for the 45 bits in the Subset Sequence Parameter Set defined in ISO / IEC 14496-10 [11]. between the constraint_set32_flag and the level_idc field in the Subset Sequence Parameter Set, as defined in ITU-T Rec. H.264 | ISO / IEC 14496-10 [11]).

The level_idc field is set to ITU-T Rec. H.264 | ISO / IEC 14496-10 [11] Coded according to the semantics for this field as defined. The entire SVC video stream associated with MH_component_type_data () depends on the profile, level and constraints signaled by the fields. (This field shall be coded according to the semantics for this field defined in ITU-T Rec. H.264 ISO / IEC 14496-10 [11] .The entire SVC video stream to which this MH_component_type_data () is associated shall conform to the profile, level and constraints signaled by these fields).

The layer_id field describes a layer identifier of the SVC enhancement layer. The field value starts with '1' and '0' is reserved to indicate the base layer. Moreover, the value of the layer_id field for the SVC enhancement layer will be greater than the layer_id field values of all layers that depend on the SVC enhancement layer (An 8-bit unsigned integer field that specifies the layer identifier of the SVC enhancement layer. The value shall start from '1', where '0' is reserved to indicate the base layer.Besides, the value of layer_id for an SVC enhancement layer shall be greater than the layer_id values of all the layers that the SVC enhancement layer depends on ).

A max_temporal_id field (3 bits) describes the temporal layer of the SVC enhancement layer. If the corresponding field value is greater than '1', the SVC layer may include temporal enhancement in the base layer or vice versa. This field describes the maximum value of temporal_id of VCL NAL units in the SVC enhancement layer. If the value is greater than or equal to '1', the SVC layer may include temporal enhancement in the base layer or vice versa. This value indicates an achievable video frame rate level when all dependent layers available for decoding and enhancement layer (A 3-bit unsigned integer field that specifies the temporal level of the SVC enhancement layer.When its value is greater than 1, the SVC layer includes a temporal (frame rate) enhancement to the base layer, and vice versa.A 3-bit unsigned integer field that specifies the maximum value of temporal_id (a field in the SVC NAL unit header extension) of all VCL NAL units in the SVC enhancement layer.When its value is greater than or equal to 1, the SVC layer includes a temporal (frame rate) enhancement to the base layer, and vice versa. value indicates the achievable video frame rate level when the enhancement layer and all the layers that it depends on are available for decoding).

The max_dependency_id field describes the inter-layer coding dependency level of the SVC enhancement layer. If the value is greater than '1', the SVC layer may include spatial enhancement in the base layer or vice versa. This field value describes the maximum value of dependencyy_id of all VCL NAL units in the SVC enhancement layer. If the value is greater than or equal to '1', the SVC layer may include a spatial or quality enhancement layer in the base layer or vice versa. This value indicates the attachable video resolution level or quality level if all layers and enhancement layers that depend on it are available for decoding (A 4-bit unsigned integer field that specifies the inter-layer coding dependency level of the SVC enhancement layer.When its value is greater than 1, the SVC layer includes a spatial enhancement to the base layer, and vice versa.A 3-bit unsigned integer field that specifies the maximum value of dependency_id (a field in the SVC NAL unit header extension) of all VCL NAL units in the SVC enhancement layer.When its value is greater than or equal to '1', the SVC layer includes a spatial or quality enhancement to the base layer, and vice versa.This value indicates the achievable video resolution level or quality level when the enhancement layer and all the layers it depends on are available for decoding).

The max_quality_id field describes the quality level of the SVC enhancement layer. If the value is greater than '1', the SVC layer may include a quality enhancement layer in the base layer or vice versa. If the corresponding field is 4 bits, the maximum value of quality_id of all VCL NAL units related to the maximum value of dependency_id among all VCL NAL units in the SVC enhancement layer will be described. If the value is greater than or equal to '1', the SVC layer may include a medium-grain cable quality enhancement layer in the base layer or vice versa. This value indicates the attachable video quality level if all layers and enhancement layers that depend on it are available for decoding (A 3-bit unsigned integer field that specifies the quality level of the SVC enhancement layer.When its value is greater than 1, the SVC layer includes a quality enhancement to the base layer, and vice versa.A 4-bit unsigned integer field that specifies the maximum value of quality_id (a field in the SVC NAL unit header extension) of all the VCL NAL units with the maximum value of dependency_id among all VCL NAL units in the SVC enhancement layer.When its value is greater than or equal to '1', the SVC layer includes a medium-grain scalable quality enhancement to the base layer, and vice versa.This value indicates the achievable video quality level when the enhancement layer and all the layers that it depends on are available for decoding).

The num_directly_dependent_layers field describes the number of other SVC layers that the current SVC layer depends on (A 6-bit unsigned integer field that specifies the number of other SVC layers that the current SVC layer directly depends on).

The directly_dependent_layer_id field describes an 8-bit unsigned integer field that specifies the layer identifier of an SVC layer which the current SVC enhancement layer directly depends on.

The SVC_still_present field indicates that the SVC video stream may include SVC still pictures. This 1-bit field when set to '1' indicates that the SVC video stream may include SVC still pictures.When set to '0', the associated SVC video stream shall not contain SVC still pictures).

As described above, by configuring values corresponding to the SDP in the form of a descriptor, a specific table of the transport stream TS, for example, a program map table (PMT), a virtual channel table (VCT) ) Or a table such as a service description table (SDT), INT, or the like, and may be used for signaling a stream on the IP. Here, the stream on the signaled IP is delivered in broadcast form through IP encapsulation in the corresponding transport stream (TS) or on another transport stream (TS), or a bidirectional network IP. It can also be delivered over the network.

Alternatively, the descriptor may be delivered through an IP stream to signal a stream on the IP. For example, in the case of digital video broadcasting in a mobile environment, an SDP file is transmitted through FLUTE, but the SDP file may be delivered in a descriptor form according to the present invention.

Second Embodiment

Next, a method of transmitting and receiving session description information in XML format according to another embodiment of the present invention will be described.

Alternatively, it may be possible to add session description information in XML format to the electronic service guide (ESG) to use the information on the electronic service guide (ESG) instead of looking for session description information through a separate mechanism. will be.

In the first embodiment described above, the session description information is configured in a binary form. In the second embodiment, the session description information is configured in an XML form. In the case of the first embodiment, it can be used in common unless it is a case of transmitting information in a binary form such as IPTV. However, in the second embodiment below, the session description information may be configured in an XML format, and thus may be applied to all methods including IPTV.

In particular, in the case of Internet Protocol TeleVision (IPTV), information necessary to receive a service is acquired through service discovery & selection (SD & S). The information necessary to receive a service in the above process may be transmitted based on a transport stream (TS) as one URL (Uniform / universal Resource Locator) or may be transmitted based on an elementary stream (ES). In this case, when transmitting based on the elementary stream (ES), information about each media stream cannot be expressed as one URL. Therefore, it is necessary to pass session information including all of them. However, in the case of IPTV, the necessary information is transmitted in the form of XML rather than the binary table. The session information according to the present invention can be easily transmitted and received by constructing the XML in the form of XML and adding it to the SD & S. In this case, the IPTV will be described later in another embodiment.

11 is an example of an XML format schema for a delivery session general parameter according to the present invention.

Referring to FIG. 12, the delivery session general parameter element according to the present invention includes general parameters applied to the entire session. Hereinafter, each sub-element constituting the delivery session general parameter element will be described.

The Service-Provider-Domain element indicates a domain of service parameter who creates the session.

The Delivery-Session-ID element indicates a unique identifier for identifying a session.

The Delivery-Session-Version element defines the version number of the session description (is a version number for this session description).

The Content-Item-Format element defines a specific format of the content item, with the following values: This element can be defined, for example, as shown in Table 1 below.

Value (Vlaue) Meaning 0 MPEG-2 Transport stream format One MPEG-2 Transport steam with associated BCG metadata. 2 MPEG-2 Transport steam encapsulated in DVB File Format. 3 Defined by Content-type of first file in the list of files in the content item descripton. 4 Elementary stream format.

However, in the present specification, by setting 4 as the value of the Content-Item-Format field, it is intended to signal that elementary stream (ES) transmission.

12 is another example of a schema in XML format for a delivery session type according to the present invention. Here, FIG. 13 is a delivery session extending the delivery session general parameter of FIG. 12.

Referring to FIG. 13, the delivery session type includes the elements of FIG. 12 described above, an IP-Address-Source element indicating a session level IP address, and a Media Information element including information on each media component constituting the session. It can be configured to include.

The Media Information element includes a plurality of attributes, a Media-Format element and a Media-Attribute element. Here, each session may consist of one or more streams, and may configure and deliver a preferred basic media combination through the attributes of the Prefered element. Only one media for each media type can have the property of the Preferred element as True. Among the plurality of attributes, an IP-Address attribute indicates a corresponding media level IP address. The IP-Port-Number attribute indicates a media level port number. The Number-of-Ports attribute indicates the number of ports. The Max-Bandwidth-Requirement attribute indicates the maximum required bandwidth of the media stream. The Preferred attribute, when true, means the preferred default media stream in the media type. However, the default value of the Preferred attribute may be False.

Next, the Media-Format element includes a Media-Type attribute, a Transport-Protocol attribute, and a Media-Format-description element.

The Media-Type attribute indicates a media type of the corresponding component. In this case, the media type may include, for example, audio and video.

The Transport-Protocol attribute indicates a transport protocol. Here, the transport protocol may include, for example, UDP, RTP / AVP, RTP / SAVP, and the like.

The Media-Format-description element defines the detailed media format description corresponding to the transport protocol.

The Media Attribute element defines the detailed attributes for the media.

Broadcast receiver

Next, an apparatus for receiving and processing a digital broadcast signal including session description information according to the present invention will be described. 13 to 15 are block diagrams of respective digital broadcast receivers constructed according to an embodiment of the present invention. FIG. 13 is a block diagram illustrating an IPTV receiver, FIG. 14 is a digital video broadcasting receiver in a mobile environment, and FIG. 15 is a satellite / terrestrial digital video broadcasting receiver.

13 to 15 illustrate a digital broadcast receiver constructed according to an embodiment of the present invention. The digital broadcast receivers shown in FIGS. 13 to 15 generally include an IPTV front end, a broadcast front end, a FLUTE processing, a service managing end, and metadata. Includes Metadata Processing, I / O Processing (Input / Output Processing), Middleware Processing, A / V Processing (Audio / Video Processing), and PVR Processing (Personal Video Recorder Processing) To configure. Here, the broadcast front end may be omitted (FIG. 13) or included (FIGS. 14 to 15) according to a transmission scheme. Hereinafter, for convenience of description, the digital broadcast receivers of FIGS. 13 to 15 will be described at a time. In this case, each stage constituting the digital broadcast receiver will be described in detail as follows.

[Broadcast Frontend]

The broadcast front end receives a broadcast signal, decodes it into an appropriate form according to a transmission method, and outputs an IP packet. Here, the broadcast front end may include a tuner / demodulator 1401, 1501, a GSE buffer / parser (GSE) buffer / parser 1502/1505, and a TS buffer ( TS Buffer (1403,1503), MPE Buffer / Parser (1402/1405), and PSI / SI Buffer / Demux + Parser (1404,1504 / 1406 1506).

The tuners / demultiplexers 1401 and 1501 receive broadcast signals and output them in the form of a stream. In case of DVB-S2 / T2 / C2, it is output in GSE / TS and in case of DVB-H in TS format.

The GSE buffer / parser 1502/1505 buffers and decodes the GSE stream (Generic Substation Events stream) and outputs the IP packet.

The TS buffers 1403 and 1503 buffer the transport stream TS.

The MPE buffer / parser 1402/1405 extracts an MPE private section (MPE) private section from the transport stream (TS) and outputs it as an IP packet.

The PSI / SI buffer / demux + parser (1404, 1504/1406, 1506) buffers and decodes the PSI / SI signal in the transport stream (TS) to decode the information on the MPE transmission and the like. 1412, 1512.

[IPTV Frontend]

The IPTV front-end receives IP-based signals and delivers them to the appropriate processing unit according to the request of the service managers 1312, 1412, and 1512. The IPTV front end may include an IP interface 1306 and an IP / Port Filter + Parser 1307, 1407, and 1507.

The IP interface 1306 includes an interface stage for connecting to the Internet, such as Ethernet, Digital Subscriber Loop (DSL), Wireless Fidelity (WiFi), and Worldwide Interoperability for Microwave Access (WiMAX).

The IP / Port filter + parser 1307, 1407, and 1507 filters the packet corresponding to the specific IP / Port according to the service access information request of the service managers 1312, 1412, and 1512, and delivers the packet to the next stage. At this time, the IP packets decoded for each address are transferred to the FLUTE processing stage, the A / V processing stage, and the security managers 1321, 1421 and 1521, which are decoded for each address under the control of the service managers 1312, 1412, and 1512.

[Service managing]

The service management group is in charge of system control regarding overall services provided by a service provider. The service management stage may include a service manager 1312, 1412, and 1512 and a channel DB 1313, 1413, and 1513.

The service managers 1312, 1412, and 1512 manage the entire service according to the service list and the access information delivered as metadata. The main functions are as follows. In the case of digital video broadcasting (DVB-H) in a mobile environment, IP list information delivered from PSI / SI is processed. In the case of terrestrial or cable digital video broadcasting (DVB-T2 / C2), tuner control information such as PLP transmitted from PSI / SI is processed. The service managers 1312, 1412, and 1512 process service connection information transmitted from the SDP parsers 1309, 1409, and 1509. The service managers 1312, 1412, and 1512 provide filtering information of the IP / Port filters 1307, 1407, and 1507 according to the processed service access information. At this time, the service managers 1312, 1412, and 1512 control which processing stages the IP packet outputted according to the filtering should be delivered to (FLUTE, security or A / V). The service managers 1312, 1412, and 1512 signal which XSLT logic (XSLT) logic should be processed when converting system-specific metadata into a common metadata scheme. In addition, the service managers 1312, 1412, and 1512 request and receive various types of information of services required for the common metadata handlers 1336, 1436, and 1536, and process the received information. 1313, 1413, and 1513 only select and store the necessary information. The service managers 1312, 1412, and 1512 are in charge of service related tasks (channel switching, etc.) during the EPG operation.

The channel databases 1313, 1413, and 1513 store information related to service management / switching / connection among the service related information so that the service managers 1312, 1412, and 1512 can operate efficiently, and the service managers 1312, At the request of 1412 and 1512, the information is inputted and outputted from time to time.

[FLUTE processing stage]

The FLUTE processing stage decodes a file encoded by the FLUTE protocol and delivers the file to the processing unit according to each content type. The FLUTE processing stage may include a FLUTE parser + Gzip / BiM decoder 1308, 1408, and 1508, an SDP parser 1309, 1409, and 1509, and a metadata buffer. Metadata Buffer 1310, 1410, 1510 and File Buffer 1311, 1411, 1511.

The FLUTE parser + Gzip / BiM decoders 1308, 1408, and 1508 decode the files encoded based on the FLUTE protocol, and decompress them according to the compressed method to output the files. The content type of the output file can be known according to the FDT contents of the FLUTE protocol. Accordingly, each file can be classified into an SDP parser (1309, 1409, 1509), a metadata buffer (1310, 1410, 1510), or a file buffer (1311). 1411, 1511).

The SDP parsers 1309, 1409, and 1509 decode the SDP files, which are files representing the connection information, and deliver the results to the service managers 1312, 1412, and 1512.

The metadata buffers 1310, 1410, and 1510 buffer metadata, which is an XML file representing overall information related to services and content, and transfer the metadata to the XSLT parser units 1314, 1414, and 1514 to convert them into common metadata.

The file buffers 1311, 1411, and 1511 buffer various files used in middleware and store them in a file database 1324. This file is used by the middleware engine units 1323, 1423, and 1523.

In the above, for metadata and SDP transmission, for example, HTTP may be used for unicast, and DVB-STP may be used for multicast.

[Metadata processing stage]

The metadata processing stage converts the metadata delivered by the FLUTE processing stage into a common metadata format, which is a common format, and stores the metadata. The metadata processing unit retrieves relevant content and transmits the result according to a request of each part. Here, the metadata processing stage may include an Extensible Stylesheet Language Transformations (XSLT) parser (1313, 1413, 1513), a metadata database (1315, 1415, 1515), and a common metadata handler (XSLT). common metadata handler) (1336,1436,1536).

The XSLT parsers 1314, 1414, and 1514 convert other metadata depending on the transmission scheme into common metadata using the XSLT for each transmission scheme.

The metadata databases 1315, 1415, and 1515 store common metadata, retrieve them according to requests of the common metadata handlers 1336, 1436, and 1536 and deliver the results.

The common metadata handlers 1336, 1436, and 1536 retrieve the metadata according to various requests for information on services, events, and connection information, and the service managers 1312, 1412, and 1512 and the EPG managers 1316, 1416, and 1516. To the security managers 1321, 1421 and 1521. The metadata may be stored in association with the PVR data at the request of the PVR managers 1329, 1429, and 1529.

[Middleware processing]

The middleware processing stage converts the metadata delivered from the FLUTE processing stage into a common metadata format, which is a common format, and stores the metadata. The middleware processing stage retrieves relevant contents according to a request of each part and delivers the result. The middleware processing stage may include a file database 1322, 1422, and 1522 and a middleware engine 1323, 1423, and 1523.

The file databases 1322, 1422, and 1522 store various files to be used by the middleware engines 1323, 1423, and 1523, and deliver necessary files upon request.

The middleware engines 1323, 1423, and 1523 drive and require middleware such as the Advanced Common Application Platform (ACAP), the OpenCable Application Platform (OCAP), the Multimedia Home Platform (MHP), and the Multimedia and Hypermedia information doding Experts Group (MHEG). The applications received from the file databases 1322, 1422, and 1522 are displayed on the screen through the video post processors 1319, 1419, and 1519.

[A / V processing stage]

The A / V processing stage decodes and scrambles the A / V stream transmitted through the Real-time Transport Protocol (RTP), and synchronizes and displays the sync on the screen. Here, the A / V processing stage may include: UDP / RTP parser + CAS (UDP / RTP parser + CAS) 1324, 1424, and 1524, descramblers 1325, 1425, and 1525, and a security manager 1321. (1421, 1521), audio decoders (1326, 1426, 1526), video decoders (1327, 1427, 1527) and system time clock (STC) (1328, 1428, 1528). It can be configured to include.

The UDP / RTP parser + CAS 1324, 1424, and 1524 parse incoming streams according to the User Datatgram Protocol (UDP) and the RTP protocol, and classify the audio stream and the video stream according to the payload type.

The descramblers 1325, 1425, and 1525 descramble the scrambled stream based on the scrambled key values and necessary parameters transmitted from the security managers 1321, 1421 and 1521.

The security managers 1321, 1421, and 1521 transfer the descrambler information to the descramblers 1325, 1425, and 1525 through the security information and the key value transmitted through the RTP and the metadata.

The audio decoders 1326, 1426 and 1526 decode the audio streams, and the video decoders 1327, 1427 and 1527 decode the video streams.

The STCs 1328, 1428, and 1528 serve as a reference for synchronizing sync according to a timestamp when decoding an A / V stream, and a standard for synchronizing a reproduction speed with a transmitted stream. It receives clock recovery information from RTP and synchronizes it with the server's clock. During PVR playback, a clock is supplied from an upload controller.

[PVR processing stage]

The PVR processing stage is a part related to a function related to a PVR (DVR), that is, a stream storage and playback. The PVR processing stage may include a PVR manager 1329, 1429, and 1529, a download controller 1334, 1434, and 1534, a scrambler 1335, 1435, and 1535. Hard disks (HDD) 1333, 1433, and 1533, descramblers 1332, 1432, and 1532, and upload controllers 1331, 1431 and 1153 may be configured.

The PVR managers 1329, 1429, and 1529 control operations related to the PVR. In other words, the download / upload control unit 1331, 1431, 1531 in the PVR processing block is controlled by storage, playback, scheduled recording, and the like, and the middleware engines 1323, 1423, and 1523 are used for data broadcasting recording. Communicate with the UI managers 1317, 1417, and 1517 for communication and PVR User Interface (UI), and interoperate with common metadata handlers 1336, 1436, and 1536 for metadata storage associated with stored content Done.

The download control units 1334, 1434, and 1534 attach and store information such as timestamps and random access points to the A / V stream during stream recording.

The scramblers 1335, 1435, and 1535 scramble the stream for recording the content.

The hard disks 1333, 1433, and 1533 store A / V streams.

The descramblers 1332, 1432, and 1532 descramble the scrambled for content protection for playback.

The upload control units 1331, 1431, and 1531 transmit information, such as a time stamp and a random access point, attached to the A / V stream to the STCs 1328, 1428, 1528, and the PVR managers 1329, 1429, and 1529 when the stream is played. The stream is then delivered to the audio decoders 1326, 1426, 1526 and the video decoders 1327, 1743, 1525.

[I / O processing stage]

The I / O processing stage is a part related to a user input and an A / V output. Here, the I / O processing stage may include an EPG manager 1316, 1416, 1516, a UI manager 1317, 1417, and 1517, a user interface 1318, 1418, and the like. 1518, video post processors 1319, 1419, and 1519, and audio post processors 1320, 1420, and 1520.

The EPG managers 1316, 1416, and 1516 receive the related metadata from the common metadata handlers 1336, 1436, and 1536 in order to display the EPG, and process the metadata into appropriate forms through the UI managers 1317, 1417, and 1517. The image is blended with a video stream or a middleware application and displayed on the screen.

The UI managers 1317, 1417, and 1517 interpret the user's input and work with the service manager / EPG manager / PVR manager 1312, 1412, 1512/1316, 1416, 1516/1329, 1429, 1529, and the like. Ask.

The user interfaces 1318, 1418, and 1518 transmit user input to the system through the UI managers 1317, 1417, and 1517.

The video post processors 1319, 1419, and 1519 blend and display a video stream, a middleware application, an EPG, various UI widgets, and the like on a screen.

The audio post processors 1320, 1420, and 1520 output the audio stream as sound in association with functions such as volume control and mute.

Through the block diagrams of the digital broadcast receivers of FIGS. 13 to 15 described above, A / V, files, metadata, etc. received through broadcast or IP may be processed.

According to the digital broadcast receiver according to the present invention of FIGS. 13 to 15 described above, the session description descriptor or the common metadata including the session description information according to the present invention can be processed to more efficiently access and process the service. It is possible to provide fast service by reducing connection time.

Next, a method of processing a digital broadcast signal including session information according to an embodiment of the present invention will be described. 16 is a flowchart illustrating a process of processing a digital broadcast signal and connecting to a receiver according to an embodiment of the present invention. Here, FIG. 16 is a diagram illustrating a process of a receiver accessing a service using session description information according to the present invention.

In connection with the present invention, a receiver may access a service by processing a session description descriptor (SDD) including session description information included in a received digital broadcast signal. Hereinafter, a process of accessing a service through the above processing will be described in more detail.

First, the receiver extracts the session description descriptor SDD from the received digital broadcast signal and processes the extracted session description descriptor SDD. The session general information is extracted from the processed session description descriptor SDD and parsed (S1601). Here, the session general information refers to information of each field in the session description descriptor (SDD) of FIG. 5, for example.

It is determined whether there is a media stream further from the parsed session general information (S1602).

As a result of the determination in step S1602, if there is no more media stream, the corresponding content is consumed. That is, it connects to the service. However, if it is determined in step S1602 that the media stream exists, information about the media type in the parsed session general information is parsed (S1603). Here, the information about the media type may mean, for example, the Media_Type field of FIG. 6.

In step S1603, after parsing information about a media type, UDP / RTP information is parsed from the parsed result (S1604). Here, the UDP / RTP information may be obtained by parsing the Target_Port_Number field and the RTP_Payload_Type field of FIG. 6, for example.

After performing step S1604, it is determined whether the media type of the media stream is audio or video using the information about the media type parsed in step S1603 (S1605).

If it is determined in step S1605 that the type of the media stream is video, information about the video codec type is parsed (S1606) and video description bytes are parsed (S1607). The content is consumed (S1610). Here, the parsed video description bytes may include the above-described AVC_Video_Description_Bytes, Hieararchy_Description_Bytes, and SVC_Extension_Description_Bytes fields.

In relation to this, if it is determined in step S1605 that the type of the media stream is audio, information about the audio codec type is parsed (S1608), and audio description bytes are parsed (S1609). The content is consumed (S1610). Here, the parsed audio description bytes may include the aforementioned MPEG-4 Audio_Description_Bytes field.

On the other hand, the terms used in the present invention (terminology) are terms defined in consideration of functions in the present invention, which may vary according to the intention or custom of a person skilled in the art, the definition of which is used throughout the present invention. It should be based on what has been done.

The present invention is not limited to the above-described embodiments, and as can be seen in the appended claims, modifications can be made by those skilled in the art to which the invention pertains, and such modifications are within the scope of the present invention.

And, the above-mentioned numerical value is a preferred embodiment or merely an example, the scope of the present invention is not limited to the numerical values, and as can be seen in the appended claims, Modifications are possible by those skilled in the art and such modifications are within the scope of the present invention.

1 is a structural diagram illustrating a structure for receiving a service in digital video broadcasting of a mobile environment according to the present invention;

FIG. 2 is a structural diagram illustrating a layer 1 signaling structure required for receiving a service in terrestrial digital video broadcasting (DVB-T2) according to the present invention; FIG.

3 is a structural diagram illustrating a frame structure of the terrestrial digital video broadcasting of FIG.

4 is a structural diagram illustrating a structure of a service description section in a service information (DVB-SI) of digital video broadcasting including a service description descriptor (SDD) according to an embodiment of the present invention. ,

5 illustrates a bitstream syntax of a session description descriptor (SDD) constructed according to an embodiment of the present invention;

6 illustrates bitstream syntax of a media_info_bytes field configured according to an embodiment of the present invention;

FIG. 7 illustrates bitstream syntax illustrated to describe AVC Video Description Bytes configured according to an embodiment of the present invention; FIG.

8 illustrates bitstream syntax illustrated to describe MPEG-4 Audio Description Bytes constructed according to an embodiment of the present invention;

FIG. 9 illustrates a bitstream syntax illustrated to explain Hierarchy Description Bytes constructed according to an embodiment of the present invention. FIG.

FIG. 10 illustrates a bitstream syntax illustrated to describe SVC Extension Description Bytes configured according to an embodiment of the present invention.

11 is an example of an XML-type schema for a delivery session general parameter according to the present invention.

12 is another example of an XML type schema for a delivery session type according to the present invention.

13 to 15 are block diagrams of digital broadcasting receivers configured according to an embodiment of the present invention.

16 is a flowchart illustrating a process of processing a digital broadcast signal and connecting to a receiver according to an embodiment of the present invention.

Claims (19)

Receiving a digital broadcast signal; Extracting a session description descriptor (SDD) including description information for signaling a session including at least one media component from the received digital broadcast signal; Parsing session general information from the extracted session description descriptor (SDD) including general parameters that apply to the entire session; Parsing information from the parsed session general information about a media type providing detailed information of each media component constituting the session; Parsing information about a protocol through which each media component is transmitted from information about the type of the parsed media component; Parsing description information including parameters used for decoding each media component based on the information about the parsed media type and the information about the protocol; And And accessing and consuming a service by decoding respective media components based on the parsed description information. The method of claim 1, Parsing information for identifying a type of a codec of each media component on the basis of the information about the parsed media type. The method of claim 1, The session description descriptor, And a service description table and an IP / MAC notification table among a plurality of tables included in the received digital broadcast signal. The method of claim 3, The session general information is Identifier information for identifying the session, version information of the session, information defining an address type of the session, a flag indicating whether a connection of a session level exists or not; A digital broadcast signal comprising at least one of information defining a connection address applicable to a component of an entire session according to a flag value and detailed information on each media stream. How to handle it. The method of claim 4, wherein Information for defining a connection address applicable to a component of an entire session according to the flag value, And at least one of information on the number of IP streams transmitted through the session and information on a target IP address. The method of claim 1, In the media type, At least one of audio and video. The method of claim 1, The protocol information, And at least one of information for identifying a target port number to which the corresponding component is transmitted and information for identifying a type of an RTP payload. The method of claim 1, Wherein each media stream is transmitted as an elementary stream. Receiving a digital broadcast signal; Extracting a delivery session parameter element including description information for signaling a session including at least one media component from the received digital broadcast signal, wherein the extracted delivery session element is a session. Session general parameter element including general parameters that apply to the whole, an IP address source element indicating a session level IP address, and information about each media component composing the session Including a media element comprising a media element; Extracting and parsing a session general parameter element from the extracted delivery session element; Extracting and parsing an IP address source element and a media element based on the parsed delivery session element; And And accessing and consuming a session by decoding a session including each media component based on each parsed element. 10. The method of claim 9, The session general parameter element is An element for providing domain information of the service provider providing the session, an element including an identifier for identifying the session, an element defining version information of the session description, and an element defining a specific format of a content item And at least one or more. The method of claim 10, An element defining a specific format of the content item, And indicating that a specific format of a corresponding content item is an elementary stream. 10. The method of claim 9, The media element is, Attributes defining a media level IP address, attributes indicating a media level port number, attributes indicating the number of ports, attributes defining the maximum required bandwidth of the media stream, and preferred media streams preferred in the media type. At least one or more of properties including at least one or more of the predefined properties defined, a media format element defining the format of each media component, and a media property element defining the detailed properties of the media component. A method for processing a digital broadcast signal, characterized in that it comprises. The method of claim 12, The media format element, Attributes including at least one of a media type attribute defining a media type of a corresponding media component and a transport protocol attribute defining a protocol over which the session is transmitted, and a detailed media format description corresponding to the protocol over which the session is transmitted And at least one of a media format description element. A tuner unit tuned to a channel to receive a digital broadcast signal; A demultiplexer for demultiplexing a session including each media stream from the received digital broadcast signal and common metadata including information about the session; A parser for parsing the demultiplexed session and common metadata; A common metadata handler unit for controlling a service manager using the parsed common metadata; An EPG manager unit configured to configure an EPG screen according to the control of the common metadata handler unit; A UI manager unit for receiving and transmitting a user input; A service manager unit controlling service access under the control of the EPG manager unit and the common metadata handle unit; A control unit controlling to process a session to provide a service under control of the service manager unit; And And a decoder for decoding each media stream in the received session under the control of the controller. The method of claim 14, A channel database unit for storing a channel map associated with service provision under the control of the service manager; And a metadata storage unit for storing common metadata parsed by the parser. The method according to claim 14 or 15, And a display unit for receiving and displaying each media stream decoded by the decoder unit. An IP interface unit for receiving and receiving an IP signal; A demultiplexer for demultiplexing a session including each media stream from the received IP signal and common metadata including information about the session; A parser for parsing the demultiplexed session and common metadata; A common metadata handler unit for controlling a service manager using the parsed common metadata; An EPG manager unit configured to configure an EPG screen according to the control of the common metadata handler unit; A UI manager unit for receiving and transmitting a user input; A service manager unit controlling service access under the control of the EPG manager unit and the common metadata handle unit; A control unit controlling to process a session to provide a service under control of the service manager unit; And And a decoder for decoding each media stream in the received session under the control of the controller. The method of claim 17, A channel database unit for storing a channel map associated with service provision under control of the service manager; And a metadata storage unit for storing common metadata parsed by the parser. The method of claim 17 or 18, And a display unit for receiving and displaying each media stream decoded by the decoder unit.

Images