OpenGL渲染实时传输
我正在尝试用 C++ 开发一个用于远程 OpenGL 渲染的工具。基本思想是：
- 客户端像普通应用程序一样发出 OpenGL 命令
- 这些命令实际上通过网络发送到外部服务器
- 服务器使用某种离屏技术执行渲染
- 完成后，服务器会通过网络将单个帧传输到客户端
- 客户端在屏幕上渲染框架。
- 循环。
我知道如果我还没有成品，我不应该开始担心优化，但我很确定这会非常慢，瓶颈可能是网络上的单帧传输，即使这些计算机连接在同一 LAN 中。
我正在考虑使用某种视频流库。这样，帧将使用适当的压缩算法进行传输，从而使过程更快。
我在这方面走的路正确吗？这里使用视频流库合适吗？如果您这么认为，那么适合此任务的库是什么（C 或 C++，最好是 C++）？
感谢您的帮助！
I'm experimenting with developing a tool for remote OpenGL rendering, in C++. The basic idea is:
- The client issues OpenGL commands like it's a normal app
- Those commands are actually sent over the network to an external server
- The server performs the rendering using some off-screen technique
- Once done, the server transmits a single frame over the network to the client
- The client renders the frame on screen.
- Loop.
I know I shouldn't start worrying about optimization if I don't have a finished product yet, but I'm pretty sure that is going to be very slow, and the bottleneck is probably going to be the single frame transmission over the network, even if those computers are connected in the same LAN.
I'm thinking about using some kind of video streaming library. That way, the frames would be transmitted using proper compression algorithms, making the process faster.
Am I in the right path about this? Is it right to use a video streaming library here? If you think so, what's a good library for this task (in C or C++, preferably C++)?
Thank you for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你有两个解决方案。
解决方案 1
->复杂，尤其是在处理缓冲区和纹理时；真正的openGL代码是在本地执行的，这可能不是你想要的，但这取决于你。更重要的是，它对于远程应用程序是透明的（无需修改源代码，无需重建）。几乎没有网络通讯。
解决方案2：正如您所描述的，以及优点和缺点。
如果您选择解决方案 2，现在不必担心速度。相信我，您将面临足够的 openGL 挑战。
从同步模式开始：渲染、获取、发送、渲染、获取、发送
然后是异步模式：渲染，开始获取，渲染，获取结束，开始发送，渲染等
我想这已经够难的了
You have two solutions.
Solution 1
-> complicated, especially when dealing with buffers and textures; the real openGL code is executed locally, which may not be what's wanted, but it's up to you. What's more, it's transparent for the remote app (no source modification, no rebuild). Almost no network communication.
Solution 2 : what you described, with the pros and cons.
If you go for Solution 2, don't bother about speed for now. You will have enough challenges with openGL as it is, trust me.
Begin by a synchronous mode : render, fetch, send, render, fetch, send
Then a asynchronous mode : render, begin the fetch, render, end of the fetch, begin the send, render, etc
It will be hard enough, I think
根据您需要支持的分辨率和 LAN 的速度，可能可以传输未压缩的数据。
24 位 1280x1024 帧需要 30 Mbit，对于千兆位以太网，这意味着理论上每秒 33 帧（未压缩）。
如果这还不够，您自己添加一个简单的 RLE 压缩相当简单。
Depending on the resolution you need to support and the speed of your LAN it may be possible to stream the data uncompressed.
A 24-bit 1280x1024 frame requires 30 Mbit, and with a gigabit ethernet this means a theoretical 33 frames per second uncompressed.
If that is not enough, adding a simple RLE-compression yourself is fairly straightforward.
想象一下必须在两台机器上花费美元才能为它们提供适当的图形处理能力。如果将所有与图形相关的任务集中在一台计算机上，则可以避免这种情况并简化客户端开发。客户端的工作只是发送/接收/显示数据，服务器可以专注于处理图形 (OpenGL) 并将数据（作为帧）发送回客户端。
您提到的瓶颈取决于您这边的一些因素：图像的大小以及发送/接收/显示它们所需的帧速率。
这些是我读过的一些有趣的主题，希望它们能够阐明这个主题：
使用 C++ 进行视频流
如何做我流式传输视频并播放它？
Imagine having to spend $ on both machines to provide them with proper graphics processing power. You could avoid this and simplify the client development if you centralize all the graphics related tasks on one single machine. The job of the client would be only to send/receive/display data, and the server could focus on processing the graphics (OpenGL) and sending the data (as frames) back to the client.
The bottleneck you referred to depends on a couple of things on your side: the size of the images and the frame rate you need to send/receive/display them.
These are some of the interesting topics I've read and hopefully they will shed a light on the subject:
Video streaming using c++
How do I stream video and play it?