nginx - 低延迟 DASH Nginx RTMP

Question

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

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

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

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;

但仍然有一些延迟问题，有时它比以前小，有时它是一样的

Answer 1

Can I achieve under 5s latency?

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

How can I reduce the delay, and make it play from the same timestamp as the streamer?

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

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

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