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