dm816x preview performance issue

Hi,

Does anyone can give me a response?

thank you.

Jacson

Jason,

Do you have a video showing the issue?

When the capture and display are asynchronous to each other then you will always see some degree of stuttering. This is not a performance issue, but the fact that the capture frame rate is not synchronous to the display frame rate.

This is just one possibility though, so it would really help to see what the stuttering looks like.

BR,

Steve

Hi Steve,

Thanks for your reply,

How do I make sure synchronous between capture and display?

How do I avoid the stuttering appearance in this architecture?

You can see this problem when you use an analog video input that content has word moving horizontal.

Thanks,

Jacson

If the source is coming from a completely asynchronous source (i.e. not from e.g. a CMOS camera which is clock sourced from the same clock as the display output) then there is no way  to synchronize the output to the input.

This is a general system problem and not a device specific problem.

The root cause is really that the display must output a stable signal and if it is dependent on the input then any variations at the input would affect the output. Startup and signal disconnect/re-connect cause discontinuity issues too.

The source of the video and the display have different reference clocks so even if both have, for example, 20MHz reference clocks with 10ppm stability they will still drift with respect to each other. This causes very slight variations in their frame rates. You can't control the source frame rate since you don't have access to the reference clock to synchronize to it, but you can't mess with the display clock since you must generate a solid and stable output.

Having said this, if you know for 100% that the input is good, solid, stable and does not have any jitter, gaps, changes etc... then you could potentially use the decoded clock as a reference clock input for the display sub-system. This will give what is called a gen-locked system where it is then possible to synchronize the output to the input, but it is not recommended unless you can guarantee the input signal stability very accurately since any disruptions of the input filter through to the output in unexpected ways. These issues become even more of an issue if the outputs are analog and not fully clock synchronous. Gen-locking only really works if the entire system from start to end is clock synchronous.

In the system where you re not gen-locked then there is no way to avoid frame skip/repeat, which manifests itself as stutter.

BR,

Steve

Hi Steve,

Thanks for your patient reply,

I think this should not be a clock issue, because the clock drift should be very very small than the display frame update time 33msec, we just need 30 frame updated per second.

I doubt the mosaic can't complete preparing frame on time. Is it reasonable?

|  |  |  |  |  |  |  |  |

capture time interval

              |    |    |    |    |  

             deinterlace output

                                     |    |    |    |    |    |

                                     mosaic

                                                         |    |    |    |         |    |

                                                         display       stutter

Thanks,

Jacson

The problem is that "very, very small" is correct, but it is also very, very fast.

Even with 20ppm crystals at 75MHz you will get visible stuttering.I can also guarantee that the input and output clocks are not within 20ppm of each other.

This is not an issue about the amount of time taken to process things it is to do with asynchronous input and output. Even if the processing was completed in an infinitely small time the input and output rates are different. In your picture above remove the "deinterlace output" and "mosaic" so that display sits under capture. The display WILL NOT align exactly between the input and output. One WILL be faster than the other so you will either skip an input frame or skip an output frame at some point. Typically this will happen once every second or so.

Is the stuttering a lot more often than once a second? Approximately how often does it happen?

I really need to see the stuttering though to try to determine if this is really just async stuttering or something else. The problem is that if you take a video of it then the exact same problem will occur with your video camera and the display, i.e. your camera capture rate will be different to the monitor display rate. Sometimes you can see the issue, sometimes things just look a mess. You could try though.

BR,

Steve

Hi Steve,

Thanks for your explanation.

The stuttering appear in analog path is not acceptable by the customer, customer hope watch the video like as analog direct input to the TV.

So we need to find method to resolve the issue, else we can't make this as a product to sell.

Can we trouble you to spend some time to check this issue is really just async stuttering or something else?

This stuttering is a lot more often than once a second. I think you can easy reproduce on your side.

Thank you very much!

Jacson

What is your exact setup and software?

Have you written your own application software or are you using the stock examples?

If you can tell me exactly what you have setup I will try to find someone to reproduce it here.

If the issue is async input to output then there is no solution other than those I mentioned, but if the stuttering is more often than once a second or so, then it sounds like it may be something different.

BR,

Steve

Hi Steve,

I am using RDK 01.08.00.15 and my hardware is dm816x evm + vs daughter card. The demo code usecase 1 can be easy reproduced, you can find stuttering in preview channel 1x1 display layout. You must use news ticker as analog source to feel stuttering.

Thanks for your help,

Jacson