The video mode does matter. But I think it has to do with performance. I see bad stuttering with NBC at 1920x1080 but if I reduce the resolution to 1024x768, I don't see it. I bet if my TV supports 1366x768, I won't experience stuttering either. I am using VGA. I believe my problem is most likely related to Windows 7 codec and my video card. I have not experience the stuttering problem in Vista prior to upgrade.

charred_water:

I did some experiments last night based on the information in this thread.

 One experiment was to switch displays from my old Sharp Aquos LC-37D6U (2006 vintage) to a new Samsung T240HD monitor (both capable of displaying 1080i)

 My "stuttering" problem, where my screen goes black periodically on certain channels, went away with the Samsung monitor!

I think the only reliable way we have to correlate "stuttering" with the "1080i frame rate bug" is to examine the frame rate in the "411 Info" debug screen. If the stuttering occurs if and only when the frame rate rapidly switches between 29 and 59 Hz, then you have the 1080i frame rate bug, which can manifest as "screen blanking" under certain conditions. When late model Sony TVs (e.g. W4100, XBR6, W5100) are paired with Nvidia cards such as the 9600GT, Nvidia drivers more recent than the ancient 181.71 beta exhibit another bug, which I call the "PC/HDTV timing bug". In this configuration, the 1080i frame rate bug manifests as screen blanking, and PC/HDTV mode switches also occur when going between video and desktop. Presumably this doesn't happen with most TVs, else it would be far more frequently reported, and so it wouldn't surprise me if switching TVs solves the screen blanking, though I would expect it to be replaced by "judder" if you really are experiencing the 1080i frame rate bug. I guess it's possible your "old Sharp Aquos" is subject to the PC/HDTV timing bug, but whether or not the stuttering you observe has anything to do with the subject of this thread comes down to what "411 Info" says.

TimSchreck-MS:

This thread has already touched on a cornerstone of what’s causing the symptoms described – frame rates and encoding.  Broadcasters have many options for their content and the Windows video processing pipeline relies on and responds to how the content is authored and flagged.  If the content is authored and flagged correctly, we do not see any playback inconsistencies.  However, if the content is flagged incorrectly or the content is mixed, then the Windows video processing pipeline must gracefully handle this. 

 

Part of this issue is that some content that is broadcast frequently switches between interlaced (59.94 fps) and progressive (29.97 fps).  We’ve also seen cases where content is incorrectly flagged – i.e. content is interlaced but marked as progressive.  In either case, this causes a hiccup as the underlying Windows video processing pipeline has to respond.  Specifically the GPU deinterlace implementation needs to reset/recover and that can take a few frames.

 

We know that there is room for improvement in how our video processing pipeline handles scenarios where the content itself or how it is flagged does not fully adhere to standards.  The Windows Media Center team is working to provide a more robust video processing pipeline; however, these efforts are very complex and are geared toward future versions of Windows Media Center.  Given that, we will evaluate if there are portions of this that can be safely implemented on existing versions of Windows Media Center and provided either through Windows Media Center Cumulative Updates or future Windows Service Packs.

 

We’re also working with content providers, recommending and encouraging better practices with content and how it is flagged.

 

millerbrad:

TimSchreck-MS:

This thread has already touched on a cornerstone of what’s causing the symptoms described – frame rates and encoding.  Broadcasters have many options for their content and the Windows video processing pipeline relies on and responds to how the content is authored and flagged.  If the content is authored and flagged correctly, we do not see any playback inconsistencies.  However, if the content is flagged incorrectly or the content is mixed, then the Windows video processing pipeline must gracefully handle this. 

 

Part of this issue is that some content that is broadcast frequently switches between interlaced (59.94 fps) and progressive (29.97 fps).  We’ve also seen cases where content is incorrectly flagged – i.e. content is interlaced but marked as progressive.  In either case, this causes a hiccup as the underlying Windows video processing pipeline has to respond.  Specifically the GPU deinterlace implementation needs to reset/recover and that can take a few frames.

 

We know that there is room for improvement in how our video processing pipeline handles scenarios where the content itself or how it is flagged does not fully adhere to standards.  The Windows Media Center team is working to provide a more robust video processing pipeline; however, these efforts are very complex and are geared toward future versions of Windows Media Center.  Given that, we will evaluate if there are portions of this that can be safely implemented on existing versions of Windows Media Center and provided either through Windows Media Center Cumulative Updates or future Windows Service Packs.

 

We’re also working with content providers, recommending and encouraging better practices with content and how it is flagged.

 

Tim or anyone at Microsoft...

I attempted to explain this information to my local TV affiliates and local Comcast office. They all insist that the way they encode their content is completely appropriate.

Since this bug continues to live on, do you have specific information that can be provided to broadcasters to remedy it?

millerbrad:

Tim or anyone at Microsoft...

I attempted to explain this information to my local TV affiliates and local Comcast office. They all insist that the way they encode their content is completely appropriate.

Since this bug continues to live on, do you have specific information that can be provided to broadcasters to remedy it?

The best suggestion I can give you is to do 411-info and watch for the framerate to change - if it changes between commercials, that's likely normal, but if you see it changing during the same TV program or even the same camera shot, in particular changing repeatedly, that is not normal and likely the problem.

I'm working with my local Time Warner office to get them some transport stream captures so they can put it on their MPEG analyzer now.

cVariable:

Or how about lazy MS coders get their lazy asses in gear and FIX the issue, since it doesn't come up with other software or at least is not noticeable this continues to be an MS PROBLEM!!!

I asked you in another thread to keep your comments productive, however you have continued to post in a hostile manner about this so I've reported you to the admins

Given that you feel you know with absolute certainity this is a Microsoft problem, I'm sure you have compared the video graphs between MCE and the other applications and to make sure they are drawing the same exact graph to make sure this is truly a Microsoft issue as you claim.

As I'm sure you haven't, my guess is the reason you only see this issue in MCE is that MCE will generally use hardware decoders even if other decoders are installed, where many other applications will use software decoders which will handle this differently.  Other applications building the same graph will generally see the same issue.

darinvedwards:

Guys this problem is 2 +  years old.  I gave up on Microsoft a year ago and quit posting.  I work for a very large corporation and it is funny how they can fix a SQL Server bug in the DB engine in 30 minutes and send you a patch when you are a multi million dollar customer.  I can only assume there are not enough HTPC users to warrant such support.  I've often suggested you tube videos showing just how bad media center behaves with this problem.  They should be embarassed they are selling a product that simply doesn't work with some HD programming.  Windows 7 rocks but this problem is a long time carryover in 7 and Vista.

It may not technically be a MS problem, but I have 6 TV(s) in my house, and they all work fine on NBC except my Windows Vista now Windows 7 HTPC.  I have resigned myself that any NBC content I record, I watch back using windows media player, not media center.  According to MS, it isn't their problem, but media player plays the files just fine.....Didn't MS code media player too?   HMMMMMM...

http://thegreenbutton.com/forums/t/64226.aspx?PageIndex=42

+1 blame

cVariable:

Bumping it back to the first page to keep the shame level high

the judder issue is less annoying than these unproductive rants.

mold:

cVariable:

Bumping it back to the first page to keep the shame level high

can you please be done with the juvenile shame/blame rhetoric?

the judder issue is less annoying than these unproductive rants.

cVariable:

One can only hope that the future for the responsible MS programmers ... is later imitated by one of CBS' crime shows as an especially gruesome murder!

mold:

cVariable:

Bumping it back to the first page to keep the shame level high

can you please be done with the juvenile shame/blame rhetoric?

the judder issue is less annoying than these unproductive rants.