Open hailsham opened 4 years ago
Very strange! There is indeed a small shift between the luma and chroma channels and I agree that there might be something wrong with how the data is written.
When you get your YUV Plane[], can you print out the width, height, pixel, and row strides? I'm curious what they are. Due to the limitations of Java's ByteBuffer APIs (basically, lack of reinterpret_cast), it's save data that has unusual strides (such as on your device) using a fast API (such as FileChannel) without making a full copy in Java. We didn't want to complicate the code by adding JNI but if your device has unusual strides, we may have to.
Hey! I met the same problem. I don't know if you have a solution now?
Thanks for your amazing work. I meet some problem when I use the softwaresync app dump the data. the color of saved pictures(including jpg and .nv21 file) seems strange. It looks like there is a shift between U, V channel and luma channel.
Converting the nv21 file to jpg/png using script/yuv2rgb.py will get totally wrong image, while converting the nv21 file to jpg using my own nv21_to_jpg tool with stride=4032 and scanline=3000 will get the same result with the saved JEPG version image. the nv21_metadata.txt is as below:
As I know, the chroma buffer size should be 0.5x of luma buffer size with respect to nv21 format, but the saved data dissatisfy that.... 2 * chroma_buffers_bytes - luma_buffer_bytes = -32. It seems that there is something wrong in data saving process rather than the decoding of nv21. I don't know how to fix it, any help would be appreciated, thanks.