Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st May 2013, 01:15   #1  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,012
Any tips for better 30p to 60i conversion?

My wife purchased a DVD of her fashion show. Here is a very short clip, unchanged from the original:

30p clip

The clip has many problems, such as extensive noise due to low light, bad camera, bad camera settings. The audio is also trashed. Some of the problems may also have been caused by iMovie.

I can take care of most of those things.

However, because of the 30p cadence, the video lacks the fluidity of 60i material. I would therefore like to perform a 30p to 60i conversion. The following script does a reasonable job, but I wondered if anyone could suggest ways to improve this basic process? Thanks.

Code:
# Convert 30p progressive camera movies to 60i
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll") 

blocksize=16

source=AVISource("E:\fs.avi")

superfps= MSuper(source,pel=2)
backward_vec2 = MAnalyse(superfps, isb = true,blksize=blocksize)
forward_vec2  = MAnalyse(superfps, isb = false,blksize=blocksize)
MFlowFps(source,superfps, backward_vec2, forward_vec2, num=60000, den=1001, ml=200)
SeparateFields()
SelectEvery(4,0,3)
output=Weave()

stackhorizontal(source.separatefields(),output.separatefields())
#return output
johnmeyer is offline   Reply With Quote
Old 21st May 2013, 10:58   #2  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Things you could experiment with:
* Using smaller block size
* Calculating motion vectors on prefiltered (denoised) input clip
* Using current larger block size to detect large motion, then refining estimates for smaller motion using MRecalculate() and smaller block size
* PS. Turn on overlap ~ blocksize/2

Out of interest, how did you arrive at the relatively high 'ml' value? From the (limited) testing I've done, I don't see much difference from around 1 and up.

I'm probably missing something, but from the looks of it your output is 29.97 fps interlaced; is that what you wanted?

Cheers,
Francois

Last edited by fvisagie; 21st May 2013 at 10:59. Reason: PS
fvisagie is offline   Reply With Quote
Old 21st May 2013, 12:59   #3  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Quote:
Originally Posted by fvisagie View Post
Out of interest, how did you arrive at the relatively high 'ml' value? From the (limited) testing I've done, I don't see much difference from around 1 and up.
Sorry, disregard that question. My comment applies to MMask(); I see with MFlowFPS() output changes more linearly with ml=[0,255].
fvisagie is offline   Reply With Quote
Old 21st May 2013, 13:57   #4  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
I would increase it by a factor of exactly 2 - at least that way you keep every original frame - rather than having almost exclusively interpolated frames in the output.

Then convert 60p to 59.97p by an assumefps() and associated audio resample to maintain sync. No one will notice.


Honestly though, I'd almost be tempted to leave it as 30p (assumefps() to 29.97 if needed). Normal people will think 30p looks kind of upscale/filmic, and video pro that you are, you'll be irritated the motion-compensation artefacts in the 60p/60i version. Depending on how well it works, even normal people might notice some of the weirdness in brief moments. From the brief sample, it looks like the shutter speed was appropriate for 30p to avoid stutter, and might look overly blurry at 60i. I could be wrong.

I have changed 25p home movies to 50i to avoid a jarring change when editing it with other native 50i footage - but for a project that only used the 25p footage, I'd leave it as it is. People soon get used to it.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 21st May 2013, 14:02   #5  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: Waterloo, WI - USA
Posts: 650
Wow... That was produced in 2013? Glad to see they went all out on the video budget..

As for the motion - it looks natural to me? I'd echo what has been said. Clean it up and leave it as is. Most folks will probably notice the low quality issues more than the framerate/motion.
osgZach is offline   Reply With Quote
Old 21st May 2013, 17:15   #6  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,012
I looked at my restored result: I was able to make a huge difference in the grotesquely clipped audio by using the "Declip" module in iZotope RX2; I used Vegas to color correct the flourescent lighting; I used MDegrain2 to reduce the noise, using blocksize=8 and overlap=4.

All those things made significant, positive changes, with very little downside. I tried to get a little more detail by using sharpening, but I had to use pretty small values in order to avoid introducing halos.

Quote:
That was produced in 2013? Glad to see they went all out on the video budget..
No kidding ...

I do not like the results of going from 29.97 progressive to 29.97 interlaced because there are just too many places where the motion estimation fails slightly, especially when the models move their hands quickly. Therefore, I'm taking the advice given here and just leaving it as 29.97 progressive.

Quote:
I would increase it by a factor of exactly 2 - at least that way you keep every original frame - rather than having almost exclusively interpolated frames in the output.
I thought that was what I was doing. The num=60000, den=1001 in MFlowFPS was designed to exactly double the original's num=30000, den=1001 progressive frame rate. I then separate into fields, take only the first and fourth field in every group of four, and weave back together in order to give me 29.97 fps interlaced. I guess that if the MFlowFPS isn't perfect, it might distort the frames that shouldn't be estimated (every other frame should be in the same temporal position as the original). I could add a few lines and separate the fields on the source and then interleave those into the temporally shifted fields resulting from the MFLowFPS operation. However, in looking at each original field, and the estimated fields (see the stackhorizontal statement in my script), the odd fields look the same as the original; it is only the even ones that have the occasional motion estimation artifacts. It was those artifacts I was hoping to reduce, but I think that using large block size and playing around with the overlap are the only two things I can do.

BTW, in my experience, larger block sizes generally produce fewer artifacts when doing frame rate conversions using this technology, but I'm open to suggestions on specific settings because perhaps I haven't discovered the right combinations.

Last edited by johnmeyer; 21st May 2013 at 17:16. Reason: Added additional quote
johnmeyer is offline   Reply With Quote
Old 23rd May 2013, 12:12   #7  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by johnmeyer View Post
I thought that was what I was doing.
Sorry, yes, you're right. My 30p camera is (or reports) exactly 30p. Yours is (or reports) 30/1.001, so you're fine.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 24th May 2013, 17:47   #8  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Quote:
Originally Posted by johnmeyer View Post
BTW, in my experience, larger block sizes generally produce fewer artifacts when doing frame rate conversions using this technology
Having just started my first framerate conversion project, I have to agree with you on that one. I made the comparisons and the best results (for this footage) was with straight-forward MSuper() and MAnalyze() calls with all settings at default values except hpad, vpad and blksize all set to 16:
Code:
super = MSuper(hpad=16, vpad=16)
backward_vec = MAnalyse(super, blksize=16, isb = true)
forward_vec = MAnalyse(super, blksize=16, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100)
(50fps output in my case)

No denoised prefiltered clip, nothing fancy helped. Even overlap caused a deterioration in artifacts. I find all this quite surprising, because MDegrain benefits from things like MRecalculate() with smaller block size, overlap etc.

For what it's worth I also evaluated InterFrame() and MSU_FRC(). MSU_FRC() produced the best artificial motion of the lot, but also the worst artifacts which can't be tuned down towards some compromise. It also crashes AvsPmod and seems to require linear frame-serving which complicates testing. In the end I settled for MVTools .

Cheers,
Francois
fvisagie is offline   Reply With Quote
Old 24th May 2013, 18:21   #9  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,012
Quote:
Originally Posted by fvisagie View Post
Having just started my first framerate conversion project, I have to agree with you on that one ... No denoised prefiltered clip, nothing fancy helped. Even overlap caused a deterioration in artifacts. I find all this quite surprising, because MDegrain benefits from things like MRecalculate() with smaller block size, overlap etc.

Francois
Thank you for that. Your testing confirms exactly what I have seen the last few years, every time I try to improve the quality of these frame rate conversions.

And, just to make sure this isn't taken as a criticism of MVTools2, I have tried the trial version of Twixtor, and it fails in exactly the same way, in the same portions of the video. So, it appears that the problem is inherent to the approach, rather then the implementation. My solution, when I have the time, and when I'm being paid, is to create a second slow motion clip using frame/field blending. This is guaranteed to produce no artifacts. Then, I line up the MVTools2 version and the frame-blended version on the timeline in my editing program (Vegas) and whenever I see an artifact, I draw a quick garbage mask (i.e., the outline of the mask can be rough) that lets the frame-blended version cover up the artifacts on that portion of the frame in the MVTools2 version where they occur.

It's a lot of work, but it produces artifact-free results.

Last edited by johnmeyer; 24th May 2013 at 18:22. Reason: Edited the last sentence for clarity
johnmeyer is offline   Reply With Quote
Old 25th May 2013, 10:14   #10  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
I just happen to have gotten Vegas recently, so will definitely keep that manual clean-up in mind, thanks.
fvisagie is offline   Reply With Quote
Old 30th May 2013, 12:38   #11  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by johnmeyer View Post
And, just to make sure this isn't taken as a criticism of MVTools2, I have tried the trial version of Twixtor, and it fails in exactly the same way, in the same portions of the video. So, it appears that the problem is inherent to the approach, rather then the implementation. My solution, when I have the time, and when I'm being paid, is to create a second slow motion clip using frame/field blending. This is guaranteed to produce no artifacts. Then, I line up the MVTools2 version and the frame-blended version on the timeline in my editing program (Vegas) and whenever I see an artifact, I draw a quick garbage mask (i.e., the outline of the mask can be rough) that lets the frame-blended version cover up the artifacts on that portion of the frame in the MVTools2 version where they occur.
I'm sure I read a proposal (probably in the old Alchemist thread) to post-process MVTools to do basically the same thing - where ever the motion compensation has gone mad, replace with a blend. I think I even saw a script that did this, but when I tried it the ?block-based? replacement it used looked even worse than the artefacts. (I could have dreamt this though - I'm sure I've had framerate conversion nightmares! )

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 31st May 2013, 07:18   #12  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Quote:
Originally Posted by 2Bdecided View Post
when I tried it the ?block-based? replacement it used looked even worse than the artefacts.
When talking about block-based approach, are you referring to this from the MVTools 2 documentation (MMask is supposed to pick up bad blocks from occlusion, tearing etc.)?
Quote:
To blur problem (blocky) areas of compensated frame with occlusion mask:

Code:
AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
super = MSuper()
vectors = MAnalyse(super, isb = false)
compensation = MCompensate(super,vectors) # or use MFlow function here
# prepare blurred frame with some strong blur or deblock function:
blurred = compensation.DeBlock(quant=51) # Use DeBlock function here
badmask = MMask(vectors, kind = 2, ml=50)
overlay(compensation,blurred,mask=badmask) # or use faster MaskedMerge function of MaskTools
I haven't had good results with this.

If it's something else you mean, kindly explain?
fvisagie is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.