VDPAU rendering delay

Dinges · 04-13-10, 06:11 AM

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 ?

**Stephen Warren** · 04-13-10, 10:56 AM

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.

Dinges · 04-14-10, 02:30 AM

Quote:

Originally Posted by Stephen Warren

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.

**Stephen Warren** · 04-14-10, 11:31 AM

Quote:

Originally Posted by Dinges

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.

Dinges · 04-15-10, 03:44 AM

Quote:

Originally Posted by Stephen Warren

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.

**Stephen Warren** · 04-15-10, 09:32 AM

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.

04-13-10, 06:11 AM	#1
Dinges Registered User Join Date: Apr 2010 Posts: 3	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 ?

04-13-10, 10:56 AM	#2
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	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.

04-15-10, 09:32 AM	#6
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	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.