nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   185.19 + VDPAU blit path == stall (http://www.nvnews.net/vbulletin/showthread.php?t=131201)

mlampard 04-06-09 11:25 PM

185.19 + VDPAU blit path == stall
 
1 Attachment(s)
Hi
I'm seeing stalls of up to 1 second when using VDPAU to play 25fps interlaced mpeg2 with VDPAU_NVIDIA_NO_OVERLAY=1. The stall appears every few minutes and no errors appear on any logs. After each stall, the video appears to fastforward to the correct position in the stream and everything goes on as normal.

VDPAU appears to halt in vdp_presentation_queue_block_until_surface_idle()

Stephen Warren 04-07-09 11:01 AM

Re: 185.19 + VDPAU blit path == stall
 
A few questions:

1) Are you sure your system is stable? I see a lot of applications crashing in your logs.

2) Which application are you seeing the problem in?

3) Does the problem only apply when playing back live data from your DVB card, or also when playing back pre-recorded files from disk. When playing back from disk, what if you quit all other apps that access HW (audio playback/capture, DVB card usage, etc.)

mlampard 04-07-09 12:29 PM

Re: 185.19 + VDPAU blit path == stall
 
Quote:

Originally Posted by Stephen Warren (Post 1977658)
A few questions:

1) Are you sure your system is stable? I see a lot of applications crashing in your logs.

2) Which application are you seeing the problem in?

3) Does the problem only apply when playing back live data from your DVB card, or also when playing back pre-recorded files from disk. When playing back from disk, what if you quit all other apps that access HW (audio playback/capture, DVB card usage, etc.)

1) Yes, the system is stable.. the crashes you see in the logs are not related.
2) tested with xine-vdpau revisions 255 and 248
3) The issue occurs with both live TV and pre-recorded mpeg2 videos, and DVD's. Stopping all hardware-related daemons etc made no difference.

Tests were run with the following commandline:
VDPAU_NVIDIA_NO_OVERLAY=1 xine --verbose -Vvdpau -Anone MRL://

Stephen Warren 04-07-09 12:44 PM

Re: 185.19 + VDPAU blit path == stall
 
OK. Can you also try MPlayer SVN please. Does/can xine produce a debug log; perhaps that might yield some clue. Finally, can you run xine/MPlayer from the console after having done this:

export VDPAU_NVIDIA_DEBUG=3

That might produce some extra debug information.

Thanks.

jusst 04-07-09 03:21 PM

Re: 185.19 + VDPAU blit path == stall
 
I can confirm this behaviour with xine-vdpau. I haven't tested mplayer yet, but couldn't spot a xine-specific problem yet. I will test a bit more the next days...

thefirstm 04-07-09 05:11 PM

Re: 185.19 + VDPAU blit path == stall
 
Works fine for me with the latest Mplayer SVN, but I cannot try Xine because this would screw up Ubuntu's configuration if I tried to compile the package.

hl_ 04-07-09 07:52 PM

Re: 185.19 + VDPAU blit path == stall
 
No problems with latest MPlayer. Maybe it is a problem of the VdpPresentationQueue? MPlayer doesn't fully use that, but xine-vdpau does as far as I know.

Stephen Warren 04-07-09 09:23 PM

Re: 185.19 + VDPAU blit path == stall
 
Both MPlayer and xine use the presentation queue, although it's entirely possible that they use it differently. MPlayer only queues a single surface, and uses a timestamp of 0. I thought xine did the same. Does xine now queue multiple surfaces and use actual timestamp values now?

Anyway, I'll try to repro this tomorrow...

mlampard 04-07-09 10:58 PM

Re: 185.19 + VDPAU blit path == stall
 
xine-vdpau currently uses:

vdp_queue_get_time( vdp_queue, &current_time );
vdp_queue_display( vdp_queue, this->output_surface[this->current_output_surface], 0, 0, current_time );

changing the above to the same as mplayer:

vdp_queue_display( vdp_queue, this->output_surface[this->current_output_surface], 0, 0, 0 );

does seem to work around the issue. Shouldn't the two be equivalent, or at least be handled the same regardless of blit/overlay path?

mlampard 04-08-09 07:39 PM

Re: 185.19 + VDPAU blit path == stall
 
Stephen, do you consider the above to be a valid use of vdp_queue_get_time(), or is it preferred to always use 0 as the timestamp when the frame is expected to display immediately?

Stephen Warren 04-08-09 09:24 PM

Re: 185.19 + VDPAU blit path == stall
 
It's certainly completely legal, and I do intend to repro this and get a fix if possible.

That said, it's pointless; specifying any past timestamp (including hard-coding zero, or one, etc.) is equivalent, and xine's usage as you showed it is simply specifying a timestamp just marginally in the past all the time, so it might as well hard-code 0.

jusst 04-09-09 03:59 PM

Re: 185.19 + VDPAU blit path == stall
 
In xine the timestamps are actually relevant for displaying deinterlaced material. The second vdp_queue_display call has an actual timestamp in the future.
That one can't be changed to 0 because it would lead to early shown second fields if the monitor refresh rate would allow that. (ie: watch 50i content on 100hz might give you: F1, F2, F2, F2, F3, F4, F4, F4, .... as the sequence of fields shown on display refresh)


All times are GMT -5. The time now is 04:10 AM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.