Stripes on DM6437EVM video working with demo software. Interlacing artifact or not?

Those line by line horizontal stripes are certainly interlacing artifacts, they exist in the image viewer because you are viewing an interlaced video frames through a static progressive display. Essentially you have two fields in one frame that are weaved together to form a single image, since those two fields are taken from different points of time in the video any where there is motion you will see these horizontal lines. Note that this only happens on a line to line basis, if you have thicker horizontal artifacting than there is probably something else going on.

There are a number of ways to try to lessen the impact of interlacing, what you are seeing here is a simple 'weaving' deinterlacing technique which is basically just putting the two fields together on a single display, there is a decent article on Wikipedia here that discusses some techniques.

Also looking at your images it looks like your chroma is out of alignment with your luma, i.e. the colors look kind of funky, and the images seem inverted, I assume this is expected from your signal?

Thanks Bernie!

So according to your explanation these stripes are absolutely unavoidable as long as I work with interlaced video. Is that what you mean?

I thought I was having this problem because my application wan't synchronizing properly to read the CCDC buffer with the FVID_exchange call. So lately I've been trying to work on the VDINT0 interrupt to call the FVID_exchange function only right after the VD interrupt was activated. I thought that now I could read the buffer exchanged with the driver without worrying about the stripes, because I was waiting until the whole buffer (both fields) was written before I read it. I also took into account that a VD interrupt is generated per each field. I thought it had sense but I've got no results: I still have the stripes.

As I said, will they always appear with interlaced video?

PS: No problem about the images being inverted. It's correct. And yes, there's something about the chroma and luma, but I'm not worrying about it. I don't think it's important at all. Thanks for the observation, anyway.

R&D said:

So according to your explanation these stripes are absolutely unavoidable as long as I work with interlaced video. Is that what you mean?

Yes, they are always there with an interlaced stream when using a weaving deinterlacing technique like this. You can lessen the impact by using various other deinterlacing techniques but the better techniques get complex, with motion adaptive filtering and such, leading to higher CPU loads and implementation work.

But even if the video I'm outputting comes from the DM355 VPBE the stripes will still be there? I mean, I understand that many analog devices capture video in interlaced format. But I thought in my case DM355 was interlacing it just to output it in BT.656 but that it was progressive in origin (with origin I mean just before converting it to BT.656). According to that I guessed there wouldn't be stripes if I synchronized properly when reading the buffer because both fields would belong to a same frame. I'm not sure if I explained it correctly. Did I make myself understood?

R&D said:

But even if the video I'm outputting comes from the DM355 VPBE the stripes will still be there?

Yes, this is the case.

R&D said:

I mean, I understand that many analog devices capture video in interlaced format. But I thought in my case DM355 was interlacing it just to output it in BT.656 but that it was progressive in origin (with origin I mean just before converting it to BT.656). According to that I guessed there wouldn't be stripes if I synchronized properly when reading the buffer because both fields would belong to a same frame.

BT.656 is inherently interlaced as well, as it represents the analog video equivalent even though it is digital, in other words the translation to digital by the video decoder does not imply any deinterlacing actually takes place. Interlacing is just manifested by the order of the data coming in (all odd lines, then all even lines, then all odd lines, etc.), the analog video is simply converted to digital and it maintains the interlaced ordering given by the analog signal.

Both fields are for a single frame, however those fields are still from two different points in time, so they will differ in appearance slightly, more so when fast motion is involved. For the video decoder to do any real deinterlacing it would have to have enough memory to hold an entire frame within it, as well as additional logic to handle any filtering to make for a good deinterlace operation.

Bernie Thompson said:

Both fields are for a single frame, however those fields are still from two different points in time, so they will differ in appearance slightly, more so when fast motion is involved.

That's exactly the answer I was expecting. But yet I'm not sure of it. My application in DM355 manages video in progressive format. Then it's changed to interleaved when converted into BT.656 just before outputting it in the VPBE. But before that conversion it was progressive.

So I thought the interleaving process (in this case applied to BT.656 conversion) was to take a whole progressive frame, then extract the two fields (odd and even lines) out of it and finally send both fields separately through the VPBE in BT.656 format. If that is correct, both fields belong to the same original frame and that would mean they were captured at the same point of time. That's why I thought the stripes shouldn't be there. What's wrong in my reasoning? Does it mean that each field (inside the same BT.656 frame) belongs to a different "original" frame?

Thanks for your patience!

There's something I've just realized! My application in DM355 manages video captured at 30 frames per second and I'm outputting BT.656 video in PAL format, which means 25 frames per second. I've read something about pull-down 2-3 when converting cinema video (24 fps) into NTSC (30 fps). As I don't know how DM355 is downscaling the frames per second, I guess this could be related to the problem I'm seeing. Any idea how DM355 might be converting the frame rate? I'll try to check this effect.

R&D said:

So I thought the interleaving process (in this case applied to BT.656 conversion) was to take a whole progressive frame, then extract the two fields (odd and even lines) out of it and finally send both fields separately through the VPBE in BT.656 format. If that is correct, both fields belong to the same original frame and that would mean they were captured at the same point of time. That's why I thought the stripes shouldn't be there. What's wrong in my reasoning? Does it mean that each field (inside the same BT.656 frame) belongs to a different "original" frame?

If your source was progressive (i.e. 480p@30fps) than this would be the case however your video looks like it was interlaced to start, and based on your mentioning of using a video loopback demo as a base on the DM6437 EVM I suspect you are capturing an interlaced signal, as the hardware/drivers/demo would have to be modified to capture a progressive signal. To capture a progressive signal you would need to be able to capture component video which is not possible on the DM6437 EVM (it only supports composite and S-Video capture), so you would need some custom hardware.

R&D said:

There's something I've just realized! My application in DM355 manages video captured at 30 frames per second and I'm outputting BT.656 video in PAL format, which means 25 frames per second. I've read something about pull-down 2-3 when converting cinema video (24 fps) into NTSC (30 fps). As I don't know how DM355 is downscaling the frames per second, I guess this could be related to the problem I'm seeing. Any idea how DM355 might be converting the frame rate? I'll try to check this effect.

Are you saying that you are capturing video from NTSC and displaying it as PAL? The drivers in the DM6437 are not particularly aware of rate differences between the source and display, so any special timing you want to implement would be done in your video processing code. With a typical loop back what would happen is that you would end up skipping a frame every so often on the PAL side, since the capture and display drivers operate continuously and asynchronously to each other. If the capture is at 30fps and the display is at 25fps and you are just constantly looping from capture to display you would end up dropping every 6th frame on the capture side (25:30 -> 5:6 so you need to drop 1/6th of the incoming 30fps frames). However NTSC and PAL also have different vertical resolutions so you would have to deal with that as well.

Note that if your source is a DVD player, even if it says it is a 'progressive' DVD player it will only output interlaced content on the composite and S-Video outputs, to get a progressive output from the DVD player you need to use component connections. If your original content on the DVD was a 24FPS film that was converted to interlaced through 2:3 pulldown than you would have to perform a reverse telecine to get back the original frame, though I do not know of any algorithms on the C64x+ to handle this operation.

Bernie Thompson said:

If your source was progressive (i.e. 480p@30fps) than this would be the case however your video looks like it was interlaced to start, and based on your mentioning of using a video loopback demo as a base on the DM6437 EVM I suspect you are capturing an interlaced signal, as the hardware/drivers/demo would have to be modified to capture a progressive signal. To capture a progressive signal you would need to be able to capture component video which is not possible on the DM6437 EVM (it only supports composite and S-Video capture), so you would need some custom hardware.

Yes, my original source is progressive so I guess that's the case. There's no problem about working with interleaved format between both processors as long as I solve the stripes issue.

Bernie Thompson said:

Are you saying that you are capturing video from NTSC and displaying it as PAL? The drivers in the DM6437 are not particularly aware of rate differences between the source and display, so any special timing you want to implement would be done in your video processing code. With a typical loop back what would happen is that you would end up skipping a frame every so often on the PAL side, since the capture and display drivers operate continuously and asynchronously to each other. If the capture is at 30fps and the display is at 25fps and you are just constantly looping from capture to display you would end up dropping every 6th frame on the capture side (25:30 -> 5:6 so you need to drop 1/6th of the incoming 30fps frames). However NTSC and PAL also have different vertical resolutions so you would have to deal with that as well.

It's not that I'm capturing video from NTSC, but video in HD @ 30fps. And then I'm "displaying" it (well, in fact I'm sending it through the VPBE to the other processor) in PAL. I wasn't sure about the way DM355 was converting the frame rates from 30fps to 25fps. So you mean it's only a simple skipping of every 6th frame? I thought there might be a kind of "pull-up" conversion (as opposite to 2-3 pull-down) in which some of the  original frame's fields (30fps) were being mixed to obtain the resulting video (25fps). But if the conversion consists only of skipping one out of every six original frames, my reasoning for the stripes is not correct because I thought they were due to what I call the "pull-up".

R&D said:

It's not that I'm capturing video from NTSC, but video in HD @ 30fps. And then I'm "displaying" it (well, in fact I'm sending it through the VPBE to the other processor) in PAL. I wasn't sure about the way DM355 was converting the frame rates from 30fps to 25fps.

I am a bit confused, your first post in this thread mentioned you were using the DM6437 EVM for a loopback which implies you could only be working with SDTV signals, and I am not sure where the DM355 comes in, I am not seeing the big picture of your system.

R&D said:

So you mean it's only a simple skipping of every 6th frame? I thought there might be a kind of "pull-up" conversion (as opposite to 2-3 pull-down) in which some of the  original frame's fields (30fps) were being mixed to obtain the resulting video (25fps). But if the conversion consists only of skipping one out of every six original frames, my reasoning for the stripes is not correct because I thought they were due to what I call the "pull-up".

If you were doing a pull up operation you would know as it would be in your video processing loop, the capture and display drivers themselves are independent and not aware of any type of pull down operation for frame rate synchronization. Essentially the both the capture and display drivers will post on the loop as soon as they have a new frame available or need a new frame for display, so if you are pending on both than it will just work out that every 6th frame never makes it to the display because the display will have requested a frame twice during a single frame period of the capture.

Bernie Thompson said:

I am a bit confused, your first post in this thread mentioned you were using the DM6437 EVM for a loopback which implies you could only be working with SDTV signals, and I am not sure where the DM355 comes in, I am not seeing the big picture of your system.

Sorry for the confusion. My custom design consists of an image sensor capturing video at 30 fps for DM355. Then DM355 passes the video to DM6435 at 25 fps (PAL). The use of the loopback was justified to check possible mistakes in my custom application when passing the video between processors.

Bernie Thompson said:

If you were doing a pull up operation you would know as it would be in your video processing loop, the capture and display drivers themselves are independent and not aware of any type of pull down operation for frame rate synchronization. Essentially the both the capture and display drivers will post on the loop as soon as they have a new frame available or need a new frame for display, so if you are pending on both than it will just work out that every 6th frame never makes it to the display because the display will have requested a frame twice during a single frame period of the capture.

Ok, I understand. Then I guess I have no reasons to believe the stripes are due to this. It's a pity because I liked my own theory...

Hi,

I have encounted the same problem on DM6437 and DM648 with NTSC input signal.

Since the stripes issue cannot be avoided without additional CPU de-interlace effors, how can I just get the consecutive "fields" (720x240) in the input port? And after processing these "fields", how can I send the processed "fields" to the output port and it will be combined to a frame automatically? If so, will the stripes issue still exist?

Is that possile with DM6437 and DM648 EVM board? Thanks!