Patent Description:
Wireless display (WD) 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, tablet computers, laptop computers, portable computers with wireless communication cards, personal digital assistants (PDAs), wireless gaming devices, portable media players, or other flash memory devices with wireless communication capabilities. Mobile devices may also include 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 and/or video data, to one or more of the sink devices participating in a particular communication 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 display and audio equipment.

In <CIT>, disclosed are "graphics overrides. " An override accepts a stream of graphics commands as produced by an application and then modifies the stream before it is rendered by the GPU. Different overrides perform different modifications. One override can modify a stream of graphics commands in response to another stream. Overrides can enforce conformity with a visual paradigm and, by being modified, can support a change to that paradigm without requiring the applications to change. Overrides can monitor the entire computing environment and improve the response to that environment of a particular application: For example, an override monitors frames as they are produced by an application. If the application cannot keep up with a fixed frame rate, then the override produces "synthetic" frames to take the place of missing frames. Overrides are not restricted to fixing existing problems. Rather, applications can be developed that depend upon the presence of overrides.

In <CIT>, the simultaneous, real time graphical information is shared between two or more intelligent work stations linked together in conversation via a network. Transmission of the essence of a graphical image is accomplished by fixed and variable length portions. The fixed portion describes the type of command and the size or length of the variable length portion. The variable length portion describes the detailed information need to properly process. Thus, the complete length of data is known a priori. While a network is constipated or congested and a drawing operation is being performed by a user, the communication endpoints are configured as non-blocking, commands are stored in a FIFO (first-in, first-out) queue, and the operating system reports how much of the drawing operation was transferred. After the network becomes unconstipated, writing of any partially written command or stored commands in the queue are completed. The graphical image may be displayed in a window or canvas designated for drawing. By transmitting the parameters defining the object and its commands, the speed of the transmission is increased over pixel-by-pixel transmission.

In <CIT>, a client computing system in a client-server computing environment includes a client display driver that receives a transmission from a server, decodes graphics commands from the transmission using a client application, executes the functions using a client 3D library stored in a memory of the client, and renders the resulting image data to a display. The client may transmit capability information to the server, allowing the resolution of differences between the graphics application programming interfaces (APIs) supported on the server and the client.

In <CIT>, there is described a method for forwarding a graphics command stream comprising: receiving a target formatted graphics stream, encoded using an intermediate graphic semantic, where the target formatted graphics stream contains graphical information renderable as a graphical image; decoding the target formatted graphics stream; and processing the decoded target formatted graphics stream to generate a target graphics command stream, encoded for rendering by a target graphics component using a target graphics semantic, where the target command stream contains equivalent graphical information contained in the target formatted graphics stream. The target graphics semantic may be based on any of: OPENGL, OPENGL ES, OPENCL, and OPENVG.

Features of some embodiments are recited in dependent claims.

This disclosure describes techniques for streaming video from a source device to a sink device. In some examples, a source device may stream video to a sink device by capturing constructed frames from a frame buffer of the source device, and transmitting the captured frames to the sink device, which may then display the images at a display of the sink device. This method may be referred to as a "pixel domain" transmission method, e.g., where the frame comprises an array of pixels. However, in some examples, it may not be desirable to use the pixel domain method due to the high average data rate required for transmission of the captured images.

Alternatively, in some examples, a "graphics domain" transmission method may be used by a source device to stream deconstructed video frames (i.e., video frames in a non-raster format) to a sink device. Graphics domain transmission may be accomplished by capturing display data at an input of a graphics processing unit (GPU) of the source device in the form of graphical command tokens (e.g., tokens/instances of OpenGL commands and their operands) and texture elements, transmitting the graphical command tokens and texture elements to the sink device. A GPU of the sink device may execute the graphical command tokens to render displayable frames based on the texture elements (i.e., by referencing the texture elements), and output the rendered frames of video data at the display of the sink device.

In some cases, it may be desirable to modify the video data output at the display of the sink device. To avoid a degraded streaming experience, it may be desirable to perform the modification in real-time (or in near real-time) so as to avoid artifacts that can result from delay. When utilizing the pixel domain transmission method, it may not be possible to modify the captured frames in real-time (or in near real-time). However, when utilizing the graphics domain transmission method, it is possible to modify the captured frames in real-time (or in near real-time). For instance, as opposed to the pixel domain method where the captured frame may be stored and modified at a later time, by utilizing the graphics domain transmission method, the captured frames may be modified close to the time (e.g., within <NUM> milliseconds, <NUM> second, <NUM> seconds) of the time when the frames were captured.

In operation, a sink device may receive graphical command tokens that are renderable into original video data. For instance, the sink device may receive the graphical command tokens wirelessly from a source device.

In accordance with one or more techniques of this disclosure, the sink device may modify the graphical command tokens to generate modified graphical command tokens that are executable to render modified video data that is different than the original video data. The sink device may execute the modified graphical command tokens and output the modified video data for presentation at a display operatively connected to the sink device. In this way, the graphical command tokens may be modified (e.g., in real-time) to cause the sink device to output modified video data, i.e., video data that has been modified relative to the original video data in some way. The modification to the graphical command tokens may be any of a variety of modifications, or combinations of such modifications, that result, in general, in a modification to the visual appearance of the video data that is presented to a user.

Some example modifications that a sink device may make to the graphical command tokens include, but are not limited to, image processing point operations (e.g., color conversions such as Grayscale adjustment, blurring, sharpening, etc.), image processing filters with artistic effects (Instagram-like filters), resolution changes (e.g., to render at higher lower spatial resolution or larger or smaller size, e.g., for partial covering of the display to allow multiple apps, etc.), viewpoint changes for three-dimensional (3D) objects, and replacing texture elements. The modifications to the graphical command tokens that are performed by the sink device can be general for any application (for example, Grayscale effect), or application-specific (for example, changing 3D viewpoint of a specific object in a specific application). The modifications can be partial or for the whole view (for example, adding an effect on figures of a PDF document in Adobe Reader but not adding the effect on text). The modifications can be adaptive. For example, the browser output at the display of the sink device may include a whole webpage if viewed by company employees, but may blur certain parts if viewed by non-employees/guests.

<FIG> is a conceptual diagram of an example wireless display (WD) system in which a device is configured to modify graphical command tokens, in accordance with one or more techniques of this disclosure. As illustrated in <FIG>, WD system <NUM> includes source device <NUM>, sink device <NUM>, and communication channel <NUM>.

Communication channel <NUM> may be any channel capable of propagating communicative signals between source device <NUM> and sink device <NUM>. In some examples, communication channel <NUM> may be a wireless communication channel. For instance, communication channel <NUM> may be implemented in radio frequency communications in frequency bands such as the <NUM> gigahertz (GHz) band, the <NUM> band, the <NUM> band, or other frequency bands. In some examples, communication channel <NUM> may comply with one or more sets of standards, protocols, or technologies such as wireless universal serial bus (WUSB) (as promoted by the USB Implementers Forum), Wi-Fi (as promoted by the Wi-Fi Alliance), WiGig (as promoted by the Wireless Gigabit Alliance), and/or the Institute of Electrical and Electronics Engineers (IEEE) <NUM> set of standards (e.g., <NUM>, <NUM>. 11a, <NUM>. 11b, <NUM>, <NUM>. 11n, <NUM>. 11ac, <NUM>. 11ad, etc.), or other standards, protocols, or technologies. The <NUM> revision of the <NUM> specification is set forth at http://standards. org/getieee802/download/<NUM>-<NUM>. The frequency bands used, such as the <NUM>, <NUM>, and <NUM> bands, may be defined for purposes of this disclosure as they are understood in light of the standards of Wi-Fi, WiGig, any one or more of the IEEE <NUM> protocols, or other applicable standards or protocols.

WD <NUM> may include source device <NUM> which may be configured to transmit video data in the form of graphical command tokens to a sink device, such as sink device <NUM>, over a communication channel, such as communication channel <NUM>. Examples of source device <NUM> may include, but are not limited to mobile devices such as smartphones or other mobile handsets, tablet computers, laptop computers, desktop computers, wearable computing devices (e.g., smart watches, visors, and the like), one or more processing units or other integrated circuits or chip sets, or other electronic devices. As illustrated in the example of <FIG>, source device <NUM> may include communication module <NUM>, graphics processing unit (GPU) <NUM>, streaming module <NUM>, and application modules 18A-18N.

Source device <NUM> may include communication module <NUM> which may manage communications between source device <NUM> and one or more external devices, such as sink device <NUM>. For instance, communication module <NUM> may exchange data with sink device <NUM> over communication channel <NUM>. As one example, communication module <NUM> may stream graphical command tokens to sink device <NUM> over communication channel <NUM>. In some examples, communication module <NUM> may receive information to be transmitted from other components of source device <NUM>. For example, communication module <NUM> may receive graphical command tokens from streaming module <NUM>.

Source device <NUM> may include GPU <NUM> which may render frames of video data based on one or more texture elements and graphical command tokens. Some examples of graphical commands which may be tokenized and performed by GPU <NUM> include, but are not limited to, the DirectX® API by Microsoft®, the Vulkan® API by the Khronos group, the OpenGL® API by the Khronos group (e.g., The OpenGL® A Specification (Version <NUM> (Core Profile) - May <NUM>, <NUM>), available at https://www. org/registry/doc/glspec45. pdf), and the OpenCL™ API by the Khronos group (e.g., The OpenCL Specification, Version <NUM>, Khronos OpenCL Working Group, January <NUM>, <NUM>, available at https://www. org/registry/cl/specs/opencl-<NUM>. In some examples, GPU <NUM> may render frames of video data based on graphical command tokens and texture elements associated with one or more of application modules <NUM>. For instance, GPU <NUM> may render frames of video data based on graphical command tokens generated by, and texture elements associated with, an application module of application modules <NUM> for output at a display operatively coupled to or included in source device <NUM>.

Source device <NUM> may include streaming module <NUM>, which may be configured to stream video data to one or more external devices. For instance, streaming module <NUM> may stream video data in the form of graphical command tokens and texture elements to sink device <NUM>. In some examples, streaming module <NUM> may capture the graphical command tokens and/or texture elements <NUM> at an input of GPU <NUM>. Streaming module <NUM> may output a bitstream that includes the graphical command tokens and one or more texture elements to communication module <NUM> for transmission to sink device <NUM>.

Source device <NUM> may include application modules <NUM> which may each represent an application provided by an entity that manufactures source device <NUM> or software operating on source device <NUM> or an application developed by a third party for use with source device <NUM>. Examples of application modules <NUM> may include applications for gaming, shopping, travel routing, maps, audio and/or video presentation, word processing, spreadsheets, weather, etc..

Source device <NUM> may include texture elements <NUM> which may be utilized by a GPU to render frames of video data. In some examples, one or more of texture elements <NUM> may be associated with a particular application module of application modules <NUM>. For instance, where a gaming application of application modules <NUM> entails the slicing of falling fruit (e.g., watermelons, avocados, pineapples, etc.), example texture elements of texture elements <NUM> that may be associated with the gaming application include a graphical representation of each of the types of fruit. In some examples, texture elements <NUM> may be stored in a plurality of formats. Some example formats include, but are not limited to, RGBα <NUM>, RGBα <NUM>, RGBα <NUM>, RGB <NUM>, Yα <NUM>, and α <NUM>.

WD <NUM> may include sink device <NUM>, which may be configured to receive video data in the form of graphical command tokens from a source device, such as source device <NUM>, over a communication channel, such as communication channel <NUM>. Examples of sink device <NUM> may include, but are not limited to mobile devices such as smartphones or other mobile handsets, tablet computers, laptop computers, desktop computers, wearable computing devices (e.g., smart watches, visors, and the like), televisions, monitors, one or more processing units or other integrated circuits or chip sets, or other electronic devices. As illustrated in the example of <FIG>, sink device <NUM> may include communication module <NUM>, graphics processing unit (GPU) <NUM>, streaming module <NUM>, and texture elements <NUM>.

Sink device <NUM> may include communication module <NUM>, which may manage communications between sink device <NUM> and one or more external devices, such as source device <NUM>. In some example, communication module <NUM> may perform operations similar to communication module <NUM> of source device <NUM>. For instance, communication module <NUM> may exchange data with source device <NUM> over communication channel <NUM>. As one example, communication module <NUM> may receive graphical command tokens and texture elements from source device <NUM> over a direct Wi-Fi connection. In some examples, communication module <NUM> may provide received information to other components of sink device <NUM>. For example, communication module <NUM> may provide received graphical command tokens and texture elements to streaming module <NUM>.

Sink device <NUM> may include GPU <NUM>, which may perform operations similar to GPU <NUM> of source device <NUM>. For instance, GPU <NUM> may render frames of video data based on one or more texture elements and graphical command tokens. In some examples, GPU <NUM> may be capable of performing the same graphical commands as GPU <NUM>. Some examples of graphical commands which may be performed by GPU <NUM> include, but are not limited to, the DirectX® API by Microsoft®, the OpenGL® API by the Khronos group, and the OpenCL™ API. In some examples, GPU <NUM> may render frames of video data based on graphical command tokens and texture elements received from one or more other components of sink device <NUM>, such as streaming module <NUM>. For instance, GPU <NUM> may render frames of video data based on graphical command tokens and texture elements received from streaming module <NUM> for output at a display operatively coupled to or included in sink device <NUM>.

Sink device <NUM> may include streaming module <NUM> which may be configured to receive streaming video data from one or more external devices. For instance, streaming module <NUM> may receive streaming video data in the form of graphical command tokens and texture elements from source device <NUM>.

Sink device <NUM> may store texture elements <NUM>, which may be utilized by a GPU to render frames of video data. In some examples, streaming module <NUM> may store texture elements received from source device <NUM> in texture elements <NUM>.

A user of source device <NUM> may desire to stream video from source device <NUM> to sink device <NUM>. For instance, where a size of a display of source device <NUM> is smaller than a size of a display of sink device <NUM>, the user of source device <NUM> may desire to utilize the larger display of sink device <NUM> to output the video. However, it may not be desirable to transmit constructed frames of video data from source device <NUM> to sink device <NUM>, e.g., due to bandwidth restrictions, processing power, and the like. As such, streaming module <NUM> source device <NUM> may output graphical command tokens and one or more texture elements to streaming module <NUM> of sink device <NUM> via communication channel <NUM> in order to cause GPU <NUM> of sink device <NUM> to render frames of video data. In this way, as opposed to streaming video data in the pixel domain, source device <NUM> may stream video data to sink device <NUM> in the graphics domain, e.g., by streaming graphical commands and texture elements.

In some examples, it may be desirable to modify the video data output at the display of sink device <NUM>. To avoid a degraded streaming experience, it may be desirable to perform the modification in real-time (or in near real-time). Additionally, it may be desirable for the modification to be application- independent. That is, it may be desirable for the modification to occur without the involvement of the application that generated the video data (i.e., such that the application that generated the video data need not be installed on the sink device). In accordance with one or more techniques of this disclosure, streaming module <NUM> of sink device <NUM> may modify graphical command tokens in order to cause GPU <NUM> to render modified video data.

In operation, source device <NUM> may receive original graphical command tokens and one or more texture elements that are renderable into original video data. For instance, streaming module <NUM> of source device <NUM> may receive the original graphical command tokens by capturing the graphical command tokens at an input of GPU <NUM> of source device <NUM>. Streaming module <NUM> of source device <NUM> may output a bitstream that includes the original graphical command tokens and one or more texture elements to streaming module <NUM> of sink device <NUM> via communication channel <NUM>.

Streaming module <NUM> of sink device <NUM> may receive the original graphical command tokens from source device <NUM>. For instance, streaming module <NUM> may wirelessly receive the bitstream via communication module <NUM>. In accordance with one or more techniques of this disclosure, streaming module <NUM> may modify the original graphical command tokens to generate modified graphical command tokens and cause GPU <NUM> to execute the modified graphical command tokens to render modified video data that is different than the original video data. In this way, sink device <NUM> may modify the original graphical command tokens (e.g., in real-time) to cause GPU <NUM> to render modified video data (i.e., while remaining application-independent).

<FIG> is a block diagram illustrating further details of one example of source device <NUM> and sink device <NUM> of <FIG> in which source device <NUM> is configured to stream video data to sink device <NUM> over communication channel <NUM>, in accordance with one or more techniques of the present disclosure.

As illustrated in <FIG>, source device <NUM> may include one or more processors <NUM>, one or more communication units <NUM>, one or more user interface (UI) devices <NUM>, and one or more storage devices <NUM>. Each of components <NUM>, <NUM>, <NUM>, and <NUM> may be interconnected (physically, communicatively, and/or operatively) via communication channels <NUM> for inter-component communications. In some examples, communication channels <NUM> may include a system bus, network connection, inter-process communication data structure, or any other channel for communicating data. One or more of storage devices <NUM>, in some examples, may include communication module <NUM>, streaming module <NUM>, one or more application modules 18A-18N (collectively, "application modules <NUM>"), and UI module <NUM>.

One or more processors <NUM> (i.e., processor(s) <NUM>), in one example, are configured to implement functionality and/or process instructions for execution within source device <NUM>. For example, processors <NUM> may be capable of processing instructions stored in one or more of storage devices <NUM>. Examples of processors <NUM> may include any one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components.

Source device <NUM>, in some examples, also includes ones or more communication units <NUM>. Source device <NUM>, in one example, utilizes one or more of communication units <NUM> to communicate with external devices via one or more networks, such as one or more wireless networks. One or more of communication units <NUM> may be a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include Bluetooth, <NUM>, and Wi-Fi radios. In some examples, source device <NUM> utilizes communication unit <NUM> to wirelessly communicate with an external device. For instance, source device <NUM> may utilize communication unit <NUM> to wirelessly communicate with communication unit <NUM> of sink device <NUM> over communication channel <NUM>. In some examples, communication unit <NUM> may receive input from other components of source device <NUM>, such as communication module <NUM>, which causes communication unit <NUM> to communicate with an external device.

Source device <NUM>, in some examples, may also include one or more UI devices <NUM>. In some examples, one or more of UI devices <NUM> can be configured to output content, such as video data. For instance, a display of UI devices <NUM> may be configured to display frames of video data rendered by GPU <NUM>. In addition to outputting content, one or more of UI devices <NUM> may be configured to receive tactile, audio, or visual input. Some examples of UI devices <NUM> include video displays, speakers, keyboards, touch screens, mice, trackballs, or other pointing devices, cameras, and the like.

Source device <NUM>, in some examples, may also include UI module <NUM>. UI module <NUM> can perform one or more functions to receive, content, such as UI data from other components associated with source device <NUM> and cause one or more of UI devices <NUM> to output the content. In some examples, UI module <NUM> may be configured to receive an indication of input, such as user input, and send the indications of the input to other components associated with source device <NUM>, such as streaming module <NUM>.

One or more storage devices <NUM> may be configured to store information within source device <NUM> during operation. One or more of storage devices <NUM>, in some examples, may comprise a computer-readable storage medium. In some examples, one or more of storage devices <NUM> may comprise a temporary memory, meaning that a primary purpose of one or more of storage devices <NUM> is not long-term storage. One or more of storage devices <NUM>, in some examples, may comprise a volatile memory, meaning that one or more of storage devices <NUM> does not maintain stored contents when the system is turned off. Example of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, one or more of storage devices <NUM> is used to store program instructions for execution by processors <NUM>. One or more of storage devices <NUM>, in one example, may be used by software or modules running on source device <NUM> (e.g., communication module <NUM>, streaming module <NUM>, application modules <NUM>, and UI module <NUM>) to temporarily store information during program execution.

One or more of storage devices <NUM>, in some examples, may also include one or more computer-readable storage media. One or more of storage devices <NUM> may further be configured for long-term storage of information. In some examples, one or more of storage devices <NUM> may include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Sink device <NUM> may include one or more processors <NUM> (i.e., processor(s) <NUM>), one or more communication units <NUM>, one or more user interface (UI) devices <NUM>, and one or more storage devices <NUM>. Each of components <NUM>, <NUM>, <NUM>, and <NUM> may be interconnected (physically, communicatively, and/or operatively) via communication channels <NUM> for inter-component communications. In some examples, communication channels <NUM> may include a system bus, network connection, inter-process communication data structure, or any other channel for communicating data. One or more of storage devices <NUM>, in some examples, may include communication module <NUM>, streaming module <NUM>, texture elements <NUM>, and UI module <NUM>.

Processors <NUM>, in some examples, may be configured to implement functionality and/or process instructions for execution within sink device <NUM>. For example, processors <NUM> may be capable of processing instructions stored in one or more of storage devices <NUM>. Examples of processors <NUM> may include any one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components.

Sink device <NUM>, in some examples, also includes ones or more communication units <NUM>. Sink device <NUM>, in one example, utilizes one or more of communication units <NUM> to communicate with external devices via one or more networks, such as one or more wireless networks. One or more of communication units <NUM> may be a network interface card, such as a USB transceiver, an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include Bluetooth, <NUM>, and Wi-Fi radios. In some examples, sink device <NUM> utilizes communication unit <NUM> to wirelessly communicate with an external device. For instance, sink device <NUM> may utilize communication unit <NUM> to wirelessly communicate with communication unit <NUM> of source device <NUM> over communication channel <NUM>. In some examples, communication unit <NUM> may provide received data to other components of sink device <NUM>, such as communication module <NUM>.

Sink device <NUM>, in some examples, may also include one or more UI devices <NUM>. In some examples, one or more of UI devices <NUM> can be configured to output content, such as video data. For instance, a display of UI devices <NUM> may be configured to display frames of video data rendered by GPU <NUM>. In addition to outputting content, one or more of UI devices <NUM> may be configured to receive tactile, audio, or visual input. Some examples of UI devices <NUM> include video displays, speakers, keyboards, touch screens, mice, cameras, and the like.

Sink device <NUM>, in some examples, may also include UI module <NUM>. UI module <NUM> can perform one or more functions to receive, content, such as UI data from other components associated with sink device <NUM> and cause one or more of UI devices <NUM> to output the content. In some examples, UI module <NUM> may be configured to receive an indication of input, such as user input, and send the indications of the input to other components associated with sink device <NUM>, such as streaming module <NUM>.

One or more storage devices <NUM> may be configured to store information within sink device <NUM> during operation. One or more of storage devices <NUM>, in some examples, may comprise a computer-readable storage medium. In some examples, one or more of storage devices <NUM> may comprise a temporary memory, meaning that a primary purpose of one or more of storage devices <NUM> is not long-term storage. One or more of storage devices <NUM>, in some examples, may comprise a volatile memory, meaning that one or more of storage devices <NUM> does not maintain stored contents when the system is turned off. Example of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, one or more of storage devices <NUM> is used to store program instructions for execution by processors <NUM>. One or more of storage devices <NUM>, in one example, may be used by software or modules running on sink device <NUM> (e.g., communication module <NUM>, streaming module <NUM>, and UI module <NUM>) to temporarily store information during program execution.

As discussed above, sink device <NUM> may include streaming module <NUM>, which may be configured to receive streaming video data from one or more external devices. In some examples, streaming module <NUM> may include command modification module <NUM>, which may be configured to modify one or more graphical command tokens. As described in further detail below, command modification module <NUM> may modify the graphical command tokens to generate modified graphical command tokens that are executable by GPU <NUM> to render modified video data.

<FIG> are conceptual diagrams illustrating example modifications of graphical commands that may be performed by a device, in accordance with one or more aspects of the present disclosure. <FIG> illustrate an example texture element replacement modification. <FIG> illustrate an example three-dimensional (3D) viewpoint change modification. <FIG> illustrate an example highlight modification. <FIG> illustrates an example split screen modification. For purposes of explanation, the modifications of <FIG>, <FIG>, <FIG> and <FIG> are described within the context of sink device <NUM> illustrated in <FIG> and <FIG>, although computing devices having configurations different than that of sink device <NUM> may perform the modifications of <FIG>, <FIG>, <FIG> and <FIG>.

<FIG> respectively illustrate frame 302A of original video data rendered based on original graphical command tokens and frame 302B of modified video data rendered based on modified graphical command tokens. Frame 302A may be displayed on a display device such as a display device of UI devices <NUM> of <FIG>. As shown in <FIG>, frame 302A of the original video data may be rendered based on original graphical command tokens generated by a gaming application (e.g., an application module of application modules <NUM> of source device <NUM> of <FIG> and <FIG>) that involves flying a helicopter through various obstacles. To enable rendering of frame 302A of the original video data, one or more of the graphical command tokens generated by the gaming application may include references to helicopter texture element <NUM>. For instance, one or more of the graphical command tokens generated by the gaming application may include a reference to a buffer that includes pixel values for helicopter texture element <NUM> (e.g., a glTexImage2D or glTexSubImage2D graphical command may include a pointer to a buffer).

As discussed above, streaming module <NUM> of sink device <NUM> may receive the original graphical command tokens from source device <NUM>. In accordance with one or more techniques of this disclosure, sink device <NUM> may modify the original video data by replacing one or more texture elements included in the original video data. For instance, command modification module <NUM> may modify the one or more graphical command tokens generated by the gaming application to generate modified graphical command tokens by replacing references in the graphical command tokens to an original texture element with references to a replacement texture element that is different from the original texture element. In some examples, the replacement texture element may be included in texture elements <NUM>. For instance, command modification module <NUM> may modify the pixel values for the original texture element in the buffer with pixel values for the replacement texture element. As one example, command modification module <NUM> may overwrite the pixel values in a buffer pointed to by a glTexImage2D or glTexSubImage2D graphical command with pixel values for the replacement texture element.

In the example of <FIG>, when generating the modified graphical command tokens, command modification module <NUM> may replace references in the graphical command tokens to helicopter texture element <NUM> with references to dragon texture element <NUM>. As shown in <FIG>, by replacing references to helicopter texture element <NUM> with references to dragon texture element <NUM>, command modification module <NUM> may cause GPU <NUM> to render frame 302B of the modified video data with dragon texture element <NUM> in the place of helicopter texture element <NUM>.

In some examples, sink device <NUM> may modify the original video data by changing a language of one or more texture elements. For instance, sink device <NUM> may perform optical character recognition (OCR) on an original texture element referenced by the original graphical command tokens to determine whether the original texture element includes text. If a language selected by a user of sink device <NUM> is different than text included in the original texture element, sink device <NUM> may generate a replacement texture element that includes a translation of the text into the language selected by the user of sink device <NUM> and replace references to the original texture element with references to the replacement texture element as described above.

<FIG> respectively illustrate frame 402A of original video data rendered based on original graphical command tokens and frame 402B of modified video data rendered based on modified graphical command tokens. As shown in <FIG>, frame 402A of the original video data may be rendered based on original graphical command tokens generated by a presentation application (e.g., an application module of application modules <NUM> of <FIG> and <FIG>) that involves the presentation of three-dimensional (3D) pie-chart object <NUM>. To enable rendering of frame 402A of the original video data, one or more of the graphical command tokens generated by the presentation application may cause 3D pie-chart object <NUM> to be rendered at first viewpoint 404A.

As discussed above, streaming module <NUM> of sink device <NUM> may receive the original graphical command tokens from source device <NUM>. In accordance with one or more techniques of this disclosure, sink device <NUM> may modify the original video data by adjusting the viewpoint at which a 3D object is rendered. For instance, where original graphical command tokens are executable to render original video data that includes a representation of a 3D object from a first viewpoint, command modification module <NUM> may modify the one or more graphical command tokens by generating modified graphical command tokens that are executable to render modified video data to include a representation of the 3D object from a second viewpoint that is different than the first viewpoint. For instance, command modification module <NUM> may detect a graphical command that includes a transformation matrix for the 3D object (e.g., one of the glUniformMatrix4fv commands) and multiply the transformation matrix by the desired transformation. As one example, if the required viewpoint change is scaling by <NUM> in x, y, z directions (to enlarge the object), command modification module <NUM> may multiply the transformation matrix by [<NUM><NUM><NUM><NUM>; <NUM><NUM><NUM><NUM>; <NUM><NUM><NUM><NUM>; <NUM><NUM><NUM><NUM>].

In the example of <FIG>, command modification module <NUM> may generate modified graphical command tokens that cause 3D pie-chart object <NUM> to be rendered at second viewpoint 404B. As shown in <FIG>, by generating the modified graphical command tokens that cause 3D pie-chart object <NUM> to be rendered at second viewpoint 404B, command modification module <NUM> may cause GPU <NUM> to render frame 402B of the modified video data with 3D pie-chart object <NUM> at a different viewpoint than in frame 402A of the original video data.

<FIG> respectively illustrate frame 502A of original video data rendered based on original graphical command tokens and frame 502B of modified video data rendered based on modified graphical command tokens. As shown in <FIG>, frame 502A of the original video data may be rendered based on original graphical command tokens generated by a presentation application (e.g., an application module of application modules <NUM> of <FIG> and <FIG>) that involves the presentation of flow-diagram <NUM> that includes blocks 506A-506C (collectively, "blocks <NUM>").

As discussed above, streaming module <NUM> of sink device <NUM> may receive the original graphical command tokens from source device <NUM>. In accordance with one or more techniques of this disclosure, sink device <NUM> may modify the original video data by highlighting one or more regions of the original video data. For instance, command modification module <NUM> may modify the original graphical command tokens by generating modified graphical command tokens that are executable to render modified video data that includes a highlight overlaid on the original video data. As one example, where the original graphical command tokens are executable to render the original video data as tiles of original texture elements, command modification module <NUM> may modify pixel values for one or more of the original texture elements in a buffer referenced by one or more of the original graphical command tokens with pixel values for a replacement texture element that includes the highlight overlay.

In the example of <FIG>, command modification module <NUM> may generate modified graphical command tokens that cause highlight box <NUM> to be rendered on top of block 506A of flow-diagram <NUM>. As shown in <FIG>, by generating the modified graphical command tokens that cause highlight box <NUM> to be rendered on top of block 506A of flow-diagram <NUM>, command modification module <NUM> may cause GPU <NUM> to render frame 502B of the modified video data with additional emphasis on block 506A.

<FIG> illustrates frame <NUM> of modified video data that is rendered based on modified graphical command tokens. As discussed above, streaming module <NUM> of sink device <NUM> may receive the original graphical command tokens from source device <NUM>. In accordance with one or more techniques of this disclosure, as opposed to presenting a single version of a frame of modified video data, sink device <NUM> may simultaneously present multiple versions of a frame of video data at a single display device. For instance, command modification module <NUM> may generate one or more sets of modified graphical command tokens, and cause GPU <NUM> to execute the one or more sets of the modified graphical command tokens to render one or more versions of modified video data at different regions of a single frame of modified video data.

In the example of <FIG>, command modification module <NUM> may receive one or more original graphical command tokens executable to render frame <NUM> of original video data that includes blocks 606A-606C (collectively, "blocks <NUM>") of flow diagram <NUM>. Command modification module <NUM> may modify the original graphical command tokens to generate a first set of modified graphical command tokens that are executable to render frame 615A of modified video data that include blocks <NUM> with highlight box <NUM> over block 606A, a second set of modified graphical command tokens that are executable to render frame 615B of modified video data that includes blocks <NUM> with highlight box <NUM> over block 606B, and a third set of modified graphical command tokens that are executable to render frame 615C of modified video data that includes blocks <NUM> with highlight box <NUM> over block 606C.

Command modification module <NUM> may combine the original set of graphical command tokens along with the first, second, and third set of modified graphical command tokens and cause GPU <NUM> to execute the one or more sets of the modified graphical command tokens to render a single frame of modified video data. As shown in <FIG>, command modification module <NUM> may combine the sets of graphical command tokens such that GPU <NUM> renders frame 614A of the original video data in the top-left quarter of frame <NUM>, frame 615A of modified video data in the top-right quarter of frame <NUM>, frame 615B in the bottom-left quarter of frame <NUM>, and frame 615C in the bottom-right quarter of frame <NUM>. In this way, command modification module <NUM> may generate multiple sets of modified graphical command tokens from a single set of original graphical command tokens (i.e., from a single bitstream).

It should be understood that the modifications described with reference to <FIG> are only examples and that other types of modifications are possible. As one example, sink device <NUM> may modify the graphical command tokens such that the modified video data is rendered with image processing point operations (e.g., color conversions such as Grayscale, blurring, sharpening, etc.). As another example, sink device <NUM> may modify the graphical command tokens such that the modified video data is rendered with the appearance of being processed with one or more image processing filters, such as one or more photographic filters (e.g., Instagram-like filters). As another example, sink device <NUM> may modify the graphical command tokens to perform resolution changes (e.g., to render at larger resolution, for partial covering of the display to allow multiple apps, etc.).

In some examples, the modifications performed by sink device <NUM> may be for any application (for example, Grayscale effect). In some examples, the modifications performed by sink device <NUM> may be application-specific (for example, changing 3D viewpoint of a specific object in a specific application). The modifications performed by sink device <NUM> can be partial or for the whole view (for example, adding an effect on figures of a PDF document in Adobe Reader but not on text). The modifications performed by sink device <NUM> can be adaptive (for example, a web browser output at the display of the sink device may include a whole webpage if viewed by company employees, but may blur certain parts if viewed by guests).

<FIG> is a flow diagram illustrating example operations of a sink device to process video data, in accordance with one or more techniques of the present disclosure. The techniques of <FIG> may be performed by one or more processors of a computing device, such as sink device <NUM> illustrated in <FIG> and <FIG>. For purposes of illustration, the techniques of <FIG> are described within the context of sink device <NUM> illustrated in <FIG> and <FIG>, although computing devices having configurations different than that of sink device <NUM> may perform the techniques of <FIG>.

In accordance with one or more techniques of this disclosure, sink device <NUM> may receive, from a source device, graphical command tokens that are executable to render original video data (<NUM>). For instance, one or more of processors <NUM> of sink device <NUM> may execute streaming module <NUM> to wirelessly receive a bitstream that includes the graphical command tokens from a source device, such as source device <NUM>. In some examples, the bitstream received by sink device <NUM> may also include one or more texture elements.

Sink device <NUM> may modify the graphical command tokens to generate modified graphical command tokens (<NUM>). For instance, one or more of processors <NUM> may execute command modification module <NUM> to generate the modified graphical command tokens by inserting additional graphical command tokens into the received bitstream. In some examples the original video data and the modified video data may be a sequence of frames of video data. In some examples the original video data and the modified video data may be a single frame of video data.

One or more of processors <NUM> may execute command modification module <NUM> to perform a wide-variety of modifications. Some example modifications that command modification module <NUM> may be executed to perform include, but are not limited to, replacing texture elements (e.g., the example of <FIG>), viewpoint changes for 3D objects (e.g., the example of <FIG>), image processing point operations (e.g., the example of <FIG>), image processing filters with artistic effects, and resolution changes.

In any case, sink device <NUM> may execute the modified graphical command tokens to render modified video data (<NUM>) and output, for presentation at a display, the modified video data (<NUM>). For instance, one or more of processors <NUM> may execute command modification module <NUM> to cause GPU <NUM> of sink device <NUM> to execute the modified graphical command tokens to render the modified video data and output the rendered modified video data at a display of UI devices <NUM> of sink device <NUM>.

Moreover, in certain examples, acts or events may be performed concurrently, e.g., through multi -threaded processing, interrupt processing, or multiple processors, rather than sequentially.

Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of inter-operative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.

Claim 1:
A method for processing video data streamed by a source device (<NUM>) to a sink device (<NUM>), the method comprising:
receiving (<NUM>), by the sink device and from the source device, one or more graphical command tokens generated by an application of the source device, wherein the one or more graphical command tokens are executable to render a frame of original video data at a first resolution, and wherein the graphical command tokens are instances of commands of a graphics application programming interface, API;
modifying (<NUM>), by the sink device and independent of the application of the source device, the graphical command tokens to generate modified graphical command tokens that are executable to render one or more modified frames of video data at a second resolution that is different from the first resolution;
rendering (<NUM>), by a GPU of the sink device, the modified graphical command tokens to generate the one or more modified frames of video data at the second resolution; and
outputting (<NUM>), for presentation at the display operatively connected to the sink device, the one or more modified frames of video data at the second resolution.