16位对齐问题(绿边green bar)
描述：一般编/解码器都有16位对齐的处理（有未经证实的说法，也存在32位、64位对齐的），否则会产生绿边问题。
因此，需要做以下处理：
-
编解码时保证16位对齐；
-
解码时遇到非16位对齐的分辨率，解码器一般会解码成比较接近的更大的尺寸（有可能长宽均有变化），因此需要手动做裁剪。
测试时发现在Android低端手机上解码高分辨率视频时会出现此种情况（哪怕视频原尺寸是16位对齐的），比如红米Note 4X上解码3180x2160的视频，解码器输出尺寸1920x1088（8bit绿边，crop大小是1920x1080，处理方式：裁剪8bit即可），在解码2280x1080视频时，解码器输出1920x1088的缓存（较大绿边，crop大小是1914x906，但输出的图像是放大过（放大到一边与输出缓存的尺寸大小相同方式，处理方式：根据放大后的大小做裁剪），此类均需要做裁剪处理。
附录1. 来源stackoverflow：
Video coding requires the frame dimensions to be aligned to multiples of 16 i.e. macroblock dimensions. HD resolution i.e. 1920 x 1080 is a special case as 1080 is not a multiple of 16. The underlying encoder expects the client to provide an aligned boundary.
In this case, you could provide the data windowed as below. For Luma, you will have to align to a multiple of 16 and for Chroma, you will have to align to a multiple of 8. The remaining pixels could be prefilled with zeroes.
Please note: If the encoder is capable of handling 1920 x 1080 as an encoding resolution, the output should be fine. If the encoder encodes with 1920 x 1088, you will observe a green band at the bottom of the picture in the generated bitstream due to the zero padding.
---------------------------------------------
| |
| |
| |
| Luma |
| 1920 x 1080 |
| filled into |
| a buffer of |
| 1920 x 1088 |
| |
| Last 8 lines could |
| be filled with zeroes |
| |
---------------------------------------------
-----------------------
| Cb |
| 960 x 540 |
| filled into |
| a buffer of |
| 960 x 544 |
| |
-----------------------
-----------------------
| Cr |
| 960 x 540 |
| filled into |
| a buffer of |
| 960 x 544 |
| |
-----------------------