tzr916 wrote:So all PC gpu's (nvidia, amd, intel), and the xbox, and the echo all suffer the 29/59 bug.
There is no such thing as "the 29/59 bug". That term originated during an investigation of stuttering playback, when someone discovered that the stuttering coincided with fluctuations in the listed frame rated in the Debug: Presentation screen in WMC (the listed frame rate would fluctuate between 29.97 and 59.9401). Many people (without any actual knowledge of what was happening) jumped to the conclusion that there was a bug in WMC that was causing the stuttering, and after the discovery of the frame rate fluctuation, the term "29/59 bug" was born. In reality, it was never a bug. The frame rate listed in the Debug: Presentation screen in WMC depicts the current state of the progressive_frame flag embedded in the MPEG stream, so when the flag fluctuates, so does the listed frame rate. Additionally, Microsoft's MPEG decoder honors the progressive_frame flag and changes the state of the GPU's interlacer/deinterlacer in response to changes in the progressive_frame flag, and some GPUs can't perform the change without dropping frames (i.e., stuttering). Microsoft explained all of this several years ago, but despite the obvious truth that there wasn't a bug, people continued to use the term "29/59 bug" to describe anything that resulted from the fluctuations in the progressive_frame flag, and that practice continues today.
To be clear "29/59" simply refers to the fluctuation of the progressive_frame flag on US content. But "29/59" is not actually the best terminology to use because the fluctuation of the flag occurs in content from other countries at other frame rates. For example, there is a thread here that discusses the fluctuation in UK content, which is either 25p or 50i. So "29/59" becomes "25/50" in that conversation. So "29/59" should actually be "fluctuating progressive_frame flags". When you use that terminology, the statement "the GPU suffers the 29/59" becomes "the GPU suffers the fluctuating progressive_frame flags", and that clearly is not correct. The GPU doesn't have any progressive_frame flags...the MPEG stream does. So it's the MPEG stream that suffers the issue, not the GPU.
When people say "the GPU suffers the 29/59 bug", what they really mean is the GPU shows an adverse on-screen reaction to the
fluctuation of the progressive_frame flag. The problem for those people isn't the flag's value...it's the fact that the flag is changing from one value to another value. The stuttering referenced in the first paragraph is an example of this. The flag's value didn't cause the stuttering. It was the
fluctuation of the flag's value that ultimately caused the stuttering. There are also other things that GPUs are known to do when the flag changes. Some GPUs have a dynamic contrast "enhancement" that when enabled causes fluctuations in the progressive_frame flag to appear as on-screen flickering. Some GPUs even go completely blank when the flag changes. All of these are examples of problems that result from
fluctuation of the flag.
What you are experiencing is not the result of
fluctuation of the flag. Your GPU handles the fluctuation just fine. You don't have any stuttering, flickering, screen blanking, or anything else that results from the fluctuation itself. What you are experiencing is simply the result of the flag being wrong part of the time (in your sample, the flag was wrong about 50% of the time.) If the flags actually matched the content, you wouldn't be complaining at all.
The progressive_frame flag affects every playback device that doesn't ignore the flag. As I stated in the first paragraph, Microsoft's MPEG decoder honors the flag and changes the state of the GPU's interlacer/deinterlacer in response to changes in the flag. If the progressive_frame flag is wrong (i.e., it is set to 0 when the frame is actually progressive, or it is set to 1 when the frame is actually interlaced), Microsoft's decoder ends up setting the GPU's interlacer/deinterlacer to the wrong state (it gets set to the "on" state when it should be set to the "off" state, and vice-versa), which results in picture quality issues such as what you see with your sample clip. If the frames were flagged correctly, Microsoft's decoder would end up setting the state of the interlacer/deinterlacer correctly and there would be no picture quality issues.
On the flip side, the progressive_frame flag does not affect any playback device that ignores the flag. That's what you are doing with LAV. You're telling LAV to ignore the flag and treat every frame as progressive. And your feeding LAV all progressive frames. So naturally none of the frames get deinterlaced, thus there are no picture quality issues.
As was previously stated, CE GPUs are much better at processing video than PC GPUs. But more importantly, CE GPUs are built specifically for video processing and have more things implemented for that specific purpose than what you'll find in a PC GPU. CE devices are powerful enough to ignore the progressive_frame flag and use their own internal interlace-detection algorithms to determine whether the frame is interlaced or progressive, and I suspect that is exactly what is happening in most CE devices...hence the reason you never hear anyone outside of the HTPC community complaining.
