我在媒体服务器上使用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;
但是仍然存在一些延迟问题,有时它比以前小,有时是相同的
我可以达到5秒以下的延迟吗?
不会。DASH是分段协议,这意味着您的媒体被切成相对较大的块。播放器必须先下载一些块,然后才能开始播放它们。您的编码器必须上传整个块,然后这些块才出现在清单中。这是错误的工作工具,任何通过减小块大小来减少延迟的尝试都会给您的项目增加大量的开销。如果延迟对您很重要,则您使用的工具错误。
如何减少延迟,并使延迟与流光播放的时间戳相同?
你不能 物理!您不可能在被编码的同时播放相同的东西。您正在通过分组交换网络发送数据,其中许多编码/解码步骤的方式都需要缓冲区,因为它们以块的形式工作。播放同时播放的内容的唯一方法是进行模拟...至少那里唯一的延迟是光速。
最好的办法就是切换到专为低延迟而设计的协议,例如WebRTC。只要确保您了解这些折衷方案即可。您的编解码器将针对延迟而不是质量进行优化……因此,质量会受到影响。UDP上的WebRTC(可选,但很常见)意味着某些数据包将丢失,从而导致观看体验受损。当您关心延迟时,在这里或那里丢失一块块都没关系,重要的是您继续前进。您可以在TCP上使用WebRTC,并使可靠性仅在延迟中稍有增加。
确定什么对您真正重要。在几乎每种情况下,它实际上都不是低延迟。您不可能一路拥有。每种方法都需要权衡。您必须决定哪种方法最适合您的特定情况。
VLC媒体播放器也有同样的问题。大部分延迟是由客户端播放器造成的,您可以使用不带缓冲区的ffplayer对其进行检查。
ffplay -fflags nobuffer rtmp://192.168.1.66/myapp/live
我的结果
VLC延迟:6〜7s
ffplay的延迟:500ms
有关更多信息,请参阅问题narlex的评论如何减少 github上的延迟