IDXGISwapChainMedia interface

This swap chain interface allows desktop media applications to request a seamless change to a specific refresh rate.

For example, a media application presenting video at a typical framerate of 23.997 frames per second can request a custom refresh rate of 24 or 48 Hz to eliminate jitter. If the request is approved, the app starts presenting frames at the custom refresh rate immediately - without the typical 'mode switch' a user would experience when changing the refresh rate themselves by using the control panel.

Members

The IDXGISwapChainMedia interface inherits from the IUnknown interface. IDXGISwapChainMedia also has these types of members:

• Methods

Methods

The IDXGISwapChainMedia interface has these methods.

Custom framerate and video playback

Most devices run at 50 or 60 Hz, while most movies are stored at approximately 24 frames per second. This difference in framerate causes media applications to need to process video to match the device's refresh rate, for example using 3:2 pulldown. This can result in judder, blur, and other undesirable effects.

DXGI 1.3 introduces a feature that sets the graphics adapter's framerate to any value supported by the hardware. This allows desktop media apps to set the refresh rate to an integer multiple of the video framerate, enabling the app to present video at its native framerate. Custom framerates that are lower than the device's standard framerate lead to reduced power consumption because the graphics hardware is presenting less often; minor power savings are also achieved by eliminating processing cycles related to framerate adjustment.

Using a custom framerate to display video

First, create a swap chain by using any IDXGIFactory method. Then use QueryInterface to obtain the IDXGISwapChainMedia interface. This interface can be obtained from any swap chain, including IDXGISwapChain, IDXGISwapChain1, IDXGISwapChain2, and IDXGIDecodeSwapChain.

The next step is to call IDXGISwapChainMedia::CheckPresentDurationSupport to find a suitable supported refresh rate.

The custom framerate API uses the duration of a single frame to represent refresh rates instead of a frequency. This duration is specified in hundreds of nanoseconds. To arrive at the duration value, take the reciprocal of the refresh rate (Hz) and then multiply by 10^7 (ten to the seventh power). For example, to query support for 60 Hz, provide the value 167777 (16.7 ms).

Check for refresh rates by using the following pattern:

• First, check the duration that corresponds the framerate of the video content. The API will return the closest supported durations (both upper and lower bounds).
• If the output adapter does not support seamless refresh rate transitions, the upper and lower bounds will be (0, 0). In this case the app should stop checking for a suitable present duration.
• If the exact duration queried for is supported, the upper and lower bounds will both equal the queried value.
• If the duration is not supported and neither of the closest durations are suitable, multiply the duration by 2 and check again.
• Repeat the pattern, incrementing the multiple by 1 each time. Continue until a suitable present duration is found or until the duration exceeds 16.7 ms (60 Hz).

If the app finds a supported duration that is suitable to its needs, it then uses IDXGISwapChainMedia::SetPresentDuration to request the ability to present frames at that duration. If the app does not find a supported duration that is suitable, or if custom refresh rates are not supported, the app must fall back to using framerate adjustment techniques (such as pulldown) to present video at the standard refresh rate.

It is not always possible for the operating system to approve the custom refresh rate request. In addition to the necessary hardware and driver support for the custom refresh rate feature, an app must also be full-screen and the swap chain must cover the entire display with no overlapping content. This requirement ensures that the custom refresh rate does not interfere with system UI or content from other apps. To find out whether the custom refresh rate is currently approved, call IDXGISwapChainMedia::GetFrameStatisticsMedia. This method returns a new DXGI_FRAME_STATISTICS_MEDIA struct. If the ApprovedPresentDuration field of this struct is equal the requested duration, the custom refresh rate request has been approved and the app can begin presenting with the approved frame duration.

After the system tells the app the duration is currently approved, the app must explicitly request the custom duration on a per-present basis by passing in the DXGI_PRESENT_USE_DURATION flag. The custom duration will only take effect on presents with this flag.

If the duration is not currently approved, the app should not attempt to present using a custom framerate. If the DXGI_PRESENT_USE_DURATION flag is set while the app does not have system approval for a custom present duration then DXGI will adjust the timing of the frame as described in the next section.

Handling revoked approval for custom present duration

The system can revoke the approval if circumstances change - for example, when the charms are displayed. Apps should check the frame statistics for approval on a frame-by-frame basis. If the approval is revoked and the system later returns to a state where the custom refresh rate can be approved, the frame statistics will once again include the approved present duration.

Note that since frames are typically scheduled for presentation in sequence, it is possible for the custom refresh rate to be revoked while frames are still scheduled to be presented with a custom duration. When this happens, DXGI uses a form of pulldown to convert the duration back to the standard interval for the device. Present durations will be converted such that the time the frame is visible is as close as possible to what the app intended, preventing the video from becoming out-of-sync.

Revocation example:   An app requests 48 Hz and the system approves the request for a custom present duration. At some point, the user displays the charms. When this happens the system returns to the standard refresh rate and revokes the app's custom present duration approval. Since the app calls GetFrameStatisticsMedia before presenting each frame, it immediately finds out that the approval is revoked and changes its behavior to present frames at the standard system refresh rate.

However, the app still has 12 presents queued. Each present has the sync interval set to 1 and the DXGI_PRESENT_USE_DURATION flag is set, meaning that each frame will be presented for exactly 1 refresh interval that matches the native framerate of the video. To retain the intended timing of the present sequence, DXGI automatically changes the sync intervals from:

1 1 1 1 1 1 1 1 1 1 1 1

To:

1 1 1 2 1 1 1 2 1 1 1 2

Remarks

Seamless changes to custom framerates can only be done on integrated panels. Custom frame rates cannot be applied to external displays. If the DXGI output adapter is attached to an external display then CheckPresentDurationSupport will return (0, 0) for upper and lower bounds, indicating that the device does not support seamless refresh rate changes.

Custom refresh rates can be used when displaying video with a dynamic framerate. However, the refresh rate change should be kept imperceptible to the user. A best practice for keeping the refresh rate transition imperceptible is to only set the custom framerate if the app determines it can present at that rate for least 5 seconds.

Requirements

See also

IUnknown

IDXGIFactoryMedia

DXGI Interfaces