可以大大缩短，即使采用软编技术，通过优化后的编码参数等技术，也可以达到技术指标的30ms左右。
[0077]下面对一帧消耗时间进行说明:
[0078]T(捕获):一帧桌面数据捕获消耗的时间；T(转换):一帧数据颜色转换消耗的时间；Τ(编码):一帧数据编码消耗的时间，则得到:一帧消耗时间=Τ(捕获)+Τ(转换)+Τ (编码);
[0079]在本发明的一个实施例中，一帧消耗时间<33ms。
[0080]ND:因为在局域网内并且使用wif1-direct技术，完全可以达到指标。
[0081]0D:播放延迟技术:分为屏幕渲染，帧间缓存，视频解码三部分，完全可以控制在16_18ms 以内。
[0082]本发明可以提供尚品质的视频:Full HD 1080，实现30巾贞/秒的尚巾贞率，低延迟达到〈=100msο并且支持扩展屏和wifi direct。
[0083]服务器进一步将编码后的视频响应舒服发送至客户端。其中，服务器和客户端之间的数据流传输通过标准RTSP、RTCP、RTP协议，服务器采用FFMPEG技术，客户端采用live555技术。live555的库是用C++来编写设计的。利用live555框架派生成RTSPClient和的MediaSink类，注册回调函数来处理网络事件。一旦RTSP客户端成功地建立了视频会话，创建一个接收器类处理从服务器传递过来的视频帧，接收器类继承于MediaSink类，并注册continuePlaying这个虚函数。continuePlaying功能从服务器接收编码帧。当一帧被成功接收，则该函数将触发一个回调函数，将放在缓冲区中，以此循环。
[0084]配置服务器的编码位速率为3Mbps。对于一个公平的比较，所有游戏都流在720p的分辨率。而本发明配置GamingAnywhere和OnLive的流在50FPS，StreamMyGame仅支持流以25fps。本发明设计的实验，以评估来自两个关键方面三个游戏系统:响应和视频质量。本发明也进行实验，以量化发生的不同的云游戏系统的网络负载。
[0085]步骤S4，客户端对接收到的视频响应数据进行解码，并对解码后的视频响应数据进行渲染播放，以实现客户端与服务器的当前桌面的同屏显示。
[0086]需要说明的是，步骤S4对应图2中的Video Decoder (视频解码)和VideoPlayer (视频清染播放)。
[0087]在本发明的一个实施例中，客户端对接收到的硬编码后的视频响应数据进行解码，采用SDL技术对解码后的视频响应数据进行渲染播放。
[0088]Video Decoder (视频解码):
[0089]客户端对接收到的经云服务器编码后的H264帧数据进行解码，生成YUV数据。该视频解码支持软解和硬解两种模式，是上述步骤S3编码的逆向过程。
[0090]为提供在延迟方面更好的体验，本步骤中使用的视频解码器目前没有在所有缓冲的视频帧。换句话说，视频缓存器元件被简单地用于缓冲与该最新的视频帧相关联的分组。因为LIVE555提供了分组的有效载荷而不的RTP报头，检测是否连续分组对应于基于每个分组中的标记比特相同的视频帧。
[0091]如果一个新接收的分组具有零标记比特(指示它不是最后一个分组关联与视频帧)，它会被追加到缓冲；否则，视频解码器将解码的基础上的所有数据包当前在缓冲器中的视频帧，清空缓冲器，然后将新到达的数据包缓冲区中。虽然这种零缓冲策略可能导致不一致的视频播放速率时网络延迟是不稳定，但是可以减少输入-反应潜伏期由于视频播放到最低水平，这样的设计折衷可以产生更好的整体用户使用体验。
[0092]处理音频帧的方式是从视频帧的其处理相同。一旦接收音频帧，RTSP客户端线程不解码该帧，而是简单地放置在一个共享缓冲器(实现为FIFO队列)中的所有接收到的帧。这是因为SDL的音频呈现使用一种按需方法实施。S卩，在SDL播放音频，一个回调函数需要进行注册，它被称为SDL时需要播放的音频帧。存储器地址填补音频帧和所需的音频帧的数量η作为参数传递给回调函数。回调函数检索从共享缓冲器中的音频数据包，对数据包进行解码，并填充该解码的音频帧到指定的存储器地址米。
[0093]需要请注意的是，回调函数必须填写恰好η音频帧到指定的内存地址的要求。如果不是，则该函数必须等待，直到有足够的帧。本发明实行轮候机制，使用互斥锁(互斥)足够的帧。如果RTSP客户端线程接收到新的音频帧，将追加的帧缓冲，并触发回调函数读取多个帧。
[0094]音频帧捕获是依赖于平台，本发明使用ALSA库和Windows音频会话API (WASAPI)分别捕捉声音在Linux和Windows。音频源模块定期捕获来自音频设备(通常默认波形输出装置)的音频帧(也称为音频数据包)。所捕获的帧由所述音频源模块复制到与编码器共享的缓冲器。编码器将音频帧生成新的帧进行编码，每次惊醒。为了简化GamingAnywhere的编程接口，本发明需要的音频帧的每个样本被存储为一个32位带符号整数。
[0095]当没有应用产生任何声音，音频读取功能可能会返回以下:1)音频帧用全零；2)错误代码，表明没有帧是当前可用的。
[0096]如果第二情况下，音频源模块需要仍然发出无声的音频帧到编码器的编码器，因为通常期望连续音频帧不管可听声音是否存在与否。因此，音频源模块必须发射无声的音频帧在第二种情况下，以解决该帧不连续性的问题。由于Windows游戏使用WASAPI，其中患有帧不连续性问题常常播放音频。WASAPI基于音频源模块已经克服了问题，通过仔细推定静音期的持续时间，并产生相应的沉默帧，如图7所示。从图7中可以看出，沉默帧的长度最好应T1-T0 ;然而，估计的静默持续时间可能会稍微更长或更短如果定时器精度不充分尚的
[0097]Video Player (视频清染播放):
[0098]客户端对解码后的视频响应数据进行渲染播放，采用FFMPEG与SDL技术。通过SDL技术，实现视频播放。
[0099]参考图6，本发明设计如下以解决视频播放的延迟:
[0100](1) 一个H264的Frame会分包成多个RTP包；
[0101](2) 一个Frame的RTP包会分配一个序号从l."n ;
[0102](3) 30ΚΒ的包在50Mbps的网络带宽中传输，缓存时间=30KB*8bits/50Mbps =?5ms ο
[0103]优选的，客户端的操作系统为Windows系统、Android系统或10S系统。其中，客户端的数量为一个或多个。图5为根据本发明实施例的无线同屏的效果图。如图5所示，一个服务器对应两个客户端，其中客户端1为Windows系统，客户端2为Android系统。
[0104]如图9所示，本发明实施例的基于流媒体方式的无线同屏装置，包括:至少一个客户端1和服务器2。其中，每个客户端1与均服务器2无线通信。优选的，每个客户端1的操作系统为Windows系统、Android系统或10S系统。
[0105]客户端1用于接收用户输入的同屏请求指令，并对同屏请求指令进行编码，将编码后的同屏请求指令通过互联网发送至服务器2。在本发明的一个实施例中，同屏请求指令包括:客户端1的名称和IP地址、响应数据描述。其中，响应数据描述包括数据的位置、格式和长度。
[0106]服务器2用于对接收到的编码后的同屏请求指令进行解码，以获取同屏请求指令对应的响应数据描述，然后启动对同屏请求指令的响应。
[0107]服务器2可以根据响应数据描述捕获当前桌面的视频帧数据，对当前桌面的视频帧数据进行编码，生