这是前一阵我第一次接手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吧。