• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 948 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Can DM365 resizer do resize and convert yuv422 to yuv420sp at the same time;

yangchar
Intellectual 705 points

Dear All:

 I saw this link about yuv422 to yuv420sp ,but i also want to resize D1 to HD1/CIF,I wander can the resizer do the two function at the same time?

  • 0
    Genius 5240 points

    Yes.  I use the resizer on the fly to convert to 420SP and store both a D1 and CIF image at the same time.

    JohnA

  • 0
    TI__Expert 8780 points

    Hi yangchar, 

    The resizer engine can do YUV422 to YUV420 conversion and resizing in the same pass.

    Regards

    Rajat

  • 0 in reply to Rajat Sagar
    Intellectual 705 points

    hi,Rajat

    Sorry for the delay.I didn't  figure out i work in the one-shot mode,i've tested resizing from D1 to HD1/CIF successly , and now still test YUV422 to YUV420 conversion .

  • 0 in reply to Rajat Sagar
    Intellectual 705 points

    I confirmed the resizer and it can do the two function at the same time .But i met a new problem,when i convert  YUV422 to YUV420SP ,the U V are not right but the Y is ok the resizing from D1 to CIF is fine; capture size:D1 704*576


    This is YUV bmp file:

     


    This  is Y part bmp file:


    This  is U part bmp file:


    This is  V part bmp file:


    You don't need to care about the color,beacuse the YUV viewer can not  analyze YUV420SP rightly, i don't kown why there are some words in UV?

    Regards

    Yangchar

  • 0 in reply to yangchar
    Prodigy 65 points

    It looks like your YUV viewer isn't decoding the YUV420SP correctly. I think it's because of the "line length" or "capture width".

    You see, the YUV420SP format is meant to be lots of Y-values, and then pairs of UV values. But there's something called "line length". Let's say the line-length is 736. That means that even if the image is only 720 pixels wide, then each line will 736 wide. So the image will start with the Y-data: 720 Y-values, followed by another 16 bytes of random data which should be ignored. Following that Y-data is the UV-data. But because this is 4:2:0, then every 4 bytes of Y, there's 2 bytes of UV. Actually, those 4 bytes of Y-data are on two lines, and the 2 bytes of UV are being "shared" vertically. (That's what 4:2:0 means). So for every two lines of Y-values, we'll have only a single line of UV values. Actually, for every two lines of 720 bytes of Y-values, we'll have only 360 bytes of UV. But the line-length is still set to be 736. So even though there's only 360 bytes of actual data, it will be followed by 360 bytes of padding (random data) which should be ignored.

    It looks like the code you're using to get the image data isn't correctly taking all of that into account, and so it's copying some of padding data from the UV, instead of copying only the image data.