我平时科学上网都是用shadowsocks的，不过有时候在别人电脑上操作或者其他移动设备时，不能总下载个客户端，我科学上网主要是查谷歌，谷歌学术，youtube。很早前谷歌可以直接通过ip直接访问，现在不行了，以前用过别人搭建的google mirror,不过大部分都被封了，好不容易找到个可以用的，没过多久又被封了，而且经常会弹出谷歌机器人检测，让你输入验证码，确定你不是机器人，很不方便。我自己有两个美国的vps，主要是搭建网站以及shadowsocks服务，还有很大的利用空间，趁着空闲时间也搭了个google mirror，用的是老网址：so.jianchihu.net。这个网址以前用的是谷歌自定义搜索api搭建的，界面是我大四时用bootstrap写的，那时简直是个搜索神器。不过后来api用不了了，我也没去更新维护。现在把这个网址用作我的google mirror，顺便这个mirror设置了账号访问（防止太多人用，被封锁），以及https访问，作为自己平时搜索使用，我测了下，手机，电脑网络访问谷歌以及谷歌学术都很快，自己动手丰衣足食，以后在哪有网络都可以快速访问谷歌了。

这几天网络上最火的莫过于勒索病毒了，造成了很大危害。其实在去年时候，勒索病毒就开始爆发了，那时在专业群里看到过一个学弟的电脑资料被加密，然后也没办法。那时勒索病毒传播没现在这么广泛，这次传播这么广泛是因为windows的一个漏洞。 看文章报道说，这次的勒索病毒来自美国网络武器库。其实现在很多病毒木马都是国家层面开发的。就说去年一个很吊的木马：黑暗幽灵木马，想了解黑暗幽灵木马的可以看下这篇文章《黑暗幽灵（DCM）木马详细分析》 。这种牛逼的木马不是一般黑客搞的，而且从木马的功能可以知道是伟大的gov想更好的了解我们。 自己也搞过多年的windows开发，以前也涉猎过外挂，反编译，所以自己对安全还是比较在意的。就我而言，我平时从以下方面进行防范： 1）系统保持最新，补丁也是； 2）下载软件都是直接从官网下载，然后通过我的vps代理下载，官网有提供md5的话下载后做md5校验，这么做是为了防止dns劫持，国内的dns实在信不过； 3）安装一款杀毒软件； 4）不清楚的东西先放到虚拟机跑一跑； 5）尽量不用各种盗版破解软件，需要的话还是放虚拟机里，目前很多软件都有免费或者社区版本，或者可替代产品，我自己电脑上现在一款破解的都没有（盗版还是有的，比如VMvare，软件是官网下的，序列号盗版的），这个链接是我电脑的一些装机软件：http://blog.jianchihu.net/my-pc-software.html，需要的可以参考下。

去年写过一篇文章，有关PCM的音量控制：http://blog.jianchihu.net/pcm-volume-control.html。那时阐述了一些概念，对一些细节没有详细描述。因为有人问到使用对数关系调节音量，故开此篇文章。 声学中的分贝 因为人耳的特性，我们对声音的大小感知呈对数关系。所以我们通常用分贝描述声音大小，分贝（decibel）是量度两个相同单位之数量比例的单位，主要用于度量声音强度，常用dB表示。声学中，声音的强度定义为声压。计算分贝值时采用20微帕斯卡为参考值（通常被认为是人类的最少听觉响应值，大约是3米以外飞行的蚊子声音）。这一参考值是人类对声音能够感知的阈值下限。声压是场量，因此使用声压计算分贝时使用下述版本的公式： 其中的pref是标准参考声压值20微帕。 分贝声音变化范围 在编程中，我们可以用以下公式计算两个声音之间的动态范围，单位为分贝： [crayon-69d8b68db12be922851961/] 其中 A1 和 A2 是两个声音的振幅，在程序中表示每个声音样本的大小。声音采样大小（也就是量化深度）为1bit时，动态范围为0，因为只可能有一个振幅。采样大小为8bit也就是一个字节时，最大振幅是最小振幅的 256 倍。因此，动态范围是 48 分贝，计算公式如下： dB = 20 * log(256) 48 分贝的动态范围大约是一个安静房间和一台运行着电动割草机之间的区别。如果将声音采样大小增加一倍到16bit，产生的动态范围则为 96 分贝，计算公式如下： dB = 20 * log(65536) 这非常接近听力最低阈值和产生痛感之间的区别，这个范围被认为非常适合还原音乐。 了解了分贝的相关概念我们通过图表说下为什么要用对数关系描述声音大小。 1）音量滑块与声音增幅大小线性变化。 上述左图中，音量滑块位置与声音振幅为线性增长关系，右图是我们人耳感受的音量大小与滑块位置关系。可知，在左侧移动相同距离的滑块，感知到的声音变化范围很大，在右侧接近声音最大值移动相同距离滑块，感知到的声音大小变化就很小了。 2）音量滑块与声音振幅大小对数关系变化。 左图中，音量滑块位置与声音振幅对数关系增长。右图中无论哪个位置，移动相同距离滑块，感知到的声音变化都是相同的。 需要说明的是滑块最小位置只是接近0，不能为0，因为对数函数y=logx中x>0。 windows系统中音量滑块控制的声音变化范围 在最新版的windows系统中，音量滑块控制的声音变化范围也是96分贝。如下表所示，是不同版本windows的音量范围以及默认音量值。 从表中我们可以看到默认值都是0分贝，根据分贝公式：dB = 20 * log(A1 / A2)，当A1，A2相等时，db为0。 程序实现 了解了分贝以及Windows中音量滑块是在哪个范围变化，我们的程序实现起来也很简单。 这里我们规定音量大小变化范围也是96分贝，每个声音采样大小为16位。对于分贝公式：dB = 20 * log(A1 / A2)，我们取参考声音振幅A2为原始声音振幅，A1为调节后的声音振幅大小。可知调节后的声音： [crayon-69d8b68db12cb229590539/] 看过一篇文章说理想的声音调节步长最好是2db，对于96db范围，我们按2db步长进行分割，可以分成48份，这样我们得到的声音变化为[-96db,-94db,-92db,...-4db.-2db,0db]，假设我们要调节一半音量大小，也就是-48db，由上述公式可知：调节后音量A1大小： [crayon-69d8b68db12d0071617968/] 程序伪代码如下，具体db大小与滑块位置对应关系的实现这里就不写出： [crayon-69d8b68db12d3241984510/] 参考 [1] Audio-Tapered Volume Controls.https://docs.microsoft.com/en-us/windows/win32/coreaudio/audio-tapered-volume-controls

前段时间，要写一个windows下的分布式软件，刚开始的方案是需要一个精确的时钟同步，误差必须控制在1毫秒内。也许很多人都知道有NTP以及PTP 时间同步协议。windows本身自带NTP协议的服务，通过注册表配置即可实现，但是误差无法满足要求，而且每次配置都要重启W32Time服务。也只有PTP这个精确时钟同步协议满足要求，后面想自己实现PTP协议，不过查了些资料，发现想的太简单了。 PTP协议的原理虽然简单，不过实现起来不简单，需要确定最佳主时钟，而且需要获取高精度的本地时钟（后面查到win8以上系统可以通过GetSystemTimePreciseAsFileTime获取<1us的高精度时钟）。后来发现有个著名的开源ptp协议实现：ptpd(Precision Time Protocol daemon)。不过该代码只针对linux系统，至于为什么没有在windows下的实现，大概有如下的原因: 1）windows不提供带时间戳的网络包，不像linux下socket有SO_TIMESTAMP选项，而且也不提供高精度时钟的内核api（win8以下系统）； 2）部分windwos系统存在时钟调整Bug，比如你调整的系统时间低于16个tick（系统的时基）单位，将会被忽略。 由于以上原因，后面也没去做windows上的ptp协议实现。

以前搞过播放器的Demuxer模块，业余时间重写了个简单音视频提取工具。可以从视频编码格式为h264+音频编码格式为aac的mp4以及flv封装文件中提取出音视频。写这个工具其实是为了方便自己听歌。因为现在很多音乐都开始注重版权，很多歌下载都要钱，比如网易云音乐，我很喜欢听泰勒的歌曲，以前花钱买过，后面换了部设备，重新下载又得要花钱。不过大部分要花钱的歌曲都有MV可以免费下载，网易云的MV都是mp4格式，现在的mp4基本都是h264+aac，所以我就想从mv中把音频提取出来，这样就可以随便听了。说完这些介绍下这个工具的使用。 工具下载链接在文章末尾，只有几十K，没有用到大多数播放器都用到的ffmpeg，ffmpeg都几十兆了。这个工具是个简单的命令行工具。界面如下： 1)第一步按提示输入提取类型，输入1只提取音频文件，输入2只提取视频文件，输入3提取音视频; 2)第二步输入视频文件名（如果视频文件与程序不在一个目录还要输入路径），最简单的方法是直接拖放视频文件到程序。 3)回车等待解析。提取结束会在程序目录生成对应文件。音频为audio.aac，视频为video.h264。 下载地址：http://jchblog.u.qiniudn.com/201703/ExtratTool.zip 由于之前写的这个软件找不到了，地址也失效了，故提供一个ffmpeg版本的，下载解压后，运行bat文件，输入要操作mp4文件名即可。 ffmpeg版本下载地址：https://gitee.com/jianchihu/jchcdn/raw/master/download/mp4toaac.zip

前段时间购入了戴尔U2515 2K显示器，分辨率为2560x1440,不过发现在Ubuntu中找不到2560x1440分辨率设置，最大的只有2560x1600分辨率。查了下，通过xrandr命令可解决。 1）通过xrandr即可查看当前显示器所有分辨率，其中Virtual1是是当前显示器名称： [crayon-69d8b68db3636193979957/] 2）接着敲入： [crayon-69d8b68db3642765515153/] 添加我们的2K分辨率。 3）在显示器分辨率列表中添加上面得到的分辨率设置： [crayon-69d8b68db3646928874741/] 4）添加该模式，其中Virtual1是第一步中得到的显示器名称，由于我是跑在虚拟机，所以为Virtual1： [crayon-69d8b68db3649443823503/] 最后就可以在分辨率设置中找到该分辨率了。

简介 Media SDK 是一个软件开发库，包含解码、视频处理和编码三大模块。利用 Intel 平台的硬件加速能力， Media SDK 为低端用户提供了优秀的高清视频质量，极大的降低了播放高清视频的硬件门槛。此外，强大的视频 APIs 也减轻了程序开发者的工作负担，使他们能够集中精力去处理程序的逻辑模块，而不必关心于 Media SDK 内部的复杂编解码逻辑及其如何提高效率。 本篇文章将着重讲述如何利用 Media SDK 提高程序的效率，面对的读者主要是视音频程序开发人员。 本文以下内容为： - 初始化设置之优化 - 内存选择之优化 - 多线程之优化 - 异步方式之优化 初始化设置之优化 在讨论优化之前，首先要了解一下 Media SDK 是如何初始化编解码器的。 1. 创建和初始化一个编解码 Session。Media SDK 提供了 mfxStatus MFXInit(mfxIMPL impl,mfxVersion *ver, mfxSession *session)函数来完成这个创建和初始化工作。 2. 使 用 已 创 建 的 Session 来 创 建 它 的 解 码 器 。 Media SDK 提 供 了 mfxStatus MFXVideoDECODE_Init(mfxSession session, mfxVideoParam *par)来完成解码器的创建和初始化工作。 3. 使 用 已 创 建 的 Session 来 创 建 它 的 编 码 器 。 Media SDK 提 供 了 mfxStatus MFXVideoENCODE_Init(mfxSession session, mfxVideoParam *par)来完成编码器的创建和初始化工作。 在创建和初始化编解码 Session 时，我们需要制定编解码的实现方式：硬件方式还是软件方式。最简单的方法是强制使用硬件方式。这会带来一个问题，在非 Intel 显卡支持的平台，应用程序将无法正常工作。当然，如果强制使用软件方式，虽然应用程序能够工作于其他平台，但是在 Intel 显卡平台，硬件加速特性将荡然无存！虽然应用程序可以外加代码检测平台硬件来决定如何选择，但是程序的复杂度和效率将受到影响。Media SDK 内部提供了自动选择功能，它会根据当前运行系统来选择何种方式。这样就能够兼顾不同平台及其性能。 在 MFXInit 函数中，枚举类型 mfxIMPL 定义 AUTO 功能： [crayon-69d8b68db3f8a284711793/] 相应的简单实用方式如下： [crayon-69d8b68db3f94487215740/] 通过 MFX_IMPL_AUTO 的设置，问题迎刃而解。 那么如何获知当前的编解码实用方法呢？Media SDK 已经考虑到了这种需求，它提供了mfxStatus MFXQueryIMPL(mfxSession session, mfxIMPL *impl)来查询当前采用的方法。 此外，在优化编码器初始化时，程序必须注意 mfxInfoMFX 结构中 TargetUsage 变量的选择，它的定义如下： [crayon-69d8b68db3f98711048234/] TargetUsage 值的选择决定了编码的性能和图像质量，它的值从 0~7，值越高效率越好，但图像质量会有所下降。最佳值应该和用户选择需求挂钩，原则上是略比最小用户需求高 1 级。 本节小结： 1. 初始化 Session 时，要使用 MFX_IMPL_AUTO。它有利于跨越硬件平台，并提高编解码效率。 2. TargetUsage 的选择应该和用户需求相结合。为了提高性能，选择略高于用户最小需求的值为佳。 内存选择之优化 Media SDK 使用内存缓冲来输入/输出视频数据，内存缓冲的不同种类将会直接影响编解码的效率。内存缓冲可以是一块在系统内存中的连续块（通过 malloc 或者 new 来分配），也可以是显卡内存的连续块（通过 Microsoft Direct3D9 Surface 函数来分配）。那么内存缓冲的 种类由谁来决定呢？本节就是以此为基础，讨论在不同情况下程序如何选择内存缓冲种类的问题。 在讨论内存缓冲对编解码影响之前，先讨论下面三种情况下的内存数据传送问题。 - 系统内存间数据如何传送？ 对于程序员而言，这个是最为简单的日常编程事项。一般的使用方式是 memcpy，在一些数据较大情况下（超过 L3 的 cache 尺寸时候，用 movntqa 等指令）。不管何种方式，都是CPU-BASED 的代码，在 SIMD 下效率很高。 - 显存间数据是如何传送的？ 它类似于系统内存之间的数据传送，并且显存的带宽和速率都很高，传送速度更快。 - 显存和系统内存间数据是如何传送的？ 通过 DMA 方式传送内存数据，速度依赖于 DMA 的带宽和速率（普通 DMA 的传送速率在33.3MB/s，而 Ultra DMA 最高也不过 100MB/s）。相比与上述两种情况，它的传送速度明显慢。 从上面的三种情况可以看出，程序一定要尽量避免出现系统内存和显存之间的数据传送，那么 Media SDK 在什么配置下会出现此类尴尬状态呢？ 初始化设置之优化小节中，程序通过 MFX_IMPL_AUTO 参数根据当前平台来自动选择硬件或软件编解码，并能通过 mfxStatus MFXQueryIMPL(mfxSession session, mfxIMPL *impl)函数来获取当前平台的编解码方式，在此将获取的编码方式分别讨论。 a）使用硬件编解码方式 硬件编解码方式主要是通过显卡的硬件加速达到高效编解码的作用，也就是说它的核心是显卡。如果我们使用系统内存为其提供缓存，会出现什么情况呢？显然，在数据输出/输出时，程序必将会有显存和系统内存之间的数据传送作用，效能将受到严重影响。在此情况下，程序的最好选择就是显存，否则必将受到性能惩罚！ b）使用软件编解码方式 很显然，软件编解码的核心是 CPU。如果我们使用显存作为其缓冲，那么必将导致显存和系统内存之间的数据交互，也就会导致速度低下的程序出现，故此，系统内存是它的不二选择！ 本节小结： Media SDK 中内存类型的选择分两步走： 1. 使用 MFXQueryIMPL 函数来查询当前的编解码方式。 2. 根据编解码方式（MFX_IMPL_SOFTWARE 为软件；MFX_IMPL_HARDWARE 为硬件）来决定内存选用类型。为了便于日后方便查询，笔者建立了一个小表格，如表 1 所示，以供参考。 此外，笔者对 Media SDK 的两种不同内存类型在解码器下做了一个简单的比较。在软件解码方式下，显存选取要比内存选取慢了近 1 倍，这个是相当可观的数字！切忌，正确选取内存是高效程序的基本点！ 多线程之优化 初始化设置之优化小节和内存选择之优化小节中，已经对 Media SDK 的两个重要配置部分进行了分析和总结。本节，我们将着重讨论如何使用多线程技术提高视频 Converter 的效能（一种视频的常用应用）。 在运用 Media SDK 进行格式转换时，一般要涉及三大模块，他们是 Decoder，VPP 和 Encoder，数据输入输出如图 1 所示。 从图 1 可以看出，每经过一个模块，都要对数据进行同步操作。在此期间，其他两个模块是处于空闲状态，是一个典型的串行处理过程。对于英特尔的多核技术，它的多核利用率是最低的，相应的效率也较差。 那么如何对现有流程进行多线程化呢？ 本节提供了一种最简单的方法，即对每个模块线程化。请参考图 2 所示。 图 2 将 Decoder，VPP 和 Encoder 三个模块分别线程化，在彼此之间以队列（queue）为数据交换。 简单的工作模式如下： - 若队列为空，后级模块等待数据。 -…

买的主机停了将近10天，以前一些文章排名都没了。垃圾主机商，被攻击了，要快10天才能搞好，又不给取出数据，恒创主机，垃圾。