Display periodically freezing at 1280 × 720 at 60 fps (pixel clock = 74.25 MHz)

Salim,

What you say 'freezing' do you mean that the image on the display simply stops, or is there some other artifact on the LCD, i.e. fading or corruption?

Basically all the DSS does is dump memory out to the LCD so if your LCD panel continues to actually display an image, even if it is a static image, then the issue is not with the DSS but with whatever is controlling the frame buffer.

It sounds to me like there is an issue with the syncronization between the capture and the display frame buffer management.

When you say "streaming a constant image", do you mean that you display a static image from a static frame buffer in memory? If so, then how are you determining that the display is freezing?

What happens when you try 1024x768@60?

Are you connecting the output through DVI to a monitor ? If so, are you 100% sure that your monitor supports the resolution you are trying to send.

Can you check the de, v-sync and h-sync signals with an oscilloscope to see if there is any disruption during the freezing periods?

BR,

Steve

Hi Steve,

Thanks for your reply.

Freezing means, it is just looks like it stops . If you see normally it looks like shaking. Not sure what exactly happening.

"Streaming a constant image", i had two buffer each has different value with small difference (filled only once). I could see a small difference in the display periodically. 

I tried 1024 * 768 @ 60 fps,  issue is occurring. But the periodic shaking/stop time changed from 3.8 sec  to 15.5 sec.

Yes, I am connecting the output through DVI to monitor and LCD also supports.

I already checked the HSYNC and VSYNC, there is no disturbance.

If the syncs are good then it implies that the issue is with the frame buffer management and not with the DSS hardware configuration.

The DSS hardware is 'dumb' and simply continuously sends a chunk of memory to the display.

I think there is most likely an issue with the synchronization between the capture events and the display events in the buffer management part of your code.

BR,

Steve

Hi,

I completely agree with Steve here, this can not be DSS hardware issue.I would consider freeze/stop as, same buffer is getting displayed multiple times OR application is not capable of filling the buffer at required rate.

Are you working on Linux OS? if yes, are you using framebuffer driver (/dev/fbX) OR V4L2 display driver (/dev/videoX) here? If it is Fbdev driver and with ping-pong buffer using WAITFORVSYNC ioctl, then I would recommend you to use WAITFORGO ioctl instead. There is an bug/known-issue we have discovered recently with WAITFORVSYNC which might lead to such behavior.

FAQ - http://processors.wiki.ti.com/index.php/OMAP35x_Linux_-_DSS_FAQ

 

Also, it again depends on how many buffers is being queued/dequued from capture and feed it to display driver and how? Is there some memory operation happening in between?

Thanks,

Vaibhav

Thanks Steve and Vaibhav. I am working with Win CE 6.0, direct show based camera application and driver. I would like to give more of my observation. Firstly my camera gives output at 59.94 Hz. It is a NTSC camera, i take the field separately so that i get 59.94 fps. I measured the camera VSYNC, it is 59.94 Hz. Now my display VYSNC is about 60 Hz for 1280 * 720 @ 74.25 Mhz. When i see the VSYNC's of camera and display there is a difference of about 0.06 Hz. In this case i see the frame missing for every 15.6 sec (1/0.0641Hz = 15.6). Similarly i checked with different Pixel clock, and blanking period. I checked with 1280 * 720 @ 59.80 Hz. In this case i see the frame missing for every 7.1 sec (difference in VSYNC is 0.14 hz, 1/0.14Hz = 7.15s). I also checked with different resolution and different display timing, there is a periodic frame missing. This period is the difference of the camera and display period. When I measured the VYSYC’s, I found that, this issue is occurring when the VSYNC of camera is at middle of the VSYNC’s of display or vice versa. For example if i take the 1280 * 720 @ 74.25 Mhz, 60 Hz and camera 59.94 Hz. In this case VSYNC of camera is at middle of the VSYNC’s of display for every 15.6 sec. I could also see that this frame dropping period changes. In 15.6 sec frame missing period (i.e. you can see frame missing continuously ) is more when compared to frame missing period for 7.1 sec. I have double checked in the camera driver there is no frame drop, whenever there is a frame drop i print message. I have used triple buffer to synchronise. There is no memory operation, i write the output (Resizer output ) directly to the buffer provided by application. There is no memcpy and no memory related API used.

Just to clarify...

What you say the display is freezing, do you mean it freezes for a long period of time or just for a single frame?

If the input and output frame rates are different then there is nothing you can do except skip/repeat frames. It is up to your buffer management code to either skip or repeat the appropriate frame buffer.

BR,

Steve

Exactly, consider both of them as separate and independent entities where you are getting buffer from capture and you are dumping it to display and that's where buffer handling mechanism comes into picture. From display perspective you should not miss any frames as long as you are unless application skips it.

Thanks,

Vaibhav

Thanks Steve and Vaibhav.

I did some testing and found some strange result. Below I have explained in detail.

 Actually my setup is, i get 704* 240 image from camera and the same is given as input to resizer and the resizer will do the resize to 704* 480. Then the resized output is given to display overlay. Resizer is enabled in the CCDC interrupt (VSYNC of camera) and the display overlay is updated at resizer done interrupt. This was my first setup. In this case, as i said earlier i see a frame missing periodically. As i said earlier, When I measured the VSYNC’s, I found that, this issue is occurring when the VSYNC of camera is at middle of the VSYNC’s of display or vice verse.

Now i changed the resizer enabling at the VSYNC of display instead of VSYNC of camera. In this case,i am receiving the resizer done interrupt but  when  "the VSYNC of camera is at middle of the VSYNC’s of display or vice verse", i am not receiving the resizer done interrupt and after that i am not receiving the resizer done interrupt.

I tried to reduce the dependency by removing the CCDC. Instead i gave a static two buffer (different value)  as a input to resizer and the output of the resizer is written to overlay. Resizer input is changed  at the VSYNC of display. And the overlay is updated at the resizer done interrupt. In this case i did not find the issue. Resizer is doing its job (i am getting the resizer done interrupt continuously) and the same is updated in the overlay without any issue.

But Now i added the CCDC but i used two different buffer sets. I just enabled the CCDC and the CCDC will update the data in the another buffer, whereas resizer will take the input from different buffer (constant value) and not from the CCDC buffer. Now there is no common buffer between the CCDC and resizer, both are working with different buffer sets. In this case i am able to see the issue. It is occurring when the VSYNC of camera is at middle of the VSYNC’s of display or vice verse. This clears that there is no buffer sharing issue.

Not sure whether any bandwidth is the issue or any relation with the VSYNC's or any other issue.

Thanks,

Salim

Dear Steve and Vaibhav,

The issue is solved.

It is because of the VSYNC mismatch betweent the Camera and display. Our camera has a facility to LOCK its VSYNC (i mean it can adjust its vsync +-1 Hz) with respect to another external clock. We have used this functionality and locked the camera VSYNC with respect to display VSYNC. This have removed the periodic frame missing.

Thanks to all.

Salim

Excellent.

Glad you are now working how you need.

This is an example of a classic synchronization problem and without the ability to control either the input or output frame rates there is not really a solution other than to skip or repeat frames.

Thankfully you can control the input frame rate.

BR,

Steve