低延迟 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.请确保您了解权衡.您的编解码器将针对延迟而不是质量进行优化……因此您的质量会受到影响.WebRTC over UDP(可选但常见)意味着一些数据包会丢失，从而导致您的观看体验受到影响.当您关心延迟时，在这里或那里丢失一块并不重要，重要的是您继续前进.您可以通过 TCP 使用 WebRTC，并在延迟略有增加的情况下保持可靠性.

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屋！