GStreamer调用gst_element_factory_make获取appsrc元素返回空问题

核心原因 #

Windows下g_module_open_full加载DLL报「指定模块找不到」，90%以上场景不是目标DLL本身缺失，而是该DLL依赖的其他二级DLL不在进程的搜索路径中。
gst-inspect和注册表遍历能查到appsrc、gstapp.dll信息，是因为GStreamer会把扫描过的插件元数据存在本地缓存里，就算插件本身已经损坏、依赖缺失，缓存没更新的情况下依然能查到注册信息，不代表插件可正常加载。

排查&解决步骤 #

• 检查DLL依赖完整性
  打开VS自带的开发者命令提示符，执行命令查看gstapp.dll的所有依赖项：

  dumpbin /dependents C:\src\vcpkg\installed\x64-windows\bin\gstapp.dll
  

  对照输出的DLL列表，逐个到GStreamer的bin目录下确认文件存在，重点核查gstbase-1.0-0.dll（gstapp属于base插件集，强依赖gstbase库）、glib/gobject系列运行时DLL是否存在。
  如果你用debug编译模式，注意依赖DLL是否带debug后缀d（比如gstreamer-1.0-0d.dll），debug和release版本DLL混放会直接触发依赖找不到错误。

• 配置正确的进程DLL搜索路径
  VS调试时默认工作目录是项目根目录，不会自动读取GStreamer的bin路径，需要手动配置：
  右键项目 -> 属性 -> 调试 -> 环境，添加路径配置：

  PATH=C:\src\vcpkg\installed\x64-windows\bin;%PATH%
  

  debug模式下把路径替换为C:\src\vcpkg\installed\x64-windows\debug\bin即可。禁止同时把debug和release的bin路径加入PATH，会触发版本冲突。
  如果用官方MSI安装包，把路径替换为你实际安装路径下的bin目录即可。

• 校验编译链接配置一致性
  确保项目编译配置和GStreamer库版本完全匹配：

  • Release模式下必须链接不带d后缀的release版GStreamer lib文件，PATH中放release版DLL
  • Debug模式下对应链接带d后缀的debug版lib，PATH中放debug版DLL
  • 确认项目预处理器宏中定义的GStreamer版本号和你安装的1.19.2一致，避免版本不兼容导致的加载失败。

• 强制加载插件排查具体错误
  不要直接调用gst_plugin_load_file加载指定路径DLL，在gst_init执行完成后，调用插件名加载接口，拿到更明确的错误信息：

  GstPlugin* app_plugin = gst_plugin_load_by_name("app");
  if (!app_plugin) {
      gchar* err_msg = gst_plugin_get_error(NULL);
      g_print("load app plugin failed: %s\n", err_msg);
      g_free(err_msg);
  }
  

  如果需要验证缓存问题，可以先执行gst_registry_remove_all_plugins(gst_registry_get())清空插件缓存，再重新扫描插件，此时如果gstapp加载失败，遍历注册表就不会再出现appsrc、appsink的记录。

常见踩坑点 #

• vcpkg安装GStreamer时不会自动配置VS调试环境的PATH，很多人只加了gstreamer核心库的bin路径，漏了gstbase等依赖库的路径，导致gstapp加载失败
• 1.19.2是GStreamer开发分支版本，不是稳定发布版，如果vcpkg编译时开启了静态编译选项，gstapp插件可能没有正确编译为动态库，但旧的注册表缓存依然存在，导致能查到元数据但加载失败
• 如果项目开启了DLL延迟加载选项，不要把gstapp及其依赖库加入延迟加载列表，否则依赖缺失时会直接抛出「找不到指定模块」错误，不会提示具体缺哪个DLL。

内容的提问来源于stack exchange，提问作者Cthurier