使用C#调用mingw的so文件，在C++端使用opencv打开视频。这样的项目完成过了一个，第二次做的时候，发现opencv打开视频文件出错。
首先怀疑是opencv的opencv_ffmpeg2410.dll文件找不到，确认了文件位置仍然不行。
然后怀疑是新换的mingw32编译器问题，换回了老版本仍然不行。
最后确认了视频文件的存在性，传递文件名的正确性，一切正常，视频无法打开。
在试验过程中，出现了很多次segmentation fault的情况，发现是因为两个mingw32编译器和他们的运行时库冲突问题。当我切换了环境变量更换编译器时，由于VS2010不重启，环境变量就不更新，所以使用VS2010启动的程序还使用原来的运行时dll；在vim中编译时，不退出环境变量不更新，有时根本没有换编译器编译。而测试编译器时一般都是在新建的命令窗口中输入g++ --version，这样看到的结果都是对的。
为了确认程序引用的dll正确性，关闭了所有程序，删除了散乱的运行时dll，将PATH环境变量整理后，打开了之前项目里做的工程，结果之前的工程能够在两个版本编译器下正确运行，而且与so文件位置无关。此时问题定位在了新写的so库上。
将新的工程中so库的代码一点一点的注释，最后只剩下视频部分，仍然不能打开。再将老工程直接复制过来，接口与新的工程做成一样的，就是让新的C#程序调用老的so文件，结果能够成功打开，然后在老so基础上逐步修改，发现修改指令部分时就出错了，最后怀疑是视频文件名正确性，之前确认正确性的时候只是从日志文件中看到了文件名，在资源管理器中证明了正确性，但文件名中可能存在无法显示的字符，导致无法访问。所以在程序中加入了 slog.log(sFormat("%s,%d",url.c_str(),url.size()).c_str()); 输出文件名的长度为26个字符，而使用无法打开视频的代码，文件名长度为27字符，说明不对，多出来的是文件名前端的空格，修改命令解析部分，删除空格后，正确执行。