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

[Thomas Hellström]

Reinhard Nissl wrote:

>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?
>
>  
>
Yes. Just back from vacation.

Need to take some time to read up.

/Thomas


>Bye.
>  
>