软硬件使用
如何快速定位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只有这么几个：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 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 连接，类似于这样：
1 | ESTAB 0 0 192.168.103.169:12345 192.168.103.12:10261 |
当然这个问题也不是最近才遇到，之前也遇到过，不过之前都是很快这个连接就自动消失，我就可以欢快
的使用我自己喜欢的12345 端口，无奈这次一直连续好几天这个连接一直存在导致我一直无法使用这个端口。
解决过程
1. google 找答案
google 果然告诉我答案，有个叫tcpkill 的工具（可以自行搜索一下），看到之后立即将源码下下来
编译了一把，按照提示将几个确实的包安装后编译成功，然后按照tcpkill 的帮助文档进行操作
1 2 | 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 测试了下，发现如下情况
1 | 对于nc 已经建立的连接运行tcpkill 后无法立即干掉，只有在这个连接上有数据传输的时候才会把发送rst 包将连接reset 掉。 |
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…VS Linux项目编译g++: fatal error: cannot specify -o with -c, -S or -E with multiple files问题
使用Visual Studio (2019)进行Linux项目开发时遇到项目编译时提示如标题所写的：
g++: fatal error: cannot specify -o with -c, -S or -E with multiple files
仔细检查了项目代码，并没有发现问题，也尝试了移除最近改动过的代码、增加过的源码文件，均不能正常编译…（同时，也确认过新建的项目可以正常编译，证明开发环境本身还是没问题的）
Continue reading…Android Studio带C++项目提示More than one file was found with OS independent path问题修正
近日，在将一个旧Android Studio项目(带native c/c++)升级了新版本gradle 4.0.1后(Android Studio版本4.0.1)，发现重新clean再构建时，提示：
More than one file was found with OS independent path ‘lib/armeabi-v7a/xxx.so’. If you are using jniLibs and CMake IMPORTED targets, see https://developer.android.com/studio/preview/features#automatic_packaging_of_prebuilt_dependencies_used_by_cmake
虽然一开始也是一脸茫然，但既然提示信息里都提供了连接了，那就看一下吧，顺带一提，给出的链接我写这篇博文的时候并不是最终信息位置，最终链接在这里：https://developer.android.com/studio/releases/gradle-plugin#cmake-imported-targets ，仔细阅读了一下，发现实际上是从gradle 4.0开始就对jni的预编译依赖引用方式做出了修改：
Continue reading…
JetBrains IntelliJ IDEA从2018更新到2019后无法卸载的问题
Uninstall hasn’t detected folder of XXX installation…
博主的IDEA是从2018一路升上来，最近出了2020，并且还用上了JB的Toolbox，看着Manually installed有点强迫症发作，于是尝试卸载掉后用Toolbox重新安装，结果就发现了上面写到的错误提示这个坑！
参考 https://youtrack.jetbrains.com/issue/PY-35047 可行的解决方法如下：
Continue reading…