通过 udp 流式传输 h264/aacplus 媒体
有人有这方面的经验吗？
到目前为止，我已经尝试使用 ffmpeg（使用 libx264 和 libaacplus）通过 udp 混合到 mpegts 中，但 mpegts 混合器显然已损坏（从多个不同来源确认）。 我也尝试过使用 vlc，但它只能编码 AAC-LC 而不能编码 HE-AAC v2 (aacplus)。
不管怎样，我需要解决的问题是有几个不同的地理位置，覆盖着网络摄像头，我需要 udp 能够一直有传入的流，而不用担心网络的起伏（udp 将简单地继续发送数据包，当网络又恢复了）。那么，你们中的任何人是否有使用 h264 和 aacplus 通过 udp 协议使用流媒体直播的经验，如果有，请给我任何链接或指导如何完成它。
预先非常感谢。
Does anyone have any experience in this area?
I've tried so far with ffmpeg (using libx264 and libaacplus) muxing into mpegts over udp, but that mpegts muxer is obviously broken (confirmed from several different sources).
I've also tried with vlc, but it can only encode AAC-LC and not HE-AAC v2 (aacplus).
Anyway, the problem I need to solve is to have several different geographic locations, covered with webcams and I need udp to be able to have incoming streams all the time and not to worry about networks ups and downs (udp will simply continue sending packets when the network is up again). So, did any of you have any experience using streaming live media using h264 with aacplus over udp protocol and if yes, can you please give me any links or directions how to accomplish it.
Thanks a lot in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我正在开发一个类似于 DVR 的系统，它必须定期从视频设备记录 h264 文件，同时提供本地预览以允许调整视频参数和摄像机视图。虽然我不是这个领域的专家，但我在 UDP 上流式传输 h264 方面取得了相对成功，因此我将尝试分享哪些没有成功以及哪些对我有用，这些都基于 ffmpeg< /strong> 作为服务器（在我的情况下没有音频）。
最初，我将应用程序设置为同时将视频录制到文件中，并将其提供给 .ffm 文件，以便 ffserver 使用 RTP/UDP 进行流式传输以进行相机预览。这种方法的问题在于，当馈送 ffmpeg 进程停止更改视频文件时，预览将停止并且永远不会恢复，尽管后续 ffmpeg 进程已经开始再次馈送 ffserver。对于 RTP，ffserver 显然会抱怨帧时间戳从 0 开始，而不是在停止的地方继续。然后我意识到，如果我能够通过纯 UDP 发送 h264 数据包，我将得到与您描述的完全相同的效果，只要下一个 ffmpeg 进程接管，预览就会恢复。
在尝试理解 ffmpeg 文档时，我还尝试使用 mpegts 格式，但这样做我在另一端的播放器上获取 MPEG2 视频（这显示了多播地址，但它也适用于特定目标）：
在客户端 PC 上我能够使用 ffplay 观看视频，并且它确实是 MPEG2 格式：
VLC 也可以播放流，但只有在指定开关之后- -解复用器ffmpeg（感谢这个）：
由于我也希望预览采用 h264 格式，但我已经对文件进行了编码，因此我尝试使用复制编解码器进行 UDP 流传输，但 ffmpeg 因段错误而失败（包含的版本供参考）：
虽然不太理想，但为 UDP 流部分指定格式 h264 导致了第二次并发 h264 转换，但它有效：
在客户端 ffplay 反复抱怨一些缺失信息，但几秒钟后它终于显示了视频，这还可以，但有点断断续续：
然后我尝试了使用相同的“--demux ffmpeg”开关的 VLC ；它还抱怨 SPS/PPS（还不知道它是什么），但最终它播放视频非常顺利：
我仍在尝试找出缺少的内容，但结果已经令人满意。 VLC 播放后，我可以停止播放暂停的 ffmpeg，当我在另一端重新启动 ffmpeg 时，我可以立即恢复播放。
希望这对您有帮助，如果您有任何关于使用 h264 作为所选格式代替 mpegts 的附加信息，请告诉我 - 我怀疑缺少的 SPS/PPS 信息可能与此有关。
I'm developing a system which is kind of a DVR that must periodically record a h264 file from a video device and at the same time provide a local preview to allow for adjusting the video parameters and camera view. Although I am no expert at all in this field, I had a relative success streaming h264 over UDP, so I'll try to share what didn't and what did work out for me, which was all based on ffmpeg as a server (no audio in my case).
Initially I had set up my application to simultaneously record the video to a file and feed it to a .ffm file for ffserver to stream it up using RTP/UDP for the camera preview. The problem with that approach was exactly that when the feeding ffmpeg process stopped to change the video file, the preview would stop and never resume although the subsequent ffmpeg process would have already started feeding ffserver again. With RTP ffserver apparently complains the frames timestamp started back at 0 instead of continuing where they have stopped. Then I realized that if I were able to send the h264 packets over pure UDP I would get exactly the same effect you described, with preview resuming as soon as the next ffmpeg process would take over.
While trying to understand ffmpeg documentation I also tried using the mpegts format, but doing that I was getting MPEG2 video at the player on the other end (this shows a multicast address, but it also worked for a specific target):
On the client PC I was able to watch the video with ffplay, and it was indeed in MPEG2 format:
VLC also worked to play the stream, but only after specifying the switch --demux ffmpeg (thanks to this):
Since I also wanted the preview to be in h264 but I already had it encoding the file, I tried to use the copy codec for the UDP streaming, but ffmpeg failed with a segfault (versions included for reference):
Although less than ideal, specifying the format h264 for the UDP streaming part led to a second concurrent h264 conversion, but it worked:
On the client side ffplay repeatedly complained about some missing information, but after some seconds it finally showed up the video, which was ok but a bit choppy:
I then tried VLC with the same ''--demux ffmpeg'' switch; it also complained about SPS/PPS (don't know what it is about yet) but in the end it played the video really smoothly:
I'm still trying to figure out what is missing, but the results are pleasing already. After VLC is playing I can stop the feeding ffmpeg that playback pauses and resumes right away when I restart ffmpeg on the other end.
Hope this can be of any help, and please let me know if you have any additional info on using h264 as the chosen format in place of mpegts - I suspect this missing SPS/PPS info might have something to do with it.