WO2017016568A1 - Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen - Google Patents

Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen Download PDF

Info

Publication number
WO2017016568A1
WO2017016568A1 PCT/EP2015/001535 EP2015001535W WO2017016568A1 WO 2017016568 A1 WO2017016568 A1 WO 2017016568A1 EP 2015001535 W EP2015001535 W EP 2015001535W WO 2017016568 A1 WO2017016568 A1 WO 2017016568A1
Authority
WO
WIPO (PCT)
Prior art keywords
gbx
hwgbx
null
params
video
Prior art date
Application number
PCT/EP2015/001535
Other languages
English (en)
French (fr)
Inventor
Frederik PETER
Sheikh KHALIL
Remco WESTERMANN
Original Assignee
Gorillabox Gmbh I. G.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gorillabox Gmbh I. G. filed Critical Gorillabox Gmbh I. G.
Priority to PCT/EP2015/001535 priority Critical patent/WO2017016568A1/de
Priority to KR1020187004544A priority patent/KR102203381B1/ko
Priority to US15/746,496 priority patent/US20180243651A1/en
Priority to EP15752917.3A priority patent/EP3325116A1/de
Priority to CN201580081901.0A priority patent/CN108136259B/zh
Publication of WO2017016568A1 publication Critical patent/WO2017016568A1/de
Priority to US17/000,878 priority patent/US20210069590A1/en

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/332—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using wireless networks, e.g. cellular phone networks
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/335—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using Internet
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/352—Details of game servers involving special game server arrangements, e.g. regional servers connected to a national server or a plurality of servers managing partitions of the game world
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/355—Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an encoded video stream for transmitting to a mobile phone or a thin client
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/358—Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • A63F13/49—Saving the game status; Pausing or ending the game
    • A63F13/493—Resuming a game, e.g. after pausing, malfunction or power failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Definitions

  • the invention relates to a method for streaming and reproducing applications (APPs).
  • APPs streaming and reproducing applications
  • the invention relates to a telecommunications network for streaming and replaying applications (APPs).
  • APPs streaming and replaying applications
  • the invention also relates to the use of a telecommunications network.
  • Web apps are applications that are developed for web browsers and are therefore usable on almost all platforms. Often a WCM system (web content management) is used for this purpose. However, these applications can only be accessed via a corresponding browser, which the platform must provide. The disadvantage of this method is that not all applications with This method can be ported. A browser must be used that does not always guarantee a native representation of the application.
  • WO 2009/073830 describes a system which offers the user access to a service on the basis of a "subscription fee", in which case the customer is assigned a specific streaming server for the booked period but our system instructs the user geographically optimal streaming server without a "subscription fee” is needed.
  • WO 2010/141522 A1 uses a game server, via which in part the streaming communication between the client and the streaming server takes place.
  • the functionalities of the Interactive Layer are mapped via the Video Source, which is handled in this development via a separate server to give third parties access to, for example, advertising space.
  • the invention has for its object to provide a method for streaming and playback of applications (APPs) on a particular telecommunications system and play non-native compatible applications in software-foreign environments.
  • APPs applications
  • Claim 1 describes a method for streaming and replaying applications (APPs) over a particular telecommunication system, in which one or more streaming servers communicate with each other by telecommunication can connect, run the application in question and communicate with the respective telecommunications terminal locally close, the relevant telecommunication terminal retrieves the required application (application) from a local server, the computer power for the rendering and coding of the application in question provides.
  • APPs streaming and replaying applications
  • the individual selection of a local streaming server reduces the latency between the streaming server and the client to a minimum, so that the greatest possible coverage is achieved with the greatest possible coverage, while the process works in a resource-efficient manner and the streaming server only then Provides, if this is needed.
  • claim 2 is a method for rendering applications on non-application system environments, which differ either by different hardware or software components, the streaming server handling the different applications as well as the rendering / encoding of the application and its audio and video signals, where the data is transmitted to the respective telecommunications terminal - mobile device, tablet, laptop, PC, TV - and the transmission is carried out using the modified h.254 protocol and the WAN as a means of transmission for audio / video packets via UDP / TCP is used and the full computer power of the respective Streaming server is adopted, wherein the packetized data are decoded only at the telecommunication terminal.
  • an ideal route for communication between the client and the streaming server can be selected at any time, regardless of the application.
  • Claim 3 describes a method for providing a platform-independent streaming technology that is once programmed and portable to any telecommunications terminal in which the streaming of the individual applications, for example video games, over a WAN, such that a) communication to the session server by means of the telecommunication terminal (small applications) is performed; b) a specific session is carried out for a specific end user for the telecommunications terminal's geographically closest streaming server of the relevant application, for example a game; c) session information is communicated by the relevant session server to the telecommunication terminal and the streaming server; d) a direct connection is made between the telecommunication terminal and the streaming server of the relevant application, for example a video game; e) when establishing a direct connection between the telecommunications terminal and the relevant streaming server, the following steps are initiated: i.
  • the method according to the invention makes it possible, according to the task, to play non-native programmed applications on software-external environments, without meeting the hardware-specific requirements of the foreign platforms, for example with regard to computer performance and graphics performance, and without fulfilling the software-specific prerequisites of the foreign platforms, for example Applications that only run on a specific operating system.
  • the invention uses a client created especially for this application. This client can be used on any platform to ensure a virtually latency-free playback of a h.254 compressed stream.
  • the h.254 code is used to transfer the frames.
  • H.264 / MPEG-4 AVC is an H. standard for high-efficiency video compression. In 2003 the standard was passed.
  • the ITU designation is H.264.
  • ISO / IEC MPEG the standard is called MPEG-4 / AVC (Advanced Video Coding) and is the tenth part of the MPEG-4 standard (MPEG-4 / Part 10, ISO / IEC 14496-10).
  • MPEG-4 / AVC Advanced Video Coding
  • MPEG-4 / Part 10 ISO / IEC 14496-10.
  • a resource handling is used, which distributes the load to individual streaming servers, in order to save on the one hand resources, on the other hand, however, also capacities / investments. This allows the system to operate more cost-effectively than comparable systems such as WO 2012/37170 A1. This also provides the option of switching off Streaming Server during operation in order to carry out maintenance work, for example.
  • the method according to the invention makes a hook superfluous and makes it possible to automate the method.
  • the client application basically consists of three parts (decode thread, render thread and the interactive layer) and is recorded in clientnetwork.so (shared library). These parts are divided into individual modules.
  • the Client Session Manager Module is responsible for the administration (start / stop) of the session and is used to administer the session started by the user. Settings for the latency optimization can also be made via this module.
  • the Network Module handles network communication and manages communication with the streaming server.
  • the controller module intercepts the user input of the application and transmits it to the game streaming server.
  • the Decoder Render Audio Module consists of two parts: The decoder module handles the decoding of the h.264 stream. The audio player plays the sound.
  • the Evaluator module sends a report to the Streaming Server.
  • the Recovery Module handles the actions of corrupt frame strategies.
  • the client Ul module is integrated in the interactive layer and is responsible for the UI of the application
  • the interactive layer makes it possible to visualize an additional visual representation of information on the underlying render thread, for example to display community feature / assistance or advertising. It lies above the render thread and can be customized by the user.
  • a predefined user interface is provided for each platform.
  • the user can use a so-called layer scripting to create the appropriate user interface under certain conditions.
  • Layer Scripting provides the user with a specially developed scripting environment, which enables certain functionalities to be linked to predefined buttons. This allows the user to customize his UI to suit their needs.
  • the streaming server basically consists of three modules (network thread, GPU thread and session handler) and is recorded in the servernetwork.dll (shared library). Each running application on the streaming server will be one each GPU and a network thread assigned. This automatic process is managed by the session handler.
  • the network thread is responsible for the delivery of the encoded audio and video file.
  • the GPU thread is responsible for hardware encoding of the application's audio and video frames, handles packet buffering via UDP / TCP and handles time stamping and compression.
  • the session handler is responsible for starting / stopping and managing the GPU & Network threads. It coordinates available resources on the Game Streaming Server and communicates with the Session Management Server. The idea behind the session handler is to manage resources automatically to save costs.
  • the Session Management Server consists of four modules: Authentication Module; Network modules; Session manager modules; Evaluator modules.
  • the authentication of the client is performed by the Access server in order to store the client specifications for the Streaming Server to check whether the client is authorized to retrieve the requested application.
  • the authenti- fication can also work with a data system, so that third-party systems can also be connected.
  • the Network Module is responsible for load balancing, quality assurance and administration.
  • Load balancing is the uniform distribution of the load within the network.
  • quality assurance each individual stream is monitored and optimized in terms of performance (for example, by means of a specific routing).
  • the administration should allow the administrator to view the current load and routing in order to carry out certain configurations.
  • the Session Manager Module is responsible for load optimization and control of the Game Streaming Server. This unit associates incoming client requests with free space on a game streaming server, and then establishes a direct connection between the client and the streaming server. Critical criteria for a join are: Latency between streaming server and application client and available resources. The aim is to establish a resource-saving process with this unit in order to be able to switch off unused power.
  • the Content Server handles the playback of advertising on the interactive layer of the corresponding client to the appropriate game. Advertising can be displayed in several forms. Either a permanent placement takes place within the application or certain times are predefined, which, as soon as these are triggered, set a corresponding trigger to play advertising.
  • UDP User Datagram Protocol
  • UDP User Datagram Protocol
  • the problem with UDP is that there is no mechanism for dealing with data packets that have been lost on the network. As a result, screen glitches, jerks and flickering occur while the game is played in the cloud.
  • Block User-side strategy that displays a still image while troubleshooting is taking place. This will allow the user a better user experience compared to screen errors, stuttering and flicker. Therefore, this method will ensure that the image is not corrupted in case of packet loss.
  • Non-blocking User-side strategy that does not generate a still image while requesting transmission of lost packets to the server. This retransmission is not comparable to TCP transmission because it is under our own control and we only request it efficiently when it is needed.
  • This strategy is implemented on the user side, it talks to the video encoder (on the server side) at runtime. In the case of loss of a packet, it requests the encoder to update the image. Therefore, once the image is broken due to loss of image packets, the image is applied in milliseconds to an image that the naked eye does not even notice.
  • Image Review This strategy keeps an eye on the frame rate at which images are sent from the server side. In the case of a fluctuating frame rate, it ensures that the image packets are sent at a constant frame rate. This helps to ensure an even picture experience.
  • a further inventive embodiment is described in claim 4, wherein in case of packet loss during transmission of files to the telecommunication nikationsend réelle, for example, from a game server to the telecommunications terminal, the following steps are performed: a) recovery strategy is called on telecommunications terminal (small) to maintain a smooth gaming experience; b) the appropriate recovery strategy is selected and c) the recovery request is sent back to the relevant streaming server of the application, for example the game.
  • Claim 6 describes a telecommunications network for reproducing applications on non-application system environments, which differ either by different hardware or software components, the streaming server, the handling of different applications and the rendering / coding of the application and its audio and Video signals are transmitted, whereby the data are transmitted to the respective telecommunication terminal - portable radio device, tablet, laptop, PC, TV - and the transmission is carried out by means of modified h.254-Protokoll and the WAN as transmission means for audio / video packages per UDP / TCP is used and the complete computer power is taken over by the relevant streaming server, the packetized data being decoded only at the telecommunication terminal.
  • the solution according to claim 7 describes a telecommunication network for providing a platform-independent streaming technology which is once programmed and portable to any telecommunication terminal in which the streaming of the individual applications, for example video games, is via a WAN such that a ) a communication to the session server by means of the telecommunication terminal (small applications) is performed; b) a specific session is carried out for a specific end user for the telecommunications terminal's geographically closest streaming server of the relevant application, for example a game; c) session information is communicated by the relevant session server to the telecommunication terminal and the streaming server; d) a direct connection is made between the telecommunication terminal and the streaming server of the relevant application, for example a video game; the following steps are taken when establishing a direct connection between the telecommunication terminal and the relevant streaming server: i.
  • Audio audio data of the running application for example a game, over the relevant streaming server of the game; II. Compression of audio video data by high quality hardware encoders; iii. Transmission of compressed audio A / ideo data via WAN; iv. Receiving the audio A / ideo data on the telecommunication terminal side; v. Decompress audio A / video data using vi. Receiving and reproducing the audio A / ideo data on the telecommunication terminal (small); vii. Recording the actions (inputs) of the user of the telecommunication terminal, for example a player, on the telecommunication terminal (small); viii. efficient transfer of the inputs back to the relevant streaming server of the game and ix. Playback of the transmitted inputs on Streaming Server.
  • Claim 8 describes the use of a telecommunication network for streaming and replaying applications (APPs) via a particular telecommunication system, in which one or more streaming servers that can communicate with each other by telecommunication execute the respective application and those with the respective telecommunication terminal close to connect locally, the telecommunications terminal in question the requested application (application) retrieves from a local server, which provides the computing power for the rendering and coding of the application in question.
  • APPs streaming and replaying applications
  • Claim 9 describes a solution for using a telecommunication network on non-application system environments that differ either in different hardware or software components, the streaming server handling the different applications as well as the rendering / encoding of the application and its audio - And video signals of the individual applications (frames) takes over, the data being transmitted to the respective telecommunications terminal - mobile device, tablet, laptop, PC, TV - and the transmission is carried out using the modified h.254 protocol and the WAN as a means of transmission for audio -A / ideo packets via UDP / TCP is used and the entire computer power is taken over by the relevant streaming server, the packetized data are decoded only at the telecommunication terminal.
  • Claim 10 describes the use of a telecommunications network for providing a platform-independent streaming technology, which is once programmed and portable to any telecommunications terminal, in which the streaming of the individual applications (applications), for example video games, via a WAN, such that a) a communication to the session server by means of the telecommunication terminal (small applications) is performed; b) a specific session is carried out for a specific end user for the telecommunications terminal's geographically closest streaming server of the relevant application, for example a game; c) session information is communicated by the relevant session server to the telecommunication terminal and the streaming server; d) a direct connection is made between the telecommunication terminal and the streaming server of the relevant application, for example a video game; e) when establishing a direct connection between the telecommunications terminal and the relevant streaming server, the following steps are initiated: i. Recording the audio / video data of the running application, for example a game, over the relevant streaming server on which the game is running. Compression of the audio
  • a further inventive embodiment with regard to the application is described in claim 11.
  • the following steps are performed: a) recovery strategies are invoked to maintain a smooth gaming experience; b) the appropriate recovery strategy is selected and c) the recovery request is sent back to the relevant streaming server of the application, for example the game.
  • Claim 12 shows the use of a telecommunications network for communication with a client (user, terminal) with the following source code:**************** ⁇ j ⁇ jp Q - ⁇ gy
  • Q Q jgg ⁇ jQ j ************************** *
  • AddPortAsync extends AsyncTask ⁇ void, void, void> ⁇
  • externalPort externalPort
  • uPnPPortMapper new UPnPPortMapper ();
  • internetGatewayDevices InternetGatewayDevice. getDevices (5000); ⁇
  • Claim 13 describes the use in connection with a telecommunication network according to the invention for the decoding of a video application and for the decoding of a terminal with the following source code:
  • Video Stats RTSP_VIDEOSTATE_SPS_RCVD;
  • Video Stats RTSP_VIDEOSTATE_PPS_RCVD;
  • Videostats! RTSP_VIDEOSTATE_PPS_RCVD) ⁇
  • gbx_contexttype gbx contextframetype, gbx_contextslicetype
  • Code snippets responsible for producing highly efficient compression technique that works in conjunction with the hardware to offer minimum latency at server end, which eventually results in real time gaming experience at end. It also contains server side of error handling strategy.
  • HANDLE gbx_hCaptureCompleteEvent [NUMFRAMESINFLIGHT]; HANDLE gbx_hFileWriterThreadHandle NULL;
  • memcpy timer, & pretv, sizeof (struct timeval)
  • HWGBXTransferRenderTargetToH264HWEncoder (params); gbx_dwFrameNumber ++;
  • hEvents [0] gbx_hThreadQuitEvent
  • hEvents [1] gbx_hCaptureCompleteEvent [bufferlndex];
  • hEvents [0] gbx_hThreadQuitEvent
  • bufferlndex (bufferlndex + 1)% NUMFRAMESINFLIGHT
  • bufferlndex (bufferlndex + 1)% NUMFRAMESINFI_IGHT;
  • bufferlndex (bufferlndex + 1)% NUMFRAMESINFLIGHT
  • gbx_plFR (HWGBXToH264HWEncoder *) HWGBXLib.create (gbx_pD3DDevice,
  • gbx_hThreadQuitEvent CreateEvent (NULL, TRUE, FALSE, NULL);
  • HWGBX_H264HWEncoder_Config encodeConfig ⁇ 0 ⁇
  • encodeConfig.eRateControl HWGBX_H264_ENC_PARAMS__RC_CONSTQP; ll ⁇ HWG BX_H264_E NC PARAM FLAG bx_FO RC E I DR;
  • encodeConfig.ePresetConfig HWGBX_H264_PRESET_LOSSLESS_HP;
  • HWGBX_SETUP_H264_PARAMS params ⁇ 0 ⁇ ;
  • ppPageLockedBitStreamBuffers gbx_pMainBuffer
  • ppEncodeCompletionEvents gbx_hCaptureCompleteEvent
  • HWGBXRESULT res HWGBX_SUCCESS
  • long long frame_interval 1000000 / video_fps
  • BOOL bRet HWGBX_CopyFromSharedSurface_fn (encodeDevice, gbx_hlFRSharedSurface, pRenderTarget);
  • HWGBX_TRANSFER_RT_TO_H264_PARAMS params ⁇ 0 ⁇ ;
  • sleep_delta frame_interval tvdiff_
  • h264HeaderParams.pSize (NvU32 * ) &dwSize;
  • HWGBXRESULT result HWGBX_SUCCESS
  • gbx_ioctl_buffer_t * buf (gbx_ioctl_buffer_t *) arg;
  • 1 is a block diagram schematically showing the relationships between the individual areas and the streaming server
  • Fig. 2 is a block diagram of the Game Package Module; a block diagram of the session management server;
  • 4 is a block diagram of the mobile interactive layer for the client; 5 is a block diagram showing a flowchart of the client's recovery module;
  • FIG. 6 Mobile Interactive Layer - Exemplary visualization of the surface of a mobile terminal.
  • Fig. 7 Recovery Strategy Process in case of loss of a data packet.
  • Fig. 1 shows the individual elements required in the communication.
  • the streaming server 120 takes over the initialization of the application and lets it start in a virtual environment.
  • the streaming server 120 has a game isolation module 140.
  • an application-friendly environment is started, which on the one hand ensures the operability of the application, but is also responsible for the playback of the control signals of the client 110A.
  • the streaming server can start any number of instances of the same or different application. The limiting factor in this regard is the processing power of the GPU in graphical applications.
  • Each started application is assigned a Game DB 180. This Game DB 180 is responsible for storing relevant data for the application. However, to start an application, it must first be available to Game Package Manager 180 as Game Package 170.
  • the network module 150 of the streaming server 120 transmits then takes the encoding and packaging of the frames. Another task of the Network Module 150 is the handling of client 110A recovery requests. In order to carry out administrative interventions and evaluations, the Evaluator Module 190 was developed. This module is responsible for generating statistics.
  • the client serves as a thin client for the transmission of AudioA / ideo signals and can typically be used on any platform.
  • a streaming server 120 may enter into a 1: n relationship, however, a client may only record communications to a particular streaming server 120.
  • the number of clients per streaming server is not limited by the software, but by the corresponding hardware capacities of the streaming server 120 GPU.
  • Communication between streaming server 120 and client 110A is always established initially via session management server 130.
  • the latter accepts the client 110A's initial request to connect to the streaming server and searches for the optimal streaming server 120 for the client 110A.
  • multiple streaming servers can operate in parallel. These do not always have to be in the same data center or country.
  • the streaming server 120 takes over the direct communication with the client 110A.
  • This server is responsible for the delivery of certain parts in the interactive layer of the client 110A. This controls, among other things, the playback of advertising according to the application that is played on the thin client. The necessary information is made available to the content server 195 via the session management server 130.
  • the communication takes place primarily via the WAN (Wide Area Network) 115. This includes various types of transmission and is not limited to specific areas.
  • WAN Wide Area Network
  • FIG. 2 shows the game package module 160, which is part of the streaming server 120.
  • the Game Package Module 160 is initially started for each new application and handles six subareas for the application.
  • Capture Encode Audio 210 is divided into Capture 210A and Encode 210 B sections, which are responsible for capturing the audio signal.
  • the Capture Encode Video area 220 is divided into the same areas as the Audio Module 210.
  • the Port Authentication Module 230 handles the port authentication and corresponds to providing the connection between the Game Stream Server 120 and the Client 110A.
  • the Control Re- lay 240 is responsible for XXX.
  • the task of the Network Relay 250 is to send the appropriate packets and to manage incoming packets.
  • the recovery module 260 is responsible for responding to the corresponding recovery requests from the client 110A.
  • FIG. 3 is concerned with the session management server 130. It has the task of authenticating 310 and, with the aid of a downstream DB module 315, its task of storing or storing the data used for authentication. However, this DB module 315 is only optional. The possibility of external authentication remains unaffected.
  • the Network 320 area is responsible for communication between WAN 115, Streaming Server 120, Content Server 195, and the respective clients.
  • the session manager 330 is then significantly responsible for managing the individual sessions and takes over the assignment of the clients to a corresponding streaming server.
  • the Evaluator module has a direct connection to the individual clients and collects relevant data for later central evaluation.
  • Client Session Manager 410 communicates with the streaming server 120 and the session management server and is initially responsible for the authentication and management of the client.
  • Network Module 420 is responsible for establishing the connection and maintaining it. This module also handles the sending and receiving of various packages.
  • the controller 430 handles the delivery of the delivered frames and audio packets as a visual image in the client.
  • Decode Render Video 440 and Decode Render Audio 450 receive the packets previously received from network module 420 and forwarded by controller 430.
  • the Elevator Module 460 is responsible for collecting statistical data and transmits it to the Session Management Server. Accordingly, the Session Management Server can also optimize the connection. This creates a feedback that makes this module very important.
  • the Recovery Module 470 evaluates incoming data packets. If a data packet is faulty, the module selects a recovery strategy and, if necessary, requests from Streaming Server a new package or take other measures to compensate for the loss, without losing a latency or quality.
  • the client Ul includes the interactive layer and content of the content server 195. There, the input of the user is intercepted and sent to the streaming server 120.
  • FIG. 5 shows the structure of the content server. He is responsible for Content Administration 510 and Content Streaming 520.
  • the content administration serves to preset the e.g. advertisement to be displayed within the interactive layer in the client 110.
  • the content administration 510 is to determine both the frequency and the content.
  • the content streaming module 520 takes over the content and serves as a central interface for all clients.
  • FIG. 6 illustrates the Interactive Layer 600 because it is part of the client Ul 480. Basically, a distinction is made between three different areas.
  • the application layer 610 reflects the received frames and is responsible for the visual presentation of the application.
  • the Ul Layer 620 Above the Application Layer 610 is the Ul Layer 620. This layer can be configured individually, but is fundamentally responsible for the input of the user in the client.
  • FIG. 7 shows the course of the recovery strategy of the client 110 in the module 470. As soon as a "package loss" has been detected 710 on the client side, the recovery module will select a corresponding solution based on firmly defined criteria 720.
  • the recovery request 770 is sent to the Streaming Server 120.
  • the streaming server sends accordingly a new package and the task of the recovery module 470 has been fulfilled.
  • a client German "customer”, also called client-side application or client application.
  • Client is a computer program that runs on a terminal of a network and communicates with a central server.
  • controller module decode thread decoding application decoder render decoding exporter evaluator evaluation unit evaluator module evaluation module frame validation frame reviser interactive layer interactive level intrarefresh interior updating loadbalancing load sharing network modules network module not blocking not blocking overlay Overlay packaging Packaging Recovery Module Recovery Module Recovery Strategies Recovery Strategy
  • Visualization exporter is for rendering

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem und ein Telekommunikationsnetz sowie die Verwendung eines Telekommunikationsnetzes zum Streamen und zur Wiedergabe derartiger Anwendungen (APPs). Das erfindungsgemäße Verfahren ermöglicht es, nicht nativ programmierte Anwendungen auf softwarefremden Umgebungen abzuspielen, und zwar ohne die hardwarespezifischen Voraussetzungen der fremden Plattformen zu erfüllen, zum Beispiel hinsichtlich Rechner- und Grafikleistung, und ohne die softwarespezifischen Voraussetzungen der fremden Plattformen zu erfüllen, zum Beispiel Anwendungen, die nur über ein bestimmtes Betriebssystem laufen.

Description

VERFAHREN UND TELEKOMMUNIKATIONSNETZ ZUM STREAMEN UND ZUR
WIEDERGABE VON ANWENDUNGEN
Beschreibung
Gattung
Die Erfindung betrifft ein Verfahren zum Streamen und zur Wiedergabe von Anwendungen (APPs).
Des Weiteren betrifft die Erfindung ein Telekommunikationsnetz zum Streamen und zur Wiedergebe von Anwendungen (APPs).
Schließlich betrifft die Erfindung auch die Verwendung eines Telekommunikationsnetzes. Stand der Technik
Heutzutage ist es immer wichtiger, Anwendungen nativ zu entwickeln. Native Entwicklungen sind jedoch immer individuell an eine bestimmte Plattform angepasst. Problematisch ist es jedoch, dass immer neuere und modernere Plattformen auf den Markt kommen und Nutzer nicht nur eine Plattform, sondern viele verschiedene Plattformen nutzen.
Ein weiteres Problem ist die dahinter liegende Hardware. Spezifische Anwendungen liegen auch spezifischer Hardware zugrunde. Diese Hardware hat bestimmte Anforderungen an die Anwendung zu erfüllen, zum Beispiel Grafik-Last, Prozessor-Kapazität, Speicher, Energieverbrauch. Umgekehrt kann aber auch eine Anwendung mehr Rechenleistung oder Grafikleistung beanspruchen, als die Hardware der Plattform zur Verfügung stellen kann. Dies kann speziell bei grafikintensiven Anwendungen - zum Beispiel Spiele - dazu führen, dass Anwender diese nicht nutzen können, da das System inkompatibel ist. Grundsätzlich gibt es drei verschiedene Ansätze, Anwendungen auf eine plattformfremde Umgebung zu übertragen.
Zunächst gibt es die sogenannte native Entwicklung (Portierung). Die Anwendung wird unter Gesichtspunkten der fremden Plattform neu entwickelt. Dies ist von allen drei Methoden der komplexeste und zeitintensivste Weg, jedoch bietet dieser die Möglichkeit, alle Funktionalitäten der neuen Plattform zu nutzen. Ein Problem dieser Methode ist jedoch, dass die Anwendung den Rahmenbedingungen der Plattform unterliegt. So können zum Beispiel Spiele mit hohen Grafikanforderungen nicht auf eine mobile Plattform portiert werden. Auch stellen unterschiedliche Hardware-Voraussetzungen innerhalb der fremden Plattform ein Problem dar, da zum Beispiel nicht jeder Anwender dasselbe Mobilfunkgerät hat.
Ergänzend dazu existiert bereits Software, die es dem Entwickler ermöglichen soll, eine native Entwicklung leichter zu gestalten. Eine Portierung findet unter Verwendung bestimmter Software dahingehend statt, dass Teile der existierenden Software ersetzt werden, um so eine Kompatibilität zu dem Fremdsystem zu erreichen. Dieser Schritt ist nicht immer möglich, da einige Plattformen sich zu sehr architektonisch voneinander unterscheiden. Auch fehlt in solchen Fällen meistens der Support des Betreibers der Plattform, aus diesem Grund wird meistens auf die native Entwicklung zurückgegriffen.
Web-Apps sind Anwendungen, welche für Webbrowser basiert entwickelt werden und dadurch auf fast allen Plattformen zu nutzen sind. Hierzu wird auch oft ein WCM- System (Webcontent Management) genutzt. Jedoch sind diese Anwendungen nur über einen entsprechenden Browser zu erreichen, den die Plattform zur Verfügung stellen muss. Nachteilig bei dieser Methode ist, dass nicht alle Anwendungen mit dieser Methode portiert werden können. Es muss ein Browser genutzt werden, der eine native Darstellung der Anwendung nicht immer gewährleistet.
Streaming: Dies bedeutet, dass die Anwendung auf einem Server läuft und auf der Fremdplattform mithilfe eines Clients nur abgespielt wird. Diese Technologie ist aktuell jedoch beschränkt auf bestimmte Anwendungen, die nicht zeitkritisch sind (Stichwort hier ist„Latenz").
Durch die WO 2012/037170 A1 ist es bekannt, parallel zum Stream den Application Code auf den Client zu übertragen, um, sobald die Applikation auf dem Client lauffähig ist, den Stream beenden zu können, so dass die Applikation direkt auf dem Client läuft, um so Streaming-Ressourcen einsparen zu können. Dies kann für zum Beispiel Konsolen interessant sein, ist aber bei hardwarespezifischen Voraussetzungen (Limitierungen) nicht möglich.
In WO 2009/073830 wird ein System beschrieben, das auf Basis einer„Subscription Fee" dem User Zugriff auf einen Service bietet. In diesem Fall wird dem Kunden ein bestimmter Streaming-Server für den gebuchten Zeitraum zugewiesen. Unser System weist dem User jedoch ein geographisch optimalen Streaming-Server zu, ohne dass eine„Subscription Fee" benötigt wird. Ergänzend dazu verwendet die WO 2010/141522 A1 einen Game Server, über den teilweise die Streaming-Kommunikation zwischen Client und Streaming Server stattfindet. Des Weiteren werden die Funktionalitäten der Interactive Layer über die Video Source abgebildet, die bei dieser Entwicklung über einen separaten Server abgehandelt wird, um auch Dritten Zugriff auf zum Beispiel Werbeflächen zu geben.
Aufgabe
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Streamen und Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem zu schaffen und nicht nativ kompatible Anwendungen auf softwarefremden Umgebungen abzuspielen.
Lösung
Diese Aufgabe wird durch jeden der nebengeordneten Patentansprüche 1 bis 3 gelöst.
Patentanspruch 1 beschreibt ein Verfahren zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem, bei welchem ein oder mehrere Streaming-Server, die durch Telekommunikation miteinander in Verbindung treten können, die betreffende Anwendung ausführen und die mit dem jeweiligen Telekommunikationsendgerät ortsnah in Verbindung treten, wobei das betreffende Telekommunikationsendgerät die verlangte Anwendung (Applikation) von einem ortsnahen Server abruft, der die Rechnerleistung für das Rendering und die Kodierung der betreffenden Anwendung zur Verfügung stellt.
Vorteil: Durch die individuelle Selektierung eines ortsnahen Streaming-Servers wird die Latenz zwischen Streaming-Server und Client auf ein Minimum reduziert, so dass eine größtmögliche Reichweite mit einer größtmöglichen Abdeckung erreicht wird, während das Verfahren ressourcenschonend arbeitet und den Streaming-Server erst dann zu Verfügung stellt, wenn dieser benötigt wird.
In Patentanspruch 2 ist ein Verfahren zur Wiedergabe von Anwendungen auf anwendungsfremden System-Umgebungen, die sich entweder durch unterschiedliche Hardware- oder Software-Komponenten unterscheiden, wobei der Streaming-Server das Handling der unterschiedlichen Anwendungen sowie das Rendering/Kodierung der Applikation und dessen Audio- und Videosignale übernimmt, wobei die Daten an das jeweilige Telekommunikationsendgerät - Mobilfunkgerät, Tablet, Laptop, PC, TV - übertragen werden und die Übertragung mittels modifiziertem h.254-Protokoll durchgeführt wird und das WAN als Übertragungsmittel für Audio-/Video-Pakete per UDP/TCP verwendet wird und die komplette Rechnerleistung von dem betreffenden Streaming-Server übernommen wird, wobei die paketierten Daten nur bei dem Telekommunikationsendgerät dekodiert werden.
Vorteil: Durch die Standardisierung der Kommunikation kann unabhängig von der Anwendung zu jedem beliebigen Zeitpunkt eine ideale Route zwecks Kommunikation zwischen Client und Streaming-Server gewählt werden.
Patentanspruch 3 beschreibt ein Verfahren zum Bereitstellen einer plattformunabhängigen Streaming-Technologie, die einmal programmiert und auf beliebige Telekommunikationsendgeräte portierbar ist, bei welchem das Streamen der einzelnen Anwendungen (Applikationen), zum Beispiel Videospiele, über ein WAN erfolgt, derart, dass a) eine Kommunikation zum Session-Server mittels des Telekommunikationsendgerätes (Klein-Applikationen) durchgeführt wird; b) eine bestimmte Session für einen bestimmten Endabnehmer für das zum Telekommunikationsendgerät geographisch nächstliegenden Streaming-Server der betreffenden Applikation, zum Beispiel eines Spiels, durchgeführt wird; c) Session-Informationen durch den betreffenden Session-Server dem Telekommunikationsendgerät und dem Streaming-Server mitgeteilt werden; d) eine direkte Verbindung zwischen dem Telekommunikationsendgerät und dem Streaming-Server der betreffenden Applikation, zum Beispiel eines Videospiels, durchgeführt wird; e) bei der Herstellung einer unmittelbaren Verbindung zwischen dem Telekommunikationsendgerät und dem betreffenden Streaming-Server folgende Schritte eingeleitet werden: i. Aufzeichnung der Audio-/Video-Daten der laufenden Applikation, zum Beispiel eines Spiels, über den betreffenden Streaming-Server auf dem das Spiel läuft. ii. Komprimierung der Audio-A/ideo-Daten durch hochwertige Hardware- Kodierer; iii. Übertragung der komprimierten Audio-A ideo-Daten über WAN; iv. Empfang der Audio-A ideo-Daten auf Seiten des Telekommunikationsendgerätes; v. Dekomprimierung der Audio-A/ideo-Daten vi. Visualisierung der Audio-A/ideo-Daten auf dem Telekommunikationsendgerät (klein); vii. Aufzeichnung der Aktionen (Eingaben) des Benutzers des Telekommunikationsendgerätes, zum Beispiel eines Spielers, auf dem Telekommunikationsendgerät (klein); viii. effiziente Übertragung der Eingaben zurück zu dem betreffenden Streaming-Server des Spiels und ix. Wiedergabe der übertragenen Eingaben auf Streaming Server.
Einige Vorteile
Das erfindungsgemäße Verfahren ermöglicht es gemäß der Aufgabenstellung, nicht nativ programmierte Anwendungen auf softwarefremden Umgebungen abzuspielen, und zwar ohne die hardwarespezifischen Voraussetzungen der fremden Plattformen zu erfüllen, zum Beispiel hinsichtlich Rechnerleistung und Grafikleistung, und ohne die softwarespezifischen Voraussetzungen der fremden Plattformen zu erfüllen, zum Beispiel Anwendungen, die nur über ein bestimmtes Betriebssystem laufen. Im Ver- gleich zu zum Beispiel US 2014/0073428 A1 verwendet die Erfindung einen eigens für diese Anwendung erstellten Client. Dieser Client kann auf jeder beliebigen Plattform genutzt werden, um eine nahezu latenzfreie Wiedergabe eines h.254 komprimierten Streams zu gewährleisten. Für das Transferieren der Frames wird der h.254 Code verwendet. H.264/MPEG-4 AVC ist ein H. -Standard zur hocheffizienten Videokompression. Im Jahr 2003 wurde der Standard verabschiedet. Die ITU-Bezeichnung lautet dabei H.264. Bei ISO/IEC MPEG läuft der Standard unter der Bezeichnung MPEG-4/AVC (Advanced Video Coding) und ist der zehnte Teil des MPEG-4-Stan- dards (MPEG-4/Part 10, ISO/IEC 14496-10). Bei dem erfindungsgemäßen Verfahren wird des Weiteren ein Ressourcen-Handling eingesetzt, das die Last auf einzelne Streaming Server verteilt, um zum einen Ressourcen, zum anderen aber auch Kapazitäten/Investitionen einzusparen. Dies ermöglicht es dem System, kostensparender zu arbeiten als vergleichbare Systeme wie zum Beispiel bei WO 2012/37170 A1. Auch bietet dies die Möglichkeit, im laufenden Betrieb Streaming Server abzuschalten, um zum Beispiel Wartungsarbeiten durchzuführen. Allgemein ist bekannt, dass in fast allen Fällen, wie zum Beispiel in der WO 2010/141522 A1 , immer ein sogenannter Hook in den Code der Applikation initiiert werden muss, um dem Streaming Server zu ermöglichen, die Applikation zu streamen. Dies hat zur Folge, dass der Application-Code verändert werden muss, was zum einen zu Mehraufwand, zum anderen jedoch zu erheblichen Problemen mit dem ursprünglichen Entwickler der Applikation führen kann. Das erfindungsgemäße Verfahren macht einen Hook überflüssig und ermöglicht es, das Verfahren zu automatisieren. Die Client-Application besteht grundsätzlich aus drei Teilen (decode thread, render thread und der interactive layer) und wird in der clientnetwork.so (shared library) festgehalten. Diese Teile gliedern sich in einzelne Module.
Das Client-Session Manager Module ist für die Verwaltung (starten/beenden) der Session verantwortlich und dient der Administrierung der vom User gestarteten Session. Über dieses Modul können auch Einstellungen bezüglich der Latenz-Optimie- rung vorgenommen werden.
Das Network Module übernimmt die Netzwerk Kommunikation und verwaltet die Kommunikation mit dem Streaming Server.
Das Controller Module fängt den User-Input der Anwendung ab und übermittelt diese dem Game Streaming Server.
Das Decoder-Render Audio Module besteht aus zwei Teilen: Das Decoder Modul übernimmt die Dekodierung des h.264 Streams. Der Audio-Player spielt den Sound aus.
Das Evaluator Modul übermittelt an den Streaming Server ein Reporting. Das Recovery Module übernimmt das Handeln der Strategien für korrupte Frames.
Das Client Ul Module ist in den interactive layer eingebunden und ist für die Ul der Applikation verantwortlich
Der interactive layer ermöglicht es eine zusätzliche visuelle Darstellung von Informationen auf dem darunterliegenden render thread zu visualisieren, um zum Beispiel Community Feature/Hilfestellungen oder Werbung anzuzeigen. Sie liegt über dem render thread und kann von dem Anwender individuell angepasst werden.
Für den interactive layer wird für jede Plattform eine vordefinierte Benutzeroberfläche zur Verfügung gestellt. Der User kann jedoch über ein sogenanntes layer Scripting sich die entsprechende Benutzeroberfläche, unter bestimmten Rahmenbedingungen, selbst erstellen. Layer Scripting stellt dem Anwender eine eigens entwickelte Scripting Umgebung zur Verfügung, die es ermöglicht bestimmte Funktionalitäten an vordefinierte Buttons zu binden. So kann der Anwender seine Ul individuell an deren Bedürfnisse anpassen.
Der Streaming Server besteht aus grundsätzlich drei Modulen (network thread, GPU thread und session handler) und wird in der servernetwork.dll (shared library) festgehalten. Jeder laufenden Applikation auf dem Streaming Server wird jeweils ein GPU und ein network thread zugewiesen. Verwaltet wird dieser automatische Pro- zess von dem Session handler.
Der network thread ist für die Auslieferung der codierten Audio und Video Datei verantwortlich.
Der GPU thread ist für das Hardware encoding der Audio und Video frames der Anwendung verantwortlich, übernimmt das packet Buffering via UDP/TCP und übernimmt das timestamping und die Komprimierung.
Der Session handler ist verantwortlich für das Starten/Stoppen und Verwalten der GPU & Network threads. Er koordiniert verfügbare Ressourcen auf dem Game Streaming Server und kommuniziert mit dem Session Management Server. Die Idee hinter dem Session handler ist eine automatische Verwaltung der Ressourcen, um Kosten sparen zu können.
Der Session Management Server besteht aus vier Modulen: Authentication Module; Network Module; Session Manager Module; Evaluator Module.
Die Authentifizierung des Clients übernimmt der Access-Server, um zum einen die Clientspezifikationen für den Streaming Server zu hinterlegen, um zu überprüfen, ob der Client dazu berechtigt ist, die angeforderte Anwendung abzurufen. Die Authenti- fizierung kann auch mit einem Dhttsystem gegenüber funktionieren, so dass auch Fremdsysteme angekoppelt werden können.
Das Network Module ist für das Loadbalancing, Qualitätssicherung und Administration verantwortlich. Unter Loadbalancing wird die gleichmäßige Verteilung der Last innerhalb des Netzwerkes verstanden. Im Bereich Qualitätssicherung wird jeder einzelne Stream überwacht und performanceabhängig optimiert (zum Beispiel durch ein bestimmtes Routing) Die Administration soll es dem Administrator ermöglichen Einsicht ihn die aktuelle Last und in das Routing zu nehmen, um bestimmte Konfigurationen vorzunehmen.
Das Session Manager Module ist für die Lastoptimierung und Kontrolle der Game Streaming Server verantwortlich. Diese Einheit verknüpft eingehende Client Anfragen mit einem freien Platz auf einem Game Streaming Server und stellt danach eine direkte Verbindung zwischen Client und Streaming Server her. Entscheidende Kriterien für eine Verknüpfung sind: Latenz zwischen Streaming Server und Applikation Client und verfügbaren Ressourcen. Ziel ist es mit dieser Einheit ein ressourcenschonendes Verfahren zu etablieren, um nicht genutzte Leistung abschalten zu können.
Evaluator Module. Dieser übernimmt das Generieren der Statistiken und Administration. Der Content Server übernimmt das Ausspielen von Werbung auf der interactive Layer des entsprechenden Clients zu dem passenden Spiel. Werbung kann in mehreren Formen angezeigt werden. Entweder findet eine permanente Platzierung innerhalb der Applikation statt oder es werden bestimmte Zeitpunkte vordefiniert, die sobald diese ausgelöst werden, einen entsprechenden Trigger setzen um Werbung auszuspielen.
UDP (User Datagram Protocol, dt. Nutzer Datenpakete Protokoll) ist einfach, weniger aufwändig und effizienter für Echtzeit-Datenübertragungen. Das Problem mit UDP liegt allerdings darin, dass es keinen Mechanismus für den Umgang mit Datenpaketen gibt, die im Netzwerk verloren gegangen sind. Daher treten Bildschirmfehler, Ruckler und Flimmern auf, während das Spiel in der Cloud gespielt wird.
Wir haben vier Strategien bestimmt, die intelligent die Paketverlust-Situation korrigieren werden.
Blockieren: Strategie auf der Nutzerseite bei der ein Standbild gezeigt wird während die Fehlerbehebung stattfindet. Dies wird dem Nutzer eine bessere Nutzererfahrung im Vergleich zu Bildschirmfehlern, Ruckler und Flimmern ermöglichen. Daher wird diese Methode sicherstellen, dass das Bild im Falle von Paketverlust nicht fehlerhaft ist. Nicht-Blockieren: Strategie auf der Nutzerseite bei der kein Standbild erzeugt wird während eine Übertragung der verlorenen Pakete beim Server angefragt wird. Diese erneute Übertragung ist nicht mit der TCP Übertragung vergleichbar, da sie in unserer eigenen Kontrolle liegt und wir sie effizient nur anfragen, wenn sie benötigt wird.
Innere Aktualisierung: Diese Strategie ist auf der Nutzerseite implementiert, sie spricht mit dem Videokodierer (auf Serverseite) in Laufzeit. Im Falle des Verlusts eines Pakets fordert sie den Kodierer auf, eine Bildaktualisierung vorzunehmen. Daher wird auf das Bild, sobald es aufgrund eines Verlusts von Bild-Paketen unterbrochen ist, in Millisekunden eine Bildaktualisierung angewandt, die das bloße Auge nicht einmal bemerkt.
Bild Überprüfung: Diese Strategie behält ein Auge auf die Bildrate bei der Bilder von der Serverseite gesendet werden. Im Falle einer schwankenden Bildrate stellt sie sicher, dass die Bildpakete mit einer konstanten Bildrate gesendet werden. Dies hilft dabei eine gleichmäßige Bilderfahrung zu gewährleisten.
Weitere erfinderische Ausgestaltungen
Eine weitere erfinderische Ausgestaltung ist in Patentanspruch 4 beschrieben, bei welcher bei Paketverlust während der Übertragung von Dateien auf das Telekommu- nikationsendgerät, zum Beispiel von einem Spiele-Server zum Telekommunikationsendgerät, folgende Schritte durchgeführt werden: a) Wiederherstellungsstrategie wird auf Telekommunikationsendgerät (klein) aufgerufen, um eine reibungslose Spieleerfahrung aufrechtzuerhalten; b) die geeignete Wiederherstellungsstrategie wird ausgewählt und c) die Wiederherstellungsanfrage wird zu dem betreffenden Streaming-Server der Applikation, zum Beispiel des Spiels, zurückgesendet.
Vorteil: Durch das Automatisieren des Wiederherstellungsprozesses reduziert sich die Dauer von eintretenden Fehlern um ein Vielfaches und ermöglicht so eine nahezu fehlerfreie sich selbst kontinuierlich kalibrierende Übertragung zwischen Streaming-Server und Client.
Lösung der Aufgabe betreffend das Telekommunikationsnetz
Diese Aufgabe wird durch der nebengeordneten Patentansprüche 5 bis 7 gelöst. In Patentanspruch 5 ist ein Telekommunikationsnetz zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem beschrieben, bei welchem ein oder mehrere Streaming-Server, die durch Telekommunikation miteinander in Verbindung treten können, die betreffende Anwendung ausführen und die mit dem jeweiligen Telekommunikationsendgerät ortsnah in Verbindung treten, wobei das betreffende Telekommunikationsendgerät die verlangte Anwendung (Applikation) von einem ortsnahen Server abruft, der die Rechnerleistung für das Rendering und die Kodierung der betreffenden Anwendung zur Verfügung stellt
Patentanspruch 6 beschreibt ein Telekommunikationsnetz zur Wiedergabe von Anwendungen auf anwendungsfremden System-Umgebungen, die sich entweder durch unterschiedliche Hardware- oder Software-Komponenten unterscheiden, wobei der Streaming-Server das Handling der unterschiedlichen Anwendungen sowie das Rendering/Kodieren der Applikation und dessen Audio- und Videosignale übernimmt, wobei die Daten an das jeweilige Telekommunikationsendgerät - Mobilfunkgerät, Tablet, Laptop, PC, TV - übertragen werden und die Übertragung mittels modifiziertem h.254-Protokoll durchgeführt wird und das WAN als Übertragungsmittel für Au- dio-/Video-Pakete per UDP/TCP verwendet wird und die komplette Rechnerleistung von dem betreffenden Streaming-Server übernommen wird, wobei die paketierten Daten nur bei dem Telekommunikationsendgerät dekodiert werden. Die Lösung nach Patentanspruch 7 beschreibt ein Telekommunikationsnetz zum Bereitstellen einer plattformunabhängigen Streaming-Technologie, die einmal programmiert und auf beliebige Telekommunikationsendgeräte portierbar ist, bei welchem das Streamen der einzelnen Anwendungen (Applikationen), zum Beispiel Videospiele, über ein WAN erfolgt, derart, dass a) eine Kommunikation zum Session-Server mittels des Telekommunikationsendgerätes (Klein-Applikationen) durchgeführt wird; b) eine bestimmte Session für einen bestimmten Endabnehmer für das zum Telekommunikationsendgerät geographisch nächstliegenden Streaming-Server der betreffenden Applikation, zum Beispiel eines Spiels, durchgeführt wird; c) Session-Informationen durch den betreffenden Session-Server dem Telekommunikationsendgerät und dem Streaming-Server mitgeteilt werden; d) eine direkte Verbindung zwischen dem Telekommunikationsendgerät und dem Streaming-Server der betreffenden Applikation, zum Beispiel eines Videospiels, durchgeführt wird; bei der Herstellung einer unmittelbaren Verbindung zwischen dem Telekommunikationsendgerät und dem betreffenden Streaming-Server folgende Schritte eingeleitet werden: i. Aufzeichnung der Audio-A ideo-Daten der laufenden Applikation, zum Beispiel eines Spiels, über den betreffenden Streaming-Server des Spiels; ii. Komprimierung der Audio-A ideo-Daten durch hochwertige Hardware- Kodierer; iii. Übertragung der komprimierten Audio-A/ideo-Daten über WAN; iv. Empfang der Audio-A/ideo-Daten auf Seiten des Telekommunikationsendgerätes; v. Dekomprimierung der Audio-A/ideo-Daten mittels vi. Empfang und Wiedergabe der Audio-A/ideo-Daten auf dem Telekommunikationsendgerät (klein); vii. Aufzeichnung der Aktionen (Eingaben) des Benutzers des Telekommunikationsendgerätes, zum Beispiel eines Spielers, auf dem Telekommunikationsendgerät (klein); viii. effiziente Übertragung der Eingaben zurück zu dem betreffenden Streaming-Server des Spiels und ix. Wiedergabe der übertragenen Eingaben auf Streaming Server.
Lösung der Aufgabe betreffend die Verwendung eines
Telekommunikationsnetzes
Diese Aufgabe wird durch jeden der nebengeordneten Patentansprüche 8 bis 10 gelöst.
Patentanspruch 8 beschreibt die Verwendung eines Telekommunikationsnetzes zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem, bei welchem ein oder mehrere Streaming-Server, die durch Telekommunikation miteinander in Verbindung treten können, die betreffende Anwendung ausführen und die mit dem jeweiligen Telekommunikationsendgerät ortsnah in Verbindung treten, wobei das betreffende Telekommunikationsendgerät die verlangte Anwendung (Applikation) von einem ortsnahen Server abruft, der die Rechnerleistung für das Rendering und die Kodierung der betreffenden Anwendung zur Verfügung stellt.
In Patentanspruch 9 ist eine Lösung zur Verwendung eines Telekommunikationsnetzes auf anwendungsfremden System-Umgebungen beschrieben, die sich entweder durch unterschiedliche Hardware- oder Software-Komponenten unterscheiden, wobei der Streaming-Server das Handling der unterschiedlichen Anwendungen sowie das Rendering/Kodierung der Anwendung und dessen Audio- und Videosignale der einzelnen Anwendungen (Frames) übernimmt, wobei die Daten an das jeweilige Telekommunikationsendgerät - Mobilfunkgerät, Tablet, Laptop, PC, TV - übertragen werden und die Übertragung mittels modifiziertem h.254-Protokoll durchgeführt wird und das WAN als Übertragungsmittel für Audio-A/ideo-Pakete per UDP/TCP verwendet wird und die komplette Rechnerleistung von dem betreffenden Streaming-Server übernommen wird, wobei die paketierten Daten nur bei dem Telekommunikationsendgerät dekodiert werden.
Patentanspruch 10 beschreibt die Verwendung eines Telekommunikationsnetzes zum Bereitstellen einer plattformunabhängigen Streaming-Technologie, die einmal programmiert und auf beliebige Telekommunikationsendgeräte portierbar ist, bei welchem das Streamen der einzelnen Anwendungen (Applikationen), zum Beispiel Videospiele, über ein WAN erfolgt, derart, dass a) eine Kommunikation zum Session-Server mittels des Telekommunikationsendgerätes (Klein-Applikationen) durchgeführt wird; b) eine bestimmte Session für einen bestimmten Endabnehmer für das zum Telekommunikationsendgerät geographisch nächstliegenden Streaming-Server der betreffenden Applikation, zum Beispiel eines Spiels, durchgeführt wird; c) Session-Informationen durch den betreffenden Session-Server dem Telekommunikationsendgerät und dem Streaming-Server mitgeteilt werden; d) eine direkte Verbindung zwischen dem Telekommunikationsendgerät und dem Streaming-Server der betreffenden Applikation, zum Beispiel eines Videospiels, durchgeführt wird; e) bei der Herstellung einer unmittelbaren Verbindung zwischen dem Telekommunikationsendgerät und dem betreffenden Streaming-Server folgende Schritte eingeleitet werden: i. Aufzeichnung der Audio-/Video-Daten der laufenden Applikation, zum Beispiel eines Spiels, über den betreffenden Streaming-Server auf dem das Spiel läuft. Komprimierung der Audio-A/ideo-Daten durch hochwertige Hardware- Kodierer;
Übertragung der komprimierten Audio-/Video-Daten über WAN;
Empfang der Audio-A/ideo-Daten auf Seiten des Telekommunikationsendgerätes;
Dekomprimierung der Audio-A/ideo-Daten
Visualisierung der Audio-A/ideo-Daten auf dem Telekommunikationsendgerät (klein);
Aufzeichnung der Aktionen (Eingaben) des Benutzers des Telekommunikationsendgerätes, zum Beispiel eines Spielers, auf dem Telekommunikationsendgerät (klein); viii. effiziente Übertragung der Eingaben zurück zu dem betreffenden Streaming-Server des Spiels und ix. Wiedergabe der übertragenen Eingaben für Applikationen auf Streaming Server.
Weitere erfinderische Ausgestaltungen
Eine weitere erfinderische Ausgestaltung hinsichtlich der Anwendung beschreibt Patentanspruch 11. Bei Paketverlust während der Übertragung von Daten auf das Telekommunikationsendgerät, zum Beispiel von einem Spiele-Server zum Telekommunikationsendgerät, werden folgende Schritte durchgeführt: a) Wiederherstellungsstrategien werden aufgerufen, um eine reibungslose Spieleerfahrung aufrechtzuerhalten; b) die geeignete Wiederherstellungsstrategie wird ausgewählt und c) die Wiederherstellungsanfrage wird zu dem betreffenden Streaming-Server der Applikation, zum Beispiel des Spiels, zurückgesendet.
Patentanspruch 12 zeigt die Verwendung eines Telekommunikationsnetzes für die Kommunikation mit einem Klienten (Anwender, Endgerät) mit folgendem Quellcode: ***********************^^j^jpQ-^^gy |Q Q jgg^jQ j ************************************** *
Responsible for adding relevant ports to network devices to make ensure smooth communication, technology targets a technique that can run independent of network hardware [verantwortlich für das Freischalten relevanter Ports im Netzwerkgerät (zum Beispiel Router), um so eine reibungslose Kommunikation zu gewährleisten. Diese Technik ermöglicht den universalen Einsatz unabhängig von der Netzwerk- Hardware des Users.]
************************************************************************************************^ package org.cloundgaming4u.client.portforwarding;
import java.io.lOException;
import net.sbbi.upnp.messages.UPNPResponseException;
import android.content.Context;
import android.os.AsyncTask;
import android.util.Log;
public class AddPortAsync extends AsyncTask<Void, Void, Void> {
private Context context;
private UPnPPortMapper uPnPPortMapper;
private String externallP;
private String internallP;
private int externalPort;
private int internalPort;
public AddPortAsync(Context context.UPnPPortMapper uPnPPortMapper, String externallP, String internallP,
int externalPort, int internalPort) {
this.context = context;
this.uPnPPortMapper = uPnPPortMapper;
this. externallP = externallP;
this. internallP = internallP;
this. externalPort = externalPort;
this. internalPort = internalPort;
}
@Override
protected void onPreExecute() {
super.onPreExecuteQ;
if(uPnPPortMapper == null)
uPnPPortMapper = new UPnPPortMapper();
}
@Override
protected Void dolnBackground(Void... params) {
if(uPnPPortMapper != null)
{
try {
Log. d("cg4u_log", "Contacting Router for setting network configurations"); if(uPnPPortMapper.openRouterPort(externallP,
externalPort,internallP,internalPort, "CG4UGames"))
{
Log.d("cg4u_log",String.format("Setting network configurations successful IP:%s Port:%d",externallP,externalPort));
Log.d("cg4u_log",String.format("Setting network configurations successful IP:%s Port^/od^internallP nternalPort));
}
}
catch (lOException e) {
e.printStackTrace(); }
catch (UPNPResponseException e) {
e.printStackTrace();
}
}
return null;
}
@Override
protected void onPostExecute(Void result) { super.onPostExecute(result);
//Send broadcast for update in the main activity
//Intent i = new lntent(ApplicationConstants.APPLICATION_ENCODING_TEXT); //context.sendBroadcast(i);
}
}
j\/0fsalPortMapper jgyg*********************************** Responsible for making sure that random port generated by Server is dynamically [verantwortlich für die generische Portzuweisung des Servers.]
mapped at
dient end
****************************************** package org.cloundgaming4u.client.portforwarding;
import net.sbbi.upnp.impls.InternetGatewayDevice;
import net.sbbi.upnp.messages.UPNPResponseException;
import java.io.lOException;
public class UPnPPortMapper {
private lnternetGatewayDevice[] internetGatewayDevices;
private InternetGatewayDevice foundGatewayDevice;
I**
* Search for IGD External Address
* @return String 7 public String findExternallPAddress () throws lOException, UPNPResponseException {
/** Upnp devices router search*/ if(internetGatewayDevices == null) {
internetGatewayDevices =
lnternetGatewayDevice.getDevices(ApplicationConstants.SCAN_TIMEOUT); }
if(internetGatewayDevices != null) {
for (InternetGatewayDevice IGD : internetGatewayDevices) {
foundGatewayDevice = IGD; return IGD.getExternallPAddress().toString();
}
}
return null; }
I**
* Search Found Internet Gateway Device Friendly Name * @ return */ public String findRouterName(){ if(foundGatewayDevice != null){ return foundGatewayDevice.getlGDRootDevice().getFriendlyName().toString(); }
return "null"; }
I**
* Open Router Port
* IGD == Internet Gateway Device
*
* @param internallP
* @param internalPort
* @param externalRouterIP
* @param externalRouterPort
* @param description
* @ return
* @throws lOException
* @throws UPNPResponseException
*/ public boolean openRouterPort(String externalRouterIP, int externalRouterPort, String internallP, int internalPort,
String description)
throws lOException, UPNPResponseException {
/** Upnp devices router
search*/
if(internetGatewayDevices == null){
internetGatewayDevices =
lnternetGatewayDevice.getDevices(ApplicationConstants.SCAN_TIMEOUT); }
if(internetGatewayDevices != null){
for (InternetGatewayDevice addIGD : internetGatewayDevices) {
/** Open port for TCP protocol and also for UDP protocol
* Both protocols must be open this
is a MUST*/
//addlGD.addPortMapping(description, externalRouterlP, internalPort, externalRouterPort, internallP, 0, ApplicationConstants.TCP_PROTOCOL); addlGD.addPortMapping(description, externalRouterlP, internalPort, externalRouterPort, internallP, 0, ApplicationConstants.UDP_PROTOCOL);
}
return true;
}else{
return false; }
}
public boolean removePort(String externallPJnt port) throws lOException,
UPNPResponseException{
/** Upnp devices router
search*/
if(internetGatewayDevices == null){
internetGatewayDevices = InternetGatewayDevice. getDevices(5000); }
/**Remote port mapping for all routers*/
if(internetGatewayDevices != null){
for (InternetGatewayDevice removelGD : internetGatewayDevices) {
// removelGD. deletePortMapping(externallP, port,
ApplicationConstants.TCP_PROTOCOL);
removelGD. deletePortMapping(externallP, port, "UDP");
}
return true;
}else{
return false;
}
}
} **********************************************************
End of ClientNetworkCommunication
*************************************************************************************
Patentanspruch 13 beschreibt die Verwendung im Zusammenhang mit einem Telekommunikationsnetz gemäß der Erfindung für das Dekodieren einer Videoanwendung und für das Dekodieren eines Endgerätes mit folgendem Quellcode:
^************************************************************************************************
*Here is the portion of code responsible for hardware decoding on android end
*hardware decoding enables smooth and rendering on android dient side
[dieser Teil des Codes ist für das Hardwaredekodieren des Andriod-Endgeräts verantwortlich,]
********************************* gbx_builtin_hw_decode_h264(RTSPThreadParam * streamConfigs, unsigned char *buffer,
int bufsize, struct timeval pts, bool marker) {
struct mini_h264_context ctx;
int more = 0;
// look for sps/pps
again: if((more = gbx_h264buffer_parser(&ctx, buffer, bufsize)) < 0) { gbx_stream_error("%lu.%06lu bad h.264 unitAn", pts.tv_sec, pts.tv return 1 ;
}
unsigned char *s1 ;
int len;
if(gbx_contexttype == 7) {
// sps
if(streamConfigs>
Videostate == RTSP_VIDEOSTATE_NULL) {
gbx_stream_error("rtspclient: initial SPS receivedAn");
if(initVideo(streamConfigs>
jnienv, "video/avc", gbx contextwidth,
gbx_contextheight) == NULL) {
gbx_stream_error("rtspclient: initVideo failedAn");
streamConfigs>
exitTransport = 1 ;
return 1 ;
} eise {
gbx_stream_error("rtspclient: initVideo success
[video/avc@%ux%d]\n",
gbx_contextwidth, gbx_contextheight); }
if(gbx_contextrawsps != NULL && gbx_contextspslen > videoSetByteBuffer(streamConfigs>
jnienv, "csdO",
gbx_contextrawsps, gbx_contextspslen);
free(gbx_contextrawsps);
}
streamConfigs>
Videostate = RTSP_VIDEOSTATE_SPS_RCVD;
// has more nals?
if(more > 0) {
buffer += more;
bufsize =
more;
goto ägain;
}
return 1 ;
}
} eise if(gbx_contexttype == 8) {
if(streamConfigs>
Videostate == RTSP_VIDEOSTATE_SPS_RCVD) { gbx_stream_error("rtspclient: initial PPS receivedAn"); if(gbx_contextrawpps != NULL && gbx_contextppslen > 0) { videoSetByteBuffer(streamConfigs>
jnienv, "csdl",
gbx_contextrawpps, gbx_contextppslen);
free(gbx_contextrawpps);
}
if(startVideoDecoder(streamConfigs>
jnienv) == NULL) {
gbx_stream_error("rtspclient: cannot start video decoderAn"); streamConfigs>
exitTransport = 1 ;
return 1 ;
} eise {
gbx_stream_error("rtspclient: video decoder startedAn"); }
streamConfigs>
Videostate = RTSP_VIDEOSTATE_PPS_RCVD;
// has more nals?
if(more > 0) {
buffer += more;
bufsize =
more; goto again;
}
return 1 ;
}
}
//
if(streamConfigs>
Videostate != RTSP_VIDEOSTATE_PPS_RCVD) {
if(android_start_h264(streamConfigs) < 0) {
// drop the frame
gbx_stream_error("rtspclient: drop video frame, state=%d type=%d\n", streamConfigs>
videostate, gbx_contexttype);
}
return 1 ;
}
if(gbx_contextis_config) {
//gbx_stream_error("rtspclient: got a config packet, type=%d\n", gbx_contexttype);
decodeVideo(streamConfigs>
jnienv, buffer, bufsize, pts, marker,
BUFFER_FLAG_CODEC_CONFIG); return 1 ;
}
//
if(gbx_contexttype == 1 || gbx_contexttype == 5 || gbx_contexttype == 19) { if(gbx_contextframetype == TYPE_I_FRAME || gbx_contextframetype ==
TYPE_SI_FRAME) {
// XXX: enable intrarefresh
at the Server will disable IDR/Iframes
// need to do something?
//gbx_stream_error("got an l/SI frame, type = %d/%d(%d)\n",
gbx_contexttype, gbx contextframetype, gbx_contextslicetype);
}
}
decodeVideo(streamConfigs>
jnienv, buffer, bufsize, pts, marker, 0/*marker ?
B U F F E R_F l_AG_SYNC_F RAM E : 0*/);
return 0;
}
*********************************************
End of DecodeVideo
************************************************************************************* Gemäß Patentanspruch 14 wird erfindungsgemäß folgender Quellcode für Dynamic Error Handling Strategies verwendet:
#ifndef UPSTREAM_REQUEST_H
#define UPSTREAM_REQUEST_H
#define PACKET_LOSS_TOLERANCE 0
#define RE_REQUEST_TIMEOUT 30
#define USER_EVENT_MSGTYPE_NULL 0
#define USER EVENT MSGTYPE IFRAME REQUEST 101
#define USER_EVENT_MSGTYPE_INTRA_REFRESH_REQUEST 102
#define USER_EVENT_MSGTYPE_INVALIDATE_REQUEST 103
#define RECOVER STRATEGY NONE 0
#define RECOVER_STRATEGY_REQ_IFRAME_BLOCKING 1
#define RECOVER STRATEGY REQ IFRAME NON BLOCKING 2
#define RECOVER_STRATEGY_REQ_INTRA_REFRESH 3
#define RECOVER_STRATEGY_REQ_INVALIDATE 4
//#define SERVER HW ENCODER FIX
// upstream event
#ifdef WIN32
#pragma pack(push, 1)
#endif struct sdlmsg_upstream_s {
unsigned Short msgsize;
unsigned char msgtype; // USER_EVENT_MSGTYPE_*
unsigned char which;
unsigned int pkt; // packet number to be invalidated
struct timeval pst; //timestamp of packet
}
#ifdef WIN32
#pragma pack(pop)
#else
attribute (( packed ))
#endif typedef struct sdlmsg_upstream_s sdlmsg upstream t;
#endif
*********************************************
End of DynamicErrorHandlingStrategies
************************************************************************************* Patentanspruch 15 ist auf die Verwendung des folgenden Quellcodes für ein Video Packet Compression gerichtet: **********************************************************************************************
Code snippets responsible for producing highly efficient compression technique that works in conjunction with the hardware to offer minimum latency at server end, which eventually results in real time gaming experience at dient end. It also contains server side of error handling strategies like intra refresh of the application window on server side.
[Dieser Teil des Codes ist für die Latenzreduktion verantwortlich. Er beinhaltet auch Server-Code für die entsprechenden "error handling strategies" wie zum Beispiel "intra refresh" des Anwendungsfensters.]
******************************************************
//upstream enable parameter
static int upstream enable = 1 ;
#ifdef NO_FIXED_FPS
// Gorillabox HW encoding data
#define NUMFRAMESINFLIGHT 1
int lnitHWGBX(IDirect3DDevice9 *);
unsigned char *gbx_pMainBuffer[NUMFRAMESINFLIGHT];
HANDLE gbx_hCaptureCompleteEvent[NUMFRAMESINFLIGHT]; HANDLE gbx_hFileWriterThreadHandle = NULL;
HANDLE gbx_hThreadQuitEvent = NULL;
DWORD gbx_dwMaxFrames = 30;
HANDLE gbx_aCanRenderEvents[NUMFRAMESINFLIGHT];
IFRSharedSurfaceHandle gbx_hlFRSharedSurface = NULL;
static IDirect3DDevice9 *encodeDevice = NULL;
static pthread_mutex_t surfaceMutex = PTHREAD_MUTEX_INITIALIZER; unsigned char *pBitStreamBuffer = NULL;
HANDLE EncodeCompleteEvent = NULL;
#endif
static IDirect3DDevice9 *capture Device = NULL;
HWGBXToH264HWEncoder *gbx_plFR=NULL;
DWORD gbx_dwFrameNumber = 0;
int HWGBXjnitialized = 0;
static int hw_vencoder_initialized = 0;
static int hw_vencoder_started = 0;
static pthread_t hw vencoderjid;
static pthread_mutex_t d3deviceMutex = PTHREAD M UTEX_I N ITIALIZER;
//TODO: read from configuration file
static int video_fps = 30;
// specific data for h.264/h.265 static char *_sps[VIDEO_SOURCE_CHANNEL_MAX]; static int _spslen[VIDEO_SOURCE_CHANNEL_MAX]; static char *_pps[VIDEO_SOURCE_CHANNEL_MAX]; static int _ppslen[VIDEO_SOURCE_CHANNEL_MAX]; static char *_vps[VIDEO_SOURCE_CHANNEL_MAX]; static int _vpslen[VIDEO_SOURCE_CHANNEL_MAX]; #ifdef NO_FIXED_FPS
static int fetchAndSendFrametoHWEncoder(void *arg) { static struct timeval *timer = NULL;
struct timeval pretv;
if(!timer)
{
timer = new timeval();
gettimeofday(timer, NULL);
}
//arg is the IDirect3DDevice9 pointer
if(arg == NULL) {
gbx_error( "arg arguement to encodernvencvideo module is NULL\r\n");
return 1 ;
}
if(captureDevice == NULL) {
pth read m utex_lock(&d 3deviceMutex) ;
captureDevice = (IDirect3DDevice9 *)arg;
pthread_mutex_unlock(&d3deviceMutex);
}
//! This is a hack of gbxMIGO to limit the frame rate of HW
if(HWGBX_initialized && hw_vencoder_started && encoder_running()) { gettimeofday(&pretv, NULL);
long millis = ((pretv.tv_sec * 1000) + (pretv.tv_usec / 1000)) ((
timer>
tv_sec *
1000) + (timer>
tv_usec / 1000));
if(millis < 30)
return 0;
memcpy(timer, &pretv, sizeof(struct timeval));
unsigned int bufferlndex = gbx_dwFrameNumber%NUMFRAMESINFLIGHT;
//! Wait for this buffer to finish saving before initiating a new capture
WaitForSingleObject(gbx_aCanRenderEvents[bufferlndex], INFINITE);
ResetEvent(gbx_aCanRenderEvents[bufferlndex]);
//! Transfer the render target to the H.264 encoder asynchronously
H WG BX_TRANS F E R_RT_TO_H 264_P ARAM S params = {0}; params.dwVersion = H WG BX_TRAN S F E R_RT_TO_H264_PARAM S VE R ; params.dwBufferlndex = bufferlndex;
//cater upstream requests from dient
if(upstream_enable) {
HWGBX_H264HWEncoder_EncodeParams encParam = {0};
params.pHWGBX_H264HWEncoder_EncodeParams = NULL;
struct timeval lastValidPst;
//TODO: we can test dynamic bitrate control
//HWGBX_H264_ENC_PARAM_FLAgbx_DYN_BITRATE_CHANGE
//Single strategy only
if(islFrameRequested()) {
//force next frame as IDR
encParam. dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam. dwEncodeParamFlags =
HWGBX_H264_ENC_PARAM_FLAgbx_FORCEIDR;
params.pHWGBX_H264HWEncoder_EncodeParams =
ÄencParam;
setl FrameReq uest(false) ;
gbx_error("[IFRAME REQUESTED]\n");
}
if(islntraRefreshRequested()) { //force an intrarefresh
wave from next frame
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam.bStartlntraRefresh = 1 ;
encParam.dwIntraRefreshCnt = 15; //number of frames per intrarefresh
wave
params.pHWGBX_H264HWEncoder_EncodeParams = SencParam;
setl ntraRef resh Req uest(false) ;
gbx_error("[INTRAREFRESH
REQUESTED]\n");
}
if(islnvalidateRequested()) {
//invalidate all previous frames before lastValidPst encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
getLastValidPst(lastValidPst);
encParam.blnvalidateRefrenceFrames = 1 ;
//TODO: compute following parameters from lastValidPst
//encParam.dwNumRefFramesTolnvalidate = 0; //number of reference frames to be invalidated
//encParam.ullnvalidFrameTimeStamp = ; //array of
timestamps of references to be invalidated
//this techinque to work, the encoder must use following property
//encParam.ulCaptureTimeStamp = ASSIGNED TIMESTAMP //later the decoder must be able to get extract this time stamp from recieved frame
params.pHWGBX_H264HWEncoder_EncodeParams =
&encParam;
setlnvalidateRequest(false);
gbx_error("[INVALIDATION REQUESTED %
d.%d]\n",
lastValidPst.tv_sec, lastValidPst.tv usec);
}
}
eise {
params.pHWGBX_H264HWEncoder_EncodeParams = NULL; }
HWGBXRESULT res =
gbx_plFR>
HWGBXTransferRenderTargetToH264HWEncoder(&params); gbx_dwFrameNumber++;
//
return 0;
}
return 0;
}
static void *fetchAndSendEncodeDataThread(void *data) {
DWORD bufferlndex = 0;
HANDLE hEvents[2];
hEvents[0] = gbx_hThreadQuitEvent;
DWORD dwEventlD = 0;
DWORD dwPendingFrames = 0;
DWORD dwCapturedFrames = 0;
while(!captureDevice)
{
pth read_m utex_lock(&d 3deviceM utex) ;
if(captureDevice == NULL)
{
pth read_m utex_u n lock(&d 3deviceM utex) ; usleep(100);
continue;
}
eise
{
pthread_mutex_unlock(&d3deviceMutex);
break;
}
}
if(!HWGBX_initialized && captu reDevice) {
if(lnitHWGBX(captureDevice) < 0) {
gbx_error( "U nable to load the HWGBX library\r\n");
return NULL;
}
}
//! While the render loop is still running
gbx_error("Hardware encoder thread started [%d] [%d]\n", hw_vencoder_started, encoder_running());
while (HWGBX_initialized && hw_vencoder_started && encoder_running()) {
hEvents[1] = gbx_hCaptureCompleteEvent[bufferlndex];
//! Wait for the capture completion event for this buffer dwEventlD = WaitForMultipleObjects(2, hEvents, FALSE, INFINITE);
if (dwEventlD WAIT_
OBJECT_0 == 0) {
//! The main thread has not signaied us to quit yet. It seems getting the
SPS Information signaied us
if(hw_vencoder_started)
{
WaitForSingleObject(gbx_hCaptureCompleteEvent[bufferlndex], INFINITE);
ResetEvent(gbx_hCaptureCompleteEvent[bufferlndex]); // optional
ResetEvent(gbx_hThreadQuitEvent); // optional
hEvents[0] = gbx_hThreadQuitEvent;
//! Fetch bitstream from HWGBX and dump to disk
GetBitStream(bufferlndex);
dwCapturedFrames++;
//! Continue rendering on this index
SetEvent(gbx_aCanRenderEvents[bufferlndex]);
//! Wait on next index for new data
bufferlndex = (bufferlndex+1)%NUMFRAMESINFLIGHT;
continue;
}
//! The main thread has signalled us to quit. //! Check if there is any pending work and finish it before quitting. dwPendingFrames = (gbx_dwMaxFrames > dwCapturedFrames) ? gbx_dwMaxFrames dwCapturedFrames
: 0;
gbx_error("Pending frames are %d\n", dwPendingFrames);
for(DWORD i = 0; i < dwPendingFrames; i++)
{
WaitForSingleObject(gbx_hCaptureCompleteEvent[bufferlndex], INFINITE);
ResetEvent(gbx_hCaptureCompleteEvent[bufferlndex]); // optional
//! Feten bitstream from HWGBX and dump to disk
GetBitStream(bufferlndex);
dwCapturedFrames++;
//! Wait on next index for new data
bufferlndex = (bufferlndex+1)%NUMFRAMESINFI_IGHT;
}
break;
}
ResetEvent(gbx_hCaptureCompleteEvent[bufferlndex]); // optional
//! Fetch bitstream from HWGBX and dump to disk
GetBitStream(bufferlndex);
dwCapturedFrames++;
//! Continue rendering on this index SetEvent(gbx_aCanRenderEvents[bufferlndex]);
//! Wait on next index for new data
bufferlndex = (bufferlndex+1)%NUMFRAMESINFLIGHT;
}
gbx_error("video hwencoder: thread terminated\n");
return NULL;
}
int lnitHWGBX(IDirect3DDevice9 *gbx_pD3DDevice)
{
HINSTANCE gbx_hHWGBXDII=NULL;
HWGBXLibrary HWGBXLib;
//! Load the HWGBX.dll library
if(NULL == (gbx hHWGBXDIl = HWGBXLib.load()))
return 1 ;
//! Create the HWGBXToH264HWEncoder object
gbx_plFR = (HWGBXToH264HWEncoder *) HWGBXLib.create (gbx_pD3DDevice,
HWGBX TOH264HWENCODER);
if(NULL == gbx_plFR)
{
gbx_error("Failed to create the HWGBXToH264HWEncoder\r\n");
return 1 ;
} for (DWORD i = 0; i < NUMFRAMESINFLIGHT; i++)
{
//! Create the events for allowing rendering to continue after a capture is complete gbx_aCanRenderEvents[i] = CreateEvent(NULL, TRUE, TRUE, NULL);
}
gbx_hThreadQuitEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
//! Set up the H.264 encoder and target buffers
DWORD dwBitRate720p = 3000000;
double dBitRate = double(dwBitRate720p);
HWGBX_H264HWEncoder_Config encodeConfig = {0};
encodeConfig.dwVersion = HWGBX_H264HWENCODER_CONFIgbx_VER; encodeConfig.dwAvgBitRate = (DWORD)dBitRate;
encodeConfig.dwFrameRateDen = 1 ;
encodeConfig. dwFrameRateNum = 30;
encodeConfig.dwPeakBitRate = (encodeConfig.dwAvgBitRate * 12/10); // +20% encodeConfig.dwGOPLength = Oxffffffff;
//encodeConfig. bRepeatSPSPPSHeader = true;
encodeConfig. bEnablelntraRefresh = 1 ;
encodeConfig. dwMaxNumRefFrames = 16;
encodeConfig. dwProfile = 100;
encodeConfig.eRateControl =
HWGBX_H264_ENC_PARAMS_RC_2_PASS_QUALITY; encodeConfig.ePresetConfig = HWGBX_H264_PRESET_LOW_LATENCY_HQ; encodeConfig.dwQP = 26;
encodeConfig.bEnableAQ = 1 ;
/*
encodeConfig.dwProfile = 100;
encodeConfig.eRateControl =
HWGBX_H264_ENC_PARAMS_RC_2_PASS_QUALITY; ll\
H WG BX H 264 E N C_P ARAM F LAg bx FORCEIDR;
encodeConfig.ePresetConfig = HWGBX_H264_PRESET_LOW_LATENCY_HQ; encodeConfig.dwQP = 26;
*/
/*encodeConfig.dwProfile = 244;
encodeConfig.eRateControl = HWGBX_H264_ENC_PARAMS__RC_CONSTQP; ll\ HWG BX_H264_E NC PARAM FLAg bx_FO RC E I DR ;
encodeConfig.ePresetConfig = HWGBX_H264_PRESET_LOSSLESS_HP;
encodeConfig.dwQP = 0;
*/
HWGBX_SETUP_H264_PARAMS params = {0};
params.dwVersion = HWGBX_SETUP_H264_PARAMS_VER;
params. pEncodeConfig = &encodeConfig;
params.eStreamStereoFormat = HWGBX_H264_STEREO_NONE;
params.dwN Buffers = NUMFRAMESINFLIGHT; params.dwBSMaxSize = 256*1024;
params.ppPageLockedBitStreamBuffers = gbx_pMainBuffer;
params.ppEncodeCompletionEvents = gbx_hCaptureCompleteEvent;
//TODO: find a way to fill give proper Channel id
params.dwTargetHeight = video_source_out_height(0);
params.dwTargetWidth = video_source_out_width(0);
HWGBXRESULT res = gbx_plFR>
HWGBXSetUpH264HWEncoder(&params);
if (res != HWGBX_SUCCESS)
{
jf (res == HWGBX_ERROR_INVALID_PARAM || res !=
HWGBX_ERROR_INVALID_PTR)
gbx_error("HWGBX Buffer creation failed due to invalid paramsAn");
eise
gbx_error("Something is wrong with the driver, cannot initialize IFR buffers\n"); return 1 ;
}
gbx_error("Gorillabox device configured\n");
HWGBXjnitialized = 1 ;
return HWGBXjnitialized;
}
#else int
create_encode_device()
{
if(encodeDevice != NULL) {
return 0;
} static void *
encode_and_send_thread_proc(void *data)
{
HWGBXRESULT res = HWGBX_SUCCESS;
struct timeval start_tv, end_tv;
long long sleep_delta;
long long frame_interval = 1000000/video_fps;
//wait for encoder to be initialized
while(!HWGBX_initialized)
{
usleep(100);
}
gbx_error("Hardware encoder thread started [%d] [%d]\n", hw_vencoder_started, encoder_running());
//main loop for encoding and sending frames while (HWGBX_initialized && hw_vencoder_started && encoder_running()) {
//read shared surface
IDirect3DSurface9* pRenderTarget;
encodeDevice>
GetRenderTarget( 0, SpRenderTarget );
pth read m utex_lock(&su rface M utex) ;
BOOL bRet = HWGBX_CopyFromSharedSurface_fn(encodeDevice, gbx_hlFRSharedSurface, pRenderTarget);
pthread_mutex_unlock(&surfaceMutex);
pRenderTarget>
Release();
//send shared buffer to encoder
HWGBX_TRANSFER_RT_TO_H264_PARAMS params = {0};
params.dwVersion = HWGBX_TRANSFER_RT_TO_H264_PARAMS_VER; params. dwBufferlndex = 0;
//cater upstream requests from dient
if(upstream_enable) {
HWGBX_H264HWEncoder_EncodeParams encParam = {0};
params.pHWGBX_H264HWEncoder_EncodeParams = NULL;
struct timeval lastValidPst;
//TODO: we can test dynamic bitrate control //H WG BX_H 264 E N C_PARAM_F LAg bx_D YN B ITRATE C HANGE
//single strategy only
if(islFrameRequested()) {
//force next frame as IDR
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam.dwEncodeParamFlags =
HWG BX_H264_E N C PARAM F LAgbx_FO RC E IDR;
params.pHWGBX_H264HWEncoder_EncodeParams =
SencParam;
setlFrameRequest(false);
gbx_error("[IFRAME REQUESTED]\n");
}
if(islntraRefreshRequested()) {
//force an intrarefresh
wave from next frame
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam.bStartlntraRefresh = 1 ;
encParam.dwIntraRefreshCnt = 5; //number of frames per intrarefresh
wave params.pHWGBX_H264HWEncoder_EncodeParams = &encParam;
set I ntra Ref resh Req uest(fa Ise) ;
gbx_error("[INTRAREFRESH
REQUESTED]\n");
}
if(islnvalidateRequested()) {
//invalidate all previous frames before lastValidPst
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
getLastValidPst(lastValidPst);
encParam.blnvalidateRefrenceFrames = 1 ;
//TODO: compute following parameters from lastValidPst
//encParam.dwNumRefFramesTolnvalidate = 0; //number of reference frames to be invalidated
//encParam.ullnvalidFrameTimeStamp = ; //array of timestamps of references to be invalidated
//this techinque to work, the encoder must use following property
//encParam.ulCaptureTimeStamp = ASSIGNED_TIMESTAMP //later the decoder must be able to get extract this time stamp from recieved frame params.pHWGBX_H264HWEncoder_EncodeParams =
ÄencParam;
setlnvalidateRequest(false);
gbx_error("[INVALIDATION REQUESTED %
d.%d]\n",
lastValidPst.tv_sec, lastValidPst.tv_usec);
}
}
eise {
params.pHWGBX_H264HWEncoder_EncodeParams = NULL; }
gettimeofday(&start_tv, NULL);
res =
gbx_plFR>
HWGBXTransferRenderTargetToH264HWEncoder(&params); if (res == HWGBX_SUCCESS)
{
//wait for encoder to set complete event
WaitForSingleObject(EncodeCompleteEvent, INFINITE);
ResetEvent(EncodeCompleteEvent);
//get frame stats
HWGBX_H264HWEncoder_FrameStats dFrameStats; d FrameStats. dwVersion =
HWGBX_H264HWENCODER_FRAMESTATS_VER;
H WG BX G ET_H264_STATS_PARAM S params = {0};
params.dwVersion = HWGBX_GET_H264_STATS_PARAMS_VER; params. dwBufferlndex = 0;
params.pHWGBX_H264HWEncoder_FrameStats = &dFrameStats; res = gbx_plFR>
HWGBXGetStatsFromH264HWEncoder(&params);
if (res == HWGBX_SUCCESS) {
//send encoded frame
AVPacket pkt;
av_init_packet(&pkt);
pkt.size = dFrameStats.dwByteSize;
pkt.data = pBitStreamBuffer;
pkt.pts = (int64_t)gbx_dwFrameNumber++;
pkt.streamjndex = 0;
if(encoder_send_packet("hwvideoencoder",
0/*rtspconf>
video_id*/, &pkt,
pkt.pts, NULL) < 0) {
gbx_error("encoder_send_packet: Error sending
packet\n"); }
}
//wait for specific time before encoding another frame gettimeofday(&end_tv, NULL);
sleep_delta = frame_interval tvdiff_
us(&end_tv, &start_tv);
if(sleep_delta > 0) {
usleep(sleep_delta);
}
}
}
gbx_error("video hwencoder: thread terminated\n"); return NULL;
}
#endif
static int
hw_vencoder_deinit(void *arg) {
static void
getSPS_PPSFromH264HWEncoder()
{ unsigned char buffer[255];
unsigned long dwSize = 0;
while(true)
{
if(!HWGBX_initialized)
usleep(100);
eise
break;
}
if(HWGBX_initialized)
{
bzero(buffer, sizeof(buffer));
HWGBX_GET_H264_HEADER_PARAMS h264HeaderParams = h264HeaderParams.dwVersion =
HWGBX_GET_H264_HEADER_PARAMS_VER;
h264HeaderParams.pBuffer = buffer;
h264HeaderParams.pSize = (NvU32 *)&dwSize;
HWGBXRESULT result = HWGBX_SUCCESS;
result =
gbx_plFR>
HWGBXGetHeaderFromH264HWEncoder(&h264HeaderParams) h264_get_hwvparam(0, buffer, dwSize); }
}
static int
hw_vencoder_ioctl(int command, int argsize, void *arg) { int ret = 0;
gbx_ioctl_buffer_t *buf = (gbx_ioctl_buffer_t*) arg;
if(argsize != sizeof(gbx_ioctl_buffer_t))
return gbx lOCTL ERR INVALID ARGUMENT;
switch(command) {
case gbx_IOCTL_GETSPS:
getSPS_PPSFromH264HWEncoder();
if(buf>
size < _spslen[buf>
id])
return gbxJOCTL ERR BUFFERSIZE;
buf>
size = _spslen[buf>
id];
bcopy(_sps[buf>
id], buf>
ptr, buf>
size); break;
case gbx_IOCTL_GETPPS:
//getSPS_PPSFromH264HWEncoder(); if(buf>
size < _ppslen[buf>
id])
return gbx lOCTL ERR BUFFERSIZE; buf>
size = _ppslen[buf>
id];
bcopy(_pps[buf>
id], buf>
ptr, buf>
size);
break;
case gbx_IOCTL_GETVPS:
if(command == gbx_IOCTL_GETVPS) return gbx_IOCTL_ERR_NOTSUPPORTED; break;
default:
ret = gbx_IOCTL_ERR_NOTSUPPORTED; break; }
return ret;
}
*********************************************
End of Video Compression
*************************************************************************************
In der Zeichnung ist die Erfindung - teils schematisch - beispielsweise veranschaulicht. Es zeigen:
Fig. 1 ein Blockdiagramm mit schematischer Darstellung der Beziehungen zwischen den einzelnen Bereichen und des Streaming Servers;
Fig. 2 ein Blockdiagramm des Game Package Module; ein Blockdiagramm des Session Management Server;
Fig. 4 ein Blockdiagramm der Mobile - Interactive Layer für den Client; Fig. 5 ein Blockdiagramm mit einem Ablaufdiagramm des Recovery Moduls des Clients;
Fig. 6 Mobile-Interactive-Layer - Exemplarische Visualisierung der Oberfläche eines Mobilen-Endgerätes.
Fig. 7 Recovery Strategy Process bei Verlust eines Datenpaketes.
Fig. 1 zeigt die einzelnen Elemente, die in der Kommunikation erforderlich sind. So übernimmt der Streaming Server 120 das Initialisieren der Application und lässt diese in einer virtuellen Umgebung starten. Zu diesem Zwecke verfügt der Streaming Server 120 über ein Game Isolation Modul 140. In diesem wird eine applikationsfreundliche Umgebung gestartet, die zum einen die Lauffähigkeit der Application gewährleistet, jedoch auch für die Wiedergabe der Steuersignale des Clients 110A verantwortlich ist. Der Streaming Server kann beliebig viele Instanzen von derselben oder unterschiedlichen Application starten. Limitierender Faktor ist in dieser Beziehung die Rechenleistung der GPU bei grafischen Anwendungen. Jeder gestarteten Application wird ein Game DB 180 zugewiesen. Dieser Game DB 180 ist für das Hinterlegen relevanter Daten für die Applikation verantwortlich. Um jedoch eine Applikation zu starten, muss diese zunächst als Game Package 170 dem Game Package Manager 180 zur Verfügung stehen. Das Network Modul 150 des Streaming Server 120 über- nimmt anschließend das Encoding und Packaging der Frames. Eine weitere Aufgabe des Network Moduls 150 ist das Handling von Recovery Requests des Clients 110A. Um administrative Eingriffe und Auswertungen vorzunehmen, wurde das Evaluator Modul 190 entwickelt. Dieses Modul ist für das Erzeugen von Statistiken verantwortlich.
Der Client dient als Thin-Client der Übertragung der AudioA/ideo Signale und kann typischerweise auf jeder beliebigen Plattform eingesetzt werden. Ein Streaming Server 120 kann eine Beziehung von 1 :n eingehen, jedoch kann ein Client nur die Kommunikation zu einem bestimmten Streaming Server 120 aufnehmen. Typischerweise sind die Anzahl der Clients pro Streaming Server nicht durch die Software, sondern durch die entsprechenden Hardware Kapazitäten der GPU des Streaming Servers 120 limitiert.
Eine Kommunikation zwischen Streaming Server 120 und Client 110A wird immer initial über den Session Management Server 130 hergestellt. Dieser übernimmt den initialen Request des Clients 110A zur Verbindung auf den Streaming Server und sucht für den Client 110A den optimalen Streaming Server 120. In einem System können mehrere Streaming Server parallel im Betrieb sein. Diese müssen auch nicht immer im selben Rechenzentrum oder Land stehen. Nach der Zuweisung eines Streaming Servers 120 durch den Session Management Server 130 für den Client 110A übernimmt der Streaming Server 120 die direkte Kommunikation mit dem Client 110A.
Ein weiteres Element stellt der Content Server 195 dar. Dieser Server ist für die Auslieferung bestimmter Teile in der Interactive-Layer des Clients 110A verantwortlich. So steuert dieser unter anderem das Ausspielen von Werbung entsprechend der Application die auf dem Thin-Client ausgespielt wird. Die nötige Information wird dem Content Server 195 über den Session Management Server 130 zur Verfügung gestellt.
Die Kommunikation findet primär über das WAN (Wide Area Network) 115 statt. Dies beinhaltet diverse Übertragungsarten und ist nicht auf bestimmte Bereiche beschränkt.
Fig 2 zeigt das Game Package Module 160, welches Teil des Streaming Servers 120 ist. Das Game Package Module 160 wird für jede neue Application initial gestartet und übernimmt sechs Teilbereiche für die Anwendung. Capture Encode Audio 210 ist in die Bereiche Capture 210A und Encode 210 B unterteilt, verantwortlich für das Abgreifen des Audio-Signales. Der Capture Encode Video Bereich 220 ist in dieselben Bereiche unterteilt wie das Audio Modul 210. Das Port Authentification Modul 230 übernimmt die Port Authentifizierung und entspricht dem Bereitstellen der Verbindung zwischen Game Stream Server 120 und dem Client 110A. Das Control Re- lay 240 ist für XXX verantwortlich. Die Aufgabe des Network Relay 250 ist es, die entsprechenden Pakete zu verschicken und ankommende Pakete zu verwalten. Das Recovery Module 260 ist für das Beantworten der entsprechenden Recovery Re- quests des Clients 110A verantwortlich.
Fig 3 befasst sich mit dem Session Management Server 130. Dieser hat die Aufgabe der Authentifizierung 310 und mithilfe eines nachgelagerten DB Module 315 dessen Aufgabe die zur Authentifizierung genutzten Daten zu speichern bzw. zu hinterlegen. Dieses DB Modul 315 ist jedoch nur optional. Die Möglichkeit einer externen Authentifizierung bleibt davon unberührt. Der Bereich Network 320 ist für die Kommunikation zwischen WAN 115, Streaming Server 120, Content Server 195 und den entsprechenden Clients verantwortlich. Der Session Manager 330 ist dann maßgeblich für das Verwalten der einzelnen Sessions verantwortlich und übernimmt die Zuweisung der Clients an einen entsprechenden Streaming Server. Das Evaluator Modul hat eine direkte Verbindung zu den individuellen Clients und sammelt relevante Daten für eine spätere zentrale Auswertung.
Fig 4 zeigt die einzelnen Elemente des Clients auf. Der komplette Client 110 wurde eigens für die Anwendung entwickelt und benötigt keine separate Software. Er besteht aus acht Bereichen die wie folgt zu beschreiben sind. Client Session Manager 410, kommuniziert mit dem Streaming Server 120 und dem Session Management Server und ist initial für die Authentifizierung und das Management des Clients verantwortlich.
Network Module 420 ist für das Einrichten der Verbindung und das Aufrechterhalten zuständig. Dieses Modul übernimmt auch das Versenden und Empfangen diverser Pakete.
Der Controller 430 übernimmt das das Ausliefern der angelieferten Frames und Audio Pakete als visuelles Bild im Client.
Decode Render Video 440 und Decode Render Audio 450 erhalten die Pakete, die zuvor vom Netzwerk Modul 420 empfangen wurden und vom Controller 430 weitergeleitet wurden.
Das Elevator Module 460 ist für das Sammeln statistischer Daten verantwortlich und überträgt diese dem Session Management Server. Entsprechend kann der Session Management Server die Verbindung auch optimieren. So entsteht eine Rückkoppe- lung, die dieses Modul sehr wichtig macht.
Das Recovery Module 470 bewertet eingehende Datenpakete. Sollte ein Datenpaket fehlerhaft sein, so wählt das Modul eine Recovery Strategy und fordert ggf. vom Streaming Server ein neues Paket oder unternimmt andere Maßnahmen, um den Verlust zu kompensieren, ohne einen Verlust in der Latenz oder Qualität zu erzielen.
Die Client Ul beinhaltet den interactive layer und Content des Content Server 195. Dort wird der Input des Anwenders abgefangen und an den Streaming Server 120 verschickt.
Fig 5 zeigt den Aufbau des Content Servers. Dieser verantwortet die Content Administration 510 und Content Streaming 520.
Die Content Administration dient der Voreinstellung der z.B. anzuzeigenden Werbung innerhalb der interactive layer im Client 110. Über die Content Administration 510 soll sowohl die Frequenz als auch der Inhalt festgelegt werden.
Das Modul Content Streaming 520 übernimmt das Ausspielen des Contents und dient als zentrale Schnittstelle für alle Clients.
Fig 6 stellt die Interactive Layer 600 da die Teil der Client Ul 480 ist. Grundsätzlich wird zwischen drei unterschiedlichen Bereichen differenziert.
Der Applikation-Layer 610 gibt die empfangenen Frames wieder und ist für die visuelle Darstellung der Applikation verantwortlich. Über der Application Layer 610 befindet sich der Ul Layer 620. Dieser Layer lässt sich individuell konfigurieren ist jedoch grundsätzlich maßgeblich für den Input des Anwenders im Client verantwortlich.
Neben den beiden oben genannten Layern gibt es die Möglichkeit Content des Content Servers 195 einzuspielen. Dies passiert dann im Bereich des Content Layers 630.
Fig 7 zeigt den Ablauf der Recovery Strategie des Clients 110 im Modul 470. Sobald ein„package loss" festgestellt 710 wurde auf Seiten des Clients, wird das Recovery Modul eine entsprechende Lösung anhand fest definierter Kriterien auswählen 720.
Ist die Entscheidung getroffen, ob Blocking 730, Not Blocking 740, Intrarefresh 750 oder Frame Validation 760 gewählt wurde, wird der recovery request 770 an den Streaming Server 120 geschickt. Der Streaming Server verschickt entsprechend ein neues Paket und die Aufgabe des Recovery Moduls 470 wurde erfüllt.
Die in den Patentansprüchen und in der Beschreibung beschriebenen sowie aus der Zeichnung ersichtlichen Merkmale können sowohl einzeln als auch in beliebigen Kombinationen für die Verwirklichung der Erfindung wesentlich sein. Begriffserklärung
Application Layer Anwendungsebene
Applications-Code Anwendungscode buffering Pufferung
Ein Client (deutsch„Kunde", auch clientseitige Anwendung oder Clientanwendung) bezeichnet
Client ein Computerprogramm, das auf einem Endgerät eines Netzwerks ausgeführt wird und mit einem zentralen Server kommuniziert.
Client Ul Module Client Benutzeroberfläche Modul
Client-Application Client-Anwendung
Client-Session Client-Sitzung
Cloud - Zusammenschluss mehrere Server im
Cloud
Internet codec Codierer-Decodierer
Content Layers Inhaltsebene Content Servers Inhalt-Server
Content Streaming Inhalt Streaming Controller Regler Controller Module Regler-Modul decode thread Dekodierungs-Anwendung Decoder-Render Dekodierungs-Ausführer Evaluator Evaluierungs-Einheit Evaluator Modul Evaluierungsmodul Frame Validation Frame Überprüfer interactive layer Interaktiv-Ebene Intrarefresh Innere Aktualisierung Loadbalancing Lastenverteilung Network Module Netzwerk-Modul Not Blocking Nicht-Blockieren Overlay Überlagerung packaging Paketierung Recovery Module Wiederherstellungs-Modul Recovery Strategies Wiederherstellungs-Strategie
Visualisierungs-Ausführer; ist für das Rendern
Render Thread
[Visualisieren] der Anwendung verantwortlich.
Scripting Skriptsprache Session handler Sitzungs-Manager shared library Geteilte Bibliotheken Streaming Streaming
Streaming-Server Streaming-Server
Streaming-Technology Streaming-Technologie
Beschreibt das Zuweisen eines Datums an ein
Timestamping
Datenpaket
UDP User Datagram Protokoll Ul Layer Benutzeroberfläche-Ebene WAN Wide Area Network
Web-Apps Web-Applikationen
Webcontent Management Web-Inhalt Management
Literaturverzeichnis
WO 2009/073830 A1
WO 2010/141522 A1
WO 2012/037170 A1
US 2014/0073428 A1

Claims

Patentansprüche
1. Verfahren zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem, bei welchem ein oder mehrere Streaming-Server, die durch Telekommunikation miteinander in Verbindung treten können, die betreffende Anwendung ausführen und die mit dem jeweiligen Telekommunikationsendgerät ortsnah in Verbindung treten, wobei das betreffende Telekommunikationsendgerät die verlangte Anwendung (Applikation) von einem ortsnahen Server abruft, der die Rechnerleistung für das Aufbauen des Video-Streams und die Kodierung der betreffenden Anwendung zur Verfügung stellt.
2. Verfahren zur Wiedergabe von Anwendungen auf anwendungsfremden System-Umgebungen, die sich entweder durch unterschiedliche Hardware- oder Software-Komponenten unterscheiden, wobei der Streaming-Server das Hand- ling der unterschiedlichen Anwendungen sowie das Rendering/Kodierung der Applikation und dessen Audio- und Videosignale übernimmt, wobei die Daten an das jeweilige Telekommunikationsendgerät - Mobilfunkgerät, Tablet, Laptop, PC, TV - übertragen werden und die Übertragung mittels modifiziertem h.254- Protokoll durchgeführt wird und das WAN als Ü bertrag ungsmittel für Audio- Λ ideo-Pakete per UDP/TCP verwendet wird und die komplette Rechnerleistung von dem betreffenden Streaming-Server übernommen wird, wobei die paketierten Daten nur bei dem Telekommunikationsendgerät dekodiert werden.
3. Verfahren zum Bereitstellen einer plattformunabhängigen Streaming-Technologie, die einmal programmiert und auf beliebige Telekommunikationsendgeräte portierbar ist, bei welchem das Streamen der einzelnen Anwendungen (Applikationen), zum Beispiel Videospiele, über ein WAN erfolgt, derart, dass a) eine Kommunikation zum Session-Server mittels des Telekommunikationsendgerätes (Klein-Applikationen) durchgeführt wird; b) eine bestimmte Session für einen bestimmten Endabnehmer für das zum Telekommunikationsendgerät geographisch nächstliegenden Streaming- Server der betreffenden Applikation, zum Beispiel eines Spiels, durchgeführt wird; c) Session-Informationen durch den betreffenden Session-Server dem Telekommunikationsendgerät und dem Streaming-Server mitgeteilt werden; eine direkte Verbindung zwischen dem Telekommunikationsendgerät und dem Streaming-Server der betreffenden Applikation, zum Beispiel eines Videospiels, durchgeführt wird; bei der Herstellung einer unmittelbaren Verbindung zwischen dem Telekommunikationsendgerät und dem betreffenden Streaming-Server folgende Schritte eingeleitet werden: i. Aufzeichnung der Audio-/Video-Daten der laufenden Applikation, zum Beispiel eines Spiels, über den betreffenden Streaming-Server auf dem das Spiel läuft. ii. Komprimierung der Audio-A ideo-Daten durch hochwertige Hardware-Kodierer; iii. Übertragung der komprimierten Audio-/Video-Daten über WAN; iv. Empfang der Audio-A/ideo-Daten auf Seiten des Telekommunikationsendgerätes; v. Dekomprimierung der Audio-A/ideo-Daten vi. Visualisierung der Audio-/Video-Daten auf dem Telekommunikationsendgerät (klein); vii. Aufzeichnung der Aktionen (Eingaben) des Benutzers des Telekommunikationsendgerätes, zum Beispiel eines Spielers, auf dem Telekommunikationsendgerät (klein); viii. effiziente Übertragung der Eingaben zurück zu dem betreffenden Streaming-Server des Spiels und ix. Wiedergabe der übertragenen Eingaben auf Streaming Server.
4. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass bei Paketverlust während der Übertragung von Dateien auf das Telekommunikationsendgerät, zum Beispiel von einem Spiele-Server zum Telekommunikationsendgerät, folgende Schritte durchgeführt werden: a) Wiederherstellungsstrategie wird auf Telekommunikationsendgerät (klein) aufgerufen, um eine reibungslose Spieleerfahrung aufrechtzuerhalten; b) die geeignete Wiederherstellungsstrategie wird ausgewählt und c) die Wiederherstellungsanfrage wird zu dem betreffenden Streaming-Server der Applikation, zum Beispiel des Spiels, zurückgesendet.
5. Telekommunikationsnetz zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem, bei welchem ein oder mehrere Streaming-Server, die durch Telekommunikation miteinander in Verbindung treten können, die betreffende Anwendung ausführen und die mit dem jeweiligen Telekommunikationsendgerät ortsnah in Verbindung treten, wobei das betreffende Telekommunikationsendgerät die verlangte Anwendung (Applikation) von einem ortsnahen Server abruft, der die Rechnerleistung für - das Rendering und die Kodierung der betreffenden Anwendung zur Verfügung stellt.
6. Telekommunikationsnetz zur Wiedergabe von Anwendungen auf anwendungsfremden System-Umgebungen, die sich entweder durch unterschiedliche Hardware- oder Software-Komponenten unterscheiden, wobei der Streaming-Server das Handling der unterschiedlichen Anwendungen sowie das Rende- ring/Kodieren der Applikation und dessen Audio- und Videosignale übernimmt, wobei die Daten an das jeweilige Telekommunikationsendgerät - Mobilfunkgerät, Tablet, Laptop, PC, TV - übertragen werden und die Übertragung mittels modifiziertem h.254-Protokoll durchgeführt wird und das WAN als Übertragungsmittel für Audio-/Video-Pakete per UDP/TCP verwendet wird und die komplette Rechnerleistung von dem betreffenden Streaming-Server übernommen wird, wobei die paketierten Daten nur bei dem Telekommunikationsendgerät dekodiert werden.
7. Telekommunikationsnetz zum Bereitstellen einer plattformunabhängigen Streaming-Technologie, die einmal programmiert und auf beliebige Telekommunikationsendgeräte portierbar ist, bei welchem das Streamen der einzelnen Anwendungen (Applikationen), zum Beispiel Videospiele, über ein WAN erfolgt, derart, dass a) eine Kommunikation zum Session-Server mittels des Telekommunikationsendgerätes (Klein-Applikationen) durchgeführt wird; b) eine bestimmte Session für einen bestimmten Endabnehmer für das zum Telekommunikationsendgerät geographisch nächstliegenden Streaming- Server der betreffenden Applikation, zum Beispiel eines Spiels, durchgeführt wird; c) Session-Informationen durch den betreffenden Session-Server dem Telekommunikationsendgerät und dem Streaming-Server mitgeteilt werden; eine direkte Verbindung zwischen dem Telekommunikationsendgerät und dem Streaming-Server der betreffenden Applikation, zum Beispiel eines Videospiels, durchgeführt wird; bei der Herstellung einer unmittelbaren Verbindung zwischen dem Telekommunikationsendgerät und dem betreffenden Streaming-Server folgende Schritte eingeleitet werden: i. Aufzeichnung der Audio-/Video-Daten der laufenden Applikation, zum Beispiel eines Spiels, über den betreffenden Streaming-Server des Spiels;
Komprimierung der Audio-/Video-Daten durch hochwertige ware-Kodierer; iii. Übertragung der komprimierten Audio- Video-Daten über WAN; iv. Empfang der Audio-/Video-Daten auf Seiten des Telekommunikationsendgerätes; v. Dekomprimierung der Audio-/Video-Daten mittels vi. Empfang und Wiedergabe der Audio/Video-Daten auf dem Telekommunikationsendgerät (klein); vii. Aufzeichnung der Aktionen (Eingaben) des Benutzers des Telekommunikationsendgerätes, zum Beispiel eines Spielers, auf dem Telekommunikationsendgerät (klein); viii. effiziente Übertragung der Eingaben zurück zu dem betreffenden Streaming-Server des Spiels und ix. Wiedergabe der übertragenen Eingaben auf Streaming" Server.
8. Verwendung eines Telekommunikationsnetzes zum Streamen und zur Wiedergabe von Anwendungen (APPs) über ein bestimmtes Telekommunikationssystem, bei welchem ein oder mehrere Streaming-Server, die durch Telekommunikation miteinander in Verbindung treten können, die betreffende Anwendung ausführen und die mit dem jeweiligen Telekommunikationsendgerät ortsnah in Verbindung treten, wobei das betreffende Telekommunikationsendgerät die verlangte Anwendung (Applikation) von einem ortsnahen Server abruft, der die Rechnerleistung für das Rendering und die Kodierung der betreffenden Anwendung zur Verfügung stellt.
9. Verwendung eines Telekommunikationsnetzes zur Wiedergabe von Anwendungen auf anwendungsfremden System-Umgebungen, die sich entweder durch unterschiedliche Hardware- oder Software-Komponenten unterscheiden, wobei der Streaming-Server das Handling der unterschiedlichen Anwendungen sowie das Rendering/Kodierung der Anwendung und dessen Audio- und Videosignale der einzelnen Bilder (Frames) übernimmt, wobei die Daten an das jeweilige Telekommunikationsendgerät - Mobilfunkgerät, Tablet, Laptop, PC, TV - übertragen werden und die Übertragung mittels modifiziertem h.254-Protokoll durchgeführt wird und das WAN als Übertragungsmittel für Audio-A/ideo-Pakete per UDP/TCP verwendet wird und die komplette Rechnerleistung von dem betreffenden Streaming-Server übernommen wird, wobei die paketierten Daten nur bei dem Telekommunikationsendgerät dekodiert werden.
10. Verwendung eines Telekommunikationsnetzes zum Bereitstellen einer plattformunabhängigen Streaming-Technologie, die einmal programmiert und auf beliebige Telekommunikationsendgeräte portierbar ist, bei welchem das Strea- men der einzelnen Anwendungen (Applikationen), zum Beispiel Videospiele, über ein WAN erfolgt, derart, dass a) eine Kommunikation zum Session-Server mittels des Telekommunikationsendgerätes (Klein-Applikationen) durchgeführt wird; b) eine bestimmte Session für einen bestimmten Endabnehmer für das zum Telekommunikationsendgerät geographisch nächstliegenden Streaming- Server der betreffenden Applikation, zum Beispiel eines Spiels, durchgeführt wird; c) Session-Informationen durch den betreffenden Session-Server dem Telekommunikationsendgerät und dem Streaming-Server mitgeteilt werden; d) eine direkte Verbindung zwischen dem Telekommunikationsendgerät und dem Streaming-Server der betreffenden Applikation, zum Beispiel eines Videospiels, durchgeführt wird; e) bei der Herstellung einer unmittelbaren Verbindung zwischen dem Telekommunikationsendgerät und dem betreffenden Streaming-Server folgende Schritte eingeleitet werden: i. Aufzeichnung der Audio-A/ideo-Daten der laufenden Applikation, zum Beispiel eines Spiels, über den betreffenden Streaming-Server, auf dem das Spiel läuft. ii. Komprimierung der Audio-A ideo-Daten durch hochwertige Hardware-Kodierer; iii. Übertragung der komprimierten Audio-/Video-Daten über WAN; iv. Empfang der Audio-A/ideo-Daten auf Seiten des Telekommunikationsendgerätes; v. Dekomprimierung der Audio-A ideo-Daten vi. Visualisierung der Audio-A ideo-Daten auf dem Telekommunikationsendgerät (klein); vii. Aufzeichnung der Aktionen (Eingaben) des Benutzers des Telekommunikationsendgerätes, zum Beispiel eines Spielers, auf dem Telekommunikationsendgerät (klein); viii. effiziente Übertragung der Eingaben zurück zu dem betreffenden Streaming-Server des Spiels und ix. Wiedergabe der übertragenen Eingaben für Applikationen auf Streaming Server.
1 1 . Verwendung nach Anspruch 8 oder einem der darauffolgenden Ansprüche, dadurch gekennzeichnet, dass bei Paketverlust während der Übertragung von Daten auf das Telekommunikationsendgerät, zum Beispiel von einem Spiele- Server zum Telekommunikationsendgerät, folgende Schritte durchgeführt werden:
a) Wiederherstellungsstrategien werden aufgerufen, um eine reibungslose Spieleerfahrung aufrechtzuerhalten; b) die geeignete Wiederherstellungsstrategie wird ausgewählt und c) die Wiederherstellungsanfrage wird zu dem betreffenden Streaming- Server der Applikation, zum Beispiel des Spiels, zurückgesendet.
12. Verwendung nach Anspruch 10 oder 11 mit einem Source Code - für die Kommunikation mit einem Klienten (Anwender, Endgerät - 110A) - wie folgt:
^***********************^^^pQ J^gy|^p Q jgg†jQ j ^ ^^*** ***************************** *
*Responsible for adding relevant ports to network devices to make ensure smooth communication, technology targets a technique that can run independent of network hardware [verantwortlich für das Freischalten relevanter
Ports im Netzwerkgerät (zum Beispiel Router), um so eine reibungslose
Kommunikation zu gewährleisten. Diese Technik ermöglicht den universalen
Einsatz unabhängig von der Netzwerk-Hardware des Users,]
******************************************************************************************^ package org.cloundgaming4u.client.portforwarding;
import java.io.lOException;
import net.sbbi.upnp.messages.UPNPResponseException;
import android.content.Context;
import android.os.AsyncTask;
import android.util. Log;
public class AddPortAsync extends AsyncTask<Void, Void, Void> { private Context context;
private UPnPPortMapper uPnPPortMapper;
private String externallP;
private String internallP;
private int externalPort;
private int internalPort;
public AddPortAsync(Context context.UPnPPortMapper uPnPPortMapper, String
externallP, String internallP,
int externalPort, int internalPort) {
this. context = context;
this. uPnPPortMapper = uPnPPortMapper;
this. externallP = externallP;
this. internallP = internallP;
this.externalPort = externalPort; this.internalPort = internalPort; }
@Override
protected void onPreExecute() {
super.onPreExecute();
if(uPnPPortMapper == null)
uPnPPortMapper = new UPnPPortMapper();
}
@Override
protected Void dolnBackground(Void... params) {
if(uPnPPortMapper != null)
{
try
{
Log. d("cg4u_log", "Contacting Router for setting network configurations"); if(uPnPPortMapper.openRouterPort(externallP,
externalPort.internallP, internalPort, "CG4UGames"))
{
Log.d("cg4u_log",String.format("Setting network configurations successful IP:%s Port:%d",externallP,externalPort));
Log.d("cg4uJog",String.format("Setting network configurations successful IP:%s Port:%d",internallP,internalPort)); }
}
catch (lOException e)
{
e.printStackTrace();
}
catch (UPNPResponseException e)
{
e.printStackTrace();
}
}
return null;
}
@Override
protected void onPostExecute(Void result) {
super.onPostExecute( result);
//Send broadcast for update in the main activity
//Intent i = new
lntent(ApplicationConstants.APPLICATION_ENCODING_TEXT);
//context.sendBroadcast(i);
}
} *******************************JJ j")jv0rgg|Pof"tMapp6r jgyg******************************
Responsible for making sure that random port generated by server is dynamically mapped at dient end [verantwortlich für die generische
Portzuweisung des Servers.]
******************************************************* package org.cloundgaming4u.client.portforwarding; import net.sbbi.upnp.impls.InternetGatewayDevice; import net.sbbi.upnp.messages.UPNPResponseException; import java.io.lOException; public class UPnPPortMapper { private InternetGatewayDeviceQ internetGatewayDevices; private InternetGatewayDevice foundGatewayDevice;
I**
* Search for IGD External Address
* @return String */
public String findExternallPAddress () throws lOException,
UPNPResponseException { /** Upnp devices router search*/ if(internetGatewayDevices == null) {
internetGatewayDevices = lntemetGatewayDevice.getDevices(ApplicationConstants.SCAN_TIMEOUT); }
if(internetGatewayDevices != null) {
for (InternetGateway Device IGD : internetGatewayDevices) {
foundGatewayDevice = IGD;
return IGD.getExternallPAddress().toString();
}
}
return null; }
I**
* Search Found Internet Gateway Device Friendly Name
* @return
*/
public String findRouterName(){
if(foundGatewayDevice != null){
return foundGatewayDevice.getlGDRootDevice().getFriendlyName().toString(); }
return "null"; } I**
* Open Router Port
* IGD == Internet Gateway Device
*
* @param internallP
* @param internalPort
* @param exte mal Routerl P
* @param externalRouterPort
* @param description
* @return
* @throws lOException
* @throws UPNPResponseException
*/
public boolean openRouterPort(String externalRouterIPJnt externalRouterPort, String internallP.int internalPort,
String description)
throws lOException, UPNPResponseException {
/** Upnp devices router
search*/
if(internetGatewayDevices == null){
internetGatewayDevices =
lnternetGatewayDevice.getDevices(ApplicationConstants.SCAN_TIMEOUT); }
if(internetGatewayDevices != null){
for (IntemetGatewayDevice addIGD : internetGatewayDevices) {
/** Open port for TCP protocol and also for UDP protocol
* Both protocols must be open this
is a MUST*/
//addlGD.addPortMapping(description, externalRouterIP, internalPort, externalRouterPort, internallP, 0, ApplicationConstants.TCP_PROTOCOL); addlGD.addPortMapping(description, externalRouterIP, internalPort, externalRouterPort, internallP, 0, ApplicationConstants.UDP_PROTOCOL);
}
return true;
}else{
return false;
}
}
public boolean removePort(String externall P, int port) throws lOException,
UPNPResponseException{
/** Upnp devices router
search*/
if(internetGatewayDevices == null){
internetGatewayDevices = lnternetGatewayDevice.getDevices(5000); }
/**Remote port mapping for all routers*/
if(internetGatewayDevices != null){
for (InternetGatewayDevice removelGD : internetGatewayDevices) {
// removelGD.deletePortMapping(externallP, port,
ApplicationConstants.TCP_PROTOCOL);
removelGD.deletePortMapping(externallP, port, "UDP");
}
return true;
}else{
return false;
}
}
}
********************************************************
End of ClientNetworkCommunication
*********************************************
Verwendung nach Anspruch 10 oder 1 1 mit einem Source Code - Decode Video oder Code für ein Endgerät (1 10A, 440) - wie folgt: ******************************************
*Here is the portion of code responsible for hardware decoding on android end *hardware decoding enables smooth and rendering on android dient side [dieser Teil des Codes ist für das Hardwaredekodieren des Andriod-Endgeräts verantwortlich.]
******************************************
gbx_builtin_hw_decode_h264(RTSPThreadParam * streamConfigs, unsigned char *buffer,
int bufsize, struct timeval pts, bool marker) { struct mini_h264_context ctx; int more = 0;
// look for sps/pps again: if((more = gbx_h264buffer_parser(&ctx, buffer, bufsize)) < 0) { gbx_stream_error("%lu.%06lu bad h.264 unitAn", pts.tv_sec, pts.tv_usec); return 1 ;
}
unsigned char *s1 ; int len; if(gbx_contexttype == 7) { // sps if(streamConfigs>
Videostate == RTSP_VIDEOSTATE_NULL) { gbx_stream_error("rtspclient: initial SPS receivedAn"); if(initVideo(streamConfigs>
jnienv, "video/avc", gbx_contextwidth,
gbx_contextheight) == NULL) {
gbx_stream_error("rtspclient: initVideo failedAn"); streamConfigs>
exitTransport = 1 ;
return 1 ;
} eise {
gbx_stream_error("rtspclient: initVideo success
[video/avc@%ux%d]\n" ,
gbx_contextwidth, gbx_contextheight);
}
if(gbx_contextrawsps != NULL && gbx_contextspslen > videoSetByteBuffer(streamConfigs>
jnienv, "csdO",
gbx_contextrawsps, gbx_contextspslen);
free(gbx_contextrawsps);
}
streamConfigs>
Videostate = RTSP_VIDEOSTATE_SPS_RCVD;
// has more nals? if(more > 0) {
buffer += more;
bufsize =
more;
goto again;
}
return 1 ;
}
} eise if(gbx_contexttype == 8) {
if(streamConfigs>
Videostate == RTSP_VIDEOSTATE_SPS_RCVD) { gbx_stream_error("rtspclient: initial PPS receivedAn");
if(gbx_contextrawpps != NULL && gbx_contextppslen > 0) { videoSetByteBuffer(streamConfigs>
jnienv, "csdl ",
gbx_contextrawpps, gbx_contextppslen);
free(gbx_contextrawpps);
}
if(startVideoDecoder(streamConfigs>
jnienv) == NULL) {
gbx_stream_error("rtspclient: cannot start video decoderAn"); streamConfigs> exitTransport = 1 ;
return 1 ;
} eise {
gbx_stream_error("rtspclient: video decoder startedAn"); }
streamConfigs>
Videostate = RTSP_VIDEOSTATE_PPS_RCVD;
// has more nals?
if(more > 0) {
buffer += more;
bufsize =
more;
goto again;
}
return 1 ;
}
}
//
if(streamConfigs>
Videostate != RTSP_VIDEOSTATE_PPS_RCVD) { if(android_start_h264(streamConfigs) < 0) {
// drop the frame gbx_stream_error("rtspclient: drop video frame, state=%d type=%d\n", streamConfigs>
ideostate, gbx_contexttype);
}
return 1 ;
}
if(gbx_contextis_config) {
//gbx_stream_error("rtspclient: got a config packet, type=%d\n", gbx_contexttype);
decodeVideo(streamConfigs>
jnienv, buffer, bufsize, pts, marker,
BUFFER_FLAG_CODEC_CONFIG);
return 1 ;
}
II
if(gbx_contexttype == 1 || gbx_contexttype == 5 || gbx_contexttype == 1 if(gbx_contextframetype == TYPE_I_FRAME || gbx_contextframetype =
TYPE_SI_FRAME) {
// XXX: enable intrarefresh
at the Server will disable IDR/Iframes
// need to do something?
//gbx_stream_error("got an l/SI frame, type = %d/%d(%d)\n", gbx_contexttype, gbx_contextframetype, gbx_contextslicetype);
}
}
decodeVideo(streamConfigs>
jnienv, buffer, bufsize, pts, marker, 0/*marker ?
BUFFER_FLAG_SYNC_FRAME : 0*/);
return 0;
}
*****************************************************************************
End of DecodeVideo
******************************************************
14. Verwendung nach Anspruch 10 oder 11 mit einem Source Code - für Dynamic Error Handling Strategies für ein Endgerät (1 10A; Fig. 7) - wie folgt:
#ifndef UPSTREAM_REQUEST_H
#define UPSTREA _REQUEST_H
#define P AC KET LOSS TO L E RAN C E 0
#define RE_REQUEST_TIMEOUT 30
#define USER EVENT MSGTYPE NULL 0 #else attribute (( packed ))
#endif
typedef struct sdlmsg_upstream_s sdlmsg_upstream_t; #endif
******************************************** *****************************************
End of DynamicErrorHandlingStrategies
*************************************************************************************
Verwendung nach Anspruch 10 oder 11 mit einem Source Code - Video Packet Compression - wie folgt:
Code snippets responsible for producing highly efficient compression technique that works in conjunction with the hardware to offer minimum latency at server end, which eventually results in realtime gaming experience at dient end. It also contains Server side of error handling strategies like intrarefresh of the game window on server side. [Dieser Teil des Codes ist für die Latenzreduktion verantwortlich. Er beinhaltet auch Server-Code für die entsprechenden "error handling strategies" wie zum Beispiel "intra refresh" des Anwendungsfensters.] ****************************************************************************************** //upstream enable parameter
static int upstream_enable = 1 ;
#ifdef NO_FIXED_FPS
// Gorillabox HW encoding data
#define NUMFRAMESINFLIGHT 1
int lnitHWGBX(IDirect3DDevice9 *);
unsigned char *gbx_pMainBuffer[NUMFRAMESINFLIGHT];
HANDLE gbx_hCaptureCompleteEvent[NUMFRAMESINFLIGHT];
HANDLE gbx_hFileWriterThreadHandle = NULL;
HANDLE gbx_hThreadQuitEvent = NULL;
DWORD gbx_dwMaxFrames = 30;
HANDLE gbx_aCanRenderEvents[NUMFRAMESINFLIGHT];
IFRSharedSurfaceHandle gbx_hlFRSharedSurface = NULL;
static IDirect3DDevice9 *encodeDevice = NULL;
static pthread_mutex_t surfaceMutex = PTHREAD_MUTEX_INITIALIZER; unsigned char *pBitStreamBuffer = NULL;
HANDLE EncodeCompleteEvent = NULL;
#endif
static IDirect3DDevice9 *capture Device = NULL;
HWGBXToH264HWEncoder *gbx_plFR=NULL; DWORD gbx_dwFrameNumber = 0;
int HWGBXJnitialized = 0;
static int hw_vencoder_initialized = 0;
static int hw_vencoder_started = 0;
static pthread_t hw_vencoder_tid;
static pthread_mutex_t d3deviceMutex = PTHREAD_MUTEX_INITIALIZER;
//TODO: read from configuration file
static int video_fps = 30;
// specific data for h.264/h.265
static char *_sps[VIDEO_SOURCE_CHANNELJVIAX];
static int _spslen[VIDEO_SOURCE_CHANNEL_MAX];
static char *_pps[VIDEO_SOURCE_CHANNEL_MAX];
static int _ppslen[VIDEO_SOURCE_CHANNEL_MAX];
static char *_vps[VIDEO_SOURCE_CHANNEL_MAX];
static int _vpslen[VIDEO_SOURCE_CHANNEL_MAX];
#ifdef NO_FIXED_FPS
static int fetchAndSendFrametoHWEncoder(void *arg) {
static struct timeval *timer = NULL;
struct timeval pretv;
if(!timer)
{
timer = new timevalQ; gettimeofday(timer, NULL);
}
//arg is the IDirect3DDevice9 pointer
if(arg == NULL) {
gbx_error( "arg arguement to encodernvencvideo
module is NULL\r\n");
retum 1 ;
}
if(captureDevice == NULL)
{
pthread_mutex_lock(&d3deviceMutex);
captureDevice = (IDirect3DDevice9 *)arg;
pthread_mutex_unlock(&d3deviceMutex);
}
//! This is a hack of gbxMIGO to limit the frame rate of HW if(HWGBX_initialized && hw_vencoder_started && encoder run gettimeofday(&pretv, NULL);
long millis = ((pretv.tv_sec * 1000) + (pretv.tv_usec / 1000)) (( timer>
tv_sec *
1000) + (timer>
tv_usec / 1000)); if(millis < 30)
return 0;
memcpy(timer, &pretv, sizeof(struct timeval));
unsigned int bufferlndex = gbx__dwFrameNumber%NUMFRAMESINFLIGHT;
//! Wait for this buffer to finish saving before initiating a new capture
WaitForSingleObject(gbx_aCanRenderEvents[bufferlndex], INFINITE);
ResetEvent(gbx_aCanRenderEvents[bufferlndex]);
//! Transfer the render target to the H.264 encoder asynchronously
HWGBX_TRANSFER_RT_TO_H264_PARAMS params = {0};
params.dwVersion = HWGBX_TRANSFER_RT_TO_H264_PARA S_VER; params.dwBufferlndex = bufferlndex;
//cater upstream requests from dient
if(upstream_enable) {
HWGBX_H264HWEncoder_EncodeParams encParam = {0};
params.pHWGBX_H264HWEncoder_EncodeParams = NULL;
struct timeval lastValidPst;
/ TODO: we can test dynamic bitrate control
//HWGBX_H264_ENC_PARAM_FLAgbx_DYN_BITRATE_CHANGE
//Single strategy only
if(islFrameRequested()) {
//force next frame as IDR
encParam. dwVersion = HWGBX_H264HWENCODER_PARAM_VER;
encParam.dwEncodeParamFlags =
HWGBX_H264_ENC_PARAM_FLAgbx_FORCEIDR; params.pHWGBX_H264HWEncoder_EncodeParams = &encParam;
setlFrameRequest(false);
gbx_error("[IFRAI\/IE REQUESTED]\n");
}
if(islntraRefreshRequested()) {
//force an intrarefresh
wave from next frame
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam.bStartlntraRefresh = 1 ;
encParam.dwIntraRefreshCnt = 15; //number of frames per intrarefresh
wave
params.pHWGBX_H264HWEncoder_EncodeParams = &encParam;
setl ntra Ref resh Req uest(fa Ise) ;
gbx_error("[INTRAREFRESH
REQUESTED]\n"); }
if(islnvalidateRequested()) {
//invalidate all previous frames before lastValidPst
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
getLastValidPst(lastValidPst);
encParam.blnvalidateRefrenceFrames = 1 ;
//TODO: compute following parameters from lastValidPst
//encParam.dwNumRefFramesTolnvalidate = 0; //number of reference frames to be invalidated
//encParam.ullnvalidFrameTimeStamp = ; //array of timestamps of references to be invalidated
//this techinque to work, the encoder must use following property
//encParam.ulCaptureTimeStamp = ASS I G N E D_TI M ESTAM P //later the decoder must be able to get extract this time stamp from recieved frame
params.pHWGBX_H264HWEncoder_EncodeParams = ÄencParam;
setlnvalidateRequest(false);
gbx_error("[INVALIDATION REQUESTED %
d.%d]\n", lastValidPst.tv_sec, lastValidPst.tv_usec);
}
}
eise {
params.pHWGBX_H264HWEncoder_EncodeParams = NULL; }
HWGBXRESULT res =
gbx_plFR>
HWGBXTransferRenderTargetToH264HWEncoder(&params); gbx_dwFrameNumber++;
//
return 0;
}
return 0;
}
static void *fetchAndSendEncodeDataThread(void *data) {
DWORD bufferlndex = 0;
HANDLE hEvents[2];
hEvents[0] = gbx_hThreadQuitEvent; DWORD dwEventlD = 0;
DWORD dwPendingFrames = 0;
DWORD dwCapturedFrames = 0;
while(!captureDevice) {
pth read_m utexjo ck(&d 3de vice M utex) ;
if(captureDevice == NULL)
{
pthread_mutex_unlock(&d3deviceMutex);
usleep(100);
continue;
}
eise
{
pth read_m utex u n lo ck( &d 3de vi ce M utex) ;
break;
}
}
if(!HWGBX_initialized && captureDevice) { if(lnitHWGBX(captureDevice) < 0) {
gbx_error( "Unable to load the HWGBX library\r\n"); return NULL; }
}
//! While the render loop is still running
gbx_error("Hardware encoder thread started [%d] [%d]\n",
hw_vencoder_started,
encoder_running());
while (HWGBX_initialized && hw_vencoder_started && encoder_running()) {
hEvents[1] = gbx_hCaptureCompleteEvent[bufferlndex];
//! Wait for the capture completion event for this buffer
dwEventlD = WaitForMultipleObjects(2, hEvents, FALSE, INFINITE);
if (dwEventlD WAIT_
OBJECT_0 == 0)
{
//! The main thread has not Signaled us to quit yet. It seems getting the SPS Information signaled us
if(hw_vencoder_started )
{
WaitForSingleObject(gbx_hCaptureCompleteEvent[bufferlndex], INFINITE); ResetEvent(gbx_hCaptureCompleteEvent[bufferlndex]); // optional
ResetEvent(gbx_hThreadQuitEvent); // optional
hEvents[0] = gbx_hThreadQuitEvent; //! Fetch bitstream from HWGBX and dump to disk
GetBitStream(bufferlndex);
d wCaptu red Fra mes++ ;
III Continue rendering on this index
SetEvent(gbx_aCanRenderEvents[bufferlndex]);
//! Wait on next index for new data
bufferlndex = (bufferlndex+1 )%NUMFRA ESINFLIGHT;
continue;
}
//! The main thread has signalled us to quit.
//! Check if there is any pending work and finish it before quitting.
dwPendingFrames = (gbx_dwMaxFrames > dwCapturedFrames) ? gbx_dwMaxFrames dwCapturedFrames
: 0;
gbx_error("Pending frames are %d\n", dwPendingFrames);
for(DWORD i = 0; i < dwPendingFrames; i++)
{
WaitForSingleObject(gbx_hCaptureCompleteEvent[bufferlndex], INFINITE);
ResetEvent(gbx_hCaptureCompleteEvent[bufferlndex]); // optional
III Fetch bitstream from HWGBX and dump to disk
GetBitStream(bufferlndex);
dwCapturedFrames++; //! Wait on next index for new data
bufferlndex = (bufferlndex+1 )%NUMFRAMESINFLIGHT;
}
break;
}
ResetEvent(gbx_hCaptureCompleteEvent[bufferlndex]); // optional
//! Fetch bitstream from HWGBX and dump to disk
GetBitStream(bufferlndex);
dwCapturedFrames++;
//! Continue rendering on this index
SetEvent(gbx_aCanRenderEvents[bufferlndex]);
//! Wait on next index for new data
bufferlndex = (bufferlndex+1)%NUMFRAMESINFLIGHT;
}
gbx_error("video hwencoder: thread terminated\n");
return NULL;
}
int lnitHWGBX(IDirect3DDevice9 *gbx_pD3DDevice)
{
HINSTANCE gbx_hHWGBXDII=NULL;
HWGBXLibrary HWGBXLib;
//! Load the HWGBX.dll library if(NULL == (gbxJiHWGBXDIl = HWGBXLib.load())) return 1 ;
//! Create the HWGBXToH264HWEncoder object
gbx_plFR = (HWGBXToH264HWEncoder *) HWGBXLib.create
(gbx_pD3DDevice,
HWGBX_TOH264HWENCODER);
if(NULL == gbx_plFR)
{
gbx_error("Failed to create the HWGBXToH264HWEncoder\r\n");
return 1 ;
}
for (DWORD i = 0; i < NUMFRAMESINFLIGHT; i++)
{
//! Create the events for allowing rendering to continue after a capture is complete
gbx_aCanRenderEvents[i] = CreateEvent(NULL, TRUE, TRUE, NULL); }
gbx_hThreadQuitEvent = CreateEvent(NULL, TRUE, FALSE, NULL); //! Set up the H.264 encoder and target buffers
DWORD dwBitRate720p = 3000000;
double dBitRate = double(dwBitRate720p);
HWGBX_H264HWEncoder_Config encodeConfig = {0}; encodeConfig.dwVersion = HWGBX_H264HWENCODER_CONFIgbx_VER; encodeConfig.dwAvgBitRate = (DWORD)dBitRate;
encodeConfig.dwFrameRateDen = 1 ;
encodeConfig.dwFrameRateNum = 30;
encodeConfig.dwPeakBitRate = (encodeConfig.dwAvgBitRate * 12/10); // +20% encodeConfig.dwGOPLength = Oxffffffff;
//encodeConfig.bRepeatSPSPPSHeader = true;
encodeConfig.bEnablelntraRefresh = 1 ;
encodeConfig.dwMaxNumRefFrames = 16;
encodeConfig.dwProfile = 100;
encodeConfig.eRateControl =
HWGBX_H264_ENC_PARAMS_RC_2_PASS_QUALITY;
encodeConfig.ePresetConfig = HWGBX_H264_PRESET_LOW_LATENCY_HQ; encodeConfig.dwQP = 26;
encodeConfig.bEnableAQ = 1 ;
/*
encodeConfig.dwProfile = 100;
encodeConfig.eRateControl =
HWGBX_H264_ENC_PARAMS_RC_2_PASS_QUALITY; ll\
HWGBX_H264_ENC_PARAM_FLAgbx_FORCEIDR;
encodeConfig.ePresetConfig = HWGBX_H264_PRESET_LOW_LATENCY_HQ; encodeConfig.dwQP = 26; */
/*encodeConfig.dwProfile = 244;
encodeConfig.eRateControl = HWGBX_H264_ENC_PARAMS_RC_CONSTQP; ll\
HWGBX_H264_ENC_PARAM_FLAgbx_FORCEIDR;
encodeConfig.ePresetConfig = HWGBX_H264_PRESET_LOSSLESS_HP; encodeConfig.dwQP = 0;
7
HWGBX_SETUP_H264_PARAMS params = {0};
params.dwVersion = HWGBX_SETUP_H264_PARAMS_VER;
params.pEncodeConfig = ÄencodeConfig;
params.eStreamStereoFormat = HWGBX_H264_STEREO_NONE;
params.dwNBuffers = NU FRAMESINFLIGHT;
params.dwBSMaxSize = 256*1024;
params. ppPageLockedBitStreamBuffers = gbx_pMainBuffer;
params.ppEncodeCompletionEvents = gbx_hCaptureCompleteEvent;
//TODO: find a way to fill give proper Channel id
params.dwTargetHeight = video_source_out_height(0);
params.dwTargetWidth = video_source_out_width(0);
HWGBXRESULT res = gbx_plFR>
HWGBXSetUpH264HWEncoder(&params);
if (res != HWGBX_SUCCESS) {
if (res == HWGBX_ERROR_INVALID_PARAM || res !=
HWGBX ERRORJNVALID PTR)
gbx_error("HWGBX Buffer creation failed due to invalid paramsAn");
eise
gbx_error("Something is wrang with the driver, cannot initialize IFR buffers\n"); return 1 ;
}
gbx_error("Gorillabox device configured\n");
HWGBX_initialized = 1 ;
return HWGBX_initialized;
#else
int
create_encode_device()
{
if(encodeDevice != NULL) {
return 0;
} static void *
encode_and_send_thread_proc(void *data) 2017/016568
121
{
HWGBXRESULT res = HWGBX_SUCCESS;
struct timeval startjv, end_tv;
long long sleep_delta;
long long frame_interval = 1000000/video_fps;
//wait for encoder to be initialized
while(!HWGBX_initialized)
{
usleep(100);
}
gbx_error("Hardware encoder thread started [%d] [%d]\n",
hw_vencoder_started ,
encoder_running());
//main loop for encoding and sending frames
while (HWGBXJnitialized && hw_vencoder_started && encoder_running()) {
//read shared surface
IDirect3DSurface9* pRenderTarget;
encodeDevice>
GetRenderTarget( 0, ÄpRenderTarget );
pthread_mutexJock(&surfaceMutex);
BOOL bRet = HWGBX_CopyFromSharedSurface_fn(encodeDevice, gbx_hlFRSharedSurface, pRenderTarget);
pthread_m utex_u nlock(&su rfaceM utex) ;
pRenderTarget>
Release();
//send shared buffer to encoder
HWGBX_TRANSFER_RT_TO_H264_PARAMS params = {0};
params.dwVersion = HWGBX_TRANSFER_RT_TO_H264_PARAMS_VER; params.dwBufferlndex = 0;
//cater upstream requests from dient
if(upstream_enable) {
HWGBX_H264HWEncoder_EncodeParams encParam = {0};
params.pHWGBX_H264HWEncoder_EncodeParams = NULL;
struct timeval lastValidPst;
//TODO: we can test dynamic bitrate control
//HWGBX_H264_ENC_PARAM_FLAgbx_DYN_BITRATE_CHANGE
//single strategy only
if(islFrameRequested()) {
//force next frame as IDR
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam. dwEncodeParamFlags =
HWGBX_H264_ENC_PARAM_FLAgbx_FORCEIDR; params.pHWGBX_H264HWEncoder_EncodeParams &encParam;
setlFrameRequest(false);
gbx_error("[IFRAME REQUESTED]\n");
}
if(islntraRefreshRequested()) {
//force an intrarefresh
wave from next frame
encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
encParam.bStartlntraRefresh = 1 ;
encParam.dwIntraRefreshCnt = 5; //number of frames intrarefresh
wave
params.pHWGBX_H264HWEncoder_EncodeParams &encParam;
setlntraRefreshRequest(false);
gbx_error("[INTRAREFRESH
REQUESTED]\n");
}
if(islnvalidateRequested()) {
//invalidate all previous frames before lastValidPst encParam.dwVersion =
HWGBX_H264HWENCODER_PARAM_VER;
getLastValidPst(lastValidPst);
encParam.blnvalidateRefrenceFrames = 1 ;
//TODO: compute following parameters from lastValidPst
//encParam.dwNumRefFramesTolnvalidate = 0; //number of reference frames to be invalidated
//encParam.ullnvalidFrameTimeStamp = ; //array of timestamps of references to be invalidated
//this techinque to work, the encoder must use following property
//encParam.ulCaptureTimeStamp = ASSIGNED TIMESTAMP //later the decoder must be able to get extract this time stamp from recieved frame
params.pHWGBX_H264HWEncoder_EncodeParams = &encParam;
setlnvalidateRequest(false);
gbx_error("[INVALIDATION REQUESTED %
d.%d]\n",
lastValidPst.tv_sec, lastValidPst.tv_usec);
}
} eise {
params.pHWGBX_H264HWEncoder_EncodeParams = NULL;
}
gettimeofday(&start_tv, NULL);
res =
gbx_plFR>
HWGBXTransferRenderTargetToH264HWEncoder(&params);
if (res == HWGBX_SUCCESS)
{
//wait for encoder to sei complete event
WaitForSingleObject(EncodeCompleteEvent, INFINITE);
ResetEvent(EncodeCompleteEvent);
//get frame stats
HWGBX_H264HWEncoder_FrameStats dFrameStats;
dFrameStats.dwVersion =
HWGBX_H264HWENCODER_FRAMESTATS_VER;
HWGBX_GET_H264_STATS_PARAMS params = {0};
params.dwVersion = HWGBX_GET_H264_STATS_PARAMS_VER; params.dwBufferlndex = 0;
params.pHWGBX_H264HWEncoder_FrameStats = &d FrameStats; res = gbx_plFR>
HWGBXGetStatsFromH264HWEncoder(&params); if (res == HWGBX_SUCCESS) {
//send encoded frame
AVPacket pkt;
av_init_packet(&pkt);
pkt.size = dFrameStats.dwByteSize;
pkt.data = pBitStreamBuffer;
pkt.pts = (int64_t)gbx_dwFrameNumber++;
pkt.stream_index = 0;
if(encoder_send_packet("hwvideoencoder",
0/*rtspconf>
videojd*/, &pkt,
pkt.pts, NULL) < 0) {
gbx_error("encoder_send_packet: Error sending packefAn");
}
}
//wait for specific time before encoding another frame gettimeofday(&end_tv, NULL);
sleep_delta = frame_interval tvdiff_
us(&end_tv, &start_tv);
if(sleep_delta > 0) {
usleep(sleep_delta); }
}
}
gbx_error("video hwencoder: thread terminated\n"); return NULL;
}
#endif
static int
hw_vencoder_deinit(void *arg) {
static void
getSPS_PPSFromH264HWEncoder()
{
unsigned char buffer[255];
unsigned long dwSize = 0;
while(true)
{
if(!HWGBX_initialized)
usleep(100);
eise
break; }
if(HWGBX_initialized)
{
bzero(buffer, sizeof(buffer));
HWGBX_GET_H264_HEADER_PARAMS h264HeaderParams = {0}; h264HeaderParams.dwVersion =
HWGBX_GET_H264_HEADER_PARAMS_VER;
h264HeaderParams.pBuffer = buffer;
h264HeaderParams.pSize = (NvU32 *)&dwSize;
HWGBXRESULT result = HWGBX_SUCCESS;
result =
gbx_plFR>
HWGBXGetHeaderFromH264HWEncoder(&h264HeaderParams); h264_get_hwvparam(0, buffer, dwSize);
}
}
static int
hw_vencoder_ioctl(int command, int argsize, void *arg) {
int ret = 0;
gbx_ioctl_buffer_t *buf = (gbx_ioctl_buffer_t*) arg;
if(argsize != sizeof(gbx_ioctl_buffer_t))
return gbx_IOCTL_ERR_INVALID_ARGUMENT; switch(command) { case gbx_IOCTL_GETSPS:
getSPS_PPSFromH264HWEncoder(); if(buf>
size < _spslen[buf>
id])
return gbx_IOCTL_ERR_BUFFERSIZE; buf>
size = _spslen[buf>
id];
bcopy(_sps[buf>
id], buf>
ptr, buf>
size);
break;
case gbx_IOCTL_GETPPS:
//getSPS_PPSFromH264HWEncoder(); if(buf>
size < _ppslen[buf>
id])
return gbx_IOCTL_ERR_BUFFERSIZE; buf> size = _ppslen[buf>
id];
bcopy(_pps[buf>
id], buf>
ptr, buf>
size);
break;
case gbx_IOCTL_GETVPS:
if(command == gbx_IOCTL_GETVPS)
return gbx_IOCTL_ERR_NOTSUPPORTED;
break;
default:
ret = gbx_IOCTL_ERR_NOTSUPPORTED;
break;
}
return ret;
}
**************************************
End of Video Compression
*************************************************************************************
PCT/EP2015/001535 2015-07-24 2015-07-24 Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen WO2017016568A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/EP2015/001535 WO2017016568A1 (de) 2015-07-24 2015-07-24 Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen
KR1020187004544A KR102203381B1 (ko) 2015-07-24 2015-07-24 애플리케이션을 스트리밍하고 재생하기 위한 방법 및 전자통신 네트워크
US15/746,496 US20180243651A1 (en) 2015-07-24 2015-07-24 Method for streaming and reproducing applications (APPs) via a particular telecommunication system, telecommunication network for streaming and reproducing applications (APPs) via a particular telecommunication system and use of a telecommunication network for streaming and reproducing applications (APPs) via a particular telecommunication system
EP15752917.3A EP3325116A1 (de) 2015-07-24 2015-07-24 Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen
CN201580081901.0A CN108136259B (zh) 2015-07-24 2015-07-24 用于流式传输和用于再现应用的方法和电信网络
US17/000,878 US20210069590A1 (en) 2015-07-24 2020-08-24 Method for playing back applications from a cloud, telecommunication network for streaming and for replaying applications (apps) via a specific telecommunication system, and use of a telecommunication network for streaming and replaying applications (apps)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/001535 WO2017016568A1 (de) 2015-07-24 2015-07-24 Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/746,496 A-371-Of-International US20180243651A1 (en) 2015-07-24 2015-07-24 Method for streaming and reproducing applications (APPs) via a particular telecommunication system, telecommunication network for streaming and reproducing applications (APPs) via a particular telecommunication system and use of a telecommunication network for streaming and reproducing applications (APPs) via a particular telecommunication system
US17/000,878 Continuation-In-Part US20210069590A1 (en) 2015-07-24 2020-08-24 Method for playing back applications from a cloud, telecommunication network for streaming and for replaying applications (apps) via a specific telecommunication system, and use of a telecommunication network for streaming and replaying applications (apps)

Publications (1)

Publication Number Publication Date
WO2017016568A1 true WO2017016568A1 (de) 2017-02-02

Family

ID=53887061

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/001535 WO2017016568A1 (de) 2015-07-24 2015-07-24 Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen

Country Status (5)

Country Link
US (1) US20180243651A1 (de)
EP (1) EP3325116A1 (de)
KR (1) KR102203381B1 (de)
CN (1) CN108136259B (de)
WO (1) WO2017016568A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200204607A1 (en) * 2016-02-09 2020-06-25 Awingu Nv A broker for providing visibility on content of storage services to an application server session
WO2023137472A2 (en) 2022-01-14 2023-07-20 Tune Therapeutics, Inc. Compositions, systems, and methods for programming t cell phenotypes through targeted gene repression
WO2023137471A1 (en) 2022-01-14 2023-07-20 Tune Therapeutics, Inc. Compositions, systems, and methods for programming t cell phenotypes through targeted gene activation
WO2024064642A2 (en) 2022-09-19 2024-03-28 Tune Therapeutics, Inc. Compositions, systems, and methods for modulating t cell function

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109069924A (zh) * 2015-12-21 2018-12-21 格瑞拉伯克斯有限公司 用于播放云端中的应用程序的方法以及用于经由确定的远程通信系统来流处理和再现应用程序（app）的远程通信网络以及用于流处理和再现应用程序（app）的远程通信网络的应用
WO2018041324A1 (de) * 2016-09-03 2018-03-08 Gorillabox Gmbh Verfahren zum streamen und zur wiedergabe von anwendungen über ein bestimmtes telekommunikationssystem, telekommunikationsnetz zum durchführen dieses verfahrens und verwendung eines derartigen telekommunikationsnetzes
TWI768972B (zh) * 2021-06-17 2022-06-21 宏碁股份有限公司 遊戲系統及其遊戲伺服器操作方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009073830A1 (en) 2007-12-05 2009-06-11 Onlive, Inc. Streaming interactive video client apparatus
WO2010141522A1 (en) 2009-06-01 2010-12-09 Gaikai, Inc. Qualified video delivery
WO2012037170A1 (en) 2010-09-13 2012-03-22 Gaikai, Inc. Dual mode program execution and loading
US20140073428A1 (en) 2008-12-15 2014-03-13 Sony Computer Entertainment America Llc Intelligent Game Loading
WO2014186858A1 (en) * 2013-05-23 2014-11-27 KABUSHIKI KAISHA SQUARE ENlX HOLDINGS (ALSO TRADING AS SQUARE ENIX HOLDINGS CO., LTD.) Dynamic allocation of rendering resources in a cloud gaming system
US20150018094A1 (en) * 2013-07-10 2015-01-15 Sony Computer Entertainment Inc. Content providing method, content providing server, and content providing system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6697869B1 (en) * 1998-08-24 2004-02-24 Koninklijke Philips Electronics N.V. Emulation of streaming over the internet in a broadcast application
US8261315B2 (en) * 2000-03-02 2012-09-04 Tivo Inc. Multicasting multimedia content distribution system
US9723319B1 (en) * 2009-06-01 2017-08-01 Sony Interactive Entertainment America Llc Differentiation for achieving buffered decoding and bufferless decoding
US8369834B2 (en) * 2010-09-24 2013-02-05 Verizon Patent And Licensing Inc. User device identification using a pseudo device identifier

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009073830A1 (en) 2007-12-05 2009-06-11 Onlive, Inc. Streaming interactive video client apparatus
US20140073428A1 (en) 2008-12-15 2014-03-13 Sony Computer Entertainment America Llc Intelligent Game Loading
WO2010141522A1 (en) 2009-06-01 2010-12-09 Gaikai, Inc. Qualified video delivery
WO2012037170A1 (en) 2010-09-13 2012-03-22 Gaikai, Inc. Dual mode program execution and loading
WO2014186858A1 (en) * 2013-05-23 2014-11-27 KABUSHIKI KAISHA SQUARE ENlX HOLDINGS (ALSO TRADING AS SQUARE ENIX HOLDINGS CO., LTD.) Dynamic allocation of rendering resources in a cloud gaming system
US20150018094A1 (en) * 2013-07-10 2015-01-15 Sony Computer Entertainment Inc. Content providing method, content providing server, and content providing system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Cloud gaming - Wikipedia, the free encyclopedia", 24 June 2015 (2015-06-24), XP055268633, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Cloud_gaming&oldid=668477716> [retrieved on 20160426] *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200204607A1 (en) * 2016-02-09 2020-06-25 Awingu Nv A broker for providing visibility on content of storage services to an application server session
US11089080B2 (en) * 2016-02-09 2021-08-10 Awingu Nv Broker for providing visibility on content of storage services to an application server session
WO2023137472A2 (en) 2022-01-14 2023-07-20 Tune Therapeutics, Inc. Compositions, systems, and methods for programming t cell phenotypes through targeted gene repression
WO2023137471A1 (en) 2022-01-14 2023-07-20 Tune Therapeutics, Inc. Compositions, systems, and methods for programming t cell phenotypes through targeted gene activation
WO2024064642A2 (en) 2022-09-19 2024-03-28 Tune Therapeutics, Inc. Compositions, systems, and methods for modulating t cell function

Also Published As

Publication number Publication date
CN108136259A (zh) 2018-06-08
KR20180044899A (ko) 2018-05-03
CN108136259B (zh) 2021-08-20
US20180243651A1 (en) 2018-08-30
KR102203381B1 (ko) 2021-01-15
EP3325116A1 (de) 2018-05-30

Similar Documents

Publication Publication Date Title
WO2017016568A1 (de) Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen
DE602004006981T2 (de) Datenabrufende und -übertragende vorrichtungen und verfahren
US9479807B1 (en) Gateway-based video client-proxy sub-system for managed delivery of A/V content using fragmented method in a stateful system
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
US20040031052A1 (en) Information platform
DE112011103333T5 (de) Medienkonvergenzplattform
US11089076B1 (en) Automated detection of capacity for video streaming origin server
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
US10887363B1 (en) Streaming decision in the cloud
DE112011101911T5 (de) Fragmentierte Dateistruktur für die Ausgabe von Live-Medien-Streams
US20230045876A1 (en) Video Playing Method, Apparatus, and System, and Computer Storage Medium
CN106572382A (zh) 多屏互动方法及系统、可扩展通讯和表示协议系统
Tizon et al. MPEG-4-based adaptive remote rendering for video games
Begen et al. Road to salvation: streaming clients and content delivery networks working together
US20040006627A1 (en) Content delivery system
US9118947B2 (en) Multi-vision virtualization system and method
CA3041692C (en) Multichannel video programming distributor stream controller
GB2446195A (en) Data Transmission
US20210069590A1 (en) Method for playing back applications from a cloud, telecommunication network for streaming and for replaying applications (apps) via a specific telecommunication system, and use of a telecommunication network for streaming and replaying applications (apps)
CN101888406B (zh) 机顶盒、业务服务器、节目下载方法、发送方法及系统
CN110740337B (zh) 直播播放方法、装置、电子设备及存储介质
EP3507958B1 (de) Verfahren zum streamen und zur wiedergabe von anwendungen über ein bestimmtes telekommunikationssystem und verwendung
DE102005052207A1 (de) Verfahren zum Übertragen von einem Datenstrom von einer Datenquelle zu einer Datensenke sowie Datensenkengerät, Datenquellgerät und Gerät zur Durchführung des Verfahrens
CN116636224A (zh) 可替代联网应用程序服务的系统和方法
CN108616760A (zh) 一种基于浏览器的直播方法、服务器、主播端和用户端

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15752917

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15746496

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20187004544

Country of ref document: KR

Kind code of ref document: A