适用于Android（3.0+）的VLC的规范低延迟设置

Question

我最近开始在Android应用程序中使用libVLC，目的是替换我们花很多钱购买的商业SDK，但看不到希望的结果。该应用程序要求尽可能接近实时地查看RTSP流。理想情况下为500毫秒或更长时间（取决于平板电脑），而延迟不会随时间漂移。

退出用于libVLC的商业SDK的过程几乎是无缝的，并且可以立即进行，但延迟只有几秒钟（无需更改任何默认设置）。它可以非常快速地连接到RTSP流，并且不会断开连接。

我花了几天的时间来调整各种设置，以尽可能减少延迟。在某些情况下，我会得到300ms的延迟，最终流会下降到几秒钟的延迟，然后流会丢失并重新启动（然后延迟舞会再次开始）。在其他情况下（我猜我将网络缓存设置得太低时），我会得到充满错误的日志，并且从不获取图片。

我当前的设置是：

val media = Media(libVLC, Uri.parse(streamUrl))
media.setHWDecoderEnabled(true, false)
media.addOption(":network-caching=300")
media.addOption(":clock-jitter=0")
media.addOption(":clock-synchro=0")

如果我将其设置network-caching为小于200的任何值，我将永远看不到图像（我读到某处的图像可能是因为平板电脑的解码器延迟时间高于200毫秒）。

无论如何，我发现十年来有数十种可能的答案，有些是相似的，有些是冲突的，有些使用了已弃用的标志。一些值得注意的：

2019：https : //forum.videolan.org/viewtopic.php? t =149511

m.AddOption(":network-caching=150");
m.AddOption(":clock-jitter=0");
m.AddOption(":clock-syncro=0");

2018：Android LibVLC选项不起作用

options.add("--network-caching=50");
options.add("--clock-jitter=0");
options.add("--clock-synchro=0");

2017：减少在Android上使用libvlc播放rtp流时的延迟

LibVLC libVlc = new LibVLC(context, arrayListOf(
    "--file-caching=150", 
    "--network-caching=150",
    "--clock-jitter=0",
    "--live-caching=150", 
    "--clock-synchro=0",
    "-vvv", 
    "--drop-late-frames", 
    "--skip-frames"
)); 

...OR...

media.setHWDecoderEnabled(true, false);
media.addOption(":network-caching=150");
media.addOption(":clock-jitter=0");
media.addOption(":clock-synchro=0");

2015年：https：//forum.videolan.org/viewtopic.php？f = 35＆t = 124932＆p = 420020＆hilit = latency＃p420020

Set network cache to 500, and disable HW acceleration

2015年：减少流媒体和实时流媒体方法的延迟

mLibvlc.setDevHardwareDecoder(LibVLC.DEV_HW_DECODER_AUTOMATIC);
mLibvlc.setHardwareAcceleration(LibVLC.HW_ACCELERATION_DISABLED);
mLibvlc.setNetworkCaching(150);
mLibvlc.setFrameSkip(true);

2013年：使用VLC通过RTP流式传输桌面，并尽可能降低延迟

Related to Desktop VLC and tweaking FFMPEG

当然，这里有巨大的VLC标志列表：https：//wiki.videolan.org/VLC_commaand-line_help/

因此，总而言之，对于Android上的libVLC 3+是否有一种规范的方法可供我们共同用于实时流式传输应用程序？

就我而言，零缓存和丢弃较晚的帧是理想的（即使对于不稳定的帧也是如此）。但是，我也确实了解，对于大多数人而言，稳定的流媒体（偶尔会有偶尔的帧丢失）将是首选。

我最初在三天前发布在VideoLAN论坛上。