The 29 59 Frame Rate Issue

From TGB WIKI
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Source: Windows Experts Community, including richard1980, iank, and others

http://experts.windows.com/w/experts_wiki/71.aspx

Each frame of video content contains embedded information (metadata) that tells playback devices how to play the content. Part of the metadata determines if a particular frame of video is interlaced or progressive, and the playback device is supposed to react accordingly. If a playback device is set to output a progressive scan signal, interlaced content must be de-interlaced to be viewed correctly, while progressive scan content can be passed untouched. If the playback device is set to output an interlaced signal, progressive scan content must be interlaced to be viewed correctly, while interlaced content can be passed untouched.

However, sometimes the metadata contained in the video signal is incorrect. Content may be interlaced while being marked as progressive scan, or the content may be progressive scan while being marked as interlaced. This will pose a problem for playback devices that properly look for and adhere to the information in the metadata, as it will cause the improperly marked frame to be handled the wrong way, which results in visible artifacts during playback. Below are two examples of improper handling of the frames (click the pictures for an enlarged view).

A progressive scan frame being handled properly:

The same frame after being de-interlaced when it shouldn't be:

An interlaced frame after being handled properly:

The same frame not being de-interlaced when it should be:

In addition to the visible artifacts, there is also another problem. The metadata is embedded in each frame of the video signal, so some frames of a particular program may be correctly marked while others are not. When a particular frame has different frame rate metadata from the frame before it, this may cause the playback device to change operating modes...specifically, the playback device may either switch to de-interlacing mode, interlacing mode, or pass-through mode. Below is a table that summarizes the instructions that any graphics processor must go through when the metadata changes: Output is interlaced Output is progressive Metadata changes from interlaced to progressive Turn interlacer on (interlacing mode) Turn de-interlacer off (pass-through mode) Metadata changes from progressive to interlaced Turn interlacer off (pass-through mode) Turn de-interlacer on (de-interlacing mode)

Switching the state of the de-interlacer or interlacer requires time, and playback devices only have a certain amount of time to process the frame before the next frame arrives. When a playback device is not finished processing a frame before the next frame arrives, this will cause adverse effects such as stuttering/dropped frames. While most consumer electronics (CE) devices are not affected by this, this is of particular interest to HTPC users. HTPCs contain GPUs that are very different from the graphics processors found in CE devices, and are generally not as well designed for video processing as the graphics processors found in CE devices. They are generally slower to do things like change the state of the de-interlacer/interlacer, so this makes HTPCs that use software that takes advantage of GPU processing more susceptible to performance issues when faced with content that changes from interlaced to progressive or vice-versa. The amount of time required for each GPU to complete the instructions varies by GPU, and when a GPU is in the process of completing the instructions and one or more additional frames arrives for processing, the additional frames will be dropped until the GPU is finished changing the state of the interlacer/deinterlacer. This is seen on-screen as a stutter in playback.

Additionally, on some NVIDIA GPUs, with current drivers (as of 9/25/2012) the 29/59 bug may manifest as a diming and brightening of the image at the transition point from interlaced to progressive coding. If you encounter this on NVidia hardware the following steps should mask it:

Do this:

   Do NOT use the nvidia control panel settings to set dynamic range. Set it to application default (or whatever it's called). Using the NVidia setting exposes the flickering.
   Use the registry settings that instruct Media Center to implicitly set the nominal/dynamic range:

16-235:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Debug\ehPresenter.dll] "NominalRange"=dword:2

0-255:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Debug\ehPresenter.dll] "NominalRange"=dword:1

This should mask the change in brightness on the interlaced/progressive transition.


It should also be noted that GPUs generally have a variety of post-processing options, all of which require a small amount of time to complete. Performance will vary based on how much post-processing a GPU is told to do. The more post-processing needs to be done, the less time the GPU has to change the state of the deinterlacer/interlacer, and the more likely you are to see stuttering. However, most GPUs will continue to stutter even after disabling all post-processing.

The 29/59 test

In Windows Media Center, you can see when the metadata in the content is incorrect. Simply start playing some content, press 4-1-1 and then the Info button on your remote, or type 411 and press Ctrl+D on your keyboard. This should bring up the debug screen in Windows Media Center. Using the right arrow, navigate the screens until you get to "Debug: Presentation", which is the furthest screen to the right. Look at the frame rate listed. If it changes between 29.97 and 59.9401 while playing the exact same content, you are seeing the metadata embedded in the signal fluctuating. This is commonly referred to as the 29/59 frame rate switching issue or the 29/59 bug.

Below is an example. Notice the frame rate is different in each screenshot.

Here's a video example of the frame rate changing on a GPU that can't handle it (the problem starts about 25 seconds into the video):

http://www.youtube.com/watch?feature=player_embedded&v=atD6vkDwtBg

Solution

There is only one true solution to this problem: Encode the video with the correct metadata to begin with. The solution is the responsibility of the entity that encoded the video, which means contacting the broadcaster, cable network, or cable company that encoded the video and working with their engineers to resolve the issue. Additionally, Microsoft has acknowledged this issue in their Knowledge Base Article ID 2658140 with no known Windows Media Center resolution at this time.

Workaround

In lieu of attempting the solution listed above, there is a workaround available. A number of GPUs have been identified as able to play back content with the bad metadata without stuttering or other adverse effects, provided there are no other issues with the system and the correct processing settings are applied. Note: Other issues and/or incorrect processing settings in the GPU software may contribute to stuttering and/or other adverse effects. It may be necessary to disable all post-processing in the GPU software to get smooth playback.

Note to wiki editors: Please ensure you have confirmed smooth playback with content that switches frame rates between 29.97 Hz and 59.9401 Hz before adding GPUs to this list.

NVIDIA

GeForce 8600 GTS

GeForce 9300

GeForce 9400 (including ION platforms)

GeForce GT 425

GeForce GT 430

GeForce GT 440 (same core as 430)

GeForce GTS 250

ATI

Radeon HD 4200

Radeon HD 4550

Radeon HD 4650

Radeon HD 5450 with Dynamic Contrast Adjustment turned off

Radeon HD 6450

Radeon HD 6850

Intel Core i3 (Clarkdale)