软硬件使用

使用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…

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…

CentOS 8运行其它环境编译的curl报77错误解决方法

此问题来源于经过Github Actions编译出来的curl执行程序,由于actions默认的构建环境都是Ubuntu的,编译构建出来的新版本curl放到CentOS 8上运行时,会提示类似如下内容的错误(仅限需要用到ssl证书的协议,如https):

curl: (77) error setting certificate verify locations:
  CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
...
curl: (77) Error reading ca cert file /etc/ssl/certs/ca-certificates.crt - mbedTLS: (-0x3E00) PK - Read/write of file failed

按照网上搜到的说法,重新yum安装ca-certificates之类的都不起作用,查看/etc/ssl/certs目录,发现有如下内容:

Continue reading…

Office 365账户在Win7系统无法登录的解决办法

问题情况如题所述,之前买过Office 365的账号用在Windows 7系统上时一直没什么问题,直到最先有一天突然提示账号登录失败,然后全套Office程序就都无法使用了,查看了下是账号无法正常登录导致的,一直提示“很抱歉,遇到一些临时服务器问题”,如下:

百度了很多方法,什么清注册表的,改DNS的,重新安装的,甚至是使用魔法的,统统不管用,最后找到了这篇简书上的参考:https://www.jianshu.com/p/9a37cca37374,才意识到原来是Win7系统上的https兼容问题(也有可能不是Win7而是这个365登录网站的问题吧,反正在Win10上没遇到过这种情况),于是…

Continue reading…

Debian 10 buster扩容swap分区后启动缓慢修复

上下文是这样,建了个虚拟机,然后一路默认安装了debian buster,装好后用了一段时间,感觉swap有点小(虽然也没实际用满,只是心理作用),看了下默认安装后的swap是直接用了swap partition,以前这种情况一般是新建个够大的swap file,然后重新挂上,但是这次呢,因为是用了交换分区,而我又不想在主分区上创建交换文件,于是就想尝试下改变虚拟机磁盘大小,重新调整分区的方法来加大swap!

Continue reading…

如何快速定位cmake执行程序位置

正常来说,cmake都是自己安装的,所以装在哪自己心里还是知道的。但是,如果cmake不是自己装的,或者是其它程序里集成的呢?比如CLion就bundle了很新版本的cmake,这时鸡贼的我在装了CLion的Mac系统上就想直接现成的cmake来build开源项目…

然后,尴尬的事就来了:我并不知道CLion自带的cmake在什么位置,找了下Library,CLion的app包内等常见位置,都没有发现自带cmake的踪影,于是搜索引擎调查了下,发现了这么个技巧:

Continue reading…

关于x265的high-tier启用问题

最近研究x265编码时如何启用high profile(后来才了解到对x265来说应该是high tier),之前接触x264的时候了解到的是直接在编码指定profile时就会有main和high的profile之分,如main、high、high10、high422等,但到了x265时却发现可指定的profile只有这么几个:

static const char * const x265_profile_names[] = {
    /* HEVC v1 */
    "main", "main10", "mainstillpicture", /* alias */ "msp",

    /* HEVC v2 (Range Extensions) */
    "main-intra", "main10-intra",
    "main444-8",  "main444-intra", "main444-stillpicture",

    "main422-10", "main422-10-intra",
    "main444-10", "main444-10-intra",

    "main12",     "main12-intra",
    "main422-12", "main422-12-intra",
    "main444-12", "main444-12-intra",

    "main444-16-intra", "main444-16-stillpicture", /* Not Supported! */
    0
};

并没有像x264的各种high,后经研究发现x265的high profile是通过另一个参数:“high-tier”来控制的,于是用ffmpeg命令行作了如下测试:

Continue reading…

[转]如何干掉一条tcp 连接(活跃/非活跃)

原文来自:https://developer.aliyun.com/article/59308,之前遇到了同样的问题,在实现RTMP服务器时由于没有设置SO_RCVTIMEO,导致在RTMP握手消息交换阶段无限等待握手数据包,出现了非活跃状态的tcp连接占用情况,试过原版tcpkill,由于非活跃状态,无法强行断开连接,所幸找到了这个修改版,试了下成功踢掉了捣乱连接,特此分享,感谢原作者!

背景

最近在测试环境部署服务的时候老是会有端口被占用情况用netstat/ss 查看后发现端口一直被占用
同另外一个ip 建立了tcp 连接,类似于这样:

ESTAB      0      0      192.168.103.169:12345              192.168.103.12:10261 

当然这个问题也不是最近才遇到,之前也遇到过,不过之前都是很快这个连接就自动消失,我就可以欢快
的使用我自己喜欢的12345 端口,无奈这次一直连续好几天这个连接一直存在导致我一直无法使用这个端口。

解决过程

1. google 找答案

google 果然告诉我答案,有个叫tcpkill 的工具(可以自行搜索一下),看到之后立即将源码下下来
编译了一把,按照提示将几个确实的包安装后编译成功,然后按照tcpkill 的帮助文档进行操作

tcpkill -i eth0 src port 12345 and dst port 10261 and src host 192.168.103.169 dst host 192.168.103.12
# 按照libpcap 规则描述出一个tcp 连接

执行上述命令后发现tcpkill 感觉像是处于hang 住状态,运行了半天也没见把这个连接干掉,为什么这个连接没干掉? 于是用 nc 测试了下,发现如下情况

对于nc 已经建立的连接运行tcpkill 后无法立即干掉,只有在这个连接上有数据传输的时候才会把发送rst 包将连接reset 掉。
Continue reading…

VS2019 16.9版引入的linux项目远程输出路径bug

这是一个Visual Studio 2019(博主发现时的版本是Community 16.9.4)的bug,之前在16.8版本的时候是没有问题的,并且影响的是VS原生的远程linux项目,Make CMake项目不受影响,发现这个问题时着实郁闷了一段时间,总结一句话就是这个选项:

红框内的两个dir,在16.9以前可以同时作用于本地windows项目路径,及同步到远端linux的项目路径,而到了16.9的时候无论怎么修改这两个路径都只有windows侧的路径会响应变化,而sync到linux的路径还会使用默认的这个路径(应该是bug或其它原因,比如,写死了?!),查了半天也没找到解决方法,对简单项目的话只好修改项目设置,都是用默认dir,或者想办法退回16.8版本,其中搜索过程中发现了有人提到这个问题:https://developercommunity.visualstudio.com/t/VS-For-Linux:-Output-files-on-remote-mac/1357691,其中提到已经修改等待发布,在此记录这个影响挺大的问题,后续有更新会同步过来…

UPDATE1: 16.10版本中已修改这个问题,加入了独立控制远端生成路径的选项。

解决UE4在中文环境下Compile错误提示乱码问题

UE4 4.26.0,VS 2019 Community,中文Win10 20H2组合在一起出现了今天要讲的问题,Compile出错时的log信息中中文乱码

试过切换VS语言为英文,UE4语言为中文,均不起作用,想起之前的这个问题:Android Studio的Build Output中文输出乱码(菱形问号)问题的解决方法,以为是不是UE4也有类似的设置,查找半天无果,最后发现其实新版Win10(最早哪个版本加上的我也不清楚)里面的区域语言设置中有个UTF-8的选项,虽然到目前用的20H2时仍声称为beta状态,但确实可以解决这个问题:

Continue reading…