分叉到 libVLC

如何解决分叉到 libVLC

我有一个使用 libVLC 构建的应用程序，可以访问 Ubuntu Linux 上标准安装的 libvlc-dev 库、插件、头文件等。 我的应用程序通常运行良好，主要用于接收 UDP 流并转换为其他内容。

然而，我在特定模式下遇到了一个非常奇怪的问题，到目前为止，我已经投入了大约 30 个开发小时来尝试解决这个问题——我希望这里的一些 VLC 天才可以解开这个难题。

它围绕基于 http:// 的 URL 源。通常适用于 HLS，但任何基于 http 的源都会出现同样的问题。

重要提示：如果我在终端中启动我的应用程序，一切 都能完美运行（包括 http 流）。但是，如果我使用 fork() 和 execv() 从父进程使用相同的启动参数“子启动”同一个应用程序，它就无法播放任何基于 http 的流（尽管像 UDP 这样的东西仍然可以完美地工作）。>

我已经检查了一些显而易见的事情，比如确保 VLC_PLUGIN_PATH 设置正确，并且我已经详尽地比较了 2 个启动状态下的所有其他环境变量，但没有发现任何明显相关的内容。 启用完整日志记录后，我可以看到在 url 打开过程中存在明显差异 - 在评估插件适用性时似乎有些不对劲。

在终端启动中： 寻找匹配“http”的 access_demux 模块：20 个候选 没有匹配的 access_demux 模块 创建访问：http://...snip....myfeed.m3u8 寻找匹配“http”的访问模块：28 个候选 解决..snip..myfeed 传出请求： 并且流播放良好

但是，当 fork 和 execv 时，我看到以下内容： 寻找匹配“http”的 access_demux 模块：40 个候选 没有匹配的 access_demux 模块 创建访问：http://...snip....myfeed.m3u8 寻找匹配“http”的访问模块：56 个候选 它就在那里，甚至不会发出 http 调用。

当然，我希望可能是一个线索的奇怪之处是分叉环境在匹配时找到了两倍的候选者。但是，它没有完成http访问阶段，并没有进一步。

这让我发疯了，到目前为止我已经放弃了 5 次，只是为了再试一次。但是，我已经用尽了通过日志记录所能发现的东西，我真的希望这里的 VLC 开发人员能够为我指明正确的方向。

非常感谢您提供的任何想法、技巧、直觉或其他任何东西。

谢谢！

解决方法

已解决：在父应用程序中，我们碰巧正在调用：signal(SIGCHLD,SIG_IGN);在 fork() 之前的某个时间点。 （所以这大概是由孩子继承的）在这种情况下，当 fork 和 execved libVLC 无法使用 http 源时。在 VLC 的 http 处理中必须有一些依赖于 SIGCHLD 的行为。我们可以通过删除信号（SIGCHLD，SIG_IGN）来解决这个问题；从父级，或通过添加信号（SIGCHLD，SIG_DFL）；到子 libVLC 应用程序。一旦我们这样做，libVLC 就会按预期运行。