软硬件使用
Windows的符号链接SymbolicLink（快捷方式）在网络共享访问时的跟随跳转问题
这个问题发现于这么一种操作，首先是用Powershell脚本进行快捷方式（SymbolicLink）创建：
New-Item -ItemType SymbolicLink -Path d:\share_folder\ -Name latest -Target d:\share_folder\v1000 -Force
此命令在d:\share_folder文件夹中创建名叫latest的快捷方式，并指向同级文件夹中的v1000目录，然后将share_folder开启网络共享，从另一台机器通过 \\xxx.xxx.xxx.xxx\share_folder方式访问这个快捷方式latest时，发现会提示：“无法遵循符号链接，因为其类型已禁用”的错误信息，百度一下，查到原因，参考：Windows 挂载磁盘错误 ‘无法遵循符号链接，因为其类型已禁用’ 解决方案 https://www.zywvvd.com/notes/system/windows/symlink-disabled/symlink-disabled/
原来Windows默认对符号链接的跟随跳转仅限本地，远程到本地（共享里的快捷方式指的本地路径），远程到远程（共享里的快捷方式指的是另外的共享路径）都是禁止的，于是参考上面的解决方案，fsutil behavior set SymlinkEvaluation R2L:1 打开远程到本地的遵循，结果再次访问时发现提示目标文件夹不存在！
Continue reading…一种FFmpeg提示“dts < pcr, TS is invalid“的解决方法
此问题出现在使用FFmpeg（动态库）输出UDP+TS流且开启muxrate输出CBR时，音频为aac编码，视频为264编码（libx264），视频部分使用vbv-bufsize及vbv-maxrate和nal-hrd=cbr编码CBR码流，可以看到程序刚跑起来FFmpeg的log回调就会疯狂报标题里提到的dts < pcr警告，这个警告的源码位置只有一个，就在libavformat\mpegtsenc.c的mpegts_write_pes这个函数里，但是读了下代码，也没看出来为什么会报这个警告，后来找到了这两篇参考：
FFMPEG转码音视频不同步情况总结 https://blog.csdn.net/liuchen1206/article/details/79461434
ffmpeg 奇葩问题2 https://blog.csdn.net/WaitForDone/article/details/78030095
其中第一篇参考文章里提到了编码速度问题，提到去掉B帧这个操作，而我的应用直接设置了zerolatency的tune相当于也是不带B帧的编码，第二篇文章提到了几个点，一开始直接放到了结果上，疯狂尝试各种qmin、qmax设置，结果都没有见效，而且实际发现我的视频码流并没有文章作者提到的编码出来的视频帧偏大的问题，其实用的就是默认的量化值，每帧大小也基本符合整体目标码率，最后百思不得其解时，试了下直接用ffmpeg命令行进行同样参数的编码操作，发现并没有报这个“dts < pcr”的警告，而且是跑了很长时间后也一次警告都没有，又结合了下第二篇参考文章中提到的delay设置，于是开始比较ffmpeg命令行程序的各种format、codec初始化操作参数，最后终于找到了问题：
Continue reading…
使用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…如何快速定位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…