Player Creators: Variable Refresh Rate (ala G-SYNC) apparently makes video better!

[Mark Rejhon]

Check my other thread I posted.
http://forum.doom9.org/showthread.php?p=1650056

NVIDIA's new G-SYNC apparently, has very useful benefits for video.

If you are a creator of a video player, bear in mind in full-screen mode, Direct3D Present() API now directly controls the refresh rate: Present() triggers the frame delivery to the display immediately (no waiting for next scheduled refresh interval). So playing existing variable frame rate files on variable frame rate displays will look much, much better. Call Direct3D Present() at exact intervals 60 times a second, you got perfect 60fps@60Hz. Call Direct3D Present() at exact intervals 83 times a second, you got perfect 83fps@83Hz. And so on. Your video players thus can then play all frame rates *perfectly* at the correct time code.

Perfect video playback
- Play movies 24fps@24Hz (or 48Hz, 72Hz, 96Hz)
- Play videos 30fps@30Hz
- Play movies 48fps@48Hz
- Play television 60fps@60Hz
- Play television 59.94Hz@59.94Hz
- Play old silent films at original theater speed 18fps@18Hz (or 36Hz, 72Hz)
- Variable frame rate video files, director chooses their own frame rate.
- Future movie formats (e.g. 72fps, 96fps)
- Play mixed TV material and dynamically detect 24p, 30p, and 60p material, dynamically rate-adapt to new fixed rate (with zero mode-change flicker)
- You can avoid stutters even if one frame takes a bit longer to render (e.g. 16.8ms instead 1/60sec = 16.7ms) for any innocous reason such as processing, background apps or error correction, you just delay that specific refresh by an unnoticeable 0.1 millisecond rather than be forced to wait till next refresh cycle. Makes video playback even smoother.
- etc.

[JanWillem32]

The basic method of disabling vertical synchronization and just presenting frames is rather well-known, also for video playback. Examples are the basic VMR-7 and VMR-9 renderers.
It causes terrible tearing of course. On top of that, the scheduling will be horrible as well. That's mostly caused by the rounds made by the rendering thread. The rendering thread is controlled by the process scheduler of the operating system. This scheduler will set an interval per running thread based on the process priority (low to high, with some special cases for real-time scheduling with user-space and kernel processes). Due to this system an application will get a fair amount of processor time, but that's of course never nicely synchronized with the display frame rate.
Issuing long waiting times to synchronize with some frame rate also worsens the renderer thread's status in the process scheduler. The scheduler will often skip several milliseconds before spending processor time on the thread again if it kept the scheduler waiting a long time. This issue causes de-synchronization and often even frame drops. If you start to issue vertical synchronization as well, the effect worsens (as you have to wait even longer for the vertical blanking period of the display device).

Another method:
http://en.wikipedia.org/wiki/Genlock
This technique is called "genlock" and actually has been around as long as television itself. The EVR Sync renderer actually already uses an implementation of it.
You need to use the video adapter's private driver API or similar to establish genlock. It's a nice feature that can help to reduce the effect of jitter in a system, reducing some of the more simple glitches. It doesn't help at all with the worst glitches caused by high CPU and GPU loads nor will it increase the maximum refresh rate of the hardware.

"Direct3D Present() API" actually isn't completely correct. Direct3D is the API, Present() and PresentEx() are the API calls to queue frames into the frame presentation queue or prepare an immediate back- to frontbuffer flip.

[dukey]

G-sync will be great for video especially variable frame rate content, but you'll need a new monitor.

[wonkey_monkey]

you just delay that specific refresh by an unnoticeable 0.1 millisecond rather than be forced to wait till next refresh cycle. Makes video playback even smoother.

Is "0.1ms" actually specified anywhere?

Isn't this just all fancy marketing talk for "a monitor with a very high refresh rate that continuously displays whatever frame it was last sent, until the graphics card deigns to send a new one"?

Call Direct3D Present() at exact intervals 60 times a second, you got perfect 60fps@60Hz. Call Direct3D Present() at exact intervals 83 times a second, you got perfect 83fps@83Hz. And so on. Your video players thus can then play all frame rates *perfectly* at the correct time code.

If that was literally the case, wouldn't you find your image flickering/brightening/darkening every time you changed framerate, since the graphics card and monitor won't know when the next one is coming along?

I guess I can see this being good for games, where instead of dropping from a smooth 60Hz to 30Hz when the graphics get too intense, it'll only drop to (say) 45Hz, but I wish games creators would just set themselves a target framerate and stick to it. If you want your game to look and play smoothly, don't throw much detail into it that the refresh rate suffers. Take the Wipeout games - with a couple of exceptions (Wipeout Pulse being one, I think), and the very occasional moment when there's too much going on at once, they play super-smoothly and are, in my opinion, excellent because of that.

David

[vivan]

wouldn't you find your image flickering/brightening/darkening every time you changed framerate, since the graphics card and monitor won't know when the next one is coming along?On LCD?

but I wish games creators would just set themselves a target framerate and stick to it. If you want your game to look and play smoothly, don't throw much detail into it that the refresh rate suffers.Just buy a couple of Titans :)
In a PC world people have different hardware, it's impossible to target them all.

Take the Wipeout games - with a couple of exceptions (Wipeout Pulse being one, I think), and the very occasional moment when there's too much going on at once, they play super-smoothly and are, in my opinion, excellent because of that.WipEout is not a PC game.

[raffriff42]

wouldn't you find your image flickering/brightening/darkening every time you changed framerate, since the graphics card and monitor won't know when the next one is coming along?

Aha, that has been thought of...Nvidia CEO Jen-Hsun Huang at Nvidia's Montreal 2013 event (http://techreport.com/review/25529/live-blog-from-day-two-of-nvidia-montreal-2013-event) (techreport.com)

...Logic is simple, but implementation is complicated. LCD monitors are complicated at the electronics level and at the molecular level. Our engineers have figured out how to drive the monitors so the color continues to be vibrant and beautiful, so that the color and gamma are correct as timing fluctuates.

[JanWillem32]

Is "0.1ms" actually specified anywhere?It can be a lot more, it can also be less (normally you only have to compensate for a little bit of jitter in the system).Isn't this just all fancy marketing talk for "a monitor with a very high refresh rate that continuously displays whatever frame it was last sent, until the graphics card deigns to send a new one"?That's actually what any modern monitor does. The digital buffers for one image are sent over the video cable, and until the next picture comes in, the signal is virtually empty. It's the monitor's task to assemble the data, do bit-error correction and display the image.If that was literally the case, wouldn't you find your image flickering/brightening/darkening every time you changed framerate, since the graphics card and monitor won't know when the next one is coming along?Not with digital video transmission. For analog, you would get a nasty blanking issue indeed. In general, genlocked systems are fed by a clock signal that is extremely stable in terms of frame rate, so even analog transmissions don't suffer much from it. I've yet to see variable frame rate solutions in practice.I guess I can see this being good for games, where instead of dropping from a smooth 60Hz to 30Hz when the graphics get too intense,See triple buffering technology on that point. Even though it increases and warps latency a little bit (but can be compensated if you keep track of frame-time statistics), you really don't have to let your rendering thread wait on the vertical blanking period.it'll only drop to (say) 45Hz, but I wish games creators would just set themselves a target framerate and stick to it.Not going to happen. Complexity in scenes are an absolute nightmare to compensate for. You can dynamically drop a few grades in shading complexity and textures, but that means that you need to have those lower quality shaders and textures loaded at all times, costing memory.If you want your game to look and play smoothly, don't throw much detail into it that the frame rate suffers.Correct, the scene, shading and texture complexity should be organized that the minimum frame rate on a system is still acceptable. Average and maximum frame rates don't matter much. For PC hardware, the video quality level options should reflect that properly.

[IanB]

Seems this is a better scheduling model that allows next frame presentation more or less on demand, much like disabling V-sync but without the problem of tearing.

I suspect a similar effect could be had by running a HDMI interface at a very high refresh rate, like 240Hz and doing buffer swaps with V-Sync enabled. Latency would now be less than or equal to 4.16ms.

Of course G-Sync seems to be advocating video card driven on demand transfer to the display which would avoid thrashing a HDMI interface at 240Hz, but need changes to the display device. Of course there still will be a scan clock for the LCD panel, so the result will still have some small timing inconsistency, but this is all steps in the right direction.

About time some proper engineering was done to eliminate jitter on motion video digital presentation.

[dukey]

much like disabling V-sync but without the problem of tearing.


That's pretty much what it is. The only reason we have a refresh rate was for CRT monitors, since they have to redraw in a fixed time period.