欢迎留言、转载请注明出处
在使用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…此问题来源于经过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的账号用在Windows 7系统上时一直没什么问题，直到最先有一天突然提示账号登录失败，然后全套Office程序就都无法使用了，查看了下是账号无法正常登录导致的，一直提示“很抱歉，遇到一些临时服务器问题”，如下：
百度了很多方法，什么清注册表的，改DNS的，重新安装的，甚至是使用魔法的，统统不管用，最后找到了这篇简书上的参考：https://www.jianshu.com/p/9a37cca37374，才意识到原来是Win7系统上的https兼容问题（也有可能不是Win7而是这个365登录网站的问题吧，反正在Win10上没遇到过这种情况），于是…
Continue reading…正常来说，cmake都是自己安装的，所以装在哪自己心里还是知道的。但是，如果cmake不是自己装的，或者是其它程序里集成的呢？比如CLion就bundle了很新版本的cmake，这时鸡贼的我在装了CLion的Mac系统上就想直接现成的cmake来build开源项目…
然后，尴尬的事就来了：我并不知道CLion自带的cmake在什么位置，找了下Library，CLion的app包内等常见位置，都没有发现自带cmake的踪影，于是搜索引擎调查了下，发现了这么个技巧：
Continue reading…格式化字符串是个写C/C++代码是很常见的东西，例如下面这段用了printf的简单代码：
#include <string>
int main()
{
std::string test = "hello world!";
printf("%s", test.c_str());
return 0;
}
虽然看起来有点怪，混用了C++的string和C的printf输出，其实换成char *也是可以的，不过，这并不重要，重要的是我有时会偷懒把上面这段代码写成这样：
#include <string>
int main()
{
std::string test = "hello world!";
printf(test.c_str());
return 0;
}
这样写，看起来似乎输出没有问题，两份代码的结果都是输出”hello world!”，并没有什么区别，那标题说的坑到底在哪呢？考虑这种情况，我们的test字符串里放的不再是简单的 hello world! 了，而是比如转义过的URL串，如“http://www.baidu.com/测试”会被转义成“http%3A%2F%2Fwww.baidu.com%2F%E6%B5%8B%E8%AF%95”，此时如果再用偷懒的写法，直接printf这个字符串，显而易见的就会出问题了！
Continue reading…最近研究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…原文来自：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 端口，无奈这次一直连续好几天这个连接一直存在导致我一直无法使用这个端口。
解决过程
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 掉。
这是一个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版本中已修改这个问题，加入了独立控制远端生成路径的选项。
13年买的港版13寸MBA A1466一直用到21年现在，好在当时略有远见，在标配4G内存的时代选择了定制的8G内存版本，才算勉强支撑了这么多年，但当时的硬盘还是选的128G版本，用到现在已经捉襟见肘，而且随着Mac OSX系统不断更新，感觉系统、软件使用起来速度越来越慢，而且还容易发生卡顿。
其实20年初时考虑过换个10代酷睿的新版Mac Book，但选择困难症纠结配置一直纠结到了年底，结果苹果发布了ARM版的Mac CPU M1，一时间好评不断，号称各种完爆Intel版的Mac，好在当时没入10代Mac Book，但参考当年入初代锐龙时的被坑经验，决定还是先观望下M1，毕竟这个变化不小，很多软件都需要对ARM版Mac系统做出适配。
不过此时我的老MBA已经基本硬盘满到快无法使用了，看了下某宝上256G、512G的MBA原装硬盘，售价比普通m.2硬盘基本上要贵一倍，而且都是拆机二手盘，也不知道会不会有问题。幸运的是，在万能的某宝上发现了这个神器：
Continue reading…