受到另一篇文章的一些启发,我可以使用 Gstreamer 和 RTMP 在 Azure 媒体服务基本直通直播活动上成功进行直播。
但是,它不会停留太久。我想让流 24/7 工作,但几个小时后,预览和出口输出得到越来越多的缓冲/加载,并出现许多浏览器控制台 404 错误。
我怀疑是因为我每6小时重启一次直播?我该如何解决这个问题?
这是我的 Gstreamer 命令:
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, width=640, height=480, format=BGR \
! vspmfilter dmabuf-use=true ! video/x-raw, format=NV12 \
! omxh264enc control-rate=2 target-bitrate=10485760 \
! video/x-h264,profile=\(string\)high,level=\(string\)4.2 \
! h264parse config-interval=-1 \
! mux. audiotestsrc is-live=true wave=silence ! audio/x-raw,rate=48000 ! faac bitrate=96000 ! aacparse ! audio/mpeg, mpegversion=4! mux. flvmux streamable=true name=mux \
! rtmpsink location="${dest} live=1 flashver=FMLE/3.0(compatibble;FMSc/1.0)"
要使用 GStreamer 和 RTMP 在 Azure 媒体服务上维护 24/7 实时流,而不遇到缓冲/加载时间增加或浏览器控制台 404 错误,您可能需要避免每 6 小时重新启动一次流。随着时间的推移,这种方法可能会造成中断和潜在的资源分配问题。
您可以尝试将 librtmp 超时设置为 0,如原始线程中的建议。 但GStreamer的RTMP接收器(
rtmpsink
)本身并不支持自动重连或错误恢复。您将需要在更高级别上管理这些方面,可能使用自定义脚本或应用程序逻辑。
为了长期稳定性,请考虑添加一种机制来监视管道的状态,并在管道发生故障时自动尝试重新连接。您通常可以通过外部脚本或用 Python 或 C 编写的 GStreamer 应用程序来管理此操作,您可以在其中捕获错误并根据需要重新启动管道。
#!/bin/bash
while true; do
gst-launch-1.0 your_pipeline_here
echo "Stream stopped, restarting in 5 seconds..."
sleep 5
done
另外,请考虑根据您的实际网络情况调整
target-bitrate
和其他编码器设置。动态比特率调整有助于在不同的网络条件下保持流的稳定性。