GetParity(): how does it work?

[bilu]

Hi,

I think this is an important matter if GetParity() is reliable enough to bring field order information to deinterlacers.

- How well does it work with DirectShow, AVISource and MPEG2Source ?

- Does it get retrieved during the whole clip or just at beginning? There are concatenated clips with different field orders around.


Thanks for your time.

Bilu

[sh0dan]

DirectShow & AVISource always assume BFF, as they have no way of knowing parity. This can however be changed by assumetff().

MPEG2Source should be correct.

When several clips are spliced with different parity, the original parity of the different clips are retained.

[bilu]

Originally posted by sh0dan
When several clips are spliced with different parity, the original parity of the different clips are retained.

Imagine you have a VOB with concatenated parts with different field orders, something that could show up in the D2V file as partly 00000 and partly 22222. How would GetParity() behave with such a stream? Is it able to receive the flags from mpeg2source at any given frame? Would it be reallistic to query GetParity at every frame to monitor field orders?

Or does it just get the first flag and assumes it as the result?

Bilu

[Guest]

Any MPEG decoder that delivers to an AVI is responsible for delivering a consistent field order, otherwise the AVI will not be playable.

In any case, the only time I have ever seen runs of 0s and 2s mixed in a DVD is as repeats in a 3:3 sequence, e.g.:

...0123012300000000123012301222222222222222301230123...

The field order of the content is consistent due to the RFF repeated fields. It is hard to explain.

Just remember that an AVI cannot specify field order, so any sane decoder has to deliver a consistent field order. The question of per-frame querying thus does not arise.

[bilu]

It's not hard to explain, I understood it perfectly (part of the explanation is on the Graft Conjecture thread :) ).

" Just remember that an AVI cannot specify field order, so any sane decoder has to deliver a consistent field order. The question of per-frame querying thus does not arise."

So the main problem is with AVI sources, and you could use GetParity in Decomb for MPEG-2 sources? Or it would be limited by trim commands on MPEG-2, and so there was need for the Graft Conjecture?


Bilu

[Guest]

Originally posted by bilu
So the main problem is with AVI sources, and you could use GetParity in Decomb for MPEG-2 sources? Or it would be limited by trim commands on MPEG-2, and so there was need for the Graft Conjecture? I can use GetParity() for any source. The user can use AssumeTFF and AssumeBFF to set the parity. It's certainly worth considering to use the Avisynth mechanism rather than duplicating it. On the other hand, I do like the idea of forcing my user to make an affirmative decision by requiring the presence of the order parameter.

My understanding is that the MPEG decoders correctly report field order to Avisynth. The conjecture was simply a heuristic for looking at a D2V and determining the field order. The conjecture appears to be true, so it provides a means to confirm whether a given MPEG decoder is correctly reporting the parity to Avisynth.

[bilu]

Originally posted by neuron2
On the other hand, I do like the idea of forcing my user to make an affirmative decision by requiring the presence of the order parameter.


Since my automated tool uses only MPEG-2 sources, I could do

function MakeTopFirst(clip c) {
c= GetParity(c)? c:ComplementParity(c)
return c
}

MakeTopFirst()

Telecide(order=1,.....)


Will have to try it and see how it deals with trimmed sources or cutted VOBs.

Best regards,
Bilu

[sh0dan]

@neuron: I understand why you force the user to enter it - I actually guessed that's why you made it work the way it does.

I don't know which solution is the best. Using parity is the most consistent - using forced parameters is less "user error" prone.

Point 1: Smoothdeinterlace is actually very good at handling different material - it also accepts material, where separatefields() has been used. Separated material is actually the best way of assuring correct parity. Using parity would allow users to easily check parity, by using separatefields() instead of your filter.

There is however the "minor" bug, so it doesn't adjust framesize, when recieving separated material.

Point 2: Couldn't a "detect parity" algorithm be devised using a simple bob, and comparing frames?

[trbarry]

I posted a script function awhile back that reports on parity. See this thread (http://forum.doom9.org/showthread.php?s=&threadid=34511&highlight=complementparity).

- Tom