[Openchrome-users] cle266: time spent in XvMCPutSurface() is longer than frame duration

[Reinhard Nissl]

Hi,

Mark Zimmerman wrote:

> I have been looking at the same code in an attempt to cure excessive
> frame drops on system with an nvidia card. The first thing I
> questioned was the unconditional sleep between frames, but I made no
> attempt to measure and report the elapsed times for fear of perturbing
> the system I was trying to measure. Are you sure that the time spent
> doing I/O is not affecting performance?

Hhm, the source for the stream is DVB, but for any reason, there is
always something little which the system writes to the hard disc (commit
interval 5 seconds). Do you mean that this disk I/O happens that
precisely that it always hits at dt9?

Regarding your NVIDIA card: I did myself some research about 3 weeks
ago. Here are my findings:
- the driver provides only 8 buffers.
- 2 are used in the decoder and 2 in the output driver (although only
one is actually used).
- 1 frame may get stuck in the video buffer pool for size mismatch.
- the frame draw code starts to drop frames if there are less than 4
frames ready for display.

As a result, frames are dropped over and over. I've "fixed" these issues
and it playes on my machine now without frame drops. But the fixes need
some cleanup before a patch can be posted.

> I made a small change that subtracts the elapsed time to render the
> first field from the sleep time and it largely cured my frame drops.
> The following patch applies to xine-lib-1.1.3 (your code seems to be a
> different version).

Well, your patch does the same as mine, and really is a big improvement.

> Also, I did something else that seemed to improve smoothness (although
> I have no measurements to prove it). I spent some time tweaking my
> modeline until I had a refresh rate that was an exact multiple of the
> 1080i frame rate. (90000/1001 = 89.91 works best for ATSC material).
> You might try something similar based on the frame rate of your source
> material.

You are right that the refresh rate has some influence on that issue.
When one schedules a picture every 20 ms, but the refresh rate is a
little bit below 50 Hz, then there will be a point in time where two
pictures are waiting to be displayed a the next retrace and the driver
spins until it can show one picture on screen. You can see this effect
in my output when dt4 and dt9 are at ~20 ms.

In my case, I want to use the S-Video connector so the driver uses fixed
mode lines.

BTW: are there driver developers on this list?

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de