Another PAL2NTSC Q: Alternate idea for 25i content.

[DoctorM]

I'm preparing to do a conversion of 25i material to NTSC and had my script all ready to go:

mpeg2source("video.d2v",cpu=4,iPP=true)
loadCPlugin("yadif.dll")
yadif(mode=1) # bob mode
Spline36Resize(720,480)
ChangeFPS(59.94) # I am moral opposed to blended fields
SeparateFields()
SelectEvery(4,1,2)
Weave()
converttoyuy2(interlaced=true)

Thinking about it, this was starting to bug me.
While I understand the need to do it this way, but by bobbing in the first step you are halving the resolution.
So not only am I taking the hit going from 576 lines to 480, I'm really going to 288 upscaled to 480.

What I'm wondering now is if there is something wrong with doing this:
mpeg2source("video.d2v",cpu=4,iPP=true)
SeparateFields()
Spline36Resize(720,240)
Weave()
converttoyuy2(interlaced=true)

And then using DGPulldown or similar to add 25 to 29.97 flags?

Sure I'm adding pulldown to interlaced material, but the hit to the detail should be seriously reduced.
Wouldn't a hardware player end up doing pretty much the same thing we already are with the original script? Heck, wouldn't progressive scan cause it to play at 25i?

Basically is this a good idea or a recipe for a juddery mess?

[Alex_ander]

The second method is (almost) absolutely wrong (using DGPulldown there is also impossible).
The first one is about correct (unlike the simple internal bob, yadif takes care of preserving resolution). The missing thing there is field order control. Yadif by default will take source field order from DGIndex project file and bring it to its own output. So to have predictable (independent of source) field order by the end, use AssumeTFF/BFF line before Separate Fields. In your script the numbers used in SelectEvery invert the assumed field order by the end of the script, so it's better (for one's memory) to use non-inverting numbers SelectEvery(4,0,3). Then the output field order will coincide with the assumed, e.g.:

AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()# TFF

Or there's a shorter (inverting) equivalent:

AssumeBFF()
DoubleWeave()
SelectEvery(4,1)#TFF

Alternative to ChangeFPS option is frame interpolation to 59.94 with MFlowFPS of MVTools2 plugin:

super = MSuper(pel=2)
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=60000, den=1001, ml=100)

[DoctorM]

Wow, I understood your first sentence anyway... so I'll comment on that: Why is using pulldown "impossible".

My field order is TFF so SelectEvery(4,1,2) should be correct not (4,0,3).
How is (4,1) short for (4,0,3) or even (4,1,2)?

As far as MFlowFPS... what?

[Alex_ander]

Why is using pulldown "impossible".

Just because you intended to apply DGPulldown utility to interlaced video (after the second script, ending with weave). Of course you can use it if you simply deinterlace/resize the video and encode it as progressive stream.
My field order is TFF so SelectEvery(4,1,2) should be correct not (4,0,3).
Only if you plan to encode one particular video with BFF after script (SelectEvery(4,1,2) inverts default field order, TFF as you say).

Also next time you use the script you'll have to modify it for field order of the new video. My suggestion was making a script working independently of source field order.
How is (4,1) short for (4,0,3) or even (4,1,2)?
I meant 2 operations in script (with DoubleWeave.SelectEvery) are less than 3 (SeparateFields.SelectEvery().Weave), AssumeTFF is 'zero' action. DoubleWeave directly creates interlaced frames and you can select the right ones.

[DoctorM]

I'm sure you mean to be helpful, but to be honest I can't understand what you're saying.

[DarkT]

I'm sure you mean to be helpful, but to be honest I can't understand what you're saying.

Then perhapes you need to read up more on how things work, etc...

[DoctorM]

It's not his technical info but his English that has me confused.

Btw, I did a test of the "impossible" pulldown flags.
It's very much possible. It even plays back on fussy standalone units.
The picture is razor sharp. Unfortunately the motion is jittery.... which was my question.

[cwk]

Hi DoctorM,

The doc for dgpulldown:

http://neuron2.net/dgpulldown/dgpulldown.html

stipulates the pal content be progressive before application. You will need to use yadif(mode=0), or some similar de-interlacer to get a 25fps progressive stream before running that through dgpulldown.

I would assume this is what is causing your jittery motion.

ck

[DoctorM]

"Must be" progressive and "SHOULD be" progressive are 2 different things... but yeah pulldown on interlaced video doesn't produce desirable results.
Checking still frames on a standalone player shows 4 edges in many cases!

AssumeBFF()
DoubleWeave()
SelectEvery(4,1)

Pretty interesting method, does the selectevery(4,1) need to be different depending on BFF or TFF? I can't work that out in my head.

I still don't know what "MFlowFPS" is for certain. Is that suppose to be MVFlowFPS? From what I read that filter still generates artificial frames which I'm trying to avoid. How is it any better than blurred frames?

[IanB]

@DoctorM,

Your 2nd method does not work because with pure interlaced content each fields has its own time instant.

DGpulldown works by fiddling with the RFF (Repeat Field First) flag element of the mpeg2 data stream.

So to go from 25i (50 fields per sec) to 30i (60 fields per sec) you need to generate a repeat pattern like :-T T B T B T B B T B T B <- Input fields
0 0 1 2 3 4 5 5 6 7 8 9 ...
t b t b t b t b t b t b <- Output fieldsNote the sequence in Red needs to have the opposite field sense, this is why in method 1 you need to Bob first.

If you try to use DGpulldown you will end up with this output field pattern :-0 1 0 2 3 4 5 6 5 7 8 9 ...
t b t b t b t b t b t bNote the sequence back stepping in Red

Using DGpulldown with progressive content you end up with this pattern :-
0t 0b 0t 1b 1t 2b 2t 2b 3t 3b 4t 4b ...

[DoctorM]

Good info IanB.
Is it theoretically possible to use the pulldown method, but before using it, separating the fields and reinterlacing shuffling the fields to correct for what the pulldown flags do to the field order? I suspect I already know the answer to that question.

Btw, out of curiosity I compared Yadif in mode=0 and mode=1 (without any re-interlacing) to try to decide between 25p w/pulldown or 29.97i. Except for half the frames, I found no distinguishable difference between the two outputs.

I then compared 29.97i output (using the first script in post 1) to a 25p version. Again I saw no difference in detail.
Yadif is pretty impressive.
Since both methods still take a quality hit from upscaling the fields, 25p seems like a better way to go.
It's sort of a shame I can't cook up a decent 29.97p out of the 25i source.

[Alex_ander]

... does the selectevery(4,1) need to be different depending on BFF or TFF?
You can't change output field order by changing numbers here, but you can get the desired order by assuming TFF or BFF in the first line (the output field order is opposite to the assumed). How it works. Each pair of input progressive frames in sequence P,P,P,P.... after bob represents 2 motion phases (from former fields). To restore interlacing you can combine fields from those pairs of frames (2 possible combinations). DoubleWeave (if applied to frames) doesn't modify the existing ones (it virtually combines their fields into already existing frames). But it inserts new interlaced frames between them (framerate becomes double of bob) using the last field of previous frame and the first field of next frame.
For BFF assumed order: P(BT),TB,P(BT),TB,P(BT),TB....
For TFF assumed order: P(TB),BT,P(TB),BT,P(TB),BT...
In both cases you need to select frame #1 of each 4 frames to restore interlacing. With the other choice, e.g. selecting frame 3 (the rest frames in cycle are progressive), you'll lose the first original frame but still have the same field order. So to control field order you can only set it before DoubleWeave:

AssumeBFF()
DoubleWeave()
SelectEvery(4,1)#TFF

AssumeTFF()
DoubleWeave()
SelectEvery(4,1)#BFF

[DoctorM]

Wow, this has gotten more complicated than I anticipated.
I think I pretty much followed that.
I guess my question is if DoubleWeave().SelectEvery(4,1) inverts the field order... is that good, bad, useful, or of no difference?
OR are you saying in order to prevent it from inverting the field order I should use AssumeBFF() even though my source is TFF?

[Alex_ander]

It's not good or bad, but if you want to have particular field order in the end of the script, provide the opposite order just before DoubleWeave(). The same thing as with SeparateFields.SelectEvery(4,1,2) which also inverts field order (unlike 4,0,3).

[Alex_ander]

OR are you saying in order to prevent it from inverting the field order I should use AssumeBFF() even though my source is TFF?
Yes, if you want to encode it with TFF. You can safely set field order here independently of source properties, since after yadif the video is progressive.

[manono]

While I understand the need to do it this way, but by bobbing in the first step you are halving the resolution.
So not only am I taking the hit going from 576 lines to 480, I'm really going to 288 upscaled to 480.
Why are you trying to reinvent the wheel here? Better men than you have tackled this problem with better results than the mostly nonsensical solutions you've proposed in this thread. Your whole premise is wrong. You're not halving the resolution since, if done correctly, the fields taken from the bobbed fields when being reinterlaced are the originals and not the interpolated ones. They've been resized but not interpolated. And it produces slightly better quality to do the resizing on the bobbed fields rather than on the fields themselves.

There are only 2 ways to do this conversion (not counting blending), neither of them optimal. You can use some variation of your first script and output interlaced video, or you can deinterlace, encode as progressive, and apply pulldown afterwards. Both methods have their drawbacks, but nothing like trying to apply pulldown to an interlaced stream.