4K占用空间巨大，平时用手机相机拍出来的4K在H.264下少说60Mbps才能保质（当然你要说30Mbps仍没有太大问题——是的，对于出品来说这样的品质算是很好的了，也许问题不大，但是考虑到这些是硬件编码的264，并且还要后期进一步编辑二压，尽可能地保留品质是重要的）。但是在大多数手机观看端，1080p早已绰绰有余——笔记本电脑也完全足够——至于为什么大家觉得不够清晰，一问问码率二问问压缩次数三问问缩放算法四问问4:2:0）

那么怎么保存4K素材？当然是下变换到1080p啦~一方面减少剪辑压力，第二方面节约素材空间高达3/4。什么你问我为什么不直接拍摄1080p？第一受限于硬件压力，许多手机，微单的1080p是不可能给你机内超采样的，那种欠采样简直是可以把1080p搞成720p用烂算法拉伸的清晰度而且锯齿摩尔纹严重，第二拍摄4K再缩放为1080p可以得到梦幻4:4:4，是十分有利于清晰度的（可惜现在好像没有平台支持。）

总而言之，我们今天就要解决这最后两个问题：缩放算法和Chroma Subsampling。

事情很长太长不看，先说结论：Chroma Subsampling当中，选择1080pYUV444p10压缩是最好的，体积约等于YUV420p8；而YUV444p8其实会变大一点。可以这么理解，444会小幅增大数据量，而10bit带来的压缩率优势可以抵消这部分增加。

有关10bit节约带宽的原理可以看Avisynth+的Wiki上有一个引用，网上讨论的也比较多，唯一缺点就是压制慢一点；有关444比较420的清晰度问题，接着往下看。

显然可以看出444的颜色更加饱满并且细致。（这里可能有点问题，我是MPEG4的源理论上不需要做半像素的shift但是420的madVR却做了，导致色度偏左半格（我感觉我这个444是正确结果，看边缘可以看到420有缺色），另外这里是用的Potplayer截取源画面工具，所以也有可能是Pot搞错了...）

另外一组可能更加明显 注意后面木纹的细节

总之，除了压制时间变长之外，444p10全是优点。

接下来就是超采样算法了，4K420变444的情况下，只需要对Y平面做一个缩放，那么问题是什么缩放质量最好。（下面的测试为了方便起见没有只做Y缩放，而是同时缩了整个视频，但是应该不影响相对结论）为此我把Avisynth里面能用的缩放基本测试了一遍

第二组对比，主要看ringing、aliasing和色度

专栏里的图应该看不出什么端倪 有兴趣的朋友可以自己试一试。关于结构相似度我是比较了一张人脸，出于肖像权就不放上来了，有的算法存在最多1像素的扭曲。

最后结论就是 Spline36综合性最好 Bilinear原理上接近物理缩放。

关于Avs+2.6版出高色深流的问题，网上很多玩法都是fake HBD时代的，奈何现在有了超级不完善的Native HBD之后，StaxRip居然没法用以前的出raw流喂264 interlaced的10bit这样的方法。于是贴一段摸索好久的代码实现Y平面超采样和高色深输出，直接推原生16bit出去可以激活StaxRip的高位深pipe，不然直接推模拟的10bit编码器根本不吃（因为是y4m）

关于gamma-aware的缩放：其实问题没有那么严重，但是既然做了就应该尽善尽美，用到的是Dither tools里面的东西。先转换成linear-light再缩放再转回去。

关于线性光：如果计算机做255和0的平均，得到的自然大约是128。但是128在却并不是50%灰，而要在188左右才是人眼的50%灰。实际上并不是不可以让128显示50%灰，而是人眼对暗部敏感，如果暗部grading不够的话容易出band，所以故意用曲线分级分多一点在暗部。但是这样设计后的数据直接扔进resize算法里面做计算显然是不合适的，所以我们先要将188这种人眼50%映射回计算机的50%，再扔给算法。而计算机内部处理是线性的，故这里称线性光。

前面load我也不知道哪些是有用的，自己看着办。

LoadPlugin("AddGrainC.dll")

LoadPlugin("dfttest.dll")

LoadPlugin("masktools2.dll")

Import("mt_xxpand_multi.avsi")

LoadPlugin("RgTools.dll")

Import("dither.avsi")

LoadPlugin("dither.dll")

LoadPlugin("LSMASHSource.dll")

LSMASHVideoSource("")

#这里直接8bit读入 有需要自己改LSMASH参数改成YUV4xxp10这类的

Dither_convert_8_to_16()

Dither_y_gamma_to_linear(tv_range_in=false, tv_range_out=false, curve="709")

y = ConvertToY().Dither_resize16(1920, 1080, kernel="spline36").Dither_y_linear_to_gamma(tv_range_in=false, tv_range_out=false, curve="709")

u = UtoY8()

v = VtoY8()

YToUV(u, v, y)

ConvertFromStacked(bits=16)

本文也参考了很多前辈的工作，比如nmm上大触们对gamma-aware的解释，VCBS的解释等。在此一一谢过了。

最后让我们看一组图，在相同编码参数的情况下，他们都从4K的60Mbps降到了15Mbps左右。体积上的差距也能反映一些问题譬如细节保留，产生的Ringing，压缩效率等。所以并不是越清晰的源喂给编码器质量一定越好，在体积受限的情况下，可控的缩放损失指不定有更好的效果？

附注：p8的p到底是progressive还是planar...