RVU Protocol Specification
RVU Alliance CONFIDENTIAL
V1.0 Rev 1.5.1 28 May 2014
RVU Specification Protocol Revision History
Revision History
Revision Description Date V1.0 Rev 0.9 DIRECTV Contribution to the RVU Alliance. 2009-09-18 DRAFT V1.0 Rev 1.0 1.1.8 – added client/server setup summary 2009-12-03 FINAL 4.2.1, 4.2.2 – added sequencing requirements on single and multiple channels 4.8.2.3.16-1 – add transparent and substitute actions 5.2.1.5, 5.2.1.8, 5.2.1.16, 5.2.1.24 – specify PAUSED_PLAYBACK state on rewind to zero time position 5.6.5, 5.7, 5.8 – removed references to DIRECTV_HD_AC3, DIRECTV_HD_AC3_T 9.2 – made mandatory the client implementation of the Connection Manager actions PrepareForConnection and ConnectionComplete 11.3 Clean up device description XML Misc clarifications, naming, parameter, reference errata removed DIRECTV references where possible V1.0 Rev 1.1 4.5, 4.5-7 – note that the background is always behind the video buffer in the z- 2010-03-31 DRAFT list, which is in turn always behind the display buffer 4.8.1.3, 4.8.2.3.9 – 4.8.2.3.15 – remove references to hardware acceleration 4.8.2.3.17, 4.8.2.3.19 – make SetZList command optional 4.8.2.5 – clarify that output units refer to the output canvas, not the video or display buffer 4.8.2.5.10 – make BlindVideo transparent to background instead of black 5.2.1.5, 5.2.1.8, 5.2.1.16, 5.2.1.24 – specify STOPPED state on rewind to zero time position, also reset absoluteTimePosition to 0, and event LastChange Misc syntax errata, clarifications, references, and table captions throughout
Intellectual Property Notice
Use of the information contained herein shall be governed solely by the terms and conditions of the RVU Alliance IPR Policy. The document and information contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by any of the authors or developers of this specification. The information contained herein is provided on an “AS IS” basis, and to the maximum extent permitted by applicable law, the authors and developers of this specification hereby disclaim all other warranties and conditions, either express, implied or statutory, including but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, of lack of negligence. ALSO THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT. RVU is a registered trademark of the RVU Alliance. All rights reserved. Copyright 2014 © RVU Alliance.
V1.0 Rev 1.5.1 2 of 262 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Revision History
Revision Description Date V1.0 Rev 1.2 1.1.7, 2,2 – noted RVU server is not required to a UPnP Media Server 2010-04-30 DRAFT 4.2.1-2 – noted channel ID is unique per RVU element 4.2.1-3 – noted a command response is sent on the same channel as the received command 4.2.1-8, 4.2.2-3 – noted action if hello received other than 1st on a channel 4.2-19, 4.2-20 – mandated initiator and only initiator must send hello on new channel (command and data) 4.3.2-4 - deleted 4.4-9 – added 1 sec limit for responding to non-queued command not associated with data 4.4.10 – added 1 sec limit after Dispatch or Blit Queue for responding to queued command not associated with data 4.6-6, 4.6-13, 4.6-14, 4.6-15 – made server only 4.6-7 to 4.6-12 – made client only 4.7.2-6 – mandated sending keys over TLS channel when established 4.8.2.1.1-1 – added ERR_INVALID_PORTNUM 4.8.2.1.3-1 – made GetMemInfo command mandatory for server only 4.8.2.2.1-2, 4.8.2.2.2-2 – mandated keyVal must be one returned from GetKeyList 4.8.2.3.12 – 4.8.2.3.15 – added ERR_CLUT_DEST_BUFFER 4.8.2.3.17-7 – added clutDestBitsSupported attributes 4.8.2.3.20-3 – added ERR_BOUNDING 4.8.2.5.1, 4.8.4.2 – noted both VideoDisplaySettingsChanged and OutputSettingsChanged are triggered 4.8.2.5.15 – clarified interaction between EnableClosedCaptioning and Local CC Setting6 – changed prose to numbered requirements 7.4.1-3 – deleted 8, 8.2, 11.2.2 – made server support of CIA optional 9.1.4 – separated xml into sections matching 9.1.3 Throughout – refer to “session” rather than “RUI session’ and ‘UPnP A/V session’ rather than ‘streaming/media session” Misc clarifications and references throughout V1.0 Rev 1.3 1.2 – added acronym table 2010-07-01 DRAFT 3.2.1 – added UPnP device icon list usage 4.8.2.5.15 – clarified server should manage display of CC vs graphics 5.1.3.1.3 – specified I-Frame container inherited from content stream 5.1.3.1.4 – rewrote text as requirements 5.6.5-2, 5.6.5-3, table 5-32 – added Non-DLNA Media Format Profile Mime Types 5.7 – updated examples 5.8 – deleted 9.1.1.2, 9.1.1.4, 9.1.4.5 – change X_Audio_Encoding and X_Video_Encoding to string Appendix C – added Throughout – refer to Porter-Duff blend rather than blit Misc clarifications and references throughout
V1.0 Rev 1.5.1 3 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Revision History
Revision Description Date V1.0 Rev 1.4 1.1.8 – added autoip guideline; noted multiple video streams can be used 2010-12-21 DRAFT 2.1.1-3, 2.1.1-4 – made client specific 2.1.1-5, 2.1.1-6, 2.1.1-7, 2.1.1-8 – added 2.2.1-8 - deleted 4.1.1 – added 4.2-18 – changed detection time for disconnect from 30 to 10 seconds 4.2.1-14 – added ERR_COMMAND_NOT_IMPLEMENTED 4.2.2-6 – deleted 4.5 – add 3DTV references 4.7.1-2 - deleted 4.7.1-4, 4.7.1-7 – require client HDMI Key Event support 4.8.1.5 – add 3DTV references 4.8.2.3.16-1 – remove replace and copy actions 4.8.2.3.17-7 – add supported3DTVStructures 4.8.2.4.4 – added ClientRequestLocalUI 4.8.2.5.1-3, 4.8.2.5.1-4 – added video buffer zlist association rules 4.8.2.5.13-2, 4.8.2.5.14-1 – added display settings attributes 4.8.2.5.18, 4.8.2.5.19 – added 3DTV commands 5.2.1 – added clarification on PLAYING substates Tables, 5-7, 5-8, 5-9, 5-11, 5-12, 5-15, 5-16, 5-19, 5-20, 5-26, 5-27, 5-28 – added END_OF_MEDIA sequence Table 5-32, Table 5-33, 5.7, Appendix C – changed naming from non-DLNA media formats to DLNA MPEG_DIRECTV_SD media formats; added SHP and SPHP profiles 9.1.1.2, 9.1.1.4 – updated encoding allowed values Misc clarifications and errata throughout V1.0 Rev 1.4.1 2.1.1-3 - 2.1.1-6 deleted 2011-06-22 DRAFT 3.2.2-2 – delete client differentiation by port 4.8.2.3.19-3, 4.8.2.3.19-4, 4.8.2.3.19-5 – M for clients supporting SetZList 4.8.2.4.1-2 – made optional 4.8.2.4.2-3 – deleted 4.8.2.5.1-3 – M independently of SetZList support 4.8.2.5.1-4 – deleted 5.1.2.1-6 – added Table 9-4 – remove last 2 columns Misc clarifications and errata throughout
V1.0 Rev 1.5.1 4 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Revision History
Revision Description Date V1.0 Rev 1.4.2 2.2.1-4, 2.2.1-5 deleted 2011-09-21 FINAL 4.2-21 – add mandatory use of Hello command UUID field 4.8.2.1.1-1 – added UDN 4.8.2.4.2-4 – deleted 4.8.2.4.3-4,5 – required server to return to previous state (video/ui) after resuming control from client local UI 4.8.2.4.4-1,2 – made optional 4.8.2.4.4-5 – add requirement for org.rvualliance.ClientRequest 4.8.2.6.4-3 – require minimum support for PCM sample rates of 44.1 and 48 4.8.2.7 – added for program audio commands 5.1.2.2.1.2 – add byte-length, note frames are sent in play order (fwd/rew) 5.6.5-4 – limit high profile format types required to 3D TV STBs and TVs only Table 5-31 – added MP4 container Format Profile MIME type and PCM profile for 48000 sample rate 6.8 – added scenario for unsupported local ui element 9.1-1 – added Tables 9-4 and 9-6 – removed Required/Optional column Appendix D – added Misc clarifications and errata throughout V1.0 Rev 1.4.3 1.1.4, 5 – mention DLNA 3-Box System Usage 2012-07-26 DRAFT 4.1.1 – allow exceptions for hex formatting 4.7.1, 4.8.1.2, 4.8.2.2.3 - clarify cdi key codes optional, hdmi mandatory, and either mapping applies to all defined keys 4.8.2.1.2-1 – added shutdown reason codes as optional 4.8.2.2 – add mandatory/optional column 4.8.2.2.1, 4.8.2.2.2 – reword key code description to omit 0x prefix, and uppercase 4.8.2.4.2 – clarify lui/rui z-list and display interaction 4.8.2.4.4-6 – suggested 3D consistency upon return from local UI tables 4-114, 4-154 - require pixel format to be argb-32 4.8.2.5.12 – add capabilitiesChanged attribute, add and renumber for -2 and -3 requirements 4.8.2.5.18.1 - update width, height values and expand and fix diagrams to illustrate half/full resolution 4.8.2.6.4, 4.8.2.6.8, 4.8.2.6.9 - updated descriptions of audio formats Figure 4-3 – add figure 4-4 to distinguish between output canvas and resulting viewer display for half resolution 4.8.2.5.19 – clarify flatten applies to video 5.4 – decouple tts from pcr for handling network jitter 5.6.5, table 5-31 – add 3DFC profile mime types 6 – local ui reqs secondary to 4.8.2.4 8.4.3-7 – allowed ignoring image after check of major and minor numbers Table 12-4 – added optional major and minor software numbers 12.3 – added major and minor software numbers to argument list 3DTV clarifications throughout, including acronym entry Resolution, width and height clarifications throughout Misc clarifications and errata throughout
V1.0 Rev 1.5.1 5 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Revision History
Revision Description Date V1.0 Rev 1.4.4 2.2.3-1, 2.2.3-3 – deleted, 2.2.3-4 added 2012-10-18 FINAL 2.2.3-2, table 4-10 reworded to remove RUI sub-protocol 5.1.1-18 add support for generic urls per dlna guidelines 5.1.2.1-3, 5.2.1 remove playspeed.dlna.org 5.7 remove DLNA.ORG_PS, remove DLNA.ORG_OP when DLNA.ORG_FLAGS begins with C 5.2.1 specify state to STOPPED after draining content buffer V1.0 Rev 1.5 1.2 - add several acronyms 2013-08-14 DRAFT 3.2.2-8 – made mandatory 4.8.2.3.3, 4.8.2.3.4 - distinguish display from graphics buffer table 4-40 - add ERR_NON_PREMULTIPLIED 4.8.2.3.17 – added LatAm and 4k resolutions table 4-78 - require multiple frame-rate support where specified 4.8.2.3.20 - remove reference to display buffer table 4-86 - clarify bufId is graphics, not display, buffer table 4-89 - add subtitle language setting 4.8.2.5.15, 4.8.2.5.16, 4.8.2.5.17 - note also applies to subtitling 4.8.2.5.17 - add language response attribute table 4-154 - make full-res frame packing optional 5.1.2.2 - deleted 5.1.3, 5.1.3.1 - reorganized multiframe scan descriptions and requirements 5.1.3.2 – added 5.3-4, 5.3.5 – added 5.6.5 - (new) add 5.6.5 RVUALLIANCE.ORG_SUB_INFO flag 5.6.6-4, table 5-33 - changed from 3D/high profile to HEVC 5.6.6-5, 5.6.6-6 - changed from informative text to requirements Table 5-34 – added 13.2.5, 13.3, 13.4 – added previous 13.3 – deleted Appendix 14 – replaced DLNA guidelines with LatAm client requirements V1.0 Rev 1.5.1 3.2.1-2 – 3.2.1-6, figure 3-2 – replace 3.2.1-2 2014-02-20 IP Review Table 4-89 – add org.rvualliance.ServerSelection DRAFT Table 5-34, 13.5, 14.1-3, 14.2-2, 14.3-3 – add h.264 + MPEG1-L2 format profile types Table 10-1 – add Ref45 Table 4-78 - separated 2160p/60 from 2160p/24/30, added 4320p/60. added optional 3DTV structures for 2160p and 4320p Noted optionality of 2160p and 4320p in 4.8.2.3.17-5 Added sample 4th field text in 5.6.5; added section 6.9 Corrected syntax of “org_sub_info” in section 5.6.5 example Added main 10 8 bit h.265 profiles in Table 5-33 Added h.265 to 5.1.3.1.3 and 9.1.1.4 V1.0 Rev 1.5.1 2014-05-28 FINAL
V1.0 Rev 1.5.1 6 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Table of Contents
Table of Contents
1 RVU – An Introduction ...... 20 1.1 Document Organization ...... 21 1.1.1 Addressing, Discovery, and Description ...... 21 1.1.2 Session Management ...... 22 1.1.3 Remote User Interface ...... 22 1.1.4 Media Transfer ...... 22 1.1.5 QoS and Diagnostics ...... 22 1.1.6 Client Image Acquisition ...... 23 1.1.7 UPnP Templates ...... 23 1.1.8 Client/server setup summary ...... 23 1.2 Acronyms ...... 24 2 Addressing, Discovery, and Description ...... 26 2.1 Standards ...... 26 2.1.1 RVU-Specific Settings ...... 26 2.2 UPnP Devices and Services ...... 27 2.2.1 RVU Client ...... 28 2.2.2 RVU Server ...... 29 2.2.3 Versioning ...... 29 3 Session Management ...... 31 3.1 Standards ...... 31 3.2 Establishment of Sessions ...... 31 3.2.1 Client-Server Association ...... 31 3.2.2 User Interfaces/RUI ...... 33 3.2.3 Examples ...... 34 4 Remote User Interface ...... 36 4.1 Standards ...... 36 4.1.1 Conventions ...... 36 4.2 Connections (Channels)...... 36 4.2.1 Command Channels ...... 39 4.2.2 Data Channels ...... 40 4.3 Session Startup and Teardown Sequences...... 42 4.3.1 Session Startup ...... 42 4.3.2 Session Teardown ...... 44 4.4 Timing...... 45 4.5 Buffers ...... 46 4.6 Audio ...... 48 4.7 User Inputs ...... 49 4.7.1 Key Event Commands ...... 49 4.7.2 Security ...... 50 4.8 Commands ...... 51 4.8.1 Summary ...... 51 V1.0 Rev 1.5.1 7 of 262 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Table of Contents
4.8.2 Command Details ...... 55 4.8.3 Missing or Invalid Parameters ...... 137 4.8.4 Examples ...... 137 4.9 Data Types ...... 140 5 Media Transfer ...... 142 5.1 Standards ...... 143 5.1.1 DLNA Requirements ...... 143 5.1.2 HTTP Usage ...... 144 5.1.3 Multi-Frame Media Scanning ...... 145 5.1.4 UPnP Requirements ...... 148 5.2 State Transitions ...... 149 5.2.1 State Transition Details ...... 154 5.3 DTCP...... 197 5.4 Clock Synchronization and Sender Pacing ...... 198 5.4.1 TTS Clock Synchronization Requirements ...... 198 5.4.2 Sender Pacing ...... 199 5.4.3 Pause – Resume With TTS Synchronization ...... 199 5.4.4 Mandatory Clock Synchronization Conditions ...... 201 5.5 Performance Criteria ...... 201 5.6 Additional res@protocolInfo other-param Flags ...... 202 5.6.1 RVUALLIANCE.ORG_APID ...... 202 5.6.2 RVUALLIANCE.ORG_VPID ...... 202 5.6.3 RVUALLIANCE.ORG_FLAGS ...... 202 5.6.4 RVUALLIANCE.ORG_MAX_REQUEST_FRAME_COUNT ...... 203 5.6.5 RVUALLIANCE.ORG_SUB_INFO ...... 203 5.6.6 Profile Names and MIME Types for AVTransport Streams ...... 203 5.7 Example Fourth res@protocolInfo Fields ...... 206 6 Client Local Menus ...... 210 6.1 Closed Captioning ...... 210 6.2 Screen Format Menus ...... 211 6.3 Restart Menu ...... 211 6.4 Reset Defaults ...... 211 6.5 Dolby Digital Menu ...... 212 6.6 Network Menus ...... 212 6.7 Unhandled Key ...... 212 6.8 Unsupported UI Element ...... 213 7 QoS and Diagnostics ...... 215 7.1 Standards ...... 215 7.2 Network Topology ...... 215 7.3 Quality of Service ...... 217 7.3.1 Recommendations ...... 218 7.3.2 Requirements ...... 218
V1.0 Rev 1.5.1 8 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Table of Contents
7.4 Diagnostics ...... 219 7.4.1 Recommendations ...... 219 7.4.2 Requirements ...... 219 8 Client Image Acquisition ...... 222 8.1 Standards ...... 223 8.2 Summary of Processes ...... 223 8.3 General Requirements ...... 227 8.4 Client Image Acquisition...... 227 8.4.1 Client Request and Server Search ...... 227 8.4.2 Server Download ...... 229 8.4.3 Client Transfer ...... 231 8.4.4 Client Boot Image Usage ...... 231 8.5 Client Image Management ...... 232 9 UPnP Templates ...... 233 9.1 RVU Extensions to RenderingControl Service...... 234 9.1.1 State Variables ...... 234 9.1.2 Eventing and Moderation ...... 235 9.1.3 Actions ...... 235 9.1.4 XML Additions ...... 238 9.2 RVU Extensions to Connection Manager Service ...... 241 9.3 RVU Extensions to AVTransport Service ...... 241 10 References ...... 242 11 Appendix A: RVUServer Device Template ...... 244 11.1 Overview and Scope ...... 244 11.2 Device Definitions ...... 244 11.2.1 Device Type ...... 244 11.2.2 Device Model ...... 244 11.2.3 Theory of Operation ...... 245 11.3 XML Device Description ...... 245 12 Appendix B: ClientImageManager Service Template ...... 247 12.1 Overview and Scope ...... 247 12.2 Service Modeling Definitions ...... 247 12.2.1 Service Type ...... 247 12.2.2 State Variables ...... 247 12.2.3 Eventing and Moderation ...... 248 12.2.4 Actions ...... 248 12.2.5 Theory of Operation ...... 251 12.3 XML Device Description ...... 252 13 Appendix C: Extended Media Format Profiling Requirements ...... 254 13.1 MPEG-4 Part 10 (AVC) Closed Caption Stream ...... 254 13.2 Characteristics of MPEG_DIRECTV_SD Media Format Profiles ...... 255 13.2.1 System Portion Profile for MPEG_DIRECTV_SD ...... 255 13.2.2 Video Portion Profile for MPEG_DIRECTV_SD Video ...... 255 V1.0 Rev 1.5.1 9 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Table of Contents
13.2.3 MPEG_DIRECTV_SD AV Format, Audio Portion Profile: MPEG1_L2 ...... 257 13.2.4 MPEG_DIRECTV_SD AV Format, Audio Portion Profile: AC3 ...... 258 13.2.5 MPEG_DIRECTV_SD AV Format, Captioning Portion Profile for Latin American Broadcast Regions 258 13.3 SBTVD Media Format Profile ...... 258 13.3.1 System Portion Profile ...... 258 13.3.2 Video Portion Profile ...... 258 13.3.3 Audio Portion Profile ...... 258 13.3.4 Captioning Portion Profile ...... 259 13.4 HEVC Media Format Profiles ...... 259 13.4.1 System Portion Profile ...... 259 13.4.2 Video Portion Profile ...... 259 13.4.3 Audio Portion Profile ...... 260 13.4.4 Captioning Portion Profile ...... 260 13.5 AVC + MPEG1 Layer 2 audio ...... 260 13.5.1 Subtitling Portion Profile ...... 260 14 Appendix D: Latin American Client Requirements ...... 261 14.1 Brazil ...... 261 14.2 Mexico ...... 261 14.3 Other Regions (Panamericana) ...... 261
V1.0 Rev 1.5.1 10 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Figures
List of Figures
Figure 1-1: RVU Sub-Protocol Sequence ...... 20 Figure 2-1: RVU UPnP Devices and Services ...... 28 Figure 3-1: Session Management Flow ...... 31 Figure 3-2: Server Selection Flow ...... 33 Figure 4-1: Session Startup Sequence ...... 44 Figure 4-2: MultiSourceBlendBlit Implementation ...... 81 Figure 4-3: Half-Resolution Side-by-Side Output Canvas Display Using ReconfigureDisplayBuffer3DTV command (4.8.2.5.18.1 example) ...... 118 Figure 4-4: Half and Full-Resolution Side-by-Side Viewer Display during Left Eye Mapping time Period Using ReconfigureDisplayBuffer3DTV command (4.8.2.5.18.1 example) ...... 119 Figure 4-5: Half and Full-Resolution Side-by-Side Viewer Display during Right Eye Mapping time Period Using ReconfigureDisplayBuffer3DTV command (4.8.2.5.18.1 example) ...... 120 Figure 4-6: Startup, No Video Sequence ...... 138 Figure 4-7: Startup, One Video Sequence ...... 139 Figure 4-8: Single Video, Aspect Change Sequence ...... 139 Figure 4-9: Single Video, Output Format Change Sequence ...... 140 Figure 5-1: Media Transfer Components ...... 143 Figure 5-2: States and State Transitions ...... 149 Figure 5-3: RVU AVTransport with Virtual Playing States ...... 151 Figure 5-4: No Media to Stopped Sequence ...... 155 Figure 5-5: Stopped to Stopped (Ready) Sequence ...... 156 Figure 5-6: Stopped to Normal-Speed Playing Sequence ...... 158 Figure 5-7: Stopped to Playing Slow Sequence ...... 160 Figure 5-8: Stopped to Playing Fast Sequence ...... 163 Figure 5-9: Stopped to Stopped (Seek) Sequence ...... 165 Figure 5-10: Playing Slow to Normal-Speed Playing Sequence...... 166 Figure 5-11: Playing Slow to Playing Fast Sequence ...... 168 Figure 5-12: Playing Slow to Paused Sequence ...... 169 Figure 5-13: Playing Slow to Playing Slow (Seek) Sequence ...... 171 Figure 5-14: Playing Fast to Normal-Speed Playing Sequence ...... 173 Figure 5-15: Playing Fast to Playing Slow Sequence ...... 175 Figure 5-16: Playing Fast to Paused Sequence ...... 176 Figure 5-17: Playing Fast to Playing Fast (Seek) Sequence ...... 178 Figure 5-18: Normal-Speed Playing to Playing Slow Sequence...... 179 Figure 5-19: Normal-Speed Playing to Playing Fast Sequence ...... 181 Figure 5-20: Normal-Speed Playing to Paused Sequence ...... 182 Figure 5-21: Normal-Speed Playing to Normal-Speed Playing Sequence ...... 184 Figure 5-22: Playing to Stopped Sequence ...... 185
V1.0 Rev 1.5.1 11 of 262 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Figures
Figure 5-23: Paused to Paused (Absolute Time Seek) Sequence ...... 187 Figure 5-24: Paused (not from Fast Forward or Reverse) to Paused (Relative Seek) Sequence ...... 189 Figure 5-25: Paused (from Fast Forward or Reverse) to Paused (Relative Seek) Sequence ...... 190 Figure 5-26: Paused to Normal-Speed Playing Sequence ...... 192 Figure 5-27: Paused to Playing Slow Sequence...... 193 Figure 5-28: Paused to Playing Fast Sequence ...... 195 Figure 5-29: Paused to Stopped Sequence ...... 196 Figure 5-30: Stopped to No Media Present Sequence ...... 197 Figure 5-31: Steady State HTTP Streaming with Sender Pacing ...... 200 Figure 5-32: HTTP Connection Stalling Based Pause ...... 200 Figure 5-33: Invalid Pacing Information ...... 200 Figure 6-1: Local UI Control Process ...... 210 Figure 7-1: Closed Network ...... 216 Figure 7-2: Open Network ...... 216 Figure 7-3: Multiple Servers ...... 217 Figure 7-4: Example of RVU Isolation ...... 218 Figure 8-1: Client Image Acquisition Flow ...... 222 Figure 8-2: CIA Flow: Boot Image Found on Server ...... 224 Figure 8-3: CIA Flow: Boot Image is Not Found on Server ...... 225 Figure 8-4: Initial Client Image Acquisition ...... 226 Figure 8-5: Client Image Maintenance Initialization ...... 226 Figure 8-6: Client Image Maintenance ...... 227 Figure 11-1: RVU Server Structure ...... 245 Figure 13-1: ITU-R BO.1516 SYSTEM B Transport Stream with TTS support ...... 255
V1.0 Rev 1.5.1 12 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
List of Tables
Table 4-1: Command not implemented response attributes ...... 40 Table 4-2: Data Channel Syntax ...... 42 Table 4-3: Data Channel Field Definitions ...... 42 Table 4-4: Setup, Teardown, and Info commands ...... 52 Table 4-5: User Input commands ...... 52 Table 4-6: Graphics commands ...... 53 Table 4-7: Local UI commands ...... 53 Table 4-8: Display commands...... 54 Table 4-9: Audio commands ...... 55 Table 4-10: Hello command attributes ...... 55 Table 4-11: Hello response attributes ...... 56 Table 4-12: Hello response error codes ...... 56 Table 4-13: Shutdown command attributes ...... 56 Table 4-14: Shutdown response attributes ...... 57 Table 4-15: Shutdown response error codes ...... 57 Table 4-16: GetMemInfo command attributes ...... 57 Table 4-17: GetMemInfo response attributes ...... 58 Table 4-18: GetMemInfo response error codes ...... 58 Table 4-19: Key Assignments ...... 60 Table 4-20: HDMIKeyEvent command attributes...... 60 Table 4-21: HDMIKeyEvent response attributes...... 61 Table 4-22: HDMIKeyEvent response error codes ...... 61 Table 4-23: CDIKeyEvent command attributes...... 61 Table 4-24: CDIKeyEvent response attributes...... 62 Table 4-25: CDIKeyEvent response error codes ...... 62 Table 4-26: GetKeyList command attributes...... 62 Table 4-27: GetKeyList response attributes ...... 63 Table 4-28: GetKeyList response error codes ...... 63 Table 4-29: AllocateBuffer command attributes ...... 64 Table 4-30: AllocateBuffer response attributes ...... 64 Table 4-31: AllocateBuffer response error codes ...... 64 Table 4-32: DeallocateBuffer command attributes ...... 65 Table 4-33: DeallocateBuffer response attributes ...... 65 Table 4-34: DeallocateBuffer response error codes ...... 65 Table 4-35: Write command attributes ...... 66 Table 4-36: Write response attributes ...... 66 Table 4-37: Write response error codes ...... 66
V1.0 Rev 1.5.1 13 of 262 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
Table 4-38: Read command attributes ...... 67 Table 4-39: Read response attributes ...... 67 Table 4-40: Read response error codes ...... 68 Table 4-41: BlitQueue command attributes ...... 68 Table 4-42: BlitQueue response attributes ...... 69 Table 4-43: BlitQueue response error codes ...... 69 Table 4-44: Dispatch command attributes ...... 69 Table 4-45: Dispatch response attributes ...... 70 Table 4-46: Dispatch response error codes ...... 70 Table 4-47: EmptyQueue command attributes ...... 70 Table 4-48: EmptyQueue response attributes ...... 71 Table 4-49: EmptyQueue response error codes ...... 71 Table 4-50: WaitVSync command attributes ...... 71 Table 4-51: WaitVSync response attributes ...... 72 Table 4-52: WaitVSync response error codes ...... 72 Table 4-53: CopyBlit command attributes ...... 72 Table 4-54: CopyBlit response attributes ...... 73 Table 4-55: CopyBlit response error codes ...... 73 Table 4-56: FillBlit command attributes ...... 73 Table 4-57: FillBlit response attributes ...... 74 Table 4-58: FillBlit response error codes ...... 74 Table 4-59: ResizeBlit command attributes ...... 75 Table 4-60: ResizeBlit response attributes ...... 75 Table 4-61: ResizeBlit response error codes ...... 75 Table 4-62: ShadeBlit command attributes ...... 76 Table 4-63: ShadeBlit response attributes ...... 76 Table 4-64: ShadeBlit response error codes ...... 77 Table 4-65: BlendBlit command attributes ...... 77 Table 4-66: BlendBlit response attributes ...... 78 Table 4-67: BlendBlit response error codes ...... 78 Table 4-68: MultiSourceBlendBlit command attributes ...... 79 Table 4-69: MultiSourceBlendBlit response attributes ...... 80 Table 4-70: MultiSourceBlendBlit response error codes ...... 80 Table 4-71: ResizeAndBlendBlit command attributes ...... 82 Table 4-72: ResizeAndBlendBlit response attributes ...... 82 Table 4-73: ResizeAndBlendBlit response error codes ...... 82 Table 4-74: ColorKeyResizeBlit command attributes ...... 83 Table 4-75: ColorKeyResizeBlit response attributes ...... 84 Table 4-76: ColorKeyResizeBlit response error codes ...... 84
V1.0 Rev 1.5.1 14 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
Table 4-77: GetGraphicsCaps command attributes ...... 84 Table 4-78: GetGraphicsCaps response attributes ...... 87 Table 4-79: GetGraphicsCaps response error codes ...... 87 Table 4-80: GetZList command attributes ...... 88 Table 4-81: GetZList response attributes ...... 88 Table 4-82: GetZList response error codes ...... 88 Table 4-83: SetZList command attributes ...... 89 Table 4-84: SetZList response attributes ...... 89 Table 4-85: SetZList response error codes ...... 89 Table 4-86: SetCLUT command attributes ...... 90 Table 4-87: SetCLUT response attributes ...... 90 Table 4-88: SetCLUT response error codes ...... 91 Table 4-89: Local UI Elements ...... 91 Table 4-90: ListLocalUIElements command attributes ...... 92 Table 4-91: ListLocalUIElements response attributes ...... 92 Table 4-92: ListLocalUIElements response error codes ...... 92 Table 4-93: RequestLocalUI command attributes ...... 93 Table 4-94: RequestLocalUI response attributes ...... 93 Table 4-95: RequestLocalUI response error codes ...... 94 Table 4-96: LocalUIEvent command attributes ...... 94 Table 4-97: LocalUIEvent response attributes ...... 94 Table 4-98: LocalUIEvent response error codes ...... 95 Table 4-99: ClientRequestLocalUI command attributes ...... 95 Table 4-100: ClientRequestLocalUI response attributes ...... 95 Table 4-101: ClientRequestLocalUI response error codes ...... 96 Table 4-102: GetVideoBuffer command attributes ...... 97 Table 4-103: GetVideoBuffer response attributes ...... 97 Table 4-104: GetVideoBuffer response error codes ...... 97 Table 4-105: ReleaseVideoBuffer command attributes ...... 98 Table 4-106: ReleaseVideoBuffer response attributes ...... 98 Table 4-107: ReleaseVideoBuffer response error codes ...... 98 Table 4-108: SetBackgroundColor command attributes ...... 98 Table 4-109: SetBackgroundColor response attributes ...... 99 Table 4-110: SetBackgroundColor response error codes ...... 99 Table 4-111: ConfigureDisplayBuffer command attributes ...... 99 Table 4-112: ConfigureDisplayBuffer response attributes ...... 99 Table 4-113: ConfigureDisplayBuffer response error codes ...... 100 Table 4-114: ReconfigureDisplayBuffer command attributes ...... 100 Table 4-115: ReconfigureDisplayBuffer response attributes ...... 101
V1.0 Rev 1.5.1 15 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
Table 4-116: ReconfigureDisplayBuffer response error codes ...... 101 Table 4-117: ConfigureVideoFullscreen command attributes ...... 101 Table 4-118: ConfigureVideoFullscreen response attributes ...... 102 Table 4-119: ConfigureVideoFullscreen response error codes ...... 102 Table 4-120: ConfigureVideoWindow command attributes ...... 102 Table 4-121: ConfigureVideoWindow response attributes ...... 103 Table 4-122: ConfigureVideoWindow response error codes ...... 103 Table 4-123: ConfigureWindowedVideoWindow command attributes ...... 104 Table 4-124: ConfigureWindowedVideoWindow response attributes ...... 104 Table 4-125: ConfigureWindowedVideoWindow response error codes ...... 104 Table 4-126: ConfigureVideoDecodeResolution command attributes ...... 105 Table 4-127: ConfigureVideoDecodeResolution response attributes ...... 105 Table 4-128: ConfigureVideoDecodeResolution response error codes ...... 105 Table 4-129: BlindVideo command attributes ...... 105 Table 4-130: BlindVideo response attributes ...... 106 Table 4-131: BlindVideo response error codes...... 106 Table 4-132: GetOutputSettings command attributes ...... 106 Table 4-133: GetOutputSettings response attributes ...... 107 Table 4-134: GetOutputSettings response error codes ...... 107 Table 4-135: OutputSettingsChanged command attributes ...... 107 Table 4-136: OutputSettingsChanged response attributes ...... 108 Table 4-137: OutputSettingsChanged response error codes ...... 108 Table 4-138: GetVideoDisplaySettings command attributes ...... 108 Table 4-139: GetVideoDisplaySettings response attributes ...... 109 Table 4-140: GetVideoDisplaySettings response error codes ...... 110 Table 4-141: VideoDisplaySettingsChanged command attributes ...... 111 Table 4-142: VideoDisplaySettingsChanged response attributes ...... 111 Table 4-143: VideoDisplaySettingsChanged response error codes ...... 111 Table 4-144: Closed Captioning control ...... 111 Table 4-145: AllowClosedCaptioning command attributes ...... 112 Table 4-146: AllowClosedCaptioning response attributes ...... 112 Table 4-147: AllowClosedCaptioning response error codes ...... 112 Table 4-148: EnableClosedCaptioning command attributes ...... 113 Table 4-149: EnableClosedCaptioning response attributes ...... 113 Table 4-150: EnableClosedCaptioning response error codes ...... 113 Table 4-151: GetClosedCaptioningState command attributes ...... 113 Table 4-152: GetClosedCaptioningState response attributes ...... 114 Table 4-153: GetClosedCaptioningState response error codes ...... 114 Table 4-154: ReconfigureDisplayBuffer3DTV command attributes ...... 115
V1.0 Rev 1.5.1 16 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
Table 4-155: ReconfigureDisplayBuffer3DTV response attributes ...... 116 Table 4-156: ReconfigureDisplayBuffer3DTV response error codes ...... 116 Table 4-157: ReconfigureDisplayBuffer3DTV example values ...... 117 Table 4-158: Set3DTVFlattenStructure command attributes ...... 121 Table 4-159: Set3DTVFlattenStructure response attributes ...... 121 Table 4-160: Set3DTVFlattenStructure response error codes ...... 121 Table 4-161: OpenAudioDecoder command attributes ...... 122 Table 4-162: OpenAudioDecoder response attributes ...... 122 Table 4-163: OpenAudioDecoder response error codes ...... 122 Table 4-164: CloseAudioDecoder command attributes ...... 123 Table 4-165: CloseAudioDecoder response attributes ...... 123 Table 4-166: CloseAudioDecoder response error codes ...... 123 Table 4-167: GetNumAudioDecoders command attributes ...... 123 Table 4-168: GetNumAudioDecoders response attributes ...... 124 Table 4-169: GetNumAudioDecoders response error codes...... 124 Table 4-170: GetAudioDecoderCaps command attributes ...... 124 Table 4-171: GetAudioDecoderCaps response attributes ...... 126 Table 4-172: GetAudioDecoderCaps response error codes ...... 126 Table 4-173: AllocateAudioBuffer command attributes ...... 127 Table 4-174: AllocateAudioBuffer response attributes ...... 127 Table 4-175: AllocateAudioBuffer response error codes ...... 127 Table 4-176: DeallocateAudioBuffer command attributes ...... 127 Table 4-177: DeallocateAudioBuffer response attributes ...... 128 Table 4-178: DellocateAudioBuffer response error codes ...... 128 Table 4-179: WriteAudioData command attributes ...... 128 Table 4-180: WriteAudioData response attributes ...... 129 Table 4-181: WriteAudioData response error codes ...... 129 Table 4-182: Play command attributes ...... 131 Table 4-183: Play response attributes ...... 131 Table 4-184: Play response error codes ...... 131 Table 4-185: PlayBuffer command attributes...... 133 Table 4-186: PlayBuffer response attributes ...... 134 Table 4-187: PlayBuffer response error codes ...... 134 Table 4-188: PlayStatus command attributes ...... 134 Table 4-189: PlayStatus status values ...... 135 Table 4-190: PlayStatus response attributes ...... 135 Table 4-191: PlayStatus response error codes...... 135 Table 4-192: Stop command attributes ...... 135 Table 4-193: Stop response attributes ...... 136
V1.0 Rev 1.5.1 17 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
Table 4-194: Stop response error codes ...... 136 Table 4-195: MuteProgramAudio scenarios ...... 136 Table 4-196: MuteProgramAudio command attributes ...... 136 Table 4-197: MuteProgramAudio response attributes ...... 137 Table 4-198: MuteProgramAudio response error codes ...... 137 Table 4-199: Startup, No Video Sequence ...... 138 Table 4-200: Startup, One Video Sequence ...... 138 Table 4-201: Single Video, Aspect Change Sequence ...... 139 Table 4-202: Single Video, Output Format Change Sequence ...... 139 Table 4-203: Data Types and Commands ...... 141 Table 5-1: RVU Element DLNA features supported ...... 144 Table 5-2: RVU Element UPnP AVTransport Actions ...... 148 Table 5-3: RVU AVTransport State Transition Table ...... 150 Table 5-4: Media Transfer State Transitions Summary ...... 153 Table 5-5: No Media to Stopped Sequence ...... 155 Table 5-6: Stopped to Stopped (Ready) Sequence ...... 156 Table 5-7: Stopped to Normal-Speed Playing Sequence ...... 157 Table 5-8: Stopped to Playing Slow Sequence...... 159 Table 5-9: Stopped to Playing Fast Sequence ...... 162 Table 5-10: Stopped to Stopped (Seek) Sequence ...... 164 Table 5-11: Playing Slow to Normal-Speed Playing Sequence ...... 165 Table 5-12: Playing Slow to Playing Fast Sequence ...... 167 Table 5-13: Playing Slow to Paused Sequence ...... 169 Table 5-14: Playing Slow to Playing Slow (Seek) Sequence...... 170 Table 5-15: Playing Fast to Normal-Speed Playing Sequence ...... 172 Table 5-16: Playing Fast to Playing Slow Sequence ...... 174 Table 5-17: Playing Fast to Paused Sequence...... 176 Table 5-18: Playing Fast to Playing Fast (Seek) Sequence ...... 177 Table 5-19: Normal-Speed Playing to Play Slow Sequence ...... 179 Table 5-20: Normal-Speed Playing to Playing Fast Sequence ...... 180 Table 5-21: Normal-Speed Playing to Paused Sequence ...... 182 Table 5-22: Normal-Speed playing to Normal-Speed Playing Sequence ...... 183 Table 5-23: Playing to Stopped Sequence ...... 185 Table 5-24: Paused to Paused (Absolute Time Seek) Sequence ...... 186 Table 5-25: Paused to Paused (Relative Seek) Sequence ...... 188 Table 5-26: Paused to Normal-Speed Playing Sequence ...... 191 Table 5-27: Paused to Playing Slow Sequence ...... 193 Table 5-28: Paused to Playing Fast Sequence...... 194 Table 5-29: Paused to Stopped Sequence ...... 196
V1.0 Rev 1.5.1 18 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol List of Tables
Table 5-30: Stopped to No Media Present Sequence ...... 197 Table 5-31: DLNA Media Format Profile MIME Types ...... 205 Table 5-32: MPEG_DIRECTV_SD Format Profile MIME Types ...... 205 Table 5-33: HEVC Format Profile MIME Types ...... 206 Table 5-34: Latin America Specific Media Format Profile MIME Types ...... 206 Table 6-1: Unsupported UI Element Message Sequence ...... 213 Table 7-1: PHY Rates per Link ...... 220 Table 7-2: PHY Stats Syntax ...... 221 Table 7-3: PHY Stats Field Definitions ...... 221 Table 9-1: RVU Server Device and Service Templates ...... 233 Table 9-2: RVU Client Device and Service Definitions ...... 233 Table 9-3: RVU Client Device and Service Templates ...... 233 Table 9-4: RenderingControl State Variables ...... 234 Table 9-5: RecordingControl Event Moderation...... 235 Table 9-6: Actions ...... 235 Table 9-7: X_UpdateAudioSelection arguments ...... 236 Table 9-8: X_UpdateAudioSelection error codes...... 236 Table 9-9: X_GetAudioSelection arguments...... 236 Table 9-10: X_GetAudioSelection error codes ...... 237 Table 9-11: X_UpdateVideoSelection arguments ...... 237 Table 9-12: X_UpdateVideoSelection error codes ...... 237 Table 9-13: X_GetVideoSelection arguments...... 238 Table 9-14: X_GetVideoSelection error codes ...... 238 Table 10-1: Documentation References ...... 243 Table 11-1: RVU Server Devices and Services ...... 244 Table 12-1: Client Image Manager State Variables ...... 247 Table 12-2: Client Image Manager Event Moderation ...... 248 Table 12-3: Actions ...... 249 Table 12-4: CheckImage arguments ...... 249 Table 12-5: CheckImage error codes ...... 250 Table 13-1: ATSC AVC SEI Syntax ...... 254 Table 13-2: AVC Caption Transport Syntax following provider_code = 0x[002F] ...... 254 Table 13-3: MPEG_DIRECTV_SD Video Encoding Parameters ...... 256 Table 13-4: MPEG_DIRECTV_SD Video Picture Header User Data ...... 256 Table 13-5: MPEG_DIRECTV_SD Video User Data Types ...... 257 Table 13-6: MPEG_DIRECTV_SD Video User Data Info ...... 257
V1.0 Rev 1.5.1 19 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol RVU – An Introduction
1 RVU – An Introduction
This document describes an open protocol called RVU (pronounced “ar-view”). RVU leverages technologies such as Universal Plug and Play (UPnP) and Digital Living Network Alliance (DLNA) to enable communication between a media server and one or more clients.
This document details the specifications for RVU, broken down into six sub-protocols: Addressing, Discovery, and Description Session Management Remote User Interface (RUI) Media Transfer Quality of Service (QoS) and Diagnostics Client Image Acquisition (CIA)
An overview of the sequence of the required RVU sub-protocols is shown in Figure 1-1 below.
Boot Process
Addressing Quality of Service (QoS) Acquisition of IP addresses by server and client. Server-managed assurance of desired service quality throughout all RVU processes.
Discovery Advertisement of devices and/or services.
Description Exchange of full device and service information between server and client.
Session Management Establishment of remote user interface connection between client and server.
Remote User Interface (RUI) Communication between client and server, providing UI graphics and audio to client.
Media Transfer Transmission of renderable data (such as video and audio) from server to client.
Figure 1-1: RVU Sub-Protocol Sequence
V1.0 Rev 1.5.1 20 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol RVU – An Introduction
1.1 Document Organization This protocol specification defines the client software support required for RVU compliance. The goal is that a client that employs the sub-protocols in this specification can be inserted into an RVU network and be functional with minimal modifications.
This document also describes the functionality required by an RVU media server, but only to fully illustrate its connectivity with a client.
Throughout this document, specific terminology is used to refer to systems that use the RVU protocol. These terms are common industry terms defined by UPnP and DLNA, among others. For example, a detailed explanation of terms such as device, service, and control point can be found in the Understanding Universal Plug and Play white paper [Ref3]. Knowledge of these terms is assumed in this document.
This document uses the following conventions for requirements:
M = Mandatory, S = Suggested, O = Optional Likewise, the words “shall” and “must” mean mandatory, the word “should” means suggested, and the word “may” means optional. RVU-S = RVU server, RVU-C = RVU client "RVU element" is a generic term for an RVU server or client For example, a requirement that is mandatory for an RVU client but only suggested for a server would be written as
[1.1-1] M: RVU-C; S: RVU-S An RVU element shall support X functionality as defined in [RefY]. where "1.1" is the section in which the requirement is found, "-1" is the requirement number, and "RefY" is a document listed in the References section (see section 10 of this document).
In some cases, the requirement is shown as an entry in a table for clarity.
The general organization of the document is summarized in the sections that follow.
1.1.1 Addressing, Discovery, and Description Based solely on the UPnP specification, RVU’s Addressing, Discovery, and Description sub-protocol encompasses how servers and clients acquire IP addresses and discover the presence and capabilities of components on the network. Addressing refers to the assignment of network addresses to each node in the network. Discovery involves the initial interaction between servers and clients (e.g., TVs). Description refers to the exchange of detailed device- and service-related information.
References and requirements specific to RVU’s use of addressing, discovery, and description are detailed in section 2.
V1.0 Rev 1.5.1 21 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol RVU – An Introduction
1.1.2 Session Management The Session Management sub-protocol describes how a client associates itself with an RVU server. Session management also encompasses how clients acquire the information they need to connect to the server’s RUI module.
RVU’s session management is based on the UPnP standard. For further elaboration, see section 3.
1.1.3 Remote User Interface One of the unique features of RVU is the sub-protocol specifically designed to handle the clients’ interaction with the RVU server: Remote User Interface (RUI). This sub-protocol allows clients to offer a complete user interface (UI) with a common look-and-feel, without requiring extensive custom UI software on the clients.
Unlike other sub-protocols, RUI is designed specifically for the demands of RVU and is completely unique. The details for RUI appear in this specification in section 4.
1.1.4 Media Transfer The Media Transfer sub-protocol describes the mechanism used to deliver content data (e.g., video and audio) securely from the server to the client. A key feature of media transfer is the ability to deliver live as well as pre-recorded content.
RVU’s application of media transfer is based substantially on the DLNA media transfer requirements, which in turn make use HTTP (HyperText Transfer Protocol). RVU employs the DLNA Two-Box Push Controller System Usage, with the server acting as the Push Controller and each RVU client acting as a Digital Media Renderer (DMR). See section 5 for specifications on extending RVU to the DLNA 3-box system usage.
The Media Transfer sub-protocol defines a set of state transitions that can be combined to provide basic content delivery, trick play, alternate audio selection, and handling of unauthorized content (such as a movie that hasn’t been purchased).
Media Transfer uses Digital Transmission Content Protection (DTCP) to ensure secure transmission of streamed data. Media Transfer also defines how to maintain clock synchronization.
Details on this sub-protocol are found in section 5.
1.1.5 QoS and Diagnostics The Quality of Service (QoS) and Diagnostics sub-protocol includes standards for ensuring a consistently high quality of service throughout the segment of network elements using RVU.
RVU uses prioritized QoS based on the DLNAQOS model. To monitor QoS throughout the system, diagnostic tools must be available. Diagnostic tools are defined for both automated system maintenance and user-initiated troubleshooting.
See section 7 for more information on QoS and diagnostics.
V1.0 Rev 1.5.1 22 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol RVU – An Introduction
1.1.6 Client Image Acquisition The Client Image Acquisition (CIA) sub-protocol describes the use of Trivial File Transfer Protocol (TFTP) to assist RVU clients in acquiring their executable boot image from the server. It defines how a client learns that a new boot image exists, how it determines the location of the boot image, and how it acquires the boot image.
The CIA sub-protocol of RVU is optional for clients utilizing RVU, but is required for RVU servers. For more information, see section 8.
1.1.7 UPnP Templates The RVU protocol uses a number of standard UPnP devices. In addition, a new device, the RVUServer, and a new service, the ClientImageManager, are defined. Note, an RVU server is not required to be a UPnP Media Server.
References to the templates for the UPnP devices and services employed by the RVU server and the RVU client can be found in section 9 of this document. The template for the RVUServer device can be found in section 11. The template for the ClientImageManager service can be found in section 12.
1.1.8 Client/server setup summary The following sequence of steps is the typical way a client and server would identify each other, setup a session and start streaming content:
1. The client discovers server, by receiving an ssdp:alive message, or by sending an SSDP search and getting a response from the server, (UPnP discovery), see 3.1 and 3.2.1.
2. When a client discovers a server having both DHCP and AutoIP IP addresses, the client should connect to the server for RVU communications using the AutoIP address. This should isolate RVU communications from network disturbances caused by user configuration of the router that supplied the DHCP address.
3. The client invokes GetCompatibleUIs on the server's RUI service, see 3.2.2.
4. The server's response includes a port to use for channel connections, see 3.2.2 and 3.2.3.2. Note: Steps 3 and 4 are collectively referred to as establishing a RUI connection.
5. The client makes an initial RUI command-channel connection to that port and continues with any other RUI startup, see chapter 4.
6. The server does a UPnP search for (or has already found/cached) the client's UPnP MediaRenderer device (and its associated ConnectionManager and AVTransport services). It can identify this by matching the incoming IP address from the client's RUI channel with the IP address of the UPnP device.
7. The server invokes ConnectionManager::PrepareForConnection, see 9.2.
8. The server invokes the RUI GetVideoBuffer command with the AVTransportID provided by the PrepareForConnection response. The server can now position where the video is V1.0 Rev 1.5.1 23 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol RVU – An Introduction
displayed on the client (PIG or full-screen), see 4.8.2.5.1 and 4.8.4.2. Note: an application could employ multiple video streams.
9. The server invokes AVTransport::SetAVTransportURI. The metadata for the URI includes the mime-type of the initial content for the client to play. If it is DTCP content, the mime-type will include the relevant DTCP parameters, along with the audio/video content information.
If DTCP content, the client performs the DTCP AKE step.
10. The server invokes AVTransport::Play, see 5.2.1.3.
11. The client makes an HTTP request to the URI that was specified in the SetAVTransportURI call, thereby starting video, see 5.2.1.3.
1.2 Acronyms
Term Stands for 3DTV Stereoscopic 3D TV (left and right eye video and graphics), i.e. not 3D graphics (e.g. OpenGL) AAC Advanced Audio Coding ABNT Associação Brasileira de Normas Técnicas (English: Brazilian National Standards Organization) AKE Authentication and Key Exchance – a DTCP process ARGB Alpha Red Green Blue - a color graphics composition scheme ARIB Association of Radio Industries and Businesses – a standard org for digital television broadcasting. ATSC Advanced Television Systems Committee – a standards org for digital television broadcasting AV “Audio with Video" – media content that contains moving pictures and sound AVC Advanced Video Coding – refers to the H.264 video codec CC Closed Captioning CIA Client Image Acquisition CLUT Color Look-Up Table (in this document CLUT-8, i.e. 8 bit lookup or 256 ARGB-32 colors) DIDL Digital Item Declaration Language DLNA Digital Living Network Alliance DMR Digital Media Renderer DTCP Digital Transmission Content Protection DVB Digital Video Broadcasting ES Elementary Stream
V1.0 Rev 1.5.1 24 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol RVU – An Introduction
HDMI High-Definition Multimedia Interface HEVC High Efficiency Video Coding – refers to the H.265 video codec HTTP Hyper-Text Transfer Protocol IDR Instantaneous Decoder Refresh – an H.264 group of pictures special I-frame IEC International Electrotechnical Commission IP Internet Protocol ISO International Standards Organization ITU International Telecommunications Union JPEG Joint Photographic Experts Group - a standard for compression of still images LUI Local User Interface LWS Linear White Space MAC Media Access Control MoCA Multimedia over Coax Alliance MPEG Moving Picture Experts Group OSD On Screen Display PCR Program Clock Reference PES Packetized Elementary Stream PID Packet Identifier (for ISO 13818-1 transport streams) QoS Quality of Service RCS Rendering Control Service RFC Request for Comments - a publication of the Internet Engineering Task Force RUI Remote User Interface SBTVD Sistema Brasileiro de Televisão Digital (English: Brazilian Digital Television System) SCID Service Channel ID (for ITU-R BO.1516 SYSTEM B transport streams) TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol TLS Transport Layer Security TTS Timestamped Transport Stream UI User Interface UPnP Universal Plug and Play URI Uniform Resource Identifier XML Extensible Markup Language
V1.0 Rev 1.5.1 25 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Addressing, Discovery, and Description
2 Addressing, Discovery, and Description
The Addressing, Discovery, and Description sub-protocol of RVU dictates how network components acquire addresses and discover the presence and capabilities of other network components. Addressing refers to the assignment of network addresses to each node in the network. Discovery involves the initial interaction between UPnP devices and control points for the purpose of notifying control points of the availability of useful devices and services. Description refers to the control points’ acquisition of detailed device- and service-related information.
2.1 Standards The RVU protocols for addressing, discovery, and description conform to those defined in UPnP Device Architecture, v1.0, 20 July 2006 [Ref1] and DLNA Networked Device Interoperability Guidelines, Volume 1: Architectures and Protocols, v1.5, October 2006 [Ref10]. The relevant sections of these documents are listed below.
An RVU element shall comply with the following UPnP specifications [Ref1] to support addressing, discovery, and description:
Req Ref1 Section Description [2.1-1] M: RVU-S, RVU-C 0 Addressing [2.1-2] M: RVU-S, RVU-C 1 Discovery [2.1-3] M: RVU-S, RVU-C 2 Description An RVU element shall comply with all requirements in the following DLNA guidelines sections [Ref10] to support addressing, discovery, and description:
Req Ref10 Section Description [2.1-4] M: RVU-S, RVU-C 7.1 Networking and Connectivity [2.1-5] M: RVU-S, RVU-C 7.2 Device Discovery and Control
2.1.1 RVU-Specific Settings
[2.1.1-1] M: RVU-S, RVU-C An RVU element shall use a default value of 1800 seconds for the value of the CACHE- CONTROL (the duration of a discovery advertisement’s availability) for advertisements. (Keeping this duration short gives control points a more accurate indication of their availability.)
[2.1.1-2] M: RVU-C An RVU client shall keep its make, model, and hardware revision values constant as these numbers are used by the server to uniquely identify the client.
V1.0 Rev 1.5.1 26 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Addressing, Discovery, and Description
[2.1.1-3] M: RVU-C
DELETED
[2.1.1-4] M: RVU-C
DELETED
[2.1.1-5] M: RVU-S
DELETED
[2.1.1-6] M: RVU-S
DELETED
[2.1.1-7] M: RVU-C An RVU client shall generate a UUID based on the Version 1 method described in section 4.1.6 of [Ref29]:
[2.1.1-8] M: RVU-C An RVU client shall keep the MAC address used in the UUID constant, even if the UUID changes, e.g. across reboots.
2.2 UPnP Devices and Services Figure 2-1 shows a logical diagram of the UPnP devices and services found in an RVU client and server. These are the only UPnP devices and services that RVU requires in these components; however, other devices and services may be included. For example, a server may also include a UPnP internet gateway device, but this is not needed to support the RVU protocol. Note, an RVU server is not required to be a UPnP Media Server.
V1.0 Rev 1.5.1 27 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Addressing, Discovery, and Description
Client Server
MediaRenderer RVUServer
RenderingControl RemoteUiServerDevice
RemoteUIServer ConnectionManager
AVTransport ClientImageManager
Key Device Subdevice Service Service
Figure 2-1: RVU UPnP Devices and Services
2.2.1 RVU Client
[2.2.1-1] M: RVU-C An RVU client shall include a DMR as defined by the DLNA standard.
[2.2.1-2] M: RVU-C An RVU client shall contain a UPnP MediaRenderer device.
[2.2.1-3] M: RVU-C An RVU client shall provide a standard UPnP RenderingControl service 1.0, extended as defined in 9.1.
[2.2.1-4] M: RVU-C DELETED
[2.2.1-5] M: RVU-C DELETED
[2.2.1-6] M: RVU-C An RVU client shall provide a standard UPnP ConnectionManager service 1.0, extended as defined in 9.2.
[2.2.1-7] M: RVU-C An RVU client shall provide a standard UPnP AVTransport service 1.0, supporting HTTP transport, extended as defined in 5.1.3. Note: the standard UPnP template for the MediaRenderer defines the AVTransport service as optional, but it is required for an RVU client.
[2.2.1-8] M: RVU-C DELETED.
V1.0 Rev 1.5.1 28 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Addressing, Discovery, and Description
[2.2.1-9] M: RVU-C An RVU client shall set the manufacturer name field of the MediaRenderer Device to the make of the client hardware.
[2.2.1-10] M: RVU-C An RVU client shall set the model name field of the MediaRenderer Device to the model of the client hardware.
[2.2.1-11] M: RVU-C An RVU client shall set the model number field of the MediaRenderer Device to the hardware revision of the client hardware.
References to the templates for the UPnP devices and services employed by an RVU client can be found in section 9 of this document.
2.2.2 RVU Server
[2.2.2-1] M: RVU-S An RVU server shall contain an RVUServer device, as defined in section 11 of this document.
[2.2.2-2] M: RVU-S An RVU server shall provide the ClientImageManager service, as defined in section 12 of this document.
[2.2.2-3] M: RVU-S An RVU server shall contain a standard UPnP RemoteUIServerDevice device.
[2.2.2-4] M: RVU-S An RVU server shall provide a standard UPnP RemoteUIServer service.
[2.2.2-5] M: RVU-S An RVU server shall provide an HTTP server.
[2.2.2-6] M: RVU-S An RVU server shall provide a UPnP control point capable of interacting with the client's AV Media Services.
Details about the templates for the UPnP devices and services employed by the RVU server can be found in section 9 of this document.
2.2.3 Versioning
[2.2.3-1] M: RVU-S, RVU-C DELETED.
[2.2.3-2] M: RVU-S, RVU-C An RVU element shall indicate its supported RVU version using the version string in the "hello" command (as specified in section 4 of this document).
V1.0 Rev 1.5.1 29 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Addressing, Discovery, and Description
[2.2.3-3] M: RVU-S DELETED.
[2.2.3-4] M: RVU-S A server shall limit RVU protocol usage to no more than the version capability indicated by the client.
V1.0 Rev 1.5.1 30 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Session Management
3 Session Management
The Session Management sub-protocol of RVU defines the process for establishing communication between the client and the server.
A client associates itself with an RVU server through session management.
RVU session management is also used to establish a RUI connection from the client to the server. It uses the device and service descriptions obtained via the discovery process to determine which devices and services to contact. This section specifies how a client determines which of its user interfaces are compatible with the server’s remote user interface, and how it acquires the information needed to perform the RUI connection.
The diagram for session management flow is shown in Figure 3-1 below.
Client Server
Select RVU Server
Which UIs can RVUServer be used for RUI connection? RemoteUiServerDevice
GetCompatibleUIs() RemoteUIServer
Connect to RUI Filtered UI list Module
connect() RUI Module
Figure 3-1: Session Management Flow
3.1 Standards The actions and results used in session management are a subset of the UPnP definition of the devices and services used. The GetCompatibleUIs action, found in the RemoteUIServerService [Ref5], section 2.4.1, is used in session management.
3.2 Establishment of Sessions
3.2.1 Client-Server Association Following discovery via UPnP, an RVU client associates itself with an RVU server to establish subscriptions to state variables and a session. This association is referred to as "pairing". Figure 3-2 shows server selection flow.
[3.2.1-1] M: RVU-C An RVU client shall pair with one and only one RVU server at any time.
V1.0 Rev 1.5.1 31 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Session Management
[3.2.1-2] M: RVU-C An RVU client shall attempt to reconnect to the cached server when entering an RVU session..
[3.2.1-3] M: RVU-C If an RVU client is unable to connect to the cached server, the client shall present a means for selection of an alternative server following discovering via UPnP .
[3.2.1-4] M: RVU-C An RVU client shall cache the connected server information for an RVU session in non-volatile memory
[3.2.1-5] M: RVU-C If an RVU client is unable to connect to the cached server (for example, due to a reset, software download or other local networking issue,) and a user does not actively select an alternative server, that RVU client shall automatically reconnect to the cached server when it becomes available.
[3.2.1-6] M: RVU-C An RVU client shall provide a means to access an RVU server selection menu at user convenience. For example, a client device’s input selection button could display the list alternative RVU servers.
[3.2.1-7] S: RVU-S An RVU server should provide suitable icons to represent the device through the use of the UPnP device icon list.
[3.2.1-8] O: RVU-C An RVU client may provide suitable icons to represent the device through the use of the UPnP device icon list.
[3.2.1-9] S: RVU-S, RVU-C An RVU element providing icons through the use of the UPnP device icon list should do so using PNG images of sizes 16x16 and 32x32 pixels.
[3.2.1-10] S: RVU-S, RVU-C When displaying any list of RVU elements, an RVU element should use the device icons from the UPnP device icon list where appropriate.
V1.0 Rev 1.5.1 32 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Session Management
Yes Start Cached server?
No
Search for servers
No servers Zero servers? found Yes No
Display server list No
Cached No server? & User available? selection?
Yes Yes
RVU Change session? Yes server? No
No Yes
Figure 3-2: Server Selection Flow
3.2.2 User Interfaces/RUI
[3.2.2-1] M: RVU-C An RVU client shall send a list of UIs supported by the client per [Ref5], section 3.1.3. Note: the protocol short name for the RVU RUI protocol used in the DeviceProfile is "RVU-RUI".
V1.0 Rev 1.5.1 33 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Session Management
[3.2.2-2] M: RVU-S An RVU server shall reply to a GetCompatibleUIs request by sending a UTF-8 XML-formatted list of UIs the server supports, filtered by the list of UIs supported by the client per [Ref5], section 3.1. Note: if the server and client both support the RVU RUI, the response would include the protocol name "RVU Remote UI", the protocol short name "RVU-RUI", and the URI/Protocol Identifier string "rvurui".
[3.2.2-3] M: RVU-S An RVU server shall reply to a GetCompatibleUIs request with an empty UIListing string if the server does not support the UI requested by the client.
[3.2.2-4] M: RVU-S An RVU server shall reply to a GetCompatibleUIs request with error code 800 if the server supports the UI requested by the client, but the maximum number of sessions is already active.
[3.2.2-5] M: RVU-C An RVU client shall start a session if at least one compatible UI is returned by the RVU server.
[3.2.2-6] M: RVU-C DELETED
[3.2.2-7] S: RVU-C An RVU client should notify the user if no RUI connection can be established for any reason (such as the case where no compatible UIs are returned by the RVU server).
[3.2.2-8] M: RVU-C An RVU client shall have a method to select one UI if multiple UIs are available. The specific selection process is beyond the scope of this document.
3.2.3 Examples
3.2.3.1 InputDeviceProfile The following is a sample xml for InputDeviceProfile sent by the client in GetCompatibleUIs requesting support for RVU_RUI protocol:
3.2.3.2 UIListing The following is an example xml for UIListing returned by the RVU server in response to a request for RVU-RUI protocol support.
V1.0 Rev 1.5.1 34 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Session Management
V1.0 Rev 1.5.1 35 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4 Remote User Interface
The Remote User Interface (RUI) sub-protocol of RVU allows clients of a media server to communicate remote control commands and status to the server. It also allows the server to send graphics and audio to provide a full-featured UI within the client. This allows clients to be manufactured with little customized UI software and makes it possible for existing clients to be integrated into an RVU network using the RVU server UI.
A RUI connection is initiated by a client (a server cannot initiate a RUI connection). Such a connection is followed by creation of one or more Transmission Control Protocol (TCP) streams, called channels. Two types of channel connections must be supported: command channels, which provide an interface for the allowed RUI commands, and data channels, which provide the data needed to employ the RUI commands.
4.1 Standards
[4.1-1] M: RVU-S, RVU-C RUI channels between RVU elements shall utilize TCP (Transmission Control Protocol, RFC 793 [Ref12]).
RUI commands are unique to the RVU protocol and do not correspond to any other existing protocol or standard.
4.1.1 Conventions In this specification, the following command attribute types shall be defined as follows:
o int – optional ‘+’ or ‘-‘, optionally followed by 1 or more leading ‘0’ characters, followed by decimal characters (‘0’-‘9’) representing a 32 bit signed integer value
o uint – optionally, 1 or more leading ‘0’ characters, followed by decimal characters (‘0’-‘9’) representing a 32 bit unsigned integer value
o hex – a sequence of 1 to 8 hexadecimal characters (‘0’-‘9’, ‘a’-‘f’, ‘A’-‘F’) representing the value of a 32-bit integer, without a “0x” prefix Note: for a specific command, restrictions on the prefix and the case of the alphabetic characters may be explicitly overridden as documented.
o string – a sequence of UTF-8 encoded characters that would be valid in an XML attribute
In this specification, XML string means UTF-8 encoded XML message
In this specification, bitmasks are indexed starting with LSB=bit 0
4.2 Connections (Channels) RVU elements send commands and responses on command channels as XML strings. On data channels, RVU elements send binary or ASCII data.
V1.0 Rev 1.5.1 36 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.2-1] M: RVU-S, RVU-C An RVU element shall have the ability to open a TCP stream (referred to as a "channel") after a RUI connection between a server and a client has been established.
[4.2-2] M: RVU-C An RVU client shall create a channel by connecting to the RVU server via a TCP socket.
[4.2-3] M: RVU-S An RVU server shall create a channel by connecting to the RVU client via a TCP socket.
[4.2-4] M: RVU-S, RVU-C An RVU element shall consider a channel to be a command channel if the first byte sent on the channel is a ‘<‘ character.
[4.2-5] M: RVU-S, RVU-C An RVU element shall not include any leading whitespace prior to the '<' character on a command channel. Note: Between successive frames on a command channel, an RVU element may include a CRLF.
[4.2-6] M: RVU-S, RVU-C An RVU element shall consider a channel to be a data channel if the first byte sent on the channel is an ASCII decimal digit from 0 through 9.
[4.2-7] M: RVU-S, RVU-C If the first byte sent on a channel is neither a ‘<’ nor an ASCII decimal digit 0 through 9, the RVU element receiving the byte shall close the channel as invalid.
[4.2-8] M: RVU-C An RVU client shall use the server’s port number obtained when the RUI connection was established as the destination port number.
[4.2-9] M: RVU-S An RVU server shall use the port number sent by the client to the server in the Hello command of the first channel opened in the session as the destination port number.
Note that this implies that the first channel opened in a session must be a command channel opened by the client (so the client can tell the server what destination port number to use when the server opens a channel).
[4.2-10] M: RVU-S, RVU-C An RVU element shall identify each channel (whether it is command or data) by a channel ID that is unique within each session (but does not need to be globally unique).
[4.2-11] M: RVU-S If an RVU server receives a new channel connection with a channel ID that is identical to the channel ID in a Hello message that the server has just sent, the RVU server shall reject the received Hello message, close the channel on which the Hello message was sent, and re- initiate using the same channel ID.
V1.0 Rev 1.5.1 37 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.2-12] M: RVU-C If an RVU client receives a new channel connection with a channel ID that is identical to the channel ID in a Hello message that the client has just sent, the RVU client shall reject the received Hello message, close the channel on which the Hello message was sent, and re- initiate using a different channel ID.
Note: 4.2-11 and 4.2-12 resolve issues that might surface due to a race between two endpoints initiating new channels with identical channel IDs. Both sides need to reject the received Hello message, close the just-initiated channel and re-initiate. This applies equally to command and data channels. An RVU element should be able to handle another RVU element closing the channels, and should not assume which channels are persistent. An RVU element can close a channel when it is no longer needed.
[4.2-13] M: RVU-S, RVU-C An RVU element shall have the ability to close a channel at any time by closing the TCP socket.
[4.2-14] M: RVU-S, RVU-C An RVU element shall discard any content received that is not a complete command frame on a command channel.
[4.2-15] M: RVU-S, RVU-C An RVU element shall discard any content received that is not a complete data frame on a data channel.
[4.2-16] M: RVU-S, RVU-C An RVU element shall deallocate any resources referencing a device when the last command channel to that device is closed. Note: this closes the session.
[4.2-17] S: RVU-S, RVU-C An RVU element should utilize TCP keepalive on each TCP stream to detect a disconnect on a quiescent (idle) channel.
[4.2-18] S: RVU-S, RVU-C An RVU element should detect a disconnection in a quiescent channel within 10 seconds of the disconnection.
[4.2-19] M: RVU-S, RVU-C Upon receiving an incoming TCP connection (creating a channel), the receiving RVU element shall not send any command or data frame on that channel until the initiator has transmitted the necessary Hello command or data frame.
[4.2-20] M: RVU-S, RVU-C A Hello (on a command channel or data channel) shall only be sent as the first command/data frame on that channel, and only by the RVU element that created the channel.
[4.2-21] M: RVU-S An RVU server shall utilize the UPnP device description UDN element (which includes the “uuid:” string and element value) received in a client originated Hello command to uniquely associate a RUI channel with a specific UPnP media renderer device. For example, this may occur when two different UPnP Media Renderer devices are using the same IP address.
V1.0 Rev 1.5.1 38 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.2.1 Command Channels
[4.2.1-1] M: RVU-S, RVU-C An RVU element shall send all commands on command channels as command frames.
[4.2.1-2] M: RVU-S, RVU-C An RVU element shall send command frames as XML strings formatted as follows:
The XML string begins with the command name, which is a string. The XML string must have a commandToken attribute. commandTokenValue is a string representation of a non-negative, 31-bit integer (int32_t, disallowing negative values), and is unique per RVU-element within the session for a period of at least 10 seconds (i.e., the same commandToken is not used on any command channel for at least 10 seconds). The XML string may also have one or more additional attributes. attributeNames are strings. attributeValues are formatted depending on the command.
[4.2.1-3] M: RVU-S, RVU-C When an RVU element receives a command, the element shall send a response on the same command channel back to the sender of the command. Note: The time at which a response is sent depends on the command itself; see section 4.4, Timing.
[4.2.1-4] M: RVU-S, RVU-C The RVU element's response shall be sent as a response command frame.
[4.2.1-5] M: RVU-S, RVU-C An RVU element's response command frame shall be an XML string, formatted as follows:
The XML string begins with the command name string “Response”. The XML string must have an errCode attribute. errorCodeValue is a string. The XML string must have a commandToken attribute. commandTokenValue must be the same string representation of the integer that appears in the original command. The XML string may have zero or more additional attributes. attributeNames are strings. attributeValues are formatted depending on the original command.
V1.0 Rev 1.5.1 39 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.2.1-6] M: RVU-S, RVU-C The first command sent on a command channel by an RVU element shall be the Hello command.
[4.2.1-7] M: RVU-S, RVU-C An RVU element shall not send the Hello command at any time other than the first command on a command channel.
[4.2.1-8] M: RVU-S, RVU-C If the Hello command is sent at any time other than the first command on a command channel, the RVU element receiving the command shall return ERR_INVALID_STATE.
[4.2.1-9] M: RVU-S, RVU-C An RVU element shall have the ability to send and receive commands on command channels asynchronously; a server or client may send other commands before previously-sent commands are completed.
[4.2.1-10] M: RVU-S, RVU-C An RVU element shall process commands received on any one command channel in the order sent and received. In other words, an RVU element shall not start to process a command until processing is complete on all previously received commands on the same channel.
[4.2.1-11] M: RVU-S, RVU-C An RVU element shall have the ability to process commands received on different command channels asynchronously, i.e. in any order, while preserving order for commands on any one command channel, per the previous requirement.
[4.2.1-12] M: RVU-S An RVU server shall have the ability to send commands via a command channel to the client (e.g., graphics commands)
[4.2.1-13] M: RVU-C An RVU client shall have the ability to send commands via a command channel to the server (e.g., key event commands)
[4.2.1-14] M: RVU-C, RVU-S An RVU element shall respond to a command that it does not implement by returning the commandToken and errCode, as described in the following table.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode ERR_COMMAND_NOT_IMPLEMENTED. string
Table 4-1: Command not implemented response attributes
4.2.2 Data Channels
[4.2.2-1] M: RVU-S, RVU-C The first data sent on a data channel by an RVU element shall be the Hello data frame.
V1.0 Rev 1.5.1 40 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.2.2-2] M: RVU-S, RVU-C An RVU element shall not send the Hello data frame at any time other than the first frame on a data channel.
[4.2.2-3] M: RVU-S, RVU-C If the Hello data frame is sent at any time other than the first frame on a data channel, the RVU element receiving the data frame shall discard the data frame as invalid.
[4.2.2-4] M: RVU-S, RVU-C An RVU element shall specify the channel ID of the data channel in the Hello data frame.
[4.2.2-5] M: RVU-S, RVU-C An RVU element shall have the ability to send and receive content on data channels asynchronously (since the commands that use the data are asynchronous).
[4.2.2-6] M: RVU-S, RVU-C DELETED.
[4.2.2-7] M: RVU-S, RVU-C An RVU element shall have the ability to process content received on different data channels asynchronously, i.e. in any order.
[4.2.2-8] M: RVU-S An RVU server shall have the ability to send data via a data channel to the client (e.g., graphics).
[4.2.2-9] M: RVU-C An RVU client shall have the ability to send data via a data channel to the server.
[4.2.2-10] M: RVU-S, RVU-C An RVU element shall send all data on data channels as data frames.
[4.2.2-11] M: RVU-S, RVU-C An RVU element shall send data frames with the syntax defined in Table 4-2 and Table 4-3.
Syntax Bits Format Comment RVU-RUI-Data-Frame() { frame-header { frame-header-len 32 ASCII-coded decimal 4-digits, 0 padded separator1 8 0x20 frame-type-id 8*number of chars ASCII characters separator2 8 0x20 command-token 8*number of digits ASCII-coded decimal separator3 8 0x20 frame-data-len 8*number of digits ASCII-coded decimal CRLF1 16 0x0D0A } frame-data 8*frame-data-len uimsbf CRLF2 16 0x0D0A }
V1.0 Rev 1.5.1 41 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Table 4-2: Data Channel Syntax
Field Definition frame-header-len This 4-byte field specifies the length of the entire frame header. The field is encoded as an ASCII-encoded 4-digit number (with zero padding if necessary). frame-type-id This field of characters specifies the type of data in this frame (e.g., “Hello”, “PixelData”, “AudioData”, etc.). command-token This field specifies an integer that matches the CommandToken attribute value specified in a corresponding command frame. If this data is unassociated with any command, the value of this field is 0. The field is encoded as an ASCII-encoded number. frame-data-len This field specifies the length of the frame-data field. The length does not include the last CRLF bytes in the data frame. The field is encoded as an ASCII-encoded number. frame-data This variable-byte field contains the data associated with the appropriate RUI command. The number of bytes in this field is specified by the frame-data-len field defined in the data-frame header.
Table 4-3: Data Channel Field Definitions
4.3 Session Startup and Teardown Sequences
4.3.1 Session Startup
[4.3.1-1] M: RVU-C The RVU client shall have the ability to initiate a session.
[4.3.1-2] M: RVU-C Once a RUI connection between a server and client has been established (see Session Management, section 3), an RVU client shall allocate resources needed to support a session.
[4.3.1-3] M: RVU-C After allocating resources, an RVU client shall open a channel to the server (using the server's destination port obtained from the RUI connection process), and tell the server the client port number to use for additional channels. (Note: the server does not have the ability to initiate a session, as it would require the client's port number to do so.) An example appears below:
[4.3.1-4] M: RVU-S Upon receipt of the Hello command, an RVU server shall determine whether it can support another session.
[4.3.1-5] M: RVU-S If an RVU server determines that it cannot support another session, it shall return an ERR_NO_SESSION error code response to the initiating client. Note: No session is established in this case.
V1.0 Rev 1.5.1 42 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.3.1-6] M: RVU-S If an RVU server determines that it can support another session, it shall allocate the resources needed to support that session.
[4.3.1-7] M: RVU-S If an RVU server determines that it can support another session, it shall return an ERR_SUCCESS response to the initiating client. An example is:
[4.3.1-8] M: RVU-S, RVU-C Once a session has been established per the above steps, an RVU element shall have the ability to open a command channel and send a Hello command.
[4.3.1-9] M: RVU-S, RVU-C Once a session has been established per the above steps, an RVU element shall have the ability to open a data channel and send a Hello data frame.
Note: The following is an example of a Hello data frame (in hexadecimal notation):
303031362048656c6c6f203020310D0A360D0A which is parsed as follows:
frame_header_length (4 bytes) = 0x30303136 (“0016”) first separator (1 byte) = 0x20 (“ “) frame_type_id (5 bytes) = 0x48656c6c6f (“Hello”) second separator (1 byte) = 0x20 (“ “) command_token (1 byte) = 0x30 (“0”, not associated with a command) third separator (1 byte) = 0x20 (“ “) frame_data_length (1 byte) = 0x31 (“1”) first CR/LF (2 bytes) = 0x0D0A frame_data (1 byte) = 0x36 (“6”, the channel ID) second CR/LF (2 bytes) = 0x0D0A
V1.0 Rev 1.5.1 43 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
An example of the RUI startup sequence is shown in Figure 4-1 below.
Client Server
Allocate RUI resources
Can support Send Hello with Hello command another client’s RUI port session? Yes
No
No session Response: Send “No Session” established. Done. ERR_NO_SESSION error code
No session established. Done.
Allocate RUI resources
Create other Response: Send “Success” error channels as needed ERR_SUCCESS code
Create other channels as needed
Figure 4-1: Session Startup Sequence
4.3.2 Session Teardown A session may be torn down by either a client or a server. The client may wish to close the session in order to terminate the UI and use it for a local application. The server may wish to terminate the session for any number of reasons.
[4.3.2-1] M: RVU-S, RVU-C An RVU element shall have the ability to tear down a session.
[4.3.2-2] M: RVU-S, RVU-C When an RVU element tears down a session, all associated channels shall be terminated.
[4.3.2-3] M: RVU-S, RVU-C An RVU element that is shutting down all channels to terminate the session shall send a Shutdown command.
[4.3.2-4] M: RVU-S, RVU-C DELETED.
V1.0 Rev 1.5.1 44 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.4 Timing When a command is sent on a command channel, its associated data is expected to arrive on a data channel immediately after the command is sent on the command channel. Since this does not always occur, limitations are placed upon the timing of command and data synchronization. Although the server may send a data frame prior to sending the associated command, best practices should cause commands to be sent before associated data frames. This obviates the need for the client to store large data frames while waiting for a command to be received, or delay consuming data off of a data channel, possibly triggering timeout conditions while waiting for a command to be sent following the data frame. Also, independent content should be sent on multiple data channels asynchronously, so that the transmission of data on one channel (which may block because of TCP transmission rules) does not delay the transmission of data on other channels.
[4.4-1] M: RVU-S, RVU-C An RVU element that is expecting data from a data channel shall return a command response with an error code of ERR_TIMEOUT_CHANNEL if the referenced data channel has not been connected and identified within one second of the element having received the command.
[4.4-2] M: RVU-C An RVU element that is expecting data from a data channel shall return a command response with an error code of ERR_TIMEOUT_DATA if the complete data frame header has not been received on the referenced data channel within one second of the element having received the command.
[4.4-3] M: RVU-S, RVU-C An RVU element that is processing a command which expects data from a data channel shall return a command response with an error code of ERR_TIMEOUT_DATA if the entire data frame content has not been received within five seconds of receipt of the header unless the RVU element chooses to use a stream-like interpretation of the data (as for the Play command).
[4.4-4] M: RVU-S, RVU-C An RVU element that receives a data frame that is not associated with any command shall hold that frame for one second.
[4.4-5] M: RVU-S, RVU-C An RVU element shall discard a data frame if that frame is not associated with any command and has been held for one second.
[4.4-6] M: RVU-S, RVU-C An RVU element shall process a data frame that was received prior to its associated command if the command is received within one second (i.e., before the data frame is discarded).
[4.4-7] O RVU-S, RVU-C If a command frame associated with a large data frame is found to trigger an error condition, an RVU element may close the data channel in order to stop the data transfer. Note that this channel may be closed by either the element sending or the element receiving the data.
V1.0 Rev 1.5.1 45 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.4-8] M: RVU-S, RVU-C If a command frame associated with a large data frame is found to trigger an error condition, and the data channel is not closed in order to stop the data transfer per 4.4-7, an RVU element shall continue to consume the data frame (in order to maintain framing on the data channel).
[4.4-9] M: RVU-S, RVU-C An RVU element that is processing a non-queued command which does not expect data from a data channel shall return a valid command response within one second of the element having received the command.
[4.4-10] M: RVU-S, RVU-C An RVU element that is processing a queued command which does not expect data from a data channel shall return a valid command response within one second of the element having received the Dispatch or BlitQueue (disable queuing) command.
4.5 Buffers The following terms are used in this section:
buffer: an off-screen graphics buffer. display buffer: the (single) on-screen graphics buffer. To support separate left and right eye/view graphics while in a 3DTV structure, the client shows the contents of the display buffer at non-overlapping positions to each eye, as specified by the ReconfigureDisplayBuffer3DTV command. The ReconfigureDisplayBuffer3DTV command is used to indicate the left and right eye graphics regions within the display buffer. output: the rendering device. video buffer: a region of the screen used to display video provided by a UPnP/AV session. z-list: the ordering of display buffer and video buffers when displayed on the output. The first item in the list is displayed on the top output layer. ARGB-32: A big-endian 32-bit packed color, with 8 bits for each of Alpha, Red, Green, Blue. ARGB-32, as used throughout this specification, is transmitted with the transparency information pre-multiplied (that is, the transparency indicated by the alpha channel is pre- multiplied through the red, green, and blue channels to speed blending operations). This pre-multiplication applies to pixel buffer data, colors specified for blending, CLUT entries, etc. Flatten 3DTV Structure: Only the left or right eye image is rendered on both the left and right eye images on the output. Effectively removes any perception of depth produced by different left and right eye images. Frame Packing 3DTV Structure: provides full resolution for each eye/view where separate frames provide the left-eye image and the right-eye image. These frames may be coded in (a) different streams/layers in a time-synchronous manner or (b) temporally multiplexed in a single stream where frames with the left-eye image always occurring first in the pair. Side-by-Side 3DTV Structure: provides half resolution for each eye/view where every frame is composed of a left-eye image on the left half of the frame and right-eye image on the right half of the frame. The spatially multiplexed images within the frame are time- synchronous and are oriented without any inversion or mirroring.
V1.0 Rev 1.5.1 46 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Top-and-Bottom 3DTV Structure: provides half resolution for each eye/view where every frame is composed of a left-eye image on the top half of the frame and right-eye image on the bottom half of the frame. The spatially multiplexed images within the frame are time- synchronous and are oriented without any inversion or mirroring. The video buffer is subject to shared control between the client and server. RUI provides the server with information about the video capabilities of the client, the aspect ratio of the client, the output resolution of the client, and (in a full-screen video case) the resolution / position of the video buffer in the display. This is necessary to deal with interactions between UI and video when the client can control letterbox/pillarbox, stretch, crop, and so on. Only one video buffer is required.
In addition to the display buffer and any video buffers, there are implicit buffers for Closed Captioning data (logically in front of all entries in any Z-list), background color (logically, behind all entries in any Z-list, and generally solid black), and any additional local UI for interacting with the local hardware. Local UI is rendered on top of all other buffers; a client implementation may stop displaying the RUI display buffer whenever local UI operations are being performed. The RUI server has no explicit control over any of the buffers that are not in the Z-list. Instead, they are completely controlled by the internal logic of the RVU client.
It is assumed there are two varieties of local UI operations: those that affect the operation of the currently-running remote UI application (changing video settings, closed captioning, display settings, etc), and those that run outside of the remote UI application (applications local to the device, terminating the remote UI application). Those that affect the current operation may be requested by the remote UI (for instance, while performing configuration); those that operate outside the remote UI are always subject to the application logic of the client device.
[4.5-1] M: RVU-C When a session begins between a server and client, an RVU client shall define one graphics display buffer.
[4.5-2] M: RVU-C An RVU client shall assign a buffer ID of 0x7fffffff for the graphics display buffer.
[4.5-3] M: RVU-C An RVU client shall automatically add the graphics display buffer to the Z-List when a session begins.
[4.5-4] M: RVU-C An RVU client shall allow more graphics buffers to be allocated by using the AllocateBuffer command, described in the Commands section below.
[4.5-5] M: RVU-C An RVU client shall only use the graphics display buffer with a buffer ID of 0x7fffffff for screen display of graphics (i.e., buffers created by the AllocateBuffer command are never displayed on the screen).
[4.5-6] M: RVU-C An RVU client shall prevent screen tearing and other display artifacts when displaying any data written to the graphics display buffer.
V1.0 Rev 1.5.1 47 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.5-7] M: RVU-C An RVU client shall display the display buffer and the video buffer(s) in the z-order defined in the Z-list.
Note: The display order of the buffers may be obtained via the GetZList command and the display buffer order may be changed via the SetZList command for clients that support the SetZList command. Otherwise, the background is always behind the video buffer, which is in- turn always behind the display buffer.
[4.5-8] M: RVU-C An RVU client that transitions from displaying a client-native menu to a server-controlled menu shall continue to display the last client-native menu until the display buffer is updated by the server using RUI graphic commands..
4.6 Audio
[4.6-1] M: RVU-S When an audio decoder is needed, an RVU server shall determine how many total audio decoders exist on a client by sending the GetNumAudioDecoders command to the client.
Note 1: This command responds with the number of decoders available for use by the RUI, and does not include additional decoders that may be used for program audio.
Note 2: RUI audio is not protected content, therefore is it not encrypted.
[4.6-2] M: RVU-C An RVU client shall respond to the GetNumAudioDecoders command with a minimum of one (1) audio decoder.
[4.6-3] M: RVU-C An RVU client shall allocate a minimum of 1 MByte for the RUI audio buffer.
[4.6-4] M: RVU-S Once an RVU server has determined the total number of audio decoders on the client, the server shall query each of the client’s audio decoders one by one (from 0 through num_decoders-1) via the GetAudioDecoderCaps command to determine which audio decoder to use for playing an audio sample.
[4.6-5] M: RVU-S Once an audio decoder has been identified, an RVU server shall send the OpenAudioDecoder command to obtain a reference to that decoder.
[4.6-6] M: RVU-S An RVU server requesting audio to be played shall send a command to play the audio (via a Play or PlayBuffer command).
[4.6-7] M: RVU-C After an RVU client receives a Play command, it shall wait for the entire audio sample to be received. Note: a PlayBuffer command does not require a waiting period as the audio data is already present in the referenced buffer.
V1.0 Rev 1.5.1 48 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.6-8] M: RVU-C If an RVU client receives the Play command, the client shall retrieve content from the associated data channel.
[4.6-9] M: RVU-C If an RVU client receives the PlayBuffer command, the client shall retrieve content from the referenced audio buffer.
[4.6-10] M: RVU-C When data transfer is complete (or already exists in the case of the PlayBuffer command), the RVU client shall return a PlayStatus command with a status attribute value of TransferComplete to the requestor.
[4.6-11] M: RVU-C After receiving a Play or PlayBuffer command and returning the PlayStatus command, a client shall then proceed to play the audio sample.
[4.6-12] M: RVU-C When the complete audio sample has been played, an RVU client shall return a PlayStatus command with a status attribute value of SampleComplete to the requestor.
[4.6-13] M: RVU-S After requesting one audio playback, an RVU server shall have the ability to send subsequent Play or PlayBuffer commands to continue an audio stream.
[4.6-14] M: RVU-S Subsequent audio commands sent by the requesting RVU server (meaning the audio data is considered to be on the same audio stream) shall have the same configureId attribute value as that returned via the response of the original Play or PlayBuffer command.
[4.6-15] M: RVU-S The RVU server requesting audio shall have the ability to stop playback of audio at any time by sending a Stop command.
[4.6-16] M: RVU-C An RVU client shall have the ability to mix program and RUI audio content, as RUI audio plays concurrently with program audio, minimally, PCM program audio and PCM RUI audio.
4.7 User Inputs
4.7.1 Key Event Commands Two sets of key identifiers are provided for returning key events from the client to the server: HDMI and CDI. While a mechanism is provided for transmitting keys from RVU client to RVU server, the interpretation of those keys is wholly up to the application running on the RVU server.
A key identifier, key code, or key value in the specification refers to value listed in Table 4-19 that a client sends to a server within an HDMIKeyEvent or CDI key event command and has been translated to that value in response to client user input.
V1.0 Rev 1.5.1 49 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
A key or user input is a labeled button on a remote control, front panel button or other means to register client user input.
[4.7.1-1] M: RVU-S An RVU server shall support HDMI key identifiers (for details, see the HDMI specification, [Ref16]).
[4.7.1-2] O: RVU-S An RVU server may support CDI key identifiers listed in Table 4-19.
[4.7.1-3] O: RVU-C If CDI key identifiers are implemented, an RVU client shall implement all mandatory CDI key identifiers listed in Table 4-19.
[4.7.1-4] M: RVU-C An RVU client shall implement all mandatory HDMI key identifiers listed in Table 4-19.
[4.7.1-5] O: RVU-C A client that supports CDI may send its first key event to the server via a CDIKeyEvent command.
[4.7.1-6] M: RVU-S Upon receipt of a CDIKeyEvent, an RVU server that does not support CDI shall return an ERR_KEY_FAILED to the client in the CDIKeyEvent command response.
[4.7.1-7] M: RVU-C An RVU client that receives an ERR_KEY_FAILED response to the first CDIKeyEvent that it sends to an RVU server shall resend the key event using the HDMIKeyEvent command (which is supported by all servers).
[4.7.1-8] M: RVU-C Once a key event command is successful, an RVU client shall send all subsequent key events using that same command (either HDMIKeyEvent or CDIKeyEvent).
[4.7.1-9] M: RVU-S If a session has been using HDMI key events, and the client sends a CDI key event, the RVU server shall return an ERR_KEY_FAILED to the client in the command response, even if the server has the capability of processing that command.
[4.7.1-10] M: RVU-S If a session has been using CDI key events, and the client sends an HDMI key event, the RVU server shall return an ERR_KEY_FAILED to the client in the command response.
4.7.2 Security RUI provides the optional capability of encrypting the channel used to send key events. This is useful if a server application requires input of sensitive information such as passwords or credit card numbers. An RVU element determines whether encryption is supported with the initial Hello command and response of the session.
V1.0 Rev 1.5.1 50 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.7.2-1] O: RVU-S, RVU-C An RVU element may have the capability of using Transport Layer Security (TLS) on a command channel that sends key event commands (for details on TLS, see RFC 4366, [Ref19]).
[4.7.2-2] M: RVU-C An RVU client that supports TLS shall include a tlsPort attribute in the initial Hello command.
[4.7.2-3] M: RVU-S If an RVU server receives a Hello command indicating the client supports TLS, the server also supports TLS, and there are no other TLS channels open for the session, the server shall open a command channel using the given tlsPort.
[4.7.2-4] M: RVU-S If an RVU server receives a Hello command indicating the client supports TLS, but the server either does not support TLS or already has another TLS channel open for the session, the server shall open a command channel using the given callbackPort instead of the tlsPort.
[4.7.2-5] M: RVU-S If an RVU server sets up a command channel using TLS, the server shall perform the TLS handshake and setup on that channel.
[4.7.2-6] M: RVU-C If a TLS channel has been successfully opened, an RVU client shall send key event commands on that channel, which will be encrypted.
[4.7.2-7] M: RVU-C If an RVU server sets up a command channel using TLS, but the handshake fails to successfully open the channel, the RVU client shall make two additional attempts to establish a TLS channel.
[4.7.2-8] M: RVU-C If the TLS channel cannot be established after three attempts, the RVU client shall inform the user that the TLS channel cannot be established.
4.8 Commands
4.8.1 Summary This section provides summaries of all RUI commands, organized by category. Each summary includes the data type, if any, that each command expects from the specified data channel.
The specifics of the sending, processing, and responses for each command are detailed in section 4.8.2 Command Details.
4.8.1.1 Setup, Teardown, and Info
Command Description Data Type Hello Sets up information needed to define a command or a None data channel.
V1.0 Rev 1.5.1 51 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Command Description Data Type Shutdown Provides notification that the session’s other endpoint is None terminating. GetMemInfo Retrieves information about memory resources and None allocations.
Table 4-4: Setup, Teardown, and Info commands
4.8.1.2 User Input
Command Description Data Type HDMIKeyEvent Indicates via HDMI format that a remote key was pressed None (and specifies which key it was). CDIKeyEvent Indicates via CDI format that a remote key was pressed None (and specifies which key it was). This command is optional. GetKeyList Retrieves information about which key codes are None supported by the client.
Table 4-5: User Input commands
4.8.1.3 Graphics Graphics commands deal with the writing of new pixel data, allocation of buffers, and blit operations between buffers, and the reporting of supported graphics and video formats.
Command Description Data Type AllocateBuffer Allocates a new graphics buffer. None DeallocateBuffer Deallocates a graphics buffer previously allocated None from an AllocateBuffer call. Write Writes data to a graphics buffer. PixelData Read Reads data from a graphics buffer. PixelData BlitQueue Specifies that all blit commands are to be queued None up and not executed until specified to do so (via a Dispatch command). Dispatch Specifies that all queued blit commands are to be None executed. EmptyQueue Erases queued commands. None WaitVSync Waits for client to enter a vertical resync period. None CopyBlit Performs a copy of pixel data. None FillBlit Performs a write of a constant color. None ResizeBlit Performs a scaling copy of pixel data. None ShadeBlit Performs a Porter-Duff blending operation with None constant color on pixel data. BlendBlit Performs a Porter-Duff blending operation with two None blocks of pixel data and stores the result in one of the pixel data blocks. V1.0 Rev 1.5.1 52 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Command Description Data Type MultiSourceBlendBlit Performs a Porter-Duff blending operation with two None source buffers and stores the result in one destination buffer. ResizeAndBlendBlit Performs a BlendBlit with two blocks of pixel data, None scales the result, and stores it in one of the pixel data blocks. ColorKeyResizeBlit Performs a copy or resize operation, along with a None conditional operation based on comparing each pixel to a constant color. GetGraphicsCaps Returns information about supported blit operations, None video formats and other graphics parameters. GetZList Gets current order of all display buffers. None SetZList Sets order of all display buffers. None SetCLUT Writes a color look-up table (CLUT) to a graphics CLUT buffer.
Table 4-6: Graphics commands
4.8.1.4 Local UI Local UI commands are used to transfer control of the UI on the client from the server to the client, and from the client back to the server. See section 6 for a description of the use of these commands and local UI requirements.
Command Description Data Type ListLocalUIElements Lists the set of locally-generated UI elements that None are available on the client. RequestLocalUI Requests a locally-generated UI element. None LocalUIEvent Notifies server that a client is entering or exiting a None local UI operation. ClientRequestLocalUI Client requests control of the UI from the server. None
Table 4-7: Local UI commands
4.8.1.5 Display Display commands manipulate one (or more) video buffers.
Command Description Data Type GetVideoBuffer Ties an existing AV stream with a buffer on the None client display. ReleaseVideoBuffer Releases control/interest in a video buffer acquired None with GetVideoBuffer. SetBackgroundColor Sets the default color for display regions that are None not occluded by the display buffer or a video buffer. ConfigureDisplayBuffer Configures the display buffer. None
V1.0 Rev 1.5.1 53 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Command Description Data Type ReconfigureDisplayBuffer Reconfigures the display buffer. None ConfigureVideoFullscreen Configures full-screen display of an AV stream. None ConfigureVideoWindow Configures windowed display of an AV stream. None ConfigureWindowedVideoWindow Configures the windowed display of a portion of an None AV stream. ConfigureVideoDecodeResolution Configures the maximum output resolution None decimation on a video buffer. BlindVideo Enables and disables blinding of an AV stream. None GetOutputSettings Determines the output display resolution. None OutputSettingsChanged Notifies server of a change to display resolution None settings, or to send GetGraphicsCaps command. GetVideoDisplaySettings Determines current aspect ratio, display position, None native decoded resolution, and decimated resolution of a video buffer. VideoDisplaySettingsChanged Notifies server of a change to the video buffer None display settings. AllowClosedCaptioning Allows closed captioning to be displayed on the None client, if the client has enabled it locally. EnableClosedCaptioning Enables/disables closed captioning on the local None device. GetClosedCaptioningState Determines the state of closed captioning on the None local device. ReconfigureDisplayBuffer3DTV Reconfigures the display buffer to accommodate None left and right eye regions. The specified 3DTV structure also indicates the timing and pixel arrangement for the decoded AVC 3D video buffer to create a stereoscopic video pictures. Set3DTVFlattenStructure Sets the state of flattening of the 3DTV video on the None client device.
Table 4-8: Display commands
4.8.1.6 Audio
Command Description Data Type OpenAudioDecoder Opens an audio decoder to play audio. None CloseAudioDecoder Closes the specified audio decoder. None GetNumAudioDecoders Gets the total number of audio decoders. None GetAudioDecoderCaps Gets information about the capabilities of an audio None decoder. AllocateAudioBuffer Allocates a new audio buffer. None DeallocateAudioBuffer Deallocates an audio buffer previously allocated None from an AllocateAudioBuffer call. WriteAudioData Writes audio obtained from a data channel. AudioData
V1.0 Rev 1.5.1 54 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Command Description Data Type Play Plays audio obtained from a data channel. AudioData PlayBuffer Plays audio from a specified audio buffer. None PlayStatus Returns status of audio play started by an earlier None Play or PlayBuffer command. Stop Stops audio play started by an earlier Play or None PlayBuffer command.
Table 4-9: Audio commands
4.8.2 Command Details This section describes all RUI commands in detail.
4.8.2.1 Setup, Teardown, and Info Commands in this section are used to set up and tear down RUI channels.
4.8.2.1.1 Hello The Hello command is sent as the first command on a command channel, and is not sent again on that channel. It is used to indicate the type of channel (command) and the channel ID of the channel.
[4.8.2.1.1-1] M: RVU-S, RVU-C An RVU element shall have the ability to send the Hello command as described in the following table.
Server Client Description Type Originated Originated Attributes Attributes commandToken commandToken A unique ID representing this command. uint channelId ChannelId The ID of this channel. uint callbackPort callbackPort The callback port number to use when creating new uint channels. Per 4.2-9, this is the port number from the 1st hello command in the session. tlsPort tlsPort Optional uint The port to use when creating a new TLS channel (See section 4.7.2). version version The supported RVU specification version number. string n/a UDN Optional string The value of the client’s UPnP Media Renderer device UDN element (see 4.2-21).
Table 4-10: Hello command attributes
[4.8.2.1.1-2] M: RVU-S, RVU-C An RVU element shall respond to the Hello command by returning the commandToken and appropriate errCode, as described in the following tables. V1.0 Rev 1.5.1 55 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-11: Hello response attributes
Error Codes
Error Code Description ERR_SUCCESS No other commands have been received on this channel, and this has properly been identified as a command channel. ERR_INVALID_STATE This is not the first command on this channel or the channel has been identified as a data channel. ERR_NO_SESSION This is the first channel started between two devices, thus implying that a session is to be started, but the responding device does not have the resources to create a new session. ERR_NO_CHANNEL The responding device does not have resources to create a new channel. ERR_BAD_ID The version numbers of the two devices are incompatible. ERR_INVALID_PORTNUM The callback port number doesn’t match the port from the 1st hello command in the session.
Table 4-12: Hello response error codes
4.8.2.1.2 Shutdown The Shutdown command is sent to indicate that the endpoint is terminating, that no additional commands should be dispatched, and that no additional channels should be connected.
[4.8.2.1.2-1] M: RVU-S, RVU-C An RVU element shall have the ability to send the Shutdown command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint reason Optional string See error code table below.
Table 4-13: Shutdown command attributes
Reason Codes
Reason Code Description SHUTDOWN_NORMAL Client terminating as part of normal processing, e.g. application exit or entering standby. SHUTDOWN_ERROR Client detected error requiring termination, e.g. invalid data on a channel or channel ID conflict.
V1.0 Rev 1.5.1 56 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Reason Code Description SHUTDOWN_FATAL_ERROR Client detected error requiring exit, in the process terminating the session. SHUTDOWN_SOFT_RESET Client performs a soft reset, in effect exiting, and therefore terminating all sessions. SHUTDOWN_SERVER_COMMANDED_RESET Client performs a reset as a result of command from the server SHUTDOWN_SOFTWARE_UPGRADE Client performs a reset as a result of an upgrade to its software image Table 4-14 Shutdown command reason codes
[4.8.2.1.2-2] M: RVU-S, RVU-C An RVU element shall process the Shutdown command by ceasing the flow of commands on all channels associated with the endpoint that sent the Shutdown command (with the exception of the Shutdown command response).
[4.8.2.1.2-3] M: RVU-S, RVU-C An RVU element shall respond to the Shutdown command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-14: Shutdown response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-15: Shutdown response error codes
4.8.2.1.3 GetMemInfo The GetMemInfo command is used to retrieve information about the memory resources and allocations in the system.
[4.8.2.1.3-1] M: RVU-S An RVU server shall have the ability to send the GetMemInfo command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-16: GetMemInfo command attributes
V1.0 Rev 1.5.1 57 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.1.3-2] M: RVU-S, RVU-C An RVU element shall respond to the GetMemInfo command by returning the commandToken, memory information, and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string maxGraphicsMemory The maximum number of bytes that can be allocated in uint response to AllocateBuffer commands. curGraphicsMemory The current number of bytes still available for graphics uint allocations. maxGraphicsAllocations The number of allocations (graphics buffers) that can be int allocated. -1: The number of allocations is bound only by available memory curGraphicsAllocations The number of allocations (graphics buffers) that have been uint allocated. maxAudioMemory The maximum number of bytes that can be allocated in uint response to AllocateAudioBuffer commands. curAudioMemory The current number of bytes still available for allocation. uint maxAudioAllocations The number of allocations (audio buffers) that can be int allocated. -1: The number of allocations is bound only by available memory curAudioAllocations The number of allocations (audio buffers) that have been uint allocated. memoryShared 0: separate memory pools are used for graphics and audio uint allocations. Non-zero: graphics and audio buffer allocations share a memory pool. allocationCountShared If memoryShared is non-zero, number of allocations uint available shared between graphics and audio buffers. 0: separate (or unlimited) allocations. Non-zero: one fixed static pool of allocations.
Table 4-17: GetMemInfo response attributes
Error Codes
Error Code Description ERR_SUCCESS No other commands have been received on this channel, and the channel was identified as a command channel. ERR_INVALID_STATE This was not the first command on this channel, or the channel was identified as a data channel.
Table 4-18: GetMemInfo response error codes
V1.0 Rev 1.5.1 58 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.2 User Input Commands in this section are used to process user input.
The following key values are defined for the Key Event commands.
Remote HDMI User HDMI HDMI CDI Comment Key Function1 Operation2 Operation Mandatory Key Value ID or Optional Select Select 0x00 M 0xE001 Up Up 0x01 M 0xE100 Down Down 0x02 M 0xE101 Left Left 0x03 M 0xE102 Right Right 0x04 M 0xE103 Menu Menu 0x0A M 0xE503 Channel Up Channel Up 0x30 M 0xE006 Channel Down Channel Down 0x31 M 0xE007 Numbers 0 – 9 Numbers 0 – 9 0x20 – M 0xE300 - 0x29 0xE309 Previous Previous 0x32 M 0xE504 Channel Enter Enter 0x2B M 0xE505 Dash Dot 0x2A M 0xE506 Play Play 0x44 M 0xE400 Stop Stop 0x45 M 0xE402 Pause Pause 0x46 M 0xE401 Record Record 0x47 M 0xE403 Rewind Rewind 0x48 M 0xE406 Fast Forward Fast Forward 0x49 M 0xE405 Advance Forward 0x4B M 0xE408 Advance playback by 30 seconds Jump Back Backward 0x4C M 0xE409 Rewind playback by 10 seconds Guide Electronic 0x53 M 0xE00B Program Guide Active N/A 0x913 O 0xE500 Interactive Portal List Contents Menu 0x0B M 0xE501 Display the Playlist Exit Exit 0x0D M 0xE502 Return to live TV or recorded playback Back N/A 0x903 O 0xE002 Back up one menu display Info Display 0x35 M 0xE00E Display information about Information selected program Blue F1 (Blue) 0x71 O 0xE203 Display the Mini-Guide
V1.0 Rev 1.5.1 59 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Remote HDMI User HDMI HDMI CDI Comment Key Function1 Operation2 Operation Mandatory Key Value ID or Optional Red F2 (Red) 0x72 M 0xE200 Backup Guide 12 hours, OR Delete selected playlist item Green F3 (Green) 0x73 O 0xE201 Advance Guide 12 hours, OR Select Audio Options Yellow F4 (Yellow) 0x74 O 0xE202 Select Guide Options, OR Select TV Options 1 PWR, Format,TV input, Mute, Volume Up and Volume Down are typical key functions handled by the client 2 Operation Names are taken from [Ref16], CEC Table 27 User Control Codes. 3 Since these key functions have no corresponding HDMI user operations, the operation IDs additions in the reserved range of [Ref16], CEC Table 27 User Control Codes.
Table 4-19: Key Assignments
4.8.2.2.1 HDMIKeyEvent The HDMIKeyEvent command is used to transmit information about a key event (e.g., a key press on a remote control) using HDMI key values.
The HDMI code listed in Table 4-19 is sent as a hex value in the keyVal attribute in the HDMIKeyEvent command. The Up/Down key press is communicated in the separate “event” attribute in the HDMIKeyEvent command.
[4.8.2.2.1-1] M: RVU-C An RVU client shall have the ability to send the HDMIKeyEvent command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint keyVal The operation ID as specified in the HDMI specification, [Ref16] hex in the CEC section table 27. event 1: key down event uint 0: key up event
Table 4-20: HDMIKeyEvent command attributes
[4.8.2.2.1-2] M: RVU-C The value contained in the keyVal attribute shall be one of those listed in the keyList attribute of the GetKeyList command.
[4.8.2.2.1-3] M: RVU-C The format of keyVal shall be 2 hex characters (0-9,A-F), where the alphabetic hex characters (A-F) are uppercase, and the 0x prefix is not included in the keyVal.
V1.0 Rev 1.5.1 60 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.2.1-4] M: RVU-S An RVU server shall process the keyVal sent in the HDMIKeyEvent command.
[4.8.2.2.1-5] M: RVU-S An RVU server shall respond to the HDMIKeyEvent command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-21: HDMIKeyEvent response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_KEY_FAILED The key could not be dispatched in a timely manner.
Table 4-22: HDMIKeyEvent response error codes
4.8.2.2.2 CDIKeyEvent The CDIKeyEvent command is used to transmit information about a key event (e.g., a key press on a remote control) using CDI key values.
The CDI code listed in Table 4-19 is sent as a hex value attribute in the CDIKeyEvent command. The Up/Down event is communicated using values of 0/1 in bit 16 of the keyVal attribute. For example,
CDI key down (press) for “Left” is sent as 0x1E102. CDI key up (release) for “Left” is sent as 0x0E102
[4.8.2.2.2-1] O: RVU-C An RVU client may have the ability to send the CDIKeyEvent command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint keyVal The keycode as defined in the CDI specification (see hex Table 4-19). Bit 16 in this key code shall be 1 for a key down event and 0 for a key up event.
Table 4-23: CDIKeyEvent command attributes
V1.0 Rev 1.5.1 61 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.2.2-2] M: RVU-C The value contained in the keyVal attribute shall be one of those listed in the keyList attribute of the GetKeyList command.
[4.8.2.2.2-3] M: RVU-C The format of keyVal shall be 5 hex characters (0-9,A-F), where the alphabetic hex characters (A-F) are uppercase, and the 0x prefix is not included in the keyVal.
[4.8.2.2.2-4] O: RVU-S An RVU server may process the keyVal sent in the CDIKeyEvent command.
[4.8.2.2.2-5] M: RVU-S An RVU server shall respond to the CDIKeyEvent command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-24: CDIKeyEvent response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_KEY_FAILED The key could not be dispatched in a timely manner.
Table 4-25: CDIKeyEvent response error codes
4.8.2.2.3 GetKeyList The GetKeyList command is used by the server to get the list of codes that the client is capable of translating from user input and sending to the server.
[4.8.2.2.3-1] M: RVU-S An RVU server shall have the ability to send the GetKeyList command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint keyFormat The format in which to list supported keys. Options are: string HDMI CDI
Table 4-26: GetKeyList command attributes
V1.0 Rev 1.5.1 62 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.2.3-2] M: RVU-C An RVU client shall respond to the GetKeyList command by returning the commandToken, key list, and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string keyList A comma-delimited list in hex integer format of codes that a string client can translate from user input and send to a server via HDMI/CDI KeyEvent commands.
Table 4-27: GetKeyList response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The server requested CDI and the client does not support the CDI key format.
Table 4-28: GetKeyList response error codes
4.8.2.3 Graphics Commands in this section are used to handle graphics display for the user interface. Graphics commands are sent by the server to generate menus and OSDs on the client formatted by the server. The client is required to allocate graphics buffers if it receives one or more AllocateBuffer commands, and then use Write, Fill, Shade, Copy and Blend commands to load display data into these buffers.
4.8.2.3.1 AllocateBuffer The AllocateBuffer command is used to allocate a graphics buffer of specified dimensions and pixel format. Graphics buffers can range from hundreds of bytes up to 16 Mbytes in size. These graphics buffers are dynamically allocated and de-allocated within a session. Information about the graphic memory capability and current allocations on the client is communicated to the server via the GetMemInfo command.
[4.8.2.3.1-1] M: RVU-S
An RVU server shall have the ability to send the AllocateBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint width The width of the requested buffer in pixels. uint height The height of the requested buffer in pixels. uint
V1.0 Rev 1.5.1 63 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type pixelFormat The pixel format. Options are: string CLUT-8: an unsigned 8-bit value representing an indirect pixel lookup index. The associated color lookup table (CLUT) for this buffer is defined as an array of 256 ARGB-32 elements. Note: the CLUT itself is not a graphics buffer, and is separately allocated and associated to the graphics buffer by the application. ARGB-32: an unsigned big-endian 32-bit value, with one 8-bit byte for each of Alpha, Red, Green, and Blue (with the Alpha byte located at the smallest address) color Optional hex The color with which to fill the buffer. Defaults to the value 0.
Table 4-29: AllocateBuffer command attributes
[4.8.2.3.1-2] M: RVU-C An RVU client shall process the AllocateBuffer command by creating a buffer of the requested size and format, and, if defined, color.
[4.8.2.3.1-3] M: RVU-C The RVU client shall allocate a minimum 64 Mbytes of memory to support the worst-case combination of graphic buffer allocation commands from the server.
[4.8.2.3.1-4] M: RVU-C An RVU client shall respond to the AllocateBuffer command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string bufId The ID of the new buffer. uint
Table 4-30: AllocateBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The buffer could not be created. ERR_BAD_CONFIG The format specified is unknown or not supported.
Table 4-31: AllocateBuffer response error codes
V1.0 Rev 1.5.1 64 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.3.2 DeallocateBuffer The DeallocateBuffer command is used to release a previously allocated buffer that was allocated via the AllocateBuffer command.
[4.8.2.3.2-1] M: RVU-S An RVU server shall have the ability to send the DeallocateBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The buffer to release. uint
Table 4-32: DeallocateBuffer command attributes
[4.8.2.3.2-2] M: RVU-C An RVU client shall process the DeallocateBuffer command by deallocating the specified buffer.
[4.8.2.3.2-3] M: RVU-C An RVU client shall respond to the DeallocateBuffer command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-33: DeallocateBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been allocated yet by the AllocateBuffer command or is the display buffer.
Table 4-34: DeallocateBuffer response error codes
4.8.2.3.3 Write The Write command is used to write pixel data into the display buffer or an allocated graphics buffer. The Write command only defines information about what and how to write the data. The data itself comes from content via an associated data channel.
[4.8.2.3.3-1] M: RVU-S An RVU server shall have the ability to send the Write command as described in the following table.
V1.0 Rev 1.5.1 65 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken A unique ID representing this command. uint bufId The buffer to update. uint x The x-position of the update in pixels (bufId coordinate). uint y The y-position of the update in pixels (bufId coordinate). uint width The width of the update in pixels. uint height The height of the update in pixels. uint channelId The channel ID of the data channel on which the content will uint be sent. dataType The data frame_type_id identifier of the content. Options are: string PixelData JPEGPixelData PNGPixelData CompressedPixelData
Table 4-35: Write command attributes
[4.8.2.3.3-2] M: RVU-C An RVU client shall process the Write command by writing the graphics data on the specified data channel to the specified buffer.
[4.8.2.3.3-3] M: RVU-C An RVU client shall respond to the Write command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-36: Write response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_BAD_CONFIG The specified data type is unknown or unsupported. ERR_FAIL The CompressedPixelData, JPEGPixelData, or PNGPixelData data frame could not be correctly decoded.
Table 4-37: Write response error codes
V1.0 Rev 1.5.1 66 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.3.4 Read The Read command is used to read pixel data from the display buffer or an allocated graphics buffer. The Read command triggers a response of data on an associated data channel. This command can be used during testing to verify what data a client has written to a graphics buffer or an allocated graphics buffer.
[4.8.2.3.4-1] M: RVU-S An RVU server shall have the ability to send the Read command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The buffer to read. uint x The x-position of the read in pixels (bufId coordinate). uint y The y-position of the read in pixels (bufId coordinate). uint width The width of the read in pixels. uint height The height of the read in pixels. uint channelId The channel ID of the data channel on which the content from uint the response of this command will be sent. dataType The data frame_type_id identifier of the content. Options are: string PixelData CompressedPixelData
Table 4-38: Read command attributes
[4.8.2.3.4-2] M: RVU-C An RVU client shall process the Read command by sending the requested buffer's graphics data on the specified data channel.
[4.8.2.3.4-3] M: RVU-C An RVU client shall respond to the Read command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-39: Read response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer.
V1.0 Rev 1.5.1 67 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Code Description ERR_NON_PREMULTIPLIED Buffer contains non-pre-multiplied pixel data
Table 4-40: Read response error codes
4.8.2.3.5 BlitQueue The BlitQueue command is used to set up the queuing state on blit operations for the command channel on which the BlitQueue command is sent. Queuing is either enabled (when the queuing attribute in the command is set to non-zero), or disabled (when the queuing attribute in the command is set to 0).
Use of queued blit commands with queued WaitVSync commands allows for a limited form of client-side animation. Such animations may be canceled by sending an EmptyQueue command during the processing of that queue.
Each command channel is considered to have a separate blit queue.
[4.8.2.3.5-1] M: RVU-S An RVU server shall have the ability to send the BlitQueue command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint queuing 0: Stop queuing (and dispatch all queued commands) uint Non-zero: Start queuing.
Table 4-41: BlitQueue command attributes
[4.8.2.3.5-2] M: RVU-C An RVU client shall queue any CopyBlit, FillBlit, ResizeBlit, ShadeBlit, BlendBlit, MultiSourceBlendBlit, ResizeAndBlendBlit, ColorKeyResizeBlit, or WaitVSync commands on this channel if the BlitQueue command is received with the queuing attribute set to any value other than zero.
[4.8.2.3.5-3] M: RVU-C An RVU client shall have the ability to enqueue at least 256 commands, totaled across all channels.
[4.8.2.3.5-4] M: RVU-C If queuing is enabled, an RVU client shall delay processing of queued commands until either a Dispatch command (defined in section 4.8.2.3.6) is received, or queuing is disabled. Note: this includes delaying response values from each of the queued blit operations until the Dispatch command is received.
[4.8.2.3.5-5] M: RVU-C An RVU client shall stop queuing commands and immediately process all queued commands (if any) when the BlitQueue command is received with the queuing attribute set to zero (changing the queuing state from enabled to disabled).
V1.0 Rev 1.5.1 68 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Note the distinction between the Dispatch command and a BlitQueue command with queuing disabled. The Dispatch command causes all queued commands to be processed without changing the queue state, whereas a BlitQueue command with queuing disabled not only causes all queued commands to be processed, but also changes the queue state to disabled.
[4.8.2.3.5-6] M: RVU-C An RVU client shall respond to the BlitQueue command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-42: BlitQueue response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-43: BlitQueue response error codes
4.8.2.3.6 Dispatch The Dispatch command is used to execute all queued blit commands, if any. Any collection of blit operations (or \frame" when queued commands are separated by a WaitVSync) executed in this fashion should be displayed/updated atomically. There should be no partial updates; either none of the operations are displayed or all are displayed.
[4.8.2.3.6-1] M: RVU-S An RVU server shall have the ability to send the Dispatch command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-44: Dispatch command attributes
[4.8.2.3.6-2] M: RVU-C An RVU client shall immediately process all queued commands (if any) when the Dispatch command is received. Note: the queuing state remains unchanged by this command.
[4.8.2.3.6-3] M: RVU-C An RVU client shall respond to the Dispatch command by returning the commandToken and appropriate errCode, as described in the following tables.
V1.0 Rev 1.5.1 69 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-45: Dispatch response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet OR queuing has not been enabled yet.
Table 4-46: Dispatch response error codes
4.8.2.3.7 EmptyQueue The EmptyQueue command is used to erase all queued blit commands, if any, on the specified queue. If this queue is currently dispatching, the dispatch is terminated when the next WaitVSync is encountered in the queue; if no WaitVSync is encountered, the dispatch is processed as normal. Any operation that was cancelled due to the EmptyQueue command triggers an error response of ERR_CANCELED (defined in the Error Codes for each queueable command).
If EmptyQueue is used to empty a dispatching queue, this command must be sent on a different command channel than the one used to send the active Dispatch command. Commands on the same command channel are processed in the order sent, so EmptyQueue wouldn’t be processed to empty the dispatching queue if it were sent on the same command channel as the Dispatch command.
[4.8.2.3.7-1] M: RVU-S An RVU server shall have the ability to send the EmptyQueue command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint channelId The channel ID associated with the blit queue to empty. uint
Table 4-47: EmptyQueue command attributes
[4.8.2.3.7-2] M: RVU-C An RVU client not currently dispatching the targeted queue shall immediately delete all queued commands (if any) when the EmptyQueue command is received. Note: the queuing state remains unchanged by this command.
[4.8.2.3.7-3] M: RVU-C If the queue targeted by the EmptyQueue command is dispatching when the EmptyQueue command is received, an RVU client shall continue processing the queue as normal until the
V1.0 Rev 1.5.1 70 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface next WaitVSync command is encountered in the queue. Note: if no WaitVSync is found, the entire queue is dispatched normally.
[4.8.2.3.7-4] M: RVU-C If the queue targeted by the EmptyQueue command is dispatching when the EmptyQueue command is received, an RVU client shall terminate dispatching the queue when handling the next WaitVSync command encountered in the queue, and shall then delete all remaining queued commands (if any).
[4.8.2.3.7-5] M: RVU-C An RVU client shall respond to the EmptyQueue command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-48: EmptyQueue response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet or queuing has not been enabled yet OR queuing isn't enabled yet.
Table 4-49: EmptyQueue response error codes
4.8.2.3.8 WaitVSync The WaitVSync command is used to wait for the client to enter a vertical resync period. It is not expected that a server can send additional commands after receiving a WaitVSync response and have them processed during the same sync period. However, this can be used to add an integer number of delay frames, which can be especially useful in conjunction with BlitQueue operations (note: WaitVSync is queue-able; see discussion in BlitQueue).
[4.8.2.3.8-1] M: RVU-S An RVU server shall have the ability to send the WaitVSync command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint syncs The number of vsync intervals to wait before returning. uint
Table 4-50: WaitVSync command attributes
[4.8.2.3.8-2] M: RVU-C An RVU client shall respond to the WaitVSync command by returning the commandToken and appropriate errCode, as described in the following tables. V1.0 Rev 1.5.1 71 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-51: WaitVSync response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet or queuing has not been enabled yet OR queuing isn't enabled yet. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command.
Table 4-52: WaitVSync response error codes
4.8.2.3.9 CopyBlit The CopyBlit command is used to perform a copy of a region from one graphics buffer to another.
[4.8.2.3.9-1] M: RVU-S An RVU server shall have the ability to send the CopyBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint srcBufId The ID of the source buffer. uint srcX Source X coordinate, in pixels (srcBufId coordinate). uint srcY Source Y coordinate, in pixels (srcBufId coordinate). uint width Width of the region to be copied, in pixels. uint height Height of the region to be copied, in pixels. uint
Table 4-53: CopyBlit command attributes
[4.8.2.3.9-2] M: RVU-C An RVU client shall process the CopyBlit command by copying the region indicated in the specified source buffer to the region indicated in the specified destination buffer.
[4.8.2.3.9-3] M: RVU-C An RVU client shall respond to the CopyBlit command by returning the commandToken and appropriate errCode, as described in the following tables. V1.0 Rev 1.5.1 72 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-54: CopyBlit response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID One or more of the specified buffers has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this operation. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command.
Table 4-55: CopyBlit response error codes
4.8.2.3.10 FillBlit The FillBlit command is used to perform a write of a constant color (of the determined pixel format) to a region in a graphics buffer.
[4.8.2.3.10-1] M: RVU-S An RVU server shall have the ability to send the FillBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint width Width of the region to be copied, in pixels. uint height Height of the region to be copied, in pixels. uint color Hex-formatted color to fill with format determined by the pixel hex format of the specified destination buffer. For example, if the destination buffer is a CLUT, the format should be a 1-byte color; if the buffer is ARGB, it should be a 4-byte color.
Table 4-56: FillBlit command attributes
V1.0 Rev 1.5.1 73 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.3.10-2] M: RVU-C An RVU client shall process the FillBlit command by writing the specified color to the region indicated in the specified buffer.
[4.8.2.3.10-3] M: RVU-C An RVU client shall respond to the FillBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-57: FillBlit response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_BAD_CONFIG The specified color does not match the pixel format for this buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command.
Table 4-58: FillBlit response error codes
4.8.2.3.11 ResizeBlit The ResizeBlit command is used to perform a scaling copy of a region from one graphics buffer to another.
[4.8.2.3.11-1] M: RVU-S An RVU server shall have the ability to send the ResizeBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint dstWidth Width of the region to be copied into, in pixels. uint dstHeight Height of the region to be copied into, in pixels. uint srcBufId The ID of the source buffer. uint srcX Source X coordinate, in pixels (srcBufId coordinate). uint V1.0 Rev 1.5.1 74 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type srcY Source Y coordinate, in pixels (srcBufId coordinate). uint srcWidth Width of the region to be copied from, in pixels. uint srcHeight Height of the region to be copied from, in pixels. uint
Table 4-59: ResizeBlit command attributes
[4.8.2.3.11-2] M: RVU-C An RVU client shall process the ResizeBlit command by copying the region indicated in the specified source buffer and resizing the copied image to fit the region indicated in the specified destination buffer.
[4.8.2.3.11-3] M: RVU-C An RVU client shall respond to the ResizeBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-60: ResizeBlit response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID One or more of the specified buffers has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this operation. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command.
Table 4-61: ResizeBlit response error codes
4.8.2.3.12 ShadeBlit The ShadeBlit command is used to perform a Porter-Duff blending operation of a constant color (of the chosen pixel format) to a region in a graphics buffer [Ref23].
[4.8.2.3.12-1] M: RVU-C An RVU client shall support all Porter-Duff operations specified in the shadeRule attribute of the ShadeBlit command. Note: support for Porter-Duff operations other than those listed is not required [Ref23].
V1.0 Rev 1.5.1 75 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.3.12-2] M: RVU-S An RVU server shall have the ability to send the ShadeBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint width Width of area to shade, in pixels. uint height Height of area to shade, in pixels. uint color Hex-formatted color to fill with format determined by the pixel hex format of the specified destination buffer. For example, if the destination buffer is a CLUT, the format should be a 1-byte color; if the buffer is ARGB, it should be a 4-byte color. shadeRule Hex-formatted integer, one of the following flags, configuring the hex Porter-Duff blend operation to perform: 0x1: Source Over 0x2: Source In 0x4: Source Out 0x8: Dest Over 0x10: Dest In 0x20: Dest Out
Table 4-62: ShadeBlit command attributes
[4.8.2.3.12-3] M: RVU-C An RVU client shall process the ShadeBlit command by writing the specified color to the region indicated in the specified buffer.
[4.8.2.3.12-4] M: RVU-C An RVU client shall respond to the ShadeBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-63: ShadeBlit response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer.
V1.0 Rev 1.5.1 76 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Code Description ERR_BAD_CONFIG The specified color does not match the pixel format for this buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this operation. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command. ERR_CLUT_DEST_BUFFER Cannot blend into a CLUT-configured buffer.
Table 4-64: ShadeBlit response error codes
4.8.2.3.13 BlendBlit The BlendBlit command is used to perform a Porter-Duff blending operation using a region of a graphics buffer blended to a region of another graphics buffer[Ref23] .
Note that only the subset of Porter-Duff operations specified in the shadeRule attribute need to be supported by clients (per [4.8.2.3.12-1]).
[4.8.2.3.13-1] M: RVU-S An RVU server shall have the ability to send the BlendBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint srcBufId The ID of the source buffer. uint srcX Source X coordinate, in pixels (srcBufId coordinate). uint srcY Source Y coordinate, in pixels (srcBufId coordinate). uint width Width of the region to be copied, in pixels. uint height Height of the region to be copied, in pixels. uint shadeRule Hex-formatted integer, one of the following flags, configuring the hex Porter-Duff blend operation to perform: 0x1: Source Over 0x2: Source In 0x4: Source Out 0x8: Dest over 0x10: Dest in 0x20: Dest out
Table 4-65: BlendBlit command attributes
V1.0 Rev 1.5.1 77 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.3.13-2] M: RVU-C An RVU client shall process the BlendBlit command by performing a Porter-Duff blending operation (as specified by the shadeRule attribute) of the specified region of the source buffer with the specified region of the destination buffer.
[4.8.2.3.13-3] M: RVU-C An RVU client shall respond to the BlendBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-66: BlendBlit response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID One or more of the specified buffers has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this operation. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command. ERR_CLUT_DEST_BUFFER Cannot blend into a CLUT-configured buffer.
Table 4-67: BlendBlit response error codes
4.8.2.3.14 MultiSourceBlendBlit The MultiSourceBlendBlit command is used to perform a Porter-Duff blending/shading operation with two source buffers and a single destination buffer [Ref23].
Note that only the subset of Porter-Duff operations specified in the shadeRule attribute need to be supported by clients (per [4.8.2.3.12-1]).
[4.8.2.3.14-1] M: RVU-S An RVU server shall have the ability to send the MultiSourceBlendBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint
V1.0 Rev 1.5.1 78 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint srcBufId1 The ID of the first source buffer. uint srcX1 Source X coordinate for BufId1, in pixels (srcBufId1 coordinate). uint srcY1 Source Y coordinate for BufId1, in pixels (srcBufId1 coordinate). uint width1 Width of the region to be copied from srcBufId1, in pixels. uint height1 Height of the region to be copied from srcBufId1, in pixels. uint srcBufId2 The ID of the second source buffer. uint srcX2 Source X coordinate for BufId2, in pixels (srcBufId2 coordinate). uint srcY2 Source Y coordinate for BufId2, in pixels (srcBufId2 coordinate). uint width2 Width of the region to be copied from srcBufId2, in pixels. uint height2 Height of the region to be copied from srcBufId2, in pixels. uint color A constant ARGB color that may be used in the blending, hex depending on the values of colorSelect and alphaSelect. colorSelect If non-zero (1): Ignore the color of the first source buffer and uint use the color (RGB only) of the color parameter instead. If zero (0): Use the appropriate color from srcBufId1. alphaSelect If non-zero (1): Ignore the alpha of the first source buffer and uint use the alpha of the color parameter instead. If zero (0): Use the appropriate alpha from srcBufId1. shadeRule Hex-formatted integer, one of the following flags, configuring the hex Porter-Duff blend operation to perform: 0x1: Source Over 0x2: Source In 0x4: Source Out 0x8: Dest over 0x10: Dest in 0x20: Dest out src1NPM If non-zero (1): Interpret color of the first source buffer as non- uint premultiplied when blending. If zero (0): Interpret the first source as premultiplied alpha (as it would be elsewhere in this document).
Table 4-68: MultiSourceBlendBlit command attributes
[4.8.2.3.14-2] M: RVU-C An RVU client shall process the MultiSourceBlendBlit command by performing a Porter-Duff blending operation (as specified by the shadeRule attribute) of the specified region of each source buffer into the specified region of the destination buffer [Ref23].
[4.8.2.3.14-3] M: RVU-C An RVU client shall respond to the MultiSourceBlendBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint
V1.0 Rev 1.5.1 79 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type errCode See error code table below. string
Table 4-69: MultiSourceBlendBlit response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID One or more of the specified buffers has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this operation. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command. ERR_CLUT_DEST_BUFFER Cannot blend into a CLUT-configured buffer.
Table 4-70: MultiSourceBlendBlit response error codes
4.8.2.3.14.1 Examples
The following provides additional information on the implementation of the MultiSourceBlendBlit command.
Blend rectangular areas of two source buffers and a fixed color. Copy the result to a destination buffer. srcBuf1 will be resized to match the size of srcBuf2 before the blend occurs. Neither srcBuf1 nor srcBuf2 are modified by this operation. For the sake of the Porter-Duff shadeRule, srcBuf1 / color parameter is considered the Source and srcBuf2 is the Destination (Dest). The result of the blend is copied to the destination buffer, with the top-left corner of the rectangle positioned at the destination position. The source/destination rectangle fully lies within the bounds of the source/destination buffer.
V1.0 Rev 1.5.1 80 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
colorSelect shadeRules and alphaSelect
Porter-Duff Blending srcBuf1 Source Selector Source dstBuf color (color/alpha) Dest srcBuf2
Figure 4-2: MultiSourceBlendBlit Implementation
Example 1: colorSelect = 0, alphaSelect = 1 The color parameter provides the constant alpha value used to blend the color pixels of srcBuf1 with srcBuf2. One use of this selection might be to perform a cross fade from the image pointed to by srcBuf1 to the image pointed to by srcBuf2. This is done by adjusting the color parameter alpha component over multiple blit operations.
Example 2: colorSelect = 1, alphaSelect = 0 The color parameter provides the color used and srcBuf1 provides the per pixel alpha used to blend the color pixels of src1 with srcBuf2. One use of this selection might be to color a font pointed to by srcBuf1 with the color in the color attribute, then blend the result to the destination. In this example srcBuf2 and dst point to the same buffer.
4.8.2.3.15 ResizeAndBlendBlit The ResizeAndBlendBlit command is used to perform a scaled copy and Porter-Duff blending operation using a region of a graphics buffer blended to a region of another graphics buffer [Ref23].
Note that only the subset of Porter-Duff operations specified in the shadeRule attribute need to be supported by clients (per [4.8.2.3.12-1]) [Ref23].
[4.8.2.3.15-1] M: RVU-S An RVU server shall have the ability to send the ResizeAndBlendBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinate). uint dstY Destination Y coordinate, in pixels (dstBufId coordinate). uint dstWidth Width of the region to be copied to, in pixels. uint dstHeight Height of the region to be copied to, in pixels. uint srcBufId The ID of the source buffer. uint srcX Source X coordinate, in pixels (srcBufId coordinate). uint
V1.0 Rev 1.5.1 81 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type srcY Source Y coordinate, in pixels (srcBufId coordinate). uint srcWidth Width of the region to be copied, in pixels. uint srcHeight Height of the region to be copied, in pixels. uint shadeRule Hex-formatted integer, one of the following flags, configuring the hex Porter-Duff blend operation to perform: 0x1: Source Over 0x2: Source In 0x4: Source Out 0x8: Dest over 0x10: Dest in 0x20: Dest out
Table 4-71: ResizeAndBlendBlit command attributes
[4.8.2.3.15-2] M: RVU-C An RVU client shall process the ResizeAndBlendBlit command by copying the region indicated in the specified source buffer, resizing the copied image to fit the region indicated in the specified destination buffer, and performing a Porter-Duff blending operation (as specified by the shadeRule attribute) of the resized region of the source buffer with the specified region of the destination buffer [Ref23].
[4.8.2.3.15-3] M: RVU-C An RVU client shall respond to the ResizeAndBlendBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-72: ResizeAndBlendBlit response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID One or more of the specified buffers has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this operation. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command. ERR_CLUT_DEST_BUFFER Cannot blend into a CLUT-configured buffer.
Table 4-73: ResizeAndBlendBlit response error codes V1.0 Rev 1.5.1 82 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.3.16 ColorKeyResizeBlit The ColorKeyResizeBlitcommand is used to copy or resize from a source bitmap into a destination bitmap while executing a conditional operation on each pixel, based on a comparison to a constant color.
[4.8.2.3.16-1] M: RVU-S An RVU server shall have the ability to send the ColorKeyResizeBlit command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint dstBufId The ID of the destination buffer. uint dstX Destination X coordinate, in pixels (dstBufId coordinates). uint dstY Destination Y coordinate, in pixels (dstBufId coordinates). uint dstWidth Width of the region to be copied to, in pixels. uint dstHeight Height of the region to be copied to, in pixels. uint srcBufId The ID of the source buffer. uint srcX Source X coordinate, in pixels (srcBufId coordinate). uint srcY Source Y coordinate, in pixels (srcBufId coordinate). uint srcWidth Width of the region to be copied, in pixels. uint srcHeight Height of the region to be copied, in pixels. uint keyColor A constant color to be used as the comparison for each hex copied/resized pixel. The pixel format is determined by the source buffer's pixel format. action Value that indicates the action to be taken based on the per-pixel uint match comparison between the resized output and the keyColor: 1: Skip (make transparent) only matching color; Match Action=SKIP, No-Match Action=COPY. 2: Substitute color key; Match Action=SOLID, No-Match Action=COPY. 3: Mask off the matching color; Match Action=SKIP, No-Match Action=SOLID. fillColor Required if the action includes a SOLID action; optional otherwise hex A constant color to be used as the fill color for SOLID actions. The pixel format is determined by the destination buffer's pixel format.
Table 4-74: ColorKeyResizeBlit command attributes
[4.8.2.3.16-2] M: RVU-C An RVU client shall process the ColorKeyResizeBlit command by copying the region indicated in the specified source buffer, performing a pixel-by-pixel color comparison of the copied region to the keyColor attribute, performing the indicated action to replace, copy, or mask off the resulting region, and resizing the copied image to fit the region indicated in the specified destination buffer.
V1.0 Rev 1.5.1 83 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.3.16-3] M: RVU-C An RVU client shall respond to the ColorKeyResizeBlit command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-75: ColorKeyResizeBlit response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID One or more of the specified buffers has not been identified yet. ERR_BOUNDING The specified region does not fit in the given buffer. ERR_QUEUE_FULL Blit operations are currently being queued, and the queue is full. ERR_CANCELED The operation was queued, and then cancelled due to the EmptyQueue command.
Table 4-76: ColorKeyResizeBlit response error codes
4.8.2.3.17 GetGraphicsCaps The GetGraphicsCaps command is used to get information about the supported blit operations and buffer configuration parameters.
[4.8.2.3.17-1] M: RVU-S An RVU server shall have the ability to send the GetGraphicsCaps command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-77: GetGraphicsCaps command attributes
[4.8.2.3.17-2] M: RVU-C An RVU client shall respond to the GetGraphicsCaps command by returning the commandToken, appropriate errCode, and client capabilities as described in the following tables.
[4.8.2.3.17-3] M: RVU-C The GetGraphicsCaps command allows the client to specify support for a subset of possible blit operations. An RVU client shall support the Blend, Copy, Resize, Fill, Shade, MultiSourceBlend and ColorKeyResize operations. The supportedBlitOps field in Table 4-78 would expand to indicate future operations that could be optional.
V1.0 Rev 1.5.1 84 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.3.17-4] M: RVU-C An RVU client shall support the Copy blit operation for the supportedClutClutBlits attributes of the GetGraphicsCaps command.
[4.8.2.3.17-5] M: RVU-C The GetGraphicsCaps command allows the client to specify support for a subset of video input formats. An RVU client shall support 480i/30, 480p/60, 720p/60, 1080i/30 and 1080p/24. Clients may support 2160p and 4320p resolutions.
[4.8.2.3.17-6] M: RVU-C An RVU client shall have the ability to accept all video input formats defined in the videoDisplayFormats attribute and convert these formats to a format matching its display capabilities (e.g., if the display only supports 480p/60 and 720p/60, it should also accept 480i/30, 1080i/30 and 1080p/24 and convert to its supported display resolutions). To preserve video quality, conversion between 25/50 and 30/60 frame rates is strongly discouraged.
[4.8.2.3.17-7] O: RVU-C An RVU client may support a subset of the video display formats defined in the videoDisplayFormats attribute, provided the client meets the requirement of 4.8.2.3.17-6.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string supportedBlitOps A bitmask of the following flags representing which blit hex operations are supported: 0x01: Blend 0x02: Copy 0x04: Resize 0x08: Fill 0x10: Shade 0x20: MultiSourceBlend 0x40: ColorKeyResize supportedClutClutBlits A bitmask of the flags defined above in supportedBlitOps hex representing which blit operations are capable of supporting a blit between two CLUT-formatted buffers. Note, the Fill and Shade bits are always set to 0
V1.0 Rev 1.5.1 85 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type videoInputFormats A bitmask of the following flags representing which hex resolutions can be received on the client: 0x0001: 480i/30 0x0002: 480p/60 0x0004: 720p/60 0x0008: 1080i/30 0x0010: 1080p/24 0x0020: 576i/25 0x0040: 576p/50 0x0080: 720p/50 0x0100: 1080i/25 0x0200: 1080p/25 0x0400: 2160p/25/50 0x0800: 2160p/24/30 0x1000: 2160p/60 0x2000: 4320p/60 Where multiple frame rates are indicated, the bit for that resolution indicates all frame rates are supported. videoDisplayFormats A bitmask of the following flags representing which hex resolutions can be displayed on the client: 0x0001: 480i/30 0x0002: 480p/60 0x0004: 720p/60 0x0008: 1080i/30 0x0010: 1080p/24/60 0x0020: 576i/25 0x0040: 576p/50 0x0080: 720p/50 0x0100: 1080i/25 0x0200: 1080p/25 0x0400: 2160p/25/50 0x0800: 2160p/24/30 0x1000: 2160p/60 0x2000: 4320p/60 Where multiple frame rates are indicated, the bit for that resolution indicates all frame rates are supported. videoStreamCount Number of video streams that can be supported int simultaneously. -1: unlimited number of streams. setZListSupported Flag indicating if the client supports SetZList command. uint 0: SetZList command is not supported 1: SetZList command is supported
V1.0 Rev 1.5.1 86 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type clutDestBlitsSupported A bitmask of the following flags representing which blit hex operations are supported when the destination buffer is a CLUT: 0x01: Copy 0x02: Resize 0x04: Fill 0x08: Shade 0x10: Blend 0x20: ResizeAndBlend 0x40: MultiSourceBlend supported3DTVStructures A five or seven element comma-delimited string of hex- string formatted bitmasks representing the 3DTV structures supported for each display format. The order of the five or seven 3DTV structure elements: The first element specifies the 3DTV structures supported for 480i. The second element specifies the 3DTV structures supported for 480p. The third element specifies the 3DTV structures supported for 720p. The forth element specifies the 3DTV structures supported for 1080i. The fifth element specifies the 3DTV structures supported for 1080p. Optional The sixth element specifies the 3DTV structures supported for 2160p Optional The seventh element specifies the 3DTV structures supported for 4320p NOTE: if there is a sixth element, there must be a seventh element.
Flags for each element: 0x00: None (3DTV structure not supported for this format) 0x01: Frame Packing (Full resolution for each eye/view) 0x02: Side-by-Side (Half resolution for each eye/view) 0x04: Top-and-Bottom (Half resolution for each eye/view)
Table 4-78: GetGraphicsCaps response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-79: GetGraphicsCaps response error codes
V1.0 Rev 1.5.1 87 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.3.18 GetZList The GetZList command is used to determine the order of the display buffers.
[4.8.2.3.18-1] M: RVU-S An RVU server shall have the ability to send the GetZList command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-80: GetZList command attributes
[4.8.2.3.18-2] M: RVU-C An RVU client shall respond to the GetZList command by returning the commandToken, appropriate errCode, and ordered list of buffer IDs as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string zlist A comma-delimited string of uint-formatted buffer IDs string representing the order of the display buffers. The first buffer listed is the topmost buffer.
Table 4-81: GetZList response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-82: GetZList response error codes
4.8.2.3.19 SetZList The SetZList command is used to specify the order of the display buffer and any video buffers.
[4.8.2.3.19-1] O: RVU-S An RVU server may have the ability to send the SetZList command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
V1.0 Rev 1.5.1 88 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type zlist A comma-delimited string of uint-formatted buffer IDs string representing the order of the buffers. The first buffer listed will be the topmost buffer. Note: Each element in the list must be a valid buffer ID. No blanks are allowed in the list. allowRemovals Optional attribute with a default value of 0: uint 0: Every buffer in the current zlist must appear in the new list. Non-zero: Buffer entries may be dropped. If so, those buffers will not be displayed on the screen at all.
Table 4-83: SetZList command attributes
[4.8.2.3.19-2] O: RVU-C An RVU client may process the SetZList command by arranging its ordered list of buffer IDs as specified in the zlist attribute of the command.
[4.8.2.3.19-3] M: RVU-C An RVU client shall display buffers as per the zlist attribute if a client processes the SetZList command and if the allowRemovals attribute of the SetZList command is set to zero (0).
[4.8.2.3.19-4] M: RVU-C An RVU client shall display only those buffers listed in the zlist attribute if a client processes the SetZList command and if the allowRemovals attribute of the SetZList command is non-zero.
[4.8.2.3.19-5] M: RVU-C An RVU client shall respond to the SetZList command by returning the commandToken and appropriate errCode as described in the following tables if a client process the SetZList command.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-84: SetZList response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_CONFIG The provided zlist string is not valid. ERR_FAIL The server sent a SetZList command and the client does not support the SetZList command.
Table 4-85: SetZList response error codes
V1.0 Rev 1.5.1 89 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.3.20 SetCLUT The SetCLUT command is used to set the color look-up table (CLUT) of a graphics buffer. This applies only to buffers allocated with AllocateBuffer with a pixelFormat of CLUT-8.
The SetCLUT command only defines information about what and how to write the data. The data itself comes from content via an associated data channel. The frame_type_id identifier in the data on the data channel must be set to CLUT.
[4.8.2.3.20-1] M: RVU-S An RVU server shall have the ability to send the SetCLUT command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The graphics buffer for which the CLUT is to be updated. uint Note: this is the ID of a graphics buffer, but the data is for its associated CLUT. The CLUT itself is not a graphics buffer, and is separately allocated and associated to the graphics buffer by the application. channelId The channel ID of the data channel on which the content will uint be sent. firstIndex The first CLUT index to update. The number of CLUT entries uint that are sent in the CLUT data will determine the length of the CLUT run that is set in this command. This index is 0-based.
Table 4-86: SetCLUT command attributes
[4.8.2.3.20-2] M: RVU-C An RVU client shall process the SetCLUT command by writing the CLUT data on the specified data channel to the specified buffer and index.
[4.8.2.3.20-3] M: RVU-C An RVU client shall respond to the SetCLUT command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-87: SetCLUT response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been identified yet. V1.0 Rev 1.5.1 90 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Code Description ERR_BAD_CONFIG The specified buffer was not defined as CLUT-8. ERR_BOUNDING First index plus the CLUT data does not fit in CLUT.
Table 4-88: SetCLUT response error codes
4.8.2.4 Local UI Commands in this section are used to manage the display of buffers and local UI menus. Local UI commands define the relationship between UI elements generated on the server and UI elements generated on the client. If the UI elements on client and server have the same look- and-feel, this allows for a seamless transition between remote-controlled functionality and locally-controlled functionality. For client/server pairs with differing display themes/branding, this still provides a mechanism for the client settings to be controlled from within the server- generated UI.
See section 6 for a description of the use of these commands and for local UI requirements.
4.8.2.4.1 ListLocalUIElements The ListLocalUIElements command is used to list the set of locally-generated UI elements that are available on the client. This list should be drawn from Table 4-89, although it is legal to allow vendor-specific elements as well.
Name Description org.rvualliance.CC Closed captioning settings org.rvualliance.Info Client information org.rvualliance.Network Network settings org.rvualliance.NetworkDiag Network diagnostics org.rvualliance.HDTV HD Output Settings org.rvualliance.Dolby Dolby Audio Settings org.rvualliance.Restart Restart app/reboot client options org.rvualliance.Reset Restore the client to default settings org.rvualliance.UnhandledKey The server does not support this key org.rvualliance.ClientRequest Client has requeted control of the UI org.rvualliance.Subtitle DVB Subtitling or SBTVD captioning language setting org.rvualliance.ServerSelection Alternative server selection
Table 4-89: Local UI Elements
Vendor-specific elements should begin with a unique namespace identifier in order to be unambiguous with other vendor-specific elements. Use of the Java-style package naming is recommended (for example, org.rvualliance.config).
[4.8.2.4.1-1] M: RVU-S An RVU server shall have the ability to send the ListLocalUIElements command as described in the following table. V1.0 Rev 1.5.1 91 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-90: ListLocalUIElements command attributes
[4.8.2.4.1-2] O: RVU-C An RVU client may support some or all Local UI Elements listed in Table 4-89.
[4.8.2.4.1-3] M: RVU-C An RVU client shall respond to the ListLocalUIElements command by returning the commandToken, elements, and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string elements A comma-delimited list of UI elements supported by the string client.
Table 4-91: ListLocalUIElements response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-92: ListLocalUIElements response error codes
4.8.2.4.2 RequestLocalUI The RequestLocalUI command is used to request a locally-generated UI element. This can be used to perform local configuration, while still tying into the general menu system of the remote UI.
When an RVU client is displaying local UI, the following apply to the client:
[4.8.2.4.2-0a] O: RVU-C The client may stop displaying the RUI display buffer.
[4.8.2.4.2-0b] M: RVU-C The client shall process commands sent by the server to update the display buffer.
[4.8.2.4.2-0c] M: RVU-C If the RUI buffer is visible, the client shall process commands sent by the server to update the display buffer and update the display as commands are received and processed.
[4.8.2.4.2-0d] M: RVU-C The local UI buffer shall be at the front of the z-list.
V1.0 Rev 1.5.1 92 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
As a result of the above requirements, if the local UI screen has full or partial transparency, then either RUI or video will show through.
[4.8.2.4.2-1] M: RVU-S An RVU server shall have the ability to send the RequestLocalUI command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. Uint enable 0: dismiss local UI element. Uint 1: enable local UI element. element Name of the local UI element on which to operate. (See String Table 4-89 for the list of client-supported elements.) keyVal Required if the element is org.rvualliance.UnhandledKey; hex optional otherwise The key code that triggered this request.
Table 4-93: RequestLocalUI command attributes
[4.8.2.4.2-2] M: RVU-C An RVU client shall respond to an enable request for all elements defined in Table 4-89.
[4.8.2.4.2-3] M: RVU-C DELETED.
[4.8.2.4.2-4] M: RVU-C DELETED
[4.8.2.4.2-5] M: RVU-C An RVU client shall respond to the RequestLocalUI command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-94: RequestLocalUI response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The local application is in a display state where it is inappropriate to enable that element. ERR_INVALID_PARAM The requested element is not supported.
V1.0 Rev 1.5.1 93 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Code Description ERR_KEY_UNKNOWN The requested element is org.rvualliance.UnhandledKey but keyVal is unsupported
Table 4-95: RequestLocalUI response error codes
4.8.2.4.3 LocalUIEvent The LocalUIEvent command is sent by a client when entering or exiting a local UI operation.
[4.8.2.4.3-1] M: RVU-C An RVU client shall send the LocalUIEvent command when entering or exiting a local UI operation.
[4.8.2.4.3-2] M: RVU-C An RVU client shall have the ability to send the LocalUIEvent command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint starting 0: terminating a local display operation. uint Non-zero: starting a new local display operation. element The name of the element that is beginning or ending. string keyVal Required if the operation is ending and is terminating due to a hex user keypress; optional otherwise. The key that terminated the local UI operation. keyFormat Required if and only if keyVal is present; optional otherwise. string The format of the keyVal parameter. Options are: HDMI CDI
Table 4-96: LocalUIEvent command attributes
[4.8.2.4.3-3] M: RVU-S An RVU server shall respond to the LocalUIEvent command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-97: LocalUIEvent response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded.
V1.0 Rev 1.5.1 94 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Code Description ERR_INVALID_STATE The channel has not been identified yet.
Table 4-98: LocalUIEvent response error codes
[4.8.2.4.3-4] M: RVU-S The server shall produce RUI and A/V content based on the keyVal attribute in LocalUIEvent(terminating) or other default display content if keyVal is not included in LocalUIEvent(terminating) received by the server.
[4.8.2.4.3-5] M: RVU-S Upon receiving a LocalUIEvent command from a client to terminate a local display operation with attribute element org.rvualliance.ClientRequest, the Server shall return to producing RUI graphics and AV content in effect when ClientRequestLocalUI was called.
4.8.2.4.4 ClientRequestLocalUI The ClientRequestLocalUI command is sent by a client to request control of the UI from the server.
[4.8.2.4.4-1] O: RVU-C An RVU client may send the ClientRequestLocalUI command when the client requires control of the UI by means other than invocation from a server menu.
[4.8.2.4.4-2] O: RVU-C An RVU client may have the ability to send the ClientRequestLocalUI command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-99: ClientRequestLocalUI command attributes
[4.8.2.4.4-3] M: RVU-S An RVU server shall respond to the ClientRequestLocalUI by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-100: ClientRequestLocalUI response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
V1.0 Rev 1.5.1 95 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Code Description ERR_FAIL The server application is in a display state where it is unable to switch to client UI.
Table 4-101: ClientRequestLocalUI response error codes
[4.8.2.4.4-4] M: RVU-S An RVU server shall respond to the ClientRequestLocalUI command by sending the RequestLocalUI command to the client with a element attribute of org.rvualiance.ClientRequest.
[4.8.2.4.4-5] M: RVU-C An RVU client shall support the org.rvualliance.ClientRequest Element listed in Table 4-89 if the ClientRequestLocalUI command is implemented.
[4.8.2.4.4-6] S: RVU-C A client should return to its prior 3DTV setting (as set by ReconfigureDisplayBuffer or ReconfigureDisplayBuffer3DTV) upon exiting local UI control.
4.8.2.5 Display Display commands operate on the display buffer or the video buffers. Video buffers operate under shared control with the client, and the client's implementation of AVTransport. RUI will provide the server with information about the video capabilities of the client, the aspect ratio of the client, the output resolution of the client, and (in a full-screen video case) the resolution / position of the video buffer in the display (which is necessary to deal with interactions between UI and video when the client can control letterbox/pillarbox, stretch, crop, etc.).
Attributes described with units as “output coordinates” or “with respect to the output” refer to the virtual canvas coordinates. These attributes define the resolution and position of the output/virtual canvas, which defines the coordinate space of the output. This is not the resolution of the video content or the display buffer. These are also the values returned in GetOutputSettings and OutputSettingsChanged.
Attributes described as “decoded video stream coordinate” refer to the resolution and coordinates of the video content.
The term “resolution” refers to distance as measured in pixels, e.g. horizontal resolution is interchangeable with horizontal width in pixels, and vertical resolution is interchangeable with vertical height in pixels
4.8.2.5.1 GetVideoBuffer The GetVideoBuffer command is used to tie an existing AV stream with a buffer on the client display used to represent the output of that video stream. The buffer ID returned is assumed to be a client-positioned full-screen state. This should immediately trigger an OutputSettingsChanged command from the client followed by an VideoDisplaySettingsChanged command from the client.
[4.8.2.5.1-1] M: RVU-S An RVU server shall have the ability to send the GetVideoBuffer command as described in the following table.
V1.0 Rev 1.5.1 96 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken A unique ID representing this command. uint avtId The InstanceID attribute for the AVTransport instance to uint associate.
Table 4-102: GetVideoBuffer command attributes
[4.8.2.5.1-2] M: RVU-C An RVU client shall respond to the GetVideoBuffer command by returning the commandToken, bufId, and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string bufId An identifier to represent the video stream associated with uint avtId.
Table 4-103: GetVideoBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID There is no matching AVTransportID.
Table 4-104: GetVideoBuffer response error codes
[4.8.2.5.1-3] M: RVU-C The video buffer shall be placed immediately behind the display buffer in the Z-List (in the appropriate ordered position of the zlist attribute) upon association of an AVTransport instance to the video buffer.
[4.8.2.5.1-4] M: RVU-C DELETED
4.8.2.5.2 ReleaseVideoBuffer The ReleaseVideoBuffer command is used to release control/interest in a video buffer that was acquired with GetVideoBuffer.
[4.8.2.5.2-1] M: RVU-S An RVU server shall have the ability to send the ReleaseVideoBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
V1.0 Rev 1.5.1 97 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type bufId The video buffer to release. uint
Table 4-105: ReleaseVideoBuffer command attributes
[4.8.2.5.2-2] M: RVU-C An RVU client shall respond to the ReleaseVideoBuffer command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-106: ReleaseVideoBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID There is no matching video buffer ID.
Table 4-107: ReleaseVideoBuffer response error codes
4.8.2.5.3 SetBackgroundColor The SetBackgroundColor command is used to set the default color of the output for regions not occluded by the display buffer or by a video buffer.
[4.8.2.5.3-1] M: RVU-S An RVU server shall have the ability to send the SetBackgroundColor command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint color The ARGB-32 formatted color with which to fill the buffer. hex Note: since this is logically the deepest blending layer, alpha values here are ignored.
Table 4-108: SetBackgroundColor command attributes
[4.8.2.5.3-2] M: RVU-C An RVU client shall process the SetBackgroundColor command by using the background color as specified in the SetBackgroundColor command.
[4.8.2.5.3-3] M: RVU-C An RVU client shall respond to the SetBackgroundColor command by returning the commandToken and appropriate errCode, as described in the following tables.
V1.0 Rev 1.5.1 98 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-109: SetBackgroundColor response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-110: SetBackgroundColor response error codes
4.8.2.5.4 ConfigureDisplayBuffer The ConfigureDisplayBuffer command is used to configure the display buffer. This command can be used to configure the output position of the display buffer.
[4.8.2.5.4-1] M: RVU-S An RVU server shall have the ability to send the ConfigureDisplayBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint x The horizontal (x) position of the buffer (in output canvas space uint coordinates). y The vertical (y) position of the buffer (in output canvas space uint coordinates).
Table 4-111: ConfigureDisplayBuffer command attributes
[4.8.2.5.4-2] M: RVU-C An RVU client shall process the ConfigureDisplayBuffer command by positioning the display buffer as specified in the ConfigureDisplayBuffer command.
[4.8.2.5.4-3] M: RVU-C An RVU client shall respond to the ConfigureDisplayBuffer command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-112: ConfigureDisplayBuffer response attributes
V1.0 Rev 1.5.1 99 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BOUNDING The display buffer at the specified position does not fit in the dimensions of the output.
Table 4-113: ConfigureDisplayBuffer response error codes
4.8.2.5.5 ReconfigureDisplayBuffer The ReconfigureDisplayBuffer command is used to configure the display buffer, and destroys any data in the buffer before configuring. This command configures the logical dimensions, resolution and pixel format of the display buffer, as well as disabling any 3DTV structure.
[4.8.2.5.5-1] M: RVU-S An RVU server shall have the ability to send the ReconfigureDisplayBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint width The width in pixels of the display buffer when projected onto the uint output canvas. The values are in the output canvas space coordinates. height The height in pixels of the display buffer when projected onto uint the output canvas. The values are in the output canvas space coordinates. xRes The width of the display buffer in pixels . uint yRes The height of the display buffer in pixels . uint pixelFormat The pixel format ARGB-32 string x Optional uint A new horizontal (x) position for the buffer (in output canvas space coordinates). If not provided by the RVU server, the RVU client shall use a value of 0. y Optional uint A new vertical (y) position for the buffer (in output canvas space coordinates). If not provided by the RVU server, the RVU client shall use a value of 0.
Table 4-114: ReconfigureDisplayBuffer command attributes
[4.8.2.5.5-2] M: RVU-C An RVU client shall process the ReconfigureDisplayBuffer command by configuring the display buffer as specified in the ReconfigureDisplayBuffer command.
V1.0 Rev 1.5.1 100 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.5.5-3] M: RVU-C An RVU client shall respond to the ReconfigureDisplayBuffer command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-115: ReconfigureDisplayBuffer response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_CONFIG The given format is unknown or unsupported. ERR_BOUNDING The display buffer with the specified dimensions and (optional) position does not fit in the dimensions of the output.
Table 4-116: ReconfigureDisplayBuffer response error codes
4.8.2.5.6 ConfigureVideoFullscreen The ConfigureVideoFullscreen command is used to give positional control of an AV stream's video buffer display back to the client after a call to ConfigureVideoWindow or ConfigureWindowedVideoWindow.
[4.8.2.5.6-1] M: RVU-S An RVU server shall have the ability to send the ConfigureVideoFullscreen command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID, as returned by GetVideoBuffer, displayed uint full-screen according to the local full-screen settings and the RUI-specified Z-list.
Table 4-117: ConfigureVideoFullscreen command attributes
[4.8.2.5.6-2] M: RVU-C An RVU client shall respond to the ConfigureVideoFullscreen command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
V1.0 Rev 1.5.1 101 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Table 4-118: ConfigureVideoFullscreen response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer is not a valid video buffer.
Table 4-119: ConfigureVideoFullscreen response error codes
4.8.2.5.7 ConfigureVideoWindow The ConfigureVideoWindow command is used to configure the position and dimensions of an AV stream's video buffer display.
[4.8.2.5.7-1] M: RVU-S An RVU server shall have the ability to send the ConfigureVideoWindow command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID, as returned by GetVideoBuffer, displayed uint non-full-screen according to the local window settings and the RUI-specified Z-list. x The horizontal position of the (non-full-screen) buffer (in output uint canvas space coordinates). y The vertical position of the (non-full-screen) buffer (in output uint canvas space coordinates). width The width in pixels of the video buffer when projected onto the uint output canvas. The values are in the output canvas space coordinates. height The height in pixels of the video buffer when projected onto the uint output canvas. The values are in the output canvas space coordinates.
Table 4-120: ConfigureVideoWindow command attributes
[4.8.2.5.7-2] M: RVU-C An RVU client shall support a minimum video display width of 98 pixels and minimum display height of 54 pixels, when the full screen resolution is 720 x 480.
[4.8.2.5.7-3] M: RVU-C An RVU client shall respond to the ConfigureVideoWindow command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint
V1.0 Rev 1.5.1 102 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type errCode See error code table below. string
Table 4-121: ConfigureVideoWindow response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BOUNDING The region specified by x, y, width, and height does not fit in the output. ERR_BAD_ID The specified buffer is not a valid video buffer.
Table 4-122: ConfigureVideoWindow response error codes
4.8.2.5.8 ConfigureWindowedVideoWindow The ConfigureWindowedVideoWindow command is used to configure the position and dimensions of an AV stream's video buffer display, displaying only a portion of the full AV stream. This allows for a region of the decoded stream to be resized and repositioned when displaying (the resized and repositioned stream are the only portion of that AV stream that will be displayed).
[4.8.2.5.8-1] M: RVU-S An RVU server shall have the ability to send the ConfigureWindowedVideoWindow command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID, as returned by GetVideoBuffer, displayed uint non-full-screen according to the local window settings and the RUI-specified Z-list. x The horizontal position of the (non-full-screen) buffer (in output uint canvas space coordinates). y The vertical position of the (non-full-screen) buffer (in output uint canvas space coordinates). width The width in pixels of the video buffer when projected onto the uint output canvas. The values are in the output canvas space coordinates. height The height in pixels of the video buffer when projected onto the uint output canvas. The values are in the output canvas space coordinates. srcX The horizontal position of the source rectangle (decoded video uint stream coordinate). srcY The vertical position of the source rectangle (decoded video uint stream coordinate).
V1.0 Rev 1.5.1 103 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type srcWidth The width of the source rectangle in pixels (decoded video uint stream coordinate). srcHeight The height of the source rectangle in pixels (decoded video uint stream coordinate).
Table 4-123: ConfigureWindowedVideoWindow command attributes
[4.8.2.5.8-2] M: RVU-C An RVU client shall respond to the ConfigureWindowedVideoWindow command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-124: ConfigureWindowedVideoWindow response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BOUNDING The region specified by x, y, width, and height does not fit in the output, or the region specified by srcX, srcY, srcWidth, or srcHeight does not fit in the decoded AV stream. ERR_BAD_ID The specified buffer is not a valid video buffer.
Table 4-125: ConfigureWindowedVideoWindow response error codes
4.8.2.5.9 ConfigureVideoDecodeResolution The ConfigureVideoDecodeResolution command is used to configure the maximum output resolution decimation on a video buffer (for instance, only outputting an SD version of an HD input).
[4.8.2.5.9-1] M: RVU-S An RVU server shall have the ability to send the ConfigureVideoDecodeResolution command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID, as returned by GetVideoBuffer. uint xRes Non-zero: The maximum horizontal resolution allowed for the uint buffer. Zero (0): Unrestricted decode.
V1.0 Rev 1.5.1 104 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type yRes Non-zero: The maximum vertical resolution allowed for the uint buffer. Zero (0): Unrestricted decode.
Table 4-126: ConfigureVideoDecodeResolution command attributes
[4.8.2.5.9-2] M: RVU-C An RVU client shall respond to the ConfigureVideoDecodeResolution command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-127: ConfigureVideoDecodeResolution response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer is not a valid video buffer.
Table 4-128: ConfigureVideoDecodeResolution response error codes
4.8.2.5.10 BlindVideo The BlindVideo command is used to enable and disable blinding of an AV stream. When blinded, the video should be displayed as a single rectangle transparent to the background color buffer, instead of video.
[4.8.2.5.10-1] M: RVU-S An RVU server shall have the ability to send the BlindVideo command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID, as returned by GetVideoBuffer. uint blind Non-zero: blind the video. uint Zero (0): unblind the video.
Table 4-129: BlindVideo command attributes
V1.0 Rev 1.5.1 105 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.5.10-2] M: RVU-C An RVU client shall blind the video (display the video buffer as a single rectangle transparent to the background color buffer) if the blind attribute of the BlindVideo command is set to a value other than zero (0).
[4.8.2.5.10-3] M: RVU-C An RVU client shall not blind the video (i.e., display video normally) if the blind attribute of the BlindVideo command is set to a value of zero (0).
[4.8.2.5.10-4] M: RVU-C An RVU client shall respond to the BlindVideo command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-130: BlindVideo response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer is not a valid video buffer.
Table 4-131: BlindVideo response error codes
4.8.2.5.11 GetOutputSettings The GetOutputSettings command is used to determine the output resolution of the output canvas.
[4.8.2.5.11-1] M: RVU-S An RVU server shall have the ability to send the GetOutputSettings command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-132: GetOutputSettings command attributes
[4.8.2.5.11-2] M: RVU-C An RVU client shall respond to the GetOutputSettings command by returning the commandToken, appropriate errCode, and output settings as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint
V1.0 Rev 1.5.1 106 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type errCode See error code table below. string xRes The horizontal width in pixels of the output canvas. uint yRes The vertical height in pixels of the output canvas. uint fps The number of frames per second that the screen displays. string Non-integer values (e.g., not 24, 30, or 60) are allowed to two decimal places (e.g., 29.97, 59.94).
Table 4-133: GetOutputSettings response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-134: GetOutputSettings response error codes
4.8.2.5.12 OutputSettingsChanged The OutputSettingsChanged command is sent by a client at the beginning of an RVU session, whenever the output canvas resolution changes, or when client capabilities as listed in the GetGraphicsCaps attribute list have changed within a single session.
[4.8.2.5.12-1] M: RVU-C An RVU client shall have the ability to send the OutputSettingsChanged command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint xRes The horizontal width in pixels of the output canvas. uint yRes The vertical height in pixels of the output canvas. uint fps The number of frames per second that the screen displays. string Non-integer values (e.g., not 24, 30, or 60) are allowed to two decimal places (e.g., 29.97, 59.94). capabilitiesChanged 0: Indicates no changes uint Non-zero: Indicates to server that the client’s supported operations, capabilities or parameters, as listed in the GetGraphicsCaps command attribute list, have changed,
Table 4-135: OutputSettingsChanged command attributes
[4.8.2.5.12-2] M: RVU-C An RVU client shall send an OutputSettingsChanged command:
at the beginning of an RVU session after successfully completing a Hello command but before configuring a Display Buffer whenever the output canvas resolution changes within a single session V1.0 Rev 1.5.1 107 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
when client capabilities as listed in the GetGraphicsCaps attribute list have changed within a single session
[4.8.2.5.12-3] M: RVU-S An RVU server shall send a GetGraphicsCaps command to a client after receiving an OutputSettingsChanged command with the capabilitiesChanged flag set to a non-zero value.
[4.8.2.5.12-4] M: RVU-S An RVU server shall respond to the OutputSettingsChanged command by returning the commandToken and appropriate errCode as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-136: OutputSettingsChanged response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-137: OutputSettingsChanged response error codes
4.8.2.5.13 GetVideoDisplaySettings The GetVideoDisplaySettings command is used to determine the position and dimensions of the video buffer. This defines the current aspect ratio, display position, native decoded resolution, and decimated resolution of a video buffer.
[4.8.2.5.13-1] M: RVU-S An RVU server shall have the ability to send the GetVideoDisplaySettings command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID as returned by GetVideoBuffer. uint
Table 4-138: GetVideoDisplaySettings command attributes
[4.8.2.5.13-2] M: RVU-C An RVU client shall respond to the GetVideoDisplaySettings command by returning the commandToken, appropriate errCode, and buffer settings as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string V1.0 Rev 1.5.1 108 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type x The horizontal position of the buffer (in output canvas space uint coordinates). y The vertical position of the buffer (in output canvas space uint coordinates). width The display width of the buffer in pixels when projected onto uint the output canvas. height The display height of the buffer in pixels when projected onto uint the output canvas. xRes The decoded horizontal width in pixels of the buffer uint (decoded video stream coordinate). yRes The decoded vertical height in pixels of the buffer (decoded uint video stream coordinate). xDisplayRes The post-decimation horizontal resolution of the buffer uint (decoded video stream coordinate). yDisplayRes The post-decimation vertical resolution of the buffer uint (decoded video stream coordinate). inputX The horizontal position of the decoded video being uint displayed, in decoded resolution coordinates. With inputY, inputWidth and inputHeight, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. inputY The vertical position of the decoded video being displayed, uint in decoded resolution coordinates. With inputX, inputWidth and inputHeight, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. inputWidth The horizontal width in pixels of the decoded video being uint displayed, in decoded resolution coordinates. With inputX, inputY and inputHeight, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. inputHeight The vertical height in pixels of the decoded video being uint displayed, in decoded resolution coordinates. With inputX, inputY and inputWidth, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. blind 0: Normal display uint 1: Blacked out
Table 4-139: GetVideoDisplaySettings response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified ID is not a valid video buffer. V1.0 Rev 1.5.1 109 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Table 4-140: GetVideoDisplaySettings response error codes
4.8.2.5.14 VideoDisplaySettingsChanged The VideoDisplaySettingsChanged command is sent by a client whenever there is a change in the display information for a video buffer.
[4.8.2.5.14-1] M: RVU-C An RVU client shall have the ability to send the VideoDisplaySettingsChanged command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The video buffer ID, as returned by GetVideoBuffer. uint x The horizontal position of the buffer (in output canvas space uint coordinates). y The vertical position of the buffer (in output canvas space uint coordinates). width The display width of the buffer in pixels (in output canvas uint space coordinates). height The display height of the buffer in pixels (in output canvas uint space coordinates). xRes The decoded horizontal width in pixels of the buffer uint (decoded video stream coordinate). yRes The decoded vertical height in pixels of the buffer (decoded uint video stream coordinate). xDisplayRes The post-decimation horizontal resolution of the buffer uint (decoded video stream coordinate). yDisplayRes The post-decimation vertical resolution of the buffer uint (decoded video stream coordinate). inputX The horizontal position of the decoded video being uint displayed, in decoded resolution coordinates. With inputY, inputWidth and inputHeight, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. inputY The vertical position of the decoded video being displayed, uint in decoded resolution coordinates. With inputX, inputWidth and inputHeight, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. inputWidth The horizontal width in pixels of the decoded video being uint displayed, in decoded resolution coordinates. With inputX, inputY and inputHeight, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output.
V1.0 Rev 1.5.1 110 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type inputHeight The vertical height in pixels of the decoded video being uint displayed, in decoded resolution coordinates. With inputX, inputY and inputWidth, the coordinates will specify a viewport within the decoded video coordinate space which is being displayed on the output. blind 0: Normal display uint 1: Blacked out
Table 4-141: VideoDisplaySettingsChanged command attributes
[4.8.2.5.14-2] M: RVU-S An RVU server shall respond to the VideoDisplaySettingsChanged command by returning the commandToken and appropriate errCode as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-142: VideoDisplaySettingsChanged response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-143: VideoDisplaySettingsChanged response error codes
4.8.2.5.15 AllowClosedCaptioning The AllowClosedCaptioning command is used to control whether closed captioning (CC) is allowed. Allowing closed captioning on a device where closed captioning has not been enabled (either by the user on the local display or with the EnableClosedCaptioning command) does nothing; only when the closed-captioning has been activated locally does this flag have any effect. This command also applies to DVB subtitling and SBTVD captioning.
The following table summarizes the interaction of AllowClosedCaptioning, EnableClosedCaptioning, and local closed captioning control:
AllowClosedCaptioning Most recent action: Display Result (EnableClosedCaptioning or Local CC Setting) 0 (disallow) N/A No CC shown 1 (allow) EnableClosedCaptioning (enable) or Local CC =On CC shown 1 (allow) EnableClosedCaptioning (disable) or Local CC =Off No CC shown
Table 4-144: Closed Captioning control
V1.0 Rev 1.5.1 111 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
It is the server’s responsibility to control CC display in relation to graphics drawing, e.g. if it is undesirable to have CC display over graphics, the server should send AllowClosedCaptioning with allow=0 before sending commands for drawing and display of graphics.
[4.8.2.5.15-1] M: RVU-S An RVU server shall have the ability to send the AllowClosedCaptioning command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint allow 0: Disallow closed captioning uint Non-zero: Allow closed captioning
Table 4-145: AllowClosedCaptioning command attributes
[4.8.2.5.15-2] M: RVU-C An RVU client shall display closed captioning if the allow attribute of the AllowClosedCaptioning command is set to a value other than zero (0), and the last action was either the receipt of an EnableClosedCaptioning (enable) command or local CC control was set on.
[4.8.2.5.15-3] M: RVU-C An RVU client shall not display closed captioning if the allow attribute of the AllowClosedCaptioning command is set to a value of zero (0), regardless of whether closed captioning is enabled locally or EnableClosedCaptioning is enabled.
[4.8.2.5.15-4] M: RVU-C An RVU client shall respond to the AllowClosedCaptioning command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-146: AllowClosedCaptioning response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-147: AllowClosedCaptioning response error codes
4.8.2.5.16 EnableClosedCaptioning The EnableClosedCaptioning command is used to enable/disable closed captioning on the local device. This command also applies to DVB subtitling and SBTVD captioning.
V1.0 Rev 1.5.1 112 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.5.16-1] M: RVU-S An RVU server shall have the ability to send the EnableClosedCaptioning command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint enable 0: Disable closed captioning uint Non-zero: Enable closed captioning
Table 4-148: EnableClosedCaptioning command attributes
[4.8.2.5.16-2] M: RVU-C An RVU client shall respond to the EnableClosedCaptioning command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-149: EnableClosedCaptioning response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-150: EnableClosedCaptioning response error codes
4.8.2.5.17 GetClosedCaptioningState The GetClosedCaptioningState command is used to query the state of closed captioning on the local device. This command also applies to DVB subtitling and SBTVD captioning.
[4.8.2.5.17-1] M: RVU-S An RVU server shall have the ability to send the GetClosedCaptioningState command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-151: GetClosedCaptioningState command attributes
[4.8.2.5.17-2] M: RVU-C An RVU client shall respond to the GetClosedCaptioningState command by returning the commandToken, allowed and enabled states, and appropriate errCode, as described in the following tables.
V1.0 Rev 1.5.1 113 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string allowed 0: Closed Captioning is disallowed (via AllowClosedCaptioning) uint Non-zero: Closed captioning is allowed enabled 0: Closed Captioning is not displaying uint Non-zero: Closed captioning is displaying language Optional string The literal “none”, or one of the standard ISO-639 (see [Ref43]) 3 character language codes. Indicates currently decoded DVB subtitling or SBTVD captioning language for Latin American clients.
Table 4-152: GetClosedCaptioningState response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-153: GetClosedCaptioningState response error codes
4.8.2.5.18 ReconfigureDisplayBuffer3DTV The ReconfigureDisplayBuffer3DTV command is used to configure the display buffer with a left eye region and a right eye region for 3DTV and destroys any data in the buffer before configuring. This command configures the logical dimensions, resolution and pixel format of the display buffer, as well as setting the 3DTV structure (full frame, side-by-side, or top-and- bottom). The rvu3DTVstructure attribute of this command also indicates how the video buffer is manipulated to create stereoscopic video pictures.
[4.8.2.5.18-1] M: RVU-S An RVU server shall have the ability to send the ReconfigureDisplayBuffer3DTV command as described in the following table and diagram.
Attribute Description Type commandToken A unique ID representing this command. uint rvu3DTVStructure The 3DTV structure. hex 0x00: (optional) Frame Packing (Full resolution for each eye/view) 0x01: Side-by-Side (Half resolution for each eye/view) 0x02: Top-and-Bottom (Half resolution for each eye/view) width The width in pixels of the right or the left eye region of the uint display buffer when projected onto the output canvas. The values are in the output canvas space coordinates..
V1.0 Rev 1.5.1 114 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type height The height in pixels of the right or the left eye region of the uint display buffer when projected onto the output canvas. The values are in the output canvas space coordinates. xRes The width in pixels of the display buffer that includes both the uint left and right eye regions. yRes The height in pixels of the display buffer that includes both uint the left and right eye regions. pixelFormat The pixel format ARGB-32 string leftX Optional uint The X position of the left eye region with respect to the buffer. If not provided by the RVU server, the RVU client shall use a value of 0. leftY Optional uint The Y position of the left eye region with respect to the buffer. If not provided by the RVU server, the RVU client shall use a value of 0. rightX Optional uint The X position of the right eye region with respect to the buffer. If not provided by the RVU server, the RVU client shall use a value of xRes/2. rightY Optional uint The Y position of the right eye region with respect to the buffer. If not provided by the RVU server, the RVU client shall use a value of 0. leftRightWidth Optional uint The width in pixels of the left eye and right eye regions with respect to the buffer. If not provided by the RVU server, the RVU client shall use a value of xRes/2. leftRightHeight Optional uint The height in pixels of the left eye and right eye regions with respect to the buffer. If not provided by the RVU server, the RVU client shall use a value of yRes. x Optional uint The horizontal (x) position for the buffer (in output canvas space coordinates). If not provided by the RVU server, the RVU client shall use a value of 0. y Optional uint The vertical (y) position for the buffer (in output canvas space coordinates). If not provided by the RVU server, the RVU client shall use a value of 0.
Table 4-154: ReconfigureDisplayBuffer3DTV command attributes
[4.8.2.5.18-2] M: RVU-S An RVU server shall ensure that the left and right eye regions within the display buffer do not overlap, i.e. (rightX >= leftX + leftRightWidth) or (rightY >= leftY+leftRightHeight),
V1.0 Rev 1.5.1 115 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.5.18-3] M: RVU-S An RVU server shall ensure that rvu3DTVStructure of Side-by-Side or Top-and-Bottom matches the orientation of the Left and Right Eye regions, i.e. for Side-by-Side rightX >= leftX + leftRightWidth, and for Top-and-Bottom, rightY >= leftY+leftRightHeight. For Frame Packing, the orientation of the eye regions is not restricted beyond not overlapping.
[4.8.2.5.18-4] M: RVU-C An RVU client shall process the ReconfigureDisplayBuffer3DTV command by configuring the display buffer as specified in the ReconfigureDisplayBuffer3DTV command.
[4.8.2.5.18-5] M: RVU-C An RVU client shall respond to the ReconfigureDisplayBuffer3DTV command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-155: ReconfigureDisplayBuffer3DTV response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_CONFIG The given pixelFormat is unknown or unsupported. ERR_OVERLAP The left eye and right eye graphics regions overlap. ERR_BOUNDING The display buffer with the specified dimensions and (optional) position does not fit in the dimensions of the output canvas. ERR_MISMATCH The orientation of the left and right graphics regions do not match the rvu3DTVStructure, e.g. rvu3DTVStructure is Side-by-Side but the Left and Right Eye Regions are oriented top and bottom. ERR_FAIL Failure not attributable to listed error causes
Table 4-156: ReconfigureDisplayBuffer3DTV response error codes
4.8.2.5.18.1 Example
The following provides an example of how ReconfigureDisplayBuffer3DTV might be used. The initial conditions are: The RVU Client reported its output canvas resolution using the OutputSettingsChanged event. The xRes was reported as 1920. The yRes was reported as 1080. The RVU Server uses 720x480 graphics buffers. When switching to stereoscopic structure, the RVU Client graphics buffer is going to be set to 1440x480 to provide space for the left eye region and right eye region.
V1.0 Rev 1.5.1 116 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
The desired 3DTV structure is obtained by the following attribute values sent in the ReconfigureDisplayBuffer3DTV command:
Attribute Value Description rvu3DTVStructure 0x01 Side-by-Side half resolution width 960 Cannot exceed one half of the horizontal width in pixels of the output canvas reported in OutputSettingsChanged. height 1080 Cannot exceed the vertical height in pixels of the output canvas reported in OutputSettingsChanged xRes 1440 Full width of the display buffer needed to hold the left and right eye regions. yRes 480 Full height of the display buffer needed to hold the left and right eye regions. pixelFormat ARGB-32 leftX 0 (default) leftY 0 (default) rightX 720 rightY 0 (default) leftRightWidth 720 leftRightHeight 480 x 0 (default) y 0 (default)
Table 4-157: ReconfigureDisplayBuffer3DTV example values
The ReconfigureDisplayBuffer3DTV and ReconfigureDisplayBuffer commands define the scaling and translation needed to transform the display buffer coordinates into output canvas coordinates.
V1.0 Rev 1.5.1 117 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Display Buffer
xRes (0,0)
(leftX, leftY) (rightX, rightY)
t
h
g
i
e
s
H t
Left Right e
h
R
g y
Eye Eye i
R t
Region Region f
e l
leftRightWidth leftRightWidth
width width (0,0)
(x,y)
d
e
g
n
a
h
C s
Display Buffer g
n
i
t
t t
t Transformed into the
e
h
h
g
g
S
i i
Output Canvas t
e
e
u
h
h p
Half Resolution t u
Side by Side O
m
o
r
f
s
e
R y
xRes from OutputSettingsChanged
Half Resolution Output Canvas
Figure 4-3: Half-Resolution Side-by-Side Output Canvas Display Using ReconfigureDisplayBuffer3DTV command (4.8.2.5.18.1 example) V1.0 Rev 1.5.1 118 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Display Buffer
xRes (0,0)
(leftX, leftY) (rightX, rightY)
t
h
g
i
e
s
H t
Left Right e
h
R
g y
Eye Eye i
R t
Region Region f
e l
leftRightWidth leftRightWidth
width
(0,0)
(x,y)
d
e
g
n
a
h
C
s
g n
Display Buffer i
t
t
t e
Transformed into the h
S
g
t
i u
Output Canvas e
p
h
t
u
O
m
o
r
f
s
e
R y
xRes from OutputSettingsChanged
Viewer Display / Full Resolution Output Canvas
Figure 4-4: Half and Full-Resolution Side-by-Side Viewer Display during Left Eye Mapping time Period Using ReconfigureDisplayBuffer3DTV command (4.8.2.5.18.1 example) V1.0 Rev 1.5.1 119 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Display Buffer
xRes (0,0)
(leftX, leftY) (rightX, rightY)
t
h
g
i
e
s
H t
Left Right e
h
R
g y
Eye Eye i
R t
Region Region f
e l
leftRightWidth leftRightWidth
width
(0,0)
(x,y)
d
e
g
n
a
h
C
s
g n
Display Buffer i
t
t
t e
Transformed into the h
S
g
t
i u
Output Canvas e
p
h
t
u
O
m
o
r
f
s
e
R y
xRes from OutputSettingsChanged
Viewer Display / Full Resolution Output Canvas
Figure 4-5: Half and Full-Resolution Side-by-Side Viewer Display during Right Eye Mapping time Period Using ReconfigureDisplayBuffer3DTV command (4.8.2.5.18.1 example) V1.0 Rev 1.5.1 120 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.5.19 Set3DTVFlattenStructure The Set3DTVFlattenStructure command indicates whether and how to replicate one of two stereoscopic video pictures to create 2D video effect. To flatten or remove 3DTV display buffer effects, the server will separately manipulate left and right display buffer pixels.
[4.8.2.5.19-1] M: RVU-S An RVU Server shall have the ability to send the Set3DTVFlattenStructure command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint flattenStructure Specify whether and how video buffers shall be manipulated to flatten, i.e. uint produce a 2D effect, or preserve 3DTV video: 0: Do not flatten, 3DTV video retained 1: Replicate left or top 3DTV video on both left/top and right/bottom output to produce the effect of 2D video 2: Replicate right or bottom 3DTV video on both left/top and right/bottom output to produce the effect of a 2D video
Table 4-158: Set3DTVFlattenStructure command attributes
[4.8.2.5.19-2] M: RVU-C An RVU client shall respond to the Set3DTVFlattenStructure command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-159: Set3DTVFlattenStructure response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_FAIL The operation failed.
Table 4-160: Set3DTVFlattenStructure response error codes
4.8.2.6 RUI Audio Commands in this section are used to handle audio for the user interface. Note that RUI audio is not protected content.
4.8.2.6.1 OpenAudioDecoder The OpenAudioDecoder command is used to get a new audio decoder ID suitable for later use in playing audio.
V1.0 Rev 1.5.1 121 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.6.1-1] M: RVU-S An RVU server shall have the ability to send the OpenAudioDecoder command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint index The audio decoder to open. This should be a value less than uint what is returned by a call to GetNumAudioDecoders.
Table 4-161: OpenAudioDecoder command attributes
[4.8.2.6.1-2] M: RVU-C An RVU client shall process the OpenAudioDecoder command by opening the specified audio decoder.
[4.8.2.6.1-3] M: RVU-C An RVU client shall respond to the OpenAudioDecoder command by returning the commandToken, appropriate errCode, and audio decoder ID as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string decoderId The ID of an audio decoder to use. uint
Table 4-162: OpenAudioDecoder response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The audio decoder could not be allocated.
Table 4-163: OpenAudioDecoder response error codes
4.8.2.6.2 CloseAudioDecoder The CloseAudioDecoder command is used to close a previously-opened audio decoder (as returned by OpenAudioDecoder).
[4.8.2.6.2-1] M: RVU-S An RVU server shall have the ability to send the CloseAudioDecoder command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
V1.0 Rev 1.5.1 122 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type decoderId The audio decoder to close. uint
Table 4-164: CloseAudioDecoder command attributes
[4.8.2.6.2-2] M: RVU-C An RVU client shall process the CloseAudioDecoder command by closing the specified audio decoder.
[4.8.2.6.2-3] M: RVU-C An RVU client shall respond to the CloseAudioDecoder command by returning the commandToken and appropriate errCode as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-165: CloseAudioDecoder response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The audio decoder could not be closed.
Table 4-166: CloseAudioDecoder response error codes
4.8.2.6.3 GetNumAudioDecoders The GetNumAudioDecoders command is used to get the number of audio decoders. Not all audio decoders are guaranteed to support the same audio formats; determining supported formats should be done by calling GetAudioDecoderCaps.
[4.8.2.6.3-1] M: RVU-S An RVU server shall have the ability to send the GetNumAudioDecoders command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint
Table 4-167: GetNumAudioDecoders command attributes
[4.8.2.6.3-2] M: RVU-C An RVU client shall respond to the GetNumAudioDecoders command by returning the commandToken, appropriate errCode, and number of audio decoders, as described in the following tables.
V1.0 Rev 1.5.1 123 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string count The number of audio decoders. uint
Table 4-168: GetNumAudioDecoders response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet.
Table 4-169: GetNumAudioDecoders response error codes
4.8.2.6.4 GetAudioDecoderCaps The GetAudioDecoderCaps command is used to get information about the capabilities of an audio decoder.
[4.8.2.6.4-1] M: RVU-S An RVU server shall have the ability to send the GetAudioDecoderCaps command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint decoderId The audio decoder to query for capabilities. uint
Table 4-170: GetAudioDecoderCaps command attributes
[4.8.2.6.4-2] M: RVU-C At a minimum, an RVU client shall decode these RUI audio encoded formats and containers:
44.1kHz and 48 kHz two channel PCM
MPEG1 layer 2 audio elementary streams as defined by ISO 11172-3 [Ref36]
MEPG1 layer 2 audio within an ISO 13818-1 [Ref18] PES container
[4.8.2.6.4-3] M: RVU-C For PCM RUI audio, the RVU client shall minimally support 16 bit uncompressed stereo PCM at 44.1 kHz and 48 kHz sample rates.
[4.8.2.6.4-4] M: RVU-C An RVU client shall respond to the GetAudioDecoderCaps command by returning the commandToken, appropriate errCode, and audio decoder capabilities, as described in the following tables.
V1.0 Rev 1.5.1 124 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string encodedFormats A bitmask of flags specifying which audio encoding hex formats are supported with this audio decoder. Flags are defined as follows: 0x01: MPEG1 Layer 2 elementary stream 0x02: MPEG1 Layer 3 (mp3) 0x04: PCM 0x08: AC3 0x10: DTS 0x20: MPEG2 AAC (ISO/IEC 13818-7:1997 [Ref33]) An AAC encoded audio stream within an ADTS transport. Only AAC-LC content is allowed when using this format 0x40: MPEG4 AAC (HE-AACv1, ISO/IEC 14496- 3:2001/Amd 1:2003 [Ref34]) An AAC encoded audio stream within an LOAS transport. All supported AAC profiles are allowed when using this format 0x80: AC3 Plus streamFormats A bitmask of flags specifying which audio stream formats hex are supported with this audio decoder. Flags are defined as follows: 0x01: MPEG elementary stream (no container) 0x02: MPEG2 PES, ISO/IEC 13818-1 [Ref18] 0x04: MPEG1 PACKET, ISO/IEC 11172-1 [Ref32] 0x08: PCM 0x10: MP4 MPEG-4 Part 14, ISO/IEC 14496- 14:2003 [Ref35] pcmFlags Required if and only if the PCM flag is set in the hex encodedFormats attribute. A bitmask of flags representing the PCM playback capabilities of this audio decoder. Flags are defined as follows: 0x01: Big-Endian 0x02: Little-Endian 0x04: Stereo 0x08: Mono 0x10: Signed 0x20: Unsigned
V1.0 Rev 1.5.1 125 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type pcmSampleRates Required if and only if the PCM flag is set in the hex encodedFormats attribute. A bitmask of flags representing the PCM sample rates that can be played back on this audio decoder. Flags are defined as follows: 0x001: 8 0x002: 11.025 0x004: 12 0x008: 16 0x010: 22.05 0x020: 24 0x040: 32 0x080: 44.1 0x100: 48 0x200: 64 0x400: 88.2 0x800: 96 pcmSampleSizes Required if and only if the PCM flag is set in the hex encodedFormats attribute. A bitmask of flags representing the PCM sample sizes (in bits) that can be played back on this audio decoder. Flags are defined as follows: 0x01: 16 0x02: 18 0x04: 20 0x08: 24
Table 4-171: GetAudioDecoderCaps response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified audio decoder ID is invalid.
Table 4-172: GetAudioDecoderCaps response error codes
4.8.2.6.5 AllocateAudioBuffer The AllocateAudioBuffer command is used to allocate an audio buffer in order to store an audio sample for playback.
[4.8.2.6.5-1] M: RVU-S An RVU server shall have the ability to send the AllocateAudioBuffer command as described in the following table.
V1.0 Rev 1.5.1 126 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type commandToken A unique ID representing this command. uint size The size, in bytes, of the buffer to allocate. uint
Table 4-173: AllocateAudioBuffer command attributes
[4.8.2.6.5-2] M: RVU-C An RVU client shall process the AllocateAudioBuffer command by creating an audio buffer of the requested size.
[4.8.2.6.5-3] M: RVU-C An RVU client shall respond to the AllocateAudioBuffer command by returning the commandToken, appropriate errCode, and ID of the newly-created buffer, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string bufId The ID of the new buffer. uint
Table 4-174: AllocateAudioBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The buffer could not be created.
Table 4-175: AllocateAudioBuffer response error codes
4.8.2.6.6 DeallocateAudioBuffer The DeallocateAudioBuffer command is used to release a previously allocated audio buffer that was allocated via the AllocateAudioBuffer command.
[4.8.2.6.6-1] M: RVU-S An RVU server shall have the ability to send the DeallocateAudioBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The buffer to release. uint
Table 4-176: DeallocateAudioBuffer command attributes
V1.0 Rev 1.5.1 127 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.6.6-2] M: RVU-C An RVU client shall process the DeallocateAudioBuffer command by deallocating the specified buffer.
[4.8.2.6.6-3] M: RVU-C An RVU client shall respond to the DeallocateAudioBuffer command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-177: DeallocateAudioBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been allocated yet by the AllocateAudioBuffer command.
Table 4-178: DellocateAudioBuffer response error codes
4.8.2.6.7 WriteAudioData The WriteAudioData command is used to write audio data into an audio buffer. The WriteAudioData command only defines information about what and how to write the data. The data itself comes from content via an associated data channel.
[4.8.2.6.7-1] M: RVU-S An RVU server shall have the ability to send the WriteAudioData command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint bufId The buffer to write audio data into. uint offset The byte offset within the buffer to begin writing. uint length The number of bytes to write. uint channelId The channel ID of the data channel on which the content will be uint sent.
Table 4-179: WriteAudioData command attributes
[4.8.2.6.7-2] M: RVU-C An RVU client shall process the WriteAudioData command by writing the audio data on the specified data channel to the specified buffer.
V1.0 Rev 1.5.1 128 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.6.7-3] M: RVU-C An RVU client shall respond to the WriteAudioData command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-180: WriteAudioData response attributes
Error Codes Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The specified buffer has not been identified yet. ERR_BOUNDING The audio data could not be written due to bounds checking.
Table 4-181: WriteAudioData response error codes
4.8.2.6.8 Play The Play command is used to play audio that is obtained from an associated data channel containing AudioData content.
[4.8.2.6.8-1] M: RVU-S An RVU server shall have the ability to send the Play command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint decoderId The audio decoder to play on. uint channelId The data channel to expect the AudioData content. uint configId Optional uint The ID returned from a previous play command indicating whether or not the configuration of parameters is identical meaning that this content is considered as part of the same audio stream. streamFormat Required if and only if the configId attribute is missing. hex The audio stream format of the audio. Choices are as follows: 0x01: MPEG elementary stream (no container) 0x02: MPEG2-PES, ISO/IEC 13818-1 [Ref18] 0x04: MPEG1-PACKET, ISO/IEC 11172-1 [Ref32] 0x08: PCM 0x10: MP4 MPEG-4 Part 14, ISO/IEC 14496- 14:2003 [Ref35]
V1.0 Rev 1.5.1 129 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type encodedFormat Required if and only if the configId attribute is missing. hex The audio encoding format of the audio. Choices are as follows: 0x01: MPEG1 Layer 2 elementary stream 0x02: MPEG1-LAYER3 (mp3) 0x04: PCM 0x08: AC3 0x10: DTS 0x20: MPEG2-AAC (ISO/IEC 13818-7:1997 [Ref33]) An AAC encoded audio stream within an ADTS transport. Only AAC-LC content is allowed when using this format 0x40: MPEG4-AAC (HE-AACv1, ISO/IEC 14496- 3:2001/Amd 1:2003 [Ref34]) An AAC encoded audio stream within an LOAS transport. All supported AAC profiles are allowed when using this format 0x80: AC3-PLUS pcmFlags Required if and only if the encodedFormat attribute exists hex and is set to PCM. A bitmask of flags representing the PCM playback characteristics for this audio. Flags are defined as follows: 0x01: Big-Endian 0x02: Little-Endian 0x04: Stereo 0x08: Mono 0x10: Signed 0x20: Unsigned pcmSampleRate Required if and only if the encodedFormat attribute exists hex and is set to PCM. The sample rate of the audio, in kHz. Choices are as follows: 0x001: 8 0x002: 11.025 0x004: 12 0x008: 16 0x010: 22.05 0x020: 24 0x040: 32 0x080: 44.1 0x100: 48 0x200: 64 0x400: 88.2 0x800: 96
V1.0 Rev 1.5.1 130 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type pcmSampleSize Required if and only if the encodedFormat attribute exists hex and is set to PCM. The sample size, in bits, of the audio. Choices are as follows: 0x01: 16 0x02: 18 0x04: 20 0x08: 24 streamId Required if and only if the streamFormat attribute exists uint and is set to MPEG2-PES or MPEG1-PACKET The identifier of the audio stream to decode. attenuation Required if and only if the configId attribute is missing. uint The relative attenuation for the playback on this audio sample. Valid range of this attribute is from 0 through 255 (8-bit uint).
Table 4-182: Play command attributes
[4.8.2.6.8-2] M: RVU-C An RVU client shall process the Play command by playing the audio data on the specified data channel using the specified decoder.
[4.8.2.6.8-3] M: RVU-C An RVU client shall respond to the Play command by returning the commandToken, appropriate errCode, and configId, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string configId A client-generated ID, used to identify this audio stream and uint configuration.
Table 4-183: Play response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The audio decoder has not been opened yet. ERR_BAD_CONFIG The decoder does not support the specified configuration.
Table 4-184: Play response error codes
V1.0 Rev 1.5.1 131 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
4.8.2.6.9 PlayBuffer The PlayBuffer command is used to start the playback of audio located in the specified audio buffer.
[4.8.2.6.9-1] M: RVU-S An RVU server shall have the ability to send the PlayBuffer command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint decoderId The audio decoder to play on. uint bufId The buffer containing the audio to play. uint length Optional uint The number of bytes to play from the buffer. If not present, play to the end of the buffer. offset Optional uint Play from the buffer starting at this location. If not present, play from the beginning of the buffer. configId Optional uint The ID returned from a previous play command indicating whether or not the configuration of parameters is identical meaning that this content is considered as part of the same audio stream. streamFormat Required if and only if the configId attribute is missing. hex The audio stream format of the audio. Choices are as follows: 0x01: MPEG elementary stream (no container) 0x02: MPEG2-PES, ISO/IEC 13818-1 [Ref18] 0x04: MPEG1-PACKET, ISO/IEC 11172-1 [Ref32] 0x08: PCM 0x10: MP4 MPEG-4 Part 14, ISO/IEC 14496- 14:2003 [Ref35] encodedFormat Required if and only if the configId attribute is missing. hex The audio encoding format of the audio. Choices are as follows: 0x01: MPEG1 Layer 2 elementary stream 0x02: MPEG1-Layer3 (mp3) 0x04: PCM 0x08: AC3 0x10: DTS 0x20: MPEG2-AAC (ISO/IEC 13818-7:1997 [Ref33]) An AAC encoded audio stream within an ADTS transport. Only AAC-LC content is allowed when using this format 0x40: MPEG4-AAC (HE-AACv1, ISO/IEC 14496- 3:2001/Amd 1:2003 [Ref34]) An AAC encoded audio stream within an LOAS transport. All supported AAC profiles are allowed when using this format 0x80: AC3-PLUS
V1.0 Rev 1.5.1 132 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Attribute Description Type pcmFlags Required if and only if the encodedFormat attribute exists hex and is set to PCM. A bitmask of flags representing the PCM playback characteristics for this audio. Flags are defined as follows: 0x01: Big-Endian 0x02: Little-Endian 0x04: Stereo 0x08: Mono 0x10: Signed 0x20: Unsigned pcmSampleRate Required if and only if the encodedFormat attribute exists hex and is set to PCM. The sample rate of the audio, in kHz. Choices are as follows: 0x001: 8 0x002: 11.025 0x004: 12 0x008: 16 0x010: 22.05 0x020: 24 0x040: 32 0x080: 44.1 0x100: 48 0x200: 64 0x400: 88.2 0x800: 96 pcmSampleSize Required if and only if the encodedFormat attribute exists hex and is set to PCM. The sample size, in bits, of the audio. Choices are as follows: 0x01: 16 0x02: 18 0x04: 20 0x08: 24 streamId Required if and only if the streamFormat attribute exists uint and is set to MPEG2-PES or MPEG1-PACKET. The identifier of the audio stream to decode. attenuation Required if and only if the configId attribute is missing. uint The relative attenuation for the playback on this audio sample. Valid range of this attribute is from 0 through 255.
Table 4-185: PlayBuffer command attributes
[4.8.2.6.9-2] M: RVU-C An RVU client shall process the PlayBuffer command by playing the audio data (either all or a portion, as defined by the optional length and offset attributes) from the specified buffer using the specified decoder.
V1.0 Rev 1.5.1 133 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.6.9-3] M: RVU-C An RVU client shall respond to the PlayBuffer command by returning the commandToken, appropriate errCode, and configId, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string configId A client-generated ID, used to identify this audio stream and uint configuration.
Table 4-186: PlayBuffer response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The audio decoder has not been opened yet. ERR_BAD_CONFIG The decoder does not support the specified configuration.
Table 4-187: PlayBuffer response error codes
4.8.2.6.10 PlayStatus The PlayStatus command is used to communicate the progress of an audio playback from an audio player back to its controller.
[4.8.2.6.10-1] M: RVU-C An RVU client shall have the ability to send the PlayStatus command as described in the following tables.
Attribute Description Type commandToken A unique ID representing this command. uint decoderId The audio decoder that triggered this event. uint playCommandToken The commandToken attribute value from the Play or uint PlayBuffer command that started this playback. status Status of playback. See status table below for a complete string explanation. Choices are: TransferComplete SampleComplete PlayError
Table 4-188: PlayStatus command attributes
Status Values Status Value Description TransferComplete Sent when the data for the audio sample has been received. V1.0 Rev 1.5.1 134 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Status Value Description SampleComplete Sent when the audio sample has completed play. PlayError Sent if the transfer of audio data has been interrupted or if a Stop command has been received.
Table 4-189: PlayStatus status values
[4.8.2.6.10-2] M: RVU-S An RVU server shall respond to the PlayStatus command by returning the commandToken and appropriate errCode as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-190: PlayStatus response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_BAD_ID No Play or PlayBuffer command is associated with the given playCommandToken attribute value.
Table 4-191: PlayStatus response error codes
4.8.2.6.11 Stop The Stop command is used to halt an in-progress Play or PlayBuffer command.
[4.8.2.6.11-1] M: RVU-S An RVU server shall have the ability to send the Stop command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint decoderId The audio decoder to stop. uint
Table 4-192: Stop command attributes
[4.8.2.6.11-2] M: RVU-C An RVU client shall respond to the Stop command by returning the commandToken and appropriate errCode as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
V1.0 Rev 1.5.1 135 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Table 4-193: Stop response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded or there was nothing playing on the specified decoder. ERR_INVALID_STATE The channel has not been identified yet. ERR_BAD_ID The audio decoder has not been opened yet.
Table 4-194: Stop response error codes
4.8.2.7 Program Audio
4.8.2.7.1 MuteProgramAudio The MuteProgramAudio command enables or disables the audio of a program (but does not affect the RUI audio). A program audio mute invoked by this command shall not be overridden by any client or UPnP control point unmute action. In addition, a program audio unmute invoked by this command shall not override any client or UPnP control point mute action. This means the following:
Program audio command Other client mute action Output audio mute mute none mute unmute RUI and any other audio, but no program audio unmute mute none unmute unmute Program, RUI and any other audio
Table 4-195: MuteProgramAudio scenarios
[4.8.2.7.1-1] M: RVU-S An RVU server shall have the ability to send the MuteProgramtAudio command as described in the following table.
Attribute Description Type commandToken A unique ID representing this command. uint mute Zero (0): unmute uint Non-zero: mute
Table 4-196: MuteProgramAudio command attributes
[4.8.2.7.1-2] M: RVU-C An RVU client shall mute the program audio if the mute attribute of the MuteProgramAudio command is set to a value other than zero (0).
V1.0 Rev 1.5.1 136 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
[4.8.2.7.1-3] M: RVU-C An RVU client shall unmute the program audio if the mute attribute of the MuteProgramAudio command is set to a value of zero (0).
[4.8.2.7.1-4] M: RVU-C An RVU client shall respond to the MuteProgramAudio command by returning the commandToken and appropriate errCode, as described in the following tables.
Attribute Description Type commandToken The same commandToken ID sent in the command. uint errCode See error code table below. string
Table 4-197: MuteProgramAudio response attributes
Error Codes
Error Code Description ERR_SUCCESS The operation succeeded. ERR_INVALID_STATE The channel has not been identified yet. ERR_FAIL The audio decoder returned an error.
Table 4-198: MuteProgramAudio response error codes
4.8.3 Missing or Invalid Parameters All commands expect required or optional parameters as specified in the command details for each command.
[4.8.3-1] M: RVU-S, RVU-C If an RVU element receives a command that is missing any expected parameters, the element shall immediately send a command response with an ERR_MISSING_PARAM error code.
[4.8.3-2] M: RVU-S, RVU-C If an RVU element receives a command that contains an expected parameter that has an inappropriate value according to the specification, the element shall immediately send a command response with an ERR_INVALID_PARAM error code.
4.8.4 Examples This section contains examples of the commands that would be used for common scenarios. Responses (indicated with dotted lines) are only shown in the sequence diagrams when parameters are passed; all other responses are implied.
4.8.4.1 Startup, No Video
Synopsis No. Description Command from Client Command from Server 1 Startup Hello — 2 Discover capabilities — GetGraphicsCaps V1.0 Rev 1.5.1 137 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
3 Configure display — ReconfigureDisplayBuffer
Table 4-199: Startup, No Video Sequence
Sequence Diagram
Client Server
Hello
GetGraphicsCaps
ReconfigureDisplayBuffer
Figure 4-6: Startup, No Video Sequence
4.8.4.2 Startup, One Video
Synopsis No. Description Command from Client Command from Server 1 Startup Hello — 2 Discover capabilities — GetGraphicsCaps 3 Set up video display — GetVideoBuffer 4 Discover full-screen video OutputSettingsChanged — geometry 5 Resolution, aspect ratio, and VideoDisplaySettingsChanged — position of the displayed video stream 6 Configure display — ReconfigureDisplayBuffer
Table 4-200: Startup, One Video Sequence
V1.0 Rev 1.5.1 138 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Sequence Diagram
Client Server
Hello
GetGraphicsCaps
GetVideoBuffer
OutputSettingsChanged
VideoDisplaySettingsChanged
ReconfigureDisplayBuffer
Figure 4-7: Startup, One Video Sequence
4.8.4.3 Single Video, Aspect Change
Synopsis No. Description Command from Client Command from Server 1 Format change OutputSettingsChanged — 2 Match display buffer to video — ReconfigureDisplayBuffer display
Table 4-201: Single Video, Aspect Change Sequence
Sequence Diagram
Client Server
OutputSettingsChanged
ReconfigureDisplayBuffer
Figure 4-8: Single Video, Aspect Change Sequence
4.8.4.4 Single Video, Output Format Change
Synopsis No. Description Command from Client Command from Server 1 Format change OutputSettingsChanged — 2 Disallow HD output — ConfigureVideoDecodeResolution 3 Match display buffer to — ReconfigureDisplayBuffer video display
Table 4-202: Single Video, Output Format Change Sequence
V1.0 Rev 1.5.1 139 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Sequence Diagram
Client Server
OutputSettingsChanged
ConfigureVideoDecodeResolution
ReconfigureDisplayBuffer
Figure 4-9: Single Video, Output Format Change Sequence
4.9 Data Types The following is a list of all data types that may be sent on a data channel, together with a list of all commands that use each data type.
An RVU element shall support the sending and processing of the data types as indicated in the "Req" column in the following table.
Req frame_type_id Content Details Commands That Use This Type [4.9-1] Hello ASCII The channel ID of the data None M: RVU-S, digits channel. RVU-C [4.9-2] PixelData Graphics Pixels representing graphics. Write M: RVU-S, For the Write command, the Read RVU-C number of pixels specified in the data frame must fill the entire area specified by the command. The total number of bytes in the body of the data frame must be bytesPerPixel * width * height. [4.9-3] CompressedPixelData Graphics Compressed pixel data Write M: RVU-S, representing graphics, encoded in Read RVU-C the zlib format with the “deflate" compression mechanism (see RFC 1950 [Ref13] and 1951 [Ref14]). This is the same as the HTTP/1.1 “deflate" content-coding method. After decompression, the pixel format must be as specified in the configuration for the destination buffer. For the Write command, the number of pixels must be exactly the full area specified in the command.
V1.0 Rev 1.5.1 140 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Remote User Interface
Req frame_type_id Content Details Commands That Use This Type [4.9-4] JPEGPixelData Graphics Pixels representing graphics, Write M: RVU-S, encoded in JPEG format. After RVU-C decoding and decompression, the pixel format must be as specified in the configuration for the destination buffer. The number of pixels specified in the data frame must be exactly the full entire area specified by the Write command. [4.9-5] PNGPixelData Graphics Pixels representing graphics, Write M: RVU-S, encoded in PNG format. After RVU-C decoding and decompression, the pixel format must be as specified in the configuration for the destination buffer. The number of pixels specified in the data frame must be exactly the full entire area specified by the Write command. [4.9-6] CLUT CLUT Binary CLUT data, each entry is SetCLUT M: RVU-S, sent as a 32-bit ARGB-32 RVU-C formatted color. [4.9-7] AudioData Audio Raw audio data, formatted as per Play M: RVU-S, configuration in the associated Play RVU-C command. Since the Play command does not include an explicit size, the body size here is the only indicator of the sample size.
Table 4-203: Data Types and Commands
V1.0 Rev 1.5.1 141 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
5 Media Transfer
The Media Transfer sub-protocol of RVU describes the delivery of audio and visual media from the server to the client. This includes both live and recorded content. For example, when a user selects something to watch, the server receives the user’s remote key presses (via RUI), tunes to the selected content, and begins streaming renderable data (e.g., video and audio) to the client. The client is then responsible for rendering the data for presentation to the user.
Media Transfer also defines how to handle trick play functionality. Trick play commands are processed by the server, which responds by invoking AVTransport actions on the client. The client responds to these actions by initiating one or more HTTP message exchanges, ultimately resulting in a state transition. If the final state is PLAYING or PAUSED_PLAYBACK, the server sends the client a modified data stream to reflect the requested trick play function.
RVU’s Media Transfer sub-protocol defines state transitions (e.g., “Stopped to Normal Playback”) that form the building blocks of all actions that can be taken through this protocol. These state transitions are described in detail in the section which follows.
Media Transfer makes use of DLNA, UPnP AV Media, and HTTP technologies. Encrypted streaming data is sent from server to client using DTCP copy link protection to ensure that the content remains secure throughout the RVU system.
The RVU media transfer protocol employs DLNA media transfer using UPnP, with some restrictions and exceptions. Media management is handled via HTTP. The protocol is designed to support the following logical media operations: Normal playback Stop Fast forward scan Fast Rewind scan Slow forward scan Frame step forward Pause and resume/release Time-based position seeking
RVU employs the DLNA v1.5 [Ref10] Two-Box Push Controller System Usage. In this model, an RVU server acts as the Push Controller (+PU+) while an RVU client acts as a Digital Media Renderer (DMR).
RVU elements may also employ a DLNA 3-Box System Usage. For example an RVU server may act as a Digital Media Controller, select content from a Media Server and set up a connection for the selected content between the RVU client DMR and the Media Server.
The DLNA requirements used by the RVU media transfer protocol are listed in section 5.1. The media transfer protocol’s state transitions are detailed in section 5.2. The use of DTCP to encrypt content streamed to the client is described in section 5.3. Clock Synchronization is described in section 5.4. V1.0 Rev 1.5.1 142 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
5.1 Standards The DLNA features upon which RVU's media transfer protocol is based are summarized in this section. In addition, the AVTransport actions invoked on the client, as well as the HTTP messages exchanged between client and server, are also summarized in this section.
Components involved in RVU's media transfer protocol are shown in Figure 5-1. The HTTP components are highlighted in green; the UPnP components are shaded yellow.
RVU Client RVU Server
Rendering Control UPnP
UPnP Stack Connection Manager UPnP Control Point UPnP Stack
AV Transport UPnP
HTTP Client HTTP HTTP Server
RVU RUI Client RUI Protocol RVU RUI Server
Figure 5-1: Media Transfer Components
5.1.1 DLNA Requirements
[5.1.1-1] M: RVU-S An RVU server shall use an embedded UPnP Media Renderer Control Point and Push Controller per DLNA v1.5 [Ref10].
[5.1.1-2] M: RVU-C An RVU client shall implement a DMR as defined by DLNA [Ref10].
An RVU element shall support the following DLNA [Ref10] features:
Req Feature [5.1.1-3] M: RVU-S, RVU-C DELETED [5.1.1-4] M: RVU-S, RVU-C Sender Pacing of data [5.1.1-5] M: RVU-S, RVU-C Streaming Transfer Mode [5.1.1-6] M: RVU-S, RVU-C Time-Based Seek Mode [5.1.1-7] M: RVU-S, RVU-C DTCP Link Protection [5.1.1-8] M: RVU-S, RVU-C Full Random Access Data Availability Model [5.1.1-9] M: RVU-S, RVU-C Limited Random Access Data Availability Model
V1.0 Rev 1.5.1 143 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Req Feature [5.1.1-10] M: RVU-S, RVU-C Play Media Operation [5.1.1-11] M: RVU-S, RVU-C Stop Media Operation [5.1.1-12] M: RVU-S, RVU-C Pause Media Operation [5.1.1-13] M: RVU-S, RVU-C Pause Release Media Operation [5.1.1-14] M: RVU-S, RVU-C Seek Media Operation [5.1.1-15] M: RVU-S, RVU-C Fast Forward Scan Media Operation [5.1.1-16] M: RVU-S, RVU-C Slow Forward Scan Operation [5.1.1-17] M: RVU-S, RVU-C Fast Backward Scan Media Operation
Table 5-1: RVU Element DLNA features supported
[5.1.1-18] M: RVU-C An RVU client shall implement support for generic HTTP URLs as required in draft DLNA Guidelines for extended DMRs.
5.1.2 HTTP Usage
[5.1.2-1] M: RVU-S, RVU-C An RVU Element shall support media transfer via DLNA HTTP Streaming Transfer Mode. Note: Streaming transfer mode is the only supported DLNA transfer mode.
[5.1.2-2] M: RVU-S, RVU-C An RVU element shall support the HTTP 1.1 protocol [Ref28].
Note: this protocol is used to transfer media from the server to the client.
5.1.2.1 Usage of DLNA Headers RVU utilizes a subset of available DLNA 1.5-defined HTTP headers [Ref10].
[5.1.2.1-1] M: RVU-S, RVU-C An RVU element shall have the ability to utilize the transferMode.dlna.org DLNA header.
[5.1.2.1-2] M: RVU-S, RVU-C An RVU element shall have the ability to utilize theTimeSeekRange.dlna.org DLNA header.
[5.1.2.1-3] M: RVU-S, RVU-C DELETED
[5.1.2.1-4] O: RVU-S, RVU-C An RVU element that recognizes HTTP headers beyond those utilized by RVU may interpret and use those headers. (RVU does not preclude the usage of additional headers by clients or servers.)
[5.1.2.1-5] M: RVU-S, RVU-C An RVU element shall gracefully ignore any additional unrecognized HTTP headers in accordance with DLNA, as noted in section 7 of [Ref10].
V1.0 Rev 1.5.1 144 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
[5.1.2.1-6] M: RVU-S The RVU server shall respond using the contentFeatures.dlna.org HTTP header in accordance with requirement [7.4.26.1] of ref. [10] if the RVU server receives an HTTP GET request with getcontentFeatures.dlna.org HTTP header.
5.1.3 Multi-Frame Media Scanning RVU provides a multi-frame extension to the “multiple HTTP GET requests with a specified TimeSeekRange.dlna.org header field” approach as defined by DLNA 1.5 section 7.4.62 and 7.4.64 [Ref10].
Instead of repeatedly seeking single frame play positions within a single HTTP GET request, the multi-frame scan mechanism allows the client to request N frames within a single HTTP GET and the server to deliver between zero and N frames spaced over a specified time interval.
5.1.3.1 Multi-Frame Media Scanning Requirements
5.1.3.1.1 Multi-Frame Requests
[5.1.3.1.1-1] S: RVU-C An RVU client should check bit 30 of the RVUalliance.org_flags prior to initiating multi-frame scan requests.
[5.1.3.1.1-2] M: RVU-C To initiate a multi-frame scan operation, an RVU client shall include the following headers within the HTTP GET request:
frameCount.rvualliance.org: This header indicates the number of frames the client wishes to receive for the TimeSeekRange.dlna.org time interval. TimeSeekRange.dlna.org: This header indicates the time interval from which the server must extract the frames returned in the response.
[5.1.3.1.1-3] M: RVU-S An RVU server shall indicate support for the multi-frame scan mechanism by the value of the multi-frame flag in the RVUALLIANCE.ORG_FLAGS parameter of the 4th res@protocolInfo field for a given media stream. See section 5.6.3.
[5.1.3.1.1-4] M: RVU-S An RVU server shall indicate the maximum number of frames that may be requested by the client for a Multi-Frame request in accordance with the requirements of section 5.6.4.
5.1.3.1.2 Multi-Frame Responses
[5.1.3.1.2-1] M: RVU-S An RVU server shall respond to a multi-frame scan operation request by including the following headers within the HTTP GET response:
frameCount.rvualliance.org: This header indicates the actual number of frames the server was able to provide within the response content.
V1.0 Rev 1.5.1 145 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
TimeSeekRange.dlna.org: This header indicates the time interval from which the provided frames were extracted. frameMap.rvualliance.org: This header provides the absolute time position for individual frames within the stream.
[5.1.3.1.2-2] M: RVU-S An RVU server shall conditionally include the frameMap.rvualliance.org header in the HTTP response to indicate a mapping between each frame returned and its absolute time position in the content stream.
[5.1.3.1.2-3] M: RVU-S If the value of frameCount.rvualliance.org is zero then an RVU server shall not include the frameMap.rvualliance.org header.
[5.1.3.1.2-4] M: RVU-S If the value of frameCount.rvualliance.org is non-zero then an RVU server shall include the frameMap.rvualliance.org header.
[5.1.3.1.2-5] M: RVU-S At the end of each frame entry an RVU server shall indicate the byte-offset of a frame within the frameMap.rvualliance.org response content.
[5.1.3.1.2-6] M: RVU-S An RVU server shall send frames in display order.
5.1.3.1.3 Format of Response data
[5.1.3.1.3-1] M: RVU-S The response data shall be a sequence of frames that comply with the definition of a random access point for that coding type.
For example, in the case of H.262/MPEG2 video, response content will consist of a sequence of I-Frames. In the case of H.264/MPEG4 AVC and H.265 HEVC video, the response content could consist of a sequence of IDR-Frames or I-Frames coded without P-Slice references to previous frames.
Note: The I-Frame sequence is delivered in the same transport container as the content stream, e.g. PES or ES.
5.1.3.1.4 Restrictions
[5.1.3.1.4-1] M: RVU-S The TimeSeekRange.dlna.org value returned in the response to a multi-frame request shall return a time range that starts at or before the requested start point and ends at or after the requested endpoint.
The value of frameCount.rvualliance.org in the response header is not required to match the value specified in the originating request.
V1.0 Rev 1.5.1 146 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
[5.1.3.1.4-2] O: RVU-S The RVU server may, based on its internal implementation, return a frameCount.rvualliance.org value greater than or less than the value specified in the request.
[5.1.3.1.4-3] S: RVU-S The RVU server should not return a frame count greater than the number of frames requested,
[5.1.3.1.4-4] S: RVU-S The RVU Server should attempt to return as many frames as possible up to the number of frames requested.
[5.1.3.1.4-5] O: RVU-S An RVU server may return a frameCount.rvualliance.org value equal to zero if it cannot locate any frames within the requested time range.
[5.1.3.1.4-6] M: RVU-S The RVU server shall return a value of frameCount.rvualliance.org that matches the actual number of frames returned in the content of the response.
Frames returned in the response content are not required to be equally distributed over the requested range.
[5.1.3.1.4-7] S: RVU-S An RVU server should return frames as uniformly distributed over the requested time range as practical.
[5.1.3.1.4-8] S: RVU-C If the RVU server returns a frame count less than the number of frames requested, the client should use those frames over the timeframe originally requested
[5.1.3.1.4-9] S: RVU-C An RVU client HTTP Get request which is subsequent to a previous Get request should use a start time coincident with the end time of the last Get request.
5.1.3.2 Multi-Frame Media Scanning Syntax
[5.1.3.2-1] M: RVU-S, RVU-C An RVU element shall conform to the following frameCount.rvualliance.org HTTP header syntax: frameCount.rvualliance.org: count count = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s
[5.1.3.2-2] M: RVU-S, RVU-C An RVU server shall conform to the following frameMap.rvualliance.org HTTP header syntax. The ‘frame-time’ value from any ’frame-entry’ indicates the absolute time of frame ‘count’ within the returned stream:
frame-list = # ( frame-entry )
V1.0 Rev 1.5.1 147 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
frame-entry = “Frame” ‘:’ count LWS frame-time LWS byte-offset count = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s frame-time = npt-time byte-offset = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s
Note: multiple frame entries are separated by LWS (linear white space, e.g. space, tab, etc).
Example frameMap.rvualliance.org: Frame:1 00:00:00.079 0 Frame:2 00:00:00.519 161492 Frame:3 00:00:01.039 399124 Frame:4 00:00:01.519 615136 Frame:5 00:00:02.039 828328
5.1.4 UPnP Requirements
[5.1.4-1] M: RVU-C An RVU client shall support UPnP’s AVTransport profile.
An RVU client shall employ the following UPnP AVTransport actions:
Req Action Specification [5.1.4-2] Pause( UPnP AVTransport:1, Service M: RVU-C InstanceID Template [Ref9], sections 2.4.10 ) & 2.2.30 [5.1.4-3] Play( [Ref9], sections 2.4.9, 2.2.30, & M: RVU-C InstanceID, 2.2.8 Speed ) [5.1.4-4] Seek( [Ref9], sections 2.4.12, 2.2.28, & M: RVU-C InstanceID, 2.2.29 Unit = "ABS_TIME" | "FRAME", Target ) [5.1.4-5] SetAVTransportURI( [Ref9], sections 2.4.1, 2.2.30, M: RVU-C InstanceID, 2.2.18, & 2.2.19 CurrentURI, CurrenttURIMetaData = "" ) [5.1.4-6] Stop( [Ref9], sections 2.4.8 & 2.2.30 M: RVU-C InstanceID )
Table 5-2: RVU Element UPnP AVTransport Actions
V1.0 Rev 1.5.1 148 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
5.2 State Transitions All media transfer functionality is handled by performing a sequence of AVTransport actions. Definitions of AVTransport actions can be found in [Ref9]. In order to provide seamless interoperability, RVU defines the precise implementation of a client's AVTransport Service. RVU also defines a precise implementation of the server's responses to client HTTP request that result from AVTransport actions.
The RVU protocol limits its usage of AVTransport to those states and transitions depicted in Figure 5-2.
NO_MEDIA_PRESENT
SetAVTransportURI Stop
Play PLAYING Stop PAUSED_PLAYBACK STOPPED Pause (Superstate) Play
Seek Seek, Play Seek
Figure 5-2: States and State Transitions
Each state transition begins in a given state, accepts some input that triggers the transition, and then transitions to the same or a different state. Any errors that occur are handled as defined by AVTransport for HTTP.
RVU decomposes the AVTransport PLAYING state into the following virtual substates (see Figure 5-3):
PLAYING_NORMAL PLAYING_SLOW PLAYING_FAST Correspondingly, RVU defines the following playback speed classes:
Normal Playback (PlaySpeed = 1) Slow Playback (-1 <= PlaySpeed < 0 || 0 < PlaySpeed < 1) Fast Playback (PlaySpeed < -1 || PlaySpeed > 1) Table 5-3 defines the RVU AVTransport states and allowed state transitions. Figure 5-3 provides a corresponding graphical representation of the RVU AVTransport states and virtual substates along with the valid RVU state transitions.
NOTE: virtual substates are so noted to signify they all represent states for playing, but are in every way full states with inbound and outbound transitions.
V1.0 Rev 1.5.1 149 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
FROM NO_MEDIA STOPPED PLAYING_ PLAYING_S PLAYING_ PAUSED_P PRESENT NORMAL LOW FAST LAYBACK TO SetAVTransport NO_MEDIA PRESENT URI STOPPED SetAVTransport SetAVTransport URI; Stop Stop Stop Stop URI Seek[Absolute Time] Seek[Absolu Play Play Play PLAYING_ Play[Normal] NORMAL te Time] [Normal] [Normal] [Normal] PLAYING_ Seek SLOW Play[Slow] Play[Slow] [Absolute Play[Slow] Play[Slow] Time] Seek[Absolu PLAYING_ Play[Fast] Play[Fast] Play[Fast] Play[Fast] FAST te Time] PAUSED_PL Seek AYBACK [Absolute Pause Pause Pause Time]; Seek[Frame Forward]
Table 5-3: RVU AVTransport State Transition Table
V1.0 Rev 1.5.1 150 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Play [Fast]
NO_MEDIA_PRESENT
SetAVTransportURI SetAVTransportURI Stop Stop
SetAVTransportURI Seek [Absolute Time]
STOPPED
Play [Fast] Play [Slow]
Stop Play [Fast] PLAYING_FAST Play [Normal] Play[Normal] PLAYING_SLOW
Play [Slow] Play [Normal] PLAYING_NORMAL Seek Seek [Absolute Time] [Absolute Time] Pause Seek [Absolute Time] PLAYING
Pause Play [Normal] Pause Play [Fast] Stop Play [Slow]
PAUSED_PLAYBACK
AVTransport: PAUSED_PLAYBACK Seek [Absolute Time], AVTransport: PLAYING Seek [Forward Frame] AVTransport: STOPPED
AVTransport: NO_MEDIA_PRESENT Play [Slow]
Figure 5-3: RVU AVTransport with Virtual Playing States
An RVU element shall support all state transitions summarized in the following table. The sections following the table provide detailed descriptions of the RVU-specified states, state transitions, and allowed operations per state.
No. Req Transition AVTransport Invoked Action AVTransport Error Name Initial State Final State Section1 1 [5.2.1.1] No Media to NO_MEDIA_ SetAVTransport STOPPED 2.4.1.4 M: RVU-S, New Media PRESENT URI() RVU-C Ready
V1.0 Rev 1.5.1 151 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
No. Req Transition AVTransport Invoked Action AVTransport Error Name Initial State Final State Section1 2 [5.2.1.2] Stopped to STOPPED SetAVTransport STOPPED 2.4.1.4 M: RVU-S, New Media URI() RVU-C Ready 3 [5.2.1.3] Stopped to STOPPED Play() PLAYING 2.4.9.4 M: RVU-S, Normal RVU-C Playback 4 [5.2.1.4] Stopped to STOPPED Play() PLAYING 2.4.9.4 M: RVU-S, Playing RVU-C Slow 5 [5.2.1.5] Stopped to STOPPED Play() PLAYING 2.4.9.4 M: RVU-S, Playing Fast RVU-C 6 [5.2.1.6] Seek While STOPPED Seek() STOPPED 2.4.12.4 M: RVU-S, Stopped RVU-C 7 [5.2.1.7] Playing PLAYING Play() PLAYING 2.4.9.4 M: RVU-S, Slow to RVU-C Normal Playback 8 [5.2.1.8] Playing PLAYING Play() PLAYING 2.4.9.4 M: RVU-S, Slow to RVU-C Playing Fast 9 [5.2.1.9] Playing PLAYING Pause() PAUSED_ 2.4.10.4 M: RVU-S, Slow to PLAYBACK RVU-C Paused 10 [5.2.1.10] Seek while PLAYING Seek() PLAYING 2.4.12.4 M: RVU-S, Playing RVU-C Slow 11 [5.2.1.11] Playing Fast PLAYING Play() PLAYING 2.4.9.4 M: RVU-S, to Normal RVU-C Playback 12 [5.2.1.12] Playing Fast PLAYING Play() PLAYING 2.4.9.4 M: RVU-S, to Playing RVU-C Slow 13 [5.2.1.13] Playing Fast PLAYING Pause() PAUSED_ 2.4.10.4 M: RVU-S, to Paused PLAYBACK RVU-C 14 [5.2.1.14] Seek While PLAYING Seek() PLAYING 2.4.12.4 M: RVU-S, Playing Fast RVU-C 15 [5.2.1.15] Normal PLAYING Play() PLAYING 2.4.9.4 M: RVU-S, Playback to RVU-C Playing Slow 16 [5.2.1.16] Normal PLAYING Play() PLAYING 2.4.9.4 M: RVU-S, Playback to RVU-C Playing Fast
V1.0 Rev 1.5.1 152 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
No. Req Transition AVTransport Invoked Action AVTransport Error Name Initial State Final State Section1 17 [5.2.1.17] Normal PLAYING Pause() PAUSED_ 2.4.10.4 M: RVU-S, Playback to PLAYBACK RVU-C Paused 18 [5.2.1.18] Seek While PLAYING Seek() PLAYING 2.4.12.4 M: RVU-S, Playing RVU-C 19 [5.2.1.19] Normal PLAYING Stop() STOPPED 2.4.8.4 M: RVU-S, Playback to RVU-C Stopped 20 [5.2.1.20] Seek While PAUSED_ Seek() PAUSED_ 2.4.12.4 M: RVU-S, Paused PLAYBACK PLAYBACK RVU-C 21 [5.2.1.21] Frame Step PAUSED_ Seek() PAUSED_ 2.4.12.4 M: RVU-S, While PLAYBACK PLAYBACK RVU-C Paused 22 [5.2.1.22] Paused to PAUSED_ Play() PLAYING 2.4.9.4 M: RVU-S, Normal PLAYBACK RVU-C Playback 23 [5.2.1.23] Paused to PAUSED_ Play() PLAYING 2.4.9.4 M: RVU-S, Playing PLAYBACK RVU-C Slow 24 [5.2.1.24] Paused to PAUSED_ Play() PLAYING 2.4.9.4 M: RVU-S, Playing Fast PLAYBACK RVU-C 25 [5.2.1.255.2. Paused to PAUSED_ Stop() STOPPED 2.4.8.4 1.26] Stopped PLAYBACK M: RVU-S, RVU-C 26 [5.2.1.26] Stopped to STOPPED SetAVTransport NO_MEDIA_P 2.4.1.4 M: RVU-S, No Media URI() RESENT RVU-C 1: Refers to the section of the AVTransport spec [Ref9] describing errors that can be encountered.
Table 5-4: Media Transfer State Transitions Summary
Each of these state transitions is described in detail in this section. Each state transition makes use of the AVTransport service plus HTTP messaging. The AVTransport service includes actions that are invoked; once invoked, each action responds (“events”) appropriately. HTTP communication between server and client is handled through requests and responses.
[5.2-8] M: RVU-S, RVU-C If an RVU element cannot accept an AVTransport::SetAVTransportURI request because the current value of the AVTransportState is not "STOPPED" or "NO_MEDIA_PRESENT", the element shall return error 705 (Transport is Locked).
V1.0 Rev 1.5.1 153 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Transition Notes Items italicized within brackets represent data to be filled in. For example, "CSeq:
Requirements for TimeSeekRange are defined in DLNA standard [Ref10], section 7.4.40.
TimeSeekRange.dlna.org entries in the description table and diagrams for Media State Transitions define the content of the "range specifier" and do not represent the exact syntax of this header.
The syntax of “npt-time” is defined in [Ref10], section 7.4.13.
Examples of a client TimeSeekRange request:
o TimeSeekRange.dlna.org: npt=3.5-5.0
o TimeSeekRange.dlna.org: npt=45.2-
Examples of a client TimeSeekRange response from server:
o TimeSeekRange.dlna.org: npt=3.4-5.1/*
o TimeSeekRange.dlna.org: npt=45.2-999/2400
Server responses always specify "instance duration" and client requests never specify instance duration (see [Ref10], section 7.4.40.3).
The argument CurrentURIMetaData for SetAVTransportURI is supplied using a DIDL-Lite XML fragment defined in the ContentDirectory service template [Ref21].
The AVTransportURI contained in the action SetAVTransportURI is unique for each client. This may be differentiated by a unique port number or by including a unique sessionId as part of the URI.
5.2.1 State Transition Details Note in the following sections, references to the PLAYING substates PLAYING_NORMAL, PLAYING_FAST and PLAYING_SLOW are for clarity only, Per section 5.2, the RVU protocol limits its usage of AVTransport to those states and state transitions depicted in Figure 5-2 and listed in Table 5-4.
5.2.1.1 NO_MEDIA_PRESENT to STOPPED (SetAVTransportURI) State: NO_MEDIA_PRESENT Action: SetAVTransportURI
V1.0 Rev 1.5.1 154 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Synopsys This transition describes a state change from the NO_MEDIA_PRESENT state to the STOPPED state.
Starting condition is a state such that no media URI has been selected for playback. Triggering input is an invocation of SetAVTransportURI. Resulting state is a state such that a media URI has been selected for playback but playback has not yet begun.
No. Description 1 The server invokes the client’s AVTransport::SetAVTransportURI action with the following arguments: InstanceID =
Table 5-5: No Media to Stopped Sequence
Sequence Diagram
Client Server
Play Mod AVT / HTTP Control Point HTTP
AVT::SetAVTransportURI
InstanceId =
AVT::LastChange
TransportState = STOPPED AVTransportURI =
Figure 5-4: No Media to Stopped Sequence
5.2.1.2 STOPPED to STOPPED (SetAVTransportURI) State: STOPPED Action: SetAVTransportURI
V1.0 Rev 1.5.1 155 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Synopsis This transition describes a state change from the STOPPED state to the STOPPED state for the purpose of changing the selected playback media.
Starting condition is a state in which a valid URI has been selected for playback but playback has not begun: STOPPED. Triggering input is an invocation of SetAVTransportURI. Resulting state is a state in which a valid URI has been selected for playback but playback has not begun: STOPPED.
No. Description 1 The server invokes the client’s AVTransport::SetAVTransportURI action with the following arguments: InstanceID =
Table 5-6: Stopped to Stopped (Ready) Sequence
Sequence Diagram
Client Server
Play Mod AVT / HTTP Control Point HTTP
AVT::SetAVTransportURI
InstanceId =
AVT:LastChange
AVTransportURI =
Figure 5-5: Stopped to Stopped (Ready) Sequence
5.2.1.3 STOPPED to PLAYING_NORMAL (Play [Normal]) State: STOPPED Action: Play
V1.0 Rev 1.5.1 156 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Synopsis This transition describes a state change from the STOPPED state to the PLAYING_NORMAL substate (PLAYING state) for the purpose of changing the selected playback media. Starting condition is a state in which a valid URI has been selected for playback but playback has not begun: STOPPED. Triggering input is an invocation of Play with a speed of 1. Resulting state is a state in which playback at normal playback speed is in progress: PLAYING
No. Description 1 The server invokes the client’s AVTransport::Play action with the following arguments: InstanceID =
The content contains the streaming media for the requested URI. 6 The client begins pulling data from the HTTP GET and feeding it to the decoder. 7 If/when the server reaches the end of stream and has sent the last byte of stream data to the client, the server sends a zero-size chunk to indicate the end of data 8 The client detects the end of data condition in the ongoing streaming HTTP transaction upon receiving the 0-sized chunk and so, upon draining the content buffer it: a. Sets its absolute playback position to "END_OF_MEDIA" b. Changes TransportState from PLAYING to STOPPED c. Issues an AVTransport::LastChange event with the following parameters: TransportState: STOPPED Note: “a” and ”b” should be done concurrently and must be done prior to “c”
9 The server issues an AVTransport::GetPositionInfo action and receives END_OF_MEDIA as the time position 10 The server raises the appropriate end of media event internally
Table 5-7: Stopped to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 157 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Sequence Diagram
Client Server
Play Mod AVT / HTTP Control Point HTTP
AVT::Play
InstanceId =
AVT::LastChange
TransportState = PLAYING TransportPlaySpeed = 1
Configure Configure decoder speed Configure no pacing Configure no clock synch
HTTP:GET
transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt=
HTTP:GET response
t
a
e p
e HTTP/1.1 200 OK
R transferMode.dlna.org: Streaming Data TimeSeekRange.dlna.org: ntp=
HTTP:GET response 0-sized chunk
AVT::LastChange
TransportState = STOPPED
AVT::GetPositionInfo
Figure 5-6: Stopped to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 158 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
5.2.1.4 STOPPED to PLAYING_SLOW (Play [Slow]) State: STOPPED Action: Play [Slow] Synopsis This transition describes a state change from the STOPPED state to the PLAYING_SLOW substate (PLAYING state) for the purpose of playing back content in slow motion. Starting condition is a state in which a valid URI has been selected for playback but playback has not begun: STOPPED. Triggering input is an invocation of Play with PlaySpeed value between -1 and 1 (ex 0). Resulting state is a state in which playback in slow motion is in progress: PLAYING.
No. Description 1 The server invokes the client’s AVTransport::Play action with the following arguments: InstanceID =
The content contains the streaming media for the requested URI. 6 The client begins reading the HTTP stream and feeding data into the decoder. 7 If/when the server reaches the end of stream and has sent the last byte of stream data to the client, the server sends a zero-size chunk to indicate the end of data 8 The client detects the end of data condition in the ongoing streaming HTTP transaction upon receiving the 0-sized chunk and so, upon draining the content buffer it:
a. Sets its absolute playback position to "END_OF_MEDIA" b. Changes TransportState from PLAYING to STOPPED c. Issues an AVTransport::LastChange event with the following parameters: TransportState: STOPPED Note: “a” and ”b” should be done concurrently and must be done prior to “c”
9 The server issues an AVTransport::GetPositionInfo action and receives END_OF_MEDIA as the time position 10 The server raises the appropriate end of media event internally Table 5-8: Stopped to Playing Slow Sequence
V1.0 Rev 1.5.1 159 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Sequence Diagram
Client Server
Play Mod AVT / HTTP Control Point HTTP
AVT::Play
InstanceId =
AVT::LastChange
TransportState = PLAYING TransportPlaySpeed =
Configure Configure decoder speed Configure no pacing Configure no clock synch
HTTP:GET
transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt=
HTTP:GET response
t
a
e p
e HTTP/1.1 200 OK
R transferMode.dlna.org: Streaming Data TimeSeekRange.dlna.org: ntp=
HTTP:GET response 0-sized chunk
AVT::LastChange
TransportState = STOPPED
AVT::GetPositionInfo
Figure 5-7: Stopped to Playing Slow Sequence
V1.0 Rev 1.5.1 160 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
5.2.1.5 STOPPED to PLAYING_FAST (Play [Fast]) State: STOPPED Action: Play [Fast]
Synopsis This transition describes a state change from the STOPPED state to the PLAYING_FAST substate (PLAYING state) for the purpose of scanning content in fast forward or fast reverse.
Starting condition is a state in which a valid URI has been selected for playback but playback has not begun: STOPPED. Triggering input is an invocation of Play with PlaySpeed value less than -1 or greater than 1. Resulting state is a state in which playback in fast reverse or fast forward scanning is in progress: PLAYING.
No. Description 1 The server embedded control point invokes the client’s AVTransport::Play action with the following arguments: InstanceID =
V1.0 Rev 1.5.1 161 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
No. Description 4 The client loops over the following sequence: 1. The client issues an HTTP GET with the following headers: frameCount.rvualliance.org:
2. The server issues an HTTP GET response with the following response headers: transferMode.dlna.org: Streaming frameCount.rvualliance.org:
The stream content is a sequence of frames as defined by the multi-frame scan operation definition.
3. For each frame, the client plays it out with 1/N second spacing between each frame.
4. When the client is Playing Fast reverse, and reaches the zero time position, then upon draining the content buffer, the client shall: a. Set the absoluteTimePosition to 00:00:00. b. Transition the TransportState to STOPPED. c. Event a single LastChange event for the TransportState variable. Note: “a” and” b” should be done concurrently and must be done prior to “c”.
5. If
At which point, upon draining the content buffer, the client shall: a. Set its absolute playback position to "END_OF_MEDIA". b. Change TransportState from PLAYING to STOPPED. c. Issue an AVTransport::LastChange event with the following parameters: TransportState: STOPPED Note: “a” and ”b” should be done concurrently and must be done prior to “c”
And the server shall then: d. Issue an AVTransport::GetPositionInfo action and receive END_OF_MEDIA as the time position e. Raise the appropriate end of media event internally.
Table 5-9: Stopped to Playing Fast Sequence
V1.0 Rev 1.5.1 162 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer
Sequence Diagram
Client Server
Play Mod AVT / HTTP Control Point HTTP
AVT::Play
InstanceId =
AVT:LastChange
TransportState = PLAYING TransportPlaySpeed = Configure Configure decoders Configure no pacing Configure no clock synch HTTP:GET frameCount.rvu.org: TimeSeekRange.dlna.org: npt= t a e p e R HTTP:GET response Data HTTP/1.1 200 OK transferMode.dlna.org: Streaming frameCount.rvu.org: HTTP:GET response eom-indicator.rvualliance.org: 1 AVT::LastChange TransportState = STOPPED AVT::GetPositionInfo Figure 5-8: Stopped to Playing Fast Sequence V1.0 Rev 1.5.1 163 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer 5.2.1.6 STOPPED to STOPPED (Seek [Absolute Time]) State: STOPPED Action: Seek Synopsis This transition describes a state change from the STOPPED state to the STOPPED state for the purpose of setting the absolute playback position of media. Starting condition is a state in which a valid URI has been selected for playback but playback has not begun: STOPPED. Triggering input is an invocation of Seek. Resulting state is a state in which a valid URI has been selected for playback, the absolute time position to start playback at has been updated to a new value but playback has not begun. No. Description 1 The server control point invokes the client’s AVTransport::Seek action with the following parameters: InstanceID = Note: From the Stopped state, the only supported Unit for seeking is absolute time. 2 Client updates its internal start time to the value represented by Target. Note: The client is currently not displaying video in this state. The Seek action is used to instruct the client to start at a time other than S0 when it initiates a Play action. Table 5-10: Stopped to Stopped (Seek) Sequence V1.0 Rev 1.5.1 164 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT:Seek InstanceId = Figure 5-9: Stopped to Stopped (Seek) Sequence 5.2.1.7 PLAYING_SLOW to PLAYING_NORMAL (Play [Normal]) State: PLAYING (PLAYING_SLOW substate) Action: Play [Normal] Synopsis This transition describes a state change from the PLAYING_SLOW substate (PLAYING state) to the PLAYING_NORMAL substate (PLAYING state) for the purpose of resuming normal playback from slow motion. Starting condition is a state in which slow motion playback is in progress: PLAYING. Triggering input is an invocation of Play with PlaySpeed value of 1. Resulting state is a state in which normal playback is in progress: PLAYING. No. Description: 1 The server invokes the client’s AVTransport::Play action with the following arguments: InstanceID = Table 5-11: Playing Slow to Normal-Speed Playing Sequence V1.0 Rev 1.5.1 165 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT:LastChange TransportPlaySpeed = 1 Configure Configure decoders Configure pacing Configure no clock synch t a HTTP: Paced Data e p Data e R Figure 5-10: Playing Slow to Normal-Speed Playing Sequence 5.2.1.8 PLAYING_SLOW to PLAYING_FAST (Play [Fast]) State: PLAYING (PLAYING_SLOW substate) Action: Play [Fast] Synopsis This transition describes a state change from the PLAYING_SLOW substate (PLAYING state) to the PLAYING_FAST substate (PLAYING state) for the purpose of fast forward or fast reverse scanning. Starting condition is a state in which slow motion playback is in progress: PLAYING. Triggering input is an invocation of Play with PlaySpeed value less than -1 or greater than 1. Resulting state is a state in which fast forward or fast reverse scanning is in progress: PLAYING. No. Description 1 The server embedded control point invokes the client’s AVTransport::Play action with the following arguments: V1.0 Rev 1.5.1 166 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer No. Description InstanceID = 2. The server issues an HTTP GET response for the requested content with the following headers: transferMode.dlna.org: Streaming frameCount.rvualliance.org: The stream content is a sequence of frames as defined by the multi-frame scan operation definition. 3. For each frame, the client plays it out with 1/N second spacing between each frame. 4. When the client is Playing Fast reverse, and reaches the zero time position, then upon draining the content buffer, the client shall: a. Set the absoluteTimePosition to 00:00:00. b. Transition the TransportState to STOPPED. c. Event a single LastChange event for the TransportState variable. Note: “a” and” b” should be done concurrently and must be done prior to “c”. 5. For END_OF_MEDIA sequence, see Table 5-9. Table 5-12: Playing Slow to Playing Fast Sequence V1.0 Rev 1.5.1 167 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = Configure Configure decoders Configure no pacing Configure no clock synch HTTP:GET frameCount.rvualliance.org: TimeSeekRange.dlna.org: npt=< time-range-requested> t a e p e R HTTP:GET response Data HTTP/1.1 200 OK transferMode.dlna.org: Streaming frameCount.rvualliance.org: Figure 5-11: Playing Slow to Playing Fast Sequence 5.2.1.9 PLAYING_SLOW to PAUSED_PLAYBACK (Pause) State: PLAYING (PLAYING_SLOW substate) Action: Pause Synopsis This transition describes a state change from the PLAYING_SLOW substate (PLAYING state) to the PAUSED_PLAYBACK state for the purpose of pausing. Starting condition is a state in which slow motion playback is in progress: PLAYING. Triggering input is an invocation of the Pause action. Resulting state is a state in which the media is paused on screen: PAUSED_PLAYBACK. V1.0 Rev 1.5.1 168 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer No. Description 1 The server control point invokes the client’s AVTransport::Pause action with the following arguments: InstanceID = Table 5-13: Playing Slow to Paused Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Pause InstanceId = Pause decoders Stall TCP AVT::LastChange TransportState = PAUSED_PLAYBACK Figure 5-12: Playing Slow to Paused Sequence 5.2.1.10 PLAYING_SLOW to PLAYING_SLOW (Seek [Absolute Time]) State: PLAYING (PLAYING_SLOW substate) Action: Seek V1.0 Rev 1.5.1 169 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Synopsis This transition describes a state change from the PLAYING_SLOW substate (PLAYING state) to the PLAYING_SLOW substate (PLAYING state) for the purpose of jumping to new positions while in slow motion. Starting condition is a state in which slow motion playback is in progress: PLAYING. Triggering input is an invocation of the Seek action with an absolute time position parameter. Resulting state is a state in which slow motion playback is in progress: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport::Seek action with the following arguments: InstanceID = Table 5-14: Playing Slow to Playing Slow (Seek) Sequence V1.0 Rev 1.5.1 170 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT:Seek InstanceId = Pause/Flush decoders HTTP:GET transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= HTTP:GET response HTTP/1.1 200 OK Configure transferMode.dlna.org: Streaming Configure decoders TimeSeekRange.dlna.org: npt= HTTP:GET response chunk t a e p e Data R Figure 5-13: Playing Slow to Playing Slow (Seek) Sequence 5.2.1.11 PLAYING_FAST to PLAYING_NORMAL (Play [Normal]) State: PLAYING (PLAYING_FAST substate) Action: Play [Normal] Synopsis This transition describes a state change from the PLAYING_FAST substate (PLAYING state) to the PLAYING_NORMAL substate (PLAYING state) for the purpose of resuming normal playback from the fast forward or fast rewind scanning mode. V1.0 Rev 1.5.1 171 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Starting condition is a state in which fast forward or fast rewind scan are in progress: PLAYING. Triggering input is an invocation of Play with PlaySpeed equal to 1. Resulting state is a state in which normal playback is in progress: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport::Play action with the following arguments: InstanceID = Table 5-15: Playing Fast to Normal-Speed Playing Sequence V1.0 Rev 1.5.1 172 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT:LastChange TransportState = PLAYING TransportPlaySpeed = 1 Configure Configure decoder speed Configure pacing Configure clock synch HTTP:GET transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= HTTP:GET response t a e p e HTTP/1.1 200 OK R transferMode.dlna.org: Streaming Data TimeSeekRange.dlna.org: npt= Figure 5-14: Playing Fast to Normal-Speed Playing Sequence 5.2.1.12 PLAYING_FAST to PLAYING_SLOW (Play [Slow]) State: PLAYING (PLAYING_FAST substate) Action: Play [Slow] Synopsis This transition describes a state change from the PLAYING_FAST substate (PLAYING state) to the PLAYING_SLOW substate (PLAYING state) for the purpose of playing in slow motion from the fast forward or fast rewind scanning mode. V1.0 Rev 1.5.1 173 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Starting condition is a state in which fast forward or fast rewind scan are in progress: PLAYING. Triggering input is an invocation of Play with PlaySpeed between -1 and 1 (ex 0). Resulting state is a state in which slow motion playback is in progress: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport::Play action with the following parameters: InstanceID = If the client implements fast forward / rewind using the RVU multi-frame scan mechanism, the client stops feeding frames to the decoder and halts its internal seek / play loop. The client records the internal start time position of the last frame displayed by the decoder. This value can be obtained using the frameMap.rvualliance.org parameter returned with multi-frame scan responses. 4 The client updates its internal start time position to the value of the absolute time position of the previously displayed frame. The client issues an HTTP GET with the following parameters: transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= Table 5-16: Playing Fast to Playing Slow Sequence V1.0 Rev 1.5.1 174 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = Configure Configure decoder speed Configure no pacing Configure no clock synch HTTP:GET transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= HTTP:GET response t a e p e HTTP/1.1 200 OK R Data transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= Figure 5-15: Playing Fast to Playing Slow Sequence 5.2.1.13 PLAYING_FAST to PAUSED_PLAYBACK (Pause) State: PLAYING (PLAYING_FAST substate) Action: Pause Synopsis This transition describes a state change from the PLAYING_FAST substate (PLAYING state) to the PAUSED_PLAYBACK state for the purpose of pausing from fast forward or fast rewind. Starting condition is a state in which fast forward or fast rewind scan are in progress: PLAYING. Triggering input is an invocation of PAUSE. Resulting state is a state in which playback is paused: PAUSED_PLAYBACK. V1.0 Rev 1.5.1 175 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer No. Description 1 The server control point invokes the client’s AVTransport Pause action with the following arguments: InstanceID = Table 5-17: Playing Fast to Paused Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Pause InstanceId = Pause decoders Flush TCP AVT::LastChange TransportState = PAUSED_PLAYBACK Figure 5-16: Playing Fast to Paused Sequence 5.2.1.14 PLAYING_FAST to PLAYING_FAST (Seek [Absolute Time]) State: PLAYING (PLAYING_FAST substate) Action: Seek [Absolute Time] V1.0 Rev 1.5.1 176 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Synopsis This transition describes a state change from the PLAYING_FAST substate (PLAYING state) to the PLAYING_FAST substate (PLAYING state) for the purpose of playing changing fast forward or fast reverse playback speeds. Starting condition is a state in which fast forward or fast rewind scan are in progress: PLAYING. Triggering input is an invocation of Seek with PlaySpeed less than -1 or greater than 1. Resulting state is a state in which fast forward or fast rewind scan are in progress: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport Seek action with the following arguments: InstanceID = Table 5-18: Playing Fast to Playing Fast (Seek) Sequence V1.0 Rev 1.5.1 177 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT:Seek InstanceId = HTTP:GET frameCount.rvualliance.org: TimeSeekRange.dlna.org: npt= t a e p e R HTTP:GET response HTTP/1.1 200 OK Data transferMode.dlna.org: Streaming frameCount.rvualliance.org: Figure 5-17: Playing Fast to Playing Fast (Seek) Sequence 5.2.1.15 PLAYING_NORMAL to PLAYING_SLOW (Play [Slow]) State: PLAYING (PLAYING_NORMAL substate) Action: Play [Slow] Synopsis This transition describes a state change from the PLAYING_NORMAL substate (PLAYING state) to the PLAYING_SLOW substate (PLAYING state) for the purpose of playing in slow motion. Starting condition is a state in which normal playback is in progress: PLAYING Triggering input is an invocation of Play with PlaySpeed between -1 and 1 (ex 0). Resulting state is a state in which slow motion playback is in progress: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport::Play action with the following arguments: InstanceID = V1.0 Rev 1.5.1 178 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer No. Description 2 Client issues an AVTransport::LastChange event with a value with the following parameters: TransportState = PLAYING TransportPlaySpeed: Table 5-19: Normal-Speed Playing to Play Slow Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT:LastChange TransportState = PLAYING TransportPlaySpeed = Configure Configure decoder speed Configure no pacing Configure no clock synch HTTP Stream t a e p e R Data Figure 5-18: Normal-Speed Playing to Playing Slow Sequence 5.2.1.16 PLAYING_NORMAL to PLAYING_FAST (Play [Fast]) State: PLAYING (PLAYING_NORMAL substate) Action: Play [Fast] V1.0 Rev 1.5.1 179 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Synopsis This transition describes a state change from the PLAYING_NORMAL substate (PLAYING state) to the PLAYING_FAST substate (PLAYING state) for the purpose of playing in fast forward or fast reverse. Starting condition is a state in which normal playback is in progress: PLAYING Triggering input is an invocation of Play with PlaySpeed less than -1 or greater than 1. Resulting state is a state in which fast forward or fast rewind scan are in progress: PLAYING. No. Description 1 The server embedded control point invokes the client’s AVTransport::Play action with the following arguments: InstanceID = 2. The server issues an HTTP GET response for the requested content with the following headers: transferMode.dlna.org: Streaming frameCount.rvualliance.org: The stream content is a sequence of frames as defined by the multi-frame scan operation definition. 3. For each frame, the client plays it out with 1/N second spacing between each frame. 4. When the client is Playing Fast reverse, and reaches the zero time position, then upon draining the content buffer, the client shall: a. Set the absoluteTimePosition to 00:00:00. b. Transition the TransportState to STOPPED. c. Event a single LastChange event for the TransportState variable. Note: “a” and” b” should be done concurrently and must be done prior to “c”. 5. For END_OF_MEDIA sequence, see Table 5-9. Table 5-20: Normal-Speed Playing to Playing Fast Sequence V1.0 Rev 1.5.1 180 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = HTTP:GET frameCount.rvualliance.org: TimeSeekRange.dlna.org: npt= t a e p e R HTTP:GET response Data HTTP/1.1 200 OK transferMode.dlna.org: Streaming frameCount.rvualliance.org: Figure 5-19: Normal-Speed Playing to Playing Fast Sequence 5.2.1.17 PLAYING_NORMAL to PAUSED_PLAYBACK (Pause) State: PLAYING (PLAYING_NORMAL substate) Action: Pause Synopsis This transition describes a state change from the PLAYING_NORMAL substate (PLAYING state) to the PAUSED_PLAYBACK state for the purpose of pausing. Starting condition is a state in which normal playback is in progress: PLAYING Triggering input is an invocation of Pause. Resulting state is a state in which playback is paused: PAUSED_PLAYBACK V1.0 Rev 1.5.1 181 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer No. Description 1 The server control point invokes the client’s AVTransport::Pause action with the following arguments: InstanceID = Table 5-21: Normal-Speed Playing to Paused Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Pause InstanceId = Pause decoders Stall TCP AVT::LastChange TransportState = PAUSED_PLAYBACK Figure 5-20: Normal-Speed Playing to Paused Sequence 5.2.1.18 PLAYING_NORMAL to PLAYING_NORMAL (Seek [Absolute Time]) State: PLAYING (PLAYING_NORMAL substate) Action: Seek V1.0 Rev 1.5.1 182 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Synopsis This transition describes a state change from the PLAYING_NORMAL substate (PLAYING state) to the PLAYING_NORMAL substate (PLAYING state) for the purpose of jumping to a new position in the media. Starting condition is a state in which normal playback is in progress: PLAYING Triggering input is an invocation of Seek with an absolute time position specified. Resulting state is a state in which normal playback is in progress: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport::Seek action with the following parameters: InstanceID = Table 5-22: Normal-Speed playing to Normal-Speed Playing Sequence V1.0 Rev 1.5.1 183 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT:Seek InstanceId = Pause/Flush decoders HTTP:GET transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= HTTP:GET response Configure HTTP/1.1 200 OK transferMode.dlna.org: Streaming Configure decoders TimeSeekRange.dlna.org: npt= HTTP:GET response chunk t a e p e Data R Figure 5-21: Normal-Speed Playing to Normal-Speed Playing Sequence 5.2.1.19 PLAYING_* to STOPPED (Stop) State: PLAYING (PLAYING_* substate) Action: Stop Synopsis This transition describes a state change from any of the playing modes to the STOPPED state. Starting condition is a state in which playback at any speed is in progress. Triggering input is an invocation of Stop. V1.0 Rev 1.5.1 184 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Resulting state is a state in which playback is stopped and no media is displayed: STOPPED. No. Description 1 The server control point invokes the client’s AVTransport::Stop action with the following parameters: InstanceID = Table 5-23: Playing to Stopped Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Stop InstanceId = Close HTTP Flush decoders AVT::LastChange TransportState = STOPPED Figure 5-22: Playing to Stopped Sequence 5.2.1.20 PAUSED_PLAYBACK to PAUSED_PLAYBACK (Seek [Absolute Time]) State: PAUSED_PLAYBACK Action: Seek (Unit = ABS_TIME) Synopsis This transition describes a state change from the PAUSED_PLAYBACK state to the PAUSED_PLAYBACK state for the purpose of jumping to a new position while paused. V1.0 Rev 1.5.1 185 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Starting condition is a state in which media playback is paused: PAUSED_PLAYBACK. Triggering input is an invocation of Seek with an absolute time position. Resulting state is a state in which playback is paused: PAUSED_PLAYBACK. No. Description 1 The server control point invokes the client’s AVTransport::Seek action with the following parameters: InstanceID = 4 The server issues an HTTP response with the following response headers: HTTP Status Code 200 OK TimeSeekRange.dlna.org: npt= Table 5-24: Paused to Paused (Absolute Time Seek) Sequence V1.0 Rev 1.5.1 186 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Seek InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = 1 Flush TCP Flush decoders HTTP:GET transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= HTTP:GET response HTTP/1.1 200 OK Configure transferMode.dlna.org: Streaming Configure decoders TimeSeekRange.dlna.org: npt= HTTP:GET response chunk Play ONE frame Stall TCP AVT::LastChange TransportState = PAUSED_PLAYBACK Figure 5-23: Paused to Paused (Absolute Time Seek) Sequence V1.0 Rev 1.5.1 187 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer 5.2.1.21 PAUSED_PLAYBACK to PAUSED_PLAYBACK (Seek [Frame Forward]) State: PAUSED_PLAYBACK Action: Seek Synopsis This transition describes a state change from the PAUSED_PLAYBACK state to PAUSED_PLAYBACK state for the purpose of frame forward stepping. Starting condition is a state in which playback is paused: PAUSED_PLAYBACK. Triggering input is an invocation of Seek with a target of frame forward. Resulting state is a state in which playback is paused and the frame displayed is advanced by one: PAUSED_PLAYBACK No. Description 1 The control point invokes the client’s AVTransport::Seek action with the following arguments: InstanceID = a. The client sets its internal start time to the last absolute time position from the frame scan operation. The client issues an HTTP GET with the following parameters: transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= b. The server responds to the HTTP GET request with the following parameters: HTTP Response Code 200 OK transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= Table 5-25: Paused to Paused (Relative Seek) Sequence V1.0 Rev 1.5.1 188 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Seek InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = 1 HTTP:GET response chunk Play ONE frame Stall TCP AVT:LastChanged TransportState = PAUSED_PLAYBACK Figure 5-24: Paused (not from Fast Forward or Reverse) to Paused (Relative Seek) Sequence V1.0 Rev 1.5.1 189 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Seek InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = 1 HTTP:GET transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= HTTP:GET response chunk Play ONE frame HTTP/1.1 200 OK transferMode.dlna.org: Streaming TimeSeekRange.dlna.org: npt= AVT::LastChange TransportState = PAUSED_PLAYBACK Figure 5-25: Paused (from Fast Forward or Reverse) to Paused (Relative Seek) Sequence 5.2.1.22 PAUSED_PLAYBACK to PLAYING_NORMAL (Play [Normal]) State: PAUSED_PLAYBACK Action: Play Synopsis This transition describes a state change from the PAUSED_PLAYBACK state to the PLAYING_NORMAL substate (PLAYING state) for the purpose of resuming playback from pause. Starting condition is a state in which playback is paused: PAUSED_PLAYBACK. V1.0 Rev 1.5.1 190 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Triggering input is an invocation of Play with PlaySpeed equal to 1. Resulting state is a state in which normal playback has resumed: PLAYING. No. Description 1 The server control point invokes the client’s AVTransport::Play action with the following arguments: InstanceID = Table 5-26: Paused to Normal-Speed Playing Sequence V1.0 Rev 1.5.1 191 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = 1 Configure Configure decoder speed Configure pacing Configure clock synch HTTP:GET response chunk t a e p e R Data Figure 5-26: Paused to Normal-Speed Playing Sequence 5.2.1.23 PAUSED_PLAYBACK to PLAYING_SLOW (Play [Slow]) State: PAUSED_PLAYBACK Action: Play [Slow] Synopsis This transition describes a state change from the PAUSED_PLAYBACK state to the PLAYING_SLOW substate (PLAYING state) for the purpose of playing in slow motion. Starting condition is a state in which playback is paused: PAUSED_PLAYBACK Triggering input is an invocation of Play with PlaySpeed between -1 and 1 (ex 0). Resulting state is a state in which slow motion playback is in progress: PLAYING. V1.0 Rev 1.5.1 192 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer No. Description 1 The server control point invokes the client’s AVTransport::Play action with the following arguments: InstanceID = Table 5-27: Paused to Playing Slow Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT::LastChanged TransportState = PLAYING TransportPlaySpeed = speed (-1 <= speed < 0 || 0 < speed < 1) Configure Configure decoder speed Configure no pacing Configure no clock synch HTTP:GET response chunk t a e p e R Data Figure 5-27: Paused to Playing Slow Sequence V1.0 Rev 1.5.1 193 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer 5.2.1.24 PAUSED_PLAYBACK to PLAYING_FAST (Play [Fast]) State: PAUSED_PLAYBACK Action: Play [Fast] Synopsis This transition describes a state change from the PAUSED_PLAYBACK state to the PLAYING_FAST substate (PLAYING state) for the purpose of playing in fast forward or fast reverse. Starting condition is a state in which playback is paused: PAUSED_PLAYBACK. Triggering input is an invocation of Play with PlaySpeed less than -1 or greater than 1. Resulting state is a state in which fast forward or fast reverse playback is in progress: PLAYING. No. Description 1 The server’s embedded control point invokes the client AVTransport::Play action with the following arguments: InstanceID = 2. The server issues an HTTP GET response for the requested content with the following headers: transferMode.dlna.org: Streaming frameCount.rvualliance.org: The stream content is a sequence of frames as defined by the multi-frame scan operation definition. 3. For each frame, the client plays it out with 1/N second spacing between each frame. The internal-start-time is advanced 1/N seconds. 4. When the client is Playing Fast reverse, and reaches the zero time position, then upon draining the content buffer, the client shall: a. Set the absoluteTimePosition to 00:00:00. b. Transition the TransportState to STOPPED. c. Event a single LastChange event for the TransportState variable. Note: “a” and” b” should be done concurrently and must be done prior to “c”. 5. For END_OF_MEDIA sequence, see Table 5-9. Table 5-28: Paused to Playing Fast Sequence V1.0 Rev 1.5.1 194 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Play InstanceId = AVT::LastChange TransportState = PLAYING TransportPlaySpeed = Configure Configure decoders Configure no pacing Configure no clock synch HTTP:GET frameCount.rvu.org: TimeSeekRange.dlna.org: npt= t a e p e R HTTP:GET response Data HTTP/1.1 200 OK transferMode.dlna.org: Streaming frameCount.rvu.org: Figure 5-28: Paused to Playing Fast Sequence 5.2.1.25 PAUSED_PLAYBACK to STOPPED (Stop) State: PAUSED_PLAYBACK Action: Stop Synopsis This transition describes a state change from the PAUSED_PLAYBACK state to the STOPPED state for the purpose of stopping media playback while paused. V1.0 Rev 1.5.1 195 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Starting condition is a state in which playback is paused: PAUSED_PLAYBACK. Triggering input is an invocation of Stop. Resulting state is a state in which no media is displayed or playing back: STOPPED. No. Description 1 The server control point invokes the client’s AVTransport::Stop action with the following parameters: InstanceID = Table 5-29: Paused to Stopped Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::Stop InstanceId = Close HTTP Flush decoders AVT::LastChange TransportState = STOPPED Figure 5-29: Paused to Stopped Sequence 5.2.1.26 STOPPED to NO_MEDIA_PRESENT (SetAVTransportURI) State: STOPPED Action: SetAVTransportURI V1.0 Rev 1.5.1 196 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Synopsis This transition describes a state change from the STOPPED state to the NO_MEDIA_PRESENT state. Starting condition is a state in which the client is STOPPED. Triggering input is an invocation of SetAVTransportURI in which CurrentURI and CurrentURIMetaData input arguments set to an empty string. Resulting state is a state in which no URI has been selected: NO_MEDIA_PRESENT. No. Description 1 The server control point invokes the client’s AVTransport::SetAVTransportURI action with the following parameters: InstanceID = Table 5-30: Stopped to No Media Present Sequence Sequence Diagram Client Server Play Mod AVT / HTTP Control Point HTTP AVT::SetTransportURI InstanceId = AVT::LastChange AVTransportURI = Figure 5-30: Stopped to No Media Present Sequence 5.3 DTCP [5.3-1] M: RVU-S When encrypting content to send to the client, an RVU server shall use DTCP copy protection. V1.0 Rev 1.5.1 197 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer [5.3-2] M: RVU-S An RVU server shall follow the recommendations of the DLNA Networked Device Interoperability Guidelines, Volume 3: Link Protection, October 2006 [Ref11]. [5.3-3] M: RVU-C An RVU client shall be “format cognizant” and process the DTCP descriptor embedded within the content stream. [5.3-4] M: RVU-S An RVU server shall be capable of.asserting the DTCP DOT field defined in [Ref20] Table 17., [5.3-5] M: RVU-C An RVU client shall support rendering of DTCP DOT content. 5.4 Clock Synchronization and Sender Pacing Transmission and delivery of IP packets in a home network is characterized by variable delay (which in this section is referred to as jitter) that can be much greater than jitter of MPEG transport delivery within initial broadcast delivery/reception to the home. Under these conditions, RVU clients may utilize recovered TTS headers appended to MPEG partial transport streams to measure server and home network induced MPEG packet jitter. If network jitter persists, clients may incur decoder underflows with resultant audio and visual artifacts. Transport Time Stamps (TTS) are defined in accordance with [Ref18], [Ref24] and Appendix C of this document. Clock synchronization can be achieved through a number of implementations. A simple PID controller is recommended. See ISO 13818-1 [Ref18] Annex J for a discussion of various clock recovery schemes proposed for MPEG2 Transport Streams over jitter inducing networks. For example, clients utilizing a jitter smoothing mechanism as described by [Ref18] Annex J Figure J.2 may utilize TTS headers as network-layer timestamps. A fixed delay is added to packets entering the de-jitter buffer and packets are removed from the buffer when a local clock derived from the TTS is greater than or equal to the TTS+delay value stored in a buffered packets. Alternatively some implementations may choose to integrate the de-jitter buffer with the video decoding buffer. ISO 13818-1 [Ref18] Annex J describes how clients with sufficient decoder capability may integrate de-jittering and decoding functions in a single system using the jittered PCR values. Client implementers are free to implement whatever mechanism they see fit to achieve clock synchronization but should tolerate at least 100 ms of server and home network induced clock jitter. RVU servers are not required to lock the TTS clock to partial transport streams embedded PCRs. However, TTS headers meet MPEG2 [ISO13818-1, [Ref18] PCR clock precision requirements. 5.4.1 TTS Clock Synchronization Requirements If the DLNA.ORG_FLAGS Sender Pacing bit (bit 31) is set and the playback speed is set to 1, the following requirements for TTS clock synchronization apply to RVU elements: V1.0 Rev 1.5.1 198 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer [5.4.1-1] M: RVU-S The server shall pace data out to the network according to the TTS clock and the TTS values in the stream. [5.4.1-2] M: RVU-S The server shall maintain TTS accuracy in compliance with MPEG2 [ISO13818-1] [Ref18] clock precision requirements. [5.4.1-3] M: RVU-C The client shall tolerate at least 100 ms of server and home network induced clock jitter. [5.4.1-4] M: RVU-C The client decoder clock shall not be derived from server generated TTS values.. 5.4.2 Sender Pacing If a sender is required to pace data onto the network according to the mandatory clock synchronization conditions, it must meet the following performance constraints: [5.4.2-1] M: RVU-S An RVU server shall guarantee total OS jitter for packet transmission does not exceed 50ms. [5.4.2-2] M: RVU-S An RVU server shall guarantee average OS jitter for packet transmission does not exceed 25ms. [5.4.2-3] M: RVU-S An RVU server shall guarantee one standard deviation of the OS jitter for packet transmission does not exceed 10 ms. OS jitter refers to variation generally attributable to the operating system, e.g. context switching, kernel buffer copying and interrupt scheduling 5.4.3 Pause – Resume With TTS Synchronization Connection Stalling based HTTP Pause-Release introduces non-trivial obstacles to TTS synchronization. Documented below are important considerations to take into account when designing a TTS recovery mechanism. Figure 5-31 demonstrates the theoretical model when the system is in steady state. While in steady state, the Paced Server Data queue rate limits data into the system. V1.0 Rev 1.5.1 199 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Server Paced Server Data TCP TX Buffer Rate Limiting Client Video Decoder Jitter Buffer TCP RX Buffer Figure 5-31: Steady State HTTP Streaming with Sender Pacing Figure 5-32 demonstrates the theoretical model when the system has been paused using the Connection Stalling mechanism. When the TCP TX Buffer is full, this signals to the server that the client intends to pause. Server Paced Server Data TCP TX Buffer Rate Limiting Client Video Decoder Jitter Buffer TCP RX Buffer Figure 5-32: HTTP Connection Stalling Based Pause Data in the TCP RX Buffer and TCP TX buffer will not be paced correctly after a client resumes to the play speed of 1 from the paused state. Data in these buffers were queued after the pacing rate limiting stage (see Figure 5-33, red striped elements). This data cannot be utilized for TTS synchronization calculations. Server Paced Server Data TCP TX Buffer Rate Limiting Client Video Decoder Jitter Buffer TCP RX Buffer Figure 5-33: Invalid Pacing Information Note that this is only a theoretical model and the Video Decoder and Jitter Buffer may be integrated into a single unit in actual implementation. V1.0 Rev 1.5.1 200 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer When resuming from a connection stalling based pause, data in the servers TCP output buffer and data in the clients TCP input buffer do not have accurate timing information. It is important that the client ignore this data for TTS synchronization. However, there is no signaling mechanism present that allows the client to know when this data has been received in entirety. For this reason, it is recommended that the client wait 30 seconds after resuming from a pause before restarting its TTS synchronization mechanism. 30 seconds provides more than enough time to fully drain the TCP buffer while not being so long as to introduce perceivable clock drift. 5.4.4 Mandatory Clock Synchronization Conditions If the DLNA.ORG_FLAGS Sender Pacing bit (bit 31) is set and the playback speed is set to 1, the mandatory clock synchronization conditions are satisfied. If the conditions for mandatory clock synchronization are satisfied, the following requirements apply to the RVU elements: [5.4.4-1] M: RVU-C The client shall receive and decode the TTS (timestamped transport stream) stream continuously without noise and blanking by using the method described in 5.4.4-2 or 5.4.4-3. [5.4.4-2] O: RVU-C The client may recover the clock present in the TTS stream and base its decoding clock on the recovered frequency. [5.4.4-3] O: RVU-C The client may keep pace of audio and video decoding speed with the TTS stream by skipping or repeating the picture frame, and control the audio decoding speed. [5.4.4-4] M: RVU-S The server shall pace data out to the network according to the clock within the TTS stream. If the conditions for mandatory clock synchronization are not satisfied, the following requirements apply to the RVU elements: [5.4.4-5] M: RVU-C The client shall base its decoding clock off of a local free running clock. [5.4.4-6] M: RVU-S The server shall not pace data and shall implement HTTP GET as a normal pull operation. 5.5 Performance Criteria [5.5-1] M: RVU-S, RVU-C An RVU element shall complete processing of any UPnP AVTransport action and transition to the appropriate state within 300ms of reception of the action. [5.5-2] M: RVU-C An RVU client shall complete processing of any UPnP Connection manager action and transition to the appropriate state within 300ms of reception of the action. V1.0 Rev 1.5.1 201 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer [5.5-3] M: RVU-C Upon reception of a video stream, an RVU client / DLNA DMR shall display video within 1 (one) second of the reception of the first packet of video from the network. 5.6 Additional res@protocolInfo other-param Flags These fields are defined for the RVU protocol for inclusion in the res@protocoInfo property, see [Ref21]. 5.6.1 RVUALLIANCE.ORG_APID Syntax rvu-apid-param = [rvu-apid-delim] “RVUALLIANCE.ORG_APID=” rvu-apid-value rvu-apid-delim = “;” rvu-apid-value = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s Description This parameter indicates the audio PID/SCID the client must choose as its default audio playback PID/SCID for content contained in transport stream formats. The range of the rvu-apid- value must be a legal PID value for MPEG2 transport streams and a legal SCID value for ITU-R BO.1516 SYSTEM B transport streams. 5.6.2 RVUALLIANCE.ORG_VPID Syntax rvu-vpid-param = [rvu-vpid-delim] “RVUALLIANCE.ORG_VPID=” rvu-vpid-value rvu-vpid-delim = “;” rvu-vpid-value = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s Description This parameter indicates the video PID/SCID the client must choose as its default video playback PID/SCID for content contained in transport stream formats. The range of the rvu-vpid- value must be a legal PID value for MPEG2 transport streams and a legal SCID value for ITU-R BO.1516 SYSTEM B transport streams, [Ref22]. 5.6.3 RVUALLIANCE.ORG_FLAGS Syntax rvu-flags-param = [rvu-flags-delim] “RVUALLIANCE.ORG_FLAGS=” rvu-flags-value rvu-flags-delim = “;” rvu-flags-value = 8 HEX characters (0-9,A-F,a-f), formatted as specified in [Ref8] Description Each bit in the binary representation of the hex string represents a single flag value in the bit field. The bit field is ordered such that bit 31 is the most significant bit while bit 0 is the least significant bit. Flag descriptions are defined below. V1.0 Rev 1.5.1 202 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Bit 31: Reserved. This bit shall not be used for any purpose and must be set to zero. Bit 30: Multi-frame scan support. This bit indicates that a server supports the multi-frame scan mechanism defined previously. Bit 29-0: Reserved. These bits shall not be used for any purpose and must be set to zero. 5.6.4 RVUALLIANCE.ORG_MAX_REQUEST_FRAME_COUNT Syntax rvu-max_request_frame_count-param = [rvu-max_request_frame_count-delim] “RVUALLIANCE.ORG_MAX_REQUEST_FRAME_COUNT=” rvu-max_frequest_frame_count-value rvu-max_request_frame_count-delim = “;” rvu-max_request_frame_count-value = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s Description This parameter indicates the maximum number of frames that should be requested by the client for a Multi-Frame request. 5.6.5 RVUALLIANCE.ORG_SUB_INFO Syntax rvu-sub_info-param = [rvu-sub_info-delim] “RVUALLIANCE.ORG_SUB_INFO=” rvu- sub_info-section [rvu-sub_info-group-separator rvu-sub_info-section]… rvu-sub_info-delim = “;” rvu-sub_info-section = “rvu-sub_info-lang-value rvu-sub_info-separator rvu- sub_info-format-value rvu-sub_info-separator rvu-sub_info-pid-value” rvu-sub_info-lang-value = “none” | standard ISO-639 (see [Ref43]) 3 character language code defined for subtitles rvu-sub_info-format-value = “DVB” | “SBTVD” rvu-sub_info-pid-value = 1 or more digits (0-9), formatted as specified in [Ref8], excluding leading 0s rvu-sub_info-separator = “-“ rvu-sub_info-group-separator = “/” Description This parameter indicates the subtitling languages, formats, and PIDs for the client to display subtitles. Example RVUALLIANCE.ORG_SUB_INFO=eng-SBTVD-3000/RVUALLIANCE.ORG_SUBINFO=spa-SBTVD-3001 A complete example would show the above text appended to sample fourth res@protocolInfo fields listed in section 5.7. 5.6.6 Profile Names and MIME Types for AVTransport Streams The third field of the ProtocolInfo string contains the content protection MIME type (if the content is protected) as well as the MIME type associated with the media format. V1.0 Rev 1.5.1 203 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer [5.6.6-1] M: RVU-C An RVU client shall support all DLNA compliant media format profiles listed in Table 5-31. 3D frame compatible (3DFC) video is indicated by AVC profile names from Table 5-31 that contain the text string “3DFC” or by the other two AVC profile names that do not contain the “3DFC” text string. If a server does not specifically identify an AVC profile name that contains the text “3DFC” in the ProtocolInfo string, a client identifies the presence of 3DFC video using the rvu3DTVStructure attribute within the ReconfigureDisplayBuffer3DTV command. [5.6.6-2] M: RVU-C An RVU client shall support the closed caption transport within the AVC profiles of Table 5-31 in accordance with the requirements in Appendix C. [5.6.6-3] M: RVU-C An RVU client shall support the media format profiles listed in Table 5-32 in accordance with the bitstream requirements Appendix C. [5.6.6-4] M: RVU-C Clients capable of decoding HEVC shall support the media format profiles listed in Table 5-33 in accordance with the bitstream requirements in Appendix C. [5.6.6-5] S: RVU-C Clients capable of decoding HEVC should implement RVU 2.0 graphics in compliance with [Ref45]. [5.6.6-6] M: RVU-S, RVU-C RVU elements shall comply with the following format of the third field of ProtocolInfo when the content is DTCP protected: application/x-dtcp1; DTCP1HOST= For example, the third field for DTCP-protected MPEG_TS_HD_NA_MPEG1_L2_ISO is: application/x-dtcp1; DTCP1HOST= [5.6.6-7] M: RVU-S, RVU-C RVU elements shall comply with the following format of the third field of ProtocolInfo when the content is not protected: For example, the third field for non-protected MPEG_TS_HD_NA_MPEG1_L2_ISO is: video/mpeg Description Profile Name Media MIME Type MPEG TS, h.264 video, AC3 AVC_TS_HP_HD_AC3_ISO video/mpeg audio, No TTS MPEG TS, h.264 video, AC3 AVC_TS_HP_HD_AC3_T video/vnd.dlna.mpeg-tts audio, TTS V1.0 Rev 1.5.1 204 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Description Profile Name Media MIME Type MPEG TS, frame compatible AVC_TS_HP_HD_3DFC_AC video/mpeg 3D, h.264 video, AC3 audio, 3_ISO No TTS MPEG TS, frame compatible AVC_TS_HP_HD_3DFC_AC video/vnd.dlna.mpeg-tts 3D, h.264 video, AC3 audio, 3_T TTS MPEG TS, h.262 video, MPEG_TS_HD_NA_MPEG1 video/mpeg MPEG1 - L2 audio, No TTS _L2_ISO MPEG TS, h.262 video, MPEG_TS_HD_NA_MPEG1 video/vnd.dlna.mpeg-tts MPEG1 - L2 audio, TTS _L2_T MPEG TS, h.262 video, AC3 MPEG_TS_HD_NA_ISO video/mpeg audio, No TTS MPEG TS, h.262 video, AC3 MPEG_TS_HD_NA_T video/vnd.dlna.mpeg-tts audio, TTS LPCM Audio 44.1 kHz LPCM audio/L16;rate=44100;channels=2 LPCM Audio 48 kHz LPCM audio/L16;rate=48000;channels=2 MP3 Audio MP3 audio/mpeg MP4 container, h.264 video, AVC_MP4_HP_HD_AAC video/mp4 AAC audio Table 5-31: DLNA Media Format Profile MIME Types Description Profile Name Media MIME Type ITU-R BO.1516 Sys B TS, SD, MPEG_DIRECTV_SD_AC3 video/vnd.directv.mpeg AC3 audio, No TTS ITU-R BO.1516 Sys B TS, SD, MPEG_DIRECTV_SD_AC3_ video/vnd.directv.mpeg-tts AC3 audio, TTS T ITU-R BO.1516 Sys B TS, SD, MPEG_DIRECTV_SD_MPE video/vnd.directv.mpeg MPEG1 - L2 audio, No TTS G1_L2 ITU-R BO.1516 Sys B TS, SD, MPEG_DIRECTV_SD_MPE video/vnd.directv.mpeg–tts MPEG1 - L2 audio, TTS G1_L2_T Table 5-32: MPEG_DIRECTV_SD Format Profile MIME Types Description Profile Name Media MIME Type MPEG TS, h.265 main 10 HEVC_TS_M10P_MT_EA video/mpeg profile video, EAC3 or AC3 C3_ISO audio, No TTS MPEG TS, h.265 main10 HEVC_TS_M10P_MT_EA video/vnd.dlna.mpeg-tts profile video, EAC3 or AC3 C3_T audio, TTS MPEG TS, h.265 main (8 bit) HEVC_TS_MP_MT_EAC3 video/mpeg video, EAC3 or AC3 audio, No _ISO TTS V1.0 Rev 1.5.1 205 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Description Profile Name Media MIME Type MPEG TS, h.265 main (8bit) HEVC_TS_MP_MT_EAC3 video/vnd.dlna.mpeg-tts video, EAC3 or AC3 audio, _T TTS Table 5-33: HEVC Format Profile MIME Types Description Profile Name Media MIME Type MPEG TS, h.264 video, AAC AVC_TS_HP_HD_HEAAC_L4_ISO video/mpeg audio, No TTS MPEG TS, h.264 video, AAC AVC_TS_HP_HD_HEAAC_L4_T video/vnd.dlna.mpeg-tts audio, TTS MPEG TS, h.264 video, AVC_TS_HP_HD_MPEG1_L2_ISO video/mpeg MPEG1-L2 audio, No TTS MPEG TS, h.264 video, AVC_TS_HP_HD_MPEG1_L2_T video/vnd.dlna.mpeg-tts MPEG1-L2 audio, TTS Table 5-34: Latin America Specific Media Format Profile MIME Types 5.7 Example Fourth res@protocolInfo Fields The fourth field of ProtocolInfo is sent as CurrentURIMetaData as part of AVTransport:SetAVTransportURI. The following are examples of the 4th ProtocolInfo field for various AVTransport content combinations, including the flags defined in section 5.6. The DLNA.ORG_PN parameter included in the 4th protocol field examples is only present if the content conforms to a DLNA media format profile. This parameter is not present if the content is not conformant to a DLNA media format profile. Note: where noted in the below examples, integer means non-negative integer. Playback Video Program (MPEG TS, h.264 video, AC3 audio, TTS) DLNA Media Format Profile name: AVC_TS_HP_HD_AC3_T DLNA.ORG_PN=AVC_TS_HP_HD_AC3_T;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=8131000000000000 0000000000000000;RVUALLIANCE.ORG_APID= Playback Video Program (MPEG TS, h.262 video, MPEG1 - L2 audio, TTS) DLNA Media Format Profile name: MPEG_TS_HD_NA_MPEG1_L2_T DLNA.ORG_PN=MPEG_TS_HD_NA_MPEG1_L2_T;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=8131000000 0000000000000000000000;RVUALLIANCE.ORG_APID= V1.0 Rev 1.5.1 206 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Playback Video Program (MPEG TS, h.262 video, AC3 audio, TTS) DLNA Media Format Profile name: MPEG_TS_HD_NA_T DLNA.ORG_PN=MPEG_TS_HD_NA_T;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=8131000000000000000 0000000000000;RVUALLIANCE.ORG_APID= Playback Video Program (ITU-R BO.1516 Sys B TS, SD, MPEG1 - L2 audio, TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_MPEG1_L2_T DLNA.ORG_PN=MPEG_DIRECTV_SD_MPEG1_L2_T;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=81310000 000000000000000000000000;RVUALLIANCE.ORG_APID= Playback Video Program (ITU-R BO.1516 Sys B TS, SD, AC3 audio, TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_AC3_T DLNA.ORG_PN=MPEG_DIRECTV_SD_AC3_T;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=8131000000000 0000000000000000000;RVUALLIANCE.ORG_APID= Internet Video Program (MPEG TS, h.264 video, AC3 audio, No TTS) DLNA Media Format Profile name: AVC_TS_HP_HD_AC3_ISO DLNA.ORG_PN=AVC_TS_HP_HD_AC3_ISO;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=01310000000000 000000000000000000;RVUALLIANCE.ORG_APID= Internet Video Program (MPEG TS, h.262 video, MPEG1 - L2 audio, No TTS) DLNA Media Format Profile name: MPEG_TS_HD_NA_MPEG1_L2_ISO DLNA.ORG_PN=MPEG_TS_HD_NA_MPEG1_L2_ISO;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=01310000 000000000000000000000000;RVUALLIANCE.ORG_APID= Internet Video Program (MPEG TS, h.262 video, AC3 audio, No TTS) DLNA Media Format Profile name: MPEG_TS_HD_NA_ISO DLNA.ORG_PN=MPEG_TS_HD_NA_ISO;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=01310000000000000 000000000000000;RVUALLIANCE.ORG_APID= Internet Video Program (ITU-R BO.1516 Sys B TS, SD, MPEG1 - L2 audio, No TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_MPEG1_L2 DLNA.ORG_PN=MPEG_DIRECTV_SD_MPEG1_L2;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=0131000000 0000000000000000000000;RVUALLIANCE.ORG_APID= V1.0 Rev 1.5.1 207 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Internet Video Program (ITU-R BO.1516 Sys B TS, SD, AC3 audio, No TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_AC3 DLNA.ORG_PN=MPEG_DIRECTV_SD_AC3;DLNA.ORG_OP=10;DLNA.ORG_FLAGS=013100000000000 00000000000000000;RVUALLIANCE.ORG_APID= Recording Video Program (MPEG TS, h.264 video, AC3 audio, TTS) DLNA Media Format Profile name: AVC_TS_HP_HD_AC3_T DLNA.ORG_PN=AVC_TS_HP_HD_AC3_T;DLNA.ORG_FLAGS=C531000000000000000000000000000 0;RVUALLIANCE.ORG_APID= Recording Video Program (MPEG TS, h.262 video, MPEG1 - L2 audio, TTS) DLNA Media Format Profile name: MPEG_TS_HD_NA_MPEG1_L2_T DLNA.ORG_PN=MPEG_TS_HD_NA_MPEG1_L2_T;DLNA.ORG_FLAGS=C531000000000000000000000 0000000;RVUALLIANCE.ORG_APID= Recording Video Program (MPEG TS, h.262 video, AC3 audio, TTS DLNA Media Format Profile name: MPEG_TS_HD_NA_T DLNA.ORG_PN=MPEG_TS_HD_NA_T;DLNA.ORG_FLAGS=C5310000000000000000000000000000;R VUALLIANCE.ORG_APID= Recording Video Program (ITU-R BO.1516 Sys B TS, SD, MPEG1 - L2 audio, TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_MPEG1_L2_T DLNA.ORG_PN=MPEG_DIRECTV_SD_MPEG1_L2_T;DLNA.ORG_FLAGS=C5310000000000000000000 000000000;RVUALLIANCE.ORG_APID= Recording Video Program (ITU-R BO.1516 Sys B TS, SD, AC3 audio, TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_AC3_T DLNA.ORG_PN=MPEG_DIRECTV_SD_AC3_T;DLNA.ORG_FLAGS=C531000000000000000000000000 0000;RVUALLIANCE.ORG_APID= Pause Live Video Program (MPEG TS, h.264 video, AC3 audio, TTS) DLNA Media Format Profile name: AVC_TS_HP_HD_AC3_T DLNA.ORG_PN=AVC_TS_HP_HD_AC3_T;DLNA.ORG_FLAGS=CD31000000000000000000000000000 0;RVUALLIANCE.ORG_APID= Pause Live Video Program (MPEG TS, h.262 video, MPEG1 - L2 audio, TTS) DLNA Media Format Profile name: MPEG_TS_HD_NA_MPEG1_L2_T DLNA.ORG_PN=MPEG_TS_HD_NA_MPEG1_L2_T;DLNA.ORG_FLAGS=CD31000000000000000000000 0000000;RVUALLIANCE.ORG_APID= V1.0 Rev 1.5.1 208 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Media Transfer Pause Live Video Program (MPEG TS, h.262 video, AC3 audio, TTS DLNA Media Format Profile name: MPEG_TS_HD_NA_T DLNA.ORG_PN=MPEG_TS_HD_NA_T;DLNA.ORG_FLAGS=CD310000000000000000000000000000;R VUALLIANCE.ORG_APID= Pause Live Video Program (ITU-R BO.1516 Sys B TS, SD, MPEG1 - L2 audio, TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_MPEG1_L2_T DLNA.ORG_PN=MPEG_DIRECTV_SD_MPEG1_L2_T;DLNA.ORG_FLAGS=CD310000000000000000000 000000000;RVUALLIANCE.ORG_APID= Pause Live Video Program (ITU-R BO.1516 Sys B TS, SD, AC3 audio, TTS) DLNA Media Format Profile name: MPEG_DIRECTV_SD_AC3_T DLNA.ORG_PN=MPEG_DIRECTV_SD_AC3_T;DLNA.ORG_FLAGS=CD31000000000000000000000000 0000;RVUALLIANCE.ORG_APID= V1.0 Rev 1.5.1 209 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Local Menus 6 Client Local Menus Some of the user-selectable parameters for the RVU client are stored on the client itself. Setting these parameters requires the client to generate local menus and OSDs to provide an interface for the user. Since the server is in control of the client display, the server requests that the client assume control of the client UI to display the client’s local menus and OSDs using the RequestLocalUI command. The client returns control of the UI to the server by sending the LocalUIEvent command to the server. The server requests the client to assume control of the UI when the user selects setting or changing the following parameters. An RVU client shall support transfer of control from the server for all UI elements defined in Table 4-89. If the client does not support setting local parameters for some of these menus, or supports setting these parameters by other means, the client is still required to process the request. The client may return control to server without generating a local menu, or may display an OSD indicating these parameters are not supported or are processed by other means. Mandatory Local UI implementation requirements in this section 6 are conditionally mandatory subject to implementation requirements in section 4.8.2.4. A general outline of the process by which control is passed between the server and client is shown in Figure 6-1. Client Server User input triggering KeyEvent (keyVal) Send RequestLocalUI local UI RequestLocalUI (enable, Begin local UI control org.rvualliance. LocalUIEvent Relinquish control of (starting, element) client UI LocalUIEvent Resume control of Exit local UI (starting=0, element, keyVal) client UI Figure 6-1: Local UI Control Process 6.1 Closed Captioning Closed Captioning (CC) decoding is performed by the client. The client must decode CC information from the AV stream and display CC based on parameters set and maintained by the client. For example, CC On/Off, Font style, Color and Opacity are set with client menus. [6.1-1] M: RVU-S An RVU server shall pass control to the client to set CC parameters by sending the RequestLocalUI command with an element attribute of org.rvualliance.CC. V1.0 Rev 1.5.1 210 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Local Menus [6.1-2] M: RVU-C An RVU client shall pass control back to the server after setting CC parameters by sending the LocalUIEvent command with a “starting” attribute of “terminating”. 6.2 Screen Format Menus Screen format parameters are a controlled by the client. This includes parameters such as display resolution, aspect ratio, letterbox and pillar-box, etc. [6.2-1] M: RVU-S An RVU server shall pass control to the client to set screen format parameters by sending the RequestLocalUI command with an element attribute of org.rvualiance.HDTV. [6.2-2] M: RVU-C An RVU client shall pass control back to the server after setting screen format parameters by sending the LocalUIEvent command with a “starting” attribute of “terminating”. 6.3 Restart Menu [6.3-1] M: RVU-S An RVU server shall pass control to the client to Restart by sending the RequestLocalUI command with an element attribute of org.rvualiance.Restart. [6.3-2] M: RVU-C If the client restart action allows the current session with the server to continue after the restart action, an RVU client shall pass control back to the server after Restart by sending the LocalUIEvent command with a “starting” attribute of “terminating”. [6.3-3] M: RVU-C If the client restart action does not allow the current session to the server to continue, the client shall send the RUI “shutdown” command (0) to the server before executing its Restart action. 6.4 Reset Defaults When a user requests a reset of client parameters to their factory default the following occurs: [6.4-1] M: RVU-S The server shall reset all client parameters that are set and stored on the server to factory defaults. Examples of these parameters are Parental Controls and Favorites. [6.4-2] M: RVU-S The server shall pass control of the UI to the client, using the RequestLocalUI RUI command with the element attribute set to “org.rvualliance.Reset. V1.0 Rev 1.5.1 211 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Local Menus [6.4-3] M: RVU-C The client shall invoke its reset action to set its parameters to factory default values [6.4-4] M: RVU-C The client shall return control to the server by sending the LocalUIEvent command to the server with a “starting” attribute set to “terminating”. 6.5 Dolby Digital Menu Dolby Digital decoding is performed by the client. If the AV stream contains Dolby Digital audio, the client determines whether to decode as Dolby Digital audio or standard audio. Selection of Dolby Digital decode is a function of the client. [6.5-1] M: RVU-S When a user selects Dolby Digital On/Off, the server shall pass control of the UI to the client by sending the RequestLocalUI RUI command with an “element” attribute of “org.rvualliance.Dolby”. [6.5-2] M: RVU-C After setting the Dolby Digital parameter, the client shall return control to the server by sending the LocalUIEvent command to the server with a “starting” attribute set to “terminating”. 6.6 Network Menus [6.6-1] M: RVU-S When the user selects setting Network parameters, the server shall transfer control of the UI to the client using the RequestLocalUI RUI command with an “element” attribute of “org.rvualliance.Network”. The client may use its local “Network” menu to select network parameters such as IP address acquisition mode and Manual IP address selection. [6.6-2] M: RVU-C The client shall return control to the server by sending the LocalUIEvent command to the server with a “starting” attribute set to “terminating”. 6.7 Unhandled Key A client may want to gain control of its UI without requiring the user to select one the server menu entries defined above. This is accomplished by sending a CDIKeyEvent or HDMI KeyEvent with a KeyVal that is not mapped to any remote function defined in Table 4-19. [6.7-1] M: RVU-S When the server receives this UnhandledKey, it shall pass control to the client by sending RequestLocalUI to the client with a UIElement of org.rvualliance.UnhandledKey. [6.7-2] M: RVU-C The client shall return control to the server by sending the LocalUIEvent command to the server with a “starting” attribute set to “terminating”. V1.0 Rev 1.5.1 212 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Local Menus 6.8 Unsupported UI Element A server is not required to call ListLocalUIElements to confirm client support of a local UI element prior to server use of that element within the RequestLocalUI command. Among the options for providing user indication that a local UI element is not supported by a client, a server may provide a remote UI indication of non-support upon receiving a ERR_INVALID_PARAM error code in response to a RequestLocalUI command. Additionaly or alternatively, a client may provide a local UI indication of non-support upon sending a ERR_INVALID_PARAM error code in response to a RequestLocalUI command. The following sequence suggests points for insertion of remote UI and/or local UI notifications. No. Description 1 Server sends RequestLocalUI command (4.8.2.4.2) with a local UI element not supported by the client 2 Client returns ERR_INVALID_PARAM error code to server (Table 4-95) Optional further sequence of commands illustrated below 3 Server may generate a remote UI indication that the local UI element is not supported then waits for user input acknowledgement and/or client may send ClientRequestLocalUI command (4.8.2.4.4) 4 If the client sends ClientRequestLocalUI, the server responds with RequestLocalUI command (4.8.2.4.2) with the element attribute of org.rvualiance.ClientRequest (Table 4-89) 5 Client sends LocalUIEvent with the following attributes: - Starting = 1 (Non-zero) - Element = org.rvualliance.ClientRequest (4.8.2.4.3) 6 Client displays its local UI indicating that the local UI element is not supported, for example, “operation not supported” then waits for user input acknowledgement 7 Client sends LocalUIEvent with the following attributes: - Starting = 0 - Element = org.rvualliance.ClientRequest (4.8.2.4.3) 8 Server produces RUI graphics and AV content in effect when ClientRequestLocalUI was called (4.8.2.4.3-5) Table 6-1: Unsupported UI Element Message Sequence 6.9 Alternative server selection Once in RVU session, and when triggered by client user input that does not trigger server RUI (e.g. “source” or “input” button on a TV remote device), clients may use the following sequence to display a menu allowing alternative server selection, where portions of this sequence are similar to that of section 6.8: If the client sends ClientRequestLocalUI, the server responds with RequestLocalUI command (4.8.2.4.2) with the element attribute of org.rvualiance.ClientRequest (Table 4-89) Client sends LocalUIEvent with the following attributes: o Starting = 1 (Non-zero) o Element = org.rvualliance.ClientRequest (4.8.2.4.3) Client displays its local UI waits for completion of user interaction Client sends LocalUIEvent with the following attributes: o Starting = 0 V1.0 Rev 1.5.1 213 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Local Menus o Element = org.rvualliance.ClientRequest (4.8.2.4.3) Client sends shutdown command to connected server Connected server is released and client begins session with new server Alternatively clients may implement to the following scenario for displaying an alternate server selection menu: Server provides a RUI soft button for access to alternate server selection based on information stored in the server to indicate the particular client in session needs RUI prompting for alternative server selection When a user selects this RUI button, the server calls RequestLocalUI with element org.rvualliance.ServerSelection After client displays local UI and user makes a selection, the connected server is released via a Shutdown command and the client begins session with the new server If an error case where a server calls RequestLocalUI with element org.rvualliance.ServerSelection, the TV client can respond in the informative scenario described in section 6.8 V1.0 Rev 1.5.1 214 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics 7 QoS and Diagnostics The Quality of Service (QoS) and Diagnostics section of the RVU protocol describes the QoS model and diagnostic tools for use in network environments where RVU servers and clients reside. Home network connections are typically designed for connectivity, potentially sacrificing link quality to provide interoperability. A lack of centralized control over these devices leads to difficulty in creating a high-quality, robust environment. High-quality services such as digital video are particularly susceptible to noticeable quality degradation. Possible QoS issues include: Buffer overflows and underflows for video, audio, and any data (including RUI) streaming from the server to the client. Interference from other devices within the system (e.g., other clients). Interference from other devices outside the system (e.g., other network traffic, such as between a PC and an Internet Gateway Device). Although QoS is managed on the server side, both the server and the client are responsible for tagging packets with the appropriate priority level as defined by DLNAQOS. 7.1 Standards The RVU protocol employs DLNAQOS as defined in the DLNA standard [Ref10]. Diagnostics can be based on standard protocol tools as discussed in the Diagnostics section below. In particular, the following documents outline the basis for RVU QoS: DLNA Networked Device Interoperability Guidelines, Volume 1: Architectures and Protocols, Oct 2006 [Ref10] DLNA Networked Device Interoperability Guidelines, Volume 3: Link Protection, Oct 2006 [Ref11] UPnP QoS Architecture:2, 16 Oct 2006 [Ref2] Specific network architecture is beyond the scope of DLNA specifications. However, the appendices to the specifications contain recommendations that may clarify the potential network topologies and their related diagnostic needs. 7.2 Network Topology The design of the RVU protocol allows for a number of different network options. Servers and clients using the RVU protocol can be deployed in either a closed or an open network. An RVU deployment in a closed network is shown in Figure 7-1 below. V1.0 Rev 1.5.1 215 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics Figure 7-1: Closed Network The network environment of a typical usage of RVU in an open network is shown in Figure 7-2 below. The number of clients and home network elements may vary. Figure 7-2: Open Network The external content source in both figures can be any kind of feed that the server is designed to process (e.g., ATSC feed, satellite feed, or cable). The home network elements in Figure 7-2 can be any kind of network-enabled PC, router, mobile device, internet gateway device, etc., and may also use other types of network connections (e.g., 802.11g). The elements may or may not be DLNA-compliant. Because the RVU protocol does not preclude the use of more than one RVU server, it is also possible that two servers may be deployed in the same network, as in Figure 7-3. QoS and diagnostic tools should be designed such that they can support such a deployment. V1.0 Rev 1.5.1 216 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics Figure 7-3: Multiple Servers 7.3 Quality of Service For closed-network configurations where the installation is performed by the service provider, the provider may make installation choices and deploy proprietary hardware, software, and techniques to ensure the best quality network connection. For open networks where a high degree of quality is not expected (e.g., a typical home computer network), a best-effort approach to network quality is acceptable. However, in open network installations where a user would expect a high degree of quality, such as for streaming video, a balance must be struck between controlling network traffic quality and allowing devices to operate. One option for managing QoS in an open network is to isolate the RVU traffic on its own network segment, with all traffic destined for the RVU clients passing through the RVU server (which may be desired if non-RVU network components such as the router do not provide the notion of UPnP-based prioritized QoS). An example of this is shown in Figure 7-4. V1.0 Rev 1.5.1 217 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics Figure 7-4: Example of RVU Isolation 7.3.1 Recommendations [7.3.1-1] S: RVU-S, RVU-C To ensure high-quality data transfer, an RVU element should support a high-bandwidth connection such as MoCA (Multimedia over Coax Alliance). The actual required bandwidth will depend on content format, network load, and required quality level. [7.3.1-2] S: RVU-S An RVU server should include a network controller. [7.3.1-3] S: RVU-S An RVU server should provide a user interface to allow validation of clients discovered on the network. The specific validation process is beyond the scope of this document. In general, the server should refuse/disconnect a RUI connection/session if a client fails validation. 7.3.2 Requirements [7.3.2-1] M: RVU-S, RVU-C An RVU element using the RVU protocol shall tag Ethernet packets with the DLNAQOS User Priority level as defined in section 7.1 of DLNA 1.5 [Ref10]. V1.0 Rev 1.5.1 218 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics 7.4 Diagnostics 7.4.1 Recommendations To monitor QoS throughout the system, diagnostic tools must be available on both the server and the client software. The goal of diagnostics in RVU is to provide ongoing non-invasive monitoring of network performance. In addition, diagnostic tools help to remediate issues with new installations. [7.4.1-1] S: RVU-S, O: RVU-C Tools for diagnosing issues with an RVU deployment should be able to perform the following: System/throughput tests Feedback analysis Bidirectional analysis Remote customer support discovery of existing traffic streams Connectivity tests [7.4.1-2] S: RVU-C The RVU client should utilize a local user interface to manage the setup, connectivity, status, and diagnostics for the network technology selected. [7.4.1-3] S: RVU-S, RVU-C DELETED. [7.4.1-4] S: RVU-S, RVU-C Setup and diagnostic tools should be provided for each network technology incorporated in an RVU element. 7.4.2 Requirements [7.4.2-1] M: RVU-S, RVU-C To support network connectivity diagnostics, an RVU element shall support UPnP discovery (discussed in section 2 of this document). [7.4.2-2] M: RVU-S, RVU-C An RVU element shall support basic ping capability. 7.4.2.1 PHY Stats RVU servers and clients must obtain, accumulate, and communicate statistics that indicate the health of the network between each network node. Which specific statistics must be available depends on the physical layer of the segment. These statistics are referred to as “PHY stats.” [7.4.2.1-1] M: RVU-S, RVU-C An RVU element shall make the PHY rate per link (raw MAC numbers) available for each node- to-node link. V1.0 Rev 1.5.1 219 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics [7.4.2.1-2] M: RVU-S, RVU-C An RVU element shall make the number of packets delivered available for each node-to-node link. [7.4.2.1-3] M: RVU-S, RVU-C An RVU element shall make the number of errored packets available for each node-to-node link. [7.4.2.1-4] M: RVU-S An RVU server shall collect the number of packets delivered and number of errored packets for each node, logging the time at which the collection took place. [7.4.2.1-5] S: RVU-S An RVU server's collection of packet delivery and error information should be infrequent (e.g., once every 24 hours). [7.4.2.1-6] M: RVU-S An RVU server shall use the number of packets delivered and number of errored packets to calculate the actual packet error rate. Note: A low packet error rate is expected (e.g., 1 error in 100,000 packets); excessive measured packet error rate over time indicates unexpected impulse noise sources in the network. For example, for each network (MoCA, 802.11n, HomePlug, etc.), the packet/byte count and packet error count must be available. In addition, PHY rates for each node-to-node link must be accessible, as shown in Table 7-1. From_Node_MAC To_Node_MAC PHY Rate MAC of RVU server MAC of client A Rate from server to client A in kbps MAC of client A MAC of RVU server Rate from client A to server in kbps MAC of RVU server MAC of client B Rate from server to client B in kbps MAC of client B MAC of RVU server Rate from client B to server in kbps Table 7-1: PHY Rates per Link [7.4.2.1-7] M: RVU-S, RVU-C The syntax used by an RVU element for the PHY stats shall be in standard network byte order. [7.4.2.1-8] M: RVU-S, RVU-C An RVU element shall format the PHY stats as shown in Table 7-2, with fields as defined in Table 7-3. V1.0 Rev 1.5.1 220 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol QoS and Diagnostics Syntax Bits Format Comment phy_stats { bytes_sent 32 uimsbf total number of bytes sent from node bytes_recv 32 uimsbf total number of bytes received by node err_pkts 32 uimsbf number of packets received in error node_cnt 8 uimsbf number of nodes in network for (i=0; i Table 7-2: PHY Stats Syntax Field Definition bytes_sent This shall be the total number of bytes sent from the specified node. bytes_recv This shall be the total number of bytes received from the specified node. err_pkts This shall be the total number erroneously-received packets. node_cnt This shall be the total number of nodes in the network. mac This shall be the standard MAC address of the node. list_cnt This shall be the number of node-to-node links, defined as the number of nodes multiplied by one less than the number of nodes. For example, if there are 5 nodes in the network, the list_cnt would be 5*4=20. src_mac The MAC table index of the source node. dst_mac The MAC table index of the destination node. phy_rate The node-to-node transfer rate in kbps Table 7-3: PHY Stats Field Definitions V1.0 Rev 1.5.1 221 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition 8 Client Image Acquisition The Client Image Acquisition (CIA) sub-protocol of RVU defines the optional process to enable clients to acquire an executable boot image from the server. The section defines how a client requests and acquires its boot image checks for a new boot image and is notified when one exists RVU clients are not required to use the CIA sub-protocol. Throughout this section, requirements that are marked as mandatory for an RVU client are mandatory only for those clients that choose to use the CIA sub-protocol. Clients that choose to implement the CIA sub- protocol must meet all the mandatory requirements in this section (i.e. all required features must be implemented). RVU clients that do not use the CIA sub-protocol must not use any CIA actions or call any CIA functions. RVU servers should use the CIA sub-protocol. Throughout this section, requirements that are marked as mandatory for an RVU server are mandatory only for those servers that choose to use the CIA sub-protocol. Servers that choose to implement the CIA sub-protocol must meet all the mandatory requirements in this section (i.e. all required features must be implemented). Servers that choose to not implement the CIA sub-protocol do not implement the Client Image Manager service, see Section 12. An RVU server is expected to work with all configurations of validated RVU clients (see 7.3.1), whether or not they employ the CIA sub-protocol. The overall flow for the optional client image acquisition process is shown in Figure 8-1 below. Acquisition Client obtains boot image from server. Client Request and Server Search Image available Yes No to server? Client Transfer Server Download (if necessary) Client Image Usage Management Client and server coordinate to manage client boot image. Figure 8-1: Client Image Acquisition Flow V1.0 Rev 1.5.1 222 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition 8.1 Standards RVU’s CIA section uses TFTP and SHA-1 [Ref17] hash functions, as well as UPnP actions and eventing. 8.2 Summary of Processes All RVU servers and clients that employ the RVU CIA sub-protocol, must implement the following functionality: Client Image Acquisition At startup, the client resident software sends a request to the server to determine the location of its boot image, and, if the client has an existing boot image, whether the server has access to a newer boot image than the one the client is currently using. The server responds with information specifying the location of the client’s boot image and whether an upgrade is required. Using the information provided in the reply, the client downloads the boot image if necessary. The client executes the boot image. Client Image Management When the server acquires a new image for any client, the server notifies all clients that a new image has arrived. Each client then queries the server as to whether this new image is targeted to that client. The following figures show examples of client and server processes for boot image acquisition and management. V1.0 Rev 1.5.1 223 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition Figure 8-2 shows the suggested initialization process if a boot image for the client is available to the server. Client Server Check for software Is image CheckImage No See other diagram on server available? Should client Yes upgrade? Send response: Download and UpgradeRequired = Yes verify image True, Availability = 0 Use current image Download Send response: Boot software and verification Yes UpgradeRequired = No image successful? False No Redo UPnP Is image No Discovery valid? Yes Select RVU Server Continue Session Management process Figure 8-2: CIA Flow: Boot Image Found on Server V1.0 Rev 1.5.1 224 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition Figure 8-3 is an example of initial client contact with a server where a boot image for the client is not available to the server. Note that in this case the client may wait indefinitely for a boot image. While the client should have a process for handling this case, defining this process is outside the scope of this document. Client Server Check for software Is image Will server try to CheckImage No on server available? acquire image? Yes Select Envoy No Server See other diagram Boot resident Send response: software image Availability = 2 Yes No Yes Have Wait for Send response: No resident image? Availability = 1 image? Yes Request notification if NewImageID State subscribeToNewImageID() image acquired Variable Server acquires Update NewImageID software for any new State Variable client Send notification to subscribed clients Figure 8-3: CIA Flow: Boot Image is Not Found on Server Sample sequence diagrams for CIA are shown in the following figures. V1.0 Rev 1.5.1 225 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition Figure 8-4 shows the initial image acquisition process. The steps in the shaded area only occur if the server does not have the client image when the client first calls the server. The last four steps always happen when the client is trying to acquire new software from the server (regardless of whether the server already has an image for the client). Client Server CheckImage UPnP Action Return values indicating image is not available Subscribe to NewImageID Get Client Image for Distribution Update NewImageID Send NewImageID Event to Subscribed Clients CheckImage UPnP Action Return values indicating TFTP location of Client Image TFTP Pull using TFTP location provided Client Image Key Solid = request/action Dotted = response Figure 8-4: Initial Client Image Acquisition Figure 8-5 shows an example of image maintenance initialization where the server does not have a new image for the client during initialization. Client Server Run Client Image Subscribe to NewImageID CheckImage UPnP Action Return values indicating image is up-to-date Figure 8-5: Client Image Maintenance Initialization V1.0 Rev 1.5.1 226 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition Figure 8-6 shows the maintenance of the client image, starting at the point where the server gets a new boot image for the client. Client Server Update NewImageID Send NewImageID Event to Subscribed Clients CheckImage UPnP Action Return values indicating TFTP location of Client Image and that Upgrade is Necessary Determine when to Upgrade based on Return values from CheckImage Action TFTP Pull using TFTP location provided Client Image Return to Client Image Maintenance Initialization Sequence Figure 8-6: Client Image Maintenance 8.3 General Requirements [8.3-1] M: RVU-C An RVU client shall avoid using a value of 0 (zero) for the major software version number if the minor software version number is also zero. [8.3-2] M: RVU-S An RVU server shall only distribute RVU-related client software. RVU CIA is not a mechanism for updating client software that is not related to the RVU protocol. 8.4 Client Image Acquisition 8.4.1 Client Request and Server Search [8.4.1-1] M: RVU-C Following the selection of an RVU server (described in section 3.2.1), an RVU client shall invoke the CheckImage UPnP action. [8.4.1-2] M: RVU-C An RVU client shall set both the MajorSoftwareVersion and MinorSoftwareVersion numbers in the CheckImage UPnP action to zeroes (0) if the client has no boot image. [8.4.1-3] M: RVU-S An RVU server shall respond to a CheckImage action with a message that an image is not available as soon as the server determines that it is unable to locate a software image for the client (i.e., the server will not delay its response while attempting to obtain an image for the client). V1.0 Rev 1.5.1 227 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition [8.4.1-4] M: RVU-S If the major version number of the client image on the server is greater than the major version number on client's image, the RVU server shall consider its image to be an upgrade to the client's image. [8.4.1-5] M: RVU-S If the client image on the server and on the client have the same major version number, and the minor version number on the server's image is greater than the minor version number on the client's image, the RVU server shall consider its image to be an upgrade to the client's image. [8.4.1-6] M: RVU-S An RVU server shall provide the fully qualified pathname specifying where on the server the boot image resides in the TftpFilepath argument of the CheckImage response if the server is distributing a boot image for the client. [8.4.1-7] M: RVU-S An RVU server shall set the UpgradeRequired argument of the CheckImage response to true if the server determines that the requesting client must obtain a new boot image. [8.4.1-8] M: RVU-S An RVU server shall set the UpgradeRequired argument of the CheckImage response to true if the client provided zeroes in both its MajorSoftwareVersion and MinorSoftwareVersion (indicating that a client does not have a boot image, per [8.4.1-2]), even if the server is not distributing a boot image for the client. [8.4.1-9] M: RVU-S An RVU server shall set the UpgradeRequired argument of the CheckImage response to false if the client provided values other than zeroes in both its MajorSoftwareVersion and MinorSoftwareVersion (indicating that the client has a boot image) if the server is not distributing a boot image for the client. [8.4.1-10] M: RVU-S If an RVU server sets the UpgradeRequired argument of the CheckImage response to false, it shall also set the Urgent argument of the response to false. [8.4.1-11] S: RVU-S If an RVU server sets the UpgradeRequired argument of the CheckImage response to true, it should also set the Urgent argument of the response to true if the server determines the client must upgrade immediately. [8.4.1-12] S: RVU-S If an RVU server sets the UpgradeRequired argument of the CheckImage response to true, it should set the Urgent argument of the response to false if the server determines that the client need not upgrade immediately. [8.4.1-13] M: RVU-S An RVU server shall provide the fully qualified pathname per [8.4.1-6] if the Availability argument of the CheckImage response is set to 0 (zero). V1.0 Rev 1.5.1 228 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition [8.4.1-14] O: RVU-S If an RVU server does not intend to acquire a boot image for a client, the server may set the Availability argument of the CheckImage response to 2. [8.4.1-15] M: RVU-S If an RVU server is unable to locate a boot image for a client, and the server chooses not to notify the client that it does not intend to acquire the image per [8.4.1-14], the server shall set the Availability argument of the CheckImage response to 1 (one). [8.4.1-16] S: RVU-C If an RVU client receives notification that software is not currently available on the server but the server will attempt to acquire a boot image, and the client chooses to wait for the server to obtain its boot image, the client should subscribe to eventing on the NewImageID state variable on the RVU server. [8.4.1-17] S: RVU-C If an RVU client receives notification that software is not currently available on the server, and the client subscribes to eventing on the NewImageID state variable on the RVU server, and has no stored image, the client should have a fallback mechanism so that the client does not wait indefinitely for a change to this state variable. For example, the client should call CheckImage another time or select a different RVU server. [8.4.1-18] O: RVU-C If an RVU client receives notification that software is not currently available on the server, and no other RVU servers are found, the client may attempt to boot any software image that it currently has. [8.4.1-19] M: RVU-C If an RVU client receives notification that a software upgrade is not required, it shall continue using its current boot image, per section 8.4.4. [8.4.1-20] M: RVU-S An RVU server shall have the ability to process and send a response to each requesting client within 2 seconds of the receipt of a request. Note: an RVU server will likely receive multiple requests since multiple clients may exist on the network. [8.4.1-21] O: RVU-C An RVU client may provide a URL in the DownloadLocation argument of the CheckImage UPnP action, indicating where the client software image will be available. 8.4.2 Server Download Note: This section only describes the features an internet-capable RVU server must support in order to acquire a client boot image using a client-provided URL. An RVU server may have other methods of acquiring boot images for its clients, but these other methods are outside the scope of the RVU protocol. The requirements in this section (8.4.2) are optional for RVU servers that have alternate methods of obtaining client images. However, RVU servers that do not have alternate image acquisition methods, and those that have alternate methods but choose to implement this functionality, are required to meet all mandatory requirements in this section. V1.0 Rev 1.5.1 229 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition [8.4.2-1] M: RVU-S An RVU server that has internet connectivity shall be capable of searching for a client’s boot image given its URL. [8.4.2-2] M: RVU-C DELETED [8.4.2-3] M: RVU-S If an RVU client specifies a URL in the CheckImage action, and the RVU server is unable to find a boot image locally for that client or begin obtaining the image by other means, the RVU server shall search for a client image at that URL. [8.4.2-4] M: RVU-S If an RVU server is able to locate a client image at the URL specified by the client in the CheckImage action, the RVU server shall download that image. [8.4.2-5] M: RVU-S If an RVU server successfully uses a client-provided URL to find a client image, the server shall use the version information for that client image found at that URL concatenated with ".version". [8.4.2-6] M: RVU-S An RVU server shall interpret the ASCII-formatted client image version number found at the client-provided URL as "majorNumber.minorNumber", where majorNumber is the major version number of the image, and minorNumber is the minor version number of the image. [8.4.2-7] M: RVU-S An RVU server shall associate the version numbers found at the client-provided URL with the software image found at that URL. [8.4.2-8] M: RVU-S If no version numbers are available at the client-provided URL, an RVU server shall not distribute the associated image. [8.4.2-9] M: RVU-S If an RVU server uses a client-provided URL to find and download a client image, the server perform a shall a SHA-1 hash [Ref17] of the downloaded software image. [8.4.2-10] M: RVU-S An RVU server shall copy the checksum information found at the URL of the software concatenated with ".checksum". [8.4.2-11] M: RVU-S An RVU server shall interpret the checksum found at the client-provided URL as a standard hexadecimal ASCII string. Example: 2eb722f340d4e57aa79bb5422b94d556888cbf38. [8.4.2-12] M: RVU-S If the SHA-1 hash of the software image downloaded in [8.4.2-4] does not match the checksum from [8.4.2-10], an RVU server shall not distribute the downloaded image. V1.0 Rev 1.5.1 230 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition 8.4.3 Client Transfer [8.4.3-1] M: RVU-C If an RVU client has obtained the fully qualified pathname specifying where on the server the boot image resides and UpgradeRequired is true, the client shall establish a TFTP session to the specified location on its associated RVU server and pull the file at the filepath provided in the response to the CheckImage action. [8.4.3-2] O: RVU-C If an RVU client that is currently running a client image receives a response to the CheckImage action with UpgradeRequired set to true but with Urgent set to false, the client may postpone the use of the new image. [8.4.3-3] M: RVU-C If an RVU client that is currently running a client image receives a response to the CheckImage action with UpgradeRequired set to true and Urgent set to true, the client shall immediately perform the TFTP transfer and use the new image as soon as the transfer is complete. [8.4.3-4] O: RVU-C If an RVU client has obtained the fully qualified pathname specifying where on the server the boot image resides, the Availability argument is 0 (zero), and UpgradeRequired is false, the client may perform the TFTP transfer from the specified location on its associated RVU server. [8.4.3-5] M: RVU-C Once the entire boot image has been downloaded, the client shall verify the validity of the boot image. Note: CIA does not provide any authenticity or integrity checking of the boot image itself. It is strongly suggested that clients internally verify that the acquired boot image is an authorized boot image intended for the client. [8.4.3-6] M: RVU-S An RVU server shall transfer the boot image as-is to the requesting client (i.e., the server does not alter the client image in any way). [8.4.3-7] O: RVU-C An RVU client may ignore an image if it recognizes the given AvailableMajorSoftwareVersion and AvailableMinorSoftwareVersion as an image that has failed previously. 8.4.4 Client Boot Image Usage [8.4.4-1] M: RVU-C After acquiring and validating a boot image, or verifying that the existing boot image is current, an RVU client shall execute its boot image. [8.4.4-2] M: RVU-C Once its boot image is functional, an RVU client shall either re-perform UPnP discovery or access stored UPnP metadata from the initial discovery process. [8.4.4-3] M: RVU-C Once an RVU server is discovered, an RVU client shall select an RVU server as described in section 3.2.1. V1.0 Rev 1.5.1 231 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Client Image Acquisition [8.4.4-4] O: RVU-C Once an RVU server is discovered, an RVU client may automatically re-select the RVU server selected during the initial startup process (described in section 3.2.1). [8.4.4-5] M: RVU-C After pairing with an RVU server per section 3.2.1, an RVU client shall subscribe to the NewImageID state variable on the associated server. [8.4.4-6] M: RVU-C After subscribing to the NewImageID state variable on the associated server, an RVU client shall invoke the CheckImage action on the associated server and proceed as described in section 8.4.3. 8.5 Client Image Management [8.5-1] S: RVU-S An RVU server should maintain boot images for its clients. [8.5-2] M: RVU-S An RVU server shall have methods by which the server can acquire updated boot images for clients. [8.5-3] M: RVU-S When an RVU server acquires an updated boot image for any RVU client, the server shall update the NewImageID state variable. [8.5-4] M: RVU-C When an RVU client receives notification that the NewImageID state variable has changed, the client shall invoke the CheckImage action and proceed as described in section 8.4.3. V1.0 Rev 1.5.1 232 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9 UPnP Templates Templates for the UPnP devices and services employed by the RVU protocol are described in this section. Pointers to the UPnP templates for standard devices and services used in RVU are provided in this section. In addition, templates for one new device (RVUServer, chapter 11) and one new service (ClientImageManager, chapter 12) created for the RVU protocol are referenced. Table 9-1 describes all devices and services required for an RVU server. Device/Service Detailed In RVUServer Section 11, Appendix A: RVUServer Device Template ClientImageManager Section 12, Appendix B: ClientImageManager Service Template RemoteUIServerDevice UPnP RemoteUIServerDevice:1, Device Template [Ref4] RemoteUIServer UPnP RemoteUIServer:1, Service Template [Ref5] Table 9-1: RVU Server Device and Service Templates Table 9-2 summarizes the devices and services on the RVU client. (Details about the columns in these tables can be found in Ref1.) Req Req DeviceType Root or ServiceType or Service ID Opt1 Opt1 MediaRenderer:1 Yes R RenderingControl:1.0 R urn:upnp-org:serviceId:RenderingControl — — — ConnectionManager:1.0 R urn:upnp- org:serviceId:ConnectionManager — — — AVTransport:1.0 R* urn:upnp-org:serviceId:AVTransport 1: R = Required, O = Optional, X = Non-standard. *Optional for standard UPnP MediaRenderer, but required for RVU client. Table 9-2: RVU Client Device and Service Definitions Table 9-3 provides references to the templates for the devices and services required for an RVU client. Device/Service Detailed In MediaRenderer UPnP MediaRenderer:1, Device Template [Ref6] Note: The AVTransport service, while optional in the MediaRenderer device template, is required for RVU. RenderingControl UPnP RenderingControl:1, Service Template [Ref7], extended as per section 9.1 of this document. ConnectionManager UPnP ConnectionManager:1, Service Template [Ref8], extended as per section 9.2 of this document. AVTransport UPnP AVTransport Service:1 Template [Ref9], extended as per section 9.3 of this document. Table 9-3: RVU Client Device and Service Templates V1.0 Rev 1.5.1 233 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9.1 RVU Extensions to RenderingControl Service An RVU server utilizes the Rendering Control Service (RCS) of a peer Media Rendering Device in order to control how content is rendered. In addition to the standard actions and state variables implemented in the standard UPnP Rendering Control Service 1.0, an RVU client must provide the extensions described in this section. A server may change the active audio stream of a program containing multiple audio tracks in a transport stream. A server may also change the active video stream of a program containing multiple video tracks in a transport stream. The extensions defined in this section allow for these stream changes. [9.1-1] M: RVU-C An RVU client shall implement all extensions to the UPnP RCS 1.0 as described in this section 9. 9.1.1 State Variables Variable Name Data Allowed Value Type X_AudioPID ui2 >= 0, <= 65535, += 1 X_AudioEncoding string see 9.1.1.2 X_VideoPID ui2 >= 0, <= 65535, += 1 X_VideoEncoding string see 9.1.1.4 Table 9-4: RenderingControl State Variables 9.1.1.1 X_AudioPID For MPEG2 transport streams, the X_AudioPID state variable shall represent the PID value of the currently decoded audio stream. For ITU-R BO.1516 SYSTEM B Transport Streams, the X_AudioPID state variable shall represent the SCID value of the currently decoded audio stream. The X_AudioPID state variable should only be accessed via the X_UpdateAudioSelection and X_GetAudioSelection actions. 9.1.1.2 X_AudioEncoding The X_AudioEncoding state variable represents the audio encoding type of the currently decoded audio stream. The value specified by this state variable shall match the stream_id indicated in the transport stream PES header for the selected audio stream. The allowed values are ”mp3”, “mpeg1layer2”, “aac”, “ac3”, “eac3”, “pcm”. This state variable should only be accessed through the X_UpdateAudioSelection and X_GetAudioSelection actions. 9.1.1.3 X_VideoPID The X_VideoPID state variable, accessed via the X_UpdateVideoSelection and X_GetVideoSelection represents PID value of the currently decoded video stream for MPEG2 V1.0 Rev 1.5.1 234 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates Transport Streams and the SCID value of the currently decoded video stream for ITU-R BO.1516 SYSTEM B Transport Streams. This state variable should only be accessed through the X_UpdateVideoSelection and X_GetVideoSelection actions. 9.1.1.4 X_VideoEncoding The X_VideoEncoding state variable, accessed via the X_UpdateVideoSelection and X_GetVideoSelection represents the video encoding type of the currently decoded video stream. The value specified by this state variable shall match the stream_id indicated in the transport stream PES header for the selected video stream. The allowed values are “h264”, “h265” and “mpeg2”. This state variable should only be accessed through the X_UpdateVideoSelection and X_GetVideoSelection actions. 9.1.2 Eventing and Moderation All new state variables defined for RVU are non-evented and non-moderated. Variable Name Evented Moderated Max Event Logical Min Delta per Event 2 Event Rate 1 Combination X_AudioPID no no n/a n/a n/a X_AudioEncoding no no n/a n/a n/a X_VideoPID no no n/a n/a n/a X_VideoEncoding no no n/a n/a n/a 1 Determined by N, where Rate = (Event)/(N seconds). 2 (N) * (allowedValueRange Step). Table 9-5: RecordingControl Event Moderation 9.1.3 Actions Extensions to the RCS 1.0 are listed in Table 9-6 and defined in this section 9.1.3. Except where noted, calling the action will have no effect on state. Name X_UpdateAudioSelection X_GetAudioSelection X_UpdateVideoSelection X_GetVideoSelection Table 9-6: Actions 9.1.3.1 X_UpdateAudioSelection The RVU server uses the X_UpdateAudioSelection action to update the actively decoded audio stream PID and encoding type. V1.0 Rev 1.5.1 235 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates The initial main audio PID and encoding type selections are provided in the 4th field of the ProtocolInfo contained in the URIMetaData field of an AVTransport SetAVTransportURI action invocation. When invoked during an active UPnP A/V session, this action shall result in the client immediately updating the audio PID and coding type. Otherwise, this action shall be ignored. 9.1.3.1.1 Arguments Argument(s) Direction relatedStateVariable InstanceID IN A_ARG_TYPE_InstanceID AudioPID IN X_AudioPID AudioEncoding IN X_AudioEncoding R Return value Table 9-7: X_UpdateAudioSelection arguments 9.1.3.1.2 Effect on State This action affects the X_AudioPID and the X_AudioEncoding state variables of the specified instance of this service. 9.1.3.1.3 Errors Standard errors from [Ref1] apply. Additional errors are: errorCode errorDescription Description 702 Invalid Instance ID The InstanceID is invalid. Table 9-8: X_UpdateAudioSelection error codes 9.1.3.2 X_GetAudioSelection The RVU server uses the X_GetAudioSelection to query the client for the currently decoded audio stream PID and encoding type. This action returns the currently active audio PID and audio coding type for currently selected audio stream. The initial main audio PID and encoding type selections are provided in the 4th field of the ProtocolInfo contained in the URIMetaData field of an AVTransport SetAVTransportURI action invocation. 9.1.3.2.1 Arguments Argument(s) Direction relatedStateVariable InstanceID IN A_ARG_TYPE_InstanceID AudioPID OUT R X_AudioPID AudioEncoding OUT R X_AudioEncoding R Return value Table 9-9: X_GetAudioSelection arguments V1.0 Rev 1.5.1 236 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9.1.3.2.2 Effect on State None. 9.1.3.2.3 Errors Standard errors from [Ref1] apply. Additional errors are: errorCode errorDescription Description 702 Invalid Instance ID The InstanceID is invalid. Table 9-10: X_GetAudioSelection error codes 9.1.3.3 X_UpdateVideoSelection The RVU server uses the X_UpdateVideoSelection action to update the actively decoded video stream PID and encoding type. This action changes the current active video PID and video coding type for the main video stream. The initial main video PID and encoding type selections are provided in the 4th field of the ProtocolInfo contained in the URIMetaData field of an AVTransport SetAVTransportURI action invocation. When invoked during an active UPnP A/V session, this action shall result in the client immediately updating the video PID and coding type. Otherwise, this action shall be ignored. 9.1.3.3.1 Arguments Argument(s) Direction relatedStateVariable InstanceID IN A_ARG_TYPE_InstanceID VideoPID IN X_VideoPID VideoEncoding IN X_VideoEncoding R Return value Table 9-11: X_UpdateVideoSelection arguments 9.1.3.3.2 Effect on State This action affects the X_VideoPID and the X_VideoEncoding state variables of the specified instance of this service. 9.1.3.3.3 Errors Standard errors from [Ref1] apply. Additional errors are: errorCode errorDescription Description 702 Invalid Instance ID The InstanceID is invalid. Table 9-12: X_UpdateVideoSelection error codes V1.0 Rev 1.5.1 237 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9.1.3.4 X_GetVideoSelection The RVU server uses the X_GetVideoSelection to query the client for the currently decoded video stream PID and encoding type. This action returns the currently active video PID and video coding type for currently selected video stream. The initial main video PID and encoding type selections are provided in the 4th field of the ProtocolInfo contained in the URIMetaData field of an AVTransport SetAVTransportURI action invocation. 9.1.3.4.1 Arguments Argument(s) Direction relatedStateVariable InstanceID IN A_ARG_TYPE_InstanceID VideoPID OUT R X_VideoPID VideoEncoding OUT R X_VideoEncoding R Return value Table 9-13: X_GetVideoSelection arguments 9.1.3.4.2 Effect on State None. 9.1.3.4.3 Errors Standard errors from [Ref1] apply. Additional errors are: errorCode errorDescription Description 702 Invalid Instance ID The InstanceID is invalid. Table 9-14: X_GetVideoSelection error codes 9.1.3.5 Relationships Between Actions The new actions defined in the RenderingControl service may be called in any order. 9.1.4 XML Additions Below is the XML for the extensions to the Rendering Control service defined in 9.1.1 and 9.1.3. 9.1.4.1 X_UpdateAudioSelection Action V1.0 Rev 1.5.1 238 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9.1.4.2 X_GetAudioSelection Action 9.1.4.3 X_UpdateVideoSelection Action V1.0 Rev 1.5.1 239 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9.1.4.4 X_GetVideoSelection Action 9.1.4.5 ServiceStateTable V1.0 Rev 1.5.1 240 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol UPnP Templates 9.2 RVU Extensions to Connection Manager Service The RVU protocol utilizes the Connection Manager Service of a peer Media Rendering Device in order to set up and tear down a UPnP A/V session. In addition to UPnP Connection Manager Service 1.0, an RVU client must implement the following Connection Manager actions for Media Renderers: PrepareForConnection ConnectionComplete If the PrepareForConnection and ConnectionComplete are implemented on the client, the server will utilize these actions to set up and tear down a UPnP A/V session. The server will not utilize these actions, and therefore be unable to setup a UPnP A/V session, if they are not implemented on the client. 9.3 RVU Extensions to AVTransport Service The RVU protocol utilizes the AVTransport Service of a peer Media Rendering Device as the interface for all media operations. The RVU protocol requires the following additional state transitions: Seek while in the PAUSED_PLAYBACK state must not fail if the Seek range is valid. Seek while in the PLAYING state must not fail if the Seek range is valid. Seek while in the STOPPED state must not fail if the Seek range is valid. V1.0 Rev 1.5.1 241 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol References 10 References Below is a list of documents referenced directly or indirectly within this specification. Ref Document Title Version Date Ref1 UPnP Device Architecture 1.0 20 Jul 2006 Ref2 UPnP QoS Architecture:2 2 16 Oct 2006 Ref3 Understanding Universal Plug and Play White Paper — Jun 2000 Ref4 UPnP RemoteUIServerDevice, DeviceTemplate:1, Device Template 1.01 2 Sep 2004 Ref5 UPnP RemoteUIServer, Service Template:1, Service Template 1.01 2 Sep 2004 Ref6 UPnP MediaRenderer:1, Device Template (Template v1.01) 1.01 25 June 2002 Ref7 UPnP RenderingControl:1, Service Template (Template v1.01) 1.01 25 June 2002 Ref8 UPnP ConnectionManager:1, Service Template (Template v1.01) 1.01 25 June 2002 Ref9 UPnP AVTransport:1, Service Template (Template v1.01) 1.01 25 June 2002 Ref10 DLNA Networked Device Interoperability Guidelines, Volume 1: 1.5 Oct 2006 Architectures and Protocols Ref11 DLNA Networked Device Interoperability Guidelines, Volume 3: Link 1.5 Oct 2006 Protection Ref12 RFC 793, Transmission Control Protocol (TCP) — Sep 1981 (http://tools.ietf.org/html/rfc793) Ref13 RFC 1950, ZLIB Compressed Data Format Specification 3.3 May 1996 (http://www.ietf.org/rfc/rfc1950.txt) Ref14 RFC 1951, DEFLATE Compressed Data Format Specification 1.3 May 1996 (http://www.ietf.org/rfc/rfc1951.txt) Ref15 EIA-766, Extended Data Services, U.S. Region Rating Table (RRT) and — Sep 1998 Content Advisory Descriptor for Transport of Content Advisory Information Using ATSC A/65 Program and System Information Protocol (PSIP) Ref16 High Definition Multimedia Interface 1.3a 10 Nov 2006 Ref17 FIPS 180-1, Secure Hash Standard 180-1 17 Apr 1995 Ref18 ISO/IEC 13818-1:2000(E), Information technology — Generic coding of — 1 Dec 2000 moving pictures and associated audio information: Systems Ref19 RFC 4366, Transport Layer Security (TLS) Extensions — April 2006 (http://www.ietf.org/rfc/rfc4366.txt) Ref20 DTCP Volume 1 Supplement E Mapping DTCP to IP 1.4 5 June 2013 Ref21 UPnP ContentDirectory:1, Service Template (Template v1.01) 1.01 25 June 2002 Ref22 International Telecommunications Union, Recommendation ITU-R BO.1516, — 1 Jan 2001 2001, "Digital multiprogramme television systems for use by satellite operating in the 11/12 GHz frequency range, System B" Ref23 Compositing Digital Images (Porter Duff), from ACM SIGGRAPH Computer — July 1984 Graphics archive Volume 18 , Issue 3 http://portal.acm.org/citation.cfm?id=808606 Ref24 ARIB STD-B24, Volume 2(1/2), Data Coding and Transmission Specification 5.2-E1 6 June 2008 for Digital Broadcasting, version 5.2-E1, June 6 2008 Ref25 DLNA Guidelines August 2009 Volume 2: Media Format Profiles Aug 2009 Ref26 ISO/IEC 13818-2:2000, Information technology -- Generic coding of moving Dec 2000 pictures and associated audio information: Video Ref27 A/72 Part 1: Video System Characteristics of AVC in the ATSC Digital July 2008 Television System Ref28 RFC 2616, Hypertext Transfer Protocol 1.1 June 1999 V1.0 Rev 1.5.1 242 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol References (http://Tools.ietf.org/html/rfc2616) Ref29 IETF Network Working Group RFC4122, A Universally Unique IDentifier July 2005 (UUID) URN Namespace Ref30 MPEG_DIRECTV_SD Video Profile Constraints Relative to ISO 13818-2 Nov 2010 http://www.rvualliance.org/, member log in, technical WG, reference documents Ref31 MPEG_DIRECTV_SD Audio Profile Constraints Relative to ISO 11172-1 & Nov 2010 3 http://www.rvualliance.org/, member log in, technical WG, reference documents Ref32 ISO 11172-1 Information technology -- Coding of moving pictures and 1993 – 1999 associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 1: Systems Ref33 ISO 13818-7 Information technology — Generic coding 2006 – 2010 of moving pictures and associated audio information — Part 7: Advanced Audio Coding (AAC) Ref34 ISO 14496-3:2001/Amd 1:2003 Information technology — Coding of 2001, 2003 audio-visual objects — Part 3: Audio Ref35 ISO 14496-14:2003 Information technology — Coding of 2003 – 2010 audio-visual objects — Part 14: MP4 file format Ref36 ISO 11172-3 Information technology -- Coding of moving pictures and 1993-1996 associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 3: Audio Ref37 ABNT* NBR 15604:2008 Digital Terrestrial Television – Receivers * ABNT = Brazilian National Standards Organization, in Portuguese as Associação Brasileira de Normas Técnicas (ABNT) Ref38 ABNT NBR 15602:2007 - Digital terrestrial television - Video coding, audio coding and multiplexing Ref39 ABNT NBR 15603:2007 - Digital terrestrial television - Multiplexing and service information (SI) Ref40 ARIB STD-B24 Data Coding and Transmission Specification for Digital Broadcasting (Closed Captioning) Ref41 ETSI EN 300 743, Digital Video Broadcasting (DVB) Subtitling 1.3.1 Nov 2006 systems Ref42 MPEG_DIRECTV_SD Video Profile Subtitling and Client Decoding 0.1 Dec 2012 Requirements for Latin American Services https://causeway.rvualliance.org/wg/TWG/document/532 Ref43 ISO-639-3:2007 Codes for the representation of names of 2007 languages — Part 3: Alpha-3 code for comprehensive coverage of languages Ref44 ISO/IEC 23008-2 MPEG-H Part 2 and ITU-T H.265, Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding Ref45 RVU Version 2.0 Protocol Specification Rev 1.0 Dec 2012 FINAL Table 10-1: Documentation References V1.0 Rev 1.5.1 243 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix A: RVUServer Device Template 11 Appendix A: RVUServer Device Template 11.1 Overview and Scope This document defines the device: urn:rvualliance-org:device:RVUServer:1 This device can be a UPnP root device, or it can be embedded within a different device. 11.2 Device Definitions 11.2.1 Device Type The following device type identifies a device that is compliant with this template: urn:rvualliance-org:device:RVUServer:1 11.2.2 Device Model The RVUServer device must contain a standard UPnP subdevice: RemoteUIServerDevice. It should also provide a ClientImageManager service. The RemoteUIServerDevice is used to obtain information necessary to setup a session, such as the supported protocols and location of the remote UI server. The RVUServer is used to provide the ClientImageManager service, which provides a control and notification mechanism for maintaining client software images. Specifications for the RemoteUIServerDevice device can be found at http://www.upnp.org/standardizeddcps/remoteui.asp in the RemoteUIServerDevice document. This UPnP device must be employed exactly as specified in this document. Specifications for the RemoteUIServerService service can also be found at http://www.upnp.org/standardizeddcps/remoteui.asp in the RemoteUIServerService document. This UPnP service must be employed exactly as specified in this document. Specifications for the ClientImageManager service can be found in section 12 of this document. This UPnP service must be employed exactly as specified in this document. The following table summarizes the devices and services on the RVU server. Req Req DeviceType Root or ServiceType or Service ID Opt1 Opt1 RVUServer:1 Yes R ClientImageManager: O urn:rvualliance- 1 org:serviceId:ClientImageManager RemoteUIServerDevice:1 No R RemoteUIServer:1 R urn:upnp- org:serviceId:RemoteUIServer 1: R = Required, O = Optional, X = Non-standard. Table 11-1: RVU Server Devices and Services V1.0 Rev 1.5.1 244 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix A: RVUServer Device Template Figure 11-1 shows the logical structure of the RVUServer Device and its sub-device and services. RVUServer RemoteUiServerDevice RemoteUIServer ClientImageManager Figure 11-1: RVU Server Structure 11.2.3 Theory of Operation 11.2.3.1 RVUServer The ClientImageManager service defines a UPnP service on the RVUServer UPnP device. This service contains a CheckImage action, which is invoked by a client to determine whether the client needs to download a new boot image, whether an upgrade is required, whether an immediate upgrade is needed, and where that new software is available. This action is invoked at initial client startup, and also when clients that are subscribed to the service's state variable, NewImageID, are notified that the variable has changed. 11.2.3.2 RemoteUIServerDevice The RemoteUIServerDevice is used to obtain information necessary to set up a session, such as supported protocols and location of the remote UI server. To set up a session, an RVU client uses the GetCompatibleUIs action on the RemoteUIServerDevice's RemoteUIServer service. The client uses one of the listed protocols to establish a session. If there are no compatible UIs with the client, or the client fails to connect to the RUI output module, the client ceases to attempt to connect to the server and may display an appropriate error message. 11.3 XML Device Description The following XML defines an RVUServer device. V1.0 Rev 1.5.1 246 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix B: ClientImageManager Service Template 12 Appendix B: ClientImageManager Service Template 12.1 Overview and Scope This document defines the urn:schemas-rvualliance-org:service:ClientImageManager:1 ClientImageManager:1 provides a control and notification mechanism to a client device for maintaining client software images. It provides clients with notifications about events of concern. Upon receiving notifications the client requests instructions from its associated server on how to proceed, or a client can make requests on its own if its internal logic requires. ClientImageManager:1 enables the following functions: Notifications of new client images available for distribution Querying for client image locations and upgrade requirements 12.2 Service Modeling Definitions 12.2.1 Service Type The following service type identifies a service that is compliant with this template: urn:schemas-rvualliance-org:service:ClientImageManager:1 The shorthand ClientImageManager is used herein to refer to this service type. 12.2.2 State Variables Variable Name Req. or Data Allowed Value Default Value Eng. Units Opt. 1 Type A_ARG_TYPE_Int R ui2 >= 0, <= 65535, += 1 0 n/a A_ARG_TYPE_String R String Undefined Empty String n/a A_ARG_TYPE_Bool R boolean false n/a NewImageID R ui2 >= 0, <= 65535, += 1 0 n/a 1 R = Required, O = Optional, X = Non-standard. Table 12-1: Client Image Manager State Variables 12.2.2.1 A_ARG_TYPE_Int A simple integer type (Unsigned, Two Bytes). 12.2.2.2 A_ARG_TYPE_String A simple string type. 12.2.2.3 A_ARG_TYPE_Bool A simple boolean type. V1.0 Rev 1.5.1 247 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix B: ClientImageManager Service Template 12.2.2.4 NewImageID NewImageID is a two-byte variable with an allowed range of 0 through 65535. The default value is 0. The actual value of this variable has no meaning. The NewImageID state variable is used for notifying clients that a new software image has been acquired for distribution by the server implementing this service. A server may also update this state variable to force all subscribed clients to verify they still meet the server's client image requirements. A client may subscribe to this variable when trying to acquire an image for use when the server does not have a software image for the client. When the server acquires a software image for a new client, this value changes and the server notifies the client. When notification is received, the client calls the CheckImage action to find whether the boot image that was acquired is targeted for that client. This allows clients to find out when their image is available without having to constantly poll the server. A client that is running an image that it acquired from the server also subscribes to this variable for notifications when an upgrade is available. When this variable is updated, the client calls the CheckImage action to find out whether the new image is for the client. If the client has a new image available at the server, the client will upgrade immediately if the upgrade is urgent, or may delay the upgrade if it is not urgent. 12.2.3 Eventing and Moderation As the table below summarizes, ClientImageManager:1 defines non-moderated eventing for some of its state variables. Variable Name Evented Moderated Max Event Logical Min Delta per Event 2 Event Rate 1 Combination NewImageID yes no n/a n/a n/a 1 Determined by N, where Rate = (Event)/(N seconds). 2 (N) * (allowedValueRange Step). Table 12-2: Client Image Manager Event Moderation 12.2.3.1 Event Model Some clients will need to be able to react to changes when the standard state variables change state. None of the state variables contain large values, and none are likely to change particularly rapidly, so none are moderated. Note that clients do need to subscribe to eventing to correctly utilize this service. 12.2.4 Actions The ClientImageManager service defines a CheckImage action, which is triggered by events. This action is required, and is summarized in the table below. Except where noted, calling the action will have no effect on state. V1.0 Rev 1.5.1 248 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix B: ClientImageManager Service Template Name Req. or Opt. 1 CheckImage R 1 R = Required, O = Optional, X = Non-standard. Table 12-3: Actions 12.2.4.1 CheckImage A client invokes this action to determine whether new software is available from the server for that client. The returned parameters specify where to get the image if it exists on the server (TftpFilepath), whether a client is required to get the new image in order to connect to the server (UpgradeRequired), whether the server plans to get the software image for the client (Availability), and whether the new image must be used immediately (Urgent). 12.2.4.1.1 Arguments Argument(s) Direction Req/Opt relatedStateVariable Make IN Required A_ARG_TYPE_String Model IN Required A_ARG_TYPE_String HardwareRevision IN Required A_ARG_TYPE_String MajorSoftwareVersion IN Required A_ARG_TYPE_Int MinorSoftwareVersion IN Required A_ARG_TYPE_Int DownloadLocation IN Required A_ARG_TYPE_String TftpFilepath OUT R Required A_ARG_TYPE_String UpgradeRequired OUT R Required A_ARG_TYPE_Bool Availability OUT R Required A_ARG_TYPE_Int Urgent OUT R Required A_ARG_TYPE_Bool AvailableMajorSoftwareVersion** OUT* Optional A_ARG_TYPE_Int AvailableMinorSoftwareVersion** OUT* Optional A_ARG_TYPE_Int R Return value, * Major and minor versions of the update image Table 12-4: CheckImage arguments Make is the manufacturer of the client device. The client must keep this number constant as the server uses this value together with model and hardware revision to uniquely identify the client. Model is the model of the client device. The client must keep this number constant as the server uses this value together with make and hardware revision to uniquely identify the client. HardwareRevision is the revision of the hardware of the client device. The client must keep this number constant as the server uses this value together with make and model to uniquely identify the client. MajorSoftwareVersion is the major version number of the software currently running on the client device. V1.0 Rev 1.5.1 249 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix B: ClientImageManager Service Template MinorSoftwareVersion is the minor version number of the software currently running on the client device. Note: A value of zero (0) for both MajorSoftwareVersion and MinorSoftwareVersion version numbers indicates that the client has no boot image. The A_ARG_TYPE_Int used by MajorSoftwareVersion and MinorSoftwareVersion is a two byte unsigned integer (see section 12.2.2.1). DownloadLocation is a URL that the client can provide the server when the client image is available for download should the server decide to use it. TftpFilepath is the fully-qualified filepath on the associated server where the boot image may be found in the home directory of the server's tftp server. UpgradeRequired is true if the client is required to upgrade to a new boot image available at the destination indicated in the TftpFilepath, false if the client is not required to upgrade its boot image Availability indicates the current availability status of the client software image. Refer to the table below. Value Meaning 0 A boot image is currently available at the filepath indicated by TftpFilepath 1 A boot image is not currently available, but the server may attempt to acquire it 2 A boot image is not currently available and the server will not make an attempt to acquire it Urgent is true if the client must immediately use the image available at the server; otherwise, the client may delay using the new image. Urgent will only be true if UpgradeRequired is also true. AvailableMajorSoftwareVersion is the major version number of the update image. Set to zero (0) if there is no available update image. AvailableMinorSoftwareVersion is the minor version number of the update image. Set to zero (0) if there is no available update image. 12.2.4.1.2 Effect on State None. 12.2.4.1.3 Errors errorCode errorDescription Description 402 Invalid Args See section 3, Control, of Ref1. 501 Action Failed See section 3, Control, of Ref1. Table 12-5: CheckImage error codes 12.2.4.2 Relationships Between Actions The actions defined in the ClientImageManager service may be called in any order. V1.0 Rev 1.5.1 250 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix B: ClientImageManager Service Template 12.2.4.3 Common Error Codes The following table lists error codes common to actions for this service type. If an action results in multiple errors, the most-specific error should be returned. Errors Standard errors from [Ref1] apply. 12.2.5 Theory of Operation The ClientImageManager service defines a UPnP service for use in a UPnP device that provides a method to clients to upgrade their software. This service contains a CheckImage action that indicates whether a client needs to download a new boot image, whether an upgrade is required, where that new software is available, and whether that new image must be used immediately. This service also allows eventing on its NewImageID state variable, enabling all registered clients to be notified when the value of that variable changes. Client software manufacturers must avoid using the combination of a major software version number of zero (0) with a minor software version that is also zero (0). 12.2.5.1 Initial Client Image Acquisition A brand new client that has never connected to the server selects the server from all the servers available on the network and calls the action CheckImage. The client then gets a response indicating that the software image is not available. The client subscribes to the NewImageID. When the server acquires a software image for any new client, it updates the NewImageID. The client calls the CheckImage again, gets the location of the software image, and uses that to get the software image. In summary: New Client invokes CheckImage Action results indicate that client image is not available Client subscribes to NewImageID Receive event when server gets new client image Client invokes CheckImage Action results indicate where the client image is available for TFTP transfer 12.2.5.2 Client Image Maintenance A client subscribes to eventing from the state variable NewImageID. When the server acquires a software image for any new client, the server updates NewImageID. Each client sends the action CheckImage and acts on the response appropriately. V1.0 Rev 1.5.1 251 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix B: ClientImageManager Service Template In summary: Subscribe to eventing for ClientImageManager:1 Receive event when server gets new client image for distribution Client invokes CheckImage Client reacts to response from action 12.3 XML Device Description V1.0 Rev 1.5.1 253 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements 13 Appendix C: Extended Media Format Profiling Requirements 13.1 MPEG-4 Part 10 (AVC) Closed Caption Stream DLNA Media Format Profiles: AVC_TS_HP_HD_AC3_T AVC_TS_HP_HD_AC3_ISO A bitstream conformant with these profiles may include Closed Caption Streams with syntax, semantics, and usage rules defined in [Ref27], A/72 Part 1: Video System Characteristics of AVC in the ATSC Digital Television System, July 2008, and as shown below in Table 13-1. Syntax Value Bits Format user_data_registered_itu_t_t35 ( ) { itu_t_t35_country_code 0xB5 8 bslbf itu_t_t35_provider_code 0x0031 16 bslbf user identifier 32 bslbf user structure() } Table 13-1: ATSC AVC SEI Syntax If the itu_t_t35_provider_code is 0x[002F] (for DIRECTV), the user identifier and user_structure() of the [Ref27] ATSC SEI syntax shall be replaced with the syntax that conforms to Table 13-2. Syntax Bits Format for( i=0; i Table 13-2: AVC Caption Transport Syntax following provider_code = 0x[002F] V1.0 Rev 1.5.1 254 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements 13.2 Characteristics of MPEG_DIRECTV_SD Media Format Profiles 13.2.1 System Portion Profile for MPEG_DIRECTV_SD Profiles: MPEG_DIRECTV_SD_AC3 MPEG_DIRECTV_SD_AC3_T MPEG_DIRECTV_SD_MPEG1_L2 MPEG_DIRECTV_SD_MPEG1_L2_T The system characteristics of this MPEG_DIRECTV_SD System Portion Profile are defined in [Ref22]. Streams with MPEG_DIRECTV SD System Profiles that have a "T" (denoting TTS for timestamped transport stream) appended as part of their Profile Identifier must be preceded by a 32-bit timestamp to form 134-byte packets as illustrated in Figure Figure 13-1. The Timestamp format is uimsbf (unsigned integer most significant bit first) as defined in [Ref18]. Streams of this profile type that do not have a “T” appended are 130 byte packets, and are not preceded by a zero value 4 byte timestamp. 4 Byte 130 Byte Timestamp DSS Packet Figure 13-1: ITU-R BO.1516 SYSTEM B Transport Stream with TTS support The 4 byte timestamp field shall represent the 27 MHz clock binary counter value to control the relative input timing to the decoder of the transport stream. The 27 MHz clock shall have the same accuracy and precision requirements of a standard MPEG2 decoding clock as defined in [Ref18]. All ITU-R BO. 1516 SYSTEM B TTS compliant packets shall have a timestamp present at the beginning of the transport packet. This includes video/audio/data packets as well as AUX and NULL packets. Timestamped Transport Streams (TTS) are defined for MPEG2 Transport Streams by [Ref24] and [Ref25] and are identically appended to ITU-R BO. 1516 SYSTEM B transport packets. 13.2.2 Video Portion Profile for MPEG_DIRECTV_SD Video Decoders should comply with the further defined constraints of this video portion profile in [ref30]. Profiles: MPEG_DIRECTV_SD_AC3 MPEG_DIRECTV_SD_AC3_T MPEG_DIRECTV_SD_MPEG1_L2 MPEG_DIRECTV_SD_MPEG1_L2_T V1.0 Rev 1.5.1 255 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements This MPEG-2 video stream shall be compliant with ISO-13818-2 [Ref26]. Profile: MP@ML Chroma: 4:2:0 Video bit rate CBR: Equal to or less than 15 Mbps VBR: maximum bit rate equal to or less than 15 Mbps Resolution Aspect Ratio Field (interlaced) Frame Rate 720x480 4:3 59.94I 704x480 4:3 59.94I 544x480 4:3 59.94I 480x480 4:3 59.94I 352x480 4:3 59.94I 353x240 4:3 59.94I Table 13-3: MPEG_DIRECTV_SD Video Encoding Parameters Syntax Bits Format user_data() { user_data_start_code 32 0x000001B2 while( nextbits() != ‘0000 0000 0000 0000 0000 0001’ ) { user_data_length 8 uimsbf user_data_type 8 uimsbf if (user_data_type==0xFF) ext_user_data_type 8 uimsbf user_data_info() (user_dat uimsbf a_length- 1)*8 } next_start_code() } Table 13-4: MPEG_DIRECTV_SD Video Picture Header User Data 8-bit code Type user_data_length 0x02 presentation_time_stamp 1+5 0x04 decode_time_stamp 1+5 0x09 closed_caption 1+2 0x0A extended_data_services 1+2 V1.0 Rev 1.5.1 256 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements Table 13-5: MPEG_DIRECTV_SD Video User Data Types Syntax Bits Format user_data_info() { switch (user_data_type){ case presentation_time_stamp: six_bit_pad 6 "000000" presentation_time_stamp[31 ..30] 2 bslbf marker_bit 1 "1" presentation_time_stamp[29..15] 15 bslbf marker_bit 1 "1" presentation_time_stamp[14..0] 15 bslbf break case decode_time_stamp: six_bit_pad 6 "000000" decode_time_stamp[31 ..30] 2 bslbf marker_bit 1 "1" decode_time_stamp[29..15] 15 bslbf marker_bit 1 "1" decode_time_stamp[14..0] 15 bslbf case closed_caption: closed_caption_byte1 8 uimsbf closed_caption_byte2 8 uimsbf break case extended_data_services: extended_data_services_byte1 8 uimsbf extended_data_services_byte2 8 uimsbf break } Table 13-6: MPEG_DIRECTV_SD Video User Data Info 13.2.3 MPEG_DIRECTV_SD AV Format, Audio Portion Profile: MPEG1_L2 Decoders should comply with the further defined constraints of this audio portion profile in [ref31]. Profiles: MPEG_DIRECTV_SD_MPEG1_L2 MPEG_DIRECTV_SD_MPEG1_L2_T V1.0 Rev 1.5.1 257 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements A bitstream conformant with this profile must conform to all aspects of the audio portion profile of the MPEG-2 AV Format as specified in Section 9.2.83 of [Ref25], with the exception of 32 kHz and 44.1 kHz sampling rates. 13.2.4 MPEG_DIRECTV_SD AV Format, Audio Portion Profile: AC3 Decoders should comply with the further defined constraints of this audio portion profile in [ref31]. Profiles: MPEG_DIRECTV_SD_AC3 MPEG_DIRECTV_SD_AC3_T A bitstream conformant with this profile must conform to all aspects of the audio portion profile of the MPEG-2 AV Format as specified in Section 9.2.32 of [Ref25]. 13.2.5 MPEG_DIRECTV_SD AV Format, Captioning Portion Profile for Latin American Broadcast Regions See MPEG_DIRECTV_SD video profile subtitling for Latin America, [Ref42] 13.3 SBTVD Media Format Profile Media Format Profile Names: AVC_TS_HP_HD_HEAAC_L4_ISO AVC_TS_HP_HD_HEAAC_L4_T 13.3.1 System Portion Profile The system level characteristics for this profile are defined in [ref18] and [ref38] 13.3.2 Video Portion Profile This video stream profile shall be compliant to ISO/IEC-14496-10 / ITU-H.264 and the further defined constraints and resolutions defined in [ref37] and [ref38]. In addition this profile includes the optional 25 Hz and 50 Hz frame rates and the optional resolutions of 720x576i, 720x576p, 1280x720p50 and 1920x1080i50 as described in [ref37] and [ref38]. 13.3.3 Audio Portion Profile Audio encoding shall match the provisions for Level 4 in the (MPEG-4) High Efficiency (HE) AAC profile as defined in [ref34] and further constrained by [ref37] and [ref38] This HEAAC profile is a superset of the LC-AAC audio object. Clients that render any of the multichannel AAC profiles are also capable of rendering corresponding profiles with fewer channels, including stereo pair, monaural signal, and/or joint stereo mode. The SBTVD audio formats and levels defined in [ref37] and [ref38] include low complexity AAC: level 2 (LC-AAC@L2) for two channels, low complexity AAC: level 4 (LCAAC@ L4) for V1.0 Rev 1.5.1 258 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements multichannel, High-Efficiency (HE): level 2 (HE-AAC v1@L2) for two channels and High- Efficiency (HE): level 4 (HE-AAC v1@L4) for multichannel. 13.3.4 Captioning Portion Profile Captioning shall comply with the SBTVD Closed Captioning and Subtitling specification, [ref40] for SBTVD streams. A buffered elementary stream filter is needed to obtain SBTVD captioning data in addition to the filters for video and audio. 13.4 HEVC Media Format Profiles Media Format Profile Names: HEVC_TS_M10P_MT_EAC3_ISO HEVC_TS_M10P_MT_EAC3_T TS denotes MPEG transport stream format M10P denotes the H.265 the main 10 profile MT denotes main tier EAC3 denotes audio support ISO versus _T denotes whether or not the transport stream appends 4 bytes of TTS (for timestamped transport stream) or is simply an ISO defined 188 byte transport stream 13.4.1 System Portion Profile The system stream shall be conformant to [ref18] and the draft amendment to incorporate carriage of High Efficiency Video Coding (HEVC.) The AC-3 or Enhanced AC-3 packetized elementary stream shall conform to the requirements of a user stream type 1, as described in [ref18]. The AC-3 or Enhanced AC-3 elementary stream shall be byte-aligned within the MPEG-2 transport stream. This means the initial 8 bits of an AC-3 or Enhanced AC-3 syncframe shall reside in a single byte which is carried in the MPEG-2 transport stream. 13.4.2 Video Portion Profile The video stream shall be conformant to ISO/IEC 23008-2 MPEG-H Part 2 and ITU-T H.265 [ref44] at up to the Main 10 Profile @ Level 5.1, Main Tier. Any luminance resolution or any sample and picture aspect ratio allowed by the applied Profile, Level and Tier may be used. Resolution and frame rates may change in a video stream. HEVC allows optional signaling of color space. As of the writing of this revision, no major worldwide standards group is specified color space encoding for H.265 distribution, although DVB is leaning towards supporting both BT.709 and BT.2020. This specification will reference available specfications (when available) for signalling color space within H.265, or will insert requirements here in a future revision in the absence of other standards organizations requirements V1.0 Rev 1.5.1 259 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix C: Extended Media Format Profiling Requirements 13.4.3 Audio Portion Profile These profiles shall conform to the AC-3 and the Enhanced AC-3 audio streams as defined in ETSI TS 102 366, Digital Audio Compression (AC-3, Enhanced AC-3) Standard (Version 1.2.1, 2008-08). Additional information on substream configuration for the delivery of associated audio services can be found in Annex C of ETSI TS 101 154. 13.4.4 Captioning Portion Profile This profile may include captioning with syntax, semantics, and usage rules described in section 13.1. The SEI messages in AVC are used in HEVC, but must conform to HEVC semantic restrictions, if applicable. 13.5 AVC + MPEG1 Layer 2 audio These DLNA media format profiles shall conform to the requirements for these profiles in [Ref25]: AVC_TS_HP_HD_MPEG1_L2_T AVC_TS_HP_HD_MPEG1_L2_ISO 13.5.1 Subtitling Portion Profile A bitstream conformant with these profiles may contain DVB subtitles as specified in [Ref41]. V1.0 Rev 1.5.1 260 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix D: Latin American Client Requirements 14 Appendix D: Latin American Client Requirements Clients for any or all of the following Latin American regions shall implement the additional requirements of this section in addition to all mandatory requirements of this specification. 14.1 Brazil [14.1-1] M: RVU-C An RVU client shall be capable of decoding and displaying DVB subtitles [Ref41] that accompany any of the media format profiles listed in Table 5-31. [14.1-2] O: RVU-C An RVU client may support the media format profiles listed in Table 5-32. [14.1-3] M: RVU-C An RVU client shall support the media format profiles listed in Table 5-34 that include HEAAC audio, and in accordance with the requirements in section 13.3. [14.1-4] M: RVU-C An RVU client shall be capable of Dolby® MS10 Multistream Decoder requirements, and shall decode any of MS10 audio streams in combination with any of the video codecs included in Table 5-31. [14.1-5] O: RVU-C An RVU client may implement the language attribute of the GetClosedCaptioningState command. [14.1-6] M: RVU-C An RVU client shall support the ORG_SUB_INFO flag described in section 5.6.5. [14.1-7] S: RVU-C An RVU client should implement the org.rvualliance.subtitle local UI element listed in Table 4-89. 14.2 Mexico [14.2-1] M: RVU-C An RVU client shall support the requirements of section 14.1 with the exception of [14.1-3]. [14.2-2] M: RVU-C An RVU client shall support the media format profiles listed in Table 5-34 that include MPEG1- L2 audio and in accordance with the requirements of 13.5. 14.3 Other Regions (Panamericana) [14.3-1] M: RVU-C An RVU client shall support the media format profiles listed in Table 5-31, including the requirements of section 13.1. V1.0 Rev 1.5.1 261 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited. RVU Specification Protocol Appendix D: Latin American Client Requirements [14.3-2] M: RVU-C An RVU client shall support the media format profiles listed in Table 5-32, including all requirements of section 13.2. [14.3-3] M: RVU-C An RVU client shall support the media format profiles listed in Table 5-34 that include HEAAC audio, and in accordance with the requirements in section 13.3. Optional frame rates and resolutions in section 13.3.2 shall be mandatory for Panamericana operating regions [14.3-4] O: RVU-C An RVU client may implement the language attribute of the GetClosedCaptioningState command. [14.3-5] M: RVU-C An RVU client shall support the ORG_SUB_INFO flag described in section 5.6.5. [14.3-6] S: RVU-C An RVU client should implement the org.rvualliance.subtitle local UI element listed in Table 4-89. V1.0 Rev 1.5.1 262 of 262 28 May 2014 Copyright 2014 © RVU Alliance. RVU Alliance Confidential. Any form of reproduction and/or distribution of this document is prohibited.