0

I have searched through and have read a ton of sources, but I cannot seem to find an answer. I thought these "types" were equal, but when I decode h264 into bytes using jcodec I assumed the data output was YUV 4:2:O Planar (YUV420P); this is the expected input type for my VPX encoder. The VPX encoded image looks like this: enter image description here

So I have to assume that while YUVFormat.YUV_420 is most likely YUV420P, the ColorSpace.YUV420 is some other variant of YUV420. Does anyone know which variant it is so that I can find a conversion routine?

Paul Gregoire
  • 9,715
  • 11
  • 67
  • 131

2 Answers2

5

One format interlaces the u and v data for a full scan line. the other writes the entire U and then the entire v data. These are after the entire Y image. yuv420 and yuv420p specifies which layout. yuv420 writes all the u then all the v data, yv420p interlaces the u and v data scan line by scan line. This image can be a little misleading because the data size is small enough to not show large blocks of u and v pixels.

yuv420 non P

I believe yuv420p would interlace the U1U2U3 V1V2V3 U4U5U6 V4V5V6

Andy--S
  • 291
  • 2
  • 7
  • I tried swapping the u and v and it didn't change the picture too much, theres still lots of pink – Paul Gregoire Oct 13 '14 at 21:59
  • @Andy-S: I believe the above image _**is**_ YUV420P, where you first have the block with Y-values, then the block with U-values and finally the block with V-values. – GeertVc Mar 18 '15 at 06:53
1

I think you are getting yuv420sp instead of yuv420p. This would explain the horizontal bars in the image. Semi Planar formats interleave the U and V planes.

// 420p to 420sp
int frameSize = width * height;
int qFrameSize = frameSize / 4;
for (int i = 0; i < (qFrameSize); i++) {  
    input[frameSize + i*2] = (input[frameSize + qFrameSize + i]);  
    input[frameSize + i*2 + 1] = (input[frameSize + i]);   
}
bond
  • 1,054
  • 8
  • 15