Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 04-13-10, 07:11 AM   #1
Dinges
Registered User
 
Join Date: Apr 2010
Posts: 3
Default VDPAU rendering delay

I'm running some tests to see how good vdpau can deal with realtime video. Getting a low delay between capturing the video and rendering it again is important.

Using VDPAU's own functions (VdpPresentationQueueQuerySurfaceStatus) I can see that the delay between VdpPresentationQueueDisplay and the surface actually getting displayed is between 45 and 62 ms on an NVIDIA ION chipset, with an Atom CPU. The video codec is VC1.

Is there some way to improve these numbers ?
Dinges is offline   Reply With Quote
Old 04-13-10, 11:56 AM   #2
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: VDPAU rendering delay

Dinges,

The timestamp that is passed to VdpPresentationQueueDisplay influences when the surface is presented. A value of 0 means "as soon as possible". What value are you using?

Also, surfaces can't be displayed until any rendering to those surfaces has completed. If you're primarily interested in presentation queue delay, you should just create some surfaces, use "put bits" to upload some content, and then keep flipping through the same surfaces.

With a timestamp of 0, and a 60Hz display, and no need to wait for rendering, I'd expect to see delays of at most ~17ms through the presentation queue.
Stephen Warren is offline   Reply With Quote
Old 04-14-10, 03:30 AM   #3
Dinges
Registered User
 
Join Date: Apr 2010
Posts: 3
Default Re: VDPAU rendering delay

Quote:
Originally Posted by Stephen Warren View Post
Dinges,

The timestamp that is passed to VdpPresentationQueueDisplay influences when the surface is presented. A value of 0 means "as soon as possible". What value are you using?
0

Quote:
Also, surfaces can't be displayed until any rendering to those surfaces has completed. If you're primarily interested in presentation queue delay, you should just create some surfaces, use "put bits" to upload some content, and then keep flipping through the same surfaces.

With a timestamp of 0, and a 60Hz display, and no need to wait for rendering, I'd expect to see delays of at most ~17ms through the presentation queue.
So in effect the decoding and rendering to the output surface takes up the most time and the variation is caused by vsync (with a max 17 ms).

I was kind of hoping that there is some way to feed the decoder the encoded VC1 data as it comes in, so it could get started the moment the data arrives and we don't have to wait for an entire frame.
Dinges is offline   Reply With Quote
Old 04-14-10, 12:31 PM   #4
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: VDPAU rendering delay

Quote:
Originally Posted by Dinges View Post
I was kind of hoping that there is some way to feed the decoder the encoded VC1 data as it comes in, so it could get started the moment the data arrives and we don't have to wait for an entire frame.
As soon as VdpDecoderRender is called, the decoding operation will start. I don't quite understand what you're saying above.
Stephen Warren is offline   Reply With Quote
Old 04-15-10, 04:44 AM   #5
Dinges
Registered User
 
Join Date: Apr 2010
Posts: 3
Default Re: VDPAU rendering delay

Quote:
Originally Posted by Stephen Warren View Post
As soon as VdpDecoderRender is called, the decoding operation will start. I don't quite understand what you're saying above.
Yes but before you can start decoding and rendering, you need to have the whole frame and capturing that takes some time. So if you could start the decoding while the capturing of the frame is still ongoing, you could reduce delay quite a bit.
Dinges is offline   Reply With Quote
Old 04-15-10, 10:32 AM   #6
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: VDPAU rendering delay

VDPAU is a frame (or field) based decoding API, not a slice based API. As such, one must have the entire picture's data available prior to initiating a decode operation.

Anything more complex would involve synchronization between the capture and decode drivers or even hardware; not something that would be generally useful or usable.
Stephen Warren is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 06:44 AM.


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