t-c

Hogwash. Until the vendor acknowledges the bug and fixes it, your argument is nothing more than cooperator bias---"a lot of people have successfully reduced stuttering.. bla bla".

WTF?  Are you kidding me?  That's the stupidest thing I've ever heard.  That's so stupid I don't even know why I bothered writing this response.

I've got 3 words for you:  Prove me wrong.

Whats stupid is your flawed misleading analysis. You should be reimbursing all the people who ran out and bought new video cards when all they really needed to do was just back rev the driver or apply IanK's registry patch.

Ian's NominalRange setting only changes the RGB range output by WMC, which can resolve flickering that is observed when 29/59 content is played.  The flickering is observed because the switch from interlaced to progressive (or vice versa) temporarily resets the RGB range output by the GPU.  The registry edit forces WMC to control the RGB range rather than allowing the GPU to do so.  The end result is a consistent RGB range is output during the transition.  This registry edit DOES NOT resolve stuttering.  Perhaps you are confusing the two symptoms, so here is a visual explanation of the difference between flickering and stuttering:

Flickering:

Stuttering:

Changing the driver cannot magically make a GPU more powerful than it actually is.  The GPU is either powerful enough to get the job done, or it's not.  If a GPU is powerful enough to get the job done, yes it is possible that the GPU may stutter using one driver version, but may not stutter when using a different driver version.  But the GPU has to have the power to begin with, and the reality is, very few GPUs actually have the required power to play 29/59 content without stuttering.  When a GPU lacks the power, changing the driver will do nothing to resolve the stuttering.  And it seems to me that you don't believe there are GPUs that lack this power.  Of course, if you think you are correct, you are welcome to post which driver version resolves the stuttering on all NVIDIA GPUs.  I'm sure Quatrix would appreciate it, as would anyone else that is in the same position.  When you find the right NVIDIA driver, can you also go look for the appropriate Intel and AMD drivers?

Ugh!!! I've just landed here. I've had a Ceton InfiniTV 4 PCI Express card with Verizon FiOS TV for about a year on a Win7 HTPC and things had been fine until about a month ago. I now have the white flicker problem only on premium movie channels, HBO, MAX, etc. and only when using the Media Center output to my main TV. Xbox 360 in the bedroom with live or recorded is fine. So, I take it the white flashing I'm seeing is the 29/59 bug?

SOB I just fixed it. I had upgraded the Intel Video drivers for Core-I5 for the first time about a month ago. I've since even tried a newer version to fix the problem. What I did not realize until searching around here on the site and then looking at the driver settings is that Intel must have defaulted to using "Image Enhancement" settings like Adaptive Contrast etc. under the Media section of the drivers. I turned all of that crap off and BAM!!! problem gone. WTF? seriously Intel. Stop defaulting image enhancement settings that you didn't use in previous releases.

AMD does the same. I have to turn off all of that crap, and the 29/59 stuttering goes away.

Richard, no offense, but it seems all you did was "try" to argue semantics.  Whether it should be called a bug or not.  Seriously?  I agree though, the 29/59 framerate bug could have been named better.  It looks like you didnt not understand what I meant by mixed soft/hard telecine content; if you did, you wouldnt spent all the effort trying to explain what "mpeg2 headers" are.  You might want to read up on what soft/hard telecine content is; and, re-read my original post.  I also put a more detailed explanation of what's going on "under the hood" below.

Older GPUs like my old GT8500 dont bother IVTCing the hard telecine portion of the mixed content (59.940 interlaced fields per second); so, it only has to worry about deinterlacing it to 29.97fps.  These older generation GPU without IVTC capabilities can easily do this without worrying about switching IVTC on and off.  The content still switches between 23.976fps and 29.97fps; but, that's still okay.  With newer display cards, they do IVTCing of hard telecine instead of deinterlacing in the hardware; reconstructing perfect progressive frames at 29.97fps. They don't do decimation (removing of duplicate frames); so, the "hard" telecine portion of the content stays at 29.97fps instead of reducing it to 23.976fps.  IVTCing of hard telecine content in itself isn't the cause of the problem; its when trying to turn IVTC on and off when switching between hard and soft telecine mixed mode content; which apparently most GPU with IVTC dont do too well.  It's not a matter of stronger or weaker GPU.  You're right that adding additional post processing features such as dynamic contrast does add to the switching delay; which can exaggerate the stuttering effect.  I haven't seen any ATSC broadcasts with this type of mixed mode content; at least not in my area.

It is possible to fix this issue by IVTCing via software; instead of leaving it up to the GPU.  This can be done one of two ways:

1. dscaler mpeg2 IVTC mod decoder  It's really old; but still does the job.  The only problem is it only has bob/weave deinterlacing.  The great thing about this solution is it not only handles IVTC correctly, it also performs the addition decimation step to convert the full TV recording to a stable/consistent 23.976fps without any framerate change or deinterlacing.  With Reclock, you can go one step further by by restoring the original 24.000fps camera framerate of the full TV show or movie without any quality loss.  You can even play it back on a TV at 24.000fps/24.000Hz.  I know this, because this is what I currently do now.  The only drawback to this method is there's no deal deinterlacing in this mpeg2 decoder; just basic bob or weave.  So, for video based content; such as Jay Leno TV show, News, etc... it will lose data when blending.  I tried to convince the creator of dscaler to add deinterlacing; but, unfortunately he lost interest a long time ago.

2. Use MadVR video renderer instead of EVR.  With this option you get best of both worlds, both full deinterlacing for video content and IVTC.  The only downside to this is Windows Media Player's builtin player can't use a different video renderer; so, playback needs to be done via an external player such as MPC-HC.  So, for practical purposes, this isn't even a real option for anyone.

The downside to both solutions is they can only handle content without DRM content protection restrictions.  For people who use R5000 TV tuners with SageTV (such as me), they can at least use the first solution (dscaler mpeg2 IVTC decoder).  I use R5000 TV tuners + sageTV.  However, sageTV cant use an external media player like the way Windows Media Center can.  Plus, I wouldn't want that anyway since I'd lose all video overlay/OSD effects.  That's how I was able to witness this problem long before it was ever reported by people using cablecards on Media Center.

This issue does need to be addressed by display card manufacturers.  It's too bad they dont test this kind of content before releasing newer generation display cards.

-

-

richard1980

mkanet2

Actually, it looks like you have it backwards richard; and, completely wrong information.

What part is backwards/wrong?  I understand this issue completely, perhaps better than most.

mkanet2

The actual problem was caused by introducing additional hardware decoding capabilities (more advanced IVTC/deinterlacing) in newer display cards when trying to handle mixed soft/hard telecine mpeg2 encodings.  It was NOT because of a "weak GPU"; in fact, it was clearly the other way around.

It has been pointed out several times that the actual problem is with the content.  Specifically, the MPEG headers contain information about each picture in the stream, and that information is what determines whether a specific picture should be treated as interlaced or progressive.  The switch from processing content marked as interlaced to processing content marked as progressive is what causes the various symptoms, such as stuttering, screen flashing, and screen blanking.  Do not confuse the symptoms with the problem.

As for the words "weak GPU", I don't know how else to describe it.  For this specific issue, the stuttering is the result of dropped frames;  the frames are dropped because some GPUs can't change the state of the deinterlacer fast enough to keep up with the incoming video stream.  Additionally, it has been proven that a GPU may stutter when certain post-processing options are enabled, but doesn't stutter when those post-processing options are disabled.  It has also been proven that there are certain GPUs that are powerful enough to play the 29/59 content without stuttering, even with post-processing options enabled.  So I don't know what you would call it, but when something isn't powerful enough to do what it is being asked to do, I call it weak.  And clearly, there are many GPUs that are not powerful enough to play 29/59 content smoothly.  Therefore, they are weak.  How else would you describe it?  Would you prefer I use the word "slow" instead of "weak"?

mkanet2

It actually takes relatively little GPU power to decode these videos; which is why any old school GPU/standalone STB can decode these video streams with no stuttering.

Except that is not true at all.  There are actually very few GPUs that are powerful enough to play the content smoothly.

mkanet2

Later down the road, another bug was introduced in the nvidia drivers which causes the "white-flash" symptom.  Unfortunately, people on the forum started incorrectly referring to this as the "29/59 bug" as well; which caused a lot of confusion for many people.

I think your definition of "29/59 bug" is what is incorrect.  First, it's not a bug.  WMC's reaction to the MPEG header flags is as expected.  Second, as I stated above, the 29/59 issue is a problem with the content, and there are several different symptoms that are caused by this problem.  You are saying that "29/59 bug" is the correct term to use to describe stuttering, when that is not correct.  "Stuttering" is the correct term to describe stuttering.  "29/59" just describes the frame rate change that can be observed from the "Debug:  Presentation" screen in WMC.  But don't stop there.  What does it mean when the listed frame rate changes?  It means the flags in the MPEG picture header are changing.  And that is the root problem.  Stuttering is not the problem.  Stuttering is just a symptom of the problem.

mkanet2

Part of the reason the original problem still exists today is because of all the confusion introduced along the way.  In fact, there's so much confusion now that people who have any kind of video stuttering under Media Center; even on local OTA ATSC channels, refer to their problem as the 29/59 bug!  I have a feeling its going to be near impossible for vendors to fix the problem due to all the confusion introduced by newcomers.  If I was trying to understand the original real problem (without seeing it), I would be confused too if I did a google search for "29/59 bug".

I agree.  And part of the problem is the discussions from the early days.  "Stuttering" is a symptom of "29/59 content", yet there are tons of posts where people have incorrectly used the term "29/59 bug" to describe the stuttering.  A more appropriate phrase would be "stuttering due to 29/59 content".  Simply put, the symptom was mislabeled as the problem, and that mislabeling still exists today.  One of my points has been that the symptom and the problem are NOT the same thing.  People want the stuttering fixed, but they fail to see that stuttering is not the only symptom.  As I explained to Carl, fixing the stuttering doesn't fix the problem.  Specifically, when the header information that accompanies each picture doesn't actually match the picture, that causes the picture to be processed incorrectly.  If you want to see for your own eyes, grab one of the GPUs that are known to play smoothly, and play Grimey's first Invention of Lying clip (see here).  Pay specific attention to the windows and lettering on the building.  You'll notice combing, and if you examine the MPEG headers, you'll also notice that the pictures are incorrectly flagged at the points where combing is evident.  The incorrect flags cause WMC to send the wrong instructions to the GPU, which causes the GPU to process those pictures incorrectly.  It doesn't matter if the GPU plays stutter-free, the content still isn't being processed correctly because the flags are still set incorrectly.  I have repeatedly said that the only way to fix the problem with the incorrect flags is to go back to the entity that encoded the content, give them a technical explanation of what is happening, and try to get it resolved.

Even if we were to get to a point where the flags always match the pictures, it is still possible for the content to contain a mix of field pictures and frame pictures, and the rendering instructions could require changing the state of the deinterlacer in order to play the video correctly.  And as you (should) know, not all GPUs are capable of doing this without dropping frames (which means there will be a visible stutter).  And again, there is an answer to this.  There are a few GPUs that are known to play 29/59 content without dropping frames (which means no stutter).  Combined with the previous solution, this should result in perfect playback.

Unfortunately, there are people that don't like either of those answers.  There are people that think there is nothing wrong with the content (and to be fair, it is entirely possible that nothing is wrong with the content they have seen, but Grimey's clips have been here long enough that there's really no justification in anyone denying the fact that the flags in the picture header are not always correct).  Additionally, there are people that think there's nothing wrong with the GPUs, despite the fact that multiple people have stated that switching GPUs fixed the stuttering.  The popular answer among those deluded people is to blame Microsoft, and they use faulty logic to justify their position (I'm reminded of all the people that use "it plays smoothly on a cable box" as justification, despite the fact that the cable box has a completely different graphics processor than their computer, or people that say "it plays smoothly in (insert application here)", despite the fact that the application they reference utilizes the CPU for deinterlacing, not the GPU, or that it ignores the flags altogether, rendering truly mixed content incorrectly.)

Here's a perfect example of somebody that thinks there's nothing wrong with their GPU:

Quatrix

richard1980

There's more to this issue than just stuttering on weak GPUs.

richard1980

Expecting WMC to run well on poor hardware is foolish.

Sorry, but blaming this on "weak" hardware is ridiculous.  The 29/59 stutter is still obvious on a $1,000 GTX 690, the fastest GPU (actually dual GPU) available.

If your $1,000 GTX 690 is the fastest GPU available, why are other GPUs able to switch the state of the deinterlacer faster than the GTX 690?  Clearly the GTX 690 is not the fastest GPU available when it comes to switching between interlaced processing and progressive processing.

mkanet2

even on local OTA ATSC channels

If you are implying that 29/59 content does not exist on ATSC broadcasts, you are incorrect.  I have seen the 29/59 issue on my ATSC NBC broadcast.  Again, this goes back to the early days, when it was thought this issue only occurred on premium channels, when in reality, it occurs on non-premium channels as well.

mkanet2

If I was trying to understand the original real problem (without seeing it), I would be confused too if I did a google search for "29/59 bug".

As I pointed out earlier, it's not a bug, so obviously any search for a bug would turn up BS results.  Luckily there is a wiki that gives a "technical explanation for dummies" here.

You are talking about something completely different than what is being discussed in this thread.  The issue being discussed in this thread has absolutely nothing to do with inverse telecine.  I suggest reading the link from my previous post (the one you quoted), as it is a very concise explanation of the issue we are discussing.