QSV编码HEVC视频参数测试

Leave a Comment

ffmpeg -i in.mp4 -c:v hevc_qsv -load_plugin hevc_hw -q:v 23 out.mp4
psnr average:43.003743 min:38.982468 max:49.839129

ffmpeg -i in.mp4 -c:v hevc_qsv -load_plugin hevc_hw -q:v 23 -preset slower out.mp4
psnr average:43.023055 min:39.008167 max:49.839129

ffmpeg -i in.mp4 -c:v hevc_qsv -load_plugin hevc_hw -q:v 23 -preset slower -g 300 out.mp4
psnr average:43.026342 min:38.824927 max:50.158498

ffmpeg -i in.mp4 -c:v hevc_qsv -load_plugin hevc_hw -global_quality 23 out.mp4
psnr average:43.278585 min:39.726054 max:47.547273

ffmpeg -i in.mp4 -c:v hevc_qsv -load_plugin hevc_hw -global_quality 23 -preset slower out.mp4
psnr average:43.252435 min:39.739919 max:47.547273

ffmpeg -i in.mp4 -c:v hevc_qsv -load_plugin hevc_hw -global_quality 23 -preset slower -g 300 out.mp4
psnr average:43.218860 min:39.407929 max:47.984913

可见使用-global_quality参数进行质量控制能获得更高的信噪比，但是不知为何-q 23 -preset slower时对比默认参数获得了更低的平均信噪比，intel的算法不太靠谱啊。

另，使用-g 300进行关键帧控制带来的效果也很迷，个人倾向于不进行设定保持默认参数。

FFmpeg中的几个新视频降噪滤镜

Leave a Comment

不久前 FFmpeg 发布了 4.1 正式版，我看到这个版本新增了一个名为 fftdnoiz 的视频降噪滤镜。其实，从我几年前测试 FFmpeg 内置的几款视频降噪滤镜到现在，已经有很多款新降噪滤镜被加入到主分支了。

  • nlmeans
  • bm3d
  • fftdnoiz

嗯，首先要说的是这几款新插件的处理速度都比较慢，最慢的 nlmeans 在普通家用机上可能只得 1 帧左右的处理速度。据我所知 nlmeans 算法是有显卡加速版本的，不知道为什么 FFmpeg 不一同引入显卡加速版本。

降噪效果来看，这几款滤镜在默认参数下效果都很普通，可能需要比较精细的参数调整才能取得较好的效果。我相信 FFmpeg 不会把落后的代码合并进主分支，尽管如此，日常使用仍然推荐使用简单快速的 hqdn3d 滤镜。

使用 libmfx 编码器编码 HEVC 视频

Leave a Comment

libmfx 是 intel 的硬件加速编码器库，在硬件编码器中效果出类拔萃，当面临对画质压缩比要求不太高的场景时可以尝试使用 libmfx 中的 hevc_qsv 编码器替代 libx265 或者 libvpx-vp9，后两者虽然画质压缩比上限高得多但是编码速度实在感人。

我们可以使用经典的 ffmpeg 工具调用 hevc_qsv 编码器，一个简单的示例命令如下。

ffmpeg -i input.mp4 -an -c:v hevc_qsv -load_plugin hevc_hw -b:v 0 -q:v 23 -look_ahead 1 outfile.mp4

实际使用下来发现了很多问题，比如必须显式载入硬件加速插件以及 preset 没有实际效果等等，看上去是 ffmpeg 的实现问题，期待以后能改进。

在 8 代酷睿核显上这样一条指令通常能以 4-8x 的速度处理 720p 的视频而保持 40 左右的 psnr 参数，输出文件体积与同质量参数的 libx265:preset=slow 输出相差在 10% 以内，配合ffmpeg 的内置滤镜完全可以完成一些要求不高的视频转存任务，值得期待以后的发展。

关于并发模型

Leave a Comment

线程模型可能是最经典的线程模型。在多核cpu诞生之前，线程模型就作为一种并发解决方案被提出来并且大规模使用了。

为什么是线程模型？第一是线程模型符合人类线性思维直觉，心智负担小。第二是线程是对进程的历史延续，实现难度低。第三是线程的overhead相对较小，当时的硬件条件不支持更复杂的并发模型。

但是随着多核cpu的发展，并发需求越来越大，人们发现简单粗暴的线程模型存在很多弊病，一些人试图通过软件工程的方式去回避线程模型的问题，一些人则试图扩展线程模型，另一些人则在考虑新的并发模型。

事件驱动，回调属于第一者，netty是其中的代表。轻线程，包括golang的goroutine和各种stackful的协程实现属于第二者。

actor模型则属于第三者，当然，因为os的并发模型是线程的，现在所谓的新的并发模型也只能是base on thread的。

GraalVM支持解释执行LLVM bitcode

Leave a Comment

graalvm这个东西从2016年关注，最初是因为其纯java实现的jit编译器而吸引注意，本以为是openjdk的一个项目，没想到如今正式发布后却是甲骨文的一个基于openjdk的产品。

相比起之前技术预览阶段，正式发布版本最大的不同是支持解释执行LLVM bitcode，这是否意味着jni接口可以下岗了呢？

使用bandizip代替7zip

Leave a Comment

多年来一直使用7zip作为日常的压缩/解压软件，但是其实7zip有一个长期存在的拖拽解压bug让人很不舒服，在很多三方窗口里拖拽解压是无效的，而最近发现的bandizip则无这个问题，且兼界面十分漂亮。

https://www.bandisoft.com/bandizip/cn/

该软件免费但不自由，支持创建zip、7z档案，解压包括rar的主流档案格式。一些细节方面的设置也十分讨喜，比如在解压tar格式档案时默认使用utf8编码解析路径。

吐槽docker的overlay网络架构

Leave a Comment

很蛋疼，我在上一篇博文里写到docker的overlay网络解决了以前的一些问题，但是实际上看起来它并没有解决任何问题。最值得吐槽的一点就是，端口的publish仍然是由dockerd这个用户空间daemon监听然后转发到容器内。

还是跟几年前一样在用户空间做端口转发，性能是真的差，跟这个的overhead相比什么用udp封装以太帧这种奇葩做法简直是小儿科（vxlan，带来约50%吞吐性能下降），而最严重的缺陷就是容器里不可能得到原始连接的套接字。#25526

dockerd再通过一个叫ingress网络接口把连接代理进容器的overlay网络，这个ingress网络是个特殊的用做路由的overlay网络，swarm节点和service在里面都占据ip。最大的槽点其实就在ingress里用了IPVS做loadbalancer（可以用docker service inspect看到一个service在ingress层和overlay层的virtual-ip分别是什么），那么为什么不直接在宿主机里用IPVS在内核空间做端口转发，非要在用户空间里倒腾几遍？

所以我当初一直吐槽说docker只适合拿来跑http服务器。

完全可以使用传统网桥和虚拟交换机连接容器与宿主机物理网络（或者也可以保留overlay，毕竟overlay保证了物理网络与容器网络的严格隔离），容器里面绑定每一个swarm节点对应的网桥或者overlay虚拟网卡ip作为virtaul-ip，用iproute-rule分别设置路由表做multi-gateway，然后宿主机上用IPVS直接做DNAT转发，这样实现出来行为与现在的overlay+ingress完全一样，可以做到连接任意一个swarm节点等于连接到同一个service。

——没有傻逼的用户空间端口转发，没有傻逼的获取不到原始连接套接字。

docker一直被称为devops里程碑的工具，但是从这点看出来docker的核心developer可能一点网络相关的op经验都没有。

(client_conn -> host-public-eth-> dockerd(userspace-proxy) -> ingress_network -> overlay-network(eth frame over udp) -> container)

重新关注docker容器技术

Leave a Comment

早在2013年的时候我就曾关注过docker这个新事物。那个时候容器其实已经并不是什么新鲜概念了，在docker前头linux世界里就有了lxc和openvz，目光放在整个*nix世界的话容器的历史还要更长。

与lxc基本只用于实验不同，openvz在当时已经是大规模商用的稳定技术，抛开它本身就是一个商用平台的组成部分不说，在当时世界上大部分的廉洁VPS都跑在openvz设施上。我个人对openvz的熟悉程度也比较高，包括一开始的mc平台和之后的梦世界的基础设施都是基于openvz的集群上。

2013年的docker已经是可用的，但是仍然存在许多的致命缺点，就mc来说，aufs文件系统的性能简直差到无法忍受，文件持久化也是个问题，很多人断言docker只适合stateless的微服务。当时也没有overlay网络，构筑一个最简单的集群网络也需要引入大量额外复杂度，以虚拟网桥/交换机来说性能开销也并不小（即使是现在也不建议把bungeecord放在overlay网络的网络里运行，overlay把以太帧封装入udp报文里传输，容器间的流量稍微有个几百mbps带来的额外开销就很夸张了），而最重要的是外围管理设施的缺失。——

现在有swarm，有k8s等等工具，而在当时选择docker就意味着只能集群管理只能自己手lu了。而现在，尽管docker本身的一些缺陷依然没有克服，但是最致命的文件系统性能和网络架构问题已经基本解决，周边设施也随着社区的发展日新月异，可以说跟我刚接触docker时候的0.x版本已经不可同日而语了。

而openvz这些年一直在原地踏步，并且随着el6的大限将至，openvz7不再单独作为基础组件发布，可以遇见到的是openvz的迅速没落，尽管它提供的一些vm级的特性是docker未来也永远不可能提供的。

现今如果要把梦世界的集群迁移到docker还需要解决一些架构上的问题，最麻烦的服务自动发现部分早在几个月前就已经通过插件解决了，代码开源在gayhub，docker世界里有很多为ha准备的工具，我相信如果能够完成迁移工作的话会给服务带来相当大的提升。