引用：飞落舞 发表于 2017-11-07 19:10
我并不是要操作什么  只是要远程客户端 能看到我自己本身客户端的整个屏幕图像  就像是投影仪一样   把我 ...

那你只能自已像视频聊天一样，把抓到的侦压缩编码成H.264这样的格式，到接收端解码。
但TCP用在这种场景下，延迟什么的肯定比UDP高啊

引用：JackJiang 发表于 2017-11-07 16:49
其实你应该这么想，开局一张全图，后绪的所有操作，其实整个电脑桌面的动的只是你操作的那部分，比如鼠标 ...

我并不是要操作什么  只是要远程客户端 能看到我自己本身客户端的整个屏幕图像  就像是投影仪一样   把我桌面的视屏  投影到远程客户端

引用：飞落舞 发表于 2017-11-07 16:32
嗯嗯  是的 类似于远程桌面  但不是通过WEBRTC哪种客户端之间直接数据传输   而是用WEBsocket  通过服务 ...

其实你应该这么想，开局一张全图，后绪的所有操作，其实整个电脑桌面的动的只是你操作的那部分，比如鼠标移动等等，后绪只传动的这部分数据，估计数据量会下降很多，不然真没办法。

引用：JackJiang 发表于 2017-11-07 16:26
其实2楼说的很对，你现在的方法，无论怎么压缩，跟传一张张图片没区别，而图片这种2进制数据再怎么压缩， ...

嗯嗯  是的 类似于远程桌面  但不是通过WEBRTC哪种客户端之间直接数据传输   而是用WEBsocket  通过服务器传输屏幕流   我主要是数据传输这一块不知道怎么弄

引用：飞落舞 发表于 2017-11-07 15:10
好的    整体思路是这样的    我想通过获取的屏幕视频流   通过websocket 发送给服务端  然后再由服务端 ...

其实2楼说的很对，你现在的方法，无论怎么压缩，跟传一张张图片没区别，而图片这种2进制数据再怎么压缩，为了让对方感觉不卡，则FPS值就得上来，一上来那数据据量就大了。

其实事情的本质你是希望做一个远程桌面吗？

引用：JackJiang 发表于 2017-11-07 14:47
你可以说说你的整体技术思路是怎么实现的，以及现在到底遇到的问题是什么？你希望得到什么样的建议？

好的    整体思路是这样的    我想通过获取的屏幕视频流   通过websocket 发送给服务端  然后再由服务端发送个给另一个 客户端，现在的方式是   我通过获取屏幕截图的方式   通过websocket  发送给服务端，再由服务端发送给另一个客户端。  可是这样一来  就会出现卡 顿   延迟这样的效果    我在想 能不能通过改进编码的方式 把发送的数据变得更小  从而使得传输更加的流畅  和快速。（标明我不知道有没有这样压缩的更小，实现传输更快的方法）。     

引用：飞落舞 发表于 2017-11-07 14:06
回复四楼   这个两种传输格式  一种是 dodataurl  形式   一种是blob形式   改怎么弄才好呢

你可以说说你的整体技术思路是怎么实现的，以及现在到底遇到的问题是什么？你希望得到什么样的建议？

每一帧图大概有多少字节？传输完一帧需要多少时间？有没有个精确地度量？不然怎么知道慢，慢多少呢？

慢的另一个原因或许是你要传输的数据量比较大，你可以想办法压缩一下每帧数据大小，比如Windows自带的远程桌面为什么这么流畅肯定是有很牛逼的压缩算法，而你用QQ的远程协助就会感觉明显卡。

WebSocket是基于TCP实现的，基本上只要你的代码编写上没有明显的性能损失，WebSocket带给你的“慢”的感受是基于TCP协议的本身决定的，没有办法解决，这也是实时音视频这种实时性要求高的场景下优先使用UDP的原因。

如果你对TCP和UDP的理论还有些疑问的话，建议你选择性阅读以下系列文章：
《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
《不为人知的网络编程(五)：UDP的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
《网络编程懒人入门(四)：快速理解TCP和UDP的差异》