RDP 和串流游戏软件的技术实现差异是什么？

[SeleiXi]

[Sisyphe42]

呃，各家的串流实现方案都不同吧

[ysc3839]

虚拟显卡和屏幕录像

[paopjian]

一个是服务器渲染好把客户端当屏幕放,一个是服务器渲染好录像发过来?

[dann73580]

串流就是服务端录制转码然后全量发过去……客户端负责解码然后播放。rdp 本质是是客户端负责绘制，在不涉及到视频传输和打游戏这种大动态场景的情况下，是可以无限接近本地体验的，非常适合办公场景。

[Evovil]

RDP 是云桌面
串流是云游戏

侧重不同，你细品

云桌面追求的是画质，客户端渲染，画质接近 native ，清晰可见 缺点是输入延迟较高，适合网页，办公等

串流一般是云游戏，低、极低延迟，讲究操作跟手，一般采用全硬件加速编解码（包括硬件色彩转换），典型有采用 264 265 + udp 这种，极限情况下延迟可以做到 20ms （ native 都有 10ms 延迟包括显示器）， 缺点是画质比较低可能受网络波动影响，所以会采用无 I 帧无 B 帧 全 P 帧这种 + DRC （动态分辨率） 在保证延迟的前提下画质可能损失

[zsxzy]

@Evovil 无 I 帧能显示图像吗.. airplay 镜像时用的 tcp 传输数据, 不知道基于啥考虑的

[version]

RDP 是微软自己琢磨的一套远程优化.应用级别的优化.图像优化等.今年会推出独立单独远程应用.例如某个 exe 远程.而不需要整个系统远程.支持触点
串流就理解为主机负责 RTMP 直播推流..客户端就等于看直播一样.想要客户端不卡也需要解码能力和连接主机带宽足够.手柄和键盘映射需要靠另外流去转发

[Evovil]

@zsxzy 表述可能有问题，应该叫无限 GOP, 相关参数 以 nvidia 举例子 NVENC_INFINITE_GOPLENGTH

[Evovil]

在正常情况下只有第一帧 I 帧后面全是 P 帧

[vsyf]

@Evovil 像 webrtc 我记得好像是 3000 张还是 3000 秒，接收端在一个 frame 超时了还拼不出来的时候会重新 request idr 。
nvidia 的是接收端不要就一直给 p frame 吗？

[vsyf]

我理解的区别:
串流是抽象一个虚拟屏，在系统给物理屏一张画面的时候，同时给虚拟屏一张; 之后去编码传输，同时可以进行裁剪、丢帧、改变码率来调整网络带宽的消耗以达到较低延迟的目的。
RDP 是在系统上提供另一个支持，就是把完整的画面分区域传输; 比如现在浏览器在播视频，那只传输视频那一个区域，像鼠标指针、系统底部 dock 和 chrome 标签栏都不变就不用传输。其他串流软件能实现的机制按道理 rdp 同样可以呀。

这里我就不理解哪里会引起延迟更高呢？按道理不是应该更低吗？

[vsyf]

@vsyf #11
@Evovil
帮帮解惑一下

[cheng6563]

据说有些串流软件可以做到比显示器延迟更低，不知真假。

[houzhenhong]

@vsyf #10

我看 srs 的 webrtc 实现，接收端的 Picture Loss Indication 是 6 秒，刚刚接触音视频不知道其他实现是怎么样的。（我只是一个切图仔）

https://github.com/ossrs/srs/blob/v6.0.48/trunk/src/app/srs_app_config.cpp#L4560

@zsxzy #6

我最开始还不相信，大概找了一下 airplay 的开源实现，发现 airplay 的 mirror 真是用 tcp 做的，的确挺奇怪的。

https://github.com/SteeBono/airplayreceiver/blob/main/AirPlay/Listeners/MirroringListener.cs#L15

https://github.com/FDH2/UxPlay/blob/v1.68.2/lib/raop_handlers.h#L807
https://github.com/FDH2/UxPlay/blob/v1.68.2/lib/raop.c#L597

[houzhenhong]

测试了一下 airplay 的 h264 数据，除了第一帧是 i 以外其他都是 p ，找了几个开源实现都没有类似 RTCP 的 PLI 机制，这个是使用 TCP 的原因？

[Evovil]

@vsyf 你的理解大致没错 不过有些细节：
1. rdp 如果应用在云桌面，是个很好的方案，因为画面变动少，可以获得很好的画质。 但是游戏、视频这类一秒变动 24fps/60fps 的在使用 rdp 就会延迟明显卡顿，换句话说就不丝滑了
- 如果传输裸图像，那么带宽会巨高，而且裸图像传输时间也很长
- 如果传输压缩的图像（比如 mjpeg ） 涉及到 cpu 编码，cpu 编码+传输延迟太高，如果选择硬件加速，那得各种微调
- 云桌面一般首先会设计 buffer 保证画面质量和避免撕裂等抵消网络波动，鼠标点击类，文字类操作超过 200ms 也不是特别影响

2. 如果使用 264 ，那就玩的花了，首先有现成的硬件电路可以提供支持，Intel/nvidia/amd 都有独立的硬件管线，其次如果 windows 从抓帧 dx11 ，dxgi 等 api 也是从 gpu 走的，理论上可以显存->电路不出 gpu 完成 264encode ，再其次，P 帧就是差异帧，在不变化的时候帧很小，变相也节省了延迟,低变化甚至比显示器延迟更低 @cheng6563

@houzhenghong 一般这类实现都是 infinite GOP

[hez2010]

用 RDP 其实也可以看视频和打游戏，不过想要获得比较好的体验需要调整一些默认设置：

注意要调整的是被远程的主机，而不是 client 。

组策略里：计算机配置——管理模板——Windows 组件——远程桌面服务——远程桌面会话主机——远程会话环境，开启优先 H.264/AVC 444 和 H.264/AVC 444 硬件编码这两个选项
然后去注册表里：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations ，添加一个 DWMFRAMEINTERVAL 的 DWORD 值，选择 10 进制，然后填写 15 保存。

重启计算机之后就能获得一个比较好的体验了。起码 60fps 是没啥问题的。

[jsq2627]

如楼上所说，RDP 在开启 H264 编码后，就和其他串流方案没什么区别了。

[hez2010]

@jsq2627 开启之后工作原理还是跟原来一样的，只不过 RDP 此前对 H.264/AVC 内容是按照 420 编码的，切换到 444 之后能有效提升图像质量。另外就是顺便把原来的软件编码切换到硬件编码了。

[hez2010]

@hez2010 另外 DWMFRAMEINTERVAL 越低帧数越高，但是你的网络和硬件不一定能带的动，如果太低了带不动了就会连接失败。可以一点一点往下调看能到哪里，一般来说调到跟你屏幕刷新率差不多就可以了。
DWMFRAMEINTERVAL = 15 大概是 62fps
DWMFRAMEINTERVAL = 7 大概是 114fps
DWMFRAMEINTERVAL = 6 大概是 128fps
DWMFRAMEINTERVAL = 5 大概是 172fps
DWMFRAMEINTERVAL = 2 大概是 360fps