This disclosure relates generally to real-time video decoding and, more particularly, to low latency sub-frame level video decoding.
A cloud-computing application such as cloud-gaming may involve generating data in real-time on a remote server, encoding the aforementioned data as video and transmitting the aforementioned video to a client device through a network (e.g., Internet, Wide Area Network (WAN), Local Area Network (LAN)). The interactivity of the cloud-computing application may demand minimal latency. In the latency-critical cloud-gaming scenario, latency beyond a threshold may severely degrade the gaming experience of a user at a client device.
Disclosed are a method, a device and/or a system of low latency sub-frame level video decoding.
In one aspect, a method includes transmitting encoded video data related to video frames of a video stream from a source to a client device through a network such that a packet of the encoded video data is limited to including data associated with one portion of a video frame. The video frame includes a number of portions including the one portion. The method also includes time-stamping, through the client device and/or the source, the video frames such that packets of a video frame have a common timestamp. Further, the method includes decoding, at the client device, the video frames at a level of a portion of a video frame instead of a level of the video frame based on the time-stamping.
In another aspect, a non-transitory medium, readable through a data processing device and including instructions embodied therein that are executable through the data processing device, is disclosed. The non-transitory medium includes instructions to receive encoded video data related to video frames of a video stream transmitted from a source at the data processing device through a network such that a packet of the encoded video data is limited to including data associated with one portion of a video frame. The video frame includes a number of portions including the one portion. The non-transitory medium also includes instructions to time stamp, through the data processing device, the video frames such that packets of a video frame have a common timestamp. Further, the non-transitory medium includes instructions to decode, at the data processing device, the video frames at a level of a portion of a video frame instead of a level of the video frame based on the time-stamping.
In yet another aspect, a system includes a source to transmit encoded video data related to video frames of a video stream such that a packet of the encoded video data is limited to including data associated with one portion of a video frame. The video frame includes a number of portions including the one portion. The system also includes a network and a client device communicatively coupled to the source through the network. The client device is configured to receive the transmitted encoded video data through the network. The client device and/or the source is configured to time-stamp the video frames such that packets of a video frame have a common timestamp. The client device is further configured to decode the video frames at a level of a portion of a video frame instead of a level of the video frame based on the time-stamping.
The methods and systems disclosed herein may be implemented in any means for achieving various aspects, and may be executed in a form of a machine-readable medium embodying a set of instructions that, when executed by a machine, cause the machine to perform any of the operations disclosed herein. Other features will be apparent from the accompanying drawings and from the detailed description that follows.
The embodiments of this invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.
Example embodiments, as described below, may be used to provide a method, a device and/or a system of low latency sub-frame level video decoding. Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments.
It should be noted that data streaming system 100 is not limited to the cloud-gaming environment mentioned above. For example, data source 102 may also be a mere personal computer transmitting data wirelessly (e.g., through Wi-Fi®) to a tablet (an example client device 104) coupled to a television (for display purposes) through a High-Definition Multimedia Interface (HDMI) cable. All example data streaming systems having the capability to incorporate concepts discussed herein therein are within the scope of the exemplary embodiments.
In typical solutions, a video frame may be received at client device 104, following which a decoder thereat decodes the video frame. The aforementioned decoding may be started only after the complete video frame is received; in other words, the complete video frame may have to be received prior to even starting decoding of the first macroblock thereof.
It is obvious that an operating system 112 may execute on client device 104.
In one or more embodiments, output data associated with processing through processor 108 may be input to a multimedia processing unit 118 configured to perform encoding/decoding associated with the data. In one or more embodiments, the output of multimedia processing unit 118 may be rendered on a display unit 120 (e.g., Liquid Crystal Display (LCD) display, Cathode Ray Tube (CRT) monitor) through a multimedia interface 122 configured to convert data to an appropriate format required by display unit 120.
File reader 208 may be configured to enable reading of video data 116. Parser 210 (e.g., Moving Picture Experts Group (MPEG) parser, Audio-Video Interleave (AVI) parser, H.264 parser) may parse video data 116 into constituent parts thereof. Decoder 212 may decode a compressed or an encoded version of video data 116 and renderer 214 may transmit the decoded data to a destination (e.g., a rendering device). The rendering process may also include processes such as displaying multimedia on display unit 120, playing an audio file on a soundcard, writing the data to a file etc. It is obvious that the aforementioned engines (or, modules) are merely shown for illustrative purposes and that variations therein are within the scope of the exemplary embodiments.
Further, it is obvious that multimedia framework 200 is merely shown for illustrative purposes, and that exemplary embodiments are not limited to implementations involving multimedia framework 200.
In one or more embodiments, decoder 212 may have a buffer (not shown; can be part of memory 110 or memory 110 itself) associated therewith; the aforementioned buffer may have data associated with one slice (say, slice 4021) stored therein. As discussed above, the depacketizer may add timestamp information to the slice and transmit the data in the buffer to decoder 212, if the depacketizer is implemented separately from decoder 212. In one or more embodiments, decoder 212 may detect the presence of a new frame or the same frame being decoded based on the timestamp information. In one or more embodiments, if a new frame is detected, the header information of the first slice (e.g., slice 4021) may be decoded. The buffer accessible through processor 108 may be selected and the data associated with the first slice copied into the buffer. In one or more embodiments, decoder 212 may then be triggered by processor 108 (if decoder 212 is implemented separately from processor 108; processor 108 may trigger another processor to, in turn, program decoder 212) to decode the aforementioned slice. Protocol implementations incorporating interrupts associated with requests, acknowledgments and errors are within the scope of the exemplary embodiments discussed herein.
In one or more embodiments, when an error is detected during decoding of the slice, an error concealment mechanism may be implemented (to be discussed below). In one or more embodiments, the process may proceed to the next slice (say, slice 4022). In one or more embodiments, when a slice of the same frame being decoded is detected (e.g., through processor 108), the slice data may, again, be copied into the same buffer used for the previous slice (or, another buffer, depending on the implementation); the slice data for the new slice is copied after the slice data corresponding to the previous slice. In one or more embodiments, information related to the number of slices copied and the total size of data copied may be passed through a shared memory (e.g., memory 110) to the processor (e.g., processor 108) executing decoder 212 or capable of triggering decoder 212. In one or more embodiments, the aforementioned information may be available to the processor to enable the processor program the correct data size; the processor may also have information regarding the remaining number of slices to be decoded. In one or more embodiments, decoding of the slice may then be performed. Again, protocol implementations incorporating interrupts discussed above are within the scope of the exemplary embodiments.
In accordance with the example 1080 p, 60 frames per second (fps), 10 Mbps, H.264 encoded video data 116 served over network 106 having 20 Mbps average throughput with each frame (402, 404 here) having 10 constituent slices, the latency incurred during the slice-level decoding process for one frame may include the network time for the first slice (˜8.33/10=0.833 ms, assuming 10 slices per frame) and the hardware decode time (˜12 ms) for the frame; total latency is then ˜12.8 ms. In general, in one or more embodiments, as the network time and the hardware decode time may be parallelized, the maximum thereof limits the latency time.
It should be noted that the abovementioned latency data is associated with a specific implementation where a separate processor is utilized for programming hardware (e.g., decoder 212). It is obvious that a separate thread executing on processor 108 (e.g., CPU) may program the hardware directly.
As briefly mentioned above, exemplary embodiments may also incorporate error-concealment during the slice-level decoding. At any point in time, decoder 212 may not possess full data of a frame (e.g., frame 402). In one or more embodiments, when there is an error during decoding of a slice or a missing slice, the next slice of the frame is waited for. If the next slice is also not available, a command may be issued (e.g., through processor 108) to synchronize to the next slice. For example, this may be accomplished to determine the address of the first macroblock of the slice in which the error was detected; error-concealment (e.g., ignoring of missing packet data through processor 108) may be triggered from the macroblock in which the error was detected to the first macroblock of the next slice. Once error-concealment is done, normal decoding from the next slice onward may be triggered. If the missing packet data associated with a slice is received in a temporal future compared to the next decoded slice, the aforementioned received data may be ignored as reordering is not feasible during real-time communication. Additionally, lost/missing packet data may be predicted (e.g., through processor 108) based on the previous data.
It is obvious that errors may depend on the protocol implemented for communication through network 106; for example, Real-time Transport Protocol (RTP)/User Datagram Protocol (UDP)-based communication may be associated with lower latency when compared to Transmission Control Protocol (TCP)/Internet Protocol (IP)-based communication, where retransmission occurs to mitigate effect(s) of packet errors.
In one or more embodiments, operation 510 may then involve checking as to whether the next slice is available. In one or more embodiments, if yes, operation 512 may involve programming the hardware (e.g., decoder 212) to decode the next N slices (or, remaining slices of, say, frame 402). In one or more embodiments, the decoding of the next slice may proceed in the same manner discussed herein. In one or more embodiments, if the result of operation 504 is a yes (implying that there is an error from the hardware (e.g., decoder 212)), operation 514 may involve checking whether the next slice is already available. In one or more embodiments, if yes, operation 516 may involve synchronizing to the start of the start address of the next slice. In one or more embodiments, operation 518 may then involve error concealment from the macroblock in which error was detected to the first macroblock of the new slice (or, next slice). In one or more embodiments, control may then pass on to operation 510.
In one or more embodiments, if the result of operation 514 is a no, operation 520 may involve waiting for a signal from processor 108 regarding availability of the next slice (e.g., slice 4022) or the next frame (e.g., frame 404). In one or more embodiments, operation 522 may involve checking as to whether data associated with the next slice is available. In one or more embodiments, if yes, control may be passed on to operation 516. In one or more embodiments, if no, operation 524 may involve error-concealment till the end of the frame (the new frame is detected and no new data for the current frame is available). In one or more embodiments, if the result of operation 510 is a no, then control may pass on to operation 524.
It should be noted that while exemplary embodiments have been discussed with regard to slice-level decoding, the granularity of the decoding may instead be at a macroblock level (not preferred as synchronization may be a problem). To generalize, granularity of the decoding may be at a level of a portion of a video frame having a number of such constituent portions. Thus, exemplary embodiments provide for reduced latency in critical cloud-computing environments. Further, it should be noted that while
It is obvious that the engines of multimedia framework 200 and the processes/operations discussed above may be executed in conjunction with processor 108. Instructions associated therewith may be stored in memory 110 to be installed on client device 104 after a download through the Internet. Alternately, an external memory may be utilized therefor. Also, the aforementioned instructions may be embodied on a non-transitory medium readable through client device 104 such as a Compact Disc (CD), a Digital Video Disc (DVD), a Blu-ray™ disc, a floppy disk, or a diskette etc. The aforementioned instructions may be executable through client device 104.
The aforementioned instructions are not limited to specific embodiments discussed above, and may, for example, be implemented in operating system 112, an application program (e.g., multimedia application 114), a foreground or a background process, a network stack or any combination thereof. Other variations are within the scope of the exemplary embodiments discussed herein.
Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments. For example, the various devices and modules described herein may be enabled and operated using hardware circuitry, firmware, software or any combination of hardware, firmware, and software (e.g., embodied in a non-transitory machine-readable medium). For example, the various electrical structure and methods may be embodied using transistors, logic gates, and electrical circuits (e.g., Application Specific Integrated Circuitry (ASIC) and/or Digital Signal Processor (DSP) circuitry).
In addition, it will be appreciated that the various operations, processes, and methods disclosed herein may be embodied in a non-transitory machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., client device 104), and may be performed in any order (e.g., including using means for achieving the various operations).
Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.