利用Real-ESRGAN修复制作高清版国产经典动画《大闹天宫》

  之前和儿子看了几次西游记的舞台剧,为了让他对故事的来龙去脉有更完整的印象,答应了和他一起看孙悟空动画片。当然不是白龙马,蹄朝西,而是更久远的 1961 年首映的国产动画《大闹天宫》,至少那时的动画是真的为了做好动画,没有商业目的,看完即走不卖周边可以放心食用。找到了 [大闹天宫(影迷修复版)].The.Monkey.King.(Fan.Restored.Edition).1965.DVDRip.x264.AC3-CMCT.mkv (1.46GB) ,虽然已经是修复版,但画质仍然是比较感人。于是自己也有了这次动画的修复经历。   修复使用的是 Real-ESRGAN 这个库,它基于 PyTorch 实现,用于对图像进行超分辨率成像 (super-resolution) 。根据作者 xinntao 的介绍, Real-ESRGAN 的目标是开发出实用的图像/视频修复算法。我们在 ESRGAN 的基础上使用纯合成的数据来进行训练,以使其能被应用于实际的图片修复的场景(顾名思义:Real-ESRGAN)。   ESRGAN 的作者也是同一人,属于自我进化了。另外作者还提供了论文和详细的 PPT 介绍。这次我用到的是专门针对动漫视频制作了模型的 RealESRGAN AnimeVideo-v3 ,介绍页面中作者已经提供了编译好的各平台可执行文件以及使用步骤,此处就不重复粘贴具体命令了,只对大致过程和遇到的问题说明一下。   从超分辨率成像的描述可以看出,Real-ESRGAN 的核心是对图像进行“修复”。那么对视频文件如何处理呢?思路和把大象关进冰箱是一样的,总共分三步: 利用 FFmpeg 把视频中的每一帧图像都抽取出来,类似把视频解压缩成图像。开头提到的《大闹天宫》视频变成了 170,977 张 720*512 的图片文件,总大小 14.33GB。 使用编译好的可执行文件 realesrgan-ncnn-vulkan 对每帧图片进行增强。我选择的是默认 2 倍分辨率,于是得到了同样数量的 1440*1024 的图片文件,总大小 171.79GB。 利用 FFmpeg 把增强后的图像文件合并成视频文件,类似把图片打包成视频。最后修复好的两倍分辨率高清版视频是 2.42GB,libx264 编码格式。这里要注意两点: 把图像打包成视频,要使用原始视频文件的fps,即每秒的帧数,也是利用FFmpeg的到。开头提到的《大闹天宫》是25 fps,由此也能推断出视频长度是 170977/25/60≈114分钟。 常见的 mp4 格式只支持 hard subtitles (硬字幕,也等于不支持字幕),也就是把字幕直接合并到每帧图像上,播放时就不能开关或切换字幕了。所以此处我选用了 mkv 格式,一并把原来的简体和繁体中文两种字幕拷贝到了新的视频中,播放时可以按需切换或关闭。具体命令是 ffmpeg -i out_frames/frame%08d.jpg -i dntg.mkv … Continue reading 利用Real-ESRGAN修复制作高清版国产经典动画《大闹天宫》 »

通过威联通NAS上的WireGuard VPN连接回家里的网络环境

  以前在外访问家里NAS内容时,都是通过路由器上的端口转发,登陆NAS管理页面。这样做一是有一定安全隐患,二是所有内容都在NAS管理网页这个”沙盒“里,无法通过本地应用直接访问。比如听歌,要么用NAS自带的网页播放器,要么需要先把歌曲文件下载到本地。最近趁618低价,新添了 QNAP 威联通 NAS TS-464C,今年的网红N5105 CPU配上32G内存(虽然官方硬件规格说最大支持16G内存),足足比14年使用至今的QNAP 212P的512M内存大了64倍……212P虽慢但稳定异常,目前依旧继续服役稳定输出。   解决上面提到的安全和内容访问问题,标准答案就是VPN,连通后无论身处何地,你的设备就像连到家中的WIFI一样。目前QANP的操作系统QTS 5.0自带了QVPN Service 3软件,内建提供QBelt(QNAP自家标准),PPTP,L2TP/IPSet(PSK),OpenVPN,WireGuard共5种VPN服务。参考NordVPN和QNAP自家页面,Wire Guard在安全性和传输速度方面表现都相对更好。 VPN protocol Speed Encryption Streaming Stability P2P OpenVPN Fast Very good Good Good Good IPSec/IKEv2 Fast Good Good Very good Good Wireguard Very fast Very good Good Very good Good SSTP Medium Good Medium Medium Good L2TP/IPSec Medium Medium Poor Good Poor PPTP Fast Poor Poor Good Poor VPN协议比较   于是这次就用QVPN Service搭建WireGuard VPN服务。具体步骤此处省略,可参考QNAP官方文档:How to … Continue reading 通过威联通NAS上的WireGuard VPN连接回家里的网络环境 »

Nintendo Switch借助macOS升级TF卡

这两天黑五打折,买了三个游戏后发现最初128GB的存储卡已经消耗殆尽,但去年21块人民币买入31.5GB的NBA2K19依然还没有下载。。。于是购入一张256GB的卡准备升级一下。 在确认游戏存档全部保存在主机上(无法转移)之后,看到大致步骤是先把新卡插入机器格式化,之后通过电脑把旧卡的所有文件复制粘贴覆盖到新卡上。于是一番操作之后插入拷贝好的新卡到机器里,开机:提示无法识别存储卡。复制之后还专门确认了新旧两张卡存储占用的字节数都是一样的……搜索之后发现类似的情况中文内容鲜有提及,只有bilibili的DioTV上这条视频里提到macOS上如此操作无法成功。之后还看到了Reddit上的这个帖子 Save you time: Copying SD card on Mac does NOT work ,心想这老任也抠得太紧了吧。 最后找到了 How to Transfer Data Between Nintendo Switch microSD Cards with OS-X 里面提到的办法,操作之后确认有效。 1. 旧卡插入mac,执行下面命令: mkdir ~/Desktop/sdcard cp -r /Volumes/Untitled/Nintendo ~/Desktop/sdcard2. 新卡插入Switch,格式化。3. 新卡取出插入电脑,执行下面命令: cp -r ~/Desktop/sdcard/Nintendo/* /Volumes/Untitled/Nintendo4. 拷贝完毕后新卡插入Switch,开机 这下Switch可以正确识别新的存储卡了,并且之前下载的游戏也能正常运行。可出现了新的问题:无法保存截图。试了一下,如果截图存储位置设置为SD卡,则截图后左上角提示“无法保存”,如果截图存储位置设置为主机内存则一切正常。同样中文内容只搜到了这篇:NS数据转移到新SD卡后无法截图! ,但暂时没有解决。最后在Reddit上找到了解决办法 Can’t save screenshots to the SD card after upgrading to a new card? I think a found a fix that doesn’t … Continue reading Nintendo Switch借助macOS升级TF卡 »

几种需要内网穿透情况下Windows远程桌面的方案

要解决一个比较典型的需求:在家里的时候需要远程桌面到办公室的电脑做一些操作,最大问题是办公室的机器在局域网内没有公网IP,所以不能直接使用远程桌面工具连接。想要完成这个任务核心是需要进行所谓的内网穿透,之后就可以选择自己熟悉的远程桌面工具操作了。这里介绍几种我使用过的办法,供有需要的朋友参考。 * 如果你需要操作的是一台内网Linux机器,也可以参考之前的这篇《从Internet访问没有外网ip的NAS服务器的解决办法》。   方案一 TeamViewer TeamViewer是一款简单好用的工具,不仅允许个人用户免费使用,还支持多平台下机器相互连接,比如可以从Android手机或macOS电脑远程到Windows电脑。只要两台电脑都安装了该软件,便可直接相互远程桌面,内网问题完全透明,操作速度也完全可以接受。不过使用一段时间后,被提示有可能是商业用途使用,也考虑过付费购买,但单个用户49刀/月的价格对于偶尔使用来说确实比较贵。于是就转到了第二个方案。   方案二 ZeroTier ZeroTier也是一款可以直接安装使用的工具,相比TeamViewer的好处是,第一提供免费套餐,不区分个人和商业用途,并且免费套餐允许同时100台设备组网,第二它是更完整的内网穿透方案,安装了ZeroTier软件的所有设备都会加入到一个自己指定的虚拟局域网内,这样这些设备之间相当于都是局域网访问,所以不仅能远程桌面,还能进行其他任何操作。ZeroTier的使用也很简单,每台设备上安装软件后加入到自己创建的网络内即可,具体可参考相关帮助。 唯一可惜的是在远程操作时,速度有些慢,这是因为同TeamViewer一样,设备之间的连接都是通过他们的服务器转发的,而ZeroTier的服务器,在国内的访问速度显然不如TeamViewer的好,如果TeamViewer的连接速度比作1的话,ZeroTier不经过额外配置的情况下,对于我的网络状况下差不多是0.6。 所谓的额外配置,是ZeroTier允许你自己加入中转服务器(通常是自己所有设备都能访问到的具有公网IP的VPS),这样两台设备连接时会自动利用ZeroTier自身服务器(称作planet)和你指定的中转服务器(称作moons)之间连接速度更好的一个。在按照官方文档Creating Your Own Roots (a.k.a. Moons)和相关参考文章《ZeroTier moon 设置教程》 设置好以后,发现速度确实有所提升,感觉可以达到TeamViewer的1-1.3倍的速度。   方案三 frp frp是国内大牛开发的一个开源方案(A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.,目前仍处在开发状态,不推荐用于生产环境),相比于TeamViewer客户端/服务器端都闭源,ZeroTier客户端开源/服务器端闭源来说,frp的客户端和服务器端都在GitHub上开源。主要思路是通过自己指定中转服务器,实现两台不同内网设备之间的点对点链接。它的好处是和ZeroTier一样能够暴露某个机器上的所有指定端口,而且服务器端完全走指定的中转服务器(ZeroTier是自动选择)。具体配置步骤如下: 1. 在中转服务器VPS上配置服务器端。 wget https://github.com/fatedier/frp/releases/download/v0.23.3/frp_0.23.3_linux_amd64.tar.gz tar -zxvf frp_0.23.3_linux_amd64.tar.gz //编辑服务器端配置文件frps.ini [common] bind_port = 7000  # VPS监听的端口,用于和frp客户端连接 。需防火墙开放 //启动服务器端(可自己配置系统服务) nohup ./frps -c frps.ini & &> … Continue reading 几种需要内网穿透情况下Windows远程桌面的方案 »

北京联通烽火HG220G-U光猫升级+路由改桥接

  去年家里宽带升到200M之后,因为原先的光猫是百兆LAN口,网速受限,所以打联通客服要求换一个千兆LAN口的光猫。当时说我们这片只有烽火HG220G-U个型号的二手光猫支持千兆了,于是就先用着,还算稳定,但发现光猫的工作模式被锁死在路由模式下,不像原来的百兆光猫是桥接模式,这样光猫后面的路由器就没法拨号,导致路由后的NAS没法从外网直接访问,又用回了之前的SSH反向端口转发的办法。   后来又联系过两次联通客服,总说新猫没有到货,于是想看看有没有什么办法自己解决。找到了老周部落贴吧里的《烽火HG220G-U E00L2.03M2000光猫改桥接教程》,修改完成后发现光猫确实按桥接模式工作了,路由器也能正常拨号上网,但网速从200M降到了不到100M,发现是因为光猫的固件版本掉坑里了,2.02版本的光猫确实会出现改桥接后掉速的问题。当时也没找到升级光猫固件的办法,无奈又改回了路由模式。   昨天恰好看到老周部落贴吧里的又出了新文章《北京联通烽火HG220G-U/HG221G/HG260G-U/HG261G互通型HGU升级指导》,先看了下跟贴,发现有一人情况和我一样,原来是2.02版本,想通过升级再改桥接。但他升级到最新2.04版本后,改完桥接依然掉速。     本想希望不大,抱着试试看的心态也升级了家里的光猫固件版本,但没有直接升到最新的2.04,而是到之前教程里改桥接肯定没问题2.03版本,然后改桥接,路由拨号,测试,200M–>200M。又可以从外网愉快的访问NAS啦~    

家用(影像)存储及备份方案选择

  随着家庭成员和移动设备的增多,我们日常生活中越来越频繁地产生着各种照片和视频文件,日积月累,这些数字资料的保存,读取,备份或早或迟都会成为困扰你的一个问题。     先来说说存储。我们移动设备存储空间满额的时候,最先想到的是把照片和视频导出保存到电脑硬盘上;而你肯定经历或者听说过硬盘坏掉这件事情,所以你可能觉得电脑硬盘靠不住了,买个移动硬盘来寸照片和其他重要资料吧,一来不用天天通电读取,看起来寿命似乎要更长,二来可以当作备份使用。但仔细想想,移动硬盘只不过是一个体积更大,容量更大的u盘(而且抗震性能还不如u盘),把你认为重要的资料存在u盘里可靠吗?你听说周围朋友移动硬盘坏了,丢了的情况多还是他说我家里台式机硬盘坏了的情况多?既然台式机硬盘无法保障我的照片和视频,更好的方案是什么呢?答案就是NAS。关于NAS的介绍大家可以自己google一下,品牌一般就是Synology(群晖)和QNAP(威联通)二选一。而当你使用NAS超过一段时间后,会发现对NAS硬盘里的资料进行备份又变成一个不可避免的话题。虽然比台式机硬盘坏掉概率要小很多,但只要发生,对于你的资料就是100%的丢失。     再来说说备份。如何对NAS上的资料进行备份呢?通常NAS里不仅有比较珍贵的照片和视频,可能还有不太重要的一堆高清电影。最先想到的办法是多块硬盘做RAID1或者RAID5。前者硬盘空间浪费多,后者对NAS硬件级别又有要求(最少3块硬盘)。自己手上的QNAP 212P是比较低端的NAS,虽然有两个盘位,但发现做RAID1的话需要自己把现有资料备份,然后塞两块硬盘进行重新格式化,之后再把备份的数据倒回去;想做热备份的话就得换更好的NAS。前者需要多加一块硬盘,外加数据导入导出,成本1000元左右;后者换NAS,加硬盘,成本更高。     最后目光又落回了云存储上面。之前也看到NAS里有应用可以备份本地数据到云存储上面,一般都支持增量备份及本地/云端双向同步备份,足够满足需求了。但感觉有额外的费用,没有细想。这回重新计算一下成本发现,云存储的备份办法确实比较划得来。目前需要备份的照片和视频差不多有100G,按照AWS S3最贵的Standard存储级别0.03美元/GB/月来算,就算200G数据,每月成本6美元,2年的成本大约1000人民币,相比加硬盘,换NAS来说更有优势。因为目前家用NAS正在快速普及,两年后NAS功能,硬盘容量,成本几何都是未知数。      下来就比较一下可选的云存储方案。能考虑的也就是三家,亚马逊的AWS S3,谷歌的Google Cloud Storage和微软的Azure Storage。从信誉度来说国内的各种所谓云计算直接pass,从持久性来说微软的Azure也pass,不是说Azure的durability不行,而是怕微软的Azure哪天就不行了。。。S3中的Glacier响应速度4小时,就不用考虑了;S3还有一个Reduced Redundancy Storage(RRS)的durability是99.99%,相比其他剩余选项的99.999999999%来说,在成本差别不大的情况下也可以淘汰掉。剩余的选项对比如下:     AWS S3 Standard AWS S3 Standard – Infrequent Access GCD Standard GCD Durable Reduced Availability GCD Nearline Storage Durability 99.999999999% 99.999999999% >= 99.9% >= 99.0% >= 99.0% Availability 99.99% 99.99% “High availability” “Lower availability than Standard” “Lower availability than Standard” Storage Pricing (per Month) $0.03 per … Continue reading 家用(影像)存储及备份方案选择 »

在CodeDeploy脚本中使用nvm

  nvm是一个nodejs版本管理工具,它能够方便地帮助你管理多个共存的nodejs版本,并在其中进行自由切换。   这回在AWS的CodeDeploy脚本中调用nvm自动安装和使用指定版本的nodejs,遇到了问题。如下的脚本,   执行后发现,最终部署结果里并没有使用5.3.0的nodejs,而使用的仍然是系统原来安装的老版本。ssh登录机器,查看nvm ls和nvm current,却已然是5.3.0版本的nodejs了:   原来nvm的所有命令,如nvm install,nvm ls都是写在~/.nvm/nvm.sh脚本里的,系统之所以能识别这些命令,是因为在当前shell里运行过source ~/.nvm/nvm.sh。而正因为已经在~/.bashrc文件中添加了该语句,所以每次ssh登录时,shell相当于已经source过了该脚本。   而以”su -c”方式执行命令时,命令是在一个non-login,non-interactive的shell执行的,所以不会读取~/.bashrc文件,因此nvm的命令就无效了。解决办法是在CodeDeploy脚本中调用nvm命令的语句前,先使~/.nvm/nvm.sh文件source一下。比如:   参考: What is the difference between interactive shells, login shells, non-login shell and their use cases? What’s the difference between .bashrc, .bash_profile, and .environment?

Windows下删除过长路径下文件(夹)的办法

  有时候在Windows下删除文件或文件夹会碰到如下错误: The source file name(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation. 或 文件名对目标文件夹可能过长。您可以缩短文件名并重试,或者尝试路径较短的位置。   解决的办法是在命令行输入: robocopy /MIR c:\a d:\xxx   其中c:\a是c盘新建的一个空目录,d:\xxx是路径过长的文件(夹)的根目录。执行后,你会发现d:\xxx目录已经被清空了。

使用AWS CodeDeploy的几点注意事项

  AWS CodeDeploy是亚马逊云计算提供的服务之一,用来将代码更容易地部署到EC2实例或私有云实例中。   它能够根据用户配置,从S3或Github上获取最新代码,并按照用户提供的appspec.yml配置文件,在不同的hook事件阶段执行不同的脚本文件,从而使代码部署过程自动化。   比如你可将多个EC2实例分为Dev,QA,PRD三组,通过结合CodeDeploy和其他CI工具(如Jenkins),自动化完成持续交付(部署到Dev/QA实例上),持续部署(部署到PRD实例上)的任务。   在使用CodeDeploy的过程中,有以下几点事项需要注意: 所有EC2实例上必须安装CodeDeploy Agent服务,EC2实例之所以会响应CodeDeploy服务,都是由CodeDeploy Agent来完成工作的。 默认CodeDeploy Agent是通过root用户安装的,所以appspec.yml中执行脚本时,默认是以root用户身份执行。而我们的代码中用到了PM2,执行PM2命令(如pm2 start)时,需要在appspec.yml中指定以ec2-user用户执行脚本,否则相关命令执行时,会导致EC2实例cpu持续占用100%,最终导致超时而部署失败。 sudo: sorry, you must have a tty to run sudo问题。在sh脚本中,如有需要sudo执行的命令,则需在所有EC2实例的/etc/sudoers文件中,注释掉“Default requiretty”一行。 /bin/bash^M: bad interpreter: No such file or directory问题。这是因为在windows操作系统上修改了.sh文件,导致文件末行编码不同,而在linux机器上无法执行。解决办法是在linux机器上重新保存该文件,或在windows上用sublime打开该文件,View->Line Endings->选择Unix,保存即可。

Amazon EC2上通过NFS共享目录的注意事项

  背景:拟在Amazon EC2上部署nodejs应用集群。假设nodejs部署在A和B两台机器上,通过前端的ELB(Elastic Load Balancer)分发请求到A和B机器上,两台机器分别对请求做无状态响应,这样就要求A和B机器存取完全相同的数据。由于nodejs应用需要读写本地硬盘目录(对响应速度要求高,无法采用S3存储),而Amazon目前提供的存储方案中,只有EBS(Elastic Block Storage)存储可以挂载到具体机器上以提供本地路径,所以只能选取EBS作为应用集群的存储位置。但EBS类似SAN,只能挂载到一个EC2实例机器中,如果直接挂到A或B上的话,另一台机器就无法读取其中数据。所以采用的方案是启动第三个EC2实例机器C,将EBS挂载到C机器上后,该机作为NFS服务器共享EBS的挂载目录,A和B机器作为NFS客户端,分别加载共享出来的EBS路径到各自对应目录,从而保证nodejs集群能够实时读写相同的数据。如下图所示:   问题:在C机器上挂在EBS存储卷后,修改/etc/exports文件设置了NFS共享,并且有rw, no_root_squash选项。但在A机器和B机器上通过修改/etc/fstab文件并mount -a后,发现能够加载C机器上的EBS存储到指定目录,但写入文件时提示无权限。   解决办法:确保C机器(NFS服务器)上,EBS挂载路径的所有者,与A和B机器(NFS客户端)上准备写入数据的用户要拥有相同的UID和GID。具体来说,这三台机器都是从Amazon Linux的AMI启动的,所以默认用户都是ec2-user(非root用户)。C机器上EBS挂载点是/data,一开始该目录的所有者和组均为root(因为在根目录下建立目录需要root权限),所以导致在A和B机器上加载该共享目录后,加载目录的所有者和组也均为root用户。这样A和B机器上运行nodejs的ec2-user用户就无法写入数据了。解决的具体办法是在C机器上运行”sudo chmod –R ec2-suer:ec2-user /data”命令后,在A,B机器上重新加载NFS共享目录即可。   参考:How to properly set permissions for NFS folder? Permission denied on mounting end.   目前Amazon EC2上推出了公测版的EFS(Elastic File System)存储,类似NAS,在可以提供本地存储路径的前提下,还可以挂载到多台EC2实例上。但目前只有US West(Oregon)一个区域可用。在EFS全面推出前,采用上述方案,可保证应用集群横向扩展的情况下,依然能存取相同的数据。缺点是C机器是单故障点;但数据存储在单独的EBS上,至少保证数据的生命周期不依赖具体的EC2实例机器。