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