来晚了,被kykdu抢先了[/ku],那我就补充两张图吧.
kykdu说得已经很明确了.问题的关键就是cli内置decoder,而这个decoder所做的deblock只输入到buffer中,也就是图1的"memory".在decoder输入超过ref数量的帧时,旧的经过inloop处理的帧就会被"洗"掉.所有贮存在硬盘上的帧都是未被deblock处理(然而却参考了前面经过了处理的帧)的帧.
而在图2中,则是直接输出到视频缓冲.
H264编码器流程图
H264解码器流程图
以上都是我看标准总结出来的.而kykdu居然靠看代码总结出来,牛人啊....
下面我说点我所发现的和kykdu不一样的.我用filter 3:3试压,结果码率下降了100kbs左右,PSNR反而上升了0.3dB.这和kykdu前面说的两点(体积变大,PSNR下降)都不同,诡异.....
而且还有一点让人难以明确,究竟解码器是通过什么来判断一个帧是否需要做deblock?为什么压制时不开deblock,解码器开不开都没有影响?按理说,即使压制时不开deblock,而解码时打开了,那么最少会对当前帧做deblock处理,而使这个帧解码下来和解码器不开deblock有所差异,但事实上这种差异并没有发生.一个反例是,如果不开deblock,用deblock压出来的片断,虽然解码下来整体的PSNR下降了2之多,但第一帧(I帧)却上升了0.2左右.说明deblock确实起了"洗"(套用DeathTheSheep的说法)的作用.那么为什么编码没开deblock,这个"洗"就不起作用呢?
所以我觉得编码时或许在每个帧中都插了一个有关deblock的flag.不知道是否如此,请分析过x264代码的朋友们再研究研究.
