DGIndex - PAL Interlaced not interlaced

[redfordxx]

Hi,

it happened more than once to me:
I have Pal 25fps MPEG2 source. I use DGIndex for making the source to AVS. When pressing F5, DGIndex reports Interlaced source. But when I look at the frames step by step I don't see any interlacing.
Anybody can explain? Then, I am not sure, whether to decomb it in avs (not to make it worse by deinterlacing).

Tnx R.

[TheRainmaker]

Your problem is some as like me...
Dgindex determined for all my DVDs(16/9) interlaced but i didn't see any interlacing from output...
I don't know if any programs or guis gives correct...

[Alain2]

For me dgindex is most of the time incorrectly reporting interlaced on my PAL dvd when it is actually progressive. Only way is to check a script with mpeg2source only in vdub(mod), and assess yourself if it's interlaced or not. Most of the time your assessment will be correct (especially from recent movies), but from time to time you have the odd dvd that is mostly progressive but have a few interlaced frames here and there that you missed in vdub..

[foxyshadis]

DGIndex reports the encoded nature, it does no analysis of the actual video content at all. Many PAL DVDs are encoded interlaced whether or not the content is; as Mug Funky once said, it's faster and simpler to flip it to interlaced than to check every frame to be sure there's no interlaced or field-shifted frames before starting the encode.

Trust your eyes, DGIndex's reports are only a starting point.

[neuron2]

What, it's not good enough that I explicitly cover this in the user manual, y'all need a personal telegram? RTFM!

http://neuron2.net/dgmpgdec/DGIndexManual.html#Video

[redfordxx]

OK, sorry neuron, it's quite long time ago I read it...


So ... If I see it correctly. There can be other problem:
When it was progressive source and is encoded interlaced there can be introduced small combing. Because it is lossy encoding and the loss can make difference between fields after decoding. So if I see progressive source with interlaced flags, some kind of slight decomb-postprocessing (is that called kernel deinterlacing?) and not field matching can be suitable... Am I right?

[Terranigma]

I actually ran across 1 progressive flagged video with some interlaced frames. It was a ntsc film video (It was part of the bonus material from the Lord Of The Rings) that was improperly ivtc'ed it seemed. Or It was correctly ivtc'ed, but the studios decided not to deinterlace or blend the interlaced frames. It was fluid after all, no dupes. :devil:
Was very unusual.

[neuron2]

OK, sorry neuron, it's quite long time ago I read it... Don't just read it once. When you run into something unexpected, look up that thing in the manual.

Am I right? No. As long as you upsample it the same way as it was downsampled, there will not be artifacts.

[redfordxx]

No. As long as you upsample it the same way as it was downsampled, there will not be artifacts.
I try to make example. It will be quite artificial but hopefully explanatory.

Let's have a block 8x16. The color value of the block is 100 only one pixel in the middle has value 200. The block will be separated into 2 fields 8x8. The One pixel will be only on one field. Then follows DCT. Quantization washes this one pixel. After IDCT we have one field in original color value 100, the field where was the pixel will maybe have color 105 because of the quantization process. After weave we have 8x16 block where are lines of 100 and 102 after each other. that's the combing I mean.

[Mug Funky]

combs will only be noticable when the encoder can't take it anymore :)

yes there will be differences between fields, but it'll be negligible until the quantizers start getting high (like above 8 or 10). mosquito noise will be showing up around this point anyway, so the combs could probably be handled the same way - with deblock/deringing.

video that looks this way can be safely processed without bizarre artefacts though (except for the mpeg noise obviously).