Interlacing artifacts with motion

[soccerdad]

I see that most are happy with the video quality with the latest firmware. On my Hitachi 1080P, 120HZ TV, when set to Native, I get a ton of interlacing artifacts on many 1080 channels. (lines running horizontal around the moving objects). When set to 720, I don't get this. Anyone else have this issue or is it just me?

[Sammy2]

Nope. Not seeing any combing at all.

[hub1]

Try setting it to 1080p

[richard1980]

Sounds like the 29/59 issue to me. Specifically, it sounds like you've got frames/fields with progressive_frame=1 (indicating the reconstructed frame should not be deinterlaced) when they should actually be progressive_frame=0 (indicating the reconstructed frame should be deinterlaced).

[Sammy2]

Sounds like the 29/59 issue to me. Specifically, it sounds like you've got frames/fields with progressive_frame=1 (indicating the reconstructed frame should not be deinterlaced) when they should actually be progressive_frame=0 (indicating the reconstructed frame should be deinterlaced).

The OP said

lines running horizontal around the moving objects

Is that the 29/59 bug? I understand the 29/59 bug to be a strobe like flicker and not to be combing.

[foxwood]

Is that the 29/59 bug? I understand the 29/59 bug to be a strobe like flicker and not to be combing.

A strobe like flicker is a symptom of the bug (the markers in the video fields don't match the actual content). Richard is suggesting that the effect that soccerdad is seeing is caused by the same problem - markers in the video fields don't match the actual content.

[soccerdad]

OK, if it is the 29/59 bug, is there anything to do about it? I searched the forum and the search utility does not like 29/59. The ones I found seem to be processor related. My recording HTPC is a quad core AMD chip with a Gigabyte 880G MB. Capture is from a HDHomerun Prime. Where does this bug reside? I do not see flashing, only combing.

I will try setting to 1080P and see what happens.

[scyto]

I have also seen issues where I think the video broadcaster has content where the interlacing field order is misflagged. oddly this is often when folks are reusing video. For example the interlaced video is in a frame in the center of the screen. The main video is fine, but the insert shows mice teeth or combs.

[Crash2009]

OK, if it is the 29/59 bug, is there anything to do about it?

If you got a few minutes, you could read this one. http://www.thegreenbutton.tv/forums/vie ... f=7&t=2440 There is quite a bit in there on combing, pixelation, signal, and the 29/59 thing. I just kept throwing $$$ at it until it went away. I was running some pretty shakey hardware at the time. The shotgun approach seemed logical to me at the time.

[richard1980]

Is that the 29/59 bug? I understand the 29/59 bug to be a strobe like flicker and not to be combing.

The 29/59 issue is an issue with the content itself. The MPEG header contains a picture coding extension which accompanies each picture in the stream. One of the flags in the picture coding extension is called progressive_frame. When set to 0, the progressive_frame flag indicates the picture is part of an interlaced frame, thus the decoder should treat the frame as an interlaced frame (which means it should be deinterlaced for progressive output). When set to 1, the progressive_frame flag indicates the picture is part of a progressive frame, thus the decoder will treat the frame as a progressive frame (which means it should be output as is, without deinterlacing it first). Combing becomes evident when the progressive_frame flag is set to 1, but the content is actually interlaced. Combing is just one of the symptoms of the 29/59 issue, and the only one that definitively identifies incorrectly encoded interlaced pictures (content can contain a mixture of interlaced/progressive flags without being incorrectly encoded..this happens with hard-telecined content). Oddly enough, I seem to be the only person in the world that has ever noticed the combing (until now, assuming this is the source of the OP's combing).

When the progressive_frame flag in one frame does not match the progressive_frame flag from the previous frame, the decoder must switch processing modes. This can cause other symptoms, such as flickering or stuttering (the two most commonly reported symptoms). Technically, this has nothing to do with whether or not the progressive_frame flag is set correctly, thus it has nothing to do with whether or not combing will exist. However, since hard-telecined content is the only kind of content that can have a mixture of progressive_frame flags and still be encoded correctly, and hard-telecine encoders are not as common today as soft-telecine encoders, chances are that any content containing a mixture of progressive_frame flags has been encoded incorrectly. There is one caveat though: In Europe, some content is purposely encoded with mixed progressive/interlaced content.

The term "29/59" came from WMC. In WMC, you can pull up the Debug: Presentation screen and see the changes in the progressive_frame flag are reflected in WMC by changes to the frame rate displayed in the Debug: Presentation screen. The issue was first identified in the US, and here in the US the listed frame rates fluctuate between 29.97 and 59.9401 (unless you are playing the content at 1.4x speed, in which case the listed frame rates will fluctuate between 41.961 and 83.9222...oddly, this is the only trick mode speed that exhibits this behavior). Seeing as how this issue occurs in places other than the US, I think there should be a new name for this issue. Which leads to the next point...

The term "bug" came from WMC users thinking the symptoms were a bug in WMC...which they aren't. Even today, people throw around the term "29/59 bug" (yes, I'm pointing at you ). It's proving to be a very difficult task to get people to use the correct terminology, so I've pretty much given up.

OK, if it is the 29/59 bug, is there anything to do about it?

The only solution is to re-encode the content using the correct progressive_frame flags. I haven't explored this option, so I don't know if it is a practical solution. Keep in mind that your issue may not actually be a problem with the progressive_frame flag...you'll need to confirm that first. Play the content in WMC and pull up the Debug: Presentation screen (on the remote, 4-1-1-Info; on the keyboard, it's 4-1-1 then Ctrl+D. This will bring up the Debug menu. Use the right arrow to get to the Presentation screen). Once you have the screen up, watch the content and the frame rate at the same time. If the combing correlates to the changing frame rates, then this is the source of the combing.

[JAS]

You're not the only person to notice combing.

I'm been using media centers for years in the house and have never had this issue until the Echo experiment.

But, I understand that the Echo is a work in progress and expect this will get fully fixed.

[Sammy2]

Could this be related to the source and not the echo? I am not experiencing these issues on the 2013.129 f/w or the 122 or previous f/w's either for that matter. Maybe the video processor in an HTPC (either on chip or dedicated) is better at handling this issue.

[Embiggens]

This problem completely disappeared for me with the 129 firmware.

Sent from my PI39100 using Board Express

[ucfknight]

This problem completely disappeared for me with the 129 firmware.

Me too. Prior to that I had really bad combing artifacts on some 1080i channels.

[Crash2009]

You're not the only person to notice combing. I'm been using media centers for years in the house and have never had this issue until the Echo experiment. But, I understand that the Echo is a work in progress and expect this will get fully fixed.

Not me, somehow I managed to create some combing long before I got the Echo.

[richard1980]

So the Echo had combing issues before the 129 F/W? Unbelievable.

[soccerdad]

FWIW, I have been using the echo a lot this weekend and have not seen any of the combing at all. I am not sure what channels I was on before that showed it, but can't find a single one now. Very odd. I will keep tracking it and post back if I get more informaton. I am now checking the stream type (1080P, 720 etc) every time I see it switch. I have not seen a 1080i one yet.

[soccerdad]

Well the combing is back. Both with it set to 1080 and to native. Pretty bad on food network. I have not updated to the latest beta yet because of some bad reports, but guess I will try it to see if it helps.

From reading other posts, I don't see how combing can be caused by anything in my HTPC since the playback is done by the echo only.

[Embiggens]

Yeah after my post, I noticed food network was the one channel I watched that still showed some combing on fast motion. And unfortunately the 0206 firmware actually seems like a step back for me- combing was, as far as I could tell, completely absent on comedy central on 0129 but now it's back, although maybe less noticeable than it was 3 firmwares back.

[richard1980]

I still suspect the problem is with the content, not the Echo. You'd really have to compare what a reconstructed frame looks like to what the MPEG headers say to know for sure though (and this is where the PC comes in handy), and quite frankly, Ceton should have known this would be an issue. After all, Eric seems to know quite a bit about the 29/59 issue, so he ought to know about the combing. I would think Ceton would want to integrate interlace detection that doesn't involve depending on the MPEG headers since the headers can't be trusted.