上次给退役的一加1刷了lineage-16.0后，本来一直使用的挺好，当个备用怀旧游戏机还挺流畅的，最近拿来做一些安卓调试时突然发现logcat没反应了，AndroidStudio里一片空白，adb设备状态一切正常，尝试adb logcat以及adb shell后logcat，发现会提示“logcat read failure”这个错误，查了半天，尝试了个各种手段，root su进到/system/bin下看logd完好无埙，又看有人说是selinux的问题，ls -Z检查了logd的权限：u:object_r:logd_exec:s0，发现也没问题。然后又以为是装Magisk装的把系统搞坏了，于是有恢复出厂了一次，结果发现错误依旧！最后突然想到之前的系统镜像貌似是不知道哪个瞎八网站上下载的，本来里面就内置了一堆乱起八糟的app，会不会是不靠谱的rom作者把重要功能给改坏了？于是废了半天劲找了个lineage官方的旧版本系统镜像：https://lineageosroms.com/bacon/#installing-lineageos-from-recovery 然后又重刷了一次机，果然，纯原版的镜像是没有问题的，logcat恢复正常了。
AndroidStudio制作Unity 2020.3插件的新坑
在Unity还是4.x 5.x的时代，为了做一些安卓原生功能，如获取电量，wifi信号强度等功能，或者是为了接入某些原生SDK，经常需要制作Unity的Android原生插件，当时基本就是基于Unity的安卓classes.jar制作plugin.jar，然后自定义AndroidManifest.xml，一起放到Unity项目的Assets/Plugins/Android下，然后Build安卓apk即可，简单粗暴。最近又有了做安卓插件的需求，这次换上了2020版的Unity，本以为还是当年熟悉的操作，没成想来了个大人，时代变了，踩了不少新坑：
首先，当年好像还是用Eclipse做Android开发，现在早就是Android Studio的天下了，我用的版本是：Chipmunk 2021.2.1 Patch 2，按着网上找到的教程（对，很久没用了，都快忘了怎么建项目了），创建了Android Library项目，又从Unity的“D:\Program Files\Unity\Hub\Editor\2020.3.30f1c1\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Release\Classes”位置，拿到了熟悉的classes.jar，注意这里有一些变量，比如mono，现在还有了il2cpp的选择，Release对应还有Debug，根据实际情况进行选择吧。然后，随便写了几个简单的静态方法，Unity C#里调用了下，nice，没有问题，于是开始进行下一步，自定义入口activity，然后就开始踩坑了：
Continue reading…OpenSSL EVP API实现MD5加密C++代码
网上找到的大部分都是旧API，新版OpenSSL推荐使用EVP系列接口，在此记录下EVP方式的MD5哈希实现代码：
#include "openssl/conf.h"
#include "openssl/evp.h"
#include "openssl/err.h"
#include "openssl/engine.h"
void handle_errors()
{
ERR_print_errors_fp(stderr);
abort();
}
std::string md5_str(const std::string & str)
{
const auto * md = EVP_get_digestbyname("MD5");
if (nullptr == md)
{
std::cerr << "Failed to EVP_get_digestbyname MD5!" << std::endl;
return "";
}
unsigned char buf[EVP_MAX_MD_SIZE] = {};
unsigned int olen = EVP_MAX_MD_SIZE;
EVP_MD_CTX * ctx = EVP_MD_CTX_new();
if (nullptr == ctx)
{
std::cerr << "Failed to EVP_MD_CTX_new!" << std::endl;
return "";
}
if (1 != EVP_DigestInit(ctx, md))
{
handle_errors();
return "";
}
if (1 != EVP_DigestUpdate(ctx, str.data(), str.length()))
{
handle_errors();
return "";
}
if (1 != EVP_DigestFinal(ctx, buf, &olen))
{
handle_errors();
return "";
}
EVP_MD_CTX_free(ctx);
return { reinterpret_cast<char*>(buf), olen };
}
int main()
{
OpenSSL_add_all_digests();
const std::string plain = "test1234";
const std::string hash = md5_str(plain);
std::cout << "plain: " << plain << " md5 hash: " << hash << std::endl;
return EXIT_SUCCESS;
}
后面有时间再增加AES等的EVP实现代码
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…10年后G1左键微动再次阵亡，更换存货凯华黑
10年前给大概8年前买的G1换了日产欧姆龙微动：给用了快8年的罗技G1换了个新的微动开关 https://blog.k-res.net/archives/996.html，时隔10年之后的今日发现左键再次开始出现连击、拖动时断断续续的情况，差点把重要文件误删了，赶紧拆开再次急救：
给用了快8年的罗技G1换了个新的微动开关
一种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…关于linux系系统的动态库全局函数重名问题
最近在使用某几个知名厂商的对象存储C SDK时，发现由于这些SDK的内部实现其实基本是一样的，进而导致了各个SDK的so中都或多或少有些被大家共同喜爱的全局函数（符号）名称，最后引发了在部分环境中出现了调用A厂商SDK的上传函数时崩溃在了B厂商SDK的同名全局函数中的问题，最开始感觉很是莫名其妙，后来查了资料发现，首先gcc编译时默认会将全局变量、函数等符号导出在都动态库中，而同时全局函数的加载又是抢占式的，这点通过如下简单试验便可验证：
Continue reading…