I am having trouble displaying a raw YUV file that it is in NV12 format. I can display a selected frame, however, it is still mainly in black and white with certain shades of pink and green. Here is how my output looks like Anyways, here is how my program works. (This is done in cocoa/objective-c, but I need your expert advice on program algorithm, not on syntax.) Prior to program execution, the YUV file is stored in a binary file named "test.yuv". The file is in NV12 format, meaning the Y plan is stored first, then the UV plan is interlaced. My file extraction has no problem because I did a lot testings on it. During initiation, I create a lookup table that will convert binary/8 bites/a byte/chars into respected Y, U, V float values For the Y plane this is my code
The U Plane lookup table
And the V look-up table
after this point, I extract the Y & UV plan and store them into two buffers, yBuffer & uvBuffer at this point, I attempt to convert the YUV data and stored it into a RGB buffer array called "frameImage"
then I tried to draw the Image in OpenGl
so basically this my program in a nut shell. essentially i read the binary YUV files, stores all the data in a char array buffer. i then translate these values into their respected YUV float values. This is where I think the error might be: in the Y lookup table I standardize the Y plane to [0,1], in the U plane I standardized the values between [-0.435,0.436], and in the V plane I standardized it bewteen [-0.615,0.615]. I did this because those are the YUV value ranges according to wikipedia. And the YUV to RGB formula is the same formula from Wikipedia. I have also tried various other formulas, and this is the only formula that gives the rough outlook of the frame. Anyone might venture to guess to why my program is not correctly displaying the YUV frame data. I think it is something to do with my standardization technique, but it seems alright to me. I have done a lot of testings, and I am 100% certain that the error is caused by by look up table. I don't think my setting formulas are correct.
@nschmidt I changed my code to what you suggested
and this is the result that i get here is the print line from the console. i am print out the values for Y, U, V and RGB value that are being translated and stored on in the frameImage array YUV:[0.658824,-0.022227,-0.045824] RGBFinal:[0.606593,0.694201,0.613655] YUV:[0.643137,-0.022227,-0.045824] RGBFinal:[0.590906,0.678514,0.597969] YUV:[0.607843,-0.022227,-0.045824] RGBFinal:[0.555612,0.643220,0.562675] YUV:[0.592157,-0.022227,-0.045824] RGBFinal:[0.539926,0.627534,0.546988] YUV:[0.643137,0.025647,0.151941] RGBFinal:[0.816324,0.544799,0.695255] YUV:[0.662745,0.025647,0.151941] RGBFinal:[0.835932,0.564406,0.714863] YUV:[0.690196,0.025647,0.151941] RGBFinal:[0.863383,0.591857,0.742314] Update July 13, 2009 The problem was finally solved thanks to the recommendation from nschmidt . It turns out that my YUV file was actually in YUV 4:1:1 format. I was originally told that it was in YUV NV12 format. Anyways, I would like to share my results with you. Here is output and my code for decode is as follows
essentially, I used NSData for the raw file extraction. stored in a char array buffer. For YUV to RGB conversion, I used the above formula, afterwards, I clamped the values to [0:255]. then I used a 2DTexture in OpenGL for display. So if you are converting YUV to RGB in the future, use the formula from above. If are using the YUV to RGB conversion formula from the earlier post, then you need to display the texture in GL_Float from the values for RGB are clamped between [0:1]
|
Next try :) I think you're uv buffer is not interleaved. It looks like the U values come first and then the array of V values. Changing the lines to
might indicate if this is really the case.
|
|
wow, I tested out my program with your adjustment and it finally worked. thanks a lot man.it turns out that you were right, the U & V plane are not interlaced as I was originally told. thank you so much nschmidt. I'm rating you up –
ReachConnection
Jul 13 '09 at 15:07
| ||
|
no problem :). for the record the first guess about the format being 4:1:1 was actually incorrect. You have 4:2:2 format. The real problem was only your data not being interleaved. –
nschmidt
Jul 14 '09 at 17:54
|
I think you're addressing U and V values incorrectly. Rather than:
It should be something along the lines of
|
|
thanks, I missed this mistake. however, I made the changes and the displayed frame is still mainly in black and white, with pink and green shades here and there. –
ReachConnection
Jul 10 '09 at 15:08
| ||
|
The picture looks like you have 4:1:1 format. You should change your lines to
Maybe you can post the result to see, what else is wrong. I find it always hard to think about it. It's much easier to approach this iteratively. |