locked
MFCopyImage RRS feed

  • Question

  • hi all

    when copying a YUV (nv12) sample from src to dest using MFCopyImage, for some reason it turns out to be greyscale even though though the original image has color. The UV bytes are not being set properly...anyone else have this issue?

    Tuesday, January 9, 2007 1:00 AM

Answers

  • MFCopyImage is basically an optimized version of this:

    for (DWORD i = 0; i < dwLines; i++)
    {
        CopyMemory(pDest, pSrc, dwWidthInByes);
        pDest += lDestStride;
        pSrc += lSrcStride;
    }

    Are you sure you're passing the right values for the second call to MFCopyImage? Other than that, I'm out of suggestions. :-(

    (btw - Is the image interlaced or progressive?)

    ----------------------------------------------------------------------------
    Mike Wasson, SDK Documentation
    This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

    (c) 2007 Microsoft Corporation. All rights reserved.

     

     

     

     

     

    Monday, January 15, 2007 8:28 PM

All replies

  • This sounds like it copied only the Y plane. You might have to make separate calls to copy the U and V planes. (You'll need to do some pointer arithmetic.) I'll do some research and follow up.

    ----------------------------------------------------------------------------
    Mike Wasson, SDK Documentation
    This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

    (c) 2007 Microsoft Corporation. All rights reserved.

    Tuesday, January 9, 2007 8:03 PM
  • Hi Mike,

    So you are saying the MFCopyImage function only does the Y plane?

    Wednesday, January 10, 2007 12:42 AM
  • It copies one plane at a time. To copy the U/V planes, you need to

    1. Do some pointer arithmetic to find the start of the U/V plane, in both the source and destination buffers.

    2. Call MFCopyImage again.

    So for NV12 it will be something like:

    pSrc = pScanLine0 + (src_stride * height)

    pDest = pDest + (dest_stride * height)

    MFCopyImage(pDest, dest_stride, pSrc, width_in_bytes, height/2)

    (I haven't double checked this, so my math might be wrong...)

    I will update the SDK docs to reflect this behavior - thanks for bringing this to my attention!

    ----------------------------------------------------------------------------
    Mike Wasson, SDK Documentation
    This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

    (c) 2007 Microsoft Corporation. All rights reserved.

     

     

    Wednesday, January 10, 2007 11:38 PM
  • Hi Mike,

    This is what I have done, but the color is all messed up as if the UV plane isn't being copied properly. Any ideas?

     

    Thursday, January 11, 2007 12:13 AM
  • MFCopyImage is basically an optimized version of this:

    for (DWORD i = 0; i < dwLines; i++)
    {
        CopyMemory(pDest, pSrc, dwWidthInByes);
        pDest += lDestStride;
        pSrc += lSrcStride;
    }

    Are you sure you're passing the right values for the second call to MFCopyImage? Other than that, I'm out of suggestions. :-(

    (btw - Is the image interlaced or progressive?)

    ----------------------------------------------------------------------------
    Mike Wasson, SDK Documentation
    This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

    (c) 2007 Microsoft Corporation. All rights reserved.

     

     

     

     

     

    Monday, January 15, 2007 8:28 PM
  • yeah im passing in right values..i even coded it manually like your above example but to no avail.

    the image is progressive

    Monday, January 15, 2007 9:24 PM
  • I'm running out of ideas. Some possibilities:

    - A problem with how you've constructed the NV12 media type? (So that the renderer is mis-interpreting the image format.)

    - If I recall, you've got an uncompressed source plus a copy transform derived from the MFTGrayScale sample. Maybe you're hitting some bug in the MFTGrayscale sample?

    I assume you're QI'ing the buffers for IMF2DBuffer. Can you describe the corrupted image?

    - Diagonal stripes (which would point to a stride issue)

    - Green/magenta colors (maybe swapped chroma bytes, or an incorrect format description, or some kind of off-by-N copy error.) 

    - something else?

    ----------------------------------------------------------------------------
    Mike Wasson, SDK Documentation
    This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

    (c) 2007 Microsoft Corporation. All rights reserved.


     

    Wednesday, January 17, 2007 6:50 PM
  • Hi Mike,

    Thank you for your feedback. I think the image format was a problem. I tried using IYUV instead of NV12 and I actually got color but I noticed some things had changed. For one, only one call to MFCopyImage was needed (2 would crash the program). Also I had to multiply the width by 2 in the MFCopyImage argument. I was under the impression that MFCopyImage copied only the Y plane first? And why did I have to multiply the width by 2? The original yuv stream is in 320x240 (and MF gives a deststride and srcstride both of 640).

     

    Thanks,

    Wednesday, January 17, 2007 10:44 PM
  • Hi,

    I am facing similar kind of issue...The video is displaying green/magenta colors using media foundation. When I set the value of VIDEO_FORMAT to be YUY2 then I get duplicate frames on the screen  with green/magenta colors overlayed on tghe video. On making it to NV12, I get proper video(no duplicate frames) but the color is still green.

    I face this issue in case of HD files on using DXVA-HD acceleration and only with files having chroma subsampling value as 4:2:0.

    Please give me suggestions to solve this problem.

    @Mike : As you have suggested that problem could be "maybe swapped chroma bytes, or an incorrect format description, or some kind of off-by-N copy error.". So can you pls provide some pointers as to how to solve it.

    Regards,

    ijkl

    Wednesday, February 8, 2012 12:42 PM