WO2023063524A1 - 미디어 데이터 처리 방법 및 미디어 데이터 처리 장치 - Google Patents

미디어 데이터 처리 방법 및 미디어 데이터 처리 장치 Download PDF

Info

Publication number
WO2023063524A1
WO2023063524A1 PCT/KR2022/008334 KR2022008334W WO2023063524A1 WO 2023063524 A1 WO2023063524 A1 WO 2023063524A1 KR 2022008334 W KR2022008334 W KR 2022008334W WO 2023063524 A1 WO2023063524 A1 WO 2023063524A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
dvb
information
media data
list
Prior art date
Application number
PCT/KR2022/008334
Other languages
English (en)
French (fr)
Inventor
박종환
윤준희
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to US18/700,061 priority Critical patent/US20240340484A1/en
Priority to KR1020247009213A priority patent/KR20240049333A/ko
Publication of WO2023063524A1 publication Critical patent/WO2023063524A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6118—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving cable transmission, e.g. using a cable modem
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6143—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a satellite
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Definitions

  • the present invention relates to a media data processing method and a media data processing apparatus.
  • IP-based TV service that can provide the same user UX as terrestrial, satellite, and cable linear channels.
  • a media carrier processing apparatus implements an IP-based TV service capable of providing the same user UX as terrestrial, satellite, and cable linear channels.
  • a media carrier processing device provides a channel guide integrated with terrestrial, satellite, and cable channels through open Internet-based native code reception, not an application-based linear channel service.
  • a media carrier processing apparatus considers a situation in which broadcast services are consumed through media such as OTT, PC, and IPTV of IP-based devices and high traffic of unicast, rather than direct reception of terrestrial waves (fixed). to provide a seamless service of real-time/non-real-time media streaming service.
  • a media data processing method includes generating media data; generating a service list for media data; and transmitting the media data and service list based on the network; can include
  • a media data processing method includes receiving media data and a service list related to the media data based on a network; and processing media data based on the service list; can include
  • FIG. 1 shows a service scenario according to embodiments.
  • Figure 2 shows a flow diagram of an operation according to embodiments at the network operator/ISP side according to embodiments.
  • Figure 3 shows a stack of protocols for DVB channel service according to embodiments.
  • FIG. 4 shows an extension syntax of a service discovery list table according to embodiments.
  • 5 shows an example of management of a channel according to embodiments.
  • FIG. 7 shows a flowchart of hidden channel management according to embodiments.
  • FIG. 8 shows an example in which a related material is included in SDLT according to embodiments.
  • FIG. 10 shows an example of utilizing an inactive banner according to embodiments.
  • FIG. 11 shows a service list hierarchical structure according to embodiments.
  • FIG. 13 shows DVB-I service types according to embodiments.
  • Fig. 16 shows a scheme for selecting a service instance based on DASHDeliveryParametersType according to embodiments.
  • FIG. 17 shows an example of a DVB-I service instance according to embodiments.
  • Fig. 19 shows a DVB-I service list hierarchy according to embodiments.
  • FIG. 21 illustrates a DVB-I client over-running issue according to embodiments.
  • FIG. 24 shows a DVB-I service hierarchy according to embodiments.
  • 25 illustrates a method for updating DVB-I service scheme and content guide latest information according to embodiments.
  • Fig. 26 shows a model of a DVB-I client according to embodiments.
  • FIG. 27 illustrates a method of obtaining the latest content guide information for each DVB-I service according to embodiments.
  • Fig. 29 shows a flow chart of DVB-I service initialization and content guide update according to embodiments.
  • FIG. 33 illustrates a DVB-I service architecture for supporting a manufacturer service list according to embodiments.
  • 35 illustrates the syntax of a service list registry entity according to embodiments.
  • 36 illustrates semantics of a service list registry entity according to embodiments.
  • 38 illustrates a method for responding to a channel collision when receiving a multiple service list according to embodiments.
  • 41 shows an example of resolving a service channel collision according to embodiments.
  • 45 illustrates reference clock synchronization according to embodiments.
  • Fig. 47 illustrates a use case according to synchronization requirements according to embodiments.
  • 50 illustrates information for service instance switching according to embodiments.
  • 51 is an example of service instance switching according to embodiments.
  • FIG. 53 shows a 5GBC instance and an OTT instance according to embodiments.
  • 54 illustrates video attribute type signaling according to embodiments.
  • HFR 55 shows a high frame rate (HFR) example according to embodiments.
  • 57 illustrates an example of signaling video attributes according to embodiments.
  • 58 illustrates a multi-view transmission process according to embodiments.
  • 59 shows video data division units according to embodiments.
  • 60 shows subpicture division according to embodiments.
  • 61 illustrates signaling information about a subpicture according to embodiments.
  • 63 shows a main scene configuration according to embodiments.
  • 64 illustrates a reference relationship between subpictures according to embodiments.
  • FIG. 66 illustrates a scene description based receiving device according to embodiments.
  • Figure 67 shows scene description transfer syntax according to embodiments.
  • 68 shows a DVB-I service list including a scene description according to embodiments.
  • 69 shows a scene description of an MPD according to embodiments.
  • 70 shows syntax of a scene description in a DVB-I service list according to embodiments.
  • 71 illustrates a hybrid service scenario according to embodiments.
  • 73 illustrates a method of obtaining a DVB-I service list according to a delivery method upon DVB-I discovery according to embodiments.
  • 76 illustrates a method of obtaining a group message through a service ID according to embodiments.
  • 77 illustrates a group message acquisition process according to embodiments.
  • ServiceInstanceType extension for supporting 5GBC according to embodiments.
  • 81 illustrates DVB 5GBC delivery parameter types according to embodiments.
  • 82 illustrates a 5GBC service acquisition process according to embodiments.
  • 83 illustrates a method of defining an image according to embodiments.
  • 86 is an example of supporting service thumbnails according to embodiments.
  • FIG. 88 shows a media processing device according to embodiments.
  • 90 illustrates image type support according to embodiments.
  • 91 illustrates service thumbnail offerings and service thumbnail elements according to embodiments.
  • 92 shows a media processing device according to embodiments.
  • a media data processing method/device may refer to a media data transmission/reception method/device.
  • a media data processing method/device according to embodiments may be referred to as a method/device according to embodiments for short.
  • a method/apparatus relates to a method for discovering and obtaining media data (which can be referred to as a service) related to Internet-based broadcasting.
  • FIG. 1 shows a service scenario according to embodiments.
  • a method/apparatus may provide a method for supporting DVB-I standard based multi-viewport user personalization (MULTI-VIEWPORT USER PERSONALIZATION).
  • the method/device according to the embodiments may provide a method for extending a communication network such as DVB-I over 5G extension and 6G.
  • the method/apparatus according to the embodiments may provide an additional webp image extension considering DVB-I backward compatibility.
  • Embodiments provide a service discovery method to provide an Internet-based broadcast service.
  • Embodiments propose additional information to be defined for Internet-based broadcast service identification.
  • Embodiments provide a system mechanism for obtaining Internet-based broadcast service signaling.
  • Embodiments propose a versioning/expiration management method for each service and a selective parsing and storage method for each service when receiving an aggregated service list.
  • Embodiments propose a channel management method in a hidden/selectable/inactive state of an Internet linear channel.
  • Embodiments propose a service discovery signaling method to provide an Internet-based broadcast service.
  • a service list metadata envelope when a fragmented service list for each unique service is included in a multipart/related container and transmitted list metadata envelope) structure.
  • Embodiments display current channel status to a user or provide an alternative channel when the user directly accesses the current channel, within the hidden/selectable/inactive case of an Internet linear logical channel. Suggest how to do it.
  • Embodiments have an effect of enabling Internet-based Broadcast Service Discovery and Acquirement through a Broadband network in a receiver not equipped with an existing traditional tuner. there is.
  • Embodiments need to receive the entire aggregated service list with a versioning/expiration management method for each service and selective parsing and storage for each service when receiving the aggregated service list. has no effect.
  • Embodiments provide better media by preventing the logical channel service that causes the inconvenience of not broadcasting to the user when the Internet linear channel is hidden/selectable/inactive, and providing an alternative Internet return channel service. There is an effect that the service can be provided.
  • the traditional IP-based linear channel service is a type in which authentication is granted through subscription of a specific operator (e.g. ISP, Network Operator) and IP linear service is received through the STB provided by the operator.
  • ISP Internet Protocol
  • IP linear service is received through the STB provided by the operator.
  • Connectivity TV it is possible to consume IP linear services in the form of STB-less.
  • Representative standard technologies are ATSC 3.0, IBB, and HbbTV, and a client can receive various linear rich-media services by operating an application on an OS platform inside the TV.
  • Various operators provide service applications that can be installed on the TV platform only developed by themselves, and the applications define servers that can receive data for services and APIs that enable request/reception. there is. Based on the life cycle, the client can access the app through the TV UI and receive various services through the app.
  • the embodiments propose a method and apparatus for solving issues such as the proprietary platform of OTTs and the dependency on the operation of applications.
  • Embodiments are receiver native (not in the form of providing a channel UX similar to terrestrial (T), satellite wave (S), and cable (C) linear channel services by necessarily executing an app as in the existing technology)
  • T terrestrial
  • S satellite wave
  • C cable
  • the embodiments propose a service scenario in which OTT content can be viewed within a channel without running an OTT app to the user by integrating OTT's independent platform into a unified TV native platform.
  • a broadcaster (10000) may transmit a service through an Internet channel (10020) simultaneously with a terrestrial (T), satellite (S), and cable (C) channel 10010.
  • Service, operator, and device manufacturer capable of receiving DVB-I service (10050) acquire authentication for service channels through regulation, and establish Internet channels through existing linear services and channel aggregators. can provide
  • the existing traditional service provision form can be expanded, and additional services can be provided in the form of on-demand/multicast service along with the existing linear channel network.
  • a personalization service may be provided through a connection-based usage report of an Internet channel.
  • OTT contents are aggregated to bring about expansion of service provision.
  • unicast/multicast dynamic allocation it is possible to provide enhanced delivery performance over non-management network-based service terminals.
  • the broadcaster 10000 may transmit broadcast data to the traditional broadcasting network 10010 and the Internet network 10020, and a receiving device according to embodiments, for example, a TV 10060 or a 2nd device 10070.
  • a receiving device may request service discovery 10030 of broadcast data from a DVB-I provider or server 10050, receive an integrated DVB-I service list 10040, and install and execute a separate app at the native level Service signaling is possible for both traditional linear channels and Internet channels without any process.
  • the method/apparatus according to the embodiments can solve the following problems based on the structure shown in FIG. 1 .
  • the end point of a request for the entire service list or individual service may be the same.
  • the limitations of not being able to give individual periods for each service and having to perform protocol communication with the same endpoint can be solved through minimum metadata update period @minimumMetadataUpdatePeriod in the DVB-I service hierarchy (see FIG. 15, etc.) according to embodiments. .
  • DVB-I mainly receives services based on a service list, and each service list can be operated and managed in a specific repository.
  • the repository providing the existing DVB broadcasting list can define the DVB-I service list by taking a method of allocating LCNs based on countries or specific regions due to the characteristics of current European broadcasting services.
  • specific DVB-I service list providers collect independent services regardless of region and define LCN list, LCN allocation can be set arbitrarily by service list provider. Therefore, under this background, a potential issue of channel collision exists when a DVB-I client receives and merges multiple service lists.
  • DVB-I over 5G it should be a smooth and continuous service between delivery routes supported by multiple distributions, and it should be able to provide services through efficient and flexible access according to the optimal network environment.
  • the propagation delay delivered is different depending on the network characteristics, so in the case of linear service, the provided reference time and media characteristics can be provided in different environments for each network.
  • the discovery URL and media location URL are all different for each operator, and there is an issue in which perfect switching is difficult when switching media in the middle.
  • the predefined TVA Attribute contains only the basic information (Framerate/resolution) of Audio, Video, and Subtitle, which is insufficient information for user access/download.
  • Embodiments require additional requirements for the user personalization service in the DVB-I service, and try to create a solution to solve the technical configuration limitations that are difficult to support in the current DVB-I standard.
  • Embodiments propose a method and technology related to service discovery in order to provide an Internet-based broadcast service.
  • Embodiments propose additional information to be defined for Internet-based broadcast service identification.
  • Embodiments propose a system mechanism for obtaining Internet-based broadcast service signaling.
  • Embodiments provide a versioning/expiration management method for each service and a selective parsing and storage method for each service when receiving an aggregated service list.
  • Embodiments provide a channel management method in a hidden/selectable/inactive state of an Internet linear channel.
  • Proper alignment between service instances can be provided so that the transition between service instances delivered through different networks can be recognized as reasonably smooth.
  • DVB-I service instances including 5GBC, 5GMS, and OTT (non 5G networks such as LTE and Wifi).
  • Embodiments provide service instances to display essential information for content selection on the Service/Content guide UI through information provided by a service discovery server or a service list server. ) to expand
  • Embodiments extend classification scheme type (ClassificationSchemeType) for extending information that cannot be provided in an existing scheme and defining specific video information through TVA Attribute extension.
  • the subpicture information in the MPEG VVC codec is coordinates/size indicating a position, but is additional information for controlling the CTU level required in the video encoding process or positional information from the point of view of a codec, and does not mean specific coordinates or pixel positions for rendering. That is, information on the rendering position is not defined, so additional extensions are required.
  • Embodiments may provide a service discovery signaling scheme to provide an Internet-based broadcast service.
  • the service list metadata envelope (service list) metadata envelope) structure.
  • Embodiments may provide a method of displaying the current channel state or providing an alternative channel to the user when the user directly accesses the current channel in the hidden/selectable/inactive case of the Internet linear logical channel.
  • the following information can be used: (1 ) Reference time information to which the dynamic polling interval is to be applied, (2) offset by x sec from the reference time;time information (e.g. DVB-I service Availability end time), (3) polling interval to be newly applied, (4) existing information and version information for comparison.
  • a method/apparatus may perform dynamic polling based on the above information and @MinimumMetadataUpdatePeriod.
  • the information of @ScheduleEndPoint in the ContentSourceType is defined as the same end point in the service list type and service list, so that related information can be requested and received. Information of individual sections can be obtained for each service.
  • scheduleInfoEndPoint can be created to request and receive event information of a specific section.
  • a DVB-I client receives service discovery entities during the bootstrapping process and can display filtered list entries according to language, country, region, and postcode. You can search for service entities and their service entity repositories that are tailored to the user's selection or environment. At this time, a service list repository operated by a manufacturer may be searched, and device capability information capable of confirming support of the corresponding service list may be defined.
  • ⁇ LCNTableEntryType> within the current DVB-I service list scheme can be extended.
  • the service list scheme can be extended to support time alignment between service instances delivered through different networks.
  • the DASH delivery parameter in the following DVB-I service list scheme can be extended.
  • Embodiments expand related information to clarify service selection criteria for users, and perform service filtering on the receiver side, so that clear information can be presented on the UI/UX.
  • Embodiments may propose a solution of scene description and rendering information for displaying subpictures based on VVC encoding.
  • Embodiments can refer to information of a hierarchy that extends scene description information at a position where video characteristics are defined in the DVB-I and DASH layers, which are system layers, and encapsulates an actual subpictute.
  • Embodiments may consider receiver operation and receiver backward compatibility to support a related use case.
  • the Internet linear channel When the Internet linear channel is hidden/selectable/inactive, it is possible to provide a better media service by blocking the logical channel service that causes the inconvenience of not broadcasting to the user and providing an alternative Internet return channel service.
  • Devices may display up-to-date information of a corresponding channel instead of showing a guide of an over-running program during tune-in or channel change.
  • the polling operation of the entire content guide can be controlled by defining it in the entire content guide at the service list level, or the polling algorithm that is dynamic for individual services by defining it at the service level can also be applied.
  • the attribute of the corresponding channel is processed as dynamic, and when updating all or individual services, it is known in advance that the corresponding channel is a channel to which the dynamic polling algorithm is applied. can be displayed
  • the latest information in the client can be updated by adding an end point that can update individual sections for each service.
  • a DVB-I client When a DVB-I client receives and merges multiple service lists or receives an additional service list on a basic legacy channel, it reflects the intention of the service provider and provides a channel ordering method that the DVB-I client handles without issues. there is.
  • Embodiments can clearly show the service that can be currently provided to the user through extended information, induce a reasonable choice, and clarify the criteria for service selection.
  • Embodiments can provide a personalized service by providing different viewports according to modes by transmitting several subpictures within a DVB-I based service.
  • the method/device according to the embodiments may refer to the DVB-I A177 document.
  • the traditional IP-based linear channel service is in the form of receiving IP linear service through the STB provided by the operator after receiving authentication through the subscription of a specific operator (e.g. ISP, Network Operator).
  • a specific operator e.g. ISP, Network Operator
  • IP linear services in the form of STB-less.
  • Typical standard technologies are ATSC 3.0, IBB, and HbbTV, and clients can receive various linear rich-media services by operating applications on the OS platform inside the TV.
  • Various operators provide service applications that can be installed on the TV platform only developed by themselves, and the application defines servers that can receive data for services and APIs that enable request/reception. Based on the life cycle, the client can access the app through the TV UI and receive various services through the app.
  • OTT channels have increased as much as watching linear TV worldwide in North America and Europe, and this expansion of the OTT market has established itself as an essential media application for IP-based devices.
  • the form of influential OTT has become an exclusive service with its own platform and OTT service eco-system.
  • each OTT shows its own app-ecosystem consumption type, such as codec, protocol stack, application, and browser.
  • DVB-I is developing a reference client application in the industry based on the A177 document, identifying development issues and problems of the current standard within the DVB-I standardization group, proceeding with appropriate extensions and clarification for smooth development. there is.
  • the content guide manager and service list manager perform separate parsing and caching processes, and in the process of managing the acquired LCN DB information, indication is required for channels that can be dynamically changed, so the corresponding information is extended.
  • indication information is added that the corresponding channel is a channel that applies dynamic polling rather than static pull method.
  • the DVB-I phase 1 scheme receives data according to the pull-only method, it is not possible to check whether the latest information of the code level has been obtained.
  • the DVB-I client of the device according to the embodiments can solve the problem through a specific polling interval.
  • the service hierarchy can obtain event information at one time at the service list or service level, but since both levels use the same method, it is impossible to update a specific section for each individual service. .
  • Figure 2 shows a flow diagram of an operation according to embodiments at the network operator/ISP side according to embodiments.
  • An apparatus 20000 may be a TV receiver. That is, it may be a device according to a hybrid IPTV/DTT network supporting DVB-I service.
  • the receiving device 20000 may be connected to the STB.
  • the connection method may be, for example, HDMI.
  • IPTV STB can receive terrestrial broadcasting signals from terrestrial headend through terrestrial network, multicast headend that provides multicast service through home gateway and broadband network, DVB-I source that provides DVB-I service, And/or various services and/or data may be received from a Content Delivery Network (CDN) providing Internet contents.
  • CDN Content Delivery Network
  • the method/device according to the embodiments may use the service as an industry standard based ecosystem without such a separate application. This has an effect of providing convenient and efficient service access by providing a common service interface.
  • Figure 3 shows a stack of protocols for DVB channel service according to embodiments.
  • the TV device 20000 of FIG. 2 may perform the scenario of FIG. 1 based on the protocol structure of FIG. 3 .
  • Services according to embodiments include DVB C/S/T/I services. Based on the protocol stack structure constituting the DVB-C (30000) / S (30010) / T (30020) / I (30030) service of FIG. We propose a mechanism for this and a signaling method accordingly.
  • the method/apparatus according to embodiments may drive an application through service discovery, and the application 30040 according to embodiments may include a native application, a pre-installed application, a user-selected application, and the like. there is.
  • FIG. 4 shows an extension syntax of a service discovery list table according to embodiments.
  • the method/apparatus according to embodiments may configure SDLT for faster SERVICE DISCOVERY and service acquisition of DVB-I service.
  • Fig. 4 shows information included in the service list of Figs. 11, 19, 28, 39, 49, 56, 68 and the like.
  • Embodiments propose a method of constructing a Service Discovery List Table (SDLT) and a USBD as shown in FIG.
  • SDLT Service Discovery List Table
  • SDLT may be essential information to be possessed by a receiver first for service discovery. Through this signaling data, the receiver can provide service list information that allows the user to select a service, and at this time, the SDLT can be configured to include more information. Such configuration information has an effect of providing a rich quantity of services and enabling faster service play when a user selects a service.
  • USBD among the signaling metadata of Internet-based services includes a DeliveryMethod element value that provides information mapped with MPD, and @serviceId and @globalServiceId information are information for mapping with SDLT. And it can be used as information for mapping with ESG.
  • the service discovery list table (ServiceDiscoveryListTable) represents a root element.
  • SDLT Internet URL (SdltInetUrl) represents a URL for accessing signaling/ESG objects.
  • the URL type (@urlType) indicates the type of files available with this URL.
  • Service represents service information.
  • the service ID represents a number that uniquely identifies this service within the range of the original network ID (originalNetworkId).
  • a global service ID (@globalServiceId) represents a globally unique service identifier. This value is mapped to the global service ID in the ESG. For traditional DVB/T/S/C services, this attribute may not exist.
  • the original network ID (@originalNetworkId) represents a number that uniquely identifies the original network on which this service was originally created.
  • a transport stream ID (@transportStreamId) represents a number that uniquely identifies a transport stream. This attribute exists in traditional DVB-T/S/C services. However, this attribute may not exist for DVB-T service in ISO BMFF format.
  • the frequency number (@frequencyNum) represents a number uniquely identifying the frequency number of the physical layer. This attribute may exist in the case of a traditional terrestrial service.
  • the service category represents the category of this service.
  • a category can be linear, on-demand, or application service.
  • the service sequence number (@svcSeqNum) indicates the version of service information. This value can be incremented by 1 for each new version of service data in the RFG.
  • the content format (@contentFormat) represents the format of the contents of this service.
  • Hidden indicates whether this service is hidden in the service list or visible to users.
  • the default value for this value is FALSE.
  • App rendering indicates whether the application is running for the first time or rendering this service.
  • the default value for this value is FALSE.
  • the media presentation description (@MediaPresentationDescription) is a URL pointing to the MPD signaling description.
  • the application information table (@ApplicationInformationTable) is a URL pointing to the AIT signaling description.
  • the distribution window description (@DistributionWindowDescription) is a URL pointing to the DWD signaling description.
  • RunningStatus indicates the status of this service.
  • 5 shows an example of management of a channel according to embodiments.
  • Figure 5 shows the hidden element of Figure 4.
  • DVB-I When providing DVB-I service, there are two ways to select a linear channel. Users can select a channel number directly or channel can be selected through channel surfing. Considering the characteristics of the DVB internet channel, it is possible to receive unicast based on the HTTP network or provide a linear channel service in the form of multicast. DVB-I is different from receiving a broadcaster's channel of DVB and delivering it to an unspecified number of people through a dedicated frequency and a logical channel. Since the Internet is a subscription and streaming type, hidden / inactive channel management of the channel is required.
  • broadcasting network ATSC 1.0 can define channel management as follows.
  • Hidden This is a bool value indicating whether a logical channel is displayed or not displayed. It refers to the property of displaying or not displaying when a user searches for a logical channel or selects a direct channel entry.
  • Hidden guide A bool value that means displaying or not displaying a logical channel on the EPG, and refers to the user's channel guide display/non-display property.
  • This method is a channel management method based on the RF broadcasting environment, and it is inevitable to manually manage the channel only with the information in the service list.
  • a return channel exists, and various channel management methods may exist.
  • a user when a channel is hidden/inactive in a DVB-I environment, a user can determine the existence/state of a corresponding channel using a return channel, and a hidden/inactive channel of an existing broadcast can be detected through an alternative service. can facilitate management.
  • @Hidden (visible) This is a bool value that means whether the logical channel is visible or not visible. It means the attribute of not visible when searching for a user's logical channel or selecting a user's direct channel entry.
  • the hidden service can be selected by directly inputting the logical channel number. If false, the hidden service cannot be selected even if the user directly inputs it.
  • @hidden_guide When accessing a channel directly in the state of a hidden channel, it guides the state within the channel or can show a screen that can be replaced through a connection link. Indicates a type value indicating various types of channel guide methods.
  • Hidden This is a bool value that indicates whether a logical channel is displayed or not displayed. It refers to a property of displaying or not displaying when a user searches for a logical channel or selects a user's direct channel entry.
  • Selectable If set (Set), the hidden service can be selected by directly inputting the logical channel number. If false, the hidden service cannot be selected even if the user directly inputs it.
  • Hidden Guide When accessing a channel directly in the state of a hidden channel, it guides the state within the channel or can show a screen that can be replaced through a link. There may be a type value indicating various types of channel guide methods.
  • Hidden presentation Through hidden_guide, corresponding anyURI information is defined according to the defined type value.
  • the type is 0x0001, it indicates an alternative link of the service provider, and the hidden presentation may provide a connection address, for example, www.bbc.co.kr/alternative/music.
  • the hidden presentation can signal a DVB triplet, eg, DITS-(OriginalNetworkID)-(TransportStreamID)-(serviceID).
  • the hidden presentation can signal a DVB triplet, eg, DITS-(OriginalNetworkID)-(TransportStreamID)-(serviceID).
  • the type is 0x0004, it indicates an ESG or BCG (Broadband Content Guide) link, and the hidden presentation may signal loginformDB.html.
  • the type is 0x0005, it indicates an alternative app service, and the hidden presentation may signal an app-dedicated channel. Due to this, the receiving device can access the app using AIT.
  • FIG. 7 shows a flowchart of hidden channel management according to embodiments.
  • FIG. 7 is a flowchart for processing a channel based on a hidden channel related to FIG. 6;
  • step 41000 when power of the receiving device is activated, the receiving device checks whether the channel/service is hidden. If there is no hidden, the receiving device displays the viewable channels and the viewable channel guide on the display.
  • step 41010 if there is hidden and channel surfing is impossible, the receiving device checks selectable. If not selectable, the receiving device informs the user that the channel is inactive and that the channel guide cannot be viewed. If selectable is YES, the receiving device may alternately process/display the hidden channel based on the hidden guide and hidden presentation.
  • FIG. 8 shows an example in which a related material is included in SDLT according to embodiments.
  • Fig. 8 is the syntax of the SDLT related to Fig. 4 and the like.
  • the DVB-I service can provide an Internet linear channel and can provide a part-time service in a specific LCN in a service discovery process. Outside of this service state, in order to avoid confusion when a user selects directly through a channel number, an inactive service banner image or an additional application is displayed. Through this, a channel change API can be executed or an additional VoD service can be provided.
  • a hierarchy suitable for real practice is proposed by applying the datatype value used in the actual industry.
  • the SDLT of FIG. 8 may correspond to the SDLT according to the above-described embodiments, and the added elements/fields are described as follows.
  • @LCN represents the logical channel number
  • RelatedMaterial may further include the following elements.
  • a relationship (@HowRelated:href) can be passed along with an @href element passing a value.
  • a MediaLocator may deliver information about the location of media.
  • MediaURI can be a value including a URI for an XML AIT file or image, and @contentType can deliver this value.
  • Availability indicates the status of this service (running, not running or starts in a few seconds, etc.).
  • @ValidFrom represents the time/date on which this service becomes valid. If this value is not specified, it is known that this service is already available.
  • @Recurrence represents the weekly cadence of scheduled availability for this service. If this value is not specified, it indicates that a recurrence occurs every week.
  • the DVB-I service may provide an Internet linear channel and may provide a part-time service in a specific LCN during a service discovery process. Outside of this service state, in order to avoid confusion when a user selects directly through a channel number, an inactive service banner image or an additional application is displayed. Through this, a channel change API can be executed or an additional VoD service can be provided.
  • a hierarchy suitable for real practice is proposed by applying the datatype value used in the actual industry.
  • a receiver signals an actual valid time of a part-time service and checks an inactive period through attributes in ⁇ Availability> element.
  • the screen displayed in the LCN in the corresponding period can show the inactive state as an attribute defined in the element of ⁇ RelatedMaterial>.
  • @MediaURI is the same attribute as the hidden(visible)_presentation URI described above, and follows HbbTV(AIT) app signaling and app life-cycle as it is. When this value is omitted, it becomes inactive through the URI defined in @ ApplicationInformationTable. Alternative services may be provided.
  • the content_type of @MediaURI is "image/png"
  • an inactive service banner can be displayed.
  • images and app signaling can be provided as inactive services.
  • a receiving device may provide an inactive state based on an image (image/png) (banner) at http://img-ctv.digitaluk.co.uk/channel7/service_a_linear.png. can
  • FIG. 10 shows an example of utilizing an inactive banner according to embodiments.
  • FIG. 10 may be included in an example of channel management in FIG. 7 and the like.
  • the receiving device may display ESG 44000 on a display.
  • the receiving device may provide an alternative application such as a no service banner indicating no service in the current no service state (44010) .
  • the alternative application may be executed on the blank screen or the receiving device may receive a signal for the user to select the alternative application through a remote controller and execute an operation related thereto.
  • FIG. 11 shows a service list hierarchical structure according to embodiments.
  • Fig. 11 is a service list hierarchy for the service scenario of Fig. 1;
  • a DVB-I service list may include each service, and each service may include service instances. Multiple service instances can be defined according to each delivery network, and uniqueness can be distinguished according to the URN of the source_type.
  • the DVB service list type 45000 may refer to the DVB-I service type 45010 for each service.
  • the DVB-I service type 45010 signals a related material and a guide source.
  • the DVB-I service type 45010 may refer to the service instance type 45020 for each service instance.
  • the service instance type 45020 signals the subscription package for the related material and the source type for the URN. This may refer to at least one of a delivery parameter type for DVB T/S/C, an RTSP delivery parameter type, a multicast delivery parameter type, and a DASH delivery parameter type.
  • Suggested Source Type URNs 45030 provide URNs for DVB T/S/C/I [TV/DASH, etc.].
  • the DVB service list type 45000 refers to the LCN table list type
  • the LCN table list type refers to the LCN table type
  • the LCN table type, DVB service list type 46000, and DVB-I service type 45010 may refer to a region. Local information related to each service may be different.
  • the service list (ServiceList) is a list of locations and details of IP services provided by a service provider. Service providers can divide their services into multiple service lists. This attribute is required.
  • Name is the name of the service in a readable format.
  • a plurality of service list names may be expressed in different languages. This attribute is required.
  • the provider name (ProviderName) is the name of the provider of the readable service list. Multiple values of a provider can be described in different languages. This attribute is required.
  • the region list (RegionList) is a list of regional regions having a logical identifier used to provide services in the service list or regional information of the service list. This attribute is optional.
  • the target region (TargetRegion) is an identifier of regions described in the region list to which this service list is targeted. This attribute is optional.
  • the LCN Table List (LCNTableList) is a list of tables defining localized and packaged logical channel numbers for each service. This attribute is optional.
  • a Service is a service that forms part of a service list. This attribute is optional.
  • the version (@version) is the version number of the service list. The value is incremented for every published change. This attribute is required.
  • FIG. 13 shows DVB-I service types according to embodiments.
  • the DVB-I service type of FIG. 13 is a description of the above-described service type in the form of a table.
  • UniqueIdentifier is a unique ID of a service. This ID may never change for a single service. Other parameters of this service may vary. This attribute is required.
  • Service Instance An instance with A/V content for this service. If multiple elements of this attribute's type are present and available, the one with the lower value of the @priority attribute may have the higher priority (or vice versa). All service instances for a given service can have the same content. This attribute is optional.
  • the target region (TargetRegion) is a region where the service is received. If this value is not specified, no region constraints exist. This attribute is optional.
  • ServiceName is the name of the service. Service names can be described in a variety of languages. This attribute is required.
  • ProviderName is the readable name of the provider of this service. This element can be described in various languages and is required.
  • the material may include, for example, a service unavailable banner, service-related applications, service logos, and the like. This attribute is optional.
  • the service genre (ServiceGenre) is a genre of service. This value is optional.
  • the service type (ServiceType) is a type of service (see description of ETSI EN 300 468). This value is optional.
  • the recording information is information that informs the DVB-I client so that it can determine whether or not the content is to be recorded, time-shifted, or redistributed from this service. This value is optional.
  • a guide source is a detail of a broadband content guide that carries the metadata of this service. This value is optional.
  • the version (@version) is the version number of this service. The value is incremented for each published change. This value is required.
  • the DisplayName is the readable name of the service associated with the specific service location. Multiple service names can be described in a variety of languages. If this value does not exist, the service name field may be used. This attribute is optional. Meanwhile, in this specification, attributes may correspond to each other according to levels such as elements, fields, information, and values, and may be referred to in various ways.
  • RelatedMaterial is an additional material related to the service. Specifically, there may be a no service banner, a service related application, a service logo, and the like. A related material with a specific value of the HowRelated attribute provided in the service instance element replaces a corresponding related material with the value of the HowRelated attribute provided in the service element. This element is optional. Alternatively, you can obtain a property corresponding to @href sting in HowRelated.
  • the DRM system ID represents a content projection method used for a service. This value can be the same as the value of @schemeIdURI in document DVB A168. This value is optional.
  • Annex D.1.3.2 of ETSI TS 103 205 may be referred to for ContentAttributes. This value is optional.
  • Availability indicates the period when this service location is expected to be active. This value is optional.
  • SubscriptionPackage is a subscription package that includes this service. This value is optional.
  • FIA Content Management DVB-I service instances that do not use DRM deliver the FTAContentManagement element to define the content management policy for the service instance.
  • the semantics of each attribute can be described in a corresponding field of FTA_content_management_descriptor, which is a descriptor of document ETSI EN 300 468. This value is optional.
  • the SourceType identifies the primary delivery source for this service instance. This value determines the required delivery parameters. This value is optional.
  • DVBT Delivery Parameters are delivery parameters for DVB-T service.
  • DVBS delivery parameters are delivery parameters for DVB-S service.
  • DVBC delivery parameters are delivery parameters for DVB-C service.
  • RTSP Delivery Parameters are delivery parameters for RTSP-based services.
  • MulticastTSDeliveryParameters are delivery parameters for services delivered using multicast UDP.
  • DASH delivery parameters ( ) are delivery parameters for services using DVB DASH delivery.
  • SATIP Delivery Parameters are parameters that a DVB-I client supporting SATIP can use to receive a service instance from a SATIP server.
  • SourceType SourceType
  • the priority is the priority of this service instance over other service instances of the service. This value is optional.
  • UriBasedLocation Refer to Annex D.1.3.2 of ETSI TS 103 205 [2] for semantic definition.
  • MinimumBitRate Threshold bit-rate under which an alternative source for the same service should be preferred, if available.
  • DASH delivery parameters according to embodiments may be additionally extended for simulcast.
  • URI-based location may refer to Annex D.1.3.2 of document ETSI TS 103 205. This value is required. When the DASH service is simulcast, this value may provide location information based on the URI.
  • the minimum bit rate (MinimumBitRate) is the threshold bit-rate at which an alternative service for the same service should be prioritized. This value is optional.
  • the client may determine a service instance by considering each priority (@priority) and device capability.
  • @minimumBitrate means throughput in terms of a network stack capable of receiving a stream within a service instance.
  • the minimum bit rate (@minimumBitrate) may indicate throughput in terms of a network stack capable of receiving a stream in a service instance. That is, the device according to the embodiments may check the minimum bit rate at which the network can currently receive the DASH service through the minimum bit rate information.
  • the service instance may be determined whether the service instance is playable.
  • the currently defined information includes multiple service instances within DVBiservicetype, it is difficult for the client to select service instances with only @minimumBitrate information.
  • minimumbitrate for determining playability is a minimum condition
  • only satisfying the minimum condition does not satisfy the fallback condition between bitstreams.
  • a client related to the transmission/reception device is an HEVC UHD capable terminal, and the other
  • the receiver terminal
  • service instance 2 eg HEVC UHD
  • the attribute that a better quality stream is included is not known to the receiver.
  • Receiving and comparing all MPDs of all service instances is not only a burden on the receiver, but also may cause issues in rational network selection.
  • a method for providing a better service between instances within DVB service scheme information is proposed below. That is, it is possible to implement embodiments in which the receiver can quickly identify and request a better service instance in response to a network situation of a certain bit rate or higher without the burden of parsing/analyzing all MPD or similar signaling information on the receiver.
  • Fig. 16 shows a scheme for selecting a service instance based on DASHDeliveryParametersType according to embodiments.
  • the DASH delivery parameter type may include a comparison bitrate (ComparisonBitRate) and a comparison content attribute type (ComparisonContentAttributeType).
  • the comparison content attribute type may include an audio attribute element, a video attribute element, a caption language element, and a sign language element.
  • comparison content attribute type may correspond to a content attribute element included in the service instance type 45020.
  • the DASH delivery parameter type may include a comparison content attribute type (ComparisonContentAttributeType). Also, the comparison content attribute type (ComparisonContentAttributeType) may include a comparison bitrate (ComparisonBitRate) together with an audio attribute element, a video attribute element, a caption language element, and a sign language element.
  • a comparison content attribute type (ComparisonContentAttributeType) may include a comparison bitrate (ComparisonBitRate) together with an audio attribute element, a video attribute element, a caption language element, and a sign language element.
  • Comparison bitrate (ComparisonBitRate) and comparison content attribute type (ComparisonContentAttributeType), which are common elements in the first and second plans, may be as follows.
  • the comparison bit rate means a bit rate capable of handling a specific IP delivery service instance that provides a better user experience than non-IP delivery service instances available for this service.
  • the comparison content attribute type indicates which video characteristics are available for DVB-I clients that provide a better user experience than non-IP delivery service instances available for this service.
  • FIG. 17 shows an example of a DVB-I service instance according to embodiments.
  • DVB-S ServiceInstance It represents two service instances, 1 is DVB-S ServiceInstance and 2 is DVB-I ServiceInstance.
  • a service instance of 1 has a priority of 0, and the display name is ABC Drama. Audio attributes, video attributes, etc. are signaled as attributes shown in FIG. 56, and include DVBS delivery parameters.
  • the priority '0' may be an exemplary value.
  • the receiving device checks an additional service instance other than the corresponding service instance, it considers not only the priority value, but also the network state or available bandwidth, and the capabilities of the client.
  • a service that can provide a better service The instance may be provided to the user through signaling information according to embodiments.
  • a service instance of 2 has a priority of 1, and the display name is ABC Drama.
  • DASH delivery parameters may signal the address of https://live.daserste.de/0001 Das%20Erste.mpd ⁇ /dvbisd-base:URI for application/dash+xml type content through a URI-based location.
  • the minimum bit rate is 1M
  • the comparison bit rate is 7M.
  • the compare content attribute signals the video attribute via "urn:mpeg:mpeg7:cs:VideoCodingFormatCS:2001:2.2.2" and HEVC Video Main10 Profile @ Main Level ⁇ /tva:Name> (UHD capable).
  • the value of the comparison bit rate may be an exemplary value.
  • the receiving device (terminal, client, etc.) according to the embodiments checks the comparison bit rate value and knows that a better service is provided through this value. For example, when a better service corresponding to a value of 7M is provided, the method/apparatus according to the embodiments may additionally define the corresponding video attribute information as a comparison content attribute. Accordingly, the receiving device according to the embodiments may check the existence of the UHD stream and convert the stream to a service for comparison content attributes according to network conditions.
  • the DVB-I client When the receiver receives two instances of the same service (eg, ABC drama) within the DVB-I service scheme, the DVB-I client provides instances (instances) that can be provided for a better user experience. ) should be selected.
  • This property means beyond HD based on @ComparisonBitrate (7Mbps -HD), and means that an enriched service can be provided than a broadcast service instance.
  • bitrates of 1M BPS and 7M BPS may be exemplary values. This value may be a bit rate applied between services having relatively different resolutions, such as UD and UHD.
  • the use case is expanded as follows.
  • instance 1 means HD broadcast
  • instance 2 means UHD DASH
  • Instance 2 can be represented from SD to UHD and has a bandwidth of 1.5 Mbps to 33 Mbps, where the HD representation is 7 Mbps, the minimum bit rate is 1.5 Mbps and the comparative bit rate is 7 Mbps.
  • a player capable of supporting UHD according to embodiments may select instance 2 when the bit rate is 7 Mbps.
  • a player that does not support HEVC according to embodiments and can support HD selects instance 1.
  • a player capable of supporting UHD having a 5.5 Mpbs wifi link selects instance 1.
  • a UHD capable player with a 1 Mbps capable 3G mobile connection that does not receive a broadcast report does not have a fast enough connection to play the service, but may attempt to play the service.
  • a player capable of supporting UHD having a 4G mobile connection capable of 2 Mbps and not receiving a broadcast according to embodiments may select instance 2.
  • Numeral 57000 represents a state in which a receiving device according to embodiments displays a DVB-T broadcast service
  • 57010 represents a state in which a receiving apparatus according to embodiments displays a DVB-I service
  • 14 shows a state in which a better user experience is provided to the user according to the user's selection and/or characteristics of the receiving device based on the signaling method and UI/UX method according to the embodiments of the same service.
  • 57020 is an example of the above-described signaling information for this purpose. This corresponds to the aforementioned service list.
  • a service list according to embodiments may provide service instances for each service.
  • the services of 57000 and 57010 have logical channel number 6 and include service instance 1 and service instance 2.
  • Service instance 1 signals a DVB-T (HD) service as in 57000
  • service instance 2 signals a DVB-I (UHD) service as in 57010.
  • HD DVB-T
  • UHD DVB-I
  • a device capable of receiving a DVB-I service when a device capable of receiving a DVB-I service receives one or multiple service instances, it is determined to provide a media service of better quality based on the included comparison bitrate value and comparison content attribute value. can do.
  • a service instance with a possibility of receiving a better service can be quickly distinguished through IP/DASH.
  • a delivery type can be selected with the above information.
  • the receiving device receiving service instance 1 and service instance 2 provides a better DVB-I UHD service based on the comparison bitrate value and the comparison content attribute value included in the service instance for DVB-I. You can immediately check whether you can do this without parsing all other signaling information for all services.
  • the receiving device can know through comparison content attributes that the comparison bit rate is 7 Mbps and the resolution of the better service is UHD (HEVC).
  • the receiving device may ask the user whether to view a better service based on the UI/UX.
  • the service according to instance 2 may be provided to the user according to the user's selection or the setting of the receiving device.
  • a receiving device may provide a DVB-I simulcast service UI/UX to a user.
  • FIG. 57 UI/ that provides a better experience to a user when a DVB-I client receives multiple service instances through extended information according to the above-described embodiments I mean UX. If the UE is capable of supporting UHD/HEVC, it is possible to select a DVB-I service instance capable of receiving UHD rather than a DVB-T service instance capable of receiving HD. The UE does not need to receive all DASH MPDs, and can select a high quality service instance through only the service list scheme.
  • Signaling information may be variously referred to as fields, attributes, elements, first information, second information, first values, and second values.
  • Embodiments may initialize an MPEG-2 system/DVB SI-based service for Internet channel scanning capable of providing the same user UX as an existing linear service channel.
  • Embodiments are capable of network/stream/service unique signaling for Internet stream identification in order to integrate with an existing linear channel.
  • Embodiments may extend a method capable of replacing a TSID within existing system information.
  • Embodiments enable switching of each bit-stream provided by a DVB network and a DVB-I channel provided within the same dedicated channel.
  • Embodiments may provide SUHD (8k) linkage through a DVB-I channel in SD, HD, and UHD linkage services provided by existing channels.
  • Embodiments may obtain a DVB-I service list in an existing DVB network.
  • Embodiments may add a service bootstrap technology of an existing linear channel network to provide a linear IP based TV service.
  • Embodiments add unique information that must be defined for Linear IP based TV service identification.
  • Embodiments may add an IP based TV channel to an existing linear channel EPG.
  • Embodiments can simultaneously provide an existing DVB stream and a DVB-I stream within the same dedicated channel, and dynamically change the stream during a certain period.
  • Embodiments may provide SUHD (8k) linkage through a DVB-I channel in SD, HD, and UHD linkage services provided by existing channels.
  • Embodiments may extend linkage information for obtaining a DVB-I service list or query end point in an existing DVB network.
  • Embodiments may extend a service bootstrap scheme of an existing linear channel network to provide a Linear IP based TV service.
  • Embodiments may provide linkage between an existing DVB network and a DVB-I network at a bouquet level, service level, and event level based on DVB-SI information.
  • Embodiments can provide contents of various resolutions in the same logical channel through linkage information of the existing DVB network and the DVB-I network.
  • Embodiments may define a DVB-I service list location and a query through a linkage descriptor (uri_linkage_descriptor) to obtain a DVB-I service list in an existing DVB network.
  • uri_linkage_descriptor a linkage descriptor
  • Embodiments may access an open DVB-I service registry through an end point and obtain a service list entry list suitable for a client. .
  • Embodiments enable a service that is accessed through a UI in which an existing linear service and an OTT service are integrated in a device supporting an RF-based DVB tuner.
  • Embodiments can provide a media service that provides the same UX as existing linear channels through open internet without a set-top box (STB).
  • STB set-top box
  • Embodiments can expand the resolution that can be provided within the same channel as the existing DVB network and Internet channels are integrated.
  • the DVB-I service list location can be signaled.
  • a receiving device may efficiently obtain a DVB-I service list. Also, due to the endpoint according to the embodiments, the receiving device according to the embodiments can efficiently obtain a service list.
  • a terminal can obtain a service list in which all channels are integrated.
  • the integrated service list may include an entire list, a list desired by the receiving device, and the like.
  • the individual list may be a list of services for each broadcaster.
  • DVB-I integrated receiving environment
  • simulcast can be performed through communication networks including terrestrial, cable, satellite, and 5G, and the receiver can receive the desired service depending on the receiver capability.
  • This process may be implemented through ComparisonBitrate and/or ComparisonContentAttribute.
  • the MPD may include a plurality of representations and may include both UD and UHD related information.
  • the receiving device has a heavy burden and time required to parse all information of the MPD.
  • the receiving device can selectively and quickly decode optimized services and rich media according to the capabilities of the receiving device.
  • the receiving device can know that services having different capabilities exist through ComparisonBitrate. ComparisonBitrate may be a concept of minimum throughput. Furthermore, there is an effect that the receiving device can know what the concrete attribute of the switched service is through ComparisonContentAttribute.
  • Fig. 19 shows a DVB-I service list hierarchy according to embodiments.
  • a transmitting device generates and transmits a service list to a receiving device, and the receiving device provides a DVB-I media service to a user based on the service list.
  • the transmitting device generates service information according to embodiments, and the receiving device obtains service-related information (eg, service list information, content guide information, etc.) using the service information according to embodiments.
  • service-related information eg, service list information, content guide information, etc.
  • each service may include service instances through unique information of service_ID. That is, one Parents element of Service_ID can define multiple Service instances classified according to delivery network.
  • the transmitting device can define and transmit instances of DVB-T and DASH when the Internet and the existing DVB network are simultaneously connected. For a service including each service instance, the transmitting device creates a DVB-I service content guide to be provided to the user.
  • a receiving device can receive a program guide currently in progress by defining specific information of a program (event) corresponding to a specific schedule (timeslot).
  • DVB-I service reception is basically a pull-only mode based on HTTP 1.1, and each client downloads content guide information currently being consumed according to the client's own polling algorithm, and then displays it through appropriate UX/UI.
  • a receiving device may download the DVB-I service content guide by the following method.
  • a receiving device When a receiving device according to embodiments requests a content guide from a content guide server (transmitting device), it requests and receives data using the following API endpoints. “” is given an API_endpoint_URL as shown in FIG. 20 and updates necessary information to the corresponding address.
  • the basic structure is as follows, and there are timestamp filtered schedule request and now/next filtered schedule request according to time span.
  • a specific time span of the ScheduleEndpoint is defined, and query information is defined as follows.
  • service_id represents a service ID (a single decimal Service ID) determined by the receiving device (client device).
  • variant can optionally represent an image variant.
  • the current/next filtered schedule endpoint represents query information.
  • FIG. 21 illustrates a DVB-I client over-running issue according to embodiments.
  • An over-running issue may occur between a broadcast signal reception device (client) and a broadcast signal transmission device (server unit, broadcaster, etc.) according to embodiments as follows.
  • a broadcast signal receiving device (DVB-I client) according to embodiments currently polls according to its own client criteria, updates content guide data with the latest information, and provides user information.
  • show to Live broadcasting of the DVB network provides content guide data in the form of a push through a broadcast network, but DVB-I is a pull-only mode and is refreshed at regular intervals. update the latest information
  • a broadcast signal receiving apparatus receives a program according to DVB-I service availability according to service discovery information according to embodiments according to the DVB-I client content guide timeline (59000). (event) can be played.
  • a program (or event, 59010) according to embodiments has a start time 59020 and an end time 59020.
  • An event according to embodiments may mean aperiodic sparse media-time related auxiliary information for a client or a receiving device according to DASH definition.
  • a broadcast signal receiving apparatus (DVB-I client) requests content guide data to the transmitting apparatus every expiration time window (59050) based on the DVB-I client polling interval (59030) (59040). )can do.
  • DVB-I service can show It is a diagram showing the DVB-I content guide information according to the polling interval and the progress status of the live program being actually consumed.
  • a client may tune-in or switch channels.
  • an issue occurs indicating data related to Event 2 according to the scheduled end time (actually, the receiving device is playing Event 1).
  • the client periodically updates the content guide through one request (59040), but if over-rubbing occurs in the end-time section, a phenomenon in which the currently playing-out screen and the UI information of the channel banner do not match occurs.
  • cache-control and max-age header related to the expiration time in the predefined HTTP do not consider the time span for over-running.
  • the embodiments propose methods for updating the latest information in a DVB-I receiver based on a pull-only mode.
  • FIG. 22 shows a method for solving the problem of FIG. 21 by a transceiver according to embodiments.
  • a broadcast signal reception device may maintain an up-to-date state based on operation 600000.
  • a broadcast signal receiving apparatus may receive a DVB-I service and check service availability in progress through ⁇ Availability> in a service instance. Accordingly, the progress of the service can be checked according to the service window defined in the service availability.
  • the polling cycle of a specific section can be adaptively changed through the ⁇ pollingInterval> value in the existing polling method performed by the client itself.
  • the receiving device performs polling in a manner determined according to the service window, and then dynamically polls from around the end of the event/program every polling period (600040) during a specific dynamic polling period (600030). there is.
  • the receiving device determines the over-running period (600030) and the polling period (600040).
  • a content guide for event 1 in which rubbing is reflected can be provided to the user along with event 1.
  • the entire dynamic polling period (600030) and the polling period (600040) may be set for a certain period (600060) from before the expiration of event 1 to after the start of event 2.
  • Such a dynamic polling interval can prevent erroneous content guide information generated during over-running and provide up-to-date information.
  • 60 shows an operation of resolving an over-running issue by adaptively switching the polling period of a specific section and applying a dynamic polling interval. As an algorithm that can solve the over-running issue, the following information is required.
  • Standard timing information to apply dynamic polling interval It can indicate the entire interval to which dynamic polling is applied.
  • the reference timing information may represent, for example, a point indicated by an offset of x sec from DVB-I service availability end time.
  • Newly applied polling interval Indicates how often dynamic polling will be polled within the entire interval.
  • Version information for comparison with existing information This may be version information indicating dynamic polling compared to its own client polling interval.
  • the reference timing information to which the dynamic polling interval is to be applied indicates an interval to which dynamic polling is applied.
  • the offset by x sec from the standard timing information e.g. DVB-I service availability end time
  • the polling interval to be newly applied may be @ minimumMetadataUpdatePeriod according to embodiments.
  • the information is for dynamic polling through version information for comparison with existing information.
  • Fig. 23 shows the scheme of the operation of Fig. 22
  • the transmitting device Indicates the DVB-I service scheme.
  • the transmitting device generates service list information and transmits it to the receiving device, and the receiving device may provide content to the user based on the service list information.
  • the transmitting device generates service information, and the receiving device obtains service-related information (eg, service list information, content guide information, etc.) using the service information.
  • service-related information eg, service list information, content guide information, etc.
  • the receiving device may update metadata for content at a predetermined period and period based on a minimum metadata update period (MinimumMetadataUpdatePeriod) and a duration.
  • MinimumMetadataUpdatePeriod a minimum metadata update period
  • the receiving device may update metadata for content during a predetermined period based on a minimum metadata update period (MinimumMetadataUpdatePeriod) and a minimum metadata period type (MinimumMetadataUpdatePeriodType).
  • MinimumMetadataUpdatePeriod a minimum metadata update period
  • MinimumMetadataUpdatePeriodType a minimum metadata period type
  • the receiving device may update metadata based on MinimumMetadataUpdatePeriod and MinimumMetadataUpdatePeriodType according to the content guide source type.
  • the transmitting device may independently transmit polling related information together with version information to the receiving device, may transmit polling related information together with a content guide source type, and may transmit polling related information together with an LCN table entry type.
  • the receiving device may obtain a polling interval and duration, a dynamic interval period offset, and an integer value according to MinimumMetadataUpdatePeriodType, transmit a query for dynamic polling to the transmitting side, and receive response information for the query.
  • the transmitting device may create MinimumMetadataUpdatePeriod at various locations on the service list and transmit it to the receiving device, and the service discovery operation of the receiving device may vary depending on the location of MinimumMetadataUpdatePeriod.
  • MinimumMetadataUpdatePeriod may have various positions and hierarchies, such as being included in a service list, included in a service, or included in a content guide.
  • DVB-I Client can solve the aforementioned issue through "PollingIntervalType", and the corresponding type can be defined in service type level and ContentGuideSourceType. This solution can check and query the latest information with the following procedure.
  • FIG. 24 shows a DVB-I service hierarchy according to embodiments.
  • a service list according to embodiments may have a hierarchical structure.
  • a transmitting device generates a service list having a hierarchical structure according to embodiments and transmits the service list to a receiving device, and the receiving device provides a media service to a user based on the service list according to embodiments.
  • the transmitting device generates service information, and the receiving device obtains service-related information (eg, service list information, content guide information, etc.) using the service information.
  • service-related information eg, service list information, content guide information, etc.
  • the receiving device determines the availability start time and end time of the currently ongoing service (or program, event) through service instance level availability values. Check the state of the service.
  • the receiving device uses the existing static ( A new content guide through a dynamic request and response through a polling interval (@PollingInterval) value without static content guide polling (59040, see FIG. 60) Data (content guide data) can be updated.
  • the receiving device dynamically polls the transmitting device (server, processor, etc.) for content guide information every 1000 time units.
  • the version of static polling of the receiving device is 10
  • the version of dynamic polling may be expressed as 11.
  • the value of the version may have various values according to embodiments
  • 25 illustrates a method for updating DVB-I service scheme and content guide latest information according to embodiments.
  • a DVB-I service list discovery schema according to embodiments is shown.
  • a receiving device may use such a schema to update the latest information of the content guide.
  • DVB-I Service List Discovery schema includes service list provider information and @ServiceListURI that can obtain service list according to service list entry points (ServiceListEntryPoints).
  • the receiving device initializes the DVB-I service to obtain a service list, performs an HTTP request/response reception process through service list address information (@ServiceListURI), and stores the received service list.
  • DVB-I service initialization, service list, and content guide can be updated through the corresponding execution process.
  • the DVB-I service list scheme Hierarchy supports an operation of receiving service list metadata through a minimum metadata update period (@MinimumMetadataUpdatePeriod).
  • multiple DVB-I service lists and individual service lists may include multiple services or services. Each single service can be assigned to a service instance according to its delivery source.
  • the content guide is content guide information for the entire service list including each service, and can be defined through a content guide source list (ContentGuideSourceList).
  • a content guide source (ContentGuideSource) may be defined for each single service.
  • the max-age header indicates the expiration period of the low layer of the HTTP level. It does not reflect the content on the actual DVB-I client or updates on the UI. Therefore, @MinimumMetadataUpdatePeriod, an algorithm to indicate issues such as over-running or up-to-date information at the DVB-I standard DVB-I client code level is required.
  • the service list update and corresponding operation in the receiver of the content guide may be different.
  • Fig. 26 shows a model of a DVB-I client according to embodiments.
  • a structure of a receiving device (client) according to embodiments and a structure between devices associated with the receiving device are shown.
  • the receiving device 690000 obtains service-related information (eg, service list information, content guide information, etc.) by using the service information.
  • service-related information eg, service list information, content guide information, etc.
  • the receiving device 690000 is a receiving device (client) according to the embodiments described herein.
  • the receiving device includes the following components, and each component corresponds to hardware, software, processor, and/or a combination thereof.
  • the DVB-I service selection UI control unit 690010 controls the service selection related UI of the reception device 690000. Necessary data may be exchanged with the service list manager 690020 and the content guide UI control unit 690040 for UI information related to service selection.
  • the service selection UI control unit 690010 may receive source data for the service selection UI from the source selection UI control unit 690070.
  • the service list manager 690020 controls service list information.
  • the service list manager 690020 may receive service selection UI information for a service list from the hybrid service selection UI control unit 690080 and exchange data related to the service list.
  • the service list manager 690020 may exchange service list data and/or service information with the service player 690030.
  • the service list manager 690020 may exchange service list information and/or content guide information with the content guide manager 690050.
  • the DVB-I service player 690030 controls service play.
  • the service player 690030 may provide services to the DVB-DASH player 690090, the secondary OTT player 690100, and the linked application engine 690110.
  • the linked application engine 690110 may be an application that provides a service under the control of the linked application manager 690060.
  • the DVB-I content guide UI controller 690040 controls a content guide related UI.
  • the service selection UI control unit 690010 and the content guide manager 690050 may exchange service selection UI-related data, content guide UI-related data, and content guide control-related data.
  • the content guide manager 690050 controls content guide processing of the receiving device.
  • the service list manager 690020 and the hybrid content guide UI control unit 690120 may exchange service list related information, content guide control information, and hybrid content guide UI related information.
  • Hybrid refers to a unit that supports integration between a DVB-I network and existing terrestrial, satellite, cable, and IPTV broadcasting services.
  • the linked application manager 690060 controls service play of applications of additional devices that may be linked with the receiving device.
  • the DVB-C/S/T/IPTV content guide control unit (690130) provides content guide information for receiving devices for services of the DVB cable network, satellite network, terrestrial network, and IP network to the hybrid content guide UI control unit (690120). .
  • the DVB-C/S/T/IPTV service list manager 690140 controls service list information for services of the cable network, satellite network, terrestrial network, and IP network.
  • the hybrid service selection UI control unit (690080) DVB-I service and cable network, satellite network, terrestrial network, and IP network service list-related information for hybrid can be exchanged.
  • the DVB-C/S/T/IPTV tuner 690150 receives broadcast services such as terrestrial, satellite, cable, and IPTV.
  • the tuner 690150 may exchange information for a service list with the service list manager 690140.
  • the receiving device 690000 may provide a service list, content guide information, and the like for the DVB-I service to the user based on embodiments.
  • the receiving device 690000 provides DVB-I service and service guide information, and optionally connects with a tuner that receives services of cable network, satellite network, terrestrial network, and IP network, thereby providing cable network, satellite network, terrestrial network, and IP Network services and service guide information can be provided to users.
  • Embodiments for maintaining the up-to-date state of the DVB-I client (690000) will be described. Depending on the options according to the embodiments, the operation of the receiving device may be variously changed.
  • the minimum metadata update period (@MinimumMetadataUpdatePeriod) in the service list is a polling period capable of updating information of the entire DVB-I service list including services.
  • a DVB-I client service list manager (690020) included in the receiving device (690000) may manage the entire service list and update the service list.
  • the max-age value is static, and the expiration period is calculated.
  • the service list can be updated.
  • a query can be sent to the service list address (@ServiceListURI) defined in ⁇ DVB-I Service List discovery scheme>.
  • the changed service list information is delivered through a content guide manager (670050), and an update cycle of the content guide can be dynamically set.
  • the minimum metadata update period (@MinimumMetadataUpdatePeriod) in the service is a polling period that can update service information and content guide source (ContentGuideSource) of a DVB-I single service.
  • a DVB-I client service list manager (690020) of FIG. 69 included in the receiving device 690000 may manage individual service information and update of individual services.
  • HTTP Cache-Control sets the max-age value to static and calculates the expiration period. If the minimum metadata update period (@MinimumMetadataUpdatePeriod) value is defined, the service list update is updated.
  • HTTP Cache-Control for @ServiceListURI defined in ⁇ DVB-I Service List discovery scheme> can dynamically set and change query cycle of service list through @MinimumMetadataUpdatePeriod value regardless of max-age value. there is.
  • polling is performed dynamically in a specific section by using the @ContentGuideSource HTTP endpoint of the content guide corresponding to each service.
  • @MinimumMetadataUpdatePeriod which defines ContentGuideSource within a service, is a polling period that can update ContentGuideSource of DVB-I single service.
  • the DVB-I content guide manager (690050) dynamically polls in a specific section by using the HTTP endpoint in the @ContentGuideSource of the content guide corresponding to each service according to the defined @MinimumMetadataUpdatePeriod value.
  • the end time of currently serviced data may be 12345. If there is no over-running issue, the receiving device may receive and reproduce next service data from the reference point in time 12345 according to a predetermined schedule.
  • the receiving device may perform an update operation for receiving metadata including content, a list of services, and guide information for every set update period value of 1000.
  • a version may indicate an update or polling operation. If the version is changed from 1 to 2, it may indicate that the version is changed from static polling to dynamic polling.
  • the receiving device may receive a service and/or service information indicated by the unique identifier korea123.
  • the transmitting device may generate a corresponding LCN table list (LCNTableList) in each service list and logical channels in the LCN table (LCNTable) according to the DVB-I service list hierarchy.
  • the transmitting device may provide an LCN channel for each service by connecting a service reference (@serviceRef) included in each LCN table entry type (LCNTableEntryType) with a unique identifier (@UniqueIdentifier) of each service.
  • LCN channels connected to each service may define selectable/visible properties according to channel properties.
  • the content guide manager (690050) and the service list manager (690010) store the LCN channel of the client (DVB-I client) in the channel database through a series of parsing and caching processes. (DataBase). In addition, channel information is directly provided to the user through the UI.
  • the DVB-I content guide UI control unit indicates that the corresponding channel (eg, a channel for DVB-I) supports dynamic polling in the channel DB.
  • the corresponding channel eg, a channel for DVB-I
  • indication can be made based on a boolean attribute of dynamic (@dynamic).
  • the DVB-I LCN DB can notify in advance that a change may occur in a specific section with a channel on which the LCN corresponding to a specific service can perform dynamic polling.
  • the DVB-I client can create an interface that can update only a specific channel in the cached channel DB, and can reflect the updated channel information to the UI through dynamic polling.
  • a channel DB, an LCN DB, and the like may correspond to a media processing device connected to a processor.
  • FIG. 27 illustrates a method of obtaining the latest content guide information for each DVB-I service according to embodiments.
  • both methods receive information according to the following methods.
  • @ScheduleInfoEndpoint can be defined in the same way in ContentGuideSourceType. That means, the endpoint that can receive at the service list level and the endpoint that can receive at the service level have a limit that must be defined identically. Therefore, the service list and the service level must be identically defined in the receiving section.
  • ContentGuideSouceList - ContentGuideSource - ContentGuideSourceType - ScheduleInfoEndPoint is equally defined in service list and service, so there is a limit to receiving the same information.
  • Fig. 29 shows a flow chart of DVB-I service initialization and content guide update according to embodiments.
  • FIG. 29 is a diagram illustrating service initialization and content guide initialization and update processes between a DVB-I service server and a DVB-I client.
  • the DVB-I service discovery process -> Service list acquisition process -> DVB-I streaming initialization process -> Content guide initialization process can be applied through the current schema.
  • the current stage since updates to individual events and individual periods cannot be supported with the same content guide update, there is a limitation that only the previously defined time window intervals can be equally applied to the service list level or service level. Therefore, we propose a method for extending the DVB-I service scheme for the request and response process.
  • a DVB-I client is an endpoint for requesting content guide metadata between individual periods for each service, and can receive IndividualPeriodEndpoint.
  • the client can create the following string through IndividualPeriodEndpoint and request metadata information for each section.
  • Corresponding information for each service may be generated and data of an individual section may be requested through the corresponding information.
  • each interface represents a series of processes for a DVB-I client to receive service discovery and media streams corresponding to each service.
  • the description of each interface is as follows.
  • a receiving device may perform a DVB-I service list discovery operation and a registry entity access operation to provide the effects of the above-described invention
  • a transmitting device may perform a DVB-I service list discovery operation and a registry entity access operation. It is possible to provide multiple service lists signaling method so that
  • DVB-I client A DVB-I client, which corresponds to a media data processing device according to embodiments.
  • Service List Registry A list of service list servers can be provided to clients. List provisioning may be performed based on query parameters.
  • Service List Server(s) A server that delivers service lists to clients.
  • a separate service list server can aggregate service list fragments from multiple content and service providers.
  • Content Guide Server(s) Can respond to requests from clients for content guide data.
  • Content guide servers for individual DVB-I services may be referenced in the service list entry for the service.
  • Content / Service Provider(s) Can provide DVB-I services.
  • Playlist Server(s) can provide playlists for services that refer to playlists of DVB-DASH content items rather than directly referencing a single DASH MPD.
  • MPD Server(s) may provide DASH MPDs.
  • Stream Server(s) can provide DASH media segments to DVB-I clients.
  • Multicast Server Server for adaptive bitrate multicast.
  • Multicast Gateway A gateway for adaptive bitrate multicast.
  • A1 Content guide query: This is a content guide query. It means a request from a DVB-I client to a content guide server.
  • A2 This is content guide data.
  • Service list query This is a request from the DVB-I client to the service list server.
  • a DVB-I client can request a full list of services.
  • the service list can be locally filtered or an already filtered list.
  • C1 A request for a playlist. It can be an HTTP GET request.
  • D1 Rechesk for DASH MPD. It can be an HTTP GET request.
  • D2 DASH MPD: DASH MPD according to the ETSI TS 103 285 standard.
  • E1 Rechest for media. It can be an HTTP GET request.
  • E2 Unicast DASH: According to ETSI TS 103 285 [1].
  • F1 This is a request for determining the entry point(s) of the service list server(s). This request may support a query to perform a selection within service list discovery.
  • F2 A list of service list entry points matching the request criteria.
  • N1 Content guide data.
  • N2 URLs of content guide servers. URLs for content included in the corresponding service list entry for the service of interface O and content guide data for each of the services of the service providers
  • P2 URLs for playlists. URLs to playlists included in the corresponding service list entry for the service on interface O.
  • Q2 URLs for DASH MPDs included in a playlist for a service of interface P1 or a service list entry for a service of interface O.
  • R URLs for media. URLs for media included in DASH MPDs.
  • X Can be a Pin' or Oin interface in the DVB A176 standard. This is information related to the flow of DASH media data to the multicast server.
  • Y1 Multicast. It may be an interface M within the A176 standard. It may be flow-related information of DASH media data on multicast.
  • Y2 Unicast repair.
  • a flow diagram of DASH media data on unicast for repairing lost data from interface Y1 is related information. It may be interface U in DVB A176 standard document.
  • a DVB-I Client which is a media data processing device according to embodiments, may correspond to a DVB-I Player, a TV device, a 2nd device, and the like.
  • the F1 and F2 interfaces receive service discovery and service list entry points as a response thereof.
  • a DVB-I client may propose a selection of service list servers and may aggregate service lists from multiple service list servers.
  • the DVB-I client can provide selection of service list servers and can aggregate service lists from multiple service list servers.
  • the F1 and F2 processes that the DVB-I client accesses for the first time after installation and shows the list of lists to show the Service list Servers can be as follows:
  • the manufacturer of the device running the DVB-I client may provide such devices.
  • a third-party service list aggregator 5.
  • DVB-I CSR DVB-I service list providers or service providers
  • a list of registered lists can be shown according to the acquired information. Users can select and directly handle service lists through filtering criteria such as user preference and country/language/region based on the list of registered lists.
  • FIG. 33 illustrates a DVB-I service architecture for supporting a manufacturer service list according to embodiments.
  • FIG. 23 A diagram of a service discovery architecture supporting this is shown in FIG. 23.
  • Each component of FIG. 23 may correspond to hardware, software, processor, and/or a combination thereof.
  • Manufacturer service list repository support service discovery entity extension (Manufacturer service list repository support service discovery entity extension)
  • DVB-I service architecture which includes a DVB-I client, service provider, streaming server, CSR, and service list provider repository.
  • the role of each module and the operation of the receiver are as follows.
  • DVB-I client Consists of system client and DASH engine.
  • System client merges and curates multiple service lists through service bootstrapping, service list discovery, and service manager. In addition, it manages allocated Channel DB within each service list, and performs content guide and app launching.
  • DASH engine receives HTTP and DASH delivery and performs decoding and rendering.
  • Service provider Entities that can provide content, such as Disney, Fox, Netflix, OTT companies such as Hulu and Amazon Prime, MNOs, IPTV operators, and individual channel operators, provide content to list providers.
  • service list provider repository List providers curate lists and register them in the DVB CSR.
  • CSR This is the initial bootstrapping location of the DVB-I client, where the list of lists is managed.
  • Mfr also operates a repository to manage lists and registers lists in DVB CSR.
  • DVB-I service discovery query When DVB-I service discovery query is sent to CSR, CSR provides the following DVB-I service discover data and ServiceListURI. DVB-I client receives service list by accessing https://dvbi.TVfromTheWorld.com/engTVservices.xml.
  • DVB-I service discovery query When DVB-I service discovery query is sent to CSR, CSR provides the following DVB-I service discover data and ServiceListURI.
  • DVB-I client receives service list by accessing via https://www.LgChannels/dvbmfr/UK/servicelist.xml.
  • DVB-I service discovery information is composed of the following information, and each service list entity may be defined.
  • DVB-I service list discovery scheme can define service list registry and provider offering information that provides service list as above. As shown in Figure 18, when providing service as a separate mfr-only service provider entity, the offering information of mfr and the information asking whether the service list provided by mfr can be received must be extended during service discovery. It is necessary to expand the capabilities information that can check whether the Mfr service list can be supported. The syntax shown in FIG. 35 can be extended by utilizing Extension in the current DVB-I service list discovery scheme.
  • 35 illustrates the syntax of a service list registry entity according to embodiments.
  • OSName Supported OS version and name
  • ServiceCode Supportable service code within the device
  • TargetLocation The target location where the device was created Ex) UK, Nordic
  • Sourcelocation The location of the streaming server that provides each service
  • ServiceReport issue or consumption report of service list
  • UpdateLocationURL Accessible URL for firmware update
  • ServiceAvailabilitySearchURL A URL that moves to a web page where services can be searched so that additional services provided by the service list provider can be added.
  • ServiceAvailabilityDBUpdateURL Link URL for service data base update.
  • the schema to support XML update based on IETF RFC 5261 is downloaded, and fetching is possible through the information.
  • 36 illustrates semantics of a service list registry entity according to embodiments.
  • a media data processing apparatus may display service list related information as shown in FIG. 37 .
  • the service list may be selected based on a provider, language, genre, country, and the like.
  • a service discovery entity supporting a manufacturer service list repository may be added, and a specific manufacturer service list may be filtered through a provider. As in the embodiment, the UK supported LG channels service can be consumed.
  • 38 illustrates a method for responding to a channel collision when receiving a multiple service list according to embodiments.
  • DVB-I receives services based on service lists, and each service list is operated and managed in a specific repository.
  • the repository providing the existing DVB broadcasting list can define the DVB-I service list by taking a method of allocating LCNs based on countries or specific regions due to the characteristics of current European broadcasting services.
  • specific DVB-I service list providers collect independent services regardless of region and define LCN list, LCN allocation can be set arbitrarily by service list provider. Therefore, under this background, a potential issue of channel collision exists when a DVB-I client receives and merges multiple service lists.
  • Use case 1 classifies the service list, each service ID, the LCN to be allocated by the service list, the LCN used in legacy TV, and the actual contents.
  • use case 1 when different lists List A and List B are received, both Sid/LCN are equally assigned and the contents are the same, so when merging the four service lists, the service can be provided without any issues.
  • Case 2 is a case of multiple service providers + different service IDs + the same LCN, where different services are assigned to one LCN and collide.
  • Case 3 is DVB-T + multiple service providers + same service ID + different LCN.
  • DVB-T and List A a hybrid environment and multiple service providers are assigned the same service ID, but service list C uses the same LCN This can happen when assigning.
  • Case 4 can occur when multiple service providers + different service IDs + the same LCN, when the local country/region service list and the immigrant's home country list are integrated.
  • the media data processing apparatus can perform reasonable allocation without LCN collision.
  • An integrated service manager that receives and integrates DVB-I service lists according to embodiments performs service list integration work.
  • the specific XML xsd is as follows.
  • a transmission/reception method/device may solve a channel collision issue when receiving a multiple service list based on element(s) included in the following LCN table.
  • a transmitting device may generate and transmit information including element(s) included in the following LCN table, and/or DVB-I included in (or connected to) a receiving device according to embodiments.
  • An integrated channel can be allocated and managed through an integrated service manager (which can be variously referred to as a manager or controller) that receives and integrates service lists.
  • the processor may control the service list integration operation based on a memory storing instructions related to an integrated channel assignment operation according to embodiments, a controller, and the like.
  • an LCN table may be referred to as LCN information and the like, and elements included in the LCN table may be referred to as first information and second information.
  • the priority of the service list is set to the region or country selected by the user for the first time, or geographically, the region at the time the current DVB-I client is installed is given priority. When integrating additional services, it is considered as a later priority.
  • the receiver can store the corresponding list as a priority list and manage the list received later.
  • the DVB-I client can use this information to give the user channel allocation guidelines, and can directly reassign channel numbers according to the user's intention.
  • a user living in Switzerland receives service list 1, which is a Swiss service list, and a DVB-I client receives an additional list of service list 2, the ServiceRef information associated with the unique identifier within each DVB-I service and displayed on the screen Receive channel number.
  • 41 shows an example of resolving a service channel collision according to embodiments.
  • the DVB-I client can solve the channel collision issue by newly allocating the issue generated in service list 2 (channel 0, Sid23) to 1000.
  • collision channels may reallocate collision channel numbers through SecondaryChannelNumberRange information. As shown in the following result, collision channel numbers 100 to 108 can be newly allocated starting from number 1000 according to SecondaryChannelNumberRange.
  • channels can be assigned to empty numbers during a specific interval as defined in SecondaryChannelNumberRange.
  • channel number ordering is assigned to an empty channel within SecondaryChannelNumberRange.
  • Channel information is defined for both FavoriteChannelNumber and SecondaryChannelNumberRange, which are information that can be reassigned in case of overlapping channels, channels are assigned in the order of FavoriteChannelNumber -> SecondaryChannelNumberRange.
  • synchronization between transmission and reception can be performed using a common clock value.
  • PCR Program Clock Reference, program time reference value
  • the receiving end performs time synchronization with the transmitting end with the PCR value.
  • MPEG-2 system-based broadcasting it is applied to perform current time and AV decoding timing during live, and smooth broadcasting can be performed without clock values being distorted through time synchronization between transmission and reception.
  • the method/device according to the embodiments can be combined with the MPEG-2 system as shown in FIG.
  • a method/device according to embodiments may correspond to hardware, software, and/or a processor.
  • FIG. 29 is an end to end architecture diagram of MPEG DASH streaming.
  • the service provider uploads AV media data captured in real time to the origin server through encoding/packaging.
  • Media data and manifest are converted into a meaningful manifest guide through MPD modification process and advertisement insertion from original data of origin server, and are ingested into CDN.
  • On the DASH client side depending on the request, it can be divided into a low latency model and an existing DASH client mode, receive it, and provide media streaming through de-packetizing and decoding processes.
  • MPEG DASH supports media sync between transmission and reception through @AvailabilityStartTime or @ProducerReferenceTime.
  • the initial engine that initializes services and the DASH-client that handles media have a parent-child relationship, so an issue can arise if the child's clock controls the service initial engine.
  • a method/apparatus may transmit/receive data based on a network as shown in FIG. 1 .
  • the service model of DVB-I is the existing DVB-T / S / C / IPTV and IP-based protocol, wired and wireless
  • DVB-I is in the process of standardizing the goal of synchronized presentation of live broadcasting through low latency delivery technology synchronized between devices and fast channel switching. Also, DVB-I uses mobile device, web app, MSE (Media Source Extension), STB, and TV set (native) as target devices.
  • MSE Media Source Extension
  • STB TV set
  • NTP timestamp determines the reference time.
  • the current time is synchronized with a specific time server on the Internet and used.
  • each reference time server When time synchronization is performed with a specific time server through the API of the device itself for each OS of each device, the operation of each reference time server is different, so not only the time is incorrect, but also the processing time of server-side / receiver-side as shown in Figure 30. Because they are all different, an issue arises in obtaining a common time. Since the clocks of Master/Slave oscillators that bring the current time can be slightly different from each other, errors between devices can occur. These phenomena cause errors to accumulate when each device brings the time, causing it to be distorted for more than several seconds or minutes.
  • NTP synchronization used by IP-connected devices can generally be shortened, but synchronization is only possible after 10 minutes of extra time, and the Ping error has an accuracy of ms.
  • an error of ms can be an issue in media services. For example, in a soccer match, other people's goals may not appear on your device, or a service in progress may suddenly become inactive. Therefore, if the same UI/UX as the existing DVB live broadcasting is provided according to the philosophy of DVB-I, synchronization between devices should be implemented.
  • 45 illustrates reference clock synchronization according to embodiments.
  • time synchronization between devices may be necessary.
  • the time of devices receiving the DVB-I service within the network is unified to the time of one reference node, and the receiving devices use the time of the transmitter
  • a synchronization method that corrects the time of the device itself.
  • the receiver corrects the current time with timestamp point information and applies it as a common time for DVB-I service. It can be implemented as a timeline.
  • the DVB-I service can scan services and channels of each DVB channel and IP channel, receive the DASH MPD manifest of the IP channel, and provide the service through live streaming.
  • Each DVB-I client determines service active/inactive according to the service availability of each service instance, and can be configured to run an additional application for the currently ongoing content through a linked application manager.
  • Time synchronization between transmission and reception at the service level determines active/inactive according to the intention of the service provider and the exact time without any error in service availability, and when a linked application is delivered, it is synchronized based on the current broadcasting content consumption time and the application engine operates The goal is to make it possible.
  • the current issue is that the DVB-I reference client gets the current time through a method that gets the internal time of the client without a reference time during live streaming.
  • the timing acquisition method brings the network time of the DVB-I client itself, and an issue that does not match the time intended by the service provider occurs.
  • time synchronization in order to provide events related to ⁇ availability> within each DVB-I service scheme according to the manufacturer's intention, time synchronization must be performed according to the reference time between transmission and reception. For example, if the effective time of the service instance provided in ⁇ availability> is "2020-02-19T10:42:02.684Z", the DVB-I service supporting device should decide whether to proceed with the service based on that time. . However, in the current DVB-I service scheme, it is unclear what time the receiver determines ⁇ availability> with reference to.
  • the time is obtained from a specific time server specified through the network API within the receiver, the time cannot compensate for the time that is distorted according to Figure 30, and the standard time within the receiver that is not compensated is not time aligned with the DASH engine. Therefore, the start and end times of services between devices do not match. Therefore, service availability aligned with the media timeline of DASH must be provided through the application of common service level time.
  • a transmission/reception method/device may signal a DVB-I Service based on DVB-I service scheme information.
  • Fig. 47 illustrates a use case according to synchronization requirements according to embodiments.
  • dvbisd:anyURI can be defined as the following URI.
  • urn:mpeg:dash:utc:ntp:2014 Provides a list of server access addresses based on NTP protocol delivery that can receive appropriate wall clock time based on IETF RFC 7230
  • @nextLeapchangeTime Defines the returning Leap second date time.
  • one leap second may be added to reflect a leap second.
  • the DVB-I client obtains a common wall clock time from the service list manager that processes the DVB-I service list, and provides more accurate service availability through synchronization between DVB-I client devices. .
  • the standard purpose and motivation of DVB-I over 5G is through the convergence of 3GPP TS 103 720 standard Rel-16 version-based media transmission technology and DVB-I media service, along with general-purpose Internet network, when accessing 5G network, media service anytime, anywhere It is to create a standard technology that can consume Media services were consumed with web browsers based on general-purpose Internet networks such as existing LTE, OTT, and LAN, independent applications, or manufacturers' middleware-based applications. Accordingly, the recently released standard technology for media transmission of the 3GPP Rel-16 version and the service integration standard DVB-I united by European service providers form a meaningful service protocol, opening up wider service possibilities than existing services.
  • the media data processing method may include an integrated DVB-I solution capable of providing multiple distribution accessibility to existing non-5G networks as well as HPHT/Broadcast and LPLT/unicast.
  • the DVB-I over 5G structure should be a smooth and continuous service in a delivery route supported by multiple distributions, and can provide services through efficient and flexible access according to an optimal network environment. Specific requirements are as follows.
  • 5GBC, 5GMS, and non-5G networks within the DVB-I Service scheme must be included in the form of service instances.
  • 5GBC, 5GMS, and OTT which are extended service instances, must include the parameters of each network to identify the network. Ex) Proper alignment between service instances must be provided so that switching between service instances transmitted through different networks such as frequency, 5GBC transmission/service identifier, 5GMS transmission/service identifier, and DVB triplet can be recognized as reasonably smooth.
  • service priority can be assigned between service instances.
  • the related support use cases are as follows.
  • the user purchases a smartphone that supports 5G network and installs the DVB-I app or runs the native app (including fixed TV) of a specific manufacturer's middleware.
  • the terminal can support 5GBC, 5GMS, and OTT, and if it exceeds the minimum supported bitrate, it can be selected according to the network or the terminal can automatically judge and perform reasonable switching.
  • the DVB-I client When the DVB-I app is executed, the DVB-I client provides and selects accessible service instances through UI/UX.
  • popular programs with high traffic can be connected to 5GBC.
  • OTT In case of fixed TV, 5GBC and in case of portable device, OTT can be given priority and 5GMS can be selected as the second best.
  • the priority of the service instance can be switched reasonably and flexibly.
  • the current service instance When the current service instance reaches a certain bitrate or less and the service quality deteriorates, it can switch to another service instance according to specific conditions.
  • UHD-supported content it can be converted to the service instance with the best condition according to the bitrate of the effective network.
  • the access priority of 5G aware App can be specified.
  • the operators' bootstrapping method and location may vary depending on the type of network.
  • the propagation delay delivered is different depending on the network characteristics, so in the case of linear service, the provided reference time and media characteristics can be provided in different environments for each network.
  • the discovery URL and media location URL are all different for each operator, and there is an issue in which perfect switching is difficult when switching media in the middle.
  • the DVB-I client can compensate for time alignment with a clock value that is a standard.
  • a method/device (DVB client, terminal, etc.) may transmit and receive media data based on the DVB-I Service scheme extension of FIG. 33 .
  • 50 illustrates information for service instance switching according to embodiments.
  • Comparison bit rate means a bit rate that can handle a specific IP delivery service instance that provides a better user experience than service instances available for this service.
  • Comparison Content AttributeType Indicates which video and audio properties are available for DVB-I clients to provide AV property comparison and better user experience than service instances available for this service.
  • Comparison Bitrate Period (@ComparisonBitratePeriod): This is a condition for checking whether the comparison between service instances is valid in order to provide a better UX to users. The time the received bitrate lasts between MinimumBitRate and ComparisonBitrate.
  • the three elements/attributes of @ComparisonBitRate, @ComparisonContentAttributeType, and @ComparisonBitratePeriod can be used as reference values for each device and can be used according to each device's own conditions.
  • backward compatibility must be supported for DVB-I phase 1 receiver service instance conversion conditions, and there must be no user inconvenience.
  • Dynamic switching A flag that enables switching between Service instances to provide a better UX to users.
  • the method/device according to the embodiments supports all networks such as T/S/C + Internet channel (DVB-I) + 5G and enables efficient switching between networks.
  • the DVB-I CLIENT may receive actual media data and DVB-I service scheme information through all networks according to embodiments.
  • a single service definition (unique ID)
  • a single service may be defined as a local service and a service instance according to a delivery method.
  • serviceinstanceTypes can be defined in serviceType, and this service can all be the same as one.
  • 51 is an example of service instance switching according to embodiments.
  • 5GBC in the case of a fixed TV and OTT in the case of a portable device can be selected first, and 5GMS can be selected as the second best.
  • the priority of the service instance can be switched reasonably and flexibly.” or “D)
  • a popular program with a lot of traffic can be connected to 5GBC.” According to this, it is possible to move from OTT to 5GBC based on certain conditions. If the average received bitrate of OTT continues below the video quality of low quality for a certain period of time, service instance switching should be considered. At this time, the switching use case of the service instance can be implemented by comparing the receiving environment of the terminal.
  • @ComparisonBitRate and @ComparisonContentAttributeType bitrates and video attributes between service instances are compared to compare whether or not the conversion condition of service instances is satisfied. For example, if the currently received bitrate exceeds @ComparisonBitratePeriod for a certain period of time within the range of MinimumBitrate to ComparisonBitRate, it can be determined that the conversion condition is satisfied.
  • FIG. 53 shows a 5GBC instance and an OTT instance according to embodiments.
  • 5GBC that supports HD as a standard can be converted to OTT. If defined as follows in the extended @ComparisonContentAttributeType, UHD service can be provided by converting to an OTT service instance capable of UHD.
  • high-quality 5G network switching may be performed when low-quality media data is received for a certain period of time in OTT.
  • 5GBC is free-to-air and can be received without using data. According to the user's will, reception is possible.
  • switching networks it is not limited to high quality/low quality, and various options can be supported. That is, not only the user's will, but also network switching according to environmental changes unrelated to the user's will can be processed.
  • fallback may be performed by a method according to embodiments.
  • 54 illustrates video attribute type signaling according to embodiments.
  • a device may perform HDR/HFR signaling for DVB-I SERVICE access.
  • the DVB-I client such as shown in FIG. 26, must compose the DVB-I service selection UI and the content guide UI to express whether the service or download access is available to the user.
  • killer characteristic information that users must access to access and download services must be configured, and that information can be the criterion for user selection.
  • the ⁇ ContentAttributesType> value is expressed as follows, but the information is essential information from the viewpoint of decoder capability such as codec, but is insufficient as information from the service UI side for the user to receive richmedia services. Therefore, expressing video characteristic information and HDR/HFR/NGA information can be considered important depending on the DVB-I service point of view and service selection on the UI/UX shown to the user.
  • MPEG-DASH MPD is parsed after service is selected
  • MPD is parsed after service is selected
  • MPD information cannot be obtained before selection.
  • opening and caching the MPD of all channels can become a load on the receiver side as the number of channels increases.
  • the standard should be extended so that the server or transmission side can display the corresponding information on the Service UI. Therefore, the service selection criteria can be made clear to users by expanding related information, and clear information can be displayed on the UI by performing service filtering on the receiver side.
  • FIG. 26 The components of FIG. 26 are as follows.
  • Source selection UI control The device hosting the DVB-I client usually has some sort of UI that allows the user to select from one or more inputs, sources or apps.
  • a device may support more than one DVB-I client (eg multiple apps).
  • a single DVB-I client can appear as more than one input or source in this UI (eg listing different brands and different services).
  • Some inputs or sources may combine DVB-I channels with DVB-C/S/T channels and/or IPTV channels. This could be the same UI that allows the user to select an input or source completely unrelated to DVB-I, such as HDMI or DLNA or a global content provider.
  • the DVB-I client may include a UI for a user to view, select/change a service list. Some DVB-I client implementations may not include such a UI and may rely on a hybrid service selection UI.
  • Hybrid service selection UI control DVB-I service is displayed in a single common service selection UI with DVB-C/S/T/IPTV channels (including DVB C/S/T services over SAT>IP instead of local tuner) can be included
  • Service List Manager retrieves and queries the service list server and processes the returned service list (interfaces C1 and C2). When a DVB-I service is selected, it serves to instruct the service player to play the service.
  • DVB-C/S/T/IPTV Service List Manager Brings a service list from a DVB-C/S/T or IPTV device and displays a service from the list when selected.
  • Some examples of what can be included include RF channel scans, "homing mux" tuning, DVB-SI SDT acquisition, or obtaining a (proprietary) list of channels used by a particular IPTV technology. This may include DVB-C/S/T services available through SAT>IP.
  • the DVB-I client may include a UI allowing the user to access information about service contents included in the service selection UI. Some DVB-I client implementations may not include such a UI and may rely on a hybrid content guide UI.
  • Hybrid Content Guide UI Control Information about content delivered from DVB-I services is potentially Including) can be included in a single common content guide UI along with information about content delivered from
  • Content guide manager accesses the content guide server and processes the returned content guide data (interfaces A1 and A2). There is no assumption that this caches the content guide data on the DVB-I client in the same way that the content guide data is cached on the broadcast device. This function can be fully integrated into the DVB-I content guide UI (or hybrid content guide UI) without separate components.
  • DVB-C/S/T/IPTV Content Guide Manager A feature of a DVB-C/S/T or IPTV device that obtains and caches content guide data for DVB-C/S/T or IPTV channels.
  • Broadband Service Player responsible for the entire life cycle of playback of services provided by a broadband network. Appropriate control of DVB-DASH players, secondary OTT players and connected application managers. For services where media content is described as playlists, it is responsible for handling playlists.
  • Broadband service playback UI control To play broadband provisioned services, some kind of UI is required for functions such as playback control, audio track selection, subtitle control and parental access control within the timeshift buffer. It can also be used to display the status/response codes of DVB-DASH players. In the case of broadcast services, they usually already exist and are therefore out of scope for DVB-I clients. In case of DVB-DASH service this may be part of DVB-DASH player or DVB-I client. The latter of these is shown here.
  • the broadband service reproduction UI may copy the look and feel of an equivalent UI used when a broadcast service is provided.
  • DVB-DASH Player responsible for playing DVB-I services whose content is delivered by DVB DASH. It can use interfaces D1, D2, E1, E2.
  • DVB-I service listings may contain references to content available (and also) OTT via means other than DVB-DASH.
  • DVB-I clients can interface with players for non-DVB-DASH OTT content.
  • DVB-C/S/T/IPTV "Tuner” responsible for playback of DVB-C/S/T/IPTV services if selected. This may include DVB-C/S/T services accessed via SAT>IP instead of a local tuner.
  • Linked Application Manager When a service contains a linked application, it is responsible for identifying which version of the application can be displayed and, if so, connecting with the appropriate engine to perform the presentation. Some services may require the associated application to be started before the service's video and audio are displayed.
  • Connected Application Engine responsible for running applications connected to the services provided.
  • HDR information When HDR information is included in the video information of media data processed by the method/device according to the embodiments, three elements for signaling video characteristic information must be included, and a value corresponding to each element must be defined.
  • the DVB-I client can interpret the corresponding information at the service level and indicate that the corresponding service is HDR in the service/content guide.
  • the information of FIG. 54 may be transmitted through a DVB-I service schema, service instance, and MPD according to embodiments.
  • Color characteristics (clour_primaires), transformation information (transfer_chreacteristics), matrix coefficient information (matrix_coeffs), and alternative transformation SEI information (alternative_transfer_characteristics SEI message) can be transmitted through Essential Property and/or Supplemental Property.
  • the receiving device receives video characteristic information, and if the value (@value) is 9, it can know that the color is BT.2020, and if @value is 14, it can know that conversion has been performed to SDR. .
  • HFR 55 shows a high frame rate (HFR) example according to embodiments.
  • High Frame Rate is that 100, 120 Hz, which is the doubling rate of 50 and 60 Hz, is called HFR, and HFR service is displayed to the user in the content/service guide according to whether or not HFR play is possible. Therefore, if the service received by the DVB-I client is the HFR service, the indication extension of the corresponding information is required.
  • the stream structure of HFR is composed of HFR (5500) composed of Complete Single layer and HFR (5501) composed of temporal layer through sub-layers. In addition, only a sub layer is selectively reproduced at a low frame rate, or a high frame rate is reproduced by reproducing all layers.
  • a layer with 50 fps and a layer with 100 fps can be selectively reproduced or both can be reproduced.
  • a video having multiple layers may be encoded.
  • the structure of the temporal layering of the stream is indicated through the Temporal ID, and the Representation of the frame rate that can be reproduced is selected, downloaded, and reproduced.
  • temporal layer information can be combined or discarded to generate a playable or necessary frame rate.
  • HFR playback is determined according to temporal layer scalability by signaling the highest temporal ID.
  • the service list in FIG. 56 may correspond to FIGS. 49, 39, 28, 24, 19, 11, and the like.
  • 57 illustrates an example of signaling video attributes according to embodiments.
  • a locally defined VideoAttributesType may be used by changing the current DVB-I definition of ContentAttributesType according to embodiments.
  • VideoAttributes Indicates the video attributes of the service.
  • Color Space Represents specific information of a video color space for rendering service UI/UX based on conformance points.
  • Transfer characteristics Represents specific information of transfer characteristics for rendering service UI/UX based on the fit point.
  • Matrix coefficient Represents specific information of matrix_coeffient for rendering service UI/UX according to conformance criteria.
  • HighestTemporalID Indicates HighestTemporalID information for rendering service UI/UX based on the specific information Conformance Point of the video. It may follow urn:dvb:metadata:cs:VideoConformancePointsCS:20172 defined in ETSI TS 101 154 [22] indicating a video format usable in the VideoConformancePoint service.
  • 58 illustrates a multi-view transmission process according to embodiments.
  • a method/apparatus may provide a multi-viewport reflecting user preference.
  • DVB-I supports connected TV that can receive both the existing broadcasting network and the IP network or according to the selection.
  • This DVB-I can transmit multiple streams within a service and provide a personalized service by providing different viewports according to modes. For example, it is possible to provide a function for two people cheering for different teams in a soccer game to select and watch a screen based on their preferred team. If four videos are encoded with independent viewports for each scene and the encoded videos are output through one pipeline, the receiver can configure a specific screen according to the user's selection from the four viewports decoded in one video pipeline.
  • the production stage may generate a video signal for game 1, a video signal for game 2, a video signal for camera 1, a video signal for camera 2, and a video signal for camera N.
  • a plurality of video signals may include video data for multi-viewports independent of each other.
  • a plurality of video signals may be encapsulated into one data format based on one pipeline, encoded, and transmitted.
  • the decoding and rendering step may receive a plurality of video signals, and decode and render the selected video signal based on a user's selection.
  • a video selected from among N video signals can be efficiently provided to the user in part.
  • Multi-view video encoding can be transmitted through a function supporting subpicture among video encoding tools within MPEG VVC, and MPEG VVC defines an encoding algorithm and related parameters of an independent viewport.
  • MPEG VVC defines an encoding algorithm and related parameters of an independent viewport.
  • the four screens provide four 4k synchronized images at 8k resolution through MPEG VVC encoding, and the function of user personalization within DVB-I can be provided according to the selection for each scene.
  • 59 shows video data division units according to embodiments.
  • a method/device according to embodiments may process video data according to an MPEG VVC subpicture.
  • Embodiments may process media data according to the sub-picture structure of VVC, which is a video compression standard within MPEG.
  • Tile defines a unit called tile for parallel processing of dividing a specific area in an image and encoding and decoding the area in MPEG.
  • a set of tiles is a unit to which independent spatial prediction and entropy coding are applied, and encoding is possible with temporal and spatial independence, and encoding within a tile set and output processing as an independent NAL unit of a sequence are possible. For example, when encoding and streaming a 360 video, there is a limitation and waste of bandwidth to decode the entire video, so it is efficient to selectively decode and render only the corresponding region to fit the actual user viewport.
  • this frame is a 1920*1080 resolution picture and this picture may consist of 135 coding tree units (CTUs). This picture may consist of 9 tiles with 3 tile columns and 3 tile rows.
  • CTUs coding tree units
  • one tile may be composed of a plurality of CTUs that are coding tree units.
  • sub-picture as a new division structure to provide a more flexible Coded Video Sequence (CVS).
  • CVS Coded Video Sequence
  • the concept of subpicture means that one or more subpictures can be composed in an image, and one sub-picture can be composed of rectangular mode slices composed of one or more rectangles.
  • slice is a unit that is encapsulated in units of NAL units, and each subpicture can be composed of one or more slices.
  • 60 shows subpicture division according to embodiments.
  • the method/apparatus according to the embodiments may perform decoding in units of tiles and extract a bitstream by merging into a specific subpicture in a bitstream, and may perform slice, tile, and brick in an image.
  • subpictures do not depend on decoding from other slices, tiles, bricks, or subpictures, and may have a relatively simple partition structure.
  • each subpicture configuration information is transmitted after being parameterized in the SPS as follows.
  • a method/device may receive a video (picture) and divide it into two slices.
  • Slice 1 data and slice 2 data may be respectively encapsulated and transmitted as bitstreams.
  • a bitstream is composed of NAL units and may include a header and a payload.
  • the payload may include the RBSP.
  • Slices can be configured in raster scan order.
  • the method/device according to the embodiments may receive an image (picture) and divide it into three slices.
  • Each slice can be transmitted as a single stream in units of each NAL unit.
  • Slices can be constructed in a rectangular shape.
  • one picture may be divided into sub-pictures, encapsulated for each sub-picture, and transmitted/received.
  • 61 illustrates signaling information about a subpicture according to embodiments.
  • a method/device may transmit a bitstream including media data and signaling information related to the media data.
  • Signaling information may be referred to as metadata, parameters, and the like.
  • Information about subpictures may be included in a sequence parameter set, which is sequence level signaling information.
  • Information indicating the position of a subpicture may be generated for each number of subpictures.
  • Identification information (id) for identifying a subpicture may be additionally included in the parameter set.
  • the DVB-I bootstrapping method of accessing entry points of a specific service provider, a method of discovering services by obtaining a service list, and configuration information and AV attribute information of each service are provided. and each parameter is defined.
  • 61 is coordinates/size indicating the location of a subpicture, but it is additional information for controlling the CTU level required in the video encoding process or location information from the point of view of a codec, and does not mean specific coordinates or pixel positions for rendering. That is, information about rendering position is not specially defined within Codec.
  • the corresponding location information can be rendering location information, but if the viewport is changed according to the ROI, the corresponding coordinates are rendering or displaying coordinates does not match
  • the rendering position description information can create a rendering environment according to the application or use case in the system layer. Therefore, in DVB-I application, it is necessary to define a scene description capable of rendering the corresponding subpicture information.
  • Representative scene descriptions include (1) HTML/MMT CI and (2) HTML/Javascript.
  • the MMT CI description in the structure stored in the form of HTML DOM can dynamically change and update the location of the area and space.
  • the screen can be updated and expressed dynamically through the JS command referenced by using a specific identifier and a specific pattern in the DOM structure of HTML.
  • HTML cache data is provided as a framework and rendering location information can be configured in the form of creating a dynamic scene description.
  • DVB-I Service can basically provide DVB service through existing DVB-T/S/C network and IP at the same time.
  • the basic premise of TV implementation is the native environment, unlike the web configuration based on HTML pages or the operation of applications that depend on a specific OS, making it difficult to apply HTML.
  • scene description can be configured by referring to the information of subpictures included in VVC video based on the absolute position of the screen layout to be rendered.
  • a method/apparatus may display and render subpictures based on VVC encoding.
  • rendering information is required.
  • Render position information can be defined at system level.
  • the ES When an ES encoded with 4 subpictures is output from the encoder, the ES is encapsulated in units of subpictures through the sample group entry in the file format, and each sample group contains reference information of coded metadata (VPS, SPS, PPS) of the VVC video in the file format You can also reference it in Therefore, the receiving side can check reference information of subpictures in the ES within the file format when MPD acquired starting with DVB-I discovery and segment reception are completed.
  • coded metadata VPS, SPS, PPS
  • the receiving device parses DVB-SI information, demultiplexes TS fields containing videos, and decapsulates the PES stream You have to rate.
  • DVB-SI information When a plurality of independent video signals are encoded and encapsulated in one pipeline and transmitted, the receiving device parses DVB-SI information, demultiplexes TS fields containing videos, and decapsulates the PES stream You have to rate.
  • 4 subpictures are included in a video stream, since 4 subpictures need to be rendered, signaling information for rendering configuration is required.
  • rendering information for DVB-I discovery may be additionally generated and transmitted.
  • a plurality of videos may be sample grouped in a segment unit, and a reference relationship may be displayed with each other.
  • the receiving device may provide multi-scenes by rendering a plurality of videos by demultiplexing a segment by pre-obtaining render date information through an MPD or the like through a discovery process.
  • 63 shows a main scene configuration according to embodiments.
  • the receiving method/device may provide a scene composition for rendering to a display.
  • the main scene composition to be supported can configure independently encoded streams with 4 subpictures of 4k at a resolution of 8k (7680x4320). Each subpicture can be configured from Area1 to 4 based on (0,0) at the left end.
  • a user can view four 4k viewports within an 8k screen, select a desired scene, and consume 4k video.
  • the corresponding coordinates can designate the position of Area1 ⁇ 4 as follows.
  • rendering information including position information may be generated and transmitted to the receiving side. That is, by transmitting rendering coordinates, rendering position information, etc. for a plurality of subpictures, it is possible to provide a multi-scene for the user, and the user can view the configured multi-scene and selectively view the scene.
  • 64 illustrates a reference relationship between subpictures according to embodiments.
  • a method/device according to embodiments may indicate a reference relationship between subpictures in VVC coded video.
  • VPS id VPS id
  • SPS id SPS id
  • PPS id PPS id
  • a bitstream may include parameter sets such as VPS, SPS, and PPS, and a slice header and slice data (payload) may be included in the bitstream for each slice unit.
  • the ids included in the parameter sets may correspond to region 1, region 2, and the like.
  • rendering information included in the scene description may be acquired.
  • a mutual reference relationship may be indicated through Id, area, and scene description information between a plurality of pictures and a plurality of subpictures.
  • the scene description may deliver information about the scene for each group id.
  • a view id may correspond to a sample group including a subpicture.
  • the main view among location, MPD id, Representation id, VPS, SPS, subpicture id, and multi-view can be delivered.
  • the scene description may indicate a reference relationship using id information so that a receiving device can obtain a reference relationship between a plurality of pictures and subpictures.
  • FIG. 66 illustrates a scene description based receiving device according to embodiments.
  • scene description can be included in the system layer: it can be included where specific video characteristics of the DVB-I service list service are defined, or it can be extended where segment and video characteristics can be defined in DASH MPD.
  • Embodiment 1 Expansion within DVB-I service list: expand scene description within DVB-I, define video properties within service instance, acquire DASH MPD from service instance, expand scene description within MPD, expand within segment A subpicture set can be obtained by accessing the sample group entry.
  • service-related information filtered out for each service and playback environment suitable for each service instance are initialized. If the extended scene description is included in this process, it is possible to access the sample/subpictures entry in the file in the DASH engine through the corresponding information and perform subpicture rendering according to each view on the display.
  • Embodiment 2 extends MPD to include a scene description in the MPD. Details are described later.
  • Figure 67 shows scene description transfer syntax according to embodiments.
  • a DVB-I scheme for performing user personalization is as follows.
  • video/audio attributes for each service instance generated according to the delivery method of the filtered out service can be defined.
  • VideoAttribute defines video characteristic/color/size/framerate/pictureformat.
  • access to extend rendering attributes for subpictures of video streams included in service instances can be configured through extension of VideoAttributesType.
  • 68 shows a DVB-I service list including a scene description according to embodiments.
  • Option 1 of FIG. 67 shows a method of accessing a group including subpictures through GroupID (ID value of a layer in which several subpictures are grouped).
  • GroupID ID value of a layer in which several subpictures are grouped.
  • position information can be created to indicate the pixel value where each view should be located based on the upper left pixel in the display.
  • a default viewport to be designated when only one 4k subpicture is to be reproduced can be designated among multi-views.
  • SceneDescriptionLocaton Defines a separate XML location that can request and receive SceneDescription.
  • Option 3 of FIG. 67 is a bool function that indicates that composition information is defined in the DASH layer, and through that information, the DVB-I service layer provides notification that user personalization is provided and actual scene description data can be downloaded in the DASH MPD. there is.
  • 69 shows a scene description of an MPD according to embodiments.
  • the method of obtaining DASH MPD from the service instance, expanding the scene description in the MPD, and accessing the sample group entry in the segment is as follows. It can be extended in the form of an extension element of ⁇ common attributes and elements> or a supplemental property in the Adaptation-set / representation base of the DASH MPD hierarchy. Each semantics is the same as the scene description extension in DVB-I.
  • 70 shows syntax of a scene description in a DVB-I service list according to embodiments.
  • a method/apparatus configures a total of 4 (4k, 4) subpictures on an 8k screen through scene description in DVB-I, such as a code, based on pixel absolute values to conform to standard positions.
  • DVB-I scene description in DVB-I
  • rendering can be performed on four divided screens by referring to reference information to be included in the actual video stream.
  • the renderer After accessing the scene description information for each view to the sample entry in the segment file and completing the parallel decoding process for each entry, the renderer performs pixel allocation according to the absolute position of each view based on the scene description. According to the area of each view, the result of decoding can be rendered and displayed.
  • a specific use case is as follows. As a specific use case, after a certain period of time, only the view ID defined in ⁇ mainview> is selected as 4k, and can be selectively decoded and rendered in full screen. When the user selects a specific screen, the view ID of the selected area can be selectively decoded and rendered in full screen.
  • 71 illustrates a hybrid service scenario according to embodiments.
  • DVB-I CLIENT which is a device according to embodiments, may perform a discovery method according to embodiments for receiving a SERVICE LIST according to DELIVERY METHOD ( DVB-I standard-based hybrid service scenario)
  • a broadcaster can transmit a service through an Internet channel simultaneously with T, S, and C channels.
  • Service providers and device manufacturers capable of receiving DVB-I services can acquire authentication for service channels through regulation and provide Internet channels through existing linear services and channel aggregators.
  • a representative use case is shown in FIG. 71.
  • the service may provide DVB-S service through a DASH instance and a DVB-S supporting STB.
  • a DVB-I client can select an instance through priority, and can receive the same service through IP or satellite depending on the selection.
  • DVB-I can establish a DVB-I hybrid service environment by pre-installing satellite STB / RF receiver / cable STB, etc. installed to support these services and receiving a DVB-I service list.
  • DVB-I mobile since it is an only-IP environment, it is possible to receive a service list and select an instance capable of receiving through IP.
  • a client selects a filtered service for a received regional service through information such as target region / postcode / region ID / LCN mapping. can be received negatively.
  • the B1 and B2 interface discovery process and the F1 and F2 interfaces in FIG. 32 show the service list acquisition process. Looking at the related sequence and the embodiment of the current standard, it is as shown in FIG.
  • service discovery searches all service lists in ⁇ ProviderOffering> regardless of delivery method, and selects and receives them according to specific criteria on the client side.
  • the service list is received in the absence of a specific criterion, rather than being classified according to the satellite STB / RF receiver / cable STB being received after receiving the service list.
  • the DVB-I client since the DVB-I client has a filtering load, it is heavy in terms of limited device capabilities.
  • the standard can be extended so that a list can be obtained according to a delivery method during a DVB-I service discovery process.
  • the receiving device can efficiently receive service entries corresponding to the pre-installed delivery method from the server.
  • 73 illustrates a method of obtaining a DVB-I service list according to a delivery method upon DVB-I discovery according to embodiments.
  • the Figure 73 method can provide the following effects.
  • the DVB-I client receives all service lists and moves the load that needs to be filtered from the client to the server, and the DVB-I client provides related information based on pre-installed reception information (pre-installed delivery method/protocol). It is delivered to the query, and the server can receive a suitable list according to the delivery method through filtering.
  • the list can be matched according to the appropriate rank of acceptable experience information defined by the service list.
  • the service list provider will provision the list according to the combination of various delivery methods, and provide information that can indicate whether the service provides a hybrid service or an acceptable experience to the user and whether it conforms to and displays DVB-I clients with various capabilities. Should be.
  • a specific embodiment can be confirmed in the process of obtaining a service list entry point that meets the DVB-I client's request.
  • the DVB-I client can indicate whether the service list can be selected/displayed.
  • Required information Indicates whether the delivery provides a hybrid service or an acceptable experience.
  • this information indicates whether the delivery type should be supported and installed in the DVB-I client in order to provide an acceptable experience as defined by the Service Listing Provider.
  • This delivery type can be installed if the client can use the associated broadcast signal or IP network to retrieve the DVB service. Also, this field can be referred to as @installRequired.
  • Availability information Indicates whether to display service selection from the user without satisfying the required attribute.
  • this information indicates whether a corresponding service satisfies a condition for providing a service to a user.
  • the DVB-I client can check whether it is displayed on the UI/UX.
  • UI/UX can be provided to the user to make a clear choice.
  • Required information indicates whether the delivery type is supported and available by the DVB-I client in order to provide an acceptable experience defined by the service provider.
  • An acceptable experience may refer to a hybrid service, for example.
  • Delivery types may include DASH, T, S, C, 5G, and the like. Elements such as DASH delivery type, T delivery type, S delivery type, S delivery type, RTSP delivery type, and multicast TS delivery type may be displayed.
  • @required has a Boolean type and can have a value of true or false.
  • Availability information indicates whether a delivery type is available when a broadcast signal or an IP network related to using DVB services is available to a client, and whether services within the delivery type can be recommended in UI/UX. (A delivery type is available and the services in the delivery type is recommendable in UI/UX when the related broadcast signal or IP network can be used by the client to retrieve DVB services).
  • Availability information has a Boolean type and can have a value of true or false.
  • the priority indicates the priority of the service list relative to other delivery types.
  • a low value of this attribute can indicate a high priority.
  • DASHDelivery required is true and availability is yes (true)
  • a device may have a registry pre-installed on a client.
  • the client may request a discovery query to the service list registry according to the pre-installed delivery method.
  • the server may deliver an end point for service lists.
  • Information on whether multicast delivery is required, availability, priority, and the like can be delivered to the receiver (client).
  • a client can discover and obtain services based on the service list.
  • 74 is a 3GPP 5G broadcast Rel. 16 and commercial DVB-I applications.
  • 5G broadcast includes 5MBS through 5GNR and High Power High Tower through BMSC by applying the existing MBMS standard.
  • the DVB-I client discovers the services and transmits the service through the 5G Broadcast network. Media service can be received.
  • a method/device may provide a DVB-I service through a 3GPP 5G broadcast network.
  • the current DVB-I service is defined as a structure in which, when a service provider registers a service entry, a DVB-I client receives a list of lists through the DVB Central Service Repository and selects a service list.
  • DVB-I service delivery through 5GBC network is currently not defined as a delivery method in the DVB-I service list.
  • This patent is a delivery method at the same level as DVB-T/S/C within the DVB-I service list, and a DVB-I client capable of using extensions and 5GBC networks complies with the 3GPP standard to recognize unique service information and provide services. We are trying to devise a solution that will allow us to receive it.
  • DVB-I over 5GBC architecture there is a method of receiving a service through an MBMS service bearer - MBMS gateway - eNodeB by applying the HPHT method similar to the existing DVB broadcasting physical transmission method and the MBMS standard.
  • Media transmission through this 5GBC network allocates and issues service-specific information so that the terminal can receive and consume it separately for each service. Therefore, it is possible to retrieve 5GBC network connection, service discovery and media data by extending and defining corresponding unique information in the DVB-I service list.
  • Content/Service provider registers service list (service) in Central Service Repository according to DVB-I standard.
  • the same identification information of the service defined in the DVB-I service list is delivered to BMSC through the xMB interface.
  • 76 illustrates a method of obtaining a group message through a service ID according to embodiments.
  • the method/device may identify and acquire a group message based on an SCS/AS identifier, a service ID, and a transaction identifier.
  • 77 illustrates a group message acquisition process according to embodiments.
  • the procedure for acquiring the group message of the MBMS resource is performed.
  • the promised request / response process including the predefined unique information based on the location information of the current UE or Geo IP information is performed.
  • the same request as in Figure 77 is performed including Service ID and transaction ID.
  • a DVB-I list service discovery process is as follows.
  • the current DVB-I standard defines service discovery query syntax as follows:
  • TargetCountry TargetCountry, regulatorListFlag, Delivery, Language, Genre ProviderName, isLocal(New), isWAN(new)
  • the current DVB-I standard defines the procedure as follows.
  • CSR bootstrap access to service list server
  • Receive service list entry points list of lists, receive information to access a list of multiple lists
  • Select Service list URL Receive service list (Accessing the service list and receiving the service list desired by the client) -> Recognizing the Postcode-based region ID in the service list -> Selecting a service matched with the region ID according to the address of the current TV -> Selecting a service instance that matches Capability + Priority”
  • the DVB-I standard includes all local services within a national area in a service list without considering a method of receiving a service list using current location information. This method defines a technique for receiving unnecessary data by receiving all local services regardless of the user's region/location.
  • TargetCountry UK and move to France
  • TargetCountry FR
  • proxy/edge can be created and deleted flexibly from the viewpoint of 5GMS and BC, so the current base station location or GPS can be recognized.
  • Mobile-based service bootstrapping can also be “efficient” service access.
  • CSR bootstrapping CSR query extension
  • Service list offering scheme extension Location-based information or 5G service-related information extension
  • Service instance extension service instance (new delivery) / source type / for 5GBC expansion is possible.
  • Embodiments newly define a service default query for 5G/Mobile, and use the current 5G (res IP) information (isWAN) or GPS information (agreement required, isLocal) to receivable services or service lists including service instances through Backend SQL can receive
  • DVB-I delivers ServiceListEntryPoints previously defined in the DVB-I standard as a response to the request.
  • a list of lists corresponding to “” value is included in ServiceListEntryPoint.
  • a 5GBC list that can be received based on the current location information is transmitted, services that can be received from the interface according to embodiments and unique information received through the interface according to embodiments are identified and service (service instance) matching is performed. It can be displayed on the DVB-I client service UI/UX through
  • DVB-5G delivery may be indicated through the DVB-5GBCDelivery element of the DVB-I service scheme according to embodiments.
  • the AbstractDeliveryType field indicates whether the delivery type must be supported and installed by the DVB-I client in order to provide an acceptable experience as defined by the service list provider.
  • a delivery type is established if the client can use the associated broadcast signal or IP network to retrieve DVB services.
  • the delivery type of FIG. 78 may include elements as shown in FIG. 79 .
  • ServiceInstanceType extension for supporting 5GBC according to embodiments.
  • a DVB-I service scheme may include extension values of service instance types as shown in FIG. 80 .
  • 81 illustrates DVB 5GBC delivery parameter types according to embodiments.
  • a DVB-I service scheme may include DVB 5GBC delivery parameter types as shown in FIG. 81 .
  • 82 illustrates a 5GBC service acquisition process according to embodiments.
  • a method/device according to embodiments may obtain 5GBC service based on FIGS. 78 to 81 .
  • the 5GBC acquisition process of the method/apparatus according to the embodiments of FIG. 82 is as follows.
  • Scan start and terminal information acquisition capabilities, GPS, country, etc. can be acquired.
  • a method/device according to embodiments may perform additional image extension for DVB-I backward compatibility.
  • DVB-I image types supported by the method/device according to the embodiments are as follows.
  • the DVB-I standard defines an image URI according to the corresponding element scheme type, and the DVB-I client can configure appropriate UI/UX within the screen.
  • DVB-I defines an image definition method as xsd as follows.
  • 83 illustrates a method of defining an image according to embodiments.
  • the above-mentioned xsd may be the same as in FIG. 83.
  • the type of image can be indicated through the media locator and media uri fields, and the uri of the image can be included.
  • DVB-I spec identifies properties of uses among Service List Logo, Service Logo, Content Guide Source Logo, and Program Posters with @href value defined in Tv anytime scheme, and defines image/type through @MediaLocator property. As shown in Figure 83, an Image URI that is actually connected can be defined through the value of anyURI.
  • Embodiments can solve the problems caused by the addition of the DVB-I image type as follows.
  • Image type support in DVB-I provides mostly small-sized images or full-screen elements such as logos. If service/content thumbnail is provided, it may be a definition that is not suitable for providing based on these elements. As in the following example, when the logo properties used in the existing DVB-I standard are composed of UI/UX, the service UI/UX can be used as a small-sized logo, and the service thumbnail is not appropriate for logo placement.
  • the absence of service/content thumbnails makes it difficult to configure by utilizing the logo attribute, which is a small size image, especially when configuring mobile UI/UX that shows services in preview form.
  • JPEG and PNG values are still image compression techniques from the early 1990s, and their compression efficiency is relatively low compared to current image compression techniques.
  • the webp image format which has better compression efficiency than JPEG and PNG and supports and replaces JPEG (lossy) and PNG (lossless), is widely used.
  • webp can provide an animated preview function, so it can be compared with GIF. Compared to GIF that only provides 8-bit 256 color released in the early 1990s, webp shows excellent performance in terms of compression rate and It has the advantage of not breaking at large resolutions because there is no limit.
  • the embodiments are (1) Absence of a thumbnail definition in the DVB-I standard. (2) We propose a technical solution considering the addition of webp in addition to the existing image format.
  • the first option is TV anytime extension considering DVB-I backward compatibility.
  • the ControlledTermType sequence may include an @href element.
  • an out of service banner may be displayed, if the term ID is 1001.1, a service list logo may be displayed, if a term ID is 1001.2, a service logo may be displayed, and if a term ID is 1001.3, a service thumbnail may be displayed.
  • the service list includes related information
  • the related information includes term ID information for media data
  • the first value indicates a logo for the service list
  • the term may represent a logo for media data
  • the third value may represent an image representing a scene related to media data.
  • the fourth value may indicate an out-of-service banner.
  • Term ID information may indicate an item that can be used within the on-screen appearance of a service.
  • a service list logo is a graphic icon that can be used to visually identify a service list.
  • a service logo is a graphic icon that can be used to visually identify a service.
  • the service banner is a large-format graphic element and may be an element depicting a subject or scene for a service.
  • Embodiments may deliver service banner information related to a service and/or program.
  • Service list image formats according to embodiments may be extended, and for compatibility, PNG and/or JPG formats may be provided together.
  • logos related to service lists and services according to embodiments may have an icon shape and a small size. Accordingly, service banner information may be extended to provide richer service and/or program information.
  • Service banner information may be transmitted by assigning a term ID to a HowRelatedCS element included in a service list according to embodiments.
  • a service banner may be a large-sized graphic element depicting a scene or subject related to a service.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

실시예들에 따른 미디어 데이터 처리 방법은 미디어 데이터를 생성하는 단계; 미디어 데이터에 관한 서비스 리스트를 생성하는 단계; 및 미디어 데이터 및 서비스 리스트를 네트워크에 기반하여 전송하는 단계; 를 포함할 수 있다. 실시예들에 따른 미디어 데이터 처리 방법은 네트워크에 기반하여 미디어 데이터 및 미디어 데이터에 관한 서비스 리스트를 수신하는 단계; 및 서비스 리스트에 기반하여 미디어 데이터를 처리하는 단계; 를 포함할 수 있다.

Description

미디어 데이터 처리 방법 및 미디어 데이터 처리 장치
본 발명은 미디어 데이터 처리 방법 및 미디어 데이터 처리 장치에 관한 것이다.
지상파, 위성, 케이블 리니어 채널과 동일한 유저UX 를 제공할 수 있는 IP 기반 TV 서비스를 구현하기 위한 방법이 부재하다.
앱 기반 리니어 채널 서비스가 아닌, 오픈 인터넷 기반 네이티브 코드 수신을 통해 지상파, 위성, 케이블 채널과 통합된 채널 가이드 제공하기 위한 방법이 부재하다.
지상파, 위성, 케이블, 인터넷 모두를 기반으로 하는 통합형 방송 시스템 프로토콜이 부재하다.
지상파, 위성, 케이블 튜너가 없는 수신기에서 인터넷 방송 서비스 시그널링을 획득할 수 있는 방법이 부재하다
인터넷 전송을 기반으로 한 방송 서비스 획득을 위한 서비스 디스커버리 시스템이 부재하다.
인터넷을 기반으로 한 방송 서비스 시그널링 메커니즘이 부재하다.
DVB-I 서비스에 대응되는 컨텐트 가이드의 업데이트 상태를 유지하기 위한 방법이 부재하다.
실시예들에 따른 미디어 데리어 처리 장치는, 지상파, 위성, 케이블 리니어 채널과 동일한 유저UX(user UX)를 제공할 수 있는 IP 기반의 TV 서비스를 구현한다.
실시예들에 따른 미디어 데리어 처리 장치는, 어플리케이션 기반의 리니어 채널 서비스가 아닌, 오픈 인터넷 기반의 네이티브 코드 수신을 통해 지상파, 위성, 케이블 채널과 통합된 채널 가이드 제공한다.
실시예들에 따른 미디어 데리어 처리 장치는, 지상파(fixed)의 직접수신이 아닌, IP 기반 디바이스들의 OTT, PC등과 IPTV등의 매체들을 통해 방송서비스가 소비되는 상황 및 유니캐스트의 높은 트래픽을 고려하여 실시간/비실시간 미디어 스트리밍 서비스의 심리스(seamless)한 서비스를 제공한다.
실시예들에 따른 미디어 데이터 처리 방법은 미디어 데이터를 생성하는 단계; 미디어 데이터에 관한 서비스 리스트를 생성하는 단계; 및 미디어 데이터 및 서비스 리스트를 네트워크에 기반하여 전송하는 단계; 를 포함할 수 있다. 실시예들에 따른 미디어 데이터 처리 방법은 네트워크에 기반하여 미디어 데이터 및 미디어 데이터에 관한 서비스 리스트를 수신하는 단계; 및 서비스 리스트에 기반하여 미디어 데이터를 처리하는 단계; 를 포함할 수 있다.
전통적인 튜너를 탑재하지 않은 수신기에서 브로드밴드(Broadband)망을 통해서 인터넷 기반 브로드캐스트 서비스 디스커버리 및 획득을 효율적으로 할 수 있는 효과가 있다.
실시예들에 따른 통합된 서비스 리스트 수신 시, 각 서비스 별 버전닝/만료(versioning/expiration) 관리 방법과 서비스 별 선택적 파싱과 저장으로 전체 서비스 리스트를 수신할 필요 없다.
캐퍼빌리티(capability)가 적합한 서비스들을 제공할 수 있는 콘텐츠나 사용자경험을 효율적으로 제공 할 수 있다.
첨부된 도면은 본 발명의 실시예들을 나타내고 설 명과 함께 본 발명의 원리를 설명한다.
도1은 실시예들에 따른 서비스 시나리오를 나타낸다.
도2는 실시예들에 따른 네트워크 오퍼레이터/ISP 측면에서 실시예들에 따른 동작의 흐름도를 나타낸다.
도3은 실시예들에 따른 DVB 채널 서비스에 대한 프로토콜의 스택을 나타낸다.
도4는 실시예들에 따른 서비스 디스커버리 리스트 테이블의 확장 신택스를 나타낸다.
도5는 실시예들에 따른 채널의 관리의 예시를 나타낸다.
도6은 실시예들에 따른 타입에 따른 히든 프리젠테이션을 나타낸다.
도7은 실시예들에 따른 히든 채널 관리의 흐름도를 나타낸다.
도8은 실시예들에 따른 SDLT에 관련 머터리얼(Related Material)이 포함된 예시를 나타낸다.
도9는 실시예들에 따른 RelatedMaterial 신택스를 나타낸다.
도10는 실시예들에 따른 인엑티브 배너의 활용 예시를 나타낸다.
도11는 실시예들에 따른 서비스 리스트 계층 구조를 나타낸다.
도12는 실시예들에 따른 DVB-I 서비스 리스트 타입을 나타낸다.
도13은 실시예들에 따른 DVB-I 서비스 타입을 나타낸다.
도14는 실시예들에 따른 서비스 인스턴스 타입을 나타낸다.
도15는 실시예들에 따른 사이멀캐스트(simulcast)을 위한 DASH딜리버리 파라미터들을 나타낸다.
도16은 실시예들에 따른 DASHDeliveryParametersType에 기반한 서비스 인스턴스를 선택하는 안을 나타낸다.
도17은 실시예들에 따른 DVB-I 서비스 인스턴스의 예시를 나타낸다.
도18은 실시예들에 따른 실시예들에 따른 사이멀캐스트 UI/UX를 나타낸다.
도19는 실시예들에 따른 DVB-I 서비스 리스트 하이어라키를 나타낸다.
도20은 실시예들에 따른 ContentGuideSourceList를 나타낸다.
도21은 실시예들에 따른 DVB-I클라이언트 오버-러닝 이슈를 나타낸다.
도22는 실시예들에 따른 다이나믹 폴링 알고리즘을 나타낸다.
도23은 실시예들에 따른 DVB-I service scheme을 나타낸다.
도24는 실시예들에 따른 DVB-I 서비스 하이어라키를 나타낸다.
도25는 실시예들에 따른 DVB-I service scheme 및 content guide 최신 정보를 업데이트 하기 위한 방법을 나타낸다.
도26은 실시예들에 따른 DVB-I 클라이언트의 모델을 나타낸다.
도27은 실시예들에 따른 DVB-I 서비스 별 content guide 최신 정보를 획득 하는 방법을 나타낸다.
도28은 실시예들에 따른 컨텐트 가이드 소스 하이어라키를 나타낸다.
도29는 실시예들에 따른 DVB-I 서비스 이니셜라이제이션 및 컨텐트 가이드 업데이트 흐름도를 나타낸다.
도30-31은 실시예들에 따른 DVB-I service scheme 을 나타낸다.
도32는 실시예들에 따른 DVB-I 모델을 나타낸다.
도33은 실시예들에 따른 제조사 서비스 리스트 지원을 위한 DVB-I 서비스 아키텍쳐를 나타낸다.
도34는 실시예들에 따른 DVB-I Service discovery information 을 나타낸다.
도35는 실시예들에 따른 서비스 리스트 레지스트리 엔티티의 신택스를 나타낸다.
도36은 실시예들에 따른 서비스 리스트 레지스트리 엔티티의 세만틱스를 나타낸다.
도37은 실시예들에 따른 서비스 리스트 선택 UI/UX를 나타낸다.
도38은 실시예들에 따른 멀티플 서비스 리스트(Multiple service list) 수신 시 채널 충돌 대응 방법을 나타낸다.
도39는 실시예들에 따른 LCN 테이블 엔트리 타입 확장을 나타낸다.
도40은 실시예들에 따른 LCN 테이블 엔트리 신택스를 나타낸다.
도41은 실시예들에 따른 서비스 채널 충돌을 해결하는 예시를 나타낸다.
도42는 실시예들에 따른 채널 중복 이슈 해결 예시이다.
도43은 실시예들에 따른 MPEG-2 시스템 STC구조를 나타낸다.
도44는 실시예들에 따른 DASH 스트리밍 구조를 나타낸다.
도45는 실시예들에 따른 레퍼런스 클럭 동기화를 나타낸다.
도46은 실시예들에 따른 수신 장치의 Reference Clock Sync 동작의 예시를 나타낸다.
도47은 실시예들에 따른 동기화 요구사항에 따른 유즈 케이스를 나타낸다.
도48은 실시예들에 따른 5G 기반 DVB-I 시스템을 나타낸다.
도49는 실시예들에 따른 DVB-I 서비스 스킴 확장을 나타낸다.
도50은 실시예들에 따른 Service instance switching 을 위한 정보를 나타낸다.
도51은 실시예들에 따른 서비스 인스턴스 스위칭 예시이다.
도52는 실시예들에 따른 서비스 인스턴스 스위칭 예시이다.
도53은 실시예들에 따른 5GBC instance 및 OTT instance를 나타낸다.
도54는 실시예들에 따른 비디오 어트리뷰트 타입 시그널링을 나타낸다.
도55는 실시예들에 따른 HFR(high frame rate) 예시를 나타낸다.
도56은 실시예들에 따른 HDR/HFR 특성을 위한 서비스 리스트 구성을 나타낸다.
도57은 실시예들에 따른 비디오 속성을 시그널링하는 예시를 나타낸다.
도58은 실시예들에 따른 멀티-뷰 전송 과정을 나타낸다.
도59는 실시예들에 따른 비디오 데이터 분할 단위를 나타낸다.
도60은 실시예들에 따른 서브 픽쳐 분할을 나타낸다.
도61은 실시예들에 따른 서브 픽쳐에 관한 시그널링 정보를 나타낸다.
도62는 실시예들에 따른 서브 픽쳐 렌더링을 나타낸다.
도63은 실시예들에 따른 메인 장면 구성을 나타낸다.
도64는 실시예들에 따른 서브 픽쳐 간 참조관계를 나타낸다.
도65는 실시예들에 따른 씬 디스크립션을 나타낸다.
도66은 실시예들에 따른 씬 디스크립션 기반 수신 장치를 나타낸다.
도67은 실시예들에 따른 씬 디스크립션 전달 신택스를 나타낸다.
도68은 실시예들에 따른 씬 디스크립션을 포함하는 DVB-I 서비스 리스트를 나타낸다.
도69는실시예들에 따른 MPD의 씬 디스크립션을 나타낸다.
도70은 실시예들에 따른 DVB-I 서비스 리스트 내 씬 디스크립션의 신택스를 나타낸다.
도71은 실시예들에 따른 하이브리드 서비스 시나리오를 나타낸다.
도72는 실시예들에 따른 DVB-I 서비스 리스트 디스커버리 과정을 나타낸다.
도73은 실시예들에 따른 DVB-I discovery 시 Delivery method 에 따른 DVB-I service list 획득 방법을 나타낸다.
도74는 실시예들에 따른 통신망 브로드캐스트에 대한 DVB-I를 나타낸다.
도75는 실시예들에 따른 5GBC 구조 상 DVB-I를 나타낸다.
도76은 실시예들에 따른 서비스 아이디를 통한 그룹 메시지 획득 방법을 나타낸다.
도77은 실시예들에 따른 그룹 메시지 획득 과정을 나타낸다.
도78은 실시예들에 따른 5GBC를 위한 DVB-I 서비스 리스트 오퍼링 딜리버리 타입의 확장을 나타낸다.
도79는 실시예들에 따른 DVB 5GBC 딜리버러 티압을 나타낸다.
도80은 실시예들에 따른 5GBC 를 지원하기 위한 DVB-I 서비스 인스턴스 타입 확장(ServiceInstanceType extension)를 나타낸다.
도81은 실시예들에 따른 DVB 5GBC 딜리버리 파라미터 타입을 나타낸다.
도82는 실시예들에 따른 5GBC 서비스 획득 과정을 나타낸다.
도83은 실시예들에 따른 이미지를 정의하는 방법을 나타낸다.
도84는 실시예들에 따른 이미지 타입에 따른 예시를 나타낸다.
도85는 실시예들에 따른 이미지 타입의 속성의 확장을 나타낸다.
도86은 실시예들에 따른 서비스 썸네일을 지원하는 예시이다.
도87은 실시예들에 따른 이미지 타입 지원을 나타낸다.
도88은 실시예들에 따른 미디어 처리 장치를 나타낸다.
도89는 실시예들에 따른 이미지 타입 지원을 나타낸다.
도90은 실시예들에 따른 이미지 타입 지원을 나타낸다.
도91은 실시예들에 따른 서비스 썸네일 오퍼링 및 서비스 썸네일 엘리먼트를 나타낸다.
도92는 실시예들에 따른 미디어 처리 장치를 나타낸다.
도93은 실시예들에 따른 이미지 타입 지원을 나타낸다.
도94는 실시예들에 따른 미디어 데이터 송신 방법을 나타낸다.
도95는 실시예들에 따른 미디어 데이터 수신 방법을 나타낸다.
이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
하기의 실시예들은 본 발명을 구체화하기 위한 것일 뿐 본 발명의 권리 범위를 제한하거나 한정하는 것이 아님은 물론이다. 본 발명의 상세한 설명 및 실시예들로부터 본 발명이 속하는 기술 분야의 전문가가 용이하게 유추할 수 있는 것은 본 발명의 권리 범위에 속하는 것으로 해석된다.
상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 안되며, 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
바람직한 실시예들에 대해 구체적으로 설명하되, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 실시예들에 따라 구현될 수 있는 실시예들만을 나타내기보다는 바람직한 실시예들을 설명하기 위한 것이다. 이하에서는 본 발명에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함하여 설명한다. 그러나 본 발명이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다. 본 발명에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 본 발명은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다. 또한 이하의 도면들 및 상세한 설명은 구체적으로 기술된 실시예들에만 국한되어 해석되지 않고, 도면 및 상세한 설명에 기재된 실시예들과 균등하거나, 대체 가능한 것들까지 포함하는 것으로 해석되어야만 한다.
실시예들에 따른 미디어 데이터 처리 방법/장치는 미디어 데이터 송수신 방법/장치를 지칭할 수 있다. 실시예들에 따른 미디어 데이터 처리 방법/장치는 줄여서 실시예들에 따른 방법/장치로 지칭될 수 있다.
실시예들에 따른 방법/장치는 인터넷 기반 방송 관련 미디어 데이터(서비스라고 지칭 가능)를 발견하고 획득하는 방안에 관한 것이다.
도1은 실시예들에 따른 서비스 시나리오를 나타낸다.
실시예들에 따른 방법/장치는 DVB-I 표준 기반 멀티 뷰포트 유저 퍼스널라이제이션(MULTI-VIEWPORT USER PERSONALIZATION)을 지원하기 위한 방법을 제공할 수 있다.
실시예들에 따른 방법/장치는 DVB-I의 5G 확장(DVB-I over 5G extension), 6G 등 통신망 확장 방안을 제공할 수 있다.
실시예들에 따른 방법/장치는 DVB-I 하위 호환을 고려한 추가적인 웹 이미지 확장(additional webp image extension)을 제공할 수 있다.
실시예들은 인터넷 기반 방송(Internet-based Broadcast) 서비스를 제공하기 위해, 서비스 디스커버리(service discovery) 방안을 제공한다.
실시예들은 인터넷 기반 방송 서비스 식별( Internet-based Broadcast service identification) 을 위해 정의되어야 하는 추가 정보들을 제안한다.
실시예들은 인터넷 기반 방송 서비스 시그널링 획득을 위한 시스템 메커니즘을 제공한다.
실시예들은 통합된 서비스 리스트(Aggregated service list) 수신 시, 각 서비스(service) 별 버전닝/만료(versioning/expiration) 관리 방법과 서비스 별 선택적 파싱과 저장 방법을 제안한다.
실시예들은 인터넷 리니어(linear) 채널의 히든/셀렉터블/인액티브(hidden/selectable/inactive) 상태 시, 채널관리 방법을 제안한다.
실시예들은 인터넷 기반 방송(Internet-based Broadcast) 서비스를 제공하기 위해, 서비스 디스커버리 시그널링(service discovery signaling) 방안을 제안한다.
실시예들은 각 유니크(unique) 한 서비스 별로 프래그먼트화(fragmented) 된 서비스 리스트(service list) 가 멀티파트/관련 컨테이너(multipart/related container)에 포함되어 전송될 때의 서비스 리스트 메타데이터 인벨롭(service list metadata envelop) 구조를 제안한다.
실시예들은 인터넷 리니어(linear) 논리적 채널의 히든/셀렉터블/인액티브(hidden/selectable/inactive) 케이스 내에서, 사용자가 현재 채널에 직접 접근 시, 사용자에게 현재 채널 상태를 표시하거나 대체 채널을 제공하는 방법을 제안한다.
실시예들은 기존의 전통적인 튜너(Traditional Tuner)를 탑재하지 않은 수신기에서 브도드밴드(Broadband)망을 통해서 인터넷 기반 방송 서비스 디스커버리(Internet-based Broadcast Service Discovery) 및 획득(Acquirement)이 가능하게 하는 효과가 있다.
실시예들은 통합된 서비스 리스트(Aggregated service list) 수신 시, 각 서비스 별 버전/만료(versioning/expiration) 관리 방법과 서비스별 선택적 파싱과 저장으로 전체 통합된 서비스 리스트(Aggregated service list)를 수신 할 필요 없는 효과가 있다.
실시예들은 인터넷 리니어 채널의 히든/셀렉터블/인액티브(hidden/selectable/inactive) 시, 사용자에게 방송이 나오지 않는 불편함을 주는 논리적 채널 서비스를 막고, 인터넷 리턴 채널 대체 서비스를 제공함으로써 보다 나은 미디어 서비스를 제공할 수 있는 효과가 있다.
전통적인 IP 기반 linear 채널 서비스는 특정 사업자(e.g. ISP, Network operator )의 가입을 통해, 인증(authentication) 을 부여 받고 사업자가 제공하는 STB 를 통해 IP 리니어 서비스(linear service)를 받는 형태이다. 또한 최근에는, 커넥트 TV(connectivity TV)의 등장으로 셋톱박스 없는(STB-less) 형태의 IP 리니어 서비스를 소비도 가능하다. 대표적인 표준 기술로는 ATSC 3.0, IBB, HbbTV로, 클라이언트(client)는 TV 내부의 OS 플랫폼 위의 어플리케이션(application) 을 동작하여 다양한 리니어 리치 미디어(linear rich-media) 서비스를 받을 수 있다. 다양한 오퍼레이터(operator)들은 자체적으로 개발만 서비스 어플리케이션(application)을 TV 플랫폼 위에 설치 할 수 있게 제공하고, 어플리케이션에서는 서비스를 위한 데이터들을 제공 받을 수 있는 서버와 요청/수신을 가능하게 하는 API 들을 정의하고 있다. 그 라이프 사이클(life cycle) 기반 위에 클라이언트는 TV UI 를 통해, 앱(app)에 접근하고 앱(app)을 통해 다양한 서비스를 수신할 수 있다.
북미, 유럽 전세계적으로 리니어TV 시청만큼 OTT 채널의 선호도가 높아져, 이러한 OTT 시장의 확대는 IP 기반 디바이스의 필수적인 미디어 어플리케이션으로서 자리 잡았다. 하지만 영향력 있는 OTT 의 형태는 독자적인 플랫폼과 OTT 만의 서비스 에코 시스템(eco-system)으로 독점적인 서비스가 되었다. 다시 말해, 각 OTT 만이 제공하는 코덱(codec), 프로토콜 스택(protocol stack), 어플리케이션(application), 브라우저(browser) 등 독자적인 앱-에코시스템(app-ecosystem) 소비형태를 보이고 있다.
이와 관련하여, 실시예들은 이러한 OTT 들의 독점적 플랫폼, 어플리케이션의 동작의 대한 의존도(dependency) 등의 이슈들을 해결하기 위한 방법 및 장치를 제안한다.
실시예들은 기존 기술과 같이 앱(App)을 반드시 실행하여 지상파(T), 위성파(S), 케이블(C) 리니어 채널(linear channel) 서비스와 유사한 채널 UX 를 제공하는 형태가 아닌, 수신기 네이티브(native) 레벨에서 서비스를 디스커버리(discovery) 하고 클라이언트가 접근 가능한 서비스 서버에 접근하여 리니어 서비스를 수신하는 서비스를 제안하고자 한다.
또한, 실시예들은 OTT 의 독자적인 플랫폼을 하나의 통일된 TV 네이티브 플랫폼으로 통합하여 사용자에게 OTT 앱(app)을 실행하지 않고, 채널 내에 OTT 콘텐츠를 받아 볼 수 있는 서비스 시나리오를 제안한다.
도1을 참조하면, 브로드캐스터(broadcaster, 10000)가 T(terrestrial), S(satellite), C(cable) 채널(10010)과 동시에 인터넷 채널(Internet channel, 10020) 로 서비스를 전송할 수 있다. 서비스와 사업자, DVB-I 서비스(10050) 수신 가능한 디바이스 제조사가 레귤레이션(regulation)을 통해 서비스 채널의 대한 인증(authentication) 을 획득하고 기존 리니어 서비스와 채널 어그리케이터(aggregator)를 통해 인터넷 채널을 제공 할 수 있다.
기존의 리니어(linear) 방송채널(예를 들어, 지상파, 위성파, 케이블 등) 리스트와 인터넷 채널 리스트를 통합된 형태로 나타내기 위해, 기존 리니어 망에서 제공하는 서비스 디스커버리(Service Discovery) 정보를 통해 부트스트랩(bootstrap, 10030)을 진행 할 수 있다.
브로드캐스터 측면에서는 기존의 전통적 서비스 제공 형태를 확장할 수 있고, 기존 리니어 채널 망과 더불어 온-디맨트/멀티캐스트(on-demand/multicast) 서비스 형태로 추가적인 서비스를 제공 할 수 있다. 또한 인터넷 채널의 연결 기반 사용 리포트(Usage report)를 통해 개인화(personalization) 서비스를 제공할 수 있다.
TV/STB 제조사 입장에서는 전통적T/S/C 채널에 OTT 서비스를 통합한 채널 리스트(10040)를 제공 함으로써, 다양한 서비스 제공과 단말의 기능 확장의 기회를 가져올 수 있다.
Network/ISP 의 경우, 그들이 가진 네트워크 인프라(network infra)를 통해, OTT 콘텐츠를 통합(aggregation)하여 서비스 제공의 확장을 가져온다. 또한, 유니캐스트/멀티캐스트(unicast/multicast)의 동적 할당(dynamic allocation)을 통해, 논-매니지먼트(non-management) 네트워크 기반 서비스하는 단말보다 강화(enhanced)된 딜리버리 퍼포먼스(delivery performance)를 제공할 수 있다.
다시 말해, 브로드캐스터(10000)는 전통적 방송망(10010) 및 인터넷망(10020)으로 방송 데이터를 송신할 수 있고, 실시예들에 따른 수신 디바이스, 예를 들어, TV(10060) 또는 2nd 디바이스(10070)은 방송 데이터의 서비스 디스커버리(10030)을 DVB-I 프로바이더 또는 서버(10050)에 요청할 수 있고, 통합된 DVB-I 서비스 리스트(10040)를 수신하여, 네이티브 레벨에서 별도의 앱을 설치 및 실행하는 과정 없이 전통적 리니어 채널 및 인터넷 채널 모두 서비스 시그널링이 가능하다.
실시예들에 따른 방법/장치는 도1과 같은 구조에 기반하여 다음과 같은 문제점들을 해결할 수 있다.
메타데이터 업데이트 주기를 통해 다음/현재 가이드 정보를 제공 시, 서비스 리스트 전체 또는 개별 서비스의 요청의 엔드 포인트가 동일할 수 있다. 각 서비스 별로 개별 주기를 줄 수 없고, 동일한 엔드포인트로 프로토콜 통신을 해야 하는 한계를 실시예들에 따른 DVB-I 서비스 하이어라키(도15 등 참조)에서 최소 메타데이터 업데이트 주기@minimumMetadataUpdatePeriod 를 통해 해결할 수 있다.
센트럴 서비스 레포지토리또는 프라이베이트 레포지토리private repository 내에서 DVB-I 서비스 디스커버리 엔티티의 하나로 제조사 서비스 레포지토리Manufacturer service repository 를 추가 시, 지원 가능한 디바이스 캐퍼빌리티들을 해결할 수 있는 정보를 제공할 수 있다.
즉, 클라이언트에서 요구되는 서비스 리스트가 Device 내에서 지원가능한지 여부를 확인 할 수 있는 정보를 제공할 수 있다.
실시예들에 따른 DVB-I 는 주로 서비스 리스트 베이스로 서비스를 수신하고, 각 서비스 리스트는 특정 레포지토리(repository) 에서 운영 및 관리할 수 있다. 기존 DVB 방송 리스트를 제공하는 repository 는 현재 유럽 방송서비스 특성 상 국가나 특정지역 기준으로 LCN 의 할당하는 방식으로 취하여 DVB-I 서비스 리스트를 정의할 수 있다. 반면, 특정 DVB-I 서비스 리스트 프로바이더들은 지역에 관계없이 독립적인 서비스들을 수집하고 LCN list 를 정의하기 때문에 LCN allocation 은 service list provider 의 임의대로 설정이 가능하다. 따라서 이러한 배경 하에, DVB-I client 는 Multiple service list 들을 수신 및 merge시 채널 충돌의 잠재적인 이슈가 존재한다.
DVB-I over 5G 에서는 multiple distribution 에서 지원하는 delivery route 간 원활하고 연속성 있는 서비스가 되어야 하고, 최적의 네트워크 환경에 따른 효율적이고 유연한 접속을 통해 서비스를 제공할 수 있어야 한다.
기존의 Network connection 종류와 관계 없이 서비스 app 에서 지정한 지정 location 에 Restful API 만을 통해 미디어 데이터를 받아오기 때문에 서비스의 연속성과 동기화에 이슈가 없지만, DVB-I for 5G 의 경우 network 의 종류에 따라 bootstrapping 과정이 다르고, 사업자들의 인프라에 따라 bootstrapping 방법과 location 이 달라질 수 있다.
network 특성에 따라 전달되는 propagation delay 가 달라서 linear 서비스의 경우 제공되는 reference time 과 미디어 특성도 망마다 다른 환경의 제공이 될 수 있다.
사업자 마다 discovery URL, 미디어 location URL 이 모두 다르고 이 미디어 중간에 전환 시 완벽한 switching 이 어려운 이슈가 존재한다.
망 내에서 전환이 필요하다는 기준점과 신호품질의 저하라고 판단하는 기준이 명확히 존재하지 않는다.
서비스 리스트를 통해 UI 를 구성하고 user 에게 프리젠테이션 할 때 Audio, video, Subtitle 정보를 등 얼마나 구체적인 정보를 나타내야 할지 기준이 명확하지 않고, 기존 방송 전송과는 다르게, HDR/HFR 등 콘텐츠를 구성하는 오디오, 비디오, 서브타이틀의 획득경로가 MPD 레벨에 존재하여 Service UI 구성단계에서 정보를 알 수 없다.
기정의된 TVA Attribute 는 Audio, video, Subtitle 의 기본적인 정보(Framerate/resolution)만 포함하고 있어 User 의 접근/다운로드를 위해 불 충분한 정보이다.
실시예들은 DVB-I 서비스에서 User personalization 서비스를 추가 요구사항이 필요하며, 현재 DVB-I 표준에서 지원하기 어려운 기술적 구성의 한계를 해결하기 위한 솔루션을 작성하고자 한다.
실시예들은 인터넷 기반 방송(Internet-based Broadcast) 서비스를 제공하기 위해, 서비스 디스크버리(service discovery) 관련 방법과 기술을 제안한다.
실시예들은 인터넷 기반 방송 서비스 식별(Internet-based Broadcast service identification)을 위해 정의되어야 하는 추가 정보들을 제안한다.
실시예들은 인터넷 기반 방송 서비스 시그널링 획득을 위한 시스템 메커니즘을 제안한다.
실시예들은 통합된 서비스 리스트(Aggregated service list) 수신 시, 각 service 별 버저닝/만료(versioning/expiration) 관리 방법과 service 별 선택적 파싱과 저장 방법을 제공한다.
실시예들은 인터넷 linear 채널의 hidden/selectable/inactive 상태 시, 채널관리 방법을 제공한다.
DVB-I 서비스의 live program 이 over-running 시, 현재 소비중인 콘텐츠의 정보가 최신 정보가 아닌, 기존 프로그램 가이드의 정보를 presentation 하게 되는 문제점을 해결하기 위한 방법을 제공할 수 있다.
각 서비스 별로 개별 period 를 적용 가능한 새로운 element 및 end point 확장이 가능하다.
DVB-I client 가 Multiple service list 들을 수신 및 병합(merge) 시, 채널 충돌 이슈를 해결할 수 있다.
서로 다른 네트워크를 통해 전달되는 서비스 인스턴스(service instance) 간 전환이 합리적으로 원활하다고 인식 될 수 있도록, 서비스 인스턴스 간 적절한 얼라인먼트(proper alignment) 를 제공할 수 있다.
5GBC, 5GMS, OTT(LTE, Wifi 등 non 5G network) 를 포함하는 DVB-I Service instance 간 스위칭을 할 수 있다.
실시예들은 서비스 디스커버리 서버(discovery Server) 또는 서비스 리스트 서버(Service list server) 측에서 제공하는 정보를 통해 Service/Content guide UI 상에 콘텐츠 선택을 위한 필수정보들을 표시 할 수 있도록 서비스 인스턴스들(service instance)을 확장한다.
실시예들은 TVA Attribute 확장을 통해, 기존 scheme 에서 제공하지 못하는 정보를 확장하고 구체적인 비디오 정보를 정의하기 위한 분류 스킴 타입(ClassificationSchemeType)을 확장한다.
MPEG VVC codec 내의 subpicture 정보는 위치를 나타내는 좌표/크기이나, 비디오 인코딩 과정에서 필요한 CTU 레벨의 컨트롤을 위한 부가정보이거나 코덱 관점에 위치 정보일 뿐 랜더링을 위한 특정 좌표나 픽셀위치를 의미하지는 않는다. 즉, 렌더링 포지션(rendering position)에 대한 information 은 정의하지 않아, 관련 추가 확장이 필요하다.
실시예들은 인터넷 기반 방송(Internet-based Broadcast) 서비스를 제공하기 위해, 서비스 디스커버리 시그널링(service discovery signaling) 방안을 제공할 수 있다.
실시예들은 각 유니크(unique) 한 서비스 별로 프래그먼트된(fragmented)된 서비스 리스트(service list)가 멀티파트/관련 컨테이너(multipart/related container)에 포함되어 전송될 때 서비스 리스트 메타데이터 인벨롭(service list metadata envelop) 구조를 제공할 수 있다.
실시예들은 인터넷 linear 논리적 채널의 hidden/selectable/inactive case 내 사용자가 현재 채널에 직접 접근 시, 사용자에게 현재 채널 상태를 표시하거나 대체 채널을 제공하는 방법을 제공하라 수 있다.
DVB-I 서비스의 라이브 프로그램이 오버 러닝 , 현재 소비중인 콘텐츠의 정보가 최신 정보가 아닌, 기존 프로그램 가이드의 정보를 제공하는 문제점 해결을 위해, 실시예들에 따른 다음 정보를 이용할 수 있다: (1) 다이나믹 폴링 인터벌을 적용할 기준 시간 정보, (2) 기준 시;간 정보 (e.g. DVB-I service Availability end time) 으로부터 x sec 만큼의 오프셋, (3) 새롭게 적용 될 폴링 인터벌, (4) 기존 정보와 비교를 위한 버전 정보.
실시예들에 따른 방법/장치는 위 정보 및 @MinimumMetadataUpdatePeriod 에 기반하여 다이나믹 폴링을 할 수 있다.
Single Service 에 대응되는 Logical channel number 의 할당 시 해당 채널이 static pull 방식이 아닌 dynamic polling 을 적용하는 채널이라는 표시 정보를 제공할 수 있다.
현재 DVB-I hierarchy 에서 현재 소비되고 있는 now/next 의 Content Guide source 획득 시, ContentSourceType 내 @ScheduleEndPoint 의 정보가 service list type 과 service list 에 동일한 end point 로 정의되어 관련 정보를 요청 및 수신할 수 있다. 서비스 별로 개별 구간의 정보를 획득 할 수 있다.
특정 구간의 event 정보를 요청 및 수신 할 수 있도록 scheduleInfoEndPoint 를 생성할 수 있다.
DVB-I client 가 bootstrapping 과정에서 service discovery entities 들을 수신하고, 언어, 국가, 지역, postcode 에 따라서 필터링된 리스트 엔트리를 표시할 수 있다. 사용자 선택이나 환경에 맞춘 service entity 들과 그 service entity repository 들을 검색할 수 있다. 이때 제조사가 운영하는 service list repository 를 검색하게 하고, 해당 service list 의 지원 여부를 확인할 수 있는 device capability 정보들을 정의할 수 있다.
DVB-I client 가 Multiple service list 들을 수신 및 merge 시, 각 서비스에 할당된 채널에 특정한 조건을 부여함으로써, DVB-I client 내에서 채널 관리가 가능 할 수 있도록 지정할 수 있다. 이에 대한 솔루션으로 현재 DVB-I service list scheme 내 <LCNTableEntryType> 확장할 수 있다.
서로 다른 네트워크를 통해 전달되는 service instance 간 time alignment 를 지원하기 위한 service list scheme 확장할 수 있다.
Service instance switching 을 지원하기 위해 하기 DVB-I service list scheme 내 DASH delivery parameter 확장할 수 있다.
실시예들은 관련 정보를 확장하여 User 에게 서비스 선택의 기준을 명확하게 하고, 수신기 측면에서도 서비스 필터링을 수행을 통해 명확한 정보를 UI/UX상에 프리젠테이션 가능이 가능한 효과가 있다.
실시예들은 VVC 인코딩 기반 서브 픽쳐(subpicture)들을 display 하기 위한 씬 디스크립션(scene description) 및 렌더링 정보(rendering information)의 솔루션을 제안할 수 있다.
실시예들은 시스템 레이어(system layer)인 DVB-I 와 DASH layer 에서 video 특성을 정의하는 위치에 scene description 정보를 확장하고, 실제 subpictute 를 encapsulation 하는 hierarchy 의 정보들을 참조하라 수 있다.
실시예들은 관련 use case 를 지원하기 위한 수신기 동작과 수신기 역호환성을 고려할 수 있다.
기존의 Traditional Tuner를 탑재하지 않은 수신기에서 Broadband망을 통해서 Internet-based Broadcast Service Discovery 및 Acquirement를 할 수 있다.
Aggregated service list 수신 시, 각 service 별 versioning/expiration 관리 방법과 service 별 선택적 파싱과 저장으로 전체 Aggregated service list 를 수신 할 필요가 없는 효과가 있다.
인터넷 linear 채널의 hidden/selectable/inactive 시, 사용자에게 방송이 나오지 않는 불편함을 주는 논리적 채널 서비스를 막고, 인터넷 리턴 채널 대체 서비스를 제공함으로써 보다 나은 미디어 서비스를 제공할 수 있다.
실시예들에 따른 장치는 tune-in 또는 channel change 시, over-running 하고 있는 프로그램의 가이드를 보여주는 것이 아닌 해당 채널의 up-to-date 한 정보를 표시할 수 있다.
DVB-I dynamic polling 을 위한 client-side algorithm 을 적용 시, Service list 레벨의 content guide 전체 속성에 정의하여 콘텐츠 가이드 전체의 polling 동작을 제어할 수 있거나, service 레벨에 정의하여 개별 서비스에 dynamic 한 polling algorithm 을 적용할 수도 있다.
DVB-I client 내에 service 와 대응되는 logical channel database 를 관리하는 별도의 caching module 에서, 해당 채널의 속성을 dynamic 으로 처리하여 전체 or 개별 서비스 업데이트 시 해당 채널이 dynamic polling algorithm 을 적용하는 채널이라는 것을 사전에 표시할킬 수 있다.
DVB-I service event 나 Content guide 정보를 업데이트 시, 서비스 별 개별 구간을 업데이트 할 수 있는 end point 를 추가하여, client 내 최신 정보를 업데이트할 수 있다.
Device 에 따라 사용자 선택이나 환경에 맞춘 service entity 들과 그 service entity repository 들을 검색할 수 있고, 특정 제조사가 지원하는 서비스 리스트를 검색하여 소비할 수 있는 기회를 제공한다.
DVB-I client 가 Multiple service list 들을 수신 및 merge 하는 경우 또는 기본 legacy 채널에 추가 서비스 리스트를 수신할 때, 서비스 제공자의 의도를 반영하고 DVB-I client 가 이슈 없이 처리 있는 channel ordering 방법을 제공 할 수 있다.
DVB-I 내 5GBC, 5GMS, OTT 등을 포함하는 multiple distribution 에서 지원하는 delivery route 간 원활하고 연속성 있는 서비스가 되어야 하고, 최적의 네트워크 환경에 따른 효율적이고 유연한 접속을 통해 서비스를 사용자에게 제공할 수 있다.
실시예들은 확장된 정보를 통해 User 에게 현재 제공될 수 있는 서비스를 명확히 보여주고, 합리적인 선택이 가능하게 유도하며 서비스 선택의 기준을 명확하게 할 수 있다.
실시예들은 DVB-I 기반 Service 내에 여러 subpicture 들을 전송하여 모드에 따라 다른 viewport 를 제공하여 개인화된 서비스를 제공할 수 있다.
실시예들에 따른 방법/장치는 DVB-I A177 문서를 참조할 수 있다.
전통적인 IP 기반 linear 채널 서비스는 특정 사업자(e.g. ISP, Network operator )의 가입을 통해, authentication 을 부여 받고 사업자가 제공하는 STB 를 통해 IP linear service 를 받는 형태이다. 또한 최근에는, connectivity TV 의 등장으로 STB-less 형태의 IP linear 서비스를 소비도 가능하다. 대표적인 표준 기술로는 ATSC 3.0, IBB, HbbTV로, client 는 TV 내부의 OS 플랫폼 위의 application 을 동작하여 다양한 linear rich-media 서비스를 받을 수 있다. 다양한 operator 들은 자체적으로 개발만 서비스 application 을 TV 플랫폼 위에 설치 할 수 있게 제공하고, application 에서는 서비스를 위한 데이터들을 제공 받을 수 있는 서버와 요청/수신을 가능하게 하는 API 들을 정의하고 있다. 그 life cycle 기반 위에 Client 는 TV UI 를 통해, app 에 접근하고 app을 통해 다양한 서비스를 수신할 수 있다.
북미, 유럽 전세계적으로 linear TV 시청만큼 OTT 채널의 선호도가 높아져, 이러한 OTT 시장의 확대는 IP based device 의 필수적인 media application 으로서 자리 잡았다. 하지만 영향력 있는 OTT 의 형태는 독자적인 플랫폼과 OTT 만의 서비스 eco-system 으로 독점적인 서비스가 되었다. 다시 말해, 각 OTT 만이 제공하는 codec, protocol stack, application, browser 등 독자적인 app-ecosystem 소비형태를 보이고 있다.
현재 DVB-I 는 A177 문서를 기반하여 industry 에서 reference client application 을 개발하고 있고, DVB-I 표준화 그룹 내에서 개발 이슈 및 현 표준의 문제점을 파악하고, 그에 맞는 extension 과 원활한 개발을 위한 clarification 을 진행하고 있다.
DVB-I phase 1 의 backward compatibility 를 유지하면서, over-running 의 이슈 발생시 해결 할 수 있는 방안을 고안하였다.
DVB-I dynamic polling 을 위한 client-side algorithm 적용 시 DVB-I service hierarchy 에 따라 다른 역할과 수신기 동작이 이루어 지므로 @MinimumMetadataUpdatePeriod 위치에 따른 수신기 동작을 상술하였다.
content guide manager 와 service list manager 는 별도의 parsing 및 caching 과정이 이루어지고, 획득된 LCN DB 정보를 관리하는 과정에서 dynamic 하게 변경될 수 있는 채널에 indication 이 필요하므로 해당 정보를 확장함.
Single Service 에 대응되는 Logical channel number 의 할당 시 해당 채널이 static pull 방식이 아닌 dynamic polling 을 적용하는 채널이라는 indication 정보 추가
DVB-I phase 1 scheme 는 pull-only 방식에 따라 데이터를 수신하므로, code 레벨의 최신 정보 획득여부를 확인 할 수 없다. 이러한 기술적 배경에서 최신 정보의 업데이트를 위해 실시예들에 따른 장치의 DVB-I client 는 특정 구간 polling interval 을 통해 문제점을 해결할 수 있다.
현재 service hierarchy 는 service list or service 레벨에서 한번에 event 정보를 획득 할 수 있으나, 그 방법은 두 레벨 모두 동일한 방법을 사용하고 있어, 개별 서비스 별 특정 구간의 업데이트는 불가능한 정의이므로, 해당 솔루션을 고안하고자 한다.
본 특허에서는 이러한 OTT 들의 독점적 플랫폼, application 의 동작의 대한 dependency 등의 이슈들을 해결하기 위한 발명을 다루고자 한다.
기존 기술과 같이 App 을 반드시 실행하여 T, S, C linear channel 서비스와 유사한 채널 UX 를 제공하는 형태가 아닌, 수신기 native 레벨에서 서비스를 discovery 하고 client 가 접근 가능한 서비스 서버에 접근하여 linear 서비스를 수신하는 서비스를 제안하고자 한다.
또한 OTT 의 독자적인 플랫폼을 하나의 통일된 TV native 플랫폼으로 통합하여 사용자에게 OTT app을 실행하지 않고, 채널 내에 OTT 콘텐츠를 받아 볼 수 있는 서비스 시나리오를 제안한다.
도2는 실시예들에 따른 네트워크 오퍼레이터/ISP 측면에서 실시예들에 따른 동작의 흐름도를 나타낸다.
실시예들에 따른 장치(20000)는 TV수신기일 수 있다. 즉, DVB-I 서비스를 지원하는 하이브리드 IPTV/DTT 네트워크에 따른 디바이스일 수 있다. 수신 장치(20000)는 STB와 연결될 수 있다. 연결 방식은, 예를 들어, HDMI 등으로 이뤄질 수 있다. IPTV STB는 지상파 네트워크를 통해 지상파 헤드엔드로부터 지상파 방송 신호를 수신할 수 있고, 홈 게이트웨이 및 브로드밴드 네트워크를 통해서 멀티캐스트 서비스를 제공하는 멀티캐스트 헤드앤드, DVB-I서비스를 제공하는 DVB-I 소스, 및/또는 인터넷 컨텐츠 등을 제공하는 CDN(Content Delivery Network) 등으로부터 각종 서비스 및/또는 데이터를 수신할 수 있다.
특히, OTT 의 경우, 기존의 단말마다 다른 OS 환경에 맞는 OTT 어플리케이션을 따로 제공하는 문제점이 있을 수 있다. 하지만, 실시예들에 따른 방법/장치는 이러한 별도의 어플리케이션 없이, 인더스터리 스탠다드 기반 에코 시스템(industry standard based ecosystem) 으로 서비스를 이용할 수 있다. 이는 커먼(common)한 서비스 인터페이스(interface)를 제공함으로써, 편리하고 효율적인 서비스 접근을 제공하는 효과가 있다.
도3은 실시예들에 따른 DVB 채널 서비스에 대한 프로토콜의 스택을 나타낸다.
도2의 TV장치(20000)가 도3의 프로토콜 구조에 기반하여 도1의 시나리오를 수행할 수 있다.
실시예들에 따른 서비스는 DVB C/S/T/I 서비스를 포함한다. 도3의 DVB-C(30000)/S(30010)/T(30020)/I(30030) 서비스를 구성하는 프로토콜 스택 구조에 기반하여, 실시예들은 인터넷을 통해 전송되는 DVB-I 서비스를 디스커버리하기 위한 메타니즘 및 그에 따른 시그널링 방안에 대해 제안한다. 실시예들에 따른 방법/장치는 서비스 디스커버리를 통해 어플리케이션을 구동할 수 있고, 실시예들에 따른 어플리케이션(30040)은 네이티브 어플리케이션, 프리-인스톨된 어플리케이션, 유저-셀렉팅된 어플리케이션 등을 포함할 수 있다.
도4는 실시예들에 따른 서비스 디스커버리 리스트 테이블의 확장 신택스를 나타낸다.
실시예들에 따른 방법/장치는DVB-I 서비스의 보다 빠른 SERVICE DISCOVERY및 서비스 획득을 위한 SDLT 를 구성할 수 있다. 도4는 도11, 도19, 도28, 도39, 도49, 도56, 도68 등의 서비스 리스트에 포함되는 정보를 나타낸다.
실시예들은 서비스 발견 과정을 통해 사용자에게 제공될 수 있는 서비스 중에서 사용자가 선택한 서비스를 보다 빠르게 제공하기 위해서 Service Discovery List Table (SDLT)와 USBD 구성 방안을 도4와 같이 제안한다.
SDLT는 서비스 디스커버리를 위해 가장 먼저 수신기에서 지녀야할 필수적(essential)인한 정보일 수 있다. 이 시그널링 데이터를 통해 수신기에서는 사용자가 서비스를 선택할 수 있도록 하는 서비스 리스트 정보를 제공할 수 있고, 이 때에 더 많은 정보를 포함할 수 있도록 SDLT를 구성할 수 있다. 이러한 구성 정보는 풍부한 양의 서비스 제공 및 사용자의 서비스 선택 시 보다 빠른 서비스 플레이를 가능할 수 있도록 하는 효과를 지닌다.
이와 같이 SDLT를 구성하면, 인터넷 기반의 서비스의 시그널링 메타데이타중 USBD는 MPD와 mapping되는 정보를 제공하는 딜리버리 방법(DeliveryMethod) 요소값을 포함하며, @serviceId, @globalServiceId 정보는 SDLT와 mapping하기 위한 정보 및 ESG와 mapping 하기 위한 정보로 사용될 수 있다.
도면을 참조하여 SDLT의 각 엘리먼트를 설명한다.
서비스 디스커버리 리스트 테이블(ServiceDiscoveryListTable)는 루트 엘리먼트를 나타낸다.
SDLT인터넷URL(SdltInetUrl)은 시그널링/ESG 오브젝트들에 접근하기 위한 URL을 나타낸다.
URL타입(@urlType)은 이 URL로 이용가능한 파일들의 타입을 나타낸다.
서비스(Service)는 서비스 인포메이션을 나타낸다.
서비스아이디(@serviceId)는 오리지널 네트워크 아이디(originalNetworkId)의 범위 내 이 서비스를 유니크하게 식별하는 넘버를 나타낸다.
글로벌 서비스 아이디(@globalServiceId)는 글로벌한 유니크 서비스 식별자를 나타낸다. 이 값은 ESG 내 글로벌 서비스 아이디와 매핑된다. 전통적인 DVB/T/S/C서비스들을 위해서, 이 어트리뷰트는 존재하지 않을 수 있다.
오리지널 네트워크 아이디(@originalNetworkId)는 이 서비스가 원래 생성된 오리지널 네트워크를 유니크하게 식별하는 넘버를 나타낸다.
트랜스포트 스트림 아이디(@transportStreamId)는 트랜스포트 스트림을 유니크하게 식별하는 넘버를 나타낸다. 이 어트리뷰트는 전통적인 DVB-T/S/C서비스 내 존재한다. 그러나, 이 어트리뷰트는 ISO BMFF 포맷의 DVB-T서비스을 위해서 존재하지 않을 수 있다.
프리퀀시 넘버(@frequencyNum)는 피지컬 레이어의 프리퀀시 넘버를 유니크하게 식별하는 넘버를 나타낸다. 이 어트리뷰트는 전통적인 지상파 서비스인 경우 존재할 수 있다.
서비스 카테고리(@serviceCategory)는 이 서비스의 카테고리를 나타낸다. 카테고리는 리니어, 온-디맨드, 또는 어플리케이션 서비스일 수 있다.
서비스 시퀀스 넘버(@svcSeqNum)는 서비스 인포메이션의 버전을 나타낸다. 이 값은RFG내 서비스 데이터의 각 새 버전마다 1씩 증가할 수 있다.
컨텐츠포맷(@contentFormat)은 이 서비스의 컨텐츠들의 포맷을 나타낸다.
히든(@hidden)은 이 서비스가 서비스 리스트 내 히든인지 사용자들에게 보여지는지 여부를 나타낸다. 이 값의 디폴트 값은 FALSE이다.
앱 렌더링(@appRendering)은 어플리케이션이 처음으로 실행되는지 이 서비스를 렌더링하는지를 나타낸다. 이 값의 디폴트값은 FALSE이다.
미디어 프리젠테이션 디스크립션(@MediaPresentationDescription)은 MPD시그널링 디스크립션을 포인팅하는 URL이다.
어플리케이션 인포메이션 테이블(@ApplicationInformationTable)은 AIT시그널링 디스크립션을 포인팅하는 URL이다.
디스트리뷰션 윈도우 디스크립션(@DistributionWindowDescription)은 DWD시그널링 디스크립션을 포인팅하는 URL이다.
러닝 상태(RunningStatus)는 이 서비스의 상태를 나타낸다.
도5는 실시예들에 따른 채널의 관리의 예시를 나타낸다.
도5는 도4의 히든 엘리먼트를 나타낸다.
DVB-I 서비스 제공 시 Linear 채널의 선택방법은 2가지로, 사용자가 직접 채널번호를 선택하거나, 채널 서핑을 통해 채널의 선택이 가능하다. DVB internet 채널의 특성을 고려하면, HTTP 망을 기본으로 하여 unicast를 받거나, Multicast 형태로 linear 채널 서비스를 제공할 수 있다. DVB-I 는 DVB 의 방송인 채널의 수신이 dedicated frequency 와 논리적 채널로 불특정 다수에게 전달하는 것과는 다르게, internet 이라는 subscribe 및 streaming 형태이므로, 채널의 hidden / inactive 채널관리가 필요하다.
예를 들어, 방송망 ATSC 1.0는 채널의 관리를 아래와 같이 정의할 수 있다.
히든(@Hidden): 논리적 채널의 표시 또는 미표시를 의미하는 bool 값으로, 사용자의 논리적 채널의 검색이나, 사용자의 직접 채널 엔트리(entry) 선택 시 표시 미 표시의 속성을 의미한다.
히든 가이드(@hide_guide): EPG 상에 논리적 채널의 표시 또는 미표시를 의미하는 bool 값으로, 사용자의 채널 가이드 표시/미표시 속성을 의미한다.
이와 같은 방식은 RF 방송환경 기반 채널관리 방법으로, 채널의 관리를 서비스 리스트 내 정보만으로 수동적으로 관리 할 수 밖에 없었다. 하지만, DVB-I 의 환경에서는 리턴 채널이 존재하여, 다양한 채널관리 방법이 존재할 수 있다.
실시예들은, DVB-I 환경에서 채널 hidden/inactive 시, 리턴 채널을 이용하여, 사용자가 해당 채널의 존재/상태를 판단할 수 있으며, 대체(alternative) 서비스를 통해 기존 방송의 hidden/inactive 채널의 관리를 용이하게 할 수 있다.
hide_guide (=1) 및 Hidden(=1)인 경우, 추가적으로, 앱 서비스에 접근이 가능함을 시그널링할 수 있다.
@Hidden(visible): 논리적 채널의 표시 or 미 표시를 의미하는 bool 값으로, 사용자의 논리적 채널의 검색이나, 사용자의 직접 채널 entry 선택 시 표시 미 표시의 속성을 의미한다.
@selectable: Set 이면, 논리적 채널번호에 직접 입력으로 숨겨진 서비스를 선택할 수 있고, false면 숨겨진 서비스에 사용자가 직접 입력해도 선택할 수 할 수 없다.
@hidden_guide: hidden 채널의 상태에서 채널 직접 접근 시, 채널 내 상태를 가이드 해주거나 연결 link 를 통해 대체 할 수 있는 화면을 보여줄 수 있다. 다양한 형태의 채널 가이드 방법을 나타내는 type 값을 나타낸다.
@hidden(visible)_presentation: hidden_guide 를 통해, 정의된 type 값에 따라 해당 anyURI 정보를 정의한다.
도6은 실시예들에 따른 타입에 따른 히든 프리젠테이션을 나타낸다.
히든(@Hidden(visible)): 논리적 채널의 표시 또는 미표시를 의미하는 bool 값으로, 사용자의 논리적 채널의 검색이나, 사용자의 직접 채널 엔트리(entry) 선택 시 표시, 미표시의 속성을 의미한다.
셀렉터블(@selectable): 세팅(Set)되면, 논리적 채널번호에 직접 입력으로 숨겨진 서비스를 선택할 수 있고, false이면 숨겨진 서비스에 사용자가 직접 입력해도 선택할 수 할 수 없다.
히든 가이드(@hidden_guide): hidden 채널의 상태에서 채널 직접 접근 시, 채널 내 상태를 가이드 해주거나 연결 링크(link)를 통해 대체 할 수 있는 화면을 보여줄 수 있다. 다양한 형태의 채널 가이드 방법을 나타내는 타입(type) 값이 있을 수 있다.
히든 프리젠테이션(@hidden(visible)_presentation): hidden_guide 를 통해, 정의된 type 값에 따라 해당 anyURI 정보를 정의한다.
도6은 히든 프리젠테이션 관련 히든 가이드의 타입을 나타낸다.
타입이 0x0001인 경우, 서비스 프로바이더의 대체 링크를 나타내고, 히든 프리젠테이션은 연결 주소, 예를 들어, www.bbc.co.kr/alternative/music 를 제공할 수 있다.
타입이 0x0002 인 경우, 대체 채널의 링크된 서비스를 나타내고, 히든 프리젠테이션은 DVB 트리플릿, 예를 들어, DITS-(OriginalNetworkID)-(TransportStreamID)-(serviceID) 을 시그널링할 수 있다.
타입이 0x0003인 경우, 스테레오스코픽 채널 가이드를 나타내고, 히든 프리젠테이션은 DVB 트리플릿, 예를 들어, DITS-(OriginalNetworkID)-(TransportStreamID)-(serviceID) 을 시그널링할 수 있다.
타입이 0x0004인 경우, ESG 또는 BCG(브로드밴드 컨텐츠 가이드)링크(ESG, BCG(Broadband Content Guide) link)를 나타내고, 히든 프리젠테이션은 loginformDB.html 을 시그널링할 수 있다.
타입이 0x0005인 경우, 대체 앱 서비스를 나타내고, 히든 프리젠테이션은 app 전용 채널을 시그널링할 수 있다. 이로 인하여, 수신 장치는 AIT 활용한 app 접근이 가능하다.
도7은 실시예들에 따른 히든 채널 관리의 흐름도를 나타낸다.
도7은 도6 관련 히든 채널에 기반하여 채널을 처리하는 흐름도이다.
상술한 실시예들의 동작을 흐름도로 설명하면 다음과 같다.
41000단계에서, 수신 장치의 전원이 활성화되면, 수신 장치는 채널/서비스의 히든 여부를 확인한다. 히든이 없으면, 수신 장치는 볼 수 있는 채널 및 볼 수 있는 채널 가이드를 디스플레이에 표시한다.
41010단계에서, 히든이 있고 채널 서핑이 불가한 경우, 수신 장치는 셀렉터블을 확인한다. 셀렉터블이 아닌 경우 채널이 비활성화이고, 채널 가이드를 볼 수 없음을 사용자게에 수신 장치가 알린다. 셀렉터블이 예스인 경우, 수신 장치는 히든 가이드, 히든 프리젠테이션에 기반하여 히든 채널을 대체적으로 처리/디스플레이할 수 있다.
도8은 실시예들에 따른 SDLT에 관련 머터리얼(Related Material)이 포함된 예시를 나타낸다.
도8은 도4등에 관련된 SDLT의 신택스이다.
도8을 참조하여, DVB-I 파트-타임 서비스(part-time service) 시, 서비스가 인엑티브(inactive) 시 서비스 관련 머터리얼(service Related Material) 를 제공하는 방법을 설명한다.
상술한 바와 같이, DVB-I 서비스는 인터넷 리니어 채널을 제공할 수 있고 서비스 디스커버리 과정에서 특정 LCN 에서 서비스를 파트타임(part-time) 형태로 제공할 수 있다. 이러한 서비스 스테이트의 아웃사이드(outside of service state)에서 사용자가 채널 번호를 통해 직접 선택했을 때 혼란을 주지 않기 위해, 인액티브(inactive)의 서비스 배너(service banner) 이미지나, 추가 어플리케이션(application)을 통해 채널 변화API(channel change API)를 실행하거나 부가적인 VoD 서비스를 제공 할 수 있다. 이와 관련하여, 실제 인더스트리(industry) 에서 사용하는 데이터타입(datatype) 값을 적용하여 실제 프렉티스(real practice)에 맞는 계층(hierarchy)을 제안한다.
도8의 SDLT는 상술한 실시예들에 따른 SDLT와 대응될 수 있고, 추가된 엘리먼트/필드를 설명하면 다음과 같다.
@LCN은 로지컬 채널 넘버를 나타낸다.
RelatedMaterial는 다음과 같은 엘리먼트를 더 포함할 수 있다.
관계(@HowRelated:href)는 값을 전달하는 @href 엘리먼트와 함께 전달될 수 있다.
미디어 로케이터(MediaLocator)는 미디어의 로케이션에 관한 정보를 전달할 수 있다. 구체적으로, MediaURI는 XML AIT 파일 또는 이미지에 대한 URI를 포함하는 값일 수 있고, @contentType이 이 값을 전달할 수 있다.
어베일러빌리티(Availability)는 이 서비스의 상태(running, not running or starts in a few seconds, etc.)를 나타낸다.
@ValidFrom는 이 서비스가 유효하게 되는 시간/날짜를 나타낸다. 이 값이 기술되지 않는 경우, 이 서비스가 이미 이용 가능함을 알 수 있다.
@ValidTo는 이 서비스가 소멸하게 되는 시간/날짜를 나타낸다. 이 값이 기술되지 않는 경우, 이 서비스가 무기한으로 이용 가능함을 알 수 있다.
@Days는 이 서비스가 한 주의 어느 날에 이용 가능한지를 나타낸다. 이 값이 기술되지 않으면, 이 서비스는 모든 날에 이용 가능함을 말해준다. 예를 들어, ServiceDays=”1 4 7”인 경우, 서비스는 오직 월요일, 목요일, 토요일에 이용 가능함을 나타낸다.
@Recurrence는 이 서비스를 위한 예정된 이용가능성의 주간 케이던스를 나타낸다. 이 값이 기술되지 않는 경우, 매 주마다 리커런스가 발생함을 나타낸다.
DVB-I 서비스는 인터넷 리니어 채널을 제공할 수 있고 서비스 디스커버리 과정에서 특정 LCN 에서 서비스를 파트타임(part-time) 형태로 제공할 수 있다. 이러한 서비스 스테이트의 아웃사이드(outside of service state)에서 사용자가 채널 번호를 통해 직접 선택했을 때 혼란을 주지 않기 위해, 인액티브(inactive)의 서비스 배너(service banner) 이미지나, 추가 어플리케이션(application)을 통해 채널 변화API(channel change API)를 실행하거나 부가적인 VoD 서비스를 제공 할 수 있다. 이와 관련하여, 실제 인더스트리(industry) 에서 사용하는 데이터타입(datatype) 값을 적용하여 실제 프렉티스(real practice)에 맞는 계층(hierarchy)을 제안한다.
실시예들에 따른 수신기는 <Availability> 엘리먼트 내 어트리뷰트들을 통해, part-time service 의 실제 유효시간을 시그널링하고, 인액티브 기간(inactive period)을 확인한다. 해당 기간(period)에서 LCN 에서 보여지는 화면은 <RelatedMaterial> 의 엘리먼트에서 정의한 속성으로 인액비트 스테이트(inactive state)를 보여질 수 있다. @MediaURI 는 상술한 hidden(visible)_presentation URI 와 동일한 속성으로 HbbTV(AIT) 앱 시그널링과 앱 라이프-사이클(app life-cycle)을 그대로 따르고, 이 값이 생략 되었을 시 @ ApplicationInformationTable 에서 정의한 URI 를 통해서 inactive 대체 서비스를 제공할 수 있다. @MediaURI 의 content_type 이 "image/png" 일 시 inactive service banner 를 나타낼 수 있다. @MediaURI attribute 에서 content_type 에 따라 이미지(image) 와 앱 시그널링(app signaling)을 인액티브 서비스(inactive service) 제공할 수 있다.
예를 들어, @MediaURI에 따라, 수신 장치는 http://img-ctv.digitaluk.co.uk/channel7/service_a_linear.png의 이미지(image/png)(배너)에 기반하여 인액티브 스테이트를 제공할 수 있다.
@MediaURI에 따라, 수신 장치는 http://www.channel9.co.uk/player/ait.aitx?channel=channela의 application/vnd.dvb.ait+xml(어플리케이션)에 기반하여 인액티브 스테이트를 제공할 수 있다.
도9는 실시예들에 따른 RelatedMaterial 신택스를 나타낸다.
도8에서 설명한 RelatedMaterial 의 신택스는 도9와 같다.
도10는 실시예들에 따른 인엑티브 배너의 활용 예시를 나타낸다.
도10는 도7등에서 채널 관리하는 예시에 포함될 수 있다.
도9는 비활성화 서비스(inactive service) 시, 특정 LCN(로지컬 채널 넘버)에서 적용될 수 있는 UI/UX 이다. 수신 장치는 디스플레이상에 ESG(44000)를 디스플레이할 수 있다. ESG(44000) UI/UX 중 LCN 6번의 경우, 수신 장치는 현재 서비스 없는(No service) 상태로 서비스 없음을 나타내는 배너(No service banner) 와 같이 대체 어플리케이션(application)을 제공할 수 있다(44010). 빈 화면 상에 대체 어플리케이션이 실행되거나, 사용자가 대체 어플리케이션을 선택하는 신호를 리모트 컨트롤러 등을 통해서 수신 장치가 수신하고, 이와 관련된 동작을 실행할 수 있다.
도11는 실시예들에 따른 서비스 리스트 계층 구조를 나타낸다.
도11는 도1의 서비스 시나리오를 위한 서비스 리스트 계층 구조이다.
DVB-I 서비스 리스트(Service list)는 각 service 들을 포함할 수 있고, 각 service 는 서비스 인스턴스(service instance)들을 포함할 수 있다. 각 딜리버리 네트워크(delivery network)에 따라 Service instance 를 다수 개를 정의할 수 있으며, 유니크니스(uniqueness)는 소스 타입(source_type) 의 URN 에 따라서 구분이 가능하다.
DVB 서비스 리스트 타입(45000)은 서비스 별로 DVB-I 서비스 타입(45010)을 레퍼런스하라 수 있다. DVB-I 서비스 타입(45010)은 관련 머터리얼(Related Material) 및 가이드 소스(Guide Source)를 시그널링한다. DVB-I 서비스 타입(45010)은 서비스 인스턴스 별로 서비스 인스턴스 타입(45020)을 레퍼런스할 수 있다. 서비스 인스턴스 타입(45020)은 관련 머터리얼에 대한 구독 패키지 및 URN을 위한 소스 타입을 시그널링한다. 이는 DVB T/S/C에 대한딜리버리 파라미터 타입, RTSP딜리버리 파라미터 타입, 멀티캐스트 딜리버리 파라미터 타입, DASH딜리버리 파라미터 타입 중 적어도 하나를 레퍼런스할 수 있다.
제안된 소스 타입 URN들(45030)은 DVB T/S/C/I[TV/DASH등에 대한URN을 제공한다.
DVB서비스 리스트 타입(45000)은 LCN테이블 리스트 타입을 레퍼런스하고, LCN테이블 리스트 타입은 LCN테이블 타입을 레퍼런스한다. LCN테이블 타입, DVB서비스 리스트 타입(46000), DVB-I 서비스 타입(45010)은 리젼(REGION)을 레퍼런스할 수 있다. 서비스마다 관련된 지역 정보가 달라질 수 있다.
도11의 엘리먼트들의 상세한 설명은 이하의 각 도면을 참조하여 기술된다.
도12는 실시예들에 따른 DVB-I 서비스 리스트 타입을 나타낸다.
도12는 도11에 포함된 서비스 리스트 정보이다.
서비스 리스트(ServiceList)는 서비스 제공자에 의해 제공되는 IP서비스들의 세부 사항 및 로케이션들의 리스트이다. 서비스 프로바이더는 그들의 서비스를 복수 개의 서비스 리스트들로 분할할 수 있다. 이 어트리뷰트는 필수사항이다.
네임(Name)은 읽을 수 있는 형태의 서비스의 이름이다. 복수 개의 서비스 리스트 이름들은 서로 다른 언어로 표현될 수 있다. 이 어트리뷰트는 필수사항이다.
프로바이더 네임(ProviderName)은 판독 가능한 서비스 리스트의 프로바이더의 네임이다. 프로바이더의 복수 개의 값들은 서로 다른 언어로 기술될 수 있다. 이 어트리뷰트는 필수사항이다.
관련된 머터리얼(RelatedMaterial) 이 서비스에 관련된 추가적인 머터리얼을 나타낸다. 이 어트리뷰트는 옵셔널하다.
리젼 리스트(RegionList)는서비스 리스트 내 서비스 또는 서비스 리스트의 지역적 정보를 제공하는데 사용되는 로지컬 식별자를 갖는 지역적 리젼들의 리스트이다. 이 어트리뷰트는 옵셔널하다.
타겟 리젼(TargetRegion)은 이 서비스 리스트가 타겟되어 리젼 리스트 내 기술되는 리젼들의 식별자이다. 이 어트리뷰트는 옵셔널하다.
LCN테이블 리스트(LCNTableList)는 각 서비스에 대한 지역화되고 패키징화된 로지컬 채널 넘버를 정의하는 테이블들의 리스트이다. 이 어트리뷰트는 옵셔널하다.
서비스(Service)는 서비스 리스트의 부분을 이루는 서비스이다. 이 어트리뷰트는 옵셔널하다.
버전(@version)은 서비스 리스트의 버전 넘버이다. 매 퍼블리시되는 변화마다 그 값이 증가한다. 이 어트리뷰트는 필수사항이다.
도13은 실시예들에 따른 DVB-I 서비스 타입을 나타낸다.
도13의 DVB-I서비스 타입은 상술한 서비스 타입을 테이블 형태로 설명한 것이다.
유니크 식별자(UniqueIdentifier)는 서비스의 유니크한 아이디이다. 이 아이디는 하나의 서비스에 대해 절대 변하지 않을 수 있다. 이 서비스의 다른 파라미터들은 변할 수 있다. 이 어트리뷰트는 필수사항이다.
서비스 인스턴스(ServiceInstance): 이 서비스를 위한 A/V컨텐츠가 있는 인스턴스이다. 이 어트리뷰트의 타입의 복수 개의 엘리먼트들이 존재하고 이용가능한 경우, 우선순위(@priority) 어트리뷰트가 낮은 값을 가지는 것이 높은 우선 순위를 가질 수 있다(혹은 그 반대도 가능하다). 주어진 서비스에 대한 모든 서비스 인스턴스들은 같은 컨첸츠를 가질 수 있다. 이 어트리뷰트는 옵셔널하다.
타겟 리젼(TargetRegion)은 서비스가 수신되는 리젼이다. 이 값이 기술되지 않으면, 어느 리젼 제약도 존재하지 않는다. 이 어트리뷰트는 옵셔널이다.
서비스 네임(ServiceName)은 서비스의 이름이다. 서비스 네임들은 다양한 언어로 기술될 수 있다. 이 어트리뷰트는 필수사항이다.
프로바이더 네임(ProviderName)은 읽을 수 있는 이 서비스의 프로바이더 네임이다. 이 엘리먼트는 다양한 언어로 기술될 수 있고 필수사항이다.
관련된 머터리얼(RelatedMaterial)은 이 서비스에 관련된 추가적인 머터리얼이다. 머티리얼이라 함은, 예를 들어, 서비스 이용 불가 배너, 서비스 관련 어플리케이션, 서비스 로고들 등을 포함할 수 있다. 이 어트리뷰트는 옵셔널하다.
서비스 장르(ServiceGenre)는 서비스의 장르이다. 이 값은 옵셔널하다.
서비스 타입(ServiceType)은 서비스의 타입이다(ETSI EN 300 468의 설명을 참조할 수 있다). 이 값은 옵셔널하다.
레코딩 정보(RecordingInfo)는 DVB-I 클라이언트가 이 서비스로부터 컨텐츠가 레코딩되는지, 타임-시프트되는지 또는 다시 분배되는지 아닌지 여부를 결정할 수 있도록 알려주는 정보이다. 이 값은 옵셔널하다.
가이드 소스는 이 서비스의 메타데이터를 전달하는 브로드밴드 컨텐츠 가이드의 상세 내용이다. 이 값은 옵셔널하다.
버전(@version)은 이 서비스의 버전 넘버이다. 매 퍼블리쉬되는 변화마다 그 값이 증가한다. 이 값은 필수사항이다.
도14는 실시예들에 따른 서비스 인스턴스 타입을 나타낸다.
도14를 참조하여, 서비스 인스턴스 타입의 엘리먼트들을 설명한다.
디스플레이 네임(DisplayName)은 구제적인 서비스 위치에 관련된 서비스의 판독 가능한 이름이다. 멀티플 서비스 네임들은 다양한 언어로 기술될 수 있다. 이 값이 존재하지 않는 경우, 서비스네임 필드가 사용될 수 있다. 이 어트리뷰트는 옵셔널하다. 한편, 본 명세서에서 어트리뷰트는 엘리먼트, 필드, 정보, 값 등 레벨에 맞게 서로 대응되고, 다양하게 지칭될 수 있다.
관련된 머터리얼(RelatedMaterial)은 서비스에 관련된 추가적인 머터리얼이다. 구체적으로, 노 서비스 배너, 서비스 관련 어플리케이션, 서비스 로고 등이 있을 수 있다. 서비스 인스턴스 엥ㄹ리먼트 내에서 제공되는 관련(HowRelated) 어트리뷰트의 특정 값을 갖는 관련 머터리얼은 서비스 엘리먼트 내 제공되는 관련(HowRelated) 어트리뷰트의 값을 갖는 대응하는 관련된 머터리얼을 대체한다. 이 엘리먼트는 옵셔널하다. 또는 HowRelated 에서 @href sting 에 대응하는 property 를 획득할 수 있다
DRM시스템 아이디(DRMSystemId)는 서비스를 위해 사용되는 컨텐츠 프로젝션 방식을 나타낸다. 이 값은 문서 DVB A168의 @schemeIdURI 값과 같을 수 있다. 이 값은 옵셔널하다.
컨텐츠 어트리뷰트(ContentAttributes)는 ETSI TS 103 205의 Annex D.1.3.2를 참조할 수 있다. 이 값은 옵셔널하다.
어베일러빌리티(Availability)는 이 서비스 위치가 액티브할 것으로 기대되는 경우 그 기간을 나타낸다. 이 값은 옵셔널하다.
구독패키지(SubscriptionPackage)는 이 서비스가 포함되는 구독 패키지이다. 이 값은 옵셔널하다.
FIA컨텐츠매니지먼트(FTAContentManagement): DRM을 사용하지 않는 DVB-I서비스 인스턴스들이 FTAContentManagement 엘리먼트를 서비스 인스턴스(ServiceInstance)를 위한 컨텐츠 운영 정책을 정의하기 위해 전달한다. 각 어트리뷰트의 시맨틱은 문서 ETSI EN 300 468의 디스크립터인 FTA_content_management_descriptor의 대응하는 필드에서 설명될 수 있다. 이 값은 옵셔널하다.
소스 타입(SourceType)은 이 서비스 인스턴스를 위한 프라이머리 딜리버리 소스를 식별한다. 이 값은 필요한 딜리버리 파라미터를 결정한다. 이 값은 옵셔널하다.
DVBT딜리버리 파라미터(DVBTDeliveryParameters)는 DVB-T서비스를 위한 딜리버리 파라미터들이다.
DVBS 딜리버리 파라미터(DVBSDeliveryParameters)는 DVB-S서비스를 위한 딜리버리 파라미터들이다.
DVBC딜리버리 파라미터(DVBCDeliveryParameters)는 DVB-C서비스를 위한 딜리버리 파라미터들이다.
RTSP딜리버리 파라미터(RTSPDeliveryParameters)는 RTSP기반 서비스들을 위한 딜리버리 파라미터들이다.
멀티캐스트TS딜리버리파라미터(MulticastTSDeliveryParameters)는 멀티캐스트UDP를 사용하여 딜리버리된 서비스들을 위한 딜리버리 파라미터들이다.
DASH딜리버리파라미터()는 DVB DASH딜리버리를 사용하는 서비스들을 위한 딜리버리 파라미터들이다.
SATIP딜리버리파라미터(SATIPDeliveryParameters)는 SATIP를 지원하는 DVB-I클라이언트가 SATIP서버로부터 서비스 인스턴스를 수신하기 위해 사용할 수 있는 파라미터들이다.
상술한 파라미터들은 소스타입(SourceType)에 따라서 기술될 수 있다.
우선순위(@priority)는 서비스의 다른 서비스 인스턴스들에 대한 이 서비스 인스턴스의 우선순위이다. 이 값은 옵셔널하다.
도15는 실시예들에 따른 사이멀캐스트(simulcast)을 위한 DASH딜리버리 파라미터들을 나타낸다.
UriBasedLocation: Refer to Annex D.1.3.2 of ETSI TS 103 205 [2] for semantic definition.
MinimumBitRate: Threshold bit-rate under which an alternative source for the same service should be preferred, if available.
이는 실시예들에 따른사이멀캐스트(simulcast)을 위한 DASH딜리버리 파라미터들을 테이블 형태로 나타낸다.
상술한 DASH딜리버리 파라미터들의 상세 신택스이다.
실시예들에 따른 DASH딜리버리 파라미터들은 사이멀캐스트를 위해서 추가로 익스텐션될 수 있다.
URI 기반 위치(UriBasedLocation)는 문서 ETSI TS 103 205의 Annex D.1.3.2을 참조할 수 있다. 이 값은 필수사항이다. DASH 서비스가 사이멀캐스트되는 경우, 이 값은URI에 기반하여 위치 정보를 제공할 수 있다.
최소 비트레이트(MinimumBitRate)는 같은 서비스를 위한 대체 서비스가 우선되어야 하는 임계치 비트-레이트이다. 이 값은 옵셔널하다.
DVB-I 서비스 타입의 자식 엘리먼트로, 딜리버리 네트워크에 따라 서비스 인터페이스가 있을 수 있고, 클라이언트는 각 우선순위(@priority) 및 디바이스 케퍼빌리티를 고려하여 서비스 인스턴스를 수신 장치가 결정할 수 있다.
여기서, @minimumBitrate는 서비스 인스턴스 내에 스트림을 수신할 수 있는 네트워크 스택(network stack) 관점의 쓰루풋(throughput)을 의미한다.
예를 들어, 실시예들에 따른 미니멈 비트레이트(@minimumBitrate)는 서비스 인스턴스 내에 스트림을 수신할 수 있는 네트워크 스택(network stack) 관점의 쓰루풋(throughput)을 나타낼 수 있다. 즉, 실시예들에 따른 장치가 미니멈 비트레이트 정보를 통해, 네트워크가 현재 DASH 서비스를 수신할 수 있는 최소한의 비트레이트를 확인할 수 있다.
해당 정보를 통해, service instance 가 플레이 가능(playable)한지를 판단할 수 있다. 그러나, 현재 정의된 정보는 DVBiservicetype 내 다수개의 service instance 가 포함 되었을 때, client 는 @minimumBitrate 의 정보만을 가지고는 서비스 인스턴스 선택(service instance selection)이 어렵다.
예를 들어, 플레이 가능여부(Playable)을 결정하는 minimumbitrate 는 최소 조건이기 때문에 최소조건을 만족하는 것만으로 비트스트림 간 폴백(fallback) 조건에는 만족하지 않는다.
예를 들어, 다음과 같이 서비스 인스턴스가 2가지 있는 경우를 가정하여 설명한다.
(Service instance 1) DVB-T delivery method, HD, H.264/AVC
(Service instance 2) DVB-I DASH delivery method, MinimumBitRate 1.5Mbps
예를 들어, 2가지 service instance (예를 들어, 서비스 인스턴스 1 및 서비스 인스턴스 2)가 존재하고, 실시예들에 따른 송/수신 장치에 관련된 클라이언트(client)가 HEVC UHD capable 단말이며, 다른 하나의 비교대상의 비트레이트 이상의 네트워크 상황을 보장 받을 수 있다면, service instance 2 (예를 들어, HEVC UHD)를 수신기(단말)이 요청해야 하지만, 현재 정보로는 MPD 를 요청하여 수신하지 않는 한, instance 1보다 나은 품질의 스트림이 포함되어 있다는 속성을 수신기가 알 수 없다. 모든 service instance 의 MPD 를 모두 수신하여 비교하는 것은 수신기 입장에서 부담이 될 뿐 만 아니라 합리적인 네트워크 선택에서도 이슈가 있을 수 있다. DVB 서비스 스킴(service scheme) 정보 내에서 인스턴스 간 보다 나은 서비스를 제공하기 위한 방안을 이하에서 제안한다. 즉, 수신기가 MPD 또는 유사 시그널링 정보를 모두 파싱/분석하는 부담을 없애고 특정 비트레이트 이상의 네트워크 상황에 대응하여 수신가가 더 나은 서비스 인스턴스를 빠르게 파악하고 요청할 수 있는 실시예들을 구현할 수 있다.
도16은 실시예들에 따른 DASHDeliveryParametersType에 기반한 서비스 인스턴스를 선택하는 안을 나타낸다.
DASH 딜리버리 파라미터 타입은 비교 비트레이트(ComparisonBitRate) 및 비교 컨텐츠 어트리뷰트 타입(ComparisonContentAttributeType)을 포함할 수 있다. 비교 컨텐츠 어트리뷰트 타입(ComparisonContentAttributeType)는 오디오 어트리뷰트 엘리먼트, 비디오 어트리뷰트 엘리먼트, 캡션 랭귀지 엘리먼트, 사인 랭귀지 엘리먼트를 포함할 수 있다.
또한, 비교 컨텐츠 어트리뷰트 타입은 서비스 인스턴스 타입(45020)에 포함된 컨텐트 어트리뷰트 엘리먼트에 대응될 수 있다.
DASH 딜리버리 파라미터 타입은 비교 컨텐츠 어트리뷰트 타입(ComparisonContentAttributeType)을 포함할 수 있다. 또한, 비교 컨텐츠 어트리뷰트 타입(ComparisonContentAttributeType)은 오디오 어트리뷰트 엘리먼트, 비디오 어트리뷰트 엘리먼트, 캡션 랭귀지 엘리먼트, 사인 랭귀지 엘리먼트와 함께, 비교 비트레이트(ComparisonBitRate)를 포함할 수 있다.
1안 및 2안에서 공통적인 엘리먼트인 비교 비트레이트(ComparisonBitRate) 및 비교 컨텐츠 어트리뷰트 타입(ComparisonContentAttributeType)의 정의는 다음과 같을 수 있다.
비교 비트 레이트(@ComparisonBitrate)는 이 서비스를 위해 이용 가능한 비IP전달 서비스 인스턴스보다 나은 유저 경험(user experience)을 제공하는 특정한 IP 전달 서비스 인스턴스를 핸들링할 수 있는 비트레이트를 의미한다.
비교 컨텐츠 어트리뷰트 타입(@ComparisonContentAttributeType)은 어느 비디오 특성이 이 서비스를 위해 이용가능한 비IP 전달 서비스 인스턴스보다 더 나은 유저 경험을 제공하는 DVB-I클라이언트를 위해 이용 가능한지를 나타낸다.
도17은 실시예들에 따른 DVB-I 서비스 인스턴스의 예시를 나타낸다.
두 가지 서비스 인스턴스를 나타내는데, 1은 DVB-S ServiceInstance 이고, 2는 DVB-I ServiceInstance이다.
1의 서비스 인스턴스는 우선순위 0을 가지고, 디스플레이 네임은 ABC드라마이다. 오디오 어트리뷰트, 비디오 어트리뷰트 등이 도56과 같은 속성으로 시그널링되고, DVBS딜리버리 파라미터들을 포함한다. 여기서, 우선순위 '0'은 하나의 예시 값일 수 있다. 또한, 실시예들에 따른 수신 장치가 해당 서비스 인스턴스 외에 추가적인 서비스 인스턴스를 확인하는 것은, 우선순위 값뿐만 아니라, 네트워크 상태 또는 가용한 밴드위스, client 의 capability 들을 고려하여 나은 서비스를 제공할 수 있는 서비스 인스턴스를 실시예들에 따른 시그널링 정보를 통해 사용자에게 제공할 수 있다.
2의 서비스 인스턴스는 우선순위1을 가지고, 디스플레이 네임은 ABC드라마이다. DASH딜리버리 파라미터들은 URI기반 위치를 통해 application/dash+xml 타입의 컨텐츠를 https://live.daserste.de/0001 Das%20Erste.mpd</dvbisd-base:URI 의 주소를 시그널링할 수 있다. 최소 비트레이트는 1M이고, 비교 비트 레이트는 7M이다. 비교 컨텐츠 어트리뷰트는 비디오 어트리뷰트를 "urn:mpeg:mpeg7:cs:VideoCodingFormatCS:2001:2.2.2" 및 HEVC Video Main10 Profile @ Main Level</tva:Name> (UHD 가능)을 통해 시그널링한다. 구체적으로, 비교 비트 레이트의 값은 하나의 예시 값일 수 있다. 또한, 실시예들에 따른 수신 장치(단말, 클라이언트 등)는 비교 비트 레이트 값을 확인하고, 이 값을 통해 더 나은 서비스가 제공됨을 알 수 있다. 예를 들어, 7M의 값에 대응하는 더 나은 서비스가 제공되는 경우, 실시예들에 따른 방법/장치는 해당 비디오 속성 정보를 비교 컨텐츠 어트리뷰트와 같이 추가적으로 정의할 수 있다. 따라서, 실시예들에 따른 수신 장치는 UHD 스트림의 존재를 확인하고, 네트워크 상황에 따라서, 비교 컨텐츠 어트리뷰트에 대한 서비스로 스트림 전환을 할 수 있다.
DVB-I 서비스 스킴(service scheme) 내 같은 서비스(예, ABC 드라마) 내 2개의 인스턴스를 수신기가 수신하는 경우, DVB-I 클라이언트는 더 나은 사용자 경험(better user experience)을 위해 제공 가능한 인스턴스(instance) 를 선택해야 한다. 비교 비트레이트(@ComparisonBitrate) 값인 7Mbps를 확인하고, HD에 비교하여 현재 네트워크의 가용한 밴드위드(bandwidth)를 초과하고, 비교 컨텐츠 어트리뷰트(@ComparisonContentAttribute)의 속성이 단말(수신 장치)에서 지원 가능하다면, MPD 를 요청하고 더 나은 서비스를 수신하여 사용자에게 제공할 수 있다. 해당 속성은 @ComparisonBitrate (7Mbps -HD) 기준 HD초과(beyond HD)를 의미하며, 브로드캐스트 서비스 인스턴스(broadcast service instance)보다 풍부한(enriched)한 서비스를 제공할 수 있는 것을 의미한다.
여기서, 1M BPS 및 7M BPS의 비트레이트는 예시 값일 수 있다. 이 값은 UD 및 UHD와 같이, 해상도가 상대적으로 차이가 나는 서비스 간 적용되는 비트레이트일 수 있다.
실시예들에 따라, 유즈 케이스(use case)를 확장하면 다음과 같다.
Instance 1. HD broadcast
Instance 2. UHD DASH with representations from SD to UHD, 1.5 Mbps to 33 Mbps (with an HD Representation at 7 Mbps). MinimumBitRate 1.5 Mbps; ComparisonBitRate 7 Mbps.
즉, 인스턴스 1는 HD브로드캐스트를 의미하고, 인스턴스2는 UHD DASH를 의미한다. 인스턴스2는 SD로부터 UHD로 리프리젠테이션되고, 1.5Mbp에서 33Mbps 밴드위드를 가질 수 있는데 이때 HD리프리젠테이션은 7Mbps이고, 최소 비트레이트는 1.5Mbps에 비교 비트레이트는 7Mbps이다.
실시예들에 따른 UHD지원가능한 플레이어는 비트레이트가 7Mbps인 경우에서 인스턴스2를 선택할 수 있다.
실시예들에 따른 HEVC 서포트가 없고 HD지원가능한 플레이어는 인스턴스1을 선택한다.
실시예들에 따른 5.5Mpbs 스피드의 wifi링크를 갖는 UHD지원가능한 플레이어는 인스턴스1을 선택한다.
실시예들에 따른 브로드캐스트 리포트를 수신하지 못하는 1Mbps 가능한 3G모바일 커넥션을 가진 UHD지원가능한 플레이어는 서비스를 플레이할 수 있는 충분히 빠른 커넥션을 가지지 못 하지만 서비스 플레이를 시도할 수 있다.
실시예들에 따른 브로드캐스트를 수신하지 못하는 2Mbps가능한 4G모바일 커넥션을 갖는 UHD지원가능한 플레이어는 인스턴스2를 선택할 수 있다.
도18은 실시예들에 따른 실시예들에 따른 사이멀캐스트 UI/UX를 나타낸다.
57000은 실시예들에 따른 수신 장치가 DVB-T 브로드캐스트 서비스를 디스플레이하는 모습을 나타내고, 57010은 실시예들에 따른 수신 장치가 DVB-I서비스를 디스플레이하는 모습을 나타낸다. 도14는 같은 서비스를 사용자의 선택 및/또는 수신 장치의 특성에 따라서 사용자에게 더 나은 사용자 경험을 실시예들에 따른 시그널링 방안 및 UI/UX방식에 기반하여 제공하는 모습을 나타낸다.
57020는 이를 위한 상술한 시그널링 정보의 예시이다. 이는 상술한 서비스 리스트에 대응된다.
실시예들에 따른 서비스 리스트는 서비스 별로 서비스 인스턴스를 제공할 수 있다. 57000 및 57010의 서비스는 로지컬 채널 넘버6을 가지고, 서비스 인스턴스1 및 서비스 인스턴스2를 포함한다. 서비스 인스턴스1은 57000과 같이 DVB-T(HD) 서비스를 시그널링하고, 서비스 인스턴스2는 57010과 같이 DVB-I (UHD)서비스를 시그널링한다.
실시예들에 따르면, DVB-I 서비스를 수신가능한 디바이스에서 서비스 인스턴스 하나 또는 다수개를 수신할 때 포함된 비교 비트레이트 값 및 비교 컨텐츠 어트리뷰트 값에 기반하여 나은 품질의 미디어 서비스를 제공할 수 있도록 판단할 수 있다. 실시예와 같이 서비스 인스턴스를 2개 수신 했을 때 IP/DASH 를 통해서 보다 나은 서비스를 수신할 가능성이 있는 서비스 인스턴스를 빠르게 구별할 수 있다. 실시예와 같이 HD 와 UHD 가 동시에 수신될 때 상기 정보로 딜리버리 타입(delivery type) 를 선택할 수 있다.
다시 말해, 서비스 인스턴스 1 및 서비스 인스턴스2를 수신한 수신 장치는 DVB-I 에 대한 서비스 인스턴스에 포함된 비교 비트레이트 값 및 비교 컨텐츠 어트리뷰트 값에 기반하여 수신 장치가 더 나은 DVB-I UHD 서비스를 제공할 수 있는지 모든 서비스에 대한 다른 시그널링 정보를 모두 파싱할 필요 없이 곧바로 확인할 수 있다. 수신 장치는 인스턴스2에 기반하여, 비교 비트레이트가 7Mbps이고 더 나은 서비스의 해상도가 UHD(HEVC)임을 비교 컨텐츠 어트리뷰트를 통해 알 수 있다. 수신 장치는 사용자에게 UI/UX에 기반하여 더 나은 서비스를 시청할 것인지 물어볼 수 있다. 사용자의 선택에 따라서, 혹은 수신 장치의 설정에 따라서 인스턴스2에 따른 서비스를 사용자에게 제공할 수 있다.
실시예들에 따른 수신 장치는 DVB-I simulcast service UI/UX를 사용자에게 제공할 수 있다. 도57상술한 실시예들에 따른 확장한 정보를 통해 DVB-I client 가 복수의 서비스 인스턴스들(multiple service instance)을 수신 했을 때 사용자(user)에게 더 나은 경험(better experience)를 제공하는 UI/UX 를 의미한다. UHD/HEVC 지원 가능한 단말이면, HD 로 수신 가능한 DVB-T service instance 보다 UHD 수신 가능한 DVB-I service instance 를 선택 가능하다. 단말은 DASH MPD 를 모두 수신 할 필요 없이, service list scheme 만을 통해 High Quality 의 service instance 를 선택 가능하다.
상술한 실시예들에 따른 시그널링 정보는 필드, 어트리뷰트, 엘리먼트, 제1정보, 제2정보, 제1값, 제2값 등 다양하게 지칭될 수 있다.
상술한 실시예들 및 이하 설명하는 실시예들은 다음과 같은 효과를 제공할 수 있다.
실시예들은 기존 리니어 서비스(linear service) 채널과 동일한 사용자(user) UX 를 제공할 수 있는 인터넷 채널 스캐닝(Internet channel scanning)을 위한 MPEG-2 시스템/DVB SI 기반 서비스(service) 초기화할 수 있다.
실시예들은 기존 linear channel 과 통합하기 위해, 인터넷 스트림 식별(Internet stream identifying )을 위한 네트워크/스트림/서비스 유니크 시그널링(Network/stream/service unique signaling) 이 가능하다.
실시예들은 기존 시스템 정보(System information) 내에서 TSID 를 대체 할 수 있는 방법을 확장할 수 있다.
실시예들은 동일한 전용 채널(dedicated channel) 내로 제공하는 DVB 망과 DVB-I 채널에서 제공하는 각 비트 스트림(bit-stream) 스위칭을 가능하게 한다.
실시예들은 기존 채널에서 제공하는 SD, HD, UHD 링키지 서비스(linkage service)에서 DVB-I 채널을 통해 SUHD(8k) linkage 를 제공할 수 있다.
실시예들은 기존 DVB 망에서 DVB-I 서비스 리스트(service list)를 획득할 수 있다.
실시예들은 리니어 IP기반 TV(Linear IP based TV) 서비스를 제공하기 위해, 기존 리니어(linear) 채널망의 서비스 부트스트랩(service bootstrap) 기술을 추가할 수 있다.
실시예들은 Linear IP based TV 서비스 식별(Service identification)을 위해 정의되어야 하는 unique 한 정보들을 추가한다.
실시예들은 기존 linear 채널 EPG 에 IP based TV channel 을 추가할 수 있다.
실시예들은 동일한 dedicated channel 내에서 기존 DVB 스트림와 DVB-I 스트림을 동시에 제공할 수 있고, 일정 기간(period) 기간 동안 다이나믹(dynamic) 하게 스트림을 변경할 수 있다.
실시예들은 기존 채널에서 제공하는 SD, HD, UHD linkage service 에서 DVB-I 채널을 통해 SUHD(8k) linkage 를 제공할 수 있다.
실시예들은 기존 DVB 망에서 DVB-I 서비스 리스트 또는 쿼리 엔드 포인트(service list or query end point)를 획득하기 위한 linkage 정보를 확장할 수 있다.
실시예들은 Linear IP based TV 서비스를 제공하기 위해, 기존 linear 채널망의 서비스 부트스트랩(service bootstrap) 방식을 확장할 수 있다.
실시예들은 DVB-SI 정보 기반 부케(bouquet) 레벨, 서비스 레벨, 이벤트 레벨에서 기존 DVB 망과 DVB-I 망의 linkage 를 제공할 수 있다.
실시예들은 기존 DVB 망과 DVB-I 망의 linkage 정보를 통해 동일한 로지컬 채널(logical channel) 에서 다양한 레졸루션(resolution) 의 콘텐츠를 제공할 수 있다.
실시예들은 기존 DVB 망에서 DVB-I service list 를 획득하기 위해 링키지 디스크립터(uri_linkage_descriptor)를 통해, DVB-I 서비스 리스트 위치(service list location)와 쿼리(query)를 정의할 수 있다.
실시예들은 엔드 포인트(End point)를 통해, 오픈 DVB-I 서비스 레지스트리(open DVB-I service registry)에 접근하고 클라이언트(client)에 맞는 서비스 리스트 엔트리 리스트(service list entry list) 를 획득할 수 있다.
실시예들은 RF 기반 DVB 튜너(tuner)를 지원하는 장치에서 기존 리니어 서비스(linear service) 와 OTT 서비스가 통합된 UI를 통해 엑세스(access) 되는 서비스를 가능하게 한다.
실시예들은 셋톱박스(STB) 없이, 오픈 인터넷(open internet)을 통해 기존 linear 채널 들과 동일한 UX 를 제공하는 미디어(media) 서비스를 제공할 수 있다.
실시예들은 기존 DVB 망과 인터넷 채널이 통합됨에 따라 같은 채널 내에 제공 가능한 레졸루션(resolution)을 확장할 수 있다.
실시예들에 따른 링키지 디스크립터(uri_linkage_descriptor)로 인하여, DVB-I service list location 을 시그널링할 수 있다. 실시예들에 따른 수신 장치는 효율적으로 DVB-I service list 를 획득할 수 있다. 또한, 실시예들에 따른 End point로 인하여, 실시예들에 따른 수신 장치는 효율적으로 서비스 리스트를 획득할 수 있다.
상술한 실시예들로 인하여, 실시예들에 따른 단말(장치)은 모든 채널이 통합된 서비스 리스트를 획득할 수 있다. 통합된 서비스 리스트는 전체 리스트, 수신 장치가 원하는 리스트 등을 포함할 수 있다.
전체 서비스를 획득할 수 있는 URI가 있고, 이 URI를 통해 개별 서비스의 리스트에 대한 URI를 추가로 획득할 수 있다. 개별 리스트는 방송사마다 서비스에 대한 리스트일 수 있다.
서비스 플랫폼의 확대에 따라 사업자들은 보다 다양한 환경을 통해 서비스를 제공 할 수 있고, User 측면에서는 다양한 앱 환경에서 수신하는 미디어 서비스를 DVB-I 라는 통합된 수신환경에서 서비스 받을 수 있으므로 보다 편리하고 접근성이 좋은 서비스를 수신할 수 있다.
서비스 플랫폼의 확대와 통합으로 지상파, 케이블파, 위성, 5G 를 포함한 통신망 등을 통해 사이멀캐스트될 수 있고, 수신기 케페빌리티에 따라서 수신기는 원하는 서비스를 수신할 수 있다.
이러한 과정은 ComparisonBitrate 및/또는 ComparisonContentAttribute 등을 통해 구현될 수 있다.
MPD는 복수의 레프리젠테이션을 포함할 수 있고, UD 및 UHD 관련 정보를 모두 포함할 수 있다.
수신 장치는 MPD의 모든 정보를 파싱해야 하는 부담 및 소요 시간이 크다.
반면에, 서비스 인스턴스 레벨의 DVB-I서비스 리스트를 이용하면, 수신 장치는 수신 장치의 케퍼빌리티에 따라서, 최적화된 서비스, 리치 미디어를 선택적으로 빠르게 디코딩할 수 있는 효과가 있다.
수신 장치는 ComparisonBitrate을 통해서, 케퍼빌리티가 상이한 서비스가 존재함을 알 수 있다. ComparisonBitrate 는 최소 처리량(minimum throughput)의 개념일 수 있다. 나아가, ComparisonContentAttribute을 통해서 스위칭되는 서비스의 구체적 속성이 무엇인지 수신 장치가 알 수 있는 효과가 있다.
도19는 실시예들에 따른 DVB-I 서비스 리스트 하이어라키를 나타낸다.
도19는 실시예들에 따른 DVB-I 서비스 리스트이다.
실시예들에 따른 송신 장치는서비스 리스트를 생성하여 수신 장치에 전송하고, 수신 장치는 서비스 리스트에 기반하여, 사용자에게 DVB-I 미디어 서비스를 제공한다.
송신 장치는 실시예들에 따른 서비스 정보를 생성하고, 수신 장치는 실시예들에 따른 서비스 정보를 이용하여 서비스에 관한 정보(예를 들어, 서비스 리스트 정보, 컨텐트 가이드 정보 등)를 획득한다.
실시예들에 따른 DVB-I 서비스 리스트 하이어라키(DVB-I Service list hierarchy)는 서비스 아이디(service_ID)의 유니크(unique) 정보를 통해, 각 서비스는 서비스 인스턴스(service instance) 들을 포함할 수 있다. 즉, Service_ID 하나의 Parents element 가 delivery network 에 따라 구분 된 Service instance 를 다수 개를 정의할 수 있다. 송신 장치는 Simulcast 의 경우 인터넷과 기존 DVB망이 동시에 연결된 경우DVB-T 와 DASH 의 instance 들을 정의하여 전송할 수 있다. 각 service instance 들을 포함하는 service 를 위해, 송신 장치는 user 에게 제공할 DVB-I service content guide 를 생성한다. 특정 schedule(timeslot) 에 대응되는 Program(Event) 의 구체적인 정보를 정의하여 현재 진행중인 program guide 를 수신 장치는 수신할 수 있다. DVB-I 서비스 수신은 기본적으로 HTTP 1.1 기반의 Pull-only mode 로서, 각 client 는 client 자체적인 polling algorithm에 따라 현재 소비중인 content guide 정보를 다운로드 후, 적절한 UX/UI 를 통해 보여줄 수 있다.
도20은 실시예들에 따른 ContentGuideSourceList를 나타낸다.
실시예들에 따른 수신 장치는 DVB-I 서비스 컨텐트 가이드를 다음과 같은 방법에 의해 다운로드할 수 있다.
실시예들에 따른 수신 장치가 컨텐트 가이드 서버(송신 장치)에 content guide 를 요청 시, 다음과 같은 API 엔드포인트(endpoint)를 가지고 데이터를 요청하고 수신한다. “”는 도20과 같은 API_endpoint_URL 가 주어지고 해당 주소로 필요한 정보를 업데이트 한다. 기본 구조는 하기와 같으며, 타임 기간(time span)에 따라 타임스탬프 필터링된 스케쥴 요청(timestamp filtered schedule request)과 현재/다음 필터링된 스케쥴 요청(now/next filtered schedule request)의 방법이 있다.
[1] 타임스탬프 필터링된 스케쥴 요청 timestamp filtered schedule request
스케쥴 엔드포인트(ScheduleEndpoint)의 특정 타임 기간(time span)을 정의하여 하기와 같이 쿼리 정보(query information)을 정의한다.
<ScheduleInfoEndpoint>?start=<start_unixtime>&end=<end_unixtime>
&sid=<service_id>&image_variant=<variant>
예를 들어,
<ScheduleInfoEndpoint>?start=1433246400&end=1433268000&sid=12345
여기서 service_id는 수신 장치(클라이언트 디바이스)에 의해 결정된 서비스 아이디(a single decimal Service ID)를 나타낸다.
서비스 아이디 파라미터의 싱글 존재만이 패스될 수 있다.
variant는 옵셔널하게 이미지 베리언트(variant)를 나타낼 수 있다.
[2] 다음 필터링된 스케쥴 요청 now/next filtered schedule request
현재/다음 필터링된 스케쥴 엔트포인트는 query information 을 나타낸다.
예를 들어, <ScheduleInfoEndpoint>?sid=12345&now_next=true
도21은 실시예들에 따른 DVB-I클라이언트 오버-러닝 이슈를 나타낸다.
실시예들에 따른 수신 장치가 DVB-I관련 데이터를 재생하는 동안 발생할 수 있는 오버-러닝에 따른 업데이트 상태 이슈(up-to-date state issues)를 나타낸다.
오버-러닝 이슈는 실시예들에 따른 방송 신호 수신 장치(클라이언트) 및 방송 신호 송신 장치(서버부, 브로드캐스터 등) 간 다음과 같은 이유로 인하여 발생할 수 있다.
실시예들에 따른 방송 신호 수신 장치(DVB-I client)는 현재 자체적인 클라이언트(client) 의 기준에 따라 폴링(polling)하여 컨텐트 가이드 데이터(content guide data)를 최신정보로 업데이트하여 유저(User)에게 보여준다. DVB 망의 라이브 방송은 브로드캐스트(broadcast) 망을 통해 푸쉬(Push) 형태로 컨텐트 가이드 데이터를 제공하나, DVB-I 는 풀 온리 모드(pull-only mode )로 일정주기의 리프레쉬(refresh)를 통해 최신정보를 업데이트한다.
실시예들에 따른 방송 신호 수신 장치(DVB-I client)는 DVB-I 클라이언트 컨텐트 가이드 타임라인(59000)에 따라서, 실시예들에 따른 서비스 디스커버리 정보에 따른 DVB-I서비스 어베일러빌리티에 의해 프로그램(이벤트)를 재생할 수 있다. 실시예들에 따른 프로그램(또는 이벤트, 59010)은 스타트 타임(59020)과 엔드 타임(59020)을 가진다.
실시예들에 따른 이벤트는 DASH정의에 따른 클라이언트 또는 수신 장치에 대한 비주기 미디어-타임 관련 부가 정보(aperiodic sparse media-time related auxiliary information)를 의미할 수 있다.
실시예들에 따른 방송 신호 수신 장치(DVB-I client)는 DVB-I 클라이언트 폴링 인터벌(59030)에 기반하여, 만기 타임 윈도우(expiry time window, 59050)마다 컨텐트 가이드 데이터를 송신 장치에 리퀘스트(59040)할 수 있다.
DVB-I 기반에서 content guide 의 문제점은 특정 프로그램(또는 이벤트, 59010), 예를 들어 스포츠 중계가 지연되거나 특정 라이브 속보의 삽입으로 인해 기존 프로그램의 가이드의 정보와는 다른 DVB-I 서비스(service)를 보여줄 수 있다. 폴링 인터벌(polling interval)에 따른 DVB-I content guide 정보와 실제 소비되고 있는 live 프로그램의 진행 상태를 나타낸 도면이다.
라이브 프로그램(live program)이 오버-러닝 주기(over-running period, 59070) 동안 클라이언트(client) 가 Tune-in 되거나 채널 전환할 수 있다. DVB-I content guide 는 예정된 엔드타임에 따라Event 2 관한 데이터를 나타내는 이슈가 발생한다(실제 수신 장치는 이벤트 1을 재생하는 중이다) .
즉, Client 는 periodically 한 Request(59040)를 통해 content guide 를 갱신하나, 엔드타임 구간에서 오버 러빙이 발생하는 경우, 현재 play-out 중인 화면과 channel banner 의 UI 정보가 일치하지 않는 현상이 발생한다.
또한, 기 정의된 HTTP 내 만료 타임(expiry time) 관련 캐쉬 컨트롤(Cache-Control), 맥스 에이지 헤더(max-age header)도 over-running 에 대한 타임 구간(time span)을 고려하지는 않는다.
따라서 실시예들은 풀 온리 모드(Pull-only mode) 기반 DVB-I 수신기에서 최신정보를 업데이트할 수 있는 방법들을 제안한다.
도22는 실시예들에 따른 다이나믹 폴링 알고리즘을 나타낸다.
도22은 실시예들에 따른 송수신 장치가 도21의 문제를 해결하기 위한 방법을 나타낸다.
실시예들에 따른 방송 신호 수신 장치(DVB-I client)는 업-투-데이트 스테이트(up-to-date state)를 동작(600000)에 기반하여 유지할 수 있다.
오버-러닝 주기(over-running period) 내 잘못된 정보(이벤트/프로그램에 관련된 가이드 정보 등)를 보여주지 않도록 하는 방법을 제안하고자 한다. 실시예들에 따른 방송 신호 수신 장치는 DVB-I 서비스를 수신하고, 서비스 인스턴스(Service instance) 내 <Availability> 를 통해 현재 진행되고 있는 서비스 어베일러빌리티(service availability) 를 확인할 수 있다. 따라서 서비스 어베일러빌리티에 정의된 서비스 윈도우(service window)에 따라 서비스 진행상황을 확인 할 수 있다.
특정 live 서비스가 over-running 된 경우, 기존의 client 자체적으로 진행하고 있는 polling 의 방법에서 <pollingInterval> 값을 통해서 특정구간의 polling 주기를 adaptive 하게 바꿀 수 있다.
600010과 같이, 수신 장치가 자체적으로 폴링을 하더라도, 이벤트 종료 시점에 발생하는 오버-러닝을 적절하게 대응할 수 없다.
따라서, 600020과 같이, 수신 장치가 서비스 윈도우에 따라 정해진 방식의 폴링을 수행하다가, 이벤트/프로그램의 종료시점 부근부터 다이나믹하게 폴링을 특정 다이나믹 폴링 구간(600030) 동안 폴링 주기(600040)마다 수행할 수 있다.
수신 장치는 실시예들에 따른 컨텐트 가이드 타임라인에 맞춰서, 이벤트1이 오버-러닝되어 오버-러닝 구간(600060)이 발생한 경우, 다이나믹 폴링 전체 기간(600030) 및 폴링 주기(600040)에 기반하여 오버-러빙이 반영된 이벤트1에 대한 컨텐트 가이드를 이벤트1과 함께 사용자에게 제공할 수 있다.
다이나믹 폴링 전체 기간(600030) 및 폴링 주기(600040)은 이벤트 1 의 만료시점 이전부터 이벤트2의 시작시점 이후까지 일정한 구간(600060)에 대해 설정될 수 있다.
이러한 다이나믹 폴링 인터벌(dynamic polling interval)은 over-running 시 발생하는 콘텐츠가이드 오정보를 막고 up-to-date 한 정보를 제공할 수 있다. 도60은 특정 구간의 polling 주기를 adaptive 하게 전환하여 dynamic polling interval 을 적용하여 over-running 이슈를 해결 하는 동작을 나타낸다. over-running 이슈를 해결 할 수 있는 알고리즘으로 하기와 같은 정보들이 필요하다.
dynamic polling interval 을 적용할 기준 timing 정보: 다이나믹 폴링이 적용되는 전체 구간을 나타낼 수 있다.
기준 timing 정보는, 예를 들어 DVB-I service Availability end time으로부터 x sec 만큼의 offset 이 나타내는 지점을 표현할 수 있다.
새롭게 적용 될 polling interval: 다이나믹 폴링을 전체 구간 내에서 얼마마다 폴링을 할지 인터벌을 나타낸다.
기존 정보와 비교를 위한 version 정보: 자체 클라이언트 폴링 인터벌과 비교하여, 다이마닉 폴링을 나타내는 버전 정보일 수 있다.
즉, 구체적으로 (1) dynamic polling interval 을 적용할 기준 timing 정보는 다이나믹 폴링을 적용하는 구간을 나타낸다. (2) 기준 timing 정보 (e.g. DVB-I service Availability end time) 으로부터 x sec 만큼의 offset은 (1)을 위한 값으로 오프셋 또는 불리언 타입일 수 있다. (3) 새롭게 적용 될 polling interval은 실시예들에 따른 @ minimumMetadataUpdatePeriod일 수 있다.
예를 들어, 전체 PERIOD가 10분이라하고, 10분 내 1분마다 폴링을 다이나믹하게 한다면 이때 (1) 정보는 10분, (2) 정보는 10분의 시작점이고(AST or AET + offset 혹은 @dynamic), (3) 인터벌은 1분일 수 있다. 또한, 기존 정보와 비교를 위한 version 정보를 통해 다이나믹 폴링을 위한 정보임을 알 수 있다.
도23은 실시예들에 따른 DVB-I service scheme을 나타낸다.
도23은 도22의 동작의 스킴을 나타낸다.
실시예들에 따른 폴링을 위한 신택스를 나타낸다. DVB-I 서비스 스킴을 나타낸다. 송신 장치는 서비스 리스트 정보를 생성하여 수신 장치에 전송하고, 수신 장치는 서비스 리스트 정보에 기반하여 컨텐트를 사용자에게 제공할 수 있다.
송신 장치는 서비스 정보를 생성하고, 수신 장치는 서비스 정보를 이용하여 서비스에 관한 정보(예를 들어, 서비스 리스트 정보, 컨텐트 가이드 정보 등)를 획득한다.
수신 장치는 미니멈 메타데이터 업데이트 피리오드(MinimumMetadataUpdatePeriod), 듀레이션(duration)에 기반하여, 컨텐트를 위한 메타데이터을 일정 주기 및 기간 동안 업데이트할 수 있다.
수신 장치는 미니멈 메타데이터 업데이트 피리오드(MinimumMetadataUpdatePeriod), 미니멈 메타데이터 피리오드 타입(MinimumMetadataUpdatePeriodType)에 기반하여, 컨텐트를 위한 메타데이터을 일정 주기 동안 업데이트할 수 있다.
수신 장치는 <attribute name="dynamic" type="boolean" default="false"/>, <attribute name="MinimumMetadataUpdatePeriod" type="duration" use="optional"/ > 와 같이, 폴링을 다이나믹하게 해야 한다는 것을 Boolean 타입에 기반하여 송신 장치로부터 알 수 있다. 예를 들어, Boolean이 False인 경우 다이나믹 폴링이 비활성화되고, Boolean이 True인 경우 다이나믹 폴링이 활성화될 수 있다. 수신 장치는 MinimumMetadataUpdatePeriod 및 duration에 기반하여 폴링을 다이나믹하게 송신 장치에 요청하고, 쿼리한 정보를 송신 장치로부터 수신할 수 있다.
수신 장치는 컨텐트 가이드 소스 타입에 따른 MinimumMetadataUpdatePeriod 및 MinimumMetadataUpdatePeriodType에 기반하여 메타데이터를 업데이트할 수 있다.
송신 장치는 수신 장치에 폴링 관련 정보를 버전 정보와 함께 독립적으로 전달할 수 있고, 컨텐트 가이드 소스 타입과 함께 폴링 관련 정보를 전달할 수 있고, LCN 테이블 엔트리 타입과 함께 폴링 관련 정보를 전달할 수 있다.
수신 장치는 MinimumMetadataUpdatePeriodType에 따라, 폴링 인터벌 및 듀레이션, 다이나믹 인터벌 피리오드 오프셋 및 정수값을 획득하여, 다이나믹 폴링을 위한 쿼리를 송신 측에 전송하여 쿼리에 대한 응답 정보를 수신할 수 있다.
송신 장치는 MinimumMetadataUpdatePeriod을 서비스 리스트 상에 다양한 위치에 생성하여 수신 장치에 전달할 수 있고, MinimumMetadataUpdatePeriod의 위치에 따른 수신 장치의 서비스 디스커버리 동작이 달라질 수 있다. 예를 들어, MinimumMetadataUpdatePeriod는 서비스리스트 내 포함되거나, 서비스에 포함되거나, 컨텐트 가이드에 포함되는 등 다양한 위치 및 계층을 가질 수 있다.
DVB-I Client 는 "PollingIntervalType" 을 통해, 전술한 이슈를 해결 할 수 있으며, 해당 타입은 service type 레벨과 ContentGuideSourceType 내 정의될 수 있다. 본 솔루션은 하기와 같은 procedure 로 최신정보를 확인하고 query 할 수 있다.
도24는 실시예들에 따른 DVB-I 서비스 하이어라키를 나타낸다.
실시예들에 따른 서비스 리스트는 계층 구조를 가질 수 있다. 실시예들에 따른 송신 장치는 실시예들에 따른 계층 구조를 가지는 서비스 리스트를 생성하여 수신 장치에 전송하고, 수신 장치는 실시예들에 따른 서비스 리스트에 기반하여 사용자에게 미디어 서비스를 제공한다.
송신 장치는 서비스 정보를 생성하고, 수신 장치는 서비스 정보를 이용하여 서비스에 관한 정보(예를 들어, 서비스 리스트 정보, 컨텐트 가이드 정보 등)를 획득한다.
수신 장치는 서비스 인스턴스(service instance) 레벨의 어베일러빌리티(availability) 값을 통해 현재 진행중인 서비스(또는 프로그램, 이벤트)의 어베일러빌리티 스타트 타임(available start time)과 엔드 타임(end time) 으로, 현재 서비스의 스테이트(state)를 확인한다.
어베일러블 엔드 타임(available end time)에서 다이나믹 인터벌 피리오드 오프셋(@DynamicIntervalPeriodoffset, 다이마닉 폴링의 시작 지점, 600030 및 600040, 600060 등 참조)만큼 뺀 지점부터 수신 장치(client)는 기존의 스테틱(static) 한 컨텐트 가이드 폴링(content guide polling)을 하지 않고(59040, 도60 참조), 폴링 인터벌(@PollingInterval) 값을 통해 다이나믹(Dynamic)한 요청(request)과 응답(response)을 통해 새로운 컨텐트 가이드 데이터(content guide data)를 갱신 할 수 있다.
다이나믹 폴링의 예시를 들면, 다음과 같다.
@availability End Time="2020-02-19T10:42:02.684Z"
(현재 수신 장치가 재생하는 데이터의 종료시간을 나타낸다)
@DynamicIntervalPeriodoffset ="5000"
(현재 데이터의 종료시간으로부터 5000시간단위(실시예들에 따라, 시, 분, 초 등 다양할 수 있음)만큼 이전부터, 수신 장치에게 다이나믹 폴링을 수행할 수 있음을 알린다)
@PollingInterval = “”
(수신 장치가 1000시간단위마다 송신 장치(서버, 프로세서 등)에 컨텐트 가이드 정보를 다이나믹하게 폴링하는 것을 의미한다)
@version = 10 -> 11
(수신 장치의 스테틱 폴링의 버전이 10이라면, 다이나믹 폴링의 버전이 11로 표현될 수 있다. 버전의 값은 실시예들에 따라 다양한 값을 가질 수 있다)
PollingIntervalType 값이 포함되면, (즉, 폴링 인터벌 타입이 다이나믹을 나타내면)
"2020-02-19T10:42:02.684Z" - “한 지점부터 “”의 간격으로 client 는 @ScheduleInfoEndpoint ( <ScheduleInfoEndpoint>?sid=12345&now_next=true )의 query 를 통해 access 하고 새로운 콘텐츠 가이드를 갱신 할 수 있다.
도25는 실시예들에 따른 DVB-I service scheme 및 content guide 최신 정보를 업데이트 하기 위한 방법을 나타낸다.
실시예들에 따른 DVB-I 서비스 리스트 디스커버리 스키마(Service List Discovery schema)를 나타낸다.
실시예들에 따른 수신 장치는 이와 같은 스키마를 이용하여, 컨텐트 가이드의 최신 정보를 업데이트할 수 있다.
DVB-I Service List Discovery schema는 서비스 리스트 엔트리 포인트(ServiceListEntryPoints)에 따라 서비스 리스트 제공자 정보 및 서비스 리스트를 획득할 수 있는 @ServiceListURI 를 포함한다.
수신 장치(DVB-I client)는 서비스 리스트를 획득하기 위해 DVB-I 서비스를 초기화하고, 서비스 리스트 주소 정보(@ServiceListURI)를 통해 HTTP request/response 수신 과정을 수행하고 수신한 서비스리스트를 저장한다. 해당 수행과정을 거쳐 DVB-I service 초기화와 service list 및 content guide 를 업데이트할 수 있다.
DVB-I service list scheme Hierarchy는 미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod)를 통해 서비스 리스트 메타데이터를 수신 동작을 지원한다. 실시예들에 따른 DVB-I 모델에 기반하면, 멀티플 DVB-I 서비스 리스트들(multiple DVB-I service list)과 개별 서비스 리스트는 멀티플 서비스들 또는 서비스를 포함할 수 있다. 각 싱글 서비스는 딜리버리 소스에 따라 서비스 인스턴스로 할당될 수 있다.
컨텐트 가이드는 각 서비스를 포함하는 서비스 리스트 전체의 컨텐트 가이드 정보이고, 컨텐트 가이드 소스 리스트(ContentGuideSourceList)를 통해 정의될 수 있고다. 각 싱글 서비스 별로 컨텐트 가이드 소스(ContentGuideSource)가 정의될 수 있다.
기존 HTTP 내 만료 시간(expiry time) 관련 캐쉬 컨트롤(Cache-Control): 맥스-에이지 헤더(max-age header)는 HTTP 레벨의 로우 레이어(low layer)의 만료 기간을 나타낸다. 실제 DVB-I client 상의 콘텐츠나 UI 상의 업데이트를 반영하지 않는다. 따라서 DVB-I 표준운 DVB-I client 코드 레벨에서 over-running 같은 이슈나 up-to-date 정보를 나타내기 위한 알고리즘인 @MinimumMetadataUpdatePeriod 가 필요하다.
서비스 리스트 스킴 하이어라키 상 미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod)의 위치에 따라 서비스 리스트의 업데이트와 대응되는 content guide 의 수신기 내의 동작이 달라 질 수 있다.
도26은 실시예들에 따른 DVB-I 클라이언트의 모델을 나타낸다.
실시예들에 따른 수신 장치(클라이언트)의 구조와 수신 장치와 연계되는 장치 간의 구조를 나타낸다.
수신 장치(690000)는 서비스 정보를 이용하여 서비스에 관한 정보(예를 들어, 서비스 리스트 정보, 컨텐트 가이드 정보 등)를 획득한다.
수신 장치(690000)는 본 명세서에서 설명하는 실시예들에 따른 수신 장치(클라이언트)이다. 수신 장치는 다음과 같은 구성요소를 포함하고, 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
DVB-I 서비스 선택 UI 제어부(690010)는 수신 장치(690000)의 서비스 선택 관련 UI를 제어한다. 서비스 선택 관련 UI정보를 위해 서비스 리스트 매니저(690020) 및 컨텐트 가이드 UI제어부(690040)와 필요한 데이터를 주고 받을 수 있다. 서비스 선택 UI 제어부(690010)는 소스 선택 UI제어부(690070)으로부터 서비스 선택 UI를 위한 소스 데이터를 수신할 수 있다.
서비스 리스트 매니저(690020)는 서비스 리스트 정보를 제어한다. 서비스 리스트 매니저(690020)는 하이브리드 서비스 선택UI제어부(690080)으로부터 서비스 리스트를 위한 서비스 선택 UI정보를 수신하고, 서비스 리스트 관련 데이터를 주고 받을 수 있다. 서비스 리스트 매니저(690020)는 서비스 플레이어(690030)와 서비스 리스트 데이터 및/또는 서비스 정보를 주고 받을 수 있다. 서비스 리스트 매니저(690020)는 컨텐트 가이드 매니저(690050)와 서비스 리스트 정보 및/또는 컨텐트 가이드 정보를 주고 받을 수 있다.
DVB-I 서비스 플레이어(690030)는 서비스 플레이를 제어한다. 서비스 플레이어(690030)는 DVB-DASH 플레이어(690090), 세컨더리 OTT플레이어(690100), 링크된 어플리케이션 엔진(690110) 등에 서비스를 제공할 수 있다. 링크된 어플리케이션 엔진(690110)은 링크된 어플리케이션 매니저(690060)의 제어를 통해 서비스를 제공하는 어플리케이션일 수 있다.
DVB-I 컨텐트 가이드 UI 제어부(690040)는 컨텐트 가이드 관련 UI를 제어한다. 서비스 선택 UI제어부(690010) 및 컨텐트 가이드 매니저(690050)와 서비스 선택 UI관련 데이터, 컨텐트 가이드UI 관련 데이터, 컨텐트 가이드 제어 관련 데이터 등을 주고 받을 수 있다.
컨텐트 가이드 매니저(690050)는 수신 장치의 컨텐트 가이드 처리를 제어한다. 서비스 리스트 매니저(690020) 및 하이브리드 컨텐트 가이드UI 제어부(690120)와 서비스 리스트 관련 정보, 컨텐트 가이드 제어 정보, 하이브리드 컨텐트 가이드 UI관련 정보를 주고 받을 수 있다. 하이브리드라 하면, DVB-I 망과 기존의 지상파, 위성파, 케이블파, IPTV 등의 방송 서비스 간의 통합을 지원하는 유닛을 의미한다.
링크된 어플리케이션 매니저(690060)는 수신 장치와 연계될 수 있는 추가 디바이스의 어플리케이션의 서비스 플레이를 제어한다.
DVB-C/S/T/IPTV 컨텐트 가이드 제어부(690130)는 DVB 케이블망, 위성망, 지상망, IP망의 서비스에 대한 수신 디바이스를 위한 컨텐트 가이드 정보를 하이브리드 컨텐트 가이드UI 제어부(690120)에 제공한다.
DVB-C/S/T/IPTV 서비스 리스트 매니저(690140)는 케이블망, 위성망, 지상망, IP망의 서비스에 대한 서비스 리스트 정보를 제어한다. 하이브리드 서비스 선택UI제어부(690080)와 DVB-I서비스와 하이브리드를 위한 케이블망, 위성망, 지상망, IP망 서비스 리스트 관련 정보를 주고 받을 수 있다.
DVB-C/S/T/IPTV 튜너(690150)는 지상파, 위성파, 케이블파, IPTV 등의 방송 서비스를 수신한다. 튜너(690150)는 서비스 리스트 매니저(690140)와 서비스 리스트를 위한 정보를 주고 받을 수 있다.
수신 장치(690000)는 DVB-I 서비스를 위한 서비스 리스트, 컨텐트 가이드 정보 등을 실시예들에 기반하여 사용자에게 제공할 수 있다. 수신 장치(690000)는 DVB-I 서비스 및 서비스 가이드 정보를 제공하면서, 옵셔널하게 케이블망, 위성망, 지상망, IP망의 서비스를 수신하는 튜너와 연계되어, 케이블망, 위성망, 지상망, IP망의 서비스 및 서비스 가이드 정보를 사용자에게 제공할 수 있다.
DVB-I client (690000)의 up-to-date state 를 유지하는 실시예들을 설명한다. 실시예들에 따른 option에 따라서, 수신 장치의 동작이 다양하게 달라질 수 있다.
Option 1, service list level의 시그널링의 의미 및 수신 동작은 다음과 같다.
서비스 리스트 내 미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod)는 서비스들을 포함하는 DVB-I 서비스 리스트 전체의 정보를 업데이트 할 수 있는 폴링 피리오드(polling period)이다.
수신 장치(690000)에 포함된 DVB-I 클라이언트 서비스 리스트 매니저(client service list manager, 690020)가 서비스 리스트 전체를 관리하고, 서비스 리스트의 업데이트를 관리할 수 있다.
수신 장치(690000)의 HTTP 캐쉬 컨트롤(Cache-Control) 관련하여, 맥스-에이지(max-age)값은 스테틱(static)이고, 만료기간을 계산한다.
미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod) 값이 정의(define)되면, 서비스 리스트를 업데이트할 수 있다. <DVB-I Service List discovery scheme>에서 정의한 서비스 리스트 주소(@ServiceListURI)에 쿼리를 보낼 수 있다.
서비스 리스트 주소(@ServiceListURI)에 대한 HTTP 캐쉬 컨트롤(Cache-Control)의 맥스-에이지(max-age) 값에 관계 없이, 미니멈 메타데이터 업데이트 피리오드 (@MinimumMetadataUpdatePeriod) 값을 통해 서비스 리스트(service list)의 쿼리(query) 주기를 다이나믹(dynamic)하게 변경이 가능하다.
변경된 서비스 리스트(service list) 정보는 컨텐트 가이드 매니저(content guide manager, 670050) 를 통해 전달되고, 컨텐트 가이드(content guide)의 업데이트 주기도 다이나믹하게 설정 가능하다.
Option 2, 3, 4 service level 의 시그널링의 의미 및 수신 동작은 다음과 같다.
서비스 내 미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod)는 DVB-I 싱글 서비스의 서비스 정보와 컨텐트 가이드 소스(ContentGuideSource)를 업데이트 할 수 있는 폴링 피리오드(polling period)이다.
수신 장치(690000)에 포함된 도69의 DVB-I 클라이언트 서비스 리스트 매니저(client service list manager, 690020)는 개별 서비스 정보를 관리하고, 개별 서비스의 업데이트를 관리할 수 있다. HTTP 캐쉬-컨트롤(Cache-Control)은 맥스-에이지(max-age) 값을 static 으로 설정하고, 만료기간을 계산한다. 미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod) 값이 정의되면, 서비스 리스트 업데이트를 업데이트한다.
<DVB-I Service List discovery scheme>에서 정의한 @ServiceListURI 에 대한 HTTP Cache-Control은 맥스-에이지(max-age) 값에 관계 없이, @MinimumMetadataUpdatePeriod 값을 통해 service list 의 query 주기를 dynamic 하게 설정하고 변경할 수 있다.
또한, Content guide manager (690050) 정의된 @MinimumMetadataUpdatePeriod 에 따라 최신 정보를 획득하기 위해 각 서비스에 대응되는 콘텐츠 가이드의 @ContentGuideSource HTTP endpoint 를 이용하여 특정구간에서 dynamic 하게 polling 을 한다.
Option 5, 6 ContentGuideSource level의 시그널링의 의미 및 수신 동작은 다음과 같다.
service 내 ContentGuideSource 를 정의하는 @MinimumMetadataUpdatePeriod는 DVB-I single service 의 ContentGuideSource 를 업데이트 할 수 있는 polling period 이다.
DVB-I 컨텐트 가이드 매니저(content guide manager, 690050)는 정의된 @MinimumMetadataUpdatePeriod 값에 따라 각 서비스에 대응되는 콘텐츠 가이드의 @ContentGuideSource 내의 HTTP endpoint 를 이용하여 특정구간에서 dynamic 하게 polling 을 수행한다.
실시예들에 따른 동작의 예시를 들면 다음과 같다.
어베일러빌리티 엔트 타임(@availability End Time)="12345”
현재 서비스되는 데이터의 엔드타임이 12345일 수 있다. 오버-러닝 이슈가 없다면 예정된 스케쥴에 따라서, 기준시점 12345 이후부터 다음 서비스 데이터를 수신 장치가 수신하여 재생할 수 있다.
미니멈 메타데이터 업데이트 피리오드(@MinimumMetadataUpdatePeriod) = 1000
수신 장치는 셋팅된 업데이트 피리오드 값인 1000마다 컨텐트, 서비스에 대한 리스트, 가이드 정보를 포함하는 메타데이터를 수신하기 위한 업데이트 동작을 수행할 수 있다.
버전(@version) = 1->2
버전은 업데이트 또는 폴링 동작을 나타낼 수 있다. 버전이 1에서 2로 바뀌면, 스테틱 폴링에서 다이나믹 폴링으로 버전이 변경됨을 나타낼 수 있다.
유니크 식별자(@UniqueIdentifier) = korea123
수신 장치는 유니크 식별자 korea123가 나타내는 서비스 및/또는 서비스 정보를 수신할 수 있다.
이와 같이, 업데이트 피리오드(@MinimumMetadataUpdatePeriod) 값이 정의되면, “”의 간격으로 수신 장치(client) 는 스케쥴 정보 엔드 포인트(@ScheduleInfoEndpoint) 의 TV 애니타임(anytime)의 나우/넥스트 필터링된 스케쥴 리퀘스트(Now/Next Filtered Schedule Request) 의 정의에 따라 (예를 들어, <ScheduleInfoEndpoint>?korea123=12345&now_next=true )의 쿼리(query)를 송신 측에 보낼 수 있다. 이를 통해 송신 측의 서버, 프로세서, 메모리 등에 엑세스(access) 하고, 사용자에게 해당 시점에서 필요한 새로운 서비스 및 콘텐츠 가이드를 갱신 할 수 있다.
<attribute name="dynamic" type="boolean" default="false"/>
송신 장치는 DVB-I 서비스 리스트 하이어라키(service list hierarchy)에 따라 각 서비스 리스트 내 대응되는 LCN테이블 리스트(LCNTableList) 와 LCN테이블(LCNTable) 내 로지컬 채널(Logical channel)들을 생성할 수 있다. 송신 장치는 각 LCN 테이블 엔트리 타입(LCNTableEntryType) 에 포함되는 서비스 레퍼런스(@serviceRef)는 각 서비스의 유니크 식별자(@UniqueIdentifier)와 연결되어 서비스 별 LCN 채널을 제공할 수 있다. 각 각 서비스와 연결된 LCN 채널들은 채널의 속성에 따라 셀렉터블/비저블(selectable/visible)할 수 있는 속성들을 정의할 수 있다.
컨텐트 가이드 매니저(content guide manager, 690050)와 서비스 리스트 매니저(service list manager, 690010)은 일련의 파싱(Parsing) 과정과 캐싱(caching) 과정을 통해 클라이언트(DVB-I client)의 LCN 채널을 채널 데이터베이스(DataBase)에 저장한다. 그리고, 사용자에게 접적으로 UI 로 채널 정보를 제공한다.
채널 DB 에 저장된 LCN 리스트가 최신 정보로 업데이트되지 않을 경우, 재생중인 콘텐츠 정보와 얼라인(aligned)된 UI 가 디스플레이되지 않을 수 있다.
DVB-I 컨텐트 가이드 UI 제어부(content guide UI, 670040)는 정확한 정보를 나타내기 위해서, 채널 DB에 해당 채널(예를 들어, DVB-I를 위한 채널)이 다이나믹 폴링(Dynamic polling)이 지원됨을 나타낼 수 있다. 예를 들어, 다이나믹(@dynamic)의 불리언 어트리뷰트(bool attribute)에 기반하여 인디케이션(indication)할 수 있다.
이러한 정보를 통해 DVB-I LCN DB는 특정 서비스에 해당하는 LCN 이 다이나믹 폴링(dynamic polling)할 수 있는 채널로 특정구간에서 변화가 일어날 수 있다는 미리 노티피케이션(notification)할 수 있다. 해당 처리를 통해 DVB-I client 는 cached 된 채널 DB에서 특정 채널만 업데이트 할 수 있는 인터페이스를 만들어주고, Dynamic polling 을 통해 업데이트 된 channel 정보를 UI 에 반영할 수 있다.
실시예들에 따른 채널DB, LCN DB 등이 프로세서에 연결된 미디어 처리 장치에 대응할 수 있다.
도27은 실시예들에 따른 DVB-I 서비스 별 content guide 최신 정보를 획득 하는 방법을 나타낸다.
상기 DVB-I service scheme 에 따르면, ContentGuideSource 를 받아오는 방법은 2가지가 존재한다. (1) Service list 레벨에서 전체 서비스들의 정의한 구간의 ContentGuideSource 를 모두 일정 하게 수신하거나, e.g. one of the following times of day (0:00, 3:00, 6:00, 9:00, 12:00, 15:00, 18:00, 21:00) (2) service 레벨에서 ContentGuideSource 정보를 수신하는 방법이다.
정보를 요청하는 방법은, 2가지 방법 모두 하기의 방법에 따라 정보를 수신한다.
Example URL:
<ScheduleInfoEndpoint>?sid=12345&now_next=true
상기 scheme 와 같이, @ScheduleInfoEndpoint 는 ContentGuideSourceType 내 동일한 방법으로 정의 할 수 있다. 그 의미는, service list 레벨에서 받을 수 있는 endpoint 와 service 레벨에서 받을 수 있는 endpoint 가 동일하게 정의해야 하는 한계를 가지고 있다. 따라서 수신하는 구간도 service list 와 service 레벨을 동일하게 정의할 수 밖에 없다. 위와 같이 ContentGuideSouceList - ContentGuideSource - ContentGuideSourceType - ScheduleInfoEndPoint 는 service list 와 service 에 동일하게 정의되어 있어, 같은 정보를 받아야 하는 한계점이 존재한다.
도28은 실시예들에 따른 컨텐트 가이드 소스 하이어라키를 나타낸다.
도29는 실시예들에 따른 DVB-I 서비스 이니셜라이제이션 및 컨텐트 가이드 업데이트 흐름도를 나타낸다.
도28의 ScheduleInfoEndpoint + sid 를 통해 now/next 를 받아오는 것은 서비스 간 모두 동일하여 발생된 한계는 서비스를 업데이트 시, 특정구간에 업데이트 만을 요청하는 방법을 할 수 없게 설계되어 있다. 각각의 period 의 대응되는 서비스 별endpoint 를 분리하여, 서비스 별 특정 개별 주기(individual period) 를 위한 end point 를 추가해야 한다.
도29는 DVB-I service server 와 DVB-I client 간에 service Initialization 와 content guide Initialization 및 update 과정을 나타낸 그림이다. 그림과 같이 DVB-I service discovery 과정 -> Service list 획득 과정 -> DVB-I streaming 초기화 과정 -> Content guide 초기화 과정을 현재 스키마를 통해 적용할 수 있다. 하지만, 현재 단계에서는 동일한 content guide update 로 개별 event 및 individual period 에 업데이트는 지원할 수 없기 때문에 기존의 정의된 time window 구간만을 service list level or service level 에 동일하게 적용할 수 밖에 없는 한계가 존재한다. 따라서 리퀘스트 및 리스폰스 과정을 위해 DVB-I service scheme 확장 방안을 제안 한다.
도30-31은 실시예들에 따른 DVB-I service scheme 을 나타낸다.
이는 실시예들에 따른DVB-I service list response 의 예제로 ContentGuideSource element 들을 수신 받을 수 있다. DVB-I client 는 서비스 별 Individual Period 간 content guide metadata 를 요청 하기 위한 endpoint 로, IndividualPeriodEndpoint 를 수신 받을 수 있다. Client 는 IndividualPeriodEndpoint 를 통해, 하기와 같은 string 을 생성하고 구간별 metadata 정보를 요청 할 수 있다.
[실시 예 1]예를 들어, Service ID = 10 Service 를 2020-3-26 21:00:00 ~ 2020-3-27 00:00:00의 정보를 획득한다고 하고, Service ID = 11 은 2020-3-26 21:00:00 ~ 2020-3-27 03:00:00 의 데이터를 획득한다고 가정하면, (unix time 기준)
https://cgs.az.metadata/IndividualPeriod?start=1585224000&end= 1585234800&sid=10
https://cgs.az.metadata/IndividualPeriod?start=1585224000&end= 1585245600&sid=11
서비스 별 해당 정보를 발생하고 해당 정보를 통해 개별 구간의 데이터를 요청할 수 있다.
[실시 예 2] 예를 들어, Service ID = 10 의 service 를 현재 시점 ~ 2020-3-27 00:00:00의 정보를 획득한다고 한다면, Service ID = 11 은 현재 시점 ~ 2020-3-27 03:00:00 의 데이터를 획득한다고 가정하면, (unix time 기준)
https://cgs.az.metadata/IndividualPeriod?sid=10&now&end=1585234800
https://cgs.az.metadata/IndividualPeriod?sid=11&now&end=1585245600
MULTIPLE SERVICE LISTS 를 지원하기 위한 DVB-I CLIENT TECHNICAL IMPROVEMENTS
DVB-I conceptual model 을 나타내며, 각 interface 는 DVB-I client 가 service discovery 와 각 Service 에 대응되는 Media stream 을 수신하기 위한 일련의 과정을 나타내고 있다. 각 Interface 의 description 은 아래와 같다. 실시예들에 따른 수신 장치는 DVB-I service list discovery 동작과 registry entity 접근 동작을 수행하여 상술한 발명의 효과를 제공할 수 있고, 실시예들에 따른 송신 장치는 수신 장치가 이러한 동작을 수행할 수 있도록 multiple service lists 시그널링 방안을 제공할 수 있다.
도32는 실시예들에 따른 DVB-I 모델을 나타낸다.
DVB-I client: A DVB-I client로써, 실시예들에 따른 미디어 데이터 처리 장치에 해당한다.
Service List Registry: 서비스 리스트 서버들의 리스트를 클라이언트에 제공할 수 있다. 리스트 제공은 쿼리 파라미터들에 기반하여 수행될 수 있다.
Service List Server(s): 클라이언트에 서비스 리스트들을 전달하는 서버이다. 개별 서비스 리스트 서버는 멀티플 컨텐트 및 서비스 프로바이더들로부터 서비스 리스트 프래그먼트들을 통합할 수 있다.
Content Guide Server(s): 컨텐트 가이드 데이터에 대한 클라이언트로부터 요청들에 대한 응답할 수 있다. 개별 DVB-I서비스에 대한 컨텐트 가이드 서버들은 서비스를 위한 서비스 리스트 엔트리 내 참조될 수 있다.
Content / Service Provider(s): DVB-I 서비스들을 제공할 수 있다.
Playlist Server(s): 싱글 DASH MPD를 다이렉트하게 참조하기 보단 DVB-DASH 컨텐트 아이템들의 플레이 리스트를 참조하는 서비스들에 대한 플레이 리스트를 제공할 수 있다.
MPD Server(s): DASH MPD들을 제공할 수 있다.
Stream Server(s): DASH 미디어 세그먼트들을 DVB-I 클라이언트에 제공할 수 있다.
Multicast Server: 어답티브 비트레이트 멀티캐스트를 위한 서버이다.
Multicast Gateway: 어답티브 비트레이트 멀티캐스트를 위한 게이트웨이이다.
A1: Content guide query: 컨텐트 가이드 쿼리이다. DVB-I클라이언트로부터 컨텐트 가이드 서버로의 요청을 의미한다.
A2: 컨텐트 가이드 데이터이다.
B1: 서비스 리스트 쿼리이다. DVB-I클라이언트로부터 서비스 리스트 서버로의 요청이다. DVB-I 클라이언트는 전체 서비스 리스트를 요청할 수 있다. 서비스 리스트는 로컬하게 필터링되거나 이미 필터된 리스트일 수 있다.
B2: 통합된 서비스 리스트이다.
C1: 플레이리스트를 위한 요청이다. HTTP GET 리퀘스트일 수 있다.
C2: 플레이 리스트이다.
D1: DASH MPD를 위한 리쉐스크이다. HTTP GET 리퀘스트일 수 있다.
D2: DASH MPD: ETSI TS 103 285 표준에 따른 DASH MPD드이다.
E1: 미디어를 위한 리쉐스트이다. HTTP GET 리퀘스트일 수 있다.
E2: Unicast DASH: According to ETSI TS 103 285 [1].
F1: 서비스 리스트 서버(들)의 엔트리 포인트(들)을 결정하기 위한 리쉐스트이다. 이 리퀘스트는 서비스 리스트 디스커버리 내 선택을 수행하기 위한 쿼리를 서포트할 수 있다.
F2: 리퀘스트 기준에 매칭되는 서비스 리스트 엔트리 포인트들의 리스트이다.
N1: 컨텐트 가이드 데이터이다.
N2: 컨텐트 가이드 서버의 URL들이다. 인터페이스 O의 서비스를 위한 대응하는 서비스 리스트 엔트리 내 포함되는 컨텐트 및 서비스 프로바이더들의 서비스들 각각에 대한 컨텐트 가이드 데이터에 대한 URL들
M: 서비스 리스트 서버들에 대한 서비스 리스트 엔트리 포인트들의 레지스트레이션이다.
O: 서비스 레코드들이다. 싱글 컨텐트 / 서비스 프로바이더에 의해 제공되는DVB-I 서비스들에 대한 데이터이다.
P1: 플레이리스트이다.
P2: 플레이리스트들을 위한 URL들이다. 인터페이스O에 대한 서비스를 위한 대응하는 서비스 리스트 엔트리 내 포함되는 플레이리스트들에 대한 URL들이다.
Q1: ETSI TS 103 285 표준문서에 따른 DASH MPD들이다.
Q2: 인터페이스 P1의 서비스에 대한 플레이리스트 또는 인터페이스O의 서비스에 대한 서비스 리스트 엔트리 내 포함되는 DASH MPD들을 위한 URL들이다.
R: 미디어를 위한 URL들이다. DASH MPD들 내 포함되는 미디어를 위한 URL들이다.
X: DVB A176 표준 내 Pin' 또는 Oin 인터페이스일 수 있다. DASH 미디어 데이터의 멀티캐스트 서버로의 플로우 관련 정보이다.
Y1: 멀티캐스트이다. A176 표준 내 인터페이스M일 수 있다. 멀티캐스트 상 DASH 미디어 데이터의 플로우 관련 정보일 수 있다.
Y2: 유니캐스트 리페어이다. 인터페이스Y1으로부터 손실된 데이터를 리페어하기 위한 유니캐스트 상 DASH 미디어 데이터의 흐름도 관련 정보이다. DVB A176 표준문서 내 인터페이스U일 수 있다.
Z: 유니캐스트 DASH이다. ETSI TS 103 285 문서를 따르는 DVB-I클라이언트로부터 멀티캐스트 게이트웨이으로부의 인터페이스 관련 정보이다. DVB A176 내 인터페이스L일 수 있다.
실시예들에 따른 미디어 데이터 처리 장치인 DVB-I Client 는 DVB-I Player, TV device, 2nd device 등에 대응할 수 있다.
DVB-I 표준에서는 F1, F2 인터페이스에서 서비스 디스커버리와 그것의 응답으로 서비스 리스트 엔트리 포인트(service list entry point)들을 수신한다. 또한 B1, B2 과정에 따라 사용자 언어, 국가, 지역, 선호도 등을 반영하여 큐레이팅(curating)된 리스트(list)를 받을 수 있다.
이를 통해 서비스 통합(service aggregation)이 가능하다. DVB-I 클라이언트는 서비스 리스트 서버들의 선택을 제안할 수 있고 멀티플 서비스 리스트 서버들로부터 서비스 리스트들을 통합(aggregate )할 수 있다.
DVB-I client 는 service list server들을 선택을 제공할 수 있고, multiple service list server 로부터 온 service list 를 aggregation 할 수 있다. 이에 더불어 DVB-I client 가 install 후 최초 접근하여 Service list Server 들을 보여줄 list 들의 list 를 보여주는 F1, F2과정이 다음과 같이 있을 수 있다:
1. DVB-I클라이언트를 실행하는 디바이스의 제조사는 그러한 디바이스들을 제공할 수 있다.
2. 관련된 국가 및 지역 내 동작하는 클라언트들의 이익을 위한 정보를 제공하는 국가 또는 지역 기관(regulator)
3. 클라이언트들을 위한 오퍼레이터 또는 플랫폼
4. 서비스 리스트들에 대한 정보를 제공하는 DVB-I 클라이언트를 수행하는 모든 디바이스들의 이익을 위해 동작하는센트럴 서비스 리스트 레지스트리(Central Service List Registry (CSR)).
5. 제3자 서비스 리스트 통합자(A third-party service list aggregator).
위와 같이 service list registry 를 운영(Operate)할 수 있는 방법들이 있는데, 4번째 case 와 같이 DVB-I CSR 의 기능은 DVB-I 서비스 리스트 프로바이더(service list provider) 또는 서비스 프로바이더(service provider)들이 CSR 에 서비스를 등록하고, DVB-I 가 F1을 통해 부트스트랩핑(bootstrapping) 시, 획득된 정보에 따라 등록된 list 들의 list 를 보여줄 수 있다. 사용자는 등록된 list 들의 list 들을 기반으로 User preference 와 국가/언어/지역 등의 Filtering criteria 들을 통해 서비스 리스트를 선택하고 직접 핸들링 할 수 있다.
도33은 실시예들에 따른 제조사 서비스 리스트 지원을 위한 DVB-I 서비스 아키텍쳐를 나타낸다.
제조사(Manufacturer)가 DVB-I client 를 실행(implementation) 하는 경우, 서비스 리스트 프로바이더(Service list provider)의 역할로 Mfr 서비스 리스트들을 등록하고, service 들을 collect 하여 전체 registry 를 관리하고 서비스 리스트를 curating 할 수 있다. 이를 지원하는 service discovery architecture 도면은 도23과 같다. 도23의 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응될 수 있다.
제조사 서비스 리스트 레포지토리 지원 서비스 디스커버리 엔티티 확장(Manufacturer service list repository 지원 service discovery entity 확장)
도33은 Manufacturer service list 지원 DVB-I service architecture 로 DVB-I client, Service provider, 스트리밍 서버(streaming server), CSR, service list provider repository 를 포함한다. 각 모듈의 역할과 수신기 동작은 하기와 같다.
DVB-I client : system client 와 DASH engine 으로 구성되고, system client 는 service bootstraping 과 service list discovery 그리고 Service manager 를 통해 여러 개의 서비스 리스트들을 merge 하고 curating 한다. 또한 각 service list 내의 할당된 Channel DB 관리와 content guide 및 app launching 을 수행한다. DASH engine 은 HTTP 와 DASH delivery 를 수신하여 디코딩과 랜더링을 수행한다.
Service provider : 디즈니, 폭스와 넷플릭스, 훌루, 아마존프라임 등의 OTT 업체들, MNO 나 IPTV 사업자들, 개인 채널 운영자 등 콘텐츠를 제공할 수 있는 주체들이 리스트 프로바이더들에게 콘텐츠를 제공한다.
service list provider repository: 리스트 프로바이더들은 리스트를 큐레이팅 해서 DVB CSR 에 리스트를 등록한다.
CSR : DVB-I client 의 최초 bootstraping location 으로, list들의 list 를 관리하는 곳이다.
각 인터페이스의 역할은 다음과 같다.
[Interface 0]: 리스트 프로바이더들은 리스트를 큐레이팅 해서 DVB CSR 에 리스트를 등록한다.
[Interface 1]: Mfr 또한 리스트를 관리할 repository 를 운영하고, DVB CSR 에 리스트를 등록한다.
[Interface 2]: DVB-I 서비스를 launching 하고, DVB-I service discovery query 를 보내면, 일련의 bootstrap 과정을 거쳐서 사용자 언어, 국가, 지역, postcode 에 따라서 필터링된 리스트 엔트리를 보여준다. 사용자 선택이나 환경에 맞춘 service entity 들과 그 service entity repository 에 접근할 ServiceListURI 을 수신한다.
[Interface 3-a]: service list repository 에 접근할 ServiceListURI 를 통해 DVB-I service list 들을 수신
[Interface 3-b]: service list repository 에 접근할 ServiceListURI 를 통해 Mfr 의 Service list 를 수신
[Interface 4-a]: DVB-I service list 내 각 service 들의 수신 가능한 instance 를 요청하여 콘텐츠 수신
[Interface 4-b]: DVB-I service list 내 각 service 들의 수신 가능한 instance 를 요청하여 콘텐츠 수신
실시예1) https://csr.dvbservices.com/query?TargetCountry=ITA&regulatorListFlag=true
CSR 에 DVB-I service discovery query 를 보내면, CSR 이 아래와 같은 DVB-I service discover data 및 ServiceListURI 를 제공한다. DVB-I client 는 https://dvbi.TVfromTheWorld.com/engTVservices.xml 를 접근하여 서비스 리스트를 수신한다.
<ServiceListURI contentType="application/xml">
<dvbisd:URI>https://dvbi.italian-authority.it/trusted-services.xml</dvbisd:URI>
</ServiceListURI>
실시예2) https://dvbisr.private-service-list-registry.com/query?ServiceListName=LGchannels
CSR 에 DVB-I service discovery query 를 보내면, CSR 이 아래와 같은 DVB-I service discover data 및 ServiceListURI 를 제공한다. DVB-I client 는 https://www.LgChannels/dvbmfr/UK/servicelist.xml 를 통해 접근하여 서비스 리스트를 수신한다.
<ServiceListURI contentType="application/xml">
<dvbisd:URI>https://www.LgChannels/dvbmfr/UK/servicelist.xml</dvbisd:URI>
</ServiceListURI>
이때, DVB-I Service discovery information 은 하기와 같은 정보로 구성하며 각 서비스 리스트 entity 들을 정의할 수 있다.
도34는 실시예들에 따른 DVB-I Service discovery information 을 나타낸다.
DVB-I service list discovery scheme는 위와 같이 service list registry 와 service list 를 제공하는 제공자 offering 정보를 정의할 수 있다. 그림 18과 같이 별도의 mfr 만의 service provider entity 로서 서비스를 제공할 때, service discovery 시 mfr 의 offering 정보와 mfr 가 제공하는 service list 의 수신가능여부를 묻는 정보가 확장되어야 한다. Mfr service list 를 지원가능 여부를 확인 할 수 있는 capabilities 정보의 확장이 필요하다. 현재 DVB-I service list discovery scheme 내 Extension 을 활용하여 도35 같은 syntax 를 확장할 수 있다.
도35는 실시예들에 따른 서비스 리스트 레지스트리 엔티티의 신택스를 나타낸다.
OSName: 지원 가능한 OS 버전과 이름
ServiceCode: Device 내 지원 가능한 서비스 코드
TargetLocation: Device 가 만들어진 타겟 위치(target location) 예) UK향, Nordic 향
Sourcelocation: 각 Service 를 제공하는 스트리밍 서버의 위치
PublishedDate: 서비스 리스트 퍼블리쉬 데이터(Service list publish data)를 의미
ReleasedDate: 서비스 리스트 릴리즈 데이터(Service list release data)를 의미
Manufacturer: 서비스 리스트 임플리멘테이션(Service list implementation) 업체
ManufacturerURL: 서비스 리스트 임플리멘테이션(Service list implementation) 업체 URL
ServiceDescription: Service list 의 간단한 설명(description) 예) list 표시 문구
ServiceReport: Service list 의 이슈 또는 소비 리포트(consumption report)
펌웨어 업그래이드(FirmwareUpgrade)
Version: 플랫폼(Platform)이 지원해야 할 펌웨어 버전 넘버(Firmware version number)
UpdateLocationURL: 펌웨어 업데이트(Firmware update)를 위해 접근 가능한 URL
서비스 어베일러빌리티(ServiceAvailability)
Version: 서비스 리스트(Service list)가 제공 되고 있는 현재 버전
ServiceAvailabilitySearchURL: 서비스 리스트 프로바이더(Service list provider)가 제공하는 추가 서비스를 애딩(adding)할 수 있도록 서비스 검색이 가능한 웹페이지로 이동하는 URL
ServiceAvailabilityDBUpdateURL: 서비스 데이터 기반 업데이트(Service data base update) 를 할 수 있는 링크 URL. IETF RFC 5261 기반 XML 업데이트를 지원하기 위한 스키마가 다운로드 되며, 해당 정보를 통해 페치(fetch)가 가능함.
도36은 실시예들에 따른 서비스 리스트 레지스트리 엔티티의 세만틱스를 나타낸다.
도37은 실시예들에 따른 서비스 리스트 선택 UI/UX를 나타낸다.
실시예들에 따른 시맥틱 및 신택스에 따라 실시예들에 따른 미디어 데이터 처리 장치는 도37와 같이 서비스 리스트 관련 정보를 표시할 수 있다.
서비스 리스트 관련하여, 프로바이더, 언어, 장르, 국가 등에 기반하여 서비스 리스트를 선택할 수 있다.
제조사 서비스 리스트 레포지토리(Manufacturer service list repository)를 지원하는 서비스 디스커버리 엔티티(service discovery entity)를 추가하고, 프로바이더(provider) 를 통해 특정 제조사 서비스 리스트(Manufacturer service list )를 필터링할 수 있다. 실시예와 같이 UK 지원 LG channels 서비스를 소비할 수 있다.
도38은 실시예들에 따른 멀티플 서비스 리스트(Multiple service list) 수신 시 채널 충돌 대응 방법을 나타낸다.
멀티플 서비스 리스트(Multiple service list) 수신 시 채널 충돌 이슈
DVB-I 는 서비스 리스트 기반 서비스를 수신하고, 각 서비스 리스트는 특정 repository 에서 운영 및 관리되고 있다. 기존 DVB 방송 리스트를 제공하는 repository 는 현재 유럽 방송서비스 특성 상 국가나 특정지역 기준으로 LCN 의 할당하는 방식으로 취하여 DVB-I 서비스 리스트를 정의할 수 있다. 반면, 특정 DVB-I 서비스 리스트 프로바이더들은 지역에 관계없이 독립적인 서비스들을 수집하고 LCN list 를 정의하기 때문에 LCN allocation 은 service list provider 의 임의대로 설정이 가능하다. 따라서 이러한 배경 하에, DVB-I client 는 Multiple service list 들을 수신 및 merge시 채널 충돌의 잠재적인 이슈가 존재한다.
Use case 1 은 service list 와 각 Service ID, 서비스 리스트가 할당하고자 하는 LCN, legacy TV 에서 사용되고 있는 LCN, 실제 콘텐츠를 구분 한 것으로, 각 서비스 리스트에 할당된 서비스와 채널들이 할당 된 것을 의미한다. Use case 1 은 서로 다른 리스트 List A 와 List B 를 수신 시, Sid/LCN 모두 동일하게 할당되고 콘텐츠도 동일하여 상기 4개의 서비스 리스트를 merge 시, 이슈 없이 서비스를 제공할 수 있다.
Case 2 는 multiple 서비스 제공자 + 다른 service ID + 같은 LCN 의 경우로, 다른 서비스가 하나의 LCN 으로 할당되어 충돌되는 경우이다.
Case3 은 DVB-T + multiple 서비스 제공자 + 같은 service ID + 다른 LCN 의 경우로 DVB-T 와 List A 는 Hybrid 환경과 다수의 서비스 제공자가 service ID 는 동일하게 할당 받았으나, service list C가 LCN 을 동일하게 할당 했을 때 발생할 수 있다.
Case 4 는 multiple 서비스 제공자 + 다른 service ID + 같은 LCN 의 경우, 현지 국가/지역 서비스 리스트와 이민자가 자국의 리스트를 통합한 경우 발생할 수 있다.
실시예들에 따른 case 들을 통해, 서비스 리스트들을 merge 했을 때 잠재적인 LCN 충돌 이슈 가능성이 존재한다. 이러한 이슈를 해결 할 수 있도록 DVB-I 표준을 아래와 같이 확장하여 실시예들에 따른 미디어 데이터 처리 장치는 LCN 충돌 없이 합리적인 할당을 할 수 있다.
도39는 실시예들에 따른 LCN 테이블 엔트리 타입 확장을 나타낸다.
실시예들에 따른 DVB-I 서비스 리스트(Service list)들을 수신하고 통합하는 통합된 서비스 매니저(Integrated service manager)에서 서비스 리스트 통합작업을 수행한다. 수신된 각 서비스 리스트 내 타겟 영역(Target Region) 또는 구독 패키지(subscriptionPackage)를 통해 국가/지역이나 유의미한 패키지(package)를 통해 수신되는 LCN 테이블(table)을 정의한다. 도2528-29는 LCN table 을 확장하여 상기 충돌 발생 시, 해당 정보를 통해 합리적인 통합 채널 할당을 가능하게 할 수 있다. 구체적인 XML xsd 는 아래와 같다.
실시예들에 따른 송수신 방법/장치는 다음과 같은 LCN table 에 포함된 엘리먼트(들)에 기반하여, Multiple service list 수신 시 채널 충돌 이슈를 해결할 수 있다. 실시 예들에 따른 송신 장치는 다음과 같은 LCN table에 포함된 엘리먼트(들)을 포함하는 정보를 생성하여 전송할 수 있고, 및/또는 실시예들에 따른 수신 장치에 포함(또는 연결)된 DVB-I Service list 들을 수신하고 통합하는 Integrated service manager(매니저 또는 컨트롤러 등으로 다양하게 지칭 가능함)을 통해 통합 채널을 할당하고 관리할 수 있다. 또한, 실시예들에 따른 프로세서는 실시예들에 따른 통합 채널 할당 동작에 관한 인스트럭션을 저장하는 메모리, 제어부 등에 기반하여 서비스 리스트 통합 동작을 제어할 수 있다. 한편, 실시예들에 따른 LCN table은 LCN 정보 등으로 지칭될 수 있고, LCN table에 포함된 엘리먼트들은 제1정보, 제2정보 등으로 지칭될 수 있다.
도40은 실시예들에 따른 LCN 테이블 엔트리 신택스를 나타낸다.
서비스 리스트의 우선 순위는 사용자가 처음으로 선택한 지역이나 국가로 설정하거나, 지리학적으로 현재 DVB-I client 가 install 되는 시점의 지역을 우선 순위로 한다. 추가로 서비스를 통합 시에는 후 순위로 고려한다. 수신기는 해당 리스트를 우선순위 리스트로 저장하여 이후에 수신되는 리스트에 대해 관리할 수 있다.
DVB-I client 는 해당 정보를 활용하여 user 에게 채널 할당 가이드라인을 줄 수 있고, user 의 의도에 따라 직접 채널 번호의 재 할당이 가능하다.
스위스에 거주하는 user 가 스위스 서비스 리스트인 service list 1을 수신하고 추가 리스트를 service list 2 을 DVB-I client 가 수신한다고 하면, 각 DVB-I service 내 unique identifier 와 연결되는 ServiceRef 정보와 화면에 표시할 channel number 를 수신 한다. 이때 두 list 의 할당된 channel number = 0이 같은 번호로 정의되어 채널 충돌이 일어나면, DVB-I client 는 동일한 채널을 처리하는 데 문제가 발생한다. 이때 본 발명에서 확장한 favorite channel information 을 통해 1000 번을 할당하여 채널중복 이슈를 해결 할 수 있다.
도41은 실시예들에 따른 서비스 채널 충돌을 해결하는 예시를 나타낸다.
상술한 바와 같이, DVB-I client 는 service list 2 내 (채널 0번, Sid23)에서 발생한 이슈를 1000으로 새롭게 할당하면서 채널 충돌이슈를 해결할 수 있다.
실시 예2
실시 예 2와 같이 User 의 지역 리스트 인 service list 1 과 service list 2, n개의 리스트를 수신 시, 100번 ~ 108번까지의 채널번호가 충돌하는 경우가 발생할 수 있다. User 의 거주 지역상 Service list 1 의 우선 순위를 가진다고 한다면, Service list 2 번의 채널 충돌 번호는 재 할당이 필요하다. 이러한 경우 충돌채널들은 SecondaryChannelNumberRange 정보를 통해 충돌 채널 번호를 재 할당할 수 있다. 하기 결과와 같이 충돌 채널 번호 100~108번은 SecondaryChannelNumberRange 에 따라 1000번부터 시작하여 새롭게 할당이 가능하다.
도42는 실시예들에 따른 채널 중복 이슈 해결 예시이다.
실시 예와 같이 동일하게 중복되는 채널이 발생시 SecondaryChannelNumberRange 의 정의대로 특정 구간 중에 빈 번호에 채널 할당이 가능하다. 이때 채널 번호 ordering 은 SecondaryChannelNumberRange 내에서 빈 채널에 할당할 때,
(1) 채널 충돌이 발생하여 재 할당이 필요한 ChannelNumber 의 순서로 SecondaryChannelNumberRange 의 값을 오름차순으로 대응하여 mapping 하거나,
(2) 오름차순으로 정의하기 어렵거나, ChannelNumber 가 정확하게 정의되지 않은 경우 DVB-I client 내에 수신된 순으로 단일 리스트 상에서 ServiceRef 의 String 값을 기준으로 제일 앞서는 번호나 문자열의 순서를 앞서는 글자 순으로 순차적으로 할당 할 수 있다.
또한 채널 중복 시 재 할당이 가능한 정보인 FavoriteChannelNumber, SecondaryChannelNumberRange 2가지 모두 채널 정보가 정의된다면, 우선 순위는 FavoriteChannelNumber -> SecondaryChannelNumberRange 의 순으로 채널을 할당한다.
도43은 실시예들에 따른 MPEG-2 시스템 STC구조를 나타낸다.
DVB-I 서비스 레퍼런스 타임 동기화 및 리프 세컨드(SERVICE REFERENCE TIME SYNCHRONIZATION AND LEAP SECOND)
MPEG-2 system 기반 라이브 브로드캐스트 레퍼런스 타임 동기화(live broadcast reference time synchronization)
도43과 같이 MPEG-2 system 에서는 common 한 clock 값을 사용하여 송수신간 동기화를 할 수 있다. 미디어 데이터의 encoding 과 packetizing 을 거쳐 전송 가능한 데이터와 현재 live program 에서 사용하고 있는 reference clock 값으로 PCR (Program Clock Reference, 프로그램 시각 기준값) 을 전송하여 수신단에서는 PCR 의 값으로 송신단과 time synchronization 을 수행한다. MPEG-2 system 기반 방송에서는 live 시에 Current time 과 AV decoding timing을 수행하는데 적용되며, 송수신 간 time synchronization 을 통해 clock 값이 틀어지지 않고 원활한 방송을 할 수 있다. 실시예들에 따른 방법/장치는 도28과 같이 MPEG-2 system에 결합될 수 있다. 실시예들에 따른 방법/장치는 하드웨어, 소프트웨어, 및/또는 프로세서 등에 대응할 수 있다.
도44는 실시예들에 따른 DASH 스트리밍 구조를 나타낸다.
실시예들에 따른 방법/장치는 도29와 같이 DASH streaming architecture 에 결합될 수 있다. 실시예들에 따른 방법/장치는 하드웨어, 소프트웨어, 및/또는 프로세서 등에 대응할 수 있다.그림 23은 MPEG DASH streaming 의 end to end architecture 의 그림이다. Service provider 는 실시간으로 capturing 된 AV media data 를 encoding / packaging 을 거쳐 origin server 에 업로드 하게 된다. Media data 와 manifest 는 Origin server 의 원본 데이터에서 MPD 수정과정과 광고 삽입 등을 거쳐 유의미한 Manifest 가이드로 변환하게 되고, CDN에 ingestion 하게 된다. DASH client 측에서는 요청에 따라 low latency model 과 기존 DASH client mode 로 나뉘어 수신하고 de-packetizing 과 decoding 과정을 거쳐 Media streaming 을 제공할 수 있다. MPEG DASH 에서는 @AvailabilityStartTime 이나 @ProducerReferenceTime 을 통해 송수신간 Media sync 를 지원한다. 하지만, DVB-I player conceptual model 에 따르면, service 들을 초기화 하는 initial engine 과 media 를 처리하는 DASH-client 는 parents-child 관계로 child 의 clock 이 service initial engine 을 컨트롤하는 것은 이슈가 발생할 수 있다.
DVB-I client 간이 Network timestamp 동기화 이슈
실시예들에 따른 방법/장치는 도1과 같이 네트워크에 기반하여 데이터를 송수신할 수 있다.
도1과 같이 DVB-I 의 service model 은 기존 DVB-T/S/C/IPTV 와 IP 기반의 protocol 인 유무선
LAN / 5G 전송을 모두 포함하는 통합 인터넷 채널 서비스를 실현하고자 한다. 또한 기존 DVB 방송의 유사한 UI/UX 를 제공하기 위해, DVB-I 는 기기간 동기화 된 Low latency delivery 기술과 빠른 채널 전환을 통해 라이브 방송의 동기화된 presentation 을 목표 표준화를 진행 중이다. 또한 DVB-I 는 Mobile device, web app, MSE(Media Source Extension), STB, TV set(native) 를 target device 로 하고 있다.
이러한 IP 가 연결이 유효한 기기에는 NTP timestamp 라는 자체적인 clock 값이 존재하여 기준시간을 정하고 있다. 각 디바이스의 OS 플랫폼에 따라 현재 시간을 인터넷상의 특정 time 서버와 동기화 해서 사용하고 있다.
각 기기의 OS 별로 디바이스 자체의 API 를 통해 특정 타임 서버와 시간 동기화를 맞추게 되면 각 기준 time 서버의 동작이 상이하여 시간이 틀릴 뿐만 아니라, 그림 30과 같이 server-side / receiver-side 의 processing 의 time 이 모두 달라서 공통의 시간을 얻어오는 데 이슈가 발행한다. Current time 을 가져오는 Master/Slave 의 오실레이터의 클럭이 서로 미세하게 다를 수 있으므로, 기기간 오차가 생길 수 있다. 이러한 현상들은 각 device 가 시간을 가져올 때 오차가 누적되어 수초 또는 수분 이상 틀어지는 현상을 야기한다.
또한 IP 가 연결된 기기들에서 사용하는 NTP 동기화는 일반적으로 단축이 가능하나 10여분의 시간이 지나야 동기화가 가능하며 Ping 의 오차는 ms 의 정확도를 가지고 있다. 하지만, 현재 비디오 압축 규격 기반 프레임의 delivery time 과 reception time 등을 고려하면 ms 의 오차도 미디어 서비스에서는 이슈가 될 수 있다. 예를 들어 축구경기에서 타인의 골장면이 본인의 디바이스에서는 나오지 않거나, 진행중인 서비스가 갑자기 inactive 되는 현상이 발생할 수 있다. 따라서 DVB-I 의 철학에 따라 기존 DVB라이브 방송과 동일한 UI/UX을 제공한다면, 기기간 동기화를 구현 해야 한다.
도45는 실시예들에 따른 레퍼런스 클럭 동기화를 나타낸다.
도46은 실시예들에 따른 수신 장치의 Reference Clock Sync 동작의 예시를 나타낸다.
DVB-I live 서비스 원활한 제공을 위해서는 기기간 시간 동기화가 필요할 수 있는데 본 발명에서는 네트워크 내에서 DVB-I 서비스를 수신하는 device 의 time 을 하나의 기준 노드의 time 으로 통일하고, 수신 받는 device 들은 송신기의 시간을 기준으로 하여 기기 자신의 시간을 보정하는 동기화 방식을 제안하고자 한다. 그림 45-46과 같이 Timestamp point 정보를 가지고 수신기에서 현재시간을 보정하여 DVB-I service 공통의 시간으로 적용하고, 공통의 time 을 적용한 device 는 실제 가지고 있는 현재 타임과 지속적인 보정을 통해 기기간 동기화가 가능한 timeline 으로 구현할 수 있다.
DVB-I service timeline 의 reference clock(time) 부재 및 leap second 미 적용 이슈
DVB-I conceptual model 에 따르면 DVB-I service는 각 DVB 채널과 IP 채널의 service 및 채널들을 scan 하고 IP 채널의 DASH MPD manifest 를 수신하고 live streaming 을 통해 서비스를 제공할 수 있다. 각 DVB-I client 는 각 service instance 의 service availability 에 따라 service active/inactive 를 결정하고, linked application manager 를 통해 현재 진행중인 콘텐츠에 부가적인 application 을 실행할 수 있도록 구성할 수 있다. 서비스 레벨에서의 송수신간 time synchronization 은 service availability 의 오차 없이 서비스 제공자의 의도와 정확한 시간으로 맞추어 active/inactive 를 결정하고, linked application 을 전달 할 때도 현재 방송 콘텐츠 소비시간을 기준으로 동기화 하여 application engine 이 동작할 수 있도록 구현하는 것이 목표이다.
현재 이슈는 DVB-I reference client 는 live streaming 시, 기준 시간이 없이, client 내부의 시간을 가져오는 method 를 통해 current time 을 가져오고 있다. 상기 timing 획득 방법은 DVB-I client 자체의 network time 을 가져오는 것으로 서비스 제공자가 의도한 시간과 맞지 않는 이슈가 발생한다.
즉, 각 DVB-I service scheme내의 <availability> 와 관련 된 event 를 제작자의 의도에 맞게 제공하기 위해서는 송수신간 reference time 에 따라 time synchronization 을 수행해야 한다. 예를 들어, 실제 <availability> 에서 제공된 service instance 의 유효시간이 "2020-02-19T10:42:02.684Z" 라면, DVB-I 서비스 지원 디바이스는 해당 시간을 기준으로 service 의 진행 여부를 결정해야 한다. 하지만, 현재 DVB-I service scheme 는 수신기에서 어떤 시간을 참고하여 <availability>를 결정할 것인지 불명확하다. 만약, 수신기 내의 자체적인 network API 를 통해 지정된 특정 타임서버에서 시간을 가져온다면, 해당 시간은 그림 30에 따라 틀어진 시간의 보상을 해줄 수 없고, 보상되지 못한 수신기 내 기준 시간은 DASH engine 과 time aligned 되지 않아 기기간 서비스의 시작과 종료시간이 맞지 않는 현상이 발생한다. 따라서, 서비스 레벨의 공통의 시간 적용을 통해, DASH 의 media timeline 과 align 된 service availability 를 제공해야 한다.
한편, 2016년 12월 31일에는 세계협정시 (UTC)와 태양시의 오차를 맞추기 위해 1초가 더 해져 네트워크 시간이 갱신되었다. UTC 기준으로 2016년 12월 31일 23시 59분 59초 이후 2017년 1월 1일 0시 0분 0초 가 된 것이 아닌, 2016년 12월 31일 23시 59분 60초가 추가 되었다. 해당 시간의 미 적용 상태가 지속되면, live streaming 에서는 수초가 틀어져 service 에 issue 가 생길 수 있다. 현재 DVB-I service scheme 는 Leap second 를 고려하지 않아, service availability 의 적용에 어려움이 있을 수 있다. 따라서 해당 시간의 보상을 통해 현재 wall clock 을 보정하고 정확한 시간에 service availability 를 signaling 할 수 있다.
실시예들에 따른 송수신 방법/장치(또는 DVB-I Client)는 DVB-I Service를 DVB-I service scheme 정보에 기초하여 시그널링할 수 있다.
도47은 실시예들에 따른 동기화 요구사항에 따른 유즈 케이스를 나타낸다.
동기화 요구사항에 따라 DVB-I service scheme 내에는 상기 “”이 option1, 2, 3 의 형태로 확장 될 수 있다. dvbisd:anyURI 로 확장 될 수 있는 use case는 하기와 같은 URI 로 정의할 수 있다.
) urn:mpeg:dash:utc:ntp:2014 or urn:dvbi:utc:ntp:2014
(2) urn:mpeg:dash:utc:http-head:2014 or urn:dvbi:utc:http-head:2014
(3) urn:mpeg:dash:utc:http-xsdate:2014 or urn:dvbi:utc:http-xsdate:2014
(4) urn:mpeg:dash:utc:http-iso:2014 or urn:dvbi:utc:http-iso:2014
(5) urn:mpeg:dash:utc:http-ntp:2014 or urn:dvbi:utc:http-ntp:2014
실시예들에 따른 URN에 따른 @value 정보는 다음과 같다.
urn:mpeg:dash:utc:ntp:2014: IETF RFC 7230 기반 적절한 wall clock time을 받아올 수 있는 NTP protocol delivery 기반의 server의 접근 주소 list 제공
urn:mpeg:dash:utc:http-head:2014: IETF RFC 7230 기반 적절한 wall clock time을 받아올 수 있는 HTTP URL 의 list
urn:mpeg:dash:utc:http-xsdate:2014: IETF RFC 7230 기반 적절한 wall clock time을 받아올 수 있는 HTTP URL 의 list, W3C 에서 정의한 xs:dateTime format 수신 가능
urn:mpeg:dash:utc:http-iso:2014: IETF RFC 7230 기반 적절한 wall clock time을 받아올 수 있는 HTTP URL 의 list, ISO/IEC 8601에서 정의한 ISO time code 수신 가능
urn:mpeg:dash:utc:http-ntp:2014: IETF RFC 7230 기반 적절한 wall clock time을 받아올 수 있는 HTTP URL 의 list, IETF RFC 5905에서 정의한 NTP timestamp format 제공
@LeapSecondOffset : DVB-I service list 가 publish 된 시점에서 지금 적용되어야 할 leap second offset이다. 이미 적용된 scheme 로 published 되었다면, 0으로 setting 되어야 한다.
@nextLeapSecondOffset : 돌아오는 Leap second date time 에 적용되어야 할 leap second offset value 이다.
@nextLeapchangeTime : 돌아오는 Leap second date time 정의한다.
실시 예:
<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-xsdate:2014" value="https://ABC.com/datetime"/>
https://ABC.com/datetime 에 따른 Response: “”
<Leapsecond LeapSecondOffset=””nextLeapSecondOffset = “1”nextLeapchangeTime = “2021-01-01T00:00:00Z”
2021년 1월 1일에는 Leap second 1초가 더해져 윤초를 반영할 수 있다.
도26의 실시예들에 따른 DVB-I client 는 DVB-I service list 를 처리하는 service list manager 에서 공통의 wall clock time 을 얻고, DVB-I client 기기간 동기화를 통해 보다 정확한 service availability 를 제공할 수 있다.
도48은 실시예들에 따른 5G 기반 DVB-I 시스템을 나타낸다.
통신망 기반 DVB-I (DVB-I OVER 5G)
DVB-I over 5G 의 표준 목적과 동기는 3GPP TS 103 720 표준 Rel-16 version 기반 미디어 전송 기술과 DVB-I 의 미디어 서비스의 융합을 통해, 범용 인터넷 망과 더불어 5G 망에 접속하면 언제 어디서 미디어 서비스를 소비할 수 있는 표준기술을 만들고자 함이다. 기존 LTE, OTT, LAN 등 범용 인터넷 망 기반 웹 브라우저나 독립적인 application 또는 제조사 미들웨어 기반 application 으로 미디어 서비스를 소비하였다. 이에 최근에 release 된 3GPP Rel-16 version 의 미디어 전송을 위한 표준기술과 유럽 서비스 사업자들의 연합된 서비스 통합 표준 DVB-I 가 유의미한 서비스 프로토콜을 구성함으로써 기존의 서비스보다 더 넓은 서비스 가능성을 열게 되었다.
실시예들에 따른 미디어 데이터 처리 방법은 HPHT/Broadcast 와 LPLT/unicast 더불어 기존의 non-5G 망까지 multiple distribution 의 accessibility가 가능한 통합형 DVB-I solution 을 포함할 수 있다.
DVB-I over 5G 미디어 스트리밍 서비스 요구사항
실시예들에 따른 DVB-I over 5G 구조는 multiple distribution 에서 지원하는 delivery route에서 원활하고 연속성 있는 서비스가 되어야 하고, 최적의 네트워크 환경에 따른 효율적이고 유연한 접속을 통해 서비스를 제공할 수 있다. 구체적인 요구사항은 하기와 같다.
DVB-I Service scheme 내 5GBC, 5GMS, non-5G network(LTE, Wifi 등 OTT 지원 범용 인터넷) 를 Service instance 형태로 포함할 수 있어야 한다.
확장되는 service instance 들인 5GBC, 5GMS, OTT 는 해당 네트워크의 식별을 위해 각 네트워크의 parameter 들이 포함되어야 한다. Ex) 주파수, 5GBC 전송/서비스 식별자, 5GMS 전송/서비스 식별자, DVB triplet 등 서로 다른 네트워크를 통해 전달되는 service instance 간 전환이 합리적으로 원활하다고 인식 될 수 있도록, 서비스 인스턴스 간 proper alignment 를 제공해야 한다.
Play-out 중 신호품질 저하 또는 네트워크 hand over 가 발생 시 다른 service instance 로 전환 할 수 있다. 또한 그러한 스위치는 reasonable 해야 하고, 신호품질의 저하는 특정 기준점이 있어야 한다.
서비스 제공자의 의도에 따라 service instance 간 service priority 를 할당할 수 있다.
관련 지원 use case 는 아래와 같다.
사용자가 5G network 을 지원하는 스마트폰을 구입하여 DVB-I app 을 설치 or 특정 제조사의 미들웨어의 native app (fixed TV 포함)을 실행한다.
단말은 5GBC, 5GMS, OTT 가 지원가능하고 최소한의 지원 bitrate 이상이 되면 네트워크에 따라 선택하거나 단말이 자동으로 판단하여 합리적인 스위칭을 할 수 있다.
DVB-I app 을 실행하면, DVB-I client 는 접속 가능한 service instance 를 UI/UX 를 통해 제공하고 선택할 수 있다.
예를 들어 트래픽이 많이 몰리는 인기 있는 프로그램은 5GBC 에 연결될 수 있다.
5GBC 서비스 중 외부에서 이동 중이거나 음영지역에 진입하면 5GMS 에 연결될 수 있다.
Fixed TV 의 경우 5GBC, Portable device 의 경우 OTT 를 우선으로 5GMS 를 차선으로 선택할 수 있다. 단말의 수신환경과 특성에 따라 Service instance 의 우선순위를 합리적이고 유연하게 스위칭 할 수 있다.
현재 service instance 에서 일정 bitrate 이하에 도달하여 서비스 품질이 떨어질 때 특정 조건에 따라 다른 service instance 로 스위칭 할 수 있다.
UHD 지원 콘텐츠의 경우, 유효 네트워크의 bitrate 의 따라 가장 우수한 조건의 service instance 로 전환할 수 있다.
단말 제조사와 서비스 업체와 특정 비즈니스 logic에 따라 5G aware App 의 접속 우선 순위를 지정할 수 있다.
상기 use case 와 요구사항에 따라 현재 DVB-I 표준으로 구현을 고려해 봤을 때 하기와 같은 이슈가 발생한다.
[Potential issue]
기존의 Network connection 종류와 관계 없이 서비스 app 에서 지정한 지정 location 에 Restful API 만을 통해 미디어 데이터를 받아오기 때문에 서비스의 연속성과 동기화에 이슈가 없음.
DVB-I for 5G 의 경우 network 의 종류에 사업자 들의 bootstrapping 방법과 location 이 달라질 수 있다.
network 특성에 따라 전달되는 propagation delay 가 달라서 linear 서비스의 경우 제공되는 reference time 과 미디어 특성도 망마다 다른 환경의 제공이 될 수 있다.
사업자 마다 discovery URL, 미디어 location URL 이 모두 다르고 이 미디어 중간에 전환 시 완벽한 switching 이 어려운 이슈가 존재한다.
망 내에서 전환이 필요하다는 기준점과 신호품질의 저하라고 판단하는 기준이 명확히 존재하지 않는다.
도49는 실시예들에 따른 DVB-I 서비스 스킴 확장을 나타낸다.
DVB-I Service instance switching 을 지원하기 위한 실시 예와 솔루션
[Time alignment]
상기 이슈들을 해결하기 공통의 reference time 을 획득하고 Service instance 간 틀어진 reference time 을 align 시켜줄 수 있다. 각 service instance 의 level 에서 reference time 을 획득하는 방법도 있지만, Service instance 들을 정의하는 상위 layer의 Service 레벨에서 reference time 을 획득하여 service instance 를 time align 시키는 방법도 존재한다. 도33과 같이, DVBiServiceType 이나, DVBiServiceListType 내에 UTC 를 획득하는 방법을 추가하여 DVB-I client 가 기준이 되는 clock 값으로 보상하여 time align 시킬 수 있다.
구체적인 syntax 위치와 type 값은 하기와 같이 정의할 수 있다. 구체적인 sementics 는 상술한 공통 내용을 참조한다.
실시예들에 따른 방법/장치(DVB client, 단말 등)는 도33의 DVB-I Service scheme extension에 기반하여 미디어 데이터를 송수신할 수 있다.
도50은 실시예들에 따른 Service instance switching 을 위한 정보를 나타낸다.
비교 비트 레이트(@ComparisonBitrate): 이 서비스를 위해 이용 가능한 서비스 인스턴스보다 나은 유저 경험(user experience)을 제공하는 특정한 IP 전달 서비스 인스턴스를 핸들링할 수 있는 비트레이트를 의미한다.
비교 컨텐트 어트리뷰트 타입(@ComparisonContentAttributeType): 어느 비디오 및 오디오 특성이 이 서비스를 위해 이용가능한 서비스 인스턴스보다 AV 특성 비교 및 더 나은 유저 경험을 제공하는 DVB-I클라이언트를 위해 이용 가능한지를 나타낸다
비교 비트레이트 피리오드(@ComparisonBitratePeriod): 사용자에게 더 나은 UX 를 제공을 위해 service instance 간 비교가 유효여부를 확인하기 위한 조건으로 수신 bitrate 가 MinimumBitRate ~ ComparisonBitrate 구간에 지속되는 시간
@ComparisonBitRate, @ComparisonContentAttributeType, @ComparisonBitratePeriod 3가지 element/attribute 는 각 device 에 reference 값으로 사용될 수 있으며 각 device 의 자체적인 조건에 따라 활용될 수 있다. 단, DVB-I phase 1 수신기 service instance 전환 조건에 역호환성을 지원해야 하며, 사용자의 불편이 없어야 한다.
다이나믹 스위칭(@Dynamic_switching): 사용자에게 더 나은 UX 를 제공하기 위해 Service instance 간에 switching이 유효하게 하는 flag
실시예들에 따른 방법/장치는 T/S/C + 인터넷 채널(DVB-I) + 5G 등 네트워크를 모두 지원하고 망 간 효율적인 전환이 가능하다. 또한, DVB-I CLIENT는 실시예들에 따른 모든 망을 통하여 실제 미디어 데이터 및 DVB-I service scheme 정보를 수신할 수 있다. 구체적으로, 단일 서비스 정의(unique ID) 를 시작으로, 단일 서비스가 지역서비스와 delivery method 에 따른 service instance 로 각각 정의될 수 있다. serviceType 에서 여러 serviceinstanceType 으로 정의될 수 있고 이 서비스는 하나로 모두 같을 수 있다.
도51은 실시예들에 따른 서비스 인스턴스 스위칭 예시이다.
도51 참조하면, 상술한 use case 중 “바) Fixed TV 의 경우 5GBC, Portable device 의 경우 OTT 를 우선으로 5GMS 를 차선으로 선택할 수 있다. 단말의 수신환경과 특성에 따라 Service instance 의 우선순위를 합리적이고 유연하게 스위칭 할 수 있다.“ 또는 “라) 예를 들어 트래픽이 많이 몰리는 인기 있는 프로그램은 5GBC 에 연결될 수 있다.” 에 따라 일정 조건 기준으로 OTT 에서 5GBC 로 이동할 수 있다. OTT 의 평균 수신 bitrate 가 낮은 품질의 비디오 품질 이하로 일정기간 지속되면 service instance switching 을 고려해야 한다. 이때 단말의 수신환경을 비교하여 service instance 의 switching use case 를 구현할 수 있다. 수신환경 비교 시 품질의 저하의 비교 수치가 존재해야 하는데, 실시예들에 따른 @ComparisonBitRate, @ComparisonContentAttributeType 를 통해 service instance 간 bitrate 와 비디오 속성을 비교하여 service instance 의 전환 조건을 충족하는지를 비교한다. 예를 들어 현재 수신되고 있는 bitrate 가 MinimumBitrate ~ ComparisonBitRate 범위로 일정시간 @ComparisonBitratePeriod 을 넘기게 되면 전환하는 조건을 만족한다고 판단할 수 있다.
이 때 DVB-I phase 1 표준에 따라 기존의 priority 에 따라 접속했던 DVB-I client 에서 해당 instance 의 Dynamic switching을 허용한다면, 기존의 단말에 이슈가 발생할 수 있다. 예를 들어, DASH Representation 은 seamless 를 위해 가장 낮은 bitrate 의 영상 또한 MPD 내에 정의할 수 있기 때문에 수신bitrate 가 낮아 진다고 해서 service instance 를 전환하는 시나리오는 존재하지 않는다. 따라서 priority 를 가장 우선순위로 @ComparisonBitRate, @ComparisonContentAttributeType, @ComparisonBitratePeriod 조건을 확인하기 전에 DVB-I phase 1 수신기의 역 호환성을 지원하기 위해 service instance 는 Dynamic switching 이 가능여부를 확인해야 하므로, @Dynamic_switching Bool type 의 확장이 필요하다.
도52는 실시예들에 따른 서비스 인스턴스 스위칭 예시이다.
도52 의 경우 “아) UHD 지원 콘텐츠의 경우, 유효 네트워크의 bitrate 의 따라 가장 우수한 조건의 service instance 로 전환할 수 있다.” 와 “자) 단말 제조사와 서비스 업체와 특정 비즈니스 logic에 따라 5G aware App 의 접속 우선 순위를 지정할 수 있다.” 의 use case 에서는 다음과 같은 조건을 만들 수 있다.
도53은 실시예들에 따른 5GBC instance 및 OTT instance를 나타낸다.
사용자의 UHD 콘텐츠 play out 의 선택에 따른 요구사항이나, 특정 비즈니스 로직에 따라 UHD 재생을 지원이 필요한 use case 에서는 HD 를 기본으로 지원하는 5GBC 에서 OTT 로 전환 될 수 있다. 확장한 @ComparisonContentAttributeType 에서 하기와 같이 정의된다면, UHD 가 가능한 OTT 의 service instance 로 전환하여 UHD 서비스를 제공할 수 있다.
실시예들에 따라, OTT에서 일정기간 저품질 미디어 데이터를 수신하는 경우 고품질 5G 망전환을 수행할 수 있다. 예를 들어, 5GBC 는 프리-투-에어(free-to-air)이고 데이터를 사용하지 않고 수신될 수 있다. 사용자 의지에 따라, 수신이 가능하다.
또한, 5GBC 커버리지(coverage)를 벗어난 경우 데이터를 사용하는 망으로 자동으로 폴백(fallback)될 수 있다. 이는 사용자 의지가 아닐 수 있다.
망 전환 시 고품질/저품질에 제한되지 않고, 다양한 옵션을 지원할 수 있다. 즉, 사용자 의지 뿐만 아니라, 사용자 의지와 무관한 환경 변화에 따른 망전환도 처리가 가능하다.
나아가, 5GMS/ 5GBC / LTE / wifi / 로컬 홈 미디어 라우터(local home media router) 등 가능한 네트워크에서의 전환 시 실시예들에 따른 방법으로 폴백(fallback)을 할 수 있다.
도54는 실시예들에 따른 비디오 어트리뷰트 타입 시그널링을 나타낸다.
도26 등 실시예들에 따른 장치는 DVB-I SERVICE 접근을 위한 HDR/HFR 시그널링을 할 수 있다.
도26 등의 DVB-I client 는 DVB-I service selection UI와 content guide UI를 구성하여 User 에게 서비스 또는 다운로드 접근 가능여부를 표현해야 한다. 또한 User 가 접근해서 서비스 접근과 다운로드를 해야 하는 killer characteristic 정보를 구성해야 하며 그 정보가 User 선택의 기준이 될 수 있다.
현재 DVB-I 표준 기술 내에서는 <ContentAttributesType> 값으로 하기와 같이 표현하지만, 해당 정보는 codec 과 같은 decoder capability 관점의 필수 정보이지, User 가 richmedia 서비스를 수신 받기 위한 Service UI 측면의 정보로서는 부족하다. 따라서 video characteristic 정보, HDR/HFR/NGA 의 정보들을 표현하는 것이 DVB-I 서비스 관점 및 User 에게 보여지는 UI/UX 상 서비스 선택에 따라 중요하게 간주될 수 있다.
또한 도26과 같이 MPEG-DASH MPD 의 파싱은 Service 의 선택 이후에 이루어 지기 때문에 선택 이후 MPD 를 Parsing 하므로, 선택전에 MPD 정보를 얻을 수는 없다. 또한 모든 채널의 MPD 를 열어서 cache 하는 것은 채널수가 많아질수록 수신기 측면에 부하가 될 수 있다. 상기와 같은 이유로 서버 or 전송 측에서 Service UI 상에 해당 정보를 표시 할 수 있도록 표준을 확장해야 한다. 따라서 관련 정보를 확장하여 User 에게 서비스 선택의 기준을 명확하게 하고, 수신기 측면에서도 서비스 필터링을 수행을 통해 명확한 정보를 UI에 표시할 수 있다.
도26의 구성요소는 다음과 같다.
소스 선택 UI 제어부: DVB-I 클라이언트를 호스팅하는 장치에는 일반적으로 사용자가 하나 이상의 입력, 소스 또는 앱 중에서 선택할 수 있도록 하는 일종의 UI가 있다. 장치는 둘 이상의 DVB-I 클라이언트(예: 여러 앱)를 지원할 수 있다. 단일 DVB-I 클라이언트는 이 UI에서 둘 이상의 입력 또는 소스로 나타날 수 있다(예: 다른 브랜드 및 다른 서비스 목록 표시). 일부 입력 또는 소스는 DVB-I 채널을 DVB-C/S/T 채널 및/또는 IPTV 채널과 결합할 수 있다. 이것은 사용자가 HDMI 또는 DLNA 또는 글로벌 콘텐츠 공급자와 같이 DVB-I와 완전히 관련이 없는 입력 또는 소스를 선택할 수 있도록 하는 동일한 UI일 수 있다.
DVB-I 서비스 선택 UI 제어부: DVB-I 클라이언트는 사용자가 서비스 목록을 보고 선택/변경할 수 있는 UI를 포함할 수 있다. 일부 DVB-I 클라이언트 구현에는 이러한 UI가 포함되지 않을 수 있으며 하이브리드 서비스 선택 UI에 의존할 수 있다.
하이브리드 서비스 선택 UI 제어부: DVB-I 서비스는 (로컬 튜너 대신에 SAT>IP를 통한 DVB C/S/T 서비스들을 포함하는) DVB-C/S/T/IPTV 채널이 있는 단일 공통 서비스 선택 UI에 포함될 수 있다.
서비스 리스트 매니저: 서비스 목록 서버를 검색 및 쿼리하고 반환된 서비스 목록을 처리한다다(인터페이스 C1 및 C2). DVB-I 서비스가 선택되면 서비스 플레이어에게 서비스를 재생하도록 지시하는 역할을 한다.
DVB-C/S/T/IPTV 서비스 리스트 매니저: DVB-C/S/T 또는 IPTV 장치에서 서비스 목록을 가져와 선택될 때 해당 목록에서 서비스를 표시하는 기능을 수행한다. 포함될 수 있는 것의 몇 가지 예에는 RF 채널 스캔, "호밍 먹스(homing mux)" 튜닝, DVB-SI SDT 획득 또는 특정 IPTV 기술에서 사용하는 채널의 (독점) 목록 획득이 포함된다. 여기에는 SAT>IP를 통해 사용 가능한 DVB-C/S/T 서비스가 포함될 수 있다.
DVB-I 컨텐츠 가이드 UI 제어부: DVB-I 클라이언트는 사용자가 서비스 선택 UI에 포함된 서비스의 컨텐츠에 대한 정보에 접근할 수 있도록 하는 UI를 포함할 수 있다. 일부 DVB-I 클라이언트 구현에는 이러한 UI가 포함되지 않을 수 있으며 하이브리드 콘텐츠 가이드 UI에 의존할 수 있다.
하이브리드 콘텐츠 가이드 UI 제어부: DVB-I 서비스에서 전달되는 콘텐츠에 대한 정보는 DVB-C/S/T/IPTV 채널(로컬 튜너 대신 SAT>IP를 통해 액세스하는 DVB-C/S/T 서비스들을 잠재적으로 포함)에서 전달되는 콘텐츠에 대한 정보와 함께 단일 공통 콘텐츠 가이드 UI에 포함될 수 있다.
콘텐츠 가이드 매니저: 콘텐츠 가이드 서버에 액세스하고 반환된 콘텐츠 가이드 데이터를 처리한다(인터페이스 A1 및 A2). 콘텐츠 가이드 데이터가 방송 장치에 캐시되는 것과 동일한 방식으로 이것이 DVB-I 클라이언트에 콘텐츠 가이드 데이터를 캐시한다는 가정은 없다. 이 기능은 별도의 구성 요소 없이 DVB-I 콘텐츠 가이드 UI(또는 하이브리드 콘텐츠 가이드 UI)에 완전히 통합될 수 있다.
DVB-C/S/T/IPTV 콘텐츠 가이드 매니저: DVB-C/S/T 또는 IPTV 채널에 대한 콘텐츠 가이드 데이터를 얻고 캐시하는 DVB-C/S/T 또는 IPTV 장치의 기능입니다.
광대역 서비스 플레이어: 광대역 네트워크에서 제공되는 서비스 재생의 전체 수명 주기를 담당한다. DVB-DASH 플레이어, 보조 OTT 플레이어 및 연결된 응용 프로그램 관리자를 적절하게 제어한다. 미디어 콘텐츠가 재생 목록으로 설명되는 서비스의 경우 재생 목록 처리를 담당한다.
광대역 서비스 재생 UI 제어부: 광대역 제공 서비스를 재생하려면 타임시프트 버퍼 내에서 재생 제어, 오디오 트랙 선택, 자막 제어 및 보호자 액세스 제어와 같은 기능을 위한 일종의 UI가 필요하다. 또한 DVB-DASH 플레이어의 상태/응답 코드를 표시하는 데 사용할 수도 있다. 브로드캐스트 서비스의 경우 일반적으로 이미 존재하므로 DVB-I 클라이언트의 범위를 벗어난다. DVB-DASH 서비스의 경우 이것은 DVB-DASH 플레이어 또는 DVB-I 클라이언트의 일부일 수 있다. 이 중 후자가 여기에 표시된다.
하이브리드 DVB-I 클라이언트의 경우 DVB-DASH 서비스 표시/재생과 관련된 UI 및 방송 서비스 표시/재생과 관련된 UI에 동일한 모양과 느낌이 사용되면 더 나은 사용자 경험을 얻을 수 있다. 이론상 동일한 UI 구현을 사용하는 것이 가능하지만 실제로는 비현실적으로 복잡할 수 있다. 또는 광대역 서비스 재생 UI는 방송 서비스가 제공될 때 사용되는 동등한 UI의 모양과 느낌을 복사할 수 있다.
DVB-DASH 플레이어: 콘텐츠가 DVB DASH에 의해 전달되는 DVB-I 서비스를 재생하는 역할을 한다. 이것은 인터페이스 D1, D2, E1, E2를 사용할 수 있다.
보조 OTT 플레이어: DVB-I 서비스 목록에는 DVB-DASH 이외의 수단을 통해 OTT로 사용 가능한 (또한) 콘텐츠에 대한 참조가 포함될 수 있다. DVB-I 클라이언트는 비 DVB-DASH OTT 콘텐츠에 대해 플레이어와 인터페이스할 수 있다.
DVB-C/S/T/IPTV "튜너": 선택한 경우 DVB-C/S/T/IPTV 서비스를 재생하는 역할을 한다. 여기에는 로컬 튜너 대신 SAT>IP를 통해 액세스되는 DVB-C/S/T 서비스가 포함될 수 있다.
연결된 응용 프로그램 관리자: 서비스에 연결된 응용 프로그램이 포함되어 있는 경우 이는 응용 프로그램의 버전이 표시될 수 있는지 식별하고 표시될 수 있는 경우 적절한 엔진과 연결하여 프레젠테이션을 수행하는 역할을 한다. 일부 서비스의 경우 서비스의 비디오 및 오디오가 표시되기 전에 연결된 응용 프로그램을 시작해야 할 수 있다.
연결된 응용 프로그램 엔진: 제공되는 서비스에 연결된 응용 프로그램을 실행하는 역할을 한다. 예를 들어, TV 세트의 HbbTV 엔진이나 전화, 태블릿 또는 PC의 HTML5 웹 보기가 있다.
실시예들에 따른 방법/장치가 처리하는 미디어 데이터의 Video 정보 내 HDR 정보가 포함될 경우 video characteristic 정보를 signaling 하기 위한 3가지 element 를 포함하고, 각 element 에 대응하는 value 값을 정의해야 한다. DVB-I client 는 해당 정보를 service level 에서 해석하여 해당 서비스가 HDR 임을 서비스/콘텐츠 가이드에 표시할 수 있다.
예를 들어, 실시예들에 따른 DVB-I 서비스 스키마, 서비스 인스턴스, MPD를 통해서 도54의 정보를 전달할 수 있다. 컬러 특성(clour_primaires), 변환 정보(transfer_chreacteristics), 매트릭스 계수 정보(matrix_coeffs), 대안 변환 SEI 정보(alternative_transfer_characteristics SEI message)를 Essential Property 및/또는 Supplemental Propery를 통해서 전달할 수 있다.
예를 들어, 수신 장치는 비디오 특성 정보를 수신하고, 값(@value)가 9인 경우 컬러가 BT.2020인 것을 알 수 있고, @value가 14인 경우 변환이 SDR로 수행된 것을 알 수 있다.
도55는 실시예들에 따른 HFR(high frame rate) 예시를 나타낸다.
High Frame Rate 의 의미는 50, 60 Hz 의 doubling rate 인 100, 120 Hz 를 HFR 이라고 하고, HFR playable 가능여부에 따라 User 에게 HFR 서비스를 콘텐츠/서비스 가이드에 표시한다. 따라서 DVB-I client 가 수신되는 서비스가 HFR 서비스 일 경우 해당 정보의 indication 확장이 필요하다. HFR 의 스트림 구조는 Complete Single layer 로 구성된 HFR(5500), sub-layer 를 통한 Temporal layer 를 구성하는 HFR (5501)로 구성한다. 또한, sub layer 만 선택적으로 낮은 프레임 레이트만을 재생하거나, 모든 layer를 재생하여 high frame rate를 재생한다.
예를 들어, 50fps를 가지는 레이어 및 100fps 를 가지는 레이어를 선택적으로 재생하거나, 모두 재생할 수 있다. 복수의 레이어들을 가지는 비디오를 인코딩할 수 있다.
DASH 에서는 해당 스트림이 어떤 구조의 Temporal layering 이 되어 있는지 Temporal ID 를 통해 나타내고, 재생 가능한 Framerate 의 Representation 을 선택하여 다운로드 받아서 재생한다. 비디오 de-packager / NAL decoder 에서는 temporal layer 의 정보를 통해 재생 가능한 또는 필요한 프레임 레이트를 생성하기 위해 조합하거나 버릴 수 있다. 이러한 DASH 의 HTTP 구조에 따라 가장 높은 temporal ID (Highest Temporal ID) 를 시그널링하여 Temporal layer scalability 에 따라 HFR 의 재생을 결정한다.
도56은 실시예들에 따른 HDR/HFR 특성을 위한 서비스 리스트 구성을 나타낸다.
도56의 서비스 리스트는 도49, 39, 28, 24, 19, 11 등에 대응할 수 있다.
즉, DVB-I service hierarchy는 확장될 수 있다. 실시예들에 따른 송신 장치는 DVB-I service를 위한 정보를 생성하고 전송할 수 있고, 실시예들에 따른 수신 장치는 서비스 리스ㅡㅌ 정보에 기반하여 HDR, HFR 등의 서비스를 사용자에게 제공할 수 있다. 효율적인 서비스 엑세스를 시그널링할 수 있는 효과가 있다.
도57은 실시예들에 따른 비디오 속성을 시그널링하는 예시를 나타낸다.
도57과 같이 실시예들에 따른 ContentAttributesType의 현재 DVB-I 정의를 변경하여 로컬로 정의된 VideoAttributesType을 사용할 수 있다.
비디오 속성(VideoAttributes): 서비스의 비디오 속성을 나타낸다.
컬러 스페이스(ColourSpace(color Primaries)): 적합성 포인트를 기반으로 서비스 UI/UX를 렌더링하기 위한 비디오 색 공간의 특정 정보를 나타낸다.
변환 특성(transfer_characteristics): 적합점을 기반으로 서비스 UI/UX를 렌더링하기 위한 전송 특성의 특정 정보를 나타낸다.
매트릭스 계수(matrix_coeffs): 적합성 기준에 따라 서비스 UI/UX를 렌더링하기 위한 matrix_coeffient의 특정 정보를 나타낸다.
높은 임시 아이디(HighestTemporalID): 영상의 특정 정보 Conformance Point를 기반으로 서비스 UI/UX를 렌더링하기 위한 HighestTemporalID 정보를 나타낸다. VideoConformancePoint 서비스에서 사용할 수 있는 비디오 형식을 나타내는 ETSI TS 101 154 [22]에 정의된 urn:dvb:metadata:cs:VideoConformancePointsCS:20172을 따를 수 있다.
도58은 실시예들에 따른 멀티-뷰 전송 과정을 나타낸다.
실시예들에 따른 방법/장치는 User preference 를 반영한 Multi-viewport 를 제공할 수 있다.
DVB-I 는 기존의 방송망과 IP 망이 모두 또는 선택에 따라 수신이 가능한 connected TV 를 지원하고 있다. 이 DVB-I 는 Service 내에 여러 스트림을 전송 가능하여 모드에 따라 다른 viewport 를 제공하여 개인화된 서비스를 제공할 수 있다. 예를 들어, 축구경기에서 다른 팀을 응원하는 두 사람이 각각의 선호하는 팀을 기준으로 화면을 선택하여 시청할 수 있는 기능을 제공할 수 있다. 각 Scene 별로 독립적인 viewport 로 4개의 비디오를 인코딩하고 인코딩된 비디오를 하나의 pipeline 으로 출력시키면, 수신기에서는 하나의 video pipeline 에서 디코딩 된 4개의 viewport 에서 사용자의 선택에 따라 특정 화면을 구성할 수 있다.
예를 들어, 실시예들에 따른 프로덕션 단계는 게임1에 대한 비디오 시그널, 게임2에 대한 비디오 시그널, 카메라1에 대한 비디오 시그널, 카메라2에 대한 비디오 시그널, 카메라N에 대한 비디오 시그널을 생성할 수 있다. 복수의 비디오 시그널들은 서로 독립된 멀티 뷰포트들에 대한 비디오 데이터를 포함할 수 있다.
실시예들에 따른 트랜스미션 단계는 복수의 비디오 시그널들을 하나의 파이프 라인에 기반하여 하나의 데이터 포맷으로 인캡슐레이션하고 인코딩하여 전송할 수 있다.
실시예들에 따른 디코딩 및 렌더링 단계는 복수의 비디오 시그널들을 수신하고, 사용자의 선택에 기초하여, 선택된 비디오 시그널을 디코딩하고 렌더링할 수 있다. N개의 비디오 시그널 중 선택된 비디오를 부분적으로 사용자에게 효율적으로 제공할 수 있다.
multi-view 비디오 인코딩은 MPEG VVC 내에 비디오 인코딩 tool 중, Subpicture 을 지원하는 기능을 통해 전송가능하며, MPEG VVC 는 독립적인 viewport 의 인코딩 알고리즘 및 관련 파라메타를 정의하고 있다. 예를 들어, 이때 4개의 화면은 MPEG VVC 인코딩을 통해 8k 해상도에 4개의 4k 동기된 이미지를 제공하고, 각 Scene 별로 취사 선택에 따라 DVB-I 내에서 User personalization 의 기능을 제공 할 수 있다.
도59는 실시예들에 따른 비디오 데이터 분할 단위를 나타낸다.
실시예들에 따른 방법/장치는 MPEG VVC subpicture 에 따라 비디오 데이터를 처리할 수 있다.
실시예들은 MPEG 내 비디오 압축 표준인 VVC 의 sub-picture 의 구조에 따라 미디어 데이터를 처리할 수 있다.
타일(tile)은 MPEG 에서 이미지 내 특정 영역을 나누고, 그 영역을 부호화, 복호화의 병렬처리를 위해 tile 이라는 단위를 정의하고 있다. tile의 set 은 독립적인 공간적 예측과 엔트로피 코딩을 적용하는 단위로, 시간적 공간적 독립성을 가지고 인코딩이 가능하며, tile set 안에서 부호화 및 독립된 sequence 의 NAL unit 으로 출력처리가 가능하다. 예를 들어, 360 비디오를 인코딩 및 스트리밍 할 때 비디오 전체를 복호화 하기에는 대역폭의 한계와 낭비가 있어, 실제 사용자 viewport 에 맞도록 해당 영역만 선택 디코딩 및 랜더링 처리하는 것이 효율적이다.
예를 들어, 시장 공간 시퀀스를 나타내는 제1프레임이 있는 경우, 이 프레임은 1920*1080 해상도 픽쳐이고 이 픽쳐는 135 CTU(coding tree unit)들로 구성될 수 있다. 이 픽쳐는 3개의 타일 컬럼들 및 3개의 타일 로우들을 가지는 9타일들로 구성될 수 있다.
하나의 타일을 예로 들어 설명하면, 하나의 타일은 코딩 트리 단위인 복수의 CTU들로 구성될 수 있다.
MPEG VVC 는 이러한 직사각형 타일을 논의하면서, 더 유연한 CVS (Coded Video Sequence) 를 제공하기 위해 새로운 분할 구조로 Sub-picture 를 제안하였다. Subpicture 의 개념이란, 이미지 내에 하나 이상의 subpicture 를 구성 할 수 있고, 하나의 Sub-picture 는 하나 이상의 직사각형을 구성되는 Rectangular mode slice 로 구성될 수 있다. 여기서 Slice 는 NAL unit 단위로 encap 하게 되는 단위로 각각의 subpicture 는 하나 이상의 slice 로 구성할 수 있다.
도60은 실시예들에 따른 서브 픽쳐 분할을 나타낸다.
실시예들에 따른 방법/장치는 비트 스트림의 내에 특정 부분(subpicture)으로 병합하여 타일단위의 복호화와 비트스트림을 추출할 수 있고, 영상 안의 슬라이스(slice), 타일(tile), 브릭(brick), 서브 픽처(subpicture)는 각각의 다른 슬라이스, 타일, 브릭, 서브픽처들로부터 복호화 의존성이 없으며, 비교적 단순한 분할 구조를 가질 수 있다.
이와 같이 하나의 이미지 내 어려개의 subpicture 를 포함하면, 각 subpicture 구성정보는 SPS 내에 아래와 같이 파라메터화 하여 전송된다.
예를 들어, 실시예들에 따른 방법/장치는 영상(픽쳐)을 수신하고, 2개의 슬라이들로 분할할 수 있다. 슬라이스1 데이터 및 슬라이스 2데이터를 각각 인캡슐레이팅하고, 비트스트림으로 각각 전송할 수 있다. 비트스트림은 NAL유닛으로 구성되고, 헤더 및 페이로드를 포함할 수 있다. 페이로드는 RBSP를 포함할 수 있다. 래스터 스캔 순서로 슬라이스를 구성할 수 있다.
또한, 실시예들에 따른 방법/장치는 영상(픽쳐)를 수신하고, 3개의 슬라이스들로 분할할 수 있다. 각 슬라이스를 각 NAL유닛 단위 싱글 스트림으로 전송할 수 있다. 사각형 모형으로 슬라이스를 구성할 수 있다.
이와 같이 하나의 픽쳐가 서브-픽쳐들로 분할되고 각 서브-픽쳐 별로 인캡슐레이팅되어 송수신될 수 있다.
도61은 실시예들에 따른 서브 픽쳐에 관한 시그널링 정보를 나타낸다.
실시예들에 따른 방법/장치는 미디어 데이터 및 미디어 데이터에 관한 시그널링 정보를 포함하는 비트스트림을 전송할 수 있다. 시그널링 정보는 메타데이터, 파라미터 등으로 지칭될 수 있다. 시퀀스 레벨의 시그널링 정보인 시퀀스 파라미터 세트에 서브 픽쳐에 관한 정보를 포함시킬 수 있다.
서브 픽쳐의 포지션을 나타내는 정보(left x, left y, width, height) 정보가 서브 픽쳐 개수 별로 생성될 수 있다. 서브 픽쳐를 식별하기 위한 식별 정보(id)가 추가로 파라미터 세트에 포함될 수 있다.
DVB-I 기반 MPEG VVC Sub-picture 들을 rendering 하기 위한 한계점
현재 DVB-I 표준에서는 IP 기반 Service 를 송수신하기 위해, 특정 서비스 제공자의 entry point 들에 접근하는 DVB-I bootstrapping방법과 서비스 리스트를 획득하여 서비스들을 discovery 하는 방법, 각 서비스들의 구성정보와 AV 속성정보와 각 파라메터들을 정의하고 있다.
User personalization 을 DVB-I 를 통해서 제공하기 위해서는 하기와 같은 요구사항이 필요하며, 현재 DVB-I 표준에서 지원하기 어려운 기술적 구성의 한계를 해결하기 위한 솔루션을 작성하고자 한다.
<현재 MPEG VVC 에서 정의한 subpicture 의 속성>
도61은 subpicture 의 위치를 나타내는 좌표/크기이나, 비디오 인코딩 과정에서 필요한 CTU 레벨의 컨트롤을 위한 부가정보이거나 코덱 관점에 위치 정보일 뿐 랜더링을 위한 특정 좌표나 픽셀위치를 의미하지는 않는다. 즉, Codec 내에서는 rendering position에 대한 information 은 특별하게 정의하지 않는다.
예를 들어, VR 영상(360-degree)에서 subpicture를 기반으로 view point를 표현한다면, 해당 위치 정보는 렌더링 위치 정보가 될 수 있으나, viewport 가 ROI 에 따라서 변경된다면, 해당 좌표는 rendering 이나 displaying 하는 좌표에 일치하지 않는다. 즉, rendering position description 의 정보는 system layer 에서 application 이나 use case 에 따라 rendering 환경을 만들 수 있다. 따라서 DVB-I application 에서는 해당 subpicture 정보들을 rendering 할 수 있는 scene description 정의가 필요하다.
<scene description 을 정의하는 기술>
scene description 은 (1) HTML/MMT CI, (2) HTML/Javascript 등이 대표적이다. (1) 의 경우, HTML DOM(Document Object Model) 형태로 저장된 구조에 MMT CI description 이 영역 및 공간의 위치를 동적으로 변경하고 업데이트 할 수 있다.
(2) 의 경우, HTML 의 DOM 구조에 특정 식별자와 특정 패턴을 사용하여 참조한 JS command 를 통해 화면을 업데이트하고 동적으로 표현할 수 있다. 두가지 모두 HTML cache data 가 기본 틀로 제공되고 동적인 scene description 을 만드는 형태로 rendering 위치 정보들 구성할 수 있다.
(1), (2) 의 기술로 DVB-I 서비스 내 user personalization 을 지원하기 위해서는 한계점이 존재한다. DVB-I Service 는 기본적으로 기존의 DVB-T/S/C 망과 IP 를 통한 DVB 서비스를 동시에 제공할 수 있다. 특히 TV implementation 의 기본적인 전제는 HTML page 를 기본으로 하는 web 구성이나, 특정 OS 에 dependency 가 있는 application 의 동작과는 다르게, native 환경을 전제로 하고 있어 HTML 의 적용이 어렵다. 또한 모든 rendering 환경을 만족시키기 위해서는 HTML 의 구조보다, common 한 rendering 위치정보와 관련 reference 정보를 제공하는 것이 합리적이다. 따라서 이러한 서비스를 지원하기 위해서는 렌더링 될 화면 layout 에 absolute position 을 기본으로 VVC 비디오가 포함하고 있는 subpicture 들의 정보를 참조함으로서 scene description 을 구성할 수 있다.
도62는 실시예들에 따른 서브 픽쳐 렌더링을 나타낸다.
실시예들에 따른 방법/장치는 VVC 인코딩 기반 subpicture 들을 display 하고 rendering할 수 있다. 이를 위해서 실시예들에 따른 rendering information 이 필요하다. render position information을 system level에서 정의할 수 있다.
이를 통해 DVB-I 기반 사용자 개인화(User personalization)를 지원할 수 있다.
subpicture 4개가 인코딩 된 ES 가 인코더에서 출력되면, ES 는 File format 내 sample group entry 를 통해 subpicture 단위로 encapsulation 되고, 각 sample group 은 VVC 비디오의 coded metadata (VPS, SPS, PPS) 들의 참조정보를 File format 내에서도 reference 할 수 있다. 따라서 수신 측에서는 DVB-I discovery 를 시작으로 획득한 MPD 와 segment reception 을 완료하면, File format 내에 ES 내 subpicture 의 reference 정보를 확인할 수 있다.
복수의 독립적인 비디오 시그널들을 하나의 파이프 라인에서 인코딩하고 인캡슐레이팅하여, 전송하는 경우, 수신장치는 DVB-SI정보를 파싱하고, 비디오들이 포함된 TS패밋들을 디멀티플렑싱하고 PES스트림을 디캡슐레이팅해야 한다. 비디오 스트림에 서브 픽쳐들이 4개가 포함되어 있는 경우, 4개의 서브 픽쳐들을 렌더링해야 하므로, 렌더링 구성을 위한 시그널링 정보가 필요하다.
따라서, DVB-I 디스커버리를 위한 렌더링 정보를 추가로 생성하여 전송할 수 있다. 복수의 비디오들은 세그먼트 단위로 샘플 그룹핑되고, 서로 참조 관계가 표시될 수 있다. 수신 장치는 디스커버리 과정을 통해 렌더일 정보를 MPD등을 통해 미리 획득하여, 세그먼트를 디멀티플렉싱하여 복수의 비디오들을 렌더링하여 멀티-씬을 제공할 수 있다.
도63은 실시예들에 따른 메인 장면 구성을 나타낸다.
실시예들에 따른 수신 방법/장치는 도63과 같이, display 에 rendering 을 위한 scene composition을 제공할 수 있다.
지원하고자 하는 main scene composition 은 display 가 8k 라는 가정하에, 전체 8k (7680x4320) 의 해상도에서 4k 의 4개의 subpicture 로 독립적으로 인코딩 된 스트림을 구성할 수 있다. 각 subpicture 들은 왼쪽의 끝에 (0,0) 을 기준으로 Area1~4까지 구성할 수 있다. 실시예들에 따른 scene composition 의 기준으로 정보를 수신하여 처리하면 사용자는 8k 화면 내에 4개의 4k viewport 를 보고 원하는 scene을 선택하여, 4k 의 비디오를 소비할 수 있다.
해당 좌표는, 좌측 상단을 시작으로 Area1~4 가 아래와 같이 position 을 지정할 수 있다.
Area 1: <AbsolutePosition left = 0, top = 0; width=3840px; height=2160px/>
Area 2: <AbsolutePosition left = 3840, top = 0; width=3840px; height=2160px/>
Area 3: <AbsolutePosition left = 0, top = 2160; width=3840px; height=2160px/>
Area 3: <AbsolutePosition left = 3840, top = 2160; width=3840px; height=2160px/>
영역1에 비디오1, 영역2에 비디오2, 영역3에 비디오3, 영역4에 비디오4를 배치하기 위해서, 포지션 정보를 포함하는 렌더링 정보를 생성하여 수신 측에 전달할 수 있다. 즉, 복수의 서브픽쳐들에 대한 렌더링 좌표, 렌더링 위치 정보 등을 전달함으로써, 멀티-씬을 사용자를 위해 제공할 수 있고, 사용자는 구성된 멀티-씬을 보고, 선택적으로 씬을 시청할 수 있다.
도64는 실시예들에 따른 서브 픽쳐 간 참조관계를 나타낸다.
실시예들에 따른 방법/장치는 VVC coded Video 내 subpicture 들을 reference 관계를 나타낼 수 있다.
VVC coded Video ES 내 subpicture 의 정보에 접근하기 위해서는 비디오 High level syntax 에 접근해야 하데, High level syntax 의 구성은 도64와 같이 구성될 수 있다. VVC video ES 내 subpicture 에 접근하기 위해서는 VPS, SPS 에 접근해야 Subpicture 로 구성된 정보에 접근이 가능하다. Parallel 한 Subpicture sequence 들에 접근하기 위해서는, (1) VPS id, (2) SPS id (3) PPS id(optional) 가 scene description 내에 Area 정보와 연결되어야 한다. 또한 해당 use case 를 지원하기 위해서는 시스템 단계에서 scene description 정보가 정의되야 하므로, 관련 hierarchy 에 맞추어 시스템 정보와도 적절한 참조관계를 생성할 수 있다.
예를 들어, 실시예들에 따른 비트스트림을 VPS, SPS, PPS등과 같은 파라미터 세트들을 포함하고, 슬라이스 단위 별로 슬라이스 헤더, 슬라이스 데이터(페이로드)가 비트스트림에 포함될 수 있다. 파라미터 세트들에 포함된 id 는 영역1, 영역 2등에 대응할 수 있다. 영역1을 렌더링하기 위해서는 씬 디스크립션에 포함된 렌더링 정보를 획득할 수 있다. 복수의 픽쳐, 복수의 서브 픽쳐 간 Id, 영역, 씬 디스크립션 정보를 통해 상호 참조관계를 지시할 수 있다.
도65는 실시예들에 따른 씬 디스크립션을 나타낸다.
씬 디스크립션은 그룹 id 별로 씬에 관한 정보를 전달할 수 있다. 뷰 id는 서브 픽쳐를 포함하는 샘플 그룹에 대응할 수 있다. 뷰 id에 따라서, 위치, MPD id, Representation id, VPS, SPS, subpicture id, multi-view중 main view를 전달할 수 있다.
복수의 픽쳐들, 서브 픽쳐들 간 참조 관계를 수신 장치가 획득할 수 있도록, 씬 디스크립션은 id 정보를 이용하여 참조관계를 나타낼 수 있다.
도66은 실시예들에 따른 씬 디스크립션 기반 수신 장치를 나타낸다.
Scene description 이 System layer 에서 포함될 수 있는 방법은 총 2가지로, DVB-I service list 서비스의 구체적인 Video 특성을 정의하는 위치에 포함되거나, DASH MPD 내에 segment 및 video 특성을 정의 가능한 곳에 확장할 수 있다.
실시예1 DVB-I service list 내 확장 안: DVB-I 내 scene description 을 확장하고, Service instance 내에 video 속성을 정의하고, Service instance 에서 DASH MPD 를 획득하고, MPD 내 scene description 을 확장하고, segment 내 sample group entry 에 접근하는 방법으로 subpicture set 을 획득할 수 있다. DVB-I service initial 과정을 거치고, 각 서비스 별로 filter out 된 서비스 관련 정보와 각 service instance 에 맞는 재생 환경을 초기화 한다. 이 과정에서 확장된 scene description 이 포함되면, 해당 정보를 통해 DASH engine 내에 File 내의 sample/subpictures entry 에 접근하여 display 에 각 view 에 맞게 subpicture 의 rendering 을 수행할 수 있다.
실시예2는 MPD 를 확장하여 MPD 내 씬 디스크립션을 포함시킬 수 있다. 상세 내용은 후술한다.
도67은 실시예들에 따른 씬 디스크립션 전달 신택스를 나타낸다.
실시예들에 따른 User personalization 을 수행하기 위한 DVB-I scheme은 다음과 같다.
DVB-I 서비스 스키마 hierarchy내 content attribute 에서는 filter out 된 서비스에서 delivery method 에 따라 발생하는 service instance 별 Video / Audio 속성을 정의할 수 있다. VideoAttribute 는 video characteristic/color/size/framerate/pictureformat 등을 정의하고 있다. 실시예들은 service instance 에 포함된 video stream 의 subpicture 에 대한 rendering 속성을 확장하는 접근은 VideoAttributesType 의 확장을 통해 구성이 가능하다.
도68은 실시예들에 따른 씬 디스크립션을 포함하는 DVB-I 서비스 리스트를 나타낸다.
도67의 옵션 1은 GroupID(subpicture 여러 개를 grouping 한 layer 에서의 ID 값)를 통해 서브 픽쳐들을 포함하는 그룹에 접근하는 방법을 나타낸다.
또한, 위치정보(AbsolutePosition)를 생성하여 display 내 왼쪽 상단 픽셀을 기준으로 각 view 가 위치해야 할 pixel 값을 나타낼 수 있다.
또한, 메인뷰(Mainview)를 통해 4개의 화면을 지원하지 않는 TV 의 경우, 4k 하나의 subpicture 만 재생해야 할 때 지정되어야 할 default viewport를 멀티 뷰 중에 지정할 수 있다.
도67의 옵션 2는 Option 1의 SceneDescription 를 요청 및 수신할 수 있는 별도의 XML location 을 정의하고, XML 를 다운로드 받을 수 있는 contenttype = application/xml 형태로 정의한다. SceneDescriptionLocaton : SceneDescription 를 요청 및 수신할 수 있는 별도의 XML location 을 정의한다.
도67의 옵션 3은 Compositioninformation 의 정의를 DASH layer 에서 하고 있다는 bool 함수이고, 해당 정보를 통해 DVB-I service layer 에서는 User personalization 을 제공한다는 notification 을 제공하고 실제 scene description 데이터를 DASH MPD 내에서 다운로드 받을 수 있다.
도69는실시예들에 따른 MPD의 씬 디스크립션을 나타낸다.
Service instance 에서 DASH MPD 를 획득하고, MPD 내 scene description 을 확장하고, segment 내 sample group entry 에 접근하는 방법은 다음과 같다. DASH MPD hierarchy 의 Adaptation-set / representation base 에서 <common attributes and elements> 의 확장 element 또는 SupplementalProperty 형태로 확장 가능하다. 각 semantics 는 DVB-I 내에 확장한 scene description 확장 내용과 동일하다.
도70은 실시예들에 따른 DVB-I 서비스 리스트 내 씬 디스크립션의 신택스를 나타낸다.
실시예들에 따른 방법/장치는 code 와 같이 DVB-I 내 scene description 을 통해, 8k 의 화면에 총 4개(4k, 4개)의 subpicture 를 표준 position 에 부합하도록 픽셀 절대값에 기반하여 구성할 수 있다. 각 구성한 view 에 따라서 실제 비디오 스트림 내에 포함되어야 할 reference 정보들을 참조하여 4개의 분할된 화면에 rendering 을 할 수 있다. 각 view 에 따른 scene description 정보를 segment file 내 sample entry 에 접근하고, 각 entry 별 parallel 한 decoding 과정이 끝나면, renderer 는 scene description 기반한 view 별 absolute position 에 따라 pixel allocation 을 한다. 각 view 별 area 에 따라 decoding 된 결과가 rendering 및 display 될 수 있다.
구체적인 use case 로는 다음과 같다. 구체적인 use case 로는 일정시간이 지나면, <mainview> 에서 정의한 view ID 만이 4k 로 선택되어 선택 디코딩 및 전체화면으로 rendering 이 될 수 있다. 사용자가 특정 화면을 선택하면 선택된 area 의 view ID 를 선택 디코딩 및 전체화면으로 rendering 이 될 수 있다.
도71은 실시예들에 따른 하이브리드 서비스 시나리오를 나타낸다.
실시예들에 따른 장치인 DVB-I CLIENT는 DELIVERY METHOD 에 따른 SERVICE LIST 를 수신하기 위한 실시예들에 따른 DISCOVERY 방법을 수행할 수 있다( DVB-I 표준 기반 hybrid service scenario)
실시예들에 따른 DVB-I 스킴은 broadcaster 가 T, S, C 채널과 동시에 Internet channel 로 서비스를 전송할 수 있다. 서비스와 사업자, DVB-I 서비스 수신 가능한 device 제조사가 regulation 을 통해 서비스 채널의 대한 authentication 을 획득하고 기존 linear 서비스와 채널 aggregator 를 통해 인터넷 채널을 제공 할 수 있다. 대표적 use case 는 도71과 같다.
서비스는 DVB-S 서비스를 DASH instance 와 DVB-S 지원 STB 를 통해 제공할 수 있다. DVB-I client 는 Priority 를 통해 instance 의 선택이 가능하고, 선택에 따라 동일한 서비스를 IP or 위성을 통해 서비스를 받을 수 있다.
DVB-I 는 이러한 서비스를 지원하기 위해 설치된 위성 STB / RF 수신기 / cable STB 등을 미리 설치하고 DVB-I 서비스 리스트를 받아서 DVB-I hybrid 서비스 환경을 구축 할 수 있다. DVB-I mobile 의 경우, only-IP 환경이므로, 서비스 리스트를 수신 받아 IP 를 통해 수신 가능한 instance 를 선택하게 할 수 있다.
한편, 실시예들에 따른DVB-I service scheme 를 사용하여, Regionalization 을 지원하기 위해 Target region / postcode / Region ID / LCN mapping 등의 정보를 통해 client 는 수신 받고 있는 지역 서비스에 대해서 필터링된 서비스를 선별적으로 수신할 수 있다.
도72는 실시예들에 따른 DVB-I 서비스 리스트 디스커버리 과정을 나타낸다.
도32의 B1, B2 인터페이스 discovery 과정과 F1, F2 인터페이스는 service list 획득 과정을 나타내고 있다. 관련 순서와 현 표준의 실시 예를 보면, 도72와 같다.
이러한 현재 서비스 scheme 구조는 service discovery 는 delivery method 에 구분 없이, 모든 서비스 리스트를 <ProviderOffering> 내에 검색하고 client 측의 특정 기준에 따라 선택 및 수신한다. 현재 scheme 에서는 서비스 리스트를 받은 후 수신하고 있는 위성 STB / RF 수신기 / cable STB 에 따라 구분하는 것이 아닌 특정 기준이 부재한 상태로 서비스 리스트를 수신하는 형태이다. 이러한 구조에서는 위성 STB 를 수신하고 있는 device 에서 지상파 리스트를 수신할 수도 있는 위험이 있다. 또한, DVB-I client 는 필터링의 load 가 있으므로, 한정적인 device capability 관점에서 무겁다는 단점이 있다.
이러한 언급한 문제점을 해결하기 위해, DVB-I service discovery 과정 중 Delivery method 에 따른 리스트 획득을 할 수 있도록 표준을 확장할 수 있다.
따라서, 수신 장치는 기설치된 delivery method 에 대응하는 서비스 엔트리들을 서버로부터 효율적으로 수신할 수 있다.
도73은 실시예들에 따른 DVB-I discovery 시 Delivery method 에 따른 DVB-I service list 획득 방법을 나타낸다.
도73 방법은 다음과 같은 효과를 제공할 수 있다. DVB-I client 가 서비스 리스트를 모두 받아서 방대한 자료를 client 에서 필터링 해야 하는 load를 서버로 이동시키고, DVB-I client 가 pre-install 된 수신 정보(기 설치된 delivery method/protocol)를 기반으로 관련 정보를 query 에 전달하고, 서버에서 필터링을 통해 delivery method 에 따른 적합한 리스트를 수신할 수 있다. 또한 DVB 망이 pre-install 되지 않는 IP-only device 지원을 위해, 서비스 리스트가 정의한 acceptable experience 정보의 적절한 순위에 따라서 리스트를 대응할 수 있다.
서비스 리스트 제공자는 다양한 delivery method 에 조합에 따라 리스트를 provisioning 할 것이고 user 에게 서비스의 하이브리드 서비스나 acceptable experience 를 제공하는지 여부와 다양한 capabilities 를 가진 DVB-I client 에 부합 및 표시 여부를 나타낼 수 있는 정보를 제공해야 한다.
구체적인 실시 예는 하기 그림 40과 같이 DVB-I client 의 요청과 부합하는 service list entry point 획득과정에서 확인할 수 있다. delivery method 에 정의된 정보에 따라 DVB-I client 는 서비스 리스트의 선택/표시 가능을 표시할 수 있다.
필요정보(@required): 해당 delivery 가 하이브리드 서비스나 acceptable experience 를 제공하는지 여부를 나타낸다.
실시예들에 따른 이 정보는 서비스 목록 공급자가 정의한 허용 가능한 경험을 제공하기 위해 전달 유형이 DVB-I 클라이언트에서 지원되고 설치되어야 하는지 여부를 나타낸다. 클라이언트가 DVB 서비스를 검색하기 위해 관련 방송 신호 또는 IP 네트워크를 사용할 수 있는 경우 해당 전달 유형이 설치될 수 있다. 또한, 이 필드는 @installRequired 라고 지칭될 수 있다.
어베일러빌리티정보(@availability): required 속성을 만족하지 못하고 user 로 부터의 service 선택을 표시할지 여부를 나타낸다.
실시예들에 따른 이 정보는 해당 서비스가 user 에게 서비스를 제공하기 위한 조건을 만족하는 지의 여부를 나타낸다. 해당 필드의 지시의 따라서 DVB-I client 는 UI/UX 에 표시 여부를 확인할 수 있다.
두 값의 조합에 따라 User 에게 선택을 위한 충분한 정보를 제공하고 user 에게 명확한 선택을 할 수 있는 UI/UX 를 제공할 수 있다.
필요정보(@required)는 서비스 프로바이더에 의해 정의되는 허용가능한 경험(acceptable experience)를 제공하기 위해서 딜리버리 타입이 DVB-I 클라이언트에 의해 서포트되고 이용 가능한지 여부를 나타낸다. 허용가능한 경험은 예를 들어, 하이브리드 서비스를 지칭할 수 있다.
실시예들에 따른 딜리버리 타입은 DASH, T, S, C, 5G 등을 포함할 수 있다. DASH딜리버리타입, T딜리버리타입, S딜리버리타입, S딜리버리타입, RTSP딜리버리타입, 멀티캐스트TS딜리버리타입 등과 같이 엘리먼트가 표시될 수 있다.
@required는 Boolean 타입을 가지고, true 또는 false 값을 가질 수 있다.
어베일러빌리티정보(@availability)는 DVB서비스들들 이용하기 위해 관련된 방송 신호 또는 IP네트워크가 클라이언트에 의해 이용 가능한 경우 딜리버리 타입이 이용 가능하고, 딜리버리 타입 내 서비스들이 UI/UX 내 추천 가능한지 여부를 나타낼 수 있다(A delivery type is available and the services in the delivery type is recommendable in UI/UX when the related broadcast signal or IP network can be used by the client to retrieve DVB services).
어베일러빌리티정보(@availability)는 Boolean 타입을 가지고, true 또는 false 값을 가질 수 있다.
우선순위(@priority)는 다른 딜리버리 타입들 대비 서비스 리스트의 우선순위를 나타낸다. 이 어트리뷰트의 낮은 값은 높은 우선순위를 나타낼 수 있다.
예를 들어, 도73을 참조하면, DASHDelivery required가 true이고, availability가 yes(true)이면, 이 서비스 리스트들 및 이 서비스 리스트들에 의해 획득되는 서비스들의 딜리버리 타입은 DASH임을 나타낸다. DASH 지원 단말은 이 서비스 리스트들을 획득하여, 서비스 리스트들에 대한 서비스에 관한 UIUX를 제공할 수 있다. priority는 1이고 다른 서비스 리스트보다 높은 우선 순위를 가질 수 있다. recommended 가 ””이면 이 서비스 리스트들 단말에 추천할 수 있다. DVBTDelivery required가 false이고 availability =””이면, 이 서비스 리스트들 및 이 서비스 리스트들에 의해 획득되는 서비스들의 딜리버리 타입이 T임을 나타낸다. 즉, T지원 단말은 이 서비스 리스트들을 획득하여, 서비스에 관한 UI/UX를 제공할 수 있다. priority는 2이고, 추천여부(recommended)는 ””이다.
실시예들에 따른 장치는 클라이언트에 사전에 설치된 레지스트리를 가질 수 있다. 클라이언트는 사전 설치된 딜리버리 방법에 따라서 서비스 리스트 레지스트리에 디스커버리 쿼리를 요청할 수 있다. 인터페이스에 기반하여, 클라이언트의 요청을 대응하여 서버는 서비스 리스트들에 대한 엔드 포인트를 전달할 수 있다. 멀티캐스트 딜리버리가 요구되는지, 어베일러빌리티가 있는지, 우선권이 어덯게 되는지 등에 관한 정보를 수신기(클라이언트)에 전달할 수 있다. 클라이언트는 서비스 리스트에 기반하여 서비스를 발견하고 획득할 수 있다.
도74는 실시예들에 따른 통신망 브로드캐스트에 대한 DVB-I를 나타낸다.
도74는 도48과 같이, 5G와 같은 통신망인 3GPP 5G 브로드캐스트 Rel. 16 및 상용 DVB-I 어플리케이션을 도시한다.
2005 년 release 6 이래로 MBMS 를 지원하기 위한 part 가 정의되고 있다. release 14 부터 하기의 요구사항을 지원하기 위해 UTRAN 을 기반으로 TV 서비스 지원을 위한 3GPP 표준제정이 진행 중이다.
3GPP 상 Free-to-Air (FTA) 서비스의 지원은 다음과 같다.
MNO 브도르캐스트 구독 없이 UE들을 윈한 오직 브로드캐스트 서비스, 공유된 eMBMS 기능들의 지원, 컨텐트, MBMS 서비스 및 MBMS 트랜스포트 기능들의 디커플링, eMBMS 서비스 및 제3자에 대한 트랜스포트 캐퍼빌리티, eMBMS통한 TV 브로드캐스트에 전용된 네트워크, Inter-Site Distance (ISD)를 지닌 Single Frequency Network (SFN), 셀룰러 배치와 관련된 ISD, Receive-Only Mode (ROM) 서비스 및 디바이스.
도74는 DVB service provider 가 5G network 를 통해 DVB-I application 을 적용하는 방법들을 도식화 한 것이다. 5G broadcast 는 5GNR 을 통한 5MBS 와 기존 MBMS 표준을 준용하여 BMSC 를 통한 High Power High Tower 의 방법이 있다. DVB service / content provider 와 DVB-I service entry 에 서비스를 등록한 3rd party provider 등이 서비스를 DVB-I 서비스를 통해 서비스 리스트를 발행하면, DVB-I client 는 해당 서비스들을 discovery 하고, 5G Broadcast 망을 통해 미디어 서비스를 수신할 수 있다.
도75는 실시예들에 따른 5GBC 구조 상 DVB-I를 나타낸다.
실시예들에 따른 방법/장치는 3GPP 5G 브로드캐스트 네트워크를 통해 DVB-I 서비스를 제공할 수 있다.
현재 DVB-I 서비스는 Service 제공자가 Service entry 의 등록하면, DVB-I client 가 DVB Central Service Repository 를 통해 list 들의 list 를 수신하고 서비스 리스트를 선택하는 구조로 정의하고 있다. 그림 41과 같이, 5GBC network 를 통한 DVB-I service delivery 는 현재 DVB-I service list 내에서 delivery method로서 정의하지 않고 있다. 본 특허는 DVB-I service list 내에 DVB-T/S/C와 동일한 레벨로서의 delivery method 로서 확장과 5GBC network 를 사용가능한 DVB-I client 가 3GPP 표준을 준수하여 정의된 서비스 unique 정보를 인식하여 서비스를 수신할 수 있도록 하는 솔루션을 고안하고자 한다.
도75는 DVB-I over 5GBC architecture 로 기존 DVB 방송 physical 전송 방법과 유사한 HPHT 의 방식과 MBMS 표준을 준용하여 MBMS 의 service bearer - MBMS gateway - eNodeB 를 통해 서비스를 수신하는 방법이 있다. 이러한 5GBC network 를 통한 미디어 전송은 서비스 고유의 정보를 할당 및 발행하여 단말이 서비스 별로 구분하여 수신하고 소비할 수 있다. 따라서 DVB-I 서비스 리스트 내에는 해당 unique information 을 확장 및 정의하여 5GBC network 의 연결과 service discovery 및 media data 를 retrieve 할 수 있다.
Content/Service provider 는 DVB-I 표준에 따라 Central Service Repository 에 서비스 리스트(서비스) 등록한다.
DVB-I 서비스 리스트에 정의한 해당 서비스의 동일한 식별정보를 xMB 인터페이스를 통해 BMSC에 전달한다.
도76은 실시예들에 따른 서비스 아이디를 통한 그룹 메시지 획득 방법을 나타낸다.
실시예들에 따른 방법/장치는 SCS/AS 식별자, 서비스 아이디, 트랜젝션 식별자에 기초하여 그룹 메시지를 식별하고 획득할 수 있다.
도77은 실시예들에 따른 그룹 메시지 획득 과정을 나타낸다.
DVB-I client / MBMS client 의 서비스 discovery 요청이 자동 or 수동으로 실행되면, MBMS resource 의 Group message 를 획득하기 위한 절차를 수행한다. 해당 과정에서 MNO 와 service 사업자간 약속을 통해 현재 UE 의 위치정보나 Geo IP 정보를 기반 기 정의한 unique 정보들을 포함한 약속된 request / response 과정을 거친다. Service ID, transaction ID 를 포함하여 도77과 같은 request 를 수행한다.
실시예들에 따른 DVB-I 리스트 서비스 디스커버리 프로세스(DVB-I list Service discovery process)는 다음과 같다.
현재 DVB-I 표준은 service discovery query 문법을 하기와 같이 정의하고 있다:
https://www.service-list-registry.com/query?<parameter1>=value1&<parameter2>=value2
parameter : TargetCountry, regulatorListFlag, Delivery, Language, Genre ProviderName, isLocal(New), isWAN(new)
ex)https://www.service-list registry.com/query?<targetCountry>=UK&<regulatorListFlag>=true&<Delivery>=5gbc&isLocal=true
현재 DVB-I 표준은 하기와 같이 절차를 정의하고 있다.
“CSR bootstrap (서비스 리스트 서버에 엑세스함)-> Service list entry points 들 수신(list of lists, 복수의 리스트들의 리스트에 엑세스할 수 있는 정보를 수신함)-> Service list URL 선택-> Service list 를 수신(서비스 리스트에 엑세스하고, 클라이언트가 원하는 서비스 리스트를 수신함)-> Service list 내 Postcode 기반 Region ID 인식-> 현재 TV 의 주소에 따라 region ID 매칭 된 서비스 선택-> Capability + Priority 에 맞는 Service instance 선택”
DVB-I 표준은 현재 위치 정보를 활용한 서비스 리스트를 수신하는 방법을 고려하지 않고 국가 지역내에 모든 지역서비스들을 service list 내에 포함하고 있다. 해당 방법은 user 의 지역/위치에 관계없이 모든 지역서비스를 수신하고 있어, 불필요한 데이터를 수신받고 있는 기술을 정의하고 있다.
또한 Target Country 의 값이 multiple value 가 삽입 시, 방대한 데이터의 관리와 채널 충돌이슈가 발생하여 DVB-I client 측면의 잠재적 오류의 가능성이 있다. 예를 들어, DVB-I client app 이 국가를 이동하게 되면, 해당 국가의 서비스를 접속하기 위해 추가 리스트를 받습니다. 예를 들어 TargetCountry = UK 로 install 을 하고 프랑스로 이동하게 되면 TargetCountry = FR 을 추가하게 되면 2개의 국가의 지역 방송 리스트를 모두 수신하게 되는 형태가 된다.
최근엔 CDN 기술로 인접한 지역/국가 별 데이터 센터로 접근하여 데이터를 수신하고 있고, 또한 5GMS, BC 관점에서도 proxy / Edge 의 flexible 한 생성과 삭제가 있어 현재 기지국 위치나 GPS 를 인식가능한 Mobile 관점의 서비스 bootstrapping 도 “효율적인” 서비스 접근이 될 수 있다.
또한 현재 DVB-I 표준은 Mobile / 5G 용 default bootstrap 하기 위한 method 가 정의되지 않았다. 따라서 방대한 리스트와 이동성, 5G 방송이라는 다양한 수신 루트가 존재하는 상황에 효율적인 서비스리스트 획득 요구된다. 확장 가능한 안은, 1) CSR bootstrapping : CSR query 확장, 2) Service list offering scheme extension : 위치기반정보나 5G 서비스 관련 정보 확장, 3) Service instance extension : 5GBC 를 위한 service instance (new delivery) / source type / 확장 등이 가능하다.
실시예들은 5G/Mobile 을 위한 서비스 default query 를 새롭게 정의하여 현재 5G(res IP) 정보(isWAN) 또는 GPS 정보(동의필요, isLocal) 활용해서 수신가능한 서비스 또는 서비스 인스턴스들을 포함한 서비스리스트를 Backend SQL 통해서 받을 수 있다.
5G broadcasting 의 리스트를 받기 위해서 현재 위치를 기준으로 수신가능한 주파수 스캔을 하고, parameter 중 ?delivery = 5GBC 를 포함하여 DVB-I service repository 에 접근할 수 있다. DVB-I 는 상기 요청에 대한 응답으로 DVB-I 표준 내에 기 정의한 ServiceListEntryPoint 들을 전달한다. ServiceListEntryPoint 내에는 “”value 에 해당하는 list 들의 list 를 포함하고 있다. 이때 현 리스트 내에는 현재 위치정보 기반하여 수신가능한 5GBC 리스트를 전달하고 실시예들에 따른interface 에서 수신가능한 서비스들과 실시예들에 따른 interface 를 통해 수신한 unique 정보를 식별하여 service (service instance) matching 을 통해 DVB-I client service UI/UX 에 나타낼 수 있다.
도78은 실시예들에 따른 5GBC를 위한 DVB-I 서비스 리스트 오퍼링 딜리버리 타입의 확장을 나타낸다.
실시예들에 따른 DVB-I 서비스 스킴의 DVB-5GBCDelivery 엘리먼트를 통해서 DVB-5G 딜리버리를 나타낼 수 있다.
AbstractDeliveryType 필드는 서비스 리스트 공급자가 정의한 허용 가능한 경험을 제공하기 위해 전달 유형이 DVB-I 클라이언트에서 지원되고 설치되어야 하는지 여부를 나타낸다.
클라이언트가 DVB 서비스를 검색하기 위해 관련 방송 신호 또는 IP 네트워크를 사용할 수 있는 경우 전달 유형이 설치된다.
도79는 실시예들에 따른 DVB 5GBC 딜리버러 티압을 나타낸다.
도78의 딜리버리 타입은 도79와 같이 엘리먼트를 포함할 수 있다.
도80은 실시예들에 따른 5GBC 를 지원하기 위한 DVB-I 서비스 인스턴스 타입 확장(ServiceInstanceType extension)를 나타낸다.
실시예들에 따른 DVB-I 서비스 스킴은 도80과 같은 서비스 인스턴스 타입의 확장 값을 포함할 수 있다.
도81은 실시예들에 따른 DVB 5GBC 딜리버리 파라미터 타입을 나타낸다.
실시예들에 따른 DVB-I 서비스 스킴은 도81과 같은 DVB 5GBC 딜리버리 파라미터 타입을 포함할 수 있다.
도82는 실시예들에 따른 5GBC 서비스 획득 과정을 나타낸다.
실시예들에 따른 방법/장치는 도78 내지 도81에 기초하여, 5GBC 서비스를 획득할 수 있다.
도82의 실시예들에 따른 방법/장치의 5GBC 획득과정은 다음과 같다.
1) Scan 시작 및 terminal 정보 획득: capabilities, GPS, country 등이 획득될 수 있다.
2) 5GBC / RF 스캔 : RF 통해 수신되는 BC 신호의 인식(perception)
3) CSR bootstrap : 1) 에서 획득한 정보와 단말(terminal) 통해서 받은 User 의 선택을 통해 query에 조건을 추가하고, delivery = 5GBC, isLocal=true 와 같이 정보를 추가한다.
4) 현재 위치 기준에 기초하여, 가능한 5GBC 의 신호들의 리스트들의 리스트(list of lists) 를 수신한다.
5) Service list URL 통해 서비스 리스트 요청한다.
6) 5GBC 포함한 서비스 리스트를 획득하고, 5GBC 의 unique ID 를 포함한 Service instance 정보를 획득한다.
7) 5GBC 서비스를 수신한다.
실시예들에 따른 방법/장치는 DVB-I 하위 호환을 위한 추가적인 이미지 확장을 수행할 수 있다.
실시예들에 따른 방법/장치가 지원하는 DVB-I 이미지 타입은 다음과 같다.
현재 DVB-I 표준은 UI/UX 에 적용 가능한 이미지 엘리먼트(image element)들을 다음과 같이 정의하고 있다:
PNG 또는 JPG 의 서비스 리스트 로고: 작은 사이즈를 가진다.
PNG 또는 JPG 내 서비스 로고: 작은 사이즈를 가진다.
PNG 또는 JPG 내 컨텐트 가이드 소스 로고: 작은 사이즈를 가진다.
프로그램 포스터들: 전체 스크린 사이즈를 가진다.
DVB-I 표준은 해당 element scheme type 에 따라 image URI 를 정의하고 DVB-I client 는 화면 내에 적절한 UI/UX 로 구성할 수 있다. 현재 DVB-I 는 image 를 정의하는 방법을 하기와 같은 xsd 로 정의하고 있다.
<element name="RelatedMaterial" type="tva:RelatedMaterialType" minOccurs="0" maxOccurs="unbounded"/>
<complexType name="RelatedMaterialType">
<sequence>
<element name="HowRelated" type="tva:ControlledTermType" minOccurs="0"/>
<element name="MediaLocator" type="dvbisd:ExtendedTVAMediaLocatorType" maxOccurs="unbounded"/>
</sequence>
</complexType>
도83은 실시예들에 따른 이미지를 정의하는 방법을 나타낸다.
전술한 xsd가 도83과 같을 수 있다. 미디어 로케이터 및 미디어 uri 필드를 통해 이미지의 타입을 나타내고, 이미지의 uri를 포함시킬 수 있다.
DVB-I spec 는 Tv anytime scheme 에서 정의한 @href 값으로 Service List Logo, Service Logo, Content Guide Source Logo, Program Posters 중 용도들을 속성들을 식별하고, @MediaLocator 의 속성을 통해 image/type 을 정의한다. 도83과 같이 anyURI 의 값을 통해 실제 연결 되는 Image URI 를 정의할 수 있다.
실시예들은 DVB-I image type 추가에 따른 문제점을 다음과 같이 해결할 수 있다.
DVB-I 내의 image type 지원은 logo 와 같이 대부분 작은 사이즈의 이미지 또는 Full screen 제공하는 element 들을 제공하고 있다. 만약 service/content thumbnail 을 제공한다고 했을 때 이러한 element 들에 기반하여 제공하기에는 속성상 맞지 않는 정의가 될 수 있다. 다음 예제와 같이 기존 DVB-I 표준에서 사용하는 logo 의 속성들을 UI/UX 로 구성했을 때 service UI/UX 는 small size 의 logo 로 사용될 수 있고 service thumbnail 은 logo 로 배치하기에는 적절하지 않는 문제점이 있다.
도84는 실시예들에 따른 이미지 타입에 따른 예시를 나타낸다.
전술한 바와 같이 service/content thumbnail 의 부재는 특히 service 들을 preview 형태로 보여주는 모바일 UI/UX 를 구성했을 때 small size 이미지인 logo 속성을 활용하여 구성하기에는 어려운 문제가 있다.
한편 DVB-I 표준 내 thumbnail 을 제공하기 위한 image type 은 현재 JPEG, PNG 값으로 정의하고 있다. 해당 image 들은 1990 년대 초반의 정지영상 압축기법으로 압축효율이 현재 이미지 압축기술에 비교하면 비교적 효율이 떨어진다. 최근 web browser 에서는 JPEG, PNG 보다는 압축효율이 좋고 JPEG(손실), PNG(무손실) 을 지원 및 대체 할 수 있는 webp image format 을 많이 사용하고 있다. 또한 webp 는 animated preview 를 기능이 제공 가능하여 GIF 와 비교를 할 수 있는데, webp 는 90 년대 초반에 출시된 8bit 256 color 만 제공하는 GIF 와 비교했을 때 압축률 관점에서도 우수한 성능을 보여주고, 색상수에 제한이 없어 큰 해상도에서 깨지지 않는다는 장점이 있다.
현재 미디어 전송 및 방송표준에서는 90년대 초반에 사용하고 있는 JPEG, PNG, GIF 만을 정의하고 이후에 추가되는 image type 의 경우의 case 는 고려하지 않고 있다. 방송이나 Streaming 표준 특성 상 서비스 제공 측면에서 stability 와 IoP 측면에서 널리 사용되고 있는 기존의 format 들만을 사용하고 있지만 새로운 이미지 포맷의 추가는 고려하지 않고 있다.
따라서, 실시예들은 (1) DVB-I 표준 내에 thumbnail 정의의 부재. (2) 기존의 image format 에 더하여 webp 를 추가를 고려한 기술적 솔루션을 제안한다.
방송 미디어 전송 표준 delivery 구조(push, quisi-static) 기반 DVB-I spec 내에 새로운 이미지가 확장되어 service list 내에 정의된다면, 종래의 JPEG, PNG 만을 고려하는 DVB-I client 는 webp format 의 수신 시 오동작을 일으킬 수 있다. 따라서 하위호환을 고려한 확장방법과 적절한 수신기 동작의 고안이 필요하다
실시예들에 따른 DVB-I 하위호환을 고려한 썸네일(thumbnail) 및 이미지 타입 확장(image type extension)을 설명한다.
도85는 실시예들에 따른 이미지 타입의 속성의 확장을 나타낸다.
첫 번째 옵션은 DVB-I 하위호환을 고려한 TV anytime 확장이다.
DVB-I 내의 image type 속성은 TV anytime 의 scheme hierarchy 를 따르고 있어 해당 속성의 확장이 필요하다.
실시예들에 따른 DVB-I 서비스 스킴의 HowRelated 엘리먼트의 타입이 ControlledTermType인 경우, ControlledTermType의 시퀀스는 @href 엘리먼트를 포함할 수 있다.
HowRelatedCS 내 @href 는 DVB-I 내에서 Classification scheme 형태를 정의한다.
텀ID가 1000.1이면 아웃 오브 서비스 배너를 나타내고, 텀ID가 1001.1이면 서비스 리스트 로고를 나타내고, 텀ID가 1001.2이면 서비스 로고를 나타내고, 텀ID가 1001.3이면 서비스 썸네일을 나타낼 수 있다.
이와 같이 @href 값을 Service Thumbnail 지원할 수 있도록 추가 Term ID 를 추가가 필요하다.
도85을 참조하면, 서비스 리스트( Service List), 연관정보(Howrelated), Term ID, Service Thumbnail(banner) 간 정보의 포함관계를 볼 수 있다. 예를 들어, 서비스 리스트는 연관 정보를 포함하고, 연관 정보는 미디어 데이터를 위한 텀 ID 정보를 포함하고, 텀 ID 정보가 제 1값을 가지면, 제1값은 서비스 리스트를 위한 로고를 나타내고, 텀 ID 정보가 제 2값을 가지면, 제2값은 미디어 데이터를 위한 로고를 나타내고, 텀 ID 정보가 제 3값을 가지면, 제3값은 미디어 데이터에 관한 장면을 나타내는 이미지를 나타낼 수 있다.
한편, 텀 ID정보가 제4값을 가지면, 제 4값은 아웃 오프 서비스 배너를 나태낼 수 있다. 텀 ID정보는 서비스의 온스크린 모습 내 사용될 수 있는 아이템을 나타낼 수 있다.
서비스 리스트 로고는 그래픽 아이콘으로, 서비스 리스트를 시각적으로 식별하는데 사용될 수 있다. 서비스 로고는 그래픽 아이콘으로, 서비스를 시각적으로 식별하는데 사용될 수 있다.
서비스 배너는 큰 포맷의 그래픽 엘리먼트이고, 서비스를 위한 주제나 장면을 묘사하는 엘리먼트일 수 있다.
실시예들은 서비스 및/또는 프로그램에 관련된 서비스 배너 정보를 전달할 수 있다. 실시예들에 따른 서비스 리스트 이미지 포맷들이 확장될 수 있고, 호환성을 위해서, PNG 및/또는 JPG 포맷이 함께 제공될 수 있다. 실시예들에 따른 서비스 리스트들 및 서비스에 관련된 로고들은 아이콘 형태에 작은 사이즈를 가질 수 있다. 따라서, 좀 더 리치한 서비스 및/또는 프로그램 정보를 제공하기 위해서, 서비스 배너 정보가 확장될 수 있다.
실시예들에 따른 서비스 리스트에 포함된 HowRelatedCS 엘리먼트에 텀 아이디를 부여하여, 서비스 배너 정보를 전달할 수 있다. 서비스 배너는 서비스에 관한 장면 또는 주제를 도시하는 큰 사이즈의 그래픽 엘리먼트일 수 있다.
실시예들에 따른 싱글 RelatedMaterial 엘리먼트는 서비스 배너 및/또는 멀티플 이미지를 사용하기 위한 디스크립션을 전달할 수 있다.
서비스 리스트를 위한 로고들은 서비스 리스트 내 하나의 RelatedMaterial 엘리먼트 내 전달될 수 있다. HowRelated 엘리먼트는 urn:dvb:metadata:cs:HowRelatedCS:2020:1001.1 값을 전달하는 @href 어트리뷰를 포함할 수 있다. MediaLocator 엘리먼트는 MediaURI 엘리먼트를 포함하고, MediaURI 의 값은 이미지 파일에 대한 URI를 포함할 수 있고, MediaURI 의 contentType 어트리뷰트는 이미지 미디어 타입을 전달할 수 있다.
멀티플 서비스 리스트 로고들 각각이 RelatedMaterial 엘리먼트 내 MediaLocator 엘리먼트를 가지도록 생성될 수 있다. 적어도 하나의 서비스 리스트 로고는 미디어 타입 이미지/JPEG 또는 이미지/PNG와 함께 호환성을 위해서 제공될 수 있다. 이미지/WEBP를 포함하는 다른 이미지 포맷들이 더 제공될 수 있다. DVB-I 클라이언트는 딜리버리에 앞서 서로 다른 해상도를 확장/축소되는 이미지를 요청할 수 있다.
서비스 리스트를 위한 로고는 서비스 내 싱글 RelatedMaterial 엘리먼트 내에서 제공될 수 있다. HowRelated 엘리먼트는 urn:dvb:metadata:cs:HowRelatedCS:2020:1001.2 값을 전달하는 @href 어트리뷰트를 가질 수 있다. MediaLocator 엘리먼트는 MediaURI 엘리먼트를 포함할 수 있고, MediaURI 의 값은 이미지 파일에 대한 URI를 포함하고, MediaURI 의 @contentType 어트리뷰트는 이미지 미디어 타입을 전달한다.
멀티플 서비스 로고들 각각은 RelatedMaterial 엘리먼트 내 MediaLocator 엘리먼트를 포함한다. 적어도 하나의 서비스 로고는 미디어 타입 이미지/JPEG 또는 이미지/PNG와 함께 호환성을 위해 제공되고, 다른 이미지 포맷들, 예를 들어, 이미지/WEBP를 포함하는 포맷들이 더 제공될 수 있다. 서비스 로고들은 서비스 및/또는 서비스 인스턴스 레벨에서 시그널링될 수 있다. DVB-I 클라이언트는 딜리버리에 앞서 서로 다른 해상도로 스케일링되는 이미지를 요청할 수 있다.
실시예들에 따른 싱글 RelatedMaterial 엘리먼트는 멀티플 이미지 정보를 전달할 수 있다.
스케쥴된 서비스 시간을 벗어나는 서비스를 선택하기 위해서, 클라이언트는 다음과 같은 동작을 수 있다. 예를 들어, DVB-I클라이언트가 모든 서비스 인스턴스들에 대한 스케쥴된 시간을 벗어나는 시간의 파트 타임 서비스를 선택하는 경우 또는 현재 선택된 서비스의 모든 서비스 인스턴스들이 이용 가능하지 않은 경우, 실시예들에 따른 방법/장치는 다음 동작을 수행할 수 있다.
서비스를 위해 시그널링되는 어플리케이션이 시행될 수 있다. 서비스를 위한 RelatedMaterial 에 기술된 out of service 이미지가 제공될 수 있다. 싱글 RelatedMaterial 엘리먼트 내 out of service 이미지가 제공될 수 있다.
HowRelated 엘리먼트는 urn:dvb:metadata:cs:HowRelatedCS:2020:1000.1값을 전달하는 @href 어트리뷰트를 가질 수 있다.
MediaLocator 엘리먼트들은 MediaURI 엘리먼트를 포함할 수 있고, MediaURI 의 값은 이미지 파일에 대한 URI를 가질 수 있다. @contentType 어트리뷰트는 이미지 미디어 타입을 전달할 수 있다. 멀티플 out of service 이미지 각각은 RelatedMaterial 엘리먼트 내 MediaLocator 엘리먼트를 포함할 수 있다. 적어도 하나의 out of service 이미지는 호환성을 위해서 미디어 타입 이미지/JPEG 또는 이미지/PNG와 제공될 수 있다. DVB-I클라이언트는 딜리버리에 앞서 상이한 해상도로 스케일되는 이미지를 요청할 수 있다.
DVB-I 클라이언트는 플레이리스트 내 모든 아이템을 재생한 경우, 컨텐트 종료 이미지를 제공할 수 있다.
컨텐트 종료 이미지(content finished image)는 싱글 RelatedMaterial 엘리먼트 내 시그널될 수 있다. HowRelated 엘리먼트는 urn:dvb:metadata:cs:HowRelatedCS:2020:1000.2값을 전달하는 @href 엘리먼트를 가질 수 있다. MediaLocator 엘리먼트들은 MediaURI 엘리먼트를 포함하고, MediaURI 의 값은 이미지 파일에 대한 URI를 포함한다. @contentType 어트리뷰트는 이미지 미디어 타입을 전달한다.
멀티플 컨텐트 종료 이미지 각각은 RelatedMaterial 엘리먼트 내 MediaLocator 엘리먼트를 가질 수 있다. 적어도 하나의 멀티플 컨텐트 종료 이미지 는 호환성을 위해서 미디어 타입 이미지/JPEG 또는 이미지/PNG와 제공될 수 있다. DVB-I클라이언트는 딜리버리에 앞서 상이한 해상도로 스케일되는 이미지를 요청할 수 있다.
실시예들에 따른 서비스 타입 관련하여, RelatedMaterial 엘리먼트는 다음 타입 필드들 폼하할 수 있다: Out of service banners, Service related applications, Service logos, Service Banner, Alternative text for service logos.
도86은 실시예들에 따른 서비스 썸네일을 지원하는 예시이다.
@MediaLocator 엘리먼트는 DVB-I 에서 기존 TV anytime scheme 의 확장형 dvbisd:ExtendedTVAMediaLocatorType 으로 xsd 를 도86과 같이 정의한다.
DVB-I 표준은 dvbisd:ExtendedURIType 을 새롭게 정의하여 도86과 같이 정의한다.
도86를 참조하면, Service Thumbnail(banner) 타입이 jpeg, png, webp 등을 가질 수 있다. 예를 들어, 서비스 리스트는 미디어 로케이터 정보를 포함하고, 미디어 로케이터 정보는 미디어URI 정보를 포함하고, 미디어URI정보에 대한 컨텐트 타입은 이미지에 관한 타입 정보를 포함하고, 이미지에 관한 타입 정보는 webp 타입을 포함하고, 이미지에 관한 타입 정보는 호환성을 위해서 jpeg 또는 png 타입 중 적어도 하나를 더 포함할 수 있다.
썸네일, 배너, 이미지 등은 서비스에 관한 대표 이미지 정보를 의미하는 용어로 해석될 수 있다. 서비스 배너는 서비스 로고와 상호 교환 가능하고 보완하기 위한 것이다. 서비스의 장면이나 테마를 묘사하기 위해 더 많은 화면 공간을 사용할 수 있는 경우에 배너를 적용할 수 다. 서비스 배너는 서비스 로고와 함께 사용할 수도 있다.
멀티플 서비스 배너는 각각이RelatedMaterial 요소 내 MediaLocator 엘리먼트를 가지는 경우 시그널링될 수 있다. 한편, 하나의 미디어 로케이터가 복수의 서비스 배너를 나타낼 수도 있다.
적어도 하나의 서비스 배너는 호환성을 위해 미디어 유형 이미지/jpeg 또는 이미지/png와 함께 제공되고, 이미지/webp를 포함한 다른 이미지 형식은 선택적으로 제공될 수 있다. 서비스 배너는 서비스 수준에서 시그널링될 수 있다. DVB-I 클라이언트는 이미지를 전달하기 전에 다른 해상도로 조정될 수 있다.
도86를 참조하면, Service Thumbnail(banner) 타입이 jpeg, png, webp 등을 가질 수 있다. 예를 들어, 서비스 리스트는 미디어 로케이터 정보를 포함하고, 미디어 로케이터 정보는 미디어URI 정보를 포함하고, 미디어URI정보에 대한 컨텐트 타입은 이미지에 관한 타입 정보를 포함하고, 이미지에 관한 타입 정보는 webp 타입을 포함하고, 이미지에 관한 타입 정보는 호환성을 위해서 jpeg 또는 png 타입 중 적어도 하나를 더 포함할 수 있다.
이미지 타입들을 처리할 수 있는 캐퍼빌리티를 지닌 장치의 경우, 리치한 UI/UX제공을 위해서 webp 타입의 이미지의 서비스 배너를 jpeg 또는 png 타입의 배너보다 우선하여 표시할 수 있다.
도87은 실시예들에 따른 이미지 타입 지원을 나타낸다.
DVB-I 는 도87과 같이 TVA scheme 를 reference 하고, image type 의 decodable 을 확인하기 위해 mimeType 을 required 로 mandatory 처리하고 있다.
이러한 mimeType 을 “”로 확장하여 DVB-I 에서 webp 를 지원할 수 있다.
@href : urn:dvb:metadata:cs:HowRelatedCS:2019:1001.2 = service logo 를 나타낸다.
@href : urn:dvb:metadata:cs:HowRelatedCS:2021:1001.3 = service thumbnail 를 새롭게 정의할 수 있다.
@contentType : “”로 extension 을 할 수 있다.
싱글 또는 멀티플 미디어 로케이터들의 서브 엘리먼트로써, 이미지 타입을 나타낼 수 있다.
DVB-I client 중 webp type 을 지원하지 않는 단말이 있을 수 있으므로 DVB-I service list 내 @relatedMaterial 내의 jpeg/png 는 적어도 하나를 반드시 정의하고, webp format 을 추가로 정의 한다. DVB-I client 가 수신 시 적어도 하나의 png/jpeg 의 image format 이 정의되어 있고, webp mimeType 을 지원하는 DVB-I client 이면 webp 를 사용하여 적용할 수 있고, DVB-I client 가 webp 를 지원하지 않는다면 jpeg/png 를 제공할 수 있다. 이러한 방법으로 기존의 DVB-I client 의 하위호환이 가능한 새로운 image type 을 추가할 수 있는 효과가 있다.
예를 들어, 기존 포맷인JPEG엔 낮은 우선순위 설정할 수 있다. 확장된 포맷이 더 높은 우선순위를 가질 수 있다.
도88은 실시예들에 따른 미디어 처리 장치를 나타낸다.
도88은 미디어 수신 장치, 즉 DVB-I 클라이언트의 구조예시를 나타낸다. 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다.
도88의 장치는 상술한 방법 및 후술 방법에 기초하여 썸네일 및 이미지 타입을 전달하고 획득하고 제공할 수 있다.
도89는 실시예들에 따른 이미지 타입 지원을 나타낸다.
도89와 같은 두 번째 방법은 첫 번째 방법의 ExtendedURIType 의 hierarchy 에서 확장하는 안이다. Priority 속성을 추가하여 다수의 image format 이 RelatedMaterial 에 정의된다면 priority 를 통해 DVB-I client 가 priority, minetype 을 통해 decodable 한 image format 을 선택하여 decoding 한 후 UI/UX 의 event 에 맞도록 화면안에 구성할 수 있다.
도90은 실시예들에 따른 이미지 타입 지원을 나타낸다.
세 번째 방법은 DVB-I 서비스 썸네일 엘리먼트를 확장하는 것이다.
이 방법은 Service thumbnail 지원 new element 확장 관점의 솔루션을 의미한다.
기존의 @RelatedMaterial 의 속성은 MPEG7 및 TVA reference 와 DVB-I 를 위한 CS 를 확장하는 것으로 표준 IoP 상 합의와 수정이 쉽지 않고, 첫 번째 방법은 서비스 운영측면에서 적어도 하나의 png, jpeg 을 정의하고 DVB-I client 상에서는 명확하지 않은 우선 순위가 없어 수신기 처리에 혼란이 있을 수 있다. 또한 jpeg/png 를 현재 많은 브라우저에서 기술적으로 대체가 가능하도록 API 들이 설계되어 있지만, DVB-I 표준은 방송 전송 특성을 가지고 있으므로 단순 정의가 아닌 명확한 Precedence 의 정의가 요구된다. 따라서 Service thumbnail 을 new element 로서 정의하고, 명확한 priority 를 정의하는 방법도 정의 가능하다.
위와 같이 @ServiceThumbnailOffering 을 통해 여러 개의 thumbnail 을 정의할 수 있도록 정의하고 @ServiceThumbnailType 은 extendedURIType 을 reference 하고 Priority attribute 를 확장한 형태로 정의할 수 있다. 이 때 priority 는 이 서비스의 우선 순위를 의미하는 명확한 속성으로 DVB-I client 의 동작을 명확히 체크 후 서비스를 제공 할 수 있다.
위와 같이 ServiceThumbnailOffering 으로 다수의 service thumbnail 들을 정의하고 priority 와 DVB-I client capability 에 따라서 적절한 service thumbnail 을 정의할 수 있다. 예를 들어 webp 를 지원하고 animated preview 를 지원을 원하는 사업자 측면에서는 해당 element 를 제공하여 명확한 서비스 제공자 의도와 화면 구성을 제공하고, DVB-I client 측면에서는 사용자에게 Rich 한 GUI 를 제공 할 수 있는 image format 을 요청할 수 있다.
도91은 실시예들에 따른 서비스 썸네일 오퍼링 및 서비스 썸네일 엘리먼트를 나타낸다.
상술한 새로운element 는 도91과 같이 service / service instance 에 모두 위치 할 수 있다.
도92는 실시예들에 따른 미디어 처리 장치를 나타낸다.
도92는 도91과 같이 수신기 시스템을 나타낸다.
DVB-I client 는 일련의 service discovery 를 포함한 service initialization 과정을 거치고, service list parsing 과정을 수행한다. Service manager 는 DVB-I service info 중 ServiceThumbnailOffering 을 확인하고 다수개의 thumbnail 접근 image 들을 확인한다. DVB-I client 는 MimeType 과 priority 를 확인하고 capable 한 image type 을 image 디코딩이 가능한 library 에 전달하고 UI/UX 의 event 에 맞도록 화면 안에 구성할 수 있다.
도93은 실시예들에 따른 이미지 타입 지원을 나타낸다.
네 번째 방법은 서비스 서버의 데이터베이스 및 SQL(Structured Query Language) 구조에서 DVB-I client 가 service thumbnail 을 지원할 수 있는 기술을 제안하고자 한다. DVB-I 에서 확장 및 재 정의한 ExtendedURIType 을 활용하여 baseURI 기반 다양한 image 파일을 request 및 response 를 구현할 수 있는 방법이다.
DVB-I service list 는 기 정의된 URI 를 baseURI 형태로 정의하면, DVB-I client 는 해당 정보를 기반으로 하여 다양한 image format 을 request 및 response 받을 수 있다. 다시 말해 서버는 해당 데이터 베이스들을 모두 가지고 있다는 가정 하에 DVB-I client method 와 server 간의 SQL 의 조합을 통해 적절한 image format 을 수신할 수 있다.
1. client-side query approach
baseURL/thumbnail?type = png, jpg, webp
2. The endpoint that returns all possible files.
baseURL/thumbnail
baseURL/thumbnail 의 return 값은 DVB-I client 가 수신 가능한 모든 image format 의 file 을 return 함.
수신된 파일 중에서 GUI 상 가장 적절한 image format 의 선택하여 UI/UX 를 구성할 수 있다.
도94는 실시예들에 따른 미디어 데이터 송신 방법을 나타낸다.
S9400 실시예들에 따른 미디어 데이터 송신 방법은 미디어 데이터를 생성하는 단계를 포함할 수 있다.
S9401 실시예들에 따른 미디어 데이터 송신 방법은 미디어 데이터에 관한 서비스 리스트를 생성하는 단계를 더 포함할 수 있다. 서비스 리스트는 미디어 데이터(또는 서비스, 서비스 데이터)를 디스커버리하기 위한 시그널링 정보를 의미할 수 있다. 서비스 리스트 정보는 도4, 도8, 도11, 도19, 도28, 도39, 도49, 도56, 도68 등의 정보를 나타낸다. 서비스 리스트 정보는 도11 내지 도17의 정보를 포함하고, 이러한 정보에 기반하여, 실시예들에 따른 방법/장치는 도18과 같이 서비스 인스턴스, 딜리버리 타입 별, 해상도를 UI/UX로 표시할 수 있다.
S9402 실시예들에 따른 미디어 데이터 송신 방법은 미디어 데이터 및 서비스 리스트를 네트워크에 기반하여 전송하는 단계를 더 포함할 수 있다. 미디어 데이터는 도1내지 도3과 같은 네트워크 및 프로토콜에 기반하여 전송될 수 있다. 실시예들에 따른 송신 방법/장치는 도32와 같은 컨텐트 가이드 서버들, 서비스 리스트 서버들, 서비스 리스트 레지스토리, 컨텐트/서비스 프로바이더들, 플레이리스트 서버들, MPD서버들, 스트림 서버들, 멀티캐스트 서버, 멀티캐스트 게이트웨이 및 그에 따른 동작들을 포함할 수 있다. 컨텐트는 서비스에 포함되는 데이터 단위일 수 있다. 미디어 데이터는 서비스, 컨텐츠 등 포함하는 용어로 해석될 수 있다. 실시예들에 따른 송신 방법을 수행하는 장치는 도33등과 같다. 서비스 리스트는 멀티플 서비스 리스트를 전송 시 수신 측 채널 충돌을 방지하기 위해서, 도39-42 동작을 위한 정보를 제공할 수 있다. 서비스 리스트는 도48과 같은 통신망 지원을 위해서 도49 등의 정보를 포함할 수 있다. 서비스 리스트는 도54와 같은 화질 정보를 나타낼 수 있다. 실시예들에 따른 송신 방법은 서브 픽쳐를 포함하는 미디어 데이터를 전송하기 위해서, 도61 등과 같은 파라미터를 생성하여 전송할 수 있다. 서비스 리스트는 도83-86 등과 같이 다양한 이미지 타입을 제공하기 위한 정보를 더 포함할 수 있다.
도95는 실시예들에 따른 미디어 데이터 수신 방법을 나타낸다.
S9500 실시예들에 따른 미디어 데이터 수신 방법은 네트워크에 기반하여 미디어 데이터 및 미디어 데이터에 관한 서비스 리스트를 수신하는 단계를 포함할 수 있다. 미디어 데이터는 도1내지 도3과 같은 네트워크 및 프로토콜에 기반하여 수신될 수 있다. 서비스 리스트 정보는 도4, 도8, 도11, 도19, 도28, 도39, 도49, 도56, 도68 등의 정보를 나타낸다. 실시예들에 따른 수신 동작은 도32와 같이 수신 장치(클라이언트)가 서버 및/또는 프로바이드를에 필요한 정보를 쿼리(요청)하고 그에 대한 응답 정보를 수신하는 과정을 의미할 수 있다. 도32의 각 인터페이스에 따라서 요청/응답 과정이 수행된다. 실시예들에 따른 수신 동작을 수행하는 장치는 도33등과 같다.
S9501 실시예들에 따른 미디어 데이터 수신 방법은 서비스 리스트를 제어하는 단계를 포함할 수 있다. 도 5 내지 도7과 같은 시그널링 정보 및 흐름도에 기반하여 실시예들에 따른 수신 방법 및 수신 장치는 히든 채널에 대한 처리를 제공할 수 있다. 도10과 깉이, 실시예들에 따른 수신 방법 및 수신 장치는 미디어 데이터(서비스)에 대한 가이드 정보를 제공하고, 서비스 수신 여부를 UI/UX로 표시할 수 있다. 서비스 리스트 정보는 도11 내지 도17의 정보를 포함하고, 이러한 정보에 기반하여, 실시예들에 따른 방법/장치는 도18과 같이 서비스 인스턴스, 딜리버리 타입 별, 해상도를 UI/UX로 표시할 수 있다. 실시예들에 따른 수신 방법/장치는 도19 내지 도20등의 정보에 기반하여, 도21 내지 도22와 같은 리얼 타임 서비스 수신 처리를 위한 오버 러닝 피리오드의 다이나믹 폴링을 수행할 수 있다. 실시예들에 따른 수신 방법은 채널 충돌을 방지하기 위해서, 도39-42 동작을 수행할 수 있다. 실시예들에 따른 수신 방법은 서비스 리스트를 제어하여, 도52 등과 같은 서비스 인스턴스 스위칭을 수행할 수 있다. 실시예들에 따른 수신 방법을 수행하는 수신 장치(클라이언트)는 도26과 같다. 실시예들에 따른 수신 방법은 서비스 리스트를 제어하여, 도83-86 등과 같이 다양한 이미지 타입을 제공할 수 있다.
도1-3, 도11를 참조하면, 서비스 리스트 관련하여, 실시예들에 따른 방법은 미디어 데이터를 생성하는 단계; 미디어 데이터에 관한 서비스 리스트를 생성하는 단계; 및 미디어 데이터 및 서비스 리스트를 네트워크에 기반하여 전송하는 단계; 를 포함할 수 있다.
도3을 참조하면, 프로토콜 스택과 관련하여, DVB-C/S/T/I 서비스를 디스커버리하기 위해서, 실시예들에 따른 네트워크는 인터넷을 포함하고, 네트워크는 지상파, 위성파, 케이블 중 적어도 하나를 더 포함할 수 있다.
도32 를 참조하면, 리스트들의 리스트와 관련하여, 서비스 리스트는 디스커버리하기 위한 엔트리 포인트들에 의해서 엑세스되고, 서비스 리스트는 멀티플 서비스 리스트 서버들을 위한 복수의 서비스 리스트들을 포함할 수 있다.
도85을 참조하면, 서비스 리스트( Service List), 연관정보(Howrelated), Term ID, Service Thumbnail(banner) 간 정보의 포함관계를 볼 수 있다. 예를 들어, 서비스 리스트는 연관 정보를 포함하고, 연관 정보는 미디어 데이터를 위한 텀 ID 정보를 포함하고, 텀 ID 정보가 제 1값을 가지면, 제1값은 서비스 리스트를 위한 로고를 나타내고, 텀 ID 정보가 제 2값을 가지면, 제2값은 미디어 데이터를 위한 로고를 나타내고, 텀 ID 정보가 제 3값을 가지면, 제3값은 미디어 데이터에 관한 장면을 나타내는 이미지를 나타낼 수 있다.
도86를 참조하면, Service Thumbnail(banner) 타입이 jpeg, png, webp 등을 가질 수 있다. 예를 들어, 서비스 리스트는 미디어 로케이터 정보를 포함하고, 미디어 로케이터 정보는 미디어URI 정보를 포함하고, 미디어URI정보에 대한 컨텐트 타입은 이미지에 관한 타입 정보를 포함하고, 이미지에 관한 타입 정보는 webp 타입을 포함하고, 이미지에 관한 타입 정보는 호환성을 위해서 jpeg 또는 png 타입 중 적어도 하나를 더 포함할 수 있다.
도32를 참조하면, 실시예들에 따른 장치는 미디어 데이터를 생성하는 프로바이더; 및 미디어 데이터에 관한 서비스 리스트를 생성하는 서버; 를 포함하고, 미디어 데이터 및 서비스 리스트를 네트워크에 기반하여 전송될 수 있다. 여기서, 네트워크는 인터넷을 포함하고, 네트워크는 지상파, 위성파, 케이블 중 적어도 하나를 더 포함할 수 있다.
한편, 실시예들에 따른 방법은 네트워크에 기반하여 미디어 데이터 및 미디어 데이터에 관한 서비스 리스트를 수신하는 단계; 및 서비스 리스트에 기반하여 미디어 데이터를 처리하는 단계; 를 포함할 수 있다.
한편, 실시예들에 따른 장치는 네트워크에 기반하여 미디어 데이터 및 미디어 데이터에 관한 서비스 리스트를 수신하는 수신부; 및 서비스 리스트에 기반하여 미디어 데이터를 처리하는 프로세서; 를 포함할 수 있다.
이로 인하여, DVB-I 서비스를 소개하는 서비스 대표 이미지(Service representative image) 를 제공하는 속성을 서비스 리스트에 추가하여 리치(rich)한 UI/UX를 구성할 수 있다. 오래된 이미지 포맷 표준인 jpeg/png 와 호환되고 나아가 이를 대체할 다른 이미지 포맷을 추가로 제공 할 수 있다. DVB-I 스키마가 확장됨으로 인해서 추가 제공이 가능하다. 이러한 확장을 통해 기존 jpeg/png 만을 지원하는 단말의 호환성을 지원하면서 webp 를 포함한 다른 이미지 포맷을 제공할 수 있는 효과가 있다.
실시예들은 방법 및/또는 장치 관점에서 설명되었으며, 방법의 설명 및 장치의 설명은 상호 보완하여 적용될 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 실시예들의 권리범위에 속한다. 실시예들에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다. 실시예들의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 실시예들은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 실시예들의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 실시예들의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
실시예들의 장치의 다양한 구성요소들은 하드웨어, 소프트웨어, 펌웨어 또는 그것들의 조합에 의해 수행될 수 있다. 실시예들의 다양한 구성요소들은 하나의 칩, 예를 들면 하나의 하드웨어 서킷으로 구현될 수 있다 실시예들에 따라, 실시예들에 따른 구성요소들은 각각 별도의 칩들로 구현될 수 있다. 실시예들에 따라, 실시예들에 따른 장치의 구성요소들 중 적어도 하나 이상은 하나 또는 그 이상의 프로그램들을 실행 할 수 있는 하나 또는 그 이상의 프로세서들로 구성될 수 있으며, 하나 또는 그 이상의 프로그램들은 실시예들에 따른 동작/방법들 중 어느 하나 또는 그 이상의 동작/방법들을 수행시키거나, 수행시키기 위한 인스트럭션들을 포함할 수 있다. 실시예들에 따른 장치의 방법/동작들을 수행하기 위한 실행 가능한 인스트럭션들은 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적이지 않은 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있거나, 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적인 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있다. 또한 실시예들에 따른 메모리는 휘발성 메모리(예를 들면 RAM 등)뿐 만 아니라 비휘발성 메모리, 플래쉬 메모리, PROM등을 전부 포함하는 개념으로 사용될 수 있다. 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함될 수 있다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
이 문서에서 “/”와 “,”는 “및/또는”으로 해석된다. 예를 들어, “A/B”는 “A 및/또는 B”로 해석되고, “A, B”는 “A 및/또는 B”로 해석된다. 추가적으로, “A/B/C”는 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 또한, “A, B, C”도 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 추가적으로, 이 문서에서 “또는”는 “및/또는”으로 해석된다. 예를 들어, “A 또는 B”은, 1) “A” 만을 의미하고, 2) “B” 만을 의미하거나, 3) “A 및 B”를 의미할 수 있다. 달리 표현하면, 본 문서의 “또는”은 “추가적으로 또는 대체적으로(additionally or alternatively)”를 의미할 수 있다.
제1, 제2 등과 같은 용어는 실시예들의 다양한 구성요소들을 설명하기 위해 사용될 수 있다. 하지만 실시예들에 따른 다양한 구성요소들은 위 용어들에 의해 해석이 제한되어서는 안된다. 이러한 용어는 하나의 구성요소를 다른 구성요소와 구별하기 위해 사욛외는 것에 불과하다. 것에 불과하다. 예를 들어, 제1 사용자 인풋 시그널은 제2사용자 인풋 시그널로 지칭될 수 있다. 이와 유사하게, 제2사용자 인풋 시그널은 제1사용자 인풋시그널로 지칭될 수 있다. 이러한 용어의 사용은 다양한 실시예들의 범위 내에서 벗어나지 않는 것으로 해석되어야만 한다. 제1사용자 인풋 시그널 및 제2사용자 인풋 시그널은 모두 사용자 인풋 시그널들이지만, 문맥 상 명확하게 나타내지 않는 한 동일한 사용자 인풋 시그널들을 의미하지 않는다.
실시예들을 설명하기 위해 사용된 용어는 특정 실시예들을 설명하기 위한 목적으로 사용되고, 실시예들을 제한하기 위해서 의도되지 않는다. 실시예들의 설명 및 청구항에서 사용된 바와 같이, 문맥 상 명확하게 지칭하지 않는 한 단수는 복수를 포함하는 것으로 의도된다. 및/또는 표현은 용어 간의 모든 가능한 결합을 포함하는 의미로 사용된다. 포함한다 표현은 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들이 존재하는 것을 설명하고, 추가적인 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들을 포함하지 않는 것을 의미하지 않는다. 실시예들을 설명하기 위해 사용되는, ~인 경우, ~때 등의 조건 표현은 선택적인 경우로만 제한 해석되지 않는다. 특정 조건을 만족하는 때, 특정 조건에 대응하여 관련 동작을 수행하거나, 관련 정의가 해석되도록 의도되었다.
또한, 본 문서에서 설명하는 실시예들에 따른 동작은 실시예들에 따라서 메모리 및/또는 프로세서를 포함하는 송수신 장치에 의해 수행될 수 있다. 메모리는 실시예들에 따른 동작을 처리/제어하기 위한 프로그램들을 저장할 수 있고, 프로세서는 본 문서에서 설명한 다양한 동작을 제어할 수 있다. 프로세서는 컨트롤러 등으로 지칭가능하다. 실시예들에 동작들은 펌웨어, 소프트웨어, 및/또는 그것들의 조합에 의해 수행될 수 있고, 펌웨어, 소프트웨어, 및/또는 그것들의 조합은 프로세서에 저장되거나 메모리에 저장될 수 있다.
한편, 상술한 실시예들에 따른 동작은 실시예들 따른 송신 장치 및/또는 수신 장치에 의해서 수행될 수 있다. 송수신 장치는 미디어 데이터를 송수신하는 송수신부, 실시예들에 따른 프로세스에 대한 인스트럭션(프로그램 코드, 알고리즘, flowchart 및/또는 데이터)을 저장하는 메모리, 송/수신 장치의 동작들을 제어하는 프로세서를 포함할 수 있다.
프로세서는 컨트롤러 등으로 지칭될 수 있고, 예를 들어, 하드웨어, 소프트웨어, 및/또는 그것들의 조합에 대응할 수 있다. 상술한 실시예들에 따른 동작은 프로세서에 의해 수행될 수 있다. 또한, 프로세서는 상술한 실시예들의 동작을 위한 인코더/디코더 등으로 구현될 수 있다.
발명의 실시를 위한 최선의 형태에서 구체적으로 설명되었다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.

Claims (15)

  1. 미디어 데이터를 생성하는 단계;
    상기 미디어 데이터에 관한 서비스 리스트를 생성하는 단계; 및
    상기 미디어 데이터 및 상기 서비스 리스트를 네트워크에 기반하여 전송하는 단계; 를 포함하는,
    미디어 데이터 처리 방법.
  2. 제1항에 있어서,
    상기 네트워크는 인터넷을 포함하고,
    상기 네트워크는 지상파, 위성파, 케이블 중 적어도 하나를 더 포함하는,
    미디어 데이터 처리 방법.
  3. 제2항에 있어서,
    상기 서비스 리스트는 디스커버리하기 위한 엔트리 포인트들에 의해서 엑세스되고,
    상기 서비스 리스트는 멀티플 서비스 리스트 서버들을 위한 복수의 서비스 리스트들을 포함하는,
    미디어 데이터 처리 방법.
  4. 제3항에 있어서,
    상기 서비스 리스트는 연관 정보를 포함하고, 상기 연관 정보는 상기 미디어 데이터를 위한 텀 ID 정보를 포함하고,
    상기 텀 ID 정보가 제 1값을 가지면, 상기 제1값은 상기 서비스 리스트를 위한 로고를 나타내고,
    상기 텀 ID 정보가 제 2값을 가지면, 상기 제2값은 상기 미디어 데이터를 위한 로고를 나타내고,
    상기 텀 ID 정보가 제 3값을 가지면, 상기 제3값은 상기 미디어 데이터에 관한 장면을 나타내는 이미지를 나타내는,
    미디어 데이터 처리 방법.
  5. 제4항에 있어서,
    상기 서비스 리스트는 미디어 로케이터 정보를 포함하고, 상기 미디어 로케이터 정보는 미디어URI 정보를 포함하고, 상기 미디어URI정보에 대한 컨텐트 타입은 상기 이미지에 관한 타입 정보를 포함하고,
    상기 이미지에 관한 타입 정보는 webp 타입을 포함하고, 상기 이미지에 관한 타입 정보는 호환성을 위해서 jpeg 또는 png 타입 중 적어도 하나를 더 포함하는,
    미디어 데이터 처리 방법.
  6. 미디어 데이터를 생성하는 프로바이더; 및
    상기 미디어 데이터에 관한 서비스 리스트를 생성하는 서버; 를 포함하고,
    상기 미디어 데이터 및 상기 서비스 리스트를 네트워크에 기반하여 전송되는,
    미디어 데이터 처리 장치.
  7. 제6항에 있어서,
    상기 네트워크는 인터넷을 포함하고,
    상기 네트워크는 지상파, 위성파, 케이블 중 적어도 하나를 더 포함하는,
    미디어 데이터 처리 장치.
  8. 제7항에 있어서,
    상기 서비스 리스트는 디스커버리하기 위한 엔트리 포인트들에 의해서 엑세스되고,
    상기 서비스 리스트는 멀티플 서비스 리스트 서버들을 위한 복수의 서비스 리스트들을 포함하는,
    미디어 데이터 처리 장치.
  9. 제8항에 있어서,
    상기 서비스 리스트는 연관 정보를 포함하고, 상기 연관 정보는 상기 미디어 데이터를 위한 텀 ID 정보를 포함하고,
    상기 텀 ID 정보가 제 1값을 가지면, 상기 제1값은 상기 서비스 리스트를 위한 로고를 나타내고,
    상기 텀 ID 정보가 제 2값을 가지면, 상기 제2값은 상기 미디어 데이터를 위한 로고를 나타내고,
    상기 텀 ID 정보가 제 3값을 가지면, 상기 제3값은 상기 미디어 데이터에 관한 장면을 나타내는 이미지를 나타내는,
    미디어 데이터 처리 장치.
  10. 제9항에 있어서,
    상기 서비스 리스트는 미디어 로케이터 정보를 포함하고, 상기 미디어 로케이터 정보는 미디어URI 정보를 포함하고, 상기 미디어URI정보에 대한 컨텐트 타입은 상기 이미지에 관한 타입 정보를 포함하고,
    상기 이미지에 관한 타입 정보는 webp 타입을 포함하고, 상기 이미지에 관한 타입 정보는 호환성을 위해서 jpeg 또는 png 타입 중 적어도 하나를 더 포함하는,
    미디어 데이터 처리 장치.
  11. 네트워크에 기반하여 미디어 데이터 및 상기 미디어 데이터에 관한 서비스 리스트를 수신하는 단계; 및
    상기 서비스 리스트에 기반하여 상기 미디어 데이터를 처리하는 단계; 를 포함하는,
    미디어 데이터 처리 방법.
  12. 제11항에 있어서,
    상기 네트워크는 인터넷을 포함하고,
    상기 네트워크는 지상파, 위성파, 케이블 중 적어도 하나를 더 포함하는,
    미디어 데이터 처리 방법.
  13. 제12항에 있어서,
    상기 서비스 리스트는 디스커버리하기 위한 엔트리 포인트들에 의해서 엑세스되고,
    상기 서비스 리스트는 멀티플 서비스 리스트 서버들을 위한 복수의 서비스 리스트들을 포함하는,
    미디어 데이터 처리 방법.
  14. 제13항에 있어서,
    상기 서비스 리스트는 연관 정보를 포함하고, 상기 연관 정보는 상기 미디어 데이터를 위한 텀 ID 정보를 포함하고,
    상기 텀 ID 정보가 제 1값을 가지면, 상기 제1값은 상기 서비스 리스트를 위한 로고를 나타내고,
    상기 텀 ID 정보가 제 2값을 가지면, 상기 제2값은 상기 미디어 데이터를 위한 로고를 나타내고,
    상기 텀 ID 정보가 제 3값을 가지면, 상기 제3값은 상기 미디어 데이터에 관한 장면을 나타내는 이미지를 나타내는,
    미디어 데이터 처리 방법.
  15. 네트워크에 기반하여 미디어 데이터 및 상기 미디어 데이터에 관한 서비스 리스트를 수신하는 수신부; 및
    상기 서비스 리스트에 기반하여 상기 미디어 데이터를 처리하는 프로세서; 를 포함하는,
    미디어 데이터 처리 장치.
PCT/KR2022/008334 2021-10-13 2022-06-14 미디어 데이터 처리 방법 및 미디어 데이터 처리 장치 WO2023063524A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/700,061 US20240340484A1 (en) 2021-10-13 2022-06-14 Media data processing method and media data processing apparatus
KR1020247009213A KR20240049333A (ko) 2021-10-13 2022-06-14 미디어 데이터 처리 방법 및 미디어 데이터 처리 장치

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2021-0136049 2021-10-13
KR20210136049 2021-10-13

Publications (1)

Publication Number Publication Date
WO2023063524A1 true WO2023063524A1 (ko) 2023-04-20

Family

ID=83050019

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/008334 WO2023063524A1 (ko) 2021-10-13 2022-06-14 미디어 데이터 처리 방법 및 미디어 데이터 처리 장치

Country Status (4)

Country Link
US (1) US20240340484A1 (ko)
EP (1) EP4167578A1 (ko)
KR (1) KR20240049333A (ko)
WO (1) WO2023063524A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190068604A (ko) * 2016-11-03 2019-06-18 샤프 가부시키가이샤 방송 식별자 시그널링
KR20190077304A (ko) * 2016-11-15 2019-07-03 소니 주식회사 동일하거나 동등한 콘텐츠를 포함하는 서비스들의 식별
KR20200098537A (ko) * 2019-02-07 2020-08-20 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
KR102167869B1 (ko) * 2013-06-18 2020-10-20 삼성전자주식회사 방송 스트림 및 대안의 로케이션으로부터 방송 컨텐츠를 수신하기 위한 장치 및 방법
KR102308877B1 (ko) * 2013-07-19 2021-10-05 삼성전자주식회사 디지털 방송 수신기, 디지털 방송 수신기 제어 방법, 서버, 서버 제어 방법 및 컴퓨터 판독 가능 매체

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021177630A1 (ko) * 2020-03-05 2021-09-10 엘지전자 주식회사 미디어 처리 장치 및 미디어 처리 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102167869B1 (ko) * 2013-06-18 2020-10-20 삼성전자주식회사 방송 스트림 및 대안의 로케이션으로부터 방송 컨텐츠를 수신하기 위한 장치 및 방법
KR102308877B1 (ko) * 2013-07-19 2021-10-05 삼성전자주식회사 디지털 방송 수신기, 디지털 방송 수신기 제어 방법, 서버, 서버 제어 방법 및 컴퓨터 판독 가능 매체
KR20190068604A (ko) * 2016-11-03 2019-06-18 샤프 가부시키가이샤 방송 식별자 시그널링
KR20190077304A (ko) * 2016-11-15 2019-07-03 소니 주식회사 동일하거나 동등한 콘텐츠를 포함하는 서비스들의 식별
KR20200098537A (ko) * 2019-02-07 2020-08-20 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치

Also Published As

Publication number Publication date
US20240340484A1 (en) 2024-10-10
EP4167578A1 (en) 2023-04-19
KR20240049333A (ko) 2024-04-16

Similar Documents

Publication Publication Date Title
WO2022191563A1 (ko) 미디어 데이터 처리 방법 및 미디어 데이터 처리 장치
WO2013058633A1 (ko) 방송 서비스 수신 방법 및 방송 서비스 수신 장치
WO2020162712A1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2014062018A1 (en) Apparatus and method for processing an interactive service
WO2013022309A1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
WO2015122747A1 (en) Apparatus for processing a hybrid broadcast service, and method for processing a hybrid broadcast service
WO2012023789A2 (ko) 디지털 방송 신호 수신 장치 및 방법
WO2014084570A1 (en) Apparatus and method for processing an interactive service
WO2012161535A2 (ko) 방송 서비스 전송 방법, 그 수신 장치 및 그 수신 장치의 부가 서비스 처리 방법
WO2012144867A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2016153326A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016093586A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2014030924A1 (en) Apparatus and method for processing an interactive service
WO2016089095A1 (ko) 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016122267A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2012173441A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
WO2015156625A1 (ko) 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
WO2011034283A1 (en) Method of processing epg metadata in network device and the network device for controlling the same
WO2012169779A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2016163772A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016171518A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016003137A1 (ko) 방송 수신 장치, 방송 수신 장치의 동작 방법, 방송 수신 장치와 연동하는 연동 장치 및 연동 장치의 동작 방법
WO2016036077A1 (ko) 방송 수신 장치, 방송 수신 장치의 동작 방법, 방송 수신 장치와 연동하는 연동 장치 및 연동 장치의 동작 방법
WO2012111979A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2016108606A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22881155

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20247009213

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22881155

Country of ref document: EP

Kind code of ref document: A1