2022

使用Win10 + WSL编译FFmpeg时的依赖库处理

Windows 10的Linux子系统WSL安装过程就不做赘述了,网上资料很多。

之前一直认为WSL只是以类似虚拟机或容器化的方式使得能在Windows上运行原生Linux程序,当然,也在WSL上做过如使用ndk交叉编译Android原生程序、动态库的操作,用起来还是挺方便的。直到最近研究FFmpeg的Windows版编译时才发现(参考自:https://www.bilibili.com/read/cv7058269/),原来WSL还有一个“大杀招”:直接运行Windows执行程序exe,如下图所示:

可以看到,在WSL内直接执行VS 2019的编译器程序cl,也是完全没有问题的,基于这种方法,FFmpeg官网上所说的用cygwin,mingw,msys之类的桥接环境构建Win版FFmpeg的麻烦就不复存在了,而且新版FFmpeg源码(博主用的4.3)的configure也做好了对这种编译方式的支持,参考上面的链接,制定上toolchain=msvc等相关参数,剩下的事和nix系统上构建一样就可以顺利完成了,简单方便!

不过,今天要记录的并不是WSL下编译Win版FFmpeg的问题,而是编译时如何引入其它依赖,如openssl,xml2等以获取更多功能支持,尤其是在Win环境下,这些其它依赖库的位置很有可能是一个很随意的位置,而在WSL环境下处理这种依赖的头文件、库文件搜索路径时是有坑的…

Continue reading…

关于linux系系统的动态库全局函数重名问题

最近在使用某几个知名厂商的对象存储C SDK时,发现由于这些SDK的内部实现其实基本是一样的,进而导致了各个SDK的so中都或多或少有些被大家共同喜爱的全局函数(符号)名称,最后引发了在部分环境中出现了调用A厂商SDK的上传函数时崩溃在了B厂商SDK的同名全局函数中的问题,最开始感觉很是莫名其妙,后来查了资料发现,首先gcc编译时默认会将全局变量、函数等符号导出在都动态库中,而同时全局函数的加载又是抢占式的,这点通过如下简单试验便可验证:

Continue reading…

FFmpeg 4.3.1 hls http(s)配新版Nginx WebDAV 无法删除切片bug

在使用FFmpeg进行hls推流输出时,发现配合新版Nginx (1.21) + WebDav组件的http服务器时,即使指定了m3u8切片数量以及删除无用切片的参数:

hls_list_size 5 -hls_flags delete_segments -hls

也没有在服务端正确删除无用切片,查看Nginx日志,发现每次FFmpeg发起的DELETE文件请求,都会跟随一个这样的报错:

DELETE with body is unsupported!

导致虽然FFmpeg删除文件的http请求到了Nginx,但实际并没有删除掉磁盘上的ts切片文件,时间一长,磁盘空间耗尽,然后就尴尬了…

Continue reading…