低延迟 DASH Nginx RTMP答案

【问题标题】：Low Latency DASH Nginx RTMP低延迟 DASH Nginx RTMP
【发布时间】：2017-05-09 11:47:10
【问题描述】：

我在媒体服务器上使用 arut nginx-rtmp-module (https://github.com/arut/nginx-rtmp-module)，然后尝试使用 FFmpeg 流式传输到 dash 应用程序，然后我通过使用 VLC 播放来测试流。

它会等待大约 30 秒开始播放，它从头开始播放，而不是当前时间戳。

这是我当前在 RTMP 块上的配置

rtmp {
    server {
        listen 1935;

        application live {
            live on;

           exec ffmpeg -re -i rtmp://localhost:1935/live/$name
              -c:a libfdk_aac -b:a 32k  -c:v libx264 -b:v 128K -f flv rtmp://localhost:1935/hls/$name_low
              -c:a libfdk_aac -b:a 64k  -c:v libx264 -b:v 256k -f flv rtmp://localhost:1935/hls/$name_mid
              -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/hls/$name_hi
              -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/dash/$name_dash;
        }

        application hls {
             live on;

             hls on;
             hls_path /tmp/hls;
             hls_nested on;

             hls_variant _low BANDWIDTH=160000;
             hls_variant _mid BANDWIDTH=320000;
             hls_variant _hi  BANDWIDTH=640000;
        }

        application dash {
            live on;

            dash on;
            dash_path /tmp/dash;
            dash_nested on;
        }
    }
}

这是我用于流式传输的命令

ffmpeg -re -i 2014\ SPRING.mp4 -c copy -f flv 
rtmp://52.221.221.163:1935/dash/spring

如何减少延迟，并使其从与流媒体相同的时间戳开始播放？

我可以实现低于 5 秒的延迟吗？

更新

尝试使用此指令更改播放列表长度和片段长度

dash_playlist_length 10s;
dash_fragment 2s;

但还是有一些延迟问题，有时比以前小，有时还是一样

【问题讨论】：

标签： nginx ffmpeg rtmp mpeg-dash

【解决方案1】：

我可以实现低于 5 秒的延迟吗？

没有。 DASH 是一种分段协议，这意味着您的媒体被分割成相对较大的块。播放器必须先下载一些块才能开始播放。您的编码器必须在这些块甚至出现在清单中之前上传整个块。这对这项工作来说是错误的工具，任何通过减小块大小来减少延迟的尝试都会给您的项目增加大量开销。如果延迟对您很重要，那么您使用了错误的工具。

如何减少延迟，并使其从与流媒体相同的时间戳开始播放？

你不能。物理！你不可能在编码的同时播放同样的东西。您正在通过分组交换网络发送数据，其中有许多编码/解码步骤，它们都需要一个缓冲区，因为它们以块的形式工作。播放同时播放的内容的唯一方法是模拟...至少您唯一的延迟是光速。

您能做的最好的事情就是切换到专为低延迟而设计的协议，例如 WebRTC。请确保您了解权衡取舍。您的编解码器将针对延迟而不是质量进行优化……因此您的质量会受到影响。 WebRTC over UDP（可选但常见）意味着一些数据包会丢失，从而影响您的观看体验。当你关心延迟时，如果你在这里或那里丢失一个块并不重要，重要的是你继续前进。您可以使用基于 TCP 的 WebRTC，并在延迟略微增加的情况下保持可靠性。

决定什么对你来说真正重要。在几乎所有情况下，它实际上都不是低延迟。你不可能拥有一切。每种方法都有权衡。您必须决定什么最适合您的具体情况。

【讨论】：

您好，很抱歉回复晚了。感谢您的解释，但对于第二个问题，我的意思是我们可以尽可能接近流媒体时间戳吗？不是同一时间的同一件事。因为我现在所拥有的，每次新人观看时，它都会从流的开头开始，而不是它可能播放的最接近的位置

【解决方案2】：

VLC 媒体播放器也有同样的问题。大部分延迟是由客户端播放器造成的，您可以使用没有缓冲区的 ffplayer 来检查它。

ffplay -fflags nobuffer rtmp://192.168.1.66/myapp/live

我的结果，

VLC 延迟：6~7s
ffplay 延迟：500ms

更多信息请参考github上的comment of narlex of issue how to reduce latency

【讨论】：

SRS 比 nginx-rtmp 更稳定、更快速。我测试了一下，flv和rtmp都没有1s延迟了。

【解决方案3】：

您可能需要在 ffmpeg 命令中更改 GOP 大小。 ffmpeg 的默认 GOP 大小为 250，这意味着每 250 帧会有一个关键帧。如果您的输出为 25fps，那么在最坏的情况下，您将每 10 秒有一个关键帧（如果启用了场景切换检测，您的关键帧间隔可能会更短）。

对于 HLS 和 DASH，段必须以关键帧开头。所以你会有很多持续时间为 10 秒的片段。您需要减少分段持续时间（GOP 大小）以减少延迟。

尝试如下修改你的ffmpeg命令，看看是否有帮助

exec ffmpeg -re -i rtmp://localhost:1935/live/$name
          -c:a libfdk_aac -b:a 32k  -c:v libx264 -g 50 -b:v 128K -f flv rtmp://localhost:1935/hls/$name_low
          -c:a libfdk_aac -b:a 64k  -c:v libx264 -g 50 -b:v 256k -f flv rtmp://localhost:1935/hls/$name_mid
          -c:a libfdk_aac -b:a 128k -c:v libx264 -g 50 -b:v 512K -f flv rtmp://localhost:1935/hls/$name_hi
          -c:a libfdk_aac -b:a 128k -c:v libx264 -g 50 -b:v 512K -f flv rtmp://localhost:1935/dash/$name_dash;

【讨论】：