众所周知视频在各个领域占有极为重要的地位，安防领域，互联网，医药，教育等等等等。扯淡我就尽量不多扯了，现主要扯安防领域吧，安防领域尤其是视频分析领域，视频质量要求比较苛刻。下面介绍一下场景比较苛刻的图片情况：

1.这种

2.这种

花屏现象，在视频接入解码过程中尤为常见，（比如28181接入，rtsp等等），解码大家都考虑使用ffmpeg进行解码，首先考虑的可能是解码错误直接从解码过程中就把这种错误的帧给干掉，看了好多博客大概也就是这个思想。

1.如果解码错误抛帧。2.如果是I帧从下一个IDR帧开始解码。想法不错当然我也在做了这一部分，具体部分代码示例如下:

到这种情况其实已经过滤掉了很多坏图了，但是想上图展示的两种情况，就像是打不死的小强一下死了又来来了又死，怎么办？

当然前面的两张图你必须得把ffmpeg的错误隐藏给关掉，再就是另一个err_recognition这个东西，看解码那块的源码找到了个这么东西，具体干什么的，自己可以细细研究一下。

观察上面的图都有规律，是什么？对，没错！就是都有灰图，那灰图是怎么来的呢？于是乎我有看了看ffmpeg的h264解码，注意到了一个0x80这么数值，还是在alloc_pic的时候，难道这就是传说中的赋初始值？看着像，具体也没看太明白。。。。

那么那些解码错误的灰色的图块吧，确实的东西是不是就是这个默认值呢？答案差不多，那我是不是就可以把这些看似解码正确的图片其实是花了的图片，直接判断这些坏块再做一遍过滤，剔除掉呢？

这里我补充一些色彩空间的知识，不再赘述了，大概就是Ycbcr经过偏置处理默认值128即0x80，大概就是为了和rgb的0~255在一个范围吧：

https://blog.csdn.net/asahinokawa/article/details/80596655

好了，到这一步骤，基本上就是单纯的过滤有灰块的图了，我的思想是判断这个值，或者这个值范围内的值，那么选择yuv哪个分量做过滤呢？当然是Y了，UV是色彩和饱和度，到了晚上这种值当然就是0x80了，看这张图。

他的末尾全是这玩意，即0x80，这就是我选y的原因，因为他是亮度。。。

我的过滤部分伪代码实现如下：