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

Newegg Daily Deals

Reply
 
Thread Tools
Old 03-01-04, 03:49 AM   #1
mboehme
Registered User
 
Join Date: Mar 2004
Posts: 5
Default Xvideo and syncing to Vblank

Hi,

I'm working on a project that uses high-resolution video (1280x720 at 30 fps), which pretty much makes Xvideo a "must" -- doing YUV->RGB in software isn't really an option, because we're already doing some image processing on the video that just about maxes out a 2.8 GHz Pentium 4 at this frame rate.

I've done a few experiments and concluded that Xvideo does sync to the vblank -- I'm not getting any tearing -- but apparently XvPutImage/XFlush don't block but return immediately. At the moment, I'm using usleep to schedule my redraws, which is OK, but it does mean that I may get slight stutter in the output -- say I'm running at a refresh rate of 60 Hz, so I would want every frame to be displayed for exactly two refreshes, but since I'm not synced to the actual refresh, it can happen that, every so often, a frame gets displayed for three refreshes or only one refresh. Since our project is about measuring the eye movements that people make in response to visual cues, we obviously want our video to be as smooth as possible.

I know that under OpenGL, I can sync to the vblank in glXSwapBuffers by setting the __GL_SYNC_TO_VBLANK environment variable to 1; I'd like to be able to do something similar under Xvideo. (OpenGL is too slow for our purposes because, as explained above, we'd have to do YUV->RGB in software.) I've even tried "hijacking" OpenGL to do my synchronization by calling glXSwapBuffers (to wait for the vertical retrace) before calling XvPutImage/XFlush, but that didn't work -- my application did sync to the refresh rate, but I got some tearing in the Xvideo window that wasn't there before (guess that serves me right for attempting such an ugly hack... ;-) ).

Is there any way of getting what I want? I would have no qualms about doing something that's Nvidia-specific or even specific for a certain driver version -- this app is only going to run on our own hardware. If syncing to the vblank isn't possible with the current driver version, is there any chance of this being implemented in the future?

Cheers

Martin Boehme
mboehme is offline   Reply With Quote
Old 03-02-04, 09:10 AM   #2
georg
Registered User
 
Join Date: Jun 2003
Posts: 24
Default

caveat: I don't know anything about xvideo, but have used GL for a bit.

run glxinfo, see if you get
GL_NVX_ycrcb

as one of the extensions. This may do the colorspace conversion for you in GL. I don't know if it's fast or not - e.g., a similar extension on a radeon in OS X is too slow to use.

Alternatively, to sync to the retrace, you could try polling the glXGetVideoSyncSGI command - I think there's a WaitVideoSync version as well. You may have more luck with these (and judicious usleeps) than waiting for the retrace. I think the Wait function used to burn CPU on previous driver versions, but I've read about it in the changelogs since, so it might work well by now. Both get confused if you're running more than one monitor.

Finally, I've found that messing with delays works far better in 2.6 than 2.4 ..
georg is offline   Reply With Quote
Old 03-08-04, 07:53 AM   #3
mboehme
Registered User
 
Join Date: Mar 2004
Posts: 5
Default

Thanks for your answer... almost didn't see it, I thought I had specified that I should be notified via email when there's an answer to my post, but that didn't happen... luckily, I decided to browse the forum again.

Thanks for the pointer to GL_NVX_ycrcb -- yes, I do get that extension when I run glxinfo, so that would be something to try... A colleague of mine told me he'd tried doing YUV->RGB via OpenGL but failed... but he uses a different machine, so I'll try it again on mine if I get round to it.

But I think I won't even have to try that because in the meantime I've found a way of syncing Xvideo to the vertical retrace. And yes, it involves glXWaitVideoSyncSGI. I had tried using this function before but without success -- it just seemed to return at once. What I found out is that to use glXWaitVideoSyncSGI, you apparently have to create at least one OpenGL window, i.e. a window that you attach a GL context to using glXMakeCurrent. The window doesn't have to be visible, though. So this is what I do: Create a dummy OpenGL window, then in my rendering loop, call glXWaitVideoSyncSGI to wait for the retrace and then draw the video frame using XvShmPutImage. Works like a charm.

And yes, under the latest driver version, I get an "intelligent" (i.e. non-CPU-burning) wait. Bring out the champagne... ;-)

>> Finally, I've found that messing with delays works far better in 2.6 than 2.4 .. <<

Yeah, we've already upgraded our systems to 2.6 because obviously we want our latencies to be as low as possible.

I'm thinking of writing a short article on this issue (syncing Xvideo to the vertical retrace) because I haven't seen it covered anywhere on the web. If I do, I'll post a link here. I might even benchmark GL_NVX_ycrcb against Xvideo and see which (if any) is faster...

Thanks for your help

Martin Boehme
mboehme is offline   Reply With Quote
Old 03-08-04, 08:30 AM   #4
mboehme
Registered User
 
Join Date: Mar 2004
Posts: 5
Default

Hmmm... it appears that GL_NVX_ycrcb is pretty slow:

http://www.mail-archive.com/dri-deve.../msg14996.html

A quote from the above post: "My testing indicated, unfortunately, that the color matrix transformation is a software path in their driver and is pretty slow."

So I think I'll stick with Xvideo for the time being...

Martin Boehme
mboehme is offline   Reply With Quote
Old 03-08-04, 08:54 AM   #5
nutball
International God of Sex
 
Join Date: Jul 2002
Location: en.gb.uk
Posts: 655
Default

Can't you do the colour transformation in a pixel shader?
__________________
Got nuts?
nutball is offline   Reply With Quote
Old 03-08-04, 09:41 AM   #6
mboehme
Registered User
 
Join Date: Mar 2004
Posts: 5
Default

>> Can't you do the colour transformation in a pixel shader? <<

Probably yes... The reasons why my tendency is to go with Xvideo at the moment are: First, I've got an Xvideo implementation that works, and it's fast (at least fast enough... maybe GL with colour conversion via a pixel shader would be faster, but I have a hunch that the limiting factor is probably bus speed). Second, Xvideo is supported by just about every graphics driver out there (so even if a driver doesn't do glXWaitVideoSyncSGI, I still get the basic video output, albeit unsynced), whereas GL_NVX_ycrcb would be Nvidia specific (I'm guessing NVX stands for Nvidia extension) - OK, we only use Nvidia hardware at the moment, but you never know. And third, I have zero experience writing pixel shaders. ;-) Of course, on its own, this last reason would not _be_ a reason -- in fact, I would welcome a pretext to learn about pixel shaders ;-) -- but given the other two factors, it just tips the scales slightly further in favour of Xvideo...

Having said that, I would definitely welcome any pointers you could give me on doing colour conversion using pixel shaders.

>> International God of Sex <<

Blimey... ;-)

Martin Boehme
mboehme is offline   Reply With Quote
Old 03-09-04, 10:06 AM   #7
mboehme
Registered User
 
Join Date: Mar 2004
Posts: 5
Default

Here's a link to an article I've written about synchronizing Xvideo to the vertical retrace (vblank):

http://www.inb.uni-luebeck.de/~boehme/xvideo_sync.html

Hope this will be of general use for people searching the forum for this kind of information.

Comments welcome!

Martin Boehme
mboehme 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 07:48 AM.


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