在网上查了一圈这个问题，结论是比较可靠的版本应该是 43 字节，完全符合标准且能被正确解析。

提供参考的网页主要有：

• http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
• https://stackoverflow.com/questions/2570633/smallest-filesize-for-transparent-single-pixel-image

其中有提到按照标准，可以省略 6 字节的全局颜色表，但是这样可能导致不能被正确解析。

还有很多人声称省略更多部分也能被正确渲染，这种就不考虑了。其中有将 LZW 数据减少到 5 字节以下的尝试，特别查阅了一下，找到了一篇 LZW 过程的讲解，写得不是很好懂不过还是能看懂。根据这篇讲解，符合标准的 LZW 数据不能少于 5 字节。

数据具体的内容可以参考 Nginx 的版本，在代码里有比较完整的注释。数据的 base64 是

1

R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAAAICTAEAOw==

代码注释里面 LZW 的部分一开始没看懂，看了上面那篇讲解才明白应该按小端序来读，01001100 00000001 应该提取出 100 001 101。

https://t.me/effective_url_bot

跟踪 HTTP 重定向响应，用来把某些 App 生成的短链接恢复为原始链接。Bot 会提取出文本中第一个完整的 HTTP(S) URL。

如果跳转是通过 JS 完成的就没用。设置了 PC 版 Chrome 的 UA，有的移动版链接可以跳回到 PC 版。

事情的起源是无意中搜到了一个 8K 视频，自然想着要体验一下。在我手机上理所当然地无法播放，在我笔记本上可以正常播放。本来这样就完了，不过遗憾的是我的显示屏只有 2K，并不能真正体验到 8K 的效果，于是找了一个有 4K 显示屏的同学来尝试（虽然还是不够……），结果他不能正常播放。

Youtube 的视频在 4K 及以下用的都是 VP9 编码，但是到了 8K 就变成了 AV1 编码（不是 AVC1）。这个 AV1 要 30 系显卡才能硬解，而他的显卡是 10 系，只能软解这个 8K 视频，当然是无力回天。

于是用 yt-dlp 把这个视频下载下来，试图转换成其他编码播放。由于解码实在是很慢，中间尝试了在有 30 系显卡的服务器上转码，但是 ffmpeg 的一般版本似乎不支持硬解 av1。在 Nvidia 的网站上找了个编译说明，手动编译了 ffmpeg，不知道为什么还是不愿意硬解，最后只好放弃。转成 HEVC 之后，在他的电脑上就可以正常播放了。

到这里好像都结束了，其实还有一个问题没有解决：为什么一开始在我的笔记本上可以正常播放？

我笔记本的显卡有 i7-1165G7 的核显和 MX450，后者根本不支持音视频编解码，反而是前者还支持硬解 AV1。在上面对各种编码和各种播放方案进行了测试，结果如下：

直接在 Youtube 上播放的时候，因为正好 Chrome 可以正确调用 AV1 的硬解，所以才能正常播放。

命令行

最后记录一下命令行，都是直接调用 ffmpeg，没有配置额外选项。

首先是 yt-dlp 只能下载单独的视频轨和音频轨，可以先将两者合并成 av1.mp4：

1

ffmpeg -i video.mp4 -i audio.webm -c copy av1.mp4

之后的转码的命令行如下：

1
2
3

ffmpeg -i av1.mp4 -c:a copy -c:v h264 avc.mp4
ffmpeg -i av1.mp4 -c:a copy -c:v hevc hevc.mp4
ffmpeg -i av1.mp4 -c:a copy -c:v vp9 vp9.mp4

也可以最后再合并音轨，不过封装音轨不费什么时间，没多大区别。

挺厉害的，基本上什么都能安装。就是手机打字实在是折磨。

可以用 ssh 访问手机文件，就不用 adb 了，好像还挺爽的。

现在还不知道还能有什么用，应该会挺有用的。

总算把博客搭好了。

这事情拖了三年，谁叫我最初想自己写一个博客系统。这根本就不是一个正确的解决方案。自己水平相当有限，精力也相当有限，就算写出来能运行也只会是一团浆糊，想着就令人头疼。更重要的是，与其花费精力维护一个博客系统，还不如多写点内容。这几年什么都没写颇有一种荒废感。

当然好的地方是，我现在知道这一切是如何工作的了。如果搭起来也不知道自己到底在干什么，我就会不断怀疑我的做法是否是正确的。到了现在，即使不见得是很好的方法，我也可以确信至少没有多大的问题。

现在这个博客用的是 Hexo，虽然我根本就不想用这个，但是实在是不想再继续研究了。这个比较方便，先凑合着用一段时间吧。

关于部署，尽管也可以部署到自己的服务器上，但是感觉挺麻烦的，加上也想试一下 Hexo 的部署功能，就先用了第三方平台。Github Pages 要建一个域名同名仓库，感觉很不爽。看到 Hexo 支持部署到 Heroku，正好以前也用过，就用这个了。Heroku 本来是用来部署代码应用的，但是静态网页是 PHP 的子集，所以也可以部署。

后面又踩了一堆坑：

• Heroku 以前可以配 ssh key，这次配完了之后发现现在已经不支持了，又把 key 给删了。现在只能用 HTTP API token，还最多只有 30 天的有效期。
• Hexo 的 Heroku 的插件一直报错，查了半天得出的结论是只能把 node 降级到 12。
  • 虽然 npm 写了支持 node 12，但实际上 npm 一更新就报错，最后只能不更新了。
  • 事实上连 node 14 的 npm 也无法更新，但是把 node 16 的 npm 直接复制过去是可以用的（node 12 不行）。
• 看了下那个插件的代码，就是调用几个 git 命令。坑点在于，它会在子目录里建 git 仓库，如果主目录已经建了 git 仓库它就不建了，会错误地使用主目录的 git 仓库。

用 Heroku 的自定义域名要绑定信用卡，不想绑定，只好自己整了个反向代理。

2022-05-27 更新

改用 GitLab Pages 了。看了这篇教程。GitLab 的 CI 看起来比 GitHub Actions 正常多了，部署静态页面很方便，自定义域名也很方便。

GitLab 有 Hexo 的模板，不过我用的是部署静态网页的模板，在本地生成好了再提交过去。不想管 Hexo 的部署功能在搞什么了，随手糊了一个一键部署脚本。