Closest AVS scripts to Alchemist results

[Clown shoes]

Originally Posted by Trixter

...and after testing it for about 30 minutes, I have to say that I like MVTools' MVFlowFPS2 much better -- the decrease in speed is well worth the estimation accuracy. I'll stick with them.

What is it you prefer about MVFlowFPS2? I have been comparing high motion sections frame by frame and although I can find hardly any difference between them, I would say I've found fractionaly more motion artifacts with MVFlowFPS2. I'm curious to know what advantage there is to the MVTools route in your opinion.

@ Didee

I tried increasing ml but I didn't see any difference at all! Very strange.

[Trixter]

Originally Posted by Clown shoes

Trixter, can you see anything wrong with my implementation of mvflowfps2.

import("C:\Program Files\AviSynth 2.5\plugins\mvbob\mvbob.avs")
MPEG2Source("I:\JUMP_BRITAIN\Jump Britain.d2v")
mvbob()
loadplugin("C:\Program Files\AviSynth 2.5\plugins\mvtools.dll")
vvbw=MVAnalyse(truemotion=true,blksize=8,delta=1,pel=2,isb=true,idx=3,chroma=true,sharp=1)
vvfw=MVAnalyse(truemotion=true,blksize=8,delta=1,pel=2,isb=false,idx=3,chroma=true,sharp=1)
vvbw2=MVAnalyse(last.Crop(4,4,-4,-4,true),truemotion=true,blksize=8,delta=1,pel=2,isb=true,idx=4,chroma=true,sharp=1)
vvfw2=MVAnalyse(last.Crop(4,4,-4,-4,true),truemotion=true,blksize=8,delta=1,pel=2,isb=false,idx=4,chroma=true,sharp=1)
MVFlowFPS2(last,vvbw,vvfw,vvbw2,vvfw2,idx=3,idx2=4,num=6000,den=1001)
converttoyuy2()
lanczos4resize(width,480)
assumetff().separatefields().selectevery(4,0,3).weave()

It is giving me amazing results except for some warping on fast moving scenes. I have posted a still on the previous page. This is not something that is apparent when I use motionprotectedfps though. Is there a fundemental difference between the two that may explain this. Or is it just my use of the filter?

num should be 60000, not 6000. (as typed above, your script converts video to about 6fps; typo?) Otherwise, you're doing it right, and the still you posted looks like it has so much of a difference between frames that no amount of motion estimation could compensate. In cases like that, hardware converters fall back to a typical line interpolation mode for that field. In full motion, you hardly notice it. The results are very similar to something like ConvertFPS(59.94, zone=80). This leaves a "gradiated band" in one field that gradually switches from the previous image to the new image, but in full motion on a regular interlaced television it is extremely difficult to detect (of course it's obvious on a full field freeze-frame on computer).

Now for the news you don't want to hear: For a DVD I'm doing with source material in PAL with a LOT of full motion smooth movements (think dance videos), I am using MVFlowFPS2 for everything and I put that on track B; I then do a conversion using ConvertFPS(59.94, zone=80) and put that on track A. Anywhere MVFlowFPS2 makes a mistake, I cut that frame out and use the frame from the ConvertFPS conversion. Tedious, but it's pretty much a flawless conversion when I'm done.

[Trixter]

Originally Posted by Clown shoes

What is it you prefer about MVFlowFPS2? I have been comparing high motion sections frame by frame and although I can find hardly any difference between them, I would say I've found fractionaly more motion artifacts with MVFlowFPS2. I'm curious to know what advantage there is to the MVTools route in your opinion.

It depends on the source material, of course. My source material is very synthetic (it was all computer generated; for examples of the type of motion, think title rolls and crawls) and for me, MVTools results in slightly less artifacts (and the artifacts that are there are less severe). Of course you should use what works best for your footage.

Here is a particularly fast panning head using MVTools' MVFlowFPS2:



...and here is the same interpolation as done by MotionProtectedFPS:



As you can see, the MotionProtectedFPS example has more distortion, as well as chroma flying all over the place :-) This isn't a massive slam on MotionProtectedFPS, just an example of why I use MVFlowFPS2. If I'm doing a quickie for viewing an MPEG-1 on television or something, MotionProtectedFPS's speed is fantastic. If I'm transcoding footage for a DVD for commercial sale, I use MVTools for the most quality. Just my $0.02.

[videoFred]

Originally Posted by Didée

Result is free or artefacts, of course. But really good it is only on clear pans. On "globally still" frames, all in-frame motion still is stuttering ... and on some difficult scenes (global shift to one side, but big objects moving to the other side), the stutter is, well, funny.
No surprise, though ... depan is doing exactly what it's designed to do: shifting the frame as a whole.

Because all my old 8mm films are all original made at 15-16-18fps, and without the use of a tripod, I need a good frame rate conversion/stabilising script.

I confirm the depan, method is perfect for clear pans...
But not for moving objects and/or zoom scenes. Stuttering!
I have the best results with mvflowfps() followed by depan for stabilising.

Motionprotectedfps() gives very good results too, and it is much faster.

Actualy, both are giving me near perfect results in 90% of the cases... The artefacts are almost invisible on TV.

Very fast moving people/objects, original recorded at low speeds like 15FPS are giving me the most problems. Maybe I am going to use convertfps() for these scenes instead.

*EDIT* MvFlowFPS2 works a lot better for this.



Fred.

[Chainmax]

Originally Posted by Clown shoes

...
@ Didee

I tried increasing ml but I didn't see any difference at all! Very strange.

Neither did I on my problem video .

Originally Posted by Trixter

...
Now for the news you don't want to hear: For a DVD I'm doing with source material in PAL with a LOT of full motion smooth movements (think dance videos), I am using MVFlowFPS2 for everything and I put that on track B; I then do a conversion using ConvertFPS(59.94, zone=80) and put that on track A. Anywhere MVFlowFPS2 makes a mistake, I cut that frame out and use the frame from the ConvertFPS conversion. Tedious, but it's pretty much a flawless conversion when I'm done.

That's exactly what I was trying to do a while back but didn't know what to use as an alternate framerate converter. I'll try that, thanks for the suggestion . I have a question though, I use the following MVFlowFPS lines:

vf=last.mvanalyse(isb=false,blksize=4,pel=2,search=3,truemotion=true)
vb=last.mvanalyse(isb=true,blksize=4,pel=2,search=3,truemotion=true)
MVFlowFPS(last,vb,vf,num=30000,den=1001)

Would that give worse results than MVFlowFPS2?

[Clown shoes]

Originally Posted by Trixter

num should be 60000, not 6000.

lol, yes that's most definately a typo!

Originally Posted by Trixter

I then do a conversion using ConvertFPS(59.94, zone=80) and put that on track A. Anywhere MVFlowFPS2 makes a mistake, I cut that frame out and use the frame from the ConvertFPS conversion. Tedious, but it's pretty much a flawless conversion when I'm done.

Sounds like a good idea, but wow that is really gonna add to the overall time it takes to do a standards conversion. That is exactly what I asked for though, the best quality disregarding time as an issue. So thank you trixter and it's good to hear you using it in a commercial enviroment. If a client comes to me with either a short peice of work or a longer peice where time is not an issue. I am now confident I can produce a professional looking standards conversion on a par with a hardware solution.

[Trixter]

Originally Posted by Chainmax

That's exactly what I was trying to do a while back but didn't know what to use as an alternate framerate converter. I'll try that, thanks for the suggestion . I have a question though, I use the following MVFlowFPS lines:

vf=last.mvanalyse(isb=false,blksize=4,pel=2,search=3,truemotion=true)
vb=last.mvanalyse(isb=true,blksize=4,pel=2,search=3,truemotion=true)
MVFlowFPS(last,vb,vf,num=30000,den=1001)

Would that give worse results than MVFlowFPS2?

That completely depends on your source material, so I can't answer that directly.

I see that you shrunk blocksize from 8 to 4... from the docs, larger blocks are less sensitive to noise, are faster, but also less accurate. A blocksize of 4 might exacerbate the noise already present in your source. I see you increased the search algorithm to exhaustive... with small blocks, you're going to be waiting a very long time :-)

MVFlowFPS2 uses two different motion analyses: A regular one and another one with the entire frame shifted half the block size diagonally. It then averages the results of both so that there are less estimation errors. So MVFlowFPS2 is always going to provide better motion estimation than just MVFlowFPS.

I would only use small block sizes like 4 if your source is less than 480 lines (like 320x240 640x360). If you're working with 720x480 or source, 8 is sufficient.

Finally, doing some quick math off the top of my head, MVFlowFPS2 with the default (subdividing) search algo and 8x8 blocksize should run faster than MVFlowFPS with an exhaustive search and 4x4 blocksize.

I shudder to think how long 4x4, exhaustive, FPS2 would take ;-)

[Chainmax]

Originally Posted by Trixter

...
I see that you shrunk blocksize from 8 to 4... from the docs, larger blocks are less sensitive to noise, are faster, but also less accurate. A blocksize of 4 might exacerbate the noise already present in your source.
...

I assumed that lower blocksizes meant better motion end results.
By the way, once I have the MVFlowFPS/2 and ChangeFPS encodes, is there a faster way to replace individual frames or frame ranges of the former with the corresponding ones from the latter than cutting and pasting (i.é: can I do it directly from Avisynth)?

[Clown shoes]

I would imagine the quickest way would be using an NLE like Avid or Premiere. Especially one with multicam mode which Avid definately has.

[Trixter]

Originally Posted by Clown shoes

I would imagine the quickest way would be using an NLE like Avid or Premiere. Especially one with multicam mode which Avid definately has.

I'm using Premiere Pro 1.5 currently (but as soon as this project is done you can be sure I'm going to upgrade). Multicam switching is for "live" switches (you literally press buttons while the video is running, like a real broadcast switcher), but I'm switching to a single frame, maybe two, so manually cutting the bad frames out is pretty much the only way to do it.

As for an AVISYNTH only solution, I would imagine you can use trim() but I've never done it... I would love to hear from the seasoned scriptwriters how something like this would be done.

[Trixter]

Originally Posted by Chainmax

I assumed that lower blocksizes meant better motion end results.

Last night I did a quick test using smaller blocksizes and it actually made the bad frames even more worse. I'll post pictures when I get home (I'm at work now).

[Chainmax]

Originally Posted by Trixter

...
I am using MVFlowFPS2 for everything and I put that on track B; I then do a conversion using ConvertFPS(59.94, zone=80) and put that on track A. Anywhere MVFlowFPS2 makes a mistake, I cut that frame out and use the frame from the ConvertFPS conversion. Tedious, but it's pretty much a flawless conversion when I'm done.

I am trying ConvertFPS(29.97, zone=80) on a 15-to-29.97 conversion and I have to say that ConvertFPS does an awful job. When stepping through the ConvertFPS script, it sometimes a given frame is exactly like the previous one but with the bottom half shifted to the left or right. It's very nasty .

I really wish MVTools could be altered so that a new MVFlowFPS parameter would be created. This new parameter would be linked to the artifacting (no idea how) and if in a given frame it exceeds or falls below a user-defined threshold then the frame in question would be replaced by an interpolation of the previous and next frame. How feasible would that be?

[actionman133]

Originally Posted by Trixter

Last night I did a quick test using smaller blocksizes and it actually made the bad frames even more worse. I'll post pictures when I get home (I'm at work now).

I agree with Trixter on this. I've found that lower blksize = 4 produces poorer results than blksize=8. I attributed it to the fact that a 4x4 block doesn't have much detail in it to provide reasonable vectors, whereas an 8x8 block can show better edges, and thus get a better vector. I also think the radius defined by searchparam is directly related to the block size. So blksize=4 has half the search radius of blksize=8....

I might be wrong on that last point, so feel free to correct me if I am.

[Revgen]

I wish there was a way to adaptively use multiple block sizes kinda like what X264 does.

[actionman133]

Perhaps an algorithm could be written where it initially tests 16x16 blocks. If the amount of detail (determined by some algorithm that searches for texture) in a block exceeds one threshold, it reduces that block to 4 blocks of 8x8. If it exceeds a higher threshold, it could reduce it to 16 blocks of 4x4.

Would that be possible?

Actually, should this go to the MVTools thread?

[Trixter]

Originally Posted by Chainmax

I am trying ConvertFPS(29.97, zone=80) on a 15-to-29.97 conversion and I have to say that ConvertFPS does an awful job. When stepping through the ConvertFPS script, it sometimes a given frame is exactly like the previous one but with the bottom half shifted to the left or right. It's very nasty .

Well, you have three options without motion compensation:

1. ChangeFPS: Add or drop frames to meet target. Good: No blended frames. Bad: Jerky motion on pans.
2. ConvertFPS: Blend frames across time to meet target. Good: Softer (not smoother) motion. Bad: Blended frames.
3. ConvertFPS(zone): Blend frames, but only at the precise moment in a CRT's scanrate. Good: Precise moment-in-time switches. Bad: Individual "half" frames.

Yes, with the third option you can see a frame blend across 80 lines into the new image... but when you're watching on a television that scans top to bottom 60 times a second, 99% of the population won't notice it. It hurts horizontal panning/crawls, but little else. And remember, most people aren't going to be pausing to stare at a bad image that is 1/60th of a second long :-)

Since my DVD is mastered specifically for television, the zone=80 method is what I'm using. In motion, it's less jerky than without zone=80. Freeze-framed, it has those "inbetween" frames. So you have to pick what you like best.

I really wish MVTools could be altered so that a new MVFlowFPS parameter would be created. This new parameter would be linked to the artifacting (no idea how) and if in a given frame it exceeds or falls below a user-defined threshold then the frame in question would be replaced by an interpolation of the previous and next frame. How feasible would that be?

Not at all, since what metric would you have that the estimation was wrong? How could you tell? Remember, you're creating frames where none exist. Our eyes can tell us when something doesn't look right, but to the mocomp algorithm, it's making it's best guess.

That being said, it might be possible to "fall through" to a ChangeFPS/ConvertFPS frame if the certainty of the mocomp vector analysis falls below a certain threshhold, but I have no idea how to script that. Scharfis might have already done something like that somewhere in mvbob() but I'm not brave enough to comment every line to find out.

[Trixter]

Originally Posted by actionman133

I agree with Trixter on this. I've found that lower blksize = 4 produces poorer results than blksize=8.

Thanks, you saved me from making new shots ;-)

[actionman133]

Your welcome, Trixter... always glad to help where I can.

But do you reckon the possibility of variable block size analysis would be feasible for application? They do it for motion compensation in video compression... Would it work with MVFlowFPS?

[foxyshadis]

x264 has some of the most advanced ME algorithms available in the open source world, if they could be cut-and-pasted into mvtools I'm sure it would improve output (and cut speed), though it'd take quite a bit of work to port their interfaces. It's certainly possible. On the other hand, x264 gets to rely on texture bits to make up for any deficiencies, and it's designed for qpel (although it doesn't necessarily have to use it).

It'd certainly be a cool summer project by someone interested.

[actionman133]

Should this recommendation be forwarded over to the MVTools thread?