分叉到 libVLC 时的非常奇怪的行为

Question

我有一个使用 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 开发人员能够为我指明正确的方向。

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

谢谢！

Answer 1

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