播放传入的视频流
我正在编写一个有点视频流播放器的应用程序。客户端正在使用 udp 套接字接收视频流。现在，当我接收流时，我想同时播放它。这与播放硬盘中的本地视频文件不同在这种情况下，它可以像使用系统运行文件一样简单（“vlc 文件名”）。但是这里涉及很多问题，例如接收可能会延迟，播放器必须等待传入的数据。我已经知道关于使用 vlc 运行视频流。您能否详细说明使用 vlc 播放流的步骤。我正在用 c++ 实现我的应用程序。
编辑：有人可以给我一些关于 VLC API 的想法吗？它可用于将给定视频流式传输到特定目的地并在另一端接收该流并播放它。
就此而言， 马维亚
I am writing an application which is a kinda video streamer.The client is receiving a video stream using udp socket.Now as I am receiving the stream I want to play it simultaneous.It is different from playing local video file lying in your hard disk in which case it can be as simple as running the file using system("vlc filename").But here many issues are involved like there can be delay in receiving and player will have to wait for the incoming data.I have come to know about using vlc to run a video stream.Can you please elaborate the step for playing the stream using vlc.I am implementing my application in c++.
EDIT: Can somebody give me some idea regarding VLC API which can be used to stream a given video to particular destination and receive that stream at other end play it.
with regards,
Mawia
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
那么你可以随时查看VideoLan自己的主页
除此之外，流媒体非常简单：
第 2 点和第 3 点听起来很奇怪，但它们值得考虑：
如果您有宽带连接，则可以将大数据包传送到客户端。注意：这里的数据包是指客户端需要完全一致的数据单元来解码下一个视频位。如果您发送大数据包，例如 4 秒的视频，您可能会因为等待 4 秒的完整数据单元而出现延迟，而 0.5 秒的小数据包会让您出现延迟，但在质量较差的情况下仍然可以识别且相对流畅的视频联系。
质量也是如此。像素化和伪影严重的视频很糟糕，口吃的视频/声音不同步的视频更糟糕。而是切换到较低质量/较高压缩设置。
如果您的问题纯粹是关于完成部分，那么第 1 点和第 4 点应该适合您。
你可能会问：
“如果我想做实时视频直播呢？”
上述所有建议仍然适用，但所有这些都必须更明智地完成。首先，您无法在连接不良的情况下进行实时处理。这是现实的事情。如果您的连接足够宽，您几乎可以实时到达，只需泵出每个图像和一个小的声音样本，无需太多处理或任何缓冲。从中获得良好的客户体验是可能的，但这样的联系几乎不可能。这里的技巧通常是，传输略低于理论上连接允许的视频质量，并且仍然在其中进行缓存和数据包重新排序......玩得开心。这很难。
Well you can always take a look at VideoLan's own homepage
Other than that, streaming is quite straightforward:
Number 2 and 3 sound strange, but they are worth thinking about:
If you have a broadband connection, you can afford to pump big packets over to the client. Note: Packets here means consistent units of data that the client needs to have completely to decode the next bit of video. If you send big packets, say 4 secs of video, you risk lag due to waiting for the complete data unit of, well, full 4 seconds, whilst small 0.5 sec packets would get you laggy but still recognizable and relatively fluent video on a bad connection.
Same goes for quality. Pixelated and artifact ridden videos are bad, stuttering video/sound desyncing videos are worse. Rather switch down to a lower quality/higher compression setting.
If your question is purely about the getting it done part, well, points 1 and 4 should do for you.
You might ask:
"If I want to do real time live video?"
All of the advice above still applies, but all of it has to be done smarter. First things first: You cannot do realtime over bad connections. It's a reality thing. If your connection is fat enough you can reach almost real time, just pump each image and a small sound sample out without much processing or any buffering at all. It is possible to get a good client experience from that, but connections like that are highly unlikely. The trick here usually is, transmit a video quality slightly lower than the connection would allow in theory and still wiggle caching and packet reordering in there... have fun. It is hard.
不幸的是，vlc 唯一的 API 是命令行或等效的命令行（您可以启动播放器实例，传递它们本质上是您在命令行上拥有的内容）。如果您需要多个实例或回调，您可以使用 libvlc，但它仍然相当不透明......
Unfortunately really the only API vlc has is the command line or equivalent of the command line (you can start player instances, passing them essentially what you would have on the command line). You can use libvlc if you need multiple instances or callbacks but it's pretty opaque still...