`(12) Patent Application Publication (10) Pub. No.: US 2009/0248802 A1
`Mahajan et al.
`(43) Pub. Date:
`Oct. 1, 2009
`
`US 200902488O2A1
`
`(54) SYSTEMS AND METHODS FORMANAGING
`MULTIMEDIA OPERATIONS IN REMOTE
`SESSIONS
`
`(75) Inventors:
`
`Rajneesh Mahajan, Bellevue, WA
`(US); Vladimir Stoyanov,
`Redmond, WA (US)
`Correspondence Address:
`LEE & HAYES, PLLC
`601 W. RIVERSIDEAVENUE, SUITE 1400
`SPOKANE, WA99201 (US)
`
`(73) Assignee:
`
`Microsoft Corporation, Redmond,
`WA (US)
`
`(21) Appl. No.:
`
`12/060,620
`
`(22) Filed:
`
`Apr. 1, 2008
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 5/16
`(2006.01)
`G06F 3/4
`(52) U.S. Cl. ......................................... 709/204; 715/716
`(57)
`ABSTRACT
`Techniques relating to managing multimedia transmissions in
`terminal services scenarios are described. In an example, a
`method sends a user-interface component from a server to a
`remote client. The exemplary method further streams a media
`component for presentation on the remote client in combina
`tion with the user-interface component and the media presen
`tation is tracked but not displayed by the server.
`
`SERVER 102
`
`CLIENT 04
`
`
`
`
`
`
`
`
`
`
`
`
`
`COLLABORATION MEDIA ABSTRACTION
`LAYER 130
`
`NETWORK
`106
`
`
`
`
`
`MEDIA PLATFORM
`122
`
`MEDIA PLAYER
`120
`
`MEDIA, PLATFORM
`126
`
`MEDIA PLAYER
`124
`
`1
`
`Comcast, Ex. 1114
`
`
`
`Patent Application Publication
`
`Oct. 1, 2009 Sheet 1 of 6
`
`US 2009/0248802 A1
`
`
`
`a.
`O
`H
`s
`
`f
`c
`s
`If
`s
`e
`O
`-
`a
`Y
`O
`c
`-
`-
`C.)
`
`i S.
`
`3
`
`N
`
`|OOOOOOO
`OOOOOOOOOO
`
`2
`
`
`
`Patent Application Publication
`
`Oct. 1, 2009 Sheet 2 of 6
`
`US 2009/0248802 A1
`
`
`
`(SCINw|NWOO (TELOVH1SEVý)|----
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`3
`
`
`
`Patent Application Publication
`
`Oct. 1, 2009 Sheet 3 of 6
`
`US 2009/0248802 A1
`
`OZ LNEJITO
`
`
`
`
`
`
`
`| Z WHO HLÝTA VIGE|W|
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`OZ HEAHES
`
`TY
`
`dU IISUO
`
`4
`
`
`
`Patent Application Publication
`
`Oct. 1, 2009 Sheet 4 of 6
`
`US 2009/0248802 A1
`
`
`
`
`
`575 HEAx’T-I VICIELAJ
`
`
`
`HECTO DECI 'A
`
`HEHETNEY) A
`
`*-- - - - --
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5
`
`
`
`Patent Application Publication
`
`Oct. 1, 2009 Sheet 5 of 6
`
`US 2009/0248802 A1
`
`500 \
`
`
`
`RECEIVING PLATFORM SPECIFIC COMMANDS
`ASSOCIATED WITH ACTIONS RELATED TO A MEDIA
`FILE FROMA REQUESTING COMPUTING DEVICE
`502
`
`ASSOCATING THE PLATFORM SPECIFIC
`COMMANDS WITH GENERC OPERATIONS
`504
`
`TRANSMITTING GENERIC OPERATIONS TO THE
`REQUESTING COMPUTING DEVICE
`506
`
`ASSOCATING THE GENERIC OPERATIONS WITH
`PLATFORM SPECIFIC COMMANDS OF THE
`REQUESTING COMPUTING DEVICE
`508
`
`Fig. 5
`
`6
`
`
`
`Patent Application Publication
`
`Oct. 1, 2009 Sheet 6 of 6
`
`US 2009/0248802 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`618
`622
`
`642
`
`MONITOR
`
`
`
`
`
`
`
`626
`
`WEO ADAPTER
`
`ADAPTER
`SYSTEM BUS
`
`REMOTE
`COMPUTING
`
`APPLICATION
`PROGRAMS
`
`
`
`
`
`OPERATING
`SYSTEM 627
`
`APPLICATION
`PROGRAMS628
`
`OTHER PROGRAM
`MODULES630
`
`PROGRAM
`DATA 632
`
`DATA MEDIA
`
`
`
`
`
`
`
`
`
`
`
`OPERATING Eg PROGRAMS-1
`
`
`
`MODULES
`
`
`
`DATA
`
`PRINTER
`
`MOUSE
`
`PROCESSING
`
`
`
`OTHER DEVICE(s)
`634
`
`KEYBOARD
`
`Fig. 6
`
`7
`
`
`
`US 2009/02488O2 A1
`
`Oct. 1, 2009
`
`SYSTEMIS AND METHODS FORMANAGING
`MULTIMEDIA OPERATIONS IN REMOTE
`SESSIONS
`
`BACKGROUND
`Remote session, which can include collaboration
`0001
`sessions can provide for a remoting experience between a
`local computer and a remote computer. Collaboration can
`involve recreating an appearance of a portion, or all, of the
`local computer's graphical user-interface on the remote com
`puter. The graphical user-interface can be recreated on the
`remote computer using one or more techniques, such as
`remoting. The collaboration sessions that are finally recreated
`on the remote computer can be governed by one or more
`parameters that may be associated with the portion of the
`local computer, being recreated at the remote computer.
`0002. A common example of a collaboration session can
`be operations relating to media operations for playing back
`multimedia files. Techniques for remoting Such sessions may
`involve transferring media data from the local computer to the
`remote computer. The media data may include data associ
`ated with the multimedia files that are intended to be played,
`processing data, rendering data, and so on. The multimedia
`files on the local computer, can be remotely played back on
`the remote computer by remoting media data to the remote
`computer. The media data, instead of being rendered onto the
`local computer, is rendered onto the remote computer.
`
`SUMMARY
`0003. This summary is provided to introduce concepts for
`managing multimedia operation in remote sessions. These
`concepts are further described below in the detailed descrip
`tion. This Summary is not intended to identify essential fea
`tures of the claimed subject matter, nor is it intended for use
`in determining the scope of the claimed Subject matter.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0004. The detailed description is described with reference
`to the accompanying figures. In the figures, the left most
`digit(s) of a reference number identifies the figure in which
`the reference number first appears. The same numbers are
`used throughout the drawings to reference like features and
`components.
`0005 FIG. 1 is a block diagram illustrating an exemplary
`network for managing multimedia operations in a collabora
`tive session.
`0006 FIG. 2 is a flow diagram illustrating the managing
`multimedia operations in a collaborative session in a com
`puter based network.
`0007 FIG. 3 is an exemplary illustration of mapping
`tables for managing multimedia operations in a collaborative
`session.
`0008 FIG. 4 is a block diagram illustrating one or more
`exemplary components of a media platform.
`0009 FIG. 5 is a flowchart illustrating an exemplary pro
`cess for managing multimedia operations in a collaborative
`session.
`0010 FIG. 6 is a block diagram illustrating an exemplary
`general computer environment.
`
`DETAILED DESCRIPTION
`0011. The methods and systems described below relate to
`collaboration sessions and handling media playback opera
`
`tions in collaboration sessions. Collaboration sessions can
`provide a remoting experience between a client computer
`(hereinafter, “client’) and a server computer (hereinafter,
`“server”). Collaboration can involve representing a portion,
`or all, of the server's graphical user-interface (GUI) on the
`client. In some collaboration scenarios, media operations,
`Such as media playback commands, can be handled sepa
`rately from the remainder of the GUI for various reasons. For
`instance, media playback commands can be handled sepa
`rately to conserve network bandwidth between the server and
`the client. In such cases, media can be redirected from the
`server to the client in an unprocessed or partially processed
`form. The client can then process the media and integrate the
`processed media with a remainder of the GUI to create a
`representation of the server GUI.
`0012 Media or media files can be stored according to
`different formats such as formats in conformance with
`MPEG, etc. among others. Processing the media files can be
`accomplished by a media player that employs one or more
`media platforms configured to handle the format of the media
`file. Media processing can involve media operations such as
`media playback commands. Such media operations can be
`platform specific. In a collaboration scenario, the client and
`server may or may not support the same media platforms. For
`example, media playback commands specific to a media plat
`form Supported on a server may be meaningless for a media
`platform Supported on the client.
`0013 The exemplary implementations can provide an
`abstraction functionality allowing media operations to be
`effectively conveyed in a collaboration session between
`server and client. For example, abstraction of the media
`operations can facilitate execution of a user's media playback
`command in a collaboration session. In Such cases, some
`implementations can translate a platform specific media play
`back command of the server into a generic media playback
`command. The generic media playback command can then be
`translated into a platform specific media playback command
`for a media platform supported on the client. The client can
`then execute the media playback command and integrate the
`results with the remainder of the GUI of the client.
`0014. In an implementation, the media is sent to the client
`for processing rather than being processed on the server, the
`platform specific commands can be intercepted at the server.
`As discussed, the server and the client may or may not have
`the same platforms. Accordingly, the server's platform spe
`cific commands may be not understood on the client. The
`present implementations can facilitate effective communica
`tion between the server and client such that the user's media
`playback commands are executable on the client independent
`of platforms employed on the server and client. For example,
`Some of the present implementations can translate the serv
`er's platform specific commands into generic media playback
`commands. The generic media playback commands can then
`be sent to the client. The client can convert the generic com
`mands into commands that are specific to a platform Sup
`ported by the client. The client's platform can then process the
`commands to achieve the desired effect (i.e., play, pause, stop,
`etc.) on the client device.
`Exemplary Systems
`(0015 FIG. 1 illustrates an exemplary system 100 for
`implementing collaboration sessions and to handle media
`operations in those collaboration sessions. The system 100
`can include a server 102 coupled to a client 104 via a network
`
`8
`
`
`
`US 2009/02488O2 A1
`
`Oct. 1, 2009
`
`106. A server desktop 110 can be displayed on server 102.
`Similarly, a client desktop 112 can be displayed on client 104.
`0016. The implementations described are in the context of
`a computing environment as commonly encountered at the
`present point in time. Various examples can be implemented
`by computer-executable instructions or code means, such as
`program modules, that are executed by a computer, Such as a
`personal computer or PC. Generally, program modules
`include routines, programs, objects, components, data struc
`tures, and the like, that perform particular tasks or implement
`particular abstract data types.
`0017 Various examples may be implemented in computer
`system configurations other than a PC. For example, various
`embodiments may be realized in hand-held devices, multi
`processor Systems, microprocessor-based or programmable
`consumer electronics, network PCs, minicomputers, main
`frame computers, cell phones and the like. Further, as tech
`nology continues to evolve, various implementations may be
`realized on yet to be identified classes of devices. For
`example, as the cost of a unit of processing power continues
`to drop and wireless technologies expand, computing devices
`resembling today's cell phones may perform the functional
`ities of today's PC, video camera, cell phone, and more in a
`single mobile device. This single device may in one scenario
`act as a server and in another scenario act as a client. This is
`but one of many existing and developing examples for the
`described implementations.
`0018 Various examples may be practiced in distributed
`computing environments, where tasks are performed by
`remote processing devices that are linked through a commu
`nications network. In a distributed computing environment,
`program modules may be located in both local and remote
`memory storage devices. Further, the terms server and client
`as used herein do not connotate any relative capabilities of the
`two devices. The client may have more, less, or equal pro
`cessing capabilities than the server. Rather, in this descrip
`tion, the names server and client describes the relative rela
`tionship of the two components. For example, a computing
`environment of a first or server device is remoted to a second
`or client device. For ease of explanation the examples pro
`vided in this document relate to a single server and a single
`client; however, this is but one potential configuration. It is to
`be appreciated that in other implementations may include one
`or more servers Supporting multiple clients. In some imple
`mentations a first computer may act as a server for a second
`computer, which acts as a server for a third computer.
`0019. As discussed, collaboration sessions can provide for
`a remoting experience between server 102 and client 104.
`Collaboration can involve representingaportion, or all, of the
`server's graphical user-interface (GUI) on the client. In this
`case, the GUI is represented as server desktop 110. In par
`ticular, collaboration can create the impression that one or
`more applications that are running on the server 102 are
`actually running on the client 104.
`0020 Examples of collaboration sessions can include
`remote terminal session scenarios and one or more presenta
`tion scenarios, among others. In a remote terminal session
`scenario, the GUI from the server's display area (e.g., server
`desktop 110) can be generated on the client 104 as represen
`tation or remote desktop 114. A presentation scenario can
`involve remoting a GUI of a particular application running on
`the server rather than the whole desktop 110. In such a sce
`nario, the server's GUI (e.g., a graphical window) of the
`application can be utilized for generating a representation of
`
`the application on the client. For example, server desktop 110
`includes a media player graphical window 116. A presenta
`tion session can generate a representation 118 on the client
`104 of graphical window 116 without the remainder of the
`server's desktop 110. Media processing can be accomplished
`on the server 102 by a media player 120 via a media platform
`122, stored on the server 102. Similarly, media processing can
`be accomplished on the client 104 by a media player 124 via
`a media platform 126, stored on the client 104.
`0021 AS discussed, most of the processes corresponding
`to the collaboration session can occur on the server 102;
`however, in the collaboration session, media operation can
`be, at least partially, processed on the client 104. For example,
`media playback commands can represent one or more types
`of media operations. Media playback commands generated
`by the user (i.e., user-commands) at the client 104 can be
`forwarded to the server 102 for processing. The server 102
`processes user-commands according to the configuration of
`the server 102. For example, the server 102 processes the
`user-commands based on the media platform 122. In Such a
`case, the processing of the user-commands can generate spe
`cific media playback commands based upon the user-com
`mands that are specific to the media platform 122.
`0022. The collaboration session can intercept the platform
`specific media playback commands and can send the com
`mands to the client for execution. In certain cases, the client's
`media platform 126, may not understand the media playback
`commands specific to the server's media platform 122. To this
`end, the system 100 can include a collaboration media
`abstraction layer 130 that can facilitate media-related com
`munications between the server 102 and client 104. For
`example, in the present example the collaboration media
`abstraction layer 130 can abstract or genericize the media
`playback commands specific to media platform 122. The
`genericized media playback commands can then be translated
`into media playback commands specific to the client's media
`platform 126.
`0023. Accordingly, the collaboration media abstraction
`layer 130 can facilitate execution of user-commands in a
`collaboration session. Furthermore, beyond the media play
`back command example, the collaboration media abstraction
`layer 130 can facilitate communicating media operations
`between the server 102 and the client 104 in a collaboration
`session.
`0024. In certain cases, the generic media playback com
`mands can be understood by the client 104 regardless of
`configuration differences of the server 102 and the client 104.
`For instance, the client 104 and the server 102 may have
`different operating systems, different versions of the same
`operating system, or different media platforms, among oth
`ers. The working of the system implementing managing mul
`timedia operations in a collaborative session is further
`described in detail in conjunction with FIG. 2 and FIG. 3.
`(0025 FIG. 2 shows a system 200 that builds upon the
`concepts introduced in relation to FIG. 1. In this case, the
`system 200 is described in relation to a remote terminal ses
`Sion. It is to be appreciated that similar concepts could be
`equally applicable to other collaboration sessions. In the
`present implementation, the system 200 includes a server 202
`and a client 204 that can communicate over a network 206.
`The server 202 includes a media platform 208 and a remote
`terminal session or "RTS’ media abstraction module 210.
`The client 204 includes a media platform 212 and a RTS
`media abstraction module 214.
`
`9
`
`
`
`US 2009/02488O2 A1
`
`Oct. 1, 2009
`
`0026. In this implementation, the server 202 can send data
`relating to server's desktop 216 to the client 204 for generat
`ing a remote representation, such as remote desktop 218, at
`the client 204. Data associated with the remote desktop 218
`can include a user-interface component 220 and a media
`component 222.
`0027. User-interface-component 220 can include graphics
`and images that typically compose a user-interface. User
`interface component 220 can include icons, host audio, back
`ground images and applications representations such as the
`GUI associated with word-processing applications, spread
`sheet applications, database applications, media applications,
`etc. Virtually any components that are not media component
`222 are part of user-interface component 220. When com
`pared to the media component 222, the user-interface com
`ponent 220 can be relatively static and relatively low data
`intensive. In contrast, the media component 222 may be rela
`tively dynamic and highly data intensive.
`0028. As discussed, media component 222 can be highly
`data intensive as they include media-rich elements that com
`pose a media presentation or media event. Transmission of
`data associated with the media component 222 can be band
`width-intensive. Examples of media component 222 include,
`but are not limited to, streaming media presentations includ
`ing a video and/or audio presentation, television broadcasts,
`such as a cable television (CATV), satellite, pay-per-view, or
`broadcast program; digitally compressed media experiences;
`radio programs; recorded media events (e.g., sourced by a
`VCR, DVD player, CD player, Personal Video Recorder and
`the like); real-time media events; and camera feeds, among
`others.
`0029. For purposes of explanation, media component 222
`is illustrated both on the server desktop 216 and on the client's
`remote desktop 218. It is to be appreciated that portions or the
`whole of the server desktop 216 may not necessarily be dis
`played on the display device of the server 202. In such imple
`mentations, the media component 222 (or a portion thereof)
`may only appear on the client. For instance, the server desk
`top can be remoted to the client even if the server is not
`connected to a display device.
`0030 The data for the remote desktop 218 can be sent
`from server 202 to client 204 over network 206. In an imple
`mentation, data associated with the user-interface component
`220 and the media component 222 can be transmitted over
`user-interface channel 224 and media channel 226 respec
`tively.
`0031. User-interface channel 224 can communicate user
`interface component 220 to client 204. In an implementation,
`Terminal Server and Terminal Client Services, offered by the
`Microsoft(R) Corporation of Redmond, Wash., can provide an
`exemplary user-interface channel 224. A remotable protocol
`can be used to transmit data through user-interface channel
`224. Exemplary protocols and data formats include, remote
`desktop protocols (RDP), the T-120 series protocol or HTML
`(hypertext markup language and its many variations), among
`others. Independent Computing Architecture (ICA) devel
`oped by Citrix(R) Systems offers another example that can
`Support remote terminal session.
`0032. The media channel 226 can be separate from, or
`integrated with, user-interface channel 224. The media chan
`nel 226 can be used to transmit bandwidth-intensive experi
`ences such as video and other media types as listed above. In
`this instance, the media channel 226 can provide a commu
`nication conduit for media component 222 to flow separately
`
`from user-interface component 220. Therefore, the media
`component 222 can be sent out of band with respect to the
`user-interface component, but synchronized. An exemplary
`protocol to transmit data through media component 226 can
`include, but is not limited to, Transmission Control Protocol
`(TCP), and a virtual channel over an RDP connection.
`0033. In other words, the present implementations can
`bifurcate data delivery relating to the remote desktop. Rela
`tively low data-intensive components of the server desktop
`216. Such as user-interface component 220, can be processed
`on the server 202 and then transmitted to the client 204.
`Relatively highly data-intensive components, such as media
`component 222, can be transmitted to the client 204 in an
`unprocessed or a less processed form. The processing can
`then be completed by the client 204, and combined with the
`low data intensive components to create the remote desktop
`218 at the client 204. Events (i.e., media operations) which
`affect the media presentation can be tracked at the server so
`that a relative relationship of the media presentation to other
`portions of the remote desktop 218 can be maintained.
`0034. In the present exemplary scenario, the user-interface
`component 220 is combined or united with the media com
`ponent 222 to generate the remote desktop 218 at the client
`204. A user at client 204 can remotely operate server 202 by
`interacting with remote desktop 218. For instance, the user at
`client 204 can move amouse cursor overan application on the
`remote desktop 218 and open an application by clicking on a
`corresponding icon. Likewise, the user can issue commands
`to an application through the remote desktop. For example, in
`relation to a media application, the user may utilize mouse
`clicks to issue user-commands Such as start playback (start),
`stop playback (stop), fast forward, rewind, pause, and set
`Volume, among others. The present implementations facili
`tate execution of the user-commands in the remote terminal
`session scenario.
`0035. For purposes of explanation consider a hypothetical
`scenario where a user at the client 204 enters user media
`playback commands (user-commands) relating to the remote
`desktop 218. The user-commands can be relayed from the
`client 204 to the server 202 as part of the remote terminal
`session via network 206 as indicated generally as commands
`230. The commands 230 can be sent over the UI channel 224
`or over a different channel. The commands 230 can be pro
`cessed on the server 202 by media platform 208 into platform
`specific media commands. As discussed, the media process
`ing of media platform 208 can be intercepted as part of the
`remote terminal session and sent to the client 204 for further
`processing.
`0036. The client's media platform 212 may or may not be
`the same as the server's media platform, such as media plat
`form 208, and as Such may or may not understand the inter
`cepted platform-specific media commands of the server 202.
`The server's RTS abstraction module 210 can receive the
`intercepted platform specific media commands. The RTS
`abstraction module 210 can translate the intercepted platform
`specific media commands into generic or abstracted media
`commands. The generic media commands can be sent from
`the server's RTS media abstraction module 210 to the client's
`RTS media abstraction module 214 as indicated generally as
`commands 232. The client's RTS media abstraction module
`214 can translate the generic media commands, such as com
`mands 232, into media commands that are specific to the
`client's media platform 212. The client's media platform 212
`can then execute the client specific media commands to
`
`10
`
`
`
`US 2009/02488O2 A1
`
`Oct. 1, 2009
`
`accomplish the user-command. A more detailed example for
`accomplishing the media command abstraction in a remote
`terminal session is described below in relation to FIG. 3.
`0037 FIG. 3 provides an example of how the system 200
`can accomplish the media operation abstraction described
`above in relation to FIG. 2. In this case, RTS media abstrac
`tion modules 210, 214 at the server 202 and the client 204
`respectively, accomplish the media operation abstraction by
`means of remote terminal session (RTS) mapping tables 302,
`304. For example, the server's RTS media abstraction module
`210 can receive media commands that are specific to the
`server's media platform 208. In an implementation, the com
`mands received by the server's RTS media abstraction mod
`ule 210 can be in response to one or more actions that may be
`specific to events associated with the playback of media files.
`For example, the server's RTS media abstraction module 210
`can receive commands when a media file is accessed for
`playback by one or more users at the client 204.
`0038. The server's RTS media abstraction module 210 can
`utilize RTS mapping table 302 to map the received media
`operations into generic or abstract media operations. The
`abstracted media operations from RTS mapping table 302 can
`be sent to the client's RTS media abstraction module 214. The
`client's RTS media abstraction module 214 can employ
`another RTS mapping table 304. The RTS mapping table 304
`can translate the abstracted media operations into media
`operations that are specific to the client's media platform 212.
`The client's media platform 212 can then execute the media
`operations.
`0039 For purposes of explanation, assume that the serv
`er's media platform 208 is a Media Foundation(R) platform,
`while the client's media platform 212 is a DShow(R) platform.
`In this example, RTS mapping table 302 can translate Media
`Foundation(R) platform specific operations designated gener
`ally at 306A-306I into corresponding generic media opera
`tions designated generally at 308A-308I, respectively. Simi
`larly, RTS mapping table 304 can translate generic media
`operations designated generally at 310A-310I into corre
`sponding DShow(R) platform specific operations designated
`generally at 312A-312I. For instance, assume that RTS media
`abstraction module 210 based on a Media Foundation plat
`form, receives an operation 306A, namely “IMFClockState
`Sink:OnClockStarted” from the media platform 208. The
`RTS media abstraction module 210 can utilize the mapping
`table 302 to translate the operation 306A into generic media
`operation command 308A, namely “StartPlayback’. The
`RTS media abstraction module 210 can send the generic
`media operation command “StartPlayback 308A to RTS
`Media abstraction module 214 on the client 204.
`0040. The generic media operation command, such as
`generic command 308A can be mapped onto a corresponding
`command of the client's media platform 212 based on the
`RTS mapping table 304. For instance, the RTS media abstrac
`tion module 214 can locate the generic media operation com
`mand “StartPlayback” received from the server 202 in the
`RTS mapping table 304. In this case, the generic media opera
`tion command “StartPlayback” is designated as 310A. The
`RTS mapping table 304 can translate the generic media opera
`tion command “StartPlayback”310 into a DShow(R) platform
`specific media operation “IMediaControl::Run” designated
`as command 312A. The RTS media abstraction module 214
`can send the DShow(R) platform specific media operation
`“IMFMediaSession::Start” 312A to the client platform 212,
`which is a DShow(R) platform, allowing the client’s platform
`
`212 to understand and execute the DShow specific media
`operation. Other mappings can be made by moving horizon
`tally across an individual row of the mapping tables 302,304.
`It is to be appreciated that the RTS mapping table 302,304 at
`the server 202 and the client 204 respectively, can include
`other commands and mappings associating platform specific
`commands to generic commands and vice versa.
`0041. In an implementation, the RTS mapping tables 302,
`304 can be configured to translate between yet to be devel
`oped media platforms. While the RTS mapping tables 302,
`304 illustrated herein include a translation between two spe
`cific media platforms, other mapping tables can include mul
`tiple translations. For example, the server's media platforms
`208 might be DShow and Media Foundation, while the cli
`ent's media platforms might be a QuickTime(R) platform and
`an Ogg R platform. Accordingly, in some implementations,
`the RTS mapping tables 302, 304 can provide translations
`between a server media platform and a client media platform.
`0042. Furthermore, by abstracting the media operations,
`the RTS mapping tables 302,304 can be simpler than other
`potential Solutions. For example, the server RTS mapping
`table 302 may not need to take into account all the possible
`media platforms that can be employed on the client 204. In
`other words, the server's media table, such as RTS mapping
`table 302 can be independent of the client's media platform
`212 (i.e., the server's media table does not need to be config
`ured based upon the client's media platform configuration).
`The same can be said of the client's media table 212. Further
`more, the server's RTS mapping table 302 may not need to be
`updated as new media platforms are developed that could be
`employed on the client 204. Instead, the server RTS mapping
`table 302 can translate media operations, such as operations
`306A-306I specific to whatever media platform(s) exists on
`the server 202 to the corresponding abstract or generic media
`operations, such 308A-308I. The client RTS mapping table
`304 can then translate the generic media operations. Such as
`308A-308 to media operations, such as operations 310A-310I
`specific to the media platform(s) 212 on the client 204. The
`client RTS mapping table 304 does not need to take into
`account all the different media platforms that are or may be
`employed on the server 202. Instead, the client RTS mapping
`table 304 can simply translate from generic media operations
`310A-310I to media operations specific to the media platform
`(s) 212 operating on the client 204.
`0043. The RTS mapping tables 302, 304 as illustrated
`represent but one possible implementation that can be accom
`plished utilizing a word processing document.
`0044 FIG. 4 is an exemplary representation of selective
`components of system 400 for Supporting media operation
`abstraction in a remote terminal session. FIG. 4 relates to a
`media component of a remote terminal session between a
`server 402 and a client 404. In this implementation, the ter
`minal services session entails a remote desktop protocol
`(RDP) configuration, examples of which are illustrated
`above. The system 400 can alternatively or additionally be
`utilized for other collaboration scenarios beyond remote ter
`minal sessions.
`0045 Server 400 can include a first media platform 406
`and a second media player 408. Media platform 406 is asso
`ciated with a media source 410. The media platform 406
`includes a geometry tracker module 412, an RTS media
`abstraction module 414, a destination module 416, and a
`distribution manager module 418 that includes an RTS media
`abstraction module 420. Media platform 406 also includes a
`
`11
`
`
`
`US 2009/02488O2 A1
`
`Oct. 1, 2009
`
`video decoder 422, a video effects module 424, a video ren
`derer 426, an RTS media abstraction module 428, an audio
`decoder 430, an audio effects module 432, an audio renderer
`434, an RTS media abstraction module 436, and an audio
`transmitter 438. The server also includes a media player 440
`that can communicate with the media platform 406.
`0046. The client's media platform 408 can include an RTS
`media abstraction module 442, a geometry tracking module