只有我不在的街道 BDRip 制作感受

 

这是前一阵我第一次接手BDRip制作任务。从5月学习完BDRip制作技术到现在算第一次正式任务。首先在5-6月写了第一遍处理文件。受限于当时屏幕问题,以及自己对于各种滤镜的使用还属于比较混乱的情况,第一遍的处理文件以及编码参数总的来说是比较糟糕的。

具体问题主要是:

对于线条欠码,没有使用足够高的psy-rd参数,limit_diff的值太高。没有起到限制作用,f3kdb的参数有点高。

因此后期是针对这个问题进行了一些修改,不过由于是小修小补,其实效果还是有些问题的。

接着6月底,BDBOX II放流了,此时正巧是x265 2.0 stable release的时候,因此组内进行了长达3周的数据测试,x265 2.0相对老版本,对于平面信息的保留更好了,然后,通过对一些参数微调,抛弃一些意义不是很大的使用时间换取质量的参数,甚至可以提高编码速度。总的来说x265 2.0的发布可以说是可喜可贺。

同时在7月我购买了新的显示器,于是我决定重写参数,从处理文件到编码参数完全的更新。首先是重写处理流程,滤镜串联也做了相应的修改。接着,加入了AA机制,进行了5轮的测试,基本决定了编码参数,也就是midhigh v3的修改版参数。略微提高线条的码率分配。此时已经到7月底。大部分测试已经完成,准备量产,量产过程持续时间较长。最终1080p 10bit成品的体积控制在平均700MB,当然这个体积小也是有原因的,大部分的EP中,画面被剪裁到21:9超宽画面,这就带来25%的黑色画面,节约大量体积。这样推算如果是常规番剧,体积应该要接近1Gb / EP 因此总的来说还是符合预期的。

在拿到量产好的成品后,我粗略的看了一下,突然发现在EP3中出现了明显的chroma shift,因此我查看了一下其他EP,结果发现所有21:9比例的内容都出现了相同的Chroma shift。我查看了一下源,发现这个问题本身就出现在源中。只是由于DCT Ringing最终放大了这个问题。过程中我曾近问了一下如何自动化处理这样的shift,最后lp给了一个比较有意思的解决方案:剪裁画面上下黑边,检测这个clip的平均值,如果低过阈值,那么就认为这段就是黑边,此时修复shift。由于这个问题只出现在21:9的内容中,因此很像是后期人为加入的。于是我将这个问题当做特效不做特殊处理。

第一部BDRip到这里就基本做完了,虽然说还是不太满意不过我决定先把视线放到下一部番剧上,希望后期逐渐积累经验以后还能有时间重新制作一下这部Rip吧。

, , ,
上一篇文章
在banana-pi M3上搭建Dlna Server
下一篇文章
使用KeyCDN为WordPress加速

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Fill out this field
Fill out this field
请输入正确的电子邮件地址。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

菜单