Why the odd lines are copied to the even lines? (deinterlaced??)

Is it possible that application is not swtiching (ping-pong) between video buffers correctly?  If application was passing the same video buffer for both fields, it could have this side effect.

I believe the driver by default will be outputting the interlaced image with the lines interlaced in a single 480 line buffer, though it is possible to adjust the VPFE to output the lines to SDRAM in varying fashions as discussed in section 4.3.1.4.4 of SPRUE38. I am not sure I understand your question entirely because you show that there are only odd lines, but you say the frame buffer has the lines correct, so where are there only odd lines (another frame buffer, or the output perhaps)? Could you go into more detail how the output image is strange, perhaps post a picture of the output?

I am not sure if FB_VMODE_NONINTERLACED is valid when you are capturing NTSC, which is inherently interlaced, so it may not actually do anything unless you have the driver and VPFE setup to talk to a progressive source, like a CCD or a video ADC.

Thanks Juan and Bernie,

Juan Gonzales said:

Is it possible that application is not swtiching (ping-pong) between video buffers correctly?  If application was passing the same video buffer for both fields, it could have this side effect.

The code snippet for the frame buffer switching is shown below, and I believe this code is passing correct data. But your explanation is also reasonable. Can you please check the below code and point out if something wrong?

/* Video display is triple buffered */
#define NUM_BUFS                 3

 

        /* Increment the display index */
        displayIdx = (displayIdx + 1) % NUM_BUFS;

        /* Copy the supplied frame to the display frame buffer */
        copyFrame(displays[displayIdx], e.frameBuffer, e.width, e.height);

        /* Give back the buffer to the video thread */
        if (FifoUtil_put(&envp->inFifo, &e) == FIFOUTIL_FAILURE) {
            breakLoop(THREAD_FAILURE);
        }

        /* Flip display buffer and working buffer */
        flipDisplayBuffers(fbFd, displayIdx);

        /* Wait for the vertical sync of the display device */
        waitForVsync(fbFd);

        gblIncFrames();

Bernie Thompson said:

I believe the driver by default will be outputting the interlaced image with the lines interlaced in a single 480 line buffer, though it is possible to adjust the VPFE to output the lines to SDRAM in varying fashions as discussed in section 4.3.1.4.4 of SPRUE38. I am not sure I understand your question entirely because you show that there are only odd lines, but you say the frame buffer has the lines correct, so where are there only odd lines (another frame buffer, or the output perhaps)? Could you go into more detail how the output image is strange, perhaps post a picture of the output?

I am not sure if FB_VMODE_NONINTERLACED is valid when you are capturing NTSC, which is inherently interlaced, so it may not actually do anything unless you have the driver and VPFE setup to talk to a progressive source, like a CCD or a video ADC.

I'm going to upload the frame buffer image (display[]) and the picture what we're seeing later.

# Now having trouble with uploading it with this page...

Thanks and regards,

Moto

Can you give it another try at describing the issue to see it we can better understand the issue at hand?

[edit] The code snippet looks good.

You should be able to add a file attachment to the post by using the options tab near the top of the reply dialog (just above the area that shows the post you are currently replying to), you can probably use that to post an image. From there you could edit your post to have it display the image from that link however that would just be to make it look better, just getting the image on here is good enough I think. If that isn't working out for you, you could post the images on a public image site, like http://imageshack.us/

Bernie, Juan,

Sorry for kept you waiting...

I finally prepared a Picasa web albums account and uploaded the images.

This is the original image stored in frame buffer.

And this is the output screen image (created a similar image as what we're seeing).

Can you imaging the problem now?

# If you face a problem to see the above images, please access to the below URL.

# http://picasaweb.google.co.jp/TImoto2000/DeInterlaceProblem#5251725480676479394

Thanks and regards,

Moto

Just to make sure we are focusing in the right area, this appears to be a problem with the VPBE (display side, as opposed to capture side), correct?  Since there are mentions of VPFE in previous postings, I just want to make sure we are focusing on the right problem area. 

If so, are you using analog or digital video output?  Also, how did you verify the video data in DDR2 is correct? could you write this data to a file instead and use another program to display the video frame correctly?

I am just thinking aloud here, but if you can confirm the first question above, we can at least focus on the correct portion of the system.

I am assuming that the image here is exactly what is in your memory, including the black edge portions, it sort of looks like you took a picture of a greyscale display at an odd angle, but looking at the edges of that makes me belive that this is in fact the entire display buffer. Looking at the images this reminds me of field swapping, i.e. if field 0 was displayed as field 1 and vice versa, which can make lines at an angle look jagged. However looking closely at the edge from grey to black it does look more like line doubling than field swapping. This looks almost like the field mode described in section 4.3.2.4.2 of SPRUE37, though your buffer pointer would be setup to skip the odd lines in the buffer, otherwise you would only be seeing the top half of the display. This certainly seems like something you would need to tweak in the display driver, are you using the default display driver included with DM6446 or have you made your own modifications?