如何流媒体视频没有延迟（ffplay，mplayer）和什么样的包装可以用于ffplay？

Question

我一直在测试使用不同的播放器播放多个直播流，因为我想获得最低的延迟值。我尝试了gstreamer播放器（gst-launch-0.01），mplayer，totem和ffmpeg播放器（ffplay）。我使用不同的配置值来获得每个配置值的最低延迟，例如：

ffplay -fflags nobuffer 
mplayer -benchmark

我流媒体的协议是udp，我使用ffplay比mplayer或gst-launch获得更好的价值。说实话，我不知道我需要什么样的配置才能让gstreamer获得更低的延迟。现在，我需要的是两件事：

1. 我想知道是否有人有更好的建议来流式传输低延迟<100毫秒的直播流。我现在高于100毫秒，这对我来说效率不高。
2. 由于我目前正在使用ffplay，因为它是目前为止最好的。我想做一个带有播放和录制按钮的简单gui和3个屏幕从不同的视频服务器流，我只是不知道使用什么样的包装（应该真的很快）！

Answer 1

那么，对于真正低延迟的流媒体场景，您可以尝试NTSC。理想情况下，它的延迟可以低于63us（微秒）。

对于质量接近NTSC和40ms延迟预算的数字流媒体，请参阅rsaxvc在120hz的答案。如果你需要Over The Air流媒体，这是我见过的最好的低延迟选项，它经过深思熟虑，分辨率将随着硬件功能而扩展。

如果您的意思是数字流，并且您希望获得良好的压缩率，即通过wifi获得1080p，那么如果您希望使用当今的商用硬件时延迟少于100毫秒，那么您就不幸了，因为为了使压缩算法具有良好的压缩比，它需要很多背景。例如，Mpeg 1在ipbbpbbbbbpb GOP（图片组）排列中使用12帧，其中i是'帧内'帧，其实际上是jpeg静止，ap是预测帧，其编码i帧和p帧之间的一些运动，以及b帧编码一些现场修正，其中预测不能很好地工作。无论如何，即使在60fps的12帧仍然是200ms，所以200ms只是为了捕获数据，然后一段时间来编码它，然后一段时间来传输它，然后一段时间来解码它，然后一段时间来缓冲音频所以当CPU将新块发送到DMA存储区时，声卡不会耗尽数据，同时需要将2-3帧视频排队等待发送到视频显示器以防止撕裂数字显示器。所以真的至少有15帧或250毫秒，加上传输延迟。 NTSC没有这样的延迟，因为它是传输模拟的唯一'压缩'是两个偷偷摸摸的技巧：隔行扫描，每次只有一半的帧作为交替行传输，即使在一帧，奇数在下一帧，然后第二个技巧是通过使用3个黑白像素加上其相位辨别来确定所显示的颜色的颜色空间压缩，因此颜色以亮度（亮度）信号的带宽的1/3传输。很酷吗？而且我想你可以说音频有一种“压缩”，因为自动增益控制可以用来使20dB的模拟音频信号看起来更接近60dB的体验，将我们的耳朵从我们的脑袋中拉出来由于AGC在节目和广告之间的2-3秒静音期间增加了音量，所以广告。后来当我们获得更高保真度的音频电路时，广告实际上比节目更响亮，但这只是他们提供与旧电视给广告商相同的影响的方式。

Nostalgia（tm）为您带来了这条记忆通道。买Nostalgia品牌香皂！ ;-)

这是我在Ubuntu 18.04下用库存ffmpeg和mpv取得的最好成绩。这需要第三代英特尔酷睿处理器或更高版本。有关使用NVidia硬件编码的说明，请参见ffmpeg网站。

ffmpeg -f x11grab -s 1920x1080 -framerate 60 -i :0.0 \
  -vaapi_device /dev/dri/renderD128 \
  -vf 'format=nv12,hwupload,scale_vaapi=w=1920:h=1080' \
  -c:v h264_vaapi -qp:v 26 -bf 0 -tune zerolatency -f mpegts \
  udp://192.168.1.201:12345

然后在媒体框中：

mpv --no-cache --untimed --no-demuxer-thread --video-sync=audio \
  --vd-lavc-threads=1 udp://192.168.1.201:12345 

这可以实现大约250毫秒的延迟，1080p @ 60hz，大约3Mbps，这对于wifi上的流媒体节目来说是可以的。 mpv可以调整嘴唇同步（CTRL + - 在比赛期间）。用于媒体控制的流媒体桌面鼠标/键盘交互是可以容忍的，但它不能用于实时游戏（参见NVidia Shield，用于远程游戏的Google Stadia）

Answer 2

传统媒体播放器（如VLC，ffmpeg，以及某种程度上的mplayer）的问题在于它们会尝试以一致的帧速率播放，这需要一些缓冲，这会导致延迟目标。另一种方法是尽可能快地呈现传入的视频，而不关心其他任何事情。

@genpfault和我制作了a custom UDP protocol，计划用于飞行遥控车和四驱车。它以低延迟为目标，牺牲了其他所有功能（分辨率，比特率，分组率，压缩效率）。在较小的分辨率下，我们得到它超过115200波特UART和XBEE，但在这些限制下的视频没有我们希望的那么有用。今天我正在测试320x240配置，在笔记本电脑（Intel i5-2540M）上运行，因为我不再拥有原始设置。

您需要计划延迟预算，这是我花费的时间：

1. 收购 - 我们选择了125FPS PS3 Eye相机。所以我们的延迟最多只有8mS。应避免使用“智能”摄像机进行板载压缩（h264或MJPEG）。此外，如果您的相机具有任何类型的自动曝光时间，您将需要禁用它以最快的帧率锁定它，或提供充足的照明（今天，我的内置网络摄像头由于AE而仅执行8 FPS）。
2. 转换 - 如果可能，让相机以您可以直接压缩的格式发出帧（通常为YUV格式，Eye本身支持）。然后你可以跳过这一步，但我在这里花了0.1毫秒。
3. 编码 - 我们使用了专门调整的H.264。它需要大约2.5mS，并且不需要以压缩比为代价来缓冲未来的帧。
4. 传输 - 我们使用UDP over WiFi，<5mS正常工作时没有其他一些无线电干扰。
5. 解码 - 这几乎受到接收器CPU的限制。编码器可以通过发送多线程可解码的工作来提供帮助。这通常比编码更快。今天~1.5mS。
6. 转换 - 您的解码器可能会为您执行此步骤，但通常编码器/解码器会说YUV，显示器会说RGB，并且有人必须在它们之间进行转换。在我的笔记本电脑上0.1毫秒。
7. 显示屏 - 没有VSYNC，60 FPS显示器的延迟高达~17mS，加上一些LCD延迟，可能是6ms？这真的取决于显示器，我不确定这台笔记本电脑有哪个面板。

总数达到：40.2mS。

编码方式：

当时，X264是我们能找到的最好的H264-AnnexB编码器。我们必须控制比特率，slice-max-size，vbv-bufsize，vbv-maxrate。从“超高速”和“零容量”的默认值开始，这将禁用B帧。

此外，帧内刷新是必须的！实际上，这允许切断正常的“I”帧并将其与以下P帧混合。如果没有这个，你会在比特率需求中产生“泡沫”，这会暂时阻塞你的传输，增加延迟。

编码交通规划：

调制编码器以生成UDP大小的H264 NALU。这样，当一个UDP数据包被丢弃时，整个H264 NALU被丢弃了，我们不必重新同步，解码器只是......被打破...并继续一些图形损坏。

最终结果320x240

它比我用手机指向笔记本电脑的相机可靠地测量得快。压缩比320x240x2B = 150kB /帧，压缩至略高于3kB /帧。