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

362 天前
SeleiXi  SeleiXi
4790 次点击
所在节点   程序员  程序员
35 条回复
Sisyphe42
Sisyphe42
362 天前
呃,各家的串流实现方案都不同吧
ysc3839
ysc3839
362 天前
虚拟显卡和屏幕录像
paopjian
paopjian
362 天前
一个是服务器渲染好把客户端当屏幕放,一个是服务器渲染好录像发过来?
dann73580
dann73580
362 天前
串流就是服务端录制转码然后全量发过去……客户端负责解码然后播放。rdp 本质是是客户端负责绘制,在不涉及到视频传输和打游戏这种大动态场景的情况下,是可以无限接近本地体验的,非常适合办公场景。
Evovil
Evovil
362 天前
RDP 是云桌面
串流是云游戏

侧重不同,你细品

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

串流一般是云游戏,低、极低延迟,讲究操作跟手,一般采用全硬件加速编解码(包括硬件色彩转换),典型有采用 264 265 + udp 这种,极限情况下延迟可以做到 20ms ( native 都有 10ms 延迟包括显示器), 缺点是画质比较低可能受网络波动影响,所以会采用无 I 帧无 B 帧 全 P 帧这种 + DRC (动态分辨率) 在保证延迟的前提下画质可能损失
zsxzy
zsxzy
362 天前
@Evovil 无 I 帧能显示图像吗.. airplay 镜像时用的 tcp 传输数据, 不知道基于啥考虑的
version
version
361 天前
RDP 是微软自己琢磨的一套远程优化.应用级别的优化.图像优化等.今年会推出独立单独远程应用.例如某个 exe 远程.而不需要整个系统远程.支持触点
串流就理解为主机负责 RTMP 直播推流..客户端就等于看直播一样.想要客户端不卡也需要解码能力和连接主机带宽足够.手柄和键盘映射需要靠另外流去转发
Evovil
Evovil
361 天前
@zsxzy 表述可能有问题,应该叫无限 GOP, 相关参数 以 nvidia 举例子 NVENC_INFINITE_GOPLENGTH
Evovil
Evovil
361 天前
在正常情况下只有第一帧 I 帧后面全是 P 帧
vsyf
vsyf
361 天前
@Evovil 像 webrtc 我记得好像是 3000 张还是 3000 秒,接收端在一个 frame 超时了还拼不出来的时候会重新 request idr 。
nvidia 的是接收端不要就一直给 p frame 吗?
vsyf
vsyf
361 天前
我理解的区别:
串流是抽象一个虚拟屏,在系统给物理屏一张画面的时候,同时给虚拟屏一张; 之后去编码传输,同时可以进行裁剪、丢帧、改变码率来调整网络带宽的消耗以达到较低延迟的目的。
RDP 是在系统上提供另一个支持,就是把完整的画面分区域传输; 比如现在浏览器在播视频,那只传输视频那一个区域,像鼠标指针、系统底部 dock 和 chrome 标签栏都不变就不用传输。其他串流软件能实现的机制按道理 rdp 同样可以呀。

这里我就不理解哪里会引起延迟更高呢?按道理不是应该更低吗?
vsyf
vsyf
361 天前
@vsyf #11
@Evovil
帮帮解惑一下
cheng6563
361 天前
据说有些串流软件可以做到比显示器延迟更低,不知真假。
houzhenhong
361 天前
@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
361 天前
测试了一下 airplay 的 h264 数据,除了第一帧是 i 以外其他都是 p ,找了几个开源实现都没有类似 RTCP 的 PLI 机制,这个是使用 TCP 的原因?

Evovil
361 天前
@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
361 天前
用 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
361 天前
如楼上所说,RDP 在开启 H264 编码后,就和其他串流方案没什么区别了。
hez2010
361 天前
@jsq2627 开启之后工作原理还是跟原来一样的,只不过 RDP 此前对 H.264/AVC 内容是按照 420 编码的,切换到 444 之后能有效提升图像质量。另外就是顺便把原来的软件编码切换到硬件编码了。
hez2010
361 天前
@hez2010 另外 DWMFRAMEINTERVAL 越低帧数越高,但是你的网络和硬件不一定能带的动,如果太低了带不动了就会连接失败。可以一点一点往下调看能到哪里,一般来说调到跟你屏幕刷新率差不多就可以了。
DWMFRAMEINTERVAL = 15 大概是 62fps
DWMFRAMEINTERVAL = 7 大概是 114fps
DWMFRAMEINTERVAL = 6 大概是 128fps
DWMFRAMEINTERVAL = 5 大概是 172fps
DWMFRAMEINTERVAL = 2 大概是 360fps

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1018180

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX