CONTENT PROVISIONING FOR WIRELESS BACK CHANNEL

This application claims priority to U.S. Provisional Application No. 61/439,809 entitled “WI-FI DISPLAY REVERSE CHANNEL SETUP AND INPUT DATA ENCAPSULATION,” filed Feb. 4, 2011, and U.S. Provisional Application No. 61/579,059 entitled “CONTENT PROVISIONING FOR WIRELESS BACK CHANNEL,” filed Dec. 22, 2011, the entire contents of which are hereby incorporated by reference in their entirety.

This disclosure relates to techniques for transmitting data between a wireless source device and a wireless sink device.

Wireless display (WD) or Wi-Fi Display (WFD) systems include a source device and one or more sink devices. The source device and each of the sink devices may be either mobile devices or wired devices with wireless communication capabilities. As mobile devices, for example, one or more of the source device and the sink devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PDAs), portable media players, or other flash memory devices with wireless communication capabilities, including so-called “smart” phones and “smart” pads or tablets, or other types of wireless communication devices. As wired devices, for example, one or more of the source device and the sink devices may comprise televisions, desktop computers, monitors, projectors, and the like, that include wireless communication capabilities.

The source device sends media data, such as audio video (AV) data, to one or more of the sink devices participating in a particular media share session. The media data may be played back at both a local display of the source device and at each of the displays of the sink devices. More specifically, each of the participating sink devices renders the received media data on its screen and audio equipment.

The techniques of this disclosure generally relate to communication between a wireless source device and a wireless sink device. For example, certain aspects of this disclosure relate to enabling a wireless source device to render content at a wireless sink device using wireless communication. According to some aspects of the disclosure, the wireless source device may share graphical content for rendering at the wireless sink device using wireless communication techniques. In addition, aspects of this disclosure relate to enabling the wireless sink device to act as a second display for the wireless source device. In addition, aspects of this disclosure relate to enabling the source device to offload an application being executed by the source device, such that the application is then executed by the sink device.

In an example, aspects of this disclosure relate to a method comprising: determining, by a source device, that display data rendered by the source device comprises one or more displayable graphical objects; in response to determining an event, selecting, by the source device, a set of the one or more graphical objects for rendering at a sink device; generating, by the source device, configuration data based at least in part on the set of the one or more graphical objects, wherein the configuration data is usable by the sink device to render representations of graphical objects in the set of one or more graphical objects based at least in part on one or more display parameters associated with the sink device; and sending, by the source device, the configuration data to the sink device.

In another example, aspects of this disclosure relate to a wireless source device comprising: a memory storing instructions; one or more processors configured to execute the instructions, wherein upon execution of the instructions the one or more processors cause: determining that display data rendered by the source device comprises one or more displayable graphical objects; in response to determining an event, selecting a set of the one or more graphical objects for rendering at a sink device; generating configuration data based at least in part on the set of the one or more graphical objects, wherein the configuration data is usable by the sink device to render representations of graphical objects in the set of one or more graphical objects based at least in part on one or more display parameters associated with the sink device; and sending the configuration data to the sink device.

In another example, aspects of this disclosure relate to a computer-readable storage medium storing instructions that upon execution by one or more processors of a wireless source device cause the one or more processors to: determine that display data rendered by the source device comprises one or more displayable graphical objects; in response to determining an event, select a set of the one or more graphical objects for rendering at a sink device; generate configuration data based at least in part on the set of the one or more graphical objects, wherein the configuration data is usable by the sink device to render representations of graphical objects in the set of one or more graphical objects based at least in part on one or more display parameters associated with the sink device; and send the configuration data to the sink device.

In another example, aspects of this disclosure relate to a wireless source device comprising: means for determining that display data rendered by the source device comprises one or more displayable graphical objects; means for selecting, in response to determining an event, a set of the one or more graphical objects for rendering at a sink device; means for generating configuration data based at least in part on the set of the one or more graphical objects, wherein the configuration data is usable by the sink device to render representations of graphical objects in the set of one or more graphical objects based at least in part on one or more display parameters associated with the sink device; and means for sending the configuration data to the sink device.

In another example, aspects of this disclosure relate to a method comprising: receiving, by a sink device, configuration data usable by the sink device to render representations of a set of graphical objects, wherein the set of graphical objects is selected by a source device in response to an event; and rendering, by the sink device, the representations of the set of graphical objects using the configuration data based at least in part on one or more display parameters associated with the sink device.

In another example, aspects of this disclosure relate to a wireless sink device comprising: a memory storing instructions; one or more processors configured to execute the instructions, wherein upon execution of the instructions the one or more processors cause: receiving configuration data usable by the sink device to render representations of a set of graphical objects, wherein the set of graphical objects is selected by a source device in response to an event; and rendering the representations of the set of graphical objects using the configuration data based at least in part on one or more display parameters associated with the sink device.

In another example, aspects of this disclosure relate to a computer-readable storage medium storing instructions that upon execution by one or more processors of a wireless sink device cause the one or more processors to: upon receiving configuration data usable by the sink device to render representations of a set of graphical objects, wherein the set of graphical objects is selected by a source device in response to an event, render the representations of the set of graphical objects using the configuration data based at least in part on one or more display parameters associated with the sink device.

In another example, aspects of this disclosure relate to a wireless sink device comprising: means for receiving configuration data usable by the sink device to render representations of a set of graphical objects, wherein the set of graphical objects is selected by a source device in response to an event; and means for rendering the representations of the set of graphical objects using the configuration data based at least in part on one or more display parameters associated with the sink device.

The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

Wireless display (WD) systems may include a wireless display (WD) source and one or more wireless display sinks In general, a wireless display source (“source device”) may send audio video (AV) data to a wireless display sink (“sink device”), which may render the received AV data at a terminal device. The AV data, in some examples, may include a sequence of frames (or pictures) played in rapid succession, which may also include associated audio frames, although sometimes audio frames are not included.

In some cases, the source device may be prompted to respond to user inputs applied at a sink device. In such an interactive application, the user inputs applied at the sink device may be sent back to the source device. In one example, a reverse channel architecture may be implemented to enable the wireless display system to transmit the user inputs applied at the sink device to the source device. The reverse channel architecture may include upper layer messages for transporting user inputs and lower layer frames for negotiating user interface capabilities at the sink device and the source device.

The wireless display reverse channel may reside above the Internet Protocol (IP) transport layer between a wireless display sink and the wireless display source. To promote reliable transmission and in sequence delivery to user inputs, the wireless display reverse channel may be configured run on top of TCP/IP. In some cases, there may be a mismatch between the user input interfaces at a sink device and a source device. To resolve the problems induced by such a mismatch and to promote a good user experience under such circumstances, user input interface capability negotiations occur between a sink device and a source device.

Aspects of this disclosure relate to enabling a source device to share graphical content for rendering at a sink device. In addition, aspects of this disclosure relate to enabling a sink device to act as a second display for a source device. Aspects of this disclosure also relate to enabling a source device to offload an application being executed by the source device, such that the application is then executed by a sink device.

FIG. 1A is a block diagram illustrating an exemplary source/sink system 100 that may implement techniques of this disclosure. As shown in FIG. 1, system 100 includes source device 120 that communicates with sink device 160 via communication channel 150. Source device 120 may include a memory that stores audio/video (AN) data 121, display 122, speaker 123, audio/video encoder 124 (also referred to as encoder 124), audio/video control module 125, and transmitter/receiver (TX/RX) unit 126. Sink device 160 may include display 162, speaker 163, audio/video decoder 164 (also referred to as decoder 164), transmitter/receiver unit 166, user input (UI) device 167, and user input processing module (UIPM) 168. The illustrated components constitute merely one example, and other examples may include fewer components than those illustrated or additional components.

In the example of FIG. 1, source device 120 can display the video portion of audio/video data 121 on display 122 and can output the audio portion of audio/video data 121 on speaker 122. Audio/video data 121 may be stored locally on source device 120, accessed from an external storage medium such as a file server, Blu-ray disc, or DVD, or may be streamed to source device 120 via a network connection such as the internet. In some instances audio/video data 121 may be captured in real-time via a camera and microphone of source device 120. Audio/video data 121 may include multimedia content such as movies, television shows, or music, but may also include real-time content generated by source device 120. Such real-time content may for example be produced by applications running on source device 120. Such real-time content may also include, in one example, a video frame of user input options available for a user to select. In some instances, audio/video data 121 may include video frames that are a combination of different types of content, such as a video frame of a movie or TV program that has user input options overlaid the frame of video.

In addition to rendering audio/video data 121 locally via display 122 and speaker 123, audio/video encoder 124 of source device 120 can encode audio/video data 121, and transmitter/receiver unit 126 can transmit the encoded data over communication channel 150 to sink device 160. Transmitter/receiver unit 166 of sink device 160 receives the encoded data, and audio/video decoder 164 decodes the encoded data and outputs the decoded data via display 162 and speaker 163. In this manner, the audio and video data being rendered by display 122 and speaker 12 can be simultaneously rendered by display 162 and speaker 163. The audio data and video data may be arranged in frames, and the audio frames may be time-synchronized with the video frames when rendered.

Audio/video encoder 124 and audio/video decoder 164 may implement any number of audio and video compression standards, such as the ITU-T H.264 standard, alternatively referred to as MPEG-4, Part 10, Advanced Video Coding (AVC), or the newly emerging high efficiency video coding (HEVC) standard, sometimes called the H.265 standard. Generally speaking, audio/video decoder 164 is configured to perform the reciprocal coding operations of audio/video encoder 124. Although not shown in FIG. 1, in some aspects, A/V encoder 124 and A/V decoder 164 may each be integrated with an audio encoder and decoder, and may include appropriate MUX-DEMUX units, or other hardware and software, to handle encoding of both audio and video in a common data stream or separate data streams.

Although, FIG. 1 shows communication channel 150 carrying audio payload data and video payload data separately, it is to be understood that in some instances video payload data and audio payload data may be part of a common data stream. If applicable, MUX-DEMUX units may conform to the ITU H.223 multiplexer protocol, or other protocols such as the user datagram protocol (UDP). Audio/video encoder 124 and audio/video decoder 164 each may be implemented as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware or any combinations thereof. Each of audio/video encoder 124 and audio/video decoder 164 may be included in one or more encoders or decoders, either of which may be integrated as part of a combined encoder/decoder (CODEC).

Display 122 and display 162 may comprise any of a variety of video output devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, an organic light emitting diode (OLED) display, or another type of display device. In these or other examples, the display device may be an emissive display or a transmissive display. Speaker 123 may comprise any of a variety of audio output devices such as headphones, a single-speaker system, a multi-speaker system, or a surround sound system. Additionally, although display 122 and speaker 123 are shown as part of source device 120 and display 162 and speaker 163 are shown as part of sink device 160, source device 120 and sink device 160 may in fact be a system of devices. As one example, display 162 may be a television, speaker 163 may be a surround sound system, and decoder 164 may be part of an external box connected, either wired or wirelessly, to display 162 and speaker 163. In other instances, sink device 160 may be a single device, such as a tablet computer or smartphone. In still other cases, source device 160 and sink device 120 are similar devices, e.g., both being smartphones, tablet computers, or the like. In this case, one device may operate as the source and the other may operate as the sink. These rolls may even be reversed in subsequent communication sessions.

Transmitter/receiver unit 126 and transmitter/receiver unit 166 may each include various mixers, filters, amplifiers and other components designed for signal modulation, as well as one or more antennas and other components designed for transmitting and receiving data. Communication channel 150 generally represents any suitable communication medium, or collection of different communication media, for transmitting video data from source device 120 to sink device 160. Communication channel 150 is usually a relatively short-range communication channel, similar to WiFi, Bluetooth, or the like. However, communication channel 150 is not necessarily limited in this respect, and may comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines, or any combination of wireless and wired media. In other examples, communication channel 150 may even form part of a packet-based network, such as a local area network, a wide-area network, or a global network such as the Internet. Source device 120 and sink device 160 may communicate over communication channel using a communications protocol such as a standard from the IEEE 802.11 family of standards.

In addition to decoding and rendering data received from source device 120, sink device 160 can also receive user inputs from user input device 167. User input device 167 may, for example, be a keyboard, mouse, trackball or track pad, touch screen, voice command recognition module, another type of human device interface (HDI) unit or device, or any other such user input device. User input processing module 168, formats user input commands received by user input device 167 into a data packet structure that source device 120 is capable of interpreting. Such data packets are transmitted by transmitter/receiver 166 to source device 120 over communication channel 150. Transmitter/receiver unit 126 receives the data packets, and A/V control module parses the data packets to interpret the user input command that was received by user input device 167. Based on the command received in the data packet, A/V control module 125 can change the content being encoded and transmitted. In this manner, a user of sink device 160 can control the audio payload data and video payload data being transmitted by source device 120 remotely and without directly interacting with source device 120. Examples of the types of commands a user of sink device 160 may transmit to source device 120 include commands for rewinding, fast forwarding, pausing, and playing audio and video data, as well as commands for zooming, rotating, scrolling, and so on. Users may also make selections, from a menu of options for example, and transmit the selection back to source device 120. Commands may be application-specific or platform-specific, or may comprise general commands applicable to multiple platforms or multiple applications.

Source device 120 can respond to user inputs applied at sink device 160. In such an interactive application setting, the user inputs applied at sink device 160 may be sent back to the wireless display source over communication channel 150. In one example, a reverse channel architecture, also referred to as a user interface back channel (UIBC) may be implemented to enable sink device 160 to transmit the user inputs applied at sink device 160 to source device 120. The reverse channel architecture may include upper layer messages for transporting user inputs and lower layer frames for negotiating user interface capabilities at sink device 160 and source device 120. The UIBC may reside over the Internet Protocol (IP) transport layer between sink device 160 and source device 120. To promote reliable transmission and in sequence delivery of data packets containing user input data, UIBC may be configured run on top of other packet-based communication protocols such as the transmission control protocol/internet protocol (TCP/IP) or the user datagram protocol (UDP).

In some cases, there may be a mismatch between the user input interfaces located at source device 120 and sink device 160. To resolve the potential problems created by such a mismatch and to promote a good user experience under such circumstances, user input interface capability negotiation may occur between source device 120 and sink device 160 prior to establishing a communication session.

The UIBC may be designed to transport various types of user input data, including cross-platform user input data. For example, source device 120 may run the iOS® operating system, while sink device 160 runs another operating system such as Android® or Windows®. Regardless of platform, UIPM 168 can encapsulate received user input in a form understandable to A/V control module 125. A number of different types of user input formats may be supported by the UIBC so as to allow many different types of source and sink devices to exploit the protocol. Generic input formats may be defined, and platform specific input formats may both be supported, thus providing flexibility in the manner in which user input can be communicated between source device 120 and sink device 160 by the UIBC.

In the example of FIG. 1, source device 120 may comprise a smartphone, tablet computer, laptop computer, desktop computer, WiFi enabled television, or any other device capable of transmitting audio and video data. Sink device 160 may likewise comprise a smartphone, tablet computer, laptop computer, desktop computer, WiFi enabled television, or any other device capable of receiving audio and video data and receiving user input data. In some instances, sink device 160 may include a system of devices, such that display 162, speaker 163, UI device 167, and A/V encoder 164 all parts of separate but interoperative devices. Source device 120 may likewise be a system of devices rather than a single device. In many cases, source device 120 and sink device 160 may be similar or identical device, with one device operating as the source and the other operating as the sink. Moreover, these roles may be reversed in different communication sessions.

Aspects of this disclosure relate to enabling source device 120 to share graphical content for rendering at sink device 160. In addition, aspects of this disclosure relate to enabling sink device 160 to act as a second display for source device 120. Aspects of this disclosure also relate to enabling source device 120 to offload an application being executed by source device 120, such that the application is then executed by sink device 160.

To share graphical content, source device 120 may initially establish a wireless connection with sink device 160. In some examples, sink device 160 may include a Graphics Processing Unit (GPU) for rendering graphics data. Accordingly, in response to establishing the wireless connection, source device 120 may receive information that describes the GPU of sink device 160 (e.g., such as information describing GPU capabilities). As source device 120 renders graphical content, source device 120, using techniques of this disclosure, may generate configuration data that represents graphical objects included in the graphical content.

In general, configuration data may represent graphical objects included in the graphical content without providing actual pixel-level data (e.g., pixel values of a particular colorspace). Graphical objects may include, for example, objects comprised of one or more geometric primitives that form a shape for display. Configuration data may require fewer bits than pixel-level display data to represent graphical content. In some examples, configuration data may be similar to OpenGL instructions or instructions of another GPU language. The configuration data may also include graphical commands to modify or manipulate graphical objects. Thus, instead of mirroring display data at a pixel-level, graphical objects (e.g., overlays) and/or graphics commands may be extracted and extended over a wireless connection from source device 120 to sink device 160.

According to the techniques of this disclosure, source device 120 may send configuration data to sink device 160 rather than pixel-level display data. Upon receiving the configuration data, sink device 160 (e.g., the GPU of sink device 160) may use the configuration data to render graphical content at sink device 160. In this way, the source/sink system can leverage the rendering capabilities of sink device 160, rather than relaying solely on source device 120 to process and produce all pixel-level data.

In some examples, source device 120 may also generate configuration data that includes commands to modify or manipulate the graphical objects at sink device 160. For instance, if a user provides a user input to source device 120 to increase the size of a graphical object, source device 120, using techniques of the disclosure, may generate configuration data that describes the increase in size of the graphical object. The configuration may be sent to sink device 160, which may use the configuration data to modify and/or manipulate the corresponding graphical object (e.g., increase the size of the graphical object). That is, upon receiving the configuration data from source device 120, the GPU of sink device 160 may use the configuration data to modify graphical content rendered at sink device 160. According to aspects of this disclosure, as noted above, the configuration data describing the modification to the graphical content may require fewer bits than updated pixel-level display data to represent changes to graphical content.

According to some examples, source device 120 may generate configuration data based on the capabilities of sink device 160. That is, for example, source device 120 may generate configuration data that is interpretable by and/or specific to the capabilities and design of the GPU of sink device 160. Thus, source device 120 may share more of the rendering load with sink device 160 having relatively powerful rendering capabilities than sink device 160 having relatively simplistic rendering capabilities.

In some examples, techniques of the present disclosure may enable source device 120 and sink devices 160 to operate in various different modes. For instance, one mode may cause source device 120 to generate and send configuration data to sink device 160, while in a different mode source device 120 may send pixel-level display data. In another mode, source device 120 may send a combination of pixel-level display data for some graphical objects and configuration data for other graphical objects.

In this way, aspects of this disclosure may be implemented to conserve power at source device 120 (e.g., due to a reduced computational load associated with rendering pixel-level data). In addition, aspects of this disclosure may be implemented to use less bandwidth, as the configuration data typically comprises fewer bits than pixel-level data. In some examples, latency associated with rendering and/or modifying graphical content at sink device 160 (from source device 120) may also be reduced.

Moreover, the techniques of the disclosure may provide improved display quality of graphical content shared between source device 120 and sink device 160 in situations in which source device 120 and sink device 160 have different rendering capabilities. That is, in some instances, source device 120 may have a lower display resolution than sink device 160. In an example for purposes of illustration, source device 120 may be a mobile device (e.g., a tablet or smartphone), while sink device 160 may be a larger television (e.g., a liquid crystal display (LCD) or other television). In such an example, if sink device 160 receives pixel-level display data from source device 120, sink device 160 may be required to upscale or otherwise modify the pixel-level graphical content to the native resolution of sink device 160. According to aspects of this disclosure, sink device 160 may instead receive configuration data (e.g., rather than pixel-level data). Thus, sink device 160 may use the configuration data to generate graphical content in the native resolution of sink device 160, thereby providing a higher quality display of the graphical content.

As noted above, aspects of this disclosure also relate to enabling sink device 160 to act as a second display, which may also be referred to as a “secondary display” for source device 120. That is, rather than mirroring all content from source device 120 to sink device 160, aspects of this disclosure relate to sharing some content between source device 120 and sink device 160 such that sink device 160 may display certain graphical objects not displayed at source device 120. In some examples, a user may select one or more graphical objects being rendered at source device 120 to be shared for rendering on sink device 160. In other examples, an application may automatically determine one or more graphical objects being rendered at source device 120 to be shared for rendering on sink device 160.

In some examples, source device 120 may map a display resolution of source device 120 to sink device 160. For example, when source device 120 and sink device 160 initially communicate, the devices may exchange display resolution information. Accordingly, source device 120 may select different sets of graphical objects for rendering at sink device 160 based on the resolution of sink device 160. For instance, if the resolution of sink device 160 is relatively high, source device 120 may send a first set of graphical objects to sink device 160. If, however, the resolution of sink device 160 is relatively low, source device 120 may send a second set of graphical objects to sink device 160 that includes fewer graphical objects than the first set. More generally, using techniques of the disclosure, source device 120 may determine, based on any capability (e.g., resolution) of sink device 160, which graphical elements are sent from source device 120 to sink device 160.

In one example, source device 120 (e.g., a mobile device such as a tablet or smartphone) may render video data associated with a movie using a movie player application being executed by source device 120. The user may provide user input that causes source device 120 to share video data representing the movie on sink device 160 (e.g., a LCD television). The user input may additionally cause graphical controls of the movie player to be rendered at source device 120, without being rendered at sink device 160. In this way, techniques of the present disclosure may enable source device 120 to render a first portion of graphical content on source device 120 and a second portion of the graphical content on sink device 160. To render the second portion of the graphical content at sink device 160, source device 120 may generate configuration data usable by sink device 160 to render the graphical content. By sending the configuration data to sink device 160, the second portion of graphical content may be rendered at sink device 160.

As noted above, aspects of this disclosure also relate to enabling source device 120 to offload an application being executed by source device 120, such that the application is then executed by sink device 160. For example, source device 120 may be initially executing a particular application. The user may then provide a user input to offload execution of the application onto sink device 160. In such examples, source device 120 may request certain information from sink device 160 regarding the capabilities of sink device 160. In response to the request, sink device 160 may send information to source device 120 that indicates capabilities of sink device 160. For instance, capabilities may include the operating system of sink device 160, applications installed on sink device 160, and data indicating the computing performing of sink device 160.

In an example, in response to a request to offload an application to sink device 160, source device 120 may determine that another instance of the application running on source device 120 is also stored on sink device 160. In such examples, source device 120 may send information to sink device 160 that identifies the application. The information may further include data previously used by the application on source device 120 that will be used by the application on sink device 160. Upon receiving the application information, sink device 160 may execute the application on sink device 160. That is, sink device 160 may launch the application at sink device 160. In addition, sink device 160 may use the application information received from source device 120 to transition to the same state as the application being executed by source device 120.

In some examples, one or more processes associated with offloading applications or other processes from source device 120 to sink device 160 may be performed automatically. For example, rather, source device 120 and sink device 160 may exchange information regarding the capabilities of sink device 160 automatically. That is, in an example, sink device 160 may send information regarding the capabilities of sink device 160 automatically upon establishing a connection with source device 120. Additionally or alternatively, rather than waiting for a request from a user to offload an application to sink device 160, source device 120 may automatically may an application offload determination. For example, upon establishing a connection and determining the capabilities of sink device 160, source device 120 may offload certain applications or other processes that source device 120 determines that sink device 160 has the ability to execute.

In some examples, source device 120 may communicate with more than one sink device 160 (e.g., as shown and described, for example, with respect to FIG. 1B). That is, for example, user input may be received by source device 120 from multiple sink devices 160 to modify graphical content rendered by source device 120. Consequently, when events representing the user inputs are transported from multiple sink devices 160 to source device 120, synchronization issues may arise. For instance, display data rendered by source device 120 may be sent to one or more sink devices 160 for rendering. A user may provide a user input from a first sink device 160, which may generate an event that is sent to source device 120. Prior to source device 120 receiving the event, another user may provide a user input at source device 120. In such examples, to facilitate such communication, timestamps may be applied to each user input. The timestamps may be used to synchronize the manner in which user inputs are applied to the display data rendered by source device 120. For instance, a first user input with an earlier timestamp may be applied prior to a second user input with a later timestamp.

FIG. 1B is a block diagram illustrating an exemplary source/sink system 101 that may implement techniques of this disclosure. Source/sink system 101 includes source device 120, sink device 160A, and sink device 160B (collectively, sink devices 160). In some examples, source device 120 and sink devices 160 may function and operate in the manner described above with respect to FIG. 1A. That is, in a similar manner as described with respect to sink device 160 shown in FIG. 1A, sink devices 160A and 160B may receive audio and video data from source device 120. For example, in some configurations, audio and video output at source device 120 may be simultaneously output at sink device 160A and sink device 160B.

Thus, in general, it should be understood that the techniques of this disclosure may be extended to support multiple source and/or sink devices. That is, according to aspects of this disclosure, as described above with respect to FIG. 1A, source device 120 may share graphical content for rendering at any or all of sink devices 160. Additionally or alternatively, any or all of sink devices 160 may act as secondary displays for source device 120. Additionally or alternatively, source device 120 may offload one or more applications being executed by source device 120 to sink device 160A, sink device 160B, or any other sink device in communication with source device 120.

While sink device 160A and sink device 160B have been assigned like numerals, it should be understood that, in some examples, sink device 160A and sink device 160B may have different capabilities and/or perform different functions. For example, in some configurations, sink device 160A may be a primary sink device and sink device 160B may be a secondary sink device. In such a configuration, sink device 160A and sink device 160B may be coupled, and sink device 160A may display video data while sink device 160B outputs corresponding audio data.

FIG. 2 is a block diagram showing one example of a source device 220, such as source device 120 in FIG. 1. Source device 220 includes local display 222, local speaker 223, processors 231, memory 232, transport module 233, and wireless modem 234. As shown in FIG. 2, source 220 device may include one or more processors (i.e. processor 231) that encode and/or decode A/V data for transport, storage, and display. The A/V data may for example be stored at memory 232. Memory 232 may store an entire A/V file, or may comprise a smaller buffer that simply stores a portion of an A/V file, e.g., streamed from another device or source. Transport module 233 may process encoded A/V data for network transport. For example, encoded A/V data may be processed by multimedia processors 231 and encapsulated by transport module 233 into Network Access Layer (NAL) units for communication across a network. The NAL units may be sent by wireless modem 234 to a sink device via a network connection.

Source device 220 may also locally process and display A/V data. In particular display processor 235 may process video data to be displayed on local display 222, audio processor 236 may process audio data for output on speaker 223.

As described above with reference to source device 120 of FIG. 1, source device 220 may also receive user input commands from a sink device. In this manner, wireless modem 234 of source device 220 receives encapsulated data packets, such as NAL units, and sends the encapsulated data units to transport unit 233 for decapsulation. For instance, transport unit 233 may extract data packets from the NAL units, and processor 231 can parse the data packets to extract the user input commands. Based on the user input commands, processor 231 can adjust the encoded A/V data being transmitted by source device 220 to a sink device.

Processor 231 of FIG. 2 generally represents any of a wide variety of processors, including but not limited to one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), other equivalent integrated or discrete logic circuitry, or some combination thereof. Memory 232 of FIG. 2 may comprise any of a wide variety of volatile or non-volatile memory, including but not limited to random access memory (RAM) such as synchronous dynamic random access memory (SDRAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), FLASH memory, and the like, Memory 232 may comprise a computer-readable storage medium for storing audio/video data, as well as other kinds of data. Memory 232 may additionally store instructions and program code that are executed by processor 231 as part of performing the various techniques described in this disclosure.

FIG. 3 shows an example of a sink device 360, such as sink device 160 in FIG. 1. Sink device 360 includes processor 331, memory 332, transport unit 333, wireless modem 334, display processor 335, local display 362, audio processor 336, speaker 363, and touch display interface 336. Sink device 360 receives at wireless modem 334 encapsulated data units sent from a source device. Transport unit 333 can decapsulate the encapsulated data units. For instance, transport unit 333 may extract encoded video data from the encapsulated data units and send the encoded A/V data to processor 331 to be decoded and rendered for output. Display processor 335 may process decoded video data to be displayed on local display 362, and audio processor 336 may process decoded audio data for output on speaker 363.

In addition to rendering audio and video data, sink device 360 can also receive user input through touch display interface 336. Although the example of FIG. 3 utilizes a touch display interface as an example input device, other input devices such as keyboards, mouse, or voice command modules are all compatible with the techniques of this disclosure. User input received through touch display interface 336 can be processed by processor 331. This processing may include generating data packets that included the received user input command in accordance with the techniques described in this disclosure. Once generated, transport module 333 may process the data packets for network transport to a wireless source device over a UIBC.

Processor 331 of FIG. 3 may comprise one or more of a wide range of processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), other equivalent integrated or discrete logic circuitry, or some combination thereof. Memory 332 of FIG. 3 may comprise any of a wide variety of volatile or non-volatile memory, including but not limited to random access memory (RAM) such as synchronous dynamic random access memory (SDRAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), FLASH memory, and the like, Memory 232 may comprise a computer-readable storage medium for storing audio/video data, as well as other kinds of data. Memory 332 may additionally store instructions and program code that are executed by processor 331 as part of performing the various techniques described in this disclosure.

FIG. 4 shows a block diagram of an example transmitter system 410 and receiver system 450, which may be used by transmitter/receiver 126 and transmitter/receiver 166 of FIG. 1 for communicating over communication channel 150. At transmitter system 410, traffic data for a number of data streams is provided from a data source 412 to a transmit (TX) data processor 414. Each data stream may be transmitted over a respective transmit antenna. TX data processor 414 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream.

The coded data for each data stream may be multiplexed with pilot data using orthogonal frequency division multiplexing (OFDM) techniques. A wide variety of other wireless communication techniques may also be used, including but not limited to time division multi access (TDMA), frequency division multi access (FDMA), code division multi access (CDMA), or any combination of OFDM, FDMA, TDMA and/or CDMA.

Consistent with FIG. 4, the pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., Binary Phase Shift Keying (BPSK), Quadrature Phase Shift Keying (QPSK), M-PSK, or M-QAM (Quadrature Amplitude Modulation), where M may be a power of two) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed by processor 430 which may be coupled with memory 432.

The modulation symbols for the data streams are then provided to a TX MIMO processor 420, which may further process the modulation symbols (e.g., for OFDM). TX MIMO processor 420 can then provides NT modulation symbol streams to NT transmitters (TMTR) 422a through 422t. In certain aspects, TX MIMO processor 420 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transmitter 422 may receive and process a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. NT modulated signals from transmitters 422a through 422t are then transmitted from NT antennas 424a through 424t, respectively.

At receiver system 450, the transmitted modulated signals are received by NR antennas 452a through 452r and the received signal from each antenna 452 is provided to a respective receiver (RCVR) 454a through 454r. Receiver 454 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream.

A receive (RX) data processor 460 then receives and processes the NR received symbol streams from NR receivers 454 based on a particular receiver processing technique to provide NT “detected” symbol streams. The RX data processor 460 then demodulates, deinterleaves and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 460 is complementary to that performed by TX MIMO processor 420 and TX data processor 414 at transmitter system 410.

A processor 470 that may be coupled with a memory 472 periodically determines which pre-coding matrix to use. The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 438, which also receives traffic data for a number of data streams from a data source 436, modulated by a modulator 480, conditioned by transmitters 454a through 454r, and transmitted back to transmitter system 410.

At transmitter system 410, the modulated signals from receiver system 450 are received by antennas 424, conditioned by receivers 422, demodulated by a demodulator 440, and processed by a RX data processor 442 to extract the reserve link message transmitted by the receiver system 450. Processor 430 then determines which pre-coding matrix to use for determining the beamforming weights then processes the extracted message.

FIG. 5 is a schematic diagram illustrating an example wireless communication between a source device and a sink device, according to aspects of this disclosure. While FIG. 5 is described with respect to source device 120 and sink device 160 (FIG. 1A), it should be understood that the techniques of FIG. 5 may be performed by a variety of devices, including other source and sink devices.

In the example shown in FIG. 5, display 122 of source device 120 is configured as a touch sensitive display. For example, display 122 may be a capacitive, resistive, or other type of touch panel that allows a user to provide user input to source device 120.

Thus, when a user provides a user input at display 122, source device 120 may generate one or more events that correspond to the user input. In some examples, display 122 may be designed to simultaneously recognize touches at more than one point, a feature commonly referred to as “multi-touch.” Multi-touch displays may separately identify and interpret touches in different areas of the screen. In addition to display 122, according to the example shown in FIG. 5, source device 120 may receive input from another source, such as one or more human interface devices (HIDs) 502. Example, HIDs 502 include a keyboard, mouse, trackball or track pad, touch screen, voice command recognition module, or any other such user input device.

In some examples, display 162 of sink device 160 may also be touch sensitive. That is, for example, display 162 may also be a capacitive, resistive, or other type of touch panel that allows a user to provide user input to source device 120. In some examples, display 162 may comprise a multi-touch display. Moreover, as shown in the example of FIG. 5, sink device 160 may also receive input from another source, such as one or more human interface devices (HIDs) 506.

According to aspects of this disclosure, source device 120 may send one or more events to sink device 160 (represented by line 510). For example, source device 120 may send certain events associated with user input at source device 120 to sink device 160. That is, the events may correspond to user input provided to display 122 and/or provided via HIDs 502. Likewise, in some examples, sink device 160 may send certain events associated with user input at sink device 160 to source device 120. Such events may correspond to user input provided to display 162 and/or provided via HIDs 506. In some examples, source device 120 may use Real-time Transport Protocol (RTP) and User Datagram Protocol (UDP) to send events to sink device 160. In other examples, source device 120 may use Transmission Control Protocol (TCP) and Internet Protocol (IP) to send events to sink device 160.

In some examples, sink device 160 may render data from source device 120 on only a portion of display 162 of sink device. That is, for example, sink device 160 may designate an area 514 in which to render graphical content 518 from source device 120. In some examples, as described in greater detail below, graphical content 518 may be displayed on display 162 in the same or in a different resolution than on display 122. Moreover, in some examples, sink device 160 may simultaneously render and display other graphical content 522 that is natively generated at sink device 160 on another portion of display 162.

As shown in FIG. 5, according to some aspects of this disclosure, source device 120 may share graphical content 518 for rendering at sink device 160. For example, source device 120 may, using techniques of this disclosure, generate configuration data that represents graphical objects included in the graphical content 518. In general, as noted above, configuration data may represent graphical objects included in the graphical content without providing actual pixel data. Moreover, the configuration data may represent the graphical objects using fewer bits than the pixel data associated with the graphical objects. In some examples, configuration data may be similar to OpenGL instructions or instructions of another GPU language. Thus, to achieve a bit savings with respect to the number of bits that are sent from source device 120 to sink device 160, source device 120 may send configuration data representing graphical content 518 to sink device 160 rather than pixel-level data. Upon receiving the configuration data, sink device 160 may use the configuration data to render the graphical content 518 at sink device 160. That is, sink device 160 may use the configuration data to render pixel-level data (e.g., RGB values, YCbCr values, or the like) for display.

In some examples, source device 120 may also generate configuration data that includes commands to modify or manipulate graphical content 518 rendered at sink device 160. For instance, if a user provides a user input to source device 120 (e.g., via display 122) to increase the size of a graphical object, source device 120, using techniques of the disclosure may generate configuration data that describes the increase in size. This configuration may be sent to sink device 160, which may use the configuration data to modify and/or manipulate the corresponding graphical content 514. That is, upon receiving the configuration data from source device 120, sink device 160 may use the configuration data to increase the size of the graphical content 518.

In another example, graphical content 518 may be associated with a motion picture or other video. In this example, source device 120 may render graphical content 518 using an application being executed by source device 120. According to aspects of this disclosure, a user may provide user input that causes source device 120 to share graphical content 518 included in the video with sink device 160. The user input may additionally cause graphical controls 526 of the application to be rendered at source device 120, without being rendered at sink device 160. In this way, techniques of the present disclosure may enable source device 120 to render a first portion of graphical content on source device 120 and a second portion of the graphical content on sink device 160. To render the second portion of the graphical content at sink device 160, source device 120 may generate configuration data usable by sink device 160 to render the graphical content. By sending the configuration data to sink device 160, the second portion of graphical content may be rendered at sink device 160.

Moreover, the techniques of the disclosure may provide improved display quality of graphical content shared between source device 120 and sink device 160 in situations in which source device 120 and sink device 160 have different rendering capabilities. In the example shown in FIG. 5, source device 120 may have a lower display resolution than sink device 160. According to aspects of this disclosure, sink device 160 may receive configuration data from source device 120, and utilize the configuration data to generate graphical content 514 in the native resolution of sink device 160. In this way, graphical content 514 may be displayed differently at sink device 160 than source device 120 (e.g., in a higher resolution, an alternative size, and the like).

FIG. 6 is a flow diagram illustrating an example method that may enable a source device to generate configuration data usable by a sink device. While the method shown in FIG. 6 may be described with respect to source device 120 and sink device 160 for purposes of explanation, it should be understood that the method of FIG. 6 may be performed by a variety of devices, including other source and/or sink devices.

As shown in FIG. 6, source device 120 may initially determine that display data rendered by source device 120 comprises one or more displayable graphical objects (600). Graphical objects may include, for example, objects comprised of one or more geometric primitives that form a shape for display. Source device 120, in response to determining an event, may select a set of the one or more graphical objects for rendering at sink device 160 (602). For example, an event may be generated in response to a user input. In another example, the event may be generated automatically by an application being executed by the source device 120.

Source device 120 may further generate configuration data based at least in part on the set of the one or more graphical objects (604). In general, configuration data may represent graphical objects without including pixel-level data (e.g., pixel values). Configuration data may require fewer bits than pixel-level data to represent the graphical objects. In some examples, configuration data may be similar to OpenGL instructions or instructions of another GPU language.

According to aspects of this disclosure, the configuration data may be usable by sink device 160 to render representations of the graphical objects in the set of one or more graphical objects. In some examples, source device 120 may generate configuration data based on display parameters of sink device 160. Display parameters may include, for example, display resolution, color bit depth, GPU type, or any other parameters that indicate display capabilities of sink device 160. Thus, source device 120 may generate configuration data that is interpretable by and/or specific to the capabilities and design of a GPU of sink device 160. In some examples, source device 120 may share more of the rendering load with sink device 160 having relatively powerful rendering capabilities than sink device 160 having relatively simplistic rendering capabilities.

Source device 120 may generate any combination of configuration data and pixel-level data for transmission to sink device 160. For example, source device 120 and sink device 160 may operate in various modes. One mode may cause source device 120 to generate only configuration data that represents graphical objects for transmission to sink device 160. Another mode may cause source device 120 to generate only pixel-level display data for transmission to sink device 160. In another mode, source device 120 may generate a combination of pixel-level data for some graphical objects and configuration data for other graphical objects for transmission to sink device 160.

After generating the configuration data, source device 120 may send the configuration data to sink device 160 (606). As described in greater detail with respect to FIG. 7 below, sink device 160 may utilize the configuration data to render the graphical objects represented by the configuration data.

FIG. 7 is a flow diagram illustrating an example method that may enable a sink device to render representations of a set of graphical objects using configuration data from a source device. While the method shown in FIG. 7 may be described with respect to source device 120 and sink device 160 for purposes of explanation, it should be understood that the method of FIG. 7 may be performed by a variety of devices, including other source and/or sink devices.

As shown in FIG. 7, sink device 160 may receive configuration data from source device 120 that is usable by sink device 160 to render representations of a set of graphical objects (700). As noted above, configuration data may represent graphical objects without including pixel-level data (e.g., pixel values), and may require fewer bits than pixel-level data to represent the graphical objects.

In some examples, sink device 160 may render the representations of the set of graphical objects using the configuration data (702). That is, for example, sink device 160 may interpret the configuration data to generate pixel-level data using the configuration data. In some examples, sink device 160 may render the representations based at least in part on one or more display parameters associated with the sink device 160 (702). Display parameters may include display resolution, color bit depth, GPU type, or any other parameters that indicate display capabilities of sink device 160.

In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.

Various examples have been described. These and other examples are within the scope of the following claims.