google-research/libsoftwaresync

something wrong with saved data

hailsham opened this issue · 2 comments

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.
sync
Screenshot from 2020-08-17 17:11:54
Screenshot from 2020-08-17 17:11:47

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:

width: 4000
height: 3000
pixel_format: NV21 (tightly packed)
luma_buffer_bytes: 12095968
interleaved_chroma_buffers_bytes: 6047968

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.

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?