VDPAU Limitations - esp. single stream

bwheaton · 03-27-09, 07:10 PM

There are a few limitations still in VDPAU which prevent us from using it in a professional environment - which we'd really like to - and I'm curious if there's any roadmap for these features, and to make it clear that they are desirable:

1. Support for decompressing multiple streams 2-4 ideally.

2. Support for, for instance, an OpenGL FrameBuffer Window System Integration Layer, or failing that some manner to know when frames are complete (to be copied to textures).

3. More pixel formats, so 10-bit video can be kept at full quality, and/or 4:4:4(:4) is supported.

Bruce

**Stephen Warren** · 03-28-09, 12:38 AM

1. At some point, we certainly hope to be able to decode N streams in parallel. There's no timescale for this at present.

2. If you render to an X pixmap, the presentation queue status is now completely accurate ("visible" means "blit complete") Admittedly you can't block waiting for this state currently.

3. NVIDIA's VDPAU implementation doesn't support decoding 10-bit video at present. Hence, 10-bit video surfaces aren't relevant right now. VDPAU does support 10-bit output surfaces though.

If you have a specific professional application in mind, your best bet may be to contact NVIDIA's professional services department for appropriate prioritization.

thefirstm · 03-28-09, 02:10 AM

Another feature I would like to see is the ability to use V-sync with VDPAU while the Xorg Composite extension is on but a compositing window manager is not running. Running KDE4 without the Composite extension causes certain redraw artifacts on the desktop, so right now you can either pick artifacts or tearing.

Don't get me wrong, I love VDPAU, though. I never thought I would be able to play HD video with spatial-temporal deinterlacing and inverse telecine on Linux :-)

**Stephen Warren** · 03-28-09, 10:50 PM

Yes, we're aware of that issue, and it should be fixed soon.

thefirstm · 03-29-09, 02:58 AM

Great! Thank you so much for all of the hard work you do.

bwheaton · 03-29-09, 04:59 PM

Quote:

Originally Posted by Stephen Warren

1. At some point, we certainly hope to be able to decode N streams in parallel. There's no timescale for this at present.

Good, thank you. Out of curiosity, is the startup/breakdown time quick enough that I could 'start' something playing with software decoding then flip over to hardware? The essence of our application is an A/B dissolve, so we could probably software decode one stream and hardware another, as long as we can switch them over in a reasonable time.

Bruce

**Stephen Warren** · 03-30-09, 11:30 AM

I don't have an exact quantification of the startup time, and it surely varies between GPUs and systems in general. You'd probably want to set up VDPAU some amount of time in advance, and simply start sending decode commands in near the time of the A/B disolve (although even then, decode ahead of time to cater for pipeline latency). If you do the VDPAU calls in a separate thread, you should be able to start it up without interfering with the SW decode.

03-27-09, 07:10 PM	#1
bwheaton Registered User Join Date: Nov 2008 Location: California Posts: 59	VDPAU Limitations - esp. single stream There are a few limitations still in VDPAU which prevent us from using it in a professional environment - which we'd really like to - and I'm curious if there's any roadmap for these features, and to make it clear that they are desirable: 1. Support for decompressing multiple streams 2-4 ideally. 2. Support for, for instance, an OpenGL FrameBuffer Window System Integration Layer, or failing that some manner to know when frames are complete (to be copied to textures). 3. More pixel formats, so 10-bit video can be kept at full quality, and/or 4:4:4(:4) is supported. Bruce

03-28-09, 12:38 AM	#2
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	Re: VDPAU Limitations - esp. single stream 1. At some point, we certainly hope to be able to decode N streams in parallel. There's no timescale for this at present. 2. If you render to an X pixmap, the presentation queue status is now completely accurate ("visible" means "blit complete") Admittedly you can't block waiting for this state currently. 3. NVIDIA's VDPAU implementation doesn't support decoding 10-bit video at present. Hence, 10-bit video surfaces aren't relevant right now. VDPAU does support 10-bit output surfaces though. If you have a specific professional application in mind, your best bet may be to contact NVIDIA's professional services department for appropriate prioritization.

03-28-09, 02:10 AM	#3
thefirstm Registered User Join Date: Feb 2009 Posts: 226	Re: VDPAU Limitations - esp. single stream Another feature I would like to see is the ability to use V-sync with VDPAU while the Xorg Composite extension is on but a compositing window manager is not running. Running KDE4 without the Composite extension causes certain redraw artifacts on the desktop, so right now you can either pick artifacts or tearing. Don't get me wrong, I love VDPAU, though. I never thought I would be able to play HD video with spatial-temporal deinterlacing and inverse telecine on Linux :-)

03-28-09, 10:50 PM	#4
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	Re: VDPAU Limitations - esp. single stream Yes, we're aware of that issue, and it should be fixed soon.

03-29-09, 02:58 AM	#5
thefirstm Registered User Join Date: Feb 2009 Posts: 226	Re: VDPAU Limitations - esp. single stream Great! Thank you so much for all of the hard work you do.

03-30-09, 11:30 AM	#7
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	Re: VDPAU Limitations - esp. single stream I don't have an exact quantification of the startup time, and it surely varies between GPUs and systems in general. You'd probably want to set up VDPAU some amount of time in advance, and simply start sending decode commands in near the time of the A/B disolve (although even then, decode ahead of time to cater for pipeline latency). If you do the VDPAU calls in a separate thread, you should be able to start it up without interfering with the SW decode.