1
Sisyphe42 264 天前
呃,各家的串流实现方案都不同吧
|
2
ysc3839 264 天前
虚拟显卡和屏幕录像
|
3
paopjian 264 天前
一个是服务器渲染好把客户端当屏幕放,一个是服务器渲染好录像发过来?
|
4
dann73580 264 天前
串流就是服务端录制转码然后全量发过去……客户端负责解码然后播放。rdp 本质是是客户端负责绘制,在不涉及到视频传输和打游戏这种大动态场景的情况下,是可以无限接近本地体验的,非常适合办公场景。
|
5
Evovil 264 天前 1
RDP 是云桌面
串流是云游戏 侧重不同,你细品 云桌面追求的是画质,客户端渲染,画质接近 native ,清晰可见 缺点是输入延迟较高,适合网页,办公等 串流一般是云游戏,低、极低延迟,讲究操作跟手,一般采用全硬件加速编解码(包括硬件色彩转换),典型有采用 264 265 + udp 这种,极限情况下延迟可以做到 20ms ( native 都有 10ms 延迟包括显示器), 缺点是画质比较低可能受网络波动影响,所以会采用无 I 帧无 B 帧 全 P 帧这种 + DRC (动态分辨率) 在保证延迟的前提下画质可能损失 |
7
version 263 天前
RDP 是微软自己琢磨的一套远程优化.应用级别的优化.图像优化等.今年会推出独立单独远程应用.例如某个 exe 远程.而不需要整个系统远程.支持触点
串流就理解为主机负责 RTMP 直播推流..客户端就等于看直播一样.想要客户端不卡也需要解码能力和连接主机带宽足够.手柄和键盘映射需要靠另外流去转发 |
9
Evovil 263 天前
在正常情况下只有第一帧 I 帧后面全是 P 帧
|
10
vsyf 263 天前 via Android
@Evovil 像 webrtc 我记得好像是 3000 张还是 3000 秒,接收端在一个 frame 超时了还拼不出来的时候会重新 request idr 。
nvidia 的是接收端不要就一直给 p frame 吗? |
11
vsyf 263 天前
我理解的区别:
串流是抽象一个虚拟屏,在系统给物理屏一张画面的时候,同时给虚拟屏一张; 之后去编码传输,同时可以进行裁剪、丢帧、改变码率来调整网络带宽的消耗以达到较低延迟的目的。 RDP 是在系统上提供另一个支持,就是把完整的画面分区域传输; 比如现在浏览器在播视频,那只传输视频那一个区域,像鼠标指针、系统底部 dock 和 chrome 标签栏都不变就不用传输。其他串流软件能实现的机制按道理 rdp 同样可以呀。 这里我就不理解哪里会引起延迟更高呢?按道理不是应该更低吗? |
13
cheng6563 263 天前
据说有些串流软件可以做到比显示器延迟更低,不知真假。
|
14
houzhenhong 263 天前
@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 |
15
houzhenhong 263 天前
|
16
Evovil 263 天前 1
@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 |
17
hez2010 263 天前 3
用 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 是没啥问题的。 |
18
jsq2627 263 天前
如楼上所说,RDP 在开启 H264 编码后,就和其他串流方案没什么区别了。
|
19
hez2010 263 天前
@jsq2627 开启之后工作原理还是跟原来一样的,只不过 RDP 此前对 H.264/AVC 内容是按照 420 编码的,切换到 444 之后能有效提升图像质量。另外就是顺便把原来的软件编码切换到硬件编码了。
|
20
hez2010 263 天前
@hez2010 另外 DWMFRAMEINTERVAL 越低帧数越高,但是你的网络和硬件不一定能带的动,如果太低了带不动了就会连接失败。可以一点一点往下调看能到哪里,一般来说调到跟你屏幕刷新率差不多就可以了。
DWMFRAMEINTERVAL = 15 大概是 62fps DWMFRAMEINTERVAL = 7 大概是 114fps DWMFRAMEINTERVAL = 6 大概是 128fps DWMFRAMEINTERVAL = 5 大概是 172fps DWMFRAMEINTERVAL = 2 大概是 360fps |
21
abcbuzhiming 262 天前
@hez2010
开启优先 H.264/AVC 444 和 H.264/AVC 444 硬件编码这两个选项。 ====== 你这其实就是开串流了,但是说真的 windows rdp 的串流效果不好,很明显的颜色失真现象。对比其它家串流哪怕是 4:2:0 的颜色也比 rdp 开串流好很多。更别说还可以选 4:4:4 |
23
giao123 262 天前
如果 gop 是无限的话,岂不是容错率很低,中间丢了一帧,后面的数据直接就是不正常的了,还是说有纠错策略
|
24
hez2010 262 天前
@abcbuzhiming 你可以开启 RDP 的 4:4:4 ,那个串流效果是真的好。
|
26
leaflxh 262 天前
感觉上像是一个东西
用过微软的 mstsc ,以及那个 UWP 应用,Steam link 都是服务端录屏,客户端播放,然后做好交互。 体验取决于服务端编码效率和客户端的解码效率,以及传输的延迟和带宽 |
27
flyqie 262 天前 via Android
@Evovil #5
偏个楼哈。 目前云桌面方案似乎广泛都放弃了 rdp ,rdp 这个方案不太适合目前的云桌面,用户在播放视频以及运行 3d 软件的时候都面临一定问题。 而且 rdp 似乎很多功能与微软都深度绑定 |
29
hez2010 262 天前
@playboy0 组策略里:计算机配置——管理模板——Windows 组件——远程桌面服务——远程桌面会话主机——远程会话环境,开启优先 H.264/AVC 444 和 H.264/AVC 444 硬件编码这两个选项
|
30
hez2010 262 天前
RDP 其实是开放协议,也有不少很完整的开源实现的,最著名的比如 https://github.com/FreeRDP/FreeRDP ,这个 FreeRDP 也被微软用在了 WSLg 里面,可以说是官方认可了。
不过 RDP 涉及到的协议实在是太多了,从差分算法,到图像到音频到视频编码,再到网络协议和 GPU 硬件加速等等,一般人很能全都实现完: https://github.com/FreeRDP/FreeRDP/wiki/Reference-Documentation |