Properly convert true 50p to 50i

[Buddy Casino]

Hi!
I'd like to convert a video with true 50fps progressive frames to 50 interlaced fields.
SeparateFields() does not do what I want, since it assumes a video of half the frame rate containing previously merged fields. This is not the case here, because the video was rendered by a program in true 50p.
It is very important to keep the video as much fluid as possible, so I don't want to discard half of the frames, but rather half the vertical resolutionof the existing frames and somehow use them as the fields for my 50i.
Is this possible?

Thanks for every help!

[Guest]

separatefields()
selecteven()
weave()

[MfA]

Shouldn't that be :

AssumeFrameBased
SeparateFields
SelectEvery(4, 0, 3)
Weave

?

[Guest]

I assumed he's already frame based, but it doesn't hurt to add it.

SelectEven() is the same as SelectEvery(4, 0, 3), it seems to me.

And you should always retain the ()'s to ensure proper Avisynth caching.

[Alain2]

SelectEven() is the same as SelectEvery(4, 0, 3), it seems to me.

I think 4,0,3 selects the even field of frame 1 and the odd field of frame 2 (or vice-versa), and weaving these will keep resolution in static parts, and avoid jitter

[MfA]

SelectEven selects 0, 2, 4, 6, etc.
SelectEvery(4, 0, 3) selects 0, 3, 4, 7 etc.

[scharfis_brain]

in fact is has to be:

AssumeFrameBased()
AssumeTFF() #-> set desired output fieldorder
converttoyuy2() # convert to desired output colourspace (as the choosen encoder needs)
SeparateFields().SelectEvery(4, 0, 3).Weave() #re-interlace


using selecteven() instead of selectevery(4,0,3) will result in halved vertical resolution due to wrong vertical alignment.

[Guest]

Yeah, I stand corrected.

I was assuming SelectEvery(4,0,2) was written and didn't look closely at it, and of course that is the same as SelectEven().

Either way, scharfi and Mfa are correct about the shift.

[MfA]

AssumeTFF() #-> set desired output fieldorderDoesn't really matter much, whichever is set things work out alright because of the weave.

[Buddy Casino]

First of all: thank you very much for your help!

Ok, now it looks like i'm getting interlaced content, I can see the comb artefacts. What puzzles me is that the resulting file (DV) displays as 25fps in the MediaPlayerClassic properties (and also in VirtualDubMod under "video" -> "framerate"). Is that normal? I know its frames per second, not fields per second, but shouldn't it instead say "50fps" or "25fps interlaced" or something like that?
Excuse my ignorance, but i'm just getting started...

[vhelp]

Hello everyone :scared:

Yeah, I was waiting all day to see how long it would take for someone to catch
this oversight.

Buddy Casino, you would need to add one more sub group to the param, [2,5] ..

selectEvery(4, 0,3, 2,5)

will (should) report 50 fps.

fwiw, I think someone wanted to do the reverse of what you want, over at videohelp,
here: dvd ntsc=> pal conversion & adding subtitles best way?expert opinion (http://forum.videohelp.com/viewtopic.php?p=1537072#1537072)

-vhelp

[MfA]

No that will generate 100 fields per second, just like the original.

What Im assuming is happening is that the codec doesn't know it's getting interlaced content, it just codes them as progressive frames.

[Buddy Casino]

If the codec is the problem, why does VirtualDubMod also report 25fps under "video" -> "framerate" when loading the above script?
(Btw.: I'm using the old MainConcept 2.4.4 DV codec, which is still VfW based)

[vhelp]

MfA, don't take this the wrong way. I'm not sure I follow you.

If I may explain myself..
I'm not an expert in the selectEvery() function, thought it's quite a
powerful filter, imho. And, I do love working with it, though my sources
are NTSC based, and not PAL. The numbers above were used on a NTSC source
who fps were 29.970 fps.

When I read this article this moring, I did a little what-if playing around.
Then, I got the idea that I could be wrong, but only beause I dont' have a PAL
source. So, I found some PAL demo clips (snipped from this forum, at various
areas - thanks everyone) and used those PAL videos as a reference to all my
selectEvery() scenarios.

FWIW, below I post the relative param values, that gave me the final FPS
for each run inside selectEvery() function:

# NTSC: @ 4
# 14.985=(0,3)
# 29.970=(0,3, 2,5)
# 44.955=(0,3, 2,5, 4,7)
# 59.940=(0,3, 2,5, 4,7, 6,9)

# PAL: @ 4
# 12.500=(0,3)
# 25.000=(0,3, 2,5)
# 37.500=(0,3, 2,5, 4,7)
# 50.000=(0,3, 2,5, 4,7, 6,9)

where

@ 4, is the first param entry for the "group of pictures" to include in the
final process.

Someone posted, selectEvery(4, 0,2) and gave an explanation why. In the end,
I found either one works well. But, the results will (would) be dependant on
the given source being used with. We all know how the tons of video out there
can be unpredictable, even when we *feel* otherwise.

Last, I sure would love to D/L a small piece of this member's video.. just to
get an idea of what this 50p (PAL) source is like with selectEvery() function.

Thank you.

-vhelp

[MfA]

Buddy, after weaving you do get a 25 frame per second stream ... the codec has to be told in some way that the source is interlaced, and that each frame is actually 2 fields.

[actionman133]

@Buddy Casino

There is no 'interlaced' flag under the AVI format (that I'm aware of), so AVISynth can't tell VDub or any other program whether it's progressive or interlaced. The only way an output application could tell is if it analyzed the frames, which can be unreliable.

As such, if you are playing 25 interlaced frames per second, it will simply tell VDub that it is playing 25 frames per second and VDub will just assume it's progressive. If you want the video to be compressed as an interlaced source, you'll have to set the option manually in your video compressor's configuration...

Hope that explains it a little for you... : )

[Buddy Casino]

I see...
Nothing to configure here:

http://boeckling.net/dv.png

Is there a DV codec I can use that would support this behaviour?
I don't have to necessarily use VirtualDub, if that is the problem...

[MfA]

Try this :

AssumeFrameBased()
AssumeBFF()
SeparateFields().SelectEvery(4, 0, 3)

Without the weave it gets a 50 fps stream, with a bit of luck it automatically assumes that kind of rate means it's interlaced.

[Alain2]

Hum interlaced clips frames are made of fields taken at with a difference in time of half the fps; so in your case, as you have only 50fps for each field taken both at exactely the same time, then you can only make 25fps interlaced ; or you can interpolate 1 intermediate frame between 2 of the original 50p source (with the mvtools or depan), which will give you 100p fps, so each field will be at 100fps, and using the methode above will give you back 50i frames...

[Buddy Casino]

...which would be 100 fields per second, right?
I only want to convert a 50fps progressive source to a 50 fields per second DV avi. This seems to be harder than expected! :-)

[actionman133]

@Buddy Casino

Although I don't know for sure, I wouldn't be surprised if the MainConcept DV codec assumes its input is interlaced, since that is its intended purpose (interlaced video).

I think the solution you want is what Mfa and scharfis_brain first suggested... perhaps explaining what each step does will help you understand what it's doing and why...

AssumeFrameBased ()
ConvertToYUY2 () # scharfis_brain suggests this due to possible chroma error
SeparateFields () # 50 frames becomes 100 fields
SelectEvery (4, 0, 3) # 100 fields to 50 fields (selects 2 from 4)
Weave () # 50 fields to 25 interlaced frames

This will convert 50 frames to 50 fields, then weave the fields together to get 25 interlaced frames.

If you want to save in MainConcept's codec, it should be fine. It's designed to handle interlaced video. It should save the fields properly (and if it doesn't, it's not AVISynth's fault, or VirtualDub's... the fault is the codec itself).

In fact, do a test render on a 10-20 second section of your clip with the codec and see if it plays back the way you want it to. Just pick an area with a reasonable amount of motion so you can see if it is playing back smoothly...

PS. Buddy Casino, it really is actually quite simple... I think you're just thinking that there is more to it (when really there isn't). ;)

[Alain2]

...which would be 100 fields per second, right?
I only want to convert a 50fps progressive source to a 50 fields per second DV avi. This seems to be harder than expected! :-)
Ah indeed, sorry I misunderstood you wanted 50 fields per seconds, I thought you wanted 50i (which is 50 frames per seconds, interlaced, not 50 fields)
Then actionman133 is probably right, I don't know anything about DV codec myself :) Good luck

[scharfis_brain]

AssumeTFF() #-> set desired output fieldorderDoesn't really matter much, whichever is set things work out alright because of the weave.

Assume?FF() IS necessary because it WILL change the fieldorder-flag and the order how the fields physically are merged into the final output.

so, these both scripts are the same (puts out TFF-flagged and also true TFF-video):


AssumeFrameBased()
AssumeBFF()
SeparateFields()
SelectEvery(4,0,3)
Weave() # video is BFF
DoubleWeave().SelectOdd() #video is TFF



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

I hope this made things clearer, because the fieldorder flag of AVS will decide how SeparateFields() treats the video.

[MfA]

Ugh, sorry for the contradiction.

I had never even considered that interlaced coding was this retarded ... I thought weaved frames always had lines in the correct position.

As if coding fields as interlaced frames wasn't retarded enough (compression is almost always worse this way). No, they also had to swap the even/odd lines just to destroy even more of the spatial coherence so that even if there wasn't much movement the coding would be as bad as possible? Who were these idiots? BFF interlaced frames are insane.

[scharfis_brain]

weaved frames ALWAYS have the lines in the correct position.

but he fieldorder describes which set of lines is sent to the output device first:
TFF -> even scanlines(0,2,4...) / top field goes out first
BFF -> odd scanlines(1,3,5...) / bottom field goes out first

it really doesn't matter which one you choose as long as you stick with one to avoid confusion.
But at least TFF is the one to prefer, even if BFF was choosen by these DV-idiots, cause TFF is quasi standard for capture cards, DVD and Television.
Editing in BFF and converting to TFF will introduce some really bad scenechanges.

[Buddy Casino]

PS. Buddy Casino, it really is actually quite simple... I think you're just thinking that there is more to it (when really there isn't).

Seems you're right. :-)
I used to think that interlaced video stores its content as half-resolution frames with a framerate of 50fps, but that obviously was nonsense...

Thanks to the help of all of you, I managed to render a good interlaced version of my video. I also used MVTools to smooth the motion and some chroma hacks to avoid some really strange artifacts that had to do with my crappy WMV source.
All of this thanks to you all, you're great!!

[smok3]

so this should be fine for BFF;

AssumeFrameBased()
AssumeBFF() #-> set desired output fieldorder
resize(1280,576)
converttoyuy2() # convert to desired output colourspace (as the choosen encoder needs)
SeparateFields().SelectEvery(4, 0, 3).Weave() #re-interlace
resize(720,576)
?

(iam going from 720p50 to PAL 50i anamorf)

edit: this may pass on CRT TV, it does look a bit on the sharp side thought (what i figured is that i will not be able to edit this without the real-time down-converted 50i preview, since it is really hard to predict when graphical borders will thin/jumper on 50i that is)

edit2: quite a lot of aliasing on lcd computer screen (VLC with bob deinterlacing).

[2Bdecided]

There are lots of HD>SD threads already, and quite a discussion about the trade-off between sharpness and inter-line-twitter.

Excellent thread here:
http://forum.doom9.org/showthread.php?t=139102
...gets interesting about page 3-4.


I think you must do some filtering before re-interlacing.

e.g. I use this (trivial, fast, looks fine to me!)

assumeframebased()

converttoyuy2() # convert to desired output colourspace (as the choosen encoder needs)

spline36resize(704,576)

blur(0.0,1.0)
sharpen(0.0,0.5)

assumebff().separatefields().selectevery(4, 0, 3).weave() #interlace


Cheers,
David.

[smok3]

yes i saw that thread, what i wondered is: wouldn't bluring/shifting/whatever need to be motion based? (less motion = more blurring), could one abuse some deinterlacer for that (some sort of 'inverse yadif' maybe, speed needed)?

p.s. because if you have a lot of motion then fields don't have to align properly and sharpness may be good attraction?

or i'am completely way off here?

-----

p.s.2. another problem would be how to handle 25p parts, that seems to be common in 50p edits, some sort of motion denoising would have to be applied on those i imagine...

[Manao]

wouldn't bluring/shifting/whatever need to be motion based?No, there's the same amount of motion per field in 50i than per frame in 50p.

Apart from that, instead of downsize/blur/sharp, i'd downsize to a smaller resolution, then upsize. It's faster, and you won't get the sharpening artifacts.

[Didée]

Well, it's a point of ambivalence. Lowpass filtering before interlacing surely helps a lot to dimish the interlacing twitter and to give an overall homogeneous output. But then, the credo of interlacing is "full temporal resolution when there's motion, full spatial resolution when there's no motion". But with lowpass pre-filtering, this is of course not true anymore: spatial resolution is reduced also when there's no motion.

So, smok3's question is quite reasonable. In parts that do not move, there's no need to apply the lowpass filter.

... and it's easy to try it:

input = whatever
lowpass = input.YourLowpassFilter()
lowpass_on_motion = Soothe( input, lowpass, keep=0 )

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

Et voila: lowpass filter on moving parts, no lowpass on static parts - q.e.d.

[smok3]

Didée, actually i meant the opposite, because with:

a. no motion (there is large chance that this is some sort of CG stuff, which will by its nature introduce flickering, one-line borders and similar) - strongest lowpass
b. low motion (this will look bad on LCD monitors - looks like aliasing) - medium lowpass
c. high-motion should look good without any filtering imho, or maybe with small amount, so that the stuff does look compatible with a. and b.

[Didée]

Well okay, I was assuming clean input. (Though I don't necessarily see why CG has to flicker "by it's nature". When rendered properly, the render will be correctly antialiased, or not?)

For the general idea of where lowpass filtering is indicated and where not, I stand with my post above.

However, if you're dealing with artificial stuff from the start, then you've to do whatever the artifacts require. ;)

[Manao]

The only time you can avoid not lowpassing is when it's perfectly still. But as soon as there's a tiniest bit of motion, you must lowpass, lest aliasing kills you.

[smok3]

with CG i meant titles (fonts) and stuff like that - which will/may appear perfectly nicely antialiased at HD 50p.

(will have to find some time for testing, maybe my 'theory' is limited to this specific project only...)

[2Bdecided]

The only time you can avoid not lowpassing is when it's perfectly still. But as soon as there's a tiniest bit of motion, you must lowpass, lest aliasing kills you.That only makes sense if you're watching on a TV with a motion adaptive deinterlacer (i.e. it weaves perfectly still fields).

It's a recipe for disaster on a CRT, where your perfectly still frame will cause horrible interline twitter and large area flicker without filtering - and it's quite bad on a cheap LCD with a simple dumb bob (plenty of portable TVs do this), where you'll get lots of bobbing.

Adaptive filter based on motion makes a nice AVIsynth script to post on doom9, but is actually useless for a general filtering approach before re-interlacing.

Cheers,
David.

[2Bdecided]

Apart from that, instead of downsize/blur/sharp, i'd downsize to a smaller resolution, then upsize. It's faster, and you won't get the sharpening artifacts.Well, if you use a "sharp" resizer you'll get basically the same "sharpening artifacts" but an otherwise slightly poorer result (because you've definitively thrown the resolution away, rather than just bluring it), and if you use a blurred resizer, it'll look very blurred (IMO).

FWIW I think the (very moderate) sharpening "artefacts" in my example help in the intended use. The options without these artefacts actually twitter far more, or look really blurred.

Again, IMO, YMMV - but I've tested this a lot now.

Cheers,
David.

[IanB]

I believe its a little more tricky than just lowpass filtering motion areas.

Things that may cause twitter are things that are present in 1 field only.

Consider a stationary 1 pixel high line. It will twitter at 25Hz (or 30Hz) like crazy.

Consider a 1 pixel high line moving down the screen at 1 line per field rate. It will not twitter at all, it will appear to be smoothly moving down the screen.

For stationary things not to twitter, they need to appear equally in both fields, or be in motion so the eye interprets any flicker as motion.

[scharfis_brain]

For stationary things not to twitter, they need to appear equally in both fields, or be in motion so the eye interprets any flicker as motion.
for stationary things this issue has already been solved: the tv-set's internal motion adaptive deinterlacer.

for moving things though these deinterlacers will exhibit the flicker again.
and for the very rare case that 1 line details is visible in every field (1, 3 , or (2n+1) motion) the resolution of this area drops to excactly the half.

[2Bdecided]

for stationary things this issue has already been solved: the tv-set's internal motion adaptive deinterlacer.But no-one encodes content for widespread use based on this assumption, surely?


I'm buying a house at the moment, so I've been in the houses of a lot of strangers recently. Despite what every lifestyle magazine and shop try to tell you, there are a lot of CRTs still in use out there. No "internal motion adaptive deinterlacer" is going to hide the flicker/twitter on these!

Cheers,
David.

[smok3]

I believe its a little more tricky than just lowpass filtering motion areas.

Things that may cause twitter are things that are present in 1 field only.

Consider a stationary 1 pixel high line. It will twitter at 25Hz (or 30Hz) like crazy.

Consider a 1 pixel high line moving down the screen at 1 line per field rate. It will not twitter at all, it will appear to be smoothly moving down the screen.

For stationary things not to twitter, they need to appear equally in both fields, or be in motion so the eye interprets any flicker as motion.
thats what i was trying to say + small amount of motion which is an intermediate problem - bad aliasing on LCDs.