SYSTEMS AND METHODS FOR DELAYED POST PROCESSES IN VIDEO CODING

Abstract

A computer-implemented method for deferring POST processes, comprising the following steps: Transmitted by a server (100), an instruction to a client application (120) for measuring the client hardware capability of a client computer system (116) running the client application; Transmitted by the server (100), an instruction to the client application (120) to sum a known load of one or more predefined post-process delay candidates in order to assess how many post-process delay candidates are capable of being migrated to client hardware; and Received by the server (100) a post-process delay list, which includes a list of delayed post-processes, from the client application (120), skip the delayed post-processes during a post-process phase of an initial video frame and send an instruction to the client application (120) to render a frame.

Description

RELATED APPLICATIONS

[0001] This application claims the benefit of the following US provisional applications No. 62 / 488,526, filed on April 21, 2017, and No. 62 / 618,498, filed on January 17, 2018. BACKGROUND OF THE INVENTION

[0002] Remote gaming applications, where a server-side game is controlled by a client-side player, have attempted to encode the video output of a three-dimensional (3D) graphics engine in real time using existing or custom encoders. However, the interactive nature of video games, particularly the feedback loop between video output and player input, makes game video streaming far more sensitive to latency than traditional video streaming. Existing video encoding methods can consume significant processing power and little else to reduce encoding time. New methods that integrate the encoding process into the video playback process can enable a substantial reduction in encoding time while simultaneously reducing processing power, improving the quality of the encoded video, and maintaining the original bitstream data format to preserve interoperability with existing hardware devices.

[0003] Typical video rendering pipelines are separate and independent from video coding pipelines, with little overlap between the processes and know-how in the two areas. As a result, some of the visual effects and post-processing applied in the video rendering pipeline are counterproductive to the video coding process, leading to video artifacts, increased encoded video size, and longer encoding times. However, these visual effects are still desirable in the resulting decoded video.

[0004] Integrating video rendering and video encoding pipelines allows post-processing effects to be deferred to improve the encoding process. For example, simulated film grain introduces randomly occurring animated grain that is difficult for typical coders to handle without significantly impacting video quality or compression ratio. Some video encoding methods attempt to remove this additional visual noise before encoding, but these methods are offline-only and computationally intensive. Disabling this specific post-process in the rendering pipeline automatically makes the video easier to encode. The post-process can then be applied after the video has been decoded.In the case of cinematic grain, piecing the grain together from the decoded video is not computationally intensive, can be done in real time at the decoder, and can improve the subjective video quality by masking other encoding artifacts.

[0005] International Patent Application No. WO2016172314 A1 (“the '314 application') discloses systems and methods aimed at artistically intended content encoding. An encoding user interface allows a user to specify an artistic set and configure the treatment of pixels and / or blocks associated with that artistic set, such as fidelity enhancement, a QP adjustment value, and / or post-processing. Examples of artistic intent that can be added to the video output include an encoder being able to remove film grain from the original signal before encoding it and using the film grain SEI to instruct the decoder on how to regenerate the film grain and add it back to the video signal before it is displayed.The present invention can be distinguished from the 314 application at least in that the 314 application does not disclose the deactivation of certain post-processes in the rendering pipeline before encoding and then the application of these post-processes after decoding the video. Consequently, the present invention is an improvement on this computer technology because it provides improved encoding and decoding of video data without significant cost to video quality or compression ratio. The present invention is also an improvement because it improves the resulting bandwidth, bitrate, and encoding time and can be used in real-time video streaming applications with improved video quality.

[0006] U.S. Patent No. 9,609,330 (“the '330 patent”) discloses content-adaptive entropy coding of modes and reference data. This means that a pre-analyzer subsystem analyzes content to compute various types of parameters useful for improving the efficiency and speed of video coding. These parameters include horizontal and vertical gradient information (Rs, Cs), variance, spatial complexity per frame, temporal complexity per frame, scene change detection, motion range estimation, gain detection, prediction distance estimation, number of objects, area boundary detection, spatial complexity mapping, focus estimation, and film grain estimation. The parameters generated by the pre-analyzer subsystem can then be consumed by the encoder or quantized and passed to the decoder.The present invention can again be distinguished from the technology disclosed in patent 330, at least because this technology does not deactivate certain post-processes in the rendering pipeline before encoding and then applies these post-processes after the video has been decoded. The present invention therefore represents an improvement on the computer technology of patent 330, since it offers improved encoding and decoding of video data without any significant cost to video quality or compression ratio, and because it can be used in real-time video streaming applications with improved video quality.

[0007] U.S. Patent No. 9,762,911 (“the '911 Patent”) discloses systems and methods for techniques related to content-adaptive prediction and entropy coding of motion vectors. The disclosed technology enables the reception of first video data and second video data for entropy coding at an entropy encoder module. The first video data and the second video data can be of different data types (e.g., head data, morphing parameters, synthesis parameters, or global map data, or motion vectors, or intra-prediction partition data, or so forth, as further explained herein).A first entropy coding technique can be determined for the first video data based on a parameter associated with that data, such as the number of compressed bits, a predetermined indicator or flag, a predetermined threshold, a heuristically determined threshold, or the like. In some examples, the first entropy coding technique can be selected from an adaptive symbol-driven variable-length coding technique or an adaptive variable-length proxy coding technique. The first video data can be entropy-coded using the first entropy coding technique, and the second video data can also be entropy-coded using the first entropy coding technique.The present invention is distinguishable at least because the technology disclosed in the 9 / 11 patent does not involve the selective disabling of post-processes in the rendering pipeline before encoding and then applying these post-processes after the video has been decoded. Again, the present invention represents an improvement on the computer technology of the 9 / 11 patent, as it provides improved encoding and decoding of video data without significant cost to video quality or compression rate. The present invention is also an improvement because it improves the resulting bit rate and encoding time and can be used in real-time video streaming applications with improved video quality.

[0008] As can be seen from the above discussion about the state of the art in this technology, there is a need in the field of technology to improve current computer technology in connection with video coding in gaming environments.

[0009] A method for operating a multimedia player is known from publication US 2011 / 0221960A1. The method comprises decoding an audio stream of the multimedia player and rendering the decoded audio stream in the multimedia player, updating the media player's media time with an audio timestamp of the rendered audio stream during playback of the audio stream, and, during decoding and rendering of the audio stream, decoding a video stream and checking the media clock to determine whether a video timestamp of the decoded video stream is within a media time threshold, and if not, adjusting the video stream post-processing to reduce the video stream post-processing time.

[0010] Publication US 2013 / 0 016 107 A1 describes an approach to rendering graphics that can utilize both server-side and client-side rendering for the same display frame.

[0011] Publication EP 3 029 940 A1 discloses a method in which the processing of a video stream is divided between a video stream processing device and a client device.

[0012] Publication US 2013 / 0 150 161 A1 presents technologies that allow the preprocessing of graphics at a rendering source to be coordinated with the postprocessing on a display device. SUMMARY OF THE INVENTION

[0013] The object of the present invention is to provide an improved computer-implemented method for post-processing and a corresponding system for delaying post-processing.

[0014] This problem is solved by the subject matter of main claim 1 and dependent claim 14, which define the present invention.

[0015] Preferred embodiments of the present invention are the subject of the dependent claims.

[0016] In accordance with one aspect of the present invention, latency and encoding times are reduced by techniques in which a server sends an instruction to a client application to measure the capability of the client hardware and sends an instruction to a client application to sum a known load of one or more predetermined post-process delay candidates to evaluate how many post-process delay candidates are capable of being deferred to the client hardware. The client application then creates and builds the post-process delay list in reverse order. The server then receives the post-process delay list, skips the list of delayed post-processes during the post-processing phase of an initial video frame, and sends an instruction to a client application to render a frame.

[0017] According to another aspect of the present invention, a client application performs a callback or query on one or more operating system events to determine whether the capability of the client hardware should be remeasured.

[0018] According to a further aspect of the present invention, the capability of the client hardware is measured by detecting available instruction sets, memory, CPU and / or GPU characteristics.

[0019] According to a further aspect of the present invention, it is evaluated how many post-process delay candidates are able to be shifted to the client hardware by measuring the frame rate and / or resource consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] A more comprehensive appreciation of the invention and many of its associated advantages is easily obtained, as it is better understood by referring to the following detailed description when considered in conjunction with the accompanying drawings, wherein: Fig. 1 is a block diagram illustrating an exemplary 3D graphics engine that reproduces a video for viewing on a remote client according to an embodiment of the invention; Fig. 2 is a flowchart illustrating the exemplary steps required to improve encoding time or subjective video quality by shifting post-processing per pixel according to an embodiment of the invention; Fig.3 is a diagram illustrating an exemplary minimal implementation of delayed per-pixel quality during the video playback, encoding, and decoding phases according to an embodiment of the invention; and Fig. 4 is a flowchart illustrating the exemplary communication between a server and a client to synchronize the list of delayed POST processes according to an embodiment of the invention. DETAILED DESCRIPTION OF PREFERRED EXECUTION FORMS

[0021] For the sake of clarity, specific terminology is used in the description of the preferred embodiments of the invention illustrated in the drawings. However, the invention is not intended to be limited to these specific terms, and it should be understood that each specific term encompasses all technical equivalents that function similarly to achieve a similar purpose. Several preferred embodiments of the invention are described for illustrative purposes, and it is understood that the invention can also be embodied in other forms not expressly shown in the drawings.

[0022] Post-processing pipelines can perform many complex processes, including anti-aliasing, motion blur, depth of field, color correction, blooming, film grain, chromatic aberration, vignetting, and tone mapping. Some of these effects actively impact the encoding process, increasing encoding times and reducing compression rates compared to unprocessed frames. Waiting for certain post-processing steps before an image is decoded can improve the perceived video quality and offer additional benefits.

[0023] During client application development, the balance between coding time, bandwidth, and perceived quality should be evaluated for each post-process in the rendering pipeline to determine which post-processes are good candidates for deferral. The client then uses this list of deferral candidates at runtime to determine which post-processes can be postponed to the client.

[0024] Each post-process should be tested to measure its impact on the encoding process. First, a series of reference frames should be passed through the unmodified rendering and encoding lines, and the encoding time and encoded frame size should be measured. The post-processes should then be disabled sequentially in the rendering pipeline, and the encoding time and encoded frame size should be compared to the control results. These measurements will help determine which post-processes are good candidates for a shift. Almost any post-process effect that increases image entropy, as measured by an increased encoded frame size, would likely be a good candidate for a shift. For example, a simulated film grain post-process adds random noise to an image, resulting in lower compression ratios.In certain situations, chromatic aberration and bloom can increase image entropy and lead to lower compression rates. Almost any post-processing effect that reduces entropy or image data should not be deferred, as entropy reductions decrease the encoding effort.

[0025] Post-processes that do not alter image entropy can be selected as candidates for delay to achieve secondary goals such as subjectively improving video quality or reducing server load. For example, color grading may not affect encoding time or bandwidth usage, but it can lead to a measurable reduction in server-side computational load if deferred to the client. Similarly, anti-aliasing can improve subjective video quality and drastically reduce server-side load if deferred. Additional testing should be conducted to determine whether deferring entropy-neutral post-processes is worthwhile. For instance, a similar test procedure using reference frames can be used to compare server load before and after deferring an entropy-neutral post-process.

[0026] The client application should be able to perform the post-processing calculations for each rendering candidate. Some code refactoring may be necessary to move these functions to the client application. Post-processes at the end of the rendering pipeline, such as film grain, chromatic aberration, or vignetting, are generally easier to move to the client application than those that occur earlier in the rendering pipeline, such as anti-aliasing or depth of field. There may be some cases where moving a post-process results in it being applied in non-linear space when it is typically applied in linear space, such as post-processes applied before tonal correction, like chromatic aberration, bloom, or vignetting.The process can be applied directly in gamma space and may not be mathematically precise, but the difference may be imperceptible to the viewer, and the overall subjective quality can be improved. Alternatively, at the cost of some client-side computation cycles and a loss of image quality, the client application can convert the image back to linear space, apply the post-processing, and then convert it back to gamma space. Converting back to linear space results in a loss of quality because the image was quantized and compressed during encoding. These subjective quality decisions should be made during the client application development phase.

[0027] All post-processes that the client application can perform form the basis for the deferral candidate list. The deferral candidate list should be in the same order as they appear in the rendering pipeline to maintain dependencies. Each deferral candidate on the list should also be linked to hardware feature requirements, such as memory minimums or GPU requirements.

[0028] Fig.Figure 1 illustrates an example system in which post-processing is shifted at the pixel level during video rendering. This example system represents a real-time remote gaming streaming application that benefits most from the subjective quality improvements and reduced encoding times resulting from shifting quality processes at the pixel level compared to other types of video systems. In this system, a server 100 hosts the video game software 102 and a graphics engine 104, which handles the video output. The video is encoded in an encoder 106, and the encoded video data 108 is transmitted to a remote client. The server architecture 100 is any combination of hardware or software that can support the functions of the graphics engine 104 and the encoder 106.In the given example, the graphics engine 104 can be implemented as, for example, a GPU 110 that runs video game software 102, which is loaded into a computer-readable memory 112, while the encoder 106 (also called encoder) can be implemented as a CPU 114 with video coding software.

[0029] The remote client computer system 116 is capable of running a client-side encoder 118 for decoding the transmitted encoded video data 108 and a client application 120 for applying the delayed pixel-quality post-processing. The client computer system 116 also includes a display controller 122 for controlling the display hardware 124. The inputs from the client-side input peripheral 126 are converted by the client application 120 into control data 128, which is sent back to the game software 102 running on the server 100. Depending on the specific implementation of the delayed pixel-perfect post-processing, some additional control data 128 may need to flow from the server-side software 102 to the client application 120 to ensure that the correct post-processing is applied to a given video frame.

[0030] Fig.Figure 2 illustrates the steps required to shift post-processing in a system that renders, encodes, and decodes videos. At step 200, the rendering pipeline begins as usual on server 100. No changes to the rendering process are required before the post-processing phase.

[0031] In step 202, during the post-processing phase of video rendering in the graphics engine 104 of server 100, all post-processing that can be deferred should be skipped. Any number of post-processes can be skipped if the client computer system 116 has the necessary processing power to apply all deferred post-processes. Fig. Section 4 describes in detail how Server 100 determines which POST processes are postponed. After skipping a postponed POST process, the rendering pipeline should continue until the frame is fully rendered.

[0032] In step 204, the resulting frame is encoded at encoder 106. Based on the selection of delayed post-processes, the encoding time can be faster and the encoded data can require less bandwidth. For example, if a post-processing step for film grain is delayed, encoder 106 has an easier time encoding the image without the introduced noise.

[0033] In step 206, the encoded video data is stored 108 or, if necessary, transferred to the remote client computer system 116. In a real-time video game streaming application, as in the example from Fig. 1. The video data 108 are transmitted immediately. In alternative embodiments of the system, the encoded video data 108 can be stored on a server 100 for on-demand streaming or stored on physical media.

[0034] In step 208, the encoded video is decoded on encoder 118 of the remote client computer system 116. No changes need to be made to the decoding process.

[0035] In step 210, a software application applies all post-processes that have been moved in the same order as they would appear in the rendering pipeline. This software, which is in Fig. If client application 120 is represented as the client application, it may also need to receive control data 128 from the server 100 if the deferred post-processing changes from frame to frame. The client application 120 may also need to send control data 128 if the video is interactive, as in video game streaming systems. The client application 120 can be sparse, depending on the computational complexity requirements of the deferred post-processing, which can allow for a greater bandwidth of processing power at the client.

[0036] Fig.Figure 3 illustrates the implementation of delayed post-processing in the example system of Fig.1. A typical 3D rendering pipeline, shown under "RENDERING PIPELINE," step 300, on server 100, consists of the "APPLICATION" stage, step 302, the "GEOMETRY" stage, step 304, and rasterization, shown as "RASTERIZATION," step 306. The output of the rasterization stage at "RASTERIZATION," step 306, is a complete video image, which is often enhanced by post-processing at "POST-PROCESSING," as shown in step 308. Some post-processes impact the encoding time or bandwidth during the encoding process at "ENCODING," step 310, and these post-processes are skipped in the post-processing stage at "POST-PROCESSING," step 308, if the client can apply them later. The remaining post-processing steps that are not moved to client 116 are applied as usual during post-processing at “POST-PROCESSING”, step 308.The source video is encoded at “ENCODING”, step 310 and transferred at “TRANSMISSION”, step 312.

[0037] When client 116 receives the encoded video image, it is decoded at "DECODING," step 314. At this point, all delayed post-processing is applied to the decoded frame at "DELAYED POST-PROCESSING," step 316. For example, with film grain, an animated effect can be cached in advance and composited over the decoded image with relatively little computational effort. Real-time solutions for color correction, dithering, and video sharpening already exist, which can be applied based on a client's processing power. The resulting video image is displayed at "DISPLAY," step 318.

[0038] Fig.Figure 4 illustrates a process in which the client application 120 creates the list of POST processes to be moved and transmits the list to the server 100.

[0039] At step 400, client application 120 measures the ability of the client hardware to determine which POST processes can be moved to client 116. Client capability can be measured by feature detection for hardware information such as available instruction sets, memory, CPU, or GPU.

[0040] At step 402, the client application 120 reads the list of potential delay candidates and discards any for which the client does not meet the hardware requirements. The delay of the candidates' post-processes should be compared to the client's real-time performance to measure the client's performance. Delay candidates are added to the benchmarking process sequentially until the client is no longer able to maintain the desired performance as measured by frame rate, resource consumption, or other live metrics. Benchmarking can be performed during client application installation, during the initial load of the client application 120, or on every application load.

[0041] Client 116 should perform post-processing for as many deferral candidates as possible. The deferral list is created in reverse order to keep the overall sequence of operations close to the original rendering pipeline order. For example, a mobile device might only run the last post-processes, a laptop the three post-processes at the end of the rendering pipeline, while a new desktop computer might run all post-processes in the deferral candidate list.

[0042] At step 404, client 116 sends the list of POST processes to be moved to server 100.

[0043] In step 202, server 100 uses the list of delayed post-processing operations during the post-processing phase of the first video frame. All post-processes on the deferral list are skipped.

[0044] At step 206, the encoded video data stream 108 begins transmission to client 116. Since client 116 sent the delay list before any frames were generated, no additional metadata needs to be sent from server 100 to client 116. Client 116 automatically knows which POST processes were delayed.

[0045] In step 210, client 116 applies all POST processes in the deferral list. Client 116 will continue to apply the deferred POST processes to future frames.

[0046] There may be scenarios where client capabilities change during runtime, requiring a modification of the list of delayed POST processes. For example, if the client application is running on a mobile device that has just entered power-saving mode, the client may reduce the number of delayed POST processes. In this example, the client application would need to register a callback or query operating system (“OS”) events to monitor for changes in battery status. In step 412, the client application responds to a recent environmental change by remeasuring the client capability. An environmental change can be any change that affects the hardware performance of the remote client computer system. For the example above, power-saving mode reduces the clock frequency by a multiplier that can be retrieved directly.Changing the clock multiplier can provide a rough estimate of the change in client capability. Alternatively, an additional benchmark in battery-saving mode can be added to the benchmark phase described in step 402.

[0047] If the client capability has changed, the client application will re-evaluate which POST processes can be deferred at step 414. In the battery saver mode example, the delay list can shrink proportionally to the change in the clock multiplier. For example, if battery saver mode reduces the clock frequency by 50%, the delay list will shrink by at least half. If the client deferred four POST processes, the list will be reduced to two. Otherwise, if battery saver mode benchmarking was performed previously, the delay list will already be known.

[0048] When the deferral list is changed, client 116 sends the modified deferral list to server 100 at step 416. Client 116 continues to apply the POST processes from the original deferral list until it receives a message from server 100, preferably containing a different list of deferred POST processes.

[0049] In step 418, server 100 applies the modified delay list to the next available frame. To synchronize with client 116, some metadata is applied to this frame.

[0050] In step 420, the frame of the encoded video data 108 is sent with the corresponding metadata.

[0051] The client waits until it receives the metadata flag. At step 422, client 116 begins processing frames according to the modified deferral list. Client 116 will continue to apply the deferred post-processing according to the modified deferral list. If the runtime environment changes again, the deferral list can grow or shrink again starting from step 412. If the deferral list shrinks due to a temporary environment change, such as battery saving mode on a mobile device, client application 120 should grow the deferral list as quickly as possible so that the maximum possible post-processing is deferred at any given time. EXAMPLE 1: Benchmark test results

[0052] Film grain introduces random visual noise that significantly impacts the encoder's compression ratio. Applying post-processing techniques like film grain on the client side results in smaller encoded image sizes.

[0053] Experimental bitrate measurements were taken while the graphics engine generated a 1280x720 resolution output at 60 frames per second. These measurements were then averaged over 60 frames per second to determine the average bitrate. The measurements compare the bitrate of a video stream with film grain applied server-side to the bitrate of a video stream with film grain shifted to the client. These measurements are repeated for three different film grain sizes and two encoder quality settings. Film grain 1 represents the smallest grain size, while film grain 3 represents the largest. The experimental results are presented in Tables 1 and 2. Table 1 shows the results at an encoder quality of 16, while Table 2 shows the results at an encoder quality of 20. TABLE 1: Bitrate results with an encoder quality setting of 16 Encoder quality = 16 Server-side film grain Delayed cinematic grain Film grain 1 550 KB / s 270 KB / s Film grain 2 1700 KB / s 270 KB / s Film grain 3 1900 KB / s 270 KB / s TABLE 2: Bitrate results with an encoder quality setting of 20 Coder quality = 20 Server-side cinematic grain Delayed film grain Film grain 1 150 KB / s 140 KB / s Film grain 2 270 KB / s 140 KB / s Film grain 3 520 KB / s 140 KB / s

[0054] Based on experimental results, it is evident that post-processing such as film grain leads to larger encoded image sizes, which is undesirable. These negative effects become more pronounced at higher encoder quality settings and are further amplified with increasing amounts of introduced noise. However, by shifting the film grain to the client, a drastic reduction in bitrate can be achieved, as shown in Tables 1 and 2, where the bitrate is reduced to 270 KB / s and 140 KB / s, respectively. Regardless of the amount of introduced noise, measured by the size of the film grain in these experiments, the bitrate remains stable for a given encoder quality.

[0055] Similarly, as shown in Table 3 below, experimental encoding times were measured while the graphics engine generated a 1280x720 resolution output at 60 frames per second for several encoder quality settings. The measurements compare the encoding times for a video stream where film grain is applied server-side with the encoding time for a video stream where the film grain is shifted to the client. The size of the film grain remains constant across all measurements. As can be seen from Table 3, the reductions in encoding times achieved using the techniques described herein are more pronounced at higher encoder quality settings. TABLE 3: Latency results across encoder quality settings Encoder quality Server-side film grain Delayed cinematic grain 15 16 ms 10 ms 17 15 ms 10 ms 20 11 ms 9 ms 25 9 ms 7 ms 40 9 ms 7 ms

[0056] The foregoing description and drawings are to be regarded only as illustrations of the principles of the invention. The invention is not intended to be limited by the preferred embodiment and can be implemented in various ways that are readily apparent to those skilled in the art. Numerous applications of the invention will be readily apparent to those skilled in the art. Therefore, it is not desirable to limit the invention to the specific examples disclosed or to the exact construction and operation. Rather, all suitable modifications and equivalents that fall within the scope of the invention may be considered.

Claims

[1] Computer-implemented method for postponing POST processes, comprising the following steps: Transmitted by a server (100), an instruction to a client application (120) for measuring the client hardware capability of a client computer system (116) running the client application; Transmitted by the server (100), an instruction to the client application (120) to sum a known load of one or more predefined post-process delay candidates in order to assess how many post-process delay candidates are capable of being migrated to client hardware; and Received by the server (100) a post-process delay list, which includes a list of delayed post-processes, from the client application (120), skip the delayed post-processes during a post-process phase of an initial video frame and send an instruction to the client application (120) to render a frame. [2] Computer-implemented method according to claim 1, wherein the post-process delay list is created in reverse order. [3] Computer-implemented method according to claim 1, wherein the server (100) applies the updated delay list to the next available video frame. [4] Computer-implemented method according to claim 1, wherein the server (100) returns the first or next available video image to the client application (120) with a metadata flag. [5] Computer-implemented method according to claim 1, further comprising the step of the server (100) transmitting encoded video data (108) to the client application (120) without metadata associated with post-processes. [6] Computer-implemented method according to claim 1, wherein the list of post-process delay candidates is recalculated based on changes in the battery status of the client hardware. [7] Computer-implemented method according to claim 1, further comprising the step of the server (100) to encode video data, wherein the skipped post-processes are not used in the encoding. [8] Computer-implemented method according to claim 7, further comprising transferring the encoded video data (108) to the client application (120). [9] Computer-implemented method according to claim 7, wherein the encoded video data (108) are stored before being transmitted to the client application (120). [10] Computer-implemented method according to claim 9, wherein the encoded video data (108) are stored on a server for on-demand streaming or on physical media. [11] Computer-implemented method according to claim 8, wherein the encoded video data (108) are for video game streaming. [12] Computer-implemented method according to claim 11, wherein the server (100) receives control data (128) from the client application (120). [13] Computer-implemented method according to claim 8, wherein the encoded video data (108) are decoded on the client computer system (116) and the client application (120) applies the skipped post-processes to the decoded video data. [14] System for delaying post-processes, wherein a server (100) executes a method according to any one of claims 1 to 13 over a network.

Images