阅读视图

用这三货做数据查询

不知道从什么时候开始,我就迷上了数据查询。

一开始只是想实现某个功能,后来发现原来实现同样东西,我用不同方法都可以做到。哪个方法更直观简便一些?我感觉Excel VBA的SQL,Power Query以及Python相比,就数据处理的方便性来说Python是碾压的,但我没有发现Python的巨大优势。问题可能在我交给Python处理的数据太少了,跟其它两个相比体现不出Python的高效。在控制Excel单元格格式方面,Python天生不如office自家的VBA。为什么我会把PQ跟VBA跟Python相比呢?是因为从Office 2019开始,PQ就算是内置的一个功能。VBA里面的SQL天生有缺陷,因为跟真正的数据库SQL相比,那就是个阉割版,有些你觉得明明可以实现的东西,在Excel VBA里好像就真没有直接的解决方案,为什么居然会这样呢?

到现在为止,我依然没有发现Excel VBA的SQL有直接的文本拼接功能。其它数据库的SQL里,那就是一个很简单的函数。Excel VBA的SQL在合并其他数据方面没问题,但一旦遇到需要进行文本拼接。我感觉除非在查询结束以后再做一个字符串的字典,否则无解。或许你会说其实我也可以直接在Excel的函数层面做这个拼接,因为用textjoin函数实际上是能实现那个功能的,但关键是如果数据比较多,既然我都在VBA里完成前面的所有,为什么最后的功能又要回归到函数呢?二者的运算速度不是一个层次的。每当我遇到文本拼接,我知道SQL是撞墙的,所以我就直接想到PQ。

PQ可以做数据分组,做文本拼接直接在高级编辑器里修改就能实现,但关键是实际上可以不用PQ,我不想用那个玩意,使用可能会有点慢还行,如果要进入到里面编写代码,那个小窗口字体无法放大,简直要逼死我这种老花。更作死的是,很多时候提醒我错误,但错误根本不发生在提醒的那个地方,不断的嵌套括号、逗号、又或者不小心带入的中文标点符号都会导致错误,找茬的过程让人挺绝望。我觉得,我还是喜欢在VBA里用SQL,其实无非就是判断加循环。在PQ里我总觉得有些很容易就能做到的事情,但是它非得用一些看上去很复杂的函数去实现。比如要根据A字段去决定B字段的数值是正数还是负数,在SQL里,一句很简单的iif就能实现,但在PQ里,你还得新建一个条件列,把条件写进去,接着把原来那个数值列删掉,再把条件列的名称改成数值列。当然你也可以直接使用replacevalue函数,但据说那个东西的执行效率反倒不如新增一列再删除一列。PQ里的函数非常多,嵌套用起来的方法更是让你眼花缭乱,也正是因为那些杂七杂八的东西太多了,反而让我觉得不如SQL简单干脆。让我很绝望的是,Access的SQL可以直接文本拼接,但Excel里的就不行,虽然二者是同一个版本的office。

当我在一个问题上钻研得越深,我就越能理解到高中时候,我的数学老师说学习数学的几个境界:不懂不会,会而不对,对而不全,全而不好。

  •  

键盘太智能

周三下午开会,周四要切换系统,到周五下午快下班的时候,我想到经常查这个数据的人还有会计。就去问了一下,他们需要哪些数据,然后我就可以在导出的表那里为他们挑选有必要的字段,没有必要的就直接不理会了。因为之前已经做了两个格式化,在做第三个的时候,我只是在之前的那个基础上修改而已,所以非常简单,从询问需求到最终出来大概只花了15分钟,同事非常惊讶。要知道前两个版本出来花了好几个小时,尤其是第一个版本,所以最后这一个只是细微的些许的变动当然显得很简单。那些需要用已有的字段做判断,得出新数据的新字段,该怎么个判断法之前我也已经考虑得很透彻了。

我觉得对导出数据用SQL做筛选或者分组合并是最恰当的,因为那个大表里的字段很多,如果用经典VBA的方法,要保留某些,要剔除某些很费劲,但是如果用SQL去考虑这个东西就很简单,我根本不需要考虑原来有多少个字段,我只需要知道我需要留下什么字段就好了。字段的排序是可以随意捣乱的,字段名也可以重命名为我想要的那个。我不知道浪潮脑子里想的是什么,字段名里面有括号有斜杠,反正就是不少不太恰当的字符。要在SQL里面引用这些字段名就得用`。这个东西之前我还真不知道,但我肯定有某些方法可以把某些特殊字符认定为某个名字而不是特殊字符的特殊含义。SQL筛选很简单,就像是点菜一样。最关键的是我得知道你要做什么菜,然后我才能为你考虑我得为你准备什么食材,那些食材应该怎么预加工。在做第三个格式化的时候,基本上所有事情都已经得心应手。

当我把这个东西交给我的同事,让她试用的时候,又发现一个新的问题了。我没有给他们配置宏大按钮,所以要运行那个宏还是用office经典的那个快捷键Alt+F8。在标准的键盘里直接按这两个就可以了,但是在某些品牌的键盘,布局是不可能光按一个键就调出F1到F12的。比如联想的台式机标配的键盘或者笔记本电脑就不行。他们默认的是那个键所对应的是多媒体。我同事的那个键盘是罗技的Wave Keys,也就是人体工程学键盘。她那个键盘默认的也是多媒体,所以当我要她按Alt+F8时候,F8根本出不来,在那种情况下,最直接的办法是按三个键,Alt+Fn+F8。联想的键盘有可能无法把F1到F12锁定为这些键原来的功能,但我确定罗技肯定可以。当我要给我的同事干这种事情的时候,她跟我说多媒体键盘那里的截图很好用。

以前的windows系统自带的截图要不全屏,要不窗口。大概好像从win10开始。win+Shift+S能调出任意选取框的截图,默认会保存到粘贴板。这个也是在我遇到了那个键盘的快捷键之后才去搜索出来的。一直以来我用的都是QQ或者微信的截图。QQ的截图是Ctrl+Alt+A,微信的截图是Alt+A。当我有截图需求的时候,这两个东西肯定有一个挂着,这两个东西除了截图以外,你还可以对图片进行各种加工,比如框选比如模糊。我的同事虽然的电脑也挂着微信,但是她用的却是罗技键盘上面的截图快捷键,也就是调用系统的截图。既然她喜欢用那个快捷键,我也没办法让她把F1到F12的功能还原出来。

在office里,Alt+F8就能马上调出宏的运行窗口,如果只有一个宏直接按回车就完了,但关键是如果遇到某些人的键盘F8不能直接出来,这显得很郁闷。我明明可以告诉她office里面找到开发工具,然后点击宏也能出那个快捷键的窗口,但我选择不告诉。因为如果她知道能用鼠标点的方式,她就不会使用快捷键。这也就是为什么明明很多事情可以很简单,他们需要点击很多次鼠标、滚动很多次滑轮才能做到的原因。

程序该考虑的我会考虑到位,但使用方法,我真的不想再为他们费心了。

  •  

实战

对系统的导出数据进行了两种形式的格式化以后,接下来我要把其中一种格式化的VBA交给同事,告诉她该怎么用。在我印象之中,每天他们报送数据的时候用的电脑装的是office软件。我这里说的报送,意思是要得出某个文字转化版本的那些人。单位是很奇怪的存在。联想电脑附带的软件是office家庭学生版的正版,另外一些系统不知道为什么一开始的时候就被格式化了,被某些人装了windows系统之后装过各种奇奇怪怪的软件,最终可能定下来的是一个不知道什么版本的wps。也不知道从哪一年开始单位就有批量买的wps,但因为我是office软件的超级粉丝,wps根本无法满足我的要求。因为wps没办法做Power三剑客。Power Pivot还好一点,我用得比较少,但是如果要对一些数据进行文本合并,SQL没那么容易,需要用字典搭配字符拼接才能实现。在那种情况下,我首选通过Power Query合并。当然用Python也能做到,但是如果某个人的电脑里面装的是office,又在2019以后,PQ内置功能,但如果要别人运行Python,还需要安装,还需要配置环境。

我没想到的是那个同事居然先拿回办公室试一下,她办公室电脑用的是wps。wps我猜她安装的版本是32位,因为我的VBA查询用了ADO+SQL,这两个东西意味着不是所有的wps都可以直接执行。即便单位买的那个wps的版本能运行宏,但是宏里面又用了SQL,这个估计就很悬,最终能不能用,可能也可以但估计得折腾一番。幸好她没有挣扎,直接拿着那个VBA文件就直冲工作地点。她第一次在办公室截图回来告诉说wps无法运行宏的时候我就下去找人,结果没找到,原来她已经直接去工作地点了。过了一阵她又跟我说运行不了,反馈出来的那个信息就是VBA脚本没有找到恰当的源文件。

我第一个反应是她导出的文件会不会文件名有一些空格没有留意到,于是我马上赶往那个地方,结果发现她的确导出了文件,但是她发现导出文件的名字跟我之前跟她说的不一样,所以她重命名了。重命名没有任何的意义,因为导出的文件名不一样,基本可以确定她导出的位置不对。当我问她是在哪里导出的时候,她自己估计也马上发现了问题所在,果然就是因为她导出的文件导出错了。

工作地点的那台电脑一次就通过VBA考验。旁边的那台电脑是一台新的联想,预装office2021家庭学生版,但是那台电脑打开VBA之后就会有一条红色的提示。正常情况下,理论上那应该是一个黄色的提醒,按确定或者允许之类就可以了,但红色的提示好像根本没办法按掉。只要按那条红色的东西,就会弹出一个网页,告诉你一些细节。一开始我没有留意,我不管那条红色直接去选项那里设置允许宏,但即便这样,这个文件也依然运行不了。我就不得不去仔细看红色那条提示对应的那个网页。发现是因为因为出于某些安全原因,系统锁定了这个带宏的文件,需要在文件那里按右键点击属性,然后再点击某个解除按钮,之后才能运行那个文件的宏,打开文件才会出现黄色的提示。所以到底是什么安全设置让那个电脑带宏的文件出现那条红色的提示呢?起码在之前我接触过的所有office里未曾遇到过。

对用宏文件的人来说,宏可能有风险,但是对我来说,宏是我自己写的,我不可能不放心。

  •  

Svelte和Sapper实战

评分

⭐⭐⭐⭐⭐ ⭐⭐⭐ 8 / 10

评论

川流的作者李大毛没有猫在群里招募为新网站写前端的人,我报名后了解到其技术栈是 Serverless 和 Svelte 和 SvelteKit。我大约在几年前在 daily.dev 上常看到大家拿 Svelte 与 React 和 VUE 对比,但也有一些认为 Svelte 也有其不足,由于当时其位列前端三大方案之后,我未作细节关注。

这几年我都没有涉足编程技术,在大体尝试 Svelte 官方例子后,得知 SvelteKit 就是之前的 Sapper,让我想到了这本书。虽然 Svelte 出现的比较晚,在营销方面也没有很多突破,但它的思路确实比虚拟 DOM 更新颖,服务端编译也为它带来了比较优势——更小的打包尺寸和更好的性能。

我相信系统性优势是可以扩大市场占有率的,同时,我也认识到 jQuery 存在的时间比想象的要长。

说到此忍不住吐槽国内的技术生态,今日还看到v2ex一个帖子,说国内技术环境常年不变 centos7 java1.8 mysql 5.7,其实不全是,常年不变的算不上以技术为竞争壁垒的公司。仅在计算机系统的软件层面构建竞争壁垒是非常困难的事情。国内某些“厂”,之所以常年使用固定的开发环境,是因为它赚钱核心并不在此(使用更新的开发平台、更新版本的编程语言、性能更高的数据库),也不想在软件研发上作小白鼠做无谓的投入。这是一种很油滑作呕的策略,只从外部吸收索取,不回报,拿着多个开源项目,自己改吧改吧生成自主掌握技术。也许商业上算成功的,但对技术社区没有实质贡献。

这本书的可读之处,不仅在于它对 Svelte 体系的介绍,更在于作者的深厚功力,可以学到一个工作三四十年的技术大拿的思维方式和对技术周期的认知。

Svelte 是否是 React 的颠覆者呢,从影响力上算不上,但它确实是一种 Smart 的范式,喜欢的人自然喜欢,我也见过太多的新技术,但 Svelte 来说,它不仅仅是前端框架中一个新的 VUE。

  •  

先补帧还是先放大

最近一直很无聊的在用AI工具做 文生图生视频 动画。线上用的豆包文生图,即梦首尾帧图生视频。豆包也有用图生视频,把首帧图倒放,然后接到即梦视频的前面。

因为豆包和即梦的视频输出是诡异的 1248x704p24fps,704甚至不能被9整除,1248÷16×9=702(根据网上搜到的结果说是为了匹配patch所以要能被32整除)。所以我在线下用了 realesrgan-ncnn-vulkan 和 rife-ncnn-vulkan 把输出放大到 1408p ,把帧率补到 60fps,然后再用 FFMPEG 重新编码到 1080p60fps。

(可灵虽然直出1920x1080p24fps,但是一个月就166个点数,非会员生成视频还要等几个小时,而且不还能多个生成并发排队,有时候生成的结果还特别像幻灯片然后补帧到的24fps。屁用没有)

这样就有一个疑问了:

是先补帧?还是先放大?


交换律?

首先第一刻板印象当然是想到了交换律,即最终结果都是1408p60fps,所以顺序并不重要。

但仔细一想,插帧是一种算法实现,缩放是另一种算法实现,这两种算法除了都是从卷积派生出来的之外,基本没啥数学关系,甚至先补帧后缩放和先缩放后补帧的1408p60fps输出结果都不一样。

所以这玩意不符合交换律。

而我其实并不太关心最终结果的质量。这俩工具目前的使用场景都是大玩具,实际生产环境也是作为玩具存在的。

我更在意的是在有限性能下,哪个前哪个后的总耗时更短,速度更快。

当然这俩玩意的算法我是没研究过,即使研究了,其在实际场景下还有多核和多线程调用的差异,在不同硬件和不同驱动下也肯定没准。

还不如在自己机器上实际跑一遍测速。


测试

所有测试中用到的视频,我上传到了B站。因为B站有二压的特性,所以所有视频素材整合到了同一个60fps的视频中。同时因为B站的限制,非会员只能观看30fps的视频,补帧效果可能看不出来。

每个测试用例的首帧图我会放到文章中。

测试用例1:AI生成的简单动画

首先准备测试用例。

我是不知道输入源的哪个因素对两个工具的性能影响最大,所以准备了两个实际素材。

一个素材偏重于更静态的图像,另一个素材则更偏重于运动场景。两个素材均是分辨率 704p 的PNG图像,共 49 帧。

当然我没有用极端测试场景(比如H.264等图形算法最常用的雪花图像,这玩意怎么缩放和补帧?),真实素材也更符合实际日常使用的结果。

输出目标均为:1408p 图像(704p的2倍),121 帧(由24fps插帧到60fps)

AI引擎和模型使用:

  • 放大引擎:realesrgan-ncnn-vulkan-20220424-ubuntu,模型:realesr-animevideov3
  • 插帧引擎:TNTwise-rife-ncnn-vulkan-20240102-frame-count-patch,模型:rife-v4.10_ensembleTrue

补帧和放大均使用目录路径作为输入参数,以排除文件系统调用和模型重复预热引入的性能限制。两个工具也均支持GPU加速所以没有单线程限制(反过来也就是说CPU和GPU在性能统计上会变得乱七八糟而没有参考价值)

存储则使用 ramdisk ,以减少硬盘读写性能的影响。

结果:

偏重静态的图像:

snap-20251022212700_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	0m15.478s
user	0m30.060s
sys	    0m0.874s

这里,如果你没有使用 Linux time 命令的经验的话,我可以简单解释一下:

  • real指的是实际用时,即真实世界时间,和你用秒表测量的数值是一样的
  • user指的是用户态的CPU时间
  • sys指的是内核态CPU时间
  • 在单核单线程硬件下,real=user+sys,但是在多核多线程场景下,每个核的CPU时间都是独立的,所以这个时间统计在现在这个场景下基本没意义。
    (解释并不精确,如果你想深入学习,建议看更详细的资料)

所以在目前这个场景下,我们只关注real这个真实耗时就足够了。

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output

计算 (49 - 1) * 60 / 24 + 1
源帧数: 49
目标帧数: 121

real	0m35.632s
user	1m27.617s
sys	    0m1.462s

放大约15秒,补帧约35秒,总计约50秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

计算 (49 - 1) * 60 / 24 + 1
源帧数: 49
目标帧数: 121

real	0m7.843s
user	0m15.536s
sys 	0m0.707s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	0m36.348s
user	1m14.572s
sys	    0m1.513s

补帧约8秒,放大约36秒,总计约44秒。

结果是 先补帧后放大 优于 先放大后补帧

偏重运动的图像:

snap-20251022214458_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	0m16.676s
user	0m30.713s
sys	    0m1.277s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output

real	0m36.721s
user	1m33.545s
sys 	0m1.513s

放大约16秒,补帧约36秒,总计约52秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m9.753s
user	0m20.995s
sys	    0m0.850s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-out/ -v

real	0m37.459s
user	1m16.351s
sys	    0m2.180s

补帧约10秒,放大约38秒,总计约48秒。

结论是:

  • 高动态的图像的确为插帧带来了更多压力
  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

很奇妙的是不论先后顺序,第二步的耗时都差不多。


测试用例2:AI生成的长动画

实际只测试两秒钟(49帧-121帧),打算再测一个输入时长更长的,看看能不能把性能差距拉得更开。

同样是两组,一组偏静态,另一组偏动态。

这回输入均为10秒钟24fps,241帧。目标仍是 60fps,601帧。

(注:这所谓的10秒其实是两个5秒钟视频贴在一起的,第一个视频使用即梦生成,首尾帧相同。第二个视频使用豆包生成,根据关键字调整了动作幅度)

结果:

偏重静态的图像:

snap-20251024222139_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m9.580s
user	2m21.161s
sys	    0m3.010s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

计算 (241 - 1) * 60 / 24 + 1
源帧数: 241
目标帧数: 601

real	2m45.014s
user	7m9.693s
sys 	0m3.845s

放大约70秒,补帧约165秒,总计约235秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m33.821s
user	1m11.185s
sys	    0m1.258s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m52.675s
user	5m57.794s
sys	    0m8.370s

补帧约34秒,放大约173秒,总计约207秒。

偏重动态的图像:

snap-20251024221945_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m10.573s
user	2m24.758s
sys	    0m2.371s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

real	2m49.481s
user	7m27.740s
sys	    0m4.279s

放大约70秒,补帧约170秒,总计约240秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m39.217s
user	1m32.454s
sys 	0m1.594s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	3m0.312s
user	6m19.679s
sys	    0m5.674s

补帧约40秒,放大约180秒,总计约220秒。

结论是:

  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

测试用例3:AI生成的现实场景视频

这里得偷懒了。缩放工具 realesrgan 本身的默认模型 realesrgan-x4plus 对现实场景的缩放效果更好,但是其仅支持4的整数倍缩放,在现在这个场景下比较浪费。
同样 rife 这边也有更适合现实场景的补帧模型,但我也打算偷懒。

所以模型将仍然使用 realesr-animevideov3 和 rife-v4.10_ensembleTrue 。

视频输入样本,偏静态样本仍为即梦5秒+豆包5秒,但偏动态样本这回使用即梦生成的10秒,因为偏动态的内容,现实场景首尾帧相同实在太诡异了,而且即梦和豆包生成奔跑内容的视频效果非常差,经常就变成单腿跳。

结果:

偏重静态的图像:

snap-20251105235631_nowatermark

time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m9.756s
user	2m22.813s
sys 	0m2.415s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

real	2m49.322s
user	7m21.308s
sys	    0m3.992s

放大约70秒,补帧约170秒,总计约240秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m37.079s
user	1m27.702s
sys	    0m1.498s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m51.899s
user	6m0.976s
sys	    0m4.820s

补帧约37秒,放大约171秒,总计约208秒。

偏重动态的图像:

snap-2025-11-08-9101

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m10.753s
user	2m24.943s
sys	    0m2.365s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

real	2m49.142s
user	7m16.057s
sys	    0m3.969s

放大约70秒,补帧约170秒,总计约240秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m38.306s
user	1m29.791s
sys	    0m1.516s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m49.268s
user	5m55.462s
sys	    0m4.760s

补帧约39秒,放大约170秒,总计约209秒。

结论是:

  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

测试用例4:真实现实场景视频

这个源不太好找,现在手里没有24fps的摄像机这玩意,目前常见的摄像设备都是30fps,60fps,120fps,240fps,960fps的。

所以这里将测试用例调整一下。

首先,源视频是拍摄的一段1080p60fps的视频,再缩小成704×1252,再把1252剪成1248。

然后分为两个策略:

  1. 去掉所有偶数帧,这样源就变成30fps了。虽然当然也可以直接拍30fps的视频,但有个补帧缩放后有个对比也算不错。
  2. 使用比较主流的减帧策略(丢弃每5帧中的第2、3、5帧),将60fps视频减至24fps。

(当然像OpenCamera这种App也支持拍摄24fps视频,但是场景过于小众了)

这样做的目的是:rife 的非整数倍补帧, 24补到60是2.5倍,只有奇数帧会被保留,偶数帧在算法里被用掉之后就被丢弃了。

相关日志:

/tmp/ramdisk/rife-tmp//0-000001.png /tmp/ramdisk/rife-tmp//0-000002.png 0.000000 -> /tmp/ramdisk/rife-output//00000001.png done
/tmp/ramdisk/rife-tmp//0-000001.png /tmp/ramdisk/rife-tmp//0-000002.png 0.400000 -> /tmp/ramdisk/rife-output//00000002.png done
/tmp/ramdisk/rife-tmp//0-000001.png /tmp/ramdisk/rife-tmp//0-000002.png 0.800000 -> /tmp/ramdisk/rife-output//00000003.png done
/tmp/ramdisk/rife-tmp//0-000002.png /tmp/ramdisk/rife-tmp//0-000003.png 0.200000 -> /tmp/ramdisk/rife-output//00000004.png done
/tmp/ramdisk/rife-tmp//0-000003.png /tmp/ramdisk/rife-tmp//0-000004.png 0.000000 -> /tmp/ramdisk/rife-output//00000006.png done
/tmp/ramdisk/rife-tmp//0-000002.png /tmp/ramdisk/rife-tmp//0-000003.png 0.600000 -> /tmp/ramdisk/rife-output//00000005.png done
/tmp/ramdisk/rife-tmp//0-000003.png /tmp/ramdisk/rife-tmp//0-000004.png 0.400000 -> /tmp/ramdisk/rife-output//00000007.png done
/tmp/ramdisk/rife-tmp//0-000003.png /tmp/ramdisk/rife-tmp//0-000004.png 0.800000 -> /tmp/ramdisk/rife-output//00000008.png done
/tmp/ramdisk/rife-tmp//0-000004.png /tmp/ramdisk/rife-tmp//0-000005.png 0.200000 -> /tmp/ramdisk/rife-output//00000009.png done
/tmp/ramdisk/rife-tmp//0-000005.png /tmp/ramdisk/rife-tmp//0-000006.png 0.000000 -> /tmp/ramdisk/rife-output//00000011.png done
/tmp/ramdisk/rife-tmp//0-000004.png /tmp/ramdisk/rife-tmp//0-000005.png 0.600000 -> /tmp/ramdisk/rife-output//00000010.png done
/tmp/ramdisk/rife-tmp//0-000005.png /tmp/ramdisk/rife-tmp//0-000006.png 0.400000 -> /tmp/ramdisk/rife-output//00000012.png done

所以这次测试用例是:

  • (类)原生30帧补到60帧
  • (由2:3策略减帧的)24帧补到60帧

模型也同样使用 realesr-animevideov3 和 rife-v4.10_ensembleTrue 。

偏静态与偏动态不做区分了,本身真实场景,除非是使用三脚架固定相机拍摄,否则也没啥偏静态的场景,大多数都是动态且镜头抖动巨大,个人拍摄的内容还有严重的低光照问题。

(说白了还不是因为根本没有可用的视频素材)

结果:

snap-2676

30帧补到60帧

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m24.551s
user	2m57.076s
sys	    0m2.912s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

计算 (301 - 1) * 60 / 30 + 1
源帧数: 301
目标帧数: 601

real	2m43.455s
user	7m6.708s
sys 	0m3.595s

放大约85秒,补帧约164秒,总计约249秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m43.132s
user	1m52.735s
sys	    0m1.387s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m48.691s
user	5m56.668s
sys	    0m5.217s

补帧约43秒,放大约169秒,总计约209秒。

24帧补到60帧

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m7.531s
user	2m21.199s
sys	    0m2.532s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/


计算 (241 - 1) * 60 / 24 + 1
源帧数: 241
目标帧数: 601

real	2m45.471s
user	7m11.694s
sys	    0m4.140s

放大约68秒,补帧约165秒,总计约233秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m42.656s
user	1m52.408s
sys	    0m1.312s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m46.998s
user	5m53.404s
sys	    0m5.189s

补帧约42秒,放大约167秒,总计约209秒。

结论是:

  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

测试总结

  • 所有测试用例的场景下,先补帧后放大的总耗时 总是小于 先放大后补帧的总耗时

相关视频

【AI工具研究之:先放大还是先补帧】 https://www.bilibili.com/video/BV1yoCtBFE1L/?share_source=copy_web&vd_source=bc6d7e4cd2c1f2bba38d19773d2bc1fc


结尾

这几组测试用例其实都不严谨,没有参考官方的建议在不同场景下使用不同模型,而且因为这是我的个人电脑,里面跑的乱七八糟东西特别多,CPU和GPU在跑用例的时候偶尔也会被其他应用调用,所以每次跑的时候精度都一般,误差很大。我本来也只是跑着玩的,根本没多次测试然后取平均值。好孩子不要学。

本次测试结果仅代表两个工具以及对应模型在本人主机硬件环境上的性能测试结果,不对其在其他场景下的性能负责。请勿将本文中的结论用于生产环境。

The post 先补帧还是先放大 first appeared on 石樱灯笼博客.
  •  

尝试把树莓派1和小米盒子1改造成游戏机,但是失败了

本文大概只是想讲讲我手中这块树莓派1B的使用经历。小米盒子1只是附带。


我玩树莓派那些事

我2013年的时候买了一块树莓派1B的板子。那时候我只有一台2007年买的奔腾T2130的笔记本,跑虚拟机比较吃力,而且由于是定制显卡所以Linux装上后显卡驱动不起来,这些问题导致没法在家(北京的出租房)用Linux。想要用Linux就只能在公司用公司的服务器。而且由于公司的系统是一个高度魔改的CentOS,公司改了相当大量的内核代码并且安装了大量跨版本的依赖包,只能用来学习Linux基础,嘛毕竟是2004年成立的公司,产品严重依赖Linux内核功能所以就只能一直往里面Merge最新功能,直到后来实在是塞不进去了,全部推倒了从新发布的CentOS7重新搞。

当时树莓派也不贵,就买了一块。说实话没怎么用。因为我没买任何外设,所以所有功能都是纯跑在CPU上的,32位的arm 700Mhz性能基本上只能验证功能上的可行性,一点性能都没有。

screenshot_on_b85m_by_flameshot_at_2025-10-17_19-17-39

IMG_3336

IMG_3337

IMG_3338

IMG_3339

IMG_3342

IMG_3344

IMG_3345

IMG_3346

IMG_3347

IMG_3348

IMG_3349

IMG_3350

(当然,想学 Linux 这个是借口)

当时手中还有个大学时买的罗技C270摄像头(15年了,这玩意到现在还没停产),能拍720p。刚巧当时出租房和公司都用的电信通/宽带通的网络,开DDNS可以用(不知真假的)公网IP互联。在公司摸鱼的时候就用SSH连上家里的树莓派,然后再开小飞机做代理就能完全访问家里的局域网(公司是有上网审计的,但公司主营业务之一也是上网审计,只要不干违法的事情且不影响公司其他同事上网就没问题)

IMG_4279

连上后瞎搞mjpg-streamer,当时调通后拿到的第一张照片刚好是放在窗台上对着窗外拍到的一位路过的美女。(然而当时的照片已经找不到了)

对应 mjpg-streamer 的内容可以参考十多年前的这篇老文章《使用树莓派制作近距离遥控摄像机(无线网卡+摄像头,手机或平板等移动终端控制)》,不过放在现在已经没什么参考意义了。

后来还把树莓派和移动电源和摄像头还有无线网卡组合到一起,把摄像头绑在书包后面,骑自行车上班时拍了一路。

【[远古画质] 北京,2013年某月】 https://www.bilibili.com/video/BV1U9W7zkEm4/?share_source=copy_web&vd_source=bc6d7e4cd2c1f2bba38d19773d2bc1fc

(请忽视评论区那些自嗨的精神病)

当年我还对视频编码什么的一无所知,就只留下了这么一个编码格式是H.262的远古画质的视频。

当时想调通这一套可是费劲。没有接入点的情况下,想把控制终端和树莓派连起来就很麻烦。而且树莓派的电路设计一直超级缺心眼,它的供电设计,一直没有优先保障主板,且USB接口一直有反相供电的问题。插拔USB设备造成的电压波动基本上100%会导致树莓派重启。输入电流也被压在500mA(201x年USB供电基本都是1A了),这就导致像无线网卡或摄像头这些用电大户(?)在工作的时候可能导致树莓派自己供电不足而重启。

为此专门买了一个同时有外置电源和反相供电屏蔽的USB Hub。这玩意可是非常稀有了。

screenshot_on_b85m_by_flameshot_at_2025-10-17_19-38-29

IMG_6866

用这玩意也就意味着没法插着移动电源用。

IMG_20140503_001825

2013年去广西出差的时候,带的公司的笔记本,散热风扇坏掉了。干活办公开SSH和Word/Excel没事,但是玩游戏或者看视频几分钟就直接蓝屏重启。恰巧客户那边网络炸了,所以一个星期我都只能在酒店发呆。当时就带着树莓派,装了个 OpenELEC 系统,用酒店的电视把《刀剑神域1》全看完了。

DSC_0195

DSC_0202

(之所以是 OpenELEC 是因为,Raspbian系统需要4GB SD卡,而3DS原装的SD卡是2GB的,落灰中。而 OpenELEC 只需要 2GB 的空间就可以安装。当然另一个理由是 Raspbian 图形界面实在太卡)

当时还买过一张跳舞毯。厂家给的光盘当然只包含一个 Windows 32位的游戏端,实际上就是个 Stepmania 汉化版。Stepmania本身是开源的,但是当时官方也只提供 64位 的 Linux 客户端。我当时对交叉编译一无所知,完全搞不懂,就只好把源码都复制到树莓派上然后直接在上面编译,结果编译了一个通宵,第二天早上屏幕上还在滚屏编译,实在是等不起,这性能可能就算跑起来了也够呛能运行(更别提还要跑在图形界面上),就放弃了。(后来在x86的Linux笔记本上编译,没报错直接成功编译并且成功运行,所以说代码里并没有int64这种必须用64位CPU才能编译运行的代码)

screenshot_on_b85m_by_flameshot_at_2025-10-18_01-05-57

再后来配套的亚克力板磕坏了,想要再买发现买不到了,网上只有B+外形的外壳了(后续的树莓派外壳基本也都是B+的)。我最后就只能用个饼干盒子套着用。就开始落灰。

IMG_20150512_152030_hongmi1

IMG_20150512_152103_hongmi1

IMG_20150725_110321_hongmi1

再再后来换了工作,我拿着树莓派当作一个远程控制设备插在公司服务器上当远程控制,即我远程登录到树莓派上模拟用户操作,这样我就不用蹲在服务器旁边干活了。结果老总为了要用墙壁上的电源插座给手机充电,直接把树莓派拔下来扔杂物堆里了。

(除非你已经为领导创造过巨大的收益,否则任何领导没见识过的努力都是狗屎)

再再再后来又换公司,公司搞高度网络劫持,然而用的是一个及其白痴的上网审计,导致大部分HTTP网站都访问不了,那时候HTTPS还没普及,导致想在网上搜资料就只能手机开热点,搜完了再切回公司网络。于是又翻出来插在出租房的联通宽带上,当时还有公网IP,在浏览器里写好规则,在公司翻到家里上网。尤其是那个白痴上网审计只会疯狂的主动探测端口的HTTP协议,小飞机的日志里全是主动探测告警,我还得专门安装个旧版的不会自动封禁主动探测的小飞机。

后来还买过扩展版和传感器模块(温度气压高度光线,但是没有湿度)。没学的时候觉得是魔法,树莓派社区吹得及其玄幻,学会后发现就是从对应API读数据,而且因为都是用Python写的,代码质量还稀烂,所以被社区吹得越来越玄乎。当时我还没转型做开发,没搞明白PHP怎么去抠系统级的API(事实上读不了,PHP-FPM不是干这个的,PHP-CLI又不是跑在Web上的,想以正经方式拿系统信息还是得走系统指令,那就和调用Python没区别了),且想在树莓派1上跑HTTP服务非常吃力,就更别提还没火起来的NodeJS了。实际上这屁事只用Bash应该就能做,只要能处理好从API中提取出来的二进制数据然后转换成人类可读的数据,然后再排版就好了。当然,Bash处理二进制数据和排版都超级麻烦,理所当然社区没人做。去他妈的国内开源社区

IMG_20151019_225300_MiPad

IMG_20151025_002219_MiPad

IMG_20151223_221943

IMG_20171030_192817

后来还买过 315M433M无线模块,想用树莓派做物联网。但是最后因为精力有限,买回来之后一直在落灰,一点都没动过。(后来物联网的发展趋势也是一坨狗屎,一帮傻逼搞紫蜂全死了,最后变成WiFi是亲爹,断网就报废,电饭锅都物联网人工智能)

screenshot_on_b85m_by_flameshot_at_2025-10-18_01-05-26

IMG_20151103_233125

再再再后来我也不在那个公司工作了,北京联通也不再分配公网IP了,手里这个树莓派又开始落灰。我也想过再利用,尝试把这树莓派做成同步网盘(大容量SD卡和U盘已经很便宜了),但是这设备的IO性能是在不够,虽然可以插外置硬盘,但兼容一代的硬盘盒也不存在,更别提之前说过跑Apache和PHP都很吃力了。

最后这树莓派1就正式落灰了。


年轻的时候憋坏了

我这个人,上学的时候憋坏了。早年间上大学从哈尔滨到西安,火车单程42个小时,后来提速后36个小时,但晚点又是日常。当年最多只能用个不到2寸的诺基亚3110c玩马里奥医生,因为屏幕小且九宫格键盘难操作且模拟器限制,只能玩这一个游戏,其他游戏都玩不了。(我也纳闷这大学4年我为什么不买一个俄罗斯方块机呢)

毕业工作后我就买了台3DS,买了两块移动电源。

后来买了台式机之后,老笔记本也开始落灰,我就装了个RetroArch又当作游戏机,在有大电视的合租房客厅里放了一年。结果是没玩,HDMI线超过2米之后要不就是价格登月,要不就是直接花屏。

IMG_20160124_160039_SHOT2SHOT1

而作为控制器的手柄,USB连接线同样没法超过两米;蓝牙又莫名其妙的高延迟。总之怎么样姿势都不舒服。

再后来有了新笔记本(就是那个后来自燃了的戴尔灵越7380),PS2模拟器的性能甚至比有GTX1080独显的台式机还好,经典掉帧场景在这个核显笔记本上竟可以全程60帧。虽然有着8代i7,但跑分和x264这笔记本(都因为散热问题)输给4代i7的,却在这个特别的场景下略微获胜(但是屁用没有,过场动画掉几帧根本不影响游戏性)(更别提Win10会给更低端的模拟器造成明显抽搐的问题,而且3DS模拟器在4代U上能稳定跑,在这破本上启动都费劲)。但最终结果也是一样的,一根又粗又硬的HDMI线扯着笔记本,笔记本还要再插着电源适配器,然后一根USB线连在手柄上,怎么样都不舒服。再再后来这破笔记本自燃了,这场景也自然没有了。

(所以我还是觉得,同样都是走2.4GHz频段,在无线键鼠和蓝牙手柄都出问题的情况下,游戏机无线手柄能做到延迟无感知是一种魔法。当然我也没钱去专门买一个无线手柄适配器,毕竟不适应需求,PC游戏还是坐在电脑显示器前玩,不需要无线)


煎熬后想把树莓派1改造成游戏机

前几年过春节都是在自己家熬夜的,用自己的电脑打一宿的TF2或者100oj。

去年在外公家过夜,但是下午的时候回家了一趟,然后晚上徒步走了3公里到街机厅,玩跳舞机一直玩到人家除夕闭店。

今年过春节时,则是在一个我不怎么熟的大人的朋友家过的。

纯煎熬。

能玩的东西就只有手机和3DS。

倒不是说3DS游戏性不行,而是我在嘈杂且陌生且随时会被打断的环境下,玩不下去那种期望有沉浸体验的游戏。

结果就是一个除夕,歪坐在一个陌生的沙发上,把魔法气泡手游的无尽之塔打到实在打不过,然后又在3DS上打了半宿的PPT(魔法气泡俄罗斯方块),最后结果是坐着落枕了。

邻居家当然是有电脑和电视的,只不过电脑是人家工作用的,别人的工作设备我基本不想碰;电视全是在播放春晚,根本看不得。

那一晚真的是纯煎熬。好在第二天大人们晚上全跑去歌厅唱歌了,我自己回了自己家,才算解脱。

再后来整理物品的时候又翻到箱子里落灰很多年的树莓派1和小米盒子1(还有2台小霸王),遂有了把这俩玩意改造成游戏机的想法。

两台小霸王机当然也是能用的,我还有一张400合1游戏不重复的游戏卡,基本上涵盖所有热门FC游戏。但这些年来我一直是在NTSC模式下以60fps的帧率玩FC的,如今再回到PAL模式的50fps,就显得特别的不适应。

为什么自己年轻的时候没感受到这么大的差异呢,我高中期间是同时玩模拟器和小霸王的啊。


把树莓派1改造成游戏机,但是失败了

思路有多个:

  • 安装个有图形界面的操作系统(Raspbian),然后在里面跑独立模拟器或者RetroArch。
  • 安装 OpenELEC ,然后在里面的 XBMC中 安装模拟器插件
  • 安装 Lakka 或 RetroPie 这种专门(只)跑 RetroArch 的操作系统

首先抛弃方法2。这个方法本来是我道听途说的,真实性不高。OpenELEC 已经停止维护太久了,XBMC也早就改名 Kodi。如今肯定是连不上那古董的插件服务器,就不费那劲了。

事实上现在想在网上搜树莓派1的资料已经很少了,就更别提树莓派基金会搞了一堆幺蛾子之后名声都臭掉了,现在还做树莓派资料的基本都是 外国营销号,没啥正经玩意,搜什么关键字都是一群人复制粘贴的垃圾(有一种百度比谷歌遥遥垃圾的领先感)。本身就追求开放的老粉肯定不会在这一根歪脖树上吊死,直接去 Linux on Arm 这种大领域玩去了。

用了几个AI工具搜了一下(百度、豆包、必应、秘塔,排名不分先后),基本上给出的答案都类似:

screenshot_on_b85m_by_flameshot_at_2025-10-17_21-58-02

screenshot_on_b85m_by_flameshot_at_2025-10-17_22-35-22

看起来还行?

Raspbian 方案

首先刷了 Raspbian 试了下。甭说模拟器了,只要进图形界面,分分钟整个系统卡到无响应。我专门是了下最新版的 Raspbian 和 自己电脑里保存的 2013 年的旧版 Raspbian ,结果是一样的。

这个配置跑一个图形界面操作系统实在是太勉强了,再在上面跑其他东西,还是算了。

RetroPie 和 Lakka

这俩方案我已经记不清前后顺序了。记忆里2013年的时候用过其中一个(另一个当时肯定没诞生),只记得当时那个很漂亮的仿PS3/PSP的系统界面(因为邻居家有台PS3)。

现在在装回来,只感觉到莫名其妙的超级卡顿。

RetroPie 方案

其中 RetroPie 又叫 EmulationStation ,看着很像是对 RetroArch 的重度套皮。不仅如此,所有对非模拟器的设置,全部都会先退出这个图形界面,然后调用Raspbian提供命令行风格的配置界面,配置完成后再重新启动 EmulationStation。这一套白痴操作下来,整个系统直接就炸了。

DSC_8108

屎山设计。

Lakka 方案

Lakka 则简介多了,看介绍,Lakka应该是直接把 OpenELEC 减掉大部分功能,只保留图形功能支持,然后在里面启动 RetroArch。

和 RetroPie 不同。RetroPie 是做加法,屎山;Lakka 是做减法,仅保留需要的内容。

缺点就是需要基于RetroArch之外的第三方功能基本没戏(但是把Samba这种功能塞进RetroArch是有可能的)。

Lakka跑起来后,首先是着跑 FC/NES,结果是卡顿得不行。

除了QuickNES核心之外,其他模拟器核心都是卡到爆炸,60fps最多只能跑到一半,30帧。

DSC_8111

这跟AI给出的答案完全对不上。还 SFC/SNES呢,连 FC/NES 都不行

试着给树莓派超频,结果是只要动树莓派的频率设置,就完全不启动。超频失败

最后勉强用 QuickNES 跑起来松鼠大战1,能将就着维持到60fps。

把耳机接上显示器/树莓派之后,又发现根本没声音,看了一眼,发现音频输出是null。手动把音频输出更改为 HDMI 或者 3.5mm 之后,游戏瞬间又卡得没法玩了。

RetroArch 的小插曲

当年在树莓派上跑RetroArch,也是我第一次RetroArch这个应用的渠道。

后来也想过在旧笔记本上安装这个操作系统,但是旧笔记本的性能可以跑Ubuntu这种功能正规操作系统,性能都绰绰有余,没必要专门安装专用操作系统,直接再在Ubuntu上安装RetroArch就好了,但是玩瘾没那么大,想玩直接上台式机,旧笔记本大部分时间在落灰。

再后来把整体操作系统环境从Win7迁移到LinuxMint时,在笔记本上使用过一阵RetroArch,结论是: RetroArch安装在专门用于游戏的机器上,或者给无经验者作为综合模拟器使用,用户体验还行;但是对于有经验的用户,在PC上使用窗口环境的模拟器的用户体验更棒。

于是之后再也没用过 RetroArch 玩游戏。

OpenELEC

本来没指望再用 OpenELEC 的,但是心理很别扭,总觉得以前不是这样的。

把 OpenELEC 重刷进去,发觉连操作菜单都卡顿得不得了。每个选择操作都能卡顿1秒以上。

啥情况?CPU缩肛了?

按理说菜单这些内容都是加载到内存的,就算SD卡因为放置太久有IO性能问题了,也不至于影响到菜单操作。

选了个 H.264的视频,播放起来倒是很顺畅,但我又用不着这玩意看视频。(尤其是现在大部分视频都是Webrip或Web-DL的,都需要手动选字幕,旧版的OpenELEC字幕能力太弱了,更别说操作还这么卡顿)

DSC_8112

DSC_8113

我电脑里当然是存着2013年的 旧版 OpenELEC 的。

刷了当初的旧版,依旧的性能问题。

看来树莓派是指望不上了。

想当年家里亲戚有过一台从单位搬回家的1988年产的 COMPAQ 486,只有486MHz主频和16MB内存(MMX指令集都没有),在DOS下用Nesticle模拟器也是能玩大部分NES游戏的(只要Mapper支持就行)(在Win95下开声音会掉帧)。

(暂时不想为了验证是否是SD卡的问题再买新的SD卡。手里的旧卡都一堆了,线上在用的只剩下3DS的卡和一个相机的卡,也都是偶尔开机)

(事实上固态存储长期不通电不擦除不读写导致性能下降的问题目前很严重且无解。PC端的冷数据还是用机械硬盘或者光盘存储更安全,SSD只适合做系统盘。但是这个情况在移动设备和移动存储上怎么做都绕不开)


小米盒子1

与树莓派1装在一个袋子里的还有个小米盒子1。

IMG_6867

IMG_6871

IMG_6876

话说小米这破品牌,当年我竟然还因为他曾把一个停产的产品在网站上多放了几个月页面,就夸了一下,当时绝对是脑子没有被门挤出屎。

(都是年轻时犯下的错)

小米盒子1这玩意,配置可比树莓派高太多了。

screenshot_on_b85m_by_flameshot_at_2025-10-17_22-04-44

(纸面参数甚至比我的旧笔记本还高)(但是别忘了这破玩意是精简指令集)

于是也想拿出来试一试。

思路很简单:小米盒子1内置的是魔改的安卓4.4系统,所以只要:

  • 安装安卓版本的 RetroArch 或其他模拟器
  • 使用任何可行办法将游戏ROM复制到小米盒子中,或使用USB OTG访问U盘
  • 使用内置蓝牙模块与PS4手柄DS4配对连接,或使用 USB OTG 有线连接PS4的DS4手柄

首先用遥控器把小米盒子1重置到出厂状态,然后连网,希望通过网络把文件复制到小米盒子中。

结果,只要一连网,小米盒子1就炸了。整个操作界面强制更新到了一个作坊风格的净是推广内容的界面,所有功能入口都没有了。用文件管理器,所有APK文件均被提示禁止安装。

DSC_8106

没办法只能用遥控器重新重置。

这回用USB OTG插U盘把好用的文件管理器和RetorArch安装包复制到小米盒子上,然后安装。

然后尝试连网,期望通过自己安装的文件管理器把游戏ROM复制到小米盒子上。

(之所以一直要连网,是因为 RetroArch 默认不带任何模拟器核心,需要连网才能下载对应的模拟器核心才能运行)

结果连网之后,不仅界面炸回山寨风格,而且隐藏了所有应用的入口,刚才安装的文件管理器和RetroArch在界面看不到了,完全被隐藏。

没办法只能再次用遥控器重新重置。

这回决定完全不连网,RetroArch的问题先搁置,大不了等会在路由器把抓包把小米盒子的所有网络请求全封掉,只放行 RetroArch 的请求。或者干脆不用 RetorArch,使用其他独立模拟器。

然后尝试用小米盒子的蓝牙配对手柄或者键盘,结果是:小米盒子除非小米自己品牌的外设之外,其余任何设备都不识别。

最后直接把手柄插在USB OTG上,依旧不识别。

封闭的垃圾!!!


开放的东西越来越封闭

本身表面上树莓派这玩意是个很新奇很开放的东西,但是实际上树莓派基金会是由博通建立的,芯片也是一直用的博通最便宜的垃圾。本身博通这公司有多烂就不用解释了。

只是没想到 卡片电脑 这个概念能在那个时间段突然爆发。之后树莓派除了换了几代SoC之外基本没任何改良,但由于名声在外,其他同类型产品都没能撼动这个破烂的地位。

然而树莓派5登场后,卡片电脑这个概念终于或许是大抵确实是好像死了。

天下苦 Intel x86 久已,但 arm 却不是来拯救大家的。

很可惜资本主义下,开放指令集根本没法发展。

没钱寸步难行。

而像小米之流的更是打着开放的名义把用户当牲口,成功培养出了很大一批的“有问题就刷机”但实际上只会在特定网站上下载自己都不知道里面是啥玩意的东西往手机里装的年轻韭菜。自由即吃饲料,自由即当牲口。

vlcsnap-2025-10-18-01h22m50s403

vlcsnap-2025-10-18-01h25m28s409

看手里一堆一堆的塑料电子垃圾,最后的结局都是换个5块钱的不锈钢铁盆。

“我们”是商品。

The post 尝试把树莓派1和小米盒子1改造成游戏机,但是失败了 first appeared on 石樱灯笼博客.
  •  

Forgejo及其Action自部署简明教程

前几天刚搭好了自己的 Forgejo 私有 Git 服务,之后出去玩了几天一直没动它。正好有朋友问起如何部署 Forgejo 及其 Actions 支持,发现网上相关资料不多。最近天气炎热,我也正宅在家,就抽空整理了这篇部署教程,希望能帮到有同样需求的你!

  •