(\d{2}): (\d{2}): (\S+)-> (\d{2}): (\d{2}): (\S+)
$1:$2:$3 --> $4:$5:$6
然后到 Google 上翻译下，以这个正则替换修复破损的 SRT 格式。

ffmpeg -i IMG_6302.MP4 -vf subtitles=IMG_6302_en.srt IMG_6302_zhEn.mp4

总耗时 40 分钟

🤔 我们来说说之前的 Montage.py 策划。
蒙太奇图是一种艺术画，它用许多相对整齐的子构件来构筑一副图画。

之前我们的安排就是，利用 Python Pillow / Java AWT+ImageIO 的接口，有一个画布以后直接取 color average （实际图像一般有三个 channel，我们只需给这片区域 int[3][] 取 avg 即可）
然后遮盖那一部分原图区域的项就用这个颜色。

不过还有个问题，就是怎么知道项都放哪，之前的项目是有一个 LayoutPlanner，它会 yield 给一大堆 Rect（矩形区域），然后作画也在那上面（准确的说是给 draw 的算法一个 "sub-image" (后来改 crop 了) ）完成，结果最后改来改去失败了，效果很不好
但后来我发现呢…… LayoutPlanner 实际上是不能独立于绘制算法要绘制的区域而存在的，所以失败是当然的。

现在的抽象会是这样
class Drawable:
def drawOn(img: Image) -> Rect: pass
class TintedDrawable:
def drawOn(img: Image, tint: Color) -> Rect: pass

然后布局就是经典的 for y for x 了， x >= width 就 y += avg_h 。

参数：
font, font-size
color-mode, crop, scale (float / tuple)
image items

后来看了另一个项目才想起来的：
space-hv (tuple)
tint-color (code on sub-image lambda it: averageColor(it) )
draw-unless (code on sub-image lambda it: pixelsInRange((0xFF,0xFF,0xFF), 10) / it.count() > 0.5 )

#dev #PLT 以前经常把类似 LuaJava, JamRuby, Lua-intrf 之类的东西称为“高阶语言桥”或“语言绑定” （相反 SWIG 之类的 bindgen 就不会了？）
想想这无非是一个好看没不讨喜、充满民科气息的名词。
给两门语言创建“绑定”，其中一般有一个采用比较“脚本化”的实现方式而非静态编译之类，但关键在于提供底层 API (如 C API)，然后再把 API 和另一门语言创建更高层的绑定（整句话都不太严谨，毕竟涉及 FFI(foreign function interface) 这种非常实践性的问题）

绑定和一般的库绑定会有较大的不同之处，主要体现在数据对象的封送、类型转换(可能存在)、对应的 GC 接口互调等等。
一个主动一个从动，但从“语言实现”绑定的角度看，如 LuaJava 在 Lua 侧能访问 Java 的对象成员，Java 侧也能从 Lua 的 boolean, number, table 等获得信息，这是主要功能。

我应该多写点 C++，光 Java 是不够的，但是我现在真的熟悉 JDK 么……

🤔 xywhijnmhv

其实无论你们怎么选，我都会再重写一遍，不好意思 😂
我只是想摸下鱼。

我不是很喜欢最后那个算 padLeft 和 padUp 的
大致就是
lineW = (cfg.font_size + sp_h) * scale
lineH = (cfg.font_size + sp_v) * scale
cols = int(image.width / lineW)
rows = int(image.height / lineH)
padLeft = (image.width - (cols*lineW) + sp_h) /2
padTop = (image.height - (rows*lineH) + sp_v) /2
🤔 很生的布局边界计算，难怪当时我想用一个 LayoutPlanner ，原来是这么算的 真的有预先算布局再区间迭代啊……
（啊不对，不是 line，应该是 item……）

差别大致在于预先算好了的项目布局不依赖执行顺序（这样就相对容易优化），看来我有必要把 TintedDrawable 给细化一点了……
class TintedDrawable:
def drawOn(self, img, rect, color): pass
这样的话既可以保证项目的灵活性，也能保证算法尽可能抽象。

这一段设计实在是太赞，爱了爱了（虽然现阶段解耦合的设计可能带来额外开销）

#GUI 🤔 谁会画这种单元格？……
class Boxes: QWidget {
public:
Boxes();
~Boxes();
int width, height;
int n_rows, n_cols;
void setColor(QPoint p, QColor color);
QColor getColor(QPoint p);
}

数据都迁移完了
目前发现损失的有
文化周的视频（可以重新编码出来）
PS安装包（可以重新下，反正到时也要换2020版的了）
红米3刷机包（重新解压的事）
Windows 8.1镜像（重新下）
腾讯会议安装包（这个其实也没啥留着的必要）

综合看来损失不算特别大，但万一以后损失的是其他东西呢

好想学 Java swing/awt 和 Qt GUI 开发啊

Python 就有一点好，就是 pip ipython 什么的都很简单，想要什么依赖几乎都可以立等可取不需要折腾什么构建管理啊包管理啊（甚至还得提供“repositories”）
而且又有带语义缩排，不像其他语言要么 {} 要么写一大堆 end

所以虽然 Python 有很多缺点，但还是会被包括学者在内的许多人喜爱
Kotlin 现在是没 boilerplate code 了，但我可以不开 IDE 直接就在 Kate 文本编辑器里想到啥写啥，虽然可怜 Python 没有静态检查而且很不严格就是了……

但好好考虑一下，Python 新建一个文件，写上一个 shell-bang line 再 import 几个必要库就可以开整，但 Kotlin 还要按照 Java 的那一套去配置半天…… 就为了个很牵强的“可复现的构建环境” 也是怪难受的了

其实 extract-subtitles 完全可以移植到 Java，关键依赖只不过…… 是 OpenCV, Tesseract, 和一个从信号取得所有峰值索引的 peak estimation 算法
不知道 Python 用 ctypes 绑定一些简单的 C function 还是用 JNI 简单（
不过也必须有 Iterator 并且能实现 chuncked 方法，要不然处理点高清视频 JVM 上照样卡死。（ java.util.stream.Stream 里面已经有了 reduce 方法，不过那个是新的 Java API，Android 里也木有…… ）