185.19 + VDPAU blit path == stall

[Stephen Warren]

I just took a look at the code, and indeed the code that uses get_time to pass into vdp_queue_display is only for interlaced clips with deinterlacing enabled as far as I can tell.

To people who're experiencing this problem:

1) If you configure your system to allow usage of the overlay presentation queue, does the problem go away?

2) If you disable de-interlacing, does the problem go away?

3) If you play progressive rather than interlaced content, does the problem go away?

4) Is the problem always in the same place in the file, or is it random?

Thanks.

[jusst]

Originally Posted by Stephen Warren

1) If you configure your system to allow usage of the overlay presentation queue, does the problem go away?

Have to test that.

2) If you disable de-interlacing, does the problem go away?

Yes, after current_time was set to 0 for the first vdp_queue_display call.

3) If you play progressive rather than interlaced content, does the problem go away?

Yes, after current_time was set to 0 for the first vdp_queue_display call.

4) Is the problem always in the same place in the file, or is it random?

Seems random

[Stephen Warren]

I'm a little confused the code basically says:

if interlaced and deinterlacing and some other stuff
time = vdp_queue_get_time
vdp_queue_display(time)
vdp_queue_display(time + delta)
else:
vdp_queue_display(0)

So surely if deinterlacing is disabled, or the clip is progressive, there's no need to modify the code to hard-code a 0 parameter?

One more question:

Does this only happen for 25fps material or anything? I'm not sure I have anything that's all of interlaced, 25fps, and long enough to repro this.

[jusst]

Originally Posted by Stephen Warren

I'm a little confused the code basically says:

if interlaced and deinterlacing and some other stuff
time = vdp_queue_get_time
vdp_queue_display(time)
vdp_queue_display(time + delta)
else:
vdp_queue_display(0)

So surely if deinterlacing is disabled, or the clip is progressive, there's no need to modify the code to hard-code a 0 parameter?

One more question:

Does this only happen for 25fps material or anything? I'm not sure I have anything that's all of interlaced, 25fps, and long enough to repro this.

Sorry, was wrong with one of my answers. Disabling deinterlacing fixes it in any case.
I reproduce it here with 50i dvb transmissions. But any interlaced coded DVD should do it as well I think. It happens almost instantly for me, never more than a minute.

[Stephen Warren]

Odd. I can't reproduce this...

[jusst]

Stephen, have you still not been able to reproduce this? - On 185.19 running a KDE4 session I can reproduce this in less than 5 minutes in any case when running xine -D somefile.
Actually I test on a system with TwinView enabled, maybe that is relevant?

[Stephen Warren]

I just tried with TwinView enabled (DVI 1600x1200 60Hz + CRT 1024x768 87Hz interlaced), and played back 10-15 minutes of MPEG-2 interlaced DVD with de-interlacing enabled. I tried twice; with the presentation queue configured to sync to DFP once and CRT once. I couldn't see any issue. Sorry!

[Stephen Warren]

Just out of curiosity, can you run nvidia-settings and observe the values on the PowerMizer page. Do you have multiple performance levels? If so, does the GPU get into a higher performance level when running xine? Does running glxgears, or some other OpenGL application, at the same time as video help at all? Thanks.

[Stephen Warren]

Are people still seeing this issue with the latest 185.* drivers? If so, could somebody try the PowerMizer experiment I mentioned above; it'd be greatly appreciated. Thanks!

[jusst]

Hi Stephen,

sorry, I missed out the question you posted previously...
I just updated to 185.18.10 and the problem seems to persist... It might happen less frequent thought. But I get tearing all the time.
The PowerMizer stays at Performance Level 0 (Maximum Performance) all the time. The GPU is a 8400GS.

Regards,
Julian

[Jotti]

Unfortunately, yes, the issue is still here. After 2 minutes of H.264 video I had another stall of about 3 seconds... quite annoying A beta NVIDIA driver that I was running a couple of months ago did not have any stalls whatsoever, but libxine has been updated several times in the meantime as well, so I am not sure what to make of that.

My system is a Core2Quad Q9450 at 3.2GHz running Debian AMD64 (testing) with KDE4.2 with compositing enabled, powered by a GTX280. The following may sound a bit incoherent, but I will post my findings for the sake of completeness anyway.

nvidia-settings reported the video card in the highest performance level (for whatever reason) before starting the video. nvidia-settings still reported this after the stall occured. Starting a second video file and running glxgears alongside the (fullscreen) video introduced some noticeable tearing. And then another stall. When I paused the video to reply to this topic, I closed glxgears and saw the performance level had dropped to the lowest level. When I hit space to resume xine, the whole video window went haywire and I had to send a SIGTERM to close it.
A second attempt showed the GPU in the lowest performance level (no clue why this had suddenly lowered). This did not change after starting the video, which did not seem to 'suffer' at all from the lower clock speeds, but I guess the GTX280 is a powerful GPU I restarted nvidia-settings a couple of times to verify the lower peformance setting.

[Stephen Warren]

Originally Posted by jusst

The PowerMizer stays at Performance Level 0 (Maximum Performance) all the time. The GPU is a 8400GS.

If you have multiple performance levels, then level 0 is the minimum performance (don't confuse this with the "Performance Mode" display, which vaguely controls the max performance level the card can be placed into). Does starting glxgears kick it up to level 1 or higher?