WMC picture quality - jaggies, moire, shimmering

[tzr916]

Ever since I built my HTPC I have had picture issues that show up using WMC but not Zoom Player+LAV. As a workaround, I have resorted to launching external player using RTVHD addin. Took time to setup remote functions but actually works great. I'm just curious if others could play this sample wtv clip in WMC and tell me if they see the same issue-
https://drive.google.com/file/d/0B82Gqd ... sp=sharing

Focus on the channel logo. I see jaggies, shimmering, and other bad stuff on my HTPC and laptop (both nvidia gpus). If I use 411+Info the refresh rate stays at 59Hz, so doesn't seem to be a 29/59 issue.

WMC-


ZP LAV-


Please reply if you see the problem that I see and what GPU you have.
Thanks

ps. for more background reading check out my original thread from July 2013 where I explain how I have tried three different GPU's, drivers, changing decoder in wmc with shark, etc, etc -
http://www.thegreenbutton.tv/forums/vie ... f=5&t=5563

[RyC]

I played your clip on Win 8.1 WMC with a Radeon 7870 and I see the logo get all shimmery as well. However, I haven't played around with any video settings since it's just my office PC. Extenders seem to play it back correctly though, I don't see it get shimmery or jagged at all on an extender.

[tzr916]

Thanks for confirming. I am learning that this might be called "soft telecine". I'm trying to figure out if it is caused by my local cable company, the channel, the production, etc. Here is another site where we are discussing-
http://forum.doom9.org/showthread.php?p ... ost1653987

[barnabas1969]

I'm downloading it to my desktop PC at home, but I'm not home at the moment. I'll move it to the HTPC and try it when I get home.

[richard1980]

If I use 411+Info the refresh rate stays at 59Hz, so doesn't seem to be a 29/59 issue.

You are looking at the wrong thing. "RefreshRate" is on the Display screen and indicates the refresh rate of your display. You should actually be looking at the frame rate listed on the Presentation screen...if you do, you'll see the frame rate bouncing back and forth between 29.97 and 59.9401, which means the progressive_frame flag is bouncing between 1 and 0.

On my GPU, I can clearly see artifacts only when the frame rate is listed as 29.97. When it is listed as 59.9401, everything looks perfect.

Frame rate is displayed as 59.9401 (progressive_frame = 0, frame is being deinterlaced)

Frame rate is displayed as 29.97 (progressive_frame = 1, frame is not being deinterlaced)

Since the rest of the frame looks correct, I'd say the problem is the overlay just doesn't match the rest of the frame.
Scratch that...I just watched the whole thing. The frames are in fact encoded incorrectly. There just weren't any artifacts in the shot above because there wasn't enough movement. But looking at other frames, you can clearly see the artifacts (especially near the beginning of the clip where the words are scrolling, the camera pans to the house, and the cars are driving).

Simply put: This is just the 29/59 issue. Welcome to the club!

[tzr916]

Ah ok. So now we know the jaggies are visible on nvidia GT640, an AMD HD7870, and an Intel HD4000... I'm not sure what you mean by "the problem is the overlay just doesn't match the rest of the frame"? But the picture problems are not just jaggies in the logo. I am seeing so much more than that. Basically any portion (large or small) of a "bad" frame that has fine detail will shimmer and move - Things that should NOT move like a sandy beach, an asphalt road, a grassy field, a large tree with tiny leaves, a chain link fence at a distance, a brick wall, a pattern in a shirt or chair or carpet....

The thing is, I NEVER see the problem on the major networks (ABC, NBC, CBS, FOX). It comes and goes on most but not all of the other cable channels. I can't figure any pattern to it, one show will have it then the next won't (even on the same channel). It gets bad in movies on channels like AMC, Syfy, USA, TNT, LIFE, LMN, HBO and in one hour shows on ID, TLC, DISC, SCIENCE, etc.

So, besides launching an external player, what can be done?
Why doesn't everyone who uses WMC see the same issue?
Is it just my cable company?

[richard1980]

I'm not sure what you mean by "the problem is the overlay just doesn't match the rest of the frame"?

Disregard that statement...I was mistaken (see my correction above). I was only examining that one frame, but after I looked at other frames I saw where artifacts were exhibited all throughout the frames. It is blatantly obvious that at least some of the frames that have progressive_frame set to 1 should actually have the flag set to 0. I'd have to pull this out of the WTV container to be able to do a frame-by-frame analysis of it to know if there are any of those frames marked correctly, but my guess is that none of them are correct.

So, besides launching an external player, what can be done?

That's probably what you'll end up doing (or just changing the WMC codec). For the content you have already recorded, the only other thing you can do is evaluate every frame with your own eyes and set the progressive_frame flag by hand so that it matches the content. I'm sure you'll decline that option (I know I would). For future content, you'd have to go to whomever encodes the content and get them to stop encoding incorrectly. Otherwise, it's back to the external player.

Why doesn't everyone who uses WMC see the same issue?

There's a difference between "see" and "notice". A lot of people see the issue, but they don't notice it. I've only seen a few people that have actually noticed it. I notice it all the time. Although, I rarely see anything as bad as what you posted. Most of what I see is much more subtle.

Is it just my cable company?

No. Although your cable company could certainly be contributing to the problem.

[barnabas1969]

I see it too. It comes and goes, depending on the amount of motion in the frame. I didn't turn on the 411-Info display, but the jaggies on the IDHD logo go away when there's more motion in the frame. I would guess that the high-motion parts are progressive, and that the low-motion parts are interlaced.

If, as Richard says, the progressive frame flag is incorrect, that would explain the problem.

[RyC]

I pulled up the 411 info on your clip, and it's definitely has the 29/59 problem (as confirmed already). I have ID HD here, and watching for a few minutes, it is not switching between 29/59 (holding at 29.97), and I'm not seeing any shimmers or jagged lines. I'm not sure if that helps you narrow it down to show/channel/cable provider though.

[tzr916]

Appreciate all the input. Helped me finally confirm that my HTPC is not defective. Seems external player/decoder is the only option (but SOL for live tv and copy protected channels).

[webminster]

I have Comcast as well, and a GT430-based card. I do see some shimmers on logos on some channels. I don't see the white flashing anything like this on my system. Since this is a wtv file (manual recording), it probably won't be a sensible suggestion... but I assume you've done all the due-diligence stuff (eth6 firmware updated, the normal suggestions for nvidia cards, etc) to mitigate any of those possibiities?

[tzr916]

I've never seen the whole frame flicker/flash either. Yes, I've spent months trying all the 29/59 driver tweaks, reg keys, three different GPU's, several driver versions. It's pretty clear that the content I am receiving from Comcast doesn't play properly on any GPU (as tested here)... But I dont' get how the Tuner or firmware has anything to do with the problem?? It just passes the digital stream doesn't do any encoding/decoding.

[richard1980]

I converted the file to MPG with VideoReDo so I could do a frame-by-frame analysis using DGIndex. To put it simply, that clip is a disaster. Not only are a significant number of the frames encoded with an incorrect progressive_frame flag, but the repeat_first_field (RFF) flag is messed up in several spots throughout the clip. This was definitely encoded by a very poor encoder.

I would guess that the high-motion parts are progressive, and that the low-motion parts are interlaced.

Not at all. There seems to be a good mixture throughout the entire clip.

I have ID HD here, and watching for a few minutes, it is not switching between 29/59 (holding at 29.97)

Holding at 29.97 means the content is encoded incorrectly. It should hold at 59.9401 (the displayed value for progressive content is frames per second, but for interlaced content it is fields per second).

but I assume you've done all the due-diligence stuff (eth6 firmware updated, the normal suggestions for nvidia cards, etc) to mitigate any of those possibiities?

But I dont' get how the Tuner or firmware has anything to do with the problem?

Neither the tuner nor the GPU have anything to do with the faulty data in the MPEG stream.

[tzr916]

...Neither the tuner nor the GPU have anything to do with the faulty data in the MPEG stream.

I guess it's too much to ask for MS to release a decoder that actually handles the faulty data as well as most modern consumer HD DVRs. The video coming out of my Tivo Elite looked so clean and smooth fed from the same coax feed, same provider, same channels, same cable card...

[barnabas1969]

This may be a dumb question, but how can a decoder correctly handle incorrectly flagged content?

[tzr916]

Look at the screenshots in first post. LAV does it VERY well. Absolutely no jaggies or shimmering and very seldom moire. Play my clip in external player with LAV, you will see.

[barnabas1969]

Look at the screenshots in first post. LAV does it VERY well. Absolutely no jaggies or shimmering and very seldom moire. Play my clip in external player with LAV, you will see.

I believe you, I'm just asking "how". I'm sure Richard will be along to explain it. He's a smart guy.

[richard1980]

LAV does it VERY well. Absolutely no jaggies or shimmering and very seldom moire.

Every frame in the clip you posted is progressive, though about half of the frames are marked as interlaced. The only possible way to achieve proper display of the "interlaced" frames is if the decoder ignores the progressive_frame flag associated with those frames and instead treats them as progressive. The reason it looks correct with LAV as the decoder is because you have disabled deinterlacing in LAV. When you give the decoder nothing but progressive frames and then tell it to treat them all as progressive, of course it's going to look correct. Try changing the deinterlacing settings in LAV and watch what happens.

This may be a dumb question, but how can a decoder correctly handle incorrectly flagged content?

I'm going to assume you are talking about the progressive_frame flag. Here are the rules:

• If progressive_sequence is set to 1, progressive_frame must also be set to 1.
• If progressive_sequence is set to 0, progressive_frame can be set to either 0 or 1.

Now pretend you are a decoder. You receive a frame with progressive_sequence set to 0 and progressive_frame set to 0. With only that information (and the rules above), you have to answer a very simple question: Is the frame flagged correctly? I don't mean "Does the frame conform to the specifications?" I mean "Does the flag match the content?" Answer that question, and you will have answered your own question.

[adam1991]

This may be a dumb question, but how can a decoder correctly handle incorrectly flagged content?

This is the world I live in every day: "I'll admit I may have given you garbage; ignore that and produce what I want, or else I won't pay you. And don't even try to teach me how not to give you garbage. I'll do whatever random things I've developed over the years, and you won't change that. If you can't give me what I want, I'll take my business elsewhere!"

[barnabas1969]

This may be a dumb question, but how can a decoder correctly handle incorrectly flagged content?

I'm going to assume you are talking about the progressive_frame flag. Here are the rules:

• If progressive_sequence is set to 1, progressive_frame must also be set to 1.
• If progressive_sequence is set to 0, progressive_frame can be set to either 0 or 1.

Now pretend you are a decoder. You receive a frame with progressive_sequence set to 0 and progressive_frame set to 0. With only that information (and the rules above), you have to answer a very simple question: Is the frame flagged correctly? I don't mean "Does the frame conform to the specifications?" I mean "Does the flag match the content?" Answer that question, and you will have answered your own question.

So, you're saying that some decoders are able to examine the content on the fly, and correctly decode it regardless of the flags?