YouView Core Technical Specification 1.0

YouView Core Technical SpecificationFor Launch Version 1.0 14 April 2011 Intellectual Property Notice YouView TV Ltd reserves all rights, title and interest in this document, its contents and subject matter. Any comments, suggestions or feedback offered to YouView TV Ltd is done on the understanding that YouView TV Ltd may freely use, disclose, reproduce, license and distribute such feedback as it sees fit. © YouView TV Ltd (2011) Page 2 of 229 YouView Core Technical Specification Table of Contents 1 1.1 1.2 1.3 1.4 This Document Introduction Relationship to DTG D-Book 7 Implementation Typographical conventions 11 11 11 12 12 Chapter I 1. 2. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. Overview Chapter Summary Consumer Device Operating Environment Summary of Core Requirements Consumer Device Hardware Consumer Device Software Consumer Device Software Management Consumer Device Storage Management Consumer Device UI Model Content Delivery and Content Protection UI Management and Presentation Engine Integration Diagnostics and Reporting Platform metadata Accessibility 13 14 15 16 16 16 16 17 17 17 17 18 18 18 Chapter II 1. 1.1. 2. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12. 3.13. 3.14. Consumer Device Platform Chapter Summary Chapter audience Device Platform Summary Core Consumer Device Platform Silicon Connectivity Internal storage Power management Noise constraints Operating system Standard libraries DirectFB requirements Graphics layers HTTP client library (libcurl) A/V handling Device software upgrade Security Automatic reset 21 22 22 23 26 26 26 27 28 28 28 29 30 32 33 33 38 39 39 © YouView TV Ltd (2011) Page 3 of 229 YouView Core Technical Specification 3.15. 4. 4.1. 4.2. 4.3. 4.4. Front panel buttons, indicators and displays User Input Device User input functions Additional control codes Physical requirements Keyboard input 39 40 40 41 41 42 Chapter III 1. 1.1. 2. 3. 3.1. 3.2. 3.3. 4. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 5. 5.1. Consumer Device Software Architecture Chapter Summary Chapter audience Introduction Software Architecture Overview Logical Architecture Design goals Device Operating System Message Bus Message Bus Overview Supported Message Buses Message types Error handing D-Bus security Message Bus Usage Message Bus C++ Bindings D-Bus Specification Device Operation Time 43 44 44 45 46 46 46 47 48 48 48 48 48 48 48 49 49 50 50 Chapter IV 1. 1.1. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 3. 3.1. 4. Consumer Device IP Networking Chapter Summary Chapter audience IP Network Stack Core specification IPv4 configuration Multicast IPv6 Performance HTTP profile Proxy support IP Resource Management Introduction Back-off Mechanism for HTTP Requests 53 54 54 55 55 55 55 55 55 56 57 58 58 59 © YouView TV Ltd (2011) Page 4 of 229 2.1.2. 6.3. Consumer Device Software Management Chapter Summary Audience Software and Configuration Management Overview Core Device Software Platform Software Device configuration Initial device state Update in the field Automatically checking for updates Core Device Software update Overview Checking for an updated version of Core Device Software Acquiring an updated version Core Device Software Verifying an updated version of Core Device Software Installing an updated version of Core Device Software Activating an updated version of Core Device Software Platform Software update Overview Checking for an updated version of Platform Software Acquiring an updated Platform Software Image Verifying an updated Platform Software Image Installing an updated version of Platform Software Activating an installed version of Platform Software Platform Software packaging format Device configuration Overview Acquiring updated configuration Verifying updated configuration Installing updated configuration Configuration packaging format 67 68 68 69 69 69 69 69 71 72 72 74 74 74 74 74 74 74 75 75 75 77 77 78 79 79 82 82 83 86 87 87 © YouView TV Ltd (2011) Page 5 of 229 .7. 7.3. 2. 1. 4.3. 3.1. 7.1. 5. 7.1. 6. 5. 6.4.2.5. 7. 7. 5.4.1.2. Consumer Device UI Model Chapter Summary Chapter audience Device UI Model Overview UI Model Implementation Introduction Setup and Settings Platform Main UI Content Provider applications 61 62 62 63 64 64 64 65 66 Chapter VI 1.2. 3. 5.6.YouView Core Technical Specification Chapter V 1. 2.4. 3. 2.5.1. 5. 3. 2.2. 5. 6.1. 6. 6.1. 4.3. 2. 1.5. 5.4. 3. 6.3. 7.4. 6.6. 3. 2. IP Content Delivery Chapter Summary Chapter audience Streaming Protocols Introduction HTTP progressive download Adaptive bitrate streaming over HTTP Live streaming using UDP Content Download Introduction HTTP content download Storage of downloaded content Content Formats Codecs 101 102 102 103 103 103 109 112 113 113 113 113 114 114 © YouView TV Ltd (2011) Page 6 of 229 .6. 3. 2.5.2.1.4.3. 2. 1. 4.3. Consumer Device Storage Management Chapter Summary Audience Storage Types Writeable storage types Read-only software images Storage of permanent data Start-up after storage partitions have been cleared Replacement of integrated storage Backup copies of Core Device Software Factory Reset function Initiating the Factory Reset function Scope of the Factory Reset function Effect of the Factory Reset function Clear Private Data function Initiating the Clear Private Data function Scope of the Clear Private Data function Effect of the Clear Private Data function Effect of Factory Reset and Clear Private Data 89 90 90 91 91 91 91 91 91 91 92 92 92 92 93 93 93 93 94 Chapter VIII 1. 2.1.1. 2.1.3. 3. 2.1. 3.2. 2.2. 4. 2. 3. 3.2. 4. 3.3. 4. 3. 1. 4.3. Broadcast Content Delivery Chapter Summary Audience D-Book Compatibility MHEG-5 Extensions Launching IP-delivered applications from broadcast services Receiving launch parameters set from non-MHEG applications Feature discovery 95 96 96 97 98 98 99 100 Chapter IX 1.YouView Core Technical Specification Chapter VII 1.1.4. 2. 1. 3.2.2.1.3. 2.1. 3. 3. 5. 2. 3. 2.1.1. 4. 3. 2. 2.1.4.2.8. 5. 3.3.YouView Core Technical Specification 4. 3. 2.9. 3. 4.10. 2.3. 3. 7.6. 3.4. 6.1. 6. MPEG-2 single program transport stream MP4 container Timed Text subtitles Audio elementary streams 114 114 118 121 Chapter X 1. 3.4. 3.2.1.1. 6.4.7. 2. Content Protection : AV Over IP Chapter Summary Chapter audience Introduction Content protection mechanisms No protection Simple device authentication Device authentication using MS3 Device authentication and transport encryption Device authentication and encrypted content delivery DRM protected content Personalisation Device architecture for content protection and DRM Output controls Protected content formats 123 124 124 125 126 126 126 128 129 131 132 135 135 136 138 Chapter XI 1. 3. 3. 3. 6.5. 1. Content Acquisition And Management Chapter Summary Introduction The conceptual model Acquisition subsystem architecture Linear Acquisition (DVR) Overview Bookings and Scheduled Recordings Making a Booking Bookings management Determining which Events to acquire Acquisition Post-acquisition handling IP Downloader The Acquisition Manager General Architecture Local Media Library General Reporting available storage space Metadata storage Storage management Push-VOD for IP Mitigation 141 142 143 143 143 144 144 144 146 147 148 149 151 153 154 154 154 155 155 155 155 156 157 © YouView TV Ltd (2011) Page 7 of 229 . 3.7. 3. 3.3.6. 3.5. 5. 2.5.1. 4. 3.2. 3. 3. 3.2. 4.3. 4. 5.1. 3. 6.2. 1. 2.2. 4. 6. 4.1.1. 5. 5.1. 1.2. 5. 3. 4.2.4. 4. 3.3.3. 6. Consumer Device UI Management Chapter Summary Audience Introduction Definition of terms UIME Overview UIME internal architecture Configuration Application Player Manager Introduction UIME Started Application Players Externally Started Application Players Application Manager Introduction UIME Launched Applications Externally Launched Applications Platform UI Applications 171 172 172 173 173 175 175 175 177 177 177 179 181 181 181 183 184 © YouView TV Ltd (2011) Page 8 of 229 .2.YouView Core Technical Specification 7. 3. 2. 4. 5. 6.2.1. 3. Application Discovery And Installation Chapter Summary Overview Classes of Application Explicit Application discovery Implicit Application discovery Application discovery and installation architecture Overview Device capabilities Conceptual model Application discovery Installing Applications on the device Application download Application verification Storage Selecting and launching an Application Management and update of installed Applications Checking for an updated version Periodic check for updates Update process Factory Reset and Application data Uninstalling Applications Storage 159 160 161 162 162 162 163 163 164 164 165 166 166 166 166 167 168 168 168 169 169 170 170 Chapter XIII 1. 3. 6.3. 2.1.1. 3. 7.1.1. 4.2.1. 5. 5. 2.4.4. Introduction Reserved storage for Push-VOD 157 157 Chapter XII 1.3.2.1. 4. 7. 3. 7. 2.3. 2.2. 3.3. 4. 6. 4. 2.2. 7.3. 2.3. 1.3. 4. Window Manager Introduction Window lifecycle User Input Event dispatch Window Property Manipulation UI Manager Introduction Viewer Perceived Device State Configuration Application Player Manager configuration Application Manager configuration Window Manager configuration Application Policy Resource Management Management of available memory Management of available CPU Watchdog functions 185 185 185 186 187 190 190 190 191 191 191 191 191 192 192 192 192 Chapter XIV 1.1.3.1. 7. 7.2. 6.1. 3. 6.1. 3. 7.2. 6. 4. 9. 2.2. 5. Presentation Engine Integration Chapter Summary Chapter audience Operating System Integration Graphics Acceleration DirectFB integration Bitmap rendering Caching of rendered graphics Audio and Video Overview Presentation Display composition Resource management User Input Fonts Networking 195 196 196 197 198 198 199 200 201 201 201 201 202 203 206 207 Chapter XV 1.4.4. 2. 2. 1. 6. 3. 4. 4. MHEG Integration Chapter Summary Chapter audience Graphics Acceleration DirectFB integration Graphics rendering Font rendering Graphics plane state 209 210 210 211 211 211 211 211 © YouView TV Ltd (2011) Page 9 of 229 .3.1. 9.YouView Core Technical Specification 6. 6.2.3.4. 3. 8. 2.2. 8. 8. 9.1. 8.4. 9.1.1.1.2. 8. 2.2. Consumer Device Local Diagnostics Chapter Summary Chapter audience Local Diagnostics within the Platform Main UI 217 218 218 219 Chapter XVII 1. Channel Tuning User Input DirectFB to MHEG key mappings User input register Networking Application Lifecycle UIME can kill an MHEG application UIME is notified of an MHEG application UIME is notified that an MHEG application has quit Launching other applications Receiving launch parameters 212 213 213 214 215 216 216 216 216 216 216 Chapter XVI 1. 6. 2.1. 6. 4. 2. 5.1. 6. 6.1.YouView Core Technical Specification 3. 3. Consumer Device Usage And Error Reporting Chapter Summary Overview Usage data Error data Privacy considerations Usage and error reporting architecture Introduction Usage Collection Agent Exporters 221 222 223 223 223 223 225 225 225 225 Chapter XVIII Annexes Annex A Annex B Related Documents Glossary 227 228 229 © YouView TV Ltd (2011) Page 10 of 229 . 3. 4. 2. 1. 6. 6.4. 4.3.2.3. 3.3.2. 3.5.2.1.1. 2. The aim is to maximise the common underlying technology that underpins a range of platforms. Harmonisation with other European standardisation activity has been sought with HbbTV and the EBU through close liaison via the DTG and more directly where appropriate. a manufacturer will also be able to determine the scale and scope of work effort and expertise required. For details on how to engage with us please visit www. 1. We‟ve made this specification available here. The technologies described in this final core technical specification for launch are intrinsic to the first YouView devices. secure and robust experience for the viewer.1 Introduction At YouView. and information on IP-delivery of content and device configuration that are relevant to ISPs. there are useful elements covering content formats and content protection that will be of interest to Content Providers. In addition to these key interoperability elements. For clarity. But making this happen isn‟t easy. we‟re committed to helping develop common technical standards for connected TV. it is necessary for manufacturers to work closely with YouView to ensure that different devices operating within this environment deliver a performant. To assist manufacturers who want to make a YouView branded device.YouView Core Technical Specification 1 This Document 1.com/industry/devices Whilst this document is primarily intended for manufacturers.youview. Common standards also mean content providers can more easily share their content widely across any connected TV device. this specification in isolation does not enable a manufacturer to build a YouView branded device. we have provided additional insight into YouView specific areas to give a greater clarity and guidance through example implementation detail. it requires not only knowledge and ability but also a willingness and commitment to participate in such an activity. Such standards bring significant advantages. By publishing this YouView Core Technical Specification we are giving industry visibility of the technologies within a YouView device. In this document we provide the specification of a set of technologies to enable the delivery of broadcast and IP delivered content onto a television set via a broadband connected device. This specification covers the overall architecture of the YouView consumer device as well as the interfaces that promote content interoperability. to help device manufacturers bring products to market utilising the same underlying technologies as a YouView device – regardless of whether or not they choose to use our brand. cheaper devices and more choice for consumers. thereby promoting further the commonality across connected TV implementations. and be part of a wider ecosystem. primarily as members of the Digital Television Group (DTG) in the development of the D-Book and connected TV standards. This will help create a competitive market for connected TV devices in the UK and beyond which means more innovation. This engagement enables the integration of the YouView platform user interface and ensures compatibility with YouView back-end services. by identifying where their existing device architectures may differ from the YouView architecture. including YouView.2 Relationship to DTG D-Book 7 This document makes use of many existing and emerging standards and widely references the DTG D-Book 7 which is the detailed interoperability specification for digital terrestrial television with extended Connected TV functionality. From this document. YouView and our partners have invested heavily in researching and developing the enabling technology for connected TV. We‟ve also been very active in industry standardisation. the specification provides our minimum hardware requirements. allowing any manufacturer to maximise their investment by re-using their developments in complex technologies across multiple markets. Due to the complexities inherent in the nascent connected TV environment. allowing an informed choice to be made about underlying hardware components. D-Book 7 is divided into two parts: © YouView TV Ltd (2011) Page 11 of 229 . Such alternative means will meet the specification provided the required functionality is delivered. which is not required for launch. 1.4 Typographical conventions The formatting listed in the table below identifies special information in the text. An 'Editor‟s note' indicating the current status of a section of the specification text or highlighting a known area of future work. which has been finalised by the DTG. YouView will simplify this specification by referencing relevant parts of D-Book 7 Part B. Whilst we provide detailed suggestions as to implementation. After the launch of YouView and once D-Book 7 Part B has been published in a non-beta form.YouView Core Technical Specification   Part A. Table 1 : Typographic Conventions Monospace Italicised grey Surrounding box © YouView TV Ltd (2011) Page 12 of 229 . whilst maintaining the functionality currently defined here. the UK broadcast specification Part B. for technical or other reasons. Formatting conventions Information type This indicates the names of commands.9. the architecture and protocols which may be used for interoperable IP delivered services in the UK This YouView specification currently references D-Book Part A v1. Manufacturers may. This is for information only and indicates intended future functionality. and directories. these are suggestions only. files. need or decide to meet the specified functionality requirements by alternative means.3 Implementation The goal of these specifications is to ensure that certain functionality requirements are attained. It doesn‟t currently reference Part B which at the time of writing has been published as a beta v0. 1. YouView Core Technical Specification Chapter I Overview © YouView TV Ltd (2011) Page 13 of 229 . Chapter Summary This chapter describes the operating environment in which a YouView consumer device will be deployed. and in doing so introduces the areas of specification covered by this document. © YouView TV Ltd (2011) Page 14 of 229 .YouView Core Technical Specification 1. Figure 1 : Consumer Device Operating Environment © YouView TV Ltd (2011) Page 15 of 229 . Consumer Device Operating Environment The following figure illustrates the operating environment of a YouView consumer device.YouView Core Technical Specification 2. to ensure that the consumer device always has a “safe” combination of software elements to fall back on in the event of any problems. distributed and managed by Content Providers. the Platform Operator and (with suitable consent) the relevant ISP. © YouView TV Ltd (2011) Page 16 of 229 . Platform Software will only run with a compatible version of the Core Device Software. access to linear TV. It contains all native code that runs on the device.2. This is built. Manufacturer. The consumer device must be deployed with a default set of configuration data. 3. existing industry trends. These are specified in Chapter II Consumer Device Platform and Chapter III Consumer Device Software Architecture. This approach seeks to increase the inherent compliance of consumer devices through use of common software components. Consumer Device Software The implementation of YouView devices is based on the use of a number of open-source software components. installed and managed by the Device Manufacturer. viewer settings. aspects of which must be upgradable in the field by the Device. which is a runtime application providing the consumer device‟s built-in user-interface. It includes the Platform Main UI. and discovery of on-demand content and services. in line with the current or intended approach of many manufacturers. the software running on a YouView consumer device is divided into four elements (as shown in Figure 1). access to DVR functionality. Summary of Core Requirements 3. It can be updated by the Platform Operator independently of Device Manufacturers and without needing to upgrade the Core Device Software.  Device Configuration.YouView Core Technical Specification 3. It is also a formalisation of strong. Consumer Device Hardware YouView consumer devices are required to meet the hardware requirements specified in Chapter II Consumer Device Platform. This chapter also includes requirements relating to the remote control including key functions and their mappings and the outputs to be provided by the device to allow connection to a display (as shown in Figure 1). and includes the adoption of Linux as a standard device OS. Consumer Device Software Management For the purposes of software management. This includes: device setup. 3. which seeks to ensure that a minimum level of consumer experience is achieved. A key part of the low-level software in a connected device is the IP network stack.  Content Provider Applications These are built. Core Device Software must always be distributed with a compatible version of the Platform Software. These are as follows:  Core Device Software.  Platform Software. This is built. This contains parameters used to control aspects of the consumer device‟s operation without needing to update either the Core Device Software or the Platform Software. The requirements for this are specified in Chapter IV Consumer Device IP Networking. installed and managed by the Platform Operator.1.3. 3. UI Management and Presentation Engine Integration YouView consumer devices are required to support multiple concurrent applications which may use more than one presentation technology.4. 3. It provides a means for the Platform Main UI provider to deploy a common user experience across a range of devices from different manufacturers. Note: Device Manufacturers may build a variant of a standard YouView consumer device. YouView consumer devices are also required to support broadband (IP) delivery of content and services as specified in Chapter IX IP Content Delivery. Platform Software and Device Configuration are managed on the consumer device is specified in Chapter VI Consumer Device Software Management. Chapter XIII Consumer Device UI Management specifies the © YouView TV Ltd (2011) Page 17 of 229 . Consumer Device Storage Management This specifies requirements for storage systems integrated into the Consumer Device.5. Details of this are beyond the scope of this document. The mechanism by which Content Provider applications are discovered and installed is specified in Chapter XII Application Discovery And Installation.6.YouView Core Technical Specification The way in which the Core Device Software.0 Part A. YouView consumer devices provide means for both broadcast and broadband delivered content to be acquired and stored on the device for later consumption by the viewer. Platform Main UI. The UI Model describes how the various elements of Setup.7. and the associated data management functions (clear private data and factory reset). which includes a CA card slot and Conditional Access technology to support PayTV services over broadcast. seamless experience for the viewer. and includes support for:    SD and HD linear television DVB Subtitles and receiver-mix Audio Description MHEG-5 “red button” interactive services Requirements for protection (in delivery) and management (once on the device) of broadcast delivered content are as defined in the DTG D-Book 7. Consumer Device UI Model YouView consumer devices are required to implement a UI model that supports a federated approach where different parties provide elements of the user experience. This builds on the DTG D-Book 7. 3.0 Part A. The UI model is described in Chapter V Consumer Device UI Model. 3. The requirements for this are specified in Chapter XI Content Acquisition And Management. This includes support for:     HTTP progressive download (PDL) HTTP adaptive bit-rate streaming IP Multicast Timed text subtitles Requirements for protection (in delivery) and management (once on the device) of IP delivered content are defined in Chapter X Content Protection : AV Over IP. Settings and Content Provider Applications fit together so as to result in a unified. It also specifies the behaviour of the device in the event that integrated storage is replaced or cleared. Content Delivery and Content Protection YouView consumer devices are required to support broadcast (DTT) delivery of content and services as specified in Chapter VIII Broadcast Content Delivery. An enhanced EPG for channels from participating Content Providers offering historical schedules and linkages into the on-demand content catalogue. YouView devices also support a © YouView TV Ltd (2011) Page 18 of 229 .10. (Discovery of content through third-party "portal" applications is also supported by the Platform. This corresponds to interface MD4 in the DTG D-Book 7. 3. YouView consumer devices must support the secure collection and backhaul of usage and error data as described in Chapter XVII Consumer Device Usage And Error Reporting. A basic eight-day lookahead Electronic Programme Guide (EPG) derived from locally-received broadcast metadata. and enables the consumer device to operate as a basic DVB receiver–decoder and Digital Video Recorder where it is installed without connection to an IP network.8. 2. This will provide viewers with information that will allow them either to solve problems themselves or be guided to an appropriate solution by a third party.) Platform metadata is contributed into the centralised Metadata Aggregation System by participating Content Providers via a Platform-defined Business-to-Business metadata contribution technical interface.5 and constitutes an implementation-specific metadata delivery interface in that model. A means of searching the aggregated on-demand catalogue by keyword. 3. The last three modes of discovery are supported by Platform metadata served from a centralised Metadata Aggregation System operated by the Platform and accessed by the consumer device over its IP network interface. 3. the Consumer Device Software Architecture and the IP Network Stack to coexist with each other and to support the YouView UI model.YouView Core Technical Specification way in which applications of different types coexist and how the shared device resources required by those applications are managed. A browsable catalogue of on-demand content items aggregated from participating Content Providers. The principle modes of content discovery supported are: 1. Chapter XV MHEG Integration describes additional requirements for the integration of the MHEG-5 engine including those relating to the broadcast-driven lifecycle of MHEG-5 applications. Accessibility In addition to the requirements for Access Services already introduced and specified fully in Chapter VIII Broadcast Content Delivery and Chapter IX IP Content Delivery. The first mode of discovery ensures that a schedule is available for channels from non-participating Content Providers.9. 3. 4. The contributed metadata is transformed by the Metadata Aggregation System into a form that can more easily be consumed by the consumer device and is exposed as a Business-to-Consumer metadata feed in the form of an HTTP-based web service. Diagnostics and Reporting YouView consumer devices are required to support Local Diagnostics. The requirements for local diagnostics are described in Chapter XVI Consumer Device Local Diagnostics. It also provides a fallback source of schedule metadata to cover outages in IP network connectivity. Chapter XIV Presentation Engine Integration specifies how application presentation engines must integrate with the Consumer Device Platform. This also covers the viewer privacy considerations that must be observed. but is not considered further here because this mode is independent of the Platform Main UI application and is not achieved through the use of aggregated Platform metadata. Platform metadata The Platform Main UI application presents a content guide to assist viewers in discovering and selecting content made available through the consumer device. Part B Section 3. Usage information may be used to enhance the user experience of the Platform Main UI. © YouView TV Ltd (2011) Page 19 of 229 .YouView Core Technical Specification range of accessibility features. These are provided through the functionality of the Platform Main UI. building on core features described in Chapter XIII Consumer Device UI Management and Chapter XIV Presentation Engine Integration. . YouView Core Technical Specification Chapter II Consumer Device Platform © YouView TV Ltd (2011) Page 21 of 229 . Chapter Summary This chapter defines a common low-level “platform” for all YouView consumer devices. compliant manner. Chapter audience This chapter is for: Device Manufacturers. This chapter describes requirements for a YouView DTT HD DVR product.YouView Core Technical Specification 1. who need to:    Design hardware that meets the capability and performance requirements Integrate the required low level software components Design a remote control supporting the required functions This chapter is not relevant for: Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 22 of 229 . existing industry trends around the use of common open-source software components. in line with the current or intended approach of many manufacturers.1. Ensure that a minimum level of consumer experience can be achieved. This involves the specification of hardware requirements that extend to the main SoC/processor. seeks to: 1. 1. This is to allow a range of different SoCs to be used whilst still achieving the desired objective. hardware decryption support and hardware graphics acceleration. which in addition to the obvious specification of required connectors etc. such as hardware AV codec support. This also involves the specification of how such hardware capability can be exposed to higherlevel software in a consistent. Increase the inherent compliance of consumer devices through use of common software components. 2. This relates to a formalisation of strong. 3 Y 1x SCART Analogue HD outputs Modulated UHF output RF loop-through Separate stereo audio Y E N Y N Excluded as part of rights management strategy. the device must support the use of USB Wifi adapters. 1x HDMI v1. May be used in conjunction with fixed wire. Strongly desired but not required. Flash memory Y Y 2. Required for HD broadcast content. 2. For Internet connectivity and Home Networking. Integrated wireless Ethernet is optional. N Unique MAC address for Ethernet. Required 1 Function 2 2. Device Platform Summary The following table summarises the main features of the device platform. The subsequent sections provide more detailed specification of these items. DVB-T2 is used for HD services on digital terrestrial. Remains powered in standby.1 Consumer device platform Core hardware CPU: 950 DMIPS+ Commentary Y Specific silicon products proposed to be incorporated into a YouView device will be evaluated by YouView. CEC “One-Touch Play” and “System Standby”. RAM: 512 Mbyte min Minimum DDR bandwidth: 3 Gbyte/sec. auto lipsync. N=no/optional. programmed at Manufacture 2x dual-mode DVB-T/T2 tuners Y Y RF characteristics as specified in DTG D-Book 7 Part A v1. Stereo audio may be provided on RCA sockets if present 1 Y = yes. Support for on disk encryption using AES128 or Triple DES. See section 3. bitstream audio.3. power line adapter or wireless adapter as convenient in home. If not provided. Y Y See section 3. Higher bandwidth may improve performance.YouView Core Technical Specification 2.11n.3 Input / output USB 2. Multichannel linear PCM audio.0 Ethernet port supporting 10BASE-T and 100BASE-TX Y Y Minimum of two: At least one on front panel and one on rear.2 Internal hard disk 320 GB min. BT709 colorimetry. Including support for HDCP.3. E=excluded/not permitted. YcbCr 4:2:2 12-bit. C=conditional (see commentary) © YouView TV Ltd (2011) Page 23 of 229 . Integrated wireless Ethernet: 802. The amount of Flash memory required will depend significantly on which categories of data are stored in Flash and which on disk. 5 Graphics 1280x720 32bpp ARGB8888 graphics plane Support for simultaneous display of subtitles.0 HD video: MPEG-4 part 10 (H. support for OpenGL ES 2. Y Y N Y Y Y Up to 5. As specified by DTG D-Book 7 Part A v1. Required for accessibility applications. As specified in DTG D-Book 7 Part A v1. As specified in DTG D-Book 7 Part A v1. Required for domestic connectivity if the IEEE 802.11n standard is not supported internally. transcode to AC-3 or DTS) Audio: Multi-channel HE-AAC (inc. Could be added in pay operator specific variant of the device.0 and/or OpenVG may allow for higher performance rendering for presentation environments that make use of vector shapes or non-rectangular bitmap transformations.4 Peripheral devices Support for USB mass storage devices Support for USB wireless Ethernet adapter Support for USB human interface devices Support for USB Bluetooth adapter Support for SD card reader 2. Y C Y N N For presentation of content from USB drives.1 channel surround sound. As specified in DTG D-Book 7 Part A v1. However. Not required. Up to 5. No requirement to export content.1 channel surround sound. MHEG engine and top level navigation 2D graphics hardware acceleration 3D graphics hardware acceleration Required 1 Commentary Optical or coaxial SPDIF connection.264/AVC) Main and High Profile Level 4. Y Y Note: may be implemented using multiple hardware graphics layers or by hardware-assisted composition onto a single layer.8 below.264/AVC) Main and High Profile Level 3.YouView Core Technical Specification Function Digital audio (DTS or AC-3 bitstream or linear stereo PCM) Adjustable delay on audio output Serial I/O Common Interface Slot CA card slot 2. Detailed specification provided in section 3. transcode to AC-3 or DTS) Audio: Down-mix of E-AC-3 and multichannel HE-AAC to stereo Y Y As specified in DTG D-Book 7 Part A v1. Automatically) Y Y N N N Where provided. Y N 2.0 Audio: MPEG-1 Layer II Audio: Dolby AC-3 Audio: Dolby E-AC-3 (inc. © YouView TV Ltd (2011) Page 24 of 229 . High profile included as will already be supported for HD services.6 AV codecs SD video: MPEG-2 MP@ML 25Hz SD video: MPEG-4 part 10 (H. CI+ recommended. Decode of existing SD FTA terrestrial services. Accommodate display video delay (pref. YouView Core Technical Specification Function Audio: HE-AAC and LC-AAC Audio description: Receiver mix Required 1 Commentary As specified by DTG D-Book 7 Part A v1.23 or later DirectFB graphics environment with multi-application core 2.6. In stereo mode. Y Y Audio: MPEG-1 Layer III Content decryption 2.15 below.5 below. Single/common remote control design Remote control protocol and codes made available by manufacturers Free-field remote control 2. contrast between labelling and background. As specified by DTG D-Book 7 Part A v1 section 4. Elementary streams. Y Y 2.5. Table 2 : Device Platform Summary © YouView TV Ltd (2011) Page 25 of 229 .9 Misc Fan-less operation N Y N For providers of alternative remotes.7 Remote control Minimum set of remote control functions Basic functions available from the device front panel Remote control design to observe requirements for accessibility Y Y Y N Y Standby button required. and presence of dedicated subtitle and. See section 3. where relevant. N Devices may have a fan subject to the requirements of section 3. other buttons optional. Requires dual decode and mix.31 or later preferred. Devices shall provide an option to enable AD on all outputs or only on SPDIF output.6. good for low bitrate services. Includes: layout of keys. audio description keys.8 Operating system & standard libraries Embedded Linux 2. 11ncompliant adapters.3. A/V outputs Devices shall provide A/V connections as specified in section 22. either built in to the device or via an external Ethernet-connected adapter.4.4. Network The device shall provide an auto-negotiating Ethernet port for connection to a TCP/IP network. full duplex mode and full duplex with flow control.3 standard. There may be a minimum set of drivers defined to be supported in all devices. or reception of two DVB-T2 multiplexes simultaneously For DVB-T and DVB-T2. It is recommended that the Ethernet port have link and traffic indicator lights to simplify the diagnosis of connection problems. the RF characteristics from DTG D-Book 7 Part A v1 shall apply. Core Consumer Device Platform This section describes in further detail the requirements listed in the table in section 2. 3. Devices may restrict the range of adapters that are supported. CEC “One-Touch Play” and “System Standby” are mandatory. or by supporting the configuration and use of optional USB IEEE 802.3. The Ethernet MAC address shall be available to the configuration user interface for diagnostic purposes. Connectivity 3. either using a built-in IEEE 802.11g-compliant and IEEE 802. Silicon All consumer devices will need to be based on SoCs for which the ability to support the necessary functionality has been established. Note: the intention here is not to require PLT to be built into the device (although this is an option) but to ensure that the device interoperates with external PLT adapters.2. Devices shall also provide options to configure the wireless interface manually by selecting from a list of SSIDs. However. for example to limit the number of drivers required. only solutions supporting ETSI TS 102 578 may be provided or recommended for use with connected television devices. to simplify configuration. The default shall be to auto negotiate but devices must also support manual selection of a specific mode.1. Devices shall support WEP. 3. UHF input The device shall have a combination of tuners and demodulators that permits:    reception of two DVB-T multiplexes simultaneously.2. Multicast capability is required. The port shall support at least 10BASE-T and 100BASE-TX physical layers via an RJ-45/8P8C socket with MDI wiring as specified by the IEEE 802. Use of WiFi Protected Setup (WPS) is recommended.1.11n adapter. 3. reception of one DVB-T multiplex and one DVB-T2 multiplex. Devices shall support wireless networking. 3. 1000BASE-T may also be supported. WPA/PSK and WPA2/PSK encryption.1 of DTG D-Book 7 Part A v1 with the following changes:  HDMI “Auto Lipsync Correction”.2. Note: MAC address shall not be used as a device unique identifier for any other purpose. Note that the “Auto Lipsync” feature implies HDMI version 1.2.2. Devices shall support half duplex mode.3. PowerLine Telecommunications (PLT) shall be supported as an option for network connectivity. © YouView TV Ltd (2011) Page 26 of 229 .YouView Core Technical Specification 3. Audio output requirements are specified further in sections 3. USB devices Devices shall provide at least two high speed. the device shall up-scale SD video to the configured HD output resolution. RGB video and audio inputs from this SCART to the primary SCART shall be provided whilst in standby and under pin 8 control. where possible. © YouView TV Ltd (2011) Page 27 of 229 . The HDMI connection shall be monitored to detect when a display is connected or removed. high power. These adjustments shall not affect the timing of HDMI audio. Devices may have an additional AUX SCART connector but this is not required. The device is not required to continue to function in the event of a hard disc failure. by default. Additional analogue and digital audio outputs are optional. The HDMI output shall use BT709 colorimetry.4. Devices shall have at least one SCART connector supporting RGB and composite video. When a SCART output is active but is not the primary output. no CGMS-A restrictions shall be signalled. the device should be able to report such a failure to the user.    As specified in DTG D-Book 7 Part A v1.3. Devices shall support reservation of 30 Gbytes of the media storage area for background „pushed‟ content. it is recommended that volume control functions do not apply to that output. If decryption keys for stored content are themselves held on the hard disk. Devices are not required to offer any user-selectable option for HDMI output resolutions below 720p.YouView Core Technical Specification  A manual audio delay adjustment affecting analogue and SPDIF outputs (both PCM and nonPCM) shall also be provided.4 below. devices must adhere to the power management requirements specified in section 3.11. HD broadcast content stored on disk shall be encrypted with AES128 or 3DES. Storage for broadcast recordings and IP downloads shall be managed as a single storage area. However. There shall be at least one connector on the front of the device and at least one on the back.3 and 3.3. 3.2. However. CGMS-A restrictions shall be signalled only when presenting protected IP-delivered content and only where specifically mandated by YouView specifications. loopthrough of composite video. Content obtained in encrypted form over IP shall be stored on disk as is. as specified in DTG D-Book 7 Part A v1. this manual adjustment shall override the automatic adjustment. Internal storage Devices shall have internal non-volatile storage to hold the device software image and to store A/V content.0 host ports. in all other cases.4 below. they shall be encrypted with a key linked to a device identifier such that the keys cannot be extracted if the hard disk is transplanted into a different device.11.1. When used. 3. The internal storage may utilise either Flash memory or a hard disc or both. See also Chapter VII Consumer Device Storage Management. The USB standard „A‟ socket shall be used. devices shall not have analogue component HD outputs. SD output modes shall not be used over HDMI unless the display offers no HD display mode. Volume controls shall not affect the SPDIF audio level. Media storage HD DVR devices shall have storage for at least 300 Gbytes of A/V content. However. USB 2. If present. 3. Devices shall have the hardware capability to output CGMS-A signalling on analogue SD outputs. consideration should be given to locking the main user interface processes in RAM. Table 3 : Noise constraints Noise constraint < 24 dB(A) < 26 dB(A) In all cases. The Linux kernel shall be suitably configured for use on a platform with limited resources. use hardware timers to wake up device from low power state. Noise constraints The device noise level.4.6 4. power down A/V outputs. 3. Device drivers for the following functions are required:     SATA USB 2. Device manufacturers shall take all reasonable steps to minimise power consumption in active standby mode.23 (2. 3. whichever is the higher. the constraints shall apply across the device‟s full operating ambient temperature range or up to 45 °C. Operating mode (fully „on‟ or making a recording or download). Typical steps will be: reduce CPU clock speed. However. provided that they meet the noise level requirements listed above and provided that the fan speed is controlled and arranged to run only as necessary to maintain the internal temperature within its normal operating range. as defined by ISO 7779:2010 for the category “Digital media recorders and playback units for consumer use” (with no recordings or downloads taking place). defined as the mean of the four A-weighted emission sound pressure levels measured at the preferred bystander positions in accordance with ISO 7779:2010.3. Power management Devices shall comply with all applicable legislation on standby power consumption.31 or later preferred) 2. power down hard discs.0 (including hot plug support) Powered and non-powered USB hubs USB mass storage © YouView TV Ltd (2011) Page 28 of 229 .2.6. power down system components not in use. shall meet the following constraints: State Idle mode.6. 3. Swap space Devices may use internal storage as swap space if this improves performance. switch SDRAM to self-refresh.YouView Core Technical Specification 3. Devices may have a fan. The following version requirements apply: Component Linux kernel Glibc Toolchain (GCC) Min version 2.2 Table 4 : Kernel and tool chain requirements Notes SMP support required for devices where SoC has a multi-core application CPU.5.6. Operating system Devices shall be built using the Linux operating system with glibc. the most recent possible version should always be used. jffs2) Filesystem for unpacking platform software images (cramfs) Filesystems used within the device shall be recoverable in the event of a power failure while the device is in use. Ethernet. Version 1.7.1.6. JPEG image decoder. Older versions unsuitable due to security concerns. xfs. Note: support for USB Wifi adapters is not required if the device has built-in 802.5 1.3 can be used with the addition of a set of patches available from YouView.g. Library C libraries C++ libraries DirectFB SaWMan DBus libpng Libjpeg libz libcurl libxml2 OpenSSL Status Required Required Required Required Required Required Required Required Required Required Required Min version See section 3. MHEG security etc. As supplied with compiler. libm. ext3) Filesystem suitable for Flash memory (e.24 1.5 1. Full requirements are detailed in section 3. See section 3.4.11n adapters with WPA and WPA2 support (may be restricted to adapters requiring specific drivers). XML parser Encryption library for TLS. Zlib compression library. gamepad and mouse buttons. IPC library. Standard libraries The following table lists software libraries that are required or recommended. Older versions unsuitable due to security concerns. For security reasons. libdl.2 above.2.11g and 802.8 below.11n support.4.g. multicast (both SSM and ASM) IR remote control DirectFB fusion shm/ipc module (version 8. 3.44 7 1.4. the most recent possible version should be used.YouView Core Technical Specification   USB human interface devices (USB keyboard.2. and libresolv. HTTP client library. For security reasons.2. © YouView TV Ltd (2011) Page 29 of 229 .1 or later) Watchdog (if supported by SoC) ALSA PCM sound 2            Set top box functions (typically using silicon-vendor provided drivers) The following filesystems shall be supported: vfat filesystem (for USB devices) Filesystem suitable for large media files (e. 1. librt. it can be omitted but additional porting work will be required for some software components. Shared application window manager for DirectFB. libpthread. for accessibility input devices) USB 802. 2 3 Where this is not available. PNG image decoder. TCP/IP. Note: ext3 is unlikely to be suitable due to the excessively long time taken to delete large files) Filesystem suitable for general purpose use (e.32 Latest available 3 Notes libc.2 above.g.3 Latest available 2. 4. The DirectFB „system‟ and „gfxdriver‟ plugins for the hardware being used must support use in a multiapplication environment. the graphics layer will always contain alpha-premultiplied pixel data.5 or later is required. Table 5 : Library requirements Additional libraries may be required to support specific presentation engines.15 2. Presentation engine integration Presentation engines requiring graphics display shall do so through a DirectFB Window. Text rendering for MHEG.4 version 1.4 1. shared libraries shall be used in all cases.8. ALSA sound API for presentation engines.1.0. This layer will be used to compose the graphics from various presentation engines.8.5. For efficiency.YouView Core Technical Specification Library SQLite log4cplus Libasound Freetype Status Required Required Recommended Recommended Min version 3. Layers The DirectFB implementation shall provide at least the capabilities to manage a single primary graphics layer. 3. Logging library.8.22 1. This composition process may use alpha blending and as a result. 3. The graphics layer shall support the following capabilities:     DLCAPS_SURFACE DLCAPS_OPACITY DLCAPS_ALPHACHANNEL DLCAPS_PREMULTIPLIED 4 3. Consequently. Presentation engines may not directly manipulate DirectFB layer surfaces.8. Devices shall provide acceleration through a suitable DirectFB graphics driver for at least the following set of operations: 4 The DirectFB implementation must accept a configuration with this option. 2D acceleration The graphics performance of the device depends on the presentation engines having access to the 2D hardware acceleration functions provided by the SoC. These are not included in this list. The platform must either act on this flag directly or must provide an alternative means for the graphics layer to be configured to handle premultiplied pixel data.9 Notes Lightweight database for configuration information. Multi-application core DirectFB shall support the multi-application core using the Fusion kernel module and support libraries.3.3. © YouView TV Ltd (2011) Page 30 of 229 .2. 3. DirectFB shall support applications running as different Linux users. Version DirectFB 1.4.0. the layer shall support the option to blend with the video layer in manner that takes into account this premultiplication.6. DirectFB requirements 3.8. 3.8. uPnP/DLNA and for device setup and configuration. 1Asrc) SRC (1. Required to be supported in combination with all blending flag combinations listed above. 0) SRC_OVER (1. or playback of content from IP. 0) SRC_OVER (1. 0) SRC_OVER (1. 1Asrc) SRC (1. 1Asrc) N/A Notes Blit StretchBlit BatchBlit DSBLIT_NOFX DSBLIT_BLEND_ALPHACHANNEL SRC (1. Graphics performance may degrade during HD video playback. Used to blend images that have an alpha channel and nonpremultiplied pixel data. Table 6 : Graphics acceleration operations The performance of these hardware accelerated functions shall be at least as specified in the following table for all pixel formats that are required to be accelerated (see below): Operation Rectangle fill Rectangle fill (blended) Blit Blit (blended) StretchBlit upscale (with and without blending) StretchBlit downscale (with and without blending) Performance required 200 Mpixel/sec 120 Mpixel/sec 120 Mpixel/sec 100 Mpixel/sec At least the same as a straight Blit of the destination size At least the same as a straight Blit of the source size Table 7 : 2D Graphics performance These figures shall be achievable when the device is showing broadcast SD video. Used to apply a constant alpha value to an image that has an alpha channel and nonpremultiplied pixel data. 0) SRC_OVER (1. DSBLIT_BLEND_ALPHACHANNEL | DSBLIT_SRC_PREMULTIPLY DSBLIT_BLEND_ALPHACHANNEL | DSBLIT_BLEND_COLORALPHA | DSBLIT_SRC_PREMULTCOLOR DSBLIT_BLEND_ALPHACHANNEL | DSBLIT_BLEND_COLORALPHA | DSBLIT_SRC_PREMULTIPLY DSBLIT_COLORIZE DSBLIT_SRC_COLORKEY None Required only if colour keying is more efficient than blending and then only if subtitles must be rendered on the same graphics plane as the UI. 1Asrc) Used to blend images that have an alpha channel and premultiplied pixel data. 1Asrc) SRC (1. Accelerated blitting operations shall be supported for at least the following pixel formats: ARGB and ARGB4444 (as source and destination formats) and A8 (as a source format and for A8 to A8 copy). Used to apply a constant alpha value to an image that has an alpha channel and premultiplied pixel data. Otherwise not required. If © YouView TV Ltd (2011) Page 31 of 229 .YouView Core Technical Specification Operation FillRectangle FillRectangles Blending flags DSDRAW_NOFX DSDRAW_BLEND Blending functions N/A SRC (1. 0) SRC_OVER (1. Implementations shall take into account filtering requirements © YouView TV Ltd (2011) Page 32 of 229 . Graphics layers Graphics from the various presentation engines shall be rendered through DirectFB. Key repeat functionality can be implemented in the DirectFB input driver if desired. Where hardware image decoding is available. 3. 3. Support for USB input devices allows for custom user input devices to meet accessibility requirements. Clipping It is strongly recommended that devices implement clipping in a manner that meets the following requirements:   pixels outside the defined clipping region are unmodified by blitting and drawing operations pixels within the clipping region are rendered in exactly the same way as they would have been were the clipping region not set. with an initial repeat delay of 400ms. However. All input devices shall support auto-repeating keys. Subtitles are always positioned directly in front of the video plane. a repeat interval of around 100ms is recommended.8. The graphics layer managed by the screen manager shall have a resolution of 1280x720. gamepad and mouse devices (mouse drivers need only support button press events). 3. Note: special care must be taken to comply with this requirement when performing StretchBlit operations where the clipping region does not align with the destination rectangle. Presentation engines are recommended to use DirectFB for image decoding wherever possible in order to take advantage of any hardware acceleration that is available. JPEG and GIF. Plug-ins DirectFB image providers shall be provided for at least the following formats: PNG. it is recommended that DVB subtitles be rendered into a separate hardware graphics plane if one is available that can support 8bpp pixel data. LUT8 is also required as a source format.8.9.8.6. Implementations in which clipping does not satisfy these requirements will necessitate less efficient rendering techniques for presentation engines. this should be supported through DirectFB. below the main graphics.YouView Core Technical Specification subtitles must be rendered on the same graphics plane as the UI. generating multiple DirectFB KEYPRESS events while the key is held down and a single KEYRELEASE event when the key is released.8.7. Presentation of DVB subtitles may also be rendered in this way. The device shall be responsible for managing the output of this graphics plane on the different output resolutions that the device is required to support. The results of hardware accelerated operations shall agree with the DirectFB software renderer to within the following tolerances: Operation Simple blit with no blending All other operations Destination pixel format Any ARGB ARGB Not ARGB Source pixel format Same as destination ARGB Not ARGB Any Colour max RMS error Zero 2% 2% 10% Alpha max error Zero 1% 7% 7% Table 8 : Blending tolerances 3. For remote control input. User input DirectFB input drivers shall be provided for the device‟s IR remote control and for USB keyboard. FILE Features: SSL. sspi.0 Notes As specified in DTG D-Book 7 Part A v1. devices shall use the libcurl library for this function. libidn 3. Decode of existing SD FTA terrestrial services. To minimise code duplication. Table 10 : Audio codecs 5 IPv6 is not required for launch © YouView TV Ltd (2011) Page 33 of 229 . 3. IPv6 .10. 3. porting efforts and for interoperability. libz.264/AVC video decoder shall support dynamic changes of bitrate and decoded frame sizes that occur at IDR points. As specified in DTG D-Book 7 Part A v1. See section 3. Table 9 : Video codecs The H.1.1 channel surround sound. High profile included as will already be supported for HD services. Devices shall support ADTS encapsulation as well as LATM/LOAS. ldaps.0 HD: MPEG-4 part 10 (H. The graphics system is performance critical.11.11. tftp.264/AVC) Main and High Profile Level 3. libcurl shall be compiled with the following protocols and features enabled:    Protocols: HTTP. proxy 5 The following features are not required and should be disabled: FTP.11.3 below. cookies. dict.4 below.264/AVC) Main and High Profile Level 4.2. HTTP client library (libcurl) Presentation engines and the metadata subsystem require an HTTP client library. Devices shall support ADTS encapsulation as well as LATM/LOAS. nss.11.11.YouView Core Technical Specification for interlaced displays. Devices shall optimise the graphics path appropriately for the particular SoC used. A/V handling 3.11. telnet.1 channel surround sound. Elementary streams. gnutls. Up to 5. As specified in DTG D-Book 7 Part A v1. See section 3. ldap. As specified in DTG D-Book 7 Part A v1. Up to 5. Video codecs Hardware support for the following video codecs is required: Codec SD: MPEG-2 MP@ML 25Hz SD: MPEG-4 part 10 (H. As specified in DTG D-Book 7 Part A v1. with or without ID3 tags.3 below. with cryptographic functions provided by OpenSSL. Audio codecs Support for the following audio codecs is required: Codec MPEG-1 Layer II Dolby E-AC-3 Multi-channel HE-AAC Stereo HE-AAC and LC-AAC Receiver-mix audio description MPEG-1 Layer III Notes As specified in DTG D-Book 7 Part A v1. HTTPS. See section 3. The following figures show a logical model for audio flow within the device. to SPDIF only. Stereo PCM Delay SPDIF Stereo Multi-channel 2. Figure 3 : Audio flow logical model where the main programme sound is multi-channel Audio delay for HDMI is controlled by the HDMI Auto Lipsync Correction feature. When audio description is enabled. 3. Delay Delay not required if only analogue output is SCART D to A Stereo analogue SCART/ RCA Nonprogramme sound (premixed) Main programme sound Stereo PCM Delay HDMI Audio description Stereo PCM Delay SPDIF Figure 2 : Audio flow logical model where the main programme sound is stereo Stereo analogue Delay Delay not required if only analogue output is SCART Downmix D to A SCART/RCA Nonprogramme sound (premixed) Stereo PCM 5. The AAC decoder shall support seamless transitions between access units that use SBR and those that do not. Audio delay for analogue and SPDIF outputs is controlled by a user configuration setting.3.1. Audio description may be routed to all outputs. receiver may restrict all outputs to stereo. or disabled.11. © YouView TV Ltd (2011) Page 34 of 229 . Audio mixing and transcoding Devices shall support the audio output and transcoding requirements specified in DTG D-Book 7 Part A v1.2. HE-AAC decoders shall support dynamic range control as described in DTG D-Book 7 Part A v1 section 4.4. This mode is required by DTG D-Book 7 but is not recommended unless specifically requested by the user as it does not allow for mixing with other audio sources on the receiver.1 PCM Main programme sound Delay Encode AC3 or DTS HDMI Passthrough (see note 1) AC3 or DTS See note 2 Audio description Notes: 1.YouView Core Technical Specification Audio decoders shall support dynamic changes of encoded bitrate between access units. 6.5. Devices shall provide the following user configuration settings for the output of audio description:    Audio description disabled Audio description mixed with all audio outputs Audio description mixed with audio on SPDIF output. for an HE-AAC bitstream with a „prog ref level‟ parameter of 0x7c (-31 dB FS) going to an HDMI output where the sink does not support bitstream audio.11. Hardware shall support at least general-purpose decryption of AES-128-CTR and AES-128-CBC. MPEG-1 layer II services shall be assumed to have a reference level of -23 dB FS. the SPDIF output is only required to provide a stereo mix. The gain factor may be positive or negative. a gain factor of +8 dB shall be applied. Audio description Devices shall support receiver-mix audio description services. Devices shall assume that non-programme sound is mixed to a programme reference level of -23 dB FS so as to match standard definition MPEG-1 layer II audio services.4. As an example. Content decryption Devices shall support decryption of content encrypted using the following schemes. E-AC3 services shall be normalised using the reference level indicated by the „dialnorm‟ parameter within the E-AC3 bitstream.11. This is achieved by applying a gain factor that is the difference between a target level for a particular output and the reference level of the audio source. For HDMI outputs where the sink does not support bitstream audio and for all analogue outputs. Non-programme sound may originate from any presentation engine and there may be multiple sources active at any time. 3. audio shall be normalised such that the reference level corresponds to a target level of -31 dB FS. Note: in this mode. as specified in IEC 62455 section 6. 3.4.1. For the purposes of these diagrams. HE-AAC services shall be normalised using the reference level indicated by the „prog ref level‟ parameter within the HE-AAC bitstream. as specified in DTG D-Book 7 Part A v1 section 4.2. Note: bitstreams can be expected to carry dynamic range control signalling that will ensure that clipping does not occur as a result of the normalisation process.  For MPEG-2 transport streams: AES with a 128-bit key using the Cipher Block Chaining (CBC) encryption mode with the residual termination block process from ANSI/SCTE 52 2003. main programme sound sent to all other audio outputs.4.YouView Core Technical Specification Volume level normalisation is required in order to ensure that the audio level at the output of the device is the same for all audio codecs. See also DTG D-Book 7 Part A v1 section 4.  For MP4: AES-based. all non-programme sound is assumed to have been premixed to stereo PCM. At the SPDIF output and for HDMI outputs where the sink supports bitstream audio. The diagrams do not show any sample rate conversion but this may be required where different audio sources have a different sample rate. Note: the audio level adjustments required to meet these requirements are not shown on the diagram but are described below. © YouView TV Ltd (2011) Page 35 of 229 . Further details of encryption formats can be found in Chapter X Content Protection : AV Over IP and Chapter IX IP Content Delivery. Devices may support additional audio output options to those shown.5. the audio shall be normalised such that the reference level corresponds to a target level of -23 dB FS. broadcast video “Primary” video decoder Player 2 e. Resource management DirectFB window Graphics plane Player 3 e. 3. Generally. Video decoding and resource management Devices shall support one HD video decode and presentation path to the specifications of DTG DBook 7 Part A v1. The low-level media playback subsystem shall accept any valid PTS value to begin playback. this will require the creation of an index file that contains PTS values and corresponding byte offsets for each frame within the stream file. 3. The primary A/V decode path shall not drop frames. To achieve this. Devices shall support the decoding of additional low resolution video streams for presentation on the graphics plane up to a maximum combined source pixel area of 720x576 pixels. Where a subtitles stream is present in a broadcast service.7.11. The following figure illustrates the primary and additional video paths. The playback subsystem shall seek to the nearest previous frame from which decoding can begin and begin presenting A/V media once the requested start PTS has been reached in the file.g. The controls shaded green © YouView TV Ltd (2011) Page 36 of 229 . Player 1 e.YouView Core Technical Specification 3. Video decoder etc. Devices shall implement a resource management function such that each such component can use the hardware resources associated with this path. It is acceptable for there to be occasional dropped frames in the rendering of video onto the graphics plane and performance may degrade further if the video is subject to blending or up-scaling or has a source resolution greater than 360x288. Only the PTS values of frames from which clean decoding of the stream can commence need be stored in the index file. The case shown best reflects the situation where broadcast video is being presented.11. IP media streaming Video presentation controls Primary video plane etc.6.11.8. A/V component selection and presentation controls The figure below shows the various component selection and presentation controls required. devices shall generate sufficient indexing metadata during recording so that playback can be requested from any PTS value. Driver support shall be provided to allow for accurate playback between specified start and end positions. presentation engine with builtin A/V capability Figure 4 : Primary and additional video paths Multiple components in the YouView software architecture need to access the primary video decode path.g. this shall be included in recordings made from that service. A/V recordings and accurate playback Devices shall support frame accurate playback of content recorded from a linear broadcast stream. The resource management function is not required to support multiple components controlling the primary decode path at the same time. Media between the seek point and the start point shall not be presented.g. The orange line indicates the resource management function from the previous diagram. The audio description decoder (marked “AD decoder”) is able to adjust the volume of the audio coming out of the main audio decoder as part of its built-in behaviour. Please refer to the appropriate presentation engine integration specification for details. ii.11. Presentation engines may output stereo PCM audio samples to be combined with audio from the media pipeline. This is an application control of video scaling and positioning. This is the viewer‟s aspect ratio control. This is an application control for aspect ratio conversion. It combines with V-P1 to influence the composition of the video picture and the display formatting. This is depicted by the dotted arrow. It combines with V-P2 to influence the composition of the video picture and the display formatting. This is the viewer‟s audio language preference and forwards a default audio component to control A-S2. The table below describes the function of the various controls: Control V-S1 V-P1 V-P2 V-P3 A-S1 Function This is the application-controlled video component selector.3.YouView Core Technical Specification are controls that are expected to be adjusted by the viewer. AD-P1 A-P2 MAIN AUDIO A-S2 AD-S2 AD-E1 AD decoder AD-S1 Subtitles S-S2 S-E1 Subtitle decoder S-S1 Figure 5 : Component selection and required presentation controls Notes: i. See also section 3. © YouView TV Ltd (2011) Page 37 of 229 . Video Format conversion Scale V-P3 V-S1 Video decoder V-P1 V-P2 VIDEO OUT PCM audio (See note i) Components of selected broadcast or IP delivered stream Audio Audio decoder A-P1 AD-E2 A-S1 See Note ii SPDIF Audio description Note: this is a simplified view of the audio system. The audio volume control A-P1 affects the audio level after this has happened. It can select between any of the video components from the selected source or can select nothing. those shaded blue are expected to be adjusted by application software. It is not sufficient simply to scale the image to the display size. Devices must take care to apply the correct cropping and scaling operations for these formats. It can select between any of the audio description components from the selected source. Similar considerations apply to other resolutions such as 544x576 or 352x288. Implementers should note that 704x576 H. The control defaults to following A-P2. This is the viewer‟s audio description enabling control. the default component from S-S1 or nothing. Table 11 : Presentation controls AD-E1 AD-P1 AD-E2 S-S1 S-S2 S-E1 3. This is the viewer‟s subtitle language preference (which may be set automatically to match A-S1). the default component from A-S1 or nothing. e.264 video with an encoded pixel aspect ratio of 16:11 is a full screen 16:9 format that requires only scaling for output to 1280x720 or 1920x1080 displays but requires horizontal padding at each side and no scaling for output to 720x576 SD outputs. Devices must be able to update their software image. This is an application-controlled audio description component selector. It adjusts the audio description volume independently of the main audio volume. © YouView TV Ltd (2011) Page 38 of 229 . Device software upgrade Devices need to store several different types of information in non-volatile storage:      Core device software image (Linux kernel and root filesystem) Platform policy information and user interface User configuration information Persistent data associated with third party services and applications. This is the viewer‟s audio description language preference (which may be set automatically to match A-S1).YouView Core Technical Specification Control A-S2 A-P1 A-P2 AD-S1 AD-S2 Function This is an application-controlled audio component selector.11. This is the viewer‟s master volume control and controls all audio outputs that are controllable. This is the application-controlled subtitle component selector.g. Video scaling and aspect ratio conversion Devices shall observe aspect ratio information encoded in A/V content. This is the viewer‟s subtitle enabling control. It can select between any of the audio components from the selected source. It is specific to the audio coming from the audio decoder and does not affect other audio sources on the device. The viewer controls the offset that makes the audio description quieter or louder relative to the main audio. the default component from AD-S1 or nothing.264 video with an encoded pixel aspect ratio of 16:11 is a format with horizontal overscan which can be output directly to a 720x576 SD output but requires cropping to scale only the central 704x576 portion to 1280x720 or 1920x1080 in order to preserve the correct aspect ratio. cookies Cached metadata and data relating to third party services The core device software image is managed by the device manufacturer. It can select between any of the audio components from the selected source.12.9. 3. This control determines whether audio description appears on all outputs or only on the SPDIF output. Similarly. This is the viewer‟s audio description volume control. This is the application-controlled audio volume control. 720x576 H. 3. 3. OK. JTAG shall be disabled or password protected in production devices. 3. The RSA private key shall not be stored unencrypted in Flash memory or on the hard disk. up. they shall not display information that is inconsistent with the standby state of the device (as perceived by the user) or with information shown in the UI. The device shall be capable of supporting DTCP-IP.15. other file systems and the platform software. Where front panel indicator lights or displays are present. indicators and displays This specification does not specify any requirements for status indicator lights or information displays. The device shall have a unique RSA private key and corresponding X. Holding down the standby button shall force a reboot of the device. The device shall use a secure boot mechanism to ensure that only manufacturer-signed software images can be run on the device.YouView Core Technical Specification Devices shall be tolerant of power interruption at any time. Content protection mechanisms for IP-delivered content shall be as described in Chapter X Content Protection : AV Over IP.13.14. left. nor in any device upgrade file or over-air download carousel. Additional front panel buttons are optional. The device shall have a unique immutable ID available to software running on the box and known to the manufacturer. including of the root file system. This ID shall not be the device‟s MAC address. © YouView TV Ltd (2011) Page 39 of 229 . Content protection mechanisms for broadcast-delivered content shall be as specified in DTG D-Book 7 Part A v1. More detailed specification of the device upgrade requirements can be found in Chapter VI Consumer Device Software Management. Automatic reset It is recommended that devices incorporate a hardware watchdog timer that will automatically reset the device in the event that the device software stops functioning. Devices shall support hardware-accelerated image decryption and signature verification.509 certificate signed by the manufacturer. No key described above shall be present unencrypted in the device software image. Security Note: nothing in this section implies that any of the keys or identifiers listed here will be made available to application-level software. If front panel buttons are provided to duplicate the functions of remote control keys. down. The device shall have a unique encryption key known to the manufacturer held securely and not available directly to the application CPU. the following set of keys will allow the operation of many device functions: standby. Front panel buttons. right. back and the menu button. Devices shall have a front panel standby button. DIKS_STOP. Note: this event may not be generated if the device is in a low power mode when the key is pressed. DIKS_FASTFORWARD. DIKS_YELLOW. DIKS_BLUE Text Info Zoom DVR controls DVR skip controls Red. Access contextual help. Menu Guide Mute sound Help Cursor control keys (Up. Yellow. Display programme information. Increase or decrease the audio level. Green. DIKS_PREVIOUS DIKS_RED. Mute the audio output. DirectFB key symbol DIKS_POWER to toggle between ON and STANDBY mode. Right) DIKS_MENU DIKS_EPG DIKS_MUTE DIKS_HELP DIKS_CURSOR_UP. Buttons available to device functions to aid user interaction. DIKS_CURSOR_DOWN. Primarily for numeric entry but also labelled so as to support text entry. Keys used to provide user interaction to a variety of device functions.YouView Core Technical Specification 4.1. Display the top level user interface menu. Accessibility and web view management. Keys to skip forward and back by 30 seconds. Down. DIKS_RECORD DIKS_NEXT. Left. User Input Device 4. DIKS_CURSOR_LEFT. User input functions The following table shows the user input functions required and their mappings to DirectFB key symbols: Function On/Standby Description To toggle between active and stand-by mode. Blue Numeric entry DIKS_0 … DIKS_9 with key identifiers set to the values DIKI_KP_0 through DIKI_KP_9 © YouView TV Ltd (2011) Page 40 of 229 . Enter an interactive application while viewing a channel. EPG or other user interaction function. EPG or other user interaction function. Keys to control playback of recorded or streamed content. DIKS_GREEN. DIKS_ESCAPE Close Allow the user to immediately exit an application. DIKS_CURSOR_RIGHT DIKS_OK DIKS_BACK OK Back Allow the user to confirm or select a particular screen choice or action. Show the main programme guide. DIKS_PLAY. Volume up/down Channel up/down DIKS_VOLUME_UP. DIKS_CHANNEL_DOWN DIKS_TEXT DIKS_INFO DIKS_ZOOM DIKS_REWIND. DIKS_PAUSE. normally ordered by number. May also be used to enter an interactive application while viewing a channel. DIKS_VOLUME_DOWN DIKS_CHANNEL_UP. Step up or down to the next service available to the user. Allow the user to move back one step in an interactive application. these are indications of best practice but are not mandatory. All labelling shall be durable and long-lasting (for example moulded into casing). Short cut to retailer / device manufacturer brand presence within the YouView UI. This is to support the use of programmable remote controls. Affiliate ISP short cut to broadband services page within the YouView UI. 4. Keys shall be logically grouped by function and those functional groups should be separated by more than the distance between keys within each group. There shall be a raised dot or „nib‟ on the figure 5 key of the numeric pad. Additional control codes In addition to the standby toggle function. and the manufacturer may choose to meet the requirement in other appropriate ways. the IR remote control code set shall include an independent power on control code.)     Keys shall be large and well separated (for example separated by 50% or more of button width). DIKS_GOTO DIKS_F2 DIKS_F3 DIKS_F4 DIKS_F5 Table 12 : Key mappings Any additional manufacturer-specific keys shall use DirectFB key symbols in the range DIKS_CUSTOM0 to DIKS_CUSTOM9. example approaches to meeting the requirement are given. Enable/disable audio description.2. Access to the remote‟s battery compartment should be straightforward but child-proof. Enable/disable subtitles. The remote should have no redundant keys. (In some cases. Short cut to on demand section of the UI. Different functions should also be distinguished by distinct shapes or texture. This additional key code shall generate the DIKS_POWER2 DirectFB key event. Short cut to search function within the YouView UI. Short cut to the MyView section of the UI.3. 4. DIKS_SUBTITLE Delete a character from a text field. Physical requirements The following physical requirements apply.     © YouView TV Ltd (2011) Page 41 of 229 .YouView Core Technical Specification Function Dual function: Shift (during text entry) Audio Description (toggle) Dual function: Delete (during text entry) Subtitles (toggle) Search On Demand ISP button MyView Retailer / device manufacturer brand shortcut Description DirectFB key symbol DIKS_AUDIO Toggle upper and lower case text entry. The remote control shall have clear legible legends (in a sans serif font and as large as possible) and contrast with the keys and/or background. Adjacent keys shall be tactilely distinguishable (for example be raised or have raised edges). they should provide a minimum lifetime of 12 months with typical remote control use. It should be non-slippery. Care should be taken to ensure that the directional properties of the communications link from the remote control to the device are as wide-angle as possible. for example by means of a textured finish. This allows user interaction with the remote control to use a multi-tap text entry method whilst allowing a keyboard to generate both alphabetic and numeric key input directly. If batteries are supplied.4.1. © YouView TV Ltd (2011) Page 42 of 229 . easy to grip and stable if placed on a flat surface.   4. Input events for such symbols may use any DirectFB key identifier and modifier values. Keyboard input Key input events from any connected USB keyboard shall be mapped to DirectFB user input events in the same manner as for the standard DirectFB „keyboard‟ and „linux_input‟ drivers.YouView Core Technical Specification  The remote shall be capable of single-handed operation by either hand. Input devices may use any other key symbols for text input purposes provided that they represent ASCII characters and do not correspond to any of the key symbols listed in section 4. The effect of this is that the key events for the numeric keypad keys will duplicate the number functions of the remote control whilst the „standard‟ number keys will generate key identifiers that can be distinguished. Any other input device capable of generating alphanumeric input (such as a remote control providing a full alphanumeric keyboard) shall map alphanumeric keys in the same way. YouView Core Technical Specification Chapter III Consumer Device Software Architecture © YouView TV Ltd (2011) Page 43 of 229 . 1. Chapter Summary This chapter provides an overview of the Consumer Device Software Architecture.YouView Core Technical Specification 1. and key operational requirements for a YouView device. and management of system time .1. including message-based communication. who need to:  Design and build a software stack that: follows the principles defined. Chapter audience This chapter is for: Device Manufacturers. is capable of delivering the target user experience in terms of stability and performance. meets the operational requirements specified. This chapter is not relevant for: Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 44 of 229 . YouView Core Technical Specification 2. to reduce authoring costs for content providers. Introduction This chapter presents an architecture that has been developed in response to a number of requirements and challenges that include:        Bringing together broadcast and IP delivery technologies. to ensure effective co-existence. Traditional monolithic middleware solutions do not provide a suitable foundation on which to build a solution that addresses all these requirements. security. so a more modular approach is needed. This includes the use of the Linux operating system. a multi-process model. Software designs with a single main executable and tight coupling between functional areas often exhibit problems in areas such as memory management. However. Enabling hardware graphics acceleration and making it easily accessible to ensure the best possible viewer experience. Supporting multiple concurrent applications. and make it difficult to integrate newer technologies. This chapter defines key technology foundations and outlines a solution that reduces the risk and complexity associated with software integration. and reduce content distribution costs. the extent of the investment made by Device Manufacturers and software vendors in existing technology is acknowledged and the principle of reusing existing software is central to this architecture. to maximise availability of content. Reducing fragmentation of technology in the connected television ecosystem. a message bus for inter-process communication and a set of common opensource libraries. Improving device compliance. Integrating components from third party suppliers. © YouView TV Ltd (2011) Page 45 of 229 . Supporting multiple application frameworks and presentation technologies. resource management. It should provide abstraction from underlying implementations at various levels in the software stack. It should allow manufacturers to differentiate their products.DVR) Software Component (e. Design goals The architecture has been designed to achieve the following goals:         It should be aligned with industry trends. It should use open-source software where appropriate. Metadata) Linux kernel & drivers Hardware 3. It allows for the re-use of existing software components and simplifies the integration of third party software.g. Logical Architecture The following illustration outlines the Consumer Device Software Architecture. The architecture has the following benefits over a monolithic approach: It allows software components and Applications to be developed in isolation and tested before final integration. Software Architecture Overview 3.1.g. Media Playback) Software Component (e. Platform Software Platform Configuration Platform Applications Content Provider Applications Content Provider Applications Application Players / Presentation Engines Core Device Software Message Bus Software Component (e.g. It should run on silicon products that are available in the market now. © YouView TV Ltd (2011) Page 46 of 229 .YouView Core Technical Specification 3.2. It supports models where the Platform Operator is able to manage and update Platform Applications and Platform Configurations independently. It also allows Platform Applications that provide the user interface to be developed and maintained independently without requiring the Core Device Software. a wide range of open-source products have been developed for. and is currently supported by the vast majority of hardware and software vendors in the connected television ecosystem.YouView Core Technical Specification 3. © YouView TV Ltd (2011) Page 47 of 229 .3. Linux has been ported to run on a large number of silicon products. Porting to new hardware is a relatively simple due to the architecture of the kernel and the features that it supports. Device Operating System Linux has been selected as the Operating System for the device. Linux is deployed on millions of PCs and consumer electronics devices. or ported to Linux. and content from multiple sources. A robust security model. and the skills to develop and optimise for it are common in the industry. Dynamic memory management. This allows applications and other software service components to run in separate operating system processes with appropriate permissions to control access these services and the underlying system resources. A mature and full-featured IP stack. In addition. The Linux environment provides the following functionality as a basis for the development and operation of the device software stack:      Multi-processing. The Linux kernel and core libraries provide facilities for executing and scheduling multiple processes which enables the device to support multiple application frameworks and presentation technologies. Real-time constraints and priority-based scheduling. This is essential for enabling a wide range of content from trusted and un-trusted sources. 5. 4. Devices may be configured with additional Message Buses to support Service Provider or Manufacturer specific features. For third party applications. the assigned permissions depend on the origin of the application.org that provides transport for remote method calls. and are configured using information from the DNS domain and/or signing certificate. Message Bus Usage The Message Bus shall not be used for the transfer of audio and video streams.1. or to provide a callback function to receive the return value asynchronously. Message types The following message types shall be supported by the Message Bus and associated libraries. an open-source project from freedesktop.    Method calls on interfaces. Error handing Errors generated by software components on the Message Bus shall be reported using a specific error message type and shall be propagated to clients as exceptions (or error codes where appropriate). It was chosen as the IPC mechanism as it supports a suitable range of data types and usage patterns. and error messages. D-Bus security The D-Bus libraries provide security features. graphics pixel data or other high bandwidth data transfers. Separate mechanisms are required for high bandwidth transfers as appropriate to the hardware and software provided by silicon vendors. and access to services on the Message Bus.YouView Core Technical Specification 4. Errors. interfaces and methods. Return values from method calls. 4. © YouView TV Ltd (2011) Page 48 of 229 . D-Bus Session Bus – used for all services which are exposed to Applications. and associated codes and data. and signals emitted by objects.3. that are applied to objects. including policies and access control lists. This is managed by assigning permissions to each Application Player instance. 4.2. and configured with specific access controls for Platform and Content Provider Applications. Clients may block and wait for the return value. 4. Supported Message Buses Devices shall be configured with the following message buses:   D-Bus System Bus – the default bus for Linux D-Bus enabled processes.4. D-Bus has gained widespread support in Linux based systems. Message Bus Overview The primary mechanism for inter-process communication (IPC) for device software components is based on D-Bus. asynchronous events. 4. but is outside the scope of this specification.6. Message Bus 4. and can be used to allow or deny messages. and is used in the majority of desktop and embedded Linux distributions. Dynamic D-Bus Objects The Device shall support D-Bus Objects that represent dynamically created resources (exported to the bus at any time as required).freedesktop.components do not keep usage reference counts for these objects. D-Bus method calls from asynchronous C++ method calls with method_return message processing handled via a callback. D-Bus error generation from to C++ exception and error handling code. D-Bus error handling and conversion to C++ exceptions. Message Bus C++ Bindings The device shall support client (proxy) API bindings to D-Bus with the following features:          D-Bus method calls from synchronous C++ method calls. Implementations shall ensure that all reference counters associated with a client D-Bus Connection are decremented when that connection is closed.1.YouView Core Technical Specification 4.every client that requests use of the resource causes a reference count to be adjusted by the component providing that resource.html © YouView TV Ltd (2011) Page 49 of 229 . Processing D-Bus method calls in separate worker threads.8. Externally managed .org/doc/dbus-specification. D-Bus Specification http://dbus. It shall be possible to manage these D-Bus Objects in the following ways:  Reference counted . 4. Connections may be closed by the client process or by the D-Bus Daemon in the case where the client process terminates abnormally.7. Processing D-Bus method calls in the main message dispatcher thread. and the D-Bus Object (and usually the resource itself) will be destroyed when the reference count < 1.7. The device shall support server (adaptor) API bindings to D-Bus with the following features: D-Bus signal emitting from C++ event handling code. D-Bus signal handling and event dispatch to C++ code.  4. Validation of enumerations. which block until a method_return message. and will usually provide means to explicitly destroy objects. YouView Core Technical Specification 5. Device Operation 5.1. Time 5.1.1. Sources of time Devices shall support setting the device‟s clock using the following methods:    Parsing of a DVB TDT or TOT received in a broadcast transport stream From a time server using SNTP version 4 as defined in IETF RFC 5905 From a time server using NTP version 4 as defined in IETF RFC 5905 If the device is operating in a mode where broadcast or IP connectivity is not available, sources requiring that connectivity shall be ignored. Devices shall implement non-volatile storage for the last known time, for the purposes of detecting roll-back of time. 5.1.2. Behaviour on boot At initial boot, devices shall set the system clock to 1 January 2000 00:00 UTC. Once the device is in a suitable state to receive a broadcast signal (if connected), communicate over IP (if connected), it shall enter a time discovery process, until a time source is found that successfully sets the clock. st 5.1.3. Maintenance of time After a usable time source has been found, that source shall be used to maintain the system clock for the period until the next boot time or until a request to update the time from that source fails. 5.1.4. Broadcast time Devices shall consider a time value discovered from a broadcast TDT or TOT table valid if it is obtained from a transport stream that carries services present in the device‟s channel list. Acquisition of broadcast time shall be considered to have failed if no broadcast signal is present or if, after five seconds of monitoring a broadcast transport stream, no TDT or TOT with a valid CRC has been received. When broadcast time is in use, devices shall attempt to resynchronise the system clock at least once every 24 hours. 5.1.5. SNTP When configured to use SNTP, implementations shall not use a full NTP client to set the time. Note: this specifically excludes the use of „ntpdate‟. An example SNTP client is available in the reference NTP software distribution from ntp.org. Devices shall retry up to 5 times at one-second intervals to each configured server. Acquisition of time using SNTP shall be considered to have failed if no time has been received from a configured server within that time, or if the device does not have IP network connectivity. When SNTP time is configured, devices shall attempt to resynchronise the system clock at regular intervals, with an additional offset of a randomly chosen number of seconds uniformly distributed between 0 and 3599 to add to the configured polling interval in order to prevent bursts of requests to the servers. © YouView TV Ltd (2011) Page 50 of 229 YouView Core Technical Specification 5.1.6. Time zones The platform software or core device software shall contain one or more time zone definition files in the Linux „tz‟ file format. The time zone to use shall be configurable by the Platform Main UI. 5.1.7. Using time information Stored time values should be in the form of UTC time. When time needs to be presented to a viewer, it shall be converted to local time. Such conversions shall use the configured time zone definition file. This is typically achieved by using the standard Linux localtime() or localtime_r() functions. © YouView TV Ltd (2011) Page 51 of 229 YouView Core Technical Specification Chapter IV Consumer Device IP Networking © YouView TV Ltd (2011) Page 53 of 229 1. This chapter does not cover hardware requirements and network interfaces (which are covered in Chapter II Consumer Device Platform) or the provisioning of the device with configuration information (which is addressed by Chapter VI Consumer Device Software Management). Chapter audience This chapter is for: Device Manufacturers. This chapter is not relevant for: Content Providers Application Developers ISPs © YouView TV Ltd (2011) Page 54 of 229 . who need to:  Implement the device‟s core IP network stack in accordance with this chapter. Chapter Summary This chapter covers the specification and configuration of the core network stack and defines mechanisms for managing the resources available to the device‟s IP connection.YouView Core Technical Specification 1. 1. 255. which should be pre-filled with the first usable IP address calculated from the IP address and netmask (e. destination and originating process.1) DNS server addresses (devices shall allow at least two to be specified) Option to use an HTTP proxy. © YouView TV Ltd (2011) Page 55 of 229 .255.4 and a netmask of 255. Core specification Devices shall support IPv4. Higher level protocols are specified elsewhere in this chapter.2.1. 2. Manual configuration IPv6 capable devices shall allow the following IPv6 parameters to be configured manually:     IP address Subnet mask length Default gateway DNS server addresses (devices shall allow at least two to be specified) 2. The IP network stack shall support filtering. Performance The IP stack shall be capable of handling a throughput of at least three concurrent 10 Mbps TCP sessions. The default shall be to use DHCP. prioritisation and measurement of traffic based on protocol.g.168. Support for IPv6 will be required at a later date. Stub-resolver and DHCPv6.3.0. this field should be pre-filled with 192. IPv6-capable devices shall support the requirements of the IPv6 Node Requirements contained in the IETF draft update to RFC4294. IPv4 DNS server addresses shall be used.0. with an IP address of 192. 2.5. DHCPv6 configuration shall be attempted to obtain DNS server addresses. Multicast Multicast shall be fully supported at the Ethernet and IP layers. including proxy server address and port   2. Path MTU Discovery.1. This requires the use of IGMPv3. Devices shall allow the following parameters to be configured manually:    IP address Subnet mask Default gateway. source. TCP and UDP. 2.4. with support for Neighbour discovery. It is anticipated that content bitrates could range from around 700 kbps up to 10 Mbps for future HD content.4. ICMP.168.YouView Core Technical Specification 2. known as RFC4294bis. IPv4 configuration Devices shall support both automatic configuration of network interfaces using DHCP and manual configuration.0. IPv6 Support for IPv6 will be required at a later date. IP Network Stack 2. If this is unsuccessful. IGMPv3. Both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM) shall be supported. 2. HTTP profile Devices shall support HTTP/1.1.6. Cookies Some web services need to store information locally on the client to establish an HTTP session that spans a number of HTTP requests over a specified period of time.6. Devices shall support persistent cookies via the Max-Age directive according to IETF RFC 2109 for all HTTP requests made from presentation engines but not for other uses of HTTP. 2. POST. Response status codes shall be as specified in section 17.6.4. session cookies shall be retained until the device next enters standby and then discarded. HEAD.2. Devices shall support session cookies for HTTP requests made by all software components on the device.6.6. timeouts shall be as defined in DTG D-Book 7 Part A v1 section 17. as defined in IETF RFC 2616. Devices shall accept cookies in the "Netscape" format in order to provide compatibility with older HTTP/1.8. PUT and DELETE methods. HTTP Methods Devices shall support GET. This profile is a largely a superset of the profile included in DTG D-Book 7 Part A v1 and includes the features necessary to interact with modern web services.12.6. 2. Header fields Devices shall support all HTTP/1.6.0 servers.3. 2.1. Devices shall support session and persistent cookies via the Cookie request header and Set-Cookie response header as defined by IETF RFC 2109. Timeouts Except where otherwise stated. Unless otherwise stated for particular uses of HTTP.5. HTTP Authentication Devices are required to support extensions to HTTP Authentication as specified in IETF RFC 2617. Devices shall not accept cookies that have no path attribute. 2. © YouView TV Ltd (2011) Page 56 of 229 . Persistent cookies shall remain available after the device is restarted and shall survive a power cycle. Response status codes Devices shall not prompt the user of a device to make choices and get answers as a result of HTTP status codes. except as specified below.6. Devices are not required to support the use of any other HTTP methods.YouView Core Technical Specification Devices shall be able to handle an encrypted TLS session with a throughput of 8 Mbps (RC4 cipher) or 4 Mbps (AES128 cipher) without significant impact on the responsiveness of other device functions. Devices shall maintain separate cookie stores for holding persistent cookies created by different applications and different presentation engines.1 headers as specified in IETF RFC 2616.3 "Response status codes" of DTG DBook 7 Part A v1 except that the 201 Created response code shall be considered successful. 2. 2. 6. devices shall support use of a specific proxy for accessing A/V content via the device configuration mechanisms. Redirection from an http: URL to an https: URL and vice versa shall be supported.1 3xx redirection response codes shall be supported wherever HTTP is used. Devices shall support HTTP responses with a Content-Encoding header containing gzip or deflate. Devices shall support chains of at least 5 redirections. using the HTTP CONNECT method. the configured A/V proxy shall be used in preference to the default proxy when requesting A/V content. requests for timed text subtitle files (see Chapter IX IP Content Delivery) and requests from presentation engines.8. Proxy support Devices shall support the use of an HTTP proxy for all HTTP requests.7. © YouView TV Ltd (2011) Page 57 of 229 . Separately from the user‟s proxy settings which apply to all HTTP requests. HTTPS traffic shall use the same proxy. terminate the infinite loop and report the failure to the component making the request. 2. If a 300 “Multiple Choices” response code is received and the particular use of HTTP does not provide any means to choose between the representations offered. the response shall be treated as a 302 response if it contains a Location header and considered an error if it does not.YouView Core Technical Specification 2. This includes any use of HTTP by a bootloader for software upgrade. Note: libcurl supports these encodings transparently but this must be enabled by setting the CURLOPT_ENCODING option to an empty string. Redirection HTTP/1. This includes requests for adaptive bitrate manifests and segments. Encodings YouView devices shall offer at least “gzip” and “deflate” encodings in an Accept-Encoding header for all HTTP requests that could return text content including requests for adaptive bitrate manifest files (see Chapter IX IP Content Delivery). 2. Implementations shall detect infinite loop redirections.6. Where such a proxy has been specified.7. An example of a download likely to fall into this category would be the download of an asset that the viewer has indicated that they would like to acquire during an off-peak period. 3. High priority Background Downloads High priority Background Downloads are downloads that can take place at any time but may be suspended to maintain the performance of Time Critical Traffic. In addition. © YouView TV Ltd (2011) Page 58 of 229 .YouView Core Technical Specification 3. Low priority Background Downloads Low priority Background Downloads are downloads that can only take place during a defined time window and may be suspended to maintain the performance of Time Critical Traffic. This traffic includes:   A/V media streaming using any streaming protocol.1.3. This section describes how the device manages usage of the IP connection. the user may have a broadband tariff in which traffic is charged at different rates at different times of day.1. 3. 3. An example of a download likely to fall into this category would be the download of an application selected from the Platform Main UI. and is always permitted.1. Three classes of traffic are defined:    Time Critical Traffic High priority Background Downloads Low priority Background Downloads The mapping of individual cases of network use to these classes is outside the scope of this chapter.1. including IP linear channels Data requests over HTTP from software components and presentation engines. Introduction The device‟s IP network stack is used for a variety of purposes.2.1. Time Critical Traffic Time Critical Traffic relates to the acquisition of content and data that have been requested by the viewer for immediate use. some of which are time critical and some of which are not. IP Resource Management 3. the device shall wait for a random period in milliseconds between 0 and the value given by (4^currentRetry * 100) and then retry the request. foreground requests shall be retried for up to 30 seconds. 501. The maximum number of retries or the maximum total time during which to attempt retries varies depending on the type of request. © YouView TV Ltd (2011) Page 59 of 229 . devices shall not retry the request and shall deem it to have failed. If an HTTP 500 or 504 error response is received. If an HTTP 4xx. and so on. Back-off Mechanism for HTTP Requests This section specifies a standard back-off algorithm which shall be used when retrying HTTP requests that have failed. If no Retry-After header is present. Unless otherwise stated.YouView Core Technical Specification 4. up to 1600 ms before the second. the device shall wait for the specified period before retrying. This algorithm waits up to 400 ms before the first retry. or the device is unable to establish a connection to the server. 502 or 505 error response is received. the device shall proceed as defined for a 500 response above. The algorithm shall be used in all cases where HTTP requests need to be retried unless otherwise stated. If an HTTP 503 error response is received and a Retry-After header is present. background requests shall be retried for up to one hour. where currentRetry has the value 1 after the first failure and increments for each failed retry. . YouView Core Technical Specification Chapter V Consumer Device UI Model © YouView TV Ltd (2011) Page 61 of 229 . YouView Core Technical Specification 1. seamless experience. It also describes how these elements need to integrate together so as to result in a unified. 1. The model supports a federated approach where different parties provide elements of the user experience. Chapter audience This chapter is for : Device Manufacturers Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 62 of 229 . Chapter Summary This chapter defines a device UI model for how the user experience provided by a consumer device can be realised.1. The model provides a means for the Platform Main UI provider to deploy a common user experience across a range of devices from different manufacturers. discovery of on-demand content and portals. app store etc. This is distinct from the Settings application (see below) which allows the user to view and change all available settings.YouView Core Technical Specification 2. This type of application is produced by Content Providers and includes VOD portals and other third party services.    Figure 6 is a simplification of the interactions between these applications: Figure 6 : Interactions between the different types of application © YouView TV Ltd (2011) Page 63 of 229 . Content Provider Application. This application provides the primary interface that the user interacts with. It will include functionality such as: accessing linear channels. Platform Main UI. A successful connected television platform will have a many such applications. It steps the user through the minimum number of user settings required to configure the device into a usable state. Settings. This application allows the user to view and change the full range of user settings that govern the operation of the device. including presentation of schedule information. This application is run on the initial install of a device (or after a “reset to factory default state” action). Device UI Model Overview The Device UI Model defines four types of application that comprise elements of the overall user experience:  Setup. © YouView TV Ltd (2011) Page 64 of 229 . Introduction The Device UI Model supports a federated approach where different parties provide the applications comprising the overall user experience. UI Model Implementation 3.2. check IP network activity.2. Setup The Setup application uses a “wizard” paradigm to step the user through the minimum number of user settings required to configure the device into a usable state.g.1. they shall provide views onto the same underlying settings information. 3. These shall be implemented such that device manufacturers can provide code extensions to support device specific features. Figure 7 : Setup 3.YouView Core Technical Specification 3.2. Settings The Settings application provides the user with access to the full range of user settings within a hierarchical structure. The specific detail of these mechanisms is outside the scope of this specification.2. Setup and Settings The Setup and Settings applications are the responsibility of the Platform Main UI provider to supply. It also allows more than one party to contribute to the implementation and/or configuration of a particular application to support extension and customisation of the user experience. This approach ensures that a device manufacturer can achieve a high degree of integration with the underlying features of the device whilst maintaining a coherent user experience. Whilst the Setup and Settings applications may differ in user experience. check broadcast signal strength. Such code extensions shall be provided as a runtime code module (as appropriate for the presentation technology used for these applications) or an XML defined UI layout. Local Diagnostics functionality aims to help users solve problems of device operation. e. 3.1. but possible examples include: an ISP specific menu item within the Platform Main UI that launches an ISP application providing customer help.YouView Core Technical Specification Figure 8 : Settings 3.3. Platform Main UI The Platform Main UI application is the responsibility of the Platform Main UI provider to supply. This results in configuration data being loaded into the Data and Configuration Repository that can be read by a suitably privileged application. Such customisation shall be achieved using the configuration mechanism defined in Chapter VI Consumer Device Software Management. inclusion of device manufacturer branding on screens within the Platform Main UI. The specific detail of such customisation is beyond the scope of this specification. Figure 9 : Configuration of the Platform Main UI * Platform Main UI features are purely illustrative. This shall be implemented such that device manufacturers and ISPs can configure aspects of the Platform Main UI so as to customise its operation. © YouView TV Ltd (2011) Page 65 of 229 . g. referred to as the “Platform Main UI Library”. Such code extensions shall be provided as a runtime code module (as appropriate for the presentation technology used for these applications). Figure 10 : Content Providers applications © YouView TV Ltd (2011) Page 66 of 229 . Such applications will be launched from the Platform Main UI. following selection of the Content Provider application itself or an item of content dependent on the Content Provider application for its successful presentation. Certain Content Provider applications may need to be implemented such that they include UI provider supplied code extensions to manage certain aspects of user interaction. The specific detail of this mechanism is outside the scope of this specification. Content Provider applications Content Providers applications are the responsibility of content providers to provide. e.YouView Core Technical Specification 3. presentation of on-screen error dialogues. which benefit from being treated in a consistent manner with the Platform Main UI.4. YouView Core Technical Specification Chapter VI Consumer Device Software Management © YouView TV Ltd (2011) Page 67 of 229 . 1.YouView Core Technical Specification 1. who need to:   Implement a robust mechanism for discovery. This chapter is not relevant for: Application Developers Content Providers © YouView TV Ltd (2011) Page 68 of 229 . acquisition. Chapter Summary This chapter describes how software updates and configuration settings are managed on the device. verification and activation of updated versions of Core Device Software and Platform Software Implement support for the discovery and acquisition of updated versions of configuration files and store the updated configuration on the device ISPs. Audience This chapter is for: Device Manufacturers.    Core Device Software is installed and managed by the device manufacturer Platform Software contains the Platform Main UI and can be updated by the platform operator independently of manufacturers and without upgrading the Core Device Software Device configuration files contain parameters used to control aspects of the device‟s operation without needing to update either the Core Device Software or the Platform Software This chapter also introduces the logical components :   Local Storage Repository (LSR) Software Manager 1. to understand the device configuration mechanism and the means by which ISP-specific configuration is supported. Core Device Software 1:n Platform Software 1:n Device configuration Figure 11 : Relationship between software and configuration on the device 2. The configuration sources are.2. Device configuration can only be applied to a specific version of Platform Software.3.YouView Core Technical Specification 2. Software and Configuration Management 2.e.1 public key certificates all other native compiled executable code 2. Device configuration For the efficient operation of the platform. Platform Software The Platform Software is common to all devices and contains no native compiled executable code. Core Device Software The Core Device Software consists of:            bootloader(s) the Linux kernel the Linux root filesystem containing libraries and the core device software middleware required to support the operation of the device presentation engine software manufacturer-supplied data a version of the Platform Software compatible with the Core Device Software user interface components and associated assets required for the manufacturer-specific setup and configuration of the device manufacturer default configuration. Overview Figure 11 shows the relationship between these updatable packages. a number of configuration parameters are required. Platform Software can only be installed on a Core Device Software that is compatible. A configuration mechanism is specified in section 7 that allows for configuration parameters to be adjusted by a number of configuration sources. the Platform Provisioning File) the Platform Main UI application (including all images and data needed for off-line use) static data files and scripts 2. The Platform Software consists of:    default platform configuration (i.4.1. See section 7.1.   The device manufacturer The platform operator © YouView TV Ltd (2011) Page 69 of 229 . The YouView Software Manager (YVSM) interface in Figure 12 is described in this specification and is the interface used to download updated versions of Platform Software and YouView configuration. merges and applies new config Schedules updates ISP Discovery Power Manager ISP Config ISP Back-end functionality Client-facing interface Web services ISP Config Figure 12 : Architecture for software management © YouView TV Ltd (2011) Page 70 of 229 .YouView Core Technical Specification   The viewer's Internet Service Provider (ISP) and The viewer themselves The logical components that are involved in device configuration are shown in Figure 12. The Local Storage Repository (LSR) represents a repository containing the device configuration and is also queried to get information about the state of the device. YouView Back-end functionality Client-facing interface Device Platform Main UI Web servers YVSM Local Storage Repository Platform Software YouView Config ISP redirect Web services Software Manager Reads config Updates. YouView Core Technical Specification 3. Initial device state The device shall be manufactured such that it includes a version of Core Device Software. Device software packages © YouView TV Ltd (2011) Page 71 of 229 . This contains a version of the Platform Software compatible with the Core Device Software so that when the device starts for the first time a version of the Platform Main UI is available. Core Device Software (updates managed by the manufacturer) Default Platform Software Figure 13 . The device shall include a default version of the Platform Software within the Core Device Software. Platform Software and device configuration files.YouView Core Technical Specification 4. The duration of the Scheduled Update Check Window is calculated by subtracting the Update Acquisition Duration from the Update Window Duration. In addition to this mechanism the device shall support recovery from USB Mass Storage Device.1.1.1.1. Distributed Time Windows of time are defined in which tasks shall be performed.1.2. Scheduled Update Check Window The Scheduled Update Check Window is a period of time within the Update Window that commences at the start of the Update Window.1. Other regulatory requirements and trademark licences may require that the device support additional update mechanisms. Scheduled Update Check Time The Scheduled Update Check Time is a Distributed Time within the Scheduled Update Check Window at which the Software Manager component shall check for the availability of updates and if © YouView TV Ltd (2011) Page 72 of 229 . This is to minimise the peak load on platform and manufacturer infrastructure.1. 4.6.1. Automatically checking for updates The way in which updates are automatically checked for and acquired shall be modelled using the following concepts. 4.1. The viewer shall not be notified or asked to confirm a software or configuration updates. Update Window The Update Window is the time period in which updates may be acquired.1. However.1. The device shall not inform the viewer when a software update or configuration update fails. Update Time The Update Time is a Distributed Time within the Update Window at which acquisition of an update will commence. 4.3. 4. Update in the field The logical Software Manager component shall support the update of Core Device Software. Concepts to do with scheduling automated updates 4. Within a Window. The Update Window will be initialised to be the same as the Default Update Window.1. and informs subsequent scheduling rules. a Distributed Time shall be allocated to ensure that the times when devices in the deployed population check for updates and/or start the acquisition of updates is evenly distributed.1. 4.4.1.1. The Default Update Window is the update window configured by the platform operator. 4.1. the device settings may include an option through which the viewer can explicitly disable automatic software updates.5. See Chapter VII Consumer Device Storage Management. Update Acquisition Duration The Update Acquisition Duration represents the amount of time that a typical update acquisition may take. It shall automatically perform updates over the IP connection using the mechanisms described in this chapter and also provide means to allow updates to be performed manually. 4. 1. © YouView TV Ltd (2011) Page 73 of 229 .1. During this window the Software Manager component shall not perform update acquisition. The start of the Opportunistic Update Check Window is calculated by subtracting the Opportunistic Check Window Duration from the Update Window start time.1. 4. Opportunistic Update Check Time The Opportunistic Update Check Time is a Distributed Time within the Opportunistic Update Check Window at which the Software Manager component shall check for the availability of updates but shall not perform update acquisition.1.1.1.YouView Core Technical Specification they are available. 4. Update Check Window The Update Check Window is a period of time commencing at the start of the Opportunistic Update Check Window and ending at the end of the Scheduled Update Check Window. will set the Update Time to the current time and immediately attempt to initiate their acquisition. 4.7.9. Opportunistic Update Check Window The Opportunistic Update Check Window is a period of time immediately preceding the start of the Update Window.8. Overview Devices shall support upgrading of the Core Device Software over the IP connection. 5. 5.1. After a successful activation of the Core Device Software the Local Storage Repository (LSR) shall contain:       The manufacturer's name The manufacturer's OUI The device model number The OEM's 3 character vendor ID that makes up the first part of the device registered PNPID Core Device Software compatibility version number Core Device Software version number © YouView TV Ltd (2011) Page 74 of 229 . Minimum requirements for the installation of the Core Device Software are defined in Chapter VII Consumer Device Storage Management. The method for acquiring an updated version of Core Device Software is manufacturer private. Installing an updated version of Core Device Software The installation of an updated version of Core Device Software is manufacturer private.3. 5. Software images shall be encrypted in delivery and on any public facing servers on which they are hosted. Activating an updated version of Core Device Software The method used to activate an updated version of Core Device Software is manufacturer private. Verifying an updated version of Core Device Software The verification of an updated version of Core Device Software is manufacturer private. When it resumes it shall be able to continue from a partially completed acquisition. The acquisition function shall allow for acquisition to be interrupted or suspended. Acquiring an updated version Core Device Software The Software Manager shall acquire an updated version of Core Device Software as described in section 4.5.2.4.YouView Core Technical Specification 5. Core Device Software update 5. Manufacturers are responsible for implementing a mechanism for secure and reliable update. Checking for an updated version of Core Device Software The Software Manager shall check for updates to the Core Device Software as described in section 4.1.1. 5. 5. The Core Device Software may be divided into separate parts for the purposes of updating.6. After installing the Core Device Software the device shall check for and if necessary install an updated version of the Platform Software as defined in section 6. This is determined by the Compatibility Version specified in the header of the Platform Software Image.  ACQUISITION_FAILED: The device has failed to acquire. A Platform Software acquisition can also end up in one of the following error states. install and activate the updated version of Platform software using the process described in section 6. Devices shall be able to store at least two versions of the Platform Software in addition to any versions of Platform Software provided in the Core Device Software on the device. Overview Devices shall use the following steps to update the Platform Software. acquire the updated version of Platform Software 3. Unpack and install the updated version of Platform Software 5.2. 6. Activate the updated version of Platform Software for use after the next restart 6. The device shall only activate a version of Platform Software if it is compatible with the active Core Device Software.YouView Core Technical Specification 6.1. The device shall then acquire. Platform Software update 6. The device may delete Platform Software versions that are no longer required (except for the last known good version) as a result of an updated version of Platform Software having been activated. If any of the update steps fail the device shall continue to use the currently activated version of the Platform Software. The download process is described in section 6. © YouView TV Ltd (2011) Page 75 of 229 . verify.2.3.2. Restart the device Details of each of these steps are provided in the following sections. Periodically check for an updated version of the Platform Software 2.2. Each Platform Software image can be in one of the following states and will move through these states during the process of updating the Platform Software version. The device shall then parse the Platform Software Image Manifest to determine if there is an updated Platform Software image is available according to the business rules described in section 6.1. If an updated version is available.2.1. Checking for an updated version of Platform Software The Software Manager shall check for updates to the Platform Software as described in section 4. Verify the encrypted and signed downloaded Platform Software Image 4. verify and activate the updated version of Platform Software.     ACQUIRING: The device is downloading an updated version of the Platform Software SUSPENDED: The device has suspended the acquisition of the updated version of Platform Software INSTALLED: The Platform Software with a specific version is installed but not active ACTIVE: The currently installed and active Platform Software version. This is the version of Platform Software that is automatically run when the device boots and there can be only one active Platform Software version. 1. The device shall check for availability of an updated version of Platform Software by downloading a Platform Software Image Manifest and comparing the metadata in the manifest with the version of the currently installed and active Platform Software and the Compatibility Version supported by the device. The variables that form part of the URL template are described in Table 13. The version of the currently installed and active Platform Software. Device action Proceed to the next step in the process of upgrading Platform Software. The device shall replace the variables in the URL template with the appropriate configuration values. Occurs when the device presents the server with the ETag of the previous request.1.xml?oem=${manuf acturer}&model=${model} When downloading the Platform Software Image Manifest. This can be used. HTTP Response 200 OK 304 Not Modified Description The manifest file has been downloaded successfully. Table 13 Platform Software URL Template Variables ${platform_software} ${policy} Examples of URL template are: ${baseurl}/${compatibility_version}/${platform_software}. for example. The serialization format is: [major_version]. The device shall take the actions in the following table based on the HTTP response status code returned when downloading the Platform Software Image Manifest. © YouView TV Ltd (2011) Page 76 of 229 . The Platform Software Image Manifest hasn‟t changed since the last time the device requested it. to indicate if the device is willing to accept updates as part of a “beta” programme. The manifest file hasn‟t changed so there is no updated version of Platform Software available for this device.[minor_version]. The current policy for accepting updates to the Platform Software.[revision] Where the major_version and minor_version are 16 bit integers and the revision is an 8 bit integer. Any other HTTP status code including HTTP redirects and errors. The URL encoded name of the manufacturer The URL encoded device model number The version number of the Core Device Software currently installed and running on the device This Compatibility Version advertises the capabilities of the Core Device Software. All other status codes The device shall deal with any other status codes as described in Chapter IV Consumer Device IP Networking. Downloading the Platform Software Image Manifest The Platform Software Image (PSI) Manifest location shall be formed from a URL template which contains a number of variables.2. if the HTTP response contains an ETag header the device shall store that ETag in the LSR and include that ETag in an If-None-Match header for all subsequent requests to check for the Platform Software Image Manifest.xml and ${baseurl}/${compatibility_version}/${platform_software}. Table 14 : HTTP response status codes The Platform Software Image Manifest HTTP response shall be Content-Type: text/xml.YouView Core Technical Specification 6. Variable ${baseurl} ${manufacturer} ${model} ${core_software} ${compatibility_version} Description The Base URL of the platform software image availability manifest. In the event that a download of the Platform Software Image Manifest fails on five consecutive occasions. Verify that the Platform Software image came from the platform operator by verifying the signature provided as described in section 6. Downloading a Platform Software Image The Platform Software Image shall be packaged using the format described in section 6.YouView Core Technical Specification The body of the HTTP response shall be the Platform Software Image Manifest in the format described in section 6.1.4.4.1) 2.4.3. 1.2. See 6. The device shall download the updated Platform Software Image (PSI) using a HTP/1. The device does not already have an installed version of Platform Software that is waiting to be activated. Whether an updated version of Platform Software is required Once the device has successfully downloaded a Platform Software Image (PSI) Manifest it shall parse the PSI manifest and based on the its contents decide if an updated version of Platform Software needs to be acquired.3.3. 6.4.2. the device shall revert to the base URL and URL template configured in the Platform Provisioning File for the next attempt. 6. Decrypt the platform software image as described in section 6. 6.1 GET request to the URL provided in the Platform Software Image Manifest.2.2. If the device receives a HTTP 200 or HTTP 304 response code from the request for the PSI manifest it shall store the current date and time in the LSR.3.3 4. decrypt and install it using the procedure‟s described below. An updated version of the Platform Software needs to be acquired if all of the following conditions are met.4. Assert that no certificate in the signer‟s certificate chain has been revoked using the CRL packaged with the signed-data of the Platform Software update package. 6. Check the preconditions on the plaintext PSID in the Platform Software image (as described in section 6.7. Acquiring an updated Platform Software Image The Software Manager shall schedule acquisition of Platform Software updates as described in section 4. verified.     The Compatibility Version in the PSI manifest is the same as the Compatibility Version supported by the active Core Device Software The Platform Software version number is greater than the active version of Platform Software The device is not already downloading an updated version of the Platform Software.4.1. Verifying an updated Platform Software Image Once an updated Platform Software image is available locally the device shall verify that the image is signed by the platform operator. If the download of the PSI is interrupted for any reason the device shall resume the download of the PSI using HTTP byte-range requests.youview. 3.com/schemas/PlatformSoftwareImageManifest/2010-10-05 6. installed and activated.2 © YouView TV Ltd (2011) Page 77 of 229 . Format of the Platform Software Image Manifest The Platform Software Image (PSI) Manifest format is an XML file using the schema http://refdata. Devices shall verify a Platform Software image using the following steps. 1.826. © YouView TV Ltd (2011) Page 78 of 229 . Mark the updated version of Platform Software as ready for activation If the viewer has disabled automatic standby on idle. 0xA5 2. CRL validation processing shall use a fresh CRL. Devices shall check the presence of this policy and its chain and if it is not present verification shall fail.7308805.2.4. 0x00. the device may alert the viewer that the device will enter standby and the software update will take place when no recording or other activity is taking place.4.4. The user may be presented with an option to defer the update procedure but not to cancel it. Assert the Platform Software image version is greater than the installed and active Platform Software version 5. 0x01 3. Devices shall assert that the Signed-data section (RFC 5652 Section 5) has been signed by the platform operator. The certificate policy term 1. Verification Devices shall calculate a message digest of the signed content and verify the digital signature as per RFC 5652 Section 5.1 If any of the verification steps above fail. 6. Intermediate certificates shall either have the same policy term or the RFC 5280 defined anyPolicy. Installing an updated version of Platform Software Once an updated Platform Software Image (PSI) has been successfully downloaded and verified it shall be installed using the following process.3. 6. Preconditions of a PSID The device shall assert the following preconditions on the Platform Software Image Identifier (PSID) and the verified PSID before installing a Platform Software image and making it available for use: 1.2. The algorithm used shall be AES128-CBC. 6. Assert all 8 bytes of the capabilities section are 0x00 6. 0x00. then the installation of the updated version of Platform Software shall be terminated. If the CRL packaged within the signed-data is considered current relative to the next update time in the CRL then validation shall use this CRL for processing certificates.4.1. Copy the updated version of Platform Software 2. Assert the magic cookie is 0xCA.5. 1. Assert the required Compatibility Version is equal to the Compatibility Version supported by the Core Device Software 4. Certificate revocation The freshest version of the Platform Management CA CRL and the platform operator Authority Revocation List (ARL) shall be included in the CRL component of the signed-data. 6.6.4.YouView Core Technical Specification 5.1. Decryption TK1 shall be decrypted using the device‟s Platform Software private key.0. The Platform Software image shall be decrypted using TK1.1 shall be explicitly present in the signer's certificate. Assert the Platform Software packaging format version identifier is 0x00. Check the preconditions on the verified PSID as described in section 6.4. The Platform Software packaging format describes the format of the Platform Software image downloaded in order to update the Platform Software. Activating an installed version of Platform Software Once an updated version of Platform Software is installed.3. 6. The Platform Software image shall be of the form: Item Platform Software Image Descriptor (PSID) { CMS Signed-data } (as per: section 6. 0x01) Revision (e. 0x00) Platform Software major version (e.7.g. with a pre-pended Platform Software Image Descriptor (PSID). Platform Software packaging format The Platform Software image shall be a single signed.7. It will be encrypted as described in section 6. 0x02) Minor version (e.7.g.3.1. 0xA5 0x00. The device shall activate the updated version of Platform Software by making the changes required so that the next time the device restarts or leaves deep standby the updated version of Platform Software shall be used.g. 6. Platform Software Image Descriptor (PSID) The Platform Software Image Descriptor (PSID) shall be of the form: Item Magic cookie Platform Software packaging format version identifier Unused Required Compatibility Version: major version Required Compatibility Version: minor version Required Compatibility Version: revision Platform Software image major version Contents 0xCA. 0x01 undefined Major version (e.3. 0x02) Size (bytes) 0x02 0x04 0x0A 0x01 0x01 0x02 0x01 © YouView TV Ltd (2011) Page 79 of 229 .YouView Core Technical Specification 6. 6.7. 0x00. encrypted cramfs filesystem image. If the activation and restart with the updated version of Platform Software fails. Platform Software Image The Platform Software image shall be of type CMS Signed-data as described in RFC 5652 Section 5.7.2. The Platform Software update package contains a Platform Software digital envelope and a Platform Software image. Platform Software digital envelope The Platform Software digital envelope shall be of type CMS Enveloped-Data with detached content as described in RFC 5652 Section 6. 0x00.3. ready to be mounted and used it shall be activated.2 and RFC 5652 Section 5) TK1 (AES-128-CBC) Offset (bytes) 0x00 0x20 Size (bytes) 0x20 variable Table 15 : Platform Software image 6. 0x00.6.7. the device shall fall back to the last known good version of the Platform Software and that shall be the active version. All other previously active versions of Platform Software that may be installed shall be marked as inactive.g. Signing The platform operator shall provide a Platform Software signing X. 0x00) 0x00 (all 8 bytes) Table 16 : Platform Software Image Descriptor Size (bytes) 0x01 0x02 0x08 The Platform Software packaging format version identifier is used to indicate the version of the packaging format used by the Platform Software image. 0x01) Platform Software revision (e. Encapsulated Content The eContent section (RFC5652 Section 5.YouView Core Technical Specification Item Platform Software image minor version Platform Software image revision Capabilities Contents Platform Software minor version (e.7. The private component of the Platform Software signing certificate key shall be used to compute the signature. The Capabilities item is a reserved section of the PSID which will be used at a later date to indicate the device capabilities which are compatible with a specific version a Platform Software image.2) of the CMS Signed-data section shall be of the form: Item Platform Software Image Descriptor (PSID) CramFS image Offset (bytes) 0x00 0x20 Table 17 : Encapsulated Content Size (bytes) 0x20 Variable The PSID is duplicated in the encapsulated content section since this part of the message is verifiable. The Platform Software image version number will increment with each updated release. © YouView TV Ltd (2011) Page 80 of 229 . The digest algorithm shall be SHA256. 6. Versions of the Platform Software and the Required Compatibility Version shall be identified by major. Encryption Manufacturers shall provide the platform operator with one or more key transport keys.509 (RFC 5280) certificate containing an RSA 2048 bit public key in the SignerInfo section of Platform Software image. minor and revision numbers. 6. Each key transport key (KTK) shall be a 2048 bit RSA public key.3.7. 6. The Platform Software signing certificate and any intermediate certificates up to but not including trust anchor shall be carried in the certificates component of the signed-data. The device shall only install a Platform Software if the Compatibility Version is supported by the Core Device Software.3.2. Multi-byte fields in the PSID shall be big-endian unsigned integers.g. 0x00. The signature algorithm shall be RSASSA-PKCS1-v1_5.3.g. The SHA256 digest shall be computed over the plain-text Platform Software image.1.3.7. The Platform Software image will be encrypted using the CEK. The content encryption key shall be a 128 bit key. The Content Encryption Key (CEK) shall be encrypted by the platform operator once for each KTK provided to the platform operator. Each encrypted CEK shall be packaged in a KeyTransRecipientInfo structure. © YouView TV Ltd (2011) Page 81 of 229 . The packager shall encrypt the CEK with RSAES-OAEP under each of the manufacturer supplied public keys.YouView Core Technical Specification The private key component of the device KTK shall be stored as a device secret. The block termination padding algorithm shall be the algorithm defined in RFC 3852. The bulk encryption algorithm used shall be AES-128-CBC. The platform operator shall generate a new random content encryption key for each distribution of the Platform Software image. This structure shall use the subjectKeyIdentifier supplied in the OEM public key certificate as the RecipientIdentifier. Sources of configuration data are processed in the specific order outlined in section 7. the access control mechanism described in section 7. Platform Configuration is provided on the network by the platform operator at a pre-defined location. Local configuration sources The device has two local sources of configuration:   Manufacturer default configuration and Platform operator default configuration.2 to arrive at a merged database of configuration values. The device uses a single pre-defined URI to check for updates to the ISP configuration and download the updated configuration file if one exists.1. When configuration updates are processed.2 is used to ensure that parameters are overwritten only where there is permission to do so. This location defines the URI the device uses to check for updates to the platform configuration and download the updated configuration file if one exists. Redirection or other means allow the file to be served by the ISP themselves. Manufacturer Configuration may be provided on the network by the manufacturer at a pre-defined location.1. Configuration sources 7. ISP Configuration may be provided on the network by the viewer's ISP if the ISP is a participating ISP. the device configuration contains a set of defined base URL and URL template from which configuration data must periodically be gathered A set of named configuration parameters and the configuration sources that have permission to set each of these parameters is defined by the platform operator.1. The platform operator default configuration shall be contained in the Platform Provisioning File provided as part of the Platform Software. This configuration merging operation is repeated when any one of the configuration sources has changed and is successfully downloaded.1. A configuration mechanism is specified that allows for configuration parameters to be adjusted by a number of configuration sources.2. the platform operator.1. The configuration sources are the device manufacturer. The order in which the configuration sources are applied determines which configuration sources are able to set and overwrite values set by another configuration source. Figure 14 shows how the sources of configuration information are managed and the order in which they are applied to the Local Storage Repository: © YouView TV Ltd (2011) Page 82 of 229 . the viewer's Internet Service Provider (ISP) and the viewer themselves.1.1. 7. 7. a number of configuration parameters are required. To enable this. Device configuration 7. The manufacturer shall apply its default configuration to the Local Storage Repository before applying any other local or remote configuration.1.YouView Core Technical Specification 7.1.1. Remote configuration sources The remote configuration sources used to configure the device and are applied in the order defined here. Overview For the efficient operation of the platform. When a configuration parameter is retrieved from the Local Storage Repository (LSR) and that value has previously been set by any application other than the configuration update process then the device shall return the configuration parameter value saved by the application. If updated configuration is available the response shall be a HTTP/1. 7. Configuration parameters that are set by an application other than the configuration process shall not be overwritten by configuration updates. Core Device Software updates or Platform Software updates. If the configuration has not changed since the last configuration update check the device shall receive a HTTP/1. All viewer settings shall be deleted when the device performs a factory reset. The body of the HTTP response shall be the XML configuration in the format described in section 7. These configuration parameters may be set by the Platform Main UI or any other application with the appropriate permissions. Otherwise the value from the active configuration created by the configuration update and merge process shall be returned.1 200 OK response.org 1 Cert Config 4 Legend Yellow circles indicate the order of processing after an update Figure 14 : Configuration sources and their processing order 7.com Active Configuration 5 User settings Cert Config 3 ispconfig. See Chapter VII Consumer Device Storage Management.5.1.org 2 Cert Config Local Storage Repository config.1 GET request and the base URL and URL template as described below. If there is no configuration available or the server decided not to configure this device then a HTTP 204 No Content response shall be returned.platform.2.platform. Acquiring updated configuration Devices shall download updated configuration data using an HTTP/1.YouView Core Technical Specification Device Software Platform root certificate Platform Provisioning File static local configuration sources 1 Applications config.3. When the device receives a HTTP 204 response that indicates that no configuration shall be applied to the device for this configuration source. Viewer and Application Configuration The viewer shall have the ability to change device configuration.1 304 Not Modified response and the device shall continue to use the last configuration downloaded.1. The result of the merge of configuration values in the LSR © YouView TV Ltd (2011) Page 83 of 229 .manufacturer. If the download fails due to an authoritative response that the domain name (or a domain name referenced in an HTTP redirect) does not exist. Unless the device is physically powered off it shall update the device configuration. ${platform_software} ${config_name} © YouView TV Ltd (2011) Page 84 of 229 . The URL encoded name of the manufacturer The URL encoded device model number The version number of the Core Device Software currently installed and running on the device This identifies the Compatibility Version supported by the Core Device Software in the format: [major_version]. the device shall add an If-None-Match HTTP header to the request quoting the ETag value for that configuration source. Variable ${baseurl} ${manufacturer} ${model} ${core_software} ${compatibility_version} Description The Base URL of the platform configuration check and download. Devices shall implement the back-off mechanism for HTTP errors and HTTP redirections as described in Chapter IV Consumer Device IP Networking.[revision] The version of the active Platform Software.1. If an ETag is not available from a previous request the device shall send an If-Modified-Since header quoting the date and time at which the last successful download of the relevant configuration was achieved. 7. the device shall treat that source as providing an empty configuration file and continue with the configuration update. If the download fails for any other reason (including but not limited to any non-authoritative DNS error. HTTP 4xx or 5xx response).2. i. TCP/IP connection error. The name of the Platform Configuration location that should be checked for an update. Devices shall check for updated configuration and apply it from all power modes. The following table shows the variables that shall form part of the URL template. The Platform Provisioning File.e. 7. Platform Configuration Location The device shall check for updated Platform Configuration and download it using a URL constructed from the URL template contained in the LSR.2.1.2. If the base URI of the last successful configuration update fails then the device shall use the base URI provided as part of the default platform configuration. If a platform or ISP configuration update base URI fails five times the device shall use the base URI of the last successful configuration update. if one is available. After a successful download of a configuration from the platform operator the device shall store the ETag in the LSR for use during future configuration updates. i.e. The URL template consists of a number of URL template variables that shall be replaced by the appropriate values. devices shall treat this as a transient failure and continue to use the most recent successfully-merged configuration file for that configuration source. The device shall not send a request with both If-None-Match and If-Modified-Since headers.[minor_version].YouView Core Technical Specification shall not contain previous values from a remote configuration source that has responded with a 204 No Content HTTP response. When to check for configuration updates The Software Manager shall check for updates to the platform operator and ISP configuration as described in 4. Platform configuration updates can change the base URL and URL template of the configuration update service. If an ETag header was provided with a previous response from a specific configuration source. 7.2.3.[minor_version]. The manufacturer name URL encoded The URL encoded device model number The version number of the Core Device Software active on the device This identifies the Compatibility Version supported by the Core Device Software in the format: [major_version].cms When the device checks for ISP configuration it shall save the last checked time in the LSR. 7. ISP Configuration Location The device shall check for an updated ISP Configuration and download it using a URL constructed from the URL template definition in the LSR. When the device successfully downloads and applies updated platform configuration to the device it shall save the current time in the LSR.[revision] The version of the Platform Software currently installed and running on the device.1.1.cms The device shall be configured with a secondary base URI for platform configuration updates and if configuration updates fail using the first base URI the device shall attempt the update using the secondary base URI.YouView Core Technical Specification Table 18 Platform Configuration URL Template Variables Examples of the URL template are: ${baseurl}/${manufacturer}/${model}/${core_software}/${platform_software}/$ {config_name} or ${baseurl}/${config_name}-${platform_software}.2. When the device successfully downloads and applies updated ISP configuration to the device it shall save the current time in the LSR. Table 19 ISP Configuration URL Template Variables ${platform_software} ${config_name} Examples of the URL template are: ${baseurl}/${manufacturer}/${model}/${core_software}/${platform_software}/$ {config_name} or ${baseurl}/${config_name}-${core_software}-${platform_software}. When the device checks for platform configuration it shall update the last checked time stored in the LSR.4.2 or another mechanism of their choosing.2. © YouView TV Ltd (2011) Page 85 of 229 . Manufacturer Configuration Location A manufacturer may choose to download and apply manufacturer configuration to the device using the mechanism described in section 7. The URL template consists of a number of URL template variables that shall be replaced with the appropriate values. If the manufacturer remote configuration is being applied to the Local Storage Repository then it shall be applied in the order specified in section 7. Variable ${baseurl} ${manufacturer} ${model} ${core_software} ${compatibility_version} Description The Base URL of the ISP configuration check and download. The name of the ISP Configuration location that should be checked for an update. The following table shows the variables that shall form part of the URL template. 0. © YouView TV Ltd (2011) Page 86 of 229 .826.[revision] The version of the Platform Software currently installed and running on the device.2 shall be explicitly present in the signer's certificate when verifying platform configuration.2. Table 20 OEM Configuration URL Template Variables ${platform_software} ${config_name} Examples of URL template values are: ${baseurl}/${manufacturer}/${model}/${core_software}/${platform_software}/$ {config_name} or ${baseurl}/${config_name}-${core_software}-${platform_software}. Intermediate certificates shall either have the same policy term or the RFC 5280 defined anyPolicy.1.826.3 shall be explicitly present in the signer's certificate when verifying ISP configuration.0.1. The following table shows the variables that shall form part of the URL template. The certificate policy term for platform configuration 1. Authentication Configuration files downloaded to the device shall be signed.3. The name of the OEM Configuration location that should be checked for an update.YouView Core Technical Specification The device may check for an updated Manufacturer Configuration and download it using a URL constructed from the URL template contained in the LSR. This configuration signing CA certificate shall be provided in the CMS Certificates section. The device shall successfully verify the signature.cms 7. as described in RFC5652 section 5.3. Configuration is signed by the organisation that created it using their configuration signing key and packaged with their corresponding certificate signed by the platform operator.[minor_version]. The signature method is CMS as defined in RFC 5652 with an unencrypted data section and using RSA.1.1. The URL template consists of a number of URL template variables that shall be replaced with the appropriate values.1. Verifying updated configuration The platform operator and ISP configuration files shall use the file format defined in section 7. Devices shall check the presence of the relevant policy when verifying the signing certificate and if it is not present verification shall fail.2. Variable ${baseurl} ${manufacturer} ${model} ${core_software} ${compatibility_version} Description The Base URL of the OEM configuration check and download. the configuration parameters shall not be applied to the device.5.7308805. 7. If verification of the signature fails or verification of the certificate chain fails. The certificate policy term for ISP configuration 1. certificate chain and certificate policy before applying the configuration parameters.7308805. The configuration signing certificate shall be identified as the SignerIdentifier.3. The manufacturer name URL encoded The URL encoded device model number The version number of the Core Device Software currently installed and running on the device This identifies the Compatibility Version supported by the Core Device Software in the format: [major_version]. Update the configuration value in the database with the value from the configuration file. 7. Platform provisioning file example <?xml version="1.youview.5. else return the Local Storage Repository to its previous state.software.5.3. If all configuration updates were successful then commit the configuration update transaction. During a configuration update any applications accessing the Local Storage Repository shall continue to retrieve the previously configured parameters.com/schemas/config/2010-0505" xsi:schemaLocation="http://refdata. Certificate revocation The device shall assert that no certificate in the configuration signer‟s certificate chain has been revoked. b. For all parameters that have changed create a notification of the change.2.com/schemas/config/2010-05-05 7.name">Platform Software v3.4.youview. 7.com/schemas/config/201005-05 config. Installing updated configuration When the device determines that a configuration source has changed and has downloaded the updated configuration using the method in section 7.0" encoding="UTF-8"?> <config xmlns:xsi="http://www.5.2</item> <item name="platform. manufacturer and ISP configuration in that order: a.org/2001/XMLSchema-instance" xmlns:cfg="http://refdata.w3.youview. 3.1. Configuration packaging format The configuration format is an XML file using the schema http://refdata.xsd" version="1"> <item name="platform.2 the device shall update the configuration database using a process equivalent to that described below: 1. Verify the configuration file is valid using the process described in section 7.5. 2.2</item> </config> © YouView TV Ltd (2011) Page 87 of 229 . Start a transaction so that configuration updates can be applied atomically to the Local Storage Repository. If verification is successful then for each parameter: i.YouView Core Technical Specification 7.3.version">3.software. For each of the last downloaded configuration files for platform. Initialise the Local Storage Repository with the default configuration taken from the Platform Provisioning File. c. . YouView Core Technical Specification Chapter VII Consumer Device Storage Management © YouView TV Ltd (2011) Page 89 of 229 . YouView Core Technical Specification 1. and associated data management functions. 1. Audience This chapter is for: Device Manufacturers This chapter is not relevant for: Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 90 of 229 .1. Chapter Summary This chapter specifies requirements for storage systems integrated into the Consumer Device. Read-only software images Core Device Software and Platform Software images shall be mounted read-only as they are cryptographically signed as part of the packaging and distribution process and must not be altered.2. Note: By its nature. such as the device serial number and DRM personalisation data.3. 2.5.4. the majority of permanent data will be subject further storage requirements. Replacement of integrated storage For device variants that have user-replaceable integrated storage. but not accessible by Content Provider Applications. shall be stored in a manner such that it can survive a Factory Reset. are deleted or cleared.1. Storage of permanent data Permanent data. 2. Temporary storage in memory Writeable media data – used to store recorded or downloaded content. HD DVR devices shall also support: 2. all required data partitions shall be initialised during the subsequent boot process to ensure the device operates correctly. Storage Types 2. Core Device Software images shall not be stored in user-replaceable integrated storage. © YouView TV Ltd (2011) Page 91 of 229 . for reasons of security and/or privacy.6. for example after a Factory Reset. Writeable storage types Devices shall support the following writeable storage areas:      Writeable data – only accessible by the Core Device Software and further restricted on a perprocess group membership basis. The device shall also include a software recovery mechanism that allows the Core Device Software to be installed via the IP Network or USB storage device. At the time of manufacture the device shall contain 2 identical copies of the Core Device Software. that should contain valid data for correct operation of the device. 2. 2. Start-up after storage partitions have been cleared The device shall initiate the process of installation and setup in the event that writable data storage partitions.YouView Core Technical Specification 2. Writeable data – accessible by Platform Applications. Backup copies of Core Device Software The device shall maintain a copy of a previously verified Core Device Software image to ensure correct operation in the event that the version of Core Device Software in use becomes corrupted. These images can be replaced via software update mechanisms described in Chapter VI Consumer Device Software Management. once a replacement storage device has been installed. Writeable data – accessible by Content Provider Applications. leaving the device in the same state as a new product. As no interaction with an on-screen UI is required.3. The details of controlling access to such a feature or the on-screen warnings to prevent misuse are beyond the scope of this specification. 3. This mechanism provides the capability to optionally give the viewer the choice of removing or retaining certain items. 3.YouView Core Technical Specification 3. or as a last resort if it has stopped functioning correctly due to data corruption. Initiating a Factory Reset shall result in a reboot of the device.1.2. this mechanism can be used even if a display is not connected. Initiating the Factory Reset function Devices shall support 2 mechanisms for initiating a Factory Reset:  Hardware Initiated Factory Reset. configuration and settings. The most recently installed Core Device Software version. and the relevant data will be subsequently erased. The function may offer the viewer the opportunity to preserve recorded content or other media assets. will be retained. © YouView TV Ltd (2011) Page 92 of 229 . The Factory Reset function will remove all personal data. Scope of the Factory Reset function The Factory Reset function does not return the device to the condition in which it was originally manufactured.  UI Initiated Factory Reset. 3. This is initiated by pressing a button or combination of buttons on the front panel of the unit. but puts it into a state as if it had just been manufactured: with the exception that recorded or downloaded AV media stored on the device may optionally be retained. Effect of the Factory Reset function This is defined in the table in Section 5. Factory Reset function The Factory Reset function is expected to be used if the device passes to a new owner. including the version of the Platform Software packaged with it. This is initiated by selecting an option in the Settings Menu of the Platform Main UI. Initiating the Clear Private Data function The Clear Private Data function can be initiated by selecting an option in the Settings Menu of the Platform Main UI. Clear Private Data function The device shall support a Clear Private Data function that removes certain settings and information about the viewer. This function shall not remove downloaded or recorded content.3. Scope of the Clear Private Data function The clear private data function is intended to remove any personal.1.2. 4. 4. private or sensitive data relating to the viewer. 4. © YouView TV Ltd (2011) Page 93 of 229 . Effect of the Clear Private Data function This is defined in the table in Section 5.YouView Core Technical Specification 4. YouView Core Technical Specification 5. Effect of Factory Reset and Clear Private Data The table below summarises the requirements of the Factory Reset function and the Clear Private Data function. Data Broadcast linear channel list Metadata caches and cookies Broadcast schedule data Log files and usage reporting ID Private Settings includes: parental controls and Platform PIN viewer approval(s) for sharing of personal data with content providers Platform managed linear channel lists for IP channels and favourites Device Manufacturer-specific settings (e .g. WLAN password) Downloaded configuration files Platform Software updates Any other data written since the box was purchased except those listed below Linear acquisition bookings Recorded broadcast A/V content Downloaded A/V content DRM licences Platform Application data: permanent cookies, cached data, locally stored files and objects. Note: session cookies will be cleared as part of the reboot associated with these functions. Content Provider Applications and associated metadata Content Provider Application data: permanent cookies, cached data, locally stored files and objects. Note: session cookies will be cleared as part of the reboot associated with these functions. Core Device Software updates DRM personalisation and provisioning keys Device unique ID Factory Reset clear clear clear clear clear Clear Private Data keep clear keep clear clear clear clear clear clear clear optional optional optional optional clear private data only keep keep keep keep keep keep keep clear optional optional keep clear keep keep keep keep keep keep Table 21: Effect of Factory Reset and Clear Private Data © YouView TV Ltd (2011) Page 94 of 229 YouView Core Technical Specification Chapter VIII Broadcast Content Delivery © YouView TV Ltd (2011) Page 95 of 229 YouView Core Technical Specification 1. Chapter Summary The DTG D-Book specifies the "Requirements for Interoperability" that have been adopted by multiplex operators in implementing digital terrestrial television services within the UK. This chapter complements the functionality described in DTG D-Book 7 Part A v1 in order to support effective integration of broadcast delivery in a connected television environment. 1.1. Audience This chapter is relevant to: Device Manufacturers who need to:    Implement the necessary support for DTG D-Book functionality including support for MHEG red button services. Implement support for MHEG Interaction Channel. Implement extensions to the MHEG presentation engine to enable the launch of IP-delivered applications from broadcast services. Content Providers who wish to:   understand what support is provided for broadcast content delivery. Application developers who wish to: launch IP-delivered applications from broadcast services. This chapter is not relevant to: ISPs © YouView TV Ltd (2011) Page 96 of 229 YouView Core Technical Specification 2. D-Book Compatibility YouView DTT HD DVR devices shall be implemented in line with DTG D-Book 7 Part A v1 and shall support all the functionality required by Section 22.4 (which in turn builds on 22.1, 22.2 and 22.3) including:            Support for the Guidance descriptor; section 22.1.3.5.4 Trailer Booking (“Green button”); section 22.2.3.12 Recommendations; section 22.2.3.6 SD/HD Event Linkage; section 22.3.3.2 MHEG Interaction Channel; section 22.3.5.2 ICEncryptedStreamExtension is not required for launch Audio Description for HD; section 22.3.1.4 Native Bitstream Audio over HDMI; section 22.3.4.4.1 Service Information and Selection: receiving signals from multiple transmitters; multiplex handling; service handling; section 22.1.3 Dynamic switching of audio between stereo and surround sound; section 22.3.1.1 MHEG High Definition Graphics Model Broadcast Record Lists; section 22.4.4 © YouView TV Ltd (2011) Page 97 of 229 1. 3. 3. The following extensions allow applications of any type to be launched over IP from a running MHEG application.1.1. false otherwise success Table 23 : ApplicationLaunch arguments 3. MHEG-5 Extensions DTG D-Book 7 Part A v1 applications that can access content and services over IP. [name. value]….YouView Core Technical Specification 3. In all cases the state of the True Persistent Storage shall not be affected. The resident program takes a variable number of arguments. A side-effect of the resident program may be that the MHEG engine is stopped (killing the application). Arguments in/ out/ in-out input input input type GenericOctetString GenericOctetString GenericBoolean or GenericInteger or GenericOctetString GenericBoolean output (Shall provide an IndirectReference to a BooleanVariable) name location name value comment Location of the application to run List of name/value pairs to be passed to the application True if the application started successfully. which updates it. which is defined below. If any name/value pairs are present. The application to run is specified by the location parameter. success ) 3. This produces a data set of the form name1=value1&name2=value2. Zero or more name/value pairs may be present. Description Causes a new application to be started with the specified arguments.1.1. where each of the names and values has been percent-encoded after replacing any space characters with „+‟. ApplicationLaunch Hands control of execution to another application of an arbitrary type.1.3.2.01 except that references to IETF RFC 1738 shall be taken as references to IETF RFC 3986. Launching IP-delivered applications from broadcast services The MHEG engine shall support the ApplicationLaunch resident program.4 of HTML 4.1. © YouView TV Ltd (2011) Page 98 of 229 .1. Invocation Resident program Typical Use Description ApplicationLaunch Name ApL Call  Fork Never Fork see below Reference Table 22 : ApplicationLaunch resident program 3. Note: Only application types supported by the device will be successfully launched. Synopsis ApL( location.13. the name/value pairs are used to construct a data set of content type application/x-www-form-urlencoded as specified by section 17.1.1. which is defined as follows: Invocation Resident program Typical Use Description GetLaunchArguments Name GLA Call  Fork Never Fork see below Reference Table 24 : GetLaunchArguments resident program 3. Arguments in/ out/ in-out input type GenericOctetString GenericOctetString output (Shall provide an IndirectReference to an OctetStringVariable) name name comment Name of argument to be retrieved Value of argument value Table 25 : GetLaunchArguments arguments 3.2. other than MHEG. Arguments can be set by applications of an arbitrary type. with a „?‟ character as a separator.1. Description Retrieves the value of the named argument.2.3. this forms a URI which references both the application to launch and the parameters to be passed to it. 3.5. © YouView TV Ltd (2011) Page 99 of 229 .1. For example.2. Receiving launch parameters set from non-MHEG applications The MHEG engine shall support the GetLaunchArguments resident program. GenericOctetString arguments are treated directly as strings.1. the character Latin Capital Letter A With Grave is represented in UTF-8 by the octets 0xC380. value ) 3. GenericInteger arguments are converted to strings as decimal integers with no leading zeros. GetLaunchArguments Retrieves an argument set by another application of an arbitrary type.2. Characters are assumed to be encoded as UTF-8. GenericBoolean arguments are converted to the string “true” if true and to “false” if false. when launching an MHEG application.12.2. this character would be written as „=C3=80‟.5 of IETF RFC 3986.10.1. 3. consequently the percent-encoding shall be carried out as specified for characters from the Universal Character Set in section 2.YouView Core Technical Specification The data set may contain characters that are not represented in the US-ASCII character set. The data set is appended to the location. Synopsis GLA( name.2.1. In the text representation of MHEG. The location URI shall follow the rules for the use of reserved characters in HTTP URIs as defined in DTG D-Book 7 Part A v1 section 18.3.2. It shall not be possible to launch an MHEG application using this resident program. after percent-encoding this would become “%C3%80”. In any case where an invalid set of arguments is supplied (such as a missing value argument) the resident program call shall fail in accordance with DTG D-Book 7 Part A v1 section 13. 3. For other values of N. String Standard Short Shall return “true” for N=0 if the device supports the ApplicationLaunch and GetLaunchArguments resident programs. Receivers shall consider that MIME type strings are case-insensitive when determining whether a MIME type is supported. Feature discovery The MHEG engine shall respond to the following GetEngineSupport feature strings. If the argument to be retrieved does not exist then the resident program succeeds and the value parameter is a zero length string. 3. Constraint ApplicationLaunchExtension(N) ApE(N) Table 26 : GetEngineSupport feature strings © YouView TV Ltd (2011) Page 100 of 229 . shall return “true” if the device supports launching applications whose MIME type=N. It is the responsibility of the application to convert this value into another type (using the SetVariable elementary action or one of the type conversion resident programs) if required.YouView Core Technical Specification The value of the argument is provided to the application as an OctetStringVariable. YouView Core Technical Specification Chapter IX IP Content Delivery © YouView TV Ltd (2011) Page 101 of 229 . Chapter audience This chapter is for: Device Manufacturers. ISPs.1. This chapter is not relevant for: Application Developers © YouView TV Ltd (2011) Page 102 of 229 . who need to:    Implement all the content delivery mechanisms described Content Providers. who may wish to understand the protocols and mechanisms used by YouView devices to access media content. The platform is designed to support four key use cases for A/V media delivery:     streaming of non-live content (video-on-demand) streaming of live content download of programmes to local storage close integration of A/V content and user interaction This chapter does not cover hardware requirements and network interfaces (which are covered in Chapter II Consumer Device Platform) or the network stack requirements (covered in Chapter IV Consumer Device IP Networking) or the provisioning of the device with configuration information (which is addressed by Chapter VI Consumer Device Software Management). Chapter Summary This chapter covers the ways in which content is acquired and consumed from the IP connection of the set top box. who need to: Understand the way in which YouView devices handle IP-delivered content Understand the content formats that are supported. 1.YouView Core Technical Specification 1. An individual streaming session shall not consume more than 90% of the available media buffer space so that it is always possible to have at least two concurrent sessions. a “fast fill” mode in which data is buffered as fast as it can be delivered by the network.YouView Core Technical Specification 2.1. HTTP progressive download 2. 2.2x the consumption rate.1. Introduction This section describes the streaming protocols that are used to fulfil the A/V delivery use cases described in section 1.2. minimal amounts of data are transferred but not used (for example.  The decoder feed buffer shall be held in RAM. Devices shall have at least 20 Mbytes of RAM to allocate to decoder feed buffers for streams that are being decoded – there may be more than one at any point in time. To support this. Devices shall have at least 2 GBytes of storage in total to allocate to the media buffers for streaming sessions – there may be more than one at any point in time. a greater amount of forward buffering is possible. Introduction HTTP progressive download is a mechanism for streaming video on demand content.g. the buffering algorithm has two modes:   © YouView TV Ltd (2011) Page 103 of 229 . Specific mechanisms for accessing A/V playback functionality from particular presentation engines is out of scope of this chapter. A defined buffering model is specified to ensure that:   the network infrastructure is not adversely impacted by large numbers of clients requesting lots of data at the same time. to recap a piece of missed dialogue or to see a particular event in a sports match again). The media buffer may be in any form of storage. Streaming Protocols 2. Devices shall retain the previous 30 seconds of media in the media buffer to allow for a rapid seek backwards (e.2. At lower stream bitrates. a “managed fill” mode in which data is buffered more slowly at a rate not exceeding 1.2. Streaming sessions that are paused do not require a decoder feed buffer until they are resumed. if users decide not to continue watching the content after a short period of time). The required size of the decoder feed buffer for a particular stream is determined based on stream parameters. a “media buffer” into which data received from the network is stored. Two buffers are defined:  a “decoder feed buffer” of a size necessary to ensure that the decoders are never stalled due to the normal variation in the bitrate of the encoded stream and due to any latency associated with reading data from the media buffer. Buffering Devices shall provide buffering to cater for variation in the data rate achieved across the network and to manage the data needed by the media decoders. Note: the minimum media buffer size specified for a single streaming session allows for around 3 hours of buffering ahead of the current play point at a typical SD stream bitrate. 2. It provides a „pull model‟ in which the client receives data as required and the server has no knowledge of the state of the device during playback.2. Devices shall support progressive download streaming of content in both MPEG-2 SPTS and MP4 containers. YouView Core Technical Specification Devices shall use the fast fill mode when the amount of data buffered ahead of the current play point is less than a threshold value which is defined as the size of the decoder feed buffer plus an amount corresponding to 10 seconds of media. When the amount of data buffered is greater than this threshold, the managed fill mode shall be used. This threshold is subsequently referred to as bufferThreshold. The required buffering model is summarised in the following figure: Figure 15 : Buffering model : bitrate This results in the buffer occupancy following a curve as shown below: Figure 16 : Buffering model : buffer occupancy © YouView TV Ltd (2011) Page 104 of 229 YouView Core Technical Specification When reading data into the buffer, devices shall do so with a single HTTP request. Devices shall not make multiple concurrent connections, nor make multiple short requests for sections of the content. This is so as to minimise the overheads on the server. Where there is a requirement to download content out of order, for example to obtain stream metadata from a point other than at the start, HTTP Range requests may be used. All rate management of the kind described above must be done by the client application reading not more than the required rate of data from the TCP socket. This allows the TCP stack to manage the rate limiting. 2.2.3. Buffer threshold control Applications can modify the behaviour of the buffering algorithm, specifying whether or not they want the buffer threshold defined in section 2.2.2 to be applied. Where an application requests the „threshold‟ algorithm, the algorithm described in section 2.2.2 above applies unaltered. Where an application requests the „unlimited‟ algorithm, the device shall not apply any bitrate limit on the incoming data and operates only in the fast fill mode. Where an application requests the „fixed‟ algorithm, the managed fill mode is not used and the incoming data is stalled while the buffer occupancy exceeds bufferThreshold. 2.2.4. Starting playback Applications may initiate buffering of a progressive download stream independently of requesting playback to start. Applications may also monitor the buffer occupancy. These mechanisms allow an application to control when in the buffering process playback should be started. Alternatively, the application may initiate playback directly. In this case, playback shall be started as soon as requirements 1 and 2 below are both met: 1. The quantity and duration of media that has been buffered ahead of the intended start point (referred to as bufferedBytes and bufferedMilliseconds) both exceed the levels needed to supply the decoder feed buffer so that under-run will not immediately occur. 2. One or more of the following conditions applies: o bufferedMilliseconds is greater than 10 seconds. o bufferedMilliseconds extends to the desired end point for playback or to the end of the stream. o The increase in bufferedMilliseconds since playback was requested exceeds the elapsed time since playback was requested by at least 250 milliseconds (note: this condition is equivalent to checking that the average incoming bitrate since playback was requested exceeds the required bitrate for sustained playback of the currently buffered data. The constant additional duration has the effect of buffering more data the closer the incoming bitrate is to the required bitrate). Note: requirements 1 and 2 are independent of each other. Once both are satisfied, playback shall start. Calculation of bufferedMilliseconds is described in section 2.2.11. 2.2.5. Handling buffer under-run conditions If at any time, a stream is being played and the buffer occupancy is below bufferThreshold as defined in section 2.2.2, any background downloads that are active shall be suspended. This includes the initial start-up phase. Further information on network resource management can be found in Chapter IV Consumer Device IP Networking. Devices may enable background downloads if it can be determined that the download will not affect the operation of the streaming session. © YouView TV Ltd (2011) Page 105 of 229 YouView Core Technical Specification If the buffer empties entirely and causes an interruption to playback, an underflow event shall be generated but playback must continue when data next becomes available. The algorithm described in Section 2.2.4 shall be used to determine when to resume playback. A higher level software component may use this event to consider whether there is a lower bitrate stream that could be played or to suggest the viewer download the content to watch later. 2.2.6. Random access Devices shall support random access to any point within the item of content. If the requested position does not fall within a portion of the content that has already been buffered, the device shall close any existing connection being used to acquire the media and shall open a new connection in order to acquire data at the new position. This may result in multiple discontinuous buffered regions being stored. Implementations are permitted to discard previously acquired regions after such a seek. If the requested position does fall within already-buffered data, the device shall begin playing from the new position using the buffered data. If the buffered data is incomplete and data is not already being acquired at the end of the region of buffered data into which the requested position falls, the device shall close any existing connection being used to acquire the media and shall open a new connection to acquire content at the end of that buffered region. In both cases, the rate at which content is downloaded is determined according to whether the download point is less than the bufferThreshold beyond the new play point. To retrieve content from the beginning of a file, devices shall use a simple HTTP GET request. To retrieve content from any other position, devices shall use an HTTP GET request with a Range header indicating the byte range being requested. When resuming acquisition at the end of currentlybuffered data, the Range request shall be open ended. Devices shall handle 200 OK and 206 Partial Content HTTP responses. Note that for a 206 Partial Content response, the byte range and total file size information is returned in the Content-Range header field. For a 200 OK response, the total file size information is returned in the Content-Length header. 2.2.7. Pause behaviour When a stream is paused (as indicated by a play speed of zero), devices shall immediately pause the presentation of the media. If an application has set the „unlimited‟ buffering algorithm, the device shall continue buffering. Otherwise, the device may continue to buffer content for a short period until the buffer occupancy reaches bufferThreshold, at which point it must close the connection to the server. When resuming a paused stream where the connection has been closed, the device shall establish a new connection and request data to continue from the end of the buffered region extending from the playback position. 2.2.8. Loss of connection If during streaming the device‟s connection to the server is lost, it shall attempt to re-establish the connection and request the remaining data following the standard back-off algorithm specified in Chapter IV Consumer Device IP Networking using the timeout period for a foreground request. 2.2.9. Trick modes Devices are not required to support playback of content obtained by HTTP progressive download at speeds other than x1. Devices may allow playback at other speeds for content that has already been downloaded into local storage. Devices shall not download content from the network at rates greater than x1.2, other than as described in section 2.2.2. © YouView TV Ltd (2011) Page 106 of 229 YouView Core Technical Specification 2.2.10. Mapping time offsets to byte positions When streaming an MPEG-2 transport stream, the device needs additional information in order to allow for random access into the stream. Three mechanisms are defined that allow the device to map times to byte offsets:    using an index file, as described in Section 2.2.10.2 below using a stream average bitrate value, as described in Section 2.2.10.3 below using only information contained within the stream itself, as described in Section 2.2.10.4 below The choice between these methods is made according to Section 2.2.10.1. MP4 files can carry the necessary indexing information internally. Seek functionality shall be made available by the device where this information is present at the start of the file. 2.2.10.1. Selecting a mechanism for time to byte mappings The information needed to map from time to byte offset can be signalled through the use of the X-BytesPerSecond and X-IndexFileLocation headers in the HTTP response from the server or provided by an application.   If the X-IndexFileLocation header is present the device shall retrieve the index file and use the Index File based timeline (see section 2.2.10.2). If there is a X-BytesPerSecond header, but no X-IndexFileLocation header then the device shall use the Known Bitrate timeline (see section 2.2.10.3). The Known Bitrate timeline shall also be used where an application has provided information about the true duration of the stream and the device is able to determine the content length in bytes.  In all other cases, devices shall use the No Timeline method (see section 2.2.10.4). The HTTP headers described here shall be observed whether they appear in a 302 response or in the response that delivers the content. 2.2.10.2. Index file timeline Where the index file timeline approach is used, the X-IndexFileLocation shall be set in the HTTP response. The value of this header shall be an http or https URL from which an index file as specified below may be obtained. The device shall retrieve the index file from the URL specified in the X-IndexFileLocation header. To allow efficient parsing by the device of the index file a binary format is used. The file consists of a series of „samples‟. Each sample has a byte offset, as a 64 bit unsigned integer and a time in milliseconds, from the start of the file, as a 32 bit unsigned integer. The byte position should correspond to the start of a transport stream packet that represents a suitable random access point but this is not guaranteed. The last sample in the file contains the size of the file in bytes and the total duration of the media in milliseconds. All integers are encoded most significant byte first. File ::= NumOffsetSamples [OffsetSamples] LastSample NumOffsetSamples ::= uint32 OffsetSamples ::= [OffsetSamples] Sample Sample ::= BytePosition TimeValue BytePostion ::= uint64 TimeValue ::= uint32 LastSample ::= FileSize MediaDuration FileSize ::= BytePosition © YouView TV Ltd (2011) Page 107 of 229 2. the X-BytesPerSecond header is present in an HTTP response or the application has provided sufficient information for the stream bitrate to be 6 calculated . as the samples are intended to indicate random access points within the file where decoding can start. To determine the current position during playback. For seeking. the bitrate figure is derived from the content duration and the information from the Content-Length HTTP header. Devices should store this file in a convenient structure to allow them to:   determine current playback time from the current position within the file find the nearest sample to a time for seeking within the file Devices shall support index files up to 256kbytes in size (containing up to 21 thousand samples).10.2.YouView Core Technical Specification MediaDuration ::= TimeValue NumOffsetSamples indicates how many Samples there are. 2. in milliseconds) a device shall use the PTS value of the most recently presented video frame (PTScurrent) and the PTS value of the first video frame in the stream (PTSstart). which must always be present. devices shall use PCR and PTS information from the stream as follows. Known bitrate timeline Where the known bitrate timeline approach is used. the device shall obtain the first and last PCR values from the stream (PCRstart and PCRend respectively) and calculate: 6 In this case.2. as follows: tcurrent = (PTScurrent – PTSstart) / 90. To determine the byte offset to seek from a time value a device shall determine the closest sample to the time value in the index and use the byte offset associated with that sample.4. in which case media_timeref will be zero.10. the PTS values of audio access units shall be used instead. devices shall decode the media from the previous random access point but present decoded media only from the requested seek position. a device shall use the PTS value of the most recently presented video frame (PTScurrent) and a previous PTS value (PTSref) of a video frame for which the media time (media_timeref) is known. which indicates the average bitrate of the file in bytes per second. The value of the X-BytesPerSecond header is a positive integer. To determine the duration of the stream. Where the seek position is between random access points.2. If the stream does not contain video. devices shall not attempt to interpolate between samples. the device shall use the MediaDuration entry in the LastSample of the index file.3. To determine the current position (tcurrent. No timeline method Where no external means of mapping between time and byte position is available. If the stream does not contain video. the device shall obtain the size of the file in bytes from the Content-length: or Range: header from the server and calculate the time corresponding to the end of the file as duration = bytes×1000/BytesPerSecond. © YouView TV Ltd (2011) Page 108 of 229 . To determine the duration of the stream. To determine the byte offset to seek to from a time value a device shall calculate the required offset as brequired = trequired×BytesPerSecond/1000 and then round this to the nearest transport packet (188 bytes). the PTS values of audio access units shall be used instead. devices shall use the same approach described in section 2. To determine the duration of the stream. It does not include the LastSample. 2. To determine the current playback position (tcurrent. as follows: tcurrent = (PTScurrent – PTSref) / 90 + media_timeref. in milliseconds) during playback. Note: the previous known reference point may be the start of the file.10. mpd”. The store of cookies for the media playback client shall not be shared with any other use of cookies on the device. one 25 Kbyte chunk should be sufficient to retrieve the final PCR. in milliseconds) can be calculated as: bufferedMilliseconds = (PCRbuffer / 300 – PTScurrent) / 90 where PCRbuffer is the latest PCR value present in the buffered data and PTScurrent is the PTS value of the most recently presented video frame (or audio access unit if there is no video). a device shall calculate the required offset as: brequired = trequired×bytes/duration. If the media is not playing. devices shall monitor data entering the buffer and observe PCR values.3gpp. Caching Devices are not required to cache any media content between progressive download sessions. In any event. there is an error in the stream.2. The duration of buffered data (bufferedMilliseconds.2. These calculations may require that the device download a portion of the stream from the start and/or the end in order to acquire the necessary PCR or PTS values. 2. When reading a PCR from the end of the stream. and it is expected that this will be compatible with the output of the MPEG DASH standardisation activity. 2. the duration of buffered data is calculated simply as: bufferedMilliseconds = (PCRbuffer – PCRstart) / 27000. only transport stream-based adaptive streaming is specified. cookies shall be discarded when the device next enters standby. Introduction Devices shall support adaptive bitrate streaming of A/V content. Adaptive bitrate streaming over HTTP 2.3.1 and shall be transparent. Cookies The media playback client is not required to store persistent cookies.11.YouView Core Technical Specification duration = (PCRend – PCRstart) / 27000. Devices shall download at most ten chunks. The client makes requests for individual segments based on the buffer occupancy and incoming bitrate. if no PCR is found in that amount of data. 2. Calculating duration of buffered data In order to determine the duration of media currently buffered for an MPEG-2 transport stream. For the avoidance of doubt. Any caching that is performed by a device shall conform to the requirements of HTTP/1.1.13. an attempt to access progressive download content shall always fail if the server cannot be reached at the time playback is attempted.3.2.12. © YouView TV Ltd (2011) Page 109 of 229 . devices shall request data 25 Kbytes at a time working backwards until a PCR is found. 2. To calculate the byte offset to seek to (brequired) from a time value (trequired). Adaptive bitrate streaming is invoked when the URL results in the retrieval of a document with the MIME type “video/vnd. In this chapter. The streaming mechanism involves using A/V media encoded at different bitrates and divided into segments. The manifest file format is based on the 3GPP MPD. Session cookies shall be retained for at least the period of time over which a particular media asset is being obtained. For streams with bitrates of less than 2 Mbps. Devices shall not use any cached data in place of content obtained from the server unless it can be confirmed as being up to date. Partial representations shall not be used. The constraints listed in section 3. Manifest file format The manifest file is a Media Presentation Description as specified in section 3. The bitrate switching decisions will therefore be devolved to software that can be updated. It is envisaged that the manifest and transport stream requirements currently specified will be compatible with any future version of this specification. which shall be used subject to the following amendments:  <Representation> elements shall have the group attribute set to 0.1 of OIPF Release 2 Specification – HTTP Adaptive Streaming. Any TrickMode element present can be ignored. If the media segments are encrypted.2 of OIPF Release 2 Specification – HTTP Adaptive Streaming shall apply. © YouView TV Ltd (2011) Page 110 of 229 .YouView Core Technical Specification The algorithms for selecting the bitrate of media to download will need to change as the UK IP networks evolve and may also need to vary between content provider. the following limitations apply:    The ProgramInformation element can be ignored. Additionally. 2. Devices are not required to support more than one Period. The switching decisions will be influenced by the current buffer state as well as preferences indicated by the application. for media protected by Marlin would include a ContentProtection element with schemeIdUri="urn:dvb:casystemid:19188”. For example. such as MPEG and the DTG is known. the ContentProtection element will be present.2. however additional features may be supported if these are specified in other standards. These additional features are therefore not required for launch.3. YouView intends to extend this specification to include Fragmented MP4 based content once the output of industry standards organisations working in this area. co.uk/test/media/low/" duration="PT4.YouView Core Technical Specification 2.0S"> <InitialisationSegmentURL sourceURL= "http://dummy.3. subject to the following amendments:  References to codec specifications within OIPF shall be regarded as referring to the relevant areas of this chapter 2.uk/test/media/init.co. © YouView TV Ltd (2011) Page 111 of 229 .bbc.ts"/> <Url sourceURL="00000"/> <Url sourceURL="00001"/> <Url sourceURL="00002"/> <Url sourceURL="00003"/> <Url sourceURL="00004"/> <Url sourceURL="00005"/> <Url sourceURL="00006"/> </SegmentInfo> <ContentProtection schemeIdUri="urn:dvb:casystemid:19188"/> </Representation> </Period> </MPD> 2.co.1 of OIPF Release 2 Specification – HTTP Adaptive Streaming.bbc. Example manifest file An example manifest is shown here: <?xml version="1.4.3.5. MPEG-2 transport stream encapsulation format Adaptive bitrate content delivered in MPEG-2 transport stream fragments shall be formatted in accordance with section 4.ts"/> <Url sourceURL="00000"/> <Url sourceURL="00001"/> <Url sourceURL="00002"/> <Url sourceURL="00003"/> <Url sourceURL="00004"/> <Url sourceURL="00005"/> <Url sourceURL="00006"/> </SegmentInfo> <ContentProtection schemeIdUri="urn:dvb:casystemid:19188"/> </Representation> <Representation bandwidth="1400000" mimeType="video/mpeg" startWithRAP="true"> <SegmentInfo baseURL="http://dummy. For information work is currently being undertaken in industry standards organisations including the DTG and MPEG.uk/test/media/high/" duration="PT4.0" encoding="UTF-8"?> <MPD xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009" minBufferTime="PT10S"> <Period start="PT0S" segmentAlignmentFlag="true" bitStreamSwitchingFlag="true"> <Representation bandwidth="5000000" mimeType="video/mpeg" startWithRAP="true"> <SegmentInfo baseURL="http://dummy. Fragmented MP4 encapsulation format Not required for launch.bbc.3.uk/test/media/init.bbc.co.3.0S"> <InitialisationSegmentURL sourceURL= "http://dummy. An alternative approach for live streaming is to use the adaptive bitrate streaming mechanisms defined in section 2. Live streaming using UDP This section describes a set of features supporting streaming of live content. © YouView TV Ltd (2011) Page 112 of 229 . 2. devices shall not pass multicast packets originating from sources other than the one specified. This is backwards compatible with gateways that support only IGMPv2.1.4. this indicates use of Source Specific Multicast. Where SSM is requested by an application. To assist with specific interoperability problems. URL formats Live UDP streaming is initiated using a content URL in one of the following forms: 1.3. See section 2.1.4.4. 2.3. IPv4 multicast joins shall be performed in accordance with IGMPv3 (RFC 3376). Multicast streams Devices shall support Any Source Multicast (ASM) and Source Specific Multicast (SSM). regardless of whether IGMPv3 was used to join the group.2. Devices shall not issue IGMPv3 membership reports requiring a filter-mode of EXCLUDE with a non-empty source-list. Note: this feature is provided as standard by the Linux network stack via the normal IP_ADD_SOURCE_MEMBERSHIP socket option. UDP encapsulation Devices shall support UDP encapsulation of MPEG-2 transport streams as specified in ETSI TS 102 034 section 7.2.4. devices shall support a configuration option to force the use of IGMPv2. 2.4.2. At the application level.YouView Core Technical Specification 2. devices shall support SSM. A direct reference to a UDP-delivered multicast stream using a URL of the form: udp://[[source_address]@]multicast_address:port_number Where a source address is specified. which may only be downloaded during a configured background download window. If a download is suspended for more than 30 seconds. devices shall follow the standard back-off algorithm specified in Chapter IV Consumer Device IP Networking using the timeout value for background requests.1. Storage of downloaded content Downloaded assets shall be stored and indexed separately such that multiple application level playlists that include common assets (e. Introduction Devices shall support background downloading of content. and high priority items. When resuming a download for which the connection has been closed. 3. © YouView TV Ltd (2011) Page 113 of 229 . 3.g. No more than four concurrent downloads shall be active at once. The download manager shall support suspending and resuming downloads. Content Download Functionality described in this section is not required for launch.YouView Core Technical Specification 3. which may be downloaded at any time.2. In the event of a download failure. the device shall close the connection to the server. the device shall make a new HTTP GET request with a Range header to continue the download from the point it left off. The handling of these different classes of download. as well as other IP resource management constraints.3. a branded „sting‟) do not require multiple copies of the shared asset to be downloaded and stored. is defined in Chapter IV Consumer Device IP Networking. Devices shall maintain a queue of content to download. HTTP content download Content download over HTTP shall be performed as an HTTP GET. 3. There may be low priority items in the queue. Only one program may be listed in the PAT. In the case of transport streams segmented for adaptive bitrate streaming. Timed Text subtitles may also be used in conjunction with transport stream based content (see section 4. MIME type When serving content contained in an MPEG-2 transport stream. If present.1. 4. Transport streams shall contain a valid PAT and PMT. Devices shall support decryption of an AES-encrypted transport stream at bitrates up to at least 10 Mbps. MP4 container Devices shall support content encapsulated in the ISO Base Media File Format ISO/IEC14496-12 (2005) and the MP4 file format ISO/IEC14496-14 as profiled below. Other SI and PSI tables may be included in the stream. Codecs IP-delivered A/V content may use any of the codecs specified in Chapter II Consumer Device Platform. Encryption Transport streams may be encrypted using AES with a 128-bit key using the Cipher Block Chaining (CBC) encryption mode with the residual termination block process as specified in IEC 62455 section 6. Further detail on encryption formats.2. devices may assume that a stream reconstructed from a valid sequence of segments will meet the same requirements for decryption as a conventional non-segmented stream. servers shall indicate the MIME type to be: video/MP2T 4. Devices shall observe aspect ratio and AFD signalling when presenting streams delivered over IP. 4. 4.6.4.2. including details of how encrypted media links to specific content protection mechanisms via IEC 62455 Key Stream Messages and PMT descriptors is defined in Chapter X Content Protection : AV Over IP.4).2. If present. It is expected that the majority of streamed content will use H. Subtitles in multiple languages may be present in a single stream.2.3.2.3. 4.YouView Core Technical Specification 4. © YouView TV Ltd (2011) Page 114 of 229 . Access services Transport streams may contain a DVB subtitle stream and/or an audio description track. MPEG-2 single program transport stream Devices shall support MPEG-2 single program transport streams (SPTS) as defined in ISO/IEC 13818-1.1. these shall be handled according to viewer preferences in the same manner as for broadcast transport streams. Content Formats 4.264 for video and HE-AAC for audio. they shall be ignored. By default. devices shall select the subtitle track whose language matches the currently configured preferred subtitle language. Note: this may require the content to be created with suitable alignment of the traffic keys in the constituent adaptive bitrate representations. Devices are not required to support MP4 files containing other video codecs. 'mvhd' 'trak' 'tkhd' 'mdia' 'mdhd' 'minf' 'hdlr' 'vmhd' 'smhd' 'dinf' Movie header box Track box Track header box Media box Media header box Media information box Handler reference box Video media header box Sound media header box Data information box Specifies the location of the media samples. 'url ' Data entry url box Specifies the location of the media samples using a URL or indicates they are within the current file. MAY be ignored as restrictions in this specification prevent external location of media. MAY support v1. Flags on this box SHALL be set to 0x01 and the url string empty. see section 4. Only version 0 box SHALL be used.YouView Core Technical Specification MP4 files conforming to this specification shall have the major brand 'avc1'. Identifies a track within the file.3. This table forms part of the normative specification. SHALL only contain the 'url ' box as specified below. SHALL support v0. Contains header information for the media in the file. MAY support v1. MAY be ignored as restrictions in this specification prevent external location of media. or because they are mandatory in the base specification.264) video content. Only version 0 box SHALL be used. Device requirements Shall recognise 'avc1' brand. SHALL support v0. 'stbl' 'stts' 'ctts' Sample table box Decoding time to sample box Composition time to sample box Sample description table 'stsd' © YouView TV Ltd (2011) Page 115 of 229 .1 Only version 0 box SHALL be used. Box type 'ftyp' 'moov' Name File Type Box Movie box Usage Indicates file format. SHALL support v0. indicating the track is within the current file. either because they must be parsed by the device. indicating MPEG-4 part 10 (H. The following table lists boxes relevant to this chapter. MP4 files contain a number of 'boxes'. MAY support v1. Restrictions for content production Shall mark MP4 files with 'avc1' as the major brand. For constraints for progressive download. 'co64' Chunk offset box(64 bit offsets) SHALL support both files containing this box or 'stco'. Gives the total duration of a fragmented file. MAY support v1. Indicates the location of chunks of samples within the file using a byte offset from the beginning of the file. SHALL support both files containing this box or 'co64'.YouView Core Technical Specification Box type 'stsz' 'stz2' Name Sample size box Sample size box (compact version) Sample to chunk box Chunk offset box Usage Device requirements Restrictions for content production Where possible this box should be used in preference to 'stsz' to save space. Only version 0 box SHALL be used. This is likely to be the case for audio tracks. SHALL support v0. but decoding after the seek may take a number of frames to resume. This box SHALL be present and indicate the total duration if the mvex box is present in a file. 'stsc' 'stco' Indicates the location of chunks of samples within the file using a byte offset from the beginning of the file. 'stss' Sync sample box Where present the device SHALL use the information from this box to assist in seek operations. 'avc1' 'avcC' AVC sample entry box AVC configuration entry box MPEG4 bitrate box AVC parameter sample entry box Sample to group box Sample group description box Movie extends box Movie extends header box Indicates that the file contains fragments. It SHOULD NOT be used otherwise due to the space overhead introduced. This box SHALL be used when a non-fragmented file exceeds 4GB in size. 'btrt' 'avcp' 'sbgp' 'sgpd' 'mvex'* 'mehd'* © YouView TV Ltd (2011) Page 116 of 229 . However if the box is empty or missing seek SHOULD still be performed. SHALL support v0 and v1 boxes. This is to allow support for files over 4GB. 4. this box SHALL refer to at least the first randomly accessible sample in each fragment. and in many of these cases the v1 is to allow 64-bit timestamps to be used. Any boxes not listed here may be ignored by the device. Note that some boxes have two versions 0 and 1.3. 'free' and 'skip' boxes are not listed above as they are technically not parsed or interpreted by the device. Device requirements Restrictions for content production This box SHALL NOT exceed 1MB in size. v1 boxes shall not be used where indicated in the table.1. Progressive download When content is intended for consumption through progressive download then there are additional requirements on the formatting of the media. Media data for the tracks used by the MP4 file shall be contained within the file itself. The Timescale value set in the 'mvhd' shall be chosen appropriately by the content author to prevent the need to use 64-bit timestamps. This box SHALL be present and SHALL be the last box within the mfra box. Note that 'mdat'. Content providers shall not insert boxes not listed here if a device ignoring those boxes would materially affect the presentation of the media to the viewer. Contains a list of random access points in a fragmented file. Table 27 : MP4 boxes Boxes marked with an asterisk (*) in the table above are only used in MP4 files containing fragments. If an 'edts' box is present it shall be empty. which need 64 bit offsets. Devices are not required to support references to tracks in external files. Edit lists shall not be used to alter playback. 'mfro'* Movie fragment random access offset box Helps a device obtain the 'mfra' box when this is placed at the end of the file. and as such. These are to avoid lengthy delays at startup and to enable to device to seek efficiently within the file. The media SHOULD use a v0 box where the file size is less than 4GB.YouView Core Technical Specification Box type 'moof'* Name Movie fragment box Track fragment box Usage Contains header information for a fragment. Contains the random access points for the specified track. This box SHALL be the last box in all fragmented files. © YouView TV Ltd (2011) Page 117 of 229 . 'traf'* 'tfhd'* 'trun'* Track fragment header box Track fragment run box Movie fragment random access box Track fragment random access box Contains sample duration and sizes for the track. MP4 files shall be constructed with the 'moov' box after the „ftyp‟ box at the start of the file and before any sample data. Contains header information for the specified track within the fragment. 'mfra'* 'tfra'* Where fragments contain more than one randomly accessible sample. Ideally it should not exceed 1MB.2.YouView Core Technical Specification Additionally files for progressive download should use fragmentation where necessarily to ensure that the following recommended size limits are not exceeded:    'moov' box total size shall not exceed 4MB. This is to avoid the device running out of media to play while downloading a 'moof'. 4.3. 'moof' boxes shall not individually exceed 1MB. 4. including an encryption mechanism for MP4 content that is part of an adaptive bitrate stream may be added in future.org/TR/ttaf1-dfxp/ © YouView TV Ltd (2011) Page 118 of 229 . the viewer experience may be impaired through lengthy startup times and possible pauses. The video/mp4 type may be used for files containing only audio.w3. 4.3.3. Access services Subtitles for MP4-based content will be provided as separate Timed Text files (see section 4.4). Fragments (that is 'moof' plus 'mdat') shall not exceed 4GB. This avoids the need for 64 bit offsets to be used. Within the media data samples shall be interleaved such that no more than one second of data is required in the device‟s buffer for the current samples for all streams in the file to be available. Encryption MP4 content may be encrypted using AES with a 128-bit key. This is to avoid excessive delays at startup while the 'moov' box loads. Other encrypted MP4 formats. Timed Text subtitles Subtitles for VOD content may be provided as a TTML/DFXP Timed Text subtitle file as defined by http://www.1. 4.4. as illustrated for a file containing one audio and one video track in the following figure: moov Audio Video Audio Video Audio Video max 1s max 1s max 1s max 1s max 1s max 1s Figure 17 : MP4 interleaving Devices shall play files which do not meet this recommendation for limits on 'moov' and 'moof' sizes.4. Devices shall support decryption of downloaded or progressively-downloaded MP4 content encrypted according to the Continuous Media Profile (PDCF) defined in section 7 of the OMA DRM Content Format specification version 2.3. MIME type When serving content contained in an MP4 file servers shall indicate the MIME type to be: video/mp4 or audio/mp4 The audio/mp4 type shall not be used for files containing video. For example support for #fontFamily implies #fontFamily-generic and #fontFamily-non-generic.3.4. 4.1.4.4.3.4. Resolution The device shall render subtitles to a graphics plane with a resolution of at least 1280x720. irrespective of the media resolution. Format TTML subtitles will be provided as one XML file per selectable programme.YouView Core Technical Specification This format allows subtitles to be used with any media format and also allows the same subtitle file to be used for other platforms (for example. TLS shall be supported.1.2. 4.4. Timing Times within the subtitle file shall be interpreted relative to the start of the media asset being presented.4. © YouView TV Ltd (2011) Page 119 of 229 . delivery to PC clients). Acquisition The device shall download the necessary file specified by the application using an HTTP request.4.4. 4.4. Rendering 4. 4. 4.2.4. a requirement for a principle feature implies support for any subset features. Profile Devices shall support at least the following features of the TTML specification: #backgroundColor #cellResolution #color #content #core #extent #fontFamily #fontSize #fontStyle #fontWeight #layout #length-cell #length-em #length-integer #length-percentage #length-pixel #length-positive #length-real #lineHeight #nested-div #nested-span #origin #padding #presentation #showBackground #structure #styling #styling-chained #styling-inheritance-content #styling-inheritance-region #styling-inline #styling-nested #styling-referential #textAlign #textDecoration-under #timeBase-media #time-clock #time-clock-with-frames #time-offset #time-offset-with-frames #timing #writingMode-horizontal-lr Note: in TTML.4. The device shall support UTF-8 encoding for XML files. Anti-aliasing The device shall provide rendering support for at least 8 colour tones per principle colour. 4. 4. the file shall be downloaded and the subtitles shall be displayed as soon as possible thereafter. below main graphics plane as described in Chapter II Consumer Device Platform. Formatting defaults Devices shall comply with the default formatting specified in the TTML standard. Control of subtitle presentation If subtitles are enabled on the device prior to playback. The displayAlign property ensures that all subtitles lines are vertically aligned to the bottom of the region by default.6. © YouView TV Ltd (2011) Page 120 of 229 . 4. 4. the relevant subtitle file shall be downloaded at the same time as buffering is started for the accompanying media.7. Number of colours The device shall support rendering at least 32 different combinations of foreground and background colour in a single subtitle file. 4.4. Layer Subtitles shall be rendered either through the screen manager and DirectFB or on a separate 8bpp graphics plane. 4. and 16 rows. Where text with tts:backgroundColor applied at the span level. If subtitles are then enabled.4. a subtitle file is kept until the corresponding media is no longer being played.4. with the following exceptions. and starts one cell into the screen. the device shall adopt the following features:      tts:backgroundColour: transparent tts:origin: 1c 1c tts:extent: 38c 14c tts:textAlign: centre tts:displayAlign: after This defines a region that is 14 text lines (cells) high.4.8.4. the filled area shall cover the full line height as specified by the tts:lineHeight attribute. and displayed as soon as possible.4.04 seconds of the specified time. this provides cells of 32 pixels wide. once loaded. Region If no region is specified.8. the subtitle file shall not be downloaded unless subtitles are subsequently enabled.1.4. If subtitles are not enabled when playback starts. 4.8.5. the filled area shall extend the width of a space character to the left of the first rendered character on each line and to the right of the last rendered character on each line.2. 4. On a 1280x720 display. allowing for semi-transparent subtitles and backgrounds. 4.YouView Core Technical Specification Subtitles shall be rendered within 0.4. For content streaming. Colour specifications that include an alpha value shall be supported. Background colour fill When rendering a span with a tts:backgroundColor. Cell resolution By default the cell resolution shall be set to 40 columns. and 45 pixels high. 5. servers shall indicate the MIME type to be: audio/mpeg © YouView TV Ltd (2011) Page 121 of 229 . it shall default to Tiresias.3.8.4.1. This corresponds to a height of 41px at a 1280x720 resolution.YouView Core Technical Specification 4. Span  tts:backgroundColor: black 4. Other font support is implementation dependent. Font  tts:fontFamily: Tiresias Where the platform does not support the font specified.  tts:fontSize: The default font size shall be 0. Paragraph   tts:color: white tts:lineHeight: If no lineHeight is specified. Audio elementary streams Devices shall support MPEG-1 layer III audio elementary streams with or without ID3 tags.4.4.4.9c. 4. MIME type When serving MPEG-1 layer III audio elementary streams.8.5. 4. it shall be set to 1c so that the background boxes of adjacent lines touch without the need for padding.8.5. sansSerif and default shall always be mapped to Tiresias. 4. . YouView Core Technical Specification Chapter X Content Protection : AV Over IP © YouView TV Ltd (2011) Page 123 of 229 . YouView Core Technical Specification 1.1. The chapter defines a range of content protection mechanisms that will give content providers choice about what they employ.e. 1. who need to:     Implement the content protection mechanisms Content Providers. Chapter Summary This chapter defines the way in which rights-sensitive A/V content can be protected and managed both in distribution and whilst it exists in the consumer device. to only need to use something that is sufficient given the nature of the content being delivered. who need to: Understand the security and utility provided by each of the content protection mechanisms Configure back-end systems to interface to the content protection mechanisms Encrypt content according to the support encryption formats This chapter is not relevant for: Application Developers ISPs © YouView TV Ltd (2011) Page 124 of 229 . Chapter audience This chapter is for: Device Manufacturers. i. These provide a simplified view of the interactions that take place with each mechanism.3 – Device authentication using MS3 §3. To illustrate the interactions between applications and the underlying media playback functions of the device. The table below summarises the features and capabilities of the different content protection options. © YouView TV Ltd (2011) Page 125 of 229 Streaming . Section 3 describes a set of content protection options to be provided by the core media playback function of the device. In addition.1 – No protection (Simple HTTP) §3. Offline playback of downloads Configurable output controls Authentication Support for HTTP caches Content encrypted on server Content encrypted in delivery Hardware decryption Protection mechanism §3. The options vary both in complexity for the content provider and the level of protection needed.5 – Device authentication and encrypted content delivery (Marlin MS3) §3. Introduction This chapter provides detailed specifications for a range of content protection options.YouView Core Technical Specification 2. a component labelled „MediaRouter‟ is shown to which represents the application‟s interface onto the media playback implementation.2 – Simple device authentication §3.4 – Device authentication and transport encryption (TLS streaming) §3.6 – DRM protected content (Marlin Broadband) N Y Y Y N N N Y N N N N Y Y Y N N/A N/A N/A N N N Y N N N N N Y Y Y Y Y Y Y Y Y Y N Y Y Y Y Y Y Y Y Y Table 28 : Content protection summary A number of sequence diagrams are shown in this chapter. Content providers may use any of the supported options according to their needs. specific presentation environments may provide additional mechanisms for content protection. a direct reference to the media is passed by the application. the high level interactions would be as follows: Figure 18 Note: Interactions between the MediaRouter and Media decoder objects shown are illustrative only.1.1. the request will be made in the clear so the content URL could be captured. Content providers can use techniques such as timelimited tokens to limit the usefulness of URLs captured in this way. This mechanism can be used to deliver a media URL securely into the device for use in the same way as described in section 3. The YouView device is not authenticated and there is no encryption of the content. For example. Description The simplest form of content delivery provides no protection. Content protection mechanisms 3.2. 3.1.9. No protection 3. Description This mechanism provides authentication of the YouView device to the content provider for an interaction which takes place prior to the start of media playback between an application running on the YouView device and a content provider‟s server.1. In this scheme. This content delivery mechanism does not provide means to change the state of output control mechanisms from the default specified in section 3. Simple device authentication 3.YouView Core Technical Specification 3. © YouView TV Ltd (2011) Page 126 of 229 . for content streamed over HTTP.1. When the media URL is subsequently used to request the content.2. The mechanism for this will vary depending on the particular application player or presentation engine being used. Compliance and robustness requirements When this mechanism is used the private key for client authentication shall be protected to the same 7 degree as required by the Marlin Robustness rules . available from http://www.2. 3.2. the secure interaction with the content provider‟s server uses the capabilities of the application player to set up a secure connection.3. For full details of the requirements for TLS server and client authentication for requests made from presentation engines. Since the media playback element of this mechanism is exactly the same as the basic case of no protection.9. this content delivery mechanism does not provide means to change the state of output control mechanisms from the default specified in section 3.2. The player makes a TLS connection to the server requested by the application and performs client authentication if requested by the server.com/downloads/agreement © YouView TV Ltd (2011) Page 127 of 229 .YouView Core Technical Specification Note: One-time URLs cannot be used with this mechanism because the URL may be used more than once if the player needs to seek within the stream. Detailed specification In this mechanism. refer to the relevant presentation engine chapters. Figure 19 3. 7 Part of the Marlin Client Adopter agreement.marlin-trust. the implementation shall behave as described by the MS3 specification. It does not include encryption of the content itself. Content providers can use techniques such as one-time or time-limited tokens to limit the usefulness of URLs captured in this way.2 of the Marlin Simple Secure Streaming (MS3) specification version 1. When presented with a URI of this type. a compound URI is passed by the application.3. allowing the content provider to reveal parts of the content‟s location only to genuine YouView devices.0. together with a URI template for an unencrypted delivery mechanism with which to obtain the content (the C-URIT). Figure 20 Note: Interactions between the MediaRouter and Media decoder objects shown are illustrative only. Server authentication shall be performed using the platform-specified bundle of HTTPS root certificates. In summary. The format of the compound URI is specified in section 3. In addition.1. Note: YouView devices are not required to support triggering of MS3 by an Action Token or by an MS3 Manifest File.3. Device authentication using MS3 3.3.YouView Core Technical Specification 3. © YouView TV Ltd (2011) Page 128 of 229 . the request made to obtain the content will be sent in the clear so the content URL could be captured. Description This mechanism provides authentication of the YouView device to the content provider. when starting to buffer content: 1.2. Detailed specification In this mechanism.4. The compound URI includes an https: URL for an MS3 service (the S-URL). 3. The implementation first makes a secure connection to the MS3 service with client authentication. If the device cannot retrieve or process the SAS.4. the output restrictions and the handling of the TLS client certificate. If this fails. Device authentication and transport encryption 3. The content is streamed using the C-URL as if it had been provided directly by the application. content at bitrates exceeding 2. and content providers should not attempt to deliver. It is expected that on many devices. it is possible that this authenticator may expire after a period of time.3. The content does not appear in the clear in the home network but would be stored unencrypted on the content provider‟s servers. 3. Note: As content is not encrypted in this delivery mechanism. The implementation forms a URL for the content (the C-URL) using the C-URIT and the authenticator. the applicable requirements here relate primarily to the „do not store‟ flag.4. an event shall be raised. For the period that the content is being presented. the device needs to make a new request (for example to perform a seek. If. Description This mechanism allows content to be delivered through an encrypted transport using TLS. the implementation shall first make one attempt to use the existing C-URL for the new request. The server responds with a Stream Access Statement (SAS) which can include an authenticator element to be substituted into the media URL and which also includes a set of output control requirements to be met whilst the content is being played. Where the SAS contains an authenticator.5 Mbps (for AES-128 encryption) or 4 Mbps (for RC4 encryption) using this method. © YouView TV Ltd (2011) Page 129 of 229 . the implementation shall return to the MS3 service for a new SAS.YouView Core Technical Specification 2. In addition. the YouView device is authenticated to the content provider.1. to resume after pausing or to re-try after a transient error condition). The SAS and the buffered data shall be retained until the application ends the streaming session or selects a different source. 3. after the initial request for the content. Compliance and robustness requirements The Marlin Compliance and Robustness rules shall apply to the implementation of this mechanism. Implementations are not required to support. software-only implementations will be able to meet this requirement. the output control mechanisms shall be configured to satisfy the output control requirements provided by the SAS within the context of section 3.9.3. 9. an https: URL is passed by the application.3. This content delivery mechanism does not provide means to change the state of output control mechanisms from the default specified in section 3. Server authentication shall be performed using the platform-specified bundle of HTTPS root certificates.2. 3. If the device cannot establish a secure connection (for example because the server refused to accept the client authentication offered). 3. Content shall not be stored on the device other than as required temporarily for buffering purposes. © YouView TV Ltd (2011) Page 130 of 229 . the implementation shall proceed from then on as if a simple http: URL had been used.YouView Core Technical Specification Figure 21 Note: Interactions between the MediaRouter and Media decoder objects shown are illustrative only. an event shall be raised. The device makes a TLS connection to the server specified in the URL and performs client authentication if requested by the server. Once the secure connection has been established.4. Compliance and robustness requirements For content delivered in this manner:    Devices shall not provide any means for the user to export the content from the device.4. Detailed specification In this mechanism. The private key for client authentication shall be protected to the same degree as required by the Marlin Robustness rules. Description This mechanism allows encrypted content to be delivered.5.5. Detailed specification In this mechanism. authenticated connection. the implementation shall behave as described by the MS3 specification. with the keys and output control information being provided through a secure. a compound URI is passed by the application. 3. In summary. Note: YouView devices are not required to support triggering of MS3 by an Action Token or by an MS3 Manifest File. Figure 22 Note: Interactions between the MediaRouter and Media decoder objects shown are illustrative only.4. this mechanism aims to provide secure delivery of content into the device but provides limited protection against a determined attacker able to tamper with the device. 3. The compound URI includes an https: URL for an MS3 service (the S-URL). The format of the compound URI is specified in section 3. The content does not appear in the clear in the home network or on the content provider‟s servers.2 of the Marlin Simple Secure Streaming specification version 1. together with a URI template for an unencrypted delivery mechanism with which to obtain the content (the C-URIT).0.5. Device authentication and encrypted content delivery 3. When presented with a URI of this type. when starting to buffer content: © YouView TV Ltd (2011) Page 131 of 229 .1. As such.2.YouView Core Technical Specification  No robustness rules apply to the handling of session keys or decrypted content with this scheme. after the initial request for the content. The server responds with a Stream Access Statement (SAS) which can include an authenticator element to be substituted into the media URL and which also includes a set of output controls to be applied whilst the content is being played. If this fails. Licence acquisition prior to playback. The C-URL may reference any supported streaming protocol specified in Chapter IX IP Content Delivery. 5. the device needs to make a new request (for example to perform a seek. The content is streamed using the C-URL as if it had been provided directly by the application.YouView Core Technical Specification 1. 3. to resume after pausing or to re-try after a transient error condition). Two modes of licence acquisition are supported: 1. it is possible that this authenticator may expire after a period of time. Compliance and robustness requirements The Marlin Compliance and Robustness rules shall apply to the implementation of this mechanism. Server authentication shall be performed using the platform-specified bundle of HTTPS root certificates. the implementation shall return to the MS3 service for a new SAS. The implementation first makes a secure connection to the MS3 service with client authentication using. Licence acquisition on demand. 2. Before the content is decoded. Note: Steps 3 and 4 can proceed in parallel with steps 1 and 2 if C-URIT does not require an authenticator. If.1. Devices shall provide hardware-accelerated decryption for content delivered in this manner.9. The location of the web store may be known to the application (in the case of a VOD store app) or may be obtained from information held in the metadata system (in the case of IP linear channels). a content identifier is encountered for which a content key is not available.5. © YouView TV Ltd (2011) Page 132 of 229 . Where the SAS contains an authenticator. If the device cannot retrieve or process the SAS or at any point during presentation of content. 3. For the period that the content is being presented. the implementation shall first make one attempt to use the existing C-URL for the new request. The implementation forms a URL for the content (the C-URL) using the C-URIT and the authenticator. triggered by an attempt to play protected content for which the device does not already have a valid licence.6. 3. an event shall be raised. 4. 6. the media decryption function is configured to decrypt the content using the keys obtained from the SAS. initiated as a result of interactions between an application running on the device and an external „web store‟. including multicast delivery. The SAS and the buffered data shall be retained until the application ends the streaming session or selects a different source. DRM protected content 3.3.6. Bitrates up to the maximum required for unencrypted content shall be supported. This will result in improved start up times. 2. Description This mechanism uses the functions of the Marlin Broadband DRM system to protect the content covering use cases such as:   Content downloaded for playback at a later time Multicast IP linear channels requiring stored licences The DRM system can also be used for streaming use cases if desired. the output control mechanisms shall be configured to satisfy the output control requirements provided by the SAS within the context of section 3. as shown in Figure 24: Figure 24 : Licence acquisition 3. Implementations shall comply with the Marlin Broadband Delivery System Specification v1.6.3. 3.YouView Core Technical Specification For the period that the DRM-protected content is being presented.6. licence acquisition is initiated via an „action token‟ which is acquired from a web service.2 with support for BNS Extended Topologies. the output control mechanisms shall be configured to satisfy the output control requirements specified in the DRM licence within the context of section 3. This is the user-facing application through which the user selects content to watch or download and through which payments are made.2. For YouView. Devices shall indicate their support for BNS Profile and BNS Extended Topologies in the manner described in section 6 of the BNS specification. It stores and manages licences. A similar process would be used for downloaded content. action tokens are only acquired by applications and there is no provision for token acquisition by the lower level components directly.6.8).9. providing a high level interface to the application. This represents the interface onto the components that play back media content. DRM.2.4. Licence acquisition In the Marlin DRM system. licence acquisition is being initiated in advance of playback. Implementations shall provide a Full Implementation as defined by the Marlin Broadband Network Service (BNS) specification v1. This represents the system component that encapsulates the licence acquisition functions of the DRM system. Example usage The following sequence diagram shows a simple example using Marlin to protect a VOD streaming session. © YouView TV Ltd (2011) Page 133 of 229 . MediaRouter. This will generally be a service specific application but could be the UI in the case of IP linear channels. In this case. Figure 23 : Simplified architecture There are three components:  Player App.   3. Client architecture Figure 23 shows a simplified view of the client device (a more detailed view is provided in section 3. This is passed through an interfaced labelled „Drm‟ where the DRM client acquires a licence from the licence server.YouView Core Technical Specification Firstly. Figure 25 Note: Interactions between the MediaRouter and Media decoder objects. Management of licences. Licences are required for three types of content:    Downloaded content stored on the device Recordings made from protected linear IP channels and stored on the device Content not stored on the device (e. otherwise it shall be deleted. nodes and links Devices shall be able to store DRM licences.5. the application may optionally make an advance check that the DRM system now has a licence that will permit playback. content to be streamed or downloaded in future) Devices shall check all stored licences at least once every 24 hours against the following conditions. 3.g. the application performs a transaction with the web store and obtains an action token.6. When playback is requested. it shall be retained. © YouView TV Ltd (2011) Page 134 of 229 . and between the Drm object and the MediaRouter are illustrative only. These interactions are implementation dependent. After this process is complete. the implementation underlying the MediaRouter and Drm interfaces shown obtains the information required and begins decoding the media. If neither condition 1 nor condition 2 applies to a licence. Personalisation Marlin clients must be „personalised‟ in order to interact with Marlin licence servers and to handle Marlin licences.8.g. 3. The licence satisfies all of the following conditions: a. Note: This means that to store licences with the content. Devices shall implement a mechanism that ensures that the device is personalised before any third party application runs for the first time. The licence has a „urn:marlin:core:node:attribute:expiration-date‟ attribute that represents a date in the past. for different temporal parts of the recording).7. it has a „urn:marlin:core:node:attribute:expiration-date‟ attribute that is more than 30 days in the future or has no such attribute. prior to searching elsewhere to find a valid licence for a requested operation. See section 3. It is implementation dependent whether licences associated with content stored on the device are stored with the media or in a separate database. it was acquired more than 30 days ago Note: This ensures that where a licence relates to content that is stored on the device. The media streaming function also requires secure key management capabilities to implement client authentication for TLS streaming. licences may have to be copied as they may relate to multiple assets stored on the device. 3. The remaining components are shown in blue. © YouView TV Ltd (2011) Page 135 of 229 . The Marlin Broadband and MS3 client uses secure key management functions to protect its secrets.4. the licence will not be discarded until the content is deleted or the licence expires. if they were made from the same IP channel on the same day). Components in green are lower-level hardware or firmware components.g. Any requirement to access a remote server to perform this task shall be included as part of the device‟s software upgrade procedure. or 2. The media playback control function interacts with the MS3 client in order to obtain any „authenticator‟ required to access content. for different tracks) but would normally have a single licence covering them. and c. Compliance and robustness requirements The Marlin Compliance and Robustness rules shall apply to the implementation of this mechanism.g.6. Implementations must take account of the following scenarios:    Downloads may reference multiple content IDs (e.6. The components shown in red are expected to be provided by the DRM provider. A recording may reference multiple content IDs and multiple licences (e.YouView Core Technical Specification 1. See section 3. Devices shall check stored nodes and links at least once every 24 hours and discard any that have a „urn:marlin:core:node:attribute:expiration-date‟ attribute that represents a date in the past. Where content formats allow DRM licences to be embedded and delivered to the device within the media. typically specific to the particular SoC being used.3. devices shall search any such licences first. and b. Device architecture for content protection and DRM The following figure shows an architectural model of the content protection and playback functions of the device. Multiple recordings may require the same licence or licences (e. it is not required by any content stored on the device. 3. 9. the analogue output shall be disabled with no other feedback provided.9. When disabling the analogue video outputs. The set of output controls shall be evaluated each time presentation of content begins or ends. Where a content licence imposes constraints on analogue outputs that the device does not support. As specified in DTG D-Book 7 Part A v1. For all other output control mechanisms. Note: This is due to the long periods of black picture that result when the HDCP state is changed. © YouView TV Ltd (2011) Page 136 of 229 . HDCP shall be applied at all times unless the user has specifically configured the device to apply HDCP only where explicitly signalled. the analogue outputs shall be disabled. RSA etc. Requirements Devices shall support the following output control mechanisms:    HDCP CGMS-A Disabling of analogue outputs The set of output controls in force at any point in time shall be sufficient to meet the requirements of all A/V presentation sessions that are active. Output controls 3.1. Hardware A/V decoders Display hardware Figure 26 : Architectural model 3. the mechanism shall not be applied unless it is explicitly required for content that is currently being presented.YouView Core Technical Specification Applications Adaptation Control Output controls Demux & decrypt Media streaming Secure key box TLS auth for 3.4 Buffering MP4 TS Decode Display Marlin client MS3 Hardware AES. devices shall act as follows:  If a digital video output is active. The following table applies to video or audio-video content: Output HDMI Output control mapping HDCP ON if (CCI != 0 || EPN == 0) HDCP may be disabled in other cases if the user has specifically configured the device to disable HDCP where not required. In bitstream mode. This section is informative. Note: Chapter II Consumer Device Platform requires that the device has no analogue HD outputs. the video shall not be presented on the video plane and an on-screen dialogue shall be presented to the viewer. 3. In the event that the mappings defined here conflict with the requirements of the Marlin Compliance Rules. no restriction. those rules take precedence. Output disabled if (APS == 0 && DOT == 0) CGMS-A bits defined in EN 300 294 to be set according to the CCI value as follows: CCI Copy control not asserted (00) No more copy (01) Copy one generation (10) Never copy (11) SPDIF bit 12 0 0 1 1 bit 13 0 1 0 1 Analogue SD video In PCM mode. 48 kHz for all Marlin protected content. Mapping from Marlin output control parameters (informative) The Marlin specifications define a set of output control parameters that can be applied to Marlinprotected content:      Encryption plus non-assertion (EPN) Copy control information (CCI) ImageConstraintToken (ICT) DigitalOnlyToken (DOT) Analogue Protection System (APS) The following tables indicate how these parameters map to the outputs required on YouView devices.2. output restricted to maximum 2-channel. 16-bit.YouView Core Technical Specification  If no digital display device is active. SCMS set according to CCI value as follows: CCI Copy control not asserted (00) No more copy (01) Copy one generation (10) Never copy (11) SCMS Copy allowed Copy prohibited Copy once Copy prohibited Analogue audio No restriction.9. Table 29 : Output controls for video or audio-video content © YouView TV Ltd (2011) Page 137 of 229 . 16-bit. The Marlin Broadband Transport Stream format specifies how Marlin-specific information is carried in an IEC 62455 compliant transport stream. This specification specifies an encrypted MP4 format for progressive download only. bitstream output may be used if so configured. and where it can be found in the MS3 SAS.5) or Marlin Broadband (see section 3. the encrypted content format for MPEG2-TS content is IEC 62455. Devices shall be able to decrypt from the first encrypted packet when commencing playback. Streams shall be constructed such that at any point in a stream where the service_CID_extension or program_CID_extension changes. Devices shall support MP4 content encrypted using the OMA PDCF format. 3. This shall be supported both for the case where the content key can be found in the Marlin Broadband licence store. © YouView TV Ltd (2011) Page 138 of 229 . 48 kHz for all Marlin protected content.YouView Core Technical Specification The following table applies to audio-only content: Output control SPDIF Mapping In PCM mode.1.10. provided that streams contain a valid ECM located between the start point and the first encrypted packet. particularly where support for both progressive download and adaptive bitrate streaming is required. YouView will address the requirement for an encrypted. Devices can expect that the current traffic key obtained before the content ID change will continue to decrypt the stream after the ID change up to the next key change. 3GPP.6) shall comply with the requirements of the Marlin Broadband Transport Stream Format specification version 1.2. Devices shall be able to present seamlessly BBTS encrypted content in which the service_CID_extension or program_CID_extension changes mid-stream. Devices shall output only PCM audio on SPDIF if (CCI != 0 || EPN == 0). OIPF.10. Encrypted streams shall use a single Initialisation Vector throughout. Seamless presentation is not required if the serviceBaseCID changes. Table 30 : Output controls for audio-only content SCMS Copy allowed Copy prohibited Copy once Copy prohibited 3. provided that the device has already acquired content keys for the new content identifier resulting from the change. output restricted to maximum 2-channel. Devices are not required to support Silent Rights or Preview Rights URL signalling.0.2. MPEG-2 transport stream As defined in Chapter IX IP Content Delivery. there is no change to the current traffic key. fragmented MP4 file format at a later date. Encrypted streams intended for use with MS3 (see section 3. SCMS set according to CCI value as follows: CCI Copy control not asserted (00) No more copy (01) Copy one generation (10) Never copy (11) Analogue audio No restriction. If (CCI == 0 && EPN == 1). MP4 YouView shareholder companies are involved in industry standardisation activities including DTG. These standardisation activities still have some way to go in agreeing a common approach to MP4 encryption. DECE and MPEG and take the work of these groups into account when deciding on content formats. Protected content formats 3.10. Devices shall support embedded licences.3. Devices are not required to support Silent Rights or Preview Rights URL signalling.0.YouView Core Technical Specification Encrypted streams intended for use with MS3 (see section 3. © YouView TV Ltd (2011) Page 139 of 229 .6) shall comply with the requirements of the Marlin Specification version 1.5) or Marlin Broadband (see section 3. . YouView Core Technical Specification Chapter XI Content Acquisition And Management © YouView TV Ltd (2011) Page 141 of 229 . and Local Media Library. However. either by the audience as a whole. Section 4 specifies the support for download over IP to be provided by the IP Downloader component. © YouView TV Ltd (2011) Page 142 of 229 . Hence all of the decision-making logic (or “business rules”) can be restricted to this function alone and internalised. specifies the support for managing and accessing acquired content to be provided by the Local Media Library. Section 2 specifies the consumer device content acquisition and management architecture. For example. Section 7. when the two acquisition functions are both present the business rules need to span both functions. which can be used to reduce (or mitigate) the level of IP traffic by pre-acquiring programmes that are likely to be viewed. This will also enable maximum re-use of existing. if the DVR fails to acquire a particular broadcast instance it may be better to initiate an IP download than wait to acquire a repeat transmission several days later. This is specified in section 5. or in a more advanced exploitation by the specific household in which the device is installed. This has been designed so as to allow the content acquisition functions in the consumer device to be as autonomous as possible due to their mission-critical nature. Section 3 specifies the support for programme acquisition from linear channels (e. and introduces the logical components : Linear Acquisition.YouView Core Technical Specification 1. This includes support for series bookings and the use of alternative instances when a recording attempt fails. Section 6. The Acquisition Manager component encapsulates business rules that cannot be internalised to the individual components providing acquisition capability. The same is true of a media asset download over IP function in an IP-only device. DVR enabling functionality) to be provided by the Linear Acquisition component. Acquisition Manager. Chapter Summary This chapter specifies the support for content acquisition and management to be built into a YouView device. In a non-IP-connected DVR device the programme acquisition from broadcast function can operate on the assumption that it controls the only way to acquire content. tried-and-tested code for both programme acquisition from linear channels (as found in existing DVR products) and media asset download over IP. specifies the support for background acquisition of programmes from linear channels.g. 2. Acquisition Manager The Acquisition Manager has three roles in the acquisition architecture:    It provides means by which an application can book IP downloads. Acquisition subsystem architecture 2.2.4. The Local Media Library The Local Media Library contains all programme content that has been acquired by the device – both via broadcast and IP. acquisition and consumption architecture overview Note 1: To simplify Figure 27 some links have been omitted. It provides means for booking acquisitions and querying the list of pending acquisitions.2. It implements business rules to minimise viewer interaction in acquisition scenarios. 2. IP Downloader This component handles the download of content over IP. 2.1. acquisition and consumption of programme content on the device.2. It implements the Push-VOD for IP mitigation functionality described in section 7. Introduction 2. This chapter describes the functionality of the components in the acquisition subsystem and the relationships between them. © YouView TV Ltd (2011) Page 143 of 229 . other device services may also interact with components of the acquisition subsystem.YouView Core Technical Specification 2. Linear Acquisition This component handles the acquisition of content from linear channels over both broadcast (DVB) and IP. Application Acquisition Manager PushVOD record list retrieval Business rules Download booking interface Broadcast metadata IP metadata Linear Acquisition IP Downloader Media Router Local media library metadata Local Media Library Acquisition Consumption Figure 27 : Discovery. 2.2. The component houses the logic required to provide series bookings and utilise alternative instance information in the case of acquisition failure. Note 2: In addition to the Platform Main UI.1.3.2.2. The conceptual model Figure 27 shows the system components involved in the discovery. 1.4.5 At the point of acquisition (Acquisition Conflict) – see section 3. Overview The Linear Acquisition component shall satisfy the functional requirements defined in this chapter and in DTG D-Book 7 Part A v1.2. A Booking may have zero or more Scheduled Recordings associated with it. Take the first opportunity to acquire any linear events with the provided Series CRID (subject to rules in section 3. Tuner management Due to the finite number of tuners in the device. Linear Acquisition (DVR) 3. 3. Table 31: Types of Booking Description Acquire the linear event with the provided event locator. A Scheduled Recording describes a specific acquisition attempt and will be linked to either an event in the linear schedule or to a time window on a linear service.2. Conflicts can arise if bookings are created which require more tuner resources than are available for linear acquisition. 3. Take the first opportunity to acquire a linear event with the provided Programme CRID. the number of concurrent recordings that can be made by the Linear Acquisition component is limited.1.2. Other software components that need access to tuners shall work around the behaviour of the Linear Acquisition component and under some circumstances are required to make use of tuner resources controlled by the Linear Acquisition component. Scheduled Recording 3.3).4. Contains descriptive metadata about the Booking along with the priority level and an identifier (CRID or event locator) supplied at booking time.1).3. © YouView TV Ltd (2011) Page 144 of 229 . Types of Booking There are five different types of Booking that the Linear Acquisition component shall accept. Bookings and Scheduled Recordings The Linear Acquisition component shall keep track of the acquisition requests that it accepts and shall logically represent this list using two structures: Booking A request to acquire one or more events (see 3.1. These types require different identifiers to be included as part of the booking request: Type Event Programme Series Collection Timer Mandatory ID Event locator Programme CRID Series CRID Collection CRID Service locator Record from a linear service between two times specified in the Booking.2 As a result of changes to the schedule since booking but before acquisition (Post-booking Conflict) – see section 3.5.1. The Linear Acquisition component is required to deal with conflicts which may be detected:    At the time of booking (Booking Conflict) – see section 3.1 The Linear Acquisition component shall be able to take control of tuners as necessary to meet its acquisition obligations.YouView Core Technical Specification 3. this means that more than one Scheduled Recording could be associated with the same Schedule Event. Series Bookings will have zero or more Scheduled Recordings associated with them. Managing Scheduled Recordings The Linear Acquisition component shall manage the Scheduled Recording(s) associated with each Booking independently.* -Booking Reference 1 -Booking Reference :Scheduled Recording :Scheduled Recording :Scheduled Recording :Scheduled Recording 1 1 -Event Locator 1 1 -Event Locator 1 1 -Event Locator 1 1 -Timer Reference :Schedule Event :Schedule Event :Schedule Event :Timer Figure 28 : The types of Booking 3. :Event Booking :Programme Booking :Series Booking :Timer Booking 1 1 1 1 1 -Booking Reference 0. When queried.2..YouView Core Technical Specification Figure 28 shows how the different types of Booking will be represented in the logical model defined at the start of section 3. the Linear Acquisition component will return all Scheduled Recordings separately.4.2 and 3. The Scheduled Recording will be created when an event with the appropriate programme CRID has been located in the schedule.2. The number of Scheduled Recordings will be dependent on the number of events with the Series CRID (from the Booking) in the current linear schedule. Booking sources The Linear Acquisition component will process Bookings from several sources in the system:   8 The Platform Main UI application i. © YouView TV Ltd (2011) Page 145 of 229 .  3.2.4.1 -Booking Reference 0. Event Bookings will have a single Scheduled Recording which in turn is associated with a schedule event.3. At the conclusion or failure of acquisition every Scheduled Recording associated with the acquired Schedule Event shall be updated in isolation. Timer Bookings will have a single Scheduled Recording which in turn is associated with a specific time window on a particular linear service. To handle this at the various points in the acquisition chain:   Scheduled Recordings with the same event locator shall be treated as a single virtual 8 Scheduled Recording for the purpose of detecting Booking and Acquisition conflicts. Programme Bookings will have up to one Scheduled Recording associated with them at any given time. However..e. even if they have the same event locator meaning that the Platform Main UI will need to filter the resulting list in order to provide a coherent de-duplicated view of which Events will be acquired. user Bookings A Record List function The virtual Scheduled Recording shall have priority equal to the highest priority Scheduled Recording with that particular event locator.3) to be repeatedly executed as a self-contained activity.2. This allows the resolution process for Programme and Series Bookings (as described in sections 3. The priority level of a Booking is used to aid the resolution of recording clashes i.5 At the point of acquisition (Acquisition Conflict) – see section 3.2.5. 3.e. 3.3. Priority 1 Event Bookings If the Linear Acquisition component predicts that it will have insufficient tuner resources available to acquire the requested event (see section 3.5.2.1).2 The priorities (with 1 being the highest) are described below: 45 Priority level Highest 1 2–6 Lowest 7 – 11 Use Viewer Booking D-Book specified record list Booking Platform specified Push VOD (see section 7) Booking Table 33: Booking priority levels The priority of the Booking also affects how any associated Scheduled Recordings are managed alongside live or time-shifted consumption of linear TV/radio (see section 3.3. Making a Booking A Booking is made by calling methods of the Linear Acquisition component.5. Duplicate Bookings The Linear Acquisition component shall always reject Booking requests that are a duplicate of an existing Booking. Booking priorities In order to manage Bookings from multiple sources the Linear Acquisition component shall observe a priority system.3. 3.4.1 As a result of changes to the schedule since booking but before acquisition (Post-booking Conflict) – see section 3.2.3. 3.1. This can be used by the caller (likely to be the Platform Main UI) to alert the © YouView TV Ltd (2011) Page 146 of 229 .2. where the number of concurrent recordings exceeds the acquisition capabilities of the device:    At the time of booking (Booking Conflict) – see section 3.YouView Core Technical Specification  A platform specified Push-VOD function The types of Booking that each of these functions can make is restricted as shown in Table 32. If there is an existing Booking of the same type with the same priority and identifier (CRID or Event Locator) the Booking request shall be rejected. Event Bookings An Event Booking is a request to acquire a specific event from the linear schedule.4. Type Programme Booking Event Booking Series Booking Timer Booking Viewer     Table 32: Booking types mapped to Booking sources D-Book Broadcast Record List   Platform managed Push-VOD   3.1) then it has detected a Booking Conflict and it shall reject the Booking.3.1.. 2. The request to start recording shall be successful if:    Note: The Event requested is in the present slot of EIT p/f on its parent Service. Series Bookings resolution The Linear Acquisition component shall keep a list of all Programme CRIDs that have been completely acquired in satisfying a given Series Booking.2. 3. The prediction shall be based on the linear schedule available at the time of booking. 3.4. Tracking schedule changes The Linear Acquisition component shall update the Bookings and Scheduled Recordings in line with new schedule information. Requests to start an instant recording are not subject to the conflict detection rules defined in section 3. Priority 2 – 11 Event bookings The Linear Acquisition component shall always accept lower priority (2 – 11) Bookings regardless of any potential conflicts. Programme Bookings resolution For any Programme Bookings that do not have an associated Scheduled Recording the resolution process shall find the soonest Event that can be scheduled for acquisition without causing a predicted conflict. instead resolving any conflict at acquisition time.4. Schedule changes shall be tracked as defined in DTG D-Book 7 Part A v1.2.3.4. 3.3.4.3. Both Programme and Series Bookings require further management to resolve the Booking into one or more events to acquire. 3. Starting a recording using this method could introduce future acquisition clashes that will be dealt with as defined in section 3. Multiple Scheduled Recordings related to different Bookings can be linked to acquisition of the same Event as specified in section 3. 3. Neither of these Booking requests involves an event locator so the Linear Acquisition component shall not attempt to detect any conflicts at booking time. The list associated with a Series Booking shall be checked before any new Scheduled Recordings are created and associated with that © YouView TV Ltd (2011) Page 147 of 229 . Bookings management 3.3.4. Note: A Booking Conflict will only occur when making a Priority 1 Event Booking. Instant recording The Linear Acquisition component provides a means for the viewer to request the „instant recording‟ of the service currently being viewed.3. The Event is not currently being acquired as a result of an existing Priority 1 Scheduled Recording.1. e.YouView Core Technical Specification viewer. Programme and Series Bookings Programme and Series Bookings represent a request to acquire a single Programme or an entire Series respectively.2.3.5.2. presenting a suitable on-screen dialogue to allow them to resolve the conflict.2.2.4. The exact nature of this dialogue and how it is achieved is outside the scope of this specification. When new linear schedule data becomes available the Linear Acquisition component shall check whether any new events carry a CRID that is present in the Booking list. The Linear Acquisition component has sufficient resource to start the recording (see note).g. This resolution process is described in sections 3.2 and 3.4.3. 3. 4.5.3 shall not execute in the 10 minutes immediately after the viewer has deleted a Scheduled Recording. The list shall be deleted when the Series Booking is deleted. One possible outcome of changes to Scheduled Recordings is that a conflict is introduced and the Linear Acquisition component will not be able to acquire all the Priority 1 Scheduled Recordings.5. Creating Scheduled Recordings When a new Scheduled Recording is created the Linear Acquisition component shall inform the Local Media Library which shall then estimate the space required to store the acquisition (see section 6.4. Deleting a Scheduled Recording If a Priority 1 Scheduled Recording is deleted.4. If the CRID is in the list no Scheduled Recordings shall be created.  3. an identical Scheduled Recording may be created as part of the next automatic update as described in section 3.4. the Booking shall not be deleted.6.YouView Core Technical Specification Booking. The Linear Acquisition component shall search for any Events that have a Series CRID that matches the Booking.4. 3.1. When an Event is found the Event‟s Programme CRID (if present) shall be checked against the list of Programme CRIDs already acquired for this Booking:  If the CRID is not present in the list.6. To avoid this becoming a race condition when the viewer is attempting to manually resolve a booking conflict the automatic update process described in sections 3. If any of the Scheduled Recordings are in progress the Booking cannot be deleted until these Scheduled Recordings have been stopped or have completed. If a deleted Scheduled Recording is linked to a Programme or Event Booking. Determining which Events to acquire 3.4.1). Viewer updates to Bookings and Scheduled Recordings 3. As a consequence of this. If the creation of a new Scheduled Recording means that there is now more than one Priority 1 Scheduled Recording associated with a broadcast event the Local Media Library will already have estimated space and shall not be informed. the automatic update shall find the soonest Event with that Programme CRID that can be scheduled for acquisition without causing a predicted conflict. This ensures that repeat showings of a programme are not acquired again even when a device has already completely acquired the programme and the viewer has deleted the file from the Local Media Library.2 and 3.6.4.4. Working with available tuner resource When allocating tuners to acquisitions the Linear Acquisition component shall base its decisions on the following order of priorities: © YouView TV Ltd (2011) Page 148 of 229 . 3. 3. the Linear Acquisition component shall also delete the Booking.5. If a Scheduled Recording is deleted and the parent Booking is a Series Booking.1. any duplicate Priority 1 Scheduled Recordings that are associated with the same Schedule Event shall also be deleted.2. 3.2.4. Post-booking conflicts The Linear Acquisition component shall respond to changes in the schedule as defined in section 3.4. Deleting a Booking When a Booking is deleted the Linear Acquisition component shall delete all associated Scheduled Recordings.3.1. Priority 2-11 Scheduled Recordings shall only be acquired where they do not disrupt the control of tuners for Priority 1 Scheduled Recordings or live/time-shifted linear consumption. For timer based acquisition it is expected that the acquisition start time will be the scheduled start time of the event and the acquisition end time will be the scheduled end time of the event e. even if this is at the expense of live TV viewing.2.5. Commencing acquisition Acquisition of linear content shall be controlled by changes in the EIT present/following information as described in the DTG D-Book 7 Part A v1. to support acquisition from IP channels.2. 3.6. 3.6. Acquisition of low priority Scheduled Recordings shall take place if possible even if some higher priority Scheduled Recordings are not possible.g.YouView Core Technical Specification Most important Less important Least important Priority 1 recordings Live or time-shifted linear consumption (TV/Radio) Priority 2-11 recordings This means that the Linear Acquisition component is able to take control of tuners as necessary to meets its acquisition obligations with respect to Priority 1 Scheduled Recordings. Support for timer based acquisition is not required for launch. Handling Acquisition Conflicts An Acquisition Conflict arises when there are insufficient tuner resources to start a new recording.6. Components to acquire The Linear Acquisition component shall acquire the following components of a linear channel:  video (if a TV service) © YouView TV Ltd (2011) Page 149 of 229 . There may be multiple Priority 1 Scheduled Recordings associated with a single Schedule Event and for the purposes of acquisition conflict detection they shall be considered as a single Priority 1 Scheduled Recording see section 3.2. Figure 29 shows how the Linear Acquisition component shall behave when an Acquisition Conflict occurs.2.1. Insufficient resources to start new recording Yes Is there an in-progress recording with a lower priority than the one due to start? No Stop the recording with the lowest priority and start the new recording Do not start new recording – re-evaluate when a current inprogress recording finishes Figure 29 : Behaviour for Acquisition Conflicts 3. Acquisition 3. { “type”: “end”. a page with no regions or a page with regions that are all empty of objects implies the end of that subtitle. the device shall record the PTS value of the corresponding subtitle PES packet and store this information in the Local Media Library. or the end of a subtitle by identifying how many regions are listed in the page composition segment. “time”: “123456789” }. The PTS value of the first video frame shall also be recorded. “time”: “123456789” } ] } Where 123456789 is replaced by the relevant PTS value in units of 1/90. If there was a subtitle present previously.    If there was no subtitle present previously. an update of a subtitle on screen.. and whether there is a version change for the page or for any region. “time”: “123456789” }. Subtitle timing signature Whilst making any recording from a linear channel. PTS of first video frame PTS of subtitle start event . The information shall be made available in the following format: { “startTime”: “123456789”.YouView Core Technical Specification    audio. change and end point detected. in accordance with viewer preferences at the time of acquisition subtitles (if present) – see section 3. { “type”: “update”. “subtitles”: [ { “type”: “start”. The device shall provide a mechanism by which the timing data can be accessed by applications. { “type”: “end”. “time”: “123456789” }.000 sec. “time”: “123456789” }. if the service contains a subtitle component. there is a subtitle change if the page or any region that is part of the page changes version. If a previous subtitle has not ended. continued for additional events © YouView TV Ltd (2011) Page 150 of 229 .2. the presence of one or more regions containing one or more objects implies a subtitle start.6.6.2.1. the device shall determine whether the packet contains the beginning of a new subtitle. the device shall parse the subtitle data to extract the timings of significant subtitle events as follows: For each subtitle PES packet. The device does not need to parse any further structures within the subtitle PES packet and does not need to decode any subtitle bitmaps. { “type”: “start”.1 for additional requirements audio description (if present) 3. which of these contain subtitle objects.. For each start. any associated Scheduled Recordings in the logical representation defined in section 3.3.1. The Local Media Library runs out of free storage space. When an acquisition is complete. If a Scheduled Recording is part of a Series or Collection Booking.7.2 shall be deleted. 5. Acquisition is stopped under the runaway recording rule as defined in DTG D-Book 7 Part A v1 section 22. Complete acquisitions An event is deemed to be completely acquired if: Actual duration (see Note) Ten minutes or less Greater than ten minutes Complete condition More than the 80% of the actual duration has been acquired More than the actual duration minus two minutes has been acquired Table 34 Conditions for a complete acquisition Note: The actual duration is defined as the time between the event entering the present slot of EIT p/f and subsequently leaving it. 3.6.3. 3. the Booking shall not be deleted and the Programme CRID (if any) shall be added to the list of CRIDs already acquired for that Booking. The Linear Acquisition Component stops the recording to free resource for a higher priority acquisition. 3.YouView Core Technical Specification 3.1.7. 2.7.2. Acquisitions that conclude due to viewer action In every instance where the viewer prematurely concludes an acquisition. Post-acquisition handling 3. For timer records the actual duration shall be taken as the time between the scheduled start time of the recording and the scheduled end time. Viewer interaction causes the acquisition to be stopped. any acquired media shall be kept in the Local Media Library (regardless of the amount of content acquired).3.14 3. If a Scheduled Recording is part of a Programme Booking the parent Booking shall also be deleted. Failed acquisitions An acquisition is deemed to have failed if: Actual duration (see Note) Ten minutes or less Greater than ten minutes Failure condition Less than 50% of the actual duration has been acquired Less than five minutes of the programme has been acquired Table 35: Conditions for a failed acquisition © YouView TV Ltd (2011) Page 151 of 229 . 4. If the viewer initiates a recording after an event has entered p/f present the actual duration shall be calculated from the point at which recording began.2. Concluding acquisition An acquisition could be concluded for one of the following reasons: 1. The defined end time for the acquisition is reached (Timer based Bookings only). The event being acquired moves from the present slot in the EIT p/f. 6.6. the associated Scheduled Recording shall be deleted. The Scheduled Recording associated with the failed acquisition shall be deleted. Priority level 2 – 11 Event or Programme Bookings The Linear Acquisition component shall not look for alternative instances to acquire failed lower priority Bookings.3.7. 3. Series Bookings If a Scheduled Recording linked to a Series Booking fails. Priority 1 partial acquisitions If an acquisition is partial the Local Media Library shall retain the acquired content and metadata. both the Booking and the Scheduled Recording are to be deleted. the Linear Acquisition component shall search the current EITschedule to find an alternative instance that can be acquired.2.1. If an alternative instance is found and the subsequent acquisition attempt results in a partial or complete acquisition. Priority level 2 – 11 partial acquisitions The Linear Acquisition component shall not look for alternative instances to satisfy lower priority Bookings. a Scheduled Recording may be created as a result of the automatic update described in section 3. In case of failure.3.7.2) and does not satisfy the criteria for a complete acquisition (see section 3. the stored metadata for the old (failed) acquisition shall be discarded from the Local Media Library.3.1.1 to look for alternative instances that could be acquired.2.2. The Linear Acquisition component shall follow the process defined in section 3. If no content has been acquired the Local Media Library shall update its estimate of storage requirements (see section 6. any associated Scheduled Recordings in the logical representation defined in section 3.2) and retain the stored metadata. If the viewer initiates a recording after an event has entered p/f present the actual duration shall be calculated from the point at which recording began.7. Timer based Bookings The Linear Acquisition component shall not look for alternative instances to acquire failed Timer Bookings. a greater proportion of the programme is acquired.4. If an alternative instance is available for the failed recording. In case of failure.YouView Core Technical Specification Note: The actual duration is defined as the time between the event entering the present slot of EIT p/f and subsequently leaving it.7. If no alternative instance can be found the Scheduled Recording associated with the failed acquisition shall be deleted as well as the associated Booking. When an acquisition fails. a new Scheduled Recording shall be created (see section 3. 3. © YouView TV Ltd (2011) Page 152 of 229 . both the Booking and the Scheduled Recording are to be deleted.7. 3. 3.4) and linked to the original Booking. 3. If. Priority level 1 Programme or Event Bookings If a Scheduled Recording linked to a Programme or Event Booking fails.3).2 shall be deleted.7. on a subsequent acquisition attempt.2. The Local Media Library shall delete any acquired content associated with the acquisition but retain the stored metadata (see section 6.2. Partial acquisitions An event is deemed to be partially acquired if it does not satisfy the criteria for failure (see section 3.4. 3.7). If an alternative instance is found.2. For timer records the actual duration shall be taken as the time between the scheduled start time of the recording and the scheduled end time. The search shall be based on the Programme CRID associated with the Schedule Event in the EIT p/f information. In case of failure.7.4.7.3.3. both the Booking and the Scheduled Recording are to be deleted.7. the new acquisition and supporting metadata shall replace the partial acquisition in the Local Media Library. 3.4.2. IP Downloader The IP Downloader shall support the download mechanisms defined in Chapter IX IP Content Delivery. © YouView TV Ltd (2011) Page 153 of 229 .YouView Core Technical Specification 4. It shall also support the resource management functionality defined in this chapter. To achieve this. The Acquisition Manager has three roles in the acquisition architecture: The first is to allow for the booking of content downloads. If an acquisition fails. Finally.YouView Core Technical Specification 5. the Acquisition Manager will pursue other acquisition opportunities for that piece of content e.e. General The Acquisition Manager shall satisfy the functional requirements defined in this section. The Acquisition Manager 5. the logic to acquire a record list. The Acquisition Manager‟s second role is to minimise viewer interaction in acquisition failure scenarios. The Acquisition Manager resolves a request for a content download into one or more file requests which are passed on to the IP Downloader component. modifying the acquisition behaviour of the platform over time. 5. if a recording fails and the Linear Acquisition component cannot identify an alternative instance. Part of the Acquisition Manager‟s functionality is the application of business rules which are likely to evolve over time.g. the Acquisition Manager will need to be configurable. Architecture The business logic implemented by the Acquisition Manager will need to evolve. the Acquisition Manager houses the Push-VOD for IP mitigation functionality i. the Acquisition Manager may be able to arrange for the programme to be download over IP instead. over broadcast and/or IP and to make the necessary requests of the Linear Acquisition component.1. This provides a point at which business and operation rules relating to the prioritisation of concurrent download requests can be applied. Platform Main UI Download booking Acquisition Manager Push-VOD for IP mitigation logic Logic to maximise acquisition opportunities (business rules) Recording booking Acquisition events (download) Query contents of library Download booking interface Individual file requests Linear Acquisition Recorded programmes Interface 1 Acquisition events (recording) File events IP Downloader Downloaded programmes Local Media Library Figure 30 : The acquisition subsystem architecture © YouView TV Ltd (2011) Page 154 of 229 .2. 3. 6.3).2. Download 6. The amount of space that the Local Media Library anticipates will be required to store all the pending downloads. Anticipated (downloads) Note: Local storage allocated to Push-VOD (Priority 7 – 11) acquisitions shall not be included in the values above. the Local Media Library shall calculate the estimated space requirement by multiplying the published duration (in seconds) of each event to be acquired by an estimated bit rate. The space requirements will be provided in the metadata that describes the download. 6.4.YouView Core Technical Specification 6. Reporting available storage space The Local Media Library shall track the amount of storage that is: Free Used (recordings) Used (downloads) Anticipated (recordings) Not currently in use.1. IP Downloads The Local Media Library may acquire the necessary metadata before acquisition begins but it must update the metadata at the time of acquisition.4). It is permissible for the amount of estimated space required to exceed the free space available.4. The Library also stores descriptive metadata for:     Pending acquisitions (excluded from queries as defined in section 6. 6. Partial acquisitions. Complete acquisitions. one for SD services and one for HD services. The Local Media Library contains all the programme content that the device has acquired through either linear acquisition or IP download in a single storage area. 6. General The Local Media Library shall satisfy the functional requirements defined in this chapter.2.3. Recordings This descriptive metadata shall be obtained from broadcast. The Local Media Library shall acquire the necessary metadata when the Linear Acquisition component creates a Scheduled Recording (see section 3. . Local Media Library 6. © YouView TV Ltd (2011) Page 155 of 229 .3. Currently in use to store recordings.1.1. It is sufficient for the Linear Acquisition component to use two bit rate estimates for this purpose.2. Determining estimated space Broadcast For items still to be acquired by the Linear Acquisition component. Failed acquisitions. Currently in use to store downloads. Metadata storage The Local Media Library shall store descriptive metadata with each acquired programme. The amount of space that the Local Media Library anticipates will be required to store all the pending (Priority 1) Scheduled Recordings. It is permissible for the amount of estimated space required to exceed the free space available. this process shall attempt to free up local storage space by deleting acquired programmes. The Local Media Library shall provide means by which an Application can check whether a specific programme is present in local storage by providing an appropriate identifier e.YouView Core Technical Specification 6. Metadata integrity The Local Media Library shall periodically (at least once every 24 hours) check that every content item available from local storage has a corresponding metadata record.4.4. Protecting programmes Content items can be protected from the automatic deletion process by marking them as protected. a Programme CRID. but it shall include entries for failed acquisitions. When active.4. Storage management 6. Most recently acquired. 6. The algorithm shall first delete content items that have been played starting with the oldest priority 6 acquisitions and ending with the newest Priority 1 acquisition.g. The Local Media Library shall take into account all locally stored content (including any in the PushVOD reservation) as part of this check. Any local storage items without supporting metadata shall be deleted. 6.2) or entries describing pending acquisitions. 6. The process shall be applied when the amount of Local Media Library storage (excluding the Push-VOD reservation) that is free falls below a configurable threshold.3.1. 6. and shall support the sorting of returned results by:    A – Z based on title. When responding to such queries the Local Media Library shall not include the contents of the PushVOD reservation (see section 7. Querying the library contents The Local Media Library shall provide means by which the contents of the library can be queried.5. When the percentage of storage that is in use has fallen below the defined threshold the process shall stop. If more space is required the algorithm should then delete unplayed content items starting with the oldest priority 6 acquisitions and ending with the newest priority 1acquisition.4.4.4.4.2. Deleting an item requires that the Local Media Library remove any metadata and stored content associated with the item. Freeing up storage space To allow the device to operate in a manner such that new recordings and downloads never fail due to lack of free storage space the Local Media Library shall offer an automatic deletion capability. The viewer shall be able to enable or disable the automatic deletion process within the device settings. © YouView TV Ltd (2011) Page 156 of 229 . Deleting library items The Local Media Library shall provide means by which the Platform Main UI can delete items from the library. Most recently viewed. If available. the platform operator can prime the storage using Push-VOD. without any unwanted announcements. To increase the likelihood that a requested asset is present in local storage. The Acquisition Manager shall contain the functionality required to fetch the list of items to be acquired and manage the appropriate Bookings on the Linear Acquisition component.1 to play back a recorded programme identified in this way cleanly.4. 7.4) shall be stored in this reserved storage. The device reserves a portion of local storage for Push-VOD use which the platform operator can use to store recorded assets. Introduction Before initiating playback of an IP stream an application is able to check whether the asset to be streamed is available from local storage (see section 6. The list of assets within this reserved storage is never directly exposed to applications. Reserved storage for Push-VOD The Local Media Library shall reserve 30GB of storage to store speculative acquisitions made for the purpose of IP traffic mitigation. Applications can use the subtitle timing signature described in section 3.1. The Local Media Library shall offer applications the opportunity to check whether an asset is available from local storage. The platform operator specifies which programmes should be recording by means of a record list. © YouView TV Ltd (2011) Page 157 of 229 .YouView Core Technical Specification 7.2. Push-VOD for IP Mitigation 7. the stored asset can be played back instead. Any acquisitions made to satisfy Bookings with a priority of 7 – 11 (see section 3.2. based on content popularity.6. an alternative would be to generate a custom list for each device based on viewing habits. In simple implementations there may be a single record list for all devices e.g. thus reducing traffic on the IP network.3).2. . YouView Core Technical Specification Chapter XII Application Discovery And Installation © YouView TV Ltd (2011) Page 159 of 229 . installed and managed on the consumer device. Chapter Summary This chapter describes how downloadable Applications (which will be referred to as Content Provider Applications) are discovered. Other Applications may be present on the device provided as part of the Platform Software. © YouView TV Ltd (2011) Page 160 of 229 . and introduces the logical components Local Application Library. . This is not covered by this chapter.YouView Core Technical Specification 1. Figure 31 shows three different ways in which Applications could be discovered by the viewer. Platform Main UI Browse on-demand Eastenders Hollyoaks Coronation Street Platform Main UI Application Gallery App A App D App B App E App C App F TV (BBC One) RED Install(App E) if not installed install(ITV Player) If not installed install(BBCRedButtonApp) Local Application Library (LAL) Periodic check and update Application Monitor Platform Main UI My Apps App Q App T Launch(BBCRedButtonApp) App Z Launch(ITVplayer) Launch(AppZ) User Interface Management Engine ITVplayer App Z BBCRedButtonApp App Z Figure 31 : Content Provider Applications overview © YouView TV Ltd (2011) Page 161 of 229 . Overview The Platform Main UI allows the viewer to discover a range of Content Provider Applications that can be installed onto the device.YouView Core Technical Specification 2. The viewer will not necessarily be aware that an Application launch is involved e. Viewers can list the contents of the LAL and launch any of their installed Applications. © YouView TV Ltd (2011) Page 162 of 229 . Implicit Application discovery In some cases the viewer will make a request that requires that a Content Provider Application be launched. 2.1. each of which is dependent on a Content Provider “player” Application for its presentation. The pre-installation and update of the Applications is handled by the logical component shown in Figure 31 as the Application Monitor. the Platform Main UI lists content items in the on-demand section.g. in Figure 31 the viewer selects “Coronation Street” from an on-demand menu which requires the launch of the “ITV Player” Application. For example. Here the viewer can select specific Applications to be installed onto the device where they are stored in the Local Application Library (LAL).3. 2. Explicit Application discovery The Platform Main UI provides a means for viewers to discover the Applications available to them in the “Application Gallery”. 2.YouView Core Technical Specification 2. If the required Application is not present in the LAL it will have to be installed in a “just in time” manner. Pre-installing these Applications means that the viewer does not have to wait when an item of content was selected.3.1. Classes of Application Content Provider Applications can be classified as follows:   A Viewer-managed Application is one has been installed at the direct request of the viewer. A Platform-managed Application is one that has been installed at the request of some Platform management service. Pre-installation of Applications For a performant viewer experience it is useful to have a collection of frequently used Applications pre-installed on the device.2. UIME Launch Metadata Publication service List Download ADI Local Application Library Verification Install Update Uninstall Platform Main UI Application hosting B2B Application catalogue Core Operations (CCO) Back-end functionality Client-facing interface B2C OSL Device Capability Information MAS Figure 32 : System overview Viewer discovery of Applications within the Platform Main UI is based on metadata provided by the Metadata Aggregation System (MAS). Management and update of installed Applications (see section 6). The LAL also stores descriptive metadata for installed Applications for use by the Platform Main UI. Content Provider App provider back-end services Device App. At the heart of the environment is the Local Application Library. Overview Figure 32 shows the different logical components that make up the Application Discovery and Installation environment. The User Interface Management Engine (UIME) is responsible for managing the life-cycle of launched Applications (see Chapter XIII Consumer Device UI Management).1.YouView Core Technical Specification 3. The LAL offers four main functions:     Installing Applications. This allows Content Providers to control which version of an Application is available at a given time. including download and verification (see section 4). Instead they are hosted by the Content Provider and may be downloaded over the Application Download Interface (ADI). Applications themselves are not hosted by the Platform Operator. © YouView TV Ltd (2011) Page 163 of 229 . Application discovery and installation architecture 3. Allowing other software components to query the installed Applications as part of Application launch (see section 5). Uninstalling Applications (see section 7). In order to provide these functions the LAL includes Download and Verification subcomponents. Application 1 n Platform B2B metadata Device-specific Application Build 1 (see note) 1 Application Download Interface Version of Device-specific Application Build Figure 33 : Conceptual data model The top level Application entity represents the abstract application concept and contains descriptive information such as title. Section 3. An Application entity may have multiple Device-specific Application Builds. Support for more than one Application format. © YouView TV Ltd (2011) Page 164 of 229 .e. Finally. An evolution of device capabilities over time that means not all deployed consumer devices will have the same capabilities. perform a capabilities check on the device and adapt accordingly. filtering of the results returned on the B2C interface to exclude any Applications that are not compatible with the consumer device.4 describes the means to manage this at Application discovery time i. 3.YouView Core Technical Specification 3. This is not covered by this chapter. a Version of a Device-specific Application Build describes a particular version of a Devicespecific Application Build. A Device-specific Application Build refers to a build of an Application for a specific presentation engine.2. description and any parental guidance.e. This level of the model corresponds to an Application that can be installed. Conceptual model Figure 33 shows the conceptual model for Content Provider Applications.3. 2. Applications may also be authored to manage this at run-time i. Device capabilities This specification anticipates: 1. Application discovery Device capability can be used in combination with targeting metadata provided by the MAS to allow the Application gallery to only show Applications that are compatible with the device.YouView Core Technical Specification Note: Though there will be multiple versions of a Device-specific Application Build. 3. there will only be one available for download to the device at any given time. © YouView TV Ltd (2011) Page 165 of 229 .4. Installing Applications on the device Requests to install an Application are made to the LAL. Application verification All Applications are signed and the Local Application Library uses the Verification subcomponent to ensure that an Application has been signed with a valid certificate and is trusted before the Application can be placed in Application storage. The Download subcomponent must respond appropriately to traffic levels on the consumer device‟s IP interface when the viewer is viewing an on-demand IP stream. The LAL retrieves metadata including the download URL for the target Application.1. © YouView TV Ltd (2011) Page 166 of 229 . 4. It can perform multiple download operations in parallel. Storage The device shall provide a means to store the following:    Installed Applications. The Download subcomponent will attempt to start new download requests immediately to ensure that the process of downloading and installing an Application is not unnecessarily delayed by existing download requests. See Chapter IV Consumer Device IP Networking.YouView Core Technical Specification 4. Applications‟ metadata.3.2. The target Application is identified by a Platform-unique Application Record Identifier allocated by the Metadata Aggregation System. Applications‟ private data. 4. This allocation shall be separate from space used for AV media storage and is defined in Chapter VII Consumer Device Storage Management. 4. Application download The Local Application Library uses a Download subcomponent to handle the download process. The Download subcomponent maintains a queue of HTTP downloads which can be paused and resumed. © YouView TV Ltd (2011) Page 167 of 229 . The LAL provides a means by which the Platform Main UI and other software components can determine which Applications are installed. Selecting and launching an Application In the context of downloadable Applications the UIME will only launch Applications that are installed and managed by the LAL. Any request to launch an Application that is not already installed will fail. This could be used to present a list of installed Applications to the viewer.YouView Core Technical Specification 5. Whenever an Application is successfully downloaded and installed the Download subcomponent shall store the ETag and Last-Modified entries from the HTTP Header. the LAL shall check that the URL is still correct by updating the Application metadata to the latest version available.2. Viewer-managed Applications If an update is available for a Viewer-managed Application the external update check process shall inspect the viewer settings to check whether automatic Application update is enabled. the external update check process may request that the LAL acquires the latest version.YouView Core Technical Specification 6. using the new URL. Periodic check for updates An update check process external to the LAL shall periodically request the complete list of installed Applications (including Platform-managed Applications) and for each one requests that the LAL check whether an update is available. 6. The viewer is responsible for triggering the actual update. subject to the type of Application. If the server responds with an HTTP 200 (OK) then there is an update available. 6. Checking for an updated version The LAL is able to use the Download subcomponent to check whether a new version of an Application is available over the ADI. to alert the viewer to the fact that the installed version of a particular Application is out of date. If the Download subcomponent is unable to access the file by following the supplied URL.2. To check for an update the Download subcomponent shall contact the Application Provider‟s server passing the HTTP ETag as part of an If-None-Match HEAD request. Platform-managed Applications If an update is available for a Platform-managed Application the external update check process shall request that the LAL download the latest version.. This value can be set by the viewer through the Platform Main UI and tells the update check whether it should automatically acquire updates to Viewer-managed Applications.   If the server responds with an HTTP 304 (Not Modified) then there is explicitly no update available. If the URL has changed the LAL shall inform the Download subcomponent which shall then run through the update check process defined above. or a Last-Modified as part of an If-ModifiedSince HEAD request. If the automatic Application update is enabled the external update check process shall request that the LAL download the latest version. If the LAL discovers that a new version of an Application is available it will update the metadata stored with the Application to indicate that an update is available. © YouView TV Ltd (2011) Page 168 of 229 . This can be used by the Platform Main UI Application when presenting the list of installed Applications..2. Management and update of installed Applications It is important that devices have the latest version of an Application installed to minimise the legacy version support that content providers need to provide.2. If the automatic Application update is disabled the update check process shall take no further action for that Application.1.1. 6. 6. If an update is available. The install step must be atomic so an attempt to launch an Application during the update process will result in the launch of the existing version.4.YouView Core Technical Specification 6. 6. Update process The LAL will not allow an Application to be installed onto the device until it has been verified (see section 4. Applications and their data will be handled as defined in Chapter VII Consumer Device Storage Management.3. Factory Reset and Application data If the viewer initiates the Factory Reset function or the Clear Private Data function.2). © YouView TV Ltd (2011) Page 169 of 229 . Only at the point of installation is the existing version replaced. A decision by the Platform to remove a Platform-managed Application. 7.1. Whilst an Application is in use it cannot be uninstalled. © YouView TV Ltd (2011) Page 170 of 229 .YouView Core Technical Specification 7. Uninstalling Applications Installed Applications can only be uninstalled by a request to the LAL. Requests to uninstall an installed Application will be made by the Platform Main UI in response to:   An explicit request by the viewer to remove a Viewer-managed Application. Any data the Application has stored on the device. The descriptive metadata. Storage When the Platform Main UI requests that an Application be uninstalled the LAL is responsible for ensuring that the following is removed:    The installed Application. YouView Core Technical Specification Chapter XIII Consumer Device UI Management © YouView TV Ltd (2011) Page 171 of 229 . 1. Audience This chapter is for: Device Manufacturers. and how the shared device resources required by those Applications are managed. This chapter also introduces a logical component – the User Interface Management Engine (UIME). 1. It also describes how devices support the presentation to the user of multiple co-existing Applications.YouView Core Technical Specification 1. who need to:   Understand the concepts presented in relation to User Interface Management and implement the required functionality Integrate the open-source libraries and components specified. of the same or different content types. This chapter is not relevant for: Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 172 of 229 . and describes its features and behaviour. Chapter Summary This chapter defines how devices support more than one presentation technology and hence different types of Applications. Management of the lifecycle of Applications rendered by Application Player instances. An Application Player. A presentable rectangle created by an Application Player to which graphical content can be rendered by an Application. Memory accessible directly by graphics acceleration and graphics display hardware. A Window to which all unconsumed User Input Events are routed. Allocation and policing of Application Player memory and CPU usage limits. Introduction The UIME is a configurable software component which manages the User Interface and exposes UI Management functionality to Applications and other software components. and the makeup of any particular screen presented to the viewer is the result of the composition of one or more stacked windows. An Application hosted by an External Application Player An event raised in response to the user pressing a button on a remote control or keyboard. Management of the Viewer Perceived Operating State of the Consumer Device. which manages its own lifecycle but allows its presentation to managed by the UIME. Management of presentation properties of the multiple graphics surfaces which are created by multiple Application Player instances and drawn to by Applications. Packaged and managed software that provides functionality to consumers. Provision of sufficient configurability of the logic which implements the above. The process of starting an Application Player Instance without requiring it to render an Application until some point in the future.1. Management of appropriate routing of User Input Events where multiple Applications are running concurrently. A set of User Input Events which an Application can respond to whether Active or Inactive. MHEG engine. General purpose memory available to the Application CPU that may be used to hold graphics. 2. Windows are stackable. Examples could be Flash player. The Key functions of the UIME are:        Management of the lifecycle of Application Player Instances. Applications that are managed by the Platform Operator. or otherwise interacting with the system using a control device. to support evolving in-field usage patterns. W3C browser. Definition of terms This chapter introduces a number of specific terms which are set out in the following table: Term Application Player Application Window Explanation Runtime environment for the execution of Applications. Platform UI Applications Externally Started Application Player External Application User Input Event Key Set Grabbed Keys Cold Starting Warm Starting System Memory Video Memory Collector Window © YouView TV Ltd (2011) Page 173 of 229 . A set of User Input Events which an Application can respond to whilst Active.YouView Core Technical Specification 2. The process of starting an Application Player Instance to render an Application at the time the Application needs to be rendered. UIME sub-component responsible for Application state and lifecycle. and for CPU and memory resource management.YouView Core Technical Specification Input Window Active Application Application Manager Application Player Manager Window Manager The single Window associated with an Application which is capable of receiving User Input Events. © YouView TV Ltd (2011) Page 174 of 229 . UIME sub-component responsible for the processes that host Applications. UIME sub-component responsible for composition and rendering of windows for multiple Application Players. The Application which is visibly running in the foreground and whose Input Window is focussed. 2.1. Window Manager The Window Manager component is responsible for tracking which Windows are in existence. Window Manager and UI Manager. and what the associations are between them. The configuration supports optimisation of the UI Management rules for deployment to a range of devices whose graphics processing capabilities differ. what state they are in.1.4. which is not specific to a particular Application instance. 3. Application Manager.1. and render Applications to those Windows. Configuration The behaviour of the Application Manager. UI Manager The UI Manager sub-component provides overall User Interface control functionality. in order to provide direct access to functionality provided by those libraries. 3. 3. which Application Players are hosting them and which Windows they are rendering to. The UIME shall use the Application Player. 3. when an Application Player creates or destroys a Window and when an Application Player starts or stops playing an Application. the Application Player Manager. and what Applications they are hosting.1. It allows new Application Players to be started and existing Application Players to be killed and suspended. Application Player Manager The Application Player Manager component is responsible for tracking which Application Players are in existence. UIME internal architecture The UIME is comprised of 4 logical sub-components. These Application Player instances may be started by or independently of the UIME component.2. The configuration also enables tuning of the logic governing graphics composition and Application lifecycle. Application Players shall be linked against DirectFB and necessary shared system libraries. Application Manager The Application Manager component is responsible for tracking which Applications are in existence.YouView Core Technical Specification 3.1. 3. Application Player Manager and Window Manager can be configured to support a range of user interaction models. to enable evolution in the field as understanding of audience behaviour increases and commercial models change. what the visual properties of those windows are and which Applications those windows are associated with. © YouView TV Ltd (2011) Page 175 of 229 . 3.1. UIME Overview The UIME shall provide support for multiple Application Player instances running concurrently. Application and Window state notifications to track which Application Players. Applications and Windows are in existence. what state they are in. The UIME shall receive notifications when an Application Player process starts or stops. Application Player instances create Windows.3. YouView Core Technical Specification Figure 34 : UIME logical model © YouView TV Ltd (2011) Page 176 of 229 . Applies UIME Policy to the lifecycle of Application Players.1.1. Application Player Manager 4. Playing an Application in a warm-started Application Player results in a faster rendering time because the Application Player initialisation has already taken place. The Application Player Manager shall support the following:   Lifecycle management of Application Players it starts (UIME Started Application Players) Limited lifecycle management of Application Players which are started externally to it (Externally Started Application Players) 4. Application Player instances run in processes external to the UIME. and polices memory and CPU usage of those Application Players. Allows other UIME sub-components to request that new Application Player processes are started. and this is the primary mechanism by which it is able to maintain synchronicity with those external Application Player processes. Allows other UIME sub-components to request that existing Application Player processes are terminated. Starting For UIME Started Application Players. Overview The UIME shall support the starting and stopping of Application Players. UIME Started Application Players 4.YouView Core Technical Specification 4. This allows the Application Player Manager to start. Introduction Application Players are executables which render Applications to Windows. and it is only then necessary for the Application Player to initialise and launch the Application when instructed to do so by the UIME. Application Players are required to render graphics into DirectFB surfaces using DirectFB APIs.2. The Application Player Manager sub-component shall support the concurrent running of multiple Application Players of different types provide the following key functionality:      Allows the UIME to become aware that new Application Player processes have started. The Application Player Manager uses the SaWMan library to access this information.2. and hence Application Players.2.2. © YouView TV Ltd (2011) Page 177 of 229 . Warm starting The Application Player Manager shall support the starting of one or more instances of an Application Player without needing to specify which Application or Applications the started Application Player is required to render. Allows the UIME to become aware that existing Application Player processes have terminated. DirectFB stores display property and process information about its client processes.2. 4. 4.1.2. but not immediately use Application Players. the following 2 launch modes shall be supported. such that they are ready to play Applications when required. The lifecycle of UIME Started Application Players shall be wholly controlled by the UIME. Lifecycle The Application Player Manager shall model the lifecycle of UIME started Application Players as follows: Figure 35 : UIME Started Application Player states 4. 4.2. In this mode. and subsequently remove an Application Player after an Application the Application Player was hosting terminates. memory and other resource © YouView TV Ltd (2011) Page 178 of 229 . the Application Player shall begin rendering the Application as soon as possible after the Application Player has started. Stopping The Application Player Manager shall be responsible for the shutdown and process removal of UIME started Application Players.4.2.2. Cold starting The Application Player Manager shall support the starting of Application Players as a consequence of a request to launch an Application of the corresponding type.YouView Core Technical Specification 4.2. In this way.3. The Application Player Manager may stop.2. Lifecycle The Application Player Manager shall provide a signalling mechanism to indicate to Externally Started Application Players that they are either running or suspended. or when the system resources that the Application Player is consuming are required by higher priority processes.2. Starting The way Externally Started Application Players are started is beyond the scope of this chapter. the UIME will consider requests from the Application Player to Activate Applications it is hosting. © YouView TV Ltd (2011) Page 179 of 229 . nor shall it be responsible for instigating the launching of Applications to be rendered by such Application Players. External Application Players shall use these signals to operate efficiently. and not attempt to render any Application graphics when in SUSPENDED state.3. The Application Player Manager shall not be responsible for starting or stopping Externally Started Application Players. Overview The UIME shall support the display of Applications rendered by Application Players started externally to it. This may typically happen prior to the device entering standby state. 4. 4. The Application Player Manager shall support Externally Started Application Players which are started both before and after the UIME itself starts. Externally Started Application Players 4.YouView Core Technical Specification used by the Application Player can be reclaimed.3.3. the UIME will ignore requests from those Application Players to Activate Applications they are hosting.3. When an Externally Started Application Player is in the RUNNING state. 4. When an Externally Started Application Player is in the SUSPENDED state.1. and ensure that no Application graphics rendered by those Application Players can be displayed.3. Terminating The Application Player Manager shall not be responsible for the shutdown or process removal of External Application Players.4. © YouView TV Ltd (2011) Page 180 of 229 .3.YouView Core Technical Specification The Application Player Manager shall model the lifecycle of Externally Started Application Players as follows: Figure 36 : Externally Started Application Player states 4. Where the Application Manager allows a request to launch an Application.2. Configuration parameters determine how an Application Player executable can be associated with an Application content type.1. whose Window is Focussed.4. or otherwise interact with a control device. Launching The Application Manager shall provide means to launch Applications.2.3. Management of display of Applications. Applications whose launch is initiated by direct clients of the Application Manager. and as such is the primary Application that the user interacts with when they press buttons on the remote control.2. which are launched externally to it (Externally Launched Applications). The UIME‟s Application Manager sub-component manages this by controlling the lifecycle of Applications. it will ensure that an appropriate Application Player is running to play the Application. the Application Manager shall force its Deactivation. The Application ID shall be available to both the launched Application and the launching entity.YouView Core Technical Specification 5. such that it becomes Inactive. Applications whose launch is initiated by other Applications. The Application Manager shall support the following:   Management of lifecycle and display of Applications it launches (UIME Launched Applications). 5. © YouView TV Ltd (2011) Page 181 of 229 . Overview The Application Manager shall support the launching and stopping of Applications. The following Application launch scenarios shall be supported:    Applications whose launch is initiated by the Application Manager. The Application Manager shall ensure that where multiple Applications are running concurrently. 5. Introduction The UIME shall support the concurrent running of multiple Applications. The Active Application is considered Active from the viewers‟ point of view. The lifecycle and display of UIME Launched Applications shall be wholly controlled by the Application Manager. If an Application Player of the necessary type is not already running. if there was a previously Active Application. Activation and Deactivation The Application Manager shall support the concurrent running and display of multiple Applications. 5.2.1. It is the Application running visibly in the foreground. only a maximum of one of those Applications can be „Active‟ at any time. UIME Launched Applications 5. and hence becomes Active. Application Manager 5. the Application Manager shall be capable of denying requests to launch Applications should it consider the launch inappropriate.2. in order that the rule that only one Application can be Active at a time holds. UIME policy shall determine whether to allow or deny Application launch requests and as such. the Application Manager shall cold-start one. When an Application successfully undergoes the process of Activation. passing the URI of the Application to launch to the Application Player. Application IDs The Application Manager shall generate a unique Application ID for each UIME Launched Application at the time that the Application‟s launch is requested.2. 5. and other applications which are not „UIME aware‟. (See Key Sets for the definition of an Application‟s Key set). with the launcher Application remaining Active until such time as the launched Application specifically requests Activation. without requiring that the Platform UI Application becomes Active. the Application needs to be Activated before it can be displayed and receive User Input Events. and that Activation requests for Applications not associated with a focusable Window will be denied. UIME policy shall determine whether to allow or deny Application Activation or Deactivation requests and the Application Manager shall be capable of denying requests to Activate or Deactivate Applications should it consider the state change inappropriate.YouView Core Technical Specification The Application Manager shall ensure that the Active Application will have been previously associated with a focusable Window. the Application Manager shall support other Inactive Applications also running visibly in the background. The Application Manager shall ensure that Windows associated with Inactive Applications shall not be focussed. where the Platform UI Application is displayed on top of it. © YouView TV Ltd (2011) Page 182 of 229 . In this mode. This supports well synchronised transitions between Applications when launching one Application from another. An Application may become the Active Application following:    The successful launch of the Application – if using Immediate Activation A request to Activate the application from another software component A successful Deactivation of another Application – where the Application is the highest priority alternative running Application An Active Application may be Deactivated following :   A request to Deactivate the application from another software component. In this mode. and hence Inactive Applications Shall not be able to receive User Input Events except by the mechanism described in Grabbed Keys.   Immediate Activation. and hence the Active Application shall be able to receive all User Input Events defined in the Application‟s Key Set. which can be deferred until that Application is fully ready to be interacted with. allowing them to be Activated without specifically having to request Activation. without requiring that the Application become Active. the Application‟s window shall be Focussed. This provides support for Native Applications. The Application Manager shall provide the following means of Activating an Application after a successful launch. A successful Activation of another Application. Subsequent to the successful launch of an Application. when an Application is Activated. the newly launched Application shall not be Activated until specifically requested. The Application Manager shall ensure that. Displaying On Top The Application Manager shall provide means to support the display of an Application at the top of the display stack. The Application Manager shall ensure that User Input Events within the Active Application‟s Key Set will be received by the Active Application‟s Window at all times while that Application is Active.   5. and hence be used by the viewer. Deferred Activation. Whilst the Active Application shall always be running visibly in the foreground. the newly launched Application shall be Activated at the point that the Application is associated with a Window and can hence be displayed.5.2. This functionality allows Platform UI Applications to render system level graphics such as the volume bar or mute symbol. and hence not stopping the Active Application from receiving User Input Events within it‟s Key-Set. This functionality is not intended to be generally available to Applications other than Platform UI Applications. 5.6.2.3. The Application Manager shall provide means for Applications to request changes to their Key Sets during their lifecycle. UIME policy shall determine whether to honour Application termination requests. where appropriate. The Application Manager shall apply a default Key Set to each new Application. and this default Key Set shall be defined in the UIME configuration.2.2. The UIME shall fully support the display of Externally Launched Applications. even when the requesting Application is Inactive. the UIME shall notify the Application that termination is imminent prior to actually terminating the Application. but only provide limited support for their lifecycle Management. © YouView TV Ltd (2011) Page 183 of 229 .1. Grabbed Keys The Application Manager shall provide means to allow Applications to define a set of User Input Events which are always routed to the requesting Application before being routed to the Active Application.3. Key Handling 5.YouView Core Technical Specification This functionality is not intended to be generally available to Applications other than Platform UI Applications. Following a transition to the DEVICE_STANDBY power state.2. and as such. Where an Application termination request is successful. 5. the UIME shall be capable of denying requests to terminate Applications should it consider the termination inappropriate. which the Application will receive when the Application is Active.7. Following a request to terminate the process in which the UIME runs.1. Key Sets An Application‟s Key Set defines the set of User Input Events. UIME policy shall determine whether to allow or deny these requests and the Application Manager shall be capable of denying requests to change an Application Key Sets should it consider that doing so is inappropriate. Externally Launched Applications 5. Applications may be terminated under the following circumstances:    Following a request to terminate the Application. which are launched and rendered by Externally Started Application Players. The UIME shall provide a mechanism whereby the imminently terminating Application and. Overview Externally Launched Applications are Applications.7.7. 5. except where the Application has Grabbed Keys.2. Applications will not receive any User Input Events when Inactive. its launching Application are both able to respond to this signal. Termination The Application Manager shall provide means for Applications to request termination of themselves or any running Applications they have launched. 5. 5. The Externally Started Application Player shall add this pre-defined ID as a property of the Window it creates for the purpose of rendering its Applications.3.6. Application IDs The UIME Configuration shall define a unique Application ID for each Externally Launched Application.3. Displaying On Top The UIME shall provide the same support for displaying Externally Launched Applications on top as it does for UIME Launched Applications. © YouView TV Ltd (2011) Page 184 of 229 . 5. 5. 5. The Application Manager shall allow one or more Applications to be configured as Platform UI Applications. The Externally Started Application Player shall use this ID for the purpose of identifying the Application.7. Activation and Deactivation By default the Application Manager shall not Activate any Externally Launched Applications. and hence require that their Application Player request their Activation through the Application Manager subsequent to launch. priority use of CPU and RAM and increased access to system resources. Launching Externally started Application Players shall be responsible for managing the launching of the Applications which they render. It follows that the UIME shall not be responsible for the launching of Applications rendered by Externally Started Application Players. The Application Manager shall be responsible for monitoring the state of the Platform UI Applications.3.3. The Application Manager shall provide the same support for the Activation and Deactivation of Externally Launched Applications as it does for Activation and Deactivation of UIME Launched Applications. Typically Platform UI Applications will be configured to allow them priority access to User Input Events. restarting them if they terminate unexpectedly. such that the UIME is able to identify the newly created Window as being associated with a known Application at the time of Window creation.4. and has sufficient RAM and CPU available to it to perform core device operations in a responsive manner.3. in the same way that UIME Launched Applications can. Key Handling The Application Manager shall provide the same support for key handling for Externally Launched Applications as it does for UIME Launched Applications.YouView Core Technical Specification 5. 5.4. 5. It follows that the Application Manager shall not be responsible for the termination of Applications rendered by Externally Started Application Players. The UIME shall provide an operating mode which shall ensure that a functioning Platform UI Application is always running. Platform UI Applications Platform UI Applications shall be configurable separately to other classes of Application.2.3. Externally Launched Application Players shall be able to manipulate the set of User Input Events that their Applications will receive. Externally Launched Applications shall use the Deferred Activation model.5. All Platform UI Applications shall be UIME Launched Applications.3. Terminating Externally Launched Application Players shall be responsible for managing the termination of the Applications which they render. Introduction The Window Manager UIME sub-component shall provide the following key functionality:        Allows the UIME to become aware that new Windows have been created both in and out of process. Window lifecycle Application Players shall create Windows for the purpose of rendering their Application graphics to.YouView Core Technical Specification 6.1. The UIME shall support Application Players that create Windows either before or after they know which specific Application will be rendered to the Window. Allows the UIME to become aware that stacking or display properties of existing Windows have changed.1. Allows the UIME to become aware that existing Windows have been removed and destroyed. Allows other UIME sub-components to request that the stacking and display properties of existing Windows are changed. Applies UIME Policy to the stacking and display properties of existing Windows. 6. the Window Manager shall only support the display of the first Window.2. The Window Manager shall not support Multiple Applications or Application Players being associated with a single Window. when the Application Player is subsequently instructed by the UIME to render an Application. © YouView TV Ltd (2011) Page 185 of 229 . The Window Manager shall have the ability to modify the properties of any Window created by an Application Player. The Window Manager shall use the SaWMan property change notification mechanism to allow it to associate each Window with the Application Player that created it. and use such notifications to maintain a list of existing windows. The Window Manager shall only support multiple Windows being created by and associated with a single Application Player. When a cold-starting Application Player starts. 6. Allows other UIME sub-components to discover the current stacking and display properties of existing Windows. In the case that a warm-starting Application Player starts and reaches the INITIALISED state without creating a Window. The Window Manager shall be notified when an Application Player attempts to set or change the Application ID property of any Window it has created. Where an Application attempts to create multiple windows. The Window Manager shall be notified when any new Window is created by an Application Player. The Window Manager shall support a single Window being associated with a single Application. Provides the underlying mechanisms to the Application Manager to allow it to control Application Display properties and User Input Event routing. Window Manager 6. the Application Player should then create a Window with dimensions appropriate to the authored Application content dimensions. it shall create a Window with dimensions appropriate to the Application it is required to render.2. and have the ability to allow or deny any attempt by an Application Player to modify the properties of any of the Windows it created. Embedded Application ID for External Application Players External Application Players must set an Application ID property on all Windows they create. where those Windows are each created with reserved Application IDs. 2.YouView Core Technical Specification The Window Manager shall support Externally Started Application Players that create and destroy a Window to render each Application.2. and Externally Started Applications Players that re-use a single Window. UIME Key Filtering The UIME shall have the ability to receive all User Input Events.3. preventing other Applications from receiving them. The Window shall be used by the Application Player both for the purposes of rendering Application graphics and handling User Input.3. This allows the Platform Main UI Application to receive User Input Events that would result in its state changing from Inactive to Active (e. The Window Manager shall provide the underlying mechanism that allows the Application Manager to maintain the set of Grabbed Keys applicable to each Application. Window Key Set A Window‟s Key Set defines the set of User Input Events which the Window will be capable of receiving when the Window is focussed. or propagating the events to Applications. 6. 6. and not already consumed by the focussed Window.1.3.3. 6. The Window Manager shall provide the underlying mechanism that allows the Application Manager to apply a default Key Set to each Application. User Input Event dispatch 6. 6.3. The UIME shall have the ability to consume these User Input Events. Input Windows Each Application can be associated with a single Window. The Window Manager shall ensure that the Window associated with the Platform Main UI Application shall be designated the Collector Window. so that it receives all user input not consumed by the UIME itself. prior to them being routed to Applications or elsewhere.4. or any other focussed Application. Collector Window The Collector Window shall receive all User Input Events not already Grabbed and consumed by a Window. Grabbed Keys A Window‟s Grabbed Key list defines the set of User Input Events that the Window will be capable of receiving whether or not it is focussed or visible. The Window Manager shall enable one and only one Window in the stack to be the Collector Window.2. MENU / GUIDE keys) without having to specifically Grab them.g. © YouView TV Ltd (2011) Page 186 of 229 .3. 6. YouView Core Technical Specification Figure 37 : User Input Event Routing 6. supporting a range of usage scenarios including:   The capability to dull. or low-light the Windows of Inactive Applications The capability to resize and reposition Windows to support widget-like Application minimisation © YouView TV Ltd (2011) Page 187 of 229 . The Window Manager shall provide other UIME sub components with the capability to modify the visual display properties of Windows.4. Window Property Manipulation The UIME shall support a range of use cases involving Application co-existence. such that the Application will continue rendering to the Window. oblivious to the change in geometry. Colorization The Window Manager shall be capable of modifying the colorization of any Window created. such that those Applications will continue rendering to the Window. Figure 38 : Source Geometry Transformation 6. without affecting the Application or Application Player associated with the modified Window.3. the Window Manager shall ensure that. oblivious to the property change. Geometry Application Players should create windows of a size appropriate to the authored content dimensions of the Application they are required to play. © YouView TV Ltd (2011) Page 188 of 229 . As a performance optimisation. then the Window‟s surface will no longer be composed with the surfaces of other.1. 6.4. 6.2. Destination geometry transformation The Window Manager shall allow the specification of a rectangle to which the entire Window can be scaled (the Destination Rectangle). 6.4.4.4.3.YouView Core Technical Specification  The capability to apply source and destination transformations to support both the provision of magnification functionality to enable accessibility features. oblivious to the change. if a Window‟s opacity is changed such that it becomes completely transparent.4. such that the Application will continue rendering to the Window.2. Opacity The Window Manager shall be capable of modifying the opacity property of any Window created. without affecting the Application or Application Player associated with the modified Window.1. Source geometry transformation The Window Manager shall allow the specification of a sub rectangle of any Window (the Source Rectangle). The Window Manager shall be capable of modifying the source and destination geometry of any windows created. without affecting the Application or Application Player associated with the modified Window. visible windows in the final composition buffer. 6.3. which can then be scaled to the Window‟s original dimensions as followed. and the optimisation of Application display for different output screen resolutions. Figure 40 : Concurrent Application of Source and Destination Geometry Transformations 6. Position and size The Window Manager shall be capable of modifying the size and position of any Window. © YouView TV Ltd (2011) Page 189 of 229 .4.4. such that the source rectangle can be stretched to fill the destination rectangle. such that those Applications will continue rendering to the Window. Combination of Source and Destination geometry transformations The Window Manager shall support the concurrent application of both the Source and Destination Geometry Transformations to any Window. oblivious to the change. without affecting the Application or Application Player associated with the modified Window.YouView Core Technical Specification Figure 39 : Destination Geometry Transformation 6.3.4.3. and hence the transition of the perceived state of the Device. © YouView TV Ltd (2011) Page 190 of 229 . Viewer Perceived Device State Whilst the UIME is running. which is not specific to a particular Application instance. The device architecture intentionally separates the concepts of the actual device state and viewer perceived device. 7. it shall control the „viewer perceived‟ operating state of the device. The UI Manager shall provide means to change the Viewer Perceived Operating State.1. Introduction The UI Manager sub-component provides overall User Interface control functionality.YouView Core Technical Specification 7. UIME policy shall determine whether requests to change the Viewer Perceived Operating State are allowed or denied. UI Manager 7.2. For example. or that it should always be hidden on deactivation. 8. The Window to which Collector status is assigned. Configuration The UIME shall support the configuration of the behaviour of aspects of its constituent components. Application Manager configuration The Application Manager configuration shall provide configurability of aspects including:     The default Key Set associated with different types of Application.1. The presentation of Applications for screens of different resolutions. namely the Application Player Manager. The activation and deactivation behaviour for different types of Application. wish to specify that it is launched with a reduced Key Set. The magnification behaviour for different types of Application. 8.4. Application Policy The UIME shall implement configurable Application Policy which allows the behaviour of different types of Applications to be configured and modified. © YouView TV Ltd (2011) Page 191 of 229 . Application Manager and Window Manager.YouView Core Technical Specification 8.2. The policy on the use of Warm Started Application Players. CPU and memory usage limits applied when hosted Applications are Active / Inactive. 8. Window Manager configuration The Window Manager shall provide configurability of aspects including:   The stacking priority of Windows associated with different types of Application. for optimal performance. an individual Application may. 8.3. Application Player Manager configuration The Application Player Manager configuration shall provide configurability of aspects including:    The association of Application content type to Application Player executable. Resource Management 9. and any interim surfaces used to make up the composition of those Window surfaces in System and Video memory. Management of available CPU The UIME shall monitor the relative CPU usage of each running Application Player.2. and dynamically change the CPU usage limits of running Application Players as appropriate. The UIME shall have the capability to limit the relative CPU usage limit for each Application Player. The UIME shall be capable of notifying Applications and Application Players of memory usage. and subsequent termination of the associated Application Player Instructing an Application Player to terminate any number of its Applications. Watchdog functions The UIME shall periodically monitor running Application Player processes to ensure the Applications they host remain responsive to User Input Events and system control signals. The UIME shall provide support to allow an Application Player‟s System and Video Memory limits to be modified during the lifecycle of the Application Player Instance. and the amount used by each Application Player. whilst also providing sufficient CPU resource to Platform UI Applications. the following remedial options shall be supported:    Denial of Window creation. the UIME shall have the capability to kill those processes. the UIME shall ensure there is sufficient Video Memory available for Window creation. The UIME shall ensure that the Application Player hosting the Active Application is allocated sufficient CPU resource to keep the Active Application performant and responsive to User Input Events. 9. The UIME shall be capable of terminating. 9. or suspending any Application Player that exceeds the configured memory allocation limit.1. in order to free sufficient memory to allow the new Application Player to render its Application Termination of another Application Player.3.  The UIME shall periodically check for the presence of a Platform UI Application and support a runtime configuration such that in the event that a Platform UI Application terminates unexpectedly. Management of available memory Application Players store the pixel information of their Window surfaces. freeing sufficient memory to allow the new Application Player to render its Application The UIME shall support the configuration of System and Video Memory allocation limits which can be applied separately to each Application Player Instance. In the case where an Application has become unresponsive to User Input Events or control signals. and sufficient headroom in memory availability to allow the Application which will write to the new Window to create sufficient interim graphics buffers from which the Window surface will be composed. and reclaim any memory resources they were using.YouView Core Technical Specification 9. and respond to Collected User Input Events while Inactive. The UIME shall monitor the amount of System and Video Memory available. such that they can continue to perform background system functions reliably. © YouView TV Ltd (2011) Page 192 of 229 . Where the UIME determines that the memory availability is insufficient. the UIME is able to restart it. Where an Application Player attempts to create a new Window. YouView Core Technical Specification © YouView TV Ltd (2011) Page 193 of 229 . . YouView Core Technical Specification Chapter XIV Presentation Engine Integration © YouView TV Ltd (2011) Page 195 of 229 . 1.1. Chapter audience This chapter is for: Device Manufacturers.YouView Core Technical Specification 1. Chapter Summary This chapter specifies how to integrate presentation engines into the wider software architecture for YouView devices. who need to:   Implement the specified functionality Integrate presentation engines in the manner described This chapter is not relevant for: Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 196 of 229 . Operating System Integration Presentation engines shall be implemented so that they can run as a user other than the „root‟ user. this shall be done using a Linux „group‟. Any shared library specified in Chapter II Consumer Device Platform that is needed by the presentation engine shall be dynamically linked. © YouView TV Ltd (2011) Page 197 of 229 . This does not preclude other libraries being statically linked. this may be appropriate if the libraries are not required by any other component on the device. If some privileges are required. Implementations must keep any privileges to an absolute minimum.YouView Core Technical Specification 2. It must not be possible for the presentation engine to access system memory or areas of the file system that are not directly associated with the implementation. The sequence diagram shows this happening in a separate Flip() call with a NULL region. Note: for performance reasons. The sequence diagram below shows the way in which the presentation engine must use the DirectFB APIs when redrawing its window. Before making any changes.YouView Core Technical Specification 3. Use of the DSFLIP_QUEUE and DSFLIP_FLUSH flags is not required if only one rectangular region needs to be updated to create a particular output frame. presentation engines must call IDirectFBWindow::BeginUpdates() so that window composition is synchronised in cases where multiple windows (possibly from separate processes) are being updated at the same time. Graphics Acceleration 3. these flags can be included in the Flip() call of the final window update. However. where a platform has OpenGL ES support. Alternatively. DirectFB must be notified using the DSFLIP_FLUSH flag and the screen composition lock released using DSFLIP_ONCE. So that the window stack can be composed efficiently. Notification of changed regions shall be provided. for integration with the wider graphics architecture. The presentation engine shall create a window sized according to the authored dimensions of the application (where this is defined). performance may be improved by using this for rendering. The presentation engine shall not manipulate any DisplayLayer directly.1. except where the number of changed regions would become excessive. it is desirable that the regions notified as having been updated are as small as possible covering only areas that have changed. For example. ARGB pixel format shall be used. The presentation engine shall notify the graphics subsystem before and after any update to the DirectFB window surface. DirectFB integration Presentation engines shall create a DirectFB Window to render graphics. © YouView TV Ltd (2011) Page 198 of 229 . window updates to non-overlapping regions must be made with separate calls to IDirectFBWindow::Flip using the DSFLIP_QUEUE flag. subject to a maximum size specified when the presentation engine is launched. When a complete frame of updates has been made. Rendering of graphics into the DirectFB window need not use only the specified DirectFB APIs if other approaches achieve greater performance. The Window shall be configured with the DSCAPS_PREMULTIPLIED surface capability. window updates must be notified using the specified DirectFB APIs. YouView Core Technical Specification Figure 41 3. Graphics operation Clearing of screen areas where required for rerendering Basic bitmap rendering DirectFB mapping FillRectangle with DSDRAW_NOFX. However. Scaled bitmap rendering 9 Where a bitmap is known to be fully opaque. Bitmap rendering The presentation engine shall provide hardware acceleration for the graphics operations defined below using the DirectFB mechanisms specified. DSBLIT_BLEND_ALPHACHANNEL may be omitted to improve performance. © YouView TV Ltd (2011) Page 199 of 229 . Blit from ARGB using DSBLIT_BLEND_ALPHACHANNEL9 DSBLIT_SRC_PREMULTIPLY shall also be set if the source pixel data is not in pre-multiplied form. DirectFB implementations are not required to be able to ignore an alpha channel when rendering ARGB bitmaps so the alpha values in the source surface must still be correct. StretchBlit from ARGB using 9 DSBLIT_BLEND_ALPHACHANNEL DSBLIT_SRC_PREMULTIPLY shall also be set if the source pixel data is not in pre-multiplied form.2. Table 36 : Graphics operation mappings In all cases. © YouView TV Ltd (2011) Page 200 of 229 . Bitmap rendering with a colour transform where one or more colour components and the alpha value are multiplied by factors between 0. Bitmap rendering with a colour transform where one or more colour components are multiplied by factors between 0.YouView Core Technical Specification Graphics operation Bitmap rendering with a colour transform where the colour components are unaffected but the alpha value is multiplied by a factor between 0. 3. Blit/StretchBlit using DSBLIT_BLEND_ALPHACHANNEL and DSBLIT_BLEND_COLORIZE with the red. DirectFB mapping Blit/StretchBlit using DSBLIT_BLEND_ALPHACHANNEL and DSBLIT_BLEND_COLORALPHA with alpha=alphaMultiplier * 255 DSBLIT_SRC_PREMULTIPLY shall also be set if the source pixel data is not in pre-multiplied form. green and blue colours set according to colour=colourMultiplier * 255 DSBLIT_SRC_PREMULTIPLY shall also be set if the source pixel data is not in pre-multiplied form. the blending mode shall be DSPD_SRC_OVER (srcBlend: DSBF_ONE.1. Implementations may optionally implement a two-pass rendering of these cases using DirectFB to improve performance. Blit/StretchBlit using DSBLIT_BLEND_ALPHACHANNEL.0 and 1. DSBLIT_SRC_PREMULTCOLOR shall be set otherwise. or has a colour transform applied that has a DirectFB mapping listed in section 3. Mapping to DirectFB not required.0 inclusive. DSBLIT_BLEND_COLORALPHA and DSBLIT_BLEND_COLORIZE with the alpha. the bitmap shall be rendered to the screen in the same way as a normal bitmap would be. red. the presentation engine should behave as follows: Cached bitmaps should not be re-created if the object is moved.0 inclusive. dstBlend: DSBF_INVSRCALPHA). In these cases.0 and 1.0 inclusive and the alpha value is unaffected. green and blue values set according to alpha=alphaMultiplier * 255 colour=colourMultiplier * 255 DSBLIT_SRC_PREMULTIPLY shall also be set if the source pixel data is not in pre-multiplied form.0 and 1. Cached bitmaps should additionally be retained when the object is scaled between to between 60% and 100% of its cached size. the bitmap being rendered with a StretchBlit operation.3. Caching of rendered graphics Where a presentation engine includes means by which vector graphics can be retained in a cached bitmap representation. Bitmap rendering with a colour transform which includes any offset value or which has negative coefficients. DSBLIT_SRC_PREMULTCOLOR shall be set otherwise. 4. Presentation of A/V in the primary mode shall be perfect with no dropped frames or other artefacts introduced during decoding. However. 4.3. devices shall support 25 fps video without dropping more than one frame per second. devices are not required to support primary mode presentation of A/V from a presentation engine at the same time as presenting A/V media on the main video plane outside of the presentation engine. 4. Presentation If a presentation engine supports full screen video. for example by dropping frames. Multichannel audio shall also be supported in this case. devices shall support all video resolutions up to the maximum HD resolution and frame rate required by Chapter II Consumer Device Platform. Only one media session can use the primary mode at any time. © YouView TV Ltd (2011) Page 201 of 229 . the presentation engine shall integrate with the hardware-accelerated decoders for that codec.2. In addition. Where multiple window mode video sessions are active.3. the presentation engine shall additionally support the requirements of „window mode‟ presentation as described in section 4. devices shall support video resolutions up to 720x576. Primary mode When using the primary mode for A/V presentation from a presentation engine. devices are only required to support two channels.2. Requirements for mixing presentation engine audio with other sources of audio are described in Chapter II Consumer Device Platform. Audio and Video 4. Window mode video shall be displayed so that it appears immediately behind the graphics plane window in which the application is running. Support for codecs not listed in Chapter II Consumer Device Platform is optional. Display composition Primary video is always presented behind the graphics plane. Where a presentation engine supports a codec required by Chapter II Consumer Device Platform.1.2.2. If a presentation engine supports presentation of more than one video stream concurrently. 4. Audio only content When presenting audio only content from a presentation engine.2. Window mode When using the window mode for A/V presentation from a presentation engine.YouView Core Technical Specification 4. the video presentation may degrade. it shall provide the capability to present the video in „primary mode‟ as described in section 4. Where the video resolution is 360x288 or less. it shall be presented as described in section 4. More than one media session can use the window mode. 4.2.1. the most recently created one will be on top.1. provided that no other graphics plane updates are taking place. Overview Some presentation engines have the capability to present audio and video.2.2. Because of this. If a presentation engine supports audio-only content.3.2. window mode video will always appear on top of primary mode (or external) video. Performance may degrade further where more than one is active. Audio associated with window mode presentation is only required to support two channels. 4. or it may use an additional video or graphics plane where the hardware has a suitable plane available. YouView devices support media playback using other means. Resource management As well as supporting playback of A/V content using presentation-engine specific mechanisms. the presentation engine shall support positioning and rectangular masking of the video frame.YouView Core Technical Specification Window mode may be implemented using a DirectFB window to compose the window onto the main graphics plane.4. © YouView TV Ltd (2011) Page 202 of 229 . For both the primary and window modes of presentation. All positions shall be interpreted as relative to the application‟s co-ordinate system. Implementations shall co-ordinate access of presentation engines and other components to hardware A/V decoders as required by Chapter II Consumer Device Platform. symbols with a cross in the „K‟ column are those produced by a USB keyboard or a remote control with alphanumeric keyboard.YouView Core Technical Specification 5. However. DirectFB key symbols DIKS_POWER DIKS_POWER2 DIKS_SMALL_P DIKS_CAPITAL_P DIKS_ESCAPE DIKS_GOTO DIKS_MENU DIKS_EPG DIKS_SMALL_E DIKS_MUTE DIKS_HELP DIKS_CURSOR_UP DIKS_CURSOR_DOWN DIKS_CURSOR_LEFT DIKS_CURSOR_RIGHT DIKS_OK DIKS_ENTER X X X X X X X X X X X X X X X X X X X ALT modifier set R X X K Conditions Key function Standby: toggle Standby: power on Notes X X X X X ALT modifier set ALT modifier set Standby: toggle Standby: power on Close Search Menu Guide Guide Mute Help Up Down Left Right OK/Enter OK/Enter DIKS_RETURN and DIKS_ENTER are the same code DIKS_BACK DIKS_SMALL_K DIKS_VOLUME_UP DIKS_VOLUME_DOWN DIKS_CHANNEL_UP DIKS_PAGE_UP DIKS_CHANNEL_DOWN DIKS_PAGE_DOWN DIKS_TEXT DIKS_SMALL_T DIKS_INFO DIKS_SMALL_I DIKS_ZOOM DIKS_SMALL_Z DIKS_REWIND DIKS_FASTFORWARD X X X X X X X X X X X X X X X X ALT modifier set ALT modifier set ALT modifier set X X ALT modifier set Back Back Volume up Volume down Channel up Channel up Channel down Channel down Text Text Info Info Zoom Zoom Rewind Fast forward © YouView TV Ltd (2011) Page 203 of 229 . it is important that all applications can be controlled both from the device‟s standard input device and from keyboards or other accessories. Note that some key mappings are conditional on the state of the ALT key modifier. Different presentation engines will have different requirements for key events. Key symbols with a cross in the „R‟ column are those that may be found on a standard remote control. User Input User input events for all presentation engines are handled through DirectFB. Chapter II Consumer Device Platform defines the way in which specific key events are mapped into the DirectFB system. In many cases. there is more than one DirectFB key code that the presentation engine must recognise for a particular key function. Presentation engines receive Window events for key presses via the standard DirectFB event handling mechanisms. The following table lists the DirectFB key codes that need to be mapped to the presentation engine‟s internal representation for particular key functions. Audio description DIKS_AUDIO DIKS_SMALL_A DIKS_SUBTITLE DIKS_SMALL_S DIKS_F1 … DIKS_F9 DIKS_CUSTOM0 … DIKS_CUSTOM9 DIKS_F1 … DIKS_F9 DIKS_CAPITAL_A … DIKS_CAPITAL_Z DIKS_SMALL_A … DIKS_SMALL_Z DIKS_SPACE DIKS_PARENTHESIS_RIGHT DIKS_EXCLAMATION_MARK DIKS_AT DIKS_NUMBER_SIGN DIKS_DOLLAR_SIGN DIKS_PERCENT_SIGN DIKS_CIRCUMFLEX_ACCENT DIKS_AMPERSAND X X X X X X ALT modifier set ALT modifier not set ALT modifier set Dual function: also „shift‟ Audio description Subtitle Subtitle Defined optional keys Dual function: also „delete‟ X Manufacturer extensions X X X X X X X X X X X X ALT modifier set ALT modifier not set ALT modifier not set ALT modifier not set Manufacturer extensions A to Z a to z Space „)‟ „!‟ „@‟ „#‟ „$‟ „%‟ „^‟ „&‟ Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported © YouView TV Ltd (2011) Page 204 of 229 .e.YouView Core Technical Specification DirectFB key symbols DIKS_STOP DIKS_RECORD DIKS_PLAY DIKS_PAUSE DIKS_NEXT DIKS_PREVIOUS DIKS_4 DIKS_6 DIKS_2 DIKS_3 DIKS_5 DIKS_1 DIKS_9 DIKS_7 DIKS_RED DIKS_GREEN DIKS_YELLOW DIKS_BLUE DIKS_SMALL_R DIKS_SMALL_G DIKS_SMALL_Y DIKS_SMALL_B DIKS_0 … DIKS_9 R X X X X X X K Conditions Key function Stop Record Play Pause Skip forward Skip backward Notes X X X X X X X X X X X X X X X X X X Key identifier is in range DIKI_KP_0 … DIKI_KP_9 and ALT modifier set Rewind Fast forward Stop Record Play Pause Skip forward Skip backward Red Green Yellow Blue ALT modifier set Red Green Yellow Blue Key identifier is in range DIKI_KP_0 … DIKI_KP_9 and ALT modifier not set Key identifier is in range DIKI_0 … DIKI_9 (i.e. main keyboard variants) 0 to 9 Remote control keypad and emulation Direct number key entry (i. do not apply multitap processing) DIKS_0 … DIKS_9 X 0 to 9 – alternative mappings to be included if the presentation engine can support two sets. ‟ „_„ Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Key identifier is DIKI_MINUS_SIGN and ALT modifier not set Key identifier is DIKI_KP_MINUS and ALT modifier not set ALT modifier not set Key identifier is DIKI_PERIOD and ALT modifier not set Key identifier is DIKI_KP_DECIMAL and ALT modifier not set ALT modifier not set Key identifier is DIKI_SLASH and ALT modifier not set Key identifier is DIKI_KP_DIV and ALT modifier not set ALT modifier not set „–„ „–„ „>‟ „.‟ „?‟ „/‟ „/‟ „~‟ „`‟ „{‟ „[‟ „|‟ „\‟ „}‟ „]‟ „”‟ „‟‟ Backspace Tab Delete Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Table 37 : Key mappings © YouView TV Ltd (2011) Page 205 of 229 .YouView Core Technical Specification DirectFB key symbols DIKS_ASTERISK DIKS_ASTERISK DIKS_PARENTHESIS_LEFT DIKS_COLON DIKS_SEMICOLON DIKS_PLUS_SIGN DIKS_PLUS_SIGN DIKS_EQUALS_SIGN DIKS_LESS_THAN_SIGN DIKS_COMMA DIKS_UNDERSCORE DIKS_MINUS_SIGN DIKS_MINUS_SIGN DIKS_GREATER_THAN_SIGN DIKS_PERIOD DIKS_PERIOD DIKS_QUESTION_MARK DIKS_SLASH DIKS_SLASH DIKS_TILDE DIKS_GRAVE_ACCENT DIKS_CURLY_BRACKET_LEFT DIKS_SQUARE_BRACKET_LEFT DIKS_VERTICAL_BAR DIKS_BACKSLASH DIKS_CURLY_BRACKET_RIGHT DIKS_SQUARE_BRACKET_RIGHT DIKS_QUOTATION DIKS_APOSTROPHE DIKS_BACKSPACE DIKS_TAB DIKS_DELETE R K X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Conditions Key identifier is DIKI_8 and ALT modifier not set Key identifier is DIKI_KP_MULT and ALT modifier not set ALT modifier not set Key function „*‟ „*‟ „(‟ „:‟ „.‟ „.‟ Notes Where alphabetic entry supported Where alphabetic entry supported Where alphabetic entry supported Key identifier is DIKI_EQUALS_SIGN and ALT modifier not set Key identifier is DIKI_KP_PLUS and ALT modifier not set ALT modifier not set „+‟ „+‟ „=‟ „<‟ „. © YouView TV Ltd (2011) Page 206 of 229 . Fonts Presentation engines shall include support for rendering fonts through the DirectFB FontProvider mechanism. The set of fonts shall include the “FS Me” family of fonts in Light.YouView Core Technical Specification 6. Regular Bold and Heavy weights. each in normal and italic variants. example. Implementations shall use such interfaces and mechanisms necessary to protect the confidentiality of keys. The header is formally defined as follows: X-YouView-Appid appid-value appid appchar Examples: x-youview-appid: dev:com. Caching shall be enabled for HTTP requests made by the presentation engine. The header shall not be included in HTTP requests that are not carried over a secure TLS connection.LivePlayerApp The presentation engine shall not allow applications to set headers with header field names that begin with the string x-youview. As HTTP header field names are case insensitive. = "x-youview-appid" ":" appid-value = ( "dev" | "youview" ) ":" appid = 1*212appchar = ALPHA | DIGIT | ". Use of HTTP proxies shall be supported. The presentation engine shall add an x-youview-appid extension header field to all HTTP requests made over TLS using the presentation engine‟s normal HTTP request APIs.example. The presentation engine shall support client authentication for HTTP requests. Networking Presentation engines shall support HTTP and HTTPS (HTTP over TLS) connections using the libcurl shared library required by Chapter II Consumer Device Platform. Applications shall not have access to the cookies of other applications. The presentation engine shall support the use of the platform-specified bundle of HTTPS root certificates for server authentication." | "-" © YouView TV Ltd (2011) Page 207 of 229 . prefixed by a field indicating whether the application was signed by a developer or was signed for deployment. Presentation engines shall maintain a separate store of persistent cookies for each application. The presentation engine shall provide a mechanism for other software to be aware of the TLS connection state during the establishment of a secure connection and based on this information. The x-youview-appid header consists of the fully-qualified application ID for the application that made the request.HelloWorld x-youview-appid: youview:com. a case insensitive comparison must be used to ensure this. to determine whether the connection should be allowed to be established.YouView Core Technical Specification 7. . YouView Core Technical Specification Chapter XV MHEG Integration © YouView TV Ltd (2011) Page 209 of 229 . 1. Unless otherwise stated. MHEG is tightly integrated with broadcast functionality and is an existing well-established technology on set top box devices.YouView Core Technical Specification 1. all the requirements of Chapter XIV Presentation Engine Integration also apply to MHEG. See also Chapter VIII Broadcast Content Delivery. Chapter Summary Chapter XIV Presentation Engine Integration defines the way in which presentation engines must be integrated for YouView devices. who need to:   Implement the specified functionality Integrate the MHEG presentation engine in the manner described This chapter is not relevant for: Application Developers ISPs Content Providers © YouView TV Ltd (2011) Page 210 of 229 . This chapter covers only integration aspects for MHEG. 1. Chapter audience This chapter is for: Device Manufacturers. This chapter describes how the integration requirements for the MHEG engine differ from those for other presentation engines. 2. Note: MHEG does not require colour transforms. The MHEG engine shall set the ApplicationID of its DirectFB Window to 0x80000001 using the IDirectFBWindow::SetApplicationID() DirectFB API. The MHEG built-in font shall map to the Tiresias font “rec://font/uk1” as defined by DTG D-Book 7 Part A v1 and shall also be supported in plain and square variants. DirectFB integration The generic DirectFB integration requirements described in Chapter XIV Presentation Engine Integration apply with the following exceptions and additions: ARGB4444 pixel format shall be used.YouView Core Technical Specification 2. © YouView TV Ltd (2011) Page 211 of 229 . The following mapping shall be used between the graphics classes provided by MHEG and DirectFB: MHEG class Bitmap Rectangle DynamicLineArt Text.1) shall be implemented perfectly. When no such rectangle exists (i. Support for additional built-in fonts is not required. plus other surfaces requiring up to a maximum of 10 Mbytes of video memory. The MHEG engine may create at most one additional intermediate surface of the same size to implement LockScreen. Note: the MHEG engine must perform logical text width calculations and text layout according to the defined rules of the DTG D-Book.2. Graphics Acceleration 2. HyperText and EntryField Video Slider DirectFB mapping Blit() or StretchBlit() with clipping 4 x FillRectangle() for any border and 1 x FillRectangle() for interior. This information allows for optimised composition of the MHEG engine‟s output with other graphics. FillRectangle() for background and any borders.4. Graphics rendering The MHEG engine shall use hardware acceleration for the graphics operations as described in Chapter XIV Presentation Engine Integration. the DirectFB Window shall be hidden by setting its opacity to zero. 2.e. The MHEG engine shall create a 1280x720 pixel window. text rendering via DrawString() FillRectangle() with full transparency FillRectangle() Table 38 : Graphics operation mappings 2. Font rendering shall be handled through the DirectFB FontProvider mechanism. MHEG engine renders to an intermediate surface at the graphics plane resolution which is then displayed using Blit(). Font rendering The MHEG engine shall support DownloadableFontExtension.3. Overlapping visibles (as described in DTG D-Book 7 Part A v1 section 14.4. the MHEG graphics plane is empty). Graphics plane state The MHEG engine shall maintain information about the smallest rectangle of its graphics plane which contains all the pixels that are not fully transparent.1. YouView Core Technical Specification 3. section 16. the channel presented by the receiver‟s UI.e.9. © YouView TV Ltd (2011) Page 212 of 229 . as described in DTG D-Book 7 Part A v1.2. Note: because of the difference between quiet and normal tunes. Channel Tuning The MHEG engine shall support the LifecycleExtension. the receiver‟s currently selected channel may not be the same as the “viewer service context” i. User Input 4. In some cases. DirectFB key symbols DIKS_CURSOR_UP DIKS_CURSOR_DOWN DIKS_CURSOR_LEFT DIKS_CURSOR_RIGHT DIKS_OK DIKS_ENTER.1. multiple key symbols are mapped to the same MHEG key to ensure that all device functions are available from USB key events as well as remote control key events. DIKS_RETURN DIKS_BACK DIKS_SMALL_K DIKS_TEXT DIKS_SMALL_T DIKS_REWIND DIKS_FASTFORWARD DIKS_STOP DIKS_PLAY DIKS_PAUSE DIKS_PLAYPAUSE DIKS_NEXT DIKS_PREVIOUS DIKS_4 DIKS_6 DIKS_2 DIKS_5 DIKS_1 DIKS_3 DIKS_9 DIKS_7 DIKS_RED DIKS_GREEN DIKS_YELLOW DIKS_BLUE X X X X X X X X X X X X X X X X X X X X Key identifier is in range DIKI_KP_0 … DIKI_KP_9 and ALT modifier set X X ALT modifier set X X ALT modifier set R X X X X X X K X X X X Conditions MHEG UserInput value Up (1) Down (2) Left (3) Right (4) Select (15) Select (15) Cancel (16) Cancel (16) Text (104) Text (104) Rewind (126) Fast Forward (125) Stop (120) Play (121) Pause (122) Play/Pause (127) Skip Forward (123) Skip Back (124) Rewind (126) Fast Forward (125) Stop (120) Play (121) Pause (122) Play/Pause (127) Skip Forward (123) Skip Back (124) Red (100) Green (101) Yellow (102) Blue (103) © YouView TV Ltd (2011) Page 213 of 229 . DirectFB to MHEG key mappings The table below defines the required mappings between DirectFB key events and MHEG UserInputEventTag values based on the requirements of Chapter XIV Presentation Engine Integration. symbols with a cross in the „K‟ column are those produced by a USB keyboard or a remote control with alphanumeric keyboard. Key symbols with a cross in the „R‟ column are those that may be found on a standard remote control.YouView Core Technical Specification 4. User input register The MHEG engine shall provide a mechanism to indicate the running application‟s key input requirements to the UI Management Engine (UIME). The UIME allows an application to request a particular keyset.2. When an MHEG application changes the input event register.YouView Core Technical Specification DirectFB key symbols DIKS_SMALL_R DIKS_SMALL_G DIKS_SMALL_Y DIKS_SMALL_B DIKS_0 … DIKS_9 R K X X X X Conditions ALT modifier set ALT modifier set ALT modifier set ALT modifier set Key identifier is in range DIKI_0 … DIKI_9 or ALT modifier not set MHEG UserInput value Red (100) Green (101) Yellow (102) Blue (103) 5-14 X X Table 39 : Key mappings 4. © YouView TV Ltd (2011) Page 214 of 229 . the new set of keys which the application now needs to respond to shall be communicated to the UIME. © YouView TV Ltd (2011) Page 215 of 229 . TLS client authentication and the x-youview-appid header are not required for MHEG. Use of HTTP proxies shall be supported. Networking The MHEG engine shall support the InteractionChannelExtension and ICStreamingExtension. The MHEG engine shall support HTTP and HTTPS (HTTP over TLS) connections using the libcurl shared library required by Chapter II Consumer Device Platform.YouView Core Technical Specification 5. UIME is notified that an MHEG application has quit A mechanism shall be provided to allow the UIME to be notified when an MHEG application quits.10.5. 6. Receiving launch parameters The MHEG engine shall support the GetLaunchArguments resident program. See also section 2. and any parent Applications of the currently active application. are deactivated. The following sections describe how the MHEG engine interacts with the UI Management Engine (UIME) described in Chapter XIII Consumer Device UI Management. The MHEG engine shall then request that the UIME activate the Application. it will either present MHEG applications on-screen or will present a full-screen transparent window. 6. GetLaunchArguments is described in more detail in Chapter VIII Broadcast Content Delivery. logical ApplicationPlayer. This may be invoked when another application requires full-screen access to the graphics plane. 6. The MHEG engine shall respond to the ApplicationLaunchExtension(N) GetEngineSupport feature string. When the MHEG engine starts.4. UIME can kill an MHEG application The MHEG engine shall provide a mechanism for the UIME to kill the currently running MHEG application. otherwise it will typically deactivate it. the UIME will activate the MHEG application. The UIME‟s Application object shall be initialised with the window set fully transparent. which provides a mechanism for the running MHEG application to receive launch parameters from the (non-MHEG) application that launched it. The MHEG engine is required to support only the „overlay‟ and „kill‟ options described in section 16. but darkened. Application Lifecycle While the MHEG engine is running.3.1. The UIME will respond to this by hiding the MHEG window and updating its internal application list. Launching other applications The MHEG engine shall support the ApplicationLaunch resident program. UIME is notified of an MHEG application A mechanism shall be provided to allow the MHEG engine to indicate the presence of a running MHEG application to the UI Management Engine. Application and Window objects are created in the UIME.1 of DTG D-Book 7 Part A v1. The „broadcast‟ MHEG engine is modelled by the UIME as an ApplicationPlayer which always hosts a single Application. 6.2. ApplicationLaunch is described in more detail in Chapter VIII Broadcast Content Delivery. 6.YouView Core Technical Specification 6. When the user changes channel and the MHEG engine detects an MHEG application in the new broadcast stream. the MHEG application will generally be activated only when the currently active application. Once deactivated. depending on whether MHEG presentation is currently visible. If no other application is active at this point. © YouView TV Ltd (2011) Page 216 of 229 . making it visible.4. which provides a mechanism for applications of any supported type to be launched from an MHEG application. it starts rendering the MHEG application to the window. described in more detail in Chapter VIII Broadcast Content Delivery. YouView Core Technical Specification Chapter XVI Consumer Device Local Diagnostics © YouView TV Ltd (2011) Page 217 of 229 . Chapter Summary This chapter specifies the Local Diagnostics support to be built into YouView consumer devices. Local Diagnostics will provide viewers with a summary of important device information and operational behaviour.YouView Core Technical Specification 1. Chapter audience This chapter is for: Device Manufacturers. Local Diagnostics will be provided as part of the Platform Main UI application and accessible through the Settings menu and/or the Help Area. This will empower the more technically savvy viewers to help themselves. This chapter is not relevant for: Content Providers Application Developers ISPs © YouView TV Ltd (2011) Page 218 of 229 . correct. 1. and give customer support agents and website tools the information needed to diagnose. which will allow them to either solve problems themselves (self-help) or be guided to the appropriate information by contextual help. who may need to:  Implement Local Diagnostic screens relating to device specific functional areas as part of the Platform Main UI application. a customer support agent or the YouView customer support website.1. This chapter does not provide a detailed definition of the on-screen appearance of each area of Local Diagnostics capability. and document commonly occurring issues. This chapter describes the Local Diagnostic capability for a range of functional areas. YouView Core Technical Specification 2. default gateway. update policy and date and time of last check – see Chapter VI Consumer Device Software Management): o Core Device Software o Platform Software o Device Manufacturer-provided Device Configuration o Platform provided-Device Configuration o ISP-provided Device Configuration  Storage and memory usage o Presence of media storage as part of the device o Total. interface name and type. DNS server addresses. time. Present the interface‟s IP address. These may appear as part of the Settings menu and/or the Help Area. Check whether the configured default gateway can be reached using ICMP echo requests. The device shall provide means for the Local Diagnostic screens to include the following information:  Hardware information o Device Manufacturer name o Consumer device model and version o Consumer device serial number  Software information (including date. Test the data transfer rate achieved by the overall IP connection. version. used and free space available for recordings and downloads o Estimated space required for future media acquisition o RAM usage  Broadcast delivery o Date and time of last check to see if the set of available broadcast services has changed o Number of broadcast services installed o Date and time that the set of installed broadcast services was updated o Target Regions receivable at the time of the last scan o Selected Target Region o Real-time presentation of signal strength and quality for a particular multiplex o Real-time presentation of signal strength and quality for a particular installed service  IP network o Physical layer The device shall provide means to carry out the following diagnostic steps for the active network interface:     Check whether there is an active interface in a connected state. Local Diagnostic screens may be provided by YouView or the Device Manufacturer. depending on the nature of the consumer device functionality being diagnosed. Local Diagnostics within the Platform Main UI Local Diagnostics screens will form part of the Platform Main UI. subnet mask. © YouView TV Ltd (2011) Page 219 of 229 . YouView Core Technical Specification © YouView TV Ltd (2011) Page 220 of 229 . YouView Core Technical Specification Chapter XVII Consumer Device Usage And Error Reporting © YouView TV Ltd (2011) Page 221 of 229 . Section 3 describes the usage and error reporting architecture. Chapter Summary This chapter describes the support for usage and error reporting to be built into the YouView consumer device. © YouView TV Ltd (2011) Page 222 of 229 . storage and use of usage and error data once it has been backhauled so as to ensure that data protection and privacy obligations are met is beyond the scope of this specification.YouView Core Technical Specification 1. Note: The handling. which has the logical component Usage Collection Agent (UCA) at its core. It also raises a number of privacy considerations which shall be observed. Section 2 introduces the concepts of usage and error reporting. This includes both the capture and backhaul of such data. Note: Nothing in this specification precludes the direct capture of usage and error reporting by a Content Provider‟s Application and backhaul to an HTTP end-point of their own. A single on-demand asset viewing is seen as a series of events:           On-demand Asset is selected to Play – Player Application is launched.YouView Core Technical Specification 2.3. which in turn relate to discreet user activities and settings information stored on the device in some common configuration repository. software version etc. Error data Error data is a collective term for any data generated as a result of detectable problems with a device.g. Determining the rate at which a new version of Core Device Software or Platform Software is upgraded to by the population of devices in the field. software version etc. remove the number of button clicks. Identifying navigational paths through the user interface that are well used and hence potential areas for optimisation. expected operation of the device.g. i. Generating “most popular” lists for use within the Platform Main UI. The following examples of usage events are provided to illustrate user activities and settings/configuration information. The Platform Main UI shall provide means to allow the viewer to set preferences relating to the export of usage and error data: this shall not be a one-time only option. Alternatively.g. the viewer may be happy to allow data to be shared with selected third parties. Buffering of On-demand Asset begins Buffer size reaches sufficient size to enable playback of an on-demand asset On-demand Asset playback begins On-demand Asset playback is paused by the viewer – Playback speed set to 0x Usage data provides a benefit to both the viewer and the platform in many ways. Identifying parts of the user interface that are not well used and hence potential areas for changing or removing. 2. e. e. However. Further benefit can be derived when usage data is combined with information about the device from which it was backhauled. Usage data Usage data is a collective term for any information related to viewer activity on a consumer device. Some viewers may not wish any usage and error data resulting from their use of the device to be made available to any third party. Error data can provide value in a raw form. as with usage data. 2.1. ability for the viewer to turn on/off usage capture at a later date. Possible examples include:   The YouView Metadata Aggregation System is unreachable. including YouView.e. Overview 2. further benefit can be derived when error data is combined with information about the device from which it was backhauled. model. Buffer underrun on on-demand asset playback. including: Identifying parts of the user interface that are well used and hence potential areas for further enhancement. e. issues of trust and the privacy of the individual are important considerations. Usage data is comprised of “usage events”. Privacy considerations As with any situation where data is to be collected. Error data is comprised of “error events”. model.2. © YouView TV Ltd (2011) Page 223 of 229 . The vast majority of this data will be generated by the normal. This can be used to determine problems specific to a particular device model or software release. In both cases this applies to usage and event data in any form. Finally. It shall not be possible for any person with physical access to the device to be able to extract usage and error data using trivial means.YouView Core Technical Specification The implementation of support for usage and error data capture and export on the device needs to be robust and secure. it shall be possible for the viewer to securely clear any usage and event data held on the device. storage and use of usage and error data once it has been backhauled so as to ensure that data protection and privacy obligations are met is beyond the scope of this specification. Hence:   It shall not be possible for third-party software (including Content Provider Applications) to be able to access and export usage and error data. The handling. © YouView TV Ltd (2011) Page 224 of 229 . YouView Core Technical Specification 3. Usage and error reporting architecture 3.1. Introduction The architecture for usage and error event collection is based around the concept of a Usage Collection Agent (UCA) and one or more Exporters. 3.2. Usage Collection Agent The UCA shall be responsible for:   Capturing relevant usage and error events on the device. Securely storing usage and event data on the device and deleting it once it is no longer needed. Usage and error data shall not be stored permanently on the device. Individual usage and error events shall not remain stored on the device if: o The event has been backhauled by all relevant Exporters, or o The event‟s “age” (i.e. time since capture) exceeds a defined maximum, or o The limit of available storage for usage and error events has been reached, in which case data shall be deleted in a “first in, first out” basis.   Supporting the clearing of stored usage and event data. Making captured usage and event data available to Exporters as appropriate. The UCA shall implement a mechanism where high priority events are sent to Exporters immediately, whilst low priority events are stored locally until needed by the relevant Exporter(s). 3.3. Exporters It shall be possible to configure the UCA to send usage and error data to a number of Exporters on the device. Each Exporter can be tailored to the requirements of a specific external interface. These interfaces are the gateways through which usage data can be backhauled from the device to some remote server. The Exporter is a translator between the internal private format used by the UCA for the capture and temporary storage of usage and error data, and the format which is expected by the endpoint exposed by the backhaul interface. 3.3.1. Export control The Platform Main UI shall provide viewers with the ability to disable usage and error reporting on the device, either completely or on a per-Exporter basis. Note: The specific design of the UI presented to the viewer to set these preferences is out of scope of this specification. © YouView TV Ltd (2011) Page 225 of 229 YouView Core Technical Specification Chapter XVIII Annexes © YouView TV Ltd (2011) Page 227 of 229 YouView Core Technical Specification Annex A Related Documents DTG, D-Book, 7 Part A v1, March 2011. ETSI TS 102 578, PowerLine Telecommunications (PLT); Coexistence between PLT Modems and Short Wave Radio broadcasting services, v1.1.8, 2007-08. IEEE 802.3, LAN/MAN CSMA/CDE (Ethernet) Access Method, 2008. IEEE 802.11g, Wireless Local Area Networks, 2003. IEEE 802.11n, Wireless Local Area Networks, 2009. IETF RFC 1738, Uniform Resource Locators (URL), December 1994 IETF RFC 2109, HTTP State Management Mechanism, February 1997. IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, June 1999. IETF RFC 2617, HTTP Authentication: Basic and Digest Access Authentication, June 1999. IETF RFC 3376, Internet Group Management Protocol, Version 3, October 2002. IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005 IETF RFC 3852, Cryptographic Message Syntax (CMS), July 2004. IETF RFC 4294-bis, IPv6 Node Requirements, March 2010. IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008 IEC 62455, Internet protocol (IP) and transport stream (TS) based service access, June 2007. W3C, HTML 4.01 Specification, December 1999 W3C Recommendation, Timed-Text Markup Language (TTML), v1.0, November 2010. Marlin Developer Community, Marlin Simple Secure Streaming Specification, version 1.0. Marlin Trust Management Organisation, Marlin Client Adopter agreement. © YouView TV Ltd (2011) Page 228 of 229 Examples could be Flash player. W3C browser Software that is managed by the Device Manufacturer Digital Video Recorder – records television broadcasts to local storage such as a hard drive Electronic Programme Guide – an on screen listings for scheduled television Internet Service Provider – an organisation that provides a user with access to the Internet The environment in which the device is deployed Applications that are managed by the Platform Operator or Device Manufacturer Describes a set of parameters that allow the behaviour of the device to be configured after deployment without requiring the software to be updated The Application that provides the core user interface for the device Software that is managed and updated by the Platform Operator Applications that are managed by the Platform Operator General purpose memory available to the Application CPU that may be used to hold graphics Memory accessible directly by graphics acceleration and graphics display hardware Video On Demand – the facility to permit a viewer to watch/listen to video/audio on demand © YouView TV Ltd (2011) Page 229 of 229 . MHEG engine.YouView Core Technical Specification Annex B Term Access Services Application Application Player Core Device Software DVR EPG ISP Platform Platform Applications Platform Configuration Platform Main UI Platform Software Platform UI Applications System Memory Video Memory VOD Glossary Explanation Subtitles and audio description Packaged and managed software that provides functionality to consumers Runtime environment for the execution of Applications.