RVU

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

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
st
4.2.1-8, 4.2.2-3 – noted action if hello received other than 1 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

RVU Specification

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
V1.0 Rev 1.5.1 4 of 262 28 May 2014

RVU Specification

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
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
V1.0 Rev 1.5.1 5 of 262 28 May 2014

RVU Specification

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
th
Added sample 4 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

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
RVU Specification
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

RVU Specification
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
RVU Specification
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

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

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

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

RVU Specification
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

RVU Specification
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

RVU Specification
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

RVU Specification
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

RVU Specification
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

RVU Specification
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

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

RVU Specification
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

RVU Specification
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

RVU Specification
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
RVU Specification
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
RVU Specification
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

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

RVU Specification
[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

RVU Specification
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

RVU Specification
[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

RVU Specification
[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

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

RVU Specification
[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

RVU Specification
Cached Yes
Start
server?
No
Search for
servers
No servers Zero
found servers?
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

RVU Specification
[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:
<deviceprofile xmlns=\"urn:schemas-upnp-org:remoteui:devprofile-1-0\"
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"
xsi:schemaLocation=\"urn:schemas-upnp-org:remoteui:devprofile-1-
0DeviceProfile.xsd\">
<maxHoldUI>0
</maxHoldUI>
<protocol shortName=\"RVU-RUI\">
</protocol>
</deviceprofile>
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.
<?xml version="1.0" encoding="UTF-8"?>
V1.0 Rev 1.5.1 34 of 262 28 May 2014

RVU Specification
<uilist xmlns="urn:schemas-upnp-org:remoteui:uilist-1-0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schemas-upnp-org:remoteui:uilist-1-0
CompatibleUIs.xsd">
<ui>
<uiID>1</uiID>
<name>RVU Remote UI</name>
<protocol shortName="RVU-RUI">
<uri>rvurui://[ip]:[port]</uri>
</protocol>
</ui>
</uilist>
In this example, [ip] is the IP address of the server, and [port] is the listening port on the server.
The square brackets are not included in the actual xml; for example, if the IP address was
128.0.0.8, and the port was 80, the uri line would be <uri>rvurui://128.0.0.8:80</uri>
V1.0 Rev 1.5.1 35 of 262 28 May 2014

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

RVU Specification
[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

RVU Specification
[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

RVU Specification
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:
<commandName commandToken=”commandTokenValue”
attributeName1=”attributeValue1” ... attributeNameN=”attributeValueN”/>
 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:
<Response errCode=”errorCodeValue” commandToken=”commandTokenValue”

attributeName1=”attributeValue1” ... attributeNameN=”attributeValueN”/>
 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

RVU Specification
[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

RVU Specification
[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
RVU Specification
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:
<Hello commandToken=”98765” channelId=”3” version=”1.0” callbackPort=”9999”/>
[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

RVU Specification
[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:
<Response errCode=”ERR_SUCCESS” commandToken=”98765”/>
[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

RVU Specification
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

RVU Specification
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

RVU Specification
[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

RVU Specification
 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

RVU Specification
[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

RVU Specification
[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

RVU Specification
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

RVU Specification
[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

RVU Specification

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

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.

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
RVU Specification

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.

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.

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

RVU Specification

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

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

RVU Specification

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
st
1 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
RVU Specification

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.
st
ERR_INVALID_PORTNUM The callback port number doesn’t match the port from the 1 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.

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

RVU Specification
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

Table 4-14: Shutdown response attributes
Error Codes
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.

Table 4-16: GetMemInfo command attributes
V1.0 Rev 1.5.1 57 of 262 28 May 2014

RVU Specification
[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.

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
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

RVU Specification
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

1 2
Key Function Operation 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
3
Active N/A 0x91 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
3
Back N/A 0x90 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

RVU Specification
Remote HDMI User HDMI HDMI CDI Comment

1 2
Key Function Operation 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.

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

RVU Specification
[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.

Table 4-21: HDMIKeyEvent response attributes
Error Codes
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.

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

RVU Specification
[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

Table 4-24: CDIKeyEvent response attributes
Error Codes
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.

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

RVU Specification
[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.

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
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.

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

RVU Specification

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

bufId The ID of the new buffer. uint
Table 4-30: AllocateBuffer response attributes
Error Codes
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

RVU Specification
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.

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

Table 4-33: DeallocateBuffer response attributes
Error Codes
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

RVU Specification

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

Table 4-36: Write response attributes
Error Codes
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

RVU Specification
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.

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

Table 4-39: Read response attributes
Error Codes
V1.0 Rev 1.5.1 67 of 262 28 May 2014

RVU Specification

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.

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

RVU Specification
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

Table 4-42: BlitQueue response attributes
Error Codes
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.

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
V1.0 Rev 1.5.1 69 of 262 28 May 2014

RVU Specification

Table 4-45: Dispatch response attributes
Error Codes
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.

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

RVU Specification
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

Table 4-48: EmptyQueue response attributes
Error Codes
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.

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
V1.0 Rev 1.5.1 71 of 262 28 May 2014
RVU Specification

Table 4-51: WaitVSync response attributes
Error Codes
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.

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
V1.0 Rev 1.5.1 72 of 262 28 May 2014
RVU Specification

Table 4-54: CopyBlit response attributes
Error Codes
ERR_BAD_ID One or more of the specified buffers has not been identified yet.
ERR_BAD_CLUT The CLUT(s) for the listed buffers are incompatible for this
operation.
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.

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

RVU Specification
[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

Table 4-57: FillBlit response attributes
Error Codes
ERR_BAD_CONFIG The specified color does not match the pixel format for this buffer.
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.

dstWidth Width of the region to be copied into, in pixels. uint
dstHeight Height of the region to be copied into, in pixels. uint
V1.0 Rev 1.5.1 74 of 262 28 May 2014
RVU Specification

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

Table 4-60: ResizeBlit response attributes
Error Codes
operation.
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

RVU Specification
[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.

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

Table 4-63: ShadeBlit response attributes
Error Codes
V1.0 Rev 1.5.1 76 of 262 28 May 2014
RVU Specification

ERR_BAD_CONFIG The specified color does not match the pixel format for this buffer.
operation.
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.

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

RVU Specification
[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

Table 4-66: BlendBlit response attributes
Error Codes
operation.
EmptyQueue command.
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].
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.

V1.0 Rev 1.5.1 78 of 262 28 May 2014

RVU Specification

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.
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.

V1.0 Rev 1.5.1 79 of 262 28 May 2014
RVU Specification

Table 4-69: MultiSourceBlendBlit response attributes
Error Codes
operation.
EmptyQueue command.
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

RVU Specification
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].
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

dstWidth Width of the region to be copied to, in pixels. uint
dstHeight Height of the region to be copied to, in pixels. uint
V1.0 Rev 1.5.1 81 of 262 28 May 2014

RVU Specification

srcWidth Width of the region to be copied, in pixels. uint
srcHeight Height of the region to be copied, in pixels. uint
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

Table 4-72: ResizeAndBlendBlit response attributes
Error Codes
operation.
EmptyQueue command.
Table 4-73: ResizeAndBlendBlit response error codes

V1.0 Rev 1.5.1 82 of 262 28 May 2014
RVU Specification
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

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
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

RVU Specification
[4.8.2.3.16-3] M: RVU-C
An RVU client shall respond to the ColorKeyResizeBlit command by returning the

Table 4-75: ColorKeyResizeBlit response attributes
Error Codes
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

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

RVU Specification
[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.

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

RVU Specification

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

RVU Specification

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
Table 4-79: GetGraphicsCaps response error codes
V1.0 Rev 1.5.1 87 of 262 28 May 2014

RVU Specification
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.

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.

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
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.

V1.0 Rev 1.5.1 88 of 262 28 May 2014

RVU Specification

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.

Table 4-84: SetZList response attributes
Error Codes
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

RVU Specification
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.

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

Table 4-87: SetCLUT response attributes
Error Codes
V1.0 Rev 1.5.1 90 of 262 28 May 2014
RVU Specification

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
V1.0 Rev 1.5.1 91 of 262 28 May 2014
RVU Specification

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.

elements A comma-delimited list of UI elements supported by the string
client.
Table 4-91: ListLocalUIElements response attributes
Error Codes
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

RVU Specification
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.

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

Table 4-94: RequestLocalUI response attributes
Error Codes
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

RVU Specification

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.

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

Table 4-97: LocalUIEvent response attributes
Error Codes
V1.0 Rev 1.5.1 94 of 262 28 May 2014

RVU Specification

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

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

Table 4-100: ClientRequestLocalUI response attributes
Error Codes
V1.0 Rev 1.5.1 95 of 262 28 May 2014

RVU Specification

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
RVU Specification

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.

bufId An identifier to represent the video stream associated with uint
avtId.
Table 4-103: GetVideoBuffer response attributes
Error Codes
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

V1.0 Rev 1.5.1 97 of 262 28 May 2014

RVU Specification

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

Table 4-106: ReleaseVideoBuffer response attributes
Error Codes
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

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
V1.0 Rev 1.5.1 98 of 262 28 May 2014
RVU Specification

Table 4-109: SetBackgroundColor response attributes
Error Codes
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.

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

Table 4-112: ConfigureDisplayBuffer response attributes
V1.0 Rev 1.5.1 99 of 262 28 May 2014

RVU Specification
Error Codes
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.

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

RVU Specification
[4.8.2.5.5-3] M: RVU-C
An RVU client shall respond to the ReconfigureDisplayBuffer command by returning the

Table 4-115: ReconfigureDisplayBuffer response attributes
Error Codes
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

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

V1.0 Rev 1.5.1 101 of 262 28 May 2014

RVU Specification
Table 4-118: ConfigureVideoFullscreen response attributes
Error Codes
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

non-full-screen according to the local window settings and the
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
width The width in pixels of the video buffer when projected onto the uint
coordinates.
height The height in pixels of the video buffer when projected onto the uint
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

V1.0 Rev 1.5.1 102 of 262 28 May 2014

RVU Specification

Table 4-121: ConfigureVideoWindow response attributes
Error Codes
ERR_BOUNDING The region specified by x, y, width, and height does not fit in the
output.
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.

non-full-screen according to the local window settings and the
x The horizontal position of the (non-full-screen) buffer (in output uint
y The vertical position of the (non-full-screen) buffer (in output uint
width The width in pixels of the video buffer when projected onto the uint
coordinates.
height The height in pixels of the video buffer when projected onto the uint
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

RVU Specification

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

Table 4-124: ConfigureWindowedVideoWindow response attributes
Error Codes
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.
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

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

RVU Specification

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

Table 4-127: ConfigureVideoDecodeResolution response attributes
Error Codes
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.

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

RVU Specification
[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

Table 4-130: BlindVideo response attributes
Error Codes
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

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.

V1.0 Rev 1.5.1 106 of 262 28 May 2014

RVU Specification

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
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

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
RVU Specification
 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.

Table 4-136: OutputSettingsChanged response attributes
Error Codes
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

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.

V1.0 Rev 1.5.1 108 of 262 28 May 2014
RVU Specification

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
yDisplayRes The post-decimation vertical resolution of the buffer uint
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
inputWidth The horizontal width in pixels of the decoded video being uint
With inputX, inputY and inputHeight, the coordinates will
inputHeight The vertical height in pixels of the decoded video being uint
With inputX, inputY and inputWidth, the coordinates will
blind 0: Normal display uint
1: Blacked out
Table 4-139: GetVideoDisplaySettings response attributes
Error Codes
ERR_BAD_ID The specified ID is not a valid video buffer.
V1.0 Rev 1.5.1 109 of 262 28 May 2014
RVU Specification
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

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
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
yDisplayRes The post-decimation vertical resolution of the buffer uint
inputX The horizontal position of the decoded video being uint
With inputY, inputWidth and inputHeight, the coordinates will
inputY The vertical position of the decoded video being displayed, uint
in decoded resolution coordinates.
With inputX, inputWidth and inputHeight, the coordinates will
inputWidth The horizontal width in pixels of the decoded video being uint
With inputX, inputY and inputHeight, the coordinates will
V1.0 Rev 1.5.1 110 of 262 28 May 2014

RVU Specification

inputHeight The vertical height in pixels of the decoded video being uint
With inputX, inputY and inputWidth, the coordinates will
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

Table 4-142: VideoDisplaySettingsChanged response attributes
Error Codes
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

RVU Specification
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

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

Table 4-146: AllowClosedCaptioning response attributes
Error Codes
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

RVU Specification
[4.8.2.5.16-1] M: RVU-S
An RVU server shall have the ability to send the EnableClosedCaptioning command as

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

Table 4-149: EnableClosedCaptioning response attributes
Error Codes
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

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

RVU Specification

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
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.

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

RVU Specification

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
leftY Optional uint
The Y position of the left eye region with respect to the
rightX Optional uint
The X position of the right eye region with respect to the
shall use a value of xRes/2.
rightY Optional uint
The Y position of the right eye region with respect to the
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

RVU Specification
[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

Table 4-155: ReconfigureDisplayBuffer3DTV response attributes
Error Codes
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

RVU Specification
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

RVU Specification
Display Buffer
xRes
(0,0)
(leftX, leftY) (rightX, rightY)
leftRightHeight
yRes
Left Right
Eye Eye
Region Region
leftRightWidth leftRightWidth
width width
(0,0)
(x,y)
yRes from OutputSettingsChanged

Display Buffer
Transformed into the height
height
Output Canvas
Half Resolution
Side by Side
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
RVU Specification
Display Buffer
xRes
(0,0)
leftRightHeight
yRes
Left Right
Eye Eye
Region Region
width
(0,0)
(x,y)

Display Buffer
height
Transformed into the

Output Canvas
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
RVU Specification
Display Buffer
xRes
(0,0)
leftRightHeight
yRes
Left Right
Eye Eye
Region Region
width
(0,0)
(x,y)

Display Buffer
height
Transformed into the

Output Canvas
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
RVU Specification
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

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

Table 4-159: Set3DTVFlattenStructure response attributes
Error Codes
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

RVU Specification
[4.8.2.6.1-1] M: RVU-S
An RVU server shall have the ability to send the OpenAudioDecoder command as described in

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.

decoderId The ID of an audio decoder to use. uint
Table 4-162: OpenAudioDecoder response attributes
Error Codes
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

V1.0 Rev 1.5.1 122 of 262 28 May 2014

RVU Specification

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

Table 4-165: CloseAudioDecoder response attributes
Error Codes
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

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

RVU Specification

count The number of audio decoders. uint
Table 4-168: GetNumAudioDecoders response attributes
Error Codes
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

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

RVU Specification

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

RVU Specification

pcmSampleRates Required if and only if the PCM flag is set in the hex
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
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
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
V1.0 Rev 1.5.1 126 of 262 28 May 2014

RVU Specification

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.

bufId The ID of the new buffer. uint
Table 4-174: AllocateAudioBuffer response attributes
Error Codes
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

bufId The buffer to release. uint
Table 4-176: DeallocateAudioBuffer command attributes
V1.0 Rev 1.5.1 127 of 262 28 May 2014

RVU Specification
[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

Table 4-177: DeallocateAudioBuffer response attributes
Error Codes
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.

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

RVU Specification
[4.8.2.6.7-3] M: RVU-C
An RVU client shall respond to the WriteAudioData command by returning the commandToken

Table 4-180: WriteAudioData response attributes
Error Codes
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.

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:
0x02: MPEG2-PES, ISO/IEC 13818-1 [Ref18]
0x04: MPEG1-PACKET, ISO/IEC 11172-1 [Ref32]
0x08: PCM
14:2003 [Ref35]
V1.0 Rev 1.5.1 129 of 262 28 May 2014

RVU Specification

encodedFormat Required if and only if the configId attribute is missing. hex
The audio encoding format of the audio. Choices are as
follows:
0x02: MPEG1-LAYER3 (mp3)
0x04: PCM
0x08: AC3
0x10: DTS
0x20: MPEG2-AAC (ISO/IEC 13818-7:1997
0x40: MPEG4-AAC (HE-AACv1, ISO/IEC 14496-
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.
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

RVU Specification

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.

configId A client-generated ID, used to identify this audio stream and uint
configuration.
Table 4-183: Play response attributes
Error Codes
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

RVU Specification
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.

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:
0x02: MPEG2-PES, ISO/IEC 13818-1 [Ref18]
0x04: MPEG1-PACKET, ISO/IEC 11172-1 [Ref32]
0x08: PCM
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:
0x02: MPEG1-Layer3 (mp3)
0x04: PCM
0x08: AC3
0x10: DTS
0x20: MPEG2-AAC (ISO/IEC 13818-7:1997
0x40: MPEG4-AAC (HE-AACv1, ISO/IEC 14496-
supported AAC profiles are allowed when
using this format
0x80: AC3-PLUS
V1.0 Rev 1.5.1 132 of 262 28 May 2014

RVU Specification

pcmFlags Required if and only if the encodedFormat attribute exists hex
and is set to PCM.
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

RVU Specification
[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.

configId A client-generated ID, used to identify this audio stream and uint
configuration.
Table 4-186: PlayBuffer response attributes
Error Codes
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.

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
RVU Specification
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.

Table 4-190: PlayStatus response attributes
Error Codes
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.

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.

V1.0 Rev 1.5.1 135 of 262 28 May 2014
RVU Specification
Table 4-193: Stop response attributes
Error Codes
ERR_SUCCESS The operation succeeded or there was nothing playing on the
specified decoder.
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

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

RVU Specification
[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

Table 4-197: MuteProgramAudio response attributes
Error Codes
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
RVU Specification
3 Configure display — ReconfigureDisplayBuffer
Table 4-199: Startup, No Video Sequence
Sequence Diagram
Client Server
Hello
GetGraphicsCaps
<graphics capablilites >
ReconfigureDisplayBuffer
Figure 4-6: Startup, No Video Sequence
4.8.4.2 Startup, One Video
Synopsis
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

RVU Specification
Sequence Diagram
Client Server
Hello
GetGraphicsCaps
<graphics capablilites>
GetVideoBuffer
<buffer ID>
VideoDisplaySettingsChanged
Figure 4-7: Startup, One Video Sequence
4.8.4.3 Single Video, Aspect Change
Synopsis
1 Format change OutputSettingsChanged —
2 Match display buffer to video — ReconfigureDisplayBuffer
display
Table 4-201: Single Video, Aspect Change Sequence
Sequence Diagram
Client Server
Figure 4-8: Single Video, Aspect Change Sequence
4.8.4.4 Single Video, Output Format Change
Synopsis
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
RVU Specification
Sequence Diagram
Client Server
ConfigureVideoDecodeResolution
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

RVU Specification
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

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
RVU Specification
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

RVU Specification
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

RVU Specification
[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

RVU Specification
 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

RVU Specification
[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
RVU Specification
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

RVU Specification
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

RVU Specification
FROM NO_MEDIA STOPPED PLAYING_ PLAYING_S PLAYING_ PAUSED_P

PRESENT NORMAL LOW FAST LAYBACK
TO
NO_MEDIA SetAVTransport
PRESENT URI
STOPPED SetAVTransport
SetAVTransport URI;
Stop Stop Stop Stop
URI Seek[Absolute
Time]
PLAYING_ Seek[Absolu Play Play Play
Play[Normal]
NORMAL te Time] [Normal] [Normal] [Normal]
PLAYING_ Seek
SLOW Play[Slow] Play[Slow] [Absolute Play[Slow] Play[Slow]
Time]
PLAYING_ Seek[Absolu
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

RVU Specification
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

1
Name Initial State Final State Section
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

RVU Specification

1
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
M: RVU-S, Playing
RVU-C Slow
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
RVU-C Playing Fast
V1.0 Rev 1.5.1 152 of 262 28 May 2014

RVU Specification

1
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
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
M: RVU-S, Playing PLAYBACK
RVU-C Slow
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

RVU Specification
Transition Notes
 Items italicized within brackets represent data to be filled in. For example,
"CSeq: <number>" translates to actual data such as "CSeq: 123".
 Items in bold represent actions. For example, SetAVTransportURI().
 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

RVU Specification
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 = <avtransport-instance-id>
CurrentURI = <uri-of-content>
CurrentURIMetaData = <uri-metadata>
2 The client sets its internal URI pointer to the URI specified by the CurrentURI parameter.
3 The client issues an AVTransport::LastChange event with the following parameters:
TransportState: STOPPED
AVTransportURI: <uri-of-content>
AVTransportURIMetaData: <meta-data>
Table 5-5: No Media to Stopped Sequence
Sequence Diagram
Client Server
Play Mod AVT / HTTP Control Point HTTP
AVT::SetAVTransportURI
InstanceId = <avtransport-instance-id>
CurrentURIMetaData = <content-meta-data>
AVT::LastChange
TransportState = STOPPED
AVTransportURI = <uri-of-content>
AVTransportURIMetaData = <uri-meta-data>
Figure 5-4: No Media to Stopped Sequence
5.2.1.2 STOPPED to STOPPED (SetAVTransportURI)

 State: STOPPED
V1.0 Rev 1.5.1 155 of 262 28 May 2014

RVU Specification
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:
2 The client sets its internal URI pointer to the URI specified by the CurrentURI argument.
AVTransportURI: <uri-of-content>
AVTransportURIMetaData: <meta-data>
Table 5-6: Stopped to Stopped (Ready) Sequence
Sequence Diagram
Client Server
AVT::SetAVTransportURI
AVT:LastChange
AVTransportURI = <uri-of-content>
AVTransportURIMetaData = <uri-meta-data>
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
RVU Specification
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.
 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:
Speed = 1
2 The client issues an AVTransport::LastChange event with parameters:
TransportState: PLAYING
TransportPlaySpeed: 1
3 The client issues an HTTP GET request to the server with the following headers:
transferMode.dlna.org: Streaming
TimeSeekRange.dlna.org: npt=<internal-start-time>
4 The client sets its local decoding rate to normal playback speed (1X) and configures other
decoder specific parameters.
Note: The client must examine the Sender Pacing bit of the DLNA.ORG_FLAGS field to
determine if clock synchronization must be utilized. If clock synchronization is required then the
client must take steps to ensure clock sync.
5 The server responds to the GET request by issuing a response containing the following response
headers:
HTTP Response Code 200 OK
TimeSeekRange.dlna.org: npt=<media-start-time> - <media-end-time>
Transfer-Coding: chunked
Content-Type: <mime-type>
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:
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

RVU Specification
Sequence Diagram
Client Server
AVT::Play
Speed = 1
AVT::LastChange
TransportState = PLAYING
TransportPlaySpeed = 1
Configure
Configure decoder speed
Configure no pacing
Configure no clock synch
HTTP:GET
TimeSeekRange.dlna.org: npt=<client-internal-start-time>
HTTP:GET response
Repeat
HTTP/1.1 200 OK
Data
TimeSeekRange.dlna.org: ntp=<time>
Content-Type: <mime-type-of-media>
HTTP:GET response 0-sized chunk
AVT::LastChange
AVT::GetPositionInfo
Figure 5-6: Stopped to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 158 of 262 28 May 2014

RVU Specification
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.
 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
Speed = <speed> (-1 <= speed < 0 || 0 < speed < 1)
2 The client issues an AVTransport::LastChange event with values:
TransportPlaySpeed: <speed>
3 The client configures its decoder with the decoding rate specified by the Speed parameter.
4 The client issues an HTTP GET to the server with the following headers:
TimeSeekRange.dlna.org: npt=<client-internal-start-time >
5 The server responds to the GET request by issuing a response containing the following response
headers:
TimeSeekRange.dlna.org: npt=<actual-range-start> - <actual-range-end>
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:
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

RVU Specification
Sequence Diagram
Client Server
AVT::Play
Speed = <speed> ( -1 <= speed < 0 || 0 < speed < 1 )
AVT::LastChange
TransportPlaySpeed = <speed> ( -1 <= speed < 0 ||
0 < speed < 1 )
Configure
Configure no pacing
HTTP:GET
HTTP:GET response
Repeat
HTTP/1.1 200 OK
Data
TimeSeekRange.dlna.org: ntp=<time>
HTTP:GET response 0-sized chunk
AVT::LastChange
Figure 5-7: Stopped to Playing Slow Sequence
V1.0 Rev 1.5.1 160 of 262 28 May 2014

RVU Specification
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.
 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:
Speed = <speed> ( -1 > speed OR 1 < speed )
TransportPlaySpeed = <speed>
3 The client configures its decoder to play at N frames per seconds.
V1.0 Rev 1.5.1 161 of 262 28 May 2014

RVU Specification
No. Description
4 The client loops over the following sequence:
1. The client issues an HTTP GET with the following headers:
frameCount.rvualliance.org: <requested-frame-count>
TimeSeekRange.dlna.org: npt=<internal-start-time> - <trick-play-end-range>
2. The server issues an HTTP GET response with the following response headers:
frameCount.rvualliance.org: <available-frame-Count>
frameMap.rvualliance.org: <frame-map>
TimeSeekRange.dlna.org: npt=<internal-start-time> - <seek-range-end>
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 <trick-play-end-range> is at or past the end of media, the server will include in the
HTTP GET response, a response header as follows:
eom-indicator.rvualliance.org: 1
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:
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

RVU Specification
Sequence Diagram
Client Server
AVT::Play
AVT:LastChange
TransportPlaySpeed = <speed> ( -1>speed OR 1<speed )
Configure
Configure decoders
Configure no pacing
HTTP:GET
frameCount.rvu.org: <frame-count-requested>
TimeSeekRange.dlna.org: npt=<time-range-requested>
Repeat
HTTP:GET response
Data HTTP/1.1 200 OK

frameCount.rvu.org: <frame-count-delivered>
frameMap.rvu.org: <frame-map-delivered>
Content-Length: <byte-length>
HTTP:GET response
eom-indicator.rvualliance.org: 1
AVT::LastChange
Figure 5-8: Stopped to Playing Fast Sequence
V1.0 Rev 1.5.1 163 of 262 28 May 2014

RVU Specification
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.
 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:
Unit = ABS_TIME
Target = <absolute-time-target>
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

RVU Specification
Sequence Diagram
Client Server
AVT:Seek
Unit = ABS_TIME
Target = <npt absolute-time-target>
Update saved
position
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:
Speed = 1
2 The client configures its decoder to play at a play speed of 1.
3 The client reads data from the HTTP connection and feeds it to the local decoder.
Note: The client must re-initiate clock synchronization in some instances. The transition from
slow to normal playback, the client delays clock synchronization for N seconds. After N seconds
the client resynchronizes its local decoder clock to the stream clock.
4 For END_OF_MEDIA sequence, see Table 5-7.
Table 5-11: Playing Slow to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 165 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT::Play
Speed = 1
AVT:LastChange
Configure
Configure decoders
Configure pacing
Repeat
HTTP: Paced Data

Data
Figure 5-10: Playing Slow to Normal-Speed Playing Sequence
5.2.1.8 PLAYING_SLOW to PLAYING_FAST (Play [Fast])

Synopsis
to the PLAYING_FAST substate (PLAYING state) for the purpose of fast forward or fast reverse
scanning.

 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
V1.0 Rev 1.5.1 166 of 262 28 May 2014
RVU Specification
No. Description
1. The client issues an HTTP GET with the following headers
TimeSeekRange.dlna.org: npt=<internal-start-time> - <end-seek-range>
2. The server issues an HTTP GET response for the requested content with the following
headers:

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

RVU Specification
Sequence Diagram
Client Server
AVT::Play
AVT::LastChange
TransportPlaySpeed = <speed> ( -1>speed OR 1<speed )
Configure
Configure decoders
Configure no pacing
HTTP:GET
frameCount.rvualliance.org: <frame-count-requested>
TimeSeekRange.dlna.org: npt=< time-range-requested>
Repeat
HTTP:GET response

frameCount.rvualliance.org: <frame-count-delivered>
frameMap.rvualliance.org: <frame-map-delivered>
Figure 5-11: Playing Slow to Playing Fast Sequence
5.2.1.9 PLAYING_SLOW to PAUSED_PLAYBACK (Pause)

 Action: Pause
Synopsis
to the PAUSED_PLAYBACK state for the purpose of pausing.

 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
RVU Specification
No. Description
1 The server control point invokes the client’s AVTransport::Pause action with the following
arguments:
2 The client pauses its local video decoder and stops reading the HTTP response stream. The
client shall keep the HTTP connection alive (e.g. Pause-Release via HTTP connection stalling).
3 The server detects that its TCP buffer has filled on the HTTP response socket and blocks until
there is space available or the HTTP connection is terminated.
TransportState: PAUSED_PLAYBACK
Table 5-13: Playing Slow to Paused Sequence
Sequence Diagram
Client Server
AVT::Pause
Configure
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])

 Action: Seek
V1.0 Rev 1.5.1 169 of 262 28 May 2014

RVU Specification
Synopsis
to the PLAYING_SLOW substate (PLAYING state) for the purpose of jumping to new positions
while in slow motion.

 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
arguments:
Unit = ABS_TIME
2 The client pauses its decoder, flushes its internal buffers and updates its internal start time value
to the time represented by Target.
3 The client issues an HTTP GET to the currently set URI with the following request headers:
TimeSeekRange.dlna.org: npt=<absolute-time-target>
4 The server issues an HTTP response with the following headers
HTTP Status Code 200 OK
TimeSeekRange.dlna.org: npt=<available-play-range>
5 The client reads the HTTP response stream, decodes and displays the media presented in the
transport stream. The decoder rate is set to the same rate as previously configured prior to the
Seek request.
Table 5-14: Playing Slow to Playing Slow (Seek) Sequence
V1.0 Rev 1.5.1 170 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT:Seek
Unit = ABS_TIME
Flush TCP
Pause/Flush
decoders
HTTP:GET
HTTP:GET response
HTTP/1.1 200 OK
Configure transferMode.dlna.org: Streaming
Configure decoders TimeSeekRange.dlna.org: npt=<time>
Configure no pacing Transfer-Coding: chunked
Configure no clock synch Content-Type: <mime-type-of-media>
HTTP:GET response chunk

Repeat
Data
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

RVU Specification
 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.
No. Description
1 The server control point invokes the client’s AVTransport::Play action with the following
arguments:
Speed = 1
3 The client stops fast forward / rewind playback. This operation depends on the mechanism used
for Fast Forward / Rewind.
 If the client implements fast forward / rewind by repeated time based seeking, the client
stops its internal seek / play loop. The client records the internal start time position of the
last frame it displayed.
 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 sets its internal start time to the last absolute time position of the previously displayed
frame. The client issues an HTTP GET with the following parameters:
TimeSeekRange.dlna.org: npt=<internal-start-time> -
5 The server responds to the HTTP GET request with the following parameters:
TimeSeekRange.dlna.org: npt=<actual-start-time> - <actual-end-time>
6 Client begins pulling data from the HTTP GET. The client sets its local decoding rate to 1 and
plays out the content.
Note: The client must examine the Sender Pacing bit of the DLNA.ORG_FLAGS field to
determine if clock synchronization must be utilized.
Table 5-15: Playing Fast to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 172 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT::Play
Speed = 1
AVT:LastChange
Configure
Configure pacing
Configure clock synch
HTTP:GET
HTTP:GET response
Repeat
HTTP/1.1 200 OK
Data
TimeSeekRange.dlna.org: npt=<time>
Figure 5-14: Playing Fast to Normal-Speed Playing Sequence
5.2.1.12 PLAYING_FAST to PLAYING_SLOW (Play [Slow])

Synopsis
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

RVU Specification
PLAYING.
 Triggering input is an invocation of Play with PlaySpeed between -1 and 1 (ex 0).
No. Description
parameters:
3 The client stops fast forward playback. This operation depends on the mechanism used for Fast
Forward / Rewind.
If the client implements fast forward / rewind by repeated time based seeking, the client stops its
internal seek / play loop. The client records the internal start time position of the last frame it
displayed.
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:
TimeSeekRange.dlna.org: npt=<internal-start-time> -
5 The server responds to the HTTP GET request with the following parameters:
6 The client begins pulling data from the HTTP GET. The client sets its local decoding rate to
<speed> and plays out the content.
Table 5-16: Playing Fast to Playing Slow Sequence
V1.0 Rev 1.5.1 174 of 262 28 May 2014

RVU Specification
Client Server
AVT::Play
AVT::LastChange
Configure
Configure no pacing
HTTP:GET
HTTP:GET response
Repeat
HTTP/1.1 200 OK
Data transferMode.dlna.org: Streaming
Figure 5-15: Playing Fast to Playing Slow Sequence
5.2.1.13 PLAYING_FAST to PAUSED_PLAYBACK (Pause)

 Action: Pause
Synopsis
the PAUSED_PLAYBACK state for the purpose of pausing from fast forward or fast rewind.
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
RVU Specification
No. Description
1 The server control point invokes the client’s AVTransport Pause action with the following
arguments:
2 The client pauses its local video decoder and drains any outstanding data on the HTTP
connection. The client updates its internal start time to the absolute time position of the last frame
displayed from the multi-frame scan operation.
Table 5-17: Playing Fast to Paused Sequence
Sequence Diagram
Client Server
AVT::Pause
Configure
Pause decoders
Flush TCP
AVT::LastChange
Figure 5-16: Playing Fast to Paused Sequence
5.2.1.14 PLAYING_FAST to PLAYING_FAST (Seek [Absolute Time])

 Action: Seek [Absolute Time]
V1.0 Rev 1.5.1 176 of 262 28 May 2014

RVU Specification
Synopsis
the PLAYING_FAST substate (PLAYING state) for the purpose of playing changing fast forward
or fast reverse playback speeds.
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:
Unit = ABS_TIME
Target = <absolute-position>
2 The client finishes playing out any frames left over from the last multi-scan request. The client
sets its internal start time to the value specified by the absolute position.
3 The client restarts looping over multi-scan requests at the same speed it was issuing requests at
prior to the Seek operation.
Table 5-18: Playing Fast to Playing Fast (Seek) Sequence
V1.0 Rev 1.5.1 177 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT:Seek
Unit = ABS_TIME
Target = <absolute-seek-time>
HTTP:GET
Repeat
HTTP:GET response
HTTP/1.1 200 OK
Data
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)
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

No. Description
arguments:
V1.0 Rev 1.5.1 178 of 262 28 May 2014

RVU Specification
No. Description
2 Client issues an AVTransport::LastChange event with a value with the following parameters:
TransportPlaySpeed: <speed>
3 The client sets its local decoding rate to the value specified by speed.
4 The client reads content from the stream and feeds it to the decoder.
Table 5-19: Normal-Speed Playing to Play Slow Sequence
Sequence Diagram
Client Server
AVT::Play
AVT:LastChange
Configure
Configure no pacing
HTTP Stream
Repeat
Data
Figure 5-18: Normal-Speed Playing to Playing Slow Sequence
5.2.1.16 PLAYING_NORMAL to PLAYING_FAST (Play [Fast])

V1.0 Rev 1.5.1 179 of 262 28 May 2014

RVU Specification
Synopsis
state) to the PLAYING_FAST substate (PLAYING state) for the purpose of playing in fast
forward or fast reverse.

 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
headers:

Table 5-20: Normal-Speed Playing to Playing Fast Sequence
V1.0 Rev 1.5.1 180 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT::Play
AVT::LastChange
TransportPlaySpeed = <speed> ( -1 > speed OR 1 < speed
)
Configure
Configure decoders
Configure no pacing
HTTP:GET
Repeat
HTTP:GET response

Figure 5-19: Normal-Speed Playing to Playing Fast Sequence
5.2.1.17 PLAYING_NORMAL to PAUSED_PLAYBACK (Pause)

 Action: Pause
Synopsis
state) to the PAUSED_PLAYBACK state for the purpose of pausing.

 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
RVU Specification
No. Description
1 The server control point invokes the client’s AVTransport::Pause action with the following
arguments:
2 The client pauses its local video decoder and stops reading the HTTP response stream. The
client shall keep the HTTP connection alive (e.g. Pause-Release via HTTP connection stalling).
3 The server detects that its TCP buffer has filled on the HTTP response socket and blocks until
there is space available or the HTTP connection is terminated.
4 Client issues an AVTransport::LastChange event with the following parameters:
Table 5-21: Normal-Speed Playing to Paused Sequence
Sequence Diagram
Client Server
AVT::Pause
Configure
Pause decoders
Stall TCP
AVT::LastChange
Figure 5-20: Normal-Speed Playing to Paused Sequence
5.2.1.18 PLAYING_NORMAL to PLAYING_NORMAL (Seek [Absolute Time])

 Action: Seek
V1.0 Rev 1.5.1 182 of 262 28 May 2014

RVU Specification
Synopsis
state) to the PLAYING_NORMAL substate (PLAYING state) for the purpose of jumping to a new
position in the media.

 Triggering input is an invocation of Seek with an absolute time position specified.
No. Description
parameters:
Unit = ABS_TIME
2 The client pauses, flushes its internal decoder and updates its internal start time to the time
represented by Target.
3 The client issues an HTTP GET request with the following request headers:
TimeSeekRange.dlna.org: npt=<absolute-time-target> -
4 The server issues an HTTP response to the GET request with the following response headers
5 The client reads the HTTP response stream and decodes and displays the media presented in
the transport stream.
Table 5-22: Normal-Speed playing to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 183 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT:Seek
Unit = ABS_TIME
Flush TCP
Pause/Flush
decoders
HTTP:GET
TimeSeekRange.dlna.org: npt=<absolute-time-range>
HTTP:GET response
Configure HTTP/1.1 200 OK

Configure decoders
Configure pacing

Repeat
Data
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

RVU Specification
 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:
2 The client stops playing the media as follows:
The client displays a black screen.
The client terminates the outstanding HTTP connection.
The client sets the internal current media start time to 0.
Table 5-23: Playing to Stopped Sequence
Sequence Diagram
Client Server
AVT::Stop
Close HTTP
Flush decoders
AVT::LastChange
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
RVU Specification
 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
parameters:
Unit = ABS_TIME
3 The client flushes its local decoder and issues an HTTP GET request to the current URI with the
following parameters:
TimeSeekRange.dlna.org: npt=<absolute-time-target>
4 The server issues an HTTP response with the following response headers:
5 The client reads the HTTP response stream, decodes and displays the first decodable frame
presented in the stream. The client then pauses its decoder and pauses the stream via HTTP
connection stalling.
Table 5-24: Paused to Paused (Absolute Time Seek) Sequence
V1.0 Rev 1.5.1 186 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT::Seek
Unit = ABS_TIME
AVT::LastChange
Flush TCP
Flush decoders
HTTP:GET
HTTP:GET response
HTTP/1.1 200 OK
Configure transferMode.dlna.org: Streaming
Configure decoders TimeSeekRange.dlna.org: npt=<time>
Configure pacing Transfer-Coding: chunked
Configure clock synch Content-Type: <mime-type-of-media>
Play ONE frame
Stall TCP
AVT::LastChange
Figure 5-23: Paused to Paused (Absolute Time Seek) Sequence
V1.0 Rev 1.5.1 187 of 262 28 May 2014

RVU Specification
5.2.1.21 PAUSED_PLAYBACK to PAUSED_PLAYBACK (Seek [Frame Forward])

 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:
Unit = FRAME
Target = STEP_FORWARD
3 If the starting state was PAUSED_PLAYBACKfrom fast forward or reverse, follow the sequence
below (see Figure 5-25); otherwise, omit this step and continue with step 4:
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:
TimeSeekRange.dlna.org: npt=<internal-start-time>
b. The server responds to the HTTP GET request with the following parameters:
4 The client reads a frame from the HTTP response stream, decodes the frame, and displays it.
The client continues to pause the stream using HTTP connection stalling (see Figure 5-24).
Note: If the client maintains some type of intermediary buffer between the HTTP/TCP buffer and
the video decoders, it may source frames in order from that buffer instead of the HTTP/TCP
frame and refill that buffer when no more frames are available. This implementation is preferred
as it will result in fewer Block-Resume-Block sequences between the client and servers TCP
buffers.
Table 5-25: Paused to Paused (Relative Seek) Sequence
V1.0 Rev 1.5.1 188 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT::Seek
Unit = FRAME
AVT::LastChange
Play ONE frame
Stall TCP
AVT:LastChanged
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

RVU Specification
Client Server
AVT::Seek
Unit = FRAME
AVT::LastChange
HTTP:GET
Play ONE frame

HTTP/1.1 200 OK
TransferCoding: chuncked
Stall TCP Content-Type: <mime-type-of-media>
AVT::LastChange
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])

 Action: Play
Synopsis
PLAYING_NORMAL substate (PLAYING state) for the purpose of resuming playback from
pause.

V1.0 Rev 1.5.1 190 of 262 28 May 2014
RVU Specification
 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
arguments:
Speed = 1
3 The client configures its decoder to play at normal playback rate (1X).
4 The client resumes reading the stalled HTTP response stream and plays the stream at the
specified speed.
Note: If the content indicates sender pacing the client must reinitiate clock synchronization. See
section 5.4 for a discussion on reinitializing clock synchronization from the pause state.
Table 5-26: Paused to Normal-Speed Playing Sequence
V1.0 Rev 1.5.1 191 of 262 28 May 2014

RVU Specification
Sequence Diagram
Client Server
AVT::Play
Speed = 1
AVT::LastChange
Configure

Configure pacing

Repeat
Data
Figure 5-26: Paused to Normal-Speed Playing Sequence
5.2.1.23 PAUSED_PLAYBACK to PLAYING_SLOW (Play [Slow])

Synopsis
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

V1.0 Rev 1.5.1 192 of 262 28 May 2014
RVU Specification
No. Description
arguments:
Speed = speed (-1 <= speed < 0 || 0 < speed < 1)
TransportPlaySpeed: speed
3 The client configures its decoder rate to the speed specified by the speed parameter.
4 The client resumes reading the stalled HTTP response stream and begins playing the stream.
Table 5-27: Paused to Playing Slow Sequence
Sequence Diagram
Client Server
AVT::Play
Speed = speed (-1 <= speed < 0 || 0 < speed < 1)
AVT::LastChanged
TransportPlaySpeed = speed (-1 <= speed < 0 ||
0 < speed < 1)
Configure

Configure no pacing

Repeat
Data
Figure 5-27: Paused to Playing Slow Sequence
V1.0 Rev 1.5.1 193 of 262 28 May 2014

RVU Specification
5.2.1.24 PAUSED_PLAYBACK to PLAYING_FAST (Play [Fast])

Synopsis
PLAYING_FAST substate (PLAYING state) for the purpose of playing in fast forward or fast
reverse.
 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
PlaySpeed = <speed> ( -1 > speed OR 1 < speed )
TimeSeekRange.dlna.org: npt=<internal-start-time> - <seek-end>
headers:
TimeSeekRange.dlna.org: npt=<response-range-start> <response-range-end>
Content-Length: <content-length>

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.

Table 5-28: Paused to Playing Fast Sequence
V1.0 Rev 1.5.1 194 of 262 28 May 2014
RVU Specification
Sequence Diagram
Client Server
AVT::Play
AVT::LastChange
Configure
Configure decoders
Configure no pacing
HTTP:GET
frameCount.rvu.org: <frame-count-requested>
Repeat
HTTP:GET response

frameCount.rvu.org: <frame-count-delivered>
frameMap.rvu.org: <frame-map-delivered>
Figure 5-28: Paused to Playing Fast Sequence
5.2.1.25 PAUSED_PLAYBACK to STOPPED (Stop)

 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
RVU Specification

 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:
2 The client stops playing the media as follows:
The client displays a black screen.
The client terminates the outstanding HTTP connection.
The client sets the internal current media start time to 0.
Table 5-29: Paused to Stopped Sequence
Sequence Diagram
Client Server
AVT::Stop
Close HTTP
Flush decoders
AVT::LastChange
Figure 5-29: Paused to Stopped Sequence
5.2.1.26 STOPPED to NO_MEDIA_PRESENT (SetAVTransportURI)

 State: STOPPED
V1.0 Rev 1.5.1 196 of 262 28 May 2014

RVU Specification
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:
CurrentURI = <null string>
CurrentURIMetaData = <null string>
2 The client sets its internal URI pointer to the null string.
TransportState: NO_MEDIA_PRESENT
AVTransportURI: <null string>
AVTransportURIMetaData: <null string>
Table 5-30: Stopped to No Media Present Sequence
Sequence Diagram
Client Server
AVT::SetTransportURI
CurrentURI = <null>
CurrentURIMetaData = <null>
AVT::LastChange
AVTransportURI = <null>
AVTransportURIMetaData = <null>
TransportState = NO_MEDIA_PRESENT
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

RVU Specification
[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
RVU Specification
[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

RVU Specification
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
Rate Limiting
Client
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
Rate Limiting
Client
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

RVU Specification
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

RVU Specification
[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],
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],
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
RVU Specification
 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

RVU Specification
[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=<host>; DTCP1PORT=<port>;

CONTENTFORMAT=<mimetype> (see section V1SE.10 of [Ref20])
For example, the third field for DTCP-protected MPEG_TS_HD_NA_MPEG1_L2_ISO is:

application/x-dtcp1; DTCP1HOST=<host>; DTCP1PORT=<port>;
CONTENTFORMAT=video/mpeg
[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:
<media_mime_type>
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

RVU Specification

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

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

MPEG TS, h.265 main 10 HEVC_TS_M10P_MT_EA video/mpeg
profile video, EAC3 or AC3
audio, No TTS
C3_ISO
MPEG TS, h.265 main10 HEVC_TS_M10P_MT_EA video/vnd.dlna.mpeg-tts

profile video, EAC3 or AC3
audio, TTS
C3_T
MPEG TS, h.265 main (8 bit) HEVC_TS_MP_MT_EAC3 video/mpeg

video, EAC3 or AC3 audio, No
TTS
_ISO
V1.0 Rev 1.5.1 205 of 262 28 May 2014

RVU Specification

MPEG TS, h.265 main (8bit) HEVC_TS_MP_MT_EAC3 video/vnd.dlna.mpeg-tts
video, EAC3 or AC3 audio,
TTS
_T
Table 5-33: HEVC Format Profile MIME Types

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=<integer>;RVUALLIANCE.ORG_VPID=<integer
>
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=<integer>;RVUALLIANCE.ORG_VPID=<i
nteger>
V1.0 Rev 1.5.1 206 of 262 28 May 2014

RVU Specification
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=<integer>;RVUALLIANCE.ORG_VPID=<integer>
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=<integer>;RVUALLIANCE.ORG_VPID=
<integer>
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=<integer>;RVUALLIANCE.ORG_VPID=<inte
ger>
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=<integer>;RVUALLIANCE.ORG_VPID=<integ
er>
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=<integer>;RVUALLIANCE.ORG_VPID=
<integer>
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
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=<integer>;RVUALLIANCE.ORG_VPID=<i
nteger>
V1.0 Rev 1.5.1 207 of 262 28 May 2014

RVU Specification
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=<integer>;RVUALLIANCE.ORG_VPID=<intege
r>
Recording Video Program (MPEG TS, h.264 video, AC3 audio, TTS)

DLNA.ORG_PN=AVC_TS_HP_HD_AC3_T;DLNA.ORG_FLAGS=C531000000000000000000000000000
Recording Video Program (MPEG TS, h.262 video, MPEG1 - L2 audio, TTS)

DLNA.ORG_PN=MPEG_TS_HD_NA_MPEG1_L2_T;DLNA.ORG_FLAGS=C531000000000000000000000
Recording Video Program (MPEG TS, h.262 video, AC3 audio, TTS

DLNA.ORG_PN=MPEG_TS_HD_NA_T;DLNA.ORG_FLAGS=C5310000000000000000000000000000;R
VUALLIANCE.ORG_APID=<integer>;RVUALLIANCE.ORG_VPID=<integer>
Recording Video Program (ITU-R BO.1516 Sys B TS, SD, MPEG1 - L2 audio, TTS)

DLNA.ORG_PN=MPEG_DIRECTV_SD_MPEG1_L2_T;DLNA.ORG_FLAGS=C5310000000000000000000
Recording Video Program (ITU-R BO.1516 Sys B TS, SD, AC3 audio, TTS)

DLNA.ORG_PN=MPEG_DIRECTV_SD_AC3_T;DLNA.ORG_FLAGS=C531000000000000000000000000
Pause Live Video Program (MPEG TS, h.264 video, AC3 audio, TTS)

DLNA.ORG_PN=AVC_TS_HP_HD_AC3_T;DLNA.ORG_FLAGS=CD31000000000000000000000000000
Pause Live Video Program (MPEG TS, h.262 video, MPEG1 - L2 audio, TTS)

DLNA.ORG_PN=MPEG_TS_HD_NA_MPEG1_L2_T;DLNA.ORG_FLAGS=CD31000000000000000000000
V1.0 Rev 1.5.1 208 of 262 28 May 2014

RVU Specification
Pause Live Video Program (MPEG TS, h.262 video, AC3 audio, TTS

DLNA.ORG_PN=MPEG_TS_HD_NA_T;DLNA.ORG_FLAGS=CD310000000000000000000000000000;R
VUALLIANCE.ORG_APID=<integer>;RVUALLIANCE.ORG_VPID=<integer>
Pause Live Video Program (ITU-R BO.1516 Sys B TS, SD, MPEG1 - L2 audio, TTS)

DLNA.ORG_PN=MPEG_DIRECTV_SD_MPEG1_L2_T;DLNA.ORG_FLAGS=CD310000000000000000000
Pause Live Video Program (ITU-R BO.1516 Sys B TS, SD, AC3 audio, TTS)

DLNA.ORG_PN=MPEG_DIRECTV_SD_AC3_T;DLNA.ORG_FLAGS=CD31000000000000000000000000
V1.0 Rev 1.5.1 209 of 262 28 May 2014

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.<UI Element>,
keyVal)
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
RVU Specification
[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

RVU Specification
[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
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
V1.0 Rev 1.5.1 212 of 262 28 May 2014

RVU Specification
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

RVU Specification
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

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

RVU Specification
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

RVU Specification
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

RVU Specification
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

RVU Specification
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

RVU Specification
[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

RVU Specification
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<node_cnt; i++)
{
mac 48 bslbf standard MAC address of node (6
bytes)
}
list_cnt 8 uimsbf always = node_cnt*(node_cnt-1)
for (i=0; i<list_cnt; i++)
{
src_mac 8 uimsbf index into mac table
dst_mac 8 uimsbf index into mac table
phy_rate 16 uimsbf rate in kbps
}
}
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

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

RVU Specification
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

RVU Specification
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:

and verification Boot software
Yes UpgradeRequired = No
successful? image
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

RVU Specification
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

RVU Specification
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
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
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

RVU Specification
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
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

RVU Specification
[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

RVU Specification
[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
RVU Specification
[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

RVU Specification
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

RVU Specification
[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

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
RVU Specification
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

RVU Specification
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.
2
Variable Name Evented Moderated Max Event Logical Min Delta per Event
1
Event Rate 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

RVU Specification
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

R
AudioPID OUT X_AudioPID
R
AudioEncoding OUT X_AudioEncoding
R
Return value
Table 9-9: X_GetAudioSelection arguments

V1.0 Rev 1.5.1 236 of 262 28 May 2014
RVU Specification

None.
9.1.3.2.3 Errors

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

VideoPID IN X_VideoPID
VideoEncoding IN X_VideoEncoding
R
Return value
Table 9-11: X_UpdateVideoSelection arguments

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

Table 9-12: X_UpdateVideoSelection error codes
V1.0 Rev 1.5.1 237 of 262 28 May 2014

RVU Specification
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

R
VideoPID OUT X_VideoPID
R
VideoEncoding OUT X_VideoEncoding
R
Return value
Table 9-13: X_GetVideoSelection arguments

None.
9.1.3.4.3 Errors

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

<action>
<name>X_UpdateAudioSelection</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>
A_ARG_TYPE_InstanceID
</relatedStateVariable>
V1.0 Rev 1.5.1 238 of 262 28 May 2014
RVU Specification
</argument>
<argument>
<name>AudioPID</name>
X_AudioPID
</argument>
<argument>
<name>AudioEncoding</name>
X_AudioEncoding
</argument>
</argumentList>
</action>
9.1.4.2 X_GetAudioSelection Action

<action>
<name>X_GetAudioSelection</name>
<argumentList>
<argument>
</argument>
<argument>
<name>AudioPID</name>
<direction>out</direction>
X_AudioPID
</argument>
<argument>
<name>AudioEncoding</name>
<diretion>out</direction>
X_AudioEncoding
</argument>
</argumentList>
</action>
9.1.4.3 X_UpdateVideoSelection Action

<action>
<name>X_UpdateVideoSelection</name>
<argumentList>
<argument>
V1.0 Rev 1.5.1 239 of 262 28 May 2014

RVU Specification
</argument>
<argument>
<name>VideoPID</name>
X_VideoPID
</argument>
<argument>
<name>VideoEncoding</name>
X_VideoEncoding
</argument>
</argumentList>
</action>
9.1.4.4 X_GetVideoSelection Action

<action>
<name>X_GetVideoSelection</name>
<argumentList>
<argument>
</argument>
<argument>
<name>VideoPID</name>
X_VideoPID
</argument>
<argument>
<name>VideoEncoding</name>
<diretion>out</direction>
X_VideoEncoding
</argument>
</argumentList>
</action>
9.1.4.5 ServiceStateTable
<stateVariable sendEvents="no">
<name>X_AudioPID</name>
<dataType>ui2</dataType>
</stateVariable>
<stateVariable sendEvents=”no”>
<name>X_AudioEncoding</name>
<dataType>string</dataType>
V1.0 Rev 1.5.1 240 of 262 28 May 2014

RVU Specification
</stateVariable>
<name>X_VideoPID</name>
</stateVariable>
<stateVariable sendEvents=”no”>
<name>X_VideoEncoding</name>
</stateVariable>
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

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
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
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

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

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
RVU Specification
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.
<?xml version="1.0" ?>

<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:rvualliance-org:device:RVUServer:1</deviceType>
<friendlyName>short user-friendly title</friendlyName>
<manufacturer>manufacturer</manufacturer>
<manufacturerURL>manufacturer's URL</manufacturerURL>
V1.0 Rev 1.5.1 245 of 262 28 May 2014
RVU Specification
<modelDescription>long user-friendly title</modelDescription>

<modelName>model name</modelName>
<modelNumber>model number</modelNumber>
<serialNumber>manufacturer's serial number</serialNumber>
<UDN>uuid:UUID</UDN>
<serviceList>
<service>
<serviceType>urn:schemas-rvualliance-
org:service:ClientImageManager:1</serviceType>
<serviceId>urn:rvualliance-
org:serviceId:ClientImageManager</serviceId>
<controlURL>control URL</controlURL>
<eventSubURL>event URL</eventSubURL>
<SCPDURL>SCPD URL</SCPDURL> </service>
</serviceList>
<deviceList>
<device>
<deviceType>urn:schemas-upnp-
org:device:RemoteUIServerDevice:1</deviceType>
<friendlyName>user-friendly title</friendlyName>
<manufacturer>manufacturer</manufacturer>
<manufacturerURL>manufacturer's URL</manufacturerURL>
<modelDescription>long user-friendly title</modelDescription>
<modelName>model name</modelName>
<modelNumber>model number</modelNumber>
<serialNumber>manufacturer's serial number</serialNumber>
<UDN>uuid:UUID</UDN>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-
org:service:RemoteUIServer:1</serviceType>
<serviceId>urn:upnp-org:serviceId:RemoteUIServer</serviceId>
<controlURL>control URL</controlURL>
<eventSubURL>event URL</eventSubURL>
<SCPDURL>SCPD URL</SCPDURL>
</service>
</serviceList>
</device>
</deviceList>
</device>
</root>
V1.0 Rev 1.5.1 246 of 262 28 May 2014

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
1
Opt. 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
RVU Specification
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.
2
Variable Name Evented Moderated Max Event Logical Min Delta per Event
1
Event Rate 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

RVU Specification
1
Name Req. or Opt.
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
R
TftpFilepath OUT Required A_ARG_TYPE_String
R
UpgradeRequired OUT Required A_ARG_TYPE_Bool
R
Availability OUT Required A_ARG_TYPE_Int
R
Urgent OUT 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

RVU Specification
 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.

None.
12.2.4.1.3 Errors

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

RVU Specification
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

RVU Specification
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

<?xml version="1.0"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<actionList>
<action>
<name>CheckImage</name>
<argumentList>
<argument>
<name>Make</name>
<relatedStateVariable>A_ARG_TYPE_String</relatedStateVariable>
</argument>
<argument>
<name>Model</name>
</argument>
<argument>
<name>HardwareRevision</name>
</argument>
<argument>
<name>MajorSoftwareVersion</name>
<relatedStateVariable>A_ARG_TYPE_Int</relatedStateVariable>
</argument>
<argument>
<name>MinorSoftwareVersion</name>
</argument>
<argument>
<name>DownloadLocation</name>
</argument>
<argument>
<name>TftpFilepath</name>
</argument>
<argument>
V1.0 Rev 1.5.1 252 of 262 28 May 2014
RVU Specification
<name>UpgradeRequired</name>
<relatedStateVariable>A_ARG_TYPE_Bool</relatedStateVariable>
</argument>
<argument>
<name>Availability</name>
</argument>
<argument>
<name>Urgent</name>
<relatedStateVariable>A_ARG_TYPE_Bool</relatedStateVariable>
</argument>
<argument>
<name>AvailableMajorSoftwareVersion</name>
</argument>
<argument>
<name>AvailableMinorSoftwareVersion</name>
</argument>
</argumentList>
</action>
</actionList>
<serviceStateTable>
<stateVariable sendEvents="yes">
<name>NewImageID</name>
<defaultValue>0</defaultValue>
</stateVariable>
<name>A_ARG_TYPE_Int</name>
<defaultValue>0</defaultValue>
</stateVariable>
<name>A_ARG_TYPE_String</name>
<defaultValue/>
</stateVariable>
<name>A_ARG_TYPE_Bool</name>
<dataType>boolean</dataType>
<defaultValue>false</defaultValue>
</stateVariable>
</serviceStateTable>
</scpd>
V1.0 Rev 1.5.1 253 of 262 28 May 2014

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<N; i++ ){

user_data_type_code 8 bslbf
user_data_code_length 8 bslbf
if(user_data_type_code == ‘0x03’)
cc_data()
else if(user_data_type_code == ‘0x06’)
bar_data()
}
Table 13-2: AVC Caption Transport Syntax following provider_code = 0x[002F]
V1.0 Rev 1.5.1 254 of 262 28 May 2014

RVU Specification
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
V1.0 Rev 1.5.1 255 of 262 28 May 2014

RVU Specification
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

RVU Specification
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:
V1.0 Rev 1.5.1 257 of 262 28 May 2014

RVU Specification
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
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
RVU Specification
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
RVU Specification
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

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
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


RVU - Protocol - Specification - V1 - 0 - Rev1 - 51 FINAL May 2014

Uploaded by

Copyright:

Available Formats

You might also like

RVU - Protocol - Specification - V1 - 0 - Rev1 - 51 FINAL May 2014

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RVU - Protocol - Specification - V1 - 0 - Rev1 - 51 FINAL May 2014

Uploaded by

Copyright:

Available Formats

V1.0 Rev 1.5.1

Intellectual Property Notice

Copyright 2014 © RVU Alliance.

V1.0 Rev 1.5.1 2 of 262

Revision Description Date

V1.0 Rev 1.5.1 3 of 262 28 May 2014

Revision Description Date

V1.0 Rev 1.5.1 4 of 262 28 May 2014

Revision Description Date

V1.0 Rev 1.5.1 5 of 262 28 May 2014

Revision Description Date

V1.0 Rev 1.5.1 6 of 262 28 May 2014

4.8.2 Command Details .................................................................................................................. 55

V1.0 Rev 1.5.1 8 of 262 28 May 2014

7.4 Diagnostics ................................................................................................................................... 219

13.2.3 MPEG_DIRECTV_SD AV Format, Audio Portion Profile: MPEG1_L2 ............................... 257

V1.0 Rev 1.5.1 10 of 262 28 May 2014

V1.0 Rev 1.5.1 11 of 262

V1.0 Rev 1.5.1 12 of 262 28 May 2014

V1.0 Rev 1.5.1 13 of 262

Table 4-38: Read command attributes ........................................................................................................ 67

V1.0 Rev 1.5.1 14 of 262 28 May 2014

Table 4-77: GetGraphicsCaps command attributes ................................................................................... 84

V1.0 Rev 1.5.1 15 of 262 28 May 2014

Table 4-116: ReconfigureDisplayBuffer response error codes ................................................................. 101

V1.0 Rev 1.5.1 16 of 262 28 May 2014

Table 4-155: ReconfigureDisplayBuffer3DTV response attributes ........................................................... 116

V1.0 Rev 1.5.1 17 of 262 28 May 2014

Table 4-194: Stop response error codes .................................................................................................. 136

V1.0 Rev 1.5.1 18 of 262 28 May 2014

Table 5-30: Stopped to No Media Present Sequence .............................................................................. 197

V1.0 Rev 1.5.1 19 of 262 28 May 2014

Addressing Quality of Service (QoS)

Remote User Interface (RUI)

Figure 1-1: RVU Sub-Protocol Sequence

V1.0 Rev 1.5.1 20 of 262 28 May 2014

1.1 Document Organization

This document uses the following conventions for requirements:

 M = Mandatory, S = Suggested, O = Optional

[1.1-1] M: RVU-C; S: RVU-S

In some cases, the requirement is shown as an entry in a table for clarity.

1.1.1 Addressing, Discovery, and Description

V1.0 Rev 1.5.1 21 of 262 28 May 2014

1.1.2 Session Management

1.1.3 Remote User Interface

1.1.4 Media Transfer

Details on this sub-protocol are found in section 5.

1.1.5 QoS and Diagnostics

See section 7 for more information on QoS and diagnostics.

V1.0 Rev 1.5.1 22 of 262 28 May 2014

1.1.6 Client Image Acquisition

1.1.7 UPnP Templates

1.1.8 Client/server setup summary

1. The client discovers server, by receiving an ssdp:alive message, or by sending an SSDP

7. The server invokes ConnectionManager::PrepareForConnection, see 9.2.

displayed on the client (PIG or full-screen), see 4.8.2.5.1 and 4.8.4.2.

9. The server invokes AVTransport::SetAVTransportURI. The metadata for the URI