I am using the ADV7184 back to back with an ADV7341, to add an RGB overlay over CVBS. I find that when pixels are isolated, with no adjacent pixels in the same line, they are considerably dimmer. This means that vertical lines appear dark and text is of inconsistent brightness.
I thought this may be the the encoder attempting to filter noise, so I experimented with various DNR gain levels and filters but I did not notice a difference.
Here is an example, note how the vertical and diagonal lines in the image are much darker than the horizontal lines.
Is there some way to avoid or mitigate this effect, and have all overlay pixels of the same brightness?
ADV7184 fast blanking could be used to overlay with dynamic switching using the FB pin. For that to work both the RGB and the NTSC/PAL must have identical timings. It may be the reason by without setting the FB pin to a logic "1" for every pixel you want blended from RGB onto the CVBS.And also refer Pages 16-18 for more information the ADV7184 data sheet.
Thanks for your reply. I am setting the FB pin to logic 1 for active pixels, and I am deriving the RGB timings from the CVBS sync. Pixels are appearing as expected, except for dimness issue. Just wondering if you can point me in the direction of any settings for the encoder or decoder that could help to reduce this?
Please crosscheck the encoder and decoder clocks.To Selecting the clock frequency one over the other may be desirable in systems in which board cross talk between different components leads to undesirable interference between video signals. It is recommended to use a crystal of frequency 28.63636 MHz to clock the ADV7184. Is this issue reproducing from encoder or decoder side?
Here is what I have found so far.
Enabling/disabling CTI in the decoder makes no appreciable difference.
Enabling/disabling DNR and changing the gain in the encoder makes no appreciable difference.
Enabling FB Edge Enhancement makes the effect slightly worse (although barely noticeable), and the effect becomes worse as edge enhancement level is increased. I would have expected the opposite.
Slowing down the pixel clock for the RGB overlay does improve things because the overlay pixels become wider and chroma has more time to stabilise, but the result is decreased horizontal resolution and rectangular pixels.
I am clocking the decoder with a 28.63636 crystal and I'm not encountering crosstalk.
I can't tell at this stage whether the effect is occurring in the encoder or decoder because I don't have a way to capture the digitized video stream from the decoder and display it. However the effect does not go away if I change the output of the ADV7341 from CVBS to YPbPr, which suggests that it is occurring within the decoder/encoder circuit rather than limitation in chroma bandwidth when decoded by the video monitor.
It is also definitely a chroma effect, I don't notice a problem with white or grey overlay text.
Do you have any other suggestions?
Please try to adjust the chroma filter register to set different bandwidth in both encoder and decoder part.Refer ADV734x datasheet, here chroma filters listed in table 43 and the ADV7340/ADV7341 contain an SSAF filter that is specifically designed for the color difference component outputs, Pr and Pb. This filter has a cutoff frequency of ~2.7MHz and a gain of –40 dB at 3.8 MHz (see Figure 62). This filter can be controlled with Subaddress 0x82, Bit 0.Please refer chroma filter section in the ADV7184 datasheet . Note : Chroma Shaping Filters (CSH):The shaping filter block (CSH) can be programmed to perform a variety of low pass responses. It can be used to reduce selectively the bandwidth of the chroma signal for scaling or compression.
Thanks Poornima, I will give that a go and post the results here.
Unfortunately the Chroma Shaping Filters don't appear to make any difference to the SCART output no matter which one I try. Also, the SSAF filter makes no difference. It looks like I am going down the wrong track. Just wondering if there is anyone who has been involved with this type of video application who can comment?
This is related to Chroma filter configuration,So we suggested that one.
And also please cross check Vertical Blank Control section for chroma text setting NVBIOCCM [1:0],BL_C_VBI, Blank Chroma During VBI, Address 0x04 
Note: NSFSEL [1:0] /PSFSEL [1:0] selects how much of the overall signal bandwidth is fed to the combs. A narrow bandwidth split filter results in better performance on diagonal lines, but more dot crawl in the final output image. The opposite is true for a wide bandwidth split filter.
OK, thank you Poornima for sticking with this issue. I will check the items you have suggested and double check the chroma filter config in case I am missing something.
Just wondering if you can clarify whereabouts in the image below the chroma shaping filter is applied?
Based on my reading of the datasheet I think this may be before the YPrPb subpixel blender. If this is the case then the CSH configuration will only affect the CVBS signal and not the RGB which is being overlaid.
I believe this may be the case because the diagram below appears to show the CSH is applied after digitization but before conversion to YPrPb.
I'm curious to know whether my reasoning is correct or not, could you please comment, thanks.
Yes, the CVBS signal is processed by the SDP and converted to YPbPr. The RGB signals are processed by CP section and it converted to YPbPr. And also CSH may cause the CVBS signal not RGB.
The CVBS signal is processed by the ADV7184 and converted to YPrPb. The RGB signals are processed by a color space converter (CSC),and samples are converted to YPrPb. Both sets of YPrPb signals are input to the subpixel blender, which can be configured to operate in any of the four modes.After digitization of the video signal and luma and chroma signal separated finally those signals are added
If this is the case, then changing the CSH configuration wouldn't affect the appearance of the overlaid video, and to resolve the issue with faint isolated pixels I would need to look further down the signal processing chain, unless I missing something?
If the overlay is being done over YPrPb video I would expect it to be immune to chroma issues, isolated pixels should appear no different to any other pixels, so presumably this issue must be happening either in the ADV7341 part or else the signal processing of my video monitor. I would also expect that if I feed component video from the ADV7341 to my monitor instead of CVBS and see the same issue, then that would rule out the monitor.
Any comments you have that can help narrow down the problem or shed light would be greatly appreciated.