nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   VDPAU video surface destroy takes too long (http://www.nvnews.net/vbulletin/showthread.php?t=155889)

seaweed 10-08-10 12:15 PM

VDPAU video surface destroy takes too long
 
Sometime even hang on that call. What would be the reason for it? First thing comes to my mind is there is a reference frame thats currently in use. But I stop decoding prior to destroy the surfaces so what else I can do to force a video surface to destroy?

Stephen Warren 10-08-10 02:15 PM

Re: VDPAU video surface destroy takes too long
 
That's odd. I haven't observed anything like this, nor heard any other reports of the problem. Are you able to reproduce this with a simple test-case application? Are you sure that the actual VDPAU driver call is taking the time; there's nothing else within your application included between timing calls, and nothing else on the system that delays when your program runs?

seaweed 10-13-10 02:21 PM

Re: VDPAU video surface destroy takes too long
 
Quote:

Originally Posted by Stephen Warren (Post 2329349)
That's odd. I haven't observed anything like this, nor heard any other reports of the problem. Are you able to reproduce this with a simple test-case application? Are you sure that the actual VDPAU driver call is taking the time; there's nothing else within your application included between timing calls, and nothing else on the system that delays when your program runs?

Hi Stephen, I found the problem, we do a lot of switching of video sources and it turned out VDPAU was causing green background flash between switching, so one of my colleague created a new window and destroyed the old window to supress the green window popping up, followed by the VDPAU destroy. Causing the window destroy while VDPAU device is still open caused the problem. I reversed the order and it got fixed, however we are back in square one, which is green flash.

If I set the background to {0,0,0,1} the green is replaced by black however some weird artefacts show up on the screen - part of the old display is stays while remaining part if updated with the new video (probably because of alpha's?).

Stephen Warren 10-15-10 11:12 AM

Re: VDPAU video surface destroy takes too long
 
If your window is going to be the same size each time, there's no need to destroy the window or presentation queue at all, and probably not the output surfaces either. This should avoid the green flash.

If your video streams are the same size, there's no need to destroy the video mixer or video surfaces.

Still, I can see how it might be simpler to tear everything down again and start from scratch.

In that case, setting the presentation queue background color to approximately black will make the flash black instead of green. The background color alpha isn't used. What's happening is that the background color is actually the overlay chroma key color, so you may just be seeing parts of the overlay showing through, when something the same color is drawn over the top of the window.

If that's not the issue, could you post a screenshot or photo of the issue? A small repro case might be useful too, if the overlay chroma key explanation isn't the problem.

seaweed 10-19-10 01:20 AM

Re: VDPAU video surface destroy takes too long
 
Quote:

Originally Posted by Stephen Warren (Post 2332308)
If your window is going to be the same size each time, there's no need to destroy the window or presentation queue at all, and probably not the output surfaces either. This should avoid the green flash.

If your video streams are the same size, there's no need to destroy the video mixer or video surfaces.

Still, I can see how it might be simpler to tear everything down again and start from scratch.

I need to create windows in different form factors, one to many. So yes I need to tear everything down and reconfigure every time a switching happen.

Quote:

Originally Posted by Stephen Warren (Post 2332308)
In that case, setting the presentation queue background color to approximately black will make the flash black instead of green. The background color alpha isn't used. What's happening is that the background color is actually the overlay chroma key color, so you may just be seeing parts of the overlay showing through, when something the same color is drawn over the top of the window.

If thats the case, I don't know how to solve this puzzle, even if there is a way I could set a particular chroma key for VDPAU via the background RGB values, there will be always a chance that the key will be an exact match for some decoded RGB value of a video source and in that case those pixels in the background will show up thru the video frames - Am I correct on this? I have seen this already actually. Disabling compositing (non-overlay mode) did not fix it.

Quote:

Originally Posted by Stephen Warren (Post 2332308)
If that's not the issue, could you post a screenshot or photo of the issue? A small repro case might be useful too, if the overlay chroma key explanation isn't the problem.

I will try to pm you some screenshots. I think I have a temporary fix for now by setting background alpha to 1 and by recreating the child window right after presentation queue destroy.

Stephen Warren 10-25-10 12:54 PM

Re: VDPAU video surface destroy takes too long
 
The content of the video stream is unrelated to the chrome key value; the video stream can never cause itself to be shown/hidden.

The chroma key value (i.e. presentation queue background color) is a color painted into the desktop surface (i.e. drawn into the presentation queue target window) that will cause the video to show up.

The only possible issue with chroma keying is: If some other window (i.e. not the presentation queue target) is moved over the top of the presentation queue target window, then that other window should be completely visible and occlude the presentation queue target entirely. However, if that other window is painted (or partially painted) the same color as the chroma key, then video may show over that window instead of being occluded.


All times are GMT -5. The time now is 07:58 PM.

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