WO2015130022A1 - 디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법 - Google Patents

디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법 Download PDF

Info

Publication number
WO2015130022A1
WO2015130022A1 PCT/KR2015/001087 KR2015001087W WO2015130022A1 WO 2015130022 A1 WO2015130022 A1 WO 2015130022A1 KR 2015001087 W KR2015001087 W KR 2015001087W WO 2015130022 A1 WO2015130022 A1 WO 2015130022A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
resource
pipeline
service
message
Prior art date
Application number
PCT/KR2015/001087
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
Priority claimed from KR1020140131938A external-priority patent/KR102225946B1/ko
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to US15/121,867 priority Critical patent/US9813766B2/en
Publication of WO2015130022A1 publication Critical patent/WO2015130022A1/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/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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H04N21/41265—The peripheral being portable, e.g. PDAs or mobile phones having a remote control device for bidirectional communication between the remote control device and client device
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4433—Implementing client middleware, e.g. Multimedia Home Platform [MHP]
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream

Definitions

  • the present invention relates to digital devices, and more particularly, to data processing such as video / application in a digital device equipped with a Web OS platform.
  • PIP picture in picture
  • the present invention has been made to solve the above situation or problem, and an object of the present invention is to provide a device and a method for processing data such as a service, an application, and a video on a webOS.
  • Another object of the present invention is to provide a run-time view, resource management, policy management, etc. required for processing data such as services, applications, videos, and the like on a webOS. It is.
  • Still another object of the present invention is to provide a PIP (Picture in Picture) or an app on app in a digital device equipped with a web OS.
  • PIP Picture in Picture
  • Yet another object of the present invention is to handle multi-tasking in a webOS even when a plurality of applications are in the foreground.
  • Still another object of the present invention is to provide convenience for a WebOS user and improve product satisfaction through the above processing process.
  • Another object of the present invention is to improve the user's satisfaction through the multi-tasking process through the PIP or App-on-App as described above.
  • each of the web kits of the first application and the second application may include a first lifecycle message, a second lifecycle message, and the second application.
  • a display processing unit which transmits coordinate information about the size and position in the display of the application;
  • a display engine including a main sink for the first application and a sub sink for the second application; And connecting the first application to the main sink of the display engine according to the identifier and the connect request received from the web kit of the first application, and generating the first application according to the identifier and connect request received from the web kit of the second application.
  • a video processor for connecting an application to a sub-sync of the display engine outputs video sources of a plurality of applications in the foreground.
  • the first processor and the second lifecycle message and each web kit of the first and second applications in the display processor respectively Transmitting a lifecycle message and coordinate information about the size and position in the display of the second application; Requesting a display engine and a connection to the video processor based on the identifier received from the web kit of the first application; Connecting the first application to a main sink of a display engine; Making a request to the video processing unit for a connection based on the identifier received from the web kit of the second application; Coupling the second application to a sub sink of the display engine; Transmitting coordinate information received from the web kit of the second application to the sub sink; And outputting video sources of a plurality of applications in the foreground.
  • a device and a method for processing data may be provided on a webOS.
  • FIG. 1 is a view for schematically illustrating a service system including a digital device according to an embodiment of the present invention
  • FIG. 2 is a block diagram illustrating a digital device according to one embodiment of the present invention.
  • FIG. 3 is a block diagram illustrating a digital device according to another embodiment of the present invention.
  • FIG. 4 is a block diagram illustrating a digital device according to another embodiment of the present invention.
  • FIG. 5 is a block diagram illustrating a detailed configuration of the controller of FIGS. 2 to 4 according to one embodiment of the present invention
  • FIG. 6 illustrates input means coupled with the digital device of FIGS. 2-4 according to one embodiment of the invention
  • FIG. 7 is a diagram illustrating a WebOS architecture according to an embodiment of the present invention.
  • FIG. 8 is a view for explaining the architecture of a WebOS device according to an embodiment of the present invention.
  • FIG. 9 is a diagram for explaining a graphic composition flow in a webOS device according to one embodiment of the present invention.
  • FIG. 10 is a diagram illustrating a media server according to one embodiment of the present invention.
  • FIG. 11 is a block diagram illustrating a configuration of a media server according to one embodiment of the present invention.
  • FIG. 12 is a diagram illustrating a relationship between a media server and a TV service according to an embodiment of the present invention
  • FIG. 13 is a diagram illustrating an interfacing method between an application and media services according to one embodiment of the present invention.
  • 15 through 19 illustrate a run-time view between an application and a media service according to an embodiment of the present invention
  • 20 to 23 illustrate a run-time view between an application and a TV service according to an embodiment of the present invention
  • FIG. 26 is a diagram illustrating a pipeline structure according to an embodiment of the present invention.
  • FIG. 27 is a diagram illustrating a pipeline type according to one embodiment of the present invention.
  • 29 is a diagram illustrating a relationship between a pipeline and a resource manager according to an embodiment of the present invention.
  • FIG. 30 is a diagram illustrating a configuration for recording simultaneously with watching as a TV service according to an embodiment of the present invention
  • FIG. 31 is a diagram illustrating a configuration for recording simultaneously with watching a TV service according to another embodiment of the present invention.
  • FIG. 34 is a view illustrating a relationship between internal components of a channel change case according to an embodiment of the present invention.
  • 35 is a sequence diagram illustrating a viewing pipeline call sequence according to an embodiment of the present invention.
  • 36 is a sequence diagram illustrating a media pipeline call sequence according to an embodiment of the present invention.
  • 37 to 41 are diagrams for explaining a resource configuration file according to an embodiment of the present invention.
  • FIG. 50 is a view illustrating a service restructuring according to an embodiment of the present invention.
  • FIG. 51 is a view illustrating a service restructuring according to another embodiment of the present invention.
  • FIG. 52 is a view illustrating a policy management according to an embodiment of the present invention.
  • 53 is a view illustrating a policy management according to another embodiment of the present invention.
  • 54 to 57 illustrate a policy management between a TV service and a media pipeline according to an embodiment of the present invention.
  • FIG. 58 is a diagram illustrating a policy scenario between TV pipelines according to an embodiment of the present invention.
  • 59 to 60 are diagrams for explaining a policy scenario between a TV pipeline and a media pipeline according to an embodiment of the present invention.
  • 61 to 62 are diagrams for explaining a policy scenario between a TV pipeline and a media pipeline according to another embodiment of the present invention.
  • FIG. 63 is a view illustrating a VSM according to an embodiment of the present invention.
  • 64 is a diagram for explaining the concept of source and sink in relation to video processing according to an embodiment of the present invention.
  • FIG. 65 is a diagram illustrating controlling video input in an input stack and a rendering stack according to an embodiment of the present invention.
  • 66 to 69 are diagrams for explaining sequence diagrams for various scenarios occurring in a web application according to one embodiment of the present invention.
  • 70 is a diagram illustrating a PIP issue according to an embodiment of the present invention.
  • FIG. 71 is a diagram to describe a PIP scenario when there are two applications in the foreground
  • FIG. 76 is a diagram to describe audio processing when there is a PIP issue according to an embodiment of the present invention.
  • 77 through 84 illustrate a PIP window transition for video according to an embodiment of the present invention
  • 89 is a flowchart illustrating a PIP processing method according to an embodiment of the present invention.
  • the term “digital device” described herein refers to at least one of transmitting, receiving, processing, and outputting data such as content, service, application, and the like. Includes all devices that perform.
  • the digital device may be paired or connected (hereinafter referred to as 'pairing') with another digital device, an external server, or the like through a wired / wireless network, and transmits predetermined data therethrough. Can send / receive At this time, if necessary, the data may be appropriately converted (converted) before the transmission / reception.
  • the digital device includes, for example, a standing device such as a network television (TV), a hybrid broadcast broadband TV (HBBTV), a smart television (TV), an internet protocol television (IPTV), a personal computer (PC), or the like.
  • a mobile device such as a PDA (Personal Digital Assistant), smart phone (Smart Phone), tablet PC (Tablet PC), notebook (notebook) and the like can all include.
  • a digital TV is illustrated in FIG. 2 and a mobile device is illustrated in FIG. 3, which will be described later to help the understanding of the present invention and for convenience of the applicant.
  • the digital device described herein may be a configuration having only a panel, or may be a set configuration such as a set-top box (STB), a device, a system, and the like. .
  • STB set-top box
  • wired / wireless network refers to a communication network supporting various communication standards or protocols for pairing and / or transmitting and receiving data between digital devices or digital devices and external servers.
  • wired / wireless networks include all communication networks that are currently or will be supported by the specification and are capable of supporting one or more communication protocols for them.
  • Such wired and wireless networks include, for example, Universal Serial Bus (USB), Composite Video Banking Sync (CVBS), Component, S-Video (Analog), Digital Visual Interface (DVI), High Definition Multimedia Interface (HDMI), Network for wired connection such as RGB, D-SUB and communication standard or protocol therefor, Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), Zigbee (ZigBee), Digital Living Network Alliance (DLNA), Wireless LAN (WLAN) (Wi-Fi), Wireless broadband (Wibro), World Interoperability for Microwave Access (Wimax), High Speed Downlink Packet Access (HSDPA), LTE / LTE It may be formed by a network for a wireless connection such as Long Term Evolution / LTE-Advanced (A), Wi-Fi Direct, and a communication standard or protocol therefor.
  • RFID Radio Frequency Identification
  • IrDA Infrared Data Association
  • UWB Ultra Wideband
  • the meaning when referred to herein only as a digital device, the meaning may mean a fixed device or a mobile device depending on the context, and may be used to include both unless specifically mentioned.
  • the digital device is, for example, an intelligent device that supports a broadcast reception function, a computer function or support, at least one external input, and the like, and includes e-mail and web browsing through the aforementioned wired / wireless network. (web browsing, banking, games, applications, etc.)
  • the digital device may include an interface for supporting at least one input or control means (hereinafter, “input means”) such as a handwritten input device, a touch-screen, and a spatial remote controller. Can be.
  • the digital device may use a standardized general-purpose operating system (OS).
  • OS general-purpose operating system
  • the digital device described in this specification can use a WebOS (WebOS) platform. Accordingly, digital devices can add, delete, modify, and update various services or applications on a general-purpose OS kernel or Linux kernel. It is possible, through which a more user-friendly environment can be constructed and provided.
  • WebOS WebOS
  • the above-described digital device may receive and process an external input, wherein the external input is connected to an external input device, that is, the digital device through a wired / wireless network and transmits / receives data to process all of the external inputs.
  • Input means to digital device.
  • a game device such as a high-definition multimedia interface (HDMI), a playstation or an X-box, a smartphone, a tablet PC, a pocket photo, etc. may be used as the external input.
  • digital devices such as printing devices, smart TVs, Blu-ray device devices, and the like.
  • server refers to a digital device or system for supplying data to or receiving data from the above-mentioned digital device, that is, a client, and also referred to as a processor. do.
  • a portal server for providing a web page, a web content or a web service
  • an advertising server for providing advertising data
  • Providing a content server providing content an SNS server providing a social network service (SNS), a service server provided by a manufacturer, and providing a video on demand (VOD) or streaming service
  • SNS social network service
  • VOD video on demand
  • It may include a multi-channel video programming distributor (MVDP), a service server for providing a pay service, and the like.
  • MVDP multi-channel video programming distributor
  • the meaning may be a meaning including not only an application but also a service based on the context.
  • FIG. 1 is a diagram schematically illustrating a service system including a digital device according to an embodiment of the present invention.
  • the service system includes a content provider 10, a service provider 20, a network provider 30, and a home network end user (HNED). (Customer) 40.
  • the HNED 40 comprises, for example, a client 100, ie a digital device according to the invention.
  • the content provider 10 produces and provides various contents. As shown in FIG. 1, such a content provider 10 includes a terrestrial broadcast sender, a cable SO (System Operator) or MSO (Multiple SO), a satellite broadcast sender, various Internet broadcast senders, Personal content providers and the like.
  • the content provider 10 may produce and provide various services or applications in addition to broadcast content.
  • the service provider 20 service packetizes the content produced by the content provider 10 and provides it to the HNED 40.
  • the service provider 20 packages at least one or more of contents produced by the first terrestrial broadcast, the second terrestrial broadcast, the cable MSO, satellite broadcast, various Internet broadcasts, applications, and the like for the service, and HNED. Provide 40.
  • the service provider 20 provides a service to the client 100 in a uni-cast or multi-cast manner. Meanwhile, the service provider 20 may transmit data to a plurality of clients 100 registered in advance. For this, the service provider 20 may use an Internet Group Management Protocol (IGMP) protocol.
  • IGMP Internet Group Management Protocol
  • the content provider 10 and the service provider 20 described above may be the same entity.
  • the content produced by the content provider 10 may be packaged as a service and provided to the HNED 40 to perform the functions of the service provider 20 together or vice versa.
  • the network provider 30 provides a network for data exchange between the content provider 10 or / and the service provider 20 and the client 100.
  • the client 100 is a consumer belonging to the HNED 40, and for example, establishes a home network through the network provider 30 to receive data, and receives data about various services or applications such as VoD and streaming. You can also send / receive.
  • the content provider 10 and / or the service provider 20 in the service system may use conditional access or content protection means to protect the transmitted content.
  • the client 100 may use a processing means such as a cable card (or point of deployment) or a downloadable casing (DCAS) in response to the limited reception or content protection.
  • a processing means such as a cable card (or point of deployment) or a downloadable casing (DCAS) in response to the limited reception or content protection.
  • the client 100 may also use a bidirectional service through a network. Accordingly, the client 100 may perform a role or function of the content provider, and the service provider 20 may receive it and transmit it to another client.
  • the content provider 10 and / or the service provider 20 may be a server that provides a service described later herein.
  • the server may mean to own or include the network provider 30 as necessary.
  • the service or service data includes not only services or applications received from the outside described above but also internal services or applications, and these services or applications are services for the client 100 based on Web OS (Web OS). To application data.
  • Web OS Web OS
  • FIG. 2 is a block diagram illustrating a digital device according to an embodiment of the present invention.
  • the digital device described herein corresponds to the client 100 of FIG. 1.
  • the digital device 200 includes a network interface 201, a TCP / IP manager 202, a service delivery manager 203, an SI decoder 204, A demux or demultiplexer 205, an audio decoder 206, a video decoder 207, a display A / V and OSD module 208, a service control manager (service control manager) 209, service discovery manager 210, SI & metadata DB 211, metadata manager 212, service manager 213, And a UI manager 214.
  • a network interface 201 includes a network interface 201, a TCP / IP manager 202, a service delivery manager 203, an SI decoder 204, A demux or demultiplexer 205, an audio decoder 206, a video decoder 207, a display A / V and OSD module 208, a service control manager (service control manager) 209, service discovery manager 210, SI & metadata DB 211, metadata manager 212, service manager 213, And a UI
  • the network interface unit 201 may be configured to perform IP packet (s) (Internet Protocol (IP) packet (s)) or IP datagram (s) (IP datagram (s)) (hereinafter referred to as IP packet (s) through a network to access. Send / receive)
  • IP packet Internet Protocol
  • IP datagram IP datagram
  • the network interface unit 201 may receive a service, an application, content, and the like from the service provider 20 of FIG. 1 through a network.
  • the TCP / IP manager 202 may be configured to transfer packets between the source and the destination for IP packets received by the digital device 200 and IP packets transmitted by the digital device 200. involved in packet delivery).
  • the TCP / IP manager 202 classifies the received packet (s) to correspond to an appropriate protocol, and includes a service delivery manager 205, a service discovery manager 210, a service control manager 209, and a metadata manager 212. Output the classified packet (s).
  • the service delivery manager 203 is in charge of controlling the received service data.
  • the service delivery manager 203 may use RTP / RTCP when controlling real-time streaming data.
  • the service delivery manager 203 parses the received data packet according to the RTP and transmits it to the demultiplexer 205 or the control of the service manager 213.
  • the service delivery manager 203 feeds back the network reception information to a server that provides a service using RTCP.
  • the demultiplexer 205 demultiplexes the received packet into audio, video, SI (System Information) data, and the like, and transmits the demultiplexed unit to the audio / video decoders 206/207 and the SI decoder 204, respectively.
  • SI System Information
  • the SI decoder 204 includes demultiplexed SI data, that is, Program Specific Information (PSI), Program and System Information Protocol (PSIP), Digital Video Broadcasting-Service Information (DVB-SI), and Digital Television Terrestrial Multimedia (DTMB / CMMB). Decode service information such as Broadcasting / Coding Mobile Multimedia Broadcasting).
  • the SI decoder 204 may store the decoded service information in the SI & metadata database 211. The stored service information may be read and used by the corresponding configuration, for example, at the request of a user.
  • the audio / video decoder 206/207 decodes each demultiplexed audio data and video data.
  • the decoded audio data and video data are provided to the user through the display unit 208.
  • the application manager may include, for example, the UI manager 214 and the service manager 213 and perform a control function of the digital device 200.
  • the application manager may manage the overall state of the digital device 200, provide a user interface (UI), and manage other managers.
  • UI user interface
  • the UI manager 214 provides a Graphic User Interface (UI) / UI for a user using an OSD (On Screen Display), etc., and receives a key input from the user to perform a device operation according to the input. For example, the UI manager 214 transmits the key input signal to the service manager 213 when receiving a key input related to channel selection from the user.
  • UI Graphic User Interface
  • OSD On Screen Display
  • the service manager 213 controls a manager associated with a service such as a service delivery manager 203, a service discovery manager 210, a service control manager 209, and a metadata manager 212.
  • the service manager 213 generates a channel map and controls the channel selection using the generated channel map according to the key input received from the UI manager 214.
  • the service manager 213 receives service information from the SI decoder 204 and sets the audio / video packet identifier (PID) of the selected channel to the demultiplexer 205.
  • PID audio / video packet identifier
  • the PID set as described above may be used in the above demultiplexing process. Accordingly, the demultiplexer 205 filters (PID or section filtering) audio data, video data, and SI data by using the PID.
  • the service discovery manager 210 provides information necessary for selecting a service provider that provides a service. Upon receiving a signal regarding channel selection from the service manager 213, the service discovery manager 210 searches for a service using the information.
  • the service control manager 209 is responsible for selecting and controlling services.
  • the service control manager 209 uses IGMP or RTSP when the user selects a live broadcasting service such as a conventional broadcasting method, and selects a service such as VOD (Video on Demand).
  • the RTSP is used to perform service selection and control.
  • the RTSP protocol may provide a trick mode for real time streaming.
  • the service control manager 209 may initialize and manage a session through the IMS gateway 250 using an IP Multimedia Subsystem (IMS) or a Session Initiation Protocol (SIP).
  • IMS IP Multimedia Subsystem
  • SIP Session Initiation Protocol
  • the protocols are one embodiment, and other protocols may be used depending on implementation.
  • the metadata manager 212 manages metadata associated with the service and stores the metadata in the SI & metadata database 211.
  • the SI & metadata database 211 stores service information decoded by the SI decoder 204, metadata managed by the metadata manager 212, and information necessary to select a service provider provided by the service discovery manager 210. Save it.
  • the SI & metadata database 211 can store set-up data and the like for the system.
  • the SI & metadata database 211 may be implemented using non-volatile memory (NVRAM), flash memory, or the like.
  • NVRAM non-volatile memory
  • the IMS gateway 250 is a gateway that collects functions necessary for accessing an IMS-based IPTV service.
  • FIG. 3 is a block diagram illustrating a digital device according to another embodiment of the present invention.
  • Figure 3 is a mobile device to another embodiment of the digital device.
  • the mobile device 300 may include a wireless communication unit 310, an A / V input unit 320, a user input unit 330, a sensing unit 340, an output unit 350,
  • the memory 360 may include an interface unit 370, a controller 380, a power supply unit 390, and the like.
  • the wireless communication unit 310 may include one or more modules that enable wireless communication between the mobile device 300 and the wireless communication system or between the mobile device and the network in which the mobile device is located.
  • the wireless communication unit 310 may include a broadcast receiving module 311, a mobile communication module 312, a wireless internet module 313, a short range communication module 314, a location information module 315, and the like. .
  • the broadcast receiving module 311 receives a broadcast signal and / or broadcast related information from an external broadcast management server through a broadcast channel.
  • the broadcast channel may include a satellite channel and a terrestrial channel.
  • the broadcast management server may mean a server that generates and transmits a broadcast signal and / or broadcast related information or a server that receives a previously generated broadcast signal and / or broadcast related information and transmits the same to a terminal.
  • the broadcast signal may include not only a TV broadcast signal, a radio broadcast signal, and a data broadcast signal, but also a broadcast signal having a data broadcast signal combined with a TV broadcast signal or a radio broadcast signal.
  • the broadcast related information may mean information related to a broadcast channel, a broadcast program, or a broadcast service provider.
  • the broadcast related information may also be provided through a mobile communication network. In this case, it may be received by the mobile communication module 312.
  • the broadcast related information may exist in various forms, for example, in the form of an electronic program guide (EPG) or an electronic service guide (ESG).
  • EPG electronic program guide
  • ESG electronic service guide
  • the broadcast receiving module 311 may be, for example, ATSC, DVB-T (Digital Video Broadcasting-Terrestrial), DVB-S (Satellite), MediaFLO (Media Forward Link Only), DVB-H (Handheld), ISDB-T ( Digital broadcasting signals can be received using digital broadcasting systems such as Integrated Services Digital Broadcast-Terrestrial) and DTMB / CMMB for China.
  • the broadcast receiving module 311 may be configured to be suitable for not only the above-described digital broadcasting system but also other broadcasting systems.
  • the broadcast signal and / or broadcast related information received through the broadcast receiving module 311 may be stored in the memory 360.
  • the mobile communication module 312 transmits and receives a radio signal with at least one of a base station, an external terminal, and a server on a mobile communication network.
  • the wireless signal may include various types of data according to transmission and reception of a voice signal, a video call signal, or a text / multimedia message.
  • the wireless internet module 313 may include a module for wireless internet access and may be embedded or external to the mobile device 300.
  • Wireless Internet technologies may include Wireless LAN (Wi-Fi), Wireless Broadband (Wibro), World Interoperability for Microwave Access (Wimax), High Speed Downlink Packet Access (HSDPA), and the like.
  • the short range communication module 314 refers to a module for short range communication.
  • Short range communication technologies include Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), ZigBee, RS-232, and RS-485. Can be.
  • the location information module 315 may be a module for acquiring location information of the mobile device 300, and may use a Global Position System (GPS) module as an example.
  • GPS Global Position System
  • the A / V input unit 320 is for inputting audio or video signals, and may include a camera 321 and a microphone 322.
  • the camera 321 processes image frames such as still images or moving images obtained by the image sensor in the video call mode or the imaging mode.
  • the processed image frame may be displayed on the display unit 351.
  • the image frame processed by the camera 321 may be stored in the memory 360 or transmitted to the outside through the wireless communication unit 310. Two or more cameras 321 may be provided depending on the use environment.
  • the microphone 322 receives an external sound signal by a microphone in a call mode, a recording mode, a voice recognition mode, etc., and processes the external sound signal into electrical voice data.
  • the processed voice data may be converted into a form transmittable to the mobile communication base station through the mobile communication module 312 and output in the call mode.
  • the microphone 322 may be implemented with various noise removing algorithms for removing noise generated in the process of receiving an external sound signal.
  • the user input unit 330 generates input data for the user to control the operation of the terminal.
  • the user input unit 330 may include a key pad, a dome switch, a touch pad (static pressure / capacitance), a jog wheel, a jog switch, and the like.
  • the sensing unit 340 may determine the current state of the mobile device 300 such as an open / closed state of the mobile device 300, a location of the mobile device 300, presence or absence of user contact, orientation of the mobile device, acceleration / deceleration of the mobile device, and the like.
  • the sensing unit generates a sensing signal for controlling the operation of the mobile device 300. For example, when the mobile device 300 is moved or tilted, the position or tilt of the mobile device may be sensed. Also, whether the power supply unit 390 is supplied with power or whether the interface unit 370 is coupled to an external device may be sensed.
  • the sensing unit 240 may include a proximity sensor 341 including near field communication (NFC).
  • the output unit 350 is to generate an output related to visual, auditory or tactile senses, and may include a display unit 351, a sound output module 352, an alarm unit 353, a haptic module 354, and the like. have.
  • the display unit 351 displays (outputs) information processed by the mobile device 300. For example, when the mobile device is in the call mode, the UI or GUI related to the call is displayed. When the mobile device 300 is in a video call mode or a photographing mode, the mobile device 300 displays a photographed and / or received image, a UI, or a GUI.
  • the display unit 351 may include a liquid crystal display (LCD), a thin film transistor-liquid crystal display (TFT LCD), an organic light-emitting diode (OLED), a flexible display ( flexible display) and three-dimensional display.
  • LCD liquid crystal display
  • TFT LCD thin film transistor-liquid crystal display
  • OLED organic light-emitting diode
  • flexible display flexible display
  • three-dimensional display three-dimensional display.
  • Some of these displays can be configured to be transparent or light transmissive so that they can be seen from the outside. This may be referred to as a transparent display.
  • a representative example of the transparent display is TOLED (Transparant OLED).
  • the rear structure of the display unit 351 may also be configured as a light transmissive structure. With this structure, the user can see the object located behind the terminal body through the area occupied by the display unit 351 of the terminal body.
  • two or more display units 351 may exist.
  • a plurality of display units may be spaced apart or integrally disposed on one surface of the mobile device 300, or may be disposed on different surfaces.
  • the display unit 351 and a sensor for detecting a touch operation form a mutual layer structure (hereinafter referred to as a touch screen)
  • the display unit 351 may input other than an output device. It can also be used as a device.
  • the touch sensor may have, for example, a form of a touch film, a touch sheet, a touch pad, or the like.
  • the touch sensor may be configured to convert a change in pressure applied to a specific portion of the display unit 351 or capacitance generated at a specific portion of the display unit 351 into an electrical input signal.
  • the touch sensor may be configured to detect not only the position and area of the touch but also the pressure at the touch.
  • the corresponding signal (s) is sent to the touch controller.
  • the touch controller processes the signal (s) and then transmits the corresponding data to the controller 380.
  • the controller 380 may determine which area of the display unit 351 is touched.
  • the proximity sensor 341 may be disposed in an inner region of the mobile device surrounded by the touch screen or near the touch screen.
  • the proximity sensor refers to a sensor that detects the presence or absence of an object approaching a predetermined detection surface or an object present in the vicinity without using a mechanical contact by using an electromagnetic force or infrared rays.
  • Proximity sensors have a longer life and higher utilization than touch sensors.
  • the proximity sensor examples include a transmission photoelectric sensor, a direct reflection photoelectric sensor, a mirror reflection photoelectric sensor, a high frequency oscillation proximity sensor, a capacitive proximity sensor, a magnetic proximity sensor, and an infrared proximity sensor.
  • the touch screen is capacitive, the touch screen is configured to detect the proximity of the pointer by the change of the electric field according to the proximity of the pointer.
  • the touch screen may be classified as a proximity sensor.
  • the act of allowing the pointer to be recognized without being in contact with the touch screen so that the pointer is located on the touch screen is referred to as a "proximity touch", and the touch
  • the act of actually touching the pointer on the screen is called “contact touch.”
  • the position where the proximity touch is performed by the pointer on the touch screen refers to a position where the pointer is perpendicular to the touch screen when the pointer is in proximity proximity.
  • the proximity sensor detects a proximity touch and a proximity touch pattern (for example, a proximity touch distance, a proximity touch direction, a proximity touch speed, a proximity touch time, a proximity touch position, and a proximity touch movement state).
  • a proximity touch and a proximity touch pattern for example, a proximity touch distance, a proximity touch direction, a proximity touch speed, a proximity touch time, a proximity touch position, and a proximity touch movement state.
  • Information corresponding to the sensed proximity touch operation and proximity touch pattern may be output on the touch screen.
  • the sound output module 352 may output audio data received from the wireless communication unit 310 or stored in the memory 360 in a call signal reception, a call mode or a recording mode, a voice recognition mode, a broadcast reception mode, and the like.
  • the sound output module 352 may output a sound signal related to a function (eg, a call signal reception sound, a message reception sound, etc.) performed by the mobile device 300.
  • the sound output module 352 may include a receiver, a speaker, a buzzer, and the like.
  • the alarm unit 353 outputs a signal for notifying occurrence of an event of the mobile device 300. Examples of events occurring in the mobile device include call signal reception, message reception, key signal input, and touch input.
  • the alarm unit 353 may output a signal for notifying the occurrence of an event by vibration, in addition to a video signal or an audio signal.
  • the video signal or the audio signal may also be output through the display unit 351 or the audio output module 352, so that they 351 and 352 may be classified as part of the alarm unit 353.
  • the haptic module 354 generates various tactile effects that a user can feel. Vibration is a representative example of the haptic effect generated by the haptic module 354.
  • the intensity and pattern of vibration generated by the haptic module 354 can be controlled. For example, different vibrations may be synthesized and output or may be sequentially output.
  • the haptic module 354 may be configured to provide a pin array that vertically moves with respect to the contact skin surface, a jetting force or suction force of air through the jetting or suction port, grazing to the skin surface, contact of the electrode, electrostatic force, and the like.
  • Various tactile effects can be generated, such as effects due to the effects of cold / warm reproduction using an element that can absorb heat or generate heat.
  • the haptic module 354 may not only deliver the haptic effect through direct contact, but also may implement the user to feel the haptic effect through muscle sensation such as a finger or an arm.
  • the haptic module 354 may be provided with two or more according to the configuration aspect of the mobile device 300.
  • the memory 360 may store a program for the operation of the controller 380 and may temporarily store input / output data (for example, a phone book, a message, a still image, a video, etc.).
  • the memory 360 may store data regarding vibration and sound of various patterns output when a touch input is input on the touch screen.
  • the memory 360 may include a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (for example, SD or XD memory), Random Access Memory (RAM), Static Random Access Memory (SRAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Programmable Read-Only Memory (PROM), Magnetic Memory, It may include a storage medium of at least one type of magnetic disk, optical disk.
  • the mobile device 300 may operate in association with web storage that performs a storage function of the memory 360 on the Internet.
  • the interface unit 370 serves as a path to all external devices connected to the mobile device 300.
  • the interface unit 370 receives data from an external device, receives power, transfers the power to each component inside the mobile device 300, or transmits data within the mobile device 300 to the external device.
  • wired / wireless headset port, external charger port, wired / wireless data port, memory card port, port for connecting a device with an identification module, audio input / output (I / O) port, The video I / O port, the earphone port, and the like may be included in the interface unit 370.
  • the identification module is a chip that stores various types of information for authenticating the usage rights of the mobile device 300, and includes a user identification module (UIM), a subscriber identification module (SIM), and a universal user authentication module (UI). Universal Subscriber Identity Module (USIM), and the like.
  • a device equipped with an identification module (hereinafter referred to as an “identification device”) may be manufactured in the form of a smart card. Therefore, the identification device may be connected to the terminal 200 through a port.
  • the interface unit 370 may be a path through which power from the cradle is supplied to the mobile device 300 or may be input by the user from the cradle. It may be a passage through which a command signal is transmitted to the mobile device. Various command signals or power input from the cradle may be operated as signals for recognizing that the mobile device is correctly mounted in the cradle.
  • the controller 380 typically controls the overall operation of the mobile device 300.
  • the controller 380 performs, for example, related control and processing for voice call, data communication, video call, and the like.
  • the controller 380 may include a multimedia module 381 for multimedia playback.
  • the multimedia module 381 may be implemented in the controller 380 or may be implemented separately from the controller 380.
  • the controller 380 may perform a pattern recognition process for recognizing a writing input or a drawing input performed on a touch-screen as a character and an image, respectively.
  • the power supply unit 390 receives an external power source and an internal power source under the control of the controller 380 to supply power for operation of each component.
  • Various embodiments described herein may be implemented in a recording medium readable by a computer or similar device using, for example, software, hardware or a combination thereof.
  • the embodiments described herein include application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), and the like. It may be implemented using at least one of a processor, a controller, micro-controllers, microprocessors, and other electrical units for performing other functions. Examples may be implemented by the controller 380 itself.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • embodiments such as the procedures and functions described herein may be implemented as separate software modules.
  • Each of the software modules may perform one or more functions and operations described herein.
  • Software code may be implemented in software applications written in a suitable programming language.
  • the software code may be stored in the memory 360 and executed by the controller 380.
  • FIG. 4 is a block diagram illustrating a digital device according to another embodiment of the present invention.
  • the digital device 400 include a broadcast receiver 405, an external device interface 435, a storage 440, a user input interface 450, a controller 470, a display 480, and audio. It may include an output unit 485, a power supply unit 490 and a photographing unit (not shown).
  • the broadcast receiver 405 may include at least one tuner 410, a demodulator 420, and a network interface unit 430. However, in some cases, the broadcast receiver 405 may include a tuner 410 and a demodulator 420, but may not include the network interface 430, or vice versa.
  • the broadcast receiver 405 includes a multiplexer and a signal demodulated by the demodulator 420 via the tuner 410 and a signal received through the network interface 430. You can also multiplex.
  • the broadcast receiving unit 425 may include a demultiplexer to demultiplex the multiplexed signal or to demultiplex the demodulated signal or the signal passed through the network interface unit 430. Can be.
  • the tuner 410 receives an RF broadcast signal by tuning a channel selected by a user or all previously stored channels among radio frequency (RF) broadcast signals received through an antenna.
  • the tuner 410 also converts the received RF broadcast signal into an intermediate frequency (IF) signal or a baseband signal.
  • IF intermediate frequency
  • the received RF broadcast signal is a digital broadcast signal
  • it is converted into a digital IF signal (DIF).
  • the analog broadcast signal is converted into an analog baseband video or audio signal (CVBS / SIF). That is, the tuner 410 may process both a digital broadcast signal or an analog broadcast signal.
  • the analog baseband video or audio signal CVBS / SIF output from the tuner 410 may be directly input to the controller 470.
  • the tuner 410 may receive an RF broadcast signal of a single carrier or multiple carriers. Meanwhile, the tuner 410 sequentially tunes and receives RF broadcast signals of all broadcast channels stored through a channel memory function among RF broadcast signals received through an antenna, and then converts them to intermediate frequency signals or baseband signals (DIFs). Frequency or baseband signal).
  • DIFs baseband signals
  • the demodulator 420 may receive and demodulate the digital IF signal DIF converted by the tuner 410 and perform channel decoding.
  • the demodulator 420 includes a trellis decoder, a de-interleaver, a reed-solomon decoder, or a convolutional decoder, deinterleaver, and lead. A solo decoder or the like.
  • the demodulator 420 may output a stream signal TS after performing demodulation and channel decoding.
  • the stream signal may be a signal multiplexed with a video signal, an audio signal, or a data signal.
  • the stream signal may be an MPEG-2 Transport Stream (TS) multiplexed with an MPEG-2 standard video signal, a Dolby AC-3 standard audio signal, and the like.
  • TS MPEG-2 Transport Stream
  • the stream signal output from the demodulator 420 may be input to the controller 470.
  • the controller 470 may control demultiplexing, image / audio signal processing, and the like, control the output of the image through the display 480, and the audio output through the audio output unit 485.
  • the external device interface unit 435 provides an interfacing environment between the digital device 300 and various external devices.
  • the external device interface unit 335 may include an A / V input / output unit (not shown) or a wireless communication unit (not shown).
  • the external device interface unit 435 may include a digital versatile disk (DVD), a Blu-ray, a game device, a camera, a camcorder, a computer (laptop), a tablet PC, a smartphone, a Bluetooth device (Bluetooth). device), an external device such as a cloud, etc. may be connected via wired / wireless.
  • the external device interface unit 435 transmits a signal including data such as an image, video, and audio input through the connected external device to the controller 470 of the digital device.
  • the controller 470 may control the processed image, video, audio, and the like to output the data signal to the connected external device.
  • the external device interface unit 435 may further include an A / V input / output unit (not shown) or a wireless communication unit (not shown).
  • the A / V input / output unit may include a USB terminal, a CVBS (Composite Video Banking Sync) terminal, a component terminal, an S-video terminal (analog), so that video and audio signals of an external device can be input to the digital device 400. It may include a DVI (Digital Visual Interface) terminal, an HDMI (High Definition Multimedia Interface) terminal, an RGB terminal, a D-SUB terminal, and the like.
  • the wireless communication unit may perform short range wireless communication with another digital device.
  • the digital device 400 may include, for example, Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), ZigBee, and Digital Living Network Alliance (DLNA). It may be networked with other digital devices according to a communication protocol.
  • RFID Radio Frequency Identification
  • IrDA Infrared Data Association
  • UWB Ultra Wideband
  • ZigBee ZigBee
  • DLNA Digital Living Network Alliance
  • the external device interface unit 435 may be connected to the set top box STB through at least one of the various terminals described above to perform an input / output operation with the set top box STB.
  • the external device interface unit 435 may receive an application or an application list in an adjacent external device and transmit the received application or application list to the controller 470 or the storage unit 440.
  • the network interface unit 430 provides an interface for connecting the digital device 400 to a wired / wireless network including an internet network.
  • the network interface unit 430 may include, for example, an Ethernet terminal for connection with a wired network, and for example, a wireless LAN (WLAN) for connection with a wireless network.
  • WLAN wireless LAN
  • Fi Wibro (Wireless broadband), Wimax (World Interoperability for Microwave Access), and High Speed Downlink Packet Access (HSDPA) communication standards.
  • the network interface unit 430 may transmit or receive data with another user or another digital device through the connected network or another network linked to the connected network.
  • some content data stored in the digital device 400 may be transmitted to another user who is registered in advance in the digital device 400 or a selected user among the other digital devices or the selected digital device.
  • the network interface unit 430 may access a predetermined web page through a connected network or another network linked to the connected network. That is, by accessing a predetermined web page through the network, it is possible to send or receive data with the server. In addition, it may receive content or data provided by a content provider or a network operator. That is, content such as a movie, an advertisement, a game, a VOD, a broadcast signal, and related information provided from the content provider or the network provider may be received through the network. In addition, it is possible to receive the update information and the update file of the firmware (firmware) provided by the network operator. It may also transmit data to the Internet or content provider or network operator.
  • the network interface unit 430 may select and receive a desired application from among applications that are open through the network.
  • the storage unit 440 may store a program for processing and controlling each signal in the controller 470, or may store a signal-processed video, audio, or data signal.
  • the storage unit 440 may perform a function for temporarily storing an image, audio, or data signal input from the external device interface unit 435 or the network interface unit 430.
  • the storage unit 440 may store information about a predetermined broadcast channel through a channel storage function.
  • the storage unit 440 may store an application or an application list input from the external device interface unit 435 or the network interface unit 330.
  • the storage unit 440 may store various platforms described below.
  • the storage unit 440 may include, for example, a flash memory type, a hard disk type, a multimedia card micro type, and a card type memory (for example, SD or XD). Memory, etc.), RAM (RAM), or ROM (EEPROM, etc.) may include at least one type of storage medium.
  • the digital device 400 may reproduce and provide a content file (video file, still image file, music file, document file, application file, etc.) stored in the storage unit 440 to the user.
  • FIG. 4 illustrates an embodiment in which the storage unit 440 is provided separately from the control unit 470, but the present invention is not limited thereto. In other words, the storage unit 440 may be included in the control unit 470.
  • the user input interface unit 450 transmits a signal input by the user to the controller 470 or transmits a signal of the controller 470 to the user.
  • the user input interface unit 450 controls power on / off, channel selection, screen setting, etc. from the remote control device 500 according to various communication methods such as an RF communication method and an infrared (IR) communication method.
  • the signal may be received and processed, or the control signal of the controller 470 may be transmitted to the remote control device 500.
  • the user input interface unit 450 may transmit a control signal input from a local key (not shown), such as a power key, a channel key, a volume key, and a set value, to the controller 470.
  • a local key such as a power key, a channel key, a volume key, and a set value
  • the user input interface unit 450 may transmit a control signal input from a sensing unit (not shown) that senses a user's gesture to the controller 470, or may sense a signal of the controller 470.
  • the sensing unit may include a touch sensor, a voice sensor, a position sensor, an operation sensor, and the like.
  • the controller 470 demultiplexes the stream input through the tuner 410, the demodulator 420, or the external device interface unit 435, or processes the demultiplexed signals to generate a signal for video or audio output. And output.
  • the image signal processed by the controller 470 may be input to the display unit 480 and displayed as an image corresponding to the image signal.
  • the image signal processed by the controller 470 may be input to the external output device through the external device interface 435.
  • the audio signal processed by the controller 470 may be audio output to the audio output unit 485.
  • the voice signal processed by the controller 470 may be input to the external output device through the external device interface 435.
  • controller 470 may include a demultiplexer, an image processor, and the like.
  • the controller 470 may control overall operations of the digital device 400.
  • the controller 470 may control the tuner 410 to control tuning of an RF broadcast corresponding to a channel selected by a user or a pre-stored channel.
  • the controller 470 may control the digital device 400 by a user command or an internal program input through the user input interface 450. In particular, it is possible to connect to the network so that the user can download the desired application or application list into the digital device 400.
  • the controller 470 controls the tuner 410 to input a signal of a channel selected according to a predetermined channel selection command received through the user input interface 450. It processes the video, audio or data signal of the selected channel.
  • the controller 470 allows the channel information selected by the user to be output through the display unit 480 or the audio output unit 485 together with the processed video or audio signal.
  • the controller 470 may be provided from an external device, for example, a camera or a camcorder, input through the external device interface unit 435 according to an external device image playback command received through the user input interface unit 450.
  • the video signal or the audio signal may be output through the display unit 480 or the audio output unit 485.
  • the controller 470 may control the display 480 to display an image.
  • an image For example, a broadcast image input through the tuner 410, an external input image input through the external device interface unit 435, an image input through a network interface unit, or an image stored in the storage unit 440.
  • the display unit 480 may control the display.
  • the image displayed on the display unit 480 may be a still image or a video, and may be a 2D image or a 3D image.
  • the controller 470 may control to reproduce the content.
  • the content may be content stored in the digital device 400, received broadcast content, or external input content input from the outside.
  • the content may be at least one of a broadcast image, an external input image, an audio file, a still image, a connected web screen, and a document file.
  • the controller 470 may control to display an application or a list of applications downloadable from the digital device 300 or from an external network.
  • the controller 470 may control to install and run an application downloaded from an external network, along with various user interfaces. In addition, by selecting a user, an image related to an application to be executed may be controlled to be displayed on the display unit 480.
  • a channel browsing processor may be further provided to generate a thumbnail image corresponding to the channel signal or the external input signal.
  • the channel browsing processor receives a stream signal TS output from the demodulator 320 or a stream signal output from the external device interface 335, extracts an image from the input stream signal, and generates a thumbnail image.
  • the generated thumbnail image may be input as it is or encoded to the controller 470.
  • the generated thumbnail image may be encoded in a stream form and input to the controller 470.
  • the controller 470 may display a thumbnail list including a plurality of thumbnail images on the display unit 480 using the input thumbnail image. Meanwhile, the thumbnail images in the thumbnail list may be updated sequentially or simultaneously. Accordingly, the user can easily grasp the contents of the plurality of broadcast channels.
  • the display unit 480 converts an image signal, a data signal, an OSD signal processed by the controller 470 or an image signal, data signal, etc. received from the external device interface unit 435 into R, G, and B signals, respectively. Generate a drive signal.
  • the display unit 480 may be a PDP, an LCD, an OLED, a flexible display, a 3D display, or the like.
  • the display unit 480 may be configured as a touch screen and used as an input device in addition to the output device.
  • the audio output unit 485 receives a signal processed by the controller 470, for example, a stereo signal, a 3.1 channel signal, or a 5.1 channel signal, and outputs a voice signal.
  • the voice output unit 485 may be implemented as various types of speakers.
  • a sensing unit including at least one of a touch sensor, a voice sensor, a position sensor, and a motion sensor may be further provided in the digital device 400. .
  • the signal detected by the sensing unit may be transmitted to the control unit 3470 through the user input interface unit 450.
  • a photographing unit (not shown) for photographing the user may be further provided. Image information photographed by a photographing unit (not shown) may be input to the controller 470.
  • the controller 470 may detect a user's gesture by combining or respectively combining an image photographed by a photographing unit or a sensed signal from a sensing unit (not shown).
  • the power supply unit 490 supplies the power throughout the digital device 400.
  • controller 470 may be implemented in the form of a System on Chip (SoC), a display unit 480 for displaying an image, and an audio output unit 485 for audio output. Can be.
  • SoC System on Chip
  • display unit 480 for displaying an image
  • audio output unit 485 for audio output. Can be.
  • the power supply unit 490 may include a converter (not shown) for converting AC power into DC power.
  • a converter for example, when the display unit 480 is implemented as a liquid crystal panel including a plurality of backlight lamps, an inverter capable of operating a pulse width modulation (PWM) for driving of variable brightness or dimming It may further comprise an inverter (not shown).
  • PWM pulse width modulation
  • the remote control device 500 transmits the user input to the user input interface unit 450.
  • the remote control device 500 may use Bluetooth, Radio Frequency (RF) communication, Infrared (IR) communication, Ultra Wideband (UWB), ZigBee (ZigBee), or the like.
  • RF Radio Frequency
  • IR Infrared
  • UWB Ultra Wideband
  • ZigBee ZigBee
  • the remote control device 500 may receive an image, an audio or a data signal output from the user input interface unit 450, display it on the remote control device 500, or output a voice or vibration.
  • the digital device 400 described above may be a digital broadcast receiver capable of processing a fixed or mobile ATSC or DVB digital broadcast signal.
  • the digital device according to the present invention may omit some of the configurations of the illustrated configurations, or may further include components not shown on the contrary.
  • the digital device does not include a tuner and a demodulator, and may receive and play content through a network interface unit or an external device interface unit.
  • FIG. 5 is a block diagram illustrating a detailed configuration of the above-described control unit according to an embodiment of the present invention.
  • control unit may include a demultiplexer 510, an image processor 5520, an OSD generator 540, a mixer 550, a frame rate converter (FRC) 555, and It may include a formatter 560.
  • controller may further include a voice processor and a data processor.
  • the demultiplexer 510 demultiplexes an input stream.
  • the demultiplexer 510 may demultiplex the input MPEG-2 TS video, audio, and data signals.
  • the stream signal input to the demultiplexer 510 may be a stream signal output from a tuner, a demodulator, or an external device interface unit.
  • the image processor 420 performs image processing of the demultiplexed image signal.
  • the image processor 420 may include an image decoder 425 and a scaler 435.
  • the video decoder 425 decodes the demultiplexed video signal, and the scaler 435 scales the resolution of the decoded video signal so that the display unit can output the resolution.
  • the image decoder 525 may support various standards.
  • the video decoder 525 performs a function of an MPEG-2 decoder when the video signal is encoded in the MPEG-2 standard, and the video signal is a digital multimedia broadcasting (DMB) method or H.264 / H.265.
  • DMB digital multimedia broadcasting
  • H.264 / H.265 decoder When encoded in the standard, it can perform the function of the H.264 / H.265 decoder.
  • the video signal decoded by the image processor 520 is input to the mixer 450.
  • the OSD generator 540 generates the OSD data according to a user input or itself. For example, the OSD generator 440 generates data for displaying various data in the form of a graphic or text on the screen of the display 380 based on a control signal of the user input interface.
  • the generated OSD data includes various data such as a user interface screen of the digital device, various menu screens, widgets, icons, viewing rate information, and the like.
  • the OSD generator 540 may generate data for displaying broadcast information based on subtitles or EPGs of a broadcast image.
  • the mixer 550 mixes the OSD data generated by the OSD generator 540 and the image signal processed by the image processor to provide the formatter 560. Since the decoded video signal and the OSD data are mixed, the OSD is overlaid and displayed on the broadcast video or the external input video.
  • the frame rate converter (FRC) 555 converts a frame rate of an input video.
  • the frame rate converter 555 may convert the frame rate of the input 60Hz image to have a frame rate of, for example, 120Hz or 240Hz according to the output frequency of the display unit.
  • various methods may exist in the method of converting the frame rate. For example, when the frame rate converter 555 converts the frame rate from 60 Hz to 120 Hz, the frame rate converter 555 inserts the same first frame between the first frame and the second frame or predicts the first frame from the first frame and the second frame. It can be converted by inserting three frames.
  • the frame rate converter 555 may insert and convert three more identical or predicted frames between existing frames. On the other hand, when no separate frame conversion is performed, the frame rate converter 555 may be bypassed.
  • the formatter 560 changes the output of the input frame rate converter 555 to match the output format of the display unit.
  • the formatter 560 may output R, G, B data signals, and the R, G, B data signals may be output as low voltage differential signals (LVDSs) or mini-LVDSs. Can be.
  • the formatter 560 may support a 3D service through the display by configuring the output in a 3D form according to the output format of the display.
  • the voice processing unit (not shown) in the controller may perform voice processing of the demultiplexed voice signal.
  • the voice processor (not shown) may support processing of various audio formats. For example, even when a voice signal is encoded in a format such as MPEG-2, MPEG-4, AAC, HE-AAC, AC-3, BSAC, etc., a decoder corresponding thereto may be provided.
  • the voice processing unit (not shown) in the controller may process base, treble, volume control, and the like.
  • the data processor in the control unit may perform data processing of the demultiplexed data signal.
  • the data processor may decode the demultiplexed data signal even when it is encoded.
  • the encoded data signal may be EPG information including broadcast information such as a start time and an end time of a broadcast program broadcasted in each channel.
  • each component may be integrated, added, or omitted according to the specifications of the digital device actually implemented. That is, as needed, two or more components may be combined into one component or one component may be subdivided into two or more components.
  • the function performed in each block is for explaining an embodiment of the present invention, the specific operation or device does not limit the scope of the present invention.
  • the digital device may be an image signal processing device that performs signal processing on an image stored in the device or an input image.
  • a set-top box STB
  • the display unit 480 and the audio output unit 485 shown in FIG. 4 the above-described DVD player, Blu-ray player, game device, computer And the like can be further illustrated.
  • FIG. 6 is a diagram illustrating input means connected to the above-described digital device according to one embodiment of the present invention.
  • a front panel (not shown) or control means (input means) provided on the digital device 600 is used.
  • control means is a user interface device (UID) capable of wired and wireless communication, the remote control 610, keyboard 630, pointing device 620, mainly implemented for the purpose of controlling the digital device 600, A touch pad may be included, but a control means dedicated to an external input connected to the digital device 600 may also be included.
  • control means also includes a mobile device such as a smart phone, a tablet PC, etc. that control the digital device 600 through mode switching and the like, although the purpose is not the digital device 600 control.
  • a pointing device is described as an embodiment, but is not limited thereto.
  • the input means is a communication protocol such as Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), ZigBee, Digital Living Network Alliance (DLNA), RS, or the like. At least one may be employed as necessary to communicate with the digital device.
  • RFID Radio Frequency Identification
  • IrDA Infrared Data Association
  • UWB Ultra Wideband
  • DLNA Digital Living Network Alliance
  • RS Digital Living Network Alliance
  • the remote controller 610 refers to conventional input means equipped with various key buttons necessary for controlling the digital device 600.
  • the pointing device 620 is equipped with a gyro sensor to implement a pointer corresponding to a screen of the digital device 600 based on a user's movement, pressure, rotation, etc., so that the digital device 600 Transmits a predetermined control command.
  • the pointing device 620 may be named by various names such as a magic remote controller and a magic controller.
  • the keyboard 630 is an intelligent integrated digital device that provides a variety of services such as a web browser, an application, a social network service (SNS), and the like, as the digital device 600 provides only a conventional broadcast. It is not easy to implement, and it is implemented to facilitate input of texts by implementing it similar to the keyboard of a PC.
  • SNS social network service
  • control means such as the remote control 610, pointing device 620, keyboard 630, the touch pad as necessary, more convenient and various control purposes, such as text input, pointer movement, enlargement / reduction of pictures and videos Can be used for
  • the digital device described herein uses WebOS as the OS and / or the platform.
  • a webOS-based configuration or algorithm or the like may be performed by the controller of the above-described digital device.
  • the control unit includes the control unit in FIGS. 2 to 5 and uses the concept broadly. Therefore, hereinafter, the configuration for the processing of WebOS-based or related services, applications, content, etc. in the digital device, the hardware or components including the related software (software), firmware (firmware), etc. to the controller (controller) Explain by naming.
  • the webOS based platform is designed to enhance development independence and function scalability by integrating services and applications based on the Luna-service bus, for example, and to develop applications based on the web application framework. Productivity can also be increased. In addition, multi-tasking may be supported by efficiently utilizing system resources through webOS processes and resource management.
  • the webOS platform described in the present specification may be used in mobile devices such as mobile phones, smart phones, tablet pcs, notebooks, and wearable devices, as well as fixed devices such as PCs, TVs, and STBs. .
  • the architecture of software for digital devices is a monolithic structure that is based on conventional problem solving and market-dependent monolithic structures, and is a single process and closed product based on multi-threading technology. Afterwards, there was a difficulty in external application, and after that, we aimed for new platform-based development, and then layered and componentized by pursuing cost innovation and efficient UI and external application development through chip-set replacement. ), Which had a three-layered structure, add-on, single source product, and add-on structure for open applications.
  • the software architecture has been further developed to provide a modular architecture of functional units, to provide a Web Open API (Application Programming Interface) for the eco-system, and to provide a game engine. Modular design for the native open API (Native Open API), etc. is being made, and accordingly, it is generated as a multi-process structure based on the service structure.
  • FIG. 7 is a diagram illustrating a webOS architecture according to an embodiment of the present invention.
  • the architecture of the webOS platform is as follows.
  • the platform may be largely classified into a kernel, a system library based web OS core platform, an application, a service, and the like.
  • the architecture of the WebOS platform is a layered structure, with the OS at the bottom layer, system library (s) at the next layer, and applications at the top.
  • the lowest layer may include a Linux kernel as an OS layer and include Linux as an OS of the digital device.
  • BSP Board Support Package
  • HAL Hardware Abstraction Layer
  • Web OS core modules layer Web OS core modules layer
  • Service layer Service layer
  • Luna-Service bus layer In the bus layer, the Enyo framework / NDK / QT layer, and the top layer, the application layer is sequentially present.
  • some layers of the above-described webOS layer structure may be omitted, and a plurality of layers may be one layer or conversely, one layer may have a plurality of layer structures.
  • the webOS core module layer is based on a Luna Surface Manager (LSM) that manages surface windows, etc., a System & Application Manager (SAM), a WebKit (WebKit) that manages execution and execution states of applications, etc. It may include a WAM (Web Application Manager) for managing a web application.
  • LSM Luna Surface Manager
  • SAM System & Application Manager
  • WebKit WebKit
  • WAM Web Application Manager
  • the LSM is a display processor and manages an application window displayed on the screen.
  • the LSM manages display hardware, provides a buffer that renders the contents required by the applications, and combines the results of the rendering of the plurality of applications on the screen. You can print
  • the SAM manages performance policies for various conditions of systems and applications.
  • WAM is based on the Enyo Framework, which can be viewed as a web application as a basic application.
  • the service use of the application is made through the Luna-service bus, and the service can be newly registered on the bus, and the application can find and use the service that it needs.
  • the service layer may include services of various service levels, such as a TV service and a WebOS service.
  • the web OS service may include a media server, Node.JS, and the like.
  • the Node.JS service supports, for example, JavaScript.
  • WebOS services can communicate over the bus to Linux processes that implement function logic. It can be divided into four parts, which are migrated from the TV process and the existing TV to webOS or services that are differentiated from manufacturers, webOS common service and JavaScript developed and used through Node.js. It consists of a Node.js service.
  • the application layer may include all applications that can be supported in a digital device, such as a TV application, a showcase application, a native application, and a web application.
  • Applications on the web OS may be classified into a web application, a Palm Development Kit (PDK) application, a Qt Meta Language or Qt Modeling Language (QML) application, and the like, according to an implementation method.
  • PDK Palm Development Kit
  • QML Qt Modeling Language
  • the web application is based on the WebKit engine and runs on the WAM Runtime. Such web applications may be based on the Enyo framework, or may be developed and executed based on general HTML5, Cascading Style Sheets (CSS), or JavaScript.
  • CCS Cascading Style Sheets
  • the PDK application includes a third-party or native application developed in C / C ++ based on a PDK provided for an external developer.
  • the PDK refers to a development library and a set of tools provided to enable a third party such as a game to develop a native application (C / C ++).
  • a PDK application can be used for the development of applications whose performance is important.
  • the QML application is a Qt-based native application, and includes a basic application provided with a web OS platform such as a card view, a home dashboard, a virtual keyboard, and the like.
  • QML is a mark-up language in script form instead of C ++.
  • the native application refers to an application that is developed in C / C ++, compiled, and executed in a binary form.
  • Such a native application has an advantage in that its execution speed is fast.
  • FIG. 8 is a diagram illustrating an architecture of a webOS device according to an embodiment of the present invention.
  • FIG. 8 is a block diagram based on runtime of a webOS device, which can be understood with reference to the layered structure of FIG. 7.
  • services and applications and WebOS core modules are included on a system OS (Linux) and system libraries, and communication therebetween may be via a luna-service bus.
  • Node.js services based on HTML5, CSS, JavaScript, e-mail, contacts, calendar, logging, backup, file notifier WebOS services such as notify, database (DB), activity manager, system policy, audio daemon (AudioD), update, media server, etc.
  • TV services such as Electronic Program Guide (PVR), Personal Video Recorder (PVR), data broadcasting, etc., voice recognition, Now on, Notification, search CP services such as ACR (Auto Content Recognition), CBOX (Contents List Broswer), wfdd, DMR, Remote Application, Download, SDPIF (Sony Philips Digital Interface Format), PDK applications, browser , Native applications such as QML applications And the enyo framework based on the TV UI-related applications and web applications, Luna - made the process via the Web OS core modules, such as the aforementioned SAM, WAM, LSM via the service bus. Meanwhile, in the above, TV applications and web applications may not necessarily be Enyo framework based or UI related.
  • CBOX can manage the list and metadata of the content of external devices such as USB, DLNA, cloud, etc. connected to the TV. Meanwhile, the CBOX may output content listings of various content containers such as USB, DMS, DVR, cloud, etc. in an integrated view. In addition, the CBOX can display various types of content listings such as pictures, music, and videos, and manage its metadata. In addition, the CBOX may output the contents of the attached storage in real-time. For example, the CBOX should be able to immediately output a content list of the storage device when the storage device such as USB is plugged in. In this case, a standardized method for processing the content listing may be defined. In addition, CBOX can accommodate a variety of connection protocols.
  • SAM is intended to improve module complexity and enhance scalability.
  • the existing System Manager processes multiple functions such as system UI, window management, web application runtime, and handling constraints on UX in one process, so that the complexity of implementation is large. Clear implementation interfaces reduce implementation complexity.
  • LSM supports the development and integration of system UX implementations, such as card views and launcher, independently, and makes it easy to respond to changes in product requirements.
  • LSM when synthesizing a plurality of application screens, such as App-on-App, to make the most of the hardware resources (HW resource) to enable multi-tasking, multi-window (multi-window) and 21: 9, etc. It can provide a window management mechanism (window management mechanism) for.
  • LSM supports the implementation of system UI based on QML and improves its development productivity.
  • QML UX is based on MVC, which makes it easy to compose views of layouts and UI components, and to easily develop code to handle user input.
  • the interface between QML and WebOS components is made through QML extension plug-in, and the graphic operation of the application may be based on the wayland protocol, luna-service call, and so on. have.
  • LSM stands for Luna Surface Manager and functions as an application window compositor.
  • the LSM allows you to synthesize independently developed applications, UI components, etc. on the screen.
  • the LSM defines a output area, an interworking method, and the like as a compositor.
  • the compositor, LSM handles graphics compositing, focus management, input events, and so on.
  • the LSM receives an event, focus, and the like from an input manager.
  • the input manager may include a remote controller, a HID such as a mouse & keyboard, a joystick, a game pad, an application remote, a pen touch, and the like.
  • LSM supports multiple window models, which can be executed simultaneously in all applications due to the system UI.
  • NLP Natural Language Processing
  • MRCU Mobile Radio Control Unit
  • Live menu ACR (Auto Content Recognition), etc. .
  • FIG. 9 is a diagram for describing a graphic composition flow in a webOS device according to one embodiment of the present invention.
  • the graphic composition processing includes a web application manager 910 in charge of a UI process, a webkit 920 in charge of a web process, a LSM 930, and a graphic manager (GM). Through 940.
  • the generated graphic data is transferred to the LSM 930 when the graphic data is not a full-screen application.
  • the web application manager 910 receives an application generated by the web kit 920 for sharing a GPU (Graphic Processing Unit) memory for graphic management between the UI process and the web process, and then displays the full-screen as described above. If it is not the application passes to the LSM (930). In the case of the full-screen application, the LSM 930 may be bypassed, and in this case, the LSM 930 may be directly transferred to the graphic manager 940.
  • the LSM 930 may be bypassed, and in this case, the LSM 930 may be directly transferred to the graphic manager 940.
  • the LSM 930 transmits the received UI application to the Wayland Compositor via the Wayland surface, and processes the received UI application to the graphic manager.
  • the graphic data delivered from the LSM 930 is delivered to the graphic manager compositor via, for example, the LSM GM surface of the graphic manager 940.
  • the full-screen application is delivered directly to the graphic manager 940 without passing through the LSM 930, which is processed by the graphic manager compositor via the WAM GM surface.
  • the graphics manager handles all graphic data in the webOS device, including GM surfaces such as data broadcasting applications, caption applications, as well as data via the LSM GM surfaces and WAM GM surfaces described above. Receives all the graphic data that has passed through and processes it to be properly displayed on the screen.
  • GM surfaces such as data broadcasting applications, caption applications, as well as data via the LSM GM surfaces and WAM GM surfaces described above.
  • the function of the GM compositor is the same as or similar to that of the compositor described above.
  • FIG. 10 is a diagram illustrating a media server according to an embodiment of the present invention.
  • FIG. 11 is a block diagram illustrating a configuration of a media server according to an embodiment of the present invention. Is a diagram illustrating a relationship between a media server and a TV service according to an embodiment of the present invention.
  • the media server supports the execution of various multimedia in the digital device and manages necessary resources.
  • the media server can efficiently use hardware resources required for media play.
  • the media server requires audio / video hardware resources in order to execute multimedia, and can efficiently utilize the resource usage status.
  • fixed devices with larger screens than mobile devices require more hardware resources to run multimedia and require faster encoding / decoding and graphics data delivery due to the large amount of data.
  • the media server may perform broadcasting, recording, and tuning tasks, record simultaneously with viewing, or simultaneously display the sender and receiver screens during a video call. It should be able to handle
  • the media server has limited hardware resources such as encoders, decoders, tuners, and display engines on a chip-set basis, making it difficult to execute multiple tasks at the same time. Input is processed.
  • the media server can enhance the system stability, for example, by removing and restarting a playback pipeline in which an error occurred during media playback by pipeline and restarting the error. Even if it does not affect other media play.
  • a pipeline is a chain connecting the respective unit functions such as decoding, analysis, and output when a media play request is requested, and required unit functions may vary according to a media type.
  • Media servers can have extensibility, for example, adding new types of pipelines without affecting existing implementations.
  • the media server may accommodate a camera pipeline, a video conference pipeline, a third-party pipeline, and the like.
  • the media server can handle normal media playback and TV task execution as separate services because the interface of the TV service is different from the media playback case.
  • the media server supports operations such as' setchannel ',' channelup ',' channeldown ',' channeltuning 'and' recordstart 'in relation to TV service, and' play 'and' pause in relation to general media playback.
  • operations such as' and 'stop', different operations can be supported for both, and they can be treated as separate services.
  • the media server may control or integrate management of resource management functions.
  • the allocation and retrieval of hardware resources in the device are integrated in the media server.
  • the TV service process transmits the running task and resource allocation status to the media server.
  • the media server frees resources and executes pipelines as each media runs, allowing execution by priority (e.g., policy) upon request for media execution based on the resource status occupied by each pipeline. Recall resources of other pipelines.
  • priority e.g., policy
  • predefined execution priority and required resource information for a specific request are managed by a policy manager, and the resource manager may communicate with the policy manager to process resource allocation and retrieval.
  • the media server may hold an identifier (ID) for all operations related to playback. For example, the media server may direct and direct a particular pipeline based on the identifier. The media server may issue separate commands to the pipelines for more than one media playback.
  • ID identifier
  • the media server may be responsible for playback of HTML 5 standard media.
  • the media server may follow the TV restructuring scope of the separate service processing of the TV pipeline.
  • the media server may be designed and implemented regardless of the TV restructuring scope. If the TV is not serviced separately, the media server may need to be re-executed when there is a problem with a specific task.
  • the media server is also referred to as uMS, or micro media server.
  • the media player is a media client, which is, for example, a web for HTML5 video tag, camera, TV, Skype, 2nd Screen, etc. It may mean a kit.
  • management of micro resources such as a resource manager, a policy manager, and the like is a core function.
  • the media server also controls the playback control role for the web standard media content.
  • the media server may also manage pipeline controller resources.
  • Such media servers support, for example, extensibility, reliability, efficient resource usage, and the like.
  • the uMS that is, the media server
  • the media server is a webOS device such as a TV game and resources such as cloud game, MVPD (pay service, etc.), camera preview, second screen, skype, and the like. It manages and controls the overall use and control of resource for proper processing within the system. Meanwhile, each resource uses, for example, a pipeline when the resource is used, and the media server can manage and control the creation, deletion, and use of the pipeline for resource management.
  • a pipeline is created when a media associated with a task starts a continuation of tasks such as parsing a request, a decoding stream, a video output, and the like.
  • tasks such as parsing a request, a decoding stream, a video output, and the like.
  • watching, recording, channel tuning, and the like are each processed under control of resource usage through a pipeline generated according to the request. .
  • an application or service is connected to a media server 1020 via a luna-service bus 1010, and the media server 1020 is connected to pipelines regenerated through the luna-service bus 1010.
  • the application or service may have various clients according to its characteristics and may exchange data with the media server 1020 or pipeline through the client or the client.
  • the client includes, for example, a uMedia client (web kit) and a resource manager (RM) client (C / C ++) for connecting to the media server 1020.
  • a uMedia client web kit
  • RM resource manager
  • the application including the uMedia client is connected to the media server 1020 as described above. More specifically, the uMedia client corresponds to, for example, a video object to be described later, and the client uses the media server 1020 for operation of the video by request.
  • the video operation relates to a video state
  • loading, unloading, play, playback, or reproduce, pause, stop, and the like are all states related to the video operation. May contain data.
  • Each operation or state of such video can be handled through the creation of a separate pipeline.
  • the uMedia client sends state data related to the video operation to the pipeline manager 1022 in the media server.
  • the pipeline manager 1022 obtains information on a resource of the current device through data communication with the resource manager 1024 and requests allocation of a resource corresponding to the state data of the uMedia client.
  • the pipeline manager 1022 or the resource manager 1024 controls resource allocation through data communication with the policy manager 1026 when necessary in relation to the resource allocation. For example, when there is no resource to be allocated according to the request of the pipeline manager 1022 in the resource manager 1024, or when there is insufficient resource, an appropriate resource allocation is performed according to the request according to the privacy comparison of the policy manager 1026. Can be.
  • the pipeline manager 1022 requests the media pipeline controller 1028 to generate a pipeline for an operation according to the request of the uMedia client for the allocated resource according to the resource allocation of the resource manager 1024.
  • the media pipeline controller 1028 generates the required pipeline under the control of the pipeline manager 1022.
  • This generated pipeline as shown, not only a media pipeline, a camera pipeline, but also a pipeline related to play, pause, and pause may be generated.
  • the pipeline may include a pipeline for HTML5, web CP, smartshare playback, thumbnail extraction, NDK, cinema, multimedia and hypermedia information coding expert groups (MHEG), and the like.
  • the pipeline may include, for example, a service-based pipeline (own pipeline) and a URI-based pipeline (media pipeline).
  • an application or service including an RM client may not be directly connected to the media server 1020. This is because an application or service may handle media directly. In other words, when an application or service directly processes media, it may not go through a media server. However, at this time, resource management is required for pipeline creation and its use, and for this purpose, the uMS connector functions. Meanwhile, when the uMS connector receives a resource management request for direct media processing of the application or service, the uMS connector communicates with the media server 1020 including the resource manager 1024. To this end, the media server 1020 should also be equipped with a uMS connector.
  • the application or service may respond to the request of the RM client by receiving resource management of the resource manager 1024 through the uMS connector.
  • RM clients can handle services such as native CP, TV services, second screens, Flash players, YouTube Source Source Extensions (MSE), cloud games, and Skype.
  • the resource manager 1024 may manage the resource through the data communication with the policy manager 1026 as necessary for resource management.
  • the URI-based pipeline is made through the media server 1020, rather than directly processing the media as described above.
  • a URI-based pipeline may include a player factory, a Gstreamer, a streaming plug-in, a digital rights management plug-in pipeline, and the like.
  • an interface method between an application and media services may be as follows.
  • the PDK interface using a service.
  • a method of using a service in the existing CP can be used to extend existing platform plug-ins based on Luna for backward compatibility.
  • Seamless change is handled by a separate module (e.g. TVWIN), which is the process of first displaying the TV on the screen without a webOS and seamlessly before or during the webOS boot. . It is used for the purpose of providing the basic functions of TV service for quick response to the user's power on request because the webOS boot time is slow.
  • the module also supports seamless change, factory mode, and the like, which provide fast boot and basic TV functions as part of the TV service process.
  • the module may be responsible for switching from the non-webOS mode to the webOS mode.
  • a processing structure of the media server is shown.
  • the solid line box may indicate a process processing configuration
  • the dotted line box may indicate an internal processing module during the process.
  • the solid arrow may indicate an inter-process call, that is, a Luna service call
  • the dashed arrow may indicate a notification or data flow such as register / notify.
  • a service or web application or PDK application (hereinafter referred to as an "application") is connected to various service processing configurations via a luna-service bus, through which the application operates or is controlled.
  • the data processing path depends on the type of application. For example, when the application is image data related to a camera sensor, the application is transmitted to the camera processor 1130 and processed. In this case, the camera processor 1130 processes image data of the received application, including a gesture, a face detection module, and the like. For example, when the data is required to be selected by the user or to automatically use the pipeline, the camera processor 1130 may generate a pipeline through the media server processor 1110 and process the corresponding data.
  • the audio may be processed through the audio processor 1140 and the audio module 1150.
  • the audio processor 1140 processes the audio data received from the application and transmits the audio data to the audio module 1150.
  • the audio processor 1140 may include an audio policy manager to determine the processing of the audio data.
  • the audio data thus processed is processed by the audio module 1160.
  • the application may notify data related to audio data processing to the audio module 1160, which may also notify the audio module 1160 in a related pipeline.
  • the audio module 1150 includes an advanced Linux sound architecture (ALSA).
  • the corresponding content data is transmitted to the DRM service processor 1160, and the DRM service processor 1170 generates a DRM instance.
  • the DRM service processor 1160 may be connected to and process the DRM pipeline in the media pipeline through the Luna-service bus to process the content data on which the DRM is applied.
  • the following describes processing when the application is media data or TV service data (e.g., broadcast data).
  • TV service data e.g., broadcast data
  • FIG. 12 illustrates only the media server processing unit and the TV service processing unit in FIG. 11 described above in more detail.
  • the TV service processor 1120 may include, for example, at least one or more of a DVR / channel manager, a broadcasting module, a TV pipeline manager, a TV resource manager, a data broadcasting module, an audio setting module, a path manager, and the like.
  • the TV service processor 1220 may include a TV broadcast handler, a TV broadcast interface, a service processor, a TV middleware, a path manager, and a BSP.
  • the service processor may mean, for example, a module including a TV pipeline manager, a TV resource manager, a TV policy manager, a USM connector, and the like.
  • the TV service processor may have a configuration as shown in FIG. 11 or 12 or a combination thereof, and some components may be omitted or some components not shown may be added.
  • the TV service processor 1120/1220 transmits the DVR (Digital Video Recorder) or channel related data to the DVR / channel manager based on the property or type of the TV service data received from the application, and then the TV pipeline manager. To create and process the TV pipeline. Meanwhile, when the attribute or type of the TV service data is broadcast content data, the TV service processor 1120 generates and processes a TV pipeline through a TV pipeline manager for processing the corresponding data through a broadcast module.
  • DVR Digital Video Recorder
  • a json (Javascript standard object notation) file or a file written in c is processed by the TV broadcast handler and transmitted to the TV pipeline manager through the TV broadcast interface to generate and process a TV pipeline.
  • the TV broadcast interface unit may transmit data or files that have passed through the TV broadcast handler to the TV pipeline manager based on the TV service policy and refer to them when generating the pipeline.
  • the TV broadcast interface may also perform a controller function of the TV service processor 1220.
  • the TV broadcast interface requests the pipeline creation to the TV pipeline manager, which creates the TV pipeline and requests resources to the TV resource manager.
  • the TV resource manager makes a resource request to the media server through the UMS connector and acquires it, and returns it to the TV pipeline manager.
  • the TV pipeline manager arranges the returned resources in the generated TV pipeline and registers pipeline information in the path manager.
  • the TV pipeline manager then returns the result to the TV pipeline manager, which returns the pipeline to the TV broadcast interface.
  • the TV broadcast interface then communicates with the TV middleware (MW: MiddleWare) to request a channel change and the like, and returns the result from the TV middleware.
  • MW MiddleWare
  • the TV service may be processed.
  • the TV pipeline manager may be controlled by the TV resource manager in generating one or more pipelines in response to a TV pipeline generation request from a processing module or manager in a TV service.
  • the TV resource manager may be controlled by the TV policy manager to request the state and allocation of resources allocated for the TV service according to the TV pipeline creation request of the TV pipeline manager, and the media server processor 1110. / 1210) and uMS connector to communicate data.
  • the resource manager in the media server processor 1110/1210 transmits a status and resource allocation of a resource for a current TV service at the request of the TV resource manager. For example, as a result of checking the resource manager in the media server processor 1110/1210, if all resources for the TV service are already allocated, the TV resource manager may notify that all resources are currently allocated.
  • the resource manager in the media server processing unit removes a predetermined TV pipeline according to a priority or a predetermined criterion among the TV pipelines pre-allocated for the TV service along with the notification and generates a TV pipeline for the requested TV service. May be requested or assigned.
  • the TV resource manager may appropriately remove, add, or establish a TV pipeline in accordance with the status report of the resource manager in the media server processor 1110/1210.
  • the BSP supports backward compatibility with existing digital devices, for example.
  • the TV pipelines thus generated may be properly operated under the control of the path manager during the processing.
  • the path manager may determine or control the processing path or process of the pipelines in consideration of not only the TV pipeline but also the operation of the pipeline generated by the media server processor 1110/1210.
  • the media server processor 1110/1210 includes a resource manager, a policy manager, a media pipeline manager, a media pipeline controller, and the like.
  • a pipeline generated under the control of the media pipeline manager and the media pipeline controller can be variously created such as a camera preview pipeline, a cloud game pipeline, and a media pipeline.
  • the media pipeline may include a streaming protocol, an auto / static gstreamer, a DRM, and the like, which may be determined according to a path manager's control.
  • the detailed processing procedure in the media server processor 1110/1210 uses the above-described description of FIG. 10 and will not be repeated herein.
  • the resource manager in the media server processor 1110/1210 may manage resources on a counter base, for example.
  • Media Server is a media framework that allows third-party multimedia pipeline (s) to interface with the WebOS platform.
  • the media server may control, manage, isolate, deconflict, and the like resources such that the third-party multimedia pipeline (s) are compliant.
  • These media servers provide a generalized API for applications to play media and can be viewed as platform modules that consistently manage hardware resources and policies.
  • the design of the media server is to reduce the complexity through generalization of media processing and separation of related modules.
  • the key to such a media server is to provide integration of, for example, the service interface with the WebOS UI.
  • the media server controls the resource manager, policy manager, pipeline manager, and provides API access according to resource manager queries.
  • the uMS Connector is the main API and SDK to interface client media pipeline processes with the media server.
  • Ums connectors are events and messages about the interface.
  • the client media pipelines implement client media pipeline state events for enabling load, play, pause, seek, stop, unload, release resource (release_resource), aquire resource (acquire_resource), and the like.
  • uMedia API provides C and C ++ API to media server.
  • the Media Resource Manager provides a way to disk-drive media hardware resources and pipeline client resource usage in a simple configuration file.
  • the Media Resource Manager provides all the performance and information needed to implement default or third-party media policy management.
  • the media policy manager works when the resource manager rejects the media pipeline because of resource conflicts.
  • the policy manager can provide a consistent API and SDK to enable third-party policy manager implementations.
  • the policy manager supports media pipelines that match Least Recently Used (LRU) and may be used for one or more conflicted resources.
  • LRU Least Recently Used
  • the pipeline manager tracks and maintains client media pipelines.
  • the pipeline controller provides a consistent API for the pipeline manager to control and manage client media pipelines.
  • the media server communicates with the resource manager via a library call, which can communicate via the TV services, media pipeline and Luna service bus.
  • the media resource manager may configure the entire configurable configuration file for disking the media hardware and media client pipelines, detect the resource conflict, and collect all the information needed to implement media policy management.
  • the media policy manager reads the policy_select and policy_action fields in the resource configuration file, the resource contention attempts to select the active pipeline described by the policy_select field, and issues with outgoing / selected pipelines based on the policy_action field. Issue.
  • the selection criterion may be a parameter supported by the pipeline configuration setting entry.
  • Policy actions are unload and release. All pipelines support the unload command to release all allocated resources. Pipelines can additionally support the release command to release specific resources. In the above, the release command is for fast switch pipelines competing with common resources, and the unload command of all resources may not be required for the incoming pipeline and deconflict.
  • the pipeline manager manages pipeline controllers.
  • the pipeline manager maintains a running queue of pipeline controllers and provides unique indexing for incoming messages from application (s) via a media server.
  • the pipeline controller maintains a relationship of related media client pipeline processes.
  • the pipeline controller maintains all relevant states and provides the media manager pipeline control interface to the pipeline manager.
  • the pipeline client process is a separate process that uses the uMS connector to provide a control interface to a media server or the like.
  • Pipeline (client) media technologies can be individually and completely decoupled from media server management and services.
  • FIG. 13 is a diagram illustrating an interfacing method between an application and media services according to an embodiment of the present invention.
  • a service on a webOS may communicate via a bus to a Linux process implementing function logic, and an application on a webOS may be a web application according to an implementation method.
  • Web Application Web Application
  • PDK Personalm Development Kit
  • QML Qt Meta Language or Qt Modeling Language
  • the web application is based on the WebKit engine, runs on the WAM runtime, based on the Enyo framework, or developed and executed based on general HTML5, Cascading Style Sheets (CSS), or JavaScript. Can be.
  • the PDK application includes a third-party or native application developed in C / C ++ based on a PDK provided for an external developer.
  • the QML application is a Qt-based native application, and includes a basic application provided with a webOS platform.
  • the native application refers to an application that is developed and compiled in C / C ++ and executed in a binary form.
  • the method using the HTML5 standard is, for example, video tags, media elements, and the like.
  • the method using Cordova may use, for example, a method of extending a display with a video tag.
  • the applications 1310 and 1320 include a media server 1372 for a media service, a DRM server 1374 for a DRM service, a TV service processor 1374 for a TV service, and a camera service.
  • the camera service processor 1378 and the audio processor 1380 for the audio service may be used through the Luna service bus 1360.
  • the web application 1310 uses a TV gap processing unit 1342, an HTML5 processing unit (web kit) 1344, a palm service bridge processing unit (web kit) 1346, and the like.
  • the existing CP of the web application 1310 may use the plug-in processor 1348 for backward compatibility, if necessary.
  • the PDK application 1320 uses the PDL processing unit 1350
  • the non-WebOS application 1330 may use a service directly through the Luna service bus 1360.
  • the service can be used through the HTML5 processing unit (web kit) 1344 and the Luna service bus 1360.
  • the Cordova processing unit (TV gap) 1342 is an HTML5 processing unit (web kit) 1344 or / and a palm service bridge processing unit (web kit).
  • the service may be available via the Luna service bus 1360 via 1346.
  • the web application 1310 may use the service through the Luna service bus 1360 via the palm service bridge processing unit (web kit) 1346.
  • the method of using the service in the PDK application 1320 may be made based on the PDL.
  • the PDK application 1320 may use the corresponding service by making a Luna call using PDL_Service or PDL_ServiceCallWithCallback.
  • non-WebOS application can use the above-mentioned service directly through a Luna call without any configuration.
  • APIs for playing media with a clear identifier as a multi-instance include load, unload, exit, play, pause, resume, and stop. , Setproperty, getproperty, etc.
  • APIs for TV playback are open, release, setchannel, channelup, channeldown, There may be a record start (start_record), a record stop (record_stop), and the like.
  • FIG. 14 is a diagram illustrating a baseline between a platform and an application according to an embodiment of the present invention.
  • the platform manages the lifecycle of resources such as applications, media, TV playback, and so on.
  • the platform manages the state changes of resources and can notify the affected application with the correct information.
  • the application may take some action and guide the event that occurs when the application does not take the action.
  • the side effects may not be limited to that application but may affect the entire platform or other applications.
  • the responsibility and authority for the change of state may be managed internally in the platform, the internal management of the platform, or the minimum exception handling that does not affect the platform.
  • the location of the controller in MVC (or MVP) implementation is as follows.
  • the controller of the service is determined by referring to the state, condition, etc. of the model (logic) in the service, and the policy that does not depend on the application is processed by the controller in the service. For example, when bad video is generated, the A / V may be muted.
  • the controller of an application can handle it within the application in the case of a UI policy or an application dependent policy in the application. At this time, even if the application is modified, it may not affect the service.
  • the baseline on the media between the platform and the application according to the present invention is as follows.
  • case A is a case where an application playing media in the foreground is switched to the background or the application is switched back to the foreground after switching to the background.
  • the application first receives a background notification before the application playing the media in the foreground is switched to the background.
  • the application may pose itself in the media playback state. If the application does not do the pose itself, the audio playback is maintained but the video is automatically hidden by the Z-order but takes up bandwidth. For example, if the MP3 player application is taken as an example, audio playback may be maintained even when the MP3 player application goes to the background.
  • the application switched to the background may be switched back to the foreground, where the application receives a notification before the transition and, when the notification is received, plays the media that itself poses again.
  • the play point may be played after the pose, for example.
  • the application does not play in the above, it can be output to the user in a paused state, and play at the request of the user.
  • case B is a case where an application is forcibly released from a resource due to a contention with another application in the background or the application is switched back to the foreground.
  • the media server forces the media to unload.
  • the media server may notify the application that the application was unloaded due to lack of resources to the application after the forced unloading.
  • the application notified of the unloading due to the lack of resources from the media server may appropriately handle an exception such as notification pop-up exposure.
  • the application when an application whose resource is released goes back to the foreground, the application, not the media server, calls to load itself. However, if the application does not load by itself, it may output to the user in an unloaded state and may follow the user's request.
  • 15 to 19 illustrate a run-time view between an application and a media service according to an embodiment of the present invention.
  • FIGS. 18 to 19 show a run-time view for case B described above.
  • FIG. 15 illustrates a run-time view when loading and playing in a media application.
  • a media application requests a load to a media server
  • the media server creates a media pipeline and writes to the generated media pipeline.
  • Obtain resources for The media application then makes a play request.
  • FIG. 16 shows a run-time view when the media application playing in the foreground in FIG. 15 goes to the background, where the media application is notified of the transition from foreground to background from the system manager.
  • the media application then makes a pause request to the media server, which forwards the received pause request to the media pipeline.
  • FIG. 17 illustrates a run-time view when an application which has been background switched to the foreground is switched back to the foreground, as shown in FIG. 16.
  • the media application is notified to switch back to the foreground from the system manager.
  • Receive Notify The media application then makes a play request to the media server, which forwards the received request to the media pipeline.
  • FIG. 18 shows a run-time view when, for example, a media application that was in the background as shown in FIG. 16 releases a pre-allocated resource in relation to another application, and the like, and the media application is in the background.
  • the media server requests to create a new media pipeline according to the load request of the foreground application.
  • resources for a newly created media pipeline must be allocated, which is in competition with the resources allocated to the previously created media pipeline.
  • the media server instructs the unloading to the existing media pipeline according to the resource allocation for the new media pipeline.
  • the media pipeline releases resources.
  • the media server also notifies the occurrence of an unload event to the media application in the background.
  • FIG. 19 illustrates a run-time view in which the media application in the background in FIG. 18 is switched back to the foreground.
  • the media server When the media application is notified of the transition to the foreground from the system manager, the media server The media server creates a new media pipeline in place of the media pipeline removed according to the resource release in FIG. 18, and the media pipeline requests and acquires resources from the media server. The media application in the foreground then makes a play request to the media server.
  • 20 to 23 are diagrams for explaining a run-time view between an application and a TV service according to an embodiment of the present invention.
  • the TV service processing unit replaces the function of the media server of FIGS. 15 to 19 described above.
  • FIG. 20 illustrates a run-time view of processing channel change in a TV service, that is, a DTV application.
  • the DTV application requests the TV service processor to open a pipeline for outputting a broadcast program of the tuned channel, and the TV service processor generates a TV pipeline for the channel and is allocated a resource.
  • the DTV application makes a setchannel request to the TV service processor, and the TV service processor stores the requested channel in the TV pipeline and allocates resources for the stored channel.
  • the resource includes, for example, a tuner.
  • the TV media pipeline then notifies that it can output video to DTV applications.
  • the channel change is continued through the above process, in which a new TV pipeline may be created for each channel change, or an existing TV pipeline may be used.
  • FIG. 21 illustrates a run-time view when the DTV application for TV service is switched to the background.
  • the DTV application receives a notification of background switching from the system manager, a stop request is made to the TV service processor. Do it.
  • the TV service processor releases resources allocated to the TV pipeline previously created.
  • FIG. 22 illustrates a run-time view when a DTV application for a TV service is in the background and then goes back to the foreground, as shown in FIG. 21.
  • the DTV application switches from the system manager to the foreground in the background.
  • the TV service processor Upon receiving the notification, the TV service processor requests a channel setting for outputting a broadcast program.
  • the TV service processor stores the corresponding channel in the created media pipeline and allocates resources for processing such as channel tuning.
  • FIG. 23 illustrates a run-time view for viewing reservation among TV services.
  • the TV service processor receives a viewing reservation request from a client (now and hot)
  • the requested viewing reservation predetermined time for example, 1 minute
  • the DTV application requests the TV service processing unit to set a viewing reserved channel
  • the TV service processing unit stores the requested channel in the TV media pipeline. And allocate the necessary resources.
  • 24 and 25 illustrate a run-time view between an application and a TV service according to another exemplary embodiment of the present invention.
  • FIGS. 24 and 25 show run-time views for continuous TV service process processing, unlike FIGS. 20-23.
  • FIG. 24 shows a run-time view for record reservation after viewing
  • FIG. 25 shows a run-time view for channel change during recording.
  • 24 illustrates a single tuner as an example.
  • a client requests AddReservedRecord to a TV service processor
  • the user notifies a user with a pop-up message before a predetermined time of the reserved recording start time.
  • the reservation processing unit in the TV service processing unit transmits a startRecord command to the DVR manager
  • a recording TV pipeline is newly generated and a resource is allocated, and the created watching TV pipeline is generated.
  • Share channel with the pipeline, and the DTV manager compares the shared channel information with the reserved recording requested channel based on the recording start command and requests channel change for recording, and the TV service processing unit requests the DTV application. To change the channel according to the scheduled recording.
  • the new resource allocation may be notified instead of the channel change notification according to the resource share.
  • a run-time view is illustrated, and the DTV application transmits the requested channel setting to the TV service processor according to the channel change request. request.
  • the TV service processor delivers this to the TV pipeline for viewing and detects resource shares and policies. Thereafter, the TV service processor notifies the DTV application that channel change due to recording is not possible, and the DTV application notifies by outputting a result of the viewing selection selected by the user as a pop-up message.
  • the DTV application requests a recording list from the DVR manager and receives a return
  • the DTV application requests stop recording from the DVR manager. This is transmitted to the recording TV pipeline, and the TV service processor deletes the recording TV pipeline.
  • the function of the TV service is not limited to simply watching.
  • additional functions may be performed simultaneously in conjunction with viewing, such as instant recording, screen capture, and the like.
  • operations separate from the viewing may be performed in the background, such as scheduled recording, second TV (2nd TV), scart signal output, and the like.
  • operations in the background may be performed by switching to the foreground.
  • resource share has been described using the TV service as an example, the present invention is not limited thereto.
  • the resource share concept is not only used for the TV service and its associated operation, but also for the TV service, the media service, and the media services.
  • resource shares can be used when resource conflicts arise due to limited resources, even though the required resource (s) are required in the course of using an application or service.
  • FIG. 26 is a diagram illustrating a pipeline structure according to an embodiment of the present invention.
  • the pipeline includes a media pipeline related to a media playback and a TV pipeline related to a TV service.
  • the TV pipeline will be described as an example to help the present invention and the convenience of the applicant.
  • the TV pipeline has a structure composed of elements that have different roles and characteristics.
  • elements such as tuner, SDEC, PSIP, VDEC, and DE may be connected to the pipeline.
  • the elements may correspond to, for example, resources, and these resources may be hardware resources in particular.
  • TV middleware These elements are implemented in a thread-based manner inside TV middleware, and are controlled organically by exchanging data and events between modules. Therefore, the TV middleware may be restructured to define all elements according to the pipeline concept.
  • one method defines the TV pipeline as abstract input element and output element only, as shown in FIG. 26A, and the actual connection and control of each element is the TV middleware. You can take charge of
  • the TV pipeline has a unique identifier (ID) for each instance, the client can control the pipeline through the identifier.
  • ID unique identifier
  • FIG. 26A may be expressed as shown in FIG. 26B. Meanwhile, FIG. 26C briefly illustrates that the broadcast pipeline, the HDMI pipeline, and the component pipeline are derived from, for example, the TV pipeline.
  • FIG. 27 is a diagram illustrating a pipeline type according to one embodiment of the present invention.
  • FIG. 27A shows the media pipeline
  • FIG. 27B shows the broadcast pipeline
  • FIG. 27C shows the HDMI pipeline.
  • FIG. 27A is a representation of a media pipeline in the TV pipeline notation form as shown in FIG. 26. Since the media pipeline is managed by a media server, the media pipeline may have a representation or other structure different from that shown.
  • Input elements or sources in the media pipeline may not require separate hardware resources.
  • the input element is a URI, and the output element is an example of viewing W. Accordingly, resources such as VDEC0, ADEC0, and DE0 are required.
  • 27B shows a channel as an input element in the broadcast pipeline, so tuner TU0 is required.
  • the output element is DTV viewing, and accordingly resources such as VDEC0, ADEC0, DE0 are required.
  • FIG. 27C shows an HDMI pipeline as an input element and an HDMI port, and requires connector resources.
  • the output element is HDMI viewing (HDMI_W), and accordingly, RX0, ADC0, ADEC0, DE0, etc. are required.
  • an output element is generated for each pipeline for viewing, and required hardware resources may be allocated.
  • FIG. 28 is a diagram illustrating a pipeline characteristic definition according to an embodiment of the present invention.
  • FIG. 28 is described using the TV broadcast pipeline as an example for convenience.
  • the TV pipeline has a unique identifier ID1 and may have one input port and one output port as described above.
  • a channel number CH may be input to the input port, and a watch, a record, and the like may be output to the output port.
  • the TV resource element may have resource information and resource information (Resource Infor (Priority)) obtained from the resource manager.
  • resource information Resource Infor (Priority)
  • a link between the resource information obtained from the resource manager may be allowed through the Prev and Next fields of FIG. 28B.
  • the action on the TV pipeline can be divided into the following steps of setting up two ports.
  • the channel is input and in the second step, the output is determined.
  • the resource manager is requested to acquire a resource, then a TV resource element is generated, and then linked with the port.
  • 28C shows, inter alia, after the channel setset.
  • 29 is a diagram illustrating a relationship between a pipeline and a resource manager according to an embodiment of the present invention.
  • FIG. 29 there is a TV service processor 2910 and a media server 2950 associated with a pipeline.
  • the TV service processor 2910 includes a TV pipeline manager 2920, a TV resource manager 2930, and the like, and the media server 2950 includes a resource manager 2960 and a policy manager.
  • the TV resource element in the TV resource manager 2930 has resource information obtained from the resource manager 2960.
  • the TV resource element is a resource contention with the media pipeline and is subject to policy.
  • the TV pipeline managed by the TV pipeline manager 2920 may generate N (where N is a positive integer) if sufficient resources are provided.
  • ports of the TV pipeline are linked, for example, with the TV resource elements in the TV resource manager 2930, as shown.
  • TV resource elements may be aliased between TV pipelines.
  • FIG. 30 is a diagram illustrating a configuration for simultaneously watching and recording a TV service according to an embodiment of the present invention
  • FIG. 31 is a diagram illustrating a simultaneous recording and viewing of a TV service according to another embodiment of the present invention.
  • Figure is a diagram.
  • FIG. 30 shows a case of a single tuner and FIG. 31 shows a case of a multi tuner.
  • the tuner (TU) resource is aliased, and in FIG. 31, the tuner resource aliasing is not necessary.
  • this is the perspective of the tuner resource, and aliasing may occur for at least one resource, whether an input port or an output port in FIGS. 30 to 31.
  • it will be described on the assumption that aliasing has occurred for the tuner resource.
  • the viewing pipeline ID1 and the recording pipeline ID2 should be generated, and each generated pipeline has a unique identifier.
  • FIG. 30 shows a case of a single tuner, in which case the input port of the viewing pipeline and the input port of the recording pipeline are both aliased to the TV resource element having the tuner (TU0) resource.
  • FIG. 31 shows that the aliasing does not occur because each input port is linkable with a TV resource element having a tuner resource.
  • output ports are linked with TV resource elements according to their characteristics.
  • the output can also be affected. For example, if a channel of an input port is changed in one pipeline, the input of another pipeline may be changed, and the output of each pipeline may also be affected.
  • resource contention for DE0 may occur, in which case the resources linked to the output port of the viewing pipeline may be released. However, at this time, even if resources of the viewing pipeline are released, the recording pipeline, that is, the recording operation may be maintained without being affected.
  • the TV pipeline manager may be in charge of swapping specific resources ex, TU0, and TU1 according to a hardware policy situation. Meanwhile, in FIG. 31, even if a channel change is requested to the input port of the viewing pipeline, the recording may not be affected.
  • 32 is a diagram for explaining a resource element definition according to one embodiment of the present invention.
  • the TV resource element 3210 includes a Prev field 3212, a resource information field 3214, and a Next field 3216.
  • the resource information field 3214 may also include privacy information.
  • the TV resource element 3210 may be linked with other TV resource elements based on the Prev and Next fields 3212 and 3216.
  • the resource element 3220 of the ID1 is normal and normal resource information is A to E.
  • a new resource element 3225 is generated and at least one or more of the resource information of the generated resource element is overlapped with one of the resources of the previous resource element 3220, common resources A and B as shown in FIG. 32C.
  • An internal resource element 3230 with C) may be created and the new resource element 3225 and the old element 3220 may be linked to each other (ID3) based on the Prev field.
  • the internal resource element 3230 may be linked to the elements ID1 and ID2 based on the next field.
  • the internal resource element 3230 may have the highest priority among the elements.
  • the priority of the internal resource element 3230 may follow the highest one of the priorities of the child elements.
  • the resources of the ID1 resource element 3220 are A to E and the priority is normal
  • the resources of the ID2 resource element 3225 are A, B, C, F, and G.
  • the tee is high, since A, B, and C among the resources of the resource element of the ID2 are included in the resources of the ID1 resource element, an internal resource element of the ID3 is newly generated, and the ID3 is generated.
  • the internal resource element has resource information of common resources A, B, and C.
  • the ID3 internal resource element has a high according to ID2 having the highest priority among the normal of ID1 and the high of ID2.
  • the ID3 internal resource element is linked including the child ID1 and ID2 in the Next field.
  • resource elements of ID1 and ID2 are shown in FIG. 32C.
  • ID1 resource elements include resources of D and E
  • resource elements of ID2 include resources of F and G.
  • the resource elements of ID1 and ID2 having a parent-child relationship are linked to include the ID3 in the Prev field for use of the common resources A, B, and C.
  • the internal element is no longer needed and thus the remaining child is removed. It may be merged into an element ID2 3240.
  • 33 is a diagram illustrating a pipeline lifecycle according to an embodiment of the present invention.
  • the pipeline lifecycle consists of open, play, stop, and close.
  • the pipeline is created according to the open command.
  • a pipeline ID is generated and a pipeline instance is created.
  • Starts an action that is, an action, according to a play command (ex, watch, record, etc.).
  • the pipeline is connected to a resource manager to dynamically allocate resources to perform the action.
  • the pipeline stops executing the action and releases the previously used resources.
  • the pipeline ID and the pipeline instance are maintained.
  • a close command it removes the pipeline ID and pipeline instance that it maintained or created.
  • one pipeline lifecycle is achieved.
  • the pipeline lifecycle may be accomplished with other paths or other configurations than shown here.
  • FIG. 34 is a diagram illustrating a relationship between internal components of a channel change case according to an embodiment of the present invention.
  • the TV broadcast handler 3430 in the TV service module 3420 may interface_broadcast_changeChannel.
  • the channel ID and the channel information are transmitted to the TV service policy processor 3442 in the TV broadcast interface (controller) 3440.
  • the TV service policy processor 3442 transfers the ID, input_type, action, and parameters to the TV pipeline manager 3450 with API_PIPELINE_SetAction, and the TV pipeline manager 3450 allocates resources and pipelines. Toggle the state from open to play.
  • the TV pipeline manager 3450 forwards the ID, resource information, input type, and action to the path manager 3460 to PathOpen, and the path manager 3460 generates a path instance.
  • Data such as ID, resource information, input type, and action.
  • the TV pipeline manager 3450 notifies the resource connection event to the TV broadcast interface 3440, and broadcasts the TV broadcast.
  • the cast interface 3440 makes a call connection with the middleware (MW) 3470 using the DIL.
  • the middleware 3470 calls the DIL 3480 for the connection, and the DIL 3480 performs the connection.
  • the TV broadcast interface 3440 registers ID, channel information, and the like in the sub library 3444, transmits API_CM_ChannelChange including the registered ID, channel information, etc. to the middleware 3470, and the TV broadcast handler 3430. Returns "OK”.
  • the TV broadcast handler 3430 then returns "OK" to the channel change request requested by the first TV application 3410 to perform a channel change operation.
  • FIG. 35 is a sequence diagram illustrating a pipeline call sequence according to an embodiment of the present invention
  • FIG. 36 is a sequence diagram illustrating a pipeline call sequence according to another embodiment of the present invention.
  • FIG. 35 illustrates, for example, a TV service viewing pipeline call sequence
  • FIG. 36 illustrates, for example, a media pipeline call sequence.
  • the configuration related to the TV service viewing pipeline call sequence includes a TV service viewing pipeline 3510, a media server resource manager 3520, a video sink manager (VSM) / DASS 3530, and the like.
  • the VSM is also called a video processor.
  • the TV service viewing pipeline 3510 and the VSM / DASS 3530 request the media server resource manager 3520 to generate a resource manager client (ResourceManagerClienCreate [PolicyActionHandler]), respectively (S3502 and S3504).
  • ResourceManagerClienCreate [PolicyActionHandler]
  • the media server resource manager 3520 returns a resource manager client handle (ResourceManagerClientHandle) for each request of the TV service viewing pipeline 3510 and the VSM / DASS 3530 (S3506 and S3508).
  • ResourceManagerClientHandle resource manager client handle
  • the TV service viewing pipeline 3510 and the VSM / DASS 3530 request the media server resource manager 3520 to the resource manager client pipeline registers (ResourceManagerClientRegisterPipeline [tv_watch] and ResourceManagerClientRegisterPipeline [vsm]), respectively (S3510 and S3512). ).
  • the TV service viewing pipeline 3510 and the VSM / DASS 3530 request a resource server client start transaction (ResourceManagerClientStartTransaction [Handle_watch] and ResourceManagerClientStartTransaction [Handle_vsm]) to the media server resource manager 3520, respectively (S3514, S3516).
  • resource server client start transaction ResourceManagerClientStartTransaction [Handle_watch] and ResourceManagerClientStartTransaction [Handle_vsm]
  • the TV service viewing pipeline 3510 and the VSM / DASS 3530 respectively request the media server resource manager 3520 to acquire a resource manager client (ResourceManagerClientAcquire [Handle_watch, resourceList], ResourceManagerClientAcquire (Handle_vsm, resourceList)). (S3518, S3520).
  • the media server resource manager 3520 returns a resource list (AllocateResourceList) allocated to the VSM / DASS 3530 and the TV service viewing pipeline 3510, respectively (S3522 and S3524).
  • a resource list (AllocateResourceList) allocated to the VSM / DASS 3530 and the TV service viewing pipeline 3510, respectively (S3522 and S3524).
  • the VSM / DASS 3530 and the TV service viewing pipeline 3510 request a resource server client end transaction (ResourceManagerClientEndTransaction [Handle_vsm] and ResourceManagerClientEndTransaction [Handle_watch]) to the media server resource manager 3520 (S3526, S3526). S3528).
  • resource server client end transaction ResourceManagerClientEndTransaction [Handle_vsm] and ResourceManagerClientEndTransaction [Handle_watch]
  • the VSM / DASS 3530 and the TV service viewing pipeline 3510 request a resource server client manager 3520 to a resource manager client pipeline unregister (ResourceManagerClientUnregisterPipeline [Handle_vsm] and ResourceManagerClientUnregisterPipeline [Handle_watch]), respectively. S3530, S3532).
  • the VSM / DASS 3530 and the TV service viewing pipeline 3510 request the media server resource manager 3520 to remove the resource manager client (ResourceManagerClientDestroy [Handle_vsm] and ResourceManagerClientDestroy [Handle_watch]), respectively (S3534 and S3536).
  • the configuration related to the media pipeline call sequence includes a media pipeline 3610, a media server resource manager 3620, a VSM / DASS 3630, and the like.
  • the media pipeline 3610 and the VSM / DASS 3630 request the media server resource manager 3620 to create a resource manager client (ResourceManagerClienCreate [PolicyActionHandler]), respectively (S3602 and S3604).
  • ResourceManagerClienCreate [PolicyActionHandler]
  • the media server resource manager 3620 returns a resource manager client handle (ResourceManagerClientHandle) for each request of the media pipeline 3610 and the VSM / DASS 3630 (S3606 and S3608).
  • ResourceManagerClientHandle resource manager client handle
  • the media pipeline 3610 and the VSM / DASS 3630 request the resource server client pipeline registers (ResourceManagerClientRegisterPipeline [media_play] and ResourceManagerClientRegisterPipeline [vsm]) to the media server resource manager 3620, respectively (S3610 and S3612).
  • ResourceManagerClientRegisterPipeline [media_play] and ResourceManagerClientRegisterPipeline [vsm] ResourceManagerClientRegisterPipeline [vsm]
  • the media pipeline 3610 and the VSM / DASS 3630 request a resource server client start transaction (ResourceManagerClientStartTransaction [Handle_media], ResourceManagerClientStartTransaction [Handle_vsm]) to the media server resource manager 3620, respectively (S3614, S3616). .
  • the media pipeline 3610 and the VSM / DASS 3630 request the media server resource manager 3620 to obtain a resource manager client (ResourceManagerClientAcquire [Handle_media, resourceList], ResourceManagerClientAcquire (Handle_vsm, resourceList)), respectively ( S3618, S3620).
  • the media server resource manager 3620 returns a resource list (AllocateResourceList) allocated to the VSM / DASS 3630 and the media pipeline 3610, respectively (S3622 and S3624).
  • a resource list (AllocateResourceList) allocated to the VSM / DASS 3630 and the media pipeline 3610, respectively (S3622 and S3624).
  • the VSM / DASS 3630 and the media pipeline 3610 request a resource server client end transaction (ResourceManagerClientEndTransaction [Handle_vsm], ResourceManagerClientEndTransaction [Handle_media]) to the media server resource manager 3620, respectively (S3626, S3628). .
  • the VSM / DASS 3630 and the media pipeline 3610 request a resource server client pipeline unregister (ResourceManagerClientUnregisterPipeline [Handle_vsm] and ResourceManagerClientUnregisterPipeline [Handle_media]) to the media server resource manager 3620, respectively (S3630, S3632).
  • resource server client pipeline unregister ResourceManagerClientUnregisterPipeline [Handle_vsm] and ResourceManagerClientUnregisterPipeline [Handle_media]
  • the VSM / DASS 3630 and the TV service viewing pipeline 3610 request the media server resource manager 3620 to remove the resource manager client (ResourceManagerClientDestroy [Handle_vsm] and ResourceManagerClientDestroy [Handle_media]), respectively (S3634 and S3636).
  • TV middleware has a plan regarding resource usage. This will be described in detail with reference to FIGS. 42 to 44.
  • the resource manager in the media server does not directly handle TV resource management because it is complicated. For example, the resource manager in the media server allocates resources for the TV service, but detailed resource management for the TV service may be handled by the resource manager and the policy manager in the TV service processing module. In this regard, resource usage according to the TV service scenario will be described in detail with reference to FIGS. 45 to 49.
  • the resource manager of the media server may support the aforementioned resource sharing concept in order to handle TV resource management.
  • a processing method of the TV service processor and the resource manager / policy manager in the media server may be variously performed.
  • the resource manager of the media server determines all hardware resources.
  • the hardware resources may include not only hardware resources in the digital device but also hardware resources of another device paired with the digital device.
  • the resource manager also knows the types of resources used for a particular TV service scenario. This is for the resource manager to appropriately allocate the resource according to the request by the user as well as the TV service as well as services or applications in the overall device.
  • the TV service processor requests a resource manager / policy manager of a media server to allocate resources to perform the requested recording operation.
  • the resource manager / policy manager determines the status of the TV pipeline and determines the necessary resources based on the status. At this time, the state of the TV pipeline is changed, for example, from watching to recording.
  • the resource manager / policy manager returns the allocated resource information to the TV service processor based on the determined resources.
  • the resource manager in the media server may only return the available resources for the TV and media, unlike the example described above.
  • the TV service processor in connection with the TV service, the TV service processor must remember the state of the TV pipeline and determine for itself the necessary TV resources. That is, in the previous example, when the resource manager only requests a resource according to the TV service, the resource manager determines the resources required for the TV service and allocates them. By determining the resources required in the TV service, the resource manager requests the allocation of the determined resources and is allocated. In other words, in this example, the resource manager can handle only the grant for resource allocation and release.
  • the TV service processor determines a TV pipeline state and determines necessary resources accordingly.
  • the resource manager / policy manager requests the allocation of the determined resources to the resource manager / policy manager in the media server, and the resource manager / policy manager allocates the requested resources in response to the request and returns the allocated resource information to the TV service processor.
  • the TV resource manager provides resource sharing information to the TV pipeline manager.
  • the above-described resource configuration file may be used.
  • the TV resource manager may provide linkage information between the resources and the TV pipeline manager.
  • the TV resource manager also provides all resource information to the TV policy manager and also interfaces with the media server. That is, the TV resource manager may obtain resources from the media server including the real resources and return the resources back to the media server.
  • the resource configuration file is like a master plan of a TV service on how to use resources, and is a blueprint of how to use resources necessary for implementing TV-specific functions in a TV service. This may be represented or implemented in a table form and stored in advance.
  • the role of such a resource configuration file is, for example, to express what resources the TV service uses, to be available for resource sharing concepts, to enable resource sharing concepts regardless of device or pipeline status, and so on. .
  • a resource configuration file for a service is known in advance, and efficient use of limited resources is made possible by appropriately using resource sharing concepts for service (s) requests.
  • the resource configuration file is shown and described, for example in relation to a TV service, but the present invention is not limited thereto.
  • the resource configuration file may be stored in advance or downloaded from a paired external device or / and an external server, and may be used.
  • a media service and an application may be defined and used when necessary to perform an operation. .
  • a description will be given by taking an example of a TV service in which resource configuration is somewhat complicated.
  • 37 to 41 are diagrams for explaining a resource configuration file according to an embodiment of the present invention.
  • FIG. 37 relates to a single tuner model.
  • FIG. 37A illustrates a viewing operation
  • FIG. 37B illustrates a resource configuration file for a recording operation during the viewing operation of FIG. 37A.
  • Resources for viewing operations require, for example, ADTU (tuner), SDEC (system decoder), VDEC (video decoder) and ADEC (audio decoder), as shown in FIG. It can be arranged in a resource arrangement.
  • the viewing operation configuration file may be configured as shown.
  • the resource ADTU0 is currently used for viewing purposes, and the pipeline ID is 1, and it is possible to share with other uses other than the same use as [+ x] from the shareable point of view.
  • the resource SDEC0 is currently used for viewing purposes, and the pipeline ID is 1, and from the shareable point of view, it can be seen that the sharing can be shared with the turning on or transmitting use.
  • the resource VDEC0 is currently used for viewing purposes, and the pipeline ID is 1, and from the shareable point of view, it can be seen that the sharing can be shared with the switching use or the transmission use from [+ c + t].
  • the resource ADEC0 is currently used for viewing purposes, and the pipeline ID is 1, and it can be seen that the sharing purpose and sharing are possible with [+ t] from a shareable point of view.
  • FIG. 37B illustrates a case where a user makes a recording request during viewing as shown in FIG. 37A.
  • the recording operation configuration file is described below.
  • Resources for the recording operation for example, need ADTU and SDEC, which is included in the resources for the viewing operation, for example in FIG. 37A described above.
  • the recording operation configuration file may be configured, as shown.
  • the recording operation configuration file may use, for example, the viewing operation configuration file of FIG. 37A described above.
  • the TV resource manager checks whether a current resource ADTU has been acquired by the TV service, and checks if the resource ADTU has already been obtained and its use and sharing are possible. Therefore, referring to the configuration file of the resource ADTU0 illustrated in FIG. 37A, since the resource ADTU can be shared, the resource ADTU can be shared even if a resource acquisition request is not made to the resource manager of the media server.
  • the configuration file of resource ADTU0 is currently used for viewing and recording purposes, and the pipeline ID is 1 for viewing purposes and 2 for recording purposes, both from the shareable point of view, with [+ x] being the same as itself. It can be defined as shareable with other uses. Accordingly, the resource ADTU0 can be shared for a purpose other than the viewing purpose of FIG.
  • the resource SDEC since the TV middleware does not request sharing of the resource SDEC, the resource SDEC must request a resource acquisition from the resource manager of the media server.
  • the resource SDEC0 is the same as that of FIG. 37A described above, and is newly defined for the resource SDEC1 as follows.
  • the resource SDEC1 is currently used for recording purposes, and the pipeline ID is 2. However, the resource SDEC1 may not be specifically defined in view of the shareable.
  • FIG. 38 also relates to the single tuner model, but unlike FIG. 37, FIG. 38A illustrates a DTV viewing and DVR recording (HQ) operation, and FIG. 38B illustrates an input source changed to HDMI during the operation of FIG. It shows the resource configuration file.
  • FIG. 38A illustrates a DTV viewing and DVR recording (HQ) operation
  • FIG. 38B illustrates an input source changed to HDMI during the operation of FIG. It shows the resource configuration file.
  • FIG. 38B illustrates a case in which the input source is changed to HDMI in FIG. 38A.
  • resources required for the operation require SDEC, VDEC, and ADEC.
  • resource conflict occurs in the resource SDEC.
  • the DTV viewing pipeline is asked if it can release the SDEC resource. If resource SDEC0 is released, DTV viewing no longer makes sense. Accordingly, all resources related to the DTV viewing operation are removed from the viewing purpose. These resources may be released in full. Thus, resources SDEC, VDEC and ADEC can be obtained at once.
  • the configuration file configuration for the HDD viewing operation in FIG. 38B will be described.
  • the resource ADTU0 acquired for the DTV viewing operation and shared for the DVR recording operation is now used exclusively for the DVR recording operation.
  • the resource ADTU0 is currently used for recording purposes, the pipeline ID is 2, and the shareable view is [+ x].
  • Resource SDEC1 is currently used for recording purposes and pipeline ID is 2.
  • Resource SDEC0 is currently used for HDD viewing, pipeline ID is 1 (ID1 is not for the DTV viewing pipeline as the DTV viewing pipeline is removed), and the shareable view is [+ c + t].
  • Resource VDEC0 is currently used for HDD viewing, pipeline ID is 1, and is [+ c + t] in view of shareable.
  • Resource ADEC0 is currently used for HDD viewing, pipeline ID is 1, and is [+ t] in view of shareable.
  • FIG. 39A is a configuration file in the same state as in FIG. 38B described above.
  • FIG. 39B is a case where an input source is changed from HDMI to DTV and a DTV viewing operation is requested as shown in FIG. 38A.
  • a resource conflict of resource SDEC0 occurs again, and the HDD viewing pipeline receives a resource release request.
  • the resource SDEC0 is released, the HDD viewing is no longer meaningless, and all resources related to the HDD viewing are removed from the viewing purpose and released.
  • the resource ADTU is required for the DTV viewing purpose, it can be seen that the ADTU can be shared with all applications except the viewing purpose. Therefore, since the resource ADTU is used for DVR recording, the share being used can be shared with the present DTV viewing purpose.
  • 40A is for the DTV viewing operation as in FIG. 37A described above. Therefore, the detailed description thereof uses the description of FIG. 37A described above, and the detailed description thereof will be omitted.
  • FIG. 40B illustrates the configuration file configuration when the capture operation request in FIG. 40A described above is received.
  • the necessary resources are required, for example, ADTU, SDEC, VDEC and secondary scaler.
  • the TV resource manager checks whether the resources ADTU, SDEC and VDEC are currently acquired by the TV service, and if the resources are obtained, check whether the resources are in use for viewing. In this case, the resources can be shared without a resource acquisition request to the resource manager.
  • a resource acquisition request should be made to the resource manager.
  • the configuration file for the DTV viewing operation and the capture operation is configured as follows.
  • the resource ADTU0 is currently used for viewing and capturing purposes, the pipeline ID for the viewing purpose is 1, the pipeline ID for the capturing purpose is 2, and the shareable viewpoint is both [+ x].
  • the resource SDEC0 is the same as the resource ADTU, but only in a shareable view, [+ c + t] for a viewing purpose, and [+ w] for a capture purpose.
  • the case of the resource VDEC0 is the same as that of SDEC0 mentioned above.
  • resource ADEC0 is used for viewing only, pipeline ID is 1, shareable aspect is [+ t], resource secondary scaler is used for capture only, pipeline ID is 2, and shareable aspect is specially defined. It may not be.
  • Fig. 41A is the same as Fig. 40B described above, and the details thereof are omitted here.
  • 41B illustrates a case in which an output is transmitted from the DTV to the SCART.
  • the necessary resources are, for example, ADTU, SDEC, VDEC and Secondary Scaler.
  • Figs. 41A and 41B all except the resource ADEC are duplicated.
  • the resources ADTU, SDEC, and VDEC among the resources may be changed to the transmission operation after the capturing operation of FIG. 41A is completed.
  • the secondary scaler cannot be shared, a resource conflict occurs for the corresponding resource. That is, in view of resource conflict, the secondary scaler is different from the ADTU, SDEC, and VDEC.
  • the current pipeline receives a release request. If the resource secondary scaler is released, capture is no longer meaningless. Thus, all resources related to capture are released. Thereafter, it is checked whether the TV service processing unit is still acquiring the ADTU, SDEC, VDEC and ADEC.
  • the resource manager should request the acquisition of the resources for the transmission operation.
  • the TV resource manager may configure the configuration file for the DTV viewing operation and the SCART transmission operation as shown in FIG. 41B.
  • 42 to 49 are diagrams for explaining a resource arrangement configured for operation (s) according to an embodiment of the present invention.
  • FIG. 42 illustrates a resource arrangement using a resource sharing concept when simultaneously performing DTV viewing and DVR recording.
  • FIGS. 42A and 42B are for HQ
  • FIGS. 42C to 42E are for LQ.
  • FIG. 42A illustrates a resource arrangement when only an ADTU is shared among resources for performing DTV viewing and DVR recording (HQ).
  • the DTV viewing operation is output via the panel via the ADTU and DMX0 (demultiplexer), via the VDEC0 and the primary scaler, and audio data is output through the SPK (speaker) via the ADEC0.
  • the DVR recording operation is transmitted from the shared ADTU to the storage through DM1 and stored.
  • FIG. 42B illustrates a case where the DMX is also shared, unlike FIG. 42A described above.
  • the resource arrangement of the DTV viewing operation is the same as that of FIG. 42A, but the DVR recording operation is demultiplexed by the resource DMX0 obtained for viewing the DTV without going through DMX1 and stored directly in storage, unlike before.
  • FIG. 42C for example, two resources are shared. At this time, the two resources to be shared are ADTU and MUX (multiplexer).
  • the DTV viewing operation is the same as that of FIGS. 42A to 42B described above.
  • the resource arrangement for the DVR recording operation is different from the above-described FIGS. 42A to 42B.
  • a signal for DVR recording is demultiplexed into video data and audio data through DMX1, video data is transferred to MUX via VDEC1, secondary scaler and VENC, and audio data is passed through MUX via ADEC1 and AENC.
  • the video data is passed to the VENC and muxed and stored in storage.
  • FIG. 42D is similar to FIG. 42C described above, but differs only in that it shares to DMX other than ADTU as compared to FIG. 42C.
  • FIG. 42E more resources are shared than in FIG. 42C described above.
  • the ADTU and the DMX0 are shared, that is, the signal for the DTV viewing and the signal for the DVR recording operation are processed through the shared resources, and the DTV viewing operation and the DVR recording are performed on the DMX0.
  • the audio data for the DTV viewing operation is delivered to the SPK via ADEC0, and the audio data for the DVR recording operation is delivered to the MUX via the AENC, which is muxed with the video data delivered to the MUX via the VENC, to the storage. And stored.
  • FIG. 43 illustrates a resource arrangement when the DTV viewing operation and the second TV operation are simultaneously performed.
  • ADTU, DMX, VDEC, ADEC, and MUX are shared for a DTV viewing operation and a second TV operation.
  • the signals for the two operations are passed through the shared ADTU and DMX0, and all video data is passed to VDEC0, and all audio data is passed to ADEC0.
  • VDEC0 the video data for the DTV viewing operation is passed through the primary scaler and the panel, and the video data for the second TV operation is passed to the MUX via the secondary scaler and the VENC.
  • the audio data for the DTV viewing operation in ADEC0 is directly output to the SPK, and the audio data for the second TV operation is delivered to the MUX via AENC, and the video data transferred through the VENC from the MUX is transferred to storage.
  • VDEC and ADEC are not shared in FIG. 43A.
  • VDEC0 and ADEC0 are used for the DTV viewing operation
  • VDEC1 and ADEC1 are used for the second TV operation.
  • the DMX is not shared in FIG. 43B.
  • the signal for DTV viewing operation is processed through DMX0 through the shared ADTU, and the signal for second TV operation is processed through DMX1.
  • the signal for DTV viewing operation is processed through DMX0 through the shared ADTU, and the signal for second TV operation is processed through DMX1.
  • FIG. 44 relates to a resource arrangement shown for simultaneously performing a DTV viewing operation and SCART output.
  • the overall contents are similar to those of FIG. 43 described above, except that the SCART output is performed together with the DTV viewing operation in place of the secondary TV operation processing, and the resources for the SCART output are different.
  • FIG. 44A is characterized by sharing VDEC and ADEC following ADTU and DMX
  • FIG. 44B is characterized by not sharing VDEC and ADEC as compared to FIG. 44A
  • FIG. 44C is characterized in that the DMX is not shared as compared with FIG. 44B.
  • FIGS. 45 to 49 illustrate how the resource arrangement changes according to, for example, a TV scenario.
  • FIG. 45A is a resource arrangement for a DTV viewing operation
  • FIG. 45B is a resource arrangement for performing a DVR recording operation together with the DTV viewing operation according to a DVR recording request
  • FIG. 45C is an input source
  • FIG. 45D shows that the DVR recording operation is terminated in FIG. It illustrates a resource arrangement configured for viewing HDMI input.
  • FIGS. 45A to 45D sequentially illustrate changes in the resource arrangement configuration according to the change of the TV scenario, and vice versa.
  • the resource arrangement for DTV viewing is output to the panel via ADTU and DMX0, and through the VDEC0 and the primary scaler, audio data is output to the SPK via ADEC0.
  • FIG. 45A when a DVR recording operation execution request is received while performing a DTV viewing operation, as described above, whether to perform two operations simultaneously is determined based on the concept of resource sharing in consideration of resource conflict, resource acquisition, and the like. And, as shown, when the two operations can be performed simultaneously, the resource arrangement is as shown. For the two operations, the share of ADTU is sufficient. Therefore, after DMX0 through the shared ADTU is the same as the above-described FIG. 45A. However, for the DVR recording operation is stored in the storage through the DMX1 via the ADTU.
  • the resources are arranged as shown in FIG. 45C.
  • input sources of the DTV and the HDMI may be changed, and resources for the DTV viewing operation may be released.
  • the simultaneous execution of both operations is determined in consideration of resource conflicts between the HDMI input source change operation and the DVR recording operation. As shown, both can be performed concurrently.
  • the ADTU since the ADTU is shared with the DTV viewing operation in FIG. 45B, the ADTU may be used for the DVR operation, and the ADTU may be acquired again through the resource manager of the media server according to the resource release for the DTV viewing operation.
  • HDMI is output via the HDMI Rx (HDMI receiver), the video data through the primary scaler through the panel, audio data is output through the SPK via ADEC0.
  • the resources such as the primary scaler, the panel, the ADEC0, and the SPK are the same as the resources for the DTV viewing operation in FIG. 45B.
  • the media server is again used for the HDMI input operation. Resource allocated from the resource manager.
  • FIGS. 45B and 46B are similar to FIG. 45 described above. However, as shown in FIGS. 42 to 44, some resources share only a difference in which resources are shared to form a resource arrangement. For example, the difference between FIGS. 45B and 46B is the same as the difference between FIGS. 42A and 42C.
  • Figure 47a is a case of DTV viewing with a cam, the ADTU is shared, the viewing operation is performed via CI (Common Interface), DMX0, VDEC, ADEC, etc. Meanwhile, signaling information for the viewing operation is ADTU Via DMX2.
  • 47B to 47D are substantially the same as those of FIGS. 46B to 46D described above except for the difference of FIG. 47A.
  • FIGS. 45 to 47 describe a resource arrangement configuration method for implementing an operation in a single tuner
  • FIGS. 48 to 49 illustrate a resource arrangement configuration method for an operation implementation in a multi-tuner.
  • Video data is output to the VDEC0, the primary scaler, and the panel, and audio data is output to the ADEC0 and the SPK through the DTU and the DMX0.
  • FIG. 48B illustrates a request for performing a DVR recording operation during the DTV viewing operation. Since the DTV viewing operation is a multi-tuner, the DTV viewing operation has no resource arrangement change as described with FIG. 48A and a separate DTU (tuner) is allocated for the DVR recording operation. Is different from the above.
  • 48C illustrates a case in which an input source is changed from DTV to HDMI.
  • a separate tuner DTU is pre-assigned for the DVR recording operation, all resources for DTV viewing may be simply released. Separately, no contact or communication with the resource manager is required for DVR recording. In addition, it is sufficient to configure the resource arrangement of the pipeline for HDMI operation.
  • FIG. 48D illustrates a case where a change occurs between the DTV and the ATV in FIG. 48B. That is, if FIG. 48B illustrates a resource arrangement for simultaneously performing a DTV viewing operation and a DVR recording operation, FIG. 48D illustrates a resource arrangement configured to simultaneously perform an ATV viewing operation and a DVR recording operation.
  • FIG. 48 assumes a multi-tuner, the resource arrangement for the DVR recording operation is still not affected at all. However, all resources for the DTV viewing operation are released, and only a resource arrangement for the ATV viewing operation needs to be configured.
  • FIG. 48E When recording is stopped or terminated in FIG. 48C, a resource arrangement is configured as shown in FIG. 48E. However, if the recording stops or stops in FIG. 48D, the resource arrangement is configured as shown in FIG. 48F. This is fully explained with reference to FIGS. 45 to 47 described above.
  • FIG. 49 is similar to the above-described FIG. 48, but merely a resource arrangement is implemented by slightly different shared resources among resources required when simultaneously performing each operation or a plurality of operations. Therefore, the general contents are similar to those of FIG. 48 described above, and the descriptions thereof are mutatis mutandis and detailed description thereof will be omitted.
  • FIG. 50 is a diagram illustrating service restructure according to an embodiment of the present invention.
  • the TV service structure of the conventional broadcast receiver is difficult to process the TV service in a webOS based digital device.
  • Conventional broadcast receivers have a finite state machine (FSM) to use MRE, a system-based state machine.
  • FSM finite state machine
  • the conventional broadcast receiver is fixed in the resource path (resource path) is less flexible or expandable.
  • the conventional broadcast receiver cannot distinguish between the UX scenario and the resource limit scenario. For example, although resource limitations have disappeared, conventional broadcast receivers are difficult to eliminate resource limitation scenarios. Therefore, in the present specification, in order to enable the TV service to operate smoothly on the WebOS platform, the TV service is to be restructured as follows.
  • the MRE used in the conventional broadcast receiver is not used. That is, it does not use a centralized state machine.
  • the TV service may be restructured.
  • the TV Pipeline Manager / TV Pipeline establishes a path when there is an input change or performs a particular function.
  • the TV resource manager allocates resources in each state, and the path manager provides path information.
  • the TV service is ported to the WebOS. This is to restructure as shown in Figure 50 to use a system-based virtual pipeline (Pseudo Pipeline).
  • the WebOS platform it separates the UX scenario from the resource limit scenario. In other words, the resource limit scenario is handled by the TV policy manager or the TV pipeline manager.
  • the hardware resource manager receives a load request (Load tv: //), and the media server defines a hardware resource configuration file.
  • the hardware resource manager allocates resources based on the defined hardware resource configuration file.
  • the hardware resource manager also receives class information from a hardware resource pool.
  • the hardware resource manager generates path information (ex, TU1 object-SDEC0 object-VDEC1 object-DE1 object) and transmits it to the TV pipeline, and the TV pipeline configures the pipeline based on the transmitted path information.
  • each object makes an open request (eg, TU1 open to TU driver, SDEC0 open to SDEC driver) with corresponding drivers of the TV middleware. This opens the drivers associated with the object and configures path control.
  • an open request eg, TU1 open to TU driver, SDEC0 open to SDEC driver
  • CM Thread channel manager thread
  • 51 is a diagram illustrating service restructuring according to another embodiment of the present invention.
  • the process of processing the upper end of the TV pipeline is the same as the process of processing the upper part of the TV pipeline of FIG. 50 described above, and the above description is used, and detailed description thereof will be omitted. Therefore, the stage below the TV pipeline is mainly described here.
  • FIGS. 50 and 51 the biggest difference between FIGS. 50 and 51 lies in the configuration of the TV pipeline.
  • FIG. 51 if the virtual pipeline is configured for porting TV service to WebOS, FIG. 51 is to replace the MRE supported by the conventional TV service. Accordingly, the TV service restructuring illustrated in FIG. 51 differs from the conventional TV service in, for example, functions such as a TV pipeline manager, a TV resource manager, a path manager, and the like related to the TV pipeline.
  • FIG. 51 In contrast to configuring the virtual pipeline in FIG. 50, referring to FIG. 51, it can be seen that more resources are arranged with each other in relation to the TV service for which the configuration of the TV pipeline is requested. In addition, unlike FIG. 50, FIG. 51 may handle the drivers for the resources in the TV middleware stage directly, rather than in the TV pipeline stage. These can be seen, for example, as the difference between FIGS. 50 and 51.
  • the resource arrangement for channel change to the TV service in the TV pipeline is composed of TU-SDEC-VDEC-DE objects, as shown in FIG. 50.
  • the arrangement of such an object can be seen, for example, as showing the basic resources for the TV service.
  • FIG. 50 if only basic resources are arranged, subsequent processing is performed by connecting related drivers and resources in TV middleware. However, in FIG. 51, the load is minimized by minimizing the intervention of the TV middleware stage, and the driver for resources and connection can be handled directly by the TV pipeline stage for fast processing.
  • the TV pipeline for the channel change TV service of FIG. 51 is arranged in the order of TU-SDEC0-PSIP-VEDC1-DE1-VIDEO sync.
  • a data broadcasting component may be arranged between the SDEC0 object and the PSIP component as necessary, and an EPG sink, a channel list sink, and the like may be arranged between the PSIP component and the VDEC1 object as needed, and the VDEC1 and DE1 objects may be arranged.
  • the ACC sink may be further arranged in between.
  • the TV pipeline stage directly handles driver opening for connection with hardware resources such as objects, components, and sinks arranged in the pipeline.
  • the TV pipeline configuration configured for the channel change service is an example illustrated for the convenience of description and convenience of description, and is not limited to the illustrated.
  • the PSIP component may be changed to a DVB component or the like as defined in a standard related to a signal, and a PSI component may be further added.
  • resources are properly arranged using the resource sharing concept.
  • resources in digital devices for services or applications are limited. Therefore, in order to support the service or application in the webOS of the present invention, it is necessary to arrange limited resources appropriately, and in particular, it is essential to support multi-tasking in the webOS platform.
  • resources are needed and one or more resources are likely to cause resource conflicts.
  • policy management which will be described in more detail below, functions. Meanwhile, the policy management will be described below as a policy action in some cases.
  • the policy management according to the present invention can be largely handled by the centralized policy manager and the distributed policy manager.
  • 52 illustrates the centralized policy manager
  • FIG. 53 illustrates the distributed policy manager.
  • FIG. 52 is a view illustrating a policy management according to an embodiment of the present invention.
  • Policy is intuitive because it applies to each pipeline by default. If a resource conflict occurs, only the resource manager of the media server needs to consider the policy. In other words, the pipeline (s) do not have to consider policy. This is because the resource manager may arrange resources in each pipeline in consideration of polis.
  • the centralized policy manager if there is a common policy to apply common on the TV system, it is easy to apply and can reduce the load. In other words, one or more resources or modules associated with a pipeline may not necessarily take into account complex policies to reduce load. This can be interpreted to mean that a consistent policy application is required for digital devices.
  • the centralized policy manager since the policy manager must care about all the policies in the digital device, there is a fear that the code becomes complicated.
  • the code may be more complicated because the policy must be defined to handle not only the common policy but also various exceptions related to a service or an application that is difficult to solve the common policy. For this reason, if the centralized policy manager is employed, the media server's code quality and reusability may be degraded. If a new pipeline is added, the privacy with all existing pipelines There may be a burden of having to re-compare, etc., and re-rank accordingly.
  • processing such as resource arrangement may be complicated.
  • the media pipeline 5210 for viewing requires VDEC1, ATP1, and ADCE1 resources for viewing.
  • the TV service 5230 has three pipelines. It includes the viewing pipeline, the recording pipeline, and the capture pipeline.
  • the viewing pipeline requires resources of TU0, SDEC0, VDEC0, ATP0, ADEC0
  • the recording pipeline requires TU0, SDEC1 resources
  • the capture pipeline requires TU0, SDEC0, VDEO0, and Secondary Scaler resources.
  • the camera pipeline 5240 also requires Camera, VENC0, AENC0 resources for viewing.
  • the resource manager 5220 in the media server allocates appropriately requested resource (s) to the pipeline.
  • the resource manager 5220 may instruct allocation to share TU0 resources commonly required for the three pipelines according to a resource sharing scheme among resources required by the viewing, recording, and capture pipelines in a TV service. And assign allocations to share SDEC0 and VDEC0 resources for viewing and capture pipelines.
  • the resource manager should not only consider the pipelines of the TV service but also consider the resources required by the media pipeline and the camera pipeline.
  • the resource manager 5220 may store resource allocation priority data in advance for each service and / or pipeline and allocate resources based thereon.
  • the resource manager may instruct the resource manager to properly allocate or share resources required by each pipeline according to pre-stored resource allocation priorities for TV viewing, TV recording, TV capture, media viewing, camera viewing, and the like.
  • the resource may be allocated to the higher priority pipeline based on the priority, and the resource allocation rejection may be returned for the lower priority pipeline (s).
  • resource allocation based on priority becomes a function of the policy manager in consideration of the possibility of resource conflict.
  • the resource manager will conflict with the created pipeline for the resource (s) allocated for the previously created pipeline (s).
  • the policy based on the above priority is appropriately determined as to which resources to release and which pipelines to release the released resources.
  • the resource release or allocation may be determined in consideration of Least Recently Used (LRU) data in some cases.
  • 53 is a view illustrating a policy management according to another embodiment of the present invention.
  • FIG. 53 illustrates a distributed policy manager.
  • the distributed policy manager there is greater independence between services than a centralized policy manager.
  • the code becomes complicated considering exception handling for various services in the centralized policy manager
  • the distributed policy manager the exception handling of the service is handled internally by the corresponding service.
  • the resource manager in the media server does not have to care about all the policies on the digital device, which simplifies the code and makes the resource management higher than the centralized policy manager.
  • the policy is processed separately for each service unit, so that the module that knows the best about the service can manage the policy, and the privacy can be easily applied when adding a new pipeline.
  • the distributed policy management of FIG. 53 is similar to that of FIG. 52 described above, and a description of common content thereof is omitted herein, and the above description is referred to. Therefore, hereinafter, the description will focus on the parts different from the above-described centralized policy management method.
  • the centralized policy management scheme of FIG. 52 may be a service unit, whereas the centralized policy management scheme of FIG. 52 is a pipeline unit. Meanwhile, the distributed policy management of FIG. 53 may also manage policy based on priority or / and LRU, similarly to the centralized policy management method of 52.
  • the media server is only responsible for the minimum load, and the specific contents are left to the corresponding service.
  • the media server predetermines and stores priority data only for TV, media, and camera services. Therefore, when a resource request is received from each service, the media server allocates resources to the service based on the priority of the service and / or the LRU. Such a processing flow considers a concern about resource conflict at every resource request in each service. When the resource conflict situation occurs as a result of the consideration, policy management is performed.
  • the centralized policy management method of FIG. 52 and the distributed policy management method of FIG. 53 may be appropriately mixed according to circumstances.
  • the media server examines whether there is a concern of resource conflict in the service unit based on the distributed policy management scheme as shown in FIG. 53, and allocates the resource based on the result. do.
  • the media server continuously allocates resources in service units according to the distributed policy management scheme, and allocates resources based on the case where a plurality of pipelines are generated in the corresponding service.
  • resources can be allocated on a per-pipeline basis within a given service, centralized.
  • the media server may use the centralized scheme if the distributed scheme is multiple pipelines. The reverse is also possible. In addition, it may be processed based on the distributed method only when there are a plurality of services requesting resources.
  • 54 to 57 illustrate a policy management method between a TV service and a media pipeline according to an embodiment of the present invention.
  • a viewing pipeline (A) in 2D (2-Dimensional) mode and a viewing pipeline (B) in 3D (3-Dimensional) mode are generated as a TV service, and a pipe for 2D playback is used as a media pipeline.
  • Line C is shown.
  • the 2D mode viewing pipeline A requires ADTU, SDEC0, VDEC0, ATP0 and ADEC0 resources
  • the 3D mode viewing pipeline B includes ADTU, SDEC0, VDEC0, ATP0, ADEC0 and VDEC1 resources.
  • Media pipeline C requires VDEC1, ATP1 and ADEC1 resources.
  • letters A, B, and C are shown for convenience in describing each pipeline. However, in another embodiment, the alphabet may mean, for example, policy priority, pipeline generation order, or resource allocation request order. In the following description, it is assumed that only the respective pipelines are meant for convenience, but as described above, the present invention is not limited thereto.
  • the media server when a resource allocation request is made in the C pipeline after resource allocation for the A and B pipelines, the media server has a conflict between the VDEC1 resources in the B pipeline and the VDEC1 resources in the C pipeline.
  • Deny resource allocation request Alternatively, if resource allocation is requested in the B pipeline after resource allocation for the A and C pipelines, a resource conflict occurs between the B and C pipelines as described above.
  • the TV service is given priority, that is, the priority is higher, so that it is controlled to release the allocated resource in the C pipeline to which the existing VDEC1 resource is allocated.
  • the TV service according to the A and B pipelines is eventually provided in the TV.
  • the webOS device in this case, is a TV service. You can inquire about resource release. In this case, the digital device may query the user's selection in the form of a GUI or OSD message. If the user chooses to remove the 3D mode viewing pipeline, the media pipeline can be allocated a VDEC resource. However, if the user does not want to remove the 3D mode viewing pipeline, the TV service will reject the policy manager's policy. Thus, the media pipeline does not acquire VDEC resources.
  • the resource manager may request the VDEC resource allocation according to the B pipeline.
  • the resource manager may request the release of the VDEC resource through a media pipeline.
  • the policy management is made differently in the conventional smart TV and in the webOS device according to the present invention.
  • FIG. 55 shows a viewing pipeline A in 2D mode as a TV service, and a 2D playback pipeline B and a 3D playback pipeline C as media pipelines.
  • FIG. 55 there is a likelihood of conflicting VDEC0 resources between the A and C pipelines.
  • the conventional smart TV when a resource request is made in the C pipeline after resource allocation for the A and B pipelines, the conventional smart TV processes to release pre-allocated resources for the A pipeline, and after resource allocation for the A and C pipelines.
  • a resource request is made in the B pipeline, as described above, the pre-allocated resource for the A pipeline is released.
  • resource requests in pipeline B after pipeline allocation for C and A pipelines are sequentially released, resources in pipeline A are released in the same way. Resource allocation request of is denied.
  • the processing is as follows.
  • the C pipeline requests a resource allocation after the resource allocation for the A and B pipelines, and the C pipeline requests the resource allocation after the resource allocation in the S and B pipelines sequentially, the C If the pipeline is a media service request via PIP, then the request of the C pipeline is rejected. However, if the C pipeline is a full-screen media service request, it must make a VDEC resource request to the media server. In this case, the media server requests a VDEC release to the TV service. Thus, the A pipeline releases VDEC resources.
  • the media server makes a VDEC release request to the media pipeline.
  • the TV service will be allocated a VDEC resource and the TV service will be available, but otherwise the media pipeline will reject the policy and eventually the TV service will not be able to obtain the VDEC resource. TV service becomes impossible.
  • FIG. 56 shows a viewing pipeline A, a recording pipeline B, and a 2D playback pipeline C as a media pipeline according to component input to a TV service.
  • the A pipeline requires VADC0, AADC0 and ADEC0 resources
  • the B pipeline requires ADTU, SDEC0, VDEC0, Secondary Scaler, VENC, ATP0, ADEC1, AENC and MUX resources
  • C pipe The line requires VDEC1, ATP1 and ADEC1 resources.
  • FIG. 56 there is a potential conflict of ADEC1 resources between the B and C pipelines.
  • a resource request in the C pipeline after resource allocation for the A and B pipelines a resource request in the B pipeline after the resource allocation for the A and C pipelines, and a resource for the C and A pipelines
  • resource requests are made in pipeline B after allocation and in pipeline A after resource allocation for pipelines C and B, in each case, when the PIP screen is requested from the pipeline that made the last resource request. All PIP screen requests are rejected.
  • FIG. 57 shows a pipeline A as a TV service and a 2D playback pipeline B and a 3D playback pipeline C as a media pipeline.
  • FIG. 57 there is a potential for conflict of VDEC0 and ADEC1 resources between the TV service and the media pipeline.
  • the C pipeline should release resources that have been denied or previously allocated.
  • the webOS device requests the release of the VDEC resource from the media server to the TV service, but the TV service number rejects the policy, and consequently, the media pipeline is not allocated the VDEC resource. Accordingly, in this case, the service may not be available in all cases except for the termination of the TV service, any resource release, etc. due to VDEC0 resources in the C pipeline.
  • 58 is a diagram illustrating a policy scenario between TV pipelines according to an embodiment of the present invention.
  • FIG. 58 may refer to the distributed policy management of FIG. 53 rather than the centralized policy management of FIG. 52 described above.
  • the media server and the TV service processing unit function.
  • the media server functions as a resource manager 5820 and a policy manager 5850, and there may be one or more media pipelines for media services in relation to the media server.
  • the TV service processor also functions as a TV resource manager 5830 and a TV policy manager 5560 to control one or more TV pipelines for TV service.
  • the resource (s) such as tuner are the resource (s) for TV service only.
  • the TV resource manager can recognize the resource conflict by itself. If the resource conflict is detected prior to resource acquisition, the TV policy manager 5560 may properly handle the resource conflict.
  • the TV resource manager 5830 inquires whether the resource conflict is through the TV policy manager.
  • the TV policy manager 5560 requests a resource release of the TV pipeline 2 5870 to process the resource conflict through the query.
  • this is a case where a resource conflict occurs.
  • the TV resource manager 5830 requests resource allocation to the resource manager 5820 of the media server, or receives a resource from the media server resource manager 5820 if a conflict occurs or not. Allocates the resource allocated to line 1 (5840).
  • FIG. 58 for example, only TV pipelines (TV Pipeline 1 5840, TV Pipeline 2 5870, etc.) were present.
  • TV pipelines TV Pipeline 1 5840, TV Pipeline 2 5870, etc.
  • a case in which one or more media pipelines 5810 exist is as follows.
  • 59 to 60 are diagrams for explaining a policy scenario between a TV pipeline and a media pipeline according to an embodiment of the present invention.
  • the TV resource manager 5930 may request a resource manager (eg, a resource manager of the media server) to acquire resources in response to the request. 5920), requesting resource allocation.
  • the resource manager 5920 of the media server queries the policy manager 5950 for resource conflict.
  • the policy manager 5950 of the media server requests the release of resources that have been previously allocated to the media pipeline according to the request of the resource manager 5920.
  • the resource manager 5920 of the media server allocates the resource requested by the TV resource manager 5930.
  • the TV resource manager 5930 allocates the obtained resource to the TV pipeline 1 5940.
  • the TV pipeline 1 6040 requests a resource allocation to the TV resource manager 6030, and the TV resource manager 6030 allocates the resource to the resource manager 6020 of the media server in response to the request.
  • the resource manager 6020 of the media server inquires of the policy manager 6050 of the media server whether the resource conflict is present.
  • the policy manager 6050 requests the media pipeline 6010 to release the resource when a resource conflict occurs. If the media pipeline 6010 responds that it rejects the request of the policy manager 6050, the policy manager 6050 reports to the resource manager 6020 that the release has been rejected, and the resource manager 6020 of the media server. Responds to the TV resource manager 6030 that resource allocation is not possible.
  • the TV resource manager 6030 passes this back to the TV pipeline 1 6040.
  • the media pipeline 5910 responds to the release request of the policy manager 5950, but in FIG. 60, the rejection request is different.
  • 61 to 62 are diagrams for explaining a policy scenario between a TV pipeline and a media pipeline according to another embodiment of the present invention.
  • 61 and 62 show a process in the case where the requested resource is a resource already acquired in the TV pipeline when a resource is requested in the media pipeline, in contrast to FIGS. 59 to 60 described above.
  • the resource manager 6120 inquires of the policy manager 6150 to determine whether a resource is conflicted.
  • the policy manager 6150 of the media server requests the TV policy manager 6160 to release the resource in which the conflict has occurred.
  • a resource release request is received from the media server policy manager 6150, a resource release session is requested to the TV resource manager 6130.
  • the TV resource manager 6130 transmits the resource release session request of the policy manager 6150 to the TV pipe.
  • the TV pipeline 16140 is responsible for TV resource release according to the delivered resource release session request.
  • the TV resource manager 6130 requests the release of the corresponding resource to the media server resource manager 6120.
  • the media server resource manager 6120 releases the content from the TV service. Assign resources to the media pipeline 6110.
  • FIG. 62 is similar to FIG. 61 described above, but when the media server policy manager 6250 requests the TV policy manager to release a resource having a conflict, the release is rejected. In this case, the media server policy manager 6250 informs the media server resource manager 6220 that the release has been rejected, and the media server resource manager 96220 notifies the media pipeline 6210 that resource allocation is not possible again. .
  • the service or application includes a PIP (Picture in Picture) service or a PIP application provided by a digital device. Therefore, hereinafter, a digital device processing a PIP service or an application and a processing method thereof will be described in detail with reference to the accompanying drawings.
  • PIP Picture in Picture
  • FIG. 63 is a diagram illustrating a video sink manager (VSM) according to an embodiment of the present invention.
  • a single application may have a single or multiple windows.
  • the VSM 6370 may know all video sources controlled by the hardware of the digital device. This is because the pipelines 6360 and 6380 register an identifier ID and a port VDEC to the VSM 6370. The VSM 6370 also provides the application with the ability to connect each source to the display engine 6390.
  • the display engine 6300 includes a main and a sub.
  • the LSM 6310 may determine whether the application is main.
  • the LSM 6310 may transmit a lifecycle event to the application.
  • the lifecycle event may include, for example, a foreground event and a background event.
  • the application may request the VSM 6370 to connect the video source to the display engine 6390.
  • the foreground application 6330 receives a foreground event from the LSM 6310 with one video source
  • the foreground application 6330 requests the VSM 6370 to connect the video source to the display engine 6300.
  • the background application 6330 receives a background event from the LSM 6310 with one video source
  • the VSM 6370 may not connect or disconnect the video source to the display engine 6390. Ask.
  • the foreground application 6330 connects the video source to the display engine 6390 after the pipeline is loaded to display the video. Meanwhile, the background application 6149 may disconnect the video source from the display engine 6390 before the pipeline unloads.
  • the video source i.e., pipeline 6360, requests a register of pipelineID with decoder information at loading time to VSM 6370.
  • the video source (pipeline) 6380 requests the VSM 6370 to unregister the pipelineID at the time of unloading.
  • the application is a web application
  • a web kit, media plug-in and flash plug-in may handle the connect and disconnect on behalf of the application.
  • Each application requests a media server 6320 and 6350 to load, play, and pause a video source, and the media server 6320 and 6350 respond to the request. Create pipelines 6360 and 6380.
  • 64 is a diagram illustrating a concept of a source and a sink in relation to video processing according to an embodiment of the present invention.
  • FIG. 64A illustrates an input stack
  • FIG. 64B illustrates a rendering stack
  • a video path consists of a video source and a video sink.
  • a graphic path is composed of a graphic source and a graphic sink.
  • the video surface from the video source and the graphic surface from the graphic source are composited into the display surface through the video sink and the graphic sink.
  • the input stack of FIG. 64A is for controlling a video source and a graphic source
  • the rendering stack of FIG. 64B is for controlling a video sink and a graphic sink.
  • a controller of an input stack for a video source is a media server (uMediaServer), a TV broadcast service, various media pipelines, and the like.
  • the controllers of the rendering stack for the video sink are a VSM, a TV display service, and the like.
  • the controllers of the input stack for the graphics source are all applications based on web kits, browsers, QTs, ie, various graphics engines.
  • controllers of the rendering stack for the graphics sink are compositors of the LSM and GM.
  • the VTG can be delivered from the video sink to the graphics source, and the subtitle can be controlled from the input stack.
  • the size and position of the subtitle may be related to the video surface rather than the display service.
  • 65 is a diagram illustrating controlling video input in an input stack and a rendering stack according to an embodiment of the present invention.
  • FIG. 65A shows the input stack and FIG. 65B shows the rendering stack.
  • the media server uMediaServer may delegate the control requested by the application to the media pipeline.
  • the application may be a web kit (video tag), or a media plug-in or a flash plug-in.
  • the application 6520 requests a pipeline loading with the URL to the media server 6630.
  • Media server 6630 creates media pipeline 6540 based on the request.
  • the media pipeline 6540 After obtaining the VDEC, the media pipeline 6540 requests the VSM 6050 to register the mediaID and the VDEC port.
  • the current state of the media pipeline 6540 is a pause state, and the media server 6630 sends a load complete to the application 6520.
  • the application When the application receives a load complete from the media server 6630, the application requests the VSM 6550 to associate the mediaID with the display engine 6560.
  • the VSM 6550 connects the VDEC port of the registered mediaID with the physical display engine 6560.
  • the application 6520 asks the display service to control the size and position of the display window.
  • the size, position, etc. of the display window may be pos ⁇ x, y, w, h ⁇ by default.
  • the application 6520 then requests the media server 6630 for pipeline playback, at which time the A / V is stopped and muted.
  • Media pipeline 6540 sends video format information to the display service after playback.
  • LSM 6510 sends a lifecycle message for the foreground or background to application 6520.
  • the application 6520 requests the VSM 6550 to connect a mediaID to the display engine 6560. Meanwhile, when the lifecycle message is in the background, the application 6520 may request the VSM 6550 to disconnect the mediaID from the display engine 6560.
  • the application 6520 may request control of the new size, position, and the like of the display window from the display service if desired.
  • 66 to 69 are diagrams for explaining sequence diagrams for various scenarios occurring in a web application according to one embodiment of the present invention.
  • FIG. 66 a sequence diagram for a scenario of loading a pipeline in a foreground application will be described.
  • Application 6610 with video source requests pipeline load to media server 6620 via webkit 6612 with video tag.
  • the media server 6620 generates a media pipeline 6622 according to the request, and registers the generated media pipeline 6622 mediaID and a VDEC port for processing a video source in the VSM 6630.
  • the media server 6620 receives the load complete message received from the VSM 6630 via the media pipeline 6622 and forwards it to the web kit 6612.
  • the web kit 6612 requests the VSM 6630 to connect with the display engine 6640, and the VSM 6630 controls the application with the display engine 6640 because the application is in the foreground.
  • the application 6610 may request a setting of a display window size, a position, etc. as necessary.
  • the media server 6620 when the media server 6620 makes a play request, the media server 6620 passes the generated media pipeline 6622 to the media pipeline 6622 based on the media video.
  • Pipeline loading is performed in the foreground application by requesting data settings from the display engine 6640.
  • FIG. 67 a sequence diagram for a scenario in which an application goes to the background is described.
  • the LSM knows the lifecycle messages of the application. Thus, if the application needs to go in the background, the LSM sends a minimized message to the application, i.e., the webkit.
  • the web kit When the web kit receives the minimization from the LSM as described above, the web kit requests the VSM to disconnect with the display engine based on the minimization. Then, the webkit makes a pause request to the media server simultaneously with or after the disconnect request. However, the pose request may be optional. When the web kit makes a disconnect request or a pause request is received, the media server requests or commands a state change from play to pose to the generated media pipeline.
  • FIG. 68 a sequence of a scenario in which the application goes from the foreground to the background in FIG. 67 and goes back to the foreground as shown in FIG. 66 will be described.
  • the LSM Since the LSM is aware of the scenario, i.e. the life cycle of the application, as described above, the LSM transfers full-screen rather than minimized to the application or webkit.
  • the web kit In response to the full-screen reception of the LSM, the web kit requests the VSM to connect to the display engine again.
  • the web kit makes a play request to the media server simultaneously with or after the connect request. However, the play request may be optional.
  • the media server requests or commands a state change from pose to play back to the media pipeline.
  • FIG. 69 the sequence for the scenario of unloading the pipeline in the foreground application will be described following FIGS. 66 to 68.
  • the application or web kit requests a stop to the media server, and the VSM requests to disconnect from the display engine.
  • the stop request may be replaced and optional by the disconnect request, for example.
  • the media server receives a stop request, it requests or commands the media pipeline to change state from play to stop.
  • the webkit makes an unload request to the media server concurrently with or after the disconnect request.
  • the media server transfers it to the media pipeline, and the media pipeline requests an unregister to the VSM when the unload request is received.
  • Unloading the pipeline in the foreground application may be performed through the above-described process.
  • 70 is a view illustrating a PIP issue according to an embodiment of the present invention.
  • main and sub-concepts are conceptual, for example, which can be mapped anywhere in the hardware block.
  • the hardware block may vary by each SoC.
  • the VSM provides an interface for connecting the video source with the main sync or sub sync.
  • the main sink has more powerful performance than the sub sink, and only the main sink can support full picture quality.
  • the main sync can be used. At this time, it is irrelevant when the size of the video source itself is full size or not the full size.
  • the main sink is used for the large size on the display and the service sink is used for the small size, but is not necessarily limited thereto.
  • the service sink is used for the small size, but is not necessarily limited thereto.
  • either of the two sinks will be the main sink by the UX.
  • the above description is made from the viewpoint of a video source, but may be described from the viewpoint of an application.
  • an application may have one video source, but may have multiple video sources. Therefore, the same can be applied to the PIP scenario in the latter case.
  • the PIP scenario may be as follows.
  • a single application has two video sources on the display. If the single application has more than one pipeline, one of them can be unloaded by the resource manager or policy manager.
  • the PIP scenario for supporting various scenarios occurring on the display in relation to an application, a video source, a menu, etc. is not limited thereto.
  • FIG. 70A shows two applications in the foreground, full-video for full-screen applications, and PIP video in PIP applications, as in the first of the PIP scenarios described above.
  • the portion where the PIP video is output may be referred to as a PIP screen, a sub screen, or the like.
  • the portion where full-video is provided may be referred to as full-screen, main screen, or the like.
  • Figure 70b is implemented as one application has two video sources, as in the second of the above-described PIP scenario, wherein the first video source is provided in full-video, the second video source Is provided as a PIP video.
  • FIG. 71 is a diagram illustrating a PIP scenario when two applications exist in the foreground, as shown in FIG. 70A, and FIGS. 72 to 75 illustrate a PIP sequence on a web application according to an embodiment of the present invention. Figure is for explaining.
  • the LSM may support at least two foreground applications, in which case the LSM may know not only which application is the foreground, but which foreground application is full-screen and which application is the PIP screen. For example, if there are two foreground applications, the first application is a full-screen application and the second foreground application is a PIP application.
  • the video source of the full-screen application is connected to the main sink and the video source of the PIP screen is connected to the sub sink.
  • LSM can support two types of Windows lifecycle messages: one full-screen for foreground and the other minimized for background.
  • Windows lifecycle messages two types of Windows lifecycle messages: one full-screen for foreground and the other minimized for background.
  • both applications are in the foreground, based on the type of window lifecycle message described above, both will receive full-screen messages. Therefore, in this case, the window lifecycle message alone cannot distinguish between a full-screen application and a PIP application for two foreground applications.
  • the types of window lifecycles are defined as full-screen, mid-sized and minimized.
  • the full-screen type message is delivered to the application going to the full screen.
  • Mid-sized type messages are delivered to the application going to the PIP.
  • the minimized type message is then passed to the application going to the background.
  • terms such as mid-size are arbitrary, and other terms for PIP may be used. Therefore, the content of the present invention is not limited to the above terms.
  • window lifecycle type may also define focus and unfocus states in the foreground.
  • the background application is a PIP application and the mini-mized message delivered from the LSM is changed to a mid-size message.
  • the contents of the foreground application and the background application described in FIG. 63 are changed to only the full-screen application and the PIP application. Therefore, overlapping description of the above-described contents of FIG. 63 is used, and detailed description thereof will not be given here, and the description will be given based on different parts.
  • the PIP application When an application receives a mid-size message from the LSM, it knows that the application is a PIP application. Thus, the PIP application requests the VSM to connect to the subsink for the video source. This is different from the background application requesting a disconnect in FIG. 63 described above. This is because the background application does not have to be displayed on the screen, but the PIP application is displayed on the screen.
  • an application receives a full-screen message from the LSM, it can be seen that the application is a full-screen application.
  • a full-screen application connects the video source to the main with the VSM. This is similar to the operation of the foreground application described above.
  • the application when the application receives a mini-mized message, the application becomes a background application and makes a video source and main or sub and disconnect request to the VSM, which is similar to the operation of the background application described in FIG. .
  • the LSM requests resize for a sub sink to a display service or the LSM transmits size and position information together in transmitting a mid-size message to an application, and the application sub There is a method of directly making a resize request for a sink to a display service.
  • the LSM knows the lifecycle message of the application. Thus, if the application needs to go to the PIP, the LSM sends a mid-size message to the PIP application, i.e., the webkit, and, as described above, sends coordinate information about the size and position in the display of the PIP application.
  • the PIP application i.e., the webkit
  • the web kit When the web kit receives the mid-sized message and the coordinate information from the LSM as described above, the web kit requests a disconnect from the display engine including the mediaID to the main sink based on the mid-sized message. At this time, the WebKid requests a connection with a sub-sink among display engines including the mediaID together with the disconnect request. Meanwhile, the web kit transmits the requested coordinate information to a sub sink of a media display engine at the same time as or after the disconnect and connect request, and requests a setting.
  • the application is in the foreground, but if it is a PIP application, it will follow the sequence described above.
  • FIG. 73 illustrates, for example, a PIP sequence for this when the PIP screen is moved after the PIP screen is generated or output as shown in FIG. 72.
  • the PIP screen may be fixed at all times but may move within the display.
  • the LSM transmits the change coordinates of the moving PIP screen to the web kit again, transfers the change coordinates received from the web kit to the sub of the display engine, and requests the coordinate change setting.
  • FIG. 74 illustrates a sequence, for example, when the PIP application goes full-screen.
  • the PIP application also knows that it has become a full-screen application when sending a full-screen message (lifecycle message) from the LSM, because it does not know whether it is changed from PIP to full-screen.
  • the web kit When the full-screen message is received, the web kit transmits a mediaID to the VSM, requests to disconnect from the display engine (sub), and connects the mediaID to the display engine (main).
  • the web kit since the web kit is full-screen even if there is no coordinate information of the LSM, the web kit directly requests the display engine (main) to configure the display window.
  • the PIP sequence may function as described with reference to FIGS. 66 to 69 as necessary.
  • LSM LSM
  • VSM VSM
  • display engine are used mainly in PIP issues.
  • 76 is a diagram illustrating audio processing when there is a PIP issue according to an embodiment of the present invention.
  • Fig. 76A it is generally shown that there is one media and one ringtone when there is one.
  • the audio processor controls the media pipeline to output the speaker and the ringtone pipeline to the headset.
  • 76B relates to audio processing in a PIP issue.
  • the audio processor determines an output unit according to an audio type.
  • the audio types of two foreground applications may be the same. In other words, it may be difficult for the audio processor to determine the output unit using only the audio type.
  • the first media pipeline may be controlled to be output through the speaker at the audio processor, and the second media pipeline may be controlled to be output through the headset at the audio processor.
  • the audio processing unit basically determines the audio output unit based on the audio type.
  • the audio processing unit cannot determine the audio output unit based on the audio type.
  • the full-screen application may be output to the speaker and the PIP screen application may be controlled to be output through the headset.
  • the audio processor needs to be newly defined. In other words, if there is a PIP issue, it may not be by the audio processor.
  • the PIP screen application may not be output despite the media pipeline creation, and the PIP screen application may be output through the speaker to the main.
  • 77 to 83 are diagrams for explaining a PIP window transition for video according to an embodiment of the present invention.
  • the size or position of the PIP window shows an arbitrary size and any position for the understanding of the present invention and for convenience of the applicant's description, but is not limited thereto.
  • 77A shows that application A of two applications includes a video source, but application B does not include a video source.
  • the B application is located in the foreground and outputs full-screen, while the A application includes a video source but is mini-mized in the background.
  • FIG. 77B shows that the A application is connected to the sub-sync of the display engine in the FIG. 77A window so that the video source is output through the PIP window on the display where the PIP window is foreground, that is, the B application is outputting full-screen. In this case, however, the window transition does not occur according to the change from FIG. 77A to FIG. 77B.
  • FIG. 78A shows a case in which two applications, namely, A application and B application both include a video source.
  • the B application is connected to the display engine main in full-screen, but the A application is mini-mized in the background and disconnected from the display engine.
  • FIG. 78B shows that the application with two video sources is executed as application A in FIG. 78A comes to the foreground in the PIP.
  • application B since application B is already connected to the display engine's main, the application A receives mid-sized messages via the PIP and is connected to the display engine's subs, even though it is located in the foreground, and the application's video through the PIP window.
  • the source is output.
  • application A is connected to the display engine's sub according to the LSM's mid-sized message including the video source and output to the PIP window
  • application B is the video source. It's full screen. In this case, however, the B application is not connected to the display engine's main but is disconnected even though it is full-screen because it does not include a video source.
  • the B application when the B application has a video source or a new B application including a video source is executed in FIG. 79A, the B application receives a full-screen message and is connected to the main of the display engine through the VSM.
  • FIG. 80A shows that two applications including a video source, that is, A application, receive a mid-size message from the LSM, are connected to the display engine's sub via the VSM, and are output to the PIP window, and the B application is pulled from the LSM. Receives a screen message and connects to the display engine's main via VSM for full-screen output.
  • a application receives a mid-size message from the LSM, are connected to the display engine's sub via the VSM, and are output to the PIP window, and the B application is pulled from the LSM.
  • Receives a screen message and connects to the display engine's main via VSM for full-screen output.
  • FIG. 80B in contrast to FIG. 79B, when the video source of the B application is terminated or a new B application without the video source is placed in the foreground, the B application is connected to the main and disconnects of the display engine previously connected through the VSM. do. In this case, however, there is no window transition, and the A application is continuously output through the PIP window.
  • the A application includes a video source, is output to full-screen, and the B application does not include a video source and runs in the background according to the mini-mized message.
  • FIG. 81B illustrates that application B in FIG. 81A receives a full-screen message and is located in the foreground.
  • Application A outputs a video source through full-screen in FIG. 81A, but receives a mid-size message from the LSM. It is connected to the main display engine connected through the display engine, and then connected to the sub and output through the PIP window.
  • FIG. 81A to FIG. 81B result in a window transition effect.
  • FIG. 82A shows that, of the two applications including the video source, the A application is connected to the main of the display engine in the foreground and outputs full-screen, and the B application is located in the background according to the mini-mized message and is displayed in the display engine and the display. Connected state.
  • FIG. 82B illustrates that, in FIG. 82A, the B application running in the background receives a full-screen message from the LSM, is connected to the main of the display engine through the VSM, and is output to the full-screen. It is disconnected from the display engine's mains, but receives mid-sized messages from the LSM and is connected to the display engine's non-mains via VSM and output through the PIP window.
  • the window transition effect does not occur.
  • FIG. 83A shows that, while the A application includes a video source and is connected to the display engine mains in full-screen, as shown in FIG. 83B, the B application is placed in the foreground and output in full-screen mode. Does not contain a video source, so application A is output in a PIP window according to the mid-sized message, but the application A continues to display the main display engine because the application B does not have a video source despite the mid-size message. If it is connected without disconnecting, the transition effect occurs.
  • FIG. 84 is a flowchart illustrating the PIP window transition process according to an embodiment of the present invention.
  • the LSM transmits coordinate information on the size and position of the mid-size message and the PIP window to the application (S8402).
  • the application receiving the mid-sized message and the coordinate information punches a hole, connects with a sub of the display engine, and scales the video source to a coordinate with the sub of the connected display engine ( S8404).
  • the application may transmit the coordinate information to the sub of the display engine according to the message of the LSM, and scale the video source based on the coordinate information (S8416).
  • FIG. 85 is a diagram illustrating a move scenario during a PIP window transition process according to an embodiment of the present invention.
  • the priority of the VTG may be lower than, for example, sub video.
  • each video is only connected to the sub-sync of the display engine for the PIP screen.
  • 86 to 88 illustrate a PIP window control scenario according to embodiments of the present invention.
  • 86A shows a state in which the main screen and the PIP screen are simultaneously output on the screen of the digital device.
  • the digital device controls the PIP screen according to the control command.
  • the digital device when the cursor 3610 is located at the boundary area of the PIP screen 8620, the digital device recognizes that the user's intention is the control of the PIP screen 8620 and variously related thereto.
  • a control GUI including information and the like can be provided.
  • the movable areas A1, A2, and A3 of the PIP screen are provided in a dotted line form.
  • the digital device moves the previously output PIP screen to the corresponding area to continue providing the PIP screen.
  • the digital device may provide a control menu GUI 8650, as shown in FIG. 86C.
  • the control menu GUI 8650 outputs items such as size change (1-100), position change (Y / N), channel change (a1-z1), and the like.
  • the control menu GUI 8650 may provide the same menu items as when calling a menu in a predetermined area of the main screen.
  • an adjustment key for displaying the current size and adjusting the displayed size may be provided. In this case, when the user inputs a number corresponding to the size through the numeric control key, the user can immediately reflect the size change so that the user can intuitively recognize the size change of the PIP screen according to the size change.
  • the size of the PIP screen is changed to the state where the size of the PIP screen can be adjusted as shown in FIG. 86C or immediately as shown in FIG. 87A or 87B.
  • the yes (y) is selected in the position change item, it is possible to provide information about the changeable region as shown in FIG. 86B, or change the cursor as shown in FIG. It can be provided to change the position of the PIP screen in the form.
  • the channel change item is selected, the channel item is provided to be scrollable or a small size EPG screen is provided to another layer and may be immediately changed to the corresponding channel according to the selection.
  • the existing PIP screen may be maintained in a manner of providing one more PIP screen for the selected channel.
  • the added PIP screen may be selected in a form as shown in FIG. 86B and output to the selected area, or may be processed by drag and drop as shown in FIG. 86D.
  • a resizing or repositioning control GUI may be provided that provides an oblique first arrow pointing upwards between the arrows and an oblique second arrow pointing downwards between the right and downward arrows.
  • the adjustment GUI is available not only for size but also for position movement.
  • an icon for adjusting the screen size may be generated and provided as shown in FIG. 87D when the cursor moves to a corner portion. For example, if the cursor is located at the right edge of the PIP screen, icons expandable to the right edge are created and provided. In addition, when the cursor is located at the bottom edge of the PIP screen, icons that are expandable to the bottom edge are created and provided.
  • a menu is provided or the user expands only the bottom as shown in FIG. 88B in response to a double click or a wheel movement level of the input device. It may be provided as.
  • a corresponding channel may be continuously provided in the first region of the extended PIP screen, and detailed information about the channel may be provided in the second region, or one or more other channels may be provided together.
  • the cursor is located at the right edge of the PIP screen, and the user may provide only the right side in an expanded form as shown in FIG. 88C in response to the double click or the wheel movement level of the input device.
  • the wheel movement level refers to a form that gradually expands as the wheel is moved up and gradually decreases as the wheel is moved down.
  • an extension or a reduction may be directly applied to each wheel movement so as to be intuitively recognized corresponding to the wheel movement level of the digital device.
  • each area is the same as the content described with reference to FIG. 88B.
  • FIG. 88A when the cursor is located at the left edge or the top edge of the PIP screen, and the user moves the wheel of the input device by double clicking, as shown in FIG. 88D, as much as 1/2 of the entire screen area belongs to the PIP screen.
  • the PIP screen can be extended.
  • the PIP screen may be provided while the existing PIP screen is maintained while the PIP screen is extended or a new PIP screen is generated in an area not belonging to the PIP screen.
  • the area of Fig. 88D can also be processed in the manner described above.
  • the control of the cursor for the corner of FIG. 88A is as described above, but is not limited thereto.
  • the control process according to the cursor and the edge can be applied according to the same mechanism according to the position of the PIP screen.
  • 89 is a flowchart illustrating a PIP processing method according to an embodiment of the present invention.
  • the display engine and the connection are requested to the VSM based on the identifier received from the web kit of the first application (S8904).
  • the first application is connected to the main sink of the display engine (S8906).
  • operation S8908 a request is made to the VSM based on the identifier received from the web kit of the second application.
  • the second application is connected to a sub sink of the display engine (S8910), and the coordinate information received from the web kit of the second application is transmitted to the sub sink (S8912).
  • the video sources of the plurality of applications in the foreground are output (S8914).
  • the lifecycle message may be at least one of a full-screen message, a mid-size message and a minimized message, wherein the mid-size message is a message for controlling the application to be executed on the PIP screen.
  • the minimized message is for controlling the application to run in the background.
  • the lifecycle message and the changed coordinate information according to the move may be transmitted to the web kit of the second application.
  • the web kit of the second application does not request the VSM to disconnect with the sub sink according to the move message and the changed coordinate information, and transmits only the coordinate information changed to the sub sink to change the display window. Can be set according to.
  • the web kit of the second application may request the pre-connected sub-sink and disconnect to the VSM and request the main sink and the connection to the VSM. have.
  • the web kit of the second application may request setting of the main synchro display window.
  • the corresponding coordinate information may also be transmitted by the LSM.
  • a window transition may occur.
  • at least one of the first application and the second application may include a video source.
  • the digital device equipped with the webOS disclosed herein and a method of processing a service or an application in the digital device may not be limitedly applied to the configuration and method of the embodiments described above, but the embodiments may be modified in various ways. All or some of the embodiments may be configured to be selectively combined so as to.
  • the method of operating a digital device disclosed in the present specification may be embodied as processor readable codes on a processor readable recording medium included in the digital device.
  • the processor-readable recording medium includes all kinds of recording devices for storing data that can be read by the processor. Examples of processor-readable recording media include read only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like. It also includes the implementation in the form of a wave (carrier-wave).
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention relates to digital devices, and can be used throughout the industry using digital devices.

Abstract

본 명세서에서는 디지털 디바이스 및 상기 디지털 디바이스에서 서비스 처리 방법에 대한 다양한 실시예(들)이 개시된다. 여기서, 본 발명의 일 실시 예에 따른 디지털 디바이스는, 포어그라운드에 복수의 애플리케이션들이 있는 경우, 제1 애플리케이션과 제2 애플리케이션의 각 웹키트로 각각 제1 라이프사이클 메시지와 제2 라이프사이클 메시지와 상기 제2 애플리케이션의 디스플레이 내 사이즈와 포지션에 대한 좌표 정보를 전송하는 디스플레이 처리부; 상기 제1 애플리케이션을 위한 메인 싱크와 상기 제2 애플리케이션을 위한 서브 싱크를 포함한 디스플레이 엔진; 및 상기 제1 애플리케이션의 웹키트로부터 수신한 식별자와 커넥트 요청에 따라 상기 제1 애플리케이션을 상기 디스플레이 엔진의 메인 싱크와 연결하고, 상기 제2 애플리케이션의 웹키트로부터 수신한 식별자와 커넥트 요청에 따라 상기 제2 애플리케이션을 상기 디스플레이 엔진의 서브 싱크와 연결하는 비디오 처리부를 포함하여 포어그라운드에 있는 복수의 애플리케이션의 비디오 소스를 출력한다.

Description

디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법
본 발명은 디지털 디바이스에 관한 것으로, 더욱 상세하게는 웹OS(Web OS) 플랫폼이 탑재된 디지털 디바이스에서 비디오/애플리케이션 등 데이터 처리에 관한 것이다.
PC(Personal Computer), TV(Television)와 같은 고정 디바이스(standing device)에 이어 스마트 폰(smart phone), 태블릿 PC(Tablet PC) 등과 같은 모바일 디바이스(mobile device)의 발전이 눈부시다. 고정 디바이스와 모바일 디바이스는 원래 각자의 영역에서 서로 구분되어 발전해 왔으나, 최근 디지털 컨버전스(digital convergence)의 붐에 따라 그 영역이 모호해지고 있다.
또한, 이러한 디지털 디바이스의 발전 내지 환경 변화에 따라 사용자의 눈높이도 높아져 점차 다양하고 고사양의 서비스들(services)이나 애플리케이션들(applications) 지원에 대한 요청이 많다.
종래 디지털 TV 등에서 PIP(Picture in Picture)를 제공하는 것은 일반적이다. 다만, 이러한 PIP는 단지 방송 서비스를 위한 튜너(tuner)가 복수 개인 경우에만 가능한 문제점이 있으며, PIP를 위한 디스플레이 윈도우(display window)는 미리 OSD(on screen display) 내에 홀(hole)을 펀치(punch)하여 구성함으로써 상기 윈도우를 무브(move) 등 변경이 어려운 문제점이 있다. 또한, 상기 PIP 서비스는 디지털 디바이스의 방송 서비스에 한정되어 있어 애플리케이션 등에 적용하기 어려운 문제점이 있었다.
본 발명은 상기와 같은 상황 내지 문제점을 해소하고자 안출된 것으로, 본 발명의 일 과제는, 웹OS상에서 서비스, 애플리케이션, 비디오 등 데이터를 처리하는 디바이스 및 방법을 제공하는 것이다.
본 발명의 다른 과제는, 웹OS상에서 상기 서비스, 애플리케이션, 비디오 등 데이터를 처리함에 있어서 필요한 런-타임 뷰(run-time view), 리소스 매니지먼트(resource management), 폴리시 매니지먼트(policy management) 등을 제공하는 것이다.
본 발명의 또 다른 과제는, 웹OS가 탑재된 디지털 디바이스에서 PIP(Picture in Picture) 또는 앱온앱(app on app)을 처리하여 제공하는 것이다.
본 발명의 또 다른 과제는, 복수의 애플리케이션이 포어그라운드(foreground)에 있는 경우에도 이를 처리하여 웹OS상에서 멀티-태스킹(multi-tasking)이 가능하도록 하는 것이다.
본 발명의 또 다른 과제는, 상기와 같은 처리 프로세스를 통해 웹OS 이용자의 편의를 도모하고 제품 만족도를 개선하는 것이다.
본 발명의 또 다른 과제는, 상기와 같이 PIP 또는 앱온앱을 통한 멀티-태스킹 처리를 통해 사용자의 이용 만족도를 개선하는 것이다.
본 발명에서 이루고자 하는 기술적 과제는 상기 언급한 기술적 과제로 제한되지 않으며, 언급하지 않은 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 명세서에서는 디지털 디바이스 및 상기 디지털 디바이스에서 처리 방법에 대한 다양한 실시 예(들)을 개시한다.
본 발명의 일 실시 예에 따른 디지털 디바이스는, 포어그라운드에 복수의 애플리케이션들이 있는 경우, 제1 애플리케이션과 제2 애플리케이션의 각 웹키트로 각각 제1 라이프사이클 메시지와 제2 라이프사이클 메시지와 상기 제2 애플리케이션의 디스플레이 내 사이즈와 포지션에 대한 좌표 정보를 전송하는 디스플레이 처리부; 상기 제1 애플리케이션을 위한 메인 싱크와 상기 제2 애플리케이션을 위한 서브 싱크를 포함한 디스플레이 엔진; 및 상기 제1 애플리케이션의 웹키트로부터 수신한 식별자와 커넥트 요청에 따라 상기 제1 애플리케이션을 상기 디스플레이 엔진의 메인 싱크와 연결하고, 상기 제2 애플리케이션의 웹키트로부터 수신한 식별자와 커넥트 요청에 따라 상기 제2 애플리케이션을 상기 디스플레이 엔진의 서브 싱크와 연결하는 비디오 처리부를 포함하여 포어그라운드에 있는 복수의 애플리케이션의 비디오 소스를 출력한다.
본 발명의 일 실시 예에 따른 디지털 디바이스에서 애플리케이션 처리 방법은, 포어그라운드에 복수의 애플리케이션들이 있는 경우, 디스플레이 처리부에서 제1 애플리케이션과 제2 애플리케이션의 각 웹키트로 각각 제1 라이프사이클 메시지와 제2 라이프사이클 메시지와 상기 제2 애플리케이션의 디스플레이 내 사이즈와 포지션에 대한 좌표 정보를 전송하는 단계; 상기 제1 애플리케이션의 웹키트에서 수신된 식별자에 기초하여 디스플레이 엔진과 커넥트를 비디오 처리부에 요청하는 단계; 상기 제1 애플리케이션을 디스플레이 엔진의 메인 싱크와 연결하는 단계; 상기 제2 애플리케이션의 웹키트에서 수신된 식별자에 기초하여 커넥트를 상기 비디오 처리부에 요청을 하는 단계; 상기 제2 애플리케이션을 상기 디스플레이 엔진의 서브 싱크와 연결하는 단계; 상기 제2 애플리케이션의 웹키트에서 수신된 좌표 정보를 상기 서브 싱크로 전송하는 단계; 및 상기 포어그라운드에 있는 복수의 애플리케이션의 비디오 소스를 출력하는 단계를 포함하여 이루어진다.
본 발명에서 얻을 수 있는 기술적 해결 수단은 이상에서 언급한 해결 수단들로 제한되지 않으며, 언급하지 않은 또 다른 해결 수단들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명은 유리한 효과는 다음과 같다.
본 발명의 다양한 실시 예들 중 일 실시 예에 따르면, 웹OS상에서 서비스, 애플리케이션, 비디오 등 데이터를 처리하는 디바이스 및 방법을 제공할 수 있는 효과가 있다.
본 발명의 다양한 실시 예들 중 다른 실시 예에 따르면, 웹OS상에서 상기 서비스, 애플리케이션, 비디오 등 데이터를 처리함에 있어서 필요한 런-타임 뷰, 리소스 매니지먼트, 폴리시 매니지먼트 등을 제공할 수 있는 효과가 있다.
본 발명의 다양한 실시 예들 중 또 다른 실시 예에 따르면, 상기와 같은 처리 프로세스를 통해 웹OS 이용자의 편의를 도모하고 제품 만족도를 개선하는 효과가 있다.
본 발명의 다양한 실시 예들 중 또 다른 실시 예에 따르면, 웹OS가 탑재된 디지털 디바이스에서 PIP 또는 앱온앱을 처리하여 제공하는 효과가 있다.
본 발명의 다양한 실시 예들 중 또 다른 실시 예에 따르면, 복수의 애플리케이션이 포어그라운드에 있는 경우에도 이를 처리하여 웹OS상에서 멀티-태스킹이 가능한 효과가 있다.
본 발명의 다양한 실시 예들 중 또 다른 실시 예에 따르면, 상기와 같이 PIP 또는 앱온앱을 통한 멀티-태스킹 처리를 통해 사용자의 이용 만족도를 개선하는 효과가 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 발명의 일 실시 예에 따른 디지털 디바이스를 포함한 서비스 시스템을 개략적으로 설명하기 위해 도시한 도면;
도 2는 본 발명의 일 실시 예에 따른 디지털 디바이스를 설명하기 위해 도시한 구성 블록도;
도 3은 본 발명의 다른 실시 예에 따른 디지털 디바이스를 설명하기 위해 도시한 구성 블록도;
도 4는 본 발명의 또 다른 실시 예에 따른 디지털 디바이스를 설명하기 위해 도시한 구성 블록도;
도 5는 본 발명의 일 실시 예에 따라 도 2 내지 4의 제어부의 상세 구성을 설명하기 위해 도시한 구성 블록도;
도 6은 본 발명의 일 실시 예에 따른 도 2 내지 4의 디지털 디바이스와 연결된 인풋 수단을 도시한 도면;
도 7은 본 발명의 일 실시 예에 따른 웹OS 아키텍처를 설명하기 위해 도시한 도면;
도 8은 본 발명의 일 실시 예에 따른 웹OS 디바이스의 아키텍처를 설명하기 위해 도시한 도면;
도 9는 본 발명의 일 실시 예에 따른 웹OS 디바이스에서 그래픽 컴포지션 플로우를 설명하기 위해 도시한 도면;
도 10은 본 발명의 일 실시 예에 따른 미디어 서버를 설명하기 위해 도시한 도면;
도 11은 본 발명의 일 실시 예에 따른 미디어 서버의 구성 블록도를 설명하기 위해 도시한 도면;
도 12는 본 발명의 일 실시 예에 따른 미디어 서버와 TV 서비스의 관계를 설명하기 위해 도시한 도면;
도 13은 본 발명의 일 실시 예에 따른 애플리케이션과 미디어 서비스들 사이의 인터페이싱 방법을 설명하기 위해 도시된 도면;
도 14는 본 발명의 일 실시 예에 따른 플랫폼과 애플리케이션 사이의 베이스라인을 설명하기 위해 도시한 도면;
도 15 내지 19는 본 발명의 일 실시 예에 따라 애플리케이션과 미디어 서비스 사이의 런-타임 뷰를 설명하기 위해 도시한 도면;
도 20 내지 23은 본 발명의 일 실시 예에 따른 애플리케이션과 TV 서비스 사이의 런-타임 뷰를 설명하기 위해 도시한 도면;
도 24와 25는 본 발명의 다른 실시 예에 따른 애플리케이션과 TV 서비스 사이의 런-타임 뷰를 설명하기 위해 도시한 도면;
도 26은 본 발명의 일 실시 예에 따른 파이프라인 구조를 설명하기 위해 도시한 도면;
도 27은 본 발명의 일 실시 예에 따른 파이프라인 종류를 설명하기 위해 도시한 도면;
도 28은 본 발명의 일 실시 예에 따른 파이프라인 특성 정의를 설명하기 위해 도시한 도면;
도 29는 본 발명의 일 실시 예에 따른 파이프라인과 리소스 매니저의 관계를 설명하기 위해 도시한 도면;
도 30은 본 발명의 일 실시 예에 따른 TV 서비스로 시청과 동시에 녹화를 위한 구성도를 도시한 도면;
도 31은 본 발명의 다른 실시 예에 따른 TV 서비스로 시청과 동시에 녹화를 위한 구성도를 도시한 도면;
도 32는 본 발명의 일 실시 예에 따른 리소스 엘레멘트 정의를 설명하기 위해 도시한 도면;
도 33은 본 발명의 일 실시 예에 따른 파이프라인 라이프사이클을 설명하기 위해 도시한 도면;
도 34는 본 발명의 일 실시 예에 따른 채널 체인지 경우의 내부 구성들 간의 관계를 설명하기 위해 도시한 도면;
도 35는 본 발명의 일 실시 예에 따른 시청 파이프라인 콜 시퀀스를 설명하기 위해 도시한 시퀀스 다이어그램;
도 36은 본 발명의 일 실시 예에 따른 미디어 파이프라인 콜 시퀀스를 설명하기 위해 도시한 시퀀스 다이어그램;
도 37 내지 41은 본 발명의 일 실시 예에 따른 리소스 컨피규레이션 파일을 설명하기 위해 도시한 도면;
도 42 내지 49는 본 발명의 일 실시 예에 따른 동작(들)을 위해 구성한 리소스 어레인지먼트를 설명하기 위해 도시한 도면;
도 50은 본 발명의 일 실시 예에 따른 서비스 재구조화를 설명하기 위해 도시한 도면;
도 51은 본 발명의 다른 실시 예에 따른 서비스 재구조화를 설명하기 위해 도시한 도면;
도 52는 본 발명의 일 실시 예에 따른 폴리시 매니지먼트를 설명하기 위해 도시한 도면;
도 53은 본 발명의 다른 실시 예에 따른 폴리시 매니지먼트를 설명하기 위해 도시한 도면;
도 54 내지 57은 본 발명의 일 실시 예에 따른 TV 서비스와 미디어 파이프라인 사이의 폴리시 매니지먼트를 설명하기 위해 도시한 도면;
도 58은 본 발명의 일 실시 예에 따른 TV 파이프라인들 사이의 폴리시 시나리오를 설명하기 위해 도시한 도면;
도 59 내지 60은 본 발명의 일 실시 예에 따른 TV 파이프라인과 미디어 파이프라인 사이의 폴리시 시나리오를 설명하기 위해 도시한 도면;
도 61 내지 62는 본 발명의 다른 실시 예에 따른 TV 파이프라인과 미디어 파이프라인 사이의 폴리시 시나리오를 설명하기 위해 도시한 도면;
도 63은 본 발명의 일 실시 예에 따른 VSM을 설명하기 위해 도시된 도면;
도 64는 본 발명의 일 실시 예에 따른 비디오 처리와 관련하여, 소스와 싱크에 대한 개념을 설명하기 위해 도시된 도면;
도 65는 본 발명의 일 실시 예에 따른 인풋 스택과 렌더링 스택에서 비디오 인풋을 컨트롤하는 것을 설명하기 위해 도시한 도면;
도 66 내지 69는 본 발명의 일 실시 예에 따른 웹 애플리케이션에서 일어나는 다양한 시나리오들에 대한 시퀀스 다이어그램을 설명하기 위해 도시한 도면;
도 70은 본 발명의 일 실시 예에 따른 PIP 이슈를 설명하기 위해 도시한 도면;
도 71은, 포어그라운드에 두 개의 애플리케이션이 있는 경우에 PIP 시나리오를 설명하기 위해 도시한 도면;
도 72 내지 75는 본 발명의 일 실시 예에 따라 웹 애플리케이션 상에서 PIP 시퀀스를 설명하기 위해 도시한 도면;
도 76은 본 발명의 일 실시 예에 따라 PIP 이슈가 있는 경우에 오디오 처리를 설명하기 위해 도시한 도면;
도 77 내지 84는 본 발명의 일 실시 예에 따른 비디오를 위한 PIP 윈도우 트랜지션을 설명하기 위해 도시한 도면;
도 85는 본 발명의 일 실시 예에 따른 상기 PIP 윈도우 트랜지션 과정을 설명하기 위해 도시한 순서도;
도 86 내지 88은 본 발명의 실시 예들에 따른 PIP 윈도우 제어 시나리오를 설명하기 위해 도시한 도면; 및
도 89는 본 발명의 일 실시 예에 따른 PIP 처리 방법을 설명하기 위해 도시한 순서도이다.
이하에서는 도면을 참조하여 본 발명에 따른 디지털 디바이스 및 상기 디지털 디바이스에서 애플리케이션 처리 방법의 다양한 실시 예(들)을 상세하게 설명한다.
본 명세서에서 사용되는 구성요소에 대한 접미사 "모듈", "부" 등은 단지 명세서 작성의 용이함을 고려하여 부여되는 것으로서, 필요에 따라 양자는 혼용될 수도 있다. 또한, "제1-", "제2-" 등과 같이 서수로 기술한 경우에도 그것이 순서를 의미하기보다는 해당 용어의 설명 편의를 위한 것일 뿐, 그러한 용어나 서수에 한정되는 것은 아니다.
또한, 본 명세서에서 사용되는 용어도, 본 발명의 기술 사상에 따른 기능을 고려하여 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 다만, 특정한 경우는 출원인이 임의로 선정한 용어도 있으나, 이에 대해서는 관련 설명 부분에서 그 의미를 기술할 것이다. 따라서, 해당 용어를 단지 그 명칭이 아니라 그가 가진 실질적인 의미와 본 명세서 전반에 걸쳐 기술된 내용을 토대로 해석되어야 함을 밝혀 둔다.
한편, 본 명세서 또는/및 도면에 기술된 내용은, 본 발명에 따른 바람직한 일 실시 예로서 그에 한정되지 않으며, 그 권리범위는 특허청구범위를 통해 결정되어야 한다.
이하 본 명세서에서 기술되는 “디지털 디바이스(digital device)”라 함은 예를 들어, 컨텐트(content), 서비스(service), 애플리케이션(application) 등 데이터를 송신, 수신, 처리 및 출력 중 적어도 하나 이상을 수행하는 모든 디바이스를 포함한다. 상기 디지털 디바이스는, 유/무선 네트워크(wire/wireless network)를 통하여 다른 디지털 디바이스, 외부 서버(external server) 등과 페어링 또는 연결(pairing or connecting)(이하 '페어링') 가능하며, 그를 통해 소정 데이터를 송/수신할 수 있다. 이때, 필요에 따라, 상기 데이터는 그 송/수신 전에 적절히 변환(converting)될 수 있다. 상기 디지털 디바이스에는 예를 들어, 네트워크 TV(Network TV), HBBTV(Hybrid Broadcast Broadband TV), 스마트 TV(Smart TV), IPTV(Internet Protocol TV), PC(Personal Computer) 등과 같은 고정형 디바이스(standing device)와, PDA(Personal Digital Assistant), 스마트 폰(Smart Phone), 태블릿 PC(Tablet PC), 노트북(Notebook) 등과 같은 모바일 디바이스(mobile device or handheld device)가 모두 포함될 수 있다. 본 명세서에서는 본 발명의 이해를 돕고 출원인의 설명의 편의상 후술하는 도 2에서는 디지털 TV(Digital TV)를 그리고, 도 3에서는 모바일 디바이스를 디지털 디바이스의 일 실시 예로 도시하고 설명한다. 또한, 본 명세서에서 기술되는 디지털 디바이스는, 패널(panel)만을 가진 구성일 수도 있고, 셋톱박스(STB: Set-Top Box) 등과 같은 구성, 디바이스, 시스템 등과 하나의 세트(SET) 구성일 수도 있다.
한편, 본 명세서에서 기술되는 “유/무선 네트워크”라 함은, 디지털 디바이스들 또는 디지털 디바이스와 외부 서버 사이에서 페어링 또는/및 데이터 송수신을 위해 다양한 통신 규격 내지 프로토콜을 지원하는 통신 네트워크를 통칭한다. 이러한 유/무선 네트워크는, 규격에 의해 현재 또는 향후 지원될 통신 네트워크를 모두 포함하며, 그를 위한 하나 또는 그 이상의 통신 프로토콜들을 모두 지원 가능하다. 이러한 유/무선 네트워크에는 예컨대, USB(Universal Serial Bus), CVBS(Composite Video Banking Sync), 컴포넌트(Component), S-비디오(아날로그), DVI(Digital Visual Interface), HDMI(High Definition Multimedia Interface), RGB, D-SUB와 같은 유선 연결을 위한 네트워크와 그를 위한 통신 규격 내지 프로토콜과, 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(IrDA: infrared Data Association), UWB(Ultra Wideband), 지그비(ZigBee), DLNA(Digital Living Network Alliance), WLAN(Wireless LAN)(Wi-Fi), Wibro(Wireless broadband), Wimax(World Interoperability for Microwave Access), HSDPA(High Speed Downlink Packet Access), LTE/LTE-A(Long Term Evolution/LTE-Advanced), Wi-Fi 다이렉트(direct)와 같은 무선 연결을 위한 네트워크와 그를 위한 통신 규격 내지 프로토콜에 의하여 형성될 수 있다.
그 밖에, 본 명세서에서 단지 디지털 디바이스로 명명하는 경우, 그 의미는 문맥에 따라 고정형 디바이스 또는 모바일 디바이스를 의미할 수도 있고 특별히 언급하지 않는다면 양자를 모두 포함하는 의미로 사용될 수 있다.
한편, 디지털 디바이스는 예컨대, 방송 수신 기능, 컴퓨터 기능 내지 지원, 적어도 하나의 외부 인풋(external input) 등을 지원하는 지능형 디바이스로서, 상술한 유/무선 네트워크를 통해 이메일(e-mail), 웹 브라우징(web browsing), 뱅킹(banking), 게임(game), 애플리케이션(application) 등을 지원할 수 있다. 더불어, 상기 디지털 디바이스는, 수기 방식의 인풋 디바이스, 터치-스크린(touch-screen), 공간 리모콘 등 적어도 하나의 인풋 또는 제어 수단(이하 ‘인풋 수단’)을 지원하기 위한 인터페이스(interface)를 구비할 수 있다.
그 밖에, 디지털 디바이스는, 표준화된 범용 OS(Operating System)를 이용할 수 있다. 관련하여, 본 명세에서 기술되는 디지털 디바이스는, 웹OS(WebOS) 플랫폼을 이용할 수 있다. 따라서, 디지털 디바이스는 범용의 OS 커널(OS kernel) 또는 리눅스 커널(Linux kernel) 상에 다양한 서비스나 애플리케이션을 추가(adding), 삭제(deleting), 수정(amending), 업데이트(updating) 등을 처리가 가능하며, 그를 통해 더욱 사용자 친화적인(user-friendly) 환경을 구성하여 제공할 수 있다.
한편, 상술한 디지털 디바이스는 외부 인풋을 수신하여 처리할 수 있는데 이때, 상기 외부 인풋은, 외부 인풋 디바이스 즉, 상술한 디지털 디바이스와 유/무선 네트워크를 통해 연결되어 데이터를 송/수신하여 처리 가능한 모든 인풋 수단 내지 디지털 디바이스를 포함한다. 예를 들어, 상기 외부 인풋으로 HDMI(High-Definition Multimedia Interface), 플레이스테이션(playstation)이나 엑스-박스(X-Box) 등과 같은 게임 디바이스(game device), 스마트 폰, 태블릿 PC, 포켓 포토(pocket photo) 등과 같은 프린터기(printing device), 스마트 TV, 블루-레이(Blu-ray device) 디바이스 등과 같은 디지털 디바이스들을 모두 포함한다.
그 밖에, 본 명세서에서 기술되는 “서버”라 함은, 상술한 디지털 디바이스 즉, 클라이언트(client)로 데이터를 공급 또는 그로부터 데이터를 수신하는 디지털 디바이스 혹은 시스템을 의미하며, 프로세서(processor)로 불리기도 한다. 상기 서버로 예컨대, 웹 페이지(web page), 웹 컨텐트 또는 웹 서비스(web content or web service)를 제공하는 포털 서버(portal server), 광고 데이터(advertising data)를 제공하는 광고 서버(advertising server), 컨텐트를 제공하는 컨텐트 서버(content server), SNS(Social Network Service)를 제공하는 SNS 서버, 제조업체(manufacturer)에서 제공하는 서비스 서버(service server), VoD(Video on Demand)나 스트리밍(streaminng) 서비스 제공을 위한 MVPD(Multichannel Video Programming Distributor), 유료 서비스(pay service) 등을 제공하는 서비스 서버 등이 포함될 수 있다.
또한, 이하 본 명세서에서 설명의 편의를 위하여 애플리케이션으로만 기술한 경우에도 그 문맥 등을 기초하여 그 의미는 애플리케이션뿐만 아니라 서비스까지 포함하는 의미일 수 있다.
이하 첨부된 도면을 참조하면 본 발명을 더욱 상세하게 설명하면, 다음과 같다.
도 1은 본 발명의 일 실시 예에 따른 디지털 디바이스를 포함한 서비스 시스템을 개략적으로 설명하기 위해 도시한 도면이다.
도 1을 참조하면, 서비스 시스템은, 컨텐트 프로바이더(content provider)(10), 서비스 프로바이더(service provider)(20), 네트워크 프로바이더(network provider)(30) 및 HNED(Home Network End User)(Customer)(40)를 포함한다. 여기서, HNED(40)는 예를 들어, 클라이언트(100) 즉, 본 발명에 따른 디지털 디바이스를 포함한다.
컨텐트 프로바이더(10)는, 각종 컨텐트를 제작하여 제공한다. 도 1에 도시된 바와 같이, 이러한 컨텐트 프로바이더(10)로 지상파 방송 송출자, 케이블 방송 사업자(cable SO(System Operator)) 또는 MSO(Multiple SO), 위성 방송 송출자, 다양한 인터넷 방송 송출자, 개인 컨텐트 프로바이더들 등을 예시할 수 있다. 한편, 컨텐트 프로바이더(10)는, 방송 컨텐트 외에도 다양한 서비스나 애플리케이션 등을 제작하여 제공할 수 있다.
서비스 프로바이더(20)는, 컨텐트 프로바이더(10)에 의해 제작된 컨텐트를 서비스 패키지화(service packetizing)하여 HNED(40)로 제공한다. 예컨대, 서비스 프로바이더(20)는, 제1 지상파 방송, 제2 지상파 방송, 케이블 MSO, 위성 방송, 다양한 인터넷 방송, 애플리케이션 등에 의해 제작된 컨텐트들 중 적어도 하나 이상을 서비스를 위해 패키지화하고, 이를 HNED(40)에게 제공한다.
서비스 프로바이더(20)는, 유니-캐스트(uni-cast) 또는 멀티-캐스트(multi-cast) 방식으로 클라이언트(100)에 서비스를 제공한다. 한편, 서비스 프로바이더(20)는 데이터를 미리 등록된 다수의 클라이언트(100)로 한꺼번에 전송할 수 있는데, 이를 위해 IGMP(Internet Group Management Protocol) 프로토콜 등을 이용할 수 있다.
상술한 컨텐트 프로바이더(10)와 서비스 프로바이더(20)는, 동일한 개체(entity)일 수 있다. 예를 들어, 컨텐트 프로바이더(10)가 제작한 컨텐트를 서비스 패키지화하여 HNED(40)로 제공함으로써 서비스 프로바이더(20)의 기능도 함께 수행하거나 그 반대일 수도 있다.
네트워크 프로바이더(30)는, 컨텐트 프로바이더(10) 또는/및 서비스 프로바이더(20)와 클라이언트(100) 사이의 데이터 교환을 위한 네트워크 망을 제공한다.
클라이언트(100)는, HNED(40)에 속한 소비자로서, 네트워크 프로바이더(30)를 통해 예컨대, 홈 네트워크(home network)를 구축하여 데이터를 수신하며, VoD, 스트리밍 등 다양한 서비스나 애플리케이션 등에 관한 데이터를 송/수신할 수도 있다.
한편, 서비스 시스템 내 컨텐트 프로바이더(10) 또는/및 서비스 프로바이더(20)는 전송되는 컨텐트의 보호를 위해 제한 수신(conditional access) 또는 컨텐트 보호(content protection) 수단을 이용할 수 있다. 따라서, 클라이언트(100)는 상기 제한 수신이나 컨텐트 보호에 대응하여 케이블카드(CableCARD)(또는 POD: Point of Deployment), DCAS(Downloadable CAS) 등과 같은 처리 수단을 이용할 수 있다.
그 밖에, 클라이언트(100)도 네트워크를 통해, 양방향 서비스를 이용할 수 있다. 따라서, 클라이언트(100)가 오히려 컨텐트 프로바이더의 역할 내지 기능을 수행할 수도 있으며, 서비스 프로바이더(20)는 이를 수신하여 다시 다른 클라이언트 등으로 전송할 수도 있다.
도 1에서 컨텐트 프로바이더(10) 또는/및 서비스 프로바이더(20)는 본 명세서에서 후술하는 서비스를 제공하는 서버일 수 있다. 이 경우, 상기 서버는 필요에 따라 네트워크 프로바이더(30)도 소유 내지 포함하는 의미일 수 있다. 이하 특별히 언급하지 않더라도 서비스 또는 서비스 데이터는, 전술한 외부로부터 수신되는 서비스 내지 애플리케이션뿐만 아니라 내부 서비스 내지 애플리케이션을 포함하며, 이러한 서비스 내지 애플리케이션은 웹OS(Web OS) 기반의 클라이언트(100)를 위한 서비스 내지 애플리케이션 데이터를 의미할 수 있다.
도 2는 본 발명의 일 실시 예에 따른 디지털 디바이스를 설명하기 위해 도시한 구성 블록도이다.
이하 본 명세서에서 기술되는 디지털 디바이스는 전술한 도 1의 클라이언트(100)에 해당한다.
디지털 디바이스(200)는, 네트워크 인터페이스부(network interface)(201), TCP/IP 매니저(TCP/IP manager)(202), 서비스 전달 매니저(service delivery manager)(203), SI 디코더(204), 역다중화부(demux or demultiplexer)(205), 오디오 디코더(audio decoder)(206), 비디오 디코더(video decoder)(207), 디스플레이부(display A/V and OSD module)(208), 서비스 제어 매니저(service control manager)(209), 서비스 디스커버리 매니저(service discovery manager)(210), SI&메타데이터 데이터베이스(SI&metadata DB)(211), 메타데이터 매니저(metadata manager)(212), 서비스 매니저(213), UI 매니저(214) 등을 포함하여 구성된다.
네트워크 인터페이스부(201)는, 액세스하는 네트워크 망을 통하여 IP 패킷(들)(Internet Protocol(IP) packet(s)) 또는 IP 데이터그램(들)(IP datagram(s))(이하 IP 패킷(들)이라 한다)을 송/수신한다. 일 예로, 네트워크 인터페이스부(201)는 네트워크 망을 통해 도 1의 서비스 프로바이더(20)로부터 서비스, 애플리케이션, 컨텐트 등을 수신할 수 있다.
TCP/IP 매니저(202)는, 디지털 디바이스(200)로 수신되는 IP 패킷들과 디지털 디바이스(200)가 전송하는 IP 패킷들에 대하여 즉, 소스(source)와 목적지(destination) 사이의 패킷 전달(packet delivery)에 관여한다. 상기 TCP/IP 매니저(202)는 수신된 패킷(들)을 적절한 프로토콜에 대응하도록 분류하고, 서비스 전달 매니저(205), 서비스 디스커버리 매니저(210), 서비스 제어 매니저(209), 메타데이터 매니저(212) 등으로 상기 분류된 패킷(들)을 출력한다.
서비스 전달 매니저(203)는, 수신되는 서비스 데이터의 제어를 담당한다. 예를 들어, 서비스 전달 매니저(203)는 실시간 스트리밍(real-time streaming) 데이터를 제어하는 경우에는 RTP/RTCP를 사용할 수 있다. 상기 실시간 스트리밍 데이터를 RTP를 사용하여 전송하는 경우, 서비스 전달 매니저(203)는 상기 수신된 데이터 패킷을 RTP에 따라 파싱(parsing)하여 역다중화부(205)로 전송하거나 서비스 매니저(213)의 제어에 따라 SI&메타데이터 데이터베이스(211)에 저장한다. 그리고, 서비스 전달 매니저(203)는 RTCP를 이용하여 상기 네트워크 수신 정보를 서비스를 제공하는 서버 측에 피드백(feedback)한다.
역다중화부(205)는, 수신된 패킷을 오디오, 비디오, SI(System Information) 데이터 등으로 역다중화하여 각각 오디오/비디오 디코더(206/207), SI 디코더(204)에 전송한다.
SI 디코더(204)는, 역다중화된 SI 데이터 즉, PSI(Program Specific Information), PSIP(Program and System Information Protocol), DVB-SI(Digital Video Broadcasting-Service Information), DTMB/CMMB(Digital Television Terrestrial Multimedia Broadcasting/Coding Mobile Multimedia Broadcasting) 등의 서비스 정보를 디코딩한다. 또한, SI 디코더(204)는, 디코딩된 서비스 정보들을 SI&메타데이터 데이터베이스(211)에 저장할 수 있다. 저장된 서비스 정보는 예를 들어, 사용자의 요청 등에 의해 해당 구성에 의해 독출되어 이용될 수 있다.
오디오/비디오 디코더(206/207)는, 역다중화된 각 오디오 데이터와 비디오 데이터를 디코딩한다. 이렇게 디코딩된 오디오 데이터 및 비디오 데이터는 디스플레이부(208)를 통하여 사용자에게 제공된다.
애플리케이션 매니저는 예를 들어, UI 매니저(214)와 서비스 매니저(213)를 포함하며 디지털 디바이스(200)의 제어부 기능을 수행할 수 있다. 다시 말해, 애플리케이션 매니저는, 디지털 디바이스(200)의 전반적인 상태를 관리하고 사용자 인터페이스(UI: User Interface)를 제공하며, 다른 매니저를 관리할 수 있다.
UI 매니저(214)는, 사용자를 위한 GUI(Graphic User Interface)/UI를 OSD(On Screen Display) 등을 이용하여 제공하며, 사용자로부터 키 인풋을 받아 상기 인풋에 따른 디바이스 동작을 수행한다. 예를 들어, UI 매니저(214)는 사용자로부터 채널 선택에 관한 키 인풋을 받으면 상기 키 인풋 신호를 서비스 매니저(213)에 전송한다.
서비스 매니저(213)는, 서비스 전달 매니저(203), 서비스 디스커버리 매니저(210), 서비스 제어 매니저(209), 메타데이터 매니저(212) 등 서비스와 연관된 매니저를 제어한다.
또한, 서비스 매니저(213)는, 채널 맵(channel map)을 생성하고 UI 매니저(214)로부터 수신한 키 인풋에 따라 상기 생성된 채널 맵을 이용하여 채널을 선택 등을 제어한다. 상기 서비스 매니저(213)는 SI 디코더(204)로부터 서비스 정보를 전송받아 선택된 채널의 오디오/비디오 PID(Packet Identifier)를 역다중화부(205)에 설정한다. 이렇게 설정되는 PID는 상술한 역다중화 과정에 이용될 수 있다. 따라서, 역다중화부(205)는 상기 PID를 이용하여 오디오 데이터, 비디오 데이터 및 SI 데이터를 필터링(PID or section filtering) 한다.
서비스 디스커버리 매니저(210)는, 서비스를 제공하는 서비스 프로바이더를 선택하는데 필요한 정보를 제공한다. 상기 서비스 매니저(213)로부터 채널 선택에 관한 신호를 수신하면, 서비스 디스커버리 매니저(210)는 상기 정보를 이용하여 서비스를 찾는다.
서비스 제어 매니저(209)는, 서비스의 선택과 제어를 담당한다. 예를 들어, 서비스 제어 매니저(209)는 사용자가 기존의 방송 방식과 같은 생방송(live broadcasting) 서비스를 선택하는 경우 IGMP 또는 RTSP 등을 사용하고, VOD(Video on Demand)와 같은 서비스를 선택하는 경우에는 RTSP를 사용하여 서비스의 선택, 제어를 수행한다. 상기 RTSP 프로토콜은 실시간 스트리밍에 대해 트릭 모드(trick mode)를 제공할 수 있다. 또한, 서비스 제어 매니저(209)는 IMS(IP Multimedia Subsystem), SIP(Session Initiation Protocol)를 이용하여 IMS 게이트웨이(250)를 통하는 세션을 초기화하고 관리할 수 있다. 상기 프로토콜들은 일 실시 예이며, 구현 예에 따라 다른 프로토콜을 사용할 수도 있다.
메타데이터 매니저(212)는, 서비스와 연관된 메타데이터를 관리하고 상기 메타데이터를 SI&메타데이터 데이터베이스(211)에 저장한다.
SI&메타데이터 데이터베이스(211)는, SI 디코더(204)가 디코딩한 서비스 정보, 메타데이터 매니저(212)가 관리하는 메타데이터 및 서비스 디스커버리 매니저(210)가 제공하는 서비스 프로바이더를 선택하는데 필요한 정보를 저장한다. 또한, SI&메타데이터 데이터베이스(211)는 시스템에 대한 세트-업 데이터 등을 저장할 수 있다.
SI&메타데이터 데이터베이스(211)는, 비휘발성 메모리(Non-Volatile RAM: NVRAM) 또는 플래시 메모리(flash memory) 등을 사용하여 구현될 수도 있다.
한편, IMS 게이트웨이(250)는, IMS 기반의 IPTV 서비스에 접근하기 위해 필요한 기능들을 모아 놓은 게이트웨이이다.
도 3은 본 발명의 다른 실시 예에 따른 디지털 디바이스를 설명하기 위해 도시한 구성 블록도이다.
전술한 도 2가 고정 디바이스를 디지털 디바이스의 일 실시 예로 하여 설명하였다면, 도 3은 모바일 디바이스를 디지털 디바이스의 다른 실시 예로 한다.
도 3을 참조하면, 모바일 디바이스(300)는, 무선 통신부(310), A/V(Audio/Video) 입력부(320), 사용자 입력부(330), 센싱부(340), 출력부(350), 메모리(360), 인터페이스부(370), 제어부(380) 및 전원 공급부(390) 등을 포함할 수 있다.
이하 각 구성요소에 대해 상세히 설명하면, 다음과 같다.
무선 통신부(310)는, 모바일 디바이스(300)와 무선 통신 시스템 사이 또는 모바일 디바이스와, 모바일 디바이스가 위치한 네트워크 사이의 무선 통신을 가능하게 하는 하나 또는 그 이상의 모듈을 포함할 수 있다. 예를 들어, 무선 통신부(310)는 방송 수신 모듈(311), 이동통신 모듈(312), 무선 인터넷 모듈(313), 근거리 통신 모듈(314) 및 위치정보 모듈(315) 등을 포함할 수 있다.
방송 수신 모듈(311)은, 방송 채널을 통하여 외부의 방송 관리 서버로부터 방송 신호 및/또는 방송 관련된 정보를 수신한다. 여기서, 방송 채널은 위성 채널, 지상파 채널을 포함할 수 있다. 상기 방송 관리 서버는, 방송 신호 및/또는 방송 관련 정보를 생성하여 송신하는 서버 또는 기 생성된 방송 신호 및/또는 방송 관련 정보를 제공받아 단말기에 송신하는 서버를 의미할 수 있다. 상기 방송 신호는, TV 방송 신호, 라디오 방송 신호, 데이터 방송 신호를 포함할 뿐만 아니라, TV 방송 신호 또는 라디오 방송 신호에 데이터 방송 신호가 결합한 형태의 방송 신호도 포함할 수 있다.
방송 관련 정보는, 방송 채널, 방송 프로그램 또는 방송 서비스 프로바이더에 관련한 정보를 의미할 수 있다. 상기 방송 관련 정보는, 이동통신망을 통하여도 제공될 수 있다. 이러한 경우에는 상기 이동통신 모듈(312)에 의해 수신될 수 있다.
방송 관련 정보는 다양한 형태 예를 들어, EPG(Electronic Program Guide) 또는 ESG(Electronic Service Guide) 등의 형태로 존재할 수 있다.
방송수신 모듈(311)은 예를 들어, ATSC, DVB-T(Digital Video Broadcasting-Terrestrial), DVB-S(Satellite), MediaFLO(Media Forward Link Only), DVB-H(Handheld), ISDB-T(Integrated Services Digital Broadcast-Terrestrial), 중국향 DTMB/CMMB 등 디지털 방송 시스템을 이용하여 디지털 방송 신호를 수신할 수 있다. 물론, 방송수신 모듈(311)은, 상술한 디지털 방송 시스템뿐만 아니라 다른 방송 시스템에 적합하도록 구성될 수도 있다.
방송수신 모듈(311)을 통해 수신된 방송 신호 및/또는 방송 관련 정보는, 메모리(360)에 저장될 수 있다.
이동통신 모듈(312)은, 이동 통신망 상에서 기지국, 외부 단말, 서버 중 적어도 하나와 무선 신호를 송수신한다. 무선 신호는, 음성 신호, 화상 통화 신호 또는 문자/멀티미디어 메시지 송수신에 따른 다양한 형태의 데이터를 포함할 수 있다.
무선인터넷 모듈(313)은, 무선 인터넷 접속을 위한 모듈을 포함하여, 모바일 디바이스(300)에 내장되거나 외장될 수 있다. 무선 인터넷 기술로는 WLAN(Wireless LAN)(Wi-Fi), Wibro(Wireless broadband), Wimax(World Interoperability for Microwave Access), HSDPA(High Speed Downlink Packet Access) 등이 이용될 수 있다.
근거리통신 모듈(314)은, 근거리 통신을 위한 모듈을 말한다. 근거리 통신(short range communication) 기술로 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(IrDA, infrared Data Association), UWB(Ultra Wideband), ZigBee, RS-232, RS-485 등이 이용될 수 있다.
위치정보 모듈(315)은, 모바일 디바이스(300)의 위치 정보 획득을 위한 모듈로서, GPS(Global Position System) 모듈을 예로 할 수 있다.
A/V 입력부(320)는, 오디오 또는/및 비디오 신호 인풋을 위한 것으로, 이에는 카메라(321)와 마이크(322) 등이 포함될 수 있다. 카메라(321)는, 화상통화 모드 또는 촬영 모드에서 이미지 센서에 의해 얻어지는 정지영상 또는 동영상 등의 화상 프레임을 처리한다. 처리된 화상 프레임은 디스플레이부(351)에 표시될 수 있다.
카메라(321)에서 처리된 화상 프레임은, 메모리(360)에 저장되거나 무선 통신부(310)를 통하여 외부로 전송될 수 있다. 카메라(321)는, 사용 환경에 따라 2개 이상이 구비될 수도 있다.
마이크(322)는, 통화 모드 또는 녹음 모드, 음성인식 모드 등에서 마이크로폰(Microphone)에 의해 외부의 음향 신호를 입력받아 전기적인 음성 데이터로 처리한다. 처리된 음성 데이터는, 통화 모드인 경우 이동통신 모듈(312)을 통하여 이동통신 기지국으로 송신 가능한 형태로 변환되어 출력될 수 있다. 마이크(322)에는 외부의 음향 신호를 입력받는 과정에서 발생하는 잡음(noise)을 제거하기 위한 다양한 잡음 제거 알고리즘이 구현될 수 있다.
사용자 입력부(330)는, 사용자가 단말기의 동작 제어를 위한 인풋 데이터를 발생시킨다. 사용자 입력부(330)는, 키 패드(key pad), 돔 스위치(dome switch), 터치 패드(정압/정전), 조그 휠(jog wheel), 조그 스위치(jog switch) 등으로 구성될 수 있다.
센싱부(340)는, 모바일 디바이스(300)의 개폐 상태, 모바일 디바이스(300)의 위치, 사용자 접촉 유무, 모바일 디바이스의 방위, 모바일 디바이스의 가속/감속 등과 같이 모바일 디바이스(300)의 현재 상태를 감지하여 모바일 디바이스(300)의 동작 제어를 위한 센싱 신호를 발생시킨다. 예를 들어, 모바일 디바이스(300)가 이동되거나 기울어진 경우 모바일 디바이스의 위치 내지 기울기 등을 센싱할 수 있다. 또한, 전원 공급부(390)의 전원 공급 여부, 인터페이스부(370)의 외부 디바이스 결합 여부 등도 센싱할 수도 있다. 한편, 센싱부(240)는, NFC(Near Field Communication) 등을 포함한 근접 센서(341)를 포함할 수 있다.
출력부(350)는, 시각, 청각 또는 촉각 등과 관련된 출력을 발생시키기 위한 것으로, 디스플레이부(351), 음향 출력 모듈(352), 알람부(353), 및 햅틱 모듈(354) 등이 포함될 수 있다.
디스플레이부(351)는, 모바일 디바이스(300)에서 처리되는 정보를 표시(출력)한다. 예를 들어, 모바일 디바이스가 통화 모드인 경우 통화와 관련된 UI 또는 GUI를 표시한다. 모바일 디바이스(300)가 화상 통화 모드 또는 촬영 모드인 경우에는, 촬영 또는/및 수신된 영상 또는 UI, GUI를 표시한다.
디스플레이부(351)는, 액정 디스플레이(liquid crystal display, LCD), 박막 트랜지스터 액정 디스플레이(thin film transistor-liquid crystal display, TFT LCD), 유기 발광 다이오드(organic light-emitting diode, OLED), 플렉시블 디스플레이(flexible display), 3차원 디스플레이 중에서 적어도 하나를 포함할 수 있다.
이들 중 일부 디스플레이는 그를 통해 외부를 볼 수 있도록 투명형 또는 광투과형으로 구성될 수 있다. 이는 투명 디스플레이라 호칭될 수 있는데, 상기 투명 디스플레이의 대표적인 예로는 TOLED(Transparant OLED) 등이 있다. 디스플레이부(351)의 후방 구조 또한 광 투과형 구조로 구성될 수 있다. 이러한 구조에 의하여, 사용자는 단말기 바디의 디스플레이부(351)가 차지하는 영역을 통해 단말기 바디(body)의 후방에 위치한 사물을 볼 수 있다.
모바일 디바이스(300)의 구현 형태에 따라 디스플레이부(351)가 2개 이상 존재할 수 있다. 예를 들어, 모바일 디바이스(300)에는 복수의 디스플레이부들이 하나의 면에 이격되거나 일체로 배치될 수 있고, 또한 서로 다른 면에 각각 배치될 수도 있다.
디스플레이부(351)와 터치 동작을 감지하는 센서(이하 '터치 센서'라 함)가 상호 레이어 구조를 이루는 경우(이하, '터치 스크린'이라 함)에, 디스플레이부(351)는 출력 디바이스 이외에 인풋 디바이스로도 사용될 수 있다. 터치 센서는, 예를 들어, 터치 필름, 터치 시트, 터치 패드 등의 형태를 가질 수 있다.
터치 센서는 디스플레이부(351)의 특정 부위에 가해진 압력 또는 디스플레이부(351)의 특정 부위에 발생하는 정전 용량 등의 변화를 전기적인 입력신호로 변환하도록 구성될 수 있다. 터치 센서는 터치 되는 위치 및 면적뿐만 아니라, 터치 시의 압력까지도 검출할 수 있도록 구성될 수 있다.
터치 센서에 대한 터치 인풋이 있는 경우, 그에 대응하는 신호(들)는 터치 제어기로 보내진다. 터치 제어기는 그 신호(들)를 처리한 다음 대응하는 데이터를 제어부(380)로 전송한다. 이로써, 제어부(380)는 디스플레이부(351)의 어느 영역이 터치 되었는지 여부 등을 알 수 있게 된다.
터치스크린에 의해 감싸지는 모바일 디바이스의 내부 영역 또는 상기 터치 스크린의 근처에 근접 센서(341)가 배치될 수 있다. 상기 근접 센서는 소정의 검출면에 접근하는 물체, 혹은 근방에 존재하는 물체의 유무를 전자계의 힘 또는 적외선을 이용하여 기계적 접촉이 없이 검출하는 센서를 말한다. 근접 센서는 접촉식 센서보다는 그 수명이 길며 그 활용도 또한 높다.
상기 근접 센서의 예로는 투과형 광전 센서, 직접 반사형 광전 센서, 미러 반사형 광전 센서, 고주파 발진형 근접 센서, 정전용량형 근접 센서, 자기형 근접 센서, 적외선 근접 센서 등이 있다. 상기 터치스크린이 정전식인 경우에는 상기 포인터의 근접에 따른 전계의 변화로 상기 포인터의 근접을 검출하도록 구성된다. 이 경우 상기 터치 스크린(터치 센서)은 근접 센서로 분류될 수도 있다.
이하에서는 설명의 편의를 위해, 상기 터치스크린 상에 포인터가 접촉되지 않으면서 근접되어 상기 포인터가 상기 터치스크린 상에 위치함이 인식되도록 하는 행위를 "근접 터치(proximity touch)"라고 칭하고, 상기 터치스크린 상에 포인터가 실제로 접촉되는 행위를 "접촉 터치(contact touch)"라고 칭한다. 상기 터치스크린 상에서 포인터로 근접 터치가 되는 위치라 함은, 상기 포인터가 근접 터치될 때 상기 포인터가 상기 터치스크린에 대해 수직으로 대응되는 위치를 의미한다.
상기 근접 센서는, 근접 터치와, 근접 터치 패턴(예를 들어, 근접 터치 거리, 근접 터치 방향, 근접 터치 속도, 근접 터치 시간, 근접 터치 위치, 근접 터치 이동 상태 등)을 감지한다. 상기 감지된 근접 터치 동작 및 근접 터치 패턴에 상응하는 정보는 터치 스크린상에 출력될 수 있다.
음향출력모듈(352)은, 호신호 수신, 통화 모드 또는 녹음 모드, 음성인식 모드, 방송수신 모드 등에서 무선 통신부(310)로부터 수신되거나 메모리(360)에 저장된 오디오 데이터를 출력할 수 있다. 음향 출력 모듈(352)은 모바일 디바이스(300)에서 수행되는 기능(예를 들어, 호신호 수신음, 메시지 수신음 등)과 관련된 음향 신호를 출력하기도 한다. 이러한 음향 출력 모듈(352)에는 리시버(receiver), 스피커(speaker), 버저(buzzer) 등이 포함될 수 있다.
알람부(353)는, 모바일 디바이스(300)의 이벤트 발생을 알리기 위한 신호를 출력한다. 모바일 디바이스에서 발생 되는 이벤트의 예로는 호 신호 수신, 메시지 수신, 키 신호 입력, 터치 입력 등이 있다. 알람부(353)는, 비디오 신호나 오디오 신호 이외에 다른 형태, 예를 들어 진동으로 이벤트 발생을 알리기 위한 신호를 출력할 수도 있다. 상기 비디오 신호나 오디오 신호는 디스플레이부(351)나 음성 출력 모듈(352)을 통해서도 출력될 수 있어서, 그들(351,352)은 알람부(353)의 일부로 분류될 수도 있다.
햅틱 모듈(haptic module)(354)은, 사용자가 느낄 수 있는 다양한 촉각 효과를 발생시킨다. 햅틱 모듈(354)이 발생시키는 촉각 효과의 대표적인 예로는 진동이 있다. 햅택 모듈(354)이 발생하는 진동의 세기와 패턴 등은 제어 가능하다. 예를 들어, 서로 다른 진동을 합성하여 출력하거나 순차적으로 출력할 수도 있다. 햅틱 모듈(354)은, 진동 외에도, 접촉 피부면에 대해 수직 운동하는 핀 배열, 분사구나 흡입구를 통한 공기의 분사력이나 흡입력, 피부 표면에 대한 스침, 전극(eletrode)의 접촉, 정전기력 등의 자극에 의한 효과와, 흡열이나 발열 가능한 소자를 이용한 냉/온감 재현에 의한 효과 등 다양한 촉각 효과를 발생시킬 수 있다. 햅틱 모듈(354)은, 직접적인 접촉을 통해 촉각 효과의 전달할 수 있을 뿐만 아니라, 사용자가 손가락이나 팔 등의 근 감각을 통해 촉각 효과를 느낄 수 있도록 구현할 수도 있다. 햅틱 모듈(354)은, 모바일 디바이스(300)의 구성 태양에 따라 2개 이상이 구비될 수 있다.
메모리(360)는, 제어부(380)의 동작을 위한 프로그램을 저장할 수 있고, 입/출력되는 데이터들(예를 들어, 폰 북, 메시지, 정지영상, 동영상 등)을 임시 저장할 수도 있다. 상기 메모리(360)는 상기 터치스크린 상의 터치 인풋 시 출력되는 다양한 패턴의 진동 및 음향에 관한 데이터를 저장할 수 있다.
메모리(360)는, 플래시 메모리 타입(flash memory type), 하드디스크 타입(hard disk type), 멀티미디어 카드 마이크로 타입(multimedia card micro type), 카드 타입의 메모리(예를 들어 SD 또는 XD 메모리 등), 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), EEPROM(Electrically Erasable Programmable Read-Only Memory), PROM(Programmable Read-Only Memory), 자기 메모리, 자기 디스크, 광디스크 중 적어도 하나의 타입의 저장매체를 포함할 수 있다. 모바일 디바이스(300)는 인터넷(internet) 상에서 상기 메모리(360)의 저장 기능을 수행하는 웹 스토리지(web storage)와 관련되어 동작할 수도 있다.
인터페이스부(370)는, 모바일 디바이스(300)에 연결되는 모든 외부 디바이스와의 통로 역할을 한다. 인터페이스부(370)는 외부 디바이스로부터 데이터를 전송 받거나, 전원을 공급받아 모바일 디바이스(300) 내부의 각 구성 요소에 전달하거나, 모바일 디바이스(300) 내부의 데이터가 외부 디바이스로 전송되도록 한다. 예를 들어, 유/무선 헤드셋 포트, 외부 충전기 포트, 유/무선 데이터 포트, 메모리 카드(memory card) 포트, 식별 모듈이 구비된 디바이스를 연결하는 포트, 오디오 I/O(Input/Output) 포트, 비디오 I/O 포트, 이어폰 포트 등이 인터페이스부(370)에 포함될 수 있다.
식별 모듈은 모바일 디바이스(300)의 사용 권한을 인증하기 위한 각종 정보를 저장한 칩으로서, 사용자 인증 모듈(User Identify Module, UIM), 가입자 인증 모듈(Subscriber Identify Module, SIM), 범용 사용자 인증 모듈(Universal Subscriber Identity Module, USIM) 등을 포함할 수 있다. 식별 모듈이 구비된 디바이스(이하 '식별 디바이스')는, 스마트 카드(smart card) 형식으로 제작될 수 있다. 따라서 식별 디바이스는 포트를 통하여 단말기(200)와 연결될 수 있다.
인터페이스부(370)는, 모바일 디바이스(300)가 외부 크래들(cradle)과 연결될 때, 상기 크래들로부터의 전원이 상기 모바일 디바이스(300)에 공급되는 통로가 되거나, 사용자에 의해 상기 크래들에서 입력되는 각종 명령 신호가 상기 모바일 디바이스로 전달되는 통로가 될 수 있다. 크래들로부터 입력되는 각종 명령 신호 또는 상기 전원은, 모바일 디바이스가 상기 크래들에 정확히 장착되었음을 인지하기 위한 신호로 동작될 수도 있다.
제어부(380)는, 통상적으로 모바일 디바이스(300)의 전반적인 동작을 제어한다. 제어부(380)는 예를 들어, 음성 통화, 데이터 통신, 화상 통화 등을 위한 관련된 제어 및 처리를 수행한다. 제어부(380)는, 멀티미디어 재생을 위한 멀티미디어 모듈(381)을 구비할 수도 있다. 멀티미디어 모듈(381)은, 제어부(380) 내에 구현될 수도 있고, 제어부(380)와 별도로 구현될 수도 있다. 제어부(380)는, 터치-스크린상에서 행해지는 필기 인풋 또는 그림 그리기 인풋을 각각 문자 및 이미지로 인식할 수 있는 패턴 인식(pattern recognition) 처리를 행할 수 있다.
전원 공급부(390)는, 제어부(380)의 제어에 의해 외부의 전원, 내부의 전원을 인가받아 각 구성요소들의 동작에 필요한 전원을 공급한다.
여기에 설명되는 다양한 실시 예는 예를 들어, 소프트웨어, 하드웨어 또는 이들의 조합된 것을 이용하여 컴퓨터 또는 이와 유사한 디바이스로 읽을 수 있는 기록매체 내에서 구현될 수 있다.
하드웨어적인 구현에 의하면, 여기에 설명되는 실시 예는 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays, 프로세서, 제어기, 마이크로 컨트롤러(micro-controllers), 마이크로 프로세서(microprocessors), 기타 기능 수행을 위한 전기적인 유닛(unit) 중 적어도 하나를 이용하여 구현될 수 있다. 일부의 경우에 본 명세서에서 설명되는 실시 예들이 제어부(380) 자체로 구현될 수 있다.
소프트웨어적인 구현에 의하면, 본 명세서에서 설명되는 절차 및 기능과 같은 실시 예들은 별도의 소프트웨어 모듈들로 구현될 수 있다. 소프트웨어 모듈들 각각은 본 명세서에서 설명되는 하나 이상의 기능 및 작동을 수행할 수 있다. 적절한 프로그램 언어로 쓰여진 소프트웨어 애플리케이션으로 소프트웨어 코드(software code)가 구현될 수 있다. 여기서, 소프트웨어 코드는, 메모리(360)에 저장되고, 제어부(380)에 의해 실행될 수 있다.
도 4는 본 발명의 또 다른 실시 예에 따른 디지털 디바이스를 설명하기 위해 도시한 구성 블록도이다.
디지털 디바이스(400)의 다른 예는, 방송 수신부(405), 외부 디바이스 인터페이스부(435), 저장부(440), 사용자입력 인터페이스부(450), 제어부(470), 디스플레이부(480), 오디오 출력부(485), 전원 공급부(490) 및 촬영부(미도시)를 포함할 수 있다. 여기서, 상기 방송 수신부(405)는, 적어도 하나의 튜너(410), 복조부(420) 및 네트워크 인터페이스부(430)를 포함할 수 있다. 다만, 경우에 따라, 상기 방송 수신부(405)는 튜너(410)와 복조부(420)는 구비하나 네트워크 인터페이스부(430)는 포함하지 않을 수 있으며 그 반대의 경우일 수도 있다. 또한, 상기 방송 수신부(405)는 도시되진 않았으나, 다중화부(multiplexer)를 구비하여 상기 튜너(410)를 거쳐 복조부(420)에서 복조된 신호와 상기 네트워크 인터페이스부(430)를 거쳐 수신된 신호를 다중화할 수도 있다. 그 밖에 상기 방송 수신부(425)는 역시 도시되진 않았으나, 역다중화부(demultiplexer)를 구비하여 상기 다중화된 신호를 역다중화하거나 상기 복조된 신호 또는 상기 네트워크 인터페이스부(430)를 거친 신호를 역다중화할 수 있다.
튜너(410)는, 안테나를 통해 수신되는 RF(Radio Frequency) 방송 신호 중 사용자에 의해 선택된 채널 또는 기 저장된 모든 채널을 튜닝하여 RF 방송 신호를 수신한다. 또한, 튜너(410)는, 수신된 RF 방송 신호를 중간 주파수(Intermediate Frequency; IF) 신호 혹은 베이스밴드(baseband) 신호로 변환한다.
예를 들어, 수신된 RF 방송 신호가 디지털 방송 신호이면 디지털 IF 신호(DIF)로 변환하고, 아날로그 방송 신호이면 아날로그 베이스밴드 영상 또는 음성 신호(CVBS/SIF)로 변환한다. 즉, 튜너(410)는 디지털 방송 신호 또는 아날로그 방송 신호를 모두 처리할 수 있다. 튜너(410)에서 출력되는 아날로그 베이스 밴드 영상 또는 음성 신호(CVBS/SIF)는 제어부(470)로 직접 입력될 수 있다.
또한, 튜너(410)는, 싱글 캐리어(single carrier) 또는 멀티플 캐리어(multiple carrier)의 RF 방송 신호를 수신할 수 있다. 한편, 튜너(410)는, 안테나를 통해 수신되는 RF 방송 신호 중 채널 기억 기능을 통하여 저장된 모든 방송 채널의 RF 방송 신호를 순차로 튜닝 및 수신하여 이를 중간 주파수 신호 혹은 베이스 밴드 신호(DIF: Digital Intermediate Frequency or baseband signal)로 변환할 수 있다.
복조부(420)는, 튜너(410)에서 변환된 디지털 IF 신호(DIF)를 수신하여 복조하고, 채널 복호화 등을 수행할 수도 있다. 이를 위해 복조부(420)는 트렐리스 디코더(Trellis Decoder), 디인터리버(De-interleaver), 리드 솔로먼 디코더(Reed-Solomon Decoder) 등을 구비하거나 컨벌루션 디코더(convolution decoder), 디인터리버 및 리드-솔로먼 디코더 등을 구비할 수 있다.
복조부(420)는, 복조 및 채널 복호화를 수행한 후 스트림 신호(TS)를 출력할 수 있다. 이때, 스트림 신호는 영상 신호, 음성 신호 또는 데이터 신호가 다중화된 신호일 수 있다. 일 예로, 스트림 신호는 MPEG-2 규격의 영상 신호, 돌비(Dolby) AC-3 규격의 음성 신호 등이 다중화된 MPEG-2 TS(Transport Stream)일 수 있다.
복조부(420)에서 출력한 스트림 신호는 제어부(470)로 입력될 수 있다. 제어부(470)는 역다중화, 영상/음성 신호 처리 등을 제어하고, 디스플레이부(480)를 통해 영상을, 오디오 출력부(485)를 통해 음성의 출력을 제어할 수 있다.
외부 디바이스 인터페이스부(435)는 디지털 디바이스(300)와 다양한 외부 디바이스 사이의 인터페이싱 환경을 제공한다. 이를 위해, 외부 디바이스 인터페이스부(335)는, A/V 입/출력부(미도시) 또는 무선 통신부(미도시)를 포함할 수 있다.
외부 디바이스 인터페이스부(435)는, DVD(Digital Versatile Disk), 블루-레이(Blu-ray), 게임 디바이스, 카메라, 캠코더(Camcorder), 컴퓨터(노트북), 태블릿 PC, 스마트 폰, 블루투스 디바이스(Bluetooth device), 클라우드(Cloud) 등과 같은 외부 디바이스 등과 유/무선으로 접속될 수 있다. 외부 디바이스 인터페이스부(435)는 연결된 외부 디바이스를 통하여 입력되는 이미지, 영상, 음성 등 데이터를 포함한 신호를 디지털 디바이스의 제어부(470)로 전달한다. 제어부(470)는 처리된 이미지, 영상, 음성 등을 데이터 신호를 연결된 외부 디바이스로 출력되도록 제어할 수 있다. 이를 위해, 외부 디바이스 인터페이스부(435)는, A/V 입/출력부(미도시) 또는 무선 통신부(미도시)를 더 포함할 수 있다.
A/V 입/출력부는, 외부 디바이스의 영상 및 음성 신호를 디지털 디바이스(400)로 입력할 수 있도록, USB 단자, CVBS(Composite Video Banking Sync) 단자, 컴포넌트 단자, S-비디오 단자(아날로그), DVI(Digital Visual Interface) 단자, HDMI(High Definition Multimedia Interface) 단자, RGB 단자, D-SUB 단자 등을 포함할 수 있다.
무선 통신부는, 다른 디지털 디바이스와 근거리 무선 통신을 수행할 수 있다. 디지털 디바이스(400)는 예를 들어, 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(IrDA, infrared Data Association), UWB(Ultra Wideband), 지그비(ZigBee), DLNA(Digital Living Network Alliance) 등의 통신 프로토콜에 따라 다른 디지털 디바이스와 네트워크 연결될 수 있다.
또한, 외부 디바이스 인터페이스부(435)는, 셋톱-박스(STB)와 상술한 각종 단자 중 적어도 하나를 통해 접속되어, 셋톱-박스(STB)와 입력/출력 동작을 수행할 수도 있다.
한편, 외부 디바이스 인터페이스부(435)는, 인접하는 외부 디바이스 내의 애플리케이션 또는 애플리케이션 목록(application list)을 수신하여, 제어부(470) 또는 저장부(440)로 전달할 수 있다.
네트워크 인터페이스부(430)는, 디지털 디바이스(400)를 인터넷 망을 포함하는 유/무선 네트워크와 연결하기 위한 인터페이스를 제공한다. 네트워크 인터페이스부(430)는, 유선 네트워크와의 접속을 위해 예를 들어, 이더넷(Ethernet) 단자 등을 구비할 수 있으며, 무선 네트워크와의 접속을 위해 예를 들어, WLAN(Wireless LAN)(Wi-Fi), Wibro(Wireless broadband), Wimax(World Interoperability for Microwave Access), HSDPA(High Speed Downlink Packet Access) 통신 규격 등을 이용할 수 있다.
네트워크 인터페이스부(430)는, 접속된 네트워크 또는 접속된 네트워크에 링크된 다른 네트워크를 통해, 다른 사용자 또는 다른 디지털 디바이스와 데이터를 송신 또는 수신할 수 있다. 특히, 디지털 디바이스(400)에 미리 등록된 다른 사용자 또는 다른 디지털 디바이스 중 선택된 사용자 또는 선택된 디지털 디바이스에, 상기 디지털 디바이스(400)에 저장된 일부의 컨텐트 데이터를 송신할 수 있다.
한편, 네트워크 인터페이스부(430)는, 접속된 네트워크 또는 접속된 네트워크에 링크된 다른 네트워크를 통해, 소정 웹 페이지에 접속할 수 있다. 즉, 네트워크를 통해 소정 웹 페이지에 접속하여, 해당 서버와 데이터를 송신 또는 수신할 수 있다. 그 외, 컨텐트 프로바이더 또는 네트워크 운영자가 제공하는 컨텐트 또는 데이터들을 수신할 수 있다. 즉, 네트워크를 통하여 컨텐트 프로바이더 또는 네트워크 프로바이더로부터 제공되는 영화, 광고, 게임, VOD, 방송 신호 등의 컨텐트 및 그와 관련된 정보를 수신할 수 있다. 또한, 네트워크 운영자가 제공하는 펌웨어(firmware)의 업데이트 정보 및 업데이트 파일을 수신할 수 있다. 또한, 인터넷 또는 컨텐트 프로바이더 또는 네트워크 운영자에게 데이터들을 송신할 수 있다.
또한, 네트워크 인터페이스부(430)는, 네트워크를 통해 공개(open)된 애플리케이션들 중 원하는 애플리케이션을 선택하여 수신할 수 있다.
저장부(440)는, 제어부(470) 내의 각 신호 처리 및 제어를 위한 프로그램을 저장할 수도 있고, 신호 처리된 영상, 음성 또는 데이터 신호를 저장할 수도 있다.
또한, 저장부(440)는 외부 디바이스 인터페이스부(435) 또는 네트워크 인터페이스부(430)로부터 입력되는 영상, 음성, 또는 데이터 신호의 임시 저장을 위한 기능을 수행할 수도 있다. 저장부(440)는, 채널 기억 기능을 통하여 소정 방송 채널에 관한 정보를 저장할 수 있다.
저장부(440)는, 외부 디바이스 인터페이스부(435) 또는 네트워크 인터페이스부(330)로부터 입력되는 애플리케이션 또는 애플리케이션 목록을 저장할 수 있다.
또한, 저장부(440)는, 후술하여 설명하는 다양한 플랫폼(platform)을 저장할 수도 있다.
저장부(440)는, 예를 들어 플래시 메모리 타입(flash memory type), 하드디스크 타입(hard disk type), 멀티미디어 카드 마이크로 타입(multimedia card micro type), 카드 타입의 메모리(예를 들어 SD 또는 XD 메모리 등), 램(RAM), 롬(EEPROM 등) 중 적어도 하나의 타입의 저장매체를 포함할 수 있다. 디지털 디바이스(400)는, 저장부(440) 내에 저장되어 있는 컨텐트 파일(동영상 파일, 정지영상 파일, 음악 파일, 문서 파일, 애플리케이션 파일 등)을 재생하여 사용자에게 제공할 수 있다.
도 4는 저장부(440)가 제어부(470)와 별도로 구비된 실시 예를 도시하고 있으나, 본 발명은 이에 한정되지 않는다. 다시 말해, 저장부(440)는 제어부(470) 내에 포함될 수도 있다.
사용자 입력 인터페이스부(450)는, 사용자가 입력한 신호를 제어부(470)로 전달하거나 제어부(470)의 신호를 사용자에게 전달한다.
예를 들어, 사용자 입력 인터페이스부(450)는, RF 통신 방식, 적외선(IR) 통신 방식 등 다양한 통신 방식에 따라, 원격제어 디바이스(500)로부터 전원 온/오프, 채널 선택, 화면 설정 등의 제어 신호를 수신하여 처리하거나, 제어부(470)의 제어 신호를 원격제어 디바이스(500)로 송신하도록 처리할 수 있다.
또한, 사용자 입력 인터페이스부(450)는, 전원 키, 채널 키, 볼륨 키, 설정치 등의 로컬 키(미도시)에서 입력되는 제어 신호를 제어부(470)에 전달할 수 있다.
사용자 입력 인터페이스부(450)는, 사용자의 제스처(gesture)를 센싱(sensing)하는 센싱부(미도시)로부터 입력되는 제어 신호를 제어부(470)에 전달하거나, 제어부(470)의 신호를 센싱부(미도시)로 송신할 수 있다. 여기서, 센싱부(미도시)는, 터치 센서, 음성 센서, 위치 센서, 동작 센서 등을 포함할 수 있다.
제어부(470)는, 튜너(410), 복조부(420) 또는 외부 디바이스 인터페이스부(435)를 통하여 입력되는 스트림을 역다중화하거나 역다중화된 신호들을 처리하여, 영상 또는 음성 출력을 위한 신호를 생성 및 출력할 수 있다.
제어부(470)에서 처리된 영상 신호는, 디스플레이부(480)로 입력되어 해당 영상 신호에 대응하는 영상으로 표시될 수 있다. 또한, 제어부(470)에서 영상 처리된 영상 신호는 외부 디바이스 인터페이스부(435)를 통하여 외부 출력 디바이스로 입력될 수 있다.
제어부(470)에서 처리된 음성 신호는 오디오 출력부(485)로 오디오 출력될 수 있다. 또한, 제어부(470)에서 처리된 음성 신호는 외부 디바이스 인터페이스부(435)를 통하여 외부 출력 디바이스로 입력될 수 있다.
도 4에서는 도시되어 있지 않으나, 제어부(470)는 역다중화부, 영상 처리부 등을 포함할 수 있다.
제어부(470)는, 디지털 디바이스(400)의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부(470)는, 튜너(410)를 제어하여, 사용자가 선택한 채널 또는 기 저장된 채널에 해당하는 RF 방송을 튜닝(tuning)하도록 제어할 수 있다.
제어부(470)는, 사용자 입력 인터페이스부(450)를 통하여 입력된 사용자 명령 또는 내부 프로그램에 의하여 디지털 디바이스(400)를 제어할 수 있다. 특히, 네트워크에 접속하여 사용자가 원하는 애플리케이션 또는 애플리케이션 목록을 디지털 디바이스(400) 내로 다운로드 받을 수 있도록 할 수 있다.
예를 들어, 제어부(470)는, 사용자 입력 인터페이스부(450)를 통하여 수신한 소정 채널 선택 명령에 따라 선택한 채널의 신호가 입력되도록 튜너(410)를 제어한다. 그리고 선택한 채널의 영상, 음성 또는 데이터 신호를 처리한다. 제어부(470)는, 사용자가 선택한 채널 정보 등이 처리한 영상 또는 음성신호와 함께 디스플레이부(480) 또는 오디오 출력부(485)를 통하여 출력될 수 있도록 한다.
다른 예로, 제어부(470)는, 사용자 입력 인터페이스부(450)를 통하여 수신한 외부 디바이스 영상 재생 명령에 따라, 외부 디바이스 인터페이스부(435)를 통하여 입력되는 외부 디바이스, 예를 들어, 카메라 또는 캠코더로부터의, 영상 신호 또는 음성 신호가 디스플레이부(480) 또는 오디오 출력부(485)를 통해 출력될 수 있도록 한다.
한편, 제어부(470)는, 영상을 표시하도록 디스플레이부(480)를 제어할 수 있다. 예를 들어, 튜너(410)를 통해 입력되는 방송 영상, 또는 외부 디바이스 인터페이스부(435)를 통해 입력되는 외부 입력 영상, 또는 네트워크 인터페이스부를 통해 입력되는 영상, 또는 저장부(440)에 저장된 영상을, 디스플레이부(480)에 표시하도록 제어할 수 있다. 이때, 디스플레이부(480)에 표시되는 영상은, 정지영상 또는 동영상일 수 있으며, 2D 영상 또는 3D 영상일 수 있다.
또한, 제어부(470)는, 컨텐트를 재생하도록 제어할 수 있다. 이때의 컨텐트는, 디지털 디바이스(400) 내에 저장된 컨텐트, 또는 수신된 방송 컨텐트, 외부로부터 입력되는 외부 입력 컨텐트일 수 있다. 컨텐트는, 방송 영상, 외부 입력 영상, 오디오 파일, 정지 영상, 접속된 웹 화면, 및 문서 파일 중 적어도 하나일 수 있다.
한편, 제어부(470)는, 애플리케이션 보기 항목에 진입하는 경우, 디지털 디바이스(300) 내 또는 외부 네트워크로부터 다운로드 가능한 애플리케이션 또는 애플리케이션 목록을 표시하도록 제어할 수 있다.
제어부(470)는, 다양한 사용자 인터페이스와 더불어, 외부 네트워크로부터 다운로드 되는 애플리케이션을 설치 및 구동하도록 제어할 수 있다. 또한, 사용자의 선택에 의해, 실행되는 애플리케이션에 관련된 영상이 디스플레이부(480)에 표시 되도록 제어할 수 있다.
한편, 도면에 도시하지 않았지만, 채널 신호 또는 외부 입력 신호에 대응하는 썸네일 이미지를 생성하는 채널 브라우징 처리부가 더 구비되는 것도 가능하다.
채널 브라우징 처리부는, 복조부(320)에서 출력한 스트림 신호(TS) 또는 외부 디바이스 인터페이스부(335)에서 출력한 스트림 신호 등을 입력받아, 입력되는 스트림 신호로부터 영상을 추출하여 썸네일 영상을 생성할 수 있다. 생성된 썸네일 영상은 그대로 또는 부호화되어 제어부(470)로 입력될 수 있다. 또한, 생성된 썸네일 영상은 스트림 형태로 부호화되어 제어부(470)로 입력되는 것도 가능하다. 제어부(470)는 입력된 썸네일 영상을 이용하여 복수의 썸네일 영상을 구비하는 썸네일 리스트를 디스플레이부(480)에 표시할 수 있다. 한편, 이러한 썸네일 리스트 내의 썸네일 영상들은 차례로 또는 동시에 업데이트 될 수 있다. 이에 따라 사용자는 복수의 방송 채널의 내용을 간편하게 파악할 수 있게 된다.
디스플레이부(480)는, 제어부(470)에서 처리된 영상 신호, 데이터 신호, OSD 신호 또는 외부 디바이스 인터페이스부(435)에서 수신되는 영상 신호, 데이터 신호 등을 각각 R, G, B 신호로 변환하여 구동 신호를 생성한다.
디스플레이부(480)는 PDP, LCD, OLED, 플렉시블 디스플레이(flexible display), 3차원 디스플레이(3D display) 등이 가능할 수 있다.
한편, 디스플레이부(480)는, 터치 스크린으로 구성되어 출력 디바이스 이외에 입력 디바이스로 사용되는 것도 가능하다.
오디오 출력부(485)는, 제어부(470)에서 음성 처리된 신호, 예를 들어, 스테레오 신호, 3.1 채널 신호 또는 5.1 채널 신호를 입력받아 음성으로 출력한다. 음성 출력부(485)는 다양한 형태의 스피커로 구현될 수 있다.
한편, 사용자의 제스처를 감지하기 위해, 상술한 바와 같이, 터치 센서, 음성 센서, 위치 센서, 동작 센서 중 적어도 하나를 구비하는 센싱부(미도시)가 디지털 디바이스(400)에 더 구비될 수 있다. 센싱부(미도시)에서 감지된 신호는 사용자입력 인터페이스부(450)를 통해 제어부(3470)로 전달될 수 있다.
한편, 사용자를 촬영하는 촬영부(미도시)가 더 구비될 수 있다. 촬영부(미도시)에서 촬영된 영상 정보는 제어부(470)에 입력될 수 있다.
제어부(470)는, 촬영부(미도시)로부터 촬영된 영상, 또는 센싱부(미도시)로부터의 감지된 신호를 각각 또는 조합하여 사용자의 제스처를 감지할 수도 있다.
전원 공급부(490)는, 디지털 디바이스(400) 전반에 걸쳐 해당 전원을 공급한다.
특히, 시스템 온 칩(System on Chip; SoC)의 형태로 구현될 수 있는 제어부(470)와, 영상 표시를 위한 디스플레이부(480), 및 오디오 출력을 위한 오디오 출력부(485)에 전원을 공급할 수 있다.
이를 위해, 전원 공급부(490)는, 교류 전원을 직류 전원으로 변환하는 컨버터(미도시)를 구비할 수 있다. 한편, 예를 들어, 디스플레이부(480)가 다수의 백라이트 램프(backlight lamp)를 구비하는 액정 패널로서 구현되는 경우, 휘도 가변 또는 디밍(dimming) 구동을 위해, PWM(Pulse Width Modulation) 동작 가능한 인버터(inverter)(미도시)를 더 구비할 수도 있다.
원격제어 디바이스(500)는, 사용자 입력을 사용자입력 인터페이스부(450)로 송신한다. 이를 위해, 원격제어 디바이스(500)는, 블루투스(Bluetooth), RF(Radio Frequency) 통신, 적외선(IR) 통신, UWB(Ultra Wideband), 지그비(ZigBee) 방식 등을 사용할 수 있다.
또한, 원격제어 디바이스(500)는, 사용자입력 인터페이스부(450)에서 출력한 영상, 음성 또는 데이터 신호 등을 수신하여, 이를 원격제어 디바이스(500)에서 표시하거나 음성 또는 진동을 출력할 수 있다.
상술한 디지털 디바이스(400)는, 고정형 또는 이동형의 ATSC 방식 또는 DVB 방식의 디지털 방송 신호의 처리가 가능한 디지털 방송 수신기일 수 있다.
그 밖에 본 발명에 따른 디지털 디바이스는 도시된 구성 중 필요에 따라 일부 구성을 생략하거나 반대로 도시되진 않은 구성을 더 포함할 수도 있다. 한편, 디지털 디바이스는 상술한 바와 달리, 튜너와 복조부를 구비하지 않고, 네트워크 인터페이스부 또는 외부 디바이스 인터페이스부를 통해서 컨텐트를 수신하여 재생할 수도 있다.
도 5는 본 발명의 일 실시 예에 따라 상술한 제어부의 상세 구성을 설명하기 위해 도시한 구성 블록도이다.
제어부의 일 예는, 역다중화부(510), 영상 처리부(5520), OSD 생성부(540), 믹서(mixer)(550), 프레임 레이트 변환부(FRC: Frame Rate Converter)(555), 및 포맷터(formatter)(560)를 포함할 수 있다. 그 외 상기 제어부는 도시되진 않았으나 음성 처리부와 데이터 처리부를 더 포함할 수 있다.
역다중화부(510)는, 입력되는 스트림을 역다중화한다. 예를 들어, 역다중화부(510)는 입력되는 MPEG-2 TS 영상, 음성 및 데이터 신호로 역다중화할 수 있다. 여기서, 역다중화부(510)에 입력되는 스트림 신호는, 튜너 또는 복조부 또는 외부디바이스 인터페이스부에서 출력되는 스트림 신호일 수 있다.
영상 처리부(420)는, 역다중화된 영상 신호의 영상 처리를 수행한다. 이를 위해, 영상 처리부(420)는, 영상 디코더(425) 및 스케일러(435)를 구비할 수 있다.
영상 디코더(425)는 역다중화된 영상 신호를 복호하며, 스케일러(435)는 복호된 영상 신호의 해상도를 디스플레이부에서 출력 가능하도록 스케일링(scaling)한다.
영상 디코더(525)는 다양한 규격을 지원할 수 있다. 예를 들어, 영상 디코더(525)는 영상 신호가 MPEG-2 규격으로 부호화된 경우에는 MPEG-2 디코더의 기능을 수행하고, 영상 신호가 DMB(Digital Multimedia Broadcasting) 방식 또는 H.264/H.265 규격으로 부호화된 경우에는 H.264/H.265 디코더의 기능을 수행할 수 있다.
한편, 영상 처리부(520)에서 복호된 영상 신호는, 믹서(450)로 입력된다.
OSD 생성부(540)는, 사용자 입력에 따라 또는 자체적으로 OSD 데이터를 생성한다. 예를 들어, OSD 생성부(440)는 사용자입력 인터페이스부의 제어 신호에 기초하여 디스플레이부(380)의 화면에 각종 데이터를 그래픽(Graphic)이나 텍스트(Text) 형태로 표시하기 위한 데이터를 생성한다. 생성되는 OSD 데이터는, 디지털 디바이스의 사용자 인터페이스 화면, 다양한 메뉴 화면, 위젯(widget), 아이콘(icon), 시청률 정보(viewing rate information) 등의 다양한 데이터를 포함한다. OSD 생성부(540)는, 방송 영상의 자막 또는 EPG에 기반한 방송 정보를 표시하기 위한 데이터를 생성할 수도 있다.
믹서(550)는, OSD 생성부(540)에서 생성된 OSD 데이터와 영상 처리부에서 영상 처리된 영상 신호를 믹싱(mixing)하여 포맷터(560)로 제공한다. 복호된 영상 신호와 OSD 데이터가 믹싱됨으로 인하여, 방송 영상 또는 외부 입력 영상 상에 OSD가 오버레이(overlay) 되어 표시된다.
프레임 레이트 변환부(FRC)(555)는, 입력되는 영상의 프레임 레이트(frame rate)를 변환한다. 예를 들어, 프레임 레이트 변환부(555)는 입력되는 60Hz 영상의 프레임 레이트를 디스플레이부의 출력 주파수에 따라 예를 들어, 120Hz 또는 240Hz의 프레임 레이트를 가지도록 변환할 수 있다. 상기와 같이, 프레임 레이트를 변환하는 방법에는 다양한 방법이 존재할 수 있다. 일 예로, 프레임 레이트 변환부(555)는 프레임 레이트를 60Hz에서 120Hz로 변환하는 경우, 제1 프레임과 제2 프레임 사이에 동일한 제1 프레임을 삽입하거나, 제1 프레임과 제2 프레임으로부터 예측된 제3 프레임을 삽입함으로써 변환할 수 있다. 다른 예로, 프레임 레이트 변환부(555)는 프레임 레이트를 60Hz에서 240Hz로 변환하는 경우, 기존 프레임 사이에 동일한 프레임 또는 예측된 프레임을 3개 더 삽입하여 변환할 수 있다. 한편, 별도의 프레임 변환을 수행하지 않는 경우에는 프레임 레이트 변환부(555)를 바이패스(bypass) 할 수도 있다.
포맷터(560)는, 입력되는 프레임 레이트 변환부(555)의 출력을 디스플레이부의 출력 포맷에 맞게 변경한다. 예를 들어, 포맷터(560)는 R, G, B 데이터 신호를 출력할 수 있으며, 이러한 R, G, B 데이터 신호는, 낮은 전압 차분 신호(LVDS: Low voltage differential signal) 또는 mini-LVDS로 출력될 수 있다. 또한, 포맷터(560)는 입력되는 프레임 레이트 변환부(555)의 출력이 3D 영상 신호인 경우에는 디스플레이부의 출력 포맷에 맞게 3D 형태로 구성하여 출력함으로써, 상기 디스플레이부를 통해 3D 서비스를 지원할 수도 있다.
한편, 제어부 내 음성 처리부(미도시)는, 역다중화된 음성 신호의 음성 처리를 수행할 수 있다. 이러한 음성 처리부(미도시)는 다양한 오디오 포맷을 처리하도록 지원할 수 있다. 일 예로, 음성 신호가 MPEG-2, MPEG-4, AAC, HE-AAC, AC-3, BSAC 등의 포맷으로 부호화된 경우에도 이에 대응되는 디코더를 구비하여 처리할 수 있다.
또한, 제어부 내 음성 처리부(미도시)는, 베이스(Base), 트레블(Treble), 음량 조절 등을 처리할 수 있다.
제어부 내 데이터 처리부(미도시)는, 역다중화된 데이터 신호의 데이터 처리를 수행할 수 있다. 예를 들어, 데이터 처리부는 역다중화된 데이터 신호가 부호화된 경우에도 이를 복호할 수 있다. 여기서, 부호화된 데이터 신호로는, 각 채널에서 방영되는 방송 프로그램의 시작시각, 종료시각 등의 방송 정보가 포함된 EPG 정보일 수 있다.
한편, 상술한 디지털 디바이스는 본 발명에 따른 예시로서, 각 구성요소는 실제 구현되는 디지털 디바이스의 사양에 따라 통합, 추가, 또는 생략될 수 있다. 즉, 필요에 따라, 2 이상의 구성요소가 하나의 구성요소로 합쳐지거나 하나의 구성요소가 2 이상의 구성요소로 세분화될 수 있다. 또한, 각 블록에서 수행하는 기능은 본 발명의 실시 예를 설명하기 위한 것이며, 그 구체적인 동작이나 디바이스는 본 발명의 권리범위를 제한하지 아니한다.
한편, 디지털 디바이스는, 디바이스 내에 저장된 영상 또는 입력되는 영상의 신호 처리를 수행하는 영상신호 처리 디바이스일 수 있다. 영상신호 처리 디바이스의 다른 예로는, 도 4에서 도시된 디스플레이부(480)와 오디오 출력부(485)가 제외된 셋톱-박스(STB), 상술한 DVD 플레이어, 블루-레이 플레이어, 게임 디바이스, 컴퓨터 등이 더 예시될 수 있다.
도 6은 본 발명의 일 실시 예에 따른 상술한 디지털 디바이스와 연결된 입력 수단을 도시한 도면이다.
디지털 디바이스(600)를 제어하기 위해 상기 디지털 디바이스(600) 상에 구비된 프론트 패널(front panel)(미도시)이나 제어 수단(입력 수단)이 이용된다.
한편, 제어 수단은 유, 무선 통신 가능한 사용자 인터페이스 디바이스(UID; User Interface Device)로써, 주로 디지털 디바이스(600)의 제어 목적으로 구현된 리모컨(610), 키보드(630), 포인팅 디바이스(620), 터치패드(touch-pad) 등이 포함되나, 상기 디지털 디바이스(600)에 연결된 외부 입력 전용의 제어 수단 역시 포함될 수 있다. 그 밖에, 디지털 디바이스(600) 제어 목적이 아니나 모드 전환 등을 통해 상기 디지털 디바이스(600)를 제어하는 스마트 폰, 태블릿 PC 등 모바일 디바이스 등도 제어 수단에 포함된다. 다만, 본 명세서에서는 편의상 포인팅 디바이스(pointing device)를 일 실시 예로 하여 설명하나, 이에 한정되는 것은 아니다.
입력 수단은, 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(IrDA, infrared Data Association), UWB(Ultra Wideband), 지그비(ZigBee), DLNA(Digital Living Network Alliance), RS 등의 통신 프로토콜을 필요에 따라 적어도 하나 이상 채용하여 디지털 디바이스와 통신 가능하다.
리모컨(610)은, 디지털 디바이스(600) 제어를 위해 필요한 다양한 키 버튼들이 구비된 통상의 입력 수단을 말한다.
포인팅 디바이스(620)는, 자이로 센서(Gyro Sensor) 등을 탑재하여 사용자의 움직임, 압력, 회전 등에 기초하여 디지털 디바이스(600)의 화면상에 대응되는 포인터(pointer)를 구현하여 상기 디지털 디바이스(600)에 소정 제어 명령을 전달한다. 이러한 포인팅 디바이스(620)는, 매직 리모컨, 매직 컨트롤러 등 다양한 이름으로 명명될 수 있다.
키보드(630)는, 디지털 디바이스(600)가 종래 방송만을 제공하던 것을 넘어 지능형 통합 디지털 디바이스로서 웹 브라우저, 애플리케이션, SNS(Social Network Service) 등 다양한 서비스를 제공함에 따라 종래 리모컨(610)만으로는 제어가 쉽지 않아 이를 보완하여 PC의 키보드와 유사하게 구현하여 텍스트 등의 입력 편의를 도모하기 위해 구현되었다.
한편, 리모컨(610), 포인팅 디바이스(620), 키보드(630) 등 제어수단은, 필요에 따라 터치패드를 구비함으로써 텍스트 인풋, 포인터 이동, 사진 내지 동영상의 확대/축소 등 더욱 편리하고 다양한 제어 목적에 이용할 수 있다.
본 명세서에서 설명하는 디지털 디바이스는, OS 및/또는 플랫폼(platform)으로 웹OS를 이용한다. 이하 웹OS 기반의 구성 내지 알고리즘 등 처리 과정은, 전술한 디지털 디바이스의 제어부 등에서 수행될 수 있다. 여기서, 상기 제어부는 전술한 도 2 내지 5에서의 제어부를 포함하여 광의의 개념으로 사용한다. 따라서, 이하에서는 디지털 디바이스 내 웹OS 기반의 또는 그와 관련된 서비스, 애플리케이션, 컨텐트 등의 처리를 위해 구성은 관련 소프트웨어(software), 펌웨어(firmware) 등을 포함한 하드웨어 내지 구성요소는 제어부(controller)로 명명하여 설명한다.
이러한 웹OS 기반 플랫폼은 예컨대, 루나-서비스 버스(Luna-service Bus)에 기반하여 서비스, 애플리케이션 등을 통합함으로써, 개발 독립성과 기능 확장성을 제고하기 위한 것으로, 웹 애플리케이션 프레임워크에 기반하여 애플리케이션 개발 생산성도 높일 수 있다. 또한, 웹OS 프로세스와 리소스 관리(resource management)를 통해 시스템 리소스(system resource) 등을 효율적으로 활용하여 멀티-태스킹(multi-tasking)도 지원할 수 있다.
한편, 본 명세서에서 기술하는 웹OS 플랫폼은 PC, TV, 셋톱박스(STB)와 같은 고정 디바이스뿐만 아니라 휴대폰, 스마트 폰, 태블릿 pc, 노트북, 웨어러블 디바이스(wearable device) 등과 같은 모바일 디바이스에서도 이용 가능하다.
디지털 디바이스를 위한 소프트웨어의 구조는, 종래 문제 해결과 시장에 의존적인 모놀리틱 구조(monolithic structure)로 멀티쓰레딩 기술(multi-threading)에 기반한 단일 프로세스(single process)와 클로우즈드 제품(closed product)으로 외부 응용에 어려움이 있었고, 그 이후 새로운 플랫폼 기반 개발을 지향하고 칩-셋(chip-set) 교체를 통한 비용 혁신과 UI 응용 및 외부 응용 개발 효율화를 추구하여 레이어링 및 콤포넌티제이션(layering & componentization)이 이루어져 3-레이어드 구조와 애드-온(add-on), 싱글 소스(single source) 제품, 오픈 애플리케이션(open application)을 위한 애드-온 구조를 가졌었다. 최근에는 더 나아가 소프트웨어 구조가 기능 단위의 모듈화 아키텍처(modulating architecture), 에코-시스템(echo-system)을 위한 웹 오픈 API(Web Open API (Application Programming Interface)) 제공, 게임 엔진(game engine)을 위한 네이티브 오픈 API(Native Open API) 등을 위한 모듈화 디자인이 이루어지고 있으며, 이에 따라 서비스 구조 기반의 멀티-프로세스 구조(multi-process structure)로 생성되고 있다.
도 7은 본 발명의 일 실시 예에 따른 웹OS 아키텍처를 설명하기 위해 도시한 도면이다.
도 7을 참조하여, 웹OS 플랫폼의 아키텍처에 대해 설명하면, 다음과 같다.
상기 플랫폼은 크게 커널, 시스템 라이브러리(system library) 기반의 웹OS 코어 플랫폼(Web OS core platform), 애플리케이션, 서비스 등으로 구분할 수 있다.
웹OS 플랫폼의 아키텍처는, 레이어드 구조(layered structure)로 최하위의 레이어에는 OS, 다음 레이어에는 시스템 라이브러리(들) 그리고 최상위에는 애플리케이션들(applications)이 존재한다.
먼저, 최하위 레이어는, OS 레이어로 리눅스 커널(Linux Kernel)이 포함되어 상기 디지털 디바이스의 OS로 리눅스를 포함할 수 있다.
상기 OS 레이어 상위에는, BSP(Board Support Package)/HAL(Hardware Abstraction Layer) 레이어, 웹OS 코어 모듈 레이어(Web OS core modules layer), 서비스 레이어(service layer), 루나-서비스 버스 레이어(Luna-Service Bus layer), 엔요 프레임워크/NDK(Native Developer’s Kit)/QT 레이어(Enyo framework/NDK/QT layer) 그리고 최상위 레이어에는 애플리케이션 레이어(Application layer)가 순차로 존재한다.
한편, 상술한 웹OS 레이어 구조 중 일부 레이어는 생략 가능하며, 복수의 레이어가 하나의 레이어화 되거나 반대로 하나의 레이어가 복수의 레이어 구조가 될 수도 있다.
상기 웹OS 코어 모듈 레이어는, 서피스 윈도우(surface window) 등을 관리하는 LSM(Luna Surface Manager), 애플리케이션의 실행과 수행 상태 등을 관리하는 SAM(System & Application Manager), 웹키트(WebKit)에 기반하여 웹 애플리케이션 등을 관리하는 WAM(Web Application Manager) 등을 포함할 수 있다.
상기 LSM은, 디스플레이 처리부로, 화면에 보이는 애플리케이션 윈도우(application window)를 관리한다. 상기 LSM은, 디스플레이 하드웨어(Display HW)를 관장하며, 애플리케이션들에게 필요한 내용을 렌더링(rendering)할 수 있는 버퍼(buffer)를 제공하며, 복수의 애플리케이션들이 렌더링한 결과를 합성(Composition)하여 화면에 출력할 수 있다.
상기 SAM은, 시스템과 애플리케이션의 여러 조건별 수행 폴리시(policy)를 관리한다.
한편, WAM은, 웹OS는 웹 애플리케이션(Web App)을 기본 애플리케이션으로 볼 수 있는바, 엔요 프레임워크(Enyo Framework)에 기반한다.
애플리케이션의 서비스 사용은, 루나-서비스 버스(Luna-service Bus)를 통해 이루어지며, 신규로 서비스를 버스에 등록할 수 있고, 애플리케이션은 자신이 필요로 하는 서비스를 찾아서 사용할 수도 있다.
상기 서비스 레이어는, TV 서비스, 웹OS 서비스 등 다양한 서비스 레벨(service level)의 서비스들이 포함될 수 있다. 한편, 상기 웹OS 서비스에는, 미디어 서버, Node.JS 등이 포함될 수 있으며 특히, Node.JS 서비스는 예컨대, 자바스크립트(javascript)를 지원한다.
웹OS 서비스는, 기능 로직(function logic)을 구현한 리눅스 프로세스(Linux process)로 버스를 통해 커뮤니케이션 할 수 있다. 이는 크게 네 파트로 구분될 수 있으며, TV 프로세스와 기존 TV로부터 웹OS에 미티그레이션(Migration)되거나 제조사 차별화 서비스인 서비스들, 웹OS 공통 서비스와 자바스크립트로 개발되고 Node.js를 통해 사용되는 Node.js 서비스로 구성된다.
상기 애플리케이션 레이어는, TV 애플리케이션, 쇼케이스(showcase) 애플리케이션, 네이티브 애플리케이션(native application), 웹 애플리케이션 등 디지털 디바이스에서 지원 가능한 모든 애플리케이션들을 포함할 수 있다.
웹OS 상의 애플리케이션은, 구현 방법에 따라 웹 애플리케이션(Web Application), PDK(Palm Development Kit) 애플리케이션, QML(Qt Meta Language or Qt Modeling Language) 애플리케이션 등으로 구분될 수 있다.
상기 웹 애플리케이션은, 웹키트 엔진(WebKit engine)에 기반하고, WAM 런타임(Runtime) 상에서 수행된다. 이러한 웹 애플리케이션은 엔요 프레임워크에 기반하거나, 일반 HTML5, CSS(Cascading Style Sheets), 자바스크립트 기반으로 개발되어 수행될 수 있다.
상기 PDK 애플리케이션은, 써드-파티(3rd-Party) 또는 외부 개발자를 위해 제공된 PDK에 기반하여 C/C++로 개발되는 네이티브 애플리케이션 등을 포함한다. 상기 PDK는, 게임 등 써드 파티가 네이티브 애플리케이션(C/C++)을 개발할 수 있도록 제공된 개발 라이브러리 및 도구 집합을 말한다. 예를 들어, PDK 애플리케이션은, 그 성능이 중요한 애플리케이션의 개발에 이용될 수 있다.
상기 QML 애플리케이션은, Qt 기반의 네이티브 애플리케이션으로, 카드 뷰(card view), 홈 대시보드(Home dashboard), 가상 키보드(virtual keyboard) 등 웹OS 플랫폼과 함께 제공되는 기본 애플리케이션 등을 포함한다. 여기서, QML은, C++ 대신 스크립트 형태의 마크-업 언어(mark-up language)이다.
한편, 상기에서, 네이티브 애플리케이션은, C/C++로 개발되고 컴파일(compile)되어 바이너리(binary) 형태로 수행되는 애플리케이션을 말하는 것으로, 이러한 네이티브 애플리케이션은 그 수행 속도가 빠른 장점이 있다.
도 8은 본 발명의 일 실시 예에 따른 웹OS 디바이스의 아키텍처를 설명하기 위해 도시한 도면이다.
도 8은 웹OS 디바이스의 런타임(Runtime)에 기반한 블록도로서, 이는 도 7의 레이어드 구조를 참조하여 이해할 수 있다.
이하, 도 7과 8을 참조하여 설명하면, 다음과 같다.
도 8을 참조하면, 시스템 OS(Linux)와 시스템 라이브러리들 상에 서비스들과 애플리케이션들 그리고 웹OS 코어 모듈들이 포함되고 그들 사이의 커뮤니케이션은 루나-서비스 버스를 통해 이루어질 수 있다.
이메일(e-mail), 연락처(contact), 캘린더(calendar) 등 HTML5, CSS, 자바스크립트(java script)에 기초한 Node.js 서비스들, 로깅(Logging), 백업(backup), 파일 노티파이(file notify), 데이터베이스(DB), 액티비티 매니저(activity manager), 시스템 폴리시(system policy), 오디오 데몬(AudioD: Audio Daemon), 업데이트(update), 미디어 서버(media server) 등과 같이 웹OS 서비스들, EPG(Electronic Program Guide), PVR(Personal Video Recorder), 데이터 방송(data broadcasting) 등과 같은 TV 서비스들, 음성 인식(voice recognition), 나우 온(Now on), 노티피케이션(Notification), 검색(search), ACR(Auto Content Recognition), CBOX(Contents List Broswer), wfdd, DMR, 리모트 애플리케이션(Remote Application), 다운로드, SDPIF(Sony Philips Digital Interface Format) 등과 같은 CP 서비스들, PDK 애플리케이션들, 브라우저(browser), QML 애플리케이션 등과 같은 네이티브 애플리케이션들 그리고, 엔요 프레임워크 기반의 UI 관련 TV 애플리케이션들과 웹 애플리케이션들은, 루나-서비스 버스를 통하여 전술한 SAM, WAM, LSM과 같은 웹OS 코어 모듈을 통해 처리가 이루어진다. 한편, 상기에서, TV 애플리케이션들과 웹 애플리케이션들은 반드시 엔요 프레임워크 기반 또는 UI 관련이 아닐 수도 있다.
CBOX는 TV에 연결된 USB, DLNA, 클라우드 등과 같은 외부 디바이스의 컨텐트에 대한 리스트와 메타데이터 등을 관리할 수 있다. 한편, CBOX는 USB, DMS, DVR, 클라우드 등과 같은 다양한 컨텐트 컨테이너들(content containers)의 컨텐트 리스팅을 통합된 뷰(View)로 출력할 수 있다. 또한, CBOX는 픽쳐, 음악, 비디오 등 다양한 타입들의 컨텐트 리스팅을 보여주고, 그 메타데이터를 관리할 수 있다. 그 밖에, CBOX는, 어태치된 저장장치(attached storage)의 컨텐츠를 리얼-타임(Real-time)으로 출력할 수 있다. 예컨대, CBOX는, USB 등의 저장 디바이스가 플러그-인되면, 해당 저장 디바이스의 컨텐츠 리스트를 즉시 출력할 수 있어야 한다. 이때, 상기 컨텐트 리스팅 처리를 위한 표준화된 방식을 정의할 수도 있다. 또한, CBOX는 다양한 연결 프로토콜을 수용할 수 있다.
SAM은, 모듈 복잡도의 개선 및 확장성을 제고하기 위한 것이다. 이는 예컨대, 기존 시스템 매니저(System Manager)는 시스템 UI, 윈도우 관리, 웹 애플리케이션 런타임, UX 상의 제약 조건 처리 등의 여러 기능을 하나의 프로세스에서 처리하여 구현 복잡도가 커 이를 해소하고자 주요 기능을 분리하고 기능 간 인터페이스를 명확히 함으로써 구현 복잡도를 낮춘다.
LSM은, 카드 뷰, 런처(launcher) 등 시스템 UX 구현이 독립적으로 개발 통합될 수 있도록 지원하고, 제품 요구사항 변경 등에 쉽게 대응할 수 있도록 지원한다. 한편, LSM은, 앱온앱 등과 같이 복수의 애플리케이션 화면을 합성하는 경우에 하드웨어 리소스(HW resource)를 최대한 활용하여 멀티-태스킹이 가능하도록 하는데, 멀티-윈도우(multi-window)와 21:9 등을 위한 윈도우 매니지먼트 메커니즘(window management mechanism)을 제공할 수 있다.
LSM은, QML에 기반하여 시스템 UI의 구현을 지원하며, 그 개발 생산성을 제고한다. QML UX는 MVC에 기반하여, 화면 레이아웃(Layout) 및 UI 컴포넌트를 쉽게 뷰를 구성할 수 있고, 사용자 입력을 처리하기 위한 코드를 쉽게 개발할 수도 있다. 한편, QML과 웹OS 컴포넌트 간의 인터페이스는 QML 확장 플러그-인을 통해 이루어지며, 애플리케이션의 그래픽 오퍼레이션(graphic operation)은 웨이랜드 프로토콜(wayland protocol), 루나 서비스 콜(luna-service call) 등에 기반할 수 있다.
LSM은 전술한 바와 같이, Luna Surface Manager의 약어로서, 애플리케이션 윈도우 컴포지터(Application Window Compositor)의 기능을 한다.
LSM은 독립적으로 개발된 애플리케이션, UI 컴포넌트 등을 화면에 합성하여 출력하도록 한다. 관련하여, 리센츠(Recents) 애플리케이션, 쇼케이스 애플리케이션, 런처 애플리케이션 등과 같은 컴포넌트(component)들이 각자 자신의 내용을 렌더링(rendering)하면, LSM은 컴포지터로서 출력 영역, 연동 방법 등에 대해 정의한다. 다시 말해, 컴포지터인 LSM은 그래픽 합성, 포커스 관리(focus management), 인풋 이벤트(input event) 등을 처리한다. 이때, LSM은 인풋 매니저(input manager)로부터 이벤트, 포커스 등을 수신하는데 이러한 인풋 매니저로 리모트 컨트롤러, 마우스 & 키보드와 같은 HID, 조이스틱, 게임 패드, 애플리케이션 리모트, 펜 터치 등이 포함될 수 있다.
이와 같이, LSM은 멀티플 윈도우 모델(multiple window model)을 지원하는데 시스템 UI 성격으로 모든 애플리케이션에서 동시에 수행 가능하다. 관련하여, 런쳐, 리센츠, 세팅(setting), 노티피케이션, 시스템 키보드, 볼륨 UI, 검색, 핑거 제스쳐(finger gesture), 음성인식(Voice Recognition)(STT(Sound to Text), TTS(Text to Sound), NLP(Natural Language Processing) 등), 패턴 제스쳐(pattern gesture)(카메라, MRCU(Mobile Radio Control Unit)), 라이브 메뉴(Live menu), ACR(Auto Content Recognition) 등을 LSM이 지원할 수 있다.
도 9는 본 발명의 일 실시 예에 따른 웹OS 디바이스에서 그래픽 컴포지션 플로우(graphic composition flow)를 설명하기 위해 도시한 도면이다.
도 9를 참조하면, 그래픽 컴포지션 처리는, UI 프로세스를 담당하는 웹 애플리케이션 매니저(910), 웹 프로세스를 담당하는 웹키트(Webkit)(920), LSM(930) 그리고 그래픽 매니저(GM: Graphic Manager)(940)를 통해 이루어질 수 있다.
웹 애플리케이션 매니저(910)에서 UI 프로세스로서 웹 애플리케이션 기반의 그래픽 데이터(또는 애플리케이션)가 생성이 되면, 생성된 그래픽 데이터가 풀-스크린 애플리케이션이 아니면 LSM(930)으로 전달한다. 한편, 웹 애플리케이션 매니저(910)는 UI 프로세스와 웹 프로세스 사이에 그래픽 매니징을 위한 GPU(Graphic Processing Unit) 메모리 공유를 위하여 웹키트(920)에서 생성된 애플리케이션을 수신하여 이를 상기와 같이 풀-스크린 애플리케이션이 아닌 경우에는 LSM(930)으로 전달한다. 상기에서 풀-스크린 애플리케이션인 경우에는, LSM(930)을 바이패스(bypass)할 수 있으며, 이 경우 직접 그래픽 매니저(940)로 전달될 수 있다.
LSM(930)은 수신되는 UI 애플리케이션을 웨이랜드 서피스를 거쳐 웨이랜드 컴포지터(Wayland Compositor)로 전송하고, 웨이랜드 컴포지터에서 이를 적절히 처리하여 그래픽 매니저로 전달한다. 이렇게 LSM(930)에서 전달되는 그래픽 데이터는 예컨대, 그래픽 매니저(940)의 LSM GM 서피스를 거쳐 그래픽 매니저 컴포지터를 전달된다.
한편, 풀-스크린 애플리케이션은 전술한 바와 같이, LSM(930)을 거치지 않고 바로 그래픽 매니저(940)로 전달이 되는데 이러한 애플리케이션은 WAM GM 서피스로 거쳐 그래픽 매니저 컴포지터에서 처리된다.
그래픽 매니저는 웹OS 디바이스 내의 모든 그래픽 데이터를 처리하는데, 전술한 LSM GM 서피스를 거친 데이터, WAM GM 서피스를 거친 데이터뿐 아니라 데이터 방송 애플리케이션(Data Broadcasting application), 캡션 애플리케이션(caption application) 등과 같이 GM 서피스를 거친 그래픽 데이터를 모두 수신하여 화면상에 적절히 출력되도록 처리한다. 여기서, GM 컴포지터의 기능은 전술한 컴포지터와 동일 또는 유사한 기능이다.
도 10은 본 발명의 일 실시 예에 따른 미디어 서버를 설명하기 위해 도시한 도면이고, 도 11은 본 발명의 일 실시 예에 따른 미디어 서버의 구성 블록도를 설명하기 위해 도시한 도면이고, 도 12는 본 발명의 일 실시 예에 따른 미디어 서버와 TV 서비스의 관계를 설명하기 위해 도시한 도면이다.
미디어 서버는, 디지털 디바이스 내 다양한 멀티미디어의 실행을 지원 및 필요한 리소스를 관리한다. 미디어 서버는, 미디어 플레이(media play)에 필요한 하드웨어 리소스를 효율적으로 사용할 수 있다. 예컨대, 미디어 서버는, 멀티미디어의 실행을 위해서는 오디오/비디오 하드웨어 리소스가 필요하며, 리소스 사용 현황을 관리하여 효율적으로 활용할 수 있다. 일반적으로 모바일 디바이스보다 큰 화면을 가진 고정 디바이스는, 멀티미디어 실행 시 하드웨어 리소스가 더 필요하고, 많은 데이터 양으로 인해 인코딩/디코딩 및 그래픽 데이터 전달 속도도 빨라야 한다. 한편, 미디어 서버는, 스트리밍, 파일 기반 재생 이외에, 브로드캐스팅(Broadcasting), 레코딩(Recording) 및 튜닝(Tuning) 태스크, 시청과 동시에 녹화를 한다거나, 영상 통화 시 송신자와 수신자 화면을 동시에 보여준다거나 하는 태스크 등을 처리할 수 있어야 한다. 다만, 미디어 서버는, 인코더, 디코더, 튜너, 디스플레이 엔진(display engine) 등 하드웨어 리소스가 칩-셋 단위로 제한이 있어, 동시에 여러 태스크를 실행하는 것이 어려워 예를 들어, 사용 시나리오를 제약하거나 사용자 선택을 입력받아 처리한다.
미디어 서버는, 시스템 안정성을 강화(robustness)할 수 있는데 이는 예컨대, 미디어 재생 중 에러(error)가 발생한 재생 파이프라인(pipeline)을 파이프라인별로 제거 가능하고 재 기동함으로써, 상기와 같이 에러가 발생하는 경우에도 다른 미디어 플레이에 영향을 주지 않을 수 있다. 이러한 파이프라인은, 미디어 재생 요청 시, 디코딩, 분석, 출력 등 각 단위 기능들을 연결한 체인(chain)으로, 미디어 타입(media type) 등에 따라, 필요 단위 기능들이 달라질 수 있다.
미디어 서버는, 확장성(extensibility)를 가질 수 있는데 예컨대, 새로운 타입의 파이프라인을 기존 구현 방식에 영향을 주지 않고 추가할 수 있다. 일 예로, 미디어 서버는, 카메라 파이프라인, 화상 회의(Skype) 파이프라인, 써드-파티 파이프라인 등을 수용할 수 있다.
미디어 서버는, 일반 미디어 재생과 TV 태스크 실행을 별개의 서비스로 처리할 수 있는데, 이는 TV 서비스의 인터페이스가 미디어 재생 경우와는 다르기 때문이다. 상기에서, 미디어 서버는, TV 서비스와 관련하여 ‘setchannel’, ‘channelup’, ‘channeldown’, ‘channeltuning’, ‘recordstart’ 등의 오퍼레이션을 지원하고, 일반 미디어 재생과 관련하여 ‘play’, ‘pause’, ‘stop’ 등의 오퍼레이션을 지원하여 양자에 대해 서로 다른 오퍼레이션을 지원하고, 별개의 서비스로 처리할 수 있다.
미디어 서버는 자원 관리 기능을 통제 또는 통합 관리할 수 있다. 디바이스 내 하드웨어 리소스 할당, 회수 등은, 미디어 서버에서 통합적으로 이루어지며 특히, TV 서비스 프로세스는 실행 중인 태스크와 리소스 할당 현황 등을 미디어 서버로 전달한다. 미디어 서버는, 각 미디어가 실행될 때마다 리소스를 확보하고 파이프라인이 실행되며, 각 파이프라인이 점유한 리소스 현황에 기반하여, 미디어 실행 요청 시 우선 순위(예를 들어, 폴리시)에 의한 실행 허용 및 다른 파이프라인의 리소스 회수 등을 수행한다. 여기서, 미리 정의된 실행 우선 순위와 특정 요청에 대한 필요 리소스 정보가 폴리시 매니저(policy manager)에 의해 관리되고, 리소스 매니저는 상기 폴리시 매니저와 커뮤니케이션하여 리소스 할당, 회수 등을 처리할 수 있다.
미디어 서버는 재생 관련 모든 오퍼레이션에 관한 식별 인자(ID: identifier)를 보유할 수 있다. 예컨대, 미디어 서버는 식별자에 근거하여 특정 파이프라인을 지시하여 명령을 내릴 수 있다. 미디어 서버는, 둘 이상의 미디어 재생을 위하여, 파이프라인들에 둘을 구분하여 명령을 내릴 수 있다.
미디어 서버는 HTML 5 표준 미디어의 재생을 담당할 수 있다.
그 밖에, 미디어 서버는 TV 파이프라인의 별도 서비스 프로세스화는 TV 재구조화 범위에 따를 수 있다. 미디어 서버는, TV 재구조화 범위와 무관하게 설계 구현될 수 있는데, TV가 별도 서비스 프로세스화가 되지 않으면, 특정 태스크에 문제가 생길 때 TV 전체를 재실행해야 할 수도 있다.
미디어 서버는, uMS 즉, 마이크로 미디어 서버(micro media server)라고도 한다. 여기서, 미디어 플레이어(media player)가 미디어 클라이언트(media client)인데, 이는 예컨대, HTML5 비디오 태그(video tag), 카메라(Camera), TV, 스카이프(Skype), 세컨드 스크린(2nd Screen) 등을 위한 웹키트(Webkit)을 의미할 수 있다.
미디어 서버는, 리소스 매니저(resource manager), 폴리시 매니저(policy manager) 등과 같은 마이크로 리소스(micro resource)의 관리가 핵심 기능이다. 관련하여, 미디어 서버는, 웹 표준 미디어 컨텐트에 대한 재생(playback) 제어 역할도 제어한다. 이와 관련하여, 미디어 서버는 파이프라인 컨트롤러 리소스(pipeline controller resource)도 관리할 수 있다.
이러한 미디어 서버는 예컨대, 확장성(extensibility), 신뢰성(reliability), 리소스의 효율적 사용(efficient resource usage) 등을 지원한다.
다시 말해, uMS 즉, 미디어 서버는, 클라우드 게임(cloud game), MVPD(pay service 등), 카메라 프리뷰(camera preview), 세컨드 스크린(2nd screen), 스카이프 등과 같은 리소스와 TV 리소스 등의 웹OS 디바이스 내에서 적절한 처리를 위한 리소스 사용을 전반적으로 관리하고 제어하여 효율적인 사용이 가능하도록 관리 제어하는 기능을 한다. 한편, 각 리소스는 그 이용 시에 예컨대, 파이프라인을 이용하는데 미디어 서버는 리소스 관리를 위한 파이프라인의 생성, 삭제, 이용 등을 전반적으로 관리 제어할 수 있다.
여기서, 파이프라인이라 함은 예컨대, 태스크(task)와 관련된 미디어가 요청(request), 디코딩 스트림(decoding stream), 비디오 출력(video output) 등의 파싱(parsing)과 같은 작업의 연속을 시작하면 생성될 수 있다. 예컨대, TV 서비스 내지 애플리케이션과 관련하여, 시청(watching), 녹화(recording), 채널 튜닝(channel tuning) 등은 각각 개별적으로 그 요청에 따라 생성된 파이프라인을 통하여 리소스 이용 등에 대해 제어를 받아 처리된다.
도 10을 참조하여, 미디어 서버의 처리 구조 등에 대해 더욱 상세하게 설명하면, 다음과 같다.
도 10에서는, 애플리케이션 또는 서비스는 미디어 서버(1020)와 루나-서비스 버스(1010)를 통해 연결되고, 상기 미디어 서버(1020)는 상기 루나-서비스 버스(1010)를 통해 다시 생성된 파이프라인들과 연결되고 관리한다.
애플리케이션 또는 서비스는 그 특성에 따라 다양한 클라이언트(client)를 구비하고 그를 통해 미디어 서버(1020) 또는 파이프라인과 데이터를 주고 받을 수 있다.
상기 클라이언트에는 예컨대, 미디어 서버(1020)와 연결을 위한 uMedia 클라이언트(웹키트)와 RM(resource manager) 클라이언트(C/C++) 등이 포함된다.
상기 uMedia 클라이언트를 포함한 애플리케이션은, 전술한 바와 같이, 미디어 서버(1020)와 연결된다. 더욱 상세하게는, uMedia 클라이언트는 예컨대, 후술할 비디오 오브젝트와 대응되고, 이러한 클라이언트는 요청 등에 의해 비디오의 동작을 위하여 미디어 서버(1020)를 이용한다.
여기서, 상기 비디오 동작은 비디오 상태에 관한 것으로, 로딩(loading), 언로딩(unloading), 재생(play, playback, or reproduce), 포즈(pause), 중단(stop) 등은 비디오 동작과 관련된 모든 상태 데이터를 포함할 수 있다. 이러한 비디오의 각 동작 내지 상태는 개별 파이프라인 생성을 통해 처리될 수 있다. 따라서, uMedia 클라이언트는 상기 비디오 동작과 관련된 상태 데이터를 미디어 서버 내 파이프라인 매니저(1022)로 전송한다.
파이프라인 매니저(1022)는, 리소스 매니저(1024)와 데이터 커뮤니케이션을 통해 현재 디바이스의 리소스에 대한 정보를 획득하고, 상기 uMedia 클라이언트의 상태 데이터에 대응되는 리소스의 할당을 요청한다. 이때, 파이프라인 매니저(1022) 또는 리소스 매니저(1024)는 상기 리소스 할당 등과 관련하여, 필요한 경우에 폴리시 매니저(1026)과 데이터 커뮤니케이션을 통해 리소스 할당에 대한 제어를 한다. 예컨대, 리소스 매니저(1024)에서 파이프라인 매니저(1022)의 요청에 따라 할당할 리소스가 없거나 부족한 경우에, 폴리시 매니저(1026)의 프라이어티 비교 등에 따라 상기 요청에 따라 적절한 리소스 할당 등이 이루어지도록 할 수 있다.
한편, 파이프라인 매니저(1022)는, 상기 리소스 매니저(1024)의 리소스 할당에 따라 할당된 리소스에 대하여 상기 uMedia 클라이언트의 요청에 따른 동작을 위한 파이프라인 생성을 미디어 파이프라인 컨트롤러(1028)에 요청한다.
미디어 파이프라인 컨트롤러(1028)는 상기 파이프라인 매니저(1022)의 제어에 따라 필요한 파이프라인을 생성한다. 이렇게 생성된 파이프라인에는 도시된 바와 같이, 미디어 파이프라인, 카메라 파이프라인뿐만 아니라, 재생, 포즈, 중단 등과 관련된 파이프라인이 생성될 수 있다. 한편, 상기 파이프라인에는 HTML5, 웹 CP, 스마트쉐어(smartshare) 재생, 썸네일 추출, NDK, 시네마, MHEG(Multimedia and Hypermedia Information coding Experts Group) 등에 대한 파이프라인 등이 포함될 수 있다.
그 밖에, 파이프라인에는 예를 들어, 서비스 기반의 파이프라인(자체 파이프라인)과 URI 기반의 파이프라인(미디어 파이프라인)이 있을 수 있다.
도 10을 참조하면, RM 클라이언트를 포함한 애플리케이션 또는 서비스는 직접적으로 미디어 서버(1020)와 연결되지 않을 수 있다. 이는 애플리케이션 또는 서비스가 직접 미디어를 처리할 수도 있기 때문이다. 다시 말해, 애플리케이션 또는 서비스가 직접 미디어 처리하는 경우에는 미디어 서버를 통하지 않을 수 있다. 다만, 이때, 파이프라인 생성 및 그 이용을 위해 리소스 관리가 필요한바 이를 위해 uMS 커넥터가 기능한다. 한편, 상기 uMS 커넥터는 상기 애플리케이션 또는 서비스의 직접적인 미디어 처리를 위한 리소스 관리 요청이 수신되면, 리소스 매니저(1024)를 포함한 미디어 서버(1020) 통신한다. 이를 위하여 미디어 서버(1020) 역시 uMS 커넥터가 구비되어야 한다.
따라서, uMS 커넥터를 통해 리소스 매니저(1024)의 리소스 관리를 받아 애플리케이션 또는 서비스는 RM 클라이언트의 요청에 대응할 수 있다. 이러한 RM 클라이언트는 네이티브 CP, TV 서비스, 세컨드 스크린, 플래시 플레이어, 유투브 MSE(Medai Source Extensions), 클라우드 게임, 스카이프 등의 서비스를 처리할 수 있다. 이 경우, 전술한 바와 같이, 리소스 매니저(1024)는 리소스 관리에 필요한 경우에 폴리시 매니저(1026)와 적절하게 데이터 커뮤니케이션을 통해 리소스를 관리할 수 있다.
한편, URI 기반의 파이프라인은 전술한 RM 클라이언트와 같이 미디어를 직접 처리하는 경우가 아니라, 미디어 서버(1020)를 통해 이루어진다. 이러한 URI 기반 파이프라인에는, 플레이어 팩토리(player factory), G스트리머(Gstreamer), 스트리밍 플러그-인(streaming plug-in), DRM(Digital Rights Management) 플러그인 파이프라인 등이 포함될 수 있다.
한편, 애플리케이션과 미디어 서비스들 사이에 인터페이스 방법은 다음과 같을 수 있다.
웹 애플리케이션에서 서비스를 이용하여 인터페이스하는 방법이다. 이는 PSB(Palm Service Bridge)를 이용하여 루나 콜(Luna Call)하는 방법, 코르도바(Cordova)를 이용하는 방법인데 이는 디스플레이를 비디오 태그로 확장하는 것이다. 그 밖에, 비디오 태그나 미디어 엘리먼트(media element)에 관한 HTML5 표준을 이용하는 방법도 있을 수 있다.
그리고, PDK에서 서비스를 이용하여 인터페이스하는 방법이다.
또는, 기존 CP에서 서비스를 이용하는 방법이다. 이는 호환성(backward compatibility)를 위해 기존 플랫폼의 플러그-인을 루나 기반으로 확장하여 이용할 수 있다.
마지막으로, non-웹OS인 경우에 인터페이스하는 방법이다. 이 경우에는 직접 루나 버스를 호출하여 인터페이스할 수 있다.
씸리스 체인지(Seamless change)는 별도의 모듈(예를 들어, TVWIN)에 의해 처리되는데, 이는 웹OS 부팅 전 또는 부팅 동안에, 웹OS 없이 TV를 화면에 먼저 보여주고 씸리스하게 처리하기 위한 프로세스이다. 이는 웹OS의 부팅 시간이 늦기 때문에 사용자의 파워 온(Power On) 요청에 빠른 응답을 위해 TV 서비스의 기본 기능을 우선 제공할 목적으로 이용된다. 또한, 상기 모듈은 TV 서비스 프로세스의 일부로, 빠른 부팅과 기본 TV 기능을 제공하는 씸리스 체인지, 공장 모드 등을 지원한다. 또한, 상기 모듈은, Non-웹OS 모드에서 웹OS 모드로 전환도 담당할 수 있다.
도 11을 참조하면, 미디어 서버의 처리 구조를 도시하고 있다.
이때, 도 11에서, 실선 박스는 프로세스 처리 구성을 나타내고, 점선 박스는 프로세스 중 내부 처리 모듈을 나타낼 수 있다. 또한, 실선 화살표는 인터-프로세스 콜 즉, 루나 서비스 콜을 나타내고, 점선 화살표는 등록/알림(register/notify)와 같은 노티피케이션이나 데이터 플로우(data flow)를 나타낼 수 있다.
서비스 또는 웹 애플리케이션 또는 PDK 애플리케이션(이하 ‘애플리케이션’)은, 루나-서비스 버스를 통하여 각종 서비스 처리 구성들과 연결되고, 그를 통해 애플리케이션이 동작하거나 동작 제어된다.
애플리케이션의 타입에 따라 그 데이터 처리 경로는 달라진다. 예컨대, 애플리케이션이 카메라 센서와 관련된 이미지 데이터인 경우에는 카메라 처리부(1130)로 전송이 되어 처리된다. 이때, 카메라 처리부(1130)는 제스처(gesture), 안면 인식(face detection) 모듈 등을 포함하여 수신되는 애플리케이션의 이미지 데이터를 처리한다. 여기서, 카메라 처리부(1130)는 예컨대, 사용자의 선택이나 자동으로 파이프라인 등의 이용이 요구되는 데이터인 경우에는 미디어 서버 처리부(1110)를 통하여 파이프라인을 생성하여 해당 데이터를 처리할 수 있다.
또는, 애플리케이션이 오디오 데이터를 포함한 경우에는 오디오 처리부(AudioD)(1140)과 오디오 모듈(PulseAudio)(1150)을 통하여 해당 오디오를 처리할 수 있다. 예컨대, 오디오 처리부(1140)는 애플리케이션으로부터 수신되는 오디오 데이터를 처리하여 오디오 모듈(1150)로 전송한다. 이때, 오디오 처리부(1140)는 오디오 폴리시 매니저(audio policy manager)를 포함하여 오디오 데이터의 처리를 결정할 수 있다. 이렇게 처리된 오디오 데이터는 오디오 모듈(1160)에서 가공 처리된다. 한편, 상기 애플리케이션은, 오디오 데이터 처리와 관련된 데이터를 오디오 모듈(1160)로 노티피케이션할 수 있고, 이는 관련 파이프라인에서도 상기 오디오 모듈(1160)로 노피티케이션할 수 있다. 상기 오디오 모듈(1150)은 ALSA(Advanced Linux Sound Architecture)를 포함한다.
또는, 애플리케이션이 DRM이 걸려있는 컨텐트를 포함 또는 처리(이하 포함)하는 경우에는, 해당 컨텐트 데이터를 DRM 서비스 처리부(1160)로 전송하고, 상기 DRM 서비스 처리부(1170)는 DRM 인스턴스(instance)를 생성하여 DRM이 걸려 있는 컨텐트 데이터를 처리한다. 한편, DRM 서비스 처리부(1160)는 상기 DRM이 걸려 있는 컨텐트 데이터의 처리를 위하여, 미디어 파이프라인 내 DRM 파이프라인과 루나-서비스 버스를 통해 연결되어 처리할 수 있다.
이하에서는, 애플리케이션이 미디어 데이터이거나 TV 서비스 데이터(예컨대, 방송 데이터)인 경우의 처리에 관해 설명한다.
도 12는, 전술한 도 11에서 미디어 서버 처리부와 TV 서비스 처리부만을 더욱 상세하게 설명하기 위해 도시한 것이다.
따라서, 이하에서는, 도 11과 12를 함께 참고하여 설명한다.
먼저, 애플리케이션이 TV 서비스 데이터를 포함한 경우에는 TV 서비스 처리부(1120/1220)에서 처리된다.
여기서, TV 서비스 처리부(1120)는 예컨대, DVR/채널 매니저, 방송 모듈, TV 파이프라인 매니저, TV 리소스 매니저, 데이터 방송 모듈, 오디오 설정 모듈, 경로 매니저 등 중 적어도 하나 이상을 포함한다. 또는, 도 12에서 TV 서비스 처리부(1220)는, TV 방송 핸들러(TV broadcast handler), TV 방송 인터페이스부(TV Broadcast Interface), 서비스 처리부, TV 미들웨어(TV MW(middleware)), 경로 매니저, BSP(예를 들어, NetCast)를 포함할 수 있다. 여기서, 상기 서비스 처리부는 예를 들어, TV 파이프라인 매니저, TV 리소스 매니저, TV 폴리시 매니저, USM 커넥터 등을 포함한 모듈을 의미할 수 있다.
본 명세서에서, TV 서비스 처리부는, 도 11 또는 12와 같은 구성을 가지거나 양자의 조합으로 구현될 수 있으며, 상기에서 일부 구성은 생략되거나 도시되지 않은 일부 구성이 추가될 수도 있다.
TV 서비스 처리부(1120/1220)는 애플리케이션으로부터 수신된 TV 서비스 데이터의 속성 내지 타입에 기초하여, DVR(Digital Video Recorder)이나 채널 관련 데이터인 경우에는 DVR/채널 매니저로 전송하고, 다시 TV 파이프라인 매니저로 전송하여 TV 파이프라인을 생성하여 처리한다. 한편, 상기 TV 서비스 데이터의 속성 내지 타입이 방송 컨텐트 데이터인 경우에는, TV 서비스 처리부(1120)는 방송 모듈을 거쳐 해당 데이터의 처리를 위하여 TV 파이프라인 매니저를 거쳐 TV 파이프라인을 생성하여 처리한다.
또는, json(Javascript standard object notation) 파일이나 c로 작성된 파일은 TV 방송 핸들러에서 처리되어 TV 방송 인터페이스부를 거쳐 TV 파이프라인 매니저로 전송하여 TV 파이프라인을 생성하여 처리한다. 이 경우, TV 방송 인터페이스부는, TV 방송 핸들러를 거친 데이터 또는 파일을 TV 서비스 폴리시에 기초하여 TV 파이프라인 매니저로 전송하여 파이프라인 생성시 참고할 수 있다.
이하 도 12의 TV 서비스 처리부(1220) 내부 특히, TV 브로드캐스트 인터페이스 이하 단의 처리 과정을 더욱 상세하게 설명하면, 다음과 같다.
TV 브로드캐스트 인터페이스는 TV 서비스 처리부(1220)의 컨트롤러 기능도 수행할 수 있다. TV 브로드캐스트 인터페이스는, TV 파이프라인 매니저로 파이프라인 생성을 요청하고, TV 파이프라인 매니저는 TV 파이프라인을 생성하고 TV 리소스 매니저로 리소스들을 요청한다. TV 리소스 매니저는 UMS 커넥터를 통해 미디어 서버로 리소스 요청을 하고 획득하면, 이를 다시 TV 파이프라인 매니저로 리턴한다.
TV 파이프라인 매니저는 리턴된 리소스들을 생성된 TV 파이프라인 내에 어레인지(arrange)하고, 파이프라인 정보를 패쓰 매니저에 레지스터한다. 이후, TV 파이프라인 매니저는 그 결과를 TV 파이프라인 매니저로 리턴하고, TV 파이프라인 매니저는 파이프라인을 TV 브로드캐스트 인터페이스로 리턴한다.
이후 TV 브로드캐스트 인터페이스는 TV 미들웨어(MW: MiddleWare)와 통신하여 채널 체인지 등을 요청하고, TV 미들웨어에서 그 결과를 리턴한다.
상술한 과정을 통해 TV 서비스는 처리될 수 있다.
TV 파이프라인 매니저는, TV 서비스 내 처리 모듈 내지 매니저 등으로부터 TV 파이프라인 생성 요청에 따라 하나 또는 그 이상의 파이프라인 생성함에 있어서, TV 리소스 매니저의 제어를 받을 수 있다. 한편, TV 리소스 매니저는, TV 파이프라인 매니저의 TV 파이프라인 생성 요청에 따라 TV 서비스를 위해 할당된 리소스의 상태와 할당을 요청하기 위해, TV 폴리시 매니저의 제어를 받을 수 있으며, 미디어 서버 처리부(1110/1210)와 uMS 커넥터를 통해 데이터 커뮤니케이션을 한다. 미디어 서버 처리부(1110/1210) 내 리소스 매니저는 상기 TV 리소스 매니저의 요청에 따라 현재 TV 서비스를 위한 리소스의 상태와 할당 가부 등에 대해 전달한다. 예컨대, 미디어 서버 처리부(1110/1210) 내 리소스 매니저의 확인 결과 만약 TV 서비스를 위한 리소스가 이미 모두 할당된 경우에는, TV 리소스 매니저로 현재 모든 리소스가 할당 완료되었음을 노티파이할 수 있다. 이때, 미디어 서버 처리부 내 리소스 매니저는 상기 노티파이와 함께, TV 서비스를 위해 기할당된 TV 파이프라인들 중 프라이어티나 소정 기준에 따라 소정 TV 파이프라인을 제거하고 요청된 TV 서비스를 위한 TV 파이프라인 생성을 요청 내지 할당할 수도 있다. 또는, TV 리소스 매니저에서 상기 미디어 서버 처리부(1110/1210) 내 리소스 매니저의 상태 보고에 따라 TV 리소스 매니저에서 적절히 TV 파이프라인을 제거, 추가, 신설 등 제어를 할 수 있다.
한편, BSP는 예컨대, 기존 디지털 디바이스와의 호환성(backward compatibility)를 지원한다.
이렇게 생성된 TV 파이프라인들은 그 처리 과정에서 경로 매니저의 제어에 따라 적절히 동작될 수 있다. 경로 매니저는 상기 처리 과정에서 TV 파이프라인만이 아니라 미디어 서버 처리부(1110/1210)에 의해 생성된 파이프라인의 동작까지 고려하여 파이프라인들의 처리 경로 내지 과정을 결정 내지 제어할 수 있다.
다음으로, 애플리케이션이 TV 서비스 데이터가 아니라 미디어 데이터를 포함한 경우에는, 미디어 서버 처리부(1110/1210)에서 처리된다. 여기서, 미디어 서버 처리부(1110/1210)는, 리소스 매니저, 폴리시 매니저, 미디어 파이프라인 매니저, 미디어 파이프라인 컨트롤러 등을 포함한다. 한편, 미디어 파이프라인 매니저와 미디어 파이프라인 컨트롤러의 제어에 따라 생성되는 파이프라인에는 카메라 프리뷰 파이프라인, 클라우드 게임 파이프라인, 미디어 파이프라인 등 다양하게 생성 가능하다. 한편, 미디어 파이프라인에는 스트리밍 프로토콜, 오토/스테이틱 gstreamer, DRM 등이 포함될 수 있는데, 이는 경로 매니저의 제어에 따라 그 처리 플로우가 결정될 수 있다. 상기 미디어 서버 처리부(1110/1210) 내 구체적인 처리 과정은 전술한 도 10의 설명을 원용하고, 여기서 중복 설명하지 않는다.
본 명세서에서 미디어 서버 처리부(1110/1210) 내 리소스 매니저는 예를 들어, 카운터 베이스로 리소스 매니징을 할 수 있다.
상술한 웹OS 플랫폼상에서의 미디어 서버 디자인에 대해 더욱 상세하게 설명하면, 다음과 같다.
미디어 서버는, 써드-파티 멀티미디어 파이프라인(들)이 웹OS 플랫폼과 인터페이스할 수 있도록 지원하는 미디어 프레임워크이다. 상기 미디어 서버는, 상기 써드-파티 멀티미디어 파이프라인(들)이 컴플라이언트(compliant)할 수 있도록 리소스들을 컨트롤, 관리, 아이솔레이트(isolate), 디컴플릭트(deconflict) 등을 할 수 있다. 이러한 미디어 서버는 애플리케이션이 미디어 재생을 할 수 있도록 일반화된 API를 제공하고, 하드웨어 리소스 및 폴리시를 일관성있게 관리하는 플랫폼 모듈로 볼 수 있다. 한편, 미디어 서버의 디자인은 미디어 처리 일반화, 관련 모듈 분리를 통한 복잡도 경감에 있다.
이러한 미디어 서버의 핵심은 예컨대, 서비스 인터페이스와 웹OS UI와의 인테그레이션(integration)을 제공하는 것이다. 이를 위해, 미디어 서버는, 리소스 매니저, 폴리시 매니저, 파이프라인 매니저를 컨트롤하고, 리소스 매니저 쿼리에 따라 API 액세스를 제공한다.
uMS 커넥터는, 클라이언트 미디어 파이프라인 프로세스들을 미디어 서버와 인터페이스하도록 하는 메인 API이자 SDK이다. Ums 커넥터는, 인터페이스에 관한 이벤트이자 메시지이다. 상기 클라이언트 미디어 파이프라인들은 로드, 플레이, 포즈, 시크(seek), 스톱, 언로드, 릴리즈 리소스(release_resource), 어콰이어 리소스(acquire_resource) 등을 인에이블하기 위한 클라이언트 미디어 파이프라인 상태 이벤트들을 구현한다.
uMedia API는 C, C++ API를 미디어 서버로 제공한다.
미디어 리소스 매니저는, 하나의 심플 컨피규레이션 파일로 미디어 하드웨어 리소스들과 파이프라인 클라이언트 리소스 이용을 디스크라이브하는 방법을 제공한다. 미디어 리소스 매니저는, 디폴트 또는 써드-파티 미디어 폴리시 매니지먼트를 구현하기 위해 필요한 모든 성능과 정보를 제공한다.
미디어 폴리시 매니저는, 리소스 컨플릭트 때문에 리소스 매니저가 미디어 파이프라인을 거절하는 경우에 기능한다. 폴리시 매니저는, 써드-파티 폴리시 매니저 구현이 가능하도록 일관적인 API와 SDK를 제공할 수 있다. 상기 폴리시 매니저는 LRU(Least Recently Used)와 매치하는 미디어 파이프라인들을 지원하고, 하나 또는 그 이상의 컨플릭트된 리소스들을 위해 이용될 수 있다.
파이프라인 매니저는, 클라이언트 미디어 파이프라인들을 추적하고 유지한다. 파이프라인 컨트롤러는, 클라이언트 미디어 파이프라인들을 컨트롤하고 관리할 수 있도록 파이프라인 매니저로 일관적인 API를 제공한다.
미디어 서버는 리소스 매니저와 라이브러리 콜로 커뮤니케이션을 하고, 리소스 매니저는 TV 서비스들, 미디어 파이프라인과 루나 서비스 버스를 통해 커뮤니케이션할 수 있다.
상기 미디어 리소스 매니저는, 미디어 하드웨어와 미디어 클라이언트 파이프라인들을 디스크라이브하기 위한 전체 컨피규러블 컨피규레이션 파일을 구성하고, 리소스 컨플릭트를 디텍하며, 미디어 폴리시 매니지먼트를 구현하기 위해 필요한 모든 정보를 수집할 수 있다.
미디어 폴리시 매니저는, 리소스 컨피규레이션 파일의 policy_select와 policy_action 필드를 읽고, 리소스 컨텐션은 policy_select 필드에 의해 설명된 액티브 파이프라인을 선택을 시도하고, policy_action 필드에 기초하여 아웃고잉/선택된 파이프라인들에 대한 문제를 제기한다(issue). 상기 선택 기준은 파이프라인 컨피규레이션 세팅 엔트리에 의해 지지되는 파라미터가 될 수 있다. 폴리시 액션들은 unload와 release이다. 모든 파이프라인들은 할당된 모든 리소스를 릴리즈하기 unload 커맨드를 지원한다. 파이프라인은 특정 리소스를 릴리즈하기 위해 release 커맨드를 부가적으로 지원할 수 있다. 상기에서, release 커맨드는 커먼 리소스들과 경쟁하는 fast switch 파이플라인들을 위한 것이고, 모든 리소스들의 unload 커맨드는 인커밍 파이프라인과 디컨플릭트에 요구되지는 않을 수 있다.
파이프라인 매니저는 파이프라인 컨트롤러를 관리한다. 상기 파이프라인 매니저는 파이프라인 컨트롤러의 러닝 큐(running queue)를 유지하고, 미디어 서버를 통해 애플리케이션(들)로부터 인커밍 메시지(incoming message)를 위한 유니크 인덱싱(unique indexing)을 제공한다.
파이프라인 컨트롤러는, 관련된 미디어 클라이언트 파이프라인 프로세스의 관계를 유지한다. 파이프라인 컨트롤러는, 모든 관련된 상태를 유지하고, 파이프라인 매니저로 미디어 클라이언트 파이프라인 컨트롤 인터페이스를 제공한다. 파이프라인 클라이언트 프로세스는, 미디어 서버 등으로 컨트롤 인터페이스를 제공하기 위해 uMS 커넥터를 이용한 개별적인 프로세스이다. 파이프라인 (클라이언트) 미디어 기술(Gstreamer, Stage Fright)는 미디어 서버 매니지먼트와 서비스들과는 개별적이고 완전히 디커플(decoupled)될 수 있다.
도 13은 본 발명의 일 실시 예에 따른 애플리케이션과 미디어 서비스들 사이의 인터페이싱 방법을 설명하기 위해 도시된 도면이다.
전술한 도 7을 참조하면, 웹OS 상의 서비스는, 기능 로직(function logic)을 구현한 리눅스 프로세스(Linux process)로 버스를 통해 커뮤니케이션 할 수 있으며, 웹OS 상의 애플리케이션은, 구현 방법에 따라 웹 애플리케이션(Web Application), PDK(Palm Development Kit) 애플리케이션, QML(Qt Meta Language or Qt Modeling Language) 애플리케이션 등으로 구분될 수 있다. 상기 웹 애플리케이션은, 웹키트 엔진(WebKit engine)에 기반하고, WAM 런타임(Runtime) 상에서 수행되며, 엔요 프레임워크에 기반하거나, 일반 HTML5, CSS(Cascading Style Sheets), 자바스크립트 기반으로 개발되어 수행될 수 있다. 상기 PDK 애플리케이션은, 써드-파티(3rd-Party) 또는 외부 개발자를 위해 제공된 PDK에 기반하여 C/C++로 개발되는 네이티브 애플리케이션 등을 포함한다. 상기 QML 애플리케이션은, Qt 기반의 네이티브 애플리케이션으로, 웹OS 플랫폼과 함께 제공되는 기본 애플리케이션 등을 포함한다. 상기 네이티브 애플리케이션은, C/C++로 개발되고 컴파일(compile)되어 바이너리(binary) 형태로 수행되는 애플리케이션을 말한다.
이하, 도 13을 참조하여, 애플리케이션에서 서비스를 이용하는 방법에 대해 설명하면, 다음과 같다.
먼저, 웹 애플리케이션에서 서비스를 이용하는 방법에는 크게 3가지 방법이 있다. 하나는 HTML5 표준을 이용하는 방법이고, 다른 하나는 코르도바를 이용하는 방법 그리고 또 다른 하나는 팜서비스브릿지를 이용하여 루나 콜하는 방법이 있다. 상기에서 HTML5 표준을 이용하는 방법은 예컨대, 비디오 태그, 미디어 엘리먼트 등이 이에 해당한다. 한편, 상기 코르도바를 이용하는 방법은 예컨대, 디스플레이를 비디오 태그로 확장하는 방법을 이용할 수 있다.
다시 말해, 도 13을 참조하면, 애플리케이션들(1310,1320)은 미디어 서비스를 위한 미디어 서버(1372), DRM 서비스를 위한 DRM 서버(1374), TV 서비스를 위한 TV 서비스 처리부(1376), 카메라 서비스를 위한 카메라 서비스 처리부(1378), 오디오 서비스를 위한 오디오 처리부(1380) 등을 루나 서비스 버스(1360)을 통해 이용할 수 있다. 이 과정에서, 웹 애플리케이션(1310)은 코르도바 처리부(TV gap)(1342), HTML5 처리부(웹키트)(1344), 팜서비스브릿지 처리부(웹키트)(1346) 등을 이용한다. 이때, 웹 애플리케이션(1310) 중 기존 CP는, 필요에 따라 호환성(backward compatibility)을 위한 플러그-인 처리부(1348)를 이용할 수도 있다. 또한, PDK 애플리케이션(1320)은 PDL 처리부(1350)을 이용하고, 넌-웹OS 애플리케이션(1330)은 루나 서비스 버스(1360)를 통해 직접 서비스를 이용할 수 있다. 특히, 웹 애플리케이션(1310)이 전술한 HTML5 표준에 기초하여 서비스를 이용하는 경우에는, HTML5 처리부(웹키트)(1344)와 루나 서비스 버스(1360)를 거쳐 서비스를 이용할 수 있다. 다만, 웹 애플리케이션(1310)이 전술한 코르도바에 기초하여 서비스를 이용하는 경우에는, 코르도바 처리부(TV gap)(1342)에서 HTML5 처리부(웹키트)(1344) 또는/및 팜서비스브릿지 처리부(웹키트)(1346)를 거쳐 루나 서비스 버스(1360)를 통해 서비스를 이용할 수 있다. 마지막으로, 웹 애플리케이션(1310)이 전술한 팜서비스브릿지에 기초하여 서비스를 이용하는 경우에는, 팜서비스브릿지 처리부(웹키트)(1346)를 거쳐 루나 서비스 버스(1360)를 통해 서비스를 이용할 수 있다. 한편, PDK 애플리케이션(1320)에서 서비스를 이용하는 방법은 PDL에 기초하여 이루어질 수 있다. 예를 들어, PDK 애플리케이션(1320)은 PDL_Service or PDL_ServiceCallWithCallback을 이용하여 루나 콜을 함으로써 해당 서비스를 이용할 수 있다.
그 밖에, 넌-웹OS 애플리케이션은, 별도의 구성없이도 직접 루나 콜을 통해 전술한 서비스를 이용할 수 있다.
상술한 바와 같이, 애플리케이션과 TV 서비스는 도 11 내지 12에 도시된 바와 같이, 미디어 서버, TV 서비스 처리부 등을 통해 처리되며, 그 과정에서 리소스 매니저, 폴리시 매니저, 상기 미디어 서버에 기초한 미디어 파이프라인과 미디어 파이프라인 컨트롤러와, 상기 TV 서비스 처리부에 기초한 TV 파이프라인과 TV 파이프라인 컨트롤러이 이용된다. 한편, 멀티 인스턴스로서 명확한 식별자가 부여된 미디어 재생을 위한 API로는 로드(load), 언로드(unload), 엑시트(exit), 플레이(play), 포즈(pause), 리줌(resume), 스톱(stop), 속성 설정(setproperty), 속성 획득(getproperty) 등이 있으며, TV 재생을 위한 API로는 오픈(open), 릴리즈(release), 채널 설정(setchannel), 채널 업(channelup), 채널 다운(channeldown), 레코드 스타트(start_record), 레코드 스톱(record_stop) 등이 있을 수 있다.
도 14는 본 발명의 일 실시 예에 따른 플랫폼과 애플리케이션 사이의 베이스라인을 설명하기 위해 도시한 도면이다.
도 14a를 참조하여, 먼저 플랫폼 사이드에서 룰을 설명하면, 다음과 같다.
플랫폼은 애플리케이션, 미디어, TV 재생 등과 같은 리소스들의 라이프사이클을 관리한다.
플랫폼은 리소스들의 상태 변화를 관리하며, 영향을 받는 애플리케이션에게 정확한 정보를 노티파이할 수 있다.
플랫폼은 상기 리소스들의 상태 변화가 감지되면, 애플리케이션이 어떤 액션을 할 수 있고, 애플리케이션이 상기 액션을 하지 않을 경우에 발생하는 이벤트에 대해 가이드할 수 있다.
한편, 애플리케이션 사이드에서 룰을 설명하면, 다음과 같다. 애플리케이션은 플랫폼으로부터 상태 변화를 노티파이 받으면 이를 무시하거나 액션할 수 있다.
만약 상기 무시하는 경우에, 그로 인한 이벤트의 책임은 해당 애플리케이션이 진다. 여기서, 그 사이드 효과는 해당 애플리케이션으로만 제한될 수 있다. 마찬가지로, 어떤 의도(intention)을 가지고 액션을 하지 않고 무시할 수 있는 권한도 애플리케이션에 있을 수 있다.
다음으로, 도 14b를 참조하여, 특정 상태 변화를 애플리케이션이 무시하면, 사이드 효과는 해당 애플리케이션에 제한되지 않고 플랫폼 전체 또는 다른 애플리케이션에 영향을 줄 수 있다.
이 경우, 해당 상태 변화에 대한 책임과 권한은 플랫폼 내부적으로 관리하거나 플랫폼 내부적으로 관리하거나 플랫폼에 영향을 주지 않는 최소한의 예외 처리를 책임져야 할 수 있다.
한편, 서비스와 애플리케이션 사이의 베이스라인을 설명하면 예를 들어, MVC(또는 MVP) 구현시에 컨트롤러의 위치는 다음과 같다.
먼저, 서비스의 컨트롤러는, 서비스 내 모델(로직)(Model(logic))의 상태, 조건 등을 참조하여 결정되며, 애플리케이션과의 의존 관계가 없는 폴리시는 서비스 내의 컨트롤러에서 처리한다. 일 예로, 배드 비디오(bad video)가 발생한 경우에는, A/V에 대해 뮤트 처리를 할 수 있다.
반면, 애플리케이션의 컨트롤러는, 애플리케이션 내의 UI 폴리시나 애플리케이션에 의존적인 폴리시의 경우에는 애플리케이션 내에서 처리할 수 있다. 이때, 애플리케이션이 수정된다고 하더라도 서비스에 영향을 안 줄 수 있다.
이하 본 발명에 따른 플랫폼과 애플리케이션 사이에 대한 미디어 상에서 베이스라인은 다음과 같다.
먼저, 케이스 A는, 포어그라운드에서 미디어 플레이 중인 애플리케이션이 백그라운드로 전환이 되거나 애플리케이션이 상기 백그라운드로 전환 이후에 다시 포어그라운드로 전환되는 경우이다.
전자에서, 포어그라운드에서 미디오 플레이 중인 애플리케이션이 백그라운드로 전환이 되기 전에 해당 애플리케이션은 먼저 백그라운드 노티파이를 수신한다. 이때, 상기 애플리케이션은 미디오 재생 상태에서 스스로 포즈할 수 있다. 만약 애플리케이션이 상기 포즈를 스스로 하지 않으면, 오디오 재생은 유지되나 비디오는 Z-order에 의해 자동으로 하이드(hide)되나 대폭(bandwidth)를 차지하게 된다. 일 예로, MP3 플레이어 애플리케이션을 예로 하면, 상기 MP3 플레이어 애플리케이션이 백그라운드로 가더라도 오디오 재생은 유지할 수 있다.
후자에서, 상기 백그라운드로 전환된 애플리케이션이 다시 포어그라운드로 전환이 될 수 있는데, 상기 애플리케이션은 상기 전환 전에 노티파이를 받고, 상기 노티파이가 수신되면, 상기에서 스스로 포즈한 미디어를 다시 플레이한다. 이때, 플레이 지점은 예컨대, 상기 포즈된 이후부터 플레이될 수 있다. 한편, 상기에서 애플리케이션이 플레이를 하지 않으면, 포즈된 상태에서 사용자에게 출력하고, 사용자의 요청에 따라 플레이할 수 있다.
다음으로, 케이스 B는, 애플리케이션이 백그라운드 중에 다른 애플리케이션과 리소스 경쟁에 의해 리소스가 강제로 해제되거나 상기 애플리케이션이 다시 포어그라운드로 전환이 되는 경우이다.
전자에서 애플리케이션이 백그라운드에서 다른 애플리케이션과 리소스 경쟁에 따라 해당 리소스가 해제된 경우, 미디어 서버는 미디어를 강제로 언로드시킨다. 그리고, 상기 미디어 서버는 상기 강제 언로드 이후에 해당 애플리케이션으로 리소스가 부족하여 언로드되었다는 사실을 상기 애플리케이션으로 노티파이할 수 있다. 이때, 상기 미디어 서버로부터 리소스 부족에 따른 언로드 사실을 노티파이 받은 애플리케이션은 알림 팝-업 노출 등과 같이, 적절하게 예외 처리할 수 있다.
반면, 후자에서 상기와 같이, 리소스가 해제되었던 애플리케이션이 다시 포어그라운드로 가게되면, 미디어 서버가 아니라 애플리케이션이 스스로 로드를 호출한다. 그러나, 만약 상기에서 애플리케이션이 로드를 스스로 하지 않은 경우에는, 언로드 상태로 사용자에게 출력하고, 상기 사용자의 요청에 따를 수 있다.
이를 도면을 참조하여, 더욱 상세하게 설명하면, 다음과 같다.
도 15 내지 19는 본 발명의 일 실시 예에 따라 애플리케이션과 미디어 서비스 사이의 런-타임 뷰를 설명하기 위해 도시한 도면이다.
도 15 내지 17은 전술한 케이스 A에 대한 런-타임 뷰를 도시한 것이고, 도 18 내지 19는 전술한 케이스 B에 대한 런-타임 뷰를 도시한 것이다.
먼저, 도 15는 미디어 애플리케이션에서 로드와 플레이 경우에 런-타임 뷰를 도시한 것으로, 미디어 애플리케이션이 미디어 서버로 로드 요청을 하면, 상기 미디어 서버는 미디어 파이프라인을 생성하고, 생성된 미디어 파이프라인에 대한 리소스를 획득한다. 이후, 미디어 애플리케이션은 플레이 요청을 한다.
도 16은, 상기 도 15에서 포어그라운드에서 플레이 중인 미디어 애플리케이션이 백그라운드로 가게된 경우에 런-타임 뷰를 도시한 것으로, 미디어 애플리케이션은 시스템 매니저로부터 포어그라운드에서 백그라운드로 전환 사실을 노티파이 받는다. 이후 미디어 애플리케이션은 미디어 서버로 포즈 요청을 하고, 상기 미디어 서버는 수신된 포즈 요청을 미디어 파이프라인으로 전달한다.
도 17은 상기 도 16과 같이, 백그라운드 전환되었던 애플리케이션이 다시 포어그라운드로 전환되는 경우에 런-타임 뷰를 도시한 것으로, 전술한 바와 같이, 상기 미디어 애플리케이션은 시스템 매니저로부터 다시 포어그라운드로 전환 사실을 노티파이 받는다. 그러면, 상기 미디어 애플리케이션은 미디어 서버로 플레이 요청을 하고, 상기 미디어 서버는 수신한 요청을 미디어 파이프라인으로 전달한다.
다음으로, 도 18은 예를 들어, 도 16과 같이 백그라운드에 있던 미디어 애플리케이션이 다른 애플리케이션 등과의 관계에서 기할당된 리소스가 해제된 경우에 런-타임 뷰를 도시한 것으로, 미디어 애플리케이션은 백그라운드에 있고 포어그라운드 애플리케이션(상기 미디어 애플리케이션 이외의 새로운 애플리케이션)이 미디어 서버로 로드 요청을 하면, 미디어 서버는 상기 포어그라운드 애플리케이션의 로드 요청에 따라 새로운 미디어 파이프라인(New Media Pipeline) 생성을 요청한다. 여기서, 새롭게 생성된 미디어 파이프라인을 위한 리소스가 할당되어야 하는데 기존에 생성된 미디어 파이프라인에 할당된 리소스와 경쟁 관계에 있게 된다. 이때, 기존 미디어 파이프라인(Old Media Pipeline)에 비하여 새롭게 생성된 미디어 파이프라인에 리소스가 할당되면, 미디어 서버는 상기 새로운 미디어 파이프라인을 위한 리소스 할당에 따라 기존 미디어 파이프라인으로 언로드 지시를 하고, 기존 미디어 파이프라인은 리소스를 릴리즈한다. 또한, 미디어 서버는, 백그라운드에 있는 미디어 애플리케이션으로 언로드 이벤트 발생을 노티파이한다.
마지막으로, 도 19는 상기 도 18에서 백그라운드에 있던 미디어 애플리케이션이 다시 포어그라운드로 전환된 경웨 런-타임 뷰를 도시한 것으로, 미디어 애플리케이션은 시스템 매니저로부터 포어그라운드로 전환 사실을 노티파이 받으면, 미디어 서버로 로드 요청을 하고, 미디어 서버는 상기 도 18에서 리소스 릴리즈에 따라 제거된 미디어 파이프라인을 대신하여 새롭게 미디어 파이프라인을 생성하고, 미디어 파이프라인은 미디어 서버로 리소스를 요청하여 획득한다. 이후, 포어그라운드에 있는 미디어 애플리케이션은 미디어 서버로 플레이 요청을 한다.
이상 애플리케이션과 미디어 서버 사이의 런-타임 뷰를 도시하고 설명하였다. 다음으로, 애플리케이션과 TV 서비스 사이의 런-타임 뷰를 설명하면, 다음과 같다.
도 20 내지 23은 본 발명의 일 실시 예에 따른 애플리케이션과 TV 서비스 사이의 런-타임 뷰를 설명하기 위해 도시한 도면이다.
이하에서는 애플리케이션과 TV 서비스 사이에서 특히, 상기 TV 서비스를 기초로 런-타임 뷰를 설명하면, TV 서비스 처리부가 전술한 도 15 내지 19의 미디어 서버의 그 기능을 대신한다.
또한, 여기서는 전술한 미디어 서비스를 대신하여 TV 서비스를 기초로 함에 따라, 채널 체인지나 시청 예약 등과 같은 서비스에 대한 런-타임 뷰를 도시하고 설명한다.
도 20은 TV 서비스 즉, DTV 애플리케이션에서 채널 체인지를 처리하는 런-타임 뷰를 설명한다.
DTV 애플리케이션은 튜닝된 채널의 방송 프로그램 출력을 위한 파이프라인 오픈(open)을 TV 서비스 처리부로 요청하고, TV 서비스 처리부는 상기 채널을 위한 TV 파이프라인을 생성하고, 리소스를 할당 받는다.
이후, DTV 애플리케이션은 TV 서비스 처리부로 채널 설정(setchannel) 요청을 하고, TV 서비스 처리부는 TV 파이프라인에 요청된 채널을 저장하고 저장된 채널을 위한 리소스를 할당한다. 이때, 상기 리소스는 예컨대, 튜너 등을 포함한다. 이후 TV 미디어 파이프라인은 DTV 애플리케이션으로 비디오를 출력 가능함을 노티파이한다.
채널 체인지는 상기 과정을 통해 계속하여 이루어지는데 이때, 매 채널 체인지마다 TV 파이프라인이 새롭게 생성될 수도 있고, 기존 TV 파이프라인을 이용할 수도 있다.
도 21은, TV 서비스를 위한 DTV 애플리케이션이 백그라운드로 전환되는 경우에 런-타임 뷰를 도시한 것으로, DTV 애플리케이션은 시스템 매니저로부터 백그라운도 전환을 노티파이 받으면, TV 서비스 처리부로 스톱(stop) 요청을 한다. TV 서비스 처리부는 상기 백그라운드에 있는 DTV 애플리케이션으로부터 스톱 요청이 수신되면, 기 생성된 TV 파이프라인에 할당된 리소스를 릴리즈한다.
도 22는, TV 서비스를 위한 DTV 애플리케이션이 도 21과 같이, 백그라운드에 있다가 다시 포어그라운드로 전환되는 경우에 런-타임 뷰를 도시한 것으로, DTV 애플리케이션은 상기 시스템 매니저로부터 백그라운드에서 포어그라운드로 전환 사실을 노티파이 받으면, 방송 프로그램 출력을 위한 채널 설정을 TV 서비스 처리부로 요청한다. TV 서비스 처리부는 기 생성된 미디어 파이프라인에 해당 채널을 저장하고 채널 튜닝 등 처리를 위한 리소스를 할당한다.
도 23은, TV 서비스 중 시청 예약을 위한 런-타임 뷰를 도시한 것으로, TV 서비스 처리부는 클라이언트(now and hot)으로부터 시청 예약 요청을 수신하면, 상기 요청된 시청 예약 소정 시간(예를 들어, 1분) 전에 시청 예약 요청 시간이 되었음을 팝-업 메시지로 스크린에 제공하고, TV 서비스 제공을 위한 DTV 애플리케이션의 론칭을 제어한다. 이후, TV 서비스 처리부에서 긴급 메시지(alert) 토스트로 스크린에 제공한 이후에, DTV 애플리케이션은 시청 예약된 채널 설정을 TV 서비스 처리부로 요청하고, TV 서비스 처리부는 TV 미디어 파이프라인에 요청된 채널을 저장하고 필요한 리소스를 할당한다.
도 24와 25는 본 발명의 다른 실시 예에 따른 애플리케이션과 TV 서비스 사이의 런-타임 뷰를 설명하기 위해 도시한 도면이다.
도 24와 25는 도 20 내지 23과 달리, 연속된 TV 서비스 프로세스 처리를 위한 런-타임 뷰를 도시한 것이다. 특히, 도 24는 시청 이후에 녹화 예약(record reservation)을 위한 런-타임 뷰를, 그리고 도 25는 녹화 중에 채널 체인지를 위한 런-타임 뷰를 도시하였다. 특히, 도 24는 편의상 싱글 튜너를 예로 하였다.
도 24를 참조하면, 클라이언트에서 TV 서비스 처리부로 예약 녹화 추가(AddReservedRecord)를 요청하면, 상기 추가 요청된 예약 녹화 시작 시간 소정 시간 전에 팝-업 메시지로 사용자에게 노티파이한다. 이후, TV 서비스 처리부 내 예약 처리부는 DVR 매니저로 녹화 시작(startRecord) 커맨드를 전송하면 녹화용 TV 파이프라인을 새롭게 생성하고 리소스를 할당하고, 기 생성중인 시청용 TV 파이프라인은 상기 생성된 녹화용 TV 파이프라인과 채널을 쉐어(share channel)하고, 상기 DTV 매니저는 녹화 시작 커맨드에 기초하여 쉐어된 채널 정보와 예약 녹화 요청된 채널을 비교하여 녹화를 위한 채널 체인지를 요청하고, TV 서비스 처리부는 DTV 애플리케이션으로 예약 녹화에 따른 채널 체인지를 노티파이한다.
이때, 전술한 바와 같이, 도 24에서는 예컨대, 싱글 튜너를 가정하여 설명한바, 만약 복수의 튜너라면, 상기에서 리소스 쉐어 따른 채널 체인지 노티파이 대신에 새로운 리소스 할당을 노티파이할 수도 있다.
다음으로, 도 25를 참조하면 예를 들어, 상기 녹화 중에 채널 체인지 요청이 수신되는 경우에 런-타임 뷰를 도시한 것으로, DTV 애플리케이션은 상기 채널 체인지 요청에 따라 요청된 채널 설정을 TV 서비스 처리부로 요청한다. TV 서비스 처리부는 이를 시청용 TV 파이프라인으로 전달하고, 리소스 쉐어와 폴리시를 디텍트한다. 이후 TV 서비스 처리부는, 녹화에 따른 채널 체인지가 불가함을 DTV 애플리케이션으로 노티파이하고, 상기 DTV 애플리케이션은 사용자에 의해 선택된 시청 선택에 대한 결과를 팝-업 메시지로 출력하여 노티파이한다.
이후, DTV 애플리케이션은 녹화 리스트를 DVR 매니저로 요청하고 리턴 받으면, 리턴 받은 녹화 리스트로부터 현재 녹화 중인 채널에 비해 채널 체인지가 우선한다고 판단되면, DVR 매니저로 녹화 중단(stopRecording)을 요청하고, DVR 매니저는 이를 녹화용 TV 파이프라인으로 전달하고, TV 서비스 처리부는 상기 녹화용 TV 파이프라인을 제거(destory)한다.
이상 애플리케이션과 미디어 서비스뿐만 아니라 애플리케이션과 TV 서비스 사이에서의 런-타임 뷰에 대한 다양한 실시 예들을 도시하고 설명하였다.
이하에서는 리소스 쉐어링(resource sharing)에 대해 살펴보면 다음과 같다.
기본적으로, TV 서비스의 기능은 단순하게 시청(watching)에만 제한되는 것은 아니다. 예컨대, 즉시 녹화, 스크린 캡쳐(screen capture) 등과 같이 시청과 연계하여 추가 기능들이 동시에 수행될 수 있다. 또한, 예약 녹화, 세컨드 TV(2nd TV), Scart 신호 출력 등과 같이, 상기 시청과는 별개의 동작들이 백그라운드로 수행될 수 있다. 그 밖에, 백그라운드로 동작하는 동작들이 포어그라운드로 전환되어 수행될 수도 있다.
그렇다면, 이러한 내용들이 리소스 할당에 미치는 영향은 예를 들어, 제한된 리소스 상황에서 동시에 여러 동작을 수행하려면, 리소스 컨플릭트 현상이 발생하게 된다. 이를 해소하기 위해서는 다양한 방법이 있는데 본 명세서에서는 일 예로 동일한 리소스를 쉐어하는 리소스 쉐어 개념을 개시하고 설명한다.
TV 서비스를 예로 하면, 싱글 튜너 상황에서 TV 시청과 녹화를 동시에 수행하는 경우, 상기 두 동작 수행을 위해 필요한 리소스 중 특히, 튜너가 1개이기 때문에, 리소스 컨플릭트가 발생한다. 따라서, 이 경우에는 리소스 쉐어가 이용될 수 있다. 또는, 백그라운드로 돌아가던 동작이 포어그라운드로 전환되면서, 이미 포어그라운드에서 실행 중인 시청 동작과 연계됨에 따라 리소스 컨플릭트가 발생할 수 있다. 따라서, 이 경우에도 리소스 쉐어가 이용될 수 있다.
그러면, 쉐어된 리소스(들)의 특징에 대해 검토해 보면, 먼저, 쉐어되는 리소스에 대한 세팅 변경은 다른 동작에 영향을 미칠 수 있기 때문에 컨트롤에 주의하여야 한다. 예를 들어, 싱글 튜너 상황에서 TV 시청과 녹화가 동시에 수행 중인 경우, 리소스 쉐어가 가능한데, 이때, 시청 중인 채널을 체인지하고자 하는 경우에는 어떻게 할 것인가에 대한 이슈가 생긴다. 또한, 리소스 컨플릭트에 의한 할당된 리소스를 릴리즈함에도, 쉐어된 리소스에 의한 동작이 프라이어티에 영향을 미칠 수 있다. 상기와 관련된 내용에 대한 보다 상세한 설명은 후술한다.
상기에서, 비록 TV 서비스를 예로 하여, 리소스 쉐어에 대해 설명하였으나, 이에 한정되는 것은 아니다. 예컨대, 단지 TV 서비스와 그와 연계된 동작에서만 리소스 쉐어 개념이 이용되는 것이 아니라, TV 서비스와 미디어 서비스, 미디어 서비스들 간에도 리소스 쉐어 개념은 이용 가능하다. 정리하면, 리소스 쉐어는 애플리케이션 또는/및 서비스 이용 과정에서 필요한 리소스(들)이 요구됨에도 제한적인 리소스로 인해 리소스 컨플릭트가 발생하는 경우에 이용될 수 있다.
다음으로, 리소스 매니지먼트, 폴리스 매니지먼트 등뿐만 아니라 리소스 쉐어 개념과 관련된 파이프라인에 대해 기술하면, 다음과 같다.
도 26은 본 발명의 일 실시 예에 따른 파이프라인 구조를 설명하기 위해 도시한 도면이다.
파이프라인에는 크게 미디어 재생 등과 관련된 미디어 파이프라인과 TV 서비스 등과 관련된 TV 파이프라인이 있는데, 이하에서는 본 발명의 이해를 돕고 출원인의 설명의 편의를 위하여 특히, TV 파이프라인을 일 예로 하여 설명한다.
TV 파이프라인은, 각기 다른 역할과 특징을 가진 엘레멘트들의 연결로 구성된 구조를 가진다. 예를 들어, 브로드캐스트의 경우 튜너(Tuner), SDEC, PSIP, VDEC, DE 등의 엘레멘트가 파이프라인으로 연결될 수 있다. 여기서, 상기 엘레멘트들은 예컨대, 리소스에 해당할 수 있으며, 이러한 리소스는 특히, 하드웨어 리소스일 수 있다.
이러한 엘레멘트들은 TV 미들웨어 내부에서 쓰레드(Thread) 기반으로 구현되어 있으며, 각 모듈 간에 데이터와 이벤트를 주고 받으며 유기적으로 컨트롤되고 있다. 따라서, 파이프라인 개념에 맞게 각 엘레멘트를 모두 정의하기 위해서는 상기 TV 미들웨어를 재구조화할 수 있다.
이러한 TV 미들웨어 재구조화와 관련하여, 하나의 방법은 TV 파이프라인을 도 26a와 같이, 추상적인 인풋 엘레멘트(Input Element)와 아웃풋 엘레멘트(Output Element)만을 정의하고 각 엘레멘트의 실질적인 커넥션과 컨트롤은 TV 미들웨어에서 담당할 수 있다.
한편, TV 파이프라인은 각 인스턴스마다 유니크한 식별자(ID)를 가지며, 클라이언트는 상기 식별자를 통해서 파이프라인을 컨트롤할 수 있다.
도 26a는 도 26b와 같이 표현할 수도 있다. 한편, 도 26c는 예컨대, TV 파이프라인으로부터 브로드캐스트 파이프라인과 HDMI 파이프라인, 컴포넌트 파이프라인이 파생되는 것을 간략하게 도시한 것이다.
한편, TV 파이프라인의 종류에 대해 기술하면, 다음과 같다.
도 27은 본 발명의 일 실시 예에 따른 파이프라인 종류를 설명하기 위해 도시한 도면이다.
도 27a는 미디어 파이프라인을, 도 27b는 브로드캐스트 파이프라인을, 그리고 도 27c는 HDMI 파이프라인을 도시한 것이다.
도 27a은 예컨대, 미디어 파이프라인을 전술한 도 26과 같은 TV 파이프라인 표기 형태로 표현한 것이다. 상기 미디어 파이프라인은 미디어 서버에서 관리하기 때문에 도시된 바와 다르게 표현 또는 다른 구조를 가질 수도 있다.
미디어 파이프라인의 인풋 엘레멘트 또는 소스는 별도의 하드웨어 리소스를 요구하지 않을 수 있다. 상기 인풋 엘레멘트는 URI이고, 아웃풋 엘레멘트는 시청(W)를 예시한 것으로 그에 따라, VDEC0, ADEC0, DE0 등의 리소스가 요구된다.
도 27b는 브로드캐스트 파이프라인으로 인풋 엘레멘트로 채널이 오며, 그에 따라 튜너(TU0)가 요구된다. 또한, 아웃풋 엘레멘트는 DTV 시청이 오며, 그에 따라 VDEC0, ADEC0, DE0 등의 리소스가 요구된다.
한편, 도 27c는 HDMI 파이프라인으로 인풋 엘레멘트로 HDMI 포트가 오며, 커넥터 리소스가 요구된다. 한편, 아웃풋 엘레멘트는 HDMI 시청(HDMI_W)가 오며, 그에 따라, RX0, ADC0, ADEC0, DE0 등이 요구된다.
상기 도 27a 내지 27c에서, 아웃풋 엘레멘트는 시청을 위해 각 파이프라인마다 필요한 엘레멘트가 생성되며, 필요한 하드웨어 리소스가 할당될 수 있다.
도 28은 본 발명의 일 실시 예에 따른 파이프라인 특성 정의를 설명하기 위해 도시한 도면이다. 여기서, 도 28은 편의상 TV 브로드캐스트 파이프라인을 예로 하여 설명한다.
도 28a를 참조하면, TV 파이프라인은 고유의 식별자(ID1)을 가지며 전술한 바와 같이, 인풋 포트와 아웃풋 포트를 각각 1개씩 가질 수 있다. 여기서, 상기 인풋 포트는 채널 넘버(CH)가 입력될 수 있고, 아웃풋 포트는 시청(Watch), 녹화(Record) 등이 출력될 수 있다.
도 28b를 참조하여, 전술한 도 28a와 관련된 TV 리소스 엘레멘트를 정의하면, 다음과 같다. TV 리소스 엘레멘트는 리소스 매니저로부터 획득한 리소스 정보와 프라이어티 정보(Resource Infor (Priority))를 가질 수 있다. 도 28b의 Prev와 Next 필드를 통해서 리소스 매니저로부터 획득한 리소스 정보 사이의 링크가 허용될 수 있다.
도 28c를 참조하여 TV 파이프라인의 동작 특성을 설명하면, 다음과 같다. TV 파이프라인에 대한 액션은 2개의 포트를 설정하는 다음 단계로 나뉘어질 수 있다. 제1 단계로, 채널을 입력하고, 제2 단계로 출력을 결정하는 것이다. 여기서, 각 단계에서 필요한 리소스가 있는 경우, 리소스 매니저에 요청하여 리소스를 획득한 후 TV 리소스 엘레멘트를 생ㅅ어하고, 그리고 나서 포트와 링크한다. 도 28c는 특히, 채널 설정(setChannel) 이후를 도시한 것이다.
다음으로, TV 파이프라인과 리소스 매니저의 관계에 대해 설명한다. 도 29는 본 발명의 일 실시 예에 따른 파이프라인과 리소스 매니저의 관계를 설명하기 위해 도시한 도면이다.
도 29를 참조하면, 파이프라인과 관련하여 TV 서비스 처리부(2910)과 미디어 서버(2950)가 존재한다.
TV 서비스 처리부(2910)는 TV 파이프라인 매니저(2920)와 TV 리소스 매니저(2930) 등을 포함하고, 미디어 서버(2950)는 리소스 매니저(2960), 폴리시 매니저 등을 포함한다.
TV 리소스 매니저(2930) 내 TV 리소스 엘레멘트는 리소스 매니저(2960)로부터 획득한 리소스 정보를 가지고, 이러한 TV 리소스 엘레멘트는 미디어 파이프라인과 리소스 경쟁 관계이며, 폴리시의 대상이 된다.
한편, TV 파이프라인 매니저(2920)에 의해 매니징되는 TV 파이프라인은 리소스가 충분하다면, N(여기서, N은 양의 정수)개 생성할 수 있다.
또한, TV 파이프라인의 포트는 예컨대, TV 리소스 매니저(2930) 내 TV 리소스 엘레멘트와 도시된 바와 같이, 링크된다.
한편, TV 리소스 엘레멘트는 TV 파이프라인끼리 에일리어싱(aliasing)될 수 있다.
도 30은 본 발명의 일 실시 예에 따른 TV 서비스로 시청과 동시에 녹화를 위한 구성도를 도시한 도면이고, 도 31은 본 발명의 다른 실시 예에 따른 TV 서비스로 시청과 동시에 녹화를 위한 구성도를 도시한 도면이다.
도 30은 싱글 튜너의 경우이고, 도 31은 멀티 튜너의 경우이다. 이로 인해, 도 30에서는 튜너(TU) 리소스를 에일리어싱하게 되고, 도 31에서는 상기 튜너 리소스 에일리어싱이 필요 없다. 다만, 이는 상기 튜너 리소스 관점이고, 도 30 내지 31에서 인풋 포트든 아웃풋 포트든 적어도 하나 이상의 리소스에 대해 에일리어싱이 발생할 수 있다. 다만, 본 시청 & 녹화 동작과 관련하여서는 특히, 튜너 리소스에 대해 에일리어싱이 발생 유무에 대해 가정하여 설명한다.
도 30과 31을 참조하면, 상기 시청과 녹화를 동시에 수행하기 위하여 시청 파이프라인(ID1)과 녹화 파이프라인(ID2)가 각각 생성되어야 하며 이때, 생성되는 각 파이프라인은 고유의 식별자를 가진다.
도 30은 싱글 튜너의 경우로, 이 경우 시청 파이프라인의 인풋 포트와 녹화 파이프라인의 인풋 포트는 둘 다 튜너(TU0) 리소스를 가지는 TV 리소스 엘레멘트와 에일리어싱 된다. 다만, 도 31은 멀티 튜너로 각 인풋 포트가 각각 튜너 리소를 가진 TV 리소스 엘레멘트와 링크 가능하므로 상기 에일리어싱이 발생하지 않는다.
한편, 도 30과 31에서 아웃풋 포트는 그 특성에 따른 TV 리소스 엘레멘트와 링크된다.
한편, 각 파이프라인은 인풋이 변경되면, 아웃풋도 영향을 받을 수 있다. 예컨대, 하나의 파이프라인에서 인풋 포트의 채널이 변경이 되면, 다른 파이프라인의 인풋도 변경될 수 있으며, 각 파이프라인의 아웃풋도 영향받을 수 있다.
리소스 매니저 관점에서 만약 미디어 파이프라인이 생성되면 예컨대, DE0에 대한 리소스 경쟁이 발생 가능하고, 이 경우 시청 파이프라인의 출력 포트에 링크된 리소스가 릴리즈될 수 있다. 다만, 이때 상기 시청 파이프라인의 리소스가 릴리즈되더라도 녹화 파이프라인 즉, 녹화 동작에는 영향이 없으며 유지될 수 있다.
도 31에서는 특히, 하드웨어 폴리시 상황에 따라 특정 리소스(ex, TU0, TU1)을 스왑(swap)시키는 것은 TV 파이프라인 매니저가 담당할 수 있다. 한편, 도 31에서는 시청 파이프라인의 인풋 포트로 채널 체인지가 요청되더라도 녹화에는 영향을 주지 않을 수 있다.
도 32는 본 발명의 일 실시 예에 따른 리소스 엘레멘트 정의를 설명하기 위해 도시한 도면이다.
도 32a를 참조하면, 전술한 바와 같이, TV 리소스 엘레멘트(3210)는 Prev 필드(3212), 리소스 정보 필드(3214) 그리고 Next 필드(3216)로 구성된다. 상기에서, 리소스 정보 필드(3214)는 프라이어티 정보도 함께 포함할 수 있다. 그리고, TV 리소스 엘레멘트(3210)는 상기 Prev와 Next 필드(3212,3216)에 기초하여 다른 TV 리소스 엘레멘트와 링크될 수 있다.
도 32b 내지 32d를 참조하면, 우선 도 32b와 같이, ID1의 리소스 엘레멘트(3220)가 존재한다. 이때, 상기 ID1의 리소스 엘레멘트(3220)는 프라이어티는 노멀(normal)이고 리소스 정보는 A 내지 E이다. 여기서, 만약 새로운 리소스 엘레멘트(3225)가 생성되고 생성된 리소스 엘레멘트의 리소스 정보 중 적어도 하나 이상이 이전 리소스 엘레멘트(3220)의 리소스들 중 하나와 중복되면, 도 32c와 같이, 커먼 리소스(A, B, C)를 가진 인터널 리소스 엘레멘트(3230)는 생성되고 새로운 리소스 엘레멘트(3225)와 이전 엘레멘트(3220)는 Prev 필드에 기초하여 서로 링크(ID3)될 수 있다. 또한, 상기 인터널 리소스 엘레멘트(3230)는 next 필드에 기초하여 상기 엘레멘트들과 링크(ID1, ID2)될 수 있다. 이를 예를 들어, 패런트와 차일드 사이의 관계로 명명할 수 있다. 이때, 상기 엘레멘트들 중에서 인터널 리소스 엘레멘트(3230)가 가장 높은 프라이어티를 가질 수 있다. 이러한 인터널 리소스 엘레멘트(3230)의 프라이어티는 차일드 엘레멘트들의 프라이어티 중 가장 높은 프라이어티를 따를 수 있다. 정리하면, 도 32b 내지 32c를 참조하면, ID1 리소스 엘레멘트(3220)의 리소스는 A 내지 E이고 프라이어티는 노멀이고, ID2 리소스 엘레멘트(3225)의 리소스가 A, B, C, F, G이고 프라이어티는 하이(High)일 경우, 상기 ID2의 리소스 엘레멘트의 리소스들 중 A, B, C가 상기 ID1 리소스 엘레멘트의 리소스들에 포함되어 있으므로, 새롭게 ID3의 인터널 리소스 엘레멘트가 생성이 되고, 상기 ID3 인터널 리소스 엘레멘트는 커먼 리소스인 A, B, C의 리소스 정보를 가진다. 이때, 상기 ID3 인터널 리소스 엘레멘트는 프라이어티는 ID1의 노멀과 ID2의 하이 중 가장 높은 프라이어티를 가진 ID2에 따라 하이를 가진다. 또한, ID3 인터널 리소스 엘레멘트는 Next 필드에 차일드 ID1과 ID2를 포함하여 링크된다. 한편, 이때 ID1과 ID2의 리소스 엘레멘트들은 도 32c에 도시된 바와 같이, 도 32b와는 달리 ID1 리소스 엘레멘트는 D, E의 리소스를 포함하고, ID2의 리소스 엘레멘트는 F, G의 리소스를 포함하고 프라이어티는 변화가 없다. 다만, 이때, 패런트와 차일드 관계에 있는 ID1과 ID2의 리소스 엘레멘트는 커먼 리소스(A, B, C)의 이용을 위하여 Prev 필드에 ID3를 포함하여 링크된다.
도 32d를 참조하면, 만약 차일드 엘레멘트들 중 하나(ID1)가 제거되고 인터널 엘레멘트(ID3)의 차일드 엘레멘트가 한 개(ID2)만 남으면, 상기 인터널 엘레멘트는 더 이상 필요가 없으므로 제거되고 남은 차일드 엘레멘트(ID2)(3240)로 머지(merge)될 수 있다.
도 33은 본 발명의 일 실시 예에 따른 파이프라인 라이프사이클을 설명하기 위해 도시한 도면이다.
도 33을 참조하면, 파이프라인 라이프사이클은 오픈(open), 플레이(play), 스톱(stop) 그리고 클로우즈(close)로 구성된다.
오픈 명령에 따라 파이프라인이 생성이 되는데 이때, 파이프라인 ID가 생성되고 파이프라인 인스턴스가 생성된다. 플레이 명령(ex, watch, record 등)에 따라 동작 즉, 액션을 시작한다. 이때, 상기 플레이 명령에 따라 액션을 수행하기 위해 파이프라인은 리소스 매니저와 커넥션되어 동적으로 리소스를 할당받아 상기 액션을 수행한다. 이후 스톱 명령에 따라 파이프라인은 액션 수행을 중단하고 기 이용하던 리소스를 릴리즈한다. 다만, 상기 스톱 명령에도 불구하고 파이프라인 ID와 파이프라인 인스턴스는 유지된다. 그러나 클로우즈 명령이 수신되면, 상기 유지하던 또는 생성되었던 파이프라인 ID와 파이프라인 인스턴스를 제거한다.
도 33에 도시된 바와 같이, 하나의 파이프라인 라이프사이클이 이루어진다. 다만, 여기에 도시된 바와 다른 패쓰나 다른 구성으로 파이프라인 라이프사이클이 이루어질 수도 있다.
도 34는 본 발명의 일 실시 예에 따른 채널 체인지 경우의 내부 구성들 간의 관계를 설명하기 위해 도시한 도면이다.
TV 애플리케이션(3410)에서 com.webos.service.tv.broadcast/changeChannel로 ID와 채널 정보를 TV 서비스 처리 모듈(3420)로 전송하면, TV 서비스 모듈(3420) 내 TV 브로드캐스트 핸들러(3430)는 interface_broadcast_changeChannel로 ID와 채널 정보를 TV 브로드캐스트 인터페이스(컨트롤러)(3440) 내 TV 서비스 폴리시 처리부(3442)로 전달한다. TV 서비스 폴리시 처리부(3442)는 API_PIPELINE_SetAction으로 ID, 인풋 타입(input_type), 액션, 파라미터를 포함하여 TV 파이프라인 매니저(3450)로 전달하고, TV 파이프라인 매니저(3450)는 리소스를 할당하고, 파이프라인 상태를 오픈에서 플레이로 전환한다. 상기 TV 파이프라인 매니저(3450)는 파이프라인 상태가 플레이로 전환되면, PathOpen으로 ID, 리소스 정보, 인풋 타입, 액션을 패쓰 매니저(3460)로 전달하고, 상기 패쓰 매니저(3460)는 패쓰 인스턴스를 생성하여 ID, 리소스 정보, 인풋 타입, 액션 등의 데이터를 저장한다.
이후, 상기와 같이, 패쓰 매니저(3460)에서 패쓰 인스터스가 생성되어 해당 데이터가 저장되면, TV 파이프라인 매니저(3450)는 리소스 커넥션 이벤트를 TV 브로드캐스트 인터페이스(3440)로 노티파이하고, TV 브로드캐스트 인터페이스(3440)는 DIL을 이용하여 미들웨어(MW)(3470)와 콜 커넥션(call connection)한다. 미들웨어(3470)는 커넥션을 위해 DIL(3480)을 콜하고, DIL(3480)은 커넥션을 수행한다.
TV 브로드캐스트 인터페이스(3440)는 서브 라이브러리(3444)에 ID, 채널 정보 등을 레지스터하고, 상기 레지스터된 ID, 채널 정보 등을 포함한 API_CM_ChannelChange를 미들웨어(3470)로 전송하고, TV 브로드캐스트 핸들러(3430)로 "OK"를 리턴한다. 그러면, TV 브로드캐스트 핸들러(3430)는 최초 TV 애플리케이션(3410)에서 요청한 채널 체인지 요청에 대하여 "OK"를 리턴하여 채널 체인지 동작이 수행된다.
이하에서는 파이프라인을 위한 콜 시퀀스(call sequence)를 첨부된 도면을 참조하여 설명한다.
도 35는 본 발명의 일 실시 예에 따른 파이프라인 콜 시퀀스를 설명하기 위해 도시한 시퀀스 다이어그램이고, 도 36은 본 발명의 다른 실시 예에 따른 파이프라인 콜 시퀀스를 설명하기 위해 도시한 시퀀스 다이어그램이다.
도 35는 예를 들어, TV 서비스 시청 파이프라인 콜 시퀀스를 예시한 것이고, 도 36은 예컨대, 미디어 파이프라인 콜 시퀀스를 예시한 것이다.
먼저, 도 35를 참조하여, TV 서비스 시청 파이프라인 콜 시퀀스를 설명한다. 여기서, 상기 TV 서비스 시청 파이프라인 콜 시퀀스와 관련된 구성은 TV 서비스 시청 파이프라인(3510), 미디어 서버 리소스 매니저(3520), VSM(Video Sink Manager)/DASS(3530) 등이 있다. 상기 VSM은 비디오 처리부라고도 한다.
TV 서비스 시청 파이프라인(3510)과 VSM/DASS(3530)는, 리소스 매니저 클라이언트 생성(ResourceManagerClienCreate [PolicyActionHandler])을 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3502, S3504).
미디어 서버 리소스 매니저(3520)는, 상기 TV 서비스 시청 파이프라인(3510)과 VSM/DASS(3530)의 각 요청에 대하여 리소스 매니저 클라이언트 핸들(ResourceManagerClientHandle)을 각각 리턴한다(S3506, S3508).
TV 서비스 시청 파이프라인(3510)과 VSM/DASS(3530)은, 리소스 매니저 클라이언트 파이프라인 레지스터(ResourceManagerClientRegisterPipeline [tv_watch], ResourceManagerClientRegisterPipeline [vsm])를 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3510, S3512).
상기 TV 서비스 시청 파이프라인(3510)과 VSM/DASS(3530)는, 리소스 매니저 클라이언트 스타트 트랜색션(ResourceManagerClientStartTransaction [Handle_watch], ResourceManagerClientStartTransaction [Handle_vsm])을 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3514, S3516).
그리고, 상기 TV 서비스 시청 파이프라인(3510)과 VSM/DASS(3530)는, 리소스 매니저 클라이언트 획득(ResourceManagerClientAcquire [Handle_watch, resourceList], ResourceManagerClientAcquire (Handle_vsm, resourceList))을 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3518, S3520). 여기서, TV 서비스 시청 파이프라인(3510)의 획득 요청은 다음과 같을 수 있다: (ADTU, qty=1, attr=tv_w_tuner), (SDEC, qty=1, attr=tv_w_sdec), (VDEC, qty=1, attr=tv_w_vdec), (ATP, qty=1, attr=tv_w_atp) 및 (ADEC, qty=1, attr=tv_w_adec). 또한, VSM/DASS(3530)의 획득 요청은 다음과 같을 수 있다: (PrimaryScaler, qty=1) 및 (PrimarySndOut, qty=1).
이후, 미디어 서버 리소스 매니저(3520)는, 상기 VSM/DASS(3530)과 TV 서비스 시청 파이프라인(3510)으로 할당된 리소스 리스트(AllocateResourceList)을 각각 리턴한다(S3522, S3524).
상기 VSM/DASS(3530)와 TV 서비스 시청 파이프라인(3510)는, 리소스 매니저 클라이언트 엔드 트랜색션(ResourceManagerClientEndTransaction [Handle_vsm], ResourceManagerClientEndTransaction [Handle_watch])을 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3526, S3528).
상기 VSM/DASS(3530)와 TV 서비스 시청 파이프라인(3510)는,, 리소스 매니저 클라이언트 파이프라인 언레지스터(ResourceManagerClientUnregisterPipeline [Handle_vsm], ResourceManagerClientUnregisterPipeline [Handle_watch])를 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3530, S3532).
VSM/DASS(3530)과 TV 서비스 시청 파이프라인(3510)은, 리소스 매니저 클라이언트 제거(ResourceManagerClientDestroy [Handle_vsm], ResourceManagerClientDestroy [Handle_watch])을 각각 미디어 서버 리소스 매니저(3520)로 요청한다(S3534, S3536).
다음으로, 도 36을 참조하여, 미디어 파이프라인 콜 시퀀스를 설명한다. 여기서, 상기 미디어 파이프라인 콜 시퀀스와 관련된 구성은 미디어 파이프라인(3610), 미디어 서버 리소스 매니저(3620), VSM/DASS(3630) 등이 있다.
미디어 파이프라인(3610)과 VSM/DASS(3630)는, 리소스 매니저 클라이언트 생성(ResourceManagerClienCreate [PolicyActionHandler])을 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3602, S3604).
미디어 서버 리소스 매니저(3620)는, 상기 미디어 파이프라인(3610)과 VSM/DASS(3630)의 각 요청에 대하여 리소스 매니저 클라이언트 핸들(ResourceManagerClientHandle)을 각각 리턴한다(S3606, S3608).
미디어 파이프라인(3610)과 VSM/DASS(3630)은, 리소스 매니저 클라이언트 파이프라인 레지스터(ResourceManagerClientRegisterPipeline [media_play], ResourceManagerClientRegisterPipeline [vsm])를 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3610, S3612).
상기 미디어 파이프라인(3610)과 VSM/DASS(3630)는, 리소스 매니저 클라이언트 스타트 트랜색션(ResourceManagerClientStartTransaction [Handle_media], ResourceManagerClientStartTransaction [Handle_vsm])을 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3614, S3616).
그리고, 상기 미디어 파이프라인(3610)과 VSM/DASS(3630)는, 리소스 매니저 클라이언트 획득(ResourceManagerClientAcquire [Handle_media, resourceList], ResourceManagerClientAcquire (Handle_vsm, resourceList))을 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3618, S3620). 여기서, 미디어 파이프라인(3610)의 획득 요청은 다음과 같을 수 있다: (VDEC, qty=1, attr=media_vdec), (ATP, qty=1, attr=media_atp) 및 (ADEC, qty=1, attr=media_adec). 또한, VSM/DASS(3630)의 획득 요청은 다음과 같을 수 있다: (PrimaryScaler, qty=1) 및 (PrimarySndOut, qty=1).
이후, 미디어 서버 리소스 매니저(3620)는, 상기 VSM/DASS(3630)과 미디어 파이프라인(3610)으로 할당된 리소스 리스트(AllocateResourceList)을 각각 리턴한다(S3622, S3624).
상기 VSM/DASS(3630)와 미디어 파이프라인(3610)은, 리소스 매니저 클라이언트 엔드 트랜색션(ResourceManagerClientEndTransaction [Handle_vsm], ResourceManagerClientEndTransaction [Handle_media])을 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3626, S3628).
상기 VSM/DASS(3630)와 미디어 파이프라인(3610)은,, 리소스 매니저 클라이언트 파이프라인 언레지스터(ResourceManagerClientUnregisterPipeline [Handle_vsm], ResourceManagerClientUnregisterPipeline [Handle_media])를 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3630, S3632).
VSM/DASS(3630)과 TV 서비스 시청 파이프라인(3610)은, 리소스 매니저 클라이언트 제거(ResourceManagerClientDestroy [Handle_vsm], ResourceManagerClientDestroy [Handle_media])을 각각 미디어 서버 리소스 매니저(3620)로 요청한다(S3634, S3636).
이하에서는 본 발명에 따른 리소스 매니지먼트에 대해 첨부된 도면을 참조하여 더욱 상세하게 설명하면, 다음과 같다.
TV 미들웨어는 리소스 이용에 관한 플랜을 가진다. 이에 대해서는 이하 도 42 내지 44를 참조하여 상세히 설명한다. 한편, 미디어 서버 내 리소스 매니저는 TV 리소스 매니지먼트가 복잡하여 직접적으로 핸들링하지 않는다. 예컨대, 상기 미디어 서버 내 리소스 매니저는 TV 서비스를 위한 리소스를 할당하나, TV 서비스를 위한 상세한 리소스 매니지먼트는 TV 서비스 처리 모듈 내 리소스 매니저와 폴리시 매니저 등에 의해 핸들링될 수 있다. 이와 관련하여, TV 서비스 시나리오에 따른 리소스 이용에 대해서는 이하 도 45 내지 49를 참조하여 상세하게 설명한다. 다만, 미디어 서버의 리소스 매니저는 TV 리소스 매니지먼트를 핸들하기 위해 전술한 리소스 쉐어링 개념을 지원할 수 있다.
이하 TV 리소스 매니지먼트와 관련하여, TV 서비스 처리부와 미디어 서버 내 리소스 매니저/폴리시 매니저의 처리 방법은 다양하게 이루어질 수 있다.
일 예로, 미디어 서버의 리소스 매니저는 모든 하드웨어 리소스들을 결정하는데, 이때 상기 하드웨어 리소스들에는 디지털 디바이스 내 하드웨어 리소스들뿐만 아니라 상기 디지털 디바이스와 페어링된 다른 디바이스의 하드웨어 리소스들도 포함할 수 있다. 상기 리소스 매니저는 또한, 특정 TV 서비스 시나리오에 이용되는 리소스들의 종류에 대해서는 알고 있다. 이는 리소스 매니저가 TV 서비스뿐만 아니라 전체적인 디바이스 내 서비스 또는 애플리케이션 등뿐만 아니라 사용자 등에 의해 요청 등에 따른 적절한 리소스 할당을 위함이다.
예를 들어, TV 서비스 처리부로 녹화 요청이 수신되면, 상기 TV 서비스 처리부는 상기 요청된 녹화 동작 수행을 위하여 리소스들 할당을 미디어 서버의 리소스 매니저/폴리시 매니저로 요청한다. 상기 리소스 매니저/폴리시 매니저는 TV 파이프라인의 상태를 파악하고, 상기 상태에 기초하여 필요한 리소스들을 결정한다. 이때, 상기 TV 파이프라인의 상태는 예컨대, 시청에서 녹화로 체인지 된다. 그리고, 상기 리소스 매니저/폴리시 매니저는 상기 결정된 리소스들에 기초하여 할당된 리소스 정보를 다시 TV 서비스 처리부로 리턴 한다.
다른 예로, 미디어 서버 내 리소스 매니저는 상술한 예시와 달리, TV와 미디어를 위한 이용 가능한 리소스들을 단지 리턴하기만 할 수 있다. 따라서, TV 서비스와 관련하여, TV 서비스 처리부는 TV 파이프라인의 상태를 기억하고, 그 스스로 필요한 TV 리소스들을 결정하여야 한다. 즉, 이전 예시가, 상기 리소스 매니저가 TV 서비스에 따라 단지 리소스 요청을 하면, 상기 리소스 매니저에서 알아서 상기 TV 서비스에 필요한 리소스를 결정하고, 그를 할당하던 방식임에 반해, 본 예시는 TV 서비스에 따라 TV 서비스에서 필요한 리소스들을 결정하여, 상기 결정된 리소스들의 할당을 리소스 매니저로 요청하고, 할당받는 방식이다. 다시 말해, 본 예시에서, 리소스 매니저는 리소스 할당과 릴리즈를 위한 가부만 핸들링할 수 있다.
예컨대, TV 서비스 처리부가 시청 중에 녹화 요청이 수신되면, TV 서비스 처리부에서 TV 파이프라인 상태를 파악하고 그에 따라 필요한 리소스들을 결정한다. 그리고, 상기 결정된 리소스들의 할당을 미디어 서버 내 리소스 매니저/폴리시 매니저로 요청하고, 상기 리소스 매니저/폴리시 매니저는 상기 요청에 대응하여 요청된 리소스들을 할당하고 할당된 리소스 정보를 상기 TV 서비스 처리부로 리턴하는 것이다.
상기한 각 예시는 각각 장단점이 있으며, 해당 디지털 디바이스의 특성에 따라 적절히 결정된 방식을 이용하면 족하다. 한편, 도시되진 않았으나, 양자를 적절히 조합한 방식을 이용할 수도 있다. 또한, 서비스 단위, 애플리케이션 단위, TV 서비스 처리부나 미디어 서버 등의 부담, 로드(load) 등 상태 등에 기초하여 어느 하나의 방식을 이용하거나 양자의 방식을 순차로 결정하여 적용하거나 다양한 형태로 조합하여 이용할 수도 있다.
TV 리소스 매니저는 TV 파이프라인 매니저로 리소스 쉐어링 정보를 제공한다. 이때, 전술한 리소스 컨피규레이션 파일(resource configuration file)이 이용될 수 있다. 한편, TV 리소스 매니저는 리소스들과 TV 파이프라인 매니저 사이의 링키지 정보(Linkage Information)를 제공할 수 있다. 또한, 상기 TV 리소스 매니저는 TV 폴리시 매니저로 모든 리소스 정보를 제공하고, 미디어 서버와도 인터페이싱한다. 즉, TV 리소스 매니저는 리얼 리소스들을 포함한 미디어 서버로부터 리소스들을 획득하고, 또 상기 미디어 서버로 리소스들을 다시 리턴할 수도 있다.
상기 리소스 컨피규레이션 파일은, 리소스들을 어떻게 사용할 것인지에 대한 TV 서비스의 마스터 플랜과 같은 것으로, TV 서비스에서 TV 고유 기능 구현을 위해 필요한 리소스들을 어떻게 사용할 것인지에 대한 설계도와 같은 것이다. 이는 테이블 형태로 표현 또는 구현되어 미리 저장될 수도 있다. 이러한 리소스 컨피규레이션 파일의 역할은 예컨대, TV 서비스가 어떤 리소스를 이용하는지 표현하고, 리소스 쉐어링 개념에 이용 가능하며, 디바이스 또는 파이프라인의 상태와 관계없이 리소스 쉐어링 개념을 이용할 수도 있게 하는 등의 역할을 한다. 예컨대, 서비스에 대한 리소스 컨피규레이션 파일을 미리 알고 있으며, 서비스(들) 요청에 대해 적절히 리소스 쉐어링 개념을 이용하여 한정된 리소스의 효율적인 이용이 가능하게 된다.
한편, 여기서, 리소스 컨피규레이션 파일은 예를 들어, TV 서비스와 관련하여, 도시하고 설명되나, 본 발명은 이에 한정되는 것은 아니다. 다시 말해, 리소스 컨피규레이션 파일은 미리 저장될 수도 있고 페어링된 외부 기기 또는/및 외부 서버 등으로부터 다운로드 받아 이용 가능하며, 상기 TV 서비스 외에 미디어 서비스, 애플리케이션 등을 동작 수행을 위해 필요한 경우 정의하고 이용할 수 있다. 다만, 이하에서는 리소스 컨피규레이션이 다소 복잡한 TV 서비스를 예로 하여 설명한다.
이하 첨부된 도면을 참조하여 리소스 컨피규레이션 파일에 대해 더욱 상세하게 설명하면, 다음과 같다.
도 37 내지 41은 본 발명의 일 실시 예에 따른 리소스 컨피규레이션 파일을 설명하기 위해 도시한 도면이다.
이하에서 상기 리소스 컨피규레이션 파일의 이해를 돕기 위해 필요한 표현에 대해 간략히 설명하면, 표 1과 같다.
표 1
표현 의미 또는 정의
+ 쉐어링 가능(다만, 동일 용도로 쉐어링이 불가능할 수 있다.)
w 시청 용도
r 녹화 용도
c 캡쳐 용도
t 전송 용도
ts 타임쉬프트 용도
sw 스위칭 용도
x 원래 용도와 다른 용도
A | B (ex, 리소스) A가 이용 가능하면 상기 A를 사용, 그렇지 않으면 B 사용
상기 표 1에 기초하면, 다음과 같은 식으로 표현 가능하다. 예를 들어, "+x"는 자기와 동일한 용도 이외의 다른 모든 용도와 쉐어링 가능함을 표현할 수 있고, "+w"는 시청 용도와 쉐어링 가능함을 표현할 수 있고, "+c+w"는 캡쳐링 용도 또는 시청 용도와 쉐어링 가능함을 표현할 수 있다.
도 37은 싱글 튜너 모델에 관한 것으로 특히, 도 37a는 시청 동작을 그리고 도 37b는 상기 도 37a의 시청 동작 중에 녹화 동작에 대한 리소스 컨피규레이션 파일에 대해 도시한 것이다.
먼저, 도 37a을 참조하여, 시청 동작 컨피규레이션 파일을 설명한다.
시청 동작을 위한 리소스들은 예를 들어, ADTU(튜너), SDEC(시스템 디코더), VDEC(비디오 디코더) 및 ADEC(오디오 디코더)가 필요하며, 도시된 바와 같이 상기 순으로 TV 파이프라인 내에서 리소스가 어레인지(resource arrangement)될 수 있다.
여기서, 시청 동작 컨피규레이션 파일은 도시된 바와 같이 구성될 수 있다. 리소스 ADTU0는 현재 시청 용도로 이용되며, 파이프라인ID는 1이고, 쉐어러블 관점에서 [+x]로 자기와 동일한 용도 이외의 다른 용도와 쉐어링 가능함을 알 수 있다. 리소스 SDEC0는 현재 시청 용도로 이용되며, 파이프라인ID는 1이고, 쉐어러블 관점에서 [+c+t]로 켭쳐링 용도 또는 전송 용도와 쉐어링 가능함을 알 수 있다. 리소스 VDEC0는 현재 시청 용도로 이용되며, 파이프라인ID는 1이고, 쉐어러블 관점에서 [+c+t]로 켭쳐링 용도 또는 전송 용도와 쉐어링 가능함을 알 수 있다. 리소스 ADEC0는 현재 시청 용도로 이용되며, 파이프라인ID는 1이고, 쉐어러블 관점에서 [+t]로 전송 용도와 쉐어링 가능함을 알 수 있다.
도 37b는 상기 도 37a와 같이, 시청 중에 사용자가 녹화 요청을 하는 경우이다. 이하 녹화 동작 컨피규레이션 파일을 설명한다.
녹화 동작을 위한 리소스들은 예를 들어, ADTU와 SDEC가 필요하며, 이는 예를 들어, 전술한 도 37a에 시청 동작을 위한 리소스들에 포함되어 있다.
녹화 동작 컨피규레이션 파일은 도시된 바와 같이, 구성될 수 있다. 여기서, 상기 녹화 동작 컨피규레이션 파일은 예컨대, 전술한 도 37a이 시청 동작 컨피규레이션 파일을 이용할 수 있다.
TV 리소스 매니저는 TV 서비스에 의해 현재 리소스 ADTU가 획득되었는지 체크하고, 만약 상기 리소스 ADTU가 이미 획득되었으며, 그 이용 및 쉐어링이 가능한지 체크한다. 따라서, 도 37a에 도시된 리소스 ADTU0의 컨피규레이션 파일을 참조하면, 리소스 ADTU는 쉐어링 가능하므로, 리소스 ADTU는 미디어 서버의 리소스 매니저로 리소스 획득 요청을 하지 않더라도 쉐어 가능하다. 따라서, 리소스 ADTU0의 컨피규레이션 파일은 현재 시청 용도와 녹화 용도로 이용되며, 파이프라인ID는 시청 용도에 대해서는 1 그리고 녹화 용도에 대해서는 2이고, 쉐어러블 관점에서 둘 다 [+x]로 자기와 동일한 용도 이외의 다른 용도와 쉐어링 가능으로 정의될 수 있다. 따라서, 상기 리소스 ADTU0는 도 37a의 시청 용도가 아닌 다른 용도 즉, 녹화 용도로 쉐어링 가능해진다. 다만, TV 미들웨어는 리소스 SDEC의 쉐어링 가부에 대해 요청하지 않기 때문에, 상기 리소스 SDEC는 미디어 서버의 리소스 매니저로 리소스 획득 요청을 하여야 한다. 또한, 도 37a를 참조하면, 리소스 SDEC는 캡쳐링 또는 전송 용도로만 쉐어 가능하다고 정의되어 있기 때문에 별도의 리소스 획득이 필요하다. 따라서, 도 37b의 컨피규레이션 파일을 참조하면, 리소스 SDEC0는 상술한 도 37a와 동일하고, 새롭게 리소스 SDEC1에 대해 다음과 같이 정의된다. 리소스 SDEC1은 현재 녹화 용도로 이용되며, 파이프라인ID는 2가 된다. 다만, 리소스 SDEC1은 쉐어러블 관점에서 특별히 정의하지 않을 수 있다.
도 38은 역시 싱글 튜너 모델에 관한 것이나 도 37과 달리, 도 38a는 DTV 시청 및 DVR 녹화(HQ) 동작을 그리고 도 38b는 상기 도 38a의 동작 중에 인풋 소스가 HDMI로 변경되어 HDD 시청 동작에 대한 리소스 컨피규레이션 파일에 대해 도시한 것이다.
도 38a는, DTV 시청 및 DVR 녹화(HQ) 동작 컨피규레이션 파일에 관한 것으로, 이는 도 37b와 동일하다. 따라서, 이에 대한 상세한 설명은 전술한 내용을 참조하고 여기서 중복하여 설명하지 않는다.
도 38b는 상기 도 38a에서 인풋 소스가 HDMI로 변경된 경우에 대한 것으로 이때, 상기 동작을 위하여 필요한 리소스들은 SDEC, VDEC 및 ADEC가 요구된다. 따라서, 도 38b의 동작을 위하여, 리소스 SDEC이 리소스 컨플릭트가 발생한다. 따라서, 이 경우, DTV 시청 파이프라인은 상기 SDEC 리소스를 릴리즈할 수 있는지 문의를 받는다. 만약, 리소스 SDEC0가 릴리즈되면, DTV 시청은 더 이상 동작이 의미가 없어진다. 이에 따라, DTV 시청 동작과 관련된 모든 리소스들은 시청 용도에서 제거된다. 해당 리소스들은 이용 불가로 전부 릴리즈될 수 있다. 따라서, 리소스들 SDEC, VDEC 및 ADEC을 한꺼번에 획득 가능해 진다.
도 38b의 HDD 시청 동작을 위한 컨피규레이션 파일 구성을 설명한다. 여기서, 상기 도 38a에서 DTV 시청 동작은 파이프라인 또는 상기 시청과 관련된 리소스들이 모두 릴리즈되지만, 여전히 DVR 녹화 동작을 위한 파이프라인과 관련 리소스들은 유지된다. 따라서, 상기 DTV 시청 동작을 위해 획득되었고 DVR 녹화 동작을 위해 쉐어링되었던 리소스 ADTU0는 이제 DVR 녹화 동작 전용으로 이용된다. 정리하면, 리소스 ADTU0는 현재 녹화 용도로 이용되며, 파이프라인ID는 2이고, 쉐어러블 관점은 [+x]이다. 리소스 SDEC1은 현재 녹화 용도로 이용되며, 파이프라인ID는 2이다. 리소스 SDEC0은 현재 HDD 시청 용도로 이용되며, 파이프라인ID는 1(DTV 시청 파이프라인 제거에 따라 ID1이 DTV 시청 파이프라인에 대한 것이 아님)이고, 쉐어러블 관점은 [+c+t]이다. 리소스 VDEC0는 현재 HDD 시청 용도로 이용되며, 파이프라인ID는 1이고, 쉐어러블 관점에서 [+c+t]이다. 리소스 ADEC0는 현재 HDD 시청 용도로 이용되며, 파이프라인ID는 1이고, 쉐어러블 관점에서 [+t]이다.
도 39a는 전술한 도 38b와 동일한 상태의 컨피규레이션 파일이고, 도 39b는 다시 도 38a와 같이, 인풋 소스가 HDMI에서 DTV로 변경되어 DTV 시청 동작이 요청된 경우이다.
따라서, 이 경우, 전술한 바와 같이, 다시 리소스 SDEC0의 리소스 컨플릭트가 발생하고, HDD 시청 파이프라인은 리소스 릴리즈 요청을 받는다. 이때, 상기 리소스 SDEC0가 릴리즈되면, HDD 시청은 더 이상 무의미해지고, 상기 HDD 시청과 관련된 모든 리소스는 시청 용도에서 제거되어 릴리즈된다. 한편, HDD 시청과 달리, DTV 시청 용도에서는 리소스 ADTU가 필요한데, 이때 상기 ADTU는 시청 용도 이외에는 모든 용도와 쉐어 가능함을 알 수 있다. 따라서, 기 이용 중인 용도가 DVR 녹화 용도로 리소스 ADTU가 이용되고 있으므로, 본 DTV 시청 용도와 쉐어 가능하다. 그러므로, 별도로 리소스 ADTU 획득을 위해 미디어 서버의 리소스 매니저로 리소스 획득 요청을 하지 않아도 기존에 DVR 녹화 용도로 획득된 리소스 ADTU0를 쉐어하면 족하다. 한편, 녹화 용도 리소스 SDEC1은 쉐어가 불가능하므로, 리소스 SDEC의 획득을 위해 리소스 매니저로 요청하여 이용하여야 하며, 이때 VDEC와 ADEC도 이미 HDD 시청 용도 파이프라인 및 리소스가 릴리즈되어 전술한 바와 같이, 리소스 매니저로부터 리소스를 획득하여야 한다.
따라서, 컨피규레이션 파일 구성은 전술한 도 38a와 동일해진다.
도 40a는, 전술한 도 37a와 같은 DTV 시청 동작에 대한 것이다. 따라서, 이에 대한 상세한 설명은 전술한 도 37a의 설명을 원용하고 여기서 상세한 설명은 생략한다.
도 40b는, 전술한 도 40a에서 캡쳐 동작 요청이 수신되는 경우에 컨피규레이션 파일 구성에 대한 것이다.
캡쳐 동작과 관련하여, 필요한 리소스들로는 예를 들어, ADTU, SDEC, VDEC 및 세컨더리 스케일러가 요구된다. 여기서, 도 40a와 대비하면, 상기 리소스들 중 ADTU, SDEC, VDEC가 중복된다. 따라서, 해당 리소스들에 대해서는 쉐어러블 여부를 검토할 필요가 있다. 예컨대, TV 리소스 매니저는 리소스 ADTU, SDEC 및 VDEC가 TV 서비스에 의해 현재 획득되었는지 체크하고, 만약 해당 리소스들이 획득되었다면 상기 리소스들이 시청을 위해 이용 중인지 체크한다. 이 경우, 해당 리소스들은 별도로 리소스 매니저로 리소스 획득 요청 없이, 쉐어 가능하다. 다만, 세컨더리 스케일러의 경우에는 리소스 매니저로 리소스 획득 요청을 하여야 한다.
이에 따라, 도 40b를 참조하면, DTV 시청 동작과 캡쳐 동작을 위한 컨피규레이션 파일은 다음과 같이 구성된다. 리소스 ADTU0는 현재 시청 용도와 캡쳐 용도로 이용되며, 상기 시청 용도에 대한 파이프라인ID는 1이고, 상기 캡쳐 용도에 대한 파이프라인ID는 2이고, 쉐어러블 관점은 둘 다 [+x]이다. 리소스 SDEC0은 상기 리소스 ADTU와 동일하나 다만 쉐어러블 관점만, 시청 용도의 경우에는 [+c+t]이고, 캡쳐 용도에서는 [+w]이다. 또한, 리소스 VDEC0의 경우는 전술한 SDEC0와 동일하다. 그 밖에, 리소스 ADEC0는 시청 용도로만 이용되며 파이프라인ID는 1이고, 쉐어러블 관점은 [+t]이며, 리소스 세컨더리 스케일러는 캡쳐 용도로만 이용되고, 파이프라인ID는 2이며 쉐어러블 관점은 특별히 정의되지 않을 수 있다.
도 41a는 전술한 도 40b와 동일한바, 그를 원용하고 여기서 상세한 설명은 생략한다. 도 41b는 이때, DTV에서 출력을 SCART로 전송하는 경우이다. 도 41b를 위하여, 필요한 리소스들은 예를 들어, ADTU, SDEC, VDEC 및 세컨더리 스케일러이다.
기본적으로, 도 41a와 41b를 대비하면, 리소스 ADEC를 제외하고는 모두 중복이 된다. 다만, 여기서 리소스들 중 리소스 ADTU, SDEC, VDEC는 도 41a의 캡쳐 동작을 종료하고, 전송 동작으로 변경하면 되므로, 캡쳐를 대신하여 전술한 바와 같이, 쉐어러블하다. 다만, 세컨더리 스케일러는 쉐어러블이 불가하므로, 해당 리소스가 리소스 컨플릭트가 발생한다. 즉, 리소스 컨플릭트 관점에서 세컨더리 스케일러는 상기 ADTU, SDEC, VDEC와는 다르다. 따라서, 현재 파이프라인은 릴리즈 요청을 받는다. 만약 상기 리소스 세컨더리 스케일러가 릴리즈되면, 캡쳐는 더 이상 무의미해진다. 따라서, 캡쳐와 관련된 모든 리소스들이 릴리즈된다. 이후, ADTU, SDEC, VDEC 및 ADEC에 TV 서비스 처리부에서 아직 획득 중인지 체크한다. 만약 상기 리소스들이 아직 획득 중이라면, DTV 시청을 위한 것인지 판단한다. 따라서, 전송 동작을 위해, 상기 획득 중인 리소스들과 쉐어러블 관점을 비교하여 쉐어한다. 다만, 상기 리소스들이 만약 DTV 시청 동작을 위해서도 미획득 상태이거나 릴리즈되었다면, 전송 동작을 위하여 해당 리소스들의 획득을 리소스 매니저로 요청하여야 한다.
따라서, TV 리소스 매니저는 DTV 시청 동작과 SCART 전송 동작을 위한 컨피규레이션 파일을 도 41b와 같이 구성할 수 있다.
이하에서는 전술한 컨피규레이션 파일 구성 방식과 리소스 쉐어링 관점을 참고하여, 다양한 동작에 대한 리소스 어레인지먼트들에 대해 간략하게 살펴본다. 한편, 본 명세서에 도시되지 않거나 설명되지 않은 구성 방식, 리소스 어레인지먼트 등도 본 명세서 설명하는 원리를 이용하여 구성할 수 있는바, 본 발명의 권리범위에 포함된다.
도 42 내지 49는 본 발명의 일 실시 예에 따른 동작(들)을 위해 구성한 리소스 어레인지먼트를 설명하기 위해 도시한 도면이다.
이하 도 42 내지 49는 전술한 리소스 컨피규레이션 파일 구성 등 내용을 참고하여 중복되는 내용에 대한 상세 설명은 생략하고, 상이한 점을 위주로 간략하게 설명한다.
도 42는 DTV 시청과 DVR 녹화 동작을 동시에 수행하는 경우에 리소스 쉐어링 개념을 이용한 리소스 어레인지먼트를 도시한 것으로 특히, 도 42a와 42b는 HQ에 대한 것이고, 도 42c 내지 42e는 LQ에 대한 것이다.
먼저, 도 42a는 DTV 시청과 DVR 녹화(HQ) 동작 수행을 위한 리소스들 중 ADTU만을 리소스 쉐어한 경우에 리소스 어레인지먼트이다. 여기서, DTV 시청 동작은, ADTU와 DMX0(디멀티플렉서)를 거쳐 비디오 데이터는 VDEC0와 프라이머리 스케일러(Primary Scaler)를 거쳐 패널을 통해 출력되고, 오디오 데이터는 ADEC0를 거쳐 SPK(스피커)를 통해 출력된다. 그리고, DVR 녹화 동작은, 쉐어된 ADTU로부터 DM1을 거쳐 스토리지(Storage)로 전송되어 저장된다.
반면, 도 42b는 전술한 도 42a와 달리, DMX도 함께 쉐어한 경우를 예시한 것이다. 이 경우, 상기 DTV 시청 동작의 리소스 어레인지먼트는 도 42a와 동일하나, 상기 DVR 녹화 동작은 이전과 달리, DMX1을 거치지 않고 상기 DTV 시청을 위해 획득된 리소스 DMX0에 의해 디멀티플렉싱되어 스토리지로 바로 저장된다.
상술한 바와 같이, 리소스가 쉐어되면, 해당 서비스 동작을 위하여 별도로 미디어 서버의 리소스 매니저와 통신하여 리소스 할당 등을 받을 필요가 없어, 리소스를 더욱 효율적으로 이용할 수 있다.
도 42c는 예를 들어, 두 개의 리소스가 쉐어된다. 이때, 쉐어되는 2개의 리소스들은 ADTU와 MUX(멀티플렉서)이다. DTV 시청 동작은 전술한 도 42a 내지 42b와 동일하다. 다만, DVR 녹화 동작을 위한 리소스 어레인지먼트는 전술한 도 42a 내지 42b와 상이하다. 예컨대, 도 42c에서는 DVR 녹화를 위한 신호가 DMX1을 통해 비디오 데이터와 오디오 데이터로 디멀티플렉싱되고, 비디오 데이터는 VDEC1, 세컨더리 스케일러와 VENC를 거쳐 MUX로 전달되고, 오디오 데이터는 ADEC1, AENC를 거쳐 상기 MUX로 전달되어 상기 VENC를 거친 비디오 데이터와 먹싱되어 스토리지에 저장된다.
도 42d는, 전술한 도 42c와 대동소이하나, 단지 상기 도 42c에 비하여 ADTU 이외에 DMX까지 쉐어하는 것이 상이하다.
도 42e는, 전술한 도 42c 보다 더욱 많은 리소스가 쉐어된다. 예컨대, DTV 시청 동작과 DVR 녹화 동작을 위해, ADTU와 DMX0를 쉐어하는데 다시 말해, DTV 시청을 위한 신호와 DVR 녹화 동작을 위한 신호를 쉐어된 리소스를 통해 처리하고, DMX0에서 DTV 시청 동작과 DVR 녹화 동작을 위한 비디오 데이터와 오디오 데이터로 분리하고, VDEC와 ADEC를 최소로 이용한다. 즉, DTV 시청 동작을 위한 비디오 데이터는 VDEC0를 거쳐 프라이머리 스케일러를 거쳐 패널로 전달되고, DVR 녹화 동작을 위한 비디오 데이터는 VDEC0을 거쳐 세컨더리 스케일러, VENC를 거쳐 MUX로 전달된다. 그리고, DTV 시청 동작을 위한 오디오 데이터는 ADEC0를 거쳐 SPK로 전달되고, DVR 녹화 동작을 위한 오디오 데이터는 AENC를 거쳐 MUX로 전달되어, 상기 VENC를 거쳐 MUX로 전달된 비디오 데이터와 먹싱되어 스토리지로 전달되어 저장된다.
도 43은 DTV 시청 동작과 세컨드 TV 동작을 동시에 수행하는 경우에 리소스 어레인지먼트를 도시한 것이다.
도 43a는, DTV 시청 동작과 세컨드 TV 동작을 위하여 ADTU, DMX 및 VDEC와 ADEC, 그리고 MUX가 쉐어되었다. DTV 시청 동작과 세컨드 TV 동작을 위하여, 상기 두 동작을 위한 신호는 쉐어된 ADTU 및 DMX0를 거쳐 모든 비디오 데이터는 VDEC0로 전달되고, 모든 오디오 데이터는 ADEC0로 전달된다. VDEC0에서 DTV 시청 동작을 위한 비디오 데이터는 프라이머리 스케일러 및 패널을 거치고, 세컨드 TV 동작을 위한 비디오 데이터는 세컨더리 스케일러 및 VENC를 거쳐 MUX로 전달된다. ADEC0에서 DTV 시청 동작을 위한 오디오 데이터는 SPK로 바로 출력되고, 세컨드 TV 동작을 위한 오디오 데이터는 AENC를 거쳐 MUX로 전달되고, MUX에서 상기 VENC를 거쳐 전달된 비디오 데이터와 먹싱되어 스토리지로 전달된다.
이에 반해, 도 43b는, 도 43a에서 VDEC와 ADEC는 쉐어하지 않은 것으로, DTV 시청 동작을 위하여 VDEC0과 ADEC0이 이용되고, 세컨드 TV 동작을 위하여 VDEC1과 ADEC1이 이용되는 것이 상이하다.
또한, 도 43c는, 도 43b에서 DMX도 쉐어하지 않은 경우로, 이 경우 쉐어된 ADTU를 거쳐 DTV 시청 동작을 위한 신호는 DMX0를 거쳐 처리되고, 세컨드 TV 동작을 위한 신호는 DMX1을 거쳐 처리되는 것이 상이하다.
도 44는 DTV 시청 동작과 SCART 출력을 동시에 수행하기 위해 도시한 리소스 어레인지먼트에 관한 것이다.
전체적인 내용은 전술한 도 43과 대동소이하며, 단지 세컨더리 TV 동작 처리를 대신하여 SCART 출력이 DTV 시청 동작과 함께 수행되는 것만 상이하고, 상기 SCART 출력을 위한 리소스가 상이하다.
전반적으로, 도 44a는 ADTU, DMX에 이어 VDEC과 ADEC을 쉐어하는 것이 특징이며, 도 44b는 도 44a에 비하여 VDEC와 ADEC는 쉐어하지 않는 것이 특징이다. 마지막으로, 도 44c는, 상기 도 44b에 비하여 DMX까지 쉐어하지 않은 것이 특징이다.
전술한 도 42 내지 44가 두 가지 동작의 동시 수행에 대한 리소스 어레인지 먼트에 대한 것이라면, 도 45 내지 49는 예를 들어, TV 시나리오에 따라 리소스 어레인지먼트가 어떻게 변화되는지 설명한다.
도 45를 참조하면, 도 45a는 DTV 시청 동작을 위한 리소스 어레인지먼트이고, 도 45b는 DVR 녹화 요청에 따라 상기 DTV 시청 동작과 함께 DVR 녹화 동작을 수행하기 위한 리소스 어레인지먼트이고, 도 45c는 인풋 소스 즉, HDMI 입력으로 체인지됨에 따라 DTV 시청 동작은 컨플릭트로 제거되고, DVR 녹화 동작과 HDMI 입력 동작을 처리하기 위한 리소스 어레인지먼트이고, 마지막으로 도 45d는 상기 도 45c에서 DVR 녹화 동작이 종료하고, HDMI 입력을 통한 HDMI 인풋을 시청하기 위해 구성된 리소스 어레인지먼트를 예시한 것이다. 여기서, 도 45a 내지 45d는 일응 순차로 TV 시나리오의 변경에 따른 리소스 어레인지먼트 구성의 변화를 도시한 것인데, 그 역도 가능하다.
먼저, 도 45a를 참조하여, DTV 시청을 위한 리소스 어레인지먼트는, ADTU, DMX0를 거쳐 비디오 데이터는 VDEC0과 프라이머리 스케일러를 거쳐 패널로 출력되고, 오디오 데이터는 ADEC0를 거쳐 SPK로 출력된다.
도 45a에서 DTV 시청 동작 수행 중에 DVR 녹화 동작 수행 요청이 수신되면, 전술한 바와 같이, 리소스 컨플릭트 여부, 리소스의 획득 여부 등을 고려하여 리소스 쉐어링 개념에 기초하여 두 동작의 동시 수행 여부가 결정된다. 그리고, 도시된 바와 같이, 두 동작을 동시 수행 가능한 경우에 리소스 어레인지먼트는 도시된 바와 같다. 상기 두 동작을 위해서는 ADTU의 쉐어로 족하다. 따라서, 상기 쉐어된 ADTU를 거쳐 DMX0 이후는 전술한 도 45a와 동일하다. 다만, DVR 녹화 동작을 위해서는 상기 ADTU를 거쳐 DMX1을 통하여 스토리지에 저장된다.
한편, 상기 도 45b 과정에서 DTV와 HDMI 사이에 인풋 소스가 변경되면, 도 45c와 같이, 리소스가 어레인지먼트된다. 이때, 상기 DTV와 HDMI는 인풋 소스가 변경되어 DTV 시청 동작을 위한 리소스들은 릴리즈될 수 있다. 그리고, HDMI 인풋 소스 체인지 동작과 DVR 녹화 동작 간에 리소스 컨플릭트 등을 고려하여 양 동작의 동시 수행이 결정한다. 도시된 바와 같이, 양자는 동시 수행 가능하다. 다만, 도 45b에서 ADTU는 DTV 시청 동작과 쉐어되었으므로, 이를 DVR 동작을 위해 이용하고, 상기 DTV 시청 동작을 위한 리소스 릴리즈에 따라 미디어 서버의 리소스 매니저를 통해 ADTU를 다시 획득하여야 할 수 있다. 한편, HDMI는 HDMI Rx(HDMI 수신부)를 거쳐 비디오 데이터는 프라이머리 스케일러를 거쳐 패널을 통해 출력되고, 오디오 데이터는 ADEC0를 거쳐 SPK를 통해 출력된다. 이때, 상기에서, 프라이머리 스케일러, 패널, ADEC0, SPK 등의 리소스들은 도 45b에서 DTV 시청 동작을 위한 리소스와 동일하나, 상술한 바와 같이 이미 리소스 릴리즈가 이루어졌으므로, HDMI 인풋 동작을 위하여 다시 미디어 서버의 리소스 매니저로부터 할당받은 리소스이다.
이후, DVR 녹화 중단 또는 종료가 되면, HDMI 시청만을 위한 리소스 어레인지먼트가 도 45d와 같이 구성된다.
도 46과 47은 전술한 도 45와 대동소이하다. 다만, 일부 리소스가 전술한 도 42 내지 44에서와 같이, 어떤 리소스를 쉐어하여 리소스 어레인지먼트를 구성하느냐의 차이일 뿐이다. 일 예로, 도 45b와 46b의 차이는, 도 42a와 도 42c의 차이와 동일하다.
한편, 도 47a는 캠을 가진 DTV 시청의 경우로, ADTU는 쉐어되고, CI(Common Interface), DMX0, VDEC, ADEC 등을 거쳐 시청 동작이 이루어지고, 한편, 상기 시청 동작을 위한 시그널링 정보는 ADTU를 거쳐 DMX2를 통해 수신된다.
도 47b 내지 47d는, 상기 도 47a의 차이 이외에는 전술한 도 46b 내지 46d와 대동소이하다.
전술한 도 45 내지 47이 싱글 튜너에서 동작 구현을 위한 리소스 어레인지먼트 구성 방식을 기술한 것이라면, 도 48 내지 49는 멀티-튜너에서 동작 구현을 위한 리소스 어레인지먼트 구성 방식을 기술한 것이다.
도 48a는 DTV 시청 동작을 위한 것으로, DTU, DMX0를 거쳐 비디오 데이터는 VDEC0, 프라이머리 스케일러, 패널로 출력되고, 오디오 데이터는 ADEC0, SPK로 출력된다.
도 48b는 DTV 시청 동작 중에 DVR 녹화 동작 수행 요청에 따른 것으로, 멀티-튜너이므로, DTV 시청 동작은 전술한 도 48a와 리소스 어레인지먼트 변경이 없고, DVR 녹화 동작을 위해 별도의 DTU(튜너)가 할당된 것이 상술한 내용과 상이하다.
도 48c는, DTV에서 HDMI로 인풋 소스가 변경된 경우로, 이 경우, 전술한 바와는 달리, DVR 녹화 동작을 위하여 별도의 튜너 DTU가 기 할당되었으므로, 간편하게 DTV 시청을 위한 리소스들은 모두 릴리즈하면 되고, 별도로 DVR 녹화 동작을 위한 리소스 매니저와의 컨택 또는 커뮤니케이션이 불필요하다. 또한, HDMI 동작을 위한 파이프라인의 리소스 어레인지먼트 구성하면 족하다.
도 48d는, 도 48b에서 DTV와 ATV 사이에 체인지가 발생한 경우이다. 즉, 도 48b가 DTV 시청 동작과 DVR 녹화 동작의 동시 수행에 관한 리소스 어레인지먼트를 도시한 것이라면, 도 48d는 ATV 시청 동작과 DVR 녹화 동작을 동시에 수행하기 위해 구성한 리소스 어레인지먼트를 도시한 것이다. 이 경우, 전술한 바와 같이, 도 48은 멀티-튜너를 가정하였으므로, 여전히 DVR 녹화 동작을 위한 리소스 어레인지먼트는 전혀 영향을 받지 않는다. 다만, DTV 시청 동작을 위한 리소스들은 모두 릴리즈되고, 단지 ATV 시청 동작 위한 리소스 어레인지먼트만을 구성하면 족하다.
도 48c에서 녹화 중단 또는 종료가 이루어지면, 도 48e와 같이 리소스 어레인지먼트가 구성된다. 그러나, 도 48d에서 녹화 중단 또는 중단이 이루어지면, 도 48f와 같이 리소스 어레인지먼트가 구성된다. 이는 전술한 도 45 내지 47을 참고하면, 충분히 설명된다.
한편, 도 49는 전술한 도 48과 대동소이하나, 단지 각 동작 또는 복수의 동작을 동시에 수행하는 경우에 필요한 리소스들 중 쉐어되는 리소스를 조금 다르게 하여 리소스 어레인지먼트를 구현한 것일 뿐이다. 따라서, 전반적인 내용은 전술한 도 48과 대동소이한바, 그를 준용하고 상세한 설명은 생략한다.
도 50은 본 발명의 일 실시 예에 따른 서비스 재구조화(service restructure)를 설명하기 위해 도시한 도면이다.
도 50은 특히, TV 서비스의 재구조화에 관한 것으로, 이는 종래 방송 수신기의 TV 서비스 구조로는 웹OS 기반의 디지털 디바이스에서 TV 서비스의 처리가 원활하게 이루어지기 힘들기 때문이다. 종래 방송 수신기는 FSM(Finite State Machine)을 구비하여 시스템 기반의 스테이트 머신인 MRE를 사용한다. 다만, MRE를 사용함에 있어서, 상기 FSM에 따른 불편함이 있다. 또한, 종래 방송 수신기는 리소스 패쓰(resource path)가 고정되어 유연성 또는 확장성이 떨어진다. 그 밖에, 종래 방송 수신기는 UX 시나리오와 리소스 제한 시나리오 간의 차이를 구분하지 못한다. 예를 들어, 리소스 제한이 사라졌음에도 불구하고, 종래 방송 수신기는 리소스 제한 시나리오를 제거하기 어렵다. 따라서, 본 명세서에서는 웹OS 플랫폼상에서 TV 서비스가 원활하게 동작되도록 하기 위해 다음과 같이 TV 서비스를 재구조화하고자 한다.
먼저, 종래 방송 수신기에서 사용하는 MRE를 사용하지 않는다. 즉, 센트럴라이즈드 스테이트 머신을 사용하지 않는다. 이를 위해, 도 51과 같이, TV 서비스를 재구조화할 수 있다. 예컨대, 웹OS 플랫폼상에서, TV 파이프라인 매니저/TV 파이프라인은, 인풋 체인지가 있거나 특정 기능을 수행할 때, 경로를 설정한다. 또한, TV 리소스 매니저는 각 스테이트에서 리소스 할당을 하고, 패쓰 매니저는 패쓰 정보를 제공한다. 또한, TV 서비스는 웹OS로 포팅한다. 이는 도 50과 같이 재구조화하여 시스템 기반의 가상의 파이프라인(Pseudo Pipeline)을 이용하는 것이다. 그 밖에, 웹OS 플랫폼상에서는, UX 시나리오와 리소스 제한 시나리오를 분리한다. 다시 말해, 리소스 제한 시나리오는 TV 폴리시 매니저 또는 TV 파이프라인 매니저에서 담당하도록 한다.
도 50을 참조하면, 하드웨어 리소스 매니저는, 로드 요청(Load tv://)을 수신하고, 미디어 서버는 하드웨어 리소스 컨피규레이션 파일을 정의한다. 상기 하드웨어 리소스 매니저는 상기 정의된 하드웨어 리소스 컨피규레이션 파일에 기초하여 리소스를 할당한다. 또한, 상기 하드웨어 리소스 매니저는, 하드웨어 리소스 풀(Hardware Resource Pool)로부터 클래스 정보를 수신한다. 하드웨어 리소스 매니저는 패쓰 정보(ex, TU1 object-SDEC0 object-VDEC1 object-DE1 object)를 생성하여 이를 TV 파이프라인으로 전송하고, TV 파이프라인은 전송된 패쓰 정보에 기초하여 파이프라인을 구성한다.
TV 파이프라인이 구성되면, 각 오브젝트는 TV 미들웨어의 해당 드라이버들로 오픈 요청(ex, TU1 open to TU driver, SDEC0 open to SDEC driver)을 한다. 이를 통해 오브젝트와 관련된 드라이버들을 오픈하고 패쓰 컨트롤을 구성한다.
이후, 플레이 요청(Play tv://)을 하드웨어 리소스 매니저에서 수신하면, 상기 수신한 플레이 요청을 TV 미들웨어 내 채널 매니저 쓰레드(CM Thread)로 전달하고, 이를 통해 필요한 드라이버가 오픈되고 서비스가 이루어진다. 이와 같이, 하드웨어 리소스를 컨트롤하여 채널 체인지 등의 서비스 동작이 수행될 수 있다.
도 51은 본 발명의 다른 실시 예에 따른 서비스 재구조화를 설명하기 위해 도시한 도면이다.
도 51에서 TV 파이프라인의 상단부 처리 과정은, 전술한 도 50의 TV 파이프라인 상단부 처리 과정과 동일한바, 상술한 내용을 원용하고 여기서 상세한 설명은 생략한다. 따라서, 여기서는 TV 파이프라인 이하 단에 대해 주로 설명한다.
전술한 바와 같이, 도 50과 51의 가장 큰 차이는 TV 파이프라인의 구성에 있다. 전술한 도 50의 경우, 웹OS로의 TV 서비스 포팅을 위한 가상의 파이프라인 구성을 위한 것이라면, 도 51은 종래 TV 서비스에서 지원하는 MRE를 대체하기 위한 것이다. 따라서, 도 51에 도시된 TV 서비스 재구조화는 예컨대, TV 파이프라인과 관련된 TV 파이프라인 매니저, TV 리소스 매니저, 패쓰 매니저 등의 기능 등이 종래 TV 서비스와 상이하다.
도 50에서 가상의 파이프라인을 구성함에 비하여, 도 51을 참조하면 TV 파이프라인의 구성이 요청된 TV 서비스와 관련하여 더욱 많은 리소스들이 서로 리소스 어레인지먼트되어 있음을 알 수 있다. 이와 함께, 도 51은 도 50과 달리, TV 미들웨어 단에서 리소스들을 위한 드라이버들을 핸들링하는 것이 아니라 TV 파이프라인 단에서 이를 직접 핸들링할 수 있다. 이러한 것들이 예컨대, 도 50과 51의 차이로 볼 수 있다.
도 51을 참조하여, TV 파이프라인 단에 대해 더욱 상세하게 설명한다.
TV 파이프라인 단 내의 TV 서비스로 채널 체인지를 위한 리소스 어레인지는 TU-SDEC-VDEC-DE 오브젝트로 구성됨에 전술한 도 50과 같다. 이러한 오브젝트의 어레인지먼트는 예컨대, 상기 TV 서비스를 위한 기본적인 리소스들을 도시한 것으로 볼 수 있다. 도 50에서는 이러한 기본적인 리소스들에 대해서만 어레인지먼트하면, TV 미들웨어에서 관련 드라이버들과 리소스들을 연결하여 후속 처리를 하였다. 그러나, 도 51에서는 TV 미들웨어 단의 개입을 최소화하여 로드(load)를 최소화하고, TV 파이프라인 단에서 직접 리소스와 커넥션을 위한 드라이버들을 핸들링하여 빠른 처리를 할 수 있다.
도 51의 채널 체인지 TV 서비스를 위한 TV 파이프라인은 TU-SDEC0-PSIP-VEDC1-DE1-VIDEO 싱크 순으로 어레인지 되었다. 여기서, SDEC0 오브젝트와 PSIP 컴포넌트 사이에는 필요에 따라 데이터 방송 컴포넌트가 어레인지될 수 있으며, 상기 PSIP 컴포넌트와 VDEC1 오브젝트 사이에 필요에 따라 EPG 싱크, 채널 리스트 싱크 등이 어레인지될 수 있으며, 상기 VDEC1과 DE1 오브젝트 사이에 ACC 싱크가 추가로 어레인지될 수도 있음을 알 수 있다. 그리고, TV 파이프라인 단에서는 상기 파이프라인 내에 어레인지되는 오브젝트, 컴포넌트나 싱크 등의 하드웨어 리소스와 커넥션을 위한 드라이버 오픈을 직접 핸들링한다. 이렇게 TV 파이프라인 단에서 드라이버를 직접 핸들링함으로써 TV 미들웨어의 동작 내지 부담을 최소화하고 빠른 액세스, 처리 등이 가능해진다. 한편, 상기에서, 채널 체인지 서비스를 위해 구성된 TV 파이프라인 구성은 본 발명의 이해를 돕고 설명의 편의를 위해 도시한 일 예로서, 도시된 바에 한정되는 것은 아니다. 또한, 상기에서 PSIP 컴포넌트는 신호와 관련된 표준에 정의된 바에 따라 DVB 컴포넌트 등으로 변경될 수 있으며, 추가로 PSI 컴포넌트가 더 추가될 수도 있다.
다음으로, 본 발명에 따른 폴리시 매니지먼트에 대해 첨부된 도면을 참조하여 더욱 상세하게 설명하면, 다음과 같다.
상기에서 파이프라인을 구성함에 있어서, 리소스 쉐어링 개념을 이용하여 리소스들을 적절히 어레인지먼트하였다. 그러나, 서비스나 애플리케이션을 위한 디지털 디바이스 내 리소스는 제한적이다. 따라서, 본 발명의 웹OS에서 상기 서비스나 애플리케이션을 지원하기 위해서는 제한된 리소스들을 적절히 어레인지하여야 하고 특히나, 웹OS 플랫폼에서 멀티-태스킹 등을 지원하기 위해서는 이는 필수적이라고 볼 수 있다. 다시 말해, 디지털 디바이스에서 서비스나 애플리케이션을 지원함에 있어서, 리소스들이 필요하고 하나 또는 그 이상의 리소스들이 리소스 컨플릭트 발생 가능성이 있다. 상기와 같이, 리소스 컨플릭트가 발생하면, 이를 적절히 컨트롤하여야만 원활한 서비스 제공에 따른 사용자의 불편을 최소화할 수 있다. 여기서, 이하 더욱 상세하게 설명할 폴리시 매니지먼트(policy management)가 기능 한다. 한편, 상기 폴리시 매니지먼트는 이하에서 경우에 따라 폴리시 액션(policy action)이라 명명하여 설명하기도 한다.
본 발명에 따른 폴리시 매니지먼트는, 크게 센트럴라이즈드 폴리시 매니저와 디스트리뷰티드 폴리시 매니저에 의해 처리될 수 있다. 여기서, 도 52는 상기 센트럴라이즈드 폴리시 매니저에 관해 도시한 것이고, 도 53은 상기 디스트리뷰티드 폴리시 매니저에 관해 도시한 것이다.
도 52는 본 발명의 일 실시 예에 따른 폴리시 매니지먼트를 설명하기 위해 도시한 도면이다.
먼저, 도 52를 참조하여, 센트럴라이즈드 폴리시 매니저에 대해 설명하면, 다음과 같다.
폴리시는 기본적으로 각 파이프라인에 적용되어 직관적이다. 리소스 컨플릭트가 발생하면, 미디어 서버의 리소스 매니저만 폴리시를 고려하면 된다. 다시 말해, 파이프라인(들)은 폴리시를 고려하지 않아도 된다. 왜냐하면, 상기 리소스 매니저에서 폴리스를 고려하여 각 파이프라인에 리소스 어레인지하면 되기 때문이다.
센트럴라이즈드 폴리시 매니저에서는, TV 시스템상에 공통을 적용할 커먼 폴리시(common policy)가 있으면 적용이 쉬워 로드를 줄일 수 있다. 다시 말해, 파이프라인과 관련된 하나 또는 그 이상의 리소스들 또는 모듈들은 기본적으로 로드를 줄이기 위해 복잡한 폴리시를 고려하지 않을 수 있다. 이는, 디지털 디바이스에 일관적인 폴리시 적용이 요구된다는 의미로 해석할 수 있다.
다만, 센트럴라이즈드 폴리시 매니저에 따르면, 상기 폴리시 매니저가 디지털 디바이스 내 모든 폴리시를 신경 써야 하기 때문에, 코드(code)가 복잡해질 우려가 있다. 이는 상기 커먼 폴리시 뿐만 아니라 상기 커먼 폴리시를 해결하기 어려운 서비스나 애플리케이션과 관련된 다양한 예외 처리 등을 처리할 수 있도록 폴리시가 정의되어야 하므로 코드는 더욱 복잡해질 수 있다. 이러한 이유 등으로, 센트럴라이즈드 폴리시 매니저를 채용하는 경우에는 미디어 서버의 코드 퀄리티(quality)와 리유저빌러티(reusability)가 떨어질 수 있으며, 신규 파이프라인이 추가되는 경우 기존 모든 파이프라인들과의 프라이어티 비교 등을 다시 해야하는 등의 부담이 있을 수 있으며, 그에 따라 순위를 다시 정해야 할 수도 있다. 한편, 디지털 디바이스가 TV 서비스를 지원하는 경우, 쉐어러블 리소스, 다이내믹 프라이어티(dynamic priority) 등의 경우 그 리소스 어레인지 등 처리가 복잡해질 우려도 있다.
도 52를 참조하면, 시청을 위한 미디어 파이프라인(5210)은, VDEC1, ATP1, ADCE1 리소스가 상기 시청을 위해 요구된다. 또한, TV 서비스(5230)은 3개의 파이프라인을 보유하고 있다. 시청 파이프라인, 녹화 파이프라인 그리고 캡쳐 파이프라인을 포함하고 있다. 여기서, 시청 파이프라인은 TU0, SDEC0, VDEC0, ATP0, ADEC0의 리소스들을 요구하고, 녹화 파이프라인은 TU0, SDEC1 리소스들을 요구하며, 캡쳐 파이프라인은 TU0, SDEC0, VDEO0, Secondary Scaler 리소스들을 요구한다. 또한, 카메라 파이프라인(5240)은 시청을 위하여, Camera, VENC0, AENC0 리소스들을 요구한다.
상기와 같이, 각 파이프라인에서 리소스들을 요구하면, 미디어 서버 내 리소스 매니저(5220)는 해당 파이프라인에 적절히 요구한 리소스(들)을 할당한다. 다만, 전술한 바와 같이, 기본적으로, 디지털 디바이스는 제한된 리소스들을 가지고 있을 뿐이므로 이를 적절하게 할당할 필요가 있다. 일 예로, 리소스 매니저(5220)는 TV 서비스 내 시청, 녹화 및 캡쳐 파이프라인들에서 요구하는 리소스들 중 리소스 쉐어링 기법에 따라 상기 3개의 파이프라인들에 공통적으로 요구되는 TU0 리소스를 쉐어하도록 할당 지시할 수 있고, 시청 및 캡쳐 파이프라인들에 대해서는 SDEC0와 VDEC0 리소스들을 쉐어하도록 할당 지시할 수 있다. 한편, 리소스 매니저는 상기와 같이, TV 서비스의 파이프라인들만 고려하여야 하는 것이 아니라 미디어 파이프라인과 카메라 파이프라인들에서 요구하는 리소스도 함께 고려하여야 한다. 이를 위해, 리소스 매니저(5220)는 각 서비스 또는/및 파이프라인들에 대하여 리소스 할당 우선순위 데이터를 미리 저장하여 그에 기초하여 리소스들을 할당할 수 있다. 도 52를 예로 하면, TV 시청, TV 녹화, TV 캡쳐, 미디어 시청, 카메라 시청 등에 대해 미리 저장된 리소스 할당 우선순위에 따라 리소스 매니저는 각 파이프라인에서 요구하는 리소스들을 적절히 할당 또는 쉐어하도록 지시할 수 있으며, 컨플릭트가 발생하는 리소스(들)에 대해서는 상기 우선순위에 기초하여 우선순위가 더 높은 파이프라인에 리소스를 할당하고 우선순위가 낮은 파이프라인(들)에 대해서는 리소스 할당 거부 의사를 리턴할 수 있다. 이와 같이, 리소스 컨플릭트 발생 가능성을 고려하여 우선순위에 기초한 리소스 할당은 폴리시 매니저의 기능이 된다. 다시 말해, 리소스 매니저는 매 파이프라인이 생성되고, 생성된 파이프라인에서 리소스를 요구할 때마다, 기 생성된 파이프라인(들)에 대해 할당된 리소스(들)에 대해 상기 생성된 파이프라인과의 컨플릭트 가능성을 검토하고, 검토 결과 컨플릭트가 발생하면, 상기 우선순위에 기초한 폴리시에 따라 어떤 리소스를 릴리즈하고 릴리즈된 리소스를 어떤 파이프라인에 할당할 것인지 등에 관하여 적절히 결정하게 된다. 상술한 폴리시 매니지먼트는 각 파이프라인에 대해 미리 결정 및 저장된 우선순위에 기초한다고 설명하였으나 경우에 따라 LRU(Least Recently Used) 데이터를 더 고려하여 상기 리소스 릴리즈 또는 할당을 결정할 수도 있다.
도 53은 본 발명의 다른 실시 예에 따른 폴리시 매니지먼트를 설명하기 위해 도시한 도면이다.
도 52의 센트럴라이즈드 폴리시 매니저와 달리, 도 53은 디스트리뷰티드 폴리시 매니저를 도시한 것이다.
디스트리뷰티드 폴리시 매니저에 따르면, 센트럴라이즈드 폴리시 매니저에 비하여 서비스들 사이에 독립성이 높다. 또한, 센트럴라이즈드 폴리시 매니저에서 각종 서비스에 대한 예외 처리까지 고려하여 코드가 복잡해짐에 비하여, 디스트리뷰티드 폴리시 매니저에서는 상기 서비스의 예외 처리는 해당 서비스에서 내부적으로 처리하도록 하여 다른 서비스와의 관계에서 프라이어티에 대한 영향이 없다. 이와 같이, 디스트리뷰티드 폴리시 매니저에서는 미디어 서버 내 리소스 매니저가 디지털 디바이스상의 모든 폴리시를 신경쓸 필요가 없어 코드가 단순해지고 리유저빌러티가 상기 센트럴라이즈드 폴리시 매니저에 비해 높고, 리소스 매니지먼트가 쉽다. 그 밖에, 각 서비스 단위로 폴리시가 별도로 진행되어 해당 서비스에 대해 가장 잘 아는 모듈이 폴리시를 매니징하고, 신규 파이프라인 추가 시에도 쉽게 프라이어티가 적용될 수 있다.
반면, 디스트리뷰티드 폴리시 매니저에 의하면, 상술한 커먼 폴리시에 대한 적용 내지 처리가 어렵다. 또한, 각 서비스에 대한 폴리시를 개별적으로 매니징하는 기능 내지 모듈이 있어야 한다.
도 53의 디스트리뷰티드 폴리시 매니지먼트는 전술한 도 52와 유사한바, 그와 공통되는 내용에 대한 설명은 여기서는 생략하고, 전술한 내용을 참조한다. 따라서, 이하에서는 전술한 센트럴라이즈드 폴리시 매니지먼트 방식과 상이한 부분을 위주로 하여 설명한다.
도 53에 도시된 디스트리뷰티드 폴리시 매니지먼트는, 상기 도 52의 센트럴라이즈드 폴리시 매니지먼트 방식이 파이프라인 단위임에 반해, 서비스 단위임을 알 수 있다. 한편, 도 53의 디스트리뷰티드 폴리시 매니지먼트도 상기 52의 센트럴라이즈드 폴리시 매니지먼트 방식과 같이, 우선순위 또는/및 LRU에 기초하여 폴리시 매니지먼트를 할 수 있다. 다만, 전술한 바와 같이, 미디어 서버는 최소한의 로드만 책임지고 구체적인 내용은 해당 서비스에 일임하고 있다.
도 53을 참조하면, 미디어 서버는 TV, 미디어, 카메라 서비스에 대해서만 우선순위 데이터를 미리 결정하여 저장한다. 따라서, 미디어 서버는 각 서비스에서 리소스 요청이 수신되면, 해당 서비스의 우선순위 또는/및 LRU에 기초하여 해당 서비스로 리소스를 할당하게 된다. 이러한 처리 플로우는 매 서비스에서 리소스 요청시마다 리소스 컨플릭트 발생 우려를 고려하게 되고, 상기 고려 결과 리소스 컨플릭트 상황이 발생하면 폴리시 매니징을 하게 된다.
한편, 본 명세서에서 비록 도시하진 않았으나, 상황에 따라 도 52의 센트럴라이즈드 폴리시 매니지먼트 방식과 도 53의 디스트리뷰티드 폴리시 매니지먼트 방식은 적절히 혼용될 수 있다. 예를 들어, 미디어 서버는 하나의 서비스에서 리소스 할당이 요청되면, 도 53과 같이 디스트리뷰티드 폴리시 매니지먼트 방식에 기초하여 서비스 단위에서 리소스 컨플릭트 우려가 있는지 검토하고, 그 결과에 기초하여 리소스를 할당하면 된다. 이때, 미디어 서버는 계속하여 디스트리뷰티드 폴리시 매니지먼트 방식에 따라 서비스 단위로 리소스를 할당하고 해당 서비스에서 만약 복수의 파이프라인들이 생성된 경우에 알아서 리소스 할당을 할 수도 있고, 서비스 단위로 판단 이후에는 도 52에 따라 센트럴라이즈드 방식에 따라 해당 서비스 내 파이프라인 단위로 리소스를 할당할 수 있다. 또는, 미디어 서버는 만약 서비스 내에 파이프라인이 싱글 파이프라인인 경우에는 디스트리뷰티드 방식을 멀티 파이프라인들이면 센트럴라이즈드 방식을 이용할 수 있다. 그 반대도 가능하다. 또한, 상기에서 리소스를 요청하는 서비스가 복수 인 경우에만 디스트리뷰티드 방식에 기초하여 처리할 수도 있다.
도 54 내지 57은 본 발명의 일 실시 예에 따른 TV 서비스와 미디어 파이프라인 사이의 폴리시 매니지먼트 방식을 설명하기 위해 도시한 도면이다.
도 54를 참조하면, TV 서비스로 2D(2-Dimensional) 모드의 시청 파이프라인(A)과 3D(3-Dimensional) 모드 시청 파이프라인(B)이 생성되고, 미디어 파이프라인으로 2D 재생을 위한 파이프라인(C)이 도시되었다. 상기에서, 2D 모드 시청 파이프라인(A)은, ADTU, SDEC0, VDEC0, ATP0 및 ADEC0 리소스들이 요구되고, 3D 모드 시청 파이프라인(B)은, ADTU, SDEC0, VDEC0, ATP0, ADEC0 및 VDEC1 리소스들이 요구되고, 미디어 파이프라인(C)은 VDEC1, ATP1 및 ADEC1 리소스들이 요구된다. 도 54에서, 알파벳 A, B, C는 단순하게 각 파이프라인을 설명하기 위해 편의상 도시한 것이다. 다만, 다른 실시 예로, 상기 알파벳은 예컨대, 폴리시 우선순위, 파이프라인 생성 순서 또는 리소스 할당 요청 순서 등을 의미할 수도 있다. 이하에서는 편의상, 단지 각 파이프라인을 의미하는 것으로 가정하여 설명하나, 전술한 바와 같이, 이에 한정되는 것은 아니다.
종래 스마트 TV의 경우, A와 B 파이프라인에 대해 리소스 할당 이후에 C 파이프라인에서 리소스 할당을 요청한 경우, 미디어 서버는 B 파이프라인의 VDEC1과 C 파이프라인의 VDEC1 리소스의 컨플릭트 때문에, 상기 C 파이프라인의 리소스 할당 요청을 거부한다. 또는, A와 C 파이프라인에 대해 리소스 할당 이후에 B 파이프라인에서 리소스 할당이 요청되면, 전술한 바와 같이 B와 C 파이프라인 사이에는 리소스 컨플릭트가 발생한다. 이 경우, 상기 리소스 컨플릭트에 대해 종래 스마트 TV에서는, TV 서비스를 우선하여 즉, 우선순위가 더 높기 때문에 기 VDEC1 리소스를 할당받은 C 파이프라인에서 할당 받은 리소스를 릴리즈하도록 제어된다. 따라서, 결국 이 경우, TV에서는 A와 B 파이프라인에 따른 TV 서비스가 이루어진다. 또한, C와 A 파이프라인 순차로 리소스 할당을 요청하면 리소스 컨플릭트 상황이 없으므로 종래 스마트 TV에서는 해당 서비스들이 동시에 처리 가능하다. 다만, 이러한 상황에서 만약 B 파이프라인이 생성되고 리소스 할당 요청이 수신되는 경우에는, 상기 B와 C 파이프라인 사이에는 리소스 컨플릭트가 발생하기 때문에 마지막에 리소스를 할당한 B 파이프라인에 대해서는 리소스를 할당하지 않고 거부한다. 따라서, 상기 경우에 3D 서비스는 C 파이프라인이 제거 또는 C 파이프라인에서 리소스를 릴리즈 등을 하지 않는 경우에는 종래 스마트 TV에서는 이용 불가능한 서비스가 된다.
반면, 본 발명에 따른 웹OS 플랫폼이 채용된 디지털 디바이스에서는, 상술한 종래 스마트 TV와 다르게 리소스 컨플릭트 발생시 폴리시 매니지먼트를 할 수 있다.
먼저, A와 B의 파이프라인에서 리소스를 요청하고 리소스 쉐어링 등을 통해 리소스가 할당이 이루어진 상태에서, C 파이프라인이 생성되고 리소스 요청이 수신되면, 웹OS 디바이스에서는, 이 경우, TV 서비스로 VDEC 리소스 릴리즈 가부를 문의할 수 있다. 이 경우, 디지털 디바이스는 GUI 또는 OSD 메시지 형태로 사용자의 선택을 문의할 수 있다. 만약 사용자가 3D 모드 시청 파이프라인을 제거하겠다고 선택하면, 미디어 파이프라인은 VDEC 리소스를 할당 받을 수 있다. 그러나 만약 상기 사용자가 3D 모드 시청 파이프라인 제거를 원치 않으면, TV 서비스는 상기 폴리시 매니저의 폴리시를 거절할 것이다. 따라서, 미디어 파이프라인은 VDEC 리소스를 획득하지 못한다.
이와 달리, 만약 A와 C 파이프라인에서 리소스들을 먼저 점유한 상태에서, B 파이프라인에서 리소스 할당 요청이 수신되는 경우에는, 상기 B 파이프라인이 PIP TV 서비스 요청인 경우에는, 상기 B 파이프라인의 리소스 할당 요청을 거부할 수 있다. 그러나, 만약 상기 B 파이프라인이 풀-스크린 TV 서비스를 요청한 경우에는, B 파이프라인에 따른 VDEC 리소스 할당을 리소스 매니저에 요청할 수 있다. 그리고, 리소스 매니저는 미디어 파이프라인으로 상기 VDEC 리소스의 릴리즈를 요청할 수 있다.
이와 같이, 종래 스마트 TV에서와 본 발명에 따른 웹OS 디바이스에 폴리시 매니지먼트는 상이하게 이루어진다.
이하에서는 전술한 내용과 중복되는 내용의 설명은 생략하고, 상이한 점 위주로 설명한다.
먼저, 도 55는 TV 서비스로 2D 모드의 시청 파이프라인(A), 그리고 미디어 파이프라인들로 2D 재생 파이프라인(B)과 3D 재생 파이프라인(C)이 도시되었다. 도 55에서는 A 파이프라인과 C 파이프라인 사이에 동일하게 VDEC0 리소스의 컨플릭트 가능성이 있다.
종래 스마트 TV에서는 A와 B 파이프라인에 대해 리소스 할당 이후에 C 파이프라인에서 리소스 요청을 하면, A 파이프라인에 대해 기 할당된 리소스를 릴리즈하도록 처리하고, A와 C 파이프라인에 대해 리소스 할당 이후에 B 파이프라인에서 리소스 요청을 하면 상술한 바와 같이, A 파이프라인에 대해 기 할당된 리소스의 릴리즈를 한다. 한편, C와 A 파이프라인에 대해 순차로 리소스 할당 이후에 B 파이프라인에서 리소스 요청하면 동일하게 A 파이프라인의 리소스를 릴리즈하고, C와 B 파이프라인 이후에 A에서 리소스 할당 요청을 하면, 상기 A의 리소스 할당 요청은 거부된다.
반면, 본 발명에 따른 웹OS 디바이스에는, 다음과 같이 처리된다.
A와 B 파이프라인에 대해 리소스 할당 이후에 C 파이프라인에서 리소스 할당을 요청하는 경우와 B와 A 파이프라인에 대해 순차로 에서 리소스 할당 이후에 C 파이프라인에서 리소스 할당을 요청하는 경우에는, 상기 C 파이프라인이 PIP를 통한 미디어 서비스 요청인 경우에는, 상기 C 파이프라인의 요청은 거부된다. 그러나, 만약, 상기 C 파이프라인이 풀-스크린을 통한 미디어 서비스 요청인 경우에는, 미디어 서버로 VDEC 리소스 요청을 해야 한다. 이 경우, 미디어 서버는 TV 서비스로 VDEC 릴리즈를 요청한다. 따라서, A 파이프라인은 VDEC 리소스를 릴리즈한다.
반면, B와 C 파이프라인에 대해 리소스 할당 이후에, A 파이프라인에서 리소스 요청을 하는 경우에는, 미디어 서버는 상기 미디어 파이프라인으로 VDEC 릴리즈 요청을 한다. 그리고 사용자가 만약 특히, C 파이프라인을 제거하겠다고 선택하면, TV 서비스는 VDEC 리소스를 할당받아 TV 서비스가 가능하나 그렇지 않은 경우에는 미디어 파이프라인은 폴리시를 거부하고, 결국 TV 서비스는 VDEC 리소스를 얻지 못해 TV 서비스가 불가능해 진다.
다음으로, 도 56은 TV 서비스로 컴포넌트 입력에 따른 시청 파이프라인(A)과 녹화 파이프라인(B), 그리고 미디어 파이프라인으로 2D 재생 파이프라인(C)이 도시되었다. 여기서, 상기에서, A 파이프라인은, VADC0, AADC0 및 ADEC0 리소스들이 요구되고, B 파이프라인은, ADTU, SDEC0, VDEC0, Secondary Scaler, VENC, ATP0, ADEC1, AENC 및 MUX 리소스들이 요구되고, C 파이프라인은 VDEC1, ATP1 및 ADEC1 리소스들이 요구된다. 따라서, 도 56에서는 B와 C 파이프라인 사이에 ADEC1 리소스의 컨플릭트 가능성이 있다.
본 발명에 따를 경우, A와 B 파이프라인에 대해 리소스 할당 이후에 C 파이프라인에서 리소스 요청, A와 C 파이프라인에 대해 리소스 할당 이후에 B 파이프라인에서 리소스 요청, C와 A 파이프라인에 대해 리소스 할당 이후에 B 파이프라인에서 리소스 요청 및 C와 B 파이프라인에 대해 리소스 할당 이후에 A 파이프라인에서 리소스 요청을 한 경우, 각 경우에서 가장 마지막에 리소스 요청을 한 파이프라인에서 PIP 스크린을 요청한 경우에는, 상기 PIP 스크린 요청은 모두 거부된다.
마지막으로, 도 57은 TV 서비스로 파이프라인(A), 그리고 미디어 파이프라인으로 2D 재생 파이프라인(B)과 3D 재생 파이프라인(C)이 도시되었다. 도 57에서는 TV 서비스와 미디어 파이프라인 사이에 VDEC0, ADEC1 리소스들의 컨플릭트 가능성이 있다.
종래 스마트 TV의 경우, 도 57에 대해 어떤 경우도 C 파이프라인은 리소스 할당이 거부되거나 기 할당 받은 리소스를 릴리즈하여야 한다. 다만, 웹OS 디바이스에서는, 미디어 서버에서 TV 서비스로 VDEC 리소스의 릴리즈를 요청하나, 상기 TV 서비수는 상기 폴리시를 거부하고, 결국, 미디어 파이프라인은 VDEC 리소스를 할당받지 못한다. 따라서, 이 경우에 C 파이프라인에서 VDEC0 리소스로 인해 상기 TV 서비스의 종료, 임의의 리소스 릴리즈 등의 경우가 아닌 경우에는 모두 서비스가 불가능해질 수 있다.
도 58은 본 발명의 일 실시 예에 따른 TV 파이프라인들 사이의 폴리시 시나리오를 설명하기 위해 도시한 도면이다.
도 58은 예를 들어, 전술한 도 52의 센트럴라이즈드 폴리시 매니지먼트보다는 도 53의 디스트리뷰티드 폴리시 매니지먼트에 대한 내용일 수 있다.
본 발명과 관련하여, 리소스 매니지먼트 또는 폴리시 매니지먼트와 관련하여, 미디어 서버와 TV 서비스 처리부가 기능한다. 여기서, 미디어 서버는 리소스 매니저(5820), 폴리시 매니저(5850)가 기능하며, 상기 미디어 서버와 관련하여 미디어 서비스를 위한 하나 또는 그 이상의 미디어 파이프라인들이 존재할 수 있다. 한편, TV 서비스 처리부 역시, TV 리소스 매니저(5830)와 TV 폴리시 매니저(5860)가 기능하여 TV 서비스를 위한 하나 또는 그 이상의 TV 파이프라인들은 제어한다.
본 발명과 관련하여, 튜너와 같은 리소스(들)은 TV 서비스만을 위한 리소스(들)이다. 따라서, TV 리소스 매니저는 스스로 리소스 컨플릭트를 인지할 수 있다. 리소스 획득 이전에 만약 상기 리소스 컨플릭트가 감지되면, TV 폴리시 매니저(5860)는 상기 리소스 컨플릭트를 적절히 처리할 수 있다.
관련하여, TV 파이프라인1(5840)에서 리소스를 요청하면, TV 리소스 매니저(5830)는 TV 폴리시 매니저를 통해 리소스 컨플릭트 여부를 문의한다. 그리고, TV 폴리시 매니저(5860)는 상기 문의를 통한 리소스 컨플릭트 처리를 위해 TV 파이프라인2(5870)의 리소스 릴리즈를 요청한다. 다만, 이는 리소스 컨플릭트가 발생하는 경우이다.
TV 리소스 매니저(5830)는, 컨플릭트가 발생한 경우 또는 그렇지 않은 경우에, 미디어 서버의 리소스 매니저(5820)로 리소스 할당을 요청하고, 상기 미디어 서버의 리소스 매니저(5820)로부터 리소를 할당받으며, TV 파이프라인1(5840)로 할당받은 리소스를 할당한다.
도 58에서는 예컨대, TV 파이프라인들(TV 파이프라인1(5840), TV 파이프라인2(5870) 등)만 존재하였다. 이와 달리, 하나 또는 그 이상의 미디어 파이프라인(5810)이 존재하는 경우에 대해 설명하면, 다음과 같다. 도 59 내지 60은 본 발명의 일 실시 예에 따른 TV 파이프라인과 미디어 파이프라인 사이의 폴리시 시나리오를 설명하기 위해 도시한 도면이다.
여기서, 도 59와 60은 예를 들어, TV 파이프라인에서 리소스를 요청하는 경우에 이미 해당 리소스가 미디어 파이프라인(5910/6010)에 할당된 경우를 가정하여 설명한다.
도 59를 참조하면, TV 파이프라인1(5940)에서 리소스 할당을 TV 리소스 매니저(5930)로 요청하면, TV 리소스 매니저(5930)는 상기에 요청에 대응하여 리소스 획득을 위해 미디어 서버의 리소스 매니저(5920)로 리소스 할당을 요청한다. 미디어 서버의 리소스 매니저(5920)는 폴리시 매니저(5950)로 리소스 컨플릭트 여부를 문의한다. 미디어 서버의 폴리시 매니저(5950)는 상기 리소스 매니저(5920)의 요청에 따라 미디어 파이프라인으로 기 할당받은 리소스의 릴리즈를 요청한다. 미디어 파이프라인(5910)에서 리소스를 릴리즈하였음을 미디어 서버의 리소스 매니저(5920)로 보고하면, 미디어 서버의 리소스 매니저(5920)는 상기 TV 리소스 매니저(5930)에서 요청한 리소스를 할당한다. TV 리소스 매니저(5930)는 상기 획득한 리소스를 TV 파이프라인1(5940)에 할당한다.
도 60을 참조하면, TV 파이프라인1(6040)에서 TV 리소스 매니저(6030)로 리소스 할당을 요청하고, TV 리소스 매니저(6030)는 상기 요청에 대응하여 미디어 서버의 리소스 매니저(6020)로 리소스 할당을 요청한다. 미디어 서버의 리소스 매니저(6020)는 리소스 컨플릭트 여부를 미디어 서버의 폴리시 매니저(6050)로 문의한다. 폴리시 매니저(6050)는 리소스 컨플릭트가 발생한 경우에 해당 리소스의 릴리즈를 미디어 파이프라인(6010)에 요청한다. 상기 미디어 파이프라인(6010)에서 만약 상기 폴리시 매니저(6050)의 요청을 거부한다고 응답하면, 폴리시 매니저(6050)는 리소스 매니저(6020)로 릴리즈가 거부되었음을 보고하고, 미디어 서버의 리소스 매니저(6020)는, TV 리소스 매니저(6030)로 리소스 할당이 불가하다고 응답한다. TV 리소스 매니저(6030)는 이를 다시 TV 파이프라인1(6040)에 전달한다.
도 59와 60은 둘 다 TV 파이프라인과 미디어 파이프라인 사이에 리소스 컨플릭트 이슈가 있다. 다만, 도 59에서는 미디어 파이프라인(5910)에서 폴리시 매니저(5950)의 릴리즈 요청에 응하였으나, 도 60에서는 거부한 것이 상이하다.
도 61 내지 62는 본 발명의 다른 실시 예에 따른 TV 파이프라인과 미디어 파이프라인 사이의 폴리시 시나리오를 설명하기 위해 도시한 도면이다.
도 61과 62는 전술한 도 59 내지 60과 반대로, 미디어 파이프라인에서 리소스를 요청할 때, 상기 요청된 리소스가 이미 TV 파이프라인에서 획득한 리소스인 경우의 처리 과정을 도시하고 있다.
도 61을 참조하면, 먼저 미디어 파이프라인(6119(에서 미디어 서버의 리소스 매니저(6120)로 리소스 할당을 요청하면, 상기 리소스 매니저(6120)는 폴리시 매니저(6150)로 리소스 컨플릭트 여부를 문의한다. 만약, 상기 폴리시 매니저(6150)에서 판단 결과 리소스 컨플릭트가 발생하면, 미디어 서버의 폴리시 매니저(6150)는 TV 폴리시 매니저(6160)로 컨플릭트가 발생한 리소스의 릴리즈를 요청한다. TV 폴리시 매니저(6160)는 상기 미디어 서버 폴리시 매니저(6150)로부터 리소스 릴리즈 요청이 수신되면, TV 리소스 매니저(6130)로 리소스 릴리즈 세션을 요청한다. TV 리소스 매니저(6130)는 상기 폴리시 매니저(6150)의 리소스 릴리즈 세션 요청을 TV 파이프라인1(6140)로 전달하고, 상기 TV 파이프라인1(6140)은 상기 전달된 리소스 릴리즈 세션 요청에 따라 리소스 릴리즈를 TV 리소스 매니저(6130)로 요청한다. TV 리소스 매니저(6130)는 다시 미디어 서버 리소스 매니저(6120)로 해당 리소스의 릴리즈를 요청한다. 마지막으로, 미디어 서버 리소스 매니저(6120)는, TV 서비스에서 릴리즈한 리소스를 미디어 파이프라인(6110)으로 할당한다.
도 62는 전술한, 도 61과 대동소이하나, 미디어 서버 폴리시 매니저(6250)에서 컨플릭트가 발생한 리소스의 릴리즈를 TV 폴리시 매니저로 요청한 경우에, 상기 릴리즈를 거부한 경우이다. 이 경우, 상기 미디어 서버 폴리시 매니저(6250)는 릴리즈가 거부되었음을 미디어 서버 리소스 매니저(6220)로 전달하고, 미디어 서버 리소스 매니저96220)에서는 다시 리소스 할당이 불가함을 미디어 파이프라인(6210)에 전달한다.
이하에서는 본 발명에 따른 서비스 또는 애플리케이션을 처리하는 디지털 디바이스에 대해 다양한 실시예(들)을 첨부된 도면을 참조하여, 더욱 상세하게 설명한다.
특히, 이하에서는 상기 서비스 또는 애플리케이션은 디지털 디바이스에서 제공하는 PIP(Picture in Picture) 서비스 또는 PIP 애플리케이션을 포함한다. 따라서, 이하에서는 첨부된 도면을 참조하여, PIP 서비스 또는 애플리케이션을 처리하는 디지털 디바이스와 그 처리 방법에 대해 상세하게 설명한다.
먼저, 도 63은 본 발명의 일 실시 예에 따른 VSM(Video Sink Manager)을 설명하기 위해 도시된 도면이다.
우선, 싱글 애플리케이션은, 싱글 또는 멀티플 윈도우(single or multiple window)를 가질 수 있다.
VSM(6370)은 디지털 디바이스의 하드웨어에 의해 제어되는 모든 비디오 소스를 알 수 있다. 이는 파이프라인(6360, 6380)이 상기 VSM(6370)에 식별자(ID)와 포트(VDEC port)를 레지스터(register)하기 때문이다. 또한, VSM(6370)은 애플리케이션으로 각 소스가 디스플레이 엔진(6390)과 연결되도록 하는 기능을 제공한다. 상기 디스플레이 엔진(6390)에는 메인(Main)과 서브(Sub)가 존재한다.
애플리케이션에는 포어그라운드 애프리케이션(6330)과 백그라운드 애플리케이션(6340)이 존재한다. 포어그라운드는 주로 풀-스크린이고, 백그라운드는 주로 미니마이즈드(minimized)이다. 여기서, 상기 메인이라 함은 포어그라운드일 수 있고, 서브라 함은 백그라운드 일 수 있으며, 그 반대일 수도 있다. 한편, LSM(6310)은 애플리케이션이 메인인지 여부를 결정할 수 있다. 또한, LSM(6310)은, 라이프사이클 이벤트(lifecycle event)를 애플리케이션으로 전송할 수 있다. 상기 라이프사이클 이벤트에는 예를 들어, 포어그라운드 이벤트와 백그라운드 이벤트가 포함될 수 있다.
애플리케이션은 비디오 소스를 디스플레이 엔진(6390)으로 연결하도록 VSM(6370)에 요청할 수 있다. 특히, 포어그라운드 애플리케이션(6330)은 하나의 비디오 소스를 가지고 LSM(6310)으로부터 포어그라운드 이벤트를 수신하면, 상기 VSM(6370)으로 상기 비디오 소스를 디스플레이 엔진(6390)으로 연결 요청한다. 또한, 백그라운드 애플리케이션(6330)은 하나의 비디오 소스를 가지고 LSM(6310)으로부터 백그라운드 이벤트를 수신하면, 상기 VSM(6370)으로 상기 비디오 소스를 디스플레이 엔진(6390)으로 연결하지 말도록 또는 그 연결을 끊도록 요청한다.
포어그라운드 애플리케이션(6330)은 비디오를 디스플레이하기 위해 파이프라인이 로딩되고 난 후 비디오 소스를 디스플레이 엔진(6390)으로 연결한다. 한편, 백그라운드 애플리케이션(6349)은 파이프라인이 언로딩(unloading) 이전에 비디오 소스를 디스플레이 엔진(6390)으로부터 연결을 끊을 수 있다.
비디오 소스 즉, 파이프라인(6360)은, 로딩 시에 디코더 정보를 가진 pipelineID의 레지스터를 VSM(6370)에 요청한다. 한편, 비디오 소스(파이프라인)(6380)은, 언로딩 시에 pipelineID의 언레지스터(unregister)를 VSM(6370)에 요청한다.
상기 애플리케이션이 웹 애플리케이션이면, 웹키트, 미디어 플러그-인(media plug-in) 그리고 플래시 플러그-인(flash plug-in)은 애플리케이션을 대신하여 상기 커넥트와 디스커넥트를 핸들링할 수 있다.
한편, 애플리케이션이 둘 또는 그 이상의 인풋 소스들(input sources)(파이프라인)을 가지는 경우에는, PIP 이슈(PIP issue)와 관련된다. 이에 대한 보다 상세한 설명은 추후 해당 파트에서 설명하고, 여기서 상세한 설명은 생략한다.
상기 각 애플리케이션은 비디오 소스에 대한 로드(load), 재생(play), 포즈(pause) 등을 미디어 서버(6320, 6350)로 요청하고, 상기 미디어 서버(6320, 6350)는 상기 요청에 대응하여 미디어 파이프라인(6360, 6380)을 생성한다.
도 64는 본 발명의 일 실시 예에 따른 비디오 처리와 관련하여, 소스(source)와 싱크(sink)에 대한 개념을 설명하기 위해 도시된 도면이다.
여기서, 도 64a는 인풋 스택(input stack)에 대해 도시한 것이고, 도 64b는 렌더링 스택(rendering stack)을 도시하고 있다.
기본적으로, 비디오 패쓰(video path)는 비디오 소스(video source)와 비디오 싱크(video sink)로 구성된다. 또한, 그래픽 패쓰(graphic path)는 그래픽 소스(graphic source)와 그래픽 싱크(graphic sink)로 구성된다.
비디오 소스로부터 비디오 서피스(video surface)와 그래픽 소스로부터 그래픽 서피스(graphic surface)는 비디오 싱크와 그래픽 싱크를 통하여 디스플레이 서피스(display surface)로 컴포지트(compsite)된다.
상기, 도 64a의 인풋 스택은 비디오 소스와 그래픽 소스를 컨트롤하기 위한 것이고, 도 64b의 렌더링 스택은 비디오 싱크와 그래픽 싱크를 컨트롤하기 위한 것이다.
도 64a를 참조하면, 비디오 소스를 위한 인풋 스택의 컨트롤러는 미디어 서버(uMediaServer), TV 브로드캐스트 서비스(TV Broadcast Service), 여러 미디어 파이프라인들(media pipelines) 등이다.
한편, 도 64b를 참조하면, 비디오 싱크를 위한 렌더링 스택의 컨트롤러들은 VSM, TV 디스플레이 서비스(TV Display Service) 등이다.
또한, 도 64a를 참조하면, 그래픽 소스를 위한 인풋 스택의 컨트롤러들은, 웹키트, 브라우저(browser), QT, 즉, 여러 그래픽 엔진(graphic engine)에 기초한 모든 애플리케이션들이다.
그 밖에, 도 64b를 참조하면, 그래픽 싱크를 위한 렌더링 스택의 컨트롤러들은, LSM과 GM의 컴포지터이다.
한편, VTG는 비디오 싱크에서 그래픽 소스로 전달될 수 있으며, 서브타이틀은 인풋 스택에서 컨트롤될 수 있다. 예를 들어, 상기 서브타이틀의 사이즈와 포지션 등은 디스플레이 서비스보다는 비디오 서피스와 관련될 수 있다.
도 65는 본 발명의 일 실시 예에 따른 인풋 스택과 렌더링 스택에서 비디오 인풋을 컨트롤하는 것을 설명하기 위해 도시한 도면이다.
여기서, 도 65a는 인풋 스택을 도시한 것이고, 도 65b는 렌더링 스택을 도시한 것이다. 한편, 미디어 서버(uMediaServer)는 애플리케이션에 의해 요청된 컨트롤을 미디어 파이프라인으로 딜리게이트(delegate)할 수 있다. 특히, 웹 애플리케이션의 경우에는, 애플리케이션은 웹키트(비디오 태그), 또는 미디어 플러그-인이나 플래시 플러그-인일 수 있다.
이하, 도 65a와 65b를 참조하여, 도시된 구성요소를 통하여 비디오 컨트롤 시퀀스를 설명한다.
먼저, 파이프라인 로딩시의 시퀀스를 설명하면, 다음과 같다.
애플리케이션(6520)에서 미디어 서버(6530)로 URL을 가지고 파이프라인 로딩을 요청한다. 미디어 서버(6530)는 상기 요청에 기초하여 미디어 파이프라인(6540)을 생성한다.
미디어 파이프라인(6540)은 VDEC을 획득한 이후에 mediaID와 VDEC 포트의 레지스터를 VSM(6550)으로 요청한다. 미디어 파이프라인(6540)의 현재 상태는 포즈 상태이고, 미디어 서버(6530) 은 애플리케이션(6520)으로 로드 컴플리트(load complete)를 전송한다.
애플리케이션은 미디어 서버(6530)로부터 로드 컴플리트가 수신되면, VSM(6550)에게 mediaID를 디스플레이 엔진(6560)과 연결하도록 요청한다. 상기 VSM(6550)은 레지스터된 mediaID의 VDEC 포트를 피지컬리 디스플레이 엔진(6560)과 연결한다.
애플리케이션(6520)은 디스플레이 서비스에게 디스플레이 윈도우의 사이즈와 포지션을 컨트롤하도록 요청한다. 우선, 상기 디스플레이 윈도우의 사이즈, 포지션 등은 디폴트로 pos{x, y, w, h}일 수 있다.
이후, 애플리케이션(6520)은 미디어 서버(6530)로 파이프라인 재생을 요청하고 이때, A/V는 스톱되고 뮤트된다.
한편, 미디어 파이프라인(6540)은, 재생 이후에 비디오 포맷 인포메이션을 디스플레이 서비스로 전송한다.
상기 파이프라인 로딩 이후에 애플리케이션의 라이프사이클 동안에 추가적인 시퀀스는 예를 들어, 다음과 같다.
LSM(6510)은 애플리케이션(6520)으로 포어그라운드 또는 백그라운드에 대한 라이프사이클 메시지를 전송한다.
이후, 애플리케이션(6520)은, 상기 LSM(6510)으로부터 라이프사이클 메시지로 포어그라운드를 수신하면, mediaID를 디스플레이 엔진(6560)에 연결하도록 VSM(6550)에 요청한다. 한편, 상기 라이프사이클 메시지가 백그라운드인 경우에는, 애플리케이션(6520)은 상기 VSM(6550)에 디스플레이 엔진(6560)으로부터 mediaID의 디스커넥트를 요청할 수 있다.
애플리케이션(6520)은 스스로 원하는 경우에는 디스플레이 서비스로 디스플레이 윈도우의 새로운 사이즈, 포지션 등에 대한 컨트롤을 요청할 수 있다.
도 66 내지 69는 본 발명의 일 실시 예에 따른 웹 애플리케이션에서 일어나는 다양한 시나리오들에 대한 시퀀스 다이어그램을 설명하기 위해 도시한 도면이다.
먼저, 도 66을 참조하여, 포어그라운드 애플리케이션에서 파이프라인을 로딩하는 시나리오에 대한 시퀀스 다이어그램을 설명한다.
비디오 소스를 가진 애플리케이션(6610)은 비디오 태그를 가진 웹키트(6612)를 통하여 파이프라인 로드를 미디어 서버(6620)로 요청한다.
미디어 서버(6620)는 상기 요청에 따라 미디어 파이프라인(6622)을 생성하고, 상기 생성된 미디어 파이프라인(6622) mediaID와 비디오 소스 처리를 위한 VDEC port를 VSM(6630)에 레지스터한다.
미디어 서버(6620)는 VSM(6630)으로부터 미디어 파이프라인(6622)를 통해 수신한 로드 컴플리트 메시지를 수신하여 이를 웹키트(6612)로 전달한다.
웹키트(6612)는 VSM(6630)으로 디스플레이 엔진(6640)과의 연결을 요청하고, VSM(6630)은 상기 애플리케이션이 포어그라운드에 있으므로 상기 애플리케이션을 디스플레이 엔진(6640)과 피지컬리 커넥트 제어한다.
이후 애플리케이션(6610)은 상기와 같이, 디스플레이 엔진(6640)과 커넥트가 된 이후, 필요에 따라 디스플레이 윈도우 사이즈, 포지션 등의 설정 요청을 할 수 있다.
웹키트(6612)에서, 미디어 서버(6620)에서 플레이 요청을 하면, 상기 미디어 서버(6620)는 생성된 미디어 파이프라인(6622)으로 전달하고, 상기 미디어 파이프라인(6622)은 이에 기초하여 미디어 비디오 데이터 설정을 디스플레이 엔진(6640)으로 요청하여 포어그라운드 애플리케이션에서 파이프라인 로딩이 이루어진다.
다음으로, 도 67을 참조하여, 애플리케이션이 백그라운드로 가는 시나리오에 대한 시퀀스 다이어그램을 설명한다.
전술한 바와 같이, LSM은 애플리케이션의 라이프사이클 메시지를 알고 있다. 따라서, 만약 애플리케이션이 백그라운드로 가야 하는 경우에 상기 LSM은 애플리케이션 즉, 웹키트로 미니마이즈(minimized)를 전송한다.
웹키트는 상기와 같이, LSM으로부터 미니마이즈가 수신되면, 이에 기초하여 VSM으로 디스플레이 엔진과의 디스커넥트를 요청한다. 그리고, 웹키트는 상기 디스커넥트 요청과 동시에 또는 그 이후에 미디어 서버로 포즈 요청을 한다. 다만, 상기 포즈 요청은 선택적일 수 있다. 미디어 서버는 상기 웹키트가 디스커넥트 요청을 하거나 포즈 요청이 수신되면, 생성된 미디어 파이프라인으로 플레이에서 포즈로 상태 변경을 요청 또는 커맨드한다.
애플리케이션이 전술한 도 66과 같이, 포어그라운드에 있다가 백그라운드로 가면, 상술한 시퀀스에 따르게 된다.
다음으로, 도 68을 참조하여, 상술한 도 67에서 애플리케이션이 포어그라운드에서 백그라운드로 갔다가 다시 도 66과 같이 포어그라운드로 가는 시나리오에 대한 시퀀스를 설명한다.
상기 시나리오 즉, 애플리케이션의 라이프사이클에 대해서 LSM이 알고 있으므로, 전술한 바와 같이, LSM은 애플리케이션 또는 웹키트로 미니마이즈가 아니라 풀-스크린을 전송한다.
웹키트는 상기 LSM의 풀-스크린 수신에 따라, 다시 VSM으로 디스플레이 엔진과의 커넥트를 요청한다. 그리고, 웹키트는 상기 커넥트 요청과 동시에 또는 그 이후에 미디어 서버로 플레이 요청을 한다. 다만, 상기 플레이 요청은 선택적일 수 있다. 미디어 서버는 상기 웹키트가 커넥트 요청을 하거나 플레이 요청이 수신되면, 미디어 파이프라인으로 포즈에서 다시 플레이로 상태 변경을 요청 또는 커맨드한다.
애플리케이션이 전술한 도 66에서 포어그라운드에 있다가 도 67에서 백그라운드로 갔다가 다시 도 68과 같이 포어그라운드에 돌아오면, 상술한 시퀀스에 따르게 된다.
마지막으로, 도 69를 참조하여, 도 66 내지 68에 이어 포어그라운드 애플리케이션에서 파이프라인을 언로딩하는 시나리오에 대한 시퀀스를 설명한다.
애플리케이션 또는 웹키트는 미디어 서버로 스톱을 요청하고, VSM으로 디스플레이 엔진과의 디스커넥트를 요청한다. 이때, 상기 스톱 요청은 예를 들어, 상기 디스커넥트 요청에 의해 대체되고 선택적일 수 있다. 상기에서, 미디어 서버가 만약 스톱 요청을 수신한 경우에는, 미디어 파이프라인에 플레이에서 스톱으로 상태 변경을 요청 또는 커맨드한다.
웹키트는, 상기 디스커넥트 요청과 동시에 또는 그 이후에 미디어 서버로 언로드 요청을 한다. 미디어 서버는 상기 언로드 요청이 수신되면, 이를 미디어 파이프라인으로 전달하고, 상기 미디어 파이프라인은 상기 언로드 요청이 수신되면 VSM으로 언레지스터를 요청한다.
포어그라운드 애플리케이션에서 파이프라인이 언로딩은 상술한 과정을 통해 이루어질 수 있다.
전술한 도 66 내지 69는 예컨대, 포어그라운드에서 파이프라인을 로딩하고, 백그라운드를 갔다가 다시 포어그라운드로 온 이후에 최종적으로 파이프라인을 언로딩하는 애플리케이션의 라이프사이클에 대한 시나리오를 설명한 것이다. 본 명세서에서는 본 발명의 이해를 돕고 설명의 편의를 위해 상술한 시나리오를 순차로 설명하였으나, 애플리케이션의 라이프사이클에 따라 상기 과정은 서로 바뀔 수도 있으며, 도면에 도시하지 않거나 설명되지 않은 내용은 전술한 내용으로부터 자명하게 유추할 수 있다.
도 70은 본 발명의 일 실시 예에 따른 PIP 이슈를 설명하기 위해 도시한 도면이다.
도 70은 디지털 디바이스의 메인 싱크와 서브 싱크에 관한 것이다. 여기서, 메인과 서브 개념은 예컨대, 개념적인 것으로 이는 하드웨어 블록의 어디에 맵핑될 수 있다. 한편, 하드웨어 블록은 각 SoC에 의해 달라질 수 있다.
전술한 바와 같이, VSM은 비디오 소스와 메인 싱크 또는 서브 싱크의 커넥트를 위한 인터페이스를 제공한다. 일반적으로, 상기 메인 싱크는 서브 싱크에 비해서는 파워풀한 성능을 가지는데, 상기 메인 싱크만 풀 픽쳐 퀄리티(full picutre quality)를 지원할 수 있다.
비디오 소스가 디스플레이 상에서 한 개 즉, 싱글 비디오 소스인 경우에는 메인 싱크가 이용될 수 있다. 이때, 상기 비디오 소스 자체의 사이즈가 풀 사이즈이나 아니면 상기 풀 사이즈가 아닌 경우에 관계없다.
다만, 비디오 소스가 둘 이상인 경우에는 상기 싱글 소스 경우와 같이, 메인 싱크만으로 디스플레이 상에 모두 출력할 수 없다. 다시 말해, 비디오 소스가 둘 이상인 경우에는 서브 싱크도 이용되어야 한다. 이를 예컨대, PIP 시나리오 또는 PIP 이슈로 칭하고, 이하 설명한다.
일반적으로, PIP 시나리오에서, 메인 싱크는 디스플레이 상에서 큰 사이즈를 위해 이용되고, 서비스 싱크는 작은 사이즈를 위해 이용되나, 반드시 그에 한정되는 것은 아니다. 예를 들어, 둘 이상의 비디오 소스의 사이즈가 디스플레이 상에서 동일하다고 한다면, UX에 의해 두 싱크 중 어느 하나가 메인 싱크가 될 것이다.
한편, 상기에서는 비디오 소스의 관점에서 기술하였으나, 애플리케이션의 관점에서 기술할 수도 있다. 예를 들어, 애플리케이션이 한 개의 비디오 소스를 가질 수 있으나, 복수 개의 비디오 소스를 가질 수도 있다. 따라서, 후자의 경우에도 동일하게 PIP 시나리오가 적용될 수 있다.
따라서, 본 발명과 관련하여, PIP 시나리오는 다음과 같을 수 있다.
첫째, 포어그라운드에 두 개의 애플리케이션이 있고, 각 애플리케이션이 디스플레이 상에서 각각 비디오 소스를 가진 경우이다.
둘째, 싱글 애플리케이션이 디스플레이 상에서 두 개의 비디오 소스를 가진 경우이다. 상기 싱글 애플리케이션이 둘 이상의 파이프라인을 가진 경우, 그들 중 하나는 리소스 매니저나 폴리시 매니저에 의하여 언로드될 수 있다.
셋째, 각각 두 개의 비디오 소스를 가진 두 개의 애플리케이션이 디스플레이 상에 있는 경우이다.
다만, 본 명세서에서 비록 상기한 실시 예들에 대해 주로 설명하나, 그 밖에 애플리케이션, 비디오 소스, 메뉴 등과 관련하여 디스플레이 상에서 발생하는 다양한 시나리오를 지원하기 위한 PIP 시나리오는 이에 한정되지 않는다.
관련하여, 도 70a는 전술한 PIP 시나리오 중 첫째 시나리오와 같이, 두 개의 애플리케이션이 포어그라운드에 있고, 풀-스크린 애플리케이션에 풀-비디오를 제공하고, PIP 애플리케이션에서 PIP 비디오를 제공하고 있다. 여기서, PIP 비디오가 출력되는 부분은, PIP 스크린, 서브 스크린 등으로 호칭될 수 있다. 반대로, 풀-비디오가 제공되는 부분은, 풀-스크린, 메인 스크린 등으로 호칭될 수 있다.
한편, 도 70b는 전술한 PIP 시나리오 중 둘째 시나리오와 같이, 한 개의 애플리케이션이 두 개의 비디오 소스를 가짐에 따라 이를 구현한 것으로, 둘 중 제1 비디오 소스가 풀-비디오로 제공되고, 제2 비디오 소스가 PIP 비디오로 제공되는 것이다.
도 71은 도 70a에 도시된 바와 같이, 포어그라운드에 두 개의 애플리케이션이 있는 경우에 PIP 시나리오를 설명하기 위해 도시한 도면이고, 도 72 내지 75는 본 발명의 일 실시 예에 따라 웹 애플리케이션 상에서 PIP 시퀀스를 설명하기 위해 도시한 도면이다.
도 71을 참조하면, 두 개의 애플리케이션이 모두 포어그라운드에 있고 각 애플리케이션이 적어도 하나의 비디오 소스를 가지는 경우를 가정하는데, 전술한 바와 같이 이 경우 PIP 이슈가 발생한다.
관련하여, LSM은 적어도 둘 이상의 포어그라운드 애플리케이션을 지원할 수 있는데, 이 경우 상기 LSM은 어느 애플리케이션이 포어그라운드인지 여부뿐만 아니라 어느 포어그라운드 애플리케이션이 풀-스크린이고 어느 애플리케이션이 PIP 스크린인지도 알 수 있다. 예를 들어, 두 개의 포어그라운드 애플리케이션이 있다면, 제1 애플리케이션은 풀-스크린 애플리케이션으로, 그리고 제2 포어그라운드 애플리케이션은 PIP 애플리케이션이 된다.
따라서, 풀-스크린 애플리케이션의 비디오 소스는 메인 싱크와 연결되고, PIP 스크린의 비디오 소스는 서브 싱크와 연결된다.
LSM은 윈도우 라이프사이클 메시지로 두 개의 타입을 지원할 수 있는데 하나는 포어그라운드를 위한 풀-스크린이고, 다른 하나는 백그라운드를 위한 미니마이즈드이다. 그런데, 만약 전술한 바와 같이, 두 개의 애플리케이션들이 모두 포어그라운드에 있다면, 상기한 윈도우 라이프사이클 메시지의 타입에 기초하면, 모두 풀-스크린 메시지를 받게 된다. 따라서, 이 경우, 상기 윈도우 라이프사이클 메시지만으로는 두 개의 포어그라운드 애플리케이션에 대한 풀-스크린 애플리케이션과 PIP 애플리케이션을 구분할 수 없다.
이에, 도 71에 도시된 바와 같이, 윈도우 라이프사이클의 타입을 풀-스크린, 미드-사이즈드 그리고 미니마이즈드을 정의한다.
여기서, 풀-스크린 타입 메시지는, 풀스크린으로 가는 애플리케이션에 전달된다. 미드-사이즈드 타입 메시지는, PIP로 가는 애플리케이션에 전달된다. 그리고, 미니-마이즈드 타입 메시지는, 백그라운드로 가는 애플리케이션으로 전달된다. 여기서, 미드-사이즈 등의 용어는 임의적인 것으로, 그 밖에 PIP를 위한 다른 용어를 사용할 수도 있다. 따라서, 본 발명의 내용이 상기한 용어에 한정되는 것은 아니다.
그 밖에, 도시되진 않았으나, 윈도우 라이프사이클 타입으로, 포어그라운드 내에서도 포커스(focus)와 언포커스(unfocus) 상태도 정의할 수 있다.
관련하여, 도 63을 참조하여, PIP 이슈를 더욱 상세하게 설명하면, 다음과 같다.
다만, 도 63에서, 백그라운드 애플리케이션은 PIP 애플리케이션으로, 그리고 LSM으로부터 전달되는 미니-마이즈드 메시지는 미드-사이즈드 메시지로 변경된다. 다시 말해, 도 63에서 기술한 포어그라운드 애플리케이션과 백그라운드 애플리케이션에 대한 내용에서 단지 풀-스크린 애플리케이션과 PIP 애플리케이션으로 변경이 된다. 따라서, 상술한 도 63의 내용 중 중복되는 설명은 원용하고, 여기서 상세한 설명은 하지 않으며, 상이한 부분을 위주로 설명한다.
애플리케이션이 미드-사이즈드 메시지를 LSM으로부터 수신하면, 해당 애플리케이션은 PIP 애플리케이션임을 알 수 있다. 따라서, PIP 애플리케이션은, VSM으로 비디오 소스를 서브 싱크와 커넥트 요청한다. 이는 전술한 도 63에서 백그라운드 애플리케이션이 디스커넥트 요청을 하던 내용과 상이하다. 왜냐하면, 백그라운드 애플리케이션은 화면에 출력되지 않아도 되나, PIP 애플리케이션은 화면에 출력이 되기 때문이다.
반대로, 애플리케이션이 풀-스크린 메시지를 LSM으로부터 수신하면, 해당 애플리케이션은 풀-스크린 애플리케이션임을 알 수 있다. 따라서, 풀-스크린 애플리케이션은 VSM으로 비디오 소스를 메인과 커넥트 요청한다. 이는 전술한 포어그라운드 애플리케이션의 동작과 유사하다.
한편, 애플리케이션이 미니-마이즈드 메시지를 받은 경우에는, 해당 애플리케이션은 백그라운드 애플리케이션이 되고, VSM에 비디오 소스와 메인 또는 서브와 디스커넥트 요청을 하는데, 이는 도 63에서 기술한 백그라운드 애플리케이션의 동작과 유사하다.
여기서, PIP 애플리케이션의 경우에 비디오의 스케일링은 어떻게 할 것인지 문제가 발생하는데, 이 역시 PIP 이슈의 하나가 된다. 왜냐하면, PIP 애플리케이션은 자신이 화면 내에 출력할 사이즈와 포지션을 알 수 없다. 이는 단지 LSM만이 디스플레이 상에서 PIP 애플리케이션의 절대 좌표를 알고 있기 때문이다.
따라서, 이를 해소하기 위해서는 LSM이 디스플레이 서비스로 서브 싱크를 위한 리사이즈(resize)를 요청하는 방법 또는 LSM이 애플리케이션으로 미드-사이즈드 메시지를 전송함에 있어서 사이즈와 포지션 정보를 함께 전송하고, 상기 애플리케이션이 서브 싱크를 위한 리사이즈 요청을 디스플레이 서비스로 직접 하는 방법이 있다.
이하, 도 72 내지 75를 참조하여, 두 개의 애플리케이션들이 포어그라운드에 있는 경우에, 웹 애플리케이션에서 PIP 시퀀스 다이어그램에 대해 상세하게 설명한다.
먼저, 도 72를 참조하면, LSM은 애플리케이션의 라이프사이클 메시지를 알고 있다. 따라서, 만약 애플리케이션이 PIP로 가야 하는 경우, LSM은 PIP 애플리케이션 즉, 웹키트로 미드-사이즈드 메시지를 전송하고, 전술한 바와 같이, PIP 애플리케이션의 디스플레이 내 사이즈와 포지션에 대한 좌표 정보를 전송한다.
웹키트는 상기와 같이, LSM으로부터 미드-사이즈드 메시지와 좌표 정보가 수신되면, 상기 미드-사이즈드 메시지에 기초하여 VSM으로 mediaID를 포함하여 디스플레이 엔진 중 메인 싱크와의 디스커넥트를 요청한다. 이때, 상기 웹키드는 상기 디스커넥트 요청과 함께 상기 mediaID를 포함하여 디스플레이 엔진 중 서브 싱크와 커넥트를 요청한다. 한편, 상기 웹키트는 상기 디스커넥트, 커넥트 요청과 동시에 또는 그 이후에 미디어 디스플레이 엔진 중 서브 싱크로 상기 수신한 좌표 정보를 전달하고 설정 요청한다.
애플리케이션이 포어그라운드에 있으나, PIP 애플리케이션이 되면 상술한 시퀀스에 따르게 된다.
도 73은 예컨대, 도 72와 같이, PIP 스크린이 생성 또는 출력이 된 이후에 PIP 스크린이 무브되었을 때 이를 위한 PIP 시퀀스를 설명하고자 한다.
상기와 같이, PIP 스크린이 그 위치가 항상 고정되어 있을 수도 있으나, 디스플레이 내에서 무브할 수도 있다.
이하 상기 경우에 그 처리 시퀀스를 설명한다.
전술한 바와 같이, PIP 애플리케이션은 이 경우에도 여전히 비디오 사이즈와 포지션의 변경 여부를 알 수 없다. 따라서, 그 처리를 위하여, LSM이 무브된 PIP 스크린의 변경 좌표를 다시 웹키트로 전송하고, 웹키트에서 수신된 변경 좌표를 디스플레이 엔진 중 서브로 전달하고 좌표 변경 설정을 요청하면 된다.
다음으로, 도 74는 예를 들어, PIP 애플리케이션이 풀-스크린으로 가는 경우에 시퀀스를 설명하면, 다음과 같다.
PIP 애플리케이션은 역시, 자신이 PIP에서 풀-스크린으로 변경이 되는지 여부를 모르기 때문에, LSM에서 풀-스크린 메시지(라이프사이클 메시지)를 전송하면, 자신이 풀-스크린 애플리케이션이 되었음을 인지한다.
웹키트는, 상기 풀-스크린 메시지가 수신되면, mediaID를 VSM으로 전송하여, 디스플레이 엔지(서브)와의 디스커넥트를 요청하고, 상기 mediaID를 디스플레이 엔진(메인)과 커넥트 요청을 한다.
한편, 웹키트는, LSM의 좌표 정보가 없더라도 풀-스크린이므로, 디스플레이 윈도에 대한 설정을 직접 디스플레이 엔진(메인)으로 요청한다.
도 75를 참조하여, 포어그라운드 애플리케이션이 두 개인 경우, 풀-스크린 애플리케이션과 PIP 애플리케이션에 대한 PIP 시퀀스를 정리하면, 다음과 같다.
PIP 시퀀스에서는 상기에서 비록 미디어 서버나 미디어 파이프라인에 대해서는 비록 별도의 설명을 하지 않았으나, 필요에 따라 전술한 도 66 내지 69에서와 같은 기능을 할 수 있다.
도 75를 보면, 주로 PIP 이슈에서는 LSM, VSM 및 디스플레이 엔진이 이용된다.
도 76은 본 발명의 일 실시 예에 따라 PIP 이슈가 있는 경우에 오디오 처리를 설명하기 위해 도시한 도면이다.
도 76a의 경우에는, 일반적으로 하나의 미디어와 하나의 링톤이 있는 경우에 이를 처리하는 것을 도시하였다.
다시 말해, 미디어 파이프라인 하나와 링톤 파이프라인 하나가 있는 경우에, 오디오 처리부(AudioD, DASS, PusleAudio)는 상기 미디어 파이프라인은 스피커로 출력하고, 링톤 파이프라인은 헤드셋으로 출력하도록 제어한다.
도 76a와 같이, 하나의 미디어와 하나의 링톤이 있는 경우에는 상술한 바와 같이 처리하는 것이 일반적이다. 다만, 본 발명의 PIP 이슈와 같이, 두 개의 애플리케이션이 모두 포어그라운드에 있고, 둘 다 비디오 소스를 가진 경우 즉, 미디어 파이프라인이 두 개인 경우에는 이를 어떻게 처리할 것인지 문제될 수 있다. 예를 들어, 하나의 미디어 파이프라인이 HDMI이고, 다른 하나는 방송인 경우이다.
도 76b는 PIP 이슈에서 오디오 처리에 관한 것이다.
일반적으로, 오디오 처리부는 오디오 타입에 따라 출력부를 결정하는데, 본 발명의 PIP 이슈가 발생한 경우에는 두 개의 포어그라운드 애플리케이션의 오디오 타입들이 동일할 수 있다. 다시 말해, 오디오 타입만으로는 오디오 처리부에서 출력부를 결정하기 어려운 경우가 있을 수 있다.
따라서, 간편하게는, 도 76b에 도시된 바와 같이, 제1 미디어 파이프라인은 오디오 처리부에서 스피커를 통해 출력되도록 제어하고, 제2 미디어 파이프라인은 오디오 처리부에서 헤드셋을 통해 출력되도록 제어할 수 있다.
그러나, 이는 기본적인 오디오 처리부의 폴리시에 어긋나는 예외 처리가 된다. 다시 말해, 오디오 처리부는 기본적으로 오디오 타입에 기초하여 오디오 출력부를 결정하는데 본 발명과 같이, PIP 이슈가 있는 경우에는 상기 오디오 타입에 기초하여 결정할 수 없다.
이 경우, 가장 심플하게는, 도 76b와 같이, 풀-스크린 애플리케이션은 스피커로 출력하고, PIP 스크린 애플리케이션은 헤드셋을 통해 출력하도록 제어할 수 있으나, 전술한 오디오 처리부를 새롭게 정의할 필요가 있다. 다시 말해, PIP 이슈가 있는 경우에는, 오디오 처리부에 의하지 않을 수 있다.
한편, PIP 스크린 애플리케이션은 미디어 파이프라인 생성에도 불구하고, 출력되지 않을 수 있으며, PIP 스크린 애플리케이션이 메인으로 스피커를 통해 출력할 수도 있다.
이하, 도 77 내지 83은 본 발명의 일 실시 예에 따른 비디오를 위한 PIP 윈도우 트랜지션(PIP window transition)에 대해 설명하기 위해 도시한 도면이다. 여기서, PIP 윈도우의 사이즈나 포지션은 본 발명의 이해를 돕고 출원인의 설명의 편의를 위하여 임의의 사이즈와 임의의 포지션을 도시한 것으로, 도시된 바에 한정되는 것은 아니다.
도 77a는, 두 개의 애플리케이션 중 A 애플리케이션은 비디오 소스를 포함하나, B 애플리케이션은 비디오 소스를 포함하지 않는다. 여기서, B 애플리케이션은 포어그라운드에 위치하여 풀-스크린으로 출력되고, A 애플리케이션은 비디오 소스를 포함하나 백그라운드에 위치하여 미니-마이즈드 되었다.
도 77b는, 상기 도 77a 윈도우에서 A 애플리케이션이 디스플레이 엔진의 서브 싱크와 커넥트되어 PIP 윈도우가 포어그라운드 즉, B 애플리케이션이 풀-스크린으로 출력중인 디스플레이 상에서 PIP 윈도우를 통해 비디오 소스가 출력된다. 다만, 이 경우, 도 77a에서 도 77b로 변경에 따라 윈도우 트랜지션이 발생하지는 않는다.
다음으로, 도 78a는, 두 개의 애플리케이션 즉, A 애플리케이션과 B 애플리케이션이 모두 비디오 소스를 포함한 경우이다. 다만, 여기서, 상기 B 애플리케이션은 풀-스크린으로 디스플레이 엔진의 메인과 커넥트되었으나, 상기 A 애플리케이션은 백그라운드로 미니-마이즈드 되어 디스플레이 엔진과 디스커넥트되어 있다.
도 78b는, 상기 도 78a에서 A 애플리케이션이 PIP로 포어그라운드로 옴에 따라 두 개의 비디오 소스를 가진 애플리케이션이 실행되게 된다. 다만, 이미 B 애플리케이션이 디스플레이 엔진의 메인과 커넥트되어 있으므로, A 애플리케이션은 포어그라운드에 위치함에도 불구하고, PIP로 미드-사이즈드 메시지를 받아 디스플레이 엔진의 서브와 연결되어 PIP 윈도우를 통해 A 애플리케이션의 비디오 소스가 출력된다.
도 78a와 78b의 경우에도, 윈도우 트랜지션은 발생하지 않는다.
도 79a는, 두 개의 애플리케이션이 포어그라운드에 있고, A 애플리케이션은 비디오 소스를 포함하여 LSM의 미드-사이즈드 메시지에 따라 디스플레이 엔진의 서브와 커넥트되어 PIP 윈도우로 출력되나, B 애플리케이션은 비디오 소스를 포함하지 않고 풀-스크린이다. 다만, 이 경우에, B 애플리케이션은 비디오 소스를 포함하지 않아 풀-스크린임에 불구하고, 디스플레이 엔진의 메인과 커넥트되어 있지 않고 디스커넥트 상태이다.
도 79b와 같이, 상기 도 79a에서 B 애플리케이션이 비디오 소스를 가지게 되거나 비디오 소스를 포함한 새로운 B 애플리케이션이 실행된 경우, 상기 B 애플리케이션은 풀-스크린 메시지를 받아 VSM을 통해 디스플레이 엔진의 메인과 연결된다.
다만, 여기서도 역시 윈도우 트랜지션이 발생하지 않는다.
다음으로, 도 80a는, 비디오 소스를 포함한 두 개의 애플리케이션 즉, A 애플리케이션은 LSM으로부터 미드-사이즈드 메시지를 받아 VSM을 통해 디스플레이 엔진의 서브와 커넥트되어 PIP 윈도우로 출력되고, B 애플리케이션은 LSM으로부터 풀-스크린 메시지를 받아 VSM을 통해 디스플레이 엔진의 메인과 커넥트되어 풀-스크린으로 출력이 된다.
도 80b에서는, 상기 도 79b와 반대로 B 애플리케이션의 비디오 소스가 종료되었거나 비디오 소스가 없는 새로운 B 애플리케이션이 포어그라운드로 위치한 경우에, B 애플리케이션은 VSM을 통해 기 연결되어 있던 디스플레이 엔진의 메인과 디스커넥트를 한다. 다만, 이 경우에도 윈도우 트랜지션은 없으며, A 애플리케이션은 계속하여 PIP 윈도우를 통해 출력된다.
다음으로, 도 81a는, A 애플리케이션은 비디오 소스를 포함하고, 풀-스크린으로 출력이 되고, B 애플리케이션은 비디오 소스를 포함하지 않고 미니-마이즈드 메시지에 따라 백그라운드에서 실행된다.
도 81b는, 상기 도 81a에서 B 애플리케이션이 풀-스크린 메시지를 받아 포어그라운드에 위치하고, A 애플리케이션은 도 81a에서 비디오 소스를 풀-스크린을 통해 출력하였으나, LSM으로부터 미드-사이즈 메시지를 받아, VSM을 통해 기 연결되어 있던 디스플레이 엔진의 메인과 디스커넥트하고, 다시 서브와 커넥트하여 PIP 윈도우를 통해 출력한다.
이 경우, 도 81a에서 도 81b는 윈도우 트랜지션 효과가 생기게 된다.
또한, 도 82a는, 비디오 소스를 포함한 두 애플리케이션 중 A 애플리케이션은 포어그라운드에서 디스플레이 엔진의 메인과 커넥트되어 풀-스크린으로 출력되고, B 애플리케이션은 미니-마이즈드 메시지에 따라 백그라운드에 위치하고 디스플레이 엔진과 디스커넥트 상태이다.
도 82b는, 상기 도 82a에서, 백그라운드에서 실행 중이던 B 애플리케이션이 LSM으로부터 풀-스크린 메시지를 받아 VSM을 통해 디스플레이 엔진의 메인과 커넥트되어 풀-스크린으로 출력이 되고, 이에 따라 A 애플리케이션은 기 연결중인 디스플레이 엔진의 메인과 디스커넥트되나 LSM으로부터 미드-사이즈드 메시지를 받아 VSM을 통해 디스플레이 엔진의 메인이 아닌 서브와 커넥트되어 PIP 윈도우를 통해 출력된다. 이 경우에는, 도 81과 달리, A 애플리케이션이 비록 도 81a에서 풀-스크린으로 출력되다가 도 81b의 PIP 스크린으로 출력됨에도 불구하고, 윈도우 트랜지션 효과는 발생하지 않는다.
마지막으로, 도 83a는, A 애플리케이션이 비디오 소스를 포함하고 풀-스크린으로 디스플레이 엔진의 메인과 커넥트된 상태에서, 도 83b와 같이 B 애플리케이션이 포어그라운드로 위치하면서 풀-스크린으로 출력되나 상기 B 애플리케이션은 비디오 소스를 포함하고 있지 않으므로 A 애플리케이션은 미드-사이즈드 메시지에 따라 PIP 윈도우로 출력되나 상기 A 애플리케이션이 상기 미드-사이즈드 메시지에도 불구하고 상기 B 애플리케이션이 비디오 소스가 없으므로 계속하여 디스플레이 엔진의 메인과 디스커넥트하지 않고 커넥트 상태로 있으면, 트랜지션 효과가 발생한다.
도 84는 본 발명의 일 실시 예에 따른 상기 PIP 윈도우 트랜지션 과정을 설명하기 위해 도시한 순서도이다.
LSM은 애플리케이션으로 미드-사이즈드 메시지와 PIP 윈도우의 사이즈와 포지션 등에 대한 좌표 정보를 전송한다(S8402).
상기 미드-사이즈드 메시지와 좌표 정보를 수신한 애플리케이션은 홀(hole)을 펀치(punch)하고, 디스플레이 엔진의 서브와 커넥트하고, 상기 커넥트된 디스플레이 엔진의 서브로 좌표에 맞게 비디오 소스를 스케일한다(S8404).
이후 LSM에서 애플리케이션으로 무브 스타트 메시지와 무브된 좌표 정보를 전달하면(S8406), 애플리케이션은 VTG를 획득하고 그린다(draw)(S8408).
애플리케이션에서 LSM으로, 무브 가능 또는 불가능에 대한 응답을 하고(S8410), 만약 상기 응답이 무브 가능이면, LSM은 무브하고(S8412), 상기 무브에 따라 다시 애플리케이션으로 미드-사이즈드 메시지와 무브된 좌표 정보를 전달한다(S8414).
애플리케이션은 상기 LSM의 메시지에 따라 디스플레이 엔진의 서브로 좌표 정보를 전달하고, 상기 좌표 정보에 기초하여 비디오 소스를 스케일할 수 있다(S8416).
도 85는 본 발명의 일 실시 예에 따른 PIP 윈도우 트랜지션 과정 중 무브 시나리오를 설명하기 위해 도시한 도면이다.
먼저, VTG의 우선순위는 예를 들어, 서브 비디오보다 낮을 수 있다.
도 85를 참조하여, 무브 시나리오를 설명하면, 싱글 비디오 즉, 메인 비디오만 존재하는 경우에, 풀-스크린에서 PIP 스크린으로 무브하는 경우, VTG를 사용하여 트랜지션 효과가 발생한다. 또한, 그 반대의 경우 즉, PIP 스크린에서 풀-스크린으로 무브하는 경우에도 역시, VTG를 사용하여 트랜지션 효과가 발생할 수 있다.
그러나, 더블 비디오 즉, 메인과 서브 비디오가 모두 존재하는 경우에는, 풀-스크린에서 PIP 스크린으로 무브하거나 그 반대의 경우에도 VTG를 이용한 트랜지션 효과는 발생하지 않는다. 다만 이 경우, 각 비디오는 단지 PIP 스크린을 위하여 디스플레이 엔진의 서브 싱크와 커넥트될 뿐이다.
이하에서는, 본 발명의 일 실시 예에 따라 PIP 또는 앱온앱의 위치 내지 크기를 인풋 디바이스를 통해 조절하는 UX/UI 시나리오를 설명한다.
도 86 내지 88은 본 발명의 실시 예들에 따른 PIP 윈도우 제어 시나리오를 설명하기 위해 도시한 도면이다.
도 86a은, 디지털 디바이스의 스크린상에 메인 화면과 PIP 화면이 동시에 출력 중인 상태이다. 여기서, 만약 사용자가 리모트 컨트롤러와 같은 인풋 디바이스를 통해 상기 PIP 스크린에 대한 제어 커맨드를 입력하면, 디지털 디바이스는 상기 제어 커맨드에 따라 PIP 스크린을 제어한다.
예를 들어, 도 86a에 도시된 바와 같이, 커서(3610)가 PIP 스크린(8620)의 경계 영역에 위치하면, 디지털 디바이스는 사용자의 의도가 상기 PIP 스크린(8620)의 제어로 인식하여 그에 관련된 다양한 정보 등을 포함한 제어 GUI를 제공할 수 있다.
예를 들어, 도 86b를 참조하면, 상기 도 86a와 같이 커서가 PIP 스크린의 경계 영역에 위치하면, PIP 스크린의 이동 가능한 영역(A1, A2, A3)이 점선 형태로 제공이 된다. 여기서, 사용자가 만약 상기 A1 내지 A3 중 어느 하나의 영역으로 상기 커서를 움직이면, 디지털 디바이스는 기 출력 중인 PIP 스크린을 해당 영역으로 이동하여 계속하여 PIP 스크린을 제공한다.
또는, 디지털 디바이스는, 도 86c에 도시된 바와 같이, 제어 메뉴 GUI(8650)를 제공할 수 있다. 여기서, 상기 제어 메뉴 GUI(8650)는 사이즈 변경(1-100), 위치 변경(Y/N), 채널 변경(a1-z1) 등과 같은 항목을 출력한다. 도시되진 않았으나, 제어 메뉴 GUI(8650)는 메인 화면의 소정 영역에서 메뉴를 호출하는 경우와 동일한 메뉴 항목들을 제공할 수도 있다. 한편, 상기에서 사이즈 변경을 요청하면, 현재 사이즈가 어느 정도인지 표시하고, 표시된 사이즈를 조절하기 위한 조절 키가 제공될 수 있다. 이때, 사용자가 숫자 조절 키를 통해 사이즈에 대응되는 숫자가 입력이 되면, 즉시 반영하여 사용자가 상기 사이즈 변경에 따른 PIP 스크린의 사이즈 변경을 직관적으로 인식 가능하도록 할 수 있다. 또는, 상기 커서가 PIP 스크린의 경계 영역에 위치하면, 상기 도 86c를 통해 또는 바로 PIP 스크린이 하이라이트되면서 사이즈 조절이 가능한 상태로 변경되어 도 87a 또는 87b와 같이 사이즈를 조절할 수 있다. 또한, 상기에서 위치 변경 항목에서 예스(y)를 선택한 경우에는, 도 86b와 같은 변경 가능한 영역에 대한 정보를 제공할 수도 있고, 도 86d와 같이 커서를 변경하여 스크린 내에 어느 영역으로 드래그&드롭의 형태로 상기 PIP 스크린의 위치를 변경 가능하도록 제공할 수 있다. 한편, 도시되진 않았으나, 만약 상기 채널 변경 항목이 선택이 되면, 채널 항목이 스크롤 가능하도록 제공 또는 작은 사이즈의 EPG 스크린이 다른 레이어로 제공되고 선택에 따라 해당 채널로 즉시 변경될 수도 있다. 이 경우, 만약 채널 변경 요청된 채널은, 기존 PIP 스크린은 그대로 유지하면서 상기 선택된 채널에 대한 PIP 스크린을 한 개 더 제공하는 방식으로 처리도 가능하다. 상기 추가되는 PIP 스크린은 예컨대, 도 86b와 같은 형태로 선택받아 선택된 영역에 출력하거나 도 86d와 같이 드래그&드롭 방식으로 처리될 수도 있다.
또는, 인풋 디바이스의 커서가 도 86a와 같이, PIP 경계 영역(또는 사각형 형태의 모서리 영역)으로 이동 시 해당 PIP 스크린은 하이라이트 또는 도 87c와 같이, 상, 하, 좌, 우뿐만 아니라 상 화살표와 좌 화살표 사이의 위 방향을 향하는 비스듬한 제1 화살표, 우 화살표와 하 화살표 사이에서 아래 방향을 향하는 비스듬한 제2 화살표를 제공하는 사이즈 변경 또는 위치 변경 조절 GUI가 제공될 수 있다. 예를 들어, 사용자가 상 화살표를 잡은 상태에서 위로 올리면 화면이 위로 커지고, 아래 화살표를 잡은 상태에서 아래로 내리면 화면이 아래로 작아지고, 제1 화살표를 잡은 상태에서 비스듬한 위 방향으로 올리면 좌, 우가 균일한 비율을 가지면서 커지고, 제2 화살표를 잡은 상태에서 비스듬한 아래 방향으로 내리면 좌, 우가 균일한 비율을 가지면서 작아질 수 있다. 한편, 상기 조절 GUI는 단지 사이즈뿐만 아니라 위치 이동을 위해서도 이용 가능하다.
또는 그냥 모서리 부분에 커서가 가면 화면 사이즈를 조절할 수 있는 아이콘이 도 87d와 같이 생성되어 제공될 수 있다. 예컨대, 커서가 PIP 스크린의 우측 모서리에 위치하면, 우측 모서리에 대해 확장 가능한 아이콘들이 생성되어 제공된다. 또한, 커서가 PIP 스크린의 하단 모서리에 위치하면 하단 모서리에 대해 확장 가능한 아이콘들이 생성되어 제공된다.
그 밖에, 도 88에 도시된 바와 같이, 커서가 PIP 스크린의 하단 모서리에 위치하면, 메뉴가 제공되거나 사용자가 더블 클릭이나 인풋 디바이스의 휠 움직임 레벨에 대응하여 도 88b와 같이, 하단만 확장된 형태로 제공될 수 있다. 이 경우, 확장된 PIP 스크린의 제1 영역에는 계속하여 해당 채널이 제공되고, 제2 영역에는 상기 채널에 대한 상세 정보가 제공되거나 하나 또는 그 이상의 다른 채널이 함께 제공될 수 있다.
반면, 도 88a에서, 커서가 PIP 스크린의 우측 모서리에 위치하고 사용자가 더블 클릭이나 인풋 디바이스의 휠 움직임 레벨에 대응하여 도 88c에 도시된 바와 같이, 우측만 확장된 형태로 제공할 수 있다. 상기 휠 움직임 레벨은 휠을 위로 올리면 점점 확장되고 휠을 아래로 움직이면 점점 감소되는 형태를 말한다. 이때, 디지털 디바이스의 휠 움직임 레벨에 대응하여 직관적으로 인식 가능하도록 휠 움직임마다 바로 확장 또는 감소를 적용할 수 있다. 이때, 각 영역은 전술한 도 88b에서 설명한 내용과 동일하다.
한편, 도 88a에서, 커서가 PIP 스크린의 좌측 모서리나 상단 모서리에 위치하고, 사용자가 더블 클릭이나 인풋 디바이스의 휠을 움직이면, 도 88d와 같이, 전체 스크린 영역 중 상기 PIP 스크린이 속한 1/2 영역만큼 상기 PIP 스크린이 확장될 수 있다. 이 경우, 상기 PIP 스크린은 기존 PIP 스크린은 유지되면서, 상기 PIP 스크린이 속하지 않은 영역에 PIP 스크린이 확장되거나 새로운 PIP 스크린이 생성되어 제공될 수도 있다. 도 88d의 영역 역시 전술한 방식대로 처리 가능하다.
이때, 도 88a를 참조하면, PIP 스크린이 좌측 상단 모서리에 위치하는 관계로, 도 88a의 모서리에 대한 커서의 제어가 전술한 바와 같으나, 이에 한정되지 않는다. 다시 말해, 커서와 모서리에 따른 제어 과정은 PIP 스크린의 위치 등에 따라 동일한 메커니즘에 따라 적용 가능하다.
도 89는 본 발명의 일 실시 예에 따른 PIP 처리 방법을 설명하기 위해 도시한 순서도이다.
포어그라운드에 복수의 애플리케이션들이 있는 경우, 제1 애플리케이션과 제2 애플리케이션의 각 웹키트로 각각 제1 라이프사이클 메시지와 제2 라이프사이클 메시지와 상기 제2 애플리케이션의 디스플레이 내 사이즈와 포지션에 대한 좌표 정보를 전송한다(S8902).
상기 제1 애플리케이션의 웹키트에서 수신된 식별자에 기초하여 디스플레이 엔진과 커넥트를 VSM에 요청한다(S8904).
상기 제1 애플리케이션을 디스플레이 엔진의 메인 싱크와 연결한다(S8906). 상기 제2 애플리케이션의 웹키트에서 수신된 식별자에 기초하여 커넥트를 상기 VSM에 요청한다(S8908).
상기 제2 애플리케이션을 상기 디스플레이 엔진의 서브 싱크와 연결하고(S8910), 상기 제2 애플리케이션의 웹키트에서 수신된 좌표 정보를 상기 서브 싱크로 전송한다(S8912).
상기 포어그라운드에 있는 복수의 애플리케이션의 비디오 소스를 출력한다(S8914).
상기에서, 라이프사이클 메시지는, 풀-스크린 메시지, 미드-사이즈드 메시지 및 미니마이즈드 메시지 중 적어도 하나일 수 있으며, 상기 미드-사이즈드 메시지는, 해당 애플리케이션을 PIP 스크린에서 실행하도록 제어하기 위한 메시지이고, 상기 미니마이즈드 메시지는 해당 애플리케이션을 백그라운드로 실행하도록 제어하기 위한 것이다.
상기에서, 서브 싱크에 따른 디스플레이 윈도우가 무브된 경우, 상기 무브에 따른 라이프사이클 메시지와 변경된 좌표 정보를 상기 제2 애플리케이션의 웹키트로 전송할 수 있다.
또한, 상기 제2 애플리케이션의 웹키트는, 상기 무브 메시지와 변경된 좌표 정보에 따라 상기 VSM에 상기 서브 싱크와의 디스커넥트를 요청하지 않고, 상기 서브 싱크로 변경된 좌표 정보만을 전달하여 디스플레이 윈도우를 변경된 좌표 정보에 따라 설정할 수 있다. 상기 제2 애플리케이션의 웹키트는, 상기 LSM으로부터 라이플사이클 메시지로 풀-스크린 메시지를 수신하면, 기 연결된 상기 서브 싱크와 디스커넥트를 상기 VSM으로 요청하고, 상기 VSM으로 상기 메인 싱크와 커넥트를 요청할 수도 있다. 그리고 상기 제2 애플리케이션의 웹키트는, 상기 메인 싱크로 디스플레이 윈도우 설정을 요청할 수도 있다.
한편, 상기 라이프사이클 메시지 중 미드-사이즈드 메시지와 무브 메시지를 전송하는 경우에만, 상기 LSM에서 해당 좌표 정보도 함께 전송할 수 있다.
그리고, 상기 제1 애플리케이션 또는 제2 애플리케이션이 풀-스크린으로 출력되다가 PIP 스크린으로 출력 변경되는 경우에는, 윈도우 트랜지션이 발생할 수 있다. 상기에서, 제1 애플리케이션과 제2 애플리케이션 중 적어도 하나의 애플리케이션은, 비디오 소스를 포함할 수 있다.
본 명세서에서 개시하는 웹OS가 탑재된 디지털 디바이스 및 상기 디지털 디바이스에서 서비스 또는 애플리케이션 처리 방법은 상기 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 명세서에서 개시된 디지털 디바이스의 동작방법은 디지털 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 디바이스를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM(Read Only Memory), RAM(Random Access Memory), CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장 디바이스 등이 있으며, 인터넷을 통한 전송 등과 같은 캐리어-웨이브(carrier-wave)의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
한편, 본 명세서에서는 첨부된 도면을 참조하여 설명하였으나, 이는 실시 예일 뿐 특정 실시 예에 한정되지 아니하며, 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 변형실시가 가능한 다양한 내용도 청구범위에 따른 권리범위에 속한다. 또한, 그러한 변형실시들이 본 발명의 기술 사상으로부터 개별적으로 이해되어서는 안 된다.
본 발명은 디지털 디바이스에 관한 것으로, 디지털 디바이스를 이용하는 산업 전반에 걸쳐 이용 가능하다.

Claims (20)

  1. 포어그라운드(foreground)에 복수의 애플리케이션들이 있는 경우, 제1 애플리케이션과 제2 애플리케이션의 각 웹키트(webkit)로 각각 제1 라이프사이클 메시지(liftcycle message)와 제2 라이프사이클 메시지와 상기 제2 애플리케이션의 디스플레이 내 사이즈(size)와 포지션(position)에 대한 좌표 정보(coodinate information)를 전송하는 디스플레이 처리부;
    상기 제1 애플리케이션을 위한 메인 싱크(main sink)와 상기 제2 애플리케이션을 위한 서브 싱크(sub sink)를 포함한 디스플레이 엔진부; 및
    상기 제1 애플리케이션의 웹키트로부터 수신한 식별자와 커넥트 요청에 따라 상기 제1 애플리케이션을 상기 디스플레이 엔진의 메인 싱크와 연결하고, 상기 제2 애플리케이션의 웹키트로부터 수신한 식별자와 커넥트 요청에 따라 상기 제2 애플리케이션을 상기 디스플레이 엔진의 서브 싱크와 연결하는 비디오 처리부를 포함하여 포어그라운드에 있는 복수의 애플리케이션의 비디오 소스를 출력하는 디지털 디바이스.
  2. 제1항에 있어서,
    상기 라이프사이클 메시지는,
    풀-스크린(full-screen) 메시지, 미드-사이즈드(mid-sized) 메시지 및 미니마이즈드(minimised) 메시지 중 적어도 하나인 것을 특징으로 하는 디지털 디바이스.
  3. 제2항에 있어서,
    상기 미드-사이즈드 메시지는, 해당 애플리케이션을 PIP 스크린에서 실행하도록 제어하기 위한 메시지이고, 상기 미니마이즈드 메시지는 해당 애플리케이션을 백그라운드로 실행하도록 제어하기 위한 것을 특징으로 하는 디지털 디바이스.
  4. 제1항에 있어서,
    상기 디스플레이 처리부는,
    상기 서브 싱크에 따른 디스플레이 윈도우가 무브된 경우, 상기 무브에 따른 라이프사이클 메시지와 변경된 좌표 정보를 상기 제2 애플리케이션의 웹키트로 전송하는 것을 특징으로 하는 디지털 디바이스.
  5. 제4항에 있어서,
    상기 웹키트는,
    상기 무브 메시지와 변경된 좌표 정보에 따라 상기 비디오 처리부에 상기 서브 싱크와의 디스커넥트를 요청하지 않고, 상기 서브 싱크로 변경된 좌표 정보만을 전달하여 디스플레이 윈도우를 변경된 좌표 정보에 따라 설정하는 것을 특징으로 하는 디지털 디바이스.
  6. 제2항에 있어서,
    상기 제2 애플리케이션의 웹키트는,
    상기 디스플레이 처리부로부터 라이플사이클 메시지로 풀-스크린 메시지를 수신하면, 기 연결된 상기 서브 싱크와 디스커넥트를 상기 비디오 처리부로 요청하고, 상기 비디오 처리부로 상기 메인 싱크와 커넥트를 요청하는 것을 특징으로 하는 디지털 디바이스.
  7. 제6항에 있어서,
    상기 제2 애플리케이션의 웹키트는,
    상기 메인 싱크로 디스플레이 윈도우 설정을 요청하는 것을 특징으로 하는 디지털 디바이스.
  8. 제2항에 있어서,
    상기 디스플레이 처리부는,
    상기 라이프사이클 메시지 중 미드-사이즈드 메시지와 무브 메시지를 전송하는 경우에만, 해당 좌표 정보도 함께 전송하는 것을 특징으로 하는 디지털 디바이스.
  9. 제2항에 있어서,
    상기 제1 애플리케이션 또는 제2 애플리케이션이 풀-스크린으로 출력되다가 PIP 스크린으로 출력 변경되는 경우에는, 윈도우 트랜지션이 발생하는 것을 특징으로 하는 디지털 디바이스.
  10. 제9항에 있어서,
    상기 제1 애플리케이션과 제2 애플리케이션 중 적어도 하나의 애플리케이션은, 비디오 소스를 포함하는 것을 특징으로 하는 디지털 디바이스.
  11. 포어그라운드에 복수의 애플리케이션들이 있는 경우, 디스플레이 처리부에서 제1 애플리케이션과 제2 애플리케이션의 각 웹키트로 각각 제1 라이프사이클 메시지와 제2 라이프사이클 메시지와 상기 제2 애플리케이션의 디스플레이 내 사이즈와 포지션에 대한 좌표 정보를 전송하는 단계;
    상기 제1 애플리케이션의 웹키트에서 수신된 식별자에 기초하여 디스플레이 엔진과 커넥트를 비디오 처리부에 요청하는 단계;
    상기 제1 애플리케이션을 디스플레이 엔진의 메인 싱크와 연결하는 단계;
    상기 제2 애플리케이션의 웹키트에서 수신된 식별자에 기초하여 커넥트를 상기 비디오 처리부에 요청을 하는 단계;
    상기 제2 애플리케이션을 상기 디스플레이 엔진의 서브 싱크와 연결하는 단계;
    상기 제2 애플리케이션의 웹키트에서 수신된 좌표 정보를 상기 서브 싱크로 전송하는 단계; 및
    상기 포어그라운드에 있는 복수의 애플리케이션의 비디오 소스를 출력하는 단계를 포함하여 이루어지는 디지털 디바이스에서 애플리케이션 처리 방법.
  12. 제11항에 있어서,
    상기 라이프사이클 메시지는,
    풀-스크린 메시지, 미드-사이즈드 메시지 및 미니마이즈드 메시지 중 적어도 하나인 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  13. 제12항에 있어서,
    상기 미드-사이즈드 메시지는, 해당 애플리케이션을 PIP 스크린에서 실행하도록 제어하기 위한 메시지이고, 상기 미니마이즈드 메시지는 해당 애플리케이션을 백그라운드로 실행하도록 제어하기 위한 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  14. 제11항에 있어서,
    상기 서브 싱크에 따른 디스플레이 윈도우가 무브된 경우, 상기 무브에 따른 라이프사이클 메시지와 변경된 좌표 정보를 상기 제2 애플리케이션의 웹키트로 전송하는 단계를 더 포함하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  15. 제14항에 있어서,
    상기 제2 애플리케이션의 웹키트는,
    상기 무브 메시지와 변경된 좌표 정보에 따라 상기 비디오 처리부에 상기 서브 싱크와의 디스커넥트를 요청하지 않고, 상기 서브 싱크로 변경된 좌표 정보만을 전달하여 디스플레이 윈도우를 변경된 좌표 정보에 따라 설정하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  16. 제12항에 있어서,
    상기 제2 애플리케이션의 웹키트는,
    상기 디스플레이 처리부로부터 라이플사이클 메시지로 풀-스크린 메시지를 수신하면, 기 연결된 상기 서브 싱크와 디스커넥트를 상기 비디오 처리부로 요청하고, 상기 비디오 처리부으로 상기 메인 싱크와 커넥트를 요청하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  17. 제16항에 있어서,
    상기 제2 애플리케이션의 웹키트는,
    상기 메인 싱크로 디스플레이 윈도우 설정을 요청하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  18. 제12항에 있어서,
    상기 라이프사이클 메시지 중 미드-사이즈드 메시지와 무브 메시지를 전송하는 경우에만, 상기 디스플레이 처리부에서 해당 좌표 정보도 함께 전송하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  19. 제12항에 있어서,
    상기 제1 애플리케이션 또는 제2 애플리케이션이 풀-스크린으로 출력되다가 PIP 스크린으로 출력 변경되는 경우에는, 윈도우 트랜지션이 발생하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
  20. 제19항에 있어서,
    상기 제1 애플리케이션과 제2 애플리케이션 중 적어도 하나의 애플리케이션은,
    비디오 소스를 포함하는 것을 특징으로 하는 디지털 디바이스에서 애플리케이션 처리 방법.
PCT/KR2015/001087 2014-02-26 2015-02-03 디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법 WO2015130022A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/121,867 US9813766B2 (en) 2014-02-26 2015-02-03 Digital device and data processing method by digital device

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201461945078P 2014-02-26 2014-02-26
US61/945,078 2014-02-26
KR1020140131938A KR102225946B1 (ko) 2014-02-26 2014-09-30 디지털 디바이스 및 상기 디지털 디바이스에서 애플리케이션 처리 방법
KR1020140131939A KR102311248B1 (ko) 2014-02-26 2014-09-30 디지털 디바이스 및 상기 디지털 디바이스에서 비디오 데이터 처리 방법
KR10-2014-0131939 2014-09-30
KR10-2014-0131938 2014-09-30

Publications (1)

Publication Number Publication Date
WO2015130022A1 true WO2015130022A1 (ko) 2015-09-03

Family

ID=54009297

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/001087 WO2015130022A1 (ko) 2014-02-26 2015-02-03 디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법

Country Status (1)

Country Link
WO (1) WO2015130022A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113485705A (zh) * 2021-06-30 2021-10-08 深圳软牛科技有限公司 基于QML Rectangle组件的选框方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120011137A (ko) * 2010-07-28 2012-02-07 엘지전자 주식회사 이동 단말기 및 멀티 태스킹 제어 방법
KR20130048290A (ko) * 2010-04-07 2013-05-09 애플 인크. 기회적 멀티태스킹
KR20130127423A (ko) * 2010-07-13 2013-11-22 톰슨 라이센싱 멀티미디어 애플리케이션을 위한 pip 방법
KR20140001120A (ko) * 2012-06-27 2014-01-06 삼성전자주식회사 단일 스크린과 다중 전경 처리를 위한 태스크 방법 및 그 전자 장치
KR20140022764A (ko) * 2010-10-18 2014-02-25 실리콘 이미지, 인크. 동시 디스플레이를 위한 상이한 차원의 비디오 데이터 스트림들의 결합

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130048290A (ko) * 2010-04-07 2013-05-09 애플 인크. 기회적 멀티태스킹
KR20130127423A (ko) * 2010-07-13 2013-11-22 톰슨 라이센싱 멀티미디어 애플리케이션을 위한 pip 방법
KR20120011137A (ko) * 2010-07-28 2012-02-07 엘지전자 주식회사 이동 단말기 및 멀티 태스킹 제어 방법
KR20140022764A (ko) * 2010-10-18 2014-02-25 실리콘 이미지, 인크. 동시 디스플레이를 위한 상이한 차원의 비디오 데이터 스트림들의 결합
KR20140001120A (ko) * 2012-06-27 2014-01-06 삼성전자주식회사 단일 스크린과 다중 전경 처리를 위한 태스크 방법 및 그 전자 장치

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113485705A (zh) * 2021-06-30 2021-10-08 深圳软牛科技有限公司 基于QML Rectangle组件的选框方法、装置、设备及存储介质
CN113485705B (zh) * 2021-06-30 2023-11-21 深圳软牛科技有限公司 基于QML Rectangle组件的选框方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
WO2015099343A1 (ko) 디지털 디바이스 및 그 제어 방법
WO2017003022A1 (ko) 디스플레이 디바이스 및 그 제어 방법
WO2016085070A1 (ko) 디바이스 제어 시스템, 디지털 디바이스 및 디지털 디바이스 제어 방법
WO2016104907A1 (ko) 디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법
WO2016085094A1 (ko) 멀티미디어 디바이스 및 그 제어 방법
WO2016186254A1 (ko) 디스플레이 디바이스 및 그 제어 방법
WO2016027933A1 (ko) 디지털 디바이스 및 그 제어 방법
WO2016143965A1 (en) Display device and controlling method thereof
WO2017034065A1 (ko) 디스플레이 디바이스 및 그 제어 방법
WO2016175361A1 (ko) 디스플레이 디바이스 및 그 제어 방법
WO2016175356A1 (ko) 디지털 디바이스 및 디지털 디바이스 제어 방법
WO2011126202A1 (en) Image display apparatus and method for operating the same
WO2012026651A1 (en) Method for synchronizing contents and display device enabling the method
WO2011136458A1 (en) Image display apparatus and method for operating the same
WO2017135585A2 (en) Main speaker, sub speaker and system including the same
WO2011132840A1 (en) Image display apparatus and method for operating the same
WO2012074197A1 (en) Method for sharing messages in image display device and image display device for the same
WO2012046928A1 (ko) 디스플레이 디바이스를 이용한 광고 컨텐츠 제작 방법 및 그에 따른 디스플레이 디바이스
EP2612504A1 (en) Image display apparatus and method for operating the same
WO2017200215A1 (en) Digital device and controlling method thereof
WO2012074189A1 (ko) 화면 표시 제어 방법 및 그를 이용한 영상 표시 기기
WO2012070742A1 (ko) 애플리케이션 설치 방법 및 그를 이용한 영상 표시 기기
EP2612505A1 (en) Image display apparatus and method for operating the same
WO2017034298A1 (ko) 디지털 디바이스 및 상기 디지털 디바이스에서 데이터 처리 방법
WO2017047868A1 (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: 15754838

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15121867

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 15754838

Country of ref document: EP

Kind code of ref document: A1