如何流媒体视频没有延迟（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. 我想知道是否有人有更好的建议来流式传输具有较低延迟的实时流＆lt; 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 

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

Answer 2

VLC，ffmpeg等传统媒体播放器（在某种程度上来说是mplayer）的问题在于，它们将尝试以一致的帧速率播放，并且这需要一定的缓冲，这会杀死延迟目标。另一种方法是尽可能快地渲染传入的视频，而不关心其他任何事情。

@genpfault和我制作的a custom UDP protocol，计划用于驾驶遥控车和四轮摩托。它的目标是低延迟，但会牺牲很多其他东西（分辨率，比特率，数据包率，压缩效率）。在较小的分辨率下，我们可以在115200波特UART和XBEE上运行它，但是在这些限制下的视频并没有我们希望的有用。今天，由于我不再具有原始设置，因此我正在笔记本电脑（Intel i5-2540M）上运行的320x240配置中进行测试。

您需要计划延迟预算，这是我花在这里的地方：

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

总计为：40.2mS。

编码：

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

此外，必须进行帧内刷新！有效地，这允许切碎正常的“ I”帧并将其与随后的P帧混合。否则，您的比特率需求将出现“泡沫”，这将暂时阻塞您的传输，增加延迟。

编码-传输规划：

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

最终结果320x240

它的速度比我用手机对准笔记本电脑对准相机的可靠测量速度快。压缩比320x240x2B = 150kB /帧，压缩到略高于3kB /帧。