Convert 30i to 30p

[Overdrive80]

Hi, i attempt convert video 30i to 30p, and i used code:


Wrong
mcbob(clip)

selectevery(4,0,3)

Correct
mcbob(clip)

selectevery(4,0,2)

Although, the result not is good. Somebody idea? Excuse me for me english and ignorance ^^.

[Guest]

Use a high-quality single-rate deinterlacer. Your solution with selectevery(4,0,2) should also work.

Also a trouble report that just says "result is not good" is totally useless.

[Overdrive80]

Use a high-quality single-rate deinterlacer. Your solution with selectevery(4,0,2) should also work.

If i used the code posted, together with selectevery(4,0,2) should work fine, doesn´t?


Also a trouble report that just says "result is not good" is totally useless.

Excuse me, i dont know as say that video previewing jumping frames without fluency.

If i use separatefields(), will it work too?

[Blue_MiSfit]

Post a sample, if you are having trouble diagnosing an issue. It's usually easier than trying to describe the issue :)

SeparateFields probably isn't what you want in this case.

Derek

[Alex_ander]

If i use separatefields(), will it work too?
No.
If i used the code posted, together with selectevery(4,0,2) should work fine, doesn´t?
It should work.

Excuse me, i dont know as say that video previewing jumping frames without fluency.

That's because (4,0,3) means using wrong (non-equidistant) frames from the double-framerate sequence created with mcbob. SelectEvery(4,0,2), SelectEvery(4,1,3), SelectEvery(2,0) or simply SelectEven() is OK.

[Didée]

i dont know as say that video previewing jumping frames without fluency.
That's because your SelectEvery(4,0,3) is wrong. That is selecting frames like this:

ABCDEFGHIJKLMNOPQ

It's quite obvious that this won't play fluid. The selection is not distributed evenly.

Correct is SelectEvery(4,0,2), like neuron2 told you. SelectEvery(4,1,3) is also possible. Both do the same as SelectEven(), respectively SelectOdd().

ABCDEFGHIJKLMNOPQ

Even distribution == fluid playback.

***

Un/related note: MCBob is one huge dinosaur.

[Guest]

Also, bobbing just to throw away half the frames rubs me the wrong way.

[Didée]

Why that? A bobber is called, yes, but with SelectEven/Odd afterwards, half of the frames are not even requested from the bobber. Thus the whole thing collapses to a normal single-rate deinterlacer. Perhaps it doesn't seem very elegant, buthere's hardly any unnecessary overhead.

After all, the choice of mocomp-deinterlacers is somewhat limited, and it happens to be that all of the scripted MVTools-Deinterlacers are bob deinterlacers. But, if those would be modificated to deliver single rate, the most important change would be ..... a SelectEven/Odd() placed somewhere in the script. :D

However, dinosaurs are for museums.

[Overdrive80]

Also, bobbing just to throw away half the frames rubs me the wrong way.
If it is wrong way, as would you do it? Maybe should apply srestore?

Edit: Thanks at all, i forgive me if disturbe you.

[Guest]

I didn't say it was wrong.

[Overdrive80]

Also, bobbing just to throw away half the frames rubs me the wrong way.

I didn't say it was wrong.[/QUOTE]

Ok, it really says that rubs the wrong way, which would be more correct for you.

[chopperman]

That's because your SelectEvery(4,0,3) is wrong. That is selecting frames like this:

ABCDEFGHIJKLMNOPQ

It's quite obvious that this won't play fluid. The selection is not distributed evenly.

Correct is SelectEvery(4,0,2), like neuron2 told you. SelectEvery(4,1,3) is also possible. Both do the same as SelectEven(), respectively SelectOdd().

ABCDEFGHIJKLMNOPQ

Even distribution == fluid playback.

***

Un/related note: MCBob is one huge dinosaur.

What's the difference between SelectEven() and SelectOdd(),does the field order has something to with it?

I mean if my field order is top field first I must use SelectEven() and vice versa.

Once i see some guys also put either AssumeTFF() or AssumeBFF() before the TempGaussMC, well it nessary???:thanks:

[Didée]

What's the difference between SelectEven() and SelectOdd(),does the field order has something to with it?
No, not related to fieldorder. (Unless you have a source where top(bottom) fields have lower quality than the bottom(top) fields).
You have 100% of bob frames, and going to eliminate 50% of those. SelectEven will nuke the one half. SelectOdd will nuke the other half. That's all.

Once i see some guys also put either AssumeTFF() or AssumeBFF() before the TempGaussMC, well it nessary???:thanks:
It's not necessary when the field order of the input material is correctly flagged, and reported by the source filter (e.g.: Mpeg-2 via DGDecode/mpeg2source).
It is necessary when the source material is not flagged, falsely flagged, and/or the source filter doesn't report the field order. (e.g.: AviSource).

[chopperman]

No, not related to fieldorder. (Unless you have a source where top(bottom) fields have lower quality than the bottom(top) fields).
You have 100% of bob frames, and going to eliminate 50% of those. SelectEven will nuke the one half. SelectOdd will nuke the other half. That's all.


It's not necessary when the field order of the input material is correctly flagged, and reported by the source filter (e.g.: Mpeg-2 via DGDecode/mpeg2source).
It is necessary when the source material is not flagged, falsely flagged, and/or the source filter doesn't report the field order. (e.g.: AviSource).

Thanks Didée :helpful:
another question: Is there any other means for keeping the same rate deinterlacing execpt for SelectEven() and SelectOdd().
Personally I would like try to adjust function in TempGaussMC and take the -1 instead of -2 for field option(like the sentence below) and whether is right or not?

# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="nnedi3") ? clp.nnedi3(field=-1,nsize=nsize,nns=nns,qual=qual)

:thanks:

[Didée]

No, that ain't work. TGMC internally needs to access all top/and/bottom fields (respectively, all even/and/odd bobframes). If you throw-away one half of the fields/frames already at the start, then TGMC doesn't make any sense anymore. For that, you can simply use NNEDI on its own.

[chopperman]

No, that ain't work. TGMC internally needs to access all top/and/bottom fields (respectively, all even/and/odd bobframes). If you throw-away one half of the fields/frames already at the start, then TGMC doesn't make any sense anymore. For that, you can simply use NNEDI on its own.
Thanks Didée your answer is helpful for the newbie like me:)