Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

something wrong with saved data #2

Open
hailsham opened this issue Aug 17, 2020 · 2 comments
Open

something wrong with saved data #2

hailsham opened this issue Aug 17, 2020 · 2 comments

Comments

@hailsham
Copy link

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.

@jiawen
Copy link
Collaborator

jiawen commented Oct 19, 2020

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.

@HuberyQ
Copy link

HuberyQ commented Apr 23, 2021

Hey! I met the same problem. I don't know if you have a solution now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants