YUV422的旋转

YUV422的旋转，其实就是将之当做YUV420一样进行旋转，即4个Y值，共享一组UV，这样旋转后，会损失一般的色度值。

不管你的decoder给你的什么鬼，或许是平面格式，或许是打包格式，反正就是两个Y值共享一组UV，那么旋转后，还得是两个Y值共享一组UV。

那么问题来了，你做的旋转使得以前垂直相邻的像素变成了水平相邻，而水平相邻的像素点需要共享UV数据，而旋转前这两个像素点没有任何关系，这个UV值从哪里来？

个最简单的例子，有4个像素点：

p1,p2

p3,p4

那么p1,p2共享一组U12，V12，p3,p4共享一组U34，V34，旋转以后呢？

这里以p2点为原点，逆时针90°:

p2,p4

p1,p3

Y值是一一对应的，其旋转不说了。可是UV呢？

这时p2,p4需要共享一组UV，p1,p3需要共享一组UV（你的screen或者encoder决定，你输出的视频数据必须要p2,p4共享一组UV，p1,p3共享一组UV），

但是旋转前，p2和p4,p1和p3一毛钱关系都木有啊！

那怎么办？那算了，没关系就没关系吧，就这样赋值吧（假设UV输出需要UVUVUVUV这样的序列）：

U12,V12,U34,V34,

那么赋值出来的结果是什么？

video_width = video_width *2;

video_hight = video_hight/2;

那么好吧，我随便赋值得了，反正没人管我，但是UV值都是相互配合才能表示一个像素点的，那咋整呢！？

好吧，算了，我妥协了，索性:

Y1和Y2,Y3和Y4都对应U12,V12。

画面不清晰就算了，至少色彩正了。

但是效率问题来了，对于一个720*480视频中的一块464 * 380的区域，进行左右90°旋转，耗时是内存拷贝该区域的4倍。

我试用了查找表的方式，徒劳，依然是4倍......