ffmpeg剪辑视频

标准例子:

ffmpeg -i input.mp4 -ss 01:19:27 -to 02:18:51 -c copy output.mp4

这里-ss 表示开始时间, -to 表示结束时间

从开始位置截取多少时长的内容:

ffmpeg -i input.mp4 -ss 00:01:10 -t 00:01:05 -c copy output.mp4

这里引用了-t : duration 参数, 控制了截取视频的时长

那么, 以上做法有什么缺点么?

有的, 一个是慢, 一直在seeking 那个时间的样子, 另一个是画面容易在开始时候黑屏

优化方式:

ffmpeg -ss 01:19:27 -i input.mp4 -to 02:18:51 -c copy output.mp4

这里的技巧是把-ss提前了, 相当于让ffmpeg索引到关键帧, 缺点是会重置时间, 所以这里的-to 参数就相当于-t duration了

参考文档:

openssl 探测证书过期时间

true | openssl s_client -connect IP:443 -servername hostname 2>&1 | openssl x509 -noout -text -certopt no_header,no_signame,no_pubkey,no_sigdump,no_aux

这边一直都是用这个来探测证书的健康的, 在内网的使用还可以, 在公网探测中就很容易出现僵死的情况

后来在sererfault.com查到可以用timeout + 命令来解决

https://serverfault.com/questions/361464/is-it-possible-to-set-a-timeout-on-openssls-s-client-command

测试时发现”timeout 5 true | openssl …” 的管道会失败, 在公网的探测就傻兮兮的只能用了

timeout 5 openssl s_client -connect IP:443 -servername hostname 2>&1 | openssl x509 -noout -text -certopt no_header,no_signame,no_pubkey,no_sigdump,no_aux

缺点是每条指令都要等5秒, 当然, 结合多进程问题也不是太大…

直到今天, 才发现自己摆了个乌龙, 可以使用timeout 5 bash -c “true | openssl s_client… “, true可以处理实时正常结果, timeout可以处理异常结果

timeout 5 bash -c "true | openssl s_client -connect IP:443 -servername hostname 2>&1 | openssl x509 -noout -text -certopt no_header,no_signame,no_pubkey,no_sigdump,no_aux "

aws lightsail ipv6 路由问题

OS 为: amazon linux 2, 当开启ipv6.forwarding的时候, 发现路由就不通了

sysctl -w net.ipv6.conf.all.forwarding=1

#ping6 www.qq.co

connect: Network is unreachable

netstat -nr6 也能看到没有default route, 此时ipv6地址也无法被外部访问

如果关闭ipv6 forwarding, 那么就有默认路由, 也能ping通外部和被访问

::/0 fe80::7c:6bff:feef:ca54 UGDAe 1024 2 9 eth0

能看到路由有一个很特别的标志UGDAe, UpGatewayDynamicAllonlinkExpires

E(e): It maps to RTF_EXPIRES. It means the route has a non-infinite lifetime. In this case, the kernel probably learned the route dynamically from a RA (Router Advertisement).

这个路由其实是动态广播的, 那么这个现象就跟一个参数有关了

net.ipv6.conf.interface.accept_ra

Accept Router Advertisements; autoconfigure using them.

It also determines whether or not to transmit Router Solicitations. If and only if the functional setting is to accept Router Advertisements, Router Solicitations will be transmitted.

Possible values are: 0 Do not accept Router Advertisements. 1 Accept Router Advertisements if forwarding is disabled. 2 Overrule forwarding behaviour. Accept Router Advertisements even if forwarding is enabled.

Functional default: enabled if local forwarding is disabled. disabled if local forwarding is enabled.

Nb: per interface setting (where “interface” is the name of your network interface); “all” is a special interface: changes the settings for all interfaces

默认系统这个参数是1, 当开启forwarding的时候, 不接受路由广播, 所以这个场合, 应该修改为2, Accept Router Advertisements even if forwarding is enabled.

sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.eth0.accept_ra=2

备注:

 UP U
 GATEWAY G
 REJECT !
 HOST H
 REINSTATE R
 DYNAMIC D
 MODIFIED M
 DEFAULT d
 ALLONLINK a
 ADDRCONF c
 NONEXTHOP o
 EXPIRES e
 CACHE c
 FLOW f
 POLICY p
 LOCAL l
 MTU u
 WINDOW w
 IRTT i
 NOTCACHED n

HTTP2 URL请求过长访问失败的问题

使用过长的url通过H2访问的时候, 容易出现请求被reset掉, 但是HTTP/1.1请求没事

  • TLSv1.2 (IN), TLS alert, close notify (256):
  • Empty reply from server
  • Connection #0 to host api.k.sohu.com left intact
    curl: (52) Empty reply from server
  • Closing connection 0

打开nginx debug 日志可以看到

client sent too large header field while processing HTTP/2 connection

这是因为HTTP2有一套自己的优化参数, 主要跟两个参数有关:

http2_max_header_sizehttp2_max_field_size

http2_max_field_size 是HPACK压缩的header大小(H2的特性, 头部压缩), 默认值4k

http2_max_header_size HPACK解压后的header大小,默认16k

需要特别留意的是, 1.19.7版本以后统一使用large_client_header_buffers 来控制

这几个参数都可以根据单独server 来使用的

http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_field_size

参考文档:

https://phabricator.wikimedia.org/T209590

亚马逊lightsail免费期的收费项目

亚马逊的lightsail提供了3个月的免费试用, 有$3.5 $5 $10的主机选择

对于刚搬迁过来的用户可能会对一些收费不了解, 这里就我踩过的坑介绍下

来看看一份账单

这里有两个收费项目:

  1. snapshot的存储是收费的, 按照容量和保存时间收费
  2. 静态IP如果没有绑定到实例, 也是需要收取闲置费用的

当然, 使用container, database, 额外的存储/IP/镜像等, 也是收费项目

个人认为静态IP在实例被释放后没有绑定到新实例, 会是新手很容易忽略的收费陷阱

从linode迁移到亚马逊lightsail

我是linode 10多年的老用户了, 从2010年就在上边安家, 期间从fremont搬迁到东京, 又搬回来,来回折腾过几次

一开始是大熊推荐的, linode的确是海外云主机最好的选择: 因为稳定.

到了最近几年, linode变成了”稳定”的慢和移动访问”稳定”的丢包, 一言难尽

今年年初刚好发现亚马逊推出了lightsail的服务, 配置类似于EC2的t2, 可定制化更少, 但是流量包更大

对比下linode 和 lightsail的方案, 可以看到lightsail的磁盘大一些, 流量包也大一些(其实差不多, 因为aws是进出双向计算, 只有超出限额才改成output流量计费)

相比硬件配置, 网络才是让我下决心搬迁的主要原因, 我lightsail节点是新加坡的, 广州电信访问大概是46ms, 广州移动访问是45ms, 广州联通访问是88ms, 都不丢包, 划重点: 不丢包!

联通线路
电信线路
移动线路

而linode的fremont 大概是160-180ms, 间歇性丢包, 尤其是晚上移动线路, 东京机房也差不多

电信线路
移动线路

这是因为亚马逊实现了跟三大运营商的直连, 而linode 没有, 这对于服务国内用户来说是一锤定音的因素, 更何况还有3个月的免费试用期

相信看到这里, 苦于linode网络的, 都已经忍不住去注册了, 这里放一下连接

https://aws.amazon.com/ 选择lightsail服务

nginx upstream check module TCP check检测漏洞

upstream test_check_bin {
server 10.19.127.22:8080;
server 10.19.127.57:8080;
server 10.19.126.6:8080;

keepalive 32;
check interval=10000 rise=2 fall=3 timeout=3000 default_down=false;

}

我们使用的是一个臭名昭著的模块 , 这个模块的作者去了淘宝后便只有tengine里边的模块得到更新了

https://github.com/yaoweibin/nginx_upstream_check_module

目前发现了在当前代码存在两个问题:

  1. TCP检查在几种情况下会失效, 比如交换机挂掉, upstream机器网线被拔了, upstream机器crash了
  2. TCP检查的rise count 存在不增加的情况, 主要是裸JAVA和JAVA容器(java -Dspring.profiles.active=local -jar httpbin-gateway-test.jar),裸python -m SimpleHTTPServer 80之类

第一个问题是因为这个版本的upstream check TCP代码使用的keepalive模式, 根据这个文章的解释TCP Keepalive的心跳包是7200s,两个小时,一旦建立,没有收到主动关闭请求的话在探测端会一直保留establish的状态

https://m.haicoder.net/note/tcpip-interview/tcpip-interview-tcp-keepalive.html

当upstream端突然硬件故障/交换机挂掉/网卡被拔之类的极端情况出现的 时候, nginx 基于keepalivedTCP检测是没办法捕获到这个情况的(检测模块没收到RST/或者dst unr包)

在正常情况下, 比如upstream 端web服务器 STOP了, web服务器oom被系统kill了, docker 实例被stop/kill了, 都会触发关闭连接的请求包 给到nginx 端, 能识别到服务down了

这个是upstream端被kill了
docker kill/stop 都会发包告知nginx TCP监测端

从tengine这个模块的最新代码看, 作者也意识到了这个问题, TCP检测把need_keepalive参数从1改成了0

这个1表示need_keepalive, tengine修改为0了
ngx_check_conf_t 模块这个结构体的定义

这个参数变成0之后会影响clean_event的操作, 每次检测完毕后会close掉连接,每个检测周期都会重新发起TCP连接

need_keepalive参数控制了连接是否销毁的行为

第二个问题: rise counts 不增加, 这个通常都是upstream 端listen 模式有问题导致, 它并没有正确的定期回包, 通常情况下, nginx, apache都能正常的主动回包让rise counts增加

大多数upstream端主动发送包(确认是否存活), 否则很快就会close

python java这些裸起的一些简单服务就没有定期主动回包, 而在这个版本的代码中, 会判断这个connection是否存在, 如果存在则return了导致计数器不会增加

tengine的新代码是去掉了connection != NULL的判断条件

不过, 划重点: 无论是否回包, rise counts 是否增加,并不影响TCP监测的存活性, TCP监测keepalive模式仅仅以能否建立连接(刚启动时)/是否收到upstream的异常包为判断依据

总结: 为了避免过于复杂的处理逻辑, tengine去掉了keepalive的TCP探测,每次请求完都销毁连接,下次探测再重新协商请求

这里给下针对这个问题的patch:

https://www.4os.org/patch/nginx_upstream_check_tcp.patch

使用利民散热硅胶垫 改造 macbook air 2020 散热

macbook air 2020款intel 处理器开始 CPU就没有风扇直连了

日常使用问题倒是不太大, 但是开视频会议的时候特别容易撞温度墙降频, 机器卡顿

发现有一款神器, 叫散热硅胶垫, 可以用于改造macbook air 散热, 有莱尔德/利民等不同品牌不同型号

Laird Tflex HD90000 Series Thermal Pad For M2 RTX 3000 3080 3090 Card Video  Memory,7.5W/mK,80x40MM,1.0,1.5,2.0,2.5mm Thick,Soft| | - AliExpress
莱尔德HD90000, 许多显卡的散热标配, 但是容易出油
利民 12.8W 之前的散热神器, 虚标

利民15w
一般大家其实都是用来显卡上的

莱尔德散热效能没得说, 缺点是容易出油并且会析出银粉不好清理, 于是我选用了利民, 有12.8W和 15W两种规格, 来都来了, 自然是选15W这款

打开机器后盖, 裁剪尺寸, 贴在散热器后边即可

从geekbench的数据看, 性能提升挺明显的

从cinebench测试看, 多核性能提升了20%, 单核性能由于没有撞温度墙所以不明显

待机温度也很友好了, 45°左右

散热垫评测:

https://www.bilibili.com/video/BV1d44y1q7vf?spm_id_from=333.999.0.0

小米路由R1D ipv6设置

分为普通模式和中继模式, 略有不同

  • 中继模式需要配置

/etc/config/ipv6
config ipv6 settings
list if_on "lan"
option enabled "1"
list if_on "ipv6"
option enabled "1

/etc/config/network

config interface 'lan6'
option ifname '@lan'
option proto 'dhcpv6'

可以适当配置ipv6的DNS, 非必须

  • 普通模式需要配置

/etc/config/ipv6
config ipv6 settings
list if_on "wan"
option enabled "1"
list if_on "ipv6"
option enabled "1

/etc/config/network

config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
list dns '240c::6666'
list dns '240c::6644'

然后重启或者/etc/init.d/network restart即可