我一直在测试使用不同的播放器同时播放多个直播流，因为我想获得最低的延迟值。我尝试了gstreamer播放器（gst-launch-0.01）、mplayer、totem和ffmpeg播放器（ffplay）。我使用了不同的配置值来获得它们每一个的最低延迟，例如：
ffplay -fflags nobuffer
mplayer -benchmark
我正在使用UDP协议进行流媒体传输，而且我发现使用ffplay比mplayer或gst-launch获得了更好的数值。老实说，我不知道我需要进行哪种配置才能在gstreamer上实现更低的延迟。
现在，我需要两件事：
我想知道是否有更好的建议可以实现低于100毫秒的低延迟直播流。我现在的延迟高于100毫秒，对我来说效率并不高。
由于我目前正在使用ffplay，因为它是目前为止最好的选择。我想要一个简单的GUI，带有播放和录制按钮以及3个屏幕从不同的视频服务器进行流媒体传输，我只是不知道使用什么样的包装器（应该非常快速）！
对于需要非常低延迟的流媒体方案，您可以尝试NTSC。理想情况下，其延迟可以低至63微秒。
如果需要数字流媒体且预算为40ms，则可以参考rsaxvc在120hz处给出的答案，以获得接近NTSC级别的质量。如果需要通过无线电进行流媒体传输，则这是我见过的最好的低延迟选项，经过了很好的思考，并且分辨率将随着硬件能力的提高而扩展。
如果您指的是数字流媒体，并且希望通过wifi实现1080p的压缩比较好，那么如果要在今天的普通硬件上实现低于100ms的延迟，就会遇到困难，因为为了使压缩算法具有良好的压缩比，它需要许多上下文信息。例如，Mpeg 1使用12个帧组成一个ipbbpbbpbbpb GOP（图片组），其中i是“intra”帧，实际上是一张jpeg静态图像，p是一帧预测帧，它编码了i和p帧之间的某些运动，b帧编码了某些修复预测错误的地方。总之，即使以每秒60帧的速度捕获数据，12个帧仍需要200ms，因此需要250ms才能捕获数据，然后需要一些时间对其进行编码，然后传输，解码，缓冲音频以使声卡在CPU发送新块到DMA内存区域时不会丢失数据，并且同时需要排队发送2-3帧视频到视频显示器，以防止数字显示器上出现撕裂。因此，实际上至少需要15帧或250毫秒的延迟，加上传输引起的延迟。NTSC没有这样的延迟，因为它是模拟传输，唯一的“压缩”是两个巧妙的技巧：交织，在每次传输中仅传输一半每一帧的行，即在一帧上是偶数行，在下一帧上是奇数行，然后第二个技巧是通过使用3个黑白像素和其相位判别来确定显示的颜色，从而对颜色空间进行压缩，因此颜色信号以亮度（luma）信号的1/3的带宽进行传输。很酷吧？我想您也可以说音频也有一种“压缩”，即可以使用自动增益控制使20dB的模拟音频信号看起来提供近60dB的体验，因为在节目与商业广告之间的2-3秒寂静期间，AGC会在商业广告中将音量调高，使我们的耳朵爆发。后来，当我们获得了更高保真度的音频电路时，商业广告实际上比节目播放的音量要大，但这只是他们以前的方式，以使广告商提供与旧电视相同的影响力。
这段回忆之旅由怀旧（tm）品牌带给您。购买怀旧牌卫生香皂！;-)
这是我在Ubuntu 18.04上使用默认的ffmpeg和mpv达到的最佳效果。这需要第三代英特尔Core处理器或更高版本
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://$HOST_IP:12345
然后在媒体盒上：
mpv --no-cache --untimed --no-demuxer-thread --video-sync=audio \
--vd-lavc-threads=1 udp://$HOST_IP:12345
mpv可以调整音频和视频同步(Ctrl +-)，对于流式桌面鼠标/键盘互动以进行媒体控制是可以容忍的，但是对于实时游戏来说无法使用(参见NVidia Shield，Google Stadia进行远程游戏)。传统媒体播放器如VLC、FFmpeg和在某种程度上的MPlayer存在的问题是它们会尝试以一致的帧速率播放，这需要一些缓冲，这会影响延迟目标。另一种选择是尽可能快地呈现传入的视频，不关心其他任何东西。
@genpfault和我制定了一种自定义UDP协议，旨在用于飞行遥控车和四轴飞行器。该协议以低延迟为目标，但牺牲了几乎所有其他因素（分辨率、比特率、数据包速率、压缩效率）。在较小的分辨率下，我们将其运行在115200波特率的UART和XBEE上，但是在这些限制下的视频并没有像我们希望的那样有用。今天，我正在测试320x240配置，运行在笔记本电脑上（Intel i5-2540M），因为我已经没有原始设置。
您需要计划好您的延迟预算，以下是我花费预算的地方:
Acquisition - 我们选择了125FPS的PS3 Eye摄像头。因此，我们的延迟最多只有8毫秒左右。应避免使用“更智能”的摄像头，在设备上进行压缩（无论是h264还是MJPEG）。此外，如果您的摄像头具有任何自动曝光时间控制功能，则需要禁用它以锁定最快的帧速率，或提供充足的照明（今天，我的内置网络摄像头仅以8 FPS运行，因为自动曝光）。
我用手机对着摄像头对准我的笔记本电脑进行测量，但速度比我能够可靠地测量的速度要快得多。压缩比为320x240x2B = 150kB/frame，压缩后每帧仅留下3kB左右。