04-03-2018 03:02 AM
We are working on Artix-7 based video processing board having one PAL Decoder and an SXGA OLED Display. Since the output of Decoder is incompatible with input of Display, we are using XAPP931 to convert YCbCr Input Data to RGB format. I have confirmed that the values of constants used for conversion is same as defined in PG014 AXI based IP.
During the operation, we are not getting correct output video on the display. Two main issues are observed:
1. Video is not stable. It is moving in horizontal direction. The main reason could be loss of synchronization but the delay created in sync signals are observed to be correct.
2. The color reproduction is not perfect. There are black patches in half the area of active video. Also the current visible data color is not perfect.
Can somebody please help to solve this issue.
04-03-2018 10:08 AM
Hello @tarun.kumar ,
You didn't include details of your video processing path, but from your description, it sounds like you are just taking the output of your PAL decoder and running it into a colorspace converter and sending that to the SXGA display. If this is the case, it won't work, because the decoded PAL video does not match the SXGA standard of your display..
I don't know which decoder you are using, but most PAL/NTSC video decoders typically put out a parallel 8- or 10-bit video signal which is formatted as 4:2:2, which means the luminance (Y) is sampled at half the 27MHz clock frequency (13.5MHz) and the baseband chroma components are sampled at one-quarter the clock frequency (6.75MHz each). If the output is an 8-bit BT.656 stream, it is interleaved like this: Cb0,Y0,Cr0, Y1, Cb2,Y2, Cr2, Y3... The chroma components are co-sited with the corresponding luma pixel, and there is an extra luma pixel between every co-sited pair.
In addition, PAL and NTSC are interlaced video standards, which means that odd lines are displayed in one field, and even lines are displayed in the next field. The eye integrates the image into a smooth display. The image has 720 active horizontal pixels and 480 active vertical lines for NTSC (720x480), or 720 active horizontal pixels and 576 active vertical lines for PAL (720x576). Since the image is interlaced, there are 240 lines in each field for NTSC, and 288 lines in each field for PAL.
SXGA video, by contrast, is 4:4:4 RGB progressive-scan format, which means there is an R, G, and B pixel for each sample. The clock rate for SXGA60 (60Hz SXGA) is 108MHz, and it has 1280 active horizontal pixels, and 1024 active vertical lines (1280x1024). The image is not interlaced, it is progressive-scan, so there are 1024 active lines in each field.
In order to display PAL or NTSC decoded video on an SXGA screen, you have to do several things:
First, you must convert the 4:2:2 Y/CbCr video to 4:4:4 RGB video, This is done using a chroma resampler, which up-samples the Cb and Cr components to match the sample rate of the Y pixels, followed by a colorspace converter, which converts the resulting 4:4:4 Y/Cb/Cr to 4:4:4 RGB.
After these two steps, you have RGB 4:4:4, video, but the image is still interlaced at 720x240 (480i) or 720x288 (576i), so you have to use a deinterlacer to convert the image to progressive-scan video at 720x480 or 720x576.
Lastly, since SXGA is 1280x1024, you have to run the 720x480 or 720x576 video into a scaler to scale it to match the size of the SXGA display.
If you are doing the above steps and it still doesn't work, post a description of your video processing path to aid in diagnosing the problem.
04-03-2018 06:32 PM
Would you show more detail information (block diagram and video timing) ?
> 2. The color reproduction is not perfect. There are black patches in half the area of active video. Also the current visible data color is not perfect.
I guess that it seems 422 issue.
04-03-2018 09:49 PM
Thanks for the reply. My path includes digital video output from ADV7180 Video Decoder which is giving 20 bit YCbCr 4:2:2 output. Next I am upsampling it and then sending it to RGB Converter IP. At this point we have 4:4:4 RGB and its timing with us. The OLED Display we are using is SXGA096 from EMagin.
We are sending it through its LVDS Channels after proper conversion. I am unsure that we need to change format from PAL to SXGA. The display should show it in a area of size of PAL Standard.
04-04-2018 01:35 AM
I'm sure that you need convert video format from YUV 4:2:2 to YUV 4:4:4 before RGB converter IP.
If no, a horizontal resolution is a half of your expected value.
Would you make sure it ?
04-04-2018 02:02 AM
Yes, we have ensured that the 4:2:2 format is first changed into 4:4:4 before conversion to RGB. We are observing the output of almost the same size as expected in the horizontal direction.
Output from Video Decoder first goes through Upsampler and then through RGB Conversion Module. We are not using DeInterlacer and scaler after this. We are directly connecting our RGB Output to a transmitter module of OLED.
04-04-2018 08:00 AM
To reiterate, you are using an ADV7180 decoder in 16-bit parallel Y/CbCr mode at 13.5MHz LLC clock (there is no 20-bit mode according to the datasheet, so I assume you meant 16-bit). You are then sending the 16-bit Y/CbCr data to a chroma resampler followed by a colorspace converter, which results in 24-bit RGB 720x576 interlaced PAL 50Hz data, which you then format as LVDS and send to the SXGA-096 display, which expects 1280x1024 60Hz progressive-scan data.
If you look at the datasheet, which I found here:
you will find the following specifications on page 12 of the pdf, Table 5-4:
As you can see, the video clock frequency has a minimum specification of 44MHz. You are sending a 13.5MHz clock, which is clearly in violation of the spec. In addition, the horizontal frequency has a minimum specification of 30kHz. PAL video has a horizontal frequency of 15.625kHz, again way outside the minimum specifications for the display.
If you look at Table 5-5 on page 16 of the pdf, you will find the recommended video input timing characteristics:
As you can see, they recommend a standard 1280x1024 60Hz RB, progressive-scan input at 91kHz. Your 720x576 60Hz interlaced signal is nowhere near correct for this display.
While it is true that some LCD displays will work at resolutions other than the intended specification, usually displaying in a corner of the screen, you can't always guarantee that you will get functional results when grossly violating the input specifications. It may be good enough for a quick test of the datapath if that is all you are going for.
I'm not sure what your goals are with this, but if you want to see if that display is running correctly, the proper way to debug something like this is to start at the back and work your way to the front. Start with a simple sync generator running at the recommended 91MHz clock, with the recommended H and V timings shown in Table 5-5. You can use an 8-bit counter that resets on the H sync edge to generate the 24-bit RGB data (replicate the 8-bits for each of the three R,G, and B components), and the result, if your LVDS conversion and sync generator is correct, should be a series of 5 monochrome ramps across the screen (1280/256 = 5).
Once you have this horizontal ramp image correctly displaying on your screen, you can then change your sync generator to match your input resolution of 720x576 50Hz at 13.5MHz, but make it progressive scan. If this image displays in a corner of the screen, you will know the display is capable of processing this resolution at the 13.5MHz clock, even though it violates all the datasheet specs.
If that works, then change the vertical counter to display a 720x288 interlaced image and see if that will display. If it does, then you can work backwards toward your decoder, substituting your test pattern generator for the video signal as you go along, until you get to the decoder, debugging any problems as you find them.
Again, the proper way to process this is with a deinterlacer and scaler to convert the PAL 50Hz interlaced video to a progressive-scan SXGA 60 image. You should be able to run the display at 50Hz, so you won't need to convert the 50Hz video to 60Hz, but you will have to adjust your output timing and clock rate to match the 50Hz vertical rate.
04-04-2018 12:55 PM
Yeah Its true that the current specification is way below the standard specification given in the datasheet. But, we have proceeded quite like you suggested from back to front. First, we did provide a pattern using counters for HSYNC and VSYNC for a 1280*1024 resolution at 91MHz. Then with 720*576 resolution also with 27 MHz clock. In both cases we are getting intended outputs. In first case a complete Image on OLED and in second in a corner part of display.
We havenot performed the test for 720*288 Interlaced scenario. We will certainly do it.
But the first two scenario do imply that the OLED Display is capable to handle the frequency below specidied levels in the Datasheets.
04-10-2018 06:27 AM
Any updates on this? Did you do the test following the datasheet?
04-17-2018 01:18 AM
If everything clear for you on this subject, please kindly close the topic by marking one reply as accepted solution.
Thanks and Regards,