为 wxWidgets 设计实时视频流
在我的应用程序中，我们会将来自交通摄像头的视频流呈现给客户端查看器。 （最终还有几个客户端观看者。）客户端应该能够观看实时视频或倒带视频并观看较早的镜头，包括在连接视频流之前发生的视频。我们打算使用 wxWidgets 来观看视频，其中我们可能会使用 wxMediaCtrl。
现在，从上述陈述中，你们中的一些人可能会想“嘿，他不知道自己在说什么。”你是对的！我对这些概念很陌生，并且对过多的信息感到困惑。 以上说法是否合理？任何人都可以为此推荐一个基本的服务器/客户端架构吗？ 我们肯定会使用 C++ wxWidgets 作为 GUI，但也许 wxMediaCtrl 不是我想要的......我应该直接使用 ffmpeg 库之类的东西吗？
我们当前的方法似乎不太理想。服务器从每个视频帧中提取位图，然后等待单个客户端发送“下一帧”消息，此时服务器发送位图。实际上，我们重新创建了我们自己的笨拙、非标准、低效和低功能的视频流协议和查看器。一定有更好的东西！
In my application we will present the video stream from a traffic camera to a client viewer. (And eventually several client viewers.) The client should have the ability to watch the live video or rewind the video and watch earlier footage including video that occurred prior to connecting with the video stream. We intend to use wxWidgets to view the video and within that we will probably use the wxMediaCtrl.
Now, from the above statements some of you might be thinking "Hey, he doesn't know what he's talking about." And you would be correct! I'm new to these concepts and I confused by the surplus of information. Are the statements above reasonable? Can anyone recommend a basic server/client architecture for this? We will definitely be using C++ wxWidgets for the GUI, but perhaps wxMediaCtrl is not what I want... should I be directly using something like the ffmpeg libraries?
Our current method seems less than optimal. The server extracts a bitmap from each video frame and then waits for the single client to send a "next frame" message, at which point the server sends the bitmap. Effectively we've recreated our own awkward, non-standard, inefficient, and low-functionality video streaming protocol and viewer. There has to be something better!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对于媒体播放工具，包括音乐和音频，您可以查看 GStream。说到服务器，我认为 Twisted （Python 中的网络库）应该是不错的选择。著名的视频直播社交网站justin.tv就是基于Twisted。您可以在此处阅读故事。另外，我还在 Twisted 上构建了一组用于流音频的服务器。他们可以同时在线为数千名听众提供服务。
For media playing facility, both music and audio, you can a look on GStream. And talking about the server, I think Twisted (A network library in Python) should be good option. The famous live video social website justin.tv is based on Twisted. Here you can read the story from here. Also, I built a group of server for streaming audio on Twisted, too. They can serve thousands of listener on line in same time.
有一个名为 VLC 的播放器。它有一个 C++ 库，您可以使用它来将播放器嵌入到 GUI 应用程序中。它支持非常广泛的协议。因此，您应该将连接、检索和播放作业留给 VLC，而只负责启动和停止作业。这会很容易，而且可能是比你自己做更好的解决方案。
There is a player called VLC. It has a library for c++ and you can use it to embed the player in your GUI application. It supports a very wide range of protocols. So you should leave connecting, retrieving and playing jobs to VLC and take care of the starting and stopping jobs only. It would be easy and probably a better solution than doing it yourself.
您应该查看此 C++ RTMP 服务器：http://www.rtmpd.com/。我很快下载、编译并成功测试了它，没有任何实际问题（在 Ubuntu Maverick 上）。文档非常好，虽然有些散乱。我怀疑一旦你有了一个能够支持典型协议的流媒体服务器（rtmpd 似乎可以做到），那么编写客户端就应该自然而然地就位了，特别是如果你使用 wxWidgets 作为接口 api。当然，在这里写起来很容易，在我舒适的客厅里，当你深入代码时，这将是一个不同的故事:)
You should check out this C++ RTMP Server: http://www.rtmpd.com/. I quickly downloaded, compiled and successfully tested it without any real problems (on Ubuntu Maverick). The documentation is pretty good if a little all over the place. I suspect that once you have a streaming media server capable of supporting the typical protocols (which rtmpd seems to do), then writing a client should fall into place naturally, especially if you're using wxWidgets as the interface api. Of course, it's easy to write that here, from the comfort of my living room, it'll be a different story when you're knee deep in code :)
您可以修改您的软件，如下所示：
服务器连接，服务器抓取图像，将其传递给建立流的 ffmpeg，然后从 ffmpeg 流复制编码数据并通过网络发送到客户端，如果连接断开，则关闭 ffmpeg 流。
也许您可以使用以下内容来发挥自己的优势：
http://www.kirsle.net/blog.html?u=kirsle&id=63" rel="nofollow">http://www. kirsle.net/blog.html?u=kirsle&id=63
you can modify your software such that:
The server connect, server grabs an image, passes it to ffmpeg establishing stream, then copy the encoded data from ffmpeg stream and send to client via network, if the connection drops, close the ffmpeg stream.
Maybe you can use the following to your own advantage:
http://www.kirsle.net/blog.html?u=kirsle&id=63