低延迟DASH Nginx RTMP [英] Low Latency DASH Nginx RTMP

问题描述

我使用了arut nginx-rtmp-module（ https://github.com/arut/ nginx-rtmp-module ），然后我尝试使用FFmpeg流向 dash 应用程序，然后我使用VLC播放流测试流

I use arut nginx-rtmp-module (https://github.com/arut/nginx-rtmp-module) on the media server, then I tried to stream using FFmpeg to the dash application, then I test the stream by playing it using VLC.

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

And it waits around 30secs to start playing, and it plays from the beginning, not the current timestamp.

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

This is my current config on the 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;
        }
    }
}

这是我使用的命令流媒体

This is the command I use for streaming

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

如何减少延迟，并使其播放来自与流光线相同的时间戳？

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

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

Can I achieve under 5s latency?

更新

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

Tried to change the playlist length and fragment length, using this directive

dash_playlist_length 10s;
dash_fragment 2s;

但仍然有一些延迟问题，有时比以前更小，有时是相同的

But still got some latency problem, sometimes it's smaller than before, sometimes it's the same

推荐答案

我可以实现5秒以下的延迟吗

Can I achieve under 5s latency?

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

No. DASH is a segmented protocol, meaning your media is chopped up into relatively large chunks. The player has to download some chunks before it can start playing them. Your encoder has to upload entire chunks before these chunks even appear in the manifest. This is the wrong tool for the job, and any attempts at reducing latency by cranking the chunk size down are adding massive overhead to your project. You're using the wrong tool for the job if latency is important to you.

如何减少延迟，并使其与拖缆相同的时间戳播放？

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

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

You can't. Physics! It's impossible for you to play the same thing at the exact same time as it is being encoded. You're sending data over a packet-switched network, with many encoding/decoding steps in the way which all require a buffer as they work in chunks. The only way to playback what's coming in simultaneously is to go analog... at least there your only delay is the speed of light.

最好的方法是切换针对低延迟设计的协议，如WebRTC。只要确定你了解权衡。您的编解码器将针对延迟进行优化，而不是质量优化，因此您的质量将受到损害。通过UDP（可选但通用）的WebRTC意味着某些数据包将丢失，从而导致您的观看体验受损。当你关心延迟时，如果你在这里或那里失去一大块，这并不重要，重要的是你继续前进。您可以使用WebRTC over TCP，并保持您的可靠性只有稍微增加延迟。

The best you can do is switch to a protocol designed for low latency, like WebRTC. Just be sure you understand the tradeoffs. Your codecs will be optimized for latency, not quality... so your quality will suffer. WebRTC over UDP (optional but common) means that some packets will get lost, causing your viewing experience to suffer. When you care about latency, it doesn't matter so much if you lose a chunk here or there, what matters is that you keep going. You can use WebRTC over TCP and keep your reliability at only a slight increase in latency.

确定真正重要的事情。在几乎每一种情况下，实际上并不是很低的延迟。你不可能有所有的方法。每个方法都有权衡。你必须决定最适合你的具体情况。

Decide what really matters to you. In almost every case, it isn't actually low latency. You can't have it all ways. There are tradeoffs to every approach. You must decide what is best for your specific situation.

这篇关于低延迟DASH Nginx RTMP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！