1080 50i to 1080 60i

[Eric69]

I've recently had a Blu Ray job which needed footage converted from 1080 50i to 1080 60i before the encode since it was to be distributed worldwide. I did the conversion in FCP with a Black Magic 1080 6Oi sequence and, to my surprise, was pretty darn happy.

I've recently started working with Avisynth was curious how a conversion like this were to be possible?

Thanks
E

[Alex_ander]

An example:
LoadPlugin("LeakKernelDeint.dll")
LoadPlugin("mvtools2.dll")
MPEG2Source("video.d2v")
LeakKernelBob(order=1)#50p
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)#59.94p
ConvertToYUY2()
DoubleWeave().SelectEvery(4,1)#59.94i, TFF here

The mvtools2 motion interpolation plugin works on progressive (bob) here; it is sometimes recommended to simply separate fields for it, but IMO that's not quite safe (for same reasons as with resizing).

[wonkey_monkey]

Are we still in the stupid situation where even some new TVs can't understand 50i? I thought we'd left that behind when we went to flat screens.

David

[TinTime]

Not just TVs. US PS3s won't play back 50i material for example.

[Lyris]

DavidHorman: yes. The (former) NTSC territories still ignore the 50hz world, whereas everything new in Europe works with both.

[wonkey_monkey]

Well, that just boggles my mind,

Anyway, Alex_ander's script is what I'd suggest - I've had some great results doing SD PAL->NTSC conversions using mvflowfps2. It seems the "2" version isn't available with MVTools2 - not sure why.

Some shots with large, fast-moving objects showed too much corruption, so I just replaced those bits with a clip using convertfps.

David

[Lyris]

I have some 60i HDV footage here that has to go out to PAL DVD, and have been investigating Avisynth-based standards conversion. This footage was shot handheld with no optical image stabilization, and it seemed to be too overwhelming for MVTools2. I've used ConvertFPS for the whole thing and the results are lot better than I was expecting - only trouble is that it obviously pays no attention to scene cut transitions and ghosts over them at times; not good for compression.

[IanB]

@Eric69,

Of course if the content is genuine 50 unique fields per second i.e sport etc, then the above MVTools approach is a way to go. Depending on the content and your usage you may be able to cheat and just ChangeFPS the 50p to 60p then reinterlace to 60i.

However if the content is 4% sped up film, then a better approach would be to recombine the frames, undo the 4% speed up to recover a standard 23.976 progressive source and then apply 3:2 pulldown.

[2Bdecided]

If you're happy with the "fake film" look, 50i>25p>24p>60i avoids motion compensation artefacts.

Mflowfps is fine, except when it isn't...!


There was an "alchemist" thread a few years ago - it might be worth re-visiting. A process which uses Mflowfps where it works, and drops back to convertfps where it doesn't, would be worth looking at again. Didee (I think) made a nice suggestion - try re-calculating motion vectors for the final footage - if it doesn't get you back to the original, the motion compensation is probably garbage and should be dropped.

There are scripts which do this, but the block-based switching I saw gave its own artefacts.

btw, be warned - doing motion compensation on HD sources is slow. So is decent deinterlacing.

Cheers,
David.

[selina5856]

60i is NTSC recording format, 50i is a the PAL recording format, they are all HD formats, maybe this is just the reason why they can be converted from one to another

[TheSkiller]

There wouldn't even be a need to convert between the two if the equipment sold in 60 Hz terretories would finally begin to be compatible with both refresh rates natively. But that would be a perfect world...


Since unlike with a SD based conversion the resolution stays the same (only the refresh rate differs) the quality of the bob-deinterlacing part isn't all that important because the converted fields will be re-interlaced and put where they originally came from (spatially, not temporally).


I would use YadifMod, either with NNEDI3 interpolation or simply Bob(0,1) (which would be very fast).


YadifMod(mode=1, edeint=NNEDI3(field=-2))

[nhope]

I was gobsmacked too when I realised that the NTSC world still wasn't going to support 50i in the age of HD. Pathetic really. I now wish I had only ever bought and used 60Hz cameras.

Here's a script that bobs 50i with QTGMC then re-uses its vectors in MFlowFps for a conversion to 60p, then reinterlaces to 60i. I posted a bunch of similar scripts on the Sony Vegas Pro forum (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=768368).

#Frameserve from Sony Vegas Pro in RGB24 format
AviSource("d:\fs.avi")
AssumeTFF()
ConvertToYUY2(interlaced=true, matrix="Rec601") #Rec601 is correct for encoding Ut Video Codec or Lagarith in Vdub

QTGMC("faster", SubPel=2) #SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2)
#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) #For very fast and quicker QTGMC presets
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)

separatefields()
SelectEvery(4,0,3)
Weave()

[wonkey_monkey]

Since unlike with a SD based conversion the resolution stays the same (only the refresh rate differs) the quality of the bob-deinterlacing part isn't all that important because the converted fields will be re-interlaced and put where they originally came from (spatially, not temporally).

What do you mean by "converted fields"? If you're interpolating motion to get from 50i to 60i, you still want a decently bobbed intermediate, don't you? I don't see how the fact that you're not changing resolution makes a difference to the choice of bob.

For instance, if you use plain bob, you could (in a contrived situation) end up with a (temporally) interpolated output frame in which an object was drawn solely with spatially interpolated lines.

In fact I'd argue that the SD case going from 576i50 to 480i60 is the one where you could consider using a cheaper bobber, since you're going to be throwing away ~20% of your hard-won resolution anyway.

David

[Blue_MiSfit]

If you're working in Final Cut professionally, do yourself a favor and get one of these bad boys:

http://www.blackmagicdesign.com/products/teranex

They used to cost way too much money, and are now incredibly inexpensive. Realtime, high quality HD-SDI standards conversion for under $2k. Not bad!

[kolak]

Teranex is useless for fps conversion- it uses blended conversion. You rather need Alchemist, which cost a fortune :)

[TheSkiller]

What do you mean by "converted fields"? If you're interpolating motion to get from 50i to 60i, you still want a decently bobbed intermediate, don't you?
What I mean is you just need to create a decent progressive intermediate (decent is exactly right word, not "(almost) perfect") for the motion interpolation to chew on.

Because after that you're throwing half (yes, half) of the information away by re-interlacing it. And before the motion interpolation exactly half of that bob-deinterlaced progressive intermediate was already interpolated by the bobber anyway.

So my point is: something as elaborate as for example QTGMC for bobbing wouldn't pay off here (I mean it wouldn't hurt, it's your CPU cycles). Many if not most of the original fields from your 50i/25 source will be put more or less unaltered into your 60i/29.97 video. If you were to resize vertically somewhere in the process this would not be the case and original fields and interpolated ones would get mixed spatially (they are mixed temporally to some degree due to the frame rate change as well). That's why a better bobber pays off more if there's a frame size change, probably not so much for 576i to 480i though.
The temporal mixing however is not very obvious since it is only there as long as things move. A spatial mix of original and rather humbly interpolated fields would be more objective because it is there all the time.

[kolak]

Very true- I use yadifmode with NNEDI3 and it's good enough.

[wonkey_monkey]

Because after that you're throwing half (yes, half) of the information away by re-interlacing it.

Yes, but which half? After a plain bob, half of your pixels are interpolated (and because it's a plain bob, they're badly interpolated). After motion compensation, 50% of your data will still be interpolated (albeit motion compensated and blended with motion compensated pixels from another bobbed field). If you're extremely lucky, and all of the objects in your scene happen to move at just the right speed and in the right direction, you could end up keeping all of the good data and chucking away all of the interpolated data. But, on average, after re-interlacing you're going to end up keeping 50% of the interpolated information and 50% of the real information.

David

[nhope]

QTGMC in "faster" mode can be pretty fast, especially if you get multi-threading going.

TDeint would be a faster bobber. Not quite as fast as yadifmod but I slightly prefer the results:

tdeint(mode=1)

You can improve it by doing the interpolation with nnedi3:

interp = nnedi3()
tdeint(mode=1,edeint=interp)

...but then it's probably approaching QTMGC "faster" speed and you have to generate the vectors for MFlowFps because you can't reuse those from QTGMC.

[TheSkiller]

Yes, but which half?
Unless you change the field order in the process (on purpose or accidentally) the interpolated lines will be discarded – the lines that were interpolated by your bob-deinterlacer. As a side note, a bob-deinterlacer like Yadif(Mod) and TDeint keeps the original fields untouched, QTGMC doesn't unless you use "lossless" mode.

After motion compensation, 50% of your data will still be interpolated
Correct, and now we're throwing away 50% of the data by re-interlacing via selecting those lines where all the original lines would be.
Like I've said, due to the motion compensated frame rate change our original fields (which are frames at that point) will still get mixed temporally with interpolated ones to some degree when things move. But if nothing moves there simply would be no improvement from a more elaborate bobber whatsoever.


Maybe this helps you understand

AssumeTFF()
Bob(0,1) #copies originals fields, interpolates the missing ones

AssumeTFF()
SeparateFields().SelectEvery(4,0,3).Weave()

This would be a NOP (well, not exactly for the chroma in case of YV12, but let's just ignore this). Exactly those lines that were interpolated are thrown away again leaving us with all the original data as if nothing happened.

[Didée]

@TheSkiller

o=original, x=interpolated

two subsequent bobbed frames of the source:
o x
x o
o x
x o

motion interpolated framerate conversion creates some middle frame between the two:

o <> [ox] <> x
x <> [xo] <> o
o <> [ox] <> x
x <> [xo] <> o

It are the freshly created [ox] and [xo] elements from which you throw away one half of the scanlines during re-interlacing. Hence you're not throwing away "only interpolated data". First, a mix between original and interpolated data is created. After that mix has been finished, only then you're throwing away one half of that already-mixed data.


David is fully correct from the technical side of view. There's no arguing against that.
But yeah, on the other hand, it is true that by reinterlacing a good bit of the "benefit" is thrown away again ... but not because you throw away only the interpolated data (this is just not true!), but because of the mere fact you're creating interlacing again.

In this context here, the most important point is that the bobber produces a result without bob shimmer. If bob shimmer is present, then it will be transposed into the output, and worse, it will be transposed from a very fast (ie: fieldwise) ding-dong-ding-dong shimmer, into a "slow crawling" version of diiiiing-doooong-diiiing-doooong - shimmer.

Important for interlaced framerate conversion is that the bobber does not produce bob shimmer. Additional detail or sharpness gives little bonus points, but is much less important in case of framerate conversion. Temporal stability is the main point.

[2Bdecided]

Even without fancy motion interpolation, some of the lines that are missing from the 50i original (and hence are invented by bob) are going to fall exactly where some of the real lines are in the 60i output (exactly spatially and almost exactly temporally). To put it another way, temporally, some even fields of the input will line up with some odd fields of the output.

And, as Didée says, you'll get a horrible slow-ish "beating" effect between real and invented lines used as a source for the output, which will be very visible if those invented lines are obviously sub-standard (i.e. crudely interpolated).

I agree with Didée again that it matters less if the output is interlaced, but matters more if the output is subsequently deinterlaced half-well. No decent modern TVs use a dumb bob.

Cheers,
David.